Re: [PATCH 1/2] Move kfree_call_rcu() to slab_common.c

Hi Boqun, Thanks a lot for all your guidance and for catching the cut and paster error. Please see inline. On 01/03/2018 05:38 PM, Boqun Feng wrote: But you introduced a bug here, you should use rcu_state_p instead of _sched_state as the third parameter for __call_rcu(). Please re-read:

Re: [PATCH 1/2] Move kfree_call_rcu() to slab_common.c

Hi Boqun, Thanks a lot for all your guidance and for catching the cut and paster error. Please see inline. On 01/03/2018 05:38 PM, Boqun Feng wrote: But you introduced a bug here, you should use rcu_state_p instead of _sched_state as the third parameter for __call_rcu(). Please re-read:

Re: [ANNOUNCE] Git v2.16.0-rc0

Hi, On Thu, 28 Dec 2017, Junio C Hamano wrote: > An early preview release Git v2.16.0-rc0 is now available for > testing at the usual places. And a corresponding Git for Windows prerelease is also available: https://github.com/git-for-windows/git/releases/tag/v2.16.0-rc0.windows.1 Ciao,

Re: [ANNOUNCE] Git v2.16.0-rc0

Hi, On Thu, 28 Dec 2017, Junio C Hamano wrote: > An early preview release Git v2.16.0-rc0 is now available for > testing at the usual places. And a corresponding Git for Windows prerelease is also available: https://github.com/git-for-windows/git/releases/tag/v2.16.0-rc0.windows.1 Ciao,

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

> For kernel, we may be able to annonate "tainted" pointers. But then > there's quite a lot of code in userspace... What will need to be > modified? Just JITs? Setuid programs? You never go from one user process to another except via the kernel. We have no hardware scheduling going on. That means

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

> For kernel, we may be able to annonate "tainted" pointers. But then > there's quite a lot of code in userspace... What will need to be > modified? Just JITs? Setuid programs? You never go from one user process to another except via the kernel. We have no hardware scheduling going on. That means

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 4, 2018 at 12:16 PM, Thomas Voegtle wrote: > > Attached a screenshot. > Is that useful? Are there some debug options I can add? Not much of an oops, because the SIGSEGV happens in user space. The only reason you get any kernel stack printout at all is because 'init'

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 4, 2018 at 12:16 PM, Thomas Voegtle wrote: > > Attached a screenshot. > Is that useful? Are there some debug options I can add? Not much of an oops, because the SIGSEGV happens in user space. The only reason you get any kernel stack printout at all is because 'init' dying will make

