Subject: + hfsplus-implement-attributes-file-creation-functionality-v2.patch added to -mm tree To: slava@xxxxxxxxxxx,hch@xxxxxxxxxxxxx,htl10@xxxxxxxxxxxxxxxxxxxxx,viro@xxxxxxxxxxxxxxxxxx From: akpm@xxxxxxxxxxxxxxxxxxxx Date: Mon, 30 Sep 2013 14:27:50 -0700 The patch titled Subject: hfsplus-implement-attributes-file-creation-functionality-v2 has been added to the -mm tree. Its filename is hfsplus-implement-attributes-file-creation-functionality-v2.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/hfsplus-implement-attributes-file-creation-functionality-v2.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/hfsplus-implement-attributes-file-creation-functionality-v2.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Vyacheslav Dubeyko <slava@xxxxxxxxxxx> Subject: hfsplus-implement-attributes-file-creation-functionality-v2 * SETOFFSET macro was removed (Andrew Morton). * Record offsets logic was reworked in hfsplus_init_header_node() (Al Viro). * AttributesFile's header node's bitmap is initialized by memset() (Al Viro). * Logic of checking attributes tree state before AttributesFile creation was reworked for HFSPLUS_CREATING_ATTR_TREE case (Andrew Morton). * Setting error code was added after read_mapping_page() call in hfsplus_create_attributes_file() method (Andrew Morton). Signed-off-by: Vyacheslav Dubeyko <slava@xxxxxxxxxxx> Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx> Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx> Cc: Hin-Tak Leung <htl10@xxxxxxxxxxxxxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- fs/hfsplus/xattr.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff -puN fs/hfsplus/xattr.c~hfsplus-implement-attributes-file-creation-functionality-v2 fs/hfsplus/xattr.c --- a/fs/hfsplus/xattr.c~hfsplus-implement-attributes-file-creation-functionality-v2 +++ a/fs/hfsplus/xattr.c @@ -217,9 +217,21 @@ check_attr_tree_state_again: goto check_attr_tree_state_again; break; case HFSPLUS_CREATING_ATTR_TREE: - schedule_timeout_uninterruptible(HZ); - goto check_attr_tree_state_again; - break; + /* + * This state means that another thread is in process + * of AttributesFile creation. Theoretically, it is + * possible to be here. But really __setxattr() method + * first of all calls hfs_find_init() for lookup in + * B-tree of CatalogFile. This method locks mutex of + * CatalogFile's B-tree. As a result, if some thread + * is inside AttributedFile creation operation then + * another threads will be waiting unlocking of + * CatalogFile's B-tree's mutex. However, if code will + * change then we will return error code (-EAGAIN) from + * here. Really, it means that first try to set of xattr + * fails with error but second attempt will have success. + */ + return -EAGAIN; case HFSPLUS_VALID_ATTR_TREE: return 0; case HFSPLUS_FAILED_ATTR_TREE: @@ -281,8 +293,10 @@ check_attr_tree_state_again: void *kaddr; page = read_mapping_page(mapping, index, NULL); - if (IS_ERR(page)) + if (IS_ERR(page)) { + err = PTR_ERR(page); goto failed_header_node_init; + } kaddr = kmap_atomic(page); memcpy(kaddr, buf + written, _ Patches currently in -mm which might be from slava@xxxxxxxxxxx are nilfs2-fix-issue-with-race-condition-of-competition-between-segments-for-dirty-blocks.patch hfsplus-add-metadata-files-clump-size-calculation-functionality.patch hfsplus-implement-attributes-files-header-node-initialization-code.patch hfsplus-implement-attributes-files-header-node-initialization-code-v2.patch hfsplus-implement-attributes-file-creation-functionality.patch hfsplus-implement-attributes-file-creation-functionality-v2.patch -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html