Re: [PATCH] unneeded variable and simplification of uipc_mbuf.c

["Bret Lambert" <bret.lambert@xxxxxxxxx>]

preface: apologies for crazy line breaks and the such;
I'm using the gmail web interface.

On 10/24/06, Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
[snip]
> :Are you sure m_copym is never called with an off0 of > 0 < ?
> :
> :Cheers,
> :--
> :         Thomas E. Spanjaard
> :         tgen@xxxxxxxxxxxxx
>
>    I see one case where it can be, a call to sctp_m_copym()
>    from sctp_add_cookie() looks like it could potentially pass
>    a non-zero offset in combination with M_COPYALL.
>
>    The issue here isn't so much whether the case occurs or not,
>    but whether m_copym should generically allow the case or not.

That's definitely beyond my pay grade; I'll leave it to you to hash
that one out. I'm just making known a subtle issue that's been in
BSD code (apparently, as it appears in Open, Net, Free, and
DragonFly) since the 4.4 days.

>    If not, then an assertion would be appropriate.  We definitely
>    do not want to simply ignore the variable, though.

The variable isn't being ignored; it's just a copy of off, and is only
used when it's known to be zero (and thus ends up being a no-op),
and can be safely culled.

>    This bit of code in the originanl m_copym looks wrong, or at
>    least confusing enough that I don't understand what it is trying to
>    do in the len != M_COPYALL case.

If not copying all of the mbuf chain, it sets the packet header length
field to reflect the length of the data that's being copied into the
new chain.

>                if (copyhdr) {
>                        if (!m_dup_pkthdr(n, m, wait))
>                                goto nospace;
>                        if (len == M_COPYALL)
>                                n->m_pkthdr.len -= off0;
>                        else
>                                n->m_pkthdr.len = len;
>                        copyhdr = 0;
>                }
>
>                                        -Matt
>                                        Matthew Dillon
>                                        <dillon@xxxxxxxxxxxxx>