On 2019/12/3 上午9:45, 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, Just a tip, as it looks like Fujitsu CN guys are suffering from M$ Exchange mail server. It looks like either you didn't apply the patch correctly or the mail server (M$ Exchange if not changed) is modifying the "From: " line. A properly formatted patch from another author looks like: From f82e569b33c3c1cfd4f8f405085ff8d439a0a915 Mon Sep 17 00:00:00 2001 From: David Sterba Date: Fri, 25 Oct 2019 14:05:38 +0200 Subject: [PATCH] Btrfs progs v5.3.1 Signed-off-by: David Sterba --- Note the "From: " line is the real author. A lot of mail servers don't accept "From: " other than the sender. And M$ Exchange is even worse, it will change "From: " tag to what M$ thinks is best. E.g Patch sent through O365 with "From: Qu Wenruo " will be modified to "From: Wenruo Qu ", screwing up certain patch accounting. You'd better contact your IT department to solve the problem (if possible). Thanks, Qu >  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. >>> 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 > ... >>> Signed-off-by: Yang Xu >>> --- >>>   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  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 > > )> >> >> --D >> >>> --  >>> 2.18.0 >>> >>> >>> >> >> > >