From: Christoph Hellwig <hch@lst.de>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@lst.de>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Hannes Reinecke <hare@suse.de>, Jens Axboe <axboe@kernel.dk>,
Tejun Heo <tj@kernel.org>,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH kernel] block: initialize block_device::bd_bdi for bdev_cache
Date: Thu, 7 Jan 2021 08:48:12 +0100 [thread overview]
Message-ID: <20210107074812.GA1089@lst.de> (raw)
In-Reply-To: <5e6716a6-0314-8360-4fb6-5c959022a24c@ozlabs.ru>
On Thu, Jan 07, 2021 at 10:58:39AM +1100, Alexey Kardashevskiy wrote:
>> And AFAICT the root inode on
>> bdev superblock can get only to bdev_evict_inode() and bdev_free_inode().
>> Looking at bdev_evict_inode() the only thing that's used there from struct
>> block_device is really bd_bdi. bdev_free_inode() will also access
>> bdev->bd_stats and bdev->bd_meta_info. So we need to at least initialize
>> these to NULL as well.
>
> These are all NULL.
>
>> IMO the most logical place for all these
>> initializations is in bdev_alloc_inode()...
>
>
> This works. We can also check for NULL where it crashes. But I do not know
> the code to make an informed decision...
The root inode is the special case, so I think moving the the initializers
for everything touched in ->evict_inode and ->free_inode to
bdev_alloc_inode makes most sense.
Alexey, do you want to respin or should I send a patch?
next prev parent reply other threads:[~2021-01-07 7:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 9:29 [RFC PATCH kernel] block: initialize block_device::bd_bdi for bdev_cache Alexey Kardashevskiy
2021-01-06 10:41 ` Jan Kara
2021-01-06 23:58 ` Alexey Kardashevskiy
2021-01-07 7:48 ` Christoph Hellwig [this message]
2021-01-07 8:24 ` Alexey Kardashevskiy
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=20210107074812.GA1089@lst.de \
--to=hch@lst.de \
--cc=aik@ozlabs.ru \
--cc=axboe@kernel.dk \
--cc=hare@suse.de \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 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.