[lkml]   [2002]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.5.31: modules don't work at all
    Linus Torvalds wrote:
    > On Sun, 11 Aug 2002, Andrew Morton wrote:
    > >
    > > Yes, that's the problem. qm_symbols() is performing copy_to_user()
    > > inside lock_kernel() and that's an "atomic copy_to_user()" in 2.5.31.
    > > But only if preempt is selected. The copy_to_user() doesn't work.
    > >
    > > There's nothing illegal about copy_to_user() inside lock_kernel().
    > >
    > > Linus, we can back out the preempt_count() test in there and
    > > perform the atomic copy_*_user via a current->flags bit, or
    > > we can do something else?
    > Since I'm actually hoping that the kernel lock goes away some day, and I
    > don't want to pollute the stuff that I hope will _not_ go away, I'd prefer
    > a slightly different approach, namely make kernel_lock() special from a
    > preempt_count() angle.
    > In particular, we already "sort" the preemtion count bits according to
    > just how atomic we are, and lock_kernel is certainly "less atomic" than a
    > spinlock. So the logical thing to do (I think) is to just make that more
    > explicit, and make lock_kernel use the low bit of preempt_count, and make
    > regular spinlocks do a "+= 2" instead of a "+= 1".

    Gets tricky with nested lock_kernels.

    We can do

    if (preempt_count() - current->lock_depth)

    To ignore the bkl contribution to preempt_count.

    I think that's even usable in generic code, because all architectures
    use lock_depth in the same way.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:27    [W:0.023 / U:38.708 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site