2018-09-04 15:46:30 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2021-11-08 18:35:01 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:09 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-16 12:46:28 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-25 18:44:27 -05:00
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
|
|
|
|
2017-02-02 19:15:33 +01:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-16 23:44:55 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-03 03:35:12 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2016-08-02 14:05:10 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 18:35:49 -07:00
|
|
|
|
2016-05-23 16:23:42 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:45 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-14 03:32:40 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-10 10:01:48 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-02 14:05:10 -07:00
|
|
|
|
2015-11-06 16:32:02 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:32:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2015-11-06 16:32:02 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2012-06-12 16:20:44 +02:00
|
|
|
|
2010-09-20 18:19:06 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:32:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-12 16:20:44 +02:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:45 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-10 10:01:49 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:45 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:45 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2015-11-06 16:32:02 -08:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2015-11-06 16:32:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-12 16:20:44 +02:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:32:02 -08:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:45 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:45 -07:00
|
|
|
|
2015-11-06 16:32:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-12 16:20:44 +02:00
|
|
|
|
2009-04-06 19:01:45 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2022-11-04 23:29:59 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:55 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:32:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2016-08-02 14:05:19 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:32:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2015-11-06 16:32:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:39 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:39 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-10 10:01:49 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:39 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-20 20:10:38 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-18 02:35:13 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-18 02:35:13 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:39 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2016-05-23 16:23:39 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:57 -07:00
|
|
|
|
2011-02-28 13:41:11 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:57 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-20 20:10:38 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-20 20:10:38 +09:00
|
|
|
|
2024-08-27 02:41:11 +09:00
|
|
|
|
2010-08-20 20:10:38 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-20 20:10:38 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:39 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-18 02:35:13 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-19 15:26:20 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-19 15:26:20 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:55 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:22:57 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-19 15:26:20 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:55 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:22:57 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:22:57 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2023-01-04 13:14:43 -08:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-04 13:14:43 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
2023-01-04 13:14:43 -08:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-01-04 13:14:43 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-01-04 13:14:43 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-01-04 13:14:43 -08:00
|
|
|
|
2023-08-05 22:20:38 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-04 13:14:43 -08:00
|
|
|
|
2023-10-16 21:11:03 +01:00
|
|
|
|
2023-10-16 21:11:14 +01:00
|
|
|
|
2023-10-16 21:11:03 +01:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-01-04 13:14:43 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
nilfs2: fix issue with race condition of competition between segments for dirty blocks
Many NILFS2 users were reported about strange file system corruption
(for example):
NILFS: bad btree node (blocknr=185027): level = 0, flags = 0x0, nchildren = 768
NILFS error (device sda4): nilfs_bmap_last_key: broken bmap (inode number=11540)
But such error messages are consequence of file system's issue that takes
place more earlier. Fortunately, Jerome Poulin <jeromepoulin@gmail.com>
and Anton Eliasson <devel@antoneliasson.se> were reported about another
issue not so recently. These reports describe the issue with segctor
thread's crash:
BUG: unable to handle kernel paging request at 0000000000004c83
IP: nilfs_end_page_io+0x12/0xd0 [nilfs2]
Call Trace:
nilfs_segctor_do_construct+0xf25/0x1b20 [nilfs2]
nilfs_segctor_construct+0x17b/0x290 [nilfs2]
nilfs_segctor_thread+0x122/0x3b0 [nilfs2]
kthread+0xc0/0xd0
ret_from_fork+0x7c/0xb0
These two issues have one reason. This reason can raise third issue
too. Third issue results in hanging of segctor thread with eating of
100% CPU.
REPRODUCING PATH:
One of the possible way or the issue reproducing was described by
Jermoe me Poulin <jeromepoulin@gmail.com>:
1. init S to get to single user mode.
2. sysrq+E to make sure only my shell is running
3. start network-manager to get my wifi connection up
4. login as root and launch "screen"
5. cd /boot/log/nilfs which is a ext3 mount point and can log when NILFS dies.
6. lscp | xz -9e > lscp.txt.xz
7. mount my snapshot using mount -o cp=3360839,ro /dev/vgUbuntu/root /mnt/nilfs
8. start a screen to dump /proc/kmsg to text file since rsyslog is killed
9. start a screen and launch strace -f -o find-cat.log -t find
/mnt/nilfs -type f -exec cat {} > /dev/null \;
10. start a screen and launch strace -f -o apt-get.log -t apt-get update
11. launch the last command again as it did not crash the first time
12. apt-get crashes
13. ps aux > ps-aux-crashed.log
13. sysrq+W
14. sysrq+E wait for everything to terminate
15. sysrq+SUSB
Simplified way of the issue reproducing is starting kernel compilation
task and "apt-get update" in parallel.
REPRODUCIBILITY:
The issue is reproduced not stable [60% - 80%]. It is very important to
have proper environment for the issue reproducing. The critical
conditions for successful reproducing:
(1) It should have big modified file by mmap() way.
(2) This file should have the count of dirty blocks are greater that
several segments in size (for example, two or three) from time to time
during processing.
(3) It should be intensive background activity of files modification
in another thread.
INVESTIGATION:
First of all, it is possible to see that the reason of crash is not valid
page address:
NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82
NILFS [nilfs_segctor_complete_write]:2101 segbuf->sb_segnum 6783
Moreover, value of b_page (0x1a82) is 6786. This value looks like segment
number. And b_blocknr with b_size values look like block numbers. So,
buffer_head's pointer points on not proper address value.
Detailed investigation of the issue is discovered such picture:
[-----------------------------SEGMENT 6783-------------------------------]
NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111149024, segbuf->sb_segnum 6783
[-----------------------------SEGMENT 6784-------------------------------]
NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff8802174a6798, bh->b_assoc_buffers.prev ffff880221cffee8
NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6784
NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111150080, segbuf->sb_segnum 6784, segbuf->sb_nbio 0
[----------] ditto
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111164416, segbuf->sb_segnum 6784, segbuf->sb_nbio 15
[-----------------------------SEGMENT 6785-------------------------------]
NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff880219277e80, bh->b_assoc_buffers.prev ffff880221cffc88
NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6785
NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111165440, segbuf->sb_segnum 6785, segbuf->sb_nbio 0
[----------] ditto
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111177728, segbuf->sb_segnum 6785, segbuf->sb_nbio 12
NILFS [nilfs_segctor_do_construct]:2399 nilfs_segctor_wait
NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6783
NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6784
NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6785
NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82
BUG: unable to handle kernel paging request at 0000000000001a82
IP: [<ffffffffa024d0f2>] nilfs_end_page_io+0x12/0xd0 [nilfs2]
Usually, for every segment we collect dirty files in list. Then, dirty
blocks are gathered for every dirty file, prepared for write and
submitted by means of nilfs_segbuf_submit_bh() call. Finally, it takes
place complete write phase after calling nilfs_end_bio_write() on the
block layer. Buffers/pages are marked as not dirty on final phase and
processed files removed from the list of dirty files.
It is possible to see that we had three prepare_write and submit_bio
phases before segbuf_wait and complete_write phase. Moreover, segments
compete between each other for dirty blocks because on every iteration
of segments processing dirty buffer_heads are added in several lists of
payload_buffers:
[SEGMENT 6784]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
[SEGMENT 6785]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8
The next pointer is the same but prev pointer has changed. It means
that buffer_head has next pointer from one list but prev pointer from
another. Such modification can be made several times. And, finally, it
can be resulted in various issues: (1) segctor hanging, (2) segctor
crashing, (3) file system metadata corruption.
FIX:
This patch adds:
(1) setting of BH_Async_Write flag in nilfs_segctor_prepare_write()
for every proccessed dirty block;
(2) checking of BH_Async_Write flag in
nilfs_lookup_dirty_data_buffers() and
nilfs_lookup_dirty_node_buffers();
(3) clearing of BH_Async_Write flag in nilfs_segctor_complete_write(),
nilfs_abort_logs(), nilfs_forget_buffer(), nilfs_clear_dirty_page().
Reported-by: Jerome Poulin <jeromepoulin@gmail.com>
Reported-by: Anton Eliasson <devel@antoneliasson.se>
Cc: Paul Fertser <fercerpav@gmail.com>
Cc: ARAI Shun-ichi <hermes@ceres.dti.ne.jp>
Cc: Piotr Szymaniak <szarpaj@grubelek.pl>
Cc: Juan Barry Manuel Canham <Linux@riotingpacifist.net>
Cc: Zahid Chowdhury <zahid.chowdhury@starsolutions.com>
Cc: Elmer Zhang <freeboy6716@gmail.com>
Cc: Kenneth Langga <klangga@gmail.com>
Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-30 13:45:12 -07:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-08 05:00:47 +09:00
|
|
|
|
2023-01-04 13:14:43 -08:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
2025-01-08 05:00:47 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-01-04 13:14:43 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-01 11:28:18 -07:00
|
|
|
|
2023-01-04 13:14:44 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-01 11:28:18 -07:00
|
|
|
|
|
|
|
|
|
2023-01-04 13:14:44 -08:00
|
|
|
|
2022-04-01 11:28:18 -07:00
|
|
|
|
2023-01-04 13:14:44 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
nilfs2: fix issue with race condition of competition between segments for dirty blocks
Many NILFS2 users were reported about strange file system corruption
(for example):
NILFS: bad btree node (blocknr=185027): level = 0, flags = 0x0, nchildren = 768
NILFS error (device sda4): nilfs_bmap_last_key: broken bmap (inode number=11540)
But such error messages are consequence of file system's issue that takes
place more earlier. Fortunately, Jerome Poulin <jeromepoulin@gmail.com>
and Anton Eliasson <devel@antoneliasson.se> were reported about another
issue not so recently. These reports describe the issue with segctor
thread's crash:
BUG: unable to handle kernel paging request at 0000000000004c83
IP: nilfs_end_page_io+0x12/0xd0 [nilfs2]
Call Trace:
nilfs_segctor_do_construct+0xf25/0x1b20 [nilfs2]
nilfs_segctor_construct+0x17b/0x290 [nilfs2]
nilfs_segctor_thread+0x122/0x3b0 [nilfs2]
kthread+0xc0/0xd0
ret_from_fork+0x7c/0xb0
These two issues have one reason. This reason can raise third issue
too. Third issue results in hanging of segctor thread with eating of
100% CPU.
REPRODUCING PATH:
One of the possible way or the issue reproducing was described by
Jermoe me Poulin <jeromepoulin@gmail.com>:
1. init S to get to single user mode.
2. sysrq+E to make sure only my shell is running
3. start network-manager to get my wifi connection up
4. login as root and launch "screen"
5. cd /boot/log/nilfs which is a ext3 mount point and can log when NILFS dies.
6. lscp | xz -9e > lscp.txt.xz
7. mount my snapshot using mount -o cp=3360839,ro /dev/vgUbuntu/root /mnt/nilfs
8. start a screen to dump /proc/kmsg to text file since rsyslog is killed
9. start a screen and launch strace -f -o find-cat.log -t find
/mnt/nilfs -type f -exec cat {} > /dev/null \;
10. start a screen and launch strace -f -o apt-get.log -t apt-get update
11. launch the last command again as it did not crash the first time
12. apt-get crashes
13. ps aux > ps-aux-crashed.log
13. sysrq+W
14. sysrq+E wait for everything to terminate
15. sysrq+SUSB
Simplified way of the issue reproducing is starting kernel compilation
task and "apt-get update" in parallel.
REPRODUCIBILITY:
The issue is reproduced not stable [60% - 80%]. It is very important to
have proper environment for the issue reproducing. The critical
conditions for successful reproducing:
(1) It should have big modified file by mmap() way.
(2) This file should have the count of dirty blocks are greater that
several segments in size (for example, two or three) from time to time
during processing.
(3) It should be intensive background activity of files modification
in another thread.
INVESTIGATION:
First of all, it is possible to see that the reason of crash is not valid
page address:
NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82
NILFS [nilfs_segctor_complete_write]:2101 segbuf->sb_segnum 6783
Moreover, value of b_page (0x1a82) is 6786. This value looks like segment
number. And b_blocknr with b_size values look like block numbers. So,
buffer_head's pointer points on not proper address value.
Detailed investigation of the issue is discovered such picture:
[-----------------------------SEGMENT 6783-------------------------------]
NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111149024, segbuf->sb_segnum 6783
[-----------------------------SEGMENT 6784-------------------------------]
NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff8802174a6798, bh->b_assoc_buffers.prev ffff880221cffee8
NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6784
NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111150080, segbuf->sb_segnum 6784, segbuf->sb_nbio 0
[----------] ditto
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111164416, segbuf->sb_segnum 6784, segbuf->sb_nbio 15
[-----------------------------SEGMENT 6785-------------------------------]
NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff880219277e80, bh->b_assoc_buffers.prev ffff880221cffc88
NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6785
NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111165440, segbuf->sb_segnum 6785, segbuf->sb_nbio 0
[----------] ditto
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111177728, segbuf->sb_segnum 6785, segbuf->sb_nbio 12
NILFS [nilfs_segctor_do_construct]:2399 nilfs_segctor_wait
NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6783
NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6784
NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6785
NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82
BUG: unable to handle kernel paging request at 0000000000001a82
IP: [<ffffffffa024d0f2>] nilfs_end_page_io+0x12/0xd0 [nilfs2]
Usually, for every segment we collect dirty files in list. Then, dirty
blocks are gathered for every dirty file, prepared for write and
submitted by means of nilfs_segbuf_submit_bh() call. Finally, it takes
place complete write phase after calling nilfs_end_bio_write() on the
block layer. Buffers/pages are marked as not dirty on final phase and
processed files removed from the list of dirty files.
It is possible to see that we had three prepare_write and submit_bio
phases before segbuf_wait and complete_write phase. Moreover, segments
compete between each other for dirty blocks because on every iteration
of segments processing dirty buffer_heads are added in several lists of
payload_buffers:
[SEGMENT 6784]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
[SEGMENT 6785]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8
The next pointer is the same but prev pointer has changed. It means
that buffer_head has next pointer from one list but prev pointer from
another. Such modification can be made several times. And, finally, it
can be resulted in various issues: (1) segctor hanging, (2) segctor
crashing, (3) file system metadata corruption.
FIX:
This patch adds:
(1) setting of BH_Async_Write flag in nilfs_segctor_prepare_write()
for every proccessed dirty block;
(2) checking of BH_Async_Write flag in
nilfs_lookup_dirty_data_buffers() and
nilfs_lookup_dirty_node_buffers();
(3) clearing of BH_Async_Write flag in nilfs_segctor_complete_write(),
nilfs_abort_logs(), nilfs_forget_buffer(), nilfs_clear_dirty_page().
Reported-by: Jerome Poulin <jeromepoulin@gmail.com>
Reported-by: Anton Eliasson <devel@antoneliasson.se>
Cc: Paul Fertser <fercerpav@gmail.com>
Cc: ARAI Shun-ichi <hermes@ceres.dti.ne.jp>
Cc: Piotr Szymaniak <szarpaj@grubelek.pl>
Cc: Juan Barry Manuel Canham <Linux@riotingpacifist.net>
Cc: Zahid Chowdhury <zahid.chowdhury@starsolutions.com>
Cc: Elmer Zhang <freeboy6716@gmail.com>
Cc: Kenneth Langga <klangga@gmail.com>
Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-30 13:45:12 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-04 13:14:44 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:39 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-05 12:25:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-27 00:07:30 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-16 23:44:55 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2010-12-27 00:07:30 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-22 23:01:57 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-22 23:01:55 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:39 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
nilfs2: fix buffer corruption due to concurrent device reads
As a result of analysis of a syzbot report, it turned out that in three
cases where nilfs2 allocates block device buffers directly via sb_getblk,
concurrent reads to the device can corrupt the allocated buffers.
Nilfs2 uses sb_getblk for segment summary blocks, that make up a log
header, and the super root block, that is the trailer, and when moving and
writing the second super block after fs resize.
In any of these, since the uptodate flag is not set when storing metadata
to be written in the allocated buffers, the stored metadata will be
overwritten if a device read of the same block occurs concurrently before
the write. This causes metadata corruption and misbehavior in the log
write itself, causing warnings in nilfs_btree_assign() as reported.
Fix these issues by setting an uptodate flag on the buffer head on the
first or before modifying each buffer obtained with sb_getblk, and
clearing the flag on failure.
When setting the uptodate flag, the lock_buffer/unlock_buffer pair is used
to perform necessary exclusive control, and the buffer is filled to ensure
that uninitialized bytes are not mixed into the data read from others. As
for buffers for segment summary blocks, they are filled incrementally, so
if the uptodate flag was unset on their allocation, set the flag and zero
fill the buffer once at that point.
Also, regarding the superblock move routine, the starting point of the
memset call to zerofill the block is incorrectly specified, which can
cause a buffer overflow on file systems with block sizes greater than
4KiB. In addition, if the superblock is moved within a large block, it is
necessary to assume the possibility that the data in the superblock will
be destroyed by zero-filling before copying. So fix these potential
issues as well.
Link: https://lkml.kernel.org/r/20230609035732.20426-1-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Reported-by: syzbot+31837fe952932efc8fb9@syzkaller.appspotmail.com
Closes: https://lkml.kernel.org/r/00000000000030000a05e981f475@google.com
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-09 12:57:32 +09:00
|
|
|
|
|
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
2011-04-30 18:56:12 +09:00
|
|
|
|
|
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
nilfs2: fix buffer corruption due to concurrent device reads
As a result of analysis of a syzbot report, it turned out that in three
cases where nilfs2 allocates block device buffers directly via sb_getblk,
concurrent reads to the device can corrupt the allocated buffers.
Nilfs2 uses sb_getblk for segment summary blocks, that make up a log
header, and the super root block, that is the trailer, and when moving and
writing the second super block after fs resize.
In any of these, since the uptodate flag is not set when storing metadata
to be written in the allocated buffers, the stored metadata will be
overwritten if a device read of the same block occurs concurrently before
the write. This causes metadata corruption and misbehavior in the log
write itself, causing warnings in nilfs_btree_assign() as reported.
Fix these issues by setting an uptodate flag on the buffer head on the
first or before modifying each buffer obtained with sb_getblk, and
clearing the flag on failure.
When setting the uptodate flag, the lock_buffer/unlock_buffer pair is used
to perform necessary exclusive control, and the buffer is filled to ensure
that uninitialized bytes are not mixed into the data read from others. As
for buffers for segment summary blocks, they are filled incrementally, so
if the uptodate flag was unset on their allocation, set the flag and zero
fill the buffer once at that point.
Also, regarding the superblock move routine, the starting point of the
memset call to zerofill the block is incorrectly specified, which can
cause a buffer overflow on file systems with block sizes greater than
4KiB. In addition, if the superblock is moved within a large block, it is
necessary to assume the possibility that the data in the superblock will
be destroyed by zero-filling before copying. So fix these potential
issues as well.
Link: https://lkml.kernel.org/r/20230609035732.20426-1-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Reported-by: syzbot+31837fe952932efc8fb9@syzkaller.appspotmail.com
Closes: https://lkml.kernel.org/r/00000000000030000a05e981f475@google.com
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-09 12:57:32 +09:00
|
|
|
|
2011-04-30 18:56:12 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-22 23:01:55 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-30 18:56:12 +09:00
|
|
|
|
nilfs2: fix buffer corruption due to concurrent device reads
As a result of analysis of a syzbot report, it turned out that in three
cases where nilfs2 allocates block device buffers directly via sb_getblk,
concurrent reads to the device can corrupt the allocated buffers.
Nilfs2 uses sb_getblk for segment summary blocks, that make up a log
header, and the super root block, that is the trailer, and when moving and
writing the second super block after fs resize.
In any of these, since the uptodate flag is not set when storing metadata
to be written in the allocated buffers, the stored metadata will be
overwritten if a device read of the same block occurs concurrently before
the write. This causes metadata corruption and misbehavior in the log
write itself, causing warnings in nilfs_btree_assign() as reported.
Fix these issues by setting an uptodate flag on the buffer head on the
first or before modifying each buffer obtained with sb_getblk, and
clearing the flag on failure.
When setting the uptodate flag, the lock_buffer/unlock_buffer pair is used
to perform necessary exclusive control, and the buffer is filled to ensure
that uninitialized bytes are not mixed into the data read from others. As
for buffers for segment summary blocks, they are filled incrementally, so
if the uptodate flag was unset on their allocation, set the flag and zero
fill the buffer once at that point.
Also, regarding the superblock move routine, the starting point of the
memset call to zerofill the block is incorrectly specified, which can
cause a buffer overflow on file systems with block sizes greater than
4KiB. In addition, if the superblock is moved within a large block, it is
necessary to assume the possibility that the data in the superblock will
be destroyed by zero-filling before copying. So fix these potential
issues as well.
Link: https://lkml.kernel.org/r/20230609035732.20426-1-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Reported-by: syzbot+31837fe952932efc8fb9@syzkaller.appspotmail.com
Closes: https://lkml.kernel.org/r/00000000000030000a05e981f475@google.com
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-09 12:57:32 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-13 15:53:22 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-05 12:56:51 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2016-05-23 16:22:57 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-22 00:46:26 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-10 10:01:50 +09:00
|
|
|
|
|
|
|
|
|
2024-08-22 00:46:26 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-01-22 23:01:58 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-08-22 00:46:26 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-05-16 23:44:55 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2010-12-27 00:07:30 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-10 10:01:49 +09:00
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:58 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 16:51:16 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-18 17:25:12 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:58 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 02:39:11 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 16:51:16 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 16:51:16 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
2009-11-25 01:04:21 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-25 01:04:21 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-11-25 01:04:21 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-18 18:23:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-11-18 18:23:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-11-18 18:23:34 +09:00
|
|
|
|
|
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 16:51:16 +09:00
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 16:51:16 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 16:51:16 +09:00
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2010-03-22 14:01:24 +09:00
|
|
|
|
|
|
|
|
|
2009-05-16 23:44:55 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
2014-01-14 17:56:36 -08:00
|
|
|
|
2009-05-16 23:44:55 +09:00
|
|
|
|
2014-01-14 17:56:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-18 02:35:13 +09:00
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:22:57 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-11 02:48:18 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-15 21:44:00 +00:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:26 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-11-14 17:44:26 +09:00
|
|
|
|
2016-05-23 16:23:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-04 12:53:28 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-11-14 17:44:26 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
nilfs2: prepare backing device folios for writing after adding checksums
Patch series "nilfs2: eliminate the call to inode_attach_wb()".
This series eliminates the inode_attach_wb() call from nilfs2, which was
introduced as a workaround for a kernel bug but is suspected of layer
violation (in fact, it is undesirable since it exposes a reference to the
backing device).
Removal of the inode_attach_wb() call is done by simply using
mark_buffer_dirty() on the backing device's buffers. To use it safely,
this series will prepare it in patch 1/2, and perform the replacement
itself in patch 2/2.
This patch (of 2):
In preparation for inode_attach_wb(), which is currently called when
attaching the log writer, to be done via mark_buffer_dirty(), change the
order of preparation for log writing.
Specifically, the function call that adds checksums to segment summary and
super root blocks, which correspond to the log header and trailer, is made
before starting writeback of folios containing those blocks.
The current steps are as follows:
1. Put the folios of segment summary blocks in writeback state.
2. Put the folios of data blocks, metadata file blocks, and btree node
blocks (collectively called payload blocks) into writeback state.
3. Put the super root block folio in writeback state.
4. Add checksums.
Change these as follows:
1. Put the folios of payload blocks in writeback state.
2. Add checksums.
3. Put the folios of segment summary blocks in writeback state.
4. Put the super root block folio in writeback state.
In this order, the contents of segment summaries and super root block
that directly use buffer/folio of the backing device can be determined
including the addition of checksums, before preparing to write.
Step (1), which puts the payload block folios in writeback state, is
performed first because if there are memory-mapped data blocks, a valid
checksum can only be calculated after step (1).
Link: https://lkml.kernel.org/r/20240610160029.7673-2-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-11 01:00:28 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:26 +09:00
|
|
|
|
nilfs2: prepare backing device folios for writing after adding checksums
Patch series "nilfs2: eliminate the call to inode_attach_wb()".
This series eliminates the inode_attach_wb() call from nilfs2, which was
introduced as a workaround for a kernel bug but is suspected of layer
violation (in fact, it is undesirable since it exposes a reference to the
backing device).
Removal of the inode_attach_wb() call is done by simply using
mark_buffer_dirty() on the backing device's buffers. To use it safely,
this series will prepare it in patch 1/2, and perform the replacement
itself in patch 2/2.
This patch (of 2):
In preparation for inode_attach_wb(), which is currently called when
attaching the log writer, to be done via mark_buffer_dirty(), change the
order of preparation for log writing.
Specifically, the function call that adds checksums to segment summary and
super root blocks, which correspond to the log header and trailer, is made
before starting writeback of folios containing those blocks.
The current steps are as follows:
1. Put the folios of segment summary blocks in writeback state.
2. Put the folios of data blocks, metadata file blocks, and btree node
blocks (collectively called payload blocks) into writeback state.
3. Put the super root block folio in writeback state.
4. Add checksums.
Change these as follows:
1. Put the folios of payload blocks in writeback state.
2. Add checksums.
3. Put the folios of segment summary blocks in writeback state.
4. Put the super root block folio in writeback state.
In this order, the contents of segment summaries and super root block
that directly use buffer/folio of the backing device can be determined
including the addition of checksums, before preparing to write.
Step (1), which puts the payload block folios in writeback state, is
performed first because if there are memory-mapped data blocks, a valid
checksum can only be calculated after step (1).
Link: https://lkml.kernel.org/r/20240610160029.7673-2-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-11 01:00:28 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
nilfs2: prepare backing device folios for writing after adding checksums
Patch series "nilfs2: eliminate the call to inode_attach_wb()".
This series eliminates the inode_attach_wb() call from nilfs2, which was
introduced as a workaround for a kernel bug but is suspected of layer
violation (in fact, it is undesirable since it exposes a reference to the
backing device).
Removal of the inode_attach_wb() call is done by simply using
mark_buffer_dirty() on the backing device's buffers. To use it safely,
this series will prepare it in patch 1/2, and perform the replacement
itself in patch 2/2.
This patch (of 2):
In preparation for inode_attach_wb(), which is currently called when
attaching the log writer, to be done via mark_buffer_dirty(), change the
order of preparation for log writing.
Specifically, the function call that adds checksums to segment summary and
super root blocks, which correspond to the log header and trailer, is made
before starting writeback of folios containing those blocks.
The current steps are as follows:
1. Put the folios of segment summary blocks in writeback state.
2. Put the folios of data blocks, metadata file blocks, and btree node
blocks (collectively called payload blocks) into writeback state.
3. Put the super root block folio in writeback state.
4. Add checksums.
Change these as follows:
1. Put the folios of payload blocks in writeback state.
2. Add checksums.
3. Put the folios of segment summary blocks in writeback state.
4. Put the super root block folio in writeback state.
In this order, the contents of segment summaries and super root block
that directly use buffer/folio of the backing device can be determined
including the addition of checksums, before preparing to write.
Step (1), which puts the payload block folios in writeback state, is
performed first because if there are memory-mapped data blocks, a valid
checksum can only be calculated after step (1).
Link: https://lkml.kernel.org/r/20240610160029.7673-2-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-11 01:00:28 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
nilfs2: prepare backing device folios for writing after adding checksums
Patch series "nilfs2: eliminate the call to inode_attach_wb()".
This series eliminates the inode_attach_wb() call from nilfs2, which was
introduced as a workaround for a kernel bug but is suspected of layer
violation (in fact, it is undesirable since it exposes a reference to the
backing device).
Removal of the inode_attach_wb() call is done by simply using
mark_buffer_dirty() on the backing device's buffers. To use it safely,
this series will prepare it in patch 1/2, and perform the replacement
itself in patch 2/2.
This patch (of 2):
In preparation for inode_attach_wb(), which is currently called when
attaching the log writer, to be done via mark_buffer_dirty(), change the
order of preparation for log writing.
Specifically, the function call that adds checksums to segment summary and
super root blocks, which correspond to the log header and trailer, is made
before starting writeback of folios containing those blocks.
The current steps are as follows:
1. Put the folios of segment summary blocks in writeback state.
2. Put the folios of data blocks, metadata file blocks, and btree node
blocks (collectively called payload blocks) into writeback state.
3. Put the super root block folio in writeback state.
4. Add checksums.
Change these as follows:
1. Put the folios of payload blocks in writeback state.
2. Add checksums.
3. Put the folios of segment summary blocks in writeback state.
4. Put the super root block folio in writeback state.
In this order, the contents of segment summaries and super root block
that directly use buffer/folio of the backing device can be determined
including the addition of checksums, before preparing to write.
Step (1), which puts the payload block folios in writeback state, is
performed first because if there are memory-mapped data blocks, a valid
checksum can only be calculated after step (1).
Link: https://lkml.kernel.org/r/20240610160029.7673-2-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-11 01:00:28 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-02-04 01:16:45 +09:00
|
|
|
|
2023-11-14 17:44:26 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nilfs2: prepare backing device folios for writing after adding checksums
Patch series "nilfs2: eliminate the call to inode_attach_wb()".
This series eliminates the inode_attach_wb() call from nilfs2, which was
introduced as a workaround for a kernel bug but is suspected of layer
violation (in fact, it is undesirable since it exposes a reference to the
backing device).
Removal of the inode_attach_wb() call is done by simply using
mark_buffer_dirty() on the backing device's buffers. To use it safely,
this series will prepare it in patch 1/2, and perform the replacement
itself in patch 2/2.
This patch (of 2):
In preparation for inode_attach_wb(), which is currently called when
attaching the log writer, to be done via mark_buffer_dirty(), change the
order of preparation for log writing.
Specifically, the function call that adds checksums to segment summary and
super root blocks, which correspond to the log header and trailer, is made
before starting writeback of folios containing those blocks.
The current steps are as follows:
1. Put the folios of segment summary blocks in writeback state.
2. Put the folios of data blocks, metadata file blocks, and btree node
blocks (collectively called payload blocks) into writeback state.
3. Put the super root block folio in writeback state.
4. Add checksums.
Change these as follows:
1. Put the folios of payload blocks in writeback state.
2. Add checksums.
3. Put the folios of segment summary blocks in writeback state.
4. Put the super root block folio in writeback state.
In this order, the contents of segment summaries and super root block
that directly use buffer/folio of the backing device can be determined
including the addition of checksums, before preparing to write.
Step (1), which puts the payload block folios in writeback state, is
performed first because if there are memory-mapped data blocks, a valid
checksum can only be calculated after step (1).
Link: https://lkml.kernel.org/r/20240610160029.7673-2-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-11 01:00:28 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-11 01:00:29 +09:00
|
|
|
|
nilfs2: prepare backing device folios for writing after adding checksums
Patch series "nilfs2: eliminate the call to inode_attach_wb()".
This series eliminates the inode_attach_wb() call from nilfs2, which was
introduced as a workaround for a kernel bug but is suspected of layer
violation (in fact, it is undesirable since it exposes a reference to the
backing device).
Removal of the inode_attach_wb() call is done by simply using
mark_buffer_dirty() on the backing device's buffers. To use it safely,
this series will prepare it in patch 1/2, and perform the replacement
itself in patch 2/2.
This patch (of 2):
In preparation for inode_attach_wb(), which is currently called when
attaching the log writer, to be done via mark_buffer_dirty(), change the
order of preparation for log writing.
Specifically, the function call that adds checksums to segment summary and
super root blocks, which correspond to the log header and trailer, is made
before starting writeback of folios containing those blocks.
The current steps are as follows:
1. Put the folios of segment summary blocks in writeback state.
2. Put the folios of data blocks, metadata file blocks, and btree node
blocks (collectively called payload blocks) into writeback state.
3. Put the super root block folio in writeback state.
4. Add checksums.
Change these as follows:
1. Put the folios of payload blocks in writeback state.
2. Add checksums.
3. Put the folios of segment summary blocks in writeback state.
4. Put the super root block folio in writeback state.
In this order, the contents of segment summaries and super root block
that directly use buffer/folio of the backing device can be determined
including the addition of checksums, before preparing to write.
Step (1), which puts the payload block folios in writeback state, is
performed first because if there are memory-mapped data blocks, a valid
checksum can only be calculated after step (1).
Link: https://lkml.kernel.org/r/20240610160029.7673-2-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-11 01:00:28 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-11 01:00:29 +09:00
|
|
|
|
nilfs2: prepare backing device folios for writing after adding checksums
Patch series "nilfs2: eliminate the call to inode_attach_wb()".
This series eliminates the inode_attach_wb() call from nilfs2, which was
introduced as a workaround for a kernel bug but is suspected of layer
violation (in fact, it is undesirable since it exposes a reference to the
backing device).
Removal of the inode_attach_wb() call is done by simply using
mark_buffer_dirty() on the backing device's buffers. To use it safely,
this series will prepare it in patch 1/2, and perform the replacement
itself in patch 2/2.
This patch (of 2):
In preparation for inode_attach_wb(), which is currently called when
attaching the log writer, to be done via mark_buffer_dirty(), change the
order of preparation for log writing.
Specifically, the function call that adds checksums to segment summary and
super root blocks, which correspond to the log header and trailer, is made
before starting writeback of folios containing those blocks.
The current steps are as follows:
1. Put the folios of segment summary blocks in writeback state.
2. Put the folios of data blocks, metadata file blocks, and btree node
blocks (collectively called payload blocks) into writeback state.
3. Put the super root block folio in writeback state.
4. Add checksums.
Change these as follows:
1. Put the folios of payload blocks in writeback state.
2. Add checksums.
3. Put the folios of segment summary blocks in writeback state.
4. Put the super root block folio in writeback state.
In this order, the contents of segment summaries and super root block
that directly use buffer/folio of the backing device can be determined
including the addition of checksums, before preparing to write.
Step (1), which puts the payload block folios in writeback state, is
performed first because if there are memory-mapped data blocks, a valid
checksum can only be calculated after step (1).
Link: https://lkml.kernel.org/r/20240610160029.7673-2-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-11 01:00:28 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:26 +09:00
|
|
|
|
|
|
|
|
|
2024-05-30 23:15:56 +09:00
|
|
|
|
2023-11-14 17:44:26 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 01:17:31 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-12-17 00:55:40 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-12-17 00:55:40 +09:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:17 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-11-14 17:44:17 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:17 +09:00
|
|
|
|
|
|
|
|
|
2009-06-18 23:52:23 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:17 +09:00
|
|
|
|
2009-07-28 17:55:29 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:17 +09:00
|
|
|
|
2023-11-14 17:44:21 +09:00
|
|
|
|
2023-11-14 17:44:25 +09:00
|
|
|
|
2023-11-14 17:44:17 +09:00
|
|
|
|
2009-07-28 17:55:29 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-07-28 17:55:29 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-04-30 14:09:01 +09:00
|
|
|
|
2023-11-14 17:44:17 +09:00
|
|
|
|
2011-04-04 12:53:28 +09:00
|
|
|
|
2023-11-14 17:44:17 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-04 12:53:28 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:18 +09:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
nilfs2: fix buffer corruption due to concurrent device reads
As a result of analysis of a syzbot report, it turned out that in three
cases where nilfs2 allocates block device buffers directly via sb_getblk,
concurrent reads to the device can corrupt the allocated buffers.
Nilfs2 uses sb_getblk for segment summary blocks, that make up a log
header, and the super root block, that is the trailer, and when moving and
writing the second super block after fs resize.
In any of these, since the uptodate flag is not set when storing metadata
to be written in the allocated buffers, the stored metadata will be
overwritten if a device read of the same block occurs concurrently before
the write. This causes metadata corruption and misbehavior in the log
write itself, causing warnings in nilfs_btree_assign() as reported.
Fix these issues by setting an uptodate flag on the buffer head on the
first or before modifying each buffer obtained with sb_getblk, and
clearing the flag on failure.
When setting the uptodate flag, the lock_buffer/unlock_buffer pair is used
to perform necessary exclusive control, and the buffer is filled to ensure
that uninitialized bytes are not mixed into the data read from others. As
for buffers for segment summary blocks, they are filled incrementally, so
if the uptodate flag was unset on their allocation, set the flag and zero
fill the buffer once at that point.
Also, regarding the superblock move routine, the starting point of the
memset call to zerofill the block is incorrectly specified, which can
cause a buffer overflow on file systems with block sizes greater than
4KiB. In addition, if the superblock is moved within a large block, it is
necessary to assume the possibility that the data in the superblock will
be destroyed by zero-filling before copying. So fix these potential
issues as well.
Link: https://lkml.kernel.org/r/20230609035732.20426-1-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Reported-by: syzbot+31837fe952932efc8fb9@syzkaller.appspotmail.com
Closes: https://lkml.kernel.org/r/00000000000030000a05e981f475@google.com
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-09 12:57:32 +09:00
|
|
|
|
2023-11-14 17:44:18 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
nilfs2: fix buffer corruption due to concurrent device reads
As a result of analysis of a syzbot report, it turned out that in three
cases where nilfs2 allocates block device buffers directly via sb_getblk,
concurrent reads to the device can corrupt the allocated buffers.
Nilfs2 uses sb_getblk for segment summary blocks, that make up a log
header, and the super root block, that is the trailer, and when moving and
writing the second super block after fs resize.
In any of these, since the uptodate flag is not set when storing metadata
to be written in the allocated buffers, the stored metadata will be
overwritten if a device read of the same block occurs concurrently before
the write. This causes metadata corruption and misbehavior in the log
write itself, causing warnings in nilfs_btree_assign() as reported.
Fix these issues by setting an uptodate flag on the buffer head on the
first or before modifying each buffer obtained with sb_getblk, and
clearing the flag on failure.
When setting the uptodate flag, the lock_buffer/unlock_buffer pair is used
to perform necessary exclusive control, and the buffer is filled to ensure
that uninitialized bytes are not mixed into the data read from others. As
for buffers for segment summary blocks, they are filled incrementally, so
if the uptodate flag was unset on their allocation, set the flag and zero
fill the buffer once at that point.
Also, regarding the superblock move routine, the starting point of the
memset call to zerofill the block is incorrectly specified, which can
cause a buffer overflow on file systems with block sizes greater than
4KiB. In addition, if the superblock is moved within a large block, it is
necessary to assume the possibility that the data in the superblock will
be destroyed by zero-filling before copying. So fix these potential
issues as well.
Link: https://lkml.kernel.org/r/20230609035732.20426-1-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Reported-by: syzbot+31837fe952932efc8fb9@syzkaller.appspotmail.com
Closes: https://lkml.kernel.org/r/00000000000030000a05e981f475@google.com
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-09 12:57:32 +09:00
|
|
|
|
2023-11-14 17:44:18 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-04 01:16:45 +09:00
|
|
|
|
2023-11-14 17:44:18 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:18 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-11-14 17:44:18 +09:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-04 12:53:28 +09:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
nilfs2: fix state management in error path of log writing function
After commit a694291a6211 ("nilfs2: separate wait function from
nilfs_segctor_write") was applied, the log writing function
nilfs_segctor_do_construct() was able to issue I/O requests continuously
even if user data blocks were split into multiple logs across segments,
but two potential flaws were introduced in its error handling.
First, if nilfs_segctor_begin_construction() fails while creating the
second or subsequent logs, the log writing function returns without
calling nilfs_segctor_abort_construction(), so the writeback flag set on
pages/folios will remain uncleared. This causes page cache operations to
hang waiting for the writeback flag. For example,
truncate_inode_pages_final(), which is called via nilfs_evict_inode() when
an inode is evicted from memory, will hang.
Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared.
As a result, if the next log write involves checkpoint creation, that's
fine, but if a partial log write is performed that does not, inodes with
NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files"
list, and their data and b-tree blocks may not be written to the device,
corrupting the block mapping.
Fix these issues by uniformly calling nilfs_segctor_abort_construction()
on failure of each step in the loop in nilfs_segctor_do_construct(),
having it clean up logs and segment usages according to progress, and
correcting the conditions for calling nilfs_redirty_inodes() to ensure
that the NILFS_I_COLLECTED flag is cleared.
Link: https://lkml.kernel.org/r/20240814101119.4070-1-konishi.ryusuke@gmail.com
Fixes: a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write")
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-08-14 19:11:19 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 03:13:39 +09:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:19 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:19 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:19 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-11-14 17:44:19 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:19 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-02 14:05:28 -07:00
|
|
|
|
2015-04-16 12:46:28 -07:00
|
|
|
|
2016-08-02 14:05:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-16 12:46:28 -07:00
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
2024-02-04 01:16:45 +09:00
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:19 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2024-02-04 01:16:45 +09:00
|
|
|
|
2023-11-14 17:44:19 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-23 21:48:36 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-23 21:48:36 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 17:44:19 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-11-14 17:44:19 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-11-14 17:44:19 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-29 12:44:56 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-08-29 12:44:56 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-13 15:53:20 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:59 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:57 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2020-08-11 18:35:49 -07:00
|
|
|
|
2026-03-04 10:32:42 -05:00
|
|
|
|
2020-08-11 18:35:49 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nilfs2: fix race condition that causes file system corruption
There is a race condition between nilfs_dirty_inode() and
nilfs_set_file_dirty().
When a file is opened, nilfs_dirty_inode() is called to update the
access timestamp in the inode. It calls __nilfs_mark_inode_dirty() in a
separate transaction. __nilfs_mark_inode_dirty() caches the ifile
buffer_head in the i_bh field of the inode info structure and marks it
as dirty.
After some data was written to the file in another transaction, the
function nilfs_set_file_dirty() is called, which adds the inode to the
ns_dirty_files list.
Then the segment construction calls nilfs_segctor_collect_dirty_files(),
which goes through the ns_dirty_files list and checks the i_bh field.
If there is a cached buffer_head in i_bh it is not marked as dirty
again.
Since nilfs_dirty_inode() and nilfs_set_file_dirty() use separate
transactions, it is possible that a segment construction that writes out
the ifile occurs in-between the two. If this happens the inode is not
on the ns_dirty_files list, but its ifile block is still marked as dirty
and written out.
In the next segment construction, the data for the file is written out
and nilfs_bmap_propagate() updates the b-tree. Eventually the bmap root
is written into the i_bh block, which is not dirty, because it was
written out in another segment construction.
As a result the bmap update can be lost, which leads to file system
corruption. Either the virtual block address points to an unallocated
DAT block, or the DAT entry will be reused for something different.
The error can remain undetected for a long time. A typical error
message would be one of the "bad btree" errors or a warning that a DAT
entry could not be found.
This bug can be reproduced reliably by a simple benchmark that creates
and overwrites millions of 4k files.
Link: http://lkml.kernel.org/r/1509367935-3086-2-git-send-email-konishi.ryusuke@lab.ntt.co.jp
Signed-off-by: Andreas Rohner <andreas.rohner@gmx.net>
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Tested-by: Andreas Rohner <andreas.rohner@gmx.net>
Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-11-17 15:29:35 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-19 16:45:30 +01:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2017-11-27 13:05:09 -08:00
|
|
|
|
2015-02-05 12:25:20 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2010-08-20 20:10:38 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-08-20 20:10:38 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-05 12:25:20 -08:00
|
|
|
|
2015-03-12 16:26:00 -07:00
|
|
|
|
2015-02-05 12:25:20 -08:00
|
|
|
|
2015-03-12 16:26:00 -07:00
|
|
|
|
|
|
|
|
|
2015-02-05 12:25:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2015-02-05 12:25:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-04-27 10:15:26 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2010-08-20 20:10:38 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nilfs2: fix state management in error path of log writing function
After commit a694291a6211 ("nilfs2: separate wait function from
nilfs_segctor_write") was applied, the log writing function
nilfs_segctor_do_construct() was able to issue I/O requests continuously
even if user data blocks were split into multiple logs across segments,
but two potential flaws were introduced in its error handling.
First, if nilfs_segctor_begin_construction() fails while creating the
second or subsequent logs, the log writing function returns without
calling nilfs_segctor_abort_construction(), so the writeback flag set on
pages/folios will remain uncleared. This causes page cache operations to
hang waiting for the writeback flag. For example,
truncate_inode_pages_final(), which is called via nilfs_evict_inode() when
an inode is evicted from memory, will hang.
Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared.
As a result, if the next log write involves checkpoint creation, that's
fine, but if a partial log write is performed that does not, inodes with
NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files"
list, and their data and b-tree blocks may not be written to the device,
corrupting the block mapping.
Fix these issues by uniformly calling nilfs_segctor_abort_construction()
on failure of each step in the loop in nilfs_segctor_do_construct(),
having it clean up logs and segment usages according to progress, and
correcting the conditions for calling nilfs_redirty_inodes() to ensure
that the NILFS_I_COLLECTED flag is cleared.
Link: https://lkml.kernel.org/r/20240814101119.4070-1-konishi.ryusuke@gmail.com
Fixes: a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write")
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-08-14 19:11:19 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2018-02-06 15:39:21 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2010-05-23 21:48:36 +09:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-03-23 01:15:31 +09:00
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2024-01-22 23:01:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nilfs2: prepare backing device folios for writing after adding checksums
Patch series "nilfs2: eliminate the call to inode_attach_wb()".
This series eliminates the inode_attach_wb() call from nilfs2, which was
introduced as a workaround for a kernel bug but is suspected of layer
violation (in fact, it is undesirable since it exposes a reference to the
backing device).
Removal of the inode_attach_wb() call is done by simply using
mark_buffer_dirty() on the backing device's buffers. To use it safely,
this series will prepare it in patch 1/2, and perform the replacement
itself in patch 2/2.
This patch (of 2):
In preparation for inode_attach_wb(), which is currently called when
attaching the log writer, to be done via mark_buffer_dirty(), change the
order of preparation for log writing.
Specifically, the function call that adds checksums to segment summary and
super root blocks, which correspond to the log header and trailer, is made
before starting writeback of folios containing those blocks.
The current steps are as follows:
1. Put the folios of segment summary blocks in writeback state.
2. Put the folios of data blocks, metadata file blocks, and btree node
blocks (collectively called payload blocks) into writeback state.
3. Put the super root block folio in writeback state.
4. Add checksums.
Change these as follows:
1. Put the folios of payload blocks in writeback state.
2. Add checksums.
3. Put the folios of segment summary blocks in writeback state.
4. Put the super root block folio in writeback state.
In this order, the contents of segment summaries and super root block
that directly use buffer/folio of the backing device can be determined
including the addition of checksums, before preparing to write.
Step (1), which puts the payload block folios in writeback state, is
performed first because if there are memory-mapped data blocks, a valid
checksum can only be calculated after step (1).
Link: https://lkml.kernel.org/r/20240610160029.7673-2-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-11 01:00:28 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-29 01:17:31 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros
PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
ago with promise that one day it will be possible to implement page
cache with bigger chunks than PAGE_SIZE.
This promise never materialized. And unlikely will.
We have many places where PAGE_CACHE_SIZE assumed to be equal to
PAGE_SIZE. And it's constant source of confusion on whether
PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
especially on the border between fs and mm.
Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
breakage to be doable.
Let's stop pretending that pages in page cache are special. They are
not.
The changes are pretty straight-forward:
- <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
- page_cache_get() -> get_page();
- page_cache_release() -> put_page();
This patch contains automated changes generated with coccinelle using
script below. For some reason, coccinelle doesn't patch header files.
I've called spatch for them manually.
The only adjustment after coccinelle is revert of changes to
PAGE_CAHCE_ALIGN definition: we are going to drop it later.
There are few places in the code where coccinelle didn't reach. I'll
fix them manually in a separate patch. Comments and documentation also
will be addressed with the separate patch.
virtual patch
@@
expression E;
@@
- E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
expression E;
@@
- E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
@@
- PAGE_CACHE_SHIFT
+ PAGE_SHIFT
@@
@@
- PAGE_CACHE_SIZE
+ PAGE_SIZE
@@
@@
- PAGE_CACHE_MASK
+ PAGE_MASK
@@
expression E;
@@
- PAGE_CACHE_ALIGN(E)
+ PAGE_ALIGN(E)
@@
expression E;
@@
- page_cache_get(E)
+ get_page(E)
@@
expression E;
@@
- page_cache_release(E)
+ put_page(E)
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-01 15:29:47 +03:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:31:59 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nilfs2: fix state management in error path of log writing function
After commit a694291a6211 ("nilfs2: separate wait function from
nilfs_segctor_write") was applied, the log writing function
nilfs_segctor_do_construct() was able to issue I/O requests continuously
even if user data blocks were split into multiple logs across segments,
but two potential flaws were introduced in its error handling.
First, if nilfs_segctor_begin_construction() fails while creating the
second or subsequent logs, the log writing function returns without
calling nilfs_segctor_abort_construction(), so the writeback flag set on
pages/folios will remain uncleared. This causes page cache operations to
hang waiting for the writeback flag. For example,
truncate_inode_pages_final(), which is called via nilfs_evict_inode() when
an inode is evicted from memory, will hang.
Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared.
As a result, if the next log write involves checkpoint creation, that's
fine, but if a partial log write is performed that does not, inodes with
NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files"
list, and their data and b-tree blocks may not be written to the device,
corrupting the block mapping.
Fix these issues by uniformly calling nilfs_segctor_abort_construction()
on failure of each step in the loop in nilfs_segctor_do_construct(),
having it clean up logs and segment usages according to progress, and
correcting the conditions for calling nilfs_redirty_inodes() to ensure
that the NILFS_I_COLLECTED flag is cleared.
Link: https://lkml.kernel.org/r/20240814101119.4070-1-konishi.ryusuke@gmail.com
Fixes: a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write")
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-08-14 19:11:19 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-14 03:01:03 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-10 23:25:39 +08:00
|
|
|
|
2024-05-20 22:26:19 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-02 14:05:28 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2016-08-02 14:05:28 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-20 12:06:13 +02:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nilfs2: fix unexpected freezing of nilfs_segctor_sync()
A potential and reproducible race issue has been identified where
nilfs_segctor_sync() would block even after the log writer thread writes a
checkpoint, unless there is an interrupt or other trigger to resume log
writing.
This turned out to be because, depending on the execution timing of the
log writer thread running in parallel, the log writer thread may skip
responding to nilfs_segctor_sync(), which causes a call to schedule()
waiting for completion within nilfs_segctor_sync() to lose the opportunity
to wake up.
The reason why waking up the task waiting in nilfs_segctor_sync() may be
skipped is that updating the request generation issued using a shared
sequence counter and adding an wait queue entry to the request wait queue
to the log writer, are not done atomically. There is a possibility that
log writing and request completion notification by nilfs_segctor_wakeup()
may occur between the two operations, and in that case, the wait queue
entry is not yet visible to nilfs_segctor_wakeup() and the wake-up of
nilfs_segctor_sync() will be carried over until the next request occurs.
Fix this issue by performing these two operations simultaneously within
the lock section of sc_state_lock. Also, following the memory barrier
guidelines for event waiting loops, move the call to set_current_state()
in the same location into the event waiting loop to ensure that a memory
barrier is inserted just before the event condition determination.
Link: https://lkml.kernel.org/r/20240520132621.4054-3-konishi.ryusuke@gmail.com
Fixes: 9ff05123e3bf ("nilfs2: segment constructor")
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Cc: "Bai, Shuangpeng" <sjb7183@psu.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-20 22:26:20 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
nilfs2: fix unexpected freezing of nilfs_segctor_sync()
A potential and reproducible race issue has been identified where
nilfs_segctor_sync() would block even after the log writer thread writes a
checkpoint, unless there is an interrupt or other trigger to resume log
writing.
This turned out to be because, depending on the execution timing of the
log writer thread running in parallel, the log writer thread may skip
responding to nilfs_segctor_sync(), which causes a call to schedule()
waiting for completion within nilfs_segctor_sync() to lose the opportunity
to wake up.
The reason why waking up the task waiting in nilfs_segctor_sync() may be
skipped is that updating the request generation issued using a shared
sequence counter and adding an wait queue entry to the request wait queue
to the log writer, are not done atomically. There is a possibility that
log writing and request completion notification by nilfs_segctor_wakeup()
may occur between the two operations, and in that case, the wait queue
entry is not yet visible to nilfs_segctor_wakeup() and the wake-up of
nilfs_segctor_sync() will be carried over until the next request occurs.
Fix this issue by performing these two operations simultaneously within
the lock section of sc_state_lock. Also, following the memory barrier
guidelines for event waiting loops, move the call to set_current_state()
in the same location into the event waiting loop to ensure that a memory
barrier is inserted just before the event condition determination.
Link: https://lkml.kernel.org/r/20240520132621.4054-3-konishi.ryusuke@gmail.com
Fixes: 9ff05123e3bf ("nilfs2: segment constructor")
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Cc: "Bai, Shuangpeng" <sjb7183@psu.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-20 22:26:20 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nilfs2: fix unexpected freezing of nilfs_segctor_sync()
A potential and reproducible race issue has been identified where
nilfs_segctor_sync() would block even after the log writer thread writes a
checkpoint, unless there is an interrupt or other trigger to resume log
writing.
This turned out to be because, depending on the execution timing of the
log writer thread running in parallel, the log writer thread may skip
responding to nilfs_segctor_sync(), which causes a call to schedule()
waiting for completion within nilfs_segctor_sync() to lose the opportunity
to wake up.
The reason why waking up the task waiting in nilfs_segctor_sync() may be
skipped is that updating the request generation issued using a shared
sequence counter and adding an wait queue entry to the request wait queue
to the log writer, are not done atomically. There is a possibility that
log writing and request completion notification by nilfs_segctor_wakeup()
may occur between the two operations, and in that case, the wait queue
entry is not yet visible to nilfs_segctor_wakeup() and the wake-up of
nilfs_segctor_sync() will be carried over until the next request occurs.
Fix this issue by performing these two operations simultaneously within
the lock section of sc_state_lock. Also, following the memory barrier
guidelines for event waiting loops, move the call to set_current_state()
in the same location into the event waiting loop to ensure that a memory
barrier is inserted just before the event condition determination.
Link: https://lkml.kernel.org/r/20240520132621.4054-3-konishi.ryusuke@gmail.com
Fixes: 9ff05123e3bf ("nilfs2: segment constructor")
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Cc: "Bai, Shuangpeng" <sjb7183@psu.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-05-20 22:26:20 +09:00
|
|
|
|
|
|
|
|
|
2024-05-20 22:26:21 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-20 22:26:21 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 12:06:46 +02:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-05-20 22:26:21 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-10 10:01:48 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2022-11-04 23:29:59 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-21 12:48:03 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2025-01-10 10:01:48 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-04 23:29:59 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2014-10-13 15:53:22 -07:00
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2014-10-13 15:53:20 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-02 14:05:28 -07:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-05-20 22:26:19 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
2024-05-20 22:26:19 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-05-20 22:26:19 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-04-05 10:17:26 +02:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
2009-11-02 15:08:13 +09:00
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
2024-05-20 22:26:21 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-02 15:08:13 +09:00
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
2009-11-02 15:08:13 +09:00
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
2009-11-02 15:08:13 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-11-02 15:08:13 +09:00
|
|
|
|
2024-05-20 22:26:19 +09:00
|
|
|
|
2010-04-10 23:25:39 +08:00
|
|
|
|
|
|
|
|
|
2009-11-02 15:08:13 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-10 10:01:49 +09:00
|
|
|
|
|
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2010-06-28 17:49:32 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-28 17:49:32 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2010-06-28 17:49:33 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
|
|
|
|
|
2010-06-28 17:49:33 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-17 15:29:32 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2025-05-09 07:51:14 +02:00
|
|
|
|
2016-05-23 16:23:25 -07:00
|
|
|
|
2024-08-27 02:41:14 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-20 12:52:57 -07:00
|
|
|
|
2022-04-01 11:28:18 -07:00
|
|
|
|
2010-08-20 19:06:11 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-10 22:41:43 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2026-05-03 13:33:29 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2026-05-03 13:33:29 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-29 12:44:56 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2009-05-16 23:44:55 +09:00
|
|
|
|
2009-05-10 22:41:43 +09:00
|
|
|
|
2010-08-29 12:44:56 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-08-29 12:44:56 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2009-05-16 23:44:55 +09:00
|
|
|
|
|
|
|
|
|
2009-11-29 02:39:11 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 18:35:49 -07:00
|
|
|
|
2026-07-17 10:58:54 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2010-01-30 18:06:35 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 18:35:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2010-01-30 18:06:35 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2009-05-16 23:44:55 +09:00
|
|
|
|
|
|
|
|
|
2010-08-29 12:44:56 +09:00
|
|
|
|
2026-05-03 13:33:29 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-06 16:32:14 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-27 02:41:16 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-08-27 02:41:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2024-08-27 02:41:15 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2020-08-11 18:35:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2023-12-19 18:09:18 +09:00
|
|
|
|
2024-08-27 02:41:16 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2024-08-27 02:41:16 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-27 02:41:16 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2009-12-09 00:57:52 +09:00
|
|
|
|
|
|
|
|
|
2009-07-23 01:33:49 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-08-27 02:41:16 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-08-27 02:41:16 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-05-20 22:26:19 +09:00
|
|
|
|
2023-03-28 02:53:18 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2015-02-05 12:25:20 -08:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2011-06-10 00:33:06 +09:00
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-23 16:23:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2010-01-26 15:20:15 +09:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2015-02-05 12:25:20 -08:00
|
|
|
|
|
|
|
|
|
2023-04-27 10:15:26 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2024-08-27 02:41:15 +09:00
|
|
|
|
|
|
|
|
|
2025-10-30 07:51:52 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-27 02:41:15 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-20 22:26:21 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-05 12:25:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-31 12:39:50 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 18:35:49 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2015-02-05 12:25:20 -08:00
|
|
|
|
2020-08-11 18:35:49 -07:00
|
|
|
|
|
|
|
|
|
2015-02-05 12:25:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:55 -07:00
|
|
|
|
2009-11-29 23:03:04 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
|
|
|
|
|
2010-08-14 13:07:15 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2025-01-10 10:01:50 +09:00
|
|
|
|
|
|
|
|
|
2024-08-27 02:41:15 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2024-08-27 02:41:15 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2010-01-31 19:46:40 +09:00
|
|
|
|
2022-11-04 23:29:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-31 19:46:40 +09:00
|
|
|
|
2022-11-04 23:29:59 +09:00
|
|
|
|
2010-01-31 19:46:40 +09:00
|
|
|
|
|
|
|
|
|
2024-08-27 02:41:15 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2024-08-27 02:41:15 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-07 17:52:26 +09:00
|
|
|
|
2024-08-27 02:41:15 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-07 17:52:26 +09:00
|
|
|
|
2024-08-27 02:41:15 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:08 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput
During unmount process of nilfs2, nothing holds nilfs_root structure after
nilfs2 detaches its writer in nilfs_detach_log_writer(). Previously,
nilfs_evict_inode() could cause use-after-free read for nilfs_root if
inodes are left in "garbage_list" and released by nilfs_dispose_list at
the end of nilfs_detach_log_writer(), and this bug was fixed by commit
9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in
nilfs_evict_inode()").
However, it turned out that there is another possibility of UAF in the
call path where mark_inode_dirty_sync() is called from iput():
nilfs_detach_log_writer()
nilfs_dispose_list()
iput()
mark_inode_dirty_sync()
__mark_inode_dirty()
nilfs_dirty_inode()
__nilfs_mark_inode_dirty()
nilfs_load_inode_block() --> causes UAF of nilfs_root struct
This can happen after commit 0ae45f63d4ef ("vfs: add support for a
lazytime mount option"), which changed iput() to call
mark_inode_dirty_sync() on its final reference if i_state has I_DIRTY_TIME
flag and i_nlink is non-zero.
This issue appears after commit 28a65b49eb53 ("nilfs2: do not write dirty
data after degenerating to read-only") when using the syzbot reproducer,
but the issue has potentially existed before.
Fix this issue by adding a "purging flag" to the nilfs structure, setting
that flag while disposing the "garbage_list" and checking it in
__nilfs_mark_inode_dirty().
Unlike commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root
in nilfs_evict_inode()"), this patch does not rely on ns_writer to
determine whether to skip operations, so as not to break recovery on
mount. The nilfs_salvage_orphan_logs routine dirties the buffer of
salvaged data before attaching the log writer, so changing
__nilfs_mark_inode_dirty() to skip the operation when ns_writer is NULL
will cause recovery write to fail. The purpose of using the cleanup-only
flag is to allow for narrowing of such conditions.
Link: https://lkml.kernel.org/r/20230728191318.33047-1-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Reported-by: syzbot+74db8b3087f293d3a13a@syzkaller.appspotmail.com
Closes: https://lkml.kernel.org/r/000000000000b4e906060113fd63@google.com
Fixes: 0ae45f63d4ef ("vfs: add support for a lazytime mount option")
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org> # 4.0+
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-07-29 04:13:18 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 18:35:49 -07:00
|
|
|
|
|
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
|
|
|
|
|
2011-03-09 11:05:07 +09:00
|
|
|
|
nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput
During unmount process of nilfs2, nothing holds nilfs_root structure after
nilfs2 detaches its writer in nilfs_detach_log_writer(). Previously,
nilfs_evict_inode() could cause use-after-free read for nilfs_root if
inodes are left in "garbage_list" and released by nilfs_dispose_list at
the end of nilfs_detach_log_writer(), and this bug was fixed by commit
9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in
nilfs_evict_inode()").
However, it turned out that there is another possibility of UAF in the
call path where mark_inode_dirty_sync() is called from iput():
nilfs_detach_log_writer()
nilfs_dispose_list()
iput()
mark_inode_dirty_sync()
__mark_inode_dirty()
nilfs_dirty_inode()
__nilfs_mark_inode_dirty()
nilfs_load_inode_block() --> causes UAF of nilfs_root struct
This can happen after commit 0ae45f63d4ef ("vfs: add support for a
lazytime mount option"), which changed iput() to call
mark_inode_dirty_sync() on its final reference if i_state has I_DIRTY_TIME
flag and i_nlink is non-zero.
This issue appears after commit 28a65b49eb53 ("nilfs2: do not write dirty
data after degenerating to read-only") when using the syzbot reproducer,
but the issue has potentially existed before.
Fix this issue by adding a "purging flag" to the nilfs structure, setting
that flag while disposing the "garbage_list" and checking it in
__nilfs_mark_inode_dirty().
Unlike commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root
in nilfs_evict_inode()"), this patch does not rely on ns_writer to
determine whether to skip operations, so as not to break recovery on
mount. The nilfs_salvage_orphan_logs routine dirties the buffer of
salvaged data before attaching the log writer, so changing
__nilfs_mark_inode_dirty() to skip the operation when ns_writer is NULL
will cause recovery write to fail. The purpose of using the cleanup-only
flag is to allow for narrowing of such conditions.
Link: https://lkml.kernel.org/r/20230728191318.33047-1-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Reported-by: syzbot+74db8b3087f293d3a13a@syzkaller.appspotmail.com
Closes: https://lkml.kernel.org/r/000000000000b4e906060113fd63@google.com
Fixes: 0ae45f63d4ef ("vfs: add support for a lazytime mount option")
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org> # 4.0+
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-07-29 04:13:18 +09:00
|
|
|
|
2009-04-06 19:01:37 -07:00
|
|
|
|
