On Tue, 1 May 2018, Andrew Morton wrote:
> On Tue, 24 Apr 2018 12:33:01 -0400 (EDT) Mikulas Patocka
> wrote:
>
> >
> >
> > On Tue, 24 Apr 2018, Michal Hocko wrote:
> >
> > > On Tue 24-04-18 11:30:40, Mikulas Patocka wrote:
> > > >
> > > >
> > > > On Tue, 24 Apr
On Tue, 24 Apr 2018 12:33:01 -0400 (EDT) Mikulas Patocka
wrote:
>
>
> On Tue, 24 Apr 2018, Michal Hocko wrote:
>
> > On Tue 24-04-18 11:30:40, Mikulas Patocka wrote:
> > >
> > >
> > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > >
> > > > On Mon 23-04-18 20:25:15,
On Tue 24-04-18 10:12:42, Michal Hocko wrote:
> On Tue 24-04-18 11:30:40, Mikulas Patocka wrote:
> >
> >
> > On Tue, 24 Apr 2018, Michal Hocko wrote:
> >
> > > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:
> > >
> > > > Fixing __vmalloc code
> > > > is easy and it doesn't require
On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:
>
>
> On Mon, 23 Apr 2018, Michal Hocko wrote:
>
> > On Mon 23-04-18 10:06:08, Mikulas Patocka wrote:
> >
> > > > > He didn't want to fix vmalloc(GFP_NOIO)
> > > >
> > > > I don't remember that conversation, so I don't know whether I agree with
On Fri, Apr 20, 2018 at 08:20:23AM -0400, Mikulas Patocka wrote:
>
>
> On Fri, 20 Apr 2018, Matthew Wilcox wrote:
>
> > On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote:
> > > Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then
> > > uses DMA-API on the returned
On Mon, 23 Apr 2018, Michal Hocko wrote:
> On Mon 23-04-18 10:06:08, Mikulas Patocka wrote:
>
> > > > He didn't want to fix vmalloc(GFP_NOIO)
> > >
> > > I don't remember that conversation, so I don't know whether I agree with
> > > his reasoning or not. But we are supposed to be moving away
On Mon, 23 Apr 2018, Michal Hocko wrote:
> On Mon 23-04-18 10:24:02, Mikulas Patocka wrote:
>
> > > Really, we have a fault injection framework and this sounds like
> > > something to hook in there.
> >
> > The testing people won't set it up. They install the "kernel-debug"
> > package and
On Mon 23-04-18 10:06:08, Mikulas Patocka wrote:
>
>
> On Sat, 21 Apr 2018, Matthew Wilcox wrote:
>
> > On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote:
> > > On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> > > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote:
> >
On Mon 23-04-18 10:24:02, Mikulas Patocka wrote:
[...]
I am not going to comment on your continuous accusations. We can discuss
patches but general rants make very limited sense.
> > > > I already said that we can change it from CONFIG_DEBUG_VM to
> > > > CONFIG_DEBUG_SG - or to whatever other
On Sun, 22 Apr 2018, Michal Hocko wrote:
> On Sat 21-04-18 07:47:57, Matthew Wilcox wrote:
>
> > > He didn't want to fix vmalloc(GFP_NOIO)
> >
> > I don't remember that conversation, so I don't know whether I agree with
> > his reasoning or not. But we are supposed to be moving away from
On Sat, 21 Apr 2018, Matthew Wilcox wrote:
> On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote:
> > On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote:
> > > > On Fri, 20 Apr 2018, Michal Hocko wrote:
> > > > > No way.
On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote:
> Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then
> uses DMA-API on the returned memory or frees it with kfree. Such bugs were
> found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific
> code.
On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote:
> On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote:
> > > On Fri, 20 Apr 2018, Michal Hocko wrote:
> > > > No way. This is just wrong! First of all, you will explode most
On Fri, Apr 20, 2018 at 03:08:52PM +0200, Michal Hocko wrote:
> > In order to detect these bugs reliably I submit this patch that changes
> > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on.
>
> No way. This is just wrong! First of all, you will explode most likely
> on many
On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote:
> On Fri, 20 Apr 2018, Michal Hocko wrote:
> > No way. This is just wrong! First of all, you will explode most likely
> > on many allocations of small sizes. Second, CONFIG_DEBUG_VM tends to be
> > enabled quite often.
>
> You're an
On Sat 21-04-18 07:47:57, Matthew Wilcox wrote:
> On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote:
> > On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote:
> > > > On Fri, 20 Apr 2018, Michal Hocko wrote:
> > > > > No
On Fri, 20 Apr 2018, Michal Hocko wrote:
> On Fri 20-04-18 06:41:36, Matthew Wilcox wrote:
> > On Fri, Apr 20, 2018 at 03:08:52PM +0200, Michal Hocko wrote:
> > > > In order to detect these bugs reliably I submit this patch that changes
> > > > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM
On Fri, 20 Apr 2018, Michal Hocko wrote:
> On Thu 19-04-18 12:12:38, Mikulas Patocka wrote:
> [...]
> > From: Mikulas Patocka
> > Subject: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
> >
> > The kvmalloc function tries to use kmalloc and falls back to vmalloc
On Fri 20-04-18 06:41:36, Matthew Wilcox wrote:
> On Fri, Apr 20, 2018 at 03:08:52PM +0200, Michal Hocko wrote:
> > > In order to detect these bugs reliably I submit this patch that changes
> > > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on.
> >
> > No way. This is just wrong!
On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote:
> > Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then
> > uses DMA-API on the returned memory or frees it with kfree. Such bugs were
> > found in the virtio-net
On Thu, 19 Apr 2018, Andrew Morton wrote:
> On Thu, 19 Apr 2018 17:19:20 -0400 (EDT) Mikulas Patocka
> wrote:
>
> > > > In order to detect these bugs reliably I submit this patch that changes
> > > > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on.
> > > >
On 04/19/2018 06:12 PM, Mikulas Patocka wrote:
> From: Mikulas Patocka
> Subject: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
>
> The kvmalloc function tries to use kmalloc and falls back to vmalloc if
> kmalloc fails.
>
> Unfortunatelly, some kernel code has
On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote:
>
>
> On Wed, 18 Apr 2018, Mikulas Patocka wrote:
>
> >
> >
> > On Wed, 18 Apr 2018, David Miller wrote:
> >
> > > From: Mikulas Patocka
> > > Date: Wed, 18 Apr 2018 12:44:25 -0400 (EDT)
> > >
> > > > The
On Thu, 19 Apr 2018 17:19:20 -0400 (EDT) Mikulas Patocka
wrote:
> > > In order to detect these bugs reliably I submit this patch that changes
> > > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on.
> > >
> > > ...
> > >
> > > --- linux-2.6.orig/mm/util.c
On Thu, 19 Apr 2018, Andrew Morton wrote:
> On Thu, 19 Apr 2018 12:12:38 -0400 (EDT) Mikulas Patocka
> wrote:
>
> > The kvmalloc function tries to use kmalloc and falls back to vmalloc if
> > kmalloc fails.
> >
> > Unfortunatelly, some kernel code has bugs - it uses
On Thu, 19 Apr 2018 12:12:38 -0400 (EDT) Mikulas Patocka
wrote:
> The kvmalloc function tries to use kmalloc and falls back to vmalloc if
> kmalloc fails.
>
> Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then
> uses DMA-API on the returned memory or
On Thu, 19 Apr 2018, Eric Dumazet wrote:
>
>
> On 04/19/2018 09:12 AM, Mikulas Patocka wrote:
> >
> >
> > These bugs are hard to reproduce because vmalloc falls back to kmalloc
> > only if memory is fragmented.
> >
>
> This sentence is wrong.
>
> because kvmalloc() falls back to
On 04/19/2018 09:12 AM, Mikulas Patocka wrote:
>
>
> These bugs are hard to reproduce because vmalloc falls back to kmalloc
> only if memory is fragmented.
>
This sentence is wrong.
because kvmalloc() falls back to vmalloc() ...
--
dm-devel mailing list
dm-devel@redhat.com
On Wed, 18 Apr 2018, Mikulas Patocka wrote:
>
>
> On Wed, 18 Apr 2018, David Miller wrote:
>
> > From: Mikulas Patocka
> > Date: Wed, 18 Apr 2018 12:44:25 -0400 (EDT)
> >
> > > The structure net_device is followed by arbitrary driver-specific data
> > > (accessible
29 matches
Mail list logo