Re: [PATCH v2] dmaengine: imx-sdma: add missing structure description

On 04-07-18, 18:06, Robin Gong wrote: > Some member description or colons missing cause build warning with > 'W=1' as below: > > drivers/dma/imx-sdma.c:326: warning: Function parameter or member 'vd' not > described in 'sdma_desc' > drivers/dma/imx-sdma.c:326: warning: Function parameter or

Re: [PATCH v2] dmaengine: imx-sdma: add missing structure description

On 04-07-18, 18:06, Robin Gong wrote: > Some member description or colons missing cause build warning with > 'W=1' as below: > > drivers/dma/imx-sdma.c:326: warning: Function parameter or member 'vd' not > described in 'sdma_desc' > drivers/dma/imx-sdma.c:326: warning: Function parameter or

Re: [PATCHv3 08/12] atomics: switch to generated fallbacks

On Thu, Jul 05, 2018 at 07:23:06PM +0200, Peter Zijlstra wrote: > On Thu, Jul 05, 2018 at 05:40:49PM +0100, Mark Rutland wrote: > > > * The fallbacks are not expected to change very often, and are not > > affected by machine details or configuration options, so regenerating > > them for

[PATCH 4.14 37/61] md: use mddev_suspend/resume instead of ->quiesce()

4.14-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit 9e1cc0a54556a6c63dc0cfb7cd7d60d43337bba6 upstream. mddev_suspend() is a more general interface than calling ->quiesce() and is so more extensible. A future patch will make

[PATCH 4.14 36/61] md: move suspend_hi/lo handling into core md code

4.14-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit b3143b9a38d5039bcd1f2d1c94039651bfba8043 upstream. responding to ->suspend_lo and ->suspend_hi is similar to responding to ->suspended. It is best to wait in the common core

Re: [PATCHv3 08/12] atomics: switch to generated fallbacks

On Thu, Jul 05, 2018 at 07:23:06PM +0200, Peter Zijlstra wrote: > On Thu, Jul 05, 2018 at 05:40:49PM +0100, Mark Rutland wrote: > > > * The fallbacks are not expected to change very often, and are not > > affected by machine details or configuration options, so regenerating > > them for

[PATCH 4.14 37/61] md: use mddev_suspend/resume instead of ->quiesce()

4.14-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit 9e1cc0a54556a6c63dc0cfb7cd7d60d43337bba6 upstream. mddev_suspend() is a more general interface than calling ->quiesce() and is so more extensible. A future patch will make

[PATCH 4.14 36/61] md: move suspend_hi/lo handling into core md code

4.14-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit b3143b9a38d5039bcd1f2d1c94039651bfba8043 upstream. responding to ->suspend_lo and ->suspend_hi is similar to responding to ->suspended. It is best to wait in the common core

Re: [PATCH V2 18/19] clocksource: add C-SKY clocksource drivers

On Thu, Jul 05, 2018 at 11:23:36AM +0200, Daniel Lezcano wrote: > > So I still need "for_each_cpu(cpu, cpu_possible_mask)" to init every > > csky_to ... > > That is what is unclear for me. percpu or IRQF_PERCPU ? IRQF_PERCPU > Have a look at the commit 9995f4f184613fb02ee73092b03545520a72b104,

Re: [PATCH V2 18/19] clocksource: add C-SKY clocksource drivers

On Thu, Jul 05, 2018 at 11:23:36AM +0200, Daniel Lezcano wrote: > > So I still need "for_each_cpu(cpu, cpu_possible_mask)" to init every > > csky_to ... > > That is what is unclear for me. percpu or IRQF_PERCPU ? IRQF_PERCPU > Have a look at the commit 9995f4f184613fb02ee73092b03545520a72b104,

[PATCH 4.14 40/61] netfilter: dont set F_IFACE on ipv6 fib lookups

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Florian Westphal commit 47b7e7f82802dced3ac73658bf4b77584a63063f upstream. "fib" starts to behave strangely when an ipv6 default route is added - the FIB lookup returns a route using 'oif' in

[PATCH 4.14 40/61] netfilter: dont set F_IFACE on ipv6 fib lookups

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Florian Westphal commit 47b7e7f82802dced3ac73658bf4b77584a63063f upstream. "fib" starts to behave strangely when an ipv6 default route is added - the FIB lookup returns a route using 'oif' in

[PATCH 4.14 42/61] netfilter: nf_tables: use WARN_ON_ONCE instead of BUG_ON in nft_do_chain()

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Taehee Yoo commit adc972c5b88829d38ede08b1069718661c7330ae upstream. When depth of chain is bigger than NFT_JUMP_STACK_SIZE, the nft_do_chain crashes. But there is no need to crash hard here.

[PATCH 4.14 42/61] netfilter: nf_tables: use WARN_ON_ONCE instead of BUG_ON in nft_do_chain()

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Taehee Yoo commit adc972c5b88829d38ede08b1069718661c7330ae upstream. When depth of chain is bigger than NFT_JUMP_STACK_SIZE, the nft_do_chain crashes. But there is no need to crash hard here.

Re: [PATCH 03/11] cpufreq/schedutil: use rt utilization tracking

On 28-06-18, 17:45, Vincent Guittot wrote: > Add both cfs and rt utilization when selecting an OPP for cfs tasks as rt > can preempt and steal cfs's running time. > > rt util_avg is used to take into account the utilization of rt tasks > on the CPU when selecting OPP. If a rt task migrate, the rt

Re: [PATCH 03/11] cpufreq/schedutil: use rt utilization tracking

On 28-06-18, 17:45, Vincent Guittot wrote: > Add both cfs and rt utilization when selecting an OPP for cfs tasks as rt > can preempt and steal cfs's running time. > > rt util_avg is used to take into account the utilization of rt tasks > on the CPU when selecting OPP. If a rt task migrate, the rt

Re: [PATCH] dmaengine: nbpfaxi: Mark expected switch fall-through

On 02-07-18, 13:06, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/dma/nbpfaxi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCH] dmaengine: nbpfaxi: Mark expected switch fall-through

On 02-07-18, 13:06, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/dma/nbpfaxi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git

[PATCH 4.14 44/61] mtd: rawnand: fix return value check for bad block status

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Abhishek Sahu commit e9893e6fa932f42c90c4ac5849fa9aa0f0f00a34 upstream. Positive return value from read_oob() is making false BAD blocks. For some of the NAND controllers, OOB bytes will be

Re: [PATCH 4.14 14/61] vt: prevent leaking uninitialized data to userspace via /dev/vcs*

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Alexander Potapenko commit 21eff690e766ca0ce445b477698dc6a9f55a upstream. KMSAN reported an infoleak when reading from /dev/vcs*: BUG: KMSAN: kernel-infoleak in

[PATCH 4.14 44/61] mtd: rawnand: fix return value check for bad block status

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Abhishek Sahu commit e9893e6fa932f42c90c4ac5849fa9aa0f0f00a34 upstream. Positive return value from read_oob() is making false BAD blocks. For some of the NAND controllers, OOB bytes will be

Re: [PATCH 4.14 14/61] vt: prevent leaking uninitialized data to userspace via /dev/vcs*

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Alexander Potapenko commit 21eff690e766ca0ce445b477698dc6a9f55a upstream. KMSAN reported an infoleak when reading from /dev/vcs*: BUG: KMSAN: kernel-infoleak in

[PATCH 4.14 46/61] afs: Fix directory permissions check

4.14-stable review patch. If anyone has any objections, please let me know. -- From: David Howells [ Upstream commit 378831e4daec75fbba6d3612bcf3b4dd00ddbf08 ] Doing faccessat("/afs/some/directory", 0) triggers a BUG in the permissions check code. Fix this by just removing

[PATCH 4.14 46/61] afs: Fix directory permissions check

4.14-stable review patch. If anyone has any objections, please let me know. -- From: David Howells [ Upstream commit 378831e4daec75fbba6d3612bcf3b4dd00ddbf08 ] Doing faccessat("/afs/some/directory", 0) triggers a BUG in the permissions check code. Fix this by just removing

