* Re: linux-next: manual merge of the tip tree with the net-next tree
From: H. Peter Anvin @ 2014-01-14 4:51 UTC (permalink / raw)
To: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
David Miller, netdev
Cc: linux-next, linux-kernel
In-Reply-To: <20140114140214.7279bcaf88d7a4514d889186@canb.auug.org.au>
On 01/13/2014 07:02 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 13 Jan 2014 14:20:59 +1100 Stephen Rothwell
> <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 13 Jan 2014 14:18:24 +1100 Stephen Rothwell
>> <sfr@canb.auug.org.au> wrote:
>>>
>>> Today's linux-next merge of the tip tree got conflicts in
>>> arch/arc/include/asm/Kbuild, arch/cris/include/asm/Kbuild,
>>> arch/hexagon/include/asm/Kbuild,
>>> arch/microblaze/include/asm/Kbuild,
>>> arch/parisc/include/asm/Kbuild and
>>> arch/score/include/asm/Kbuild between commit e3fec2f74f7f
>>> ("lib: Add missing arch generic-y entries for
>>> asm-generic/hash.h") from the net-next tree and commit
>>> 93ea02bb8435 ("arch: Clean up asm/barrier.h implementations
>>> using asm-generic/barrier.h") from the tip tree.
>>>
>>> I fixed it up (see below) and can carry the fix as necessary
>>> (no action is required).
>>>
>>> BTW: thanks for not keeping the Kbuild files sorted :-(
>>
>> I missed arch/mn10300/include/asm/Kbuild the first time round.
>
> And ... git rerere does not work well here. It stores resolutions
> by a hash of the (sanitised) conflict and since most of these files
> have exactly the same conflict, I am going to have to edit 5 of
> them by hand every day.
>
Well, you probably can keep a diff from the conflict-merge tree to the
fix, but still.
Is there a sensible way we can fix this in either net-next or tip?
-hpa
^ permalink raw reply
* Re: suspicious RCU usage in net/ipv4/ip_tunnel.c:80
From: Paul E. McKenney @ 2014-01-14 4:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Cong Wang, Tom Herbert, netdev
In-Reply-To: <1389601233.31367.213.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Jan 13, 2014 at 12:20:33AM -0800, Eric Dumazet wrote:
> On Sun, 2014-01-12 at 22:36 -0800, Cong Wang wrote:
> > > Please read rcu_dereference_protected() documentation in
> > > include/linux/rcupdate.h
> >
> > I did before I replied.
>
>
>
> >
> > >
> > > Also you can run sparse, with CONFIG_SPARSE_RCU_POINTER=y in
> > > your .config
> > >
> > > make C=2 net/ipv4/ip_tunnel.o
> > >
> > > And then you'll know the answer to this question.
> > >
> >
> > Sounds like it is only to shut up a sparse warning, then its name
> > is misleading, we clearly don't dereference it here.
OK, I'll bite... This code invokes dst_release() which looks to me
like it dereferences this pointer:
void dst_release(struct dst_entry *dst)
{
if (dst) {
int newrefcnt;
newrefcnt = atomic_dec_return(&dst->__refcnt);
WARN_ON(newrefcnt < 0);
if (unlikely(dst->flags & DST_NOCACHE) && !newrefcnt) {
dst = dst_destroy(dst);
if (dst)
__dst_free(dst);
}
}
}
If you really were not dereferencing the pointer, for example, if you
were only testing it against NULL or some such, then you can use
rcu_access_pointer(). This is a bit cheaper on DEC Alpha, FWIW.
You can think of rcu_dereference() as meaning "fetch this RCU-protected
pointer with intent to dereference()" if that helps.
Or am I missing your point?
> Historical reasons, you should have been there when Paul invented the
> name and lazy people like us let him do so !
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b62730baea32f86fe91a7930e4b7ee8d82778b79
Indeed! ;-)
And rcu_dereference() is at least an improvement over the earlier
hand-placed smp_read_barrier_depends().
Thanx, Paul
> You are lucky, there is plenty of documentation, maybe too much..
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v3 2/4] net_dma: revert 'copied_early'
From: David Miller @ 2014-01-14 5:16 UTC (permalink / raw)
To: dan.j.williams
Cc: dmaengine, yoshfuji, netdev, saidi, jmorris, edumazet, kuznet,
davej, ncardwell, kaber, linux-kernel
In-Reply-To: <20140114004637.27138.50365.stgit@viggo.jf.intel.com>
From: Dan Williams <dan.j.williams@intel.com>
Date: Mon, 13 Jan 2014 16:47:14 -0800
> Now that tcp_dma_try_early_copy() is gone nothing ever sets
> copied_early.
>
> Also reverts "53240c208776 tcp: Fix possible double-ack w/ user dma"
> since it is no longer necessary.
>
> Cc: Ali Saidi <saidi@engin.umich.edu>
> Cc: James Morris <jmorris@namei.org>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Neal Cardwell <ncardwell@google.com>
> Reported-by: Dave Jones <davej@redhat.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the net-next tree
From: Stephen Rothwell @ 2014-01-14 5:19 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, David Miller,
netdev, linux-next, linux-kernel
In-Reply-To: <52D4C25F.8060804@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]
Hi,
On Mon, 13 Jan 2014 20:51:43 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 01/13/2014 07:02 PM, Stephen Rothwell wrote:
> >
> > On Mon, 13 Jan 2014 14:20:59 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> On Mon, 13 Jan 2014 14:18:24 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>>
> >>> Today's linux-next merge of the tip tree got conflicts in
> >>> arch/arc/include/asm/Kbuild, arch/cris/include/asm/Kbuild,
> >>> arch/hexagon/include/asm/Kbuild,
> >>> arch/microblaze/include/asm/Kbuild,
> >>> arch/parisc/include/asm/Kbuild and
> >>> arch/score/include/asm/Kbuild between commit e3fec2f74f7f
> >>> ("lib: Add missing arch generic-y entries for
> >>> asm-generic/hash.h") from the net-next tree and commit
> >>> 93ea02bb8435 ("arch: Clean up asm/barrier.h implementations
> >>> using asm-generic/barrier.h") from the tip tree.
> >>>
> >>> I fixed it up (see below) and can carry the fix as necessary
> >>> (no action is required).
> >>>
> >>> BTW: thanks for not keeping the Kbuild files sorted :-(
> >>
> >> I missed arch/mn10300/include/asm/Kbuild the first time round.
> >
> > And ... git rerere does not work well here. It stores resolutions
> > by a hash of the (sanitised) conflict and since most of these files
> > have exactly the same conflict, I am going to have to edit 5 of
> > them by hand every day.
> >
>
> Well, you probably can keep a diff from the conflict-merge tree to the
> fix, but still.
>
> Is there a sensible way we can fix this in either net-next or tip?
Probably not now. If the respective patches had kept those Kbuild files
sorted, then (most of the) conflicts would not have happened.
Maybe if there were follow up patches that put them back in order it may
help. Or at least maybe make the conflicts different enough so that
git rerere would store them all.
I am just grumbling because I guessed this would happen when I saw the
patch go into the next-next tree (unfortunately, it was a report of mine
that caused that patch to be created :-().
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the net-next tree
From: David Miller @ 2014-01-14 5:19 UTC (permalink / raw)
To: hpa; +Cc: sfr, tglx, mingo, peterz, netdev, linux-next, linux-kernel
In-Reply-To: <52D4C25F.8060804@zytor.com>
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 13 Jan 2014 20:51:43 -0800
> Is there a sensible way we can fix this in either net-next or tip?
I think if I sort the files in net-next the problem will go away,
if someone can confirm this I'll do it.
^ permalink raw reply
* RE: [PATCH net-next 0/8] qlcnic driver updates
From: Shahed Shaikh @ 2014-01-14 5:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept-NX Linux NIC Driver
In-Reply-To: <20140113.153255.182055320418133623.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, January 14, 2014 5:03 AM
> To: Shahed Shaikh
> Cc: netdev; Dept-NX Linux NIC Driver
> Subject: Re: [PATCH net-next 0/8] qlcnic driver updates
>
> From: Shahed Shaikh <shahed.shaikh@qlogic.com>
> Date: Fri, 10 Jan 2014 11:48:51 -0500
>
> > This series includes following changes:
> > o SRIOV and VLAN filtering related enhancements which includes
> > - Do MAC learning for PF
> > - Restrict VF from configuring any VLAN mode
> > - Enable flooding on PF
> > - Turn on promiscuous mode for PF
> >
> > o Bug fix in qlcnic_sriov_cleanup() introduced by commit
> > 154d0c81("qlcnic: VLAN enhancement for 84XX adapters")
> >
> > o Beaconing support for 83xx and 84xx series adapters
> >
> > o Allow 82xx adapter to perform IPv6 LRO even if destination IP address is
> not
> > programmed.
> >
> > Please apply this series to net-next.
>
> Series applied, but you really should make rx_mac_learn a bool just like
> drv_mac_learn and fdb_mac_learn already are.
Thanks David. We will a send patch to make rx_mac_lean a bool.
Thanks,
Shahed
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: move IPV6_TCLASS_SHIFT into ipv6.h
From: David Miller @ 2014-01-14 5:25 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1389348199-5855-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Fri, 10 Jan 2014 18:03:18 +0800
> @@ -150,6 +150,8 @@ static int fib6_rule_match(struct fib_rule *rule, struct flowi *fl, int flags)
> {
> struct fib6_rule *r = (struct fib6_rule *) rule;
> struct flowi6 *fl6 = &fl->u.ip6;
> + u8 tclass = ntohl(fl6->flowlabel & IPV6_TCLASS_MASK) >>
> + IPV6_TCLASS_SHIFT;
As others have mentioned, please make a helper inline function or
macro for this calculation. It happens in two places.
Thanks.
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the net-next tree
From: Stephen Rothwell @ 2014-01-14 5:44 UTC (permalink / raw)
To: David Miller; +Cc: hpa, tglx, mingo, peterz, netdev, linux-next, linux-kernel
In-Reply-To: <20140113.211946.205101073261467184.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 670 bytes --]
On Mon, 13 Jan 2014 21:19:46 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: "H. Peter Anvin" <hpa@zytor.com>
> Date: Mon, 13 Jan 2014 20:51:43 -0800
>
> > Is there a sensible way we can fix this in either net-next or tip?
>
> I think if I sort the files in net-next the problem will go away,
> if someone can confirm this I'll do it.
I have attached 2 patches: one for net-next and one for tip/auto-latest
(but should be applicable in the appropriate topic branch). If both are
applied to their respect trees, then I get no conflict when merging the
two trees.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-net-resort-some-Kbuild-files-to-hopefully-help-avoid.patch --]
[-- Type: text/x-diff; name="0001-net-resort-some-Kbuild-files-to-hopefully-help-avoid.patch", Size: 3338 bytes --]
>From da6b3ed2f43d1a0c5e946d11902c167eb6188cca Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 14 Jan 2014 16:37:45 +1100
Subject: [PATCH] net: resort some Kbuild files to hopefully help avoid some
conflicts
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arc/include/asm/Kbuild | 2 +-
arch/cris/include/asm/Kbuild | 2 +-
arch/hexagon/include/asm/Kbuild | 2 +-
arch/microblaze/include/asm/Kbuild | 2 +-
arch/mn10300/include/asm/Kbuild | 2 +-
arch/score/include/asm/Kbuild | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index 93e6ca919620..cf29d84fd9c2 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -11,6 +11,7 @@ generic-y += fcntl.h
generic-y += fb.h
generic-y += ftrace.h
generic-y += hardirq.h
+generic-y += hash.h
generic-y += hw_irq.h
generic-y += ioctl.h
generic-y += ioctls.h
@@ -47,4 +48,3 @@ generic-y += user.h
generic-y += vga.h
generic-y += xor.h
generic-y += preempt.h
-generic-y += hash.h
diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild
index c5963b3e4624..406cbd3ebd58 100644
--- a/arch/cris/include/asm/Kbuild
+++ b/arch/cris/include/asm/Kbuild
@@ -5,6 +5,7 @@ header-y += arch-v32/
generic-y += clkdev.h
generic-y += exec.h
+generic-y += hash.h
generic-y += kvm_para.h
generic-y += linkage.h
generic-y += module.h
@@ -12,4 +13,3 @@ generic-y += trace_clock.h
generic-y += vga.h
generic-y += xor.h
generic-y += preempt.h
-generic-y += hash.h
diff --git a/arch/hexagon/include/asm/Kbuild b/arch/hexagon/include/asm/Kbuild
index 469d223950ff..ae45d75a3187 100644
--- a/arch/hexagon/include/asm/Kbuild
+++ b/arch/hexagon/include/asm/Kbuild
@@ -15,6 +15,7 @@ generic-y += fb.h
generic-y += fcntl.h
generic-y += ftrace.h
generic-y += hardirq.h
+generic-y += hash.h
generic-y += hw_irq.h
generic-y += ioctl.h
generic-y += ioctls.h
@@ -54,4 +55,3 @@ generic-y += ucontext.h
generic-y += unaligned.h
generic-y += xor.h
generic-y += preempt.h
-generic-y += hash.h
diff --git a/arch/microblaze/include/asm/Kbuild b/arch/microblaze/include/asm/Kbuild
index 43eec338ff50..ca60945ddf30 100644
--- a/arch/microblaze/include/asm/Kbuild
+++ b/arch/microblaze/include/asm/Kbuild
@@ -1,7 +1,7 @@
generic-y += clkdev.h
generic-y += exec.h
+generic-y += hash.h
generic-y += trace_clock.h
generic-y += syscalls.h
generic-y += preempt.h
-generic-y += hash.h
diff --git a/arch/mn10300/include/asm/Kbuild b/arch/mn10300/include/asm/Kbuild
index bc42f14c9c2e..199345207d82 100644
--- a/arch/mn10300/include/asm/Kbuild
+++ b/arch/mn10300/include/asm/Kbuild
@@ -1,6 +1,6 @@
generic-y += clkdev.h
generic-y += exec.h
+generic-y += hash.h
generic-y += trace_clock.h
generic-y += preempt.h
-generic-y += hash.h
diff --git a/arch/score/include/asm/Kbuild b/arch/score/include/asm/Kbuild
index 099e7ba40599..1d35e33ccf86 100644
--- a/arch/score/include/asm/Kbuild
+++ b/arch/score/include/asm/Kbuild
@@ -2,8 +2,8 @@
header-y +=
generic-y += clkdev.h
+generic-y += hash.h
generic-y += trace_clock.h
generic-y += xor.h
generic-y += preempt.h
-generic-y += hash.h
--
1.8.5.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: 0001-tip-resort-some-Kbuild-files-to-hopefully-help-avoid.patch --]
[-- Type: text/x-diff; name="0001-tip-resort-some-Kbuild-files-to-hopefully-help-avoid.patch", Size: 3862 bytes --]
>From 6d0a3746f35cb879189228093728251b7ce04135 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 14 Jan 2014 16:36:10 +1100
Subject: [PATCH] tip: resort some Kbuild files to hopefully help avoid some
conflicts
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arc/include/asm/Kbuild | 2 +-
arch/cris/include/asm/Kbuild | 2 +-
arch/hexagon/include/asm/Kbuild | 2 +-
arch/microblaze/include/asm/Kbuild | 2 +-
arch/mn10300/include/asm/Kbuild | 2 +-
arch/parisc/include/asm/Kbuild | 2 +-
arch/score/include/asm/Kbuild | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index e07c786011af..9ae21c198007 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -1,4 +1,5 @@
generic-y += auxvec.h
+generic-y += barrier.h
generic-y += bugs.h
generic-y += bitsperlong.h
generic-y += clkdev.h
@@ -47,4 +48,3 @@ generic-y += user.h
generic-y += vga.h
generic-y += xor.h
generic-y += preempt.h
-generic-y += barrier.h
diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild
index 35ec2e5ca832..199b1a9dab89 100644
--- a/arch/cris/include/asm/Kbuild
+++ b/arch/cris/include/asm/Kbuild
@@ -3,6 +3,7 @@ header-y += arch-v10/
header-y += arch-v32/
+generic-y += barrier.h
generic-y += clkdev.h
generic-y += exec.h
generic-y += kvm_para.h
@@ -12,4 +13,3 @@ generic-y += trace_clock.h
generic-y += vga.h
generic-y += xor.h
generic-y += preempt.h
-generic-y += barrier.h
diff --git a/arch/hexagon/include/asm/Kbuild b/arch/hexagon/include/asm/Kbuild
index a614ec9747a6..ada843c701ef 100644
--- a/arch/hexagon/include/asm/Kbuild
+++ b/arch/hexagon/include/asm/Kbuild
@@ -2,6 +2,7 @@
header-y += ucontext.h
generic-y += auxvec.h
+generic-y += barrier.h
generic-y += bug.h
generic-y += bugs.h
generic-y += clkdev.h
@@ -54,4 +55,3 @@ generic-y += ucontext.h
generic-y += unaligned.h
generic-y += xor.h
generic-y += preempt.h
-generic-y += barrier.h
diff --git a/arch/microblaze/include/asm/Kbuild b/arch/microblaze/include/asm/Kbuild
index f77fb6630b11..a82426589fff 100644
--- a/arch/microblaze/include/asm/Kbuild
+++ b/arch/microblaze/include/asm/Kbuild
@@ -1,7 +1,7 @@
+generic-y += barrier.h
generic-y += clkdev.h
generic-y += exec.h
generic-y += trace_clock.h
generic-y += syscalls.h
generic-y += preempt.h
-generic-y += barrier.h
diff --git a/arch/mn10300/include/asm/Kbuild b/arch/mn10300/include/asm/Kbuild
index 367ef399ddf7..032143ec2324 100644
--- a/arch/mn10300/include/asm/Kbuild
+++ b/arch/mn10300/include/asm/Kbuild
@@ -1,6 +1,6 @@
+generic-y += barrier.h
generic-y += clkdev.h
generic-y += exec.h
generic-y += trace_clock.h
generic-y += preempt.h
-generic-y += barrier.h
diff --git a/arch/parisc/include/asm/Kbuild b/arch/parisc/include/asm/Kbuild
index 8df06d0074f4..34b0be4ca52d 100644
--- a/arch/parisc/include/asm/Kbuild
+++ b/arch/parisc/include/asm/Kbuild
@@ -1,8 +1,8 @@
+generic-y += barrier.h
generic-y += word-at-a-time.h auxvec.h user.h cputime.h emergency-restart.h \
segment.h topology.h vga.h device.h percpu.h hw_irq.h mutex.h \
div64.h irq_regs.h kdebug.h kvm_para.h local64.h local.h param.h \
poll.h xor.h clkdev.h exec.h
generic-y += trace_clock.h
generic-y += preempt.h
-generic-y += barrier.h
diff --git a/arch/score/include/asm/Kbuild b/arch/score/include/asm/Kbuild
index ee2993b6e5d1..fe7471eb0167 100644
--- a/arch/score/include/asm/Kbuild
+++ b/arch/score/include/asm/Kbuild
@@ -1,8 +1,8 @@
header-y +=
+generic-y += barrier.h
generic-y += clkdev.h
generic-y += trace_clock.h
generic-y += xor.h
generic-y += preempt.h
-generic-y += barrier.h
--
1.8.5.2
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: linux-next: manual merge of the tip tree with the net-next tree
From: David Miller @ 2014-01-14 5:48 UTC (permalink / raw)
To: sfr; +Cc: hpa, tglx, mingo, peterz, netdev, linux-next, linux-kernel
In-Reply-To: <20140114164420.d296fbcc4be3a5f126c86069@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 14 Jan 2014 16:44:20 +1100
> On Mon, 13 Jan 2014 21:19:46 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>>
>> From: "H. Peter Anvin" <hpa@zytor.com>
>> Date: Mon, 13 Jan 2014 20:51:43 -0800
>>
>> > Is there a sensible way we can fix this in either net-next or tip?
>>
>> I think if I sort the files in net-next the problem will go away,
>> if someone can confirm this I'll do it.
>
> I have attached 2 patches: one for net-next and one for tip/auto-latest
> (but should be applicable in the appropriate topic branch). If both are
> applied to their respect trees, then I get no conflict when merging the
> two trees.
Net patch applied, thanks Stephen.
^ permalink raw reply
* Re: pull request: batman-adv 2014-01-13
From: David Miller @ 2014-01-14 5:50 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1389652298-472-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Mon, 13 Jan 2014 23:31:24 +0100
> here you have another pull request intended for net-next/linux-3.14.
Pulled, thanks Antonio.
^ permalink raw reply
* Re: [PATCH v3 2/4] net_dma: revert 'copied_early'
From: Dan Williams @ 2014-01-14 6:04 UTC (permalink / raw)
To: David Miller
Cc: dmaengine@vger.kernel.org, Hideaki YOSHIFUJI, Netdev, saidi,
James Morris, edumazet, Alexey Kuznetsov, Dave Jones,
Neal Cardwell, Patrick McHardy, linux-kernel@vger.kernel.org
In-Reply-To: <20140113.211619.613683326137425186.davem@davemloft.net>
On Mon, Jan 13, 2014 at 9:16 PM, David Miller <davem@davemloft.net> wrote:
> From: Dan Williams <dan.j.williams@intel.com>
> Date: Mon, 13 Jan 2014 16:47:14 -0800
>
>> Now that tcp_dma_try_early_copy() is gone nothing ever sets
>> copied_early.
>>
>> Also reverts "53240c208776 tcp: Fix possible double-ack w/ user dma"
>> since it is no longer necessary.
>>
>> Cc: Ali Saidi <saidi@engin.umich.edu>
>> Cc: James Morris <jmorris@namei.org>
>> Cc: Patrick McHardy <kaber@trash.net>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
>> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
>> Cc: Neal Cardwell <ncardwell@google.com>
>> Reported-by: Dave Jones <davej@redhat.com>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>
> Acked-by: David S. Miller <davem@davemloft.net>
Thank you sir.
^ permalink raw reply
* Re: [PATCH net] bonding: reset the slave's mtu when its be changed
From: Veaceslav Falico @ 2014-01-14 6:03 UTC (permalink / raw)
To: Ding Tianhong; +Cc: Jay Vosburgh, Netdev, David S. Miller
In-Reply-To: <52D49CE1.6040900@huawei.com>
On Tue, Jan 14, 2014 at 10:11:45AM +0800, Ding Tianhong wrote:
>On 2014/1/12 13:18, Ding Tianhong wrote:
>> On 2014/1/10 20:19, Veaceslav Falico wrote:
>>> On Fri, Jan 10, 2014 at 07:32:51PM +0800, Ding Tianhong wrote:
>>>> All slave should have the same mtu with mastet's, and the bond do it when
>>>> enslave the slave, but the user could change the slave's mtu, it will cause
>>>> the master and slave have different mtu, althrough in AB mode, it does not
>>>> matter if the slave is not the current slave, but in other mode, it is incorrect,
>>>> so reset the slave's mtu like the master set.
>>>
>>> Why "net"? It's not a bugfix, it's a feature, and really discussable.
>>>
>>> Also, wrt the actual change - why do you think it's incorrect for slaves in
>>> bonding mode other than AB to have different MTU values? I don't see any
>>> reason for it, from the top of the head.
>>>
>>
>> Ok, I will test more situation for every mode when slave's mtu changed, I am not sure
>> what will happened yet, if some links was interrupt, I thinks it is a bug.
>>
>>>>
>
>I have test several mode for bonding when the slave mtu changed:
>
>RR(0) 0<mtu<1500 ok
>AB(1) 0<mtu<1500 loss packets
>XOR(2) 0<mtu<1500 ok
>Broadcast(3) 0<mtu<1500 ok
>LACP 0<mtu<1500 loss packets
>
>
>so I think we should not let the mtu set for slave.
Why do you see lost packets?
>
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the net-next tree
From: Stephen Rothwell @ 2014-01-14 6:10 UTC (permalink / raw)
To: David Miller; +Cc: hpa, tglx, mingo, peterz, netdev, linux-next, linux-kernel
In-Reply-To: <20140113.214841.1954373583033654604.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 222 bytes --]
Hi Dave,
On Mon, 13 Jan 2014 21:48:41 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> Net patch applied, thanks Stephen.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] bonding: don't permit slaves to change their mtu
From: Veaceslav Falico @ 2014-01-14 6:15 UTC (permalink / raw)
To: Ding Tianhong; +Cc: Jay Vosburgh, David S. Miller, Netdev
In-Reply-To: <52D4A8A7.60100@huawei.com>
On Tue, Jan 14, 2014 at 11:01:59AM +0800, Ding Tianhong wrote:
>The commit 2315dc91a5059d7da9a8b9b9daf78d695c11383e
>(net: make dev_set_mtu() honor notification return code)
>will deal with the return value for NETDEV_CHANGEMTU notification,
>and the slaves should not change their mtu, so add return value
>to prevent doing it.
In another email you said you've tested the mtu changes and some of the
bonds have packet loss when mtu is changed, and some of them don't.
Maybe it'd be good to understand which modes can tolerate the mtu change
(if it can be tolerated at all/if it should really matter) and allow it for
specific bond modes only/for any bond modes?
>
>Suggested-by: Veaceslav Falico <vfalico@redhat.com>
Don't add my name unless I specifically ask you to, please.
Thank you.
>Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>---
> drivers/net/bonding/bond_main.c | 16 ++++------------
> 1 file changed, 4 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index e06c445..af4e678 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -2846,19 +2846,11 @@ static int bond_slave_netdev_event(unsigned long event,
> */
> break;
> case NETDEV_CHANGEMTU:
>- /*
>- * TODO: Should slaves be allowed to
>- * independently alter their MTU? For
>- * an active-backup bond, slaves need
>- * not be the same type of device, so
>- * MTUs may vary. For other modes,
>- * slaves arguably should have the
>- * same MTUs. To do this, we'd need to
>- * take over the slave's change_mtu
>- * function for the duration of their
>- * servitude.
>+ /* The master and slaves should have the
>+ * the same mtu, so do't permit slaves
>+ * to change their mtu independently.
> */
>- break;
>+ return NOTIFY_BAD;
> case NETDEV_CHANGENAME:
> /*
> * TODO: handle changing the primary's name
>--
>1.8.0
>
>
^ permalink raw reply
* Re: [PATCH v4 net-next 0/3] bonding: fix bond_3ad RCU usage
From: David Miller @ 2014-01-14 6:22 UTC (permalink / raw)
To: vfalico; +Cc: netdev, dingtianhong, fubar, andy
In-Reply-To: <1389351585-19615-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Fri, 10 Jan 2014 11:59:42 +0100
> While digging through bond_3ad.c I've found that the RCU usage there is
> just wrong - it's used as a kind of mutex/spinlock instead of RCU.
>
> v3->v4: remove useless goto and wrap __get_first_agg() in proper RCU.
>
> v2->v3: make bond_3ad_set_carrier() use RCU read lock for the whole
> function, so that all other functions will be protected by RCU as well.
> This way we can use _rcu variants everywhere.
>
> v1->v2: use generic primitives instead of _rcu ones cause we can hold RTNL
> lock without RCU one, which is still safe.
>
> This patchset is on top of bond_3ad.c cleanup:
> http://www.spinics.net/lists/netdev/msg265447.html
Series applied, thank you.
^ permalink raw reply
* RE: [PATCH net 2/2] be2net: Need a delay before processing CQE after 2nd mbox register write
From: Somnath Kotur @ 2014-01-14 6:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Kalesh Purayil
In-Reply-To: <20140110.151109.1275347758815420234.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Saturday, January 11, 2014 1:41 AM
> To: Somnath Kotur
> Cc: netdev@vger.kernel.org; Kalesh Purayil
> Subject: Re: [PATCH net 2/2] be2net: Need a delay before processing CQE
> after 2nd mbox register write
>
> From: Somnath Kotur <somnath.kotur@emulex.com>
> Date: Wed, 8 Jan 2014 14:52:02 +0530
>
> > Due to Host platform synchronization issues between the mbox RDY bit
> > polled status and the completion of the DMA for the CQE, it is
> > preferable that the Host always wait for the RDY bit to transition to
> > 1 after the 2nd mbox register write and always follow that with a
> > short wait for the valid bit in the CQE, before processing the CQE.
> >
> > Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com>
> > Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
> > ---
> > drivers/net/ethernet/emulex/benet/be_cmds.c | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c
> > b/drivers/net/ethernet/emulex/benet/be_cmds.c
> > index 94c35c8..78560f2 100644
> > --- a/drivers/net/ethernet/emulex/benet/be_cmds.c
> > +++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
> > @@ -502,6 +502,9 @@ static int be_mbox_notify_wait(struct be_adapter
> *adapter)
> > if (status != 0)
> > return status;
> >
> > + /* Need a delay before processing CQE after 2nd mbox register write
> */
> > + udelay(1);
> > +
>
> Like others, I find his delay being used to fix the stated problem as
> questionable, at best.
>
> Either find a more appropriate way to fix this problem, or elaborate (in the
> commit message), why this is really a suitable way to handle this.
Dave,
It indeed looks like an *arbitrary* delay between the mbox RDY read and CQ-entry read was not the right solution.
The correct fix would be for the driver to poll on the CQ-entry valid bit to become 1, as the time taken for the mbox-compl DMA
to finish may not be deterministic.
^ permalink raw reply
* RE: [PATCH net 2/2] be2net: Need a delay before processing CQE after 2nd mbox register write
From: Somnath Kotur @ 2014-01-14 6:33 UTC (permalink / raw)
To: David Laight, netdev@vger.kernel.org; +Cc: davem@davemloft.net, Kalesh Purayil
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D454FBA@AcuExch.aculab.com>
> -----Original Message-----
> From: David Laight [mailto:David.Laight@ACULAB.COM]
> Sent: Wednesday, January 08, 2014 3:02 PM
> To: Somnath Kotur; netdev@vger.kernel.org
> Cc: davem@davemloft.net; Kalesh Purayil
> Subject: RE: [PATCH net 2/2] be2net: Need a delay before processing CQE
> after 2nd mbox register write
>
> > From: Somnath Kotur
> > Due to Host platform synchronization issues between the mbox RDY bit
> > polled status and the completion of the DMA for the CQE, it is
> > preferable that the Host always wait for the RDY bit to transition to
> > 1 after the 2nd mbox register write and always follow that with a
> > short wait for the valid bit in the CQE, before processing the CQE.
>
> While I don't doubt that a delay(1) fixes the problem it doesn't seem an ideal
> solution.
> I've not looked at what the code is doing (or how often it does it) but either
> delay(1) is far, far longer than is necessary or it might not be long enough and
> some kind of retry loop is required.
>
> It might even be that the driver is just missing a memory barrier.
David,
The memory barrier by itself did not work, however like you said polling on the valid
Bit to be set seems like the right solution as the time for the mbox-completion DMA to finish/reach the host
may not be deterministic.
Thanks
Som
^ permalink raw reply
* Re: [PATCH net] inet_diag: fix inet_diag_dump_icsk() to use correct state for timewait sockets
From: David Miller @ 2014-01-14 6:36 UTC (permalink / raw)
To: ncardwell; +Cc: netdev, edumazet
In-Reply-To: <1389386085-22659-1-git-send-email-ncardwell@google.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Fri, 10 Jan 2014 15:34:45 -0500
> Fix inet_diag_dump_icsk() to reflect the fact that both TCP_TIME_WAIT
> and TCP_FIN_WAIT2 connections are represented by inet_timewait_sock
> (not just TIME_WAIT), and for such sockets the tw_substate field holds
> the real state, which can be either TCP_TIME_WAIT or TCP_FIN_WAIT2.
>
> This brings the inet_diag state-matching code in line with the field
> it uses to populate idiag_state. This is also analogous to the info
> exported in /proc/net/tcp, where get_tcp4_sock() exports sk->sk_state
> and get_timewait4_sock() exports tw->tw_substate.
>
> Before fixing this, (a) neither "ss -nemoi" nor "ss -nemoi state
> fin-wait-2" would return a socket in TCP_FIN_WAIT2; and (b) "ss -nemoi
> state time-wait" would also return sockets in state TCP_FIN_WAIT2.
>
> This is an old bug that predates 05dbc7b ("tcp/dccp: remove twchain").
>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] net/mlx4_core: clean up srq_res_start_move_to()
From: Jack Morgenstein @ 2014-01-14 6:40 UTC (permalink / raw)
To: Paul Bolle
Cc: Or Gerlitz, Rony Efraim, Hadar Hen Zion, David S. Miller, netdev,
linux-kernel
In-Reply-To: <1389099734.15032.20.camel@x41>
On Tue, 07 Jan 2014 14:02:14 +0100
Paul Bolle <pebolle@tiscali.nl> wrote:
> diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c index
> a41f01e..8ace450 100644 ---
> a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c +++
> b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c @@ -1372,7
> +1372,7 @@ static int cq_res_start_move_to(struct mlx4_dev *dev, int
> slave, int cqn, }
> static int srq_res_start_move_to(struct mlx4_dev *dev, int slave,
> int index,
> - enum res_cq_states state, struct res_srq **srq)
> + enum res_srq_states state, struct res_srq **srq) {
ACK
> + /* state == RES_SRQ_HW */
> + if (r->com.state != RES_SRQ_ALLOCATED)
if (state != RES_SRQ_HW || r->com.state != RES_SRQ_ALLOCATED)
> err = -EINVAL;
> - }
> + }
>
> - if (!err) {
> - r->com.from_state = r->com.state;
> - r->com.to_state = state;
> - r->com.state = RES_SRQ_BUSY;
> - if (srq)
> - *srq = r;
> - }
> + if (!err) {
> + r->com.from_state = r->com.state;
> + r->com.to_state = state;
> + r->com.state = RES_SRQ_BUSY;
please leave in the if (srq). Not currently needed, but if this
changes in the future, we will get an Oops.
> + *srq = r;
> }
>
> spin_unlock_irq(mlx4_tlock(dev));
^ permalink raw reply
* Re: [PATCH net-next 1/3] bonding: update the primary slave when slave's name changed
From: Veaceslav Falico @ 2014-01-14 6:38 UTC (permalink / raw)
To: Ding Tianhong; +Cc: Jay Vosburgh, David S. Miller, Netdev
In-Reply-To: <52D4A2C8.3000908@huawei.com>
On Tue, Jan 14, 2014 at 10:36:56AM +0800, Ding Tianhong wrote:
>If the slave's name changed, and the bond params primary is exist,
>the bond should deal with the situation in two ways:
>
>1) If the slave is the primary slave yet, clean the primary slave
> and reselect active slave.
>2) If the slave's new name is as same as bond primary, set the slave
> as primary slave and reselect active slave.
>
>Thanks for Veaceslav's suggestion.
>
>Suggested-by: Veaceslav Falico <vfalico@redhat.com>
As in my previous email - please, don't use my name until I say so.
I'll add my signed-off-by to any patch that I've worked enough on.
>Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>---
> drivers/net/bonding/bond_main.c | 30 ++++++++++++++++++++++++++++--
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index e06c445..63d6533 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -2860,9 +2860,35 @@ static int bond_slave_netdev_event(unsigned long event,
> */
> break;
> case NETDEV_CHANGENAME:
>- /*
>- * TODO: handle changing the primary's name
>+ /* Handle changing the slave's name:
>+ * 1) If the slave is primary save yet,
>+ * clean the primary slave and reselect
>+ * active slave.
I usually don't mind bad english (as I myself am speaking quite horrible
one), but I can't really understand what you've meant here. And given that
it's a comment in code - please, proof-read it first.
>+ * 2) If the slave's new name is bond
>+ * primary, set the slave as primary
>+ * slave and reselect active slave.
> */
>+ if (USES_PRIMARY(bond->params.mode) &&
>+ bond->params.primary[0]) {
Too many indentions. Verify if we're not using primary or primary string
name is null and break, otherwise go further.
>+ if (bond->primary_slave &&
>+ slave == bond->primary_slave) {
Useless verification, slave can't be NULL.
>+ pr_info("%s: Setting primary slave to None.\n",
>+ bond->dev->name);
>+ bond->primary_slave = NULL;
>+ write_lock_bh(&bond->curr_slave_lock);
>+ bond_select_active_slave(bond);
Get bond_select_active_slave() out of if()s, you use it twice here.
>+ write_unlock_bh(&bond->curr_slave_lock);
>+ } else if (!bond->primary_slave &&
Useless verification, if the name of a slave changed to our params.primary
- then it means that bond->primary_slave was NULL, as it can only be
not-null when we have a matching interface, and that would mean that we
have two interfaces with the same name.
>+ !strcmp(bond->params.primary,
>+ slave_dev->name)) {
>+ pr_info("%s: Setting %s as primary slave.\n",
>+ bond->dev->name, slave_dev->name);
>+ bond->primary_slave = slave;
>+ write_lock_bh(&bond->curr_slave_lock);
>+ bond_select_active_slave(bond);
>+ write_unlock_bh(&bond->curr_slave_lock);
>+ }
>+ }
> break;
> case NETDEV_FEAT_CHANGE:
> bond_compute_features(bond);
>--
>1.8.0
>
>
^ permalink raw reply
* Re: [PATCH net-next 2/3] bonding: clean the primary slave if there is no slave matching new primary
From: Veaceslav Falico @ 2014-01-14 6:42 UTC (permalink / raw)
To: Ding Tianhong; +Cc: Jay Vosburgh, David S. Miller, Netdev
In-Reply-To: <52D4A2CC.6010907@huawei.com>
On Tue, Jan 14, 2014 at 10:37:00AM +0800, Ding Tianhong wrote:
>If the new primay is not matching any slave in the bond, the bond should
>record it to params, clean the primary slave and select a new active slave.
This one looks good.
>
>Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>---
> drivers/net/bonding/bond_options.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
>diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
>index 945a666..0ee0bfe 100644
>--- a/drivers/net/bonding/bond_options.c
>+++ b/drivers/net/bonding/bond_options.c
>@@ -512,6 +512,12 @@ int bond_option_primary_set(struct bonding *bond, const char *primary)
> }
> }
>
>+ if (bond->primary_slave) {
>+ pr_info("%s: Setting primary slave to None.\n",
>+ bond->dev->name);
>+ bond->primary_slave = NULL;
>+ bond_select_active_slave(bond);
>+ }
> strncpy(bond->params.primary, primary, IFNAMSIZ);
> bond->params.primary[IFNAMSIZ - 1] = 0;
>
>--
>1.8.0
>
>
^ permalink raw reply
* Re: [PATCH 1/2] net/mlx4_core: clean up cq_res_start_move_to()
From: Jack Morgenstein @ 2014-01-14 6:47 UTC (permalink / raw)
To: Paul Bolle
Cc: Or Gerlitz, Rony Efraim, Hadar Hen Zion, David S. Miller, netdev,
linux-kernel
In-Reply-To: <1389099678.15032.19.camel@x41>
This time, replying to the list as well.
-Jack
P.S. sorry for the delay, I was swamped.
On Tue, 07 Jan 2014 14:01:18 +0100
Paul Bolle <pebolle@tiscali.nl> wrote:
> + } else {
> + /* state == RES_CQ_HW */
> + if (r->com.state != RES_CQ_ALLOCATED)
if (state != RES_CQ_HW || r->com.state != RES_CQ_ALLOCATED)
to protect against any bad calls to this function
(although I know that currently there are none).
This also preserves the behavior of the switch statement.
> err = -EINVAL;
> - }
> + else
> + err = 0;
> + }
>
> - if (!err) {
> - r->com.from_state = r->com.state;
> - r->com.to_state = state;
> - r->com.state = RES_CQ_BUSY;
> - if (cq)
> - *cq = r;
> - }
> + if (!err) {
> + r->com.from_state = r->com.state;
> + r->com.to_state = state;
> + r->com.state = RES_CQ_BUSY;
Please keep the "if" here. Protects against (future) bad calls.
> + *cq = r;
> }
^ permalink raw reply
* pull request (net-next): ipsec-next 2014-01-14
From: Steffen Klassert @ 2014-01-14 6:49 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
This pull request has a merge conflict between commits be7928d20bab
("net: xfrm: xfrm_policy: fix inline not at beginning of declaration") and
da7c224b1baa ("net: xfrm: xfrm_policy: silence compiler warning") from
the net-next tree and commit 2f3ea9a95c58 ("xfrm: checkpatch erros with
inline keyword position") from the ipsec-next tree.
The version from net-next can be used, like it is done in linux-next.
1) Checkpatch cleanups, from Weilong Chen.
2) Fix lockdep complaints when pktgen is used with IPsec,
from Fan Du.
3) Update pktgen to allow any combination of IPsec transport/tunnel mode
and AH/ESP/IPcomp type, from Fan Du.
4) Make pktgen_dst_metrics static, Fengguang Wu.
5) Compile fix for pktgen when CONFIG_XFRM is not set,
from Fan Du.
Please pull or let me know if there are problems.
Thanks!
The following changes since commit 852ad5e631967ae2203cb08c5b6b42c26011ed63:
Merge branch 'bridge_cleanups' (2013-12-19 19:27:34 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git master
for you to fetch changes up to 6bae919003602729d6f5920315bf71ca78bd9e48:
{xfrm,pktgen} Fix compiling error when CONFIG_XFRM is not set (2014-01-10 07:46:24 +0100)
----------------------------------------------------------------
Fan Du (9):
{pktgen, xfrm} Correct xfrm state lock usage when transforming
{pktgen, xfrm} Add statistics counting when transforming
{pktgen, xfrm} Correct xfrm_state_lock usage in xfrm_stateonly_find
{pktgen, xfrm} Using "pgset spi xxx" to spedifiy SA for a given flow
{pktgen, xfrm} Construct skb dst for tunnel mode transformation
{pktgen, xfrm} Introduce xfrm_state_lookup_byspi for pktgen
{pktgen, xfrm} Show spi value properly when ipsec turned on
{pktgen, xfrm} Document IPsec usage in pktgen.txt
{xfrm,pktgen} Fix compiling error when CONFIG_XFRM is not set
Fengguang Wu (1):
pktgen_dst_metrics[] can be static
Weilong Chen (5):
xfrm: checkpatch errors with space
xfrm: checkpatch errors with foo * bar
xfrm: checkpatch erros with space prohibited
xfrm: fix checkpatch error
xfrm: checkpatch erros with inline keyword position
Documentation/networking/pktgen.txt | 15 +++++++
include/net/xfrm.h | 2 +
net/core/pktgen.c | 80 +++++++++++++++++++++++++++++------
net/xfrm/xfrm_input.c | 6 +--
net/xfrm/xfrm_policy.c | 38 ++++++++---------
net/xfrm/xfrm_proc.c | 2 +-
net/xfrm/xfrm_state.c | 44 ++++++++++++++-----
net/xfrm/xfrm_user.c | 6 +--
8 files changed, 142 insertions(+), 51 deletions(-)
^ permalink raw reply
* [PATCH 04/15] xfrm: fix checkpatch error
From: Steffen Klassert @ 2014-01-14 6:49 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1389682159-3260-1-git-send-email-steffen.klassert@secunet.com>
From: Weilong Chen <chenweilong@huawei.com>
Fix that "else should follow close brace '}'".
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_policy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index fbc72b4..b5c315e 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1316,9 +1316,9 @@ xfrm_tmpl_resolve_one(struct xfrm_policy *policy, const struct flowi *fl,
error = (x->km.state == XFRM_STATE_ERROR ?
-EINVAL : -EAGAIN);
xfrm_state_put(x);
- }
- else if (error == -ESRCH)
+ } else if (error == -ESRCH) {
error = -EAGAIN;
+ }
if (!tmpl->optional)
goto fail;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 02/15] xfrm: checkpatch errors with foo * bar
From: Steffen Klassert @ 2014-01-14 6:49 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <1389682159-3260-1-git-send-email-steffen.klassert@secunet.com>
From: Weilong Chen <chenweilong@huawei.com>
This patch clean up some checkpatch errors like this:
ERROR: "foo * bar" should be "foo *bar"
ERROR: "(foo*)" should be "(foo *)"
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_input.c | 6 +++---
net/xfrm/xfrm_policy.c | 12 ++++++------
net/xfrm/xfrm_state.c | 8 ++++----
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 8884399..6c7ac01 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -67,7 +67,7 @@ int xfrm_parse_spi(struct sk_buff *skb, u8 nexthdr, __be32 *spi, __be32 *seq)
case IPPROTO_COMP:
if (!pskb_may_pull(skb, sizeof(struct ip_comp_hdr)))
return -EINVAL;
- *spi = htonl(ntohs(*(__be16*)(skb_transport_header(skb) + 2)));
+ *spi = htonl(ntohs(*(__be16 *)(skb_transport_header(skb) + 2)));
*seq = 0;
return 0;
default:
@@ -77,8 +77,8 @@ int xfrm_parse_spi(struct sk_buff *skb, u8 nexthdr, __be32 *spi, __be32 *seq)
if (!pskb_may_pull(skb, hlen))
return -EINVAL;
- *spi = *(__be32*)(skb_transport_header(skb) + offset);
- *seq = *(__be32*)(skb_transport_header(skb) + offset_seq);
+ *spi = *(__be32 *)(skb_transport_header(skb) + offset);
+ *seq = *(__be32 *)(skb_transport_header(skb) + offset_seq);
return 0;
}
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 8a2b9d8..dc8bd1b 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -171,7 +171,7 @@ static inline unsigned long make_jiffies(long secs)
static void xfrm_policy_timer(unsigned long data)
{
- struct xfrm_policy *xp = (struct xfrm_policy*)data;
+ struct xfrm_policy *xp = (struct xfrm_policy *)data;
unsigned long now = get_seconds();
long next = LONG_MAX;
int warn = 0;
@@ -1758,7 +1758,7 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy **pols, int num_pols,
}
xdst->num_pols = num_pols;
- memcpy(xdst->pols, pols, sizeof(struct xfrm_policy*) * num_pols);
+ memcpy(xdst->pols, pols, sizeof(struct xfrm_policy *) * num_pols);
xdst->policy_genid = atomic_read(&pols[0]->genid);
return xdst;
@@ -2027,7 +2027,7 @@ make_dummy_bundle:
}
xdst->num_pols = num_pols;
xdst->num_xfrms = num_xfrms;
- memcpy(xdst->pols, pols, sizeof(struct xfrm_policy*) * num_pols);
+ memcpy(xdst->pols, pols, sizeof(struct xfrm_policy *) * num_pols);
dst_hold(&xdst->u.dst);
return &xdst->flo;
@@ -2136,7 +2136,7 @@ struct dst_entry *xfrm_lookup(struct net *net, struct dst_entry *dst_orig,
num_pols = xdst->num_pols;
num_xfrms = xdst->num_xfrms;
- memcpy(pols, xdst->pols, sizeof(struct xfrm_policy*) * num_pols);
+ memcpy(pols, xdst->pols, sizeof(struct xfrm_policy *) * num_pols);
route = xdst->route;
}
@@ -3064,8 +3064,8 @@ static bool xfrm_migrate_selector_match(const struct xfrm_selector *sel_cmp,
return false;
}
-static struct xfrm_policy * xfrm_migrate_policy_find(const struct xfrm_selector *sel,
- u8 dir, u8 type, struct net *net)
+static struct xfrm_policy *xfrm_migrate_policy_find(const struct xfrm_selector *sel,
+ u8 dir, u8 type, struct net *net)
{
struct xfrm_policy *pol, *ret = NULL;
struct hlist_head *chain;
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 5fe79b4..9e6a4d6 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -382,7 +382,7 @@ static inline unsigned long make_jiffies(long secs)
return secs*HZ;
}
-static enum hrtimer_restart xfrm_timer_handler(struct hrtimer * me)
+static enum hrtimer_restart xfrm_timer_handler(struct hrtimer *me)
{
struct tasklet_hrtimer *thr = container_of(me, struct tasklet_hrtimer, timer);
struct xfrm_state *x = container_of(thr, struct xfrm_state, mtimer);
@@ -1237,8 +1237,8 @@ struct xfrm_state *xfrm_migrate_state_find(struct xfrm_migrate *m, struct net *n
}
EXPORT_SYMBOL(xfrm_migrate_state_find);
-struct xfrm_state * xfrm_state_migrate(struct xfrm_state *x,
- struct xfrm_migrate *m)
+struct xfrm_state *xfrm_state_migrate(struct xfrm_state *x,
+ struct xfrm_migrate *m)
{
struct xfrm_state *xc;
int err;
@@ -1630,7 +1630,7 @@ EXPORT_SYMBOL(xfrm_state_walk_done);
static void xfrm_replay_timer_handler(unsigned long data)
{
- struct xfrm_state *x = (struct xfrm_state*)data;
+ struct xfrm_state *x = (struct xfrm_state *)data;
spin_lock(&x->lock);
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox