linux-kernel - Re: [RFC] Tux3 for review

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 23 May 2014 01:21:41 -0700
From:	Daniel Phillips <daniel@...nq.net>
To:	Dongsu Park <dongsu.park@...fitbricks.com>
Cc:	Dave Chinner <david@...morbit.com>,
	<linux-fsdevel@...r.kernel.org>, <tux3@...3.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Tux3 for review

Hi Dongsu,

On Thursday, May 22, 2014 2:52:27 AM PDT, Dongsu Park wrote:
> First of all, thank you for trying to merge it to mainline.
> Maybe I cannot say the code is clean enough, but basically
> the filesystem seems to work at least.

Thank you for confirming that. We test Tux3 extensively so we know it works 
pretty well (short of enospc handling) but independent confirmation carries 
more weight than anything we could say. Our standard disclaimer: Tux3 is 
for developers right now, not for users.

>> ...The files named "*_hack" were kept as close as
>> possible to the original core code to clarify exactly where core
>> needs to change in order to remove our workarounds. If you think we
>> should pretty up that code then we will happily do it. Or maybe we
>> can hammer out acceptable core patches right now, and include those
>  ...
>
> Looking up kallsyms is not only hacky, but also making the filesystem
> unable to be mounted at all, when CONFIG_KALLSYMS_ALL is not defined.
> I'll send out patches to fix that separately to tux3 mailing list.

Thank you for improving the hack. We are working on getting rid of that 
flusher hack completely. There is a patch under development to introduce a 
new super_operationss.writeback() operation that allows a filesystem to 
flush its own inodes instead of letting core do it. This will allow Tux3 to 
enforce its strong ordering semantics efficiently without needing to 
reimplement part of fs-writeback.c.

Regards,

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/