Re: [PATCH] cramfs corruption after BLKFLSBUF on loop device

[Andrew Morton]

Olaf Hering <olh@xxxxxxx> wrote:
>
> 
>  
> +/* return a page in PageUptodate state, BLKFLSBUF may have flushed the page */
> +static struct page *cramfs_read_cache_page(struct address_space *m, unsigned int n)
> +{
> +	struct page *page;
> +	int readagain = 5;
> +retry:
> +	page = read_cache_page(m, n, (filler_t *)m->a_ops->readpage, NULL);
> +	if (IS_ERR(page))
> +		return NULL;
> +	lock_page(page);
> +	if (PageUptodate(page))
> +		return page;
> +	unlock_page(page);
> +	page_cache_release(page);
> +	if (readagain--)
> +		goto retry;
> +	return NULL;
> +}

Better, but it's still awful, isn't it?  The things you were discussing
with Chris look more promising.  PG_Dirty would be a bit of a hack, but at
least it'd be a 100% reliable hack, whereas the above is a
whatever-the-previous-failure-rate-was-to-the-fifth hack.

> +			page = cramfs_read_cache_page(mapping, blocknr + i);
> +			if (page) {
> +				memcpy(data, kmap_atomic(page, KM_USER0), PAGE_CACHE_SIZE);
> +				kunmap(page);

kunmap_atomic, please.

> +				unlock_page(page);
> +				page_cache_release(page);
> +			} else
> +				memset(data, 0, PAGE_CACHE_SIZE);
> +		}
>  		data += PAGE_CACHE_SIZE;
>  	}
>  	return read_buffers[buffer] + offset;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/