On Mon, 23 Jul 2007 16:54:36 -0400 "Mike Frysinger" <[EMAIL PROTECTED]> wrote:
> On 7/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Mon, 23 Jul 2007 14:19:12 -0400 > > Robin Getz <[EMAIL PROTECTED]> wrote: > > > > > On Sun 22 Jul 2007 19:50, Mike Frysinger pondered: > > > > > > > > i think the attached two functions account for what Robin and Andrew > > > > were thinking ... > > > > > > A note about why/when grab_lock would be set to zero (pre-kernel init, or > > > OOPs) might be nice. > > > > Definitely. > > > > The pre-kernel init shouldn't be an issue: logbuf_lock is initialised at > > compile time. > > > > At oops time we could possibly use oops_in_progress to work out whether to > > avoid taking the lock. That's not terribly nice, but nor is it nice for > > callers to know about printk internals. > > maybe, but for early debug users (the reason we wanted this > originally), it wouldnt be an oops in progress ... but i guess we can > just as easily set oops_in_progress to 1 in our code before calling > this function to keep from having to worry over locks from being > doubly grabbed. I don't immediately see how logbuf_lock could be doubly grabbed. Only if you're calling this from hard irq context? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
