[PATCH] documentation: ntb.txt correct grammar "however"
Correct the grammar around the word however. Signed-off-by: Justin Keller <justincomp...@gmail.com> --- index 1d9bbab..5d43510 100644 --- a/Documentation/ntb.txt +++ b/Documentation/ntb.txt @@ -35,7 +35,7 @@ establishes a logical link to the peer, and creates queue pairs to exchange messages and data. The NTB Netdev then creates an ethernet device using a Transport queue pair. Network data is copied between socket buffers and the Transport queue pair buffer. The Transport client may be used for other things -besides Netdev, however no other applications have yet been written. +besides Netdev; however, no other applications have yet been written. ### NTB Ping Pong Test Client (ntb\_pingpong)
[PATCH] documentation: ntb.txt correct grammar "however"
Correct the grammar around the word however. Signed-off-by: Justin Keller --- index 1d9bbab..5d43510 100644 --- a/Documentation/ntb.txt +++ b/Documentation/ntb.txt @@ -35,7 +35,7 @@ establishes a logical link to the peer, and creates queue pairs to exchange messages and data. The NTB Netdev then creates an ethernet device using a Transport queue pair. Network data is copied between socket buffers and the Transport queue pair buffer. The Transport client may be used for other things -besides Netdev, however no other applications have yet been written. +besides Netdev; however, no other applications have yet been written. ### NTB Ping Pong Test Client (ntb\_pingpong)
patch to fix small grammar error
Hello, I have a small patch to the memory-hotplug documentation. One line adds a comma, and the other line adds an and. Justin Keller --- Documentation/memory-hotplug.txt.orig 2016-02-11 11:21:22.0 -0500 +++ Documentation/memory-hotplug.txt 2016-02-11 11:23:08.0 -0500 @@ -88,9 +88,9 @@ 1.3. Unit of Memory online/offline operation -Memory hotplug uses SPARSEMEM memory model which allows memory to be divided +Memory hotplug uses SPARSEMEM memory model, which allows memory to be divided into chunks of the same size. These chunks are called "sections". The size of -a memory section is architecture dependent. For example, power uses 16MiB, ia64 +a memory section is architecture dependent. For example, power uses 16MiB and ia64 uses 1GiB. Memory sections are combined into chunks referred to as "memory blocks". The
patch to fix small grammar error
Hello, I have a small patch to the memory-hotplug documentation. One line adds a comma, and the other line adds an and. Justin Keller --- Documentation/memory-hotplug.txt.orig 2016-02-11 11:21:22.0 -0500 +++ Documentation/memory-hotplug.txt 2016-02-11 11:23:08.0 -0500 @@ -88,9 +88,9 @@ 1.3. Unit of Memory online/offline operation -Memory hotplug uses SPARSEMEM memory model which allows memory to be divided +Memory hotplug uses SPARSEMEM memory model, which allows memory to be divided into chunks of the same size. These chunks are called "sections". The size of -a memory section is architecture dependent. For example, power uses 16MiB, ia64 +a memory section is architecture dependent. For example, power uses 16MiB and ia64 uses 1GiB. Memory sections are combined into chunks referred to as "memory blocks". The
possible patch
Hello,
I am new to submitting patches, so sorry if I am doing it wrong. My idea was
to change line 147 in drivers/isdn/pcbit/callbacks.c from
if (cbdata->data.setup.CallingPN == NULL) {
to
if (cbdata->data.setup.CallingPN == NULL ||
sizeof(cbdata->data.setup.CallingPN)>sizeof(ictl.parm.setup.phone) {
Justin Keller
possible patch
Hello,
I am new to submitting patches, so sorry if I am doing it wrong. My idea was
to change line 147 in drivers/isdn/pcbit/callbacks.c from
if (cbdata->data.setup.CallingPN == NULL) {
to
if (cbdata->data.setup.CallingPN == NULL ||
sizeof(cbdata->data.setup.CallingPN)>sizeof(ictl.parm.setup.phone) {
Justin Keller
update README
The README file specifics 3.X kernel in different places. The kernel is now 4.X, no longer 3.X Justin Keller diff --git a/README b/linux/README index a24ec89..67fc7a8 100644 --- a/README +++ b/linux/README @@ -1,6 +1,6 @@ -Linux kernel release 3.x <http://kernel.org/> +Linux kernel release 4.x <http://kernel.org/> -These are the release notes for Linux version 3. Read them carefully, +These are the release notes for Linux version 4. Read them carefully, as they tell you what this is all about, explain how to install the kernel, and what to do if something goes wrong. @@ -62,11 +62,11 @@ INSTALLING the kernel source: directory where you have permissions (eg. your home directory) and unpack it: - gzip -cd linux-3.X.tar.gz | tar xvf - + gzip -cd linux-4.X.tar.gz | tar xvf - or - bzip2 -dc linux-3.X.tar.bz2 | tar xvf - + bzip2 -dc linux-4.X.tar.bz2 | tar xvf - Replace "X" with the version number of the latest kernel. @@ -75,16 +75,16 @@ INSTALLING the kernel source: files. They should match the library, and not get messed up by whatever the kernel-du-jour happens to be. - - You can also upgrade between 3.x releases by patching. Patches are + - You can also upgrade between 4.x releases by patching. Patches are distributed in the traditional gzip and the newer bzip2 format. To install by patching, get all the newer patch files, enter the - top level directory of the kernel source (linux-3.X) and execute: + top level directory of the kernel source (linux-4.X) and execute: - gzip -cd ../patch-3.x.gz | patch -p1 + gzip -cd ../patch-4.x.gz | patch -p1 or - bzip2 -dc ../patch-3.x.bz2 | patch -p1 + bzip2 -dc ../patch-4.x.bz2 | patch -p1 Replace "x" for all versions bigger than the version "X" of your current source tree, _in_order_, and you should be ok. You may want to remove @@ -92,13 +92,13 @@ INSTALLING the kernel source: that there are no failed patches (some-file-name# or some-file-name.rej). If there are, either you or I have made a mistake. - Unlike patches for the 3.x kernels, patches for the 3.x.y kernels + Unlike patches for the 4.x kernels, patches for the 4.x.y kernels (also known as the -stable kernels) are not incremental but instead apply - directly to the base 3.x kernel. For example, if your base kernel is 3.0 - and you want to apply the 3.0.3 patch, you must not first apply the 3.0.1 - and 3.0.2 patches. Similarly, if you are running kernel version 3.0.2 and - want to jump to 3.0.3, you must first reverse the 3.0.2 patch (that is, - patch -R) _before_ applying the 3.0.3 patch. You can read more on this in + directly to the base 4.x kernel. For example, if your base kernel is 4.0 + and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1 + and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and + want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is, + patch -R) _before_ applying the 4.0.3 patch. You can read more on this in Documentation/applying-patches.txt Alternatively, the script patch-kernel can be used to automate this @@ -120,7 +120,7 @@ INSTALLING the kernel source: SOFTWARE REQUIREMENTS - Compiling and running the 3.x kernels requires up-to-date + Compiling and running the 4.x kernels requires up-to-date versions of various software packages. Consult Documentation/Changes for the minimum version numbers required and how to get updates for these packages. Beware that using @@ -137,12 +137,12 @@ BUILD directory for the kernel: place for the output files (including .config). Example: - kernel source code: /usr/src/linux-3.X + kernel source code: /usr/src/linux-4.X build directory:/home/name/build/kernel To configure and build the kernel, use: - cd /usr/src/linux-3.X + cd /usr/src/linux-4.X make O=/home/name/build/kernel menuconfig make O=/home/name/build/kernel sudo make O=/home/name/build/kernel modules_install install -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
update README
The README file specifics 3.X kernel in different places. The kernel is now 4.X, no longer 3.X Justin Keller diff --git a/README b/linux/README index a24ec89..67fc7a8 100644 --- a/README +++ b/linux/README @@ -1,6 +1,6 @@ -Linux kernel release 3.x http://kernel.org/ +Linux kernel release 4.x http://kernel.org/ -These are the release notes for Linux version 3. Read them carefully, +These are the release notes for Linux version 4. Read them carefully, as they tell you what this is all about, explain how to install the kernel, and what to do if something goes wrong. @@ -62,11 +62,11 @@ INSTALLING the kernel source: directory where you have permissions (eg. your home directory) and unpack it: - gzip -cd linux-3.X.tar.gz | tar xvf - + gzip -cd linux-4.X.tar.gz | tar xvf - or - bzip2 -dc linux-3.X.tar.bz2 | tar xvf - + bzip2 -dc linux-4.X.tar.bz2 | tar xvf - Replace X with the version number of the latest kernel. @@ -75,16 +75,16 @@ INSTALLING the kernel source: files. They should match the library, and not get messed up by whatever the kernel-du-jour happens to be. - - You can also upgrade between 3.x releases by patching. Patches are + - You can also upgrade between 4.x releases by patching. Patches are distributed in the traditional gzip and the newer bzip2 format. To install by patching, get all the newer patch files, enter the - top level directory of the kernel source (linux-3.X) and execute: + top level directory of the kernel source (linux-4.X) and execute: - gzip -cd ../patch-3.x.gz | patch -p1 + gzip -cd ../patch-4.x.gz | patch -p1 or - bzip2 -dc ../patch-3.x.bz2 | patch -p1 + bzip2 -dc ../patch-4.x.bz2 | patch -p1 Replace x for all versions bigger than the version X of your current source tree, _in_order_, and you should be ok. You may want to remove @@ -92,13 +92,13 @@ INSTALLING the kernel source: that there are no failed patches (some-file-name# or some-file-name.rej). If there are, either you or I have made a mistake. - Unlike patches for the 3.x kernels, patches for the 3.x.y kernels + Unlike patches for the 4.x kernels, patches for the 4.x.y kernels (also known as the -stable kernels) are not incremental but instead apply - directly to the base 3.x kernel. For example, if your base kernel is 3.0 - and you want to apply the 3.0.3 patch, you must not first apply the 3.0.1 - and 3.0.2 patches. Similarly, if you are running kernel version 3.0.2 and - want to jump to 3.0.3, you must first reverse the 3.0.2 patch (that is, - patch -R) _before_ applying the 3.0.3 patch. You can read more on this in + directly to the base 4.x kernel. For example, if your base kernel is 4.0 + and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1 + and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and + want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is, + patch -R) _before_ applying the 4.0.3 patch. You can read more on this in Documentation/applying-patches.txt Alternatively, the script patch-kernel can be used to automate this @@ -120,7 +120,7 @@ INSTALLING the kernel source: SOFTWARE REQUIREMENTS - Compiling and running the 3.x kernels requires up-to-date + Compiling and running the 4.x kernels requires up-to-date versions of various software packages. Consult Documentation/Changes for the minimum version numbers required and how to get updates for these packages. Beware that using @@ -137,12 +137,12 @@ BUILD directory for the kernel: place for the output files (including .config). Example: - kernel source code: /usr/src/linux-3.X + kernel source code: /usr/src/linux-4.X build directory:/home/name/build/kernel To configure and build the kernel, use: - cd /usr/src/linux-3.X + cd /usr/src/linux-4.X make O=/home/name/build/kernel menuconfig make O=/home/name/build/kernel sudo make O=/home/name/build/kernel modules_install install -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] livepatch: Fix the bug if the function name is larger than KSYM_NAME_LEN-1
I agree that 128+ function names are bad and there is no need for such long names, epically for compatibility with 80 char/line displays. I cannot think of an example even near as long as 127 characters. Are there even such long function names anywhere in the kernel? Justin On Wed, Apr 15, 2015 at 7:58 AM, Miroslav Benes wrote: > On Wed, 15 Apr 2015, Minfei Huang wrote: > >> On 04/15/15 at 10:30P, Miroslav Benes wrote: >> > On Wed, 15 Apr 2015, Minfei Huang wrote: >> > >> > > >> > > Yes, the function name can be changed, before the extra module is >> > > installed to the production system. >> > > >> > > We discuss around and around, there are still some confusion with it. >> > > >> > > 1) How does end user know that livepatch can _not_ support the function >> > > which length is larger than 127. We can not enforce the end user >> > > to know the livepatch and kallsyms code in detail. >> > > 2) How does end user use livepatch to patch running extra module, once >> > > the module is running in the production system, if the function name >> > > is insane. >> > > 3) The error message is ambiguity, if we try to patch the overlength >> > > function. We can give the error message clearly, once the function >> > > name is overlength. >> > > >> > > I think it is better that we can take more time on the people who will >> > > use livepatch frequently. >> > >> > Just my two cents, even if we admit that such change is worth it (and I >> > am still not convinced that it is the case), I think it would make sense >> > to fix it somewhere in kallsyms as Josh proposed. I suspect that when >> >> Ohhh... >> >> Fixing kallsyms to restrict the function name length maybe is not a good >> idea. I have no idea how we should do this, except for the coding >> problems. > > Well we do it now via scripts/kallsyms.c when vmlinux is built. Try it. We > apparently do not do it when kernel modules are built out of the tree (as > you demonstrated before). So the question is whether we should do it also > there. That is one thing we try to tell you. > > The other one is that 128 characters long function names are insane. > Probably that is what KSYM_NAME_LEN is for in the first place. Maybe you > could even try to add the check to checkpatch.pl. > >> > function names longer than KSYM_NAME_LEN were common there would be many >> > similar problems elsewhere in the kernel. >> > >> > That is you can prepare a patch to kallsyms and submit it there. Not sure >> > who is the maintainer but he might have an opinion about this... >> > >> > Thanks, >> > Miroslav >> >> Hold on, I get a scenario that livepatch may do fatal error. I am fine >> that livepatch do not support overlength function name, because it can >> not corrupt the kernel. >> >> Once there is a function name A is larger than 127, and another function >> name B is as longer as 127, it is disaster that we want to patch >> function B, if function name of first 127 is same between A and B. > > True, but see above. > >> Livepatch may find the function of A to patch it. So this patch(2/2) may >> be needed to fix the issue. > > Hm, but this patch is not the solution for the issue, or is it? You would > check only those first KSYM_NAME_LEN characters, but that would not > differentiate between A and B. Or maybe I do not follow. > > Thanks > Miroslav > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow
Is there a reason for "step = leap"?
On Wed, Apr 15, 2015 at 11:41 AM, Miroslav Lichvar wrote:
> On systems with 32-bit time_t, it seems there are quite a few problems
> that applications may have with time overflowing in year 2038. Beside
> getting in an unexpected state by not checking integer operations with
> time_t variables, some system calls have unexpected behavior, e.g. the
> system time can't be set back to the current time (negative value),
> timers with the ABSTIME flag can't be set (negative value) or they
> expire immediately (current time is always larger).
>
> It would be unrealistic to expect all applications to be able to handle
> all these problems. Year 2038 is still many years away, but this can be
> a problem even now. The clock can be set close to the overflow
> accidentally or maliciously, e.g. when the clock is synchronized over
> network by NTP or PTP.
>
> This patch sets a maximum value of the system time to prevent the system
> time from getting too close to the overflow. The time can't be set to a
> larger value. When the maximum is reached in normal time accumulation,
> the clock will be stepped back by one week.
>
> A new kernel sysctl time_max is added to select the maximum time. It can
> be set to 0 for no limit, 1 for one week before 32-bit time_t overflow,
> and 2 for one week before ktime_t overflow. The default value is 1 with
> 32-bit time_t and 2 with 64-bit time_t. This can be changed later to be
> always 2 when 64-bit versions of system calls using 32-bit time_t are
> available.
>
> Signed-off-by: Miroslav Lichvar
> ---
> Documentation/sysctl/kernel.txt | 19 +
> include/linux/timekeeping.h | 5
> include/uapi/linux/sysctl.h | 1 +
> kernel/sysctl.c | 9 ++
> kernel/sysctl_binary.c | 1 +
> kernel/time/timekeeping.c | 62
> +
> 6 files changed, 91 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index 83ab256..08e4f28 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -82,6 +82,7 @@ show up in /proc/sys/kernel:
> - sysctl_writes_strict
> - tainted
> - threads-max
> +- time_max
> - unknown_nmi_panic
> - watchdog_thresh
> - version
> @@ -847,6 +848,24 @@ can be ORed together:
>
> ==
>
> +time_max:
> +
> +Select the maximum allowed value of the system time. The system clock cannot
> be
> +set to a larger value and when it reaches the maximum on its own, it will be
> +stepped back by one week.
> +
> +0: No limit.
> +
> +1: One week before 32-bit time_t overflows, i.e. Jan 12 03:14:07 UTC 2038.
> + This is currently the default value with 32-bit time_t, but it will likely
> + change when 64-bit versions of system calls using time_t are available.
> +
> +2: One week before time in the internal kernel representation (ktime_t)
> + overflows, i.e. Apr 4 23:47:16 UTC 2262. This is the default value with
> + 64-bit time_t.
> +
> +==
> +
> unknown_nmi_panic:
>
> The value in this file affects behavior of handling NMI. When the
> diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> index 99176af..51fc970 100644
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -5,6 +5,11 @@
>
> void timekeeping_init(void);
> extern int timekeeping_suspended;
> +extern int sysctl_time_max;
> +
> +struct ctl_table;
> +extern int sysctl_time_max_handler(struct ctl_table *table, int write,
> + void __user *buffer, size_t *length, loff_t *ppos);
>
> /*
> * Get and set timeofday
> diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
> index 0956373..8fd2aab 100644
> --- a/include/uapi/linux/sysctl.h
> +++ b/include/uapi/linux/sysctl.h
> @@ -154,6 +154,7 @@ enum
> KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
> KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered
> */
> KERN_PANIC_ON_WARN=77, /* int: call panic() in WARN() functions */
> + KERN_TIMEMAX=78,/* int: select maximum allowed system time */
> };
>
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index ce410bb..6713a5b 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1120,6 +1120,15 @@ static struct ctl_table kern_table[] = {
> .extra1 = ,
> .extra2 = ,
> },
> + {
> + .procname = "time_max",
> + .data = _time_max,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = sysctl_time_max_handler,
> + .extra1 = ,
> + .extra2 = ,
> + },
> { }
> };
>
> diff --git a/kernel/sysctl_binary.c
Re: [PATCH 2/2] livepatch: Fix the bug if the function name is larger than KSYM_NAME_LEN-1
I agree that 128+ function names are bad and there is no need for such long names, epically for compatibility with 80 char/line displays. I cannot think of an example even near as long as 127 characters. Are there even such long function names anywhere in the kernel? Justin On Wed, Apr 15, 2015 at 7:58 AM, Miroslav Benes mbe...@suse.cz wrote: On Wed, 15 Apr 2015, Minfei Huang wrote: On 04/15/15 at 10:30P, Miroslav Benes wrote: On Wed, 15 Apr 2015, Minfei Huang wrote: Yes, the function name can be changed, before the extra module is installed to the production system. We discuss around and around, there are still some confusion with it. 1) How does end user know that livepatch can _not_ support the function which length is larger than 127. We can not enforce the end user to know the livepatch and kallsyms code in detail. 2) How does end user use livepatch to patch running extra module, once the module is running in the production system, if the function name is insane. 3) The error message is ambiguity, if we try to patch the overlength function. We can give the error message clearly, once the function name is overlength. I think it is better that we can take more time on the people who will use livepatch frequently. Just my two cents, even if we admit that such change is worth it (and I am still not convinced that it is the case), I think it would make sense to fix it somewhere in kallsyms as Josh proposed. I suspect that when Ohhh... Fixing kallsyms to restrict the function name length maybe is not a good idea. I have no idea how we should do this, except for the coding problems. Well we do it now via scripts/kallsyms.c when vmlinux is built. Try it. We apparently do not do it when kernel modules are built out of the tree (as you demonstrated before). So the question is whether we should do it also there. That is one thing we try to tell you. The other one is that 128 characters long function names are insane. Probably that is what KSYM_NAME_LEN is for in the first place. Maybe you could even try to add the check to checkpatch.pl. function names longer than KSYM_NAME_LEN were common there would be many similar problems elsewhere in the kernel. That is you can prepare a patch to kallsyms and submit it there. Not sure who is the maintainer but he might have an opinion about this... Thanks, Miroslav Hold on, I get a scenario that livepatch may do fatal error. I am fine that livepatch do not support overlength function name, because it can not corrupt the kernel. Once there is a function name A is larger than 127, and another function name B is as longer as 127, it is disaster that we want to patch function B, if function name of first 127 is same between A and B. True, but see above. Livepatch may find the function of A to patch it. So this patch(2/2) may be needed to fix the issue. Hm, but this patch is not the solution for the issue, or is it? You would check only those first KSYM_NAME_LEN characters, but that would not differentiate between A and B. Or maybe I do not follow. Thanks Miroslav -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow
Is there a reason for step = leap?
On Wed, Apr 15, 2015 at 11:41 AM, Miroslav Lichvar mlich...@redhat.com wrote:
On systems with 32-bit time_t, it seems there are quite a few problems
that applications may have with time overflowing in year 2038. Beside
getting in an unexpected state by not checking integer operations with
time_t variables, some system calls have unexpected behavior, e.g. the
system time can't be set back to the current time (negative value),
timers with the ABSTIME flag can't be set (negative value) or they
expire immediately (current time is always larger).
It would be unrealistic to expect all applications to be able to handle
all these problems. Year 2038 is still many years away, but this can be
a problem even now. The clock can be set close to the overflow
accidentally or maliciously, e.g. when the clock is synchronized over
network by NTP or PTP.
This patch sets a maximum value of the system time to prevent the system
time from getting too close to the overflow. The time can't be set to a
larger value. When the maximum is reached in normal time accumulation,
the clock will be stepped back by one week.
A new kernel sysctl time_max is added to select the maximum time. It can
be set to 0 for no limit, 1 for one week before 32-bit time_t overflow,
and 2 for one week before ktime_t overflow. The default value is 1 with
32-bit time_t and 2 with 64-bit time_t. This can be changed later to be
always 2 when 64-bit versions of system calls using 32-bit time_t are
available.
Signed-off-by: Miroslav Lichvar mlich...@redhat.com
---
Documentation/sysctl/kernel.txt | 19 +
include/linux/timekeeping.h | 5
include/uapi/linux/sysctl.h | 1 +
kernel/sysctl.c | 9 ++
kernel/sysctl_binary.c | 1 +
kernel/time/timekeeping.c | 62
+
6 files changed, 91 insertions(+), 6 deletions(-)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 83ab256..08e4f28 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -82,6 +82,7 @@ show up in /proc/sys/kernel:
- sysctl_writes_strict
- tainted
- threads-max
+- time_max
- unknown_nmi_panic
- watchdog_thresh
- version
@@ -847,6 +848,24 @@ can be ORed together:
==
+time_max:
+
+Select the maximum allowed value of the system time. The system clock cannot
be
+set to a larger value and when it reaches the maximum on its own, it will be
+stepped back by one week.
+
+0: No limit.
+
+1: One week before 32-bit time_t overflows, i.e. Jan 12 03:14:07 UTC 2038.
+ This is currently the default value with 32-bit time_t, but it will likely
+ change when 64-bit versions of system calls using time_t are available.
+
+2: One week before time in the internal kernel representation (ktime_t)
+ overflows, i.e. Apr 4 23:47:16 UTC 2262. This is the default value with
+ 64-bit time_t.
+
+==
+
unknown_nmi_panic:
The value in this file affects behavior of handling NMI. When the
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 99176af..51fc970 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -5,6 +5,11 @@
void timekeeping_init(void);
extern int timekeeping_suspended;
+extern int sysctl_time_max;
+
+struct ctl_table;
+extern int sysctl_time_max_handler(struct ctl_table *table, int write,
+ void __user *buffer, size_t *length, loff_t *ppos);
/*
* Get and set timeofday
diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index 0956373..8fd2aab 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h
@@ -154,6 +154,7 @@ enum
KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered
*/
KERN_PANIC_ON_WARN=77, /* int: call panic() in WARN() functions */
+ KERN_TIMEMAX=78,/* int: select maximum allowed system time */
};
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ce410bb..6713a5b 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1120,6 +1120,15 @@ static struct ctl_table kern_table[] = {
.extra1 = zero,
.extra2 = one,
},
+ {
+ .procname = time_max,
+ .data = sysctl_time_max,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = sysctl_time_max_handler,
+ .extra1 = zero,
+ .extra2 = two,
+ },
{ }
};
diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
index 7e7746a..66c0946 100644
--- a/kernel/sysctl_binary.c
NMI watchdog
Hello, Although not running a vanilla kernel on this machine, I have reported the issue to the distribution's bug tracking system. It has been almost a week with no response, so I am sending this email. Multiple times, when I return to my computer from being away for a little while, I noticed: Message from syslogd@redacted at Mar 23 XX:XX:XX ... kernel:[1059322.470817] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kswapd0:31] Dmesg | grep NMI produced: [1151200.727734] sending NMI to all CPUs: [1151200.727812] NMI backtrace for cpu 0 [1151200.764129] INFO: NMI handler (arch_trigger_all_cpu_backtrace_handler) took too long to run: 36.262 msecs [1151200.764198] NMI backtrace for cpu 1 [1151216.700893] sending NMI to all CPUs: [1151216.700984] NMI backtrace for cpu 1 [1151216.706524] NMI backtrace for cpu 0 [1723994.455161] [] ? dump_stack+0x41/0x51 I didn't have time to grep for kswapd or to investigate further. Long story short, the machine was shutdown shortly afterwords. Justin PS this was also sent to linux-watchdog. I forgot to turn of HTML, so I had to re-send it here -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NMI watchdog
Hello, Although not running a vanilla kernel on this machine, I have reported the issue to the distribution's bug tracking system. It has been almost a week with no response, so I am sending this email. Multiple times, when I return to my computer from being away for a little while, I noticed: Message from syslogd@redacted at Mar 23 XX:XX:XX ... kernel:[1059322.470817] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kswapd0:31] Dmesg | grep NMI produced: [1151200.727734] sending NMI to all CPUs: [1151200.727812] NMI backtrace for cpu 0 [1151200.764129] INFO: NMI handler (arch_trigger_all_cpu_backtrace_handler) took too long to run: 36.262 msecs [1151200.764198] NMI backtrace for cpu 1 [1151216.700893] sending NMI to all CPUs: [1151216.700984] NMI backtrace for cpu 1 [1151216.706524] NMI backtrace for cpu 0 [1723994.455161] NMI [81554a5e] ? dump_stack+0x41/0x51 I didn't have time to grep for kswapd or to investigate further. Long story short, the machine was shutdown shortly afterwords. Justin PS this was also sent to linux-watchdog. I forgot to turn of HTML, so I had to re-send it here -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
