Re: [PATCH 0/2] tools/memory-model: Model 'smp_store_mb()'

On Thu, Apr 12, 2018 at 02:22:48PM +0200, Andrea Parri wrote: > Hi, > > This (tiny) series adds 'smp_store_mb()' to the model (patch 1/2), and > it fixes a stylistic discrepancy in 'linux-kernel.def (patch 2/2). I applied them both, thank you! I had to apply 2/2 by hand for reasons that are not

Re: [PATCH 0/2] tools/memory-model: Model 'smp_store_mb()'

On Thu, Apr 12, 2018 at 02:22:48PM +0200, Andrea Parri wrote: > Hi, > > This (tiny) series adds 'smp_store_mb()' to the model (patch 1/2), and > it fixes a stylistic discrepancy in 'linux-kernel.def (patch 2/2). I applied them both, thank you! I had to apply 2/2 by hand for reasons that are not

[PATCH] radix tree test suite: fix mapshift build target

The following commit commit c6ce3e2fe3da ("radix tree test suite: Add config option for map shift") Introduced a phony makefile target called 'mapshift' that ends up generating the file generated/map-shift.h. This phony target was then added as a dependency of the top level 'targets' build

[PATCH] radix tree test suite: fix mapshift build target

The following commit commit c6ce3e2fe3da ("radix tree test suite: Add config option for map shift") Introduced a phony makefile target called 'mapshift' that ends up generating the file generated/map-shift.h. This phony target was then added as a dependency of the top level 'targets' build

INFO: rcu detected stall in d_walk

Hello, syzbot hit the following crash on upstream commit c17b0aadb7d8f87de56a4a374a8131519c0f7422 (Thu Apr 12 16:15:48 2018 +) Merge tag 'asm-generic' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic syzbot dashboard link:

INFO: rcu detected stall in d_walk

Hello, syzbot hit the following crash on upstream commit c17b0aadb7d8f87de56a4a374a8131519c0f7422 (Thu Apr 12 16:15:48 2018 +) Merge tag 'asm-generic' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic syzbot dashboard link:

Re: [PATCH v9 07/61] xarray: Add the xa_lock to the radix_tree_root

On Tue, Mar 13, 2018 at 7:25 AM, Matthew Wilcox wrote: > From: Matthew Wilcox > > This results in no change in structure size on 64-bit machines as it > fits in the padding between the gfp_t and the void *. 32-bit machines > will grow the structure

Re: [PATCH v9 07/61] xarray: Add the xa_lock to the radix_tree_root

On Tue, Mar 13, 2018 at 7:25 AM, Matthew Wilcox wrote: > From: Matthew Wilcox > > This results in no change in structure size on 64-bit machines as it > fits in the padding between the gfp_t and the void *. 32-bit machines > will grow the structure from 8 to 12 bytes. Almost all radix trees >

Re: [RFC PATCH 0/3] Interface for higher order contiguous allocations

On 04/12/2018 01:40 PM, Reinette Chatre wrote: > Hi Mike, > > On 2/15/2018 12:22 PM, Reinette Chatre wrote: >> On 2/12/2018 2:20 PM, Mike Kravetz wrote: >>> These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at: >>>

Re: [RFC PATCH 0/3] Interface for higher order contiguous allocations

On 04/12/2018 01:40 PM, Reinette Chatre wrote: > Hi Mike, > > On 2/15/2018 12:22 PM, Reinette Chatre wrote: >> On 2/12/2018 2:20 PM, Mike Kravetz wrote: >>> These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at: >>>

Re: [PATCH v7 [RESEND] 1/2] drivers: qcom: add command DB driver

Quoting Lina Iyer (2018-04-10 10:46:29) > On Fri, Apr 06 2018 at 17:23 -0600, Stephen Boyd wrote: > >Quoting Lina Iyer (2018-04-06 08:13:55) > >> From: Mahesh Sivasubramanian > >> > >> Command DB is a simple database in the shared memory of QCOM SoCs, that > >> provides

Re: [PATCH v7 [RESEND] 1/2] drivers: qcom: add command DB driver

Quoting Lina Iyer (2018-04-10 10:46:29) > On Fri, Apr 06 2018 at 17:23 -0600, Stephen Boyd wrote: > >Quoting Lina Iyer (2018-04-06 08:13:55) > >> From: Mahesh Sivasubramanian > >> > >> Command DB is a simple database in the shared memory of QCOM SoCs, that > >> provides information regarding

Re: [PATCH v4 6/7] dt-bindings: phy-qcom-usb2: Add support to override tuning values

