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. Reported-by: Dan

[PATCH 1/1] input: pwm-beeper: add feature to set volume via sysfs

Make the driver accept different volume levels via sysfs. This can be helpful if the beep/bell sound intensity needs to be adapted to the environment of the device. The number of volume levels available and their values can be specified via device tree (similar to pwm-backlight). This patch was

[PATCH 1/1] input: pwm-beeper: add feature to set volume via sysfs

Make the driver accept different volume levels via sysfs. This can be helpful if the beep/bell sound intensity needs to be adapted to the environment of the device. The number of volume levels available and their values can be specified via device tree (similar to pwm-backlight). This patch was

Re: [PATCH 1/2] pci: add pci_unmap_iospace function for PCI_IOBASE

Hi Sinan, On Mon, Mar 07, 2016 at 05:21:49PM -0500, Sinan Kaya wrote: > The PCI_IOBASE needs to be released after hotplug removal so that it can be > re-added back by the pci_remap_iospace function during insertion. > > Adding unmap function to follow IO remap function. > > Signed-off-by: Sinan

Re: [PATCH 1/2] pci: add pci_unmap_iospace function for PCI_IOBASE

Hi Sinan, On Mon, Mar 07, 2016 at 05:21:49PM -0500, Sinan Kaya wrote: > The PCI_IOBASE needs to be released after hotplug removal so that it can be > re-added back by the pci_remap_iospace function during insertion. > > Adding unmap function to follow IO remap function. > > Signed-off-by: Sinan

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

