All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH -next] staging: fwserial: Switch to kvfree_rcu() API
@ 2022-09-17  2:47 Shang XiaoJing
  2022-09-17  8:21 ` Andy Shevchenko
  0 siblings, 1 reply; 6+ messages in thread
From: Shang XiaoJing @ 2022-09-17  2:47 UTC (permalink / raw)
  To: gregkh, andy.shevchenko, ilpo.jarvinen, linux-staging; +Cc: shangxiaojing

Instead of invoking a synchronize_rcu() to free a pointer after a grace
period, we can directly make use of new API that does the same but in
more efficient way.

Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
---
sorry, the previous same patch have the wrong v3 flag in subject.
---
 drivers/staging/fwserial/fwserial.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/fwserial/fwserial.c b/drivers/staging/fwserial/fwserial.c
index 81b06d88ed0d..ac2d625f0883 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -2117,8 +2117,7 @@ static void fwserial_remove_peer(struct fwtty_peer *peer)
 	if (port)
 		fwserial_release_port(port, true);
 
-	synchronize_rcu();
-	kfree(peer);
+	kvfree_rcu(peer);
 }
 
 /**
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH -next] staging: fwserial: Switch to kvfree_rcu() API
  2022-09-17  2:47 [PATCH -next] staging: fwserial: Switch to kvfree_rcu() API Shang XiaoJing
@ 2022-09-17  8:21 ` Andy Shevchenko
  2022-09-19  1:43   ` shangxiaojing
  0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2022-09-17  8:21 UTC (permalink / raw)
  To: Shang XiaoJing; +Cc: gregkh, ilpo.jarvinen, linux-staging

On Sat, Sep 17, 2022 at 5:12 AM Shang XiaoJing <shangxiaojing@huawei.com> wrote:
>
> Instead of invoking a synchronize_rcu() to free a pointer after a grace
> period, we can directly make use of new API that does the same but in

a new

> more efficient way.

...

> sorry, the previous same patch have the wrong v3 flag in subject.

has

First of all, this brings even more confusion. Since the below needs
some work, we want to have a v4 with a proper changelog, explaining
also v1 and v3.

...

> -       synchronize_rcu();
> -       kfree(peer);
> +       kvfree_rcu(peer);

This is not equivalent. The commit message doesn't explain why the "v"
variant is needed. So, shouldn't it be the plain kfree_rcu()?

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH -next] staging: fwserial: Switch to kvfree_rcu() API
  2022-09-17  8:21 ` Andy Shevchenko
@ 2022-09-19  1:43   ` shangxiaojing
  2022-09-19  7:45     ` Andy Shevchenko
  0 siblings, 1 reply; 6+ messages in thread
From: shangxiaojing @ 2022-09-19  1:43 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: gregkh, ilpo.jarvinen, linux-staging


On 2022/9/17 16:21, Andy Shevchenko wrote:
> On Sat, Sep 17, 2022 at 5:12 AM Shang XiaoJing <shangxiaojing@huawei.com> wrote:
>> Instead of invoking a synchronize_rcu() to free a pointer after a grace
>> period, we can directly make use of new API that does the same but in
> a new
>
>> more efficient way.
> ...
>
>> sorry, the previous same patch have the wrong v3 flag in subject.
> has
>
> First of all, this brings even more confusion. Since the below needs
> some work, we want to have a v4 with a proper changelog, explaining
> also v1 and v3.

Ok, I 'll figure out a more clear changelog.

Besides, v3 is my miss, please ignore it, next patch will be v2.

>
> ...
>
>> -       synchronize_rcu();
>> -       kfree(peer);
>> +       kvfree_rcu(peer);
> This is not equivalent. The commit message doesn't explain why the "v"
> variant is needed. So, shouldn't it be the plain kfree_rcu()?

kfree_rcu() is defined as kvfree_rcu(), which will free the pointer with the

corresponding way(use is_vmalloc_addr() to determine vfree or kfree). For

clearlity, kfree_rcu() is a better way, will be fixed in patch v2.


Thanks :-),

