Miklos Szeredi wrote:
> Shell script is the one I'm most familiar with, and that maybe true
> for other kernel developers too.
>
> Also, it's what xfstests are using and it would make sense to move
> towards that. Although I'm not sure how well it supports
> multiple-device filesystems.
It was
On Tue, Jun 3, 2014 at 5:30 PM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> And this one is a missing annotation in overlayfs. Tested patch pushed to
>> the
>> usual branches.
>
> Looks good so far, though there are a few more bits to try and break -
> rename() for example.
>
> I also wan
Miklos Szeredi wrote:
> And this one is a missing annotation in overlayfs. Tested patch pushed to the
> usual branches.
Looks good so far, though there are a few more bits to try and break -
rename() for example.
I also want to rewrite my test stuff in something a little more wieldy than
shell
On Tue, Jun 03, 2014 at 11:33:54AM +0100, David Howells wrote:
> Miklos Szeredi wrote:
>
> > Fix now pushed to overlayfs.v22/overlayfs.current.
>
> I ran my testscript, which leaves a clean set up and mounted overlay fs
> behind. I then ran:
>
> for ((i=100; i<=129; i++)); do mv /mnt/a/f
On Tue, Jun 3, 2014 at 12:21 PM, Sedat Dilek wrote:
> On Tue, Jun 3, 2014 at 11:42 AM, Miklos Szeredi wrote:
>> On Tue, Jun 3, 2014 at 11:26 AM, Sedat Dilek wrote:
>>> On Tue, Jun 3, 2014 at 11:18 AM, Sedat Dilek wrote:
[...]
>> [ NOTE-2: The call-trace I have seen once (TERMSLASH=0).
Miklos Szeredi wrote:
> Fix now pushed to overlayfs.v22/overlayfs.current.
I ran my testscript, which leaves a clean set up and mounted overlay fs
behind. I then ran:
for ((i=100; i<=129; i++)); do mv /mnt/a/foo$i /mnt/a/bar$i; done
for ((i=100; i<=129; i++)); do mv /mnt/a/dir$
On Tue, Jun 3, 2014 at 11:42 AM, Miklos Szeredi wrote:
> On Tue, Jun 3, 2014 at 11:26 AM, Sedat Dilek wrote:
>> On Tue, Jun 3, 2014 at 11:18 AM, Sedat Dilek wrote:
>>> [...]
> [ NOTE-2: The call-trace I have seen once (TERMSLASH=0). ]
Do you know for which operation?
>
> This still
On Tue, Jun 3, 2014 at 11:26 AM, Sedat Dilek wrote:
> On Tue, Jun 3, 2014 at 11:18 AM, Sedat Dilek wrote:
>> [...]
[ NOTE-2: The call-trace I have seen once (TERMSLASH=0). ]
>>>
>>> Do you know for which operation?
This still looks like the same annotation problem in
generic_file_splice_wri
[...]
> The lockdep appears one time in the logs... I tried several...
>
> # LC_ALL=C TEST_OVERLAYFS=1 ./run.sh truncate.test
>
> ...and see the only lockdep.
>
> Sorry, I cannot say which of the test-no (is that what you mean by
> operation?) is causing the lockdep.
>
> Truncate-test results
On Tue, Jun 3, 2014 at 11:18 AM, Sedat Dilek wrote:
> [...]
>>> [ NOTE-2: The call-trace I have seen once (TERMSLASH=0). ]
>>
>> Do you know for which operation?
>>
>
> # echo $TESTS
> open-plain.test open-trunc.test open-creat.test open-creat-trunc.test
> open-creat-excl.test open-creat-excl-trun
On Tue, Jun 3, 2014 at 11:00 AM, David Howells wrote:
> My suspicion is that overlayfs is doing stuff to the lower layer whilst
> holding a lock on the upper layer or vice versa.
No. It's holding the overlayfs i_mutex and then getting either the
upper *or* the lower i_mutex, but never both. So
Sedat Dilek wrote:
> [ Re-Tested with 3.15.0-rc8-1-iniza-lockdep ]
>
> Running the impermissible test on OverlayFS with TERMSLASH=1 is
> successful here
That's not very surprising. utimensat() doesn't even get out of pathwalk if
the filename has a terminal slash and the fs_op macro correctly o
David Howells:
> > Does readlink(2) return "/u/fileA" instead of /ro/fileA?"
>
> No.
>
> The test suite sets the lower symlink to point to the union path for its
> target.
>
> [root@andromeda union-testsuite]# readlink /lower/a/indirect_dir_sym100
> /mnt/a/direct_dir_sym100
Now I've found you
David Howells wrote:
> I'll have to address the termslash alterations at some point.
Okay. Done and pushed.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
J. R. Okajima wrote:
> I've found some interesting cases.
>
> - impermissible.test,
> open_file_as_bin -t -w $file -E EACCES
> When $termslash is "/", a '/' is appended to the expanded $file, such
> as "/path/fileA/". If fileA is a regular file, that path is obviously
> wrong. Does U
Sedat Dilek wrote:
> umount: /mnt: not mounted
Don't worry about that.
> TEST104: Impermissible utimes
> - fs_op_as_bin utimes /mnt/a/rootfile104 -E EACCES
> /mnt/a/rootfile104: Test file not on upper filesystem (line 130)
That might be a failure in overlayfs.
David
--
To unsubscribe from th
"J. R. Okajima":
> - readlink.test,
> fs_op readlink $file -R $testdir/direct_dir_sym100 ${termslash:+-E
> EINVAL}
> It expects "$testdir/direct_dir_sym100". Does it mean UnionMount
> converts the target path?
> For example,
> - /u = /rw + /ro
> - /rw/symlinkA doesn't exist
> -
On Fri, May 30, 2014 at 6:15 AM, Sedat Dilek wrote:
> On Thu, May 29, 2014 at 10:59 PM, David Howells wrote:
>> Sedat Dilek wrote:
>>
>>> "Fixable" in your testsuite?
>>
>> Done and pushed.
>>
>
> Thanks.
>
> I still see lots of...
>
> umount: /mnt: not mounted
>
> ...and impermissible.test fail
On Thu, May 29, 2014 at 10:59 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> "Fixable" in your testsuite?
>
> Done and pushed.
>
Thanks.
I still see lots of...
umount: /mnt: not mounted
...and impermissible.test fails here...
***
*** ./run.sh impermissible.test
***
umount: /mnt: not moun
David Howells:
> http://git.infradead.org/users/dhowells/unionmount-testsuite.git
I've found some interesting cases.
- impermissible.test,
open_file_as_bin -t -w $file -E EACCES
When $termslash is "/", a '/' is appended to the expanded $file, such
as "/path/fileA/". If fileA is a reg
[cc fste...@vger.kernel.org]
On Thu, May 29, 2014 at 05:48:01PM +0100, David Howells wrote:
>
> http://git.infradead.org/users/dhowells/unionmount-testsuite.git
>
> Check it out and read the README file as to how to drive it. Sorry, it's a
> bit crude. I may rewrite it in python or perl at som
Sedat Dilek wrote:
> "Fixable" in your testsuite?
Done and pushed.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at ht
On Thu, May 29, 2014 at 9:35 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> # LC_ALL=C TEST_OVERLAYFS="1" ./run.sh
>> [ run.sh ] TEST_OVERLAYFS is 1
>> ***
>> *** ./run.sh open-plain.test
>> ***
>> [ mount_union.sh ] TEST_OVERLAYFS is 1
>> TEST100: Open O_RDONLY
>> - open_file -r /mnt/a/foo1
Sedat Dilek wrote:
> # LC_ALL=C TEST_OVERLAYFS="1" ./run.sh
> [ run.sh ] TEST_OVERLAYFS is 1
> ***
> *** ./run.sh open-plain.test
> ***
> [ mount_union.sh ] TEST_OVERLAYFS is 1
> TEST100: Open O_RDONLY
> - open_file -r /mnt/a/foo100 -R :xxx:yyy:zzz
> - open_file -r /mnt/a/foo100 -R :xxx:yyy:zzz
On Thu, May 29, 2014 at 9:25 PM, David Howells wrote:
>
> Sedat Dilek wrote:
>
>> # LC_ALL=C TEST_OVERLAYFS="1" ./run.sh
>> [ run.sh ] TEST_OVERLAYFS is 1
>> ***
>> *** ./run.sh open-plain.test
>> ***
>> [ mount_union.sh ] TEST_OVERLAYFS is 1
>> TEST100: Open O_RDONLY
>> - open_file -r /mnt/a/fo
Sedat Dilek wrote:
> # LC_ALL=C TEST_OVERLAYFS="1" ./run.sh
> [ run.sh ] TEST_OVERLAYFS is 1
> ***
> *** ./run.sh open-plain.test
> ***
> [ mount_union.sh ] TEST_OVERLAYFS is 1
> TEST100: Open O_RDONLY
> - open_file -r /mnt/a/foo100 -R :xxx:yyy:zzz
> - open_file -r /mnt/a/foo100 -R :xxx:yyy:zz
On Thu, May 29, 2014 at 9:20 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> Hmm, why is the generated binary callled "open-file" and in the
>> scripts I see "open_file"?
>
> grep is your friend:-) Look in tool_box.inc
>
I resetted to origin/HEAD and still get...
# LC_ALL=C TEST_OVERLAYFS=1
Sedat Dilek wrote:
> Hmm, why is the generated binary callled "open-file" and in the
> scripts I see "open_file"?
grep is your friend:-) Look in tool_box.inc
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
M
On Thu, May 29, 2014 at 8:44 PM, Sedat Dilek wrote:
> On Thu, May 29, 2014 at 8:22 PM, David Howells wrote:
>> Sedat Dilek wrote:
>>
>>> > TEST_OVERLAYFS=1 ./run.sh
>>> >
>>> > right?
>>> >
>>>
>>> Yes (with my mount-patch applied).
>>>
>>> ( ...and... # umount /lower /upper /mnt )
>>
>>
On Thu, May 29, 2014 at 8:22 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> > TEST_OVERLAYFS=1 ./run.sh
>> >
>> > right?
>> >
>>
>> Yes (with my mount-patch applied).
>>
>> ( ...and... # umount /lower /upper /mnt )
>
> Can you put a couple of echo commands in settings.inc to show whic
Dave Jones wrote:
> The more interesting parts of lockdep come under CONFIG_PROVE_LOCKING
Ah, yes... I have that one enabled also.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Thu, May 29, 2014 at 06:50:03PM +0100, David Howells wrote:
> Sedat Dilek wrote:
>
> > config LOCKDEP
> > bool
>
> It has no name, so you can't turn it on manually. You have to enable
> something the depends on or selects it.
>
> Turn on:
>
> CONFIG_DEBUG_ATOMIC_SLE
Sedat Dilek wrote:
> > TEST_OVERLAYFS=1 ./run.sh
> >
> > right?
> >
>
> Yes (with my mount-patch applied).
>
> ( ...and... # umount /lower /upper /mnt )
Can you put a couple of echo commands in settings.inc to show which side of
the if-statement it goes and also put:
echo TEST
On Thu, May 29, 2014 at 7:50 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> config LOCKDEP
>> bool
>
> It has no name, so you can't turn it on manually. You have to enable
> something the depends on or selects it.
>
> Turn on:
>
> CONFIG_DEBUG_ATOMIC_SLEEP=y
> CONFIG_
Sedat Dilek wrote:
> config LOCKDEP
> bool
It has no name, so you can't turn it on manually. You have to enable
something the depends on or selects it.
Turn on:
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_RT
On Thu, May 29, 2014 at 7:41 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> >> /mnt/a/foo101: Test file not on upper filesystem (line 30)
>> >
>> > Now check dmesg.
>> >
>>
>> [ 1384.995334] tmpfs: No value for mount option 'union'
>
> That's going down the unionmount testing route, it would
Sedat Dilek wrote:
> >> /mnt/a/foo101: Test file not on upper filesystem (line 30)
> >
> > Now check dmesg.
> >
>
> [ 1384.995334] tmpfs: No value for mount option 'union'
That's going down the unionmount testing route, it would appear. You're
definitely doing:
TEST_OVERLAYFS=1 ./run
On Thu, May 29, 2014 at 7:24 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> /mnt/a/foo101: Test file not on upper filesystem (line 30)
>
> Now check dmesg.
>
[ 1384.995334] tmpfs: No value for mount option 'union'
- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux
On Thu, May 29, 2014 at 7:15 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> # grep LOCKDEP /boot/config-3.15.0-rc7-58.1-iniza-small
>> CONFIG_LOCKDEP_SUPPORT=y
>
> That's not LOCKDEP, merely support for it. What I see:
>
> warthog>grep LOCKDEP build/.config
> CONFIG_LOCKDEP_S
Sedat Dilek wrote:
> /mnt/a/foo101: Test file not on upper filesystem (line 30)
Now check dmesg.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.
Sedat Dilek wrote:
> # grep LOCKDEP /boot/config-3.15.0-rc7-58.1-iniza-small
> CONFIG_LOCKDEP_SUPPORT=y
That's not LOCKDEP, merely support for it. What I see:
warthog>grep LOCKDEP build/.config
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_LOCKDEP=y
> ./tool_box.inc: line 144: /usr/
On Thu, May 29, 2014 at 7:15 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> # grep LOCKDEP /boot/config-3.15.0-rc7-58.1-iniza-small
>> CONFIG_LOCKDEP_SUPPORT=y
>
> That's not LOCKDEP, merely support for it. What I see:
>
> warthog>grep LOCKDEP build/.config
> CONFIG_LOCKDEP_S
Sedat Dilek wrote:
> -/root/util-linux-union/mount/mount -i -t tmpfs upper_layer
> $union_mntroot -o union || exit $?
> +mount -i -t tmpfs upper_layer $union_mntroot -o union || exit $?
That's irrelevant if you're testing overlayfs.
David
--
To unsubscribe from this list: send the line
http://git.infradead.org/users/dhowells/unionmount-testsuite.git
Check it out and read the README file as to how to drive it. Sorry, it's a
bit crude. I may rewrite it in python or perl at some point.
Make sure you turn on CONFIG_LOCKDEP before running it - you don't want to
miss any locking c
44 matches
Mail list logo