[PATCH 4.14 48/61] s390/dasd: use blk_mq_rq_from_pdu for per request data

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Ott [ Upstream commit f0f59a2fab8e52b9d582b39da39f22230ca80aee ] Dasd uses completion_data from struct request to store per request private data - this is problematic since this

[PATCH 4.14 48/61] s390/dasd: use blk_mq_rq_from_pdu for per request data

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Ott [ Upstream commit f0f59a2fab8e52b9d582b39da39f22230ca80aee ] Dasd uses completion_data from struct request to store per request private data - this is problematic since this

[PATCH 4.14 49/61] netfilter: nft_limit: fix packet ratelimiting

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Pablo Neira Ayuso [ Upstream commit 3e0f64b7dd3149f75e8652ff1df56cffeedc8fc1 ] Credit calculations for the packet ratelimiting are not correct, as per the applied ratelimit of 25/second and

[PATCH 4.14 49/61] netfilter: nft_limit: fix packet ratelimiting

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Pablo Neira Ayuso [ Upstream commit 3e0f64b7dd3149f75e8652ff1df56cffeedc8fc1 ] Credit calculations for the packet ratelimiting are not correct, as per the applied ratelimit of 25/second and

[PATCH 4.14 50/61] ipvs: fix buffer overflow with sync daemon and service

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Julian Anastasov [ Upstream commit 52f96757905bbf0edef47f3ee6c7c784e7f8ff8a ] syzkaller reports for buffer overflow for interface name when starting sync daemons [1] What we do is that we

[PATCH 4.14 55/61] perf bpf: Fix NULL return handling in bpf__prepare_load()

4.14-stable review patch. If anyone has any objections, please let me know. -- From: YueHaibing [ Upstream commit ab4e32ff5aa797eaea551dbb67946e2fcb56cc7e ] bpf_object__open()/bpf_object__open_buffer can return error pointer or NULL, check the return values with

[PATCH 4.14 50/61] ipvs: fix buffer overflow with sync daemon and service

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Julian Anastasov [ Upstream commit 52f96757905bbf0edef47f3ee6c7c784e7f8ff8a ] syzkaller reports for buffer overflow for interface name when starting sync daemons [1] What we do is that we

[PATCH 4.14 55/61] perf bpf: Fix NULL return handling in bpf__prepare_load()

4.14-stable review patch. If anyone has any objections, please let me know. -- From: YueHaibing [ Upstream commit ab4e32ff5aa797eaea551dbb67946e2fcb56cc7e ] bpf_object__open()/bpf_object__open_buffer can return error pointer or NULL, check the return values with

[PATCH 4.14 56/61] fs: clear writeback errors in inode_init_always

4.14-stable review patch. If anyone has any objections, please let me know. -- From: "Darrick J. Wong" [ Upstream commit 829bc787c1a0403e4d886296dd4d90c5f9c1744a ] In inode_init_always(), we clear the inode mapping flags, which clears any retained error (AS_EIO, AS_ENOSPC)

[PATCH 4.14 52/61] atm: zatm: fix memcmp casting

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Ivan Bornyakov [ Upstream commit f9c6442a8f0b1dde9e755eb4ff6fa22bcce4eabc ] memcmp() returns int, but eprom_try_esi() cast it to unsigned char. One can lose significant bits and get 0 from

[PATCH 4.14 54/61] perf test: "Session topology" dumps core on s390

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Richter [ Upstream commit d121109100bda84199dab97f9d56432ab235 ] The "perf test Session topology" entry fails with core dump on s390. The root cause is a NULL pointer dereference

[PATCH 4.14 52/61] atm: zatm: fix memcmp casting

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Ivan Bornyakov [ Upstream commit f9c6442a8f0b1dde9e755eb4ff6fa22bcce4eabc ] memcmp() returns int, but eprom_try_esi() cast it to unsigned char. One can lose significant bits and get 0 from

[PATCH 4.14 56/61] fs: clear writeback errors in inode_init_always

