* Re: [PATCH net 0/3] bridge: Fix undesirable behavior related to vlan
From: Vlad Yasevich @ 2013-11-14 3:14 UTC (permalink / raw)
To: Toshiaki Makita, David S . Miller, Stephen Hemminger, netdev
In-Reply-To: <1384331175-4136-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
On 11/13/2013 03:26 AM, Toshiaki Makita wrote:
> There seem to be some problems around vlan code.
>
> - Unexpectedly filter vlan by NIC.
> - Not correctly decrement refcount of vlan_vid_info.
> - Memory leak when deleting a bridge with vlan_info allocated.
>
> This is a patch series to fix these issues.
>
> Toshiaki Makita (3):
> bridge: Use vlan_vid_[add/del] instead of direct
> ndo_vlan_rx_[add/kill]_vid calls
> bridge: Call vlan_vid_del for all vids at nbp_vlan_flush
> bridge: Fix memory leak when deleting bridge with vlan filtering
> enabled
>
These all look good to me. Thanks you.
Acked-by: Vlad Yasevich <vyasevic@redhat.com>
-vlad
> net/bridge/br_if.c | 1 +
> net/bridge/br_vlan.c | 24 ++++++++++--------------
> 2 files changed, 11 insertions(+), 14 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] random: seed random_int_secret at least poorly at core_initcall time
From: Hannes Frederic Sowa @ 2013-11-14 4:18 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Daniel Borkmann, davem, shemminger, fweimer, netdev, Eric Dumazet,
linux-wireless, keescook
In-Reply-To: <20131114025448.GB31602@thunk.org>
On Wed, Nov 13, 2013 at 09:54:48PM -0500, Theodore Ts'o wrote:
> On Tue, Nov 12, 2013 at 02:46:03PM +0100, Hannes Frederic Sowa wrote:
> > > It is needed by fork to set up the stack canary. And this actually gets
> > > called before the secret is initialized.
> >
> > Maybe we could use this for the time being and use the seeding method
> > of kaslr as soon as it hits the tree?
>
> Hmm, from what I can tell even early_initcall() is going to be early
> enough. The stack canary is set up by boot_init_stack_canary(), which
> is run very, very early in start_kerne() --- way before
> early_initcalls, or even before interrupts are enabled. So adding
> random_int_secret_init_early() as a core_initcall is still too late.
Actually I tried to protect the tsk->stack_canary = get_random_int()
in fork.c. It sets up the per-task canary.
> I wonder if we need to do something in common with what Kees has been
> considering for the kaslr code, since it's a similar issue --- we need
> random number way earlier than we can really afford to initialize
> /dev/random.
Definiteley. I would also propose hashing the boot arguments, often
enough there is a filesystem UUID in there, or even hash the multiboot
information we are given from grub. Maybe compile-time entropy, at least
a bit.
> P.S. Unless I'm missing something (and I hope I am), it would appear
> that the stack canary is going to easily predictable by an attacker on
> non-x86 platforms that don't have RDRAND. Has someone tested whether
> or not the stack canary isn't constant across ARM or pre-Sandy Bridge
> x86 systems?
In case of protection for interrupt stacks and early cmwq threads,
it looks pretty bad from a first look at the source (at least for the
first initialized CPU).
I'll try to do some tests tomorrow.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH] random: seed random_int_secret at least poorly at core_initcall time
From: Hannes Frederic Sowa @ 2013-11-14 5:05 UTC (permalink / raw)
To: Theodore Ts'o, Daniel Borkmann, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
shemminger-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
fweimer-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
Eric Dumazet, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
keescook-F7+t8E8rja9g9hUCZPvPmw
In-Reply-To: <20131114041829.GA26901-5j1vdhnGyZutBveJljeh2VPnkB77EeZ12LY78lusg7I@public.gmane.org>
On Thu, Nov 14, 2013 at 05:18:30AM +0100, Hannes Frederic Sowa wrote:
> On Wed, Nov 13, 2013 at 09:54:48PM -0500, Theodore Ts'o wrote:
> > On Tue, Nov 12, 2013 at 02:46:03PM +0100, Hannes Frederic Sowa wrote:
> > > > It is needed by fork to set up the stack canary. And this actually gets
> > > > called before the secret is initialized.
> > >
> > > Maybe we could use this for the time being and use the seeding method
> > > of kaslr as soon as it hits the tree?
> >
> > Hmm, from what I can tell even early_initcall() is going to be early
> > enough. The stack canary is set up by boot_init_stack_canary(), which
> > is run very, very early in start_kerne() --- way before
> > early_initcalls, or even before interrupts are enabled. So adding
> > random_int_secret_init_early() as a core_initcall is still too late.
>
> Actually I tried to protect the tsk->stack_canary = get_random_int()
> in fork.c. It sets up the per-task canary.
>
> > I wonder if we need to do something in common with what Kees has been
> > considering for the kaslr code, since it's a similar issue --- we need
> > random number way earlier than we can really afford to initialize
> > /dev/random.
>
> Definiteley. I would also propose hashing the boot arguments, often
> enough there is a filesystem UUID in there, or even hash the multiboot
> information we are given from grub. Maybe compile-time entropy, at least
> a bit.
>
> > P.S. Unless I'm missing something (and I hope I am), it would appear
> > that the stack canary is going to easily predictable by an attacker on
> > non-x86 platforms that don't have RDRAND. Has someone tested whether
> > or not the stack canary isn't constant across ARM or pre-Sandy Bridge
> > x86 systems?
>
> In case of protection for interrupt stacks and early cmwq threads,
> it looks pretty bad from a first look at the source (at least for the
> first initialized CPU).
First output on first cpu of get_random_bytes is always identical on amd64
without rdrand. :/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC][PATCH 0/3] net_tstamp: Add SIOCGHWTSTAMP ioctl
From: David Miller @ 2013-11-14 6:50 UTC (permalink / raw)
To: bhutchings; +Cc: richardcochran, netdev, linux-net-drivers
In-Reply-To: <1384396635.29151.36.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 14 Nov 2013 02:37:15 +0000
> SIOCSHWTSTAMP returns the real configuration to the application
> using it, but there is currently no way for any other
> application to find out the configuration non-destructively.
>
> This series adds a new ioctl with the obvious name which just reads the
> configuration, and an example implementation for the sfc driver.
>
> This information could alternately be added to struct ethtool_ts_info
> returned by the ethtool ETHTOOL_GET_TS_INFO command, although that
> wouldn't be very symmetric. There would also be a problem of how to
> indicate whether this extra information is present, given that all
> fields of hwtstamp_config can validly be 0.
No objections to the new ioctl, but you absolutely need to implement
the appropriate compat ioctl handler in net/socket.c just as we have
one for the existing SIOCSHWTSTAMP.
Thanks.
^ permalink raw reply
* Re: Test program for SIOC{G,S}HWTSTAMP
From: David Miller @ 2013-11-14 6:51 UTC (permalink / raw)
To: bhutchings; +Cc: richardcochran, netdev, linux-net-drivers
In-Reply-To: <1384397184.29151.44.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 14 Nov 2013 02:46:24 +0000
> I used this to exercise the two ioctls.
You could put this under Documentation/networking/timestamping/
There is already example code there.
^ permalink raw reply
* Re: [PATCH net 0/6] net_tstamp: Validate hwtstamp_config completely before applying it
From: David Miller @ 2013-11-14 6:53 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, richardcochran
In-Reply-To: <1384389542.29151.5.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 14 Nov 2013 00:39:02 +0000
> This series fixes very similar bugs in 6 implementations of
> SIOCSHWTSTAMP.
This looks fine to me, I'll just way a day or so for driver maintainers
to ACK.
^ permalink raw reply
* [patch iproute2] lib/utils.c: should return correct error message
From: Hangbin Liu @ 2013-11-14 7:00 UTC (permalink / raw)
To: network dev; +Cc: Hangbin Liu
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
lib/utils.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/utils.c b/lib/utils.c
index 4e9c719..59221b2 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -487,7 +487,11 @@ int get_addr(inet_prefix *dst, const char *arg, int family)
exit(1);
}
if (get_addr_1(dst, arg, family)) {
- fprintf(stderr, "Error: an inet address is expected rather than \"%s\".\n", arg);
+ // FIXME: Don't know how to handle AF_UNSPEC and AF_DECnet
+ if (family == AF_INET6)
+ fprintf(stderr, "Error: an inet6 address is expected rather than \"%s\".\n", arg);
+ else
+ fprintf(stderr, "Error: an inet address is expected rather than \"%s\".\n", arg);
exit(1);
}
return 0;
@@ -500,7 +504,11 @@ int get_prefix(inet_prefix *dst, char *arg, int family)
exit(1);
}
if (get_prefix_1(dst, arg, family)) {
- fprintf(stderr, "Error: an inet prefix is expected rather than \"%s\".\n", arg);
+ // FIXME: Don't know how to handle AF_DECnet
+ if (family == AF_INET6)
+ fprintf(stderr, "Error: an inet6 prefix is expected rather than \"%s\".\n", arg);
+ else
+ fprintf(stderr, "Error: an inet prefix is expected rather than \"%s\".\n", arg);
exit(1);
}
return 0;
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH] rds: fix local ping DoS
From: David Miller @ 2013-11-14 7:03 UTC (permalink / raw)
To: johunt; +Cc: netdev, venkat.x.venkatsubra, linux-kernel, jjolly, fenlason,
honli
In-Reply-To: <1384391743-9342-1-git-send-email-johunt@akamai.com>
From: Josh Hunt <johunt@akamai.com>
Date: Wed, 13 Nov 2013 17:15:43 -0800
> The rds_ib_xmit function in net/rds/ib_send.c in the Reliable Datagram Sockets
> (RDS) protocol implementation allows local users to cause a denial of service
> (BUG_ON and kernel panic) by establishing an RDS connection with the source
> IP address equal to the IPoIB interface's own IP address, as demonstrated by
> rds-ping.
>
> A local unprivileged user could use this flaw to crash the system.
>
> CVE-2012-2372
>
> Reported-by: Honggang Li <honli@redhat.com>
> Signed-off-by: Josh Hunt <johunt@akamai.com>
I'm sorry I can't apply this. This commit message needs to be much
less terse and explain things more.
First of all, why is the "off % RDS_FRAG_SIZE" important?
And, even more importantly, why is is OK to avoid this assertion just
because we're going over loopback?
Furthermore, why doesn't net/rds/iw_send.c:rds_iw_xmit() have the same
exact problem? It makes the same exact assertion check.
I know this RDS code is a steaming pile of poo, but that doesn't mean
we just randomly adjust assertions to make crashes go away without
sufficient understanding of exactly what's going on.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/2 v4] Open vSwitch zerocopy upcall
From: David Miller @ 2013-11-14 7:13 UTC (permalink / raw)
To: tgraf; +Cc: jesse, dev, netdev, eric.dumazet
In-Reply-To: <cover.1383906944.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Fri, 8 Nov 2013 11:47:16 +0100
> Respin of the zerocopy patches for the openvswitch upcall.
>
> V4: - Daniel Borkmann pointed out that the style in skbuff.h has changed
> in net-next, adapted to no longer using extern in headers.
> V3: - Removed unneeded alignment of nlmsg_len after padding
> V2: - Added skb_zerocopy_headlen() to calculate headroom of destination
> buffer. This also takes care of the from->head_frag issue.
> - Attribute alignment for frag_list case
> - API documentation
> - performance data for CHECKSUM_PARTIAL tx case
>
> Thomas Graf (2):
> net: Export skb_zerocopy() to zerocopy from one skb to another
> openvswitch: Use skb_zerocopy() for upcall
No objections from me for these changes, but it's too late for the
current merge window.
Jesse can feel free to queue this up in his tree and you can add my:
Acked-by: David S. Miller <davem@davemloft.net>
to these patches.
Thanks!
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: cxgb3: Update cxgb3 maintainer entry
From: David Miller @ 2013-11-14 7:18 UTC (permalink / raw)
To: divy; +Cc: netdev, santosh, linux-kernel
In-Reply-To: <20131111230139.5105.31716.stgit@zola.asicdesigners.com>
From: Divy Le Ray <divy@chelsio.com>
Date: Mon, 11 Nov 2013 15:01:39 -0800
> Santosh raspatur is taking over the maintenance of cxgb3.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net 3/6] pch_gbe: Validate hwtstamp_config completely before applying it
From: Richard Cochran @ 2013-11-14 7:21 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1384389770.29151.9.camel@bwh-desktop.uk.level5networks.com>
On Thu, Nov 14, 2013 at 12:42:50AM +0000, Ben Hutchings wrote:
> --- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> +++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> @@ -245,16 +245,8 @@ static int hwtstamp_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
> /* Get ieee1588's dev information */
> pdev = adapter->ptp_pdev;
>
> - switch (cfg.tx_type) {
> - case HWTSTAMP_TX_OFF:
> - adapter->hwts_tx_en = 0;
> - break;
> - case HWTSTAMP_TX_ON:
> - adapter->hwts_tx_en = 1;
> - break;
> - default:
> + if (cfg.tx_type != HWTSTAMP_TX_OFF && cfg.tx_type != HWTSTAMP_TX_ON)
> return -ERANGE;
> - }
>
> switch (cfg.rx_filter) {
> case HWTSTAMP_FILTER_NONE:
> @@ -284,6 +276,8 @@ static int hwtstamp_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
> return -ERANGE;
> }
>
> + adapter->hwts_tx_en = cfg.tx_type == HWTSTAMP_TX_ON;
> +
But now there is no way to turn transmit time stamping off?
> /* Clear out any old time stamps. */
> pch_ch_event_write(pdev, TX_SNAPSHOT_LOCKED | RX_SNAPSHOT_LOCKED);
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net] neigh: Force garbage collection if an entry is deleted administratively
From: David Miller @ 2013-11-14 7:23 UTC (permalink / raw)
To: steffen.klassert; +Cc: yoshfuji, netdev
In-Reply-To: <20131112085714.GU31491@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 12 Nov 2013 09:57:14 +0100
> Since git commit 2724680 ("neigh: Keep neighbour cache entries if number
> of them is small enough."), we keep all neighbour cache entries if the
> number is below a threshold. But if we now delete an entry administratively
> and then try to replace this by a permanent one, we get -EEXIST because the
> old entry ist still in the table (in NUD_FAILED state).
>
> So lets force a garbage collect if we delete an entry administratively.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
I don't think this is a sufficient fix.
If some entity refers to this entry (refcnt != 1) then the forced
GC won't do anything, and this is very much possible.
It is the difficult situation mentioned in a comment in
neigh_flush_dev() below the "refcnt != 1" test there.
^ permalink raw reply
* Re: Bug - regression - Via velocity interface coming up freezes kernel
From: Francois Romieu @ 2013-11-14 7:24 UTC (permalink / raw)
To: Michele Baldessari; +Cc: Dirk Kraft, netdev, Julia Lawall
In-Reply-To: <20131111234656.GA4846@marquez.int.rhx>
Michele Baldessari <michele@acksyn.org> :
[...]
> any chance you can submit this officially ?
Yes.
> Or does this patch need some more work ?
I'll write some narrative for the commit message.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net 3/6] pch_gbe: Validate hwtstamp_config completely before applying it
From: Richard Cochran @ 2013-11-14 7:27 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <20131114072011.GA4908@netboy>
On Thu, Nov 14, 2013 at 08:21:37AM +0100, Richard Cochran wrote:
> On Thu, Nov 14, 2013 at 12:42:50AM +0000, Ben Hutchings wrote:
> >
> > + adapter->hwts_tx_en = cfg.tx_type == HWTSTAMP_TX_ON;
> > +
>
> But now there is no way to turn transmit time stamping off?
Sorry, overlooked that '==' operator. Tricky.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net] bonding: don't permit to use ARP monitoring in 802.3ad mode
From: David Miller @ 2013-11-14 7:29 UTC (permalink / raw)
To: vfalico; +Cc: netdev, fubar, andy
In-Reply-To: <1384267060-10851-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Tue, 12 Nov 2013 15:37:40 +0100
> Currently the ARP monitoring is not supported with 802.3ad, and it's
> prohibited to use it via the module params.
>
> However we still can set it afterwards via sysfs, cause we only check for
> *LB modes there.
>
> To fix this - add a check for 802.3ad mode in bonding_store_arp_interval.
>
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] usbnet: fix status interrupt urb handling
From: David Miller @ 2013-11-14 7:33 UTC (permalink / raw)
To: nbd-p3rKhJxN3npAfugRpC6u6w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
dcbw-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1384270481-30972-1-git-send-email-nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
From: Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
Date: Tue, 12 Nov 2013 16:34:41 +0100
> Since commit 7b0c5f21f348a66de495868b8df0284e8dfd6bbf
> "sierra_net: keep status interrupt URB active", sierra_net triggers
> status interrupt polling before the net_device is opened (in order to
> properly receive the sync message response).
>
> To be able to receive further interrupts, the interrupt urb needs to be
> re-submitted, so this patch removes the bogus check for netif_running().
>
> Signed-off-by: Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 1/4] virtio-net: mergeable buffer size should include virtio-net header
From: David Miller @ 2013-11-14 7:38 UTC (permalink / raw)
To: mwdalton; +Cc: mst, netdev, dborkman, virtualization, edumazet
In-Reply-To: <1384294885-6444-1-git-send-email-mwdalton@google.com>
From: Michael Dalton <mwdalton@google.com>
Date: Tue, 12 Nov 2013 14:21:22 -0800
> Commit 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page
> frag allocators") changed the mergeable receive buffer size from PAGE_SIZE
> to MTU-size. However, the merge buffer size does not take into account the
> size of the virtio-net header. Consequently, packets that are MTU-size
> will take two buffers intead of one (to store the virtio-net header),
> substantially decreasing the throughput of MTU-size traffic due to TCP
> window / SKB truesize effects.
>
> This commit changes the mergeable buffer size to include the virtio-net
> header. The buffer size is cacheline-aligned because skb_page_frag_refill
> will not automatically align the requested size.
>
> Benchmarks taken from an average of 5 netperf 30-second TCP_STREAM runs
> between two QEMU VMs on a single physical machine. Each VM has two VCPUs and
> vhost enabled. All VMs and vhost threads run in a single 4 CPU cgroup
> cpuset, using cgroups to ensure that other processes in the system will not
> be scheduled on the benchmark CPUs. Transmit offloads and mergeable receive
> buffers are enabled, but guest_tso4 / guest_csum are explicitly disabled to
> force MTU-sized packets on the receiver.
>
> next-net trunk before 2613af0ed18a (PAGE_SIZE buf): 3861.08Gb/s
> net-next trunk (MTU 1500- packet uses two buf due to size bug): 4076.62Gb/s
> net-next trunk (MTU 1480- packet fits in one buf): 6301.34Gb/s
> net-next trunk w/ size fix (MTU 1500 - packet fits in one buf): 6445.44Gb/s
>
> Suggested-by: Eric Northup <digitaleric@google.com>
> Signed-off-by: Michael Dalton <mwdalton@google.com>
Michael, please submit this seperately for the 'net' tree as it is
a bug fix.
The rest of this series are optimizations and should be resubmitted
when the merge window closes and the 'net-next' tree opens back up.
^ permalink raw reply
* Re: [PATCH v2 net] core/dev: do not ignore dmac in dev_forward_skb()
From: David Miller @ 2013-11-14 7:40 UTC (permalink / raw)
To: ast; +Cc: edumazet, netdev, yamahatanetdev, zenczykowski, nicolas.dichtel
In-Reply-To: <1384295953-8332-1-git-send-email-ast@plumgrid.com>
From: Alexei Starovoitov <ast@plumgrid.com>
Date: Tue, 12 Nov 2013 14:39:13 -0800
> commit 06a23fe31ca3
> ("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()")
> and refactoring 64261f230a91
> ("dev: move skb_scrub_packet() after eth_type_trans()")
>
> are forcing pkt_type to be PACKET_HOST when skb traverses veth.
>
> which means that ip forwarding will kick in inside netns
> even if skb->eth->h_dest != dev->dev_addr
>
> Fix order of eth_type_trans() and skb_scrub_packet() in dev_forward_skb()
> and in ip_tunnel_rcv()
>
> Fixes: 06a23fe31ca3 ("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()")
> CC: Isaku Yamahata <yamahatanetdev@gmail.com>
> CC: Maciej Zenczykowski <zenczykowski@gmail.com>
> CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [RFC][PATCH 0/3] net_tstamp: Add SIOCGHWTSTAMP ioctl
From: Richard Cochran @ 2013-11-14 7:41 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <1384396635.29151.36.camel@bwh-desktop.uk.level5networks.com>
On Thu, Nov 14, 2013 at 02:37:15AM +0000, Ben Hutchings wrote:
> SIOCSHWTSTAMP returns the real configuration to the application
> using it, but there is currently no way for any other
> application to find out the configuration non-destructively.
I guess that the reasoning behind the original interface is that an
application only wants to know the settings when it needs a particular
setting in order to operate correctly. This would make the query call
pointless, since the application might as well just go ahead and set
the values that it needs.
Do you have a particular use case in mind?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH V3] usbnet: fix race condition caused spinlock bad magic issue
From: Oliver Neukum @ 2013-11-14 7:44 UTC (permalink / raw)
To: wangbiao
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, mingo-X9Un+BFzKDI,
a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw, rusty-8n+1lVoiYb80n/F98K4Iww,
william.douglas-ral2JQCrhuEAvxtiuMwx3w,
di.zhang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <1384394595.4229.24.camel@wangbiao>
On Thu, 2013-11-14 at 10:03 +0800, wangbiao wrote:
> From: wang, biao <biao.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date: Mon, 11 Nov 2013 10:23:40 +0800
> Subject: [PATCH] usbnet: fix race condition caused spinlock bad magic issue
>
> there is race between usbnet_terminate_urbs and usbnet_bh.
> for example:
> cpu 0 cpu 1
> usbnet_suspend
> usbnet_bh { ->usbnet_terminate_urbs {
> dev->wait = &unlink_wakeup;
> while(....){..}//break
> if(dev->wait) is true
> dev->wait=NULL
> }//unlink_wakeup is invalid
> __wake_up(dev->wait)//garbage value
> }
>
> the race is due to unprotection of dev->wait, so this patch involves a
> spinlock to avoid it.
>
> Signed-off-by: wang, biao <biao.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Zhang, Di <di.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Acked-by: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: make of_get_phy_mode parse 'phy-connection-type'
From: Grant Likely @ 2013-11-14 7:47 UTC (permalink / raw)
To: Florian Fainelli
Cc: rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Florian Fainelli
In-Reply-To: <1384386147-13817-1-git-send-email-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, 13 Nov 2013 15:42:27 -0800, "Florian Fainelli" <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Per the ePAPR v1.1 specification, 'phy-connection-type' is the canonical
> property name for describing an Ethernet to PHY connection type. Make
> sure that of_get_phy_mode() also attempts to parse that property and
> update the comments mentioninng 'phy-mode' to also include
> 'phy-connection-type'.
>
> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/of/of_net.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
> index 8f9be2e..101a34c 100644
> --- a/drivers/of/of_net.c
> +++ b/drivers/of/of_net.c
> @@ -13,8 +13,8 @@
>
> /**
> * It maps 'enum phy_interface_t' found in include/linux/phy.h
> - * into the device tree binding of 'phy-mode', so that Ethernet
> - * device driver can get phy interface from device tree.
> + * into the device tree binding of 'phy-mode' or 'phy-connection-type',
> + * so that Ethernet device driver can get phy interface from device tree.
> */
> static const char *phy_modes[] = {
> [PHY_INTERFACE_MODE_NA] = "",
> @@ -36,8 +36,9 @@ static const char *phy_modes[] = {
> * of_get_phy_mode - Get phy mode for given device_node
> * @np: Pointer to the given device_node
> *
> - * The function gets phy interface string from property 'phy-mode',
> - * and return its index in phy_modes table, or errno in error case.
> + * The function gets phy interface string from property 'phy-mode' or
> + * 'phy-connection-type', and return its index in phy_modes table, or errno in
> + * error case.
> */
> int of_get_phy_mode(struct device_node *np)
> {
> @@ -45,8 +46,11 @@ int of_get_phy_mode(struct device_node *np)
> int err, i;
>
> err = of_property_read_string(np, "phy-mode", &pm);
> - if (err < 0)
> - return err;
> + if (err < 0) {
> + err = of_property_read_string(np, "phy-connection-type", &pm);
> + if (err < 0)
> + return err;
> + }
Nit: The following would actually be better:
err = of_property_read_string(np, "phy-mode", &pm);
+ if (err < 0)
+ err = of_property_read_string(np, "phy-connection-type", &pm);
if (err < 0)
return err;
Otherwise, the patch looks fine. If you test and repost then it can be merged with my:
Acked-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe - Profihost AG @ 2013-11-14 7:47 UTC (permalink / raw)
To: vyasevic, Vlad Yasevich, Veaceslav Falico; +Cc: Linux Netdev List
In-Reply-To: <52843EEA.3020905@redhat.com>
Hi,
> eth2
> \
> -- bond1 -- vmbr1
> / \
> eth3 ----- bond1.3000 --- vmbr1v3000
> \ ---- tap114i1
thos one works fine now.
> eth2
> \
> -- bond1 -- vmbr1
> / \
> eth3 \ vmbr1.3000
> \ ---- tap114i1
this one does not. Another note to this one. It also never worked on
RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
3.10. But it was the only one where gvrp on vlans had worked.
Greets,
Stefan
^ permalink raw reply
* Re: [PATCH V3] usbnet: fix race condition caused spinlock bad magic issue
From: Ingo Molnar @ 2013-11-14 7:58 UTC (permalink / raw)
To: wangbiao
Cc: oneukum, netdev, linux-usb, linux-kernel, akpm, mingo,
a.p.zijlstra, rusty, william.douglas, di.zhang
In-Reply-To: <1384394595.4229.24.camel@wangbiao>
* wangbiao <biao.wang@intel.com> wrote:
> @@ -86,6 +86,7 @@ static const char driver_name [] = "usbnet";
>
> /* use ethtool to change the level for any given device */
> static int msg_level = -1;
> +static spinlock_t dev_wait_lock = __SPIN_LOCK_UNLOCKED(dev_wait_lock);
> module_param (msg_level, int, 0);
> MODULE_PARM_DESC (msg_level, "Override default message level");
>
> @@ -1447,13 +1454,18 @@ static void usbnet_bh (unsigned long param)
> clear_bit(EVENT_RX_KILL, &dev->flags);
>
> // waiting for all pending urbs to complete?
Please escape this code from the clutches of C++ style!
> + spin_lock_irqsave(&dev_wait_lock, flags);
> if (dev->wait) {
> if ((dev->txq.qlen + dev->rxq.qlen + dev->done.qlen) == 0) {
> - wake_up (dev->wait);
> + wake_up(dev->wait);
> }
> + spin_unlock_irqrestore(&dev_wait_lock, flags);
> + return;
> + }
> + spin_unlock_irqrestore(&dev_wait_lock, flags);
The extra locking and the naked return from the middle of the
control flow is a bit sad.
>
> // or are we maybe short a few urbs?
> - } else if (netif_running (dev->net) &&
> + if (netif_running(dev->net) &&
> netif_device_present (dev->net) &&
> netif_carrier_ok(dev->net) &&
> !timer_pending (&dev->delay) &&
While using a global spinlock from the probe/teardown methods is
probably not a big deal, using it in usbnet_bh() looks rather
unfortunate for performance and scalability of this driver.
I don't know the usbnet code at all, but is there really no
natural per device synchronization method available for such
cases? Could the race be avoided some other way? How do other
drivers implement such kind of dev->wait handling?
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH iproute2] htb: support 64bit rates
From: Yang Yingliang @ 2013-11-14 8:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1384352510.28458.105.camel@edumazet-glaptop2.roam.corp.google.com>
On 2013/11/13 22:21, Eric Dumazet wrote:
> On Wed, 2013-11-13 at 17:11 +0800, Yang Yingliang wrote:
>>> - if (!buffer) buffer = opt.rate.rate / get_hz() + mtu;
>>> - if (!cbuffer) cbuffer = opt.ceil.rate / get_hz() + mtu;
>>> + if (!buffer)
>>> + buffer = rate64 / get_hz() + mtu;
>>> + if (!cbuffer)
>>> + cbuffer = ceil64 / get_hz() + mtu;
>>
>> Hi,
>> It may overflow here if rate64 and mtu are big enough.
>
> Not really.
>
> get_hz() on current kernels is really huge : 1000000000
Yeah, in normal condition, it won't happen.
If user make a wrong input, such as "rate 0x800000000Gbit",
Overflow happens. Although it has no impact on the value of the "opt.buffer".
If it's better to have a judgement of the buffer's value. :)
Regards,
Yang
>
>
>
>
> --
> 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] net: cdc_ncm: cleanup a type issue in cdc_ncm_setup()
From: David Miller @ 2013-11-14 8:10 UTC (permalink / raw)
To: dan.carpenter; +Cc: oliver, linux-usb, netdev, kernel-janitors
In-Reply-To: <20131113074234.GB25541@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 13 Nov 2013 10:42:34 +0300
> This is harmless but cdc_ncm_setup() returns negative error codes
> truncated to u8 values. There is only one caller and treats all
> non-zero returns as errors but doesn't store the the return code. So
> the code works correctly but it's messy and upsets the static checkers.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ 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