Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/07/2016 06:39 PM, Linus Torvalds wrote: > Can anybody give a *coherent* and actual *real* reason why the kernel > would ever care about anything else? We already have a similar per-thread data structure, the robust mutex list. The CPU ID is another one. So it's conceivable we might get

[PATCH] mtd: nand: s3c2410: fix bug in s3c2410_nand_correct_data()

From: Zeng Zhaoxiu If there is only one bit difference in the ECC, the function should return 1. The result of "diff0 & ~(1<

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/07/2016 06:39 PM, Linus Torvalds wrote: > Can anybody give a *coherent* and actual *real* reason why the kernel > would ever care about anything else? We already have a similar per-thread data structure, the robust mutex list. The CPU ID is another one. So it's conceivable we might get

[PATCH] mtd: nand: s3c2410: fix bug in s3c2410_nand_correct_data()

From: Zeng Zhaoxiu If there is only one bit difference in the ECC, the function should return 1. The result of "diff0 & ~(1<

Re: [rfc patch 2/2] rt/locking/hotplug: Fix rt_spin_lock_slowlock() migrate_disable() bug

On 04/07/2016 06:37 AM, Mike Galbraith wrote: > On Wed, 2016-04-06 at 14:00 +0200, Mike Galbraith wrote: >> It'll take a hotplug beating seemingly as well as any non-rt kernel, >> but big box NAKed it due to jitter, which can mean 1.0 things.. duh. > > FWIW, the below turned big box NAK into ACK.

Re: [rfc patch 2/2] rt/locking/hotplug: Fix rt_spin_lock_slowlock() migrate_disable() bug

On 04/07/2016 06:37 AM, Mike Galbraith wrote: > On Wed, 2016-04-06 at 14:00 +0200, Mike Galbraith wrote: >> It'll take a hotplug beating seemingly as well as any non-rt kernel, >> but big box NAKed it due to jitter, which can mean 1.0 things.. duh. > > FWIW, the below turned big box NAK into ACK.

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

On 04/02/2016 05:12 AM, Mike Galbraith wrote: >> By the time I improved hotplug I played with this. I had a few ideas but >> it didn't fly in the end. Today however I ended up with this: > > Yeah, but that fails the duct tape test too. Mine is below, and is the > extra sticky variety ;-) With

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

On 04/02/2016 05:12 AM, Mike Galbraith wrote: >> By the time I improved hotplug I played with this. I had a few ideas but >> it didn't fly in the end. Today however I ended up with this: > > Yeah, but that fails the duct tape test too. Mine is below, and is the > extra sticky variety ;-) With

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds wrote: > Can anybody give a *coherent* and actual *real* reason why the kernel > would ever care about anything else? The rseq data structure, which is still being designed. OTOH, that thing could be registered

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds wrote: > Can anybody give a *coherent* and actual *real* reason why the kernel > would ever care about anything else? The rseq data structure, which is still being designed. OTOH, that thing could be registered separately by userspace. --Andy

Re: [PATCH v6 6/7] dma-reserved-iommu: iommu_get/put_single_reserved

On 04/07/2016 04:38 PM, Jean-Philippe Brucker wrote: > Hi Eric, > > On Thu, Apr 07, 2016 at 11:33:42AM +0200, Eric Auger wrote: >> Alex, >> On 04/07/2016 01:12 AM, Alex Williamson wrote: >>> On Mon, 4 Apr 2016 08:07:01 + >>> Eric Auger wrote: >>> This patch

Re: [PATCH v6 6/7] dma-reserved-iommu: iommu_get/put_single_reserved

On 04/07/2016 04:38 PM, Jean-Philippe Brucker wrote: > Hi Eric, > > On Thu, Apr 07, 2016 at 11:33:42AM +0200, Eric Auger wrote: >> Alex, >> On 04/07/2016 01:12 AM, Alex Williamson wrote: >>> On Mon, 4 Apr 2016 08:07:01 + >>> Eric Auger wrote: >>> This patch introduces

Re: [PATCH RFC 1/2] scatterlist: add mempool based chained SG alloc/free api

On Thu, Apr 7, 2016 at 7:56 AM, Bart Van Assche wrote: > On 03/15/16 15:39, Ming Lin wrote: >> >> +static void sg_mempoll_free(struct scatterlist *sgl, unsigned int nents) > > > Please change mempoll into mempool. Good catch. Thanks Bart!

