* Re: [PATCH] sctp: Do not trigger BUG_ON when deleting assoc without primary path
From: Daniel Borkmann @ 2013-10-17 18:01 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, linux-sctp, Mark Thomas, Neil Horman
In-Reply-To: <1382031042-27339-1-git-send-email-vyasevich@gmail.com>
On 10/17/2013 07:30 PM, Vlad Yasevich wrote:
> It is possible to enter sctp_cmd_delete_tcb() without having a
> primary path. The situations this most often happens in is
> when duplication cookie processing is triggered. In this
> case, we are deleting a temporarily created association that
> is not fully populated. Additially, at the time we
> are deleting the offending association, it is really too
> late to issue a BUG!
>
> This was introduced by:
> commit f9e42b853523cda0732022c2e0473c183f7aec65
> net: sctp: sideeffect: throw BUG if primary_path is NULL
Sure, lets remove it, but then we could still get a WARN() [sure,
better than BUG], if the user at the very same time checks procfs
through sctp_seq_dump_local_addrs(), see discussion we had here [1]:
It may trigger the crash later if the user performs some action on the
association that touches the primary. That's the reason why I was
proposing the checks below.
With the checks in command interpreter, we are only left with the
possibility that primary_path changes to NULL during the association
lifetime, which code audit doesn't support right now. If that ever
changes we would at least have a bit more information to go on.
[1] http://patchwork.ozlabs.org/patch/251099/
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index 666c668..1a6eef3 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -860,7 +860,6 @@ static void sctp_cmd_delete_tcb(sctp_cmd_seq_t *cmds,
> (!asoc->temp) && (sk->sk_shutdown != SHUTDOWN_MASK))
> return;
>
> - BUG_ON(asoc->peer.primary_path == NULL);
> sctp_unhash_established(asoc);
> sctp_association_free(asoc);
> }
>
^ permalink raw reply
* Re: transmit lockup using smsc95xx ethernet on usb3
From: Alan Stern @ 2013-10-17 18:07 UTC (permalink / raw)
To: Sarah Sharp
Cc: David Laight, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Xenia Ragiadakou
In-Reply-To: <20131017174329.GB6256@xanatos>
On Thu, 17 Oct 2013, Sarah Sharp wrote:
> > Given the difficulty (or rather the infrequency) of reproducing the
> > problem I'd like to sort out the failing code path before changing
> > kernels so that I can then verify that a more recent kernel fixes it.
>
> The problem is that -ESHUTDOWN usually means there's a driver or host
> controller issue. Numerous bug fixes have gone in since 3.4 to avoid
> such host controller issues. It would be a waste of time for me to
> attempt debug your issue, only to discover it had been fixed in a more
> recent kernel. So I would really rather you test on a stable kernel,
> see if the issue still occurs, and then we can work from a known good
> base to figure out where the problem is.
-ESHUTDOWN really indicates either that the system believes the device
has been disconnected from the USB bus or that the host controller
itself has stopped working.
> > To clarify the fail trace below is from an xhci controller, but
> > I'm pretty sure we've seen a tx lockup when using ohci.
>
> Then it might not be an xHCI host specific issue.
Undoubtedly not.
> > The usbmon trace when the tx locks up starts with:
> >
> > > > Two Bo 'fail -71', 6 succeed, one fails -32 the rest fail -104.
> > > > done:9871:6913:60 ffff88020ea16a80 293818155 C Bo:3:003:2 -71 EPROTO 512 >
> > > > done:9872:6927:59 ffff88020ea16f00 293818235 C Bo:3:003:2 -71 EPROTO 0
Those -71 errors indicate a low-level problem. It generally means that
the device has stopped sending packets. Perhaps its firmware has
crashed, or perhaps it has disconnected itself electrically from the
bus.
> > Last successful ethernet transmit
> > ffff88020c4870c0 701760986 C Bo:3:018:2 0 1090 >
> > ffff88020c4870c0 701760992 S Bo:3:018:2 -115 1090
> > = 3a340000 3a440000 22003200 00224d98
> > d8460002 1f0057d7 08004500 042879ca
> > Interrupt - I think from the root hub.
> > ffff88020c8570c0 701761038 C Ii:3:001:1 0:2048 1 = 02
> > ffff88020c8570c0 701761042 S Ii:3:001:1 -115:2048 4 <
> > ffff88020ea16840 701761046 C Ii:3:018:3 -71:1 0 EPROTO
> > ffff88020ea16840 701761047 S Ii:3:018:3 -115:1 16 <
> > ffff88020c53c480 701761051 C Bi:3:018:1 -71 0
> > ffff88020c487180 701761054 C Bo:3:018:2 -71 1024 >
> > ffff880210570240 701761063 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
> > ffff880210570240 701761071 C Ci:3:001:0 0 4 = 00010100
These last two lines show the host controller telling the system that
the device has disconnected. Once that happens, any future
communication with the device is hopeless.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
From: H. Peter Anvin @ 2013-10-17 18:19 UTC (permalink / raw)
To: Ingo Molnar, Neil Horman
Cc: Eric Dumazet, linux-kernel, sebastien.dugue, Thomas Gleixner,
Ingo Molnar, x86, netdev
In-Reply-To: <20131017084121.GC22705@gmail.com>
On 10/17/2013 01:41 AM, Ingo Molnar wrote:
>
> To correctly simulate the workload you'd have to:
>
> - allocate a buffer larger than your L2 cache.
>
> - to measure the effects of the prefetches you'd also have to randomize
> the individual buffer positions. See how 'perf bench numa' implements a
> random walk via --data_rand_walk, in tools/perf/bench/numa.c.
> Otherwise the CPU might learn your simplistic stream direction and the
> L2 cache might hw-prefetch your data, interfering with any explicit
> prefetches the code does. In many real-life usecases packet buffers are
> scattered.
>
> Also, it would be nice to see standard deviation noise numbers when two
> averages are close to each other, to be able to tell whether differences
> are statistically significant or not.
>
Seriously, though, how much does it matter? All the above seems likely
to do is to drown the signal by adding noise.
If the parallel (threaded) checksumming is faster, which theory says it
should and microbenchmarking confirms, how important are the
macrobenchmarks?
-hpa
^ permalink raw reply
* Re: [PATCH net 2/9] bnx2x: Prevent an illegal pointer dereference during panic
From: David Miller @ 2013-10-17 18:21 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, ariele, eilong, dmitry
In-Reply-To: <1381847335-32662-3-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Tue, 15 Oct 2013 16:28:48 +0200
> @@ -775,6 +775,15 @@ void bnx2x_fw_dump_lvl(struct bnx2x *bp, const char *lvl)
> trace_shmem_base = bp->common.shmem_base;
> else
> trace_shmem_base = SHMEM2_RD(bp, other_shmem_base_addr);
> +
> + /* sanity */
> + if (trace_shmem_base < MCPR_SCRATCH_BASE(bp) ||
> + trace_shmem_base > MCPR_SCRATCH_BASE(bp) + 0x28000) {
I would say that this second test should be ">=" rather than ">".
Actually, there are a lot of holes still remaining here.
trace_shmem_base is validated, but then you access the signature at
0x800 bytes before trace_shmem_base value. That should be accounted
for in the test above too.
And what about that 'mark' value you read? Any validations needed on
that?
And then you read from "addr" to "mark", and I see no checks that this
range makes any sense either.
^ permalink raw reply
* Re: [PATCH] sctp: Do not trigger BUG_ON when deleting assoc without primary path
From: Daniel Borkmann @ 2013-10-17 18:25 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, linux-sctp, Mark Thomas, Neil Horman
In-Reply-To: <526025F2.2040304@redhat.com>
On 10/17/2013 08:01 PM, Daniel Borkmann wrote:
> On 10/17/2013 07:30 PM, Vlad Yasevich wrote:
>> It is possible to enter sctp_cmd_delete_tcb() without having a
>> primary path. The situations this most often happens in is
>> when duplication cookie processing is triggered. In this
>> case, we are deleting a temporarily created association that
>> is not fully populated. Additially, at the time we
>> are deleting the offending association, it is really too
>> late to issue a BUG!
>>
>> This was introduced by:
>> commit f9e42b853523cda0732022c2e0473c183f7aec65
>> net: sctp: sideeffect: throw BUG if primary_path is NULL
>
> Sure, lets remove it, but then we could still get a WARN() [sure,
> better than BUG], if the user at the very same time checks procfs
> through sctp_seq_dump_local_addrs(), see discussion we had here [1]:
>
> It may trigger the crash later if the user performs some action on the
> association that touches the primary. That's the reason why I was
> proposing the checks below.
>
> With the checks in command interpreter, we are only left with the
> possibility that primary_path changes to NULL during the association
> lifetime, which code audit doesn't support right now. If that ever
> changes we would at least have a bit more information to go on.
>
> [1] http://patchwork.ozlabs.org/patch/251099/
Meaning, all I'm saying is that with f9e42b853 we wanted to find exactly
such a case we have right now, that is, that an assoc could enter the
hashtable w/o primary path, no?
^ permalink raw reply
* Re: pull request: batman-adv 2013-10-13
From: David Miller @ 2013-10-17 18:27 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Sun, 13 Oct 2013 13:22:45 +0200
> this is our second pull request intended for net-next/linux-3.13.
>
> The most important piece in this patchset is the new packet fragmentation code
> implemented by Martin Hundebøll during his Google Summer of Code 2012[1]. This
> code is entirely substituting the current fragmentation mechanism.
>
> Other than this you have:
> - the creation of a common BAT ICMP header which makes the ICMP subsystem more
> flexible and extensible
> - the addition of a dummy rx mode handler for the soft-interface which allows
> users to set static multicast listeners
> - some minor improvements and code cleanups
>
>
> Please pull or let me know of any problem.
Pulled, thanks Antonio.
^ permalink raw reply
* pull request: wireless-next 2013-10-17
From: John W. Linville @ 2013-10-17 18:23 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
[-- Attachment #1: Type: text/plain, Size: 11716 bytes --]
Dave,
This is a batch of updates intended for the 3.13 stream...
The biggest item of interest in here is wcn36xx, the new mac80211
driver for Qualcomm WCN3660/WCN3680 hardware.
Regarding the mac80211 bits, Johannes says:
"We have an assortment of cleanups and new features, of which the
biggest one is probably the channel-switch support in IBSS. Nothing
else really stands out much."
On top of that, the ath9k and rt2x00 get a lot of update action from
Felix Fietkau and Gabor Juhos, respectively. There are a handful of
updates to other drivers here and there as well.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit ccdbb6e96beca362db876d820ac1e560ff6d9579:
tcp: tcp_transmit_skb() optimizations (2013-10-11 17:48:18 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
for you to fetch changes up to 9f96da4dd2ccf685b506a21104cb13b1aadd907a:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem (2013-10-17 14:02:07 -0400)
----------------------------------------------------------------
Amitkumar Karwar (1):
mwifiex: use alloc_workqueue() function
Arik Nemtsov (1):
mac80211: implement STA CSA for drivers using channel contexts
Eliad Peller (2):
mac80211: fix some snprintf misuses
ieee80211: fix vht cap definitions
Eugene Krasnikov (1):
wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware
Felipe Balbi (1):
net: wireless: wl1251: update firmware path
Felix Fietkau (10):
ath9k: use a separate data structure for rx buffers
ath9k_hw: remove direct accesses to channel mode flags
ath9k_hw: remove IS_CHAN_B()
ath9k_hw: remove IS_CHAN_OFDM()
ath9k_hw: simplify channel flags
ath9k: make ath9k_cmn_update_ichannel static
ath9k: move channel change code to ath_set_channel
ath9k: remove sc->config.cabqReadyTime
ath9k: make ath9k_uses_beacons static
ath9k_hw: remove references to hw->conf
Fengguang Wu (1):
wcn36xx: fix coccinelle warnings
Fred Zhou (2):
mac80211: use exact-size allocation for authentication frame
mac80211: improve default WMM parameter setting
Gabor Juhos (14):
rt2x00: rt2800lib: remove TXMIXER_GAIN entries from the extended EEPROM map
rt2x00: rt2800lib: remove TXPOWER_DELTA entry from extended EEPROM map
rt2x00: rt2800lib: fix default VGC values for RT3593
rt2x00: rt2800lib: fix VGC programming for RT3572 and RT3593
rt2x00: rt2800lib: fix default VGC values for RT3572 for the 5GHz band
rt2x00: use generic EWMA functions for average RSSI calculations
rt2x00: rt2800lib: fix VGC adjustment for RT5592
rt2x00: rt2800lib: fix VGC adjustment for RT3572 and RT3593
rt2x00: cleanup indentation in rt2800.h
rt2x00: add rt2x00_has_cap_* helpers
rt2x00: rt2x00lib: use rt2x00_has_cap_* helpers
rt2x00: rt2800lib: use rt2x00_has_cap_* helpers
rt2x00: rt61pci: use rt2x00_has_cap_* helpers
rt2x00: rt73usb: use rt2x00_has_cap_* helpers
Hauke Mehrtens (3):
bcma: reject PCI cards in bcma.
bcma: add PCI id 0x4313
brcmsmac: add support for a BCM4313 with PCI id 0x4313
Janusz Dziedzic (1):
cfg80211: parse dfs region for internal regdb option
Johannes Berg (4):
mac80211: add ieee80211_iterate_active_interfaces_rtnl()
mac80211: use ERR_CAST()
mac80211: add explicit IBSS driver operations
regulatory: enable channels 52-64 and 100-144 for world roaming
John W. Linville (2):
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211-next
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Kevin Lo (3):
rt2x00: rt2800lib: no need to toggle RF R30 bit 7 twice
rt2x00: rt2800lib: fix RF registers for RT5390/RT5392
rt2x00: rt2800lib: remove duplicate rf_vals for RF3053
Kirill Tkhai (1):
rt2x00_pci: Fix interrupt handler name (visible at /proc/interrupts)
Lorenzo Bianconi (2):
mac80211: add fixed_rate management to minstrel rc
mac80211: do not override fixed_rate_idx in minstrel_ht_update_stats
Michael Opdenacker (1):
net: p54spi: remove deprecated IRQF_DISABLED
Michal Kazior (1):
mac80211: support reporting A-MSDU subframes individually
Peter Senna Tschudin (1):
mwifiex: Change variable type to bool
Sergey Ryazanov (1):
mac80211: Remove superfluous is_multicast_ether_addr() call
Simon Wunderlich (7):
cfg80211: export cfg80211_chandef_dfs_required
mac80211: split off channel switch parsing function
mac80211: split off ibss disconnect
mac80211: add support for CSA in IBSS mode
mac80211: send a CSA action frame when changing channel
nl80211: enable IBSS support for channel switch announcements
nl80211: allow CAC only if no operation is going on
Stanislaw Gruszka (2):
mac80211: change beacon/connection polling
rt2x00: do not pause queue on flush
cedric Voncken (1):
cfg80211: vlan priority handling in WMM
MAINTAINERS | 8 +
drivers/bcma/host_pci.c | 8 +-
drivers/net/wireless/ath/Kconfig | 1 +
drivers/net/wireless/ath/Makefile | 1 +
drivers/net/wireless/ath/ath9k/ani.c | 6 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 43 +-
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 7 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 26 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 113 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 12 +-
drivers/net/wireless/ath/ath9k/calib.c | 9 +-
drivers/net/wireless/ath/ath9k/common.c | 91 +-
drivers/net/wireless/ath/ath9k/common.h | 7 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 32 +-
drivers/net/wireless/ath/ath9k/hw.c | 67 +-
drivers/net/wireless/ath/ath9k/hw.h | 82 +-
drivers/net/wireless/ath/ath9k/init.c | 87 +-
drivers/net/wireless/ath/ath9k/mac.c | 6 +-
drivers/net/wireless/ath/ath9k/mac.h | 2 -
drivers/net/wireless/ath/ath9k/main.c | 157 +-
drivers/net/wireless/ath/ath9k/mci.c | 8 +-
drivers/net/wireless/ath/ath9k/recv.c | 48 +-
drivers/net/wireless/ath/ath9k/xmit.c | 12 +-
drivers/net/wireless/ath/wcn36xx/Kconfig | 16 +
drivers/net/wireless/ath/wcn36xx/Makefile | 7 +
drivers/net/wireless/ath/wcn36xx/debug.c | 181 +
drivers/net/wireless/ath/wcn36xx/debug.h | 49 +
drivers/net/wireless/ath/wcn36xx/dxe.c | 805 ++++
drivers/net/wireless/ath/wcn36xx/dxe.h | 284 ++
drivers/net/wireless/ath/wcn36xx/hal.h | 4657 ++++++++++++++++++++++++
drivers/net/wireless/ath/wcn36xx/main.c | 1036 ++++++
drivers/net/wireless/ath/wcn36xx/pmc.c | 62 +
drivers/net/wireless/ath/wcn36xx/pmc.h | 33 +
drivers/net/wireless/ath/wcn36xx/smd.c | 2126 +++++++++++
drivers/net/wireless/ath/wcn36xx/smd.h | 127 +
drivers/net/wireless/ath/wcn36xx/txrx.c | 284 ++
drivers/net/wireless/ath/wcn36xx/txrx.h | 160 +
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 238 ++
drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
drivers/net/wireless/mwifiex/cmdevt.c | 2 +-
drivers/net/wireless/mwifiex/join.c | 2 +-
drivers/net/wireless/mwifiex/main.c | 4 +-
drivers/net/wireless/mwifiex/sta_cmd.c | 2 +-
drivers/net/wireless/mwifiex/wmm.c | 2 +-
drivers/net/wireless/p54/p54spi.c | 2 +-
drivers/net/wireless/rt2x00/Kconfig | 1 +
drivers/net/wireless/rt2x00/rt2800.h | 42 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 173 +-
drivers/net/wireless/rt2x00/rt2x00.h | 103 +-
drivers/net/wireless/rt2x00/rt2x00crypto.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00debug.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00link.c | 74 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 6 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 39 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 2 +
drivers/net/wireless/rt2x00/rt61pci.c | 20 +-
drivers/net/wireless/rt2x00/rt73usb.c | 18 +-
drivers/net/wireless/ti/wl1251/wl1251.h | 4 +-
include/linux/ieee80211.h | 4 +-
include/net/cfg80211.h | 9 +
include/net/mac80211.h | 42 +
net/mac80211/cfg.c | 92 +-
net/mac80211/chan.c | 5 -
net/mac80211/debugfs.c | 55 +-
net/mac80211/driver-ops.h | 27 +
net/mac80211/ibss.c | 608 +++-
net/mac80211/ieee80211_i.h | 30 +-
net/mac80211/iface.c | 4 +
net/mac80211/key.c | 2 +-
net/mac80211/mlme.c | 334 +-
net/mac80211/rc80211_minstrel.c | 14 +
net/mac80211/rc80211_minstrel_ht.c | 23 +-
net/mac80211/rc80211_pid_debugfs.c | 26 +-
net/mac80211/rx.c | 39 +-
net/mac80211/scan.c | 3 +-
net/mac80211/spectmgmt.c | 162 +
net/mac80211/trace.h | 35 +
net/mac80211/tx.c | 39 +-
net/mac80211/util.c | 162 +-
net/mac80211/vht.c | 4 +-
net/wireless/chan.c | 1 +
net/wireless/core.h | 9 -
net/wireless/debugfs.c | 24 +-
net/wireless/genregdb.awk | 6 +
net/wireless/nl80211.c | 52 +-
net/wireless/reg.c | 14 +-
net/wireless/util.c | 9 +
89 files changed, 11937 insertions(+), 1309 deletions(-)
create mode 100644 drivers/net/wireless/ath/wcn36xx/Kconfig
create mode 100644 drivers/net/wireless/ath/wcn36xx/Makefile
create mode 100644 drivers/net/wireless/ath/wcn36xx/debug.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/debug.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/dxe.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/dxe.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/hal.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/main.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/pmc.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/pmc.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/smd.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/smd.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/txrx.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/txrx.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/wcn36xx.h
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] sctp: Do not trigger BUG_ON when deleting assoc without primary path
From: Vlad Yasevich @ 2013-10-17 18:35 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-sctp, Mark Thomas, Neil Horman
In-Reply-To: <52602BA3.5020405@redhat.com>
On 10/17/2013 02:25 PM, Daniel Borkmann wrote:
> On 10/17/2013 08:01 PM, Daniel Borkmann wrote:
>> On 10/17/2013 07:30 PM, Vlad Yasevich wrote:
>>> It is possible to enter sctp_cmd_delete_tcb() without having a
>>> primary path. The situations this most often happens in is
>>> when duplication cookie processing is triggered. In this
>>> case, we are deleting a temporarily created association that
>>> is not fully populated. Additially, at the time we
>>> are deleting the offending association, it is really too
>>> late to issue a BUG!
>>>
>>> This was introduced by:
>>> commit f9e42b853523cda0732022c2e0473c183f7aec65
>>> net: sctp: sideeffect: throw BUG if primary_path is NULL
>>
>> Sure, lets remove it, but then we could still get a WARN() [sure,
>> better than BUG], if the user at the very same time checks procfs
>> through sctp_seq_dump_local_addrs(), see discussion we had here [1]:
>>
>> It may trigger the crash later if the user performs some action on the
>> association that touches the primary. That's the reason why I was
>> proposing the checks below.
>>
>> With the checks in command interpreter, we are only left with the
>> possibility that primary_path changes to NULL during the association
>> lifetime, which code audit doesn't support right now. If that ever
>> changes we would at least have a bit more information to go on.
>>
>> [1] http://patchwork.ozlabs.org/patch/251099/
>
> Meaning, all I'm saying is that with f9e42b853 we wanted to find exactly
> such a case we have right now, that is, that an assoc could enter the
> hashtable w/o primary path, no?
But it didn't enter a hash table in this case. SCTP_CMD_NEW_ASOC
was never issued. The sequence was:
SCTP_CMD_SET_ASOC
SCTP_CMD_DELETE_TCB
Such association would never be found through /proc since it was never
hashed. Such association would never be found the user since it
is only really alive while the packet is processed. By all rights
it should be marked as 'temp', but it isn't due to cookie processing.
May be we should update cookie processing function to allow it
to create temp associations if so desired.
-vlad
^ permalink raw reply
* Re: [PATCH net 2/9] bnx2x: Prevent an illegal pointer dereference during panic
From: Eilon Greenstein @ 2013-10-17 18:47 UTC (permalink / raw)
To: David Miller; +Cc: yuvalmin, netdev, ariele, dmitry
In-Reply-To: <20131017.142134.1058688642083607743.davem@davemloft.net>
On Thu, 2013-10-17 at 14:21 -0400, David Miller wrote:
> From: "Yuval Mintz" <yuvalmin@broadcom.com>
> Date: Tue, 15 Oct 2013 16:28:48 +0200
>
> > @@ -775,6 +775,15 @@ void bnx2x_fw_dump_lvl(struct bnx2x *bp, const char *lvl)
> > trace_shmem_base = bp->common.shmem_base;
> > else
> > trace_shmem_base = SHMEM2_RD(bp, other_shmem_base_addr);
> > +
> > + /* sanity */
> > + if (trace_shmem_base < MCPR_SCRATCH_BASE(bp) ||
> > + trace_shmem_base > MCPR_SCRATCH_BASE(bp) + 0x28000) {
>
> I would say that this second test should be ">=" rather than ">".
>
> Actually, there are a lot of holes still remaining here.
>
> trace_shmem_base is validated, but then you access the signature at
> 0x800 bytes before trace_shmem_base value. That should be accounted
> for in the test above too.
>
> And what about that 'mark' value you read? Any validations needed on
> that?
>
> And then you read from "addr" to "mark", and I see no checks that this
> range makes any sense either.
The failure that we saw was due to PCI read failure, so we could have
checked that we did not read all 1's, but then we thought about a
stronger validation to make sure this address is not being overrun for
some unknown reason (maybe stack overflow of the FW, after all, we are
at a FW bug handling routine) so this added condition validate that the
address is within the scratchpad limitation. To make it more precious,
we should account for the differences between the different silicon
revisions, but we did not really see such a failure - the failure we saw
was reading all 1's, the extra sanity will catch some more failure, but
obviously not all.
I guess we should really re-spin and check for all 1's, or add some more
code to make it really accurate, or at least fix the ">" to ">=". We
will send a revised series with a fix.
Thanks,
Eilon
^ permalink raw reply
* Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
From: Eric Dumazet @ 2013-10-17 18:48 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, Neil Horman, linux-kernel, sebastien.dugue,
Thomas Gleixner, Ingo Molnar, x86, netdev
In-Reply-To: <52602A29.506@zytor.com>
On Thu, 2013-10-17 at 11:19 -0700, H. Peter Anvin wrote:
> Seriously, though, how much does it matter? All the above seems likely
> to do is to drown the signal by adding noise.
I don't think so.
>
> If the parallel (threaded) checksumming is faster, which theory says it
> should and microbenchmarking confirms, how important are the
> macrobenchmarks?
Seriously, micro benchmarks are very misleading.
I spent time on this patch, and found no changes on real workloads.
I was excited first, then disappointed.
I hope we will find the real issue, as I really don't care of micro
benchmarks.
^ permalink raw reply
* Re: [PATCH] sctp: Do not trigger BUG_ON when deleting assoc without primary path
From: Daniel Borkmann @ 2013-10-17 18:52 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, linux-sctp, Mark Thomas, Neil Horman
In-Reply-To: <52602E0C.6000300@gmail.com>
On 10/17/2013 08:35 PM, Vlad Yasevich wrote:
> On 10/17/2013 02:25 PM, Daniel Borkmann wrote:
>> On 10/17/2013 08:01 PM, Daniel Borkmann wrote:
>>> On 10/17/2013 07:30 PM, Vlad Yasevich wrote:
>>>> It is possible to enter sctp_cmd_delete_tcb() without having a
>>>> primary path. The situations this most often happens in is
>>>> when duplication cookie processing is triggered. In this
>>>> case, we are deleting a temporarily created association that
>>>> is not fully populated. Additially, at the time we
>>>> are deleting the offending association, it is really too
>>>> late to issue a BUG!
>>>>
>>>> This was introduced by:
>>>> commit f9e42b853523cda0732022c2e0473c183f7aec65
>>>> net: sctp: sideeffect: throw BUG if primary_path is NULL
>>>
>>> Sure, lets remove it, but then we could still get a WARN() [sure,
>>> better than BUG], if the user at the very same time checks procfs
>>> through sctp_seq_dump_local_addrs(), see discussion we had here [1]:
>>>
>>> It may trigger the crash later if the user performs some action on the
>>> association that touches the primary. That's the reason why I was
>>> proposing the checks below.
>>>
>>> With the checks in command interpreter, we are only left with the
>>> possibility that primary_path changes to NULL during the association
>>> lifetime, which code audit doesn't support right now. If that ever
>>> changes we would at least have a bit more information to go on.
>>>
>>> [1] http://patchwork.ozlabs.org/patch/251099/
>>
>> Meaning, all I'm saying is that with f9e42b853 we wanted to find exactly
>> such a case we have right now, that is, that an assoc could enter the
>> hashtable w/o primary path, no?
>
> But it didn't enter a hash table in this case. SCTP_CMD_NEW_ASOC
> was never issued. The sequence was:
> SCTP_CMD_SET_ASOC
> SCTP_CMD_DELETE_TCB
>
> Such association would never be found through /proc since it was never
> hashed. Such association would never be found the user since it
> is only really alive while the packet is processed. By all rights
> it should be marked as 'temp', but it isn't due to cookie processing.
>
> May be we should update cookie processing function to allow it
> to create temp associations if so desired.
Yes, I think that might be the better way to move on.
> -vlad
^ permalink raw reply
* Re: [PATCH net-next] inet_diag: use sock_gen_put()
From: David Miller @ 2013-10-17 19:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381506889.4971.104.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 11 Oct 2013 08:54:49 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP listener refactoring, part 6 :
>
> Use sock_gen_put() from inet_diag_dump_one_icsk() for future
> SYN_RECV support.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next v3 7/9] qlcnic: Validate Tx queue only for 82xx adapters.
From: David Miller @ 2013-10-17 19:07 UTC (permalink / raw)
To: himanshu.madhani; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <21b377dba7708434c344a9204afd460c9b43af3c.1381882600.git.himanshu.madhani@qlogic.com>
From: Himanshu Madhani <himanshu.madhani@qlogic.com>
Date: Tue, 15 Oct 2013 12:57:52 -0400
> From: Himanshu Madhani <himanshu.madhani@qlogic.com>
>
> o validate Tx queue only in case of adapters which supports
> multi Tx queue.
>
> This patch is to fix regression introduced in commit
> aa4a1f7df7cbb98797c9f4edfde3c726e2b3841f
> "qlcnic: Enable Tx queue changes using ethtool for 82xx Series adapter"
>
> Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Do not submit bug fixes for "net-next" if they are for problems
that exist in 'net'.
What do several driver maintainers do this repeatedly?
Are you scared I'll reject the submission? If it's really a bug fix
I won't, 'net' is where it really belongs.
I'm not applying this series, submit it properly.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/4] net/mlx4: Mellanox driver update 15-10-2013
From: David Miller @ 2013-10-17 19:13 UTC (permalink / raw)
To: amirv; +Cc: netdev, eyalpe
In-Reply-To: <1381848924-18992-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Tue, 15 Oct 2013 16:55:20 +0200
> This patchset contains small code cleaning patches, and a patch to make
> mlx4_core use module_request() in order to load the relevant link layer module
> (mlx4_en or mlx4_ib) according to the port type.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] isdn: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-10-17 19:14 UTC (permalink / raw)
To: michael.opdenacker; +Cc: mac, isdn, netdev, linux-kernel
In-Reply-To: <1381641869-7709-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Sun, 13 Oct 2013 07:24:29 +0200
> This patch proposes to remove the use of the IRQF_DISABLED flag
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] irda: update comment mentioning IRQF_DISABLED
From: David Miller @ 2013-10-17 19:15 UTC (permalink / raw)
To: michael.opdenacker; +Cc: samuel, netdev, linux-kernel
In-Reply-To: <1381645591-9565-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Sun, 13 Oct 2013 08:26:31 +0200
> This patch removes a comment mentioning IRQF_DISABLED,
> which is deprecated.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 00/17] netfilter updates: nf_tables pull request
From: David Miller @ 2013-10-17 19:23 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, kaber, netdev
In-Reply-To: <1381768738-17739-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 14 Oct 2013 18:38:41 +0200
> The following patchset contains the current original nf_tables tree
> condensed in 17 patches. I have organized them by chronogical order
> since the original nf_tables code was released in 2009 and by
> dependencies between the different patches.
...
> There is still work to do to fully replace x_tables [4] [5] but that can
> be done incrementally by extending our netlink API. Moreover, looking at
> netfilter-devel and the amount of contributions to nf_tables we've been
> getting, I think it would be good to have it mainstream to avoid accumulating
> large patchsets skip continuous rebases.
>
> I tried to provide a reasonable patchset, we have more than 100 accumulated
> patches in the original nf_tables tree, so I collapsed many of the small
> fixes to the main patch we had since 2009 and provide a small batch for
> review to netdev, while trying to retain part of the history.
>
> For those who didn't give a try to nf_tables yet, there's a quick howto
> available from Eric Leblond that describes how to get things working [6].
>
> Comments/reviews welcome.
This looks great, pulled, thanks a lot!!
^ permalink raw reply
* Re: [PATCH v4 net 0/3] sctp: Use software checksum under certain
From: David Miller @ 2013-10-17 19:26 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, linux-sctp, fan.du
In-Reply-To: <1381888891-31186-1-git-send-email-vyasevich@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Tue, 15 Oct 2013 22:01:28 -0400
> There are some cards that support SCTP checksum offloading. When using
> these cards with IPSec or forcing IP fragmentation of SCTP traffic,
> the checksum is computed incorrectly due to the fact that xfrm and IP/IPv6
> fragmentation code do not know that this is SCTP traffic and do not
> know that checksum has to be computed differently.
>
> To fix this, we let SCTP detect these conditions and perform software
> checksum calculation.
Series applied, thanks Vlad.
^ permalink raw reply
* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: Eric W. Biederman @ 2013-10-17 19:28 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: Stephen Hemminger, David Miller, yamato, netdev
In-Reply-To: <52600ABC.1030701@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
> Le 16/10/2013 21:53, Eric W. Biederman a écrit :
>> The age old question why can't we have global identifiers for
>> namespaces?
>>
>> The answer is that I don't want to implement a namespace for namespaces.
> Sorry, but I don't understand the problem. This ID is owned by the kernel, like
> the netns list (for_each_net()) is owned by it.
The scenario where problem are likely to show up is something like this.
For testing it would be reasonable to setup two linux containers that
look like full linux systems. In those containers you run one instance
of your virtual router managment daemons, and you arrange to synchronize
between the two linux containers for testing.
It becomes even more interesting when we want to migrate one of those
linux containers to another physical machine.
Global identifiers start breaking the first scenario, and really trash
the second scenario.
At the same time migration of configuration and replication of
configuration are essentially the same problem, so it would be very
silly to design such that will cause problems.
>> While the proc inode does work today across different mounts of proc, I
>> reserve the right at some future date (if it solves a technical problem)
>> to give each namespace a different inode number in each different mount
>> of proc. So the inode number is not quite the unique identifier you
>> want. The inode number is a close as I am willing to get to a namespace
>> of namespaces.
>>
>> I think the simplest solution is to just not worry about which namespace
>> the other half of a veth pair is in. But I have not encountered the
>> problem where I need to know exactly which namespace we are worrying
>> about.
> Ok, let's start by explaining our usecase.
>
> We are using namespaces only to implement virtual routers (VR), ie only
> the networking stack is virtualized. We don't care about other namespaces, we
> just want to run several network stacks and beeing able to manage them.
>
> For example, providers use this feature to isolate clients, one VR is opened
> for each client. You can have a large number of clients (+10 000) and thus the
> same number of netns.
> Considering these numbers, we don't want to run one instance per VR for all of
> our network daemons, but have only one instance that manage all VR.
>
> You also have daemons that monitor the system and synchronize network objects
> (interfaces, routes, etc.) on another linux. Goal is to implement an high
> availablity system: it's possible to switch to the other linux to avoid service
> interruption.
> This kind of daemon wants to have the full information about interfaces to be
> able to build/configure them on the other linux.
>
>>
>> Global identifiers are easy until you hit the cases where they make
>> things impossible.
> I don't want specially to use ID, but I fear that the solution with file
> descriptors will be a nightmare.
I can certainly see challenges. In asking for symmetry between set and
get the solution with file descriptors is the obvious answer and the
first answer I have been able to come up with so far.
My original answer was that the ifindex happened to be unique across
namespaces but that actually turned out to be a problem for migration
so that abandoned.
Namespace file descriptors are the solution that I know semantically
will work. Beyond that I don't have any good ideas right now.
I just know that local names (aka file descriptors) are much easier to
work with semantically than global names.
Eric
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] bonding: patchset for rcu use in bonding
From: David Miller @ 2013-10-17 19:32 UTC (permalink / raw)
To: dingtianhong; +Cc: fubar, andy, nikolay, vfalico, netdev
In-Reply-To: <525CFCAF.2000605@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Tue, 15 Oct 2013 16:28:31 +0800
> The Patch Set convert the xmit of 3ad and alb mode to use rcu lock.
> dd rtnl lock and remove read lock for bond sysfs.
>
> v2 because the bond_for_each_slave_rcu without rcu_read_lock() will occurs one warming, so
> add new function for alb xmit path to avoid warming.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v5 0/5] xen-netback: IPv6 offload support
From: David Miller @ 2013-10-17 19:36 UTC (permalink / raw)
To: paul.durrant; +Cc: xen-devel, netdev
In-Reply-To: <1381942232-26268-1-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Wed, 16 Oct 2013 17:50:27 +0100
> This patch series adds support for checksum and large packet offloads into
> xen-netback.
> Testing has mainly been done using the Microsoft network hardware
> certification suite running in Server 2008R2 VMs with Citrix PV frontends.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] Stmmac: fix a bug when clk_csr is euqal to 0x0
From: David Miller @ 2013-10-17 19:39 UTC (permalink / raw)
To: mcuos.com; +Cc: netdev, peppe.cavallaro
In-Reply-To: <CAKT61h9Cv=g5stPBnp25XiUyfPy_NxBKxtAABUHm+GajCHMGWA@mail.gmail.com>
From: Wan ZongShun <mcuos.com@gmail.com>
Date: Sat, 12 Oct 2013 10:04:20 +0800
> According to spec, if csr clock freq is 60-100Mhz, we have to set CR[5:2] = 0000
> but when I set the 'plat_dat.clk_csr = 0',acctually, this value is not used
> since the driver code judge 'if (!priv->plat->clk_csr)' then go to dynamic tune
> the MDC clock. So this patch is to add other judge condition.
>
> Signed-off-by: Wan Zongshun <mcuos.com@gmail.com>
There are still many problems with this patch.
Do not capitalize "Stmmac" in the subject prefix, use plain "stmmac: "
There is a typo in "equal" in the subject line.
> @@ -148,6 +149,8 @@ Where:
> GMAC also enables the 4xPBL by default.
> o fixed_burst/mixed_burst/burst_len
> o clk_csr: fixed CSR Clock range selection.
> + o dynamic_mdc_clk_en: If it is set to >=1 MDC clk will be selected
> dynamically,
> + or else you must set a fixed CSR Clock range to clk_src.
> o has_gmac: uses the GMAC core.
> o enh_desc: if sets the MAC will use the enhanced descriptor structure.
> o tx_coe: core is able to perform the tx csum in HW.
The patch has been corrupted by your email client.
^ permalink raw reply
* Re: [PATCH] usbnet: fix error return code in usbnet_probe()
From: David Miller @ 2013-10-17 19:40 UTC (permalink / raw)
To: weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w
Cc: oneukum-l3A5Bk7waGM, yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAPgLHd9jQfT2Kzi5o+3KPy0hFrkHL135K2aYp7OXcbLX4Cmkcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Wei Yongjun <weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Sat, 12 Oct 2013 14:24:08 +0800
> From: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
>
> Fix to return -ENOMEM in the padding pkt alloc fail error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
Applied, thanks Wei.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] bnx2x: record rx queue for LRO packets
From: David Miller @ 2013-10-17 19:43 UTC (permalink / raw)
To: dmitry; +Cc: eric.dumazet, netdev, eilong, willemb
In-Reply-To: <504C9EFCA2D0054393414C9CB605C37F20DD4605@SJEXCHMB06.corp.ad.broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Sun, 13 Oct 2013 06:23:31 +0000
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Eric Dumazet
>> Sent: Sunday, October 13, 2013 12:09 AM
>> To: David Miller
>> Cc: netdev; Eilon Greenstein; Willem de Bruijn
>> Subject: [PATCH] bnx2x: record rx queue for LRO packets
>>
>> From: Eric Dumazet <edumazet@google.com>
>>
>> RPS support is kind of broken on bnx2x, because only non LRO packets get
>> proper rx queue information. This triggers reorders, as it seems bnx2x like to
>> generate a non LRO packet for segment including TCP PUSH flag : (this might
>> be pure coincidence, but all the reorders I've seen involve segments with a
>> PUSH)
>>
>> 11:13:34.335847 IP A > B: . 415808:447136(31328) ack 1 win 457
>> <nop,nop,timestamp 3789336 3985797>
>> 11:13:34.335992 IP A > B: . 447136:448560(1424) ack 1 win 457
>> <nop,nop,timestamp 3789336 3985797>
>> 11:13:34.336391 IP A > B: . 448560:479888(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985797>
>> 11:13:34.336425 IP A > B: P 511216:512640(1424) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336423 IP A > B: . 479888:511216(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336924 IP A > B: . 512640:543968(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336963 IP A > B: . 543968:575296(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>>
>> We must call skb_record_rx_queue() to properly give to RPS (and more
>> generally for TX queue selection on forward path) the receive queue
>> information.
>>
>> Similar fix is needed for skb_mark_napi_id(), but will be handled in a
>> separate patch to ease stable backports.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
...
> Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: refactor sk_page_frag_refill()
From: David Miller @ 2013-10-17 19:46 UTC (permalink / raw)
To: eric.dumazet
Cc: mwdalton, dborkman, netdev, ffusco, ycheng, ncardwell,
digitaleric
In-Reply-To: <1381639591.3392.31.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 12 Oct 2013 21:46:31 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> While working on virtio_net new allocation strategy to increase
> payload/truesize ratio, we found that refactoring sk_page_frag_refill()
> was needed.
>
> This patch splits sk_page_frag_refill() into two parts, adding
> page_frag_refill() which can be used without a socket.
>
> While we are at it, add a minimum frag size of 32 for
> sk_page_frag_refill()
>
> Michael will either use netdev_alloc_frag() from softirq context,
> or page_frag_refill() from process context in refill_work() (GFP_KERNEL
> allocations)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Please rename this to something like "skb_page_frag_refill" so that it
is clear that this is a networking interface.
Thanks Eric.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox