linux-kernel - Re: [PATCH] support larger cifs network reads

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

Message-ID: <20070605093017.GA30288@infradead.org>
Date:	Tue, 5 Jun 2007 10:30:17 +0100
From:	Christoph Hellwig <hch@...radead.org>
To:	Steve French <smfrench@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-cifs-client@...ts.samba.org
Subject: Re: [PATCH] support larger cifs network reads

On Thu, May 31, 2007 at 06:08:23PM -0500, Steve French wrote:
> With Samba 3.0.26pre it is now possible for a cifs client (one which
> supports the newest Unix/Posix cifs extensions) to request up to
> almost 8MB at a time on a cifs read request.
> 
> A patch for the cifs client to support larger reads follows.  In this
> patch, using very large reads is not the default behavior, since it
> would require larger buffer allocations for the large cifs request
> buffers, but in the future when cifs can demultiplex reads to a page
> list in the cifs_demultiplex_thread (without having to copy to a large
> temporary buffer) this will be even more useful.

Increasing this now doesn't make any sense - slab won't be able to
create a 8MB cache on most architectures, and even if it could the
wasted memory would be enormous.  Once you actually support
scatter/gather allocations an increase is fine.

-
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/