Hi, On Tue, Apr 10, 2018 at 12:16 AM, Manu Gautam wrote: > > > On 4/10/2018 1:48 AM, Rob Herring wrote: >> On Thu, Mar 29, 2018 at 01:38:23PM -0700, Doug Anderson wrote: >>> Hi, >>> >>> On Thu, Mar 29, 2018 at 4:04 AM, Manu Gautam wrote: To

Re: [PATCH v4 6/7] dt-bindings: phy-qcom-usb2: Add support to override tuning values

Hi, On Tue, Apr 10, 2018 at 12:16 AM, Manu Gautam wrote: > > > On 4/10/2018 1:48 AM, Rob Herring wrote: >> On Thu, Mar 29, 2018 at 01:38:23PM -0700, Doug Anderson wrote: >>> Hi, >>> >>> On Thu, Mar 29, 2018 at 4:04 AM, Manu Gautam wrote: To improve eye diagram for PHYs on different boards

Re: [PATCH v4] mm: remove odd HAVE_PTE_SPECIAL

On Thu, 12 Apr 2018, Laurent Dufour wrote: > Remove the additional define HAVE_PTE_SPECIAL and rely directly on > CONFIG_ARCH_HAS_PTE_SPECIAL. > > There is no functional change introduced by this patch > > Signed-off-by: Laurent Dufour Acked-by: David Rientjes

Re: [PATCH v4] mm: remove odd HAVE_PTE_SPECIAL

On Thu, 12 Apr 2018, Laurent Dufour wrote: > Remove the additional define HAVE_PTE_SPECIAL and rely directly on > CONFIG_ARCH_HAS_PTE_SPECIAL. > > There is no functional change introduced by this patch > > Signed-off-by: Laurent Dufour Acked-by: David Rientjes

[PATCH] Documentation/process: updates to the PGP guide

Small tweaks to the Maintainer PGP guide: - Use --quick-addkey command that is compatible between GnuPG-2.2 and GnuPG-2.1 (which many people still have) - Add a note about the Nitrokey program - Warn that some devices can't change the passphrase before there are keys on the card

[PATCH] Documentation/process: updates to the PGP guide

Small tweaks to the Maintainer PGP guide: - Use --quick-addkey command that is compatible between GnuPG-2.2 and GnuPG-2.1 (which many people still have) - Add a note about the Nitrokey program - Warn that some devices can't change the passphrase before there are keys on the card

Re: [RFC PATCH 0/3] Interface for higher order contiguous allocations

Hi Mike, On 2/15/2018 12:22 PM, Reinette Chatre wrote: > On 2/12/2018 2:20 PM, Mike Kravetz wrote: >> These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at: >> http://lkml.kernel.org/r/21f1ec96-2822-1189-1c95-79a2bb491...@oracle.com >> >> One suggestion in that thread was to

Re: [RFC PATCH 0/3] Interface for higher order contiguous allocations

Hi Mike, On 2/15/2018 12:22 PM, Reinette Chatre wrote: > On 2/12/2018 2:20 PM, Mike Kravetz wrote: >> These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at: >> http://lkml.kernel.org/r/21f1ec96-2822-1189-1c95-79a2bb491...@oracle.com >> >> One suggestion in that thread was to

Re: [PATCH v4 2/7] phy: qcom-qmp: Enable pipe_clk before PHY initialization

Quoting Manu Gautam (2018-04-11 08:37:38) > > > > I ask because it may be easier to never expose these clks in Linux, hit > > the enable bits in the branches during clk driver probe, and then act > > like they never exist because we don't really use them. > This sounds better idea. Let me check if

Re: [PATCH v4 2/7] phy: qcom-qmp: Enable pipe_clk before PHY initialization

Quoting Manu Gautam (2018-04-11 08:37:38) > > > > I ask because it may be easier to never expose these clks in Linux, hit > > the enable bits in the branches during clk driver probe, and then act > > like they never exist because we don't really use them. > This sounds better idea. Let me check if

Re: [PATCH v4] proc: fixup copyright sign

Yup, this came through correctly: Content-Type: text/plain; charset=utf-8 and the patch looks fine too. Linus

Re: [PATCH v4] proc: fixup copyright sign

Yup, this came through correctly: Content-Type: text/plain; charset=utf-8 and the patch looks fine too. Linus

[PATCH v4 1/4] fpga: region: don't use drvdata in common fpga code

Changes to fpga_region_register function to not set drvdata. Setting drvdata is fine for DT based devices that will have one region per platform device. However PCIe based devices may have multiple FPGA regions under one PCIe device. Without these changes, the PCIe solution has to create an

[PATCH v4] proc: fixup copyright sign

