public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nikanth Karthikesan <knikanth@suse.de>
To: balbir@linux.vnet.ibm.com
Cc: Paul Menage <menage@google.com>,
	lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] taskstats: Fix CGROUPSTATS_TYPE_CGROUP_STATS having same value as TASKSTATS_TYPE_PID
Date: Mon, 13 Jul 2009 21:07:37 +0530	[thread overview]
Message-ID: <200907132107.37850.knikanth@suse.de> (raw)
In-Reply-To: <20090713134158.GD5051@balbir.in.ibm.com>

On Monday 13 July 2009 19:11:58 Balbir Singh wrote:
> * Nikanth Karthikesan <knikanth@suse.de> [2009-07-13 18:31:12]:
> > Hi
> >
> > Currently we never get message from kernel to userspace of type
> > TASKSTATS_TYPE_PID. Otherwise this could have been spotted earlier.
> >
> > I was trying to add a new taskstat command that would return response of
> > type TASKSTATS_TYPE_PID.
> >
> > Having the same values would restrict one not to use the same netlink
> > socket for a command that would return response of type
> > TASKSTATS_TYPE_PID and the CGROUPSTATS_CMD_GET command.
> >
> > Should we fix it by using values after __TASKSTATS_TYPE_MAX.
> >
> > Changing this now might break pre-built binaries. Or is this intended,
> > and the application is not supposed to use CGROUPSTATS and TASKSTATS on
> > the same socket?
>
> Ideally they are supposed to be on different sockets, but nothing
> really is hard and fast in terms of rules.
>

IMHO, If we are adding CGROUPSTATS_CMD_GET to the same netlink family of 
TASKSTATS, we should allow both the commands in the same socket.

> > Thanks
> > Nikanth
> >
> > Currently we never get message from kernel to userspace of type
> > TASKSTATS_TYPE_PID. Otherwise this could have been spotted earlier.
> > Having the values in the same range would restrict one not to use the
> > same netlink socket for a command that would return response of type
> > TASKSTATS_TYPE_PID and the CGROUPSTATS_CMD_GET command. Fix it by using
> > values after
> > __TASKSTATS_TYPE_MAX.
> >
> > Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
> >
> > ---
> >
> >
> > diff --git a/include/linux/cgroupstats.h b/include/linux/cgroupstats.h
> > index 3753c33..87b31f0 100644
> > --- a/include/linux/cgroupstats.h
> > +++ b/include/linux/cgroupstats.h
> > @@ -53,7 +53,7 @@ enum {
> >  #define CGROUPSTATS_CMD_MAX (__CGROUPSTATS_CMD_MAX - 1)
> >
> >  enum {
> > -	CGROUPSTATS_TYPE_UNSPEC = 0,	/* Reserved */
> > +	CGROUPSTATS_TYPE_UNSPEC = __TASKSTATS_TYPE_MAX,	/* Reserved */
> >  	CGROUPSTATS_TYPE_CGROUP_STATS,	/* contains name + stats */
> >  	__CGROUPSTATS_TYPE_MAX,
> >  };
>
> This seems like the correct fix
>
> Reviewed-by: Balbir Singh <balbir@linux.vnet.ibm.com>

But this would break applications every time a new item is added to the enums 
in taskstat.h

The correct fix would be to add all the CGROUPSTATS_* enums, as part of the 
same enum in taskstat.h. So that when new members are added to enum's in 
taskstat.h, the cgroup stat enum's values won't change and applications need 
not be re-built. If you agree, I would send a patch to do that.

Thanks
Nikanth

  reply	other threads:[~2009-07-13 15:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-13 13:01 [RFC][PATCH] taskstats: Fix CGROUPSTATS_TYPE_CGROUP_STATS having same value as TASKSTATS_TYPE_PID Nikanth Karthikesan
2009-07-13 13:41 ` Balbir Singh
2009-07-13 15:37   ` Nikanth Karthikesan [this message]
2009-07-13 15:53     ` Balbir Singh
2009-07-14 10:57       ` Nikanth Karthikesan
2009-07-13 15:46   ` Nikanth Karthikesan
2009-07-13 15:54     ` Balbir Singh
2009-07-13 16:53       ` [PATCH] taskstats: Unify cgroupstats.h with taskstats.h and use a single nla_policy Nikanth Karthikesan

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=200907132107.37850.knikanth@suse.de \
    --to=knikanth@suse.de \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=menage@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox