public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Tarmo Tänav" <tarmo@itech.ee>
To: Jeff Mahoney <jeffm@suse.com>
Cc: "Vladimir V. Saveliev" <vs@namesys.com>, Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, reiserfs-list@namesys.com,
	mason@suse.com, grev@namesys.com
Subject: Re: BUG: reiserfs+acl+quota deadlock
Date: Fri, 12 Aug 2005 18:56:00 +0300	[thread overview]
Message-ID: <1123862161.14093.4.camel@localhost> (raw)
In-Reply-To: <42FCBC00.2040903@suse.com>

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 <tarmo@itech.ee>


  reply	other threads:[~2005-08-12 15:56 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
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 [this message]
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=1123862161.14093.4.camel@localhost \
    --to=tarmo@itech.ee \
    --cc=grev@namesys.com \
    --cc=jack@suse.cz \
    --cc=jeffm@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mason@suse.com \
    --cc=reiserfs-list@namesys.com \
    --cc=vs@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