Re: [PATCH v2 01/11] crypto: introduce crypto wait for async op
On Sat, Jun 10, 2017 at 6:43 AM, Herbert Xu wrote:
> On Mon, May 29, 2017 at 11:22:48AM +0300, Gilad Ben-Yossef wrote:
>>
>> +static inline int crypto_wait_req(int err, struct crypto_wait *wait)
>> +{
>> + switch (err) {
>> + case -EINPROGRESS:
>> + case -EBUSY:
>> + wait_for_completion(&wait->completion);
>> + reinit_completion(&wait->completion);
>> + err = wait->err;
>> + break;
>> + };
>> +
>> + return err;
>> +}
>
> This assumes that the request is used with backlog. For non-backlog
> requests this would result in a memory leak as EBUSY in that case is
> a fatal error.
>
> So this API can't be used without backlog.
You are right, of course. I did not take that into account.
>
> We could introduce a flag to indicate whether we want backlog or not,
> or maybe we should change our API so that in the non-backlog case we
> return something other than EBUSY.
>
> Opinions?
I guess there is a question if it really is important to know that
your request ended up
on the backlog, rather than being handled.I can imagine it can be used
as back pressure
indication but I wonder if someone is using that.
If not, maybe we can simplify things and use EINPROGRESS asindication
of a request
being accepted by the next layer (either being processed or queued in
the back log), whereas
EBUSY would indicate failure.
It does have a potential to make things simpler, I think.
Gilad
>
> Thanks,
> --
> Email: Herbert Xu
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] crypto: introduce crypto wait for async op
On Sat, Jun 10, 2017 at 11:05:39AM +0300, Gilad Ben-Yossef wrote: > > I guess there is a question if it really is important to know that > your request ended up > on the backlog, rather than being handled.I can imagine it can be used > as back pressure > indication but I wonder if someone is using that. Oh yes we do want it to return EBUSY if we put it on the backlog because in that case we want the user to stop sending us new requests. It's the other case where we dropped the request and returned EBUSY where I think we could return something other than EBUSY and get rid of the ambiguity. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 09/34] x86/mm: Simplify p[gum]d_page() macros
On Wed, Jun 07, 2017 at 02:14:45PM -0500, Tom Lendacky wrote: > Create a pgd_pfn() macro similar to the p[um]d_pfn() macros and then > use the p[gum]d_pfn() macros in the p[gum]d_page() macros instead of > duplicating the code. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/pgtable.h | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) For patches 7-9: Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 13/34] x86/mm: Add support for early encrypt/decrypt of memory
On Wed, Jun 07, 2017 at 02:15:27PM -0500, Tom Lendacky wrote: > Add support to be able to either encrypt or decrypt data in place during > the early stages of booting the kernel. This does not change the memory > encryption attribute - it is used for ensuring that data present in either > an encrypted or decrypted memory area is in the proper state (for example > the initrd will have been loaded by the boot loader and will not be > encrypted, but the memory that it resides in is marked as encrypted). > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/mem_encrypt.h | 15 +++ > arch/x86/mm/mem_encrypt.c | 76 > > 2 files changed, 91 insertions(+) Patches 11-13: Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 14/34] x86/mm: Insure that boot memory areas are mapped properly
On Wed, Jun 07, 2017 at 02:15:39PM -0500, Tom Lendacky wrote:
> The boot data and command line data are present in memory in a decrypted
> state and are copied early in the boot process. The early page fault
> support will map these areas as encrypted, so before attempting to copy
> them, add decrypted mappings so the data is accessed properly when copied.
>
> For the initrd, encrypt this data in place. Since the future mapping of the
> initrd area will be mapped as encrypted the data will be accessed properly.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/mem_encrypt.h | 11 +
> arch/x86/include/asm/pgtable.h |3 +
> arch/x86/kernel/head64.c | 30 --
> arch/x86/kernel/setup.c|9
> arch/x86/mm/mem_encrypt.c | 77
>
> 5 files changed, 126 insertions(+), 4 deletions(-)
Some cleanups ontop in case you get to send v7:
diff --git a/arch/x86/include/asm/mem_encrypt.h
b/arch/x86/include/asm/mem_encrypt.h
index 61a704945294..5959a42dd4d5 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -45,13 +45,8 @@ static inline void __init sme_early_decrypt(resource_size_t
paddr,
{
}
-static inline void __init sme_map_bootdata(char *real_mode_data)
-{
-}
-
-static inline void __init sme_unmap_bootdata(char *real_mode_data)
-{
-}
+static inline void __init sme_map_bootdata(char *real_mode_data) { }
+static inline void __init sme_unmap_bootdata(char *real_mode_data) { }
static inline void __init sme_early_init(void)
{
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 2321f05045e5..32ebbe0ab04d 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -132,6 +132,10 @@ static void __init __sme_map_unmap_bootdata(char
*real_mode_data, bool map)
struct boot_params *boot_data;
unsigned long cmdline_paddr;
+ /* If SME is not active, the bootdata is in the correct state */
+ if (!sme_active())
+ return;
+
__sme_early_map_unmap_mem(real_mode_data, sizeof(boot_params), map);
boot_data = (struct boot_params *)real_mode_data;
@@ -142,40 +146,22 @@ static void __init __sme_map_unmap_bootdata(char
*real_mode_data, bool map)
cmdline_paddr = boot_data->hdr.cmd_line_ptr |
((u64)boot_data->ext_cmd_line_ptr << 32);
- if (cmdline_paddr)
- __sme_early_map_unmap_mem(__va(cmdline_paddr),
- COMMAND_LINE_SIZE, map);
+ if (!cmdline_paddr)
+ return;
+
+ __sme_early_map_unmap_mem(__va(cmdline_paddr), COMMAND_LINE_SIZE, map);
+
+ sme_early_pgtable_flush();
}
void __init sme_unmap_bootdata(char *real_mode_data)
{
- /* If SME is not active, the bootdata is in the correct state */
- if (!sme_active())
- return;
-
- /*
-* The bootdata and command line aren't needed anymore so clear
-* any mapping of them.
-*/
__sme_map_unmap_bootdata(real_mode_data, false);
-
- sme_early_pgtable_flush();
}
void __init sme_map_bootdata(char *real_mode_data)
{
- /* If SME is not active, the bootdata is in the correct state */
- if (!sme_active())
- return;
-
- /*
-* The bootdata and command line will not be encrypted, so they
-* need to be mapped as decrypted memory so they can be copied
-* properly.
-*/
__sme_map_unmap_bootdata(real_mode_data, true);
-
- sme_early_pgtable_flush();
}
void __init sme_early_init(void)
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
