linux-kernel - Re: [BUG] Reiserfs panic while running fsstress due to multiple truncate "safe links" for a file.

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

Message-ID: <456B76CD.5000600@in.ibm.com>
Date:	Mon, 27 Nov 2006 15:37:49 -0800
From:	Suzuki <suzuki@...ibm.com>
To:	Andrew Morton <akpm@...l.org>
CC:	amitarora@...ibm.com, "Vladimir V. Saveliev" <vs@...esys.com>,
	reiserfs-list@...esys.com, reiserfs-dev@...esys.com,
	lkml <linux-kernel@...r.kernel.org>, rdunlap@...otime.net
Subject: Re: [BUG] Reiserfs panic while running fsstress due to multiple truncate
 "safe links" for a file.

Andrew Morton wrote:
> On Mon, 08 May 2006 17:03:41 +0530
> Suzuki <suzuki@...ibm.com> wrote:
> 
> 
>>Resending, since there were no responses to the earlier post.
>>
>>Hi,
>>
>>
>>I was working on a reiserfs panic with 2.6.17-rc3, while running fs
>>stress tests.
>>
>>The panic message looked like :
>>
>>" REISERFS: panic (device Null superblock): reiserfs[4248]: assertion
>>!(truncate && (REISERFS_I(inode)->i_flags & i_link_saved_truncate_mask)
>>) failed at fs/reiserfs/super.c:328:add_save_link: saved link already re
>>exists for truncated inode 13b5a "
>>
>>------ Summary of the problem -----------
>>
>>Reiserfs uses "safe links" ( directory entries with some special key
>>value) to keep track of "truncated" or "unlinked" files to ensure
>>integrity across crashes.
>>
>>Whenever there is a truncate/unlink on a file, Reiserfs creates a safe
>>link for the same and deletes the same once the operation is complete.
>>If the machine crashes before committing the operation, whenever the fs
>>is mounted next time, the fs will look for the saved links ( easy to
>>find out, since they have special key) and commit the operation that was
>>unfinished.
>>
>>
>>The problem here occurs as follows:
>>
>>  Whenever there is an extending DIO write operation, the fs would
>>create a safe link so as to ensure the file size consistent, if there is
>>crash in between the DIO. This will be deleted once the write operation
>>finishes.
>>
>>  If the DIO write happens to go through a "HOLE" region in the file, it
>>will fall into normal "buffered write", which is done  through the
>>address space operations prepare_write() & commit_write(). Now, the
>>prepare_write() might allocate blocks for the file (if needed). So if
>>there is some error at a later point (say ENOSPC) in prepare_write(), we
>>need to discard the allocated blocks. This is done by calling
>>"vmtruncate()" on the file. This call leads to reiserfs specific
>>truncate, which would try to add a save link for the file.
>>
>>This addition causes a reiserfs_panic, since there is already a "save
>>link" stored for the file.
>>
>>
>>I have a simple testcase to reproduce the problem, which does the same 
>>as described above. I will attach it if required.
>>
>>Any thoughts on how to fix this ?
>>
> 
> 
> Did we end up fixing this?

Finally, we were able to verify this on 2.6.18-rc7. Sorry for the delay.

Vladimir wrote :

     "I am not sure why safe link is needed for write. Maybe one who 
added that still remembers why that was done and can explain, please? "


The patch attached by Vladimir has been modified to fit into the current 
level.

The patch is on 2.6.19-rc1.

Thanks,

-Suzuki

> 
> Thanks.


View attachment "reiserfs-no-save-links-on-write.diff" of type "text/x-patch" (2602 bytes)