summary of current pending changes in aio-next.git

for you to fetch changes up to 6878ea72a5d1aa6caae86449975a50b7fe9abed5: aio: be defensive to ensure request batching is non-zero instead of BUG_ON() (2013-07-31 10:34:18 -0400) Benjamin LaHaise (4): aio: fix build when

Re: [PATCH] aio: Support read/write with non-iter file-ops

On Thu, Jul 18, 2019 at 04:43:52PM -0700, Bjorn Andersson wrote: > On Thu 18 Jul 16:17 PDT 2019, Al Viro wrote: > > > On Thu, Jul 18, 2019 at 04:10:54PM -0700, Bjorn Andersson wrote: > > > Implement a wrapper for aio_read()/write() to allow async IO on files > > > not implementing the iter

Re: aio poll, io_pgetevents and a new in-kernel poll API V4

l is > added, which atomically saves and restores the signal mask over the > io_pgetevents system call. It it the logical equivalent to pselect and > ppoll for io_pgetevents. That looks useful. I'll have to look at this in detail. -ben commit a299c474b19107122eae846b53f742d876f3

Re: aio poll, io_pgetevents and a new in-kernel poll API V4

l is > added, which atomically saves and restores the signal mask over the > io_pgetevents system call. It it the logical equivalent to pselect and > ppoll for io_pgetevents. That looks useful. I'll have to look at this in detail. -ben commit a299c474b19107122eae846b53f742d87

Re: [PATCH 2/6] move _body_io_syscall to the generic syscall.h

On Fri, Jan 05, 2018 at 11:25:17AM -0500, Jeff Moyer wrote: > Christoph Hellwig writes: > > > This way it can be used for the fallback 6-argument version on > > all architectures. > > > > Signed-off-by: Christoph Hellwig > > This is a strange way to do things.

Re: [PATCH 2/6] move _body_io_syscall to the generic syscall.h

On Fri, Jan 05, 2018 at 11:25:17AM -0500, Jeff Moyer wrote: > Christoph Hellwig writes: > > > This way it can be used for the fallback 6-argument version on > > all architectures. > > > > Signed-off-by: Christoph Hellwig > > This is a strange way to do things. However, I was never really sold

Re: [PATCH 1/1] aio: make sure the input "timeout" value is valid

at an awful interface we have here! > The user must not only fetch it, they must validate it separately? > And if they forget, then userspace is provoking undefined behaviour? Ugh. > Why not this: That looks far better! Acked-by: Benjamin LaHaise <b...@kvack.org>

Re: [PATCH 1/1] aio: make sure the input "timeout" value is valid

at an awful interface we have here! > The user must not only fetch it, they must validate it separately? > And if they forget, then userspace is provoking undefined behaviour? Ugh. > Why not this: That looks far better! Acked-by: Benjamin LaHaise -ben > diff --

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On Wed, Dec 06, 2017 at 09:19:09PM +0300, Kirill Tkhai wrote: > On 06.12.2017 20:44, Benjamin LaHaise wrote: > > On Wed, Dec 06, 2017 at 06:32:56PM +0100, Oleg Nesterov wrote: > >>>> This memory lives in page-cache/lru, it is visible for shrinker which > >>>&g

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On Wed, Dec 06, 2017 at 09:19:09PM +0300, Kirill Tkhai wrote: > On 06.12.2017 20:44, Benjamin LaHaise wrote: > > On Wed, Dec 06, 2017 at 06:32:56PM +0100, Oleg Nesterov wrote: > >>>> This memory lives in page-cache/lru, it is visible for shrinker which > >>>&g

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On Wed, Dec 06, 2017 at 06:32:56PM +0100, Oleg Nesterov wrote: > > > This memory lives in page-cache/lru, it is visible for shrinker which > > > will unmap these pages for no reason on memory shortage. IOW, aio fools > > > the kernel, this memory looks reclaimable but it is not. And we only do > >

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On Wed, Dec 06, 2017 at 06:32:56PM +0100, Oleg Nesterov wrote: > > > This memory lives in page-cache/lru, it is visible for shrinker which > > > will unmap these pages for no reason on memory shortage. IOW, aio fools > > > the kernel, this memory looks reclaimable but it is not. And we only do > >

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On Tue, Dec 05, 2017 at 04:19:56PM +0100, Oleg Nesterov wrote: > On 12/05, Kirill Tkhai wrote: > > > > Currently, aio_nr and aio_max_nr are global. > > Yeah, I too tried to complain 2 years ago... > > > In case of containers this > > means that a single container may occupy all aio requests,

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On Tue, Dec 05, 2017 at 04:19:56PM +0100, Oleg Nesterov wrote: > On 12/05, Kirill Tkhai wrote: > > > > Currently, aio_nr and aio_max_nr are global. > > Yeah, I too tried to complain 2 years ago... > > > In case of containers this > > means that a single container may occupy all aio requests,

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Hi Kirill, On Mon, Dec 04, 2017 at 07:12:51PM +0300, Kirill Tkhai wrote: > Hi, > > this patch set introduces accounting aio_nr and aio_max_nr per blkio cgroup. > It may be used to limit number of aio requests, which are available for > a cgroup, and could be useful for containers. > > The

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Hi Kirill, On Mon, Dec 04, 2017 at 07:12:51PM +0300, Kirill Tkhai wrote: > Hi, > > this patch set introduces accounting aio_nr and aio_max_nr per blkio cgroup. > It may be used to limit number of aio requests, which are available for > a cgroup, and could be useful for containers. > > The

