Re: [linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

Hi Marc, On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai wrote: > On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng wrote: >> >> >> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier 写到: >>>On 18/05/17 08:16, Icenowy Zheng wrote: Add support

Re: [linux-sunxi] Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC

Hi Marc, On Mon, May 22, 2017 at 10:25 PM, Chen-Yu Tsai wrote: > On Mon, May 22, 2017 at 5:41 PM, Icenowy Zheng wrote: >> >> >> 于 2017年5月22日 GMT+08:00 下午5:39:22, Marc Zyngier 写到: >>>On 18/05/17 08:16, Icenowy Zheng wrote: Add support for the newly imported compatible for the A64 R_INTC in

Re: [Linux-ima-devel] [PATCH 6/7] ima: add securityfs interface to restore a measurements list

On Tue, 2017-05-16 at 14:53 +0200, Roberto Sassu wrote: > Through the new interface restore_kexec_list, it will be possible > to restore a measurements list, previously read from > binary_kexec_runtime_measurements. For development, this was fine.  You were able to save and restore the

Re: [Linux-ima-devel] [PATCH 6/7] ima: add securityfs interface to restore a measurements list

On Tue, 2017-05-16 at 14:53 +0200, Roberto Sassu wrote: > Through the new interface restore_kexec_list, it will be possible > to restore a measurements list, previously read from > binary_kexec_runtime_measurements. For development, this was fine.  You were able to save and restore the

Re: [Linux-ima-devel] [PATCH 1/7] ima: introduce ima_parse_buf()

Hi Roberto, On Tue, 2017-05-16 at 14:53 +0200, Roberto Sassu wrote: > ima_parse_buf() takes as input the buffer start and end pointers, and > stores the result in a static array of ima_field_data structures, > where the len field contains the length parsed from the buffer, and > the data field

Re: [Linux-ima-devel] [PATCH 1/7] ima: introduce ima_parse_buf()

Hi Roberto, On Tue, 2017-05-16 at 14:53 +0200, Roberto Sassu wrote: > ima_parse_buf() takes as input the buffer start and end pointers, and > stores the result in a static array of ima_field_data structures, > where the len field contains the length parsed from the buffer, and > the data field

Re: [PATCH v1 7/8] powerpc/Kconfig: Enable STRICT_KERNEL_RWX

Balbir Singh writes: > On Mon, May 29, 2017 at 6:00 PM, Christophe LEROY > wrote: >> Le 25/05/2017 à 18:45, kbuild test robot a écrit : >>> All errors (new ones prefixed by >>): >>> > kernel//power/snapshot.c:40:28: fatal error:

Re: [PATCH v1 7/8] powerpc/Kconfig: Enable STRICT_KERNEL_RWX

Balbir Singh writes: > On Mon, May 29, 2017 at 6:00 PM, Christophe LEROY > wrote: >> Le 25/05/2017 à 18:45, kbuild test robot a écrit : >>> All errors (new ones prefixed by >>): >>> > kernel//power/snapshot.c:40:28: fatal error: asm/set_memory.h: No such > file or directory >>> >>>

Re: [PATCH v4 7/8] nvmet: allow overriding the NVMe VS via configfs

On Sun, Jun 04, 2017 at 12:36:48PM +0200, Johannes Thumshirn wrote: > Allow overriding the announced NVMe Version of a via configfs. > > This is particularly helpful when debugging new features for the host > or target side without bumping the hard coded version (as the target > might not be

Re: [PATCH v4 7/8] nvmet: allow overriding the NVMe VS via configfs

On Sun, Jun 04, 2017 at 12:36:48PM +0200, Johannes Thumshirn wrote: > Allow overriding the announced NVMe Version of a via configfs. > > This is particularly helpful when debugging new features for the host > or target side without bumping the hard coded version (as the target > might not be

Re: [RFC PATCH] acpi: indicate to platform when hot remove returns busy

On Sun, Jun 04, 2017 at 06:04:53PM +0800, joeyli wrote: > Hi Andy, > > Thanks for your help to review my patch. > > On Sat, Jun 03, 2017 at 08:37:51PM +0300, Andy Shevchenko wrote: > > On Sat, Jun 3, 2017 at 8:20 PM, Lee, Chun-Yi > > wrote: > > > In hotplug logic, it

Re: [RFC PATCH] acpi: indicate to platform when hot remove returns busy

On Sun, Jun 04, 2017 at 06:04:53PM +0800, joeyli wrote: > Hi Andy, > > Thanks for your help to review my patch. > > On Sat, Jun 03, 2017 at 08:37:51PM +0300, Andy Shevchenko wrote: > > On Sat, Jun 3, 2017 at 8:20 PM, Lee, Chun-Yi > > wrote: > > > In hotplug logic, it always indicates

Re: [PATCH -next] mtd: nand: Add support for Toshiba BENAND (Built-in ECC NAND)

Hi Boris, Thank you very much for your detailed review. I just comming back from busy week for conference and started to look it. I have a question regarding to the following comment. >> static int toshiba_nand_init(struct nand_chip *chip) >> { >> +struct mtd_info *mtd =

Re: [PATCH v4 5/8] nvme: get list of namespace descriptors

> + } > + len = NVME_NIDT_UUID_LEN; > + memcpy(ns->uuid, data + pos + sizeof(*cur), len); > + break; > + default: > + dev_warn(ns->ctrl->dev, > + "Invalid

Re: [PATCH] ARM: imx6ull: Make suspend/resume work like on 6ul

On Tue, May 30, 2017 at 07:11:19PM +0300, Leonard Crestez wrote: > Suspend and resume on imx6ull is currenty not working because of some > missed checks where behavior should match imx6ul. > > Signed-off-by: Leonard Crestez > --- > arch/arm/mach-imx/mxc.h | 6 ++

Re: [PATCH v4 5/8] nvme: get list of namespace descriptors

> + } > + len = NVME_NIDT_UUID_LEN; > + memcpy(ns->uuid, data + pos + sizeof(*cur), len); > + break; > + default: > + dev_warn(ns->ctrl->dev, > + "Invalid

Re: [PATCH] ARM: imx6ull: Make suspend/resume work like on 6ul

On Tue, May 30, 2017 at 07:11:19PM +0300, Leonard Crestez wrote: > Suspend and resume on imx6ull is currenty not working because of some > missed checks where behavior should match imx6ul. > > Signed-off-by: Leonard Crestez > --- > arch/arm/mach-imx/mxc.h | 6 ++ >

Re: [PATCH -next] mtd: nand: Add support for Toshiba BENAND (Built-in ECC NAND)

Hi Boris, Thank you very much for your detailed review. I just comming back from busy week for conference and started to look it. I have a question regarding to the following comment. >> static int toshiba_nand_init(struct nand_chip *chip) >> { >> +struct mtd_info *mtd =

Re: [PATCH v4 3/8] nvmet: implement namespace identify descriptor list

I think this needs to zero the remainder of the 4k buffer, quoting the spec: "The controller may return any number of variable length Namespace Identification Descriptor structures that fit into the 4096 byte Identify payload. All remaining bytes after the namespace identification descriptor

Re: [PATCH v4 3/8] nvmet: implement namespace identify descriptor list

I think this needs to zero the remainder of the 4k buffer, quoting the spec: "The controller may return any number of variable length Namespace Identification Descriptor structures that fit into the 4096 byte Identify payload. All remaining bytes after the namespace identification descriptor

[PATCH] crypto: testmgr: use consistent format for errors

Fix inconsistent format and spelling in hash tests error messages. Signed-off-by: Gilad Ben-Yossef --- crypto/testmgr.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index 6f5f3ed..8c68c99 100644

[PATCH] crypto: testmgr: use consistent format for errors

Fix inconsistent format and spelling in hash tests error messages. Signed-off-by: Gilad Ben-Yossef --- crypto/testmgr.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index 6f5f3ed..8c68c99 100644 --- a/crypto/testmgr.c

Re: [PATCH v4 1/8] nvme: introduce NVMe Namespace Identification Descriptor structures

On Sun, Jun 04, 2017 at 05:59:06PM +0300, Sagi Grimberg wrote: >> +struct nvme_ns_identifier_hdr { >> +__u8 nidt; >> +__u8 nidl; >> +__le16 reserved; >> +}; > > Nit: _hdr is usually associated with a message or alike. > > Maybe nvme_ns_id_desc is more consistent with the spec

Re: [PATCH v4 1/8] nvme: introduce NVMe Namespace Identification Descriptor structures

On Sun, Jun 04, 2017 at 05:59:06PM +0300, Sagi Grimberg wrote: >> +struct nvme_ns_identifier_hdr { >> +__u8 nidt; >> +__u8 nidl; >> +__le16 reserved; >> +}; > > Nit: _hdr is usually associated with a message or alike. > > Maybe nvme_ns_id_desc is more consistent with the spec

Re: [PATCH v4 0/8] Implement NVMe Namespace Descriptor Identification

On Sun, Jun 04, 2017 at 12:36:41PM +0200, Johannes Thumshirn wrote: > The Namespace Identification Descriptor list is the only way a target > can identify itself via the newly introduced UUID to the host (instead > of the EUI-64 or NGUID). s/instead/in addition/ > While I was already touching

Re: [PATCH v4 0/8] Implement NVMe Namespace Descriptor Identification

On Sun, Jun 04, 2017 at 12:36:41PM +0200, Johannes Thumshirn wrote: > The Namespace Identification Descriptor list is the only way a target > can identify itself via the newly introduced UUID to the host (instead > of the EUI-64 or NGUID). s/instead/in addition/ > While I was already touching

Re: [PATCH v3 3/8] nvmet: implement namespace identify descriptor list

What about a little helper like this: ? static u16 nvmet_copy_ns_identifier(struct nvmet_req *req, u8 type, u8 len, void *id, off_t *off) { struct nvme_ns_identifier_hdr hdr = { .nidt = type, .nidl = len, }; u16 status;

Re: [PATCH v3 3/8] nvmet: implement namespace identify descriptor list

What about a little helper like this: ? static u16 nvmet_copy_ns_identifier(struct nvmet_req *req, u8 type, u8 len, void *id, off_t *off) { struct nvme_ns_identifier_hdr hdr = { .nidt = type, .nidl = len, }; u16 status;

Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

On 5/31/2017 18:50, Jani Nikula wrote: From: Chris Wilson An error during suspend (e100e_pm_suspend), [ 429.994338] ACPI : EC: event blocked [ 429.994633] e1000e: EEE TX LPI TIMER: 0011 [ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e]

Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

On 5/31/2017 18:50, Jani Nikula wrote: From: Chris Wilson An error during suspend (e100e_pm_suspend), [ 429.994338] ACPI : EC: event blocked [ 429.994633] e1000e: EEE TX LPI TIMER: 0011 [ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2 [ 430.955454]

Re: [PATCH v5 12/20] ARM: dts: uniphier: Add generic compatible string for I2C EEPROM

Hi. 2017-05-23 22:34 GMT+09:00 Javier Martinez Canillas : > The at24 driver allows to register I2C EEPROM chips using different vendor > and devices, but the I2C subsystem does not take the vendor into account > when matching using the I2C table since it only has device

Re: [PATCH v5 12/20] ARM: dts: uniphier: Add generic compatible string for I2C EEPROM

Hi. 2017-05-23 22:34 GMT+09:00 Javier Martinez Canillas : > The at24 driver allows to register I2C EEPROM chips using different vendor > and devices, but the I2C subsystem does not take the vendor into account > when matching using the I2C table since it only has device entries. > > But when

Re: [PATCH v2] swap: cond_resched in swap_cgroup_prepare()

[CC Andrew] On Sun 04-06-17 13:01:09, Yu Zhao wrote: > Saw need_resched() warnings when swapping on large swapfile (TBs) > because continuously allocating many pages in swap_cgroup_prepare() > took too long. > > We already cond_resched when freeing page in swap_cgroup_swapoff(). > Do the same

Re: [PATCH v2] swap: cond_resched in swap_cgroup_prepare()

[CC Andrew] On Sun 04-06-17 13:01:09, Yu Zhao wrote: > Saw need_resched() warnings when swapping on large swapfile (TBs) > because continuously allocating many pages in swap_cgroup_prepare() > took too long. > > We already cond_resched when freeing page in swap_cgroup_swapoff(). > Do the same

Re: [PATCH v10 4/5] i2c: aspeed: added driver for Aspeed I2C

On Fri, 2017-06-02 at 18:29 -0700, Brendan Higgins wrote: > Added initial master support for Aspeed I2C controller. Supports > fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed. > > Signed-off-by: Brendan Higgins I exercised this patch on an

Re: [PATCH v10 4/5] i2c: aspeed: added driver for Aspeed I2C

On Fri, 2017-06-02 at 18:29 -0700, Brendan Higgins wrote: > Added initial master support for Aspeed I2C controller. Supports > fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed. > > Signed-off-by: Brendan Higgins I exercised this patch on an AST2500-based machine. The results

linux-next: manual merge of the staging tree with the tty tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: include/uapi/linux/tty.h between commit: 8a8dabf2dd68 ("tty: handle the case where we cannot restore a line discipline") from the tty tree and commit: 1ab92da32e37 ("staging: speakup: add tty-based comms

linux-next: manual merge of the staging tree with the tty tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: include/uapi/linux/tty.h between commit: 8a8dabf2dd68 ("tty: handle the case where we cannot restore a line discipline") from the tty tree and commit: 1ab92da32e37 ("staging: speakup: add tty-based comms

Re: [PATCH v10 2/5] irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed

On Fri, 2017-06-02 at 18:29 -0700, Brendan Higgins wrote: > The Aspeed 24XX/25XX chips share a single hardware interrupt across 14 > separate I2C busses. This adds a dummy irqchip which maps the single > hardware interrupt to software interrupts for each of the busses. > > Signed-off-by: Brendan

Re: [PATCH v10 2/5] irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed

On Fri, 2017-06-02 at 18:29 -0700, Brendan Higgins wrote: > The Aspeed 24XX/25XX chips share a single hardware interrupt across 14 > separate I2C busses. This adds a dummy irqchip which maps the single > hardware interrupt to software interrupts for each of the busses. > > Signed-off-by: Brendan

[patch] tty: fix port buffer locking V2

This is just in case.  While it works, I consider it to be diagnostic data for those unfortunate enough to be intimate with tty locking :) --- V1 (925bb1ce47f4) changelog: tty_insert_flip_string_fixed_flag() is racy against itself when called from the ioctl(TCXONC, TCION/TCIOFF) path [1] and the

[patch] tty: fix port buffer locking V2

This is just in case.  While it works, I consider it to be diagnostic data for those unfortunate enough to be intimate with tty locking :) --- V1 (925bb1ce47f4) changelog: tty_insert_flip_string_fixed_flag() is racy against itself when called from the ioctl(TCXONC, TCION/TCIOFF) path [1] and the

Re: [PATCH v2] devlink: fix potential memort leak

Mon, Jun 05, 2017 at 02:57:21AM CEST, yanhaishu...@cmss.chinamobile.com wrote: >We must free allocated skb when genlmsg_put() return fails. > >Fixes: 1555d204e743 ("devlink: Support for pipeline debug (dpipe)") >Signed-off-by: Haishuang Yan Acked-by: Jiri Pirko

Re: [PATCH v2] devlink: fix potential memort leak

Mon, Jun 05, 2017 at 02:57:21AM CEST, yanhaishu...@cmss.chinamobile.com wrote: >We must free allocated skb when genlmsg_put() return fails. > >Fixes: 1555d204e743 ("devlink: Support for pipeline debug (dpipe)") >Signed-off-by: Haishuang Yan Acked-by: Jiri Pirko Thanks.

Re: [PATCH 5/7] USB: of: fix root-hub device-tree node handling

On Tue, May 30, 2017 at 06:25:52PM +0200, Johan Hovold wrote: > In an attempt to work around a pinmux over-allocation issue in driver > core, commit dc5878abf49c ("usb: core: move root hub's device node > assignment after it is added to bus") moved the device-tree node > assignment until after the

Re: [PATCH 5/7] USB: of: fix root-hub device-tree node handling

On Tue, May 30, 2017 at 06:25:52PM +0200, Johan Hovold wrote: > In an attempt to work around a pinmux over-allocation issue in driver > core, commit dc5878abf49c ("usb: core: move root hub's device node > assignment after it is added to bus") moved the device-tree node > assignment until after the

Re: [PATCH] net: sched: fix mips build failure

Sun, Jun 04, 2017 at 11:44:13PM CEST, sudipm.mukher...@gmail.com wrote: >The build of mips ar7_defconfig was failing with the error: >../net/sched/act_api.c: In function 'tcf_action_goto_chain_init': >../net/sched/act_api.c:37:18: error: > implicit declaration of function 'tcf_chain_get' >

Re: [PATCH] net: sched: fix mips build failure

Sun, Jun 04, 2017 at 11:44:13PM CEST, sudipm.mukher...@gmail.com wrote: >The build of mips ar7_defconfig was failing with the error: >../net/sched/act_api.c: In function 'tcf_action_goto_chain_init': >../net/sched/act_api.c:37:18: error: > implicit declaration of function 'tcf_chain_get' >

Re: [PATCH V7 0/2] PM / Domains: Power domain performance states

On 17-05-17, 12:32, Viresh Kumar wrote: > Hi, > > Here is the 7th version of the series and it looks very different from > whatever is sent until now. Almost a rewrite. Gentle reminder as 3 weeks have passed since this was last posted :) @Kevin/Ulf: Any inputs ? -- viresh

Re: [PATCH V7 0/2] PM / Domains: Power domain performance states

On 17-05-17, 12:32, Viresh Kumar wrote: > Hi, > > Here is the 7th version of the series and it looks very different from > whatever is sent until now. Almost a rewrite. Gentle reminder as 3 weeks have passed since this was last posted :) @Kevin/Ulf: Any inputs ? -- viresh

Re: [PATCH v10 3/5] i2c: aspeed: added documentation for Aspeed I2C driver

On Sat, Jun 3, 2017 at 10:59 AM, Brendan Higgins wrote: > Added device tree binding documentation for Aspeed I2C busses. > > Signed-off-by: Brendan Higgins > Acked-by: Rob Herring Acked-by: Joel Stanley

Re: [PATCH v10 3/5] i2c: aspeed: added documentation for Aspeed I2C driver

On Sat, Jun 3, 2017 at 10:59 AM, Brendan Higgins wrote: > Added device tree binding documentation for Aspeed I2C busses. > > Signed-off-by: Brendan Higgins > Acked-by: Rob Herring Acked-by: Joel Stanley

Re: [PATCH v10 4/5] i2c: aspeed: added driver for Aspeed I2C

On Sat, Jun 3, 2017 at 10:59 AM, Brendan Higgins wrote: > Added initial master support for Aspeed I2C controller. Supports > fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed. > > Signed-off-by: Brendan Higgins Reviewed-by:

Re: [PATCH v10 4/5] i2c: aspeed: added driver for Aspeed I2C

On Sat, Jun 3, 2017 at 10:59 AM, Brendan Higgins wrote: > Added initial master support for Aspeed I2C controller. Supports > fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed. > > Signed-off-by: Brendan Higgins Reviewed-by: Joel Stanley I have also tested this on an

[PATCH 1/2] ARM: sunxi: h3-h5: Convert R_CCU raw numbers to macros

Now that the R_CCU device tree binding headers have been merged, we can convert the raw number references in the device trees to use the defined macros. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sunxi-h3-h5.dtsi | 8 +--- 1 file changed, 5 insertions(+), 3

[PATCH 2/2] arm64: allwinner: a64: Convert CCU raw number references to macros

The A64 device tree file has some remnants of raw number references to the CCU node, likely from when the CCU bindings and device tree changes were first merged. Convert these, and the R_CCU ones, to use the proper defined macros from their respective device tree binding header files.

[PATCH 0/2] ARM/arm64: sunxi: convert CCU raw numbers to macros

Hi Maxime, These are some clean up patches for 4.12. They convert raw number references for the CCU and R_CCU nodes, from when the CCU/R_CCU stuff was first added, to the defined macros in the device tree header files. These affect the A64 and H3/H5. These are based on our sunxi/fixes-for-4.12

[PATCH 2/2] arm64: allwinner: a64: Convert CCU raw number references to macros

The A64 device tree file has some remnants of raw number references to the CCU node, likely from when the CCU bindings and device tree changes were first merged. Convert these, and the R_CCU ones, to use the proper defined macros from their respective device tree binding header files.

[PATCH 0/2] ARM/arm64: sunxi: convert CCU raw numbers to macros

Hi Maxime, These are some clean up patches for 4.12. They convert raw number references for the CCU and R_CCU nodes, from when the CCU/R_CCU stuff was first added, to the defined macros in the device tree header files. These affect the A64 and H3/H5. These are based on our sunxi/fixes-for-4.12

[PATCH 1/2] ARM: sunxi: h3-h5: Convert R_CCU raw numbers to macros

Now that the R_CCU device tree binding headers have been merged, we can convert the raw number references in the device trees to use the defined macros. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sunxi-h3-h5.dtsi | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git

RE: [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events

Hi, Benjamin > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > Subject: [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events > > The input stack already filters out the LID events. So instead of > filtering them out at the source, we can hook up after the input >

RE: [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events

Hi, Benjamin > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > Subject: [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events > > The input stack already filters out the LID events. So instead of > filtering them out at the source, we can hook up after the input >

Re: [PATCH] kvm: async_pf: fix rcu_irq_enter() with irqs enabled

2017-04-26 22:56 GMT+08:00 Paolo Bonzini : > native_safe_halt enables interrupts, and you just shouldn't > call rcu_irq_enter() with interrupts enabled. Reorder the > call with the following local_irq_disable() to respect the > invariant. > > Reported-by: Ross Zwisler

Re: [PATCH] kvm: async_pf: fix rcu_irq_enter() with irqs enabled

2017-04-26 22:56 GMT+08:00 Paolo Bonzini : > native_safe_halt enables interrupts, and you just shouldn't > call rcu_irq_enter() with interrupts enabled. Reorder the > call with the following local_irq_disable() to respect the > invariant. > > Reported-by: Ross Zwisler > Cc:

[PATCH] cachefiles: Fix a sleep-in-atomic bug in cachefiles_printk_object

The driver may sleep under a write spin lock, and the function call path is: cachefiles_mark_object_active (acquire the lock by write_lock) cachefiles_printk_object kmalloc(GFP_NOIO) --> may sleep cachefiles_mark_object_buried (acquire the lock by write_lock) cachefiles_printk_object

[PATCH] cachefiles: Fix a sleep-in-atomic bug in cachefiles_printk_object

The driver may sleep under a write spin lock, and the function call path is: cachefiles_mark_object_active (acquire the lock by write_lock) cachefiles_printk_object kmalloc(GFP_NOIO) --> may sleep cachefiles_mark_object_buried (acquire the lock by write_lock) cachefiles_printk_object

Cgroup hung system with rt patch, tested under 4.4.32/4.4.66/4.9.30

Hi RT Devs, I enabled cpu/cpuacct/cpuset/devices/freezer subsystems in cgroup. Attach serveral thread ids to these systems' tasks file frequently last 4 or 5 hours(start process, echo thread ids to tasks, stop process). The system will hung, no response to user keyboard input. Through I have

Cgroup hung system with rt patch, tested under 4.4.32/4.4.66/4.9.30

Hi RT Devs, I enabled cpu/cpuacct/cpuset/devices/freezer subsystems in cgroup. Attach serveral thread ids to these systems' tasks file frequently last 4 or 5 hours(start process, echo thread ids to tasks, stop process). The system will hung, no response to user keyboard input. Through I have

[PATCH 1/2] ARM: dts: uniphier: use SPDX-License-Identifier

Follow the recent trend for the license description, and fix the wrongly stated X11 to MIT. The X11 license text [1] is explicitly for the X Consortium and has a couple of extra clauses. The MIT license text [2] is actually what the current DT files claim. [1] https://spdx.org/licenses/X11.html

[PATCH 1/2] ARM: dts: uniphier: use SPDX-License-Identifier

Follow the recent trend for the license description, and fix the wrongly stated X11 to MIT. The X11 license text [1] is explicitly for the X Consortium and has a couple of extra clauses. The MIT license text [2] is actually what the current DT files claim. [1] https://spdx.org/licenses/X11.html

[PATCH 2/2] arm64: dts: uniphier: use SPDX-License-Identifier

Follow the recent trend for the license description, and fix the wrongly stated X11 to MIT. The X11 license text [1] is explicitly for the X Consortium and has a couple of extra clauses. The MIT license text [2] is actually what the current DT files claim. [1] https://spdx.org/licenses/X11.html

[PATCH 2/2] arm64: dts: uniphier: use SPDX-License-Identifier

Follow the recent trend for the license description, and fix the wrongly stated X11 to MIT. The X11 license text [1] is explicitly for the X Consortium and has a couple of extra clauses. The MIT license text [2] is actually what the current DT files claim. [1] https://spdx.org/licenses/X11.html

Re: [PATCH] nvmem: rockchip-efuse: add support for rk322x-efuse

Hi Finley, On 2017/5/12 10:44, Finley Xiao wrote: This adds the necessary data for handling eFuse on the rk322x. Signed-off-by: Finley Xiao --- Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt | 1 + drivers/nvmem/rockchip-efuse.c

Re: [PATCH] nvmem: rockchip-efuse: add support for rk322x-efuse

Hi Finley, On 2017/5/12 10:44, Finley Xiao wrote: This adds the necessary data for handling eFuse on the rk322x. Signed-off-by: Finley Xiao --- Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt | 1 + drivers/nvmem/rockchip-efuse.c | 4 2 files

[PATCH RFC v2 2/8] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

These functions are simple convenience wrappers that call wait_for_random_bytes before calling the respective get_random_* function. Signed-off-by: Jason A. Donenfeld --- include/linux/net.h| 2 ++ include/linux/once.h | 2 ++ include/linux/random.h | 25

[PATCH RFC v2 2/8] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

These functions are simple convenience wrappers that call wait_for_random_bytes before calling the respective get_random_* function. Signed-off-by: Jason A. Donenfeld --- include/linux/net.h| 2 ++ include/linux/once.h | 2 ++ include/linux/random.h | 25 + 3

[PATCH RFC v2 5/8] security/keys: ensure RNG is seeded before use

Otherwise, we might use bad random numbers which, particularly in the case of IV generation, could be quite bad. It makes sense to use the synchronous API here, because we're always in process context (as the code is littered with GFP_KERNEL and the like). Signed-off-by: Jason A. Donenfeld

[PATCH RFC v2 5/8] security/keys: ensure RNG is seeded before use

Otherwise, we might use bad random numbers which, particularly in the case of IV generation, could be quite bad. It makes sense to use the synchronous API here, because we're always in process context (as the code is littered with GFP_KERNEL and the like). Signed-off-by: Jason A. Donenfeld Cc:

[PATCH RFC v2 8/8] ceph: ensure RNG is seeded before using

Ceph uses the RNG for various nonce generations, and it shouldn't accept using bad randomness. So, we wait for the RNG to be properly seeded. We do this by calling wait_for_random_bytes() in a function that is certainly called in process context, early on, so that all subsequent calls to

[PATCH RFC v2 8/8] ceph: ensure RNG is seeded before using

Ceph uses the RNG for various nonce generations, and it shouldn't accept using bad randomness. So, we wait for the RNG to be properly seeded. We do this by calling wait_for_random_bytes() in a function that is certainly called in process context, early on, so that all subsequent calls to

[PATCH RFC v2 6/8] iscsi: ensure RNG is seeded before use

It's not safe to use weak random data here, especially for the challenge response randomness. Since we're always in process context, it's safe to simply wait until we have enough randomness to carry out the authentication correctly. While we're at it, we clean up a small memleak during an error

[PATCH RFC v2 3/8] random: warn when kernel uses unseeded randomness

This enables an important dmesg notification about when drivers have used the crng without it being seeded first. Prior, these errors would occur silently, and so there hasn't been a great way of diagnosing these types of bugs for obscure setups. By adding this as a config option, we can leave it

[PATCH RFC v2 6/8] iscsi: ensure RNG is seeded before use

It's not safe to use weak random data here, especially for the challenge response randomness. Since we're always in process context, it's safe to simply wait until we have enough randomness to carry out the authentication correctly. While we're at it, we clean up a small memleak during an error

[PATCH RFC v2 3/8] random: warn when kernel uses unseeded randomness

This enables an important dmesg notification about when drivers have used the crng without it being seeded first. Prior, these errors would occur silently, and so there hasn't been a great way of diagnosing these types of bugs for obscure setups. By adding this as a config option, we can leave it

[PATCH RFC v2 7/8] bluetooth/smp: ensure RNG is properly seeded before ECDH use

This protocol uses lots of complex cryptography that relies on securely generated random numbers. Thus, it's important that the RNG is actually seeded before use. Fortuantely, it appears we're always operating in process context (there are many GFP_KERNEL allocations and other sleeping

[PATCH RFC v2 4/8] crypto/rng: ensure that the RNG is ready before using

Otherwise, we might be seeding the RNG using bad randomness, which is dangerous. Cc: Herbert Xu Signed-off-by: Jason A. Donenfeld --- crypto/rng.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/crypto/rng.c b/crypto/rng.c

[PATCH RFC v2 4/8] crypto/rng: ensure that the RNG is ready before using

Otherwise, we might be seeding the RNG using bad randomness, which is dangerous. Cc: Herbert Xu Signed-off-by: Jason A. Donenfeld --- crypto/rng.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/crypto/rng.c b/crypto/rng.c index f46dac5288b9..e042437e64b4 100644 ---

[PATCH RFC v2 7/8] bluetooth/smp: ensure RNG is properly seeded before ECDH use

This protocol uses lots of complex cryptography that relies on securely generated random numbers. Thus, it's important that the RNG is actually seeded before use. Fortuantely, it appears we're always operating in process context (there are many GFP_KERNEL allocations and other sleeping

[PATCH RFC v2 0/8] get_random_bytes_wait family of APIs

As discussed in [1], there is a problem with get_random_bytes being used before the RNG has actually been seeded. The solution for fixing this appears to be multi-pronged. One of those prongs involves adding a simple blocking API so that modules that use the RNG in process context can just sleep

[PATCH RFC v2 1/8] random: add synchronous API for the urandom pool

This enables users of get_random_{bytes,u32,u64,int,long} to wait until the pool is ready before using this function, in case they actually want to have reliable randomness. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 41

[PATCH RFC v2 0/8] get_random_bytes_wait family of APIs

As discussed in [1], there is a problem with get_random_bytes being used before the RNG has actually been seeded. The solution for fixing this appears to be multi-pronged. One of those prongs involves adding a simple blocking API so that modules that use the RNG in process context can just sleep

[PATCH RFC v2 1/8] random: add synchronous API for the urandom pool

This enables users of get_random_{bytes,u32,u64,int,long} to wait until the pool is ready before using this function, in case they actually want to have reliable randomness. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 41 +++--

[PATCH] ubifs: Fix a sleep-in-atomic bug in read_nnode

The driver may sleep under a spin lock, and the function call path is: ubifs_change_lp (acquire the lock by spin_lock) change_category ubifs_remove_from_cat remove_from_lpt_heap dbg_check_heap ubifs_lpt_lookup ubifs_get_pnode read_pnode

[PATCH] ubifs: Fix a sleep-in-atomic bug in read_nnode

The driver may sleep under a spin lock, and the function call path is: ubifs_change_lp (acquire the lock by spin_lock) change_category ubifs_remove_from_cat remove_from_lpt_heap dbg_check_heap ubifs_lpt_lookup ubifs_get_pnode read_pnode

[PATCH linux-next v3 3/4] ARM: dts: imx: change compatiblity for SPI controllers on imx53 later soc

for SPI controllers on imx53 and later SoCs, there is HW issue when work in slave mode, as new device type 'IMX53_ECSPI' has been added for these SPI controllers which is compatible with 'fsl,imx53-ecspi'. This patch updates DTS to make imx53 later SPI controller only be compatibile with

[PATCH linux-next v3 3/4] ARM: dts: imx: change compatiblity for SPI controllers on imx53 later soc

for SPI controllers on imx53 and later SoCs, there is HW issue when work in slave mode, as new device type 'IMX53_ECSPI' has been added for these SPI controllers which is compatible with 'fsl,imx53-ecspi'. This patch updates DTS to make imx53 later SPI controller only be compatibile with

[PATCH linux-next v3 1/4] spi: imx: introduce fifo_size and has_dmamode in spi_imx_devtype_data

Different ECSPI controller has different fifosize and DMA capability, instead of calling functions to identify these information by check devtype. add fifo_size and has_dmamode to spi_imx_devtype_data. so that these information can be directly accessed. Signed-off-by: Jiada Wang

[PATCH linux-next v3 1/4] spi: imx: introduce fifo_size and has_dmamode in spi_imx_devtype_data

Different ECSPI controller has different fifosize and DMA capability, instead of calling functions to identify these information by check devtype. add fifo_size and has_dmamode to spi_imx_devtype_data. so that these information can be directly accessed. Signed-off-by: Jiada Wang ---

[PATCH linux-next v3 0/4] i.MX ECSPI controller slave mode support

Changes in v3: * renamed several variables for for better readability * created spi_imx_pio_transfer_slave() for slave pio transfer * added fifo_size, has_dmamode and has_slavemode in spi_imx_devtype_data Changes in v2: * re-workd i.MX ECSPI controller slave mode support based on Geert's work

[PATCH linux-next v3 2/4] spi: imx: add selection for iMX53 and iMX6 controller

ECSPI contorller for iMX53 and iMX6 has few hardware issues comparing to iMX51. The change add possibility to detect which controller is used to apply possible workaround and limitations. Signed-off-by: Jiada Wang --- .../devicetree/bindings/spi/fsl-imx-cspi.txt |

  1   2   3   4   5   6   7   >