linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: nick <xerofoify@gmail.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs crypto: add rwsem to avoid data races
Date: Wed, 20 May 2015 08:38:30 -0400	[thread overview]
Message-ID: <20150520123830.GE2871@thunk.org> (raw)
In-Reply-To: <20150520045554.GA56982@jaegeuk-mac02.hsd1.ca.comcast.net>

On Tue, May 19, 2015 at 09:55:54PM -0700, Jaegeuk Kim wrote:
> 
> Looking at a glance, it's mostly same as what I wanted. The key is to share
> ci->ci_ctfm for regular file and the other dir/symlink files.
> So, ext4_get_encryption_info will handle most of cases.

Yeah, I noticed after sending out my changes that your patches did
something really similar in that regard.  "Great minds run in the same
channels", as the (very) old saying goes...

> In ext4_readdir, it also needs ext4_get_encryption_info?

No, it not needed because when the directory is opened using
opendir(3), we'll end up calling ext4_get_encryption_info() in
ext4_file_open() --- yes, the name is a little misleading, but it gets
used for all ext4 open(2)'s.

One of the things which I've been mildly concerned about is that in
the no key case, we end up calling ext4_get_encrpyion_info() over and
over again, which means we end up calling request_key() over and over
again as well.  On the other hand, we do want to use the key as soon
as it becomes available, there isn't a good way of doing a negative
cache on the unavailability of the logon key that could be reliably
revoked the moment the user does have the key --- and the no-key case
isn't the common one, so I haven't worried too much about it.  But I
did want to remove it from the readdir() path, since it also means
that we don't have to worry about oddities stemming from half the
files being returned in encrypted form, and half the files in
plaintext, because the user inserted an encryption key in the while
there was an "ls" running in the background.

Cheers,

						- Ted

  reply	other threads:[~2015-05-20 12:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-19  5:36 [PATCH] f2fs crypto: add rwsem to avoid data races Jaegeuk Kim
2015-05-19 14:29 ` Theodore Ts'o
2015-05-19 14:35   ` nick
2015-05-20  0:38     ` [f2fs-dev] " Jaegeuk Kim
2015-05-20  0:47       ` Nicholas Krause
2015-05-20  4:35       ` Theodore Ts'o
2015-05-20  4:55         ` [f2fs-dev] " Jaegeuk Kim
2015-05-20 12:38           ` Theodore Ts'o [this message]
2015-05-19 17:42   ` Jaegeuk Kim

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=20150520123830.GE2871@thunk.org \
    --to=tytso@mit.edu \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xerofoify@gmail.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;
as well as URLs for NNTP newsgroup(s).