[GIT PULL] aio: improve aio-nr counting

Hello Linus, Please consider pulling the following change for 4.14 to improve aio-nr counting on large SMP systems which has been in linux-next for quite some time. Cheers, -ben The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261: Linux 4.13

[GIT PULL] aio: improve aio-nr counting

Hello Linus, Please consider pulling the following change for 4.14 to improve aio-nr counting on large SMP systems which has been in linux-next for quite some time. Cheers, -ben The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261: Linux 4.13

Re: [PATCH] aio: Add command to wait completion of all requests

On Wed, Jun 14, 2017 at 12:11:38PM +0300, Kirill Tkhai wrote: > On 14.06.2017 02:26, Benjamin LaHaise wrote: ... > > Nope. An aio may not complete in a timely fashion, in which case your > > wait for all aios to complete will simply wait forever. I take it this is > > not

Re: [PATCH] aio: Add command to wait completion of all requests

On Wed, Jun 14, 2017 at 12:11:38PM +0300, Kirill Tkhai wrote: > On 14.06.2017 02:26, Benjamin LaHaise wrote: ... > > Nope. An aio may not complete in a timely fashion, in which case your > > wait for all aios to complete will simply wait forever. I take it this is > > not

Re: [PATCH] aio: Add command to wait completion of all requests

On Tue, Jun 13, 2017 at 07:17:43PM +0300, Kirill Tkhai wrote: > On 13.06.2017 18:26, Benjamin LaHaise wrote: > > On Tue, Jun 13, 2017 at 06:11:03PM +0300, Kirill Tkhai wrote: > > ... > >> The functionality, I did, grew from real need and experience. We try to > >>

Re: [PATCH] aio: Add command to wait completion of all requests

On Tue, Jun 13, 2017 at 07:17:43PM +0300, Kirill Tkhai wrote: > On 13.06.2017 18:26, Benjamin LaHaise wrote: > > On Tue, Jun 13, 2017 at 06:11:03PM +0300, Kirill Tkhai wrote: > > ... > >> The functionality, I did, grew from real need and experience. We try to > >>

Re: [PATCH] aio: Add command to wait completion of all requests

On Tue, Jun 13, 2017 at 06:11:03PM +0300, Kirill Tkhai wrote: ... > The functionality, I did, grew from real need and experience. We try to > avoid kernel modification, where it's possible, but the in-flight aio > requests is not a case suitable for that. What you've done only works for *your*

Re: [PATCH] aio: Add command to wait completion of all requests

On Tue, Jun 13, 2017 at 06:11:03PM +0300, Kirill Tkhai wrote: ... > The functionality, I did, grew from real need and experience. We try to > avoid kernel modification, where it's possible, but the in-flight aio > requests is not a case suitable for that. What you've done only works for *your*

Re: [PATCH] aio: Add command to wait completion of all requests

On Fri, Jun 09, 2017 at 12:49:34PM +0300, Kirill Tkhai wrote: > During implementation aio support for Checkpoint-Restore > in Userspace project (CRIU), we found, that current > kernel functionality does not allow to wait for > completion of all submitted requests. Checkpoint software > can't

