From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88E94C4740A for ; Mon, 9 Sep 2019 11:32:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 65064218AF for ; Mon, 9 Sep 2019 11:32:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391079AbfIILcn convert rfc822-to-8bit (ORCPT ); Mon, 9 Sep 2019 07:32:43 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:35686 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391070AbfIILcn (ORCPT ); Mon, 9 Sep 2019 07:32:43 -0400 Received: by mail-lj1-f195.google.com with SMTP id q22so7782022ljj.2 for ; Mon, 09 Sep 2019 04:32:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8FsgMun2KShGa6ac76Dh5jCeuEqaKnCVziaJEG5KzVs=; b=J9gkwXWF0azonnmdNKwPMDdTVezc4y4MP86fsHlsPHJ1dRR43PqkDRegNwmL+jXBfd ynkcgB20cjvvH297WUvqdByw9kqfIFzNr7q69jrSF0W3LggGlbcYbbBDjQA0M4majMS/ uKLDJeo3T8h7Hvv4zgRZ/HQA/QRWYmPmgegEH/bgR+rgB3WU0UN9+7w8F0W/b8F04XQG ifdaJ2WDMP1zPM3mMpZJtTaVPdxlw8oPu/6L9BxUyYzqVSu+NJw/B1NHU1EG853yhfBD dN0YLFHr4+0pPdH6YTWOGsS8WodMX3BuiwK773xom4/atJsh/Umu3vnaSPddObPt/4le 8Zdg== X-Gm-Message-State: APjAAAW2HhiuEBGfGU3voeCPTDGeYHj2VvoMP26NlLGZZXmnZ7aiOzpi XXjWwx/gKi3IOCehpcrc0lJdtaV/tIY= X-Google-Smtp-Source: APXvYqyXl58YinQRpskn2W/FjE4StnvEnvGNaoZY+n48M4e2VC2CzDn+vBDABjEczPs2Oyw+7cqhJQ== X-Received: by 2002:a2e:7410:: with SMTP id p16mr15869345ljc.186.1568028759634; Mon, 09 Sep 2019 04:32:39 -0700 (PDT) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id 3sm2894159ljs.20.2019.09.09.04.32.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Sep 2019 04:32:39 -0700 (PDT) Received: by mail-lf1-f44.google.com with SMTP id w6so10212211lfl.2 for ; Mon, 09 Sep 2019 04:32:39 -0700 (PDT) X-Received: by 2002:ac2:520d:: with SMTP id a13mr16887581lfl.101.1568028759172; Mon, 09 Sep 2019 04:32:39 -0700 (PDT) MIME-Version: 1.0 References: <20190906095846.30592-1-git@vladimir.panteleev.md> In-Reply-To: From: Vladimir Panteleev Date: Mon, 9 Sep 2019 11:32:22 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] btrfs-progs: mkfs: fix xattr enumeration To: Nikolay Borisov Cc: Btrfs BTRFS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Hi Nikolay, Unfortunately, as I mentioned in the issue, I have also been unable to reproduce this issue locally. Please see here: https://github.com/kdave/btrfs-progs/issues/194 The reporter tested the patch and confirmed that it worked. Additionally, they have provided strace output which appears to confirm that the bug description in the patch commit message indeed corresponds to the behavior they are observing on their machine. Perhaps the issue might be reproducible in an environment closer to the reporter's (looks like some Fedora distro judging by the uname). On Mon, 9 Sep 2019 at 11:22, Nikolay Borisov wrote: > > > > On 6.09.19 г. 12:58 ч., Vladimir Panteleev wrote: > > Use the return value of listxattr instead of tokenizing. > > > > The end of the extended attribute list is indicated by the return > > value, not an empty list item (two consecutive NULs). Using strtok > > in this way thus sometimes caused add_xattr_item to reuse stack data > > in xattr_list from the previous invocation, thus querying attributes > > that are not actually in the file's xattr list. > > > > Issue: #194 > > Signed-off-by: Vladimir Panteleev > > Can you elaborate how to trigger this? I tried by creating a folder with > 2 files and set 5 xattr to the first file and 1 to the second. Then I > run mkfs.btrfs -r /path/to/dir /dev/vdc and stepped through the code > with gdb and didn't see any issues. Ideally I'd like to see a regression > test for this issue. > > Your code looks correct. > > > --- > > mkfs/rootdir.c | 11 +++++------ > > 1 file changed, 5 insertions(+), 6 deletions(-) > > > > diff --git a/mkfs/rootdir.c b/mkfs/rootdir.c > > index 51411e02..c86159e7 100644 > > --- a/mkfs/rootdir.c > > +++ b/mkfs/rootdir.c > > @@ -228,10 +228,9 @@ static int add_xattr_item(struct btrfs_trans_handle *trans, > > int ret; > > int cur_name_len; > > char xattr_list[XATTR_LIST_MAX]; > > + char *xattr_list_end; > > char *cur_name; > > char cur_value[XATTR_SIZE_MAX]; > > - char delimiter = '\0'; > > - char *next_location = xattr_list; > > > > ret = llistxattr(file_name, xattr_list, XATTR_LIST_MAX); > > if (ret < 0) { > > @@ -243,10 +242,10 @@ static int add_xattr_item(struct btrfs_trans_handle *trans, > > if (ret == 0) > > return ret; > > > > - cur_name = strtok(xattr_list, &delimiter); > > - while (cur_name != NULL) { > > + xattr_list_end = xattr_list + ret; > > + cur_name = xattr_list; > > + while (cur_name < xattr_list_end) { > > cur_name_len = strlen(cur_name); > > - next_location += cur_name_len + 1; > > > > ret = lgetxattr(file_name, cur_name, cur_value, XATTR_SIZE_MAX); > > if (ret < 0) { > > @@ -266,7 +265,7 @@ static int add_xattr_item(struct btrfs_trans_handle *trans, > > file_name); > > } > > > > - cur_name = strtok(next_location, &delimiter); > > + cur_name += cur_name_len + 1; > > } > > > > return ret; > >