Add copyright in two files before they get autorubberstamped. Signed-off-by: Alexey Dobriyan --- tools/testing/selftests/proc/proc-loadavg-001.c|2 +- tools/testing/selftests/proc/proc-self-map-files-001.c |2 +-

[PATCH v4 0/4] fpga: change api, don't use drive data

This patchset must go on top of Paolo Pisoli's "fpga: lattice machxo2: Add Lattice MachXO2 support" Don't set or use drvdata in the FPGA common manager/bridge/region code. Change API for manager, bridge, and region to each include functions for create, free, register, and unregister. This

[PATCH v4 1/4] fpga: region: don't use drvdata in common fpga code

Changes to fpga_region_register function to not set drvdata. Setting drvdata is fine for DT based devices that will have one region per platform device. However PCIe based devices may have multiple FPGA regions under one PCIe device. Without these changes, the PCIe solution has to create an

[PATCH v4] proc: fixup copyright sign

Add copyright in two files before they get autorubberstamped. Signed-off-by: Alexey Dobriyan --- tools/testing/selftests/proc/proc-loadavg-001.c|2 +- tools/testing/selftests/proc/proc-self-map-files-001.c |2 +- tools/testing/selftests/proc/proc-self-map-files-002.c |2 +-

[PATCH v4 0/4] fpga: change api, don't use drive data

This patchset must go on top of Paolo Pisoli's "fpga: lattice machxo2: Add Lattice MachXO2 support" Don't set or use drvdata in the FPGA common manager/bridge/region code. Change API for manager, bridge, and region to each include functions for create, free, register, and unregister. This

