* Re: Fw: [Bug 54281] New: kernel NULL pointer dereference on deleting a vlan interface
From: Cong Wang @ 2013-02-24 4:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130223072603.594c45e1@samsung-9>
On Sat, 23 Feb 2013 at 15:26 GMT, Stephen Hemminger <stephen@networkplumber.org> wrote:
> # ip link del em1.57
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<ffffffffa03c356f>] garp_uninit_applicant+0x2f/0xd0 [garp]
> PGD 47ce2f1067 PUD 47cbc15067 PMD 0
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/system/cpu/cpu23/cache/index2/shared_cpu_map
> CPU 15
> Modules linked in: bridge xt_comment ipt_LOG xt_limit fuse bonding 8021q garp
> stp llc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables
> ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack
> ip6table_filter ip6_tables ipv6 xfs exportfs power_meter dcdbas microcode
> sb_edac edac_core iTCO_wdt iTCO_vendor_support shpchp sg tg3 ext4 mbcache jbd2
> sr_mod cdrom sd_mod crc_t10dif ahci wmi megaraid_sas dm_mirror dm_region_hash
> dm_log dm_mod [last unloaded: speedstep_lib]
>
> Pid: 27564, comm: ip Not tainted 2.6.32-279.el6.x86_64 #1 Dell Inc. PowerEdge
> R720/0VWT90
> RIP: 0010:[<ffffffffa03c356f>] [<ffffffffa03c356f>]
> garp_uninit_applicant+0x2f/0xd0 [garp]
> RSP: 0018:ffff8847ce2e38a8 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: ffff8823cdc8e020 RCX: ffff8847cc6c0080
> RDX: ffffffff81b12200 RSI: ffffffffa03cfa20 RDI: ffff8823cdc8e020
> RBP: ffff8847ce2e38c8 R08: ffffffff81b12200 R09: 00000000ffffffff
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8823cdc8e020
> R13: ffffffffa03cfa20 R14: 0000000000000000 R15: ffff8823cdab26c0
> FS: 00007fe26eef1700(0000) GS:ffff8824aece0000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 00000047cce94000 CR4: 00000000000406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process ip (pid: 27564, threadinfo ffff8847ce2e2000, task ffff8847cc6c0080)
> Stack:
> ffff8823cdc8e020 0000000000000039 ffff8847cf7b4020 ffffffffa0141d80
><d> ffff8847ce2e38d8 ffffffffa03ce085 ffff8847ce2e3918 ffffffffa03cb420
><d> 00000000ffffffa6 ffffffff8200cec0 ffff8847cc914810 0000000000000001
> Call Trace:
> [<ffffffffa03ce085>] vlan_gvrp_uninit_applicant+0x15/0x20 [8021q]
> [<ffffffffa03cb420>] unregister_vlan_dev+0xf0/0x190 [8021q]
> [<ffffffff81448ae0>] rtnl_dellink+0xd0/0x110
> [<ffffffff81448837>] rtnetlink_rcv_msg+0x177/0x290
> [<ffffffff814486c0>] ? rtnetlink_rcv_msg+0x0/0x290
> [<ffffffff81463df9>] netlink_rcv_skb+0xa9/0xd0
> [<ffffffff814486a5>] rtnetlink_rcv+0x25/0x40
> [<ffffffff81463a56>] netlink_unicast+0x2e6/0x300
> [<ffffffff814643e0>] netlink_sendmsg+0x200/0x2e0
> [<ffffffff81428003>] sock_sendmsg+0x123/0x150
> [<ffffffff810920d0>] ? autoremove_wake_function+0x0/0x40
> [<ffffffff81427c24>] ? move_addr_to_kernel+0x64/0x70
> [<ffffffff81429b56>] __sys_sendmsg+0x406/0x420
> [<ffffffff8104452c>] ? __do_page_fault+0x1ec/0x480
> [<ffffffff8114328b>] ? vma_link+0x9b/0xf0
> [<ffffffff811453bc>] ? do_brk+0x26c/0x350
> [<ffffffff81429d79>] sys_sendmsg+0x49/0x90
> [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b
> Code: 48 83 ec 20 48 89 1c 24 4c 89 64 24 08 4c 89 6c 24 10 4c 89 74 24 18 0f
> 1f 44 00 00 8b 06 4c 8b b7 28 04 00 00 49 89 fc 49 89 f5 <49> 8b 1c c6 e8 38 46
> 08 e1 85 c0 74 6f 41 8b 45 00 49 c7 04 c6
> RIP [<ffffffffa03c356f>] garp_uninit_applicant+0x2f/0xd0 [garp]
> RSP <ffff8847ce2e38a8>
> CR2: 0000000000000000
>
I think we miss some locking...
-----
diff --git a/net/802/garp.c b/net/802/garp.c
index 1dcb066..5f72212 100644
--- a/net/802/garp.c
+++ b/net/802/garp.c
@@ -611,8 +611,10 @@ void garp_uninit_applicant(struct net_device
*dev, struct garp_application *appl
/* Delete timer and generate a final TRANSMIT_PDU event to
flush out
* all pending messages before the applicant is gone. */
del_timer_sync(&app->join_timer);
+ spin_lock_bh(&app->lock);
garp_gid_event(app, GARP_EVENT_TRANSMIT_PDU);
garp_pdu_queue(app);
+ spin_unlock_bh(&app->lock);
garp_queue_xmit(app);
dev_mc_delete(dev,appl->proto.group_address, ETH_ALEN, 0);
^ permalink raw reply related
* Re: [PATCH 2/2] vlan: adjust vlan_set_encap_proto() for its callers
From: David Miller @ 2013-02-24 2:01 UTC (permalink / raw)
To: jesse; +Cc: amwang, netdev
In-Reply-To: <CAEP_g=_eWXuR_3zUYsbBiAjaCJQjRpSmUypqpJe5_jwN=rmM0Q@mail.gmail.com>
From: Jesse Gross <jesse@nicira.com>
Date: Fri, 22 Feb 2013 17:05:01 -0800
> On Fri, Feb 22, 2013 at 1:32 AM, Cong Wang <amwang@redhat.com> wrote:
>> From: Cong Wang <amwang@redhat.com>
>>
>> There are two places to call vlan_set_encap_proto():
>> vlan_untag() and __pop_vlan_tci().
>>
>> vlan_untag() assumes skb->data points after mac addr, otherwise
>> the following code
>>
>> vhdr = (struct vlan_hdr *) skb->data;
>> vlan_tci = ntohs(vhdr->h_vlan_TCI);
>> __vlan_hwaccel_put_tag(skb, vlan_tci);
>>
>> skb_pull_rcsum(skb, VLAN_HLEN);
>>
>> won't be correct. But __pop_vlan_tci() assumes points _before_
>> mac addr.
>>
>> In vlan_set_encap_proto(), it looks for some magic L2 value
>> after mac addr:
>>
>> rawp = skb->data;
>> if (*(unsigned short *) rawp == 0xFFFF)
>> ...
>>
>> Therefore __pop_vlan_tci() is obviously wrong.
>>
>> A quick fix is avoiding using skb->data in vlan_set_encap_proto(),
>> use 'vhdr+1' is always correct in both cases.
>>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Jesse Gross <jesse@nicira.com>
>> Signed-off-by: Cong Wang <amwang@redhat.com>
>
> Acked-by: Jesse Gross <jesse@nicira.com>
Applied, thanks.
^ permalink raw reply
* Re: AF_VSOCK and the LSMs
From: Casey Schaufler @ 2013-02-23 23:43 UTC (permalink / raw)
To: Paul Moore
Cc: netdev, linux-security-module, selinux, Andy King, Gerd Hoffmann,
Eric Paris, Casey Schaufler
In-Reply-To: <1968537.V0Fsdryuo8@sifl>
On 2/22/2013 4:45 PM, Paul Moore wrote:
> On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
>> Please add an LSM blob. Please do not use a secid. I am currently
>> battling with secids in my efforts for multiple LSM support.
>>
>> ...
>>
>> I am going to be able to deal with secids for AF_INET only because
>> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
>> be willing to have networking be optional.
> "prefers"? Really Casey, did you think I would let you get away with that
> statement? What a LSM "prefers" is really not relevant to the stacking
> effort, what a LSM _supports_ is what matters.
I suppose. My point, which you may refute if it is incorrect,
is that there are common, legitimate SELinux configurations which
eschew Netlabel in favor of XFRM.
> SELinux _supports_ NetLabel (CIPSO, etc.), XFRM (labeled IPsec), and secmark.
>
> Smack _supports_ NetLabel (CIPSO).
>
> AppArmor and TOMOYO don't really do any of the forms of labeled networking
> that are relevant for this discussion.
I am informed that labeled networking is being developed as an
option for AppArmor.
> If you are going to do stacking with
> LSMs that conflict when it comes to what they _support_, not what they
> _prefer_, with labeled networking then you are either going to have to either:
>
> 1. Selectively remove support from all but one of the LSMs. (ungh ...)
> 2. Convince netdev to give you a blob in the sk_buff. (the pigs are flying!)
> 3. Work some sub-system dependent magic.
With those being the possibilities, the choice is pretty obvious.
(It's 3, just in case the reader is unfamiliar with the histories
involved)
> If you want to try option #3 I think we might be able to do something with
> NetLabel to support multiple LSMs as the label abstraction stuff should
> theoretically make this possible; although the NetLabel cache will need some
> work.
It is reasonably easy to restrict Netlabel to a single LSM,
and since SELinux seems better served by XFRM in most configurations
and AppArmor intends to make networking an option that seems
like a viable strategy until Netlabel gets multiple LSM support.
> Labeled IPsec is likely out due to the way it was designed unless you
> want to attempt to negotiate two labels during the IKE exchange (yuck). I
> think we can also rule out secmark as multi-LSM enabled due to the limitations
> on a 32 bit integer.
That was my take as well. But, since only SELinux uses those currently,
and I see little pressure for Smack to support them I don't have
a lot of incentive in that direction.
> If you want to talk about this further let me know - I think we've talked
> about this at the past two security summits - but don't attempt to gloss over
> details with this "prefers" crap.
Sorry if I presented my position poorly. I'm not trying to
gloss over details, and I apologize if I gave offense or made
statements that disrupted the harmony of the community.
>
>> If you have two LSMs that use secids you are never going to have a
>> rational way to get the information for both into one secid.
> Exactly, I don't disagree which is why I've always said that networking was
> going to be a major problem for the stacked LSM effort. Unfortunately it
> sounds like you haven't yet made any serious effort into resolving that
> problem other than saying "don't do that".
Oh believe me, I have made serious effort. I just haven't made
significant progress. The good news is that there can be a
networking configuration (SELinux with XFRM, Smack with Netlabel,
AppArmor with none) that is both supported and rational.
Options I have considered include:
- Netlabel support for discriminating LSM use by host,
just as it currently allows for unlabeled hosts.
- Netlabel as an independent LSM. Lots of refactoring.
- secid maps.
- Remove secids completely in favor of blobs.
I should have an updated patch set by month's end. I think it
will address the current LSM issues. I don't know that I can
say it will address everything new LSMs might want to try.
> Now, circling back to the issue of secid/blob in the AF_VSOCK/VMCI context ...
> based on Andy's email I think I'm still missing some critical bit of
> understanding regarding how VMCI is used so let's punt on this for a moment;
> however, your preference for a blob is noted (you also remember that I prefer
> blobs when they make sense, reference a lot of our earlier discussions).
Indeed. Thank you. A blob can contain sub-blobs. A secid is just
a number at the whim of an LSM.
Thanks. Sorry 'bout the whole "prefer" bruhaha.
^ permalink raw reply
* Re: [PATCH v2 1/5] drivers: phy: add generic PHY framework
From: Rob Landley @ 2013-02-23 22:44 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: tony, linux, eballetbo, javier, kishon, balbi, gregkh, akpm,
mchehab, cesarb, davem, arnd, santosh.shilimkar, broonie, swarren,
linux-doc, linux-kernel, linux-arm-kernel, linux-omap, linux-usb,
netdev
In-Reply-To: <1361253198-7401-2-git-send-email-kishon@ti.com>
On 02/18/2013 11:53:14 PM, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference
> to the
> PHY with or without using phandle. To obtain a reference to the PHY
> without
> using phandle, the platform specfic intialization code (say from
> board file)
> should have already called phy_bind with the binding information. The
> binding
> information consists of phy's device name, phy user device name and
> an index.
> The index is used when the same phy user binds to mulitple phys.
Given that this has a separately selectable config option, I'm guessing
that it's useful all by itself even in the absence of a driver using
this phy? (Or it gives user visibility to the phy buried in an E1000 or
SATA drive or some such?)
> +1. Introduction
> +
> +*PHY* is the abbreviation for physical layer. It is used to connect
> a device
> +to the physical medium e.g., the USB controller has a PHY to provide
> functions
> +such as serialization, de-serialization, encoding, decoding and is
> responsible
> +for obtaining the required data transmission rate. Note that some USB
> +controller has PHY functionality embedded into it and others use an
> external
> +PHY. Other peripherals that uses a PHY include Wireless LAN,
> Ethernet,
> +SATA etc.
I've usually heard the word "transciever" used to describe these.
> +The intention of creating this framework is to bring the phy drivers
> spread
> +all over the Linux kernel to drivers/phy to increase code re-use and
> to
> +increase code maintainability.
> +
> +This framework will be of use only to devices that uses external PHY
> (PHY
> +functionality is not embedded within the controller).
> +
> +2. Creating the PHY
> +
> +The PHY driver should create the PHY in order for other peripheral
> controllers
> +to make use of it. The PHY framework provides 2 APIs to create the
> PHY.
Given that a PHY is a chip (random example
http://ark.intel.com/products/47620/Intel-82579LM-Gigabit-Ethernet-PHY),
you seem to be saying that software should manifest a piece of hardware
out of thin air through sheer willpower. I'm pretty sure I've
misunderstood this phrasing.
> +struct phy *phy_create(struct device *dev, struct phy_descriptor
> *desc);
> +struct phy *devm_phy_create(struct device *dev, struct
> phy_descriptor *desc);
> +
> +The PHY drivers can use one of the above 2 APIs to create the PHY by
> passing
Um, the driver should _bind_ to the phy, maybe? Allocate? Initialize?
> +6. Destroying the PHY
I've run drivers like that. I try not to, though.
> +7. Current Status
> +
> +Currently only USB in OMAP is made to use this framework. However
> using the
> +USB PHY library cannot be completely removed because it is
> intertwined with
> +OTG. Once we move OTG out of PHY completely, using the old PHY
> library can be
> +completely removed. SATA in OMAP will also more likely use this new
> framework
> +and we should have a patch for it soon.
Does this paragraph belong in the documentation? (Git commit, sure, but
I've seen a lot of stale paragraphs like these hang around a
surprisingly long time.)
Rob
^ permalink raw reply
* Re: Disable IPv4-mapped - enforce IPV6_V6ONLY
From: Alexander Holler @ 2013-02-23 20:44 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <51278CF6.2060402@ahsoftware.de>
Am 22.02.2013 16:21, schrieb Alexander Holler:
> Hello,
>
> I'm searching for a way to either enforce IPV6_V6ONLY or to block
> IPv4-mapped addresses on ipv6-sockets (e.g. by using iptables) system-wide.
>
> E.g. net.ipv6.bindv6only doesn't help if something calls
>
> int v6on = 0;
> setsockopt(sd, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&v6on, sizeof(v6on))
>
> In such a case I still want to disable or block IPv4-mapped addresses on
> that socket, even if the program thinks it nows it better.
>
> Until now I haven't found a solution.
I've now done it by the following hack:
-----------
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index d1e2e8e..9eefd3e 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -235,7 +235,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int
level, int optname,
if (optlen < sizeof(int) ||
inet_sk(sk)->inet_num)
goto e_inval;
- np->ipv6only = valbool;
+ np->ipv6only = valbool || net->ipv6.sysctl.bindv6only;
retv = 0;
break;
-----------
A proper solution would be to either return false if net.ipv6.bindv6only
is true and optval is false (which would break downward compatibility
because it wouldn't just be a default and setsockopt might return an
error) or to introduce a new sysctl variable like
net.ipv6.bindv6only_enforced_silently. ("silently" because setsockopt()
wouldn't return an error if net.ipv6.bindv6only is true and optval
(v6only in the example above) is false.)
I would volunteer to write a patch which introduces something like
net.ipv6.bindv6only_enforced_silently if some maintainer would give me
his ok.
If so, the question remains if
systemctl net.ipv6.bindv6only_enforced_silently = 1
should set systemctl.net.ipv6.bindv6only too or if an error should be
returned if net.ipv6.bindv6only is false.
Regards,
Alexander
^ permalink raw reply related
* Re: [PATCH v2 0/5] Generic PHY Framework
From: Rob Landley @ 2013-02-23 20:05 UTC (permalink / raw)
To: balbi
Cc: Arnd Bergmann, balbi, kishon, tony, linux, eballetbo, javier,
gregkh, akpm, mchehab, cesarb, davem, santosh.shilimkar, broonie,
swarren, linux-doc, linux-kernel, linux-arm-kernel, linux-omap,
linux-usb, netdev
In-Reply-To: <20130219150500.GG4390@arwen.pp.htv.fi>
On 02/19/2013 09:05:00 AM, Felipe Balbi wrote:
> Greg, can you pitch your suggestion here ? It would be great to hear
> your rationale behind dropping class infrastructure, couldn't find
> anything through Google and since feature-removal-schedule.txt has
> been
> removed (without adding it to feature-removal-schedule.txt, I must add
> :-) I don't know what's the idea behind removing classes.
I actually went through and poked a couple of people about old entries
in feature-removal-shedule.txt last year, but I haven't been very
active since the kernel.org breakin because my account got disabled,
and I needed to meet kernel developers in person to get keys signed to
get it switched back on (or set up a separate git tree with signed
commits -next could pull from).
I don't get out much; as a consultant I have to take time off from work
and pay for my own travel and lodging. So I've been to exactly two
conferences in the past 3 years: last year's Texas Linux Fest (my house
got broken into and a netbook with the key on it stolen the following
wednesday), and CELF (which I'm on the plane back from now, Greg KH
signed my key! Woo!).
If I can use that to get my account back, set up a tree feeding into
linux-next, and maybe even recover the ability to update
http://kernel.org/doc, I'd happily field some sort of
feature-removal-schedule list and make sure it stays current. (Linus
didn't ask me about removing the old one, I found out about it from the
git log. But I can't blame him, I haven't exactly been tearing through
the bureaucracy to get my access back. "Volunteer work" and "painful"
tend not to combine well on my todo list in terms of scheduling
priority...)
Rob
^ permalink raw reply
* Re: [PATCH 1/2] sock_diag: Fix out-of-bounds access to sock_diag_handlers[]
From: Mathias Krause @ 2013-02-23 19:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev, Dave Jones
In-Reply-To: <1361640939.6781.3.camel@edumazet-glaptop>
On Sat, Feb 23, 2013 at 6:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sat, 2013-02-23 at 12:13 +0100, Mathias Krause wrote:
>> Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY
>> with a family greater or equal then AF_MAX -- the array size of
>> sock_diag_handlers[]. The current code does not test for this
>> condition therefore is vulnerable to an out-of-bound access opening
>> doors for a privilege escalation.
>>
>> Signed-off-by: Mathias Krause <minipli@googlemail.com>
>> ---
>> net/core/sock_diag.c | 3 +++
>> 1 file changed, 3 insertions(+)
>
> Thanks for fixing this.
>
> It seems trinity didnt catch it !
For trinity to catch that one, trinity needs to generate a valid
netlink request on a PF_NETLINK socket with protocol
NETLINK_SOCK_DIAG. Very unlikely. Especially the sanity checks in
netlink_rcv_skb() will probably filter invalid messages before they
reach any interesting code. But if trinity would have support for
generating netlink messages, then, yes, it should probably have found
that bug easily. It's in there for ages, now ;)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
>
>
Thanks,
Mathias
^ permalink raw reply
* Re: [PATCH 0/2] net: sock_diag fixes
From: David Miller @ 2013-02-23 18:54 UTC (permalink / raw)
To: minipli; +Cc: netdev
In-Reply-To: <1361618028-9024-1-git-send-email-minipli@googlemail.com>
From: Mathias Krause <minipli@googlemail.com>
Date: Sat, 23 Feb 2013 12:13:46 +0100
> Hi Dave,
>
> this small series fixes an exploitable bug in sock_diag. An unprivileged
> user can send us a netlink message resulting in an out-of-bounds access
> that allows userland to take over control while in kernel mode.
>
> The first patch fixes the bug and should be pushed to stable. The second
> one is an attempt to cleanup the sock_diag_handlers[] access mess in
> __sock_diag_rcv_msg.
>
> Please apply!
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] vxlan: remove depends on CONFIG_EXPERIMENTAL
From: David Miller @ 2013-02-23 18:54 UTC (permalink / raw)
To: keescook; +Cc: linux-kernel, shemminger, gregkh, netdev
In-Reply-To: <20130223072538.GA4770@www.outflux.net>
From: Kees Cook <keescook@chromium.org>
Date: Fri, 22 Feb 2013 23:25:38 -0800
> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> while now and is almost always enabled by default. As agreed during the
> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Applied.
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix allocation of CPU affinity reverse-map
From: David Miller @ 2013-02-23 18:54 UTC (permalink / raw)
To: klebers; +Cc: amirv, netdev
In-Reply-To: <1361596492-10565-1-git-send-email-klebers@linux.vnet.ibm.com>
From: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Date: Sat, 23 Feb 2013 02:14:52 -0300
> The mlx4_en driver allocates the number of objects for the CPU affinity
> reverse-map based on the number of rx rings of the device. However,
> mlx4_assign_eq() calls irq_cpu_rmap_add() as many times as IRQ's are
> assigned to EQ's, which can be as large as mlx4_dev->caps.comp_pool. If
> caps.comp_pool is larger than rx_ring_num we will eventually hit the
> BUG_ON() in cpu_rmap_add().
>
> Fix this problem by allocating space for the maximum number of CPU
> affinity reverse-map objects we might want to add.
>
> Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix allocation of device tx_cq
From: David Miller @ 2013-02-23 18:54 UTC (permalink / raw)
To: klebers; +Cc: amirv, netdev
In-Reply-To: <1361581082-5583-1-git-send-email-klebers@linux.vnet.ibm.com>
From: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Date: Fri, 22 Feb 2013 21:58:02 -0300
> The memory to hold the network device tx_cq is not being allocated with
> the correct size in mlx4_en_init_netdev(). It should use MAX_TX_RINGS
> instead of MAX_RX_RINGS. This can cause problems if the number of tx
> rings being used is greater than MAX_RX_RINGS.
>
> Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Problem with multicast traffic when using network bridging
From: Adam Baker @ 2013-02-23 18:18 UTC (permalink / raw)
To: herbert; +Cc: Stephen Hemminger, bridge, netdev
After upgrading the kernel on the box that acts as a bridge between my
wireless and wired networks I observed that access to my UPnP media
servers became unreliable.
I tried a number of kernel versions to attempt to establish when things
went wrong and got as far as
3.4 - works
3.5.7 - doesn't work
3.6.11 - doesn't work
3.7.1 - doesn't work
3.7.6 - doesn't work
I can test other versions if required but it doesn't always fail
instantly and sometimes takes several hours before I notice it has
failed so don't expect a quick response
All of the above are built with
CONFIG_BRIDGE_IGMP_SNOOPING=y
Knowing that I wasn't having problems with other traffic and the UPnP
was the only protocol I use that relies on multicast I started looking
at what changed in the file net/bridge/br_multicast.c and found the patch
bridge: Add multicast_querier toggle and disable queries by default
http://patchwork.ozlabs.org/patch/152295/
so tried
echo 1 >/sys/class/net/br0/bridge/multicast_querier
and after 48 hours of testing running kernel 3.7.6 it seems to be
working reliably.
Whilst setting that value manually at boot time would be adequate to
meet my needs it is reasonable to assume that vendors will build
wireless access points using new kernels that would also exhibit this
behaviour and users may not be able to get at the internals easily to
change this configuration.
I therefore suspect that the assumption this patch makes that generating
queries in the bridge is only an optimisation and isn't necessary isn't
universally true.
Other details about my network configuration that may be relevant:
There are 2 UPnP media servers, one on the bridge machine and one on a
machine on the wired network
There are 1 or 2 UPnP media control point / renderers, both on the
wireless network
As I'm not using multicast on offsite links the IGMP proxy setting is
disabled on my ADSL router (which is connected to the wired network)
Things I think are irrelevant but I'll mention just in case:
Bridge machine is a Marvell Kirkwood ARM5TE CPU
The wired network includes some homeplug connections
Have I done something unreasonable with my configuration or have I found
a bug?
Thanks
Adam Baker
^ permalink raw reply
* (unknown)
From: web_office984.126 @ 2013-02-23 17:38 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 26 bytes --]
please open the attachment
[-- Attachment #2: United Nations Scam Victim Compensation 2013.rtf --]
[-- Type: application/rtf, Size: 1253676 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] sock_diag: Fix out-of-bounds access to sock_diag_handlers[]
From: Eric Dumazet @ 2013-02-23 17:35 UTC (permalink / raw)
To: Mathias Krause; +Cc: David S. Miller, netdev, Dave Jones
In-Reply-To: <1361618028-9024-2-git-send-email-minipli@googlemail.com>
On Sat, 2013-02-23 at 12:13 +0100, Mathias Krause wrote:
> Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY
> with a family greater or equal then AF_MAX -- the array size of
> sock_diag_handlers[]. The current code does not test for this
> condition therefore is vulnerable to an out-of-bound access opening
> doors for a privilege escalation.
>
> Signed-off-by: Mathias Krause <minipli@googlemail.com>
> ---
> net/core/sock_diag.c | 3 +++
> 1 file changed, 3 insertions(+)
Thanks for fixing this.
It seems trinity didnt catch it !
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Fw: [Bug 54281] New: kernel NULL pointer dereference on deleting a vlan interface
From: Stephen Hemminger @ 2013-02-23 15:26 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Fri, 22 Feb 2013 22:31:22 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 54281] New: kernel NULL pointer dereference on deleting a vlan interface
https://bugzilla.kernel.org/show_bug.cgi?id=54281
Summary: kernel NULL pointer dereference on deleting a vlan
interface
Product: Networking
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Fedora
Status: NEW
Severity: high
Priority: P1
Component: Other
AssignedTo: shemminger@linux-foundation.org
ReportedBy: bugs@syam.in
Regression: No
I managed to trigger a NULL pointer dereference by perhaps an incorrect usage
of "ip" tool.
I will be happy to provide more details if necessary. Here is the backtrace for
now.
# ip link del em1.57
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffffa03c356f>] garp_uninit_applicant+0x2f/0xd0 [garp]
PGD 47ce2f1067 PUD 47cbc15067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu23/cache/index2/shared_cpu_map
CPU 15
Modules linked in: bridge xt_comment ipt_LOG xt_limit fuse bonding 8021q garp
stp llc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables
ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack
ip6table_filter ip6_tables ipv6 xfs exportfs power_meter dcdbas microcode
sb_edac edac_core iTCO_wdt iTCO_vendor_support shpchp sg tg3 ext4 mbcache jbd2
sr_mod cdrom sd_mod crc_t10dif ahci wmi megaraid_sas dm_mirror dm_region_hash
dm_log dm_mod [last unloaded: speedstep_lib]
Pid: 27564, comm: ip Not tainted 2.6.32-279.el6.x86_64 #1 Dell Inc. PowerEdge
R720/0VWT90
RIP: 0010:[<ffffffffa03c356f>] [<ffffffffa03c356f>]
garp_uninit_applicant+0x2f/0xd0 [garp]
RSP: 0018:ffff8847ce2e38a8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8823cdc8e020 RCX: ffff8847cc6c0080
RDX: ffffffff81b12200 RSI: ffffffffa03cfa20 RDI: ffff8823cdc8e020
RBP: ffff8847ce2e38c8 R08: ffffffff81b12200 R09: 00000000ffffffff
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8823cdc8e020
R13: ffffffffa03cfa20 R14: 0000000000000000 R15: ffff8823cdab26c0
FS: 00007fe26eef1700(0000) GS:ffff8824aece0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000047cce94000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ip (pid: 27564, threadinfo ffff8847ce2e2000, task ffff8847cc6c0080)
Stack:
ffff8823cdc8e020 0000000000000039 ffff8847cf7b4020 ffffffffa0141d80
<d> ffff8847ce2e38d8 ffffffffa03ce085 ffff8847ce2e3918 ffffffffa03cb420
<d> 00000000ffffffa6 ffffffff8200cec0 ffff8847cc914810 0000000000000001
Call Trace:
[<ffffffffa03ce085>] vlan_gvrp_uninit_applicant+0x15/0x20 [8021q]
[<ffffffffa03cb420>] unregister_vlan_dev+0xf0/0x190 [8021q]
[<ffffffff81448ae0>] rtnl_dellink+0xd0/0x110
[<ffffffff81448837>] rtnetlink_rcv_msg+0x177/0x290
[<ffffffff814486c0>] ? rtnetlink_rcv_msg+0x0/0x290
[<ffffffff81463df9>] netlink_rcv_skb+0xa9/0xd0
[<ffffffff814486a5>] rtnetlink_rcv+0x25/0x40
[<ffffffff81463a56>] netlink_unicast+0x2e6/0x300
[<ffffffff814643e0>] netlink_sendmsg+0x200/0x2e0
[<ffffffff81428003>] sock_sendmsg+0x123/0x150
[<ffffffff810920d0>] ? autoremove_wake_function+0x0/0x40
[<ffffffff81427c24>] ? move_addr_to_kernel+0x64/0x70
[<ffffffff81429b56>] __sys_sendmsg+0x406/0x420
[<ffffffff8104452c>] ? __do_page_fault+0x1ec/0x480
[<ffffffff8114328b>] ? vma_link+0x9b/0xf0
[<ffffffff811453bc>] ? do_brk+0x26c/0x350
[<ffffffff81429d79>] sys_sendmsg+0x49/0x90
[<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b
Code: 48 83 ec 20 48 89 1c 24 4c 89 64 24 08 4c 89 6c 24 10 4c 89 74 24 18 0f
1f 44 00 00 8b 06 4c 8b b7 28 04 00 00 49 89 fc 49 89 f5 <49> 8b 1c c6 e8 38 46
08 e1 85 c0 74 6f 41 8b 45 00 49 c7 04 c6
RIP [<ffffffffa03c356f>] garp_uninit_applicant+0x2f/0xd0 [garp]
RSP <ffff8847ce2e38a8>
CR2: 0000000000000000
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [PATCH 2/2] sock_diag: Simplify sock_diag_handlers[] handling in __sock_diag_rcv_msg
From: Mathias Krause @ 2013-02-23 11:13 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Mathias Krause
In-Reply-To: <1361618028-9024-1-git-send-email-minipli@googlemail.com>
The sock_diag_lock_handler() and sock_diag_unlock_handler() actually
make the code less readable. Get rid of them and make the lock usage
and access to sock_diag_handlers[] clear on the first sight.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
---
net/core/sock_diag.c | 24 +++++++-----------------
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c
index 750f44f..a29e90c 100644
--- a/net/core/sock_diag.c
+++ b/net/core/sock_diag.c
@@ -97,21 +97,6 @@ void sock_diag_unregister(const struct sock_diag_handler *hnld)
}
EXPORT_SYMBOL_GPL(sock_diag_unregister);
-static const inline struct sock_diag_handler *sock_diag_lock_handler(int family)
-{
- if (sock_diag_handlers[family] == NULL)
- request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
- NETLINK_SOCK_DIAG, family);
-
- mutex_lock(&sock_diag_table_mutex);
- return sock_diag_handlers[family];
-}
-
-static inline void sock_diag_unlock_handler(const struct sock_diag_handler *h)
-{
- mutex_unlock(&sock_diag_table_mutex);
-}
-
static int __sock_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
{
int err;
@@ -124,12 +109,17 @@ static int __sock_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
if (req->sdiag_family >= AF_MAX)
return -EINVAL;
- hndl = sock_diag_lock_handler(req->sdiag_family);
+ if (sock_diag_handlers[req->sdiag_family] == NULL)
+ request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
+ NETLINK_SOCK_DIAG, req->sdiag_family);
+
+ mutex_lock(&sock_diag_table_mutex);
+ hndl = sock_diag_handlers[req->sdiag_family];
if (hndl == NULL)
err = -ENOENT;
else
err = hndl->dump(skb, nlh);
- sock_diag_unlock_handler(hndl);
+ mutex_unlock(&sock_diag_table_mutex);
return err;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] sock_diag: Fix out-of-bounds access to sock_diag_handlers[]
From: Mathias Krause @ 2013-02-23 11:13 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Mathias Krause
In-Reply-To: <1361618028-9024-1-git-send-email-minipli@googlemail.com>
Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY
with a family greater or equal then AF_MAX -- the array size of
sock_diag_handlers[]. The current code does not test for this
condition therefore is vulnerable to an out-of-bound access opening
doors for a privilege escalation.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
---
net/core/sock_diag.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c
index 602cd63..750f44f 100644
--- a/net/core/sock_diag.c
+++ b/net/core/sock_diag.c
@@ -121,6 +121,9 @@ static int __sock_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
if (nlmsg_len(nlh) < sizeof(*req))
return -EINVAL;
+ if (req->sdiag_family >= AF_MAX)
+ return -EINVAL;
+
hndl = sock_diag_lock_handler(req->sdiag_family);
if (hndl == NULL)
err = -ENOENT;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] net: sock_diag fixes
From: Mathias Krause @ 2013-02-23 11:13 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Mathias Krause
Hi Dave,
this small series fixes an exploitable bug in sock_diag. An unprivileged
user can send us a netlink message resulting in an out-of-bounds access
that allows userland to take over control while in kernel mode.
The first patch fixes the bug and should be pushed to stable. The second
one is an attempt to cleanup the sock_diag_handlers[] access mess in
__sock_diag_rcv_msg.
Please apply!
Mathias Krause (2):
sock_diag: Fix out-of-bounds access to sock_diag_handlers[]
sock_diag: Simplify sock_diag_handlers[] handling in
__sock_diag_rcv_msg
net/core/sock_diag.c | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
--
1.7.10.4
^ permalink raw reply
* Re: Problem with Reaktek 8168
From: Ralf Friedl @ 2013-02-23 11:10 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20130222230757.GA4248@electric-eye.fr.zoreil.com>
Francois Romieu:
> Ralf Friedl <Ralf.Friedl@online.de> :
> [...]
>
>> I have one warning in the syslog, but I hope it is not serious.
>> WARNING: at net/sched/sch_generic.c:254 dev_watchdog+0x239/0x250()
>> NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
>>
> [snip]
>
> It's the usual transmit timeout watchdog. A transient loss of network
> traffic should be noticable when it triggers. You may live with it as
> long as it does not happen much but it means that something does not
> work correctly.
I had this happen once for about 300GB of transfer data, so I can live
with this.
But if you have an idea what it might be, I can run some tests for you.
Ralf
^ permalink raw reply
* Re: [PATCHi v2] net: sh_eth: Add support of device tree probe
From: Simon Horman @ 2013-02-22 18:49 UTC (permalink / raw)
To: Nobuhiro Iwamatsu
Cc: Kuninori Morimoto, netdev, magnus.damm, devicetree-discuss, kda
In-Reply-To: <511C5279.3070008@renesas.com>
On Thu, Feb 14, 2013 at 11:56:57AM +0900, Nobuhiro Iwamatsu wrote:
> (2013/02/14 10:24), Kuninori Morimoto wrote:
> >
> >Hi Iwamatsu-san
> >
> >Thank you for this patch.
> >
> >Small comment from me
> >
> >>+#ifdef CONFIG_OF
> >(snip)
> >>+sh_eth_parse_dt(struct device *dev, struct net_device *ndev)
> >>+{
> >>+ int ret;
> >>+ struct device_node *np = dev->of_node;
> >>+ struct sh_eth_plat_data *pdata;
> >...
> >>+#else
> >>+static struct sh_eth_plat_data *
> >>+sh_eth_parse_dt(struct device *dev, struct net_device *ndev)
> >>+{
> >>+ return NULL;
> >>+}
> >>+#endif
> >
> >(snip)
> >
> >> static int sh_eth_drv_probe(struct platform_device *pdev)
> >> {
> >...
> >>+#ifdef CONFIG_OF
> >>+ if (np&& of_device_is_available(np)) {
> >>+ pd = sh_eth_parse_dt(&pdev->dev, ndev);
> >>+ if (pdev->dev.platform_data) {
> >>+ struct sh_eth_plat_data *tmp =
> >>+ pdev->dev.platform_data;
> >>+ pd->set_mdio_gate = tmp->set_mdio_gate;
> >>+ pd->needs_init = tmp->needs_init;
> >>+ }
> >>+ } else
> >>+#endif
> >
> >sh_eth_parse_dt() was defined for both CONFIG_OF and !CONFIG_OF.
> >But it is called only from CONFIG_OF ?
> >
>
> Because of_device_is_available needs CONFIG_OF.
> I already send a patch which add empty function of of_device_is_available.
> If this was apply, this ifdef becomes without need.
Hi Iwamatsu-san,
could you let me know of the status of that patch?
Has it been queued-up or merged? If so, where and when?
^ permalink raw reply
* Re: [PATCHv2 vringh 1/3] remoteproc: Add support for vringh (Host vrings)
From: Ohad Ben-Cohen @ 2013-02-23 9:49 UTC (permalink / raw)
To: Sjur Brændeland
Cc: Dmitry Tarnyagin, netdev, Linus Walleij, Ido Yariv,
linux-kernel@vger.kernel.org, Erwan Yvin, virtualization,
David S. Miller
In-Reply-To: <CAJK669Yr=rkmBhUNZGSQAQzC46c3v2KVewnAaEJhKT1a0Ci8Pw@mail.gmail.com>
On Thu, Feb 21, 2013 at 9:36 PM, Sjur Brændeland <sjurbren@gmail.com> wrote:
> OK, We did carefully consider using the normal vrings, but concluded it was
> not doable. I'll try to give you some of the background that I can
> recall from top of my head.
> (I can dig out more if you're still not convinced :)
>
> The modem we're integrating with is a complex beast (multi mode modem
> LTE, HSPA+, etc).
> When a packet is received deep down in the radio stack, it allocates packet
> buffers using the internal slab allocator.The packet may contain
> anything from control, voice,
> or IP packets. If the packet contains IP-payload it will travel to a
> different asymmetric CPU that
> handles the IPC towards the modem. If the packet is not a IP-packet it will be
> processed internally and eventually freed.
>
> What we have done to integrate virtio is to inject the carveout into the
> the modem internal slab-allocator.
>
> Using the reversed ring allows us to introduce zero-copy for virtio
> with virtually no
> impact on the radio-stack, only a small change on the modem slab allocator.
> It supports dynamic size buffer allocation, and modem internal
> messaging using data
> allocated from the shared region. It also allows modem to manage it's
> own memory,
> without any dependency on host side allocators.
Thanks for the description, Sjur.
It sounds like this mostly simplifies your modem-side code, especially
if it talks to other cores as well. My impression is that persistently
sticking to guest vrings is also possible, but it makes things
cumbersome.
We will most probably adopt vringh in rpmsg too when a real multicore
use case shows up.
Ohad.
^ permalink raw reply
* [PATCH] drivers/vhost: remove depends on CONFIG_EXPERIMENTAL
From: Kees Cook @ 2013-02-23 7:33 UTC (permalink / raw)
To: linux-kernel
Cc: Michael S. Tsirkin, kvm, virtualization, netdev, David S. Miller,
Asias He, Greg Kroah-Hartman
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Asias He <asias@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
---
drivers/vhost/Kconfig.blk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/Kconfig.blk b/drivers/vhost/Kconfig.blk
index 831a121..eeffc8b 100644
--- a/drivers/vhost/Kconfig.blk
+++ b/drivers/vhost/Kconfig.blk
@@ -1,6 +1,6 @@
config VHOST_BLK
- tristate "Host kernel accelerator for virtio blk (EXPERIMENTAL)"
- depends on BLOCK && EXPERIMENTAL && EVENTFD && m
+ tristate "Host kernel accelerator for virtio blk"
+ depends on BLOCK && EVENTFD && m
---help---
This kernel module can be loaded in host kernel to accelerate
guest block with virtio_blk. Not to be confused with virtio_blk
--
1.7.9.5
--
Kees Cook
Chrome OS Security
^ permalink raw reply related
* [PATCH] vxlan: remove depends on CONFIG_EXPERIMENTAL
From: Kees Cook @ 2013-02-23 7:25 UTC (permalink / raw)
To: linux-kernel
Cc: David S. Miller, Kees Cook, Stephen Hemminger, Greg Kroah-Hartman,
netdev
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: David S. Miller <davem@davemloft.net>
---
drivers/net/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 56c2d75..87f1d39 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -150,7 +150,7 @@ config MACVTAP
config VXLAN
tristate "Virtual eXtensible Local Area Network (VXLAN)"
- depends on EXPERIMENTAL && INET
+ depends on INET
---help---
This allows one to create vxlan virtual interfaces that provide
Layer 2 Networks over Layer 3 Networks. VXLAN is often used
--
1.7.9.5
--
Kees Cook
Chrome OS Security
^ permalink raw reply related
* Re: [PATCH] mlx4_en: fix allocation of CPU affinity reverse-map
From: Amir Vadai @ 2013-02-23 7:07 UTC (permalink / raw)
To: Kleber Sacilotto de Souza; +Cc: davem, netdev
In-Reply-To: <1361596492-10565-1-git-send-email-klebers@linux.vnet.ibm.com>
On 23/02/2013 07:14, Kleber Sacilotto de Souza wrote:
> The mlx4_en driver allocates the number of objects for the CPU affinity
> reverse-map based on the number of rx rings of the device. However,
> mlx4_assign_eq() calls irq_cpu_rmap_add() as many times as IRQ's are
> assigned to EQ's, which can be as large as mlx4_dev->caps.comp_pool. If
> caps.comp_pool is larger than rx_ring_num we will eventually hit the
> BUG_ON() in cpu_rmap_add().
>
> Fix this problem by allocating space for the maximum number of CPU
> affinity reverse-map objects we might want to add.
>
> Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 5944dd6..5385474 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -1829,7 +1829,7 @@ int mlx4_en_alloc_resources(struct mlx4_en_priv *priv)
> }
>
> #ifdef CONFIG_RFS_ACCEL
> - priv->dev->rx_cpu_rmap = alloc_irq_cpu_rmap(priv->rx_ring_num);
> + priv->dev->rx_cpu_rmap = alloc_irq_cpu_rmap(priv->mdev->dev->caps.comp_pool);
> if (!priv->dev->rx_cpu_rmap)
> goto err;
> #endif
>
Acked-by: Amir Vadai <amirv@mellanox.com>
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix allocation of device tx_cq
From: Amir Vadai @ 2013-02-23 7:05 UTC (permalink / raw)
To: Kleber Sacilotto de Souza; +Cc: davem, netdev
In-Reply-To: <1361581082-5583-1-git-send-email-klebers@linux.vnet.ibm.com>
On 23/02/2013 02:58, Kleber Sacilotto de Souza wrote:
> The memory to hold the network device tx_cq is not being allocated with
> the correct size in mlx4_en_init_netdev(). It should use MAX_TX_RINGS
> instead of MAX_RX_RINGS. This can cause problems if the number of tx
> rings being used is greater than MAX_RX_RINGS.
>
> Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 5088dc5..5944dd6 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -2067,7 +2067,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
> err = -ENOMEM;
> goto out;
> }
> - priv->tx_cq = kzalloc(sizeof(struct mlx4_en_cq) * MAX_RX_RINGS,
> + priv->tx_cq = kzalloc(sizeof(struct mlx4_en_cq) * MAX_TX_RINGS,
> GFP_KERNEL);
> if (!priv->tx_cq) {
> err = -ENOMEM;
>
(sorry for double posting - tried to send from my tablet in plain text
without success).
Acked-by: Amir Vadai <amirv@mellanox.com>
^ 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