Eric Lee / smarc-fsl-linux-kernel

04 Oct, 2006

1 commit

30 Sep, 2006

8 commits

29 Sep, 2006

1 commit

23 Sep, 2006

2 commits

18 Sep, 2006

1 commit

18 Aug, 2006

1 commit

  • b9c6e3e96   [ATM]: Compile error on ARM ... Browse Code »

    atm_proc_exit() is declared as __exit, and thus in .exit.text. On
    some architectures (ARM) .exit.text is discarded at compile time, and
    since atm_proc_exit() is called by some other __init functions, it
    results in a link error.

    Signed-off-by: Kevin Hilman
    Signed-off-by: David S. Miller

    Kevin Hilman
     

22 Jul, 2006

1 commit

10 Jul, 2006

1 commit

  • 247817346   [ATM] net/atm/clip.c: fix PROC_FS=n compile ... Browse Code »

    This patch fixes the following compile error with CONFIG_PROC_FS=n by
    reverting commit dcdb02752ff13a64433c36f2937a58d93ae7a19e:

    ...
    CC net/atm/clip.o
    net/atm/clip.c: In function ‘atm_clip_init’:
    net/atm/clip.c:975: error: ‘atm_proc_root’ undeclared (first use in this function)
    net/atm/clip.c:975: error: (Each undeclared identifier is reported only once
    net/atm/clip.c:975: error: for each function it appears in.)
    net/atm/clip.c:977: error: ‘arp_seq_fops’ undeclared (first use in this function)
    make[2]: *** [net/atm/clip.o] Error 1

    Signed-off-by: Adrian Bunk
    Signed-off-by: David S. Miller

    Adrian Bunk
     

09 Jul, 2006

1 commit

  • 1252ecf63   [ATM]: fix possible recursive locking in skb_migrate() ... Browse Code »

    ok this is a real potential deadlock in a way, it takes two locks of 2
    skbuffs without doing any kind of lock ordering; I think the following
    patch should fix it. Just sort the lock taking order by address of the
    skb.. it's not pretty but it's the best this can do in a minimally
    invasive way.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Chas Williams
    Signed-off-by: David S. Miller

    Arjan van de Ven
     

04 Jul, 2006

1 commit

01 Jul, 2006

1 commit

30 Jun, 2006

1 commit

26 Jun, 2006

1 commit

20 Jun, 2006

1 commit

18 Jun, 2006

1 commit

  • 932ff279a   [NET]: Add netif_tx_lock ... Browse Code »

    Various drivers use xmit_lock internally to synchronise with their
    transmission routines. They do so without setting xmit_lock_owner.
    This is fine as long as netpoll is not in use.

    With netpoll it is possible for deadlocks to occur if xmit_lock_owner
    isn't set. This is because if a printk occurs while xmit_lock is held
    and xmit_lock_owner is not set can cause netpoll to attempt to take
    xmit_lock recursively.

    While it is possible to resolve this by getting netpoll to use
    trylock, it is suboptimal because netpoll's sole objective is to
    maximise the chance of getting the printk out on the wire. So
    delaying or dropping the message is to be avoided as much as possible.

    So the only alternative is to always set xmit_lock_owner. The
    following patch does this by introducing the netif_tx_lock family of
    functions that take care of setting/unsetting xmit_lock_owner.

    I renamed xmit_lock to _xmit_lock to indicate that it should not be
    used directly. I didn't provide irq versions of the netif_tx_lock
    functions since xmit_lock is meant to be a BH-disabling lock.

    This is pretty much a straight text substitution except for a small
    bug fix in winbond. It currently uses
    netif_stop_queue/spin_unlock_wait to stop transmission. This is
    unsafe as an IRQ can potentially wake up the queue. So it is safer to
    use netif_tx_disable.

    The hamradio bits used spin_lock_irq but it is unnecessary as
    xmit_lock must never be taken in an IRQ handler.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

13 May, 2006

1 commit

  • bd89efc53   [NEIGH]: Fix IP-over-ATM and ARP interaction. ... Browse Code »

    The classical IP over ATM code maintains its own IPv4
    ARP table, using the standard neighbour-table code. The
    neigh_table_init function adds this neighbour table to a linked list
    of all neighbor tables which is used by the functions neigh_delete()
    neigh_add() and neightbl_set(), all called by the netlink code.

    Once the ATM neighbour table is added to the list, there are two
    tables with family == AF_INET there, and ARP entries sent via netlink
    go into the first table with matching family. This is indeterminate
    and often wrong.

    To see the bug, on a kernel with CLIP enabled, create a standard IPv4
    ARP entry by pinging an unused address on a local subnet. Then attempt
    to complete that entry by doing

    ip neigh replace lladdr nud reachable

    Looking at the ARP tables by using

    ip neigh show

    will reveal two ARP entries for the same address. One of these can be
    found in /proc/net/arp, and the other in /proc/net/atm/arp.

    This patch adds a new function, neigh_table_init_no_netlink() which
    does everything the neigh_table_init() does, except add the table to
    the netlink all-arp-tables chain. In addition neigh_table_init() has a
    check that all tables on the chain have a distinct address family.
    The init call in clip.c is changed to call
    neigh_table_init_no_netlink().

    Since ATM ARP tables are rather more complicated than can currently be
    handled by the available rtattrs in the netlink protocol, no
    functionality is lost by this patch, and non-ATM ARP manipulation via
    netlink is rescued. A more complete solution would involve a rtattr
    for ATM ARP entries and some way for the netlink code to give
    neigh_add and friends more information than just address family with
    which to find the correct ARP table.

    [ I've changed the assertion checking in neigh_table_init() to not
    use BUG_ON() while holding neigh_tbl_lock. Instead we remember that
    we found an existing tbl with the same family, and after dropping
    the lock we'll give a diagnostic kernel log message and a stack dump.
    -DaveM ]

    Signed-off-by: Simon Kelley
    Signed-off-by: David S. Miller

    Simon Kelley
     

15 Apr, 2006

6 commits

21 Mar, 2006

3 commits

05 Mar, 2006

1 commit

14 Feb, 2006

1 commit

12 Jan, 2006

2 commits

11 Jan, 2006

1 commit

07 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