[PATCH 2/5] kprobes/x86: Fix to set RWX bits correctly before releasing trampoline

From: Masami Hiramatsu Fix kprobes to set(recover) RWX bits correctly on trampoline buffer before releasing it. Releasing readonly page to module_memfree() crash the kernel. Without this fix, if kprobes user register a bunch of kprobes in function body (since kprobes on

[PATCH 2/5] kprobes/x86: Fix to set RWX bits correctly before releasing trampoline

From: Masami Hiramatsu Fix kprobes to set(recover) RWX bits correctly on trampoline buffer before releasing it. Releasing readonly page to module_memfree() crash the kernel. Without this fix, if kprobes user register a bunch of kprobes in function body (since kprobes on function entry usually

Re: [PATCH v4] usb: typec: Add a sysfs node to manage port type

On 05/26/2017 04:07 PM, Badhri Jagan Sridharan wrote: User space applications in some cases have the need to enforce a specific port type(DFP/UFP/DRP). This change allows userspace to attempt setting the desired port type. Low level drivers can however reject the request if the specific port

Re: [PATCH v4] usb: typec: Add a sysfs node to manage port type

On 05/26/2017 04:07 PM, Badhri Jagan Sridharan wrote: User space applications in some cases have the need to enforce a specific port type(DFP/UFP/DRP). This change allows userspace to attempt setting the desired port type. Low level drivers can however reject the request if the specific port

Re: [4.12 REGRESSION] pinctrl: rockchip: sleeping function called from atomic context

Any thoughts? Revert the offending patch? I can spend a little more time next week trying to debug what's actually going on if needed. Brian On Wed, May 17, 2017 at 03:56:34PM -0700, Brian Norris wrote: > Hi, > > Looks like we've added a mutex in the ->bus_lock() callback for > Rockchip's

Re: [4.12 REGRESSION] pinctrl: rockchip: sleeping function called from atomic context

Any thoughts? Revert the offending patch? I can spend a little more time next week trying to debug what's actually going on if needed. Brian On Wed, May 17, 2017 at 03:56:34PM -0700, Brian Norris wrote: > Hi, > > Looks like we've added a mutex in the ->bus_lock() callback for > Rockchip's

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

On 05/26/17 at 12:17pm, Xunlei Pang wrote: > On 04/19/2017 at 05:21 AM, Tom Lendacky wrote: > > Provide support so that kexec can be used to boot a kernel when SME is > > enabled. > > > > Support is needed to allocate pages for kexec without encryption. This > > is needed in order to be able to

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

On 05/26/17 at 12:17pm, Xunlei Pang wrote: > On 04/19/2017 at 05:21 AM, Tom Lendacky wrote: > > Provide support so that kexec can be used to boot a kernel when SME is > > enabled. > > > > Support is needed to allocate pages for kexec without encryption. This > > is needed in order to be able to

Re: [PATCH v3 1/1] partitions/msdos: FreeBSD UFS2 file systems are not recognized

(please keep replies on the list) On Fri, 2017-05-26 at 18:33 -0700, Richard Narron wrote: > On Fri, 26 May 2017, Joe Perches wrote: > > On Fri, 2017-05-26 at 16:30 -0700, Richard Narron wrote: > > > On Fri, 26 May 2017, Joe Perches wrote: > > > > On Fri, 2017-05-26 at 03:48 -0700, Richard Narron

Re: [PATCH v3 1/1] partitions/msdos: FreeBSD UFS2 file systems are not recognized

(please keep replies on the list) On Fri, 2017-05-26 at 18:33 -0700, Richard Narron wrote: > On Fri, 26 May 2017, Joe Perches wrote: > > On Fri, 2017-05-26 at 16:30 -0700, Richard Narron wrote: > > > On Fri, 26 May 2017, Joe Perches wrote: > > > > On Fri, 2017-05-26 at 03:48 -0700, Richard Narron

Re: [PATCH] drivers/watchdog/Kconfig: Update CONFIG_WATCHDOG_RTAS dependencies

On 05/26/2017 06:22 PM, Murilo Opsfelder Araujo wrote: drivers/watchdog/wdrtas.c uses symbols defined in arch/powerpc/kernel/rtas.c, which are exported iff CONFIG_PPC_RTAS is selected. Building wdrtas.c without setting CONFIG_PPC_RTAS throws the following errors: ERROR: ".rtas_token"

Re: [PATCH] drivers/watchdog/Kconfig: Update CONFIG_WATCHDOG_RTAS dependencies

On 05/26/2017 06:22 PM, Murilo Opsfelder Araujo wrote: drivers/watchdog/wdrtas.c uses symbols defined in arch/powerpc/kernel/rtas.c, which are exported iff CONFIG_PPC_RTAS is selected. Building wdrtas.c without setting CONFIG_PPC_RTAS throws the following errors: ERROR: ".rtas_token"

[PATCH v2 01/20] NFS: Avoid cross-structure casting

When the call to nfs_devname() fails, the error path attempts to retain the error via the mnt variable, but this requires a cast across very different types (char * to struct vfsmount *), which the upcoming structure layout randomization plugin flags as being potentially dangerous in the face of

[PATCH v2 03/20] compiler: Add __designated_init annotation

This allows structure annotations for requiring designated initialization in GCC 5.1.0 and later: https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html The structure randomization layout plugin will be using this to help identify structures that need this form of initialization.

[PATCH v2 01/20] NFS: Avoid cross-structure casting

When the call to nfs_devname() fails, the error path attempts to retain the error via the mnt variable, but this requires a cast across very different types (char * to struct vfsmount *), which the upcoming structure layout randomization plugin flags as being potentially dangerous in the face of

[PATCH v2 03/20] compiler: Add __designated_init annotation

This allows structure annotations for requiring designated initialization in GCC 5.1.0 and later: https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html The structure randomization layout plugin will be using this to help identify structures that need this form of initialization.

[PATCH v2 00/20] Introduce struct layout randomization plugin

This series brings grsecurity's structure layout randomization plugin to upstream. The plugin randomizes the layout of selected structures at compile time, as a probabilistic defense against attacks that need to know the layout of structures within the kernel. This is most useful for "in-house"

[PATCH v2 00/20] Introduce struct layout randomization plugin

This series brings grsecurity's structure layout randomization plugin to upstream. The plugin randomizes the layout of selected structures at compile time, as a probabilistic defense against attacks that need to know the layout of structures within the kernel. This is most useful for "in-house"

[PATCH v2 04/20] gcc-plugins: Add the randstruct plugin

This feature is ported from grsecurity. The implementation is almost entirely identical to the original code written by the PaX Team and Brad Spengler. The new plugin randomizes the layout of selected structures at compile time. This is a probabilistic defense against attacks that need to know

[PATCH v2 04/20] gcc-plugins: Add the randstruct plugin

This feature is ported from grsecurity. The implementation is almost entirely identical to the original code written by the PaX Team and Brad Spengler. The new plugin randomizes the layout of selected structures at compile time. This is a probabilistic defense against attacks that need to know

[PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast

The LSM initialization routines walk security_hook_heads as an array of struct list_head instead of via names to avoid a ton of needless source. Whitelist this to avoid the false positive warning from the plugin: security/security.c: In function ‘security_init’: security/security.c:59:20: note:

[PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast

The LSM initialization routines walk security_hook_heads as an array of struct list_head instead of via names to avoid a ton of needless source. Whitelist this to avoid the false positive warning from the plugin: security/security.c: In function ‘security_init’: security/security.c:59:20: note:

[PATCH v2 06/20] randstruct: Whitelist UNIXCB cast

This is another false positive in bad cast detection: net/unix/af_unix.c: In function ‘unix_skb_scm_eq’: net/unix/af_unix.c:1621:31: note: found mismatched rhs struct pointer types: ‘struct unix_skb_parms’ and ‘char’ const struct unix_skb_parms *u = (skb); ^

[PATCH v2 06/20] randstruct: Whitelist UNIXCB cast

This is another false positive in bad cast detection: net/unix/af_unix.c: In function ‘unix_skb_scm_eq’: net/unix/af_unix.c:1621:31: note: found mismatched rhs struct pointer types: ‘struct unix_skb_parms’ and ‘char’ const struct unix_skb_parms *u = (skb); ^

[PATCH v2 07/20] randstruct: Whitelist big_key path struct overloading

The big_key payload structure intentionally stores a struct path in two void pointers to avoid header soup. Whitelist this case: security/keys/big_key.c: In function ‘big_key_read’: security/keys/big_key.c:293:16: note: found mismatched rhs struct pointer types: ‘struct path’ and ‘void *’

[PATCH v2 07/20] randstruct: Whitelist big_key path struct overloading

The big_key payload structure intentionally stores a struct path in two void pointers to avoid header soup. Whitelist this case: security/keys/big_key.c: In function ‘big_key_read’: security/keys/big_key.c:293:16: note: found mismatched rhs struct pointer types: ‘struct path’ and ‘void *’

[PATCH v2 08/20] randstruct: Whitelist NIU struct page overloading

The NIU ethernet driver intentionally stores a page struct pointer on top of the "mapping" field. Whitelist this case: drivers/net/ethernet/sun/niu.c: In function ‘niu_rx_pkt_ignore’: drivers/net/ethernet/sun/niu.c:3402:10: note: found mismatched ssa struct pointer types: ‘struct page’ and

[PATCH v2 08/20] randstruct: Whitelist NIU struct page overloading

The NIU ethernet driver intentionally stores a page struct pointer on top of the "mapping" field. Whitelist this case: drivers/net/ethernet/sun/niu.c: In function ‘niu_rx_pkt_ignore’: drivers/net/ethernet/sun/niu.c:3402:10: note: found mismatched ssa struct pointer types: ‘struct page’ and

[PATCH v2 09/20] randstruct: Mark various structs for randomization

This marks many critical kernel structures for randomization. These are structures that have been targeted in the past in security exploits, or contain functions pointers, pointers to function pointer tables, lists, workqueues, ref-counters, credentials, permissions, or are otherwise sensitive.

[PATCH v2 09/20] randstruct: Mark various structs for randomization

This marks many critical kernel structures for randomization. These are structures that have been targeted in the past in security exploits, or contain functions pointers, pointers to function pointer tables, lists, workqueues, ref-counters, credentials, permissions, or are otherwise sensitive.

[PATCH v2 10/20] randstruct: opt-out externally exposed function pointer structs

Some function pointer structures are used externally to the kernel, like the paravirt structures. These should never be randomized, so mark them as such. This set was extracted from grsecurity. Signed-off-by: Kees Cook --- arch/arm/include/asm/cacheflush.h | 2 +-

[PATCH v2 10/20] randstruct: opt-out externally exposed function pointer structs

Some function pointer structures are used externally to the kernel, like the paravirt structures. These should never be randomized, so mark them as such. This set was extracted from grsecurity. Signed-off-by: Kees Cook --- arch/arm/include/asm/cacheflush.h | 2 +-

[PATCH v2 12/20] sgi-xp: Use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. To avoid casting, this implements dummy functions

[PATCH v2 11/20] randstruct: Disable randomization of ACPICA structs

Since the ACPICA source is maintained externally to the kernel, we can neither switch it to designated initializers nor mark it __no_randomize_layout. Until ACPICA-upstream changes[1] land to handle the designated initialization, explicitly skip it in the plugin. [1]

[PATCH v2 12/20] sgi-xp: Use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. To avoid casting, this implements dummy functions

[PATCH v2 11/20] randstruct: Disable randomization of ACPICA structs

Since the ACPICA source is maintained externally to the kernel, we can neither switch it to designated initializers nor mark it __no_randomize_layout. Until ACPICA-upstream changes[1] land to handle the designated initialization, explicitly skip it in the plugin. [1]

Re: [PATCH v3 1/2] remoteproc: Introduce rproc_{start,stop}() functions

On Fri 26 May 16:51 PDT 2017, Sarangdhar Joshi wrote: > In the context of recovering from crash, rproc_trigger_recovery() does > rproc_shutdown() followed by rproc_boot(). The remoteproc resources are > cleaned up in rproc_shutdown() and immediately reallocated in > rproc_boot() which is an

Re: [PATCH v3 1/2] remoteproc: Introduce rproc_{start,stop}() functions

On Fri 26 May 16:51 PDT 2017, Sarangdhar Joshi wrote: > In the context of recovering from crash, rproc_trigger_recovery() does > rproc_shutdown() followed by rproc_boot(). The remoteproc resources are > cleaned up in rproc_shutdown() and immediately reallocated in > rproc_boot() which is an

[PATCH v2 14/20] drm/amd/powerplay: Use designated initializers

The randstruct plugin requires designated initializers for structures that are entirely function pointers. Cc: Christian König Cc: Eric Huang Cc: Alex Deucher Signed-off-by: Kees Cook ---

[PATCH v2 14/20] drm/amd/powerplay: Use designated initializers

The randstruct plugin requires designated initializers for structures that are entirely function pointers. Cc: Christian König Cc: Eric Huang Cc: Alex Deucher Signed-off-by: Kees Cook --- .../gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c | 28 ++ 1 file changed, 18

[PATCH v2 15/20] mtk-vcodec: Use designated initializers

The randstruct plugin requires designated initializers for structures that are entirely function pointers. Cc: Wu-Cheng Li Cc: PC Chen Cc: Tiffany Lin Cc: Hans Verkuil Cc: Mauro Carvalho Chehab

[PATCH v2 15/20] mtk-vcodec: Use designated initializers

The randstruct plugin requires designated initializers for structures that are entirely function pointers. Cc: Wu-Cheng Li Cc: PC Chen Cc: Tiffany Lin Cc: Hans Verkuil Cc: Mauro Carvalho Chehab Signed-off-by: Kees Cook --- drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c | 8

[PATCH v2 13/20] drm/amdgpu: Use designated initializers

The randstruct plugin requires structures that are entirely function pointers be initialized using designated initializers. Cc: Alex Deucher Cc: Christian König Signed-off-by: Kees Cook ---

[PATCH v2 13/20] drm/amdgpu: Use designated initializers

The randstruct plugin requires structures that are entirely function pointers be initialized using designated initializers. Cc: Alex Deucher Cc: Christian König Signed-off-by: Kees Cook --- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 10 +- 1 file changed, 5 insertions(+), 5

[PATCH v2 16/20] ntfs: Use ERR_CAST() to avoid cross-structure cast

When trying to propagate an error result, the error return path attempts to retain the error, but does this with an open cast across very different types, which the upcoming structure layout randomization plugin flags as being potentially dangerous in the face of randomization. This is a false

[PATCH v2 16/20] ntfs: Use ERR_CAST() to avoid cross-structure cast

When trying to propagate an error result, the error return path attempts to retain the error, but does this with an open cast across very different types, which the upcoming structure layout randomization plugin flags as being potentially dangerous in the face of randomization. This is a false

[PATCH v2 17/20] ocfs2: Use ERR_CAST() to avoid cross-structure cast

When trying to propagate an error result, the error return path attempts to retain the error, but does this with an open cast across very different types, which the upcoming structure layout randomization plugin flags as being potentially dangerous in the face of randomization. This is a false

[PATCH v2 17/20] ocfs2: Use ERR_CAST() to avoid cross-structure cast

When trying to propagate an error result, the error return path attempts to retain the error, but does this with an open cast across very different types, which the upcoming structure layout randomization plugin flags as being potentially dangerous in the face of randomization. This is a false

[PATCH v2 19/20] [RFC] task_struct: Allow randomized layout

This marks most of the layout of task_struct as randomizable, but leaves thread_info and scheduler state untouched at the start, and thread_struct untouched at the end. Other parts of the kernel use unnamed structures, but the 0-day builder using gcc-4.4 blows up on static initializers.

[PATCH v2 19/20] [RFC] task_struct: Allow randomized layout

This marks most of the layout of task_struct as randomizable, but leaves thread_info and scheduler state untouched at the start, and thread_struct untouched at the end. Other parts of the kernel use unnamed structures, but the 0-day builder using gcc-4.4 blows up on static initializers.

[PATCH v2 20/20] ACPICA: Use designated initializers

The struct layout randomization plugin detects and randomizes any structs that contain only function pointers. Once layout is randomized, all initialization must be designated or the compiler will misalign the assignments. This switches all the ACPICA function pointer struct to use designated

[PATCH v2 20/20] ACPICA: Use designated initializers

The struct layout randomization plugin detects and randomizes any structs that contain only function pointers. Once layout is randomized, all initialization must be designated or the compiler will misalign the assignments. This switches all the ACPICA function pointer struct to use designated

Re: [PATCH] misc: ad525x_dpot_spi: Add device tree support

On Fri, May 26, 2017 at 8:17 PM, Roshni Shah wrote: > @@ -81,14 +82,26 @@ static const struct ad_dpot_bus_ops bops = { > +static const struct of_device_id ad_dpot_spi_of_match[] = { > + { > + .compatible = "ad,ad5160", > + .name

Re: [PATCH] misc: ad525x_dpot_spi: Add device tree support

On Fri, May 26, 2017 at 8:17 PM, Roshni Shah wrote: > @@ -81,14 +82,26 @@ static const struct ad_dpot_bus_ops bops = { > +static const struct of_device_id ad_dpot_spi_of_match[] = { > + { > + .compatible = "ad,ad5160", > + .name = "ad5160", > +

[PATCH 0/4] Add DT support for davinci remoteproc driver

Hi, The following series adds the device tree support to the Davinci remoteproc driver. The TI Davinci family has boards booting both in legacy mode and DT mode, so both modes are still supported by this driver. Patches are baselined on 4.12-rc1 + the "Davinci remoteproc cleanups/fixes" series

[PATCH 0/4] Add DT support for davinci remoteproc driver

Hi, The following series adds the device tree support to the Davinci remoteproc driver. The TI Davinci family has boards booting both in legacy mode and DT mode, so both modes are still supported by this driver. Patches are baselined on 4.12-rc1 + the "Davinci remoteproc cleanups/fixes" series

[PATCH 4/4] remoteproc/davinci: Add device tree support for OMAP-L138 DSP

The Davinci remoteproc driver currently supports the DSP remoteproc device created in legacy-style on OMAP-L13x SoCs. The driver has been enhanced to support the DSP remoteproc device created through Device Tree now. The current DT support handles the C674x DSP processor subsystem on OMAP-L138

[PATCH 4/4] remoteproc/davinci: Add device tree support for OMAP-L138 DSP

The Davinci remoteproc driver currently supports the DSP remoteproc device created in legacy-style on OMAP-L13x SoCs. The driver has been enhanced to support the DSP remoteproc device created through Device Tree now. The current DT support handles the C674x DSP processor subsystem on OMAP-L138

[PATCH 3/4] Documentation: dt: Add bindings for Davinci DSP processors

Add the device tree bindings document for the DSP processor subsystem devices on TI Davinci DA8xx/OMAP-L13x SoCs. Signed-off-by: Suman Anna --- .../bindings/remoteproc/ti,davinci-rproc.txt | 92 ++ 1 file changed, 92 insertions(+) create mode 100644

[PATCH 2/4] remoteproc/davinci: add support to parse internal memories

The DSP subsystem on OMAP-L13x SoCs has various internal RAM memories that can accessed from the ARM side. These memories can be configured to be used as either RAM or Cache. The Davinci remoteproc driver has been enhanced to parse and store the kernel mappings for these internal RAM memories.

[PATCH 3/4] Documentation: dt: Add bindings for Davinci DSP processors

Add the device tree bindings document for the DSP processor subsystem devices on TI Davinci DA8xx/OMAP-L13x SoCs. Signed-off-by: Suman Anna --- .../bindings/remoteproc/ti,davinci-rproc.txt | 92 ++ 1 file changed, 92 insertions(+) create mode 100644

[PATCH 2/4] remoteproc/davinci: add support to parse internal memories

The DSP subsystem on OMAP-L13x SoCs has various internal RAM memories that can accessed from the ARM side. These memories can be configured to be used as either RAM or Cache. The Davinci remoteproc driver has been enhanced to parse and store the kernel mappings for these internal RAM memories.

Re: [PATCH v9 1/7] LIB: Introduce a generic PIO mapping method

On Thu, May 25, 2017 at 12:37:22PM +0100, Gabriele Paoloni wrote: > From: "zhichang.yuan" > > In 'commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and > pci_pio_to_address()")' a new I/O space management was supported. With that > driver, the I/O ranges

[stable backport PATCH v2] usercopy: Adjust tests to deal with SMAP/PAN

From: Kees Cook Commit f5f893c57e37ca730808cb2eee3820abd05e7507 upstream. Under SMAP/PAN/etc, we cannot write directly to userspace memory, so this rearranges the test bytes to get written through copy_to_user(). Additionally drops the bad copy_from_user() test that would

Re: [PATCH v9 1/7] LIB: Introduce a generic PIO mapping method

On Thu, May 25, 2017 at 12:37:22PM +0100, Gabriele Paoloni wrote: > From: "zhichang.yuan" > > In 'commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and > pci_pio_to_address()")' a new I/O space management was supported. With that > driver, the I/O ranges configured for PCI/PCIE hosts on

[stable backport PATCH v2] usercopy: Adjust tests to deal with SMAP/PAN

From: Kees Cook Commit f5f893c57e37ca730808cb2eee3820abd05e7507 upstream. Under SMAP/PAN/etc, we cannot write directly to userspace memory, so this rearranges the test bytes to get written through copy_to_user(). Additionally drops the bad copy_from_user() test that would trigger a memcpy()

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 26 May 2017 at 21:40, Luis R. Rodriguez wrote: > On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: >> On 25 May 2017 at 06:13, Andy Lutomirski wrote: >> >>> >> >>> Can you give a simple example of what's going on and why it matters? >> >>> >>

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 26 May 2017 at 21:40, Luis R. Rodriguez wrote: > On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: >> On 25 May 2017 at 06:13, Andy Lutomirski wrote: >> >>> >> >>> Can you give a simple example of what's going on and why it matters? >> >>> >> >> >> Here is the use case in which

Re: [PATCH v2 19/20] [RFC] task_struct: Allow randomized layout

On Fri, May 26, 2017 at 1:17 PM, Kees Cook wrote: > This marks most of the layout of task_struct as randomizable, but leaves > thread_info and scheduler state untouched at the start, and thread_struct > untouched at the end. I think you want to abstract this out somehow,

Re: [PATCH v2 19/20] [RFC] task_struct: Allow randomized layout

On Fri, May 26, 2017 at 1:17 PM, Kees Cook wrote: > This marks most of the layout of task_struct as randomizable, but leaves > thread_info and scheduler state untouched at the start, and thread_struct > untouched at the end. I think you want to abstract this out somehow, because this is both

Re: [PATCH v2 5/5] HID: intel_ish-hid: enable compile testing

On Thu, 2017-05-18 at 22:21 +0200, Arnd Bergmann wrote: > To increase build coverage, drivers should generally be allowed to > build on other architectures even if they are only used on one > of them. > > Signed-off-by: Arnd Bergmann  Acked-by: Srinivas Pandruvada

Re: [PATCH v2 5/5] HID: intel_ish-hid: enable compile testing

On Thu, 2017-05-18 at 22:21 +0200, Arnd Bergmann wrote: > To increase build coverage, drivers should generally be allowed to > build on other architectures even if they are only used on one > of them. > > Signed-off-by: Arnd Bergmann  Acked-by: Srinivas Pandruvada > --- >  

Re: arm64 test_user_copy crash on copy_from_user(uptr, kptr, size)

On Fri, May 26, 2017 at 5:40 PM, Mark Rutland wrote: > On Fri, May 26, 2017 at 05:24:47PM +0200, Arnd Bergmann wrote: > AFAICT, that test was disabled in commit: > > f5f893c57e37ca73 ("usercopy: Adjust tests to deal with SMAP/PAN") > > ... or have I misunderstood? I

Re: arm64 test_user_copy crash on copy_from_user(uptr, kptr, size)

On Fri, May 26, 2017 at 5:40 PM, Mark Rutland wrote: > On Fri, May 26, 2017 at 05:24:47PM +0200, Arnd Bergmann wrote: > AFAICT, that test was disabled in commit: > > f5f893c57e37ca73 ("usercopy: Adjust tests to deal with SMAP/PAN") > > ... or have I misunderstood? I think you are right, my

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 10:23:03PM +0200, Fuzzey, Martin wrote: > On 26 May 2017 at 21:40, Luis R. Rodriguez wrote: > > > > No no, this is not how the fallback system works. > > The sysfs file I was talking about is *not* the sysfs file involved in > the firmware loading

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 10:23:03PM +0200, Fuzzey, Martin wrote: > On 26 May 2017 at 21:40, Luis R. Rodriguez wrote: > > > > No no, this is not how the fallback system works. > > The sysfs file I was talking about is *not* the sysfs file involved in > the firmware loading mechanism > but a

Re: [PATCHv3] usb: typec: Add a sysfs node to manage port type

On Fri, May 26, 2017 at 11:31 AM, Greg Kroah-Hartman wrote: > On Fri, May 26, 2017 at 10:45:59AM -0700, Badhri Jagan Sridharan wrote: >> User space applications in some cases have the need to enforce a >> specific port type(DFP/UFP/DRP). This change allows userspace to

Re: [PATCHv3] usb: typec: Add a sysfs node to manage port type

On Fri, May 26, 2017 at 11:31 AM, Greg Kroah-Hartman wrote: > On Fri, May 26, 2017 at 10:45:59AM -0700, Badhri Jagan Sridharan wrote: >> User space applications in some cases have the need to enforce a >> specific port type(DFP/UFP/DRP). This change allows userspace to >> attempt setting the

Re: [PATCH v2 4/5] HID: intel_ish-hid: fix format string for size_t

On Thu, 2017-05-18 at 22:21 +0200, Arnd Bergmann wrote: > When building for 32-bit architectures, we get a harmless warning: > > intel-ish-hid/ishtp-hid-client.c: In function 'process_recv': > intel-ish-hid/ishtp-hid-client.c:139:7: error: format '%lu' expects > argument of type 'long unsigned

Re: [PATCH v2 4/5] HID: intel_ish-hid: fix format string for size_t

On Thu, 2017-05-18 at 22:21 +0200, Arnd Bergmann wrote: > When building for 32-bit architectures, we get a harmless warning: > > intel-ish-hid/ishtp-hid-client.c: In function 'process_recv': > intel-ish-hid/ishtp-hid-client.c:139:7: error: format '%lu' expects > argument of type 'long unsigned

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

hi Luis On 5/25/2017 5:43 PM, Luis R. Rodriguez wrote: On Thu, May 25, 2017 at 3:30 PM, Li, Yi wrote: This patch is for "disabling the cache" for streaming and iwlwifi case, adding the test to verify the cache function should be a separate patch, right? I can look

[PATCH] JFS: do not ignore return code from write_one_page()

There are a couple places where jfs calls write_one_page() where clean recovery is not possible. In these cases, the file system should be marked dirty. To do this, it is now necessary to store the superblock in the metapage structure. Signed-off-by: Dave Kleikamp ---

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

hi Luis On 5/25/2017 5:43 PM, Luis R. Rodriguez wrote: On Thu, May 25, 2017 at 3:30 PM, Li, Yi wrote: This patch is for "disabling the cache" for streaming and iwlwifi case, adding the test to verify the cache function should be a separate patch, right? I can look more into the cache part.

[PATCH] JFS: do not ignore return code from write_one_page()

There are a couple places where jfs calls write_one_page() where clean recovery is not possible. In these cases, the file system should be marked dirty. To do this, it is now necessary to store the superblock in the metapage structure. Signed-off-by: Dave Kleikamp --- fs/jfs/jfs_metapage.c | 7

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez wrote: > On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote: >> "Fuzzey, Martin" writes: >> Maybe SIGCHLD shouldn't interrupt firmware loading? >> > >> > I don't think there's a way of

[PATCH 1/3] cfq-iosched: Mark cfq_clear_cfqq_*() as __maybe_unused

This fixes the following warning when building with clang: block/cfq-iosched.c:449:1: error: unused function 'cfq_clear_cfqq_sync' [-Werror,-Wunused-function] Signed-off-by: Matthias Kaehlcke --- block/cfq-iosched.c | 3 ++- 1 file changed, 2 insertions(+), 1

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez wrote: > On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote: >> "Fuzzey, Martin" writes: >> Maybe SIGCHLD shouldn't interrupt firmware loading? >> > >> > I don't think there's a way of doing that without disabling all >> >

[PATCH 1/3] cfq-iosched: Mark cfq_clear_cfqq_*() as __maybe_unused

This fixes the following warning when building with clang: block/cfq-iosched.c:449:1: error: unused function 'cfq_clear_cfqq_sync' [-Werror,-Wunused-function] Signed-off-by: Matthias Kaehlcke --- block/cfq-iosched.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[PATCH V4 1/2] powerpc/numa: Update CPU topology when VPHN enabled

powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities

[PATCH V4 1/2] powerpc/numa: Update CPU topology when VPHN enabled

powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities

Re: [PATCH] Revert "timers: Don't wake ktimersoftd on every tick"

On Fri, 26 May 2017, Haris Okanovic wrote: > Oh crap. I think I see the problem. I decrement expired_count before > processing the list. Dropping the lock permits another run of > tick_find_expired()->find_expired_timers() in the middle of __expire_timers() > since it uses expired_count==0 as a

Re: [PATCH] Revert "timers: Don't wake ktimersoftd on every tick"

On Fri, 26 May 2017, Haris Okanovic wrote: > Oh crap. I think I see the problem. I decrement expired_count before > processing the list. Dropping the lock permits another run of > tick_find_expired()->find_expired_timers() in the middle of __expire_timers() > since it uses expired_count==0 as a

[PATCH v3 4/4] kmod: throttle kmod thread limit

If we reach the limit of modprobe_limit threads running the next request_module() call will fail. The original reason for adding a kill was to do away with possible issues with in old circumstances which would create a recursive series of request_module() calls. We can do better than just be super

[PATCH v3 4/4] kmod: throttle kmod thread limit

If we reach the limit of modprobe_limit threads running the next request_module() call will fail. The original reason for adding a kill was to do away with possible issues with in old circumstances which would create a recursive series of request_module() calls. We can do better than just be super

Re: [PATCH v3 3/4] dt-bindings: power: tps65217_charger: add NTC type for battery temperature measurement.

Hi Enric, On Fri, May 26, 2017 at 4:04 AM, Enric Balletbo i Serra wrote: > The TS pin of the TPS56217 connects to the NTC resistor in the battery > pack. By default the device is setup to support a 10-kohm but can also > be configured to support a 100-kohm. Add a

Re: [PATCH v3 3/4] dt-bindings: power: tps65217_charger: add NTC type for battery temperature measurement.

Hi Enric, On Fri, May 26, 2017 at 4:04 AM, Enric Balletbo i Serra wrote: > The TS pin of the TPS56217 connects to the NTC resistor in the battery > pack. By default the device is setup to support a 10-kohm but can also > be configured to support a 100-kohm. Add a propietry to configure the >

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

On Fri, May 26, 2017 at 04:05:43PM -0500, Li, Yi wrote: > hi Luis > > > On 5/25/2017 5:43 PM, Luis R. Rodriguez wrote: > > On Thu, May 25, 2017 at 3:30 PM, Li, Yi wrote: > > > This patch is for "disabling the cache" for streaming and iwlwifi case, > > > adding the test

Re: [stable backport PATCH] usercopy: Adjust tests to deal with SMAP/PAN

On Fri, May 26, 2017 at 10:53 PM, Kees Cook wrote: >> + >> + value = 0x5a; > > I don't think this "value" bit wanted, but it should be harmless. > Right, that should not be there, it came from a different patch. I've sent a new version of the backport now. Thanks for

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

On Fri, May 26, 2017 at 04:05:43PM -0500, Li, Yi wrote: > hi Luis > > > On 5/25/2017 5:43 PM, Luis R. Rodriguez wrote: > > On Thu, May 25, 2017 at 3:30 PM, Li, Yi wrote: > > > This patch is for "disabling the cache" for streaming and iwlwifi case, > > > adding the test to verify the cache

Re: [stable backport PATCH] usercopy: Adjust tests to deal with SMAP/PAN

On Fri, May 26, 2017 at 10:53 PM, Kees Cook wrote: >> + >> + value = 0x5a; > > I don't think this "value" bit wanted, but it should be harmless. > Right, that should not be there, it came from a different patch. I've sent a new version of the backport now. Thanks for taking a look.

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