On Thu, 15 Aug 2019 at 08:13, Herbert Xu wrote:
>
> On Thu, Aug 15, 2019 at 07:59:34AM +0300, Ard Biesheuvel wrote:
> >
> > So how do I ensure that the cipher and shash are actually loaded at
> > create() time, and that they are still loaded at TFM init time?
>
> If they're not available at TFM
On Thu, Aug 15, 2019 at 07:59:34AM +0300, Ard Biesheuvel wrote:
>
> So how do I ensure that the cipher and shash are actually loaded at
> create() time, and that they are still loaded at TFM init time?
If they're not available at TFM init then you just fail the init
and therefore the TFM
On Thu, 15 Aug 2019 at 05:37, Herbert Xu wrote:
>
> On Wed, Aug 14, 2019 at 07:37:43PM +0300, Ard Biesheuvel wrote:
> >
> > + /* Block cipher, e.g., "aes" */
> > + crypto_set_spawn(>essiv_cipher_spawn, inst);
> > + err = crypto_grab_spawn(>essiv_cipher_spawn, essiv_cipher_name,
> > +
On Wed, Aug 14, 2019 at 07:37:43PM +0300, Ard Biesheuvel wrote:
>
> + /* Block cipher, e.g., "aes" */
> + crypto_set_spawn(>essiv_cipher_spawn, inst);
> + err = crypto_grab_spawn(>essiv_cipher_spawn, essiv_cipher_name,
> + CRYPTO_ALG_TYPE_CIPHER,
On Sat, Aug 03, 2019 at 10:36:44AM +0300, Ard Biesheuvel wrote:
>
> To use your GCM analogy: gcm_base(ctr-ppc-spe, ghash-generic) is a
> supported aead identifier, but there is nothing in the name that
> identifies the skcipher as one that encapsulates AES.
I would've thought that you would
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> To enable future changes, mp->pgpolicyfn() now takes a vector of
> paths instead of always using mp->paths.
>
> Signed-off-by: Benjamin Marzinski
> ---
> libmultipath/pgpolicies.c | 38 +++
> ---
>
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> store_pathgroup() is only called by add_pathgroup(), and doesn't need
> to
> exist as a seperate function.
>
> Signed-off-by: Benjamin Marzinski
Reviewed-by: Martin Wilck
--
dm-devel mailing list
dm-devel@redhat.com
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> In the pgpolicy functions, if an error is encountered after
> alloc_pathgroup() is called, but before the path group is added to a
> multipath device with add_pathgroup(), the pathgroup needs to be
> cleaned
> up by calling
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> This commit adds a marginal variable ot the paths and pathgroups
> structs.
> The marginal paths variable can be set by
>
> multipathd path setmarginal
>
> and cleared by
>
> multipathd path unsetmarginal
>
> All of the marginal
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> In preparation for changing the path grouping code, add some unit
> tests
> to verify that it works correctly. The only test that currently fails
> (and so it being skipped) is using MULTIBUS when mp->paths is empty.
> All
> the other
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> group_paths() is a wrapper around the pgpolicy functions, that pulls
> out
> the common code from the beginning and the end. However since
> one_group() didn't free the mp->paths vector, it has to set it to
> NULL,
> to avoid having
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> The pgpolicy unit tests now work again, using group_paths().
> test_one_group0(), which was skipped with the old path grouping code
> because it failed, is now working correctly.
>
> Signed-off-by: Benjamin Marzinski
Reviewed-by:
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> group_by_node_name() and group_by_serial() are exactly the same
> except
> for how the paths are compared. group_by_prio() is different but its
> pathvec solves the same issue as the bitmap from the other two
> functions, and since we
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> All the pgpolicy functions besides one_group() allocate a new vector
> for
> the pathgroups. If one_group() works the same, it is easier to factor
> out the common code.
>
> Signed-off-by: Benjamin Marzinski
Reviewed-by: Martin
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> All of the code that uses vector_foreach_slot_backwards() treats "i"
> as
> the index of the entry "p", but the way it was coded, that wasn't the
> case. "i" was the number of the entry counting from 1, not 0.
>
> Signed-off-by:
On Wed, 2019-08-14 at 12:22 -0500, Benjamin Marzinski wrote:
> This adds a print_foreign multipath.conf defaults option, that allows
> users to disable printing foreign devices and paths. It defaults to
> "yes".
>
> Signed-off-by: Benjamin Marzinski
> ---
> libmultipath/config.c | 1 +
>
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> The delay_checks shaky paths detection method works the same way as
> the
> san_path_err method, but not as well, with less configurability, and
> with the code spread all over check_path(). The only real difference
> is
> that marks
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> The pgpolicy unit tests now work again, using group_paths().
> test_one_group0(), which was skipped with the old path grouping code
> because it failed, is now working correctly.
>
> Signed-off-by: Benjamin Marzinski
> ---
>
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> In preparation for changing the path grouping code, add some unit
> tests
> to verify that it works correctly. The only test that currently fails
> (and so it being skipped) is using MULTIBUS when mp->paths is empty.
> All
> the other
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> Add documentation for the marginal_pathgroups option and the
> (un)setmarginal commands.
>
> Signed-off-by: Benjamin Marzinski
> ---
> multipath/multipath.conf.5 | 34 ++
> multipathd/multipathd.8
On Fri, 2019-08-02 at 11:33 -0500, Benjamin Marzinski wrote:
> In the pgpolicy functions, if an error is encountered after
> alloc_pathgroup() is called, but before the path group is added to a
> multipath device with add_pathgroup(), the pathgroup needs to be
> cleaned
> up by calling
Cc: Steve Schremmer
Signed-off-by: Benjamin Marzinski
---
libmultipath/hwtable.c | 8
1 file changed, 8 insertions(+)
diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c
index 96e8b25d..94af153d 100644
--- a/libmultipath/hwtable.c
+++ b/libmultipath/hwtable.c
@@ -780,6
This adds a print_foreign multipath.conf defaults option, that allows
users to disable printing foreign devices and paths. It defaults to
"yes".
Signed-off-by: Benjamin Marzinski
---
libmultipath/config.c | 1 +
libmultipath/config.h | 1 +
libmultipath/defaults.h| 1 +
This series creates an ESSIV template that produces a skcipher or AEAD
transform based on a tuple of the form ',' (or ','
for the AEAD case). It exposes the encapsulated sync or async skcipher/aead by
passing through all operations, while using the cipher/shash pair to transform
the input IV into
Add a test vector for the ESSIV mode that is the most widely used,
i.e., using cbc(aes) and sha256, in both skcipher and AEAD modes
(the latter is used by tcrypt to encapsulate the authenc template
or h/w instantiations of the same)
Signed-off-by: Ard Biesheuvel
---
crypto/tcrypt.c | 9 +
Implement a template that wraps a (skcipher,shash) or (aead,shash) tuple
so that we can consolidate the ESSIV handling in fscrypt and dm-crypt and
move it into the crypto API. This will result in better test coverage, and
will allow future changes to make the bare cipher interface internal to the
The plain CBC driver and the CTS one share some code that iterates over
a scatterwalk and invokes the CBC asm code to do the processing. The
upcoming ESSIV/CBC mode will clone that pattern for the third time, so
let's factor it out first.
Signed-off-by: Ard Biesheuvel
---
Add an accelerated version of the 'essiv(cbc(aes),sha256)' skcipher,
which is used by fscrypt or dm-crypt on systems where CBC mode is
signficantly more performant than XTS mode (e.g., when using a h/w
accelerator which supports the former but not the latter) This avoids
a separate call into the
On Thu, Aug 01, 2019 at 07:21:38PM +0200, Xose Vazquez Perez wrote:
> Otherwise "3303[ ]+NVDISK" is never reached, because "NVDISK" regex takes
> priority over it.
Huh? I don't understand why this is necessary. First off, with Martin's
hwentry code, all matching hardware entries are used, not
On Tue, Aug 13, 2019 at 12:35:49PM -0400, Mikulas Patocka wrote:
>
>
> On Sat, 10 Aug 2019, Dave Chinner wrote:
>
> > No, you misunderstand. I'm talking about blocking kswapd being
> > wrong. i.e. Blocking kswapd in shrinkers causes problems
> > because th ememory reclaim code does not expect
30 matches
Mail list logo