Shang XiaoJing


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH -next] staging: fwserial: Switch to kvfree_rcu() API
  2022-09-19  1:43   ` shangxiaojing
@ 2022-09-19  7:45     ` Andy Shevchenko
  2022-09-19  7:50       ` shangxiaojing
  0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2022-09-19  7:45 UTC (permalink / raw)
  To: shangxiaojing; +Cc: gregkh, ilpo.jarvinen, linux-staging

On Mon, Sep 19, 2022 at 4:43 AM shangxiaojing <shangxiaojing@huawei.com> wrote:
> On 2022/9/17 16:21, Andy Shevchenko wrote:
> > On Sat, Sep 17, 2022 at 5:12 AM Shang XiaoJing <shangxiaojing@huawei.com> wrote:

...

> > First of all, this brings even more confusion. Since the below needs
> > some work, we want to have a v4 with a proper changelog, explaining
> > also v1 and v3.
>
> Ok, I 'll figure out a more clear changelog.
>
> Besides, v3 is my miss, please ignore it, next patch will be v2.

Versioning should go only one direction. You confuse people with your
versioning schema.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH -next] staging: fwserial: Switch to kvfree_rcu() API
  2022-09-19  7:45     ` Andy Shevchenko
@ 2022-09-19  7:50       ` shangxiaojing
  2022-09-19  8:27         ` Andy Shevchenko
  0 siblings, 1 reply; 6+ messages in thread
From: shangxiaojing @ 2022-09-19  7:50 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: gregkh, ilpo.jarvinen, linux-staging


On 2022/9/19 15:45, Andy Shevchenko wrote:
> On Mon, Sep 19, 2022 at 4:43 AM shangxiaojing <shangxiaojing@huawei.com> wrote:
>> On 2022/9/17 16:21, Andy Shevchenko wrote:
>>> On Sat, Sep 17, 2022 at 5:12 AM Shang XiaoJing <shangxiaojing@huawei.com> wrote:
> ...
>
>>> First of all, this brings even more confusion. Since the below needs
>>> some work, we want to have a v4 with a proper changelog, explaining
>>> also v1 and v3.
>> Ok, I 'll figure out a more clear changelog.
>>
>> Besides, v3 is my miss, please ignore it, next patch will be v2.
> Versioning should go only one direction. You confuse people with your
> versioning schema.

Should I send the sent patch "[PATCH -next v2] staging: fwserial: Switch 
to kfree_rcu() API" again as v4?


Thanks,

Shang XiaoJing


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH -next] staging: fwserial: Switch to kvfree_rcu() API
  2022-09-19  7:50       ` shangxiaojing
@ 2022-09-19  8:27         ` Andy Shevchenko
  0 siblings, 0 replies; 6+ messages in thread
From: Andy Shevchenko @ 2022-09-19  8:27 UTC (permalink / raw)
  To: shangxiaojing; +Cc: gregkh, ilpo.jarvinen, linux-staging

On Mon, Sep 19, 2022 at 10:50 AM shangxiaojing <shangxiaojing@huawei.com> wrote:
> On 2022/9/19 15:45, Andy Shevchenko wrote:
> > On Mon, Sep 19, 2022 at 4:43 AM shangxiaojing <shangxiaojing@huawei.com> wrote:
> >> On 2022/9/17 16:21, Andy Shevchenko wrote:
> >>> On Sat, Sep 17, 2022 at 5:12 AM Shang XiaoJing <shangxiaojing@huawei.com> wrote:

...

> >>> First of all, this brings even more confusion. Since the below needs
> >>> some work, we want to have a v4 with a proper changelog, explaining
> >>> also v1 and v3.
> >> Ok, I 'll figure out a more clear changelog.
> >>
> >> Besides, v3 is my miss, please ignore it, next patch will be v2.
> > Versioning should go only one direction. You confuse people with your
> > versioning schema.
>
> Should I send the sent patch "[PATCH -next v2] staging: fwserial: Switch
> to kfree_rcu() API" again as v4?

Yes, and explain in the changelog all of the previous ones, like
v3: the first version of the patch
v1: v3 resent as v1
v2: changed kv... to k...
v4: resend as v4 to avoid versioning confusion

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-09-19  8:27 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-17  2:47 [PATCH -next] staging: fwserial: Switch to kvfree_rcu() API Shang XiaoJing
2022-09-17  8:21 ` Andy Shevchenko
2022-09-19  1:43   ` shangxiaojing
2022-09-19  7:45     ` Andy Shevchenko
2022-09-19  7:50       ` shangxiaojing
2022-09-19  8:27         ` Andy Shevchenko

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.