linux-kernel - Re: still nfs problems [Was: Linux 2.6.37-rc8]

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

Date:	Thu, 6 Jan 2011 15:19:33 -0500
From:	"John Stoffel" <john@...ffel.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Trond Myklebust <Trond.Myklebust@...app.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	Marc Kleine-Budde <mkl@...gutronix.de>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Marc Kleine-Budde <m.kleine-budde@...gutronix.de>,
	linux-arm-kernel@...ts.infradead.org,
	Parisc List <linux-parisc@...r.kernel.org>,
	linux-arch@...r.kernel.org
Subject: Re: still nfs problems [Was: Linux 2.6.37-rc8]

>>>>> "James" == James Bottomley <James.Bottomley@...senPartnership.com> writes:

James> On Wed, 2011-01-05 at 23:28 +0000, James Bottomley wrote:
>> Can you explain how the code works? it looks to me like you read the xdr
>> stuff through the vmap region then write it out directly to the pages? 

James> OK, I think I see how this is supposed to work: It's a
James> sequential loop of reading in via the pages (i.e. through the
James> kernel mapping) and then updating those pages via the vmap.  In
James> which case, I think this patch is what you need.

James> The theory of operation is that the readdir on pages actually
James> uses the network DMA operations to perform, so when it's
James> finished, the underlying page is up to date.  After this you
James> invalidate the vmap range, so we have no cache lines above it
James> (so it picks up the values from the uptodate page).  Finally,
James> after the operation on the vmap region has finished, you flush
James> it so that any updated contents go back to the pages themselves
James> before the next iteration begins.

You need to re-spin this patch to include the above description into
the magic steps your taking here, or at least document it more clearly
somewhere why you need to make these funky steps.  

John


James> James

James> ---

James> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
James> index 996dd89..bde1911 100644
James> --- a/fs/nfs/dir.c
James> +++ b/fs/nfs/dir.c
James> @@ -587,12 +587,16 @@ int nfs_readdir_xdr_to_array(nfs_readdir_descriptor_t *desc, struct page *page,
James>  		if (status < 0)
James>  			break;
James>  		pglen = status;
James> +
James> +		invalidate_kernel_vmap_range(pages_ptr, pglen);
James> +
James>  		status = nfs_readdir_page_filler(desc, &entry, pages_ptr, page, pglen);
James>  		if (status < 0) {
James>  			if (status == -ENOSPC)
James>  				status = 0;
James>  			break;
James>  		}
James> +		flush_kernel_vmap_range(pages_ptr, pglen);
James>  	} while (array->eof_index < 0);
 
James>  	nfs_readdir_free_large_page(pages_ptr, pages, array_size);


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

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