Re: [PATCH 4.9 00/14] 4.9.50-stable review

On Wed, Sep 13, 2017 at 02:30:46PM -0700, Greg Kroah-Hartman wrote: > > Yes. I don't recall if it is a direct --force or if you would have to > > remove the original tag first (with git push :refs/tags/). > > Ah, but then if someone had pulled the old tag, they would have to > delete it locally

auxdisplay: charlcd: properly restore atomic counter on error path

re (modulo the renamed atomic counter) but I can provide a tested backport if desired. ] Fixes: f4757af85 # 3.19-rc1 Cc: sta...@vger.kernel.org Cc: Mariusz Gorski <marius.gor...@gmail.com> Cc: Geert Uytterhoeven <ge...@linux-m68k.org> Cc: Miguel Ojeda Sandonis <miguel.ojeda.sando...@gmail.

auxdisplay: charlcd: properly restore atomic counter on error path

re (modulo the renamed atomic counter) but I can provide a tested backport if desired. ] Fixes: f4757af85 # 3.19-rc1 Cc: sta...@vger.kernel.org Cc: Mariusz Gorski Cc: Geert Uytterhoeven Cc: Miguel Ojeda Sandonis Signed-off-by: Willy Tarreau --- drivers/auxdisplay/charlcd.c | 11 +-- drivers/

Re: [PATCH v3] leds/trigger/activity: add a system activity LED trigger

Hi Jacek, On Tue, Aug 29, 2017 at 10:44:03PM +0200, Jacek Anaszewski wrote: > Applied to the for-4.15 branch of linux-leds.git. Great, thanks! Willy

Re: [PATCH v3] leds/trigger/activity: add a system activity LED trigger

Hi Jacek, On Tue, Aug 29, 2017 at 10:44:03PM +0200, Jacek Anaszewski wrote: > Applied to the for-4.15 branch of linux-leds.git. Great, thanks! Willy

Re: [PATCH] leds/trigger/activity: add a system activity LED trigger

