* Re: [PATCH] net: add checks if dev->netdev_ops is NULL in register_netdevice()
From: David Miller @ 2013-04-08 15:34 UTC (permalink / raw)
To: eric.dumazet
Cc: dingtianhong, edumazet, alexander.h.duyck, netdev, lizefan,
huxinwei
In-Reply-To: <1365434194.3887.13.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 08 Apr 2013 08:16:34 -0700
> On Mon, 2013-04-08 at 17:43 +0800, dingtianhong wrote:
>> In some cases netdev->netdev_ops could be NULL in the register_netdevice(),
>> thus a NULL point deference happens and lead to oops:
>
>> /* Init, if this function is available */
>> - if (dev->netdev_ops->ndo_init) {
>> + if (dev->netdev_ops && dev->netdev_ops->ndo_init) {
>> ret = dev->netdev_ops->ndo_init(dev);
>> if (ret) {
>> if (ret > 0)
>> -- 1.8.0
>>
>
> Seriously ?
>
> This patch is not needed, and not complete anyway.
>
> Fix the driver instead, we don't want this to happen.
Agreed, I'm not seriously considering patches like this at all.
^ permalink raw reply
* Re: [PATCH 2/2] at86rf230: change irq handling to prevent lockups with edge type irq
From: Werner Almesberger @ 2013-04-08 15:35 UTC (permalink / raw)
To: Sascha Herrmann; +Cc: netdev, linux-zigbee-devel
In-Reply-To: <5161DC96.6030905@ps.nvbi.de>
Sascha Herrmann wrote:
> Maybe one way to eliminate the extra latency of the second register read
> would be to split the interrupt handling function into a generic part
> and two different functions to handle the different types of interrupts:
Yes, if you want to optimize the number of register accesses and
work queue invocations, splitting the paths that touch interrupts
seems to be the most straightforward approach.
> If you think the solution above would be ok, I could try to send a
> version which allows the configuration of trigger type and level.
Sounds good to me. Pity the irq_get_irq_type() you mentioned
doesn't exist. That would have made things a bit nicer.
- Werner
^ permalink raw reply
* Re: v3.8.5: "TCP: snd_cwnd is nul, please report this bug."
From: Bjørn Mork @ 2013-04-08 15:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, netdev
In-Reply-To: <1365434301.3887.14.camel@edumazet-glaptop>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> I believe patch applies (with some fuzz) on Linus tree, and maybe on 3.8
> too.
Probably just a minor context issue, but it failed like this on v3.9-rc6
(as well as 'net' and v3.8.6):
Applying: v3.8.5: "TCP: snd_cwnd is nul, please report this bug."
error: patch failed: net/ipv4/tcp_westwood.c:233
error: net/ipv4/tcp_westwood.c: patch does not apply
I'll just run todays net-next with this on top. No problem.
Bjørn
^ permalink raw reply
* [PATCH] tcp: assign the sock correctly to an outgoing SYNACK packet
From: Paul Moore @ 2013-04-08 15:45 UTC (permalink / raw)
To: netdev; +Cc: Miroslav Vadkerti
Commit 90ba9b1986b5ac4b2d184575847147ea7c4280a2 converted
tcp_make_synack() to use alloc_skb() directly instead of calling
sock_wmalloc(), the goal being the elimination of two atomic
operations. Unfortunately, in doing so the change broke certain
SELinux/NetLabel configurations by no longer correctly assigning
the sock to the outgoing packet.
This patch fixes this regression by doing the skb->sk assignment
directly inside tcp_make_synack().
Reported-by: Miroslav Vadkerti <mvadkert@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
---
net/ipv4/tcp_output.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 5d0b438..23cc295 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2705,6 +2705,8 @@ struct sk_buff *tcp_make_synack(struct sock *sk, struct dst_entry *dst,
dst_release(dst);
return NULL;
}
+ skb->sk = sk;
+
/* Reserve space for headers. */
skb_reserve(skb, MAX_TCP_HEADER);
^ permalink raw reply related
* Re: Active URB submitted twice in pegasus driver
From: Sarah Sharp @ 2013-04-08 15:49 UTC (permalink / raw)
To: Petko Manolov
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Greg KH,
netdev-u79uwXL29TY76Z2rM5mHXA, Stephen Hemminger
In-Reply-To: <alpine.DEB.2.02.1304051946020.7054@fry>
On Fri, Apr 05, 2013 at 08:01:03PM +0300, Petko Manolov wrote:
> On Wed, 27 Mar 2013, Petko Manolov wrote:
> >On Tue, 26 Mar 2013, Sarah Sharp wrote:
> The new driver actually compiles and runs fine with Pegasus-II based
> device. Please let me know if you run into problems.
I'm away for a week, so I won't be able to test for a while. I'll let
you know the results when I get back.
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH] net: add checks if dev->netdev_ops is NULL in register_netdevice()
From: Alexander Duyck @ 2013-04-08 15:49 UTC (permalink / raw)
To: dingtianhong; +Cc: David S. Miller, Eric Dumazet, Netdev, Li Zefan, Xinwei Hu
In-Reply-To: <51629159.9040000@huawei.com>
On 04/08/2013 02:43 AM, dingtianhong wrote:
> In some cases netdev->netdev_ops could be NULL in the register_netdevice(),
> thus a NULL point deference happens and lead to oops:
>
> [ 8260.836400] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 8260.955306] IP: [<ffffffff81388333>] register_netdevice+0x73/0x2d0
> [ 8261.054888] PGD 2f4dcd067 PUD 2f4de0067 PMD 0
> [ 8261.134244] Oops: 0000 [#1] SMP
> [ 8261.198938] CPU 0
> [ 8262.605182] RIP: 0010:[<ffffffff81388333>] [<ffffffff81388333>] register_netdevice+0x73/0x2d0
> [ 8262.741859] RSP: 0018:ffff8802f489f9f8 EFLAGS: 00010246
> [ 8262.839463] RAX: 0000000000000000 RBX: ffff8802f4e73000 RCX: ffff8802f4e73006
> [ 8262.959484] RDX: 0000000000000000 RSI: 00000000daa92527 RDI: ffff8802f4e73006
> [ 8263.079352] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff880327d898c0
> [ 8263.198987] R10: 00000000000000c1 R11: 0000000000000000 R12: ffffffff81fed080
> [ 8263.318401] R13: ffffffff81fed080 R14: ffff8802f4e73000 R15: 0000000000000000
> [ 8263.438014] FS: 00007f01dfa81700(0000) GS:ffff88033f200000(0000) knlGS:0000000000000000
> [ 8263.569778] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 8263.673859] CR2: 0000000000000000 CR3: 000000032893f000 CR4: 00000000000006f0
> [ 8263.794922] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 8263.915734] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 8264.036251] Process rmcli (pid: 14089, threadinfo ffff8802f489e000, task ffff880324708080)
> [ 8264.170961] Stack:
> [ 8264.231328] ffff88032a3c0000 0000000000000003 0000000000000003 ffff88032a3c0000
> [ 8264.356967] 0000000000000003 ffffffffa039dbcb 000000003ec216c0 0000000000000246
> [ 8264.483081] 382e30363238205b 00205d3900000006 ff00305f63696e76 0000000000000003
>
> We should check the point to avoid the oops.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> net/core/dev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index e7d68ed..596a11e 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5159,7 +5159,7 @@ int register_netdevice(struct net_device *dev)
> goto out;
>
> /* Init, if this function is available */
> - if (dev->netdev_ops->ndo_init) {
> + if (dev->netdev_ops && dev->netdev_ops->ndo_init) {
> ret = dev->netdev_ops->ndo_init(dev);
> if (ret) {
> if (ret > 0)
> -- 1.8.0
>
The correct fix for this is to not allow the registration of devices
with a null netdev_ops pointer. The subtle approach to resolving this
is adding a check for the null pointer near the start of the function
and returning -EVINAL since the dev structure passed was configured
incorrectly. The blunt approach is to just add a BUG_ON with a comment
on the line before it explaining that you should always set the
netdev_ops pointer before trying to register a netdev. That way if
someone else makes the mistake then they will hit the BUG_ON and realize
what they are doing wrong.
Thanks,
Alex
^ permalink raw reply
* Re: be2net: GRO for non-inet protocols
From: Eric Dumazet @ 2013-04-08 15:51 UTC (permalink / raw)
To: Erik Hugne; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev
In-Reply-To: <20130408152417.GD19951@eerihug-hybrid.ki.sw.ericsson.se>
On Mon, 2013-04-08 at 17:24 +0200, Erik Hugne wrote:
> On Mon, Apr 08, 2013 at 08:40:10AM +0200, Erik Hugne wrote:
> > Thanks Eric, it works as expected after applying this.
>
> So, on to the next problem, now i'm getting corrupted packets
> from the driver instead. Would be great to get some comments
> from the Emulex guys regarding this.
>
> Attaching a printk trace where i log the mac header and packet data of
> all 0x88CA (TIPC) packets in the gro_receive routine that have an
> erroneous TIPC header. This happens immediately when i register
> myself with the device.
>
You could check using a GRE tunnel, that the GRO support I added in
recent kernel is working or not. (including the be2net patch I sent)
^ permalink raw reply
* [PATCH] rtnetlink: Call nlmsg_parse() with correct header length
From: Michael Riesch @ 2013-04-08 15:45 UTC (permalink / raw)
To: netdev
Cc: Michael Riesch, David S. Miller, Greg Kroah-Hartman, Jiri Benc,
Theodore Ts'o, linux-kernel
Signed-off-by: Michael Riesch <michael.riesch@omicron.at>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: linux-kernel@vger.kernel.org
---
Habidere,
I encountered a netlink kernel warning when running avahi 0.6.31 on my system
with kernel v3.4.35 (it appears several times):
netlink: 12 bytes leftover after parsing attributes.
Searching the web showed that commit "115c9b81928360d769a76c632bae62d15206a94a
rtnetlink: Fix problem with buffer allocation" introduced this behaviour[1].
Now I - knowing nothing about netlink whatsoever - assume that the nlmsg_parse
function is called with the wrong header length. In user space the request
message consists out of the message header (struct nlmsghdr, 16 bytes) and an
ifinfomsg (struct ifinfomsg, 16 bytes). After that, request attributes could
follow. nlmsg_parse checks for this attributes after a given header length. In
rtnl_get_link() this header length is sizeof(struct ifinfomsg), but in
rtnl_calcit() as well as in rntl_dump_ifinfo() the header length is
sizeof(struct rtgenmsg), which is 1 byte.
With this patch I got rid of these warnings. However, I do not know whether
this is the correct solution, so I am looking forward to your comments.
Regards, Michael
[1] http://lists.infradead.org/pipermail/libnl/2012-April/000515.html
net/core/rtnetlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 900fc61..ebf6ace 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1065,7 +1065,7 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
rcu_read_lock();
cb->seq = net->dev_base_seq;
- if (nlmsg_parse(cb->nlh, sizeof(struct rtgenmsg), tb, IFLA_MAX,
+ if (nlmsg_parse(cb->nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
ifla_policy) >= 0) {
if (tb[IFLA_EXT_MASK])
@@ -1909,7 +1909,7 @@ static u16 rtnl_calcit(struct sk_buff *skb, struct nlmsghdr *nlh)
u32 ext_filter_mask = 0;
u16 min_ifinfo_dump_size = 0;
- if (nlmsg_parse(nlh, sizeof(struct rtgenmsg), tb, IFLA_MAX,
+ if (nlmsg_parse(nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
ifla_policy) >= 0) {
if (tb[IFLA_EXT_MASK])
ext_filter_mask = nla_get_u32(tb[IFLA_EXT_MASK]);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next 0/2] ieee802154_mlme_ops oops removal and cleanup
From: David Miller @ 2013-04-08 16:00 UTC (permalink / raw)
To: werner; +Cc: netdev, linux-zigbee-devel
In-Reply-To: <cover.1365092820.git.werner@almesberger.net>
From: Werner Almesberger <werner@almesberger.net>
Date: Thu, 4 Apr 2013 13:31:46 -0300
> This fixes a kernel oops we get when some linux-zigbee user
> space tools try to invoke unimplemented operations.
>
> The second of the two patches checks whether the respective
> functions are present and returne EOPNOTSUPP if they aren't.
> It also updates the documentation.
>
> The first one removes the unused get_bsn function, which was
> a small obstacle for the other patch.
Both applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] enic: be less verbose about non-critical firmware errors
From: David Miller @ 2013-04-08 16:00 UTC (permalink / raw)
To: sassmann; +Cc: netdev, neepatel
In-Reply-To: <1365094628-21520-1-git-send-email-sassmann@kpanic.de>
From: Stefan Assmann <sassmann@kpanic.de>
Date: Thu, 4 Apr 2013 18:57:08 +0200
> If a feature is not supported by firmware no need to print an error message.
> This surpresses the following harmless message on boot up and ethtool query.
> enic: Error 1 devcmd 36
>
> Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] at86rf230: remove unnecessary / dead code
From: David Miller @ 2013-04-08 16:01 UTC (permalink / raw)
To: sascha; +Cc: linux-zigbee-devel, netdev, alex.bluesman.smirnov, dbaryshkov
In-Reply-To: <c9c5bee7116dd5847ed9e2ebb8be49fcde0cc052.1365107512.git.sascha@ps.nvbi.de>
From: Sascha Herrmann <sascha@ps.nvbi.de>
Date: Thu, 4 Apr 2013 23:02:00 +0200
> In at86rf230_probe() lp was first set to dev->priv and a few lines later
> dev->priv was set to lp again, without changing lp in between. The call
> to ieee802154_unregister_device() before err_irq: was unreachable.
>
> Signed-off-by: Sascha Herrmann <sascha@ps.nvbi.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ip_gre: fix a possible crash in parse_gre_header()
From: David Miller @ 2013-04-08 16:01 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, pshelar
In-Reply-To: <1365126087.3308.17.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 04 Apr 2013 18:41:27 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> pskb_may_pull() can change skb->head, so we must init iph/greh after
> calling it.
>
> Bug added in commit c54419321455 (GRE: Refactor GRE tunneling code.)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [patch net 0/2] net: ipv4: fix couple of addr lifetime related bugs
From: David Miller @ 2013-04-08 16:05 UTC (permalink / raw)
To: jiri; +Cc: netdev, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <1365154779-4204-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 5 Apr 2013 11:39:37 +0200
> Jiri Pirko (2):
> net: ipv4: reset check_lifetime_work after changing lifetime
> net: ipv4: fix schelude while atomic bug in check_lifetime()
Both applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH 00/51] netfilter updates for net-next
From: Pablo Neira Ayuso @ 2013-04-08 16:06 UTC (permalink / raw)
To: David Miller; +Cc: netfilter-devel, netdev
In-Reply-To: <20130407.122728.797835275855932038.davem@davemloft.net>
On Sun, Apr 07, 2013 at 12:27:28PM -0400, David Miller wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Sat, 6 Apr 2013 14:16:59 +0200
>
> > You can pull these changes from:
> >
> > git://1984.lsi.us.es/nf-next master
>
> Not a very good pull request, I don't know how you were able to
> successfully create it with all the inaccuracies.
I'm very sorry for this, will put more care on next pull requests,
specifically for big batches like this. Will send you the remaining
patches from Patrick that were missing.
Thanks a lot for having pulled even it was not in good shape.
^ permalink raw reply
* Re: [PATCH] mrf24j40: Enable link-layer acknowledgement and retry
From: David Miller @ 2013-04-08 16:09 UTC (permalink / raw)
To: alan
Cc: alex.bluesman.smirnov, dbaryshkov, linux-zigbee-devel, netdev,
linux-kernel
In-Reply-To: <1365194091-2542-1-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Fri, 5 Apr 2013 16:34:51 -0400
> On the MRF24J40, link-layer acknowledgment request and retry must be
> turned on explicitly for each packet. Turn this on in the hardware based
> on the FC_ACK_REQ bit being set in the packet.
>
> Also, now that failure to receive an ACK will cause the hardware to report
> failure of transmission, change the log level for this failure to debug
> level.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
Applied.
^ permalink raw reply
* Re: [PATCH v2] mac802154: Keep track of the channel when changed
From: David Miller @ 2013-04-08 16:09 UTC (permalink / raw)
To: alan
Cc: alex.bluesman.smirnov, dbaryshkov, linux-zigbee-devel, netdev,
linux-kernel
In-Reply-To: <1365202990-9006-1-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Fri, 5 Apr 2013 19:03:10 -0400
> Two sections checked whether the current channel != the new channel
> without ever setting the current channel variables.
>
> 1. net/mac802154/tx.c: Prevent set_channel() from getting called every
> time a packet is sent.
>
> 2. net/mac802154/mib.c: Lock (pib_lock) accesses to current_channel and
> current_page and make sure they are updated when the channel has been
> changed.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] irda: GFP_ATOMIC cleanups
From: David Miller @ 2013-04-08 16:10 UTC (permalink / raw)
To: minipli; +Cc: samuel, netdev
In-Reply-To: <1365194488-23462-1-git-send-email-minipli@googlemail.com>
From: Mathias Krause <minipli@googlemail.com>
Date: Fri, 5 Apr 2013 22:41:26 +0200
> Hi Samuel, Dave,
>
> this small series changes some obvious misusages of GFP_ATOMIC in the
> irda code.
>
> Please apply -- probably to net-next!
Both applied, thanks.
^ permalink raw reply
* Re: [PATCH] TTY: ircomm, use GFP_KERNEL in ircomm_open()
From: David Miller @ 2013-04-08 16:10 UTC (permalink / raw)
To: gregkh; +Cc: minipli, samuel, netdev
In-Reply-To: <20130405211500.GA14617@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 5 Apr 2013 14:15:00 -0700
> On Fri, Apr 05, 2013 at 11:02:07PM +0200, Mathias Krause wrote:
>> Hi Greg,
>>
>> I'm unsure if you or Dave should take that one as it's for one a TTY
>> patch but also living under net/. So I'm uncertain and let you decide!
>
> If Dave want to take it, it's fine with me:
>
>> -- >8 --
>> Subject: [PATCH] TTY: ircomm, use GFP_KERNEL in ircomm_open()
>>
>> We're clearly running in non-atomic context as our only call site is
>> able to call wait_event_interruptible(). So we're safe to use GFP_KERNEL
>> here instead of GFP_ATOMIC.
>>
>> Signed-off-by: Mathias Krause <minipli@googlemail.com>
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: assign the sock correctly to an outgoing SYNACK packet
From: David Miller @ 2013-04-08 16:14 UTC (permalink / raw)
To: pmoore; +Cc: netdev, mvadkert
In-Reply-To: <20130408154519.18177.57709.stgit@localhost>
From: Paul Moore <pmoore@redhat.com>
Date: Mon, 08 Apr 2013 11:45:19 -0400
> Commit 90ba9b1986b5ac4b2d184575847147ea7c4280a2 converted
> tcp_make_synack() to use alloc_skb() directly instead of calling
> sock_wmalloc(), the goal being the elimination of two atomic
> operations. Unfortunately, in doing so the change broke certain
> SELinux/NetLabel configurations by no longer correctly assigning
> the sock to the outgoing packet.
>
> This patch fixes this regression by doing the skb->sk assignment
> directly inside tcp_make_synack().
>
> Reported-by: Miroslav Vadkerti <mvadkert@redhat.com>
> Signed-off-by: Paul Moore <pmoore@redhat.com>
Setting skb->sk without the destructor results in an SKB that can live
potentially forever with a stale reference to a destroyed socket.
You cannot fix the problem in this way.
^ permalink raw reply
* Re: [PATCH] net: mvneta: enable features before registering the driver
From: David Miller @ 2013-04-08 16:16 UTC (permalink / raw)
To: w; +Cc: netdev, thomas.petazzoni
In-Reply-To: <20130406184701.GA16142@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Sat, 6 Apr 2013 20:47:01 +0200
> Hi,
>
> I noticed that mvneta's tx-csum/sg were off until disabled then
> enabled, which led me to think that something was not made in the
> correct sequence. And indeed, setting the dev features _before_
> registering the device works much better :-)
>
> This patch is for master but may be backported to 3.8-stable as well,
> which is where I first experienced the issue.
Please don't post patches like this, you make extra work for the
maintainer by having to edit out this commentary.
You put such commentary after the "---" seperator the delineates
your commit message in the email body, not before.
Anyways, applied.
^ permalink raw reply
* Re: [PATCH net,1/2] hyperv: Fix a kernel warning from netvsc_linkstatus_callback()
From: David Miller @ 2013-04-08 16:16 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, linux-kernel, devel
In-Reply-To: <1365198280-23270-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Fri, 5 Apr 2013 14:44:39 -0700
> The warning about local_bh_enable inside IRQ happens when disconnecting a
> virtual NIC.
>
> The reason for the warning is -- netif_tx_disable() is called when the NIC
> is disconnected. And it's called within irq context. netif_tx_disable() calls
> local_bh_enable() which displays warning if in irq.
>
> The fix is to remove the unnecessary netif_tx_disable & wake_queue() in the
> netvsc_linkstatus_callback().
>
> Reported-by: Richard Genoud <richard.genoud@gmail.com>
> Tested-by: Long Li <longli@microsoft.com>
> Tested-by: Richard Genoud <richard.genoud@gmail.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH net,2/2] hyperv: Fix RNDIS send_completion code path
From: David Miller @ 2013-04-08 16:16 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, linux-kernel, devel
In-Reply-To: <1365198280-23270-2-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Fri, 5 Apr 2013 14:44:40 -0700
> In some cases, the VM_PKT_COMP message can arrive later than RNDIS completion
> message, which will free the packet memory. This may cause panic due to access
> to freed memory in netvsc_send_completion().
>
> This patch fixes this problem by removing rndis_filter_send_request_completion()
> from the code path. The function was a no-op.
>
> Reported-by: Long Li <longli@microsoft.com>
> Tested-by: Long Li <longli@microsoft.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: assign the sock correctly to an outgoing SYNACK packet
From: Eric Dumazet @ 2013-04-08 16:19 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, Miroslav Vadkerti
In-Reply-To: <20130408154519.18177.57709.stgit@localhost>
On Mon, 2013-04-08 at 11:45 -0400, Paul Moore wrote:
> Commit 90ba9b1986b5ac4b2d184575847147ea7c4280a2 converted
> tcp_make_synack() to use alloc_skb() directly instead of calling
> sock_wmalloc(), the goal being the elimination of two atomic
> operations. Unfortunately, in doing so the change broke certain
> SELinux/NetLabel configurations by no longer correctly assigning
> the sock to the outgoing packet.
>
> This patch fixes this regression by doing the skb->sk assignment
> directly inside tcp_make_synack().
>
> Reported-by: Miroslav Vadkerti <mvadkert@redhat.com>
> Signed-off-by: Paul Moore <pmoore@redhat.com>
> ---
> net/ipv4/tcp_output.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 5d0b438..23cc295 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -2705,6 +2705,8 @@ struct sk_buff *tcp_make_synack(struct sock *sk, struct dst_entry *dst,
> dst_release(dst);
> return NULL;
> }
> + skb->sk = sk;
> +
Hmm...
Keeping a pointer on a socket without taking a refcount is not going to
work.
We are trying to make the stack scale, so you need to add a selinux call
to take a ref count only if needed.
That is : If selinux is not used, we don't need to slow down the stack.
^ permalink raw reply
* Re: [patch net-next] net: squash ->rx_handler and ->rx_handler_data into single rcu pointer
From: Steven Rostedt @ 2013-04-08 16:32 UTC (permalink / raw)
To: Jiri Pirko
Cc: alexander.h.duyck-ral2JQCrhuEAvxtiuMwx3w,
dev-yBygre7rU0TnMu66kgdUjQ, paulmck-r/Jw6+rmf7HQT0dZR+AlfA,
streeter-H+wXaHxf7aLQT0dZR+AlfA,
nicolas.2p.debian-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, fubar-r/Jw6+rmf7HQT0dZR+AlfA,
kaber-dcUjhNyLwpNeoWH0uzbU5w, edumazet-hpIqsD4AKlfQT0dZR+AlfA,
ivecera-H+wXaHxf7aLQT0dZR+AlfA, tglx-hfZtesqFncYOwBW4kG4KsQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, andy-QlMahl40kYEqcZcGjlUOXw
In-Reply-To: <20130330193210.GD1544-RDzucLLXGGI88b5SBfVpbw@public.gmane.org>
On Sat, 2013-03-30 at 20:32 +0100, Jiri Pirko wrote:
> >This doesn't solve anything. The CPU can be executing func when you set it to null. Then you have the same problem. This patch shows you still don't understand the bug.
>
> rx_handler->func is never set to NULL and is valid for all rx_handler (port_priv)
> lifetime.
>
Ah, you're right. I'll look deeper at this patch after reading the
thread.
This is what I get for trying to review a patch reading it on my android
phone ;-)
-- Steve
^ permalink raw reply
* Re: [Patch net-next] tcp: add a global sysctl to control TCP delayed ack
From: Rick Jones @ 2013-04-08 16:39 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, netdev, eric.dumazet, shemminger, tgraf,
David.Laight
In-Reply-To: <1365385541.31063.0.camel@cr0>
On 04/07/2013 06:45 PM, Cong Wang wrote:
> On Sun, 2013-04-07 at 17:09 -0400, David Miller wrote:
>>
>> I'm not applying a patch that adds a global parameter for
>> an attribute which has per-path scope.
>
> Ok, I will make it per-route.
Is setting a per-route attribute to cover the backside of an application
for which source code is not available in this day and age really all
that much easier than hitting that application with an LD_PRELOAD
library to make the desired setsockopt() call?
rick jones
having flashbacks to similar conversations in other contexts in the 1990s...
^ 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