Re: [PATCH 22/28] x86: apm: avoid uninitialized data

On Tue, Oct 18, 2016 at 12:16:10AM +0200, Arnd Bergmann wrote: > apm_bios_call() can fail, and return a status in its argument > structure. If that status however is zero during a call from > apm_get_power_status(), we end up using data that may have > never been set, as reported by "gcc

Re: [PATCH 22/28] x86: apm: avoid uninitialized data

On Tue, Oct 18, 2016 at 12:16:10AM +0200, Arnd Bergmann wrote: > apm_bios_call() can fail, and return a status in its argument > structure. If that status however is zero during a call from > apm_get_power_status(), we end up using data that may have > never been set, as reported by "gcc

[PATCH] staging: slicoss: replace memcpy_fromio with memcpy

As per discusion with Lino Sanfilippo, memcpy is the proper way to copy across dma memory, which also removes sparse warning that triggered inquiry. Signed-off-by: Ryan Swan --- drivers/staging/slicoss/slicoss.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH] staging: slicoss: replace memcpy_fromio with memcpy

As per discusion with Lino Sanfilippo, memcpy is the proper way to copy across dma memory, which also removes sparse warning that triggered inquiry. Signed-off-by: Ryan Swan --- drivers/staging/slicoss/slicoss.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] sched/fair: fix fairness problems among the tasks in different cgroups

When a new cgroup is created, scheduler attaches the child cgroup to its parent and also increases the parent's task_group load_avg to account increased load with following path : sched_create_group() alloc_fair_sched_group() sched_online_group() online_fair_sched_group()

[PATCH] sched/fair: fix fairness problems among the tasks in different cgroups

When a new cgroup is created, scheduler attaches the child cgroup to its parent and also increases the parent's task_group load_avg to account increased load with following path : sched_create_group() alloc_fair_sched_group() sched_online_group() online_fair_sched_group()

[PATCH 1/3] remoteproc: qcom: q6v5_pil: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 1/3] remoteproc: qcom: q6v5_pil: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 2/3] remoteproc: qcom: wcnss: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 2/3] remoteproc: qcom: wcnss: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 3/3] remoteproc: qcom: wcnss_iris: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 0/3] remoteproc: Fix module autoload for qcom platform drivers

Hello, I noticed that module autoload won't be working in some of the qcom remoteproc drivers. This patch series contains the fixes for these. Best regards, Javier Javier Martinez Canillas (3): remoteproc: qcom: q6v5_pil: Fix module autoload remoteproc: qcom: wcnss: Fix module autoload

[PATCH 3/3] remoteproc: qcom: wcnss_iris: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 0/3] remoteproc: Fix module autoload for qcom platform drivers

Hello, I noticed that module autoload won't be working in some of the qcom remoteproc drivers. This patch series contains the fixes for these. Best regards, Javier Javier Martinez Canillas (3): remoteproc: qcom: q6v5_pil: Fix module autoload remoteproc: qcom: wcnss: Fix module autoload

Re: [PATCH v2 01/10] phy: qcom-ufs: remove failure when rx/tx_iface_clk are absent

On 10/18/2016 07:28 AM, Vivek Gautam wrote: > From: Yaniv Gardi > > Since in future UFS Phy's the tx_iface_clk and rx_iface_clk > are no longer exist, we should not fail when their initialization > fail, but rather just report with debug message. > > Signed-off-by: Yaniv

Re: [PATCH v2 01/10] phy: qcom-ufs: remove failure when rx/tx_iface_clk are absent

On 10/18/2016 07:28 AM, Vivek Gautam wrote: > From: Yaniv Gardi > > Since in future UFS Phy's the tx_iface_clk and rx_iface_clk > are no longer exist, we should not fail when their initialization > fail, but rather just report with debug message. > > Signed-off-by: Yaniv Gardi > Signed-off-by:

Re: [PATCH 01/12] extarray: define helpers for arrays defined in linker scripts

On Tue, Oct 18, 2016 at 10:08:44AM +0200, Vegard Nossum wrote: > Vegard, thanks for bringing this to attention! Including this hunk for those that were originally not CC'd on the original patch. > diff --git a/include/linux/extarray.h b/include/linux/extarray.h > new file mode 100644 > index

Re: [PATCH 01/12] extarray: define helpers for arrays defined in linker scripts

