Messages in this thread | | | From | "Bu, Yitian" <> | Subject | RE: [PATCH] Fix rq->lock vs logbuf_lock unlock race | Date | Wed, 20 Feb 2013 11:24:36 +0000 |
| |
> Unfortunately that's not quite possible, rq->lock is really out of bounds. At > one point I tried 'fixing' this but there's a whole bunch of nasty that's not > going to go away. > > I've since forgotten most of the details, but aside from logbuf problems > there's a whole host of issues with the console drivers themselves as well. > > If you really want to do this, use early_printk.
Hi Peter:
The patch 0b5e1c5255e("printk: Release console_sem after logbuf_lock" ) is as below:
console_locked = 0; - up(&console_sem); + wake = 1; retval = 0; } } printk_cpu = UINT_MAX; spin_unlock(&logbuf_lock); + if (wake) + up(&console_sem); return retval;
the patch 07354eb1a74d1("locking, printk: Annotate logbuf_lock as raw ") is as below:
printk_cpu = UINT_MAX; - spin_unlock(&logbuf_lock); if (wake) up(&console_sem); + raw_spin_unlock(&logbuf_lock); return retval; }
Note that the purpose of patch 07354eb1a74d1 is to use raw_spin_unlock instead of spin_unlock, it is not supposed to change any lock sequences.
What I do is to revert this change to 0b5e1c5255e, and it is nothing to do with how people use printk. It is just to recover a merge mistake.
| |