Eric Lee / smarc-fsl-linux-kernel

11 Feb, 2007

1 commit

13 Jul, 2006

1 commit

  • a6f157a88   [NET]: fix __sk_stream_mem_reclaim ... Browse Code »

    __sk_stream_mem_reclaim is only called by sk_stream_mem_reclaim.

    As such the check on sk->sk_forward_alloc is not needed and can be
    removed.

    Signed-off-by: Ian McDonald
    Acked-by: Herbert Xu
    Signed-off-by: David S. Miller

    Ian McDonald
     

20 Apr, 2006

1 commit

  • dc6de3367   [NET]: Add skb->truesize assertion checking. ... Browse Code »

    Add some sanity checking. truesize should be at least sizeof(struct
    sk_buff) plus the current packet length. If not, then truesize is
    seriously mangled and deserves a kernel log message.

    Currently we'll do the check for release of stream socket buffers.

    But we can add checks to more spots over time.

    Incorporating ideas from Herbert Xu.

    Signed-off-by: David S. Miller

    David S. Miller
     

04 Jan, 2006

1 commit

  • c1cbe4b7a   [NET]: Avoid atomic xchg() for non-error case ... Browse Code »

    It also looks like there were 2 places where the test on sk_err was
    missing from the event wait logic (in sk_stream_wait_connect and
    sk_stream_wait_memory), while the rest of the sock_error() users look
    to be doing the right thing. This version of the patch fixes those,
    and cleans up a few places that were testing ->sk_err directly.

    Signed-off-by: Benjamin LaHaise
    Signed-off-by: David S. Miller

    Benjamin LaHaise
     

06 Nov, 2005

1 commit

  • 6151b31c9   [NET]: Fix race condition in sk_stream_wait_connect ... Browse Code »

    When sk_stream_wait_connect detects a state transition to ESTABLISHED
    or CLOSE_WAIT prior to it going to sleep, it will return without
    calling finish_wait and decrementing sk_write_pending.

    This may result in crashes and other unintended behaviour.

    The fix is to always call finish_wait and update sk_write_pending since
    it is safe to do so even if the wait entry is no longer on the queue.

    This bug was tracked down with the help of Alex Sidorenko and the
    fix is also based on his suggestion.

    Signed-off-by: Herbert Xu
    Signed-off-by: Arnaldo Carvalho de Melo

    Herbert Xu
     

01 May, 2005

1 commit

  • 4dc3b16ba   [PATCH] DocBook: changes and extensions to the kernel documentation ... Browse Code »

    I have recompiled Linux kernel 2.6.11.5 documentation for me and our
    university students again. The documentation could be extended for more
    sources which are equipped by structured comments for recent 2.6 kernels. I
    have tried to proceed with that task. I have done that more times from 2.6.0
    time and it gets boring to do same changes again and again. Linux kernel
    compiles after changes for i386 and ARM targets. I have added references to
    some more files into kernel-api book, I have added some section names as well.
    So please, check that changes do not break something and that categories are
    not too much skewed.

    I have changed kernel-doc to accept "fastcall" and "asmlinkage" words reserved
    by kernel convention. Most of the other changes are modifications in the
    comments to make kernel-doc happy, accept some parameters description and do
    not bail out on errors. Changed to @pid in the description, moved some
    #ifdef before comments to correct function to comments bindings, etc.

    You can see result of the modified documentation build at
    http://cmp.felk.cvut.cz/~pisa/linux/lkdb-2.6.11.tar.gz

    Some more sources are ready to be included into kernel-doc generated
    documentation. Sources has been added into kernel-api for now. Some more
    section names added and probably some more chaos introduced as result of quick
    cleanup work.

    Signed-off-by: Pavel Pisa
    Signed-off-by: Martin Waitz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Pisa
     

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