lkml.org 
[lkml]   [2007]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] paravirt: isolate module ops
Arjan van de Ven wrote:
>> I would suggest a slightly different carving. For one, no TLB flushes.
>> If you can't modify PTEs, why do you need to have TLB flushes? And I
>> would allow CR0 read / write for code which saves and restores FPU state
>>
>
> no that is abstracted away by kernel_fpu_begin/end. Modules have no
> business doing that themselves
>

As long as they don't rely on inlines for that... checking and
kernel_fpu_end is inline and uses stts(), which requires CR0 read /
write. One can easily imagine binary modules which do use the fpu, and
these were not broken before, so breaking them now seems the wrong thing
to do.

I agree on debug registers - anything touching them is way too shady.
And there is no reason modules should be doing raw page table
operations, they should use proper mm functions and leave the page
details to the mm layer, which doesn't do these things inline.

Basically, it is just the things that do get inlined that I think we
should worry about. If you all feel strongly that this should be fixed
in 2.6.20, perhaps the best thing to do is in fact
EXPORT_SYMBOL_GPL(paravirt_ops), and we can queue up a patch in -mm
which will export those paravirt_ops required inline by modules for
2.6.21. Otherwise, I think there will be too many rejects against the
paravirt code in Andrew's tree.

Zach
-
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: 2007-01-06 05:45    [W:0.065 / U:0.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site