On Sat, Feb 09, 2013 at 11:41:42AM +0100, Borislav Petkov wrote:
> On Fri, Feb 08, 2013 at 11:08:52AM -0800, H. Peter Anvin wrote:
> > Yes, or anything else getting a pointer in memory from user space.
>
> Here are some more from a 32-bit build here:
>
> fs/exec.c: In function ‘get_user_arg_ptr’:
On Fri, Feb 08, 2013 at 11:08:52AM -0800, H. Peter Anvin wrote:
> Yes, or anything else getting a pointer in memory from user space.
Here are some more from a 32-bit build here:
fs/exec.c: In function ‘get_user_arg_ptr’:
fs/exec.c:414:6: warning: cast to pointer from integer of different size
[-
Yes, or anything else getting a pointer in memory from user space.
"Ville Syrjälä" wrote:
>On Fri, Feb 08, 2013 at 09:30:05AM -0800, H. Peter Anvin wrote:
>> On 02/08/2013 08:24 AM, Ville Syrjälä wrote:
>> >>
>> >> How have you tested it?
>> >
>> > I've tried it with my drm/kms atomic pageflip/
On Fri, Feb 08, 2013 at 09:30:05AM -0800, H. Peter Anvin wrote:
> On 02/08/2013 08:24 AM, Ville Syrjälä wrote:
> >>
> >> How have you tested it?
> >
> > I've tried it with my drm/kms atomic pageflip/modeset code. I also had
> > a small test module that did a couple of different sized get_user()
>
On 02/08/2013 08:24 AM, Ville Syrjälä wrote:
>>
>> How have you tested it?
>
> I've tried it with my drm/kms atomic pageflip/modeset code. I also had
> a small test module that did a couple of different sized get_user()
> calls, but I'll be damned if I can find it again.
>
Did you see the warnin
On Thu, Feb 07, 2013 at 09:59:00AM -0800, H. Peter Anvin wrote:
> On 02/07/2013 08:53 AM, Ville Syrjälä wrote:
> >
> > Based on the initial response there seems to be some interest towards
> > it at least. So I'm wondering what's the next step. Is it OK as is,
> > or does it need more work, or wou
On 02/07/2013 08:53 AM, Ville Syrjälä wrote:
>
> Based on the initial response there seems to be some interest towards
> it at least. So I'm wondering what's the next step. Is it OK as is,
> or does it need more work, or would people want to extend it to include
> more of the original work?
>
> I
On Wed, Dec 12, 2012 at 01:34:03PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Implement __get_user_8() for x86-32. It will return the
> 64bit result in edx:eax register pair, and ecx is used
> to pass in the address and return the error value.
>
> For consistency, chan
It's a good change -- and one which opens up even more unification -- but right
now we're worried about 3.8.
"Ville Syrjälä" wrote:
>On Wed, Dec 12, 2012 at 08:15:12AM -0800, H. Peter Anvin wrote:
>> Can we worry about this after the merge window?
>
>Sure. The only use I have for this is in my
On Wed, Dec 12, 2012 at 08:15:12AM -0800, H. Peter Anvin wrote:
> Can we worry about this after the merge window?
Sure. The only use I have for this is in my drm/kms atomic
modeset/pageflip patch set, and that's not 3.8 material.
>
> ville.syrj...@linux.intel.com wrote:
>
> >From: Ville Syrjälä
Can we worry about this after the merge window?
ville.syrj...@linux.intel.com wrote:
>From: Ville Syrjälä
>
>Implement __get_user_8() for x86-32. It will return the
>64bit result in edx:eax register pair, and ecx is used
>to pass in the address and return the error value.
>
>For consistency, cha
From: Ville Syrjälä
Implement __get_user_8() for x86-32. It will return the
64bit result in edx:eax register pair, and ecx is used
to pass in the address and return the error value.
For consistency, change the register assignment for all
other __get_user_x() variants, so that address is passed i
12 matches
Mail list logo
