public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Christoph Hellwig <hch@infradead.org>,
	syzbot <syzbot+4f1a237abaf14719db49@syzkaller.appspotmail.com>,
	axboe@kernel.dk, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
	Jan Kara <jack@suse.cz>
Subject: Re: [syzbot] INFO: task can't die in blkdev_common_ioctl
Date: Mon, 4 Apr 2022 23:44:22 -0700	[thread overview]
Message-ID: <YkvlRnO3Ho/mrk0V@infradead.org> (raw)
In-Reply-To: <67179a84-8be7-4c93-e355-2ca50666f960@I-love.SAKURA.ne.jp>

On Mon, Apr 04, 2022 at 02:12:14PM +0900, Tetsuo Handa wrote:
> On 2022/04/04 13:58, Christoph Hellwig wrote:
> > all, as it does not come through blkdev_fallocate.
> 
> My patch proposes filemap_invalidate_lock_killable() and converts only
> blkdev_fallocate() case as a starting point. Nothing prevents us from
> converting e.g. blk_ioctl_zeroout() case as well. The "not come through
> blkdev_fallocate" is bogus.

Sure, we could try to convert most of the > 50 instances of
filemap_invalidate_lock to be killable.  But that:

  a) isn't what your patch actuall did
  b) doesn't solve the underlying issue that is wasn't designed to to be
     held over very extremely long running operations

Or to get back to what I said before - I don't think we can just hold
the lock over manually zeroing potentially gigabytes of blocks.

In other words:  we'll need to chunk the zeroing up if we want
to hold the invalidate lock, I see no ther way to properly fix this.

  reply	other threads:[~2022-04-05  6:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-02  7:20 [syzbot] INFO: task can't die in blkdev_common_ioctl syzbot
2022-04-02 11:26 ` Tetsuo Handa
2022-04-04  4:58   ` Christoph Hellwig
2022-04-04  5:12     ` Tetsuo Handa
2022-04-05  6:44       ` Christoph Hellwig [this message]
2022-04-05 13:15         ` Tetsuo Handa

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=YkvlRnO3Ho/mrk0V@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=syzbot+4f1a237abaf14719db49@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /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