Re: linux-next oops

["Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>]

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