17 May, 2016

1 commit


24 Apr, 2016

6 commits


22 Apr, 2016

1 commit


21 Apr, 2016

1 commit


20 Apr, 2016

2 commits


30 Sep, 2015

1 commit

  • This patch adds missing inline wrappers for nla_get_le32 and
    nla_get_le64. The 802.15.4 MAC byteorder is little endian and we keep
    the byteorder for fields like address configuration in the same
    byteorder as it comes from the MAC layer.

    To provide these fields for nl802154 userspace applications, we need
    these inline wrappers for netlink.

    Cc: David S. Miller
    Signed-off-by: Alexander Aring
    Signed-off-by: Marcel Holtmann

    Alexander Aring
     

01 Apr, 2015

2 commits


18 Jan, 2015

1 commit

  • Contrary to common expectations for an "int" return, these functions
    return only a positive value -- if used correctly they cannot even
    return 0 because the message header will necessarily be in the skb.

    This makes the very common pattern of

    if (genlmsg_end(...) < 0) { ... }

    be a whole bunch of dead code. Many places also simply do

    return nlmsg_end(...);

    and the caller is expected to deal with it.

    This also commonly (at least for me) causes errors, because it is very
    common to write

    if (my_function(...))
    /* error condition */

    and if my_function() does "return nlmsg_end()" this is of course wrong.

    Additionally, there's not a single place in the kernel that actually
    needs the message length returned, and if anyone needs it later then
    it'll be very easy to just use skb->len there.

    Remove this, and make the functions void. This removes a bunch of dead
    code as described above. The patch adds lines because I did

    - return nlmsg_end(...);
    + nlmsg_end(...);
    + return 0;

    I could have preserved all the function's return values by returning
    skb->len, but instead I've audited all the places calling the affected
    functions and found that none cared. A few places actually compared
    the return value with < 0 with no change in behaviour, so I opted for the more
    efficient version.

    One instance of the error I've made numerous times now is also present
    in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
    check for
    Signed-off-by: David S. Miller

    Johannes Berg
     

06 Jan, 2015

1 commit


29 Oct, 2014

1 commit

  • The original motivation for this change was to allow the helper to be used
    in files other than actions.c as part of work on an odp select group
    action.

    It was as pointed out by Thomas Graf that this helper would be best off
    living in netlink.h. Furthermore, I think that the generic nature of this
    helper means it is best off in netlink.h regardless of if it is used more
    than one .c file or not. Thus, I would like it considered independent of
    the work on an odp select group action.

    Cc: Thomas Graf
    Cc: Pravin Shelar
    Cc: Andy Zhou
    Signed-off-by: Simon Horman
    Acked-by: Thomas Graf
    Signed-off-by: David S. Miller

    Simon Horman
     

17 Oct, 2014

1 commit


29 Jul, 2014

1 commit


22 Sep, 2013

1 commit

  • There are a mix of function prototypes with and without extern
    in the kernel sources. Standardize on not using extern for
    function prototypes.

    Function prototypes don't need to be written with extern.
    extern is assumed by the compiler. Its use is as unnecessary as
    using auto to declare automatic/local variables in a block.

    Signed-off-by: Joe Perches
    Signed-off-by: David S. Miller

    Joe Perches
     

11 Sep, 2012

1 commit

  • It is a frequent mistake to confuse the netlink port identifier with a
    process identifier. Try to reduce this confusion by renaming fields
    that hold port identifiers portid instead of pid.

    I have carefully avoided changing the structures exported to
    userspace to avoid changing the userspace API.

    I have successfully built an allyesconfig kernel with this change.

    Signed-off-by: "Eric W. Biederman"
    Acked-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    Eric W. Biederman
     

04 Aug, 2012

1 commit


02 Apr, 2012

4 commits


31 Jan, 2012

1 commit

  • text data bss dec hex filename
    8455963 532732 1810804 10799499 a4c98b vmlinux.o.before
    8448899 532732 1810804 10792435 a4adf3 vmlinux.o

    This change also removes commented-out copy of __nlmsg_put
    which was last touched in 2005 with "Enable once all users
    have been converted" comment on top.

    Changes in v2: rediffed against net-next.

    Signed-off-by: Denys Vlasenko
    Signed-off-by: David S. Miller

    Denys Vlasenko
     

05 Nov, 2011

1 commit


23 Jun, 2011

1 commit

  • Consider the following situation:
    * a dump that would show 8 entries, four in the first
    round, and four in the second
    * between the first and second rounds, 6 entries are
    removed
    * now the second round will not show any entry, and
    even if there is a sequence/generation counter the
    application will not know

    To solve this problem, add a new flag NLM_F_DUMP_INTR
    to the netlink header that indicates the dump wasn't
    consistent, this flag can also be set on the MSG_DONE
    message that terminates the dump, and as such above
    situation can be detected.

    To achieve this, add a sequence counter to the netlink
    callback struct. Of course, netlink code still needs
    to use this new functionality. The correct way to do
    that is to always set cb->seq when a dumpit callback
    is invoked and call nl_dump_check_consistent() for
    each new message. The core code will also call this
    function for the final MSG_DONE message.

    To make it usable with generic netlink, a new function
    genlmsg_nlhdr() is needed to obtain the netlink header
    from the genetlink user header.

    Signed-off-by: Johannes Berg
    Acked-by: David S. Miller
    Signed-off-by: John W. Linville

    Johannes Berg
     

10 May, 2011

1 commit


01 Feb, 2011

1 commit


17 Nov, 2010

1 commit


05 Nov, 2010

1 commit


24 Jun, 2010

1 commit


20 Mar, 2010

1 commit


19 Feb, 2010

1 commit


25 Aug, 2009

1 commit


27 May, 2009

1 commit


26 Mar, 2009

1 commit


26 Dec, 2008

1 commit

  • See commit 1045b03e07d85f3545118510a587035536030c1c ("netlink: fix
    overrun in attribute iteration") for a detailed explanation of why
    this patch is necessary.

    In short, nlmsg_next() can make "remaining" go negative, and the
    remaining >= sizeof(...) comparison will promote "remaining" to an
    unsigned type, which means that the expression will evaluate to
    true for negative numbers, even though it was not intended.

    I put "theoretical" in the title because I have no evidence that
    this can actually happen, but I suspect that a crafted netlink
    packet can trigger some badness.

    Note that the last test, which seemingly has the exact same
    problem (also true for nla_ok()), is perfectly OK, since we
    already know that remaining is positive.

    Signed-off-by: Vegard Nossum
    Signed-off-by: David S. Miller

    Vegard Nossum