Re: [PATCH RFC 1/2] scatterlist: add mempool based chained SG alloc/free api

On Thu, Apr 7, 2016 at 7:56 AM, Bart Van Assche wrote: > On 03/15/16 15:39, Ming Lin wrote: >> >> +static void sg_mempoll_free(struct scatterlist *sgl, unsigned int nents) > > > Please change mempoll into mempool. Good catch. Thanks Bart!

Re: [RFC PATCH 0/3] restartable sequences v2: fast user-space percpu critical sections

On Thu, Apr 7, 2016 at 8:53 AM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 08:44:38AM -0700, Andy Lutomirski wrote: >> On Thu, Apr 7, 2016 at 8:24 AM, Peter Zijlstra wrote: >> > On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote: >>

Re: [RFC PATCH 0/3] restartable sequences v2: fast user-space percpu critical sections

On Thu, Apr 7, 2016 at 8:53 AM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 08:44:38AM -0700, Andy Lutomirski wrote: >> On Thu, Apr 7, 2016 at 8:24 AM, Peter Zijlstra wrote: >> > On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote: >> >> What I meant was: rather than shoving

Re: [PATCH] libnvdimm, test: add mock SMART data payload

On Thu, Apr 7, 2016 at 1:27 AM, Johannes Thumshirn wrote: > On Mittwoch, 6. April 2016 17:53:49 CEST Dan Williams wrote: >> Provide simulated SMART data to enable the ndctl implementation of SMART >> data retrieval and parsing. >> >> The payload is defined here, "Section 4.1

Re: [RESEND] mwifiex: fix NULL pointer dereference error

> In mwifiex_enable_hs, we need to check if > priv->wdev.wiphy->wowlan_config is NULL before accessing its member. > This sometimes cause kernel panic when suspend/resume. > > Signed-off-by: Wei-Ning Huang Thanks, applied to wireless-drivers-next.git. Kalle Valo

Re: [PATCH v1 06/10] device property: switch to use UUID API

On Fri, 2016-02-26 at 16:11 +0200, Andy Shevchenko wrote: > On Thu, 2016-02-18 at 01:03 +0100, Rafael J. Wysocki wrote: > > > > On Wednesday, February 17, 2016 02:17:24 PM Andy Shevchenko wrote: > > > > > > Switch to use a generic UUID API instead of custom approach. It > > > allows to > > >

Re: [RESEND] mwifiex: fix NULL pointer dereference error

> In mwifiex_enable_hs, we need to check if > priv->wdev.wiphy->wowlan_config is NULL before accessing its member. > This sometimes cause kernel panic when suspend/resume. > > Signed-off-by: Wei-Ning Huang Thanks, applied to wireless-drivers-next.git. Kalle Valo

Re: [PATCH v1 06/10] device property: switch to use UUID API

On Fri, 2016-02-26 at 16:11 +0200, Andy Shevchenko wrote: > On Thu, 2016-02-18 at 01:03 +0100, Rafael J. Wysocki wrote: > > > > On Wednesday, February 17, 2016 02:17:24 PM Andy Shevchenko wrote: > > > > > > Switch to use a generic UUID API instead of custom approach. It > > > allows to > > >

Re: [PATCH] libnvdimm, test: add mock SMART data payload

On Thu, Apr 7, 2016 at 1:27 AM, Johannes Thumshirn wrote: > On Mittwoch, 6. April 2016 17:53:49 CEST Dan Williams wrote: >> Provide simulated SMART data to enable the ndctl implementation of SMART >> data retrieval and parsing. >> >> The payload is defined here, "Section 4.1 SMART and Health Info

Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another

> On Thu, 7 Apr 2016, Michal Nazarewicz wrote: >> This makes me suspect it’s not possible to link a function instance to >> the same configuration twice, but now that I think about it, I’m not >> quite sure what would happen if one did: >> >> ln -s functions/mass_storage.0 configs/c.1/foo >>

Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another

> On Thu, 7 Apr 2016, Michal Nazarewicz wrote: >> This makes me suspect it’s not possible to link a function instance to >> the same configuration twice, but now that I think about it, I’m not >> quite sure what would happen if one did: >> >> ln -s functions/mass_storage.0 configs/c.1/foo >>