On Tue, Oct 18, 2016 at 10:08:44AM +0200, Vegard Nossum wrote: > Vegard, thanks for bringing this to attention! Including this hunk for those that were originally not CC'd on the original patch. > diff --git a/include/linux/extarray.h b/include/linux/extarray.h > new file mode 100644 > index

[REVIEW][PATCH] exec: Don't exec files the userns root can not read.

When the user namespace support was merged the need to prevent ptracing an executable that is not readable was overlooked. Correct this oversight by not letting exec succeed if during exec an executable is not readable and the current user namespace capabilities do not apply to the executable's

[REVIEW][PATCH] exec: Don't exec files the userns root can not read.

When the user namespace support was merged the need to prevent ptracing an executable that is not readable was overlooked. Correct this oversight by not letting exec succeed if during exec an executable is not readable and the current user namespace capabilities do not apply to the executable's

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Tue, 2016-10-18 at 13:48 -0700, Kees Cook wrote: > On Mon, Oct 17, 2016 at 6:44 AM, Mark Rutland > wrote: > > Hi, > > > > Attempt to revive discussions below... > > > > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote: > > > When

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Tue, 2016-10-18 at 13:48 -0700, Kees Cook wrote: > On Mon, Oct 17, 2016 at 6:44 AM, Mark Rutland > wrote: > > Hi, > > > > Attempt to revive discussions below... > > > > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote: > > > When kernel.perf_event_paranoid is set to 3 (or

[PATCH] latent_entropy: raise CONFIG_FRAME_WARN by default

When building with the latent_entropy plugin, set the default CONFIG_FRAME_WARN to 2048, since some __init functions have many basic blocks that, when instrumented by the latent_entropy plugin, grow beyond 1024 byte stack size on 32-bit builds. Reported-by: kbuild test robot

[PATCH] latent_entropy: raise CONFIG_FRAME_WARN by default

When building with the latent_entropy plugin, set the default CONFIG_FRAME_WARN to 2048, since some __init functions have many basic blocks that, when instrumented by the latent_entropy plugin, grow beyond 1024 byte stack size on 32-bit builds. Reported-by: kbuild test robot Cc: Emese Revfy

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

On 10/18/2016 09:15 PM, Boris Brezillon wrote: > On Tue, 18 Oct 2016 11:46:51 -0700 > Brian Norris wrote: > >> + others >> >> On Tue, Oct 18, 2016 at 06:15:23PM +0200, Richard Weinberger wrote: >>> On 18.10.2016 17:55, Cyrille Pitchen wrote: Le 18/10/2016 à

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

On 10/18/2016 09:15 PM, Boris Brezillon wrote: > On Tue, 18 Oct 2016 11:46:51 -0700 > Brian Norris wrote: > >> + others >> >> On Tue, Oct 18, 2016 at 06:15:23PM +0200, Richard Weinberger wrote: >>> On 18.10.2016 17:55, Cyrille Pitchen wrote: Le 18/10/2016 à 17:30, Richard Weinberger a

Re: [REVIEW][PATCH] mm: Add a user_ns owner to mm_struct and fix ptrace_may_access

Jann Horn writes: > On Tue, Oct 18, 2016 at 10:35:23AM -0500, Eric W. Biederman wrote: >> Jann Horn writes: >> >> > On Tue, Oct 18, 2016 at 09:56:53AM -0500, Eric W. Biederman wrote: >> >> Michal Hocko writes: >> >> >> >> > On Mon 17-10-16

Re: [REVIEW][PATCH] mm: Add a user_ns owner to mm_struct and fix ptrace_may_access

Jann Horn writes: > On Tue, Oct 18, 2016 at 10:35:23AM -0500, Eric W. Biederman wrote: >> Jann Horn writes: >> >> > On Tue, Oct 18, 2016 at 09:56:53AM -0500, Eric W. Biederman wrote: >> >> Michal Hocko writes: >> >> >> >> > On Mon 17-10-16 11:39:49, Eric W. Biederman wrote: >> >> >> >> >>

[PATCH] pinctrl: imx: reset group index on probe

Group index is incremented on every new group parsed. Since the field is part of struct imx_pinctrl_soc_info, which is typically a global variable passed by the individual pinctrl-imx.c based driver, it does not get cleared automatically when re-probing the driver. This lead

[PATCH] pinctrl: imx: reset group index on probe

Group index is incremented on every new group parsed. Since the field is part of struct imx_pinctrl_soc_info, which is typically a global variable passed by the individual pinctrl-imx.c based driver, it does not get cleared automatically when re-probing the driver. This lead

[RFC 1/2] mmc: sdhci: dt: Add device tree property sdhci-cap-speed-modes-broken

On some systems the sdhci capabilty registers are incorrect for one reason or another. The sdhci-cap-speed-modes-broken property will let the driver know that the sdhci capability registers should not be relied on for speed modes. Instead the driver should check the mmc generic DT bindings.

[PATCH v2 2/2] tools/power turbostat: enable turbostat to support Knights Mill (KNM)

Add Knights Mill (KNM) to the list of CPUIDs supported by turbostat. Change-Id: I616e3232e985fba4080a65e982604bd03d6dfb9f Signed-off-by: Piotr Luc Reviewed-by: Dave Hansen Cc: Borislav Petkov Cc: Len Brown ---

[RFC 1/2] mmc: sdhci: dt: Add device tree property sdhci-cap-speed-modes-broken

On some systems the sdhci capabilty registers are incorrect for one reason or another. The sdhci-cap-speed-modes-broken property will let the driver know that the sdhci capability registers should not be relied on for speed modes. Instead the driver should check the mmc generic DT bindings.

[PATCH v2 2/2] tools/power turbostat: enable turbostat to support Knights Mill (KNM)

Add Knights Mill (KNM) to the list of CPUIDs supported by turbostat. Change-Id: I616e3232e985fba4080a65e982604bd03d6dfb9f Signed-off-by: Piotr Luc Reviewed-by: Dave Hansen Cc: Borislav Petkov Cc: Len Brown --- v2: Remove trailing comments. tools/power/x86/turbostat/turbostat.c | 7 +++

[PATCH 0/2]tools/power turbostat: enable turbostat to support Knights Mill (KNM)

This patchset is rebased onto 08328814256d888634ff15ba8fb67e2ae4340b64. First patch improves code style by replacing raw numbers of CPUID with descriptive macros of processor names. The second patch adds Knights Mill (KNM) to the list of CPUIDs supported by turbostat. Both patches come in new

[PATCH 0/2]tools/power turbostat: enable turbostat to support Knights Mill (KNM)

This patchset is rebased onto 08328814256d888634ff15ba8fb67e2ae4340b64. First patch improves code style by replacing raw numbers of CPUID with descriptive macros of processor names. The second patch adds Knights Mill (KNM) to the list of CPUIDs supported by turbostat. Both patches come in new

[PATCH v3 1/2] tools/power turbostat: Use Intel family processor macros

Use macros of Intel processor families instead of raw numbers. Change-Id: I033e40bcea6bde66284e2217e9231f856c827d20 Signed-off-by: Piotr Luc Reviewed-by: Dave Hansen Cc: Borislav Petkov Cc: Len Brown --- v2:

[PATCH v3 1/2] tools/power turbostat: Use Intel family processor macros

Use macros of Intel processor families instead of raw numbers. Change-Id: I033e40bcea6bde66284e2217e9231f856c827d20 Signed-off-by: Piotr Luc Reviewed-by: Dave Hansen Cc: Borislav Petkov Cc: Len Brown --- v2: Include Intel family header. v3: Remove trailing comments.

Re: [PATCH] PM / AVS: SmartReflex: add in missing white space in error message text

Colin King writes: > From: Colin Ian King > > Several line wrapped literal strings are missing white spaces, add the > whitespace to fix this. > > Signed-off-by: Colin Ian King > --- >

[RFC 2/2] mmc: sdhci: Ignore capability register when it comes to speeds and use DT binding instead when sdhci-cap-speed-modes-broken is set.

When the sdhci-cap-speed-modes-broken DT property is set, the driver will ignore the bits of the capability registers that correspond to speed modes and will read the of properties of the device to determine which speeds are supported. Signed-off-by: Zach Brown ---

[RFC 0/2] Ignore capability registers when it comes to speeds and use DT binding instead.

The first patch add documentation about a new devicetree property sdhci-cap-speed-modes-broken. The second patch makes the sdhci use the DT binding instead of the caps register for determining which speed modes are supported by the controller. This RFC is an alternative to another patch set I

Re: [PATCH] PM / AVS: SmartReflex: add in missing white space in error message text

Colin King writes: > From: Colin Ian King > > Several line wrapped literal strings are missing white spaces, add the > whitespace to fix this. > > Signed-off-by: Colin Ian King > --- > drivers/power/avs/smartreflex.c | 20 ++-- > 1 file changed, 10 insertions(+), 10

[RFC 2/2] mmc: sdhci: Ignore capability register when it comes to speeds and use DT binding instead when sdhci-cap-speed-modes-broken is set.

When the sdhci-cap-speed-modes-broken DT property is set, the driver will ignore the bits of the capability registers that correspond to speed modes and will read the of properties of the device to determine which speeds are supported. Signed-off-by: Zach Brown --- drivers/mmc/host/sdhci.c | 31

[RFC 0/2] Ignore capability registers when it comes to speeds and use DT binding instead.

The first patch add documentation about a new devicetree property sdhci-cap-speed-modes-broken. The second patch makes the sdhci use the DT binding instead of the caps register for determining which speed modes are supported by the controller. This RFC is an alternative to another patch set I

[PATCH 1/4] i2c: jz4780: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 0/4] i2c: Fix module autoload for some i2c busses platform drivers

Hello Wolfram, I noticed that module autoload won't be working in some of the i2c busses drivers. This patch series contains the fixes for these. Best regards, Javier Javier Martinez Canillas (4): i2c: jz4780: Fix module autoload i2c: xlp9xx: Fix module autoload i2c: xlr: Fix module

Re: [PATCH v20 10/10] fpga-manager: Add Socfpga Arria10 support

On Mon, Oct 17, 2016 at 11:09:41AM -0500, Alan Tull wrote: > Add low level driver to support reprogramming FPGAs for Altera > SoCFPGA Arria10. > > Signed-off-by: Alan Tull Reviewed-by: Moritz Fischer > --- > v19: Added to this patchset as

[PATCH 1/4] i2c: jz4780: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 0/4] i2c: Fix module autoload for some i2c busses platform drivers

Hello Wolfram, I noticed that module autoload won't be working in some of the i2c busses drivers. This patch series contains the fixes for these. Best regards, Javier Javier Martinez Canillas (4): i2c: jz4780: Fix module autoload i2c: xlp9xx: Fix module autoload i2c: xlr: Fix module

Re: [PATCH v20 10/10] fpga-manager: Add Socfpga Arria10 support

On Mon, Oct 17, 2016 at 11:09:41AM -0500, Alan Tull wrote: > Add low level driver to support reprogramming FPGAs for Altera > SoCFPGA Arria10. > > Signed-off-by: Alan Tull Reviewed-by: Moritz Fischer > --- > v19: Added to this patchset as has been changed to use >fpga image information

