Re: [PATCH] lkdtm: Convert from jprobe to kprobe

On Fri, 20 Oct 2017 06:31:27 -0700 Kees Cook wrote: > The jprobe subsystem is being removed, so convert to using kprobe instead. > Looks good to me:) Acked-by: Masami Hiramatsu Thanks, > Cc: Masami Hiramatsu > Signed-off-by:

Re: [PATCH] lkdtm: Convert from jprobe to kprobe

On Fri, 20 Oct 2017 06:31:27 -0700 Kees Cook wrote: > The jprobe subsystem is being removed, so convert to using kprobe instead. > Looks good to me:) Acked-by: Masami Hiramatsu Thanks, > Cc: Masami Hiramatsu > Signed-off-by: Kees Cook > --- > drivers/misc/lkdtm_core.c | 154 >

Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

On Thu, 2017-10-19 at 12:58 -0400, Jerome Glisse wrote: > On Thu, Oct 19, 2017 at 09:53:11PM +1100, Balbir Singh wrote: > > On Thu, Oct 19, 2017 at 2:28 PM, Jerome Glisse wrote: > > > On Thu, Oct 19, 2017 at 02:04:26PM +1100, Balbir Singh wrote: > > > > On Mon, 16 Oct 2017

Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

On Thu, 2017-10-19 at 12:58 -0400, Jerome Glisse wrote: > On Thu, Oct 19, 2017 at 09:53:11PM +1100, Balbir Singh wrote: > > On Thu, Oct 19, 2017 at 2:28 PM, Jerome Glisse wrote: > > > On Thu, Oct 19, 2017 at 02:04:26PM +1100, Balbir Singh wrote: > > > > On Mon, 16 Oct 2017 23:10:02 -0400 > > > >

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

On Fri, Oct 20, 2017 at 09:48:16PM +0100, David Howells wrote: > Alan Cox wrote: > > > There are a load of standard tools that use this so I think you are going > > to need a whitelist. Can you at least log *which* MSR in the failing case > > so a whitelist can be

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

On Fri, Oct 20, 2017 at 09:48:16PM +0100, David Howells wrote: > Alan Cox wrote: > > > There are a load of standard tools that use this so I think you are going > > to need a whitelist. Can you at least log *which* MSR in the failing case > > so a whitelist can be built over time ? > [...snip]

Re: [PATCH v3 02/13] dax: require 'struct page' for filesystem dax

On Fri, Oct 20, 2017 at 8:20 PM, Matthew Wilcox wrote: > On Fri, Oct 20, 2017 at 03:29:57PM -0700, Dan Williams wrote: >> Ok, I'd also like to kill DAX support in the brd driver. It's a source >> of complexity and maintenance burden for zero benefit. It's the only >>

Re: [PATCH v3 02/13] dax: require 'struct page' for filesystem dax

On Fri, Oct 20, 2017 at 8:20 PM, Matthew Wilcox wrote: > On Fri, Oct 20, 2017 at 03:29:57PM -0700, Dan Williams wrote: >> Ok, I'd also like to kill DAX support in the brd driver. It's a source >> of complexity and maintenance burden for zero benefit. It's the only >> ->direct_access()

[PATCH] net: can: dev: remove unused code in can_restart

Value assigned to variable err is overwritten at line 562: err = priv->do_set_mode(dev, CAN_MODE_START); before it can be used. Also, notice that this code has been there since 2014. Addresses-Coverity-ID: 1227031 Signed-off-by: Gustavo A. R. Silva --- This code was

[PATCH] net: can: dev: remove unused code in can_restart

Value assigned to variable err is overwritten at line 562: err = priv->do_set_mode(dev, CAN_MODE_START); before it can be used. Also, notice that this code has been there since 2014. Addresses-Coverity-ID: 1227031 Signed-off-by: Gustavo A. R. Silva --- This code was tested by compilation only.

Re: [PATCH v3 02/13] dax: require 'struct page' for filesystem dax

On Fri, Oct 20, 2017 at 03:29:57PM -0700, Dan Williams wrote: > Ok, I'd also like to kill DAX support in the brd driver. It's a source > of complexity and maintenance burden for zero benefit. It's the only > ->direct_access() implementation that sleeps and it's the only > implementation where

Re: [PATCH v3 02/13] dax: require 'struct page' for filesystem dax

On Fri, Oct 20, 2017 at 03:29:57PM -0700, Dan Williams wrote: > Ok, I'd also like to kill DAX support in the brd driver. It's a source > of complexity and maintenance burden for zero benefit. It's the only > ->direct_access() implementation that sleeps and it's the only > implementation where

