From 317cc01098bd9fe88530a38a97636c0a77462ab6 Mon Sep 17 00:00:00 2001 From: "Stephen M. Cameron" Date: Thu, 12 Nov 2009 12:49:55 -0600 Subject: [PATCH] --- yaml --- r: 172956 b: refs/heads/master c: da0021841c3ea6a82588efae3260015847ea5d33 h: refs/heads/master v: v3 --- [refs] | 2 +- trunk/drivers/block/cciss.c | 18 ++++++++++++++++-- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/[refs] b/[refs] index 8751bdc03eb9..fb7dddefeb7b 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: d06dfbd236795acbb67e22e51bb8af12e953ced3 +refs/heads/master: da0021841c3ea6a82588efae3260015847ea5d33 diff --git a/trunk/drivers/block/cciss.c b/trunk/drivers/block/cciss.c index 42eaddb54380..bf2d1c80b788 100644 --- a/trunk/drivers/block/cciss.c +++ b/trunk/drivers/block/cciss.c @@ -3416,8 +3416,22 @@ static int check_for_unit_attention(ctlr_info_t *h, CommandList_struct *c) case REPORT_LUNS_CHANGED: printk(KERN_WARNING "cciss%d: report LUN data " "changed\n", h->ctlr); - add_to_scan_list(h); - wake_up_process(cciss_scan_thread); + /* + * Here, we could call add_to_scan_list and wake up the scan thread, + * except that it's quite likely that we will get more than one + * REPORT_LUNS_CHANGED condition in quick succession, which means + * that those which occur after the first one will likely happen + * *during* the scan_thread's rescan. And the rescan code is not + * robust enough to restart in the middle, undoing what it has already + * done, and it's not clear that it's even possible to do this, since + * part of what it does is notify the block layer, which starts + * doing it's own i/o to read partition tables and so on, and the + * driver doesn't have visibility to know what might need undoing. + * In any event, if possible, it is horribly complicated to get right + * so we just don't do it for now. + * + * Note: this REPORT_LUNS_CHANGED condition only occurs on the MSA2012. + */ return 1; break; case POWER_OR_RESET: