Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 09 5月, 2008 1 次提交
  3. 08 5月, 2008 1 次提交
    • P
      macvlan: Fix memleak on device removal/crash on module removal · 73120964
      由 Patrick McHardy 提交于 
      As noticed by Ben Greear, macvlan crashes the kernel when unloading the
module. The reason is that it tries to clean up the macvlan_port pointer
on the macvlan device itself instead of the underlying device. A non-NULL
pointer is taken as indication that the macvlan_handle_frame_hook is
valid, when receiving the next packet on the underlying device it tries
to call the NULL hook and crashes.

Clean up the macvlan_port on the correct device to fix this.

Signed-off-by; Patrick McHardy <kaber@trash.net>
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73120964
  5. 07 5月, 2008 19 次提交
  7. 06 5月, 2008 2 次提交
  9. 05 5月, 2008 2 次提交
    • I
      irda: fix !PNP support for drivers/net/irda/smsc-ircc2.c · 7a1aa309
      由 Ingo Molnar 提交于 
      x86.git testing found this build bug on v2.6.26-rc1:

  ERROR: "pnp_get_resource" [drivers/net/irda/smsc-ircc2.ko] undefined!
  make[1]: *** [__modpost] Error 1
  make: *** [modules] Error 2

the driver did not anticipate the case of !CONFIG_PNP which is rare but 
still possible. Instead of restricting the driver to PNP-only in the 
Kconfig space, add the (trivial) dummy struct pnp_driver - this is that 
other drivers use in the !PNP case too.

The driver itself can in theory be initialized on !PNP too in certain 
cases, via smsc_ircc_legacy_probe().

Patch only minimally build tested, i dont have this hardware.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7a1aa309
    • I
      irda: fix !PNP support in drivers/net/irda/nsc-ircc.c · c17f888f
      由 Ingo Molnar 提交于 
      x86.git testing found the following build failure in latest -git:

 drivers/built-in.o: In function `nsc_ircc_pnp_probe':
 nsc-ircc.c:(.text+0xdf1b6): undefined reference to `pnp_get_resource'
 nsc-ircc.c:(.text+0xdf1d4): undefined reference to `pnp_get_resource'
 nsc-ircc.c:(.text+0xdf1ee): undefined reference to `pnp_get_resource'
 nsc-ircc.c:(.text+0xdf237): undefined reference to `pnp_get_resource'
 nsc-ircc.c:(.text+0xdf24c): undefined reference to `pnp_get_resource'
 drivers/built-in.o:nsc-ircc.c:(.text+0xdf266): more undefined references to `pnp_get_resource' follow
 make: *** [.tmp_vmlinux1] Error 1

triggered via this config:

  http://redhat.com/~mingo/misc/config-Sat_May__3_20_53_13_CEST_2008.bad

while generally most users will have PNP enabled, drivers can support
non-PNP build mode too - and most drivers implement it. That is typically
done by providing a dummy pnp_driver structure that will not probe anything.

The fallback routines in the driver will handle this dumber mode of
operation too.

This patch implements that. I have not tested whether this actually
works on real hardware so take care. It does resolve the build bug.

[ Another solution that is used by a few drivers is to exclude the driver
  in the Kconfig if PNP is disabled, via "depends on PNP", but this would
  limit the availability of the driver needlessly. ]
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c17f888f
  11. 04 5月, 2008 2 次提交
  13. 03 5月, 2008 11 次提交
  15. 02 5月, 2008 2 次提交
    • R
      virtio: explicit advertisement of driver features · c45a6816
      由 Rusty Russell 提交于 
      A recent proposed feature addition to the virtio block driver revealed
some flaws in the API: in particular, we assume that feature
negotiation is complete once a driver's probe function returns.

There is nothing in the API to require this, however, and even I
didn't notice when it was violated.

So instead, we require the driver to specify what features it supports
in a table, we can then move the feature negotiation into the virtio
core.  The intersection of device and driver features are presented in
a new 'features' bitmap in the struct virtio_device.

Note that this highlights the difference between Linux unsigned-long
bitmaps where each unsigned long is in native endian, and a
straight-forward little-endian array of bytes.

Drivers can still remove feature bits in their probe routine if they
really have to.

API changes:
- dev->config->feature() no longer gets and acks a feature.
- drivers should advertise their features in the 'feature_table' field
- use virtio_has_feature() for extra sanity when checking feature bits
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      c45a6816
    • R
      virtio: finer-grained features for virtio_net · 5539ae96
      由 Rusty Russell 提交于 
      So, we previously had a 'VIRTIO_NET_F_GSO' bit which meant that 'the
host can handle csum offload, and any TSO (v4&v6 incl ECN) or UFO
packets you might want to send.  I thought this was good enough for
Linux, but it actually isn't, since we don't do UFO in software.

So, add separate feature bits for what the host can handle.  Add
equivalent ones for the guest to say what it can handle, because LRO
is coming too (thanks Herbert!).
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      5539ae96