Re: [PATCH] aio: Add command to wait completion of all requests

On Fri, Jun 09, 2017 at 12:49:34PM +0300, Kirill Tkhai wrote: > During implementation aio support for Checkpoint-Restore > in Userspace project (CRIU), we found, that current > kernel functionality does not allow to wait for > completion of all submitted requests. Checkpoint software > can't

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

On Wed, Oct 05, 2016 at 02:58:12PM -0300, Mauricio Faria de Oliveira wrote: > Hi Benjamin, > > On 10/05/2016 02:41 PM, Benjamin LaHaise wrote: > >I'd suggest increasing the default limit by changing how it is calculated. > >The current number came about 13 years ago whe

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

On Wed, Oct 05, 2016 at 02:58:12PM -0300, Mauricio Faria de Oliveira wrote: > Hi Benjamin, > > On 10/05/2016 02:41 PM, Benjamin LaHaise wrote: > >I'd suggest increasing the default limit by changing how it is calculated. > >The current number came about 13 years ago whe

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

On Tue, Oct 04, 2016 at 07:55:12PM -0300, Mauricio Faria de Oliveira wrote: > Hi Benjamin, Kent, and others, > > Would you please comment / answer about this possible problem? > Any feedback is appreciated. I'd suggest increasing the default limit by changing how it is calculated. The current

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

On Tue, Oct 04, 2016 at 07:55:12PM -0300, Mauricio Faria de Oliveira wrote: > Hi Benjamin, Kent, and others, > > Would you please comment / answer about this possible problem? > Any feedback is appreciated. I'd suggest increasing the default limit by changing how it is calculated. The current

Re: linux-next: build failure after merge of the aio tree

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.

Re: linux-next: build failure after merge of the aio tree

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.

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: manual merge of the aio tree with the vfs tree

On Tue, Mar 15, 2016 at 05:35:33AM +, Al Viro wrote: > On Mon, Mar 14, 2016 at 11:24:38AM -0400, Benjamin LaHaise wrote: > > On Mon, Mar 14, 2016 at 08:35:23AM +0100, Christoph Hellwig wrote: > > > The aio changes have either been reviewed negatively or not at all. That

Re: linux-next: manual merge of the aio tree with the vfs tree

On Tue, Mar 15, 2016 at 05:35:33AM +, Al Viro wrote: > On Mon, Mar 14, 2016 at 11:24:38AM -0400, Benjamin LaHaise wrote: > > On Mon, Mar 14, 2016 at 08:35:23AM +0100, Christoph Hellwig wrote: > > > The aio changes have either been reviewed negatively or not at all. That

Re: linux-next: manual merge of the aio tree with the vfs tree

On Tue, Mar 15, 2016 at 05:19:39AM +, Al Viro wrote: > On Tue, Mar 15, 2016 at 05:07:12AM +, Al Viro wrote: > > > There *is* a reason for code review. Or, at least, asking somebody familiar > > with the code you are working with whether some assumption you are making > > is true or

Re: linux-next: manual merge of the aio tree with the vfs tree

On Tue, Mar 15, 2016 at 05:19:39AM +, Al Viro wrote: > On Tue, Mar 15, 2016 at 05:07:12AM +, Al Viro wrote: > > > There *is* a reason for code review. Or, at least, asking somebody familiar > > with the code you are working with whether some assumption you are making > > is true or

aio openat Re: [PATCH 07/13] aio: enabled thread based async fsync

e now." fs/aio.c | 122 +- fs/internal.h |1 fs/namei.c| 16 -- fs/open.c |2 include/linux/namei.h |1 5 files changed, 117 insertions(+), 25 deletions(-) commit 5d3d80fcf99287decc4774af0

aio openat Re: [PATCH 07/13] aio: enabled thread based async fsync

e now." fs/aio.c | 122 +- fs/internal.h |1 fs/namei.c| 16 -- fs/open.c |2 include/linux/namei.h |1 5 files changed, 117 insertions(+), 25 deletions(-) commit 5d3d80fcf99287decc4774af0196

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: build failure after merge of the aio tree

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

Re: [PATCH] x86_32: add support for 64 bit __get_user() v3

Any more comments/feedback on this? Can this be merged for 4.6? -ben On Wed, Mar 09, 2016 at 03:05:56PM -0500, Benjamin LaHaise wrote: > The existing __get_user() implementation does not support fetching > 64 bit values on 32 bit x86. Implement this in a way tha

Re: [PATCH] x86_32: add support for 64 bit __get_user() v3

Any more comments/feedback on this? Can this be merged for 4.6? -ben On Wed, Mar 09, 2016 at 03:05:56PM -0500, Benjamin LaHaise wrote: > The existing __get_user() implementation does not support fetching > 64 bit values on 32 bit x86. Implement this in a way tha

Re: linux-next: manual merge of the aio tree with the vfs tree

On Mon, Mar 14, 2016 at 08:35:23AM +0100, Christoph Hellwig wrote: > The aio changes have either been reviewed negatively or not at all. That > tree should be dropped. That isn't solely your decision. If you have comments, please provide constructive feedback, as there are users and use-cases

Re: linux-next: manual merge of the aio tree with the vfs tree

On Mon, Mar 14, 2016 at 08:35:23AM +0100, Christoph Hellwig wrote: > The aio changes have either been reviewed negatively or not at all. That > tree should be dropped. That isn't solely your decision. If you have comments, please provide constructive feedback, as there are users and use-cases

[PATCH] x86_32: add support for 64 bit __get_user() v3

() as suggested by H. Peter Anvin, which cleans the code up nicely, and fix things to work on x86_64 as well. v3: fix undefined behaviour on 32 bit x86 caused by multiple expansion of ptr in the 64 bit case. Signed-off-by: Benjamin LaHaise <b...@kvack.org> diff --git a/arch/x86/include/asm/uacce

[PATCH] x86_32: add support for 64 bit __get_user() v3

() as suggested by H. Peter Anvin, which cleans the code up nicely, and fix things to work on x86_64 as well. v3: fix undefined behaviour on 32 bit x86 caused by multiple expansion of ptr in the 64 bit case. Signed-off-by: Benjamin LaHaise diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include

[PATCH] x86_32: add support for 64 bit __get_user() v2

() as suggested by H. Peter Anvin, which cleans the code up nicely, and fix things to work on x86_64 as well. Tested on both 32 bit and 64 bit x86. Signed-off-by: Benjamin LaHaise <b...@kvack.org> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h index a4a30e4..1284da2

[PATCH] x86_32: add support for 64 bit __get_user() v2

() as suggested by H. Peter Anvin, which cleans the code up nicely, and fix things to work on x86_64 as well. Tested on both 32 bit and 64 bit x86. Signed-off-by: Benjamin LaHaise diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h index a4a30e4..1284da2 100644 --- a/arch/x86

Re: [PATCH] x86_32: add support for 64 bit __get_user()

On Wed, Mar 09, 2016 at 10:22:50AM -0800, H. Peter Anvin wrote: > On 03/09/2016 09:50 AM, Benjamin LaHaise wrote: > > On Wed, Mar 09, 2016 at 09:36:30AM -0800, H. Peter Anvin wrote: > >> On March 9, 2016 9:22:25 AM PST, Benjamin LaHaise <b...@kvack.org> wrote: >

Re: [PATCH] x86_32: add support for 64 bit __get_user()

On Wed, Mar 09, 2016 at 10:22:50AM -0800, H. Peter Anvin wrote: > On 03/09/2016 09:50 AM, Benjamin LaHaise wrote: > > On Wed, Mar 09, 2016 at 09:36:30AM -0800, H. Peter Anvin wrote: > >> On March 9, 2016 9:22:25 AM PST, Benjamin LaHaise wrote: > >>> The existing __

Re: [PATCH] x86_32: add support for 64 bit __get_user()

On Wed, Mar 09, 2016 at 09:36:30AM -0800, H. Peter Anvin wrote: > On March 9, 2016 9:22:25 AM PST, Benjamin LaHaise <b...@kvack.org> wrote: > >The existing __get_user() implementation does not support fetching > >64 bit values on 32 bit x86. Implement this in a way that does

Re: [PATCH] x86_32: add support for 64 bit __get_user()

On Wed, Mar 09, 2016 at 09:36:30AM -0800, H. Peter Anvin wrote: > On March 9, 2016 9:22:25 AM PST, Benjamin LaHaise wrote: > >The existing __get_user() implementation does not support fetching > >64 bit values on 32 bit x86. Implement this in a way that does not > >g

