We're worried about reading beyond the end of the array and it's a heap
allocation and the last char of the eth addr is the last byte of the
page. This causes an oops.
It's almost impossible to hit that bug.
1) You would have to have the eth addr at the end of the array.
2) It would have to be a
On Mon, 2014-01-06 at 10:24 +0100, Geert Uytterhoeven wrote:
> Thanks to this discussion, my eye fell on:
>
> static inline unsigned compare_ether_addr(const u8 *addr1, const u8 *addr2)
> {
> const u16 *a = (const u16 *) addr1;
> const u16 *b = (const u16 *) addr2;
>
> BU
On Tue, Dec 31, 2013 at 12:13:08AM +0100, Johannes Berg wrote:
> On Mon, 2013-12-30 at 19:57 -0200, Henrique de Moraes Holschuh wrote:
> > On Mon, 30 Dec 2013, Johannes Berg wrote:
> > > On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wrote:
> > > > > Is there any way we could catch (sparse, or som
On Mon, 2014-01-06 at 10:09 +0100, Julia Lawall wrote:
> > BUILD_BUG_ON(sizeof(struct foo) - offsetof(struct foo, addr) < 8);
> >
> > with the user(s?) and that should catch the scenario I was worrying
> > about?
>
> OK, thanks. That is what I had in mind. But I was hoping to be able to
> put i
On Mon, 6 Jan 2014, Geert Uytterhoeven wrote:
> On Tue, Dec 31, 2013 at 7:26 AM, Emmanuel Grumbach
> wrote:
> > On Tue, Dec 31, 2013 at 1:13 AM, Johannes Berg
> > wrote:
> >>
> >> On Mon, 2013-12-30 at 19:57 -0200, Henrique de Moraes Holschuh wrote:
> >> > On Mon, 30 Dec 2013, Johannes Berg wro
On Tue, Dec 31, 2013 at 7:26 AM, Emmanuel Grumbach wrote:
> On Tue, Dec 31, 2013 at 1:13 AM, Johannes Berg
> wrote:
>>
>> On Mon, 2013-12-30 at 19:57 -0200, Henrique de Moraes Holschuh wrote:
>> > On Mon, 30 Dec 2013, Johannes Berg wrote:
>> > > On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wro
On Mon, 6 Jan 2014, Johannes Berg wrote:
> On Mon, 2014-01-06 at 10:04 +0100, Julia Lawall wrote:
>
> > OK, the question was expressed badly. Is there any way to use the value
> > to trigger an action at build time? The only way I kow to trigger an
> > action is with #error, but #error is proces
On Mon, 6 Jan 2014, Johannes Berg wrote:
> On Tue, 2013-12-31 at 17:40 +0100, Julia Lawall wrote:
>
> > > If nothing else, then some run-time code that calculates the offset off
> > > and asserts if it is broken in module initialization or similar might
> > > be good enough.
> >
> > Could be OK.
On Mon, 2014-01-06 at 10:04 +0100, Julia Lawall wrote:
> OK, the question was expressed badly. Is there any way to use the value
> to trigger an action at build time? The only way I kow to trigger an
> action is with #error, but #error is processed by cpp, which doesn't know
> about the size of
On Tue, 2013-12-31 at 17:40 +0100, Julia Lawall wrote:
> > If nothing else, then some run-time code that calculates the offset off
> > and asserts if it is broken in module initialization or similar might
> > be good enough.
>
> Could be OK. Something right in or after the structure declaration
On Mon, 6 Jan 2014, Joe Perches wrote:
> On Mon, 2014-01-06 at 09:48 +0100, Julia Lawall wrote:
> > Is there any way to get sizeof evaluated at build time?
>
> I'm confused a bit by what you want to accomplish.
To check that a field that is an argument od ether_addr_equal_64bits is
a sufficient d
On Mon, 2014-01-06 at 09:48 +0100, Julia Lawall wrote:
> Is there any way to get sizeof evaluated at build time?
I'm confused a bit by what you want to accomplish.
Except for variable length arrays, isn't sizeof always
evaluated at build time?
6.5.3.4 The sizeof operator
Constraints
[]
2 The siz
Is there any way to get sizeof evaluated at build time?
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.o
On Tue, 31 Dec 2013, Ben Greear wrote:
> On 12/31/2013 08:09 AM, Julia Lawall wrote:
> >
> >
> > On Tue, 31 Dec 2013, Ben Greear wrote:
> >
> > > On 12/30/2013 10:32 PM, Julia Lawall wrote:
> > > > > > > > I'm just thinking of a programmer, e.g. changing a struct like
> > > > > > > > this:
> > >
On 12/31/2013 08:09 AM, Julia Lawall wrote:
On Tue, 31 Dec 2013, Ben Greear wrote:
On 12/30/2013 10:32 PM, Julia Lawall wrote:
I'm just thinking of a programmer, e.g. changing a struct like this:
struct foo {
u8 addr[ETH_ALEN];
- u16 dummy;
};
I don't know of a way to catch th
On Tue, 31 Dec 2013, Ben Greear wrote:
> On 12/30/2013 10:32 PM, Julia Lawall wrote:
> > > > > > I'm just thinking of a programmer, e.g. changing a struct like this:
> > > > > >
> > > > > > struct foo {
> > > > > > u8 addr[ETH_ALEN];
> > > > > > - u16 dummy;
> > > > > > };
> > >
> > > I
On 12/30/2013 10:32 PM, Julia Lawall wrote:
I'm just thinking of a programmer, e.g. changing a struct like this:
struct foo {
u8 addr[ETH_ALEN];
- u16 dummy;
};
I don't know of a way to catch that.
Anyone else?
Well, one could have a semantic patch that checks for that. But the
pro
> > > > I'm just thinking of a programmer, e.g. changing a struct like this:
> > > >
> > > > struct foo {
> > > >u8 addr[ETH_ALEN];
> > > > - u16 dummy;
> > > > };
>
> I don't know of a way to catch that.
> Anyone else?
Well, one could have a semantic patch that checks for that. But the
On Tue, Dec 31, 2013 at 1:13 AM, Johannes Berg
wrote:
>
> On Mon, 2013-12-30 at 19:57 -0200, Henrique de Moraes Holschuh wrote:
> > On Mon, 30 Dec 2013, Johannes Berg wrote:
> > > On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wrote:
> > > > > Is there any way we could catch (sparse, or some othe
On Tue, 2013-12-31 at 00:13 +0100, Johannes Berg wrote:
> On Mon, 2013-12-30 at 19:57 -0200, Henrique de Moraes Holschuh wrote:
> > On Mon, 30 Dec 2013, Johannes Berg wrote:
> > > On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wrote:
> > > > > Is there any way we could catch (sparse, or some other
On Mon, 2013-12-30 at 19:57 -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 30 Dec 2013, Johannes Berg wrote:
> > On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wrote:
> > > > Is there any way we could catch (sparse, or some other script?) that
> > > > struct reorganising won't break the condi
On Mon, 30 Dec 2013, Johannes Berg wrote:
> On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wrote:
> > > Is there any way we could catch (sparse, or some other script?) that
> > > struct reorganising won't break the condition needed ("within a
> > > structure that contains at least two more bytes")
On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wrote:
> > Is there any way we could catch (sparse, or some other script?) that
> > struct reorganising won't break the condition needed ("within a
> > structure that contains at least two more bytes")?
>
> What kind of reorganizing could happen? D
> Seems to be missing an "iwlwifi:" or so prefix, but I guess we can add
> it when we take the patch ...
Sorry. Not sure why that happened. I'll look into it.
> Is there any way we could catch (sparse, or some other script?) that
> struct reorganising won't break the condition needed ("within a
On Mon, 2013-12-30 at 19:15 +0100, Julia Lawall wrote:
> From: Julia Lawall
>
> Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be
> used when each argument is an array within a structure that contains at
> least two bytes of data beyond the array.
>
> The structures inv
From: Julia Lawall
Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be
used when each argument is an array within a structure that contains at
least two bytes of data beyond the array.
The structures involved are:
iwl_rxon_cmd defined in drivers/net/wireless/iwlwifi/dvm/c
26 matches
Mail list logo
