[PATCH 15/24] staging: lustre: selftest: convert lstcon_rpc_trans_t to proper struct

Turn typedef lstcon_rpc_trans_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/conrpc.c | 36 drivers/staging/lustre/lnet/selftest/conrpc.h | 20 ++--

[PATCH 15/24] staging: lustre: selftest: convert lstcon_rpc_trans_t to proper struct

Turn typedef lstcon_rpc_trans_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/conrpc.c | 36 drivers/staging/lustre/lnet/selftest/conrpc.h | 20 ++-- drivers/staging/lustre/lnet/selftest/console.c | 20

[PATCH 21/24] staging: lustre: selftest: convert lstcon_test_t to proper struct

Turn typedef lstcon_test_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/conctl.c |2 +- drivers/staging/lustre/lnet/selftest/conrpc.c |5 ++- drivers/staging/lustre/lnet/selftest/console.c | 26

[PATCH 21/24] staging: lustre: selftest: convert lstcon_test_t to proper struct

Turn typedef lstcon_test_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/conctl.c |2 +- drivers/staging/lustre/lnet/selftest/conrpc.c |5 ++- drivers/staging/lustre/lnet/selftest/console.c | 26

[PATCH 03/24] staging: lustre: selftest: convert srpc_bulk_t to proper struct

Turn typedef srpc_bulk_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/brw_test.c | 14 +++--- drivers/staging/lustre/lnet/selftest/conrpc.c|4 ++-- drivers/staging/lustre/lnet/selftest/framework.c |2 +-

Re: [RFC PATCH v2 3/3] restartable sequences: basic self-tests

On Wed, Apr 06, 2016 at 01:39:22PM +, Mathieu Desnoyers wrote: > There is still the question of use-after-free however that > remains open. My understanding is that this lock-free list > should be paired with either a type-safe memory allocator, > using RCU, or a garbage collector. Yeah, it

[PATCH 02/24] staging: lustre: selftest: convert srpc_event_t to proper struct

Turn typedef srpc_event_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/rpc.c | 20 ++-- drivers/staging/lustre/lnet/selftest/selftest.h | 14 +++--- 2 files changed, 17 insertions(+), 17

[PATCH 04/24] staging: lustre: selftest: convert srpc_buffer_t to proper struct

Turn typedef srpc_buffer_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/rpc.c | 12 ++-- drivers/staging/lustre/lnet/selftest/selftest.h |6 +++--- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git

[PATCH 13/24] staging: lustre: selftest: convert sfw_test_case_t to proper struct

Turn typedef sfw_test_case_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/framework.c | 16 drivers/staging/lustre/lnet/selftest/selftest.h |4 ++-- 2 files changed, 10 insertions(+), 10 deletions(-) diff

[PATCH 03/24] staging: lustre: selftest: convert srpc_bulk_t to proper struct

Turn typedef srpc_bulk_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/brw_test.c | 14 +++--- drivers/staging/lustre/lnet/selftest/conrpc.c|4 ++-- drivers/staging/lustre/lnet/selftest/framework.c |2 +-

Re: [RFC PATCH v2 3/3] restartable sequences: basic self-tests

On Wed, Apr 06, 2016 at 01:39:22PM +, Mathieu Desnoyers wrote: > There is still the question of use-after-free however that > remains open. My understanding is that this lock-free list > should be paired with either a type-safe memory allocator, > using RCU, or a garbage collector. Yeah, it

[PATCH 02/24] staging: lustre: selftest: convert srpc_event_t to proper struct

Turn typedef srpc_event_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/rpc.c | 20 ++-- drivers/staging/lustre/lnet/selftest/selftest.h | 14 +++--- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git

[PATCH 04/24] staging: lustre: selftest: convert srpc_buffer_t to proper struct

Turn typedef srpc_buffer_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/rpc.c | 12 ++-- drivers/staging/lustre/lnet/selftest/selftest.h |6 +++--- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git

[PATCH 13/24] staging: lustre: selftest: convert sfw_test_case_t to proper struct

Turn typedef sfw_test_case_t to proper structure Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/selftest/framework.c | 16 drivers/staging/lustre/lnet/selftest/selftest.h |4 ++-- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

