[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100928211106.GE19804@ZenIV.linux.org.uk>
Date: Tue, 28 Sep 2010 22:11:06 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Boaz Harrosh <bharrosh@...asas.com>, Julia Lawall <julia@...u.dk>,
"David S. Miller" <davem@...emloft.net>,
Andrew Morton <akpm@...ux-foundation.org>,
uml-devel <user-mode-linux-devel@...ts.sourceforge.net>,
linux-kernel <linux-kernel@...r.kernel.org>,
Stephen Hemminger <shemminger@...tta.com>
Subject: Re: {painfully BISECTED} Please revert f25c80a4b2: arch/um/drivers:
remove duplicate structure field initialization
On Tue, Sep 28, 2010 at 01:24:40PM -0700, Linus Torvalds wrote:
> It looks like that commit is indeed very misleading. The commit message says:
>
> "arch/um/drivers: remove duplicate structure field initialization"
>
> but it is in fact not duplicate: there's two field initializations,
> but they are _different_. Looking at the patch, it has:
>
> .ndo_set_mac_address = uml_net_set_mac,
> - .ndo_set_mac_address = eth_mac_addr,
>
> so it removes the later one, but it is not at all clear which one the
> compiler actually used. My guess is that it used to use the later one
> (the standard eth_mac_addr function), and the patch made it suddenly
> use the uml_net_set_mac function.
C99 6.7.8p19:
The initialization shall occur in initializer list order, each
initializer provided for a particular subobject overriding any previously
listed initializer for the same subobject[*]; all subobjects that are not
initialized explicitly shall be initialized implicitly the same as objects
that have static storage duration.
[*] Any initializer for subobject which is overridden and so not used to
initialize that subobject might not be evaluated at all.
IOW, it _must_ use the last one in such cases.
As for the driver, I smell an interface change (in eth_mac_addr() arguments)
that has been missed... FWIW, grep through the tree shows one more instance
of eth_mac_addr() called with such argument and it's also in net_kern.c; there
we simply want memcpy() instead, since device is definitely not running at
that point and we'd done the validity checks earlier.
Not sure if we need lp->lock around that eth_mac_addr() call - not familiar
with the driver in question. If we don't, we should switch to eth_mac_addr
for the method, indeed...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists