On Fri, Feb 28, 2014 at 02:12:22PM +1100, Finn Thain wrote: > > >> Data read fault at 0x00000000 in Super Data (pc=0x3afec) BAD KERNEL > > >> BUSERR > > > > I think futex_init needs to do set_fs(USER_DS), since futex is about > > user data. > > Rhetorical question: does it make sense to explicitly switch to USER_DS > when we know that current->mm may be invalid at the time? > > Given that the presence of USER_DS or KERNEL_DS at initcall-time varies > between architectures, perhaps this question must be left to arch > implementors. All architectures start with KERNEL_DS, otherwise the first couple of system calls within kernel_init() would all fail and the system wouldn't boot. > Moreover, architectures that have no need for a run-time test for usable > futex_value ops have no real interest in such questions. AFAICT, only mips > needs the run-time test. > > For every other arch the availability of futex_value ops is known at > compile-time. We don't need to pursue universal answers to questions like > these: > > 1) the correctness of switching to USER_DS with mm->current == NULL [1] I "fixed" s390, so it should survive an early switch to USER_DS and a subsequent failing user space access now. Anyway, > The discussion of these questions in various threads on various lists did > not resolve anything. Again, this is probably because all of these > questions are actually arch implementation issues. > > So it seems to me that the solution to the futex_init() problem is to > evaluate the futex_cmpxchg_enabled assignment at compile-time where > possible, and use the run-time test only on mips. Thoughts? Such a patch exists already (bottom of message): http://marc.info/?l=linux-next&m=138875880028607&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
