8b11ff09 | 03-Jul-2022 |
Kent Overstreet <kent.overstreet@gmail.com> |
9p: Add client parameter to p9_req_put()
This is to aid in adding mempools, in the next patch.
Link: https://lkml.kernel.org/r/20220704014243.153050-2-kent.overstreet@gmail.com Signed-off-by: Kent
9p: Add client parameter to p9_req_put()
This is to aid in adding mempools, in the next patch.
Link: https://lkml.kernel.org/r/20220704014243.153050-2-kent.overstreet@gmail.com Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Latchesar Ionkov <lucho@ionkov.net> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
show more ...
|
6cda1286 | 03-Jul-2022 |
Kent Overstreet <kent.overstreet@gmail.com> |
9p: Drop kref usage
An upcoming patch is going to require passing the client through p9_req_put() -> p9_req_free(), but that's awkward with the kref indirection - so this patch switches to using ref
9p: Drop kref usage
An upcoming patch is going to require passing the client through p9_req_put() -> p9_req_free(), but that's awkward with the kref indirection - so this patch switches to using refcount_t directly.
Link: https://lkml.kernel.org/r/20220704014243.153050-1-kent.overstreet@gmail.com Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Latchesar Ionkov <lucho@ionkov.net> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
show more ...
|
286c171b | 12-Jun-2022 |
Dominique Martinet <asmadeus@codewreck.org> |
9p fid refcount: add a 9p_fid_ref tracepoint
This adds a tracepoint event for 9p fid lifecycle tracing: when a fid is created, its reference count increased/decreased, and freed. The new 9p_fid_ref
9p fid refcount: add a 9p_fid_ref tracepoint
This adds a tracepoint event for 9p fid lifecycle tracing: when a fid is created, its reference count increased/decreased, and freed. The new 9p_fid_ref tracepoint should help anyone wishing to debug any fid problem such as missing clunk (destroy) or use-after-free.
Link: https://lkml.kernel.org/r/20220612085330.1451496-6-asmadeus@codewreck.org Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
show more ...
|
019641d1 | 03-Nov-2021 |
Thomas Weißschuh <linux@weissschuh.net> |
net/p9: load default transports
Now that all transports are split into modules it may happen that no transports are registered when v9fs_get_default_trans() is called. When that is the case try to l
net/p9: load default transports
Now that all transports are split into modules it may happen that no transports are registered when v9fs_get_default_trans() is called. When that is the case try to load more transports from modules.
Link: https://lkml.kernel.org/r/20211103193823.111007-5-linux@weissschuh.net Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> [Dominique: constify v9fs_get_trans_by_name argument as per patch1v2] Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
show more ...
|
ff5e72eb | 03-Nov-2020 |
Dominique Martinet <asmadeus@codewreck.org> |
9p: apply review requests for fid refcounting
Fix style issues in parent commit ("apply review requests for fid refcounting"), no functional change.
Link: http://lkml.kernel.org/r/1605802012-31133-
9p: apply review requests for fid refcounting
Fix style issues in parent commit ("apply review requests for fid refcounting"), no functional change.
Link: http://lkml.kernel.org/r/1605802012-31133-2-git-send-email-asmadeus@codewreck.org Fixes: 6636b6dcc3db ("9p: add refcount to p9_fid struct") Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
show more ...
|
6636b6dc | 23-Sep-2020 |
Jianyong Wu <jianyong.wu@arm.com> |
9p: add refcount to p9_fid struct
Fix race issue in fid contention.
Eric's and Greg's patch offer a mechanism to fix open-unlink-f*syscall bug in 9p. But there is race issue in fid parallel accesse
9p: add refcount to p9_fid struct
Fix race issue in fid contention.
Eric's and Greg's patch offer a mechanism to fix open-unlink-f*syscall bug in 9p. But there is race issue in fid parallel accesses. As Greg's patch stores all of fids from opened files into according inode, so all the lookup fid ops can retrieve fid from inode preferentially. But there is no mechanism to handle the fid contention issue. For example, there are two threads get the same fid in the same time and one of them clunk the fid before the other thread ready to discard the fid. In this scenario, it will lead to some fatal problems, even kernel core dump.
I introduce a mechanism to fix this race issue. A counter field introduced into p9_fid struct to store the reference counter to the fid. When a fid is allocated from the inode or dentry, the counter will increase, and will decrease at the end of its occupation. It is guaranteed that the fid won't be clunked before the reference counter go down to 0, then we can avoid the clunked fid to be used.
tests: race issue test from the old test case: for file in {01..50}; do touch f.${file}; done seq 1 1000 | xargs -n 1 -P 50 -I{} cat f.* > /dev/null
open-unlink-f*syscall test: I have tested for f*syscall include: ftruncate fstat fchown fchmod faccessat.
Link: http://lkml.kernel.org/r/20200923141146.90046-5-jianyong.wu@arm.com Fixes: 478ba09edc1f ("fs/9p: search open fids first") Signed-off-by: Jianyong Wu <jianyong.wu@arm.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
show more ...
|
43657496 | 05-Feb-2020 |
Dominique Martinet <dominique.martinet@cea.fr> |
net/9p: remove unused p9_req_t aux field
The p9_req_t field 'aux' has not been used in a very long time, remove leftover field declaration
Link: http://lkml.kernel.org/r/1580941152-12973-1-git-send
net/9p: remove unused p9_req_t aux field
The p9_req_t field 'aux' has not been used in a very long time, remove leftover field declaration
Link: http://lkml.kernel.org/r/1580941152-12973-1-git-send-email-asmadeus@codewreck.org Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
show more ...
|
728356de | 14-Aug-2018 |
Tomas Bortoli <tomasbortoli@gmail.com> |
9p: Add refcount to p9_req_t
To avoid use-after-free(s), use a refcount to keep track of the usable references to any instantiated struct p9_req_t.
This commit adds p9_req_put(), p9_req_get() and p
9p: Add refcount to p9_req_t
To avoid use-after-free(s), use a refcount to keep track of the usable references to any instantiated struct p9_req_t.
This commit adds p9_req_put(), p9_req_get() and p9_req_try_get() as wrappers to kref_put(), kref_get() and kref_get_unless_zero(). These are used by the client and the transports to keep track of valid requests' references.
p9_free_req() is added back and used as callback by kref_put().
Add SLAB_TYPESAFE_BY_RCU as it ensures that the memory freed by kmem_cache_free() will not be reused for another type until the rcu synchronisation period is over, so an address gotten under rcu read lock is safe to inc_ref() without corrupting random memory while the lock is held.
Link: http://lkml.kernel.org/r/1535626341-20693-1-git-send-email-asmadeus@codewreck.org Co-developed-by: Dominique Martinet <dominique.martinet@cea.fr> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com> Reported-by: syzbot+467050c1ce275af2a5b8@syzkaller.appspotmail.com Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
show more ...
|
91a76be3 | 30-Jul-2018 |
Dominique Martinet <dominique.martinet@cea.fr> |
9p: add a per-client fcall kmem_cache
Having a specific cache for the fcall allocations helps speed up end-to-end latency.
The caches will automatically be merged if there are multiple caches of it
9p: add a per-client fcall kmem_cache
Having a specific cache for the fcall allocations helps speed up end-to-end latency.
The caches will automatically be merged if there are multiple caches of items with the same size so we do not need to try to share a cache between different clients of the same size.
Since the msize is negotiated with the server, only allocate the cache after that negotiation has happened - previous allocations or allocations of different sizes (e.g. zero-copy fcall) are made with kmalloc directly.
Some figures on two beefy VMs with Connect-IB (sriov) / trans=rdma, with ior running 32 processes in parallel doing small 32 bytes IOs: - no alloc (4.18-rc7 request cache): 65.4k req/s - non-power of two alloc, no patch: 61.6k req/s - power of two alloc, no patch: 62.2k req/s - non-power of two alloc, with patch: 64.7k req/s - power of two alloc, with patch: 65.1k req/s
Link: http://lkml.kernel.org/r/1532943263-24378-2-git-send-email-asmadeus@codewreck.org Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr> Acked-by: Jun Piao <piaojun@huawei.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Greg Kurz <groug@kaod.org>
show more ...
|
523adb6c | 30-Jul-2018 |
Dominique Martinet <dominique.martinet@cea.fr> |
9p: embed fcall in req to round down buffer allocs
'msize' is often a power of two, or at least page-aligned, so avoiding an overhead of two dozen bytes for each allocation will help the allocator d
9p: embed fcall in req to round down buffer allocs
'msize' is often a power of two, or at least page-aligned, so avoiding an overhead of two dozen bytes for each allocation will help the allocator do its work and reduce memory fragmentation.
Link: http://lkml.kernel.org/r/1533825236-22896-1-git-send-email-asmadeus@codewreck.org Suggested-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr> Reviewed-by: Greg Kurz <groug@kaod.org> Acked-by: Jun Piao <piaojun@huawei.com> Cc: Matthew Wilcox <willy@infradead.org>
show more ...
|
6348b903 | 11-Jul-2018 |
Matthew Wilcox <willy@infradead.org> |
9p: Remove p9_idpool
There are no more users left of the p9_idpool; delete it.
Link: http://lkml.kernel.org/r/20180711210225.19730-7-willy@infradead.org Signed-off-by: Matthew Wilcox <willy@infrade
9p: Remove p9_idpool
There are no more users left of the p9_idpool; delete it.
Link: http://lkml.kernel.org/r/20180711210225.19730-7-willy@infradead.org Signed-off-by: Matthew Wilcox <willy@infradead.org> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Ron Minnich <rminnich@sandia.gov> Cc: Latchesar Ionkov <lucho@ionkov.net> Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
show more ...
|