svn commit: r323944 - in head/sys: kern sys

[Gleb Smirnoff]

On Mon, Sep 25, 2017 at 02:46:37PM -0700, Stephen Hurd wrote:
S> > On Sat, Sep 23, 2017 at 01:39:16AM +0000, Stephen Hurd wrote:
S> > S> Author: shurd
S> > S> Date: Sat Sep 23 01:39:16 2017
S> > S> New Revision: 323944
S> > S> URL: https://svnweb.freebsd.org/changeset/base/323944
S> > S>
S> > S> Log:
S> > S>   Make struct grouptask gt_name member a char array
S> > S>
S> > S>   Previously, it was just a pointer which was copied, but
S> > S>   some callers pass in a stack variable which will go out of scope.
S> > S>   Add GROUPTASK_NAMELEN macro (32) and snprintf() the name into it,
S> > S>   using "grouptask" if name is NULL. We can now safely include
S> > S>   gtask->gt_name in console messages.
S> >
S> > Have you estimated which structures include struct grouptask, so
S> > that they now got larger?
S> 
S> I did take a look through and didn't see anything alarming in either 
S> iflib or the linuxkpi stuff which seem to be the only consumers at this 
S> time.
S> 
S> > Is this done only for the sake of console messages?
S> 
S> I'm not sure yet.  The member was already there and had pointers to the 
S> stack in it.  Nothing appeared to be consuming it, but I noticed the 
S> error while working on console messages, so that's all it's used for 
S> now.  I need to finish digging through the rest of the iflib backlog to 
S> see if there's another use for it.
S> 
S> The safest change seemed to be making it part of the structure and 
S> reviewing the usage later.

Thanks. I don't know much about grouptask, but regular struct task is
included in many structures throughout the kernel, that's why I express
my concerns.

-- 
Gleb Smirnoff