Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, 12 Dec 2017, Dave Hansen wrote: > On 12/12/2017 11:21 AM, Thomas Gleixner wrote: > > The only critical interaction is the return to user path (user CS/SS) and > > we made sure with the LAR touching that these are precached in the CPU > > before we go into fragile exit code. > > How do we

Re: [PATCH v4 08/12] clk: qcom: Add KPSS ACC/GCC driver

On Fri, Dec 08, 2017 at 03:12:26PM +0530, Sricharan R wrote: > From: Stephen Boyd > > The ACC and GCC regions present in KPSSv1 contain registers to > control clocks and power to each Krait CPU and L2. For CPUfreq > purposes probe these devices and expose a mux clock that chooses > between PXO

Re: [PATCH v4 04/12] clk: qcom: Add HFPLL driver

On Fri, Dec 08, 2017 at 03:12:22PM +0530, Sricharan R wrote: > From: Stephen Boyd > > On some devices (MSM8974 for example), the HFPLLs are > instantiated within the Krait processor subsystem as separate > register regions. Add a driver for these PLLs so that we can >

Re: [PATCH v4 04/12] clk: qcom: Add HFPLL driver

On Fri, Dec 08, 2017 at 03:12:22PM +0530, Sricharan R wrote: > From: Stephen Boyd > > On some devices (MSM8974 for example), the HFPLLs are > instantiated within the Krait processor subsystem as separate > register regions. Add a driver for these PLLs so that we can > provide HFPLL clocks for

Re: [PATCHSET v2] blk-mq: reimplement timeout handling

On 12/12/2017 12:01 PM, Tejun Heo wrote: > Changes from the last version[1] > > - BLK_EH_RESET_TIMER handling fixed. > > - s/request->gstate_seqc/request->gstate_seq/ > > - READ_ONCE() added to blk_mq_rq_udpate_state(). > > - Removed left over blk_clear_rq_complete() invocation from >

Re: [PATCHSET v2] blk-mq: reimplement timeout handling

On 12/12/2017 12:01 PM, Tejun Heo wrote: > Changes from the last version[1] > > - BLK_EH_RESET_TIMER handling fixed. > > - s/request->gstate_seqc/request->gstate_seq/ > > - READ_ONCE() added to blk_mq_rq_udpate_state(). > > - Removed left over blk_clear_rq_complete() invocation from >

Re: [PATCH v1 5/7] iio: adc: ina2xx: Use a monotonic clock for delay calculation

On Sun, 10 Dec 2017 21:47:37 +0100 Stefan Brüns wrote: > On Sunday, December 10, 2017 6:31:57 PM CET Jonathan Cameron wrote: > > On Fri, 8 Dec 2017 18:41:50 +0100 > > > > Stefan Brüns wrote: > > > The iio timestamp clock is user

Re: [PATCH v1 5/7] iio: adc: ina2xx: Use a monotonic clock for delay calculation

On Sun, 10 Dec 2017 21:47:37 +0100 Stefan Brüns wrote: > On Sunday, December 10, 2017 6:31:57 PM CET Jonathan Cameron wrote: > > On Fri, 8 Dec 2017 18:41:50 +0100 > > > > Stefan Brüns wrote: > > > The iio timestamp clock is user selectable and may be non-monotonic. Also, > > > only part of

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On 12/12/2017 11:21 AM, Thomas Gleixner wrote: > The only critical interaction is the return to user path (user CS/SS) and > we made sure with the LAR touching that these are precached in the CPU > before we go into fragile exit code. How do we make sure that it _stays_ cached? Surely there is

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On 12/12/2017 11:21 AM, Thomas Gleixner wrote: > The only critical interaction is the return to user path (user CS/SS) and > we made sure with the LAR touching that these are precached in the CPU > before we go into fragile exit code. How do we make sure that it _stays_ cached? Surely there is

Re: [PATCH] KVM: PPC: Book3S HV: Fix pending_pri value in kvmppc_xive_get_icp()

On Tue, 2017-12-12 at 18:23 +0100, Laurent Vivier wrote: > When we migrate a VM from a POWER8 host (XICS) to a POWER9 host > (XICS-on-XIVE), we have an error: > > qemu-kvm: Unable to restore KVM interrupt controller state \ > (0xff00) for CPU 0: Invalid argument > > This is because

Re: [PATCH] KVM: PPC: Book3S HV: Fix pending_pri value in kvmppc_xive_get_icp()

On Tue, 2017-12-12 at 18:23 +0100, Laurent Vivier wrote: > When we migrate a VM from a POWER8 host (XICS) to a POWER9 host > (XICS-on-XIVE), we have an error: > > qemu-kvm: Unable to restore KVM interrupt controller state \ > (0xff00) for CPU 0: Invalid argument > > This is because

