From: Hugh Dickins <hugh@veritas.com>
To: Ryan Richter <ryan@tau.solarneutrino.net>
Cc: Linus Torvalds <torvalds@osdl.org>,
Kai Makisara <Kai.Makisara@kolumbus.fi>,
James Bottomley <James.Bottomley@SteelEye.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Andrew Morton <akpm@osdl.org>, Roland Dreier <rdreier@cisco.com>,
Brian King <brking@us.ibm.com>, Willem Riede <osst@riede.org>,
Doug Gilbert <dougg@torque.net>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: Fw: crash on x86_64 - mm related?
Date: Fri, 3 Feb 2006 19:46:24 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.61.0602031842290.14065@goblin.wat.veritas.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0601181556050.9110@goblin.wat.veritas.com>
On Wed, 18 Jan 2006, Hugh Dickins wrote:
> On Tue, 17 Jan 2006, Ryan Richter wrote:
>
> > This machine experienced another random reboot today, nothing in the
> > logs or on the console etc. This is the 3rd time now since I upgraded
> > from 2.6.11.3. Is there any way to debug something like this?
>
> Nasty. I hope someone else can suggest something constructive.
Are they still happening?
> > I'm fairly certain it's not hardware-related.
> > Might this have something to do with the st problem?
>
> Well, it might: I've not been able to explain that at all, so cannot
> rule out a relation to your reboots.
If no "Bad page state" has occurred earlier, we can now be sure that
these reboots are (unfortunately) unrelated to the st problem.
> The st problem (Bad page state,
> mapcount 2 while count 0, from sgl_unmap_user_pages) ought to be a lot
> easier to debug than a random reboot: but I've still no suggestion.
I guessed it last week, Ryan verified that booting with "iommu=nomerge"
worked around it, and then that the 2.6.15 patch below fixes it.
On some architectures (alpha, ia64, parisc, powerpc, sparc64, x86_64,
more?) in some configurations, dma_map_sg or pci_map_sg may coalesce
scatterlist entries, copying later entries down: bad news if we then
go on to use that coalesced scatterlist to free the pages afterwards -
we're quite liable to free the same page twice.
James' DMA-API.txt is perfectly clear that "The mapping process is
allowed to destroy information in the sg". I wonder that this hasn't
been noticed before. Perhaps we should have a debug option to destroy
everything in the scatterlist when unmapping.
The st code has moved on a little since 2.6.15, I'll send the 2.6.16-rc2
patch to Kai and lists in reply to this mail. I've looked around for
similar culprits - fewer than I was expecting, but I'm not sure if
I've found them all:
drivers/infiniband/core/uverbs_mem.c
drivers/scsi/ipr.c
drivers/scsi/osst.c
drivers/scsi/sg.c
I'll reply with _untested_ patches to the maintainers and list for
those too. Except for sg.c, which I'll send privately to Doug -
I've wasted a lot of time not quite understanding it, and don't
want to expose my ignorance in public.
Hugh
--- 2.6.15/drivers/scsi/st.c 2006-01-03 03:21:10.000000000 +0000
+++ linux/drivers/scsi/st.c 2006-01-29 17:21:47.000000000 +0000
@@ -188,11 +188,11 @@ static int from_buffer(struct st_buffer
static void move_buffer_data(struct st_buffer *, int);
static void buf_to_sg(struct st_buffer *, unsigned int);
-static int st_map_user_pages(struct scatterlist *, const unsigned int,
+static int st_map_user_pages(struct st_buffer *, const unsigned int,
unsigned long, size_t, int, unsigned long);
-static int sgl_map_user_pages(struct scatterlist *, const unsigned int,
+static int sgl_map_user_pages(struct st_buffer *, const unsigned int,
unsigned long, size_t, int);
-static int sgl_unmap_user_pages(struct scatterlist *, const unsigned int, int);
+static int sgl_unmap_user_pages(struct st_buffer *, const unsigned int, int);
static int st_probe(struct device *);
static int st_remove(struct device *);
@@ -1402,7 +1402,7 @@ static int setup_buffering(struct scsi_t
i = STp->try_dio && try_wdio;
if (i && ((unsigned long)buf & queue_dma_alignment(
STp->device->request_queue)) == 0) {
- i = st_map_user_pages(&(STbp->sg[0]), STbp->use_sg,
+ i = st_map_user_pages(STbp, STbp->use_sg,
(unsigned long)buf, count, (is_read ? READ : WRITE),
STp->max_pfn);
if (i > 0) {
@@ -1455,7 +1455,7 @@ static void release_buffering(struct scs
STbp = STp->buffer;
if (STbp->do_dio) {
- sgl_unmap_user_pages(&(STbp->sg[0]), STbp->do_dio, 0);
+ sgl_unmap_user_pages(STbp, STbp->do_dio, 0);
STbp->do_dio = 0;
}
}
@@ -4396,32 +4396,33 @@ static void do_create_class_files(struct
- any page is above max_pfn
(i.e., either completely successful or fails)
*/
-static int st_map_user_pages(struct scatterlist *sgl, const unsigned int max_pages,
+static int st_map_user_pages(struct st_buffer *STbp, const unsigned int max_pages,
unsigned long uaddr, size_t count, int rw,
unsigned long max_pfn)
{
int i, nr_pages;
- nr_pages = sgl_map_user_pages(sgl, max_pages, uaddr, count, rw);
+ nr_pages = sgl_map_user_pages(STbp, max_pages, uaddr, count, rw);
if (nr_pages <= 0)
return nr_pages;
for (i=0; i < nr_pages; i++) {
- if (page_to_pfn(sgl[i].page) > max_pfn)
+ if (page_to_pfn(STbp->sg[i].page) > max_pfn)
goto out_unmap;
}
return nr_pages;
out_unmap:
- sgl_unmap_user_pages(sgl, nr_pages, 0);
+ sgl_unmap_user_pages(STbp, nr_pages, 0);
return 0;
}
/* The following functions may be useful for a larger audience. */
-static int sgl_map_user_pages(struct scatterlist *sgl, const unsigned int max_pages,
+static int sgl_map_user_pages(struct st_buffer *STbp, const unsigned int max_pages,
unsigned long uaddr, size_t count, int rw)
{
+ struct scatterlist *sgl = STbp->sg;
unsigned long end = (uaddr + count + PAGE_SIZE - 1) >> PAGE_SHIFT;
unsigned long start = uaddr >> PAGE_SHIFT;
const int nr_pages = end - start;
@@ -4485,7 +4486,7 @@ static int sgl_map_user_pages(struct sca
sgl[0].length = count;
}
- kfree(pages);
+ STbp->sg_pages = pages;
return nr_pages;
out_unmap:
@@ -4500,13 +4501,13 @@ static int sgl_map_user_pages(struct sca
/* And unmap them... */
-static int sgl_unmap_user_pages(struct scatterlist *sgl, const unsigned int nr_pages,
+static int sgl_unmap_user_pages(struct st_buffer *STbp, const unsigned int nr_pages,
int dirtied)
{
int i;
for (i=0; i < nr_pages; i++) {
- struct page *page = sgl[i].page;
+ struct page *page = STbp->sg_pages[i];
if (dirtied)
SetPageDirty(page);
@@ -4516,5 +4517,7 @@ static int sgl_unmap_user_pages(struct s
page_cache_release(page);
}
+ kfree(STbp->sg_pages);
+ STbp->sg_pages = NULL;
return 0;
}
--- 2.6.15/drivers/scsi/st.h 2005-10-28 01:02:08.000000000 +0100
+++ linux/drivers/scsi/st.h 2006-01-29 16:52:02.000000000 +0000
@@ -37,6 +37,7 @@ struct st_buffer {
unsigned short frp_segs; /* number of buffer segments */
unsigned int frp_sg_current; /* driver buffer length currently in s/g list */
struct st_buf_fragment *frp; /* the allocated buffer fragment list */
+ struct page **sg_pages; /* pages to be freed from s/g list */
struct scatterlist sg[1]; /* MUST BE last item */
};
next prev parent reply other threads:[~2006-02-03 19:46 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20051129092432.0f5742f0.akpm@osdl.org>
2005-11-29 18:34 ` Ryan Richter
[not found] ` <Pine.LNX.4.63.0511292147120.5739@kai.makisara.local>
2005-11-29 20:31 ` Ryan Richter
2005-11-29 20:48 ` Kai Makisara
2005-11-29 20:58 ` Ryan Richter
2005-11-29 21:36 ` Kai Makisara
2005-11-30 5:12 ` Kai Makisara
2005-12-01 19:18 ` Kai Makisara
2005-12-01 19:38 ` Linus Torvalds
2005-12-01 19:56 ` Ryan Richter
2005-12-01 20:21 ` Hugh Dickins
2005-12-01 21:44 ` Kai Makisara
2005-12-02 18:03 ` Ryan Richter
2005-12-02 18:43 ` Jesper Juhl
2005-12-02 19:12 ` Hugh Dickins
2005-12-02 19:44 ` Ryan Richter
2005-12-02 20:40 ` Hugh Dickins
2005-12-03 17:29 ` Ryan Richter
2005-12-06 16:08 ` Ryan Richter
2005-12-06 20:31 ` Hugh Dickins
2005-12-06 20:43 ` Ryan Richter
2005-12-07 18:37 ` Hugh Dickins
2005-12-08 2:26 ` Ryan Richter
2005-12-12 16:54 ` Ryan Richter
2005-12-12 17:40 ` Linus Torvalds
2005-12-12 17:45 ` James Bottomley
2005-12-12 18:04 ` Ryan Richter
2005-12-12 18:09 ` Linus Torvalds
2005-12-12 18:24 ` James Bottomley
2005-12-15 19:09 ` Ryan Richter
2005-12-16 4:01 ` James Bottomley
2005-12-17 3:31 ` Ryan Richter
2005-12-26 23:42 ` Ryan Richter
2005-12-27 16:21 ` Kai Makisara
2006-01-03 19:03 ` Ryan Richter
2006-01-04 17:27 ` Ryan Richter
2006-01-04 21:48 ` Kai Makisara
2006-01-05 5:40 ` Ryan Richter
2006-01-05 20:12 ` Ryan Richter
2006-01-05 21:18 ` Linus Torvalds
2006-01-08 22:36 ` Ryan Richter
2006-01-09 3:31 ` Ryan Richter
2006-01-09 4:07 ` Linus Torvalds
2006-01-09 5:13 ` Andrew Morton
2006-01-09 5:45 ` Ryan Richter
2006-01-09 5:57 ` Andrew Morton
2006-01-09 9:44 ` Hugh Dickins
2006-01-09 18:53 ` Ryan Richter
2006-01-09 19:31 ` Hugh Dickins
2006-01-09 20:05 ` Ryan Richter
2006-01-18 0:12 ` Ryan Richter
2006-01-18 16:00 ` Hugh Dickins
2006-02-03 19:46 ` Hugh Dickins [this message]
2006-02-03 19:51 ` [PATCH] ib: don't doublefree pages from scatterlist Hugh Dickins
2006-02-03 23:13 ` Roland Dreier
2006-02-03 19:53 ` [PATCH] st: " Hugh Dickins
2006-02-03 20:38 ` Mike Christie
2006-02-03 21:16 ` Hugh Dickins
2006-02-04 12:10 ` Kai Makisara
2006-02-04 15:01 ` Hugh Dickins
2006-02-03 19:55 ` [PATCH] ipr: " Hugh Dickins
2006-02-03 22:06 ` Brian King
2006-02-04 0:26 ` Hugh Dickins
2006-02-05 21:35 ` Brian King
2006-02-06 9:32 ` Hugh Dickins
2006-02-06 9:46 ` David S. Miller
2006-02-06 14:46 ` Brian King
2006-02-06 16:45 ` Hugh Dickins
2006-02-06 17:38 ` James Bottomley
2006-02-06 19:15 ` Brian King
2006-02-06 21:11 ` Andi Kleen
2006-02-06 21:49 ` David S. Miller
2006-02-06 22:11 ` Hugh Dickins
2006-02-06 22:13 ` Andi Kleen
2006-02-07 3:09 ` Ryan Richter
2006-02-11 22:38 ` Ryan Richter
2006-02-12 18:57 ` Hugh Dickins
2006-02-12 21:29 ` Andi Kleen
2006-02-13 17:21 ` Hugh Dickins
2006-02-06 15:02 ` James Bottomley
2006-02-06 17:01 ` Hugh Dickins
2006-02-03 19:56 ` [PATCH] osst: " Hugh Dickins
2006-02-03 21:10 ` Fw: crash on x86_64 - mm related? Ryan Richter
2006-02-04 11:58 ` Kai Makisara
2006-02-04 14:46 ` Hugh Dickins
2006-01-05 22:09 ` Kai Makisara
2006-01-04 18:26 ` Ryan Richter
2005-12-07 18:30 ` Ryan Richter
2005-12-07 18:56 ` Hugh Dickins
2005-12-07 19:06 ` Ryan Richter
2005-12-06 17:57 ` Ryan Richter
2005-12-01 20:28 ` James Bottomley
2005-12-01 21:17 ` Kai Makisara
2005-12-02 13:45 ` Hugh Dickins
2005-12-02 17:59 ` Kai Makisara
2005-12-02 18:55 ` Hugh Dickins
2005-12-02 19:46 ` Kai Makisara
2005-12-02 20:47 ` Hugh Dickins
2005-12-04 9:29 ` Kai Makisara
2005-12-01 19:53 ` Ryan Richter
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.61.0602031842290.14065@goblin.wat.veritas.com \
--to=hugh@veritas.com \
--cc=James.Bottomley@SteelEye.com \
--cc=Kai.Makisara@kolumbus.fi \
--cc=akpm@osdl.org \
--cc=brking@us.ibm.com \
--cc=dougg@torque.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=osst@riede.org \
--cc=rdreier@cisco.com \
--cc=ryan@tau.solarneutrino.net \
--cc=torvalds@osdl.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
all inboxes | Powered by JetHome®