Re: [PATCH 00/10]block-throttle: add low/high limit

On Fri, May 13, 2016 at 03:59:50PM -0700, Shaohua Li wrote: > On Fri, May 13, 2016 at 03:12:45PM -0400, Vivek Goyal wrote: > > On Tue, May 10, 2016 at 05:16:30PM -0700, Shaohua Li wrote: > > > Hi, > > > > > > This patch set adds low/high limit for blk-throttle cgroup. The interface > > > is > >

Re: [PATCH 00/10]block-throttle: add low/high limit

On Fri, May 13, 2016 at 03:59:50PM -0700, Shaohua Li wrote: > On Fri, May 13, 2016 at 03:12:45PM -0400, Vivek Goyal wrote: > > On Tue, May 10, 2016 at 05:16:30PM -0700, Shaohua Li wrote: > > > Hi, > > > > > > This patch set adds low/high limit for blk-throttle cgroup. The interface > > > is > >

Re: UBSAN whinge in ihci-hub.c

On Wed, 18 May 2016, Andrey Ryabinin wrote: > 2016-05-18 19:09 GMT+03:00 Alan Stern : > > On Wed, 18 May 2016, Andrey Ryabinin wrote: > > > >> 2016-05-18 17:40 GMT+03:00 Alan Stern : > >> > >> > All right, I'm getting very tired of all these

Re: UBSAN whinge in ihci-hub.c

On Wed, 18 May 2016, Andrey Ryabinin wrote: > 2016-05-18 19:09 GMT+03:00 Alan Stern : > > On Wed, 18 May 2016, Andrey Ryabinin wrote: > > > >> 2016-05-18 17:40 GMT+03:00 Alan Stern : > >> > >> > All right, I'm getting very tired of all these bug reports. Besides, > >> > Andrey has a point:

Re: [PATCH v2 07/32] perf/x86/intel/cqm: add helpers for per-package locking

On Wed, 18 May 2016, Thomas Gleixner wrote: > On Wed, 11 May 2016, David Carrillo-Cisneros wrote: > > + cqm_pkg_id_for_each_online(i) > > + mutex_lock_nested(_pkgs_data[i]->pkg_data_mutex, i); Peter just pointed out that this will fail when the number of nest levels exceeds 8. So any

Re: [PATCH v2 07/32] perf/x86/intel/cqm: add helpers for per-package locking

On Wed, 18 May 2016, Thomas Gleixner wrote: > On Wed, 11 May 2016, David Carrillo-Cisneros wrote: > > + cqm_pkg_id_for_each_online(i) > > + mutex_lock_nested(_pkgs_data[i]->pkg_data_mutex, i); Peter just pointed out that this will fail when the number of nest levels exceeds 8. So any

Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4

On Tuesday, May 17, 2016 04:50:48 PM John Youn wrote: > On 5/14/2016 6:11 AM, Christian Lamparter wrote: > > On Thursday, May 12, 2016 11:40:28 AM John Youn wrote: > >> On 5/12/2016 6:30 AM, Christian Lamparter wrote: > >>> On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote: > On

Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4

On Tuesday, May 17, 2016 04:50:48 PM John Youn wrote: > On 5/14/2016 6:11 AM, Christian Lamparter wrote: > > On Thursday, May 12, 2016 11:40:28 AM John Youn wrote: > >> On 5/12/2016 6:30 AM, Christian Lamparter wrote: > >>> On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote: > On

Re: [Xen-devel] [PATCH] x86, locking: Remove ticket (spin)lock implementation

On Wed, May 18, 2016 at 08:43:02PM +0200, Peter Zijlstra wrote: > > We've unconditionally used the queued spinlock for many releases now. Like since 4.2? I don't know of any enterprise distro that is shipping anything more modern than 4.1? Perhaps it would be good to wait until they at least

Re: [Xen-devel] [PATCH] x86, locking: Remove ticket (spin)lock implementation

On Wed, May 18, 2016 at 08:43:02PM +0200, Peter Zijlstra wrote: > > We've unconditionally used the queued spinlock for many releases now. Like since 4.2? I don't know of any enterprise distro that is shipping anything more modern than 4.1? Perhaps it would be good to wait until they at least

