diff options
| author | Hugh Dickins <hugh@veritas.com> | 2005-12-01 20:21:57 +0000 |
|---|---|---|
| committer | James Bottomley <jejb@titanic.(none)> | 2005-12-01 16:16:06 -0600 |
| commit | 6bc733e9f71c937f3c64159bf1e569321726a44c (patch) | |
| tree | 2822abc9574f1fc0d8eddb80adbe34d5460926ff /kernel/resource.c | |
| parent | c87e34efaecc952f9a0c1bbb9c6da76ccbf5ee3d (diff) | |
| download | op-kernel-dev-6bc733e9f71c937f3c64159bf1e569321726a44c.zip op-kernel-dev-6bc733e9f71c937f3c64159bf1e569321726a44c.tar.gz | |
[SCSI] st: fix a bug in sgl_map_user_pages failure path
Nick and I had already been looking at drivers/scsi/{sg.c,st.c},
brought there by __put_page in sg.c's peculiar sg_rb_correct4mmap,
which we'd like to remove. But that's irrelevant to your pain, except...
One extract from the patches I'd like to send Doug and Kai for 2.6.15
or 2.6.16 is this below: since the incomplete get_user_pages path omits
to reset res, but has already released all the pages, it will result in
premature freeing of user pages, and behaviour just like you've seen.
Though I'd have thought incomplete get_user_pages was an exceptional
case, and a bit surprised you'd encounter it. Perhaps there's some
other premature freeing in the driver, and this instance has nothing
whatever to do with it.
If the problem were easily reproducible, it'd be great if you could
try this patch; but I think you've said it's not :-(
Signed-off-by: Kai Makisara <kai.makisara@kolumbus.fi>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Diffstat (limited to 'kernel/resource.c')
0 files changed, 0 insertions, 0 deletions
