* Andrew Morton <[email protected]> wrote:
> > However I still have some concern on cond_resched_lock(), on an UP
> > kernel it will return 1 if schedule happen, but actually it does not
> > drop any lock, that semantic seems to be different to SMP kernel.
>
> That's OK (I think - I don't have a good track record in this thread).
>
> If the kernel is non-preemptible and UP, we want to return true from
> cond_resched_foo() if we called schedule(). Because schedule() might
> allow a different thread into the kernel which might modify the locked
> data.
>
> And if the kernel is preemptible and UP, we want to return true from
> cond_resched_foo() if we dropped the lock, because that internally
> does a preempt_enable().
>
> And the patch (hopefully) satisfies those requirements. Does that all
> sound solid?
it looks solid to me ... but this is subtle stuff and i dont seem to
have a good track record for these details today. I guess if it's
inadequate Zou ought to see them in practice?
Ingo
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]