From: "William A. (Andy) Adamson" <androsadamson@gmail.com>
To: Benny Halevy <bhalevy@panasas.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 0/5] pnfs-submit fix kfree under spin lock
Date: Wed, 21 Jul 2010 10:46:15 -0400 [thread overview]
Message-ID: <AANLkTimYOLwLskHupGwk0HJpGA9gES_Ooe=stFt5LJpr@mail.gmail.com> (raw)
In-Reply-To: <4C46A08D.1000604@panasas.com>
On Wed, Jul 21, 2010 at 3:23 AM, Benny Halevy <bhalevy@panasas.com> wro=
te:
> On Jul. 20, 2010, 20:30 +0300, "William A. (Andy) Adamson" <androsada=
mson@gmail.com> wrote:
>> Trond and Fred informed me that kfree under a spin lock is actually
>> OK. So, maybe these patches aren't needed.
>>
>> On the other hand, with these patches we don't hold the spin lock ov=
er
>> function calls which to my mind is easier to read. Also, the
>> free_layout/free_lseg layoutdriver calls may do more than call kfree=
=2E
>
> I'm all for that.
> Just document they must not block.
> If we ever see that as a requirement we can then change the caller
> to drop the spin lock before calling the free method.
You might consider the first patch which combines looking up an lseg
and allocating the pnfs_layout_type. They are really the same job, and
I think it's more clear what is going on.
-->Andy
>
> Beny
>
>>
>> At least, we should document what we expect from the
>> free_layout/free_lseg - e.g. no side affects that conflict with bein=
g
>> called under a spinlock..
>>
>> -->Andy
>>
>> On Tue, Jul 20, 2010 at 1:01 PM, =A0<andros@netapp.com> wrote:
>>>
>>> Fix kfree under spin lock
>>>
>>> Both put_lseg and put_layout are called under the inode i_lock wher=
e the
>>> last reference will end up freeing structures.
>>>
>>> I know there has been a lot of churn in this code, but free'ing und=
er the
>>> spin lock is a no-no.
>>> In this patch I refactor the layout allocation, combining it with t=
he
>>> layout segment lookup code. The new function, pnfs_get_layout_segme=
nt takes
>>> inode spin lock, and looks to see if the requested range is service=
d by an
>>> existing layout segment. If the layout has not been allocated, allo=
cate it.
>>> If a layout segement is found, reference it and give up the lock. I=
f no
>>> layout segment is found, reference the layout for the layoutget cal=
l and
>>> give up the lock.
>>>
>>> 0001-SQUASHME-pnfs-submit-alloc-layout-don-t-call-put_lay.patch
>>> 0002-SQUASHME-pnfs-submit-use-atomic_dec_and_lock-for-lay.patch
>>>
>>> Fix the put_lseg under spin lock.
>>> 0003-SQUASHME-pnfs-submit-don-t-call-put_lseg-under-spin-.patch
>>>
>>> Cleanup.
>>> 0004-SQUASHME-pnfs-submit-pnfs_release_layout-just-use-in.patch
>>> 0005-SQUASHME-pnfs-submit-fix-has_layout-compile-error.patch
>>>
>>> Tests:
>>> CONFIG_NFS_V4_1 set:
>>> Connectathon tests pass against GFS2 and pyNFS file layout servers.
>>>
>>> CONFIG_NFS_V4_1 not set:
>>> Connectathon tests pass.
>>>
>>> -->Andy
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs=
" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.htm=
l
>>>
>
next prev parent reply other threads:[~2010-07-21 14:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-20 17:01 [PATCH 0/5] pnfs-submit fix kfree under spin lock andros
2010-07-20 17:01 ` [PATCH 1/5] SQUASHME pnfs-submit alloc layout don't call put_layout " andros
2010-07-20 17:01 ` [PATCH 2/5] SQUASHME pnfs-submit use atomic_dec_and_lock for layout refcounting andros
2010-07-20 17:01 ` [PATCH 3/5] SQUASHME pnfs-submit don't call put_lseg under spin lock andros
2010-07-20 17:01 ` [PATCH 4/5] SQUASHME pnfs-submit pnfs_release_layout just use inode andros
2010-07-20 17:01 ` [PATCH 5/5] SQUASHME pnfs-submit fix has_layout compile error andros
2010-07-22 16:26 ` [PATCH 1/5] SQUASHME pnfs-submit alloc layout don't call put_layout under spin lock Benny Halevy
2010-07-20 17:30 ` [PATCH 0/5] pnfs-submit fix kfree " William A. (Andy) Adamson
[not found] ` <AANLkTikzt-A69kM863U=YuGZ1-HGWr51KsJEts3uKFx6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-07-21 7:23 ` Benny Halevy
2010-07-21 14:46 ` William A. (Andy) Adamson [this message]
2010-07-20 19:09 ` Christoph Hellwig
2010-07-20 20:36 ` William A. (Andy) Adamson
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='AANLkTimYOLwLskHupGwk0HJpGA9gES_Ooe=stFt5LJpr@mail.gmail.com' \
--to=androsadamson@gmail.com \
--cc=bhalevy@panasas.com \
--cc=linux-nfs@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;
as well as URLs for NNTP newsgroup(s).