linux-next oops
 

I'm seeing an oops with the patch
http://people.redhat.com/agk/patches/linux/editing/dm-store-dm_target_io-in-bio-front_pad.patch
in linux-next (commit 24d047b).

I'll attach the dmesg output from a crash. I bisected it down to this
one patch and verified that reverting it results in a kernel that
boots normally. It appears that this will crash any linux-next kernel
since 20120918 -- I've not tried them all, but I have tried a few.

The machines where this happens are Dell PowerEdge SC1425

--
Bill


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

linux-next oops
 

Hi

I pulled linux-next, set up multipath and executed fsync() on it, and
there was no crash for me.

Mikulas


On Tue, 9 Oct 2012, Bill Pemberton wrote:

> I'm seeing an oops with the patch
> http://people.redhat.com/agk/patches/linux/editing/dm-store-dm_target_io-in-bio-front_pad.patch
> in linux-next (commit 24d047b).
>
> I'll attach the dmesg output from a crash. I bisected it down to this
> one patch and verified that reverting it results in a kernel that
> boots normally. It appears that this will crash any linux-next kernel
> since 20120918 -- I've not tried them all, but I have tried a few.
>
> The machines where this happens are Dell PowerEdge SC1425
>
> --
> Bill
>
>
>

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

linux-next oops
 

Hello Mikulas,

On 10/10/12 08:57, Mikulas Patocka wrote:
> On Tue, 9 Oct 2012, Bill Pemberton wrote:
>
>> I'm seeing an oops with the patch
>> http://people.redhat.com/agk/patches/linux/editing/dm-store-dm_target_io-in-bio-front_pad.patch
>> in linux-next (commit 24d047b).
>>
>> I'll attach the dmesg output from a crash. I bisected it down to this
>> one patch and verified that reverting it results in a kernel that
>> boots normally. It appears that this will crash any linux-next kernel
>> since 20120918 -- I've not tried them all, but I have tried a few.
>>
>> The machines where this happens are Dell PowerEdge SC1425

I haven't actually tried linux-next but
the following code misses actual cloning after alloc_tio().
(Your patch removed bio_clone_bioset())
Doesn't it cause flush request to be issued unprepared?

1121 static void __issue_target_request(struct clone_info *ci, struct dm_target *ti,
1122 unsigned request_nr, sector_t len)
1123 {
1124 struct dm_target_io *tio = alloc_tio(ci, ti, ci->bio->bi_max_vecs);
1125 struct bio *clone = &tio->clone;
1126
1127 tio->info.target_request_nr = request_nr;
1128
1129 /*
1130 * Discard requests require the bio's inline iovecs be initialized.
1131 * ci->bio->bi_max_vecs is BIO_INLINE_VECS anyway, for both flush
1132 * and discard, so no need for concern about wasted bvec allocations.
1133 */
1134
1135 if (len) {
1136 clone->bi_sector = ci->sector;
1137 clone->bi_size = to_bytes(len);
1138 }
1139
1140 __map_bio(ti, tio);

--
Jun'ichi Nomura, NEC Corporation

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

linux-next oops
 

> I pulled linux-next, set up multipath and executed fsync() on it, and
> there was no crash for me.
>

Ok, I've got two machines that won't boot with it.... it doesn't get
far enough to run anything.

--
Bill

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

linux-next oops
 

On Tue, 9 Oct 2012, Bill Pemberton wrote:

> > I pulled linux-next, set up multipath and executed fsync() on it, and
> > there was no crash for me.
> >
>
> Ok, I've got two machines that won't boot with it.... it doesn't get
> far enough to run anything.
>
> --
> Bill

Try this. In my original patch that I sent, I removed bio_alloc_bioset and
left __bio_clone. But meanwhile, Kent Overstreet sent another patch that
replaces both bio_alloc_bioset and __bio_clone with bio_clone_bioset. The
reason for this crash is incorrect resolution of this conflict -
bio_clone_bioset was removed (although my patch removed only
bio_alloc_bioset) and __bio_clone was not added back.

Mikulas

---
drivers/md/dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-next-copy/drivers/md/dm.c
================================================== =================
--- linux-next-copy.orig/drivers/md/dm.c 2012-10-11 02:55:34.000000000 +0200
+++ linux-next-copy/drivers/md/dm.c 2012-10-11 02:55:58.000000000 +0200
@@ -1160,7 +1160,7 @@ static void __issue_target_request(struc
* ci->bio->bi_max_vecs is BIO_INLINE_VECS anyway, for both flush
* and discard, so no need for concern about wasted bvec allocations.
*/
-
+ __bio_clone(clone, ci->bio);
if (len) {
clone->bi_sector = ci->sector;
clone->bi_size = to_bytes(len);

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

linux-next oops
 

Mikulas Patocka writes:
>
> Try this. In my original patch that I sent, I removed bio_alloc_bioset and
> left __bio_clone. But meanwhile, Kent Overstreet sent another patch that
> replaces both bio_alloc_bioset and __bio_clone with bio_clone_bioset. The
> reason for this crash is incorrect resolution of this conflict -
> bio_clone_bioset was removed (although my patch removed only
> bio_alloc_bioset) and __bio_clone was not added back.
>
> Mikulas
>
> ---
> drivers/md/dm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-next-copy/drivers/md/dm.c
> ================================================== =================
> --- linux-next-copy.orig/drivers/md/dm.c 2012-10-11 02:55:34.000000000 +0200
> +++ linux-next-copy/drivers/md/dm.c 2012-10-11 02:55:58.000000000 +0200
> @@ -1160,7 +1160,7 @@ static void __issue_target_request(struc
> * ci->bio->bi_max_vecs is BIO_INLINE_VECS anyway, for both flush
> * and discard, so no need for concern about wasted bvec allocations.
> */
> -
> + __bio_clone(clone, ci->bio);
> if (len) {
> clone->bi_sector = ci->sector;
> clone->bi_size = to_bytes(len);
>


Yes, this fixes the crashes for me.

--
Bill

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel