* Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown
From: Neil Horman @ 2011-07-06 14:19 UTC (permalink / raw)
To: Thomas Graf
Cc: Vladislav Yasevich, netdev, davem, Wei Yongjun, Sridhar Samudrala,
linux-sctp
In-Reply-To: <1309958184.12098.111.camel@lsx>
On Wed, Jul 06, 2011 at 03:16:24PM +0200, Thomas Graf wrote:
> On Wed, 2011-07-06 at 08:15 -0400, Neil Horman wrote:
> > On Mon, Jul 04, 2011 at 09:50:19AM -0400, Thomas Graf wrote:
>
> > > --- a/net/sctp/sm_statefuns.c
> > > +++ b/net/sctp/sm_statefuns.c
> > > @@ -5154,7 +5154,7 @@ sctp_disposition_t sctp_sf_do_9_2_start_shutdown(
> > > * The sender of the SHUTDOWN MAY also start an overall guard timer
> > > * 'T5-shutdown-guard' to bound the overall time for shutdown sequence.
> > > */
> > > - sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_START,
> > > + sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART,
> > > SCTP_TO(SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD));
> > >
> > How come you're modifying this chunk to use TIMER_RESTART rather than
> > TIMER_START? start shutdown is where the t5 timer is actually started, isn't it?
>
> Since we also start the timer in SHUTDOWN_PENDING now if we hit
> the retransmission limit the timer may be running already and
> needs to be restarted (at least in theory).
>
> In reality the timer should be stopped though, we can only go
> from SHUTDOWN_PENDING into SHUTDOWN by actually SACKing bytes which
> will delete the timer. This may change though and I did not want
> this to bite us later on.
>
>
>
Ok, makes sense
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: 3.0.0rc6: ethtool not working without a cable
From: Ben Hutchings @ 2011-07-06 14:28 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: netdev
In-Reply-To: <201107061338.08573.a.miskiewicz@gmail.com>
On Wed, 2011-07-06 at 13:38 +0200, Arkadiusz Miskiewicz wrote:
> 3.0.0rc6, thinkpad t400 notebook.
>
> If there is no cable then ethtool reports no device. It wasn't that before
> AFAIK.
>
> ethtool version 2.6.36
>
>
> cable disconnected:
>
> [root@t400 ~]# ethtool eth0
> Settings for eth0:
> Cannot get device settings: No such device
> Cannot get wake-on-lan settings: No such device
> Cannot get message level: No such device
> Cannot get link status: No such device
> No data available
> zsh: exit 75 ethtool eth0
> [root@t400 ~]# ethtool -i eth0
> Cannot get driver information: No such device
> zsh: exit 71 ethtool -i eth0
[...]
Then there really isn't a device under that name. Maybe the driver is
getting a bogus MAC address, so that the device is renamed by udev.
Check which devices do exist, and the MAC addresses they have, using 'ip
link'.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown
From: Vladislav Yasevich @ 2011-07-06 14:31 UTC (permalink / raw)
To: netdev, davem, Wei Yongjun, Sridhar Samudrala, linux-sctp
In-Reply-To: <20110706141808.GA17652@canuck.infradead.org>
On 07/06/2011 10:18 AM, Thomas Graf wrote:
> On Wed, Jul 06, 2011 at 09:42:42AM -0400, Vladislav Yasevich wrote:
>> On a related note, were you going to re-submit the receiver patch as well?
>
> Yes
>
>> On 07/04/2011 09:50 AM, Thomas Graf wrote:
>>> + * retransmission limit. Stop that timer as soon
>>> + * as the receiver acknowledged any data.
>>> + */
>>> + t = &asoc->timers[SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD];
>>> + if (asoc->state == SCTP_STATE_SHUTDOWN_PENDING &&
>>> + timer_pending(t) && del_timer(t))
>>> + sctp_association_put(asoc);
>>> +
>>
>> I believe 'state' and 'timers' are in different cache lines, so might be able to optimize it
>> a little by checking the state prior to referencing timers array.
>
> gcc should do that but I'm fine with changing it.
>
>>> + *
>>> + * Allow the association to timeout if SHUTDOWN is
>>> + * pending in case the receiver stays in zero window
>>> + * mode forever.
>>> */
>>> if (!q->asoc->peer.rwnd &&
>>> !list_empty(&tlist) &&
>>> - (sack_ctsn+2 == q->asoc->next_tsn)) {
>>> + (sack_ctsn+2 == q->asoc->next_tsn) &&
>>> + !(q->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)) {
>>
>> Would a test for (q->asoc->state != SCTP_STATE_SHUTDOWN_PENDING) be clearer? We only
>> care about the PENDING state here.
>
> I think SHUTDOWN_RECEIVED should also be included. We continue to transmit and
> process SACKs after receiving a SHUTDOWN.
I am not sure about SHUTDOWN_RECEIVED. If we received shutdown, then we are not in
a 0 window situation. Additionally, the sender of the SHUTDOWN started the GUARD timer
and will abort after it expires. So there is no special handling on our part.
-vlad
>
>>> + * Although RFC2960 and RFC4460 specify that the overall error
>>> + * count must be cleared when a HEARTBEAT ACK is received this
>>> + * behaviour may prevent the maximum retransmission count from
>>> + * being reached while in SHUTDOWN. If the peer keeps its window
>>> + * closed not acknowledging any outstanding TSN we may rely on
>>> + * reaching the max_retrans limit via the T3-rtx timer to close
>>> + * the association which will never happen if the error count is
>>> + * reset every heartbeat interval.
>>> + */
>>> + if (!(t->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING))
>>> + t->asoc->overall_error_count = 0;
>>
>> Same here. We only care about the PENDING state. Also, please fix the comment to reflect
>> the code.
>
> Agreed.
>
>>> + if (asoc->state == SCTP_STATE_SHUTDOWN_PENDING) {
>>> + /*
>>> + * We are here likely because the receiver had its rwnd
>>> + * closed for a while and we have not been able to
>>> + * transmit the locally queued data within the maximum
>>> + * retransmission attempts limit. Start the T5
>>> + * shutdown guard timer to give the receiver one last
>>> + * chance and some additional time to recover before
>>> + * aborting.
>>> + */
>>> + sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART,
>>> + SCTP_TO(SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD));
>>
>> This is bug. You don't want to restart the timer every time you hit a T3-timeout. Remember, since you fall
>> through here, you do another retransmission and schedule another timeout. So next time the timeout happens,
>> you'll restart the SHUTDOWN_GUARD, which is not what you want.
>>
>> We want to start it once if it isn't pending, and leave it running without restart if it is already pending.
>
> Doh, absolutely. The timer_pending() check got lost between testing and submission.
>
^ permalink raw reply
* Re: 3.0.0rc6: ethtool not working without a cable
From: Arkadiusz Miskiewicz @ 2011-07-06 14:53 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1309962484.4280.25.camel@localhost>
On Wednesday 06 of July 2011, Ben Hutchings wrote:
> On Wed, 2011-07-06 at 13:38 +0200, Arkadiusz Miskiewicz wrote:
> > 3.0.0rc6, thinkpad t400 notebook.
> >
> > If there is no cable then ethtool reports no device. It wasn't that
> > before AFAIK.
> >
> > ethtool version 2.6.36
> >
> >
> > cable disconnected:
> >
> > [root@t400 ~]# ethtool eth0
> > Settings for eth0:
> > Cannot get device settings: No such device
> > Cannot get wake-on-lan settings: No such device
> > Cannot get message level: No such device
> > Cannot get link status: No such device
> > No data available
> > zsh: exit 75 ethtool eth0
> > [root@t400 ~]# ethtool -i eth0
> > Cannot get driver information: No such device
> > zsh: exit 71 ethtool -i eth0
>
> [...]
>
> Then there really isn't a device under that name. Maybe the driver is
> getting a bogus MAC address, so that the device is renamed by udev.
No, no, device exists:
[arekm@t400 ~]$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state
DOWN qlen 1000
link/ether 00:21:86:a2:19:06 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc sfq state UP qlen
1000
link/ether 00:16:eb:05:5d:08 brd ff:ff:ff:ff:ff:ff
[arekm@t400 ~]$ ethtool eth0
Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available
zsh: exit 75 ethtool eth0
[arekm@t400 ~]$
--
Arkadiusz Miśkiewicz
^ permalink raw reply
* failure to find rate WARN_ON on iwlagn
From: Dave Jones @ 2011-07-06 15:11 UTC (permalink / raw)
To: netdev; +Cc: ilw
I just hit this trace 3 times on this hardware..
04:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300
Dave
wlan0: authenticate with b8:c7:5d:0c:39:88 (try 1)
wlan0: authenticate with b8:c7:5d:0c:39:88 (try 2)
wlan0: authenticate with b8:c7:5d:0c:39:88 (try 3)
wlan0: authentication with b8:c7:5d:0c:39:88 timed out
------------[ cut here ]------------
WARNING: at include/net/mac80211.h:3081 rate_control_send_low+0x8b/0x10f [mac80211]()
Hardware name: Adamo 13
Modules linked in: sctp libcrc32c ip_queue can_raw cmtp kernelcapi rfcomm can_bcm hidp caif_socket caif af_802154 phonet af_rxrpc can pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose ax25 x25 atm appletalk ipx p8022 psnap llc p8023 tcp_lp nfs fscache fuse nfsd lockd nfs_acl auth_rpcgss sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables btusb bluetooth arc4 dell_wmi sparse_keymap snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_hda_codec_hdmi snd_hda_codec_idt cdc_ether usbnet cdc_wdm mii snd_hda_intel snd_hda_codec snd_hwdep cdc_acm uvcvideo dell_laptop snd_seq microcode videodev v4l2_compat_ioctl32 dcdbas snd_seq_device snd_pcm iwlagn mac80211 iTCO_wdt tg3 cfg80211 pcspkr joydev i2c_i801 iTCO_vendor_
support rfkill snd_timer snd soundcore snd_page_alloc wmi virtio_net kvm_intel kvm ipv6 xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
Pid: 0, comm: swapper Not tainted 3.0.0-rc5+ #89
Call Trace:
<IRQ> [<ffffffff8105acfc>] warn_slowpath_common+0x83/0x9b
[<ffffffff8105ad2e>] warn_slowpath_null+0x1a/0x1c
[<ffffffffa0252b17>] rate_control_send_low+0x8b/0x10f [mac80211]
[<ffffffffa0291c59>] rs_get_rate+0x138/0x215 [iwlagn]
[<ffffffffa0252fcf>] rate_control_get_rate+0x86/0x14c [mac80211]
[<ffffffff814cf60e>] ? _raw_spin_unlock_irqrestore+0x6c/0x7a
[<ffffffffa025bde1>] invoke_tx_handlers+0x8f3/0xf47 [mac80211]
[<ffffffffa025a4f0>] ? compare_ether_addr+0x2c/0x2c [mac80211]
[<ffffffff814c818e>] ? __slab_alloc+0x399/0x3b4
[<ffffffffa025c4b4>] ieee80211_tx+0x7f/0xaf [mac80211]
[<ffffffffa025c66a>] ieee80211_xmit+0x186/0x19a [mac80211]
[<ffffffff81060d3f>] ? __local_bh_disable+0x8c/0xbe
[<ffffffffa025d5dc>] ieee80211_tx_skb+0x56/0x5e [mac80211]
[<ffffffffa02493c3>] ieee80211_send_bar+0xda/0xe9 [mac80211]
[<ffffffffa0243928>] ieee80211_tx_status+0x25c/0x808 [mac80211]
[<ffffffff814cf600>] ? _raw_spin_unlock_irqrestore+0x5e/0x7a
[<ffffffffa0242d12>] ieee80211_tasklet_handler+0x5b/0xa8 [mac80211]
[<ffffffff81061311>] tasklet_action+0x93/0xf3
[<ffffffff810614ba>] __do_softirq+0x10f/0x257
[<ffffffff814d6bdc>] call_softirq+0x1c/0x30
[<ffffffff8100bcaa>] do_softirq+0x4b/0xa1
[<ffffffff8106189d>] irq_exit+0x5d/0xb5
[<ffffffff814d747d>] do_IRQ+0x8d/0xa4
[<ffffffff814cfc13>] common_interrupt+0x13/0x13
<EOI> [<ffffffff814d29f7>] ? notifier_call_chain+0xbb/0xbb
[<ffffffff812e11c3>] ? arch_local_irq_enable+0x8/0xd
[<ffffffff8108e2a8>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff812e1d80>] acpi_idle_enter_c1+0xa0/0xbe
[<ffffffff813e0acb>] cpuidle_idle_call+0x10c/0x1eb
[<ffffffff81009323>] cpu_idle+0xe3/0x143
[<ffffffff81d3dbc2>] ? start_kernel+0x401/0x40c
[<ffffffff814abc71>] rest_init+0xd5/0xdc
[<ffffffff814abb9c>] ? csum_partial_copy_generic+0x16c/0x16c
[<ffffffff81d3dbc2>] start_kernel+0x401/0x40c
[<ffffffff81d3d2c4>] x86_64_start_reservations+0xaf/0xb3
[<ffffffff81d3d140>] ? early_idt_handlers+0x140/0x140
[<ffffffff81d3d3ca>] x86_64_start_kernel+0x102/0x111
---[ end trace ab18f52dc63f6394 ]---
^ permalink raw reply
* Re: linux-next: build failure after merge of the staging tree
From: Greg KH @ 2011-07-06 15:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Alexey Dobriyan, David Miller, netdev
In-Reply-To: <20110706150249.f2c67b43.sfr@canb.auug.org.au>
On Wed, Jul 06, 2011 at 03:02:49PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:599:24: error: field 'tasklet' has incomplete type
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_bus_stop':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:3068:3: error: implicit declaration of function 'tasklet_kill'
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_probe':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:5376:3: error: implicit declaration of function 'tasklet_init'
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_probe_attach':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:5505:14: warning: cast to pointer from integer of different size
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_chip_recognition':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:6056:19: warning: cast from pointer to integer of different size
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_dpc_tasklet':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:6593:4: error: implicit declaration of function 'tasklet_schedule'
>
> Caused by commit a6b7a407865a ("net: remove interrupt.h inclusion from netdevice.h") from the net tree interacting with commit ("") from the atsging tree.
>
> I have applied the following merge fixup patch for today (it should be
> applicable to the staging tree directly).
Ok, I'll go queue this up right now so this doesn't cause a problem in
the future.
greg k-h
^ permalink raw reply
* Re: FW: Re: [PATCH v3 4/4] packet: Add pre-defragmentation support for ipv4
From: Eric Dumazet @ 2011-07-06 15:18 UTC (permalink / raw)
To: Penttilä Mika; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <1A61D8EA6755AF458F06EA669A4EC8182F05BCB0@JKLMAIL02.ixonos.local>
Le mercredi 06 juillet 2011 à 14:06 +0000, Penttilä Mika a écrit :
>
> > +static struct sk_buff *fanout_check_defrag(struct sk_buff *skb)
> > +{
> > + const struct iphdr *iph;
> > + u32 len;
> > +
> > + if (skb->protocol != htons(ETH_P_IP))
> > + return skb;
> > +
> > + if (!pskb_may_pull(skb, sizeof(struct iphdr)))
> > + return skb;
> > +
> > + iph = ip_hdr(skb);
> > + if (iph->ihl < 5 || iph->version != 4)
> > + return skb;
> > + if (!pskb_may_pull(skb, iph->ihl*4))
> > + return skb;
> > + iph = ip_hdr(skb);
> > + len = ntohs(iph->tot_len);
> > + if (skb->len < len || len < (iph->ihl * 4))
> > + return skb;
> > +
> > + if (ip_is_fragment(ip_hdr(skb))) {
> > + skb = skb_clone(skb, GFP_ATOMIC);
>
> Isn't this leaking the original skb?
Yes, there are several problems here.
More fundamentally, there is a problem if two (or more) applications use
FANOUT sockets.
Only one will get the defragmented packet.
We probably need to have separate frag lists, or adding/using skb->sk as
a key.
Thanks
[PATCH] packet: fix a leak in fanout_check_defrag()
Reported-by: Penttilä Mika <mika.penttila@ixonos.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/packet/af_packet.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 41f0489..69238f6 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -476,15 +476,20 @@ static struct sk_buff *fanout_check_defrag(struct sk_buff *skb)
return skb;
if (ip_is_fragment(ip_hdr(skb))) {
- skb = skb_clone(skb, GFP_ATOMIC);
- if (skb) {
- if (pskb_trim_rcsum(skb, len))
- return skb;
- memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
- if (ip_defrag(skb, IP_DEFRAG_AF_PACKET))
- return NULL;
- skb->rxhash = 0;
+ struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
+
+ if (!nskb)
+ return skb;
+ if (pskb_trim_rcsum(nskb, len)) {
+ kfree_skb(nskb);
+ return skb;
}
+ kfree_skb(skb);
+ skb = nskb;
+ memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+ if (ip_defrag(skb, IP_DEFRAG_AF_PACKET))
+ return NULL;
+ skb->rxhash = 0;
}
return skb;
}
^ permalink raw reply related
* Re: [PATCH v3 4/4] packet: Add pre-defragmentation support for ipv4
From: David Miller @ 2011-07-06 15:20 UTC (permalink / raw)
To: eric.dumazet; +Cc: mika.penttila, netdev
In-Reply-To: <1309965489.2292.27.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Jul 2011 17:18:09 +0200
> [PATCH] packet: fix a leak in fanout_check_defrag()
>
> Reported-by: Penttilä Mika <mika.penttila@ixonos.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Eric, see what I commited, it's much simpler than all
of this code movement you added, ala skb_share_check()
:-)
^ permalink raw reply
* Re: 3.0.0rc6: ethtool not working without a cable
From: Ben Hutchings @ 2011-07-06 15:26 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: netdev, e1000-devel
In-Reply-To: <201107061653.04689.a.miskiewicz@gmail.com>
On Wed, 2011-07-06 at 16:53 +0200, Arkadiusz Miskiewicz wrote:
> On Wednesday 06 of July 2011, Ben Hutchings wrote:
> > On Wed, 2011-07-06 at 13:38 +0200, Arkadiusz Miskiewicz wrote:
> > > 3.0.0rc6, thinkpad t400 notebook.
> > >
> > > If there is no cable then ethtool reports no device. It wasn't that
> > > before AFAIK.
> > >
> > > ethtool version 2.6.36
> > >
> > >
> > > cable disconnected:
> > >
> > > [root@t400 ~]# ethtool eth0
> > > Settings for eth0:
> > > Cannot get device settings: No such device
> > > Cannot get wake-on-lan settings: No such device
> > > Cannot get message level: No such device
> > > Cannot get link status: No such device
> > > No data available
> > > zsh: exit 75 ethtool eth0
> > > [root@t400 ~]# ethtool -i eth0
> > > Cannot get driver information: No such device
> > > zsh: exit 71 ethtool -i eth0
> >
> > [...]
> >
> > Then there really isn't a device under that name. Maybe the driver is
> > getting a bogus MAC address, so that the device is renamed by udev.
>
> No, no, device exists:
>
> [arekm@t400 ~]$ ip l
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state
> DOWN qlen 1000
> link/ether 00:21:86:a2:19:06 brd ff:ff:ff:ff:ff:ff
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc sfq state UP qlen
> 1000
> link/ether 00:16:eb:05:5d:08 brd ff:ff:ff:ff:ff:ff
> [arekm@t400 ~]$ ethtool eth0
> Settings for eth0:
> Cannot get device settings: No such device
> Cannot get wake-on-lan settings: No such device
> Cannot get message level: No such device
> Cannot get link status: No such device
> No data available
> zsh: exit 75 ethtool eth0
> [arekm@t400 ~]$
Then the only other explanation I can think of is that the driver has
'detached' the device due to some kind of error. The ethtool core does
have a check for that.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [PATCH RFC] igb: Fix false positive return of igb_get_auto_rd_done for 82580
From: Wyborny, Carolyn @ 2011-07-06 15:28 UTC (permalink / raw)
To: Guenter Roeck, Kirsher, Jeffrey T
Cc: Brandeburg, Jesse, Duyck, Alexander H, Ronciak, John,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Tong Ho
In-Reply-To: <20110705143105.GA27454@ericsson.com>
>-----Original Message-----
>From: Guenter Roeck [mailto:guenter.roeck@ericsson.com]
>Sent: Tuesday, July 05, 2011 7:31 AM
>To: Kirsher, Jeffrey T
>Cc: Brandeburg, Jesse; Wyborny, Carolyn; Duyck, Alexander H; Ronciak,
>John; e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; Tong Ho
>Subject: Re: [PATCH RFC] igb: Fix false positive return of
>igb_get_auto_rd_done for 82580
>
>On Tue, Jun 21, 2011 at 05:17:26PM -0400, Jeff Kirsher wrote:
>> On Tue, 2011-06-21 at 12:02 -0700, Guenter Roeck wrote:
>> > From: Tong Ho <tong.ho@ericsson.com>
>> >
>> > 82580 re-reads the port specific portion of eeprom after port reset.
>> > If called immediately after a reset, igb_get_auto_rd_done() returns
>> > false positive because the done bit has yet to transition from 1 to
>0.
>> >
>> > Add wrfl() immediately after resetting 82580 port or device,
>> > plus a 1ms delay, to avoid the problem.
>> >
>> > Signed-off-by: Tong Ho <tong.ho@ericsson.com>
>> > Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
>> > ---
>> > Sent as RFC since I am not entirely sure if the solution is the
>> > correct one
>> > to address the problem we are seeing. If there is a better solution,
>> > please
>> > let me know.
>>
>> Thank you for the suggested patch. Carolyn is the maintainer for igb
>> and we will look into this issue you are seeing and the suggested fix.
>
>Hi Jeff and Carolyn,
>
>Any update ?
>
>Thanks,
>Guenter
Sorry for the delay, we've had some holidays, its just passed internal testing and should be coming upstream shortly.
Thanks,
Carolyn
Carolyn Wyborny
Linux Development
LAN Access Division
Intel Corporation
^ permalink raw reply
* Re: [PATCH v3 4/4] packet: Add pre-defragmentation support for ipv4
From: Eric Dumazet @ 2011-07-06 15:27 UTC (permalink / raw)
To: David Miller; +Cc: mika.penttila, netdev
In-Reply-To: <20110706.082040.1487690721120263418.davem@davemloft.net>
Le mercredi 06 juillet 2011 à 08:20 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 06 Jul 2011 17:18:09 +0200
>
> > [PATCH] packet: fix a leak in fanout_check_defrag()
> >
> > Reported-by: Penttilä Mika <mika.penttila@ixonos.com>
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Eric, see what I commited, it's much simpler than all
> of this code movement you added, ala skb_share_check()
> :-)
I tried to not lose the original packet and let application catch it ;)
We probably need to add some atomic_inc(&sk->sk_drops) to at least warn
the application.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Michael Büsch @ 2011-07-06 15:32 UTC (permalink / raw)
To: Neil Horman
Cc: Eric Dumazet, Alexey Zaytsev, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <20110705220644.GB12118@hmsreliant.think-freely.org>
On Tue, 5 Jul 2011 18:06:44 -0400
Neil Horman <nhorman@tuxdriver.com> wrote:
> On Tue, Jul 05, 2011 at 10:15:40PM +0200, Eric Dumazet wrote:
> > Le mardi 05 juillet 2011 à 22:02 +0200, Eric Dumazet a écrit :
> > > Le mardi 05 juillet 2011 à 15:53 -0400, Neil Horman a écrit :
> > > > I think this is a goo idea, at least for testing. It seems odd to me that we
> > > > have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
> > > > descriptor to be processed next (the documentation isnt' very verbose on the
> > > > subject), along with the EOT bit on a descriptor. It seems like both the
> > > > register and the bit are capable of conveying the same (or at least overlapping)
> > > > information.
> > > >
> > > > I think what I'm having the most trouble with is understanding when the hw looks
> > > > at the EOT bit in the descriptor. If it completes a DMA and sees the EOT bit
> > > > set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
> > > > register? Of does it stall until such time as the DMARX_PTR register is rotated
> > > > around? What if it doesn't see the EOT bit set? Does it just keep going with
> > > > the next descriptor?
> >
> > Since there is no OWN bit (at least not on the online doc I got : it
> > says the rx_ring is read only by the NIC), I would say we really need to
> > advance DMARX_PTR to signal NIC a new entry is available for following
> > incoming frames.
> >
> > This is the reason rx_pending max value is B44_RX_RING_SIZE - 1, or else
> > chip could loop on a circular rx_ring.
> >
> Agree, although that still leaves open the question of what exactly should get
> written into the DMARX_PTR. Is it an index of the descriptor number, or a byte
> offset.
>
> Regardless, I think we ned to fix up the looping so as to prevent an EOT reset
> jumping outside of our valid ring window. Alexey, theres better ways to do
> this, but if in the interim, you could please try this patch, it makes the valid
> receive window for b44 cover the entire ring, so as to avoid this problem. It
> will at least help support or refute this theory. Note its not exactly the same
> as my previous patch. If you set the default ring pending to 512, the math in
> the b44_alloc_rx_skb path is wrong, we skip the EOT bit as well as the first
> entry in the ring. At 511 it should work out properly.
>
> Thanks
> Neil
>
>
> diff --git a/drivers/net/b44.c b/drivers/net/b44.c
> index 3d247f3..b7f5ed1 100644
> --- a/drivers/net/b44.c
> +++ b/drivers/net/b44.c
> @@ -57,7 +57,7 @@
> #define B44_MAX_MTU 1500
>
> #define B44_RX_RING_SIZE 512
> -#define B44_DEF_RX_RING_PENDING 200
> +#define B44_DEF_RX_RING_PENDING 511
> #define B44_RX_RING_BYTES (sizeof(struct dma_desc) * \
> B44_RX_RING_SIZE)
> #define B44_TX_RING_SIZE 512
You guys are mixing up quite a bit of stuff here...
The EOT bit has _nothing_ to do with the descriptor pointers.
It simply marks the last descriptor in the (linear) descriptor
page, so that it becomes an actual ring:
DDDDDDDDDDDDDDDDDDDDDDDDDDDE
| O
| T
^--------------------------|
It doesn't say anything about the read and write pointers
to the ring.
The B44_DMARX_PTR is the write-end pointer. It points one entry
beyond the end of the write area. Then there's the software pointer
where we keep track of the read position.
-rx_cons DMARX_PTR-
v v
DDDDDDDDDDDDDDDDDDDDDDDDDDE
^ ^ O
| | T
Device might write from
here to here.
On an RX interrupt (or poll), we read the _actual_ device write
pointer. (B44_DMARX_STAT & DMARX_STAT_CDMASK). If that is equal
to our stored rx_cons, the device didn't write anything.
So we read buffers until we hit the _actual_ device write pointer.
So rx_cons is equal to (B44_DMARX_STAT & DMARX_STAT_CDMASK), except
that it lags behind by one IRQ/poll.
If we read are done, we set the DMARX_PTR write pointer to one desc
beyond the buffer that we just ate. So the device is free to continue
writing the ring _up to_ the position we left.
I don't know why b44 sets the DMARX_PTR to 200 initially (which is 40
descriptors, as this is a byte pointer). This seems kind of arbitrary.
In b43 we set it to (NR_OF_DESCRIPTORS - 1) * sizeof(descriptor).
But I don't think it really matters. It only limits the usable DMA
area before the first interrupt (or poll) occurs. After the final
B44_DMARX_PTR write in b44_rx(), the full descriptor range (well, minus one)
will be usable.
Summary: I don't see where the DMA engine code is broken (except for
the minor missing wmb(), which doesn't trigger this memory corruption, though)
I hope that helps to clear up stuff...
^ permalink raw reply
* Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown
From: Thomas Graf @ 2011-07-06 15:49 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, davem, Wei Yongjun, Sridhar Samudrala, linux-sctp
In-Reply-To: <4E1471DC.2090407@hp.com>
On Wed, Jul 06, 2011 at 10:31:56AM -0400, Vladislav Yasevich wrote:
> >>> + *
> >>> + * Allow the association to timeout if SHUTDOWN is
> >>> + * pending in case the receiver stays in zero window
> >>> + * mode forever.
> >>> */
> >>> if (!q->asoc->peer.rwnd &&
> >>> !list_empty(&tlist) &&
> >>> - (sack_ctsn+2 == q->asoc->next_tsn)) {
> >>> + (sack_ctsn+2 == q->asoc->next_tsn) &&
> >>> + !(q->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)) {
> >>
> >> Would a test for (q->asoc->state != SCTP_STATE_SHUTDOWN_PENDING) be clearer? We only
> >> care about the PENDING state here.
> >
> > I think SHUTDOWN_RECEIVED should also be included. We continue to transmit and
> > process SACKs after receiving a SHUTDOWN.
>
> I am not sure about SHUTDOWN_RECEIVED. If we received shutdown, then we are not in
> a 0 window situation. Additionally, the sender of the SHUTDOWN started the GUARD timer
> and will abort after it expires. So there is no special handling on our part.
Why can't we be in a 0 window situation? A well behaving sctp peer may not,
but we're on the Internet, everyone behaves at their worst :-)
Seriously, this would make for a simple dos. Establish a stream, don't ack any
data to make sure there is something on the retransmission queue of the peer.
Immediately shutdown the stream and ack any retransmission attempt with
a_rwnd=0 to keep the association around forever.
Starting the T5 SHUTDOWN GUARD timer is specified as MAY and not MUST so even in
a well behaving world we could not really rely on it.
Alternatively the peer could just be buggy as well.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-06 16:00 UTC (permalink / raw)
To: Michael Büsch
Cc: Neil Horman, Alexey Zaytsev, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <20110706173243.404d8599@maggie>
Le mercredi 06 juillet 2011 à 17:32 +0200, Michael Büsch a écrit :
> You guys are mixing up quite a bit of stuff here...
>
> The EOT bit has _nothing_ to do with the descriptor pointers.
> It simply marks the last descriptor in the (linear) descriptor
> page, so that it becomes an actual ring:
>
> DDDDDDDDDDDDDDDDDDDDDDDDDDDE
> | O
> | T
> ^--------------------------|
>
> It doesn't say anything about the read and write pointers
> to the ring.
>
> The B44_DMARX_PTR is the write-end pointer. It points one entry
> beyond the end of the write area. Then there's the software pointer
> where we keep track of the read position.
>
> -rx_cons DMARX_PTR-
> v v
> DDDDDDDDDDDDDDDDDDDDDDDDDDE
> ^ ^ O
> | | T
> Device might write from
> here to here.
>
> On an RX interrupt (or poll), we read the _actual_ device write
> pointer. (B44_DMARX_STAT & DMARX_STAT_CDMASK). If that is equal
> to our stored rx_cons, the device didn't write anything.
> So we read buffers until we hit the _actual_ device write pointer.
> So rx_cons is equal to (B44_DMARX_STAT & DMARX_STAT_CDMASK), except
> that it lags behind by one IRQ/poll.
> If we read are done, we set the DMARX_PTR write pointer to one desc
> beyond the buffer that we just ate. So the device is free to continue
> writing the ring _up to_ the position we left.
Not exactly :
If we read one skb at descriptor 0, we prepare a new buffer on slot 200,
and advance DMARX_PTR to 201*sizeof(descriptor).
>
> I don't know why b44 sets the DMARX_PTR to 200 initially (which is 40
> descriptors, as this is a byte pointer). This seems kind of arbitrary.
> In b43 we set it to (NR_OF_DESCRIPTORS - 1) * sizeof(descriptor).
> But I don't think it really matters. It only limits the usable DMA
> area before the first interrupt (or poll) occurs. After the final
> B44_DMARX_PTR write in b44_rx(), the full descriptor range (well, minus one)
> will be usable.
Yes, this is probably a small bug, we should fix it for correctness.
>
> Summary: I don't see where the DMA engine code is broken (except for
> the minor missing wmb(), which doesn't trigger this memory corruption, though)
>
> I hope that helps to clear up stuff...
Well, you describe (nicely, thanks !) your understanding of how work the
driver and chip.
Problem is we suspect a wrong statement or wrong hardware ;)
Another problem is Alexey doesnt answer anymore, and I dont have this
(old) hardware...
Other point : Do you know why b44_get_ringparam() doesnt set
ering->tx_max_pending and ering->tx_pending
The comment seems wrong :
/* XXX ethtool lacks a tx_max_pending, oops... */
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Michael Büsch @ 2011-07-06 16:12 UTC (permalink / raw)
To: Eric Dumazet
Cc: Neil Horman, Alexey Zaytsev, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309968019.2292.44.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wed, 06 Jul 2011 18:00:19 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Not exactly :
>
> If we read one skb at descriptor 0, we prepare a new buffer on slot 200,
> and advance DMARX_PTR to 201*sizeof(descriptor).
I don't think so. Why do you think this is the case?
We allocate a new descriptor buffer for the consumed buffer at exactly
the same place (which is "cons").
(Alternatively, we leave the buffer in place, and just copy the data to a new buffer).
And DMARX_PTR is updated to the last "cons", which is one beyond
the last buffer that we consumed (and pushed up the net stack).
(Note that "beyond" always means "beyond" in the sense of a DMA _ring_,
which honors the EOT bit. This is done by masking cons with RX_RING_SIZE-1,
which is thus assumed to be a power of two).
> > I don't know why b44 sets the DMARX_PTR to 200 initially (which is 40
> > descriptors, as this is a byte pointer). This seems kind of arbitrary.
> > In b43 we set it to (NR_OF_DESCRIPTORS - 1) * sizeof(descriptor).
> > But I don't think it really matters. It only limits the usable DMA
> > area before the first interrupt (or poll) occurs. After the final
> > B44_DMARX_PTR write in b44_rx(), the full descriptor range (well, minus one)
> > will be usable.
>
> Yes, this is probably a small bug, we should fix it for correctness.
I wouldn't call this a bug.
> > Summary: I don't see where the DMA engine code is broken (except for
> > the minor missing wmb(), which doesn't trigger this memory corruption, though)
> >
> > I hope that helps to clear up stuff...
>
> Well, you describe (nicely, thanks !) your understanding of how work the
> driver and chip.
>
> Problem is we suspect a wrong statement or wrong hardware ;)
>
> Another problem is Alexey doesnt answer anymore, and I dont have this
> (old) hardware...
I do really think that either
1) His device is broken. Chips break. I already saw several devices
with HND DMA engine that broke down after some time of use.
or
2) The bug is at another place, but not in the lowlevel DMA handling.
Could this possibly be some kind of context issue? threaded IRQs?
The net subsys was rather picky about context, last time I looked
into it. see the .._ni() style functions.
> Other point : Do you know why b44_get_ringparam() doesnt set
> ering->tx_max_pending and ering->tx_pending
>
> The comment seems wrong :
> /* XXX ethtool lacks a tx_max_pending, oops... */
Well, I _guess_ that ering->tx_max_pending was added later? (I didn't
even check if it's there _now_, though.)
^ permalink raw reply
* [PATCH RESEND v2 3/3] net/fec: add device tree probe support
From: Shawn Guo @ 2011-07-06 16:22 UTC (permalink / raw)
To: netdev
Cc: devicetree-discuss, linux-arm-kernel, patches, Shawn Guo,
Jason Liu, David S. Miller, Grant Likely
In-Reply-To: <1309878839-25743-4-git-send-email-shawn.guo@linaro.org>
It adds device tree probe support for fec driver.
Signed-off-by: Jason Liu <jason.hui@linaro.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
Resend with changes:
* use of_get_named_gpio for phy-reset-gpios
Documentation/devicetree/bindings/net/fsl-fec.txt | 24 +++++
drivers/net/fec.c | 98 +++++++++++++++++++-
2 files changed, 117 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/fsl-fec.txt
diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt
new file mode 100644
index 0000000..de43951
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
@@ -0,0 +1,24 @@
+* Freescale Fast Ethernet Controller (FEC)
+
+Required properties:
+- compatible : Should be "fsl,<soc>-fec"
+- reg : Address and length of the register set for the device
+- interrupts : Should contain fec interrupt
+- phy-mode : String, operation mode of the PHY interface.
+ Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii",
+ "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii".
+- phy-reset-gpios : Should specify the gpio for phy reset
+
+Optional properties:
+- local-mac-address : 6 bytes, mac address
+
+Example:
+
+fec@83fec000 {
+ compatible = "fsl,imx51-fec", "fsl,imx27-fec";
+ reg = <0x83fec000 0x4000>;
+ interrupts = <87>;
+ phy-mode = "mii";
+ phy-reset-gpios = <&gpio1 14 0>; /* GPIO2_14 */
+ local-mac-address = [00 04 9F 01 1B B9];
+};
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 7ae3f28..720aa63 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -44,6 +44,10 @@
#include <linux/platform_device.h>
#include <linux/phy.h>
#include <linux/fec.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
+#include <linux/of_net.h>
#include <asm/cacheflush.h>
@@ -78,6 +82,17 @@ static struct platform_device_id fec_devtype[] = {
{ }
};
+enum fec_type {
+ IMX27_FEC,
+ IMX28_FEC,
+};
+
+static const struct of_device_id fec_dt_ids[] = {
+ { .compatible = "fsl,imx27-fec", .data = &fec_devtype[IMX27_FEC], },
+ { .compatible = "fsl,imx28-fec", .data = &fec_devtype[IMX28_FEC], },
+ { /* sentinel */ }
+};
+
static unsigned char macaddr[ETH_ALEN];
module_param_array(macaddr, byte, NULL, 0);
MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
@@ -734,8 +749,22 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
*/
iap = macaddr;
+#ifdef CONFIG_OF
+ /*
+ * 2) from device tree data
+ */
+ if (!is_valid_ether_addr(iap)) {
+ struct device_node *np = fep->pdev->dev.of_node;
+ if (np) {
+ const char *mac = of_get_mac_address(np);
+ if (mac)
+ iap = (unsigned char *) mac;
+ }
+ }
+#endif
+
/*
- * 2) from flash or fuse (via platform data)
+ * 3) from flash or fuse (via platform data)
*/
if (!is_valid_ether_addr(iap)) {
#ifdef CONFIG_M5272
@@ -748,7 +777,7 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
}
/*
- * 3) FEC mac registers set by bootloader
+ * 4) FEC mac registers set by bootloader
*/
if (!is_valid_ether_addr(iap)) {
*((unsigned long *) &tmpaddr[0]) =
@@ -1358,6 +1387,52 @@ static int fec_enet_init(struct net_device *ndev)
return 0;
}
+#ifdef CONFIG_OF
+static int __devinit fec_get_phy_mode_dt(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+
+ if (np)
+ return of_get_phy_mode(np);
+
+ return -ENODEV;
+}
+
+static int __devinit fec_reset_phy(struct platform_device *pdev)
+{
+ int err, phy_reset;
+ struct device_node *np = pdev->dev.of_node;
+
+ if (!np)
+ return -ENODEV;
+
+ phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
+ err = gpio_request_one(phy_reset, GPIOF_OUT_INIT_LOW, "phy-reset");
+ if (err) {
+ pr_warn("FEC: failed to get gpio phy-reset: %d\n", err);
+ return err;
+ }
+
+ gpio_set_value(phy_reset, 1);
+
+ return 0;
+}
+#else /* CONFIG_OF */
+static inline int fec_get_phy_mode_dt(struct platform_device *pdev)
+{
+ return -ENODEV;
+}
+
+static inline int fec_reset_phy(struct platform_device *pdev)
+{
+ /*
+ * In case of platform probe, the reset has been done
+ * by machine code.
+ */
+ return 0;
+}
+#endif /* CONFIG_OF */
+
static int __devinit
fec_probe(struct platform_device *pdev)
{
@@ -1366,6 +1441,11 @@ fec_probe(struct platform_device *pdev)
struct net_device *ndev;
int i, irq, ret = 0;
struct resource *r;
+ const struct of_device_id *of_id;
+
+ of_id = of_match_device(fec_dt_ids, &pdev->dev);
+ if (of_id)
+ pdev->id_entry = of_id->data;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r)
@@ -1397,9 +1477,16 @@ fec_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ndev);
- pdata = pdev->dev.platform_data;
- if (pdata)
- fep->phy_interface = pdata->phy;
+ fep->phy_interface = fec_get_phy_mode_dt(pdev);
+ if (fep->phy_interface < 0) {
+ pdata = pdev->dev.platform_data;
+ if (pdata)
+ fep->phy_interface = pdata->phy;
+ else
+ fep->phy_interface = PHY_INTERFACE_MODE_MII;
+ }
+
+ fec_reset_phy(pdev);
/* This device has up to three irqs on some platforms */
for (i = 0; i < 3; i++) {
@@ -1534,6 +1621,7 @@ static struct platform_driver fec_driver = {
#ifdef CONFIG_PM
.pm = &fec_pm_ops,
#endif
+ .of_match_table = fec_dt_ids,
},
.id_table = fec_devtype,
.probe = fec_probe,
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown
From: Vladislav Yasevich @ 2011-07-06 16:23 UTC (permalink / raw)
To: netdev, davem, Wei Yongjun, Sridhar Samudrala, linux-sctp
In-Reply-To: <20110706154900.GB17652@canuck.infradead.org>
On 07/06/2011 11:49 AM, Thomas Graf wrote:
> On Wed, Jul 06, 2011 at 10:31:56AM -0400, Vladislav Yasevich wrote:
>>>>> + *
>>>>> + * Allow the association to timeout if SHUTDOWN is
>>>>> + * pending in case the receiver stays in zero window
>>>>> + * mode forever.
>>>>> */
>>>>> if (!q->asoc->peer.rwnd &&
>>>>> !list_empty(&tlist) &&
>>>>> - (sack_ctsn+2 == q->asoc->next_tsn)) {
>>>>> + (sack_ctsn+2 == q->asoc->next_tsn) &&
>>>>> + !(q->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)) {
>>>>
>>>> Would a test for (q->asoc->state != SCTP_STATE_SHUTDOWN_PENDING) be clearer? We only
>>>> care about the PENDING state here.
>>>
>>> I think SHUTDOWN_RECEIVED should also be included. We continue to transmit and
>>> process SACKs after receiving a SHUTDOWN.
>>
>> I am not sure about SHUTDOWN_RECEIVED. If we received shutdown, then we are not in
>> a 0 window situation. Additionally, the sender of the SHUTDOWN started the GUARD timer
>> and will abort after it expires. So there is no special handling on our part.
>
> Why can't we be in a 0 window situation? A well behaving sctp peer may not,
> but we're on the Internet, everyone behaves at their worst :-)
>
> Seriously, this would make for a simple dos. Establish a stream, don't ack any
> data to make sure there is something on the retransmission queue of the peer.
> Immediately shutdown the stream and ack any retransmission attempt with
> a_rwnd=0 to keep the association around forever.
>
> Starting the T5 SHUTDOWN GUARD timer is specified as MAY and not MUST so even in
> a well behaving world we could not really rely on it.
>
> Alternatively the peer could just be buggy as well.
>
You are right. Without a receiver patch, a linux receiver would stay in 0-window condition
while sending a SHUTDOWN with a_rwnd of 0.
How about instead of checking for "Not greater then or equals", we instead simply test for
"less then"?
-vlad
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-06 16:35 UTC (permalink / raw)
To: Michael Büsch
Cc: Neil Horman, Alexey Zaytsev, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <20110706181258.57b3c112@maggie>
Le mercredi 06 juillet 2011 à 18:12 +0200, Michael Büsch a écrit :
> On Wed, 06 Jul 2011 18:00:19 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Not exactly :
> >
> > If we read one skb at descriptor 0, we prepare a new buffer on slot 200,
> > and advance DMARX_PTR to 201*sizeof(descriptor).
>
> I don't think so. Why do you think this is the case?
> We allocate a new descriptor buffer for the consumed buffer at exactly
> the same place (which is "cons").
> (Alternatively, we leave the buffer in place, and just copy the data to a new buffer).
> And DMARX_PTR is updated to the last "cons", which is one beyond
> the last buffer that we consumed (and pushed up the net stack).
Not at all.
If it was true, b44_recycle_rx() would not even exist as is.
When we allocate a new buffer, we put it at rx_prod index, which is the
slot _after_ window, not the first slot.
First time we dequeue a packet from NIC, rx_prod is something like 200
Oh, it seems we do the following in b44_init_hw()
bp->rx_prod = bp->rx_pending;
But this seems completely wrong, if b44_init_rings() was not able to
allocate rx_pending buffers (b44_alloc_rx_skb() can return NULL)
^ permalink raw reply
* Re: 3.0.0rc6: ethtool not working without a cable
From: Brandeburg, Jesse @ 2011-07-06 16:52 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Arkadiusz Miskiewicz, netdev@vger.kernel.org, e1000-devel
In-Reply-To: <1309966010.2712.4.camel@bwh-desktop>
On Wed, 2011-07-06 at 08:26 -0700, Ben Hutchings wrote:
> On Wed, 2011-07-06 at 16:53 +0200, Arkadiusz Miskiewicz wrote:
> > On Wednesday 06 of July 2011, Ben Hutchings wrote:
> > > On Wed, 2011-07-06 at 13:38 +0200, Arkadiusz Miskiewicz wrote:
> > > > 3.0.0rc6, thinkpad t400 notebook.
> > > >
> > > > If there is no cable then ethtool reports no device. It wasn't that
> > > > before AFAIK.
> > > >
> > > > ethtool version 2.6.36
snip
> Then the only other explanation I can think of is that the driver has
> 'detached' the device due to some kind of error. The ethtool core does
> have a check for that.
could it be that aspm is enabled or that you've enabled runtime power
management?
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-06 16:56 UTC (permalink / raw)
To: Michael Büsch
Cc: Neil Horman, Alexey Zaytsev, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <20110706173243.404d8599@maggie>
Le mercredi 06 juillet 2011 à 17:32 +0200, Michael Büsch a écrit :
> You guys are mixing up quite a bit of stuff here...
Well
>
> The EOT bit has _nothing_ to do with the descriptor pointers.
> It simply marks the last descriptor in the (linear) descriptor
> page, so that it becomes an actual ring:
>
> DDDDDDDDDDDDDDDDDDDDDDDDDDDE
> | O
> | T
> ^--------------------------|
>
> It doesn't say anything about the read and write pointers
> to the ring.
>
> The B44_DMARX_PTR is the write-end pointer. It points one entry
> beyond the end of the write area. Then there's the software pointer
> where we keep track of the read position.
>
Thats not how b44_rx() works :
It writes on DMARX_PTR the last slot that driver _dequeued_ in its NAPI
run. Its not the end of the window that device is allowed to use.
bw32(bp, B44_DMARX_PTR, cons * sizeof(struct dma_desc));
The end of the 'allocated buffers' is in rx_prod. Problem is NIC have no
idea of where is the end of window. We never give rx_prod to NIC.
So NIC actually read old descriptors value. We need to clear them to
avoid memory corruption.
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 6c4ef96..ec9773b 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -725,6 +725,7 @@ static void b44_recycle_rx(struct b44 *bp, int src_idx, u32 dest_idx_unmasked)
DMA_BIDIRECTIONAL);
ctrl = src_desc->ctrl;
+ src_desc->ctrl = ctrl & cpu_to_le32(DESC_CTRL_EOT);
if (dest_idx == (B44_RX_RING_SIZE - 1))
ctrl |= cpu_to_le32(DESC_CTRL_EOT);
else
@@ -732,6 +733,7 @@ static void b44_recycle_rx(struct b44 *bp, int src_idx, u32 dest_idx_unmasked)
dest_desc->ctrl = ctrl;
dest_desc->addr = src_desc->addr;
+ src_desc->addr = 0;
src_map->skb = NULL;
@@ -1118,6 +1120,7 @@ static void b44_init_rings(struct b44 *bp)
if (b44_alloc_rx_skb(bp, -1, i) < 0)
break;
}
+ bp->rx_prod = i;
}
/*
@@ -1406,7 +1409,6 @@ static void b44_init_hw(struct b44 *bp, int reset_kind)
bw32(bp, B44_DMARX_ADDR, bp->rx_ring_dma + bp->dma_offset);
bw32(bp, B44_DMARX_PTR, bp->rx_pending);
- bp->rx_prod = bp->rx_pending;
bw32(bp, B44_MIB_CTRL, MIB_CTRL_CLR_ON_READ);
}
^ permalink raw reply related
* Re: 3.0.0rc6: ethtool not working without a cable
From: Arkadiusz Miskiewicz @ 2011-07-06 16:57 UTC (permalink / raw)
To: Brandeburg, Jesse; +Cc: Ben Hutchings, netdev@vger.kernel.org, e1000-devel
In-Reply-To: <1309971146.6217.0.camel@jbrandeb-mobl.amr.corp.intel.com>
On Wednesday 06 of July 2011, Brandeburg, Jesse wrote:
> On Wed, 2011-07-06 at 08:26 -0700, Ben Hutchings wrote:
> > On Wed, 2011-07-06 at 16:53 +0200, Arkadiusz Miskiewicz wrote:
> > > On Wednesday 06 of July 2011, Ben Hutchings wrote:
> > > > On Wed, 2011-07-06 at 13:38 +0200, Arkadiusz Miskiewicz wrote:
> > > > > 3.0.0rc6, thinkpad t400 notebook.
> > > > >
> > > > > If there is no cable then ethtool reports no device. It wasn't that
> > > > > before AFAIK.
> > > > >
> > > > > ethtool version 2.6.36
>
> snip
>
> > Then the only other explanation I can think of is that the driver has
> > 'detached' the device due to some kind of error. The ethtool core does
> > have a check for that.
>
> could it be that aspm is enabled
I have CONFIG_PCIEASPM=y
> or that you've enabled runtime power
> management?
In e1000e? no (unless it's default somehow).
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* [PATCH 00/10] dynamic_debug: various fixes
From: Jason Baron @ 2011-07-06 17:24 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
Hi,
Various dynamic debug fixes and cleanups, and a patch to add myself as
maintainer. Hopefully, nobody will object too loudly :)
Thanks,
-Jason
Joe Perches (4):
dynamic_debug: Add __dynamic_dev_dbg
dynamic_debug: Consolidate prefix output to single routine
dynamic_debug: Remove uses of KERN_CONT in dynamic_emit_prefix
dynamic_debug: Convert printks to pr_<level>
Jason Baron (6):
dynamic_debug: remove unused control variables
dynamic_debug: add myslef as maintainer
dynamic_debug: make netdev_dbg() call __netdev_printk()
dynamic_debug: make netif_dbg() call __netdev_printk()
dynamic_debug: consolidate repetitive struct _ddebug descriptor
definitions
dynamic_debug: remove num_enabled accounting
MAINTAINERS | 6 ++
drivers/base/core.c | 5 +-
include/linux/device.h | 5 +
include/linux/dynamic_debug.h | 58 ++++++++++-----
include/linux/netdevice.h | 12 ++--
lib/dynamic_debug.c | 165 ++++++++++++++++++++++++++++-------------
net/core/dev.c | 3 +-
7 files changed, 172 insertions(+), 82 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH 01/10] dynamic_debug: Add __dynamic_dev_dbg
From: Jason Baron @ 2011-07-06 17:24 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
In-Reply-To: <cover.1309967232.git.root@dhcp-100-18-164.bos.redhat.com>
From: Joe Perches <joe@perches.com>
Unlike dynamic_pr_debug, dynamic uses of dev_dbg can not
currently add task_pid/KBUILD_MODNAME/__func__/__LINE__
to selected debug output.
Add a new function similar to dynamic_pr_debug to
optionally emit these prefixes.
Cc: Aloisio Almeida <aloisio.almeida@openbossa.org>
Noticed-by: Aloisio Almeida <aloisio.almeida@openbossa.org>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@redhat.com>
---
drivers/base/core.c | 5 +++--
include/linux/device.h | 5 +++++
include/linux/dynamic_debug.h | 10 ++++++++--
lib/dynamic_debug.c | 38 ++++++++++++++++++++++++++++++++++++++
4 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index bc8729d..82c8654 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1764,8 +1764,8 @@ void device_shutdown(void)
#ifdef CONFIG_PRINTK
-static int __dev_printk(const char *level, const struct device *dev,
- struct va_format *vaf)
+int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf)
{
if (!dev)
return printk("%s(NULL device *): %pV", level, vaf);
@@ -1773,6 +1773,7 @@ static int __dev_printk(const char *level, const struct device *dev,
return printk("%s%s %s: %pV",
level, dev_driver_string(dev), dev_name(dev), vaf);
}
+EXPORT_SYMBOL(__dev_printk);
int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
diff --git a/include/linux/device.h b/include/linux/device.h
index 553fd37..5a9c8b5 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -786,6 +786,8 @@ extern const char *dev_driver_string(const struct device *dev);
#ifdef CONFIG_PRINTK
+extern int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf);
extern int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
__attribute__ ((format (printf, 3, 4)));
@@ -806,6 +808,9 @@ extern int _dev_info(const struct device *dev, const char *fmt, ...)
#else
+static inline int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf)
+ { return 0; }
static inline int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
__attribute__ ((format (printf, 3, 4)));
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index e747ecd..bdf1531 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -47,6 +47,13 @@ extern int ddebug_remove_module(const char *mod_name);
extern int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
__attribute__ ((format (printf, 2, 3)));
+struct device;
+
+extern int __dynamic_dev_dbg(struct _ddebug *descriptor,
+ const struct device *dev,
+ const char *fmt, ...)
+ __attribute__ ((format (printf, 3, 4)));
+
#define dynamic_pr_debug(fmt, ...) do { \
static struct _ddebug descriptor \
__used \
@@ -57,7 +64,6 @@ extern int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
__dynamic_pr_debug(&descriptor, pr_fmt(fmt), ##__VA_ARGS__); \
} while (0)
-
#define dynamic_dev_dbg(dev, fmt, ...) do { \
static struct _ddebug descriptor \
__used \
@@ -65,7 +71,7 @@ extern int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
{ KBUILD_MODNAME, __func__, __FILE__, fmt, __LINE__, \
_DPRINTK_FLAGS_DEFAULT }; \
if (unlikely(descriptor.enabled)) \
- dev_printk(KERN_DEBUG, dev, fmt, ##__VA_ARGS__); \
+ __dynamic_dev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__); \
} while (0)
#else
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 75ca78f..5c5f8f9 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -30,6 +30,7 @@
#include <linux/jump_label.h>
#include <linux/hardirq.h>
#include <linux/sched.h>
+#include <linux/device.h>
extern struct _ddebug __start___verbose[];
extern struct _ddebug __stop___verbose[];
@@ -456,6 +457,43 @@ int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
}
EXPORT_SYMBOL(__dynamic_pr_debug);
+int __dynamic_dev_dbg(struct _ddebug *descriptor,
+ const struct device *dev, const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+ int res;
+
+ BUG_ON(!descriptor);
+ BUG_ON(!fmt);
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
+
+ res = printk(KERN_DEBUG);
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_TID) {
+ if (in_interrupt())
+ res += printk(KERN_CONT "<intr> ");
+ else
+ res += printk(KERN_CONT "[%d] ", task_pid_vnr(current));
+ }
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_MODNAME)
+ res += printk(KERN_CONT "%s:", descriptor->modname);
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_FUNCNAME)
+ res += printk(KERN_CONT "%s:", descriptor->function);
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_LINENO)
+ res += printk(KERN_CONT "%d ", descriptor->lineno);
+
+ res += __dev_printk("", dev, &vaf);
+
+ va_end(args);
+
+ return res;
+}
+EXPORT_SYMBOL(__dynamic_dev_dbg);
+
static __initdata char ddebug_setup_string[1024];
static __init int ddebug_setup_query(char *str)
{
--
1.7.5.4
^ permalink raw reply related
* [PATCH 07/10] dynamic_debug: make netdev_dbg() call __netdev_printk()
From: Jason Baron @ 2011-07-06 17:25 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
In-Reply-To: <cover.1309967232.git.root@dhcp-100-18-164.bos.redhat.com>
From: Jason Baron <jbaron@redhat.com>
Previously, if dynamic debug was enabled netdev_dbg() was using
dynamic_dev_dbg() to print out the underlying msg. Fix this by making
sure netdev_dbg() uses __netdev_printk().
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Jason Baron <jbaron@redhat.com>
---
include/linux/dynamic_debug.h | 17 +++++++++++++++++
include/linux/netdevice.h | 6 ++++--
lib/dynamic_debug.c | 25 +++++++++++++++++++++++++
net/core/dev.c | 3 ++-
4 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 843cb9e..feaac1e 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -47,6 +47,13 @@ extern int __dynamic_dev_dbg(struct _ddebug *descriptor,
const char *fmt, ...)
__attribute__ ((format (printf, 3, 4)));
+struct net_device;
+
+extern int __dynamic_netdev_dbg(struct _ddebug *descriptor,
+ const struct net_device *dev,
+ const char *fmt, ...)
+ __attribute__ ((format (printf, 3, 4)));
+
#define dynamic_pr_debug(fmt, ...) do { \
static struct _ddebug descriptor \
__used \
@@ -67,6 +74,16 @@ extern int __dynamic_dev_dbg(struct _ddebug *descriptor,
__dynamic_dev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__); \
} while (0)
+#define dynamic_netdev_dbg(dev, fmt, ...) do { \
+ static struct _ddebug descriptor \
+ __used \
+ __attribute__((section("__verbose"), aligned(8))) = \
+ { KBUILD_MODNAME, __func__, __FILE__, fmt, __LINE__, \
+ _DPRINTK_FLAGS_DEFAULT }; \
+ if (unlikely(descriptor.enabled)) \
+ __dynamic_netdev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__);\
+ } while (0)
+
#else
static inline int ddebug_remove_module(const char *mod)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 54b8b4d..9b132ef 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2635,6 +2635,9 @@ static inline const char *netdev_name(const struct net_device *dev)
return dev->name;
}
+extern int __netdev_printk(const char *level, const struct net_device *dev,
+ struct va_format *vaf);
+
extern int netdev_printk(const char *level, const struct net_device *dev,
const char *format, ...)
__attribute__ ((format (printf, 3, 4)));
@@ -2662,8 +2665,7 @@ extern int netdev_info(const struct net_device *dev, const char *format, ...)
#elif defined(CONFIG_DYNAMIC_DEBUG)
#define netdev_dbg(__dev, format, args...) \
do { \
- dynamic_dev_dbg((__dev)->dev.parent, "%s: " format, \
- netdev_name(__dev), ##args); \
+ dynamic_netdev_dbg(__dev, format, ##args); \
} while (0)
#else
#define netdev_dbg(__dev, format, args...) \
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index e627874..db66a48 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -33,6 +33,7 @@
#include <linux/hardirq.h>
#include <linux/sched.h>
#include <linux/device.h>
+#include <linux/netdevice.h>
extern struct _ddebug __start___verbose[];
extern struct _ddebug __stop___verbose[];
@@ -503,6 +504,30 @@ int __dynamic_dev_dbg(struct _ddebug *descriptor,
}
EXPORT_SYMBOL(__dynamic_dev_dbg);
+int __dynamic_netdev_dbg(struct _ddebug *descriptor,
+ const struct net_device *dev, const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+ int res;
+
+ BUG_ON(!descriptor);
+ BUG_ON(!fmt);
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
+
+ res = dynamic_emit_prefix(descriptor);
+ res += __netdev_printk("", dev, &vaf);
+
+ va_end(args);
+
+ return res;
+}
+EXPORT_SYMBOL(__dynamic_netdev_dbg);
+
static __initdata char ddebug_setup_string[1024];
static __init int ddebug_setup_query(char *str)
{
diff --git a/net/core/dev.c b/net/core/dev.c
index 9c58c1e..d6d48b2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6288,7 +6288,7 @@ const char *netdev_drivername(const struct net_device *dev)
return empty;
}
-static int __netdev_printk(const char *level, const struct net_device *dev,
+int __netdev_printk(const char *level, const struct net_device *dev,
struct va_format *vaf)
{
int r;
@@ -6303,6 +6303,7 @@ static int __netdev_printk(const char *level, const struct net_device *dev,
return r;
}
+EXPORT_SYMBOL(__netdev_printk);
int netdev_printk(const char *level, const struct net_device *dev,
const char *format, ...)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 08/10] dynamic_debug: make netif_dbg() call __netdev_printk()
From: Jason Baron @ 2011-07-06 17:25 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
In-Reply-To: <cover.1309967232.git.root@dhcp-100-18-164.bos.redhat.com>
From: Jason Baron <jbaron@redhat.com>
Previously, netif_dbg() was using dynamic_dev_dbg() to perform
the underlying printk. Fix it to use __netdev_printk(), instead.
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Jason Baron <jbaron@redhat.com>
---
include/linux/dynamic_debug.h | 12 ++++++++++++
include/linux/netdevice.h | 6 ++----
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index feaac1e..7048e64 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -84,6 +84,18 @@ extern int __dynamic_netdev_dbg(struct _ddebug *descriptor,
__dynamic_netdev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__);\
} while (0)
+#define dynamic_netif_dbg(dev, cond, fmt, ...) do { \
+ static struct _ddebug descriptor \
+ __used \
+ __attribute__((section("__verbose"), aligned(8))) = \
+ { KBUILD_MODNAME, __func__, __FILE__, fmt, __LINE__, \
+ _DPRINTK_FLAGS_DEFAULT }; \
+ if (unlikely(descriptor.enabled)) { \
+ if (cond) \
+ __dynamic_netdev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__);\
+ } \
+ } while (0)
+
#else
static inline int ddebug_remove_module(const char *mod)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9b132ef..99c358f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2731,10 +2731,8 @@ do { \
#elif defined(CONFIG_DYNAMIC_DEBUG)
#define netif_dbg(priv, type, netdev, format, args...) \
do { \
- if (netif_msg_##type(priv)) \
- dynamic_dev_dbg((netdev)->dev.parent, \
- "%s: " format, \
- netdev_name(netdev), ##args); \
+ dynamic_netif_dbg(netdev, (netif_msg_##type(priv)), \
+ format, ##args); \
} while (0)
#else
#define netif_dbg(priv, type, dev, format, args...) \
--
1.7.5.4
^ 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