From: Nicholas Krause <xerofoify@gmail.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] f2fs crypto: add rwsem to avoid data races
Date: Tue, 19 May 2015 20:47:12 -0400 [thread overview]
Message-ID: <55CD0467-9C9F-4B30-83E2-A29AF28DE794@gmail.com> (raw)
In-Reply-To: <20150520003859.GA55280@jaegeuk-mac02.mot.com>
On May 19, 2015 8:38:59 PM EDT, Jaegeuk Kim <jaegeuk@kernel.org> wrote:
>On Tue, May 19, 2015 at 10:35:30AM -0400, nick wrote:
>>
>>
>> On 2015-05-19 10:29 AM, Theodore Ts'o wrote:
>> > On Mon, May 18, 2015 at 10:36:41PM -0700, Jaegeuk Kim wrote:
>> >> Previoulsy, fi->i_crypt_info was not covered by any lock,
>resulting in
>> >> memory leak.
>> >>
>> >> This patch adds a rwsem to avoid leaking objects on i_crypt_info.
>> >>
>> >> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>> >
>> > I'm not sure we need an rwsem to fix this issue. In terms of
>> > serializing the creation and deletion of the structure, it should
>be
>> > possible to use an cmpxchg() on the pointer itself. (e.g., if we
>lose
>> > the race on the creation side, we just release our structure and
>use
>> > the one that the winner allocated).
>> >
>> > If we do end up needing to serialize access to the tfm in the
>> > i_crypt_info object for datapath reads/writes, then we might need a
>> > mutex, but I think that should be it, no?
>> >
>> > - Ted
>> >
>> I have to agree with Ted here, as mutual exclusion locking is ideal
>> for the scenario here of a reader vs writer exclusion. My only
>concern
>
>What I'm saying is writer vs writer actually.
>
>> is that can there be many readers to one writer here as if so
>reader/writer
>> spin locks may be better.
>
>I could write another patch using a rwlock by removing needless
>down_write for
>f2fs_free_encryption_info.
>
That sounds good to me, I wasn't sure if it was writer vs writer or reader vs writer. However rwlocks are the easiest way to avoid dealing with semaphones as you seem interested in avoiding writing one into the f2fs code with this patch.
Nick
>Thanks,
>
>> Nick
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
next prev parent reply other threads:[~2015-05-20 0:46 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 [this message]
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
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=55CD0467-9C9F-4B30-83E2-A29AF28DE794@gmail.com \
--to=xerofoify@gmail.com \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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).