linux-ext4 - Re: [PATCH 1/3] jbd2 : Make jbd2 transaction handle allocation to return errors and handle them gracefully.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 24 Apr 2011 17:06:30 -0700
From:	Manish Katiyar <mkatiyar@...il.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Andreas Dilger <adilger.kernel@...ger.ca>,
	Joel Becker <jlbec@...lplan.org>, "Ted Ts'o" <tytso@....edu>,
	ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 1/3] jbd2 : Make jbd2 transaction handle allocation to
 return errors and handle them gracefully.

On Fri, Feb 4, 2011 at 7:53 AM, Jan Kara <jack@...e.cz> wrote:
> On Sat 29-01-11 21:40:03, Manish Katiyar wrote:
>  Hi Manish,
>
>> Have we reached on any conclusion yet on the function name which I can
>> use to send my updated patch ? My preference from the above list is to
>> use ext4_journal_start_nofs() as that seems the closest match, but I
>> would like hear the conclusion from experts.
>  How about "ext4_journal_start_tryhard()"? I don't like "nofs" because
> the fact whether we use GFP_NOFS is separate from the fact whether we are
> able to handle memory allocation failure.

Hi Jan,

Sorry for taking so long to respond to this. I'm sending the updated
set of patches after incorporating your previous comments. As
suggested I have added a wrapper routine ext4_journal_start_tryhard()
for the transaction allocation which can't fail and does
its allocation using GFP_NOFS. Regular ext4_journal_start() uses GFP_KERNEL.


-- 
Thanks a lot -
Manish
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html