All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>,
	Anand Jain <anand.jain@oracle.com>,
	linux-btrfs@vger.kernel.org
Cc: dsterba@suse.cz
Subject: Re: [PATCH 2/4] btrfs: stop using uninitiazlised fs_info in device_list_add()
Date: Tue, 14 Jan 2020 09:30:05 +0200	[thread overview]
Message-ID: <c5987d03-ef3a-e36c-4e45-94605d02888a@suse.com> (raw)
In-Reply-To: <9c548a6f-dc44-72f5-0d92-855af2e22b68@gmx.com>



On 14.01.20 г. 8:58 ч., Qu Wenruo wrote:
> 
> 
> On 2020/1/14 下午2:09, Anand Jain wrote:
>> fs_info is born during mount, and operations before the mount such as
>> scanning and assembling of the device volume should happen without any
>> reference to fs_info.
>>
>> However the patch commit a9261d4125c9 (btrfs: harden agaist duplicate
>> fsid on scanned devices) used fs_info to call btrfs_warn_in_rcu() and
>> btrfs_info_in_rcu(), so if fs_info is NULL, the stacked functions which
>> leads to btrfs_printk() which shall print "unknown" instead of sb->s_id.
>> Or even might UAF as reported in [1].
> 
> With your previous patch, which already checked NULL pointer, I didn't
> see the need for NO_FS_INFO.
> 
> Or do you believe this calling site is a special?
> If so, I still didn't get the point of NO_FS_INFO, just extra lines
> using __func__ or "during scan: xxxxx" looks enough to me.

I agree with this assessment. What value does NO_FS_INFO bring in
comparison to plain NULL that it warrants a special case?

> 
> Thanks,
> Qu
> 

  reply	other threads:[~2020-01-14  7:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14  6:09 [PATCH 1/4] btrfs: add NO_FS_INFO to btrfs_printk Anand Jain
2020-01-14  6:09 ` [PATCH 2/4] btrfs: stop using uninitiazlised fs_info in device_list_add() Anand Jain
2020-01-14  6:58   ` Qu Wenruo
2020-01-14  7:30     ` Nikolay Borisov [this message]
2020-01-14  6:09 ` [PATCH 3/4] btrfs: make the scan logs consistent Anand Jain
2020-01-14  6:09 ` [PATCH 4/4] btrfs: use btrfs consistent logging wrappers Anand Jain
2020-01-14  6:54 ` [PATCH 1/4] btrfs: add NO_FS_INFO to btrfs_printk Qu Wenruo
2020-01-14  7:21   ` Anand Jain
2020-01-14  7:31     ` Nikolay Borisov
2020-01-14  7:33     ` Qu Wenruo
2020-01-22 15:50     ` David Sterba
2020-01-23  7:22       ` Anand Jain
2020-02-03  4:06         ` Anand Jain

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=c5987d03-ef3a-e36c-4e45-94605d02888a@suse.com \
    --to=nborisov@suse.com \
    --cc=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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 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.