Michal Hocko wrote:

On Wed 25-01-17 19:33:59, Tetsuo Handa wrote:

quoted

Michal Hocko wrote:

quoted

I think we are missing a check for fatal_signal_pending in
iomap_file_buffered_write. This means that an oom victim can consume the
full memory reserves. What do you think about the following? I haven't
tested this but it mimics generic_perform_write so I guess it should
work.

Looks OK to me. I worried

#define AOP_FLAG_UNINTERRUPTIBLE        0x0001 /* will not do a short write */

which forbids (!?) aborting the loop. But it seems that this flag is
no longer checked (i.e. set but not used). So, everybody should be ready
for short write, although I don't know whether exofs / hfs / hfsplus are
doing appropriate error handling.

Those were using generic implementation before and that handles this
case AFAICS.

What I wanted to say is: "We can remove AOP_FLAG_UNINTERRUPTIBLE completely
because grep does not find that flag used in condition check, can't we?".

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>