On Fri, 2012-05-25 at 16:16 -0400, David Miller wrote: > From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > Date: Fri, 25 May 2012 14:59:52 +0100 > > > I'll queue this patch in our git repo. It seems to work fine for us, > > thanks, Dave! > > > > Parisc people, I'm a bit worried about the #include <linux/sched.h> in > > asm/uaccess.h ... I'm sure that's going to lead to complications later. > > It's needed to get the dynamic TASK_SIZE, which expands through the task > > structure to fill in user_addr_max() ... I'm thinking though that the > > top of address space doesn't provide much protection on pa (since our > > stack grows up towards it anyway, so we could just replace that with > > ~0UL ... what do people think? > > Do what I did on Sparc wrt. TASK_SIZE, that way you won't need to > include linux/sched.h Yes, we have all the machinery for a variable task_size, but we never use it. > The only reason you need linux/sched.h is to get > test_tsk_thread_flag(), for your TASK_SIZE_OF(). > > But that's completely pointless for TASK_SIZE which only needs to look > at the current thread's settings. > > Thus if you use test_thread_flag() for TASK_SIZE, instead of trying to > borrow TASK_SIZE_OF()'s implementation, you'll no longer have this > linux/sched.h dependency. Right, so we have thread_info in %cr30, but we still seem to be using a vestigial struct thread_struct as well as a struct thread_info (so we don't have all the info at the right level). I'll code user_max_addr as (segment_eq(get_fs(), USER_DS) ? TMP_TASK_SIZE : ~0UL) And do TMP_TASK_SIZE as (test_tsk_thread_flag(tsk,TIF_32BIT) ? DEFAULT_TASK_SIZE_32 : DEFAULT_TASK_SIZE) until we can get this sorted out properly (i.e. by removing task_size from struct thread_struct) James -- 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