All of lore.kernel.org
 help / color / mirror / Atom feed
From: nick <xerofoify@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>, Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@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 10:35:30 -0400	[thread overview]
Message-ID: <555B4A32.3000302@gmail.com> (raw)
In-Reply-To: <20150519142943.GE20421@thunk.org>



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
> 
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> 
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
is that can there be many readers to one writer here as if so reader/writer
spin locks may be better.
Nick  

------------------------------------------------------------------------------
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

  reply	other threads:[~2015-05-19 14:35 UTC|newest]

Thread overview: 10+ 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 [this message]
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:35         ` [f2fs-dev] " Theodore Ts'o
2015-05-20  4:55         ` 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=555B4A32.3000302@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.