* Re: [patch net-next-2.6] bonding: remove skb_share_check in handle_frame
From: Jiri Pirko @ 2011-03-02 12:29 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, davem, fubar, eric.dumazet, nicolas.2p.debian
In-Reply-To: <20110302100354.GB2858@psychotron.brq.redhat.com>
Wed, Mar 02, 2011 at 11:03:55AM CET, jpirko@redhat.com wrote:
>Tue, Mar 01, 2011 at 09:38:43PM CET, andy@greyhouse.net wrote:
>>On Tue, Mar 01, 2011 at 10:29:07AM +0100, Jiri Pirko 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.
>>>
>>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>> ---
>>> drivers/net/bonding/bond_main.c | 3 ---
>>> 1 files changed, 0 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>>> index 584f97b..367ea60 100644
>>> --- a/drivers/net/bonding/bond_main.c
>>> +++ b/drivers/net/bonding/bond_main.c
>>> @@ -1498,9 +1498,6 @@ static struct sk_buff *bond_handle_frame(struct sk_buff *skb)
>>> struct net_device *slave_dev;
>>> struct net_device *bond_dev;
>>>
>>> - skb = skb_share_check(skb, GFP_ATOMIC);
>>> - if (unlikely(!skb))
>>> - return NULL;
>>> slave_dev = skb->dev;
>>> bond_dev = ACCESS_ONCE(slave_dev->master);
>>> if (unlikely(!bond_dev))
>>> --
>>> 1.7.3.4
>>>
>>
>>Why did you decide to get rid of it here rather than the 3 places in the
>>bonding driver where it is currently needed? I think this can cover
>>those cases since bond_handle_frame will be called after the ptype_all
>>handlers before any of the ptype handlers.
>
>I have already a patch prepared which converts bond ptype handlers into
>being called from bond_handle_frame. You are propably right that this
>should probably stay here.
>
>So please Dave, drop this patch for now. Thanks.
Thinking about this more I'm pretty convinced that skb_share_check is
not needed here.
If I got that correctly, skb_share_check is neede when user acually
modifies skb for his needs only. On the other hand, the only change
to skb is setting skb->dev and this change needs to be visible later on.
And given that skb is returned at the end of the function, changes are
never local (makes sense).
^ permalink raw reply
* Re: [PATCH net-2.6] bonding: drop frames received with master's source MAC
From: Herbert Xu @ 2011-03-02 12:30 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jay Vosburgh, Andy Gospodarek, netdev, David Miller, Jiri Pirko
In-Reply-To: <AANLkTi=QTDNBf7Jskj55NP64Os8kgEs1WMpFGHMo+K3B@mail.gmail.com>
On Wed, Mar 02, 2011 at 11:10:07AM +0100, Nicolas de Pesloüan wrote:
>
> If one decide to configure two interfaces with the same MAC and connect them
> to the same LAN, then we get the exact same situation. Having eth0 and eth1
> share a single MAC and a single IP address, connected to a switch in
> Etherchannel mode is a perfectly valid setup, while suboptimal. And if the
> Etherchannel mode happens to be improperly configured, we end up with the
> same problem as reported by Andy.
Right. There's also the case where you have other MAC addresses
sitting behind the bonding device, e.g., virtualisation. So basing
it purely on the bonding device's MAC address is probably not worth
the trouble.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/4] slub,rcu: don't assume the size of struct rcu_head
From: Christoph Lameter @ 2011-03-02 12:32 UTC (permalink / raw)
To: Hugh Dickins
Cc: Pekka Enberg, Lai Jiangshan, Ingo Molnar, Paul E. McKenney,
Eric Dumazet, David S. Miller, Matt Mackall, linux-mm,
linux-kernel, netdev
In-Reply-To: <AANLkTim0Zjc7c9-7LCnEaYpV5PVN=5fNQpjMYqtZe-fk@mail.gmail.com>
On Tue, 1 Mar 2011, Hugh Dickins wrote:
> > Struct page may be larger for debugging purposes already because of the
> > need for extended spinlock data.
>
> That was so for a long time, but I stopped it just over a year ago
> with commit a70caa8ba48f21f46d3b4e71b6b8d14080bbd57a, stop ptlock
> enlarging struct page.
Strange. I just played around with in in January and the page struct size
changes when I build kernels with full debugging. I have some
cmpxchg_double patches here that depend on certain alignment in the page
struct. Debugging causes all that stuff to get out of whack so that I had
to do some special patches to make sure fields following the spinlock are
properly aligned when the sizes change.
> If a union leads to "random junk" overwriting the page->mapping field
> when the page is reused, and that junk could resemble the pointer in
> question, then KSM would mistakenly think it still owned the page.
> Very remote chance, and maybe it amounts to no more than a leak. But
> I'd still prefer we keep page->mapping for pointers (sometimes with
> lower bits set as flags).
DESTROY BY RCU uses the lru field which follows the mapping field in page
struct. Why would random junk overwrite the mapping field?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: skb->frag_list != NULL in start_xmit for device without NETIF_F_FRAGLIST
From: Ian Campbell @ 2011-03-02 13:12 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev@vger.kernel.org, Paul Durrant
In-Reply-To: <AANLkTinDmW1oirOFZCHe7yw8E8TGJfFe+fucAxOPpbjV@mail.gmail.com>
Hi Jesse,
On Tue, 2011-03-01 at 23:41 +0000, Jesse Gross wrote:
> On Tue, Mar 1, 2011 at 3:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > Hi,
> >
> > We are seeing cases where Xen netback's start_xmit is being passed an
> > skb which has a ->frag_list, despite the driver not advertising the
> > NETIF_F_FRAGLIST feature.
> >
> > Is this indicative of a problem somewhere? Are drivers expected to
> > handle a frag_list? grepping for frag_list in drivers/net it appears not
> > many drivers do anything with the frag_list.
>
> It certainly sounds like a problem to me. Off the top of my head I
> don't know of any drivers that actually set and handle
> NETIF_F_FRAGLIST (except for pseudo-devices like bridging).
That's basically all I found with grep too.
> > The netback driver is bridged with a tg3 physical device and we think
> > the problematic skb's are originating on the wire.
> >
> > The case we are actually seeing is with 2.6.32 + tg3 3.110g so obviously
> > the next step is to reproduce on a more modern kernel and the in-tree
> > driver and then to attempt to determine if the fault is in what the
> > physical interface's driver is passing up the stack or in the stack's
> > handling of those skbs. Any hints on where to look would be much
> > appreciated.
>
> I'd guess that the most likely source of frag_lists generated here are
> from GRO, in skb_gro_receive(). The driver/NIC can definitely
> influence the strategy that GRO uses for reassembly but it seems less
> likely that the driver itself will create frag_lists.
Agreed, I cant see anywhere in the driver which would do this and
skb_gro_receive does seem like the likely source of the frag list.
> > In particular I'm not sure where the frag_list is supposed to get
> > resolved in the case where dev_hard_start_xmit takes the netif_needs_gso
> > == true path and calls dev_gso_segment rather than taking the
> > __skb_linearize path (the issue appears to occur only when the netback
> > device has NETIF_F_GSO but not NETIF_F_TSO). AFAICT dev_gso_segment goes
> > to tcp_tso_segment and then to skb_segment which does appear to create
> > skbs with a frag_list (although it's not outside the realms of
> > possibility that I'm reading it wrong).
>
> I'm fairly certain that the problem is in skb_segment(). It's not the
> most tolerant of skbs with frag_lists that do not line up with the
> requested mss. Depending on how the original skb is laid out,
> sometimes this will trigger a BUG_ON and sometimes it creates new
> frag_lists. Since there are no further checks after GSO, the skb with
> a frag_list will get passed to the driver, even if it is not
> supported.
I wondered if that was the case, but skb_segment made my head spin a
bit ;-)
Do you think there might be a case for adding a some skb_needs_linearize
and __skb_linearize calls on the netif_needs_gso paths too, perhaps with
some WARN_ON's?
The first check in skb_needs_linearize looks at skb->data_len, I thought
skb->data_len only covered the paged fragments but the conditions in
skb_needs_linearize seem to imply that it covers the frag_list length
too? Was I simply mistaken?
FWIW an example of the sort of thing we see is:
skb: len=0x59a, data_len=0x55a, headlen=64 (matches tail-data), no paged
frags
skb->frag_list: len=0x55a, data_len=0, headlen=0x55a (matches
tail-data), no paged frags
> 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.
I looked through the diff of net/core and net/ipv4 between a reproducing
and non-reproducing kernel and didn't see anything glaringly obvious.
Anyway, since I can't reproduce on a mainline kernel I'll stop bothering
you all with it.
Ian.
^ permalink raw reply
* 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
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