* Re: [PATCH net-next 2/2] PPC: net: bpf_jit_comp: add VLAN instructions for BPF JIT
From: David Miller @ 2012-11-18 3:13 UTC (permalink / raw)
To: matt; +Cc: dxchgb, benh, netdev
In-Reply-To: <45EBCE3A-FE92-4A8D-B5D8-DED4E30DF419@ozlabs.org>
From: Matt Evans <matt@ozlabs.org>
Date: Sat, 17 Nov 2012 00:06:03 +0000
> Hi,
>
> On 08/11/2012, at 9:41 PM, Daniel Borkmann wrote:
>
>> This patch is a follow-up for patch "net: filter: add vlan tag access"
>> to support the new VLAN_TAG/VLAN_TAG_PRESENT accessors in BPF JIT.
>>
>> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
>> Cc: Matt Evans <matt@ozlabs.org>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> ---
>> Disclaimer: uncompiled and untested, since I don't have a PPC machine,
>> but it should (hopefully) integrate cleanly; impl. after PPC instruction
>> reference.
>
> And for this too,
>
> Acked-by: Matt Evans <matt@ozlabs.org>
>
> Sorry for the delay in reviewing this!
Applied, thanks for reviewing.
^ permalink raw reply
* Re: [PATCH net-next 1/2] PPC: net: bpf_jit_comp: add XOR instruction for BPF JIT
From: David Miller @ 2012-11-18 3:13 UTC (permalink / raw)
To: matt; +Cc: dxchgb, benh, netdev
In-Reply-To: <744A32A4-3F1F-4253-9ECB-59DBCC240847@ozlabs.org>
From: Matt Evans <matt@ozlabs.org>
Date: Sat, 17 Nov 2012 00:00:38 +0000
> Hi Daniel,
>
>
> On 08/11/2012, at 9:39 PM, Daniel Borkmann wrote:
>
>> This patch is a follow-up for patch "filter: add XOR instruction for use
>> with X/K" that implements BPF PowerPC JIT parts for the BPF XOR operation.
>>
>> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
>> Cc: Matt Evans <matt@ozlabs.org>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> ---
>> Disclaimer: uncompiled and untested, since I don't have a PPC machine,
>> but it should (hopefully) integrate cleanly; impl. after PPC instruction
>> reference.
>
> Unfortunately I can only compile and test this mentally, but it looks fine, instruction formats correct etc. Thanks!
>
>
> Acked-by: Matt Evans <matt@ozlabs.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] pch_gbe, ptp_pch: Fix the dependency direction between these drivers
From: David Miller @ 2012-11-18 3:12 UTC (permalink / raw)
To: rdunlap; +Cc: bhutchings, netdev, tshimizu818, richardcochran
In-Reply-To: <50A6F01C.4010304@xenotime.net>
From: Randy Dunlap <rdunlap@xenotime.net>
Date: Fri, 16 Nov 2012 18:02:04 -0800
> On 11/16/2012 05:43 PM, Ben Hutchings wrote:
>
>> In commit a24006ed12616bde1bbdb26868495906a212d8dc ('ptp: Enable clock
>> drivers along with associated net/PHY drivers') I wrongly made
>> PTP_1588_CLOCK_PCH depend on PCH_GBE. The dependency is really the
>> other way around. Therefore make PCH_GBE select PTP_1588_CLOCK_PCH
>> and remove the 'default y' from the latter.
>>
>> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
>> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
>
>
> Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Applied, thanks everyone.
^ permalink raw reply
* Re: [net-next patch] vxlan: remove unused variable.
From: David Miller @ 2012-11-18 3:02 UTC (permalink / raw)
To: shemminger; +Cc: ramirose, netdev
In-Reply-To: <20121117095225.48bd9ab1@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 17 Nov 2012 09:52:25 -0800
> On Sat, 17 Nov 2012 16:08:07 +0200
> Rami Rosen <ramirose@gmail.com> wrote:
>
>> This patch removes addrexceeded member from vxlan_dev struct as it is unused.
>>
>> Signed-off-by: Rami Rosen <ramirose@gmail.com>
...
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] sctp: use bitmap_weight
From: David Miller @ 2012-11-18 3:01 UTC (permalink / raw)
To: vyasevich; +Cc: akinobu.mita, linux-sctp, sri, netdev
In-Reply-To: <50A83DAF.8000408@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Sat, 17 Nov 2012 20:45:19 -0500
> On 11/17/2012 01:39 AM, Akinobu Mita wrote:
>> Use bitmap_weight to count the total number of bits set in bitmap.
>>
>> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
>> Cc: Vlad Yasevich <vyasevich@gmail.com>
>> Cc: Sridhar Samudrala <sri@us.ibm.com>
>> Cc: linux-sctp@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>
> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] sctp: use bitmap_weight
From: Vlad Yasevich @ 2012-11-18 1:45 UTC (permalink / raw)
To: Akinobu Mita; +Cc: linux-sctp, Sridhar Samudrala, netdev
In-Reply-To: <1353134389-25583-1-git-send-email-akinobu.mita@gmail.com>
On 11/17/2012 01:39 AM, Akinobu Mita wrote:
> Use bitmap_weight to count the total number of bits set in bitmap.
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Cc: Sridhar Samudrala <sri@us.ibm.com>
> Cc: linux-sctp@vger.kernel.org
> Cc: netdev@vger.kernel.org
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> net/sctp/tsnmap.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/net/sctp/tsnmap.c b/net/sctp/tsnmap.c
> index b5fb7c4..5f25e0c 100644
> --- a/net/sctp/tsnmap.c
> +++ b/net/sctp/tsnmap.c
> @@ -272,7 +272,7 @@ __u16 sctp_tsnmap_pending(struct sctp_tsnmap *map)
> __u32 max_tsn = map->max_tsn_seen;
> __u32 base_tsn = map->base_tsn;
> __u16 pending_data;
> - u32 gap, i;
> + u32 gap;
>
> pending_data = max_tsn - cum_tsn;
> gap = max_tsn - base_tsn;
> @@ -280,11 +280,7 @@ __u16 sctp_tsnmap_pending(struct sctp_tsnmap *map)
> if (gap == 0 || gap >= map->len)
> goto out;
>
> - for (i = 0; i < gap+1; i++) {
> - if (test_bit(i, map->tsn_map))
> - pending_data--;
> - }
> -
> + pending_data -= bitmap_weight(map->tsn_map, gap + 1);
> out:
> return pending_data;
> }
>
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Eric W. Biederman @ 2012-11-17 23:37 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Michael Richardson, tcpdump-workers, Ani Sinha, netdev,
Francesco Ruggeri
In-Reply-To: <CAD6jFUQguS0oqGuA-HDFV2gd9m_=kZAvKJJq3ymr8zWM2cePXw@mail.gmail.com>
Daniel Borkmann <danborkmann@iogearbox.net> writes:
> Speaking of netsniff-ng where we don't reconstruct VLAN headers, users
> have reported that depending on the NIC/driver resp. ethtool setting,
> they can come in stripped or not (in the pf_packet's rx_ring buffer).
> However, I assume VLAN AUXDATA is always consistent (and so the
> BPF/BPF JIT filtering).
Yes it was a mess before we added software stripping of the vlan headers
a year ago.
Eric
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Eric W. Biederman @ 2012-11-17 23:33 UTC (permalink / raw)
To: Michael Richardson; +Cc: tcpdump-workers, Ani Sinha, netdev, Francesco Ruggeri
In-Reply-To: <12918.1353190488@obiwan.sandelman.ca>
Michael Richardson <mcr@sandelman.ca> writes:
> Thank you for this reply.
>
>>>>>> "Eric" == Eric W Biederman <ebiederm@xmission.com> writes:
> Eric> I don't see any need to add any kernel code to allow checking
> Eric> if vlan tags are stripped. Vlan headers are stripped on all
> Eric> kernel interfaces today. Vlan headers have been stripped on
> Eric> all but a handful of software interfaces for 6+ years. For
> Eric> all kernels if the vlan header is stripped it is reported in
> Eric> the auxdata, upon packet reception. Careful code should also
> Eric> look for TP_STATUS_VLAN_VALID which allows for distinguishing
> Eric> a striped vlan header of 0 from no vlan header.
>
> I can regularly see vlan tags on raw dumps from the untagged ("eth0")
> today, running 3.2 (debian stable):
>
> obiwan-[~] mcr 4848 %sudo tcpdump -i eth0 -n -p -e | grep -i vlan
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 17:05:15.404909 38:60:77:38:e6:47 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 3800, p 0, ethertype ARP, Request who-has 172.30.42.1 tell 172.30.42.11, length 28
>
> So, I'm curious about the statement that vlan tags have been stripped
> for some time, because I don't see them stripped today. My desktop has
> an Intel 82579V NIC in it...
So I just took a quick look at libpcap 1.1.1.1.
In pcap_read_packet in pcap-linux.c the code to readd the vlan header is
protected by HAVE_PACKET_AUXDATA.
In pcap_read_linux_mmap in pcap-linux.c the code to readd the vlan
header is protected by HAVE_TPACKET2.
That code is shifting the the ethernet header up 4 bytes and inserting
the vlan header in packets as we receive them.
The code is correct except for the case of packets in vlan 0. Currently
the packet reconstruction is ambiguous. The most recent kernels have
a TP_STATUS_VLAN_VALID flag that can be checked to see if the packet was
in vlan 0 or if there was no vlan at all. libpcap probably should be
taught how to handle TP_STATUS_VLAN_VALID so that it can get the vlan 0
handling correct.
> Eric> For old kernels that do not support the new extensions it is
> Eric> possible to generate code that looks at the ethernet header
> Eric> and sees if the ethertype is 0x8100 and then does things with
> Eric> it, but that will only work on a small handful of software
> Eric> only interfaces.
>
> at tcpdump.org, our concern is to release code that works on both new,
> and what for kernel.org folks would be considered "ancient" systems,
> such as Centos5/RHEL5 machines which are regularly still in production
> in the field (sadly...), but often need the latest diagnostics.
> What I hear you saying is that our existing code will work on older
> kernels, and that once we have new code to use the VLAN tag extensions,
> we should simply attempt to load it, and either it loads, or we get an
> error, and we go back to the code we had before. That's great news.
The existing code will work as well as anything if you don't have the
VLAN tag extensions. If you are not using the VLAN tag extensions there
is no reliable way to filter for vlan tagged packets in the kernel as on
most network devices (all for the last year) the vlan header has been
stripped at the time the bpf filter is run.
So yes. Just falling back to the existing code seems as good as it is
going to get. Which isn't very good but it took 5+ years before people
cared enough to get this fixed. :(
> The major concern is that if the 802.1q header is gone, although we can
> retrieve it somehow (I'm not sure how the AUXDATA is presented on the
> MMAP PF_PACKET interface...) we will have to reconstruct it in order to
> save it properly to a savefile. Many entities, including most major
> Network Telescopes (http://en.wikipedia.org/wiki/Network_telescope) use
> libpcap (and often tcpdump itself) to capture packets on probe points,
> and having good performance matters here...
Yes. I wasn't looking at the mmap path. The vlan information is
present in the tpacket2_hdr and tpacket3_hdr structures that accompany
packets read with the mmap interface. The old tpacket1_hdr doesn't
support the vlan_tci information so that won't work.
Not having the vlan header on the packet when the bpf filter is run is
justified by performance, and likewise reading vlan tagged packets to
userspace with the vlan header stripped is justified by performance.
Eric
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Daniel Borkmann @ 2012-11-17 23:16 UTC (permalink / raw)
To: Michael Richardson
Cc: tcpdump-workers, Eric W. Biederman, Ani Sinha, netdev,
Francesco Ruggeri
In-Reply-To: <12918.1353190488@obiwan.sandelman.ca>
On Sat, Nov 17, 2012 at 11:14 PM, Michael Richardson <mcr@sandelman.ca> wrote:
>
> Thank you for this reply.
>
>>>>>> "Eric" == Eric W Biederman <ebiederm@xmission.com> writes:
> Eric> I don't see any need to add any kernel code to allow checking
> Eric> if vlan tags are stripped. Vlan headers are stripped on all
> Eric> kernel interfaces today. Vlan headers have been stripped on
> Eric> all but a handful of software interfaces for 6+ years. For
> Eric> all kernels if the vlan header is stripped it is reported in
> Eric> the auxdata, upon packet reception. Careful code should also
> Eric> look for TP_STATUS_VLAN_VALID which allows for distinguishing
> Eric> a striped vlan header of 0 from no vlan header.
>
> I can regularly see vlan tags on raw dumps from the untagged ("eth0")
> today, running 3.2 (debian stable):
>
> obiwan-[~] mcr 4848 %sudo tcpdump -i eth0 -n -p -e | grep -i vlan
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 17:05:15.404909 38:60:77:38:e6:47 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 3800, p 0, ethertype ARP, Request who-has 172.30.42.1 tell 172.30.42.11, length 28
>
> So, I'm curious about the statement that vlan tags have been stripped
> for some time, because I don't see them stripped today. My desktop has
> an Intel 82579V NIC in it...
Speaking of netsniff-ng where we don't reconstruct VLAN headers, users
have reported that depending on the NIC/driver resp. ethtool setting,
they can come in stripped or not (in the pf_packet's rx_ring buffer).
However, I assume VLAN AUXDATA is always consistent (and so the
BPF/BPF JIT filtering).
> Eric> For old kernels that do not support the new extensions it is
> Eric> possible to generate code that looks at the ethernet header
> Eric> and sees if the ethertype is 0x8100 and then does things with
> Eric> it, but that will only work on a small handful of software
> Eric> only interfaces.
>
> at tcpdump.org, our concern is to release code that works on both new,
> and what for kernel.org folks would be considered "ancient" systems,
> such as Centos5/RHEL5 machines which are regularly still in production
> in the field (sadly...), but often need the latest diagnostics.
>
> What I hear you saying is that our existing code will work on older
> kernels, and that once we have new code to use the VLAN tag extensions,
> we should simply attempt to load it, and either it loads, or we get an
> error, and we go back to the code we had before. That's great news.
Yes, this should be handled in such a way.
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Michael Richardson @ 2012-11-17 22:14 UTC (permalink / raw)
To: tcpdump-workers, Eric W. Biederman; +Cc: Ani Sinha, netdev, Francesco Ruggeri
In-Reply-To: <87mwyi9h1x.fsf@xmission.com>
[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]
Thank you for this reply.
>>>>> "Eric" == Eric W Biederman <ebiederm@xmission.com> writes:
Eric> I don't see any need to add any kernel code to allow checking
Eric> if vlan tags are stripped. Vlan headers are stripped on all
Eric> kernel interfaces today. Vlan headers have been stripped on
Eric> all but a handful of software interfaces for 6+ years. For
Eric> all kernels if the vlan header is stripped it is reported in
Eric> the auxdata, upon packet reception. Careful code should also
Eric> look for TP_STATUS_VLAN_VALID which allows for distinguishing
Eric> a striped vlan header of 0 from no vlan header.
I can regularly see vlan tags on raw dumps from the untagged ("eth0")
today, running 3.2 (debian stable):
obiwan-[~] mcr 4848 %sudo tcpdump -i eth0 -n -p -e | grep -i vlan
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:05:15.404909 38:60:77:38:e6:47 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 3800, p 0, ethertype ARP, Request who-has 172.30.42.1 tell 172.30.42.11, length 28
So, I'm curious about the statement that vlan tags have been stripped
for some time, because I don't see them stripped today. My desktop has
an Intel 82579V NIC in it...
Eric> For old kernels that do not support the new extensions it is
Eric> possible to generate code that looks at the ethernet header
Eric> and sees if the ethertype is 0x8100 and then does things with
Eric> it, but that will only work on a small handful of software
Eric> only interfaces.
at tcpdump.org, our concern is to release code that works on both new,
and what for kernel.org folks would be considered "ancient" systems,
such as Centos5/RHEL5 machines which are regularly still in production
in the field (sadly...), but often need the latest diagnostics.
What I hear you saying is that our existing code will work on older
kernels, and that once we have new code to use the VLAN tag extensions,
we should simply attempt to load it, and either it loads, or we get an
error, and we go back to the code we had before. That's great news.
The major concern is that if the 802.1q header is gone, although we can
retrieve it somehow (I'm not sure how the AUXDATA is presented on the
MMAP PF_PACKET interface...) we will have to reconstruct it in order to
save it properly to a savefile. Many entities, including most major
Network Telescopes (http://en.wikipedia.org/wiki/Network_telescope) use
libpcap (and often tcpdump itself) to capture packets on probe points,
and having good performance matters here...
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: [PATCH v2 net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: Brian Haley @ 2012-11-17 21:58 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <50A71B50.3030603@parallels.com>
On 11/17/2012 12:06 AM, Pavel Emelyanov wrote:
>> @@ -4165,6 +4180,8 @@ static int dev_ifname(struct net *net, struct ifreq __user
>> *arg)
>>
>> strcpy(ifr.ifr_name, dev->name);
>> rcu_read_unlock();
>> + if (read_seqretry(&devnet_rename_seq, seq))
>> + goto retry;
>
> I believe it makes sense to make the seqcount protection as a separate patch
> with description of what may happen.
I asked about that before and Dave said he "wanted all the races resolved". At
best I could make this a series...
>> +retry:
>> + seq = read_seqbegin(&devnet_rename_seq);
>> + rcu_read_lock();
>> + dev = dev_get_by_index_rcu(net, sk->sk_bound_dev_if);
>
> The sk->sk_bound_dev_if might have changed to 0 while we did read_seqretry (or
> did the len check above, but the race window is smaller) and this code will
> report -ENODEV instead of zero lenght.
If there are two threads twiddling with the same socket like this the
application is broken in my mind.
-Brian
^ permalink raw reply
* RE:
From: UNITED NATION @ 2012-11-17 13:14 UTC (permalink / raw)
To: netdev
Contact Jacek Slotala of Bank Zachodni WBK Poland via his email address : 1744837202@qq.com for your UN Compensation draft worth $550,000.00
^ permalink raw reply
* Re: PROBLEM: freeze when resuming from suspend-to-ram
From: Francois Romieu @ 2012-11-17 19:20 UTC (permalink / raw)
To: Jan Janssen; +Cc: Daniele Venzano, netdev
In-Reply-To: <2582926.dI8WEMfVKW@brinja>
Jan Janssen <medhefgo@web.de> :
[...]
> I'd be glad to help you with that. The bug happens with 3.6.6 and with 3.7-
> rc6. Pick one that suits you best, I can work with both.
/me slaps head.
Please try the patch below against v3.7-rc6
diff --git a/drivers/net/ethernet/sis/sis900.c b/drivers/net/ethernet/sis/sis900.c
index fb9f6b3..edf5edb 100644
--- a/drivers/net/ethernet/sis/sis900.c
+++ b/drivers/net/ethernet/sis/sis900.c
@@ -2479,7 +2479,7 @@ static int sis900_resume(struct pci_dev *pci_dev)
netif_start_queue(net_dev);
/* Workaround for EDB */
- sis900_set_mode(ioaddr, HW_SPEED_10_MBPS, FDX_CAPABLE_HALF_SELECTED);
+ sis900_set_mode(sis_priv, HW_SPEED_10_MBPS, FDX_CAPABLE_HALF_SELECTED);
/* Enable all known interrupts by setting the interrupt mask. */
sw32(imr, RxSOVR | RxORN | RxERR | RxOK | TxURN | TxERR | TxIDLE);
^ permalink raw reply related
* Re: [net-next patch] vxlan: remove unused variable.
From: Stephen Hemminger @ 2012-11-17 17:52 UTC (permalink / raw)
To: Rami Rosen; +Cc: davem, netdev
In-Reply-To: <1353161287-22493-1-git-send-email-ramirose@gmail.com>
On Sat, 17 Nov 2012 16:08:07 +0200
Rami Rosen <ramirose@gmail.com> wrote:
> This patch removes addrexceeded member from vxlan_dev struct as it is unused.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
> ---
> drivers/net/vxlan.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 9814d67..288ad3a 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -117,7 +117,6 @@ struct vxlan_dev {
> spinlock_t hash_lock;
> unsigned int addrcnt;
> unsigned int addrmax;
> - unsigned int addrexceeded;
>
> struct hlist_head fdb_head[FDB_HASH_SIZE];
> };
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply
* Re: PROBLEM: freeze when resuming from suspend-to-ram
From: Jan Janssen @ 2012-11-17 13:21 UTC (permalink / raw)
To: Francois Romieu; +Cc: Daniele Venzano, netdev
In-Reply-To: <20121117105702.GA25549@electric-eye.fr.zoreil.com>
Hi,
On Saturday 17 November 2012 11:57:02 you wrote:
> Jan, is it ok if I split this changeset in smaller chunks to identify
> which part bugs / triggers the problem ? If so please specify a kernel
> version - linusish or stable - I should work with.
I'd be glad to help you with that. The bug happens with 3.6.6 and with 3.7-
rc6. Pick one that suits you best, I can work with both.
Jan
^ permalink raw reply
* Re: [PATCH v2 net-next] sctp: Add support to per-association statistics via a new SCTP_GET_ASSOC_STATS call
From: Neil Horman @ 2012-11-17 13:20 UTC (permalink / raw)
To: Thomas Graf
Cc: Michele Baldessari, linux-sctp, Vlad Yasevich, netdev,
David S. Miller
In-Reply-To: <20121116214742.GH10831@casper.infradead.org>
On Fri, Nov 16, 2012 at 09:47:42PM +0000, Thomas Graf wrote:
> On 11/16/12 at 11:39am, Neil Horman wrote:
> > Yes, I think this is good, I still don't like the idea of having to do these via
> > an ioctl, but I suppose it fits well enough.
>
> I'm with you on this. I have started scribbling notes on paper for
> a netlink based stats retriever. We should discuss this at some
> point making sure we get everyone on board with interests in this
> and solve this nice and clean for everyone to enjoy.
>
Agreed, I was also doodling out some protocol format and kernel API ideas for
this. We have a short week due to Thanksgiving here next week, but why don't I
email you after the holiday and we can exchange thoughts? I think a netlink
stats protocol would be a great way to solve the process-private/global access
problem.
> I guess the ioctl is the best we can do as long as we don't have
> the above.
>
Agreed, it will do, and if we do a good job with the kernel API for the netlink
idea above, maybe we can even inherit existing stats transparently.
Neil
^ permalink raw reply
* [net-next patch] vxlan: remove unused variable.
From: Rami Rosen @ 2012-11-17 14:08 UTC (permalink / raw)
To: davem; +Cc: netdev, shemminger, Rami Rosen
This patch removes addrexceeded member from vxlan_dev struct as it is unused.
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
drivers/net/vxlan.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 9814d67..288ad3a 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -117,7 +117,6 @@ struct vxlan_dev {
spinlock_t hash_lock;
unsigned int addrcnt;
unsigned int addrmax;
- unsigned int addrexceeded;
struct hlist_head fdb_head[FDB_HASH_SIZE];
};
--
1.7.11.7
^ permalink raw reply related
* Re: PROBLEM: freeze when resuming from suspend-to-ram
From: Francois Romieu @ 2012-11-17 10:57 UTC (permalink / raw)
To: Daniele Venzano; +Cc: medhefgo, netdev
In-Reply-To: <20121114211115.GD14880@ge.brownhat.org>
Thanks for Cc:ing Daniele.
Daniele Venzano <venza@brownhat.org> :
> On Sun, Nov 11, 2012 at 08:47:45PM +0100, medhefgo@web.de wrote:
[...]
> The patch is big and, while by looking at it nothing jumps to my eyes as
> clearly wrong, I currently do not have access to sis900 hardware to test
> it. Francois Romieu (in CC), who did the patch, perhaps can shed some light.
Nothing here. I'll search harder but I won't mind some brute force approach
at the same time.
Jan, is it ok if I split this changeset in smaller chunks to identify
which part bugs / triggers the problem ? If so please specify a kernel
version - linusish or stable - I should work with.
--
Ueimor
^ permalink raw reply
* [PATCH v2] checkpatch: add double empty line check
From: Eilon Greenstein @ 2012-11-17 11:17 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Joe Perches, David Rientjes, linux-kernel, netdev
Changes from previous attempt:
- Use CHK instead of WARN
- Issue only one warning per empty lines block
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
scripts/checkpatch.pl | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 21a9f5d..13d264f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3579,6 +3579,14 @@ sub process {
WARN("EXPORTED_WORLD_WRITABLE",
"Exporting world writable files is usually an error. Consider more restrictive permissions.\n" . $herecurr);
}
+
+# check for double empty lines
+ if ($line =~ /^\+\s*$/ &&
+ ($rawlines[$linenr] =~ /^\s*$/ ||
+ $prevline =~ /^\+?\s*$/ && $rawlines[$linenr] !~ /^\+\s*$/)) {
+ CHK("DOUBLE_EMPTY_LINE",
+ "One empty line should be sufficient. Consider removing this one.\n" . $herecurr);
+ }
}
# If we have no input at all, then there is nothing to report on
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] checkpatch: add double empty line check
From: Eilon Greenstein @ 2012-11-17 11:12 UTC (permalink / raw)
To: Joe Perches; +Cc: David Rientjes, Andy Whitcroft, linux-kernel, netdev
In-Reply-To: <1353113454.2512.21.camel@joe-AO722>
On Fri, 2012-11-16 at 16:50 -0800, Joe Perches wrote:
Hi Joe, thanks for replying.
> On Fri, 2012-11-16 at 22:04 +0200, Eilon Greenstein wrote:
> > On Fri, 2012-11-16 at 11:55 -0800, David Rientjes wrote:
> > > On Fri, 16 Nov 2012, Eilon Greenstein wrote:
> > > This is fairly common in all the acpi code where variables declared in a
> > > function are separated from the code in a function.
> > >
> >
> > Indeed, I see that you do use it in some functions.
> >
> > Maybe we can limit it only to the networking tree (similar to the
> > networking comments style) or if the ACPI is the exception, we can apply
> > to all but ACPI.
>
> I'm not sure this should be done.
> Double line spacing has some utility and
> is pretty common.
Since adding double empty line can cause a patch to be rejected, we
should have an easy way to catch it before submitting.
> Perhaps make this a --strict/CHK option
> and also perhaps make sure this isn't
> emitted on consecutive lines.
Indeed, CHK makes more sense. I wanted to have a warning per redundant
line, but since it can be annoying when adding 3 or more empty lines
intentionally, I will issue one comment for consecutive lines.
v2 is on its way.
Thanks,
Eilon
^ permalink raw reply
* Re: [PATCH v7] Network driver for the Armada 370 and Armada XP ARM Marvell SoCs
From: Willy Tarreau @ 2012-11-17 6:48 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: David Miller, romieu, kernel, netdev, linux-arm-kernel, jason,
andrew, gregory.clement, alior, dima
In-Reply-To: <20121115090257.4b9e20c5@skate>
Hi Thomas,
On Thu, Nov 15, 2012 at 09:02:57AM +0100, Thomas Petazzoni wrote:
> David,
>
> On Thu, 15 Nov 2012 02:42:13 -0500 (EST), David Miller wrote:
> > From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > Date: Thu, 15 Nov 2012 08:33:19 +0100
> >
> > > Would you mind if we take, with your Ack, the network driver through
> > > the arm-soc tree, so that we can carry the related patches modifying
> > > the Device Tree and so on? If not, then I'll send you a pull request
> > > with just the drivers/net changes, and we'll integrate the ARM-related
> > > changes through the arm-soc tree, in which we will have the necessary
> > > dependencies. I'm fine with any of those solutions.
> >
> > Sure, no problem, take it via the ARM tree:
> >
> > Acked-by: David S. Miller <davem@davemloft.net>
>
> Excellent, thanks!
Your patch set works fine on my mirabox, feel free to add my tested-by
to the patch set if you want :
Tested-By: Willy Tarreau <w@1wt.eu>
Nice work!
Willy
^ permalink raw reply
* [PATCH] sctp: use bitmap_weight
From: Akinobu Mita @ 2012-11-17 6:39 UTC (permalink / raw)
To: linux-sctp; +Cc: Akinobu Mita, Vlad Yasevich, Sridhar Samudrala, netdev
Use bitmap_weight to count the total number of bits set in bitmap.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: Sridhar Samudrala <sri@us.ibm.com>
Cc: linux-sctp@vger.kernel.org
Cc: netdev@vger.kernel.org
---
net/sctp/tsnmap.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/sctp/tsnmap.c b/net/sctp/tsnmap.c
index b5fb7c4..5f25e0c 100644
--- a/net/sctp/tsnmap.c
+++ b/net/sctp/tsnmap.c
@@ -272,7 +272,7 @@ __u16 sctp_tsnmap_pending(struct sctp_tsnmap *map)
__u32 max_tsn = map->max_tsn_seen;
__u32 base_tsn = map->base_tsn;
__u16 pending_data;
- u32 gap, i;
+ u32 gap;
pending_data = max_tsn - cum_tsn;
gap = max_tsn - base_tsn;
@@ -280,11 +280,7 @@ __u16 sctp_tsnmap_pending(struct sctp_tsnmap *map)
if (gap == 0 || gap >= map->len)
goto out;
- for (i = 0; i < gap+1; i++) {
- if (test_bit(i, map->tsn_map))
- pending_data--;
- }
-
+ pending_data -= bitmap_weight(map->tsn_map, gap + 1);
out:
return pending_data;
}
--
1.7.11.7
^ permalink raw reply related
* Dear Sir/Madam,
From: MICHELA ZARA @ 2012-11-17 0:09 UTC (permalink / raw)
Dear Sir/Madam,
I saw your email address during the course of my research today. My Name
is Allen my wife and I won a Jackpot Lottery of 11.3 million USD in july
and during
the process my wife passed away as a result of cancer illness, we are
donating the sum of $1000,000.00 USD to 6 lucky individual over the
world and if you received this email then you are one of the luck
recipients and all you have to do is get back to me, so that we can send
your details to the payout bank.Please note that you have to contact my
private email for more information(allenvioletlarge823@yahoo.ca)
You can verify this by visiting the web pages below.
http://www.dailymail.co.uk/news/article-1326473/Canadian-couple-Allen-Violet-Large-away-entire-11-2m-lottery-win.html
Goodluck,
Allen and Violet Large
Email:allenvioletlarge823@yahoo.ca
^ permalink raw reply
* Re: [PATCH v2 net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: Pavel Emelyanov @ 2012-11-17 5:06 UTC (permalink / raw)
To: Brian Haley; +Cc: David Miller, Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <50A6A8FB.3050901@hp.com>
> @@ -4165,6 +4180,8 @@ static int dev_ifname(struct net *net, struct ifreq __user
> *arg)
>
> strcpy(ifr.ifr_name, dev->name);
> rcu_read_unlock();
> + if (read_seqretry(&devnet_rename_seq, seq))
> + goto retry;
I believe it makes sense to make the seqcount protection as a separate patch
with description of what may happen.
>
> if (copy_to_user(arg, &ifr, sizeof(struct ifreq)))
> return -EFAULT;
> @@ -562,6 +563,59 @@ out:
> return ret;
> }
>
> +static int sock_getbindtodevice(struct sock *sk, char __user *optval,
> + int __user *optlen, int len)
> +{
> + int ret = -ENOPROTOOPT;
> +#ifdef CONFIG_NETDEVICES
> + struct net *net = sock_net(sk);
> + struct net_device *dev;
> + char devname[IFNAMSIZ];
> + unsigned seq;
> +
> + if (sk->sk_bound_dev_if == 0) {
> + len = 0;
> + goto zero;
> + }
> +
> + ret = -EINVAL;
> + if (len < IFNAMSIZ)
> + goto out;
> +
> +retry:
> + seq = read_seqbegin(&devnet_rename_seq);
> + rcu_read_lock();
> + dev = dev_get_by_index_rcu(net, sk->sk_bound_dev_if);
The sk->sk_bound_dev_if might have changed to 0 while we did read_seqretry (or
did the len check above, but the race window is smaller) and this code will
report -ENODEV instead of zero lenght.
Other than this, the intention looks OK to me.
> + ret = -ENODEV;
> + if (!dev) {
> + rcu_read_unlock();
> + goto out;
> + }
> +
> + strcpy(devname, dev->name);
> + rcu_read_unlock();
> + if (read_seqretry(&devnet_rename_seq, seq))
> + goto retry;
> +
> + len = strlen(devname) + 1;
> +
> + ret = -EFAULT;
> + if (copy_to_user(optval, devname, len))
> + goto out;
> +
Thanks,
Pavel
^ permalink raw reply
* Re: [PATCH 0/4] Implement persistent grant in xen-netfront/netback
From: annie li @ 2012-11-17 4:39 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel@lists.xensource.com, netdev@vger.kernel.org,
konrad.wilk@oracle.com
In-Reply-To: <1353066382.3499.227.camel@zakaz.uk.xensource.com>
On 2012-11-16 19:46, Ian Campbell wrote:
>
> It seems like having netfront simply allocate itself a pool of grant
> references which it reuses would give equivalent benefits whilst being a
> smaller patch, with no protocol change and avoiding double copying. In
> fact by avoiding the double copy I'd expect it to be even better.
>
>
OK, I can try this implementation.
And I'd better to compare the performance between double copy and this
implementation to see how much grant lock affects grant copy too.
> I think you need to measure both dom0->domU and domU->dom0 to get the
> full picture since AIUI netperf sends the bulk data in only one
> direction with just ACKs coming back the other way.
>
Yes.
My environment does not meet requirement of more VMs, I would do more
thorough test after Konrad setups the environment.
Thanks
Annie
^ 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