[ Upstream commit 3f034c374ad55773c12dd8f3c1607328e17c0072 ]
Reordered a check to avoid a possible overflow when adding len to bv_len.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Link: https://lore.kernel.org/r/20231204173419.782378-2-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1b151e2435fc3a9b10c8946c6aebe9f3e1938c55 upstream.
The special casing was originally added in pre-git history; reproducing
the commit log here:
> commit a318a92567d77
> Author: Andrew Morton <akpm@osdl.org>
> Date: Sun Sep 21 01:42:22 2003 -0700
>
> [PATCH] Speed up direct-io hugetlbpage handling
>
> This patch short-circuits all the direct-io page dirtying logic for
> higher-order pages. Without this, we pointlessly bounce BIOs up to
> keventd all the time.
In the last twenty years, compound pages have become used for more than
just hugetlb. Rewrite these functions to operate on folios instead
of pages and remove the special case for hugetlbfs; I don't think
it's needed any more (and if it is, we can put it back in as a call
to folio_test_hugetlb()).
This was found by inspection; as far as I can tell, this bug can lead
to pages used as the destination of a direct I/O read not being marked
as dirty. If those pages are then reclaimed by the MM without being
dirtied for some other reason, they won't be written out. Then when
they're faulted back in, they will not contain the data they should.
It'll take a pretty unusual setup to produce this problem with several
races all going the wrong way.
This problem predates the folio work; it could for example have been
triggered by mmaping a THP in tmpfs and using that as the target of an
O_DIRECT read.
Fixes: 800d8c63b2e98 ("shmem: add huge pages support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 27b13e209ddca5979847a1b57890e0372c1edcee ]
Inside blkg_for_each_descendant_pre(), both
css_for_each_descendant_pre() and blkg_lookup() requires RCU read lock,
and either cgroup_assert_mutex_or_rcu_locked() or rcu_read_lock_held()
is called.
Fix the warning by adding rcu read lock.
Reported-by: Changhui Zhong <czhong@redhat.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20231117023527.3188627-2-ming.lei@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Flash memory is extremely latency efficient, so we can make the maximum
target latency 1ms. Anything exceeding 1ms of latency will cause
blk-throttle to trigger.
Signed-off-by: Tyler Nijmeh <tylernij@gmail.com>
Signed-off-by: John Vincent <git@tensevntysevn.cf>
Signed-off-by: ThunderStorms21th <pinakastorm@gmail.com>
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
(cherry picked from commit 4d3c7baa4acb5fa3b238dde267826254788e86e5)
(cherry picked from commit 6e658026fe20dc1d651c5f4a56afd363a3195f42)
(cherry picked from commit 2ce27817f2fa8e4bbd3420b2f6c050d404703efc)
(cherry picked from commit 85c200268a4bd8b9ad639991bdaf233ba14f6ade)
(cherry picked from commit 35ab17dbef37e36630d542dce420dc3ac6467d74)
(cherry picked from commit 77662095632a51547ca5f921ec453802788d58ee)
(cherry picked from commit 46e2b47e9560de0877079c8a5db0f5ae742133c4)
(cherry picked from commit d12b3702c6e03ac84d399d41e2859b24e8630dea)
(cherry picked from commit 79be04236891dcd6e5e87a25626a64d6d0d0a42f)
(cherry picked from commit c85b5a7d9c215ca4dc35e894149523b33409fd40)
If we attempt a direct issue to a SCSI device, and it returns BUSY, then
we queue the request up normally. However, the SCSI layer may have
already setup SG tables etc for this particular command. If we later
merge with this request, then the old tables are no longer valid. Once
we issue the IO, we only read/write the original part of the request,
not the new state of it.
This causes data corruption, and is most often noticed with the file
system complaining about the just read data being invalid:
[ 235.934465] EXT4-fs error (device sda1): ext4_iget:4831: inode #7142: comm dpkg-query: bad extra_isize 24937 (inode size 256)
because most of it is garbage...
This doesn't happen from the normal issue path, as we will simply defer
the request to the hardware queue dispatch list if we fail. Once it's on
the dispatch list, we never merge with it.
Fix this from the direct issue path by flagging the request as
REQ_NOMERGE so we don't change the size of it before issue.
See also:
https://bugzilla.kernel.org/show_bug.cgi?id=201685
Tested-by: Guenter Roeck <linux@roeck-us.net>
Fixes: 6ce3dd6eec1 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Adam W. Willis <return.of.octobot@gmail.com>
(cherry picked from commit 9a897ce1d5b6611daa27bf00fcfb5c97a3d826b4)
(cherry picked from commit 66af19f52cf6d2a9deef8de2f451604d49ef42f1)
Testing:
[ElectroPerf & resist15]
In testing we found out that there were significant improvements
in the sequential read and write speeds. Some screenshots of the tests are below:
Before: https://i.imgur.com/UBL74X2.jpg
After: https://i.imgur.com/CrkD5iE.jpg
Change-Id: Idd7f5c7df0a7fc1535555927923491ecb39bc6a9
[Tashar02: Apply patch on kernel]
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
We this to access task_is_booster().
ld.lld: error: undefined symbol: task_is_booster
>>> referenced by elevator.c:774 (../block/elevator.c:774)
>>> vmlinux.o:(elv_iosched_store)
>>> did you mean: task_is_booster
>>> defined in: vmlinux.o
Signed-off-by: Nahuel Gómez <nahuelgomez329@gmail.com>