4.14-stable review patch. If anyone has any objections, please let me know. -- From: "Darrick J. Wong" [ Upstream commit 829bc787c1a0403e4d886296dd4d90c5f9c1744a ] In inode_init_always(), we clear the inode mapping flags, which clears any retained error (AS_EIO, AS_ENOSPC)

[PATCH 4.14 54/61] perf test: "Session topology" dumps core on s390

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Richter [ Upstream commit d121109100bda84199dab97f9d56432ab235 ] The "perf test Session topology" entry fails with core dump on s390. The root cause is a NULL pointer dereference

[PATCH 4.14 51/61] iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Hao Wei Tee [ Upstream commit ab1068d6866e28bf6427ceaea681a381e5870a4a ] When there are 16 or more logical CPUs, we request for `IWL_MAX_RX_HW_QUEUES` (16) IRQs only as we limit to that

[PATCH 4.14 47/61] netfilter: ebtables: handle string from userspace with care

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Paolo Abeni [ Upstream commit 94c752f99954797da583a84c4907ff19e92550a4 ] strlcpy() can't be safely used on a user-space provided string, as it can try to read beyond the buffer's end, if the

[PATCH 4.14 51/61] iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Hao Wei Tee [ Upstream commit ab1068d6866e28bf6427ceaea681a381e5870a4a ] When there are 16 or more logical CPUs, we request for `IWL_MAX_RX_HW_QUEUES` (16) IRQs only as we limit to that

[PATCH 4.14 47/61] netfilter: ebtables: handle string from userspace with care

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Paolo Abeni [ Upstream commit 94c752f99954797da583a84c4907ff19e92550a4 ] strlcpy() can't be safely used on a user-space provided string, as it can try to read beyond the buffer's end, if the

Re: [PATCH] checkpatch: Add exceptions for dsb keyword usage

On Fri, 2018-07-06 at 06:45 +0100, Mark Rutland wrote: > On Thu, Jul 05, 2018 at 02:14:28PM -0700, Joe Perches wrote: > > On Thu, 2018-07-05 at 11:19 -0700, Prakruthi Deepak Heragu wrote: > > > mb() API can relpace the dsb() API in the kernel code. So, dsb() usage > > > is discouraged. However,

Re: [PATCH] checkpatch: Add exceptions for dsb keyword usage

On Fri, 2018-07-06 at 06:45 +0100, Mark Rutland wrote: > On Thu, Jul 05, 2018 at 02:14:28PM -0700, Joe Perches wrote: > > On Thu, 2018-07-05 at 11:19 -0700, Prakruthi Deepak Heragu wrote: > > > mb() API can relpace the dsb() API in the kernel code. So, dsb() usage > > > is discouraged. However,

[PATCH 4.14 58/61] sched/core: Require cpu_active() in select_task_rq(), for user tasks

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Paul Burton [ Upstream commit 7af443ee1697607541c6346c87385adab2214743 ] select_task_rq() is used in a few paths to select the CPU upon which a thread should be run - for example it is used

[PATCH 4.14 57/61] sched/core: Fix rules for running on online && !active CPUs

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Peter Zijlstra [ Upstream commit 175f0e25abeaa2218d431141ce19cf1de70fa82d ] As already enforced by the WARN() in __set_cpus_allowed_ptr(), the rules for running on an online && !active CPU

[PATCH 4.14 58/61] sched/core: Require cpu_active() in select_task_rq(), for user tasks

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Paul Burton [ Upstream commit 7af443ee1697607541c6346c87385adab2214743 ] select_task_rq() is used in a few paths to select the CPU upon which a thread should be run - for example it is used

[PATCH 4.14 57/61] sched/core: Fix rules for running on online && !active CPUs

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Peter Zijlstra [ Upstream commit 175f0e25abeaa2218d431141ce19cf1de70fa82d ] As already enforced by the WARN() in __set_cpus_allowed_ptr(), the rules for running on an online && !active CPU

[PATCH 4.14 60/61] net/sonic: Use dma_mapping_error()

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Finn Thain [ Upstream commit 26de0b76d9ba3200f09c6cb9d9618bda338be5f7 ] With CONFIG_DMA_API_DEBUG=y, calling sonic_open() produces the message, "DMA-API: device driver failed to check map

