Eric Lee / smarc-fsl-linux-kernel

26 Feb, 2009

1 commit

  • a760a6656   crypto: api - Fix module load deadlock with fallback algorithms ... Browse Code »

    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: Herbert Xu

    Herbert Xu
     

19 Feb, 2009

1 commit

17 Feb, 2009

1 commit

  • 8eb2dfac4   crypto: lrw - Fix big endian support ... Browse Code »

    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: Geert Uytterhoeven
    Signed-off-by: Herbert Xu

    Herbert Xu
     

09 Feb, 2009

1 commit

05 Feb, 2009

2 commits

28 Jan, 2009

1 commit

  • b8e15992b   crypto: api - Fix algorithm test race that broke aead initialisation ... Browse Code »

    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: Andreas Steffen
    Signed-off-by: Herbert Xu

    Herbert Xu
     

27 Jan, 2009

2 commits

  • 516280e73   crypto: ccm - Fix handling of null assoc data ... Browse Code »

    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:
    [] :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:[] [] :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:
    [] :ccm:crypto_ccm_auth+0x12d/0x140
    [] :ccm:crypto_ccm_decrypt+0x161/0x23a
    [] :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: Jarod Wilson
    Acked-by: Neil Horman
    Signed-off-by: Herbert Xu

    Jarod Wilson
     
  • bac1b5c46   crypto: blkcipher - Fix WARN_ON handling in walk_done ... Browse Code »

    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: Roel Kluin
    Reported-by: Huang Ying
    Signed-off-by: Herbert Xu

    Herbert Xu
     

15 Jan, 2009

1 commit

  • 29b37f421   crypto: authenc - Fix zero-length IV crash ... Browse Code »

    As it is if an algorithm with a zero-length IV is used (e.g.,
    NULL encryption) with authenc, authenc may generate an SG entry
    of length zero, which will trigger a BUG check in the hash layer.

    This patch fixes it by skipping the IV SG generation if the IV
    size is zero.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

07 Jan, 2009

4 commits

  • 209b84a88   dmaengine: replace dma_async_client_register with dmaengine_get ... Browse Code »

    Now that clients no longer need to be notified of channel arrival
    dma_async_client_register can simply increment the dmaengine_ref_count.

    Reviewed-by: Andrew Morton
    Signed-off-by: Dan Williams

    Dan Williams
     
  • 2ba05622b   dmaengine: provide a common 'issue_pending_all' implementation ... Browse Code »

    async_tx and net_dma each have open-coded versions of issue_pending_all,
    so provide a common routine in dmaengine.

    The implementation needs to walk the global device list, so implement
    rcu to allow dma_issue_pending_all to run lockless. Clients protect
    themselves from channel removal events by holding a dmaengine reference.

    Reviewed-by: Andrew Morton
    Signed-off-by: Dan Williams

    Dan Williams
     
  • bec085134   dmaengine: centralize channel allocation, introduce dma_find_channel ... Browse Code »

    Allowing multiple clients to each define their own channel allocation
    scheme quickly leads to a pathological situation. For memory-to-memory
    offload all clients can share a central allocator.

    This simply moves the existing async_tx allocator to dmaengine with
    minimal fixups:
    * async_tx.c:get_chan_ref_by_cap --> dmaengine.c:nth_chan
    * async_tx.c:async_tx_rebalance --> dmaengine.c:dma_channel_rebalance
    * split out common code from async_tx.c:__async_tx_find_channel -->
    dma_find_channel

    Reviewed-by: Andrew Morton
    Signed-off-by: Dan Williams

    Dan Williams
     
  • 6f49a57aa   dmaengine: up-level reference counting to the module level ... Browse Code »

    Simply, if a client wants any dmaengine channel then prevent all dmaengine
    modules from being removed. Once the clients are done re-enable module
    removal.

    Why?, beyond reducing complication:
    1/ Tracking reference counts per-transaction in an efficient manner, as
    is currently done, requires a complicated scheme to avoid cache-line
    bouncing effects.
    2/ Per-transaction ref-counting gives the false impression that a
    dma-driver can be gracefully removed ahead of its user (net, md, or
    dma-slave)
    3/ None of the in-tree dma-drivers talk to hot pluggable hardware, but
    if such an engine were built one day we still would not need to notify
    clients of remove events. The driver can simply return NULL to a
    ->prep() request, something that is much easier for a client to handle.

    Reviewed-by: Andrew Morton
    Acked-by: Maciej Sosnowski
    Signed-off-by: Dan Williams

    Dan Williams
     

06 Jan, 2009

1 commit

  • 07f2211e4   dmaengine: remove dependency on async_tx ... Browse Code »

    async_tx.ko is a consumer of dma channels. A circular dependency arises
    if modules in drivers/dma rely on common code in async_tx.ko. It
    prevents either module from being unloaded.

    Move dma_wait_for_async_tx and async_tx_run_dependencies to dmaeninge.o
    where they should have been from the beginning.

    Reviewed-by: Andrew Morton
    Signed-off-by: Dan Williams

    Dan Williams
     

25 Dec, 2008

25 commits