Re: [PATCH v2] doc: add maintainer book

On Sat, Nov 25, 2017 at 08:44:19AM +1100, Tobin C. Harding wrote: > There is currently very little documentation in the kernel on maintainer > level tasks. In particular there are no documents on creating pull > requests to submit to Linus. > > Quoting Greg Kroah-Hartman on LKML: > > Anyway,

Re: [PATCH v2] doc: add maintainer book

On Sat, Nov 25, 2017 at 08:44:19AM +1100, Tobin C. Harding wrote: > There is currently very little documentation in the kernel on maintainer > level tasks. In particular there are no documents on creating pull > requests to submit to Linus. > > Quoting Greg Kroah-Hartman on LKML: > > Anyway,

About GPL license compliance of Tesla Model S, Linux kernel 4.4

Hi All, I want to talk about a potential GPL misuse of the Linux open source that is used by Tesla Model S. Some months ago, I have read that a version information of Linux kernel that is deployed into the commercial self-driving car such as Tesla Model S via (1) the twitter web page of Tesla CEO

About GPL license compliance of Tesla Model S, Linux kernel 4.4

Hi All, I want to talk about a potential GPL misuse of the Linux open source that is used by Tesla Model S. Some months ago, I have read that a version information of Linux kernel that is deployed into the commercial self-driving car such as Tesla Model S via (1) the twitter web page of Tesla CEO

[PATCH net-next] bridge: ebtables: Avoid resetting limit rule state

So far any changes with ebtables will reset the state of limit rules, leading to spikes in traffic. This is especially noticeable if changes are done frequently, for instance via a daemon. This patch fixes this by bailing out from (re)setting if the limit rule was initialized before. When

[PATCH net-next] bridge: ebtables: Avoid resetting limit rule state

So far any changes with ebtables will reset the state of limit rules, leading to spikes in traffic. This is especially noticeable if changes are done frequently, for instance via a daemon. This patch fixes this by bailing out from (re)setting if the limit rule was initialized before. When

[PATCH resend] mm/page_alloc: fix comment is __get_free_pages

From: Jiankang Chen __get_free_pages will return an 64bit address in 64bit System like arm64 or x86_64. And this comment really confuse new bigenner of mm. Signed-off-by: Jiankang Chen --- mm/page_alloc.c | 2 +- 1 file changed, 1

[PATCH resend] mm/page_alloc: fix comment is __get_free_pages

From: Jiankang Chen __get_free_pages will return an 64bit address in 64bit System like arm64 or x86_64. And this comment really confuse new bigenner of mm. Signed-off-by: Jiankang Chen --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_alloc.c

[PATCH 1/4] staging: ccree: Remove a attribute group from a kobject

All attribute group created during sys_init_dir() should be removed in sys_free_dir() Signed-off-by: Arvind Yadav --- drivers/staging/ccree/ssi_sysfs.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_sysfs.c

[PATCH 1/4] staging: ccree: Remove a attribute group from a kobject

All attribute group created during sys_init_dir() should be removed in sys_free_dir() Signed-off-by: Arvind Yadav --- drivers/staging/ccree/ssi_sysfs.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_sysfs.c b/drivers/staging/ccree/ssi_sysfs.c

[PATCH 2/4] staging: lustre: ldlm: Remove a attribute group from a kobject

All attribute group created during ldlm_setup() should be removed in ldlm_cleanup(). Signed-off-by: Arvind Yadav --- drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH 2/4] staging: lustre: ldlm: Remove a attribute group from a kobject

All attribute group created during ldlm_setup() should be removed in ldlm_cleanup(). Signed-off-by: Arvind Yadav --- drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c

[PATCH 4/4] staging: most: Remove a attribute group from a kobject

All attribute group created during dim2_sysfs_probe() should be removed in dim2_sysfs_destroy(). Signed-off-by: Arvind Yadav --- drivers/staging/most/hdm-dim2/dim2_sysfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/most/hdm-dim2/dim2_sysfs.c

[PATCH 4/4] staging: most: Remove a attribute group from a kobject

