[PATCH 13/13] rcutorture: formal: prepare for ACCESS_ONCE() removal

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 11/13] selftests/powerpc: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 12/13] workqueue: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 12/13] workqueue: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 05/13] fs: ncpfs: kill off ACCESS_ONCE()

The NCPFS code has some stale comments regarding ACCESS_ONCE() uses which were removed a long time ago. Let's remove the stale comments. Signed-off-by: Mark Rutland Cc: Alexander Viro Cc: Petr Vandrovec --- fs/ncpfs/dir.c |

[PATCH 05/13] fs: ncpfs: kill off ACCESS_ONCE()

The NCPFS code has some stale comments regarding ACCESS_ONCE() uses which were removed a long time ago. Let's remove the stale comments. Signed-off-by: Mark Rutland Cc: Alexander Viro Cc: Petr Vandrovec --- fs/ncpfs/dir.c | 9 - 1 file changed, 9 deletions(-) diff --git

[PATCH 03/13] firmware/ivc: kill off ACCESS_ONCE()

workqueue: kill off ACCESS_ONCE() For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful.

[PATCH 03/13] firmware/ivc: kill off ACCESS_ONCE()

workqueue: kill off ACCESS_ONCE() For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful.

[PATCH 01/13] dm integrity: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 04/13] fs: dcache: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 01/13] dm integrity: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 04/13] fs: dcache: kill off ACCESS_ONCE()

For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently harmful. However, for some features it is

[PATCH 00/13] Preparatory work to kill off ACCESS_ONCE()

Hi all, There's a general want to kill off ACCESS_ONCE(), which is required to kill off smp_read_barrier_depends(), and to support debug features which require instrumenting reads and writes separately. Thanks to preparatory work by a number of people, it's largely possible to script this with

[PATCH 00/13] Preparatory work to kill off ACCESS_ONCE()

Hi all, There's a general want to kill off ACCESS_ONCE(), which is required to kill off smp_read_barrier_depends(), and to support debug features which require instrumenting reads and writes separately. Thanks to preparatory work by a number of people, it's largely possible to script this with

Re: [PATCH 1/3] backlight: tdo24m: fix the spi cs between transfers

Daniel Thompson writes: > On 06/10/17 20:58, Robert Jarzmik wrote: > > I'm a tiny bit worried about see-saw bug fixing here but nevertheless this > change looks correct to me. > > Mike's change was eight years ago and it is reasonable to hope that the patch > was

Re: [PATCH 1/3] backlight: tdo24m: fix the spi cs between transfers

Daniel Thompson writes: > On 06/10/17 20:58, Robert Jarzmik wrote: > > I'm a tiny bit worried about see-saw bug fixing here but nevertheless this > change looks correct to me. > > Mike's change was eight years ago and it is reasonable to hope that the patch > was really just working around a

Re: [PATCH] platform/x86: mlx-platform: make a couple of structures static

On Sat, Oct 07, 2017 at 05:03:41PM +0300, Andy Shevchenko wrote: > On Thu, Oct 5, 2017 at 1:42 PM, Colin King wrote: > > From: Colin Ian King > > > > The structures mlxplat_dev and mlxplat_hotplug are local to the source > > and do not need to

Re: [PATCH] platform/x86: mlx-platform: make a couple of structures static

On Sat, Oct 07, 2017 at 05:03:41PM +0300, Andy Shevchenko wrote: > On Thu, Oct 5, 2017 at 1:42 PM, Colin King wrote: > > From: Colin Ian King > > > > The structures mlxplat_dev and mlxplat_hotplug are local to the source > > and do not need to be in global scope, so make them static. > > > >

RE: [PATCH linux-firmware 2/3] WHENCE: Add new radeon firmware