ers/leds/trigger/ledtrig-activity.c > > @@ -0,0 +1,297 @@ > > +/* > > + * Activity LED trigger > > + * > > + * Copyright (C) 2017 Willy Tarreau <w...@1wt.eu> > > + * Partially based on Atsushi Nemoto's ledtrig-heartbeat.c. > > + * > > + * This program is free software;

Re: [PATCH] leds/trigger/activity: add a system activity LED trigger

ers/leds/trigger/ledtrig-activity.c > > @@ -0,0 +1,297 @@ > > +/* > > + * Activity LED trigger > > + * > > + * Copyright (C) 2017 Willy Tarreau > > + * Partially based on Atsushi Nemoto's ledtrig-heartbeat.c. > > + * > > + * This program is free software; you ca

Re: [PATCH] leds/trigger/activity: add a system activity LED trigger

to this, but here's a new version which works on 4.13-rc6 by not relying on jiffies anymore. Thanks! Willy >From 655256adb790590bbc0c35a9e34bf0a22ea95b5d Mon Sep 17 00:00:00 2001 From: Willy Tarreau <w...@1wt.eu> Date: Fri, 10 Feb 2017 19:45:07 +0100 Subject: leds/trigger/activity: add a sys

Re: [PATCH] leds/trigger/activity: add a system activity LED trigger

to this, but here's a new version which works on 4.13-rc6 by not relying on jiffies anymore. Thanks! Willy >From 655256adb790590bbc0c35a9e34bf0a22ea95b5d Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Fri, 10 Feb 2017 19:45:07 +0100 Subject: leds/trigger/activity: add a system activity LED tr

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 08:09:50AM -0400, Theodore Ts'o wrote: > On Tue, Aug 15, 2017 at 10:05:46AM +0200, Ingo Molnar wrote: > > > > * Willy Tarreau <w...@1wt.eu> wrote: > > > > > > > > > > Nowadays we could use similar methods using RDTSC pr

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 08:09:50AM -0400, Theodore Ts'o wrote: > On Tue, Aug 15, 2017 at 10:05:46AM +0200, Ingo Molnar wrote: > > > > * Willy Tarreau wrote: > > > > > > > > > > Nowadays we could use similar methods using RDTSC providing more > &

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 09:42:54AM +0200, Ingo Molnar wrote: > > * Willy Tarreau <w...@1wt.eu> wrote: > > > Nowadays we could use similar methods using RDTSC providing more accurate > > counting. This doesn't provide a lot of entropy of course, given that a > >

Re: early x86 unseeded randomness

On Tue, Aug 15, 2017 at 09:42:54AM +0200, Ingo Molnar wrote: > > * Willy Tarreau wrote: > > > Nowadays we could use similar methods using RDTSC providing more accurate > > counting. This doesn't provide a lot of entropy of course, given that a > > 2 GHz machine

Re: early x86 unseeded randomness

Hi Ted, On Mon, Aug 14, 2017 at 09:31:24PM -0400, Theodore Ts'o wrote: > The real fix is to do what OpenBSD does, which is to teach the > bootloader (e.g., grub) to read from some file such as > /var/lib/urandom/random-seed, and then to have the init scripts > overwrite it with a new set of

Re: early x86 unseeded randomness

Hi Ted, On Mon, Aug 14, 2017 at 09:31:24PM -0400, Theodore Ts'o wrote: > The real fix is to do what OpenBSD does, which is to teach the > bootloader (e.g., grub) to read from some file such as > /var/lib/urandom/random-seed, and then to have the init scripts > overwrite it with a new set of

Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53?

On Tue, Aug 08, 2017 at 05:12:03PM -0500, Rob Landley wrote: > If your rootfs has a size= in /proc/mounts it's tmpfs, ala: > > rootfs / rootfs rw,size=126564k,nr_inodes=31641 0 0 You're right, I have it and thought about it. Anyway the point is that it works transparently for me. Apparently

Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53?

On Tue, Aug 08, 2017 at 05:12:03PM -0500, Rob Landley wrote: > If your rootfs has a size= in /proc/mounts it's tmpfs, ala: > > rootfs / rootfs rw,size=126564k,nr_inodes=31641 0 0 You're right, I have it and thought about it. Anyway the point is that it works transparently for me. Apparently

Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53?

On Tue, Aug 08, 2017 at 03:18:19PM +0200, Thomas Meyer wrote: > On Tue, Aug 08, 2017 at 02:04:42PM +0200, Willy Tarreau wrote: > > Hi Thomas, > > > > On Tue, Aug 08, 2017 at 01:46:25PM +0200, Thomas Meyer wrote: > > > Hi, > > > > > > did the commi

Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53?

On Tue, Aug 08, 2017 at 03:18:19PM +0200, Thomas Meyer wrote: > On Tue, Aug 08, 2017 at 02:04:42PM +0200, Willy Tarreau wrote: > > Hi Thomas, > > > > On Tue, Aug 08, 2017 at 01:46:25PM +0200, Thomas Meyer wrote: > > > Hi, > > > > > > did the commi

Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53?

Hi Thomas, On Tue, Aug 08, 2017 at 01:46:25PM +0200, Thomas Meyer wrote: > Hi, > > did the commit 6e19eded3684dc184181093af3bff2ff440f5b53 break a linux kernel > build with an included ramdisk? > > As fas as I understand you must expliclity add rootfstype=ramfs to the kernel > command line to

Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53?

Hi Thomas, On Tue, Aug 08, 2017 at 01:46:25PM +0200, Thomas Meyer wrote: > Hi, > > did the commit 6e19eded3684dc184181093af3bff2ff440f5b53 break a linux kernel > build with an included ramdisk? > > As fas as I understand you must expliclity add rootfstype=ramfs to the kernel > command line to

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On Sat, Aug 05, 2017 at 07:55:11AM +0200, Willy Tarreau wrote: > On Fri, Aug 04, 2017 at 07:51:07PM -0700, Greg Kroah-Hartman wrote: > > On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: > > > On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > &

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On Sat, Aug 05, 2017 at 07:55:11AM +0200, Willy Tarreau wrote: > On Fri, Aug 04, 2017 at 07:51:07PM -0700, Greg Kroah-Hartman wrote: > > On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: > > > On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > &

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On Fri, Aug 04, 2017 at 07:51:07PM -0700, Greg Kroah-Hartman wrote: > On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: > > On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > > > On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: > > > > This is the start of the

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On Fri, Aug 04, 2017 at 07:51:07PM -0700, Greg Kroah-Hartman wrote: > On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: > > On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > > > On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: > > > > This is the start of the

Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

Hi Leo, On Sun, Jul 30, 2017 at 11:48:39PM +0800, Leo Yan wrote: > > Given that 3.10 only has a few months left, if 3.10 isn't available on > > this hardware, do you really think we need to fix something in it that > > apparently nobody will be in situation to experience, at the risk of > >

Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

Hi Leo, On Sun, Jul 30, 2017 at 11:48:39PM +0800, Leo Yan wrote: > > Given that 3.10 only has a few months left, if 3.10 isn't available on > > this hardware, do you really think we need to fix something in it that > > apparently nobody will be in situation to experience, at the risk of > >

Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

On Fri, Jul 28, 2017 at 02:52:15PM +0800, Leo Yan wrote: > On Fri, Jul 28, 2017 at 06:25:55AM +0200, Willy Tarreau wrote: > > Hi Leo, > > > > There was no upstream commit ID here but I found it in mainline here : > > > > commit 109704492ef637956265ec2eb7

Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

On Fri, Jul 28, 2017 at 02:52:15PM +0800, Leo Yan wrote: > On Fri, Jul 28, 2017 at 06:25:55AM +0200, Willy Tarreau wrote: > > Hi Leo, > > > > There was no upstream commit ID here but I found it in mainline here : > > > > commit 109704492ef637956265ec2eb7

Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

Hi Leo, There was no upstream commit ID here but I found it in mainline here : commit 109704492ef637956265ec2eb72ae7b3b39eb6f4 Author: Joel Fernandes Date: Thu Oct 20 00:34:00 2016 -0700 pstore: Make spinlock per zone instead of global What worries me is

Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

Hi Leo, There was no upstream commit ID here but I found it in mainline here : commit 109704492ef637956265ec2eb72ae7b3b39eb6f4 Author: Joel Fernandes Date: Thu Oct 20 00:34:00 2016 -0700 pstore: Make spinlock per zone instead of global What worries me is that some later fixes

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Mon, Jul 10, 2017 at 09:18:09AM -0700, Linus Torvalds wrote: > On Mon, Jul 10, 2017 at 9:12 AM, Kees Cook wrote: > > > > Sounds good to me, but won't large-memory users in 32-bit get annoyed? > > We'll see. > > I suspect that all large-memory users have long since

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Mon, Jul 10, 2017 at 09:18:09AM -0700, Linus Torvalds wrote: > On Mon, Jul 10, 2017 at 9:12 AM, Kees Cook wrote: > > > > Sounds good to me, but won't large-memory users in 32-bit get annoyed? > > We'll see. > > I suspect that all large-memory users have long since upgraded to > x86-64 (rule

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

On Thu, Jul 06, 2017 at 10:24:06AM +0200, Willy Tarreau wrote: > On Wed, Jul 05, 2017 at 04:51:06PM -0700, Linus Torvalds wrote: > > On Wed, Jul 5, 2017 at 4:35 PM, Ben Hutchings <b...@decadent.org.uk> wrote: > > >> > > >> And I think your second patc

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

On Thu, Jul 06, 2017 at 10:24:06AM +0200, Willy Tarreau wrote: > On Wed, Jul 05, 2017 at 04:51:06PM -0700, Linus Torvalds wrote: > > On Wed, Jul 5, 2017 at 4:35 PM, Ben Hutchings wrote: > > >> > > >> And I think your second patch breaks that "use a re

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

On Wed, Jul 05, 2017 at 04:51:06PM -0700, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 4:35 PM, Ben Hutchings wrote: > >> > >> And I think your second patch breaks that "use a really large value to > >> approximate infinity" case that definitely has existed as a pattern. >

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

On Wed, Jul 05, 2017 at 04:51:06PM -0700, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 4:35 PM, Ben Hutchings wrote: > >> > >> And I think your second patch breaks that "use a really large value to > >> approximate infinity" case that definitely has existed as a pattern. > > > > Right. Well

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Wed, Jul 05, 2017 at 09:32:35PM -0700, Kees Cook wrote: > In an attempt to provide sensible rlimit defaults for setuid execs, this > inherits the namespace's init rlimits: > > $ ulimit -s > 8192 > $ ulimit -s unlimited > $ /bin/sh -c 'ulimit -s' > unlimited > $ sudo /bin/sh -c 'ulimit -s' >

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Wed, Jul 05, 2017 at 09:32:35PM -0700, Kees Cook wrote: > In an attempt to provide sensible rlimit defaults for setuid execs, this > inherits the namespace's init rlimits: > > $ ulimit -s > 8192 > $ ulimit -s unlimited > $ /bin/sh -c 'ulimit -s' > unlimited > $ sudo /bin/sh -c 'ulimit -s' >

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

On Wed, Jul 05, 2017 at 05:19:47PM -0700, Andy Lutomirski wrote: > I think it's ridiculous that you can change rlimits and then > exec a setuid thing. It's not so easy to fix, though. Maybe track, > per-task, inherited by clone and exec, what the rlimits were the last > time the process had

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

On Wed, Jul 05, 2017 at 05:19:47PM -0700, Andy Lutomirski wrote: > I think it's ridiculous that you can change rlimits and then > exec a setuid thing. It's not so easy to fix, though. Maybe track, > per-task, inherited by clone and exec, what the rlimits were the last > time the process had

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

On Wed, Jul 05, 2017 at 08:32:43PM +0100, Ben Hutchings wrote: > >  - As a hardening feature, if the stack would expand within 64k or > > whatever of a non-MAP_FIXED mapping, refuse to expand it.  (This might > > have to be a non-hinted mapping, not just a non-MAP_FIXED mapping.) > > The idea

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

On Wed, Jul 05, 2017 at 08:32:43PM +0100, Ben Hutchings wrote: > >  - As a hardening feature, if the stack would expand within 64k or > > whatever of a non-MAP_FIXED mapping, refuse to expand it.  (This might > > have to be a non-hinted mapping, not just a non-MAP_FIXED mapping.) > > The idea

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

On Wed, Jul 05, 2017 at 12:17:20PM -0700, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 11:59 AM, Willy Tarreau <w...@1wt.eu> wrote: > > > > Don't you think that the option of having a sysctl to relax the check > > per task wouldn't be easier for distros and safer overa

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

On Wed, Jul 05, 2017 at 12:17:20PM -0700, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 11:59 AM, Willy Tarreau wrote: > > > > Don't you think that the option of having a sysctl to relax the check > > per task wouldn't be easier for distros and safer overall ? Ie, emit &g

Re: [PATCH] mm: mm, mmap: do not blow on PROT_NONE MAP_FIXED holes in the stack

On Wed, Jul 05, 2017 at 12:15:05PM -0700, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 11:53 AM, Michal Hocko wrote: > > > > That would lead to conflicts when backporting to stable trees though > > which is quite annoying as well and arguably slightly more annoying than > >

Re: [PATCH] mm: mm, mmap: do not blow on PROT_NONE MAP_FIXED holes in the stack

On Wed, Jul 05, 2017 at 12:15:05PM -0700, Linus Torvalds wrote: > On Wed, Jul 5, 2017 at 11:53 AM, Michal Hocko wrote: > > > > That would lead to conflicts when backporting to stable trees though > > which is quite annoying as well and arguably slightly more annoying than > > resolving this in

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

On Wed, Jul 05, 2017 at 09:17:59AM -0700, Linus Torvalds wrote: (...) > The good news is that this is probably specialized enough that we can > just keep the defaults as "will break this one case, but we give > people the tools to work around it". > > I hate doing that, but distros that still

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

On Wed, Jul 05, 2017 at 09:17:59AM -0700, Linus Torvalds wrote: (...) > The good news is that this is probably specialized enough that we can > just keep the defaults as "will break this one case, but we give > people the tools to work around it". > > I hate doing that, but distros that still

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

On Wed, Jul 05, 2017 at 01:21:54PM +0100, Ben Hutchings wrote: > On Wed, 2017-07-05 at 10:14 +0200, Willy Tarreau wrote: > > On Wed, Jul 05, 2017 at 08:36:46AM +0200, Michal Hocko wrote: > > > PROT_NONE would explicitly fault but we would simply > > > run over this mappi

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

On Wed, Jul 05, 2017 at 01:21:54PM +0100, Ben Hutchings wrote: > On Wed, 2017-07-05 at 10:14 +0200, Willy Tarreau wrote: > > On Wed, Jul 05, 2017 at 08:36:46AM +0200, Michal Hocko wrote: > > > PROT_NONE would explicitly fault but we would simply > > > run over this mappi

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

On Wed, Jul 05, 2017 at 10:24:41AM +0200, Michal Hocko wrote: > > Thus maybe if that helps we could even relax some of the stack guard > > checks as soon as we meet a PROT_NONE area, allowing VMAs to be tightly > > packed if the application knows what it's doing. > > Yes, this is what my patch

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

On Wed, Jul 05, 2017 at 10:24:41AM +0200, Michal Hocko wrote: > > Thus maybe if that helps we could even relax some of the stack guard > > checks as soon as we meet a PROT_NONE area, allowing VMAs to be tightly > > packed if the application knows what it's doing. > > Yes, this is what my patch

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

On Wed, Jul 05, 2017 at 08:36:46AM +0200, Michal Hocko wrote: > PROT_NONE would explicitly fault but we would simply > run over this mapping too easily and who knows what might end up below > it. So to me the guard gap does its job here. I tend to think that applications that implement their own

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

On Wed, Jul 05, 2017 at 08:36:46AM +0200, Michal Hocko wrote: > PROT_NONE would explicitly fault but we would simply > run over this mapping too easily and who knows what might end up below > it. So to me the guard gap does its job here. I tend to think that applications that implement their own

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

On Tue, Jul 04, 2017 at 11:47:37AM -0700, Linus Torvalds wrote: > Let's > say that you are using lots of threads, so that you know your stack > space is limited. What you do is to use MAP_FIXED a lot, and you lay > out your stacks fairly densely (with each other, but also possibly > with other

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

On Tue, Jul 04, 2017 at 11:47:37AM -0700, Linus Torvalds wrote: > Let's > say that you are using lots of threads, so that you know your stack > space is limited. What you do is to use MAP_FIXED a lot, and you lay > out your stacks fairly densely (with each other, but also possibly > with other

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

On Tue, Jul 04, 2017 at 11:37:15AM -0700, Linus Torvalds wrote: > On Tue, Jul 4, 2017 at 10:22 AM, Michal Hocko wrote: > > > > Well, I've been thinking about this some more and the more I think about > > it the less I am convinced we should try to be clever here. Why? Because >

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

On Tue, Jul 04, 2017 at 11:37:15AM -0700, Linus Torvalds wrote: > On Tue, Jul 4, 2017 at 10:22 AM, Michal Hocko wrote: > > > > Well, I've been thinking about this some more and the more I think about > > it the less I am convinced we should try to be clever here. Why? Because > > as soon as

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

On Tue, Jul 04, 2017 at 12:36:11PM +0100, Ben Hutchings wrote: > @@ -2323,11 +2330,17 @@ int expand_downwards(struct vm_area_struct *vma, > if (error) > return error; > > - /* Enforce stack_guard_gap */ > + /* > + * Enforce stack_guard_gap, but allow VM_NONE

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

On Tue, Jul 04, 2017 at 12:36:11PM +0100, Ben Hutchings wrote: > @@ -2323,11 +2330,17 @@ int expand_downwards(struct vm_area_struct *vma, > if (error) > return error; > > - /* Enforce stack_guard_gap */ > + /* > + * Enforce stack_guard_gap, but allow VM_NONE

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

On Tue, Jul 04, 2017 at 05:27:55PM +0100, John Haxby wrote: > Alas, the people who could confirm this for me are getting ready to > watch fireworks and generally have a good time. Let's hope the fireworks is controlled by Java with on up-to-date kernel so that they can quickly get back to work

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

On Tue, Jul 04, 2017 at 05:27:55PM +0100, John Haxby wrote: > Alas, the people who could confirm this for me are getting ready to > watch fireworks and generally have a good time. Let's hope the fireworks is controlled by Java with on up-to-date kernel so that they can quickly get back to work

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

On Tue, Jul 04, 2017 at 12:36:11PM +0100, Ben Hutchings wrote: > > If anywhing this would require to have a loop over all PROT_NONE > > mappings to not hit into other weird usecases. > > That's what I was thinking of. Tried the following patch: (...) > - next = vma->vm_next; > + /* > +

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

On Tue, Jul 04, 2017 at 12:36:11PM +0100, Ben Hutchings wrote: > > If anywhing this would require to have a loop over all PROT_NONE > > mappings to not hit into other weird usecases. > > That's what I was thinking of. Tried the following patch: (...) > - next = vma->vm_next; > + /* > +

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

On Tue, Jul 04, 2017 at 11:35:38AM +0200, Michal Hocko wrote: > On Tue 04-07-17 10:41:22, Michal Hocko wrote: > > On Mon 03-07-17 17:05:27, Linus Torvalds wrote: > > > On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings > > > wrote: > > > > > > > > Firstly, some Rust programs are

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

On Tue, Jul 04, 2017 at 11:35:38AM +0200, Michal Hocko wrote: > On Tue 04-07-17 10:41:22, Michal Hocko wrote: > > On Mon 03-07-17 17:05:27, Linus Torvalds wrote: > > > On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings > > > wrote: > > > > > > > > Firstly, some Rust programs are crashing on ppc64el

Linux 3.10.107

quest queue Weston Andros Adamson (1): NFSv4: fix getacl ERANGE for some ACL buffer sizes Willem de Bruijn (3): macvtap: read vnet_hdr_size once packet: round up linear to header len tun: read vnet_hdr_sz once Willy Tarreau (1): Linux 3.10.107 Xin Long (1): sctp:

Linux 3.10.107

quest queue Weston Andros Adamson (1): NFSv4: fix getacl ERANGE for some ACL buffer sizes Willem de Bruijn (3): macvtap: read vnet_hdr_size once packet: round up linear to header len tun: read vnet_hdr_sz once Willy Tarreau (1): Linux 3.10.107 Xin Long (1): sctp:

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

On Thu, Jun 22, 2017 at 03:14:00PM +0100, Ben Hutchings wrote: > On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote: > > but I think Ben is currently looking > > for feedback on the validity of his backport which was a difficult > > task. > > Right. Ben, barring

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

On Thu, Jun 22, 2017 at 03:14:00PM +0100, Ben Hutchings wrote: > On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote: > > but I think Ben is currently looking > > for feedback on the validity of his backport which was a difficult > > task. > > Right. Ben, barring

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

Hi, On Thu, Jun 22, 2017 at 03:15:51PM +0200, Levente Polyak wrote: > Just a side note, but i think its worth mentioning to also have look at > these fixup patches: > > > -- mm: fix new crash in unmapped_area_topdown() >

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

Hi, On Thu, Jun 22, 2017 at 03:15:51PM +0200, Levente Polyak wrote: > Just a side note, but i think its worth mentioning to also have look at > these fixup patches: > > > -- mm: fix new crash in unmapped_area_topdown() >

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

On Thu, Jun 22, 2017 at 03:10:34PM +0200, Willy Tarreau wrote: > On Thu, Jun 22, 2017 at 01:58:11PM +0100, Ben Hutchings wrote: > > On Thu, 2017-06-22 at 14:46 +0200, Willy Tarreau wrote: > > > On Thu, Jun 22, 2017 at 01:30:45PM +0100, Ben Hutchings wrote: > > > > H

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

On Thu, Jun 22, 2017 at 03:10:34PM +0200, Willy Tarreau wrote: > On Thu, Jun 22, 2017 at 01:58:11PM +0100, Ben Hutchings wrote: > > On Thu, 2017-06-22 at 14:46 +0200, Willy Tarreau wrote: > > > On Thu, Jun 22, 2017 at 01:30:45PM +0100, Ben Hutchings wrote: > > > > H

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

On Thu, Jun 22, 2017 at 01:58:11PM +0100, Ben Hutchings wrote: > On Thu, 2017-06-22 at 14:46 +0200, Willy Tarreau wrote: > > On Thu, Jun 22, 2017 at 01:30:45PM +0100, Ben Hutchings wrote: > > > Here's my attempt at a backport to 3.2.  This is only tested on > > >

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

On Thu, Jun 22, 2017 at 01:58:11PM +0100, Ben Hutchings wrote: > On Thu, 2017-06-22 at 14:46 +0200, Willy Tarreau wrote: > > On Thu, Jun 22, 2017 at 01:30:45PM +0100, Ben Hutchings wrote: > > > Here's my attempt at a backport to 3.2.  This is only tested on > > >

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

On Thu, Jun 22, 2017 at 01:30:45PM +0100, Ben Hutchings wrote: > Here's my attempt at a backport to 3.2. This is only tested on > x86_64 and I think I should introduce local variables for > vma_start_gap() in a few places. I had to cherry-pick commit > 09884964335e "mm: do not grow the stack vma

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

On Thu, Jun 22, 2017 at 01:30:45PM +0100, Ben Hutchings wrote: > Here's my attempt at a backport to 3.2. This is only tested on > x86_64 and I think I should introduce local variables for > vma_start_gap() in a few places. I had to cherry-pick commit > 09884964335e "mm: do not grow the stack vma

Re: [criu] 1M guard page ruined restore

Hi Oleg, On Wed, Jun 21, 2017 at 07:01:29PM +0200, Oleg Nesterov wrote: > Ah. I forgot about another kernel "feature" ;) not related to the recent guard > page changes... > > Could you test the patch below? FWIW, I've just checked here on 3.10.107-rc and while I observe the same regression as

Re: [criu] 1M guard page ruined restore

Hi Oleg, On Wed, Jun 21, 2017 at 07:01:29PM +0200, Oleg Nesterov wrote: > Ah. I forgot about another kernel "feature" ;) not related to the recent guard > page changes... > > Could you test the patch below? FWIW, I've just checked here on 3.10.107-rc and while I observe the same regression as

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

Hey Hugh, On Wed, Jun 21, 2017 at 09:18:23AM +0200, Willy Tarreau wrote: > Thanks a lot, I'll include your patch and will test it again. And > yes, I intend to merge Helge's fix once it lands into mainline (maybe > it is right now, I didn't check) and possibly other ones you might be

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

Hey Hugh, On Wed, Jun 21, 2017 at 09:18:23AM +0200, Willy Tarreau wrote: > Thanks a lot, I'll include your patch and will test it again. And > yes, I intend to merge Helge's fix once it lands into mainline (maybe > it is right now, I didn't check) and possibly other ones you might be

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

On Tue, Jun 20, 2017 at 11:10:56PM -0700, Hugh Dickins wrote: > On Wed, 21 Jun 2017, Willy Tarreau wrote: > > On Tue, Jun 20, 2017 at 10:49:16PM -0700, Hugh Dickins wrote: > > > On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote: > > > > > > > 3.18-stable revi

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

On Tue, Jun 20, 2017 at 11:10:56PM -0700, Hugh Dickins wrote: > On Wed, 21 Jun 2017, Willy Tarreau wrote: > > On Tue, Jun 20, 2017 at 10:49:16PM -0700, Hugh Dickins wrote: > > > On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote: > > > > > > > 3.18-stable revi

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

On Wed, Jun 21, 2017 at 12:05:07AM -0700, Hugh Dickins wrote: > On Mon, 19 Jun 2017, Willy Tarreau wrote: > > > From: Hugh Dickins <hu...@google.com> > > > > commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream. > > Some of these suggested adjustment

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

On Wed, Jun 21, 2017 at 12:05:07AM -0700, Hugh Dickins wrote: > On Mon, 19 Jun 2017, Willy Tarreau wrote: > > > From: Hugh Dickins > > > > commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream. > > Some of these suggested adjustments below are just what compar

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

On Tue, Jun 20, 2017 at 10:49:16PM -0700, Hugh Dickins wrote: > On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote: > > > 3.18-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Hugh Dickins > > > > commit

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

On Tue, Jun 20, 2017 at 10:49:16PM -0700, Hugh Dickins wrote: > On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote: > > > 3.18-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Hugh Dickins > > > > commit

Re: [PATCH 3.10 000/268] 3.10.107-stable review

On Tue, Jun 20, 2017 at 02:10:08AM -0700, Guenter Roeck wrote: > Confirmed. All builds and qemu tests passed with v3.10.106-267-g4242a2a. Nice, thank you Guenter! Willy

Re: [PATCH 3.10 000/268] 3.10.107-stable review

On Tue, Jun 20, 2017 at 02:10:08AM -0700, Guenter Roeck wrote: > Confirmed. All builds and qemu tests passed with v3.10.106-267-g4242a2a. Nice, thank you Guenter! Willy

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

On Tue, Jun 20, 2017 at 10:14:05AM +0200, Rafal Milecki wrote: > On 2017-06-20 09:58, Willy Tarreau wrote: > > On Tue, Jun 20, 2017 at 09:31:00AM +0200, Rafal Milecki wrote: > > > Do you know if my name will appear correctly in git [0]? > > > > > > [0] > &

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

On Tue, Jun 20, 2017 at 10:14:05AM +0200, Rafal Milecki wrote: > On 2017-06-20 09:58, Willy Tarreau wrote: > > On Tue, Jun 20, 2017 at 09:31:00AM +0200, Rafal Milecki wrote: > > > Do you know if my name will appear correctly in git [0]? > > > > > > [0] > &

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

On Tue, Jun 20, 2017 at 09:31:00AM +0200, Rafal Milecki wrote: > Do you know if my name will appear correctly in git [0]? > > [0] > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-3.10.y I would have almost promised it was going to be OK but it's bogus so it

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

On Tue, Jun 20, 2017 at 09:31:00AM +0200, Rafal Milecki wrote: > Do you know if my name will appear correctly in git [0]? > > [0] > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-3.10.y I would have almost promised it was going to be OK but it's bogus so it

Re: [PATCH 3.10 219/268] tty/serial: atmel: fix race condition (TX+DMA)

Hi Richard, On Tue, Jun 20, 2017 at 09:04:03AM +0200, Richard Genoud wrote: > Hi Willy, > > You can drop this patch. > > There's nothing to fix on 3.10.x since the DMA TX support has been > introduced in 3.12. I've already dropped it as it broke some build. Thanks! Willy

Re: [PATCH 3.10 219/268] tty/serial: atmel: fix race condition (TX+DMA)

Hi Richard, On Tue, Jun 20, 2017 at 09:04:03AM +0200, Richard Genoud wrote: > Hi Willy, > > You can drop this patch. > > There's nothing to fix on 3.10.x since the DMA TX support has been > introduced in 3.12. I've already dropped it as it broke some build. Thanks! Willy

Re: [PATCH 3.10 000/268] 3.10.107-stable review

Hi Guenter, On Tue, Jun 20, 2017 at 12:51:46AM +0200, Willy Tarreau wrote: > Hi Guenter, > > On Mon, Jun 19, 2017 at 03:46:36PM -0700, Guenter Roeck wrote: > > Build results: > > total: 121 pass: 118 fail: 3 > > Failed builds: > > arm:at91_dt_defc

Re: [PATCH 3.10 000/268] 3.10.107-stable review

Hi Guenter, On Tue, Jun 20, 2017 at 12:51:46AM +0200, Willy Tarreau wrote: > Hi Guenter, > > On Mon, Jun 19, 2017 at 03:46:36PM -0700, Guenter Roeck wrote: > > Build results: > > total: 121 pass: 118 fail: 3 > > Failed builds: > > arm:at91_dt_defc

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

On Tue, Jun 20, 2017 at 08:12:26AM +0300, Kalle Valo wrote: > Willy Tarreau <w...@1wt.eu> writes: > > > From: Rafał Miłecki <ra...@milecki.pl> > > > > commit a971df0b9d04674e325346c17de9a895425ca5e1 upstream. > > > > This allows tracking d

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