Re: mwifiex: ie_list is an array, so no need to check if NULL

> From: Colin Ian King > > ap_ie->ie_list is an array of struct mwifiex_ie and can never > be null, so the null check on this array is redundant and can > be removed. > > Signed-off-by: Colin Ian King Thanks, applied to

Re: mwifiex: ie_list is an array, so no need to check if NULL

> From: Colin Ian King > > ap_ie->ie_list is an array of struct mwifiex_ie and can never > be null, so the null check on this array is redundant and can > be removed. > > Signed-off-by: Colin Ian King Thanks, applied to wireless-drivers-next.git. Kalle Valo

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On Thu, Apr 7, 2016 at 4:19 AM, Peter Zijlstra wrote: > > People objected against the fixed size scheme, but it being possible to > get a fixed TCB offset and reduce indirections is a big win IMO. Guys, I'm going to just make an executive decision here, because this whole

Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On Thu, Apr 7, 2016 at 4:19 AM, Peter Zijlstra wrote: > > People objected against the fixed size scheme, but it being possible to > get a fixed TCB offset and reduce indirections is a big win IMO. Guys, I'm going to just make an executive decision here, because this whole "fixed vs some strange

Re: [PATCH] x86: wire up compat readv2/writev2 syscalls

Hi Christoph, [auto build test ERROR on v4.6-rc2] [also build test ERROR on next-20160407] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Christoph-Hellwig/x86

Re: [PATCH] x86: wire up compat readv2/writev2 syscalls

Hi Christoph, [auto build test ERROR on v4.6-rc2] [also build test ERROR on next-20160407] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Christoph-Hellwig/x86

Re: [kernel-hardening] Re: [RFC v1] mm: SLAB freelist randomization

That's a use after free. The randomization of the freelist should not have much effect on that. I was going to quote this exploit that is applicable to SLAB as well: https://jon.oberheide.org/blog/2010/09/10/linux-kernel-can-slub-overflow Regards. Thomas On Thu, Apr 7, 2016 at 9:17 AM,

Re: [kernel-hardening] Re: [RFC v1] mm: SLAB freelist randomization

That's a use after free. The randomization of the freelist should not have much effect on that. I was going to quote this exploit that is applicable to SLAB as well: https://jon.oberheide.org/blog/2010/09/10/linux-kernel-can-slub-overflow Regards. Thomas On Thu, Apr 7, 2016 at 9:17 AM,

[PATCH v11 2/3] printk: Make wake_up_klogd_work_func() async

From: Jan Kara Offload printing of scheduler deferred messages from IRQ context to a schedulable printing kthread, when possible (the same way we do it in vprintk_emit()). Otherwise, the CPU can spend unbounded amount of time doing printing in console_unlock() from IRQ.

[PATCH v11 0/3] printk: Make printk() completely async