> -Original Message- > From: Ben Hutchings [mailto:b...@decadent.org.uk] > Sent: Monday, October 09, 2017 1:18 PM > To: linux-kernel@vger.kernel.org; linux-firmw...@kernel.org > Cc: Deucher, Alexander > Subject: [PATCH linux-firmware 2/3] WHENCE: Add new radeon firmware > > Signed-off-by:

RE: [PATCH linux-firmware 2/3] WHENCE: Add new radeon firmware

> -Original Message- > From: Ben Hutchings [mailto:b...@decadent.org.uk] > Sent: Monday, October 09, 2017 1:18 PM > To: linux-kernel@vger.kernel.org; linux-firmw...@kernel.org > Cc: Deucher, Alexander > Subject: [PATCH linux-firmware 2/3] WHENCE: Add new radeon firmware > > Signed-off-by:

Re: usb/media/imon: null-ptr-deref in imon_probe

Hi Andrey, I have added NULL check for usb_ifnum_to_if() and send a patch. Please re-test it. ~arvind On Monday 09 October 2017 11:20 PM, Andrey Konovalov wrote: Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f

Re: usb/media/imon: null-ptr-deref in imon_probe

Hi Andrey, I have added NULL check for usb_ifnum_to_if() and send a patch. Please re-test it. ~arvind On Monday 09 October 2017 11:20 PM, Andrey Konovalov wrote: Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f

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

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c between commit: 866af46e6ebbc ("media: Staging: atomisp: fix alloc_cast.cocci warnings") from the media tree and commit: 4d962df5a7771

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

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c between commit: 866af46e6ebbc ("media: Staging: atomisp: fix alloc_cast.cocci warnings") from the media tree and commit: 4d962df5a7771

Re: [RFC] a question about mlockall() and mprotect()

On Wed 27-09-17 13:51:09, Xishi Qiu wrote: > On 2017/9/26 19:00, Michal Hocko wrote: > > > On Tue 26-09-17 11:45:16, Vlastimil Babka wrote: > >> On 09/26/2017 11:22 AM, Xishi Qiu wrote: > >>> On 2017/9/26 17:13, Xishi Qiu wrote: > > This is still very fuzzy. What are you actually trying to

Re: [RFC] a question about mlockall() and mprotect()

On Wed 27-09-17 13:51:09, Xishi Qiu wrote: > On 2017/9/26 19:00, Michal Hocko wrote: > > > On Tue 26-09-17 11:45:16, Vlastimil Babka wrote: > >> On 09/26/2017 11:22 AM, Xishi Qiu wrote: > >>> On 2017/9/26 17:13, Xishi Qiu wrote: > > This is still very fuzzy. What are you actually trying to

Re: [PATCH v2] ARC: reset: introduce AXS10x reset driver

On 10/04/2017 03:09 AM, Philipp Zabel wrote: Hi Vineet, On Mon, 2017-09-18 at 18:51 +0200, Philipp Zabel wrote: Will it be OK for you to apply the corresponding DT update for platform - that way I don't have to keep track of when ur branch hits mainline etc. The chances of any ensuing

Re: [PATCH v2] ARC: reset: introduce AXS10x reset driver

On 10/04/2017 03:09 AM, Philipp Zabel wrote: Hi Vineet, On Mon, 2017-09-18 at 18:51 +0200, Philipp Zabel wrote: Will it be OK for you to apply the corresponding DT update for platform - that way I don't have to keep track of when ur branch hits mainline etc. The chances of any ensuing

RE: [PATCH v1 RFC 1/1] Add Microchip KSZ8795 DSA driver

> in previous version I see that transit traffic (ping) goes to cpu, > then from cpu back to destination port. I.e. it works but with cpu > involving. Is this version supposed to work like that? Yes, it works in the old DSA way such that a software bridge is responsible to forward every packet.

RE: [PATCH v1 RFC 1/1] Add Microchip KSZ8795 DSA driver

