10 May, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

27 Dec, 2009

4 commits

  • For the cases where a lot of interfaces are used in conjunction with a
    lot of LLC sockets bound to the same SAP, the iteration of the socket
    list becomes prohibitively expensive.

    Replacing the list with a a local address based hash significantly
    improves the bind and listener lookup operations as well as the
    datagram delivery.

    Connected sockets delivery is also improved, but this patch does not
    address the case where we have lots of sockets with the same local
    address connected to different remote addresses.

    In order to keep the socket sanity checks alive and fast a socket
    counter was added to the SAP structure.

    Signed-off-by: Octavian Purdila
    Signed-off-by: David S. Miller

    Octavian Purdila
     
  • This patch adds a per SAP device based hash table to solve the
    multicast delivery scalability issue when we have large number of
    interfaces and a large number of sockets bound to the same SAP.

    Signed-off-by: Octavian Purdila
    Signed-off-by: David S. Miller

    Octavian Purdila
     
  • Optimize multicast delivery by doing the actual delivery without
    holding the lock. Based on the same approach used in UDP code.

    Signed-off-by: Octavian Purdila
    Signed-off-by: David S. Miller

    Octavian Purdila
     
  • For the reclamation phase we use the SLAB_DESTROY_BY_RCU mechanism,
    which require some extra checks in the lookup code:

    a) If the current socket was released, reallocated & inserted in
    another list it will short circuit the iteration for the current list,
    thus we need to restart the lookup.

    b) If the current socket was released, reallocated & inserted in the
    same list we just need to recheck it matches the look-up criteria and
    if not we can skip to the next element.

    In this case there is no need to restart the lookup, since sockets are
    inserted at the start of the list and the worst that will happen is
    that we will iterate throught some of the list elements more then
    once.

    Note that the /proc and multicast delivery was not yet converted to
    RCU, it still uses spinlocks for protection.

    Signed-off-by: Octavian Purdila
    Signed-off-by: David S. Miller

    Octavian Purdila
     

30 May, 2008

1 commit

  • llc_sap_rcv was being preceded by skb_set_owner_r, then calling
    llc_state_process that calls sock_queue_rcv_skb, that in turn calls
    skb_set_owner_r again making the space allowed to be used by the socket to be
    leaked, making the socket to get stuck.

    Fix it by setting skb->sk at llc_sap_rcv and leave the accounting to be done
    only at sock_queue_rcv_skb.

    Reported-by: Dmitry Petukhov
    Tested-by: Dmitry Petukhov
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

01 Apr, 2008

1 commit

  • Allocate the skb for llc responses with the received packet size by
    using the size adjustable llc_frame_alloc.
    Don't allocate useless extra payload.
    Cleanup magic numbers.

    So, this fixes oops.
    Reported by Jim Westfall:
    kernel: skb_over_panic: text:c0541fc7 len:1000 put:997 head:c166ac00 data:c166ac2f tail:0xc166b017 end:0xc166ac80 dev:eth0
    kernel: ------------[ cut here ]------------
    kernel: kernel BUG at net/core/skbuff.c:95!

    Signed-off-by: Joonwoo Park
    Acked-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Joonwoo Park
     

26 Apr, 2007

3 commits

  • For the common, open coded 'skb->h.raw = skb->data' operation, so that we can
    later turn skb->h.raw into a offset, reducing the size of struct sk_buff in
    64bit land while possibly keeping it as a pointer on 32bit.

    This one touches just the most simple cases:

    skb->h.raw = skb->data;
    skb->h.raw = {skb_push|[__]skb_pull}()

    The next ones will handle the slightly more "complex" cases.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     
  • For the common, open coded 'skb->nh.raw = skb->data' operation, so that we can
    later turn skb->nh.raw into a offset, reducing the size of struct sk_buff in
    64bit land while possibly keeping it as a pointer on 32bit.

    This one touches just the most simple case, next will handle the slightly more
    "complex" cases.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     
  • skb->head is equal to skb->data after alloc_skb, so reset the mac header while
    this is true, i.e. before skb_reserve.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

11 Feb, 2007

1 commit


14 Aug, 2006

1 commit

  • Fix from Aji_Srinivas@emc.com, STP packets are incorrectly received on
    all LLC datagram sockets, whichever interface they are bound to. The
    llc_sap datagram receive logic sends packets with a unicast
    destination MAC to one socket bound to that SAP and MAC, and multicast
    packets to all sockets bound to that SAP. STP packets are multicast,
    and we do need to know on which interface they were received.

    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    Stephen Hemminger
     

05 Aug, 2006

1 commit

  • The datagram interface of LLC is broken in a couple of ways.
    These were discovered when trying to use it to build an out-of-kernel
    version of STP.

    First it didn't pass the source address of the received packet
    in recvfrom(). It needs to copy the source address of received LLC packets
    into the socket control block. At the same time fix a security issue
    because there was uninitialized data leakage. Every recvfrom call
    was just copying out old data.

    Second, LLC should not merge multiple packets in one receive call
    on datagram sockets. LLC should preserve packet boundaries on
    SOCK_DGRAM.

    This fix goes against the old historical comments about UNIX98 semantics
    but without this fix SOCK_DGRAM is broken and useless. So either ANK's
    interpretation was incorect or UNIX98 standard was wrong.

    Signed-off-by: Stephen Hemminger
    Acked-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Stephen Hemminger
     

18 Jun, 2006

1 commit


22 Sep, 2005

4 commits


30 Aug, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds