Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

Hello, Nice read, see some comments below On Fri, Oct 06, 2017 at 11:34:30AM -0400, Steven Rostedt wrote: > On Fri, 6 Oct 2017 13:49:59 +0900 > Masami Hiramatsu wrote: > > > Steve, could you write a documentation how to use ftrace callback? > > I think I should update the

Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

Hello, Nice read, see some comments below On Fri, Oct 06, 2017 at 11:34:30AM -0400, Steven Rostedt wrote: > On Fri, 6 Oct 2017 13:49:59 +0900 > Masami Hiramatsu wrote: > > > Steve, could you write a documentation how to use ftrace callback? > > I think I should update the

Re: [PATCH] mwifiex: Use put_unaligned_le32

Hi Himanshu, [auto build test ERROR on wireless-drivers-next/master] [also build test ERROR on v4.14-rc3 next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] mwifiex: Use put_unaligned_le32

Hi Himanshu, [auto build test ERROR on wireless-drivers-next/master] [also build test ERROR on v4.14-rc3 next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] MAINTAINERS: Update the UV architecture to current addresses

On Fri, 2017-10-06 at 15:36 -0500, Nathan Zimmer wrote: > After the buyout/merger our @sgi.com address are slowing being less useful. > So make sure we are can be contacted properly. This seems more like a new entry so the commit message seems wrong. > Signed-off-by: Nathan Zimmer

Re: [PATCH] MAINTAINERS: Update the UV architecture to current addresses

On Fri, 2017-10-06 at 15:36 -0500, Nathan Zimmer wrote: > After the buyout/merger our @sgi.com address are slowing being less useful. > So make sure we are can be contacted properly. This seems more like a new entry so the commit message seems wrong. > Signed-off-by: Nathan Zimmer >

[PATCH] irqchip/gicv3-its: Add missing changes to support 52bit physical address

The current ITS driver works fine as long as normal memory and GICR regions are located within the lower 48bit (>=0 && <2^48) physical address space. Some of the registers GICR_PEND/PROP, GICR_VPEND/VPROP and GITS_CBASER are handled properly but not all when configuring the hardware with 52bit

[PATCH] irqchip/gicv3-its: Add missing changes to support 52bit physical address

The current ITS driver works fine as long as normal memory and GICR regions are located within the lower 48bit (>=0 && <2^48) physical address space. Some of the registers GICR_PEND/PROP, GICR_VPEND/VPROP and GITS_CBASER are handled properly but not all when configuring the hardware with 52bit

Re: [Patch v6 6/7] regmap: add SLIMBUS support

Hi, On Fri, Oct 06, 2017 at 05:51:35PM +0200, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > This patch adds support to read/write slimbus value elements. > Currently it only supports byte read/write. Adding this support in > regmap would

Re: [Patch v6 6/7] regmap: add SLIMBUS support

Hi, On Fri, Oct 06, 2017 at 05:51:35PM +0200, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > This patch adds support to read/write slimbus value elements. > Currently it only supports byte read/write. Adding this support in > regmap would give codec drivers more

[PATCH v5 02/14] platform/x86: dell-wmi: increase severity of some failures

There is a lot of error checking in place for the format of the WMI descriptor buffer, but some of the potentially raised issues should be considered critical failures. If the buffer size or header don't match, this is a good indication that the buffer format changed in a way that the rest of the

[PATCH v5 02/14] platform/x86: dell-wmi: increase severity of some failures

There is a lot of error checking in place for the format of the WMI descriptor buffer, but some of the potentially raised issues should be considered critical failures. If the buffer size or header don't match, this is a good indication that the buffer format changed in a way that the rest of the

[PATCH v5 01/14] platform/x86: wmi: Add new method wmidev_evaluate_method

Drivers properly using the wmibus can pass their wmi_device pointer rather than the GUID back to the WMI bus to evaluate the proper methods. Any "new" drivers added that use the WMI bus should use this rather than the old wmi_evaluate_method that would take the GUID. Signed-off-by: Mario

[PATCH v5 01/14] platform/x86: wmi: Add new method wmidev_evaluate_method

Drivers properly using the wmibus can pass their wmi_device pointer rather than the GUID back to the WMI bus to evaluate the proper methods. Any "new" drivers added that use the WMI bus should use this rather than the old wmi_evaluate_method that would take the GUID. Signed-off-by: Mario

[PATCH v5 03/14] platform/x86: dell-wmi: clean up wmi descriptor check

Some cases the wrong type was used for errors and checks can be done more cleanly. Signed-off-by: Mario Limonciello Reviewed-by: Edward O'Callaghan Suggested-by: Andy Shevchenko --- drivers/platform/x86/dell-wmi.c |

[PATCH v5 07/14] platform/x86: dell-smbios: only run if proper oem string is detected

The proper way to indicate that a system is a 'supported' Dell System is by the presence of this string in OEM strings. Allowing the driver to load on non-Dell systems will have undefined results. Signed-off-by: Mario Limonciello ---

[PATCH v5 03/14] platform/x86: dell-wmi: clean up wmi descriptor check

Some cases the wrong type was used for errors and checks can be done more cleanly. Signed-off-by: Mario Limonciello Reviewed-by: Edward O'Callaghan Suggested-by: Andy Shevchenko --- drivers/platform/x86/dell-wmi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH v5 07/14] platform/x86: dell-smbios: only run if proper oem string is detected

The proper way to indicate that a system is a 'supported' Dell System is by the presence of this string in OEM strings. Allowing the driver to load on non-Dell systems will have undefined results. Signed-off-by: Mario Limonciello --- drivers/platform/x86/dell-smbios.c | 7 +++ 1 file

[PATCH v5 08/14] platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens

Currently userspace tools can access system tokens via the dcdbas kernel module and a SMI call that will cause the platform to execute SMM code. With a goal in mind of deprecating the dcdbas kernel module a different method for accessing these tokens from userspace needs to be created. This is

[PATCH v5 04/14] platform/x86: dell-wmi: allow 32k return size in the descriptor

Some platforms this year will be adopting 32k WMI buffer, so don't complain when encountering those. Signed-off-by: Mario Limonciello --- drivers/platform/x86/dell-wmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v5 08/14] platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens

Currently userspace tools can access system tokens via the dcdbas kernel module and a SMI call that will cause the platform to execute SMM code. With a goal in mind of deprecating the dcdbas kernel module a different method for accessing these tokens from userspace needs to be created. This is

[PATCH v5 04/14] platform/x86: dell-wmi: allow 32k return size in the descriptor

Some platforms this year will be adopting 32k WMI buffer, so don't complain when encountering those. Signed-off-by: Mario Limonciello --- drivers/platform/x86/dell-wmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/dell-wmi.c

[PATCH v5 09/14] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

This splits up the dell-smbios driver into two drivers: * dell-smbios * dell-smbios-smm dell-smbios can operate with multiple different dispatcher drivers to perform SMBIOS operations. Also modify the interface that dell-laptop and dell-wmi use align to this model more closely. Rather than a

[PATCH v5 05/14] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver

All communication on individual GUIDs should occur in separate drivers. Allowing a driver to communicate with the bus to another GUID is just a hack that discourages drivers to adopt the bus model. The information found from the WMI descriptor driver is now exported for use by other drivers.

[PATCH v5 00/14] Introduce support for Dell SMBIOS over WMI

The existing way that the dell-smbios helper module and associated other drivers (dell-laptop, dell-wmi) communicate with the platform really isn't secure. It requires creating a buffer in physical DMA32 memory space and passing that to the platform via SMM. Since the platform got a physical

[PATCH v5 09/14] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

This splits up the dell-smbios driver into two drivers: * dell-smbios * dell-smbios-smm dell-smbios can operate with multiple different dispatcher drivers to perform SMBIOS operations. Also modify the interface that dell-laptop and dell-wmi use align to this model more closely. Rather than a

[PATCH v5 05/14] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver

All communication on individual GUIDs should occur in separate drivers. Allowing a driver to communicate with the bus to another GUID is just a hack that discourages drivers to adopt the bus model. The information found from the WMI descriptor driver is now exported for use by other drivers.

[PATCH v5 00/14] Introduce support for Dell SMBIOS over WMI

The existing way that the dell-smbios helper module and associated other drivers (dell-laptop, dell-wmi) communicate with the platform really isn't secure. It requires creating a buffer in physical DMA32 memory space and passing that to the platform via SMM. Since the platform got a physical

[PATCH v5 11/14] platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver

The dell-smbios stack only currently uses an SMI interface which grants direct access to physical memory to the firmware SMM methods via a pointer. This dispatcher driver adds a WMI-ACPI interface that is detected by WMI probe and preferred over the SMI interface in dell-smbios. Changing this to

[PATCH v5 11/14] platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver

The dell-smbios stack only currently uses an SMI interface which grants direct access to physical memory to the firmware SMM methods via a pointer. This dispatcher driver adds a WMI-ACPI interface that is detected by WMI probe and preferred over the SMI interface in dell-smbios. Changing this to

[PATCH v5 10/14] platform/x86: dell-smbios: add filtering capability for requests

There are some categories of tokens and SMBIOS calls that it makes sense to protect userspace from accessing. These are calls that may write to one time use fields or activate hardware debugging capabilities. They are not intended for general purpose use. This same functionality may be be later

[PATCH v5 10/14] platform/x86: dell-smbios: add filtering capability for requests

There are some categories of tokens and SMBIOS calls that it makes sense to protect userspace from accessing. These are calls that may write to one time use fields or activate hardware debugging capabilities. They are not intended for general purpose use. This same functionality may be be later

[PATCH v5 13/14] platform/x86: wmi: create character devices when requested by drivers

For WMI operations that are only Set or Query read or write sysfs attributes created by WMI vendor drivers make sense. For other WMI operations that are run on Method, there needs to be a way to guarantee to userspace that the results from the method call belong to the data request to the method

[PATCH v5 13/14] platform/x86: wmi: create character devices when requested by drivers

For WMI operations that are only Set or Query read or write sysfs attributes created by WMI vendor drivers make sense. For other WMI operations that are run on Method, there needs to be a way to guarantee to userspace that the results from the method call belong to the data request to the method

[PATCH v5 14/14] platform/x86: dell-smbios-wmi: introduce userspace interface

It's important for the driver to provide a R/W ioctl to ensure that two competing userspace processes don't race to provide or read each others data. This userspace character device will be used to perform SMBIOS calls from any applications. It provides an ioctl that will allow passing the WMI

[PATCH v5 06/14] platform/x86: wmi: Don't allow drivers to get each other's GUIDs

The only driver using this was dell-wmi, and it really was a hack. The driver was getting a data attribute from another driver and this type of action should not be encouraged. Rather drivers that need to interact with one another should pass data back and forth via exported functions.

[PATCH v5 14/14] platform/x86: dell-smbios-wmi: introduce userspace interface

It's important for the driver to provide a R/W ioctl to ensure that two competing userspace processes don't race to provide or read each others data. This userspace character device will be used to perform SMBIOS calls from any applications. It provides an ioctl that will allow passing the WMI

[PATCH v5 06/14] platform/x86: wmi: Don't allow drivers to get each other's GUIDs

The only driver using this was dell-wmi, and it really was a hack. The driver was getting a data attribute from another driver and this type of action should not be encouraged. Rather drivers that need to interact with one another should pass data back and forth via exported functions.

[PATCH v5 12/14] platform/x86: dell-smbios-smm: test for WSMT

WSMT is as an attestation to the OS that the platform won't modify memory outside of pre-defined areas. If a platform has WSMT enabled in BIOS setup, SMM calls through dcdbas will fail. The only way to access platform data in these instances is through the WMI SMBIOS calling interface.

[PATCH v5 12/14] platform/x86: dell-smbios-smm: test for WSMT

WSMT is as an attestation to the OS that the platform won't modify memory outside of pre-defined areas. If a platform has WSMT enabled in BIOS setup, SMM calls through dcdbas will fail. The only way to access platform data in these instances is through the WMI SMBIOS calling interface.