> in previous version I see that transit traffic (ping) goes to cpu, > then from cpu back to destination port. I.e. it works but with cpu > involving. Is this version supposed to work like that? Yes, it works in the old DSA way such that a software bridge is responsible to forward every packet.

Re: [PATCH] direct-io: Prevent NULL pointer access in submit_page_section

On 9 October 2017 at 18:22, Al Viro wrote: > On Mon, Oct 09, 2017 at 11:13:18AM +0200, Andreas Gruenbacher wrote: >> In the code added to function submit_page_section by commit b1058b981, >> sdio->bio can currently be NULL when calling dio_bio_submit. This then >> leads

Re: [PATCH] direct-io: Prevent NULL pointer access in submit_page_section

On 9 October 2017 at 18:22, Al Viro wrote: > On Mon, Oct 09, 2017 at 11:13:18AM +0200, Andreas Gruenbacher wrote: >> In the code added to function submit_page_section by commit b1058b981, >> sdio->bio can currently be NULL when calling dio_bio_submit. This then >> leads to a NULL pointer access

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Pavel, On Mon, Oct 09, 2017 at 01:51:47PM -0400, Pavel Tatashin wrote: > I can go back to that approach, if Michal OK with it. But, that would > mean that I would need to touch every single architecture that > implements vmemmap_populate(), and also pass flags at least through > these

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Pavel, On Mon, Oct 09, 2017 at 01:51:47PM -0400, Pavel Tatashin wrote: > I can go back to that approach, if Michal OK with it. But, that would > mean that I would need to touch every single architecture that > implements vmemmap_populate(), and also pass flags at least through > these

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

On Mon, Oct 9, 2017 at 7:18 PM, Bjorn Helgaas wrote: > On Mon, Oct 09, 2017 at 12:15:17PM -0500, Bjorn Helgaas wrote: >> [+cc Rafael, linux-pm] >> >> Hi Jia-Ju, >> >> On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: >> > The drivers vt6655 and gma500 call

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

On Mon, Oct 9, 2017 at 7:18 PM, Bjorn Helgaas wrote: > On Mon, Oct 09, 2017 at 12:15:17PM -0500, Bjorn Helgaas wrote: >> [+cc Rafael, linux-pm] >> >> Hi Jia-Ju, >> >> On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: >> > The drivers vt6655 and gma500 call pci_set_power_state under a

Re: [PATCH] selinux: check CAP_SETFCAP for a particular inode & mapped user

On Mon, Oct 9, 2017 at 2:14 PM, Lubomir Rintel wrote: > On Thu, 2017-10-05 at 01:48 -0500, Serge E. Hallyn wrote: >> On Thu, Oct 05, 2017 at 08:16:11AM +0200, Lubomir Rintel wrote: >> > This allows setting "security.capability" xattr by a user that has >> > CAP_SETFCAP in an

Re: [PATCH] selinux: check CAP_SETFCAP for a particular inode & mapped user

On Mon, Oct 9, 2017 at 2:14 PM, Lubomir Rintel wrote: > On Thu, 2017-10-05 at 01:48 -0500, Serge E. Hallyn wrote: >> On Thu, Oct 05, 2017 at 08:16:11AM +0200, Lubomir Rintel wrote: >> > This allows setting "security.capability" xattr by a user that has >> > CAP_SETFCAP in an userns with SELinux.

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

On Mon 09-10-17 20:04:09, Michal Hocko wrote: > [CC Johannes - the thread starts > http://lkml.kernel.org/r/20171005222144.123797-1-shake...@google.com] > > On Mon 09-10-17 10:52:44, Greg Thelen wrote: [...] > > A few ideas on how to make it more flexible: > > > > a) Go back to memcg oom killing

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

On Mon 09-10-17 20:04:09, Michal Hocko wrote: > [CC Johannes - the thread starts > http://lkml.kernel.org/r/20171005222144.123797-1-shake...@google.com] > > On Mon 09-10-17 10:52:44, Greg Thelen wrote: [...] > > A few ideas on how to make it more flexible: > > > > a) Go back to memcg oom killing

net/sunrpc: v4.14-rc4 lockdep warning

Hi, I have run into the lockdep warning below while running v4.14-rc3/rc4 on an ARM64 defconfig Juno dev board - reporting it to check whether it is a known/genuine issue. Please let me know if you need further debug data or need some specific tests. Thanks, Lorenzo [6.209384]

net/sunrpc: v4.14-rc4 lockdep warning

Hi, I have run into the lockdep warning below while running v4.14-rc3/rc4 on an ARM64 defconfig Juno dev board - reporting it to check whether it is a known/genuine issue. Please let me know if you need further debug data or need some specific tests. Thanks, Lorenzo [6.209384]

Re: [PATCH v2 1/3] kcov: support comparison operands collection

On Mon, Oct 9, 2017 at 5:46 PM, Mark Rutland wrote: > Hi, > > I look forward to using this! :) > > I just have afew comments below. > > On Mon, Oct 09, 2017 at 05:05:19PM +0200, Alexander Potapenko wrote: >> +/* >> + * Defines the format for the types of collected

Re: [PATCH v2 1/3] kcov: support comparison operands collection

On Mon, Oct 9, 2017 at 5:46 PM, Mark Rutland wrote: > Hi, > > I look forward to using this! :) > > I just have afew comments below. > > On Mon, Oct 09, 2017 at 05:05:19PM +0200, Alexander Potapenko wrote: >> +/* >> + * Defines the format for the types of collected comparisons. >> + */ >> +enum

Re: [PATCH] selinux: check CAP_SETFCAP for a particular inode & mapped user

On Thu, 2017-10-05 at 01:48 -0500, Serge E. Hallyn wrote: > On Thu, Oct 05, 2017 at 08:16:11AM +0200, Lubomir Rintel wrote: > > This allows setting "security.capability" xattr by a user that has > > CAP_SETFCAP in an userns with SELinux. Namespaced capabilities are > > supported, as of commit

Re: [PATCH] selinux: check CAP_SETFCAP for a particular inode & mapped user

On Thu, 2017-10-05 at 01:48 -0500, Serge E. Hallyn wrote: > On Thu, Oct 05, 2017 at 08:16:11AM +0200, Lubomir Rintel wrote: > > This allows setting "security.capability" xattr by a user that has > > CAP_SETFCAP in an userns with SELinux. Namespaced capabilities are > > supported, as of commit

[PATCH] media: imon: Fix null-ptr-deref in imon_probe

It seems that the return value of usb_ifnum_to_if() can be NULL and needs to be checked. Signed-off-by: Arvind Yadav --- This bug report by Andrey Konovalov usb/media/imon: null-ptr-deref in imon_probe drivers/media/rc/imon.c | 5 + 1 file changed, 5

[PATCH] media: imon: Fix null-ptr-deref in imon_probe

It seems that the return value of usb_ifnum_to_if() can be NULL and needs to be checked. Signed-off-by: Arvind Yadav --- This bug report by Andrey Konovalov usb/media/imon: null-ptr-deref in imon_probe drivers/media/rc/imon.c | 5 + 1 file changed, 5 insertions(+) diff --git

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

On Mon 09-10-17 13:51:47, Pavel Tatashin wrote: > Hi Will, > > I can go back to that approach, if Michal OK with it. But, that would > mean that I would need to touch every single architecture that > implements vmemmap_populate(), and also pass flags at least through > these functions on every

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

On Mon 09-10-17 13:51:47, Pavel Tatashin wrote: > Hi Will, > > I can go back to that approach, if Michal OK with it. But, that would > mean that I would need to touch every single architecture that > implements vmemmap_populate(), and also pass flags at least through > these functions on every

Re: [tho...@m3y3r.de: Re: [PATCH] um: Fix kcov crash before kernel is started.]

On Mon, Oct 9, 2017 at 6:47 PM, Thomas Meyer wrote: > - Forwarded message from Thomas Meyer - > > Hi, > > are you able to shed light on this topic? > Any help is greatly appreciated! > > With kind regards > thomas > > Date: Sun, 8 Oct 2017 13:18:24 +0200

Re: [PATCH] net: can: Convert timers to use timer_setup()

On 10/09/2017 08:09 PM, Kees Cook wrote: > On Mon, Oct 9, 2017 at 10:53 AM, Marc Kleine-Budde > wrote: >> On 10/05/2017 02:51 AM, Kees Cook wrote: >>> In preparation for unconditionally passing the struct timer_list pointer to >>> all timer callbacks, switch to using the new

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

On Mon, 9 Oct 2017 09:33:50 -0600 Jonathan Corbet wrote: > > will prevent the callback from being called again. But this wrapper > > adds some overhead, and if the callback is safe from recursion, > > it can set this flag to disable the ftrace protection. > >

Re: [tho...@m3y3r.de: Re: [PATCH] um: Fix kcov crash before kernel is started.]

On Mon, Oct 9, 2017 at 6:47 PM, Thomas Meyer wrote: > - Forwarded message from Thomas Meyer - > > Hi, > > are you able to shed light on this topic? > Any help is greatly appreciated! > > With kind regards > thomas > > Date: Sun, 8 Oct 2017 13:18:24 +0200 > From: Thomas Meyer > To:

Re: [PATCH] net: can: Convert timers to use timer_setup()

On 10/09/2017 08:09 PM, Kees Cook wrote: > On Mon, Oct 9, 2017 at 10:53 AM, Marc Kleine-Budde > wrote: >> On 10/05/2017 02:51 AM, Kees Cook wrote: >>> In preparation for unconditionally passing the struct timer_list pointer to >>> all timer callbacks, switch to using the new timer_setup() and

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

On Mon, 9 Oct 2017 09:33:50 -0600 Jonathan Corbet wrote: > > will prevent the callback from being called again. But this wrapper > > adds some overhead, and if the callback is safe from recursion, > > it can set this flag to disable the ftrace protection. > > What happens if

Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically

On 10/07/2017 07:27 PM, Linus Walleij wrote: > On Thu, Sep 28, 2017 at 10:33 AM, Mika Westerberg > wrote: >> On Fri, Jul 21, 2017 at 11:49:00AM -0500, Grygorii Strashko wrote: >>> Now IRQ mappings are always created for all (allowed) GPIOs in gpiochip in >>>

Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically

On 10/07/2017 07:27 PM, Linus Walleij wrote: > On Thu, Sep 28, 2017 at 10:33 AM, Mika Westerberg > wrote: >> On Fri, Jul 21, 2017 at 11:49:00AM -0500, Grygorii Strashko wrote: >>> Now IRQ mappings are always created for all (allowed) GPIOs in gpiochip in >>> gpiochip_irqchip_add_key() which

Re: [PATCH] net: can: Convert timers to use timer_setup()

On Mon, Oct 9, 2017 at 10:53 AM, Marc Kleine-Budde wrote: > On 10/05/2017 02:51 AM, Kees Cook wrote: >> In preparation for unconditionally passing the struct timer_list pointer to >> all timer callbacks, switch to using the new timer_setup() and from_timer() >> to pass the

Re: [PATCH] net: can: Convert timers to use timer_setup()

On Mon, Oct 9, 2017 at 10:53 AM, Marc Kleine-Budde wrote: > On 10/05/2017 02:51 AM, Kees Cook wrote: >> In preparation for unconditionally passing the struct timer_list pointer to >> all timer callbacks, switch to using the new timer_setup() and from_timer() >> to pass the timer pointer

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

On Mon, Oct 09, 2017 at 10:50:34AM -0700, Andy Lutomirski wrote: > The choices are somewhat lazy and not lazy at all. Yeah, you probably should explain those choices somewhere and what exactly they mean. > The degree of simplification I would get by removing it is basically > nil. The debugfs

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

On Mon, Oct 09, 2017 at 10:50:34AM -0700, Andy Lutomirski wrote: > The choices are somewhat lazy and not lazy at all. Yeah, you probably should explain those choices somewhere and what exactly they mean. > The degree of simplification I would get by removing it is basically > nil. The debugfs

Re: [PATCH] pinctrl: cherryview: fix issues caused by dynamic gpio irqs mapping

On 10/07/2017 07:42 PM, Linus Walleij wrote: > On Tue, Oct 3, 2017 at 7:00 PM, Grygorii Strashko > wrote: > >> New GPIO IRQs are allocated and mapped dynamically by default when >> GPIO IRQ infrastructure is used by cherryview-pinctrl driver. >> This causes issues on

Re: [PATCH] pinctrl: cherryview: fix issues caused by dynamic gpio irqs mapping

On 10/07/2017 07:42 PM, Linus Walleij wrote: > On Tue, Oct 3, 2017 at 7:00 PM, Grygorii Strashko > wrote: > >> New GPIO IRQs are allocated and mapped dynamically by default when >> GPIO IRQ infrastructure is used by cherryview-pinctrl driver. >> This causes issues on some Intel platforms

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

[CC Johannes - the thread starts http://lkml.kernel.org/r/20171005222144.123797-1-shake...@google.com] On Mon 09-10-17 10:52:44, Greg Thelen wrote: > Michal Hocko wrote: > > > On Fri 06-10-17 12:33:03, Shakeel Butt wrote: > >> >> names_cachep =

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

[CC Johannes - the thread starts http://lkml.kernel.org/r/20171005222144.123797-1-shake...@google.com] On Mon 09-10-17 10:52:44, Greg Thelen wrote: > Michal Hocko wrote: > > > On Fri 06-10-17 12:33:03, Shakeel Butt wrote: > >> >> names_cachep = kmem_cache_create("names_cache", PATH_MAX,

Re: [PATCH v2 4/5] drm/vc4: remove bridge from driver internal structure

Benjamin Gaignard writes: > With a call to drm_of_panel_bridge_remove() we could remove > the bridge without store it in vc4_dpi internal driver structure. > > Signed-off-by: Benjamin Gaignard Reviewed-by: Eric Anholt

Re: [PATCH v2 4/5] drm/vc4: remove bridge from driver internal structure

Benjamin Gaignard writes: > With a call to drm_of_panel_bridge_remove() we could remove > the bridge without store it in vc4_dpi internal driver structure. > > Signed-off-by: Benjamin Gaignard Reviewed-by: Eric Anholt Thanks for doing this cleanup! signature.asc Description: PGP signature

linux-next: manual merge of the drivers-x86 tree with the net-next tree

Hi Darren, [Apologies for multiple copies - for some reason vger seems to eat mails I send from scripts, still trying to figure this out] Today's linux-next merge of the drivers-x86 tree got a conflict in: Documentation/admin-guide/thunderbolt.rst between commit: e69b6c02b4c3b ("net: Add

linux-next: manual merge of the drivers-x86 tree with the net-next tree

Hi Darren, [Apologies for multiple copies - for some reason vger seems to eat mails I send from scripts, still trying to figure this out] Today's linux-next merge of the drivers-x86 tree got a conflict in: Documentation/admin-guide/thunderbolt.rst between commit: e69b6c02b4c3b ("net: Add

Re: [PATCH 4/4] arm: dts: r8a7790: add cpu capacity-dmips-mhz information

On 18/09/17 08:39, Simon Horman wrote: > On Wed, Aug 30, 2017 at 03:41:20PM +0100, Dietmar Eggemann wrote: >> The following 'capacity-dmips-mhz' dt property values are used: >> >> Cortex-A15: 1024, Cortex-A7: 539 >> >> They have been derived form the cpu_efficiency values: >> >> Cortex-A15: 3891,

Re: [PATCH 4/4] arm: dts: r8a7790: add cpu capacity-dmips-mhz information

On 18/09/17 08:39, Simon Horman wrote: > On Wed, Aug 30, 2017 at 03:41:20PM +0100, Dietmar Eggemann wrote: >> The following 'capacity-dmips-mhz' dt property values are used: >> >> Cortex-A15: 1024, Cortex-A7: 539 >> >> They have been derived form the cpu_efficiency values: >> >> Cortex-A15: 3891,

Re: [RFC PATCH] mm: shm: round up tmpfs size to huge page size when huge=always

On 10/9/17 10:26 AM, Michal Hocko wrote: On Tue 10-10-17 00:43:31, Yang Shi wrote: On 10/8/17 11:48 PM, Michal Hocko wrote: On Sun 08-10-17 15:56:51, Kirill A. Shutemov wrote: On Sat, Oct 07, 2017 at 04:22:10AM +0800, Yang Shi wrote: When passing "huge=always" option for mounting tmpfs,

Re: [RFC PATCH] mm: shm: round up tmpfs size to huge page size when huge=always

On 10/9/17 10:26 AM, Michal Hocko wrote: On Tue 10-10-17 00:43:31, Yang Shi wrote: On 10/8/17 11:48 PM, Michal Hocko wrote: On Sun 08-10-17 15:56:51, Kirill A. Shutemov wrote: On Sat, Oct 07, 2017 at 04:22:10AM +0800, Yang Shi wrote: When passing "huge=always" option for mounting tmpfs,

Re: [PATCH] net: can: Convert timers to use timer_setup()

On 10/05/2017 02:51 AM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Oliver Hartkopp > Cc: Marc

Re: [PATCH] net: can: Convert timers to use timer_setup()

On 10/05/2017 02:51 AM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Oliver Hartkopp > Cc: Marc Kleine-Budde > Cc:

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Michal Hocko wrote: > On Fri 06-10-17 12:33:03, Shakeel Butt wrote: >> >> names_cachep = kmem_cache_create("names_cache", PATH_MAX, 0, >> >> - SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL); >> >> +

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

Michal Hocko wrote: > On Fri 06-10-17 12:33:03, Shakeel Butt wrote: >> >> names_cachep = kmem_cache_create("names_cache", PATH_MAX, 0, >> >> - SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL); >> >> + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL); >> > >> >

usb/sound: use-after-free in snd_usb_mixer_interrupt

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). gadgetfs: bound to dummy_udc driver usb 1-1: new full-speed USB device number 2 using dummy_hcd gadgetfs: connected gadgetfs: disconnected gadgetfs:

usb/sound: use-after-free in snd_usb_mixer_interrupt

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). gadgetfs: bound to dummy_udc driver usb 1-1: new full-speed USB device number 2 using dummy_hcd gadgetfs: connected gadgetfs: disconnected gadgetfs:

