11 Jul, 2007

2 commits

  • * 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6: (40 commits)
    bonding/bond_main.c: make 2 functions static
    ps3: gigabit ethernet driver for PS3, take3
    [netdrvr] Fix dependencies for ax88796 ne2k clone driver
    eHEA: Capability flag for DLPAR support
    Remove sk98lin ethernet driver.
    sunhme.c:quattro_pci_find() must be __devinit
    bonding / ipv6: no addrconf for slaves separately from master
    atl1: remove write-only var in tx handler
    macmace: use "unsigned long flags;"
    Cleanup usbnet_probe() return value handling
    netxen: deinline and sparse fix
    eeprom_93cx6: shorten pulse timing to match spec (bis)
    phylib: Add Marvell 88E1112 phy id
    phylib: cleanup marvell.c a bit
    AX88796 network driver
    IOC3: Switch to pci refcounting safe APIs
    e100: Fix Tyan motherboard e100 not receiving IPMI commands
    QE Ethernet driver writes to wrong register to mask interrupts
    rrunner.c:rr_init() must be __devinit
    tokenring/3c359.c:xl_init() must be __devinit
    ...

    Linus Torvalds
     
  • At present, when a device is enslaved to bonding, if ipv6 is
    active then addrconf will be initated on the slave (because it is closed
    then opened during the enslavement processing). This causes DAD and RS
    packets to be sent from the slave. These packets in turn can confuse
    switches that perform ipv6 snooping, causing them to incorrectly update
    their forwarding tables (if, e.g., the slave being added is an inactve
    backup that won't be used right away) and direct traffic away from the
    active slave to a backup slave (where the incoming packets will be
    dropped).

    This patch alters the behavior so that addrconf will only run on
    the master device itself. I believe this is logically correct, as it
    prevents slaves from having an IPv6 identity independent from the
    master. This is consistent with the IPv4 behavior for bonding.

    This is accomplished by (a) having bonding set IFF_SLAVE sooner
    in the enslavement processing than currently occurs (before open, not
    after), and (b) having ipv6 addrconf ignore UP and CHANGE events on
    slave devices.

    The eql driver also uses the IFF_SLAVE flag. I inspected eql,
    and I believe this change is reasonable for its usage of IFF_SLAVE, but
    I did not test it.

    Signed-off-by: Jay Vosburgh
    Signed-off-by: Jeff Garzik

    Jay Vosburgh
     

10 Jul, 2007

1 commit


09 Jul, 2007

1 commit


08 Jul, 2007

1 commit

  • When cleaning up HIDP sessions, we currently close the ACL connection
    before deregistering the input device. Closing the ACL connection
    schedules a workqueue to remove the associated objects from sysfs, but
    the input device still refers to them -- and if the workqueue happens to
    run before the input device removal, the kernel will oops when trying to
    look up PHYSDEVPATH for the removed input device.

    Fix this by deregistering the input device before closing the
    connections.

    Signed-off-by: David Woodhouse
    Acked-by: Marcel Holtmann
    Signed-off-by: Linus Torvalds

    David Woodhouse
     

06 Jul, 2007

7 commits


29 Jun, 2007

2 commits


27 Jun, 2007

1 commit

  • If sky2 device poll routine is called from netpoll_send_skb, it would
    deadlock. The netpoll_send_skb held the netif_tx_lock, and the poll
    routine could acquire it to clean up skb's. Other drivers might use
    same locking model.

    The driver is correct, netpoll should not introduce more locking
    problems than it causes already. So change the code to drop lock
    before calling poll handler.

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

    Stephen Hemminger
     

26 Jun, 2007

1 commit

  • sctp_sock_migrate() grabs the socket lock on a newly allocated socket while
    holding the socket lock on an old socket. lockdep worries that this might
    be a recursive lock attempt.

    task/3026 is trying to acquire lock:
    (sk_lock-AF_INET){--..}, at: [] sctp_sock_migrate+0x2e3/0x327 [sctp]
    but task is already holding lock:
    (sk_lock-AF_INET){--..}, at: [] sctp_accept+0xdf/0x1e3 [sctp]

    This patch tells lockdep that this locking is safe by using
    lock_sock_nested().

    Signed-off-by: Zach Brown
    Signed-off-by: Vlad Yasevich

    Zach Brown
     

24 Jun, 2007

5 commits


23 Jun, 2007

3 commits


19 Jun, 2007

5 commits

  • This is the split out of the patch that we agreed I should split
    out from my last patch. It changes space_left to be computed in the same
    way the to variable is. I know we talked about changing space_left to an
    int, but I think size_t is more appropriate, since we should never have
    negative space in our buffer, and computing using offsetof means space_left
    should now never drop below zero.

    Signed-off-by: Neil Horman
    Acked-by: Sridhar Samudrala
    Signed-off-by: Vlad Yasevich

    Neil Horman
     
  • I noted the other day while looking at a bug that was ostensibly
    in some perl networking library, that we strictly avoid allowing getsockopt
    operations to complete if we pass in oversized buffers. This seems to make
    libraries like Perl::NET malfunction since it seems to allocate oversized
    buffers for use in several operations. It also seems to be out of line with
    the way udp, tcp and ip getsockopt routines handle buffer input (since the
    *optlen pointer in both an input and an output and gets set to the length
    of the data that we copy into the buffer). This patch brings our getsockopt
    helpers into line with other protocols, and allows us to accept oversized
    buffers for our getsockopt operations. Tested by me with good results.

    Signed-off-by: Neil Horman
    Acked-by: Sridhar Samudrala
    Signed-off-by: Vlad Yasevich

    Neil Horman
     
  • Return the number of bytes buffered in rxrpc_send_data().

    Signed-off-by: David Howells
    Signed-off-by: David S. Miller

    David Howells
     
  • ip_vs currently fails to reset its ip_vs_sync_state variable if the
    sync thread fails to start properly. The result is that the kernel
    will report a running daemon when their actuall is none.

    If you issue the following commands:

    1. ipvsadm --start-daemon master --mcast-interface bla
    2. ipvsadm -L --daemon
    3. ipvsadm --stop-daemon master

    Assuming that bla is not an actual interface, step 2 should return no
    data, but instead returns:

    $ ipvsadm -L --daemon
    master sync daemon (mcast=bla, syncid=0)

    Signed-off-by: Neil Horman
    Signed-off-by: David S. Miller

    Neil Horman
     
  • My IPsec MTU optimization patch introduced a regression in MTU calculation
    for non-ESP SAs, the SA's header_len needs to be subtracted from the MTU if
    the transform doesn't provide a ->get_mtu() function.

    Reported-and-tested-by: Marco Berizzi

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     

16 Jun, 2007

3 commits

  • This patch fixes a NULL dereference spotted by the Coverity checker.

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

    Adrian Bunk
     
  • Commit 6f74651ae626ec672028587bc700538076dfbefb is found guilty
    of breaking DSACK counting, which should be done only for the
    SACK block reported by the DSACK instead of every SACK block
    that is received along with DSACK information.

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     
  • Commit 164891aadf1721fca4dce473bb0e0998181537c6 broke RTT
    sampling of congestion control modules. Inaccurate timestamps
    could be fed to them without providing any way for them to
    identify such cases. Previously RTT sampler was called only if
    FLAG_RETRANS_DATA_ACKED was not set filtering inaccurate
    timestamps nicely. In addition, the new behavior could give an
    invalid timestamp (zero) to RTT sampler if only skbs with
    TCPCB_RETRANS were ACKed. This solves both problems.

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     

15 Jun, 2007

3 commits

  • David S. Miller
     
  • The recent patch that added ipv6_hwtype is broken on tuntap tunnels.
    Indeed, it's broken on any device that does not pass the ipv6_hwtype
    test.

    The reason is that the original test only applies to autoconfiguration,
    not IPv6 support. IPv6 support is allowed on any device. In fact,
    even with the ipv6_hwtype patch applied you can still add IPv6 addresses
    to any interface that doesn't pass thw ipv6_hwtype test provided that
    they have a sufficiently large MTU. This is a serious problem because
    come deregistration time these devices won't be cleaned up properly.

    I've gone back and looked at the rationale for the patch. It appears
    that the real problem is that we were creating IPv6 devices even if the
    MTU was too small. So here's a patch which fixes that and reverts the
    ipv6_hwtype stuff.

    Thanks to Kanru Chen for reporting this issue.

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

    Herbert Xu
     
  • This flaw does not affect any behavior (currently).

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     

14 Jun, 2007

5 commits