mmotm 2018-03-07-16-19 uploaded

The mm-of-the-moment snapshot 2018-03-07-16-19 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2018-03-07-16-19 uploaded

The mm-of-the-moment snapshot 2018-03-07-16-19 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: [PATCH 07/17] staging: lustre: ptlrpc: change GFP_NOFS to GFP_KERNEL

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > These allocations are performed during initialization, > so they don't need GFP_NOFS. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- >

Re: [PATCH 07/17] staging: lustre: ptlrpc: change GFP_NOFS to GFP_KERNEL

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > These allocations are performed during initialization, > so they don't need GFP_NOFS. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- > drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c |2 +- >

Re: [PATCH 06/17] staging: lustre: get entropy from nid when nid set.

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > When the 'lustre' module is loaded, it gets a list of > net devices and uses the node ids to add entropy > to the prng. This means that the network interfaces need > to be configured before the module is loaded, which prevents >

Re: [PATCH 06/17] staging: lustre: get entropy from nid when nid set.

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > When the 'lustre' module is loaded, it gets a list of > net devices and uses the node ids to add entropy > to the prng. This means that the network interfaces need > to be configured before the module is loaded, which prevents > the module from

Re: [PATCH] configfs: initialize inode with owner

This patch is not correct: When listed with ls, configfs attributes have the uid/gid of the user who list them, but looks wrong. I will test it more and repost. Gwendal. On Tue, Mar 6, 2018 at 7:36 PM, Gwendal Grignou wrote: > From: Sarthak Kukreti

Re: [PATCH] configfs: initialize inode with owner

This patch is not correct: When listed with ls, configfs attributes have the uid/gid of the user who list them, but looks wrong. I will test it more and repost. Gwendal. On Tue, Mar 6, 2018 at 7:36 PM, Gwendal Grignou wrote: > From: Sarthak Kukreti > > Use standard helper to set inode owner

Re: usb: musb: error when trying to unbind musb-hdrc.0.auto

Hi, I suspected that the issue was similar to the one fixed in this commit: 0c3aae9bd59978fb8c3557d7883380bef0f2cfa1 (USB: musb: fix late external abort on suspend) I've applied a similar fix to the musb_remove function (as well as moving musb_platform_exit just before spin_unlock_irqrestore),

Re: usb: musb: error when trying to unbind musb-hdrc.0.auto

Hi, I suspected that the issue was similar to the one fixed in this commit: 0c3aae9bd59978fb8c3557d7883380bef0f2cfa1 (USB: musb: fix late external abort on suspend) I've applied a similar fix to the musb_remove function (as well as moving musb_platform_exit just before spin_unlock_irqrestore),

Re: [PATCH] vsprintf: Remove accidental VLA usage

On Wed, 7 Mar 2018 15:59:27 -0800 Kees Cook wrote: > I didn't want to encourage a global macro that _lacked_ the safety > built into the max*() family, though... thoughts for a reasonable > approach? I think SIMPLE_MAX() is OK.Along with one of /* these */ things ;)

Re: [PATCH] vsprintf: Remove accidental VLA usage

On Wed, 7 Mar 2018 15:59:27 -0800 Kees Cook wrote: > I didn't want to encourage a global macro that _lacked_ the safety > built into the max*() family, though... thoughts for a reasonable > approach? I think SIMPLE_MAX() is OK.Along with one of /* these */ things ;)

[PATCH] floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl

The final field of a floppy_struct is the field "name", which is a pointer to a string in kernel memory. The kernel pointer should not be copied to user memory. The FDGETPRM ioctl copies a floppy_struct to user memory, including the "name" field. This pointer cannot be used by the user, and it

[PATCH] floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl

The final field of a floppy_struct is the field "name", which is a pointer to a string in kernel memory. The kernel pointer should not be copied to user memory. The FDGETPRM ioctl copies a floppy_struct to user memory, including the "name" field. This pointer cannot be used by the user, and it

Re: [PATCH] ipmi:ssif: Fix double probe from tryacpi and trydmi

On 03/07/2018 07:34 AM, Corey Minyard wrote: On 03/06/2018 11:49 PM, Jiandi An wrote: IPMI SSIF driver's parameter tryacpi and trydmi both are set to true.  The addition of IPMI DMI driver to create platform device for each IPMI device causes SSIF probe to be done twice on the same SMB I2C

Re: [PATCH] ipmi:ssif: Fix double probe from tryacpi and trydmi