Linus Torvalds writes: > I suspect there really aren't all that many hibernation users out > there at all, and that yes, that would be the right default. > > Hibernation is really quite nasty when you have to have a fairly big > special partition for it, and shrink

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

Linus Torvalds writes: > I suspect there really aren't all that many hibernation users out > there at all, and that yes, that would be the right default. > > Hibernation is really quite nasty when you have to have a fairly big > special partition for it, and shrink your memory down. Writing

Re: [kernel-hardening] Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 06, 2016 at 09:11:07PM +0200, Yves-Alexis Perez wrote: > On mer., 2016-04-06 at 12:02 -0700, Linus Torvalds wrote: > > So yeah, maybe swap partitions are still more common than I thought. > > And I didn't even consider the possibility that people would hibernate > > a desktop like you

Re: [kernel-hardening] Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 06, 2016 at 09:11:07PM +0200, Yves-Alexis Perez wrote: > On mer., 2016-04-06 at 12:02 -0700, Linus Torvalds wrote: > > So yeah, maybe swap partitions are still more common than I thought. > > And I didn't even consider the possibility that people would hibernate > > a desktop like you

Re: [PATCH v3] arm: omap2: remove redundant multiplatform checks

* Lokesh Vutla [160406 01:50]: > +Tony > > On Wednesday 06 April 2016 01:44 PM, Jonas Rabenstein wrote: > > From: Jonas Rabenstein > > > > The directory arch/arm/mach-omap2 is only selected for compilation if > >

Re: [PATCH v3] arm: omap2: remove redundant multiplatform checks

* Lokesh Vutla [160406 01:50]: > +Tony > > On Wednesday 06 April 2016 01:44 PM, Jonas Rabenstein wrote: > > From: Jonas Rabenstein > > > > The directory arch/arm/mach-omap2 is only selected for compilation if > > CONFIG_ARCH_OMAP2PLUS is selected. CONFIG_ARCH_OMAP2PLUS itself is a > > silent

RE: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)

On Wed, Apr 06, 2016 at 22:07:39, Kalle Valo wrote: > > > More than that, wl1251 family is not officially supported via the > > mainline Linux. > > I guess you mean not officially supported by TI? Because wl1251 driver > has been in mainline for ages and reportedly working. > Correct.

RE: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)

On Wed, Apr 06, 2016 at 22:07:39, Kalle Valo wrote: > > > More than that, wl1251 family is not officially supported via the > > mainline Linux. > > I guess you mean not officially supported by TI? Because wl1251 driver > has been in mainline for ages and reportedly working. > Correct.

Re: [kernel-hardening] Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On mer., 2016-04-06 at 12:02 -0700, Linus Torvalds wrote: > So yeah, maybe swap partitions are still more common than I thought. > And I didn't even consider the possibility that people would hibernate > a desktop like you do. To be fair, it's *my* use case, because suspend won't work but I'm

Re: [kernel-hardening] Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On mer., 2016-04-06 at 12:02 -0700, Linus Torvalds wrote: > So yeah, maybe swap partitions are still more common than I thought. > And I didn't even consider the possibility that people would hibernate > a desktop like you do. To be fair, it's *my* use case, because suspend won't work but I'm

[PATCH] Honor mmap_min_addr with the actual minimum

The minimum address that a process is allowed to mmap when LSM is enabled is 0x1 (65536). This value is tunable and exported via /proc/sys/vm/mmap_min_addr but it is not honored with the actual minimum value. It can be easily checked in a system typing: $ cat /proc/sys/vm/mmap_min_addr 4096

[PATCH] Honor mmap_min_addr with the actual minimum

The minimum address that a process is allowed to mmap when LSM is enabled is 0x1 (65536). This value is tunable and exported via /proc/sys/vm/mmap_min_addr but it is not honored with the actual minimum value. It can be easily checked in a system typing: $ cat /proc/sys/vm/mmap_min_addr 4096

Re: [PATCH] Input: Do not add SYN_REPORT in between a single packet data

On Wed, Apr 6, 2016 at 11:08 PM, Dmitry Torokhov wrote: > On Wed, Apr 06, 2016 at 08:26:39PM +0530, Aniroop Mathur wrote: >> On Sat, Apr 2, 2016 at 10:31 PM, Aniroop Mathur >> wrote: >> > Hello Mr. Torokhov, >> > >> > First of all, Thank you