[PATCH 4.14 60/61] net/sonic: Use dma_mapping_error()

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Finn Thain [ Upstream commit 26de0b76d9ba3200f09c6cb9d9618bda338be5f7 ] With CONFIG_DMA_API_DEBUG=y, calling sonic_open() produces the message, "DMA-API: device driver failed to check map

[PATCH 4.14 13/61] serdev: fix memleak on module unload

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Johan Hovold commit bc6cf3669d22371f573ab0305b3abf13887c0786 upstream. Make sure to free all resources associated with the ida on module exit. Fixes: cd6484e1830b ("serdev: Introduce new bus

[PATCH 4.14 14/61] vt: prevent leaking uninitialized data to userspace via /dev/vcs*

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Alexander Potapenko commit 21eff690e766ca0ce445b477698dc6a9f55a upstream. KMSAN reported an infoleak when reading from /dev/vcs*: BUG: KMSAN: kernel-infoleak in vcs_read+0x18ba/0x1cc0

[PATCH 4.14 08/61] xhci: Fix kernel oops in trace_xhci_free_virt_device

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Zhengjun Xing commit d850c1658328e757635a46763783c6fd56390dcb upstream. commit 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device") set dev->udev pointer to NULL in

[PATCH 4.14 12/61] serial: 8250_pci: Remove stalled entries in blacklist

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Andy Shevchenko commit 20dcff436e9fcd2e106b0ccc48a52206bc176d70 upstream. After the commit 7d8905d06405 ("serial: 8250_pci: Enable device after we check black list") pure serial

[PATCH 4.14 13/61] serdev: fix memleak on module unload

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Johan Hovold commit bc6cf3669d22371f573ab0305b3abf13887c0786 upstream. Make sure to free all resources associated with the ida on module exit. Fixes: cd6484e1830b ("serdev: Introduce new bus

[PATCH 4.14 14/61] vt: prevent leaking uninitialized data to userspace via /dev/vcs*

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Alexander Potapenko commit 21eff690e766ca0ce445b477698dc6a9f55a upstream. KMSAN reported an infoleak when reading from /dev/vcs*: BUG: KMSAN: kernel-infoleak in vcs_read+0x18ba/0x1cc0

[PATCH 4.14 08/61] xhci: Fix kernel oops in trace_xhci_free_virt_device

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Zhengjun Xing commit d850c1658328e757635a46763783c6fd56390dcb upstream. commit 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device") set dev->udev pointer to NULL in

[PATCH 4.14 12/61] serial: 8250_pci: Remove stalled entries in blacklist

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Andy Shevchenko commit 20dcff436e9fcd2e106b0ccc48a52206bc176d70 upstream. After the commit 7d8905d06405 ("serial: 8250_pci: Enable device after we check black list") pure serial

[PATCH 4.14 38/61] md: allow metadata update while suspending.

4.14-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit 35bfc52187f6df8779d0f1cebdb52b7f797baf4e upstream. There are various deadlocks that can occur when a thread holds reconfig_mutex and calls ->quiesce(mddev, 1). As some write

[PATCH 4.14 39/61] md: remove special meaning of ->quiesce(.., 2)

4.14-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit b03e0ccb5ab9df3efbe51c87843a1ffbecbafa1f upstream. The '2' argument means "wake up anything that is waiting". This is an inelegant part of the design and was added to help

[PATCH 4.14 43/61] ARM: dts: imx6q: Use correct SDMA script for SPI5 core

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Sean Nyekjaer commit df07101e1c4a29e820df02f9989a066988b160e6 upstream. According to the reference manual the shp_2_mcu / mcu_2_shp scripts must be used for devices connected through the

[PATCH 4.14 41/61] netfilter: ip6t_rpfilter: provide input interface for route lookup

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Vincent Bernat commit cede24d1b21d68d84ac5a36c44f7d37daadcc258 upstream. In commit 47b7e7f82802, this bit was removed at the same time the RT6_LOOKUP_F_IFACE flag was removed. However, it is

[PATCH 4.14 39/61] md: remove special meaning of ->quiesce(.., 2)

4.14-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit b03e0ccb5ab9df3efbe51c87843a1ffbecbafa1f upstream. The '2' argument means "wake up anything that is waiting". This is an inelegant part of the design and was added to help

[PATCH 4.14 43/61] ARM: dts: imx6q: Use correct SDMA script for SPI5 core

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Sean Nyekjaer commit df07101e1c4a29e820df02f9989a066988b160e6 upstream. According to the reference manual the shp_2_mcu / mcu_2_shp scripts must be used for devices connected through the

[PATCH 4.14 41/61] netfilter: ip6t_rpfilter: provide input interface for route lookup

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Vincent Bernat commit cede24d1b21d68d84ac5a36c44f7d37daadcc258 upstream. In commit 47b7e7f82802, this bit was removed at the same time the RT6_LOOKUP_F_IFACE flag was removed. However, it is

[PATCH 4.14 38/61] md: allow metadata update while suspending.

4.14-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit 35bfc52187f6df8779d0f1cebdb52b7f797baf4e upstream. There are various deadlocks that can occur when a thread holds reconfig_mutex and calls ->quiesce(mddev, 1). As some write

[PATCH 4.14 11/61] staging: android: ion: Return an ERR_PTR in ion_map_kernel

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Laura Abbott commit 0a2bc00341dcfcc793c0dbf4f8d43adf60458b05 upstream. The expected return value from ion_map_kernel is an ERR_PTR. The error path for a vmalloc failure currently just returns

[PATCH 4.14 11/61] staging: android: ion: Return an ERR_PTR in ion_map_kernel

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Laura Abbott commit 0a2bc00341dcfcc793c0dbf4f8d43adf60458b05 upstream. The expected return value from ion_map_kernel is an ERR_PTR. The error path for a vmalloc failure currently just returns

[PATCH 4.14 35/61] md: dont call bitmap_create() while array is quiesced.

4.14-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit 52a0d49de3d592a3118e13f35985e3d99eaf43df upstream. bitmap_create() allocates memory with GFP_KERNEL and so can wait for IO. If called while the array is quiesced, it could

[PATCH 4.14 35/61] md: dont call bitmap_create() while array is quiesced.

4.14-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit 52a0d49de3d592a3118e13f35985e3d99eaf43df upstream. bitmap_create() allocates memory with GFP_KERNEL and so can wait for IO. If called while the array is quiesced, it could

[PATCH 4.14 31/61] netfilter: nf_tables: fix memory leak on error exit return

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Colin Ian King commit f0dfd7a2b35b02030949100247d851b793cb275f upstream. Currently the -EBUSY error return path is not free'ing resources allocated earlier, leaving a memory leak. Fix this by

[PATCH 4.14 28/61] netfilter: nft_meta: fix wrong value dereference in nft_meta_set_eval

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Taehee Yoo commit 97a0549b15a0b466c47f6a0143a490a082c64b4e upstream. In the nft_meta_set_eval, nftrace value is dereferenced as u32 from sreg. But correct type is u8. so that sometimes

[PATCH 4.14 31/61] netfilter: nf_tables: fix memory leak on error exit return

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Colin Ian King commit f0dfd7a2b35b02030949100247d851b793cb275f upstream. Currently the -EBUSY error return path is not free'ing resources allocated earlier, leaving a memory leak. Fix this by

[PATCH 4.14 28/61] netfilter: nft_meta: fix wrong value dereference in nft_meta_set_eval

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Taehee Yoo commit 97a0549b15a0b466c47f6a0143a490a082c64b4e upstream. In the nft_meta_set_eval, nftrace value is dereferenced as u32 from sreg. But correct type is u8. so that sometimes

[PATCH 4.14 25/61] netfilter: nft_compat: fix handling of large matchinfo size

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Florian Westphal commit 732a8049f365f514d0607e03938491bf6cb0d620 upstream. currently matchinfo gets stored in the expression, but some xt matches are very large. To handle those we either

[PATCH 4.14 24/61] netfilter: nft_compat: prepare for indirect info storage

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Florian Westphal commit 8bdf164744b2c7f63561846c01cff3db597f282d upstream. Next patch will make it possible for *info to be stored in a separate allocation instead of the expr private area.

[PATCH 4.14 25/61] netfilter: nft_compat: fix handling of large matchinfo size

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Florian Westphal commit 732a8049f365f514d0607e03938491bf6cb0d620 upstream. currently matchinfo gets stored in the expression, but some xt matches are very large. To handle those we either

[PATCH 4.14 24/61] netfilter: nft_compat: prepare for indirect info storage

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Florian Westphal commit 8bdf164744b2c7f63561846c01cff3db597f282d upstream. Next patch will make it possible for *info to be stored in a separate allocation instead of the expr private area.

[PATCH 4.14 22/61] drm/i915: Enable provoking vertex fix on Gen9 systems.

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Kenneth Graunke commit 7a3727f385dc64773db1c144f6b15c1e9d4735bb upstream. The SF and clipper units mishandle the provoking vertex in some cases, which can cause misrendering with shaders that

[PATCH 4.14 22/61] drm/i915: Enable provoking vertex fix on Gen9 systems.

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Kenneth Graunke commit 7a3727f385dc64773db1c144f6b15c1e9d4735bb upstream. The SF and clipper units mishandle the provoking vertex in some cases, which can cause misrendering with shaders that

[PATCH 4.14 18/61] drm/qxl: Call qxl_bo_unref outside atomic context

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Jeremy Cline commit 889ad63d41eea20184b0483e7e585e5b20fb6cfe upstream. "qxl_bo_unref" may sleep, but calling "qxl_release_map" causes "preempt_disable()" to be called and "preempt_enable()"

[PATCH 4.14 18/61] drm/qxl: Call qxl_bo_unref outside atomic context

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Jeremy Cline commit 889ad63d41eea20184b0483e7e585e5b20fb6cfe upstream. "qxl_bo_unref" may sleep, but calling "qxl_release_map" causes "preempt_disable()" to be called and "preempt_enable()"

[PATCH 4.14 02/61] USB: serial: cp210x: add CESINEL device ids

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Johan Hovold commit 24160628a34af962ac99f2f58e547ac3c4cbd26f upstream. Add device ids for CESINEL products. Reported-by: Carlos Barcala Lara Cc: stable Signed-off-by: Johan Hovold

[PATCH 4.14 02/61] USB: serial: cp210x: add CESINEL device ids

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Johan Hovold commit 24160628a34af962ac99f2f58e547ac3c4cbd26f upstream. Add device ids for CESINEL products. Reported-by: Carlos Barcala Lara Cc: stable Signed-off-by: Johan Hovold

[PATCH 4.14 04/61] usb: dwc2: fix the incorrect bitmaps for the ports of multi_tt hub

4.14-stable review patch. If anyone has any objections, please let me know. -- From: William Wu commit 8760675932ddb614e83702117d36ea644050c609 upstream. The dwc2_get_ls_map() use ttport to reference into the bitmap if we're on a multi_tt hub. But the bitmaps index from 0 to

[PATCH 4.14 00/61] 4.14.54-stable review

This is the start of the stable review cycle for the 4.14.54 release. There are 61 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Jul 8 05:46:58 UTC 2018. Anything

[PATCH 4.17 46/46] ARM: dts: imx6q: Use correct SDMA script for SPI5 core

4.17-stable review patch. If anyone has any objections, please let me know. -- From: Sean Nyekjaer commit df07101e1c4a29e820df02f9989a066988b160e6 upstream. According to the reference manual the shp_2_mcu / mcu_2_shp scripts must be used for devices connected through the

[PATCH 4.17 43/46] netfilter: nf_tables: use WARN_ON_ONCE instead of BUG_ON in nft_do_chain()

4.17-stable review patch. If anyone has any objections, please let me know. -- From: Taehee Yoo commit adc972c5b88829d38ede08b1069718661c7330ae upstream. When depth of chain is bigger than NFT_JUMP_STACK_SIZE, the nft_do_chain crashes. But there is no need to crash hard here.

[PATCH 4.14 03/61] USB: serial: cp210x: add Silicon Labs IDs for Windows Update

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Karoly Pados commit 2f839823382748664b643daa73f41ee0cc01ced6 upstream. Silicon Labs defines alternative VID/PID pairs for some chips that when used will automatically install drivers for

[PATCH 4.14 07/61] usb: typec: ucsi: Fix for incorrect status data issue

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Heikki Krogerus commit 68816e16b4789f2d05e77b6dcb77564cf5d6a8d8 upstream. According to UCSI Specification, Connector Change Event only means a change in the Connector Status and Operation

[PATCH 4.14 06/61] usb: typec: ucsi: acpi: Workaround for cache mode issue

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Heikki Krogerus commit 1f9f9d168ce619608572b01771c47a41b15429e6 upstream. This fixes an issue where the driver fails with an error: ioremap error for 0x3f799000-0x3f79a000, requested

[PATCH 4.14 07/61] usb: typec: ucsi: Fix for incorrect status data issue

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Heikki Krogerus commit 68816e16b4789f2d05e77b6dcb77564cf5d6a8d8 upstream. According to UCSI Specification, Connector Change Event only means a change in the Connector Status and Operation

[PATCH 4.14 06/61] usb: typec: ucsi: acpi: Workaround for cache mode issue

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Heikki Krogerus commit 1f9f9d168ce619608572b01771c47a41b15429e6 upstream. This fixes an issue where the driver fails with an error: ioremap error for 0x3f799000-0x3f79a000, requested

[PATCH 4.14 04/61] usb: dwc2: fix the incorrect bitmaps for the ports of multi_tt hub

4.14-stable review patch. If anyone has any objections, please let me know. -- From: William Wu commit 8760675932ddb614e83702117d36ea644050c609 upstream. The dwc2_get_ls_map() use ttport to reference into the bitmap if we're on a multi_tt hub. But the bitmaps index from 0 to

[PATCH 4.14 00/61] 4.14.54-stable review

This is the start of the stable review cycle for the 4.14.54 release. There are 61 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Jul 8 05:46:58 UTC 2018. Anything

[PATCH 4.17 46/46] ARM: dts: imx6q: Use correct SDMA script for SPI5 core

4.17-stable review patch. If anyone has any objections, please let me know. -- From: Sean Nyekjaer commit df07101e1c4a29e820df02f9989a066988b160e6 upstream. According to the reference manual the shp_2_mcu / mcu_2_shp scripts must be used for devices connected through the

[PATCH 4.17 43/46] netfilter: nf_tables: use WARN_ON_ONCE instead of BUG_ON in nft_do_chain()

4.17-stable review patch. If anyone has any objections, please let me know. -- From: Taehee Yoo commit adc972c5b88829d38ede08b1069718661c7330ae upstream. When depth of chain is bigger than NFT_JUMP_STACK_SIZE, the nft_do_chain crashes. But there is no need to crash hard here.

[PATCH 4.14 03/61] USB: serial: cp210x: add Silicon Labs IDs for Windows Update

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Karoly Pados commit 2f839823382748664b643daa73f41ee0cc01ced6 upstream. Silicon Labs defines alternative VID/PID pairs for some chips that when used will automatically install drivers for

[PATCH 4.17 44/46] ARM64: dts: meson-gxl-s905x-p212: Add phy-supply for usb0

4.17-stable review patch. If anyone has any objections, please let me know. -- From: Neil Armstrong commit d511b3e4087eedbe11c7496c396432b8b7c2d7d9 upstream. Like LibreTech-CC, the USB0 needs the 5V regulator to be enabled to power the devices on the P212 Reference Design

[PATCH 4.17 16/46] vt: prevent leaking uninitialized data to userspace via /dev/vcs*

4.17-stable review patch. If anyone has any objections, please let me know. -- From: Alexander Potapenko commit 21eff690e766ca0ce445b477698dc6a9f55a upstream. KMSAN reported an infoleak when reading from /dev/vcs*: BUG: KMSAN: kernel-infoleak in vcs_read+0x18ba/0x1cc0

  1   2   3   4   5   6   7   8   9   10   >