2018-01-16 15:01:54

by Eremin, Dmitry

[permalink] [raw]
Subject: [PATCH] staging: lustre: Fix avoid intensive reconnecting for ko2iblnd patch

In the original commit 4d99b2581effe115376402e710fbcb1c3c073769
was missed one hunk. Added it now to avoid issue with use after free.

Signed-off-by: Dmitry Eremin <[email protected]>
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 2ebc484..a15a625 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -890,7 +890,8 @@ void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn)
atomic_dec(&net->ibn_nconns);
}

- kfree(conn);
+ if (free_conn)
+ kfree(conn);
}

int kiblnd_close_peer_conns_locked(struct kib_peer *peer, int why)
--
1.8.3.1


--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


2018-01-16 16:56:32

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH] staging: lustre: Fix avoid intensive reconnecting for ko2iblnd patch

On Tue, Jan 16, 2018 at 03:01:49PM +0000, Eremin, Dmitry wrote:
> In the original commit 4d99b2581effe115376402e710fbcb1c3c073769

Please use the documented way to write this:
4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd")

> was missed one hunk. Added it now to avoid issue with use after free.

And I do not understand this commit message at all.

>
> Signed-off-by: Dmitry Eremin <[email protected]>
> ---
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> index 2ebc484..a15a625 100644
> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> @@ -890,7 +890,8 @@ void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn)
> atomic_dec(&net->ibn_nconns);
> }
>
> - kfree(conn);
> + if (free_conn)
> + kfree(conn);

This looks really odd, don't you think?

thanks,

greg k-h

2018-01-17 00:36:23

by Dilger, Andreas

[permalink] [raw]
Subject: Re: [PATCH] staging: lustre: Fix avoid intensive reconnecting for ko2iblnd patch


> On Jan 16, 2018, at 09:56, Greg Kroah-Hartman <[email protected]> wrote:
>
> On Tue, Jan 16, 2018 at 03:01:49PM +0000, Eremin, Dmitry wrote:
>> In the original commit 4d99b2581effe115376402e710fbcb1c3c073769
>
> Please use the documented way to write this:
> 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd")
>

>> was missed one hunk. Added it now to avoid issue with use after free.
>
> And I do not understand this commit message at all.
>
>> Signed-off-by: Dmitry Eremin <[email protected]>
>> ---
>> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
>> index 2ebc484..a15a625 100644
>> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
>> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
>> @@ -890,7 +890,8 @@ void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn)
>> atomic_dec(&net->ibn_nconns);
>> }
>>
>> - kfree(conn);
>> + if (free_conn)
>> + kfree(conn);
>
> This looks really odd, don't you think?

I'm not sure what the objection is here? There is an argument to this
this function named "free_conn" which determines if the structure should
be freed, or if the network connection is just being torn down and
reconnected.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation







2018-01-17 14:03:47

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH] staging: lustre: Fix avoid intensive reconnecting for ko2iblnd patch

On Wed, Jan 17, 2018 at 12:36:19AM +0000, Dilger, Andreas wrote:
>
> > On Jan 16, 2018, at 09:56, Greg Kroah-Hartman <[email protected]> wrote:
> >
> > On Tue, Jan 16, 2018 at 03:01:49PM +0000, Eremin, Dmitry wrote:
> >> In the original commit 4d99b2581effe115376402e710fbcb1c3c073769
> >
> > Please use the documented way to write this:
> > 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd")
> >
>
> >> was missed one hunk. Added it now to avoid issue with use after free.
> >
> > And I do not understand this commit message at all.
> >
> >> Signed-off-by: Dmitry Eremin <[email protected]>
> >> ---
> >> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> >> index 2ebc484..a15a625 100644
> >> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> >> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> >> @@ -890,7 +890,8 @@ void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn)
> >> atomic_dec(&net->ibn_nconns);
> >> }
> >>
> >> - kfree(conn);
> >> + if (free_conn)
> >> + kfree(conn);
> >
> > This looks really odd, don't you think?
>
> I'm not sure what the objection is here? There is an argument to this
> this function named "free_conn" which determines if the structure should
> be freed, or if the network connection is just being torn down and
> reconnected.

At first glance it really looks like the normal pattern of:
if (foo_ptr)
kfree(foo_ptr);

right?

If you don't want to free the variable, set it to NULL.

Even then, this is a horrible function, you should have 2 different
ones:
kiblnd_destroy_conn(...)
kiblnd_free_conn()

and then just free the variable in the free_conn() function if you were
going to set the free_conn variable, right?

That way no odd code paths are taken, and it's obvious what you are
doing just by reading the code at the callsite.

thanks,

greg k-h