All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Nikolay Borisov <nborisov@suse.com>,
	dsterba@suse.cz, Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: Validate child tree block's level and first key
Date: Thu, 22 Mar 2018 22:26:08 +0800	[thread overview]
Message-ID: <fd2e2920-afcc-6bcf-77bf-17380252524b@gmx.com> (raw)
In-Reply-To: <47bb1e1a-97f2-817c-7b80-6190cc5da18e@suse.com>


[-- Attachment #1.1: Type: text/plain, Size: 2867 bytes --]



On 2018年03月22日 22:20, Nikolay Borisov wrote:
> 
> 
> On 22.03.2018 16:17, Qu Wenruo wrote:
>>
>>
>> On 2018年03月22日 22:00, David Sterba wrote:
>>> On Thu, Mar 22, 2018 at 09:53:46PM +0800, Qu Wenruo wrote:
>>>>>> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
>>>>>> index 26484648d090..3866b8ab20f1 100644
>>>>>> --- a/fs/btrfs/backref.c
>>>>>> +++ b/fs/btrfs/backref.c
>>>>>> @@ -738,7 +738,8 @@ static int add_missing_keys(struct btrfs_fs_info *fs_info,
>>>>>>  		BUG_ON(ref->key_for_search.type);
>>>>>>  		BUG_ON(!ref->wanted_disk_byte);
>>>>>>  
>>>>>> -		eb = read_tree_block(fs_info, ref->wanted_disk_byte, 0);
>>>>>> +		eb = read_tree_block(fs_info, ref->wanted_disk_byte, 0, NULL,
>>>>>> +				     0);
>>>>>
>>>>> Please add 2nd function that will take the extended parameters and
>>>>> keep read_tree_block as is.
>>>>
>>>> So for any new caller of read_tree_block(), reviewer is the last person
>>>> to info the author to use these parameters for safety check?
>>>>
>>>> And in fact, the old function should be avoid if possible, I think the
>>>> new parameters act as a pretty good sign to make any caller double think
>>>> about this.
>>>
>>> I saw half of the new parameters were just 0, NULL, so this looks like a
>>> lot of code churn and I haven't looked closer if there's a chance to
>>> fill the parameters in all callsites. So if it's a matter of adding them
>>> incrementally then fine.
>>>
>> I'm afraid some of the call sites (ones I left with NULL, 0) are unable
>> to pass the new parameters by its nature.
>>
>> Such callers include:
>> 1) Tree root
>>    Just @bytenr and @gen from ROOT_ITEM. No @first_key.
>>
>> 2) Backref walker for FULL_BACKREF
>>    Only parent bytenr, no extra info on @first_key.
>>
>> But despite of such call sites, every top-down reader should grab first
>> key and level. (And so I did in the patch).
>>
>> BTW, about half of the read_tree_block() callers are using the new
>> parameters.
>> So a new function seems a little embarrassing here.
> 
> 
> Is it possible to centralise those checks in the read tree verifier,
> rather than sprinkling them around the code?

The problem is, tree checker can only handle things *inside* a
leaf/node, nothing can go beyond leaf/node boundary.

And for current check, we need a top-down pointer (nodeptr, which has
bytenr, generation, first key along with the level) to do the
verification, so that's the reason we can't put it into tree-checker.

(Sorry I forgot to add this explanation, and I didn't find better solution)

Thanks,
Qu

> 
>>
>> Thanks,
>> Qu
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

  reply	other threads:[~2018-03-22 14:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-19  9:18 [PATCH] btrfs: Validate child tree block's level and first key Qu Wenruo
2018-03-19 22:59 ` kbuild test robot
2018-03-20 10:57 ` kbuild test robot
2018-03-22 12:12 ` Nikolay Borisov
2018-03-22 12:15   ` Qu Wenruo
2018-03-22 13:40 ` David Sterba
2018-03-22 13:53   ` Qu Wenruo
2018-03-22 14:00     ` David Sterba
2018-03-22 14:17       ` Qu Wenruo
2018-03-22 14:20         ` Nikolay Borisov
2018-03-22 14:26           ` Qu Wenruo [this message]
2018-03-22 14:41             ` Nikolay Borisov

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=fd2e2920-afcc-6bcf-77bf-17380252524b@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=wqu@suse.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.