All attribute group created during dim2_sysfs_probe() should be removed in dim2_sysfs_destroy(). Signed-off-by: Arvind Yadav --- drivers/staging/most/hdm-dim2/dim2_sysfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/most/hdm-dim2/dim2_sysfs.c

[PATCH 0/4] Remove a attribute group from a kobject

Arvind Yadav (4): [PATCH 1/4] staging: ccree: Remove a attribute group from a kobject [PATCH 2/4] staging: lustre: ldlm: Remove a attribute group from a kobject [PATCH 3/4] staging: lustre: obdclass: Remove a attribute group from a kobject [PATCH 4/4] staging: most: Remove a attribute

[PATCH 3/4] staging: lustre: obdclass: Remove a attribute group from a kobject

All attribute group created during class_procfs_init() should be removed. if class_procfs_init() will fail and also in class_procfs_clean(). Signed-off-by: Arvind Yadav --- drivers/staging/lustre/lustre/obdclass/linux/linux-module.c | 3 +++ 1 file changed, 3

[PATCH 0/4] Remove a attribute group from a kobject

Arvind Yadav (4): [PATCH 1/4] staging: ccree: Remove a attribute group from a kobject [PATCH 2/4] staging: lustre: ldlm: Remove a attribute group from a kobject [PATCH 3/4] staging: lustre: obdclass: Remove a attribute group from a kobject [PATCH 4/4] staging: most: Remove a attribute

[PATCH 3/4] staging: lustre: obdclass: Remove a attribute group from a kobject

All attribute group created during class_procfs_init() should be removed. if class_procfs_init() will fail and also in class_procfs_clean(). Signed-off-by: Arvind Yadav --- drivers/staging/lustre/lustre/obdclass/linux/linux-module.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH] mm/page_alloc: fix comment is __get_free_pages

From: c00426987 __get_free_pages will return an 64bit address in 64bit System like arm64 or x86_64. And this comment really confuse new bigenner of mm. reported-by: Hanjun Guo Signed-off-by: Chen Jiankang ---

[PATCH] mm/page_alloc: fix comment is __get_free_pages

From: c00426987 __get_free_pages will return an 64bit address in 64bit System like arm64 or x86_64. And this comment really confuse new bigenner of mm. reported-by: Hanjun Guo Signed-off-by: Chen Jiankang --- mm/page_alloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

Re: [dm-devel] [PATCH 3/4] dm: convert dm_dev_internal.count from atomic_t to refcount_t

