Date: Tue, 20 Jun 2000 13:48:09 -0400 From: Christopher Sedore <cmsedore@maxwell.syr.edu> To: "'arch@freebsd.org'" <arch@freebsd.org> Subject: RE: MORE: Re: kblob discussion. Message-ID: <D006CCEB462FD411976100A0C9B413A139E5C2@EXCHANGE>
next in thread | raw e-mail | index | archive | help
>* Christopher Sedore <cmsedore@maxwell.syr.edu> [000620 09:43] wrote: >> >> [...] >> >> >Last night I started thinking about making kblob more flexible, >> >here's the problem I came across: >> > >> >All the papers that have been given to me make sure that once a >> >0 copy buffer is shared across subsystems it is immutable until >> >the data it's loaned has gone back to no references except by >> >the user process. >> > >> >Not following the above system is _wrong_. >> >> I'm not sure I would put that level of emphasis on _wrong_. > It deserves >> that level of emphasis if it can cause kernel state (or other system) >> corruption (which should be reason for _wrong_, though I'd >call this a >> problem with implementation more than anything else). If the >> user/application can only screw up its own data/connections >(in the sense of >> undefined, possibly random data being sent/written), then >why not state that >> modifying the data causes undefined results (including TCP >checksum errors, >> whatever else) and let the programmer beware. > >Because it puts undue burden on the rest of the kernel to cope with >a user's access to internals. What happens if we are using some >sort of checksum offloading chipset or encryption/compression system >that can't stand the data being ripped out from under it. What's >the point of recalculating the checksum of a packet when we know >it shouldn't have changed? > >It's wrong. :) The only access is to data that the user passed in already, so harm should be limited to incorrect checksums. I guess I have to agree that ultimately it would be harder to make sure the kernel could deal with changes in this area than just to prevent them in the first place. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D006CCEB462FD411976100A0C9B413A139E5C2>