Re: [RFC 01/12] clk: qcom: support for register offsets from rcg2 clock node

On 07/28, Abhishek Sahu wrote: > On 2017-07-28 00:14, Stephen Boyd wrote: > > > >It looks like the two UBI clks that messed this up don't have an MN > >counter, so instead of doing this maddness, just add a flag like > > I have given example for one of the RCG. IPQ8074 have more clocks for >

Re: [RFC 01/12] clk: qcom: support for register offsets from rcg2 clock node

On 07/28, Abhishek Sahu wrote: > On 2017-07-28 00:14, Stephen Boyd wrote: > > > >It looks like the two UBI clks that messed this up don't have an MN > >counter, so instead of doing this maddness, just add a flag like > > I have given example for one of the RCG. IPQ8074 have more clocks for >

[RFC PATCH] NFS: Fix the access mask checks in NFSv4

Commit bd8b2441742b ("NFS: Store the raw NFS access mask in the inode's access cache") changed the way access mask is stored in struct nfs_access_entry. However, there a are couple of places NFSv4 code where it still uses the generic access bits instead of the raw NFS ones (e.g. MAY_READ instead

[RFC PATCH] NFS: Fix the access mask checks in NFSv4

Commit bd8b2441742b ("NFS: Store the raw NFS access mask in the inode's access cache") changed the way access mask is stored in struct nfs_access_entry. However, there a are couple of places NFSv4 code where it still uses the generic access bits instead of the raw NFS ones (e.g. MAY_READ instead

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

On 07/28/2017 07:44 AM, Corentin Labbe wrote: > On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote: I've probably asked this before: Does the internal PHY use a different PHY ID in registers 2 and 3? >>> >>> yes >>> >>> reg2: 0x0044 >>> reg3: 0X1500 > > Copy/paste error,

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

On 07/28/2017 07:44 AM, Corentin Labbe wrote: > On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote: I've probably asked this before: Does the internal PHY use a different PHY ID in registers 2 and 3? >>> >>> yes >>> >>> reg2: 0x0044 >>> reg3: 0X1500 > > Copy/paste error,

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

On Fri, Jul 28, 2017 at 04:48:47PM +, Levin, Alexander (Sasha Levin) wrote: > Hey Josh, > > Syzkaller seems to trigger the following: > > == > BUG: KASAN: stack-out-of-bounds in __read_once_size > include/linux/compiler.h:253

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

On Fri, Jul 28, 2017 at 04:48:47PM +, Levin, Alexander (Sasha Levin) wrote: > Hey Josh, > > Syzkaller seems to trigger the following: > > == > BUG: KASAN: stack-out-of-bounds in __read_once_size > include/linux/compiler.h:253

Re: [resend PATCH v2 11/33] dm: add dax_device and dax_operations support

On Fri, Jul 28 2017 at 12:17pm -0400, Bart Van Assche wrote: > On Mon, 2017-04-17 at 12:09 -0700, Dan Williams wrote: > > diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig > > index b7767da50c26..1de8372d9459 100644 > > --- a/drivers/md/Kconfig > > +++

Re: [resend PATCH v2 11/33] dm: add dax_device and dax_operations support

On Fri, Jul 28 2017 at 12:17pm -0400, Bart Van Assche wrote: > On Mon, 2017-04-17 at 12:09 -0700, Dan Williams wrote: > > diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig > > index b7767da50c26..1de8372d9459 100644 > > --- a/drivers/md/Kconfig > > +++ b/drivers/md/Kconfig > > @@ -200,6

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed 26-07-17 10:33:31, Michal Hocko wrote: [...] > @@ -312,7 +324,7 @@ int __ref __add_pages(int nid, unsigned long > phys_start_pfn, > } > > for (i = start_sec; i <= end_sec; i++) { > - err = __add_section(nid, section_nr_to_pfn(i), want_memblock); > +

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed 26-07-17 10:33:31, Michal Hocko wrote: [...] > @@ -312,7 +324,7 @@ int __ref __add_pages(int nid, unsigned long > phys_start_pfn, > } > > for (i = start_sec; i <= end_sec; i++) { > - err = __add_section(nid, section_nr_to_pfn(i), want_memblock); > +

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 28, 2017, at 1:31 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: > On Fri, Jul 28, 2017 at 10:15:49AM -0700, Andrew Hunter wrote: >> On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney >> wrote: >> > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 28, 2017, at 1:31 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: > On Fri, Jul 28, 2017 at 10:15:49AM -0700, Andrew Hunter wrote: >> On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney >> wrote: >> > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >> >> IPIing

Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending()

On Fri, Jun 09, 2017 at 03:45:54PM +0100, Will Deacon wrote: > On Wed, Jun 07, 2017 at 06:15:02PM +0200, Peter Zijlstra wrote: > > Commit: > > > > af2c1401e6f9 ("mm: numa: guarantee that tlb_flush_pending updates are > > visible before page table updates") > > > > added

Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending()

On Fri, Jun 09, 2017 at 03:45:54PM +0100, Will Deacon wrote: > On Wed, Jun 07, 2017 at 06:15:02PM +0200, Peter Zijlstra wrote: > > Commit: > > > > af2c1401e6f9 ("mm: numa: guarantee that tlb_flush_pending updates are > > visible before page table updates") > > > > added

BUG: NULL pointer dereference at ib_uverbs_comp_handler+0x20

Hi, My system has been failing with recent kernels (4.12.x and 4.13-rc2) with a NULL pointer dereference at the stack trace given at the end of this email. This happens when simply running 'ib_write_bw -R ' with a Chelsio T6 (cxgb4). I've bisected (log attached) to find the offending commit to

BUG: NULL pointer dereference at ib_uverbs_comp_handler+0x20

Hi, My system has been failing with recent kernels (4.12.x and 4.13-rc2) with a NULL pointer dereference at the stack trace given at the end of this email. This happens when simply running 'ib_write_bw -R ' with a Chelsio T6 (cxgb4). I've bisected (log attached) to find the offending commit to

Re: Udpated sys_membarrier() speedup patch, FYI

On Thu, Jul 27, 2017 at 12:06 PM, Paul E. McKenney wrote: > IPIin only those CPUs running threads in the same process as the > thread invoking membarrier() would be very nice! There is some LKML > discussion on this topic, which is currently circling around making

Re: Udpated sys_membarrier() speedup patch, FYI

On Thu, Jul 27, 2017 at 12:06 PM, Paul E. McKenney wrote: > IPIin only those CPUs running threads in the same process as the > thread invoking membarrier() would be very nice! There is some LKML > discussion on this topic, which is currently circling around making this > determination reliable

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote: > Dan Williams and Christoph Hellwig have recently expressed doubt about > whether the rw_page() interface made sense for synchronous memory drivers > [1][2]. It's unclear whether this interface has any performance benefit > for these

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote: > Dan Williams and Christoph Hellwig have recently expressed doubt about > whether the rw_page() interface made sense for synchronous memory drivers > [1][2]. It's unclear whether this interface has any performance benefit > for these

Re: Udpated sys_membarrier() speedup patch, FYI

On Fri, Jul 28, 2017 at 10:15:49AM -0700, Andrew Hunter wrote: > On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney > wrote: > > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: > >> IPIing only running threads of my process would be perfect. In fact > >> I

Re: Udpated sys_membarrier() speedup patch, FYI

On Fri, Jul 28, 2017 at 10:15:49AM -0700, Andrew Hunter wrote: > On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney > wrote: > > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: > >> IPIing only running threads of my process would be perfect. In fact > >> I might even be able to make

Re: [PATCH v3 3/3] net: ethernet: ti: cpts: fix tx timestamping timeout

On 07/28/2017 12:02 PM, Ivan Khoronzhuk wrote: On Wed, Jul 26, 2017 at 05:11:38PM -0500, Grygorii Strashko wrote: With the low speed Ethernet connection CPDMA notification about packet processing can be received before CPTS TX timestamp event, which is set when packet actually left CPSW while

Re: [PATCH v3 3/3] net: ethernet: ti: cpts: fix tx timestamping timeout

On 07/28/2017 12:02 PM, Ivan Khoronzhuk wrote: On Wed, Jul 26, 2017 at 05:11:38PM -0500, Grygorii Strashko wrote: With the low speed Ethernet connection CPDMA notification about packet processing can be received before CPTS TX timestamp event, which is set when packet actually left CPSW while

RE: [PATCH] drm/amd/powerplay: rv: Use designated initializers

> -Original Message- > From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of > Kees Cook > Sent: Friday, July 28, 2017 1:16 PM > To: Alex Deucher > Cc: LKML; David Airlie; amd-gfx list; Maling list - DRI developers; Deucher, > Alexander; Zhu, Rex; Koenig, Christian; Zhang,

RE: [PATCH] drm/amd/powerplay: rv: Use designated initializers

> -Original Message- > From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of > Kees Cook > Sent: Friday, July 28, 2017 1:16 PM > To: Alex Deucher > Cc: LKML; David Airlie; amd-gfx list; Maling list - DRI developers; Deucher, > Alexander; Zhu, Rex; Koenig, Christian; Zhang,

[PATCH v3] livepatch: introduce shadow variable API

Add exported API for livepatch modules: klp_shadow_get() klp_shadow_attach() klp_shadow_get_or_attach() klp_shadow_update_or_attach() klp_shadow_detach() klp_shadow_detach_all() that implement "shadow" variables, which allow callers to associate new shadow fields to existing data

[PATCH v3] livepatch: introduce shadow variable API

Add exported API for livepatch modules: klp_shadow_get() klp_shadow_attach() klp_shadow_get_or_attach() klp_shadow_update_or_attach() klp_shadow_detach() klp_shadow_detach_all() that implement "shadow" variables, which allow callers to associate new shadow fields to existing data

[PATCH v3] livepatch: shadow variables

Hi all, This is v3 of the livepatch shadow variable API. v2 collected a bunch of great feedback on terminology, use cases and concurrency notes which I've tried to incorporate here. Here's a high-level sketch of v2 changes: - Overall - Squash into a one patch, makes for finding terms and

[PATCH v3] livepatch: shadow variables

Hi all, This is v3 of the livepatch shadow variable API. v2 collected a bunch of great feedback on terminology, use cases and concurrency notes which I've tried to incorporate here. Here's a high-level sketch of v2 changes: - Overall - Squash into a one patch, makes for finding terms and

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 28, 2017, at 1:15 PM, Andrew Hunter a...@google.com wrote: > On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney > wrote: >> On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >>> IPIing only running threads of my process would be perfect. In fact

Re: Udpated sys_membarrier() speedup patch, FYI

- On Jul 28, 2017, at 1:15 PM, Andrew Hunter a...@google.com wrote: > On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney > wrote: >> On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >>> IPIing only running threads of my process would be perfect. In fact >>> I might even be able to

Re: Udpated sys_membarrier() speedup patch, FYI

On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney wrote: > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >> IPIing only running threads of my process would be perfect. In fact >> I might even be able to make use of "membarrier these threads >> please" to

Re: Udpated sys_membarrier() speedup patch, FYI

On Thu, Jul 27, 2017 at 12:43 PM, Paul E. McKenney wrote: > On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote: >> IPIing only running threads of my process would be perfect. In fact >> I might even be able to make use of "membarrier these threads >> please" to reduce IPIs, when I change

Re: [PATCH] drm/amd/powerplay: rv: Use designated initializers

On Thu, Jul 27, 2017 at 6:43 PM, Alex Deucher wrote: > On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook wrote: >> As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use >> designated initializers") mark other tableFunction entries with

Re: [PATCH] drm/amd/powerplay: rv: Use designated initializers

On Thu, Jul 27, 2017 at 6:43 PM, Alex Deucher wrote: > On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook wrote: >> As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use >> designated initializers") mark other tableFunction entries with designated >> initializers. The randstruct plugin

Re: [PATCH tip/core/rcu 07/15] rcu: Add event tracing to ->gp_tasks update at GP start

On Fri, Jul 28, 2017 at 08:18:18AM -0400, Steven Rostedt wrote: > On Thu, 27 Jul 2017 20:22:32 -0700 > "Paul E. McKenney" wrote: > > > On Thu, Jul 27, 2017 at 09:38:10PM -0400, Steven Rostedt wrote: > > > On Mon, 24 Jul 2017 14:44:36 -0700 > > > "Paul E. McKenney"

Re: [PATCH tip/core/rcu 07/15] rcu: Add event tracing to ->gp_tasks update at GP start

On Fri, Jul 28, 2017 at 08:18:18AM -0400, Steven Rostedt wrote: > On Thu, 27 Jul 2017 20:22:32 -0700 > "Paul E. McKenney" wrote: > > > On Thu, Jul 27, 2017 at 09:38:10PM -0400, Steven Rostedt wrote: > > > On Mon, 24 Jul 2017 14:44:36 -0700 > > > "Paul E. McKenney" wrote: > > > > > > > There

[PATCH] zram: Fix buffer size passed to strlcpy()

comp_algorithm_store() passes the size of the source buffer to strlcpy() instead of the destination buffer size, fix this. Signed-off-by: Matthias Kaehlcke --- drivers/block/zram/zram_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] zram: Fix buffer size passed to strlcpy()

comp_algorithm_store() passes the size of the source buffer to strlcpy() instead of the destination buffer size, fix this. Signed-off-by: Matthias Kaehlcke --- drivers/block/zram/zram_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/zram/zram_drv.c

Re: [PATCH] drm/amd/powerplay: rv: Use designated initializers

On Fri, Jul 28, 2017 at 2:13 AM, Christian König wrote: > Am 28.07.2017 um 03:43 schrieb Alex Deucher: >> >> On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook wrote: >>> >>> As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use >>>

Re: [PATCH] drm/amd/powerplay: rv: Use designated initializers

On Fri, Jul 28, 2017 at 2:13 AM, Christian König wrote: > Am 28.07.2017 um 03:43 schrieb Alex Deucher: >> >> On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook wrote: >>> >>> As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use >>> designated initializers") mark other tableFunction entries

Re: [PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

On 07/28/2017 09:55 AM, Vivien Didelot wrote: > Hi Egil, > > Egil Hjelmeland writes: > +const struct lan9303_phy_ops lan9303_indirect_phy_ops = { + .phy_read = lan9303_indirect_phy_read, + .phy_write = lan9303_indirect_phy_write, +};

Re: [PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

On 07/28/2017 09:55 AM, Vivien Didelot wrote: > Hi Egil, > > Egil Hjelmeland writes: > +const struct lan9303_phy_ops lan9303_indirect_phy_ops = { + .phy_read = lan9303_indirect_phy_read, + .phy_write = lan9303_indirect_phy_write, +};

Re: two more objtool warnings: lib/ubsan.o and fs/fs_pin.o

On Fri, Jul 28, 2017 at 01:25:27PM +0200, Arnd Bergmann wrote: > Hi Josh, > > I ran into two more warnings with the two patches you sent me in private, > using gcc-7.1.1: > > lib/ubsan.o: warning: objtool: val_to_string.constprop.7()+0x97: leave > instruction with modified stack frame > .config:

Re: two more objtool warnings: lib/ubsan.o and fs/fs_pin.o

On Fri, Jul 28, 2017 at 01:25:27PM +0200, Arnd Bergmann wrote: > Hi Josh, > > I ran into two more warnings with the two patches you sent me in private, > using gcc-7.1.1: > > lib/ubsan.o: warning: objtool: val_to_string.constprop.7()+0x97: leave > instruction with modified stack frame > .config:

Re: [RFC PATCH v2] membarrier: expedited private command

- On Jul 28, 2017, at 12:46 PM, Peter Zijlstra pet...@infradead.org wrote: > On Fri, Jul 28, 2017 at 03:38:15PM +, Mathieu Desnoyers wrote: >> > Which only leaves PPC stranded.. but the 'good' news is that mpe says >> > they'll probably need a barrier in switch_mm() in any case. >> >> As

Re: [RFC PATCH v2] membarrier: expedited private command

- On Jul 28, 2017, at 12:46 PM, Peter Zijlstra pet...@infradead.org wrote: > On Fri, Jul 28, 2017 at 03:38:15PM +, Mathieu Desnoyers wrote: >> > Which only leaves PPC stranded.. but the 'good' news is that mpe says >> > they'll probably need a barrier in switch_mm() in any case. >> >> As

Re: [PATCH net-next 3/4] net: dsa: lan9303: Renamed indirect phy access functions

On 07/28/2017 08:11 AM, Egil Hjelmeland wrote: > Preparing for the following fix of MDIO phy access: > > Renamed functions that access PHY 1 and 2 indirectly through PMI > registers. > > lan9303_port_phy_reg_wait_for_completion() to > lan9303_indirect_phy_wait_for_completion() > >

Re: [PATCH net-next 3/4] net: dsa: lan9303: Renamed indirect phy access functions

On 07/28/2017 08:11 AM, Egil Hjelmeland wrote: > Preparing for the following fix of MDIO phy access: > > Renamed functions that access PHY 1 and 2 indirectly through PMI > registers. > > lan9303_port_phy_reg_wait_for_completion() to > lan9303_indirect_phy_wait_for_completion() > >

Re: [PATCH net-next 2/4] net: dsa: lan9303: Multiply by 4 to get MDIO register

On 07/28/2017 08:11 AM, Egil Hjelmeland wrote: > lan9303_mdio_write()/_read() must multiply register number by 4 to get > offset. > > Added some commments to the register definitions. > > Signed-off-by: Egil Hjelmeland Reviewed-by: Florian Fainelli

Re: [PATCH net-next 2/4] net: dsa: lan9303: Multiply by 4 to get MDIO register

On 07/28/2017 08:11 AM, Egil Hjelmeland wrote: > lan9303_mdio_write()/_read() must multiply register number by 4 to get > offset. > > Added some commments to the register definitions. > > Signed-off-by: Egil Hjelmeland Reviewed-by: Florian Fainelli -- Florian

Re: [PATCH v3 3/3] net: ethernet: ti: cpts: fix tx timestamping timeout

On Wed, Jul 26, 2017 at 05:11:38PM -0500, Grygorii Strashko wrote: > With the low speed Ethernet connection CPDMA notification about packet > processing can be received before CPTS TX timestamp event, which is set > when packet actually left CPSW while cpdma notification is sent when packet >

Re: [PATCH v3 3/3] net: ethernet: ti: cpts: fix tx timestamping timeout

On Wed, Jul 26, 2017 at 05:11:38PM -0500, Grygorii Strashko wrote: > With the low speed Ethernet connection CPDMA notification about packet > processing can be received before CPTS TX timestamp event, which is set > when packet actually left CPSW while cpdma notification is sent when packet >

Re: [PATCH net-next 1/4] net: dsa: lan9303: Fix lan9303_detect_phy_setup() for MDIO

On 07/28/2017 08:11 AM, Egil Hjelmeland wrote: > Handle that MDIO read with no response return 0x. > > Signed-off-by: Egil Hjelmeland Reviewed-by: Florian Fainelli -- Florian

Re: [PATCH net-next 1/4] net: dsa: lan9303: Fix lan9303_detect_phy_setup() for MDIO

On 07/28/2017 08:11 AM, Egil Hjelmeland wrote: > Handle that MDIO read with no response return 0x. > > Signed-off-by: Egil Hjelmeland Reviewed-by: Florian Fainelli -- Florian

Re: [RFC PATCH v3] membarrier: expedited private command

On Fri, Jul 28, 2017 at 12:54:29PM -0400, Mathieu Desnoyers wrote: > Scheduler-wise, it requires a memory barrier before and after context > switching between processes (which have different mm). The memory > barrier before context switch is already present. After context switch, >

Re: [RFC PATCH v3] membarrier: expedited private command

On Fri, Jul 28, 2017 at 12:54:29PM -0400, Mathieu Desnoyers wrote: > Scheduler-wise, it requires a memory barrier before and after context > switching between processes (which have different mm). The memory > barrier before context switch is already present. After context switch, >

[PATCH 3/3] brd: remove brd_rw_page()

The rw_page() interface doesn't provide a clear performance benefit for BRD and has had a nonzero maintenance burden, so remove it. Signed-off-by: Ross Zwisler Suggested-by: Dan Williams Suggested-by: Christoph Hellwig

[PATCH 3/3] brd: remove brd_rw_page()

The rw_page() interface doesn't provide a clear performance benefit for BRD and has had a nonzero maintenance burden, so remove it. Signed-off-by: Ross Zwisler Suggested-by: Dan Williams Suggested-by: Christoph Hellwig Cc: Matthew Wilcox --- drivers/block/brd.c | 10 -- 1 file

RE: [PATCH] MAINTAINERS: Add Tony and Boris as ACPI/APEI reviewers

> Since this piece of the ACPI pile is doing RAS, it is perhaps prudent if > we at least paid attention to it and the direction it takes. So add Tony > and me as reviewers. Acked-by: Tony Luck

RE: [PATCH] MAINTAINERS: Add Tony and Boris as ACPI/APEI reviewers

> Since this piece of the ACPI pile is doing RAS, it is perhaps prudent if > we at least paid attention to it and the direction it takes. So add Tony > and me as reviewers. Acked-by: Tony Luck

[PATCH 2/3] pmem: remove pmem_rw_page()

The rw_page() interface doesn't provide a clear performance benefit for PMEM and has had a nonzero maintenance burden, so remove it. Signed-off-by: Ross Zwisler Suggested-by: Dan Williams Suggested-by: Christoph Hellwig

[PATCH 2/3] pmem: remove pmem_rw_page()

The rw_page() interface doesn't provide a clear performance benefit for PMEM and has had a nonzero maintenance burden, so remove it. Signed-off-by: Ross Zwisler Suggested-by: Dan Williams Suggested-by: Christoph Hellwig Cc: Matthew Wilcox --- drivers/nvdimm/pmem.c | 21 -

[PATCH 1/3] btt: remove btt_rw_page()

The rw_page() interface doesn't provide a clear performance benefit for the BTT and has had a nonzero maintenance burden, so remove it. Signed-off-by: Ross Zwisler Suggested-by: Dan Williams Suggested-by: Christoph Hellwig

[PATCH 1/3] btt: remove btt_rw_page()

The rw_page() interface doesn't provide a clear performance benefit for the BTT and has had a nonzero maintenance burden, so remove it. Signed-off-by: Ross Zwisler Suggested-by: Dan Williams Suggested-by: Christoph Hellwig Cc: Matthew Wilcox --- drivers/nvdimm/btt.c | 15 --- 1

Re: [PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

Hi Egil, Egil Hjelmeland writes: >>> +const struct lan9303_phy_ops lan9303_indirect_phy_ops = { >>> + .phy_read = lan9303_indirect_phy_read, >>> + .phy_write = lan9303_indirect_phy_write, >>> +}; >>> +EXPORT_SYMBOL(lan9303_indirect_phy_ops); >> >> Isn't

Re: [PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

Hi Egil, Egil Hjelmeland writes: >>> +const struct lan9303_phy_ops lan9303_indirect_phy_ops = { >>> + .phy_read = lan9303_indirect_phy_read, >>> + .phy_write = lan9303_indirect_phy_write, >>> +}; >>> +EXPORT_SYMBOL(lan9303_indirect_phy_ops); >> >> Isn't EXPORT_SYMBOL_GPL prefered over

[PATCH 0/3] remove rw_page() from brd, pmem and btt

Dan Williams and Christoph Hellwig have recently expressed doubt about whether the rw_page() interface made sense for synchronous memory drivers [1][2]. It's unclear whether this interface has any performance benefit for these drivers, but as we continue to fix bugs it is clear that it does have

[PATCH 0/3] remove rw_page() from brd, pmem and btt

Dan Williams and Christoph Hellwig have recently expressed doubt about whether the rw_page() interface made sense for synchronous memory drivers [1][2]. It's unclear whether this interface has any performance benefit for these drivers, but as we continue to fix bugs it is clear that it does have

[RFC PATCH v3] membarrier: expedited private command

Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built from all runqueues for which current thread's mm is the same as the thread calling sys_membarrier. Scheduler-wise, it requires a memory barrier before and after context switching between processes (which have different mm).

[RFC PATCH v3] membarrier: expedited private command

Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built from all runqueues for which current thread's mm is the same as the thread calling sys_membarrier. Scheduler-wise, it requires a memory barrier before and after context switching between processes (which have different mm).

Re: [v3,04/10] ipw2200: constify attribute_group structures

Kalle Valo writes: > Kalle Valo writes: > >> Arvind Yadav wrote: >> >>> attribute_group are not supposed to change at runtime. All functions >>> working with attribute_group provided by work >>> with const attribute_group.

Re: [v3,04/10] ipw2200: constify attribute_group structures

Kalle Valo writes: > Kalle Valo writes: > >> Arvind Yadav wrote: >> >>> attribute_group are not supposed to change at runtime. All functions >>> working with attribute_group provided by work >>> with const attribute_group. So mark the non-const structs as const. >>> >>> Signed-off-by: Arvind

[PATCH 2/2] perf/aux: Ensure aux_wakeup represents most recent wakeup index

The aux_watermark member of struct ring_buffer represents the period (in terms of bytes) at which wakeup events should be generated when data is written to the aux buffer in non-snapshot mode. On hardware that cannot generate an interrupt when the aux_head reaches an arbitrary wakeup index (such

[PATCH 2/2] perf/aux: Ensure aux_wakeup represents most recent wakeup index

The aux_watermark member of struct ring_buffer represents the period (in terms of bytes) at which wakeup events should be generated when data is written to the aux buffer in non-snapshot mode. On hardware that cannot generate an interrupt when the aux_head reaches an arbitrary wakeup index (such

[PATCH 1/2] perf/aux: Make aux_{head,wakeup} ring_buffer members long

The aux_head and aux_wakeup members of struct ring_buffer are defined using the local_t type, despite the fact that they are only accessed via the perf_aux_output_* functions, which cannot race with each other for a given ring buffer. This patch changes the type of the members to long, so we can

[PATCH 1/2] perf/aux: Make aux_{head,wakeup} ring_buffer members long

The aux_head and aux_wakeup members of struct ring_buffer are defined using the local_t type, despite the fact that they are only accessed via the perf_aux_output_* functions, which cannot race with each other for a given ring buffer. This patch changes the type of the members to long, so we can

Re: [RESEND PATCH] soc: ti: ti_sci_pm_domains: Populate name for genpd

On 7/28/17 9:35 AM, Dave Gerlach wrote: Hi, On 07/28/2017 11:33 AM, Dave Gerlach wrote: Commit b6a1d093f96b ("PM / Domains: Extend generic power domain debugfs") now creates a debugfs directory for each genpd based on the name of the genpd. Currently no name is given to the genpd created by

Re: [RESEND PATCH] soc: ti: ti_sci_pm_domains: Populate name for genpd

On 7/28/17 9:35 AM, Dave Gerlach wrote: Hi, On 07/28/2017 11:33 AM, Dave Gerlach wrote: Commit b6a1d093f96b ("PM / Domains: Extend generic power domain debugfs") now creates a debugfs directory for each genpd based on the name of the genpd. Currently no name is given to the genpd created by

Re: [PATCH v2] cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()

On Fri, Jul 28, 2017 at 7:05 AM, Vlastimil Babka wrote: > On 07/28/2017 11:30 AM, Peter Zijlstra wrote: >> On Fri, Jul 28, 2017 at 09:45:16AM +0200, Vlastimil Babka wrote: >>> [+CC PeterZ] >>> >>> On 07/27/2017 06:46 PM, Dima Zavin wrote: In codepaths that use the begin/retry

Re: [PATCH v2] cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()

On Fri, Jul 28, 2017 at 7:05 AM, Vlastimil Babka wrote: > On 07/28/2017 11:30 AM, Peter Zijlstra wrote: >> On Fri, Jul 28, 2017 at 09:45:16AM +0200, Vlastimil Babka wrote: >>> [+CC PeterZ] >>> >>> On 07/27/2017 06:46 PM, Dima Zavin wrote: In codepaths that use the begin/retry interface for

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

On Mon, Jul 24, 2017 at 06:36:57PM -0500, Josh Poimboeuf wrote: >Add a new ORC unwinder which is enabled by CONFIG_ORC_UNWINDER. It >plugs into the existing x86 unwinder framework. > >It relies on objtool to generate the needed .orc_unwind and >.orc_unwind_ip sections. > >For more details on why

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

On Mon, Jul 24, 2017 at 06:36:57PM -0500, Josh Poimboeuf wrote: >Add a new ORC unwinder which is enabled by CONFIG_ORC_UNWINDER. It >plugs into the existing x86 unwinder framework. > >It relies on objtool to generate the needed .orc_unwind and >.orc_unwind_ip sections. > >For more details on why

Re: [PATCH v2 1/2] misc: eeprom_93xx46: Simplify the usage of gpiod API

Hi Cory, On Wed, Jul 19, 2017 at 11:44 PM, Fabio Estevam wrote: > From: Fabio Estevam > > Commit 3ca9b1ac28398c ("misc: eeprom_93xx46: Add support for a GPIO > 'select' line.") introduced the optional usage of 'select-gpios' > by using the gpiod API in

Re: [PATCH v2 1/2] misc: eeprom_93xx46: Simplify the usage of gpiod API

Hi Cory, On Wed, Jul 19, 2017 at 11:44 PM, Fabio Estevam wrote: > From: Fabio Estevam > > Commit 3ca9b1ac28398c ("misc: eeprom_93xx46: Add support for a GPIO > 'select' line.") introduced the optional usage of 'select-gpios' > by using the gpiod API in a convoluted way. > > Rewrite the gpiod

Re: [RFC PATCH v2] membarrier: expedited private command

On Fri, Jul 28, 2017 at 03:38:15PM +, Mathieu Desnoyers wrote: > > Which only leaves PPC stranded.. but the 'good' news is that mpe says > > they'll probably need a barrier in switch_mm() in any case. > > As I pointed out in my other email, I plan to do this: > > --- a/kernel/sched/core.c >

Re: [RFC PATCH v2] membarrier: expedited private command

On Fri, Jul 28, 2017 at 03:38:15PM +, Mathieu Desnoyers wrote: > > Which only leaves PPC stranded.. but the 'good' news is that mpe says > > they'll probably need a barrier in switch_mm() in any case. > > As I pointed out in my other email, I plan to do this: > > --- a/kernel/sched/core.c >

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

On Wed, Jul 26, 2017 at 08:07:37PM +0300, Dmitry Safonov wrote: > vDSO VMA address is saved in mm_context for the purpose of using > restorer from vDSO page to return to userspace after signal handling. > > In Checkpoint Restore in Userspace (CRIU) project we place vDSO VMA > on restore back to

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

On Wed, Jul 26, 2017 at 08:07:37PM +0300, Dmitry Safonov wrote: > vDSO VMA address is saved in mm_context for the purpose of using > restorer from vDSO page to return to userspace after signal handling. > > In Checkpoint Restore in Userspace (CRIU) project we place vDSO VMA > on restore back to

Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource for SGMII interfaces

On 07/28/2017 07:23 AM, Tom Bogendoerfer wrote: > On Thu, Jul 27, 2017 at 03:39:58PM -0700, Laura Abbott wrote: >> I don't know the intricacies of the Mustang hardware but external >> aborts have been a symptom of missing clocks on other hardware. > > you are right, it's a missing clock. For

Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource for SGMII interfaces

On 07/28/2017 07:23 AM, Tom Bogendoerfer wrote: > On Thu, Jul 27, 2017 at 03:39:58PM -0700, Laura Abbott wrote: >> I don't know the intricacies of the Mustang hardware but external >> aborts have been a symptom of missing clocks on other hardware. > > you are right, it's a missing clock. For

Re: [RESEND PATCH] soc: ti: ti_sci_pm_domains: Populate name for genpd

Hi, On 07/28/2017 11:33 AM, Dave Gerlach wrote: > Commit b6a1d093f96b ("PM / Domains: Extend generic power domain > debugfs") now creates a debugfs directory for each genpd based on the > name of the genpd. Currently no name is given to the genpd created by > ti_sci_pm_domains driver so because of

Re: [RESEND PATCH] soc: ti: ti_sci_pm_domains: Populate name for genpd

Hi, On 07/28/2017 11:33 AM, Dave Gerlach wrote: > Commit b6a1d093f96b ("PM / Domains: Extend generic power domain > debugfs") now creates a debugfs directory for each genpd based on the > name of the genpd. Currently no name is given to the genpd created by > ti_sci_pm_domains driver so because of

[RESEND PATCH] soc: ti: ti_sci_pm_domains: Populate name for genpd

Commit b6a1d093f96b ("PM / Domains: Extend generic power domain debugfs") now creates a debugfs directory for each genpd based on the name of the genpd. Currently no name is given to the genpd created by ti_sci_pm_domains driver so because of this we see a NULL pointer dereferences when it is

[RESEND PATCH] soc: ti: ti_sci_pm_domains: Populate name for genpd

Commit b6a1d093f96b ("PM / Domains: Extend generic power domain debugfs") now creates a debugfs directory for each genpd based on the name of the genpd. Currently no name is given to the genpd created by ti_sci_pm_domains driver so because of this we see a NULL pointer dereferences when it is

[PATCH RESEND] f2fs: support journelled quota

From: Chao Yu This patch supports to enable f2fs to accept quota information through mount option: - {usr,grp,prj}jquota= - jqfmt= Then, in ->mount flow, we can recover quota file during log replaying, by this, journelled quota can be supported. Signed-off-by: Chao Yu

[PATCH RESEND] f2fs: support journelled quota

From: Chao Yu This patch supports to enable f2fs to accept quota information through mount option: - {usr,grp,prj}jquota= - jqfmt= Then, in ->mount flow, we can recover quota file during log replaying, by this, journelled quota can be supported. Signed-off-by: Chao Yu ---

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