1. 13 5月, 2008 1 次提交
    • J
      pppol2tp: Remove null pointer dereference. · 5dc474d6
      Julia Lawall 提交于
      If session is NULL, it is not possible to access its name field.  So I
      have split apart the printing of the error message to drop the
      printing of the name field in this case.
      
      The macro PRINTK actually only evaluates its arguments starting with
      the third one if the bitwise conjunction of the first two is non-zero.
      Normally, this conjunction would only be non-zero if debugging mode
      were turned on, but when session is NULL, the first argument in both
      the old and new code is -1, and thus the bitwise conjunction is true.
      Perhaps a different strategy is desired, such as using tunnel->debug,
      which session->debug is initialized to, but tunnel can also be NULL,
      so this does not completely solve the problem.
      
      
      This problem was found using the following semantic match
      (http://www.emn.fr/x-info/coccinelle/)
      
      // <smpl>
      @@
      expression E, E1;
      identifier f;
      statement S1,S2,S3;
      @@
      
      * if (E == NULL)
      {
        ... when != if (E == NULL) S1 else S2
            when != E = E1
      * E->f
        ... when any
        return ...;
      }
      else S3
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5dc474d6
  2. 12 5月, 2008 2 次提交
  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
  4. 07 5月, 2008 19 次提交
  5. 06 5月, 2008 1 次提交
  6. 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
  7. 04 5月, 2008 2 次提交
  8. 03 5月, 2008 11 次提交
  9. 02 5月, 2008 1 次提交