- 06 Apr, 2018 40 commits
-
-
Alexey Dobriyan authored
If kmem case sizes are 32-bit, then usecopy region should be too. Link: http://lkml.kernel.org/r/20180305200730.15812-21-adobriyan@gmail.comSigned-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: David Miller <davem@davemloft.net> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Alexey Dobriyan authored
If SLAB doesn't support 4GB+ kmem caches (it never did), KASAN should not do it as well. Link: http://lkml.kernel.org/r/20180305200730.15812-20-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
Now that all sizes are properly typed, propagate "unsigned int" down the callgraph. Link: http://lkml.kernel.org/r/20180305200730.15812-19-adobriyan@gmail.comSigned-off-by:
Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by:
-
Alexey Dobriyan authored
Linux doesn't support negative length objects (including meta data). Link: http://lkml.kernel.org/r/20180305200730.15812-18-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
Linux doesn't support negative length objects. Link: http://lkml.kernel.org/r/20180305200730.15812-17-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
->offset is free pointer offset from the start of the object, can't be negative. Link: http://lkml.kernel.org/r/20180305200730.15812-16-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
/* * cpu_partial determined the maximum number of objects * kept in the per cpu partial lists of a processor. */ Can't be negative. Link: http://lkml.kernel.org/r/20180305200730.15812-15-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
->inuse is "the number of bytes in actual use by the object", can't be negative. Link: http://lkml.kernel.org/r/20180305200730.15812-14-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
Kmem cache alignment can't be negative. Link: http://lkml.kernel.org/r/20180305200730.15812-13-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
->reserved is either 0 or sizeof(struct rcu_head), can't be negative. Link: http://lkml.kernel.org/r/20180305200730.15812-12-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
Padding length can't be negative. Link: http://lkml.kernel.org/r/20180305200730.15812-11-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
->max_attr_size is maximum length of every SLAB memcg attribute ever written. VFS limits those to INT_MAX. Link: http://lkml.kernel.org/r/20180305200730.15812-10-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
->remote_node_defrag_ratio is in range 0..1000. This also adds a check and modifies the behavior to return an error code. Before this patch invalid values were ignored. Link: http://lkml.kernel.org/r/20180305200730.15812-9-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
size_index_elem() always works with small sizes (kmalloc caches are 32-bit) and returns small indexes. Link: http://lkml.kernel.org/r/20180305200730.15812-8-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
All those small numbers are reverse indexes into kmalloc caches array and can't be negative. On x86_64 "unsigned int = fls()" can drop CDQE instruction: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-2 (-2) Function old new delta kmalloc_slab 101 99 -2 Link: http://lkml.kernel.org/r/20180305200730.15812-7-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
struct kmem_cache::size and ::align were always 32-bit. Out of curiosity I created 4GB kmem_cache, it oopsed with division by 0. kmem_cache_create(1UL<<32+1) created 1-byte cache as expected. size_t doesn't work and never did. Link: http://lkml.kernel.org/r/20180305200730.15812-6-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
struct kmem_cache::size has always been "int", all those "size_t size" are fake. Link: http://lkml.kernel.org/r/20180305200730.15812-5-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
KMALLOC_MAX_CACHE_SIZE is 32-bit so is the largest kmalloc cache size. Christoph said: : : Ok SLABs maximum allocation size is limited to 32M (see : include/linux/slab.h: : : #define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT - 1) <= 25 ? \ : (MAX_ORDER + PAGE_SHIFT - 1) : 25) : : And SLUB/SLOB pass all larger requests to the page allocator anyways. Link: http://lkml.kernel.org/r/20180305200730.15812-4-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
kmalloc_size() derives size of kmalloc cache from internal index, which can't be negative. Propagate unsignedness a bit. Link: http://lkml.kernel.org/r/20180305200730.15812-3-adobriyan@gmail.comSigned-off-by:
-
Alexey Dobriyan authored
kmalloc_index() return index into an array of kmalloc kmem caches, therefore should be unsigned. Space savings with SLUB on trimmed down .config: add/remove: 0/1 grow/shrink: 6/56 up/down: 85/-557 (-472) Function old new delta calculate_sizes 924 983 +59 on_freelist 589 604 +15 init_cache_random_seq 122 127 +5 ext4_mb_init 1206 1210 +4 slab_pad_check.part 270 271 +1 cpu_partial_store 112 113 +1 usersize_show 28 27 -1 ... new_slab 1871 1837 -34 slab_order 204 - -204 This patch start a series of converting SLUB (mostly) to "unsigned int". 1) Most integers in the code are in fact unsigned entities: array indexes, lengths, buffer sizes, allocation orders. It is therefore better to use unsigned variables 2) Some integers in the code are either "size_t" or "unsigned long" for no reason. size_t usually comes from people trying to maintain type correctness and figuring out that "sizeof" operator returns size_t or memset/memcpy takes size_t so should everything passed to it. However the number of 4GB+ objects in the kernel is very small. Most, if not all, dynamically allocated objects with kmalloc() or kmem_cache_create() aren't actually big. Maintaining wide types doesn't do anything. 64-bit ops are bigger than 32-bit on our beloved x86_64, so try to not use 64-bit where it isn't necessary (read: everywhere where integers are integers not pointers) 3) in case of SLAB allocators, there are additional limitations *) page->inuse, page->objects are only 16-/15-bit, *) cache size was always 32-bit *) slab orders are small, order 20 is needed to go 64-bit on x86_64 (PAGE_SIZE << order) Basically everything is 32-bit except kmalloc(1ULL<<32) which gets shortcut through page allocator. Christoph said: : : That changes with large base page size on power and ARM64 f.e. but then : we do not want to encourage larger allocations through slab anyways. Link: http://lkml.kernel.org/r/20180305200730.15812-2-adobriyan@gmail.comSigned-off-by: -
Alexey Dobriyan authored
Link: http://lkml.kernel.org/r/20180305200730.15812-1-adobriyan@gmail.comSigned-off-by:
-
Chintan Pandya authored
When SLUB_DEBUG catches some issues, it prints all the required debug info. However, in a few cases where allocation and free of the object has happened in a very short time, 'age' might be misleading. See the example below: ============================================================================= BUG kmalloc-256 (Tainted: G W O ): Poison overwritten ----------------------------------------------------------------------------- ... INFO: Allocated in binder_transaction+0x4b0/0x2448 age=731 cpu=3 pid=5314 ... INFO: Freed in binder_free_transaction+0x2c/0x58 age=735 cpu=6 pid=2079 ... Object fffffff14956a870: 6b 6b 6b 6b 6b 6b 6b 6b 67 6b 6b 6b 6b 6b 6b a5 kkkkkkkkgkkkk In this case, object got freed later but 'age' shows otherwise. This could be because, while printing this info, we print allocation traces first and free traces thereafter. In between, if we get schedule out or jiffies increment, (jiffies - t->when) could become meaningless. Use the jitter free reference to calculate age. New output will exactly be same. 'age' is still staying with single jiffies ref in both prints. Change-Id: I0846565807a4229748649bbecb1ffb743d71fcd8 Link: http://lkml.kernel.org/r/1520492010-19389-1-git-send-email-cpandya@codeaurora.orgSigned-off-by:
Chintan Pandya <cpandya@codeaurora.org> Acked-by:
-
Alexey Dobriyan authored
kmalloc caches aren't relocated after being set up neither does "size_index" array. Link: http://lkml.kernel.org/r/20180226203519.GA6886@avx2Signed-off-by:
-
shunki-fujita authored
When changing the size of a block device, its all caches are freed. It's necessary on shrinking to prevent spurious I/Os to the disappeared region. However, on expanding, such kind of I/Os doesn't happen. Similar things can be considered for btrfs filesystem resize and resize2fs, but they are designed not to drop caches when expanding. Therefore this patch removes unnecessary cache drop. Link: http://lkml.kernel.org/r/1521457240-153390-1-git-send-email-shunki-fujita@cybozu.co.jpSigned-off-by:
Shunki Fujita <shunki-fujita@cybozu.co.jp> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jan Kara <jack@suse.cz> Signed-off-by:
-
Chengguang Xu authored
When specifying trans_mod multiple times in a mount, it will cause an inaccurate refcount of the trans module. Also, in the error case of option parsing, we should put the trans module if we have already got it. Link: http://lkml.kernel.org/r/1522154942-57339-1-git-send-email-cgxu519@gmx.comSigned-off-by:
Chengguang Xu <cgxu519@gmx.com> Reviewed-by:
-
Yiwen Jiang authored
When the user uses some syscall, for example mmap(v9fs_file_mmap), it will not update atime even if user's was set mnt_flags without MNT_NOATIME, because v9fs defaults to settine SB_NOATIME in v9fs_set_super. For supporting access time updating when the user mounts with relatime, we should not set SB_NOATIME by default. Link: http://lkml.kernel.org/r/5AB9A377.6080906@huawei.comSigned-off-by:
Yiwen Jiang <jiangyiwen@huawei.com> Reviewed-by:
Greg Kurz <groug@kaod.org> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Ron Minnich <rminnich@sandia.gov> Cc: Latchesar Ionkov <lucho@ionkov.net> Signed-off-by:
-
Chengguang Xu authored
Check memory allocation result for cachetag in mount option parsing and fix potential memory leak in the error case. Link: http://lkml.kernel.org/r/1521614889-73446-1-git-send-email-cgxu519@gmx.comSigned-off-by:
-
Eryu Guan authored
If the exported filesystem dir on 9p server doesn't maintain accurate i_nlink count, e.g. always reports i_nlink as 1, then 9p should not maintain nlink count either, otherwise drop_link would report warning with i_nlink being zero. For example: - overlayfs sets nlink to 1 for merged dir - ext4 (with dir_nlink feature enabled) sets nlink to 1 if a dir has more than EXT4_LINK_MAX (65000) links. In this case, everytime a stat(2) call (getattr) on such exported dirs on 9p client side, the i_nlink gets reset to 1, then operations like rmdir(2), unlink(2) and rename(2) would cause the dir nlink to go to zero (then negative), which results in warnings in drop_nlink() and/or inc_nlink() calls. This can be reproduced easily as the following steps: - export a merged overlayfs dir via qemu virtfs to guest - mount the exported virtfs in guest - create two sub-directories in the root dir of the mounted 9pfs - stat the root dir of 9pfs, this resets nlink to 1 - remove all subdirs, the second unlink/rmdir would trigger warning ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1284 at fs/inode.c:282 drop_nlink+0x3e/0x50 ... Call Trace: dump_stack+0x63/0x81 __warn+0xcb/0xf0 warn_slowpath_null+0x1d/0x20 drop_nlink+0x3e/0x50 v9fs_remove+0xaa/0x130 [9p] v9fs_vfs_rmdir+0x13/0x20 [9p] vfs_rmdir+0xb7/0x130 do_rmdir+0x1b8/0x230 SyS_unlinkat+0x22/0x30 do_syscall_64+0x67/0x180 ---[ end trace 43758d8ba91e603b ]--- Fix it by leaving i_nlink to be 1 and don't drop nlink if a directory has nlink <= 2, which indicates that the underlying exported fs doesn't maintain nlink count accurately. This follows what ext4 does in ext4_dec_count(). Link: http://lkml.kernel.org/r/20180312053829.4367-1-eguan@linux.alibaba.comSigned-off-by:Eryu Guan <eguan@linux.alibaba.com> Reviewed-by:
Roman Kapl <code@rkapl.cz> Cc: Caspar Zhang <caspar@linux.alibaba.com> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Ron Minnich <rminnich@sandia.gov> Cc: Latchesar Ionkov <lucho@ionkov.net> Cc: <v9fs-developer@lists.sourceforge.net> Signed-off-by:
-
Greg Kurz authored
If it was interrupted by a signal, the 9p client may need to send some more requests to the server for cleanup before returning to userspace. To avoid such a last minute request to be interrupted right away, the client memorizes if a signal is pending, clears TIF_SIGPENDING, handles the request and calls recalc_sigpending() before returning. Unfortunately, if the transmission of this cleanup request fails for any reason, the transport returns an error and the client propagates it right away, without calling recalc_sigpending(). This ends up with -ERESTARTSYS from the initially interrupted request crawling up to syscall exit, with TIF_SIGPENDING cleared by the cleanup request. The specific signal handling code, which is responsible for converting -ERESTARTSYS to -EINTR is not called, and userspace receives the confusing errno value: open: Unknown error 512 (512) This is really hard to hit in real life. I discovered the issue while working on hot-unplug of a virtio-9p-pci device with an instrumented QEMU allowing to control request completion. Both p9_client_zc_rpc() and p9_client_rpc() functions have this buggy error path actually. Their code flow is a bit obscure and the best thing to do would probably be a full rewrite: to really ensure this situation of clearing TIF_SIGPENDING and returning -ERESTARTSYS can never happen. But given the general lack of interest for the 9p code, I won't risk breaking more things. So this patch simply fixes the buggy paths in both functions with a trivial label+goto. Thanks to Laurent Dufour for his help and suggestions on how to find the root cause and how to fix it. Link: http://lkml.kernel.org/r/152062809886.10599.7361006774123053312.stgit@bahia.lanSigned-off-by:
-
Changwei Ge authored
Link: http://lkml.kernel.org/r/1522734135-7933-1-git-send-email-ge.changwei@h3c.comSigned-off-by:
Changwei Ge <ge.changwei@h3c.com> Acked-by:
Joseph Qi <jiangqi903@gmail.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <ge.changwei@h3c.com> Signed-off-by:
-
piaojun authored
We need to check len for bio_add_page() to make sure the bio has been set up correctly, otherwise we may submit incorrect data to device. Link: http://lkml.kernel.org/r/5ABC3EBE.5020807@huawei.comSigned-off-by:
Jun Piao <piaojun@huawei.com> Reviewed-by:
-
Gang He authored
Add duplicated ino number check, to avoid adding a file into the file check list when this file is being checked. Link: http://lkml.kernel.org/r/1495611866-27360-5-git-send-email-ghe@suse.comSigned-off-by:
Gang He <ghe@suse.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Joseph Qi <jiangqi903@gmail.com> Signed-off-by:
-
Gang He authored
Use embedded kobject mechanism for online file check feature, this will avoid to use a global list to save/search per-device online file check related data, meanwhile, reduce the code lines and make the code logic clear. The changed code is based on Goldwyn Rodrigues's patches and ext4 fs code. Link: http://lkml.kernel.org/r/1495611866-27360-4-git-send-email-ghe@suse.comSigned-off-by:
-
Gang He authored
First, move setting fe_done = 1 in spin lock, avoid bring any potential race condition. Second, tune mlog message level from ERROR to NOTICE, since the message should not belong to error message. Third, tune errno to -EAGAIN when file check queue is full, this errno is more appropriate in the case. Link: http://lkml.kernel.org/r/1495611866-27360-3-git-send-email-ghe@suse.comSigned-off-by:
-
Gang He authored
Patch series "ocfs2: use kobject for online file check", v3. Use embedded kobject mechanism for online file check feature, this will avoid to use a global list to save/search per-device online file check related data. The changed code is based on Goldwyn Rodrigues's patches and ext4 fs code, there is not any new features added, except some very small fixes during this code refactoring. Second, the code change does not affect the underlying file check code. Thank Goldwyn very much. Compare with second version, add more comments in the patch descriptions, to make sure each modification is mentioned. Compare with first version, split the code change into four patches, make sure each patch will not bring ocfs2 kernel modules compiling errors. This patch (of 3): Move some definitions to header file, which will be referenced by other source files when kobject mechanism is introduced. Link: http://lkml.kernel.org/r/1495611866-27360-2-git-send-email-ghe@suse.comSigned-off-by:
-
Changwei Ge authored
Inspired by the ocfs2 patch to fix the spelling of migrateable to migratable, I checked all ocfs2 files and found more spelling mistakes. So correct them all. Link: http://lkml.kernel.org/r/1521525734-19576-1-git-send-email-ge.changwei@h3c.comSigned-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in mlog message text Link: http://lkml.kernel.org/r/20180319114101.2051-1-colin.king@canonical.comSigned-off-by:
Colin Ian King <colin.king@canonical.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Joseph Qi <jiangqi903@gmail.com> Cc: Changwei Ge <ge.changwei@h3c.com> Signed-off-by:
-
piaojun authored
Wait for dlm recovery done when migrating all lock resources in case that new lock resource left after leaving dlm domain. And the left lock resource will cause other nodes BUG. NodeA NodeB NodeC umount: dlm_unregister_domain() dlm_migrate_all_locks() NodeB down do recovery for NodeB and collect a new lockres form other live nodes: dlm_do_recovery dlm_remaster_locks dlm_request_all_locks: dlm_mig_lockres_handler dlm_new_lockres __dlm_insert_lockres at last NodeA become the master of the new lockres and leave domain: dlm_leave_domain() mount: dlm_join_domain() touch file and request for the owner of the new lockres, but all the other nodes said 'NO', so NodeC decide to be the owner, and send do assert msg to other nodes: dlmlock() dlm_get_lock_resource() dlm_do_assert_master() other nodes receive the msg and found two masters exist. at last cause BUG in dlm_assert_master_handler() -->BUG(); Link: http://lkml.kernel.org/r/5AAA6E25.7090303@huawei.com Fixes: bc9838c4 ("dlm: allow dlm do recovery during shutdown") Signed-off-by:Alex Chen <alex.chen@huawei.com> Reviewed-by:
-
Changwei Ge authored
Link: http://lkml.kernel.org/r/1521116681-14602-2-git-send-email-ge.changwei@h3c.comSigned-off-by:
-
Changwei Ge authored
Link: http://lkml.kernel.org/r/1521116681-14602-1-git-send-email-ge.changwei@h3c.comSigned-off-by:
-