Re: [PATCH v5 2/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

On 5/18/2016 11:37 AM, Sudeep Holla wrote: > > > On 17/05/16 18:46, Prakash, Prashanth wrote: >> Hi Sudeep, >> >> On 5/11/2016 9:37 AM, Sudeep Holla wrote: >>> + >>> +static int acpi_processor_get_lpi_info(struct acpi_processor *pr) >>> +{ >>> +int ret, i; >>> +struct

Re: [PATCH v5 2/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

On 5/18/2016 11:37 AM, Sudeep Holla wrote: > > > On 17/05/16 18:46, Prakash, Prashanth wrote: >> Hi Sudeep, >> >> On 5/11/2016 9:37 AM, Sudeep Holla wrote: >>> + >>> +static int acpi_processor_get_lpi_info(struct acpi_processor *pr) >>> +{ >>> +int ret, i; >>> +struct

[ANNOUNCE] iproute2 4.6

Update to iproute2 utility to support new features in Linux 4.5. Major things are improvements to bridg mdb management, and bpf. Also, support for new devlink infrastructure Source: http://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-4.6.0.tar.gz Repository:

Re: [RFC PATCH 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use

On Wed, May 18, 2016 at 02:11:38PM -0500, Alex Thorlton wrote: > Let me know what everybody thinks! I realized right as I sent these that I should've included prefixes on the individual patches. I have a feeling we'll need a v2 anyways, so I'll clean that up then. - Alex

[PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

Now that the efi_call_virt macro has been generalized to be able to use EFI system tables besides efi.systab, we are able to convert our uv_bios_call wrapper to use this standard EFI callback mechanism. This simple change is part of a much larger effort to recover from some issues with the way we

[ANNOUNCE] iproute2 4.6

Update to iproute2 utility to support new features in Linux 4.5. Major things are improvements to bridg mdb management, and bpf. Also, support for new devlink infrastructure Source: http://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-4.6.0.tar.gz Repository:

Re: [RFC PATCH 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use

On Wed, May 18, 2016 at 02:11:38PM -0500, Alex Thorlton wrote: > Let me know what everybody thinks! I realized right as I sent these that I should've included prefixes on the individual patches. I have a feeling we'll need a v2 anyways, so I'll clean that up then. - Alex

[PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

Now that the efi_call_virt macro has been generalized to be able to use EFI system tables besides efi.systab, we are able to convert our uv_bios_call wrapper to use this standard EFI callback mechanism. This simple change is part of a much larger effort to recover from some issues with the way we

[PATCH 3/3] Update efi_thunk to use efi_call_virt_generic

Now that we have efi_call_virt_generic, we no longer need to have an entirely separate efi_thunk macro to handle the CONFIG_EFI_MIXED scenario, where the function pointers cannot be read directly out of efi.systab->runtime. This commit creates a new set of arch_efi_call_virt* macros to mimic the

[RFC PATCH 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use

Hey guys, This patchset creates a general purpose version of the efi_call_virt macro that does not assume that the function pointer being passed in is inside of efi.systab->runtime. It also fixes up a few potentional users of that new functionality, namely the SGI UV, and the CONFIG_EFI_MIXED

[PATCH 3/3] Update efi_thunk to use efi_call_virt_generic

Now that we have efi_call_virt_generic, we no longer need to have an entirely separate efi_thunk macro to handle the CONFIG_EFI_MIXED scenario, where the function pointers cannot be read directly out of efi.systab->runtime. This commit creates a new set of arch_efi_call_virt* macros to mimic the

[RFC PATCH 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use

Hey guys, This patchset creates a general purpose version of the efi_call_virt macro that does not assume that the function pointer being passed in is inside of efi.systab->runtime. It also fixes up a few potentional users of that new functionality, namely the SGI UV, and the CONFIG_EFI_MIXED

[PATCH 1/3] Convert efi_call_virt to efi_call_virt_generic

This commit makes a few slight modifications to the efi_call_virt macro to get it to work with function pointers that are stored in locations other than efi.systab->runtime, and renames the macro to efi_call_virt_generic. The majority of the changes here are to pull these macros up into header

[PATCH 1/3] Convert efi_call_virt to efi_call_virt_generic

This commit makes a few slight modifications to the efi_call_virt macro to get it to work with function pointers that are stored in locations other than efi.systab->runtime, and renames the macro to efi_call_virt_generic. The majority of the changes here are to pull these macros up into header

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

I thought the mix of slab_test & kernbench would show a diverse picture on perf data. Is there another test that you think would be useful? Thanks, Thomas On Wed, May 18, 2016 at 12:02 PM, Christoph Lameter wrote: > On Wed, 18 May 2016, Thomas Garnier wrote: > >> Yes, I agree

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

I thought the mix of slab_test & kernbench would show a diverse picture on perf data. Is there another test that you think would be useful? Thanks, Thomas On Wed, May 18, 2016 at 12:02 PM, Christoph Lameter wrote: > On Wed, 18 May 2016, Thomas Garnier wrote: > >> Yes, I agree that it is not

Re: [GIT] Networking

Linus Torvalds writes: > On Wed, May 18, 2016 at 11:58 AM, Kalle Valo wrote: >> >> It would be best if you could send a patch either directly to Dave or >> Linus to resolve this quickly. > > I'm committing my patch myself right now, since

Re: [GIT] Networking

Linus Torvalds writes: > On Wed, May 18, 2016 at 11:58 AM, Kalle Valo wrote: >> >> It would be best if you could send a patch either directly to Dave or >> Linus to resolve this quickly. > > I'm committing my patch myself right now, since this bug makes my > laptop useless, and I will take

Re: [PATCH 3/3] introduce task_rcu_dereference()

On Wed, May 18, 2016 at 08:23:18PM +0200, Oleg Nesterov wrote: > IOW. We can never know if we have a garbage in "sighand" or the real value, > this task_struct can be freed/reallocated when we do probe_slab_address(). > > And this is fine. We re-check that "task == *ptask" after that. Now we have

Re: [PATCH 3/3] introduce task_rcu_dereference()

On Wed, May 18, 2016 at 08:23:18PM +0200, Oleg Nesterov wrote: > IOW. We can never know if we have a garbage in "sighand" or the real value, > this task_struct can be freed/reallocated when we do probe_slab_address(). > > And this is fine. We re-check that "task == *ptask" after that. Now we have

[PATCH 1/1] rtc: ds1685: correct check of day of month

Operator ! has a higher priority than &&. (!(mday >= 1) && (mday <= 31)) is false for mday == 32. Signed-off-by: Heinrich Schuchardt --- drivers/rtc/rtc-ds1685.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-ds1685.c

[PATCH 1/1] rtc: ds1685: correct check of day of month

Operator ! has a higher priority than &&. (!(mday >= 1) && (mday <= 31)) is false for mday == 32. Signed-off-by: Heinrich Schuchardt --- drivers/rtc/rtc-ds1685.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-ds1685.c b/drivers/rtc/rtc-ds1685.c index

Re: [GIT] Networking

On Wed, 2016-05-18 at 12:00 -0700, Linus Torvalds wrote: > On Wed, May 18, 2016 at 11:58 AM, Kalle Valo > wrote: > > > > > > It would be best if you could send a patch either directly to Dave > > or > > Linus to resolve this quickly. > I'm committing my patch myself right

Re: [GIT] Networking

On Wed, 2016-05-18 at 12:00 -0700, Linus Torvalds wrote: > On Wed, May 18, 2016 at 11:58 AM, Kalle Valo > wrote: > > > > > > It would be best if you could send a patch either directly to Dave > > or > > Linus to resolve this quickly. > I'm committing my patch myself right now, since this bug

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

On Wed, 18 May 2016, Thomas Garnier wrote: > Yes, I agree that it is not related to the changes. Could you please provide meaningful test data?

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

On Wed, 18 May 2016, Thomas Garnier wrote: > Yes, I agree that it is not related to the changes. Could you please provide meaningful test data?

Re: [GIT] Networking

On Wed, May 18, 2016 at 11:58 AM, Kalle Valo wrote: > > It would be best if you could send a patch either directly to Dave or > Linus to resolve this quickly. I'm committing my patch myself right now, since this bug makes my laptop useless, and I will take credit for

Re: [GIT] Networking

On Wed, May 18, 2016 at 11:58 AM, Kalle Valo wrote: > > It would be best if you could send a patch either directly to Dave or > Linus to resolve this quickly. I'm committing my patch myself right now, since this bug makes my laptop useless, and I will take credit for finding and testing it on my

Re: [GIT] Networking

"Coelho, Luciano" writes: > Kalle, David, what is the status with the fix that is on the way via > your trees? It would be best if you could send a patch either directly to Dave or Linus to resolve this quickly. -- Kalle Valo

Re: [GIT] Networking

"Coelho, Luciano" writes: > Kalle, David, what is the status with the fix that is on the way via > your trees? It would be best if you could send a patch either directly to Dave or Linus to resolve this quickly. -- Kalle Valo

Re: [PATCH omap v2 0/6] Fix OMAP uses of RCU from idle loop

On Wed, May 18, 2016 at 07:38:39AM -0700, Guenter Roeck wrote: > On 05/16/2016 11:48 AM, Paul E. McKenney wrote: > >Hello! > > > >The following series fixes a number of uses of RCU from the idle loop. > >These are all due to tracing, so the fix is simply to append _rcuidle > >to the event-tracing

Re: [PATCH omap v2 0/6] Fix OMAP uses of RCU from idle loop

On Wed, May 18, 2016 at 07:38:39AM -0700, Guenter Roeck wrote: > On 05/16/2016 11:48 AM, Paul E. McKenney wrote: > >Hello! > > > >The following series fixes a number of uses of RCU from the idle loop. > >These are all due to tracing, so the fix is simply to append _rcuidle > >to the event-tracing

Re: [PATCH] usb: echi-hcd: Add register access check in shutdown

On Wed, 18 May 2016, Srinivas Kandagatla wrote: > On 18/05/16 15:56, Alan Stern wrote: > > This doesn't seem like the right place. What you really should do is > > skip calling ehci_silence_controller() if the hardware isn't > > accessible. That's where the hardware gets touched, not in > >

Re: [PATCH] usb: echi-hcd: Add register access check in shutdown

On Wed, 18 May 2016, Srinivas Kandagatla wrote: > On 18/05/16 15:56, Alan Stern wrote: > > This doesn't seem like the right place. What you really should do is > > skip calling ehci_silence_controller() if the hardware isn't > > accessible. That's where the hardware gets touched, not in > >

Re: [GIT] Networking

On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds wrote: > > From what I can tell, there's a merge bug in commit 909b27f70643, > where David seems to have lost some of the changes to > iwl_mvm_set_tx_cmd(). > > I do not know if that's the reason for the problem I

Re: [GIT] Networking

On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds wrote: > > From what I can tell, there's a merge bug in commit 909b27f70643, > where David seems to have lost some of the changes to > iwl_mvm_set_tx_cmd(). > > I do not know if that's the reason for the problem I see. But I will test. Yes. The

Re: [GIT] Networking

On Wed, 2016-05-18 at 11:45 -0700, Linus Torvalds wrote: > On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano > wrote: > > > > > > I can confirm that 4.6 contains the same bug.  And reverting the > > patch > > I mentioned does solve the problem... > > > > The same patch

Re: [GIT] Networking

On Wed, 2016-05-18 at 11:45 -0700, Linus Torvalds wrote: > On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano > wrote: > > > > > > I can confirm that 4.6 contains the same bug.  And reverting the > > patch > > I mentioned does solve the problem... > > > > The same patch works fine in our

Re: [GIT] Networking

On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano wrote: > > I can confirm that 4.6 contains the same bug. And reverting the patch > I mentioned does solve the problem... > > The same patch works fine in our internal tree. I'll have to figure > out together with

Re: [GIT] Networking

On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano wrote: > > I can confirm that 4.6 contains the same bug. And reverting the patch > I mentioned does solve the problem... > > The same patch works fine in our internal tree. I'll have to figure > out together with Emmanuel what the problem

Re: [PATCH] rcu: tree: correctly handle sparse possible CPUs

On Wed, May 18, 2016 at 07:30:41PM +0100, Mark Rutland wrote: > On Wed, May 18, 2016 at 11:01:53AM -0700, Paul E. McKenney wrote: > > On Wed, May 18, 2016 at 06:15:23PM +0300, Andrey Ryabinin wrote: > > > 2016-05-16 19:48 GMT+03:00 Mark Rutland : > > > > > > > /* > > > > +

Re: [PATCH] rcu: tree: correctly handle sparse possible CPUs

On Wed, May 18, 2016 at 07:30:41PM +0100, Mark Rutland wrote: > On Wed, May 18, 2016 at 11:01:53AM -0700, Paul E. McKenney wrote: > > On Wed, May 18, 2016 at 06:15:23PM +0300, Andrey Ryabinin wrote: > > > 2016-05-16 19:48 GMT+03:00 Mark Rutland : > > > > > > > /* > > > > + * Iterate over all

[PATCH] x86,locking: Remove ticket (spin)lock implementation

We've unconditionally used the queued spinlock for many releases now. Its time to remove the old ticket lock code. Cc: Waiman Long Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/Kconfig | 3 +-

[PATCH] x86,locking: Remove ticket (spin)lock implementation

We've unconditionally used the queued spinlock for many releases now. Its time to remove the old ticket lock code. Cc: Waiman Long Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/Kconfig | 3 +- arch/x86/include/asm/paravirt.h | 18 ---

Re: [PATCHv2] rcu: tree: correctly handle sparse possible CPUs

On Wed, May 18, 2016 at 07:15:09PM +0100, Mark Rutland wrote: > On Wed, May 18, 2016 at 02:02:36PM +0200, Arnd Bergmann wrote: > > It's the missing "possible_" that Mark mentioned in his reply on Friday. > > Actually, that was this morning. My VM on my laptop had a stale date due to >

Re: [PATCHv2] rcu: tree: correctly handle sparse possible CPUs

On Wed, May 18, 2016 at 07:15:09PM +0100, Mark Rutland wrote: > On Wed, May 18, 2016 at 02:02:36PM +0200, Arnd Bergmann wrote: > > It's the missing "possible_" that Mark mentioned in his reply on Friday. > > Actually, that was this morning. My VM on my laptop had a stale date due to >

[PATCH 1/1] net: pegasus: simplify logical constraint

If !count is true, count < 4 is also true. Signed-off-by: Heinrich Schuchardt --- drivers/net/usb/pegasus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c index 36cd7f0..9bbe0161 100644 ---

[PATCH 1/1] net: pegasus: simplify logical constraint

If !count is true, count < 4 is also true. Signed-off-by: Heinrich Schuchardt --- drivers/net/usb/pegasus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c index 36cd7f0..9bbe0161 100644 --- a/drivers/net/usb/pegasus.c

Re: [BUG] Null pointer dereference when freeing pages on 4.6-rc6

On 5/16/2016 5:44 AM, Vlastimil Babka wrote: [+CC Joonsoo based on git blame] On 05/05/2016 11:13 PM, Shi, Yang wrote: Hi folks, When I enable the below kernel configs on 4.6-rc6, I came across null pointer deference issue in boot stage. CONFIG_SPARSEMEM CONFIG_DEFERRED_STRUCT_PAGE_INIT

Re: [BUG] Null pointer dereference when freeing pages on 4.6-rc6

On 5/16/2016 5:44 AM, Vlastimil Babka wrote: [+CC Joonsoo based on git blame] On 05/05/2016 11:13 PM, Shi, Yang wrote: Hi folks, When I enable the below kernel configs on 4.6-rc6, I came across null pointer deference issue in boot stage. CONFIG_SPARSEMEM CONFIG_DEFERRED_STRUCT_PAGE_INIT

[git pull] vfs.git#work.misc

Assorted cleanups and fixes all over the place. The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc for

[git pull] vfs.git#work.misc

Assorted cleanups and fixes all over the place. The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc for

[git pull] vfs.git#work.iov_iter

iov_iter stuff this cycle The following changes since commit 03cc0789a690eb9ab07070376252961caeae7441: do_splice_to(): cap the size before passing to ->splice_read() (2016-04-03 19:52:59 -0400) are available in the git repository at:

[git pull] vfs.git#work.iov_iter

iov_iter stuff this cycle The following changes since commit 03cc0789a690eb9ab07070376252961caeae7441: do_splice_to(): cap the size before passing to ->splice_read() (2016-04-03 19:52:59 -0400) are available in the git repository at:

Re: [PATCH] kvm-pr: manage illegal instructions

On 18.05.2016 12:53, Thomas Huth wrote: > On 18.05.2016 12:18, Thomas Huth wrote: >> On 17.05.2016 19:49, Laurent Vivier wrote: >>> >>> >>> On 17/05/2016 10:37, Alexander Graf wrote: On 05/17/2016 10:35 AM, Laurent Vivier wrote: > > On 12/05/2016 16:23, Laurent Vivier wrote: >>

Re: [PATCH] kvm-pr: manage illegal instructions

On 18.05.2016 12:53, Thomas Huth wrote: > On 18.05.2016 12:18, Thomas Huth wrote: >> On 17.05.2016 19:49, Laurent Vivier wrote: >>> >>> >>> On 17/05/2016 10:37, Alexander Graf wrote: On 05/17/2016 10:35 AM, Laurent Vivier wrote: > > On 12/05/2016 16:23, Laurent Vivier wrote: >>

[git pull] Input updates for 4.7-rc0

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive first round of updates for the input subsystem. No new drivers here, just some driver fixes. Changelog: - Andreas Färber (1): Input: gpio-keys - clean up device

[git pull] Input updates for 4.7-rc0

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive first round of updates for the input subsystem. No new drivers here, just some driver fixes. Changelog: - Andreas Färber (1): Input: gpio-keys - clean up device

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

Yes, I agree that it is not related to the changes. On Wed, May 18, 2016 at 11:24 AM, Christoph Lameter wrote: > 0.On Wed, 18 May 2016, Thomas Garnier wrote: > >> slab_test, before: >> 1 times kmalloc(8) -> 67 cycles kfree -> 101 cycles >> 1 times kmalloc(16) -> 68 cycles

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

Yes, I agree that it is not related to the changes. On Wed, May 18, 2016 at 11:24 AM, Christoph Lameter wrote: > 0.On Wed, 18 May 2016, Thomas Garnier wrote: > >> slab_test, before: >> 1 times kmalloc(8) -> 67 cycles kfree -> 101 cycles >> 1 times kmalloc(16) -> 68 cycles kfree -> 109

Re: next: Build failure in drivers/s390/block/dcssblk.c due to 'dax: enable dax ...'

On Wed, May 18, 2016 at 06:30:16AM -0700, Guenter Roeck wrote: > drivers/s390/block/dcssblk.c:43:2: warning: initialization from incompatible > pointer type [enabled by default] > drivers/s390/block/dcssblk.c:43:2: warning: (near initialization for > 'dcssblk_devops.direct_access') [enabled by

Re: next: Build failure in drivers/s390/block/dcssblk.c due to 'dax: enable dax ...'

On Wed, May 18, 2016 at 06:30:16AM -0700, Guenter Roeck wrote: > drivers/s390/block/dcssblk.c:43:2: warning: initialization from incompatible > pointer type [enabled by default] > drivers/s390/block/dcssblk.c:43:2: warning: (near initialization for > 'dcssblk_devops.direct_access') [enabled by

Re: [PATCH] rcu: tree: correctly handle sparse possible CPUs

On Wed, May 18, 2016 at 11:01:53AM -0700, Paul E. McKenney wrote: > On Wed, May 18, 2016 at 06:15:23PM +0300, Andrey Ryabinin wrote: > > 2016-05-16 19:48 GMT+03:00 Mark Rutland : > > > > > /* > > > + * Iterate over all possible CPUs in a leaf RCU node. > > > + */ > > >

Re: [PATCH] rcu: tree: correctly handle sparse possible CPUs

On Wed, May 18, 2016 at 11:01:53AM -0700, Paul E. McKenney wrote: > On Wed, May 18, 2016 at 06:15:23PM +0300, Andrey Ryabinin wrote: > > 2016-05-16 19:48 GMT+03:00 Mark Rutland : > > > > > /* > > > + * Iterate over all possible CPUs in a leaf RCU node. > > > + */ > > > +#define

Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE

On 05/18/2016 01:21 PM, Jason Low wrote: On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote: On Tue, 17 May 2016, Waiman Long wrote: Without using WRITE_ONCE(), the compiler can potentially break a write into multiple smaller ones (store tearing). So a read from the same data by another

Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE

On 05/18/2016 01:21 PM, Jason Low wrote: On Wed, 2016-05-18 at 07:04 -0700, Davidlohr Bueso wrote: On Tue, 17 May 2016, Waiman Long wrote: Without using WRITE_ONCE(), the compiler can potentially break a write into multiple smaller ones (store tearing). So a read from the same data by another

Re: [PATCH 3/3] introduce task_rcu_dereference()

On 05/18, Peter Zijlstra wrote: > > So I keep coming back to this, and every time I look at it my brain > explodes. Heh ;) I forgot about this completely. > On Mon, Oct 27, 2014 at 08:54:46PM +0100, Oleg Nesterov wrote: > > +struct task_struct *task_rcu_dereference(struct task_struct **ptask) >

Re: [PATCH 3/3] introduce task_rcu_dereference()

On 05/18, Peter Zijlstra wrote: > > So I keep coming back to this, and every time I look at it my brain > explodes. Heh ;) I forgot about this completely. > On Mon, Oct 27, 2014 at 08:54:46PM +0100, Oleg Nesterov wrote: > > +struct task_struct *task_rcu_dereference(struct task_struct **ptask) >

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

0.On Wed, 18 May 2016, Thomas Garnier wrote: > slab_test, before: > 1 times kmalloc(8) -> 67 cycles kfree -> 101 cycles > 1 times kmalloc(16) -> 68 cycles kfree -> 109 cycles > 1 times kmalloc(32) -> 76 cycles kfree -> 119 cycles > 1 times kmalloc(64) -> 88 cycles kfree -> 114

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

0.On Wed, 18 May 2016, Thomas Garnier wrote: > slab_test, before: > 1 times kmalloc(8) -> 67 cycles kfree -> 101 cycles > 1 times kmalloc(16) -> 68 cycles kfree -> 109 cycles > 1 times kmalloc(32) -> 76 cycles kfree -> 119 cycles > 1 times kmalloc(64) -> 88 cycles kfree -> 114

Re: [PATCHv2] rcu: tree: correctly handle sparse possible CPUs

On Wed, May 18, 2016 at 02:02:36PM +0200, Arnd Bergmann wrote: > It's the missing "possible_" that Mark mentioned in his reply on Friday. Actually, that was this morning. My VM on my laptop had a stale date due to suspend/resume of the host. :/ I should be back at a real computer by Friday, and

Re: [PATCHv2] rcu: tree: correctly handle sparse possible CPUs

On Wed, May 18, 2016 at 02:02:36PM +0200, Arnd Bergmann wrote: > It's the missing "possible_" that Mark mentioned in his reply on Friday. Actually, that was this morning. My VM on my laptop had a stale date due to suspend/resume of the host. :/ I should be back at a real computer by Friday, and

Re: UBSAN: Undefined behaviour in arch/x86/events/intel/p6.c:115:29

On 16 May 2016 at 13:41, Meelis Roos wrote: > Not sure if this is a genuine warning or a false positive but since some > UBSAN warnings have been real and google does not find report about this > specific warning, I'll send it in anyway. > > I have seen similar amd pmu warnings

Re: UBSAN: Undefined behaviour in arch/x86/events/intel/p6.c:115:29

On 16 May 2016 at 13:41, Meelis Roos wrote: > Not sure if this is a genuine warning or a false positive but since some > UBSAN warnings have been real and google does not find report about this > specific warning, I'll send it in anyway. > > I have seen similar amd pmu warnings from UBSAN but I

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

On Wed, May 18, 2016 at 11:59 AM, Tony S wrote: > On Wed, May 18, 2016 at 11:20 AM, Boris Ostrovsky > wrote: >> On 05/18/2016 12:10 PM, Dario Faggioli wrote: >>> On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote: On 18/05/16 16:46,

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

On Wed, May 18, 2016 at 11:59 AM, Tony S wrote: > On Wed, May 18, 2016 at 11:20 AM, Boris Ostrovsky > wrote: >> On 05/18/2016 12:10 PM, Dario Faggioli wrote: >>> On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote: On 18/05/16 16:46, Boris Ostrovsky wrote: > > Won't we be

Re: [PATCH v2 9/9] powerpc/powernv: Use deepest stop state when cpu is offlined

On Tue, May 03, 2016 at 01:54:38PM +0530, Shreyas B. Prabhu wrote: > If hardware supports stop state, use the deepest stop state when > > the cpu is offlined. > > Signed-off-by: Shreyas B. Prabhu Reviewed-by: Gautham R. Shenoy -- Thanks

Re: [PATCH v2 9/9] powerpc/powernv: Use deepest stop state when cpu is offlined

On Tue, May 03, 2016 at 01:54:38PM +0530, Shreyas B. Prabhu wrote: > If hardware supports stop state, use the deepest stop state when > > the cpu is offlined. > > Signed-off-by: Shreyas B. Prabhu Reviewed-by: Gautham R. Shenoy -- Thanks and Regards gautham.

Re: [RFC PATCH 00/15] Provide atomics and bitops implemented with ISO C++11 atomics

On Wed, May 18, 2016 at 04:10:37PM +0100, David Howells wrote: > (1) We could weaken the kernel memory model to for the benefit of arches > that have instructions that employ explicit acquire/release barriers - > but that may cause data races to occur based on assumptions we've >

Re: [RFC PATCH 00/15] Provide atomics and bitops implemented with ISO C++11 atomics

On Wed, May 18, 2016 at 04:10:37PM +0100, David Howells wrote: > (1) We could weaken the kernel memory model to for the benefit of arches > that have instructions that employ explicit acquire/release barriers - > but that may cause data races to occur based on assumptions we've >

Re: [PATCH v2 7/9] powerpc/powernv: Add platform support for stop instruction

Hi Shreyas, On Tue, May 03, 2016 at 01:54:36PM +0530, Shreyas B. Prabhu wrote: > POWER ISA v3 defines a new idle processor core mechanism. In summary, > a) new instruction named stop is added. This instruction replaces > instructions like nap, sleep, rvwinkle. > b) new per thread SPR

Re: [PATCH] usb: echi-hcd: Add register access check in shutdown

On 18/05/16 15:56, Alan Stern wrote: This doesn't seem like the right place. What you really should do is skip calling ehci_silence_controller() if the hardware isn't accessible. That's where the hardware gets touched, not in ehci_shutdown(). Just tried this suggestion, this would not work

Re: [PATCH v2 7/9] powerpc/powernv: Add platform support for stop instruction

Hi Shreyas, On Tue, May 03, 2016 at 01:54:36PM +0530, Shreyas B. Prabhu wrote: > POWER ISA v3 defines a new idle processor core mechanism. In summary, > a) new instruction named stop is added. This instruction replaces > instructions like nap, sleep, rvwinkle. > b) new per thread SPR

Re: [PATCH] usb: echi-hcd: Add register access check in shutdown

On 18/05/16 15:56, Alan Stern wrote: This doesn't seem like the right place. What you really should do is skip calling ehci_silence_controller() if the hardware isn't accessible. That's where the hardware gets touched, not in ehci_shutdown(). Just tried this suggestion, this would not work

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

Am Mittwoch, 18. Mai 2016, 10:37:52 schrieb Doug Anderson: > Note: I'd be very curious if your problems get better if you disable > the "grf_force_jtag" bit in the GRF. If you're using the builtin card > detect and you use the boot default of "grf_force_jtag" then your pins > will be unmuxed

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

Am Mittwoch, 18. Mai 2016, 10:37:52 schrieb Doug Anderson: > Note: I'd be very curious if your problems get better if you disable > the "grf_force_jtag" bit in the GRF. If you're using the builtin card > detect and you use the boot default of "grf_force_jtag" then your pins > will be unmuxed

Re: [PATCH] rcu: tree: correctly handle sparse possible CPUs

On Wed, May 18, 2016 at 06:15:23PM +0300, Andrey Ryabinin wrote: > 2016-05-16 19:48 GMT+03:00 Mark Rutland : > > > /* > > + * Iterate over all possible CPUs in a leaf RCU node. > > + */ > > +#define for_each_leaf_node_possible_cpu(rnp, cpu) \ > > + for ((cpu) =

Re: [PATCH] rcu: tree: correctly handle sparse possible CPUs

On Wed, May 18, 2016 at 06:15:23PM +0300, Andrey Ryabinin wrote: > 2016-05-16 19:48 GMT+03:00 Mark Rutland : > > > /* > > + * Iterate over all possible CPUs in a leaf RCU node. > > + */ > > +#define for_each_leaf_node_possible_cpu(rnp, cpu) \ > > + for ((cpu) = rnp->grplo; \ > > +

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

On Wed, May 18, 2016 at 11:20 AM, Boris Ostrovsky wrote: > On 05/18/2016 12:10 PM, Dario Faggioli wrote: >> On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote: >>> On 18/05/16 16:46, Boris Ostrovsky wrote: Won't we be accounting for stolen cycles twice

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

On Wed, May 18, 2016 at 11:20 AM, Boris Ostrovsky wrote: > On 05/18/2016 12:10 PM, Dario Faggioli wrote: >> On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote: >>> On 18/05/16 16:46, Boris Ostrovsky wrote: Won't we be accounting for stolen cycles twice now --- once from

<    1   2   3   4   5   6   7   8   9   10   >