usb/net/rtlwifi: trying to register non-static key in rtl_c2hcmd_launcher

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 24 Comm:

usb/net/rtlwifi: trying to register non-static key in rtl_c2hcmd_launcher

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 24 Comm:

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Will, I can go back to that approach, if Michal OK with it. But, that would mean that I would need to touch every single architecture that implements vmemmap_populate(), and also pass flags at least through these functions on every architectures (some have more than one decided by configs).:

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

Hi Will, I can go back to that approach, if Michal OK with it. But, that would mean that I would need to touch every single architecture that implements vmemmap_populate(), and also pass flags at least through these functions on every architectures (some have more than one decided by configs).:

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

On Mon, Oct 9, 2017 at 10:36 AM, Borislav Petkov wrote: > On Mon, Oct 09, 2017 at 07:02:31PM +0200, Borislav Petkov wrote: >> From 29a6426c20f25b8df767356a04727cb113e8e784 Mon Sep 17 00:00:00 2001 >> From: Andy Lutomirski >> Date: Mon, 9 Oct 2017 09:50:49 -0700

Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

On Mon, Oct 9, 2017 at 10:36 AM, Borislav Petkov wrote: > On Mon, Oct 09, 2017 at 07:02:31PM +0200, Borislav Petkov wrote: >> From 29a6426c20f25b8df767356a04727cb113e8e784 Mon Sep 17 00:00:00 2001 >> From: Andy Lutomirski >> Date: Mon, 9 Oct 2017 09:50:49 -0700 >> Subject: [PATCH] x86/mm: Flush

