Re: [ 09/76] lockd: use rpc clients cl_nodename for id encoding

[Ben Hutchings]

On Thu, Oct 18, 2012 at 07:46:33PM -0700, Greg Kroah-Hartman wrote:
> 3.6-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx>
> 
> commit 303a7ce92064c285a04c870f2dc0192fdb2968cb upstream.
> 
> Taking hostname from uts namespace if not safe, because this cuold be
> performind during umount operation on child reaper death. And in this case
> current->nsproxy is NULL already.
> 
> Signed-off-by: Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx>
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> 
> ---
>  fs/lockd/mon.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> --- a/fs/lockd/mon.c
> +++ b/fs/lockd/mon.c
> @@ -42,6 +42,7 @@ struct nsm_args {
>  	u32			proc;
>  
>  	char			*mon_name;
> +	char			*nodename;
>  };
>  
>  struct nsm_res {
> @@ -141,6 +142,7 @@ static int nsm_mon_unmon(struct nsm_hand
>  		.vers		= 3,
>  		.proc		= NLMPROC_NSM_NOTIFY,
>  		.mon_name	= nsm->sm_mon_name,
> +		.nodename	= utsname()->nodename,

Can we be sure that this string pointer will remain valid at the point
where current->nsproxy has become NULL?  Or should nsm_args::nodename
actually be a copy of the string?

Ben.

>  	};
>  	struct rpc_message msg = {
>  		.rpc_argp	= &args,
> @@ -477,7 +479,7 @@ static void encode_my_id(struct xdr_stre
>  {
>  	__be32 *p;
>  
> -	encode_nsm_string(xdr, utsname()->nodename);
> +	encode_nsm_string(xdr, argp->nodename);
>  	p = xdr_reserve_space(xdr, 4 + 4 + 4);
>  	*p++ = cpu_to_be32(argp->prog);
>  	*p++ = cpu_to_be32(argp->vers);

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/