Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic

On Tue, Sep 03, 2019 at 06:56:10PM +0100, Al Viro wrote: > On Tue, Sep 03, 2019 at 08:39:30AM -0700, Christoph Hellwig wrote: > > > > There's much nastier situation than "new upstream kernel released, > > > need to rebuild" - it's bisect in mainline trying to locate something... > > > > I really

[PATCH] libertas: Add missing sentinel at end of if_usb.c fw_table

This sentinel tells the firmware loading process when to stop. Reported-and-tested-by: syzbot+98156c174c5a2cad9...@syzkaller.appspotmail.com Signed-off-by: Kevin Easton --- drivers/net/wireless/marvell/libertas/if_usb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH 4.19 053/105] mm/mincore.c: make mincore() more conservative

On Wed, May 22, 2019 at 11:21:11AM +0200, Michal Hocko wrote: > On Wed 22-05-19 10:57:41, Pavel Machek wrote: > > Hi! > > > > > commit 134fca9063ad4851de767d1768180e5dede9a881 upstream. > > > > > > The semantics of what mincore() considers to be resident is not > > > completely clear, but Linux

Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]

On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote: > On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote: > > > > On 2019-04-15, Enrico Weigelt, metux IT consult wrote: > > > > This patchset makes it possible to retrieve pid file descriptors at > > > > process creation time by

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

On Tue, Jan 15, 2019 at 11:52:25PM -0800, Josh Snyder wrote: > On Tue, Jan 15, 2019 at 10:34 PM Dominique Martinet > wrote: > > > > There is a difference with your previous patch though, that used to list no > > page in core when it didn't know; this patch lists pages as in core when it > >

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

On Sat, Jan 05, 2019 at 01:54:03PM -0800, Linus Torvalds wrote: > On Sat, Jan 5, 2019 at 12:43 PM Jiri Kosina wrote: > > > > > Who actually _uses_ mincore()? That's probably the best guide to what > > > we should do. Maybe they open the file read-only even if they are the > > > owner, and we

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

On Sat, Jan 05, 2019 at 01:54:03PM -0800, Linus Torvalds wrote: > On Sat, Jan 5, 2019 at 12:43 PM Jiri Kosina wrote: > > > > > Who actually _uses_ mincore()? That's probably the best guide to what > > > we should do. Maybe they open the file read-only even if they are the > > > owner, and we

Re: Can we drop upstream Linux x32 support?

On Thu, Dec 13, 2018 at 10:05:14AM +0100, Richard Weinberger wrote: > On Thu, Dec 13, 2018 at 6:03 AM Kevin Easton wrote: > > > > On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote: > > ... > > > I can't say anything about the syscall inte

Re: Can we drop upstream Linux x32 support?

On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote: ... > I can't say anything about the syscall interface. However, what I do know > is that the weird combination of a 32-bit userland with a 64-bit kernel > interface is sometimes causing issues. For example, application

Re: [PATCH] Add /proc/pid_generation

On Wed, Nov 21, 2018 at 12:14:44PM -0800, Daniel Colascione wrote: > This change adds a per-pid-namespace 64-bit generation number, > incremented on PID rollover, and exposes it via a new proc file > /proc/pid_generation. By examining this file before and after /proc > enumeration, user code can

Re: [PATCH] Add /proc/pid_generation

On Wed, Nov 21, 2018 at 12:14:44PM -0800, Daniel Colascione wrote: > This change adds a per-pid-namespace 64-bit generation number, > incremented on PID rollover, and exposes it via a new proc file > /proc/pid_generation. By examining this file before and after /proc > enumeration, user code can

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

On Mon, May 07, 2018 at 04:03:25PM +0300, Michael S. Tsirkin wrote: > On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote: > > The struct vhost_msg within struct vhost_msg_node is copied to userspace, > > so it should be allocated with kzalloc() to ensure all st

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

On Mon, May 07, 2018 at 04:03:25PM +0300, Michael S. Tsirkin wrote: > On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote: > > The struct vhost_msg within struct vhost_msg_node is copied to userspace, > > so it should be allocated with kzalloc() to ensure all st

Re: [PATCH] vhost: make msg padding explicit