Re: [PATCH] Input: Do not add SYN_REPORT in between a single packet data

On Wed, Apr 6, 2016 at 11:08 PM, Dmitry Torokhov wrote: > On Wed, Apr 06, 2016 at 08:26:39PM +0530, Aniroop Mathur wrote: >> On Sat, Apr 2, 2016 at 10:31 PM, Aniroop Mathur >> wrote: >> > Hello Mr. Torokhov, >> > >> > First of all, Thank you for your reply. >> > >> > On Sat, Apr 2, 2016 at 3:21

Re: [PATCH] cpuidle: Indicate when a device has been unregistered

On Tue, Apr 05, 2016 at 02:05:38PM -0500, Dave Gerlach wrote: > Currently the 'registered' member of the cpuidle_device struct is set > to 1 during cpuidle_register_device. In this same function there are > checks to see if the device is already registered to prevent duplicate > calls to register

Re: [PATCH] cpuidle: Indicate when a device has been unregistered

On Tue, Apr 05, 2016 at 02:05:38PM -0500, Dave Gerlach wrote: > Currently the 'registered' member of the cpuidle_device struct is set > to 1 during cpuidle_register_device. In this same function there are > checks to see if the device is already registered to prevent duplicate > calls to register

Re: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)

"Machani, Yaniv" writes: > More than that, wl1251 family is not officially supported via the > mainline Linux. I guess you mean not officially supported by TI? Because wl1251 driver has been in mainline for ages and reportedly working. -- Kalle Valo

Re: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)

"Machani, Yaniv" writes: > More than that, wl1251 family is not officially supported via the > mainline Linux. I guess you mean not officially supported by TI? Because wl1251 driver has been in mainline for ages and reportedly working. -- Kalle Valo

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, 6 Apr 2016, e...@abdsec.com wrote: > First, I wrote your attached patch, but then I thought zeroing other > /proc/iomem values would be better. So I changed it. On my systems, /proc/iomem, /proc/ioports and others get their world-readable bits removed during bootup - I guess that would

Re: [kernel-hardening] Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:53 AM, Yves-Alexis Perez wrote: > > Actually you just have to have a swap partition, which people still set as > more or less the ram size, I think, so all in all it works (especially if > people hibernate without the ram completely used). I guess

Re: [kernel-hardening] Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:53 AM, Yves-Alexis Perez wrote: > > Actually you just have to have a swap partition, which people still set as > more or less the ram size, I think, so all in all it works (especially if > people hibernate without the ram completely used). I guess people still do those.

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, 6 Apr 2016, e...@abdsec.com wrote: > First, I wrote your attached patch, but then I thought zeroing other > /proc/iomem values would be better. So I changed it. On my systems, /proc/iomem, /proc/ioports and others get their world-readable bits removed during bootup - I guess that would

Re: [PATCH v7 0/5] ACPI: parse the SPCR table

On Wed, 2016-04-06 at 09:27 -0700, Peter Hurley wrote: > On 04/06/2016 07:18 AM, Mark Salter wrote: > > > > On Wed, 2016-04-06 at 11:52 +0100, Graeme Gregory wrote: > > > > > > On Wed, Apr 06, 2016 at 01:24:12PM +0300, Aleksey Makarov wrote: > > > > > > > > > > > > > > > > > > > > On

Re: [PATCH v7 0/5] ACPI: parse the SPCR table

On Wed, 2016-04-06 at 09:27 -0700, Peter Hurley wrote: > On 04/06/2016 07:18 AM, Mark Salter wrote: > > > > On Wed, 2016-04-06 at 11:52 +0100, Graeme Gregory wrote: > > > > > > On Wed, Apr 06, 2016 at 01:24:12PM +0300, Aleksey Makarov wrote: > > > > > > > > > > > > > > > > > > > > On

Re: [PATCH v3 01/15] dmaengine: dw: fix master selection

