[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20368.1311761379@redhat.com>
Date: Wed, 27 Jul 2011 11:09:39 +0100
From: David Howells <dhowells@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: dhowells@...hat.com,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Mike Frysinger <vapier.adi@...il.com>,
Shan Hai <haishan.bai@...il.com>, paulus@...ba.org,
tglx@...utronix.de, walken@...gle.com, cmetcalf@...era.com,
tony.luck@...el.com, akpm@...ux-foundation.org,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
uclinux-dist-devel@...ckfin.uclinux.org
Subject: Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
Peter Zijlstra <peterz@...radead.org> wrote:
> > What should nommu do anyways ? it's not like there's much it can do
> > right ? It should never even hit the fault path to start with ...
>
> Something like the below makes a nommu arm config build.. David, is this
> indeed the correct thing to do for nommu?
>
> ---
> Index: linux-2.6/mm/nommu.c
> ===================================================================
> --- linux-2.6.orig/mm/nommu.c
> +++ linux-2.6/mm/nommu.c
> @@ -190,6 +190,12 @@ int get_user_pages(struct task_struct *t
> }
> EXPORT_SYMBOL(get_user_pages);
>
> +int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
> + unsigned long address, unsigned int fault_flags)
> +{
> + BUG(); /* nommu should never call this */
> +}
> +
> /**
> * follow_pfn - look up PFN at a user virtual address
> * @vma: memory mapping
Or perhaps send SEGV? Can 'address' be bad at this point?
Can you inline this for the NOMMU case please?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists