Re: vmalloced stacks and scatterwalk_map_and_copy()

On Mon, Nov 21, 2016 at 04:26:19PM +0800, Herbert Xu wrote: > crypto: scatterwalk - Remove unnecessary aliasing check in map_and_copy > > The aliasing check in map_and_copy is no longer necessary because > the IPsec ESP code no longer provides an IV that points into the > actual request data. As

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Mon, Nov 21, 2016 at 04:26:19PM +0800, Herbert Xu wrote: > crypto: scatterwalk - Remove unnecessary aliasing check in map_and_copy > > The aliasing check in map_and_copy is no longer necessary because > the IPsec ESP code no longer provides an IV that points into the > actual request data. As

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Sun, Nov 20, 2016 at 06:19:48PM -0800, Andy Lutomirski wrote: > > > Herbert, can you clarify this? The check seems rather bizarre -- > > you're doing an incomplete check for aliasing and skipping the whole > > copy if the beginning aliases. In any event the stack *can't* > > reasonably alias

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Sun, Nov 20, 2016 at 06:19:48PM -0800, Andy Lutomirski wrote: > > > Herbert, can you clarify this? The check seems rather bizarre -- > > you're doing an incomplete check for aliasing and skipping the whole > > copy if the beginning aliases. In any event the stack *can't* > > reasonably alias

Re: vmalloced stacks and scatterwalk_map_and_copy()

[Adding Thorsten to help keep this from getting lost] On Thu, Nov 3, 2016 at 1:30 PM, Andy Lutomirski wrote: > On Thu, Nov 3, 2016 at 11:16 AM, Eric Biggers wrote: >> Hello, >> >> I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto

Re: vmalloced stacks and scatterwalk_map_and_copy()

[Adding Thorsten to help keep this from getting lost] On Thu, Nov 3, 2016 at 1:30 PM, Andy Lutomirski wrote: > On Thu, Nov 3, 2016 at 11:16 AM, Eric Biggers wrote: >> Hello, >> >> I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto >> code >> in an x86_64 kernel with

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 03, 2016 at 08:57:49PM -0700, Andy Lutomirski wrote: > > The crypto request objects can live on the stack just fine. It's the > request buffers that need to live elsewhere (or the alternative > interfaces can be used, or the crypto core code can start using > something other than

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 03, 2016 at 08:57:49PM -0700, Andy Lutomirski wrote: > > The crypto request objects can live on the stack just fine. It's the > request buffers that need to live elsewhere (or the alternative > interfaces can be used, or the crypto core code can start using > something other than

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 3, 2016 at 4:10 PM, Eric Biggers wrote: > On Thu, Nov 03, 2016 at 02:12:07PM -0700, Eric Biggers wrote: >> On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: >> > >> > Also, Herbert, it seems like the considerable majority of the crypto >> > code is

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 3, 2016 at 4:10 PM, Eric Biggers wrote: > On Thu, Nov 03, 2016 at 02:12:07PM -0700, Eric Biggers wrote: >> On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: >> > >> > Also, Herbert, it seems like the considerable majority of the crypto >> > code is acting on kernel

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 03, 2016 at 02:12:07PM -0700, Eric Biggers wrote: > On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: > > > > Also, Herbert, it seems like the considerable majority of the crypto > > code is acting on kernel virtual memory addresses and does software > > processing.

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 03, 2016 at 02:12:07PM -0700, Eric Biggers wrote: > On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: > > > > Also, Herbert, it seems like the considerable majority of the crypto > > code is acting on kernel virtual memory addresses and does software > > processing.

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: > > Also, Herbert, it seems like the considerable majority of the crypto > code is acting on kernel virtual memory addresses and does software > processing. Would it perhaps make sense to add a kvec-based or > iov_iter-based

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: > > Also, Herbert, it seems like the considerable majority of the crypto > code is acting on kernel virtual memory addresses and does software > processing. Would it perhaps make sense to add a kvec-based or > iov_iter-based

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 3, 2016 at 11:16 AM, Eric Biggers wrote: > Hello, > > I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto code > in an x86_64 kernel with CONFIG_DEBUG_VIRTUAL=y and CONFIG_VMAP_STACK=y: > > /* carry flag will be set if starting x was

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 3, 2016 at 11:16 AM, Eric Biggers wrote: > Hello, > > I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto code > in an x86_64 kernel with CONFIG_DEBUG_VIRTUAL=y and CONFIG_VMAP_STACK=y: > > /* carry flag will be set if starting x was >= PAGE_OFFSET */ >

vmalloced stacks and scatterwalk_map_and_copy()

Hello, I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto code in an x86_64 kernel with CONFIG_DEBUG_VIRTUAL=y and CONFIG_VMAP_STACK=y: /* carry flag will be set if starting x was >= PAGE_OFFSET */ VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x)); The

vmalloced stacks and scatterwalk_map_and_copy()

Hello, I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto code in an x86_64 kernel with CONFIG_DEBUG_VIRTUAL=y and CONFIG_VMAP_STACK=y: /* carry flag will be set if starting x was >= PAGE_OFFSET */ VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x)); The