On Mon, Apr 04, 2016 at 08:10:54PM +0300, Andy Shevchenko wrote: > On Mon, 2016-04-04 at 10:03 -0700, Vinod Koul wrote: > > On Fri, Mar 18, 2016 at 04:24:40PM +0200, Andy Shevchenko wrote: > > > > > > + /* > > > +  * We need controller-specific data to set up slave > > > transfers. > > > +  */ >

Re: [PATCH v3 01/15] dmaengine: dw: fix master selection

On Mon, Apr 04, 2016 at 08:10:54PM +0300, Andy Shevchenko wrote: > On Mon, 2016-04-04 at 10:03 -0700, Vinod Koul wrote: > > On Fri, Mar 18, 2016 at 04:24:40PM +0200, Andy Shevchenko wrote: > > > > > > + /* > > > +  * We need controller-specific data to set up slave > > > transfers. > > > +  */ >

Re: [lustre-devel] [PATCH] staging/lustre/obdclass: fix build warning

> While building with W=1 we were getting the warning: > > drivers/staging/lustre/lustre/obdclass/cl_object.c:1056:16: > warning: old-style function definition > struct lu_env *cl_env_percpu_get() > ^ > > Signed-off-by: Sudip Mukherjee

[no subject]

Re: [lustre-devel] [PATCH] staging/lustre/obdclass: fix build warning

> While building with W=1 we were getting the warning: > > drivers/staging/lustre/lustre/obdclass/cl_object.c:1056:16: > warning: old-style function definition > struct lu_env *cl_env_percpu_get() > ^ > > Signed-off-by: Sudip Mukherjee Acked-by: James Simmons > --- >

[no subject]

Re: [PATCH RFC] sched/fair: let cpu's cfs_rq to reflect task migration

