24 Jun, 2009

1 commit

  • In order to get the tun driver to account packets, we need to be
    able to receive packets with destructors set. To be on the safe
    side, I added an skb_orphan call for all protocols by default since
    some of them (IP in particular) cannot handle receiving packets
    destructors properly.

    Now it seems that at least one protocol (CAN) expects to be able
    to pass skb->sk through the rx path without getting clobbered.

    So this patch attempts to fix this properly by moving the skb_orphan
    call to where it's actually needed. In particular, I've added it
    to skb_set_owner_[rw] which is what most users of skb->destructor
    call.

    This is actually an improvement for tun too since it means that
    we only give back the amount charged to the socket when the skb
    is passed to another socket that will also be charged accordingly.

    Signed-off-by: Herbert Xu
    Tested-by: Oliver Hartkopp
    Signed-off-by: David S. Miller

    Herbert Xu
     

18 Jun, 2009

1 commit

  • commit 2b85a34e911bf483c27cfdd124aeb1605145dc80
    (net: No more expensive sock_hold()/sock_put() on each tx)
    changed initial sk_wmem_alloc value.

    We need to take into account this offset when reporting
    sk_wmem_alloc to user, in PROC_FS files or various
    ioctls (SIOCOUTQ/TIOCOUTQ)

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

    Eric Dumazet
     

17 Jun, 2009

1 commit

  • commit 2b85a34e911bf483c27cfdd124aeb1605145dc80
    (net: No more expensive sock_hold()/sock_put() on each tx)
    changed initial sk_wmem_alloc value.

    Some protocols check sk_wmem_alloc value to determine if a timer
    must delay socket deallocation. We must take care of the sk_wmem_alloc
    value being one instead of zero when no write allocations are pending.

    Reported by Ingo Molnar, and full diagnostic from David Miller.

    This patch introduces three helpers to get read/write allocations
    and a followup patch will use these helpers to report correct
    write allocations to user.

    Reported-by: Ingo Molnar
    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

20 Apr, 2009

1 commit

  • This has been broken for a while. I happened to catch it testing because one
    app "knew" that the top line of the calls data was the policy line and got
    confused.

    Put the header back.

    Signed-off-by: Alan Cox
    Signed-off-by: David S. Miller

    Alan Cox
     

28 Mar, 2009

1 commit


22 Mar, 2009

2 commits


10 Mar, 2009

1 commit


07 Feb, 2009

1 commit


01 Feb, 2009

1 commit


29 Dec, 2008

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (1429 commits)
    net: Allow dependancies of FDDI & Tokenring to be modular.
    igb: Fix build warning when DCA is disabled.
    net: Fix warning fallout from recent NAPI interface changes.
    gro: Fix potential use after free
    sfc: If AN is enabled, always read speed/duplex from the AN advertising bits
    sfc: When disabling the NIC, close the device rather than unregistering it
    sfc: SFT9001: Add cable diagnostics
    sfc: Add support for multiple PHY self-tests
    sfc: Merge top-level functions for self-tests
    sfc: Clean up PHY mode management in loopback self-test
    sfc: Fix unreliable link detection in some loopback modes
    sfc: Generate unique names for per-NIC workqueues
    802.3ad: use standard ethhdr instead of ad_header
    802.3ad: generalize out mac address initializer
    802.3ad: initialize ports LACPDU from const initializer
    802.3ad: remove typedef around ad_system
    802.3ad: turn ports is_individual into a bool
    802.3ad: turn ports is_enabled into a bool
    802.3ad: make ntt bool
    ixgbe: Fix set_ringparam in ixgbe to use the same memory pools.
    ...

    Fixed trivial IPv4/6 address printing conflicts in fs/cifs/connect.c due
    to the conversion to %pI (in this networking merge) and the addition of
    doing IPv6 addresses (from the earlier merge of CIFS).

    Linus Torvalds
     

15 Dec, 2008

1 commit


26 Nov, 2008

1 commit

  • fix this warning:

    net/ax25/sysctl_net_ax25.c:27: warning: ‘min_ds_timeout’ defined but not used
    net/ax25/sysctl_net_ax25.c:27: warning: ‘max_ds_timeout’ defined but not used

    These are only used in the CONFIG_AX25_DAMA_SLAVE case.

    Signed-off-by: Ingo Molnar
    Signed-off-by: David S. Miller

    Ingo Molnar
     

14 Nov, 2008

1 commit

  • Wrap access to task credentials so that they can be separated more easily from
    the task_struct during the introduction of COW creds.

    Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().

    Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more
    sense to use RCU directly rather than a convenient wrapper; these will be
    addressed by later patches.

    Signed-off-by: David Howells
    Reviewed-by: James Morris
    Acked-by: Serge Hallyn
    Acked-by: Ralf Baechle
    Cc: linux-hams@vger.kernel.org
    Signed-off-by: James Morris

    David Howells
     

04 Nov, 2008

1 commit

  • I want to compile out proc_* and sysctl_* handlers totally and
    stub them to NULL depending on config options, however usage of &
    will prevent this, since taking adress of NULL pointer will break
    compilation.

    So, drop & in front of every ->proc_handler and every ->strategy
    handler, it was never needed in fact.

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: David S. Miller

    Alexey Dobriyan
     

07 Oct, 2008

2 commits


06 Aug, 2008

1 commit

  • Since 49ffcf8f99e8d33ec8afb450956804af518fd788 ("sysctl: update
    sysctl_check_table") setting struct ctl_table.procname = NULL does no
    longer work as it used to the way the AX.25 code is expecting it to
    resulting in the AX.25 sysctl registration code to break if
    CONFIG_AX25_DAMA_SLAVE was not set as in some distribution kernels.
    Kernel releases from 2.6.24 are affected.

    Signed-off-by: Ralf Baechle
    Signed-off-by: David S. Miller

    Ralf Baechle
     

20 Jul, 2008

1 commit


18 Jun, 2008

1 commit

  • Tihomir Heidelberg - 9a4gl, reports:

    --------------------
    I would like to direct you attention to one problem existing in ax.25
    kernel since 2.4. If listening socket is closed and its SKB queue is
    released but those sockets get weird. Those "unAccepted()" sockets
    should be destroyed in ax25_std_heartbeat_expiry, but it will not
    happen. And there is also a note about that in ax25_std_timer.c:
    /* Magic here: If we listen() and a new link dies before it
    is accepted() it isn't 'dead' so doesn't get removed. */

    This issue cause ax25d to stop accepting new connections and I had to
    restarted ax25d approximately each day and my services were unavailable.
    Also netstat -n -l shows invalid source and device for those listening
    sockets. It is strange why ax25d's listening socket get weird because of
    this issue, but definitely when I solved this bug I do not have problems
    with ax25d anymore and my ax25d can run for months without problems.
    --------------------

    Actually as far as I can see, this problem is even in releases
    as far back as 2.2.x as well.

    It seems senseless to special case this test on TCP_LISTEN state.
    Anything still stuck in state 0 has no external references and
    we can just simply kill it off directly.

    Signed-off-by: David S. Miller

    David S. Miller
     

17 Jun, 2008

1 commit

  • The way that listening sockets work in ax25 is that the packet input
    code path creates new socks via ax25_make_new() and attaches them
    to the incoming SKB. This SKB gets queued up into the listening
    socket's receive queue.

    When accept()'d the sock gets hooked up to the real parent socket.
    Alternatively, if the listening socket is closed and released, any
    unborn socks stuff up in the receive queue get released.

    So during this time period these sockets are unreachable in any
    other way, so no wakeup events nor references to their ->sk_socket
    and ->sk_sleep members can occur. And even if they do, all such
    paths have to make NULL checks.

    So do not deceptively initialize them in ax25_make_new() to the
    values in the listening socket. Leave them at NULL.

    Finally, use sock_graft() in ax25_accept().

    Signed-off-by: David S. Miller

    David S. Miller
     

04 Jun, 2008

1 commit

  • From: Jarek Poplawski

    There is only one function in AX25 calling skb_append(), and it really
    looks suspicious: appends skb after previously enqueued one, but in
    the meantime this previous skb could be removed from the queue.

    This patch Fixes it the simple way, so this is not fully compatible with
    the current method, but testing hasn't shown any problems.

    Signed-off-by: Ralf Baechle
    Signed-off-by: David S. Miller

    Jarek Poplawski
     

14 Apr, 2008

1 commit


13 Apr, 2008

1 commit

  • The ax25_uid_free call walks the ax25_uid_list and releases entries
    from it. The problem is that after the fisrt call to hlist_del_init
    the hlist_for_each_entry (which hides behind the ax25_uid_for_each)
    will consider the current position to be the last and will return.

    Thus, the whole list will be left not freed.

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: David S. Miller

    Pavel Emelyanov
     

28 Mar, 2008

1 commit


26 Mar, 2008

3 commits


18 Feb, 2008

1 commit

  • According to some OOPS reports ax25_kick tries to clone NULL skbs
    sometimes. It looks like a race with ax25_clear_queues(). Probably
    there is no need to add more than a simple check for this yet.
    Another report suggested there are probably also cases where ax25
    ->paclen == 0 can happen in ax25_output(); this wasn't confirmed
    during testing but let's leave this debugging check for some time.

    Reported-and-tested-by: Jann Traschewski
    Signed-off-by: Jarek Poplawski
    Signed-off-by: David S. Miller

    Jarek Poplawski
     

13 Feb, 2008

4 commits

  • This patch changes current use of: init_timer(), add_timer()
    and del_timer() to setup_timer() with mod_timer(), which
    should be safer anyway.

    Reported-by: Jann Traschewski
    Signed-off-by: Jarek Poplawski
    Signed-off-by: David S. Miller

    Jarek Poplawski
     
  • According to one of Jann's OOPS reports it looks like
    BUG_ON(timer_pending(timer)) triggers during add_timer()
    in ax25_start_t1timer(). This patch changes current use
    of: init_timer(), add_timer() and del_timer() to
    setup_timer() with mod_timer(), which should be safer
    anyway.

    Reported-by: Jann Traschewski
    Signed-off-by: Jarek Poplawski
    Signed-off-by: David S. Miller

    Jarek Poplawski
     
  • > =================================
    > [ INFO: inconsistent lock state ]
    > 2.6.24-dg8ngn-p02 #1
    > ---------------------------------
    > inconsistent {softirq-on-W} -> {in-softirq-R} usage.
    > linuxnet/3046 [HC0[0]:SC1[2]:HE1:SE0] takes:
    > (ax25_route_lock){--.+}, at: [] ax25_get_route+0x18/0xb7 [ax25]
    > {softirq-on-W} state was registered at:
    ...

    This lockdep report shows that ax25_route_lock is taken for reading in
    softirq context, and for writing in process context with BHs enabled.
    So, to make this safe, all write_locks in ax25_route.c are changed to
    _bh versions.

    Reported-by: Jann Traschewski ,
    Signed-off-by: Jarek Poplawski
    Signed-off-by: David S. Miller

    Jarek Poplawski
     
  • This lockdep warning:

    > =======================================================
    > [ INFO: possible circular locking dependency detected ]
    > 2.6.24 #3
    > -------------------------------------------------------
    > swapper/0 is trying to acquire lock:
    > (ax25_list_lock){-+..}, at: [] ax25_destroy_socket+0x171/0x1f0 [ax25]
    >
    > but task is already holding lock:
    > (slock-AF_AX25){-+..}, at: [] ax25_std_heartbeat_expiry+0x1c/0xe0 [ax25]
    >
    > which lock already depends on the new lock.
    ...

    shows that ax25_list_lock and slock-AF_AX25 are taken in different
    order: ax25_info_show() takes slock (bh_lock_sock(ax25->sk)) while
    ax25_list_lock is held, so reversely to other functions. To fix this
    the sock lock should be moved to ax25_info_start(), and there would
    be still problem with breaking ax25_list_lock (it seems this "proper"
    order isn't optimal yet). But, since it's only for reading proc info
    it seems this is not necessary (e.g. ax25_send_to_raw() does similar
    reading without this lock too).

    So, this patch removes sock lock to avoid deadlock possibility; there
    is also used sock_i_ino() function, which reads sk_socket under proper
    read lock. Additionally printf format of this i_ino is changed to %lu.

    Reported-by: Bernard Pidoux F6BVP
    Signed-off-by: Jarek Poplawski
    Signed-off-by: David S. Miller

    Jarek Poplawski
     

01 Feb, 2008

1 commit


29 Jan, 2008

3 commits

  • net/ax25/ax25_route.c:251:13: warning: context imbalance in
    'ax25_rt_seq_start' - wrong count at exit
    net/ax25/ax25_route.c:276:13: warning: context imbalance in 'ax25_rt_seq_stop'
    - unexpected unlock
    net/ax25/ax25_std_timer.c:65:25: warning: expensive signed divide
    net/ax25/ax25_uid.c:46:1: warning: symbol 'ax25_uid_list' was not declared.
    Should it be static?
    net/ax25/ax25_uid.c:146:13: warning: context imbalance in 'ax25_uid_seq_start'
    - wrong count at exit
    net/ax25/ax25_uid.c:169:13: warning: context imbalance in 'ax25_uid_seq_stop'
    - unexpected unlock
    net/ax25/af_ax25.c:573:28: warning: expensive signed divide
    net/ax25/af_ax25.c:1865:13: warning: context imbalance in 'ax25_info_start' -
    wrong count at exit
    net/ax25/af_ax25.c:1888:13: warning: context imbalance in 'ax25_info_stop' -
    unexpected unlock
    net/ax25/ax25_ds_timer.c:133:25: warning: expensive signed divide

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

    Eric Dumazet
     
  • This one is almost the same as the hunks in the
    first patch, but ax25 tables are created dynamically.

    So this patch differs a bit to handle this case.

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: David S. Miller

    Pavel Emelyanov
     
  • Many-many code in the kernel initialized the timer->function
    and timer->data together with calling init_timer(timer). There
    is already a helper for this. Use it for networking code.

    The patch is HUGE, but makes the code 130 lines shorter
    (98 insertions(+), 228 deletions(-)).

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

    Pavel Emelyanov
     

11 Jan, 2008

1 commit

  • Bernard Pidoux F6BVP reported:
    > When I killall kissattach I can see the following message.
    >
    > This happens on kernel 2.6.24-rc5 already patched with the 6 previously
    > patches I sent recently.
    >
    >
    > =======================================================
    > [ INFO: possible circular locking dependency detected ]
    > 2.6.23.9 #1
    > -------------------------------------------------------
    > kissattach/2906 is trying to acquire lock:
    > (linkfail_lock){-+..}, at: [] ax25_link_failed+0x11/0x39 [ax25]
    >
    > but task is already holding lock:
    > (ax25_list_lock){-+..}, at: [] ax25_device_event+0x38/0x84
    > [ax25]
    >
    > which lock already depends on the new lock.
    >
    >
    > the existing dependency chain (in reverse order) is:
    ...

    lockdep is worried about the different order here:

    #1 (rose_neigh_list_lock){-+..}:
    #3 (ax25_list_lock){-+..}:

    #0 (linkfail_lock){-+..}:
    #1 (rose_neigh_list_lock){-+..}:

    #3 (ax25_list_lock){-+..}:
    #0 (linkfail_lock){-+..}:

    So, ax25_list_lock could be taken before and after linkfail_lock.
    I don't know if this three-thread clutch is very probable (or
    possible at all), but it seems another bug reported by Bernard
    ("[...] system impossible to reboot with linux-2.6.24-rc5")
    could have similar source - namely ax25_list_lock held by
    ax25_kill_by_device() during ax25_disconnect(). It looks like the
    only place which calls ax25_disconnect() this way, so I guess, it
    isn't necessary.

    This patch is breaking the lock for ax25_disconnect().

    Reported-and-tested-by: Bernard Pidoux
    Signed-off-by: Jarek Poplawski
    Signed-off-by: David S. Miller

    Jarek Poplawski
     

10 Jan, 2008

1 commit

  • sfuzz can easily trigger any of those.

    move the printk message to the corresponding comment: makes the
    intention of the code clear and easy to pick up on an scheduled
    removal. as bonus simplify the braces placement.

    Signed-off-by: maximilian attems
    Signed-off-by: David S. Miller

    maximilian attems
     

20 Dec, 2007

1 commit