Re: [PATCH] um: remove hppfs MAINTAINERS entry

On 11.10.2016 07:50, Dan Carpenter wrote: > We removed hppfs in commit f74a14e870c8 ('um: Remove hppfs') so we can > remove the MAINTAINERS entry as well. > > Signed-off-by: Dan Carpenter > > diff --git a/MAINTAINERS b/MAINTAINERS > index 63f15c9..116729a 100644 > ---

Re: 4.8.1 regression with cpufreq governors

On Monday, October 17, 2016 07:46:06 PM Tim Walberg wrote: > May or may not be related to similar reports, but here's what I've just > observed > on my system. Built a stock kernel from tags/v4.8.1, relevant cpufreq bits: > > CONFIG_ACPI_CPU_FREQ_PSS=y > CONFIG_CPU_FREQ=y >

Re: [PATCH] um: remove hppfs MAINTAINERS entry

On 11.10.2016 07:50, Dan Carpenter wrote: > We removed hppfs in commit f74a14e870c8 ('um: Remove hppfs') so we can > remove the MAINTAINERS entry as well. > > Signed-off-by: Dan Carpenter > > diff --git a/MAINTAINERS b/MAINTAINERS > index 63f15c9..116729a 100644 > --- a/MAINTAINERS > +++

Re: 4.8.1 regression with cpufreq governors

On Monday, October 17, 2016 07:46:06 PM Tim Walberg wrote: > May or may not be related to similar reports, but here's what I've just > observed > on my system. Built a stock kernel from tags/v4.8.1, relevant cpufreq bits: > > CONFIG_ACPI_CPU_FREQ_PSS=y > CONFIG_CPU_FREQ=y >

