Re: [PATCH 2/2] Fix possible leakage of blocks in UDF

[Cyrill Gorcunov <gorcunov@gmail.com>]

[Andrew Morton - Sat, Jun 02, 2007 at 12:06:45AM -0700]
| On Sat, 2 Jun 2007 10:59:23 +0400 Cyrill Gorcunov <gorcunov@gmail.com> wrote:
| 
| > [Andrew Morton - Fri, Jun 01, 2007 at 11:54:22PM -0700]
| > | On Sat, 2 Jun 2007 10:34:03 +0400 Cyrill Gorcunov <gorcunov@gmail.com> wrote:
| > | 
| > | > | That patch is DOA, methinks.
| > | > | 
| > | > 
| > | > Andrew, what does it mean - "DOA"? Dead on arrival?
| > | 
| > | yes - I dropped it.
| > | 
| > 
| > But that could lead to rejection of my code-style-conversion patch...
| > Should I remake them?
| 
| Actually I've rebuilt those patches four times already.  People keep
| changing stuff.
| 
| > Actually Jan was right, the current state of UDF (without his patches)
| > could lead to lost blocks and his patch must be just fixed I think.
| 
| sure.
| 

Andrew, you know I've been trying to reproduce Eric's lockup case almost
two hour and still can't reach it. All manupulation I've done to UDF didn't
lead to lockup. Moreover, I've added debug print for UDF module and here is
the results (for single drop_inode call):

	[12063.897000] UDF: udf_drop_inode:105 --> udf_drop_inode --> inode->i_count: 0
	[12063.897000] UDF: udf_drop_inode:107 udf_drop_inode -> discard_prealloc
	[12063.897000] UDF: udf_discard_prealloc:136 udf_discard_prealloc
	[12063.897000] UDF: udf_truncate_tail_extent:84 udf_truncate_tail_extent
	[12063.897000] UDF: udf_truncate_extents:194 udf_truncate_extents -->
	[12063.897000] UDF: extent_trunc:38 --->
	[12063.897000] UDF: extent_trunc:54 call to udf_write_aext
	[12063.897000] UDF: udf_write_aext:1843 udf_write_aext
	[12063.897000] UDF: udf_write_aext:1846 dont has epos->bh
	[12063.897000] UDF: udf_write_aext:1866 ICBTAG_FLAG_AD_LONG
--->	[12063.897000] UDF: udf_write_aext:1893 ---> gotcha ---> call mark_inode_dirty
--->	[12063.897000] UDF: extent_trunc:59 --> gotcha --> call mark_inode_dirty
	[12063.897000] UDF: extent_trunc:68 <---
--->	[12063.897000] UDF: udf_truncate_extents:282 call mark_inode_dirty
	[12063.897000] UDF: udf_truncate_extents:330 udf_truncate_extents <--
	[12063.897000] UDF: udf_drop_inode:115 <-- udf_drop_inode <--

As you may see, mark_inode_dirty is called several time and no locking happened.
Maybe I should use some test utils?

		Cyrill

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