Date: Fri, 10 Nov 2000 00:54:09 -0500 (EST) From: Bosko Milekic <bmilekic@dsuper.net> To: freebsd-net@freebsd.org Subject: M_RDONLY: review & comment Message-ID: <Pine.BSF.4.21.0011100039040.92343-100000@jehovah.technokratis.com>
next in thread | raw e-mail | index | archive | help
Hi, It's been about 4 months since this was last discussed... The updated and merged diff adding M_RDONLY flag for mbufs is now available here: http://people.freebsd.org/~bmilekic/mb_rdonly.diff Please review and comment. It does the following: * Adds M_RDONLY flag for mbufs, which basically means "don't tamper with my data region." A macro, M_WRITABLE() is provided which will evaluate true if: (a) mbuf does not have M_RDONLY bit set in its flags ...and... (b) either: (i) mbuf is "regular" mbuf with no ext_buf (i.e. no M_EXT) or (ii) mbuf is M_EXT and reference count is not above 1. Hopefully this will replace all the scattered "is this mbuf writable" checks, at least eventually. * m_pulldown() ; replaced "sharedcluster" variable with one called "writable." This code is still somewhat flawed. Checkout the comment in the diff for a good explanation on how it works and what still needs to be done. But, a decent start on using M_WRITABLE() to determine "writability." * Added m_ext.ext_type which holds either EXT_CLUSTER, EXT_SFBUF, ... better than checking whether there is an installed ext_free to determine whether ext_buf is cluster. * Made sendfile(2)'s sf_bufs explicitly make their buffers M_RDONLY to the mbuf system. If M_WRITABLE() is used on an mbuf with an sf_buf for an ext_buf, then it will never evaluate "writable," but always "read-only." * Small tiny tiny fix in netinet/ip_fil.c, diff is self-explanatory. * netinet6/ipsec.c should probably eventually be checked out (see diff for exact spot where) to be made to use M_WRITABLE as an approach to determining whether to make a copy or not... wasn't 100% sure on what to do with it immediately. I think that's it. It's really not that much and the diff is a mere 10K. Reviews and comments welcomed, I'd like to commit this soon and get the PR closed, unless anyone has objections. dwmalone, anything to add? (I modified the behavior in m_pulldown() just a bit w.r.t. the original patch, so feel free to glance at that). Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0011100039040.92343-100000>