On Mon, Jul 12, 2010 at 1:43 PM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
> On 07/12/2010 08:34 PM, William A. (Andy) Adamson wrote:
>> On Mon, Jul 12, 2010 at 12:29 PM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
>>>> static inline bool
>>>> layoutcommit_needed(struct nfs_inode *nfsi)
>>>> {
>>>> - return test_bit(NFS_INO_LAYOUTCOMMIT, &nfsi->layout.pnfs_layout_state);
>>>> + return has_layout(nfsi) &&
>>>> + test_bit(NFS_INO_LAYOUTCOMMIT, &nfsi->layout->pnfs_layout_state);
>>>
>>> What is the purpose of patch[1/1] ?
>>
>> To not segfault when the nfs_inode->layout field is NULL.
>>
>
> Yes that is this patch [3/16].
>
> I was asking about [PATCH 01/16] that changed it to a state_bit from lo_cred
> why do we need that one. Now that you proved that has_layout(nfsi) cannot become
> negative on us while asking?
Hmm. Looks like you're right, it's not needed. We do need to document
that the existance of the lo_cred is what signals the need for layout
commit.....
Thanks
-->Andy
>
>>>
>>> you are unlocked and asking about a layout pointer. Which according to you might
>>> go away mid-flight?
>>
>> No, it simply has not been allocated. The pnfs_layout_type reference
>> counting will be done under the inode->i_lock and all in-flight RPC's
>> will hold a reference, so there is no reason to hold a lock to call
>> has_layout().
>>
>
> I agree it is safe.
>
> Boaz
>
>> -->Andy
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
