<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <style>  </style>  </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> Hello everyone, <o:p></o:p> <o:p> </o:p> I believe that I’ve found a bug in the dm-stripe.c driver. I’ve been working on getting event alerting put into the driver so that it matches what is found in the dm-raid1.c driver. During my implementation efforts I ran into a problem where the kernel would oops out when I tried to call the queue_work() function. After putting some printk’s in the driver to monitor the pointer addresses of the stripe_c structure members I finally think I’ve got an answer. I found that in its declaration the struct stripe stripe[0] is only accounting for a stripe with one drive present; in my case I have 2 drives in the stripe volume. Here is the stripe struct (and as you can see it only allows for 1 drive):<o:p></o:p> <o:p> </o:p> struct stripe_c {<o:p></o:p> uint32_t stripes;<o:p></o:p> <o:p> </o:p> /* The size of this target / num. stripes */<o:p></o:p> sector_t stripe_width;<o:p></o:p> <o:p> </o:p> /* stripe chunk size */<o:p></o:p> uint32_t chunk_shift;<o:p></o:p> sector_t chunk_mask;<o:p></o:p> <o:p> </o:p> /***** Here’s the problem spot *****/ <o:p></o:p> struct stripe stripe[0];<o:p></o:p> <o:p></o:p> /***** New member elements below problem declaration *****/<o:p></o:p> /* Needed for handling events */<o:p></o:p> struct dm_target *ti;<o:p></o:p> <o:p></o:p> /* New work_queue setup for triggering events*/<o:p></o:p> struct work_struct kstriped_ws;<o:p></o:p> <o:p> </o:p> };<o:p></o:p> <o:p> </o:p> So, by adding the new declarations of member elements after that stripe[0] declaration there is the possibility of overwriting memory addresses when the processing code for the get_stripe() function is ran. Here’s a snippet of the printk code I used to figure this out and its resulting syslog data:<o:p></o:p> <o:p> </o:p> /*<o:p></o:p> * Construct a striped mapping.<o:p></o:p> * <number of stripes> <chunk size (2^^n)> [<dev_path> <offset>]+<o:p></o:p> */<o:p></o:p> static int stripe_ctr(struct dm_target *ti, unsigned int argc, char **argv)<o:p></o:p> {<o:p></o:p> .<o:p></o:p> .<o:p></o:p> .<o:p></o:p> /*<o:p></o:p> * Get the stripe destinations.<o:p></o:p> */<o:p></o:p> for (i = 0; i < stripes; i++) {<o:p></o:p> argv += 2;<o:p></o:p> printk("EVENT: 7:%d Address of sc->kstriped_ws.entry=%p, next=%p, prev=%p\n", i, &sc->kstriped_ws.entry, sc->kstriped_ws.entry.next, sc->kstriped_ws.entry.prev);<o:p></o:p> r = get_stripe(ti, sc, i, argv);<o:p></o:p> printk("EVENT: 8:%d Address of sc->kstriped_ws.entry=%p, next=%p, prev=%p\n", i, &sc->kstriped_ws.entry, sc->kstriped_ws.entry.next, sc->kstriped_ws.entry.prev);<o:p></o:p> if (r < 0) {<o:p></o:p> ti->error = "Couldn't parse stripe destination";<o:p></o:p> while (i--)<o:p></o:p> dm_put_device(ti, sc->stripe[i].dev);<o:p></o:p> kfree(sc);<o:p></o:p> return r;<o:p></o:p> }<o:p></o:p> }<o:p></o:p> .<o:p></o:p> .<o:p></o:p> .<o:p></o:p> }<o:p></o:p> <o:p></o:p> /*<o:p></o:p> * Parse a single <dev> <sector> pair<o:p></o:p> */<o:p></o:p> static int get_stripe(struct dm_target *ti, struct stripe_c *sc,<o:p></o:p> unsigned int stripe, char **argv)<o:p></o:p> {<o:p></o:p> unsigned long long start;<o:p></o:p> <o:p> </o:p> if (sscanf(argv[1], "%llu", &start) != 1)<o:p></o:p> return -EINVAL;<o:p></o:p> <o:p> </o:p> printk("EVENT: 7:%d%d.1 Address of sc->kstriped_ws.entry=%p, next=%p, prev=%p\n", stripe, stripe, &sc->kstriped_ws.entry, sc->kstriped_ws.entry.next, sc->kstriped_ws.entry.prev);<o:p></o:p> printk(" argv[0]=%s, stripe=%d, sc->stripe_width=%u\n", argv[0], stripe, (uint32_t)sc->stripe_width); <o:p></o:p> if (dm_get_device(ti, argv[0], start, sc->stripe_width,<o:p></o:p> dm_table_get_mode(ti->table),<o:p></o:p> &sc->stripe[stripe].dev))<o:p></o:p> return -ENXIO;<o:p></o:p> printk("EVENT: 7:%d%d.2 Address of sc->kstriped_ws.entry=%p, next=%p, prev=%p\n",stripe, stripe, &sc->kstriped_ws.entry, sc->kstriped_ws.entry.next, sc->kstriped_ws.entry.prev);<o:p></o:p> <o:p> </o:p> sc->stripe[stripe].physical_start = start;<o:p></o:p> printk("EVENT: 7:%d%d.3 Address of sc->kstriped_ws.entry=%p, next=%p, prev=%p\n",stripe, stripe, &sc->kstriped_ws.entry, sc->kstriped_ws.entry.next, sc->kstriped_ws.entry.prev);<o:p></o:p> <o:p> </o:p> return 0;<o:p></o:p> }<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Nov 21 01:55:19 dmraid-devhost kernel: EVENT: 7:0 Address of sc->kstriped_ws.entry=ffff81001d8ca5b0, next=ffff81001d8ca5b0, prev=ffff81001d8ca5b0<o:p></o:p> Nov 21 01:55:19 dmraid-devhost kernel: EVENT: 7:00.1 Address of sc->kstriped_ws.entry=ffff81001d8ca5b0, next=ffff81001d8ca5b0, prev=ffff81001d8ca5b0<o:p></o:p> Nov 21 01:55:19 dmraid-devhost kernel: argv[0]=/dev/sdb, stripe=0, sc->stripe_width=488391936<o:p></o:p> Nov 21 01:55:19 dmraid-devhost kernel: EVENT: 7:00.2 Address of sc->kstriped_ws.entry=ffff81001d8ca5b0, next=ffff81001d8ca5b0, prev=ffff81001d8ca5b0<o:p></o:p> Nov 21 01:55:19 dmraid-devhost kernel: EVENT: 7:00.3 Address of sc->kstriped_ws.entry=ffff81001d8ca5b0, next=ffff81001d8ca5b0, prev=ffff81001d8ca5b0<o:p></o:p> Nov 21 01:55:19 dmraid-devhost kernel: EVENT: 8:0 Address of sc->kstriped_ws.entry=ffff81001d8ca5b0, next=ffff81001d8ca5b0, prev=ffff81001d8ca5b0<o:p></o:p> Nov 21 01:55:19 dmraid-devhost kernel: EVENT: 7:1 Address of sc->kstriped_ws.entry=ffff81001d8ca5b0, next=ffff81001d8ca5b0, prev=ffff81001d8ca5b0<o:p></o:p> Nov 21 01:55:19 dmraid-devhost kernel: EVENT: 7:11.1 Address of sc->kstriped_ws.entry=ffff81001d8ca5b0, next=ffff81001d8ca5b0, prev=ffff81001d8ca5b0<o:p></o:p> Nov 21 01:55:19 dmraid-devhost kernel: argv[0]=/dev/sdc, stripe=1, sc->stripe_width=488391936<o:p></o:p> Nov 21 01:55:19 dmraid-devhost kernel: EVENT: 7:11.2 Address of sc->kstriped_ws.entry=ffff81001d8ca5b0, next=ffff81003c47dec0, prev=ffff81001d8ca5b0<o:p></o:p> Nov 21 01:55:19 dmraid-devhost kernel: EVENT: 7:11.3 Address of sc->kstriped_ws.entry=ffff81001d8ca5b0, next=ffff81003c47dec0, prev=0000000000000000<o:p></o:p> Nov 21 01:55:19 dmraid-devhost kernel: EVENT: 8:1 Address of sc->kstriped_ws.entry=ffff81001d8ca5b0, next=ffff81003c47dec0, prev=0000000000000000<o:p></o:p> <o:p> </o:p> As you can see from the output when it hits the second drive of the stripe it is overwriting the memory addresses for the work_struct list_head “prev” pointer; leading to my oops condition.<o:p></o:p> <o:p> </o:p> To verify this I decided to up the number in stripe[] to match the number of drives present:<o:p></o:p> struct stripe stripe[1];<o:p></o:p> <o:p> </o:p> After this change the memory corruption is gone:<o:p></o:p> <o:p> </o:p> Nov 21 02:21:45 dmraid-devhost kernel: EVENT: 7:0 Address of sc->kstriped_ws.entry=ffff81001f4d8040, next=ffff81001f4d8040, prev=ffff81001f4d8040<o:p></o:p> Nov 21 02:21:45 dmraid-devhost kernel: EVENT: 7:00.1 Address of sc->kstriped_ws.entry=ffff81001f4d8040, next=ffff81001f4d8040, prev=ffff81001f4d8040<o:p></o:p> Nov 21 02:21:45 dmraid-devhost kernel: argv[0]=/dev/sdb, stripe=0, sc->stripe_width=488391936<o:p></o:p> Nov 21 02:21:45 dmraid-devhost kernel: EVENT: 7:00.2 Address of sc->kstriped_ws.entry=ffff81001f4d8040, next=ffff81001f4d8040, prev=ffff81001f4d8040<o:p></o:p> Nov 21 02:21:45 dmraid-devhost kernel: EVENT: 7:00.3 Address of sc->kstriped_ws.entry=ffff81001f4d8040, next=ffff81001f4d8040, prev=ffff81001f4d8040<o:p></o:p> Nov 21 02:21:45 dmraid-devhost kernel: EVENT: 8:0 Address of sc->kstriped_ws.entry=ffff81001f4d8040, next=ffff81001f4d8040, prev=ffff81001f4d8040<o:p></o:p> Nov 21 02:21:45 dmraid-devhost kernel: EVENT: 7:1 Address of sc->kstriped_ws.entry=ffff81001f4d8040, next=ffff81001f4d8040, prev=ffff81001f4d8040<o:p></o:p> Nov 21 02:21:45 dmraid-devhost kernel: EVENT: 7:11.1 Address of sc->kstriped_ws.entry=ffff81001f4d8040, next=ffff81001f4d8040, prev=ffff81001f4d8040<o:p></o:p> Nov 21 02:21:45 dmraid-devhost kernel: argv[0]=/dev/sdc, stripe=1, sc->stripe_width=488391936<o:p></o:p> Nov 21 02:21:45 dmraid-devhost kernel: EVENT: 7:11.2 Address of sc->kstriped_ws.entry=ffff81001f4d8040, next=ffff81001f4d8040, prev=ffff81001f4d8040<o:p></o:p> Nov 21 02:21:45 dmraid-devhost kernel: EVENT: 7:11.3 Address of sc->kstriped_ws.entry=ffff81001f4d8040, next=ffff81001f4d8040, prev=ffff81001f4d8040<o:p></o:p> Nov 21 02:21:45 dmraid-devhost kernel: EVENT: 8:1 Address of sc->kstriped_ws.entry=ffff81001f4d8040, next=ffff81001f4d8040, prev=ffff81001f4d8040<o:p></o:p> <o:p> </o:p> <o:p> </o:p> My question now is how should this be patched? Do I just use some arbitrary number in the stripe[] declaration? Say something like 6 (since that is the maximum number of on-board SATA ports for an Intel based controller at the moment). (Probably not, since this is making it platform specific.) How about maybe changing this to an array-of-pointers to a “struct stripe” and setting this to something like “struct stripe *stripe[256]”? This would only be wasting memory for the unused pointers which is comparatively small. <o:p></o:p> <o:p> </o:p> I look forward to hearing everyone’s ideas on how this should be solved, thank you.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Brian Wood<o:p></o:p> Software Engineer<o:p></o:p> Intel Corp., Manageability & Platform Software Division<o:p></o:p> brian.j.wood@intel.com<o:p></o:p> <o:p> </o:p> </div> </body> </html>