Adrian Chadd 5799c2bce7 [iwm] Fix up busdma use in the RX path
When allocating a new mbuf or bus_dmamap_load()-ing it fails,
we can just keep the old mbuf since we are dropping that packet anyway.
Instead of doing bus_dmamap_create() and bus_dmamap_destroy() all the time,
create an extra bus_dmamap_t which we can use to safely try
bus_dmamap_load()-ing the new mbuf. On success we just swap the spare
bus_dmamap_t with the data->map of that ring entry.

Tested:

Tested with Intel AC7260, verified with vmstat -m that new kernel no
longer visibly leaks memory from the M_DEVBUF malloc type.
Before, leakage was 1KB every few seconds while ping(8)-ing over the wlan
connection.

Submitted by:	Imre Vadasz <imre@vdsz.com>
Approved by:	re@
Obtained from:	DragonflyBSD.git cc440b26818b5dfdd9af504d71c1b0e6522b53ef
Differential Revision:	https://reviews.freebsd.org/D6742
2016-06-13 00:13:20 +00:00
..
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-06-07 19:08:13 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-04-21 19:48:28 +00:00
2016-05-10 16:40:19 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 17:11:33 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-04 06:24:10 +00:00
2016-05-17 12:52:31 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-04 06:24:51 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-06-05 18:16:33 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-03-22 06:24:52 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-27 11:37:02 +00:00
2016-05-03 03:41:25 +00:00
2016-05-26 11:12:36 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-04 06:23:49 +00:00
2016-05-03 03:41:25 +00:00
2016-06-08 14:22:16 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-17 12:52:31 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-09 19:28:22 +00:00
2016-05-17 12:52:31 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-17 12:52:31 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-26 22:43:02 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-03-01 17:47:32 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-06-01 14:03:13 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-06-04 07:18:39 +00:00
2016-05-14 06:07:15 +00:00
2016-03-01 17:47:32 +00:00
2016-05-03 03:41:25 +00:00
2016-05-03 03:41:25 +00:00
2016-05-02 16:47:28 +00:00
2016-05-20 08:58:06 +00:00
2016-05-03 03:41:25 +00:00
2016-05-02 16:47:28 +00:00
2016-05-03 03:41:25 +00:00
2016-04-19 15:36:18 +00:00
2016-05-03 03:41:25 +00:00