* r8169 won't transmit with 3.12
From: Craig Small @ 2014-01-21 0:06 UTC (permalink / raw)
To: Realtek linux nic maintainers, Francois Romieu; +Cc: netdev
Hi,
I seem to be having lots of troubles with the RealTek chipsets. I have
one onboard and two PCI-e cards and they all have the same problem. They
will not transmit anything. The r8169 driver does it, as does the
r8168-dkms module.
It's a new setup so it might of never worked. It's not likely to be a
hardware problem as its three different devices.
I've sent what I think you might need for starters, but if there
is extra stuff you'd like to see, let me know.
I'm using a stock Debian kernel
3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29)
I've included the lspci output of one of the cards below. I'm not
really sure what else you'd need to check things.
The problem shows up the same, the TX dropped counter increments.
I'm not sure why 42 packets made it out (or even if they really did)
Receive works fine, I can even start up wireshark and see packets
pass by.
eth0 Link encap:Ethernet HWaddr 00:e0:4c:80:66:57
inet addr:192.168.1.222 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::2e0:4cff:fe80:6657/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8252 errors:0 dropped:0 overruns:0 frame:0
TX packets:42 errors:0 dropped:8029 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:584930 (571.2 KiB) TX bytes:5083 (4.9 KiB)
ethtool -S shows a similar story, not sure if the rx_missed counter
is another problem:
NIC statistics:
tx_packets: 47
rx_packets: 31342
tx_errors: 0
rx_errors: 0
rx_missed: 47438
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 1
broadcast: 29638
multicast: 1891
tx_aborted: 0
tx_underrun: 0
I've disabled the on-board device now, but the simple lspci output was:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
The PCI-e cards have the following:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 73
Region 0: I/O ports at d000 [size=256]
Region 2: Memory at fde00000 (64-bit, non-prefetchable) [size=4K]
Region 4: Memory at d2200000 (64-bit, prefetchable) [size=64K]
Expansion ROM at d2210000 [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee3f00c Data: 4123
Capabilities: [70] Express (v1) Endpoint, MSI 08
DevCap: MaxPayload 1024 bytes, PhantFunc 0, Latency L0s <128ns, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend+
LnkCap: Port #16, Speed unknown, Width x22, ASPM not supported, Exit Latency L0s <64ns, L1 <2us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [b0] MSI-X: Enable- Count=2 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
Unknown small resource type 05, will not decode more.
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP+ BadDLLP+ Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00
Kernel driver in use: r8169
--
Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
^ permalink raw reply
* [net-next] [patch v2] i40e: potential array underflow in i40e_vc_process_vf_msg()]
From: Brown, Aaron F @ 2014-01-21 0:15 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: davem@davemloft.net
I did not see this on the netdev list so forwarding from e1000-devel
with subject line changed, a Tested-by: and Signed-off-by added.
From: Dan Carpenter <dan.carpenter@oracle.com>
Reply-to: Dan Carpenter <dan.carpenter@oracle.com>
To: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: kernel-janitors@vger.kernel.org, e1000-devel@lists.sourceforge.net,
Bruce Allan <bruce.w.allan@intel.com>, Jesse Brandeburg
<jesse.brandeburg@intel.com>, Wei Yongjun
<yongjun_wei@trendmicro.com.cn>, John Ronciak <john.ronciak@intel.com>
Subject: [E1000-devel] [patch v2] i40e: potential array underflow in
i40e_vc_process_vf_msg()
Date: Sat, 11 Jan 2014 12:58:42 +0300
If "vf_id" is smaller than hw->func_caps.vf_base_id then it leads to
an array underflow of the pf->vf[] array. This is unlikely to happen
unless the hardware is bad, but it's a small change and it silences a
static checker warning.
Fixes: 7efa84b7abc1 ('i40e: support VFs on PFs other than 0')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
v2: rebased. commit message updated.
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 51a4f6125437..b77d7e79d977 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1772,7 +1772,7 @@ int i40e_vc_process_vf_msg(struct i40e_pf *pf, u16 vf_id, u32 v_opcode,
u32 v_retval, u8 *msg, u16 msglen)
{
struct i40e_hw *hw = &pf->hw;
- int local_vf_id = vf_id - hw->func_caps.vf_base_id;
+ unsigned int local_vf_id = vf_id - hw->func_caps.vf_base_id;
struct i40e_vf *vf;
int ret;
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: [PATCH net-next v5 8/9] xen-netback: Timeout packets in RX path
From: Zoltan Kiss @ 2014-01-21 0:24 UTC (permalink / raw)
To: Wei Liu; +Cc: ian.campbell, xen-devel, netdev, linux-kernel, jonathan.davies
In-Reply-To: <20140120220348.GA5058@zion.uk.xensource.com>
On 20/01/14 22:03, Wei Liu wrote:
> On Mon, Jan 20, 2014 at 09:24:28PM +0000, Zoltan Kiss wrote:
>> @@ -557,12 +577,25 @@ void xenvif_disconnect(struct xenvif *vif)
>> void xenvif_free(struct xenvif *vif)
>> {
>> int i, unmap_timeout = 0;
>> + /* Here we want to avoid timeout messages if an skb can be legitimatly
>> + * stucked somewhere else. Realisticly this could be an another vif's
>> + * internal or QDisc queue. That another vif also has this
>> + * rx_drain_timeout_msecs timeout, but the timer only ditches the
>> + * internal queue. After that, the QDisc queue can put in worst case
>> + * XEN_NETIF_RX_RING_SIZE / MAX_SKB_FRAGS skbs into that another vif's
>> + * internal queue, so we need several rounds of such timeouts until we
>> + * can be sure that no another vif should have skb's from us. We are
>> + * not sending more skb's, so newly stucked packets are not interesting
>> + * for us here.
>> + */
> You beat me to this. Was about to reply to your other email. :-)
>
> It's also worth mentioning that DIV_ROUND_UP part is merely estimation,
> as you cannot possible know the maximum / miminum queue length of all
> other vifs (as they can be changed during runtime). In practice most
> users will stick with the default, but some advanced users might want to
> tune this value for individual vif (whether that's a good idea or not is
> another topic).
>
> So, in order to convince myself this is safe. I also did some analysis
> on the impact of having queue length other than default value. If
> queue_len < XENVIF_QUEUE_LENGTH, that means you can queue less packets
> in qdisc than default and drain it faster than calculated, which is
> safe. On the other hand if queue_len > XENVIF_QUEUE_LENGTH, it means
> actually you need more time than calculated. I'm in two minded here. The
> default value seems sensible to me but I'm still a bit worried about the
> queue_len > XENVIF_QUEUE_LENGTH case.
>
> An idea is to book-keep maximum tx queue len among all vifs and use that
> to calculate worst scenario.
I don't think it should be that perfect. This is just a best effort
estimation, if someone changes the vif queue length and see this message
because of that, nothing very drastic will happen. It is just a rate
limited warning message. Well, it is marked as error, because it is a
serious condition.
And also, the odds of seeing this message unnecessarily are quite low.
With default settings (256 slots, max 17 per skb, 32 queue length, 10
secs queue drain timeout) this delay is 20 seconds. You can raise the
queue length to 64 before getting warning (see netif_napi_add), so it
would go up to 40 seconds, but anyway, if your vif is sitting on a
packet more than 20 seconds, you deserve this message :)
Zoli
^ permalink raw reply
* Re: [netfilter-core] Release of nftables-plus 0.099
From: Patrick McHardy @ 2014-01-21 0:26 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Linux Networking Developer Mailing List,
Netfilter user mailing list, Netfilter Developer Mailing List,
coreteam, announce
In-Reply-To: <alpine.LSU.2.11.1401210056010.18315@nerf08.vanv.qr>
On Tue, Jan 21, 2014 at 01:00:05AM +0100, Jan Engelhardt wrote:
> On Tuesday 2014-01-21 00:41, Patrick McHardy wrote:
>
> >On Tue, Jan 21, 2014 at 12:38:41AM +0100, Jan Engelhardt wrote:
> >>
> >> My lone self presents:
> >>
> >> nftables-plus 0.099
> >
> >Jan, there's no need to CC the netfilter-core list, we're not interested
> >in your ego trips.
>
> Well thanks for spelling out so clearly that I am not welcome anymore.
Indeed, and you have your own antisocial and disruptive behaviour to thank
for that. Besides you, everyone else here is trying to work together.
For all I care, you can go play on netfilter2.org or something.
I'd also ask you to refrain from abusing the nftables name in this way.
You can use nftables in a descriptive fashion if you like, as with
xtables-addons.
Knowing your difficult personality, I'll register the name, just in case.
^ permalink raw reply
* Re: Fwd: Linux bridge for route
From: tingwei liu @ 2014-01-21 1:26 UTC (permalink / raw)
To: Bart De Schuymer; +Cc: netfilter-devel, netfilter, netdev
In-Reply-To: <52D992F4.8070500@pandora.be>
On Sat, Jan 18, 2014 at 4:30 AM, Bart De Schuymer <bdschuym@pandora.be> wrote:
> tingwei liu schreef op 17/01/2014 10:14:
>
>> Dear all,
>>
>> There is a question has puzzled me for a long time.
>> You can find the topology from attachment.
>>
>> Normal traffic is:
>>
>> PC(192.168.1.8)--->Bridge(eth0)--->Bridget(eth1)--->NAT
>> server-->switch--->Server(192.168.5.3)
>>
>> Now I want the ssh traffic like this:
>> PC(182.168.1.8)--->Bridge(eth0)--->eth2--->NAT
>> server--->switch--->Server(192.168.5.3)
>>
>>
>> What I have done on LINUX Server:
>> #net.bridge.bridge-nf-call-iptables = 1
>> #iptables -t nat -A POSTROUTING -s 192.168.1.8 -p tcp
>> --dport 22 -j SNAT --to-source 192.168.5.2
>>
>> I have find the rule matched through command "iptables -t nat
>> -nvL", but the packets doesn't sent to 192.168.5.3.
>> and "tcpdump -i eth2 tcp port 22" can not capture any packet!
>
>
> You are trying to make a brouter. You don't need to set
> net.bridge.bridge-nf-call-iptables to 1, instead you need to add an ebtables
> rule in the BROUTING chain, see:
> http://ebtables.sourceforge.net/examples/basic.html#ex_brouter
>
> Something like this (in combination with your existing iptables rules):
> ebtables -t broute -A BROUTING -p ipv4 --ip-source 192.168.1.8 \
> --ip-protocol tcp --ip-destination-port 22 \
> -j redirect --redirect-target DROP
>
Dear man,
This is bad news. It does _not_ work!
Is there any idea?
Thanks for your reply!
> cheers,
> Bart
>
^ permalink raw reply
* Re: [PATCH net v2] tuntap: Fix for a race in accessing numqueues
From: Jason Wang @ 2014-01-21 2:41 UTC (permalink / raw)
To: Dominic Curran, netdev; +Cc: Maxim Krasnyansky
In-Reply-To: <1390255158-9058-1-git-send-email-dominic.curran@citrix.com>
On 01/21/2014 05:59 AM, Dominic Curran wrote:
> A patch for fixing a race between queue selection and changing queues
> was introduced in commit 92bb73ea2("tuntap: fix a possible race between
> queue selection and changing queues").
>
> The fix was to prevent the driver from re-reading the tun->numqueues
> more than once within tun_select_queue() using ACCESS_ONCE().
>
> We have been experiancing 'Divide-by-zero' errors in tun_net_xmit()
> since we moved from 3.6 to 3.10, and believe that they come from a
> simular source where the value of tun->numqueues changes to zero
> between the first and a subsequent read of tun->numqueues.
>
> The fix is a simular use of ACCESS_ONCE(), as well as a multiply
> instead of a divide in the if statement.
>
> Signed-off-by: Dominic Curran <dominic.curran@citrix.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Maxim Krasnyansky <maxk@qti.qualcomm.com>
> ---
> V2: Use multiply instead of divide. Suggested by Eric Dumazet.
> Fixed email address for maxk. Rebase against net tree.
> ---
> drivers/net/tun.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> Index: net/drivers/net/tun.c
> ===================================================================
> --- net.orig/drivers/net/tun.c 2014-01-20 20:22:06.000000000 +0000
> +++ net/drivers/net/tun.c 2014-01-20 20:54:54.000000000 +0000
> @@ -721,12 +721,14 @@ static netdev_tx_t tun_net_xmit(struct s
> struct tun_struct *tun = netdev_priv(dev);
> int txq = skb->queue_mapping;
> struct tun_file *tfile;
> + u32 numqueues = 0;
>
> rcu_read_lock();
> tfile = rcu_dereference(tun->tfiles[txq]);
> + numqueues = ACCESS_ONCE(tun->numqueues);
>
> /* Drop packet if interface is not attached */
> - if (txq >= tun->numqueues)
> + if (txq >= numqueues)
> goto drop;
>
> tun_debug(KERN_INFO, tun, "tun_net_xmit %d\n", skb->len);
> @@ -746,8 +748,8 @@ static netdev_tx_t tun_net_xmit(struct s
> /* Limit the number of packets queued by dividing txq length with the
> * number of queues.
> */
> - if (skb_queue_len(&tfile->socket.sk->sk_receive_queue)
> - >= dev->tx_queue_len / tun->numqueues)
> + if (skb_queue_len(&tfile->socket.sk->sk_receive_queue) * numqueues
> + >= dev->tx_queue_len)
> goto drop;
>
> if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
Acked-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Alexandre Courbot @ 2014-01-21 3:11 UTC (permalink / raw)
To: Linus Walleij
Cc: Chen-Yu Tsai, Mika Westerberg, Heikki Krogerus, Arnd Bergmann,
linux-arm-kernel, Johannes Berg, David S. Miller, devicetree,
netdev, linux-wireless, linux-sunxi, linux-kernel, Maxime Ripard
In-Reply-To: <CACRpkdZOD4zeA8T5kbJ4c5NsnuzHCg1mw8rRMYNT9c4R-Qnc6A@mail.gmail.com>
On Sat, Jan 18, 2014 at 8:11 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Jan 17, 2014 at 6:43 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Sat, Jan 18, 2014 at 12:47 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>>>> +- NAME_shutdown-gpios : GPIO phandle to shutdown control
>>>> + (phandle must be the second)
>>>> +- NAME_reset-gpios : GPIO phandle to reset control
>>>> +
>>>> +NAME must match the rfkill-name property. NAME_shutdown-gpios or
>>>> +NAME_reset-gpios, or both, must be defined.
>>>> +
>>>
>>> I don't understand this part. Why do you include the name in the
>>> gpios property, rather than just hardcoding the property strings
>>> to "shutdown-gpios" and "reset-gpios"?
>>
>> This quirk is a result of how gpiod_get_index implements device tree
>> lookup.
>
> Why can't it just have a single property "gpios", where the first
> element is the reset GPIO and the second is the shutdown GPIO?
>
> rfkill-gpio does this:
>
> gpio = devm_gpiod_get_index(&pdev->dev, rfkill->reset_name, 0);
> gpio = devm_gpiod_get_index(&pdev->dev, rfkill->shutdown_name, 1);
>
> The passed con ID name parameter is only there for the device
> tree case it seems. (ACPI ignores it.) So what about you just
> don't pass it at all and patch it to do like this instead:
>
> gpio = devm_gpiod_get_index(&pdev->dev, NULL, 0);
> gpio = devm_gpiod_get_index(&pdev->dev, NULL, 1);
>
> Heikki, are you OK with this change?
>
> I think this is actually necessary if the ACPI and DT unification
> pipe dream shall limp forward, we cannot have arguments passed
> that have a semantic effect on DT but not on ACPI... Drivers
> that are supposed to use both ACPI and DT will always
> have to pass NULL as con ID.
I agree that's how it should be be done with the current API if your
driver can obtain GPIOs from both ACPI and DT. This is a potential
issue, as drivers are not supposed to make assumptions about who is
going to be their GPIO provider. Let's say you started a driver with
only DT in mind, and used gpio_get(dev, con_id) to get your GPIOs. DT
bindings are thus of the form "con_id-gpio = <phandle>", and set in
stone. Then later, someone wants to use your driver with ACPI. How do
you handle that gracefully?
I'm starting to wonder, now that ACPI is a first-class GPIO provider,
whether we should not start to encourage the deprecation of the
"con_id-gpio = <phandle>" binding form in DT and only use a single
indexed GPIO property per device. The con_id parameter would then only
be used as a label, which would also have the nice side-effect that
all GPIOs used for a given function will be reported under the same
name no matter what the GPIO provider is.
>From an aesthetic point of view, I definitely prefer using con_id to
identify GPIOs instead of indexes, but I don't see how we can make it
play nice with ACPI. Thoughts?
Alex.
^ permalink raw reply
* [PATCH net] tcp: metrics: Handle v6/v4-mapped sockets in tcp-metrics
From: Christoph Paasch @ 2014-01-21 7:17 UTC (permalink / raw)
To: David Miller; +Cc: netdev
A socket may be v6/v4-mapped. In that case sk->sk_family is AF_INET6,
but the IP being used is actually an IPv4-address.
Current's tcp-metrics will thus represent it as an IPv6-address:
root@server:~# ip tcp_metrics
::ffff:10.1.1.2 age 22.920sec rtt 18750us rttvar 15000us cwnd 10
10.1.1.2 age 47.970sec rtt 16250us rttvar 10000us cwnd 10
This patch modifies the tcp-metrics so that they are able to handle the
v6/v4-mapped sockets correctly.
Fixes: 51c5d0c4b169b (tcp: Maintain dynamic metrics in local cache.)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
net/ipv4/tcp_metrics.c | 50 ++++++++++++++++++++++++++++++--------------------
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index 098b3a29f6f3..3144524fe20f 100644
--- a/net/ipv4/tcp_metrics.c
+++ b/net/ipv4/tcp_metrics.c
@@ -264,21 +264,26 @@ static struct tcp_metrics_block *__tcp_get_metrics_tw(struct inet_timewait_sock
unsigned int hash;
struct net *net;
- addr.family = tw->tw_family;
- switch (addr.family) {
- case AF_INET:
+ if (tw->tw_family == AF_INET) {
+ addr.family = AF_INET;
addr.addr.a4 = tw->tw_daddr;
hash = (__force unsigned int) addr.addr.a4;
- break;
+ }
#if IS_ENABLED(CONFIG_IPV6)
- case AF_INET6:
- *(struct in6_addr *)addr.addr.a6 = tw->tw_v6_daddr;
- hash = ipv6_addr_hash(&tw->tw_v6_daddr);
- break;
+ else if (tw->tw_family == AF_INET6) {
+ if (ipv6_addr_v4mapped(&tw->tw_v6_daddr)) {
+ addr.family = AF_INET;
+ addr.addr.a4 = tw->tw_daddr;
+ hash = (__force unsigned int) addr.addr.a4;
+ } else {
+ addr.family = AF_INET6;
+ *(struct in6_addr *)addr.addr.a6 = tw->tw_v6_daddr;
+ hash = ipv6_addr_hash(&tw->tw_v6_daddr);
+ }
+ }
#endif
- default:
+ else
return NULL;
- }
net = twsk_net(tw);
hash = hash_32(hash, net->ipv4.tcp_metrics_hash_log);
@@ -300,21 +305,26 @@ static struct tcp_metrics_block *tcp_get_metrics(struct sock *sk,
unsigned int hash;
struct net *net;
- addr.family = sk->sk_family;
- switch (addr.family) {
- case AF_INET:
+ if (sk->sk_family == AF_INET) {
+ addr.family = AF_INET;
addr.addr.a4 = inet_sk(sk)->inet_daddr;
hash = (__force unsigned int) addr.addr.a4;
- break;
+ }
#if IS_ENABLED(CONFIG_IPV6)
- case AF_INET6:
- *(struct in6_addr *)addr.addr.a6 = sk->sk_v6_daddr;
- hash = ipv6_addr_hash(&sk->sk_v6_daddr);
- break;
+ else if (sk->sk_family == AF_INET6) {
+ if (ipv6_addr_v4mapped(&sk->sk_v6_daddr)) {
+ addr.family = AF_INET;
+ addr.addr.a4 = inet_sk(sk)->inet_daddr;
+ hash = (__force unsigned int) addr.addr.a4;
+ } else {
+ addr.family = AF_INET6;
+ *(struct in6_addr *)addr.addr.a6 = sk->sk_v6_daddr;
+ hash = ipv6_addr_hash(&sk->sk_v6_daddr);
+ }
+ }
#endif
- default:
+ else
return NULL;
- }
net = dev_net(dst->dev);
hash = hash_32(hash, net->ipv4.tcp_metrics_hash_log);
--
1.8.3.2
^ permalink raw reply related
* [PATCH] ip_tunnel: clear IPCB in ip_tunnel_xmit() in case dst_link_failure() is called
From: Duan Jiong @ 2014-01-21 7:18 UTC (permalink / raw)
To: David Miller; +Cc: Pravin B Shelar, Daniel Petre, Eric Dumazet, netdev
commit a622260254ee48("ip_tunnel: fix kernel panic with icmp_dest_unreach")
clear IPCB in ip_tunnel_xmit() , or else skb->cb[] may contain garbage from
GSO segmentation layer.
But commit 0e6fbc5b6c621("ip_tunnels: extend iptunnel_xmit()") refactor codes,
and it clear IPCB behind the dst_link_failure().
So clear IPCB in ip_tunnel_xmit() just like commti a622260254ee48("ip_tunnel:
fix kernel panic with icmp_dest_unreach").
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
net/ipv4/ip_tunnel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 90ff957..dda1e9a 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -535,6 +535,7 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
inner_iph = (const struct iphdr *)skb_inner_network_header(skb);
+ memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
dst = tnl_params->daddr;
if (dst == 0) {
/* NBMA tunnel */
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 4/7] sctp: remove macros sctp_write_[un]_lock
From: Wang Weidong @ 2014-01-21 7:44 UTC (permalink / raw)
To: nhorman, davem, vyasevich; +Cc: dborkman, netdev, linux-sctp
In-Reply-To: <1390290252-16080-1-git-send-email-wangweidong1@huawei.com>
Redefined write_[un]lock to sctp_write_[un]lock for user space
friendly code which we haven't use in years, so removing them.
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
include/net/sctp/sctp.h | 2 --
net/sctp/input.c | 16 ++++++++--------
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 4f77e98..73dcc0c 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -171,8 +171,6 @@ extern struct kmem_cache *sctp_bucket_cachep __read_mostly;
*/
/* spin lock wrappers. */
-#define sctp_write_lock(lock) write_lock(lock)
-#define sctp_write_unlock(lock) write_unlock(lock)
#define sctp_read_lock(lock) read_lock(lock)
#define sctp_read_unlock(lock) read_unlock(lock)
diff --git a/net/sctp/input.c b/net/sctp/input.c
index e22b326..94f7f440 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -718,9 +718,9 @@ static void __sctp_hash_endpoint(struct sctp_endpoint *ep)
epb->hashent = sctp_ep_hashfn(net, epb->bind_addr.port);
head = &sctp_ep_hashtable[epb->hashent];
- sctp_write_lock(&head->lock);
+ write_lock(&head->lock);
hlist_add_head(&epb->node, &head->chain);
- sctp_write_unlock(&head->lock);
+ write_unlock(&head->lock);
}
/* Add an endpoint to the hash. Local BH-safe. */
@@ -744,9 +744,9 @@ static void __sctp_unhash_endpoint(struct sctp_endpoint *ep)
head = &sctp_ep_hashtable[epb->hashent];
- sctp_write_lock(&head->lock);
+ write_lock(&head->lock);
hlist_del_init(&epb->node);
- sctp_write_unlock(&head->lock);
+ write_unlock(&head->lock);
}
/* Remove endpoint from the hash. Local BH-safe. */
@@ -798,9 +798,9 @@ static void __sctp_hash_established(struct sctp_association *asoc)
head = &sctp_assoc_hashtable[epb->hashent];
- sctp_write_lock(&head->lock);
+ write_lock(&head->lock);
hlist_add_head(&epb->node, &head->chain);
- sctp_write_unlock(&head->lock);
+ write_unlock(&head->lock);
}
/* Add an association to the hash. Local BH-safe. */
@@ -828,9 +828,9 @@ static void __sctp_unhash_established(struct sctp_association *asoc)
head = &sctp_assoc_hashtable[epb->hashent];
- sctp_write_lock(&head->lock);
+ write_lock(&head->lock);
hlist_del_init(&epb->node);
- sctp_write_unlock(&head->lock);
+ write_unlock(&head->lock);
}
/* Remove association from the hash table. Local BH-safe. */
--
1.7.12
^ permalink raw reply related
* [PATCH net-next 3/7] sctp: remove macros sctp_spin_[un]lock
From: Wang Weidong @ 2014-01-21 7:44 UTC (permalink / raw)
To: nhorman, davem, vyasevich; +Cc: dborkman, netdev, linux-sctp
In-Reply-To: <1390290252-16080-1-git-send-email-wangweidong1@huawei.com>
Redefined spin_[un]lock to sctp_spin_[un]lock for user space friendly
code which we haven't use in years, so removing them.
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
include/net/sctp/sctp.h | 6 ++----
net/sctp/socket.c | 16 ++++++++--------
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index c17121a..4f77e98 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -171,8 +171,6 @@ extern struct kmem_cache *sctp_bucket_cachep __read_mostly;
*/
/* spin lock wrappers. */
-#define sctp_spin_lock(lock) spin_lock(lock)
-#define sctp_spin_unlock(lock) spin_unlock(lock)
#define sctp_write_lock(lock) write_lock(lock)
#define sctp_write_unlock(lock) write_unlock(lock)
#define sctp_read_lock(lock) read_lock(lock)
@@ -349,11 +347,11 @@ static inline void sctp_skb_list_tail(struct sk_buff_head *list,
unsigned long flags;
spin_lock_irqsave(&head->lock, flags);
- sctp_spin_lock(&list->lock);
+ spin_lock(&list->lock);
skb_queue_splice_tail_init(list, head);
- sctp_spin_unlock(&list->lock);
+ spin_unlock(&list->lock);
spin_unlock_irqrestore(&head->lock, flags);
}
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index f2e0005..98532cb 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -5937,14 +5937,14 @@ static long sctp_get_port_local(struct sock *sk, union sctp_addr *addr)
continue;
index = sctp_phashfn(sock_net(sk), rover);
head = &sctp_port_hashtable[index];
- sctp_spin_lock(&head->lock);
+ spin_lock(&head->lock);
sctp_for_each_hentry(pp, &head->chain)
if ((pp->port == rover) &&
net_eq(sock_net(sk), pp->net))
goto next;
break;
next:
- sctp_spin_unlock(&head->lock);
+ spin_unlock(&head->lock);
} while (--remaining > 0);
/* Exhausted local port range during search? */
@@ -5965,7 +5965,7 @@ static long sctp_get_port_local(struct sock *sk, union sctp_addr *addr)
* port iterator, pp being NULL.
*/
head = &sctp_port_hashtable[sctp_phashfn(sock_net(sk), snum)];
- sctp_spin_lock(&head->lock);
+ spin_lock(&head->lock);
sctp_for_each_hentry(pp, &head->chain) {
if ((pp->port == snum) && net_eq(pp->net, sock_net(sk)))
goto pp_found;
@@ -6049,7 +6049,7 @@ success:
ret = 0;
fail_unlock:
- sctp_spin_unlock(&head->lock);
+ spin_unlock(&head->lock);
fail:
local_bh_enable();
@@ -6286,13 +6286,13 @@ static inline void __sctp_put_port(struct sock *sk)
inet_sk(sk)->inet_num)];
struct sctp_bind_bucket *pp;
- sctp_spin_lock(&head->lock);
+ spin_lock(&head->lock);
pp = sctp_sk(sk)->bind_hash;
__sk_del_bind_node(sk);
sctp_sk(sk)->bind_hash = NULL;
inet_sk(sk)->inet_num = 0;
sctp_bucket_destroy(pp);
- sctp_spin_unlock(&head->lock);
+ spin_unlock(&head->lock);
}
void sctp_put_port(struct sock *sk)
@@ -6951,12 +6951,12 @@ static void sctp_sock_migrate(struct sock *oldsk, struct sock *newsk,
head = &sctp_port_hashtable[sctp_phashfn(sock_net(oldsk),
inet_sk(oldsk)->inet_num)];
local_bh_disable();
- sctp_spin_lock(&head->lock);
+ spin_lock(&head->lock);
pp = sctp_sk(oldsk)->bind_hash;
sk_add_bind_node(newsk, &pp->owner);
sctp_sk(newsk)->bind_hash = pp;
inet_sk(newsk)->inet_num = inet_sk(oldsk)->inet_num;
- sctp_spin_unlock(&head->lock);
+ spin_unlock(&head->lock);
local_bh_enable();
/* Copy the bind_addr list from the original endpoint to the new
--
1.7.12
^ permalink raw reply related
* [PATCH net-next 0/7] sctp: remove some macro locking wrappers
From: Wang Weidong @ 2014-01-21 7:44 UTC (permalink / raw)
To: nhorman, davem, vyasevich; +Cc: dborkman, netdev, linux-sctp
In sctp.h we can find some macro locking wrappers. As Neil point out that:
"Its because in the origional implementation of the sctp protocol, there was a
user space test harness which built the kernel module for userspace execution to
cary our some unit testing on the code. It did so by redefining some of those
locking macros to user space friendly code. IIRC we haven't use those unit
tests in years, and so should be removing them, not adding them to other
locations."
So I remove them.
Wang Weidong (7):
sctp: remove macro sctp_spin_[un]lock_irqrestore
sctp: remove macro sctp_local_bh_{disable|enable}
sctp: remove macro sctp_spin_[un]lock
sctp: remove macros sctp_write_[un]_lock
sctp: remove macros sctp_read_[un]lock
sctp: remove macros sctp_{lock|release}_sock
sctp: remove macros sctp_bh_[un]lock_sock
include/net/sctp/sctp.h | 27 ++-----------
net/sctp/endpointola.c | 4 +-
net/sctp/input.c | 54 +++++++++++++-------------
net/sctp/proc.c | 12 +++---
net/sctp/protocol.c | 4 +-
net/sctp/sm_sideeffect.c | 16 ++++----
net/sctp/socket.c | 98 ++++++++++++++++++++++++------------------------
7 files changed, 98 insertions(+), 117 deletions(-)
--
1.7.12
^ permalink raw reply
* [PATCH net-next 2/7] sctp: remove macros sctp_local_bh_{disable|enable}
From: Wang Weidong @ 2014-01-21 7:44 UTC (permalink / raw)
To: nhorman, davem, vyasevich; +Cc: dborkman, netdev, linux-sctp
In-Reply-To: <1390290252-16080-1-git-send-email-wangweidong1@huawei.com>
Redefined local_bh_{disable|enable} to sctp_local_bh_{disable|enable}
for user space friendly code which we haven't use in years, so removing them.
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
include/net/sctp/sctp.h | 2 --
net/sctp/endpointola.c | 4 ++--
net/sctp/input.c | 20 ++++++++++----------
net/sctp/proc.c | 12 ++++++------
net/sctp/socket.c | 16 ++++++++--------
5 files changed, 26 insertions(+), 28 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index b180a8f..c17121a 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -171,8 +171,6 @@ extern struct kmem_cache *sctp_bucket_cachep __read_mostly;
*/
/* spin lock wrappers. */
-#define sctp_local_bh_disable() local_bh_disable()
-#define sctp_local_bh_enable() local_bh_enable()
#define sctp_spin_lock(lock) spin_lock(lock)
#define sctp_spin_unlock(lock) spin_unlock(lock)
#define sctp_write_lock(lock) write_lock(lock)
diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
index 6ffb6c1..8e5fdea 100644
--- a/net/sctp/endpointola.c
+++ b/net/sctp/endpointola.c
@@ -368,9 +368,9 @@ struct sctp_association *sctp_endpoint_lookup_assoc(
{
struct sctp_association *asoc;
- sctp_local_bh_disable();
+ local_bh_disable();
asoc = __sctp_endpoint_lookup_assoc(ep, paddr, transport);
- sctp_local_bh_enable();
+ local_bh_enable();
return asoc;
}
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 1f4eeb4..e22b326 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -726,9 +726,9 @@ static void __sctp_hash_endpoint(struct sctp_endpoint *ep)
/* Add an endpoint to the hash. Local BH-safe. */
void sctp_hash_endpoint(struct sctp_endpoint *ep)
{
- sctp_local_bh_disable();
+ local_bh_disable();
__sctp_hash_endpoint(ep);
- sctp_local_bh_enable();
+ local_bh_enable();
}
/* Remove endpoint from the hash table. */
@@ -752,9 +752,9 @@ static void __sctp_unhash_endpoint(struct sctp_endpoint *ep)
/* Remove endpoint from the hash. Local BH-safe. */
void sctp_unhash_endpoint(struct sctp_endpoint *ep)
{
- sctp_local_bh_disable();
+ local_bh_disable();
__sctp_unhash_endpoint(ep);
- sctp_local_bh_enable();
+ local_bh_enable();
}
/* Look up an endpoint. */
@@ -809,9 +809,9 @@ void sctp_hash_established(struct sctp_association *asoc)
if (asoc->temp)
return;
- sctp_local_bh_disable();
+ local_bh_disable();
__sctp_hash_established(asoc);
- sctp_local_bh_enable();
+ local_bh_enable();
}
/* Remove association from the hash table. */
@@ -839,9 +839,9 @@ void sctp_unhash_established(struct sctp_association *asoc)
if (asoc->temp)
return;
- sctp_local_bh_disable();
+ local_bh_disable();
__sctp_unhash_established(asoc);
- sctp_local_bh_enable();
+ local_bh_enable();
}
/* Look up an association. */
@@ -891,9 +891,9 @@ struct sctp_association *sctp_lookup_association(struct net *net,
{
struct sctp_association *asoc;
- sctp_local_bh_disable();
+ local_bh_disable();
asoc = __sctp_lookup_association(net, laddr, paddr, transportp);
- sctp_local_bh_enable();
+ local_bh_enable();
return asoc;
}
diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index 63ba0bd..0947f1e 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -218,7 +218,7 @@ static int sctp_eps_seq_show(struct seq_file *seq, void *v)
return -ENOMEM;
head = &sctp_ep_hashtable[hash];
- sctp_local_bh_disable();
+ local_bh_disable();
read_lock(&head->lock);
sctp_for_each_hentry(epb, &head->chain) {
ep = sctp_ep(epb);
@@ -235,7 +235,7 @@ static int sctp_eps_seq_show(struct seq_file *seq, void *v)
seq_printf(seq, "\n");
}
read_unlock(&head->lock);
- sctp_local_bh_enable();
+ local_bh_enable();
return 0;
}
@@ -326,7 +326,7 @@ static int sctp_assocs_seq_show(struct seq_file *seq, void *v)
return -ENOMEM;
head = &sctp_assoc_hashtable[hash];
- sctp_local_bh_disable();
+ local_bh_disable();
read_lock(&head->lock);
sctp_for_each_hentry(epb, &head->chain) {
assoc = sctp_assoc(epb);
@@ -362,7 +362,7 @@ static int sctp_assocs_seq_show(struct seq_file *seq, void *v)
seq_printf(seq, "\n");
}
read_unlock(&head->lock);
- sctp_local_bh_enable();
+ local_bh_enable();
return 0;
}
@@ -446,7 +446,7 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
return -ENOMEM;
head = &sctp_assoc_hashtable[hash];
- sctp_local_bh_disable();
+ local_bh_disable();
read_lock(&head->lock);
rcu_read_lock();
sctp_for_each_hentry(epb, &head->chain) {
@@ -505,7 +505,7 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
rcu_read_unlock();
read_unlock(&head->lock);
- sctp_local_bh_enable();
+ local_bh_enable();
return 0;
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index fd7337a..f2e0005 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1510,7 +1510,7 @@ static void sctp_close(struct sock *sk, long timeout)
/* Supposedly, no process has access to the socket, but
* the net layers still may.
*/
- sctp_local_bh_disable();
+ local_bh_disable();
sctp_bh_lock_sock(sk);
/* Hold the sock, since sk_common_release() will put sock_put()
@@ -1520,7 +1520,7 @@ static void sctp_close(struct sock *sk, long timeout)
sk_common_release(sk);
sctp_bh_unlock_sock(sk);
- sctp_local_bh_enable();
+ local_bh_enable();
sock_put(sk);
@@ -5918,7 +5918,7 @@ static long sctp_get_port_local(struct sock *sk, union sctp_addr *addr)
pr_debug("%s: begins, snum:%d\n", __func__, snum);
- sctp_local_bh_disable();
+ local_bh_disable();
if (snum == 0) {
/* Search for an available port. */
@@ -6052,7 +6052,7 @@ fail_unlock:
sctp_spin_unlock(&head->lock);
fail:
- sctp_local_bh_enable();
+ local_bh_enable();
return ret;
}
@@ -6297,9 +6297,9 @@ static inline void __sctp_put_port(struct sock *sk)
void sctp_put_port(struct sock *sk)
{
- sctp_local_bh_disable();
+ local_bh_disable();
__sctp_put_port(sk);
- sctp_local_bh_enable();
+ local_bh_enable();
}
/*
@@ -6950,14 +6950,14 @@ static void sctp_sock_migrate(struct sock *oldsk, struct sock *newsk,
/* Hook this new socket in to the bind_hash list. */
head = &sctp_port_hashtable[sctp_phashfn(sock_net(oldsk),
inet_sk(oldsk)->inet_num)];
- sctp_local_bh_disable();
+ local_bh_disable();
sctp_spin_lock(&head->lock);
pp = sctp_sk(oldsk)->bind_hash;
sk_add_bind_node(newsk, &pp->owner);
sctp_sk(newsk)->bind_hash = pp;
inet_sk(newsk)->inet_num = inet_sk(oldsk)->inet_num;
sctp_spin_unlock(&head->lock);
- sctp_local_bh_enable();
+ local_bh_enable();
/* Copy the bind_addr list from the original endpoint to the new
* endpoint so that we can handle restarts properly
--
1.7.12
^ permalink raw reply related
* [PATCH net-next 5/7] sctp: remove macros sctp_read_[un]lock
From: Wang Weidong @ 2014-01-21 7:44 UTC (permalink / raw)
To: nhorman, davem, vyasevich; +Cc: dborkman, netdev, linux-sctp
In-Reply-To: <1390290252-16080-1-git-send-email-wangweidong1@huawei.com>
Redefined read_[un]lock to sctp_read_[un]lock for user space
friendly code which we haven't use in years, and the macros
we never used, so removing them.
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
include/net/sctp/sctp.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 73dcc0c..572cd5a 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -170,10 +170,6 @@ extern struct kmem_cache *sctp_bucket_cachep __read_mostly;
* Section: Macros, externs, and inlines
*/
-/* spin lock wrappers. */
-#define sctp_read_lock(lock) read_lock(lock)
-#define sctp_read_unlock(lock) read_unlock(lock)
-
/* sock lock wrappers. */
#define sctp_lock_sock(sk) lock_sock(sk)
#define sctp_release_sock(sk) release_sock(sk)
--
1.7.12
^ permalink raw reply related
* [PATCH net-next 6/7] sctp: remove macros sctp_{lock|release}_sock
From: Wang Weidong @ 2014-01-21 7:44 UTC (permalink / raw)
To: nhorman, davem, vyasevich; +Cc: dborkman, netdev, linux-sctp
In-Reply-To: <1390290252-16080-1-git-send-email-wangweidong1@huawei.com>
Redefined {lock|release}_sock to sctp_{lock|release}_sock for user space friendly
code which we haven't use in years, so removing them.
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
include/net/sctp/sctp.h | 2 --
net/sctp/socket.c | 62 ++++++++++++++++++++++++-------------------------
2 files changed, 31 insertions(+), 33 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 572cd5a..ec18d30 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -171,8 +171,6 @@ extern struct kmem_cache *sctp_bucket_cachep __read_mostly;
*/
/* sock lock wrappers. */
-#define sctp_lock_sock(sk) lock_sock(sk)
-#define sctp_release_sock(sk) release_sock(sk)
#define sctp_bh_lock_sock(sk) bh_lock_sock(sk)
#define sctp_bh_unlock_sock(sk) bh_unlock_sock(sk)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 98532cb..893aa56 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -272,7 +272,7 @@ static int sctp_bind(struct sock *sk, struct sockaddr *addr, int addr_len)
{
int retval = 0;
- sctp_lock_sock(sk);
+ lock_sock(sk);
pr_debug("%s: sk:%p, addr:%p, addr_len:%d\n", __func__, sk,
addr, addr_len);
@@ -284,7 +284,7 @@ static int sctp_bind(struct sock *sk, struct sockaddr *addr, int addr_len)
else
retval = -EINVAL;
- sctp_release_sock(sk);
+ release_sock(sk);
return retval;
}
@@ -1461,7 +1461,7 @@ static void sctp_close(struct sock *sk, long timeout)
pr_debug("%s: sk:%p, timeout:%ld\n", __func__, sk, timeout);
- sctp_lock_sock(sk);
+ lock_sock(sk);
sk->sk_shutdown = SHUTDOWN_MASK;
sk->sk_state = SCTP_SS_CLOSING;
@@ -1505,7 +1505,7 @@ static void sctp_close(struct sock *sk, long timeout)
sctp_wait_for_close(sk, timeout);
/* This will run the backlog queue. */
- sctp_release_sock(sk);
+ release_sock(sk);
/* Supposedly, no process has access to the socket, but
* the net layers still may.
@@ -1665,7 +1665,7 @@ static int sctp_sendmsg(struct kiocb *iocb, struct sock *sk,
pr_debug("%s: about to look up association\n", __func__);
- sctp_lock_sock(sk);
+ lock_sock(sk);
/* If a msg_name has been specified, assume this is to be used. */
if (msg_name) {
@@ -1949,7 +1949,7 @@ out_free:
sctp_association_free(asoc);
}
out_unlock:
- sctp_release_sock(sk);
+ release_sock(sk);
out_nounlock:
return sctp_error(sk, msg_flags, err);
@@ -2035,7 +2035,7 @@ static int sctp_recvmsg(struct kiocb *iocb, struct sock *sk,
"addr_len:%p)\n", __func__, sk, msg, len, noblock, flags,
addr_len);
- sctp_lock_sock(sk);
+ lock_sock(sk);
if (sctp_style(sk, TCP) && !sctp_sstate(sk, ESTABLISHED)) {
err = -ENOTCONN;
@@ -2119,7 +2119,7 @@ out_free:
sctp_ulpevent_free(event);
}
out:
- sctp_release_sock(sk);
+ release_sock(sk);
return err;
}
@@ -3590,7 +3590,7 @@ static int sctp_setsockopt(struct sock *sk, int level, int optname,
goto out_nounlock;
}
- sctp_lock_sock(sk);
+ lock_sock(sk);
switch (optname) {
case SCTP_SOCKOPT_BINDX_ADD:
@@ -3708,7 +3708,7 @@ static int sctp_setsockopt(struct sock *sk, int level, int optname,
break;
}
- sctp_release_sock(sk);
+ release_sock(sk);
out_nounlock:
return retval;
@@ -3736,7 +3736,7 @@ static int sctp_connect(struct sock *sk, struct sockaddr *addr,
int err = 0;
struct sctp_af *af;
- sctp_lock_sock(sk);
+ lock_sock(sk);
pr_debug("%s: sk:%p, sockaddr:%p, addr_len:%d\n", __func__, sk,
addr, addr_len);
@@ -3752,7 +3752,7 @@ static int sctp_connect(struct sock *sk, struct sockaddr *addr,
err = __sctp_connect(sk, addr, af->sockaddr_len, NULL);
}
- sctp_release_sock(sk);
+ release_sock(sk);
return err;
}
@@ -3778,7 +3778,7 @@ static struct sock *sctp_accept(struct sock *sk, int flags, int *err)
long timeo;
int error = 0;
- sctp_lock_sock(sk);
+ lock_sock(sk);
sp = sctp_sk(sk);
ep = sp->ep;
@@ -3816,7 +3816,7 @@ static struct sock *sctp_accept(struct sock *sk, int flags, int *err)
sctp_sock_migrate(sk, newsk, asoc, SCTP_SOCKET_TCP);
out:
- sctp_release_sock(sk);
+ release_sock(sk);
*err = error;
return newsk;
}
@@ -3826,7 +3826,7 @@ static int sctp_ioctl(struct sock *sk, int cmd, unsigned long arg)
{
int rc = -ENOTCONN;
- sctp_lock_sock(sk);
+ lock_sock(sk);
/*
* SEQPACKET-style sockets in LISTENING state are valid, for
@@ -3856,7 +3856,7 @@ static int sctp_ioctl(struct sock *sk, int cmd, unsigned long arg)
break;
}
out:
- sctp_release_sock(sk);
+ release_sock(sk);
return rc;
}
@@ -5754,7 +5754,7 @@ static int sctp_getsockopt(struct sock *sk, int level, int optname,
if (get_user(len, optlen))
return -EFAULT;
- sctp_lock_sock(sk);
+ lock_sock(sk);
switch (optname) {
case SCTP_STATUS:
@@ -5878,7 +5878,7 @@ static int sctp_getsockopt(struct sock *sk, int level, int optname,
break;
}
- sctp_release_sock(sk);
+ release_sock(sk);
return retval;
}
@@ -6144,7 +6144,7 @@ int sctp_inet_listen(struct socket *sock, int backlog)
if (unlikely(backlog < 0))
return err;
- sctp_lock_sock(sk);
+ lock_sock(sk);
/* Peeled-off sockets are not allowed to listen(). */
if (sctp_style(sk, UDP_HIGH_BANDWIDTH))
@@ -6177,7 +6177,7 @@ int sctp_inet_listen(struct socket *sock, int backlog)
err = 0;
out:
- sctp_release_sock(sk);
+ release_sock(sk);
return err;
}
@@ -6474,9 +6474,9 @@ static int sctp_wait_for_packet(struct sock *sk, int *err, long *timeo_p)
* does not fit in the user's buffer, but this seems to be the
* only way to honor MSG_DONTWAIT realistically.
*/
- sctp_release_sock(sk);
+ release_sock(sk);
*timeo_p = schedule_timeout(*timeo_p);
- sctp_lock_sock(sk);
+ lock_sock(sk);
ready:
finish_wait(sk_sleep(sk), &wait);
@@ -6659,10 +6659,10 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p,
/* Let another process have a go. Since we are going
* to sleep anyway.
*/
- sctp_release_sock(sk);
+ release_sock(sk);
current_timeo = schedule_timeout(current_timeo);
BUG_ON(sk != asoc->base.sk);
- sctp_lock_sock(sk);
+ lock_sock(sk);
*timeo_p = current_timeo;
}
@@ -6767,9 +6767,9 @@ static int sctp_wait_for_connect(struct sctp_association *asoc, long *timeo_p)
/* Let another process have a go. Since we are going
* to sleep anyway.
*/
- sctp_release_sock(sk);
+ release_sock(sk);
current_timeo = schedule_timeout(current_timeo);
- sctp_lock_sock(sk);
+ lock_sock(sk);
*timeo_p = current_timeo;
}
@@ -6812,9 +6812,9 @@ static int sctp_wait_for_accept(struct sock *sk, long timeo)
TASK_INTERRUPTIBLE);
if (list_empty(&ep->asocs)) {
- sctp_release_sock(sk);
+ release_sock(sk);
timeo = schedule_timeout(timeo);
- sctp_lock_sock(sk);
+ lock_sock(sk);
}
err = -EINVAL;
@@ -6847,9 +6847,9 @@ static void sctp_wait_for_close(struct sock *sk, long timeout)
prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
if (list_empty(&sctp_sk(sk)->ep->asocs))
break;
- sctp_release_sock(sk);
+ release_sock(sk);
timeout = schedule_timeout(timeout);
- sctp_lock_sock(sk);
+ lock_sock(sk);
} while (!signal_pending(current) && timeout);
finish_wait(sk_sleep(sk), &wait);
@@ -7046,7 +7046,7 @@ static void sctp_sock_migrate(struct sock *oldsk, struct sock *newsk,
newsk->sk_shutdown |= RCV_SHUTDOWN;
newsk->sk_state = SCTP_SS_ESTABLISHED;
- sctp_release_sock(newsk);
+ release_sock(newsk);
}
--
1.7.12
^ permalink raw reply related
* [PATCH net-next 7/7] sctp: remove macros sctp_bh_[un]lock_sock
From: Wang Weidong @ 2014-01-21 7:44 UTC (permalink / raw)
To: nhorman, davem, vyasevich; +Cc: dborkman, netdev, linux-sctp
In-Reply-To: <1390290252-16080-1-git-send-email-wangweidong1@huawei.com>
Redefined bh_[un]lock_sock to sctp_bh[un]lock_sock for user
space friendly code which we haven't use in years, so removing them.
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
include/net/sctp/sctp.h | 4 ----
net/sctp/input.c | 18 +++++++++---------
net/sctp/protocol.c | 4 ++--
net/sctp/sm_sideeffect.c | 16 ++++++++--------
net/sctp/socket.c | 4 ++--
5 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index ec18d30..a3353f4 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -170,10 +170,6 @@ extern struct kmem_cache *sctp_bucket_cachep __read_mostly;
* Section: Macros, externs, and inlines
*/
-/* sock lock wrappers. */
-#define sctp_bh_lock_sock(sk) bh_lock_sock(sk)
-#define sctp_bh_unlock_sock(sk) bh_unlock_sock(sk)
-
/* SCTP SNMP MIB stats handlers */
#define SCTP_INC_STATS(net, field) SNMP_INC_STATS((net)->sctp.sctp_statistics, field)
#define SCTP_INC_STATS_BH(net, field) SNMP_INC_STATS_BH((net)->sctp.sctp_statistics, field)
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 94f7f440..f2e2cbd 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -238,7 +238,7 @@ int sctp_rcv(struct sk_buff *skb)
* bottom halves on this lock, but a user may be in the lock too,
* so check if it is busy.
*/
- sctp_bh_lock_sock(sk);
+ bh_lock_sock(sk);
if (sk != rcvr->sk) {
/* Our cached sk is different from the rcvr->sk. This is
@@ -248,14 +248,14 @@ int sctp_rcv(struct sk_buff *skb)
* be doing something with the new socket. Switch our veiw
* of the current sk.
*/
- sctp_bh_unlock_sock(sk);
+ bh_unlock_sock(sk);
sk = rcvr->sk;
- sctp_bh_lock_sock(sk);
+ bh_lock_sock(sk);
}
if (sock_owned_by_user(sk)) {
if (sctp_add_backlog(sk, skb)) {
- sctp_bh_unlock_sock(sk);
+ bh_unlock_sock(sk);
sctp_chunk_free(chunk);
skb = NULL; /* sctp_chunk_free already freed the skb */
goto discard_release;
@@ -266,7 +266,7 @@ int sctp_rcv(struct sk_buff *skb)
sctp_inq_push(&chunk->rcvr->inqueue, chunk);
}
- sctp_bh_unlock_sock(sk);
+ bh_unlock_sock(sk);
/* Release the asoc/ep ref we took in the lookup calls. */
if (asoc)
@@ -327,7 +327,7 @@ int sctp_backlog_rcv(struct sock *sk, struct sk_buff *skb)
*/
sk = rcvr->sk;
- sctp_bh_lock_sock(sk);
+ bh_lock_sock(sk);
if (sock_owned_by_user(sk)) {
if (sk_add_backlog(sk, skb, sk->sk_rcvbuf))
@@ -337,7 +337,7 @@ int sctp_backlog_rcv(struct sock *sk, struct sk_buff *skb)
} else
sctp_inq_push(inqueue, chunk);
- sctp_bh_unlock_sock(sk);
+ bh_unlock_sock(sk);
/* If the chunk was backloged again, don't drop refs */
if (backloged)
@@ -522,7 +522,7 @@ struct sock *sctp_err_lookup(struct net *net, int family, struct sk_buff *skb,
goto out;
}
- sctp_bh_lock_sock(sk);
+ bh_lock_sock(sk);
/* If too many ICMPs get dropped on busy
* servers this needs to be solved differently.
@@ -542,7 +542,7 @@ out:
/* Common cleanup code for icmp/icmpv6 error handler. */
void sctp_err_finish(struct sock *sk, struct sctp_association *asoc)
{
- sctp_bh_unlock_sock(sk);
+ bh_unlock_sock(sk);
sctp_association_put(asoc);
}
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index d6934dc..4e1d0fc 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -634,10 +634,10 @@ static void sctp_addr_wq_timeout_handler(unsigned long arg)
/* ignore bound-specific endpoints */
if (!sctp_is_ep_boundall(sk))
continue;
- sctp_bh_lock_sock(sk);
+ bh_lock_sock(sk);
if (sctp_asconf_mgmt(sp, addrw) < 0)
pr_debug("%s: sctp_asconf_mgmt failed\n", __func__);
- sctp_bh_unlock_sock(sk);
+ bh_unlock_sock(sk);
}
#if IS_ENABLED(CONFIG_IPV6)
free_next:
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index ded6db6..bd85915 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -248,7 +248,7 @@ void sctp_generate_t3_rtx_event(unsigned long peer)
/* Check whether a task is in the sock. */
- sctp_bh_lock_sock(asoc->base.sk);
+ bh_lock_sock(asoc->base.sk);
if (sock_owned_by_user(asoc->base.sk)) {
pr_debug("%s: sock is busy\n", __func__);
@@ -275,7 +275,7 @@ void sctp_generate_t3_rtx_event(unsigned long peer)
asoc->base.sk->sk_err = -error;
out_unlock:
- sctp_bh_unlock_sock(asoc->base.sk);
+ bh_unlock_sock(asoc->base.sk);
sctp_transport_put(transport);
}
@@ -288,7 +288,7 @@ static void sctp_generate_timeout_event(struct sctp_association *asoc,
struct net *net = sock_net(asoc->base.sk);
int error = 0;
- sctp_bh_lock_sock(asoc->base.sk);
+ bh_lock_sock(asoc->base.sk);
if (sock_owned_by_user(asoc->base.sk)) {
pr_debug("%s: sock is busy: timer %d\n", __func__,
timeout_type);
@@ -315,7 +315,7 @@ static void sctp_generate_timeout_event(struct sctp_association *asoc,
asoc->base.sk->sk_err = -error;
out_unlock:
- sctp_bh_unlock_sock(asoc->base.sk);
+ bh_unlock_sock(asoc->base.sk);
sctp_association_put(asoc);
}
@@ -367,7 +367,7 @@ void sctp_generate_heartbeat_event(unsigned long data)
struct sctp_association *asoc = transport->asoc;
struct net *net = sock_net(asoc->base.sk);
- sctp_bh_lock_sock(asoc->base.sk);
+ bh_lock_sock(asoc->base.sk);
if (sock_owned_by_user(asoc->base.sk)) {
pr_debug("%s: sock is busy\n", __func__);
@@ -392,7 +392,7 @@ void sctp_generate_heartbeat_event(unsigned long data)
asoc->base.sk->sk_err = -error;
out_unlock:
- sctp_bh_unlock_sock(asoc->base.sk);
+ bh_unlock_sock(asoc->base.sk);
sctp_transport_put(transport);
}
@@ -405,7 +405,7 @@ void sctp_generate_proto_unreach_event(unsigned long data)
struct sctp_association *asoc = transport->asoc;
struct net *net = sock_net(asoc->base.sk);
- sctp_bh_lock_sock(asoc->base.sk);
+ bh_lock_sock(asoc->base.sk);
if (sock_owned_by_user(asoc->base.sk)) {
pr_debug("%s: sock is busy\n", __func__);
@@ -427,7 +427,7 @@ void sctp_generate_proto_unreach_event(unsigned long data)
asoc->state, asoc->ep, asoc, transport, GFP_ATOMIC);
out_unlock:
- sctp_bh_unlock_sock(asoc->base.sk);
+ bh_unlock_sock(asoc->base.sk);
sctp_association_put(asoc);
}
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 893aa56..9e91d6e 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1511,7 +1511,7 @@ static void sctp_close(struct sock *sk, long timeout)
* the net layers still may.
*/
local_bh_disable();
- sctp_bh_lock_sock(sk);
+ bh_lock_sock(sk);
/* Hold the sock, since sk_common_release() will put sock_put()
* and we have just a little more cleanup.
@@ -1519,7 +1519,7 @@ static void sctp_close(struct sock *sk, long timeout)
sock_hold(sk);
sk_common_release(sk);
- sctp_bh_unlock_sock(sk);
+ bh_unlock_sock(sk);
local_bh_enable();
sock_put(sk);
--
1.7.12
^ permalink raw reply related
* [PATCH net-next 1/7] sctp: remove macros sctp_spin_[un]lock_irqrestore
From: Wang Weidong @ 2014-01-21 7:44 UTC (permalink / raw)
To: nhorman, davem, vyasevich; +Cc: dborkman, netdev, linux-sctp
In-Reply-To: <1390290252-16080-1-git-send-email-wangweidong1@huawei.com>
Redefined spin_[un]lock_irqstore to sctp_spin_[un]lock_irqrestore for user
space friendly code which we haven't use in years, so removing them.
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
include/net/sctp/sctp.h | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 610a8c8..b180a8f 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -171,9 +171,6 @@ extern struct kmem_cache *sctp_bucket_cachep __read_mostly;
*/
/* spin lock wrappers. */
-#define sctp_spin_lock_irqsave(lock, flags) spin_lock_irqsave(lock, flags)
-#define sctp_spin_unlock_irqrestore(lock, flags) \
- spin_unlock_irqrestore(lock, flags)
#define sctp_local_bh_disable() local_bh_disable()
#define sctp_local_bh_enable() local_bh_enable()
#define sctp_spin_lock(lock) spin_lock(lock)
@@ -353,13 +350,13 @@ static inline void sctp_skb_list_tail(struct sk_buff_head *list,
{
unsigned long flags;
- sctp_spin_lock_irqsave(&head->lock, flags);
+ spin_lock_irqsave(&head->lock, flags);
sctp_spin_lock(&list->lock);
skb_queue_splice_tail_init(list, head);
sctp_spin_unlock(&list->lock);
- sctp_spin_unlock_irqrestore(&head->lock, flags);
+ spin_unlock_irqrestore(&head->lock, flags);
}
/**
--
1.7.12
^ permalink raw reply related
* [PATCH net-next] net/mlx4_core: Remove unnecessary validation for port number
From: Amir Vadai @ 2014-01-21 8:19 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Moni Shoua, Matan Barak, Amir Vadai
From: Moni Shoua <monis@mellanox.co.il>
This is a fix to a regression introduced by commit:
"982290a net/mlx4_core: Check port number for validity
before accessing data"
IPoIB could not attach to multicast group and we get this in dmesg:
[144214.145008] ib0: failed to attach to multicast group, ret = -22
[144214.145016] ib0: couldn't attach QP to multicast group ff12:401b:ffff:0000:0000:0000:ffff:ffff
[144214.145019] ib0: multicast join failed for ff12:401b:ffff:0000:0000:0000:ffff:ffff, status -22
The cause to the problem is because port is extracted from gid[5].
Which is only valid for Ethernet.
Removed this validation in mlx4_qp_attach_common(), which is accessed
from both Ethernet and IB flows.
Error flow for bad port value in Ethernet is already exists in that
function.
Signed-off-by: Moni Shoua <monis@mellanox.co.il>
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/mcg.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mcg.c b/drivers/net/ethernet/mellanox/mlx4/mcg.c
index bfe65f7..aefb74f 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mcg.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mcg.c
@@ -943,9 +943,6 @@ int mlx4_qp_attach_common(struct mlx4_dev *dev, struct mlx4_qp *qp, u8 gid[16],
u8 port = gid[5];
u8 new_entry = 0;
- if (port < 1 || port > dev->caps.num_ports)
- return -EINVAL;
-
mailbox = mlx4_alloc_cmd_mailbox(dev);
if (IS_ERR(mailbox))
return PTR_ERR(mailbox);
--
1.8.3.4
^ permalink raw reply related
* [PATCH net] bnx2x: Fix VF flr flow
From: Yuval Mintz @ 2014-01-21 8:31 UTC (permalink / raw)
To: davem, netdev; +Cc: Ariel Elior, Yuval Mintz
From: Ariel Elior <ariele@broadcom.com>
When a VF originating from a given PF is flr-ed, that PF gets an interrupt
from the chip management and takes a part in the flr process.
This patch fixes several corner cases in which the driver performs its part
of the flr flow out-of-order, causing the FW to assert due to badly timed
messages received from the driver.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
---
Hi Dave,
Please consider applying this to `net'.
Thanks,
Yuval
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 61 ++++++++++++-----------
1 file changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index e7845e5..36e2222 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -617,7 +617,7 @@ static void bnx2x_vfop_vlan_mac(struct bnx2x *bp, struct bnx2x_virtf *vf)
&vlan_mac->user_req.vlan_mac_flags,
&vlan_mac->ramrod_flags);
- bnx2x_vfop_finalize(vf, vfop->rc, VFOP_DONE);
+ bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
case BNX2X_VFOP_VLAN_MAC_CONFIG_SINGLE:
/* next state */
@@ -628,7 +628,7 @@ static void bnx2x_vfop_vlan_mac(struct bnx2x *bp, struct bnx2x_virtf *vf)
if (vfop->rc == -EEXIST)
vfop->rc = 0;
- bnx2x_vfop_finalize(vf, vfop->rc, VFOP_DONE);
+ bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
case BNX2X_VFOP_VLAN_MAC_CHK_DONE:
vfop->rc = !!obj->raw.check_pending(&obj->raw);
@@ -645,7 +645,7 @@ static void bnx2x_vfop_vlan_mac(struct bnx2x *bp, struct bnx2x_virtf *vf)
set_bit(RAMROD_CONT, &vlan_mac->ramrod_flags);
vfop->rc = bnx2x_config_vlan_mac(bp, vlan_mac);
- bnx2x_vfop_finalize(vf, vfop->rc, VFOP_DONE);
+ bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
case BNX2X_VFOP_VLAN_CONFIG_LIST:
/* next state */
@@ -657,7 +657,7 @@ static void bnx2x_vfop_vlan_mac(struct bnx2x *bp, struct bnx2x_virtf *vf)
set_bit(RAMROD_CONT, &vlan_mac->ramrod_flags);
vfop->rc = bnx2x_config_vlan_mac(bp, vlan_mac);
}
- bnx2x_vfop_finalize(vf, vfop->rc, VFOP_DONE);
+ bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
default:
bnx2x_vfop_default(state);
@@ -1023,25 +1023,35 @@ static void bnx2x_vfop_qflr(struct bnx2x *bp, struct bnx2x_virtf *vf)
case BNX2X_VFOP_QFLR_CLR_VLAN:
/* vlan-clear-all: driver-only, don't consume credit */
vfop->state = BNX2X_VFOP_QFLR_CLR_MAC;
- if (!validate_vlan_mac(bp, &bnx2x_vfq(vf, qid, vlan_obj)))
- vfop->rc = bnx2x_vfop_vlan_delall_cmd(bp, vf, &cmd, qid,
- true);
- if (vfop->rc)
- goto op_err;
- bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
+
+ if (!validate_vlan_mac(bp, &bnx2x_vfq(vf, qid, vlan_obj))) {
+ /* the vlan_mac vfop will re-schedule us */
+ vfop->rc = bnx2x_vfop_vlan_delall_cmd(bp, vf, &cmd,
+ qid, true);
+ if (vfop->rc)
+ goto op_err;
+ return;
+
+ } else {
+ /* need to reschedule ourselves */
+ bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
+ }
case BNX2X_VFOP_QFLR_CLR_MAC:
/* mac-clear-all: driver only consume credit */
vfop->state = BNX2X_VFOP_QFLR_TERMINATE;
- if (!validate_vlan_mac(bp, &bnx2x_vfq(vf, qid, mac_obj)))
- vfop->rc = bnx2x_vfop_mac_delall_cmd(bp, vf, &cmd, qid,
- true);
- DP(BNX2X_MSG_IOV,
- "VF[%d] vfop->rc after bnx2x_vfop_mac_delall_cmd was %d",
- vf->abs_vfid, vfop->rc);
- if (vfop->rc)
- goto op_err;
- bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
+ if (!validate_vlan_mac(bp, &bnx2x_vfq(vf, qid, mac_obj))) {
+ /* the vlan_mac vfop will re-schedule us */
+ vfop->rc = bnx2x_vfop_mac_delall_cmd(bp, vf, &cmd,
+ qid, true);
+ if (vfop->rc)
+ goto op_err;
+ return;
+
+ } else {
+ /* need to reschedule ourselves */
+ bnx2x_vfop_finalize(vf, vfop->rc, VFOP_CONT);
+ }
case BNX2X_VFOP_QFLR_TERMINATE:
qstate = &vfop->op_p->qctor.qstate;
@@ -2372,8 +2382,9 @@ int bnx2x_iov_eq_sp_event(struct bnx2x *bp, union event_ring_elem *elem)
goto get_vf;
case EVENT_RING_OPCODE_MALICIOUS_VF:
abs_vfid = elem->message.data.malicious_vf_event.vf_id;
- DP(BNX2X_MSG_IOV, "Got VF MALICIOUS notification abs_vfid=%d err_id=0x%x\n",
- abs_vfid, elem->message.data.malicious_vf_event.err_id);
+ BNX2X_ERR("Got VF MALICIOUS notification abs_vfid=%d err_id=0x%x\n",
+ abs_vfid,
+ elem->message.data.malicious_vf_event.err_id);
goto get_vf;
default:
return 1;
@@ -2425,15 +2436,9 @@ get_vf:
bnx2x_vf_handle_filters_eqe(bp, vf);
break;
case EVENT_RING_OPCODE_VF_FLR:
- DP(BNX2X_MSG_IOV, "got VF [%d] FLR notification\n",
- vf->abs_vfid);
- /* Do nothing for now */
- break;
case EVENT_RING_OPCODE_MALICIOUS_VF:
- DP(BNX2X_MSG_IOV, "Got VF MALICIOUS notification abs_vfid=%d error id %x\n",
- abs_vfid, elem->message.data.malicious_vf_event.err_id);
/* Do nothing for now */
- break;
+ return 0;
}
/* SRIOV: reschedule any 'in_progress' operations */
bnx2x_iov_sp_event(bp, cid, false);
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net-next] dlm: use {lock|release}_sock instead, sctp_{lock|release}_sock
From: Wang Weidong @ 2014-01-21 8:33 UTC (permalink / raw)
To: David Miller; +Cc: ccaulfie, teigland, cluster-devel, netdev
As we remove the macros sctp_{lock|release}_sock in sctp.h, so change the use
in dlm as well.
This is a followup to ("sctp: remove macros sctp_{lock|release}_sock").
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
fs/dlm/lowcomms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index d90909e..ce53dff 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -713,11 +713,11 @@ static void process_sctp_notification(struct connection *con,
return;
/* Peel off a new sock */
- sctp_lock_sock(con->sock->sk);
+ lock_sock(con->sock->sk);
ret = sctp_do_peeloff(con->sock->sk,
sn->sn_assoc_change.sac_assoc_id,
&new_con->sock);
- sctp_release_sock(con->sock->sk);
+ release_sock(con->sock->sk);
if (ret < 0) {
log_print("Can't peel off a socket for "
"connection %d to node %d: err=%d",
--
1.7.12
^ permalink raw reply related
* Re: Reply Very Urgent.
From: Mr.Baszm Hamza @ 2014-01-21 9:32 UTC (permalink / raw)
Dear Friend,
I'm happy to inform you about my success in getting the fund
transferred under the cooperation of a new partner from China .
Presently I’m in China for investment projects with my own share of
the total sum, I have limited access to internet, but I will get back
to you as soon I finished my project. Meanwhile, I didn't forget your
past efforts and attempts to assist me in transferring those funds
despite that it failed us some how.
Now contact my secretary, his name is Rve.Garvey Julius and his Email
Address is as follows: (rve.garvejulius12@hotmail.fr) Ask him to send
you the sum of $500,000.00 token gift which I kept for you as
compensation for all the past efforts and attempts to assist me in
this matter but it was decided by all Might God. I appreciated your
efforts at that time very much. So feel free and get in touched with
my secretary Rve.Garvey Julius and instruct him where to send the
amount to you.
Please do let me know immediately you receive it so that we can share
the joy after all the sufferness at that time. In the moment, I am
very busy here because of the investment projects which me and the new
partner are having at hand, finally, remember that I had forwarded
instruction to the secretary on your behalf to receive that money, so
feel free to get in touch with Rve.Garvey Julius and he will send the
amount to you without any delay.
Contact him through email and also call him on his cell phone +226 76 32 26 98.
With best regards
Mr.Baszm Hamza
^ permalink raw reply
* Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Linus Walleij @ 2014-01-21 9:35 UTC (permalink / raw)
To: Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Chen-Yu Tsai, Mika Westerberg, Heikki Krogerus, Arnd Bergmann,
linux-arm-kernel, Johannes Berg, David S. Miller, netdev,
linux-wireless, linux-sunxi, linux-kernel, Maxime Ripard
In-Reply-To: <CAAVeFuLP4MkfXGG1FMauvUw_J63zRXdhGwxqYy5W98L1wCQNbw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Jan 21, 2014 at 4:11 AM, Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sat, Jan 18, 2014 at 8:11 AM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> gpio = devm_gpiod_get_index(&pdev->dev, NULL, 0);
>> gpio = devm_gpiod_get_index(&pdev->dev, NULL, 1);
>>
>> Heikki, are you OK with this change?
>>
>> I think this is actually necessary if the ACPI and DT unification
>> pipe dream shall limp forward, we cannot have arguments passed
>> that have a semantic effect on DT but not on ACPI... Drivers
>> that are supposed to use both ACPI and DT will always
>> have to pass NULL as con ID.
>
> I agree that's how it should be be done with the current API if your
> driver can obtain GPIOs from both ACPI and DT. This is a potential
> issue, as drivers are not supposed to make assumptions about who is
> going to be their GPIO provider. Let's say you started a driver with
> only DT in mind, and used gpio_get(dev, con_id) to get your GPIOs. DT
> bindings are thus of the form "con_id-gpio = <phandle>", and set in
> stone. Then later, someone wants to use your driver with ACPI. How do
> you handle that gracefully?
Short answer is you can't. You have to pour backward-compatibility
code into the driver first checking for that property and then falling
back to the new binding if it doesn't exist.
> I'm starting to wonder, now that ACPI is a first-class GPIO provider,
> whether we should not start to encourage the deprecation of the
> "con_id-gpio = <phandle>" binding form in DT and only use a single
> indexed GPIO property per device.
You have a valid point.
> The con_id parameter would then only
> be used as a label, which would also have the nice side-effect that
> all GPIOs used for a given function will be reported under the same
> name no matter what the GPIO provider is.
As discussed earlier in this thread I'm not sure the con_id is
suitable for labelling GPIOs. It'd be better to have a proper name
specified in DT/ACPI instead.
> From an aesthetic point of view, I definitely prefer using con_id to
> identify GPIOs instead of indexes, but I don't see how we can make it
> play nice with ACPI. Thoughts?
Let's ask the DT maintainers...
I'm a bit sceptic to the whole ACPI-DT-API-should-be-unified
just-one-function-call business, as this was just a very simple example
of what can happen to something as simple as
devm_gpiod_get[_index]().
Yours,
Linus Walleij
^ permalink raw reply
* [BUG PATCH RFC] Memory on tcp_prot with TPROXY and TCP early demux
From: Holger Eitzenberger @ 2014-01-21 9:43 UTC (permalink / raw)
To: netfilter-devel, netdev; +Cc: David Miller, Florian Westphal, Krisztian Kovacs
[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]
Hi,
I see a memory leak when using a transparent HTTP proxy using TPROXY
together with TCP early demux and Kernel v3.8.13.15 (Ubuntu stable):
unreferenced object 0xffff88008cba4a40 (size 1696):
comm "softirq", pid 0, jiffies 4294944115 (age 8907.520s)
hex dump (first 32 bytes):
0a e0 20 6a 40 04 1b 37 92 be 32 e2 e8 b4 00 00 .. j@..7..2.....
02 00 07 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff810b710a>] kmem_cache_alloc+0xad/0xb9
[<ffffffff81270185>] sk_prot_alloc+0x29/0xc5
[<ffffffff812702cf>] sk_clone_lock+0x14/0x283
[<ffffffff812aaf3a>] inet_csk_clone_lock+0xf/0x7b
[<ffffffff8129a893>] netlink_broadcast+0x14/0x16
[<ffffffff812c1573>] tcp_create_openreq_child+0x1b/0x4c3
[<ffffffff812c033e>] tcp_v4_syn_recv_sock+0x38/0x25d
[<ffffffff812c13e4>] tcp_check_req+0x25c/0x3d0
[<ffffffff812bf87a>] tcp_v4_do_rcv+0x287/0x40e
[<ffffffff812a08a7>] ip_route_input_noref+0x843/0xa55
[<ffffffff812bfeca>] tcp_v4_rcv+0x4c9/0x725
[<ffffffff812a26f4>] ip_local_deliver_finish+0xe9/0x154
[<ffffffff8127a927>] __netif_receive_skb+0x4b2/0x514
[<ffffffff8127aa77>] process_backlog+0xee/0x1c5
[<ffffffff8127c949>] net_rx_action+0xa7/0x200
[<ffffffff81209d86>] add_interrupt_randomness+0x39/0x157
But I see plenty of them, resulting in the machine going OOM after
some days.
>From looking at the TPROXY code, and with help from Florian, I see that
the memory leak is introduced in tcp_v4_early_demux():
void tcp_v4_early_demux(struct sk_buff *skb)
{
/* ... */
iph = ip_hdr(skb);
th = tcp_hdr(skb);
if (th->doff < sizeof(struct tcphdr) / 4)
return;
sk = __inet_lookup_established(dev_net(skb->dev), &tcp_hashinfo,
iph->saddr, th->source,
iph->daddr, ntohs(th->dest),
skb->skb_iif);
if (sk) {
skb->sk = sk;
where the socket is assigned unconditionally to skb->sk, also bumping
the refcnt on it. This is problematic, because in our case the skb
has already a socket assigned in the TPROXY target if being proxied
traffic. This then results in the leak I see.
The very same issue seems to be with IPv6, but haven't tested.
Because this codepath is only hit with net.ipv4.ip_early_demux enabled
(default '0') disabling Early Demux prooved to be a valid workaround
for this issue.
The patch which fixes the issue for me is attached as RFC: I simply
skip Early Demux if a local socket already has been assigned
in the target. Both for IPv4 and IPv6. kmemleak then reports
no more leaks.
Please have a look, there may be smarter ways of fixing that.
Same issue is present in net-next and v3.13.
Thanks,
/Holger
[-- Attachment #2: fix-memleak-if-TPROXY-plus-early-demux.diff --]
[-- Type: text/x-diff, Size: 3290 bytes --]
net: Fix memory leak if TPROXY used with TCP early demux
I see a memory leak when using a transparent HTTP proxy using TPROXY
together with TCP early demux and Kernel v3.8.13.15 (Ubuntu stable):
unreferenced object 0xffff88008cba4a40 (size 1696):
comm "softirq", pid 0, jiffies 4294944115 (age 8907.520s)
hex dump (first 32 bytes):
0a e0 20 6a 40 04 1b 37 92 be 32 e2 e8 b4 00 00 .. j@..7..2.....
02 00 07 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff810b710a>] kmem_cache_alloc+0xad/0xb9
[<ffffffff81270185>] sk_prot_alloc+0x29/0xc5
[<ffffffff812702cf>] sk_clone_lock+0x14/0x283
[<ffffffff812aaf3a>] inet_csk_clone_lock+0xf/0x7b
[<ffffffff8129a893>] netlink_broadcast+0x14/0x16
[<ffffffff812c1573>] tcp_create_openreq_child+0x1b/0x4c3
[<ffffffff812c033e>] tcp_v4_syn_recv_sock+0x38/0x25d
[<ffffffff812c13e4>] tcp_check_req+0x25c/0x3d0
[<ffffffff812bf87a>] tcp_v4_do_rcv+0x287/0x40e
[<ffffffff812a08a7>] ip_route_input_noref+0x843/0xa55
[<ffffffff812bfeca>] tcp_v4_rcv+0x4c9/0x725
[<ffffffff812a26f4>] ip_local_deliver_finish+0xe9/0x154
[<ffffffff8127a927>] __netif_receive_skb+0x4b2/0x514
[<ffffffff8127aa77>] process_backlog+0xee/0x1c5
[<ffffffff8127c949>] net_rx_action+0xa7/0x200
[<ffffffff81209d86>] add_interrupt_randomness+0x39/0x157
But there are many more, resulting in the machine going OOM after some
days.
>From looking at the TPROXY code, and with help from Florian, I see
that the memory leak is introduced in tcp_v4_early_demux():
void tcp_v4_early_demux(struct sk_buff *skb)
{
/* ... */
iph = ip_hdr(skb);
th = tcp_hdr(skb);
if (th->doff < sizeof(struct tcphdr) / 4)
return;
sk = __inet_lookup_established(dev_net(skb->dev), &tcp_hashinfo,
iph->saddr, th->source,
iph->daddr, ntohs(th->dest),
skb->skb_iif);
if (sk) {
skb->sk = sk;
where the socket is assigned unconditionally to skb->sk, also bumping
the refcnt on it. This is problematic, because in our case the skb
has already a socket assigned in the TPROXY target. This then results
in the leak I see.
The very same issue seems to be with IPv6, but haven't tested.
Signed-off-by: Holger Eitzenberger <holger@eitzenberger.org>
Index: net-next/net/ipv4/ip_input.c
===================================================================
--- net-next.orig/net/ipv4/ip_input.c
+++ net-next/net/ipv4/ip_input.c
@@ -314,7 +314,7 @@ static int ip_rcv_finish(struct sk_buff
const struct iphdr *iph = ip_hdr(skb);
struct rtable *rt;
- if (sysctl_ip_early_demux && !skb_dst(skb)) {
+ if (sysctl_ip_early_demux && !skb_dst(skb) && skb->sk == NULL) {
const struct net_protocol *ipprot;
int protocol = iph->protocol;
Index: net-next/net/ipv6/ip6_input.c
===================================================================
--- net-next.orig/net/ipv6/ip6_input.c
+++ net-next/net/ipv6/ip6_input.c
@@ -49,7 +49,7 @@
int ip6_rcv_finish(struct sk_buff *skb)
{
- if (sysctl_ip_early_demux && !skb_dst(skb)) {
+ if (sysctl_ip_early_demux && !skb_dst(skb) && skb->sk == NULL) {
const struct inet6_protocol *ipprot;
ipprot = rcu_dereference(inet6_protos[ipv6_hdr(skb)->nexthdr]);
^ permalink raw reply
* [PATCH net-next 0/5] bonding: Fix some issues for fail_over_mac
From: Ding Tianhong @ 2014-01-21 9:43 UTC (permalink / raw)
To: Jay Vosburgh, Veaceslav Falico, David S. Miller, Netdev,
Andy Gospodarek
The parameter fail_over_mac only affect active-backup mode, if it was
set to active or follow and works with other modes, just like RR or XOR
mode, the bonding could not set all slaves to the master's address, it
will cause the slave could not work well with master.
So set the fail_over_mac to none if the mode is not active-backup and
slight optimization for bond_set_mac_address().
Ding Tianhong (5):
bonding: The fail_over_mac should be set only in ACTIVE_BACKUP mode
bonding: don't set fail_over_mac if the mode is not active backup
bonding: bonding: set fail_over_mac to none if new mode is not active-backup
bonding: set fail_over_mac to active only in active-backup mode at
enslavement
bonding: remove the redundant judgements for bond_set_mac_address()
drivers/net/bonding/bond_main.c | 19 +++++++------------
drivers/net/bonding/bond_options.c | 12 ++++++++++++
2 files changed, 19 insertions(+), 12 deletions(-)
--
1.8.0
^ permalink raw reply
* [PATCH net-next 1/5] bonding: The fail_over_mac should be set only in ACTIVE_BACKUP mode
From: Ding Tianhong @ 2014-01-21 9:44 UTC (permalink / raw)
To: Jay Vosburgh, Veaceslav Falico, David S. Miller, Netdev,
Andy Gospodarek
According the bonding.txt, the option fail_over_mac only affect for
AB mode, but in currect code, the parameter could be set to active
or follow in every mode, this will cause bonding could not set all
slaves of an RR or XOR mode to the same MAC address at enslavement
time, so reset fail_over_mac to 0 if the mode is not ACTIVE_BACKUP.
Fix the wrong variables for pr_err().
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
drivers/net/bonding/bond_main.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 3220b48..ecff04e 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4307,12 +4307,14 @@ static int bond_check_params(struct bond_params *params)
fail_over_mac_tbl);
if (fail_over_mac_value == -1) {
pr_err("Error: invalid fail_over_mac \"%s\"\n",
- arp_validate == NULL ? "NULL" : arp_validate);
+ fail_over_mac == NULL ? "NULL" : fail_over_mac);
return -EINVAL;
}
- if (bond_mode != BOND_MODE_ACTIVEBACKUP)
- pr_warning("Warning: fail_over_mac only affects active-backup mode.\n");
+ if (bond_mode != BOND_MODE_ACTIVEBACKUP) {
+ pr_warning("Warning: fail_over_mac only affects active-backup mode, set it to 0.\n");
+ fail_over_mac_value = BOND_FOM_NONE;
+ }
} else {
fail_over_mac_value = BOND_FOM_NONE;
}
--
1.8.0
^ permalink raw reply related
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