29 Mar, 2012

1 commit


07 Oct, 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
     

29 Jan, 2008

1 commit

  • 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
     

15 Feb, 2007

1 commit

  • 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


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