summaryrefslogtreecommitdiffstats
path: root/sys/kern/subr_mbuf.c
Commit message (Collapse)AuthorAgeFilesLines
* Bring in mbuma to replace mballoc.bmilekic2004-05-311-1548/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mbuma is an Mbuf & Cluster allocator built on top of a number of extensions to the UMA framework, all included herein. Extensions to UMA worth noting: - Better layering between slab <-> zone caches; introduce Keg structure which splits off slab cache away from the zone structure and allows multiple zones to be stacked on top of a single Keg (single type of slab cache); perhaps we should look into defining a subset API on top of the Keg for special use by malloc(9), for example. - UMA_ZONE_REFCNT zones can now be added, and reference counters automagically allocated for them within the end of the associated slab structures. uma_find_refcnt() does a kextract to fetch the slab struct reference from the underlying page, and lookup the corresponding refcnt. mbuma things worth noting: - integrates mbuf & cluster allocations with extended UMA and provides caches for commonly-allocated items; defines several zones (two primary, one secondary) and two kegs. - change up certain code paths that always used to do: m_get() + m_clget() to instead just use m_getcl() and try to take advantage of the newly defined secondary Packet zone. - netstat(1) and systat(1) quickly hacked up to do basic stat reporting but additional stats work needs to be done once some other details within UMA have been taken care of and it becomes clearer to how stats will work within the modified framework. From the user perspective, one implication is that the NMBCLUSTERS compile-time option is no longer used. The maximum number of clusters is still capped off according to maxusers, but it can be made unlimited by setting the kern.ipc.nmbclusters boot-time tunable to zero. Work should be done to write an appropriate sysctl handler allowing dynamic tuning of kern.ipc.nmbclusters at runtime. Additional things worth noting/known issues (READ): - One report of 'ips' (ServeRAID) driver acting really slow in conjunction with mbuma. Need more data. Latest report is that ips is equally sucking with and without mbuma. - Giant leak in NFS code sometimes occurs, can't reproduce but currently analyzing; brueffer is able to reproduce but THIS IS NOT an mbuma-specific problem and currently occurs even WITHOUT mbuma. - Issues in network locking: there is at least one code path in the rip code where one or more locks are acquired and we end up in m_prepend() with M_WAITOK, which causes WITNESS to whine from within UMA. Current temporary solution: force all UMA allocations to be M_NOWAIT from within UMA for now to avoid deadlocks unless WITNESS is defined and we can determine with certainty that we're not holding any locks when we're M_WAITOK. - I've seen at least one weird socketbuffer empty-but- mbuf-still-attached panic. I don't believe this to be related to mbuma but please keep your eyes open, turn on debugging, and capture crash dumps. This change removes more code than it adds. A paper is available detailing the change and considering various performance issues, it was presented at BSDCan2004: http://www.unixdaemons.com/~bmilekic/netbuf_bmilekic.pdf Please read the paper for Future Work and implementation details, as well as credits. Testing and Debugging: rwatson, brueffer, Ketrien I. Saihr-Kesenchedra, ... Reviewed by: Lots of people (for different parts)
* At some point during the history of m_getcl(), MAC support began torwatson2004-04-161-6/+6
| | | | | | | | | unconditionally initialize the mbuf header even if cluster allocation failed, which could result in a NULL pointer dereference in low-memory conditions. PR: kern/65548 Submitted by: Stephan Uphoff <ups@tree.com>
* Track current and peak sfbuf usage, export the values via sysctl.silby2003-12-271-0/+6
|
* Pass MTX_DEF as the last argument to mtx_init() instead of 0. Thistruckman2003-12-071-2/+2
| | | | | is not a functional change. The code happened to work properly only because MTX_DEF is defined as 0.
* Change all SYSCTLS which are readonly and have a related TUNABLEsilby2003-10-211-4/+4
| | | | | from CTLFLAG_RD to CTLFLAG_RDTUN so that sysctl(8) can provide more useful error messages.
* Use constants less throughout the code and instead use the objsizebmilekic2003-08-161-6/+6
| | | | | | | variable. This makes changing the size of an mbuf or cluster for testing/debugging/whatever purposes easier. Submitted by: sam
* Now that we can call kmem_malloc without Giant it should be safedwmalone2003-07-271-2/+0
| | | | | to do mbuf allocation without Giant, so remove the GIANT_REQUIRED from mb_alloc in the M_TRYWAIT case.
* Don't attempt to inline large functions mb_alloc() and mb_free(),phk2003-07-221-2/+2
| | | | | | it more than doubles the text size of this file. GCC has wisely ignored us on this previously
* Use __FBSDID().obrien2003-06-111-2/+3
|
* Fix a potential bucket leak where when freeing to an empty bucketbmilekic2003-06-031-57/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | we failed to put the bucket back into the general cache/container. Also, fix a bad assumption. There was a KASSERT() that aimed to guarantee that whenever the pcpu container's mc_starved was > 0, that whatever the bucket we were freeing to was an empty bucket, assuming it belonged to the pcpu container cache. However, there is at least one case where this is not true anymore; consider: 1) All containers empty, next thread to try to alloc will touch a pcpu container, notice it's empty, and increment the pcpu container's mc_starved. 2) Some other thread frees an mbuf belonging to a bucket in the general cache/container. Then it frees another mbuf belonging to the same bucket (still in gen container). 3) Some third thread tries to allocate an mbuf from the pcpu container and, since empty, grabs one mbuf now available in the general cache and moves the non-empty bucket from which it took 1 mbuf and to which the thread in (2) freed to, and moves it to the pcpu container. 4) A final thread tries to free an mbuf belonging to the NON-EMPTY bucket mentionned in (2) and (3) and, since the pcpu container's mc_starved is > 0, but the bucket is obviously non-empty, it trips on the KASSERT. This meant that one could potentially get a panic in some cases when out of mbufs and clusters. The problem could be mitigated by commenting out some cv_signal() calls, but I'm assuming that was pure coincidence and this is the correct fix.
* Add an INVARIENTS only check to make sure Giant is held if mbufdwmalone2003-05-291-0/+2
| | | | | | | allocation is attempted with M_TRYWAIT. Reviewed by: bmilekic Approved by: re (scottl)
* Make the mb_alloc low-watermark sysctl-tunable read-only and makebmilekic2003-05-151-2/+5
| | | | | | | | netstat(1) not display it for now because its effects are not yet completely implemented and we're about to cut 5.2-RELEASE. This is temporary. Approved by: re (scottl, rwatson)
* Make m_freem() just use m_free() instead of duplicating the code. Thebmilekic2003-05-101-32/+2
| | | | | | | | | | | | | | reason for the duplication was that m_freem() was meant to eventually be optimized to hold the lock of the cache being freed to as long as possible across frees but the difficulty of implementing said optimization right now is too high, given that in some cases (see MAC and non-cluster external buffers), we need to call into other subsytems, something not permissible when the cache lock is held. This change minimizes code duplication while keeping at least the atomic mbuf+cluster free optimization. Suggested by: luigi
* Add the M_FREELIST flag, which is used to detect whenever asilby2003-05-021-0/+10
| | | | | | | | | | | double free of a mbuf occurs and cause an immediate panic, rather than allowing free list corruption to occur. This code is trapped under INVARIANTS, so it should not cause any change in default performance. Reviewed by: a bunch of people on -net MFC after: 1 week
* Fix some easy, global, lint warnings. In most cases, this meansmarkm2003-04-301-1/+1
| | | | | making some local variables static. In a couple of cases, this means removing an unused variable.
* Move MAC label storage for mbufs into m_tags from the m_pkthdr structure,rwatson2003-04-141-17/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | returning some additional room in the first mbuf in a chain, and avoiding feature-specific contents in the mbuf header. To do this: - Modify mbuf_to_label() to extract the tag, returning NULL if not found. - Introduce mac_init_mbuf_tag() which does most of the work mac_init_mbuf() used to do, except on an m_tag rather than an mbuf. - Scale back mac_init_mbuf() to perform m_tag allocation and invoke mac_init_mbuf_tag(). - Replace mac_destroy_mbuf() with mac_destroy_mbuf_tag(), since m_tag's are now GC'd deep in the m_tag/mbuf code rather than at a higher level when mbufs are directly free()'d. - Add mac_copy_mbuf_tag() to support m_copy_pkthdr() and related notions. - Generally change all references to mbuf labels so that they use mbuf_to_label() rather than &mbuf->m_pkthdr.label. This required no changes in the MAC policies (yay!). - Tweak mbuf release routines to not call mac_destroy_mbuf(), tag destruction takes care of it for us now. - Remove MAC magic from m_copy_pkthdr() and m_move_pkthdr() -- the existing m_tag support does all this for us. Note that we can no longer just zero the m_tag list on the target mbuf, rather, we have to delete the chain because m_tag's will already be hung off freshly allocated mbuf's. - Tweak m_tag copying routines so that if we're copying a MAC m_tag, we don't do a binary copy, rather, we initialize the new storage and do a deep copy of the label. - Remove use of MAC_FLAG_INITIALIZED in a few bizarre places having to do with mbuf header copies previously. - When an mbuf is copied in ip_input(), we no longer need to explicitly copy the label because it will get handled by the m_tag code now. - No longer any weird handling of MAC labels in if_loop.c during header copies. - Add MPC_LOADTIME_FLAG_LABELMBUFS flag to Biba, MLS, mac_test. In mac_test, handle the label==NULL case, since it can be dynamically loaded. In order to improve performance with this change, introduce the notion of "lazy MAC label allocation" -- only allocate m_tag storage for MAC labels if we're running with a policy that uses MAC labels on mbufs. Policies declare this intent by setting the MPC_LOADTIME_FLAG_LABELMBUFS flag in their load-time flags field during declaration. Note: this opens up the possibility of post-boot policy modules getting back NULL slot entries even though they have policy invariants of non-NULL slot entries, as the policy might have been loaded after the mbuf was allocated, leaving the mbuf without label storage. Policies that cannot handle this case must be declared as NOTLATE, or must be modified. - mac_labelmbufs holds the current cumulative status as to whether any policies require mbuf labeling or not. This is updated whenever the active policy set changes by the function mac_policy_updateflags(). The function iterates the list and checks whether any have the flag set. Write access to this variable is protected by the policy list; read access is currently not protected for performance reasons. This might change if it causes problems. - Add MAC_POLICY_LIST_ASSERT_EXCLUSIVE() to permit the flags update function to assert appropriate locks. - This makes allocation in mac_init_mbuf() conditional on the flag. Reviewed by: sam Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
* Use MBTOM() to convert mbuf allocator flags to malloc() flags, ratherrwatson2003-04-141-3/+2
| | | | | | | than using the same compare/substitute in many places. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
* PHCC[1]:phk2003-03-101-2/+2
| | | | | | | | | | I had commented the #ifdef INVARIANTS checks out to make sure I ran this code in all kernels and forgot to comment the #ifdefs back in before I committed. Spotted by: bmilekic [1] PHCC = Pointy Hat Correction Commit
* Make malloc and mbuf allocation mode flags nonoverlapping.phk2003-03-101-0/+15
| | | | | | Under INVARIANTS whine if we get incompatible flags. Submitted by: imp
* Replace calls to WITNESS_SLEEP() and witness_list() with equivalent callsjhb2003-03-041-9/+2
| | | | to WITNESS_WARN().
* o Allow "buckets" in mb_alloc to be differently sized (according tobmilekic2003-02-201-73/+112
| | | | | | | | | | | | | | | | compile-time constants). That is, a "bucket" now is not necessarily a page-worth of mbufs or clusters, but it is MBUF_BUCK_SZ, CLUS_BUCK_SZ worth of mbufs, clusters. o Rename {mbuf,clust}_limit to {mbuf,clust}_hiwm and introduce {mbuf,clust}_lowm, which currently has no effect but will be used to set the low watermarks. o Fix netstat so that it can deal with the differently-sized buckets and teach it about the low watermarks too. o Make sure the per-cpu stats for an absent CPU has mb_active set to 0, explicitly. o Get rid of the allocate refcounts from mbuf map mess. Instead, just malloc() the refcounts in one shot from mbuf_init() o Clean up / update comments in subr_mbuf.c
* Fix a serious bug when computing the index for thebmilekic2003-02-201-1/+1
| | | | | | | reference counter array for mbuf clusters. I don't know how this got past early testing nor how it survived so long without getting caught. If anyone was seeing really really bizarre memory corruption in a few mbufs this would be why.
* Back out M_* changes, per decision of the TRB.imp2003-02-191-22/+22
| | | | Approved by: trb
* Make m_getm() always return the top of the newly allocated chain, asbmilekic2003-02-141-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | opposed to returning the top of the old chain when there was one and the top of the newly allocated chain if there was no old chain. Actually, it should be noted that prior to this fix, although the comment above m_getm() advertised that m_getm() would return the top of the old chain (if an old chain was being passed in) it actually [wrongly] was returning the tail mbuf in the old chain instead. This is a bug but since the one use of m_getm() in the tree luckily did not depend on the behavior, it happened to work out without notice. Harti Brandt pointed out that the advertised behavior was actually not the real behavior and so this change makes m_getm() ALWAYS return the newly allocated chain (and fixes the comment). This is less confusing and is the best course of action as then the caller is always able to have both a reference to the top of the original chain (because it's passing it in in the call) and a reference to the newly attached chain. Although the API is slightly modified, I don't think that any third-party code uses m_getm() and if it does, it surely can't be working properly because the old behavior was bogus. API bug pointed out by: Harti Brandt <brandt@fokus.fraunhofer.de>
* Remove M_TRYWAIT/M_WAITOK/M_WAIT. Callers should use 0.alfred2003-01-211-22/+22
| | | | Merge M_NOWAIT/M_DONTWAIT into a single flag M_NOWAIT.
* o Introduce a new external mbuf type, EXT_EXTREF.gallatin2003-01-021-3/+8
| | | | | | | | | | | | | | | | | o Allow callers of m_extadd() to allocate their own reference m_ext.ref_cnt pointer, rather than having the mbuf system allocate it with a malloc() in the critical path. This speeds m_extadd() up, and also simplifies locking (malloc() may need Giant). A driver or subsystem wishing to take use its own ref counter must initialize m_ext.ref_cnt to point to its ref counter prior to calling m_extadd(), and it must use EXT_EXTREF as its external type. Eg: m->m_ext.ref_cnt = my_ref_cnt_ptr; m_extadd(.....,EXT_EXTREF); Reviewed by: bosko
* o Initialise each mbuf's m_len to 0 in m_getm(); mb_put_mem() dependstjr2002-11-271-1/+3
| | | | | | | | | on this. o Update the `cur' pointer in the cluster loop in m_getm() to avoid incorrect truncation and leaked mbufs. Reviewed by: bmilekic Approved by: re
* Fix a fairly subtle bug in mbuf_init() where the reference counterbmilekic2002-10-161-1/+1
| | | | | | | | contiguous space was being allocated from the clust_map instead of the mbuf_map as the comments indicated. This resulted in some address space wastage in mbuf_map. Submitted by: Rohit Jalan <rohjal@yahoo.co.in>
* Replace aux mbufs with packet tags:sam2002-10-161-14/+7
| | | | | | | | | | | | | | | | | | | o instead of a list of mbufs use a list of m_tag structures a la openbsd o for netgraph et. al. extend the stock openbsd m_tag to include a 32-bit ABI/module number cookie o for openbsd compatibility define a well-known cookie MTAG_ABI_COMPAT and use this in defining openbsd-compatible m_tag_find and m_tag_get routines o rewrite KAME use of aux mbufs in terms of packet tags o eliminate the most heavily used aux mbufs by adding an additional struct inpcb parameter to ip_output and ip6_output to allow the IPsec code to locate the security policy to apply to outbound packets o bump __FreeBSD_version so code can be conditionalized o fixup ipfilter's call to ip_output based on __FreeBSD_version Reviewed by: julian, luigi (silent), -arch, -net, darren Approved by: julian, silence from everyone else Obtained from: openbsd (mostly) MFC after: 1 month
* Be consistent about "static" functions: if the function is markedphk2002-09-281-1/+1
| | | | | | static in its prototype, mark it static at the definition too. Inspired by: FlexeLint warning #512
* Make m_flags an int instead of a short, this is consistent with thebmilekic2002-08-151-1/+1
| | | | | | | | | type of the 'flags' argument m_getcl() was using anyway; m_extadd() needed to be changed to accept an int instead of a short for 'flags.' This makes things more consistent and also gives us more bits to use for m_flags in the future (we have almost run out). Requested by: sam (Sam Leffler)
* Only my brain can fart while fixing a previous brain fart.bmilekic2002-08-081-2/+1
|
* YIKES, I take the pointy-hat for a really big braino here. Ibmilekic2002-08-081-4/+3
| | | | | | | | | appologize to those of you who may have been seeing crashes in code that uses sendfile(2) or other types of external buffers with mbufs. Pointed out by, and provided trace: Niels Chr. Bank-Pedersen <ncbp at bank-pedersen.dk>
* Correct a bug introduced in 1.26: M_PKTHDR is set in the 'flags'rwatson2002-08-071-1/+1
| | | | | | | | | argument, not the 'type' argument. As a result of the buf, the MAC label on some packet header mbufs might not be set in mbufs allocated using m_getcl(), resulting in a page fault. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
* Move the MAC label init/destroy stuff to more appropriate places so thatbmilekic2002-08-011-10/+20
| | | | | | the inits/destroys are done without the cache locks held even in the persistent-lock calls. I may be cheating a little by using the MAC "already initialized" flag for now.
* Introduce support for Mandatory Access Control and extensiblerwatson2002-07-311-1/+22
| | | | | | | | | | | | | | | | kernel access control. Invoke the necessary MAC entry points to maintain labels on header mbufs. In particular, invoke entry points during the two mbuf header allocation cases, and the mbuf freeing case. Pass the "how" argument at allocation time to the MAC framework so that it can determine if it is permitted to block (as with policy modules), and permit the initialization entry point to fail if it needs to allocate memory but is not permitted to, failing the mbuf allocation. Obtained from: TrustedBSD Project Sponsored by: DARPA, NAI Labs
* Make reference counting for mbuf clusters [only] work like in RELENG_4.bmilekic2002-07-301-49/+37
| | | | | | | | | | | | | | | While I don't think this is the best solution, it certainly is the fastest and in trying to find bottlenecks in network related code I want this out of the way, so that I don't have to think about it. What this means, for mbuf clusters anyway is: - one less malloc() to do for every cluster allocation (replaced with a relatively quick calculation + assignment) - no more free() in the cluster free case (replaced with empty space) :-) This can offer a substantial throughput improvement, but it may not for all cases. Particularly noticable for larger buffer sends/recvs. See http://people.freebsd.org/~bmilekic/code/measure2.txt for a rough idea.
* Move m_freem() from uipc_mbuf.c to subr_mbuf.c so it can take advantagebmilekic2002-07-241-0/+48
| | | | | | | | | | | of the inlines, like its cousin, m_free(). Also, make a small (first step?) optimisation of m_free() to use the MBP_PERSIST{,ENT} interface to hold the lock across frees when possible. The thing is that right now, we can only do this easily for at most across one mbuf + one cluster free, as the comment mentions (it also explains why). Anyway, some basic tests revealed a 5-10% overall improvement. Some of the results can be found here: http://people.freebsd.org/~bmilekic/code/measure.txt
* Introduce mb_free() to the MBP_PERSIST{,ENT} interface. What this meansbmilekic2002-07-231-17/+70
| | | | | | | | | | | | | | | is that grouped frees will be done as most often as possible without dropping the cache lock in between. So, for the most part, they'll be done without the lock being dropped. This is particularly true if you have something that does a grouped m_getm() or m_getcl() (a cluster and mbuf at the same time) - most likely getting the buffers from the same per-CPU cache - and then frees them with m_free{,m}(). Unless the buffers' underlying buckets were moved, the free will be done without the lock getting dropped in between. So far, only m_free() has been shown how to do this, and m_freem() will shortly follow. Since I'm here, I also fixed a small (but mostly harmless) type-mismatch introduced in the last commit.
* o Introduce new m_getcl() interface routine that allocates an mbufbmilekic2002-07-151-74/+395
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and a cluster in one shot. o Introduce MBP_PERSIST and MBP_PERSISTENT control bits to mb_alloc(); MBP_PERSIST means "if you can allocate, then keep the cache lock held on exit," and MBP_PERSISTENT means "a cache lock is alredy held on entry, so allocate from the specified (already locked) cache." They may be used in combination. o m_getcl() uses the MBP_PERSIST/MBP_PERSISTENT interface so that it doesn't drop the cache lock in between the mbuf and cluster allocations. o m_getm(), which takes a size and allocates an mbuf + cluster "best fit" chain, has been moved from uipc_mbuf.c to subr_mbuf.c and shown how to use MBP_PERSIST/MBP_PERSISTENT to attempt to do a grouped allocation without dropping the cache lock in between. Why this is good: much less bus-locked lock acquires/drops when they're not needed. Also, prototype for m_getcl(): struct mbuf * m_getcl(int how, short type, int flags); "how" and "type" are self-explanatory. "flags" may be M_PKTHDR, in which case m_getcl() will make the mbuf a pkthdr-mbuf. While I'm in subr_mbuf.c: o Every exported routine now has a nice comment with a description of the expected arguments. Eventually, mbuf(9) needs to be re-vamped but there's still more code to write/finalize before I get to that. o internal macros have been changed a bit. o consistently use 'short' for "type." This somehow slipped through before (that 'type' was sometimes declared as int). Alfred has been pushing for the MBP_PERSIST{,ENT} thing for almost a year now. Luigi asked for m_getcl(), and will probably MFC that part of this commit. TODO [Related]: teach mb_free() about MBP_PERSIST{, ENT}.
* m_extadd takes a void (*freef)(void *, void *) now, not aalfred2002-06-291-1/+1
| | | | void (*freef)(caddr_t, void *).
* Set system_map for both mbuf_map and clust_map to 1, in mbuf_init().bmilekic2002-06-131-2/+4
| | | | | Submitted by: Tor Egge (tegge) Pointed out to me by: hsu
* Separate "seperate" from kernel source.eric2002-05-161-1/+1
|
* Remove a printf(3) argument with no corresponding format specifier.des2002-05-141-1/+1
|
* Change the mbuf exhaustion warning message to match the messagesilby2002-05-091-1/+2
| | | | in -stable.
* Change callers of mtx_init() to pass in an appropriate lock type name. Injhb2002-04-041-2/+2
| | | | | | | most cases NULL is passed, but in some cases such as network driver locks (which use the MTX_NETWORK_LOCK macro) and UMA zone locks, a name is used. Tested on: i386, alpha, sparc64
* Fix bug in mb_alloc that made systems configured withbmilekic2002-03-031-3/+1
| | | | | | | | | | PAGE_SIZE / MCLBYTES == 1 crash. Fix them by changing the appropriate "allocate new page and bucket" code in mb_alloc to use the macro for properly grabbing an allocated object from a bucket, the one that checks whether the bucket is empty. This should allow ken to continue testing zero-copy stuff on -CURRENT. Noticed and provided debug info: ken
* On the first day of Christmas bde gave to me:bmilekic2001-12-231-143/+132
| | | | | | | | A [hopefully] conforming style(9) revamp of mb_alloc and related code. (This was possible due to bde's remarkable patience.) Submitted by: (in large part) bde Reviewed by: (the other part) bde
* Move prototype of _mext_free to mbuf.h, where it belongs, because it isbmilekic2001-12-221-1/+0
| | | | | | | used in MEXTFREE and needs to be in scope for external MEXTFREE users. Pointed out by: Chad David <davidc@acns.ab.ca> Confirmed by: bde
* vm/vm_kern.c: rate limit (to once per second) diagnostic printf whenluigi2001-12-011-1/+14
| | | | | | | | | | | | | | | | | | | | | you run out of mbuf address space. kern/subr_mbuf.c: print a warning message when mb_alloc fails, again rate-limited to at most once per second. This covers other cases of mbuf allocation failures. Probably it also overlaps the one handled in vm/vm_kern.c, so maybe the latter should go away. This warning will let us gradually remove the printf that are scattered across most network drivers to report mbuf allocation failures. Those are potentially dangerous, in that they are not rate-limited and can easily cause systems to panic. Unless there is disagreement (which does not seem to be the case judging from the discussion on -net so far), and because this is sort of a safety bugfix, I plan to commit a similar change to STABLE during the weekend (it affects kern/uipc_mbuf.c there). Discussed-with: jlemon, silby and -net
OpenPOWER on IntegriCloud