From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Minchan Kim <minchan@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC] mm/shrinker: define INIT_SHRINKER macro
Date: Sat, 11 Jul 2015 10:25:13 +0900 [thread overview]
Message-ID: <20150711012513.GB811@swordfish> (raw)
In-Reply-To: <20150710153235.835c4992fbce526da23361d0@linux-foundation.org>
On (07/10/15 15:32), Andrew Morton wrote:
> > Shrinker API does not handle nicely unregister_shrinker() on a not-registered
> > ->shrinker. Looking at shrinker users, they all have to (a) carry on some sort
> > of a flag telling that "unregister_shrinker()" will not blow up... or (b) just
> > be fishy
> >
> > ...
> >
> > I was thinking of a trivial INIT_SHRINKER macro to init `struct shrinker'
> > internal members (composed in email client, not tested)
> >
> > include/linux/shrinker.h
> >
> > #define INIT_SHRINKER(s) \
> > do { \
> > (s)->nr_deferred = NULL; \
> > INIT_LIST_HEAD(&(s)->list); \
> > } while (0)
>
> Spose so. Although it would be simpler to change unregister_shrinker()
> to bale out if list.next==NULL and then say "all zeroes is the
> initialized state".
Yes, or '->nr_deferred == NULL' -- we can't have NULL ->nr_deferred
in a properly registered shrinker (as of now)
register_shrinker()
...
shrinker->nr_deferred = kzalloc(size, GFP_KERNEL);
if (!shrinker->nr_deferred)
return -ENOMEM;
down_write(&shrinker_rwsem);
list_add_tail(&shrinker->list, &shrinker_list);
up_write(&shrinker_rwsem);
return 0;
...
But that will not work if someone has accidentally passed not zeroed
out pointer to unregister.
e.g.
...
struct foo *bar = kmalloc(..) /* no __GFP_ZERO */
... something goes wrong and we 'goto err' before
shrinker_register()
err:
unregister_shrinker(&bar->shrinker);
...
->list.next and ->nr_deferred won't help us here.
That was the reason to have INIT_SHRINKER/shrinker_init().
But adding an additional check to unregister_shrinker() will not harm.
> > --- a/include/linux/shrinker.h
> > +++ b/include/linux/shrinker.h
> > @@ -63,6 +63,12 @@ struct shrinker {
> > };
> > #define DEFAULT_SEEKS 2 /* A good number if you don't know better. */
> >
> > +#define INIT_SHRINKER(s) \
> > + do { \
> > + INIT_LIST_HEAD(&(s)->list); \
> > + (s)->nr_deferred = NULL; \
> > + } while (0)
> > +
>
> The only reason to make this a macro would be so that it can be used at
> compile-time, with something like
>
> static struct shrinker my_shrinker = INIT_SHRINKER(&my_shrinker);
>
> But as we're not planning on doing that, we implement it in C, please.
>
> Also, shrinker_init() would be a better name. Although we already
> mucked up shrinker_register() and shrinker_unregister().
>
Sure. Will do. Thanks.
-ss
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Minchan Kim <minchan@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC] mm/shrinker: define INIT_SHRINKER macro
Date: Sat, 11 Jul 2015 10:25:13 +0900 [thread overview]
Message-ID: <20150711012513.GB811@swordfish> (raw)
In-Reply-To: <20150710153235.835c4992fbce526da23361d0@linux-foundation.org>
On (07/10/15 15:32), Andrew Morton wrote:
> > Shrinker API does not handle nicely unregister_shrinker() on a not-registered
> > ->shrinker. Looking at shrinker users, they all have to (a) carry on some sort
> > of a flag telling that "unregister_shrinker()" will not blow up... or (b) just
> > be fishy
> >
> > ...
> >
> > I was thinking of a trivial INIT_SHRINKER macro to init `struct shrinker'
> > internal members (composed in email client, not tested)
> >
> > include/linux/shrinker.h
> >
> > #define INIT_SHRINKER(s) \
> > do { \
> > (s)->nr_deferred = NULL; \
> > INIT_LIST_HEAD(&(s)->list); \
> > } while (0)
>
> Spose so. Although it would be simpler to change unregister_shrinker()
> to bale out if list.next==NULL and then say "all zeroes is the
> initialized state".
Yes, or '->nr_deferred == NULL' -- we can't have NULL ->nr_deferred
in a properly registered shrinker (as of now)
register_shrinker()
...
shrinker->nr_deferred = kzalloc(size, GFP_KERNEL);
if (!shrinker->nr_deferred)
return -ENOMEM;
down_write(&shrinker_rwsem);
list_add_tail(&shrinker->list, &shrinker_list);
up_write(&shrinker_rwsem);
return 0;
...
But that will not work if someone has accidentally passed not zeroed
out pointer to unregister.
e.g.
...
struct foo *bar = kmalloc(..) /* no __GFP_ZERO */
... something goes wrong and we 'goto err' before
shrinker_register()
err:
unregister_shrinker(&bar->shrinker);
...
->list.next and ->nr_deferred won't help us here.
That was the reason to have INIT_SHRINKER/shrinker_init().
But adding an additional check to unregister_shrinker() will not harm.
> > --- a/include/linux/shrinker.h
> > +++ b/include/linux/shrinker.h
> > @@ -63,6 +63,12 @@ struct shrinker {
> > };
> > #define DEFAULT_SEEKS 2 /* A good number if you don't know better. */
> >
> > +#define INIT_SHRINKER(s) \
> > + do { \
> > + INIT_LIST_HEAD(&(s)->list); \
> > + (s)->nr_deferred = NULL; \
> > + } while (0)
> > +
>
> The only reason to make this a macro would be so that it can be used at
> compile-time, with something like
>
> static struct shrinker my_shrinker = INIT_SHRINKER(&my_shrinker);
>
> But as we're not planning on doing that, we implement it in C, please.
>
> Also, shrinker_init() would be a better name. Although we already
> mucked up shrinker_register() and shrinker_unregister().
>
Sure. Will do. Thanks.
-ss
next prev parent reply other threads:[~2015-07-11 1:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 1:12 [RFC] mm/shrinker: define INIT_SHRINKER macro Sergey Senozhatsky
2015-07-10 1:12 ` Sergey Senozhatsky
2015-07-10 22:32 ` Andrew Morton
2015-07-10 22:32 ` Andrew Morton
2015-07-11 1:25 ` Sergey Senozhatsky [this message]
2015-07-11 1:25 ` Sergey Senozhatsky
2015-07-11 1:33 ` Andrew Morton
2015-07-11 1:33 ` Andrew Morton
2015-07-11 1:48 ` Sergey Senozhatsky
2015-07-11 1:48 ` Sergey Senozhatsky
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=20150711012513.GB811@swordfish \
--to=sergey.senozhatsky@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=sergey.senozhatsky.work@gmail.com \
/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 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.