On Fri, Nov 24, 2017 at 2:36 AM, Reshetova, Elena wrote: >> On Fri, Oct 20, 2017 at 10:37:38AM +0300, Elena Reshetova wrote: >> > } else if (dd->dm_dev->mode != (mode | dd->dm_dev->mode)) { >> > r = upgrade_mode(dd, mode, t->md); >> > if (r)

Re: [dm-devel] [PATCH 3/4] dm: convert dm_dev_internal.count from atomic_t to refcount_t

On Fri, Nov 24, 2017 at 2:36 AM, Reshetova, Elena wrote: >> On Fri, Oct 20, 2017 at 10:37:38AM +0300, Elena Reshetova wrote: >> > } else if (dd->dm_dev->mode != (mode | dd->dm_dev->mode)) { >> > r = upgrade_mode(dd, mode, t->md); >> > if (r) >> >

[PATCH] usbhid: add quirk for another PIXART OEM mouse used by HP

This mouse keep disconnecting in runleve 3 like below, add it needs the quirk to mute the anoying messages. [ 111.230555] usb 2-2: USB disconnect, device number 6 [ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd [ 112.941594] usb 2-2: New USB device found, idVendor=03f0,

[PATCH] usbhid: add quirk for another PIXART OEM mouse used by HP

This mouse keep disconnecting in runleve 3 like below, add it needs the quirk to mute the anoying messages. [ 111.230555] usb 2-2: USB disconnect, device number 6 [ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd [ 112.941594] usb 2-2: New USB device found, idVendor=03f0,

Re: [PATCH 2/2] clocksource: sprd: Add timer driver for Spreadtrum SC9860 platform

Hi Baolin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tip/timers/core] [also build test WARNING on v4.14 next-20171124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: [PATCH 2/2] clocksource: sprd: Add timer driver for Spreadtrum SC9860 platform

Hi Baolin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tip/timers/core] [also build test WARNING on v4.14 next-20171124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: [PATCH v2] staging: rtl8188eu: Fix private WEXT IOCTL calls

On Sat, Nov 25, 2017 at 02:29:36AM +0100, ishraq.i.ash...@gmail.com wrote: > + > + ret = 0; > + Sorry, I wasn't clear before. When I said don't initialize "ret" to zero, I just meant that in that specific case we initialized "ret" and then immediately reassigned it with: ret =

Re: [PATCH v2] staging: rtl8188eu: Fix private WEXT IOCTL calls

On Sat, Nov 25, 2017 at 02:29:36AM +0100, ishraq.i.ash...@gmail.com wrote: > + > + ret = 0; > + Sorry, I wasn't clear before. When I said don't initialize "ret" to zero, I just meant that in that specific case we initialized "ret" and then immediately reassigned it with: ret =

[PATCH v2] pata_pdc2027x: Remove unnecessary error check and coding style error.

Here, The function pdc_hardware_init always return zero. So it is not necessary to check its return value. So make the function return void. Fix these checkpatch.pl error: ERROR: space prohibited after that '~' (ctx:WxW) + mask &= ~ (1 << (6 + ATA_SHIFT_UDMA)); ERROR: spaces

Re: [PATCH 2/2] clocksource: sprd: Add timer driver for Spreadtrum SC9860 platform

Hi Baolin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tip/timers/core] [also build test WARNING on v4.14 next-20171124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

[PATCH v2] pata_pdc2027x: Remove unnecessary error check and coding style error.

Here, The function pdc_hardware_init always return zero. So it is not necessary to check its return value. So make the function return void. Fix these checkpatch.pl error: ERROR: space prohibited after that '~' (ctx:WxW) + mask &= ~ (1 << (6 + ATA_SHIFT_UDMA)); ERROR: spaces

Re: [PATCH 2/2] clocksource: sprd: Add timer driver for Spreadtrum SC9860 platform

Hi Baolin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tip/timers/core] [also build test WARNING on v4.14 next-20171124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: [PATCH 2/2] staging: rtl8188eu: Fix private WEXT IOCTL calls

Thanks for doing this. This needs to be folded in with the earlier patch you send and then resend it as a V2 patch. https://kernelnewbies.org/FirstKernelPatch#head-5c81b3c517a1d0bbc24f92594cb734e155fcbbcb I added Johannes to the CC list again because this is sort of his fault... To be honest,

Re: [PATCH 2/2] staging: rtl8188eu: Fix private WEXT IOCTL calls

Thanks for doing this. This needs to be folded in with the earlier patch you send and then resend it as a V2 patch. https://kernelnewbies.org/FirstKernelPatch#head-5c81b3c517a1d0bbc24f92594cb734e155fcbbcb I added Johannes to the CC list again because this is sort of his fault... To be honest,

Re: [PATCH] pata_pdc2027x: Remove unnecessary error check and coding style error.

On Sat, 2017-11-25 at 09:45 +0530, Arvind Yadav wrote: > Here, The function pdc_hardware_init always return zero. So it is not > necessary to check its return value. > > Fix these checkpatch.pl error: > > ERROR: space prohibited after that '~' (ctx:WxW) > + mask &= ~ (1 << (6 +

Re: [PATCH] pata_pdc2027x: Remove unnecessary error check and coding style error.

On Sat, 2017-11-25 at 09:45 +0530, Arvind Yadav wrote: > Here, The function pdc_hardware_init always return zero. So it is not > necessary to check its return value. > > Fix these checkpatch.pl error: > > ERROR: space prohibited after that '~' (ctx:WxW) > + mask &= ~ (1 << (6 +

[PATCH] pata_pdc2027x: Remove unnecessary error check and coding style error.

Here, The function pdc_hardware_init always return zero. So it is not necessary to check its return value. Fix these checkpatch.pl error: ERROR: space prohibited after that '~' (ctx:WxW) + mask &= ~ (1 << (6 + ATA_SHIFT_UDMA)); ERROR: spaces required around that '?' (ctx:VxW) +

[PATCH] pata_pdc2027x: Remove unnecessary error check and coding style error.

Here, The function pdc_hardware_init always return zero. So it is not necessary to check its return value. Fix these checkpatch.pl error: ERROR: space prohibited after that '~' (ctx:WxW) + mask &= ~ (1 << (6 + ATA_SHIFT_UDMA)); ERROR: spaces required around that '?' (ctx:VxW) +

Re: [crash] PANIC: double fault, error_code: 0x0

On 11/24/2017 08:09 PM, Dave Hansen wrote: > Doesn't this stack trace mean we started C-code page fault handing on > the sysenter stack? Seems like we missed a switch to the process stack. ... and probably a KAISER switch to the kernel CR3.

Re: [crash] PANIC: double fault, error_code: 0x0

On 11/24/2017 08:09 PM, Dave Hansen wrote: > Doesn't this stack trace mean we started C-code page fault handing on > the sysenter stack? Seems like we missed a switch to the process stack. ... and probably a KAISER switch to the kernel CR3.

Re: [crash] PANIC: double fault, error_code: 0x0

On 11/24/2017 12:22 PM, Ingo Molnar wrote: > [8.831002] RIP: 0010:page_fault+0x11/0x60 > [8.831002] RSP: :ff0e7fc8 EFLAGS: 00010046 > [8.831002] RAX: 819d4d77 RBX: 0001 RCX: > 819d4d77 > [8.831002] RDX: 0003 RSI: 0010

Re: [crash] PANIC: double fault, error_code: 0x0

On 11/24/2017 12:22 PM, Ingo Molnar wrote: > [8.831002] RIP: 0010:page_fault+0x11/0x60 > [8.831002] RSP: :ff0e7fc8 EFLAGS: 00010046 > [8.831002] RAX: 819d4d77 RBX: 0001 RCX: > 819d4d77 > [8.831002] RDX: 0003 RSI: 0010

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Fri, Nov 24, 2017 at 08:51:02AM -0800, Andi Kleen wrote: > > I think e2fsck can fix this quite easily, and there really isn't > > an easy way to revert to the old method if the large xattr feature > > is enabled. If you are willing to run a new kernel, you should also > > be willing to run a

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Fri, Nov 24, 2017 at 08:51:02AM -0800, Andi Kleen wrote: > > I think e2fsck can fix this quite easily, and there really isn't > > an easy way to revert to the old method if the large xattr feature > > is enabled. If you are willing to run a new kernel, you should also > > be willing to run a

[f2fs-dev] [PATCH] f2fs: remove an excess variable

Remove the variable page_idx which no one would miss. Signed-off-by: Fan li --- fs/f2fs/data.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index b0781ed..1a9 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c

[f2fs-dev] [PATCH] f2fs: remove an excess variable

Remove the variable page_idx which no one would miss. Signed-off-by: Fan li --- fs/f2fs/data.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index b0781ed..1a9 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -1198,7 +1198,6 @@

[PATCH v2 2/2] x86: disable IRQs before changing CR4

CR4 changes need to be performed while IRQs are disabled in order to update the CR4 shadow and the actual register atomically. Actually, they are needed regardless of CR4 shadowing, since CR4 are performed in a read-modify-write manner. Currently, however, this is not the case, as can be

[PATCH v2 2/2] x86: disable IRQs before changing CR4

CR4 changes need to be performed while IRQs are disabled in order to update the CR4 shadow and the actual register atomically. Actually, they are needed regardless of CR4 shadowing, since CR4 are performed in a read-modify-write manner. Currently, however, this is not the case, as can be

[PATCH v2 0/2] x86: disable IRQs during CR4 changes

CR4 needs to be updated atomically with its shadow value, as CR4 updates are performed in read-modify-write fashion which are based on the shadow value. If CR4 is changed between the read and the write, CR4 might not be updated correctly. For this to happen, CR4 needs to be rewritten by an

[PATCH v2 0/2] x86: disable IRQs during CR4 changes

CR4 needs to be updated atomically with its shadow value, as CR4 updates are performed in read-modify-write fashion which are based on the shadow value. If CR4 is changed between the read and the write, CR4 might not be updated correctly. For this to happen, CR4 needs to be rewritten by an

[PATCH v2 1/2] x86: refactor CR4 setting and shadow write

Refactor the write to CR4 and its shadow value. This is done in preparation for the addition of an assertion to check that IRQs are disabled during CR4 update. No functional change. Cc: Andy Lutomirski Cc: Thomas Gleixner Cc: Ingo Molnar

[PATCH v2 1/2] x86: refactor CR4 setting and shadow write

Refactor the write to CR4 and its shadow value. This is done in preparation for the addition of an assertion to check that IRQs are disabled during CR4 update. No functional change. Cc: Andy Lutomirski Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org

Re: [PATCH v2] KVM: X86: Fix softlockup when get the current kvmclock timestamp

Hi, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on kvm/linux-next] [also build test WARNING on v4.14 next-20171124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2] KVM: X86: Fix softlockup when get the current kvmclock timestamp

Hi, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on kvm/linux-next] [also build test WARNING on v4.14 next-20171124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH 0/5] Consolidate init_task handling

On Fri, Nov 24, 2017 at 5:31 AM, David Howells wrote: > > It doesn't seem useful to have the init_task in a header file rather than > in a normal source file. We could consolidate init_task handling instead. > Do want to do this? If so, this is probably something we'd want

Re: [PATCH 0/5] Consolidate init_task handling

On Fri, Nov 24, 2017 at 5:31 AM, David Howells wrote: > > It doesn't seem useful to have the init_task in a header file rather than > in a normal source file. We could consolidate init_task handling instead. > Do want to do this? If so, this is probably something we'd want to do at > the end of

Re: [x86/mm/kaiser] a6c70b8b30: WARNING:at_kernel/locking/lockdep.c:#trace_hardirqs_off_caller

On Fri, Nov 24, 2017 at 03:02:33PM +0100, Ingo Molnar wrote: * kernel test robot wrote: FYI, we noticed the following commit (built with gcc-6): commit: a6c70b8b30bf35045d14e352bfd1eb16aaee906f ("x86/mm/kaiser: Prepare assembly for entry/exit CR3 switching")

Re: [x86/mm/kaiser] a6c70b8b30: WARNING:at_kernel/locking/lockdep.c:#trace_hardirqs_off_caller

On Fri, Nov 24, 2017 at 03:02:33PM +0100, Ingo Molnar wrote: * kernel test robot wrote: FYI, we noticed the following commit (built with gcc-6): commit: a6c70b8b30bf35045d14e352bfd1eb16aaee906f ("x86/mm/kaiser: Prepare assembly for entry/exit CR3 switching")

[PATCH v2] x86/mce: add support SRAO reported via CMC check

In Intel SDM Volume 3B (253669-063US, July 2017), SRAO could be reported either via MCE or CMC: In cases when SRAO is signaled via CMCI the error signature is indicated via UC=1, PCC=0, S=0. Type(*1) UC EN PCC S AR Signaling

[PATCH v2] x86/mce: add support SRAO reported via CMC check

In Intel SDM Volume 3B (253669-063US, July 2017), SRAO could be reported either via MCE or CMC: In cases when SRAO is signaled via CMCI the error signature is indicated via UC=1, PCC=0, S=0. Type(*1) UC EN PCC S AR Signaling

Re: [PATCH] mm,madvise: bugfix of madvise systemcall infinite loop under special circumstances.

Yes , your modification is much better! thanks. 在 2017/11/24 21:08, Michal Hocko 写道: On Fri 24-11-17 20:51:29, 郭雪楠 wrote: Sorry,I explained wrong before. But,I've tested using trinity in DAX mode,and I'am sure it has possibility of triggering an soft lockup. I have encountered the problem of

Re: [PATCH] mm,madvise: bugfix of madvise systemcall infinite loop under special circumstances.

Yes , your modification is much better! thanks. 在 2017/11/24 21:08, Michal Hocko 写道: On Fri 24-11-17 20:51:29, 郭雪楠 wrote: Sorry,I explained wrong before. But,I've tested using trinity in DAX mode,and I'am sure it has possibility of triggering an soft lockup. I have encountered the problem of

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

> Sure, but not many people are going to be running a 4.14 kernel with > a 2007 system. It's not just root, but any disk. People could well have 10 year old disks. > Could you please run the updated find command to see > whether this is an isolated case, or if it is a common case: > > find /

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

> Sure, but not many people are going to be running a 4.14 kernel with > a 2007 system. It's not just root, but any disk. People could well have 10 year old disks. > Could you please run the updated find command to see > whether this is an isolated case, or if it is a common case: > > find /

[PATCH v2] staging: rtl8188eu: Fix private WEXT IOCTL calls

From: Ishraq Ibne Ashraf Commit 8bfb36766064 ("wireless: wext: remove ndo_do_ioctl fallback") breaks private WEXT IOCTL calls of this driver as these are not invoked through ndo_do_ioctl interface anymore. As a result hostapd stops working with this driver. In this

[PATCH v2] staging: rtl8188eu: Fix private WEXT IOCTL calls

From: Ishraq Ibne Ashraf Commit 8bfb36766064 ("wireless: wext: remove ndo_do_ioctl fallback") breaks private WEXT IOCTL calls of this driver as these are not invoked through ndo_do_ioctl interface anymore. As a result hostapd stops working with this driver. In this patch this problem is solved

Re: [PATCH 20/23] x86, kaiser: add a function to check for KAISER being enabled

On Wed, Nov 22, 2017 at 04:35:18PM -0800, Dave Hansen wrote: > > From: Dave Hansen > > Currently, all of the checks for KAISER are compile-time checks. > > Runtime checks are needed for turning it on/off at runtime. > > Add a function to do that. > >

Re: [PATCH 20/23] x86, kaiser: add a function to check for KAISER being enabled

On Wed, Nov 22, 2017 at 04:35:18PM -0800, Dave Hansen wrote: > > From: Dave Hansen > > Currently, all of the checks for KAISER are compile-time checks. > > Runtime checks are needed for turning it on/off at runtime. > > Add a function to do that. > > Signed-off-by: Dave Hansen > Cc: Moritz

Re: [PATCH 21/23] x86, kaiser: un-poison PGDs at runtime

On Wed, Nov 22, 2017 at 04:35:21PM -0800, Dave Hansen wrote: > > From: Dave Hansen > > With KAISER Kernel PGDs that map userspace are "poisoned" with > the NX bit. This ensures that if a kernel->user CR3 switch is > missed, userspace crashes instead of running in

Re: [PATCH 21/23] x86, kaiser: un-poison PGDs at runtime

On Wed, Nov 22, 2017 at 04:35:21PM -0800, Dave Hansen wrote: > > From: Dave Hansen > > With KAISER Kernel PGDs that map userspace are "poisoned" with > the NX bit. This ensures that if a kernel->user CR3 switch is > missed, userspace crashes instead of running in an unhardened > state. > >

Re: [PATCH v2 2/2] ASoC: fsl_ssi: add 20-bit sample format for AC'97 and use it for capture

Hi Maciej, Thank you for the patch! Yet something to improve: [auto build test ERROR on sound/for-next] [also build test ERROR on v4.14 next-20171124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2 2/2] ASoC: fsl_ssi: add 20-bit sample format for AC'97 and use it for capture

Hi Maciej, Thank you for the patch! Yet something to improve: [auto build test ERROR on sound/for-next] [also build test ERROR on v4.14 next-20171124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2 2/2] ASoC: fsl_ssi: add 20-bit sample format for AC'97 and use it for capture

Hi Maciej, Thank you for the patch! Yet something to improve: [auto build test ERROR on sound/for-next] [also build test ERROR on v4.14 next-20171124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2 2/2] ASoC: fsl_ssi: add 20-bit sample format for AC'97 and use it for capture

Hi Maciej, Thank you for the patch! Yet something to improve: [auto build test ERROR on sound/for-next] [also build test ERROR on v4.14 next-20171124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2 13/13] nubus: Add support for the driver model

On Fri, 24 Nov 2017, Greg Kroah-Hartman wrote: > > > > > > But what happens when the bus code is unloaded if it is built as a > > > module? The devices will be removed then. Or they should be. > > > > > > > This bus driver is not a module. > > It can not be built as a module ever? >

Re: [PATCH v2 13/13] nubus: Add support for the driver model

On Fri, 24 Nov 2017, Greg Kroah-Hartman wrote: > > > > > > But what happens when the bus code is unloaded if it is built as a > > > module? The devices will be removed then. Or they should be. > > > > > > > This bus driver is not a module. > > It can not be built as a module ever? >

[PATCH 2/2] staging: rtl8188eu: Fix private WEXT IOCTL calls

From: Ishraq Ibne Ashraf Apply changes suggested by Dan Carpenter --- drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 1052 1 file changed, 536 insertions(+), 516 deletions(-) diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c

[PATCH 2/2] staging: rtl8188eu: Fix private WEXT IOCTL calls

From: Ishraq Ibne Ashraf Apply changes suggested by Dan Carpenter --- drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 1052 1 file changed, 536 insertions(+), 516 deletions(-) diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c

Re: [PATCH 22/43] x86/mm/kaiser: Prepare assembly for entry/exit CR3 switching

On Fri, 24 Nov 2017, Ingo Molnar wrote: > @@ -1288,6 +1308,8 @@ ENTRY(error_entry) >* from user mode due to an IRET fault. >*/ > SWAPGS > + /* We have user CR3. Change to kernel CR3. */ > + SWITCH_TO_KERNEL_CR3 scratch_reg=%rax > >

Re: [PATCH 22/43] x86/mm/kaiser: Prepare assembly for entry/exit CR3 switching

On Fri, 24 Nov 2017, Ingo Molnar wrote: > @@ -1288,6 +1308,8 @@ ENTRY(error_entry) >* from user mode due to an IRET fault. >*/ > SWAPGS > + /* We have user CR3. Change to kernel CR3. */ > + SWITCH_TO_KERNEL_CR3 scratch_reg=%rax > >

Re: [PATCH] This patch is used ... [trimmed overly long subject]

Tim, Your patch looks good, but your patch description needs some care: Please do not write full sentences in the subject line. The subject line should be a short and precise information about the patch. The format is: [PATCH] subsystem: Short precise description. in this case:

Re: [PATCH] This patch is used ... [trimmed overly long subject]

Tim, Your patch looks good, but your patch description needs some care: Please do not write full sentences in the subject line. The subject line should be a short and precise information about the patch. The format is: [PATCH] subsystem: Short precise description. in this case:

Re: [PATCH] x86/xen: support early interrupts in xen pv guests

On Fri, 24 Nov 2017, Andy Lutomirski wrote: > On Fri, Nov 24, 2017 at 12:52 AM, Juergen Gross wrote: > > Sorry, Andy, forgot to Cc: you... > > > > On 24/11/17 09:42, Juergen Gross wrote: > >> Add early interrupt handlers activated by idt_setup_early_handler() to > >> the

Re: [PATCH] x86/xen: support early interrupts in xen pv guests

On Fri, 24 Nov 2017, Andy Lutomirski wrote: > On Fri, Nov 24, 2017 at 12:52 AM, Juergen Gross wrote: > > Sorry, Andy, forgot to Cc: you... > > > > On 24/11/17 09:42, Juergen Gross wrote: > >> Add early interrupt handlers activated by idt_setup_early_handler() to > >> the handlers supported by

Re: [crash] PANIC: double fault, error_code: 0x0

* Andy Lutomirski wrote: > > Note that if *any* of those 4 padding sequences is removed, the kernel > > starts > > crashing again. Also note that the exact size of the padding appears to be > > not > > material - it could be larger as well, i.e. it's not an alignment

Re: [crash] PANIC: double fault, error_code: 0x0

* Andy Lutomirski wrote: > > Note that if *any* of those 4 padding sequences is removed, the kernel > > starts > > crashing again. Also note that the exact size of the padding appears to be > > not > > material - it could be larger as well, i.e. it's not an alignment bug I > > think. > >

Re: [crash] PANIC: double fault, error_code: 0x0

> On Nov 24, 2017, at 3:09 PM, Ingo Molnar wrote: > > > * Ingo Molnar wrote: > >> >> * Ingo Molnar wrote: >> >>> This is a repost of the latest entry-stack plus Kaiser bits from Andy >>> Lutomirski >>> (v3 series from today) and Dave

Re: [crash] PANIC: double fault, error_code: 0x0

> On Nov 24, 2017, at 3:09 PM, Ingo Molnar wrote: > > > * Ingo Molnar wrote: > >> >> * Ingo Molnar wrote: >> >>> This is a repost of the latest entry-stack plus Kaiser bits from Andy >>> Lutomirski >>> (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123 version), >>> on

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Fri, 2017-11-24 at 15:03 -0700, Andreas Dilger wrote: > On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote: > > > > > > > > > > We checked old kernels, and old e2fsprogs, and didn't see any > > > cases > > > where fast (<= 60 chars) symlinks were created using external > > >

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Fri, 2017-11-24 at 15:03 -0700, Andreas Dilger wrote: > On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote: > > > > > > > > > > We checked old kernels, and old e2fsprogs, and didn't see any > > > cases > > > where fast (<= 60 chars) symlinks were created using external > > > blocks. > > > It

Re: [crash] PANIC: double fault, error_code: 0x0

* Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > This is a repost of the latest entry-stack plus Kaiser bits from Andy > > Lutomirski > > (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123 version), > > on top of latest tip:x86/urgent

Re: [crash] PANIC: double fault, error_code: 0x0

* Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > This is a repost of the latest entry-stack plus Kaiser bits from Andy > > Lutomirski > > (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123 version), > > on top of latest tip:x86/urgent (12a78d43de76). > > > > This version

Re: XArray documentation

On Fri, Nov 24, 2017 at 11:02:41PM +0100, Martin Steigerwald wrote: > I like this. > > I bet I may not be able help much further with it other than to possibly > proofread it tomorrow. > > Thank you for considering my suggestion. Not at all; your feedback has significantly improved this

Re: XArray documentation

On Fri, Nov 24, 2017 at 11:02:41PM +0100, Martin Steigerwald wrote: > I like this. > > I bet I may not be able help much further with it other than to possibly > proofread it tomorrow. > > Thank you for considering my suggestion. Not at all; your feedback has significantly improved this

[PATCH] [media] v4l: mt9v032: Disable clock on error paths

mt9v032_power_on() leaves clk enabled in case of errors, but it is not expected by its callers. There is a similar problem in mt9v032_registered(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov ---

[PATCH] [media] v4l: mt9v032: Disable clock on error paths

mt9v032_power_on() leaves clk enabled in case of errors, but it is not expected by its callers. There is a similar problem in mt9v032_registered(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/media/i2c/mt9v032.c | 21

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote: > >> We checked old kernels, and old e2fsprogs, and didn't see any cases >> where fast (<= 60 chars) symlinks were created using external blocks. >> It seems that _something_ did create them, and it would be good to >> figure

Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote: > >> We checked old kernels, and old e2fsprogs, and didn't see any cases >> where fast (<= 60 chars) symlinks were created using external blocks. >> It seems that _something_ did create them, and it would be good to >> figure that out so we can

Re: XArray documentation

Matthew Wilcox - 24.11.17, 22:18: > On Fri, Nov 24, 2017 at 07:01:31PM +0100, Martin Steigerwald wrote: > > > The XArray is an abstract data type which behaves like an infinitely > > > large array of pointers. The index into the array is an unsigned long. > > > A freshly-initialised XArray

Re: XArray documentation

Matthew Wilcox - 24.11.17, 22:18: > On Fri, Nov 24, 2017 at 07:01:31PM +0100, Martin Steigerwald wrote: > > > The XArray is an abstract data type which behaves like an infinitely > > > large array of pointers. The index into the array is an unsigned long. > > > A freshly-initialised XArray

  1   2   3   4   5   6   7   8   9   10   >