On Wed, 2016-05-04 at 12:50 -0400, David Miller wrote:
> From: Eric Dumazet
> Date: Wed, 04 May 2016 07:27:06 -0700
>
> > kernel was fine, and most user land apps were fine as well.
>
> Userland should really not have to deal with garbage like this.
>
> And because it quietly works just fine on
From: Eric Dumazet
Date: Wed, 04 May 2016 07:27:06 -0700
> kernel was fine, and most user land apps were fine as well.
Userland should really not have to deal with garbage like this.
And because it quietly works just fine on x86-64, nothing makes
sure that applications will universally get this
From: Nicolas Dichtel
Date: Wed, 4 May 2016 14:49:00 +0200
> Le 04/05/2016 11:05, Lars Ellenberg a écrit :
> [snip]
>> We don't have an "alignment problem" there, btw.
>> Last time I checked, we did work fine without this alignment magic,
>> we already take care of that, yes, even on affected arc
On Wed, 2016-05-04 at 14:49 +0200, Nicolas Dichtel wrote:
> Le 04/05/2016 11:05, Lars Ellenberg a écrit :
> [snip]
> > We don't have an "alignment problem" there, btw.
> > Last time I checked, we did work fine without this alignment magic,
> > we already take care of that, yes, even on affected arc
On Wed, May 04, 2016 at 02:49:00PM +0200, Nicolas Dichtel wrote:
> Le 04/05/2016 11:05, Lars Ellenberg a écrit :
> [snip]
> > We don't have an "alignment problem" there, btw.
> > Last time I checked, we did work fine without this alignment magic,
> > we already take care of that, yes, even on affec
Le 04/05/2016 11:05, Lars Ellenberg a écrit :
[snip]
> We don't have an "alignment problem" there, btw.
> Last time I checked, we did work fine without this alignment magic,
> we already take care of that, yes, even on affected architectures.
The code adds several consecutive u64 attributes. The nl
On Tue, May 03, 2016 at 12:05:56PM -0400, David Miller wrote:
> From: Lars Ellenberg
> Date: Tue, 3 May 2016 12:06:44 +0200
>
> > Please just NOT use an additional "field",
> > but always use 0 to pad.
>
> You can't, it doesn't work.
I did, and it *did* work.
At least, it appeared to.
I'm not
From: Lars Ellenberg
Date: Tue, 3 May 2016 12:06:44 +0200
> Whereas using some arbitrary value will be wrong,
> and will needlessly break userland.
It cannot break userland.
A fundamental property of netlink is that all code must silently
ignore netlink attributes it does not understand.
This
From: Lars Ellenberg
Date: Tue, 3 May 2016 12:06:44 +0200
> Please just NOT use an additional "field",
> but always use 0 to pad.
You can't, it doesn't work.
We are adding a new field to every netlink protocol family that has this
alignment problem.
Le 03/05/2016 12:06, Lars Ellenberg a écrit :
> On Tue, May 03, 2016 at 11:39:18AM +0200, Nicolas Dichtel wrote:
>> Two new handlers have been defined in genl_magic_ headers:
>> - __field2: the corresponding nla_put() function (nla_put_flag()) takes
>> only two args
>> - __field4: th
On Tue, May 03, 2016 at 11:39:18AM +0200, Nicolas Dichtel wrote:
> Two new handlers have been defined in genl_magic_ headers:
> - __field2: the corresponding nla_put() function (nla_put_flag()) takes
> only two args
> - __field4: the corresponding nla_put() function (nla_put_u64_64bi
Two new handlers have been defined in genl_magic_ headers:
- __field2: the corresponding nla_put() function (nla_put_flag()) takes
only two args
- __field4: the corresponding nla_put() function (nla_put_u64_64bit())
takes four args
__field2 allows us to define __unspec_
12 matches
Mail list logo