Re: [PATCH v4 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

On 12/04/2018 22:19, KarimAllah Ahmed wrote: > Update 'tsc_offset' on vmenty/vmexit of L2 guests to ensure that it always > captures the TSC_OFFSET of the running guest whether it is the L1 or L2 > guest. > > Cc: Jim Mattson > Cc: Paolo Bonzini > Cc:

Re: [PATCH v4 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

On 12/04/2018 22:19, KarimAllah Ahmed wrote: > Update 'tsc_offset' on vmenty/vmexit of L2 guests to ensure that it always > captures the TSC_OFFSET of the running guest whether it is the L1 or L2 > guest. > > Cc: Jim Mattson > Cc: Paolo Bonzini > Cc: Radim Krčmář > Cc: k...@vger.kernel.org >

[PATCH v4 4/4] fpga: region: change api, add fpga_region_create/free

Add fpga_region_create/free API functions. Change fpga_region_register to take FPGA region struct as the only parameter. Change fpga_region_unregister to return void. struct fpga_region *fpga_region_create(struct device *dev, struct fpga_manager *mgr,

[PATCH v4 4/4] fpga: region: change api, add fpga_region_create/free

Add fpga_region_create/free API functions. Change fpga_region_register to take FPGA region struct as the only parameter. Change fpga_region_unregister to return void. struct fpga_region *fpga_region_create(struct device *dev, struct fpga_manager *mgr,

[PATCH v4 3/4] fpga: bridge: change api, don't use drvdata

Change fpga_bridge_register to not set drvdata. This is to support the case where a PCIe device can have more than one bridge. Add API functions to create/free the fpga bridge struct. Change fpga_bridge_register/unregister to take FPGA bridge struct as the only parameter. struct fpga_bridge

[PATCH v4 3/4] fpga: bridge: change api, don't use drvdata

Change fpga_bridge_register to not set drvdata. This is to support the case where a PCIe device can have more than one bridge. Add API functions to create/free the fpga bridge struct. Change fpga_bridge_register/unregister to take FPGA bridge struct as the only parameter. struct fpga_bridge

[PATCH v4 2/4] fpga: manager: change api, don't use drvdata

Change fpga_mgr_register to not set or use drvdata. This supports the case where a PCIe device has more than one manager. Add fpga_mgr_create/free functions. Change fpga_mgr_register and fpga_mgr_unregister functions to take the mgr struct as their only parameter. struct fpga_manager

[PATCH v4 2/4] fpga: manager: change api, don't use drvdata

Change fpga_mgr_register to not set or use drvdata. This supports the case where a PCIe device has more than one manager. Add fpga_mgr_create/free functions. Change fpga_mgr_register and fpga_mgr_unregister functions to take the mgr struct as their only parameter. struct fpga_manager

Re: [PATCH 1/2] X86/KVM: Properly restore 'tsc_offset' when running an L2 guest

On Thu, 2018-04-12 at 22:21 +0200, Paolo Bonzini wrote: > On 12/04/2018 19:21, Raslan, KarimAllah wrote: > > > > Now looking further at the code, it seems that everywhere in the code > > tsc_offset is treated as the L01 TSC_OFFSET. > > > > Like here: > > > >         if

Re: [PATCH 1/2] X86/KVM: Properly restore 'tsc_offset' when running an L2 guest

On Thu, 2018-04-12 at 22:21 +0200, Paolo Bonzini wrote: > On 12/04/2018 19:21, Raslan, KarimAllah wrote: > > > > Now looking further at the code, it seems that everywhere in the code > > tsc_offset is treated as the L01 TSC_OFFSET. > > > > Like here: > > > >         if

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

> Can we plan on merging just the plain rseq parts *without* this all > first, and then see the cpu_opv thing as a "maybe future expansion" > part. That would be the right way to go. I doubt anybody really needs cpu_opv. We already have other code (e.g. vgettimeofday) which cannot be single

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

> Can we plan on merging just the plain rseq parts *without* this all > first, and then see the cpu_opv thing as a "maybe future expansion" > part. That would be the right way to go. I doubt anybody really needs cpu_opv. We already have other code (e.g. vgettimeofday) which cannot be single

Re: [PATCH 06/10] KVM/nVMX: Use kvm_vcpu_map when mapping the virtual APIC page

On 12/04/2018 19:57, Sean Christopherson wrote: > On Thu, Apr 12, 2018 at 04:38:39PM +0200, Paolo Bonzini wrote: >> On 21/02/2018 18:47, KarimAllah Ahmed wrote: >>> + >>> + if (kvm_vcpu_map(vcpu, >>> gpa_to_gfn(vmcs12->virtual_apic_page_addr), map)) >>> +

Re: [PATCH 06/10] KVM/nVMX: Use kvm_vcpu_map when mapping the virtual APIC page

On 12/04/2018 19:57, Sean Christopherson wrote: > On Thu, Apr 12, 2018 at 04:38:39PM +0200, Paolo Bonzini wrote: >> On 21/02/2018 18:47, KarimAllah Ahmed wrote: >>> + >>> + if (kvm_vcpu_map(vcpu, >>> gpa_to_gfn(vmcs12->virtual_apic_page_addr), map)) >>> +

Re: [PATCH 1/2] X86/KVM: Properly restore 'tsc_offset' when running an L2 guest

On 12/04/2018 19:21, Raslan, KarimAllah wrote: > Now looking further at the code, it seems that everywhere in the code > tsc_offset is treated as the L01 TSC_OFFSET. > > Like here: > >         if (vmcs12->cpu_based_vm_exec_control & > CPU_BASED_USE_TSC_OFFSETING) >

Re: [PATCH 1/2] X86/KVM: Properly restore 'tsc_offset' when running an L2 guest

On 12/04/2018 19:21, Raslan, KarimAllah wrote: > Now looking further at the code, it seems that everywhere in the code > tsc_offset is treated as the L01 TSC_OFFSET. > > Like here: > >         if (vmcs12->cpu_based_vm_exec_control & > CPU_BASED_USE_TSC_OFFSETING) >

[PATCH v4 2/2] kvm: nVMX: Introduce KVM_CAP_STATE

From: Jim Mattson For nested virtualization L0 KVM is managing a bit of state for L2 guests, this state can not be captured through the currently available IOCTLs. In fact the state captured through all of these IOCTLs is usually a mix of L1 and L2 state. It is also

[PATCH v4 2/2] kvm: nVMX: Introduce KVM_CAP_STATE

From: Jim Mattson For nested virtualization L0 KVM is managing a bit of state for L2 guests, this state can not be captured through the currently available IOCTLs. In fact the state captured through all of these IOCTLs is usually a mix of L1 and L2 state. It is also dependent on whether the L2

[PATCH v4 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

Update 'tsc_offset' on vmenty/vmexit of L2 guests to ensure that it always captures the TSC_OFFSET of the running guest whether it is the L1 or L2 guest. Cc: Jim Mattson Cc: Paolo Bonzini Cc: Radim Krčmář Cc: k...@vger.kernel.org

[PATCH v4 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

Update 'tsc_offset' on vmenty/vmexit of L2 guests to ensure that it always captures the TSC_OFFSET of the running guest whether it is the L1 or L2 guest. Cc: Jim Mattson Cc: Paolo Bonzini Cc: Radim Krčmář Cc: k...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Suggested-by: Paolo Bonzini

[GIT PULL] xfs: cleanups & fixes for 4.17

Hi Linus, Here's the second round of patches for XFS for 4.17. Most of these are code cleanups, but there are a couple of notable use-after-free bug fixes. This series has been run through a full xfstests run over the week and through a quick xfstests run against this morning's master, with no

[GIT PULL] xfs: cleanups & fixes for 4.17

Hi Linus, Here's the second round of patches for XFS for 4.17. Most of these are code cleanups, but there are a couple of notable use-after-free bug fixes. This series has been run through a full xfstests run over the week and through a quick xfstests run against this morning's master, with no

[GIT PULL] clk changes for v4.17

From: Stephen Boyd The following changes since commit e2749bb998701e21cdb8b34486b82fc1c051ab41: reset: modify the way reset lookup works for board files (2018-03-27 10:39:47 +0200) are available in the Git repository at:

[GIT PULL] clk changes for v4.17

From: Stephen Boyd The following changes since commit e2749bb998701e21cdb8b34486b82fc1c051ab41: reset: modify the way reset lookup works for board files (2018-03-27 10:39:47 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git

Re: [PATCH] proc: fixup (c) sign

On Thu, Apr 12, 2018 at 12:50 PM, Alexey Dobriyan wrote: > > I've checked earlier mails, mutt has been "guessing" outgoing encoding > by default. Let's try again. I think it still does. This email came with Content-Type: text/plain; charset=us-ascii which is what I'd

Re: [PATCH] proc: fixup (c) sign

On Thu, Apr 12, 2018 at 12:50 PM, Alexey Dobriyan wrote: > > I've checked earlier mails, mutt has been "guessing" outgoing encoding > by default. Let's try again. I think it still does. This email came with Content-Type: text/plain; charset=us-ascii which is what I'd expect if Mutt has a

Re: [PATCH] net: ethernet: ti: cpsw: fix tx vlan priority mapping

On 04/12/2018 09:25 AM, Ivan Khoronzhuk wrote: > The CPDMA_TX_PRIORITY_MAP in real is vlan pcp field priority mapping > register and basically replaces vlan pcp field for tagged packets. > So, set it to be 1:1 mapping. "Otherwise, it will cause unexpected change of egress vlan tagged packets,

Re: [PATCH] net: ethernet: ti: cpsw: fix tx vlan priority mapping

On 04/12/2018 09:25 AM, Ivan Khoronzhuk wrote: > The CPDMA_TX_PRIORITY_MAP in real is vlan pcp field priority mapping > register and basically replaces vlan pcp field for tagged packets. > So, set it to be 1:1 mapping. "Otherwise, it will cause unexpected change of egress vlan tagged packets,

Re: [PATCH 10/14] gpio: omap: Drop the concept of gpio banks not being able to lose context.

On 04/12/2018 09:22 AM, Tony Lindgren wrote: > * Keerthy [180412 03:56]: >> From: Russ Dill >> --- a/drivers/gpio/gpio-omap.c >> +++ b/drivers/gpio/gpio-omap.c >> @@ -68,7 +68,7 @@ struct gpio_bank { >> bool dbck_enabled; >> bool is_mpuio; >>

Re: [PATCH 10/14] gpio: omap: Drop the concept of gpio banks not being able to lose context.

On 04/12/2018 09:22 AM, Tony Lindgren wrote: > * Keerthy [180412 03:56]: >> From: Russ Dill >> --- a/drivers/gpio/gpio-omap.c >> +++ b/drivers/gpio/gpio-omap.c >> @@ -68,7 +68,7 @@ struct gpio_bank { >> bool dbck_enabled; >> bool is_mpuio; >> bool dbck_flag; >> -bool

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

On Thu, Apr 12, 2018 at 12:59 PM, Mathieu Desnoyers wrote: > > What are your concerns about page pinning ? Pretty much everything. It's the most complex part by far, and the vmalloc space is a limited resource on 32-bit architectures. > Do you have an

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

On Thu, Apr 12, 2018 at 12:59 PM, Mathieu Desnoyers wrote: > > What are your concerns about page pinning ? Pretty much everything. It's the most complex part by far, and the vmalloc space is a limited resource on 32-bit architectures. > Do you have an alternative approach in mind ? Do

Re: [PATCH 11/14] gpio: omap: Restore power_mode configuration at resume time

On 04/12/2018 09:39 AM, Tony Lindgren wrote: > * Keerthy [180412 03:56]: >> From: Dave Gerlach >> >> Commit 2dc983c565e0 ("gpio/omap: cleanup prepare_for_idle and >> resume_after_idle") introduces omap2_gpio_prepare_for_idle and >>

Re: [PATCH 11/14] gpio: omap: Restore power_mode configuration at resume time

On 04/12/2018 09:39 AM, Tony Lindgren wrote: > * Keerthy [180412 03:56]: >> From: Dave Gerlach >> >> Commit 2dc983c565e0 ("gpio/omap: cleanup prepare_for_idle and >> resume_after_idle") introduces omap2_gpio_prepare_for_idle and >> omap2_gpio_resume_after_idle to properly configure gpios that

Re: [PATCH v2] gpiolib: add hogs support for machine code

On Dienstag, 10. April 2018 22:30:28 CEST Bartosz Golaszewski wrote: > Board files constitute a significant part of the users of the legacy > GPIO framework. In many cases they only export a line and set its > desired value. We could use GPIO hogs for that like we do for DT and > ACPI but there's

Re: [PATCH v2] gpiolib: add hogs support for machine code

On Dienstag, 10. April 2018 22:30:28 CEST Bartosz Golaszewski wrote: > Board files constitute a significant part of the users of the legacy > GPIO framework. In many cases they only export a line and set its > desired value. We could use GPIO hogs for that like we do for DT and > ACPI but there's

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

- On Apr 12, 2018, at 3:43 PM, Linus Torvalds torva...@linux-foundation.org wrote: > On Thu, Apr 12, 2018 at 12:27 PM, Mathieu Desnoyers > wrote: >> The cpu_opv system call executes a vector of operations on behalf of >> user-space on a specific CPU with

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

- On Apr 12, 2018, at 3:43 PM, Linus Torvalds torva...@linux-foundation.org wrote: > On Thu, Apr 12, 2018 at 12:27 PM, Mathieu Desnoyers > wrote: >> The cpu_opv system call executes a vector of operations on behalf of >> user-space on a specific CPU with preemption disabled. It is inspired

Re: [PATCH 0/5] [GIT PULL] tracing: A few last minute clean up and fixes

On 04/12/18 15:46, Steven Rostedt wrote: > On Thu, 12 Apr 2018 14:28:45 -0400 > Steven Rostedt wrote: > >> Primary key fingerprint: 5ED9 A48F C54C 0A22 D1D0 804C EBC2 6CDB 5A56 DE73 >> Subkey fingerprint: B5D7 BDD5 67E0 67A3 EE0C 9FBE 3F0B D661 FC59 E3D3 > > Don't

Re: [PATCH 0/5] [GIT PULL] tracing: A few last minute clean up and fixes

On 04/12/18 15:46, Steven Rostedt wrote: > On Thu, 12 Apr 2018 14:28:45 -0400 > Steven Rostedt wrote: > >> Primary key fingerprint: 5ED9 A48F C54C 0A22 D1D0 804C EBC2 6CDB 5A56 DE73 >> Subkey fingerprint: B5D7 BDD5 67E0 67A3 EE0C 9FBE 3F0B D661 FC59 E3D3 > > Don't use this key. > >

Re: [PATCH 1/2] perf tools powerpc: Fix callchain ip filtering

On 04/13/2018 12:13 AM, Arnaldo Carvalho de Melo wrote: > > So, the author for the fixed-by patch here is Sukadev Bhattiprolu > , and the reporter for the problem that > patch fixed is Maynard Johnson , who also tested > that patch, I think it'd

Re: [PATCH 1/2] perf tools powerpc: Fix callchain ip filtering

On 04/13/2018 12:13 AM, Arnaldo Carvalho de Melo wrote: > > So, the author for the fixed-by patch here is Sukadev Bhattiprolu > , and the reporter for the problem that > patch fixed is Maynard Johnson , who also tested > that patch, I think it'd be better if they get CCed to have the >

[PATCH v3] proc: fixup copyright sign

Add copyright in two files before they get autorubberstamped. Signed-off-by: Alexey Dobriyan --- tools/testing/selftests/proc/proc-loadavg-001.c|2 +- tools/testing/selftests/proc/proc-self-map-files-001.c |2 +-

[PATCH v3] proc: fixup copyright sign

Add copyright in two files before they get autorubberstamped. Signed-off-by: Alexey Dobriyan --- tools/testing/selftests/proc/proc-loadavg-001.c|2 +- tools/testing/selftests/proc/proc-self-map-files-001.c |2 +- tools/testing/selftests/proc/proc-self-map-files-002.c |2 +-

[PATCH] powerpc/sparse: fix plain integer as NULL pointer warning

Trivial fix to remove the following sparse warnings: arch/powerpc/kernel/module_32.c:112:74: warning: Using plain integer as NULL pointer arch/powerpc/kernel/module_32.c:117:74: warning: Using plain integer as NULL pointer drivers/macintosh/via-pmu.c:1155:28: warning: Using plain integer

[PATCH] powerpc/sparse: fix plain integer as NULL pointer warning

Trivial fix to remove the following sparse warnings: arch/powerpc/kernel/module_32.c:112:74: warning: Using plain integer as NULL pointer arch/powerpc/kernel/module_32.c:117:74: warning: Using plain integer as NULL pointer drivers/macintosh/via-pmu.c:1155:28: warning: Using plain integer

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

On 4/12/2018 10:37 AM, Guenter Roeck wrote: On Thu, Apr 12, 2018 at 10:09:51AM -0700, Jae Hyun Yoo wrote: [ ... ] +static int find_core_index(struct peci_cputemp *priv, int channel) +{ +    int core_channel = channel - DEFAULT_CHANNEL_NUMS; +    int idx, found = 0; + +    for (idx = 0; idx <

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

On 4/12/2018 10:37 AM, Guenter Roeck wrote: On Thu, Apr 12, 2018 at 10:09:51AM -0700, Jae Hyun Yoo wrote: [ ... ] +static int find_core_index(struct peci_cputemp *priv, int channel) +{ +    int core_channel = channel - DEFAULT_CHANNEL_NUMS; +    int idx, found = 0; + +    for (idx = 0; idx <

[GIT PULL v2] tracing: A few last minute clean up and fixes

Linus, [ Yeah, I used bash up arrow to get the last tag I made, and added to it (without noticing it was ktest). Then I used Esc-. to get the tag name for the script, which handles both ktest and trace so it didn't realize it was wrong either, and just used it. Note, I'm using the

Re: [PATCH] proc: fixup (c) sign

On Thu, Apr 12, 2018 at 10:14:35AM -0700, Linus Torvalds wrote: > On Wed, Apr 11, 2018 at 1:19 PM, Alexey Dobriyan wrote: > > Andrew's scripts butchered it :-( > > Oh, it's not just Andrew. > > Git will fix up commit messages etc, but the actual *patch* will be > considered

[GIT PULL v2] tracing: A few last minute clean up and fixes

Linus, [ Yeah, I used bash up arrow to get the last tag I made, and added to it (without noticing it was ktest). Then I used Esc-. to get the tag name for the script, which handles both ktest and trace so it didn't realize it was wrong either, and just used it. Note, I'm using the

Re: [PATCH] proc: fixup (c) sign

On Thu, Apr 12, 2018 at 10:14:35AM -0700, Linus Torvalds wrote: > On Wed, Apr 11, 2018 at 1:19 PM, Alexey Dobriyan wrote: > > Andrew's scripts butchered it :-( > > Oh, it's not just Andrew. > > Git will fix up commit messages etc, but the actual *patch* will be > considered just "data". So if

Re: [PATCH 0/5] [GIT PULL] tracing: A few last minute clean up and fixes

On Thu, 12 Apr 2018 14:28:45 -0400 Steven Rostedt wrote: > Primary key fingerprint: 5ED9 A48F C54C 0A22 D1D0 804C EBC2 6CDB 5A56 DE73 > Subkey fingerprint: B5D7 BDD5 67E0 67A3 EE0C 9FBE 3F0B D661 FC59 E3D3 Don't use this key. Konstantin wanted me to make a ECC key,

Re: [PATCH 0/5] [GIT PULL] tracing: A few last minute clean up and fixes

On Thu, 12 Apr 2018 14:28:45 -0400 Steven Rostedt wrote: > Primary key fingerprint: 5ED9 A48F C54C 0A22 D1D0 804C EBC2 6CDB 5A56 DE73 > Subkey fingerprint: B5D7 BDD5 67E0 67A3 EE0C 9FBE 3F0B D661 FC59 E3D3 Don't use this key. Konstantin wanted me to make a ECC key, which I did. Here's

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

On Thu, Apr 12, 2018 at 12:27 PM, Mathieu Desnoyers wrote: > The cpu_opv system call executes a vector of operations on behalf of > user-space on a specific CPU with preemption disabled. It is inspired > by readv() and writev() system calls which take a "struct

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

On Thu, Apr 12, 2018 at 12:27 PM, Mathieu Desnoyers wrote: > The cpu_opv system call executes a vector of operations on behalf of > user-space on a specific CPU with preemption disabled. It is inspired > by readv() and writev() system calls which take a "struct iovec" > array as argument. Do we

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Am 12.04.2018 um 15:30 schrieb Vincent Guittot: > Heiner, Niklas, > > Le Thursday 12 Apr 2018 à 13:15:19 (+0200), Niklas Söderlund a écrit : >> Hi Vincent, >> >> Thanks for your feedback. >> >> On 2018-04-12 12:33:27 +0200, Vincent Guittot wrote: >>> Hi Niklas, >>> >>> On 12 April 2018 at 11:18,

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

Am 12.04.2018 um 15:30 schrieb Vincent Guittot: > Heiner, Niklas, > > Le Thursday 12 Apr 2018 à 13:15:19 (+0200), Niklas Söderlund a écrit : >> Hi Vincent, >> >> Thanks for your feedback. >> >> On 2018-04-12 12:33:27 +0200, Vincent Guittot wrote: >>> Hi Niklas, >>> >>> On 12 April 2018 at 11:18,

[RFC PATCH for 4.18 15/23] arm: Wire up cpu_opv system call

Signed-off-by: Mathieu Desnoyers CC: Russell King CC: Catalin Marinas CC: Will Deacon CC: Thomas Gleixner CC: Paul Turner CC: Andrew Hunter

[RFC PATCH for 4.18 15/23] arm: Wire up cpu_opv system call

Signed-off-by: Mathieu Desnoyers CC: Russell King CC: Catalin Marinas CC: Will Deacon CC: Thomas Gleixner CC: Paul Turner CC: Andrew Hunter CC: Peter Zijlstra CC: Andy Lutomirski CC: Andi Kleen CC: Dave Watson CC: Chris Lameter CC: Ingo Molnar CC: Ben Maurer CC: Steven Rostedt CC:

[RFC PATCH for 4.18 14/23] powerpc: Wire up cpu_opv system call

Signed-off-by: Mathieu Desnoyers CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: Michael Ellerman CC: Boqun Feng CC: Peter Zijlstra CC: "Paul E.

[RFC PATCH for 4.18 14/23] powerpc: Wire up cpu_opv system call

Signed-off-by: Mathieu Desnoyers CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: Michael Ellerman CC: Boqun Feng CC: Peter Zijlstra CC: "Paul E. McKenney" CC: linuxppc-...@lists.ozlabs.org --- arch/powerpc/include/asm/systbl.h | 1 + arch/powerpc/include/asm/unistd.h | 2 +-

[RFC PATCH for 4.18 06/23] x86: Wire up restartable sequence system call

Wire up the rseq system call on x86 32/64. This provides an ABI improving the speed of a user-space getcpu operation on x86 by removing the need to perform a function call, "lsl" instruction, or system call on the fast path, as well as improving the speed of user-space operations on per-cpu data.

[RFC PATCH for 4.18 06/23] x86: Wire up restartable sequence system call

Wire up the rseq system call on x86 32/64. This provides an ABI improving the speed of a user-space getcpu operation on x86 by removing the need to perform a function call, "lsl" instruction, or system call on the fast path, as well as improving the speed of user-space operations on per-cpu data.

[RFC PATCH for 4.18 18/23] rseq: selftests: Provide rseq library (v5)

This rseq helper library provides a user-space API to the rseq() system call. The rseq fast-path exposes the instruction pointer addresses where the rseq assembly blocks begin and end, as well as the associated abort instruction pointer, in the __rseq_table section. This section allows debuggers

[RFC PATCH for 4.18 18/23] rseq: selftests: Provide rseq library (v5)

This rseq helper library provides a user-space API to the rseq() system call. The rseq fast-path exposes the instruction pointer addresses where the rseq assembly blocks begin and end, as well as the associated abort instruction pointer, in the __rseq_table section. This section allows debuggers

[RFC PATCH for 4.18 03/23] arm: Add restartable sequences support

Call the rseq_handle_notify_resume() function on return to userspace if TIF_NOTIFY_RESUME thread flag is set. Perform fixup on the pre-signal frame when a signal is delivered on top of a restartable sequence critical section. Signed-off-by: Mathieu Desnoyers CC:

[RFC PATCH for 4.18 03/23] arm: Add restartable sequences support

Call the rseq_handle_notify_resume() function on return to userspace if TIF_NOTIFY_RESUME thread flag is set. Perform fixup on the pre-signal frame when a signal is delivered on top of a restartable sequence critical section. Signed-off-by: Mathieu Desnoyers CC: Russell King CC: Catalin

[RFC PATCH for 4.18 21/23] rseq: selftests: Provide basic percpu ops test

"basic_percpu_ops_test" is a slightly more "realistic" variant, implementing a few simple per-cpu operations and testing their correctness. Signed-off-by: Mathieu Desnoyers CC: Shuah Khan CC: Russell King CC:

[RFC PATCH for 4.18 13/23] x86: Wire up cpu_opv system call

Signed-off-by: Mathieu Desnoyers CC: "Paul E. McKenney" CC: Peter Zijlstra CC: Paul Turner CC: Thomas Gleixner CC: Andrew Hunter CC: Andy Lutomirski

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