Re: [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts

On 01/04/2018 12:00 PM, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote: >> >> That is a minor inefficiency only, but we can eliminate it by saving >> the MSR when entering the NMI in save_paranoid and restoring it when >> exiting the NMI. > > Any hints as to what

Re: [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts

On 01/04/2018 12:00 PM, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote: >> >> That is a minor inefficiency only, but we can eliminate it by saving >> the MSR when entering the NMI in save_paranoid and restoring it when >> exiting the NMI. > > Any hints as to what

[PATCH] mtdoops: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Thu, 4 Jan 2018 21:10:56 +0100 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH] mtdoops: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Thu, 4 Jan 2018 21:10:56 +0100 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/mtd/mtdoops.c | 9 +++-- 1 file changed, 3

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On 04/01/18 20:05, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: >> From: David Woodhouse >> >> We are impervious to the indirect branch prediction attack with retpoline >> but firmware won't be, so we still need to set IBRS to protect >> firmware

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On 04/01/18 20:05, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: >> From: David Woodhouse >> >> We are impervious to the indirect branch prediction attack with retpoline >> but firmware won't be, so we still need to set IBRS to protect >> firmware code execution when

Re: [PATCH v3] gpio: winbond: add driver

On 04.01.2018 18:35, Andy Shevchenko wrote: > On Thu, 2018-01-04 at 00:41 +0100, Maciej S. Szmigiero wrote: >> On 03.01.2018 20:05, Andy Shevchenko wrote: >>> On Sat, 2017-12-30 at 22:02 +0100, Maciej S. Szmigiero wrote: This commit adds GPIO driver for Winbond Super I/Os. > >>> First of

Re: [PATCH v3] gpio: winbond: add driver

On 04.01.2018 18:35, Andy Shevchenko wrote: > On Thu, 2018-01-04 at 00:41 +0100, Maciej S. Szmigiero wrote: >> On 03.01.2018 20:05, Andy Shevchenko wrote: >>> On Sat, 2017-12-30 at 22:02 +0100, Maciej S. Szmigiero wrote: This commit adds GPIO driver for Winbond Super I/Os. > >>> First of

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On Thu, Jan 04, 2018 at 09:56:47AM -0800, Tim Chen wrote: > There are 2 ways to control IBRS > > 1. At boot time > noibrs kernel boot parameter will disable IBRS usage > > Otherwise if the above parameters are not specified, the system > will enable ibrs and ibpb usage if the cpu supports

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, 4 Jan 2018, Greg Kroah-Hartman wrote: On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system. The same kernel binary

Re: [PATCH 6/7] x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature

On Thu, Jan 04, 2018 at 09:56:47AM -0800, Tim Chen wrote: > There are 2 ways to control IBRS > > 1. At boot time > noibrs kernel boot parameter will disable IBRS usage > > Otherwise if the above parameters are not specified, the system > will enable ibrs and ibpb usage if the cpu supports

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, 4 Jan 2018, Greg Kroah-Hartman wrote: On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system. The same kernel binary

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

On Thu, 2018-01-04 at 17:50 +0200, Jani Nikula wrote: > On Thu, 04 Jan 2018, Knut Omang wrote: > > Add scripts/runchecks which has generic support for running > > checker tools in a convenient and user friendly way that > > the author hopes can contribute to rein in issues

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

On Thu, 2018-01-04 at 17:50 +0200, Jani Nikula wrote: > On Thu, 04 Jan 2018, Knut Omang wrote: > > Add scripts/runchecks which has generic support for running > > checker tools in a convenient and user friendly way that > > the author hopes can contribute to rein in issues detected > > by these

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 4, 2018 at 8:38 AM, Pavel Tatashin wrote: > I am getting the following panic when trying to boot 4.4.110rc1 on > Intel(R) Xeon(R) CPU E5-2630: > > [5.923489] BUG: unable to handle kernel NULL pointer dereference at > 000d > [5.932259] IP: [] >

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 4, 2018 at 8:38 AM, Pavel Tatashin wrote: > I am getting the following panic when trying to boot 4.4.110rc1 on > Intel(R) Xeon(R) CPU E5-2630: > > [5.923489] BUG: unable to handle kernel NULL pointer dereference at > 000d > [5.932259] IP: [] >

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: > > When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a > segfault and the kernel panics (attempted to kill init). > The VM host is a Haswell system. > > The same kernel binary boots fine on a (other) Haswell system.

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: > > When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a > segfault and the kernel panics (attempted to kill init). > The VM host is a Haswell system. > > The same kernel binary boots fine on a (other) Haswell system.

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On Thu, 2018-01-04 at 21:05 +0100, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: > > > > From: David Woodhouse > > > > We are impervious to the indirect branch prediction attack with > > retpoline > > but firmware won't be, so we still need to set

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On Thu, 2018-01-04 at 21:05 +0100, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: > > > > From: David Woodhouse > > > > We are impervious to the indirect branch prediction attack with > > retpoline > > but firmware won't be, so we still need to set IBRS to protect >

Re: [PATCH v3 9/9] arch: sh: migor: Use new renesas-ceu camera driver

Hi Jacopo, Thank you for the patch. On Thursday, 4 January 2018 18:03:17 EET Jacopo Mondi wrote: > Migo-R platform uses sh_mobile_ceu camera driver, which is now being > replaced by a proper V4L2 camera driver named 'renesas-ceu'. > > Move Migo-R platform to use the v4l2 renesas-ceu camera

Re: [PATCH v3 9/9] arch: sh: migor: Use new renesas-ceu camera driver

Hi Jacopo, Thank you for the patch. On Thursday, 4 January 2018 18:03:17 EET Jacopo Mondi wrote: > Migo-R platform uses sh_mobile_ceu camera driver, which is now being > replaced by a proper V4L2 camera driver named 'renesas-ceu'. > > Move Migo-R platform to use the v4l2 renesas-ceu camera

Re: Avoid speculative indirect calls in kernel

On 01/04/2018 01:33 PM, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 3:26 AM, Pavel Machek wrote: >> On Wed 2018-01-03 15:51:35, Linus Torvalds wrote: >>> >>> A *competent* CPU engineer would fix this by making sure speculation >>> doesn't happen across protection domains. Maybe

Re: Avoid speculative indirect calls in kernel

On 01/04/2018 01:33 PM, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 3:26 AM, Pavel Machek wrote: >> On Wed 2018-01-03 15:51:35, Linus Torvalds wrote: >>> >>> A *competent* CPU engineer would fix this by making sure speculation >>> doesn't happen across protection domains. Maybe even a L1 I$

Re: Bricked x86 CPU with software?

Hi! > In all my years of extensive experience writing drivers and kernels, I never > came across a situation > where you could brick an x86 CPU. Not until recently, when I was working on > debugging a piece of > code and I bricked an Intel CPU. I am not talking about an experimental >

Re: Bricked x86 CPU with software?

Hi! > In all my years of extensive experience writing drivers and kernels, I never > came across a situation > where you could brick an x86 CPU. Not until recently, when I was working on > debugging a piece of > code and I bricked an Intel CPU. I am not talking about an experimental >

Re: Avoid speculative indirect calls in kernel

On Thu, 2018-01-04 at 14:00 -0600, Tom Lendacky wrote: > Yes, lfence is sufficient.  As long as the target is in the register > before the lfence and we jump through the register all is good, i.e.: Thanks. Can I have a Reviewed-by: for this then please:

Re: Avoid speculative indirect calls in kernel

On Thu, 2018-01-04 at 14:00 -0600, Tom Lendacky wrote: > Yes, lfence is sufficient.  As long as the target is in the register > before the lfence and we jump through the register all is good, i.e.: Thanks. Can I have a Reviewed-by: for this then please:

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: > From: David Woodhouse > > We are impervious to the indirect branch prediction attack with retpoline > but firmware won't be, so we still need to set IBRS to protect > firmware code execution when calling into firmware

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: > From: David Woodhouse > > We are impervious to the indirect branch prediction attack with retpoline > but firmware won't be, so we still need to set IBRS to protect > firmware code execution when calling into firmware at runtime. Wait,

Re: [PATCH v5 01/12] dt-bindings: panel: lvds: Document power-supply property

Hi Maxime, On Thursday, 4 January 2018 21:44:36 EET Maxime Ripard wrote: > On Fri, Dec 22, 2017 at 02:08:20PM +0200, Laurent Pinchart wrote: > > On Thursday, 21 December 2017 13:02:27 EET Maxime Ripard wrote: > >> The power-supply property is used by a vast majority of panels, > >> including

Re: [PATCH v5 01/12] dt-bindings: panel: lvds: Document power-supply property

Hi Maxime, On Thursday, 4 January 2018 21:44:36 EET Maxime Ripard wrote: > On Fri, Dec 22, 2017 at 02:08:20PM +0200, Laurent Pinchart wrote: > > On Thursday, 21 December 2017 13:02:27 EET Maxime Ripard wrote: > >> The power-supply property is used by a vast majority of panels, > >> including

Re: [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts

On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote: > > That is a minor inefficiency only, but we can eliminate it by saving > the MSR when entering the NMI in save_paranoid and restoring it when > exiting the NMI. Any hints as to what exactly "minor" means in cycles here? :) thanks,

Re: [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts

On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote: > > That is a minor inefficiency only, but we can eliminate it by saving > the MSR when entering the NMI in save_paranoid and restoring it when > exiting the NMI. Any hints as to what exactly "minor" means in cycles here? :) thanks,

Re: Avoid speculative indirect calls in kernel

On 1/4/2018 10:15 AM, David Woodhouse wrote: > On Thu, 2018-01-04 at 15:29 +, Woodhouse, David wrote: >> >>> With the GCC -mindirect-branch=thunk-external support, and microcode, >>> Xen will make a boot-time choice between using Retpoline, Lfence (which >>> is the better AMD option, and

Re: Avoid speculative indirect calls in kernel

On 1/4/2018 10:15 AM, David Woodhouse wrote: > On Thu, 2018-01-04 at 15:29 +, Woodhouse, David wrote: >> >>> With the GCC -mindirect-branch=thunk-external support, and microcode, >>> Xen will make a boot-time choice between using Retpoline, Lfence (which >>> is the better AMD option, and

Re: Avoid speculative indirect calls in kernel

+ Jeff Law, Nick Clifton On 01/04/2018 03:20 AM, Woodhouse, David wrote: > On Thu, 2018-01-04 at 03:11 +0100, Paolo Bonzini wrote: >> On 04/01/2018 02:59, Alan Cox wrote: But then, exactly because the retpoline approach adds quite some cruft and leaves something to be desired, why even

Re: Avoid speculative indirect calls in kernel

+ Jeff Law, Nick Clifton On 01/04/2018 03:20 AM, Woodhouse, David wrote: > On Thu, 2018-01-04 at 03:11 +0100, Paolo Bonzini wrote: >> On 04/01/2018 02:59, Alan Cox wrote: But then, exactly because the retpoline approach adds quite some cruft and leaves something to be desired, why even

Re: [PATCH 1/7] x86/feature: Detect the x86 feature to control Speculation

On Thu, Jan 04, 2018 at 09:56:42AM -0800, Tim Chen wrote: > cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature > IA32_SPEC_CTRL (0x48) and IA32_PRED_CMD (0x49) > IA32_SPEC_CTRL, bit0 – Indirect Branch Restricted Speculation (IBRS) > IA32_PRED_CMD, bit0 – Indirect Branch

Re: [PATCH 1/7] x86/feature: Detect the x86 feature to control Speculation

On Thu, Jan 04, 2018 at 09:56:42AM -0800, Tim Chen wrote: > cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature > IA32_SPEC_CTRL (0x48) and IA32_PRED_CMD (0x49) > IA32_SPEC_CTRL, bit0 – Indirect Branch Restricted Speculation (IBRS) > IA32_PRED_CMD, bit0 – Indirect Branch

Re: [PATCH v2 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate

Hi, On Tue, Dec 26, 2017 at 10:12:25PM +1100, Jonathan Liu wrote: > We should check if the best match has been set before comparing it. > > Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support") > Signed-off-by: Jonathan Liu > --- > drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c |

Re: [PATCH v2 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate

Hi, On Tue, Dec 26, 2017 at 10:12:25PM +1100, Jonathan Liu wrote: > We should check if the best match has been set before comparing it. > > Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support") > Signed-off-by: Jonathan Liu > --- > drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +- > 1 file

Re: [PATCH] ASoC: codecs: dmic: Use channel map for configs with a single mic

+ Brian & Dylan El Thu, Jan 04, 2018 at 11:48:48AM -0800 Matthias Kaehlcke ha dit: > The DMIC DAI driver specifies a number of 1 to 8 channels for each DAI. > The actual number of mics can currently not be configured in the device > tree or audio glue, but is derived from the min/max channels of

Re: [PATCH] ASoC: codecs: dmic: Use channel map for configs with a single mic

+ Brian & Dylan El Thu, Jan 04, 2018 at 11:48:48AM -0800 Matthias Kaehlcke ha dit: > The DMIC DAI driver specifies a number of 1 to 8 channels for each DAI. > The actual number of mics can currently not be configured in the device > tree or audio glue, but is derived from the min/max channels of

Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

On 04/01/18 12:22 PM, Jason Gunthorpe wrote: This seems really clunky since we are going to want to do this same logic all over the place. I'd be much happier if dma_map_sg can tell the memory is P2P or not from the scatterlist or dir arguments and not require the callers to have this. We

Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()

On 04/01/18 12:22 PM, Jason Gunthorpe wrote: This seems really clunky since we are going to want to do this same logic all over the place. I'd be much happier if dma_map_sg can tell the memory is P2P or not from the scatterlist or dir arguments and not require the callers to have this. We

proposal for meltdown-workaround with low overhead

Hi all, This is my first post here and I hope it is fine. I will subscribe tomorrow to this list, so please take me in CC for answers now. As Meltdown-Issue depends on allowing to cause many exceptions (usually : accessing an invalid address), we could restrict this misusage easy. My rough

proposal for meltdown-workaround with low overhead

Hi all, This is my first post here and I hope it is fine. I will subscribe tomorrow to this list, so please take me in CC for answers now. As Meltdown-Issue depends on allowing to cause many exceptions (usually : accessing an invalid address), we could restrict this misusage easy. My rough

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: > > When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a > segfault and the kernel panics (attempted to kill init). > The VM host is a Haswell system. > > The same kernel binary boots fine on a (other) Haswell system.

Re: [PATCH v1 00/15] ASoC: fsl_ssi: Clean up - program flow level

On Thu, Jan 4, 2018 at 11:48 AM, Nicolin Chen wrote: > On Tue, Jan 02, 2018 at 03:28:11PM -0800, Caleb Crome wrote: > >> tested this patch set on MX6 SSI against broonie for-next (4.15-rc5), >> no problems. >> Do I send a separate Tested-by for each patch, or just the

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: > > When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a > segfault and the kernel panics (attempted to kill init). > The VM host is a Haswell system. > > The same kernel binary boots fine on a (other) Haswell system.

Re: [PATCH v1 00/15] ASoC: fsl_ssi: Clean up - program flow level

On Thu, Jan 4, 2018 at 11:48 AM, Nicolin Chen wrote: > On Tue, Jan 02, 2018 at 03:28:11PM -0800, Caleb Crome wrote: > >> tested this patch set on MX6 SSI against broonie for-next (4.15-rc5), >> no problems. >> Do I send a separate Tested-by for each patch, or just the 00/15 one? > >> Tested-by:

[PATCH] ASoC: codecs: dmic: Use channel map for configs with a single mic

The DMIC DAI driver specifies a number of 1 to 8 channels for each DAI. The actual number of mics can currently not be configured in the device tree or audio glue, but is derived from the min/max channels of the CPU and codec DAI. A typical CPU DAI has two or more channels, in consequence a single

[PATCH] ASoC: codecs: dmic: Use channel map for configs with a single mic

The DMIC DAI driver specifies a number of 1 to 8 channels for each DAI. The actual number of mics can currently not be configured in the device tree or audio glue, but is derived from the min/max channels of the CPU and codec DAI. A typical CPU DAI has two or more channels, in consequence a single

Re: [PATCH v5 1/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer

On 04/01/2018 15:06, Greentime Hu wrote: > Hi, Daniel: > > 2018-01-04 21:50 GMT+08:00 Daniel Lezcano : >> >> Hi, >> >> sorry I missed your answer. Comments below. >> >> On 13/12/2017 07:06, Greentime Hu wrote: >>> Hi, Daniel: >>> >>> 2017-12-12 18:05 GMT+08:00 Daniel

Re: [PATCH v5 1/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer

On 04/01/2018 15:06, Greentime Hu wrote: > Hi, Daniel: > > 2018-01-04 21:50 GMT+08:00 Daniel Lezcano : >> >> Hi, >> >> sorry I missed your answer. Comments below. >> >> On 13/12/2017 07:06, Greentime Hu wrote: >>> Hi, Daniel: >>> >>> 2017-12-12 18:05 GMT+08:00 Daniel Lezcano : On 12/12/2017

Re: [PATCH v1 00/15] ASoC: fsl_ssi: Clean up - program flow level

On Tue, Jan 02, 2018 at 03:28:11PM -0800, Caleb Crome wrote: > tested this patch set on MX6 SSI against broonie for-next (4.15-rc5), > no problems. > Do I send a separate Tested-by for each patch, or just the 00/15 one? > Tested-by: Caleb Crome I will include your Tested-by

Re: [PATCH v1 00/15] ASoC: fsl_ssi: Clean up - program flow level

On Tue, Jan 02, 2018 at 03:28:11PM -0800, Caleb Crome wrote: > tested this patch set on MX6 SSI against broonie for-next (4.15-rc5), > no problems. > Do I send a separate Tested-by for each patch, or just the 00/15 one? > Tested-by: Caleb Crome I will include your Tested-by to each patch in

Re: [PATCH 4.14 00/14] 4.14.12-stable review

On Thu, Jan 04, 2018 at 01:09:17PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.12 release. > There are 14 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.14 00/14] 4.14.12-stable review

On Thu, Jan 04, 2018 at 01:09:17PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.12 release. > There are 14 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 0/7] IBRS patch series

On Thu, 2018-01-04 at 19:40 +, Andrew Cooper wrote: > > Also remember that sibling threads share a BTB, so you can't rely on > isolated straight-line codepath on the current cpu for safety. (e.g. by > issuing an IBPB on every entry to supervisor mode). That is just one of a whole litany of

Re: [PATCH 0/7] IBRS patch series

On Thu, 2018-01-04 at 19:40 +, Andrew Cooper wrote: > > Also remember that sibling threads share a BTB, so you can't rely on > isolated straight-line codepath on the current cpu for safety. (e.g. by > issuing an IBPB on every entry to supervisor mode). That is just one of a whole litany of

Re: [PATCH v5 01/12] dt-bindings: panel: lvds: Document power-supply property

Hi Laurent, On Fri, Dec 22, 2017 at 02:08:20PM +0200, Laurent Pinchart wrote: > Hi Maxime, > > Thank you for the patch. > > On Thursday, 21 December 2017 13:02:27 EET Maxime Ripard wrote: > > The power-supply property is used by a vast majority of panels, including > > panel-simple. Let's

Re: [PATCH v5 01/12] dt-bindings: panel: lvds: Document power-supply property

Hi Laurent, On Fri, Dec 22, 2017 at 02:08:20PM +0200, Laurent Pinchart wrote: > Hi Maxime, > > Thank you for the patch. > > On Thursday, 21 December 2017 13:02:27 EET Maxime Ripard wrote: > > The power-supply property is used by a vast majority of panels, including > > panel-simple. Let's

Re: [PATCH 4.4 00/37] 4.4.110-stable review

When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system. The same kernel binary boots fine on a (other) Haswell system. I tried: 4.4.110-rc1 broken 4.4.109 ok 4.9.75-rc1 ok

Re: [PATCH 4.4 00/37] 4.4.110-stable review

When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system. The same kernel binary boots fine on a (other) Haswell system. I tried: 4.4.110-rc1 broken 4.4.109 ok 4.9.75-rc1 ok

Re: [PATCH v1 05/15] ASoC: fsl_ssi: Clean up helper functions of trigger()

On Mon, Jan 01, 2018 at 10:59:30PM +0100, Maciej S. Szmigiero wrote: > > +static void fsl_ssi_config_enable(struct fsl_ssi *ssi, bool tx) > > + srcr = vals[tx].srcr; > > + stcr = vals[tx].stcr; > > + sier = vals[tx].sier; > > Implicit assumption here that RX == 0,

Re: [PATCH v1 05/15] ASoC: fsl_ssi: Clean up helper functions of trigger()

On Mon, Jan 01, 2018 at 10:59:30PM +0100, Maciej S. Szmigiero wrote: > > +static void fsl_ssi_config_enable(struct fsl_ssi *ssi, bool tx) > > + srcr = vals[tx].srcr; > > + stcr = vals[tx].stcr; > > + sier = vals[tx].sier; > > Implicit assumption here that RX == 0,

Re: [PATCH v1 03/15] ASoC: fsl_ssi: Rename fsl_ssi_disable_val macro

On Mon, Jan 01, 2018 at 10:29:24PM +0100, Maciej S. Szmigiero wrote: > > @@ -445,16 +445,10 @@ static void fsl_ssi_config(struct fsl_ssi *ssi, bool > > enable, > > bool tx = >regvals[TX] == vals; > > + /* Check if the opposite stream is active */ > > + aactive = ssi->streams & BIT(!tx);

Re: [PATCH v1 03/15] ASoC: fsl_ssi: Rename fsl_ssi_disable_val macro

On Mon, Jan 01, 2018 at 10:29:24PM +0100, Maciej S. Szmigiero wrote: > > @@ -445,16 +445,10 @@ static void fsl_ssi_config(struct fsl_ssi *ssi, bool > > enable, > > bool tx = >regvals[TX] == vals; > > + /* Check if the opposite stream is active */ > > + aactive = ssi->streams & BIT(!tx);

Re: [PATCH 0/7] IBRS patch series

On 04/01/18 19:33, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: >> On Skylake the target for a 'ret' instruction may also come from the >> BTB. So if you ever let the RSB (which remembers where the 'call's came >> from get empty, you end up

Re: [PATCH 0/7] IBRS patch series

On 04/01/18 19:33, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: >> On Skylake the target for a 'ret' instruction may also come from the >> BTB. So if you ever let the RSB (which remembers where the 'call's came >> from get empty, you end up vulnerable. > That

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu 2018-01-04 02:47:51, Jiri Kosina wrote: > On Thu, 4 Jan 2018, Alan Cox wrote: > > > > If the CPU speculation can cause these kinds of side-effects, it just > > > must > > > not happen, full stop. > > > > At which point your performance will resemble that of a 2012 atom > > processor at

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu 2018-01-04 02:47:51, Jiri Kosina wrote: > On Thu, 4 Jan 2018, Alan Cox wrote: > > > > If the CPU speculation can cause these kinds of side-effects, it just > > > must > > > not happen, full stop. > > > > At which point your performance will resemble that of a 2012 atom > > processor at

Re: [PATCH 0/7] IBRS patch series

On Thu, 2018-01-04 at 11:33 -0800, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: > > > > On Skylake the target for a 'ret' instruction may also come from the > > BTB. So if you ever let the RSB (which remembers where the 'call's came > > from

Re: [PATCH 0/7] IBRS patch series

On Thu, 2018-01-04 at 11:33 -0800, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: > > > > On Skylake the target for a 'ret' instruction may also come from the > > BTB. So if you ever let the RSB (which remembers where the 'call's came > > from get empty, you end

Re: "bad pmd" errors + oops with KPTI on 4.14.11 after loading X.509 certs

On Thu, Jan 04, 2018 at 01:28:59PM +0100, Thomas Gleixner wrote: > On Wed, 3 Jan 2018, Andy Lutomirski wrote: > > Our memory map code is utter shite. This kind of bug should not be > > possible without a giant warning at boot that something is screwed up. > > You're right it's utter shite and

Re: "bad pmd" errors + oops with KPTI on 4.14.11 after loading X.509 certs

On Thu, Jan 04, 2018 at 01:28:59PM +0100, Thomas Gleixner wrote: > On Wed, 3 Jan 2018, Andy Lutomirski wrote: > > Our memory map code is utter shite. This kind of bug should not be > > possible without a giant warning at boot that something is screwed up. > > You're right it's utter shite and

Re: BUG: free active (active state 0) object type: work_struct hint: strp_work

On Thu, Jan 4, 2018 at 4:10 AM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6bb8824732f69de0f233ae6b1a8158e149627b38 > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1

Re: BUG: free active (active state 0) object type: work_struct hint: strp_work

On Thu, Jan 4, 2018 at 4:10 AM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6bb8824732f69de0f233ae6b1a8158e149627b38 > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

Re: [PATCH 0/7] IBRS patch series

On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: > > On Skylake the target for a 'ret' instruction may also come from the > BTB. So if you ever let the RSB (which remembers where the 'call's came > from get empty, you end up vulnerable. That sounds like it could cause

Re: [PATCH 0/7] IBRS patch series

On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: > > On Skylake the target for a 'ret' instruction may also come from the > BTB. So if you ever let the RSB (which remembers where the 'call's came > from get empty, you end up vulnerable. That sounds like it could cause mispredicts, but it

[PATCH 1/2] mtdconcat: Delete an error message for a failed memory allocation in mtd_concat_create()

From: Markus Elfring Date: Thu, 4 Jan 2018 19:55:10 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 2/2] mtdconcat: Improve a size determination in concat_erase()

From: Markus Elfring Date: Thu, 4 Jan 2018 20:00:27 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 1/2] mtdconcat: Delete an error message for a failed memory allocation in mtd_concat_create()

From: Markus Elfring Date: Thu, 4 Jan 2018 19:55:10 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/mtd/mtdconcat.c | 7 ++- 1 file changed, 2 insertions(+),

[PATCH 2/2] mtdconcat: Improve a size determination in concat_erase()

From: Markus Elfring Date: Thu, 4 Jan 2018 20:00:27 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was

[PATCH 0/2] mtdconcat: Adjustments for two function implementations

From: Markus Elfring Date: Thu, 4 Jan 2018 20:24:56 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation in mtd_concat_create() Improve a size

[PATCH 0/2] mtdconcat: Adjustments for two function implementations

From: Markus Elfring Date: Thu, 4 Jan 2018 20:24:56 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation in mtd_concat_create() Improve a size determination in concat_erase()

Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls

Hi, Dne četrtek, 04. januar 2018 ob 15:45:18 CET je Chen-Yu Tsai napisal(a): > On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec wrote: > > For example, A83T have nmp plls which are modelled as nkmp plls. Since k > > is not specified, it has offset 0, shift 0 and lowest

Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls

Hi, Dne četrtek, 04. januar 2018 ob 15:45:18 CET je Chen-Yu Tsai napisal(a): > On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec wrote: > > For example, A83T have nmp plls which are modelled as nkmp plls. Since k > > is not specified, it has offset 0, shift 0 and lowest value 1. This > > means

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, 2018-01-04 at 10:36 -0800, Alexei Starovoitov wrote: > > Pretty much. > Paul's writeup: https://support.google.com/faqs/answer/7625886 > tldr: jmp *%r11 gets converted to: > call set_up_target; > capture_spec: >   pause; >   jmp capture_spec; > set_up_target: >   mov %r11, (%rsp); >  

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, 2018-01-04 at 10:36 -0800, Alexei Starovoitov wrote: > > Pretty much. > Paul's writeup: https://support.google.com/faqs/answer/7625886 > tldr: jmp *%r11 gets converted to: > call set_up_target; > capture_spec: >   pause; >   jmp capture_spec; > set_up_target: >   mov %r11, (%rsp); >  

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