linux-next: Tree for Nov 7
Hi all, Changes since 20181106: New trees: slimbus, nvmem The tip tree still had its build failure for which I applied a fix patch. Non-merge commits (relative to Linus' tree): 1408 1540 files changed, 69938 insertions(+), 65849 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 296 trees (counting Linus' and 67 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (8053e5b93eca Merge tag 'trace-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux) Merging kbuild-current/fixes (02826a6ba301 kbuild: deb-pkg: fix bindeb-pkg breakage when O= is used) Merging arc-current/for-curr (d94cf77e44d5 ARC: [plat-hsdk] Enable DW APB GPIO support) Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() offset check) Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject stand-alone CHAIN events for PMUv3) Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode) Merging powerpc-fixes/fixes (651022382c7f Linux 4.20-rc1) Merging sparc/master (1f2b5b8e2df4 sparc64: Wire up compat getpeername and getsockname.) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (042cb5647815 net: phy: Allow BCM54616S PHY to setup internal TX/RX clock delay) Merging bpf/master (ea53abfab960 bonding/802.3ad: fix link_failure_count tracking) Merging ipsec/master (533555e5cbb6 xfrm: Fix error return code in xfrm_output_one()) Merging netfilter/master (a422757e8c32 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (b374e8686fc3 mt76: fix building without CONFIG_LEDS_CLASS) Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error paths for netlink) Merging rdma-fixes/for-rc (651022382c7f Linux 4.20-rc1) Merging sound-current/for-linus (5e93a125f521 ALSA: hda - Fix incorrect clearance of thinkpad_acpi hooks) Merging sound-asoc-fixes/for-linus (6eeb153e005f Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8) Merging regulator-fixes/for-linus (651022382c7f Linux 4.20-rc1) Merging spi-fixes/for-linus (66460685fb71 Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (651022382c7f Linux 4.20-rc1) Merging driver-core.current/driver-core-linus (651022382c7f Linux 4.20-rc1) Merging tty.current/tty-linus (202dc3cc10b4 serial: sh-sci: Fix receive on SCIFA/SCIFB variants with DMA) Merging usb.current/usb-linus (651022382c7f Linux 4.20-rc1) Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of dwc2_check_core_endianness) Merging usb-serial-fixes/usb-linus (0238df646e62 Linux 4.19-rc7) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (651022382c7f Linux 4.20-rc1) Merging staging.current/staging-linus (651022382c7f Linux 4.20-rc1) Merging char-misc.current/char-misc-linus (651022382c7f Linux 4.20-rc1) Merging soundwire-fixes/fixes (651022382c7f Linux 4.20-rc1) Merging input-
Re: linux-next: Tree for Nov 7
On Tue, 2017-11-14 at 10:04 +0100, Michal Hocko wrote: > If there is a general consensus that this is the preferred way to go, > I > will post the patch as an RFC to linux-api > > [1] http://lkml.kernel.org/r/20171113160637.jhekbdyfpccme3be@dhcp22.s > use.cz I prefer the new flag. It is cleaner and avoids unintended breakage for existing flag. -- Khalid
Re: linux-next: Tree for Nov 7
On Tue 14-11-17 20:18:04, Michael Ellerman wrote: > Michal Hocko writes: > > > [Sorry for spamming, this one is the last attempt hopefully] > > > > On Mon 13-11-17 16:49:39, Michal Hocko wrote: > >> On Mon 13-11-17 16:16:41, Michal Hocko wrote: > >> > On Mon 13-11-17 13:00:57, Michal Hocko wrote: > >> > [...] > >> > > Yes, I have mentioned that in the previous email but the amount of code > >> > > would be even larger. Basically every arch which reimplements > >> > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to > >> > > do vma lookup. > >> > > >> > It turned out that this might be much more easier than I thought after > >> > all. It seems we can really handle that in the common code. This would > >> > mean that we are exposing a new functionality to the userspace though. > >> > Myabe this would be useful on its own though. Just a quick draft (not > >> > even compile tested) whether this makes sense in general. I would be > >> > worried about unexpected behavior when somebody set other bit without a > >> > good reason and we might fail with ENOMEM for such a call now. > >> > >> Hmm, the bigger problem would be the backward compatibility actually. We > >> would get silent corruptions which is exactly what the flag is trying > >> fix. mmap flags handling really sucks. So I guess we would have to make > >> the flag internal only :/ > > > > OK, so this one should take care of the backward compatibility while > > still not touching the arch code > > I'm not sure I understand your worries about backward compatibility? Just imagine you are running an application which uses the new flag combination on an older kernel. You will get no warning, yet you have no way to check that you have actually clobbered an existing mapping because MAP_FIXED will be used the old way. > If we add a new mmap flag which is currently unused then what is the > problem? Are you worried about user code that accidentally passes that > flag already? If we add a completely new flag, like in this patch, then the code using the flag will not clobber an existing mapping on older kernels which do not recognize it (we will simply fall back to the default hint based implementation). You might not get the mapping you asked for which sucks but that is not fixable AFAICS. You can at least do mapped_addr = mmap(addr, ... MAP_FIXED_SAFE...); assert(mapped_addr == addr); So I do not think we can go with the modifier unfortunatelly. -- Michal Hocko SUSE Labs
Re: linux-next: Tree for Nov 7
Michal Hocko writes: > [Sorry for spamming, this one is the last attempt hopefully] > > On Mon 13-11-17 16:49:39, Michal Hocko wrote: >> On Mon 13-11-17 16:16:41, Michal Hocko wrote: >> > On Mon 13-11-17 13:00:57, Michal Hocko wrote: >> > [...] >> > > Yes, I have mentioned that in the previous email but the amount of code >> > > would be even larger. Basically every arch which reimplements >> > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to >> > > do vma lookup. >> > >> > It turned out that this might be much more easier than I thought after >> > all. It seems we can really handle that in the common code. This would >> > mean that we are exposing a new functionality to the userspace though. >> > Myabe this would be useful on its own though. Just a quick draft (not >> > even compile tested) whether this makes sense in general. I would be >> > worried about unexpected behavior when somebody set other bit without a >> > good reason and we might fail with ENOMEM for such a call now. >> >> Hmm, the bigger problem would be the backward compatibility actually. We >> would get silent corruptions which is exactly what the flag is trying >> fix. mmap flags handling really sucks. So I guess we would have to make >> the flag internal only :/ > > OK, so this one should take care of the backward compatibility while > still not touching the arch code I'm not sure I understand your worries about backward compatibility? If we add a new mmap flag which is currently unused then what is the problem? Are you worried about user code that accidentally passes that flag already? > diff --git a/include/uapi/asm-generic/mman-common.h > b/include/uapi/asm-generic/mman-common.h > index 203268f9231e..03c518777f83 100644 > --- a/include/uapi/asm-generic/mman-common.h > +++ b/include/uapi/asm-generic/mman-common.h > @@ -25,6 +25,8 @@ > # define MAP_UNINITIALIZED 0x0 /* Don't support this flag */ > #endif > > +#define MAP_FIXED_SAFE 0x200 /* MAP_FIXED which doesn't unmap > underlying mapping */ > + As I said in my other mail I think this should be a modifier to MAP_FIXED. That way all the existing code that checks for MAP_FIXED (in the kernel) works exactly as it currently does - like the check Khalid pointed out. And I think MAP_NO_CLOBBER would be a better name. cheers
Re: linux-next: Tree for Nov 7
On Tue 14-11-17 19:54:59, Michael Ellerman wrote: > Michal Hocko writes: [...] > > So this was the most simple solution I could come up > > with. If there was a general interest for MAP_FIXED_SAFE then we can > > introduce it later of course. I would just like the hardening merged > > sooner rather than later. > > Sure. But in the scheme of things one more kernel release is not that > big a deal to get it right. Given that the simple approach of dropping > MAP_FIXED turns out to not be simple at all. Well, my idea was to push this hardening to older kernels because those were more vulnerable for the PIE base vs. stack placement and stack controllable size from userspace etc... Anyway, as per [1] it seems that the MAP_FIXED_SAFE doesn't look terrible from the backporting POV. If there is a general consensus that this is the preferred way to go, I will post the patch as an RFC to linux-api [1] http://lkml.kernel.org/r/20171113160637.jhekbdyfpccme...@dhcp22.suse.cz -- Michal Hocko SUSE Labs
Re: linux-next: Tree for Nov 7
Michal Hocko writes: > On Mon 13-11-17 13:00:57, Michal Hocko wrote: > [...] >> Yes, I have mentioned that in the previous email but the amount of code >> would be even larger. Basically every arch which reimplements >> arch_get_unmapped_area would have to special case new MAP_FIXED flag to >> do vma lookup. > > It turned out that this might be much more easier than I thought after > all. It seems we can really handle that in the common code. Ah nice. I should have read this before replying to your previous mail. > This would mean that we are exposing a new functionality to the userspace > though. > Myabe this would be useful on its own though. Yes I think it would. At least jemalloc seems like it could use it: https://github.com/jemalloc/jemalloc/blob/9f455e2786685b443201c33119765c8093461174/src/pages.c#L65 And I have memories of some JIT code I read once which did a loop of mmap()s or something to try and get allocations below 4GB or some other limit - but I can't remember now what it was. > Just a quick draft (not > even compile tested) whether this makes sense in general. I would be > worried about unexpected behavior when somebody set other bit without a > good reason and we might fail with ENOMEM for such a call now. > > Elf loader would then use MAP_FIXED_SAFE rather than MAP_FIXED. > --- > diff --git a/arch/alpha/include/uapi/asm/mman.h > b/arch/alpha/include/uapi/asm/mman.h > index 3b26cc62dadb..d021c21f9b01 100644 > --- a/arch/alpha/include/uapi/asm/mman.h > +++ b/arch/alpha/include/uapi/asm/mman.h > @@ -31,6 +31,9 @@ > #define MAP_STACK0x8 /* give out an address that is best > suited for process/thread stacks */ > #define MAP_HUGETLB 0x10/* create a huge page mapping */ > > +#define MAP_KEEP_MAPPING 0x200 > +#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED > without clobbering an existing mapping */ So bike-shedding a bit, but I think "SAFE" is too vague a name. Perhaps MAP_NO_CLOBBER - which has the single semantic of "do not clobber any existing mappings". It would be a flag on its own, so you could pass it with or without MAP_FIXED, but it would only change the behaviour when MAP_FIXED is specified also. cheers
Re: linux-next: Tree for Nov 7
Michal Hocko writes: > On Mon 13-11-17 22:34:50, Michael Ellerman wrote: >> Hi Michal, >> >> Michal Hocko writes: >> > On Mon 13-11-17 10:20:06, Michal Hocko wrote: >> >> [Cc arm and ppc maintainers] >> > >> > Hmm, it turned out to be a problem on other architectures as well. >> > CCing more maintainers. For your reference, we are talking about >> > http://lkml.kernel.org/r/20171023082608.6167-1-mho...@kernel.org >> > which has broken architectures which do apply aligning on the mmap >> > address hint without MAP_FIXED applied. See below my proposed way >> > around this issue because I belive that the above patch is quite >> > valuable on its own to be dropped for all archs. >> >> I don't really like your solution sorry :) The fact that you've had to >> patch seven arches seems like a red flag. >> >> I think this is a generic problem with MAP_FIXED, which I've heard >> userspace folks complain about in the past. > > The thing is that we canno change MAP_FIXED behavior as it is carved in > stone Yes obviously. I didn't mean to imply we would change MAP_FIXED, rather we would add a new flag with the new semantics. >> Currently MAP_FIXED does two things: >> 1. makes addr not a hint but the required address >> 2. blasts any existing mapping >> >> You want 1) but not 2). > > + fail if there is a clashing range Yep. I thought that was implied :) >> So the right solution IMHO would be to add a new mmap flag to request >> that behaviour, ie. a fixed address but iff there is nothing already >> mapped there. >> >> I don't know the mm code well enough to know if that's hard for some >> reason, but it *seems* like it should be doable. > > Yes, I have mentioned that in the previous email but the amount of code > would be even larger. Basically every arch which reimplements > arch_get_unmapped_area would have to special case new MAP_FIXED flag to > do vma lookup. I'd have to look, but my memory of the arch code is that it doesn't deal with the vma so it wouldn't need any change. > So this was the most simple solution I could come up > with. If there was a general interest for MAP_FIXED_SAFE then we can > introduce it later of course. I would just like the hardening merged > sooner rather than later. Sure. But in the scheme of things one more kernel release is not that big a deal to get it right. Given that the simple approach of dropping MAP_FIXED turns out to not be simple at all. cheers
Re: linux-next: Tree for Nov 7
On Mon 13-11-17 09:35:22, Khalid Aziz wrote: > On 11/13/2017 09:06 AM, Michal Hocko wrote: > > OK, so this one should take care of the backward compatibility while > > still not touching the arch code > > --- > > commit 39ff9bf8597e79a032da0954aea1f0d77d137765 > > Author: Michal Hocko > > Date: Mon Nov 13 17:06:24 2017 +0100 > > > > mm: introduce MAP_FIXED_SAFE > > MAP_FIXED is used quite often but it is inherently dangerous because it > > unmaps an existing mapping covered by the requested range. While this > > might be might be really desidered behavior in many cases there are > > others which would rather see a failure than a silent memory > > corruption. > > Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior. > > It is a MAP_FIXED extension with a single exception that it fails with > > ENOMEM if the requested address is already covered by an existing > > mapping. We still do rely on get_unmaped_area to handle all the arch > > specific MAP_FIXED treatment and check for a conflicting vma after it > > returns. > > Signed-off-by: Michal Hocko > > > > .. deleted ... > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 680506faceae..aad8d37f0205 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned > > long addr, > > if (mm->map_count > sysctl_max_map_count) > > return -ENOMEM; > > + /* force arch specific MAP_FIXED handling in get_unmapped_area */ > > + if (flags & MAP_FIXED_SAFE) > > + flags |= MAP_FIXED; > > + > > /* Obtain the address to map to. we verify (or select) it and ensure > > * that it represents a valid section of the address space. > > */ > > Do you need to move this code above: > > if (!(flags & MAP_FIXED)) > addr = round_hint_to_min(addr); > > /* Careful about overflows.. */ > len = PAGE_ALIGN(len); > if (!len) > return -ENOMEM; > > Not doing that might mean the hint address will end up being rounded for > MAP_FIXED_SAFE which would change the behavior from MAP_FIXED. Yes, I will move it. -- Michal Hocko SUSE Labs
Re: linux-next: Tree for Nov 7
Hi Andrew, On Mon, 13 Nov 2017 16:03:14 -0800 Andrew Morton wrote: > > Does this kernel have "fs/binfmt_elf.c: drop MAP_FIXED usage from > elf_map" applied? That patch was dropped due to runtime issues. next-20171107 has that patch in it, next-20171108 does not. -- Cheers, Stephen Rothwell
Re: linux-next: Tree for Nov 7
On Sun, 12 Nov 2017 11:38:02 +1030 Joel Stanley wrote: > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko wrote: > > Hi Joel, > > > > On Wed 08-11-17 15:20:50, Michal Hocko wrote: > > [...] > >> > There are a lot of messages on the way up that look like this: > >> > > >> > [2.527460] Uhuuh, elf segement at 000d9000 requested but the > >> > memory is mapped already > >> > [2.540160] Uhuuh, elf segement at 000d9000 requested but the > >> > memory is mapped already > >> > [2.546153] Uhuuh, elf segement at 000d9000 requested but the > >> > memory is mapped already > >> > > >> > And then trying to run userspace looks like this: > >> > >> Could you please run with debugging patch posted > >> http://lkml.kernel.org/r/20171107102854.vylrtaodla63k...@dhcp22.suse.cz > > > > Did you have chance to test with this debugging patch, please? > > Lots of this: > > [1.177266] Uhuuh, elf segement at 000d9000 requested but the > memory is mapped already, got 000dd000 > [1.177555] Clashing vma [dd000, de000] flags:100873 name:(null) > > Full log is attached. > > If you want to reproduce yourself and have an arm compiler lying around: > > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make aspeed_g5_defconfig > $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make > $ qemu-system-arm -M ast2500-evb -nographic -nodefaults -serial stdio \ > -kernel arch/arm/boot/zImage \ > -dtb arch/arm/boot/dts/aspeed-ast2500-evb.dtb > > I'm using Qemu 2.10 which current distros ship. ymmv with older releases. (wakes up) Does this kernel have "fs/binfmt_elf.c: drop MAP_FIXED usage from elf_map" applied? That patch was dropped due to runtime issues.
Re: linux-next: Tree for Nov 7
On 11/13/2017 09:06 AM, Michal Hocko wrote: OK, so this one should take care of the backward compatibility while still not touching the arch code --- commit 39ff9bf8597e79a032da0954aea1f0d77d137765 Author: Michal Hocko Date: Mon Nov 13 17:06:24 2017 +0100 mm: introduce MAP_FIXED_SAFE MAP_FIXED is used quite often but it is inherently dangerous because it unmaps an existing mapping covered by the requested range. While this might be might be really desidered behavior in many cases there are others which would rather see a failure than a silent memory corruption. Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior. It is a MAP_FIXED extension with a single exception that it fails with ENOMEM if the requested address is already covered by an existing mapping. We still do rely on get_unmaped_area to handle all the arch specific MAP_FIXED treatment and check for a conflicting vma after it returns. Signed-off-by: Michal Hocko .. deleted ... diff --git a/mm/mmap.c b/mm/mmap.c index 680506faceae..aad8d37f0205 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr, if (mm->map_count > sysctl_max_map_count) return -ENOMEM; + /* force arch specific MAP_FIXED handling in get_unmapped_area */ + if (flags & MAP_FIXED_SAFE) + flags |= MAP_FIXED; + /* Obtain the address to map to. we verify (or select) it and ensure * that it represents a valid section of the address space. */ Do you need to move this code above: if (!(flags & MAP_FIXED)) addr = round_hint_to_min(addr); /* Careful about overflows.. */ len = PAGE_ALIGN(len); if (!len) return -ENOMEM; Not doing that might mean the hint address will end up being rounded for MAP_FIXED_SAFE which would change the behavior from MAP_FIXED. -- Khalid
Re: linux-next: Tree for Nov 7
[Sorry for spamming, this one is the last attempt hopefully] On Mon 13-11-17 16:49:39, Michal Hocko wrote: > On Mon 13-11-17 16:16:41, Michal Hocko wrote: > > On Mon 13-11-17 13:00:57, Michal Hocko wrote: > > [...] > > > Yes, I have mentioned that in the previous email but the amount of code > > > would be even larger. Basically every arch which reimplements > > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to > > > do vma lookup. > > > > It turned out that this might be much more easier than I thought after > > all. It seems we can really handle that in the common code. This would > > mean that we are exposing a new functionality to the userspace though. > > Myabe this would be useful on its own though. Just a quick draft (not > > even compile tested) whether this makes sense in general. I would be > > worried about unexpected behavior when somebody set other bit without a > > good reason and we might fail with ENOMEM for such a call now. > > Hmm, the bigger problem would be the backward compatibility actually. We > would get silent corruptions which is exactly what the flag is trying > fix. mmap flags handling really sucks. So I guess we would have to make > the flag internal only :/ OK, so this one should take care of the backward compatibility while still not touching the arch code --- commit 39ff9bf8597e79a032da0954aea1f0d77d137765 Author: Michal Hocko Date: Mon Nov 13 17:06:24 2017 +0100 mm: introduce MAP_FIXED_SAFE MAP_FIXED is used quite often but it is inherently dangerous because it unmaps an existing mapping covered by the requested range. While this might be might be really desidered behavior in many cases there are others which would rather see a failure than a silent memory corruption. Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior. It is a MAP_FIXED extension with a single exception that it fails with ENOMEM if the requested address is already covered by an existing mapping. We still do rely on get_unmaped_area to handle all the arch specific MAP_FIXED treatment and check for a conflicting vma after it returns. Signed-off-by: Michal Hocko diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h index 3b26cc62dadb..767bcb8a4c28 100644 --- a/arch/alpha/include/uapi/asm/mman.h +++ b/arch/alpha/include/uapi/asm/mman.h @@ -31,6 +31,8 @@ #define MAP_STACK 0x8 /* give out an address that is best suited for process/thread stacks */ #define MAP_HUGETLB0x10/* create a huge page mapping */ +#define MAP_FIXED_SAFE 0x200 /* MAP_FIXED which doesn't unmap underlying mapping */ + #define MS_ASYNC 1 /* sync memory asynchronously */ #define MS_SYNC2 /* synchronous memory sync */ #define MS_INVALIDATE 4 /* invalidate the caches */ diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/asm/mman.h index da3216007fe0..c2311eb7219b 100644 --- a/arch/mips/include/uapi/asm/mman.h +++ b/arch/mips/include/uapi/asm/mman.h @@ -49,6 +49,8 @@ #define MAP_STACK 0x4 /* give out an address that is best suited for process/thread stacks */ #define MAP_HUGETLB0x8 /* create a huge page mapping */ +#define MAP_FIXED_SAFE 0x200 /* MAP_FIXED which doesn't unmap underlying mapping */ + /* * Flags for msync */ diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/uapi/asm/mman.h index cc9ba1d34779..b06fd830bc6f 100644 --- a/arch/parisc/include/uapi/asm/mman.h +++ b/arch/parisc/include/uapi/asm/mman.h @@ -25,6 +25,8 @@ #define MAP_STACK 0x4 /* give out an address that is best suited for process/thread stacks */ #define MAP_HUGETLB0x8 /* create a huge page mapping */ +#define MAP_FIXED_SAFE 0x200 /* MAP_FIXED which doesn't unmap underlying mapping */ + #define MS_SYNC1 /* synchronous memory sync */ #define MS_ASYNC 2 /* sync memory asynchronously */ #define MS_INVALIDATE 4 /* invalidate the caches */ diff --git a/arch/xtensa/include/uapi/asm/mman.h b/arch/xtensa/include/uapi/asm/mman.h index b15b278aa314..f4b291bca764 100644 --- a/arch/xtensa/include/uapi/asm/mman.h +++ b/arch/xtensa/include/uapi/asm/mman.h @@ -62,6 +62,8 @@ # define MAP_UNINITIALIZED 0x0 /* Don't support this flag */ #endif +#define MAP_FIXED_SAFE 0x200 /* MAP_FIXED which doesn't unmap underlying mapping */ + /* * Flags for msync */ diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h index 203268f9231e..03c518777f83 100644 --- a/include/uapi/asm-generic/mman-common.h +++ b/include/uapi/asm-generic/mman-common.h @@ -25,6 +25,8 @@ # define MAP_UNINITIALIZED 0x0 /* Don't support this flag */ #endif +#define MAP_FIXED_SAFE 0x20
Re: linux-next: Tree for Nov 7
On Mon 13-11-17 15:48:13, Russell King - ARM Linux wrote:
> On Mon, Nov 13, 2017 at 04:16:41PM +0100, Michal Hocko wrote:
> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> > [...]
> > > Yes, I have mentioned that in the previous email but the amount of code
> > > would be even larger. Basically every arch which reimplements
> > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> > > do vma lookup.
> >
> > It turned out that this might be much more easier than I thought after
> > all. It seems we can really handle that in the common code. This would
> > mean that we are exposing a new functionality to the userspace though.
> > Myabe this would be useful on its own though. Just a quick draft (not
> > even compile tested) whether this makes sense in general. I would be
> > worried about unexpected behavior when somebody set other bit without a
> > good reason and we might fail with ENOMEM for such a call now.
> >
> > Elf loader would then use MAP_FIXED_SAFE rather than MAP_FIXED.
> > ---
> > diff --git a/arch/alpha/include/uapi/asm/mman.h
> > b/arch/alpha/include/uapi/asm/mman.h
> > index 3b26cc62dadb..d021c21f9b01 100644
> > --- a/arch/alpha/include/uapi/asm/mman.h
> > +++ b/arch/alpha/include/uapi/asm/mman.h
> > @@ -31,6 +31,9 @@
> > #define MAP_STACK 0x8 /* give out an address that is best
> > suited for process/thread stacks */
> > #define MAP_HUGETLB0x10/* create a huge page mapping */
> >
> > +#define MAP_KEEP_MAPPING 0x200
> > +#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED
> > without clobbering an existing mapping */
>
> A few things...
>
> 1. Does this need to be exposed to userland?
As I've written in another email, exposing the flag this way would be
really dangerous wrt. backward compatibility. So we would either need some
translation or make it a flag on its own and touch the arch specific
code which I really wanted to prevent from.
Whether this is something useful for the userspace is a separate
question which I should bring up to linux-api for a wider audience to
discuss.
So I guess this goes down to whether we want/need something like
MAP_FIXED_SAFE or opt out the specific hardening code for arches that
cannot make unaligned mappings for the requested address.
> 2. Can it end up in include/uapi/asm-generic/mman*.h ?
> 3. The definition of MAP_FIXED_SAFE should really have parens around it.
Of course. I thought I did...
> > @@ -1365,6 +1365,13 @@ unsigned long do_mmap(struct file *file, unsigned
> > long addr,
> > if (offset_in_page(addr))
> > return addr;
> >
> > + if ((flags & MAP_FIXED_SAFE) == MAP_FIXED_SAFE) {
>
> I'm surprised this doesn't warn - since this effectively expands to:
>
> flags & MAP_FIXED | MAP_KEEP_MAPPING
>
> hence why MAP_FIXED_SAFE needs parens.
It sure does.
Thanks!
--
Michal Hocko
SUSE Labs
Re: linux-next: Tree for Nov 7
On Mon 13-11-17 16:16:41, Michal Hocko wrote: > On Mon 13-11-17 13:00:57, Michal Hocko wrote: > [...] > > Yes, I have mentioned that in the previous email but the amount of code > > would be even larger. Basically every arch which reimplements > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to > > do vma lookup. > > It turned out that this might be much more easier than I thought after > all. It seems we can really handle that in the common code. This would > mean that we are exposing a new functionality to the userspace though. > Myabe this would be useful on its own though. Just a quick draft (not > even compile tested) whether this makes sense in general. I would be > worried about unexpected behavior when somebody set other bit without a > good reason and we might fail with ENOMEM for such a call now. Hmm, the bigger problem would be the backward compatibility actually. We would get silent corruptions which is exactly what the flag is trying fix. mmap flags handling really sucks. So I guess we would have to make the flag internal only :/ -- Michal Hocko SUSE Labs
Re: linux-next: Tree for Nov 7
On Mon, Nov 13, 2017 at 04:16:41PM +0100, Michal Hocko wrote:
> On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> [...]
> > Yes, I have mentioned that in the previous email but the amount of code
> > would be even larger. Basically every arch which reimplements
> > arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> > do vma lookup.
>
> It turned out that this might be much more easier than I thought after
> all. It seems we can really handle that in the common code. This would
> mean that we are exposing a new functionality to the userspace though.
> Myabe this would be useful on its own though. Just a quick draft (not
> even compile tested) whether this makes sense in general. I would be
> worried about unexpected behavior when somebody set other bit without a
> good reason and we might fail with ENOMEM for such a call now.
>
> Elf loader would then use MAP_FIXED_SAFE rather than MAP_FIXED.
> ---
> diff --git a/arch/alpha/include/uapi/asm/mman.h
> b/arch/alpha/include/uapi/asm/mman.h
> index 3b26cc62dadb..d021c21f9b01 100644
> --- a/arch/alpha/include/uapi/asm/mman.h
> +++ b/arch/alpha/include/uapi/asm/mman.h
> @@ -31,6 +31,9 @@
> #define MAP_STACK0x8 /* give out an address that is best
> suited for process/thread stacks */
> #define MAP_HUGETLB 0x10/* create a huge page mapping */
>
> +#define MAP_KEEP_MAPPING 0x200
> +#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED
> without clobbering an existing mapping */
A few things...
1. Does this need to be exposed to userland?
2. Can it end up in include/uapi/asm-generic/mman*.h ?
3. The definition of MAP_FIXED_SAFE should really have parens around it.
> @@ -1365,6 +1365,13 @@ unsigned long do_mmap(struct file *file, unsigned long
> addr,
> if (offset_in_page(addr))
> return addr;
>
> + if ((flags & MAP_FIXED_SAFE) == MAP_FIXED_SAFE) {
I'm surprised this doesn't warn - since this effectively expands to:
flags & MAP_FIXED | MAP_KEEP_MAPPING
hence why MAP_FIXED_SAFE needs parens.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
Re: linux-next: Tree for Nov 7
On Mon 13-11-17 15:09:09, Russell King - ARM Linux wrote: > On Mon, Nov 13, 2017 at 03:11:40PM +0100, Michal Hocko wrote: > > On Mon 13-11-17 10:20:06, Michal Hocko wrote: > > > [Cc arm and ppc maintainers] > > > > > > Thanks a lot for testing! > > > > > > On Sun 12-11-17 11:38:02, Joel Stanley wrote: > > > > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko > > > > wrote: > > > > > Hi Joel, > > > > > > > > > > On Wed 08-11-17 15:20:50, Michal Hocko wrote: > > > > > [...] > > > > >> > There are a lot of messages on the way up that look like this: > > > > >> > > > > > >> > [2.527460] Uhuuh, elf segement at 000d9000 requested but the > > > > >> > memory is mapped already > > > > >> > [2.540160] Uhuuh, elf segement at 000d9000 requested but the > > > > >> > memory is mapped already > > > > >> > [2.546153] Uhuuh, elf segement at 000d9000 requested but the > > > > >> > memory is mapped already > > > > >> > > > > > >> > And then trying to run userspace looks like this: > > > > >> > > > > >> Could you please run with debugging patch posted > > > > >> http://lkml.kernel.org/r/20171107102854.vylrtaodla63k...@dhcp22.suse.cz > > > > > > > > > > Did you have chance to test with this debugging patch, please? > > > > > > > > Lots of this: > > > > > > > > [1.177266] Uhuuh, elf segement at 000d9000 requested but the > > > > memory is mapped already, got 000dd000 > > > > [1.177555] Clashing vma [dd000, de000] flags:100873 name:(null) > > > > > > This smells like the problem I've expected that mmap with hint doesn't > > > respect the hint even though there is no clashing mapping. The above > > > basically says that we didn't map at 0xd9000 but it has placed it at > > > 0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new > > > mapping. find_vma returns the closest vma (with addr < vm_end) for the > > > given address 0xd9000 so this address cannot be mapped by any other vma. > > > > > > Now that I am looking at arm's arch_get_unmapped_area it does perform > > > aligning for shared vmas. > > > > Sorry for confusion here. These are not shared mappings as pointed out > > by Russell in a private email. I got confused by the above flags which I > > have misinterpreted as bit 0 set => MAP_SHARED. These are vm_flags > > obviously so the bit 0 is VM_READ. Sorry about the confusion. The real > > reason we are doing the alignment is that we do a file mapping > > /* > > * We only need to do colour alignment if either the I or D > > * caches alias. > > */ > > if (aliasing) > > do_align = filp || (flags & MAP_SHARED); > > > > I am not really familiar with this architecture to understand why do we > > need aliasing for file mappings, though. > > I think it's there so that flush_dcache_page() works - possibly > get_user_pages() being used on a private mapping of page cache pages, > but that's guessing. I fail to see how the mixure of MAP_FIXED and regular mapping of the same file work then, but as I've said I really do not understand this code. > I'm afraid I don't remember all the details, this is code from around > 15 years ago, and I'd be very nervous about changing it now without > fully understanding the issues. Ohh, absolutely! I didn't dare to touch this code and that's why I took the easy way and simply opt-out from the harding for all those archs that are basically sharing this pattern. But after a closer look it seems that we can really introduce MAP_FIXED_SAFE that would keep the arch mmap code intact yet we would get the hardening for all archs. It would allow also allow a safer MAP_FIXED semantic for userspace. -- Michal Hocko SUSE Labs
Re: linux-next: Tree for Nov 7
On Mon 13-11-17 13:00:57, Michal Hocko wrote:
[...]
> Yes, I have mentioned that in the previous email but the amount of code
> would be even larger. Basically every arch which reimplements
> arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> do vma lookup.
It turned out that this might be much more easier than I thought after
all. It seems we can really handle that in the common code. This would
mean that we are exposing a new functionality to the userspace though.
Myabe this would be useful on its own though. Just a quick draft (not
even compile tested) whether this makes sense in general. I would be
worried about unexpected behavior when somebody set other bit without a
good reason and we might fail with ENOMEM for such a call now.
Elf loader would then use MAP_FIXED_SAFE rather than MAP_FIXED.
---
diff --git a/arch/alpha/include/uapi/asm/mman.h
b/arch/alpha/include/uapi/asm/mman.h
index 3b26cc62dadb..d021c21f9b01 100644
--- a/arch/alpha/include/uapi/asm/mman.h
+++ b/arch/alpha/include/uapi/asm/mman.h
@@ -31,6 +31,9 @@
#define MAP_STACK 0x8 /* give out an address that is best
suited for process/thread stacks */
#define MAP_HUGETLB0x10/* create a huge page mapping */
+#define MAP_KEEP_MAPPING 0x200
+#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without
clobbering an existing mapping */
+
#define MS_ASYNC 1 /* sync memory asynchronously */
#define MS_SYNC2 /* synchronous memory sync */
#define MS_INVALIDATE 4 /* invalidate the caches */
diff --git a/arch/mips/include/uapi/asm/mman.h
b/arch/mips/include/uapi/asm/mman.h
index da3216007fe0..51e3885fbfc1 100644
--- a/arch/mips/include/uapi/asm/mman.h
+++ b/arch/mips/include/uapi/asm/mman.h
@@ -49,6 +49,9 @@
#define MAP_STACK 0x4 /* give out an address that is best
suited for process/thread stacks */
#define MAP_HUGETLB0x8 /* create a huge page mapping */
+#define MAP_KEEP_MAPPING 0x200
+#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without
clobbering an existing mapping */
+
/*
* Flags for msync
*/
diff --git a/arch/parisc/include/uapi/asm/mman.h
b/arch/parisc/include/uapi/asm/mman.h
index cc9ba1d34779..5a4381484fc5 100644
--- a/arch/parisc/include/uapi/asm/mman.h
+++ b/arch/parisc/include/uapi/asm/mman.h
@@ -25,6 +25,9 @@
#define MAP_STACK 0x4 /* give out an address that is best
suited for process/thread stacks */
#define MAP_HUGETLB0x8 /* create a huge page mapping */
+#define MAP_KEEP_MAPPING 0x200
+#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without
clobbering an existing mapping */
+
#define MS_SYNC1 /* synchronous memory sync */
#define MS_ASYNC 2 /* sync memory asynchronously */
#define MS_INVALIDATE 4 /* invalidate the caches */
diff --git a/arch/xtensa/include/uapi/asm/mman.h
b/arch/xtensa/include/uapi/asm/mman.h
index b15b278aa314..5df8a81524da 100644
--- a/arch/xtensa/include/uapi/asm/mman.h
+++ b/arch/xtensa/include/uapi/asm/mman.h
@@ -62,6 +62,9 @@
# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */
#endif
+#define MAP_KEEP_MAPPING 0x200
+#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without
clobbering an existing mapping */
+
/*
* Flags for msync
*/
diff --git a/include/uapi/asm-generic/mman-common.h
b/include/uapi/asm-generic/mman-common.h
index 203268f9231e..22442846f5c8 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -25,6 +25,9 @@
# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */
#endif
+#define MAP_KEEP_MAPPING 0x200
+#define MAP_FIXED_SAFE MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED without
clobbering an existing mapping */
+
/*
* Flags for mlock
*/
diff --git a/mm/mmap.c b/mm/mmap.c
index 680506faceae..e53b6b15a8d9 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1365,6 +1365,13 @@ unsigned long do_mmap(struct file *file, unsigned long
addr,
if (offset_in_page(addr))
return addr;
+ if ((flags & MAP_FIXED_SAFE) == MAP_FIXED_SAFE) {
+ struct vm_area_struct *vma = find_vma(mm, addr);
+
+ if (vma && vma->vm_start <= addr)
+ return -ENOMEM;
+ }
+
if (prot == PROT_EXEC) {
pkey = execute_only_pkey(mm);
if (pkey < 0)
--
Michal Hocko
SUSE Labs
Re: linux-next: Tree for Nov 7
On Mon, Nov 13, 2017 at 03:11:40PM +0100, Michal Hocko wrote: > On Mon 13-11-17 10:20:06, Michal Hocko wrote: > > [Cc arm and ppc maintainers] > > > > Thanks a lot for testing! > > > > On Sun 12-11-17 11:38:02, Joel Stanley wrote: > > > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko wrote: > > > > Hi Joel, > > > > > > > > On Wed 08-11-17 15:20:50, Michal Hocko wrote: > > > > [...] > > > >> > There are a lot of messages on the way up that look like this: > > > >> > > > > >> > [2.527460] Uhuuh, elf segement at 000d9000 requested but the > > > >> > memory is mapped already > > > >> > [2.540160] Uhuuh, elf segement at 000d9000 requested but the > > > >> > memory is mapped already > > > >> > [2.546153] Uhuuh, elf segement at 000d9000 requested but the > > > >> > memory is mapped already > > > >> > > > > >> > And then trying to run userspace looks like this: > > > >> > > > >> Could you please run with debugging patch posted > > > >> http://lkml.kernel.org/r/20171107102854.vylrtaodla63k...@dhcp22.suse.cz > > > > > > > > Did you have chance to test with this debugging patch, please? > > > > > > Lots of this: > > > > > > [1.177266] Uhuuh, elf segement at 000d9000 requested but the memory > > > is mapped already, got 000dd000 > > > [1.177555] Clashing vma [dd000, de000] flags:100873 name:(null) > > > > This smells like the problem I've expected that mmap with hint doesn't > > respect the hint even though there is no clashing mapping. The above > > basically says that we didn't map at 0xd9000 but it has placed it at > > 0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new > > mapping. find_vma returns the closest vma (with addr < vm_end) for the > > given address 0xd9000 so this address cannot be mapped by any other vma. > > > > Now that I am looking at arm's arch_get_unmapped_area it does perform > > aligning for shared vmas. > > Sorry for confusion here. These are not shared mappings as pointed out > by Russell in a private email. I got confused by the above flags which I > have misinterpreted as bit 0 set => MAP_SHARED. These are vm_flags > obviously so the bit 0 is VM_READ. Sorry about the confusion. The real > reason we are doing the alignment is that we do a file mapping > /* >* We only need to do colour alignment if either the I or D >* caches alias. >*/ > if (aliasing) > do_align = filp || (flags & MAP_SHARED); > > I am not really familiar with this architecture to understand why do we > need aliasing for file mappings, though. I think it's there so that flush_dcache_page() works - possibly get_user_pages() being used on a private mapping of page cache pages, but that's guessing. I'm afraid I don't remember all the details, this is code from around 15 years ago, and I'd be very nervous about changing it now without fully understanding the issues. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
Re: linux-next: Tree for Nov 7
On Mon 13-11-17 10:20:06, Michal Hocko wrote: > [Cc arm and ppc maintainers] > > Thanks a lot for testing! > > On Sun 12-11-17 11:38:02, Joel Stanley wrote: > > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko wrote: > > > Hi Joel, > > > > > > On Wed 08-11-17 15:20:50, Michal Hocko wrote: > > > [...] > > >> > There are a lot of messages on the way up that look like this: > > >> > > > >> > [2.527460] Uhuuh, elf segement at 000d9000 requested but the > > >> > memory is mapped already > > >> > [2.540160] Uhuuh, elf segement at 000d9000 requested but the > > >> > memory is mapped already > > >> > [2.546153] Uhuuh, elf segement at 000d9000 requested but the > > >> > memory is mapped already > > >> > > > >> > And then trying to run userspace looks like this: > > >> > > >> Could you please run with debugging patch posted > > >> http://lkml.kernel.org/r/20171107102854.vylrtaodla63k...@dhcp22.suse.cz > > > > > > Did you have chance to test with this debugging patch, please? > > > > Lots of this: > > > > [1.177266] Uhuuh, elf segement at 000d9000 requested but the memory is > > mapped already, got 000dd000 > > [1.177555] Clashing vma [dd000, de000] flags:100873 name:(null) > > This smells like the problem I've expected that mmap with hint doesn't > respect the hint even though there is no clashing mapping. The above > basically says that we didn't map at 0xd9000 but it has placed it at > 0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new > mapping. find_vma returns the closest vma (with addr < vm_end) for the > given address 0xd9000 so this address cannot be mapped by any other vma. > > Now that I am looking at arm's arch_get_unmapped_area it does perform > aligning for shared vmas. Sorry for confusion here. These are not shared mappings as pointed out by Russell in a private email. I got confused by the above flags which I have misinterpreted as bit 0 set => MAP_SHARED. These are vm_flags obviously so the bit 0 is VM_READ. Sorry about the confusion. The real reason we are doing the alignment is that we do a file mapping /* * We only need to do colour alignment if either the I or D * caches alias. */ if (aliasing) do_align = filp || (flags & MAP_SHARED); I am not really familiar with this architecture to understand why do we need aliasing for file mappings, though. -- Michal Hocko SUSE Labs
Re: linux-next: Tree for Nov 7
On Mon 13-11-17 22:34:50, Michael Ellerman wrote: > Hi Michal, > > Michal Hocko writes: > > On Mon 13-11-17 10:20:06, Michal Hocko wrote: > >> [Cc arm and ppc maintainers] > > > > Hmm, it turned out to be a problem on other architectures as well. > > CCing more maintainers. For your reference, we are talking about > > http://lkml.kernel.org/r/20171023082608.6167-1-mho...@kernel.org > > which has broken architectures which do apply aligning on the mmap > > address hint without MAP_FIXED applied. See below my proposed way > > around this issue because I belive that the above patch is quite > > valuable on its own to be dropped for all archs. > > I don't really like your solution sorry :) The fact that you've had to > patch seven arches seems like a red flag. > > I think this is a generic problem with MAP_FIXED, which I've heard > userspace folks complain about in the past. The thing is that we canno change MAP_FIXED behavior as it is carved in stone > Currently MAP_FIXED does two things: > 1. makes addr not a hint but the required address > 2. blasts any existing mapping > > You want 1) but not 2). + fail if there is a clashing range > So the right solution IMHO would be to add a new mmap flag to request > that behaviour, ie. a fixed address but iff there is nothing already > mapped there. > > I don't know the mm code well enough to know if that's hard for some > reason, but it *seems* like it should be doable. Yes, I have mentioned that in the previous email but the amount of code would be even larger. Basically every arch which reimplements arch_get_unmapped_area would have to special case new MAP_FIXED flag to do vma lookup. So this was the most simple solution I could come up with. If there was a general interest for MAP_FIXED_SAFE then we can introduce it later of course. I would just like the hardening merged sooner rather than later. -- Michal Hocko SUSE Labs
Re: linux-next: Tree for Nov 7
Hi Michal, Michal Hocko writes: > On Mon 13-11-17 10:20:06, Michal Hocko wrote: >> [Cc arm and ppc maintainers] > > Hmm, it turned out to be a problem on other architectures as well. > CCing more maintainers. For your reference, we are talking about > http://lkml.kernel.org/r/20171023082608.6167-1-mho...@kernel.org > which has broken architectures which do apply aligning on the mmap > address hint without MAP_FIXED applied. See below my proposed way > around this issue because I belive that the above patch is quite > valuable on its own to be dropped for all archs. I don't really like your solution sorry :) The fact that you've had to patch seven arches seems like a red flag. I think this is a generic problem with MAP_FIXED, which I've heard userspace folks complain about in the past. Currently MAP_FIXED does two things: 1. makes addr not a hint but the required address 2. blasts any existing mapping You want 1) but not 2). So the right solution IMHO would be to add a new mmap flag to request that behaviour, ie. a fixed address but iff there is nothing already mapped there. I don't know the mm code well enough to know if that's hard for some reason, but it *seems* like it should be doable. cheers
Re: linux-next: Tree for Nov 7
On Mon 13-11-17 10:20:06, Michal Hocko wrote: > [Cc arm and ppc maintainers] Hmm, it turned out to be a problem on other architectures as well. CCing more maintainers. For your reference, we are talking about http://lkml.kernel.org/r/20171023082608.6167-1-mho...@kernel.org which has broken architectures which do apply aligning on the mmap address hint without MAP_FIXED applied. See below my proposed way around this issue because I belive that the above patch is quite valuable on its own to be dropped for all archs. > Thanks a lot for testing! > > On Sun 12-11-17 11:38:02, Joel Stanley wrote: > > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko wrote: > > > Hi Joel, > > > > > > On Wed 08-11-17 15:20:50, Michal Hocko wrote: > > > [...] > > >> > There are a lot of messages on the way up that look like this: > > >> > > > >> > [2.527460] Uhuuh, elf segement at 000d9000 requested but the > > >> > memory is mapped already > > >> > [2.540160] Uhuuh, elf segement at 000d9000 requested but the > > >> > memory is mapped already > > >> > [2.546153] Uhuuh, elf segement at 000d9000 requested but the > > >> > memory is mapped already > > >> > > > >> > And then trying to run userspace looks like this: > > >> > > >> Could you please run with debugging patch posted > > >> http://lkml.kernel.org/r/20171107102854.vylrtaodla63k...@dhcp22.suse.cz > > > > > > Did you have chance to test with this debugging patch, please? > > > > Lots of this: > > > > [1.177266] Uhuuh, elf segement at 000d9000 requested but the memory is > > mapped already, got 000dd000 > > [1.177555] Clashing vma [dd000, de000] flags:100873 name:(null) > > This smells like the problem I've expected that mmap with hint doesn't > respect the hint even though there is no clashing mapping. The above > basically says that we didn't map at 0xd9000 but it has placed it at > 0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new > mapping. find_vma returns the closest vma (with addr < vm_end) for the > given address 0xd9000 so this address cannot be mapped by any other vma. > > Now that I am looking at arm's arch_get_unmapped_area it does perform > aligning for shared vmas. We do not do that for MAP_FIXED. Powepc, > reported earlier [1] seems to suffer from the similar problem. > slice_get_unmapped_area alignes to slices, whatever that means. > > I can see two possible ways around that. Either we explicitly request > non-aligned mappings via a special MAP_$FOO (e.g. MAP_FIXED_SAFE) or > simply opt out from the MAP_FIXED protection via ifdefs. The first > option sounds more generic to me but also more tricky to not introduce > other user visible effects. The later is quite straightforward. What do > you think about the following on top of the previous patch? > > It is rather terse and disables the MAP_FIXED protection for arm > comletely because I couldn't find a way to make it conditional on > CACHEID_VIPT_ALIASING. But this can be always handled later. I find the > protection for other archtectures useful enough to have this working for > most architectures now and handle others specially. > > [1] http://lkml.kernel.org/r/1510048229.12079.7.ca...@abdul.in.ibm.com > --- diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 61a0cb15067e..018d041a30e6 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -99,6 +99,7 @@ config ARM select PERF_USE_VMALLOC select RTC_LIB select SYS_SUPPORTS_APM_EMULATION + select ARCH_ALIGNED_MMAPS # Above selects are sorted alphabetically; please add new ones # according to that. Thanks. help diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 48d91d5be4e9..eca59d27e9f1 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -72,6 +72,7 @@ config MIPS select RTC_LIB if !MACH_LOONGSON64 select SYSCTL_EXCEPTION_TRACE select VIRT_TO_BUS + select ARCH_ALIGNED_MMAPS menu "Machine selection" diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index 22f27ec8c117..8376d16e0a4a 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -40,6 +40,7 @@ config PARISC select GENERIC_CLOCKEVENTS select ARCH_NO_COHERENT_DMA_MMAP select CPU_NO_EFFICIENT_FFS + select ARCH_ALIGNED_MMAPS help The PA-RISC microprocessor is designed by Hewlett-Packard and used diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 2f629e0551e9..156f69c09c7f 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -368,6 +368,7 @@ config PPC_MM_SLICES bool default y if PPC_STD_MMU_64 default n + select ARCH_ALIGNED_MMAPS config PPC_HAVE_PMU_SUPPORT bool diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 640a85925060..ac1d4637a728 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -49,6 +49,7 @@ config SUPERH select HAVE_ARCH_AUDITSYSCALL
Re: linux-next: Tree for Nov 7
On Mon, Nov 13, 2017 at 10:20:06AM +0100, Michal Hocko wrote: > [Cc arm and ppc maintainers] > > Thanks a lot for testing! > > On Sun 12-11-17 11:38:02, Joel Stanley wrote: > > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko wrote: > > > Hi Joel, > > > > > > On Wed 08-11-17 15:20:50, Michal Hocko wrote: > > > [...] > > >> > There are a lot of messages on the way up that look like this: > > >> > > > >> > [2.527460] Uhuuh, elf segement at 000d9000 requested but the > > >> > memory is mapped already > > >> > [2.540160] Uhuuh, elf segement at 000d9000 requested but the > > >> > memory is mapped already > > >> > [2.546153] Uhuuh, elf segement at 000d9000 requested but the > > >> > memory is mapped already > > >> > > > >> > And then trying to run userspace looks like this: > > >> > > >> Could you please run with debugging patch posted > > >> http://lkml.kernel.org/r/20171107102854.vylrtaodla63k...@dhcp22.suse.cz > > > > > > Did you have chance to test with this debugging patch, please? > > > > Lots of this: > > > > [1.177266] Uhuuh, elf segement at 000d9000 requested but the memory is > > mapped already, got 000dd000 > > [1.177555] Clashing vma [dd000, de000] flags:100873 name:(null) > > This smells like the problem I've expected that mmap with hint doesn't > respect the hint even though there is no clashing mapping. The above > basically says that we didn't map at 0xd9000 but it has placed it at > 0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new > mapping. find_vma returns the closest vma (with addr < vm_end) for the > given address 0xd9000 so this address cannot be mapped by any other vma. > > Now that I am looking at arm's arch_get_unmapped_area it does perform > aligning for shared vmas. We do not do that for MAP_FIXED. Powepc, > reported earlier [1] seems to suffer from the similar problem. > slice_get_unmapped_area alignes to slices, whatever that means. > > I can see two possible ways around that. Either we explicitly request > non-aligned mappings via a special MAP_$FOO (e.g. MAP_FIXED_SAFE) or > simply opt out from the MAP_FIXED protection via ifdefs. The first > option sounds more generic to me but also more tricky to not introduce > other user visible effects. The later is quite straightforward. What do > you think about the following on top of the previous patch? > > It is rather terse and disables the MAP_FIXED protection for arm > comletely because I couldn't find a way to make it conditional on > CACHEID_VIPT_ALIASING. But this can be always handled later. I find the > protection for other archtectures useful enough to have this working for > most architectures now and handle others specially. Can someone provide the background information for this please? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
Re: linux-next: Tree for Nov 7
[Cc arm and ppc maintainers]
Thanks a lot for testing!
On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko wrote:
> > Hi Joel,
> >
> > On Wed 08-11-17 15:20:50, Michal Hocko wrote:
> > [...]
> >> > There are a lot of messages on the way up that look like this:
> >> >
> >> > [2.527460] Uhuuh, elf segement at 000d9000 requested but the
> >> > memory is mapped already
> >> > [2.540160] Uhuuh, elf segement at 000d9000 requested but the
> >> > memory is mapped already
> >> > [2.546153] Uhuuh, elf segement at 000d9000 requested but the
> >> > memory is mapped already
> >> >
> >> > And then trying to run userspace looks like this:
> >>
> >> Could you please run with debugging patch posted
> >> http://lkml.kernel.org/r/20171107102854.vylrtaodla63k...@dhcp22.suse.cz
> >
> > Did you have chance to test with this debugging patch, please?
>
> Lots of this:
>
> [1.177266] Uhuuh, elf segement at 000d9000 requested but the memory is
> mapped already, got 000dd000
> [1.177555] Clashing vma [dd000, de000] flags:100873 name:(null)
This smells like the problem I've expected that mmap with hint doesn't
respect the hint even though there is no clashing mapping. The above
basically says that we didn't map at 0xd9000 but it has placed it at
0xdd000. The nearest (clashing) vma is at 0xdd000 so this is our new
mapping. find_vma returns the closest vma (with addr < vm_end) for the
given address 0xd9000 so this address cannot be mapped by any other vma.
Now that I am looking at arm's arch_get_unmapped_area it does perform
aligning for shared vmas. We do not do that for MAP_FIXED. Powepc,
reported earlier [1] seems to suffer from the similar problem.
slice_get_unmapped_area alignes to slices, whatever that means.
I can see two possible ways around that. Either we explicitly request
non-aligned mappings via a special MAP_$FOO (e.g. MAP_FIXED_SAFE) or
simply opt out from the MAP_FIXED protection via ifdefs. The first
option sounds more generic to me but also more tricky to not introduce
other user visible effects. The later is quite straightforward. What do
you think about the following on top of the previous patch?
It is rather terse and disables the MAP_FIXED protection for arm
comletely because I couldn't find a way to make it conditional on
CACHEID_VIPT_ALIASING. But this can be always handled later. I find the
protection for other archtectures useful enough to have this working for
most architectures now and handle others specially.
[1] http://lkml.kernel.org/r/1510048229.12079.7.ca...@abdul.in.ibm.com
---
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 61a0cb15067e..018d041a30e6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -99,6 +99,7 @@ config ARM
select PERF_USE_VMALLOC
select RTC_LIB
select SYS_SUPPORTS_APM_EMULATION
+ select ARCH_ALIGNED_MMAPS
# Above selects are sorted alphabetically; please add new ones
# according to that. Thanks.
help
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index 2f629e0551e9..156f69c09c7f 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -368,6 +368,7 @@ config PPC_MM_SLICES
bool
default y if PPC_STD_MMU_64
default n
+ select ARCH_ALIGNED_MMAPS
config PPC_HAVE_PMU_SUPPORT
bool
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index a22718de42db..d23eb89f31c0 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -345,13 +345,19 @@ static unsigned long elf_vm_mmap(struct file *filep,
unsigned long addr,
unsigned long size, int prot, int type, unsigned long off)
{
unsigned long map_addr;
+ unsigned long map_type = type;
/*
* If caller requests the mapping at a specific place, make sure we fail
* rather than potentially clobber an existing mapping which can have
-* security consequences (e.g. smash over the stack area).
+* security consequences (e.g. smash over the stack area). Be careful
+* about architectures which do not respect the address hint due to
+* aligning restrictions for !fixed mappings.
*/
- map_addr = vm_mmap(filep, addr, size, prot, type & ~MAP_FIXED, off);
+ if (!IS_ENABLED(ARCH_ALIGNED_MMAPS))
+ map_type &= ~MAP_FIXED;
+
+ map_addr = vm_mmap(filep, addr, size, prot, map_type, off);
if (BAD_ADDR(map_addr))
return map_addr;
--
Michal Hocko
SUSE Labs
Re: linux-next: Tree for Nov 7
On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko wrote: > Hi Joel, > > On Wed 08-11-17 15:20:50, Michal Hocko wrote: > [...] >> > There are a lot of messages on the way up that look like this: >> > >> > [2.527460] Uhuuh, elf segement at 000d9000 requested but the >> > memory is mapped already >> > [2.540160] Uhuuh, elf segement at 000d9000 requested but the >> > memory is mapped already >> > [2.546153] Uhuuh, elf segement at 000d9000 requested but the >> > memory is mapped already >> > >> > And then trying to run userspace looks like this: >> >> Could you please run with debugging patch posted >> http://lkml.kernel.org/r/20171107102854.vylrtaodla63k...@dhcp22.suse.cz > > Did you have chance to test with this debugging patch, please? Lots of this: [1.177266] Uhuuh, elf segement at 000d9000 requested but the memory is mapped already, got 000dd000 [1.177555] Clashing vma [dd000, de000] flags:100873 name:(null) Full log is attached. If you want to reproduce yourself and have an arm compiler lying around: $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make aspeed_g5_defconfig $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make $ qemu-system-arm -M ast2500-evb -nographic -nodefaults -serial stdio \ -kernel arch/arm/boot/zImage \ -dtb arch/arm/boot/dts/aspeed-ast2500-evb.dtb I'm using Qemu 2.10 which current distros ship. ymmv with older releases. Cheers, Joel next-20171107-failure-debugging Description: Binary data
Re: linux-next: Tree for Nov 7
Hi Joel, On Wed 08-11-17 15:20:50, Michal Hocko wrote: [...] > > There are a lot of messages on the way up that look like this: > > > > [2.527460] Uhuuh, elf segement at 000d9000 requested but the > > memory is mapped already > > [2.540160] Uhuuh, elf segement at 000d9000 requested but the > > memory is mapped already > > [2.546153] Uhuuh, elf segement at 000d9000 requested but the > > memory is mapped already > > > > And then trying to run userspace looks like this: > > Could you please run with debugging patch posted > http://lkml.kernel.org/r/20171107102854.vylrtaodla63k...@dhcp22.suse.cz Did you have chance to test with this debugging patch, please? -- Michal Hocko SUSE Labs
Re: linux-next: Tree for Nov 7
Hi, On Wed 08-11-17 08:52:24, Joel Stanley wrote: > Hello Michal, > > On Tue, Nov 7, 2017 at 3:52 PM, Stephen Rothwell > wrote: > > Hi all, > > > > Changes since 20171106: > > > > The powerpc tree still had its build failure for which I applied a patch. > > > > The crypto tree lost its build failure. > > > > The akpm tree still had its build failure for which I reverted a commit. > > > > Non-merge commits (relative to Linus' tree): 10912 > > 10165 files changed, 524042 insertions(+), 247066 deletions(-) > > I tried to boot this -next tree built for the ARM platform I maintain, > and it did not make it to userspace. When I revert your patch > "fs/binfmt_elf.c: drop MAP_FIXED usage from elf_map" the system boots > as expected. > > There are a lot of messages on the way up that look like this: > > [2.527460] Uhuuh, elf segement at 000d9000 requested but the > memory is mapped already > [2.540160] Uhuuh, elf segement at 000d9000 requested but the > memory is mapped already > [2.546153] Uhuuh, elf segement at 000d9000 requested but the > memory is mapped already > > And then trying to run userspace looks like this: Could you please run with debugging patch posted http://lkml.kernel.org/r/20171107102854.vylrtaodla63k...@dhcp22.suse.cz -- Michal Hocko SUSE Labs
Re: linux-next: Tree for Nov 7
Hello Michal, On Tue, Nov 7, 2017 at 3:52 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20171106: > > The powerpc tree still had its build failure for which I applied a patch. > > The crypto tree lost its build failure. > > The akpm tree still had its build failure for which I reverted a commit. > > Non-merge commits (relative to Linus' tree): 10912 > 10165 files changed, 524042 insertions(+), 247066 deletions(-) I tried to boot this -next tree built for the ARM platform I maintain, and it did not make it to userspace. When I revert your patch "fs/binfmt_elf.c: drop MAP_FIXED usage from elf_map" the system boots as expected. There are a lot of messages on the way up that look like this: [2.527460] Uhuuh, elf segement at 000d9000 requested but the memory is mapped already [2.540160] Uhuuh, elf segement at 000d9000 requested but the memory is mapped already [2.546153] Uhuuh, elf segement at 000d9000 requested but the memory is mapped already And then trying to run userspace looks like this: [3.116476] Uhuuh, elf segement at 000d9000 requested but the memory is mapped already [3.116988] Failed to execute /init (error -11) [3.117713] Starting init: /sbin/init exists but couldn't execute it (error -14) [3.118879] Starting init: /bin/sh exists but couldn't execute it (error -14) [3.119186] Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. [3.119683] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc8-next-20171107-00016-g9f804d9fa870 #55 [3.119933] Hardware name: Generic DT based system [3.120205] [<8000fa9c>] (unwind_backtrace) from [<8000d2dc>] (show_stack+0x10/0x14) [3.120462] [<8000d2dc>] (show_stack) from [<800174bc>] (panic+0xb8/0x244) [3.120688] [<800174bc>] (panic) from [<80355298>] (kernel_init+0xc8/0xf0) [3.120880] [<80355298>] (kernel_init) from [<8000a5e0>] (ret_from_fork+0x14/0x34) I've built the aspeed_g5_defconfig, which is a 32 bit ARM machine. The full dmesg is attached. I noted a report of this for ppc64, but I'm not on that list: https://marc.info/?l=linuxppc-embedded&m=151005537413751&w=2 Cheers, Joel next-20171107-failure Description: Binary data
linux-next: Tree for Nov 7
Hi all, Changes since 20171106: The powerpc tree still had its build failure for which I applied a patch. The crypto tree lost its build failure. The akpm tree still had its build failure for which I reverted a commit. Non-merge commits (relative to Linus' tree): 10912 10165 files changed, 524042 insertions(+), 247066 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 272 trees (counting Linus' and 42 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (136fc5c41f34 scripts: add leaking_addresses.pl) Merging fixes/master (820bf5c419e4 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging kbuild-current/fixes (bb3f38c3c5b7 kbuild: clang: fix build failures with sparse check) Merging arc-current/for-curr (fdbed19697e1 ARC: unbork module link errors with !CONFIG_ARC_HAS_LLSC) Merging arm-current/fixes (dad4675388fc ARM: add debug ".edata_real" symbol) Merging m68k-current/for-linus (558d5ad276c9 m68k/mac: Avoid soft-lockup warning after mach_power_off) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (7ecb37f62fe5 powerpc/perf: Fix core-imc hotplug callback failure during imc initialization) Merging sparc/master (23198ddffb6c sparc32: Add cmpxchg64().) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (d09b9e60e06d tcp: fix DSACK-based undo on non-duplicate ACK) Merging ipsec/master (c9f3f813d462 xfrm: Fix stack-out-of-bounds read in xfrm_state_find.) Merging netfilter/master (7400bb4b5800 netfilter: nf_reject_ipv4: Fix use-after-free in send_reset) Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook mask only if set) Merging wireless-drivers/master (a6127b4440d1 Merge tag 'iwlwifi-for-kalle-2017-10-06' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (9618aec3349b Merge tag 'mac80211-for-davem-2017-10-25' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging sound-current/for-linus (9b7d869ee5a7 ALSA: timer: Limit max instances per timer) Merging pci-current/for-linus (814eae5982cc alpha/PCI: Move pci_map_irq()/pci_swizzle() out of initdata) Merging driver-core.current/driver-core-linus (39dae59d66ac Linux 4.14-rc8) Merging tty.current/tty-linus (8a5776a5f498 Linux 4.14-rc4) Merging usb.current/usb-linus (bb176f67090c Linux 4.14-rc6) Merging usb-gadget-fixes/fixes (7c80f9e4a588 usb: usbtest: fix NULL pointer dereference) Merging usb-serial-fixes/usb-linus (0b07194bb55e Linux 4.14-rc7) Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: check before accessing ci_role in ci_role_show) Merging phy/fixes (2fb850092fd9 phy: rockchip-typec: Check for errors from tcphy_phy_init()) Merging staging.current/staging-linus (bb176f67090c Linux 4.14-rc6) Merging char-misc.current/char-misc-linus (bb176f67090c Linux 4.14-rc6) Merging input-current/for-linus (6f29c244075c Input: sparse-keymap - send sync event for KE_SW/KE_VSW) Merging crypto-current/master (441f99c90497 crypto: ccm - preserve the IV buffer) Merging ide/master (b671e1703394 PNP: ide: constify pnp_device_id) Merging vfio-fixes/for-linus (796b755066dd vfio/pci: Fix handl
linux-next: Tree for Nov 7
Hi all, Changes since 20131106: The vfs tree gained a build failure so I used the version from next-20131106. The drm tree gained conflicts against Linus' tree. The drm-intel tree gained a conflict against the drm tree. The audit tree lost its build failure. The akpm-current tree gained a conflict against the kbuild tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 210 trees (counting Linus' and 29 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (be408cd3e1fe Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (fa8218def1b1 Merge tag 'regmap-v3.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (68195fadb2a0 ARC: [plat-arcfpga] defconfig update) Merging arm-current/fixes (384b38b66947 ARM: 7873/1: vfp: clear vfp_current_hw_state for dying cpu) Merging m68k-current/for-linus (55490050df0f m68k/atari: ARAnyM - Always use physical addresses in NatFeat calls) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (8b5ede69d24d powerpc/irq: Don't switch to irq stack from softirq stack) Merging sparc/master (6d15ee492809 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging net/master (be408cd3e1fe Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (84502b5ef984 xfrm: Fix null pointer dereference when decoding sessions) Merging sound-current/for-linus (8e35cd4ac996 ALSA: HDA - Limit mic boost and add mute LED for an HP machine) Merging pci-current/for-linus (67d470e0e171 Revert "x86/PCI: MMCONFIG: Check earlier for MMCONFIG region at address zero") Merging wireless/master (8ce9beac4661 drivers: net: wireless: b43: Fix possible NULL ptr dereference) Merging driver-core.current/driver-core-linus (31d141e3a666 Linux 3.12-rc6) Merging tty.current/tty-linus (6e757ad2c92c tty/serial: at91: fix uart/usart selection for older products) Merging usb.current/usb-linus (e1466ad5b1ae USB: serial: ftdi_sio: add id for Z3X Box device) Merging staging.current/staging-linus (31d141e3a666 Linux 3.12-rc6) Merging char-misc.current/char-misc-linus (31d141e3a666 Linux 3.12-rc6) Merging input-current/for-linus (5beea882e641 Input: ALPS - add support for model found on Dell XT2) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (f262f0f5cad0 crypto: s390 - Fix aes-cbc IV corruption) Merging ide/master (64110c16e012 ide: sgiioc4: Staticize ioc4_ide_attach_one()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (1931ee143b0a Revert "drivers: of: add initialization code for dma reserved memory") Merging rr-fixes/fixes (f6537f2f0eba scripts/kallsyms: filter symbols not in kernel address space) Merging mfd-fixes/master (d0e639c9e06d Linux 3.12-rc4) Merging vfio-fixes/for-linus (d93b3ac0edb8 VFIO: vfio_iommu_type
linux-next: Tree for Nov 7
Hi all, /me resists commenting on recent political events Changes since 20121106: The pci tree still has its build failure for which I applied a merge fix patch. The v4l-dvb tree lost its build failure but gained another so I used the version from next-20121026. The pinctrl tree gained a build failure for which I applied a patch. The arm-soc tree gained a conflict against the l2-mtd and pinctrl trees. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 209 trees (counting Linus' and 28 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (3d70f8c Linux 3.7-rc4) Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux) Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by list_head-style lists.) Merging arm-current/fixes (6404f0b ARM: 7569/1: mm: uninitialized warning corrections) Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp) Merging powerpc-merge/merge (8c23f40 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging sparc/master (f7e8d9f qlogicpti: Fix build warning.) Merging net/master (cacb6ba net: inet_diag -- Return error code if protocol handler is missed) Merging sound-current/for-linus (ae24c31 ALSA: hda - Force to reset IEC958 status bits for AD codecs) Merging pci-current/for-linus (ff8e59b PCI/portdrv: Don't create hotplug slots unless port supports hotplug) Merging wireless/master (6fe7cc7 ath9k: Test for TID only in BlockAcks while checking tx status) Merging driver-core.current/driver-core-linus (8f0d816 Linux 3.7-rc3) Merging tty.current/tty-linus (8f0d816 Linux 3.7-rc3) Merging usb.current/usb-linus (d99e65b USB: fix build with XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled) Merging staging.current/staging-linus (8f0d816 Linux 3.7-rc3) Merging char-misc.current/char-misc-linus (8f0d816 Linux 3.7-rc3) Merging input-current/for-linus (32ed191 Input: tsc40 - remove wrong announcement of pressure support) Merging md-current/for-linus (ed30be0 MD RAID10: Fix oops when creating RAID10 arrays via dm-raid.c) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (9efade1 crypto: cryptd - disable softirqs in cryptd_queue_worker to prevent data corruption) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging rr-fixes/fixes (f6a79af modules: don't break modules_install on external modules with no key.) Merging asm-generic/master (9b04ebd asm-generic/io.h: remove asm/cacheflush.h include) Merging arm/for-next (31ccae2 Merge remote-tr
