- 29 Mar, 2020 4 commits
-
-
Steve French authored
To 2.26 Signed-off-by:Steve French <stfrench@microsoft.com>
-
Long Li authored
When encryption is used, smb2_transform_hdr is defined on the stack and is passed to the transport. This doesn't work with RDMA as the buffer needs to be DMA'ed. Fix it by using kmalloc. Signed-off-by:
Long Li <longli@microsoft.com> Signed-off-by:
-
Long Li authored
When a RDMA packet is received and server is extending send credits, we should check and unblock senders immediately in IRQ context. Doing it in a worker queue causes unnecessary delay and doesn't save much CPU on the receive path. Signed-off-by:
-
Long Li authored
The packet size needs to take account of SMB2 header size and possible encryption header size. This is only done when signing is used and it is for RDMA send/receive, not read/write. Also remove the dead SMBD code in smb2_negotiate_r(w)size. Signed-off-by:
-
- 27 Mar, 2020 1 commit
-
-
Steve French authored
It clarifies the code slightly to use SMB2_SIGNATURE_SIZE define rather than 16. Suggested-by:
Henning Schild <henning.schild@siemens.com> Signed-off-by:
-
- 23 Mar, 2020 24 commits
-
-
Yilu Lin authored
This patch is used to fix the bug in collect_uncached_read_data() that rc is automatically converted from a signed number to an unsigned number when the CIFS asynchronous read fails. It will cause ctx->rc is error. Example: Share a directory and create a file on the Windows OS. Mount the directory to the Linux OS using CIFS. On the CIFS client of the Linux OS, invoke the pread interface to deliver the read request. The size of the read length plus offset of the read request is greater than the maximum file size. In this case, the CIFS server on the Windows OS returns a failure message (for example, the return value of smb2.nt_status is STATUS_INVALID_PARAMETER). After receiving the response message, the CIFS client parses smb2.nt_status to STATUS_INVALID_PARAMETER and converts it to the Linux error code (rdata->result=-22). Then the CIFS client invokes the collect_uncached_read_data function to assign the value of rdata->result to rc, that is, rc=rdata->result=-22. The type of the ctx->total_len variable is unsigned integer, the type of the rc variable is integer, and the type of the ctx->rc variable is ssize_t. Therefore, during the ternary operation, the value of rc is automatically converted to an unsigned number. The final result is ctx->rc=4294967274. However, the expected result is ctx->rc=-22. Signed-off-by:
Yilu Lin <linyilu@huawei.com> Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com>
-
Murphy Zhou authored
xfstests generic/228 checks if fallocate respect RLIMIT_FSIZE. After fallocate mode 0 extending enabled, we can hit this failure. Fix this by check the new file size with vfs helper, return error if file size is larger then RLIMIT_FSIZE(ulimit -f). This patch has been tested by LTP/xfstests aginst samba and Windows server. Acked-by:
Murphy Zhou <jencce.kernel@gmail.com> Signed-off-by:
-
Steve French authored
And add one missing define (COMPRESSION_TRANSFORM_ID) and flag (TRANSFORM_FLAG_ENCRYPTED) Signed-off-by: -
Steve French authored
New transform header structures. See recent updates to MS-SMB2 adding section 2.2.42.1 and 2.2.42.2 Signed-off-by:
-
Steve French authored
Additional compression capabilities can now be negotiated and a new compression algorithm. Add the flags for these. See newly updated MS-SMB2 sections 3.1.4.4.1 and 2.2.3.1.3 Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Eric Biggers authored
Leaving PF_MEMALLOC set when exiting a kthread causes it to remain set during do_exit(). That can confuse things. For example, if BSD process accounting is enabled and the accounting file has FS_SYNC_FL set and is located on an ext4 filesystem without a journal, then do_exit() can end up calling ext4_write_inode(). That triggers the WARN_ON_ONCE(current->flags & PF_MEMALLOC) there, as it assumes (appropriately) that inodes aren't written when allocating memory. This was originally reported for another kernel thread, xfsaild() [1]. cifs_demultiplex_thread() also exits with PF_MEMALLOC set, so it's potentially subject to this same class of issue -- though I haven't been able to reproduce the WARN_ON_ONCE() via CIFS, since unlike xfsaild(), cifs_demultiplex_thread() is sent SIGKILL before exiting, and that interrupts the write to the BSD process accounting file. Either way, leaving PF_MEMALLOC set is potentially problematic. Let's clean this up by properly saving and restoring PF_MEMALLOC. [1] https://lore.kernel.org/r/0000000000000e7156059f751d7b@google.comSigned-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Steve French authored
The warning we print on mount about how to use less secure dialects (when the user does not specify a version on mount) is useful but is noisy to print on every default mount, and can be changed to a warn_once. Slightly updated the warning text as well to note SMB3.1.1 which has been the default which is typically negotiated (for a few years now) by most servers. "No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount." Signed-off-by: -
Qiujun Huang authored
fix warning [-Wunused-but-set-variable] at variable 'rc', keeping the code readable. Signed-off-by:
Qiujun Huang <hqjagain@gmail.com> Signed-off-by:
-
Murphy Zhou authored
Since commit d0677992 ("cifs: add support for flock") added support for flock, LTP/flock03[1] testcase started to fail. This testcase is testing flock lock and unlock across fork. The parent locks file and starts the child process, in which it unlock the same fd and lock the same file with another fd again. All the lock and unlock operation should succeed. Now the child process does not actually unlock the file, so the following lock fails. Fix this by allowing flock and OFD lock go through the unlock routine, not skipping if the unlock request comes from another process. Patch has been tested by LTP/xfstests on samba and Windows server, v3.11, with or without cache=none mount option. [1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/flock/flock03.cSigned-off-by:
Pavel Shilovsky <pshilov@microsoft.com>
-
Steve French authored
See commit 349457cc "Allow file systems to manually d_move() inside of ->rename()" Lessens possibility of race conditions in rename Signed-off-by:
-
Aurelien Aptel authored
allows SMB2_open() callers to pass down a POSIX data buffer that will trigger requesting POSIX create context and parsing the response into the provided buffer. Signed-off-by:
Aurelien Aptel <aaptel@suse.com> Signed-off-by:
Paulo Alcantara (SUSE) <pc@cjr.nz>
-
Aurelien Aptel authored
* add code to request POSIX info level * parse dir entries and fill cifs_fattr to get correct inode data since the POSIX payload is variable size the number of entries in a FIND response needs to be computed differently. Dirs and regular files are properly reported along with mode bits, hardlink number, c/m/atime. No special files yet (see below). Current experimental version of Samba with the extension unfortunately has issues with wildcards and needs the following patch: > --- i/source3/smbd/smb2_query_directory.c > +++ w/source3/smbd/smb2_query_directory.c > @@ -397,9 +397,7 @@ smbd_smb2_query_directory_send(TALLOC_CTX > *mem_ctx, > } > } > > - if (!state->smbreq->posix_pathnames) { > wcard_has_wild = ms_has_wild(state->in_file_name); > - } > > /* Ensure we've canonicalized any search path if not a wildcard. */ > if (!wcard_has_wild) { > Also for special files despite reporting them as reparse point samba doesn't set the reparse tag field. This patch will mark them as needing re-evaluation but the re-evaluate code doesn't deal with it yet. Signed-off-by: -
Aurelien Aptel authored
* add new info level and structs for SMB2 posix extension * add functions to parse and validate it Signed-off-by:
-
Aurelien Aptel authored
little progress on the posix create response. * rename struct to create_posix_rsp to match with the request create_posix context * make struct packed * pass smb info struct for parse_posix_ctxt to fill * use smb info struct as param * update TODO What needs to be done: SMB2_open() has an optional smb info out argument that it will fill. Callers making use of this are: - smb3_query_mf_symlink (need to investigate) - smb2_open_file Callers of smb2_open_file (via server->ops->open) are passing an smbinfo struct but that struct cannot hold POSIX information. All the call stack needs to be changed for a different info type. Maybe pass SMB generic struct like cifs_fattr instead. Signed-off-by:
-
Steve French authored
We really, really don't want people using insecure dialects unless they realize what they are doing ... Add mount warning if mounting with vers=1.0 (older SMB1/CIFS dialect) instead of the default (SMB2.1 or later, typically SMB3.1.1). Signed-off-by:
-
Steve French authored
There are cases when we don't want to send the SMB2 flush operation (e.g. when user specifies mount parm "nostrictsync") and it can be a very expensive operation on the server. In most cases in order to set mtime, we simply need to flush (write) the dirtry pages from the client and send the writes to the server not also send a flush protocol operation to the server. Fixes: aa081859 ("cifs: flush before set-info if we have writeable handles") CC: Stable <stable@vger.kernel.org> Signed-off-by:
-
Stefan Metzmacher authored
cap_unix(ses) defaults to false for SMB2. Signed-off-by:
Stefan Metzmacher <metze@samba.org> Reviewed-by:
-
Stefan Metzmacher authored
mod_delayed_work() is safer than queue_delayed_work() if there's a chance that the work is already in the queue. Signed-off-by:
-
Stefan Metzmacher authored
This means it's consistently called and the callers don't need to care about it. Signed-off-by:
-
Paulo Alcantara (SUSE) authored
For the case where we have a DFS path like below and we're currently connected to targetA: //dfsroot/link -> //targetA/share/foo, //targetB/share/bar after failover, we should make sure to update cifs_sb->prepath so the next operations will use the new prefix path "/bar". Besides, in order to simplify the use of different prefix paths, enforce CIFS_MOUNT_USE_PREFIX_PATH for DFS mounts so we don't have to revalidate the root dentry every time we set a new prefix path. Signed-off-by: -
Steve French authored
Check the AT_STATX_FORCE_SYNC flag and force an attribute revalidation if requested by the caller, and if the caller specificies AT_STATX_DONT_SYNC only revalidate cached attributes if required. In addition do not flush writes in getattr (which can be expensive) if size or timestamps not requested by the caller. Reviewed-by:
-
Linus Torvalds authored
-
- 22 Mar, 2020 11 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linuxLinus Torvalds authored
Pull btrfs fixes from David Sterba: "Two fixes. The first is a regression: when dropping some incompat bits the conditions were reversed. The other is a fix for rename whiteout potentially leaving stack memory linked to a list" * tag 'for-5.6-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix removal of raid[56|1c34} incompat flags after removing block group btrfs: fix log context list corruption after rename whiteout error
-
Linus Torvalds authored
Merge misc fixes from Andrew Morton: "10 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: x86/mm: split vmalloc_sync_all() mm, slub: prevent kmalloc_node crashes and memory leaks mm/mmu_notifier: silence PROVE_RCU_LIST warnings epoll: fix possible lost wakeup on epoll_ctl() path mm: do not allow MADV_PAGEOUT for CoW pages mm, memcg: throttle allocators based on ancestral memory.high mm, memcg: fix corruption on 64-bit divisor in memory.high throttling page-flags: fix a crash at SetPageError(THP_SWAP) mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case memcg: fix NULL pointer dereference in __mem_cgroup_usage_unregister_event
-
Joerg Roedel authored
Commit 3f8fd02b ("mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()") introduced a call to vmalloc_sync_all() in the vunmap() code-path. While this change was necessary to maintain correctness on x86-32-pae kernels, it also adds additional cycles for architectures that don't need it. Specifically on x86-64 with CONFIG_VMAP_STACK=y some people reported severe performance regressions in micro-benchmarks because it now also calls the x86-64 implementation of vmalloc_sync_all() on vunmap(). But the vmalloc_sync_all() implementation on x86-64 is only needed for newly created mappings. To avoid the unnecessary work on x86-64 and to gain the performance back, split up vmalloc_sync_all() into two functions: * vmalloc_sync_mappings(), and * vmalloc_sync_unmappings() Most call-sites to vmalloc_sync_all() only care about new mappings being synchronized. The only exception is the new call-site added in the above mentioned commit. Shile Zhang directed us to a report of an 80% regression in reaim throughput. Fixes: 3f8fd02b ("mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()") Reported-by:
kernel test robot <oliver.sang@intel.com> Reported-by:
Shile Zhang <shile.zhang@linux.alibaba.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Tested-by:
Borislav Petkov <bp@suse.de> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [GHES] Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20191009124418.8286-1-joro@8bytes.org Link: https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/4D3JPPHBNOSPFK2KEPC6KGKS6J25AIDB/ Link: http://lkml.kernel.org/r/20191113095530.228959-1-shile.zhang@linux.alibaba.comSigned-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Vlastimil Babka authored
Sachin reports [1] a crash in SLUB __slab_alloc(): BUG: Kernel NULL pointer dereference on read at 0x000073b0 Faulting instruction address: 0xc0000000003d55f4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 19 PID: 1 Comm: systemd Not tainted 5.6.0-rc2-next-20200218-autotest #1 NIP: c0000000003d55f4 LR: c0000000003d5b94 CTR: 0000000000000000 REGS: c0000008b37836d0 TRAP: 0300 Not tainted (5.6.0-rc2-next-20200218-autotest) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24004844 XER: 00000000 CFAR: c00000000000dec4 DAR: 00000000000073b0 DSISR: 40000000 IRQMASK: 1 GPR00: c0000000003d5b94 c0000008b3783960 c00000000155d400 c0000008b301f500 GPR04: 0000000000000dc0 0000000000000002 c0000000003443d8 c0000008bb398620 GPR08: 00000008ba2f0000 0000000000000001 0000000000000000 0000000000000000 GPR12: 0000000024004844 c00000001ec52a00 0000000000000000 0000000000000000 GPR16: c0000008a1b20048 c000000001595898 c000000001750c18 0000000000000002 GPR20: c000000001750c28 c000000001624470 0000000fffffffe0 5deadbeef0000122 GPR24: 0000000000000001 0000000000000dc0 0000000000000002 c0000000003443d8 GPR28: c0000008b301f500 c0000008bb398620 0000000000000000 c00c000002287180 NIP ___slab_alloc+0x1f4/0x760 LR __slab_alloc+0x34/0x60 Call Trace: ___slab_alloc+0x334/0x760 (unreliable) __slab_alloc+0x34/0x60 __kmalloc_node+0x110/0x490 kvmalloc_node+0x58/0x110 mem_cgroup_css_online+0x108/0x270 online_css+0x48/0xd0 cgroup_apply_control_enable+0x2ec/0x4d0 cgroup_mkdir+0x228/0x5f0 kernfs_iop_mkdir+0x90/0xf0 vfs_mkdir+0x110/0x230 do_mkdirat+0xb0/0x1a0 system_call+0x5c/0x68 This is a PowerPC platform with following NUMA topology: available: 2 nodes (0-1) node 0 cpus: node 0 size: 0 MB node 0 free: 0 MB node 1 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 node 1 size: 35247 MB node 1 free: 30907 MB node distances: node 0 1 0: 10 40 1: 40 10 possible numa nodes: 0-31 This only happens with a mmotm patch "mm/memcontrol.c: allocate shrinker_map on appropriate NUMA node" [2] which effectively calls kmalloc_node for each possible node. SLUB however only allocates kmem_cache_node on online N_NORMAL_MEMORY nodes, and relies on node_to_mem_node to return such valid node for other nodes since commit a561ce00 ("slub: fall back to node_to_mem_node() node if allocating on memoryless node"). This is however not true in this configuration where the _node_numa_mem_ array is not initialized for nodes 0 and 2-31, thus it contains zeroes and get_partial() ends up accessing non-allocated kmem_cache_node. A related issue was reported by Bharata (originally by Ramachandran) [3] where a similar PowerPC configuration, but with mainline kernel without patch [2] ends up allocating large amounts of pages by kmalloc-1k kmalloc-512. This seems to have the same underlying issue with node_to_mem_node() not behaving as expected, and might probably also lead to an infinite loop with CONFIG_SLUB_CPU_PARTIAL [4]. This patch should fix both issues by not relying on node_to_mem_node() anymore and instead simply falling back to NUMA_NO_NODE, when kmalloc_node(node) is attempted for a node that's not online, or has no usable memory. The "usable memory" condition is also changed from node_present_pages() to N_NORMAL_MEMORY node state, as that is exactly the condition that SLUB uses to allocate kmem_cache_node structures. The check in get_partial() is removed completely, as the checks in ___slab_alloc() are now sufficient to prevent get_partial() being reached with an invalid node. [1] https://lore.kernel.org/linux-next/3381CD91-AB3D-4773-BA04-E7A072A63968@linux.vnet.ibm.com/ [2] https://lore.kernel.org/linux-mm/fff0e636-4c36-ed10-281c-8cdb0687c839@virtuozzo.com/ [3] https://lore.kernel.org/linux-mm/20200317092624.GB22538@in.ibm.com/ [4] https://lore.kernel.org/linux-mm/088b5996-faae-8a56-ef9c-5b567125ae54@suse.cz/ Fixes: a561ce00 ("slub: fall back to node_to_mem_node() node if allocating on memoryless node") Reported-by:Sachin Sant <sachinp@linux.vnet.ibm.com> Reported-by:
PUVICHAKRAVARTHY RAMACHANDRAN <puvichakravarthy@in.ibm.com> Signed-off-by:
Vlastimil Babka <vbabka@suse.cz> Signed-off-by:
Bharata B Rao <bharata@linux.ibm.com> Reviewed-by:
Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Hocko <mhocko@kernel.org> Cc: Christopher Lameter <cl@linux.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Nathan Lynch <nathanl@linux.ibm.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20200320115533.9604-1-vbabka@suse.czDebugged-by:
-
Qian Cai authored
It is safe to traverse mm->notifier_subscriptions->list either under SRCU read lock or mm->notifier_subscriptions->lock using hlist_for_each_entry_rcu(). Silence the PROVE_RCU_LIST false positives, for example, WARNING: suspicious RCU usage ----------------------------- mm/mmu_notifier.c:484 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by libvirtd/802: #0: ffff9321e3f58148 (&mm->mmap_sem#2){++++}, at: do_mprotect_pkey+0xe1/0x3e0 #1: ffffffff91ae6160 (mmu_notifier_invalidate_range_start){+.+.}, at: change_p4d_range+0x5fa/0x800 #2: ffffffff91ae6e08 (srcu){....}, at: __mmu_notifier_invalidate_range_start+0x178/0x460 stack backtrace: CPU: 7 PID: 802 Comm: libvirtd Tainted: G I 5.6.0-rc6-next-20200317+ #2 Hardware name: HP ProLiant BL460c Gen8, BIOS I31 11/02/2014 Call Trace: dump_stack+0xa4/0xfe lockdep_rcu_suspicious+0xeb/0xf5 __mmu_notifier_invalidate_range_start+0x3ff/0x460 change_p4d_range+0x746/0x800 change_protection+0x1df/0x300 mprotect_fixup+0x245/0x3e0 do_mprotect_pkey+0x23b/0x3e0 __x64_sys_mprotect+0x51/0x70 do_syscall_64+0x91/0xae8 entry_SYSCALL_64_after_hwframe+0x49/0xb3 Signed-off-by:Qian Cai <cai@lca.pw> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Reviewed-by:
Jason Gunthorpe <jgg@mellanox.com> Link: http://lkml.kernel.org/r/20200317175640.2047-1-cai@lca.pwSigned-off-by:
-
Roman Penyaev authored
This fixes possible lost wakeup introduced by commit a218cc49. Originally modifications to ep->wq were serialized by ep->wq.lock, but in commit a218cc49 ("epoll: use rwlock in order to reduce ep_poll_callback() contention") a new rw lock was introduced in order to relax fd event path, i.e. callers of ep_poll_callback() function. After the change ep_modify and ep_insert (both are called on epoll_ctl() path) were switched to ep->lock, but ep_poll (epoll_wait) was using ep->wq.lock on wqueue list modification. The bug doesn't lead to any wqueue list corruptions, because wake up path and list modifications were serialized by ep->wq.lock internally, but actual waitqueue_active() check prior wake_up() call can be reordered with modifications of ep ready list, thus wake up can be lost. And yes, can be healed by explicit smp_mb(): list_add_tail(&epi->rdlink, &ep->rdllist); smp_mb(); if (waitqueue_active(&ep->wq)) wake_up(&ep->wp); But let's make it simple, thus current patch replaces ep->wq.lock with the ep->lock for wqueue modifications, thus wake up path always observes activeness of the wqueue correcty. Fixes: a218cc49 ("epoll: use rwlock in order to reduce ep_poll_callback() contention") Reported-by:
Max Neunhoeffer <max@arangodb.com> Signed-off-by:
Roman Penyaev <rpenyaev@suse.de> Signed-off-by:
-
Michal Hocko authored
Jann has brought up a very interesting point [1]. While shared pages are excluded from MADV_PAGEOUT normally, CoW pages can be easily reclaimed that way. This can lead to all sorts of hard to debug problems. E.g. performance problems outlined by Daniel [2]. There are runtime environments where there is a substantial memory shared among security domains via CoW memory and a easy to reclaim way of that memory, which MADV_{COLD,PAGEOUT} offers, can lead to either performance degradation in for the parent process which might be more privileged or even open side channel attacks. The feasibility of the latter is not really clear to me TBH but there is no real reason for exposure at this stage. It seems there is no real use case to depend on reclaiming CoW memory via madvise at this stage so it is much easier to simply disallow it and this is what this patch does. Put it simply MADV_{PAGEOUT,COLD} can operate only on the exclusively owned memory which is a straightforward semantic. [1] http://lkml.kernel.org/r/CAG48ez0G3JkMq61gUmyQAaCq=_TwHbi1XKzWRooxZkv08PQKuw@mail.gmail.com [2] http://lkml.kernel.org/r/CAKOZueua_v8jHCpmEtTB6f3i9e2YnmX4mqdYVWhV4E=Z-n+zRQ@mail.gmail.com Fixes: 9c276cc6 ("mm: introduce MADV_COLD") Reported-by:Jann Horn <jannh@google.com> Signed-off-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
-
Chris Down authored
Prior to this commit, we only directly check the affected cgroup's memory.high against its usage. However, it's possible that we are being reclaimed as a result of hitting an ancestor memory.high and should be penalised based on that, instead. This patch changes memory.high overage throttling to use the largest overage in its ancestors when considering how many penalty jiffies to charge. This makes sure that we penalise poorly behaving cgroups in the same way regardless of at what level of the hierarchy memory.high was breached. Fixes: 0e4b01df ("mm, memcg: throttle allocators when failing reclaim over memory.high") Reported-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
Chris Down <chris@chrisdown.name> Signed-off-by:
-
Chris Down authored
Commit 0e4b01df had a bunch of fixups to use the right division method. However, it seems that after all that it still wasn't right -- div_u64 takes a 32-bit divisor. The headroom is still large (2^32 pages), so on mundane systems you won't hit this, but this should definitely be fixed. Fixes: 0e4b01df ("mm, memcg: throttle allocators when failing reclaim over memory.high") Reported-by:
-
Qian Cai authored
Commit bd4c82c2 ("mm, THP, swap: delay splitting THP after swapped out") supported writing THP to a swap device but forgot to upgrade an older commit df8c94d1 ("page-flags: define behavior of FS/IO-related flags on compound pages") which could trigger a crash during THP swapping out with DEBUG_VM_PGFLAGS=y, kernel BUG at include/linux/page-flags.h:317! page dumped because: VM_BUG_ON_PAGE(1 && PageCompound(page)) page:fffff3b2ec3a8000 refcount:512 mapcount:0 mapping:000000009eb0338c index:0x7f6e58200 head:fffff3b2ec3a8000 order:9 compound_mapcount:0 compound_pincount:0 anon flags: 0x45fffe0000d8454(uptodate|lru|workingset|owner_priv_1|writeback|head|reclaim|swapbacked) end_swap_bio_write() SetPageError(page) VM_BUG_ON_PAGE(1 && PageCompound(page)) <IRQ> bio_endio+0x297/0x560 dec_pending+0x218/0x430 [dm_mod] clone_endio+0xe4/0x2c0 [dm_mod] bio_endio+0x297/0x560 blk_update_request+0x201/0x920 scsi_end_request+0x6b/0x4b0 scsi_io_completion+0x509/0x7e0 scsi_finish_command+0x1ed/0x2a0 scsi_softirq_done+0x1c9/0x1d0 __blk_mqnterrupt+0xf/0x20 </IRQ> Fix by checking PF_NO_TAIL in those places instead. Fixes: bd4c82c2 ("mm, THP, swap: delay splitting THP after swapped out") Signed-off-by:
David Hildenbrand <david@redhat.com> Acked-by:
"Huang, Ying" <ying.huang@intel.com> Acked-by:
Rafael Aquini <aquini@redhat.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20200310235846.1319-1-cai@lca.pwSigned-off-by:
-
Baoquan He authored
In section_deactivate(), pfn_to_page() doesn't work any more after ms->section_mem_map is resetting to NULL in SPARSEMEM|!VMEMMAP case. It causes a hot remove failure: kernel BUG at mm/page_alloc.c:4806! invalid opcode: 0000 [#1] SMP PTI CPU: 3 PID: 8 Comm: kworker/u16:0 Tainted: G W 5.5.0-next-20200205+ #340 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Workqueue: kacpi_hotplug acpi_hotplug_work_fn RIP: 0010:free_pages+0x85/0xa0 Call Trace: __remove_pages+0x99/0xc0 arch_remove_memory+0x23/0x4d try_remove_memory+0xc8/0x130 __remove_memory+0xa/0x11 acpi_memory_device_remove+0x72/0x100 acpi_bus_trim+0x55/0x90 acpi_device_hotplug+0x2eb/0x3d0 acpi_hotplug_work_fn+0x1a/0x30 process_one_work+0x1a7/0x370 worker_thread+0x30/0x380 kthread+0x112/0x130 ret_from_fork+0x35/0x40 Let's move the ->section_mem_map resetting after depopulate_section_memmap() to fix it. [akpm@linux-foundation.org: remove unneeded initialization, per David] Fixes: ba72b4c8 ("mm/sparsemem: support sub-section hotplug") Signed-off-by:
Baoquan He <bhe@redhat.com> Signed-off-by:
Pankaj Gupta <pankaj.gupta.linux@gmail.com> Reviewed-by:
-
