* Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.
From: David Howells @ 2016-04-07 19:43 UTC (permalink / raw)
To: Joe Perches; +Cc: dhowells, linux-afs, netdev, linux-kernel
In-Reply-To: <1460049545.6715.98.camel@perches.com>
Joe Perches <joe@perches.com> wrote:
> > Joe Perches <joe@perches.com> wrote:
> > > It might be better to remove kenter and _enter
> > > altogether and use function tracing instead.
> > Possibly - but not at this time.
>
> Swell.
I didn't say I wouldn't do it - it's just that I'm trying to fix other stuff
at the moment and don't particularly want to add that to the list just now.
kenter, _enter and co. are serving me very well.
> > Besides, isn't the function tracing log lost
> > if the machine crashes?
>
> I believe yes, but would it matter?
Let's see... If the machine panics whilst I'm developing stuff (quite likely
if something goes wrong in BH context), how do I get at the function tracing
log to find out why it panicked if the log is then lost? With the serial
console, at least I automatically capture the output of kenter and co..
David
^ permalink raw reply
* Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.
From: David Howells @ 2016-04-07 19:45 UTC (permalink / raw)
To: David Miller; +Cc: dhowells, joe, linux-afs, netdev, linux-kernel
In-Reply-To: <20160407.133843.156901424652264502.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> Yeah this custom stuff is really inappropriate given the excellent
> infrastructure we have these days...
Excellent only if I can get at it to find out why the something went wrong.
If it's lost because the machine panics, then it is worthless.
David
^ permalink raw reply
* Re: [PATCH V2 6/8] net: mediatek: fix TX locking
From: Sergei Shtylyov @ 2016-04-07 19:46 UTC (permalink / raw)
To: John Crispin, David S. Miller
Cc: Felix Fietkau, Matthias Brugger,
Sean Wang (王志亘), netdev, linux-mediatek,
linux-kernel
In-Reply-To: <1460057210-55786-7-git-send-email-blogic@openwrt.org>
Hello.
On 04/07/2016 10:26 PM, John Crispin wrote:
> Inside the TX path there is a lock inside the tx_map function. This is
> however too late. The patch moves the lock to the start of the xmit
> function right before the free count check of the DMA ring happens.
> If we do not do this, the code becomes racy leading to TX stalls and
> dropped packets. This happens as there are 2 netdevs running on the
> same physical DMA ring.
>
> Signed-off-by: John Crispin <blogic@openwrt.org>
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 60b66ab..8434355 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
[...]
> @@ -712,14 +702,22 @@ static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
> struct mtk_eth *eth = mac->hw;
> struct mtk_tx_ring *ring = ð->tx_ring;
> struct net_device_stats *stats = &dev->stats;
> + unsigned long flags;
> bool gso = false;
> int tx_num;
>
> + /* normally we can rely on the stack not calling this more than once,
> + * however we have 2 queues running ont he same ring so we need to lock
s/ont he/ on the/, perhaps a good chance to fix the comment?
> + * the ring access
> + */
> + spin_lock_irqsave(ð->page_lock, flags);
> +
> tx_num = mtk_cal_txd_req(skb);
> if (unlikely(atomic_read(&ring->free_count) <= tx_num)) {
> mtk_stop_queue(eth);
> netif_err(eth, tx_queued, dev,
> "Tx Ring full when queue awake!\n");
> + spin_unlock_irqrestore(ð->page_lock, flags);
> return NETDEV_TX_BUSY;
> }
>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [Lsf] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Waskiewicz, PJ @ 2016-04-07 19:48 UTC (permalink / raw)
To: lsf@lists.linux-foundation.org, linux-mm@kvack.org,
brouer@redhat.com
Cc: netdev@vger.kernel.org, bblanco@plumgrid.com,
alexei.starovoitov@gmail.com,
James.Bottomley@HansenPartnership.com, tom@herbertland.com,
lsf-pc@lists.linux-foundation.org
In-Reply-To: <20160407161715.52635cac@redhat.com>
On Thu, 2016-04-07 at 16:17 +0200, Jesper Dangaard Brouer wrote:
> (Topic proposal for MM-summit)
>
> Network Interface Cards (NIC) drivers, and increasing speeds stress
> the page-allocator (and DMA APIs). A number of driver specific
> open-coded approaches exists that work-around these bottlenecks in
> the
> page allocator and DMA APIs. E.g. open-coded recycle mechanisms, and
> allocating larger pages and handing-out page "fragments".
>
> I'm proposing a generic page-pool recycle facility, that can cover
> the
> driver use-cases, increase performance and open up for zero-copy RX.
Is this based on the page recycle stuff from ixgbe that used to be in
the driver? If so I'd really like to be part of the discussion.
-PJ
--
PJ Waskiewicz
Principal Engineer, NetApp
e: pj.waskiewicz@netapp.com
d: 503.961.3705
^ permalink raw reply
* Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver
From: Andrew Lunn @ 2016-04-07 20:10 UTC (permalink / raw)
To: Timur Tabi
Cc: Rob Herring, Gilad Avidov, netdev,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm,
Sagar Dharia, shankerd-sgV2jX0FEOL9JmXXK+q4OQ, Greg Kroah-Hartman,
vikrams-sgV2jX0FEOL9JmXXK+q4OQ, Christopher Covington
In-Reply-To: <5706B4EF.2050600-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> I'm back to working on this driver, and I need some more help with
> how to handle the phy. mdio-gpio.txt doesn't really tell me much.
> I'm actually working on an ACPI system and not DT.
I can help you with DT, but not ACPI.
The MDIO bus can be a separate Linux device. Since you have GPIO lines
for the MDIO bus, it makes sense for this to be a mdio-gpio device. So
in DT, you would have:
mdio0: mdio {
compatible = "virtual,mdio-gpio";
#address-cells = <1>;
#size-cells = <0>;
gpios = <&qcomgpio 123 0
&qcomgpio 124 0>;
phy0: ethernet-phy@8 {
reg = <9>;
};
};
Here i've assumed the PHY is using address 8 on the bus. Change as
needed.
In your MAC DT node, you then have phy-handle pointing to this phy:
emac0: qcom,emac@feb20000 {
cell-index = <0>;
compatible = "qcom,emac";
reg-names = "base", "csr", "ptp", "sgmii";
reg = <0xfeb20000 0x10000>,
<0xfeb36000 0x1000>,
<0xfeb3c000 0x4000>,
<0xfeb38000 0x400>;
#address-cells = <0>;
interrupt-parent = <&emac0>;
#interrupt-cells = <1>;
interrupts = <0 1>;
interrupt-map-mask = <0xffffffff>;
interrupt-map = <0 &intc 0 76 0
1 &intc 0 80 0>;
interrupt-names = "emac_core0", "sgmii_irq";
qcom,emac-tstamp-en;
qcom,emac-ptp-frac-ns-adj = <125000000 1>;
phy-handle = <&phy0>
}
In the driver, you need to connect the PHY to the MAC. You do this
using something like:
if (dev->of_node) {
phy_np = of_parse_phandle(dev->of_node, "phy-handle", 0);
if (!phy_np) {
netdev_dbg(ndev, "No phy-handle found in DT\n");
return -ENODEV;
}
phy_dev = of_phy_connect(ndev, phy_np, &xxxx_enet_adjust_link,
0, pdata->phy_mode);
if (!phy_dev) {
netdev_err(ndev, "Could not connect to PHY\n");
return -ENODEV;
}
Do you have an ACPI table describing this hardware? What does it look
like?
Andrew
--
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: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.
From: Joe Perches @ 2016-04-07 20:21 UTC (permalink / raw)
To: David Howells; +Cc: linux-afs, netdev, linux-kernel
In-Reply-To: <981.1460058224@warthog.procyon.org.uk>
On Thu, 2016-04-07 at 20:43 +0100, David Howells wrote:
> Joe Perches <joe@perches.com> wrote:
> > > Joe Perches <joe@perches.com> wrote:
> > > > It might be better to remove kenter and _enter
> > > > altogether and use function tracing instead.
> > > Possibly - but not at this time.
> > Swell.
> I didn't say I wouldn't do it - it's just that I'm trying to fix other stuff
> at the moment and don't particularly want to add that to the list just now.
> kenter, _enter and co. are serving me very well.
No worries, I didn't mean to imply you wouldn't.
It's your code, do what and when you want.
> > > Besides, isn't the function tracing log lost
> > > if the machine crashes?
> > I believe yes, but would it matter?
> Let's see... If the machine panics whilst I'm developing stuff (quite likely
> if something goes wrong in BH context), how do I get at the function tracing
> log to find out why it panicked if the log is then lost? With the serial
> console, at least I automatically capture the output of kenter and co..
But you also don't get a bunch of other useful stuff.
btw: there is ftrace_dump_on_oops
https://lwn.net/Articles/366796/
^ permalink raw reply
* Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.
From: David Miller @ 2016-04-07 20:36 UTC (permalink / raw)
To: dhowells; +Cc: joe, linux-afs, netdev, linux-kernel
In-Reply-To: <1091.1460058308@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Thu, 07 Apr 2016 20:45:08 +0100
> David Miller <davem@davemloft.net> wrote:
>
>> Yeah this custom stuff is really inappropriate given the excellent
>> infrastructure we have these days...
>
> Excellent only if I can get at it to find out why the something went wrong.
> If it's lost because the machine panics, then it is worthless.
If you're ok with these kenter things spewing into the logs with the
current facility, you can run the function tracer and have it record
into the logs all the time too.
I don't see any argument which is appropriate for keeping this stuff
around.
^ permalink raw reply
* Re: [Lsf] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Jesper Dangaard Brouer @ 2016-04-07 20:38 UTC (permalink / raw)
To: Waskiewicz, PJ
Cc: lsf@lists.linux-foundation.org, linux-mm@kvack.org,
netdev@vger.kernel.org, bblanco@plumgrid.com,
alexei.starovoitov@gmail.com,
James.Bottomley@HansenPartnership.com, tom@herbertland.com,
lsf-pc@lists.linux-foundation.org, brouer
In-Reply-To: <1460058531.13579.12.camel@netapp.com>
On Thu, 7 Apr 2016 19:48:50 +0000
"Waskiewicz, PJ" <PJ.Waskiewicz@netapp.com> wrote:
> On Thu, 2016-04-07 at 16:17 +0200, Jesper Dangaard Brouer wrote:
> > (Topic proposal for MM-summit)
> >
> > Network Interface Cards (NIC) drivers, and increasing speeds stress
> > the page-allocator (and DMA APIs). A number of driver specific
> > open-coded approaches exists that work-around these bottlenecks in
> > the
> > page allocator and DMA APIs. E.g. open-coded recycle mechanisms, and
> > allocating larger pages and handing-out page "fragments".
> >
> > I'm proposing a generic page-pool recycle facility, that can cover
> > the
> > driver use-cases, increase performance and open up for zero-copy RX.
>
> Is this based on the page recycle stuff from ixgbe that used to be in
> the driver? If so I'd really like to be part of the discussion.
Okay, so it is not part of the driver any-longer? I've studied the
current ixgbe driver (and other NIC drivers) closely. Do you have some
code pointers, to this older code?
The likely-fastest recycle code I've see is in the bnx2x driver. If
you are interested see: bnx2x_reuse_rx_data(). Again is it a bit
open-coded produce/consumer ring queue (which would be nice to also
cleanup).
To amortize the cost of allocating a single page, most other drivers
use the trick of allocating a larger (compound) page, and partition
this page into smaller "fragments". Which also amortize the cost of
dma_map/unmap (important on non-x86).
This is actually problematic performance wise, because packet-data
(in these page fragments) only get DMA_sync'ed, and is thus considered
"read-only". As netstack need to write packet headers, yet-another
(writable) memory area is allocated per packet (plus the SKB meta-data
struct).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.
From: David Howells @ 2016-04-07 20:42 UTC (permalink / raw)
To: Joe Perches; +Cc: dhowells, linux-afs, netdev, linux-kernel
In-Reply-To: <1460060518.1800.8.camel@perches.com>
Joe Perches <joe@perches.com> wrote:
> > Let's see... If the machine panics whilst I'm developing stuff (quite
> > likely if something goes wrong in BH context), how do I get at the
> > function tracing log to find out why it panicked if the log is then
> > lost? With the serial console, at least I automatically capture the
> > output of kenter and co..
>
> But you also don't get a bunch of other useful stuff.
>
> btw: there is ftrace_dump_on_oops
>
> https://lwn.net/Articles/366796/
Cute.
How do I get at the argument values and suchlike that kenter() and co print?
I presume I would need to replace any kenter() or suchlike that printed more
than just the address with a tracing hook?
David
^ permalink raw reply
* Re: [PATCH net-next 0/3] sock: lockdep tightening
From: David Miller @ 2016-04-07 20:44 UTC (permalink / raw)
To: hannes; +Cc: netdev, daniel
In-Reply-To: <1459869016-13896-1-git-send-email-hannes@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 5 Apr 2016 17:10:13 +0200
> First patch is from Eric Dumazet and improves lockdep accuracy for
> socket locks. After that, second patch introduces lockdep_sock_is_held
> and uses it. Final patch reverts and reworks the lockdep fix from Daniel
> in the filter code, as we now have tighter lockdep support.
Series applied, thanks Hannes.
^ permalink raw reply
* Re: [PATCH v2 net-next 00/10] allow bpf attach to tracepoints
From: David Miller @ 2016-04-07 20:46 UTC (permalink / raw)
To: ast
Cc: rostedt, peterz, mingo, daniel, acme, wangnan0, jbacik,
brendan.d.gregg, netdev, linux-kernel, kernel-team
In-Reply-To: <1459993411-2754735-1-git-send-email-ast@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Wed, 6 Apr 2016 18:43:21 -0700
> Hi Steven, Peter,
Steven/Peter, can you give this series a review?
Thanks!
^ permalink raw reply
* Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.
From: David Howells @ 2016-04-07 20:47 UTC (permalink / raw)
To: David Miller; +Cc: dhowells, joe, linux-afs, netdev, linux-kernel
In-Reply-To: <20160407.163616.385449823878901734.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> > Excellent only if I can get at it to find out why the something went wrong.
> > If it's lost because the machine panics, then it is worthless.
>
> If you're ok with these kenter things spewing into the logs with the
> current facility, you can run the function tracer and have it record
> into the logs all the time too.
They don't do that unless you enable them. And I can enable them individually
at compile time or by set at runtime.
> I don't see any argument which is appropriate for keeping this stuff
> around.
Sigh.
As I said to Joe: I don't want to deal with converting to using ftrace at the
moment whilst I'm towards the end of reworking the rewrite of the code. I
have a stack of patches that would need reworking yet again.
David
^ permalink raw reply
* Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.
From: David Miller @ 2016-04-07 20:50 UTC (permalink / raw)
To: dhowells; +Cc: joe, linux-afs, netdev, linux-kernel
In-Reply-To: <5702.1460062039@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Thu, 07 Apr 2016 21:47:19 +0100
> David Miller <davem@davemloft.net> wrote:
>
>> > Excellent only if I can get at it to find out why the something went wrong.
>> > If it's lost because the machine panics, then it is worthless.
>>
>> If you're ok with these kenter things spewing into the logs with the
>> current facility, you can run the function tracer and have it record
>> into the logs all the time too.
>
> They don't do that unless you enable them. And I can enable them individually
> at compile time or by set at runtime.
As you can with the function tracer and tracepoints.
We're not telling you to kill this now, we're just saying that you should
thinking about tossing this custom stuff when you have a chance.
^ permalink raw reply
* Re: [PATCH net-next 0/8] udp: GRO in UDP sockets
From: David Miller @ 2016-04-07 20:54 UTC (permalink / raw)
To: tom; +Cc: netdev, kernel-team
In-Reply-To: <1459869776-2090500-1-git-send-email-tom@herbertland.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 5 Apr 2016 08:22:48 -0700
> This patch set adds GRO functions (gro_receive and gro_complete) to UDP
> sockets and removes udp_offload infrastructure.
>
> Add GRO functions (gro_receive and gro_complete) to UDP sockets. In
> udp_gro_receive and udp_gro_complete a socket lookup is done instead of
> looking up the port number in udp_offloads. If a socket is found and
> there are GRO functions for it then those are called. This feature
> allows binding GRO functions to more than just a port number.
> Eventually, we will be able to use this technique to allow application
> defined GRO for an application protocol by attaching BPF porgrams to UDP
> sockets for doing GRO.
>
> In order to implement these functions, we added exported
> udp6_lib_lookup_skb and udp4_lib_lookup_skb functions in ipv4/udp.c and
> ipv6/udp.c. Also, inet_iif and references to skb_dst() were changed to
> check that dst is set in skbuf before derefencing. In the GRO path there
> is now a UDP socket lookup performed before dst is set, to the get the
> device in that case we simply use skb->dev.
>
> Tested:
>
> Ran various combinations of VXLAN and GUE TCP_STREAM and TCP_RR tests.
> Did not see any material regression.
Series applied thanks Tom.
^ permalink raw reply
* Re: [PATCH v2 net-next 02/10] perf: remove unused __addr variable
From: Peter Zijlstra @ 2016-04-07 20:54 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Steven Rostedt, David S . Miller, Ingo Molnar, Daniel Borkmann,
Arnaldo Carvalho de Melo, Wang Nan, Josef Bacik, Brendan Gregg,
netdev, linux-kernel, kernel-team
In-Reply-To: <1459993411-2754735-3-git-send-email-ast@fb.com>
On Wed, Apr 06, 2016 at 06:43:23PM -0700, Alexei Starovoitov wrote:
> now all calls to perf_trace_buf_submit() pass 0 as 4th
> argument which will be repurposed in the next patch which will
> change the meaning of 1st arg of perf_tp_event() to event_type
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> include/trace/perf.h | 7 ++-----
> include/trace/trace_events.h | 3 ---
> 2 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/include/trace/perf.h b/include/trace/perf.h
> index 26486fcd74ce..6f7e37869065 100644
> --- a/include/trace/perf.h
> +++ b/include/trace/perf.h
> @@ -20,9 +20,6 @@
> #undef __get_bitmask
> #define __get_bitmask(field) (char *)__get_dynamic_array(field)
>
> -#undef __perf_addr
> -#define __perf_addr(a) (__addr = (a))
> -
Ah, we're not using that anylonger..
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
^ permalink raw reply
* Re: [net PATCH v3] GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU
From: David Miller @ 2016-04-07 20:57 UTC (permalink / raw)
To: aduyck; +Cc: jesse, netdev, alexander.duyck, tom
In-Reply-To: <20160405161249.3861.1683.stgit@localhost.localdomain>
From: Alexander Duyck <aduyck@mirantis.com>
Date: Tue, 05 Apr 2016 09:13:39 -0700
> This patch fixes an issue I found in which we were dropping frames if we
> had enabled checksums on GRE headers that were encapsulated by either FOU
> or GUE. Without this patch I was barely able to get 1 Gb/s of throughput.
> With this patch applied I am now at least getting around 6 Gb/s.
>
> The issue is due to the fact that with FOU or GUE applied we do not provide
> a transport offset pointing to the GRE header, nor do we offload it in
> software as the GRE header is completely skipped by GSO and treated like a
> VXLAN or GENEVE type header. As such we need to prevent the stack from
> generating it and also prevent GRE from generating it via any interface we
> create.
>
> Fixes: c3483384ee511 ("gro: Allow tunnel stacking in the case of FOU/GUE")
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
> ---
>
> v3: Basically the same patch as v1 and v2, but I am cutting it loose from
> the IPv4 ID patch as that one will likely need to be resolved in
> net-next.
Applied, thanks Alexander.
^ permalink raw reply
* Re: [PATCH v2 net-next 03/10] perf: split perf_trace_buf_prepare into alloc and update parts
From: Peter Zijlstra @ 2016-04-07 20:58 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Steven Rostedt, David S . Miller, Ingo Molnar, Daniel Borkmann,
Arnaldo Carvalho de Melo, Wang Nan, Josef Bacik, Brendan Gregg,
netdev, linux-kernel, kernel-team
In-Reply-To: <1459993411-2754735-4-git-send-email-ast@fb.com>
On Wed, Apr 06, 2016 at 06:43:24PM -0700, Alexei Starovoitov wrote:
> split allows to move expensive update of 'struct trace_entry' to later phase.
> Repurpose unused 1st argument of perf_tp_event() to indicate event type.
>
> While splitting use temp variable 'rctx' instead of '*rctx' to avoid
> unnecessary loads done by the compiler due to -fno-strict-aliasing
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
^ permalink raw reply
* Re: [PATCH v2 net-next 04/10] perf, bpf: allow bpf programs attach to tracepoints
From: Peter Zijlstra @ 2016-04-07 20:58 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Steven Rostedt, David S . Miller, Ingo Molnar, Daniel Borkmann,
Arnaldo Carvalho de Melo, Wang Nan, Josef Bacik, Brendan Gregg,
netdev, linux-kernel, kernel-team
In-Reply-To: <1459993411-2754735-5-git-send-email-ast@fb.com>
On Wed, Apr 06, 2016 at 06:43:25PM -0700, Alexei Starovoitov wrote:
> introduce BPF_PROG_TYPE_TRACEPOINT program type and allow it to be attached
> to the perf tracepoint handler, which will copy the arguments into
> the per-cpu buffer and pass it to the bpf program as its first argument.
> The layout of the fields can be discovered by doing
> 'cat /sys/kernel/debug/tracing/events/sched/sched_switch/format'
> prior to the compilation of the program with exception that first 8 bytes
> are reserved and not accessible to the program. This area is used to store
> the pointer to 'struct pt_regs' which some of the bpf helpers will use:
> +---------+
> | 8 bytes | hidden 'struct pt_regs *' (inaccessible to bpf program)
> +---------+
> | N bytes | static tracepoint fields defined in tracepoint/format (bpf readonly)
> +---------+
> | dynamic | __dynamic_array bytes of tracepoint (inaccessible to bpf yet)
> +---------+
>
> Not that all of the fields are already dumped to user space via perf ring buffer
> and broken application access it directly without consulting tracepoint/format.
> Same rule applies here: static tracepoint fields should only be accessed
> in a format defined in tracepoint/format. The order of fields and
> field sizes are not an ABI.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] tipc: some small fixes
From: David Miller @ 2016-04-07 21:00 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, paul.gortmaker, tipc-discussion, ying.xue
In-Reply-To: <1460038154-26856-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 7 Apr 2016 10:09:12 -0400
> When fix a minor buffer leak, and ensure that bearers filter packets
> correctly while they are being shut down.
>
> v2: Corrected typos in commit #3, as per feedback from S. Shtylyov
> v3: Removed commit #3 from the series. Improved version will be
> re-submitted later.
Series applied, thanks Jon.
------------------------------------------------------------------------------
^ permalink raw reply
* [net-next:master 194/196] include/net/sock.h:1367:9: error: implicit declaration of function 'lockdep_is_held'
From: kbuild test robot @ 2016-04-07 21:00 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 1fbbe1a8a9b195c4ac856540dfaef49d663c2e91
commit: 1e1d04e678cf72442f57ce82803c7a407769135f [194/196] net: introduce lockdep_is_held and update various places to use it
config: i386-tinyconfig (attached as .config)
reproduce:
git checkout 1e1d04e678cf72442f57ce82803c7a407769135f
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from include/linux/tcp.h:22:0,
from include/linux/ipv6.h:75,
from include/net/ipv6.h:16,
from include/linux/sunrpc/clnt.h:27,
from include/linux/nfs_fs.h:30,
from init/do_mounts.c:32:
include/net/sock.h: In function 'lockdep_sock_is_held':
>> include/net/sock.h:1367:9: error: implicit declaration of function 'lockdep_is_held' [-Werror=implicit-function-declaration]
return lockdep_is_held(&sk->sk_lock) ||
^
init/do_mounts.c: At top level:
include/net/sock.h:1363:13: warning: 'lockdep_sock_is_held' defined but not used [-Wunused-function]
static bool lockdep_sock_is_held(const struct sock *csk)
^
cc1: some warnings being treated as errors
vim +/lockdep_is_held +1367 include/net/sock.h
1361 } while (0)
1362
1363 static bool lockdep_sock_is_held(const struct sock *csk)
1364 {
1365 struct sock *sk = (struct sock *)csk;
1366
> 1367 return lockdep_is_held(&sk->sk_lock) ||
1368 lockdep_is_held(&sk->sk_lock.slock);
1369 }
1370
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 6274 bytes --]
^ permalink raw reply
* Re: [net-next:master 194/196] include/net/sock.h:1367:9: error: implicit declaration of function 'lockdep_is_held'
From: David Miller @ 2016-04-07 21:09 UTC (permalink / raw)
To: fengguang.wu; +Cc: hannes, kbuild-all, netdev
In-Reply-To: <201604080541.jzrX1awl%fengguang.wu@intel.com>
From: kbuild test robot <fengguang.wu@intel.com>
Date: Fri, 8 Apr 2016 05:00:42 +0800
> include/net/sock.h: In function 'lockdep_sock_is_held':
>>> include/net/sock.h:1367:9: error: implicit declaration of function 'lockdep_is_held' [-Werror=implicit-function-declaration]
> return lockdep_is_held(&sk->sk_lock) ||
...
> 1361 } while (0)
> 1362
> 1363 static bool lockdep_sock_is_held(const struct sock *csk)
> 1364 {
> 1365 struct sock *sk = (struct sock *)csk;
> 1366
>> 1367 return lockdep_is_held(&sk->sk_lock) ||
> 1368 lockdep_is_held(&sk->sk_lock.slock);
> 1369 }
Hmmm, Hannes to we need to make this a macro just like lockdep_is_held() is?
^ permalink raw reply
* Re: [RFC PATCH] possible bug in handling of ipv4 route caching
From: Julian Anastasov @ 2016-04-07 21:20 UTC (permalink / raw)
To: Chris Friesen; +Cc: netdev
In-Reply-To: <5706B250.1060303@windriver.com>
Hello,
On Thu, 7 Apr 2016, Chris Friesen wrote:
> Hi,
>
> We think we may have found a bug in the handling of ipv4 route caching,
> and are curious what you think.
>
> For local routes that require a particular output interface we do not
> want to cache the result. Caching the result causes incorrect behaviour
> when there are multiple source addresses on the interface. The end
> result being that if the intended recipient is waiting on that interface
> for the packet he won't receive it because it will be delivered on the
> loopback interface and the IP_PKTINFO ipi_ifindex will be set to the
> loopback interface as well.
So, if we store some orig_oif in rt_iif that
is specific (cached in nexthop) to some device, this
orig_oif should match the device. The only case when
this is violated is when we redirect traffic to lo.
Any attempts to store eth1 in rt_iif for nexthop
cache for lo should be avoided.
> This can be tested by running a program such as "dhcp_release" which
> attempts to inject a packet on a particular interface so that it is
> received by another program on the same board. The receiving process
> should see an IP_PKTINFO ipi_ifndex value of the source interface
> (e.g., eth1) instead of the loopback interface (e.g., lo). The packet
> will still appear on the loopback interface in tcpdump but the important
> aspect is that the CMSG info is correct.
>
> For what it's worth, here's a patch that we've applied locally to deal
> with the issue.
>
> Chris
>
>
>
> Signed-off-by: Allain Legacy <allain.legacy@windriver.com>
> Signed-off-by: Chris Friesen <chris.friesen@windriver.com>
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 02c6229..e965d4b 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -2045,6 +2045,17 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
> */
> if (fi && res->prefixlen < 4)
> fi = NULL;
> + } else if ((type == RTN_LOCAL) && (orig_oif != 0)) {
So, we can be more specific. Can this work?:
} else if ((type == RTN_LOCAL) && (orig_oif != 0) &&
(orig_oif != dev_out->ifindex)) {
I.e. we should allow to cache orig_oif=LOOPBACK_IFINDEX
but eth1 should not be cached.
> + /* For local routes that require a particular output interface
> + * we do not want to cache the result. Caching the result
> + * causes incorrect behaviour when there are multiple source
> + * addresses on the interface, the end result being that if the
> + * intended recipient is waiting on that interface for the
> + * packet he won't receive it because it will be delivered on
> + * the loopback interface and the IP_PKTINFO ipi_ifindex will
> + * be set to the loopback interface as well.
> + */
> + fi = NULL;
> }
>
> fnhe = NULL;
Regards
^ permalink raw reply
* Re: [PATCH 2/9] rxrpc: Disable a debugging statement that has been left enabled.
From: David Howells @ 2016-04-07 21:24 UTC (permalink / raw)
To: David Miller; +Cc: dhowells, joe, linux-afs, netdev, linux-kernel
In-Reply-To: <20160407.165021.1271761992369838408.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> As you can with the function tracer and tracepoints.
I've had experience with tracepoints before (i2c and smbus). It wasn't
particularly fun. There's got to be some easier way to write them.
Hmmm...
Of the _enter() and _leave() macros in my tree at the moment, I have 261 that
record more information than just the name of the function. I presume each
would need to be converted to a TRACE_EVENT*() macro as, as far as I can see
with a cursory examination, the function tracer doesn't record arguments or the
things arguments point to (which I do a lot of). There are also another 84 of
these macros that only record the name of the function which are simpler
propositions.
Add to that 286 _debug(), _net() and _proto() macros, all of which record more
information than just the name of the calling function and don't have anything
particularly to do with function trace.
Now, I have been considering that the _net() and _proto() macros would probably
work well as TRACE_EVENT()-type constructs, allowing the tracing of protocol
flow.
I don't suppose you have a script for automatically converting something like
a printk()-type thing into a TRACE_EVENT()?
David
^ permalink raw reply
* [net-next:master 194/208] include/net/sock.h:1363:13: error: 'lockdep_sock_is_held' defined but not used
From: kbuild test robot @ 2016-04-07 21:34 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 889750bd2e08a94d52a116056d462b3a8e5616a7
commit: 1e1d04e678cf72442f57ce82803c7a407769135f [194/208] net: introduce lockdep_is_held and update various places to use it
config: sparc64-allnoconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1e1d04e678cf72442f57ce82803c7a407769135f
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
In file included from include/linux/tcp.h:22:0,
from include/linux/ipv6.h:75,
from include/net/ipv6.h:16,
from include/linux/sunrpc/clnt.h:27,
from include/linux/nfs_fs.h:30,
from arch/sparc/kernel/sys_sparc32.c:24:
include/net/sock.h: In function 'lockdep_sock_is_held':
include/net/sock.h:1367:2: error: implicit declaration of function 'lockdep_is_held' [-Werror=implicit-function-declaration]
return lockdep_is_held(&sk->sk_lock) ||
^
arch/sparc/kernel/sys_sparc32.c: At top level:
>> include/net/sock.h:1363:13: error: 'lockdep_sock_is_held' defined but not used [-Werror=unused-function]
static bool lockdep_sock_is_held(const struct sock *csk)
^
cc1: all warnings being treated as errors
vim +/lockdep_sock_is_held +1363 include/net/sock.h
1357 sizeof((sk)->sk_lock)); \
1358 lockdep_set_class_and_name(&(sk)->sk_lock.slock, \
1359 (skey), (sname)); \
1360 lockdep_init_map(&(sk)->sk_lock.dep_map, (name), (key), 0); \
1361 } while (0)
1362
> 1363 static bool lockdep_sock_is_held(const struct sock *csk)
1364 {
1365 struct sock *sk = (struct sock *)csk;
1366
> 1367 return lockdep_is_held(&sk->sk_lock) ||
1368 lockdep_is_held(&sk->sk_lock.slock);
1369 }
1370
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 4893 bytes --]
^ permalink raw reply
* Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver
From: Timur Tabi @ 2016-04-07 21:43 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, Gilad Avidov, netdev,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm,
Sagar Dharia, shankerd-sgV2jX0FEOL9JmXXK+q4OQ, Greg Kroah-Hartman,
vikrams-sgV2jX0FEOL9JmXXK+q4OQ, Christopher Covington
In-Reply-To: <20160407201009.GA16136-g2DYL2Zd6BY@public.gmane.org>
Andrew Lunn wrote:
>> I'm back to working on this driver, and I need some more help with
>> how to handle the phy. mdio-gpio.txt doesn't really tell me much.
>> I'm actually working on an ACPI system and not DT.
>
> I can help you with DT, but not ACPI.
>
> The MDIO bus can be a separate Linux device. Since you have GPIO lines
> for the MDIO bus, it makes sense for this to be a mdio-gpio device. So
> in DT, you would have:
>
> mdio0: mdio {
> compatible = "virtual,mdio-gpio";
> #address-cells = <1>;
> #size-cells = <0>;
> gpios = <&qcomgpio 123 0
> &qcomgpio 124 0>;
>
> phy0: ethernet-phy@8 {
> reg = <9>;
> };
> };
>
> Here i've assumed the PHY is using address 8 on the bus. Change as
> needed.
>
> In your MAC DT node, you then have phy-handle pointing to this phy:
>
> emac0: qcom,emac@feb20000 {
> cell-index = <0>;
> compatible = "qcom,emac";
> reg-names = "base", "csr", "ptp", "sgmii";
> reg = <0xfeb20000 0x10000>,
> <0xfeb36000 0x1000>,
> <0xfeb3c000 0x4000>,
> <0xfeb38000 0x400>;
> #address-cells = <0>;
> interrupt-parent = <&emac0>;
> #interrupt-cells = <1>;
> interrupts = <0 1>;
> interrupt-map-mask = <0xffffffff>;
> interrupt-map = <0 &intc 0 76 0
> 1 &intc 0 80 0>;
> interrupt-names = "emac_core0", "sgmii_irq";
> qcom,emac-tstamp-en;
> qcom,emac-ptp-frac-ns-adj = <125000000 1>;
>
> phy-handle = <&phy0>
> }
>
> In the driver, you need to connect the PHY to the MAC. You do this
> using something like:
>
> if (dev->of_node) {
> phy_np = of_parse_phandle(dev->of_node, "phy-handle", 0);
> if (!phy_np) {
> netdev_dbg(ndev, "No phy-handle found in DT\n");
> return -ENODEV;
> }
>
> phy_dev = of_phy_connect(ndev, phy_np, &xxxx_enet_adjust_link,
> 0, pdata->phy_mode);
> if (!phy_dev) {
> netdev_err(ndev, "Could not connect to PHY\n");
> return -ENODEV;
> }
Thank you very much. I'll study this in detail.
> Do you have an ACPI table describing this hardware? What does it look
> like?
So a little background. There are several versions of this driver
floating in Qualcomm, and this is the first serious attempt to upstream
it. I'm trying to reconcile Gilad's driver with the one we use
internally for our ACPI-enabled ARM server platform (the QDF2432).
My goal is to get Gilad's driver accepted upstream with minimal changes
on my part. I will then follow up with several patches that enable ACPI
and our SOC, as well as adding missing parts like ethtool and 1588 support.
On my platform, firmware (UEFI) configures all of the GPIOs. I need to
get confirmation, but it appears that we don't actually make any GPIO
calls at all. I see code that looks like this:
for (i = 0; (!adpt->no_mdio_gpio) && i < EMAC_NUM_GPIO; i++) {
gpio_info = &adpt->gpio_info[i];
retval = of_get_named_gpio(node, gpio_info->name, 0);
if (retval < 0)
return retval;
And on our ACPI system, adpt->no_mdio_gpio is always true:
/* Assume GPIOs required for MDC/MDIO are enabled in firmware */
adpt->no_mdio_gpio = true;
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation collaborative project.
--
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
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