* Re: skb->frag_list != NULL in start_xmit for device without NETIF_F_FRAGLIST
From: Ian Campbell @ 2011-03-02 13:14 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev@vger.kernel.org, Paul Durrant
In-Reply-To: <1299071546.17907.1755.camel@zakaz.uk.xensource.com>
On Wed, 2011-03-02 at 13:12 +0000, Ian Campbell wrote:
>
> > I believe that not much has changed in this regard between 2.6.32
> and net-next.
>
> It turns out I cannot reproduce with either 2.6.32 (pvops xen.git) or
> a more recent ((26.38-rc) kernel. The kernel where we see this is the
> XCP kernel which is a 2.6.32 based thing derived from SLES11SP1 + XCP
> specific updates.
Paul reminded me that his XCP system where we see this is running
openvswitch not bridging (all my own tests were with bridging), is this
something which could be caused by vswitch at all? I don't see any
interesting ->frag_list usage in openvswitch.git.
Anyway I'm going to see if I can repro with vswitch.
Ian.
^ permalink raw reply
* Re: [PATCH 0/7] Final BKL removal, take 2
From: Greg KH @ 2011-03-02 14:04 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Arnd Bergmann, linux-kernel, Andi Kleen, Andrew Hendry,
Arnaldo Carvalho de Melo, David Miller, Eric Dumazet,
Evgeniy Dushistov, linux-fsdevel, linux-x25, Max Vozeler,
Mikulas Patocka, netdev, Nick Bowler, Nick Piggin,
Palash Bandyopadhyay, Takahiro Hirofuchi
In-Reply-To: <4D6E2ABF.5040500@redhat.com>
On Wed, Mar 02, 2011 at 08:32:15AM -0300, Mauro Carvalho Chehab wrote:
> Em 02-03-2011 01:59, Greg KH escreveu:
> > On Wed, Mar 02, 2011 at 12:13:04AM +0100, Arnd Bergmann wrote:
> >> This is the set of patches that remain from
> >> my previous submission one month ago. I've
> >> dropped the ones that have either gone into
> >> linux-next or got a sufficient number of
> >> Acked-by:s so I put them into my own tree.
> >>
> >> I've updated the usbip, hpfs, ufs and appletalk
> >> patches according to the feedback I got.
> >>
> >> If possible, I'd like the three networking patches
> >> to go through the net-next tree, and the two
> >> staging patches through the staging tree. I'll
> >> add the other ones to my own series if I hear
> >> no objections.
> >
> > I'll queue up the staging patches in the staging-next tree in a day or
> > so, thanks for digging them up.
>
> Greg,
>
> It is probably better to queue the staging/cx25821 patch via my tree, as this is one
> of those staging files that it is handled via media tree. So, if it is ok
> for you both, I'll get patch 2/7.
Yes, you are right, please take it through your tree.
thanks,
greg k-h
^ permalink raw reply
* Re: [Bugme-new] [Bug 30092] New: smsc911x.c drops long packets with VLAN tags
From: Göran Weinholt @ 2011-03-02 14:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon, Steve Glendinning
In-Reply-To: <20110301161547.13480e90.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Mon, 28 Feb 2011 15:57:14 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=30092
>>
> Thanks. Become famous, get more girls: send us a patch as per
> Documentation/SubmittingPatches :)
There's a register called VLAN1 that wasn't being configured. Setting it
to 0x8100 fixes the problem I reported. There's also a VLAN2 register,
possibly meant for stacked VLANs, but the description in the datasheet
doesn't make sense to me, and I can't test stacked VLANs, so I'm not
going to change it.
Subject: [PATCH] net/smsc911x.c: Set the VLAN1 register to fix VLAN MTU problem
From: Göran Weinholt <weinholt@csbnet.se>
The smsc911x driver would drop frames longer than 1518 bytes, which is a
problem for networks with VLAN tagging. The VLAN1 tag register is used
to increase the legal frame size to 1522 when a VLAN tag is identified.
Signed-off-by: Göran Weinholt <weinholt@csbnet.se>
---
diff -uprN linux-2.6.36.4-vanilla/drivers/net/smsc911x.c linux-2.6.36.4/drivers/net/smsc911x.c
--- linux-2.6.36.4-vanilla/drivers/net/smsc911x.c 2011-02-18 00:14:38.000000000 +0100
+++ linux-2.6.36.4/drivers/net/smsc911x.c 2011-03-02 14:29:11.884382251 +0100
@@ -1178,6 +1178,11 @@ static int smsc911x_open(struct net_devi
smsc911x_reg_write(pdata, HW_CFG, 0x00050000);
smsc911x_reg_write(pdata, AFC_CFG, 0x006E3740);
+ /* Increase the legal frame size of VLAN tagged frames to 1522 bytes */
+ spin_lock_irq(&pdata->mac_lock);
+ smsc911x_mac_write(pdata, VLAN1, ETH_P_8021Q);
+ spin_unlock_irq(&pdata->mac_lock);
+
/* Make sure EEPROM has finished loading before setting GPIO_CFG */
timeout = 50;
while ((smsc911x_reg_read(pdata, E2P_CMD) & E2P_CMD_EPC_BUSY_) &&
--
Göran Weinholt
Network Administrator
Chalmers Studentbostäder (AS48514)
^ permalink raw reply
* [PATCH] xfrm: fix xfrm by MARK logic in mangle table, POSTROUTING chain
From: Peter Kosyh @ 2011-03-02 14:24 UTC (permalink / raw)
To: netdev
From: Peter Kosyh <p.kosyh@gmail.com>
While using xfrm by MARK feature in >= 2.6.35 kernels, i found some
strange behaviour in MARK and xfrm logic.
After doing MARK target in POSTROUTING chain in mangle table, new mark
is not used in policy lookup logic.
That is because that mark logic is a part of routing logic, and
rerouting is done only in LOCALOUT hook. Here is the code from
/net/ipv4/netfilter/iptable_mangle.c:
/* The work comes in here from netfilter.c. */
static unsigned int
iptable_mangle_hook(unsigned int hook,
struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
if (hook == NF_INET_LOCAL_OUT)
return ipt_mangle_out(skb, out);
if (hook == NF_INET_POST_ROUTING)
return ipt_do_table(skb, hook, in, out,
dev_net(out)->ipv4.iptable_mangle);
...
Looking NF_INET_LOCAL_OUT case, in ipt_mangle_out there is a call to
ip_route_me_harder, that will call xfrm_decode_session and new mark
will be applied to xfrm flow.
But in NF_INET_POST_ROUTING there is nothing. So we can not use xfrm
by MARK logic from POSTROUTING chain at all.
It's like due the fact, that in postrouting we are not doing
rerouting, BUT in NAT case (in POSTROUTING chain), there is call to
ip_xfrm_me_harder(skb) in nf_nat_out, so, i suppose it is a bug in
iptable_mangle.c.
Here it is my patch that works for me. I ask anyone to help me, if it
is wrong, and i have no ideas how to fix ipv6 layer.
Signed-off-by: Peter Kosyh <p.kosyh@gmail.com>
---
diff -Nur linux-2.6.35.7/net/ipv4/netfilter/iptable_mangle.c
linux-2.6.35.7-mark/net/ipv4/netfilter/iptable_mangle.c
--- linux-2.6.35.7/net/ipv4/netfilter/iptable_mangle.c 2010-09-29
05:09:08.000000000 +0400
+++ linux-2.6.35.7-mark/net/ipv4/netfilter/iptable_mangle.c 2011-03-02
15:54:14.000000000 +0300
@@ -84,9 +84,22 @@
{
if (hook == NF_INET_LOCAL_OUT)
return ipt_mangle_out(skb, out);
- if (hook == NF_INET_POST_ROUTING)
+ if (hook == NF_INET_POST_ROUTING) {
+#ifdef CONFIG_XFRM
+ int ret;
+ u_int32_t mark = skb->mark;
+ ret = ipt_do_table(skb, hook, in, out,
+ dev_net(out)->ipv4.iptable_mangle);
+ if (skb->mark != mark && ret != NF_DROP && ret != NF_STOLEN) {
+ if (ip_xfrm_me_harder(skb))
+ ret = NF_DROP;
+ }
+ return ret;
+#else
return ipt_do_table(skb, hook, in, out,
dev_net(out)->ipv4.iptable_mangle);
+#endif
+ }
/* PREROUTING/INPUT/FORWARD: */
return ipt_do_table(skb, hook, in, out,
dev_net(in)->ipv4.iptable_mangle);
^ permalink raw reply
* Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0
From: Changli Gao @ 2011-03-02 14:37 UTC (permalink / raw)
To: Patrick McHardy
Cc: Oleg A. Arkhangelsky, netfilter-devel, netdev, Paul E McKenney
In-Reply-To: <4D6E2BEB.50805@trash.net>
On Wed, Mar 2, 2011 at 7:37 PM, Patrick McHardy <kaber@trash.net> wrote:
> Am 23.02.2011 18:07, schrieb "Oleg A. Arkhangelsky":
>> Hello,
>>
>> Got this panic yesterday:
>> http://www.progtech.ru/~oleg/crash.txt
>>
>> The offending instruction is:
>> cmpb 54(%edx), %cl # <variable>.tuple.dst.protonum,
>>
>> and here is the assembler code of net/ipv4/netfilter/nf_nat_core.c:
>> http://www.progtech.ru/~oleg/nf_nat_core.s
>>
>> Quick investigation lead me to conclusion that the problem is in
>> return of same_src function:
>>
>> return (t->dst.protonum == tuple->dst.protonum &&
>> t->src.u3.ip == tuple->src.u3.ip &&
>> t->src.u.all == tuple->src.u.all);
>>
>> So either t or tuple pointer is bad, but I don't understand how
>> this can be.
>
t should be NULL here, as offsetof(struct nf_conn, dst.protonum) == 0x36.
We should free the nf_ct_extend with call_rcu(), since nat ext is
referenced in the rcu read context.
717 void nf_conntrack_free(struct nf_conn *ct)
718 {
719 struct net *net = nf_ct_net(ct);
720
721 nf_ct_ext_destroy(ct);
722 atomic_dec(&net->ct.count);
723 nf_ct_ext_free(ct);
if (ct->ext)
call_rcu(&ct->ext->rcu, __nf_ct_ext_free_rcu);
724 kmem_cache_free(net->ct.nf_conntrack_cachep, ct);
725 }
726 EXPORT_SYMBOL_GPL(nf_conntrack_free);
--
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-02 15:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Fabio Checconi, Luigi Rizzo, netdev
In-Reply-To: <20110228171738.2cc8c9a0@nehalam>
Le lundi 28 février 2011 à 17:17 -0800, Stephen Hemminger a écrit :
> --- a/include/linux/pkt_sched.h 2011-02-28 13:28:57.763177314 -0800
> +++ b/include/linux/pkt_sched.h 2011-02-28 13:29:10.466792117 -0800
> @@ -588,4 +588,18 @@ struct tc_sfb_xstats {
>
> #define SFB_MAX_PROB 0xFFFF
>
> +/* QFQ */
> +enum {
+ TCA_QFQ_UNSPEC,
> + TCA_QFQ_WEIGHT,
> + TCA_QFQ_LMAX,
> + __TCA_QFQ_MAX
> +};
> +
> +#define TCA_QFQ_MAX (__TCA_QFQ_MAX - 1)
> +
With TCA_QFQ_UNSPEC bit (and mirror the change in iproute2), it seems to
work better.
Oh wait, I had a crash in qfq_reset_qdisc() when re-running my setup
script.
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-02 15:53 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Fabio Checconi, Luigi Rizzo, netdev
In-Reply-To: <20110228171738.2cc8c9a0@nehalam>
Le lundi 28 février 2011 à 17:17 -0800, Stephen Hemminger a écrit :
> This is an implementation of the Quick Fair Queue scheduler developed
> by Fabio Checconi. The same algorithm is already implemented in ipfw
> in FreeBSD. Fabio had an earlier version developed on Linux, I just
> cleaned it up and tested it. All bugs are mine.
Here is my crash analysis :
> +static void qfq_reset_qdisc(struct Qdisc *sch)
> +{
> + struct qfq_sched *q = qdisc_priv(sch);
> + struct qfq_group *grp;
> + struct qfq_class *cl, **pp;
> + struct hlist_node *n;
> + unsigned int i, j;
> +
> + for (i = 0; i <= QFQ_MAX_INDEX; i++) {
> + grp = &q->groups[i];
> + for (j = 0; j < QFQ_MAX_SLOTS; j++) {
> + for (pp = &grp->slots[j]; *pp; pp = &(*pp)->next) {
> + cl = *pp;
> + if (cl->qdisc->q.qlen)
> + qfq_deactivate_class(q, cl, pp);
Here, if we deactivated last class in chain, *pp is NULL, but
pp = &(*pp)->next put 0x50 (on 64bit arches) in pp, so we crash ...
> + }
> + }
> + }
> +
> + for (i = 0; i < q->clhash.hashsize; i++) {
> + hlist_for_each_entry(cl, n, &q->clhash.hash[i], common.hnode)
> + qdisc_reset(cl->qdisc);
> + }
> + sch->q.qlen = 0;
> +}
> +
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Kees Cook @ 2011-03-02 16:01 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, mjt, arnd, mirqus, netdev, Ben Hutchings,
David Miller, kuznet, pekkas, jmorris, yoshfuji, kaber,
eric.dumazet, therbert, xiaosuo, jesse, eugene, dan.j.rosenberg,
akpm
In-Reply-To: <20110301213313.GA6507@albatros>
On Wed, Mar 02, 2011 at 12:33:13AM +0300, Vasiliy Kulikov wrote:
> This patch restricts an ability of autoloading modules to netdev modules
> with explicit aliases. This fixes CVE-2011-1019.
> ...
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Looks good; thanks for sorting this out.
Acked-by: Kees Cook <kees.cook@canonical.com>
-Kees
--
Kees Cook
Ubuntu Security Team
^ permalink raw reply
* Re: [Lxc-users] Bad checksums and lost packets with macvlan on dummy
From: Daniel Lezcano @ 2011-03-02 16:03 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, Andrian Nord, lxc-users, Linux Netdev List
In-Reply-To: <4D6E23F3.4010402@trash.net>
On 03/02/2011 12:03 PM, Patrick McHardy wrote:
> Am 01.03.2011 21:04, schrieb Daniel Lezcano:
>> On 03/01/2011 05:51 PM, Patrick McHardy wrote:
>>>> Patrick, do you have any suggestions to fix this ?
>>> Since the frames are only looped back locally, I suppose the easiest
>>> fix would be to mark them with CHECKSUM_UNNECESSARY. Alternatively
>>> we need to complete the checksum manually, similar to what
>>> dev_hard_start_xmit() does.
>> That sounds very simple to fix, maybe too much simple :)
>>
>> I did the following change:
>>
>> --- linux-next.orig/drivers/net/macvlan.c
>> +++ linux-next/drivers/net/macvlan.c
>> @@ -222,6 +222,7 @@ static int macvlan_queue_xmit(struct sk_
>>
>> if (vlan->mode == MACVLAN_MODE_BRIDGE) {
>> const struct ethhdr *eth = (void *)skb->data;
>> + skb->ip_summed = CHECKSUM_UNNECESSARY;
>>
>> /* send to other bridge ports directly */
>> if (is_multicast_ether_addr(eth->h_dest)) {
>>
>>
>> and that fixed the problem. Do you think it is acceptable ?
> The only problem I see is if the packets are bridged to a
> different networking device (or redirected using the mirred
> action), in this case the checksum will not be completed.
> This would be a very strange setup though and probably wouldn't
> be using dummy as lower device, so I'm not sure we have to
> worry about this case.
I am not sure to get it, do you say the patch is correct ?
If my understanding is correct, the packet will be flagged
CHECKSUM_UNNECESSARY only for the macvlan devices, right ?
By the way, this problem occurs for any lower device with offloading
capabilities with a macvlan port in bridge mode.
Thanks
-- Daniel
<javascript:void(0);>
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Stephen Hemminger @ 2011-03-02 16:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Fabio Checconi, David Miller, Luigi Rizzo, netdev
In-Reply-To: <1299064667.2920.4.camel@edumazet-laptop>
On Wed, 02 Mar 2011 12:17:47 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 02 mars 2011 à 03:06 +0100, Fabio Checconi a écrit :
> > Hi,
> >
> > > From: Stephen Hemminger <shemminger@vyatta.com>
> > > Date: Mon, Feb 28, 2011 05:17:38PM -0800
> > >
> > > This is an implementation of the Quick Fair Queue scheduler developed
> > > by Fabio Checconi. The same algorithm is already implemented in ipfw
> > > in FreeBSD. Fabio had an earlier version developed on Linux, I just
> > > cleaned it up and tested it. All bugs are mine.
> > >
> >
> > thanks for posting, I'm pretty sure that bugs are more likely to be
> > ours than yours :)
> >
> > During the development of the algorithm we used a simple traffic
> > simulator to verify (informally) the timestamping and the guarantees
> > provided. I've tested this version of the code with the simulator and
> > so far it worked fine, so I think that timestamping and guarantees should
> > be OK.
> >
> > Please let us know if we can be of any help,
> > fabio
>
> Hmm, I tried to setup QFQ (using iproute2patch
> http://patchwork.ozlabs.org/patch/77902/ ) but failed
>
> Do you have a link to a script/sample ?
>
> Thanks
I put the iproute2 code into the repository in the experimental branch.
--
^ permalink raw reply
* Re: [patch net-next-2.6] bonding: remove skb_share_check in handle_frame
From: Changli Gao @ 2011-03-02 16:13 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, netdev, davem, fubar, eric.dumazet, andy, Herbert Xu
In-Reply-To: <4D6D52F1.6020407@gmail.com>
On Wed, Mar 2, 2011 at 4:11 AM, Nicolas de Pesloüan
<nicolas.2p.debian@gmail.com> wrote:
> Le 01/03/2011 16:12, Changli Gao a écrit :
>>
>> On Tue, Mar 1, 2011 at 5:29 PM, Jiri Pirko<jpirko@redhat.com> wrote:
>>>
>>> Unapplicable, sorry (wrong branch :(). Here's corrected patch:
>>>
>>> Subject: [PATCH net-next-2.6 v2] bonding: remove skb_share_check in
>>> handle_frame
>>>
>>> No need to do share check here.
>>>
>>
>> I don't think so. Although you avoid netif_rx(), you can't avoid
>> ptype_all handlers. In fact, all the RX handlers should has this
>> check(), if they may modify the skb.
>
> Can you please develop your explanation?
>
> In current __netif_receive_skb() (after the recent patch from Jiri), we
> deliver the skb to ptype_all handlers inside a loop, while possibly changing
> skb->dev inside this loop.
>
> Then, at the end of __netif_receive_skb(), we loop on ptype_base, without
> changing anything in skb.
>
> Should we consider ptype_*->func() to be called in a pure sequential way?
> Should we consider that when a ptype_*->func() returns, nothing from this
> handler will use the skb in anyway later, in a parallel way?
>
> Or should we, instead, consider that special precautions must be taken,
> because protocol handlers may run in parallel for the same skb? Which kind
> of precautions?
>
If the packets gotten by __netif_receive_skb() are unshared, the skb
gotten by bond should be unshared, as we call prev_pt before calling
bond. I don't see there is any relationship with the previous patch
from Jiri. The bridge is in the same condition with bond here, and it
checks if the skb is shared or not. Does it imply that dev->rx_handler
may see shared skbs?
BTW: bond may change skb and packet data. But before change the packet
data, it doesn't check if the packet data is shared or not.
1519 if (bond_dev->priv_flags & IFF_MASTER_ALB &&
1520 bond_dev->priv_flags & IFF_BRIDGE_PORT &&
1521 skb->pkt_type == PACKET_HOST) {
1522 u16 *dest = (u16 *) eth_hdr(skb)->h_dest;
skb_cow_head() should be added, otherwise the previous ptype handler
may get the unexpected dset MAC address.
1523
1524 memcpy(dest, bond_dev->dev_addr, ETH_ALEN);
1525 }
Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH] rds: prevent BUG_ON triggering on congestion map updates
From: Neil Horman @ 2011-03-02 16:28 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, David S. Miller, rds-devel
Recently had this bug halt reported to me:
kernel BUG at net/rds/send.c:329!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: rds sunrpc ipv6 dm_mirror dm_region_hash dm_log ibmveth sg
ext4 jbd2 mbcache sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt
dm_mod [last unloaded: scsi_wait_scan]
NIP: d000000003ca68f4 LR: d000000003ca67fc CTR: d000000003ca8770
REGS: c000000175cab980 TRAP: 0700 Not tainted (2.6.32-118.el6.ppc64)
MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 44000022 XER: 00000000
TASK = c00000017586ec90[1896] 'krdsd' THREAD: c000000175ca8000 CPU: 0
GPR00: 0000000000000150 c000000175cabc00 d000000003cb7340 0000000000002030
GPR04: ffffffffffffffff 0000000000000030 0000000000000000 0000000000000030
GPR08: 0000000000000001 0000000000000001 c0000001756b1e30 0000000000010000
GPR12: d000000003caac90 c000000000fa2500 c0000001742b2858 c0000001742b2a00
GPR16: c0000001742b2a08 c0000001742b2820 0000000000000001 0000000000000001
GPR20: 0000000000000040 c0000001742b2814 c000000175cabc70 0800000000000000
GPR24: 0000000000000004 0200000000000000 0000000000000000 c0000001742b2860
GPR28: 0000000000000000 c0000001756b1c80 d000000003cb68e8 c0000001742b27b8
NIP [d000000003ca68f4] .rds_send_xmit+0x4c4/0x8a0 [rds]
LR [d000000003ca67fc] .rds_send_xmit+0x3cc/0x8a0 [rds]
Call Trace:
[c000000175cabc00] [d000000003ca67fc] .rds_send_xmit+0x3cc/0x8a0 [rds]
(unreliable)
[c000000175cabd30] [d000000003ca7e64] .rds_send_worker+0x54/0x100 [rds]
[c000000175cabdb0] [c0000000000b475c] .worker_thread+0x1dc/0x3c0
[c000000175cabed0] [c0000000000baa9c] .kthread+0xbc/0xd0
[c000000175cabf90] [c000000000032114] .kernel_thread+0x54/0x70
Instruction dump:
4bfffd50 60000000 60000000 39080001 935f004c f91f0040 41820024 813d017c
7d094a78 7d290074 7929d182 394a0020 <0b090000> 40e2ff68 4bffffa4 39200000
Kernel panic - not syncing: Fatal exception
Call Trace:
[c000000175cab560] [c000000000012e04] .show_stack+0x74/0x1c0 (unreliable)
[c000000175cab610] [c0000000005a365c] .panic+0x80/0x1b4
[c000000175cab6a0] [c00000000002fbcc] .die+0x21c/0x2a0
[c000000175cab750] [c000000000030000] ._exception+0x110/0x220
[c000000175cab910] [c000000000004b9c] program_check_common+0x11c/0x180
--- Exception: 700 at .rds_send_xmit+0x4c4/0x8a0 [rds]
LR = .rds_send_xmit+0x3cc/0x8a0 [rds]
[c000000175cabd30] [d000000003ca7e64] .rds_send_worker+0x54/0x100 [rds]
[c000000175cabdb0] [c0000000000b475c] .worker_thread+0x1dc/0x3c0
[c000000175cabed0] [c0000000000baa9c] .kthread+0xbc/0xd0
[c000000175cabf90] [c000000000032114] .kernel_thread+0x54/0x70
Rebooting in 180 seconds..
Tracked it down to a flaw in the xmit methods for the loop and ib transports.
Those two transports, when called with an rds message that has the
RDS_FLAG_CONG_BITMAP set, execute a rds_cong_map_updated call and return. Since
the xmit method requires that the number of bytes sent be returned, and a
congestion map update doesn't really send any data, it just returns the sizeof
an rds_header plus the defined size of the congestion map. This is problematic
because the caller of these methods (rds_send_xmit), validates that we didn't
send more data than was available in the passed rds_message. If the return
value from ->xmit() is larger than the remaining data in the message, we bug
halt, which is exactly what we get above. We could add a check to skip the bug
on check if the RDS_FLAG_CONG_BITMAP flag is set, but I think the check is
otherwise valid, so I've fixed it with this patch, which limits the return value
in the effected transports to not be more than the remainig space in the
rds_message.
Tested successfully by myself to solve the above bug halt.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Petr Matousek <pmatouse@redhat.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: rds-devel@oss.oracle.com
---
net/rds/ib_send.c | 5 ++++-
net/rds/loop.c | 11 ++++++++---
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c
index 71f373c..c47a511 100644
--- a/net/rds/ib_send.c
+++ b/net/rds/ib_send.c
@@ -551,7 +551,10 @@ int rds_ib_xmit(struct rds_connection *conn, struct rds_message *rm,
if (conn->c_loopback
&& rm->m_inc.i_hdr.h_flags & RDS_FLAG_CONG_BITMAP) {
rds_cong_map_updated(conn->c_fcong, ~(u64) 0);
- return sizeof(struct rds_header) + RDS_CONG_MAP_BYTES;
+ scat = &rm->data.op_sg[sg];
+ ret = sizeof(struct rds_header) + RDS_CONG_MAP_BYTES;
+ ret = min_t(int, ret, scat->length - conn->c_xmit_data_off);
+ return ret;
}
/* FIXME we may overallocate here */
diff --git a/net/rds/loop.c b/net/rds/loop.c
index aeec1d4..bca6761 100644
--- a/net/rds/loop.c
+++ b/net/rds/loop.c
@@ -61,10 +61,15 @@ static int rds_loop_xmit(struct rds_connection *conn, struct rds_message *rm,
unsigned int hdr_off, unsigned int sg,
unsigned int off)
{
+ struct scatterlist *sgp = &rm->data.op_sg[sg];
+ int ret = sizeof(struct rds_header) +
+ be32_to_cpu(rm->m_inc.i_hdr.h_len);
+
/* Do not send cong updates to loopback */
if (rm->m_inc.i_hdr.h_flags & RDS_FLAG_CONG_BITMAP) {
rds_cong_map_updated(conn->c_fcong, ~(u64) 0);
- return sizeof(struct rds_header) + RDS_CONG_MAP_BYTES;
+ ret = min_t(int, ret, sgp->length - conn->c_xmit_data_off);
+ goto out;
}
BUG_ON(hdr_off || sg || off);
@@ -80,8 +85,8 @@ static int rds_loop_xmit(struct rds_connection *conn, struct rds_message *rm,
NULL);
rds_inc_put(&rm->m_inc);
-
- return sizeof(struct rds_header) + be32_to_cpu(rm->m_inc.i_hdr.h_len);
+out:
+ return ret;
}
/*
--
1.7.4
^ permalink raw reply related
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-02 16:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Fabio Checconi, David Miller, Luigi Rizzo, netdev
In-Reply-To: <20110302081108.689571d8@nehalam>
Le mercredi 02 mars 2011 à 08:11 -0800, Stephen Hemminger a écrit :
> I put the iproute2 code into the repository in the experimental branch.
>
Thanks
It seems as soon as packets are dropped, qdisc is frozen (no more
packets dequeued)
Hmm...
^ permalink raw reply
* Re: [PATCH] sysctl: ipv6: use correct net in ipv6_sysctl_rtcache_flush
From: Daniel Lezcano @ 2011-03-02 16:38 UTC (permalink / raw)
To: Shan Wei; +Cc: Lucian Adrian Grijincu, netdev, David S . Miller, Benjamin Thery
In-Reply-To: <4D6DB89E.6010709@cn.fujitsu.com>
On 03/02/2011 04:25 AM, Shan Wei wrote:
> Lucian Adrian Grijincu wrote, at 02/25/2011 01:48 PM:
>> Before this patch issuing these commands:
>>
>> fd = open("/proc/sys/net/ipv6/route/flush")
>> unshare(CLONE_NEWNET)
>> write(fd, "stuff")
>>
>> would flush the newly created net, not the original one.
>
> After appling your patch, when excuting above commands,
> router cache still not be flushed in init net namespace.
> But IPv4 is ok.
>
> Host1: Host2
> ping6 Host2
> (shell1)
> open(/proc/sys/net/ipv6/route/flush)
> unshare(CLONE_NEWNET)
> while(1) {write(fd, "stuff")}
>
>
> (shell2)
> ip -6 route show cache<==1*
> 1*: IPv6 will show one route cache entry.
> But IPv4 shows nothing.
>
> As changlog said, after this patch, shell1 only fulsh the original
> net namespace, not the newly created one. But from shell2, we
> can see that IPv6 route cache is not flushed.
>
> Have i missed something?
Yes, you are right you shouldn't see any route from shell2.
Are you sure 'ip -6 route show cache' does not show the route cache in a
window where ping6 created a new route and 'write(fd, "stuff")' did not
flushed the new route yet ?
^ permalink raw reply
* [PATCH] via-rhine: do not abort due to invalid MAC address
From: Roger Luethi @ 2011-03-02 16:32 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Alex G.
From: "Alex G." <mr.nuke.me@gmail.com>
via-rhine drops out of the init code if the hardware provides an invalid
MAC address. I have several reports of Rhine NICs doing just that. The
hardware still works, though; continuing the init process gives the user a
chance to fix the MAC address using "ifconfig ethX hw ether" which appears
to result in a perfectly useable network adapter.
Most recent report and patch provided by Alex G.
Signed-off-by: "Alex G." <mr.nuke.me@gmail.com>
Signed-off-by: Roger Luethi <rl@hellgate.ch>
diff --git a/linux-2.6.35.11/drivers/net/via-rhine.c b/via-rhine.c
index 4930f9d..a1189f4 100644
--- a/linux-2.6.35.11/drivers/net/via-rhine.c
+++ b/via-rhine.c
@@ -766,8 +766,12 @@ static int __devinit rhine_init_one(struct pci_dev *pdev,
if (!is_valid_ether_addr(dev->perm_addr)) {
rc = -EIO;
- printk(KERN_ERR "Invalid MAC address\n");
- goto err_out_unmap;
+ printk(KERN_ERR "via-rhine: invalid MAC address: %pM. "
+ "Use ifconfig to configure valid address.\n",
+ dev->dev_addr);
+ /* The device may still be used normally if a valid MAC is configured
+ * We do not consider this a fatal error, and continue initialization
+ */
}
/* For Rhine-I/II, phy_id is loaded from EEPROM */
^ permalink raw reply related
* Re: txqueuelen has wrong units; should be time
From: Mikael Abrahamsson @ 2011-03-02 16:41 UTC (permalink / raw)
To: Stephen Hemminger
Cc: John Heffner, Bill Sommerfeld, Hagen Paul Pfeifer, Albert Cahalan,
Jussi Kivilinna, Eric Dumazet, linux-kernel, netdev
In-Reply-To: <20110301230754.5ef4ab35@nehalam>
On Tue, 1 Mar 2011, Stephen Hemminger wrote:
> Also WRED is not default on faster links because it can't be done fast
> enough.
Before this propagates as some kind of truth. Cisco modern core routers
have no problems doing WRED at wirespeed, the above statement is not true.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Eric Dumazet @ 2011-03-02 16:50 UTC (permalink / raw)
To: Mikael Abrahamsson
Cc: Stephen Hemminger, John Heffner, Bill Sommerfeld,
Hagen Paul Pfeifer, Albert Cahalan, Jussi Kivilinna, linux-kernel,
netdev
In-Reply-To: <alpine.DEB.1.10.1103021739550.7942@uplift.swm.pp.se>
Le mercredi 02 mars 2011 à 17:41 +0100, Mikael Abrahamsson a écrit :
> On Tue, 1 Mar 2011, Stephen Hemminger wrote:
>
> > Also WRED is not default on faster links because it can't be done fast
> > enough.
>
> Before this propagates as some kind of truth. Cisco modern core routers
> have no problems doing WRED at wirespeed, the above statement is not true.
>
looking at cisco docs you provided
( <http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/12stbwr.html>
)
, it seems the WRED time limits (instead of bytes/packets limits) are
internaly converted to bytes/packets limits
quote :
When the queue limit threshold is specified in milliseconds, the number
of milliseconds is internally converted to bytes using the bandwidth
available for the class.
So it seems its only a facility provided, and queues are still managed
with bytes/packets limits...
WRED is able to prob drop a packet when this packet is enqueued. At time
of enqueue, we dont know yet the time of dequeue, unless bandwidth is
known.
^ permalink raw reply
* [PATCH V4] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Narendra_K @ 2011-03-02 17:04 UTC (permalink / raw)
To: linux-pci, linux-hotplug
Cc: netdev, mjg, Matt_Domsch, Charles_Rose, Jordan_Hargrave,
Shyam_Iyer, sfr
In-Reply-To: <20110223125741.GA16473@fedora14-r610.blr.amer.dell.com>
On Wed, Feb 23, 2011 at 06:06:42PM +0530, K, Narendra wrote:
> Hello,
>
> This patch exports ACPI _DSM provided firmware instance number and
> string name to sysfs.
>
> V1 -> V2:
> The attribute 'index' is changed to 'acpi_index' as the semantics of
> SMBIOS provided device type instance and ACPI _DSM provided firmware
> instance number are different.
>
> V2 -> V3:
> Matthew Garrett pointed out that 'sysfs_create_groups' does return an
> error when there are no ACPI _DSM attributes available and because of
> that the fallback to SMBIOS will not happen. As a result SMBIOS provided
> attributes are not created. This version of the patch addresses the issue.
>
V3 -> V4:
Select NLS if (DMI || ACPI) in drivers/pci/Kconfig to prevent build
breakage from an 'allmodconfig'
Matthew,
Thanks for the suggestion.
From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] Export ACPI _DSM provided firmware instance number and string to sysfs
This patch exports ACPI _DSM (Device Specific Method) provided firmware
instance number and string name of PCI devices as defined by
'PCI Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming
a PCI or PCI Express Device Under Operating Systems) to sysfs.
New files created are:
/sys/bus/pci/devices/.../label which contains the firmware name for
the device in question, and
/sys/bus/pci/devices/.../acpi_index which contains the firmware device type
instance for the given device.
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/acpi_index
1
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/label
Embedded Broadcom 5709C NIC 1
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/acpi_index
2
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/label
Embedded Broadcom 5709C NIC 2
The ACPI _DSM provided firmware 'instance number' and 'string name' will
be given priority if the firmware also provides 'SMBIOS type 41 device
type instance and string'.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: Narendra K <narendra_k@dell.com>
---
Documentation/ABI/testing/sysfs-bus-pci | 31 +++-
drivers/pci/Kconfig | 2 +
drivers/pci/Makefile | 3 +-
drivers/pci/pci-label.c | 247 ++++++++++++++++++++++++++++++-
drivers/pci/pci.h | 2 +-
5 files changed, 270 insertions(+), 15 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index f979d82..36bf454 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -145,9 +145,11 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
- given name(SMBIOS type 41 string) of the PCI device.
- The attribute will be created only if the firmware
- has given a name to the PCI device.
+ given name (SMBIOS type 41 string or ACPI _DSM string) of
+ the PCI device. The attribute will be created only
+ if the firmware has given a name to the PCI device.
+ ACPI _DSM string name will be given priority if the
+ system firmware provides SMBIOS type 41 string also.
Users:
Userspace applications interested in knowing the
firmware assigned name of the PCI device.
@@ -157,12 +159,27 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
- given instance(SMBIOS type 41 device type instance)
- of the PCI device. The attribute will be created
- only if the firmware has given a device type instance
- to the PCI device.
+ given instance (SMBIOS type 41 device type instance) of the
+ PCI device. The attribute will be created only if the firmware
+ has given an instance number to the PCI device.
Users:
Userspace applications interested in knowing the
firmware assigned device type instance of the PCI
device that can help in understanding the firmware
intended order of the PCI device.
+
+What: /sys/bus/pci/devices/.../acpi_index
+Date: July 2010
+Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
+Description:
+ Reading this attribute will provide the firmware
+ given instance (ACPI _DSM instance number) of the PCI device.
+ The attribute will be created only if the firmware has given
+ an instance number to the PCI device. ACPI _DSM instance number
+ will be given priority if the system firmware provides SMBIOS
+ type 41 device type instance also.
+Users:
+ Userspace applications interested in knowing the
+ firmware assigned instance number of the PCI
+ device that can help in understanding the firmware
+ intended order of the PCI device.
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index a9523fd..c8ff646 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -87,3 +87,5 @@ config PCI_IOAPIC
depends on ACPI
depends on HOTPLUG
default y
+
+select NLS if (DMI || ACPI)
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 98e6fdf..bb1d3b2 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -53,8 +53,9 @@ obj-$(CONFIG_TILE) += setup-bus.o setup-irq.o
#
# ACPI Related PCI FW Functions
+# ACPI _DSM provided firmware instance and string name
#
-obj-$(CONFIG_ACPI) += pci-acpi.o
+obj-$(CONFIG_ACPI) += pci-acpi.o pci-label.o
# SMBIOS provided firmware instance and labels
obj-$(CONFIG_DMI) += pci-label.o
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 90c0a72..824e247 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -5,6 +5,13 @@
* by Narendra K <Narendra_K@dell.com>,
* Jordan Hargrave <Jordan_Hargrave@dell.com>
*
+ * PCI Firmware Specification Revision 3.1 section 4.6.7 (DSM for Naming a
+ * PCI or PCI Express Device Under Operating Systems) defines an instance
+ * number and string name. This code retrieves them and exports them to sysfs.
+ * If the system firmware does not provide the ACPI _DSM (Device Specific
+ * Method), then the SMBIOS type 41 instance number and string is exported to
+ * sysfs.
+ *
* SMBIOS defines type 41 for onboard pci devices. This code retrieves
* the instance number and string from the type 41 record and exports
* it to sysfs.
@@ -19,8 +26,30 @@
#include <linux/pci_ids.h>
#include <linux/module.h>
#include <linux/device.h>
+#include <linux/nls.h>
+#include <linux/acpi.h>
+#include <linux/pci-acpi.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/acpi_bus.h>
#include "pci.h"
+#define DEVICE_LABEL_DSM 0x07
+
+#ifndef CONFIG_DMI
+
+static inline int
+pci_create_smbiosname_file(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+static inline void
+pci_remove_smbiosname_file(struct pci_dev *pdev)
+{
+}
+
+#else
+
enum smbios_attr_enum {
SMBIOS_ATTR_NONE = 0,
SMBIOS_ATTR_LABEL_SHOW,
@@ -120,9 +149,7 @@ static struct attribute_group smbios_attr_group = {
static int
pci_create_smbiosname_file(struct pci_dev *pdev)
{
- if (!sysfs_create_group(&pdev->dev.kobj, &smbios_attr_group))
- return 0;
- return -ENODEV;
+ return sysfs_create_group(&pdev->dev.kobj, &smbios_attr_group);
}
static void
@@ -131,13 +158,221 @@ pci_remove_smbiosname_file(struct pci_dev *pdev)
sysfs_remove_group(&pdev->dev.kobj, &smbios_attr_group);
}
+#endif
+
+#ifndef CONFIG_ACPI
+
+static inline int
+pci_create_acpi_index_label_files(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+static inline int
+pci_remove_acpi_index_label_files(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+#else
+
+static const char device_label_dsm_uuid[] = {
+ 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
+ 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
+};
+
+enum acpi_attr_enum {
+ ACPI_ATTR_NONE = 0,
+ ACPI_ATTR_LABEL_SHOW,
+ ACPI_ATTR_INDEX_SHOW,
+};
+
+static void dsm_label_utf16s_to_utf8s(union acpi_object *obj, char *buf)
+{
+ int len;
+ len = utf16s_to_utf8s((const wchar_t *)obj->
+ package.elements[1].string.pointer,
+ obj->package.elements[1].string.length,
+ UTF16_LITTLE_ENDIAN,
+ buf, PAGE_SIZE);
+ buf[len] = '\n';
+}
+
+static int
+dsm_get_label(acpi_handle handle, int func,
+ struct acpi_buffer *output,
+ char *buf, enum acpi_attr_enum attribute)
+{
+ struct acpi_object_list input;
+ union acpi_object params[4];
+ union acpi_object *obj;
+ int len = 0;
+
+ int err;
+
+ input.count = 4;
+ input.pointer = params;
+ params[0].type = ACPI_TYPE_BUFFER;
+ params[0].buffer.length = sizeof(device_label_dsm_uuid);
+ params[0].buffer.pointer = (char *)device_label_dsm_uuid;
+ params[1].type = ACPI_TYPE_INTEGER;
+ params[1].integer.value = 0x02;
+ params[2].type = ACPI_TYPE_INTEGER;
+ params[2].integer.value = func;
+ params[3].type = ACPI_TYPE_PACKAGE;
+ params[3].package.count = 0;
+ params[3].package.elements = NULL;
+
+ err = acpi_evaluate_object(handle, "_DSM", &input, output);
+ if (err)
+ return -1;
+
+ obj = (union acpi_object *)output->pointer;
+
+ switch (obj->type) {
+ case ACPI_TYPE_PACKAGE:
+ if (obj->package.count != 2)
+ break;
+ len = obj->package.elements[0].integer.value;
+ if (buf) {
+ if (attribute == ACPI_ATTR_INDEX_SHOW)
+ scnprintf(buf, PAGE_SIZE, "%llu\n",
+ obj->package.elements[0].integer.value);
+ else if (attribute == ACPI_ATTR_LABEL_SHOW)
+ dsm_label_utf16s_to_utf8s(obj, buf);
+ kfree(output->pointer);
+ return strlen(buf);
+ }
+ kfree(output->pointer);
+ return len;
+ break;
+ default:
+ kfree(output->pointer);
+ }
+ return -1;
+}
+
+static bool
+device_has_dsm(struct device *dev)
+{
+ acpi_handle handle;
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return FALSE;
+
+ if (dsm_get_label(handle, DEVICE_LABEL_DSM, &output, NULL,
+ ACPI_ATTR_NONE) > 0)
+ return TRUE;
+
+ return FALSE;
+}
+
+static mode_t
+acpi_index_string_exist(struct kobject *kobj, struct attribute *attr, int n)
+{
+ struct device *dev;
+
+ dev = container_of(kobj, struct device, kobj);
+
+ if (device_has_dsm(dev))
+ return S_IRUGO;
+
+ return 0;
+}
+
+static ssize_t
+acpilabel_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+ acpi_handle handle;
+ int length;
+
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return -1;
+
+ length = dsm_get_label(handle, DEVICE_LABEL_DSM,
+ &output, buf, ACPI_ATTR_LABEL_SHOW);
+
+ if (length < 1)
+ return -1;
+
+ return length;
+}
+
+static ssize_t
+acpiindex_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+ acpi_handle handle;
+ int length;
+
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return -1;
+
+ length = dsm_get_label(handle, DEVICE_LABEL_DSM,
+ &output, buf, ACPI_ATTR_INDEX_SHOW);
+
+ if (length < 0)
+ return -1;
+
+ return length;
+
+}
+
+static struct device_attribute acpi_attr_label = {
+ .attr = {.name = "label", .mode = 0444},
+ .show = acpilabel_show,
+};
+
+static struct device_attribute acpi_attr_index = {
+ .attr = {.name = "acpi_index", .mode = 0444},
+ .show = acpiindex_show,
+};
+
+static struct attribute *acpi_attributes[] = {
+ &acpi_attr_label.attr,
+ &acpi_attr_index.attr,
+ NULL,
+};
+
+static struct attribute_group acpi_attr_group = {
+ .attrs = acpi_attributes,
+ .is_visible = acpi_index_string_exist,
+};
+
+static int
+pci_create_acpi_index_label_files(struct pci_dev *pdev)
+{
+ return sysfs_create_group(&pdev->dev.kobj, &acpi_attr_group);
+}
+
+static int
+pci_remove_acpi_index_label_files(struct pci_dev *pdev)
+{
+ sysfs_remove_group(&pdev->dev.kobj, &acpi_attr_group);
+ return 0;
+}
+#endif
+
void pci_create_firmware_label_files(struct pci_dev *pdev)
{
- if (!pci_create_smbiosname_file(pdev))
- ;
+ if (device_has_dsm(&pdev->dev))
+ pci_create_acpi_index_label_files(pdev);
+ else
+ pci_create_smbiosname_file(pdev);
}
void pci_remove_firmware_label_files(struct pci_dev *pdev)
{
- pci_remove_smbiosname_file(pdev);
+ if (device_has_dsm(&pdev->dev))
+ pci_remove_acpi_index_label_files(pdev);
+ else
+ pci_remove_smbiosname_file(pdev);
}
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f69d6e0..a6ec200 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -11,7 +11,7 @@
extern int pci_uevent(struct device *dev, struct kobj_uevent_env *env);
extern int pci_create_sysfs_dev_files(struct pci_dev *pdev);
extern void pci_remove_sysfs_dev_files(struct pci_dev *pdev);
-#ifndef CONFIG_DMI
+#if !defined(CONFIG_DMI) && !defined(CONFIG_ACPI)
static inline void pci_create_firmware_label_files(struct pci_dev *pdev)
{ return; }
static inline void pci_remove_firmware_label_files(struct pci_dev *pdev)
--
1.7.3.1
With regards,
Narendra K
^ permalink raw reply related
* Re: [PATCH v3, RESEND 00/16] make rpc_pipefs be mountable multiple time
From: Kirill A. Shutemov @ 2011-03-02 17:06 UTC (permalink / raw)
To: Trond Myklebust, J. Bruce Fields
Cc: Kirill A. Shutemov, Neil Brown, Pavel Emelyanov,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, David S. Miller, Rob Landley,
Al Viro, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1297190527-19925-1-git-send-email-kas-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Any chanse to get it in .39?
--
Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/3] mii: Convert printks to netdev_info
From: Joe Perches @ 2011-03-02 17:18 UTC (permalink / raw)
To: netdev
In-Reply-To: <7f33dcacd277e127208211d8c3ef11c992408628.1299086044.git.joe@perches.com>
Add a bit more data to the output.
Convert string speeds to integer.
Object size reduced a tiny bit.
$ size drivers/net/mii.o*
text data bss dec hex filename
4155 56 1000 5211 145b drivers/net/mii.o.new
4184 56 1000 5240 1478 drivers/net/mii.o.old
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/tun.c | 83 ++++++++++++++++++++--------------------------------
1 files changed, 32 insertions(+), 51 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index f5e9ac0..55786a0 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -34,8 +34,6 @@
* Modifications for 2.3.99-pre5 kernel.
*/
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
#define DRV_NAME "tun"
#define DRV_VERSION "1.6"
#define DRV_DESCRIPTION "Universal TUN/TAP device driver"
@@ -78,27 +76,11 @@
#ifdef TUN_DEBUG
static int debug;
-#define tun_debug(level, tun, fmt, args...) \
-do { \
- if (tun->debug) \
- netdev_printk(level, tun->dev, fmt, ##args); \
-} while (0)
-#define DBG1(level, fmt, args...) \
-do { \
- if (debug == 2) \
- printk(level fmt, ##args); \
-} while (0)
+#define DBG if(tun->debug)printk
+#define DBG1 if(debug==2)printk
#else
-#define tun_debug(level, tun, fmt, args...) \
-do { \
- if (0) \
- netdev_printk(level, tun->dev, fmt, ##args); \
-} while (0)
-#define DBG1(level, fmt, args...) \
-do { \
- if (0) \
- printk(level fmt, ##args); \
-} while (0)
+#define DBG( a... )
+#define DBG1( a... )
#endif
#define FLT_EXACT_COUNT 8
@@ -223,7 +205,7 @@ static void tun_put(struct tun_struct *tun)
tun_detach(tfile->tun);
}
-/* TAP filtering */
+/* TAP filterting */
static void addr_hash_set(u32 *mask, const u8 *addr)
{
int n = ether_crc(ETH_ALEN, addr) >> 26;
@@ -378,7 +360,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct tun_struct *tun = netdev_priv(dev);
- tun_debug(KERN_INFO, tun, "tun_net_xmit %d\n", skb->len);
+ DBG(KERN_INFO "%s: tun_net_xmit %d\n", tun->dev->name, skb->len);
/* Drop packet if interface is not attached */
if (!tun->tfile)
@@ -517,7 +499,7 @@ static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
sk = tun->socket.sk;
- tun_debug(KERN_INFO, tun, "tun_chr_poll\n");
+ DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name);
poll_wait(file, &tun->wq.wait, wait);
@@ -708,7 +690,7 @@ static ssize_t tun_chr_aio_write(struct kiocb *iocb, const struct iovec *iv,
if (!tun)
return -EBADFD;
- tun_debug(KERN_INFO, tun, "tun_chr_write %ld\n", count);
+ DBG(KERN_INFO "%s: tun_chr_write %ld\n", tun->dev->name, count);
result = tun_get_user(tun, iv, iov_length(iv, count),
file->f_flags & O_NONBLOCK);
@@ -757,7 +739,7 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
else if (sinfo->gso_type & SKB_GSO_UDP)
gso.gso_type = VIRTIO_NET_HDR_GSO_UDP;
else {
- pr_err("unexpected GSO type: "
+ printk(KERN_ERR "tun: unexpected GSO type: "
"0x%x, gso_size %d, hdr_len %d\n",
sinfo->gso_type, gso.gso_size,
gso.hdr_len);
@@ -804,7 +786,7 @@ static ssize_t tun_do_read(struct tun_struct *tun,
struct sk_buff *skb;
ssize_t ret = 0;
- tun_debug(KERN_INFO, tun, "tun_chr_read\n");
+ DBG(KERN_INFO "%s: tun_chr_read\n", tun->dev->name);
add_wait_queue(&tun->wq.wait, &wait);
while (len) {
@@ -1101,7 +1083,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) ||
device_create_file(&tun->dev->dev, &dev_attr_owner) ||
device_create_file(&tun->dev->dev, &dev_attr_group))
- pr_err("Failed to create tun sysfs files\n");
+ printk(KERN_ERR "Failed to create tun sysfs files\n");
sk->sk_destruct = tun_sock_destruct;
@@ -1110,7 +1092,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
goto failed;
}
- tun_debug(KERN_INFO, tun, "tun_set_iff\n");
+ DBG(KERN_INFO "%s: tun_set_iff\n", tun->dev->name);
if (ifr->ifr_flags & IFF_NO_PI)
tun->flags |= TUN_NO_PI;
@@ -1147,7 +1129,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
static int tun_get_iff(struct net *net, struct tun_struct *tun,
struct ifreq *ifr)
{
- tun_debug(KERN_INFO, tun, "tun_get_iff\n");
+ DBG(KERN_INFO "%s: tun_get_iff\n", tun->dev->name);
strcpy(ifr->ifr_name, tun->dev->name);
@@ -1247,7 +1229,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
if (!tun)
goto unlock;
- tun_debug(KERN_INFO, tun, "tun_chr_ioctl cmd %d\n", cmd);
+ DBG(KERN_INFO "%s: tun_chr_ioctl cmd %d\n", tun->dev->name, cmd);
ret = 0;
switch (cmd) {
@@ -1267,8 +1249,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
else
tun->flags &= ~TUN_NOCHECKSUM;
- tun_debug(KERN_INFO, tun, "checksum %s\n",
- arg ? "disabled" : "enabled");
+ DBG(KERN_INFO "%s: checksum %s\n",
+ tun->dev->name, arg ? "disabled" : "enabled");
break;
case TUNSETPERSIST:
@@ -1278,34 +1260,33 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
else
tun->flags &= ~TUN_PERSIST;
- tun_debug(KERN_INFO, tun, "persist %s\n",
- arg ? "enabled" : "disabled");
+ DBG(KERN_INFO "%s: persist %s\n",
+ tun->dev->name, arg ? "enabled" : "disabled");
break;
case TUNSETOWNER:
/* Set owner of the device */
tun->owner = (uid_t) arg;
- tun_debug(KERN_INFO, tun, "owner set to %d\n", tun->owner);
+ DBG(KERN_INFO "%s: owner set to %d\n", tun->dev->name, tun->owner);
break;
case TUNSETGROUP:
/* Set group of the device */
tun->group= (gid_t) arg;
- tun_debug(KERN_INFO, tun, "group set to %d\n", tun->group);
+ DBG(KERN_INFO "%s: group set to %d\n", tun->dev->name, tun->group);
break;
case TUNSETLINK:
/* Only allow setting the type when the interface is down */
if (tun->dev->flags & IFF_UP) {
- tun_debug(KERN_INFO, tun,
- "Linktype set failed because interface is up\n");
+ DBG(KERN_INFO "%s: Linktype set failed because interface is up\n",
+ tun->dev->name);
ret = -EBUSY;
} else {
tun->dev->type = (int) arg;
- tun_debug(KERN_INFO, tun, "linktype set to %d\n",
- tun->dev->type);
+ DBG(KERN_INFO "%s: linktype set to %d\n", tun->dev->name, tun->dev->type);
ret = 0;
}
break;
@@ -1337,8 +1318,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
case SIOCSIFHWADDR:
/* Set hw address */
- tun_debug(KERN_DEBUG, tun, "set hw address: %pM\n",
- ifr.ifr_hwaddr.sa_data);
+ DBG(KERN_DEBUG "%s: set hw address: %pM\n",
+ tun->dev->name, ifr.ifr_hwaddr.sa_data);
ret = dev_set_mac_address(tun->dev, &ifr.ifr_hwaddr);
break;
@@ -1452,7 +1433,7 @@ static int tun_chr_fasync(int fd, struct file *file, int on)
if (!tun)
return -EBADFD;
- tun_debug(KERN_INFO, tun, "tun_chr_fasync %d\n", on);
+ DBG(KERN_INFO "%s: tun_chr_fasync %d\n", tun->dev->name, on);
if ((ret = fasync_helper(fd, file, on, &tun->fasync)) < 0)
goto out;
@@ -1474,7 +1455,7 @@ static int tun_chr_open(struct inode *inode, struct file * file)
{
struct tun_file *tfile;
- DBG1(KERN_INFO, "tunX: tun_chr_open\n");
+ DBG1(KERN_INFO "tunX: tun_chr_open\n");
tfile = kmalloc(sizeof(*tfile), GFP_KERNEL);
if (!tfile)
@@ -1495,7 +1476,7 @@ static int tun_chr_close(struct inode *inode, struct file *file)
if (tun) {
struct net_device *dev = tun->dev;
- tun_debug(KERN_INFO, tun, "tun_chr_close\n");
+ DBG(KERN_INFO "%s: tun_chr_close\n", dev->name);
__tun_detach(tun);
@@ -1626,18 +1607,18 @@ static int __init tun_init(void)
{
int ret = 0;
- pr_info("%s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
- pr_info("%s\n", DRV_COPYRIGHT);
+ printk(KERN_INFO "tun: %s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
+ printk(KERN_INFO "tun: %s\n", DRV_COPYRIGHT);
ret = rtnl_link_register(&tun_link_ops);
if (ret) {
- pr_err("Can't register link_ops\n");
+ printk(KERN_ERR "tun: Can't register link_ops\n");
goto err_linkops;
}
ret = misc_register(&tun_miscdev);
if (ret) {
- pr_err("Can't register misc device %d\n", TUN_MINOR);
+ printk(KERN_ERR "tun: Can't register misc device %d\n", TUN_MINOR);
goto err_misc;
}
return 0;
--
1.7.4.2.g597a6.dirty
^ permalink raw reply related
* [PATCH 1/3] tun: Convert logging messages to pr_<level> and tun_debug
From: Joe Perches @ 2011-03-02 17:18 UTC (permalink / raw)
To: netdev
Use the current logging forms with pr_fmt.
Convert DBG macro to tun_debug, use netdev_printk as well.
Add printf verification when TUN_DEBUG not defined.
Miscellaneous comment typo fix.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/tun.c | 83 ++++++++++++++++++++++++++++++++--------------------
1 files changed, 51 insertions(+), 32 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 55786a0..f5e9ac0 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -34,6 +34,8 @@
* Modifications for 2.3.99-pre5 kernel.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#define DRV_NAME "tun"
#define DRV_VERSION "1.6"
#define DRV_DESCRIPTION "Universal TUN/TAP device driver"
@@ -76,11 +78,27 @@
#ifdef TUN_DEBUG
static int debug;
-#define DBG if(tun->debug)printk
-#define DBG1 if(debug==2)printk
+#define tun_debug(level, tun, fmt, args...) \
+do { \
+ if (tun->debug) \
+ netdev_printk(level, tun->dev, fmt, ##args); \
+} while (0)
+#define DBG1(level, fmt, args...) \
+do { \
+ if (debug == 2) \
+ printk(level fmt, ##args); \
+} while (0)
#else
-#define DBG( a... )
-#define DBG1( a... )
+#define tun_debug(level, tun, fmt, args...) \
+do { \
+ if (0) \
+ netdev_printk(level, tun->dev, fmt, ##args); \
+} while (0)
+#define DBG1(level, fmt, args...) \
+do { \
+ if (0) \
+ printk(level fmt, ##args); \
+} while (0)
#endif
#define FLT_EXACT_COUNT 8
@@ -205,7 +223,7 @@ static void tun_put(struct tun_struct *tun)
tun_detach(tfile->tun);
}
-/* TAP filterting */
+/* TAP filtering */
static void addr_hash_set(u32 *mask, const u8 *addr)
{
int n = ether_crc(ETH_ALEN, addr) >> 26;
@@ -360,7 +378,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct tun_struct *tun = netdev_priv(dev);
- DBG(KERN_INFO "%s: tun_net_xmit %d\n", tun->dev->name, skb->len);
+ tun_debug(KERN_INFO, tun, "tun_net_xmit %d\n", skb->len);
/* Drop packet if interface is not attached */
if (!tun->tfile)
@@ -499,7 +517,7 @@ static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
sk = tun->socket.sk;
- DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name);
+ tun_debug(KERN_INFO, tun, "tun_chr_poll\n");
poll_wait(file, &tun->wq.wait, wait);
@@ -690,7 +708,7 @@ static ssize_t tun_chr_aio_write(struct kiocb *iocb, const struct iovec *iv,
if (!tun)
return -EBADFD;
- DBG(KERN_INFO "%s: tun_chr_write %ld\n", tun->dev->name, count);
+ tun_debug(KERN_INFO, tun, "tun_chr_write %ld\n", count);
result = tun_get_user(tun, iv, iov_length(iv, count),
file->f_flags & O_NONBLOCK);
@@ -739,7 +757,7 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
else if (sinfo->gso_type & SKB_GSO_UDP)
gso.gso_type = VIRTIO_NET_HDR_GSO_UDP;
else {
- printk(KERN_ERR "tun: unexpected GSO type: "
+ pr_err("unexpected GSO type: "
"0x%x, gso_size %d, hdr_len %d\n",
sinfo->gso_type, gso.gso_size,
gso.hdr_len);
@@ -786,7 +804,7 @@ static ssize_t tun_do_read(struct tun_struct *tun,
struct sk_buff *skb;
ssize_t ret = 0;
- DBG(KERN_INFO "%s: tun_chr_read\n", tun->dev->name);
+ tun_debug(KERN_INFO, tun, "tun_chr_read\n");
add_wait_queue(&tun->wq.wait, &wait);
while (len) {
@@ -1083,7 +1101,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) ||
device_create_file(&tun->dev->dev, &dev_attr_owner) ||
device_create_file(&tun->dev->dev, &dev_attr_group))
- printk(KERN_ERR "Failed to create tun sysfs files\n");
+ pr_err("Failed to create tun sysfs files\n");
sk->sk_destruct = tun_sock_destruct;
@@ -1092,7 +1110,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
goto failed;
}
- DBG(KERN_INFO "%s: tun_set_iff\n", tun->dev->name);
+ tun_debug(KERN_INFO, tun, "tun_set_iff\n");
if (ifr->ifr_flags & IFF_NO_PI)
tun->flags |= TUN_NO_PI;
@@ -1129,7 +1147,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
static int tun_get_iff(struct net *net, struct tun_struct *tun,
struct ifreq *ifr)
{
- DBG(KERN_INFO "%s: tun_get_iff\n", tun->dev->name);
+ tun_debug(KERN_INFO, tun, "tun_get_iff\n");
strcpy(ifr->ifr_name, tun->dev->name);
@@ -1229,7 +1247,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
if (!tun)
goto unlock;
- DBG(KERN_INFO "%s: tun_chr_ioctl cmd %d\n", tun->dev->name, cmd);
+ tun_debug(KERN_INFO, tun, "tun_chr_ioctl cmd %d\n", cmd);
ret = 0;
switch (cmd) {
@@ -1249,8 +1267,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
else
tun->flags &= ~TUN_NOCHECKSUM;
- DBG(KERN_INFO "%s: checksum %s\n",
- tun->dev->name, arg ? "disabled" : "enabled");
+ tun_debug(KERN_INFO, tun, "checksum %s\n",
+ arg ? "disabled" : "enabled");
break;
case TUNSETPERSIST:
@@ -1260,33 +1278,34 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
else
tun->flags &= ~TUN_PERSIST;
- DBG(KERN_INFO "%s: persist %s\n",
- tun->dev->name, arg ? "enabled" : "disabled");
+ tun_debug(KERN_INFO, tun, "persist %s\n",
+ arg ? "enabled" : "disabled");
break;
case TUNSETOWNER:
/* Set owner of the device */
tun->owner = (uid_t) arg;
- DBG(KERN_INFO "%s: owner set to %d\n", tun->dev->name, tun->owner);
+ tun_debug(KERN_INFO, tun, "owner set to %d\n", tun->owner);
break;
case TUNSETGROUP:
/* Set group of the device */
tun->group= (gid_t) arg;
- DBG(KERN_INFO "%s: group set to %d\n", tun->dev->name, tun->group);
+ tun_debug(KERN_INFO, tun, "group set to %d\n", tun->group);
break;
case TUNSETLINK:
/* Only allow setting the type when the interface is down */
if (tun->dev->flags & IFF_UP) {
- DBG(KERN_INFO "%s: Linktype set failed because interface is up\n",
- tun->dev->name);
+ tun_debug(KERN_INFO, tun,
+ "Linktype set failed because interface is up\n");
ret = -EBUSY;
} else {
tun->dev->type = (int) arg;
- DBG(KERN_INFO "%s: linktype set to %d\n", tun->dev->name, tun->dev->type);
+ tun_debug(KERN_INFO, tun, "linktype set to %d\n",
+ tun->dev->type);
ret = 0;
}
break;
@@ -1318,8 +1337,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
case SIOCSIFHWADDR:
/* Set hw address */
- DBG(KERN_DEBUG "%s: set hw address: %pM\n",
- tun->dev->name, ifr.ifr_hwaddr.sa_data);
+ tun_debug(KERN_DEBUG, tun, "set hw address: %pM\n",
+ ifr.ifr_hwaddr.sa_data);
ret = dev_set_mac_address(tun->dev, &ifr.ifr_hwaddr);
break;
@@ -1433,7 +1452,7 @@ static int tun_chr_fasync(int fd, struct file *file, int on)
if (!tun)
return -EBADFD;
- DBG(KERN_INFO "%s: tun_chr_fasync %d\n", tun->dev->name, on);
+ tun_debug(KERN_INFO, tun, "tun_chr_fasync %d\n", on);
if ((ret = fasync_helper(fd, file, on, &tun->fasync)) < 0)
goto out;
@@ -1455,7 +1474,7 @@ static int tun_chr_open(struct inode *inode, struct file * file)
{
struct tun_file *tfile;
- DBG1(KERN_INFO "tunX: tun_chr_open\n");
+ DBG1(KERN_INFO, "tunX: tun_chr_open\n");
tfile = kmalloc(sizeof(*tfile), GFP_KERNEL);
if (!tfile)
@@ -1476,7 +1495,7 @@ static int tun_chr_close(struct inode *inode, struct file *file)
if (tun) {
struct net_device *dev = tun->dev;
- DBG(KERN_INFO "%s: tun_chr_close\n", dev->name);
+ tun_debug(KERN_INFO, tun, "tun_chr_close\n");
__tun_detach(tun);
@@ -1607,18 +1626,18 @@ static int __init tun_init(void)
{
int ret = 0;
- printk(KERN_INFO "tun: %s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
- printk(KERN_INFO "tun: %s\n", DRV_COPYRIGHT);
+ pr_info("%s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
+ pr_info("%s\n", DRV_COPYRIGHT);
ret = rtnl_link_register(&tun_link_ops);
if (ret) {
- printk(KERN_ERR "tun: Can't register link_ops\n");
+ pr_err("Can't register link_ops\n");
goto err_linkops;
}
ret = misc_register(&tun_miscdev);
if (ret) {
- printk(KERN_ERR "tun: Can't register misc device %d\n", TUN_MINOR);
+ pr_err("Can't register misc device %d\n", TUN_MINOR);
goto err_misc;
}
return 0;
--
1.7.4.2.g597a6.dirty
^ permalink raw reply related
* [PATCH 3/3] eql: Convert printks to pr_<level> and netdev_<level>
From: Joe Perches @ 2011-03-02 17:18 UTC (permalink / raw)
To: netdev
In-Reply-To: <7f33dcacd277e127208211d8c3ef11c992408628.1299086044.git.joe@perches.com>
Add pr_fmt
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/eql.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/eql.c b/drivers/net/eql.c
index 0cb1cf9..ffda358 100644
--- a/drivers/net/eql.c
+++ b/drivers/net/eql.c
@@ -111,6 +111,8 @@
* Sorry, I had to rewrite most of this for 2.5.x -DaveM
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/capability.h>
#include <linux/module.h>
#include <linux/kernel.h>
@@ -204,8 +206,8 @@ static int eql_open(struct net_device *dev)
equalizer_t *eql = netdev_priv(dev);
/* XXX We should force this off automatically for the user. */
- printk(KERN_INFO "%s: remember to turn off Van-Jacobson compression on "
- "your slave devices.\n", dev->name);
+ netdev_info(dev,
+ "remember to turn off Van-Jacobson compression on your slave devices\n");
BUG_ON(!list_empty(&eql->queue.all_slaves));
@@ -591,7 +593,7 @@ static int __init eql_init_module(void)
{
int err;
- printk(version);
+ pr_info(version);
dev_eql = alloc_netdev(sizeof(equalizer_t), "eql", eql_setup);
if (!dev_eql)
--
1.7.4.2.g597a6.dirty
^ permalink raw reply related
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-02 17:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Fabio Checconi, David Miller, Luigi Rizzo, netdev
In-Reply-To: <1299082728.2920.18.camel@edumazet-laptop>
Le mercredi 02 mars 2011 à 17:18 +0100, Eric Dumazet a écrit :
> Le mercredi 02 mars 2011 à 08:11 -0800, Stephen Hemminger a écrit :
>
> > I put the iproute2 code into the repository in the experimental branch.
> >
>
> Thanks
>
> It seems as soon as packets are dropped, qdisc is frozen (no more
> packets dequeued)
>
> Hmm...
>
It seems class deletes are buggy.
After one "tc class del dev $ETH classid 11:1 ..."
a "tc -s -d qdisc show dev $ETH" triggers an Oops
[ 414.517709] general protection fault: 0000 [#1] SMP
[ 414.517894] last sysfs file: /sys/devices/virtual/net/gre34/ifindex
[ 414.517956] CPU 3
[ 414.517995] Modules linked in: sch_qfq sch_cbq ip_gre gre dummy ipmi_devintf ipmi_si ipmi_msghandler dm_mod video tg3 libphy sg [last unloaded: ip_tables]
[ 414.518663]
[ 414.518717] Pid: 4692, comm: tc Not tainted 2.6.38-rc5-02726-gd486b8c-dirty #554 HP ProLiant BL460c G6
[ 414.518905] RIP: 0010:[<ffffffff8145118e>] [<ffffffff8145118e>] tc_fill_qdisc+0xbe/0x300
[ 414.519025] RSP: 0018:ffff88011a123878 EFLAGS: 00010283
[ 414.519085] RAX: a00e6660ffffffff RBX: 0000000000000002 RCX: 0000000000000024
[ 414.519149] RDX: ffff880078683334 RSI: 0000000000000000 RDI: ffff88007867b400
[ 414.519212] RBP: ffff88011a123928 R08: ffff880078683000 R09: 0000000000000002
[ 414.519276] R10: 00000000000001f0 R11: 00000000000001e0 R12: ffff88007867b400
[ 414.519340] R13: ffff88011cb1779c R14: ffff880078683324 R15: 0000000000001254
[ 414.519405] FS: 0000000000000000(0000) GS:ffff88007fc40000(0063) knlGS:00000000f77778e0
[ 414.519486] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 414.519553] CR2: 00000000005ffc80 CR3: 0000000078087000 CR4: 00000000000006e0
[ 414.519616] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 414.519680] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 414.519744] Process tc (pid: 4692, threadinfo ffff88011a122000, task ffff88011a1715d0)
[ 414.519823] Stack:
[ 414.519876] ffff88011bbfb570 000000004d6e7c8e ffff880078683324 0000000000000000
[ 414.520095] ffff88011cb1789c ffff88007867b400 ffff8800786832bc 0000000400000003
[ 414.520312] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 414.520531] Call Trace:
[ 414.520602] [<ffffffff81451469>] tc_dump_qdisc_root+0x99/0x100
[ 414.520666] [<ffffffff81452680>] tc_dump_qdisc+0x80/0x100
[ 414.520729] [<ffffffff8146a50b>] netlink_dump+0x6b/0x1e0
[ 414.520791] [<ffffffff810f5d16>] ? kmem_cache_alloc_trace+0xb6/0x100
[ 414.520855] [<ffffffff8146d2ef>] netlink_dump_start+0x16f/0x190
[ 414.520918] [<ffffffff81452600>] ? tc_dump_qdisc+0x0/0x100
[ 414.520981] [<ffffffff81443b36>] rtnetlink_rcv_msg+0xb6/0x270
[ 414.521043] [<ffffffff81443a80>] ? rtnetlink_rcv_msg+0x0/0x270
[ 414.521106] [<ffffffff8146b609>] netlink_rcv_skb+0x99/0xc0
[ 414.521167] [<ffffffff81443a65>] rtnetlink_rcv+0x25/0x40
[ 414.521229] [<ffffffff8146b379>] netlink_unicast+0x2a9/0x2b0
[ 414.521292] [<ffffffff8142c3e3>] ? memcpy_fromiovec+0x63/0x80
[ 414.521354] [<ffffffff8146c30d>] netlink_sendmsg+0x24d/0x390
[ 414.521418] [<ffffffff81421510>] sock_sendmsg+0xc0/0xf0
[ 414.521482] [<ffffffff810b699a>] ? unlock_page+0x2a/0x40
[ 414.521545] [<ffffffff81421262>] ? move_addr_to_kernel+0x62/0x70
[ 414.521608] [<ffffffff8144d59f>] ? verify_compat_iovec+0x8f/0x100
[ 414.521685] [<ffffffff814222b0>] sys_sendmsg+0x180/0x300
[ 414.521747] [<ffffffff810d682c>] ? __pte_alloc+0xdc/0x100
[ 414.521809] [<ffffffff810d6992>] ? handle_mm_fault+0x142/0x1c0
[ 414.521872] [<ffffffff81569594>] ? do_page_fault+0x274/0x490
[ 414.521935] [<ffffffff81421f41>] ? sys_getsockname+0xa1/0xb0
[ 414.521997] [<ffffffff81421909>] ? sys_recvmsg+0x49/0x80
[ 414.522059] [<ffffffff8144d164>] compat_sys_sendmsg+0x14/0x20
[ 414.522121] [<ffffffff8144e08d>] compat_sys_socketcall+0x19d/0x1f0
[ 414.522185] [<ffffffff8102d640>] sysenter_dispatch+0x7/0x2e
[ 414.522246] Code: 06 49 8d 56 10 45 89 7e 0c 66 41 89 46 04 8b 85 58 ff ff ff 41 c6 46 10 00 41 89 46 08 c6 42 01 00 66 c7 42 02 00 00 49 8b 45 68 <48> 8b 00 8b 80 c0 00 00 00 89 42 04 8b 85 5c ff ff ff 89 42 0c
[ 414.524636] RIP [<ffffffff8145118e>] tc_fill_qdisc+0xbe/0x300
[ 414.524734] RSP <ffff88011a123878>
[ 414.524799] ---[ end trace 513a4307e5c34d00 ]---
^ permalink raw reply
* Re: [PATCH (sh-2.6) 1/4] clksource: Generic timer infrastructure
From: Peppe CAVALLARO @ 2011-03-02 17:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Stuart MENEFY, Arnd Bergmann, linux-sh@vger.kernel.org,
netdev@vger.kernel.org, John Stultz, linux-kernel@vger.kernel.org,
linux@arm.linux.org.uk
In-Reply-To: <alpine.LFD.2.00.1103011630080.2701@localhost6.localdomain6>
Hello and many thanks to All for your feedback.
On 3/1/2011 5:48 PM, Thomas Gleixner wrote:
>
> On Tue, 1 Mar 2011, Stuart Menefy wrote:
> > On 24/02/11 17:20, Arnd Bergmann wrote:
> > > On Tuesday 22 February 2011, Peppe CAVALLARO wrote:
> > >> From: Stuart Menefy <stuart.menefy@st.com>
> > >>
> > >> Many devices targeted at the embedded market provide a number of
> > >> generic timers which are capable of generating interrupts at a
> > >> requested rate. These can then be used in the implementation of
> drivers
> > >> for other peripherals which require a timer interrupt, without having
> > >> to provide an additional timer as part of that peripheral.
>
> Why can't you just use an hrtimer and be done with it? Just because
> there is some extra hardware in the chip?
>
> > If anything this duplicates clockevents. The main reason for not using
> > clockevents was that nobody else does! Currently clockevents are
> > used strictly for time keeping within the kernel, and most architectures
> > only register those which are intended to be used for this purpose.
> > We felt a bit nervous about adding code to register all the device's
> timers
> > as clockevents, and having the network device driver pick up one of
> those
> > for its own use.
>
> We had this discussion before and there was never an real outcome as
> it turned out that hrtimers provide enough abstraction for this kind
> of problems.
>
> > True. The intent was that this would be a third interface onto timer
> > hardware, alongside clocksources and clockevents.
> >
> > > I don't know if this could also be merged with the clocksource
> infrastructure,
> > > but your code currently doesn't do that.
> >
> > It would probably be clockevent rather than clocksource, but it
> could be if
> > people felt that was a better way to go.
>
> If we get some reasonable explanation why an extra timer interrupt is
> solving a specific problem better than hrtimers we can do that, but
> that needs more thought than picking the first available clockevent
> from a list. If we come to the conclusion, that we want/need this kind
> of functionality then I really prefer not to create yet another piece
> of infrastructure which deals with timer devices.
>
The initial/main usage of this code was to provide
an interrupt timer to handle the rx/tx processes in
the stmmac Ethernet d.d.
Some Ethernet devices have embedded timer
used for mitigating the number of their DMA interrupts.
So, to be frankly, my first idea was to use an
extra HW (SH4 TMU channel 2), unused on our platforms,
because our MAC hadn't something like that.
I'm not sure if other Ethernet drivers use hrtimer for
handling the whole rx/tx processes (on CC the net-2.6 ML:
please correct me if I'm wrong) and if this could have
impact on the performances or reliability of the network
activity (pkt loss%).
At any rate, I am happy to use the stmmac as experimental
driver to do this kind tests.
Indeed, in the past, on old Kernel (IIRC 2.6.23), I tried to use
the kernel timers but I removed the code from it because
I had noticed packets loss and a strange phenomenon with cyclesoak
(that showed broken sysload % during the heavy network activities).
Let me know how to proceed:
1) experiment with stmmac and hrtimer for handling rx/tx?
2) rework the patches for the Generic Timer Infra?
Best Regards,
Peppe
> Thanks,
>
> tglx
>
^ permalink raw reply
* Re: skb->frag_list != NULL in start_xmit for device without NETIF_F_FRAGLIST
From: Ian Campbell @ 2011-03-02 17:42 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev@vger.kernel.org, Paul Durrant, dev
In-Reply-To: <1299071683.17907.1764.camel@zakaz.uk.xensource.com>
On Wed, 2011-03-02 at 13:14 +0000, Ian Campbell wrote:
> On Wed, 2011-03-02 at 13:12 +0000, Ian Campbell wrote:
> >
> > > I believe that not much has changed in this regard between 2.6.32
> > and net-next.
> >
> > It turns out I cannot reproduce with either 2.6.32 (pvops xen.git) or
> > a more recent ((26.38-rc) kernel. The kernel where we see this is the
> > XCP kernel which is a 2.6.32 based thing derived from SLES11SP1 + XCP
> > specific updates.
>
> Paul reminded me that his XCP system where we see this is running
> openvswitch not bridging (all my own tests were with bridging), is this
> something which could be caused by vswitch at all? I don't see any
> interesting ->frag_list usage in openvswitch.git.
>
> Anyway I'm going to see if I can repro with vswitch.
It seems that was the key.
Using openvswitch.git aae3743bf24cd0e14be726c774a0be49ff0459d7 on top of
2.6.38-rc7 (+ some Xen stuff from linux-next and my netback branch). I
added:
WARN_ONCE(skb_shinfo(skb)->frag_list, "skb %p has a frag list\n", skb)
to netback's start_xmit and saw it trigger (full trace below).
I've added ovs-dev, you guys can see the complete thread at
http://thread.gmane.org/gmane.linux.network/187720 . The gist is that we
are seeing skb's passed to a driver's start_xmit which have a
->frag_list despite not advertising NETIF_F_FRAGLIST. The netback device
has GSO but not TSO enabled.
(aae3743bf24cd0e14be726c774a0be49ff0459d7 is from the end of January but
it does appear to be the current master, I guess it's a recently rebased
+pushed old commit).
Cheers,
Ian.
------------[ cut here ]------------
WARNING: at /local/scratch/ianc/devel/kernels/linux-2.6/drivers/net/xen-netback/interface.c:84 xenvif_start_xmit+0x109/0x120()
Hardware name: PowerEdge 860
skb cfa14c80 has a frag list
Modules linked in: openvswitch_mod
Pid: 0, comm: swapper Not tainted 2.6.38-rc7-x86_32p-xen0-00190-g0716c28-dirty #375
Call Trace:
[<c12bfbf9>] ? xenvif_start_xmit+0x109/0x120
[<c103f17c>] ? warn_slowpath_common+0x6c/0xa0
[<c12bfbf9>] ? xenvif_start_xmit+0x109/0x120
[<c103f22e>] ? warn_slowpath_fmt+0x2e/0x30
[<c12bfbf9>] ? xenvif_start_xmit+0x109/0x120
[<c13500d4>] ? dev_hard_start_xmit+0x2c4/0x5a0
[<c134fe58>] ? dev_hard_start_xmit+0x48/0x5a0
[<c13639ec>] ? sch_direct_xmit+0x12c/0x230
[<c142be5a>] ? _raw_spin_lock+0x3a/0x40
[<c13505de>] ? dev_queue_xmit+0x22e/0x7a0
[<c13503b0>] ? dev_queue_xmit+0x0/0x7a0
[<f8c77ab7>] ? netdev_send+0x17/0x20 [openvswitch_mod]
[<f8c755a0>] ? vport_send+0x40/0x100 [openvswitch_mod]
[<c100790a>] ? xen_force_evtchn_callback+0x1a/0x30
[<c10080f0>] ? xen_restore_fl_direct+0x0/0x17
[<f8c6d70b>] ? execute_actions+0x62b/0x7f0 [openvswitch_mod]
[<c106b0d2>] ? mark_held_locks+0x62/0x80
[<c106b3f2>] ? trace_hardirqs_on_caller+0xa2/0x1f0
[<f8c726b3>] ? flow_used+0x63/0x90 [openvswitch_mod]
[<c1044fb4>] ? local_bh_enable_ip+0xa4/0x110
[<c142c5b5>] ? _raw_spin_unlock_bh+0x25/0x30
[<f8c726b3>] ? flow_used+0x63/0x90 [openvswitch_mod]
[<f8c6f0aa>] ? dp_process_received_packet+0x8a/0x200 [openvswitch_mod]
[<c10450b6>] ? local_bh_enable+0x96/0x110
[<c106b3f2>] ? trace_hardirqs_on_caller+0xa2/0x1f0
[<f8c756ec>] ? vport_receive+0x8c/0xa0 [openvswitch_mod]
[<f8c756a7>] ? vport_receive+0x47/0xa0 [openvswitch_mod]
[<f8c77bcf>] ? netdev_frame_hook+0xaf/0xe0 [openvswitch_mod]
[<c134dff5>] ? __netif_receive_skb+0x185/0x340
[<c134dee2>] ? __netif_receive_skb+0x72/0x340
[<c1008114>] ? check_events+0x8/0xc
[<f8c77b20>] ? netdev_frame_hook+0x0/0xe0 [openvswitch_mod]
[<c134edbb>] ? netif_receive_skb+0xcb/0xe0
[<c134ed0a>] ? netif_receive_skb+0x1a/0xe0
[<c134ef0f>] ? napi_gro_complete+0x3f/0x110
[<c134ef18>] ? napi_gro_complete+0x48/0x110
[<c134f140>] ? dev_gro_receive+0x160/0x280
[<c134f057>] ? dev_gro_receive+0x77/0x280
[<c134f41b>] ? napi_gro_receive+0xcb/0xe0
[<c12aae75>] ? tg3_poll_work+0x5e5/0xda0
[<c106b0d2>] ? mark_held_locks+0x62/0x80
[<c100790a>] ? xen_force_evtchn_callback+0x1a/0x30
[<c100790a>] ? xen_force_evtchn_callback+0x1a/0x30
[<c10080f0>] ? xen_restore_fl_direct+0x0/0x17
[<c1008114>] ? check_events+0x8/0xc
[<c100810b>] ? xen_restore_fl_direct_end+0x0/0x1
[<c100790a>] ? xen_force_evtchn_callback+0x1a/0x30
[<c10080f0>] ? xen_restore_fl_direct+0x0/0x17
[<c11d08f0>] ? xen_swiotlb_unmap_page+0x0/0x20
[<c142c5f1>] ? _raw_spin_unlock_irq+0x31/0x40
[<c12ab714>] ? tg3_poll+0x44/0x1d0
[<c134f5fc>] ? net_rx_action+0xcc/0x1a0
[<c134f5fc>] ? net_rx_action+0xcc/0x1a0
[<c1044dbf>] ? __do_softirq+0x9f/0x170
[<c1044d20>] ? __do_softirq+0x0/0x170
<IRQ> [<c1003640>] ? xen_cpuid+0x0/0xa0
[<c1044b45>] ? irq_exit+0x65/0x90
[<c11c5800>] ? xen_evtchn_do_upcall+0x20/0x30
[<c100bc2f>] ? xen_do_upcall+0x7/0xc
[<c1003640>] ? xen_cpuid+0x0/0xa0
[<c10023a7>] ? hypercall_page+0x3a7/0x1010
[<c10079f2>] ? xen_safe_halt+0x12/0x30
[<c1003640>] ? xen_cpuid+0x0/0xa0
[<c1012d30>] ? default_idle+0x40/0xa0
[<c100a769>] ? cpu_idle+0x59/0xa0
[<c1408d71>] ? rest_init+0xa1/0xb0
[<c1408cd0>] ? rest_init+0x0/0xb0
[<c10080e0>] ? xen_save_fl_direct+0x0/0xd
[<c1613a25>] ? start_kernel+0x37c/0x399
[<c1613467>] ? unknown_bootoption+0x0/0x1f1
[<c16130b7>] ? i386_start_kernel+0xa6/0xe2
[<c161676a>] ? xen_start_kernel+0x5fc/0x6b2
---[ end trace 877717720328b880 ]---
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox