Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 19 3月, 2009 1 次提交
    • K
      tulip: fix crash on iface up with shirq debug · 69145635
      由 Kyle McMartin 提交于 
      Tulip is currently doing request_irq before it has done its
initialization. This is usually not a problem because it hasn't
enable interrupts yet, but with DEBUG_SHIRQ on, we call the irq handler
when registering the interrupt as a sanity check.

This can result in a NULL ptr dereference, so call tulip_init_ring
before request_irq, and add a free_ring function to do the freeing
now shared with tulip_close.

Tested with a shell loop running ifup, ifdown in a loop a few hundred
times with DEBUG_SHIRQ on.
Signed-off-by: NKyle McMartin <kyle@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69145635
  3. 08 1月, 2009 1 次提交
  5. 26 12月, 2008 1 次提交
  7. 28 10月, 2008 1 次提交
  9. 25 6月, 2008 1 次提交
  11. 12 6月, 2008 1 次提交
    • D
      net: Eliminate flush_scheduled_work() calls while RTNL is held. · 4bb073c0
      由 David S. Miller 提交于 
      If the RTNL is held when we invoke flush_scheduled_work() we could
deadlock.  One such case is linkwatch, it is a work struct which tries
to grab the RTNL semaphore.

The most common case are net driver ->stop() methods.  The
simplest conversion is to instead use cancel_{delayed_}work_sync()
explicitly on the various work struct the driver uses.

This is an OK transformation because these work structs are doing
things like resetting the chip, restarting link negotiation, and so
forth.  And if we're bringing down the device, we're about to turn the
chip off and reset it anways.  So if we cancel a pending work event,
that's fine here.

Some drivers were working around this deadlock by using a msleep()
polling loop of some sort, and those cases are converted to instead
use cancel_{delayed_}work_sync() as well.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bb073c0
  13. 31 5月, 2008 1 次提交
  15. 29 4月, 2008 1 次提交
  17. 17 4月, 2008 1 次提交
  19. 29 3月, 2008 1 次提交
    • G
      [netdrvr] tulip_read_eeprom fixes for BUG 4420 · 209261c0
      由 Grant Grundler 提交于 
      If "location" is > "addr_len" bits, the high bits of location would interfere
with the READ_CMD sent to the eeprom controller.

A patch was submitted to bug:
    http://bugzilla.kernel.org/show_bug.cgi?id=4420

which simply truncated the "location", read whatever was in "location
modulo addr_len", and returned that value. That avoids confusing the
eeprom but seems like the wrong solution to me.

Correct would be to not read beyond "1 << addr_len" address of the eeprom.
I am submitting two changes to implement this:
1) tulip_read_eeprom will return zero (since we can't return -EINVAL)
   if this is attempted (defensive programming).
2) In tulip_core.c, fix the tulip_read_eeprom caller so they don't
   iterate past addr_len bits and make sure the entire tp->eeprom[]
   array is cleared.

I konw we don't strictly need both. I would prefer both in the tree
since it documents the issue and provides a second "defense" from
the bug from creeping back in.
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      209261c0
  21. 13 1月, 2008 1 次提交
  23. 15 10月, 2007 1 次提交
  25. 11 10月, 2007 4 次提交
    • A
      tulip: endianness annotations · c559a5bc
      由 Al Viro 提交于 
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      c559a5bc
    • J
      [NET]: Introduce and use print_mac() and DECLARE_MAC_BUF() · 0795af57
      由 Joe Perches 提交于 
      This is nicer than the MAC_FMT stuff.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0795af57
    • R
      [NET]: Nuke SET_MODULE_OWNER macro. · 10d024c1
      由 Ralf Baechle 提交于 
      It's been a useless no-op for long enough in 2.6 so I figured it's time to
remove it.  The number of people that could object because they're
maintaining unified 2.4 and 2.6 drivers is probably rather small.

