On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote:
> On Saturday April 21, [EMAIL PROTECTED] wrote:
> > When the kernel calls svc_reserve to downsize the expected size of an RPC
> > reply, it fails to account for the possibility of a checksum at the end of
> > the packet. If a client
On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote:
On Saturday April 21, [EMAIL PROTECTED] wrote:
When the kernel calls svc_reserve to downsize the expected size of an RPC
reply, it fails to account for the possibility of a checksum at the end of
the packet. If a client mounts a
On Mon, Apr 30, 2007 at 11:33:10PM -0400, bfields wrote:
> On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote:
> > Bruce: does it look OK to you?
>
> It looks sensible, but it's a little late for me--I'll take another look
> at it and run some tests tommorow.
Just to confirm--yep, loks
On Tuesday May 1, [EMAIL PROTECTED] wrote:
>
> Resending patch with a proper signed-off-by line. Also cc'ing Andrew:
Thanks, but it isn't much good to Andrew without a changelog entry,
though probably it should just go in as
rpc--add-wrapper-for-svc_reserve-to-account-for-checksum-fix
On Tue, May 01, 2007 at 01:01:27PM -0400, Jeff Layton wrote:
> On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote:
> >
> > Yes, that asn1 encoding does seem rather awkward.
> >
> > Maybe we should just use RPC_MAX_AUTH_SIZE like other bits of GSS code
> > does. There is no great cost in
On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote:
> On Saturday April 21, [EMAIL PROTECTED] wrote:
> > When the kernel calls svc_reserve to downsize the expected size of an RPC
> > reply, it fails to account for the possibility of a checksum at the end of
> > the packet. If a client
On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote:
On Saturday April 21, [EMAIL PROTECTED] wrote:
When the kernel calls svc_reserve to downsize the expected size of an RPC
reply, it fails to account for the possibility of a checksum at the end of
the packet. If a client mounts a
On Tue, May 01, 2007 at 01:01:27PM -0400, Jeff Layton wrote:
On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote:
Yes, that asn1 encoding does seem rather awkward.
Maybe we should just use RPC_MAX_AUTH_SIZE like other bits of GSS code
does. There is no great cost in reserving
On Tuesday May 1, [EMAIL PROTECTED] wrote:
Resending patch with a proper signed-off-by line. Also cc'ing Andrew:
Thanks, but it isn't much good to Andrew without a changelog entry,
though probably it should just go in as
rpc--add-wrapper-for-svc_reserve-to-account-for-checksum-fix
Acked-by:
On Mon, Apr 30, 2007 at 11:33:10PM -0400, bfields wrote:
On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote:
Bruce: does it look OK to you?
It looks sensible, but it's a little late for me--I'll take another look
at it and run some tests tommorow.
Just to confirm--yep, loks fine.
On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote:
> I don't think this BUG_ON is correct. If a readdir finds zero entries,
> then will be some trailer information in the 'tail', but page_len will
> be 0. I think the following patch is correct and could fix that.
Yep.
> Bruce: does
On Saturday April 21, [EMAIL PROTECTED] wrote:
> When the kernel calls svc_reserve to downsize the expected size of an RPC
> reply, it fails to account for the possibility of a checksum at the end of
> the packet. If a client mounts a NFSv2/3 with sec=krb5i/p, and does I/O then
> you'll generally
On Saturday April 21, [EMAIL PROTECTED] wrote:
When the kernel calls svc_reserve to downsize the expected size of an RPC
reply, it fails to account for the possibility of a checksum at the end of
the packet. If a client mounts a NFSv2/3 with sec=krb5i/p, and does I/O then
you'll generally see
On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote:
I don't think this BUG_ON is correct. If a readdir finds zero entries,
then will be some trailer information in the 'tail', but page_len will
be 0. I think the following patch is correct and could fix that.
Yep.
Bruce: does it
14 matches
Mail list logo