On 06/04/16 09:37, Morten Rasmussen wrote: > On Tue, Apr 05, 2016 at 06:00:40PM +0100, Dietmar Eggemann wrote: >> @@ -2893,8 +2906,12 @@ static void attach_entity_load_avg(struct cfs_rq >> *cfs_rq, struct sched_entity *s >> se->avg.last_update_time = cfs_rq->avg.last_update_time; >>

Re: [PATCH RFC] sched/fair: let cpu's cfs_rq to reflect task migration

On 06/04/16 09:37, Morten Rasmussen wrote: > On Tue, Apr 05, 2016 at 06:00:40PM +0100, Dietmar Eggemann wrote: >> @@ -2893,8 +2906,12 @@ static void attach_entity_load_avg(struct cfs_rq >> *cfs_rq, struct sched_entity *s >> se->avg.last_update_time = cfs_rq->avg.last_update_time; >>

Re: [kernel-hardening] Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On mer., 2016-04-06 at 11:43 -0700, Linus Torvalds wrote: > Hibernation is really quite nasty when you have to have a fairly big > special partition for it, and shrink your memory down. Writing things > to disk was a whole lot more reasonable back in the days when laptops > had 16MB of memory.

Re: [kernel-hardening] Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On mer., 2016-04-06 at 11:43 -0700, Linus Torvalds wrote: > Hibernation is really quite nasty when you have to have a fairly big > special partition for it, and shrink your memory down. Writing things > to disk was a whole lot more reasonable back in the days when laptops > had 16MB of memory.

Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

On Wed, 6 Apr 2016 15:45:10 +0200 Vitaly Kuznetsov wrote: > This patchset continues the work I started with: > > commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6 > Author: Vitaly Kuznetsov > Date: Tue Mar 15 14:56:48 2016 -0700 > >

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:52 AM, Christian Kujau wrote: > On Wed, 6 Apr 2016, e...@abdsec.com wrote: >> First, I wrote your attached patch, but then I thought zeroing other >> /proc/iomem values would be better. So I changed it. > > On my systems, /proc/iomem, /proc/ioports

Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

On Wed, 6 Apr 2016 15:45:10 +0200 Vitaly Kuznetsov wrote: > This patchset continues the work I started with: > > commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6 > Author: Vitaly Kuznetsov > Date: Tue Mar 15 14:56:48 2016 -0700 > > memory-hotplug: add automatic onlining policy for the

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:52 AM, Christian Kujau wrote: > On Wed, 6 Apr 2016, e...@abdsec.com wrote: >> First, I wrote your attached patch, but then I thought zeroing other >> /proc/iomem values would be better. So I changed it. > > On my systems, /proc/iomem, /proc/ioports and others get their >

Re: [PATCH] IMA: Use the system trusted keyrings instead of .ima_mok (update)

On Wed, 2016-04-06 at 19:10 +0100, David Howells wrote: > Mimi Zohar wrote: > > > I'm not sure what you're asking. If you're asking if the whole file can > > be include based on whether this option is enabled, then no. > > No - but integrity_init_keyring() just

Re: [PATCH] IMA: Use the system trusted keyrings instead of .ima_mok (update)

On Wed, 2016-04-06 at 19:10 +0100, David Howells wrote: > Mimi Zohar wrote: > > > I'm not sure what you're asking. If you're asking if the whole file can > > be include based on whether this option is enabled, then no. > > No - but integrity_init_keyring() just returns if init_keyring is false

Re: [PATCH] csiostor: Fix backwards locking in the function __csio_unreg_rnode

On Wed, Apr 06, 2016 at 01:28:24PM -0400, James Bottomley wrote: > On Wed, 2016-04-06 at 13:23 -0400, Bastien Philbert wrote: > > > > On 2016-04-06 01:14 PM, James Bottomley wrote: > > > On Wed, 2016-04-06 at 10:36 -0400, Bastien Philbert wrote: > > > > > > > > On 2016-04-06 10:24 AM, James

Re: [PATCH] csiostor: Fix backwards locking in the function __csio_unreg_rnode

On Wed, Apr 06, 2016 at 01:28:24PM -0400, James Bottomley wrote: > On Wed, 2016-04-06 at 13:23 -0400, Bastien Philbert wrote: > > > > On 2016-04-06 01:14 PM, James Bottomley wrote: > > > On Wed, 2016-04-06 at 10:36 -0400, Bastien Philbert wrote: > > > > > > > > On 2016-04-06 10:24 AM, James

Re: [PATCH 1/2] x86/arch_prctl: add ARCH_SET_{COMPAT,NATIVE} to change compatible mode

On Wed, Apr 6, 2016 at 11:04 AM, Andy Lutomirski wrote: > [cc Dave Hansen for MPX] > > - For MPX, could we track which syscall called mpx_enable_management? > I.e. can we stash in_compat_syscall's return from > mpx_enable_management and use that instead of trying to

Re: [PATCH 1/2] x86/arch_prctl: add ARCH_SET_{COMPAT,NATIVE} to change compatible mode

On Wed, Apr 6, 2016 at 11:04 AM, Andy Lutomirski wrote: > [cc Dave Hansen for MPX] > > - For MPX, could we track which syscall called mpx_enable_management? > I.e. can we stash in_compat_syscall's return from > mpx_enable_management and use that instead of trying to determine the > MPX data

Re: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs

On Wed, Apr 6, 2016 at 9:05 AM, Zheng, Lv wrote: >> It is hard to create new kernel objects from sysfs. You need to resort >> to hacks like using new_table sysfs entries which does not map to a >> kernel object. Writes larger then PAGE_SIZE are impossible to handle >> with

Re: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs

On Wed, Apr 6, 2016 at 9:05 AM, Zheng, Lv wrote: >> It is hard to create new kernel objects from sysfs. You need to resort >> to hacks like using new_table sysfs entries which does not map to a >> kernel object. Writes larger then PAGE_SIZE are impossible to handle >> with multiple open files

Re: [PATCH v2 08/30] Add sparc-specific parity functions

Hi Zeng. > > Use runtime patching for sparc64, lifted from hweight No errors found in patch - but a few comments. In general patch looks good. > +++ b/arch/sparc/include/asm/bitops_64.h > @@ -47,6 +47,24 @@ unsigned int __arch_hweight16(unsigned int w); > unsigned int __arch_hweight8(unsigned

Re: [PATCH v2 08/30] Add sparc-specific parity functions

Hi Zeng. > > Use runtime patching for sparc64, lifted from hweight No errors found in patch - but a few comments. In general patch looks good. > +++ b/arch/sparc/include/asm/bitops_64.h > @@ -47,6 +47,24 @@ unsigned int __arch_hweight16(unsigned int w); > unsigned int __arch_hweight8(unsigned

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:37 AM, Kees Cook wrote: > > At some point I'd like to see if distros would be interested in > inverting the default logic (maybe with a CONFIG to avoid changing the > current behavior) where instead of needing to put "kaslr" on the > command line

Re: brcmfmac: sdio: remove unused variable retry_limit

> From: Colin Ian King > > retry_limit has never been used during the life of this driver, so > we may as well remove it as it is redundant. > > Signed-off-by: Colin Ian King > Reviewed-by: Julian Calaby Thanks,

Re: brcmfmac: sdio: remove unused variable retry_limit

> From: Colin Ian King > > retry_limit has never been used during the life of this driver, so > we may as well remove it as it is redundant. > > Signed-off-by: Colin Ian King > Reviewed-by: Julian Calaby Thanks, applied to wireless-drivers-next.git. Kalle Valo

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:37 AM, Kees Cook wrote: > > At some point I'd like to see if distros would be interested in > inverting the default logic (maybe with a CONFIG to avoid changing the > current behavior) where instead of needing to put "kaslr" on the > command line to prefer kaslr over

Re: [v2] mwifiex: advertise low priority scan feature

> From: Amitkumar Karwar > > Low priority scan handling code which delays or aborts scan > operation based on Tx traffic is removed recently. The reason > is firmware already takes care of it in our new feature scan > channel gap. Hence we should advertise low priority scan

Re: [v2] mwifiex: advertise low priority scan feature

> From: Amitkumar Karwar > > Low priority scan handling code which delays or aborts scan > operation based on Tx traffic is removed recently. The reason > is firmware already takes care of it in our new feature scan > channel gap. Hence we should advertise low priority scan > support to

Re: wl12xx: remove redundant null check on wl->scan.ssid

> From: Colin Ian King > > ssid is an array of u8, so it can never be null, so the null check on > wl->scan.ssid is redundant and can be removed. > > Signed-off-by: Colin Ian King Thanks, applied to wireless-drivers-next.git. Kalle Valo

Re: wl12xx: remove redundant null check on wl->scan.ssid

> From: Colin Ian King > > ssid is an array of u8, so it can never be null, so the null check on > wl->scan.ssid is redundant and can be removed. > > Signed-off-by: Colin Ian King Thanks, applied to wireless-drivers-next.git. Kalle Valo

Re: rtlwifi: btcoexist: Convert BTC_PRINTK to btc__dbg

> Use a more common logging style. > > Miscellanea: > > o Add specific logging macros for ALGORITHM and INTERFACE types > o Output the messages at KERN_DEBUG > o Coalesce formats > o Align arguments > o Whitespace style adjustments for only these changes > > Signed-off-by: Joe Perches

Re: rtlwifi: btcoexist: Convert BTC_PRINTK to btc__dbg

> Use a more common logging style. > > Miscellanea: > > o Add specific logging macros for ALGORITHM and INTERFACE types > o Output the messages at KERN_DEBUG > o Coalesce formats > o Align arguments > o Whitespace style adjustments for only these changes > > Signed-off-by: Joe Perches

[patch] iommu/vt-d: silence an uninitialized variable warning

My static checker complains that "dma_alias" is uninitialized unless we are dealing with a pci device. This is true but harmless. Anyway, we can flip the condition around to silence the warning. Signed-off-by: Dan Carpenter diff --git a/drivers/iommu/intel-iommu.c

[patch] iommu/vt-d: silence an uninitialized variable warning

My static checker complains that "dma_alias" is uninitialized unless we are dealing with a pci device. This is true but harmless. Anyway, we can flip the condition around to silence the warning. Signed-off-by: Dan Carpenter diff --git a/drivers/iommu/intel-iommu.c

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:31 AM, Linus Torvalds wrote: > On Wed, Apr 6, 2016 at 11:05 AM, wrote: >> >> Most distros don't use KASLR, but they use kptr_restrict. Without KASLR, >> kptr_restirct most likely useless. > > Well, yes kaslr is

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:31 AM, Linus Torvalds wrote: > On Wed, Apr 6, 2016 at 11:05 AM, wrote: >> >> Most distros don't use KASLR, but they use kptr_restrict. Without KASLR, >> kptr_restirct most likely useless. > > Well, yes kaslr is effectively useless right now due to the fact that >

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:05 AM, wrote: > > Most distros don't use KASLR, but they use kptr_restrict. Without KASLR, > kptr_restirct most likely useless. Well, yes kaslr is effectively useless right now due to the fact that people still use hibernation in effectively every

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:05 AM, wrote: > > Most distros don't use KASLR, but they use kptr_restrict. Without KASLR, > kptr_restirct most likely useless. Well, yes kaslr is effectively useless right now due to the fact that people still use hibernation in effectively every single distro out

Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable

On Fri, Apr 01, 2016 at 01:04:54PM +0200, Michal Hocko wrote: > diff --git a/arch/x86/lib/rwsem.S b/arch/x86/lib/rwsem.S > index 40027db99140..d1a1397e1fb3 100644 > --- a/arch/x86/lib/rwsem.S > +++ b/arch/x86/lib/rwsem.S > @@ -101,6 +101,14 @@ ENTRY(call_rwsem_down_write_failed) > ret >

Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable

On Fri, Apr 01, 2016 at 01:04:54PM +0200, Michal Hocko wrote: > diff --git a/arch/x86/lib/rwsem.S b/arch/x86/lib/rwsem.S > index 40027db99140..d1a1397e1fb3 100644 > --- a/arch/x86/lib/rwsem.S > +++ b/arch/x86/lib/rwsem.S > @@ -101,6 +101,14 @@ ENTRY(call_rwsem_down_write_failed) > ret >

Re: [trivial] mwifiex: Spelling s/minmum/minimum/, s/bandwidth/bandwith/

> Signed-off-by: Geert Uytterhoeven Thanks, applied to wireless-drivers-next.git. Kalle Valo

Re: [trivial] mwifiex: Spelling s/minmum/minimum/, s/bandwidth/bandwith/

> Signed-off-by: Geert Uytterhoeven Thanks, applied to wireless-drivers-next.git. Kalle Valo

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:05 AM, wrote: > First, I wrote your attached patch, but then I thought zeroing other > /proc/iomem values would be better. So I changed it. > > Most distros don't use KASLR, but they use kptr_restrict. Without KASLR, Well, hopefully that'll change over

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

On Wed, Apr 6, 2016 at 11:05 AM, wrote: > First, I wrote your attached patch, but then I thought zeroing other > /proc/iomem values would be better. So I changed it. > > Most distros don't use KASLR, but they use kptr_restrict. Without KASLR, Well, hopefully that'll change over time. :) >

Re: [PATCH] neigh: remove duplicated log msg

From: Abdelmajid Mlayeh Date: Wed, 6 Apr 2016 14:42:06 +0200 > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the

Re: [PATCH] neigh: remove duplicated log msg

From: Abdelmajid Mlayeh Date: Wed, 6 Apr 2016 14:42:06 +0200 > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please

Re: [PATCH] IMA: Use the system trusted keyrings instead of .ima_mok (update)

Mimi Zohar wrote: > I'm not sure what you're asking. If you're asking if the whole file can > be include based on whether this option is enabled, then no. No - but integrity_init_keyring() just returns if init_keyring is false - but this is a variable and is assigned

Re: [PATCH] IMA: Use the system trusted keyrings instead of .ima_mok (update)

Mimi Zohar wrote: > I'm not sure what you're asking. If you're asking if the whole file can > be include based on whether this option is enabled, then no. No - but integrity_init_keyring() just returns if init_keyring is false - but this is a variable and is assigned storage, despite the fact

Re: [PATCH v2 2/2] rtmutex: Kill pi_waiters_leftmost from task_struct

On Wed, Apr 06, 2016 at 08:59:16PM +0800, Xunlei Pang wrote: > Current code use pi_waiters_leftmost to record the leftmost waiter, > but actually it can be get directly from task_struct::pi_waiters > using rb_first(). The performance penalty introduced by rb_first() > should be fine, because

Re: [PATCH v2 2/2] rtmutex: Kill pi_waiters_leftmost from task_struct

On Wed, Apr 06, 2016 at 08:59:16PM +0800, Xunlei Pang wrote: > Current code use pi_waiters_leftmost to record the leftmost waiter, > but actually it can be get directly from task_struct::pi_waiters > using rb_first(). The performance penalty introduced by rb_first() > should be fine, because

Re: [PATCH v2 1/2] sched/rtmutex/deadline: Fix a PI crash for deadline tasks

On Wed, Apr 06, 2016 at 08:59:15PM +0800, Xunlei Pang wrote: > A crash happened while I'm playing with deadline PI rtmutex. > > BUG: unable to handle kernel NULL pointer dereference at 0018 > IP: [] rt_mutex_get_top_task+0x1f/0x30 > PGD 232a75067 PUD 230947067 PMD 0 >

Re: [PATCH v2 1/2] sched/rtmutex/deadline: Fix a PI crash for deadline tasks

On Wed, Apr 06, 2016 at 08:59:15PM +0800, Xunlei Pang wrote: > A crash happened while I'm playing with deadline PI rtmutex. > > BUG: unable to handle kernel NULL pointer dereference at 0018 > IP: [] rt_mutex_get_top_task+0x1f/0x30 > PGD 232a75067 PUD 230947067 PMD 0 >

RE: [PATCH] staging: comedi: das1800: remove unused variable

On Wednesday, April 06, 2016 3:41 AM, Ian Abbott wrote: > On 06/04/16 10:41, Ian Abbott wrote: >> On 06/04/16 02:21, Hartley Sweeten wrote: >>> On Tuesday, April 05, 2016 7:23 AM, Sudip Mukherjee wrote: The variable unipolar was never used. Signed-off-by: Sudip Mukherjee

Re: [PATCH v2 10/14] USB: ch341: fix coding style

On Wed, Apr 06, 2016 at 07:58:36PM +0200, Grigori Goronzy wrote: > On 04/02/2016 07:29 PM, Joe Perches wrote: > > Most of the whitespace only changes are undesired. > > Well, the style wasn't very consistent. I think consistency is > important. So I took the liberty of deciding for one style and

RE: [PATCH] staging: comedi: das1800: remove unused variable

On Wednesday, April 06, 2016 3:41 AM, Ian Abbott wrote: > On 06/04/16 10:41, Ian Abbott wrote: >> On 06/04/16 02:21, Hartley Sweeten wrote: >>> On Tuesday, April 05, 2016 7:23 AM, Sudip Mukherjee wrote: The variable unipolar was never used. Signed-off-by: Sudip Mukherjee ---

Re: [PATCH v2 10/14] USB: ch341: fix coding style

On Wed, Apr 06, 2016 at 07:58:36PM +0200, Grigori Goronzy wrote: > On 04/02/2016 07:29 PM, Joe Perches wrote: > > Most of the whitespace only changes are undesired. > > Well, the style wasn't very consistent. I think consistency is > important. So I took the liberty of deciding for one style and

Re: [PATCH] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()

On 04/03/2016 11:09 AM, Jonathan Cameron wrote: > On 01/04/16 17:53, Alison Schofield wrote: >> Two instances are moved to the new claim/release API: >> >> In the first instance, the driver was using mlock followed by >> iio_buffer_enabled(). Replace that code with the new API to guarantee >> the

Re: [PATCH] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()

On 04/03/2016 11:09 AM, Jonathan Cameron wrote: > On 01/04/16 17:53, Alison Schofield wrote: >> Two instances are moved to the new claim/release API: >> >> In the first instance, the driver was using mlock followed by >> iio_buffer_enabled(). Replace that code with the new API to guarantee >> the

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

First, I wrote your attached patch, but then I thought zeroing other /proc/iomem values would be better. So I changed it. Most distros don't use KASLR, but they use kptr_restrict. Without KASLR, kptr_restirct most likely useless. As you said these things should be done long ago

Re: [PATCH] KERNEL: resource: Fix bug on leakage in /proc/iomem file

First, I wrote your attached patch, but then I thought zeroing other /proc/iomem values would be better. So I changed it. Most distros don't use KASLR, but they use kptr_restrict. Without KASLR, kptr_restirct most likely useless. As you said these things should be done long ago

<    3   4   5   6   7   8   9   10   11   12   >