public inbox for linux-kernel@vger.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: 10+ 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 15:10         ` Jeff Mahoney
2005-08-12 15:56           ` Tarmo Tänav
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox