linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Josef 'Jeff' Sipek" <jeffpc@josefsipek.net>
To: Hugh Dickins <hugh@veritas.com>
Cc: Erez Zadok <ezk@cs.sunysb.edu>,
	akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
	hch@infradead.org
Subject: Re: fs_stack/eCryptfs: remove 3rd arg of copy_attr_all, add locking to copy_inode_size
Date: Thu, 3 Apr 2008 15:31:27 -0400	[thread overview]
Message-ID: <20080403193127.GA640@josefsipek.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0804032014350.4616@blonde.site>

On Thu, Apr 03, 2008 at 08:26:54PM +0100, Hugh Dickins wrote:
> On Thu, 3 Apr 2008, Erez Zadok wrote:
> > In message <20080403182001.GB30189@josefsipek.net>, "Josef 'Jeff' Sipek" writes:
> > > I think you need to check CONFIG_PREEMPT as well.
> > 
> > I'm not sure if it's needed in case of CONFIG_PREEMPT.  Anyone?  The code
> > for i_size_write (below), and the comment at the top of the function,
> > suggest that the spinlock is needed only to prevent the lots seqcount.
> 
> Correct.
 
True...

> > BTW, some time ago I reviewed all callers of i_size_write.  I did so again
> > just now, and the results were the same:
> > 
> > - a LOT of callers of i_size_write don't take any lock
> 
> They mostly know that i_mutex is already held (as i_size_write comment
> mentions); but I believe that's up to the individual filesystem.

Is this function (fsstack_copy_inode_size) used only in unlocked paths? If
there's little chance that it'll ever need to be used in locked paths, then
sure, why not have the lock right in the function.

Josef 'Jeff' Sipek.

-- 
My public GPG key can be found at
http://www.josefsipek.net/gpg/public-0xC7958FFE.txt

      reply	other threads:[~2008-04-03 19:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-03  1:49 fs_stack/eCryptfs: remove 3rd arg of copy_attr_all, add locking to copy_inode_size Erez Zadok
2008-04-03  2:26 ` Andrew Morton
2008-04-03 18:20 ` Josef 'Jeff' Sipek
2008-04-03 19:02   ` Hugh Dickins
2008-04-03 19:07   ` Erez Zadok
2008-04-03 19:26     ` Hugh Dickins
2008-04-03 19:31       ` Josef 'Jeff' Sipek [this message]

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=20080403193127.GA640@josefsipek.net \
    --to=jeffpc@josefsipek.net \
    --cc=akpm@linux-foundation.org \
    --cc=ezk@cs.sunysb.edu \
    --cc=hch@infradead.org \
    --cc=hugh@veritas.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).