Re: [PATCH mmotm] lib/bug.c: fix build when MODULES are not enabled

On Fri, Oct 20, 2017 at 04:53:50PM -0700, Randy Dunlap wrote: > From: Randy Dunlap > > Fix build when CONFIG_MODULES is not enabled. > Fixes multiple build errors. Thanks. I already sent a patch earlier. -Andi > > Signed-off-by: Randy Dunlap >

Re: [PATCH mmotm] lib/bug.c: fix build when MODULES are not enabled

On Fri, Oct 20, 2017 at 04:53:50PM -0700, Randy Dunlap wrote: > From: Randy Dunlap > > Fix build when CONFIG_MODULES is not enabled. > Fixes multiple build errors. Thanks. I already sent a patch earlier. -Andi > > Signed-off-by: Randy Dunlap > Reported-by: kbuild test robot > Cc: Andi Kleen

Re: [PATCH 00/23] Hardened usercopy whitelisting

On Fri, Oct 20, 2017 at 4:25 PM, Paolo Bonzini wrote: > On 21/10/2017 00:40, Paolo Bonzini wrote: >> This breaks KVM completely on x86, due to two ioctls >> (KVM_GET/SET_CPUID2) accessing the cpuid_entries field of struct >> kvm_vcpu_arch. >> >> There's also another broken

Re: [PATCH 00/23] Hardened usercopy whitelisting

On Fri, Oct 20, 2017 at 4:25 PM, Paolo Bonzini wrote: > On 21/10/2017 00:40, Paolo Bonzini wrote: >> This breaks KVM completely on x86, due to two ioctls >> (KVM_GET/SET_CPUID2) accessing the cpuid_entries field of struct >> kvm_vcpu_arch. >> >> There's also another broken ioctl,

[PATCH v7] acpi: apei: remove the unused dead-code for SEA/NMI notification type

For the SEA notification, the two functions ghes_sea_add() and ghes_sea_remove() are only called when CONFIG_ACPI_APEI_SEA is defined. If not, it will return errors in the ghes_probe() and not continue. If the probe is failed, the ghes_sea_remove() also has no chance to be called. Hence, remove

[PATCH v7] acpi: apei: remove the unused dead-code for SEA/NMI notification type

For the SEA notification, the two functions ghes_sea_add() and ghes_sea_remove() are only called when CONFIG_ACPI_APEI_SEA is defined. If not, it will return errors in the ghes_probe() and not continue. If the probe is failed, the ghes_sea_remove() also has no chance to be called. Hence, remove

Re: [PATCH 2/3] watchdog: hpwdt: SMBIOS check

On 10/20/2017 03:54 PM, Jerry Hoemann wrote: Correct test on SMBIOS table 219 Misc Features bits for UEFI supported. Please explain in more detail. There is no table 219 in the SMBIOS specification. There is table 9, BIOS Characteristics Extension Byte 2, which specifies bit 3 as "UEFI

Re: [PATCH 2/3] watchdog: hpwdt: SMBIOS check

On 10/20/2017 03:54 PM, Jerry Hoemann wrote: Correct test on SMBIOS table 219 Misc Features bits for UEFI supported. Please explain in more detail. There is no table 219 in the SMBIOS specification. There is table 9, BIOS Characteristics Extension Byte 2, which specifies bit 3 as "UEFI

Re: [PATCH 1/3] watchdog: hpwdt: add ioctl WDIOC_GETPRETIMEOUT

On 10/20/2017 03:54 PM, Jerry Hoemann wrote: Add support for WDIOC_GETPRETIMEOUT ioctl so that user applications can determine when the NMI should arrive. Signed-off-by: Jerry Hoemann --- drivers/watchdog/hpwdt.c | 7 +++ 1 file changed, 7 insertions(+) diff

Re: [PATCH 1/3] watchdog: hpwdt: add ioctl WDIOC_GETPRETIMEOUT

On 10/20/2017 03:54 PM, Jerry Hoemann wrote: Add support for WDIOC_GETPRETIMEOUT ioctl so that user applications can determine when the NMI should arrive. Signed-off-by: Jerry Hoemann --- drivers/watchdog/hpwdt.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

Re: [RESEND PATCH 1/3] completion: Add support for initializing completion with lockdep_map

On Sat, Oct 21, 2017 at 4:58 AM, Bart Van Assche wrote: > Sorry but I'm not sure that's the best possible answer. In my opinion > avoiding that completion objects have dependencies on other lock objects, > e.g. by avoiding to wait on a completion object while holding a

Re: [RESEND PATCH 1/3] completion: Add support for initializing completion with lockdep_map

On Sat, Oct 21, 2017 at 4:58 AM, Bart Van Assche wrote: > Sorry but I'm not sure that's the best possible answer. In my opinion > avoiding that completion objects have dependencies on other lock objects, > e.g. by avoiding to wait on a completion object while holding a mutex, is a > far superior

Re: [PATCH] [v2] tomoyo: fix timestamping for y2038

On Thu, 19 Oct 2017, Arnd Bergmann wrote: > Tomoyo uses an open-coded version of time_to_tm() to create a timestamp > from the current time as read by get_seconds(). This will overflow and > give wrong results on 32-bit systems in 2038. > > To correct this, this changes the code to use

Re: [PATCH] [v2] tomoyo: fix timestamping for y2038

On Thu, 19 Oct 2017, Arnd Bergmann wrote: > Tomoyo uses an open-coded version of time_to_tm() to create a timestamp > from the current time as read by get_seconds(). This will overflow and > give wrong results on 32-bit systems in 2038. > > To correct this, this changes the code to use

Re: [PATCH 26/27] efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode

On Thu, 19 Oct 2017, David Howells wrote: > + if (efi_enabled(EFI_BOOT)) { > + switch (mode) { > + case efi_secureboot_mode_disabled: > + pr_info("Secure boot disabled\n"); > + break; > + case

Re: [PATCH 26/27] efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode

On Thu, 19 Oct 2017, David Howells wrote: > + if (efi_enabled(EFI_BOOT)) { > + switch (mode) { > + case efi_secureboot_mode_disabled: > + pr_info("Secure boot disabled\n"); > + break; > + case

Re: [PATCH 25/27] Lock down /proc/kcore

On Thu, 19 Oct 2017, David Howells wrote: > Disallow access to /proc/kcore when the kernel is locked down to prevent > access to cryptographic data. > > Signed-off-by: David Howells Reviewed-by: James Morris I have to wonder, though, after

Re: [PATCH 25/27] Lock down /proc/kcore

On Thu, 19 Oct 2017, David Howells wrote: > Disallow access to /proc/kcore when the kernel is locked down to prevent > access to cryptographic data. > > Signed-off-by: David Howells Reviewed-by: James Morris I have to wonder, though, after everything is locked down, how easy will it be for

[PATCH v6] acpi: apei: remove the unused dead-code for SEA/NMI notification type

For the SEA notification, the two functions ghes_sea_add() and ghes_sea_remove() are only called when CONFIG_ACPI_APEI_SEA is defined. If not, it will return errors in the ghes_probe() and not continue. If the probe is failed, the ghes_sea_remove() also has no chance to be called. Hence, remove

[PATCH v6] acpi: apei: remove the unused dead-code for SEA/NMI notification type

For the SEA notification, the two functions ghes_sea_add() and ghes_sea_remove() are only called when CONFIG_ACPI_APEI_SEA is defined. If not, it will return errors in the ghes_probe() and not continue. If the probe is failed, the ghes_sea_remove() also has no chance to be called. Hence, remove

Re: [PATCH 1/4] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS

On Fri, Oct 20, 2017 at 12:59 PM, Kirill A. Shutemov wrote: > With boot-time switching between paging mode we will have variable > MAX_PHYSMEM_BITS. > > Let's use the maximum variable possible for CONFIG_X86_5LEVEL=y > configuration to define zsmalloc data

Re: [PATCH 1/4] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS

On Fri, Oct 20, 2017 at 12:59 PM, Kirill A. Shutemov wrote: > With boot-time switching between paging mode we will have variable > MAX_PHYSMEM_BITS. > > Let's use the maximum variable possible for CONFIG_X86_5LEVEL=y > configuration to define zsmalloc data structures. > > The patch introduces

Re: [PATCH net] hv_sock: add locking in the open/close/release code paths

From: Dexuan Cui Date: Thu, 19 Oct 2017 03:33:14 + > > Without the patch, when hvs_open_connection() hasn't completely established > a connection (e.g. it has changed sk->sk_state to SS_CONNECTED, but hasn't > inserted the sock into the connected queue),

Re: [PATCH net] hv_sock: add locking in the open/close/release code paths

From: Dexuan Cui Date: Thu, 19 Oct 2017 03:33:14 + > > Without the patch, when hvs_open_connection() hasn't completely established > a connection (e.g. it has changed sk->sk_state to SS_CONNECTED, but hasn't > inserted the sock into the connected queue), vsock_stream_connect() may see > the

[PATCH v1] mm: broken deferred calculation

In reset_deferred_meminit we determine number of pages that must not be deferred. We initialize pages for at least 2G of memory, but also pages for reserved memory in this node. The reserved memory is determined in this function: memblock_reserved_memory_within(), which operates over physical

[PATCH v1] mm: broken deferred calculation

In reset_deferred_meminit we determine number of pages that must not be deferred. We initialize pages for at least 2G of memory, but also pages for reserved memory in this node. The reserved memory is determined in this function: memblock_reserved_memory_within(), which operates over physical

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On Friday, October 20, 2017 10:46:07 PM CEST Bjorn Helgaas wrote: > On Mon, Oct 16, 2017 at 03:12:35AM +0200, Rafael J. Wysocki wrote: > > Hi All, > > > > Well, this took more time than expected, as I tried to cover everything I > > had > > in mind regarding PM flags for drivers. > > For the

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

On Friday, October 20, 2017 10:46:07 PM CEST Bjorn Helgaas wrote: > On Mon, Oct 16, 2017 at 03:12:35AM +0200, Rafael J. Wysocki wrote: > > Hi All, > > > > Well, this took more time than expected, as I tried to cover everything I > > had > > in mind regarding PM flags for drivers. > > For the

Re: swap_info_get: Bad swap offset entry 0200f8a7

On Fri, 20 Oct 2017, huang ying wrote: > > 4 May < Linux version 4.11.2-1-ARCH > > 4 Jun < Linux version 4.11.3-1-ARCH > > 7 Jul < Linux version 4.11.9-1-ARCH > > 4 Aug < Linux version 4.12.8-2-ARCH > > 24 Sep < Linux version 4.12.13-1-ARCH > > 158 Oct <

Re: swap_info_get: Bad swap offset entry 0200f8a7

On Fri, 20 Oct 2017, huang ying wrote: > > 4 May < Linux version 4.11.2-1-ARCH > > 4 Jun < Linux version 4.11.3-1-ARCH > > 7 Jul < Linux version 4.11.9-1-ARCH > > 4 Aug < Linux version 4.12.8-2-ARCH > > 24 Sep < Linux version 4.12.13-1-ARCH > > 158 Oct <

[PATCH v2 2/4] android: binder: Fix null ptr dereference in debug msg

Don't access next->data in kernel debug message when the next buffer is null. Acked-by: Arve Hjønnevåg Signed-off-by: Sherry Yang --- drivers/android/binder_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 2/4] android: binder: Fix null ptr dereference in debug msg

Don't access next->data in kernel debug message when the next buffer is null. Acked-by: Arve Hjønnevåg Signed-off-by: Sherry Yang --- drivers/android/binder_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/android/binder_alloc.c

[PATCH v2 3/4] android: binder: Remove unused vma argument

The vma argument in update_page_range is no longer used after 74310e06 ("android: binder: Move buffer out of area shared with user space"), since mmap_handler no longer calls update_page_range with a vma. Acked-by: Arve Hjønnevåg Signed-off-by: Sherry Yang

[PATCH v2 3/4] android: binder: Remove unused vma argument

The vma argument in update_page_range is no longer used after 74310e06 ("android: binder: Move buffer out of area shared with user space"), since mmap_handler no longer calls update_page_range with a vma. Acked-by: Arve Hjønnevåg Signed-off-by: Sherry Yang --- drivers/android/binder_alloc.c |

[PATCH v2 1/4] android: binder: Don't get mm from task

Use binder_alloc struct's mm_struct rather than getting a reference to the mm struct through get_task_mm to avoid a potential deadlock between lru lock, task lock and dentry lock, since a thread can be holding the task lock and the dentry lock while trying to acquire the lru lock. Acked-by: Arve

[PATCH v2 4/4] android: binder: Change binder_shrinker to static

binder_shrinker struct is not used anywhere outside of binder_alloc.c and should be static. Acked-by: Arve Hjønnevåg Signed-off-by: Sherry Yang --- drivers/android/binder_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 1/4] android: binder: Don't get mm from task

Use binder_alloc struct's mm_struct rather than getting a reference to the mm struct through get_task_mm to avoid a potential deadlock between lru lock, task lock and dentry lock, since a thread can be holding the task lock and the dentry lock while trying to acquire the lru lock. Acked-by: Arve

[PATCH v2 4/4] android: binder: Change binder_shrinker to static

binder_shrinker struct is not used anywhere outside of binder_alloc.c and should be static. Acked-by: Arve Hjønnevåg Signed-off-by: Sherry Yang --- drivers/android/binder_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/android/binder_alloc.c

[PATCH v2 0/4] android: binder: fixes for memory allocator change

This patchset resolves a potential deadlock between lru lock, task lock and dentry lock reported by lockdep. It also fixes the null pointer dereference in kernel debug message in binder_alloc.c. Unused vma argument is removed, and binder shrinker is made static. android: binder: Don't get mm

[PATCH v2 0/4] android: binder: fixes for memory allocator change

This patchset resolves a potential deadlock between lru lock, task lock and dentry lock reported by lockdep. It also fixes the null pointer dereference in kernel debug message in binder_alloc.c. Unused vma argument is removed, and binder shrinker is made static. android: binder: Don't get mm

Re: [PATCH net 5/5] net/ncsi: Fix length of GVI response packet

From: Samuel Mendoza-Jonas Date: Thu, 19 Oct 2017 13:43:09 +1100 > From: Gavin Shan > > The length of GVI (GetVersionInfo) response packet should be 40 instead > of 36. This issue was found from /sys/kernel/debug/ncsi/eth0/stats. > > #

Re: [PATCH net 2/5] net/ncsi: Stop monitor if channel times out or is inactive

From: Samuel Mendoza-Jonas Date: Thu, 19 Oct 2017 13:43:06 +1100 > ncsi_channel_monitor() misses stopping the channel monitor in several > places that it should, causing a WARN_ON_ONCE() to trigger when the > monitor is re-started later, eg: > > [ 459.04] WARNING:

Re: [PATCH net 3/5] net/ncsi: Disable HWA mode when no channels are found

From: Samuel Mendoza-Jonas Date: Thu, 19 Oct 2017 13:43:07 +1100 > From: Gavin Shan > > When there are no NCSI channels probed, HWA (Hardware Arbitration) > mode is enabled. It's not correct because HWA depends on the fact: > NCSI channels

Re: [PATCH net 5/5] net/ncsi: Fix length of GVI response packet

From: Samuel Mendoza-Jonas Date: Thu, 19 Oct 2017 13:43:09 +1100 > From: Gavin Shan > > The length of GVI (GetVersionInfo) response packet should be 40 instead > of 36. This issue was found from /sys/kernel/debug/ncsi/eth0/stats. > > # ethtool --ncsi eth0 swstats > : > RESPONSE OK

Re: [PATCH net 2/5] net/ncsi: Stop monitor if channel times out or is inactive

From: Samuel Mendoza-Jonas Date: Thu, 19 Oct 2017 13:43:06 +1100 > ncsi_channel_monitor() misses stopping the channel monitor in several > places that it should, causing a WARN_ON_ONCE() to trigger when the > monitor is re-started later, eg: > > [ 459.04] WARNING: CPU: 0 PID: 1093 at

Re: [PATCH net 3/5] net/ncsi: Disable HWA mode when no channels are found

From: Samuel Mendoza-Jonas Date: Thu, 19 Oct 2017 13:43:07 +1100 > From: Gavin Shan > > When there are no NCSI channels probed, HWA (Hardware Arbitration) > mode is enabled. It's not correct because HWA depends on the fact: > NCSI channels exist and all of them support HWA mode. This disables

Re: [PATCH net 4/5] net/ncsi: Enforce failover on link monitor timeout

From: Samuel Mendoza-Jonas Date: Thu, 19 Oct 2017 13:43:08 +1100 > From: Gavin Shan > > The NCSI channel has been configured to provide service if its link > monitor timer is enabled, regardless of its state (inactive or active). > So the

Re: [PATCH net 4/5] net/ncsi: Enforce failover on link monitor timeout

From: Samuel Mendoza-Jonas Date: Thu, 19 Oct 2017 13:43:08 +1100 > From: Gavin Shan > > The NCSI channel has been configured to provide service if its link > monitor timer is enabled, regardless of its state (inactive or active). > So the timeout event on the link monitor indicates the

Re: [PATCH net 1/5] net/ncsi: Fix AEN HNCDSC packet length

From: Samuel Mendoza-Jonas Date: Thu, 19 Oct 2017 13:43:05 +1100 > Correct the value of the HNCDSC AEN packet. > Fixes: 7a82ecf4cfb85 "net/ncsi: NCSI AEN packet handler" > > Signed-off-by: Samuel Mendoza-Jonas Applied.

Re: [PATCH net 1/5] net/ncsi: Fix AEN HNCDSC packet length

From: Samuel Mendoza-Jonas Date: Thu, 19 Oct 2017 13:43:05 +1100 > Correct the value of the HNCDSC AEN packet. > Fixes: 7a82ecf4cfb85 "net/ncsi: NCSI AEN packet handler" > > Signed-off-by: Samuel Mendoza-Jonas Applied.

Re: [PATCH 7/7] gpio: brcmstb: implement suspend/resume/shutdown

On Thu, Oct 19, 2017 at 11:39 AM, Doug Berger wrote: >>> +static int brcmstb_gpio_resume(struct device *dev) >>> +{ >>> +struct brcmstb_gpio_priv *priv = dev_get_drvdata(dev); >>> +struct brcmstb_gpio_bank *bank; >>> +u32 wake_mask = 0; >> >> This isn't really being

Re: [PATCH 7/7] gpio: brcmstb: implement suspend/resume/shutdown

On Thu, Oct 19, 2017 at 11:39 AM, Doug Berger wrote: >>> +static int brcmstb_gpio_resume(struct device *dev) >>> +{ >>> +struct brcmstb_gpio_priv *priv = dev_get_drvdata(dev); >>> +struct brcmstb_gpio_bank *bank; >>> +u32 wake_mask = 0; >> >> This isn't really being used as a mask,

Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

On 10/20/2017 01:24 PM, Jon Masters wrote: > 1). The first thing people do when they get an Arm server is to cat > /proc/cpuinfo. They then come complaining that it's not like x86. They > can't get the output their looking for and this results in bug filing, > and countless hours on phone calls

Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

On 10/20/2017 01:24 PM, Jon Masters wrote: > 1). The first thing people do when they get an Arm server is to cat > /proc/cpuinfo. They then come complaining that it's not like x86. They > can't get the output their looking for and this results in bug filing, > and countless hours on phone calls

[PATCH] net: core: rtnetlink: use BUG_ON instead of if condition followed by BUG

Use BUG_ON instead of if condition followed by BUG in do_setlink. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva --- This code was tested by compilation only. net/core/rtnetlink.c | 3 +-- 1 file changed, 1 insertion(+), 2

[PATCH] net: core: rtnetlink: use BUG_ON instead of if condition followed by BUG

Use BUG_ON instead of if condition followed by BUG in do_setlink. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva --- This code was tested by compilation only. net/core/rtnetlink.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

Re: [PATCH] MIPS: kernel: proc: Remove spurious white space in cpuinfo

On 10/20/2017 01:47 PM, Maciej W. Rozycki wrote: On Fri, 20 Oct 2017, Aleksandar Markovic wrote: Remove unnecessary space from FPU info segment of /proc/cpuinfo. NAK. As I recall back in Nov 2001 I placed the extra space there to visually separate the CPU part from the FPU part, e.g.:

Re: [PATCH] MIPS: kernel: proc: Remove spurious white space in cpuinfo

On 10/20/2017 01:47 PM, Maciej W. Rozycki wrote: On Fri, 20 Oct 2017, Aleksandar Markovic wrote: Remove unnecessary space from FPU info segment of /proc/cpuinfo. NAK. As I recall back in Nov 2001 I placed the extra space there to visually separate the CPU part from the FPU part, e.g.:

Re: [PATCH] PCI/AER: update AER status string print to match other AER logs

On Tue, Oct 17, 2017 at 09:42:02AM -0600, Tyler Baicar wrote: > Currently the AER driver uses cper_print_bits() to print the AER status > string. This causes the status string to not include the proper PCI device > name prefix that the other AER prints include. Also, it has a different > print

Re: [PATCH] PCI/AER: update AER status string print to match other AER logs

On Tue, Oct 17, 2017 at 09:42:02AM -0600, Tyler Baicar wrote: > Currently the AER driver uses cper_print_bits() to print the AER status > string. This causes the status string to not include the proper PCI device > name prefix that the other AER prints include. Also, it has a different > print

[PATCH mmotm] lib/bug.c: fix build when MODULES are not enabled

From: Randy Dunlap Fix build when CONFIG_MODULES is not enabled. Fixes multiple build errors. Signed-off-by: Randy Dunlap Reported-by: kbuild test robot Cc: Andi Kleen --- lib/bug.c |2 ++ 1 file

[PATCH mmotm] lib/bug.c: fix build when MODULES are not enabled

From: Randy Dunlap Fix build when CONFIG_MODULES is not enabled. Fixes multiple build errors. Signed-off-by: Randy Dunlap Reported-by: kbuild test robot Cc: Andi Kleen --- lib/bug.c |2 ++ 1 file changed, 2 insertions(+) --- mmotm-2017-1019-1700.orig/lib/bug.c +++

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

On Fri, 2017-10-20 at 16:54 -0600, dann frazier wrote: > hey, > I'm seeing a regression when executing 'dmraid -r -c' in an arm64 > QEMU guest, which I've bisected to the following commit: > > ca18d6f7 "block: Make most scsi_req_init() calls implicit" > > I haven't yet had time to try and

Re: [bug report] regression bisected to "block: Make most scsi_req_init() calls implicit"

On Fri, 2017-10-20 at 16:54 -0600, dann frazier wrote: > hey, > I'm seeing a regression when executing 'dmraid -r -c' in an arm64 > QEMU guest, which I've bisected to the following commit: > > ca18d6f7 "block: Make most scsi_req_init() calls implicit" > > I haven't yet had time to try and

Re: [PATCH 09/27] uswsusp: Disable when the kernel is locked down

On Thu, 19 Oct 2017, David Howells wrote: > From: Matthew Garrett > > uswsusp allows a user process to dump and then restore kernel state, which > makes it possible to modify the running kernel. Disable this if the kernel > is locked down. > > Signed-off-by: Matthew

Re: [PATCH 09/27] uswsusp: Disable when the kernel is locked down

On Thu, 19 Oct 2017, David Howells wrote: > From: Matthew Garrett > > uswsusp allows a user process to dump and then restore kernel state, which > makes it possible to modify the running kernel. Disable this if the kernel > is locked down. > > Signed-off-by: Matthew Garrett > Signed-off-by:

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Thu, 19 Oct 2017, David Howells wrote: > From: Chun-Yi Lee > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image > through kexec_file systemcall if securelevel has been set. > > This code was showed in Matthew's patch but not in git: >

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Thu, 19 Oct 2017, David Howells wrote: > From: Chun-Yi Lee > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image > through kexec_file systemcall if securelevel has been set. > > This code was showed in Matthew's patch but not in git: > https://lkml.org/lkml/2015/3/13/778 >

Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

On 10/20/2017 10:10 AM, Mark Rutland wrote: > Hi Al, > > On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote: >> On 10/13/2017 08:27 AM, Mark Rutland wrote: >>> I certainly agree that exposing the information that we have is useful, >>> as I have stated several times. I'm not NAKing exposing

Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

On 10/20/2017 10:10 AM, Mark Rutland wrote: > Hi Al, > > On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote: >> On 10/13/2017 08:27 AM, Mark Rutland wrote: >>> I certainly agree that exposing the information that we have is useful, >>> as I have stated several times. I'm not NAKing exposing

Re: [PATCH 00/23] Hardened usercopy whitelisting

On 21/10/2017 00:40, Paolo Bonzini wrote: > This breaks KVM completely on x86, due to two ioctls > (KVM_GET/SET_CPUID2) accessing the cpuid_entries field of struct > kvm_vcpu_arch. > > There's also another broken ioctl, KVM_XEN_HVM_CONFIG, but it is > obsolete and not a big deal at all. > > I

Re: [PATCH 00/23] Hardened usercopy whitelisting

On 21/10/2017 00:40, Paolo Bonzini wrote: > This breaks KVM completely on x86, due to two ioctls > (KVM_GET/SET_CPUID2) accessing the cpuid_entries field of struct > kvm_vcpu_arch. > > There's also another broken ioctl, KVM_XEN_HVM_CONFIG, but it is > obsolete and not a big deal at all. > > I

[PATCH 2/2] KVM: fix KVM_XEN_HVM_CONFIG ioctl

This ioctl is obsolete (it was used by Xenner as far as I know) but still let's not break it gratuitously... Its handler is copying directly into struct kvm. Go through a bounce buffer instead, with the added benefit that we can actually do something useful with the flags argument---the previous

[PATCH 2/2] KVM: fix KVM_XEN_HVM_CONFIG ioctl

This ioctl is obsolete (it was used by Xenner as far as I know) but still let's not break it gratuitously... Its handler is copying directly into struct kvm. Go through a bounce buffer instead, with the added benefit that we can actually do something useful with the flags argument---the previous

[PATCH 0/2] KVM: fixes for the kernel-hardening tree

Two KVM ioctls (KVM_GET/SET_CPUID2) directly access the cpuid_entries field of struct kvm_vcpu_arch. Therefore, the new usercopy hardening work in linux-next, which forbids copies from and to slab objects unless they are from kmalloc or explicitly whitelisted, breaks KVM completely. This series

[PATCH 1/2] KVM: allow setting a usercopy region in struct kvm_vcpu

On x86, struct kvm_vcpu has a usercopy region corresponding to the CPUID entries. The area is read and written by the KVM_GET/SET_CPUID2 ioctls. Without this patch, KVM is completely broken on x86 with usercopy hardening enabled. Define kvm_init in terms of a more generic function that allows

[PATCH 0/2] KVM: fixes for the kernel-hardening tree

Two KVM ioctls (KVM_GET/SET_CPUID2) directly access the cpuid_entries field of struct kvm_vcpu_arch. Therefore, the new usercopy hardening work in linux-next, which forbids copies from and to slab objects unless they are from kmalloc or explicitly whitelisted, breaks KVM completely. This series

[PATCH 1/2] KVM: allow setting a usercopy region in struct kvm_vcpu

On x86, struct kvm_vcpu has a usercopy region corresponding to the CPUID entries. The area is read and written by the KVM_GET/SET_CPUID2 ioctls. Without this patch, KVM is completely broken on x86 with usercopy hardening enabled. Define kvm_init in terms of a more generic function that allows

Re: [PATCH 05/27] kexec: Disable at runtime if the kernel is locked down

On Thu, 19 Oct 2017, David Howells wrote: > From: Matthew Garrett > > kexec permits the loading and execution of arbitrary code in ring 0, which > is something that lock-down is meant to prevent. It makes sense to disable > kexec in this situation. > > This does not

Re: [PATCH 05/27] kexec: Disable at runtime if the kernel is locked down

On Thu, 19 Oct 2017, David Howells wrote: > From: Matthew Garrett > > kexec permits the loading and execution of arbitrary code in ring 0, which > is something that lock-down is meant to prevent. It makes sense to disable > kexec in this situation. > > This does not affect kexec_file_load()

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

On Thu, 19 Oct 2017, David Howells wrote: > From: Matthew Garrett > > Allowing users to write to address space makes it possible for the kernel to > be subverted, avoiding module loading restrictions. Prevent this when the > kernel has been locked down. > >

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

On Thu, 19 Oct 2017, David Howells wrote: > From: Matthew Garrett > > Allowing users to write to address space makes it possible for the kernel to > be subverted, avoiding module loading restrictions. Prevent this when the > kernel has been locked down. > > Signed-off-by: Matthew Garrett >

Re: [PATCH 0/5] xfs refcount conversions

On Fri, Oct 20, 2017 at 02:07:53PM +0300, Elena Reshetova wrote: > Note: our previous thread didn't finish in any conclusion, so > I am resending this now (rebased at latest linux-next) to revive > the discussion. refcount_t is slowly becoming a standard for > refcounters and we would really like

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

On Thu, 19 Oct 2017, David Howells wrote: > If the kernel is locked down, require that all modules have valid > signatures that we can verify. > > Signed-off-by: David Howells Reviewed-by: James Morris -- James Morris

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

On Thu, 19 Oct 2017, David Howells wrote: > If the kernel is locked down, require that all modules have valid > signatures that we can verify. > > Signed-off-by: David Howells Reviewed-by: James Morris -- James Morris

Re: [PATCH 0/5] xfs refcount conversions

On Fri, Oct 20, 2017 at 02:07:53PM +0300, Elena Reshetova wrote: > Note: our previous thread didn't finish in any conclusion, so > I am resending this now (rebased at latest linux-next) to revive > the discussion. refcount_t is slowly becoming a standard for > refcounters and we would really like

Re: [PATCH 01/27] Add the ability to lock down access to the running kernel image

On Thu, 19 Oct 2017, David Howells wrote: > Provide a single call to allow kernel code to determine whether the system > should be locked down, thereby disallowing various accesses that might > allow the running kernel image to be changed including the loading of > modules that aren't validly

Re: [PATCH 01/27] Add the ability to lock down access to the running kernel image

On Thu, 19 Oct 2017, David Howells wrote: > Provide a single call to allow kernel code to determine whether the system > should be locked down, thereby disallowing various accesses that might > allow the running kernel image to be changed including the loading of > modules that aren't validly

  1   2   3   4   5   6   7   8   9   10   >