Re: BUG: reiserfs+acl+quota deadlock
On R, 2005-08-12 at 18:55 +0400, Vladimir V. Saveliev wrote: > > It looks like the problem is that reiserfs_new_inode can be called either > having xattrs locked or not. > It does unlocking/locking xattrs on error handling path, but has no idea > about whether > xattrs are locked of not. > The attached patch seems to fix the problem. > I am not sure whether it is correct way to fix this problem, though. > > Tarmo, please check if this patch works for you. Sorry, I made a mistake when I first tested the patch, got some kernel images mixed up, it does fix the problem, thank you. -- Tarmo Tänav <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: reiserfs+acl+quota deadlock
Vladimir V. Saveliev wrote:
>
> > It looks like the problem is that reiserfs_new_inode can be called
> > either having xattrs locked or not.
> > It does unlocking/locking xattrs on error handling path, but has no idea
> > about whether
> > xattrs are locked of not.
> > The attached patch seems to fix the problem.
> > I am not sure whether it is correct way to fix this problem, though.
I tested the patch, it did not fix the problem. Is there any way that I
could help diagnose the problem? (so far I have not tried reiserfs or
kernel debug options, could those help?)
On R, 2005-08-12 at 11:10 -0400, Jeff Mahoney wrote:
>
> Does this patch actually fix it? It shouldn't.
>
> The logic is like this: If a default ACL is associated with the parent
> when the inode is created, xattrs will be locked so that the ACL can be
> inherited. Since reiserfs_new_inode is called from the VFS layer with
> inode->i_sem downed, {set,remove}xattr is locked out. The default ACL
> can't be removed/added/changed while reiserfs_new_inode is running.
> Therefore, if there is a default ACL, xattrs must be locked.
I don't know if you read my report on this bug, but note that it had
no requirement for any ACL's to be used (even default ACL's), there was
only need for acl support to be enabled when mounting the partition.
--
Tarmo Tänav <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: reiserfs+acl+quota deadlock
Vladimir V. Saveliev wrote:
It looks like the problem is that reiserfs_new_inode can be called
either having xattrs locked or not.
It does unlocking/locking xattrs on error handling path, but has no idea
about whether
xattrs are locked of not.
The attached patch seems to fix the problem.
I am not sure whether it is correct way to fix this problem, though.
I tested the patch, it did not fix the problem. Is there any way that I
could help diagnose the problem? (so far I have not tried reiserfs or
kernel debug options, could those help?)
On R, 2005-08-12 at 11:10 -0400, Jeff Mahoney wrote:
Does this patch actually fix it? It shouldn't.
The logic is like this: If a default ACL is associated with the parent
when the inode is created, xattrs will be locked so that the ACL can be
inherited. Since reiserfs_new_inode is called from the VFS layer with
inode-i_sem downed, {set,remove}xattr is locked out. The default ACL
can't be removed/added/changed while reiserfs_new_inode is running.
Therefore, if there is a default ACL, xattrs must be locked.
I don't know if you read my report on this bug, but note that it had
no requirement for any ACL's to be used (even default ACL's), there was
only need for acl support to be enabled when mounting the partition.
--
Tarmo Tänav [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: reiserfs+acl+quota deadlock
On R, 2005-08-12 at 18:55 +0400, Vladimir V. Saveliev wrote: It looks like the problem is that reiserfs_new_inode can be called either having xattrs locked or not. It does unlocking/locking xattrs on error handling path, but has no idea about whether xattrs are locked of not. The attached patch seems to fix the problem. I am not sure whether it is correct way to fix this problem, though. Tarmo, please check if this patch works for you. Sorry, I made a mistake when I first tested the patch, got some kernel images mixed up, it does fix the problem, thank you. -- Tarmo Tänav [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: reiserfs+acl+quota deadlock
Tried the attached patch but it changed nothing, I trying to create a new file as a user whose quota grace time has ran out will still cause everything accessing the users homedir (the one with the quota) to hang in D state. Also note that the bug I reported only exists when acl is also enabled (does not have to be used). And although my kernel is not built with debug (or reiserfs debug) support, I don't get any oopses or reiserfs errors.. it just hangs. On K, 2005-08-10 at 15:00 +0200, Jan Kara wrote: > Hello, > > > I've already reported a similiar bug to the one I found now > > and that was fixed by: > > "[PATCH] reiserfs: fix deadlock in inode creation failure path w/ > > default ACL" > > > > This bug is similiar in effect but has some differences in how > > to trigger it. The end effect will be just like with the other > > bug that the affected directory will be unaccessible to any user > > or process. > > > > So here's the way to reproduce it, as minimal as I could get it: > > > > You need reiserfs, quota and acl support in kernel. > > you also need quota tools (edquota, quotaon, quotacheck), I used > > linuxquota 3.12. > > > > # cd /mnt > > # dd if=/dev/zero of=test bs=1M count=50 > > 50+0 records in > > 50+0 records out > > # mkreiserfs -f test >/dev/null > > mkreiserfs 3.6.19 (2003 www.namesys.com) > > > > test is not a block special device > > Continue (y/n):y > > # mkdir mpoint > > # mount test mpoint -o loop,acl,usrquota > > # mkdir mpoint/user1 > > # useradd -d /mnt/mpoint/user1 user1 # may also use existing user > > # chown user1 mpoint/user1 > > # quotacheck -v mpoint # initializes quota file > > # edquota user1 > > set soft block limit to 1000, hard limit to 4000 > > # edquota -t > > set the grace periods to something small: 1minutes --- > > # quotaon mpoint > > # ## at this point "repquota -a" should show the quota for user1 > > # su user1 > > # cd > > # ## now we are in user1 home dir as user1 > > # cat /dev/zero > file1 > > loop2: warning, user block quota exceeded. > > loop2: write failed, user block limit reached. > > cat: write error: No space left on device > > --- now we wait till the grace period expires (repquota -a) > > # cat "" > otherfile > > loop2: write failed, user block quota exceeded too long. > > and it will hang forever > > # ## /mnt/mpoint can still be accessed, but /mnt/mpoint/user1 can't > > > > > > I tested this on an -mm patchset kernel (2.6.13-rc5-mm1), but I > > discovered the bug in my server which runs plain 2.6.12 with the > > patch from Jeff Mahoney for the first reiserfs+acl bug. > > > > The main difference between the two bugs is that the first one requires > > the existance of a default acl, this one does not, but it does require > > acl to be enabled. > This seems to be the same problem as bug #4771 that I've just fix. Can > you try attached patch please? > Andrew, can you include the patch into -mm if ReiserFS guys won't object? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: reiserfs+acl+quota deadlock
Tried the attached patch but it changed nothing, I trying to create a new file as a user whose quota grace time has ran out will still cause everything accessing the users homedir (the one with the quota) to hang in D state. Also note that the bug I reported only exists when acl is also enabled (does not have to be used). And although my kernel is not built with debug (or reiserfs debug) support, I don't get any oopses or reiserfs errors.. it just hangs. On K, 2005-08-10 at 15:00 +0200, Jan Kara wrote: Hello, I've already reported a similiar bug to the one I found now and that was fixed by: [PATCH] reiserfs: fix deadlock in inode creation failure path w/ default ACL This bug is similiar in effect but has some differences in how to trigger it. The end effect will be just like with the other bug that the affected directory will be unaccessible to any user or process. So here's the way to reproduce it, as minimal as I could get it: You need reiserfs, quota and acl support in kernel. you also need quota tools (edquota, quotaon, quotacheck), I used linuxquota 3.12. # cd /mnt # dd if=/dev/zero of=test bs=1M count=50 50+0 records in 50+0 records out # mkreiserfs -f test /dev/null mkreiserfs 3.6.19 (2003 www.namesys.com) test is not a block special device Continue (y/n):y # mkdir mpoint # mount test mpoint -o loop,acl,usrquota # mkdir mpoint/user1 # useradd -d /mnt/mpoint/user1 user1 # may also use existing user # chown user1 mpoint/user1 # quotacheck -v mpoint # initializes quota file # edquota user1 set soft block limit to 1000, hard limit to 4000 # edquota -t set the grace periods to something small: 1minutes --- # quotaon mpoint # ## at this point repquota -a should show the quota for user1 # su user1 # cd # ## now we are in user1 home dir as user1 # cat /dev/zero file1 loop2: warning, user block quota exceeded. loop2: write failed, user block limit reached. cat: write error: No space left on device --- now we wait till the grace period expires (repquota -a) # cat otherfile loop2: write failed, user block quota exceeded too long. and it will hang forever # ## /mnt/mpoint can still be accessed, but /mnt/mpoint/user1 can't I tested this on an -mm patchset kernel (2.6.13-rc5-mm1), but I discovered the bug in my server which runs plain 2.6.12 with the patch from Jeff Mahoney for the first reiserfs+acl bug. The main difference between the two bugs is that the first one requires the existance of a default acl, this one does not, but it does require acl to be enabled. This seems to be the same problem as bug #4771 that I've just fix. Can you try attached patch please? Andrew, can you include the patch into -mm if ReiserFS guys won't object? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: reiserfs+acl+quota deadlock
Hi, I've already reported a similiar bug to the one I found now and that was fixed by: "[PATCH] reiserfs: fix deadlock in inode creation failure path w/ default ACL" This bug is similiar in effect but has some differences in how to trigger it. The end effect will be just like with the other bug that the affected directory will be unaccessible to any user or process. So here's the way to reproduce it, as minimal as I could get it: You need reiserfs, quota and acl support in kernel. you also need quota tools (edquota, quotaon, quotacheck), I used linuxquota 3.12. # cd /mnt # dd if=/dev/zero of=test bs=1M count=50 50+0 records in 50+0 records out # mkreiserfs -f test >/dev/null mkreiserfs 3.6.19 (2003 www.namesys.com) test is not a block special device Continue (y/n):y # mkdir mpoint # mount test mpoint -o loop,acl,usrquota # mkdir mpoint/user1 # useradd -d /mnt/mpoint/user1 user1 # may also use existing user # chown user1 mpoint/user1 # quotacheck -v mpoint # initializes quota file # edquota user1 set soft block limit to 1000, hard limit to 4000 # edquota -t set the grace periods to something small: 1minutes --- # quotaon mpoint # ## at this point "repquota -a" should show the quota for user1 # su user1 # cd # ## now we are in user1 home dir as user1 # cat /dev/zero > file1 loop2: warning, user block quota exceeded. loop2: write failed, user block limit reached. cat: write error: No space left on device --- now we wait till the grace period expires (repquota -a) # cat "" > otherfile loop2: write failed, user block quota exceeded too long. and it will hang forever # ## /mnt/mpoint can still be accessed, but /mnt/mpoint/user1 can't I tested this on an -mm patchset kernel (2.6.13-rc5-mm1), but I discovered the bug in my server which runs plain 2.6.12 with the patch from Jeff Mahoney for the first reiserfs+acl bug. The main difference between the two bugs is that the first one requires the existance of a default acl, this one does not, but it does require acl to be enabled. PS. please CC, I'm not subscribed to the list -- Tarmo Tänav <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: reiserfs+acl+quota deadlock
Hi, I've already reported a similiar bug to the one I found now and that was fixed by: [PATCH] reiserfs: fix deadlock in inode creation failure path w/ default ACL This bug is similiar in effect but has some differences in how to trigger it. The end effect will be just like with the other bug that the affected directory will be unaccessible to any user or process. So here's the way to reproduce it, as minimal as I could get it: You need reiserfs, quota and acl support in kernel. you also need quota tools (edquota, quotaon, quotacheck), I used linuxquota 3.12. # cd /mnt # dd if=/dev/zero of=test bs=1M count=50 50+0 records in 50+0 records out # mkreiserfs -f test /dev/null mkreiserfs 3.6.19 (2003 www.namesys.com) test is not a block special device Continue (y/n):y # mkdir mpoint # mount test mpoint -o loop,acl,usrquota # mkdir mpoint/user1 # useradd -d /mnt/mpoint/user1 user1 # may also use existing user # chown user1 mpoint/user1 # quotacheck -v mpoint # initializes quota file # edquota user1 set soft block limit to 1000, hard limit to 4000 # edquota -t set the grace periods to something small: 1minutes --- # quotaon mpoint # ## at this point repquota -a should show the quota for user1 # su user1 # cd # ## now we are in user1 home dir as user1 # cat /dev/zero file1 loop2: warning, user block quota exceeded. loop2: write failed, user block limit reached. cat: write error: No space left on device --- now we wait till the grace period expires (repquota -a) # cat otherfile loop2: write failed, user block quota exceeded too long. and it will hang forever # ## /mnt/mpoint can still be accessed, but /mnt/mpoint/user1 can't I tested this on an -mm patchset kernel (2.6.13-rc5-mm1), but I discovered the bug in my server which runs plain 2.6.12 with the patch from Jeff Mahoney for the first reiserfs+acl bug. The main difference between the two bugs is that the first one requires the existance of a default acl, this one does not, but it does require acl to be enabled. PS. please CC, I'm not subscribed to the list -- Tarmo Tänav [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs+acl makes processes hang?
You made one mistake, the last echo "1" >blah should not be
to the file you created earlier.. the echo is meant to
create another file which is supposed to fail because there
is no free space but for some reason instead of failing it
will cause the process to enter D state.
Here is how I just reproced it:
#mkdir testdir
#cd testdir/
#dd if=/dev/zero of=blk count=64 bs=1M
64+0 records in
64+0 records out
#mkreiserfs -f blk >/dev/null
mkreiserfs 3.6.19 (2003 www.namesys.com)
blk is not a block special device
Continue (y/n):y
#mkdir mpoint
#mount blk mpoint/ -o loop,acl
#cd mpoint
#mkdir dir
#setfacl -f -m u:sn4ip3r:rwX dir
setfacl: invalid option -- f
Usage: setfacl [-bkndRLP] { -m|-M|-x|-X ... } file ...
Try `setfacl --help' for more information.
#setfacl -d -m u:sn4ip3r:rwX dir
#cd dir
#cat /dev/zero >blah
cat: write error: No space left on device
#df .
Filesystem 1K-blocks Used Available Use% Mounted on
/home/sn4ip3r/testdir/blk
65528 65528 0
100% /home/sn4ip3r/testdir/mpoint
#echo 1 > blah2 <<< and this is the line that never returns
--
Tarmo Tänav
[EMAIL PROTECTED]
On L, 2005-07-16 at 10:24 +0200, Jan Engelhardt wrote:
> >Hi,
> >
> >Here's how to reproduce:
> >1. mount a reiserfs volume (loopmount will do) with "-o acl".
> >2. create a directory "dir"
> >3. set some default acl: setfacl -d -m u:username:rwX dir
> >4. cd dir
> >5. dd if=/dev/zero of=somefile1 bs=4k count=10
> >(the idea is to run out of space)
> >6. now df should show 0 free space, if not then repeat 5.
> >7. echo "1" > somefile2 # this should hang infinitely
>
> Can't reproduce. My versions are:
> mkreiserfs 3.6.18
> Kernel 2.6.13-rc1
>
>
> ---Step 1---
> 10:25 shanghai:/mnt > dd if=/dev/zero of=blk count=64 bs=1M
> 64+0 records in
> 64+0 records out
> 67108864 bytes (67 MB) copied, 0.552862 seconds, 121 MB/s
> 10:26 shanghai:/mnt > mkreiserfs -f blk
> mkreiserfs 3.6.18 (2003 www.namesys.com)
>
> A pair of credits:
> ...
> blk is not a block special device
> Continue (y/n):y
> Guessing about desired format.. Kernel 2.6.13-rc1 is running.
> Format 3.6 with standard journal
> Count of blocks on the device: 16384
> Number of blocks consumed by mkreiserfs formatting process: 8212
> Blocksize: 4096
> Hash function used to sort names: "r5"
> Journal Size 8193 blocks (first block 18)
> Journal Max transaction length 1024
> inode generation number: 0
> UUID: aa3bd664-fde0-4552-9484-49bac0fb698f
> Initializing journal - 0%20%40%60%80%100%
> Syncing..ok
> ReiserFS is successfully created on blk.
> 10:26 shanghai:/mnt > mount blk loop -o loop,acl
>
> ---Step 2-7---
> 10:26 shanghai:/mnt > cd loop/
> 10:27 shanghai:/mnt/loop > md dir
> 10:27 shanghai:/mnt/loop > setfacl -d -m u:daemon:rwX dir
> 10:27 shanghai:/mnt/loop > cd dir
> 10:27 shanghai:/mnt/loop/dir > cat /dev/zero >blah
> cat: write error: No space left on device
> 10:27 shanghai:/mnt/loop/dir > df .
> Filesystem 1K-blocks Used Available Use% Mounted on
> /mnt/blk 65528 65528 0 100% /mnt/loop
> 10:27 shanghai:/mnt/loop/dir > l
> total 32684
> drwxr-xr-x+ 2 root root 72 Jul 16 10:27 .
> drwxr-xr-x 5 root root 104 Jul 16 10:27 ..
> -rw-rw-r--+ 1 root root 33435648 Jul 16 10:27 blah
> (That's ok, the other 32MB are for the journal)
> 10:27 shanghai:/mnt/loop/dir > echo "1" >blah
> 10:28 shanghai:/mnt/loop/dir > l blah
> -rw-rw-r--+ 1 root root 2 Jul 16 10:28 blah
>
>
>
> Jan Engelhardt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs+acl makes processes hang?
You made one mistake, the last echo 1 blah should not be
to the file you created earlier.. the echo is meant to
create another file which is supposed to fail because there
is no free space but for some reason instead of failing it
will cause the process to enter D state.
Here is how I just reproced it:
#mkdir testdir
#cd testdir/
#dd if=/dev/zero of=blk count=64 bs=1M
64+0 records in
64+0 records out
#mkreiserfs -f blk /dev/null
mkreiserfs 3.6.19 (2003 www.namesys.com)
blk is not a block special device
Continue (y/n):y
#mkdir mpoint
#mount blk mpoint/ -o loop,acl
#cd mpoint
#mkdir dir
#setfacl -f -m u:sn4ip3r:rwX dir
setfacl: invalid option -- f
Usage: setfacl [-bkndRLP] { -m|-M|-x|-X ... } file ...
Try `setfacl --help' for more information.
#setfacl -d -m u:sn4ip3r:rwX dir
#cd dir
#cat /dev/zero blah
cat: write error: No space left on device
#df .
Filesystem 1K-blocks Used Available Use% Mounted on
/home/sn4ip3r/testdir/blk
65528 65528 0
100% /home/sn4ip3r/testdir/mpoint
#echo 1 blah2 and this is the line that never returns
--
Tarmo Tänav
[EMAIL PROTECTED]
On L, 2005-07-16 at 10:24 +0200, Jan Engelhardt wrote:
Hi,
Here's how to reproduce:
1. mount a reiserfs volume (loopmount will do) with -o acl.
2. create a directory dir
3. set some default acl: setfacl -d -m u:username:rwX dir
4. cd dir
5. dd if=/dev/zero of=somefile1 bs=4k count=10
(the idea is to run out of space)
6. now df should show 0 free space, if not then repeat 5.
7. echo 1 somefile2 # this should hang infinitely
Can't reproduce. My versions are:
mkreiserfs 3.6.18
Kernel 2.6.13-rc1
---Step 1---
10:25 shanghai:/mnt dd if=/dev/zero of=blk count=64 bs=1M
64+0 records in
64+0 records out
67108864 bytes (67 MB) copied, 0.552862 seconds, 121 MB/s
10:26 shanghai:/mnt mkreiserfs -f blk
mkreiserfs 3.6.18 (2003 www.namesys.com)
A pair of credits:
...
blk is not a block special device
Continue (y/n):y
Guessing about desired format.. Kernel 2.6.13-rc1 is running.
Format 3.6 with standard journal
Count of blocks on the device: 16384
Number of blocks consumed by mkreiserfs formatting process: 8212
Blocksize: 4096
Hash function used to sort names: r5
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: aa3bd664-fde0-4552-9484-49bac0fb698f
Initializing journal - 0%20%40%60%80%100%
Syncing..ok
ReiserFS is successfully created on blk.
10:26 shanghai:/mnt mount blk loop -o loop,acl
---Step 2-7---
10:26 shanghai:/mnt cd loop/
10:27 shanghai:/mnt/loop md dir
10:27 shanghai:/mnt/loop setfacl -d -m u:daemon:rwX dir
10:27 shanghai:/mnt/loop cd dir
10:27 shanghai:/mnt/loop/dir cat /dev/zero blah
cat: write error: No space left on device
10:27 shanghai:/mnt/loop/dir df .
Filesystem 1K-blocks Used Available Use% Mounted on
/mnt/blk 65528 65528 0 100% /mnt/loop
10:27 shanghai:/mnt/loop/dir l
total 32684
drwxr-xr-x+ 2 root root 72 Jul 16 10:27 .
drwxr-xr-x 5 root root 104 Jul 16 10:27 ..
-rw-rw-r--+ 1 root root 33435648 Jul 16 10:27 blah
(That's ok, the other 32MB are for the journal)
10:27 shanghai:/mnt/loop/dir echo 1 blah
10:28 shanghai:/mnt/loop/dir l blah
-rw-rw-r--+ 1 root root 2 Jul 16 10:28 blah
Jan Engelhardt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
reiserfs+acl makes processes hang?
Hi, I think I've found a bug in reiserfs acls. If triggered it means that any program trying to access the partition, where the bug occured, will just hang in D state, with no way to kill the program. Here's how to reproduce: 1. mount a reiserfs volume (loopmount will do) with "-o acl". 2. create a directory "dir" 3. set some default acl: setfacl -d -m u:username:rwX dir 4. cd dir 5. dd if=/dev/zero of=somefile1 bs=4k count=10 (the idea is to run out of space) 6. now df should show 0 free space, if not then repeat 5. 7. echo "1" > somefile2 # this should hang infinitely Now no program will be able to access the partition. I haven't tried to reproduce it, but the same problem also happened when a user hit his hard quota limit on my server. Then no program could access his homedir. PS. I'm not subscribed to lkml so please CC -- Tarmo Tänav [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
reiserfs+acl makes processes hang?
Hi, I think I've found a bug in reiserfs acls. If triggered it means that any program trying to access the partition, where the bug occured, will just hang in D state, with no way to kill the program. Here's how to reproduce: 1. mount a reiserfs volume (loopmount will do) with -o acl. 2. create a directory dir 3. set some default acl: setfacl -d -m u:username:rwX dir 4. cd dir 5. dd if=/dev/zero of=somefile1 bs=4k count=10 (the idea is to run out of space) 6. now df should show 0 free space, if not then repeat 5. 7. echo 1 somefile2 # this should hang infinitely Now no program will be able to access the partition. I haven't tried to reproduce it, but the same problem also happened when a user hit his hard quota limit on my server. Then no program could access his homedir. PS. I'm not subscribed to lkml so please CC -- Tarmo Tänav [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
