Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-27 Thread Michal Hocko
On Mon 26-03-18 22:45:31, Ilya Smith wrote: > > > On 26 Mar 2018, at 11:46, Michal Hocko wrote: > > > > On Fri 23-03-18 20:55:49, Ilya Smith wrote: > >> > >>> On 23 Mar 2018, at 15:48, Matthew Wilcox wrote: > >>> > >>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: > Current

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-27 Thread Ilya Smith
> On 27 Mar 2018, at 10:24, Michal Hocko wrote: > > On Mon 26-03-18 22:45:31, Ilya Smith wrote: >> >>> On 26 Mar 2018, at 11:46, Michal Hocko wrote: >>> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote: > On 23 Mar 2018, at 15:48, Matthew Wilcox wrote: > > On Thu, Mar 22, 20

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-27 Thread Michal Hocko
On Tue 27-03-18 16:51:08, Ilya Smith wrote: > > > On 27 Mar 2018, at 10:24, Michal Hocko wrote: > > > > On Mon 26-03-18 22:45:31, Ilya Smith wrote: > >> > >>> On 26 Mar 2018, at 11:46, Michal Hocko wrote: > >>> > >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote: > > > On 23 Mar 2018,

[PATCH 4.4 07/43] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs

2018-03-27 Thread Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Evgeniy Didin commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream. It was found that in IDMAC mode after soft-reset driver switches to PIO mode. That's what happens in case of DTO timeout

[PATCH 4.9 07/67] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs

2018-03-27 Thread Greg Kroah-Hartman
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Evgeniy Didin commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream. It was found that in IDMAC mode after soft-reset driver switches to PIO mode. That's what happens in case of DTO timeout

[PATCH 4.14 021/101] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs

2018-03-27 Thread Greg Kroah-Hartman
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Evgeniy Didin commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream. It was found that in IDMAC mode after soft-reset driver switches to PIO mode. That's what happens in case of DTO timeou

[PATCH 4.15 021/105] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs

2018-03-27 Thread Greg Kroah-Hartman
4.15-stable review patch. If anyone has any objections, please let me know. -- From: Evgeniy Didin commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream. It was found that in IDMAC mode after soft-reset driver switches to PIO mode. That's what happens in case of DTO timeou

dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board.

2018-03-27 Thread Evgeniy Didin
Hello, After commit 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common code") we noticed problems with Ethernet controller on one of our platforms (namely ARC HSDK). I n particular we see that removal of __GFP_ZERO flag in function dma_alloc_attrs() was the culprit because in our

Re: dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board.

2018-03-27 Thread Andy Shevchenko
On Tue, Mar 27, 2018 at 8:12 PM, Evgeniy Didin wrote: > Hello, > > After commit 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common > code") we noticed problems with Ethernet controller on one of our platforms > (namely ARC HSDK). > I > n particular we see that removal of __GFP_ZER

Re: dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board.

2018-03-27 Thread Vineet Gupta
Hi Christoph, Andy On 03/27/2018 11:11 AM, Andy Shevchenko wrote: On Tue, Mar 27, 2018 at 8:12 PM, Evgeniy Didin wrote: Hello, After commit 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common code") we noticed problems with Ethernet controller on one of our platforms (namely A

Re: dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board.

2018-03-27 Thread Alexey Brodkin
Hi Andy, On Tue, 2018-03-27 at 21:11 +0300, Andy Shevchenko wrote: > On Tue, Mar 27, 2018 at 8:12 PM, Evgeniy Didin > wrote: > > Hello, > > > > After commit 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in > > common code") we noticed problems with Ethernet controller on one of our >

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-27 Thread Kees Cook
On Tue, Mar 27, 2018 at 6:51 AM, Ilya Smith wrote: > >> On 27 Mar 2018, at 10:24, Michal Hocko wrote: >> >> On Mon 26-03-18 22:45:31, Ilya Smith wrote: >>> On 26 Mar 2018, at 11:46, Michal Hocko wrote: On Fri 23-03-18 20:55:49, Ilya Smith wrote: > >> On 23 Mar 2018, at 15:

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-27 Thread Matthew Wilcox
On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote: > I agree: pushing this off to libc leaves a lot of things unprotected. > I think this should live in the kernel. The question I have is about > making it maintainable/readable/etc. > > The state-of-the-art for ASLR is moving to finer gran

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-27 Thread Kees Cook
On Tue, Mar 27, 2018 at 4:49 PM, Matthew Wilcox wrote: > On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote: >> I agree: pushing this off to libc leaves a lot of things unprotected. >> I think this should live in the kernel. The question I have is about >> making it maintainable/readable/et

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-27 Thread Rich Felker
On Tue, Mar 27, 2018 at 06:16:35PM -0400, Theodore Y. Ts'o wrote: > On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote: > > > /dev/[u]random is not sufficient? > > > > Using /dev/[u]random makes 3 syscalls - open, read, close. This is a > > performance > > issue. > > You may want to take

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-27 Thread Rich Felker
On Tue, Mar 27, 2018 at 04:49:04PM -0700, Matthew Wilcox wrote: > On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote: > > I agree: pushing this off to libc leaves a lot of things unprotected. > > I think this should live in the kernel. The question I have is about > > making it maintainable/

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-27 Thread Rob Landley
On 03/23/2018 02:06 PM, Matthew Wilcox wrote: > On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote: >> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote: >>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: Current implementation doesn't randomize address retur