1. 04 6月, 2009 3 次提交
    • D
      async_xor: permit callers to pass in a 'dma/page scribble' region · 04ce9ab3
      Dan Williams 提交于
      async_xor() needs space to perform dma and page address conversions.  In
      most cases the code can simply reuse the struct page * array because the
      size of the native pointer matches the size of a dma/page address.  In
      order to support archs where sizeof(dma_addr_t) is larger than
      sizeof(struct page *), or to preserve the input parameters, we utilize a
      memory region passed in by the caller.
      
      Since the code is now prepared to handle the case where it cannot
      perform address conversions on the stack, we no longer need the
      !HIGHMEM64G dependency in drivers/dma/Kconfig.
      
      [ Impact: don't clobber input buffers for address conversions ]
      Reviewed-by: NAndre Noll <maan@systemlinux.org>
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      04ce9ab3
    • D
      async_tx: structify submission arguments, add scribble · a08abd8c
      Dan Williams 提交于
      Prepare the api for the arrival of a new parameter, 'scribble'.  This
      will allow callers to identify scratchpad memory for dma address or page
      address conversions.  As this adds yet another parameter, take this
      opportunity to convert the common submission parameters (flags,
      dependency, callback, and callback argument) into an object that is
      passed by reference.
      
      Also, take this opportunity to fix up the kerneldoc and add notes about
      the relevant ASYNC_TX_* flags for each routine.
      
      [ Impact: moves api pass-by-value parameters to a pass-by-reference struct ]
      Signed-off-by: NAndre Noll <maan@systemlinux.org>
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      a08abd8c
    • D
      async_tx: kill ASYNC_TX_DEP_ACK flag · 88ba2aa5
      Dan Williams 提交于
      In support of inter-channel chaining async_tx utilizes an ack flag to
      gate whether a dependent operation can be chained to another.  While the
      flag is not set the chain can be considered open for appending.  Setting
      the ack flag closes the chain and flags the descriptor for garbage
      collection.  The ASYNC_TX_DEP_ACK flag essentially means "close the
      chain after adding this dependency".  Since each operation can only have
      one child the api now implicitly sets the ack flag at dependency
      submission time.  This removes an unnecessary management burden from
      clients of the api.
      
      [ Impact: clean up and enforce one dependency per operation ]
      Reviewed-by: NAndre Noll <maan@systemlinux.org>
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      88ba2aa5
  2. 09 4月, 2009 1 次提交
  3. 31 3月, 2009 1 次提交
  4. 26 3月, 2009 2 次提交
  5. 26 2月, 2009 1 次提交
    • H
      crypto: api - Fix module load deadlock with fallback algorithms · a760a665
      Herbert Xu 提交于
      With the mandatory algorithm testing at registration, we have
      now created a deadlock with algorithms requiring fallbacks.
      This can happen if the module containing the algorithm requiring
      fallback is loaded first, without the fallback module being loaded
      first.  The system will then try to test the new algorithm, find
      that it needs to load a fallback, and then try to load that.
      
      As both algorithms share the same module alias, it can attempt
      to load the original algorithm again and block indefinitely.
      
      As algorithms requiring fallbacks are a special case, we can fix
      this by giving them a different module alias than the rest.  Then
      it's just a matter of using the right aliases according to what
      algorithms we're trying to find.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      a760a665
  6. 19 2月, 2009 1 次提交
  7. 17 2月, 2009 1 次提交
    • H
      crypto: lrw - Fix big endian support · 8eb2dfac
      Herbert Xu 提交于
      It turns out that LRW has never worked properly on big endian.
      This was never discussed because nobody actually used it that
      way.  In fact, it was only discovered when Geert Uytterhoeven
      loaded it through tcrypt which failed the test on it.
      
      The fix is straightforward, on big endian the to find the nth
      bit we should be grouping them by words instead of bytes.  So
      setbit128_bbe should xor with 128 - BITS_PER_LONG instead of
      128 - BITS_PER_BYTE == 0x78.
      Tested-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      8eb2dfac
  8. 09 2月, 2009 1 次提交
  9. 05 2月, 2009 2 次提交
  10. 28 1月, 2009 1 次提交
    • H
      crypto: api - Fix algorithm test race that broke aead initialisation · b8e15992
      Herbert Xu 提交于
      When we complete a test we'll notify everyone waiting on it, drop
      the mutex, and then remove the test larval (after reacquiring the
      mutex).  If one of the notified parties tries to register another
      algorithm with the same driver name prior to the removal of the
      test larval, they will fail with EEXIST as only one algorithm of
      a given name can be tested at any time.
      
      This broke the initialisation of aead and givcipher algorithms as
      they will register two algorithms with the same driver name, in
      sequence.
      
      This patch fixes the problem by marking the larval as dead before
      we drop the mutex, and also ignoring all dead or dying algorithms
      on the registration path.
      Tested-by: NAndreas Steffen <andreas.steffen@strongswan.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      b8e15992
  11. 27 1月, 2009 2 次提交
    • J
      crypto: ccm - Fix handling of null assoc data · 516280e7
      Jarod Wilson 提交于
      Its a valid use case to have null associated data in a ccm vector, but
      this case isn't being handled properly right now.
      
      The following ccm decryption/verification test vector, using the
      rfc4309 implementation regularly triggers a panic, as will any
      other vector with null assoc data:
      
      * key: ab2f8a74b71cd2b1ff802e487d82f8b9
      * iv: c6fb7d800d13abd8a6b2d8
      * Associated Data: [NULL]
      * Tag Length: 8
      * input: d5e8939fc7892e2b
      
      The resulting panic looks like so:
      
      Unable to handle kernel paging request at ffff810064ddaec0 RIP: 
       [<ffffffff8864c4d7>] :ccm:get_data_to_compute+0x1a6/0x1d6
      PGD 8063 PUD 0 
      Oops: 0002 [1] SMP 
      last sysfs file: /module/libata/version
      CPU 0
      Modules linked in: crypto_tester_kmod(U) seqiv krng ansi_cprng chainiv rng ctr aes_generic aes_x86_64 ccm cryptomgr testmgr_cipher testmgr aead crypto_blkcipher crypto_a
      lgapi des ipv6 xfrm_nalgo crypto_api autofs4 hidp l2cap bluetooth nfs lockd fscache nfs_acl sunrpc ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_
      tcpudp iptable_filter ip_tables x_tables dm_mirror dm_log dm_multipath scsi_dh dm_mod video hwmon backlight sbs i2c_ec button battery asus_acpi acpi_memhotplug ac lp sg 
      snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss joydev snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ide_cd snd_pcm floppy parport_p
      c shpchp e752x_edac snd_timer e1000 i2c_i801 edac_mc snd soundcore snd_page_alloc i2c_core cdrom parport serio_raw pcspkr ata_piix libata sd_mod scsi_mod ext3 jbd uhci_h
      cd ohci_hcd ehci_hcd
      Pid: 12844, comm: crypto-tester Tainted: G      2.6.18-128.el5.fips1 #1
      RIP: 0010:[<ffffffff8864c4d7>]  [<ffffffff8864c4d7>] :ccm:get_data_to_compute+0x1a6/0x1d6
      RSP: 0018:ffff8100134434e8  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff8100104898b0 RCX: ffffffffab6aea10
      RDX: 0000000000000010 RSI: ffff8100104898c0 RDI: ffff810064ddaec0
      RBP: 0000000000000000 R08: ffff8100104898b0 R09: 0000000000000000
      R10: ffff8100103bac84 R11: ffff8100104898b0 R12: ffff810010489858
      R13: ffff8100104898b0 R14: ffff8100103bac00 R15: 0000000000000000
      FS:  00002ab881adfd30(0000) GS:ffffffff803ac000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: ffff810064ddaec0 CR3: 0000000012a88000 CR4: 00000000000006e0
      Process crypto-tester (pid: 12844, threadinfo ffff810013442000, task ffff81003d165860)
      Stack:  ffff8100103bac00 ffff8100104898e8 ffff8100134436f8 ffffffff00000000
       0000000000000000 ffff8100104898b0 0000000000000000 ffff810010489858
       0000000000000000 ffff8100103bac00 ffff8100134436f8 ffffffff8864c634
      Call Trace:
       [<ffffffff8864c634>] :ccm:crypto_ccm_auth+0x12d/0x140
       [<ffffffff8864cf73>] :ccm:crypto_ccm_decrypt+0x161/0x23a
       [<ffffffff88633643>] :crypto_tester_kmod:cavs_test_rfc4309_ccm+0x4a5/0x559
      [...]
      
      The above is from a RHEL5-based kernel, but upstream is susceptible too.
      
      The fix is trivial: in crypto/ccm.c:crypto_ccm_auth(), pctx->ilen contains
      whatever was in memory when pctx was allocated if assoclen is 0. The tested
      fix is to simply add an else clause setting pctx->ilen to 0 for the
      assoclen == 0 case, so that get_data_to_compute() doesn't try doing
      things its not supposed to.
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      516280e7
    • H
      crypto: blkcipher - Fix WARN_ON handling in walk_done · bac1b5c4
      Herbert Xu 提交于
      When we get left-over bits from a slow walk, it means that the
      underlying cipher has gone troppo.  However, as we're handling
      that case we should ensure that the caller terminates the walk.
      
      This patch does this by setting walk->nbytes to zero.
      Reported-by: NRoel Kluin <roel.kluin@gmail.com>
      Reported-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      bac1b5c4
  12. 15 1月, 2009 1 次提交
  13. 07 1月, 2009 4 次提交
  14. 06 1月, 2009 1 次提交
  15. 25 12月, 2008 18 次提交