Hi,
Some specific implementation of the Clearview UV component requires the
dupb() function to copy mblk_t's b_flag field. We'd like to get your opinion
that whether you see any risk there.
See more details in the forwarded mail.
Thanks
- Cathy
--- Begin Message ---
> I found there are two problems:
>
> 1. When ce driver sends a packet, it loops back the packet is the stream is
> in the DL_PROMISC_SAP mode, which is incorrect. The packet should only be
> loop back if the stream is in DL_PROMISC_PHYS mode.
>
> 2. When ce loops back the packet, it calls dupmsg() to duplicate the
> message. But dupb() does not copy the b_flags flag as copyb() does. This
> makes the MSGNOLOOP flag to be removed.
>
> The MSGNOLOOP flag is set when Nemo sents the packets down to the legacy
> driver. It is used by Nemo to identify this kind of packets looped back from
> legacy drivers. For example, in aggr_recv_cb() function, there is code like:
>
> /*
> * If this message is looped back from the legacy devices, drop
> * it as the Nemo framework will be responsible for looping it
> * back by the mac_txloop() function.
> */
> if (mp->b_flag & MSGNOLOOP) {
> ASSERT(mp->b_next == NULL);
> freemsg(mp);
> return;
> }
>
> My question is: If I copy the b_flags flag in dupb() function, will it cause
> any problem?
Great question. In general, I'd say no, just because a lot of code uses
dupb() and copyb() (or dupmsg() and copymsg()) in sequence -- i.e., they
first try dupb()/dupmsg() and if that fails they try copyb()/copymsg().
Also, having dupb() copy b_flags is consistent with the manpage, which
states "The new mblk_t structure contains the same information as the
original." That said, it's never copied b_flags, so who knows what you
might smoke out by making such a change.
--
meem
--- End Message ---
_______________________________________________
networking-discuss mailing list
[email protected]
