RE: [PATCH v2 1/2] btrfs: Check each block group has corresponding chunk at mount time
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org
> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Qu Wenruo
> Sent: Friday, July 06, 2018 1:36 PM
> To: linux-btrfs@vger.kernel.org
> Subject: [PATCH v2 1/2] btrfs: Check each block group has corresponding chunk
> at mount time
>
> A crafted btrfs with incorrect chunk<->block group mapping, it could leads
> to a lot of unexpected behavior.
>
> Although the crafted image can be catched by block group item checker
> added in "[PATCH] btrfs: tree-checker: Verify block_group_item", if one
> crafted a valid enough block group item which can pass above check but
> still mismatch with existing chunk, it could cause a lot of undefined
> behavior.
>
> This patch will add extra block group -> chunk mapping check, to ensure
> we have a completely matching (start, len, flags) chunk for each block
> group at mount time.
>
> Here we reuse the original find_first_block_group(), which is already
> doing basic bg -> chunk check, adding more check on start/len and type
> flags.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=199837
> Reported-by: Xu Wen
> Signed-off-by: Qu Wenruo
> ---
> changelog:
> v2:
> Reuse existing find_first_block_group() to do the verification,
> pointed out by Gu.
> ---
> fs/btrfs/extent-tree.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 3d9fe58c0080..63a6b5d36ac1 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -9717,6 +9717,8 @@ static int find_first_block_group(struct btrfs_fs_info
> *fs_info,
> int ret = 0;
> struct btrfs_key found_key;
> struct extent_buffer *leaf;
> + struct btrfs_block_group_item bg;
> + u64 flags;
> int slot;
>
> ret = btrfs_search_slot(NULL, root, key, path, 0, 0);
> @@ -9751,8 +9753,33 @@ static int find_first_block_group(struct btrfs_fs_info
> *fs_info,
> "logical %llu len %llu found bg but no related chunk",
> found_key.objectid, found_key.offset);
> ret = -ENOENT;
> + } else if (em->start != found_key.objectid ||
> +em->len != found_key.offset) {
> + btrfs_err(fs_info,
> + "block group %llu len %llu mismatch with chunk %llu len %llu",
> + found_key.objectid, found_key.offset,
> + em->start, em->len);
> + ret = -EUCLEAN;
> } else {
> - ret = 0;
> + read_extent_buffer(leaf, ,
> + btrfs_item_ptr_offset(leaf, slot),
> + sizeof(bg));
> + flags = btrfs_block_group_flags() &
> + BTRFS_BLOCK_GROUP_TYPE_MASK;
> +
> + if (flags != (em->map_lookup->type &
> + BTRFS_BLOCK_GROUP_TYPE_MASK)) {
> + btrfs_err(fs_info,
> +"block group %llu len %llu type flags 0x%llx mismatch with chunk type flags
> 0x%llx",
> + found_key.objectid,
> + found_key.offset,
> + flags,
> + (BTRFS_BLOCK_GROUP_TYPE_MASK &
> + em->map_lookup->type));
> + ret = -EUCLEAN;
> + } else {
> + ret = 0;
> + }
> }
> free_extent_map(em);
> goto out;
> --
Reviewed-by: Gu Jinxiang
> 2.18.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{�n谶�)��骅w* jg�报 �茛j/�赇z罐���2���ㄨ��&�)摺�a囤�� �G���h��j:+v���w��佶
Re: [PATCH v2 1/2] btrfs: Check each block group has corresponding chunk at mount time
On Tue, Jul 03, 2018 at 12:08:02PM +0300, Nikolay Borisov wrote: > >> Also for evry patch which fixes a specific issue from one of the > >> reported on bugzilla.kernel.org just use the Link: tag to point to the > >> original report on bugzilla that will make it easier to relate the > >> fixes to the original report. > > > > Never heard of "Link:" tag. > > Maybe it's a good idea to added it to "submitting-patches.rst"? > > I guess it's not officially documented but if you do git log --grep > "Link:" you'd see quite a lot of patches actually have a Link pointing > to the original thread if it has sparked some pertinent discussion. In > this case those patches are a direct result of a bugzilla bugreport so > having a Link: tag makes sense. The tag section of the commit has some predefined tags that could be somehow "legally binding" like the Signed-off, other can help to gather statistics about the devlopment process (reviewed, reported, tested) and the rest is basically free-form that should make sense to a human reader. So Link: or Bugzilla: would work. There were suggestions to formalize the links to email discussions but there was also opposition to formalize too much. Also, the important bits should be in the changelog as the mail archives are volatile as we've seen already. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] btrfs: Check each block group has corresponding chunk at mount time
On Tue, Jul 03, 2018 at 08:58:05PM +0200, Martin Steigerwald wrote: > Nikolay Borisov - 03.07.18, 11:08: > > On 3.07.2018 11:47, Qu Wenruo wrote: > > > On 2018年07月03日 16:33, Nikolay Borisov wrote: > > >> On 3.07.2018 11:08, Qu Wenruo wrote: > > >>> Reported in https://bugzilla.kernel.org/show_bug.cgi?id=199837, if > > >>> a > > >>> crafted btrfs with incorrect chunk<->block group mapping, it could > > >>> leads to a lot of unexpected behavior. > > >>> > > >>> Although the crafted image can be catched by block group item > > >>> checker > > >>> added in "[PATCH] btrfs: tree-checker: Verify block_group_item", > > >>> if one crafted a valid enough block group item which can pass > > >>> above check but still mismatch with existing chunk, it could > > >>> cause a lot of undefined behavior. > > >>> > > >>> This patch will add extra block group -> chunk mapping check, to > > >>> ensure we have a completely matching (start, len, flags) chunk > > >>> for each block group at mount time. > > >>> > > >>> Reported-by: Xu Wen > > >>> Signed-off-by: Qu Wenruo > > >>> --- > > >>> changelog: > > >>> > > >>> v2: > > >>> Add better error message for each mismatch case. > > >>> Rename function name, to co-operate with later patch. > > >>> Add flags mismatch check. > > >>> > > >>> --- > > >> > > >> It's getting really hard to keep track of the various validation > > >> patches you sent with multiple versions + new checks. Please batch > > >> everything in a topic series i.e "Making checks stricter" or some > > >> such and send everything again nicely packed, otherwise the risk > > >> of mis-merging is increased. > > > > > > Indeed, I'll send the branch and push it to github. > > > > > >> I now see that Gu Jinxiang from fujitsu also started sending > > >> validation fixes. > > > > > > No need to worry, that will be the only patch related to that thread > > > of bugzilla from Fujitsu. > > > As all the other cases can be addressed by my patches, sorry Fujitsu > > > guys :)> > > >> Also for evry patch which fixes a specific issue from one of the > > >> reported on bugzilla.kernel.org just use the Link: tag to point to > > >> the original report on bugzilla that will make it easier to relate > > >> the fixes to the original report. > > > > > > Never heard of "Link:" tag. > > > Maybe it's a good idea to added it to "submitting-patches.rst"? > > > > I guess it's not officially documented but if you do git log --grep > > "Link:" you'd see quite a lot of patches actually have a Link pointing > > to the original thread if it has sparked some pertinent discussion. > > In this case those patches are a direct result of a bugzilla > > bugreport so having a Link: tag makes sense. > > For Bugzilla reports I saw something like > > Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43511 > > in a patch I was Cc´d to. > > Of course that does only apply if the patch in question fixes the > reported bug. The tag 'Fixes:' already has some meaning and should point to the commit id and subject of a patch that it fixes. The stable team and its bots/filters recognize this flag and this helps maintainers to forward patches to the stable trees. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] btrfs: Check each block group has corresponding chunk at mount time
Nikolay Borisov - 03.07.18, 11:08: > On 3.07.2018 11:47, Qu Wenruo wrote: > > On 2018年07月03日 16:33, Nikolay Borisov wrote: > >> On 3.07.2018 11:08, Qu Wenruo wrote: > >>> Reported in https://bugzilla.kernel.org/show_bug.cgi?id=199837, if > >>> a > >>> crafted btrfs with incorrect chunk<->block group mapping, it could > >>> leads to a lot of unexpected behavior. > >>> > >>> Although the crafted image can be catched by block group item > >>> checker > >>> added in "[PATCH] btrfs: tree-checker: Verify block_group_item", > >>> if one crafted a valid enough block group item which can pass > >>> above check but still mismatch with existing chunk, it could > >>> cause a lot of undefined behavior. > >>> > >>> This patch will add extra block group -> chunk mapping check, to > >>> ensure we have a completely matching (start, len, flags) chunk > >>> for each block group at mount time. > >>> > >>> Reported-by: Xu Wen > >>> Signed-off-by: Qu Wenruo > >>> --- > >>> changelog: > >>> > >>> v2: > >>> Add better error message for each mismatch case. > >>> Rename function name, to co-operate with later patch. > >>> Add flags mismatch check. > >>> > >>> --- > >> > >> It's getting really hard to keep track of the various validation > >> patches you sent with multiple versions + new checks. Please batch > >> everything in a topic series i.e "Making checks stricter" or some > >> such and send everything again nicely packed, otherwise the risk > >> of mis-merging is increased. > > > > Indeed, I'll send the branch and push it to github. > > > >> I now see that Gu Jinxiang from fujitsu also started sending > >> validation fixes. > > > > No need to worry, that will be the only patch related to that thread > > of bugzilla from Fujitsu. > > As all the other cases can be addressed by my patches, sorry Fujitsu > > guys :)> > >> Also for evry patch which fixes a specific issue from one of the > >> reported on bugzilla.kernel.org just use the Link: tag to point to > >> the original report on bugzilla that will make it easier to relate > >> the fixes to the original report. > > > > Never heard of "Link:" tag. > > Maybe it's a good idea to added it to "submitting-patches.rst"? > > I guess it's not officially documented but if you do git log --grep > "Link:" you'd see quite a lot of patches actually have a Link pointing > to the original thread if it has sparked some pertinent discussion. > In this case those patches are a direct result of a bugzilla > bugreport so having a Link: tag makes sense. For Bugzilla reports I saw something like Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43511 in a patch I was Cc´d to. Of course that does only apply if the patch in question fixes the reported bug. > In the example of the qgroup patch I sent yesterday resulting from > Misono's report there was also an involved discussion hence I added a > link to the original thread. […] -- Martin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] btrfs: Check each block group has corresponding chunk at mount time
On 3.07.2018 11:47, Qu Wenruo wrote: > > > On 2018年07月03日 16:33, Nikolay Borisov wrote: >> >> >> On 3.07.2018 11:08, Qu Wenruo wrote: >>> Reported in https://bugzilla.kernel.org/show_bug.cgi?id=199837, if a >>> crafted btrfs with incorrect chunk<->block group mapping, it could leads >>> to a lot of unexpected behavior. >>> >>> Although the crafted image can be catched by block group item checker >>> added in "[PATCH] btrfs: tree-checker: Verify block_group_item", if one >>> crafted a valid enough block group item which can pass above check but >>> still mismatch with existing chunk, it could cause a lot of undefined >>> behavior. >>> >>> This patch will add extra block group -> chunk mapping check, to ensure >>> we have a completely matching (start, len, flags) chunk for each block >>> group at mount time. >>> >>> Reported-by: Xu Wen >>> Signed-off-by: Qu Wenruo >>> --- >>> changelog: >>> v2: >>> Add better error message for each mismatch case. >>> Rename function name, to co-operate with later patch. >>> Add flags mismatch check. >>> --- >> >> It's getting really hard to keep track of the various validation patches >> you sent with multiple versions + new checks. Please batch everything in >> a topic series i.e "Making checks stricter" or some such and send >> everything again nicely packed, otherwise the risk of mis-merging is >> increased. > > Indeed, I'll send the branch and push it to github. > >> I now see that Gu Jinxiang from fujitsu also started sending >> validation fixes. > > No need to worry, that will be the only patch related to that thread of > bugzilla from Fujitsu. > As all the other cases can be addressed by my patches, sorry Fujitsu guys :) > >> Also for evry patch which fixes a specific issue from one of the >> reported on bugzilla.kernel.org just use the Link: tag to point to the >> original report on bugzilla that will make it easier to relate the >> fixes to the original report. > > Never heard of "Link:" tag. > Maybe it's a good idea to added it to "submitting-patches.rst"? I guess it's not officially documented but if you do git log --grep "Link:" you'd see quite a lot of patches actually have a Link pointing to the original thread if it has sparked some pertinent discussion. In this case those patches are a direct result of a bugzilla bugreport so having a Link: tag makes sense. In the example of the qgroup patch I sent yesterday resulting from Misono's report there was also an involved discussion hence I added a link to the original thread. > > Thanks, > Qu > >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] btrfs: Check each block group has corresponding chunk at mount time
On 2018年07月03日 16:33, Nikolay Borisov wrote: > > > On 3.07.2018 11:08, Qu Wenruo wrote: >> Reported in https://bugzilla.kernel.org/show_bug.cgi?id=199837, if a >> crafted btrfs with incorrect chunk<->block group mapping, it could leads >> to a lot of unexpected behavior. >> >> Although the crafted image can be catched by block group item checker >> added in "[PATCH] btrfs: tree-checker: Verify block_group_item", if one >> crafted a valid enough block group item which can pass above check but >> still mismatch with existing chunk, it could cause a lot of undefined >> behavior. >> >> This patch will add extra block group -> chunk mapping check, to ensure >> we have a completely matching (start, len, flags) chunk for each block >> group at mount time. >> >> Reported-by: Xu Wen >> Signed-off-by: Qu Wenruo >> --- >> changelog: >> v2: >> Add better error message for each mismatch case. >> Rename function name, to co-operate with later patch. >> Add flags mismatch check. >> --- > > It's getting really hard to keep track of the various validation patches > you sent with multiple versions + new checks. Please batch everything in > a topic series i.e "Making checks stricter" or some such and send > everything again nicely packed, otherwise the risk of mis-merging is > increased. Indeed, I'll send the branch and push it to github. > I now see that Gu Jinxiang from fujitsu also started sending > validation fixes. No need to worry, that will be the only patch related to that thread of bugzilla from Fujitsu. As all the other cases can be addressed by my patches, sorry Fujitsu guys :) > Also for evry patch which fixes a specific issue from one of the > reported on bugzilla.kernel.org just use the Link: tag to point to the > original report on bugzilla that will make it easier to relate the > fixes to the original report. Never heard of "Link:" tag. Maybe it's a good idea to added it to "submitting-patches.rst"? Thanks, Qu > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] btrfs: Check each block group has corresponding chunk at mount time
On 3.07.2018 11:33, Nikolay Borisov wrote: > > > On 3.07.2018 11:08, Qu Wenruo wrote: >> Reported in https://bugzilla.kernel.org/show_bug.cgi?id=199837, if a >> crafted btrfs with incorrect chunk<->block group mapping, it could leads >> to a lot of unexpected behavior. >> >> Although the crafted image can be catched by block group item checker >> added in "[PATCH] btrfs: tree-checker: Verify block_group_item", if one >> crafted a valid enough block group item which can pass above check but >> still mismatch with existing chunk, it could cause a lot of undefined >> behavior. >> >> This patch will add extra block group -> chunk mapping check, to ensure >> we have a completely matching (start, len, flags) chunk for each block >> group at mount time. >> >> Reported-by: Xu Wen >> Signed-off-by: Qu Wenruo >> --- >> changelog: >> v2: >> Add better error message for each mismatch case. >> Rename function name, to co-operate with later patch. >> Add flags mismatch check. >> --- > > It's getting really hard to keep track of the various validation patches > you sent with multiple versions + new checks. Please batch everything in > a topic series i.e "Making checks stricter" or some such and send > everything again nicely packed, otherwise the risk of mis-merging is > increased. I now see that Gu Jinxiang from fujitsu also started sending > validation fixes. Also for evry patch which fixes a specific issue from one of the reported on bugzilla.kernel.org just use the Link: tag to point to the original report on bugzilla that will make it easier to relate the fixes to the original report. > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] btrfs: Check each block group has corresponding chunk at mount time
On 3.07.2018 11:08, Qu Wenruo wrote: > Reported in https://bugzilla.kernel.org/show_bug.cgi?id=199837, if a > crafted btrfs with incorrect chunk<->block group mapping, it could leads > to a lot of unexpected behavior. > > Although the crafted image can be catched by block group item checker > added in "[PATCH] btrfs: tree-checker: Verify block_group_item", if one > crafted a valid enough block group item which can pass above check but > still mismatch with existing chunk, it could cause a lot of undefined > behavior. > > This patch will add extra block group -> chunk mapping check, to ensure > we have a completely matching (start, len, flags) chunk for each block > group at mount time. > > Reported-by: Xu Wen > Signed-off-by: Qu Wenruo > --- > changelog: > v2: > Add better error message for each mismatch case. > Rename function name, to co-operate with later patch. > Add flags mismatch check. > --- It's getting really hard to keep track of the various validation patches you sent with multiple versions + new checks. Please batch everything in a topic series i.e "Making checks stricter" or some such and send everything again nicely packed, otherwise the risk of mis-merging is increased. I now see that Gu Jinxiang from fujitsu also started sending validation fixes. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