and thus we don't lockup any particular CPU or even interrupts. against next-20160407 v11: -- switch default to sync printk -- make `synchronous' param RW (Andrew, Jan) -- set RT priority to printk kthread (Andrew) -- correct comments (Andrew) v10: -- simplify printk_kthread_need_flush_console (Jan

[PATCH v11 2/3] printk: Make wake_up_klogd_work_func() async

From: Jan Kara Offload printing of scheduler deferred messages from IRQ context to a schedulable printing kthread, when possible (the same way we do it in vprintk_emit()). Otherwise, the CPU can spend unbounded amount of time doing printing in console_unlock() from IRQ. Signed-off-by: Jan Kara

[PATCH v11 0/3] printk: Make printk() completely async

and thus we don't lockup any particular CPU or even interrupts. against next-20160407 v11: -- switch default to sync printk -- make `synchronous' param RW (Andrew, Jan) -- set RT priority to printk kthread (Andrew) -- correct comments (Andrew) v10: -- simplify printk_kthread_need_flush_console (Jan

[PATCH v11 1/3] printk: Make printk() completely async

From: Jan Kara Currently, printk() sometimes waits for message to be printed to console and sometimes it does not (when console_sem is held by some other process). In case printk() grabs console_sem and starts printing to console, it prints messages from kernel printk buffer until

[PATCH v11 3/3] printk: make printk.synchronous param rw

Change `synchronous' printk param to be RW, so user space can change printk mode back and forth to/from sync mode (which is considered to be more reliable). Signed-off-by: Sergey Senozhatsky --- kernel/printk/printk.c | 63

[PATCH v11 1/3] printk: Make printk() completely async

From: Jan Kara Currently, printk() sometimes waits for message to be printed to console and sometimes it does not (when console_sem is held by some other process). In case printk() grabs console_sem and starts printing to console, it prints messages from kernel printk buffer until the buffer is

[PATCH v11 3/3] printk: make printk.synchronous param rw

Change `synchronous' printk param to be RW, so user space can change printk mode back and forth to/from sync mode (which is considered to be more reliable). Signed-off-by: Sergey Senozhatsky --- kernel/printk/printk.c | 63 ++ 1 file changed, 53

Re: [PATCH] phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar

On 04/05/2016 09:34 PM, Jon Mason wrote: > > > On Wed, Mar 30, 2016 at 5:32 PM, Jon Mason > wrote: > > On Tue, Mar 29, 2016 at 10:01 AM, Rafał Miłecki > wrote: > > Northstar is

Re: [PATCH] phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar

On 04/05/2016 09:34 PM, Jon Mason wrote: > > > On Wed, Mar 30, 2016 at 5:32 PM, Jon Mason > wrote: > > On Tue, Mar 29, 2016 at 10:01 AM, Rafał Miłecki > wrote: > > Northstar is a family of SoCs used in home routers. They

[PATCH] staging: android: ion: dummy: fix dereference of ERR_PTR

ion_device_create() can fail and if it fails then it returns the error value in ERR_PTR. Signed-off-by: Sudip Mukherjee --- drivers/staging/android/ion/ion_dummy_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH] staging: android: ion: dummy: fix dereference of ERR_PTR

ion_device_create() can fail and if it fails then it returns the error value in ERR_PTR. Signed-off-by: Sudip Mukherjee --- drivers/staging/android/ion/ion_dummy_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/android/ion/ion_dummy_driver.c

Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

On Thu, 2016-04-07 at 17:23 +0100, David Howells wrote: > Disable a debugging statement that has been left enabled > > Signed-off-by: David Howells > --- > >  net/rxrpc/ar-ack.c |2 +- >  1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/rxrpc/ar-ack.c

Re: [PATCH 0/3] mm/mmap.c: don't unmap the overlapping VMA(s)

On Thu 07-04-16 18:11:29, Piotr Kwapulinski wrote: > On Mon, Apr 04, 2016 at 05:26:43PM +0200, Vlastimil Babka wrote: > > On 04/04/2016 09:31 AM, Michal Hocko wrote: > > >On Sat 02-04-16 21:17:31, Piotr Kwapulinski wrote: > > >>Currently the mmap(MAP_FIXED) discards the overlapping part of the > >

Re: [PATCH RFC] clocksource: Detect a watchdog overflow

On Thu, Apr 7, 2016 at 1:14 AM, Gratian Crisan wrote: > John Stultz writes: >> So I'm sympathetic to this issue, because I remember seeing similar >> problems w/ runaway SCHED_FIFO tasks w/ PREEMPT_RT. > > Yeah, a runaway rt thread can easily do it. That's just bad design.

Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

On Thu, 2016-04-07 at 17:23 +0100, David Howells wrote: > Disable a debugging statement that has been left enabled > > Signed-off-by: David Howells > --- > >  net/rxrpc/ar-ack.c |2 +- >  1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/rxrpc/ar-ack.c b/net/rxrpc/ar-ack.c

Re: [PATCH 0/3] mm/mmap.c: don't unmap the overlapping VMA(s)

On Thu 07-04-16 18:11:29, Piotr Kwapulinski wrote: > On Mon, Apr 04, 2016 at 05:26:43PM +0200, Vlastimil Babka wrote: > > On 04/04/2016 09:31 AM, Michal Hocko wrote: > > >On Sat 02-04-16 21:17:31, Piotr Kwapulinski wrote: > > >>Currently the mmap(MAP_FIXED) discards the overlapping part of the > >

Re: [PATCH RFC] clocksource: Detect a watchdog overflow

On Thu, Apr 7, 2016 at 1:14 AM, Gratian Crisan wrote: > John Stultz writes: >> So I'm sympathetic to this issue, because I remember seeing similar >> problems w/ runaway SCHED_FIFO tasks w/ PREEMPT_RT. > > Yeah, a runaway rt thread can easily do it. That's just bad design. In > our case it was a

Re: [PATCH v3 00/16] da8xx USB clocks

On 03/24/2016 06:51 PM, David Lechner wrote: This is a reworking of the v2 series based of feedback and review. There were very many suggestions, so hopefully I didn't miss any. Here are the highlights... New stuff: * Fixed the davinci device tree declarations to use the preferred DT address

Re: [PATCH v3 00/16] da8xx USB clocks

On 03/24/2016 06:51 PM, David Lechner wrote: This is a reworking of the v2 series based of feedback and review. There were very many suggestions, so hopefully I didn't miss any. Here are the highlights... New stuff: * Fixed the davinci device tree declarations to use the preferred DT address

[PATCH 4/5] max44000: Expose ambient sensor scaling

This patch exposes ALSTIM as illuminance_integration_time and ALSPGA as illuminance_scale. Changing ALSTIM also changes the number of bits available in the data register. This is handled inside raw value reading because: * It's very easy to shift a few bits * It allows SCALE and INT_TIME to be

[PATCH 4/5] max44000: Expose ambient sensor scaling

This patch exposes ALSTIM as illuminance_integration_time and ALSPGA as illuminance_scale. Changing ALSTIM also changes the number of bits available in the data register. This is handled inside raw value reading because: * It's very easy to shift a few bits * It allows SCALE and INT_TIME to be

[PATCH 0/5] Support for max44000 Ambient and Infrared Proximity Sensor

The driver supports reporting illuminance and proximity (via raw reads or software-triggered) buffers and controling the scaling factors. There is no support for power management, events or reporting the IR/green channels separately. The device is always set in the ALS/PROX mode in order to

[PATCH 0/5] Support for max44000 Ambient and Infrared Proximity Sensor

The driver supports reporting illuminance and proximity (via raw reads or software-triggered) buffers and controling the scaling factors. There is no support for power management, events or reporting the IR/green channels separately. The device is always set in the ALS/PROX mode in order to

[PATCH 1/5] max44000: Initial commit

This just adds support for reporting illuminance with default settings. All default registers are written on probe because the device otherwise lacks a reset function. Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/Kconfig| 11 ++

[PATCH 1/5] max44000: Initial commit

This just adds support for reporting illuminance with default settings. All default registers are written on probe because the device otherwise lacks a reset function. Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/Kconfig| 11 ++ drivers/iio/light/Makefile | 1 +

[PATCH 6/9] rxrpc: Don't pass gfp around in incoming call handling functions

Don't pass gfp around in incoming call handling functions, but rather hard code it at the points where we actually need it since the value comes from within the rxrpc driver and is always the same. Signed-off-by: David Howells --- net/rxrpc/ar-accept.c |4 ++--

[PATCH 6/9] rxrpc: Don't pass gfp around in incoming call handling functions

Don't pass gfp around in incoming call handling functions, but rather hard code it at the points where we actually need it since the value comes from within the rxrpc driver and is always the same. Signed-off-by: David Howells --- net/rxrpc/ar-accept.c |4 ++-- net/rxrpc/ar-call.c

[PATCH 9/9] rxrpc: Create a null security type and get rid of conditional calls

Create a null security type for security index 0 and get rid of all conditional calls to the security operations. We expect normally to be using security, so this should be of little negative impact. Signed-off-by: David Howells --- net/rxrpc/Makefile|1 +

[PATCH 4/9] rxrpc: Static arrays of strings should be const char *const[]

Static arrays of strings should be const char *const[]. Signed-off-by: David Howells --- include/rxrpc/packet.h |2 -- net/rxrpc/ar-internal.h |2 +- net/rxrpc/misc.c|2 +- 3 files changed, 2 insertions(+), 4 deletions(-) diff --git

[PATCH 5/9] rxrpc: Differentiate local and remote abort codes in structs

In the rxrpc_connection and rxrpc_call structs, there's one field to hold the abort code, no matter whether that value was generated locally to be sent or was received from the peer via an abort packet. Split the abort code fields in two for cleanliness sake and add an error field to hold the

[PATCH 9/9] rxrpc: Create a null security type and get rid of conditional calls

Create a null security type for security index 0 and get rid of all conditional calls to the security operations. We expect normally to be using security, so this should be of little negative impact. Signed-off-by: David Howells --- net/rxrpc/Makefile|1 + net/rxrpc/ar-ack.c

[PATCH 4/9] rxrpc: Static arrays of strings should be const char *const[]

Static arrays of strings should be const char *const[]. Signed-off-by: David Howells --- include/rxrpc/packet.h |2 -- net/rxrpc/ar-internal.h |2 +- net/rxrpc/misc.c|2 +- 3 files changed, 2 insertions(+), 4 deletions(-) diff --git a/include/rxrpc/packet.h

[PATCH 5/9] rxrpc: Differentiate local and remote abort codes in structs

In the rxrpc_connection and rxrpc_call structs, there's one field to hold the abort code, no matter whether that value was generated locally to be sent or was received from the peer via an abort packet. Split the abort code fields in two for cleanliness sake and add an error field to hold the

[PATCH 7/9] rxrpc: Don't assume transport address family and size when using it

Don't assume transport address family and size when using the peer address to send a packet. Instead, use the start of the transport address rather than any particular element of the union and use the transport address length noted inside the sockaddr_rxrpc struct. This will be necessary when

[PATCH 8/9] rxrpc: Absorb the rxkad security module

Absorb the rxkad security module into the af_rxrpc module so that there's only one module file. This avoids a circular dependency whereby rxkad pins af_rxrpc and cached connections pin rxkad but can't be manually evicted (they will expire eventually and cease pinning). With this change, af_rxrpc

[PATCH 7/9] rxrpc: Don't assume transport address family and size when using it

Don't assume transport address family and size when using the peer address to send a packet. Instead, use the start of the transport address rather than any particular element of the union and use the transport address length noted inside the sockaddr_rxrpc struct. This will be necessary when

[PATCH 8/9] rxrpc: Absorb the rxkad security module

Absorb the rxkad security module into the af_rxrpc module so that there's only one module file. This avoids a circular dependency whereby rxkad pins af_rxrpc and cached connections pin rxkad but can't be manually evicted (they will expire eventually and cease pinning). With this change, af_rxrpc

[PATCH 3/9] rxrpc: Move some miscellaneous bits out into their own file

Move some miscellaneous bits out into their own file to make it easier to split the call handling. Signed-off-by: David Howells --- include/net/af_rxrpc.h |1 + net/rxrpc/Makefile |3 +- net/rxrpc/ar-ack.c | 68

[PATCH 3/9] rxrpc: Move some miscellaneous bits out into their own file

Move some miscellaneous bits out into their own file to make it easier to split the call handling. Signed-off-by: David Howells --- include/net/af_rxrpc.h |1 + net/rxrpc/Makefile |3 +- net/rxrpc/ar-ack.c | 68 net/rxrpc/ar-input.c

[PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

Disable a debugging statement that has been left enabled Signed-off-by: David Howells --- net/rxrpc/ar-ack.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/rxrpc/ar-ack.c b/net/rxrpc/ar-ack.c index 16d967075eaf..01a017a05f14 100644 ---

[PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.

Disable a debugging statement that has been left enabled Signed-off-by: David Howells --- net/rxrpc/ar-ack.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/rxrpc/ar-ack.c b/net/rxrpc/ar-ack.c index 16d967075eaf..01a017a05f14 100644 --- a/net/rxrpc/ar-ack.c +++

[PATCH 5/5] max44000: Initial triggered buffer support

Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/max44000.c | 63 1 file changed, 63 insertions(+) diff --git a/drivers/iio/light/max44000.c b/drivers/iio/light/max44000.c index e479c53..7b1f8bc 100644 ---

[PATCH 0/9] RxRPC: 2nd rewrite part 1

-rewrite Tagged thusly: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-rewrite-20160407 This is based on net-next/master David --- David Howells (9): afs: Wait for outstanding async calls before closing rxrpc socket rxrpc: Disable a debugging

[PATCH 0/9] RxRPC: 2nd rewrite part 1

-rewrite Tagged thusly: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-rewrite-20160407 This is based on net-next/master David --- David Howells (9): afs: Wait for outstanding async calls before closing rxrpc socket rxrpc: Disable a debugging

[PATCH 5/5] max44000: Initial triggered buffer support

Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/max44000.c | 63 1 file changed, 63 insertions(+) diff --git a/drivers/iio/light/max44000.c b/drivers/iio/light/max44000.c index e479c53..7b1f8bc 100644 --- a/drivers/iio/light/max44000.c +++

[PATCH 1/9] afs: Wait for outstanding async calls before closing rxrpc socket

The afs filesystem needs to wait for any outstanding asynchronous calls (such as FS.GiveUpCallBacks cleaning up the callbacks lodged with a server) to complete before closing the AF_RXRPC socket when unloading the module. This may occur if the module is removed too quickly after unmounting all

[PATCH 3/5] max44000: Support controlling LED current output

This is exposed as an output channel with "led" as an extend_name. Other sensors also have support for controlling an external LED. It's not clear that simply exposing an undecorated output channel is the correct approach. Signed-off-by: Crestez Dan Leonard ---

[PATCH 3/5] max44000: Support controlling LED current output

This is exposed as an output channel with "led" as an extend_name. Other sensors also have support for controlling an external LED. It's not clear that simply exposing an undecorated output channel is the correct approach. Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/max44000.c |

[PATCH 1/9] afs: Wait for outstanding async calls before closing rxrpc socket

The afs filesystem needs to wait for any outstanding asynchronous calls (such as FS.GiveUpCallBacks cleaning up the callbacks lodged with a server) to complete before closing the AF_RXRPC socket when unloading the module. This may occur if the module is removed too quickly after unmounting all

[PATCH 2/5] max44000: Initial support for proximity reading

The proximity sensor relies on sending pulses to an external IR led and it is disabled by default on powerup. The driver will enable it with a default power setting. Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/max44000.c | 61

[PATCH 2/5] max44000: Initial support for proximity reading

The proximity sensor relies on sending pulses to an external IR led and it is disabled by default on powerup. The driver will enable it with a default power setting. Signed-off-by: Crestez Dan Leonard --- drivers/iio/light/max44000.c | 61 1 file

Re: [PATCH] net: mark DECnet as broken

From: One Thousand Gnomes Date: Thu, 7 Apr 2016 15:01:20 +0100 > On Thu, 7 Apr 2016 09:22:43 +0200 > Vegard Nossum wrote: > >> There are NULL pointer dereference bugs in DECnet which can be triggered >> by unprivileged users and have been

Re: [PATCH] net: mark DECnet as broken

From: One Thousand Gnomes Date: Thu, 7 Apr 2016 15:01:20 +0100 > On Thu, 7 Apr 2016 09:22:43 +0200 > Vegard Nossum wrote: > >> There are NULL pointer dereference bugs in DECnet which can be triggered >> by unprivileged users and have been reported multiple times to LKML, >> however nobody

Re: [PATCH 0/3] mm/mmap.c: don't unmap the overlapping VMA(s)

On Mon, Apr 04, 2016 at 05:26:43PM +0200, Vlastimil Babka wrote: > On 04/04/2016 09:31 AM, Michal Hocko wrote: > >On Sat 02-04-16 21:17:31, Piotr Kwapulinski wrote: > >>Currently the mmap(MAP_FIXED) discards the overlapping part of the > >>existing VMA(s). > >>Introduce the new MAP_DONTUNMAP flag

Re: [PATCH 0/3] mm/mmap.c: don't unmap the overlapping VMA(s)

On Mon, Apr 04, 2016 at 05:26:43PM +0200, Vlastimil Babka wrote: > On 04/04/2016 09:31 AM, Michal Hocko wrote: > >On Sat 02-04-16 21:17:31, Piotr Kwapulinski wrote: > >>Currently the mmap(MAP_FIXED) discards the overlapping part of the > >>existing VMA(s). > >>Introduce the new MAP_DONTUNMAP flag

Re: [PATCH] arm/arm64/irqchip/pci: select PCI_MSI instead of depending on it

On Thu, Mar 17, 2016 at 11:52:49AM +0100, Arnd Bergmann wrote: > The PCI_MSI symbol is used inconsistently throughout the tree, > with some drivers using 'select' and others using 'depends on', > or using conditional selects. This keeps causing problems, > and the latest one is a result of

Re: [PATCH] arm/arm64/irqchip/pci: select PCI_MSI instead of depending on it

On Thu, Mar 17, 2016 at 11:52:49AM +0100, Arnd Bergmann wrote: > The PCI_MSI symbol is used inconsistently throughout the tree, > with some drivers using 'select' and others using 'depends on', > or using conditional selects. This keeps causing problems, > and the latest one is a result of

Re: [kernel-hardening] Re: [RFC v1] mm: SLAB freelist randomization

On mer., 2016-04-06 at 14:45 -0700, Kees Cook wrote: > > This security feature reduces the predictability of > > the kernel slab allocator against heap overflows. > > I would add "... rendering attacks much less stable." And if you can > find a specific example exploit that is foiled by this, I

Re: [kernel-hardening] Re: [RFC v1] mm: SLAB freelist randomization

On mer., 2016-04-06 at 14:45 -0700, Kees Cook wrote: > > This security feature reduces the predictability of > > the kernel slab allocator against heap overflows. > > I would add "... rendering attacks much less stable." And if you can > find a specific example exploit that is foiled by this, I

Re: [PATCH 0/3] mm/mmap.c: don't unmap the overlapping VMA(s)

On Mon, Apr 04, 2016 at 05:26:43PM +0200, Vlastimil Babka wrote: > On 04/04/2016 09:31 AM, Michal Hocko wrote: > >On Sat 02-04-16 21:17:31, Piotr Kwapulinski wrote: > >>Currently the mmap(MAP_FIXED) discards the overlapping part of the > >>existing VMA(s). > >>Introduce the new MAP_DONTUNMAP flag

Re: [PATCH 0/3] mm/mmap.c: don't unmap the overlapping VMA(s)

On Mon, Apr 04, 2016 at 05:26:43PM +0200, Vlastimil Babka wrote: > On 04/04/2016 09:31 AM, Michal Hocko wrote: > >On Sat 02-04-16 21:17:31, Piotr Kwapulinski wrote: > >>Currently the mmap(MAP_FIXED) discards the overlapping part of the > >>existing VMA(s). > >>Introduce the new MAP_DONTUNMAP flag

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 4, 2016 at 6:29 PM, Eric W. Biederman wrote: > > In practice I expect the permission checks are a non-issue as the > permissions on /dev/ptmx and /dev/pts/ptmx are always 0666. So I think this is still entirely wrongheaded, and thinking about the problem the

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 4, 2016 at 6:29 PM, Eric W. Biederman wrote: > > In practice I expect the permission checks are a non-issue as the > permissions on /dev/ptmx and /dev/pts/ptmx are always 0666. So I think this is still entirely wrongheaded, and thinking about the problem the wrong way around. The

Re: [PATCH 2/3] percpu_stats: Simple per-cpu statistics count helper functions

Hello, Waiman. On Thu, Apr 07, 2016 at 11:58:13AM -0400, Waiman Long wrote: > We can certainly make it watertight. However, that will certainly require > adding performance overhead in the percpu stats update fast path which I am > not willing to pay. There are multiple options depending on the

Re: [PATCH 2/3] percpu_stats: Simple per-cpu statistics count helper functions

Hello, Waiman. On Thu, Apr 07, 2016 at 11:58:13AM -0400, Waiman Long wrote: > We can certainly make it watertight. However, that will certainly require > adding performance overhead in the percpu stats update fast path which I am > not willing to pay. There are multiple options depending on the

Re: [PATCH 2/2] pci, acpi: free IO resource during shutdown

Hi Sinan, On Mon, Mar 07, 2016 at 05:21:50PM -0500, Sinan Kaya wrote: > The ACPI PCI driver is leaking out memory mappings > when a slot is removed. Upon insertion following a > removal, we are hitting a BUG statement. Second call > to the remap API hits a bug statement because the area is >

[PATCH] livepatch: robustify klp_register_patch() API error checking

From: Jiri Kosina Commit 425595a7fc20 ("livepatch: reuse module loader code to write relocations") adds a possibility of dereferncing pointers supplied by the consumer of the livepatch API before sanity (NULL) checking them (patch and patch->mod). Spotted by smatch tool.

<    5   6   7   8   9   10   11   12   13   14   >