mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steve French <smfltc@us.ibm.com>
To: linux-kernel@vger.kernel.org
Subject: how to safely not grab a semaphore when you already have it (rename sem)
Date: 25 May 2004 14:34:26 -0500	[thread overview]
Message-ID: <1085513665.11307.56.camel@stevef95.austin.ibm.com> (raw)

How do you safely test and not grab a semaphore (ie if the kernel above
you already has it ...) - without deadlock?

Al Viro correctly noted that walking a tree to build a full path can not
be safely done due to races with rename.   Unfortunately for some
filesystems (including cifs), the only obvious way to protect against
this would be to grab the rename sem for the superblock everywhere a
full path is built e.g.

	down(&i_sb->s_vfs_rename_sem);

but of course this would deadlock (vfs_rename calls at least 3 path
based operations in a filesystem, all while holding the rename sem - in
particular rename can make two lookup calls and a rename call into a vfs
while holding the sem).   At least the lookup/revalidate path in the
filesystem would require a check such as: 

if(!we_are_called_from_sys_rename)
	down(&i_sb->s_vfs_rename_sem);

build_fullpath_from_dentry(dentry);

if(!we_are_called_from_sys_rename)
	up(&_sb->s_vfs_rename_sem);

and there is no need to grab the semaphore in cifs_rename at all (it is
already held by the caller).  Unfortuantely I don't know of any way to
tell that we are in lookup/revalidate called from sys_rename other than
trying to grab the rename sem and deadlocking.

Alternatively, is there were a way to do something like:

if(our task is not owner of rename sem) {
	down(&i_sb->s_vfs_rename_sem);
	build_fullpath_from_dentry(dentry);
	up(&_sb->s_vfs_rename_sem); 
} else /* our caller had already gotten rename sem */
	build_fullpath_from_dentry(dentry);
	



                 reply	other threads:[~2004-05-25 19:35 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1085513665.11307.56.camel@stevef95.austin.ibm.com \
    --to=smfltc@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®