On Mon, 2019-09-30 at 10:57 -0700, John Hubbard wrote: > > As I told before, there are cases where this function is called from > > 'real mode' in powerpc, which doesn't disable irqs and may have a > > tricky behavior if we do. So, encapsulate the irq disable in this > > function can be a bad choice. > > You still haven't explained how this works in that case. So far, the > synchronization we've discussed has depended upon interrupt disabling > as part of the solution, in order to hold off page splitting and page > table freeing. The irqs are already disabled by another mechanism (hw): MSR_EE=0. So, serialize will work as expected. > Simply skipping that means that an additional mechanism is required...which > btw might involve a new, ppc-specific routine, so maybe this is going to end > up pretty close to what I pasted in after all... > > Of course, if we really need that, we can add a bool parameter to the > > function to choose about disabling/enabling irqs. > > > * This is really a core mm function, so don't hide it away in arch layers. > > > (If you're changing mm/ files, that's a big hint.) > > > > My idea here is to let the arch decide on how this 'register' is going > > to work, as archs may have different needs (in powerpc for example, we > > can't always disable irqs, since we may be in realmode). > > > > Maybe we can create a generic function instead of a dummy, and let it > > be replaced in case the arch needs to do so. > > Yes, that might be what we need, if it turns out that ppc can't use this > approach (although let's see about that). > I initially used the dummy approach because I did not see anything like serialize in other archs. I mean, even if I put some generic function here, if there is no function to use the 'lockless_pgtbl_walk_count', it becomes only a overhead. > > thanks, Thank you!
Attachment:
signature.asc
Description: This is a digitally signed message part
