I observed it in mac layer. Specifically in mac_promisc_dispatch_one. I check the original packet to make sure that it is not malformed i.e (db_base <= b_rptr <= b_wptr <= db_lim) and MBLKL for original is non-zero. Is there any workaround? Is there any address alignment or data size factor involved?
-SF ________________________________ From: James Carlson <carls...@workingcode.com> To: Paul Durrant <pdurr...@gmail.com> Cc: Saadia Fatima <saadiafat...@yahoo.com>; opensolaris-code@opensolaris.org Sent: Friday, October 22, 2010 7:23:24 Subject: Re: [osol-code] copymsg and MBLK On 10/22/10 05:32, Paul Durrant wrote: > MBLKL(mp) is merely the difference between mp->b_wptr and mp->b_rptr, > which is state usually specific to usage of a particular *instance* of > a STREAMS message buffer. Such state is not copied across by > copymsg(). Think of copymsg() as dupmsg() but with a duplicate dblk_t > rather than a reference to the original. That's not quite right. Look at the source: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/stream.c#copyb The copymsg() function calls copyb(), and the latter sets up b_wptr and b_rptr for each new mblk. It has to. If it didn't, then the copy would be entirely worthless. >> When I copy a message block (mblk_t, with a non-zero length) using copymsg, >> the >>value returned by MBLKL for the copy is zero. >> >> len = MBLKL(m); //say 80 >> mc = copymsg(m); >> len = MBLKL(mc);// returns 0 ??? That sounds like a bug of some sort, though it's not clear what the bug might be. A possible answer would be that the original message was owned by someone else and was being modified during this process ... but that would take some unusual timing to make happen. -- James Carlson 42.703N 71.076W <carls...@workingcode.com>
_______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
