From: Dileep Sankhla <dileepsankhla.ds@gmail.com>
To: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: on solving syzkaller bug in __filemap_add_folio function
Date: Thu, 6 Nov 2025 15:41:52 +0530 [thread overview]
Message-ID: <CAHxc4bug3HOPd1i2coqyJz_gRNGyeCpqiYo0UWV-w6cAAtD5KQ@mail.gmail.com> (raw)
Hello everyone,
I am solving my first kernel bug. As far as I understood, the
syzkaller bug I am solving (please see [0] below) is about a crash
during synchronous readahead when the folio order of the allocated
folio is less than the mapping's minimum folio order. On debugging, I
found out that the folio order was greater than or equal to the
minimum order when the readahead was initiated, but the minimum order
somehow changed (increased) while the readahead was in progress.
Actually the set_blocksize() function (inside file block/bdev.c) is
setting the new value for minimum order. This function was called as
the result of handling ioctl() system call invoked from the C
reproducer.
Both readahead and changing minimum order are done under
mapping->invalidate_lock (readahead acquires it in read mode and
set_blocksize() acquires it in write mode). In my patch [2] tested
against the upstream commit [1] taken from the syzkaller crashes,
during readahead, I am acquiring the lock first before initializing
the min_order variable with mapping's minimum folio order. This solves
the original syzkaller bug but another crash [3] occurs after running
the C repro for a while. Actually this crash occurs in
__readahead_folio() function (file include/linux/pagemap.h):
BUG_ON(ractl->_batch_count > ractl->_nr_pages);
The condition is being true during runtime. From what I understood, it
is impossible to have the current batch greater than the number of
pages in a readahead request. This means we are somehow altering the
current readahead request improperly somewhere in the code. How to go
about this bug?
P.S. The same crash was reported as another syzkaller bug [4] (kernel
BUG in mpage_readahead), however, its call trace is different.
Best Regards,
Dileep
Links:
[0]: https://syzkaller.appspot.com/bug?extid=4d3cc33ef7a77041efa6
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9dd1835ecda5b96ac88c166f4a87386f3e727bd9
[2]: https://syzkaller.appspot.com/text?tag=Patch&x=103ee342580000
[3]: https://syzkaller.appspot.com/x/report.txt?x=14cdc114580000
[4]: https://syzkaller.appspot.com/bug?extid=fdba5cca73fee92c69d6
reply other threads:[~2025-11-06 10:05 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHxc4bug3HOPd1i2coqyJz_gRNGyeCpqiYo0UWV-w6cAAtD5KQ@mail.gmail.com \
--to=dileepsankhla.ds@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).