- On Apr 7, 2016, at 8:25 AM, Peter Zijlstra pet...@infradead.org wrote: > On Thu, Apr 07, 2016 at 02:03:53PM +0200, Florian Weimer wrote: >> > struct tlabi { >> >union { >> >__u8[64] __foo; >> >struct { >> >/* fields go here */ >> >

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

- On Apr 7, 2016, at 8:25 AM, Peter Zijlstra pet...@infradead.org wrote: > On Thu, Apr 07, 2016 at 02:03:53PM +0200, Florian Weimer wrote: >> > struct tlabi { >> >union { >> >__u8[64] __foo; >> >struct { >> >/* fields go here */ >> >

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

On 04/06/2016 06:54 PM, Tejun Heo wrote: Hello, On Wed, Apr 06, 2016 at 05:51:45PM -0400, Waiman Long wrote: + /* +* If a statistics count is in the middle of being updated, it +* is possible that the above clearing may not work. So we need +* to double check

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

On 04/06/2016 06:54 PM, Tejun Heo wrote: Hello, On Wed, Apr 06, 2016 at 05:51:45PM -0400, Waiman Long wrote: + /* +* If a statistics count is in the middle of being updated, it +* is possible that the above clearing may not work. So we need +* to double check

Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

On Thu, Apr 07, 2016 at 03:11:53PM +0300, Octavian Purdila wrote: > On Wed, Apr 6, 2016 at 3:01 AM, Mark Rutland wrote: > > On Tue, Apr 05, 2016 at 11:09:34PM +0300, Octavian Purdila wrote: > >> On Tue, Apr 5, 2016 at 9:16 PM, Mark Rutland wrote: > >>

Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

On Thu, Apr 07, 2016 at 03:11:53PM +0300, Octavian Purdila wrote: > On Wed, Apr 6, 2016 at 3:01 AM, Mark Rutland wrote: > > On Tue, Apr 05, 2016 at 11:09:34PM +0300, Octavian Purdila wrote: > >> On Tue, Apr 5, 2016 at 9:16 PM, Mark Rutland wrote: > >> > * The firmware is to some extent expected

Re: [PATCH] arm64: CONFIG_DEVPORT should not be used when PCI is being used

On 04/07/2016 01:26 AM, Geert Uytterhoeven wrote: > On Thu, Apr 7, 2016 at 2:18 AM, Greg Kroah-Hartman > wrote: >> On Wed, Apr 06, 2016 at 03:27:20PM -0600, Al Stone wrote: >>> On arm64 systems, using /dev/port does not really make sense; this is >>> historically used

Re: [PATCH] arm64: CONFIG_DEVPORT should not be used when PCI is being used

On 04/07/2016 01:26 AM, Geert Uytterhoeven wrote: > On Thu, Apr 7, 2016 at 2:18 AM, Greg Kroah-Hartman > wrote: >> On Wed, Apr 06, 2016 at 03:27:20PM -0600, Al Stone wrote: >>> On arm64 systems, using /dev/port does not really make sense; this is >>> historically used for other architectures to

Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD (drivers/block/skd*)

On Tue, Apr 05, 2016 at 12:45:08AM +0100, Al Viro wrote: > AFAICS, what we need there is simply > nr_pages = iov_iter_npages(iter); > alignment = iov_iter_alignment(iter); > if (alignment & (queue_dma_alignment(q) | q->dma_pad_mask)) > copy = true; > and I really

Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD (drivers/block/skd*)

On Tue, Apr 05, 2016 at 12:45:08AM +0100, Al Viro wrote: > AFAICS, what we need there is simply > nr_pages = iov_iter_npages(iter); > alignment = iov_iter_alignment(iter); > if (alignment & (queue_dma_alignment(q) | q->dma_pad_mask)) > copy = true; > and I really

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

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 individual values into the TLABI > >>

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

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 individual values into the TLABI > >> thing, shove in a pointer:

Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD (drivers/block/skd*)

On Mon, Apr 04, 2016 at 06:16:12PM +0100, Al Viro wrote: > Another fun question: should the normal sg_io() copy the buffer in on > SG_DXFER_TO_FROM_DEV? Right now it doesn't; in !copy case (when it goes > through bio_map_user_iov()) the effect is achieved simply by doing the > read into the pages

Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD (drivers/block/skd*)

On Mon, Apr 04, 2016 at 06:16:12PM +0100, Al Viro wrote: > Another fun question: should the normal sg_io() copy the buffer in on > SG_DXFER_TO_FROM_DEV? Right now it doesn't; in !copy case (when it goes > through bio_map_user_iov()) the effect is achieved simply by doing the > read into the pages

Re: Boot failure when using NFS on OMAP based evms

Currently linux-next is failing to boot via NFS on my AM335x GP evm, AM437x GP evm and Beagle X15. I bisected the problem down to the commit "udp: remove headers from UDP packets before queueing". >>> >>> Thanks for the report, and apologies for breaking your configuration. >>> I

Re: Boot failure when using NFS on OMAP based evms

Currently linux-next is failing to boot via NFS on my AM335x GP evm, AM437x GP evm and Beagle X15. I bisected the problem down to the commit "udp: remove headers from UDP packets before queueing". >>> >>> Thanks for the report, and apologies for breaking your configuration. >>> I

Re: [PATCH v3] drm/gma500: fix double freeing

On Wednesday 09 December 2015 05:50 PM, Patrik Jakobsson wrote: On Wed, Dec 9, 2015 at 12:53 PM, Sudip Mukherjee wrote: On Thu, Oct 08, 2015 at 06:17:48PM +0530, Sudip Mukherjee wrote: We are allocating backing using psbfb_alloc() and so backing->stolen is always

Re: [PATCH v3] drm/gma500: fix double freeing

On Wednesday 09 December 2015 05:50 PM, Patrik Jakobsson wrote: On Wed, Dec 9, 2015 at 12:53 PM, Sudip Mukherjee wrote: On Thu, Oct 08, 2015 at 06:17:48PM +0530, Sudip Mukherjee wrote: We are allocating backing using psbfb_alloc() and so backing->stolen is always true. So we were freeing

Re: [PATCH 1/3] perf tools: Introduce trim function

On Thursday, April 7, 2016 4:03:21 PM CEST Jiri Olsa wrote: > On Thu, Apr 07, 2016 at 10:50:47AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Thu, Apr 07, 2016 at 09:11:11AM +0200, Jiri Olsa escreveu: > > > To be used in cases for both sides trim. > > > > > > Link: > > >

Re: [PATCH 1/3] perf tools: Introduce trim function

On Thursday, April 7, 2016 4:03:21 PM CEST Jiri Olsa wrote: > On Thu, Apr 07, 2016 at 10:50:47AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Thu, Apr 07, 2016 at 09:11:11AM +0200, Jiri Olsa escreveu: > > > To be used in cases for both sides trim. > > > > > > Link: > > >

Re: [PATCH v9 2/4] tpm: Proxy driver for supporting multiple emulated TPMs

On 04/07/2016 08:35 AM, Jarkko Sakkinen wrote: On Tue, Mar 29, 2016 at 02:19:12PM -0400, Stefan Berger wrote: This patch implements a proxy driver for supporting multiple emulated TPMs in a system. The driver implements a device /dev/vtpmx that is used to created a client device pair /dev/tpmX

Re: [PATCH v9 2/4] tpm: Proxy driver for supporting multiple emulated TPMs

On 04/07/2016 08:35 AM, Jarkko Sakkinen wrote: On Tue, Mar 29, 2016 at 02:19:12PM -0400, Stefan Berger wrote: This patch implements a proxy driver for supporting multiple emulated TPMs in a system. The driver implements a device /dev/vtpmx that is used to created a client device pair /dev/tpmX

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Thu, 7 Apr 2016, Josh Poimboeuf wrote: > > > - try ftrace handler switching idea from v1 cover letter [ ... ] > > We probably should not check the stack in atomic context > > Can you elaborate why not? I admittedly forgot what the "ftrace handler switching idea" is, and am not sure where

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Thu, 7 Apr 2016, Josh Poimboeuf wrote: > > > - try ftrace handler switching idea from v1 cover letter [ ... ] > > We probably should not check the stack in atomic context > > Can you elaborate why not? I admittedly forgot what the "ftrace handler switching idea" is, and am not sure where

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

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 individual values into the TLABI >> thing, shove in a pointer: >> >> struct commit_info { >> u64

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

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 individual values into the TLABI >> thing, shove in a pointer: >> >> struct commit_info { >> u64 post_commit_rip; >> u32 cpu; >>

Re: [PATCH 06/14] coresight: tmc: making prepare/unprepare functions generic

On 22/03/16 20:23, Mathieu Poirier wrote: Dealing with HW related matters in tmc_read_prepare/unprepare becomes convoluted when many cases need to be handled distinctively. As such moving processing related to HW setup to individual driver files and keep the core driver generic. Signed-off-by:

Re: [PATCH 06/14] coresight: tmc: making prepare/unprepare functions generic

On 22/03/16 20:23, Mathieu Poirier wrote: Dealing with HW related matters in tmc_read_prepare/unprepare becomes convoluted when many cases need to be handled distinctively. As such moving processing related to HW setup to individual driver files and keep the core driver generic. Signed-off-by:

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

On Thu, Apr 07, 2016 at 05:24:32PM +0200, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote: > > That way we could take an async signal, handle it, and resume, even in > > the middle of a commit, without aborting. Of course, if the signal > > hander tried to

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

On Thu, Apr 07, 2016 at 05:24:32PM +0200, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote: > > That way we could take an async signal, handle it, and resume, even in > > the middle of a commit, without aborting. Of course, if the signal > > hander tried to

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

Signed-off-by: Christoph Hellwig Reported-by: David Smith Tested-by: David Smith --- arch/x86/entry/syscalls/syscall_32.tbl | 4 ++-- arch/x86/entry/syscalls/syscall_64.tbl | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git

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

Signed-off-by: Christoph Hellwig Reported-by: David Smith Tested-by: David Smith --- arch/x86/entry/syscalls/syscall_32.tbl | 4 ++-- arch/x86/entry/syscalls/syscall_64.tbl | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/syscalls/syscall_32.tbl

[PATCH] usb: wusbcore: remove unreachable code

The call to wusb_dev_sysfs_rm() which is just after return will never be executed. On checking the code, wusb_dev_sysfs_add() is the last one to be executed so even if that fails we do not need wusb_dev_sysfs_rm() in the error path. Signed-off-by: Sudip Mukherjee

[PATCH] usb: wusbcore: remove unreachable code

The call to wusb_dev_sysfs_rm() which is just after return will never be executed. On checking the code, wusb_dev_sysfs_add() is the last one to be executed so even if that fails we do not need wusb_dev_sysfs_rm() in the error path. Signed-off-by: Sudip Mukherjee ---

Re: [RESEND PATCH v7 1/6] mfd: cros_ec: Add MKBP event support

On Tue, 05 Apr 2016, Tomeu Vizoso wrote: > From: Vic Yang > > Newer revisions of the ChromeOS EC add more events besides the keyboard > ones. So handle interrupts in the MFD driver and let consumers register > for notifications for the events they might care. > > To keep

Re: [RESEND PATCH v7 1/6] mfd: cros_ec: Add MKBP event support

On Tue, 05 Apr 2016, Tomeu Vizoso wrote: > From: Vic Yang > > Newer revisions of the ChromeOS EC add more events besides the keyboard > ones. So handle interrupts in the MFD driver and let consumers register > for notifications for the events they might care. > > To keep backward

Re: [RFC v1] mm: SLAB freelist randomization

Thanks for the feedback Kees. I am preparing another RFC version. For the config, I plan on creating an equivalent option for SLUB. Both can benefit from randomizing their freelist order. Thomas On Wed, Apr 6, 2016 at 2:45 PM Kees Cook wrote: > > On Wed, Apr 6, 2016 at

Re: [RFC v1] mm: SLAB freelist randomization

Thanks for the feedback Kees. I am preparing another RFC version. For the config, I plan on creating an equivalent option for SLUB. Both can benefit from randomizing their freelist order. Thomas On Wed, Apr 6, 2016 at 2:45 PM Kees Cook wrote: > > On Wed, Apr 6, 2016 at 12:35 PM, Thomas Garnier

[PATCH 08/11] ia64, rwsem: provide __down_write_killable

From: Michal Hocko Introduce ___down_write for the fast path and reuse it for __down_write resp. __down_write_killable each using the respective generic slow path (rwsem_down_write_failed resp. rwsem_down_write_failed_killable). Signed-off-by: Michal Hocko ---

[PATCH 08/11] ia64, rwsem: provide __down_write_killable

From: Michal Hocko Introduce ___down_write for the fast path and reuse it for __down_write resp. __down_write_killable each using the respective generic slow path (rwsem_down_write_failed resp. rwsem_down_write_failed_killable). Signed-off-by: Michal Hocko --- arch/ia64/include/asm/rwsem.h |

[PATCH] KVM: new maintainer on the block

Avi has kept Gleb busy enough, and Radim has been helping me for a while, so let's "reward" him with an entry in MAINTAINERS. Acked-by: Gleb Natapov Cc: Radim Krčmář --- Radim, please commit this yourself to kvm/master and kvm/next please!

[PATCH] KVM: new maintainer on the block

Avi has kept Gleb busy enough, and Radim has been helping me for a while, so let's "reward" him with an entry in MAINTAINERS. Acked-by: Gleb Natapov Cc: Radim Krčmář --- Radim, please commit this yourself to kvm/master and kvm/next please! Signed-off-by: Paolo Bonzini ---

Re: [PATCH] cpu/hotplug: fix rollback during error-out in __cpu_disable()

On 04/06/2016 09:51 PM, Heiko Carstens wrote: > This fixes the issue that a second cpu_down() will take forever, if > __cpu_disable() fails. Yes. But even without the second take down your CPU isn't complete up. > However it does not fix the issue that CPU_DOWN_FAILED will be seen on a >

[PATCH 04/11] sh, rwsem: drop superfluous arch specific implementation

From: Michal Hocko since "locking, rwsem: drop explicit memory barriers" the arch specific code is basically same as the the generic one so we can drop the superfluous code. Suggested-by: Davidlohr Bueso Signed-off-by: Michal Hocko ---

Re: [PATCH] cpu/hotplug: fix rollback during error-out in __cpu_disable()

On 04/06/2016 09:51 PM, Heiko Carstens wrote: > This fixes the issue that a second cpu_down() will take forever, if > __cpu_disable() fails. Yes. But even without the second take down your CPU isn't complete up. > However it does not fix the issue that CPU_DOWN_FAILED will be seen on a >

[PATCH 04/11] sh, rwsem: drop superfluous arch specific implementation

From: Michal Hocko since "locking, rwsem: drop explicit memory barriers" the arch specific code is basically same as the the generic one so we can drop the superfluous code. Suggested-by: Davidlohr Bueso Signed-off-by: Michal Hocko --- arch/sh/include/asm/Kbuild | 1 +

[PATCH 06/11] locking, rwsem: introduce basis for down_write_killable

From: Michal Hocko Introduce a generic implementation necessary for down_write_killable. This is a trivial extension of the already existing down_write call which can be interrupted by SIGKILL. This patch doesn't provide down_write_killable yet because arches have to provide

[PATCH 06/11] locking, rwsem: introduce basis for down_write_killable

From: Michal Hocko Introduce a generic implementation necessary for down_write_killable. This is a trivial extension of the already existing down_write call which can be interrupted by SIGKILL. This patch doesn't provide down_write_killable yet because arches have to provide the necessary

[PATCH 03/11] xtensa, rwsem: drop superfluous arch specific implementation

From: Michal Hocko since "locking, rwsem: drop explicit memory barriers" the arch specific code is basically same as the the generic one so we can drop the superfluous code. Suggested-by: Davidlohr Bueso Acked-by: Max Filippov

[PATCH 03/11] xtensa, rwsem: drop superfluous arch specific implementation

From: Michal Hocko since "locking, rwsem: drop explicit memory barriers" the arch specific code is basically same as the the generic one so we can drop the superfluous code. Suggested-by: Davidlohr Bueso Acked-by: Max Filippov Signed-off-by: Michal Hocko --- arch/xtensa/include/asm/Kbuild

[PATCH 11/11] locking, rwsem: provide down_write_killable

From: Michal Hocko Now that all the architectures implement the necessary glue code we can introduce down_write_killable. The only difference wrt. regular down_write is that the slow path waits in TASK_KILLABLE state and the interruption by the fatal signal is reported as -EINTR

[PATCH 11/11] locking, rwsem: provide down_write_killable

From: Michal Hocko Now that all the architectures implement the necessary glue code we can introduce down_write_killable. The only difference wrt. regular down_write is that the slow path waits in TASK_KILLABLE state and the interruption by the fatal signal is reported as -EINTR to the caller.

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

On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote: > What I meant was: rather than shoving individual values into the TLABI > thing, shove in a pointer: > > struct commit_info { > u64 post_commit_rip; > u32 cpu; > u64 *event; > // whatever else; > }; > > and then put a

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

On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote: > What I meant was: rather than shoving individual values into the TLABI > thing, shove in a pointer: > > struct commit_info { > u64 post_commit_rip; > u32 cpu; > u64 *event; > // whatever else; > }; > > and then put a

[PATCH 02/11] locking, rwsem: drop explicit memory barriers

From: Michal Hocko sh and xtensa seem to be the only architectures which use explicit memory barriers for rw_semaphore operations even though they are not really needed because there is the full memory barrier is always implied by atomic_{inc,dec,add,sub}_return resp. cmpxchg.

[PATCH 02/11] locking, rwsem: drop explicit memory barriers

From: Michal Hocko sh and xtensa seem to be the only architectures which use explicit memory barriers for rw_semaphore operations even though they are not really needed because there is the full memory barrier is always implied by atomic_{inc,dec,add,sub}_return resp. cmpxchg. Remove them.

Re: Re: Re: PG_reserved and compound pages

On Thu 07-04-16 15:45:02, Frank Mehnert wrote: > On Wednesday 06 April 2016 17:33:43 Michal Hocko wrote: [...] > > Do you map your pages to the userspace? If yes then vma with VM_IO or > > VM_PFNMAP should keep any attempt away from those pages. > > Yes, such memory objects are also mapped to

Re: Re: Re: PG_reserved and compound pages

On Thu 07-04-16 15:45:02, Frank Mehnert wrote: > On Wednesday 06 April 2016 17:33:43 Michal Hocko wrote: [...] > > Do you map your pages to the userspace? If yes then vma with VM_IO or > > VM_PFNMAP should keep any attempt away from those pages. > > Yes, such memory objects are also mapped to

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

On 04/07/2016 05:39 PM, Andy Lutomirski wrote: On Apr 7, 2016 5:12 AM, "Dmitry Safonov" wrote: On 04/06/2016 09:04 PM, Andy Lutomirski wrote: [cc Dave Hansen for MPX] On Apr 6, 2016 9:30 AM, "Dmitry Safonov" wrote: Now each process that runs

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

On 04/07/2016 05:39 PM, Andy Lutomirski wrote: On Apr 7, 2016 5:12 AM, "Dmitry Safonov" wrote: On 04/06/2016 09:04 PM, Andy Lutomirski wrote: [cc Dave Hansen for MPX] On Apr 6, 2016 9:30 AM, "Dmitry Safonov" wrote: Now each process that runs natively on x86_64 may execute 32-bit code by

Re: [PATCH RFC] select_idle_sibling experiments

On Tue, Apr 05, 2016 at 02:08:22PM -0400, Chris Mason wrote: > Hi everyone, > > We're porting the fb kernel up to 4.5, and one of our last few out-of-tree > patches is a hack to try harder to find idle cpus when waking up tasks. > This helps in pretty much every workload we run, mostly because

Re: [PATCH RFC] select_idle_sibling experiments

On Tue, Apr 05, 2016 at 02:08:22PM -0400, Chris Mason wrote: > Hi everyone, > > We're porting the fb kernel up to 4.5, and one of our last few out-of-tree > patches is a hack to try harder to find idle cpus when waking up tasks. > This helps in pretty much every workload we run, mostly because

[PATCH 07/11] alpha, rwsem: provide __down_write_killable

From: Michal Hocko Introduce ___down_write for the fast path and reuse it for __down_write resp. __down_write_killable each using the respective generic slow path (rwsem_down_write_failed resp. rwsem_down_write_failed_killable). Signed-off-by: Michal Hocko ---

[PATCH 0/11] introduce down_write_killable for rw_semaphore v3

Hi, the following patchset implements a killable variant of write lock for rw_semaphore. My usecase is to turn as many mmap_sem write users to use a killable variant which will be helpful for the oom_reaper merged in 4.6-rc1 (aac453635549 ("mm, oom: introduce oom reaper")) to asynchronously tear

[PATCH 07/11] alpha, rwsem: provide __down_write_killable

From: Michal Hocko Introduce ___down_write for the fast path and reuse it for __down_write resp. __down_write_killable each using the respective generic slow path (rwsem_down_write_failed resp. rwsem_down_write_failed_killable). Signed-off-by: Michal Hocko --- arch/alpha/include/asm/rwsem.h |

[PATCH 0/11] introduce down_write_killable for rw_semaphore v3

Hi, the following patchset implements a killable variant of write lock for rw_semaphore. My usecase is to turn as many mmap_sem write users to use a killable variant which will be helpful for the oom_reaper merged in 4.6-rc1 (aac453635549 ("mm, oom: introduce oom reaper")) to asynchronously tear

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

From: Michal Hocko which uses the same fast path as __down_write except it falls back to call_rwsem_down_write_failed_killable slow path and return -EINTR if killed. To prevent from code duplication extract the skeleton of __down_write into a helper macro which just takes the

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

From: Michal Hocko which uses the same fast path as __down_write except it falls back to call_rwsem_down_write_failed_killable slow path and return -EINTR if killed. To prevent from code duplication extract the skeleton of __down_write into a helper macro which just takes the semaphore and the

[PATCH 09/11] s390, rwsem: provide __down_write_killable

From: Michal Hocko Introduce ___down_write for the fast path and reuse it for __down_write resp. __down_write_killable each using the respective generic slow path (rwsem_down_write_failed resp. rwsem_down_write_failed_killable). Signed-off-by: Michal Hocko ---

[PATCH 01/11] locking, rwsem: get rid of __down_write_nested

From: Michal Hocko This is no longer used anywhere and all callers (__down_write) use 0 as a subclass. Ditch __down_write_nested to make the code easier to follow. This shouldn't introduce any functional change. Acked-by: Davidlohr Bueso Signed-off-by:

[PATCH 09/11] s390, rwsem: provide __down_write_killable

From: Michal Hocko Introduce ___down_write for the fast path and reuse it for __down_write resp. __down_write_killable each using the respective generic slow path (rwsem_down_write_failed resp. rwsem_down_write_failed_killable). Signed-off-by: Michal Hocko --- arch/s390/include/asm/rwsem.h |

[PATCH 01/11] locking, rwsem: get rid of __down_write_nested

From: Michal Hocko This is no longer used anywhere and all callers (__down_write) use 0 as a subclass. Ditch __down_write_nested to make the code easier to follow. This shouldn't introduce any functional change. Acked-by: Davidlohr Bueso Signed-off-by: Michal Hocko ---

Re: [PATCH] sdhci: wakeup from runtime PM

On Thu, Apr 07, 2016 at 11:11:08AM +0200, Ulf Hansson wrote: > On 5 April 2016 at 14:40, Adrian Hunter wrote: > > On 25/03/16 18:05, Ludovic Desroches wrote: > >> Hi, > >> > >> When not using the SDHCI controller, it is logical to save power by > >> suspending > >> it.

[PATCH 05/11] sparc, rwsem: drop superfluous arch specific implementation

From: Michal Hocko sparc basically reuses generic implementation of rwsem so we can reuse the code rather than duplicate it. Signed-off-by: Michal Hocko --- arch/sparc/include/asm/Kbuild | 1 + arch/sparc/include/asm/rwsem.h | 119

Re: [PATCH] sdhci: wakeup from runtime PM

On Thu, Apr 07, 2016 at 11:11:08AM +0200, Ulf Hansson wrote: > On 5 April 2016 at 14:40, Adrian Hunter wrote: > > On 25/03/16 18:05, Ludovic Desroches wrote: > >> Hi, > >> > >> When not using the SDHCI controller, it is logical to save power by > >> suspending > >> it. The issue is that SDHCI

[PATCH 05/11] sparc, rwsem: drop superfluous arch specific implementation

From: Michal Hocko sparc basically reuses generic implementation of rwsem so we can reuse the code rather than duplicate it. Signed-off-by: Michal Hocko --- arch/sparc/include/asm/Kbuild | 1 + arch/sparc/include/asm/rwsem.h | 119 - 2 files changed,

Re: The most insane proposal in regard to the Linux kernel development

On Thu, Apr 07, 2016 at 02:01:03PM +0500, Artem S. Tashkinov wrote: > On 2016-04-07 01:05, Greg KH wrote: > > On Sat, Apr 02, 2016 at 05:43:47PM +0500, Artem S. Tashkinov wrote: > > > One very big justification of this proposal is that core Linux > > > development > > > (I'm talking about various

Re: The most insane proposal in regard to the Linux kernel development

On Thu, Apr 07, 2016 at 02:01:03PM +0500, Artem S. Tashkinov wrote: > On 2016-04-07 01:05, Greg KH wrote: > > On Sat, Apr 02, 2016 at 05:43:47PM +0500, Artem S. Tashkinov wrote: > > > One very big justification of this proposal is that core Linux > > > development > > > (I'm talking about various

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Thu, Apr 07, 2016 at 02:10:30PM +0200, Petr Mladek wrote: > On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote: > > TODO: > > - try ftrace handler switching idea from v1 cover letter > > I have had a discussion about it with Mirek. This would help with > kthreads. If they are sleeping in a

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Thu, Apr 07, 2016 at 02:10:30PM +0200, Petr Mladek wrote: > On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote: > > TODO: > > - try ftrace handler switching idea from v1 cover letter > > I have had a discussion about it with Mirek. This would help with > kthreads. If they are sleeping in a

Re: [PATCH] x86/hpet: Reduce HPET counter read contention

On 04/07/2016 12:58 AM, Andy Lutomirski wrote: On Wed, Apr 6, 2016 at 7:02 AM, Waiman Long wrote: On a large system with many CPUs, using HPET as the clock source can have a significant impact on the overall system performance because of the following reasons: 1) There

Re: [PATCH] x86/hpet: Reduce HPET counter read contention

On 04/07/2016 12:58 AM, Andy Lutomirski wrote: On Wed, Apr 6, 2016 at 7:02 AM, Waiman Long wrote: On a large system with many CPUs, using HPET as the clock source can have a significant impact on the overall system performance because of the following reasons: 1) There is a single HPET

Re: [LINUX PATCH v2 2/3] mtd:m25p80: Assigned number of dummy cycles to dummy_cycles.

Hi L, [auto build test ERROR on spi/for-next] [also build test ERROR on v4.6-rc2 next-20160407] [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/P-L-Sai-Krishna/spi-Added-dummy_cycle-entry

Re: [LINUX PATCH v2 2/3] mtd:m25p80: Assigned number of dummy cycles to dummy_cycles.

Hi L, [auto build test ERROR on spi/for-next] [also build test ERROR on v4.6-rc2 next-20160407] [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/P-L-Sai-Krishna/spi-Added-dummy_cycle-entry

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

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. Thanks, Bart.

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

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. Thanks, Bart.

Re: [LINUX PATCH v2 1/3] spi: Added dummy_cycle entry in the spi_transfer structure.

Hi all, Le 07/04/2016 16:39, P L Sai Krishna a écrit : > This patch adds dummy_cycles entry in the spi_transfer structure. > len field in the transfer structure contains dummy bytes along with > actual data bytes, controllers which requires dummy bytes use len > field and simply Ignore the

Re: [LINUX PATCH v2 1/3] spi: Added dummy_cycle entry in the spi_transfer structure.

Hi all, Le 07/04/2016 16:39, P L Sai Krishna a écrit : > This patch adds dummy_cycles entry in the spi_transfer structure. > len field in the transfer structure contains dummy bytes along with > actual data bytes, controllers which requires dummy bytes use len > field and simply Ignore the

perf report --no-children chopping off tracepoint fields

Hi Namhyung, If I do: # perf record --call dwarf -p 2519 -e syscalls:sys_enter_open And then run plain 'perf report' I get this on the TUI, perfect: Samples: 1 of event 'syscalls:sys_enter_open', Event count (approx.): 1 Children Self Trace output + 100.00% 100.00%

perf report --no-children chopping off tracepoint fields

Hi Namhyung, If I do: # perf record --call dwarf -p 2519 -e syscalls:sys_enter_open And then run plain 'perf report' I get this on the TUI, perfect: Samples: 1 of event 'syscalls:sys_enter_open', Event count (approx.): 1 Children Self Trace output + 100.00% 100.00%

[PATCH 02/10] isa: Implement the max_num_isa_dev macro

max_num_isa_dev is a macro to determine the maximum possible number of ISA devices which may be registered in the I/O port address space given the address extent of the ISA devices. The highest base address possible for an ISA device is 0x3FF; this results in 1024 possible base addresses.

Re: Problems with commit a770d946371e ("gpio: pxa: add pin control gpio direction and request")

On 03/27/2016 01:29 PM, Robert Jarzmik wrote: Guenter Roeck writes: Hi, Hi Guenter, when trying pxa_defconfig with various pxa270 and pxa255 qemu targets, I noticed that the gpio pin direction is no longer set. Bisect points to commit a770d946371e ("gpio: pxa: add pin

[PATCH 02/10] isa: Implement the max_num_isa_dev macro

max_num_isa_dev is a macro to determine the maximum possible number of ISA devices which may be registered in the I/O port address space given the address extent of the ISA devices. The highest base address possible for an ISA device is 0x3FF; this results in 1024 possible base addresses.

Re: Problems with commit a770d946371e ("gpio: pxa: add pin control gpio direction and request")

On 03/27/2016 01:29 PM, Robert Jarzmik wrote: Guenter Roeck writes: Hi, Hi Guenter, when trying pxa_defconfig with various pxa270 and pxa255 qemu targets, I noticed that the gpio pin direction is no longer set. Bisect points to commit a770d946371e ("gpio: pxa: add pin control gpio

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