Re: [PATCH] PCI: qcom: add missing supplies required for msm8996

On Fri, Dec 08, 2017 at 09:20:53AM +, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > This patch adds supplies that are required for msm8996. Two of them vdda > and vdda-1p8 are analog supplies that go in to controller, and the rest > of

Re: [PATCH] PCI: qcom: add missing supplies required for msm8996

On Fri, Dec 08, 2017 at 09:20:53AM +, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > This patch adds supplies that are required for msm8996. Two of them vdda > and vdda-1p8 are analog supplies that go in to controller, and the rest > of the two vddpe's are supplies to

Re: [PATCH v1 3/7] iio: adc: ina2xx: Remove unneeded dummy read to clear CNVR flag

On Sun, 10 Dec 2017 21:53:42 +0100 Stefan Brüns wrote: > On Sunday, December 10, 2017 6:27:33 PM CET Jonathan Cameron wrote: > > On Fri, 8 Dec 2017 18:41:48 +0100 > > > > Stefan Brüns wrote: > > > Although the datasheet states the

Re: [PATCH v1 3/7] iio: adc: ina2xx: Remove unneeded dummy read to clear CNVR flag

On Sun, 10 Dec 2017 21:53:42 +0100 Stefan Brüns wrote: > On Sunday, December 10, 2017 6:27:33 PM CET Jonathan Cameron wrote: > > On Fri, 8 Dec 2017 18:41:48 +0100 > > > > Stefan Brüns wrote: > > > Although the datasheet states the CNVR flag is cleared by reading the > > > BUS_VOLTAGE

Re: [PATCH v3 30/33] dt-bindings: nds32 SoC Bindings

On Fri, Dec 08, 2017 at 05:12:13PM +0800, Greentime Hu wrote: > From: Greentime Hu > > This patch adds nds32 SoC(AE3XX and AG101P) binding documents. > > Signed-off-by: Greentime Hu > --- > .../devicetree/bindings/nds32/andestech-boards |

Re: [PATCH v3 30/33] dt-bindings: nds32 SoC Bindings

On Fri, Dec 08, 2017 at 05:12:13PM +0800, Greentime Hu wrote: > From: Greentime Hu > > This patch adds nds32 SoC(AE3XX and AG101P) binding documents. > > Signed-off-by: Greentime Hu > --- > .../devicetree/bindings/nds32/andestech-boards | 40 > > 1 file changed, 40

Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

On 12/12/2017 11:56 AM, Kees Cook wrote: On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott wrote: On 12/12/2017 11:23 AM, Kees Cook wrote: On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote: Hello, Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec:

Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

On 12/12/2017 11:56 AM, Kees Cook wrote: On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott wrote: On 12/12/2017 11:23 AM, Kees Cook wrote: On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote: Hello, Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK races with

Re: [PATCH v3 29/33] dt-bindings: nds32 CPU Bindings

On Fri, Dec 08, 2017 at 05:12:12PM +0800, Greentime Hu wrote: > From: Greentime Hu > > This patch adds nds32 CPU binding documents. > > Signed-off-by: Vincent Chen > Signed-off-by: Rick Chen > Signed-off-by: Zong Li

Re: [PATCH v3 29/33] dt-bindings: nds32 CPU Bindings

On Fri, Dec 08, 2017 at 05:12:12PM +0800, Greentime Hu wrote: > From: Greentime Hu > > This patch adds nds32 CPU binding documents. > > Signed-off-by: Vincent Chen > Signed-off-by: Rick Chen > Signed-off-by: Zong Li > Signed-off-by: Greentime Hu > --- >

Re: [PATCH v2 2/3] dt-bindings: Add optional nvmem BD address bindings to ti,wlink-st

On Thu, Dec 07, 2017 at 08:57:39PM -0600, David Lechner wrote: > This adds optional nvmem consumer properties to the ti,wlink-st device tree > bindings to allow specifying the BD address. > > Signed-off-by: David Lechner > --- > > v2 changes: > * Renamed "mac-address" to

Re: [PATCH v2 2/3] dt-bindings: Add optional nvmem BD address bindings to ti,wlink-st

On Thu, Dec 07, 2017 at 08:57:39PM -0600, David Lechner wrote: > This adds optional nvmem consumer properties to the ti,wlink-st device tree > bindings to allow specifying the BD address. > > Signed-off-by: David Lechner > --- > > v2 changes: > * Renamed "mac-address" to "bd-address" > * Fixed

Re: [PATCH v1 0/7] iio: adc: ina2xx: Rework CNVR alignment, fix busy loops

On Sun, 10 Dec 2017 21:22:13 +0100 Stefan Brüns wrote: > On Sunday, December 10, 2017 6:36:54 PM CET Jonathan Cameron wrote: > > On Fri, 8 Dec 2017 18:41:45 +0100 > > > > Stefan Brüns wrote: > > > Currently, the INA2xx driver may

Re: [PATCH v1 0/7] iio: adc: ina2xx: Rework CNVR alignment, fix busy loops

On Sun, 10 Dec 2017 21:22:13 +0100 Stefan Brüns wrote: > On Sunday, December 10, 2017 6:36:54 PM CET Jonathan Cameron wrote: > > On Fri, 8 Dec 2017 18:41:45 +0100 > > > > Stefan Brüns wrote: > > > Currently, the INA2xx driver may end up causing 100% load on a single core > > > and fully

Re: [PATCH v2 1/2] Documentation: devicetree: Add DT bindings to xlnx_vcu driver

On Thu, Dec 07, 2017 at 01:31:15PM -0800, Dhaval Shah wrote: > Add Device Tree binding document for logicoreIP. This logicoreIP > provides the isolation between the processing system and > programmable logic. Also provides the clock related information. > > Signed-off-by: Dhaval Shah

Re: [PATCH v2 1/2] Documentation: devicetree: Add DT bindings to xlnx_vcu driver

On Thu, Dec 07, 2017 at 01:31:15PM -0800, Dhaval Shah wrote: > Add Device Tree binding document for logicoreIP. This logicoreIP > provides the isolation between the processing system and > programmable logic. Also provides the clock related information. > > Signed-off-by: Dhaval Shah > --- >

Re: [patch 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

On Mon, Dec 11, 2017 at 02:11:55PM -0800, David Rientjes wrote: > --- a/drivers/misc/sgi-gru/grutlbpurge.c > +++ b/drivers/misc/sgi-gru/grutlbpurge.c > @@ -298,6 +298,7 @@ struct gru_mm_struct *gru_register_mmu_notifier(void) > return ERR_PTR(-ENOMEM); >

Re: [patch 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

On Mon, Dec 11, 2017 at 02:11:55PM -0800, David Rientjes wrote: > --- a/drivers/misc/sgi-gru/grutlbpurge.c > +++ b/drivers/misc/sgi-gru/grutlbpurge.c > @@ -298,6 +298,7 @@ struct gru_mm_struct *gru_register_mmu_notifier(void) > return ERR_PTR(-ENOMEM); >

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

On Tue, 12 Dec 2017 19:45:32 +, Al Viro wrote: > On Tue, Dec 12, 2017 at 06:20:02AM +, Al Viro wrote: > > > Umm... What's wrong with > > > > #define FIELD_FOO 0,4 > > #define FIELD_BAR 6,12 > > #define FIELD_BAZ 18,14 > > > > A macro can bloody well expand to any sequence of tokens -

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

On Tue, 12 Dec 2017 19:45:32 +, Al Viro wrote: > On Tue, Dec 12, 2017 at 06:20:02AM +, Al Viro wrote: > > > Umm... What's wrong with > > > > #define FIELD_FOO 0,4 > > #define FIELD_BAR 6,12 > > #define FIELD_BAZ 18,14 > > > > A macro can bloody well expand to any sequence of tokens -

[PATCH] vfio: Simplify capability helper

The vfio_info_add_capability() helper requires the caller to pass a capability ID, which it then uses to fill in header fields, assuming hard coded versions. This makes for an awkward and rigid interface. The only thing we want this helper to do is allocate sufficient space in the caps buffer and

[PATCH] vfio: Simplify capability helper

The vfio_info_add_capability() helper requires the caller to pass a capability ID, which it then uses to fill in header fields, assuming hard coded versions. This makes for an awkward and rigid interface. The only thing we want this helper to do is allocate sufficient space in the caps buffer and

Re: [RFC 0/5] Add I3C subsystem

On Mon, 31 Jul 2017 21:17:45 +0200 Wolfram Sang wrote: > Hi Boris, > > > This patch series is a proposal for a new I3C [1] subsystem. > > Nice. Good luck with that! > > Some hi-level comments from me related to I2C. I can't say a lot more > because the specs are not

Re: [RFC 0/5] Add I3C subsystem

On Mon, 31 Jul 2017 21:17:45 +0200 Wolfram Sang wrote: > Hi Boris, > > > This patch series is a proposal for a new I3C [1] subsystem. > > Nice. Good luck with that! > > Some hi-level comments from me related to I2C. I can't say a lot more > because the specs are not public :( > > > - the

Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott wrote: > On 12/12/2017 11:23 AM, Kees Cook wrote: >> >> On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote: >>> >>> Hello, >>> >>> Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK >>> races

Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

On Tue, Dec 12, 2017 at 11:52 AM, Laura Abbott wrote: > On 12/12/2017 11:23 AM, Kees Cook wrote: >> >> On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote: >>> >>> Hello, >>> >>> Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK >>> races with prlimit()" that made it into

Re: [PATCH 5/8] power: supply: axp20x_battery: add support for AXP813

On Mon, 11 Dec 2017 09:35:43 +0100 Quentin Schulz wrote: > Hi Jonathan, > > On 10/12/2017 17:49, Jonathan Cameron wrote: > > On Mon, 4 Dec 2017 15:12:51 +0100 > > Quentin Schulz wrote: > > > >> The X-Powers AXP813 PMIC

Re: [PATCH 5/8] power: supply: axp20x_battery: add support for AXP813

On Mon, 11 Dec 2017 09:35:43 +0100 Quentin Schulz wrote: > Hi Jonathan, > > On 10/12/2017 17:49, Jonathan Cameron wrote: > > On Mon, 4 Dec 2017 15:12:51 +0100 > > Quentin Schulz wrote: > > > >> The X-Powers AXP813 PMIC has got some slight differences from > >> AXP20X/AXP22X PMICs: > >> -

Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

On 12/12/2017 11:23 AM, Kees Cook wrote: On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote: Hello, Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK races with prlimit()" that made it into 4.14.4 effectively changes the default hard RLIMIT_STACK on

Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

On 12/12/2017 11:23 AM, Kees Cook wrote: On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote: Hello, Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK races with prlimit()" that made it into 4.14.4 effectively changes the default hard RLIMIT_STACK on machines with

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, Dec 12, 2017 at 11:21 AM, Thomas Gleixner wrote: > > That has nothing to do with the user installed LDT. The kernel does not use > and rely on LDT at all. Sure it does. We end up loading the selector for %gs and %fs, and those selectors end up being connected with

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, Dec 12, 2017 at 11:21 AM, Thomas Gleixner wrote: > > That has nothing to do with the user installed LDT. The kernel does not use > and rely on LDT at all. Sure it does. We end up loading the selector for %gs and %fs, and those selectors end up being connected with whatever user-mode has

Re: UDL's fbdev doesn't work for user-space apps

Hi Pavel, On Sat, 2017-12-09 at 18:20 +0100, Pavel Machek wrote: > On Mon 2017-12-04 11:50:40, Jose Abreu wrote: > > > > Hi Alexey, > > > > On 04-12-2017 11:32, Alexey Brodkin wrote: > > > > > > My first [probably incorrect] assumption is Xserver requires fbdev > > > (/dev/fbX) > > > and it

Re: UDL's fbdev doesn't work for user-space apps

Hi Pavel, On Sat, 2017-12-09 at 18:20 +0100, Pavel Machek wrote: > On Mon 2017-12-04 11:50:40, Jose Abreu wrote: > > > > Hi Alexey, > > > > On 04-12-2017 11:32, Alexey Brodkin wrote: > > > > > > My first [probably incorrect] assumption is Xserver requires fbdev > > > (/dev/fbX) > > > and it

Re: [PATCH net-next v5 2/2] net: thunderx: add timestamping support

On Mon, 2017-12-11 at 15:36 -0800, Richard Cochran wrote: > On Mon, Dec 11, 2017 at 05:14:31PM +0300, Aleksey Makarov wrote: > > @@ -880,6 +889,46 @@ static void nic_pause_frame(struct nicpf *nic, int vf, > > struct pfc *cfg) > > } > > } > > > > +/* Enable or disable HW timestamping by BGX

Re: [PATCH net-next v5 2/2] net: thunderx: add timestamping support

On Mon, 2017-12-11 at 15:36 -0800, Richard Cochran wrote: > On Mon, Dec 11, 2017 at 05:14:31PM +0300, Aleksey Makarov wrote: > > @@ -880,6 +889,46 @@ static void nic_pause_frame(struct nicpf *nic, int vf, > > struct pfc *cfg) > > } > > } > > > > +/* Enable or disable HW timestamping by BGX

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

On Tue, Dec 12, 2017 at 06:20:02AM +, Al Viro wrote: > Umm... What's wrong with > > #define FIELD_FOO 0,4 > #define FIELD_BAR 6,12 > #define FIELD_BAZ 18,14 > > A macro can bloody well expand to any sequence of tokens - le32_get_bits(v, > FIELD_BAZ) > will become le32_get_bits(v, 18, 14)

Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()

On Tue, Dec 12, 2017 at 06:20:02AM +, Al Viro wrote: > Umm... What's wrong with > > #define FIELD_FOO 0,4 > #define FIELD_BAR 6,12 > #define FIELD_BAZ 18,14 > > A macro can bloody well expand to any sequence of tokens - le32_get_bits(v, > FIELD_BAZ) > will become le32_get_bits(v, 18, 14)

Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

On Tuesday, 12 December 2017 20:23:47 CET Kees Cook wrote: > This is an interesting state for the system to be in, though, it means > AT_SECURE is being set for virtually all processes too? I would expect > that might break a lot too (but clearly it hasn't). Not really. AT_SECURE is set only for

Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

On Tuesday, 12 December 2017 20:23:47 CET Kees Cook wrote: > This is an interesting state for the system to be in, though, it means > AT_SECURE is being set for virtually all processes too? I would expect > that might break a lot too (but clearly it hasn't). Not really. AT_SECURE is set only for

Re: [PATCH] ARM: CPU hotplug: Delegate complete() to surviving CPU

On Tue, Dec 12, 2017 at 05:37:59PM +, Russell King - ARM Linux wrote: > On Tue, Dec 12, 2017 at 09:20:59AM -0800, Paul E. McKenney wrote: > > The ARM implementation of arch_cpu_idle_dead() invokes complete(), but > > does so after RCU has stopped watching the outgoing CPU, which results > > in

Re: [PATCH] ARM: CPU hotplug: Delegate complete() to surviving CPU

On Tue, Dec 12, 2017 at 05:37:59PM +, Russell King - ARM Linux wrote: > On Tue, Dec 12, 2017 at 09:20:59AM -0800, Paul E. McKenney wrote: > > The ARM implementation of arch_cpu_idle_dead() invokes complete(), but > > does so after RCU has stopped watching the outgoing CPU, which results > > in

[PATCH v3] igb: Free IRQs when device is hotplugged

Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon hotplugging my kernel would immediately crash due to igb: [ 680.825801] kernel BUG at drivers/pci/msi.c:352! [ 680.828388] invalid opcode: [#1] SMP [ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit

[PATCH v3] igb: Free IRQs when device is hotplugged

Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon hotplugging my kernel would immediately crash due to igb: [ 680.825801] kernel BUG at drivers/pci/msi.c:352! [ 680.828388] invalid opcode: [#1] SMP [ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit

Re: [PATCH] ARM: CPU hotplug: Delegate complete() to surviving CPU

On Tue, Dec 12, 2017 at 07:40:46PM +0200, Baruch Siach wrote: > Hi Paul, > > On Tue, Dec 12, 2017 at 09:20:59AM -0800, Paul E. McKenney wrote: > > The ARM implementation of arch_cpu_idle_dead() invokes complete(), but > > does so after RCU has stopped watching the outgoing CPU, which results > >

Re: [PATCH] ARM: CPU hotplug: Delegate complete() to surviving CPU

On Tue, Dec 12, 2017 at 07:40:46PM +0200, Baruch Siach wrote: > Hi Paul, > > On Tue, Dec 12, 2017 at 09:20:59AM -0800, Paul E. McKenney wrote: > > The ARM implementation of arch_cpu_idle_dead() invokes complete(), but > > does so after RCU has stopped watching the outgoing CPU, which results > >

[PATCH 2/2] crypto: seqiv - Remove unused alg/spawn variable

This patch remove two unused variable and some dead "code" using it. Fixes: 92932d03c2b3 ("crypto: seqiv - Remove AEAD compatibility code") Signed-off-by: Corentin Labbe --- crypto/seqiv.c | 5 - 1 file changed, 5 deletions(-) diff --git a/crypto/seqiv.c

[PATCH 2/2] crypto: seqiv - Remove unused alg/spawn variable

This patch remove two unused variable and some dead "code" using it. Fixes: 92932d03c2b3 ("crypto: seqiv - Remove AEAD compatibility code") Signed-off-by: Corentin Labbe --- crypto/seqiv.c | 5 - 1 file changed, 5 deletions(-) diff --git a/crypto/seqiv.c b/crypto/seqiv.c index

[PATCH 1/2] crypto: echainiv - Remove unused alg/spawn variable

This patch remove two unused variable and some dead "code" using it. Fixes: 66008d4230f6 ("crypto: echainiv - Remove AEAD compatibility code") Signed-off-by: Corentin Labbe --- crypto/echainiv.c | 5 - 1 file changed, 5 deletions(-) diff --git a/crypto/echainiv.c

[PATCH 1/2] crypto: echainiv - Remove unused alg/spawn variable

This patch remove two unused variable and some dead "code" using it. Fixes: 66008d4230f6 ("crypto: echainiv - Remove AEAD compatibility code") Signed-off-by: Corentin Labbe --- crypto/echainiv.c | 5 - 1 file changed, 5 deletions(-) diff --git a/crypto/echainiv.c b/crypto/echainiv.c index

Re: [PATCH v2] PCI: keystone: fix interrupt-controller-node lookup

On Tue, Dec 12, 2017 at 06:07:31PM +, Lorenzo Pieralisi wrote: > On Tue, Dec 12, 2017 at 11:25:37AM -0600, Bjorn Helgaas wrote: > > On Mon, Dec 11, 2017 at 10:42:33AM +, Lorenzo Pieralisi wrote: > > > On Mon, Dec 11, 2017 at 11:29:55AM +0100, Johan Hovold wrote: > > > > On Fri, Nov 17,

Re: [PATCH v2] PCI: keystone: fix interrupt-controller-node lookup

On Tue, Dec 12, 2017 at 06:07:31PM +, Lorenzo Pieralisi wrote: > On Tue, Dec 12, 2017 at 11:25:37AM -0600, Bjorn Helgaas wrote: > > On Mon, Dec 11, 2017 at 10:42:33AM +, Lorenzo Pieralisi wrote: > > > On Mon, Dec 11, 2017 at 11:29:55AM +0100, Johan Hovold wrote: > > > > On Fri, Nov 17,

Re: [PATCH 1/2] PCI: rcar: Fix use-after-free in probe error path

On Thu, Dec 07, 2017 at 11:15:19AM +0100, Geert Uytterhoeven wrote: > If CONFIG_DEBUG_SLAB=y, and no PCIe card is inserted, the kernel crashes > during probe on r8a7791/koelsch: > > rcar-pcie fe00.pcie: PCIe link down > Unable to handle kernel paging request at virtual address

Re: [PATCH 1/2] PCI: rcar: Fix use-after-free in probe error path

On Thu, Dec 07, 2017 at 11:15:19AM +0100, Geert Uytterhoeven wrote: > If CONFIG_DEBUG_SLAB=y, and no PCIe card is inserted, the kernel crashes > during probe on r8a7791/koelsch: > > rcar-pcie fe00.pcie: PCIe link down > Unable to handle kernel paging request at virtual address

[PATCH] Revert "exec: avoid RLIMIT_STACK races with prlimit()"

This reverts commit 04e35f4495dd560db30c25efca4eecae8ec8c375. SELinux runs with secureexec for all non-"noatsecure" domain transitions, which means lots of processes end up hitting the stack hard-limit change that was introduced in order to fix a race with prlimit(). That race fix will need to be

[PATCH] Revert "exec: avoid RLIMIT_STACK races with prlimit()"

This reverts commit 04e35f4495dd560db30c25efca4eecae8ec8c375. SELinux runs with secureexec for all non-"noatsecure" domain transitions, which means lots of processes end up hitting the stack hard-limit change that was introduced in order to fix a race with prlimit(). That race fix will need to be

Re: [PATCH v4] printk: Add console owner and waiter logic to load balance console writes

On Tue, 12 Dec 2017 14:39:21 +0900 Sergey Senozhatsky wrote: > p.s. > frankly, I don't see any "locking issues" in Steven's patch. Should I push out another revision of mine? -- Steve

Re: [PATCH v4] printk: Add console owner and waiter logic to load balance console writes

On Tue, 12 Dec 2017 14:39:21 +0900 Sergey Senozhatsky wrote: > p.s. > frankly, I don't see any "locking issues" in Steven's patch. Should I push out another revision of mine? -- Steve

Re: [patch 11/16] x86/ldt: Force access bit for CS/SS

> On Dec 12, 2017, at 11:05 AM, Linus Torvalds > wrote: > >> On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote: >> >> There is one exception; IRET will immediately load CS/SS and unrecoverably >> #GP. To avoid this issue access the LDT

Re: [patch 11/16] x86/ldt: Force access bit for CS/SS

> On Dec 12, 2017, at 11:05 AM, Linus Torvalds > wrote: > >> On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote: >> >> There is one exception; IRET will immediately load CS/SS and unrecoverably >> #GP. To avoid this issue access the LDT descriptors used by CS/SS before >> the IRET to

Re: [PATCH v2 2/2] dm unstripe: Add documentation for unstripe target

On Tue, Dec 12, 2017 at 01:10:13PM -0500, Mike Snitzer wrote: > On Mon, Dec 11 2017 at 11:00am -0500, > Scott Bauer wrote: > > OK, but I'm left wondering: why doesn't the user avoid striping across > the cores? > > Do the Intel NVMe drives not provide the ability to

Re: [PATCH v2 2/2] dm unstripe: Add documentation for unstripe target

On Tue, Dec 12, 2017 at 01:10:13PM -0500, Mike Snitzer wrote: > On Mon, Dec 11 2017 at 11:00am -0500, > Scott Bauer wrote: > > OK, but I'm left wondering: why doesn't the user avoid striping across > the cores? > > Do the Intel NVMe drives not provide the ability to present 1 device per > NVMe

Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote: > Hello, > > Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK > races with prlimit()" that made it into 4.14.4 effectively changes the default > hard RLIMIT_STACK on machines with SELinux (seen on Fedora

Re: System-wide hard RLIMIT_STACK in 4.14.4+ w/ SELinux

On Tue, Dec 12, 2017 at 2:58 AM, Tomáš Trnka wrote: > Hello, > > Commit 04e35f4495dd560db30c25efca4eecae8ec8c375 "exec: avoid RLIMIT_STACK > races with prlimit()" that made it into 4.14.4 effectively changes the default > hard RLIMIT_STACK on machines with SELinux (seen on Fedora 27). > >

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, 12 Dec 2017, Linus Torvalds wrote: > On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote: > > From: Thomas Gleixner > > > > When the LDT is mapped RO, the CPU will write fault the first time it uses > > a segment descriptor in order to set the

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, 12 Dec 2017, Linus Torvalds wrote: > On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote: > > From: Thomas Gleixner > > > > When the LDT is mapped RO, the CPU will write fault the first time it uses > > a segment descriptor in order to set the ACCESS bit (for some reason it > >

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

Hello Jason, On 12/12/2017 07:57 PM, Jason Gunthorpe wrote: > On Tue, Dec 12, 2017 at 12:38:00PM +0100, Javier Martinez Canillas wrote: > >> I'm not familiar with LPC so please let me know if my assumptions are wrong, >> but I find suspicious that a driver for a single device attached to the bus

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

Hello Jason, On 12/12/2017 07:57 PM, Jason Gunthorpe wrote: > On Tue, Dec 12, 2017 at 12:38:00PM +0100, Javier Martinez Canillas wrote: > >> I'm not familiar with LPC so please let me know if my assumptions are wrong, >> but I find suspicious that a driver for a single device attached to the bus

Re: [patch 11/16] x86/ldt: Force access bit for CS/SS

On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote: > > There is one exception; IRET will immediately load CS/SS and unrecoverably > #GP. To avoid this issue access the LDT descriptors used by CS/SS before > the IRET to userspace. Ok, so the other patch made me nervous,

Re: [patch 11/16] x86/ldt: Force access bit for CS/SS

On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote: > > There is one exception; IRET will immediately load CS/SS and unrecoverably > #GP. To avoid this issue access the LDT descriptors used by CS/SS before > the IRET to userspace. Ok, so the other patch made me nervous, this just makes me go

Re: [patch 11/16] x86/ldt: Force access bit for CS/SS

On Tue, Dec 12, 2017 at 07:41:39PM +0100, Thomas Gleixner wrote: > The pages are populated _before_ the new ldt is installed. So no memory > pressure issue, nothing. If the populate fails, then modify_ldt() returns > with an error. Also, these pages are not visible to reclaim. They're not

Re: [patch 11/16] x86/ldt: Force access bit for CS/SS

On Tue, Dec 12, 2017 at 07:41:39PM +0100, Thomas Gleixner wrote: > The pages are populated _before_ the new ldt is installed. So no memory > pressure issue, nothing. If the populate fails, then modify_ldt() returns > with an error. Also, these pages are not visible to reclaim. They're not

[PATCH 1/6] blk-mq: protect completion path with RCU

Currently, blk-mq protects only the issue path with RCU. This patch puts the completion path under the same RCU protection. This will be used to synchronize issue/completion against timeout by later patches, which will also add the comments. Signed-off-by: Tejun Heo ---

[PATCH 1/6] blk-mq: protect completion path with RCU

Currently, blk-mq protects only the issue path with RCU. This patch puts the completion path under the same RCU protection. This will be used to synchronize issue/completion against timeout by later patches, which will also add the comments. Signed-off-by: Tejun Heo --- block/blk-mq.c | 16

[PATCH 3/6] blk-mq: use blk_mq_rq_state() instead of testing REQ_ATOM_COMPLETE

blk_mq_check_inflight() and blk_mq_poll_hybrid_sleep() test REQ_ATOM_COMPLETE to determine the request state. Both uses are speculative and we can test REQ_ATOM_STARTED and blk_mq_rq_state() for equivalent results. Replace the tests. This will allow removing REQ_ATOM_COMPLETE usages from

[PATCH 3/6] blk-mq: use blk_mq_rq_state() instead of testing REQ_ATOM_COMPLETE

blk_mq_check_inflight() and blk_mq_poll_hybrid_sleep() test REQ_ATOM_COMPLETE to determine the request state. Both uses are speculative and we can test REQ_ATOM_STARTED and blk_mq_rq_state() for equivalent results. Replace the tests. This will allow removing REQ_ATOM_COMPLETE usages from

[PATCH 5/6] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

After the recent updates to use generation number and state based synchronization, blk-mq no longer depends on REQ_ATOM_COMPLETE for anything. Remove all REQ_ATOM_COMPLETE usages. This removes atomic bitops from hot paths too. v2: Removed blk_clear_rq_complete() from blk_mq_rq_timed_out().

[PATCH 5/6] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

After the recent updates to use generation number and state based synchronization, blk-mq no longer depends on REQ_ATOM_COMPLETE for anything. Remove all REQ_ATOM_COMPLETE usages. This removes atomic bitops from hot paths too. v2: Removed blk_clear_rq_complete() from blk_mq_rq_timed_out().

[PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

Currently, blk-mq timeout path synchronizes against the usual issue/completion path using a complex scheme involving atomic bitflags, REQ_ATOM_*, memory barriers and subtle memory coherence rules. Unfortunatley, it contains quite a few holes. There's a complex dancing around REQ_ATOM_STARTED and

[PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

Currently, blk-mq timeout path synchronizes against the usual issue/completion path using a complex scheme involving atomic bitflags, REQ_ATOM_*, memory barriers and subtle memory coherence rules. Unfortunatley, it contains quite a few holes. There's a complex dancing around REQ_ATOM_STARTED and

[PATCH 6/6] blk-mq: remove REQ_ATOM_STARTED

After the recent updates to use generation number and state based synchronization, we can easily replace REQ_ATOM_STARTED usages by adding an extra state to distinguish completed but not yet freed state. Add MQ_RQ_COMPLETE and replace REQ_ATOM_STARTED usages with blk_mq_rq_state() tests.

[PATCH 6/6] blk-mq: remove REQ_ATOM_STARTED

After the recent updates to use generation number and state based synchronization, we can easily replace REQ_ATOM_STARTED usages by adding an extra state to distinguish completed but not yet freed state. Add MQ_RQ_COMPLETE and replace REQ_ATOM_STARTED usages with blk_mq_rq_state() tests.

[PATCH 4/6] blk-mq: make blk_abort_request() trigger timeout path

With issue/complete and timeout paths now using the generation number and state based synchronization, blk_abort_request() is the only one which depends on REQ_ATOM_COMPLETE for arbitrating completion. There's no reason for blk_abort_request() to be a completely separate path. This patch makes

[PATCH 4/6] blk-mq: make blk_abort_request() trigger timeout path

With issue/complete and timeout paths now using the generation number and state based synchronization, blk_abort_request() is the only one which depends on REQ_ATOM_COMPLETE for arbitrating completion. There's no reason for blk_abort_request() to be a completely separate path. This patch makes

[PATCHSET v2] blk-mq: reimplement timeout handling

Changes from the last version[1] - BLK_EH_RESET_TIMER handling fixed. - s/request->gstate_seqc/request->gstate_seq/ - READ_ONCE() added to blk_mq_rq_udpate_state(). - Removed left over blk_clear_rq_complete() invocation from blk_mq_rq_timed_out(). Currently, blk-mq timeout path synchronizes

[PATCHSET v2] blk-mq: reimplement timeout handling

Changes from the last version[1] - BLK_EH_RESET_TIMER handling fixed. - s/request->gstate_seqc/request->gstate_seq/ - READ_ONCE() added to blk_mq_rq_udpate_state(). - Removed left over blk_clear_rq_complete() invocation from blk_mq_rq_timed_out(). Currently, blk-mq timeout path synchronizes

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote: > From: Thomas Gleixner > > When the LDT is mapped RO, the CPU will write fault the first time it uses > a segment descriptor in order to set the ACCESS bit (for some reason it > doesn't always

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote: > From: Thomas Gleixner > > When the LDT is mapped RO, the CPU will write fault the first time it uses > a segment descriptor in order to set the ACCESS bit (for some reason it > doesn't always observe that it already preset). Catch the

<    8   9   10   11   12   13   14   15   16   17   >