31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

03 Aug, 2018

1 commit


22 Nov, 2016

1 commit


18 Jul, 2016

6 commits


03 Jun, 2015

1 commit

  • On architectures where flush_dcache_page is not needed, we will
    end up generating all the code up to the PageSlab call. This is
    because PageSlab operates on a volatile pointer and thus cannot
    be optimised away.

    This patch works around this by checking whether flush_dcache_page
    is needed before we call PageSlab which then allows PageSlab to be
    compiled awy.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

28 May, 2015

1 commit


22 May, 2015

2 commits

  • This patch adds a check for in scatterwalk_map_and_copy to avoid
    copying from the same address to the same address. This is going
    to be used for IV copying in AEAD IV generators.

    There is no provision for partial overlaps.

    This patch also uses the new scatterwalk_ffwd instead of doing
    it by hand in scatterwalk_map_and_copy.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • This patch adds the scatterwalk_ffwd helper which can create an
    SG list that starts in the middle of an existing SG list. The
    new list may either be part of the existing list or be a chain
    that latches onto part of the existing list.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

26 Jan, 2015

1 commit


21 Aug, 2013

1 commit


20 Mar, 2012

1 commit


19 May, 2010

1 commit

  • We are done with the scattergather entry when the walk offset goes
    past sg->offset + sg->length, not when it crosses a page boundary.

    There is a similarly queer test in the second half of
    scatterwalk_pagedone() that probably needs some scrutiny.

    Signed-off-by: David S. Miller
    Signed-off-by: Herbert Xu

    David S. Miller
     

09 Feb, 2009

1 commit


11 Jan, 2008

4 commits


23 Oct, 2007

1 commit


16 Oct, 2007

1 commit


11 Oct, 2007

2 commits

  • When scatterwalk is built as a module digest.c was broken because it
    requires the crypto_km_types structure which is in scatterwalk. This
    patch removes the crypto_km_types structure by encoding the logic into
    crypto_kmap_type directly.

    In fact, this even saves a few bytes of code (not to mention the data
    structure itself) on i386 which is about the only place where it's
    needed.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • This patch adds the function scatterwalk_map_and_copy which reads or
    writes a chunk of data from a scatterlist at a given offset. It will
    be used by authenc which would read/write the authentication data at
    the end of the cipher/plain text.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

31 Mar, 2007

2 commits


21 Mar, 2007

1 commit

  • In the loop in scatterwalk_copychunks(), if walk->offset is zero,
    then scatterwalk_pagedone rounds that up to the nearest page boundary:

    walk->offset += PAGE_SIZE - 1;
    walk->offset &= PAGE_MASK;

    which is a no-op in this case, so we don't advance to the next element
    of the scatterlist array:

    if (walk->offset >= walk->sg->offset + walk->sg->length)
    scatterwalk_start(walk, sg_next(walk->sg));

    and we end up copying the same data twice.

    It appears that other callers of scatterwalk_{page}done first advance
    walk->offset, so I believe that's the correct thing to do here.

    This caused a bug in NFS when run with krb5p security, which would
    cause some writes to fail with permissions errors--for example, writes
    of less than 8 bytes (the des blocksize) at the start of a file.

    A git-bisect shows the bug was originally introduced by
    5c64097aa0f6dc4f27718ef47ca9a12538d62860, first in 2.6.19-rc1.

    Signed-off-by: "J. Bruce Fields"
    Signed-off-by: Herbert Xu

    J. Bruce Fields
     

21 Sep, 2006

1 commit

  • This patch prepares the scatterwalk code for use by the new block cipher
    type.

    Firstly it halves the size of scatter_walk on 32-bit platforms. This
    is important as we allocate at least two of these objects on the stack
    for each block cipher operation.

    It also exports the symbols since the block cipher code can be built as
    a module.

    Finally there is a hack in scatterwalk_unmap that relies on progress
    being made. Unfortunately, for hardware crypto we can't guarantee
    progress to be made since the hardware can fail.

    So this also gets rid of the hack by not advancing the address returned
    by scatterwalk_map.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

08 Feb, 2006

1 commit


07 Jul, 2005

1 commit

  • The VIA Padlock device is able to perform much better when multiple
    blocks are fed to it at once. As this device offers an exceptional
    throughput rate it is worthwhile to optimise the infrastructure
    specifically for it.

    We shift the existing page-sized fast path down to the CBC/ECB functions.
    We can then replace the CBC/ECB functions with functions provided by the
    underlying algorithm that performs the multi-block operations.

    As a side-effect this improves the performance of large cipher operations
    for all existing algorithm implementations. I've measured the gain to be
    around 5% for 3DES and 15% for AES.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds