1. 21 Sep, 2007 37 commits
  2. 20 Sep, 2007 3 commits
    • Linus Torvalds's avatar
      Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev · 335fb8fc
      Linus Torvalds authored
      * 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev:
        [libata] ahci: add ATI SB800 PCI IDs
        libata-sff: Fix documentation
        libata: Update the blacklist with a few more devices
      335fb8fc
    • Davide Libenzi's avatar
      signalfd simplification · b8fceee1
      Davide Libenzi authored
      This simplifies signalfd code, by avoiding it to remain attached to the
      sighand during its lifetime.
      
      In this way, the signalfd remain attached to the sighand only during
      poll(2) (and select and epoll) and read(2).  This also allows to remove
      all the custom "tsk == current" checks in kernel/signal.c, since
      dequeue_signal() will only be called by "current".
      
      I think this is also what Ben was suggesting time ago.
      
      The external effect of this, is that a thread can extract only its own
      private signals and the group ones.  I think this is an acceptable
      behaviour, in that those are the signals the thread would be able to
      fetch w/out signalfd.
      Signed-off-by: default avatarDavide Libenzi <davidel@xmailserver.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b8fceee1
    • Wolfgang Walter's avatar
      rpc: fix garbage in printk in svc_tcp_accept() · 9db619e6
      Wolfgang Walter authored
      we upgraded the kernel of a nfs-server from 2.6.17.11 to 2.6.22.6. Since
      then we get the message
      
      lockd: too many open TCP sockets, consider increasing the number of nfsd threads
      lockd: last TCP connect from ^\\236^\É^D
      
      These random characters in the second line are caused by a bug in
      svc_tcp_accept.
      
      (Note: there are two previous __svc_print_addr(sin, buf, sizeof(buf))
      calls in this function, either of which would initialize buf correctly;
      but both are inside "if"'s and are not necessarily executed.  This is
      less obvious in the second case, which is inside a dprintk(), which is a
      macro which expands to an if statement.)
      Signed-off-by: default avatarWolfgang Walter <wolfgang.walter@studentenwerk.mhn.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9db619e6