11 Feb, 2016

1 commit

  • In order to support fast reuseport lookups in TCP, the hash function
    defined in struct proto must be capable of returning an error code.
    This patch changes the function signature of all related hash functions
    to return an integer and handles or propagates this return value at
    all call sites.

    Signed-off-by: Craig Gallek
    Signed-off-by: David S. Miller

    Craig Gallek
     

30 Sep, 2015

1 commit

  • This patch changes the mtu size of 802.15.4 interfaces. The current
    setting is the meaning of the maximum transport unit with mac header,
    which is 127 bytes according 802.15.4. The linux meaning of the mtu size
    field is the maximum payload of a mac frame. Like in ethernet, which is
    1500 bytes.

    We have dynamic length of mac frames in 802.15.4, this is why we assume
    the minimum header length which is hard_header_len. This contains fc and
    sequence fields. These can evaluated by driver layer without additional
    checks. We currently don't support to set the FCS from userspace, so we
    need to subtract this from mtu size as well.

    Signed-off-by: Alexander Aring
    Signed-off-by: Marcel Holtmann

    Alexander Aring
     

22 Sep, 2015

1 commit

  • The current header_ops callback structure of net device are used mostly
    from 802.15.4 upper-layers. Because this callback structure is a very
    generic one, which is also used by e.g. DGRAM AF_PACKET sockets, we
    can't make this callback structure 802.15.4 specific which is currently
    is.

    I saw the smallest "constraint" for calling this callback with
    dev_hard_header/dev_parse_header by AF_PACKET which assign a 8 byte
    array for address void pointers. Currently 802.15.4 specific protocols
    like af802154 and 6LoWPAN will assign the "struct ieee802154_addr" as
    these parameters which is greater than 8 bytes. The current callback
    implementation for header_ops.create assumes always a complete
    "struct ieee802154_addr" which AF_PACKET can't never handled and is
    greater than 8 bytes.

    For that reason we introduce now a "generic" create/parse header_ops
    callback which allows handling with intra-pan extended addresses only.
    This allows a small use-case with AF_PACKET to send "somehow" a valid
    dataframe over DGRAM.

    To keeping the current dev_hard_header behaviour we introduce a similar
    callback structure "wpan_dev_header_ops" which contains 802.15.4 specific
    upper-layer header creation functionality, which can be called by
    wpan_dev_hard_header.

    Signed-off-by: Alexander Aring
    Signed-off-by: Marcel Holtmann

    Alexander Aring
     

04 Jun, 2015

1 commit

  • The AF_IEEE802154 sockaddr looks like this:

    struct sockaddr_ieee802154 {
    sa_family_t family; /* AF_IEEE802154 */
    struct ieee802154_addr_sa addr;
    };

    struct ieee802154_addr_sa {
    int addr_type;
    u16 pan_id;
    union {
    u8 hwaddr[IEEE802154_ADDR_LEN];
    u16 short_addr;
    };
    };

    On most architectures there will be implicit structure padding here,
    in two different places:

    * In struct sockaddr_ieee802154, two bytes of padding between 'family'
    (unsigned short) and 'addr', so that 'addr' starts on a four byte
    boundary.

    * In struct ieee802154_addr_sa, two bytes at the end of the structure,
    to make the structure 16 bytes.

    When calling recvmsg(2) on a PF_IEEE802154 SOCK_DGRAM socket, the
    ieee802154 stack constructs a struct sockaddr_ieee802154 on the
    kernel stack without clearing these padding fields, and, depending
    on the addr_type, between four and ten bytes of uncleared kernel
    stack will be copied to userspace.

    We can't just insert two 'u16 __pad's in the right places and zero
    those before copying an address to userspace, as not all architectures
    insert this implicit padding -- from a quick test it seems that avr32,
    cris and m68k don't insert this padding, while every other architecture
    that I have cross compilers for does insert this padding.

    The easiest way to plug the leak is to just memset the whole struct
    sockaddr_ieee802154 before filling in the fields we want to fill in,
    and that's what this patch does.

    Cc: stable@vger.kernel.org
    Signed-off-by: Lennert Buytenhek
    Acked-by: Alexander Aring
    Signed-off-by: Marcel Holtmann

    Lennert Buytenhek
     

27 May, 2015

2 commits


23 May, 2015

1 commit

  • This patch removes the mib lock. The new locking mechanism is to protect
    the mib values with the rtnl lock. Note that this isn't always necessary
    if we have an interface up the most mib values are readonly (e.g.
    address settings). With this behaviour we can remove locking in
    hotpath like frame parsing completely. It depends on context if we need
    to hold the rtnl lock or not, this makes the callbacks of
    ieee802154_mlme_ops unnecessary because these callbacks hols always the
    locks.

    Signed-off-by: Alexander Aring
    Reviewed-by: Stefan Schmidt
    Signed-off-by: Marcel Holtmann

    Alexander Aring
     

11 May, 2015

1 commit


03 Mar, 2015

1 commit

  • After TIPC doesn't depend on iocb argument in its internal
    implementations of sendmsg() and recvmsg() hooks defined in proto
    structure, no any user is using iocb argument in them at all now.
    Then we can drop the redundant iocb argument completely from kinds of
    implementations of both sendmsg() and recvmsg() in the entire
    networking stack.

    Cc: Christoph Hellwig
    Suggested-by: Al Viro
    Signed-off-by: Ying Xue
    Signed-off-by: David S. Miller

    Ying Xue
     

03 Jan, 2015

1 commit