[ Handled drivers added by netdev tree and some missed IRDA cases... -DaveM ]
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10d024c1
    • S
      [NET]: Make NAPI polling independent of struct net_device objects. · bea3348e
      由 Stephen Hemminger 提交于 
      Several devices have multiple independant RX queues per net
device, and some have a single interrupt doorbell for several
queues.

In either case, it's easier to support layouts like that if the
structure representing the poll is independant from the net
device itself.

The signature of the ->poll() call back goes from:

	int foo_poll(struct net_device *dev, int *budget)

to

	int foo_poll(struct napi_struct *napi, int budget)

The caller is returned the number of RX packets processed (or
the number of "NAPI credits" consumed if you want to get
abstract).  The callee no longer messes around bumping
dev->quota, *budget, etc. because that is all handled in the
caller upon return.

The napi_struct is to be embedded in the device driver private data
structures.

Furthermore, it is the driver's responsibility to disable all NAPI
instances in it's ->stop() device close handler.  Since the
napi_struct is privatized into the driver's private data structures,
only the driver knows how to get at all of the napi_struct instances
it may have per-device.

With lots of help and suggestions from Rusty Russell, Roland Dreier,
Michael Chan, Jeff Garzik, and Jamal Hadi Salim.

Bug fixes from Thomas Graf, Roland Dreier, Peter Zijlstra,
Joseph Fannin, Scott Wood, Hans J. Koch, and Michael Chan.

[ Ported to current tree and all drivers converted.  Integrated
  Stephen's follow-on kerneldoc additions, and restored poll_list
  handling to the old style to fix mutual exclusion issues.  -DaveM ]
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bea3348e
  27. 01 8月, 2007 1 次提交
  29. 16 7月, 2007 1 次提交
  31. 12 7月, 2007 2 次提交
  33. 28 4月, 2007 1 次提交
  35. 26 4月, 2007 3 次提交
  37. 03 3月, 2007 1 次提交
  39. 22 11月, 2006 1 次提交
  41. 05 10月, 2006 1 次提交
    • D
      IRQ: Maintain regs pointer globally rather than passing to IRQ handlers · 7d12e780
      由 David Howells 提交于 
      Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.

The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around.  On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).

Where appropriate, an arch may override the generic storage facility and do
something different with the variable.  On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.

Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions.  Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller.  A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.

I've build this code with allyesconfig for x86_64 and i386.  I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.

This will affect all archs.  Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:

	struct pt_regs *old_regs = set_irq_regs(regs);

And put the old one back at the end:

	set_irq_regs(old_regs);

Don't pass regs through to generic_handle_irq() or __do_IRQ().

In timer_interrupt(), this sort of change will be necessary:

	-	update_process_times(user_mode(regs));
	-	profile_tick(CPU_PROFILING, regs);
	+	update_process_times(user_mode(get_irq_regs()));
	+	profile_tick(CPU_PROFILING);

I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().

Some notes on the interrupt handling in the drivers:

 (*) input_dev() is now gone entirely.  The regs pointer is no longer stored in
     the input_dev struct.

 (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking.  It does
     something different depending on whether it's been supplied with a regs
     pointer or not.

 (*) Various IRQ handler function pointers have been moved to type
     irq_handler_t.
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
      7d12e780
  43. 14 9月, 2006 2 次提交
  45. 12 9月, 2006 1 次提交
    • A
      [PATCH] Remove more unnecessary driver printk's · d5b20697
      由 Andy Gospodarek 提交于 
      As I promised last week, here is the first pass at removing all
unnecessary printk's that exist in network device drivers currently in
promiscuous mode.  The duplicate messages are not needed so they have
been removed.  Some of these drivers are quite old and might not need an
update, but I did them all anyway.

I am currently auditing the remaining conditional printk's and will send
out a patch for those soon.
Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      d5b20697
  47. 11 9月, 2006 7 次提交
  49. 20 8月, 2006 1 次提交
  51. 03 7月, 2006 1 次提交
  53. 01 7月, 2006 1 次提交