usb/irda: global-out-of-bounds in irda_qos_bits_to_value

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that qos->baud_rate.bits value is taken from USB descriptor and then used as a array index without any checks.

usb/irda: global-out-of-bounds in irda_qos_bits_to_value

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that qos->baud_rate.bits value is taken from USB descriptor and then used as a array index without any checks.

usb/net/rt2x00: warning in rt2800_eeprom_word_index

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). I'm not sure whether this is a bug in the driver, or just a way to report misbehaving device. In the latter case this shouldn't be a WARN() call, since

usb/net/rt2x00: warning in rt2800_eeprom_word_index

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). I'm not sure whether this is a bug in the driver, or just a way to report misbehaving device. In the latter case this shouldn't be a WARN() call, since

usb/media/imon: global-out-of-bounds in imon_probe/imon_init_intf0

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that imon_ir_raw doesn't have the .key_table initializer, which causes out-of-bounds access when iterating over the key table.

usb/media/imon: global-out-of-bounds in imon_probe/imon_init_intf0

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that imon_ir_raw doesn't have the .key_table initializer, which causes out-of-bounds access when iterating over the key table.

usb/net/prism2usb: warning in hfa384x_usbctlxq_run/usb_submit_urb

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that the driver doesn't check the endpoint type provided in the USB descriptor. usb 1-1: BOGUS urb xfer, pipe 3 != type 1 [ cut here

usb/net/prism2usb: warning in hfa384x_usbctlxq_run/usb_submit_urb

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that the driver doesn't check the endpoint type provided in the USB descriptor. usb 1-1: BOGUS urb xfer, pipe 3 != type 1 [ cut here

usb/nfs/pn533: use-after-free in pn533_send_complete

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). usb 1-1: NFC: Can't submit reader poweron cmd response -90 pn533_usb 1-1:6.1: NFC: Couldn't poweron the reader (error -90) pn533_usb: probe of 1-1:6.1 failed

usb/nfs/pn533: use-after-free in pn533_send_complete

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). usb 1-1: NFC: Can't submit reader poweron cmd response -90 pn533_usb 1-1:6.1: NFC: Couldn't poweron the reader (error -90) pn533_usb: probe of 1-1:6.1 failed

usb/media/imon: null-ptr-deref in imon_probe

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that the return value of usb_ifnum_to_if() can be NULL and needs to be checked. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by

usb/net/ath6kl: GPF in ath6kl_usb_alloc_urb_from_pipe

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). usb 1-1: New USB device found, idVendor=0cf3, idProduct=9375 usb 1-1: New USB device strings: Mfr=2, Product=255, SerialNumber=8 usb 1-1: Product: a usb 1-1:

usb/net/prism2usb: warning in hfa384x_drvr_start/usb_submit_urb

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that the driver doesn't check the endpoint type provided in the USB descriptor. usb 1-1: BOGUS urb xfer, pipe 3 != type 1 [ cut here

usb/media/imon: null-ptr-deref in imon_probe

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). It seems that the return value of usb_ifnum_to_if() can be NULL and needs to be checked. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by

<    4   5   6   7   8   9   10   11   12   13   >