linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Boqun Feng <boqun.feng@gmail.com>
To: Rao Shoaib <rao.shoaib@oracle.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	linux-kernel@vger.kernel.org, paulmck@linux.vnet.ibm.com,
	brouer@redhat.com, linux-mm@kvack.org
Subject: Re: [PATCH 1/2] Move kfree_call_rcu() to slab_common.c
Date: Thu, 4 Jan 2018 09:38:07 +0800	[thread overview]
Message-ID: <20180104013807.GA31392@tardis> (raw)
In-Reply-To: <3be609d4-800e-a89e-f885-7e0f5d288862@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 3991 bytes --]

Hi Shoaib,

Good to see you set out a patchset ;-)

On Tue, Jan 02, 2018 at 02:49:25PM -0800, Rao Shoaib wrote:
> 
> 
> On 01/02/2018 02:23 PM, Matthew Wilcox wrote:
> > On Tue, Jan 02, 2018 at 12:11:37PM -0800, rao.shoaib@oracle.com wrote:
> > > -#define kfree_rcu(ptr, rcu_head)					\
> > > -	__kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head))
> > > +#define kfree_rcu(ptr, rcu_head_name)	\
> > > +	do { \
> > > +		typeof(ptr) __ptr = ptr;	\
> > > +		unsigned long __off = offsetof(typeof(*(__ptr)), \
> > > +						      rcu_head_name); \
> > > +		struct rcu_head *__rptr = (void *)__ptr + __off; \
> > > +		__kfree_rcu(__rptr, __off); \
> > > +	} while (0)
> > I feel like you're trying to help people understand the code better,
> > but using longer names can really work against that.  Reverting to
> > calling the parameter 'rcu_head' lets you not split the line:
> I think it is a matter of preference, what is the issue with line splitting
> ?
> Coming from a background other than Linux I find it very annoying that Linux
> allows variables names that are meaning less. Linux does not even enforce
> adding a prefix for structure members, so trying to find out where a member
> is used or set is impossible using cscope.
> I can not change the Linux requirements so I will go ahead and make the
> change in the next rev.
> 
> > 
> > +#define kfree_rcu(ptr, rcu_head)	\
> > +	do { \
> > +		typeof(ptr) __ptr = ptr;	\
> > +		unsigned long __off = offsetof(typeof(*(__ptr)), rcu_head); \
> > +		struct rcu_head *__rptr = (void *)__ptr + __off; \
> > +		__kfree_rcu(__rptr, __off); \
> > +	} while (0)
> > 
> > Also, I don't understand why you're bothering to create __ptr here.
> > I understand the desire to not mention the same argument more than once,
> > but you have 'ptr' twice anyway.
> > 
> > And it's good practice to enclose macro arguments in parentheses in case
> > the user has done something really tricksy like pass in "p + 1".
> > 
> > In summary, I don't see anything fundamentally better in your rewrite
> > of kfree_rcu().  The previous version is more succinct, and to my
> > mind, easier to understand.
> I did not want to make thins change but it is required due to the new tests
> added for macro expansion where the same name as in the macro can not be
> used twice. It takes care of the 'p + 1' hazard that you refer to above.
> > 
> > > +void call_rcu_lazy(struct rcu_head *head, rcu_callback_t func)
> > > +{
> > > +	__call_rcu(head, func, &rcu_sched_state, -1, 1);
> > > +}
> > > -void kfree_call_rcu(struct rcu_head *head,
> > > -		    rcu_callback_t func)
> > > -{
> > > -	__call_rcu(head, func, rcu_state_p, -1, 1);
> > > -}
> > You've silently changed this.  Why?  It might well be the right change,
> > but it at least merits mentioning in the changelog.
> This was to address a comment about me not changing the tiny implementation
> to be same as the tree implementation.
> 

But you introduced a bug here, you should use rcu_state_p instead of
&rcu_sched_state as the third parameter for __call_rcu().

Please re-read:

	https://marc.info/?l=linux-mm&m=151390529209639

, and there are other comments, which you still haven't resolved in this
version. You may want to write a better commit log to explain the
reasons of each modifcation and fix bugs or typos in your previous
version. That's how review process works ;-)

Regards,
Boqun

> Shoaib
> > 
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-01-04  1:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-02 20:11 [PATCH 1/2] Move kfree_call_rcu() to slab_common.c rao.shoaib
2018-01-02 20:11 ` [PATCH 2/2] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures rao.shoaib
2018-01-02 22:23 ` [PATCH 1/2] Move kfree_call_rcu() to slab_common.c Matthew Wilcox
2018-01-02 22:49   ` Rao Shoaib
2018-01-04  1:38     ` Boqun Feng [this message]
2018-01-04 20:35       ` Rao Shoaib
2018-01-04 21:27         ` Rao Shoaib
2018-01-04 21:46           ` Matthew Wilcox
2018-01-04 22:18             ` Rao Shoaib
2018-01-04 23:13               ` Matthew Wilcox
2018-01-04 23:47                 ` Paul E. McKenney
2018-01-05  0:07                   ` Matthew Wilcox
2018-01-05  2:14                     ` Rao Shoaib
2018-01-05  6:46                     ` Joe Perches
2018-03-27  1:56                       ` Rao Shoaib
2018-03-27  2:06                         ` Joe Perches
  -- strict thread matches above, loose matches on Subject: below --
2018-04-02  5:31 [PATCH 0/2] Move kfree_rcu out of rcu code and use kfree_bulk rao.shoaib
2018-04-02  5:31 ` [PATCH 1/2] Move kfree_call_rcu() to slab_common.c rao.shoaib
2018-04-02  7:59   ` kbuild test robot
2018-04-02  9:45   ` kbuild test robot
2018-04-02 15:43     ` Paul E. McKenney
2018-04-03 17:22 [PATCH 0/2] Move kfree_rcu out of rcu code and use kfree_bulk rao.shoaib
2018-04-03 17:22 ` [PATCH 1/2] Move kfree_call_rcu() to slab_common.c rao.shoaib

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180104013807.GA31392@tardis \
    --to=boqun.feng@gmail.com \
    --cc=brouer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rao.shoaib@oracle.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).