From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> To: Christoph Hellwig <email@example.com> Cc: Alexander Viro <firstname.lastname@example.org>, Jens Axboe <email@example.com>, firstname.lastname@example.org, linux-fsdevel <email@example.com> Subject: Re: [PATCH] block: add filemap_invalidate_lock_killable() Date: Sat, 12 Feb 2022 17:28:09 +0900 [thread overview] Message-ID: <cf0d2a39-3301-ecc6-12b5-e8e204812c71@I-love.SAKURA.ne.jp> (raw) In-Reply-To: <8b2a61cb-4850-8bd7-3ff3-cebebefdb01b@I-love.SAKURA.ne.jp> On 2022/01/04 22:26, Tetsuo Handa wrote: > On 2022/01/04 16:14, Christoph Hellwig wrote: >> On Mon, Jan 03, 2022 at 07:49:11PM +0900, Tetsuo Handa wrote: >>> syzbot is reporting hung task at blkdev_fallocate() , for it can take >>> minutes with mapping->invalidate_lock held. Since fallocate() has to accept >>> size > MAX_RW_COUNT bytes, we can't predict how long it will take. Thus, >>> mitigate this problem by using killable wait where possible. >> >> Well, but that also means we want all other users of the invalidate_lock >> to be killable, as fallocate vs fallocate synchronization is probably >> not the interesting case. > > Right. But being responsive to SIGKILL is generally preferable. > > syzbot (and other syzkaller based fuzzing) is reporting many hung task reports, > but many of such reports are simply overstressing. > > We can't use killable lock wait for release operation because it is a "void" > function. But we can use killable lock wait for majority of operations which > are not "void" functions. Use of killable lock wait where possible can improve > situation. > If there is no alternative, can we apply this patch?
next prev parent reply other threads:[~2022-02-12 8:28 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-03 9:11 [syzbot] INFO: task hung in blkdev_fallocate syzbot 2022-01-03 10:49 ` [PATCH] block: add filemap_invalidate_lock_killable() Tetsuo Handa 2022-01-04 7:14 ` Christoph Hellwig 2022-01-04 13:26 ` Tetsuo Handa 2022-02-12 8:28 ` Tetsuo Handa [this message] 2022-02-14 8:17 ` Christoph Hellwig
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=cf0d2a39-3301-ecc6-12b5-e8e204812c71@I-love.SAKURA.ne.jp \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] block: add filemap_invalidate_lock_killable()' \ /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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.