Re: [ANNOUNCE] v4.11.12-rt13

On Fri, 2017-10-06 at 19:38 +0200, Mike Galbraith wrote: > On Fri, 2017-10-06 at 15:33 +0200, Mike Galbraith wrote: > > > > I'll run full ltp again, make sure there are no new failure deltas. > > Haven't done that yet, but I have checked all of the reported failures. > >

Re: [ANNOUNCE] v4.11.12-rt13

On Fri, 2017-10-06 at 19:38 +0200, Mike Galbraith wrote: > On Fri, 2017-10-06 at 15:33 +0200, Mike Galbraith wrote: > > > > I'll run full ltp again, make sure there are no new failure deltas. > > Haven't done that yet, but I have checked all of the reported failures. > >

[rcu:rcu/next 48/97] drivers/firmware/tegra/ivc.c:154:39: error: lvalue required as left operand of assignment

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: bd76953f4e7b0b1f66b3fe631106fcc4c85a380c commit: 669f98e232aa6f77bd602e2826dd55c3694109e5 [48/97] drivers/firmware/tegra: Convert ACCESS_ONCE() to READ_ONCE() config: arm64-defconfig (attached as

[rcu:rcu/next 48/97] drivers/firmware/tegra/ivc.c:154:39: error: lvalue required as left operand of assignment

tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next head: bd76953f4e7b0b1f66b3fe631106fcc4c85a380c commit: 669f98e232aa6f77bd602e2826dd55c3694109e5 [48/97] drivers/firmware/tegra: Convert ACCESS_ONCE() to READ_ONCE() config: arm64-defconfig (attached as

Re: [PATCH] crypto: omap: use of_device_get_match_data

On Wed, Sep 20, 2017 at 08:42:48PM +0200, Corentin Labbe wrote: > The usage of of_device_get_match_data reduce the code size a bit. > Furthermore, it prevents an improbable dereference when > of_match_device() return NULL. > > Signed-off-by: Corentin Labbe Patch

Re: [PATCH] crypto: bcm: use of_device_get_match_data

On Wed, Sep 20, 2017 at 08:47:26PM +0200, Corentin Labbe wrote: > The usage of of_device_get_match_data reduce the code size a bit. > Furthermore, it prevents an improbable dereference when > of_match_device() return NULL. > > Signed-off-by: Corentin Labbe Patch

Re: [PATCH] crypto: stm32: use of_device_get_match_data

On Wed, Sep 20, 2017 at 08:31:40PM +0200, Corentin Labbe wrote: > The usage of of_device_get_match_data reduce the code size a bit. > Furthermore, it prevents an improbable dereference when > of_match_device() return NULL. > > Signed-off-by: Corentin Labbe Patch

Re: [PATCH] crypto: bcm: use of_device_get_match_data

On Wed, Sep 20, 2017 at 08:47:26PM +0200, Corentin Labbe wrote: > The usage of of_device_get_match_data reduce the code size a bit. > Furthermore, it prevents an improbable dereference when > of_match_device() return NULL. > > Signed-off-by: Corentin Labbe Patch applied. Thanks. -- Email:

Re: [PATCH] crypto: stm32: use of_device_get_match_data

On Wed, Sep 20, 2017 at 08:31:40PM +0200, Corentin Labbe wrote: > The usage of of_device_get_match_data reduce the code size a bit. > Furthermore, it prevents an improbable dereference when > of_match_device() return NULL. > > Signed-off-by: Corentin Labbe Patch applied. Thanks. -- Email:

Re: [PATCH] crypto: omap: use of_device_get_match_data

On Wed, Sep 20, 2017 at 08:42:48PM +0200, Corentin Labbe wrote: > The usage of of_device_get_match_data reduce the code size a bit. > Furthermore, it prevents an improbable dereference when > of_match_device() return NULL. > > Signed-off-by: Corentin Labbe Patch applied. Thanks. -- Email:

Re: [PATCH] crypto: algboss: remove redundant setting of len to zero

On Thu, Sep 14, 2017 at 07:02:19PM +0100, Colin King wrote: > From: Colin Ian King > > The variable len is set to zero, never read and then later updated > to p - name, so clearly the zero'ing of len is redundant and > can be removed. > > Detected by clang scan-build:

Re: [PATCH] crypto: algboss: remove redundant setting of len to zero

On Thu, Sep 14, 2017 at 07:02:19PM +0100, Colin King wrote: > From: Colin Ian King > > The variable len is set to zero, never read and then later updated > to p - name, so clearly the zero'ing of len is redundant and > can be removed. > > Detected by clang scan-build: > " warning: Value stored

Re: [PATCH 02/10] drivers:crypto: return -ENOMEM on allocation failure.

Allen Pais wrote: > Signed-off-by: Allen Pais Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 02/10] drivers:crypto: return -ENOMEM on allocation failure.

Allen Pais wrote: > Signed-off-by: Allen Pais Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 1/2] crypto: stm32 - Fix uninitialized data usage