[PATCH 3/4] i2c: xlr: Fix module autoload for OF registration

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 4/4] i2c: digicolor: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 3/4] i2c: xlr: Fix module autoload for OF registration

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 4/4] i2c: digicolor: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 2/4] i2c: xlp9xx: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

Re: [PATCH 6/6] mm: add preempt points into __purge_vmap_area_lazy

On Tue, 18 Oct 2016 16:56:48 -0400 Steven Rostedt wrote: > Is releasing the lock within a llist_for_each_entry_safe() actually safe? Is > vmap_area_lock the one to protect the valist? > > That is llist_for_each_entry_safe(va, n_va, valist, purg_list) does: > > for

[PATCH 2/4] i2c: xlp9xx: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

Re: [PATCH 6/6] mm: add preempt points into __purge_vmap_area_lazy

On Tue, 18 Oct 2016 16:56:48 -0400 Steven Rostedt wrote: > Is releasing the lock within a llist_for_each_entry_safe() actually safe? Is > vmap_area_lock the one to protect the valist? > > That is llist_for_each_entry_safe(va, n_va, valist, purg_list) does: > > for (va =

Re: [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200 speed from rk3288-veyron-speedy.

Hi, Le mardi 18 octobre 2016 à 11:21 +0200, Heiko Stübner a écrit : > Am Sonntag, 16. Oktober 2016, 21:49:43 schrieb Paul Kocialkowski: > > > > Hi, > > > > Le mardi 27 septembre 2016 à 13:53 -0700, Vagrant Cascadian a écrit : > > > > > > This essentially mimics what was done with

Re: [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200 speed from rk3288-veyron-speedy.

Hi, Le mardi 18 octobre 2016 à 11:21 +0200, Heiko Stübner a écrit : > Am Sonntag, 16. Oktober 2016, 21:49:43 schrieb Paul Kocialkowski: > > > > Hi, > > > > Le mardi 27 septembre 2016 à 13:53 -0700, Vagrant Cascadian a écrit : > > > > > > This essentially mimics what was done with

Re: drivers/pci/hotplug/ibmphp_ebda.c:409:1: warning: the frame size of 1108 bytes is larger than 1024 bytes

On Mon, Oct 17, 2016 at 2:37 PM, Emese Revfy wrote: > On Sun, 16 Oct 2016 06:52:16 +0800 > kbuild test robot wrote: > >>drivers/pci/hotplug/ibmphp_ebda.c: In function 'ibmphp_access_ebda': >> >> drivers/pci/hotplug/ibmphp_ebda.c:409:1: warning: the

Re: drivers/pci/hotplug/ibmphp_ebda.c:409:1: warning: the frame size of 1108 bytes is larger than 1024 bytes

On Mon, Oct 17, 2016 at 2:37 PM, Emese Revfy wrote: > On Sun, 16 Oct 2016 06:52:16 +0800 > kbuild test robot wrote: > >>drivers/pci/hotplug/ibmphp_ebda.c: In function 'ibmphp_access_ebda': >> >> drivers/pci/hotplug/ibmphp_ebda.c:409:1: warning: the frame size of 1108 >> >> bytes is larger

[PATCH] gpu: Remove depends on RESET_CONTROLLER when not a provider

These GPU drivers only depend on the RESET_CONTROLLER config option to fix build issues that existed when there weren't stub reset APIs for reset controller consumers. Given that these drivers aren't providing any reset controllers themselves, they don't actually depend on the API to build (just

[PATCH] gpu: Remove depends on RESET_CONTROLLER when not a provider

These GPU drivers only depend on the RESET_CONTROLLER config option to fix build issues that existed when there weren't stub reset APIs for reset controller consumers. Given that these drivers aren't providing any reset controllers themselves, they don't actually depend on the API to build (just

Re: [PATCH 6/6] mm: add preempt points into __purge_vmap_area_lazy

On Tue, Oct 18, 2016 at 08:56:11AM +0200, Christoph Hellwig wrote: > From: Joel Fernandes > > Use cond_resched_lock to avoid holding the vmap_area_lock for a > potentially long time. > > Signed-off-by: Joel Fernandes > [hch: split from a larger patch by

Re: [PATCH 6/6] mm: add preempt points into __purge_vmap_area_lazy

On Tue, Oct 18, 2016 at 08:56:11AM +0200, Christoph Hellwig wrote: > From: Joel Fernandes > > Use cond_resched_lock to avoid holding the vmap_area_lock for a > potentially long time. > > Signed-off-by: Joel Fernandes > [hch: split from a larger patch by Joel, wrote the crappy changelog] >

fscrypto: Two trivial patches

Thanks, //richard [PATCH 1/2] fscrypto: Fix log string in do_crypto() [PATCH 2/2] fscrypto: Fix fscrypt_decrypt_page() doc string

[PATCH 2/2] fscrypto: Fix fscrypt_decrypt_page() doc string

Most likely a copy error from the f2fs import. Signed-off-by: Richard Weinberger --- fs/crypto/crypto.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index 1637a0450b9f..d789ddbc0a46 100644 --- a/fs/crypto/crypto.c

[PATCH 1/2] fscrypto: Fix log string in do_crypto()

The operations supports both encryption and decryption. Signed-off-by: Richard Weinberger --- fs/crypto/crypto.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index 61057b7dbddb..1637a0450b9f 100644 ---

fscrypto: Two trivial patches

Thanks, //richard [PATCH 1/2] fscrypto: Fix log string in do_crypto() [PATCH 2/2] fscrypto: Fix fscrypt_decrypt_page() doc string

[PATCH 2/2] fscrypto: Fix fscrypt_decrypt_page() doc string

Most likely a copy error from the f2fs import. Signed-off-by: Richard Weinberger --- fs/crypto/crypto.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index 1637a0450b9f..d789ddbc0a46 100644 --- a/fs/crypto/crypto.c +++

[PATCH 1/2] fscrypto: Fix log string in do_crypto()

The operations supports both encryption and decryption. Signed-off-by: Richard Weinberger --- fs/crypto/crypto.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index 61057b7dbddb..1637a0450b9f 100644 --- a/fs/crypto/crypto.c +++

Re: [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver

Hi Bartosz, Thank you for the patch. On Monday 17 Oct 2016 18:30:49 Bartosz Golaszewski wrote: > Create the driver for the da8xx System Configuration and implement > support for writing to the three Master Priority registers. > > Signed-off-by: Bartosz Golaszewski >

Re: [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver

Hi Bartosz, Thank you for the patch. On Monday 17 Oct 2016 18:30:49 Bartosz Golaszewski wrote: > Create the driver for the da8xx System Configuration and implement > support for writing to the three Master Priority registers. > > Signed-off-by: Bartosz Golaszewski > --- >

Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user

On Mon, Oct 17, 2016 at 6:04 AM, Mark Rutland wrote: > On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote: >> On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland wrote: >> > The strncpy_from_user() accessor is effectively a copy_from_user() >> >

Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user

On Mon, Oct 17, 2016 at 6:04 AM, Mark Rutland wrote: > On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote: >> On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland wrote: >> > The strncpy_from_user() accessor is effectively a copy_from_user() >> > specialised to copy strings, terminating early

Re: [PATCH v2] arm64: defconfig: enable EEPROM_AT25 config option

On Tue, Oct 18, 2016 at 1:38 PM, Scott Branden wrote: > Hi Olof, > > On 16-10-17 05:04 PM, Olof Johansson wrote: >> >> On Mon, Oct 17, 2016 at 4:24 PM, Scott Branden >> wrote: >>> >>> Hi Olof, >>> >>> On 16-10-17 02:58 PM, Olof Johansson

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Mon, Oct 17, 2016 at 6:44 AM, Mark Rutland wrote: > Hi, > > Attempt to revive discussions below... > > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote: >> When kernel.perf_event_paranoid is set to 3 (or greater), disallow >> all access to performance

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Mon, Oct 17, 2016 at 6:44 AM, Mark Rutland wrote: > Hi, > > Attempt to revive discussions below... > > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote: >> When kernel.perf_event_paranoid is set to 3 (or greater), disallow >> all access to performance events by users without

Re: [PATCH v2] arm64: defconfig: enable EEPROM_AT25 config option

On Tue, Oct 18, 2016 at 1:38 PM, Scott Branden wrote: > Hi Olof, > > On 16-10-17 05:04 PM, Olof Johansson wrote: >> >> On Mon, Oct 17, 2016 at 4:24 PM, Scott Branden >> wrote: >>> >>> Hi Olof, >>> >>> On 16-10-17 02:58 PM, Olof Johansson wrote: Hi, On Wed, Oct 12, 2016

[PATCH] ubifs: Fix xattr_names length in exit paths

When the operation fails we also have to undo the changes we made to ->xattr_names. Otherwise listxattr() will report wrong lengths. Cc: sta...@vger.kernel.org Signed-off-by: Richard Weinberger --- fs/ubifs/xattr.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH] ubifs: Fix xattr_names length in exit paths

When the operation fails we also have to undo the changes we made to ->xattr_names. Otherwise listxattr() will report wrong lengths. Cc: sta...@vger.kernel.org Signed-off-by: Richard Weinberger --- fs/ubifs/xattr.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ubifs/xattr.c

[PATCH] ubifs: Rename ubifs_rename2

Since ->rename2 is gone, rename ubifs_rename2() to ubifs_rename(). Suggested-by: Linus Torvalds Signed-off-by: Richard Weinberger --- fs/ubifs/dir.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/ubifs/dir.c

[PATCH] ubifs: Rename ubifs_rename2

Since ->rename2 is gone, rename ubifs_rename2() to ubifs_rename(). Suggested-by: Linus Torvalds Signed-off-by: Richard Weinberger --- fs/ubifs/dir.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index c8f60df2733e..668ec3b90ea1

Re: [PATCH 1/3] ARM: memory: da8xx-ddrctl: new driver

Hi Bartosz, Thank you for the patch. On Monday 17 Oct 2016 18:30:48 Bartosz Golaszewski wrote: > Create a new driver for the da8xx DDR2/mDDR controller and implement > support for writing to the Peripheral Bus Burst Priority Register. > > Signed-off-by: Bartosz Golaszewski

Re: [PATCH 1/3] ARM: memory: da8xx-ddrctl: new driver

Hi Bartosz, Thank you for the patch. On Monday 17 Oct 2016 18:30:48 Bartosz Golaszewski wrote: > Create a new driver for the da8xx DDR2/mDDR controller and implement > support for writing to the Peripheral Bus Burst Priority Register. > > Signed-off-by: Bartosz Golaszewski > --- >

Re: Difficulties around "fixdep" for the usage of a kernel build output directory

On Tue, Oct 18, 2016 at 10:25 AM, SF Markus Elfring wrote: > Can it be that the passing of the adjusted parameter "HOSTCFLAGS" has got a > significant > influence (with unwanted side effects) in this use case? That's probably it. If I strip down your advanced

Re: Difficulties around "fixdep" for the usage of a kernel build output directory

On Tue, Oct 18, 2016 at 10:25 AM, SF Markus Elfring wrote: > Can it be that the passing of the adjusted parameter "HOSTCFLAGS" has got a > significant > influence (with unwanted side effects) in this use case? That's probably it. If I strip down your advanced original example to just make

[PATCH 2/2] gpio: ts4800: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 2/2] gpio: ts4800: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 1/2] gpio: ath79: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH 1/2] gpio: ath79: Fix module autoload

If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo

[PATCH v3] arm64: defconfig: enable EEPROM_AT25 config option

Enable support for on board SPI EEPROM by setting CONFIG_EEPROM_AT25=m Signed-off-by: Scott Branden --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index eadf485..4c62662

[PATCH v3] arm64: defconfig: enable EEPROM_AT25 config option

Enable support for on board SPI EEPROM by setting CONFIG_EEPROM_AT25=m Signed-off-by: Scott Branden --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index eadf485..4c62662 100644 ---

Re: 784d5699eddc ("x86: move exports to actual definitions")

On 2016.10.18 at 22:29 +0200, Markus Trippelsdorf wrote: > On 2016.10.18 at 22:23 +0200, Borislav Petkov wrote: > > Hey Al, > > > > I see the gazillion warnings below when building -rc1 here. > > > > When I revert > > > > 784d5699eddc ("x86: move exports to actual definitions") > > > > the

Re: 784d5699eddc ("x86: move exports to actual definitions")

On 2016.10.18 at 22:29 +0200, Markus Trippelsdorf wrote: > On 2016.10.18 at 22:23 +0200, Borislav Petkov wrote: > > Hey Al, > > > > I see the gazillion warnings below when building -rc1 here. > > > > When I revert > > > > 784d5699eddc ("x86: move exports to actual definitions") > > > > the

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