[PATCH] x86_32: add support for 64 bit __get_user()

The existing __get_user() implementation does not support fetching 64 bit values on 32 bit x86. Implement this in a way that does not generate any incorrect warnings as cautioned by Russell King. Test code available at http://www.kvack.org/~bcrl/x86_32-get_user.tar . Signed-off-by: Benjamin

[PATCH] x86_32: add support for 64 bit __get_user()

The existing __get_user() implementation does not support fetching 64 bit values on 32 bit x86. Implement this in a way that does not generate any incorrect warnings as cautioned by Russell King. Test code available at http://www.kvack.org/~bcrl/x86_32-get_user.tar . Signed-off-by: Benjamin

Re: linux-next: Tree for Feb 24

On Wed, Feb 24, 2016 at 07:32:17AM +0100, Sedat Dilek wrote: > On Wed, Feb 24, 2016 at 6:34 AM, Stephen Rothwell > wrote: > > Hi all, > > > > Changes since 20160223: > > > ... > > The aio tree still had a build failure so I used the version from > > next-20160111. > > > >

Re: linux-next: Tree for Feb 24

On Wed, Feb 24, 2016 at 07:32:17AM +0100, Sedat Dilek wrote: > On Wed, Feb 24, 2016 at 6:34 AM, Stephen Rothwell > wrote: > > Hi all, > > > > Changes since 20160223: > > > ... > > The aio tree still had a build failure so I used the version from > > next-20160111. > > > > Might be good to poke

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: build failure after merge of the aio tree

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)\ > ({

Re: linux-next: build failure after merge of the aio tree

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: > > > &g

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: build failure after merge of the aio tree

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)\ > ({

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: build failure after merge of the aio tree

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: > > > &g

Re: linux-next: build failure after merge of the aio tree

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

Re: linux-next: build failure after merge of the aio tree

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

Re: [mm -next] mapping->tree_lock inconsistent lock state

On Wed, Feb 03, 2016 at 01:45:09PM -0500, Johannes Weiner wrote: > On Thu, Feb 04, 2016 at 12:36:33AM +0900, Sergey Senozhatsky wrote: > > Hello, > > > > next-20160203 > > > > [ 3587.997451] = > > [ 3587.997453] [ INFO: inconsistent lock state ] > > [ 3587.997456]

Re: [mm -next] mapping->tree_lock inconsistent lock state

On Wed, Feb 03, 2016 at 01:45:09PM -0500, Johannes Weiner wrote: > On Thu, Feb 04, 2016 at 12:36:33AM +0900, Sergey Senozhatsky wrote: > > Hello, > > > > next-20160203 > > > > [ 3587.997451] = > > [ 3587.997453] [ INFO: inconsistent lock state ] > > [ 3587.997456]

Re: [PATCH 07/13] aio: enabled thread based async fsync

On Sat, Jan 23, 2016 at 03:24:49PM +1100, Dave Chinner wrote: > On Wed, Jan 20, 2016 at 04:56:30PM -0500, Benjamin LaHaise wrote: > > On Thu, Jan 21, 2016 at 08:45:46AM +1100, Dave Chinner wrote: > > > Filesystems *must take locks* in the IO path. We have to serialise >

Re: [PATCH -next] aio: Fix compile error due to unexpected use of cmpxchg()

:1: error: cast specifies function type > Fixes: 6a81013efc40 ("aio: add support for IOCB_CMD_POLL via aio thread > helper") Ah, I was wondering if there was an easy way to fix this bug. Applied -- thanks! -ben > Cc: Benjamin LaHaise > Signed-o

Re: [PATCH -next] aio: Fix compile error due to unexpected use of cmpxchg()

:1: error: cast specifies function type > Fixes: 6a81013efc40 ("aio: add support for IOCB_CMD_POLL via aio thread > helper") Ah, I was wondering if there was an easy way to fix this bug. Applied -- thanks! -ben > Cc: Benjamin LaHaise <b...@kvack.org> >

Re: [PATCH 07/13] aio: enabled thread based async fsync

On Sat, Jan 23, 2016 at 03:24:49PM +1100, Dave Chinner wrote: > On Wed, Jan 20, 2016 at 04:56:30PM -0500, Benjamin LaHaise wrote: > > On Thu, Jan 21, 2016 at 08:45:46AM +1100, Dave Chinner wrote: > > > Filesystems *must take locks* in the IO path. We have to serialise >

Re: [PATCH 07/13] aio: enabled thread based async fsync

On Thu, Jan 21, 2016 at 08:45:46AM +1100, Dave Chinner wrote: > Filesystems *must take locks* in the IO path. We have to serialise > against truncate and other operations at some point in the IO path > (e.g. block mapping vs concurrent allocation and/or removal), and > that can only be done sanely

Re: [PATCH 07/13] aio: enabled thread based async fsync

On Wed, Jan 20, 2016 at 12:29:32PM -0800, Linus Torvalds wrote: > On Wed, Jan 20, 2016 at 11:59 AM, Dave Chinner wrote: > >> > >> Are there other users outside of Solace? It would be good to get comments.. > > > > I know of quite a few storage/db products that use AIO. The most > > recent high

Re: [PATCH 07/13] aio: enabled thread based async fsync

On Wed, Jan 20, 2016 at 12:29:32PM -0800, Linus Torvalds wrote: > On Wed, Jan 20, 2016 at 11:59 AM, Dave Chinner wrote: > >> > >> Are there other users outside of Solace? It would be good to get comments.. > > > > I know of quite a few storage/db products that use AIO. The

Re: [PATCH 07/13] aio: enabled thread based async fsync

On Thu, Jan 21, 2016 at 08:45:46AM +1100, Dave Chinner wrote: > Filesystems *must take locks* in the IO path. We have to serialise > against truncate and other operations at some point in the IO path > (e.g. block mapping vs concurrent allocation and/or removal), and > that can only be done sanely

Re: int overflow in io_getevents

its, and that negative or other invalid values fail with EINVAL (download from http://www.kvack.org/~bcrl/aio-io_getevents-timespec.c ). -ben -- "Thought is the essence of where you are now." commit 49b78150bc5762c58cfb8b19a859c354cf1a71ac Author: Benjamin LaHaise Date: Th

Re: int overflow in io_getevents

ess my concerns. Updated commit below. -ben -- "Thought is the essence of where you are now." commit 3a55c535cf3836257434518bd6bc11464c493492 Author: Benjamin LaHaise Date: Thu Jan 7 10:25:44 2016 -0500 aio: handle integer overflow in io_getevents() timespec usage

Re: int overflow in io_getevents

ess my concerns. Updated commit below. -ben -- "Thought is the essence of where you are now." commit 3a55c535cf3836257434518bd6bc11464c493492 Author: Benjamin LaHaise <b...@kvack.org> Date: Thu Jan 7 10:25:44 2016 -0500 aio: handle integer overflow in io_gete

Re: int overflow in io_getevents

its, and that negative or other invalid values fail with EINVAL (download from http://www.kvack.org/~bcrl/aio-io_getevents-timespec.c ). -ben -- "Thought is the essence of where you are now." commit 49b78150bc5762c58cfb8b19a859c354cf1a71ac Author: Benjamin LaHaise <b...

Re: int overflow in io_getevents

ns. -ben -- "Thought is the essence of where you are now." commit 4304367826d0df42086ef24428c6c277acd822a9 Author: Benjamin LaHaise Date: Wed Jan 6 12:46:12 2016 -0500 aio: handle integer overflow in io_getevents() timespec usage Dmitry Vyukov reported an integer overflow in io_getevents()

Re: int overflow in io_getevents

ns. -ben -- "Thought is the essence of where you are now." commit 4304367826d0df42086ef24428c6c277acd822a9 Author: Benjamin LaHaise <b...@kvack.org> Date: Wed Jan 6 12:46:12 2016 -0500 aio: handle integer overflow in io_getevents() timespec usage Dmitry Vyukov reported an int

Re: use-after-free in sock_wake_async

On Tue, Nov 24, 2015 at 04:30:01PM -0500, Jason Baron wrote: > So looking at this trace I think its the other->sk_socket that gets > freed and then we call sk_wake_async() on it. > > We could I think grab the socket reference there with unix_state_lock(), > since that is held by

Re: use-after-free in sock_wake_async

On Tue, Nov 24, 2015 at 04:30:01PM -0500, Jason Baron wrote: > So looking at this trace I think its the other->sk_socket that gets > freed and then we call sk_wake_async() on it. > > We could I think grab the socket reference there with unix_state_lock(), > since that is held by

Re: [PATCH] aio: Add few code style fixes

On Wed, Nov 11, 2015 at 11:28:08PM +0800, 刘长冬 wrote: > >From 1609d68dee344925d182631922cd98790109588b Mon Sep 17 00:00:00 2001 > From: Liu Changdong > Date: Tue, 10 Nov 2015 00:04:18 +0800 > Subject: [PATCH] aio: Add few code style fixes > > Add a blank line after declarations > >

Re: [PATCH] aio: Add few code style fixes

On Wed, Nov 11, 2015 at 11:28:08PM +0800, 刘长冬 wrote: > >From 1609d68dee344925d182631922cd98790109588b Mon Sep 17 00:00:00 2001 > From: Liu Changdong > Date: Tue, 10 Nov 2015 00:04:18 +0800 > Subject: [PATCH] aio: Add few code style fixes > > Add a blank line after

Re: [PATCH v2] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix

On Tue, Jul 21, 2015 at 05:29:03PM +0200, Oleg Nesterov wrote: > Andrew, > > this replaces > > mm-move-mremap-from-file_operations-to-vm_operations_struct-fix.patch > > in -mm tree nacked by Benjamin. > > fs/aio.c can't be compiled if CONFIG_MMU=n, filemap_page_mkwrite() is > not defined

Re: [PATCH v2] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix

On Tue, Jul 21, 2015 at 05:29:03PM +0200, Oleg Nesterov wrote: Andrew, this replaces mm-move-mremap-from-file_operations-to-vm_operations_struct-fix.patch in -mm tree nacked by Benjamin. fs/aio.c can't be compiled if CONFIG_MMU=n, filemap_page_mkwrite() is not defined in this

Re: [PATCH] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix

On Mon, Jul 20, 2015 at 09:24:40PM +0200, Oleg Nesterov wrote: > On 07/20, Oleg Nesterov wrote: > > > > But again, again, please ignore. This all is off-topic and my understanding > > is very limited. > > Yes, yes, but sorry for noise and let me repeat... > > This memory lives in page-cache/lru,

Re: [PATCH] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix

On Mon, Jul 20, 2015 at 07:33:11PM +0200, Oleg Nesterov wrote: > Hi Jeff, > > On 07/20, Jeff Moyer wrote: > > > > Hi, Oleg, > > > > Oleg Nesterov writes: > > > > > Shouldn't we account aio events/pages somehow, say per-user, or in > > > mm->pinned_vm ? > > > > Ages ago I wrote a patch to account

Re: [PATCH] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix

On Mon, Jul 20, 2015 at 07:33:11PM +0200, Oleg Nesterov wrote: Hi Jeff, On 07/20, Jeff Moyer wrote: Hi, Oleg, Oleg Nesterov o...@redhat.com writes: Shouldn't we account aio events/pages somehow, say per-user, or in mm-pinned_vm ? Ages ago I wrote a patch to account the

Re: [PATCH] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix

On Mon, Jul 20, 2015 at 09:24:40PM +0200, Oleg Nesterov wrote: On 07/20, Oleg Nesterov wrote: But again, again, please ignore. This all is off-topic and my understanding is very limited. Yes, yes, but sorry for noise and let me repeat... This memory lives in page-cache/lru, it is

Re: [PATCH] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix

On Fri, Jul 17, 2015 at 07:27:26PM +0200, Oleg Nesterov wrote: > Benjamin, > > it seems that we do not understand each other, ... > > > > Either try to fix it correctly, > > And I think this fix is correct. In a sense that we only add > filemap_page_mkwrite() to make the linker happy, it can

Re: [PATCH] mm-move-mremap-from-file_operations-to-vm_operations_struct-fix

On Fri, Jul 17, 2015 at 01:52:28AM +0200, Oleg Nesterov wrote: > On 07/16, Andrew Morton wrote: > > > > On Fri, 17 Jul 2015 01:14:05 +0200 Oleg Nesterov wrote: > > > > > fs/aio.c can't be compiled if CONFIG_MMU=n, filemap_page_mkwrite() > > > is not defined in this case. Add yet another "must not

  1   2   3   4   5   6   7   >