1. 02 Aug, 2004 18 commits
  2. 01 Aug, 2004 6 commits
  3. 31 Jul, 2004 16 commits
    • James Morris's avatar
      [CRYPTO]: Add i586 optimized AES · 817bbc47
      James Morris authored
      Below is an updated version of patch from Fruhwirth which integrates the 
      Gladman AES code into the crypto API.
      
      I've tried to ensure that this is done as simply as possible: the user 
      gets the asm version by default if it's suitable.
      
      I've also now added the alternate GPL licensing provided by Brian Gladman, 
      and licensed the code as GPL.
      Signed-off-by: default avatarJames Morris <jmorris@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@redhat.com>
      817bbc47
    • Bert Hubert's avatar
      [IPSEC]: Fix UDP decap code. · 8f49b589
      Bert Hubert authored
      The missing break causes the packet to be tested against
      both encapsulation types, one will always fail.
      Signed-off-by: default avatarbert hubert <ahu@ds9a.nl>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@redhat.com>
      8f49b589
    • Herbert Xu's avatar
      [PF_KEY]: spirange should be in host byte order. · 0797db20
      Herbert Xu authored
      I'm looking through the xfrm_alloc_spi stuff and noticed that the
      netlink alloc_spi function takes the range in host order while the
      PFKEY alloc_spi function takes them in network order.
      
      First I thought that I stuffed up since I was the one who changed
      the code in the netlink interface to take them in host order :)
      
      But reading RFC 2367 seems to indicate otherwise.  It says that all
      fields are host order unless specified otherwise.  And the spirange
      fields are not specified to be network order at all.
      
      Looking at the existing PFKEY users:
      
      User Space
      ----------
      Openswan - Doesn't use PFKEY for this.
      Racoon - Puts zeros in there so it doesn't care.  However its test-pfkey
      	 program stores things in host order.
      ISAKMPD - Stores things in host order.
      
      So the conclusion is that we can and should change our PFKEY
      implementation to use host order for these fields.
      
      This patch does exactly that.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@redhat.com>
      0797db20
    • Herbert Xu's avatar
      [IPSEC]: xfrm_alloc_spi always succeeds on non-trivial range · 3860b281
      Herbert Xu authored
      xfrm_alloc_spi will always succeed if minspi < maxspi, even if
      minspi + 1 == maxspi.  If the range is already occupied this
      will obviously lead to breakage.
      
      Of course this is very unlikely to occur in reality due to the
      size of the range.  Although with IPCOMP it might actually happen
      on a very large server.
      
      The fix is obivous.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@redhat.com>
      3860b281
    • Herbert Xu's avatar
      [IPSEC]: Remove redundant check in xfrm_state_add() · 5eb968f9
      Herbert Xu authored
      This is the patch referred to in the netlink_get_spi thread.
      
      I was actually wrong about the reason for this patch though.  Firstly
      it's the SPI check that is redundant and not the find_acq() call.
      And it's redundant because of the find_acq() patch, not because
      of the fact that this is in xfrm_state_add().
      
      Now that find_acq() only returns SAs with SPIs, we don't need to
      check this in xfrm_state_add() anymore.
      
      We do still need the call though to clean up leftover larval states.
      
      Another side-effect of the change is that we can move the existence
      check above find_acq() since find_acq() will never return any SAs
      matching the SPI we're trying to add (It doesn't need to because if
      an SA with a matching SPI existed, it would've been returned by
      state_lookup() already).
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@redhat.com>
      5eb968f9
    • Herbert Xu's avatar
      [IPSEC]: Fix SPI generation by netlink_get_spi() · 94408b14
      Herbert Xu authored
      The issue is that two successive calls to netlink_get_spi is returning
      the same SA.  Since netlink_get_spi is meant to be a creation operation
      this is incorrect.
      
      The netlink_get_spi operation is modelled off the PFKEY SADB_GETSPI
      command which is specified in RFC 2367.  The purpose of SADB_GETSPI
      is to create a new larval SA that can then be filled in by SADB_UPDATE.
      
      Its semantics does not allow two SADB_GETSPI calls to return the same
      SA, even if there is no SADB_UPDATE call in between.
      
      The reason the second netlink_get_spi is returning the same SA is
      because in find_acq(), the code is looking at all larval states as
      opposed to only larval states with an SPI of zero.
      
      Since the only other caller of find_acq() -- xfrm_state_add() intentionally
      ignores all return values with a non-zero SPI, it is safe to not look at
      SAs with non-zero SPIs at all in find_acq().
      
      The following patch does exactly that.
      
      In fact, the find_acq() call in xfrm_state_add() is a remnant from
      the days when we had xfrm_state_replace() instead of xfrm_state_add()
      and xfrm_state_update().  It can now be safely removed.
      
      I'll post a separate patch for that.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@redhat.com>
      94408b14
    • David S. Miller's avatar
      Merge http://linux-mh.bkbits.net/bluetooth-2.6 · 02160d32
      David S. Miller authored
      into nuts.davemloft.net:/disk1/BK/net-2.6
      02160d32
    • Marcel Holtmann's avatar
      [Bluetooth] Fix resetting to default filters · 1317c324
      Marcel Holtmann authored
      The problem is that after a successful connection between the Windows
      Bluetooth stack and the Linux Bluez stack, no packets from the device
      ever reach the PC running Windows XP Service Pack 2. That is, a ping
      from the PC never receives a response, and a ping from BlueZ never
      reaches the PC. Linux packet statistics show that the PC packets are
      received, but all return traffic seems to be routed over the loopback
      interface.
      
      Immediately after creating the BNEP connection with BlueZ, the Windows
      Bluetooth stack sends a BNEP_FILTER_NET_TYPE_SET_MSG with an effective
      length of zero. BlueZ interprets this message to mean that no filter
      ranges should be allowed. The code zeros the first entry in the filter
      list, which is than interpreted as meaning that no ranges of acceptable
      packets are available. This interpretation is wrong and leads to all
      packets being rejected by BNEP.
      
      The Bluetooth BNEP specification clearly states the following:
      
      The length (in octets) of this message is 4+4*N, where N is the number
      of disjoint ranges of Networking protocol types that form the complete
      set. Note that N=0 (empty set) denotes a reset to default filters (if
      any) supported by the remote device.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      1317c324
    • David S. Miller's avatar
      Merge nuts.davemloft.net:/disk1/BK/network-2.6 · d9fde4ea
      David S. Miller authored
      into nuts.davemloft.net:/disk1/BK/net-2.6
      d9fde4ea
    • Marcel Holtmann's avatar
      [Bluetooth] Send HCI_Reset for ISSC USB dongles · c8f53798
      Marcel Holtmann authored
      For the USB dongles from ISSC the first command must be a HCI_Reset,
      because otherwise the inquiry procedures won't work.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c8f53798
    • Linus Torvalds's avatar
      Merge bk://cifs.bkbits.net/linux-2.5cifs · 70a83a8c
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      70a83a8c
    • Alan Cox's avatar
      [PATCH] PATCH: Fix HPT366 crash and support HPT372N · f03a6bbb
      Alan Cox authored
      On a board containing the HPT372N IDE controller the 2.6.x series kernels will
      misbehave. If the HPT372N is set up with the newer PCI identifier it is 
      ignored. If it is set up with the HPT372 identifier then the kernel crashes
      on boot.
      
      This patch is a forward port of my 2.4 driver fixes that have been in 2.4
      for a year but somehow escaped 2.6. Ronny Buchmann caught a couple
      of merge details I missed and those are fixed in this diff too.
      
      As well as adding 372N support this also fixes the unknown revision case
      to avoid crashes should any future 37x variants with weird class_rev's appear
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f03a6bbb
    • Steve French's avatar
      Merge bk://linux.bkbits.net/linux-2.5 · 62401684
      Steve French authored
      into hostme.bitkeeper.com:/repos/c/cifs/linux-2.5cifs
      62401684
    • Steve French's avatar
      [CIFS] Update readme and todo lists for cifs vfs · 34c044fa
      Steve French authored
      Signed-off-by: Steve French (sfrench@us.ibm.com)
      34c044fa
    • Andrew Morton's avatar
      [PATCH] slab memory shrinking balancing fix · ed158dc1
      Andrew Morton authored
      The logic in shrink_slab tries to balance the proportion of slab which it
      scans against the proportion of pagecache which the caller scanned.  Problem
      is that with a large number of highmem LRU pages and a small number of lowmem
      LRU pages, the amount of pagecache scanning appears to be very small, so we
      don't push slab hard enough.
      
      The patch changes things so that for, say, a GFP_KERNEL allocation attempt we
      only consider ZONE_NORMAL and ZONE_DMA when calculating "what proportion of
      the LRU did the caller just scan".
      
      This will have the effect of shrinking slab harder in response to GFP_KERNEL
      allocations than for GFP_HIGHMEM allocations.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ed158dc1
    • Tom Rini's avatar
      [PATCH] ppc32: fix compilation with binutils-2.15 · f44ba7d6
      Tom Rini authored
      Currently, ppc32 will not always compile with binutils-2.15.  The issue
      is that binutils has become even more strict about which opcodes can be
      used with which CPU flags.  The problem is that we have a number of
      cases where we compile with altivec instructions (with runtime checks to
      make sure we can actually run them) in code that's not altivec specific.
      
      The fix for this is to always pass in -maltivec on CONFIG_6xx.  To do
      this cleanly, we split our AFLAGS definition up into
      aflags-$(CONFIG_FOO).
      Signed-off-by: default avatarTom Rini <trini@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f44ba7d6