[Top] [All Lists]

re: XFS memory hardening

To: lord@xxxxxxx
Subject: re: XFS memory hardening
From: Andi Kleen <ak@xxxxxx>
Date: Wed, 15 Aug 2001 05:11:28 +0200
Cc: linux-xfs@xxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
Hi Steve,

In reply to your reply to my XFS memory hardening patch. Work email is
unfortunately down, so this way.

> The problem with the code which does some
> xfs memory allocation failure detection is that you can never get to
> all of them, this is why I have never checked in the stuff about
> seeing a NULL and doing an error return. There are also places in xfs
> where failure is not an option - once a transaction has dirtied
> metadata there is no turning back. So really the only option which will
> fly long term is making sure memory allocations do not return failure
> when they get back up to xfs proper. I do have some other ideas it is
> just a matter of finding the time.

Most of my patch satisfies that. The kmem changes especially do not return
until success, even though that could mean deadlock on OOM.

The only place in the patch where a transaction could be potentially 
dirtied and a new ENOMEM is added is in xfs_trans_read_buf(). There I still 
think it's better to return the error than to oops in the caller on a NULL 
pointer. Also this function definitely can return other errors instead
(EIO) so the callers should handle it (or they have a different bug)

The other places either involve no transactions or just extend existing 
error paths.


<Prev in Thread] Current Thread [Next in Thread>