On Wed, Mar 16, 2016 at 02:59:38PM +0100, Arnd Bergmann wrote:
> On Wednesday 16 March 2016 13:12:36 Andy Shevchenko wrote:
> >
> > > I've also sent a patch that fixes the link error on ARM and that should
> > > work on all other architectures too.
> >
> > In case of avr32 signalfd_read() fails.
On Wednesday 16 March 2016 13:12:36 Andy Shevchenko wrote:
>
> > I've also sent a patch that fixes the link error on ARM and that should
> > work on all other architectures too.
>
> In case of avr32 signalfd_read() fails. Does your patch help with it as well?
>
> P.S. Bisecting shows same culpri
On Wed, Mar 16, 2016 at 12:02 AM, Arnd Bergmann wrote:
> On Tuesday 15 March 2016 12:22:28 Benjamin LaHaise wrote:
>> On Tue, Mar 15, 2016 at 04:19:02PM +, Sudip Mukherjee wrote:
>> > On Tue, Mar 15, 2016 at 05:46:34PM +1100, Stephen Rothwell wrote:
>> > > Hi Benjamin,
>> > >
>> > > After merg
On Tuesday 15 March 2016 12:22:28 Benjamin LaHaise wrote:
> On Tue, Mar 15, 2016 at 04:19:02PM +, Sudip Mukherjee wrote:
> > On Tue, Mar 15, 2016 at 05:46:34PM +1100, Stephen Rothwell wrote:
> > > Hi Benjamin,
> > >
> > > After merging the aio tree, today's linux-next build (powerpc
> > > ppc4
On Tuesday 15 March 2016 16:38:51 Andy Shevchenko wrote:
> On Tue, Mar 15, 2016 at 8:46 AM, Stephen Rothwell
> wrote:
> > Hi Benjamin,
> >
> > After merging the aio tree, today's linux-next build (powerpc
> > ppc44x_defconfig) failed like this:
> >
> > fs/built-in.o: In function `aio_thread_op_fo
On Tue, Mar 15, 2016 at 04:19:02PM +, Sudip Mukherjee wrote:
> On Tue, Mar 15, 2016 at 05:46:34PM +1100, Stephen Rothwell wrote:
> > Hi Benjamin,
> >
> > After merging the aio tree, today's linux-next build (powerpc
> > ppc44x_defconfig) failed like this:
> >
> > fs/built-in.o: In function `a
On Tue, Mar 15, 2016 at 05:46:34PM +1100, Stephen Rothwell wrote:
> Hi Benjamin,
>
> After merging the aio tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> fs/built-in.o: In function `aio_thread_op_foo_at':
> aio.c:(.text+0x4dab4): undefined reference to `__get_us
On Tue, Mar 15, 2016 at 8:46 AM, Stephen Rothwell wrote:
> Hi Benjamin,
>
> After merging the aio tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> fs/built-in.o: In function `aio_thread_op_foo_at':
> aio.c:(.text+0x4dab4): undefined reference to `__get_user_bad'
>
Hi Benjamin,
After merging the aio tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
fs/built-in.o: In function `aio_thread_op_foo_at':
aio.c:(.text+0x4dab4): undefined reference to `__get_user_bad'
aio.c:(.text+0x4daec): undefined reference to `__get_user_bad'
Caused b
Hi Ben,
On Mon, 14 Mar 2016 13:08:07 -0400 Benjamin LaHaise wrote:
>
> I put in a patch to use get_user() for now since the 32 bit architectures
> don't seem to have any plans for fixing this issue in a predictable
> timeframe. There shouldn't be any build failures now -- I've checked ia64,
>
On Mon, Mar 14, 2016 at 03:49:15PM +1100, Stephen Rothwell wrote:
> Hi Ben,
...
> OK, so at this point (just to get rid of the build failure I have done this:
...
> Well, you need to negotiate that with the affected architectures.
I put in a patch to use get_user() for now since the 32 bit archit
Hi Ben,
On Sat, 16 Jan 2016 09:55:15 +1100 Stephen Rothwell
wrote:
>
> On Fri, 15 Jan 2016 10:18:21 -0500 Benjamin LaHaise wrote:
> >
> > On Fri, Jan 15, 2016 at 01:25:31AM -0800, Christoph Hellwig wrote:
> > > On Fri, Jan 15, 2016 at 08:23:16PM +1100, Stephen Rothwell wrote:
> > > > Via
On Thu, Feb 04, 2016 at 04:17:42PM +, Russell King - ARM Linux wrote:
> __gu_val will be 32-bit, even when you're wanting a 64-bit quantity.
> That's where the fun and games start...
Okay, I figured out how to do it: instead of using a 64 bit unsigned long
long for __gu_val, use an array of 2
On Thu, Feb 04, 2016 at 04:17:42PM +, Russell King - ARM Linux wrote:
> That's the easy bit!
>
> The problem you're going to run into is here:
>
> #define __get_user_nocheck(x, ptr, size)\
> ({
On Thu, Feb 04, 2016 at 04:17:42PM +, Russell King - ARM Linux wrote:
> On Thu, Feb 04, 2016 at 11:01:01AM -0500, Benjamin LaHaise wrote:
> > On Thu, Feb 04, 2016 at 02:39:07PM +, Russell King - ARM Linux wrote:
> > > However, this one should warn:
> > >
> > > int test_wrong(char **v, cons
On Thu, Feb 04, 2016 at 11:01:01AM -0500, Benjamin LaHaise wrote:
> On Thu, Feb 04, 2016 at 02:39:07PM +, Russell King - ARM Linux wrote:
> > However, this one should warn:
> >
> > int test_wrong(char **v, const char **p)
> > { return __get_user(*v, p); }
> >
> > Good luck (I think you'll nee
On Thu, Feb 04, 2016 at 02:39:07PM +, Russell King - ARM Linux wrote:
> However, this one should warn:
>
> int test_wrong(char **v, const char **p)
> { return __get_user(*v, p); }
>
> Good luck (I think you'll need lots of it to get a working solution)! :)
This works with your test cases on
On Thu, Feb 04, 2016 at 09:32:04AM -0500, Benjamin LaHaise wrote:
> On Thu, Feb 04, 2016 at 02:12:53PM +, Russell King - ARM Linux wrote:
> > Hence, __get_user() on x86-32 with a 64-bit quantity results in
> > __get_user_bad() being called, which is an undefined function.
> > Only if you build
On Thu, Feb 04, 2016 at 02:12:53PM +, Russell King - ARM Linux wrote:
> Hence, __get_user() on x86-32 with a 64-bit quantity results in
> __get_user_bad() being called, which is an undefined function.
> Only if you build with x86-64 support enabled (iow, CONFIG_X86_32 not
> defined) then you ge
On Thu, Feb 04, 2016 at 09:08:22AM -0500, Benjamin LaHaise wrote:
> On Thu, Feb 04, 2016 at 01:50:56PM +, Russell King - ARM Linux wrote:
> > > I am still convinced that this is an architecture issue. Given that 64
> > > bit
> > > values work in the *get_user implementations on other archite
On Thu, Feb 04, 2016 at 01:50:56PM +, Russell King - ARM Linux wrote:
> > I am still convinced that this is an architecture issue. Given that 64 bit
> > values work in the *get_user implementations on other architectures, I see
> > no reason there should need to be a workaround for this in c
On Thu, Feb 04, 2016 at 08:41:42AM -0500, Benjamin LaHaise wrote:
> On Thu, Feb 04, 2016 at 01:19:59PM +1100, Stephen Rothwell wrote:
> > Hi Benjamin,
> >
> > On Fri, 29 Jan 2016 13:03:39 +0100 Geert Uytterhoeven
> > wrote:
> > >
> > > On Fri, Jan 29, 2016 at 12:30 PM, Russell King - ARM Linux
>
On Thu, Feb 04, 2016 at 01:19:59PM +1100, Stephen Rothwell wrote:
> Hi Benjamin,
>
> On Fri, 29 Jan 2016 13:03:39 +0100 Geert Uytterhoeven
> wrote:
> >
> > On Fri, Jan 29, 2016 at 12:30 PM, Russell King - ARM Linux
> > wrote:
> > >> Background: new aio code is adding __get_user() calls referenc
Hi Benjamin,
On Fri, 29 Jan 2016 13:03:39 +0100 Geert Uytterhoeven
wrote:
>
> On Fri, Jan 29, 2016 at 12:30 PM, Russell King - ARM Linux
> wrote:
> >> Background: new aio code is adding __get_user() calls referencing 64
> >> bit quantities (__u64 and __s64).
> >
> > There's lots more architec
On Fri, Jan 29, 2016 at 12:30 PM, Russell King - ARM Linux
wrote:
>> Background: new aio code is adding __get_user() calls referencing 64
>> bit quantities (__u64 and __s64).
>
> There's lots more architectures which do not support 64-bit get_user()
> _or_ __get_user(): avr32, blackfin, metag for
On Wed, Jan 27, 2016 at 01:40:24PM +1100, Stephen Rothwell wrote:
> Hi Benjamin,
>
> On Tue, 12 Jan 2016 11:38:35 -0500 Benjamin LaHaise wrote:
> >
> > On Tue, Jan 12, 2016 at 04:40:34PM +1100, Stephen Rothwell wrote:
> > >
> > > After merging the aio tree, today's linux-next build (arm
> > > mu
Hi Benjamin,
On Tue, 12 Jan 2016 11:38:35 -0500 Benjamin LaHaise wrote:
>
> On Tue, Jan 12, 2016 at 04:40:34PM +1100, Stephen Rothwell wrote:
> >
> > After merging the aio tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > fs/built-in.o: In function `aio_threa
On Fri, Aug 30, 2013 at 12:55 AM, Stephen Rothwell
wrote:
> - aio_ring_file->f_path.dentry->d_count,
> + aio_ring_file->f_path.dentry->d_lockref.count,
This is wrong. If you really want the dentry count (which I doubt, I
don't see why this code would c
On Fri, Aug 30, 2013 at 10:38:25AM -0700, Linus Torvalds wrote:
> On Fri, Aug 30, 2013 at 12:55 AM, Stephen Rothwell
> wrote:
> > - aio_ring_file->f_path.dentry->d_count,
> > + aio_ring_file->f_path.dentry->d_lockref.count,
>
> This is wrong. If you re
Hi Stephen,
On Fri, Aug 30, 2013 at 05:55:09PM +1000, Stephen Rothwell wrote:
> Hi Benjamin,
>
> After merging the aio tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/kernel.h:13:0,
> from fs/aio.c:13:
> fs/aio
Hi Benjamin,
After merging the aio tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/linux/kernel.h:13:0,
from fs/aio.c:13:
fs/aio.c: In function 'aio_free_ring':
fs/aio.c:188:32: error: 'struct dentry' has no member named 'd
Hi Dave,
On Wed, 21 Aug 2013 10:52:27 -0500 Dave Kleikamp
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> There's another problem after the merge. Now that buf is passed into
> aio_run_iocb(), ki_iter is no longer needed. It's not getting
> initialized and causes an oops.
>
> Si
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephen,
There's another problem after the merge. Now that buf is passed into
aio_run_iocb(), ki_iter is no longer needed. It's not getting
initialized and causes an oops.
Signed-off-by: Dave Kleikamp
- ---
fs/aio.c| 4 ++--
include/lin
Hi Benjamin,
After merging the aio tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/aio.c: In function 'aio_kernel_init_rw':
fs/aio.c:1359:6: error: 'struct kiocb' has no member named 'ki_left'
iocb->ki_left = nr;
^
fs/aio.c: In function 'aio_kernel_submit':
f
34 matches
Mail list logo