On Tue, Sep 12, 2017 at 11:35:38AM +0200, Arnd Bergmann wrote: > The error handling in stm32_hash_irq_thread passes > uninitialized data into stm32_hash_finish_req, as gcc > points out: > > drivers/crypto/stm32/stm32-hash.c: In function 'stm32_hash_irq_thread': >

Re: [PATCH 2/2] crypto: stm32 - Try to fix hash padding

On Tue, Sep 12, 2017 at 11:35:39AM +0200, Arnd Bergmann wrote: > gcc warns that the length for the extra unaligned data in the hash > function may be used unaligned. In theory this could happen if > we pass a zero-length sg_list, or if sg_is_last() was never true: > > In file included from

Re: [PATCH 1/2] crypto: stm32 - Fix uninitialized data usage

On Tue, Sep 12, 2017 at 11:35:38AM +0200, Arnd Bergmann wrote: > The error handling in stm32_hash_irq_thread passes > uninitialized data into stm32_hash_finish_req, as gcc > points out: > > drivers/crypto/stm32/stm32-hash.c: In function 'stm32_hash_irq_thread': >

Re: [PATCH 2/2] crypto: stm32 - Try to fix hash padding

On Tue, Sep 12, 2017 at 11:35:39AM +0200, Arnd Bergmann wrote: > gcc warns that the length for the extra unaligned data in the hash > function may be used unaligned. In theory this could happen if > we pass a zero-length sg_list, or if sg_is_last() was never true: > > In file included from

Re: [PATCH] crc32-pclmul: remove useless relative addressing

On Wed, Sep 06, 2017 at 10:41:21PM -0400, Mikulas Patocka wrote: > In 32-bit mode, the x86 architecture can hold full 32-bit pointers. > Therefore, the code that copies the current address to the %ecx register > and uses %ecx-relative addressing is useless, we could just use absolute > addressing.

Re: [PATCH] crc32-pclmul: remove useless relative addressing

On Wed, Sep 06, 2017 at 10:41:21PM -0400, Mikulas Patocka wrote: > In 32-bit mode, the x86 architecture can hold full 32-bit pointers. > Therefore, the code that copies the current address to the %ecx register > and uses %ecx-relative addressing is useless, we could just use absolute > addressing.

Re: [PATCH] crypto: xts - Fix an error handling path in 'create()'

On Tue, Sep 26, 2017 at 08:17:44AM +0200, Christophe JAILLET wrote: > All error handling paths 'goto err_drop_spawn' except this one. > In order to avoid some resources leak, we should do it as well here. > > Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher") > Signed-off-by: Christophe

Re: [PATCH] crypto: xts - Fix an error handling path in 'create()'

On Tue, Sep 26, 2017 at 08:17:44AM +0200, Christophe JAILLET wrote: > All error handling paths 'goto err_drop_spawn' except this one. > In order to avoid some resources leak, we should do it as well here. > > Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher") > Signed-off-by: Christophe

Re: [Patch v6 1/7] slimbus: Device management on SLIMbus

