On Wed, 26 Mar 2014, ty...@mit.edu wrote:
> But that's another new user of GFP_NOFAIL (and one added three years
> after David tried to declare There Shalt Be No New Users of
> GFP_NOFAIL), and sure, we could probably patch around that by having
> places where there's no other alternaive to keep
On Tue, Mar 25, 2014 at 11:32:09PM -0700, Andrew Morton wrote:
> Well, there are always alternatives. For example ext3 could
> preallocate a single transaction_t and a single IO page and fall back
> to synchronous page-at-a-time journal writes. But I can totally see
> that such things are
On Wed, 26 Mar 2014 02:19:04 -0400 ty...@mit.edu wrote:
> On Tue, Mar 25, 2014 at 06:06:17PM -0700, David Rientjes wrote:
> >
> > The point is not to add new callers and new code should handle NULL
> > correctly, not that we should run around changing current users to just do
> > infinite
On Tue, Mar 25, 2014 at 06:06:17PM -0700, David Rientjes wrote:
>
> The point is not to add new callers and new code should handle NULL
> correctly, not that we should run around changing current users to just do
> infinite retries. Checkpatch should have nothing to do with that.
My problem
On Tue, Mar 25, 2014 at 06:06:17PM -0700, David Rientjes wrote:
The point is not to add new callers and new code should handle NULL
correctly, not that we should run around changing current users to just do
infinite retries. Checkpatch should have nothing to do with that.
My problem with
On Wed, 26 Mar 2014 02:19:04 -0400 ty...@mit.edu wrote:
On Tue, Mar 25, 2014 at 06:06:17PM -0700, David Rientjes wrote:
The point is not to add new callers and new code should handle NULL
correctly, not that we should run around changing current users to just do
infinite retries.
On Tue, Mar 25, 2014 at 11:32:09PM -0700, Andrew Morton wrote:
Well, there are always alternatives. For example ext3 could
preallocate a single transaction_t and a single IO page and fall back
to synchronous page-at-a-time journal writes. But I can totally see
that such things are
On Wed, 26 Mar 2014, ty...@mit.edu wrote:
But that's another new user of GFP_NOFAIL (and one added three years
after David tried to declare There Shalt Be No New Users of
GFP_NOFAIL), and sure, we could probably patch around that by having
places where there's no other alternaive to keep a
On Sat, 22 Mar 2014, Joe Perches wrote:
> How about just changing this message to something like:
>
> WARN("__GFP_NOFAIL",
>"Use of __GFP_NOFAIL may cause the OOM handler to
> kill a random process\n" . $herecurr);
Because it doesn't, the
On Sat, 22 Mar 2014, Dave Jones wrote:
> On Sat, Mar 22, 2014 at 10:55:24AM -0700, Andrew Morton wrote:
> > On Sat, 22 Mar 2014 13:32:07 -0400 ty...@mit.edu wrote:
> >
> > > On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
> > > > > Well. Converting an existing retry-for-ever
On Sat, 22 Mar 2014, Dave Jones wrote:
On Sat, Mar 22, 2014 at 10:55:24AM -0700, Andrew Morton wrote:
On Sat, 22 Mar 2014 13:32:07 -0400 ty...@mit.edu wrote:
On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
Well. Converting an existing retry-for-ever caller to
On Sat, 22 Mar 2014, Joe Perches wrote:
How about just changing this message to something like:
WARN(__GFP_NOFAIL,
Use of __GFP_NOFAIL may cause the OOM handler to
kill a random process\n . $herecurr);
Because it doesn't, the GFP_NOFS
> The whole point of __GFP_NOFAIL is to centralise this
> wait-for-memory-for-ever operation. So it is implemented in a common
> (core) place and so that we can easily locate these problematic
> callers.
For reiserfs I'm not sure it's worth bothering. If you get an out of
memory or disk caused
The whole point of __GFP_NOFAIL is to centralise this
wait-for-memory-for-ever operation. So it is implemented in a common
(core) place and so that we can easily locate these problematic
callers.
For reiserfs I'm not sure it's worth bothering. If you get an out of
memory or disk caused block
On Sat, 22 Mar 2014 10:55:24 -0700
Andrew Morton wrote:
> On Sat, 22 Mar 2014 13:32:07 -0400 ty...@mit.edu wrote:
>
> > On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
> > > > Well. Converting an existing retry-for-ever caller to GFP_NOFAIL is
> > > > good. Adding new
On Sat, Mar 22, 2014 at 10:55:24AM -0700, Andrew Morton wrote:
> On Sat, 22 Mar 2014 13:32:07 -0400 ty...@mit.edu wrote:
>
> > On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
> > > > Well. Converting an existing retry-for-ever caller to GFP_NOFAIL is
> > > > good. Adding new
On Sat, 2014-03-22 at 10:55 -0700, Andrew Morton wrote:
> On Sat, 22 Mar 2014 13:32:07 -0400 ty...@mit.edu wrote:
>
> > On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
> > > > Well. Converting an existing retry-for-ever caller to GFP_NOFAIL is
> > > > good. Adding new
On Sat, Mar 22, 2014 at 10:55:24AM -0700, Andrew Morton wrote:
>
> From: Andrew Morton
> Subject: scripts/checkpatch.pl: __GFP_NOFAIL isn't going away
>
> Revert 7e4915e78992eb ("checkpatch: add warning of future __GFP_NOFAIL use").
>
> There are no plans to remove __GFP_NOFAIL.
>
>
On Sat, 22 Mar 2014 13:32:07 -0400 ty...@mit.edu wrote:
> On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
> > > Well. Converting an existing retry-for-ever caller to GFP_NOFAIL is
> > > good. Adding new retry-for-ever code is not good.
>
> Oh, and BTW --- now that checkpatch.pl
On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
> > Well. Converting an existing retry-for-ever caller to GFP_NOFAIL is
> > good. Adding new retry-for-ever code is not good.
Oh, and BTW --- now that checkpatch.pl now flags an warning whenever
GFP_NOFAIL is used, because it is
On Sat, Mar 22, 2014 at 10:15:12AM -0700, Andrew Morton wrote:
> > I'll note that since 2011, there has been precious little movement on
> > removing the final few callers of GFP_NOFAIL, and we still have a bit
> > under two dozen of them, including a new one in fs/buffer.c that was
> > added in
On Sat, 22 Mar 2014 13:03:22 -0400 ty...@mit.edu wrote:
> On Fri, Mar 21, 2014 at 01:00:55PM -0700, Andrew Morton wrote:
> >
> > The whole point of __GFP_NOFAIL is to centralise this
> > wait-for-memory-for-ever operation. So it is implemented in a common
> > (core) place and so that we can
On Fri, Mar 21, 2014 at 01:00:55PM -0700, Andrew Morton wrote:
>
> The whole point of __GFP_NOFAIL is to centralise this
> wait-for-memory-for-ever operation. So it is implemented in a common
> (core) place and so that we can easily locate these problematic
> callers.
>
> is exactly wrong.
On Fri, Mar 21, 2014 at 01:00:55PM -0700, Andrew Morton wrote:
The whole point of __GFP_NOFAIL is to centralise this
wait-for-memory-for-ever operation. So it is implemented in a common
(core) place and so that we can easily locate these problematic
callers.
is exactly wrong. Yes, we'd
On Sat, 22 Mar 2014 13:03:22 -0400 ty...@mit.edu wrote:
On Fri, Mar 21, 2014 at 01:00:55PM -0700, Andrew Morton wrote:
The whole point of __GFP_NOFAIL is to centralise this
wait-for-memory-for-ever operation. So it is implemented in a common
(core) place and so that we can easily
On Sat, Mar 22, 2014 at 10:15:12AM -0700, Andrew Morton wrote:
I'll note that since 2011, there has been precious little movement on
removing the final few callers of GFP_NOFAIL, and we still have a bit
under two dozen of them, including a new one in fs/buffer.c that was
added in 2013.
On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
Well. Converting an existing retry-for-ever caller to GFP_NOFAIL is
good. Adding new retry-for-ever code is not good.
Oh, and BTW --- now that checkpatch.pl now flags an warning whenever
GFP_NOFAIL is used, because it is
On Sat, 22 Mar 2014 13:32:07 -0400 ty...@mit.edu wrote:
On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
Well. Converting an existing retry-for-ever caller to GFP_NOFAIL is
good. Adding new retry-for-ever code is not good.
Oh, and BTW --- now that checkpatch.pl now flags
On Sat, Mar 22, 2014 at 10:55:24AM -0700, Andrew Morton wrote:
From: Andrew Morton a...@linux-foundation.org
Subject: scripts/checkpatch.pl: __GFP_NOFAIL isn't going away
Revert 7e4915e78992eb (checkpatch: add warning of future __GFP_NOFAIL use).
There are no plans to remove
On Sat, 2014-03-22 at 10:55 -0700, Andrew Morton wrote:
On Sat, 22 Mar 2014 13:32:07 -0400 ty...@mit.edu wrote:
On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
Well. Converting an existing retry-for-ever caller to GFP_NOFAIL is
good. Adding new retry-for-ever code is
On Sat, Mar 22, 2014 at 10:55:24AM -0700, Andrew Morton wrote:
On Sat, 22 Mar 2014 13:32:07 -0400 ty...@mit.edu wrote:
On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
Well. Converting an existing retry-for-ever caller to GFP_NOFAIL is
good. Adding new
On Sat, 22 Mar 2014 10:55:24 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Sat, 22 Mar 2014 13:32:07 -0400 ty...@mit.edu wrote:
On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
Well. Converting an existing retry-for-ever caller to GFP_NOFAIL is
good. Adding
On Sat, 22 Mar 2014 00:21:59 +0100 Fabian Frederick wrote:
> > What we should do is to fix all these call sites so they can handle
> > memory exhaustion. That's hard so in the interim they should be using
> > __GFP_NOFAIL.
> >
>
> Ok, if even ext4 comments are wrong, things gonna be very
On Fri, 21 Mar 2014 13:00:55 -0700
Andrew Morton wrote:
> On Fri, 21 Mar 2014 17:18:30 +0100 Fabian Frederick wrote:
>
> > Loop around congestion_wait on allocation failure/alloc_journal_list
> > like already fixed in other FS.
> >
> > ...
> >
> > --- a/fs/reiserfs/journal.c
> > +++
On Fri, 21 Mar 2014 17:18:30 +0100 Fabian Frederick wrote:
> Loop around congestion_wait on allocation failure/alloc_journal_list
> like already fixed in other FS.
>
> ...
>
> --- a/fs/reiserfs/journal.c
> +++ b/fs/reiserfs/journal.c
> @@ -2487,8 +2487,13 @@ static int journal_read(struct
Loop around congestion_wait on allocation failure/alloc_journal_list
like already fixed in other FS.
(Does it need returning -ENOMEM after some retries ?)
Signed-off-by: Fabian Frederick
---
fs/reiserfs/journal.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
Loop around congestion_wait on allocation failure/alloc_journal_list
like already fixed in other FS.
(Does it need returning -ENOMEM after some retries ?)
Signed-off-by: Fabian Frederick f...@skynet.be
---
fs/reiserfs/journal.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
On Fri, 21 Mar 2014 17:18:30 +0100 Fabian Frederick f...@skynet.be wrote:
Loop around congestion_wait on allocation failure/alloc_journal_list
like already fixed in other FS.
...
--- a/fs/reiserfs/journal.c
+++ b/fs/reiserfs/journal.c
@@ -2487,8 +2487,13 @@ static int journal_read(struct
On Fri, 21 Mar 2014 13:00:55 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Fri, 21 Mar 2014 17:18:30 +0100 Fabian Frederick f...@skynet.be wrote:
Loop around congestion_wait on allocation failure/alloc_journal_list
like already fixed in other FS.
...
---
On Sat, 22 Mar 2014 00:21:59 +0100 Fabian Frederick f...@skynet.be wrote:
What we should do is to fix all these call sites so they can handle
memory exhaustion. That's hard so in the interim they should be using
__GFP_NOFAIL.
Ok, if even ext4 comments are wrong, things gonna be very
40 matches
Mail list logo
