Skip to content
Snippets Groups Projects
Select Git revision
  • llvm_v4.8
  • dev_smp_nullb
  • dev_smp
  • dev_nullb
  • lcd_v4.8 default
  • dev_foobar
  • dev_ixgbe
  • dev_netdummy
  • depriv
  • dev_idl_4.8_no_channels
  • dev_idl_4.8
  • dev_idl
  • temp_lcd_v4.8
  • idl_fixes
  • lcd
  • lcd_stack_protector
  • irq
  • pmfs
  • dev_nvme
  • async
  • sosp-19
  • v3.11.3
  • v3.10.14
  • v3.4.64
  • v3.0.98
  • v3.12-rc3
  • v3.11.2
  • v3.10.13
  • v3.4.63
  • v3.0.97
  • v3.12-rc2
  • v3.12-rc1
  • v3.11.1
  • v3.10.12
  • v3.4.62
  • v3.0.96
  • v3.2.51
  • v3.10.11
  • v3.4.61
  • v3.0.95
40 results
Search by author
  • Any Author
  • Abhiram Balasubramanian Abhiram Balasubramanian abhiram
  • Anton Burtsev Anton Burtsev aburtsev
  • Charlie Jacobsen Charlie Jacobsen cjacobsen
  • David Detweiler David Detweiler ddetweiler
  • David Johnson David Johnson johnsond
  • Michael Quigley Michael Quigley MichaelQuigley
  • Mike Hibler Mike Hibler hibler
  • Robert Ricci Robert Ricci ricci
  • Sarah Spall Sarah Spall spall
  • Scotty Bauer Scotty Bauer ScottyB
  • Vikram Narayanan Vikram Narayanan vikram
11 authors
  1. Jul 27, 2011
    • Neil Horman's avatar
      net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared · 550fd08c
      Neil Horman authored 
      
After the last patch, We are left in a state in which only drivers calling
ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real
hardware call ether_setup for their net_devices and don't hold any state in
their skbs.  There are a handful of drivers that violate this assumption of
course, and need to be fixed up.  This patch identifies those drivers, and marks
them as not being able to support the safe transmission of skbs by clearning the
IFF_TX_SKB_SHARING flag in priv_flags

Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
CC: Karsten Keil <isdn@linux-pingi.de>
CC: "David S. Miller" <davem@davemloft.net>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Patrick McHardy <kaber@trash.net>
CC: Krzysztof Halasa <khc@pm.waw.pl>
CC: "John W. Linville" <linville@tuxdriver.com>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: Marcel Holtmann <marcel@holtmann.org>
CC: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      550fd08c
  3. Jul 22, 2011
  5. Jun 30, 2011
  7. Jun 27, 2011
  9. Jun 24, 2011
  11. Jun 21, 2011
  13. Jun 17, 2011
  15. Jun 06, 2011
  17. Jun 03, 2011
    • Linus Torvalds's avatar
      Revert "tty: make receive_buf() return the amout of bytes received" · 55db4c64
      Linus Torvalds authored 
      
This reverts commit b1c43f82.

It was broken in so many ways, and results in random odd pty issues.

It re-introduced the buggy schedule_work() in flush_to_ldisc() that can
cause endless work-loops (see commit a5660b41: "tty: fix endless
work loop when the buffer fills up").

It also used an "unsigned int" return value fo the ->receive_buf()
function, but then made multiple functions return a negative error code,
and didn't actually check for the error in the caller.

And it didn't actually work at all.  BenH bisected down odd tty behavior
to it:
  "It looks like the patch is causing some major malfunctions of the X
   server for me, possibly related to PTYs.  For example, cat'ing a
   large file in a gnome terminal hangs the kernel for -minutes- in a
   loop of what looks like flush_to_ldisc/workqueue code, (some ftrace
   data in the quoted bits further down).

   ...

   Some more data: It -looks- like what happens is that the
   flush_to_ldisc work queue entry constantly re-queues itself (because
   the PTY is full ?) and the workqueue thread will basically loop
   forver calling it without ever scheduling, thus starving the consumer
   process that could have emptied the PTY."

which is pretty much exactly the problem we fixed in a5660b41.

Milton Miller pointed out the 'unsigned int' issue.

Reported-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reported-by: default avatarMilton Miller <miltonm@bga.com>
Cc: Stefan Bigler <stefan.bigler@keymile.com>
Cc: Toby Gray <toby.gray@realvnc.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      55db4c64
  19. May 26, 2011
  21. May 10, 2011
  23. May 05, 2011
  25. Apr 22, 2011
  27. Mar 31, 2011
  29. Mar 17, 2011
  31. Feb 17, 2011
  33. Dec 21, 2010
  35. Dec 12, 2010
  37. Nov 29, 2010
  39. Nov 28, 2010
  41. Nov 01, 2010
  43. Oct 18, 2010
  45. Oct 12, 2010
  47. Sep 26, 2010
  49. Sep 21, 2010
  51. Sep 15, 2010
  53. Sep 06, 2010
  55. Aug 25, 2010
  57. Aug 16, 2010
  59. Aug 10, 2010
    • David S. Miller's avatar
      farsync: Fix compile warnings. · 5d337d6f
      David S. Miller authored 
      
drivers/net/wan/farsync.c: In function 'fst_intr_rx':
drivers/net/wan/farsync.c:1312: warning: cast to pointer from integer of different size
drivers/net/wan/farsync.c: In function 'do_bottom_half_tx':
drivers/net/wan/farsync.c:1407: warning: cast to pointer from integer of different size

The "skb" and "mem" arguments being passed here are DMA addresses
being programmed into the hardware registers, so pass them as the type
that they actually are.  And use the correct printf formatting in
debug logging statements for these things to match the type change.

Reported-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d337d6f
  61. Aug 02, 2010
  63. Jul 12, 2010
    • Arnd Bergmann's avatar
      net: autoconvert trivial BKL users to private mutex · 15fd0cd9
      Arnd Bergmann authored 
      
All these files use the big kernel lock in a trivial
way to serialize their private file operations,
typically resulting from an earlier semi-automatic
pushdown from VFS.

None of these drivers appears to want to lock against
other code, and they all use the BKL as the top-level
lock in their file operations, meaning that there
is no lock-order inversion problem.

Consequently, we can remove the BKL completely,
replacing it with a per-file mutex in every case.
Using a scripted approach means we can avoid
typos.

file=$1
name=$2
if grep -q lock_kernel ${file} ; then
    if grep -q 'include.*linux.mutex.h' ${file} ; then
            sed -i '/include.*<linux\/smp_lock.h>/d' ${file}
    else
            sed -i 's/include.*<linux\/smp_lock.h>.*$/include <linux\/mutex.h>/g' ${file}
    fi
    sed -i ${file} \
        -e "/^#include.*linux.mutex.h/,$ {
                1,/^\(static\|int\|long\)/ {
                     /^\(static\|int\|long\)/istatic DEFINE_MUTEX(${name}_mutex);

} }"  \
    -e "s/\(un\)*lock_kernel\>[ ]*()/mutex_\1lock(\&${name}_mutex)/g" \
    -e '/[      ]*cycle_kernel_lock();/d'
else
    sed -i -e '/include.*\<smp_lock.h\>/d' ${file}  \
                -e '/cycle_kernel_lock()/d'
fi

Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15fd0cd9