Date: Thu, 25 Dec 2014 21:04:48 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Peter Jeremy <peter@rulingia.com> Cc: freebsd-fs@freebsd.org, benno@freebsd.org Subject: Re: "panic: len 0" on NFS read Message-ID: <1511059720.2385651.1419559488456.JavaMail.root@uoguelph.ca> In-Reply-To: <20141226014220.GA2001@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: > On 2014-Dec-25 20:08:20 -0500, Rick Macklem <rmacklem@uoguelph.ca> > wrote: > >Peter Jeremy wrote: > >> Whilst trying to debug a RPC issue with a NFS tunneling tool, I > >> mounted a > >> NFS filesystem onto the same host and got a panic when I tried to > >> access it. > >> > >> I'm running FreeBSD/amd64 10-stable r276177. > >> > >> I mounted the filesystem with: > >> # mount -o udp,nfsv3 $(hostname):/tank/src92 /dist > >> > >> (/tank/src92 and / are ZFS) > >> > >> And then ran: > >> $ grep zzzz /dist/* > >> > >> And got: > >> panic: len 0 > >r275941 in head changed this KASSERT to allow a 0 length mbuf, so I > >don't think the panic is meaningful. > >Maybe r275941 should be MFC'd? (I've cc'd benno, who did the > >commit.) > > Thanks. I've tried MFCing r275941 and can't reproduce the panic by > following the above (though without knowing the exact reason for > having a > 0-byte mbuf in the chain originally, I can't be sure that I'm getting > a > 0-byte mbuf in the chain now). > Well, NFSM_DISSECT() behaves a little like m_pullup(), in that it can copy data from one mbuf to another to create a large enough contiguous data area. It is conceivable that the mbuf being copied from could be reduced to m_len == 0. The code wouldn't remove this mbuf from the chain. rick > -- > Peter Jeremy >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1511059720.2385651.1419559488456.JavaMail.root>