On 03/07/2018 07:34 AM, Corey Minyard wrote: On 03/06/2018 11:49 PM, Jiandi An wrote: IPMI SSIF driver's parameter tryacpi and trydmi both are set to true.  The addition of IPMI DMI driver to create platform device for each IPMI device causes SSIF probe to be done twice on the same SMB I2C

[PATCH] hugetlbfs: check for pgoff value overflow

A vma with vm_pgoff large enough to overflow a loff_t type when converted to a byte offset can be passed via the remap_file_pages system call. The hugetlbfs mmap routine uses the byte offset to calculate reservations and file size. A sequence such as: mmap(0x20a0, 0x60, 0, 0x66033, -1,

[PATCH] hugetlbfs: check for pgoff value overflow

A vma with vm_pgoff large enough to overflow a loff_t type when converted to a byte offset can be passed via the remap_file_pages system call. The hugetlbfs mmap routine uses the byte offset to calculate reservations and file size. A sequence such as: mmap(0x20a0, 0x60, 0, 0x66033, -1,

Re: [PATCH] vsprintf: Remove accidental VLA usage

On Wed, Mar 7, 2018 at 3:42 PM, Tycho Andersen wrote: > Hi Kees, > > On Wed, Mar 07, 2018 at 03:07:14PM -0800, Kees Cook wrote: >> The "sym" calculation is actually a fixed size, but since the max() >> macro uses some extensive tricks for safety, it ends up looking like a >>

Re: [PATCH] vsprintf: Remove accidental VLA usage

On Wed, Mar 7, 2018 at 3:42 PM, Tycho Andersen wrote: > Hi Kees, > > On Wed, Mar 07, 2018 at 03:07:14PM -0800, Kees Cook wrote: >> The "sym" calculation is actually a fixed size, but since the max() >> macro uses some extensive tricks for safety, it ends up looking like a >> variable size. This

Re: [PATCH v2] block: sed-opal: fix u64 short atom length

On Wed, Mar 07, 2018 at 04:24:29PM -0700, Scott Bauer wrote: > On Wed, Mar 07, 2018 at 05:55:56PM +0100, Jonas Rabenstein wrote: > > The length must be given as bytes and not as 4 bit tuples. > > > > Signed-off-by: Jonas Rabenstein > > --- > > v2: > >

Re: [PATCH v2] block: sed-opal: fix u64 short atom length

On Wed, Mar 07, 2018 at 04:24:29PM -0700, Scott Bauer wrote: > On Wed, Mar 07, 2018 at 05:55:56PM +0100, Jonas Rabenstein wrote: > > The length must be given as bytes and not as 4 bit tuples. > > > > Signed-off-by: Jonas Rabenstein > > --- > > v2: > > - use fls64 > > - shorten loop body > >

[PATCH v3 1/5] irq: Add CONFIG_GENERIC_IRQ_MULTI_HANDLER

It looks like the arm irqchip registration mechanism has been copied into a handful of ports, including arm64 and openrisc. I want to use this in the RISC-V port, so I thought it would be good to make this generic instead. This patch copies the arm definition of CONFIG_MULTI_IRQ_HANDLER into

[PATCH v3 1/5] irq: Add CONFIG_GENERIC_IRQ_MULTI_HANDLER

It looks like the arm irqchip registration mechanism has been copied into a handful of ports, including arm64 and openrisc. I want to use this in the RISC-V port, so I thought it would be good to make this generic instead. This patch copies the arm definition of CONFIG_MULTI_IRQ_HANDLER into

Make set_handle_irq and handle_arch_irq generic, v3

This is my third version of this patch set, but the original cover letter is still the most relevant description I can come up with. This patch set has been sitting around for a while, but it got a bit lost in the shuffle. In RISC-V land we currently couple do_IRQ (the C entry point

Make set_handle_irq and handle_arch_irq generic, v3

This is my third version of this patch set, but the original cover letter is still the most relevant description I can come up with. This patch set has been sitting around for a while, but it got a bit lost in the shuffle. In RISC-V land we currently couple do_IRQ (the C entry point

[PATCH v3 2/5] RISC-V: Move to the new GENERIC_IRQ_MULTI_HANDLER handler

The old mechanism for handling IRQs on RISC-V was pretty ugly: the arch code looked at the Kconfig entry for our first-level irqchip driver and called into it directly. This patch uses the new generic IRQ handling infastructure, which essentially just deletes a bunch of code. This does add an

[PATCH v3 2/5] RISC-V: Move to the new GENERIC_IRQ_MULTI_HANDLER handler

The old mechanism for handling IRQs on RISC-V was pretty ugly: the arch code looked at the Kconfig entry for our first-level irqchip driver and called into it directly. This patch uses the new generic IRQ handling infastructure, which essentially just deletes a bunch of code. This does add an

[PATCH v3 3/5] arm: Convert to GENERIC_IRQ_MULTI_HANDLER

This converts the ARM port to use the recently added GENERIC_IRQ_MULTI_HANDLER, which is essentially just a copy of ARM's existhing MULTI_IRQ_HANDLER. The only changes are: * handle_arch_irq is now defined in a generic C file instead of an arm-specific assembly file. * handle_arch_irq is not

[PATCH v3 5/5] openrisc: Use the new GENERIC_IRQ_MULTI_HANDLER

It appears that openrisc copied arm64's GENERIC_IRQ_MULTI_HANDLER code (which came from arm). I wanted to make this generic so I could use it in the RISC-V port. This patch converts the openrisc code to use the generic version. Acked-by: Stafford Horne Signed-off-by: Palmer

[PATCH v3 3/5] arm: Convert to GENERIC_IRQ_MULTI_HANDLER

This converts the ARM port to use the recently added GENERIC_IRQ_MULTI_HANDLER, which is essentially just a copy of ARM's existhing MULTI_IRQ_HANDLER. The only changes are: * handle_arch_irq is now defined in a generic C file instead of an arm-specific assembly file. * handle_arch_irq is not

[PATCH v3 5/5] openrisc: Use the new GENERIC_IRQ_MULTI_HANDLER

It appears that openrisc copied arm64's GENERIC_IRQ_MULTI_HANDLER code (which came from arm). I wanted to make this generic so I could use it in the RISC-V port. This patch converts the openrisc code to use the generic version. Acked-by: Stafford Horne Signed-off-by: Palmer Dabbelt ---

Re: [PATCH 4.15 000/122] 4.15.8-stable review

On 03/07/2018 12:36 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.8 release. > There are 122 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

[PATCH v3 4/5] arm64: Use the new GENERIC_IRQ_MULTI_HANDLER

It appears arm64 copied arm's GENERIC_IRQ_MULTI_HANDLER code, but made it unconditional. I wanted to make this generic so it could be used by the RISC-V port. This patch converts the arm64 code to use the new generic code, which simply consists of deleting the arm64 code and setting

Re: [PATCH 4.15 000/122] 4.15.8-stable review

On 03/07/2018 12:36 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.8 release. > There are 122 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

[PATCH v3 4/5] arm64: Use the new GENERIC_IRQ_MULTI_HANDLER

It appears arm64 copied arm's GENERIC_IRQ_MULTI_HANDLER code, but made it unconditional. I wanted to make this generic so it could be used by the RISC-V port. This patch converts the arm64 code to use the new generic code, which simply consists of deleting the arm64 code and setting

Re: [PATCH 4.14 000/110] 4.14.25-stable review

On 03/07/2018 12:37 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.25 release. > There are 110 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

Re: [PATCH 4.14 000/110] 4.14.25-stable review

On 03/07/2018 12:37 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.25 release. > There are 110 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

Re: [PATCH] vsprintf: Remove accidental VLA usage

On Wed, Mar 7, 2018 at 3:40 PM, Andrew Morton wrote: > On Wed, 7 Mar 2018 15:07:14 -0800 Kees Cook wrote: > >> The "sym" calculation is actually a fixed size, but since the max() >> macro uses some extensive tricks for safety, it ends up looking

Re: [PATCH] vsprintf: Remove accidental VLA usage

On Wed, Mar 7, 2018 at 3:40 PM, Andrew Morton wrote: > On Wed, 7 Mar 2018 15:07:14 -0800 Kees Cook wrote: > >> The "sym" calculation is actually a fixed size, but since the max() >> macro uses some extensive tricks for safety, it ends up looking like a >> variable size. This replaces max() with

[git pull] Input updates for v4.16-rc4

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem: - we are reverting patch that was switched touchpad on Lenovo T460P over to native RMI because on these boxes BIOS messes up with SMBus

[git pull] Input updates for v4.16-rc4

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem: - we are reverting patch that was switched touchpad on Lenovo T460P over to native RMI because on these boxes BIOS messes up with SMBus

[patch] mm, oom: remove 3% bonus for CAP_SYS_ADMIN processes

Since the 2.6 kernel, the oom killer has slightly biased away from CAP_SYS_ADMIN processes by discounting some of its memory usage in comparison to other processes. This has always been implicit and nothing exactly relies on the behavior. Gaurav notices that __task_cred() can dereference a

[patch] mm, oom: remove 3% bonus for CAP_SYS_ADMIN processes

Since the 2.6 kernel, the oom killer has slightly biased away from CAP_SYS_ADMIN processes by discounting some of its memory usage in comparison to other processes. This has always been implicit and nothing exactly relies on the behavior. Gaurav notices that __task_cred() can dereference a

Re: [PATCH v2] block: sed-opal: fix u64 short atom length

On Wed, Mar 07, 2018 at 05:55:56PM +0100, Jonas Rabenstein wrote: > The length must be given as bytes and not as 4 bit tuples. > > Signed-off-by: Jonas Rabenstein > --- > v2: > - use fls64 > - shorten loop body > --- > block/sed-opal.c | 11

Re: [PATCH v2] block: sed-opal: fix u64 short atom length

On Wed, Mar 07, 2018 at 05:55:56PM +0100, Jonas Rabenstein wrote: > The length must be given as bytes and not as 4 bit tuples. > > Signed-off-by: Jonas Rabenstein > --- > v2: > - use fls64 > - shorten loop body > --- > block/sed-opal.c | 11 --- > 1 file changed, 4 insertions(+), 7

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Wed, Mar 7, 2018 at 6:41 PM, Paul Moore wrote: > On Wed, Mar 7, 2018 at 11:48 AM, Jiri Kosina wrote: >> On Wed, 7 Mar 2018, Andy Lutomirski wrote: >>> Wow, this was a long time ago. >> >> Oh yeah; but it now resurfaced on our side, as we are of course

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Wed, Mar 7, 2018 at 6:41 PM, Paul Moore wrote: > On Wed, Mar 7, 2018 at 11:48 AM, Jiri Kosina wrote: >> On Wed, 7 Mar 2018, Andy Lutomirski wrote: >>> Wow, this was a long time ago. >> >> Oh yeah; but it now resurfaced on our side, as we are of course receiving >> a lot of requests with

Re: [PATCH] vsprintf: Remove accidental VLA usage

Hi Kees, On Wed, Mar 07, 2018 at 03:07:14PM -0800, Kees Cook wrote: > The "sym" calculation is actually a fixed size, but since the max() > macro uses some extensive tricks for safety, it ends up looking like a > variable size. This replaces max() with a simple max macro which is > sufficient for

Re: [PATCH] vsprintf: Remove accidental VLA usage

Hi Kees, On Wed, Mar 07, 2018 at 03:07:14PM -0800, Kees Cook wrote: > The "sym" calculation is actually a fixed size, but since the max() > macro uses some extensive tricks for safety, it ends up looking like a > variable size. This replaces max() with a simple max macro which is > sufficient for

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Wed, Mar 7, 2018 at 11:48 AM, Jiri Kosina wrote: > On Wed, 7 Mar 2018, Andy Lutomirski wrote: >> Wow, this was a long time ago. > > Oh yeah; but it now resurfaced on our side, as we are of course receiving > a lot of requests with respect to making syscall performance great

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Wed, Mar 7, 2018 at 11:48 AM, Jiri Kosina wrote: > On Wed, 7 Mar 2018, Andy Lutomirski wrote: >> Wow, this was a long time ago. > > Oh yeah; but it now resurfaced on our side, as we are of course receiving > a lot of requests with respect to making syscall performance great again > :) Ooof.

Re: [PATCH] vsprintf: Remove accidental VLA usage

On Wed, 7 Mar 2018 15:07:14 -0800 Kees Cook wrote: > The "sym" calculation is actually a fixed size, but since the max() > macro uses some extensive tricks for safety, it ends up looking like a > variable size. This replaces max() with a simple max macro which is >

Re: [PATCH] vsprintf: Remove accidental VLA usage

On Wed, 7 Mar 2018 15:07:14 -0800 Kees Cook wrote: > The "sym" calculation is actually a fixed size, but since the max() > macro uses some extensive tricks for safety, it ends up looking like a > variable size. This replaces max() with a simple max macro which is > sufficient for the calculation

Re: [PATCH] bloat-o-meter: fix typo in help

On Wed, Feb 14, 2018 at 6:47 PM, Matteo Croce wrote: > the bloat-o-meter script has two typos in the help, fix both. > > Fixes: 192efb7a1f9b ("bloat-o-meter: provide 3 different arguments for data, > function and All") > Signed-off-by: Matteo Croce > --- >

Re: [PATCH] bloat-o-meter: fix typo in help

On Wed, Feb 14, 2018 at 6:47 PM, Matteo Croce wrote: > the bloat-o-meter script has two typos in the help, fix both. > > Fixes: 192efb7a1f9b ("bloat-o-meter: provide 3 different arguments for data, > function and All") > Signed-off-by: Matteo Croce > --- > scripts/bloat-o-meter | 2 +- > 1

Re: [PATCH] rtc: remove VLA usage

On 03/07/2018 05:12 PM, Alexandre Belloni wrote: On 07/03/2018 at 17:09:22 -0600, Gustavo A. R. Silva wrote: On 03/07/2018 05:01 PM, Alexandre Belloni wrote: On 07/03/2018 at 16:39:51 -0600, Gustavo A. R. Silva wrote: Hi Alexandre, On 03/07/2018 03:25 PM, Alexandre Belloni wrote: On

Re: [RFC/RFT][PATCH v2 2/6] sched: idle: Do not stop the tick upfront in the idle loop

On Tue, Mar 06, 2018 at 10:02:15AM +0100, Rafael J. Wysocki wrote: > Index: linux-pm/kernel/sched/idle.c > === > --- linux-pm.orig/kernel/sched/idle.c > +++ linux-pm/kernel/sched/idle.c > @@ -220,13 +220,17 @@ static void

Re: [RFC/RFT][PATCH v2 2/6] sched: idle: Do not stop the tick upfront in the idle loop

On Tue, Mar 06, 2018 at 10:02:15AM +0100, Rafael J. Wysocki wrote: > Index: linux-pm/kernel/sched/idle.c > === > --- linux-pm.orig/kernel/sched/idle.c > +++ linux-pm/kernel/sched/idle.c > @@ -220,13 +220,17 @@ static void

Re: [PATCH] rtc: remove VLA usage

On 03/07/2018 05:12 PM, Alexandre Belloni wrote: On 07/03/2018 at 17:09:22 -0600, Gustavo A. R. Silva wrote: On 03/07/2018 05:01 PM, Alexandre Belloni wrote: On 07/03/2018 at 16:39:51 -0600, Gustavo A. R. Silva wrote: Hi Alexandre, On 03/07/2018 03:25 PM, Alexandre Belloni wrote: On

Re: [PATCH v2 (RESEND)] lockdep: Fix fs_reclaim warning.

On Wed, 28 Feb 2018 06:50:02 +0900 Tetsuo Handa wrote: > > This warning is caused by commit d92a8cfcb37ecd13 ("locking/lockdep: Rework > FS_RECLAIM annotation") which replaced lockdep_set_current_reclaim_state()/ > lockdep_clear_current_reclaim_state() in

Re: [PATCH v2 (RESEND)] lockdep: Fix fs_reclaim warning.

On Wed, 28 Feb 2018 06:50:02 +0900 Tetsuo Handa wrote: > > This warning is caused by commit d92a8cfcb37ecd13 ("locking/lockdep: Rework > FS_RECLAIM annotation") which replaced lockdep_set_current_reclaim_state()/ > lockdep_clear_current_reclaim_state() in __perform_reclaim() and >

Re: [PATCH] ubi: Reject MLC NAND

Hi Boris, On Wed, Mar 07, 2018 at 11:30:57PM +0100, Boris Brezillon wrote: > I have one simple question: did you ever play with MLC NANDs or are you > just trolling? If you had, like Richard and I did when working on MLC > support, I'm pretty sure you wouldn't play this "don't backport to >

Re: [PATCH] ubi: Reject MLC NAND

Hi Boris, On Wed, Mar 07, 2018 at 11:30:57PM +0100, Boris Brezillon wrote: > I have one simple question: did you ever play with MLC NANDs or are you > just trolling? If you had, like Richard and I did when working on MLC > support, I'm pretty sure you wouldn't play this "don't backport to >

Re: [PATCH v2] earlycon: Allow specifying a uartclk in options

On Thu, Mar 1, 2018 at 11:43 AM Daniel Kurtz wrote: > Currently when an earlycon is registered, the uartclk is assumed to be > BASE_BAUD * 16 = 1843200. If a baud rate is specified in the earlycon > options, then 8250_early's init_port will program the UART clock divider >

Re: [PATCH v2] earlycon: Allow specifying a uartclk in options

On Thu, Mar 1, 2018 at 11:43 AM Daniel Kurtz wrote: > Currently when an earlycon is registered, the uartclk is assumed to be > BASE_BAUD * 16 = 1843200. If a baud rate is specified in the earlycon > options, then 8250_early's init_port will program the UART clock divider > registers based on

Re: linux-next: manual merge of the selinux tree with the net-next tree

On Wed, Mar 7, 2018 at 3:26 PM, David Miller wrote: > From: Paul Moore > Date: Wed, 7 Mar 2018 15:20:33 -0500 > >>> So you would only have to wait until my tree went in before >>> sending your pull request. >> >> So you would want me to rebase

Re: linux-next: manual merge of the selinux tree with the net-next tree

On Wed, Mar 7, 2018 at 3:26 PM, David Miller wrote: > From: Paul Moore > Date: Wed, 7 Mar 2018 15:20:33 -0500 > >>> So you would only have to wait until my tree went in before >>> sending your pull request. >> >> So you would want me to rebase selinux/next on top of Linus' tree in >> the middle

[PATCH 1/2] x86/Kconfig: Add config for specifying BASE_BAUD

Not all x86 CPUs have UARTs that use a baud reference clock (BASE_BAUD) of 115200 = 1843200 / 16. For example, the UARTs on AMD Carrizo and later use a fixed input clock of 4800, and hence require BASE_BAUD=300. The BASE_BAUD value is used by the generic earlycon driver to compute the

[PATCH 2/2] x86/Kconfig: Add config to allow not defining old serial ports

The old_serial_port global array in 8250_core is supposed to hold an entry for each serial port on the system that cannot be discovered via a standard enumeration mechanism (aka ACPI/PCI/DTS). The array is populated at compile-time from the value specified in the SERIAL_PORT_DFNS macro. This

[PATCH 1/2] x86/Kconfig: Add config for specifying BASE_BAUD

Not all x86 CPUs have UARTs that use a baud reference clock (BASE_BAUD) of 115200 = 1843200 / 16. For example, the UARTs on AMD Carrizo and later use a fixed input clock of 4800, and hence require BASE_BAUD=300. The BASE_BAUD value is used by the generic earlycon driver to compute the

[PATCH 2/2] x86/Kconfig: Add config to allow not defining old serial ports

The old_serial_port global array in 8250_core is supposed to hold an entry for each serial port on the system that cannot be discovered via a standard enumeration mechanism (aka ACPI/PCI/DTS). The array is populated at compile-time from the value specified in the SERIAL_PORT_DFNS macro. This

Re: [PATCH 2/2] x86/mm: implement free pmd/pte page interfaces

On Wed, 2018-03-07 at 15:01 -0800, Andrew Morton wrote: > On Wed, 7 Mar 2018 11:32:27 -0700 Toshi Kani wrote: > > > Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which > > clear a given pud/pmd entry and free up lower level page table(s). > > Address range

Re: [PATCH 2/2] x86/mm: implement free pmd/pte page interfaces

On Wed, 2018-03-07 at 15:01 -0800, Andrew Morton wrote: > On Wed, 7 Mar 2018 11:32:27 -0700 Toshi Kani wrote: > > > Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which > > clear a given pud/pmd entry and free up lower level page table(s). > > Address range associated with the

Re: [PATCH] kbuild: Handle builtin dtb files containing hyphens

On 03/07/18 12:25, James Hogan wrote: > On Wed, Mar 07, 2018 at 12:11:41PM -0800, Frank Rowand wrote: >> I initially misread the patch description (and imagined an entirely >> different problem). >> >> >> On 03/07/18 06:06, James Hogan wrote: >>> On dtb files which contain hyphens, the dt_S_dtb

Re: [PATCH] kbuild: Handle builtin dtb files containing hyphens

On 03/07/18 12:25, James Hogan wrote: > On Wed, Mar 07, 2018 at 12:11:41PM -0800, Frank Rowand wrote: >> I initially misread the patch description (and imagined an entirely >> different problem). >> >> >> On 03/07/18 06:06, James Hogan wrote: >>> On dtb files which contain hyphens, the dt_S_dtb

Re: [RFC/RFT][PATCH v2 1/6] time: tick-sched: Reorganize idle tick management code

On Tue, Mar 06, 2018 at 10:02:01AM +0100, Rafael J. Wysocki wrote: > Index: linux-pm/kernel/time/tick-sched.c > === > --- linux-pm.orig/kernel/time/tick-sched.c > +++ linux-pm/kernel/time/tick-sched.c > + > +/** > + *

Re: [RFC/RFT][PATCH v2 1/6] time: tick-sched: Reorganize idle tick management code

On Tue, Mar 06, 2018 at 10:02:01AM +0100, Rafael J. Wysocki wrote: > Index: linux-pm/kernel/time/tick-sched.c > === > --- linux-pm.orig/kernel/time/tick-sched.c > +++ linux-pm/kernel/time/tick-sched.c > + > +/** > + *

Re: [RFC] android: ion: How to properly clean caches for uncached allocations

On 02/28/2018 09:18 PM, Liam Mark wrote: The issue: Currently in ION if you allocate uncached memory it is possible that there are still dirty lines in the cache. And often these dirty lines in the cache are the zeros which were meant to clear out any sensitive kernel data. What this means is

Re: [RFC] android: ion: How to properly clean caches for uncached allocations

On 02/28/2018 09:18 PM, Liam Mark wrote: The issue: Currently in ION if you allocate uncached memory it is possible that there are still dirty lines in the cache. And often these dirty lines in the cache are the zeros which were meant to clear out any sensitive kernel data. What this means is

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

On Wed, Mar 7, 2018 at 1:46 PM, Dave Hansen wrote: > > From: Dave Hansen > > I think we need to soften the language a bit. It might scare folks > off, especially the: > > We prefer to fully disclose the bug as soon as possible.

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

On Wed, Mar 7, 2018 at 1:46 PM, Dave Hansen wrote: > > From: Dave Hansen > > I think we need to soften the language a bit. It might scare folks > off, especially the: > > We prefer to fully disclose the bug as soon as possible. > > which is not really the case. Linus says: > >

[PATCH] rtc: Add useful timestamp definitions

Add commonly used timestamps for range definition. Signed-off-by: Alexandre Belloni --- include/linux/rtc.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/linux/rtc.h b/include/linux/rtc.h index 82a3038f16ab..4c007f69082f 100644 ---

[PATCH] rtc: Add useful timestamp definitions

Add commonly used timestamps for range definition. Signed-off-by: Alexandre Belloni --- include/linux/rtc.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/linux/rtc.h b/include/linux/rtc.h index 82a3038f16ab..4c007f69082f 100644 --- a/include/linux/rtc.h +++

Re: [PATCH] rtc: remove VLA usage

On 07/03/2018 at 17:09:22 -0600, Gustavo A. R. Silva wrote: > > > On 03/07/2018 05:01 PM, Alexandre Belloni wrote: > > On 07/03/2018 at 16:39:51 -0600, Gustavo A. R. Silva wrote: > > > Hi Alexandre, > > > > > > On 03/07/2018 03:25 PM, Alexandre Belloni wrote: > > > > On 07/03/2018 at 14:11:33

Re: [PATCH] rtc: remove VLA usage

On 07/03/2018 at 17:09:22 -0600, Gustavo A. R. Silva wrote: > > > On 03/07/2018 05:01 PM, Alexandre Belloni wrote: > > On 07/03/2018 at 16:39:51 -0600, Gustavo A. R. Silva wrote: > > > Hi Alexandre, > > > > > > On 03/07/2018 03:25 PM, Alexandre Belloni wrote: > > > > On 07/03/2018 at 14:11:33

Re: [PATCH] rtc: remove VLA usage

On 03/07/2018 05:01 PM, Alexandre Belloni wrote: On 07/03/2018 at 16:39:51 -0600, Gustavo A. R. Silva wrote: Hi Alexandre, On 03/07/2018 03:25 PM, Alexandre Belloni wrote: On 07/03/2018 at 14:11:33 -0600, Gustavo A. R. Silva wrote: In preparation to enabling -Wvla, remove VLA and replace

Re: [PATCH] rtc: remove VLA usage

On 03/07/2018 05:01 PM, Alexandre Belloni wrote: On 07/03/2018 at 16:39:51 -0600, Gustavo A. R. Silva wrote: Hi Alexandre, On 03/07/2018 03:25 PM, Alexandre Belloni wrote: On 07/03/2018 at 14:11:33 -0600, Gustavo A. R. Silva wrote: In preparation to enabling -Wvla, remove VLA and replace

Re: [PATCH][RESEND] block: sed-opal: fix response string extraction

On Tue, Mar 06, 2018 at 04:23:24PM -0800, Derrick, Jonathan wrote: > This looks correct. > > Adding my Ack unless Scott has objections > > Acked-by: Jonathan Derrick Reviewed-by: Scott Bauer Nice catch Jonas! Sorry you had to resend, my

Re: [PATCH][RESEND] block: sed-opal: fix response string extraction

On Tue, Mar 06, 2018 at 04:23:24PM -0800, Derrick, Jonathan wrote: > This looks correct. > > Adding my Ack unless Scott has objections > > Acked-by: Jonathan Derrick Reviewed-by: Scott Bauer Nice catch Jonas! Sorry you had to resend, my message filtering was a little too agressive and this

[PATCH] vsprintf: Remove accidental VLA usage

The "sym" calculation is actually a fixed size, but since the max() macro uses some extensive tricks for safety, it ends up looking like a variable size. This replaces max() with a simple max macro which is sufficient for the calculation of the array size. Seen with -Wvla. Fixed as part of the

[PATCH] vsprintf: Remove accidental VLA usage

The "sym" calculation is actually a fixed size, but since the max() macro uses some extensive tricks for safety, it ends up looking like a variable size. This replaces max() with a simple max macro which is sufficient for the calculation of the array size. Seen with -Wvla. Fixed as part of the

Re: [PATCH 1/2] mm/vmalloc: Add interfaces to free unused page table

On Wed, 2018-03-07 at 14:54 -0800, Andrew Morton wrote: > On Wed, 7 Mar 2018 11:32:26 -0700 Toshi Kani wrote: > > > On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() > > may create pud/pmd mappings. Kernel panic was observed on arm64 > > systems with

Re: [PATCH 1/2] mm/vmalloc: Add interfaces to free unused page table

On Wed, 2018-03-07 at 14:54 -0800, Andrew Morton wrote: > On Wed, 7 Mar 2018 11:32:26 -0700 Toshi Kani wrote: > > > On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() > > may create pud/pmd mappings. Kernel panic was observed on arm64 > > systems with Cortex-A75 in the following

Re: [PATCH] rtc: remove VLA usage

On 07/03/2018 at 16:39:51 -0600, Gustavo A. R. Silva wrote: > Hi Alexandre, > > On 03/07/2018 03:25 PM, Alexandre Belloni wrote: > > On 07/03/2018 at 14:11:33 -0600, Gustavo A. R. Silva wrote: > > > In preparation to enabling -Wvla, remove VLA and replace it > > > with a fixed-length array

Re: [PATCH] rtc: remove VLA usage

On 07/03/2018 at 16:39:51 -0600, Gustavo A. R. Silva wrote: > Hi Alexandre, > > On 03/07/2018 03:25 PM, Alexandre Belloni wrote: > > On 07/03/2018 at 14:11:33 -0600, Gustavo A. R. Silva wrote: > > > In preparation to enabling -Wvla, remove VLA and replace it > > > with a fixed-length array

Re: [PATCH 2/2] x86/mm: implement free pmd/pte page interfaces

On Wed, 7 Mar 2018 11:32:27 -0700 Toshi Kani wrote: > Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which > clear a given pud/pmd entry and free up lower level page table(s). > Address range associated with the pud/pmd entry must have been purged > by INVLPG.

Re: [PATCH 2/2] x86/mm: implement free pmd/pte page interfaces

On Wed, 7 Mar 2018 11:32:27 -0700 Toshi Kani wrote: > Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which > clear a given pud/pmd entry and free up lower level page table(s). > Address range associated with the pud/pmd entry must have been purged > by INVLPG. OK, now we have

Re: [PATCH 1/2] mm/vmalloc: Add interfaces to free unused page table

On Wed, 7 Mar 2018 11:32:26 -0700 Toshi Kani wrote: > On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() > may create pud/pmd mappings. Kernel panic was observed on arm64 > systems with Cortex-A75 in the following steps as described by > Hanjun Guo. > > 1.

Re: [PATCH 1/2] mm/vmalloc: Add interfaces to free unused page table

On Wed, 7 Mar 2018 11:32:26 -0700 Toshi Kani wrote: > On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() > may create pud/pmd mappings. Kernel panic was observed on arm64 > systems with Cortex-A75 in the following steps as described by > Hanjun Guo. > > 1. ioremap a 4K size,

<    10   11   12   13   14   15   16   17   18   19   >