All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tarmo Tänav" <tarmo@itech.ee>
To: Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org, reiserfs-list@namesys.com,
	akpm@osdl.org, mason@suse.com, jeffm@suse.com
Subject: Re: BUG: reiserfs+acl+quota deadlock
Date: Wed, 10 Aug 2005 17:31:38 +0300	[thread overview]
Message-ID: <1123684298.14562.4.camel@localhost> (raw)
In-Reply-To: <20050810130009.GE22112@atrey.karlin.mff.cuni.cz>

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?


  reply	other threads:[~2005-08-10 14:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-10  3:05 BUG: reiserfs+acl+quota deadlock Tarmo Tänav
2005-08-10 13:00 ` Jan Kara
2005-08-10 14:31   ` Tarmo Tänav [this message]
2005-08-10 14:40     ` Jan Kara
2005-08-12 14:55       ` Vladimir V. Saveliev
2005-08-12 14:55       ` Vladimir V. Saveliev
2005-08-12 15:10         ` Jeff Mahoney
2005-08-12 15:56           ` Tarmo Tänav
2005-08-12 16:44           ` Vladimir V. Saveliev
2005-08-12 17:21             ` Jeff Mahoney
2005-08-12 16:17         ` Tarmo Tänav
2005-08-18 14:36         ` Jan Kara
2005-08-13 11:19     ` Jan Kara

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=1123684298.14562.4.camel@localhost \
    --to=tarmo@itech.ee \
    --cc=akpm@osdl.org \
    --cc=jack@suse.cz \
    --cc=jeffm@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mason@suse.com \
    --cc=reiserfs-list@namesys.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.