On Wed, May 02, 2018 at 05:19:27PM +0300, Michael S. Tsirkin wrote: > On Wed, May 02, 2018 at 10:04:46AM -0400, David Miller wrote: > > From: "Michael S. Tsirkin" > > Date: Wed, 2 May 2018 16:36:37 +0300 > > > > > Ouch. True - and in particular the 32 bit ABI on 64 bit kernels

Re: [PATCH] vhost: make msg padding explicit

On Wed, May 02, 2018 at 05:19:27PM +0300, Michael S. Tsirkin wrote: > On Wed, May 02, 2018 at 10:04:46AM -0400, David Miller wrote: > > From: "Michael S. Tsirkin" > > Date: Wed, 2 May 2018 16:36:37 +0300 > > > > > Ouch. True - and in particular the 32 bit ABI on 64 bit kernels doesn't > > >

Re: [PATCH] vhost: make msg padding explicit

; <m...@redhat.com> > >> Date: Fri, 27 Apr 2018 19:02:05 +0300 > >> > >> > There's a 32 bit hole just after type. It's best to > >> > give it a name, this way compiler is forced to initialize > >> > it with rest of the structure. > >

Re: [PATCH] vhost: make msg padding explicit

Fri, 27 Apr 2018 19:02:05 +0300 > >> > >> > There's a 32 bit hole just after type. It's best to > >> > give it a name, this way compiler is forced to initialize > >> > it with rest of the structure. > >> > > >> > Reported-

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

On Fri, Apr 27, 2018 at 09:07:56PM -0400, Kevin Easton wrote: > On Fri, Apr 27, 2018 at 07:05:45PM +0300, Michael S. Tsirkin wrote: > > On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote: > > > The struct vhost_msg within struct vhost_msg_node is copied to userspace,

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

On Fri, Apr 27, 2018 at 09:07:56PM -0400, Kevin Easton wrote: > On Fri, Apr 27, 2018 at 07:05:45PM +0300, Michael S. Tsirkin wrote: > > On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote: > > > The struct vhost_msg within struct vhost_msg_node is copied to userspace,

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

On Fri, Apr 27, 2018 at 07:05:45PM +0300, Michael S. Tsirkin wrote: > On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote: > > The struct vhost_msg within struct vhost_msg_node is copied to userspace, > > so it should be allocated with kzalloc() to ensure all st

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

On Fri, Apr 27, 2018 at 07:05:45PM +0300, Michael S. Tsirkin wrote: > On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote: > > The struct vhost_msg within struct vhost_msg_node is copied to userspace, > > so it should be allocated with kzalloc() to ensure all st

[PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

The struct vhost_msg within struct vhost_msg_node is copied to userspace, so it should be allocated with kzalloc() to ensure all structure padding is zeroed. Signed-off-by: Kevin Easton <ke...@guarana.org> Reported-by: syzbot+87cfa083e727a2247...@syzkaller.appspotmail.com --- drivers

[PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

The struct vhost_msg within struct vhost_msg_node is copied to userspace, so it should be allocated with kzalloc() to ensure all structure padding is zeroed. Signed-off-by: Kevin Easton Reported-by: syzbot+87cfa083e727a2247...@syzkaller.appspotmail.com --- drivers/vhost/vhost.c | 2 +- 1 file

Re: KASAN: slab-out-of-bounds Read in pfkey_add

On Mon, Apr 09, 2018 at 01:56:36AM -0400, Kevin Easton wrote: > On Sun, Apr 08, 2018 at 09:04:33PM -0700, Eric Biggers wrote: > ... > > > > Looks like this is going to be fixed by > > https://patchwork.kernel.org/patch/10327883/ ("af_key: Always verify length

Re: KASAN: slab-out-of-bounds Read in pfkey_add

On Mon, Apr 09, 2018 at 01:56:36AM -0400, Kevin Easton wrote: > On Sun, Apr 08, 2018 at 09:04:33PM -0700, Eric Biggers wrote: > ... > > > > Looks like this is going to be fixed by > > https://patchwork.kernel.org/patch/10327883/ ("af_key: Always verify length

Re: [PATCH v2 2/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

On Mon, Apr 09, 2018 at 12:34:42PM +0200, Steffen Klassert wrote: > On Sat, Apr 07, 2018 at 11:40:47AM -0400, Kevin Easton wrote: > > Several places use (x + 7) / 8 to convert from a number of bits to a number > > of bytes. Replace those with DIV_ROUND_UP(x, 8) instead,

Re: [PATCH v2 2/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

On Mon, Apr 09, 2018 at 12:34:42PM +0200, Steffen Klassert wrote: > On Sat, Apr 07, 2018 at 11:40:47AM -0400, Kevin Easton wrote: > > Several places use (x + 7) / 8 to convert from a number of bits to a number > > of bytes. Replace those with DIV_ROUND_UP(x, 8) instead,

Re: KASAN: slab-out-of-bounds Read in pfkey_add

On Sun, Apr 08, 2018 at 09:04:33PM -0700, Eric Biggers wrote: ... > > Looks like this is going to be fixed by > https://patchwork.kernel.org/patch/10327883/ ("af_key: Always verify length of > provided sadb_key"), but it's not applied yet to the ipsec tree yet. Kevin, > for > future reference,

Re: KASAN: slab-out-of-bounds Read in pfkey_add

On Sun, Apr 08, 2018 at 09:04:33PM -0700, Eric Biggers wrote: ... > > Looks like this is going to be fixed by > https://patchwork.kernel.org/patch/10327883/ ("af_key: Always verify length of > provided sadb_key"), but it's not applied yet to the ipsec tree yet. Kevin, > for > future reference,

[PATCH v2 1/2] af_key: Always verify length of provided sadb_key

of SADB_X_AALG_NULL. Furthermore, the sadb_key_len value must be long enough to include both the key data and the struct sadb_key itself. Introduce a helper function verify_key_len(), and call it from parse_exthdrs() where other exthdr types are similarly checked for correctness. Signed-off-by: Kevin Easton <

[PATCH v2 0/2] af_key: Fix for sadb_key memcpy read overrun

on Steffen's feedback I have re-ordered them so that the fix only is in patch 1, which I would suggest is also a stable tree candidate, whereas patch 2 is a cleanup only. Kevin Easton (2): af_key: Always verify length of provided sadb_key af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

[PATCH v2 2/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

Several places use (x + 7) / 8 to convert from a number of bits to a number of bytes. Replace those with DIV_ROUND_UP(x, 8) instead, for consistency with other parts of the same file. Signed-off-by: Kevin Easton <ke...@guarana.org> --- net/key/af_key.c | 13 +++-- 1 file chan

[PATCH v2 1/2] af_key: Always verify length of provided sadb_key

of SADB_X_AALG_NULL. Furthermore, the sadb_key_len value must be long enough to include both the key data and the struct sadb_key itself. Introduce a helper function verify_key_len(), and call it from parse_exthdrs() where other exthdr types are similarly checked for correctness. Signed-off-by: Kevin Easton

[PATCH v2 0/2] af_key: Fix for sadb_key memcpy read overrun

on Steffen's feedback I have re-ordered them so that the fix only is in patch 1, which I would suggest is also a stable tree candidate, whereas patch 2 is a cleanup only. Kevin Easton (2): af_key: Always verify length of provided sadb_key af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

[PATCH v2 2/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

Several places use (x + 7) / 8 to convert from a number of bits to a number of bytes. Replace those with DIV_ROUND_UP(x, 8) instead, for consistency with other parts of the same file. Signed-off-by: Kevin Easton --- net/key/af_key.c | 13 +++-- 1 file changed, 7 insertions(+), 6

Re: [PATCH 1/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

On Wed, Mar 28, 2018 at 07:59:25AM +0200, Steffen Klassert wrote: > On Mon, Mar 26, 2018 at 07:39:16AM -0400, Kevin Easton wrote: > > Several places use (x + 7) / 8 to convert from a number of bits to a number > > of bytes. Replace those with DIV_ROUND_UP(x, 8) instead,

Re: [PATCH 1/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

On Wed, Mar 28, 2018 at 07:59:25AM +0200, Steffen Klassert wrote: > On Mon, Mar 26, 2018 at 07:39:16AM -0400, Kevin Easton wrote: > > Several places use (x + 7) / 8 to convert from a number of bits to a number > > of bytes. Replace those with DIV_ROUND_UP(x, 8) instead,

[PATCH 1/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

Several places use (x + 7) / 8 to convert from a number of bits to a number of bytes. Replace those with DIV_ROUND_UP(x, 8) instead, for consistency with other parts of the same file. Signed-off-by: Kevin Easton <ke...@guarana.org> --- net/key/af_key.c | 21 +++-- 1 file c

[PATCH 2/2] af_key: Always verify length of provided sadb_key

of SADB_X_AALG_NULL. Furthermore, the sadb_key_len value must be long enough to include both the key data and the struct sadb_key itself. Introduce a helper function verify_key_len(), and call it from parse_exthdrs() where other exthdr types are similarly checked for correctness. Signed-off-by: Kevin Easton <

[PATCH 1/2] af_key: Use DIV_ROUND_UP() instead of open-coded equivalent

Several places use (x + 7) / 8 to convert from a number of bits to a number of bytes. Replace those with DIV_ROUND_UP(x, 8) instead, for consistency with other parts of the same file. Signed-off-by: Kevin Easton --- net/key/af_key.c | 21 +++-- 1 file changed, 11 insertions

[PATCH 2/2] af_key: Always verify length of provided sadb_key

of SADB_X_AALG_NULL. Furthermore, the sadb_key_len value must be long enough to include both the key data and the struct sadb_key itself. Introduce a helper function verify_key_len(), and call it from parse_exthdrs() where other exthdr types are similarly checked for correctness. Signed-off-by: Kevin Easton

[PATCH 0/2] af_key: Fix for sadb_key memcpy read overrun

As found by syzbot, af_key does not properly validate the key length in sadb_key messages from userspace. This can result in copying from beyond the end of the sadb_key part of the message, or indeed beyond the end of the entire packet. Kevin Easton (2): af_key: Use DIV_ROUND_UP() instead

[PATCH 0/2] af_key: Fix for sadb_key memcpy read overrun

As found by syzbot, af_key does not properly validate the key length in sadb_key messages from userspace. This can result in copying from beyond the end of the sadb_key part of the message, or indeed beyond the end of the entire packet. Kevin Easton (2): af_key: Use DIV_ROUND_UP() instead

Re: [RFC PATCH 2/6] fs: provide a generic compat_sys_truncate64() implementation

On Sun, Mar 18, 2018 at 05:10:52PM +0100, Dominik Brodowski wrote: > The compat_sys_truncate64() implementations in mips, powerpc, s390, sparc > and x86 only differed based on whether the u64 parameter needed padding > and on its endianness. > ... > +#ifdef __ARCH_WANT_COMPAT_SYS_TRUNCATE64 >

Re: [RFC PATCH 2/6] fs: provide a generic compat_sys_truncate64() implementation

On Sun, Mar 18, 2018 at 05:10:52PM +0100, Dominik Brodowski wrote: > The compat_sys_truncate64() implementations in mips, powerpc, s390, sparc > and x86 only differed based on whether the u64 parameter needed padding > and on its endianness. > ... > +#ifdef __ARCH_WANT_COMPAT_SYS_TRUNCATE64 >

Re: [RFC PATCH 4/7] kconfig: support new special property shell=

On Sat, Feb 10, 2018 at 10:05:12AM -0800, Randy Dunlap wrote: > On 02/10/2018 12:55 AM, Ulf Magnusson wrote: > > How many compilers don't support -fno-stack-protector by the way? > > > > config CC_HAS_STACKPROTECTOR_STRONG > > bool > > option shell="$CC -Werror

Re: [RFC PATCH 4/7] kconfig: support new special property shell=

On Sat, Feb 10, 2018 at 10:05:12AM -0800, Randy Dunlap wrote: > On 02/10/2018 12:55 AM, Ulf Magnusson wrote: > > How many compilers don't support -fno-stack-protector by the way? > > > > config CC_HAS_STACKPROTECTOR_STRONG > > bool > > option shell="$CC -Werror

Re: [PATCH 30/35] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

On Thu, Jan 18, 2018 at 04:38:32PM -0800, Tim Chen wrote: > On 01/18/2018 05:48 AM, Peter Zijlstra wrote: > > > >+/* > >+ * Avoid user/user BTB poisoning by flushing the branch > >predictor > >+ * when switching between processes. This stops one process from >

Re: [PATCH 30/35] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

On Thu, Jan 18, 2018 at 04:38:32PM -0800, Tim Chen wrote: > On 01/18/2018 05:48 AM, Peter Zijlstra wrote: > > > >+/* > >+ * Avoid user/user BTB poisoning by flushing the branch > >predictor > >+ * when switching between processes. This stops one process from >

Re: [PATCH 16/21] x86/entry/64: Use a per-CPU trampoline stack for IDT entries

> From: Dave Hansen > > The "SYSENTER" stack is used for a lot more than SYSENTER now. > Give it a better string to display in stack dumps. > > We should probably cleanse the 64-bit code of the remaining > "SYSENTER" nomenclature too at some point. > >

Re: [PATCH 16/21] x86/entry/64: Use a per-CPU trampoline stack for IDT entries

> From: Dave Hansen > > The "SYSENTER" stack is used for a lot more than SYSENTER now. > Give it a better string to display in stack dumps. > > We should probably cleanse the 64-bit code of the remaining > "SYSENTER" nomenclature too at some point. > > Signed-off-by: Dave Hansen > --- > >

Re: [GIT pull] printk updates for 4.15

On Sat, Nov 18, 2017 at 01:26:07AM +0100, Thomas Gleixner wrote: > On Thu, 16 Nov 2017, Thomas Gleixner wrote: > > I hope that I can find a few spare cycles to whip up a POC patch which does > > not make stuff fall apart immediately. > > Here you go. It survived suspend resume in a VM. > >

Re: [GIT pull] printk updates for 4.15

On Sat, Nov 18, 2017 at 01:26:07AM +0100, Thomas Gleixner wrote: > On Thu, 16 Nov 2017, Thomas Gleixner wrote: > > I hope that I can find a few spare cycles to whip up a POC patch which does > > not make stuff fall apart immediately. > > Here you go. It survived suspend resume in a VM. > >

Re: [PATCH 05/14] isdn: isdnloop: suppress a gcc-7 warning

On Fri, Jul 14, 2017 at 12:37:05PM +0200, Arnd Bergmann wrote: > On Fri, Jul 14, 2017 at 12:08 PM, Joe Perches wrote: > > On Fri, 2017-07-14 at 11:25 +0200, Arnd Bergmann wrote: > >> We test whether a bit is set in a mask here, which is correct > >> but gcc warns about it as it

Re: [PATCH 05/14] isdn: isdnloop: suppress a gcc-7 warning

On Fri, Jul 14, 2017 at 12:37:05PM +0200, Arnd Bergmann wrote: > On Fri, Jul 14, 2017 at 12:08 PM, Joe Perches wrote: > > On Fri, 2017-07-14 at 11:25 +0200, Arnd Bergmann wrote: > >> We test whether a bit is set in a mask here, which is correct > >> but gcc warns about it as it thinks it might be

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 04:23:56PM +0200, Michal Hocko wrote: > On Wed 05-07-17 13:19:40, Ben Hutchings wrote: > > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > > > wrote: > > > > > > > > We have: > > > > > >

Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 05, 2017 at 04:23:56PM +0200, Michal Hocko wrote: > On Wed 05-07-17 13:19:40, Ben Hutchings wrote: > > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > > > wrote: > > > > > > > > We have: > > > > > > > > bottom =

Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 05:56:20AM +0200, Jason A. Donenfeld wrote: > Hey Ted, > > On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote: > > Note that crypto_rng_reset() is called by big_key_init() in > > security/keys/big_key.c as a late_initcall(). So if we are on a > > system

Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 05:56:20AM +0200, Jason A. Donenfeld wrote: > Hey Ted, > > On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote: > > Note that crypto_rng_reset() is called by big_key_init() in > > security/keys/big_key.c as a late_initcall(). So if we are on a > > system where the crng

Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On Thu, May 25, 2017 at 05:40:16PM -0700, Andy Lutomirski wrote: > On Thu, May 25, 2017 at 4:24 PM, Linus Torvalds > wrote: > > On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov > > wrote: > >> Here' my first attempt to bring

Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On Thu, May 25, 2017 at 05:40:16PM -0700, Andy Lutomirski wrote: > On Thu, May 25, 2017 at 4:24 PM, Linus Torvalds > wrote: > > On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov > > wrote: > >> Here' my first attempt to bring boot-time between 4- and 5-level paging. > >> It looks not too

Re: [PATCH] kernel/fork.c: use sizeof() instead of sizeof

On Tue, Feb 02, 2016 at 05:04:06PM +, Al Viro wrote: > FWIW, the actual rules are > unary-expression: postfix-expression | > ++ unary-expression | > -- unary-expression | > - cast-expression | >

Re: [PATCH] kernel/fork.c: use sizeof() instead of sizeof

On Tue, Feb 02, 2016 at 05:04:06PM +, Al Viro wrote: > FWIW, the actual rules are > unary-expression: postfix-expression | > ++ unary-expression | > -- unary-expression | > - cast-expression | >

Re: [PATCH RFC] vfs: add a O_NOMTIME flag

On Mon, May 11, 2015 at 07:10:21PM -0400, Theodore Ts'o wrote: > On Mon, May 11, 2015 at 09:24:09AM -0700, Sage Weil wrote: > > > Let me re-ask the question that I asked last week (and was apparently > > > ignored). Why not trying to use the lazytime feature instead of > > > pointing a head

Re: [PATCH RFC] vfs: add a O_NOMTIME flag

On Mon, May 11, 2015 at 07:10:21PM -0400, Theodore Ts'o wrote: On Mon, May 11, 2015 at 09:24:09AM -0700, Sage Weil wrote: Let me re-ask the question that I asked last week (and was apparently ignored). Why not trying to use the lazytime feature instead of pointing a head straight at the

Re: [PATCH 00/12] [RFC] x86: Memory Protection Keys

On Thu, May 07, 2015 at 08:18:43PM +0100, One Thousand Gnomes wrote: > > We could keep heap metadata as R/O and only make it R/W inside of > > malloc() itself to catch corruption more quickly. > > If you implement multiple malloc pools you can chop up lots of stuff. > > In library land it isn't

Re: [PATCH 00/12] [RFC] x86: Memory Protection Keys

On Thu, May 07, 2015 at 08:18:43PM +0100, One Thousand Gnomes wrote: We could keep heap metadata as R/O and only make it R/W inside of malloc() itself to catch corruption more quickly. If you implement multiple malloc pools you can chop up lots of stuff. In library land it isn't just

Re: Minimal effort/low overhead file descriptor duplication over Posix.1b s

On Tue, Dec 02, 2014 at 03:35:17PM +1100, Alex Dubov wrote: > Unfortunately, using facilities like Unix domain sockets to merely pass file > descriptors between "worker" processes is unnecessarily difficult, due to > the following common consideration: > > 1. Domain sockets and named pipes are

Re: Minimal effort/low overhead file descriptor duplication over Posix.1b s

On Tue, Dec 02, 2014 at 03:35:17PM +1100, Alex Dubov wrote: Unfortunately, using facilities like Unix domain sockets to merely pass file descriptors between worker processes is unnecessarily difficult, due to the following common consideration: 1. Domain sockets and named pipes are

Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

On Wed, Sep 17, 2014 at 09:43:09PM -0700, Dave Hansen wrote: > On 09/17/2014 08:23 PM, Kevin Easton wrote: > > I was actually thinking that the kernel would take care of the xsave / > > xrstor (for current), updating tsk->thread.fpu.state (for non-running > > thr

Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

On Wed, Sep 17, 2014 at 09:43:09PM -0700, Dave Hansen wrote: On 09/17/2014 08:23 PM, Kevin Easton wrote: I was actually thinking that the kernel would take care of the xsave / xrstor (for current), updating tsk-thread.fpu.state (for non-running threads) and sending an IPI for threads

Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

On Thu, Sep 18, 2014 at 12:40:29AM +, Ren, Qiaowei wrote: > > Would it be prudent to use an error code other than EINVAL for the > > "hardware doesn't support it" case? > > > Seems like no specific error code for this case. ENXIO would probably be OK. It's not too important as long as it's

Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load

On Tue, Sep 16, 2014 at 05:05:51PM -0700, Richard Larocque wrote: > + case PR_SET_VDSO: > + if (arg2 == PR_VDSO_ENABLE) > + me->signal->disable_vdso = 0; > + else if (arg2 == PR_VDSO_DISABLE) > + me->signal->disable_vdso = 1; > +

Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load

On Tue, Sep 16, 2014 at 05:05:51PM -0700, Richard Larocque wrote: + case PR_SET_VDSO: + if (arg2 == PR_VDSO_ENABLE) + me-signal-disable_vdso = 0; + else if (arg2 == PR_VDSO_DISABLE) + me-signal-disable_vdso = 1; +

Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

On Thu, Sep 18, 2014 at 12:40:29AM +, Ren, Qiaowei wrote: Would it be prudent to use an error code other than EINVAL for the hardware doesn't support it case? Seems like no specific error code for this case. ENXIO would probably be OK. It's not too important as long as it's

Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

On Thu, Sep 11, 2014 at 04:46:48PM +0800, Qiaowei Ren wrote: > +static __user void *task_get_bounds_dir(struct task_struct *tsk) > +{ > + struct xsave_struct *xsave_buf; > + > + fpu_xsave(>thread.fpu); > + xsave_buf = &(tsk->thread.fpu.state->xsave); > + if

Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

On Thu, Sep 11, 2014 at 04:46:48PM +0800, Qiaowei Ren wrote: +static __user void *task_get_bounds_dir(struct task_struct *tsk) +{ + struct xsave_struct *xsave_buf; + + fpu_xsave(tsk-thread.fpu); + xsave_buf = (tsk-thread.fpu.state-xsave); + if (!(xsave_buf-bndcsr.cfg_reg_u

Re: [PATCH] fs: Cleanup string initializations (char[] instead of char *)

On Sat, May 17, 2014 at 05:53:45PM +0100, Al Viro wrote: > On Sat, May 17, 2014 at 05:00:18PM +0200, Manuel Sch?lling wrote: > > Initializations like 'char *foo = "bar"' will create two variables: a static > > string and a pointer (foo) to that static string. Instead 'char foo[] = > > "bar"' > >

Re: [PATCH] fs: Cleanup string initializations (char[] instead of char *)

On Sat, May 17, 2014 at 05:53:45PM +0100, Al Viro wrote: On Sat, May 17, 2014 at 05:00:18PM +0200, Manuel Sch?lling wrote: Initializations like 'char *foo = bar' will create two variables: a static string and a pointer (foo) to that static string. Instead 'char foo[] = bar' will declare

Re: [PATCH 0/5] Volatile Ranges (v12) & LSF-MM discussion fodder

On Wed, Apr 02, 2014 at 10:40:16AM -0700, John Stultz wrote: > On Wed, Apr 2, 2014 at 9:36 AM, Johannes Weiner wrote: > > I'm just dying to hear a "normal" use case then. :) > > So the more "normal" use cause would be marking objects volatile and > then non-volatile w/o accessing them

Re: [PATCH 0/5] Volatile Ranges (v12) LSF-MM discussion fodder

On Wed, Apr 02, 2014 at 10:40:16AM -0700, John Stultz wrote: On Wed, Apr 2, 2014 at 9:36 AM, Johannes Weiner han...@cmpxchg.org wrote: I'm just dying to hear a normal use case then. :) So the more normal use cause would be marking objects volatile and then non-volatile w/o accessing them

Re: [RFC] [PATCH] Pre-emption control for userspace

On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote: > Anything else? If it was possible to make the time remaining in the current timeslice available to userspace through the vdso, the thread could do something like: if (sys_timeleft() < CRITICAL_SECTION_SIZE) yield(); lock(); to

Re: [RFC] [PATCH] Pre-emption control for userspace

On Tue, Mar 04, 2014 at 04:51:15PM -0800, Andi Kleen wrote: Anything else? If it was possible to make the time remaining in the current timeslice available to userspace through the vdso, the thread could do something like: if (sys_timeleft() CRITICAL_SECTION_SIZE) yield(); lock(); to

Re: Update of file offset on write() etc. is non-atomic with I/O

On Fri, Feb 21, 2014 at 07:01:31AM +0100, Michael Kerrisk (man-pages) wrote: > Here's the fulll list from POSIX.1-2008/SUSv4 Section XSI 2.9.7: > > [[ > 2.9.7 Thread Interactions with Regular File Operations > > All of the following functions shall be atomic with respect to each > other in the

Re: Update of file offset on write() etc. is non-atomic with I/O

On Fri, Feb 21, 2014 at 07:01:31AM +0100, Michael Kerrisk (man-pages) wrote: Here's the fulll list from POSIX.1-2008/SUSv4 Section XSI 2.9.7: [[ 2.9.7 Thread Interactions with Regular File Operations All of the following functions shall be atomic with respect to each other in the effects

Re: 3.12: kernel panic when resuming from suspend to RAM (x86_64)

On Sun, Nov 17, 2013 at 11:06:12PM +0100, Borislav Petkov wrote: > and the virtual address in rIP is 8106f5c3, i.e. the same one > as in the photo. Thus, the CALL instruction tries to call the timer > function 'fn' which we pass as an argument to call_timer_fn. > > However, the address

Re: 3.12: kernel panic when resuming from suspend to RAM (x86_64)

On Sun, Nov 17, 2013 at 11:06:12PM +0100, Borislav Petkov wrote: and the virtual address in rIP is 8106f5c3, i.e. the same one as in the photo. Thus, the CALL instruction tries to call the timer function 'fn' which we pass as an argument to call_timer_fn. However, the address we're

Re: [PATCH 0/7] preempt_count rework -v2

On Thu, Sep 12, 2013 at 04:20:40AM +0200, Peter Zijlstra wrote: > On Wed, Sep 11, 2013 at 04:02:14PM -0700, Linus Torvalds wrote: > > On Wed, Sep 11, 2013 at 11:59 AM, Peter Zijlstra > > wrote: > > > > > > OK, stripped it down further, I couldn't quite see how to collapse the > > > unary and

Re: [PATCH 0/7] preempt_count rework -v2

On Thu, Sep 12, 2013 at 04:20:40AM +0200, Peter Zijlstra wrote: On Wed, Sep 11, 2013 at 04:02:14PM -0700, Linus Torvalds wrote: On Wed, Sep 11, 2013 at 11:59 AM, Peter Zijlstra pet...@infradead.org wrote: OK, stripped it down further, I couldn't quite see how to collapse the unary

Re: [PATCH jiffies] Avoid undefined behavior from signed overflow

Quoting "Paul E. McKenney" : On Mon, Jul 29, 2013 at 03:30:35PM +1000, c...@guarana.org wrote: Quoting "Paul E. McKenney" : ... > >Note that the C standard considers the cast from signed to >unsigned to be implementation-defined, see 6.3.1.3p3. ... Don't worry, the case from signed to

Re: [PATCH jiffies] Avoid undefined behavior from signed overflow

Quoting Paul E. McKenney paul...@linux.vnet.ibm.com: On Mon, Jul 29, 2013 at 03:30:35PM +1000, c...@guarana.org wrote: Quoting Paul E. McKenney paul...@linux.vnet.ibm.com: ... Note that the C standard considers the cast from signed to unsigned to be implementation-defined, see 6.3.1.3p3.

[patch] clone.2, execve.2: Describe interaction of execve(2) and CLONE_FILES

Hi Michael, This very small patch against man-pages-3.50 adds a description of the way in which a shared file descriptor table, as created by the CLONE_FILES flag of clone(2), is unshared when a process calls execve(2). It's easy to see this from the source - there's an unshare_files() call

[patch] clone.2, execve.2: Describe interaction of execve(2) and CLONE_FILES

Hi Michael, This very small patch against man-pages-3.50 adds a description of the way in which a shared file descriptor table, as created by the CLONE_FILES flag of clone(2), is unshared when a process calls execve(2). It's easy to see this from the source - there's an unshare_files() call

Re: New system call wanted: fdreopen

Quoting Tristan Wibberley : Why === A common idiom on Linux is to open a file and keep the fd open so that the underlying file can be unlinked from its directory. But if the file needs to be read from several different parts of the codebase then due to the file descriptor having exactly one

Re: New system call wanted: fdreopen

Quoting Tristan Wibberley tristan.wibber...@gmail.com: Why === A common idiom on Linux is to open a file and keep the fd open so that the underlying file can be unlinked from its directory. But if the file needs to be read from several different parts of the codebase then due to the file

Re: [PATCH v1] firmware loader: introduce module parameter to customize fw search path

Quoting Al Viro : On Thu, Oct 25, 2012 at 08:38:25PM -0700, Linus Torvalds wrote: It's valid to cast a non-const pointer to a const one. It's the *other* way around that is invalid. So marking fw_path[] as having 'const char *' elements just means that we won't be changing those elements

Re: [PATCH v1] firmware loader: introduce module parameter to customize fw search path

Quoting Al Viro v...@zeniv.linux.org.uk: On Thu, Oct 25, 2012 at 08:38:25PM -0700, Linus Torvalds wrote: It's valid to cast a non-const pointer to a const one. It's the *other* way around that is invalid. So marking fw_path[] as having 'const char *' elements just means that we won't be