1. 29 9月, 2006 2 次提交
  2. 23 9月, 2006 2 次提交
  3. 26 7月, 2006 1 次提交
  4. 18 6月, 2006 1 次提交
  5. 21 3月, 2006 2 次提交
  6. 19 1月, 2006 1 次提交
    • A
      [PATCH] EDAC: atomic scrub operations · 715b49ef
      Alan Cox 提交于
      EDAC requires a way to scrub memory if an ECC error is found and the chipset
      does not do the work automatically.  That means rewriting memory locations
      atomically with respect to all CPUs _and_ bus masters.  That means we can't
      use atomic_add(foo, 0) as it gets optimised for non-SMP
      
      This adds a function to include/asm-foo/atomic.h for the platforms currently
      supported which implements a scrub of a mapped block.
      
      It also adjusts a few other files include order where atomic.h is included
      before types.h as this now causes an error as atomic_scrub uses u32.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      715b49ef
  7. 08 1月, 2006 1 次提交
  8. 20 9月, 2005 1 次提交
    • M
      [PATCH] raw_sendmsg DoS on 2.6 · 6d1cfe3f
      Mark J Cox 提交于
      Fix unchecked __get_user that could be tricked into generating a
      memory read on an arbitrary address.  The result of the read is not
      returned directly but you may be able to divine some information about
      it, or use the read to cause a crash on some architectures by reading
      hardware state.  CAN-2004-2492.
      
      Fix from Al Viro, ack from Dave Miller.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6d1cfe3f
  9. 30 8月, 2005 2 次提交
  10. 19 6月, 2005 5 次提交
    • J
      [IPV4]: [4/4] signed vs unsigned cleanup in net/ipv4/raw.c · f7d7fc03
      Jesper Juhl 提交于
      This patch changes the type of the third parameter 'length' of the 
      raw_send_hdrinc() function from 'int' to 'size_t'.
      This makes sense since this function is only ever called from one 
      location, and the value passed as the third parameter in that location is 
      itself of type size_t, so this makes the recieving functions parameter 
      type match. Also, inside raw_send_hdrinc() the 'length' variable is 
      used in comparisons with unsigned values and passed as parameter to 
      functions expecting unsigned values (it's used in a single comparison with 
      a signed value, but that one can never actually be negative so the patch 
      also casts that one to size_t to stop gcc worrying, and it is passed in a 
      single instance to memcpy_fromiovecend() which expects a signed int, but 
      as far as I can see that's not a problem since the value of 'length' 
      shouldn't ever exceed the value of a signed int).
      Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f7d7fc03
    • J
      [IPV4]: [3/4] signed vs unsigned cleanup in net/ipv4/raw.c · 93765d8a
      Jesper Juhl 提交于
      This patch changes the type of the local variable 'i' in 
      raw_probe_proto_opt() from 'int' to 'unsigned int'. The only use of 'i' in 
      this function is as a counter in a for() loop and subsequent index into 
      the msg->msg_iov[] array.
      Since 'i' is compared in a loop to the unsigned variable msg->msg_iovlen 
      gcc -W generates this warning : 
      
      net/ipv4/raw.c:340: warning: comparison between signed and unsigned
      
      Changing 'i' to unsigned silences this warning and is safe since the array 
      index can never be negative anyway, so unsigned int is the logical type to 
      use for 'i' and also enables a larger msg_iov[] array (but I don't know if 
      that will ever matter).
      Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93765d8a
    • J
      [IPV4]: [2/4] signed vs unsigned cleanup in net/ipv4/raw.c · 926d4b81
      Jesper Juhl 提交于
      This patch gets rid of the following gcc -W warning in net/ipv4/raw.c :
      
      net/ipv4/raw.c:387: warning: comparison of unsigned expression < 0 is always false
      
      Since 'len' is of type size_t it is unsigned and can thus never be <0, and 
      since this is obvious from the function declaration just a few lines above 
      I think it's ok to remove the pointless check for len<0.
      Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      926d4b81
    • J
      [IPV4]: [1/4] signed vs unsigned cleanup in net/ipv4/raw.c · 5418c692
      Jesper Juhl 提交于
      This patch silences these two gcc -W warnings in net/ipv4/raw.c :
      
      net/ipv4/raw.c:517: warning: signed and unsigned type in conditional expression
      net/ipv4/raw.c:613: warning: signed and unsigned type in conditional expression
      
      It doesn't change the behaviour of the code, simply writes the conditional 
      expression with plain 'if()' syntax instead of '? :' , but since this 
      breaks it into sepperate statements gcc no longer complains about having 
      both a signed and unsigned value in the same conditional expression.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5418c692
    • H
      [IPV4/IPV6]: Replace spin_lock_irq with spin_lock_bh · e0f9f858
      Herbert Xu 提交于
      In light of my recent patch to net/ipv4/udp.c that replaced the
      spin_lock_irq calls on the receive queue lock with spin_lock_bh,
      here is a similar patch for all other occurences of spin_lock_irq
      on receive/error queue locks in IPv4 and IPv6.
      
      In these stacks, we know that they can only be entered from user
      or softirq context.  Therefore it's safe to disable BH only.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0f9f858
  11. 06 5月, 2005 1 次提交
  12. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4