FSTests Archive on lore.kernel.org
 help / color / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] xfs/148: sort and filter attribute list output
Date: Mon, 2 Dec 2019 18:38:15 -0800
Message-ID: <20191203023815.GB7328@magnolia> (raw)
In-Reply-To: <297458b1-b8ad-3e88-e378-351faccc113b@cn.fujitsu.com>

On Tue, Dec 03, 2019 at 09:45:58AM +0800, Yang Xu wrote:
> 
> 
> on 2019/12/03 7:21, Darrick J. Wong wrote:
> > On Thu, Nov 28, 2019 at 03:10:45PM +0800, Yang Xu wrote:
> > > When I backport fixed patches from Darrick tighten-verifiers tree, this case
> > 
> > NAK, why are you backporting out of my development tree and not upstream?
> My description is wrong. I use upstream kernel 5.4-rc8 and 4 attr patches as
> your tighten-verifiers tree do.
> > What are you even backporting, seeing as the patches for this are in 5.5
> > and Linus hasn't even pulled that yet??
> > I see Linus pulled the patches 3 hour ago,
> > Also, why are you sending a patch to fstests that is (a) barely a week
> > old, (b) doesn't actually list me as the author, and (c) I myself
> > haven't even sent to fstests yet?
> > 
> I  have listed you as author,  I think I should add  "Darrick J. Wong
> pointed  selinux and sort problem" info.  I find ls and "a_are_bad/for_you"
> problem.
> Also, in personal mail("Re: question about xfstests test case
> xfs/148(new)"), I said "I think you may  busy with other important things. I
> will send this simple patch with correct "a_are_bad/for_you" info and add
> your signed-off-by tag."). Anyway, I am sorry, I should have received your
> reply before sending the patch.

<nod> Apology accepted.  I'll send this (and everything else queueing in
my fstest tree) tomorrow like usual.

> > > also fails. As below:
> > > -----------------------------------------------------------
> > > "diff test/xfs/148.out result/xfs/148.out.bad
> > > 7,8d6
> > > < Attribute "a_something" has a 3 byte value for TEST_DIR/mount-148/testfile
> > > < Attribute "a_too_many_beans" has a 3 byte value for TEST_DIR/mount-148/testfile
> > > 9a8
> > > > Attribute "a_too_many_beans" has a 3 byte value for TEST_DIR/mount-148/testfile
> > > 10a10,11
> > > > Attribute "a_something" has a 3 byte value for TEST_DIR/mount-148/testfile
> > > > Attribute "selinux" has a 37 byte value for TEST_DIR/mount-148/testfile
> > > 49,50c50,51
> > > < Attribute "a_are_bad/for_you" had a 3 byte value for TEST_DIR/mount-148/testfile:
> > > < heh
> > > > attr_get: No data available
> > > > Could not get "a_are_bad/for_you" for TEST_DIR/mount-148/testfile"
> > > -------------------------------------------------------------
> > > We should sort attribute list output and filter selinux. Also "a_are_bad/for_you"
> > > doesn't exist, we should correct it in output.
> > > 
> > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ...
> > > Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
> > > ---
> > >   tests/xfs/148     | 2 +-
> > >   tests/xfs/148.out | 8 ++++----
> > >   2 files changed, 5 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/tests/xfs/148 b/tests/xfs/148
> > > index 42cfdab0..06862faa 100755
> > > --- a/tests/xfs/148
> > > +++ b/tests/xfs/148
> > > @@ -76,7 +76,7 @@ test_names+=("too_many" "are_bad/for_you")
> > >   access_stuff() {
> > >   	ls $testdir
> > > -	$ATTR_PROG -l $testfile
> > > +	$ATTR_PROG -l $testfile | grep "a_" | sort
> > >   	for name in "${test_names[@]}"; do
> > >   		ls "$testdir/f_$name"
> > > diff --git a/tests/xfs/148.out b/tests/xfs/148.out
> > > index c301ecb6..ab3fc25b 100644
> > > --- a/tests/xfs/148.out
> > > +++ b/tests/xfs/148.out
> > > @@ -4,10 +4,10 @@ f_another
> > >   f_are_bad_for_you
> > >   f_something
> > >   f_too_many_beans
> > > +Attribute "a_another" has a 3 byte value for TEST_DIR/mount-148/testfile
> > > +Attribute "a_are_bad_for_you" has a 3 byte value for TEST_DIR/mount-148/testfile
> > >   Attribute "a_something" has a 3 byte value for TEST_DIR/mount-148/testfile
> > >   Attribute "a_too_many_beans" has a 3 byte value for TEST_DIR/mount-148/testfile
> > > -Attribute "a_are_bad_for_you" has a 3 byte value for TEST_DIR/mount-148/testfile
> > > -Attribute "a_another" has a 3 byte value for TEST_DIR/mount-148/testfile
> > >   TEST_DIR/mount-148/testdir/f_something
> > >   Attribute "a_something" had a 3 byte value for TEST_DIR/mount-148/testfile:
> > >   heh
> > > @@ -46,5 +46,5 @@ ls: cannot access 'TEST_DIR/mount-148/testdir/f_too_many': No such file or direc
> > >   attr_get: No data available
> > >   Could not get "a_too_many" for TEST_DIR/mount-148/testfile
> > >   ls: cannot access 'TEST_DIR/mount-148/testdir/f_are_bad/for_you': No such file or directory
> > > -Attribute "a_are_bad/for_you" had a 3 byte value for TEST_DIR/mount-148/testfile:
> > > -heh
> > > +attr_get: No data available
> > > +Could not get "a_are_bad/for_you" for TEST_DIR/mount-148/testfile
> > 
> > Huh?  Why???
> > 
> > NAK NAK NAK
> a_are_bad_for_you has been corrupted by "/". So it should be nothing such as

It's been changed, yes, but '/' is a valid character in an attribute
name.  Note that checksums are deliberately disabled on the loopdev
filesystem so that the only checks we perform are the name checks
themselves.

> a_too_many_beans by beans. am  I wrong?( I use 5.4-rc8 and 4 patches
> xfs: check attribute leaf block structure
> xfs: namecheck attribute names before listing them
> xfs: namecheck directory entry names before listing them
> xfs: replace -EIO with -EFSCORRUPTED for corrupt metadata
> ,this four patches from https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?h=tighten-verifiers

This is my development git repo ^^^^^^^^^^ which sometimes contains
older versions of patches that do not end up going upstream.

And this is the official xfs repo:
https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/

Anyway, Linus pulled the 5.5 patches now, so you *really* ought to be
backporting from that.

--D

> )>
> > 
> > --D
> > 
> > > -- 
> > > 2.18.0
> > > 
> > > 
> > > 
> > 
> > 
> 
> 

  reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-28  7:10 Yang Xu
2019-11-29  9:48 ` Yang Xu
2019-12-02 23:21 ` Darrick J. Wong
2019-12-03  1:45   ` Yang Xu
2019-12-03  2:38     ` Darrick J. Wong [this message]
2019-12-03 14:13     ` Qu Wenruo

Reply instructions:

You may reply publically 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=20191203023815.GB7328@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=xuyang2018.jy@cn.fujitsu.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

FSTests Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/fstests/0 fstests/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 fstests fstests/ https://lore.kernel.org/fstests \
		fstests@vger.kernel.org
	public-inbox-index fstests

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.fstests


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git