Bruce Evans writes:
> > That is, what we really need is a more general audit for code that
> > writes into mbufs that might be read-only -- and, as one special case
> > of tha, code that calls M_TRAILINGSPACE()/M_LEADINGSPACE() before writing
> > into an mbuf.
> >
> > FYI, any easy way to do this
On Fri, 31 May 2002, Archie Cobbs wrote:
> That is, what we really need is a more general audit for code that
> writes into mbufs that might be read-only -- and, as one special case
> of tha, code that calls M_TRAILINGSPACE()/M_LEADINGSPACE() before writing
> into an mbuf.
>
> FYI, any easy way t
On Fri, May 31, 2002 at 01:25:09PM -0700, Archie Cobbs wrote:
> As a temporary saftey measure, I'll add M_WRITABLE(m) into the
> M_TRAILINGSPACE() macro. However, I see this as a temporary hack;
> the correct fix is to put the burden of writability on the caller.
> After all, M_TRAILINGSPACE() doe
Julian Elischer writes:
> > It's not clear whether the caller of M_TRAILINGSPACE()/M_LEADINGSPACE()
> > is responsible for checking for writability, or the macros themselves.
> > It seems to make more sense that the caller would be responsible...
> > why would you call M_TRAILINGSPACE() unless you
On Fri, 31 May 2002, Archie Cobbs wrote:
>
> It's not clear whether the caller of M_TRAILINGSPACE()/M_LEADINGSPACE()
> is responsible for checking for writability, or the macros themselves.
> It seems to make more sense that the caller would be responsible...
> why would you call M_TRAILINGSPAC
On Fri, May 31, 2002 at 01:25:09PM -0700, Archie Cobbs wrote:
[...]
> As a temporary saftey measure, I'll add M_WRITABLE(m) into the
> M_TRAILINGSPACE() macro. However, I see this as a temporary hack;
> the correct fix is to put the burden of writability on the caller.
> After all, M_TRAILINGSPAC
On Fri, May 31, 2002 at 12:54:39PM -0700, Julian Elischer wrote:
>
>
> On Fri, 31 May 2002, Bosko Milekic wrote:
>
> >
> > I don't remember why the ext_size here was this originally (as you
> > mention, it was imported that way), but it certainly seems bogus and
> > you catching it now
On Fri, 31 May 2002, Bosko Milekic wrote:
>
> I don't remember why the ext_size here was this originally (as you
> mention, it was imported that way), but it certainly seems bogus and
> you catching it now is hopefully going to solve some really wierd and
> difficult-to-debug problems
When I added these fields in freebsd1.x
(They may have gone through some metamorphesis since)
it was to support some stuff we were doing at TFS.
They were variants of similar fields in BSD4.3 RENO.
The problem that can occur is that the code that splits
the data can end up having two references
On Fri, May 31, 2002 at 11:29:20AM -0700, Archie Cobbs wrote:
> Hi,
>
> There is an inconsistency in the kernel mbuf code around the
> "m->m_ext.ext_size" field of an M_EXT mbuf.
>
> At first glance you might assume that this field is the total amount
> of contiguous space available in the exte
On Fri, May 31, 2002 at 11:29:20AM -0700, Archie Cobbs wrote:
...
if you add the additional Note, then it might be worthwhile that the
writability of the returned buffer should be checked in the
standard way (whatever macro it is, i forget the name).
cheers
luigi
>
> --- kern/u
11 matches
Mail list logo
