linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@sgi.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Nicolas Ferre <nicolas.ferre@rfo.atmel.com>,
	ARM Linux Mailing List  <linux-arm-kernel@lists.arm.linux.org.uk>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Marc Pignat <marc.pignat@hevs.ch>,
	Andrew Victor <andrew@sanpeople.com>,
	Pierre Ossman <drzeus@drzeus.cx>,
	Andrew Morton <akpm@linux-foundation.org>,
	Russell King <rmk@arm.linux.org.uk>
Subject: Re: Oops in a driver while using SLUB as a SLAB allocator
Date: Fri, 22 Jun 2007 11:51:02 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0706221143190.17958@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0706221931370.4699@blonde.wat.veritas.com>

On Fri, 22 Jun 2007, Hugh Dickins wrote:

> I'm quite happy with this approach for 2.6.23-rc, along with your ARM
> dma_map patch which (if I understood aright) rmk approved.  Except,
> haven't you misplaced that VM_BUG_ON between an if and its else?

Right.

> And I'd much prefer you to make it an outright BUG_ON, because
> many testers have those VM_BUG_ONs configured out.

Thought about it but doing so would create quite a load of BUG_ONs in the 
VM given the frequent use of that particular inline function. And AFAIK
we are only aware of one other potential call site that could cause 
trouble. Many arches have run SLUB now for awhile and would certainly have 
shown issues if they would do strange things with slab allocs. Even with 
SLAB they would have to be very careful in order to make this work. So I 
think its rather unlikely that this is going to be triggered. Its 
primarily useful for debugging if strange things start to happen.
The VM_BUG_ON could stay there for good to make sure development does not
result in similar issues in the future.

Fixed up patch:




Add VM_BUG_ON in case someone uses page_mapping on a slab page

Detect slab objects being passed to the page oriented functions of the VM.

It is not sufficient to simply return NULL because the functions calling
page_mapping may depend on other items of the page_struct also to be setup
properly. Moreover slab object may not be properly aligned. The page oriented
functions of the VM expect to operate on page aligned, page sized objects.
Operations on object straddling page boundaries may only affect the objects
partially which may lead to surprising results.

It is better to detect eventually remaining uses and eliminate them.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

---
 include/linux/mm.h |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

Index: linux-2.6/include/linux/mm.h
===================================================================
--- linux-2.6.orig/include/linux/mm.h	2007-06-22 10:33:27.000000000 -0700
+++ linux-2.6/include/linux/mm.h	2007-06-22 11:44:10.000000000 -0700
@@ -601,12 +601,9 @@ static inline struct address_space *page
 {
 	struct address_space *mapping = page->mapping;
 
+	VM_BUG_ON(PageSlab(page));
 	if (unlikely(PageSwapCache(page)))
 		mapping = &swapper_space;
-#ifdef CONFIG_SLUB
-	else if (unlikely(PageSlab(page)))
-		mapping = NULL;
-#endif
 	else if (unlikely((unsigned long)mapping & PAGE_MAPPING_ANON))
 		mapping = NULL;
 	return mapping;

  reply	other threads:[~2007-06-22 18:51 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-21  9:30 Oops in a driver while using SLUB as a SLAB allocator Nicolas Ferre
2007-06-21 14:54 ` Marc Pignat
2007-06-21 14:57 ` Marc Pignat
2007-06-21 15:54   ` Nicolas Ferre
2007-06-22  6:28     ` [PATCH] mmc-atmel : fix kunmap wrong usage Marc Pignat
2007-06-22 12:00       ` Hugh Dickins
2007-06-22 13:34         ` Nicolas Ferre
2007-06-22 13:46           ` Hugh Dickins
2007-06-22 14:21           ` Marc Pignat
2007-06-22 14:58           ` Marc Pignat
2007-06-22 19:00       ` Jens Axboe
2007-06-22  9:09     ` Oops in a driver while using SLUB as a SLAB allocator Nicolas Ferre
2007-06-21 22:27 ` Hugh Dickins
2007-06-22  1:01   ` Christoph Lameter
2007-06-22  4:26     ` Hugh Dickins
2007-06-22  5:13       ` Christoph Lameter
2007-06-22  7:00       ` Russell King
2007-06-22  1:36   ` Christoph Lameter
2007-06-22  4:40     ` Hugh Dickins
2007-06-22  5:10       ` Christoph Lameter
2007-06-22  5:37         ` Hugh Dickins
2007-06-22 16:40       ` Linus Torvalds
2007-06-22 17:26         ` Christoph Lameter
2007-06-22 17:41         ` Christoph Lameter
2007-06-22 18:39           ` Hugh Dickins
2007-06-22 18:51             ` Christoph Lameter [this message]
2007-06-22 19:01               ` Hugh Dickins
2007-06-22 19:11                 ` Christoph Lameter
2007-06-22 20:21                   ` Hugh Dickins
2007-06-22 22:54                     ` Christoph Lameter
2007-06-22 20:15                 ` Christoph Lameter
2007-06-23 10:40                   ` Oleg Verych
2007-06-24  8:38             ` Russell King
2007-06-24 10:24               ` Hugh Dickins
2007-06-24 10:51                 ` Russell King
2007-06-25  0:25                   ` Hugh Dickins
2007-06-25 13:55                     ` Nicolas Ferre
2007-06-25 14:07                     ` Christoph Lameter
2007-06-25 16:42                       ` Hugh Dickins
2007-06-25 17:00                         ` Christoph Lameter
2007-06-25 17:23                           ` Hugh Dickins
2007-06-25 18:23                             ` Christoph Lameter
2007-06-25 18:43                               ` Hugh Dickins
2007-06-25 18:50                                 ` Christoph Lameter
2007-06-25 19:04                                   ` Hugh Dickins
2007-06-26 18:09                                     ` Christoph Lameter
2007-06-22 20:18         ` Russell King
2007-06-22  1:41   ` Christoph Lameter
2007-06-22  4:46     ` Hugh Dickins
2007-06-22  5:31       ` Christoph Lameter

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=Pine.LNX.4.64.0706221143190.17958@schroedinger.engr.sgi.com \
    --to=clameter@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew@sanpeople.com \
    --cc=drzeus@drzeus.cx \
    --cc=hugh@veritas.com \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.pignat@hevs.ch \
    --cc=nicolas.ferre@rfo.atmel.com \
    --cc=rmk@arm.linux.org.uk \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).