lkml.org 
[lkml]   [2002]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:27    [from the cache]
©2003-2011 Jasper Spaans