2019-05-19 13:08:55 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-13 15:23:48 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-16 13:38:26 -08:00
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-19 23:28:16 -07:00
|
|
|
|
2011-05-26 16:00:52 -04:00
|
|
|
|
2015-09-29 20:34:05 -04:00
|
|
|
|
|
|
|
|
|
2018-01-09 08:21:17 -05:00
|
|
|
|
2022-11-20 09:15:34 -05:00
|
|
|
|
2006-10-19 23:28:16 -07:00
|
|
|
|
2016-12-24 11:46:01 -08:00
|
|
|
|
2019-02-18 13:06:54 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-12-05 00:35:38 -05:00
|
|
|
|
2006-03-20 13:44:14 -05:00
|
|
|
|
2009-04-01 09:22:26 -04:00
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2011-03-01 01:34:14 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-08-19 18:59:33 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-20 19:35:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nfs: don't ignore return value from nfs_pageio_add_request
Ignoring the return value from nfs_pageio_add_request can cause deadlocks.
In read path:
call nfs_pageio_add_request from readpage_async_filler
assume at this point that there are requests already in desc, that
can't be merged with the current request.
so nfs_pageio_doio is fired up to clear out desc.
assume something goes wrong in setting up the io, so desc->pg_error is set.
This causes nfs_pageio_add_request to return 0, *WITHOUT* adding the original
request.
BUT, since return code is ignored, readpage_async_filler assumes it has
been added, and does nothing further, leaving page locked.
do_generic_mapping_read will eventually call lock_page, resulting in deadlock
In write path:
page is marked dirty by generic_perform_write
nfs_writepages is called
call nfs_pageio_add_request from nfs_page_async_flush
assume at this point that there are requests already in desc, that
can't be merged with the current request.
so nfs_pageio_doio is fired up to clear out desc.
assume something goes wrong in setting up the io, so desc->pg_error is set.
This causes nfs_page_async_flush to return 0, *WITHOUT* adding the original
request, yet marking the request as locked (PG_BUSY) and in writeback,
clearing dirty marks.
The next time a write is done to the page, deadlock will result as
nfs_write_end calls nfs_update_request
Signed-off-by: Fred Isaman <iisaman@citi.umich.edu>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2008-03-19 11:24:39 -04:00
|
|
|
|
2006-03-20 13:44:27 -05:00
|
|
|
|
2012-04-20 14:47:48 -04:00
|
|
|
|
2012-04-20 14:47:54 -04:00
|
|
|
|
2014-05-06 09:12:30 -04:00
|
|
|
|
2019-08-14 15:42:43 -04:00
|
|
|
|
2023-09-04 12:34:40 -04:00
|
|
|
|
|
|
|
|
|
2014-07-17 20:42:17 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-12-06 20:33:20 -08:00
|
|
|
|
2006-03-20 13:44:37 -05:00
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2022-03-21 12:34:19 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
NFS: fix usage of mempools.
When passed GFP flags that allow sleeping (such as
GFP_NOIO), mempool_alloc() will never return NULL, it will
wait until memory is available.
This means that we don't need to handle failure, but that we
do need to ensure one thread doesn't call mempool_alloc()
twice on the one pool without queuing or freeing the first
allocation. If multiple threads did this during times of
high memory pressure, the pool could be exhausted and a
deadlock could result.
pnfs_generic_alloc_ds_commits() attempts to allocate from
the nfs_commit_mempool while already holding an allocation
from that pool. This is not safe. So change
nfs_commitdata_alloc() to take a flag that indicates whether
failure is acceptable.
In pnfs_generic_alloc_ds_commits(), accept failure and
handle it as we currently do. Else where, do not accept
failure, and do not handle it.
Even when failure is acceptable, we want to succeed if
possible. That means both
- using an entry from the pool if there is one
- waiting for direct reclaim is there isn't.
We call mempool_alloc(GFP_NOWAIT) to achieve the first, then
kmem_cache_alloc(GFP_NOIO|__GFP_NORETRY) to achieve the
second. Each of these can fail, but together they do the
best they can without blocking indefinitely.
The objects returned by kmem_cache_alloc() will still be freed
by mempool_free(). This is safe as mempool_alloc() uses
exactly the same function to allocate objects (since the mempool
was created with mempool_create_slab_pool()). The object returned
by mempool_alloc() and kmem_cache_alloc() are indistinguishable
so mempool_free() will handle both identically, either adding to the
pool or calling kmem_cache_free().
Also, don't test for failure when allocating from
nfs_wdata_mempool.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2017-04-10 12:22:09 +10:00
|
|
|
|
2005-11-30 18:09:02 -05:00
|
|
|
|
2022-03-21 12:34:19 -04:00
|
|
|
|
|
|
|
|
|
NFS: fix usage of mempools.
When passed GFP flags that allow sleeping (such as
GFP_NOIO), mempool_alloc() will never return NULL, it will
wait until memory is available.
This means that we don't need to handle failure, but that we
do need to ensure one thread doesn't call mempool_alloc()
twice on the one pool without queuing or freeing the first
allocation. If multiple threads did this during times of
high memory pressure, the pool could be exhausted and a
deadlock could result.
pnfs_generic_alloc_ds_commits() attempts to allocate from
the nfs_commit_mempool while already holding an allocation
from that pool. This is not safe. So change
nfs_commitdata_alloc() to take a flag that indicates whether
failure is acceptable.
In pnfs_generic_alloc_ds_commits(), accept failure and
handle it as we currently do. Else where, do not accept
failure, and do not handle it.
Even when failure is acceptable, we want to succeed if
possible. That means both
- using an entry from the pool if there is one
- waiting for direct reclaim is there isn't.
We call mempool_alloc(GFP_NOWAIT) to achieve the first, then
kmem_cache_alloc(GFP_NOIO|__GFP_NORETRY) to achieve the
second. Each of these can fail, but together they do the
best they can without blocking indefinitely.
The objects returned by kmem_cache_alloc() will still be freed
by mempool_free(). This is safe as mempool_alloc() uses
exactly the same function to allocate objects (since the mempool
was created with mempool_create_slab_pool()). The object returned
by mempool_alloc() and kmem_cache_alloc() are indistinguishable
so mempool_free() will handle both identically, either adding to the
pool or calling kmem_cache_free().
Also, don't test for failure when allocating from
nfs_wdata_mempool.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2017-04-10 12:22:09 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-21 12:34:19 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
NFS: fix usage of mempools.
When passed GFP flags that allow sleeping (such as
GFP_NOIO), mempool_alloc() will never return NULL, it will
wait until memory is available.
This means that we don't need to handle failure, but that we
do need to ensure one thread doesn't call mempool_alloc()
twice on the one pool without queuing or freeing the first
allocation. If multiple threads did this during times of
high memory pressure, the pool could be exhausted and a
deadlock could result.
pnfs_generic_alloc_ds_commits() attempts to allocate from
the nfs_commit_mempool while already holding an allocation
from that pool. This is not safe. So change
nfs_commitdata_alloc() to take a flag that indicates whether
failure is acceptable.
In pnfs_generic_alloc_ds_commits(), accept failure and
handle it as we currently do. Else where, do not accept
failure, and do not handle it.
Even when failure is acceptable, we want to succeed if
possible. That means both
- using an entry from the pool if there is one
- waiting for direct reclaim is there isn't.
We call mempool_alloc(GFP_NOWAIT) to achieve the first, then
kmem_cache_alloc(GFP_NOIO|__GFP_NORETRY) to achieve the
second. Each of these can fail, but together they do the
best they can without blocking indefinitely.
The objects returned by kmem_cache_alloc() will still be freed
by mempool_free(). This is safe as mempool_alloc() uses
exactly the same function to allocate objects (since the mempool
was created with mempool_create_slab_pool()). The object returned
by mempool_alloc() and kmem_cache_alloc() are indistinguishable
so mempool_free() will handle both identically, either adding to the
pool or calling kmem_cache_free().
Also, don't test for failure when allocating from
nfs_wdata_mempool.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2017-04-10 12:22:09 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-03-23 13:27:53 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-23 13:27:53 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-06-09 11:48:33 -04:00
|
|
|
|
2006-03-20 13:44:37 -05:00
|
|
|
|
2022-03-21 13:48:36 -04:00
|
|
|
|
2012-04-20 14:47:44 -04:00
|
|
|
|
2022-03-21 13:48:36 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-18 17:12:51 +10:00
|
|
|
|
2006-03-20 13:44:37 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-09 11:48:33 -04:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
2014-06-09 11:48:33 -04:00
|
|
|
|
2006-03-20 13:44:37 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-06-20 19:35:37 -04:00
|
|
|
|
|
|
|
|
|
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-20 23:49:23 -08:00
|
|
|
|
2017-06-20 19:35:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-04 21:09:21 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-16 07:25:20 -07:00
|
|
|
|
2024-11-04 21:09:21 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2014-07-11 10:20:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2006-12-05 00:35:35 -05:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2017-08-01 12:06:30 -04:00
|
|
|
|
2006-12-05 00:35:35 -05:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2017-08-01 12:26:53 -04:00
|
|
|
|
2023-11-17 21:58:23 +00:00
|
|
|
|
2024-07-01 07:26:49 +02:00
|
|
|
|
2014-07-11 10:20:47 -04:00
|
|
|
|
|
|
|
|
|
2012-07-31 16:45:10 -07:00
|
|
|
|
2014-07-11 10:20:47 -04:00
|
|
|
|
2023-11-17 21:58:23 +00:00
|
|
|
|
2017-08-01 12:26:53 -04:00
|
|
|
|
|
|
|
|
|
2012-07-31 16:45:10 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2008-06-11 12:21:19 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-06-11 12:21:19 -04:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2008-06-11 12:21:19 -04:00
|
|
|
|
nfs: drop usage of folio_file_pos
folio_file_pos is only needed for mixed usage of page cache and swap
cache, for pure page cache usage, the caller can just use folio_pos
instead.
After commit e1209d3a7a67 ("mm: introduce ->swap_rw and use it for reads
from SWP_FS_OPS swap-space"), swap cache should never be exposed to nfs.
So remove the usage of folio_file_pos in following NFS functions / helpers:
- nfs_vm_page_mkwrite
It's only used by nfs_file_vm_ops.page_mkwrite
- trace event helper: nfs_folio_event
- trace event helper: nfs_folio_event_done
These two are used through DEFINE_NFS_FOLIO_EVENT and
DEFINE_NFS_FOLIO_EVENT_DONE, which defined following events:
- trace_nfs_aop_readpage{_done}: only called by nfs_read_folio
- trace_nfs_writeback_folio: only called by nfs_wb_folio
- trace_nfs_invalidate_folio: only called by nfs_invalidate_folio
- trace_nfs_launder_folio_done: only called by nfs_launder_folio
None of them could possibly be used on swap cache folio,
nfs_read_folio only called by:
.write_begin -> nfs_read_folio
.read_folio
nfs_wb_folio only called by nfs mapping:
.release_folio -> nfs_wb_folio
.launder_folio -> nfs_wb_folio
.write_begin -> nfs_read_folio -> nfs_wb_folio
.read_folio -> nfs_wb_folio
.write_end -> nfs_update_folio -> nfs_writepage_setup -> nfs_setup_write_request -> nfs_try_to_update_request -> nfs_wb_folio
.page_mkwrite -> nfs_update_folio -> nfs_writepage_setup -> nfs_setup_write_request -> nfs_try_to_update_request -> nfs_wb_folio
.write_begin -> nfs_flush_incompatible -> nfs_wb_folio
.page_mkwrite -> nfs_vm_page_mkwrite -> nfs_flush_incompatible -> nfs_wb_folio
nfs_invalidate_folio is only called by .invalidate_folio.
nfs_launder_folio is only called by .launder_folio
- nfs_grow_file
- nfs_update_folio
nfs_grow_file is only called by nfs_update_folio, and all
possible callers of them are:
.write_end -> nfs_update_folio
.page_mkwrite -> nfs_update_folio
- nfs_wb_folio_cancel
.invalidate_folio -> nfs_wb_folio_cancel
Also, seeing from the swap side, swap_rw is now the only interface calling
into fs, the offset info is always in iocb.ki_pos now.
So we can remove all these folio_file_pos call safely.
Link: https://lkml.kernel.org/r/20240521175854.96038-8-ryncsn@gmail.com
Signed-off-by: Kairui Song <kasong@tencent.com>
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: Anna Schumaker <anna@kernel.org>
Cc: Barry Song <v-songbaohua@oppo.com>
Cc: Chao Yu <chao@kernel.org>
Cc: Chris Li <chrisl@kernel.org>
Cc: David Hildenbrand <david@redhat.com>
Cc: David Howells <dhowells@redhat.com>
Cc: "Huang, Ying" <ying.huang@intel.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ilya Dryomov <idryomov@gmail.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Jeff Layton <jlayton@kernel.org>
Cc: Marc Dionne <marc.dionne@auristor.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: NeilBrown <neilb@suse.de>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: Xiubo Li <xiubli@redhat.com>
Cc: Yosry Ahmed <yosryahmed@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-22 01:58:49 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-06-11 12:21:19 -04:00
|
|
|
|
2021-10-04 10:10:16 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-03-27 17:10:42 -04:00
|
|
|
|
2008-06-11 12:21:19 -04:00
|
|
|
|
|
|
|
|
|
2024-06-16 21:21:25 -04:00
|
|
|
|
|
|
|
|
|
2008-06-11 12:21:19 -04:00
|
|
|
|
nfs: Convert to new fscache volume/cookie API
Change the nfs filesystem to support fscache's indexing rewrite and
reenable caching in nfs.
The following changes have been made:
(1) The fscache_netfs struct is no more, and there's no need to register
the filesystem as a whole.
(2) The session cookie is now an fscache_volume cookie, allocated with
fscache_acquire_volume(). That takes three parameters: a string
representing the "volume" in the index, a string naming the cache to
use (or NULL) and a u64 that conveys coherency metadata for the
volume.
For nfs, I've made it render the volume name string as:
"nfs,<ver>,<family>,<address>,<port>,<fsidH>,<fsidL>*<,param>[,<uniq>]"
(3) The fscache_cookie_def is no more and needed information is passed
directly to fscache_acquire_cookie(). The cache no longer calls back
into the filesystem, but rather metadata changes are indicated at
other times.
fscache_acquire_cookie() is passed the same keying and coherency
information as before.
(4) fscache_enable/disable_cookie() have been removed.
Call fscache_use_cookie() and fscache_unuse_cookie() when a file is
opened or closed to prevent a cache file from being culled and to keep
resources to hand that are needed to do I/O.
If a file is opened for writing, we invalidate it with
FSCACHE_INVAL_DIO_WRITE in lieu of doing writeback to the cache,
thereby making it cease caching until all currently open files are
closed. This should give the same behaviour as the uptream code.
Making the cache store local modifications isn't straightforward for
NFS, so that's left for future patches.
(5) fscache_invalidate() now needs to be given uptodate auxiliary data and
a file size. It also takes a flag to indicate if this was due to a
DIO write.
(6) Call nfs_fscache_invalidate() with FSCACHE_INVAL_DIO_WRITE on a file
to which a DIO write is made.
(7) Call fscache_note_page_release() from nfs_release_page().
(8) Use a killable wait in nfs_vm_page_mkwrite() when waiting for
PG_fscache to be cleared.
(9) The functions to read and write data to/from the cache are stubbed out
pending a conversion to use netfslib.
Changes
=======
ver #3:
- Added missing =n fallback for nfs_fscache_release_file()[1][2].
ver #2:
- Use gfpflags_allow_blocking() rather than using flag directly.
- fscache_acquire_volume() now returns errors.
- Remove NFS_INO_FSCACHE as it's no longer used.
- Need to unuse a cookie on file-release, not inode-clear.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Co-developed-by: David Howells <dhowells@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Dave Wysochanski <dwysocha@redhat.com>
Acked-by: Jeff Layton <jlayton@kernel.org>
cc: Trond Myklebust <trond.myklebust@hammerspace.com>
cc: Anna Schumaker <anna.schumaker@netapp.com>
cc: linux-nfs@vger.kernel.org
cc: linux-cachefs@redhat.com
Link: https://lore.kernel.org/r/202112100804.nksO8K4u-lkp@intel.com/ [1]
Link: https://lore.kernel.org/r/202112100957.2oEDT20W-lkp@intel.com/ [2]
Link: https://lore.kernel.org/r/163819668938.215744.14448852181937731615.stgit@warthog.procyon.org.uk/ # v1
Link: https://lore.kernel.org/r/163906979003.143852.2601189243864854724.stgit@warthog.procyon.org.uk/ # v2
Link: https://lore.kernel.org/r/163967182112.1823006.7791504655391213379.stgit@warthog.procyon.org.uk/ # v3
Link: https://lore.kernel.org/r/164021575950.640689.12069642327533368467.stgit@warthog.procyon.org.uk/ # v4
2020-11-14 13:43:54 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-06 11:07:15 -08:00
|
|
|
|
2019-02-06 06:09:43 -05:00
|
|
|
|
2007-02-06 11:07:15 -08:00
|
|
|
|
2020-01-06 15:25:00 -05:00
|
|
|
|
|
|
|
|
|
2019-02-06 06:09:43 -05:00
|
|
|
|
2020-01-06 15:25:00 -05:00
|
|
|
|
|
|
|
|
|
2021-03-08 14:42:54 -05:00
|
|
|
|
2022-02-09 13:22:48 -05:00
|
|
|
|
2021-03-08 14:42:54 -05:00
|
|
|
|
2020-01-06 15:25:00 -05:00
|
|
|
|
2007-02-06 11:07:15 -08:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2019-04-07 13:59:05 -04:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2020-01-06 15:25:01 -05:00
|
|
|
|
2022-02-15 15:58:38 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-06 15:25:01 -05:00
|
|
|
|
2019-04-07 13:59:05 -04:00
|
|
|
|
|
|
|
|
|
2014-05-15 11:56:48 -04:00
|
|
|
|
2025-09-03 20:11:03 -04:00
|
|
|
|
|
|
|
|
|
2014-05-15 11:56:48 -04:00
|
|
|
|
2025-09-03 20:11:03 -04:00
|
|
|
|
|
|
|
|
|
2014-05-15 11:56:48 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2014-05-15 11:56:48 -04:00
|
|
|
|
2025-09-03 20:11:03 -04:00
|
|
|
|
2014-05-15 11:56:48 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-15 11:56:48 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-05-15 11:56:48 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-18 16:09:27 +10:00
|
|
|
|
2016-05-16 17:42:45 -04:00
|
|
|
|
2014-09-18 16:09:27 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-03-16 13:38:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2007-03-16 13:38:26 -08:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2007-04-14 19:10:12 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
2022-03-22 14:39:01 -07:00
|
|
|
|
2007-03-16 13:38:26 -08:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2007-03-16 13:38:26 -08:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2007-03-16 13:38:26 -08:00
|
|
|
|
2025-09-06 12:48:16 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2024-07-01 12:50:48 +02:00
|
|
|
|
2022-03-22 14:39:01 -07:00
|
|
|
|
2024-07-01 12:50:48 +02:00
|
|
|
|
|
|
|
|
|
2007-03-16 13:38:26 -08:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-18 15:22:12 -04:00
|
|
|
|
|
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-01 13:04:49 -04:00
|
|
|
|
|
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-01 13:04:49 -04:00
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
2017-07-19 13:50:07 -04:00
|
|
|
|
|
|
|
|
|
2017-07-19 10:06:36 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-01 13:04:49 -04:00
|
|
|
|
|
|
|
|
|
2017-07-19 10:06:36 -04:00
|
|
|
|
2020-04-01 13:04:49 -04:00
|
|
|
|
|
|
|
|
|
2017-07-19 10:06:36 -04:00
|
|
|
|
|
|
|
|
|
2020-04-01 13:04:49 -04:00
|
|
|
|
2017-07-19 10:06:36 -04:00
|
|
|
|
2020-04-01 10:07:16 -04:00
|
|
|
|
2017-07-19 10:06:36 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 15:39:46 -04:00
|
|
|
|
2017-07-19 10:06:36 -04:00
|
|
|
|
|
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
|
|
|
|
|
2017-07-19 10:06:36 -04:00
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-30 12:40:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-04 12:34:40 -04:00
|
|
|
|
|
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
2020-03-30 12:40:47 -04:00
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
2020-03-30 11:12:16 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-17 10:29:32 -04:00
|
|
|
|
|
|
|
|
|
2020-03-30 11:12:16 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-17 11:11:49 -04:00
|
|
|
|
2020-03-30 11:12:16 -04:00
|
|
|
|
|
|
|
|
|
2017-07-17 10:29:32 -04:00
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
2020-03-30 11:12:16 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-04 12:34:40 -04:00
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-18 15:22:12 -04:00
|
|
|
|
2020-03-30 12:40:47 -04:00
|
|
|
|
2014-07-11 10:20:48 -04:00
|
|
|
|
2024-07-01 07:26:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-01 07:26:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-30 12:40:47 -04:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2020-03-30 12:40:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2020-03-30 12:40:47 -04:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2020-03-30 12:40:47 -04:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2024-07-01 07:26:52 +02:00
|
|
|
|
2023-09-04 12:34:40 -04:00
|
|
|
|
2020-03-30 12:40:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-01 07:26:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-30 12:40:47 -04:00
|
|
|
|
2024-07-01 07:26:51 +02:00
|
|
|
|
|
|
|
|
|
2025-04-02 14:02:40 +03:00
|
|
|
|
|
|
|
|
|
2024-07-01 07:26:51 +02:00
|
|
|
|
2025-04-02 14:02:40 +03:00
|
|
|
|
2017-07-17 10:34:21 -04:00
|
|
|
|
|
|
|
|
|
2025-08-16 07:25:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-01 07:26:51 +02:00
|
|
|
|
|
|
|
|
|
2025-08-16 07:25:20 -07:00
|
|
|
|
2024-07-01 07:26:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-07 08:51:00 +01:00
|
|
|
|
2025-08-16 07:25:20 -07:00
|
|
|
|
2024-07-01 07:26:54 +02:00
|
|
|
|
2024-07-01 07:26:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-01 07:26:51 +02:00
|
|
|
|
2023-09-04 12:34:40 -04:00
|
|
|
|
2020-03-30 12:40:47 -04:00
|
|
|
|
2024-07-01 07:26:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
|
|
|
|
|
2019-04-07 13:59:05 -04:00
|
|
|
|
2015-12-05 15:57:31 +08:00
|
|
|
|
2023-01-19 16:33:38 -05:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2019-08-14 15:42:43 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2017-04-14 14:24:28 -04:00
|
|
|
|
2015-12-05 15:57:31 +08:00
|
|
|
|
|
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-05-07 06:48:51 +02:00
|
|
|
|
|
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
|
|
|
|
|
2025-05-07 06:48:53 +02:00
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2025-05-07 06:48:51 +02:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2025-05-07 06:48:53 +02:00
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2025-05-07 06:48:53 +02:00
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2025-08-08 07:40:33 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2012-10-15 15:02:01 -04:00
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2017-04-25 12:06:00 -04:00
|
|
|
|
2019-08-24 10:39:00 -04:00
|
|
|
|
|
|
|
|
|
2017-04-25 12:06:00 -04:00
|
|
|
|
|
|
|
|
|
nfs: don't ignore return value from nfs_pageio_add_request
Ignoring the return value from nfs_pageio_add_request can cause deadlocks.
In read path:
call nfs_pageio_add_request from readpage_async_filler
assume at this point that there are requests already in desc, that
can't be merged with the current request.
so nfs_pageio_doio is fired up to clear out desc.
assume something goes wrong in setting up the io, so desc->pg_error is set.
This causes nfs_pageio_add_request to return 0, *WITHOUT* adding the original
request.
BUT, since return code is ignored, readpage_async_filler assumes it has
been added, and does nothing further, leaving page locked.
do_generic_mapping_read will eventually call lock_page, resulting in deadlock
In write path:
page is marked dirty by generic_perform_write
nfs_writepages is called
call nfs_pageio_add_request from nfs_page_async_flush
assume at this point that there are requests already in desc, that
can't be merged with the current request.
so nfs_pageio_doio is fired up to clear out desc.
assume something goes wrong in setting up the io, so desc->pg_error is set.
This causes nfs_page_async_flush to return 0, *WITHOUT* adding the original
request, yet marking the request as locked (PG_BUSY) and in writeback,
clearing dirty marks.
The next time a write is done to the page, deadlock will result as
nfs_write_end calls nfs_update_request
Signed-off-by: Fred Isaman <iisaman@citi.umich.edu>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2008-03-19 11:24:39 -04:00
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2015-12-05 15:57:31 +08:00
|
|
|
|
2017-04-26 12:26:22 -04:00
|
|
|
|
2015-12-05 15:57:31 +08:00
|
|
|
|
2022-05-14 10:08:12 -04:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2015-12-05 16:20:43 +08:00
|
|
|
|
2019-08-24 10:39:00 -04:00
|
|
|
|
2025-05-07 06:48:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-25 12:06:00 -04:00
|
|
|
|
2019-04-07 13:59:05 -04:00
|
|
|
|
2019-04-07 13:59:02 -04:00
|
|
|
|
2006-12-05 00:35:41 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2017-04-26 12:26:22 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-07-22 19:27:32 -04:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2006-12-05 00:35:41 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-10-01 11:36:38 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-24 10:39:00 -04:00
|
|
|
|
2007-07-22 19:27:32 -04:00
|
|
|
|
2022-05-14 10:27:04 -04:00
|
|
|
|
2006-12-05 00:35:41 -05:00
|
|
|
|
|
|
|
|
|
2017-06-20 19:35:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-02 19:29:52 -04:00
|
|
|
|
2021-02-12 16:49:48 -05:00
|
|
|
|
|
|
|
|
|
2024-07-01 12:50:48 +02:00
|
|
|
|
2021-02-12 16:49:48 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2025-08-08 07:40:34 -04:00
|
|
|
|
|
|
|
|
|
2024-07-01 12:50:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-08 07:40:34 -04:00
|
|
|
|
2024-07-01 12:50:48 +02:00
|
|
|
|
2022-03-22 14:39:01 -07:00
|
|
|
|
2006-03-20 13:44:14 -05:00
|
|
|
|
|
|
|
|
|
2021-02-12 16:49:48 -05:00
|
|
|
|
2025-06-10 07:49:42 +02:00
|
|
|
|
2021-02-12 16:49:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-20 19:35:37 -04:00
|
|
|
|
2022-05-14 10:08:12 -04:00
|
|
|
|
2025-05-07 06:48:54 +02:00
|
|
|
|
|
|
|
|
|
2022-05-14 10:08:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-05-07 06:48:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-14 10:08:12 -04:00
|
|
|
|
|
|
|
|
|
2023-09-09 19:16:53 -04:00
|
|
|
|
|
|
|
|
|
2022-05-14 10:08:12 -04:00
|
|
|
|
2017-06-20 19:35:37 -04:00
|
|
|
|
2009-03-11 14:10:30 -04:00
|
|
|
|
2025-08-08 07:40:34 -04:00
|
|
|
|
|
|
|
|
|
2009-03-11 14:10:30 -04:00
|
|
|
|
2025-08-08 07:40:34 -04:00
|
|
|
|
2009-03-11 14:10:30 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
2014-05-15 11:56:45 -04:00
|
|
|
|
|
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
2012-05-09 13:19:15 -04:00
|
|
|
|
2023-11-17 21:58:23 +00:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2024-11-04 21:01:43 -05:00
|
|
|
|
|
|
|
|
|
2023-11-17 21:58:23 +00:00
|
|
|
|
2017-08-01 15:39:46 -04:00
|
|
|
|
2014-07-11 10:20:45 -04:00
|
|
|
|
2014-11-12 12:08:00 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-11 10:20:45 -04:00
|
|
|
|
2007-06-17 13:26:38 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-16 13:38:26 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-11 10:43:26 -04:00
|
|
|
|
|
|
|
|
|
2025-08-16 07:25:20 -07:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2014-05-15 11:56:47 -04:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2026-07-02 09:50:14 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-04 21:01:43 -05:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2026-07-02 09:50:14 +08:00
|
|
|
|
2025-09-06 12:48:16 -04:00
|
|
|
|
2026-07-02 09:50:14 +08:00
|
|
|
|
|
|
|
|
|
2012-07-31 16:45:10 -07:00
|
|
|
|
2025-08-16 07:25:20 -07:00
|
|
|
|
2014-07-11 10:20:45 -04:00
|
|
|
|
2019-09-26 14:29:38 +08:00
|
|
|
|
2023-10-11 10:43:26 -04:00
|
|
|
|
2023-09-19 09:17:28 -04:00
|
|
|
|
2019-09-26 14:29:38 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2006-12-05 00:35:42 -05:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-05 00:35:42 -05:00
|
|
|
|
|
|
|
|
|
2015-07-31 16:24:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 11:53:49 -04:00
|
|
|
|
|
|
|
|
|
2015-07-31 16:24:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 17:04:12 -04:00
|
|
|
|
2015-07-31 16:24:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-15 16:54:15 -05:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
2017-08-01 11:53:49 -04:00
|
|
|
|
2016-01-15 16:54:15 -05:00
|
|
|
|
2017-08-01 11:53:49 -04:00
|
|
|
|
2026-07-07 11:07:16 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
|
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 17:04:12 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-01 13:45:09 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:55 -04:00
|
|
|
|
2012-04-20 14:47:54 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
|
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:57 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2014-09-05 18:20:21 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-05 18:20:21 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
2016-01-15 16:54:15 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-20 16:12:34 -04:00
|
|
|
|
2026-07-07 11:07:16 -04:00
|
|
|
|
2012-03-08 17:29:35 -05:00
|
|
|
|
2026-07-07 11:07:16 -04:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2026-07-07 11:07:16 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
2026-02-13 11:16:34 +05:30
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2012-03-08 17:29:35 -05:00
|
|
|
|
|
|
|
|
|
2017-07-17 10:34:21 -04:00
|
|
|
|
2023-09-04 12:34:40 -04:00
|
|
|
|
|
|
|
|
|
2008-06-13 13:25:22 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
2019-04-07 13:59:11 -04:00
|
|
|
|
|
|
|
|
|
2008-06-13 13:25:22 -04:00
|
|
|
|
2017-08-01 11:53:49 -04:00
|
|
|
|
2023-09-04 12:34:40 -04:00
|
|
|
|
|
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
2017-08-01 11:53:49 -04:00
|
|
|
|
2026-07-07 11:07:16 -04:00
|
|
|
|
2008-06-13 13:25:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-09 11:48:35 -04:00
|
|
|
|
2007-04-20 16:12:34 -04:00
|
|
|
|
2014-06-09 11:48:36 -04:00
|
|
|
|
2014-06-09 11:48:35 -04:00
|
|
|
|
2014-06-09 11:48:36 -04:00
|
|
|
|
2007-04-20 16:12:34 -04:00
|
|
|
|
|
|
|
|
|
2017-06-20 19:35:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:48 -04:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-09 12:50:28 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
|
|
|
|
|
2014-06-09 11:48:36 -04:00
|
|
|
|
2026-04-13 18:24:23 -04:00
|
|
|
|
NFS: write_completion: dereference loop-local req, not hdr->req
5d3869a41f36 ("NFS: fix writeback in presence of errors") introduced
a dereference of hdr->req->wb_lock_context in nfs_write_completion's
per-request loop. hdr->req is set once at nfs_pgheader_init() time
and is not refcount-protected for the lifetime of the loop; when hdr
aggregates requests from multiple page groups (common under heavy
NFSv3 writeback), a parallel COMMIT on hdr->req's group can drop the
last reference and free it while the outer loop is still iterating
requests from other groups. KASAN catches this as an 8-byte read at
offset +24 of a freed nfs_page slab object (wb_lock_context).
All requests in a given pgio share the same open_context, so reading
the loop-local req's wb_lock_context yields the same value and is
safe -- req is still on hdr->pages and holds its writeback kref
through the commit branch.
Caught with kasan:
BUG: KASAN: slab-use-after-free in nfs_write_completion+0x8f8/0xa50 [nfs]
Read of size 8 at addr ffff888118af2058 by task kworker/u16:16/122062
CPU: 2 UID: 0 PID: 122062 Comm: kworker/u16:16 Kdump: loaded Not tainted 7.1.0-rc4+ #ge05a759574b2 PREEMPT
Workqueue: nfsiod rpc_async_release
Call Trace:
<TASK>
dump_stack_lvl+0xaf/0x100
? nfs_write_completion+0x8f8/0xa50 [nfs]
print_report+0x157/0x4a1
? __virt_addr_valid+0x1fb/0x400
? nfs_write_completion+0x8f8/0xa50 [nfs]
kasan_report+0xc2/0x190
? nfs_write_completion+0x8f8/0xa50 [nfs]
nfs_write_completion+0x8f8/0xa50 [nfs]
? nfs_commit_release_pages+0xbd0/0xbd0 [nfs]
? lock_acquire+0x182/0x2e0
? process_one_work+0x937/0x1890
? nfs_pgio_header_alloc+0xd0/0xd0 [nfs]
rpc_free_task+0xee/0x160
rpc_async_release+0x5d/0xb0
process_one_work+0x9b0/0x1890
? pwq_dec_nr_in_flight+0xed0/0xed0
? rpc_final_put_task+0x140/0x140
worker_thread+0x75a/0x10a0
? process_one_work+0x1890/0x1890
? kthread+0x1af/0x4d0
? process_one_work+0x1890/0x1890
kthread+0x3d3/0x4d0
? kthread_affine_node+0x2c0/0x2c0
ret_from_fork+0x669/0xa50
? native_tss_update_io_bitmap+0x660/0x660
? __switch_to+0x9dd/0x1310
? kthread_affine_node+0x2c0/0x2c0
ret_from_fork_asm+0x11/0x20
</TASK>
Allocated by task 121997 on cpu 3 at 31643.290294s:
kasan_save_stack+0x1e/0x40
kasan_save_track+0x13/0x60
__kasan_slab_alloc+0x62/0x70
kmem_cache_alloc_noprof+0x1ab/0x4e0
nfs_page_create+0x152/0x460 [nfs]
nfs_page_create_from_folio+0x7e/0x210 [nfs]
nfs_update_folio+0x7a9/0x32a0 [nfs]
nfs_write_end+0x290/0xc60 [nfs]
generic_perform_write+0x4ce/0x990
nfs_file_write+0x6b3/0xce0 [nfs]
vfs_write+0x63c/0xfa0
ksys_write+0x122/0x240
do_syscall_64+0xc3/0x13f0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
Freed by task 122046 on cpu 0 at 31647.037964s:
kasan_save_stack+0x1e/0x40
kasan_save_track+0x13/0x60
kasan_save_free_info+0x37/0x60
__kasan_slab_free+0x3b/0x60
kmem_cache_free+0x11b/0x5a0
nfs_page_group_destroy+0x13a/0x210 [nfs]
nfs_unlock_and_release_request+0x64/0x90 [nfs]
nfs_commit_release_pages+0x339/0xbd0 [nfs]
nfs_commit_release+0x51/0xb0 [nfs]
rpc_free_task+0xee/0x160
rpc_async_release+0x5d/0xb0
process_one_work+0x9b0/0x1890
worker_thread+0x75a/0x10a0
kthread+0x3d3/0x4d0
ret_from_fork+0x669/0xa50
ret_from_fork_asm+0x11/0x20
The buggy address belongs to the object at ffff888118af2040\x0a which belongs to the cache nfs_page of size 96
The buggy address is located 24 bytes inside of\x0a freed 96-byte region [ffff888118af2040, ffff888118af20a0)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x118af2
head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x4000000000000040(head|zone=2)
page_type: f5(slab)
raw: 4000000000000040 ffff88818cf2c4c0 ffffea000e61b990 ffffea0004e7d110
raw: 0000000000000000 0000000800190019 00000000f5000000 0000000000000000
head: 4000000000000040 ffff88818cf2c4c0 ffffea000e61b990 ffffea0004e7d110
head: 0000000000000000 0000000800190019 00000000f5000000 0000000000000000
head: 4000000000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000002
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 1, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 121997, tgid 121997 (rsync), ts 31643290274577, free_ts 31642154777182
post_alloc_hook+0xd1/0x100
get_page_from_freelist+0xbad/0x2910
__alloc_frozen_pages_noprof+0x1c6/0x4a0
allocate_slab+0x330/0x620
___slab_alloc+0xe9/0x930
kmem_cache_alloc_noprof+0x35b/0x4e0
nfs_page_create+0x152/0x460 [nfs]
nfs_page_create_from_folio+0x7e/0x210 [nfs]
nfs_update_folio+0x7a9/0x32a0 [nfs]
nfs_write_end+0x290/0xc60 [nfs]
generic_perform_write+0x4ce/0x990
nfs_file_write+0x6b3/0xce0 [nfs]
vfs_write+0x63c/0xfa0
ksys_write+0x122/0x240
do_syscall_64+0xc3/0x13f0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
page last free pid 122202 tgid 122202 stack trace:
__free_frozen_pages+0x6da/0xf30
qlist_free_all+0x53/0x130
kasan_quarantine_reduce+0x198/0x1f0
__kasan_slab_alloc+0x46/0x70
kmem_cache_alloc_noprof+0x1ab/0x4e0
__alloc_object+0x2f/0x230
__create_object+0x22/0x80
kmem_cache_alloc_node_noprof+0x416/0x4d0
__alloc_skb+0x146/0x6e0
tcp_stream_alloc_skb+0x35/0x660
tcp_sendmsg_locked+0x1746/0x4260
tcp_sendmsg+0x2f/0x40
inet_sendmsg+0x9e/0xe0
__sock_sendmsg+0xd9/0x180
sock_sendmsg+0x122/0x200
xprt_sock_sendmsg+0x4ff/0x9a0
Memory state around the buggy address:
ffff888118af1f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
ffff888118af1f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888118af2000: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
^
ffff888118af2080: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
ffff888118af2100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Reviewed-by Jeff Layton <jlayton@kernel.org>
Fixes: 5d3869a41f36 ("NFS: fix writeback in presence of errors")
Cc: Olga Kornievskaia <okorniev@redhat.com>
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: Anna Schumaker <anna@kernel.org>
Cc: linux-nfs@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2026-05-18 14:46:28 -04:00
|
|
|
|
2026-04-13 18:24:23 -04:00
|
|
|
|
2019-04-07 13:59:08 -04:00
|
|
|
|
|
|
|
|
|
2014-05-06 09:12:28 -04:00
|
|
|
|
2026-04-13 18:24:23 -04:00
|
|
|
|
2014-09-05 18:20:21 -04:00
|
|
|
|
2025-09-24 16:20:43 +00:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2012-05-09 14:30:35 -04:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
|
|
|
|
|
2017-06-20 19:35:37 -04:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-06 09:12:34 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2009-03-11 14:10:29 -04:00
|
|
|
|
2017-08-01 17:04:12 -04:00
|
|
|
|
2009-03-11 14:10:29 -04:00
|
|
|
|
|
|
|
|
|
2017-08-01 11:53:49 -04:00
|
|
|
|
2012-04-20 14:47:57 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
|
|
|
|
|
2012-03-08 17:29:35 -05:00
|
|
|
|
2017-09-09 12:28:01 -04:00
|
|
|
|
2012-03-08 17:29:35 -05:00
|
|
|
|
|
|
|
|
|
2017-09-09 12:28:01 -04:00
|
|
|
|
2012-05-09 13:19:15 -04:00
|
|
|
|
2017-08-01 17:29:29 -04:00
|
|
|
|
|
|
|
|
|
2021-10-04 15:44:16 -04:00
|
|
|
|
2017-08-01 17:29:29 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2017-09-09 12:40:38 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:57 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
2017-08-01 11:53:49 -04:00
|
|
|
|
2012-03-08 17:29:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-09 12:40:38 -04:00
|
|
|
|
2012-03-08 17:29:35 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:57 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-03-08 17:29:35 -05:00
|
|
|
|
2009-03-11 14:10:29 -04:00
|
|
|
|
2017-08-01 17:04:12 -04:00
|
|
|
|
|
|
|
|
|
2017-08-01 11:53:49 -04:00
|
|
|
|
2017-08-01 17:04:12 -04:00
|
|
|
|
2012-03-15 17:16:40 -04:00
|
|
|
|
2012-03-08 17:29:35 -05:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-08 17:29:35 -05:00
|
|
|
|
2017-08-01 11:53:49 -04:00
|
|
|
|
2010-02-19 16:53:39 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-03-08 17:29:35 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-08 07:40:32 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2017-07-17 19:50:23 -04:00
|
|
|
|
2025-08-08 07:40:32 -04:00
|
|
|
|
2006-12-05 00:35:35 -05:00
|
|
|
|
2017-07-17 19:50:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
|
|
|
|
|
2019-04-07 13:59:08 -04:00
|
|
|
|
2025-08-08 07:40:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
|
|
|
|
|
2017-07-17 19:50:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2025-08-08 07:40:32 -04:00
|
|
|
|
2017-07-17 19:50:23 -04:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2008-06-10 18:31:00 -04:00
|
|
|
|
2007-10-18 17:08:05 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
|
|
|
|
|
2025-08-08 07:40:33 -04:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2014-05-15 11:56:48 -04:00
|
|
|
|
2010-04-09 19:07:08 -04:00
|
|
|
|
2012-05-09 14:04:55 -04:00
|
|
|
|
2008-06-13 12:12:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-08-10 17:44:32 -04:00
|
|
|
|
2012-08-13 18:54:45 -04:00
|
|
|
|
2022-11-16 09:55:36 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-12-05 00:35:40 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-05 00:35:40 -05:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2006-12-05 00:35:40 -05:00
|
|
|
|
|
|
|
|
|
2012-08-13 18:54:45 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-13 15:26:47 +11:00
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-12-05 00:35:40 -05:00
|
|
|
|
|
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2006-12-05 00:35:40 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-08-14 11:59:16 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-03 11:30:30 +11:00
|
|
|
|
2021-07-10 18:07:14 -04:00
|
|
|
|
2018-12-03 11:30:30 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-14 11:59:16 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sunrpc: move NO_CRKEY_TIMEOUT to the auth->au_flags
A generic_cred can be used to look up a unx_cred or a gss_cred, so it's
not really safe to use the the generic_cred->acred->ac_flags to store
the NO_CRKEY_TIMEOUT flag. A lookup for a unx_cred triggered while the
KEY_EXPIRE_SOON flag is already set will cause both NO_CRKEY_TIMEOUT and
KEY_EXPIRE_SOON to be set in the ac_flags, leaving the user associated
with the auth_cred to be in a state where they're perpetually doing 4K
NFS_FILE_SYNC writes.
This can be reproduced as follows:
1. Mount two NFS filesystems, one with sec=krb5 and one with sec=sys.
They do not need to be the same export, nor do they even need to be from
the same NFS server. Also, v3 is fine.
$ sudo mount -o v3,sec=krb5 server1:/export /mnt/krb5
$ sudo mount -o v3,sec=sys server2:/export /mnt/sys
2. As the normal user, before accessing the kerberized mount, kinit with
a short lifetime (but not so short that renewing the ticket would leave
you within the 4-minute window again by the time the original ticket
expires), e.g.
$ kinit -l 10m -r 60m
3. Do some I/O to the kerberized mount and verify that the writes are
wsize, UNSTABLE:
$ dd if=/dev/zero of=/mnt/krb5/file bs=1M count=1
4. Wait until you're within 4 minutes of key expiry, then do some more
I/O to the kerberized mount to ensure that RPC_CRED_KEY_EXPIRE_SOON gets
set. Verify that the writes are 4K, FILE_SYNC:
$ dd if=/dev/zero of=/mnt/krb5/file bs=1M count=1
5. Now do some I/O to the sec=sys mount. This will cause
RPC_CRED_NO_CRKEY_TIMEOUT to be set:
$ dd if=/dev/zero of=/mnt/sys/file bs=1M count=1
6. Writes for that user will now be permanently 4K, FILE_SYNC for that
user, regardless of which mount is being written to, until you reboot
the client. Renewing the kerberos ticket (assuming it hasn't already
expired) will have no effect. Grabbing a new kerberos ticket at this
point will have no effect either.
Move the flag to the auth->au_flags field (which is currently unused)
and rename it slightly to reflect that it's no longer associated with
the auth_cred->ac_flags. Add the rpc_auth to the arg list of
rpcauth_cred_key_to_expire and check the au_flags there too. Finally,
add the inode to the arg list of nfs_ctx_key_to_expire so we can
determine the rpc_auth to pass to rpcauth_cred_key_to_expire.
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2016-06-07 15:14:48 -04:00
|
|
|
|
2013-08-14 11:59:16 -04:00
|
|
|
|
sunrpc: move NO_CRKEY_TIMEOUT to the auth->au_flags
A generic_cred can be used to look up a unx_cred or a gss_cred, so it's
not really safe to use the the generic_cred->acred->ac_flags to store
the NO_CRKEY_TIMEOUT flag. A lookup for a unx_cred triggered while the
KEY_EXPIRE_SOON flag is already set will cause both NO_CRKEY_TIMEOUT and
KEY_EXPIRE_SOON to be set in the ac_flags, leaving the user associated
with the auth_cred to be in a state where they're perpetually doing 4K
NFS_FILE_SYNC writes.
This can be reproduced as follows:
1. Mount two NFS filesystems, one with sec=krb5 and one with sec=sys.
They do not need to be the same export, nor do they even need to be from
the same NFS server. Also, v3 is fine.
$ sudo mount -o v3,sec=krb5 server1:/export /mnt/krb5
$ sudo mount -o v3,sec=sys server2:/export /mnt/sys
2. As the normal user, before accessing the kerberized mount, kinit with
a short lifetime (but not so short that renewing the ticket would leave
you within the 4-minute window again by the time the original ticket
expires), e.g.
$ kinit -l 10m -r 60m
3. Do some I/O to the kerberized mount and verify that the writes are
wsize, UNSTABLE:
$ dd if=/dev/zero of=/mnt/krb5/file bs=1M count=1
4. Wait until you're within 4 minutes of key expiry, then do some more
I/O to the kerberized mount to ensure that RPC_CRED_KEY_EXPIRE_SOON gets
set. Verify that the writes are 4K, FILE_SYNC:
$ dd if=/dev/zero of=/mnt/krb5/file bs=1M count=1
5. Now do some I/O to the sec=sys mount. This will cause
RPC_CRED_NO_CRKEY_TIMEOUT to be set:
$ dd if=/dev/zero of=/mnt/sys/file bs=1M count=1
6. Writes for that user will now be permanently 4K, FILE_SYNC for that
user, regardless of which mount is being written to, until you reboot
the client. Renewing the kerberos ticket (assuming it hasn't already
expired) will have no effect. Grabbing a new kerberos ticket at this
point will have no effect either.
Move the flag to the auth->au_flags field (which is currently unused)
and rename it slightly to reflect that it's no longer associated with
the auth_cred->ac_flags. Add the rpc_auth to the arg list of
rpcauth_cred_key_to_expire and check the au_flags there too. Finally,
add the inode to the arg list of nfs_ctx_key_to_expire so we can
determine the rpc_auth to pass to rpcauth_cred_key_to_expire.
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2016-06-07 15:14:48 -04:00
|
|
|
|
2021-07-10 18:07:14 -04:00
|
|
|
|
2018-12-03 11:30:30 +11:00
|
|
|
|
2018-12-03 11:30:31 +11:00
|
|
|
|
2018-12-03 11:30:30 +11:00
|
|
|
|
2021-07-10 18:07:14 -04:00
|
|
|
|
sunrpc: move NO_CRKEY_TIMEOUT to the auth->au_flags
A generic_cred can be used to look up a unx_cred or a gss_cred, so it's
not really safe to use the the generic_cred->acred->ac_flags to store
the NO_CRKEY_TIMEOUT flag. A lookup for a unx_cred triggered while the
KEY_EXPIRE_SOON flag is already set will cause both NO_CRKEY_TIMEOUT and
KEY_EXPIRE_SOON to be set in the ac_flags, leaving the user associated
with the auth_cred to be in a state where they're perpetually doing 4K
NFS_FILE_SYNC writes.
This can be reproduced as follows:
1. Mount two NFS filesystems, one with sec=krb5 and one with sec=sys.
They do not need to be the same export, nor do they even need to be from
the same NFS server. Also, v3 is fine.
$ sudo mount -o v3,sec=krb5 server1:/export /mnt/krb5
$ sudo mount -o v3,sec=sys server2:/export /mnt/sys
2. As the normal user, before accessing the kerberized mount, kinit with
a short lifetime (but not so short that renewing the ticket would leave
you within the 4-minute window again by the time the original ticket
expires), e.g.
$ kinit -l 10m -r 60m
3. Do some I/O to the kerberized mount and verify that the writes are
wsize, UNSTABLE:
$ dd if=/dev/zero of=/mnt/krb5/file bs=1M count=1
4. Wait until you're within 4 minutes of key expiry, then do some more
I/O to the kerberized mount to ensure that RPC_CRED_KEY_EXPIRE_SOON gets
set. Verify that the writes are 4K, FILE_SYNC:
$ dd if=/dev/zero of=/mnt/krb5/file bs=1M count=1
5. Now do some I/O to the sec=sys mount. This will cause
RPC_CRED_NO_CRKEY_TIMEOUT to be set:
$ dd if=/dev/zero of=/mnt/sys/file bs=1M count=1
6. Writes for that user will now be permanently 4K, FILE_SYNC for that
user, regardless of which mount is being written to, until you reboot
the client. Renewing the kerberos ticket (assuming it hasn't already
expired) will have no effect. Grabbing a new kerberos ticket at this
point will have no effect either.
Move the flag to the auth->au_flags field (which is currently unused)
and rename it slightly to reflect that it's no longer associated with
the auth_cred->ac_flags. Add the rpc_auth to the arg list of
rpcauth_cred_key_to_expire and check the au_flags there too. Finally,
add the inode to the arg list of nfs_ctx_key_to_expire so we can
determine the rpc_auth to pass to rpcauth_cred_key_to_expire.
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2016-06-07 15:14:48 -04:00
|
|
|
|
2021-07-10 18:07:14 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-03 11:30:30 +11:00
|
|
|
|
2021-07-10 18:07:14 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-14 11:59:16 -04:00
|
|
|
|
|
|
|
|
|
NFS: Fix a potential file corruption issue when writing
If the inode is flagged as having an invalid mapping, then we can't rely on
the PageUptodate() flag. Ensure that we don't use the "anti-fragmentation"
write optimisation in nfs_updatepage(), since that will cause NFS to write
out areas of the page that are no longer guaranteed to be up to date.
A potential corruption could occur in the following scenario:
client 1 client 2
=============== ===============
fd=open("f",O_CREAT|O_WRONLY,0644);
write(fd,"fubar\n",6); // cache last page
close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"foo\n",4);
close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"bar\n",4);
close(fd);
-----
The bug may lead to the file "f" reading 'fubar\n\0\0\0\nbar\n' because
client 2 does not update the cached page after re-opening the file for
write. Instead it keeps it marked as PageUptodate() until someone calls
invaldate_inode_pages2() (typically by calling read()).
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2008-02-07 17:24:07 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
NFS: Fix a potential file corruption issue when writing
If the inode is flagged as having an invalid mapping, then we can't rely on
the PageUptodate() flag. Ensure that we don't use the "anti-fragmentation"
write optimisation in nfs_updatepage(), since that will cause NFS to write
out areas of the page that are no longer guaranteed to be up to date.
A potential corruption could occur in the following scenario:
client 1 client 2
=============== ===============
fd=open("f",O_CREAT|O_WRONLY,0644);
write(fd,"fubar\n",6); // cache last page
close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"foo\n",4);
close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"bar\n",4);
close(fd);
-----
The bug may lead to the file "f" reading 'fubar\n\0\0\0\nbar\n' because
client 2 does not update the cached page after re-opening the file for
write. Instead it keeps it marked as PageUptodate() until someone calls
invaldate_inode_pages2() (typically by calling read()).
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2008-02-07 17:24:07 -05:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
NFS: fix the handling of NFS_INO_INVALID_DATA flag in nfs_revalidate_mapping
There is a possible race in how the nfs_invalidate_mapping function is
handled. Currently, we go and invalidate the pages in the file and then
clear NFS_INO_INVALID_DATA.
The problem is that it's possible for a stale page to creep into the
mapping after the page was invalidated (i.e., via readahead). If another
writer comes along and sets the flag after that happens but before
invalidate_inode_pages2 returns then we could clear the flag
without the cache having been properly invalidated.
So, we must clear the flag first and then invalidate the pages. Doing
this however, opens another race:
It's possible to have two concurrent read() calls that end up in
nfs_revalidate_mapping at the same time. The first one clears the
NFS_INO_INVALID_DATA flag and then goes to call nfs_invalidate_mapping.
Just before calling that though, the other task races in, checks the
flag and finds it cleared. At that point, it trusts that the mapping is
good and gets the lock on the page, allowing the read() to be satisfied
from the cache even though the data is no longer valid.
These effects are easily manifested by running diotest3 from the LTP
test suite on NFS. That program does a series of DIO writes and buffered
reads. The operations are serialized and page-aligned but the existing
code fails the test since it occasionally allows a read to come out of
the cache incorrectly. While mixing direct and buffered I/O isn't
recommended, I believe it's possible to hit this in other ways that just
use buffered I/O, though that situation is much harder to reproduce.
The problem is that the checking/clearing of that flag and the
invalidation of the mapping really need to be atomic. Fix this by
serializing concurrent invalidations with a bitlock.
At the same time, we also need to allow other places that check
NFS_INO_INVALID_DATA to check whether we might be in the middle of
invalidating the file, so fix up a couple of places that do that
to look for the new NFS_INO_INVALIDATING flag.
Doing this requires us to be careful not to set the bitlock
unnecessarily, so this code only does that if it believes it will
be doing an invalidation.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2014-01-27 13:46:15 -05:00
|
|
|
|
|
|
|
|
|
2012-04-29 12:50:01 -04:00
|
|
|
|
|
|
|
|
|
2021-02-08 08:55:46 -05:00
|
|
|
|
2021-03-25 21:07:21 -04:00
|
|
|
|
NFS: fix the handling of NFS_INO_INVALID_DATA flag in nfs_revalidate_mapping
There is a possible race in how the nfs_invalidate_mapping function is
handled. Currently, we go and invalidate the pages in the file and then
clear NFS_INO_INVALID_DATA.
The problem is that it's possible for a stale page to creep into the
mapping after the page was invalidated (i.e., via readahead). If another
writer comes along and sets the flag after that happens but before
invalidate_inode_pages2 returns then we could clear the flag
without the cache having been properly invalidated.
So, we must clear the flag first and then invalidate the pages. Doing
this however, opens another race:
It's possible to have two concurrent read() calls that end up in
nfs_revalidate_mapping at the same time. The first one clears the
NFS_INO_INVALID_DATA flag and then goes to call nfs_invalidate_mapping.
Just before calling that though, the other task races in, checks the
flag and finds it cleared. At that point, it trusts that the mapping is
good and gets the lock on the page, allowing the read() to be satisfied
from the cache even though the data is no longer valid.
These effects are easily manifested by running diotest3 from the LTP
test suite on NFS. That program does a series of DIO writes and buffered
reads. The operations are serialized and page-aligned but the existing
code fails the test since it occasionally allows a read to come out of
the cache incorrectly. While mixing direct and buffered I/O isn't
recommended, I believe it's possible to hit this in other ways that just
use buffered I/O, though that situation is much harder to reproduce.
The problem is that the checking/clearing of that flag and the
invalidation of the mapping really need to be atomic. Fix this by
serializing concurrent invalidations with a bitlock.
At the same time, we also need to allow other places that check
NFS_INO_INVALID_DATA to check whether we might be in the middle of
invalidating the file, so fix up a couple of places that do that
to look for the new NFS_INO_INVALIDATING flag.
Doing this requires us to be careful not to set the bitlock
unnecessarily, so this code only does that if it believes it will
be doing an invalidation.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2014-01-27 13:46:15 -05:00
|
|
|
|
2014-01-28 13:47:46 -05:00
|
|
|
|
2021-02-08 08:55:46 -05:00
|
|
|
|
2012-04-29 12:50:01 -04:00
|
|
|
|
|
|
|
|
|
2021-02-08 08:55:46 -05:00
|
|
|
|
2014-06-20 08:44:42 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
NFS: Fix a potential file corruption issue when writing
If the inode is flagged as having an invalid mapping, then we can't rely on
the PageUptodate() flag. Ensure that we don't use the "anti-fragmentation"
write optimisation in nfs_updatepage(), since that will cause NFS to write
out areas of the page that are no longer guaranteed to be up to date.
A potential corruption could occur in the following scenario:
client 1 client 2
=============== ===============
fd=open("f",O_CREAT|O_WRONLY,0644);
write(fd,"fubar\n",6); // cache last page
close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"foo\n",4);
close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"bar\n",4);
close(fd);
-----
The bug may lead to the file "f" reading 'fubar\n\0\0\0\nbar\n' because
client 2 does not update the cached page after re-opening the file for
write. Instead it keeps it marked as PageUptodate() until someone calls
invaldate_inode_pages2() (typically by calling read()).
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2008-02-07 17:24:07 -05:00
|
|
|
|
|
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-31 18:01:52 -05:00
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
|
|
|
|
|
2013-07-05 17:33:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-17 15:12:05 -05:00
|
|
|
|
|
|
|
|
|
2013-07-05 17:33:19 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
2013-07-05 17:33:19 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2022-11-16 09:55:36 -05:00
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2024-07-24 14:07:12 +03:00
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
2024-07-24 14:07:12 +03:00
|
|
|
|
|
|
|
|
|
2013-07-05 17:33:19 -04:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2014-01-17 15:12:05 -05:00
|
|
|
|
2024-06-16 21:21:24 -04:00
|
|
|
|
2013-07-05 17:33:19 -04:00
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
|
|
|
|
|
2015-10-01 18:38:27 -04:00
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-16 15:05:57 -05:00
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
|
|
|
|
|
2024-01-31 18:02:22 -05:00
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
2024-01-31 18:02:22 -05:00
|
|
|
|
2024-01-31 18:01:52 -05:00
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
|
|
|
|
|
2015-01-16 15:05:57 -05:00
|
|
|
|
2015-01-16 15:05:55 -05:00
|
|
|
|
2013-07-05 17:33:19 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-08-10 17:44:32 -04:00
|
|
|
|
2024-07-01 07:26:48 +02:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-20 13:44:14 -05:00
|
|
|
|
|
|
|
|
|
2025-08-08 07:40:32 -04:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
nfs: drop usage of folio_file_pos
folio_file_pos is only needed for mixed usage of page cache and swap
cache, for pure page cache usage, the caller can just use folio_pos
instead.
After commit e1209d3a7a67 ("mm: introduce ->swap_rw and use it for reads
from SWP_FS_OPS swap-space"), swap cache should never be exposed to nfs.
So remove the usage of folio_file_pos in following NFS functions / helpers:
- nfs_vm_page_mkwrite
It's only used by nfs_file_vm_ops.page_mkwrite
- trace event helper: nfs_folio_event
- trace event helper: nfs_folio_event_done
These two are used through DEFINE_NFS_FOLIO_EVENT and
DEFINE_NFS_FOLIO_EVENT_DONE, which defined following events:
- trace_nfs_aop_readpage{_done}: only called by nfs_read_folio
- trace_nfs_writeback_folio: only called by nfs_wb_folio
- trace_nfs_invalidate_folio: only called by nfs_invalidate_folio
- trace_nfs_launder_folio_done: only called by nfs_launder_folio
None of them could possibly be used on swap cache folio,
nfs_read_folio only called by:
.write_begin -> nfs_read_folio
.read_folio
nfs_wb_folio only called by nfs mapping:
.release_folio -> nfs_wb_folio
.launder_folio -> nfs_wb_folio
.write_begin -> nfs_read_folio -> nfs_wb_folio
.read_folio -> nfs_wb_folio
.write_end -> nfs_update_folio -> nfs_writepage_setup -> nfs_setup_write_request -> nfs_try_to_update_request -> nfs_wb_folio
.page_mkwrite -> nfs_update_folio -> nfs_writepage_setup -> nfs_setup_write_request -> nfs_try_to_update_request -> nfs_wb_folio
.write_begin -> nfs_flush_incompatible -> nfs_wb_folio
.page_mkwrite -> nfs_vm_page_mkwrite -> nfs_flush_incompatible -> nfs_wb_folio
nfs_invalidate_folio is only called by .invalidate_folio.
nfs_launder_folio is only called by .launder_folio
- nfs_grow_file
- nfs_update_folio
nfs_grow_file is only called by nfs_update_folio, and all
possible callers of them are:
.write_end -> nfs_update_folio
.page_mkwrite -> nfs_update_folio
- nfs_wb_folio_cancel
.invalidate_folio -> nfs_wb_folio_cancel
Also, seeing from the swap side, swap_rw is now the only interface calling
into fs, the offset info is always in iocb.ki_pos now.
So we can remove all these folio_file_pos call safely.
Link: https://lkml.kernel.org/r/20240521175854.96038-8-ryncsn@gmail.com
Signed-off-by: Kairui Song <kasong@tencent.com>
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: Anna Schumaker <anna@kernel.org>
Cc: Barry Song <v-songbaohua@oppo.com>
Cc: Chao Yu <chao@kernel.org>
Cc: Chris Li <chrisl@kernel.org>
Cc: David Hildenbrand <david@redhat.com>
Cc: David Howells <dhowells@redhat.com>
Cc: "Huang, Ying" <ying.huang@intel.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ilya Dryomov <idryomov@gmail.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Jeff Layton <jlayton@kernel.org>
Cc: Marc Dionne <marc.dionne@auristor.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: NeilBrown <neilb@suse.de>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: Xiubo Li <xiubli@redhat.com>
Cc: Yosry Ahmed <yosryahmed@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-22 01:58:49 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-07-18 10:41:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2024-07-05 07:42:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2008-06-05 16:02:35 -04:00
|
|
|
|
2019-02-06 06:09:43 -05:00
|
|
|
|
2016-07-18 10:41:57 -04:00
|
|
|
|
2025-08-08 07:40:32 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-14 15:40:00 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-09 11:48:35 -04:00
|
|
|
|
|
|
|
|
|
2014-06-09 13:12:20 -07:00
|
|
|
|
2014-05-06 09:12:37 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-07-14 15:40:00 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-03-07 10:41:44 +11:00
|
|
|
|
|
|
|
|
|
2014-05-06 09:12:37 -04:00
|
|
|
|
2018-05-04 16:22:48 -04:00
|
|
|
|
2020-01-06 15:25:09 -05:00
|
|
|
|
2011-07-12 13:42:02 -04:00
|
|
|
|
|
|
|
|
|
2008-03-19 11:24:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:38 -05:00
|
|
|
|
2022-08-13 08:22:25 -04:00
|
|
|
|
2019-04-07 13:59:08 -04:00
|
|
|
|
|
|
|
|
|
2008-03-19 11:24:38 -04:00
|
|
|
|
2022-08-13 08:22:25 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2012-05-09 14:30:35 -04:00
|
|
|
|
2008-03-19 11:24:38 -04:00
|
|
|
|
|
|
|
|
|
2019-02-13 10:39:39 -05:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-14 10:27:00 -04:00
|
|
|
|
2019-04-07 13:59:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-31 11:44:06 -05:00
|
|
|
|
|
|
|
|
|
2019-02-13 10:39:39 -05:00
|
|
|
|
2015-12-31 11:44:06 -05:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:48 -04:00
|
|
|
|
2017-06-20 19:35:37 -04:00
|
|
|
|
2012-04-20 14:47:48 -04:00
|
|
|
|
|
|
|
|
|
2015-12-31 11:44:06 -05:00
|
|
|
|
2012-04-20 14:47:48 -04:00
|
|
|
|
|
|
|
|
|
2012-06-20 15:53:48 -04:00
|
|
|
|
2014-04-16 15:07:21 +02:00
|
|
|
|
2012-04-20 14:47:48 -04:00
|
|
|
|
2011-06-10 13:30:23 -04:00
|
|
|
|
2014-04-16 15:07:21 +02:00
|
|
|
|
2014-05-06 09:12:40 -04:00
|
|
|
|
2014-04-16 15:07:21 +02:00
|
|
|
|
2025-12-04 15:44:33 -05:00
|
|
|
|
2014-04-16 15:07:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-06 09:12:30 -04:00
|
|
|
|
2017-08-20 11:33:25 -04:00
|
|
|
|
2011-06-10 13:30:23 -04:00
|
|
|
|
2012-07-30 16:05:23 -04:00
|
|
|
|
2011-06-10 13:30:23 -04:00
|
|
|
|
2011-07-13 15:59:19 -04:00
|
|
|
|
|
|
|
|
|
2014-09-19 10:55:07 -04:00
|
|
|
|
|
|
|
|
|
2015-09-20 23:03:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-06 09:12:40 -04:00
|
|
|
|
2014-09-19 10:55:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-13 15:59:19 -04:00
|
|
|
|
2011-07-13 15:59:57 -04:00
|
|
|
|
2011-07-13 15:59:19 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 17:36:09 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-05 20:06:38 -04:00
|
|
|
|
2015-02-26 17:36:09 -05:00
|
|
|
|
|
|
|
|
|
2015-07-05 20:06:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 17:36:09 -05:00
|
|
|
|
2015-07-05 20:06:38 -04:00
|
|
|
|
|
|
|
|
|
2015-02-26 17:36:09 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-05 20:06:38 -04:00
|
|
|
|
|
|
|
|
|
2015-02-26 17:36:09 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-05 20:06:38 -04:00
|
|
|
|
2015-02-26 17:36:09 -05:00
|
|
|
|
|
|
|
|
|
2024-06-16 21:21:25 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-26 17:36:09 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-09 11:48:35 -04:00
|
|
|
|
|
|
|
|
|
2014-05-06 09:12:32 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-20 13:44:27 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-09-20 14:33:04 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-09 11:48:35 -04:00
|
|
|
|
2006-03-20 13:44:27 -05:00
|
|
|
|
2014-05-06 09:12:32 -04:00
|
|
|
|
2017-08-21 15:00:49 -04:00
|
|
|
|
2014-06-09 11:48:35 -04:00
|
|
|
|
2020-01-06 15:25:09 -05:00
|
|
|
|
2006-03-20 13:44:14 -05:00
|
|
|
|
2022-07-22 14:12:20 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-07-22 14:12:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-04-13 11:11:31 -04:00
|
|
|
|
|
|
|
|
|
2018-03-20 16:53:31 -04:00
|
|
|
|
|
|
|
|
|
2025-10-09 16:42:12 -04:00
|
|
|
|
|
|
|
|
|
2018-03-20 16:53:31 -04:00
|
|
|
|
|
|
|
|
|
2014-05-06 09:12:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-09 11:48:35 -04:00
|
|
|
|
|
|
|
|
|
2014-05-06 09:12:32 -04:00
|
|
|
|
2014-06-09 11:48:35 -04:00
|
|
|
|
|
|
|
|
|
2014-04-13 11:11:31 -04:00
|
|
|
|
2026-02-20 16:42:18 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2026-04-13 18:24:23 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2026-04-13 18:24:23 -04:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
2014-06-09 11:48:35 -04:00
|
|
|
|
2006-03-20 13:44:14 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-06-09 11:48:35 -04:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
2011-02-11 15:42:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-10-16 17:23:29 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-09 11:48:35 -04:00
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-01-06 15:25:13 -05:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:47 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-29 20:34:05 -04:00
|
|
|
|
2010-04-22 15:35:57 -04:00
|
|
|
|
2018-03-15 11:44:34 +01:00
|
|
|
|
|
|
|
|
|
2015-09-29 20:34:05 -04:00
|
|
|
|
|
|
|
|
|
2024-03-01 11:49:57 -05:00
|
|
|
|
2015-09-29 20:34:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-04 15:37:42 -04:00
|
|
|
|
2015-09-29 20:34:05 -04:00
|
|
|
|
2021-10-04 15:37:42 -04:00
|
|
|
|
2018-03-15 11:44:34 +01:00
|
|
|
|
2021-10-04 15:37:42 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-22 15:35:57 -04:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-03-23 13:27:53 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
2014-06-09 07:10:14 +08:00
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
2024-09-05 15:09:52 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-10-25 18:42:54 -04:00
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
2007-07-14 15:40:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
2007-07-14 15:40:00 -04:00
|
|
|
|
2007-07-14 15:39:59 -04:00
|
|
|
|
2007-10-25 18:42:54 -04:00
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
2007-07-14 15:40:00 -04:00
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
2007-07-14 15:39:59 -04:00
|
|
|
|
2008-02-19 20:04:23 -05:00
|
|
|
|
2020-05-13 09:55:36 -04:00
|
|
|
|
2007-07-14 15:40:00 -04:00
|
|
|
|
2007-07-14 15:39:59 -04:00
|
|
|
|
2022-05-25 12:12:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 13:44:27 -05:00
|
|
|
|
2018-05-04 16:22:49 -04:00
|
|
|
|
2017-08-21 15:00:49 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-07-01 12:00:13 +08:00
|
|
|
|
2007-07-14 15:40:00 -04:00
|
|
|
|
2024-09-05 15:09:53 -04:00
|
|
|
|
2026-07-06 12:05:48 -04:00
|
|
|
|
2024-09-05 15:09:53 -04:00
|
|
|
|
2007-10-25 18:42:54 -04:00
|
|
|
|
2008-04-14 14:54:53 -04:00
|
|
|
|
|
|
|
|
|
nfs: close NFSv4 COMMIT vs. CLOSE race
I've been adding in more artificial delays in the NFSv4 commit and close
codepaths to uncover races. The kernel I'm testing has the patch to
close the race in __rpc_wait_for_completion_task that's in Trond's
cthon2011 branch. The reproducer I've been using does this in a loop:
mkdir("DIR");
fd = open("DIR/FILE", O_WRONLY|O_CREAT|O_EXCL, 0644);
write(fd, "abcdefg", 7);
close(fd);
unlink("DIR/FILE");
rmdir("DIR");
The above reproducer shouldn't result in any silly-renaming. However,
when I add a "msleep(100)" just after the nfs_commit_clear_lock call in
nfs_commit_release, I can almost always force one to occur. If I can
force it to occur with that, then it can happen without that delay
given the right timing.
nfs_commit_inode waits for the NFS_INO_COMMIT bit to clear when called
with FLUSH_SYNC set. nfs_commit_rpcsetup on the other hand does not wait
for the task to complete before putting its reference to it, so the last
reference get put in rpc_release task and gets queued to a workqueue.
In this situation, the last open context reference may be put by the
COMMIT release instead of the close() syscall. The close() syscall
returns too quickly and the unlink runs while the d_count is still
high since the COMMIT release hasn't put its dentry reference yet.
Fix this by having rpc_commit_rpcsetup wait for the RPC call to complete
before putting the task reference when FLUSH_SYNC is set. With this, the
last reference is put by the process that's initiating the FLUSH_SYNC
commit and the race is closed.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2011-03-06 17:14:13 +00:00
|
|
|
|
|
|
|
|
|
2008-04-14 14:54:53 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-03-23 13:27:53 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-08-07 10:15:02 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
2012-04-20 14:47:54 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
2020-03-19 17:29:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-19 17:29:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
|
|
|
|
|
2019-04-07 13:59:11 -04:00
|
|
|
|
2011-03-23 13:27:52 +00:00
|
|
|
|
2014-08-07 10:15:02 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
2012-04-20 14:47:54 -04:00
|
|
|
|
2012-04-20 14:47:55 -04:00
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-07 13:59:11 -04:00
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-04 15:37:42 -04:00
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
2011-03-23 13:27:53 +00:00
|
|
|
|
2011-03-23 13:27:45 +00:00
|
|
|
|
2011-03-23 13:27:53 +00:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2014-09-05 18:20:21 -04:00
|
|
|
|
|
|
|
|
|
2011-03-23 13:27:47 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-05 18:20:21 -04:00
|
|
|
|
2026-07-07 11:07:16 -04:00
|
|
|
|
2012-05-09 14:04:55 -04:00
|
|
|
|
2011-03-23 13:27:47 +00:00
|
|
|
|
|
|
|
|
|
2011-03-23 13:27:53 +00:00
|
|
|
|
2011-03-23 13:27:47 +00:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
2015-12-31 09:28:06 -05:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-31 09:28:06 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
2024-09-05 15:09:54 -04:00
|
|
|
|
2021-06-23 23:28:51 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-05-25 10:07:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-21 12:34:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:54 -04:00
|
|
|
|
2021-06-23 23:28:51 -04:00
|
|
|
|
|
|
|
|
|
2024-09-05 15:09:54 -04:00
|
|
|
|
|
|
|
|
|
2024-11-15 20:40:57 -05:00
|
|
|
|
|
|
|
|
|
2014-06-09 07:10:14 +08:00
|
|
|
|
2021-06-23 23:28:51 -04:00
|
|
|
|
2024-09-05 15:09:54 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 13:44:27 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-20 13:44:27 -05:00
|
|
|
|
2011-04-12 12:29:15 -04:00
|
|
|
|
2020-01-06 15:25:10 -05:00
|
|
|
|
2008-04-15 16:56:39 -04:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:54 -04:00
|
|
|
|
2008-04-15 16:56:39 -04:00
|
|
|
|
2020-01-06 15:25:04 -05:00
|
|
|
|
2011-03-23 13:27:48 +00:00
|
|
|
|
2008-04-15 16:56:39 -04:00
|
|
|
|
2012-04-20 14:47:54 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2006-03-20 13:44:27 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2026-07-07 11:07:16 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-12-17 18:20:16 +01:00
|
|
|
|
2019-04-07 13:59:11 -04:00
|
|
|
|
2026-05-12 12:12:44 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-04-15 16:56:39 -04:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2022-08-09 12:50:28 -04:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2017-03-09 11:36:36 +08:00
|
|
|
|
2019-04-07 13:59:05 -04:00
|
|
|
|
2025-08-22 09:19:22 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-21 09:27:46 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2017-03-09 11:36:36 +08:00
|
|
|
|
2025-08-22 09:19:22 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-22 09:19:22 -04:00
|
|
|
|
2008-03-19 11:24:38 -04:00
|
|
|
|
2026-04-13 18:24:23 -04:00
|
|
|
|
|
|
|
|
|
2022-08-13 08:22:25 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-05-09 14:04:55 -04:00
|
|
|
|
2017-12-18 14:39:13 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-24 11:28:32 +10:00
|
|
|
|
2012-04-20 14:47:54 -04:00
|
|
|
|
2015-09-29 20:34:05 -04:00
|
|
|
|
2011-03-23 13:27:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
2011-03-23 13:27:48 +00:00
|
|
|
|
2012-04-20 14:47:54 -04:00
|
|
|
|
2008-04-15 16:56:39 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-20 13:44:27 -05:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
2006-03-20 13:44:27 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-04-20 14:47:54 -04:00
|
|
|
|
|
|
|
|
|
2015-12-31 09:28:06 -05:00
|
|
|
|
2012-04-20 14:47:54 -04:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:57 -04:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:52 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2012-04-20 14:47:52 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2012-04-20 14:47:52 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-07 15:22:31 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2010-04-22 15:35:57 -04:00
|
|
|
|
2018-03-07 15:22:31 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-10-04 15:44:16 -04:00
|
|
|
|
2012-04-20 14:47:53 -04:00
|
|
|
|
2015-09-29 20:34:05 -04:00
|
|
|
|
2018-03-07 15:22:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-29 20:34:05 -04:00
|
|
|
|
2018-03-07 15:22:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-12-31 09:28:06 -05:00
|
|
|
|
2010-02-19 16:46:56 -08:00
|
|
|
|
2015-07-13 14:01:32 -04:00
|
|
|
|
2010-02-19 16:46:56 -08:00
|
|
|
|
2010-02-19 17:00:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-19 16:46:56 -08:00
|
|
|
|
2010-09-28 09:14:01 -04:00
|
|
|
|
2018-03-07 15:22:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-28 09:14:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-20 19:35:38 -04:00
|
|
|
|
2010-09-28 09:14:01 -04:00
|
|
|
|
2010-02-19 17:00:02 -08:00
|
|
|
|
2010-09-28 09:14:01 -04:00
|
|
|
|
2010-02-19 17:00:02 -08:00
|
|
|
|
2010-09-28 09:14:01 -04:00
|
|
|
|
|
|
|
|
|
2018-03-07 15:22:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-19 17:00:02 -08:00
|
|
|
|
2010-02-19 16:46:56 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-30 16:05:25 -04:00
|
|
|
|
2012-06-20 15:53:49 -04:00
|
|
|
|
2016-06-25 18:12:03 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-19 17:03:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-25 14:09:54 -04:00
|
|
|
|
2013-08-19 18:59:33 -04:00
|
|
|
|
2007-07-25 14:09:54 -04:00
|
|
|
|
2013-08-19 18:59:33 -04:00
|
|
|
|
|
|
|
|
|
2015-03-25 14:14:42 -04:00
|
|
|
|
2015-05-06 18:26:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-19 18:59:33 -04:00
|
|
|
|
2015-05-06 18:26:58 -04:00
|
|
|
|
2013-08-19 18:59:33 -04:00
|
|
|
|
|
|
|
|
|
2006-10-09 16:18:38 -04:00
|
|
|
|
2012-07-30 16:05:23 -04:00
|
|
|
|
2006-10-09 16:18:38 -04:00
|
|
|
|
2022-02-09 20:21:47 +00:00
|
|
|
|
2007-08-28 10:29:36 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-09 20:21:47 +00:00
|
|
|
|
2014-07-11 10:20:49 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2014-07-11 10:20:49 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-09 20:21:47 +00:00
|
|
|
|
2014-07-11 10:20:49 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-03 11:48:57 -04:00
|
|
|
|
2007-08-28 10:29:36 -04:00
|
|
|
|
2014-07-11 10:20:49 -04:00
|
|
|
|
2007-08-28 10:29:36 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-31 11:42:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:42 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-19 17:03:28 -08:00
|
|
|
|
2023-01-19 16:33:42 -05:00
|
|
|
|
2006-10-09 16:18:38 -04:00
|
|
|
|
2024-07-11 09:17:02 +02:00
|
|
|
|
|
|
|
|
|
2006-12-05 00:35:41 -05:00
|
|
|
|
|
|
|
|
|
2010-02-19 17:03:28 -08:00
|
|
|
|
2006-12-05 00:35:41 -05:00
|
|
|
|
2024-07-11 09:17:02 +02:00
|
|
|
|
2006-12-05 00:35:41 -05:00
|
|
|
|
|
|
|
|
|
2006-10-09 16:18:38 -04:00
|
|
|
|
2024-07-11 09:17:02 +02:00
|
|
|
|
2013-08-19 18:59:33 -04:00
|
|
|
|
2010-05-26 08:42:24 -04:00
|
|
|
|
2023-01-19 16:33:42 -05:00
|
|
|
|
|
|
|
|
|
2023-01-19 16:33:43 -05:00
|
|
|
|
2008-04-11 16:03:54 -04:00
|
|
|
|
|
|
|
|
|
2010-05-26 08:42:24 -04:00
|
|
|
|
2010-02-19 17:03:28 -08:00
|
|
|
|
2013-08-19 18:59:33 -04:00
|
|
|
|
2023-01-19 16:33:42 -05:00
|
|
|
|
2010-05-26 08:42:24 -04:00
|
|
|
|
|
|
|
|
|
2010-04-27 18:33:54 -04:00
|
|
|
|
2008-04-11 16:03:54 -04:00
|
|
|
|
2010-02-19 17:03:28 -08:00
|
|
|
|
2008-04-11 16:03:54 -04:00
|
|
|
|
2024-07-11 09:17:02 +02:00
|
|
|
|
2006-12-05 00:35:41 -05:00
|
|
|
|
2006-10-09 16:18:38 -04:00
|
|
|
|
|
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2022-06-06 09:22:19 -04:00
|
|
|
|
|
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2011-10-12 10:57:42 -04:00
|
|
|
|
2022-06-06 09:22:19 -04:00
|
|
|
|
2011-10-12 10:57:42 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-06 09:22:19 -04:00
|
|
|
|
2011-10-12 10:57:42 -04:00
|
|
|
|
2025-06-24 17:32:09 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2024-03-19 11:13:26 +00:00
|
|
|
|
2021-08-27 15:19:34 +01:00
|
|
|
|
|
|
|
|
|
2024-03-19 11:13:26 +00:00
|
|
|
|
2021-08-27 15:19:34 +01:00
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
2022-06-06 10:27:41 -04:00
|
|
|
|
2009-08-10 08:54:13 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NFS: Split fs/nfs/inode.c
As fs/nfs/inode.c is rather large, heterogenous and unwieldy, the attached
patch splits it up into a number of files:
(*) fs/nfs/inode.c
Strictly inode specific functions.
(*) fs/nfs/super.c
Superblock management functions for NFS and NFS4, normal access, clones
and referrals. The NFS4 superblock functions _could_ move out into a
separate conditionally compiled file, but it's probably not worth it as
there're so many common bits.
(*) fs/nfs/namespace.c
Some namespace-specific functions have been moved here.
(*) fs/nfs/nfs4namespace.c
NFS4-specific namespace functions (this could be merged into the previous
file). This file is conditionally compiled.
(*) fs/nfs/internal.h
Inter-file declarations, plus a few simple utility functions moved from
fs/nfs/inode.c.
Additionally, all the in-.c-file externs have been moved here, and those
files they were moved from now includes this file.
For the most part, the functions have not been changed, only some multiplexor
functions have changed significantly.
I've also:
(*) Added some extra banner comments above some functions.
(*) Rearranged the function order within the files to be more logical and
better grouped (IMO), though someone may prefer a different order.
(*) Reduced the number of #ifdefs in .c files.
(*) Added missing __init and __exit directives.
Signed-Off-By: David Howells <dhowells@redhat.com>
2006-06-09 09:34:33 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-06-09 11:48:33 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-07-20 10:11:58 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-26 01:37:50 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-02 14:30:56 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-02 14:30:56 -04:00
|
|
|
|
2012-04-20 14:47:39 -04:00
|
|
|
|
2006-03-26 01:37:50 -08:00
|
|
|
|
2012-11-12 09:27:37 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-02 14:30:56 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-03-16 13:38:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-28 00:34:29 -08:00
|
|
|
|
2007-03-16 13:38:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-08-02 14:30:56 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-06-27 12:59:15 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-08-02 14:30:56 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-09-27 01:49:40 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-05-06 09:12:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-06 09:12:32 -04:00
|
|
|
|
|
|
|
|
|
2014-05-06 09:12:37 -04:00
|
|
|
|
2014-05-06 09:12:30 -04:00
|
|
|
|
