On Mon, Jan 12, 2015 at 01:14:19AM -0500, Tom Haynes wrote:
>
> > +file system must sit on shared storage (typically iSCSI) that is accessible
> > +to the clients as well as the server. The file system needs to either sit
> > +directly on the exported volume, or on a RAID 0 using the MD software RAID
>
> a RAID 0 what?
I don't quite understand that comment. But I'll have to revise that
text anyway as the RAID0/1 support isn't part of this submission yet,
as it needs a little more work and involves two more subsystems.
For those who are curious about the md support, it is available at:
git://git.infradead.org/users/hch/pnfs.git pnfsd-block-md-support
> What reclaims bex in both error cases??
>
> The call flow seems to be:
>
> nfsd4_proc_compound -> nfsd4_layoutget -> nfsd4_block_proc_layoutget
>
> lg_content gets freed in nfsd4_encode_layoutget() in all paths.
>
> nfsd4_encode_operation() calls nfsd4_encode_layoutget().
>
> But nfsd4_encode_layoutget() is not called in all paths:
>
> p = xdr_reserve_space(xdr, 8);
> if (!p) {
> WARN_ON_ONCE(1);
> return; // leak
> }
> ...
> if (op->opnum == OP_ILLEGAL)
> goto status; // Not really a leak, if we hit this, bigger issues apply.
>
> So bex is correctly accounted for, but in general
> nfsd4_encode_operation() can leak any operation
> specific memory.
I guess we need to fix properly in the nfsd core eventually. For
example by adding a new method called for successful and error completions
that can free all ressources.
--
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
