aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-10-31fs/hfs/extent.c: fix array out of bounds read of array extentColin Ian King1-1/+1
Currently extent and index i are both being incremented causing an array out of bounds read on extent[i]. Fix this by removing the extraneous increment of extent. Ernesto said: : This is only triggered when deleting a file with a resource fork. I : may be wrong because the documentation isn't clear, but I don't think : you can create those under linux. So I guess nobody was testing them. : : > A disk space leak, perhaps? : : That's what it looks like in general. hfs_free_extents() won't do : anything if the block count doesn't add up, and the error will be : ignored. Now, if the block count randomly does add up, we could see : some corruption. Detected by CoverityScan, CID#711541 ("Out of bounds read") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Ernesto A. Fernndez <[email protected]> Cc: David Howells <[email protected]> Cc: Al Viro <[email protected]> Cc: Hin-Tak Leung <[email protected]> Cc: Vyacheslav Dubeyko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31hfs: update timestamp on truncate()Ernesto A. Fernández1-0/+2
The vfs takes care of updating mtime on ftruncate(), but on truncate() it must be done by the module. Link: http://lkml.kernel.org/r/e1611eda2985b672ed2d8677350b4ad8c2d07e8a.1539316825.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández <[email protected]> Reviewed-by: Vyacheslav Dubeyko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31hfsplus: update timestamps on truncate()Ernesto A. Fernández1-0/+1
The vfs takes care of updating ctime and mtime on ftruncate(), but on truncate() it must be done by the module. This patch can be tested with xfstests generic/313. Link: http://lkml.kernel.org/r/9beb0913eea37288599e8e1b7cec8768fb52d1b8.1539316825.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández <[email protected]> Reviewed-by: Vyacheslav Dubeyko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31hfs: fix return value of hfs_get_block()Ernesto A. Fernández1-1/+3
Direct writes to empty inodes fail with EIO. The generic direct-io code is in part to blame (a patch has been submitted as "direct-io: allow direct writes to empty inodes"), but hfs is worse affected than the other filesystems because the fallback to buffered I/O doesn't happen. The problem is the return value of hfs_get_block() when called with !create. Change it to be more consistent with the other modules. Link: http://lkml.kernel.org/r/4538ab8c35ea37338490525f0f24cbc37227528c.1539195310.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández <[email protected]> Reviewed-by: Vyacheslav Dubeyko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31hfsplus: fix return value of hfsplus_get_block()Ernesto A. Fernández1-1/+3
Direct writes to empty inodes fail with EIO. The generic direct-io code is in part to blame (a patch has been submitted as "direct-io: allow direct writes to empty inodes"), but hfsplus is worse affected than the other filesystems because the fallback to buffered I/O doesn't happen. The problem is the return value of hfsplus_get_block() when called with !create. Change it to be more consistent with the other modules. Link: http://lkml.kernel.org/r/2cd1301404ec7cf1e39c8f11a01a4302f1460ad6.1539195310.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández <[email protected]> Reviewed-by: Vyacheslav Dubeyko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31hfs: prevent btree data loss on ENOSPCErnesto A. Fernández4-16/+46
Inserting a new record in a btree may require splitting several of its nodes. If we hit ENOSPC halfway through, the new nodes will be left orphaned and their records will be lost. This could mean lost inodes or extents. Henceforth, check the available disk space before making any changes. This still leaves the potential problem of corruption on ENOMEM. There is no need to reserve space before deleting a catalog record, as we do for hfsplus. This difference is because hfs index nodes have fixed length keys. Link: http://lkml.kernel.org/r/ab5fc8a7d5ffccfd5f27b1cf2cb4ceb6c110da74.1536269131.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández <[email protected]> Cc: Christoph Hellwig <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31hfsplus: prevent btree data loss on ENOSPCErnesto A. Fernández5-16/+68
Inserting or deleting a record in a btree may require splitting several of its nodes. If we hit ENOSPC halfway through, the new nodes will be left orphaned and their records will be lost. This could mean lost inodes, extents or xattrs. Henceforth, check the available disk space before making any changes. This still leaves the potential problem of corruption on ENOMEM. The patch can be tested with xfstests generic/027. Link: http://lkml.kernel.org/r/4596eef22fbda137b4ffa0272d92f0da15364421.1536269129.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández <[email protected]> Cc: Christoph Hellwig <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31hfs: fix BUG on bnode parent updateErnesto A. Fernández1-0/+1
hfs_brec_update_parent() may hit BUG_ON() if the first record of both a leaf node and its parent are changed, and if this forces the parent to be split. It is not possible for this to happen on a valid hfs filesystem because the index nodes have fixed length keys. For reasons I ignore, the hfs module does have support for a number of hfsplus features. A corrupt btree header may report variable length keys and trigger this BUG, so it's better to fix it. Link: http://lkml.kernel.org/r/cf9b02d57f806217a2b1bf5db8c3e39730d8f603.1535682463.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Viacheslav Dubeyko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31hfs: prevent btree data loss on root splitErnesto A. Fernández1-0/+4
This bug is triggered whenever hfs_brec_update_parent() needs to split the root node. The height of the btree is not increased, which leaves the new node orphaned and its records lost. It is not possible for this to happen on a valid hfs filesystem because the index nodes have fixed length keys. For reasons I ignore, the hfs module does have support for a number of hfsplus features. A corrupt btree header may report variable length keys and trigger this bug, so it's better to fix it. Link: http://lkml.kernel.org/r/9750b1415685c4adca10766895f6d5ef12babdb0.1535682463.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández <[email protected]> Cc: Christoph Hellwig <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31hfsplus: fix BUG on bnode parent updateErnesto A. Fernández1-0/+1
Creating, renaming or deleting a file may hit BUG_ON() if the first record of both a leaf node and its parent are changed, and if this forces the parent to be split. This bug is triggered by xfstests generic/027, somewhat rarely; here is a more reliable reproducer: truncate -s 50M fs.iso mkfs.hfsplus fs.iso mount fs.iso /mnt i=1000 while [ $i -le 2400 ]; do touch /mnt/$i &>/dev/null ((++i)) done i=2400 while [ $i -ge 1000 ]; do mv /mnt/$i /mnt/$(perl -e "print $i x61") &>/dev/null ((--i)) done The issue is that a newly created bnode is being put twice. Reset new_node to NULL in hfs_brec_update_parent() before reaching goto again. Link: http://lkml.kernel.org/r/5ee1db09b60373a15890f6a7c835d00e76bf601d.1535682461.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández <[email protected]> Cc: Christoph Hellwig <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31hfsplus: prevent btree data loss on root splitErnesto A. Fernández1-0/+4
Creating, renaming or deleting a file may cause catalog corruption and data loss. This bug is randomly triggered by xfstests generic/027, but here is a faster reproducer: truncate -s 50M fs.iso mkfs.hfsplus fs.iso mount fs.iso /mnt i=100 while [ $i -le 150 ]; do touch /mnt/$i &>/dev/null ((++i)) done i=100 while [ $i -le 150 ]; do mv /mnt/$i /mnt/$(perl -e "print $i x82") &>/dev/null ((++i)) done umount /mnt fsck.hfsplus -n fs.iso The bug is triggered whenever hfs_brec_update_parent() needs to split the root node. The height of the btree is not increased, which leaves the new node orphaned and its records lost. Link: http://lkml.kernel.org/r/26d882184fc43043a810114258f45277752186c7.1535682461.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández <[email protected]> Cc: Christoph Hellwig <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31init/do_mounts.c: add root=PARTLABEL=<name> supportNikolaus Voss1-0/+31
Support referencing the root partition label from GPT as argument to the root= option on the kernel command line in analogy to referencing the partition uuid as root=PARTUUID=<uuid>. Specifying the partition label instead of the uuid is often much easier, e.g. in embedded environments when there is an A/B rootfs partition scheme for interruptible firmware updates (i.e. rootfsA/ rootfsB). The partition label can be queried with the blkid command. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Nikolaus Voss <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Dominik Brodowski <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Al Viro <[email protected]> Cc: Jens Axboe <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31checkpatch: remove GCC_BINARY_CONSTANT warningChristophe Leroy1-11/+0
This warning was there to avoid the use of 0bxxx values as they are not supported by gcc prior to v4.3 Since cafa0010cd51f ("Raise the minimum required gcc version to 4.6"), it's not an issue anymore and using such values can increase readability of code. Joe said: : Seems sensible as the other compilers also support binary literals from : relatively old versions. : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf : https://software.intel.com/en-us/articles/c14-features-supported-by-intel-c-compiler Link: http://lkml.kernel.org/r/392eeae782302ee8812a3c932a602035deed1609.1535351453.git.christophe.leroy@c-s.fr Signed-off-by: Christophe Leroy <[email protected]> Cc: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31include/linux/compat.h: mark expected switch fall-throughsGustavo A. R. Silva1-0/+3
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Gustavo A. R. Silva <[email protected]> Acked-by: Kees Cook <[email protected]> Cc: Michael Ellerman <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31lib/kstrtox.c: delete unnecessary castsAlexey Dobriyan1-8/+8
Implicit casts to the same type are done by the language if necessary. Link: http://lkml.kernel.org/r/20181014223934.GA18107@avx2 Signed-off-by: Alexey Dobriyan <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31lib/rbtree.c: fix typo in comment of rb_insert_augmented()Wei Yang1-2/+2
The function name in the comment is not correct. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Wei Yang <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31lib/sg_pool.c: remove unnecessary null check when freeing objectzhong jiang1-4/+3
mempool_destroy(NULL) and kmem_cache_destroy(NULL) are legal Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: zhong jiang <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31lib/zlib_inflate/inflate.c: remove fall through warningsCorentin Labbe1-0/+12
This patch remove all following fall through warnings by adding /* fall through */ markers. Note that we cannot add "__attribute__ ((fallthrough));" due to it is GCC7 only arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:384:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:391:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:393:16: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:430:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:556:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:595:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:602:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:627:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:646:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:696:25: warning: this statement may fall through [-Wimplicit-fallthrough=] It is easy to see that thoses fall through are needed since in each case state->mode are set to the case value just below. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Corentin Labbe <[email protected]> Cc: David Miller <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31lib/parser.c: switch match_number() over to use match_strdup()Eric Biggers1-4/+1
This simplifies the code. No change in behavior. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31lib/parser.c: switch match_u64int() over to use match_strdup()Eric Biggers1-4/+1
This simplifies the code. No change in behavior. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31lib/parser.c: switch match_strdup() over to use kmemdup_nul()Eric Biggers1-5/+1
This simplifies the code. No change in behavior. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31lib/bitmap.c: simplify bitmap_print_to_pagebuf()Rasmus Villemoes1-5/+2
len is guaranteed to lie in [1, PAGE_SIZE]. If scnprintf is called with a buffer size of 1, it is guaranteed to return 0. So in the extremely unlikely case of having just one byte remaining in the page, let's just call scnprintf anyway. The only difference is that this will write a '\0' to that final byte in the page, but that's an improvement: We now guarantee that after the call, buf is a properly terminated C string of length exactly the return value. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: Yury Norov <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Sudeep Holla <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31lib/bitmap.c: fix remaining space computation in bitmap_print_to_pagebufRasmus Villemoes1-4/+6
For various alignments of buf, the current expression computes 4096 ok 4095 ok 8190 8189 ... 4097 i.e., if the caller has already written two bytes into the page buffer, len is 8190 rather than 4094, because PTR_ALIGN aligns up to the next boundary. So if the printed version of the bitmap is huge, scnprintf() ends up writing beyond the page boundary. I don't think any current callers actually write anything before bitmap_print_to_pagebuf, but the API seems to be designed to allow it. [[email protected]: use offset_in_page(), per Andy] [[email protected]: include mm.h for offset_in_page()] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: Yury Norov <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Sudeep Holla <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31linux/bitmap.h: relax comment on compile-time constant nbitsRasmus Villemoes1-2/+2
It's not clear what's so horrible about emitting a function call to handle a run-time sized bitmap. Moreover, gcc also emits a function call for a compile-time-constant-but-huge nbits, so the comment isn't even accurate. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: Yury Norov <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Sudeep Holla <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31linux/bitmap.h: fix type of nbits in bitmap_shift_right()Rasmus Villemoes1-1/+1
Most other bitmap API, including the OOL version __bitmap_shift_right, take unsigned nbits. This was accidentally left out from 2fbad29917c98. Link: http://lkml.kernel.org/r/[email protected] Fixes: 2fbad29917c98 ("lib: bitmap: change bitmap_shift_right to take unsigned parameters") Signed-off-by: Rasmus Villemoes <[email protected]> Reported-by: Yury Norov <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Sudeep Holla <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31linux/bitmap.h: remove redundant uses of small_const_nbits()Rasmus Villemoes1-18/+6
In the _zero, _fill and _copy functions, the small_const_nbits branch is redundant. If nbits is small and const, gcc knows full well that BITS_TO_LONGS(nbits) is 1, so len is also a compile-time constant (sizeof(long)), and calling memset or memcpy with a length argument of sizeof(long) makes gcc generate the expected code anyway: #include <string.h> void a(unsigned long *x) { memset(x, 0, 8); } void b(unsigned long *x) { memset(x, 0xff, 8); } void c(unsigned long *x, const unsigned long *y) { memcpy(x, y, 8); } turns into 0000000000000000 <a>: 0: 48 c7 07 00 00 00 00 movq $0x0,(%rdi) 7: c3 retq 8: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) f: 00 0000000000000010 <b>: 10: 48 c7 07 ff ff ff ff movq $0xffffffffffffffff,(%rdi) 17: c3 retq 18: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) 1f: 00 0000000000000020 <c>: 20: 48 8b 06 mov (%rsi),%rax 23: 48 89 07 mov %rax,(%rdi) 26: c3 retq Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: Yury Norov <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Sudeep Holla <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31linux/bitmap.h: handle constant zero-size bitmaps correctlyRasmus Villemoes1-1/+6
The static inlines in bitmap.h do not handle a compile-time constant nbits==0 correctly (they dereference the passed src or dst pointers, despite only 0 words being valid to access). I had the 0-day buildbot chew on a patch [1] that would cause build failures for such cases without complaining, suggesting that we don't have any such users currently, at least for the 70 .config/arch combinations that was built. Should any turn up, make sure they use the out-of-line versions, which do handle nbits==0 correctly. This is of course not the most efficient, but it's much less churn than teaching all the static inlines an "if (zero_const_nbits())", and since we don't have any current instances, this doesn't affect existing code at all. [1] lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: Yury Norov <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Sudeep Holla <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31lib/bitmap.c: remove wrong documentationRasmus Villemoes1-5/+0
This promise is violated in a number of places, e.g. already in the second function below this paragraph. Since I don't think anybody relies on this being true, and since actually honouring it would hurt performance and code size in various places, just remove the paragraph. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: Yury Norov <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Sudeep Holla <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31kernel/fail_function.c: remove meaningless null pointer check before ↵zhong jiang1-2/+1
debugfs_remove_recursive debugfs_remove_recursive() has taken the null pointer into account. just remove the null check before debugfs_remove_recursive(). Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: zhong jiang <[email protected]> Acked-by: Masami Hiramatsu <[email protected]> Acked-by: Kees Cook <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31treewide: remove current_text_addrNick Desaulniers29-199/+2
Prefer _THIS_IP_ defined in linux/kernel.h. Most definitions of current_text_addr were the same as _THIS_IP_, but a few archs had inline assembly instead. This patch removes the final call site of current_text_addr, making all of the definitions dead code. [[email protected]: fix arch/csky/include/asm/processor.h] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Nick Desaulniers <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31.mailmap: add Oleksij RempelOleksij Rempel1-0/+5
I have had various email addresses and a name change after marriage. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Oleksij Rempel <[email protected]> Cc: Jiri Kosina <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31fs/proc/vmcore.c: Convert to use vmf_error()Souptick Joarder1-1/+1
This code can be replaced with vmf_error() inline function. Link: http://lkml.kernel.org/r/20180918145945.GA11392@jordon-HP-15-Notebook-PC Signed-off-by: Souptick Joarder <[email protected]> Reviewed-by: Matthew Wilcox <[email protected]> Cc: Alexey Dobriyan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31mm/gup_benchmark.c: prevent integer overflow in ioctlDan Carpenter1-0/+3
The concern here is that "gup->size" is a u64 and "nr_pages" is unsigned long. On 32 bit systems we could trick the kernel into allocating fewer pages than expected. Link: http://lkml.kernel.org/r/[email protected] Fixes: 64c349f4ae78 ("mm: add infrastructure for get_user_pages_fast() benchmarking") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Stephen Rothwell <[email protected]> Cc: Keith Busch <[email protected]> Cc: "Michael S. Tsirkin" <[email protected]> Cc: Kees Cook <[email protected]> Cc: YueHaibing <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31mm/hmm: invalidate device page table at start of invalidationJérôme Glisse1-12/+15
Invalidate device page table at start of invalidation and invalidate in progress CPU page table snapshooting at both start and end of any invalidation. This is helpful when device need to dirty page because the device page table report the page as dirty. Dirtying page must happen in the start mmu notifier callback and not in the end one. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Jérôme Glisse <[email protected]> Cc: Ralph Campbell <[email protected]> Cc: John Hubbard <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31mm/hmm: use a structure for update callback parametersJérôme Glisse2-20/+44
Use a structure to gather all the parameters for the update callback. This make it easier when adding new parameters by avoiding having to update all callback function signature. The hmm_update structure is always associated with a mmu_notifier callbacks so we are not planing on grouping multiple updates together. Nor do we care about page size for the range as range will over fully cover the page being invalidated (this is a mmu_notifier property). Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Jérôme Glisse <[email protected]> Cc: Ralph Campbell <[email protected]> Cc: John Hubbard <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31mm/hmm: properly handle migration pmdJérôme Glisse1-6/+34
Before this patch migration pmd entry (!pmd_present()) would have been treated as a bad entry (pmd_bad() returns true on migration pmd entry). The outcome was that device driver would believe that the range covered by the pmd was bad and would either SIGBUS or simply kill all the device's threads (each device driver decide how to react when the device tries to access poisonnous or invalid range of memory). This patch explicitly handle the case of migration pmd entry which are non present pmd entry and either wait for the migration to finish or report empty range (when device is just trying to pre- fill a range of virtual address and thus do not want to wait or trigger page fault). Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Aneesh Kumar K.V <[email protected]> Signed-off-by: Jérôme Glisse <[email protected]> Cc: Zi Yan <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Ralph Campbell <[email protected]> Cc: John Hubbard <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31mm/hmm: fix race between hmm_mirror_unregister() and mmu_notifier callbackRalph Campbell1-15/+21
In hmm_mirror_unregister(), mm->hmm is set to NULL and then mmu_notifier_unregister_no_release() is called. That creates a small window where mmu_notifier can call mmu_notifier_ops with mm->hmm equal to NULL. Fix this by first unregistering mmu notifier callbacks and then setting mm->hmm to NULL. Similarly in hmm_register(), set mm->hmm before registering mmu_notifier callbacks so callback functions always see mm->hmm set. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ralph Campbell <[email protected]> Signed-off-by: Jérôme Glisse <[email protected]> Reviewed-by: John Hubbard <[email protected]> Reviewed-by: Jérôme Glisse <[email protected]> Reviewed-by: Balbir Singh <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31mm/rmap: map_pte() was not handling private ZONE_DEVICE page properlyRalph Campbell1-1/+23
Private ZONE_DEVICE pages use a special pte entry and thus are not present. Properly handle this case in map_pte(), it is already handled in check_pte(), the map_pte() part was lost in some rebase most probably. Without this patch the slow migration path can not migrate back to any private ZONE_DEVICE memory to regular memory. This was found after stress testing migration back to system memory. This ultimatly can lead to the CPU constantly page fault looping on the special swap entry. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ralph Campbell <[email protected]> Signed-off-by: Jérôme Glisse <[email protected]> Reviewed-by: Balbir Singh <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31mm/hmm: fix utf8 ...Jérôme Glisse2-2/+2
Patch series "HMM updates, improvements and fixes", v2 Few fixes that only affect HMM users. Improve the synchronization call back so that we match was other mmu_notifier listener do and add proper support to the new blockable flags in the process. For curious folks here are branches to leverage HMM in various existing device drivers: https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-nouveau-v01 https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-radeon-v00 https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-intel-v00 More to come (amd gpu, Mellanox, ...) I expect more of the preparatory work for nouveau will be merge in 4.20 (like we have been doing since 4.16) and i will wait until this patchset is upstream before pushing the patches that actualy make use of HMM (to avoid complex tree inter-dependency). This patch (of 6): Somehow utf=8 must have been broken. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Jérôme Glisse <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-10-31block: call rq_qos_exit() after queue is frozenMing Lei2-2/+3
rq_qos_exit() removes the current q->rq_qos, this action has to be done after queue is frozen, otherwise the IO queue path may never be waken up, then IO hang is caused. So fixes this issue by moving rq_qos_exit() after queue is frozen. Cc: Josef Bacik <[email protected]> Signed-off-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-10-31HID: asus: only support backlight when it's not driven by WMIDaniel Drake2-1/+23
The Asus GL502VSK has the same 0B05:1837 keyboard as we've seen in several Republic of Gamers laptops. However, in this model, the keybard backlight control exposed by hid-asus has no effect on the keyboard backlight. Instead, the keyboard backlight is correctly driven by asus-wmi. With two keyboard backlight devices available (and only the acer-wmi one working), GNOME is picking the wrong one to drive in the UI. Avoid this problem by not creating the backlight interface when we detect a WMI-driven keyboard backlight. We have also tested Asus GL702VMK which does have the hid-asus backlight present, and it still works fine with this patch (WMI method call returns UNSUPPORTED_METHOD). A direct "depends on ASUS_WMI" is intentionally avoided so that HID_ASUS users who have ASUS_WMI=n will not quietly lose their HID_ASUS driver on a kernel upgrade. Signed-off-by: Daniel Drake <[email protected]> Reviewed-by: Benjamin Tissoires <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2018-10-31platform/x86: asus-wmi: export function for evaluating WMI methodsDaniel Drake2-85/+104
Export asus_wmi_evaluate_method() and related headers for use by other drivers. hid-asus is going to use this to avoid advertising that it has a keyboard backlight when the keyboard backlight is controlled via WMI. Signed-off-by: Daniel Drake <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2018-10-31platform/x86: asus-wmi: Only notify kbd LED hw_change by fn-key pressedJian-Hong Pan1-5/+12
Since commit dbb3d78f61ba ("platform/x86: asus-wmi: Call led hw_changed API on kbd brightness change"), asus-wmi directly changes the keyboard LED brightness when the keyboard brightness keys are pressed, raising the appropriate notification. However, this notification was unintentionally also being raised during boot and resume from suspend. This was resulting in userspace showing the keyboard LED OSD on resume for no good reason. Move the keyboard LED brightness changed notification from kbd_led_update to the new kbd_led_set_by_kbd function which is only called from the keyboard brightness function keys codepath. Signed-off-by: Jian-Hong Pan <[email protected]> Signed-off-by: Daniel Drake <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2018-10-31platform/x86: wmi: declare device_type structure as constantBhumika Goyal1-3/+3
The only usage of device_type structure is getting stored as a reference in the type field of device structure. This type field is declared const. Therefore, the device_type structure can never be modified and can be declared as const. Signed-off-by: Bhumika Goyal <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2018-10-31platform/x86: ideapad: Add Y530-15ICH to no_hw_rfkillMisha Komarovskiy1-0/+7
Lenovo Legion Y530-15ICH is another model without hardware radio switch. Add it to no_hw_rfkill to enable wireless. Signed-off-by: Misha Komarovskiy <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2018-10-31perf tools: Don't clone maps from parent when synthesizing forksDavid Miller6-10/+29
When synthesizing FORK events, we are trying to create thread objects for the already running tasks on the machine. Normally, for a kernel FORK event, we want to clone the parent's maps because that is what the kernel just did. But when synthesizing, this should not be done. If we do, we end up with overlapping maps as we process the sythesized MMAP2 events that get delivered shortly thereafter. Use the FORK event misc flags in an internal way to signal this situation, so we can elide the map clone when appropriate. Signed-off-by: David S. Miller <[email protected]> Cc: Don Zickus <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Joe Mario <[email protected]> Link: http://lkml.kernel.org/r/[email protected] [ Added comment about flag use in machine__process_fork_event(), use ternary op in thread__clone_map_groups() as suggested by Jiri ] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2018-10-31perf top: Start display thread earlierDavid Miller1-5/+5
If events are coming in at a rate such that the event processing thread can barely keep up, our initial run of the event ring will almost never terminate and this delays the starting of the display thread. The screen basically stays black until the event thread can get out of it's endless loop. Therefore, start the display thread before we start processing the ring buffer. This also make sure that we always have the user requested real time setting engaged when processing the ring. Signed-off-by: David S. Miller <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Namhyung Kim <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2018-10-31tools headers uapi: Update linux/if_link.h header copyArnaldo Carvalho de Melo1-0/+1
To pick the changes from: 9163a0fc1f0c ("net: bridge: add support for per-port vlan stats") And silence this build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/if_link.h' differs from latest version at 'include/uapi/linux/if_link.h' Cc: Alexei Starovoitov <[email protected]> Cc: David S. Miller <[email protected]> Cc: Eric Leblond <[email protected]> Cc: Nikolay Aleksandrov <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2018-10-31tools headers uapi: Update linux/netlink.h header copyArnaldo Carvalho de Melo1-0/+1
Picking the changes from: 89d35528d17d ("netlink: Add new socket option to enable strict checking on dumps") To silence this build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/netlink.h' differs from latest version at 'include/uapi/linux/netlink.h' Cc: Alexei Starovoitov <[email protected]> Cc: David Ahern <[email protected]> Cc: David S. Miller <[email protected]> Cc: Eric Leblond <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2018-10-31tools headers: Sync the various kvm.h header copiesArnaldo Carvalho de Melo4-6/+24
For powerpc, s390, x86 and the main uapi linux/kvm.h header, none of them entail changes in tooling. Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.