Eric Lee / smarc-fsl-linux-kernel

26 Apr, 2007

1 commit

  • badff6d01   [SK_BUFF]: Introduce skb_reset_transport_header(skb) ... Browse Code »

    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
     

08 Mar, 2007

1 commit

  • b40df5743   [PATCH] bluetooth: fix socket locking in hci_sock_dev_event() ... Browse Code »

    [Bluetooth] Fix socket locking in hci_sock_dev_event()

    hci_sock_dev_event() uses bh_lock_sock() to lock the socket lock.
    This is not deadlock-safe against locking of the same socket lock in
    l2cap_connect_cfm() from softirq context. In addition to that,
    hci_sock_dev_event() doesn't seem to be called from softirq context,
    so it is safe to use lock_sock()/release_sock() instead.

    The lockdep warning can be triggered on my T42p simply by switching
    the Bluetooth off by the keyboard button.

    =================================
    [ INFO: inconsistent lock state ]
    2.6.21-rc2 #4
    ---------------------------------
    inconsistent {in-softirq-W} -> {softirq-on-W} usage.
    khubd/156 [HC0[0]:SC0[0]:HE1:SE1] takes:
    (slock-AF_BLUETOOTH){-+..}, at: [] hci_sock_dev_event+0xa8/0xc5 [bluetooth]
    {in-softirq-W} state was registered at:
    [] mark_lock+0x59/0x414
    [] l2cap_connect_cfm+0x4e/0x11f [l2cap]
    [] __lock_acquire+0x3e5/0xb99
    [] l2cap_connect_cfm+0x4e/0x11f [l2cap]
    [] lock_acquire+0x67/0x81
    [] l2cap_connect_cfm+0x4e/0x11f [l2cap]
    [] _spin_lock+0x29/0x34
    [] l2cap_connect_cfm+0x4e/0x11f [l2cap]
    [] l2cap_connect_cfm+0x4e/0x11f [l2cap]
    [] hci_send_cmd+0x126/0x14f [bluetooth]
    [] hci_event_packet+0x729/0xebd [bluetooth]
    [] hci_rx_task+0x2a/0x20f [bluetooth]
    [] hci_rx_task+0x6c/0x20f [bluetooth]
    [] trace_hardirqs_on+0x10d/0x14e
    [] tasklet_action+0x3d/0x68
    [] __do_softirq+0x41/0x92
    [] do_softirq+0x27/0x3d
    [] do_IRQ+0x7b/0x8f
    [] common_interrupt+0x24/0x34
    [] common_interrupt+0x2e/0x34
    [] acpi_processor_idle+0x1b3/0x34a
    [] acpi_processor_idle+0x1b6/0x34a
    [] cpu_idle+0x39/0x4e
    [] start_kernel+0x372/0x37a
    [] unknown_bootoption+0x0/0x202
    [] 0xffffffff

    Signed-off-by: Jiri Kosina
    Acked-by: Marcel Holtmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Kosina
     

15 Feb, 2007

1 commit

  • cd354f1ae   [PATCH] remove many unneeded #includes of sched.h ... Browse Code »

    After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

11 Feb, 2007

1 commit

14 Dec, 2006

1 commit

22 Nov, 2006

1 commit

16 Oct, 2006

1 commit

01 Jul, 2006

1 commit

13 Feb, 2006

1 commit

12 Jan, 2006

1 commit

04 Jan, 2006

1 commit

  • 90ddc4f04   [NET]: move struct proto_ops to const ... Browse Code »

    I noticed that some of 'struct proto_ops' used in the kernel may share
    a cache line used by locks or other heavily modified data. (default
    linker alignement is 32 bytes, and L1_CACHE_LINE is 64 or 128 at
    least)

    This patch makes sure a 'struct proto_ops' can be declared as const,
    so that all cpus can share all parts of it without false sharing.

    This is not mandatory : a driver can still use a read/write structure
    if it needs to (and eventually a __read_mostly)

    I made a global stubstitute to change all existing occurences to make
    them const.

    This should reduce the possibility of false sharing on SMP, and
    speedup some socket system calls.

    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

09 Nov, 2005

1 commit

29 Oct, 2005

1 commit

30 Aug, 2005

2 commits

26 Apr, 2005

1 commit

  • b453257f0   [PATCH] kill gratitious includes of major.h under net/* ... Browse Code »

    A lot of places in there are including major.h for no reason whatsoever.
    Removed. And yes, it still builds.

    The history of that stuff is often amusing. E.g. for net/core/sock.c
    the story looks so, as far as I've been able to reconstruct it: we used
    to need major.h in net/socket.c circa 1.1.early. In 1.1.13 that need
    had disappeared, along with register_chrdev(SOCKET_MAJOR, "socket",
    &net_fops) in sock_init(). Include had not. When 1.2 -> 1.3 reorg of
    net/* had moved a lot of stuff from net/socket.c to net/core/sock.c,
    this crap had followed...

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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