Re: [PATCH] overlay: test ro/rw fd data inconsistecies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 2, 2016 at 8:49 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> On Thu, Dec 01, 2016 at 06:42:00PM +0200, Amir Goldstein wrote:
...
>
> I think there's a bug somewhere in xfs_io to do with command line
> repetition of the open command. That is:
>
> # xfs_io
> xfs_io> open foo
> xfs_io> open -r foo
> xfs_io> print
>  000  foo            (foreign,non-sync,non-direct,read-write)
>  [001] foo            (foreign,non-sync,non-direct,read-only)
> xfs_io>
>
> Shows we have two open files, the second being read only.
>
> From the command line, opening a read-only file:
>
> # xfs_io -r -c file foo
> [000] foo            (foreign,non-sync,non-direct,read-only)
> #
>
> But if we try to open a second file from the CLI:
>
> sudo xfs_io -r -c "open -f bar" -c print foo
> bar: Too many open files
> [000] foo            (foreign,non-sync,non-direct,read-only)
>  001  bar            (foreign,non-sync,non-direct,read-write)
>  002  bar            (foreign,non-sync,non-direct,read-write)
>  003  bar            (foreign,non-sync,non-direct,read-write)
>  004  bar            (foreign,non-sync,non-direct,read-write)
>  005  bar            (foreign,non-sync,non-direct,read-write)
>  006  bar            (foreign,non-sync,non-direct,read-write)
> .....
>
> It just falls into an endless loop opening the file until we run out
> fd space.
>
> Oh, there's bugs all over the place here - Ok, I think the command
> loop handling is broken - it's making my head hurt right now.
> Functions that don't set CMD_FLAG_GLOBAL have problems with not
> breaking out of the args processing loop. I'll deal with this on
> Monday, not at beer o'clock on Friday afternoon.
>
>> I realize that the use of redirecting commands from here document
>> to xfs_io has not been used in xfstests before, but I could not find
>> another way to use 'open' commands, which are needed for this test.
>
> Let's fix xfs_io rather than hack yet another whacky way to execute
> xfs_io into xfstests...
>

I have started going down that path, because I initially mistaken
xfs_io -c to be similar to bash -c, but then I realized it is quite different.
xfs_io -c CMD1 -c CMD2 FILE1 FILE2 iterates CMD1, CMD2 on FILE1
and then on FILE2.
As long as this semantic holds, it is going to difficult be to support
-c "open file", without resorting to spaghetti code and confusing users.

OTOH, is there anymore more natural for an program that has an
interactive shell mode to get a script as input and work in non interactive
mode?

So I wrote this test by redirecting input into an interactive shell, which
is not clean.

One alternative is xfs_io -F <script>, similar to debugfs -f, sed -f.
Another is xfs_io -s to read from stdio, similar to bash -s, then
prompt and echo can be silent.
And last, there is the option to treat -c CMD1 -c CMD2 exactly the
same as you would treat interactive commands, meaning that
first FILE1 FILE2 are open as then execute all commands just
instead of "per file in the file table", which creates the endless loop.

Incidentally, xfs_io does not advertise the "run all command per file"
behavior, so not sure why it was done for and if anybody relies on it.
I did not notice any tests that make use of multiple file args for xfs_io,
but it wasn't easy to grep for this practice.

If you have a preference for solution I can execute the work.

Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux