On Fri, 2010-04-09 at 11:13 -0400, John David Anglin wrote: > On Fri, 09 Apr 2010, Carlos O'Donell wrote: > > > We need to start splitting up your giant "stability" patch into > > manageable chunks. > > I agree. What I posted was not intended as a submission. Some > of the changes aren't mine, some are cleanups, some are "obvious", > some are not obvious and may well be wrong, or inefficient. > > I posted the change to not clobber r19 on fork/clone syscalls, > but there has been no response to it. Theory looks fine to me ... although Helge sees no difference in behaviour, I'd be happy to apply on the principle of no harm and theoretically necessary. > I will try split up the change this weekend. > > > For example, are the futex fixes anywhere for Kyle to pickup? > > The futex fixes are Helge's and were posted to the list on Wed, > 03 Feb 2010 23:03:49 +0100 along with Helge's minifail3.c. > > The change to syscall.S in the above post included two hunks from me. > I removed Helge's portion so that I could enable LWS locking on UP > builds because of the concern that a page fault on COW memory could > cause user code to be scheduled in the locking code. > > I think there is merit in using __atomic_user_hash, etc, but it > will take a bit of work to make it available in UP kernels. > I think Helge's change to fork.c is probably not necessary. I'm fairly convinced we need the flush on kmap(_atomic) as well if the user had dirtied the page. Right at the moment if the aliases are inequivalent (which they are about 99.9% of the time) we're in danger of using stale data in the kernel. We also need a flush on kunmap if the kernel has dirtied the page. James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
