* [PATCH v2] SubmittingPatches: clarify SOB tag usage when evolving submissions
From: Luis R. Rodriguez @ 2012-08-09 21:48 UTC (permalink / raw)
To: torvalds
Cc: rdunlap, tytso, alan, davem, netdev, linux-kernel,
Luis R. Rodriguez
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Initial large code submissions typically are not accepted
on their first patch submission. The developers are
typically given feedback and at times some developers may
even submit changes to the original authors for integration
into their second submission attempt.
Developers wishing to contribute changes to the evolution
of a second patch submission must supply their own Siged-off-by
tag to the original authors and must submit their changes
on a public mailing list or ensure that these submission
are recorded somewhere publicly.
To date a few of these type of contributors have expressed
different preferences for whether or not their own SOB tag
should be used for a second code submission. Lets keep things
simple and only require the contributor's SOB tag if so desired
explicitly. It is not technically required if there already
is a public record of their contribution somewhere.
Document this on Documentation/SubmittingPatches
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
This v2 has Singed/Signed typo fixes.
Documentation/SubmittingPatches | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c379a2a..3154565 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -366,6 +366,21 @@ and protect the submitter from complaints. Note that under no circumstances
can you change the author's identity (the From header), as it is the one
which appears in the changelog.
+If you are submitting a large change (for example a new driver) at times
+you may be asked to make quite a lot of modifications prior to getting
+your change accepted. At times you may even receive patches from developers
+who not only wish to tell you what you should change to get your changes
+upstream but actually send you patches. If those patches were made publicly
+and they do contain a Signed-off-by tag you are not expected to provide
+their own Signed-off-by tag on the second iteration of the patch so long
+as there is a public record somewhere that can be used to show the
+contributor had sent their changes with their own Signed-off-by tag.
+
+If you receive patches privately during development you may want to
+ask for these patches to be re-posted publicly or you can also decide
+to merge the patches as part of a separate historical git tree that
+will remain online for historical archiving.
+
Special note to back-porters: It seems to be a common and useful practise
to insert an indication of the origin of a patch at the top of the commit
message (just after the subject line) to facilitate tracking. For instance,
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 00/19] netfilter: IPv6 NAT
From: Patrick McHardy @ 2012-08-09 21:52 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netfilter-devel, netdev
In-Reply-To: <87a9y3n5rz.fsf@xmission.com>
On Thu, 9 Aug 2012, Eric W. Biederman wrote:
> kaber@trash.net writes:
>
>> The following patches contain an updated version of IPv6 NAT against
>> Linus' current tree.
>>
>> The series is organized as follows:
>>
>> - Patches 01-03 contain bugfixes for SIP helper bugs/regressions
>> present in the current kernel
>
> Why not just delete this code? The current best practices are to
> disable ALGs for SIP. To the point in some circles people recommend
> running SIP over TLS to avoid over helpful NAT ALGs.
And where can I read up on these best practices and how well they work?
In any case, these patches are all for the connection tracking helper,
which is needed unless you want to open up your firewall for every
possible RTP source, in which case you can simply disable it. Some people
are also using it to proritize RTP streams without any filtering.
Also, even if the NAT helper would not mangle packets, it is still needed
to adjust expectations. so incoming connections can go to the correct
destination. That is, direct RTP connections between two endpoints
that didn't have any direct signalling communication before
You can of course also proxy everything through your SIP provider
(including internal calls) and/or use STUN (which is unreliable under
Linux). I prefer not to.
^ permalink raw reply
* Re: [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock
From: Casey Schaufler @ 2012-08-09 21:53 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Paris, Paul Moore, David Miller, John Stultz,
Serge E. Hallyn, lkml, James Morris, selinux, john.johansen, LSM,
netdev, Casey Schaufler
In-Reply-To: <1344547743.31104.582.camel@edumazet-glaptop>
On 8/9/2012 2:29 PM, Eric Dumazet wrote:
> On Thu, 2012-08-09 at 16:06 -0400, Eric Paris wrote:
>> NAK.
>>
>> I personally think commit be9f4a44e7d41cee should be reverted until it
>> is fixed. Let me explain what all I believe it broke and how.
>>
> Suggesting to revert this commit while we have known working fixes is a
> bit of strange reaction.
A couple of potential short term workarounds have been identified,
but no one is happy with them for the long term. That does not
qualify as a "working fix" in engineering terms.
> I understand you are upset, but I believe we tried to fix it.
>
>> Old callchain of the creation of the 'equivalent' socket previous to
>> the patch in question just for reference:
>>
>> inet_ctl_sock_create
>> sock_create_kern
>> __sock_create
>> pf->create (inet_create)
>> sk_alloc
>> sk_prot_alloc
>> security_sk_alloc()
>>
>>
>> This WAS working properly. All of it.
> Nobody denies it. But acknowledge my patch uncovered a fundamental
> issue.
>
> What kind of 'security module' can decide to let RST packets being sent
> or not, on a global scale ? (one socket for the whole machine)
The short answer is "any security module that wants to".
And before we go any further, I'm a little surprised that
SELinux doesn't do this already.
>
> smack_sk_alloc_security() uses smk_of_current() : What can be the
> meaning of smk_of_current() in the context of 'kernel' sockets...
Yes, and all of it's callers - to date - have had an appropriate
value of current. It is using the API in the way it is supposed to.
It is assuming a properly formed socket. You want to give it a
cobbled together partial socket structure without task context.
Your predecessor did not have this problem.
>
> Your patch tries to maintain this status quo.
>
> In fact I suggest the following one liner patch, unless you can really
> demonstrate what can be the meaning of providing a fake socket for these
> packets.
>
> This mess only happened because ip_append_data()/ip_push_pending_frames()
> are so complex and use an underlying socket.
>
> But this socket should not be ever used outside of its scope.
>
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 76dde25..ec410e0 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -1536,6 +1536,7 @@ void ip_send_unicast_reply(struct net *net, struct sk_buff *skb, __be32 daddr,
> arg->csumoffset) = csum_fold(csum_add(nskb->csum,
> arg->csum));
> nskb->ip_summed = CHECKSUM_NONE;
> + skb_orphan(nskb);
> skb_set_queue_mapping(nskb, skb_get_queue_mapping(skb));
> ip_push_pending_frames(sk, &fl4);
> }
>
>
>
^ permalink raw reply
* Re: [PATCH 19/19] netfilter: ip6tables: add stateless IPv6-to-IPv6 Network Prefix Translation target
From: Jan Engelhardt @ 2012-08-09 21:55 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1344542943-11588-20-git-send-email-kaber@trash.net>
On Thursday 2012-08-09 22:09, kaber@trash.net wrote:
>+config IP6_NF_TARGET_NPT
>+ tristate "NPT (Network Prefix translation) target support"
>+ depends on NETFILTER_ADVANCED
>+ help
>+ This option adda `SNPT' and `DNPT' target, which perform stateless
>+ IPv6-to-IPv6 Network Prefix Translation (RFC 6296).
Fixes/suggestion in the help text (near "adda" and subsequent).
config IP6_NF_TARGET_NPT
tristate "NPT (Network Prefix translation) target support"
depends on NETFILTER_ADVANCED
---help---
This option adds the "SNPT" and "DNPT" targets, which perform stateless
IPv6-to-IPv6 Network Prefix Translation per RFC 6296.
>+/*
>+ * Copyright (c) 2011, 2012 Patrick McHardy <kaber@trash.net>
>+ *
>+ * This program is free software; you can redistribute it and/or modify
>+ * it under the terms of the GNU General Public License version 2 as
>+ * published by the Free Software Foundation.
>+ */
GNU sometimes has a strange way of expressing their (C) lines,
listing all years separately, as if "1989-1991,1994-1999,2001-2005" was not
sufficient. In your case, would "2011-2012" work?
Any objection to adding a "(or later)" clause to the set?
>+static int ip6t_npt_checkentry(const struct xt_tgchk_param *par)
>+{
>+ struct ip6t_npt_tginfo *npt = par->targinfo;
>+ __sum16 src_sum = 0, dst_sum = 0;
>+ unsigned int i;
>+
>+ if (npt->src_pfx_len > 64 || npt->dst_pfx_len > 64)
>+ return -EINVAL;
While the RFC probably only specifies masks up to /64,
the general algorithm is sustainable up to at least /96.
Extending the RFC's section 3.6 ("/48 Prefix Mapping") example,
fd01:0203:0405:0001:0000:0000:0000:1234/112 (specification per `ip
addr`) would become 2001:0db8:0001:0000:0000:0000:d550:1234.
Not everybody runs exclusively on EUI64-SLAAC / PRIVACY addresses :)
>+static struct xt_target ip6t_npt_target_reg[] __read_mostly = {
>+ {
>+ .name = "SNPT",
IETF did quite a job again... NPT as an acronym is quite
close to NAPT - too close.
Since it's essentially NETMAP, having something in that ballpark
may seem more fitting. NPMAP? (Translation is mapping -
henceforh "Network Prefix Mapping")
I would hint towards choosing a different name; the P in NPT
may be (mis)understood as port (due to the common "NAPT")
keyword.
>+ .target = ip6t_snpt_tg,
>+ .targetsize = sizeof(struct ip6t_npt_tginfo),
>+ .checkentry = ip6t_npt_checkentry,
>+ .family = NFPROTO_IPV6,
>+ .hooks = (1 << NF_INET_LOCAL_IN) |
>+ (1 << NF_INET_POST_ROUTING),
>+ .me = THIS_MODULE,
Should perhaps a .table = "mangle" be added?
Are any tricks on the userspace side needed to use SNPT/SNPMAP?
Since I spot no code telling conntrack about the address mingling,
one would have to use -j CT --notrack or the rawpost table, like
it's done for RAWSNAT in xtables-addons, would he not?
^ permalink raw reply
* (Proposal USD$450 Million Dollars.)
From: MR VICTOR @ 2012-08-09 21:59 UTC (permalink / raw)
To: victorb7
[-- Attachment #1: Type: text/plain, Size: 56 bytes --]
VIEW DOWNLOAD MESSAGE AND REACH ME ON: +27-83-549-5671.
[-- Attachment #2: Fund Transfer7.pdf --]
[-- Type: application/pdf, Size: 23383 bytes --]
^ permalink raw reply
* Re: [PATCH 00/19] netfilter: IPv6 NAT
From: Pablo Neira Ayuso @ 2012-08-09 22:00 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1344542943-11588-1-git-send-email-kaber@trash.net>
Hi Patrick,
On Thu, Aug 09, 2012 at 10:08:44PM +0200, kaber@trash.net wrote:
> The following patches contain an updated version of IPv6 NAT against
> Linus' current tree.
>
> The series is organized as follows:
>
> - Patches 01-03 contain bugfixes for SIP helper bugs/regressions
> present in the current kernel
Thanks, I'll pass these to David.
I have also two more to fixes to oopses regarding SIP. I'm expecting
one user to finally confirm that their issues are fixed.
> - Patches 04-06 improve conntrack fragmentation handling, the IPv6
> parts are also a precondition for IPv6 NAT
>
> - Patches 07 and 08 prepare the current NAT code for conversion to
> an address family independant core, but contain no functional
> changes
>
> - Patch 09 adds the address family independant NAT core and converts
> the existing IPv4-only NAT code to an AF-specific module
>
> - Patches 10 and 11 add some infrastructure for IPv6 NAT
>
> - Patch 12 adds IPv6 NAT support
>
> - Patches 13-15 add IPv6 specific NAT targets
>
> - Patches 16-19 add some IPv6-capable ports of existing NAT helpers
>
> - Patch 19 is independant of the IPv6 NAT code and adds support for
> stateless IPv6 prefix translation, just to relieve my conscience ;)
>
>
> Since the last posting numerous bugs have been fixed, I don't remember
> all of them, the more important ones include:
>
> - automatic NAT module loading in ctnetlink
>
> - address selection when mapping to IPv6 ranges
>
> - handling of IPv6 fragments
>
> - NAT handling of ICMPv6 error messages
Thanks, I was keeping the previous patchset in one branch:
http://1984.lsi.us.es/git/nf-next/log/?h=nf-nat4
You can also find forward ports of netlink-mmap (from Florian Westpal)
and one for nftables from myself in that tree.
> Besides implementing IPv6 NAT, there are no known bugs left. Userspace
> patches will follow shortly.
We have this branch for iptables IPv6 NAT:
http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a=shortlog;h=refs/heads/nf-nat
Let me know if you're OK with these.
^ permalink raw reply
* Re: [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock
From: Eric Dumazet @ 2012-08-09 22:05 UTC (permalink / raw)
To: Casey Schaufler
Cc: Eric Paris, Paul Moore, David Miller, John Stultz,
Serge E. Hallyn, lkml, James Morris, selinux, john.johansen, LSM,
netdev
In-Reply-To: <5024313F.1010404@schaufler-ca.com>
On Thu, 2012-08-09 at 14:53 -0700, Casey Schaufler wrote:
> On 8/9/2012 2:29 PM, Eric Dumazet wrote:
> > smack_sk_alloc_security() uses smk_of_current() : What can be the
> > meaning of smk_of_current() in the context of 'kernel' sockets...
>
> Yes, and all of it's callers - to date - have had an appropriate
> value of current. It is using the API in the way it is supposed to.
> It is assuming a properly formed socket. You want to give it a
> cobbled together partial socket structure without task context.
> Your predecessor did not have this problem.
My predecessor ? You mean before the patch ?
tcp socket was preallocated by at kernel boot time.
What is the 'user' owning this socket ?
You guys focus on an implementation detail of TCP stack.
You should never use this fake socket.
I repeat : There are no true socket for these control packets.
If you want them, then you'll have to add fields in timewait socket.
I can decide to rewrite the whole thing just building a TCP packet on
its own, and send it without any fake socket.
Some guy 15 years ago tried to reuse some high level functions, able to
build super packets and use sophisticated tricks, while we only want so
send a 40 or 60 bytes packet.
^ permalink raw reply
* Re: [PATCH 19/19] netfilter: ip6tables: add stateless IPv6-to-IPv6 Network Prefix Translation target
From: Patrick McHardy @ 2012-08-09 22:25 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1208092337220.10514@frira.zrqbmnf.qr>
On Thu, 9 Aug 2012, Jan Engelhardt wrote:
>
> On Thursday 2012-08-09 22:09, kaber@trash.net wrote:
>> +config IP6_NF_TARGET_NPT
>> + tristate "NPT (Network Prefix translation) target support"
>> + depends on NETFILTER_ADVANCED
>> + help
>> + This option adda `SNPT' and `DNPT' target, which perform stateless
>> + IPv6-to-IPv6 Network Prefix Translation (RFC 6296).
>
> Fixes/suggestion in the help text (near "adda" and subsequent).
>
> config IP6_NF_TARGET_NPT
> tristate "NPT (Network Prefix translation) target support"
> depends on NETFILTER_ADVANCED
> ---help---
> This option adds the "SNPT" and "DNPT" targets, which perform stateless
> IPv6-to-IPv6 Network Prefix Translation per RFC 6296.
Thanks, changes.
>> +/*
>> + * Copyright (c) 2011, 2012 Patrick McHardy <kaber@trash.net>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>
> GNU sometimes has a strange way of expressing their (C) lines,
> listing all years separately, as if "1989-1991,1994-1999,2001-2005" was not
> sufficient. In your case, would "2011-2012" work?
>
> Any objection to adding a "(or later)" clause to the set?
Yeah this is a stupid habit that doesn't matter anyway, in all
jurisdictions I care about copyright duration is based on the
lifetime of the author. I'll try to find out whether just adding
a copyright statement without any specific year would be fine
for my purposes.
>> +static int ip6t_npt_checkentry(const struct xt_tgchk_param *par)
>> +{
>> + struct ip6t_npt_tginfo *npt = par->targinfo;
>> + __sum16 src_sum = 0, dst_sum = 0;
>> + unsigned int i;
>> +
>> + if (npt->src_pfx_len > 64 || npt->dst_pfx_len > 64)
>> + return -EINVAL;
>
> While the RFC probably only specifies masks up to /64,
> the general algorithm is sustainable up to at least /96.
>
> Extending the RFC's section 3.6 ("/48 Prefix Mapping") example,
> fd01:0203:0405:0001:0000:0000:0000:1234/112 (specification per `ip
> addr`) would become 2001:0db8:0001:0000:0000:0000:d550:1234.
>
> Not everybody runs exclusively on EUI64-SLAAC / PRIVACY addresses :)
I'll think about it. If you want to send a patch, please go ahead ;)
>> +static struct xt_target ip6t_npt_target_reg[] __read_mostly = {
>> + {
>> + .name = "SNPT",
>
> IETF did quite a job again... NPT as an acronym is quite
> close to NAPT - too close.
> Since it's essentially NETMAP, having something in that ballpark
> may seem more fitting. NPMAP? (Translation is mapping -
> henceforh "Network Prefix Mapping")
So we'd have SNPMAP and DNPMAP. I like NPMAP, but SNPMAP and DNPMAP
don't sound that much better, so I think I prefer keeping the currently
used abrevation of Network Prefix Translation. I don't care much though.
> I would hint towards choosing a different name; the P in NPT
> may be (mis)understood as port (due to the common "NAPT")
> keyword.
Well, I think people using computers are used to tons of similar
sounding acronyms and abrevations. They'll manage ;)
>> + .target = ip6t_snpt_tg,
>> + .targetsize = sizeof(struct ip6t_npt_tginfo),
>> + .checkentry = ip6t_npt_checkentry,
>> + .family = NFPROTO_IPV6,
>> + .hooks = (1 << NF_INET_LOCAL_IN) |
>> + (1 << NF_INET_POST_ROUTING),
>> + .me = THIS_MODULE,
>
> Should perhaps a .table = "mangle" be added?
I've been proposing to lift the mangle restriction on all targets
for years. Basically the only special thing about the mangle table
is rerouting on mark changes. Everything else works just fine in
other tables (with NAT being somewhat special as well), even marking
packets if you don't need rerouting, its even more performant in that
case since no extra routing lookups need to be done. So I don't see
a reason to impose artificial limitations.
> Are any tricks on the userspace side needed to use SNPT/SNPMAP?
> Since I spot no code telling conntrack about the address mingling,
> one would have to use -j CT --notrack or the rawpost table, like
> it's done for RAWSNAT in xtables-addons, would he not?
Yes, if connection tracking is used (which is not necessary of course)
its best to exclude the translated packets from tracking. There's
actually a lot of potential for improvement here. One thing is telling
connection tracking, if its used, about the translations, so it can
properly track packets. Another thing is, with stateless translation
you still need ALGs to take care of addresses in layer 7 protocols.
I've been thinking about how to make the existing NAT helpers work
without conntrack and NAT, but its not easy and requires a lot of
restructuring of the existing code. Its something we can still add
later, its something that just affects the kernel.
^ permalink raw reply
* Re: [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock
From: Casey Schaufler @ 2012-08-09 22:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Paris, Paul Moore, David Miller, John Stultz,
Serge E. Hallyn, lkml, James Morris,
selinux-+05T5uksL2qpZYMLLGbcSA,
john.johansen-Z7WLFzj8eWMS+FvcfC7Uqw, LSM, netdev,
Casey Schaufler
In-Reply-To: <1344549920.31104.701.camel@edumazet-glaptop>
On 8/9/2012 3:05 PM, Eric Dumazet wrote:
> On Thu, 2012-08-09 at 14:53 -0700, Casey Schaufler wrote:
>> On 8/9/2012 2:29 PM, Eric Dumazet wrote:
>>> smack_sk_alloc_security() uses smk_of_current(): What can be the
> I repeat: There are no true socket for these control packets.
OK, fine. You have an optimization. I'm good with that. Just don't
expect that the entire software stack you are taking advantage of
is going to change to accommodate your special case.
^ permalink raw reply
* Re: [PATCH 00/19] netfilter: IPv6 NAT
From: Patrick McHardy @ 2012-08-09 22:30 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, netdev
In-Reply-To: <20120809220014.GB26051@1984>
On Fri, 10 Aug 2012, Pablo Neira Ayuso wrote:
> Hi Patrick,
>
> On Thu, Aug 09, 2012 at 10:08:44PM +0200, kaber@trash.net wrote:
>> The following patches contain an updated version of IPv6 NAT against
>> Linus' current tree.
>>
>> The series is organized as follows:
>>
>> - Patches 01-03 contain bugfixes for SIP helper bugs/regressions
>> present in the current kernel
>
> Thanks, I'll pass these to David.
>
> I have also two more to fixes to oopses regarding SIP. I'm expecting
> one user to finally confirm that their issues are fixed.
If you want me to have a look as well, just send me an URL or the patches.
>> - Patches 04-06 improve conntrack fragmentation handling, the IPv6
>> parts are also a precondition for IPv6 NAT
>>
>> - Patches 07 and 08 prepare the current NAT code for conversion to
>> an address family independant core, but contain no functional
>> changes
>>
>> - Patch 09 adds the address family independant NAT core and converts
>> the existing IPv4-only NAT code to an AF-specific module
>>
>> - Patches 10 and 11 add some infrastructure for IPv6 NAT
>>
>> - Patch 12 adds IPv6 NAT support
>>
>> - Patches 13-15 add IPv6 specific NAT targets
>>
>> - Patches 16-19 add some IPv6-capable ports of existing NAT helpers
>>
>> - Patch 19 is independant of the IPv6 NAT code and adds support for
>> stateless IPv6 prefix translation, just to relieve my conscience ;)
>>
>>
>> Since the last posting numerous bugs have been fixed, I don't remember
>> all of them, the more important ones include:
>>
>> - automatic NAT module loading in ctnetlink
>>
>> - address selection when mapping to IPv6 ranges
>>
>> - handling of IPv6 fragments
>>
>> - NAT handling of ICMPv6 error messages
>
> Thanks, I was keeping the previous patchset in one branch:
>
> http://1984.lsi.us.es/git/nf-next/log/?h=nf-nat4
>
> You can also find forward ports of netlink-mmap (from Florian Westpal)
> and one for nftables from myself in that tree.
Thanks, Florian just pointed me to these trees. Will have a look at
the changes compared to my tree. I'm actually intending to finish up
the mmaped netlink work once I'm done with IPv6 NAT.
>> Besides implementing IPv6 NAT, there are no known bugs left. Userspace
>> patches will follow shortly.
>
> We have this branch for iptables IPv6 NAT:
>
> http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a=shortlog;h=refs/heads/nf-nat
>
> Let me know if you're OK with these.
For now I'll just accumulate feedback and will incorporate it into my
tree. I'll also diff them against your tree and will then send the
final result once all feedback/fixes are included.
^ permalink raw reply
* Re: [PATCH] net: ipv6: fix TCP early demux
From: Andrew Morton @ 2012-08-09 23:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1344265773.26674.27.camel@edumazet-glaptop>
On Mon, 06 Aug 2012 17:09:33 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> IPv6 needs a cookie in dst_check() call.
>
> We need to add rx_dst_cookie and provide a family independent
> sk_rx_dst_set(sk, skb) method to properly support IPv6 TCP early demux.
My test box is oopsing late in initscripts. Current mainline, config
at http://ozlabs.org/~akpm/stuff/config-akpm2.
It looks like icsk->icsk_af_ops->sk_rx_dst_set is NULL. Reverting this
patch fixes things up.
[ 67.422369] SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
[ 67.449678] SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
[ 92.631060] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 92.631435] IP: [< (null)>] (null)
[ 92.631645] PGD 0
[ 92.631846] Oops: 0010 [#1] SMP
[ 92.632095] Modules linked in: autofs4 sunrpc ipv6 dm_mirror dm_region_hash dm_log dm_multipath dm_mod video sbs sbshc battery ac lp parport sg snd_hda_intel snd_hda_codec snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device pcspkr snd_pcm_oss snd_mixer_oss snd_pcm snd_timer serio_raw button floppy snd i2c_i801 i2c_core soundcore snd_page_alloc shpchp ide_cd_mod cdrom microcode ehci_hcd ohci_hcd uhci_hcd
[ 92.634294] CPU 0
[ 92.634294] Pid: 4469, comm: sendmail Not tainted 3.6.0-rc1 #3
[ 92.634294] RIP: 0010:[<0000000000000000>] [< (null)>] (null)
[ 92.634294] RSP: 0018:ffff880245fc7cb0 EFLAGS: 00010282
[ 92.634294] RAX: ffffffffa01985f0 RBX: ffff88024827ad00 RCX: 0000000000000000
[ 92.634294] RDX: 0000000000000218 RSI: ffff880254735380 RDI: ffff88024827ad00
[ 92.634294] RBP: ffff880245fc7cc8 R08: 0000000000000001 R09: 0000000000000000
[ 92.634294] R10: 0000000000000000 R11: ffff880245fc7bf8 R12: ffff880254735380
[ 92.634294] R13: ffff880254735380 R14: 0000000000000000 R15: 7fffffffffff0218
[ 92.634294] FS: 00007f4516ccd6f0(0000) GS:ffff880256600000(0000) knlGS:0000000000000000
[ 92.634294] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 92.634294] CR2: 0000000000000000 CR3: 0000000245ed1000 CR4: 00000000000007f0
[ 92.634294] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 92.634294] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 92.634294] Process sendmail (pid: 4469, threadinfo ffff880245fc6000, task ffff880254b8cac0)
[ 92.634294] Stack:
[ 92.634294] ffffffff813837a7 ffff88024827ad00 ffff880254b6b0e8 ffff880245fc7d68
[ 92.634294] ffffffff81385083 00000000001d2680 ffff8802547353a8 ffff880245fc7d18
[ 92.634294] ffffffff8105903a ffff88024827ad60 0000000000000002 00000000000000ff
[ 92.634294] Call Trace:
[ 92.634294] [<ffffffff813837a7>] ? tcp_finish_connect+0x2c/0xfa
[ 92.634294] [<ffffffff81385083>] tcp_rcv_state_process+0x2b6/0x9c6
[ 92.634294] [<ffffffff8105903a>] ? sched_clock_cpu+0xc3/0xd1
[ 92.634294] [<ffffffff81059073>] ? local_clock+0x2b/0x3c
[ 92.634294] [<ffffffff8138caf3>] tcp_v4_do_rcv+0x63a/0x670
[ 92.634294] [<ffffffff8133278e>] release_sock+0x128/0x1bd
[ 92.634294] [<ffffffff8139f060>] __inet_stream_connect+0x1b1/0x352
[ 92.634294] [<ffffffff813325f5>] ? lock_sock_nested+0x74/0x7f
[ 92.634294] [<ffffffff8104b333>] ? wake_up_bit+0x25/0x25
[ 92.634294] [<ffffffff813325f5>] ? lock_sock_nested+0x74/0x7f
[ 92.634294] [<ffffffff8139f223>] ? inet_stream_connect+0x22/0x4b
[ 92.634294] [<ffffffff8139f234>] inet_stream_connect+0x33/0x4b
[ 92.634294] [<ffffffff8132e8cf>] sys_connect+0x78/0x9e
[ 92.634294] [<ffffffff813fd407>] ? sysret_check+0x1b/0x56
[ 92.634294] [<ffffffff81088503>] ? __audit_syscall_entry+0x195/0x1c8
[ 92.634294] [<ffffffff811cc26e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 92.634294] [<ffffffff813fd3e2>] system_call_fastpath+0x16/0x1b
[ 92.634294] Code: Bad RIP value.
[ 92.634294] RIP [< (null)>] (null)
[ 92.634294] RSP <ffff880245fc7cb0>
[ 92.634294] CR2: 0000000000000000
[ 92.648982] ---[ end trace 24e2bed94314c8d9 ]---
[ 92.649146] Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* Re: [PATCH][XFRM][v2] Replace rwlock on xfrm_policy_afinfo with rcu
From: David Miller @ 2012-08-09 23:15 UTC (permalink / raw)
To: Priyanka.Jain; +Cc: netdev
In-Reply-To: <1344493315-2505-1-git-send-email-Priyanka.Jain@freescale.com>
From: Priyanka Jain <Priyanka.Jain@freescale.com>
Date: Thu, 9 Aug 2012 11:51:55 +0530
> + local_bh_disable();
> + rcu_read_lock();
This is "rcu_read_lock_bh()"
Also I do not believe you addressed any of Eric Dumazet's feedback.
^ permalink raw reply
* Re: [PATCH] tun: don't zeroize sock->file on detach
From: David Miller @ 2012-08-09 23:16 UTC (permalink / raw)
To: skinsbursky; +Cc: dhowells, netdev, rick.jones2, ycheng, linux-kernel
In-Reply-To: <20120809124436.5156.26944.stgit@localhost.localdomain>
From: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date: Thu, 09 Aug 2012 16:50:40 +0400
> This is a fix for bug, introduced in 3.4 kernel by commit
> 1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d, which, among other things, replaced
> simple sock_put() by sk_release_kernel(). Below is sequence, which leads to
> oops for non-persistent devices:
>
> tun_chr_close()
> tun_detach() <== tun->socket.file = NULL
> tun_free_netdev()
> sk_release_sock()
> sock_release(sock->file == NULL)
> iput(SOCK_INODE(sock)) <== dereference on NULL pointer
>
> This patch just removes zeroing of socket's file from __tun_detach().
> sock_release() will do this.
>
> Cc: stable@vger.kernel.org
> Reported-by: Ruan Zhijie <ruanzhijie@hotmail.com>
> Tested-by: Ruan Zhijie <ruanzhijie@hotmail.com>
> Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
> Acked-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] time: jiffies_delta_to_clock_t() helper to the rescue
From: David Miller @ 2012-08-09 23:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, linux-kernel, tglx, maze, paul.gortmaker, akpm, pyu
In-Reply-To: <1344496433.28967.443.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 09 Aug 2012 09:13:53 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Various /proc/net files sometimes report crazy timer values, expressed
> in clock_t units.
>
> This happens when an expired timer delta (expires - jiffies) is passed
> to jiffies_to_clock_t().
>
> This function has an overflow in :
>
> return div_u64((u64)x * TICK_NSEC, NSEC_PER_SEC / USER_HZ);
>
> commit cbbc719fccdb8cb (time: Change jiffies_to_clock_t() argument type
> to unsigned long) only got around the problem.
>
> As we cant output negative values in /proc/net/tcp without breaking
> various tools, I suggest adding a jiffies_delta_to_clock_t() wrapper
> that caps the negative delta to a 0 value.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Maciej Żenczykowski <maze@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next 0/5] Per-net and on-demand link indices (and related) v3
From: David Miller @ 2012-08-09 23:18 UTC (permalink / raw)
To: xemul; +Cc: eric.dumazet, ebiederm, netdev, bhutchings
In-Reply-To: <50236C20.4050108@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Thu, 09 Aug 2012 11:52:00 +0400
> This set tries to summarize the recent discussion of making ifindices friendly
> to checkpoint-restore and consists of:
>
> 1. Prepare hash function to non-unique ifindices
> 2. Allow for specifying the desired ifindex on net link creation
> 3. Make ifindex generation per-net
> 4. Simplify loopback device ifindex access
Looks good, all applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net 0/2] bnx2x: bug fixes patch series
From: David Miller @ 2012-08-09 23:20 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, eilong
In-Reply-To: <1344523046-31577-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Thu, 9 Aug 2012 17:37:24 +0300
> This series contains fixes for bnx2x's 'unload previous driver' flow
> and its recovery flow.
>
> Please consider applying these patches to 'net'.
Both patches applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 0/14] some netpoll and netconsole fixes
From: David Miller @ 2012-08-09 23:30 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1344524426-11588-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Thu, 9 Aug 2012 23:00:12 +0800
> V3:
> * add more patches
> * update patch 7 as David suggested
>
> V2:
> * update patch 1/8 as Eric suggested
> * drop the bridge patch, add comments instead
> * add patch 8/8
>
> This patchset fixes serval problems in netconsole and netpoll.
>
> I ran this patch in my KVM guest with some netpoll test cases,
> even covered with some corner cases, everything worked as expected.
All applied to 'net', thanks for fixing all of this stuff.
^ permalink raw reply
* Re: [PATCH v3 0/14] some netpoll and netconsole fixes
From: David Miller @ 2012-08-09 23:36 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <20120809.163046.584126910434037730.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 09 Aug 2012 16:30:46 -0700 (PDT)
> From: Cong Wang <amwang@redhat.com>
> Date: Thu, 9 Aug 2012 23:00:12 +0800
>
>> V3:
>> * add more patches
>> * update patch 7 as David suggested
>>
>> V2:
>> * update patch 1/8 as Eric suggested
>> * drop the bridge patch, add comments instead
>> * add patch 8/8
>>
>> This patchset fixes serval problems in netconsole and netpoll.
>>
>> I ran this patch in my KVM guest with some netpoll test cases,
>> even covered with some corner cases, everything worked as expected.
>
> All applied to 'net', thanks for fixing all of this stuff.
Actually, you didn't test the build very well, I'm reverting:
In file included from drivers/net/team/team_mode_broadcast.c:17:0:
include/linux/if_team.h: In function ‘team_dev_queue_xmit’:
include/linux/if_team.h:107:6: error: dereferencing pointer to incomplete type
make[3]: *** [drivers/net/team/team_mode_broadcast.o] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from drivers/net/team/team.c:31:0:
include/linux/if_team.h: In function ‘team_dev_queue_xmit’:
include/linux/if_team.h:107:6: error: dereferencing pointer to incomplete type
make[3]: *** [drivers/net/team/team.o] Error 1
make[2]: *** [drivers/net/team] Error 2
make[2]: *** Waiting for unfinished jobs....
^ permalink raw reply
* Re: [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock
From: David Miller @ 2012-08-09 23:38 UTC (permalink / raw)
To: eric.dumazet
Cc: eparis, paul, casey, johnstul, serge, linux-kernel,
james.l.morris, selinux, john.johansen, linux-security-module,
netdev
In-Reply-To: <1344547743.31104.582.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 09 Aug 2012 23:29:03 +0200
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 76dde25..ec410e0 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -1536,6 +1536,7 @@ void ip_send_unicast_reply(struct net *net, struct sk_buff *skb, __be32 daddr,
> arg->csumoffset) = csum_fold(csum_add(nskb->csum,
> arg->csum));
> nskb->ip_summed = CHECKSUM_NONE;
> + skb_orphan(nskb);
> skb_set_queue_mapping(nskb, skb_get_queue_mapping(skb));
> ip_push_pending_frames(sk, &fl4);
> }
>
This is definitely the best fix, please submit this formally.
^ permalink raw reply
* Re: [net-next] bonding: don't allow the master to become its slave
From: David Miller @ 2012-08-09 23:43 UTC (permalink / raw)
To: fubar; +Cc: bhutchings, jpirko, fbl, netdev, andy, lchiquitto
In-Reply-To: <22811.1344547628@death.nxdomain>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Thu, 09 Aug 2012 14:27:08 -0700
> If that's hard to do (and it might be; I'm not aware of a
> standard way to run up and down those stacks of interfaces, which might
> not always be vlans in the middle), there's still the priv_flags &
> IFF_BONDING test that bonding could (and probably should) do itself as
> well. The team driver could presumably have a similar test, although I
> seem to recall that team was allowed to nest.
>
> FWIW, I've seen both the top and bottom halves of that picture
> in use (i.e., bonds consisting of vlans as slaves or bonds with vlans
> configured above them), but not combined as in your diagram.
We're basically looking for cycles in a complex graph.
Some combination of Jay and Ben's most recent patches, with some minor
modifications, ought to do it.
^ permalink raw reply
* Re: [PATCH net-next,1/1] hyperv: Add comments for the extended buffer after RNDIS message
From: David Miller @ 2012-08-09 23:45 UTC (permalink / raw)
To: haiyangz; +Cc: netdev, kys, olaf, linux-kernel, devel
In-Reply-To: <1344535458-3613-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Thu, 9 Aug 2012 11:04:18 -0700
> Reported-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] ipv4: tcp: unicast_sock should not land outside of TCP stack
From: Eric Dumazet @ 2012-08-09 23:56 UTC (permalink / raw)
To: David Miller
Cc: eparis, paul, casey, johnstul, serge, linux-kernel,
james.l.morris, selinux, john.johansen, linux-security-module,
netdev
In-Reply-To: <20120809.163851.1182547052663187702.davem@davemloft.net>
From: Eric Dumazet <edumazet@google.com>
commit be9f4a44e7d41cee (ipv4: tcp: remove per net tcp_sock) added a
selinux regression, reported and bisected by John Stultz
selinux_ip_postroute_compat() expect to find a valid sk->sk_security
pointer, but this field is NULL for unicast_sock
It turns out that unicast_sock are really temporary stuff to be able
to reuse part of IP stack (ip_append_data()/ip_push_pending_frames())
Fact is that frames sent by ip_send_unicast_reply() should be orphaned
to not fool LSM.
Note IPv6 never had this problem, as tcp_v6_send_response() doesnt use a
fake socket at all. I'll probably implement tcp_v4_send_response() to
remove these unicast_sock in linux-3.7
Reported-by: John Stultz <johnstul@us.ibm.com>
Bisected-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Eric Paris <eparis@parisplace.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
---
net/ipv4/ip_output.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 76dde25..ec410e0 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1536,6 +1536,7 @@ void ip_send_unicast_reply(struct net *net, struct sk_buff *skb, __be32 daddr,
arg->csumoffset) = csum_fold(csum_add(nskb->csum,
arg->csum));
nskb->ip_summed = CHECKSUM_NONE;
+ skb_orphan(nskb);
skb_set_queue_mapping(nskb, skb_get_queue_mapping(skb));
ip_push_pending_frames(sk, &fl4);
}
^ permalink raw reply related
* Re: [PATCH] net: ipv6: fix TCP early demux
From: Eric Dumazet @ 2012-08-09 23:58 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, netdev
In-Reply-To: <20120809160349.d2880b5a.akpm@linux-foundation.org>
On Thu, 2012-08-09 at 16:03 -0700, Andrew Morton wrote:
> On Mon, 06 Aug 2012 17:09:33 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > IPv6 needs a cookie in dst_check() call.
> >
> > We need to add rx_dst_cookie and provide a family independent
> > sk_rx_dst_set(sk, skb) method to properly support IPv6 TCP early demux.
>
> My test box is oopsing late in initscripts. Current mainline, config
> at http://ozlabs.org/~akpm/stuff/config-akpm2.
>
> It looks like icsk->icsk_af_ops->sk_rx_dst_set is NULL. Reverting this
> patch fixes things up.
>
>
> [ 67.422369] SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
> [ 67.449678] SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
> [ 92.631060] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 92.631435] IP: [< (null)>] (null)
> [ 92.631645] PGD 0
> [ 92.631846] Oops: 0010 [#1] SMP
> [ 92.632095] Modules linked in: autofs4 sunrpc ipv6 dm_mirror dm_region_hash dm_log dm_multipath dm_mod video sbs sbshc battery ac lp parport sg snd_hda_intel snd_hda_codec snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device pcspkr snd_pcm_oss snd_mixer_oss snd_pcm snd_timer serio_raw button floppy snd i2c_i801 i2c_core soundcore snd_page_alloc shpchp ide_cd_mod cdrom microcode ehci_hcd ohci_hcd uhci_hcd
> [ 92.634294] CPU 0
> [ 92.634294] Pid: 4469, comm: sendmail Not tainted 3.6.0-rc1 #3
> [ 92.634294] RIP: 0010:[<0000000000000000>] [< (null)>] (null)
> [ 92.634294] RSP: 0018:ffff880245fc7cb0 EFLAGS: 00010282
> [ 92.634294] RAX: ffffffffa01985f0 RBX: ffff88024827ad00 RCX: 0000000000000000
> [ 92.634294] RDX: 0000000000000218 RSI: ffff880254735380 RDI: ffff88024827ad00
> [ 92.634294] RBP: ffff880245fc7cc8 R08: 0000000000000001 R09: 0000000000000000
> [ 92.634294] R10: 0000000000000000 R11: ffff880245fc7bf8 R12: ffff880254735380
> [ 92.634294] R13: ffff880254735380 R14: 0000000000000000 R15: 7fffffffffff0218
> [ 92.634294] FS: 00007f4516ccd6f0(0000) GS:ffff880256600000(0000) knlGS:0000000000000000
> [ 92.634294] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 92.634294] CR2: 0000000000000000 CR3: 0000000245ed1000 CR4: 00000000000007f0
> [ 92.634294] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 92.634294] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 92.634294] Process sendmail (pid: 4469, threadinfo ffff880245fc6000, task ffff880254b8cac0)
> [ 92.634294] Stack:
> [ 92.634294] ffffffff813837a7 ffff88024827ad00 ffff880254b6b0e8 ffff880245fc7d68
> [ 92.634294] ffffffff81385083 00000000001d2680 ffff8802547353a8 ffff880245fc7d18
> [ 92.634294] ffffffff8105903a ffff88024827ad60 0000000000000002 00000000000000ff
> [ 92.634294] Call Trace:
> [ 92.634294] [<ffffffff813837a7>] ? tcp_finish_connect+0x2c/0xfa
> [ 92.634294] [<ffffffff81385083>] tcp_rcv_state_process+0x2b6/0x9c6
> [ 92.634294] [<ffffffff8105903a>] ? sched_clock_cpu+0xc3/0xd1
> [ 92.634294] [<ffffffff81059073>] ? local_clock+0x2b/0x3c
> [ 92.634294] [<ffffffff8138caf3>] tcp_v4_do_rcv+0x63a/0x670
> [ 92.634294] [<ffffffff8133278e>] release_sock+0x128/0x1bd
> [ 92.634294] [<ffffffff8139f060>] __inet_stream_connect+0x1b1/0x352
> [ 92.634294] [<ffffffff813325f5>] ? lock_sock_nested+0x74/0x7f
> [ 92.634294] [<ffffffff8104b333>] ? wake_up_bit+0x25/0x25
> [ 92.634294] [<ffffffff813325f5>] ? lock_sock_nested+0x74/0x7f
> [ 92.634294] [<ffffffff8139f223>] ? inet_stream_connect+0x22/0x4b
> [ 92.634294] [<ffffffff8139f234>] inet_stream_connect+0x33/0x4b
> [ 92.634294] [<ffffffff8132e8cf>] sys_connect+0x78/0x9e
> [ 92.634294] [<ffffffff813fd407>] ? sysret_check+0x1b/0x56
> [ 92.634294] [<ffffffff81088503>] ? __audit_syscall_entry+0x195/0x1c8
> [ 92.634294] [<ffffffff811cc26e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 92.634294] [<ffffffff813fd3e2>] system_call_fastpath+0x16/0x1b
> [ 92.634294] Code: Bad RIP value.
> [ 92.634294] RIP [< (null)>] (null)
> [ 92.634294] RSP <ffff880245fc7cb0>
> [ 92.634294] CR2: 0000000000000000
> [ 92.648982] ---[ end trace 24e2bed94314c8d9 ]---
> [ 92.649146] Kernel panic - not syncing: Fatal exception in interrupt
Oops, it seems I missed ipv6_mapped
Thanks Andrew, I'll send a fix
^ permalink raw reply
* [PATCH] net: tcp: ipv6_mapped needs sk_rx_dst_set method
From: Eric Dumazet @ 2012-08-10 0:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, netdev
In-Reply-To: <1344556733.31104.819.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
commit 5d299f3d3c8a2fb (net: ipv6: fix TCP early demux) added a
regression for ipv6_mapped case.
[ 67.422369] SELinux: initialized (dev autofs, type autofs), uses
genfs_contexts
[ 67.449678] SELinux: initialized (dev autofs, type autofs), uses
genfs_contexts
[ 92.631060] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 92.631435] IP: [< (null)>] (null)
[ 92.631645] PGD 0
[ 92.631846] Oops: 0010 [#1] SMP
[ 92.632095] Modules linked in: autofs4 sunrpc ipv6 dm_mirror
dm_region_hash dm_log dm_multipath dm_mod video sbs sbshc battery ac lp
parport sg snd_hda_intel snd_hda_codec snd_seq_oss snd_seq_midi_event
snd_seq snd_seq_device pcspkr snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer serio_raw button floppy snd i2c_i801 i2c_core soundcore
snd_page_alloc shpchp ide_cd_mod cdrom microcode ehci_hcd ohci_hcd
uhci_hcd
[ 92.634294] CPU 0
[ 92.634294] Pid: 4469, comm: sendmail Not tainted 3.6.0-rc1 #3
[ 92.634294] RIP: 0010:[<0000000000000000>] [< (null)>]
(null)
[ 92.634294] RSP: 0018:ffff880245fc7cb0 EFLAGS: 00010282
[ 92.634294] RAX: ffffffffa01985f0 RBX: ffff88024827ad00 RCX:
0000000000000000
[ 92.634294] RDX: 0000000000000218 RSI: ffff880254735380 RDI:
ffff88024827ad00
[ 92.634294] RBP: ffff880245fc7cc8 R08: 0000000000000001 R09:
0000000000000000
[ 92.634294] R10: 0000000000000000 R11: ffff880245fc7bf8 R12:
ffff880254735380
[ 92.634294] R13: ffff880254735380 R14: 0000000000000000 R15:
7fffffffffff0218
[ 92.634294] FS: 00007f4516ccd6f0(0000) GS:ffff880256600000(0000)
knlGS:0000000000000000
[ 92.634294] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 92.634294] CR2: 0000000000000000 CR3: 0000000245ed1000 CR4:
00000000000007f0
[ 92.634294] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 92.634294] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 92.634294] Process sendmail (pid: 4469, threadinfo ffff880245fc6000,
task ffff880254b8cac0)
[ 92.634294] Stack:
[ 92.634294] ffffffff813837a7 ffff88024827ad00 ffff880254b6b0e8
ffff880245fc7d68
[ 92.634294] ffffffff81385083 00000000001d2680 ffff8802547353a8
ffff880245fc7d18
[ 92.634294] ffffffff8105903a ffff88024827ad60 0000000000000002
00000000000000ff
[ 92.634294] Call Trace:
[ 92.634294] [<ffffffff813837a7>] ? tcp_finish_connect+0x2c/0xfa
[ 92.634294] [<ffffffff81385083>] tcp_rcv_state_process+0x2b6/0x9c6
[ 92.634294] [<ffffffff8105903a>] ? sched_clock_cpu+0xc3/0xd1
[ 92.634294] [<ffffffff81059073>] ? local_clock+0x2b/0x3c
[ 92.634294] [<ffffffff8138caf3>] tcp_v4_do_rcv+0x63a/0x670
[ 92.634294] [<ffffffff8133278e>] release_sock+0x128/0x1bd
[ 92.634294] [<ffffffff8139f060>] __inet_stream_connect+0x1b1/0x352
[ 92.634294] [<ffffffff813325f5>] ? lock_sock_nested+0x74/0x7f
[ 92.634294] [<ffffffff8104b333>] ? wake_up_bit+0x25/0x25
[ 92.634294] [<ffffffff813325f5>] ? lock_sock_nested+0x74/0x7f
[ 92.634294] [<ffffffff8139f223>] ? inet_stream_connect+0x22/0x4b
[ 92.634294] [<ffffffff8139f234>] inet_stream_connect+0x33/0x4b
[ 92.634294] [<ffffffff8132e8cf>] sys_connect+0x78/0x9e
[ 92.634294] [<ffffffff813fd407>] ? sysret_check+0x1b/0x56
[ 92.634294] [<ffffffff81088503>] ? __audit_syscall_entry+0x195/0x1c8
[ 92.634294] [<ffffffff811cc26e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 92.634294] [<ffffffff813fd3e2>] system_call_fastpath+0x16/0x1b
[ 92.634294] Code: Bad RIP value.
[ 92.634294] RIP [< (null)>] (null)
[ 92.634294] RSP <ffff880245fc7cb0>
[ 92.634294] CR2: 0000000000000000
[ 92.648982] ---[ end trace 24e2bed94314c8d9 ]---
[ 92.649146] Kernel panic - not syncing: Fatal exception in interrupt
Fix this using inet_sk_rx_dst_set(), and export this function in case
IPv6 is modular.
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/tcp.h | 1 +
net/ipv4/tcp_ipv4.c | 3 ++-
net/ipv6/tcp_ipv6.c | 1 +
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index e19124b..1f000ff 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -464,6 +464,7 @@ extern int tcp_disconnect(struct sock *sk, int flags);
void tcp_connect_init(struct sock *sk);
void tcp_finish_connect(struct sock *sk, struct sk_buff *skb);
int tcp_send_rcvq(struct sock *sk, struct msghdr *msg, size_t size);
+void inet_sk_rx_dst_set(struct sock *sk, const struct sk_buff *skb);
/* From syncookies.c */
extern __u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS];
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 272241f..7678237 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1869,7 +1869,7 @@ static struct timewait_sock_ops tcp_timewait_sock_ops = {
.twsk_destructor= tcp_twsk_destructor,
};
-static void inet_sk_rx_dst_set(struct sock *sk, const struct sk_buff *skb)
+void inet_sk_rx_dst_set(struct sock *sk, const struct sk_buff *skb)
{
struct dst_entry *dst = skb_dst(skb);
@@ -1877,6 +1877,7 @@ static void inet_sk_rx_dst_set(struct sock *sk, const struct sk_buff *skb)
sk->sk_rx_dst = dst;
inet_sk(sk)->rx_dst_ifindex = skb->skb_iif;
}
+EXPORT_SYMBOL(inet_sk_rx_dst_set);
const struct inet_connection_sock_af_ops ipv4_specific = {
.queue_xmit = ip_queue_xmit,
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 5a439e9..bb9ce2b 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1777,6 +1777,7 @@ static const struct inet_connection_sock_af_ops ipv6_mapped = {
.queue_xmit = ip_queue_xmit,
.send_check = tcp_v4_send_check,
.rebuild_header = inet_sk_rebuild_header,
+ .sk_rx_dst_set = inet_sk_rx_dst_set,
.conn_request = tcp_v6_conn_request,
.syn_recv_sock = tcp_v6_syn_recv_sock,
.net_header_len = sizeof(struct iphdr),
^ permalink raw reply related
* RE: [PATCH] net: add new QCA alx ethernet driver
From: Huang, Xiong @ 2012-08-10 0:26 UTC (permalink / raw)
To: Ben Hutchings, Steven Rostedt
Cc: Joe Perches, Ren, Cloud, David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, qca-linux-team, nic-devel,
hao-ran.liu@canonical.com, Rodriguez, Luis
In-Reply-To: <1344538611.2593.4.camel@bwh-desktop.uk.solarflarecom.com>
> The alterations to the description of atl1c ought to be broken out as a
> separate patch, though.
>
Yes, we will separate it. thanks !
-Xiong
^ 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