linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve French <smfrench@gmail.com>
To: ronnie sahlberg <ronniesahlberg@gmail.com>
Cc: CIFS <linux-cifs@vger.kernel.org>
Subject: Re: More tests added to buildbot
Date: Mon, 4 Mar 2019 23:00:00 -0600	[thread overview]
Message-ID: <CAH2r5mvF-gD08nwcXFmu+_=ZRcn5nC7t2DcaSBg__BpFMW5oyw@mail.gmail.com> (raw)
In-Reply-To: <CAN05THTyukBUmbLu-pB+xjLQDq_LByxz=twkUEP1hktGdjdbBg@mail.gmail.com>

I tried it to Samba a few minutes ago and it worked fine with current for-next
 and also:q it looks important (data integrity etc.).  Test description

# Test that mmap read doesn't see non-zero data past EOF on truncate down.
#
# This is inspired by an XFS bug that truncate down fails to zero page cache
# beyond new EOF and causes stale data written to disk unexpectedly and a
# subsequent mmap reads and sees non-zeros post EOF.

I have two test targets, both Samba localhost.  One succeeds for all 8 of
the ones that we were worried about:

./check -cifs generic/013 generic/014 generic/024 generic/030
generic/069 generic/075 generic/112 generic/125 generic/346
generic/469

The other succeeds on all but 075 and 112 which worked on the 'old'
xfstests from a month ago, but fail on the one with the newer
xfstests.

So I think we are ok with 469 ... but we do have to figure out what to
do with what seems to be either a regression in 075 and 112 xfstests
(a bug in the tests) or something that the updated tests are now
seeing as a cifs bug.  My theory is that it is due to this xfstest
commit:

root@smf-Thinkpad-P51:~/xfstests-dev# git log tests/generic/075
commit ec295d73ac19a42d1f022cb074d0bd506252cb3b
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Feb 15 13:41:40 2019 +0100

    generic/075,112: detect preallocation support for fsx tests

    Currently generic/075 and generic/112 have two extra fsx passes each
    that exercise fsx with preallocation, which are only enabled for
    XFS.

    These tests can also be run with other file systems, given that the
    XFS prealloc ioctls are implemented in generic code since the
    addition of the fallocate system call.  This also means a version of
    XFS that does not support preallocation (e.g. because it always
    writes out of place) can skip the prealloc tests while still
    completing the normal fsx tests just fine.

    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Eryu Guan <guaneryu@gmail.com>
    Signed-off-by: Eryu Guan <guaneryu@gmail.com>

On Mon, Mar 4, 2019 at 10:10 PM ronnie sahlberg
<ronniesahlberg@gmail.com> wrote:
>
> generic/469   does it work for you?
> It fails in the tests.
>
> I have tried it locally and it always fails here. With current
> for-next as well as for-next as of a month ago.
> Same for xfs-tests, with current as well as months old master.
>
> Lets remove it.
>
> On Sun, Mar 3, 2019 at 3:05 PM Steve French <smfrench@gmail.com> wrote:
> >
> > Added four xfs subtests to the cifs-testing buildbot (and 3 of these
> > were also missing from the Azure buildbot so added them to Azure as
> > well)
> > +        [ "generic/464", "smb3"],
> > +        [ "generic/469", "smb3"],
> > +        [ "generic/524", "smb3"],
> > +        [ "generic/528", "smb3samba],
> >
> > Testing the three new tests for Azure in
> > http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/4/builds/105
> >
> >
> > --
> > Thanks,
> >
> > Steve



-- 
Thanks,

Steve

  reply	other threads:[~2019-03-05  5:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-03  5:05 More tests added to buildbot Steve French
2019-03-05  4:09 ` ronnie sahlberg
2019-03-05  5:00   ` Steve French [this message]
2019-03-05  5:07     ` ronnie sahlberg
2019-03-05  5:17       ` Steve French
2019-03-05  5:22       ` ronnie sahlberg
2019-03-05  6:01     ` Steve French
2019-03-05  7:21       ` Xiaoli Feng

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='CAH2r5mvF-gD08nwcXFmu+_=ZRcn5nC7t2DcaSBg__BpFMW5oyw@mail.gmail.com' \
    --to=smfrench@gmail.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=ronniesahlberg@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).