1. 21 5月, 2005 20 次提交
  2. 20 5月, 2005 17 次提交
  3. 19 5月, 2005 3 次提交
    • L
      [PATCH] prevent NULL mmap in topdown model · 49a43876
      Linus Torvalds 提交于
      Prevent the topdown allocator from allocating mmap areas all the way
      down to address zero.
      
      We still allow a MAP_FIXED mapping of page 0 (needed for various things,
      ranging from Wine and DOSEMU to people who want to allow speculative
      loads off a NULL pointer).
      
      Tested by Chris Wright.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      49a43876
    • H
      [IPV4/IPV6] Ensure all frag_list members have NULL sk · 2fdba6b0
      Herbert Xu 提交于
      Having frag_list members which holds wmem of an sk leads to nightmares
      with partially cloned frag skb's.  The reason is that once you unleash
      a skb with a frag_list that has individual sk ownerships into the stack
      you can never undo those ownerships safely as they may have been cloned
      by things like netfilter.  Since we have to undo them in order to make
      skb_linearize happy this approach leads to a dead-end.
      
      So let's go the other way and make this an invariant:
      
      	For any skb on a frag_list, skb->sk must be NULL.
      
      That is, the socket ownership always belongs to the head skb.
      It turns out that the implementation is actually pretty simple.
      
      The above invariant is actually violated in the following patch
      for a short duration inside ip_fragment.  This is OK because the
      offending frag_list member is either destroyed at the end of the
      slow path without being sent anywhere, or it is detached from
      the frag_list before being sent.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2fdba6b0
    • E
      [XFRM]: skb_cow_data() does not set proper owner for new skbs. · d4810200
      Evgeniy Polyakov 提交于
      It looks like skb_cow_data() does not set 
      proper owner for newly created skb.
      
      If we have several fragments for skb and some of them
      are shared(?) or cloned (like in async IPsec) there 
      might be a situation when we require recreating skb and 
      thus using skb_copy() for it.
      Newly created skb has neither a destructor nor a socket
      assotiated with it, which must be copied from the old skb.
      As far as I can see, current code sets destructor and socket
      for the first one skb only and uses truesize of the first skb
      only to increment sk_wmem_alloc value.
      
      If above "analysis" is correct then attached patch fixes that.
      Signed-off-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d4810200