From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH v2] hfsplus: avoid crash on failed block map free Date: Tue, 13 Nov 2012 14:34:44 -0800 Message-ID: <20121113143444.f8d4bbc3.akpm@linux-foundation.org> References: <1352799065.2443.3.camel@slavad-ubuntu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alan Cox , linux-fsdevel@vger.kernel.org, Christoph Hellwig To: Vyacheslav Dubeyko Return-path: Received: from mail.linuxfoundation.org ([140.211.169.12]:55819 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751474Ab2KMWep (ORCPT ); Tue, 13 Nov 2012 17:34:45 -0500 In-Reply-To: <1352799065.2443.3.camel@slavad-ubuntu> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, 13 Nov 2012 13:31:05 +0400 Vyacheslav Dubeyko wrote: > If the read fails we kmap an error code. This doesn't end well. Instead print a critical error and pray. This mirrors the rest of the fs behaviour with critical error cases. > > ... > > index 4cfbe2e..6feefc0 100644 > --- a/fs/hfsplus/bitmap.c > +++ b/fs/hfsplus/bitmap.c > @@ -176,12 +176,14 @@ int hfsplus_block_free(struct super_block *sb, u32 offset, u32 count) > dprint(DBG_BITMAP, "block_free: %u,%u\n", offset, count); > /* are all of the bits in range? */ > if ((offset + count) > sbi->total_blocks) > - return -2; > + return -ENOENT; > > mutex_lock(&sbi->alloc_mutex); > mapping = sbi->alloc_file->i_mapping; > pnr = offset / PAGE_CACHE_BITS; > page = read_mapping_page(mapping, pnr, NULL); > + if (IS_ERR(page)) > + goto kaboom; > pptr = kmap(page); > curr = pptr + (offset & (PAGE_CACHE_BITS - 1)) / 32; > end = pptr + PAGE_CACHE_BITS / 32; > @@ -214,6 +216,8 @@ int hfsplus_block_free(struct super_block *sb, u32 offset, u32 count) > set_page_dirty(page); > kunmap(page); > page = read_mapping_page(mapping, ++pnr, NULL); > + if (IS_ERR(page)) > + goto kaboom; > pptr = kmap(page); > curr = pptr; > end = pptr + PAGE_CACHE_BITS / 32; > @@ -232,4 +236,11 @@ out: > mutex_unlock(&sbi->alloc_mutex); > > return 0; > + > +kaboom: > + printk(KERN_CRIT "hfsplus: unable to mark blocks free: error %ld\n", > + PTR_ERR(page)); > + mutex_unlock(&sbi->alloc_mutex); > + > + return -EIO; > } It looks better than what we currently have! The code is missing a flush_dcache_page()? We should have one in there after the CPU has modified userspace-mappable page contents. btw, I still have question marks over your earlier patches: hfsplus-add-on-disk-layout-declarations-related-to-attributes-tree.patch hfsplus-add-functionality-of-manipulating-by-records-in-attributes-tree.patch hfsplus-rework-functionality-of-getting-setting-and-deleting-of-extended-attributes.patch hfsplus-add-support-of-manipulation-by-attributes-file.patch hfsplus-add-support-of-manipulation-by-attributes-file-checkpatch-fixes.patch hfsplus-code-style-fixes-reworked-support-of-extended-attributes.patch Christoph sounded unhappy, but the review discussion petered out?