All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>, Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@iki.fi>,
	linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org
Subject: Re: [PATCH] fix crash when using XFS on loopback
Date: Tue, 7 Jan 2014 10:41:59 +0900	[thread overview]
Message-ID: <20140107014159.GA26726@lge.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1401061237120.6190@file01.intranet.prod.int.rdu2.redhat.com>

On Mon, Jan 06, 2014 at 12:54:22PM -0500, Mikulas Patocka wrote:
> Hi
> 
> On Mon, 6 Jan 2014, Joonsoo Kim wrote:
> 
> > Hello,
> > 
> > I'm surprised that this VM_BUG_ON() has not been triggered until now. It was
> > introduced in 2007 by commit (b5fab14). Maybe there is no person who test
> > with CONFIG_DEBUG_VM.
> 
> Last time I tried it, PS-RISC didn't work with CONFIG_DEBUG_VM at all.
> 
> > There is one more bug report same as this.
> > * possible regression on 3.13 when calling flush_dcache_page
> >   (lkml.org/lkml/2013/12/12/255)
> 
> That link doesn't show anything.
> 
> > As mentioned in the description of commit (b5fab14), slab object may not be
> > properly aligned and use of page oriented function to this object can be
> > dangerous. I searched the XFS code and found that they only try to allocate
> > multiple of 512 bytes, so there is no problem for now. But, IMHO, it is better
> > not to use slab objects for this purpose.
> 
> If slab debugging is enabled, kmalloc memory is not aligned.
> 
> In XFS in xfs_buf_allocate_memory they test if the kmalloc memory crosses 
> page boundary - if it does, they free the kmalloc memory and allocate a 
> full page. Maybe this approach could still run into problems with some 
> bus-master adapters that assume alignment in hardware...
> 
> 
> dm-bufio also does I/O to slab-allocated buffers, but it allocates the 
> object from slab (not kmalloc) with proper alignment.

Hello,

Okay. I see.
Thanks for good explanation.

> 
> > And I rapidly searched every callsites of page_mapping() and, IMHO, this 
> > patch would work correctly. But possibly reverting original commit is 
> > better solution.
> 
> Reverting the original commit wouldn't fix that VM_BUG_ON.

Initially, I thought that VM_BUG_ON() isn't wrong and it was better to remove
the callsites where do I/O with slab-allocated buffers, because doing I/O
with slab-allocated buffers needs a great care. So I didn't fully agreed with
your patch and recommended to revert original commit yesterday. After reverting
that, I would attempt to remove the callsites.

But, now, I change my thought, because of your explanation. There are already
some users to do I/O with slab-allocated buffers and they already did it with
some cares, so I guess that admitting this usage is more beneficial than
forbidding it.

Reviewed-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

Thanks.

  reply	other threads:[~2014-01-07  1:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-04 17:45 [PATCH] fix crash when using XFS on loopback Mikulas Patocka
2014-01-04 18:48 ` John David Anglin
2014-01-04 19:55   ` Mikulas Patocka
2014-01-04 20:31     ` John David Anglin
2014-01-04 20:52       ` Mikulas Patocka
2014-01-06  7:35 ` Joonsoo Kim
2014-01-06 17:54   ` Mikulas Patocka
2014-01-07  1:41     ` Joonsoo Kim [this message]
2014-01-08 21:05       ` Helge Deller
2014-01-08 21:37         ` Pekka Enberg
2014-01-08 21:42           ` Helge Deller
2014-01-08 21:59           ` Andrew Morton
2014-01-09  0:13             ` Joonsoo Kim
2014-01-09  0:19               ` Andrew Morton
2014-01-09  8:35                 ` Pekka Enberg
2014-01-09  8:49 ` Simon Baatz
2014-01-09  8:49   ` Simon Baatz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140107014159.GA26726@lge.com \
    --to=iamjoonsoo.kim@lge.com \
    --cc=ak@linux.intel.com \
    --cc=cl@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=penberg@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.