Hi, I have some more or less trivial comments below. On Fri, Oct 06, 2017 at 05:51:30PM +0200, srinivas.kandaga...@linaro.org wrote: > From: Sagar Dharia > > SLIMbus (Serial Low Power Interchip Media Bus) is a specification > developed by MIPI (Mobile Industry Processor

Re: [Patch v6 1/7] slimbus: Device management on SLIMbus

Hi, I have some more or less trivial comments below. On Fri, Oct 06, 2017 at 05:51:30PM +0200, srinivas.kandaga...@linaro.org wrote: > From: Sagar Dharia > > SLIMbus (Serial Low Power Interchip Media Bus) is a specification > developed by MIPI (Mobile Industry Processor Interface) alliance. >

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

Johannes Weiner wrote: > On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote: > > On 2017/10/05 19:36, Tetsuo Handa wrote: > > > I don't want this patch backported. If you want to backport, > > > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way. > > > > If you backport this

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

Johannes Weiner wrote: > On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote: > > On 2017/10/05 19:36, Tetsuo Handa wrote: > > > I don't want this patch backported. If you want to backport, > > > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way. > > > > If you backport this

Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

Hi Steven, Peter, On 2017/9/26 11:18, Steven Rostedt wrote: On Tue, 26 Sep 2017 09:23:20 +0800 zhouchengming wrote: On 2017/9/26 3:40, Steven Rostedt wrote: On Mon, 11 Sep 2017 14:51:49 +0800 Zhou Chengming wrote: push_rt_task() pick

Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

Hi Steven, Peter, On 2017/9/26 11:18, Steven Rostedt wrote: On Tue, 26 Sep 2017 09:23:20 +0800 zhouchengming wrote: On 2017/9/26 3:40, Steven Rostedt wrote: On Mon, 11 Sep 2017 14:51:49 +0800 Zhou Chengming wrote: push_rt_task() pick the first pushable task and find an eligible

Re: [RFC PATCH] crypto: make the seed() function optional

Mathieu Malaterre wrote: > This makes it simplier for driver author to not provide the seed() function > in case of a pseudo RNG where the seed operation is a no-op. > > Document that the seed() function pointer is optional in header. > > Signed-off-by: Mathieu Malaterre

Re: [RFC PATCH] crypto: make the seed() function optional

Mathieu Malaterre wrote: > This makes it simplier for driver author to not provide the seed() function > in case of a pseudo RNG where the seed operation is a no-op. > > Document that the seed() function pointer is optional in header. > > Signed-off-by: Mathieu Malaterre > --- > The PRNG as

Re: [PATCH] mwifiex: Use put_unaligned_le32

Hi Himanshu, [auto build test ERROR on wireless-drivers-next/master] [also build test ERROR on v4.14-rc3 next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] mwifiex: Use put_unaligned_le32

Hi Himanshu, [auto build test ERROR on wireless-drivers-next/master] [also build test ERROR on v4.14-rc3 next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

On Fri, Oct 06, 2017 at 10:15:37PM +0200, Peter Zijlstra wrote: > On Fri, Oct 06, 2017 at 12:18:22PM -0700, Paul E. McKenney wrote: > > > /me goes and install this herd thing again.. I'm sure I had it running > > > _somewhere_.. A well. > > > > > > C C-PaulEMcKenney-W+RWC4+2017-10-05 > > > > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

On Fri, Oct 06, 2017 at 10:15:37PM +0200, Peter Zijlstra wrote: > On Fri, Oct 06, 2017 at 12:18:22PM -0700, Paul E. McKenney wrote: > > > /me goes and install this herd thing again.. I'm sure I had it running > > > _somewhere_.. A well. > > > > > > C C-PaulEMcKenney-W+RWC4+2017-10-05 > > > > >

follow this information

hello,note that i am having problem with other e-mail. i therefore, recommend you to register free via below link to increase your finance, free money no charges click or copy link - http://woredrzydo.win/8071093818423/ please get back to me after registration.

follow this information

hello,note that i am having problem with other e-mail. i therefore, recommend you to register free via below link to increase your finance, free money no charges click or copy link - http://woredrzydo.win/8071093818423/ please get back to me after registration.

Re: [BUG] GPF on reboot of box

This bug still crashes my box on rc3 -- Steve On October 6, 2017 10:21:26 PM EDT, Nadav Amit wrote: >Steven Rostedt wrote: > >> Starting with v4.14-rc1 my box crashes during a reboot. All I get is >> the following: >> >> [ 250.615793] sd 0:0:0:0:

Re: [BUG] GPF on reboot of box

This bug still crashes my box on rc3 -- Steve On October 6, 2017 10:21:26 PM EDT, Nadav Amit wrote: >Steven Rostedt wrote: > >> Starting with v4.14-rc1 my box crashes during a reboot. All I get is >> the following: >> >> [ 250.615793] sd 0:0:0:0: [sda] Synchronizing SCSI cache >> [

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Fri, Oct 06, 2017 at 07:13:22PM +0100, Mark Rutland wrote: >Hi Greg, > >On Fri, Oct 06, 2017 at 10:52:04AM +0200, Greg Kroah-Hartman wrote: >> 4.9-stable review patch. If anyone has any objections, please let me know. > >I'm a little confused as to why this is being backported, given it

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Fri, Oct 06, 2017 at 07:13:22PM +0100, Mark Rutland wrote: >Hi Greg, > >On Fri, Oct 06, 2017 at 10:52:04AM +0200, Greg Kroah-Hartman wrote: >> 4.9-stable review patch. If anyone has any objections, please let me know. > >I'm a little confused as to why this is being backported, given it

Re: [PATCH v8 01/20] crypto: change transient busy return code to -EAGAIN

On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote: > > diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c > index 5e92bd2..3b3c154 100644 > --- a/crypto/algif_hash.c > +++ b/crypto/algif_hash.c > @@ -39,6 +39,20 @@ struct algif_hash_tfm { > bool has_key; > }; > > +/*

Re: [PATCH v8 01/20] crypto: change transient busy return code to -EAGAIN

On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote: > > diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c > index 5e92bd2..3b3c154 100644 > --- a/crypto/algif_hash.c > +++ b/crypto/algif_hash.c > @@ -39,6 +39,20 @@ struct algif_hash_tfm { > bool has_key; > }; > > +/*

[PATCH v2 2/4] kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK

Convert all allocations that used a NOTRACK flag to stop using it. Signed-off-by: Sasha Levin --- arch/arm/include/asm/pgalloc.h | 2 +- arch/arm64/include/asm/pgalloc.h | 2 +- arch/powerpc/include/asm/pgalloc.h | 2 +- arch/sh/kernel/dwarf.c

[PATCH v2 2/4] kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK

Convert all allocations that used a NOTRACK flag to stop using it. Signed-off-by: Sasha Levin --- arch/arm/include/asm/pgalloc.h | 2 +- arch/arm64/include/asm/pgalloc.h | 2 +- arch/powerpc/include/asm/pgalloc.h | 2 +- arch/sh/kernel/dwarf.c | 4 ++--

[PATCH v2 1/4] kmemcheck: remove annotations

Remove kmemcheck annotations, and calls to kmemcheck from the kernel. Signed-off-by: Sasha Levin --- arch/arm/include/asm/dma-iommu.h| 1 - arch/openrisc/include/asm/dma-mapping.h | 1 - arch/x86/Makefile | 5 -

[PATCH v2 3/4] kmemcheck: rip it out

Fix up makefiles, remove references, and git rm kmemcheck. Signed-off-by: Sasha Levin --- Documentation/admin-guide/kernel-parameters.txt | 7 - Documentation/dev-tools/index.rst | 1 - Documentation/dev-tools/kmemcheck.rst | 733

[PATCH v2 1/4] kmemcheck: remove annotations

Remove kmemcheck annotations, and calls to kmemcheck from the kernel. Signed-off-by: Sasha Levin --- arch/arm/include/asm/dma-iommu.h| 1 - arch/openrisc/include/asm/dma-mapping.h | 1 - arch/x86/Makefile | 5 - arch/x86/include/asm/dma-mapping.h | 1 -

[PATCH v2 3/4] kmemcheck: rip it out

Fix up makefiles, remove references, and git rm kmemcheck. Signed-off-by: Sasha Levin --- Documentation/admin-guide/kernel-parameters.txt | 7 - Documentation/dev-tools/index.rst | 1 - Documentation/dev-tools/kmemcheck.rst | 733 MAINTAINERS

[PATCH v2 4/4] kmemcheck: remove whats left of NOTRACK flags

Now that kmemcheck is gone, we don't need the NOTRACK flags. Signed-off-by: Sasha Levin --- arch/x86/include/asm/pgtable.h | 5 - arch/x86/include/asm/pgtable_types.h | 13 - include/linux/gfp.h | 9 -

[PATCH v2 0/4] kmemcheck: kill kmemcheck

2 Years ago I proposed to kill kmemcheck: > As discussed on LSF/MM, kill kmemcheck. > > KASan is a replacement that is able to work without the limitation of > kmemcheck (single CPU, slow). KASan is already upstream. > > We are also not aware of any users of kmemcheck (or users who don't consider

[PATCH v2 4/4] kmemcheck: remove whats left of NOTRACK flags

Now that kmemcheck is gone, we don't need the NOTRACK flags. Signed-off-by: Sasha Levin --- arch/x86/include/asm/pgtable.h | 5 - arch/x86/include/asm/pgtable_types.h | 13 - include/linux/gfp.h | 9 - include/linux/slab.h | 6

[PATCH v2 0/4] kmemcheck: kill kmemcheck

2 Years ago I proposed to kill kmemcheck: > As discussed on LSF/MM, kill kmemcheck. > > KASan is a replacement that is able to work without the limitation of > kmemcheck (single CPU, slow). KASan is already upstream. > > We are also not aware of any users of kmemcheck (or users who don't consider

Re: [PATCH] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

cc: Andrea Arcangeli On 10/6/17 7:52 PM, Prakash Sangappa wrote: Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should be available in Linux 4.14 release. This patch is for the manpage changes documenting this API. Documents the following commit: commit

Re: [PATCH] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

cc: Andrea Arcangeli On 10/6/17 7:52 PM, Prakash Sangappa wrote: Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should be available in Linux 4.14 release. This patch is for the manpage changes documenting this API. Documents the following commit: commit

[PATCH] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should be available in Linux 4.14 release. This patch is for the manpage changes documenting this API. Documents the following commit: commit 2d6d6f5a09a96cc1fec7ed992b825e05f64cb50e Author: Prakash Sangappa

[PATCH] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should be available in Linux 4.14 release. This patch is for the manpage changes documenting this API. Documents the following commit: commit 2d6d6f5a09a96cc1fec7ed992b825e05f64cb50e Author: Prakash Sangappa Date: Wed Sep 6

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote: > On 2017/10/05 19:36, Tetsuo Handa wrote: > > I don't want this patch backported. If you want to backport, > > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way. > > If you backport this patch, you will see "complete

Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote: > On 2017/10/05 19:36, Tetsuo Handa wrote: > > I don't want this patch backported. If you want to backport, > > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way. > > If you backport this patch, you will see "complete

[RFC v4 5/8] platform/x86: intel_punit_ipc: Fix resource ioremap warning

From: Kuppuswamy Sathyanarayanan For PUNIT device, ISPDRIVER_IPC and GTDDRIVER_IPC resources are not mandatory. So when PMC IPC driver creates a PUNIT device, if these resources are not available then it creates dummy resource entries for these missing

[RFC v4 5/8] platform/x86: intel_punit_ipc: Fix resource ioremap warning

From: Kuppuswamy Sathyanarayanan For PUNIT device, ISPDRIVER_IPC and GTDDRIVER_IPC resources are not mandatory. So when PMC IPC driver creates a PUNIT device, if these resources are not available then it creates dummy resource entries for these missing resources. But during PUNIT device probe ,

  1   2   3   4   5   6   7   8   9   10   >