On Wed, Sep 28, 2016 at 06:49:51AM -0700, Eric Dumazet wrote:
> >
> > 4.7 is pretty widespread, so I've to think...
>
> Sorry, 4.4.7 it was
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg128714.html
Ah, thanks for info!
On Wed, 2016-09-28 at 16:43 +0300, Cyrill Gorcunov wrote:
> On Wed, Sep 28, 2016 at 06:29:08AM -0700, Eric Dumazet wrote:
> > >
> > > Oh, crap :( I've been looking into uapi headers, found that we
> > > use anonymous unions (for example include/uapi/linux/bcache.h)
> > > and thought it will be saf
On Wed, Sep 28, 2016 at 06:29:08AM -0700, Eric Dumazet wrote:
> >
> > Oh, crap :( I've been looking into uapi headers, found that we
> > use anonymous unions (for example include/uapi/linux/bcache.h)
> > and thought it will be safe (and my test builds didn't fail).
> > Are you happen to know which
On Wed, 2016-09-28 at 16:03 +0300, Cyrill Gorcunov wrote:
> On Wed, Sep 28, 2016 at 05:57:12AM -0700, Eric Dumazet wrote:
> ...
> > Note that some programs could fail to compile with the added union
> > anyway.
> >
> > Some gcc versions are unable to compile a static init with an union
> >
> > st
On Wed, Sep 28, 2016 at 06:02:11AM -0700, Eric Dumazet wrote:
>
> This is a bit different of course, since struct tc_fq_qd_stats is only
> one way : Kernel produces the content and gives it to user space.
>
> User space should probably not need to initialize such a structure, but
> who knows what
On Wed, 2016-09-28 at 05:57 -0700, Eric Dumazet wrote:
> Note that some programs could fail to compile with the added union
> anyway.
>
> Some gcc versions are unable to compile a static init with an union
>
> struct inet_diag_req_v2 foo = { .pad = 0, sdiag_family = AF_INET, };
>
> When I cooke
On Wed, Sep 28, 2016 at 05:57:12AM -0700, Eric Dumazet wrote:
...
> Note that some programs could fail to compile with the added union
> anyway.
>
> Some gcc versions are unable to compile a static init with an union
>
> struct inet_diag_req_v2 foo = { .pad = 0, sdiag_family = AF_INET, };
>
> Wh
On Wed, Sep 28, 2016 at 08:50:31AM -0400, Jamal Hadi Salim wrote:
>
> struct tcp_info.
Yeah I see. As I said naming pads will be safe but to do so we
will have to compile on every arch we support and make sure the
implicit pad remains here.
> Sorry - i didnt mean to drag this for long; but the m
On Wed, 2016-09-28 at 14:27 +0300, Cyrill Gorcunov wrote:
> On Wed, Sep 28, 2016 at 07:06:26AM -0400, Jamal Hadi Salim wrote:
> > >
> > > This structure is uapi, so anyone has complete rights to reference
> > > @pad in the userspace programs. Sure it would be more clear to remove
> > > the @pad co
On 16-09-28 08:45 AM, Cyrill Gorcunov wrote:
Note: inet_diag somewhere has a netlink structure that
has a hole. I pointed it out to Eric D. and he said we cant
add it now because it would break ABI.
Naming holes generated by a compiler for alignment sake should
not break abi (because alignment
On Wed, Sep 28, 2016 at 08:27:24AM -0400, Jamal Hadi Salim wrote:
> >
> > They must initialize it to zero.
> >
>
> What if in the future actually meant to use 0 for
> something?;-> For example in Cyrill's case it means PROTO_IP
> Not sure if it useful to interpret or not but it is part of the
>
On 16-09-28 08:27 AM, Jamal Hadi Salim wrote:
On 16-09-28 08:16 AM, David Miller wrote:
From: Jamal Hadi Salim
Date: Wed, 28 Sep 2016 08:09:28 -0400
On 16-09-28 08:07 AM, David Miller wrote:
Right, it would be legal for an existing user to have code that
explicitly initializes every member
On 16-09-28 08:16 AM, David Miller wrote:
From: Jamal Hadi Salim
Date: Wed, 28 Sep 2016 08:09:28 -0400
On 16-09-28 08:07 AM, David Miller wrote:
Right, it would be legal for an existing user to have code that
explicitly initializes every member of the structure, including 'pad'.
So we have t
On Wed, Sep 28, 2016 at 08:06:51AM -0400, Jamal Hadi Salim wrote:
>
> I understood well your point;-> Maybe my response was not clear:
> _nobody should be fscking fondling pad fields_ setting them or
> otherwise.
> Maybe let these programs fail. I asked if you knew any such app which
> did anythin
On Wed, Sep 28, 2016 at 08:07:01AM -0400, David Miller wrote:
...
> >
> > I think you miss the point what I'm trying to say: currently end-user
> > may have reference to this member (for any reason) and his program
> > will compile and run. If we change the name the compilation procedure
> > fails
From: Jamal Hadi Salim
Date: Wed, 28 Sep 2016 08:09:28 -0400
> On 16-09-28 08:07 AM, David Miller wrote:
>
>> Right, it would be legal for an existing user to have code that
>> explicitly initializes every member of the structure, including 'pad'.
>> So we have to keep that member around, at a m
From: Jamal Hadi Salim
Date: Wed, 28 Sep 2016 08:06:51 -0400
> I understood well your point;-> Maybe my response was not clear:
> _nobody should be fscking fondling pad fields_ setting them or
> otherwise.
Especially considering potential future uses of the field, existing
users absolutely must
On 16-09-28 08:07 AM, David Miller wrote:
Right, it would be legal for an existing user to have code that
explicitly initializes every member of the structure, including 'pad'.
So we have to keep that member around, at a minimum, for their sake.
I think we need to start labelling any new pad
On 16-09-28 07:27 AM, Cyrill Gorcunov wrote:
On Wed, Sep 28, 2016 at 07:06:26AM -0400, Jamal Hadi Salim wrote:
This structure is uapi, so anyone has complete rights to reference
@pad in the userspace programs. Sure it would be more clear to remove
the @pad completely, but if we choose so I thin
From: Cyrill Gorcunov
Date: Wed, 28 Sep 2016 14:27:03 +0300
> On Wed, Sep 28, 2016 at 07:06:26AM -0400, Jamal Hadi Salim wrote:
>> >
>> > This structure is uapi, so anyone has complete rights to reference
>> > @pad in the userspace programs. Sure it would be more clear to remove
>> > the @pad co
On Wed, Sep 28, 2016 at 07:06:26AM -0400, Jamal Hadi Salim wrote:
> >
> > This structure is uapi, so anyone has complete rights to reference
> > @pad in the userspace programs. Sure it would be more clear to remove
> > the @pad completely, but if we choose so I think it's better to do
> > on top i
On 16-09-28 06:51 AM, Cyrill Gorcunov wrote:
On Wed, Sep 28, 2016 at 06:43:01AM -0400, Jamal Hadi Salim wrote:
[..]
I dont know how compilation will fail but you may be right with note:
that is not how pads have been used in the past. They are supposed to
cosmetic annotation which indicates "h
On Wed, Sep 28, 2016 at 06:43:01AM -0400, Jamal Hadi Salim wrote:
...
> >
> > Someone may have set it to zero explicitly on source level, and the
> > compilation will fail on new kernel then. So no, keeping the name
> > is reasonable.
> >
>
> I dont know how compilation will fail but you may be
On 16-09-28 06:17 AM, Cyrill Gorcunov wrote:
On Wed, Sep 28, 2016 at 06:08:00AM -0400, Jamal Hadi Salim wrote:
...
@@ -38,7 +38,10 @@ struct inet_diag_req_v2 {
__u8sdiag_family;
__u8sdiag_protocol;
__u8idiag_ext;
- __u8pad;
+ union {
+
On Wed, Sep 28, 2016 at 06:08:00AM -0400, Jamal Hadi Salim wrote:
...
> > @@ -38,7 +38,10 @@ struct inet_diag_req_v2 {
> > __u8sdiag_family;
> > __u8sdiag_protocol;
> > __u8idiag_ext;
> > - __u8pad;
> > + union {
> > + __u8pad;
> > + __u8s
On 16-09-28 05:03 AM, Cyrill Gorcunov wrote:
In criu we are actively using diag interface to collect sockets
present in the system when dumping applications. And while for
unix, tcp, udp[lite], packet, netlink it works as expected,
the raw sockets do not have. Thus add it.
v2:
- add missing soc
In criu we are actively using diag interface to collect sockets
present in the system when dumping applications. And while for
unix, tcp, udp[lite], packet, netlink it works as expected,
the raw sockets do not have. Thus add it.
v2:
- add missing sock_put calls in raw_diag_dump_one (by eric.dumaz
27 matches
Mail list logo
