From: Stephen Hemminger <shemminger@vyatta.com>
To: Jiri Pirko <jpirko@redhat.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
eric.dumazet@gmail.com, mirqus@gmail.com, xemul@openvz.org
Subject: Re: [patch net-next-2.6] net: call dev_alloc_name from register_netdevice
Date: Sat, 30 Apr 2011 21:47:35 -0700 [thread overview]
Message-ID: <20110430214735.73036260@nehalam> (raw)
In-Reply-To: <20110430205752.GE2658@psychotron.orion>
On Sat, 30 Apr 2011 22:57:52 +0200
Jiri Pirko <jpirko@redhat.com> wrote:
> Sat, Apr 30, 2011 at 07:34:44PM CEST, shemminger@vyatta.com wrote:
> >On Sat, 30 Apr 2011 13:21:32 +0200
> >Jiri Pirko <jpirko@redhat.com> wrote:
> >
> >> Force dev_alloc_name() to be called from register_netdevice() by
> >> dev_get_valid_name(). That allows to remove multiple explicit
> >> dev_alloc_name() calls.
> >>
> >> The possibility to call dev_alloc_name in advance remains.
> >>
> >> This also fixes veth creation regresion caused by
> >> 84c49d8c3e4abefb0a41a77b25aa37ebe8d6b743
> >>
> >> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> >
> >The problem with this then you have to audit all the calls
> >to register_netdevice to make sure that user can't provide a bad
> >value which then is passed a format string. Why not just fix
> >just veth which would be safer.
>
> Well it looks convenient to do name allocations inside
> register_netdevice generically. For special cases dev_get_valid_name()
> can be still used as before (this I think should be also prohibited in
> future).
>
> Also I think that drivers should be responsible for what they are
> passing from user to core. Btw could you please give me an example of
> "a bad value" causing any harm in particular situation?
>
> Thanks
>
> Jirka
I am concerned that code like that before a driver could be passed
a string with format characters; and make a device with % in the name
and some configuration might depend on that.
dev_alloc_name tries to be as safe as possible about the processing
of format string so it should be safe from names like 'eth%s'
next prev parent reply other threads:[~2011-05-01 4:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-30 11:21 [patch net-next-2.6] net: call dev_alloc_name from register_netdevice Jiri Pirko
2011-04-30 17:34 ` Stephen Hemminger
2011-04-30 20:57 ` Jiri Pirko
2011-05-01 4:47 ` Stephen Hemminger [this message]
2011-05-01 6:41 ` Jiri Pirko
2011-05-05 17:58 ` David Miller
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=20110430214735.73036260@nehalam \
--to=shemminger@vyatta.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jpirko@redhat.com \
--cc=mirqus@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=xemul@openvz.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 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.