* WICHTIGE MITTEILUNG
From: ines_valdiviezo @ 2018-08-17 11:22 UTC (permalink / raw)
To: Recipients
Lieber Freund,
Ich bin Herr Richard Wahl der Mega-Gewinner von $ 533M In Mega Millions Jackpot spende ich an 5 zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde Ihre E-Mail nach einem Spinball ausgewählt. Ich habe den größten Teil meines Vermögens auf eine Reihe von Wohltätigkeitsorganisationen und Organisationen verteilt. Ich habe mich freiwillig dazu entschieden, Ihnen den Betrag von € 2.000.000,00 zu spenden
eine der ausgewählten 5, um meine Gewinne zu überprüfen, finden Sie auf meiner You Tube Seite unten.
UHR MICH HIER: https://www.youtube.com/watch?v=tne02ExNDrw
Das ist dein Spendencode: [DF00430342018]
Antworten Sie mit dem Spendencode auf diese E-Mail: oceanicfinancialhome@gmail.com
Ich hoffe, Sie und Ihre Familie glücklich zu machen.
Grüße
Herr Richard Wahl
^ permalink raw reply
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Stefan Wahren @ 2018-08-17 18:51 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Eric Dumazet, netdev, Marc Haber, Russell King - ARM Linux,
Peter Robinson, labbott, linux-arm-kernel
In-Reply-To: <adf49ea9-09a3-80f8-8c85-a62d028e21a3@iogearbox.net>
Hi Daniel,
> Daniel Borkmann <daniel@iogearbox.net> hat am 17. August 2018 um 20:30 geschrieben:
>
>
> On 08/17/2018 06:17 PM, Russell King - ARM Linux wrote:
> > On Fri, Aug 17, 2018 at 02:40:19PM +0200, Daniel Borkmann wrote:
> >> I'd have one potential bug suspicion, for the 4.18 one you were trying,
> >> could you run with the below patch to see whether it would help?
> >
> > I think this is almost certainly the problem - looking at the history,
> > it seems that the "-4" was assumed to be part of the scratch stuff in
> > commit 38ca93060163 ("bpf, arm32: save 4 bytes of unneeded stack space")
> > but it isn't - it's because "off" of zero refers to the top word in the
> > stack (iow at STACK_SIZE-4).
>
> Yeah agree, my thinking as well (albeit bit late, sigh, sorry about that).
> Waiting for Peter to get back with results for definite confirmation. Your
> rework in 1c35ba122d4a ("ARM: net: bpf: use negative numbers for stacked
> registers") and 96cced4e774a ("ARM: net: bpf: access eBPF scratch space using
> ARM FP register") fixes this in mainline, so unless I'm missing something this
> would only need a stand-alone fix for 4.18/stable which I can cook up and
> submit then.
i was able to reproduce this issue on RPi 3 with Linux 4.18.1 + multi_v7_defconfig and the following config changes:
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -2,7 +2,10 @@ CONFIG_SYSVIPC=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_CGROUPS=y
+CONFIG_CGROUP_BPF=y
CONFIG_BLK_DEV_INITRD=y
+CONFIG_BPF_SYSCALL=y
+CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
CONFIG_MODULES=y
@@ -153,6 +156,8 @@ CONFIG_IPV6_MIP6=m
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_NET_DSA=m
+CONFIG_BPF_JIT=y
+CONFIG_BPF_STREAM_PARSER=y
CONFIG_CAN=y
CONFIG_CAN_AT91=m
CONFIG_CAN_FLEXCAN=m
After applying the "-4" patch the oopses doesn't appear during boot anymore.
Stefan
>
> Thanks,
> Daniel
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [endianness bug] cxgb4: mk_act_open_req() buggers ->{local,peer}_ip on big-endian hosts
From: Al Viro @ 2018-08-17 15:43 UTC (permalink / raw)
To: Ganesh Goudar; +Cc: Rahul Lakkireddy, David Miller, netdev@vger.kernel.org
In-Reply-To: <20180817130536.GA31768@chelsio.com>
On Fri, Aug 17, 2018 at 06:35:41PM +0530, Ganesh Goudar wrote:
> Thanks, Al. The patch looks good to me but it does not seem
> to be showing up in patchwork, should I resend the patch on
> your behalf to net tree ?
Umm... I thought net-next had been closed until -rc1, hadn't
it?
Anyway, endianness cleanups and fixes of drivers/net/ethernet/chelsio
can be found in vfs.git #net-endian.chelsio; I was planning to post
that stuff on netdev after -rc1, but I would certainly appreciate
a look from somebody familiar with the hardware prior to that, assuming
you have time for that at the moment... The stuff in there (it's
based off net/master):
struct cxgb4_next_header .match_val/.match_mask/mask should be net-endian
cxgb4: fix TC-PEDIT-related parts of cxgb4_tc_flower on big-endian
cxgb4_tc_u32: trivial endianness annotations
cxgb4: trivial endianness annotations
libcxgb: trivial __percpu annotations
libcxgb: trivial endianness annotations
cxgb3: trivial endianness annotations
cxgb3: don't get cute with !! and shifts in t3_prep_adapter()...
[investigate][endianness bug] cxgb3: assigning htonl(11-bit value) to __be16 field is wrong
cxgb: trivial endianness annotations
The first two are fixes (the second being the patch you've just replied to),
next-to-last might or might not be (see "[RFC] weirdness in
cxgb3_main.c:init_tp_parity()" posted to netdev a couple of weeks
ago), the rest is pure annotations. Result is not entirely sparse-clean, but
fairly close to that:
drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:681:67: warning: incorrect type in argument 3 (different base types)
drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:681:67: expected restricted __le32 [usertype] data
drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:681:67: got int
drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:898:31: warning: incorrect type in assignment (different base types)
drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:898:31: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:898:31: got restricted __be32 [usertype] <noident>
drivers/net/ethernet/chelsio/cxgb3/sge.c:2435:43: warning: incorrect type in assignment (different base types)
drivers/net/ethernet/chelsio/cxgb3/sge.c:2435:43: expected restricted __wsum [usertype] csum
drivers/net/ethernet/chelsio/cxgb3/sge.c:2435:43: got restricted __be32 [assigned] [usertype] rss_hi
drivers/net/ethernet/chelsio/cxgb3/sge.c:2436:47: warning: incorrect type in assignment (different base types)
drivers/net/ethernet/chelsio/cxgb3/sge.c:2436:47: expected unsigned int [unsigned] [usertype] priority
drivers/net/ethernet/chelsio/cxgb3/sge.c:2436:47: got restricted __be32 [assigned] [usertype] rss_lo
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c:419:38: warning: incorrect type in assignment (different base types)
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c:419:38: expected restricted __be32 [usertype] mask
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c:419:38: got unsigned int
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c:420:37: warning: incorrect type in assignment (different base types)
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c:420:37: expected restricted __be32 [usertype] val
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c:420:37: got unsigned int
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c:449:22: warning: incorrect type in assignment (different base types)
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c:449:22: expected restricted __be32 [usertype] mask
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c:449:22: got unsigned int
Remaining tc_flower warnings are misannotated tcf_pedit_mask()/tcf_pedit_val()
(both are actually returning __be32)
sge.c ones are
/* Preserve the RSS info in csum & priority */
skb->csum = rss_hi;
skb->priority = rss_lo;
and I've no idea whether it's a problem or not - ->csum is almost
certainly being abused there, and it looks like ->priority also
is... I don't know - it's certainly used as host-endian in the
same driver (see e.g. queue_set() and is_ctrl_pkt()), but those are
on TX path and this is RX... I'm not familiar enough with the
code to tell what's going on here - what *is* the consumer of
the data stored there? cxgb3_offload.c get_hwtid() and get_opcode()?
If so (and if that's all there is), why not simply something like
skb->priority = (ntohl(rss_lo) & 0xffff00) | G_OPCODE(ntohl(rss_hi));
before passing skb to rx_offload(), with
static inline u32 get_hwtid(struct sk_buff *skb)
{
return skb->priority >> 8;
}
static inline u32 get_opcode(struct sk_buff *skb)
{
return skb->priority & 0xff;
}
and don't bother touching ->csum... Again, I'm not familiar with hardware
*or* the driver; I've no idea how much is e.g. shared with the infiniband
or scsi sides of the things (hadn't even looked there). So this one is
up to somebody familiar with the design of that thing.
t3_hw.c: the first one is
return t3_seeprom_write(adapter, EEPROM_STAT_ADDR, enable ? 0xc : 0);
which looks bloody odd, seeing that t3_seeprom_write() expects __le32 as
the last argument and appears to be serious about that -
pci_write_config_dword(adapter->pdev, base + PCI_VPD_DATA,
le32_to_cpu(data));
is where that 0 or 0xc ends up. Might or might not be a bug, but I'd
suggest triggering that sucker on big-endian host and checking whether
it works there...
The second in t3_hw.c... I'd be tempted to make sf1_read() to do
htonl() before storing the result, adjusted the callers (i.e.
if (!(status & htonl(1)))
in flash_wait_op(), no byteswaps in t3_read_flash()) and
had t3_read_flash() do explicit ntohl() on the value read before
storing it in *vers, but that's cosmetical anyway - making it
easier for sparse (and human readers) to keep track of what's
host- and what's net-endian; no real bug there.
Said that, there's another thing worth looking into - uses of __force
in the driver(s). I mean, look at
union {
u32 word;
char byte[4];
} last;
unsigned char *bp;
int i;
if (dir == T4_MEMORY_READ) {
last.word = le32_to_cpu((__force __le32)
t4_read_reg(adap, addr));
for (bp = (unsigned char *)buf, i = off; i < 4; i++)
bp[i] = last.byte[i];
That "__force __le32" crap is a plain and simple result of confusion -
the code clearly intends last.word to be fixed-endian, since it then
proceeds to access individual bytes via aliasing. IOW, this
le32_to_cpu() is a misspelled cpu_to_le32(), and the force-cast
is an attempt to confuse sparse into not noticing the misannotation.
All too successful attempt, at that - the other half
} else {
last.word = *buf;
for (i = off; i < 4; i++)
last.byte[i] = 0;
t4_write_reg(adap, addr,
(__force u32)cpu_to_le32(last.word));
}
also wants last.word fixed-endian, which makes the first assignment
very dubious - buf is a pointer to _byte_, so that makes very little
sense. I very much doubt that this thing (t4_memory_rw_residual())
is correct - e.g. if len = 4n + 2 in "write" t4_memory_rw(), the
first 4n bytes will be fed to hardware and then
* on little-endian hbuf[4n] will be padded with 3 zeroes and
passed to t4_write_reg(), completely ignoring hbuf[4n+1], while
* on big-endian zero will be passed to t4_write_reg(),
completely ignoring both hbuf[4n] and hbuf[4n+1].
Looks rather odd, doesn't it?
It smells like
__le32 v = 0;
memcpy(&v, buf, off);
t4_write_reg(adap, addr, le32_to_cpu(v));
on the write side. And on the read side... Are you sure you want
to copy 4 - off bytes? After all, if it was a *read* for 4n+1 bytes,
we'll copy the first 4n bytes from the hardware, then call that thing
with off = 1. Presumably wanting to copy one more byte, not three...
Should that be
__le32 v = cpu_to_le32(t4_read_reg(adap, addr));
memcpy(buf, &v, off);
instead?
Looking at the callers, I'd say that t4_memory_rw() ought to declare
buf as __le32 *, and have
if (dir == T4_MEMORY_READ)
*buf++ = cpu_to_le32(t4_read_reg(adap,
mem_base + offset));
else
t4_write_reg(adap, mem_base + offset,
le32_to_cpu(*buf++));
offset += sizeof(__le32);
len -= sizeof(__le32);
and to hell with force-casts in there (BTW, where has __be32 come
from in the mainline? It's only in sizeof, but still...).
And cudbg_memory_read() looks somewhat fishy in one more way -
you are doing 64bit host memory stores to pointer that is only
32bit-aligned. Sure, x86 can cope, but what about e.g. sparc64?
And what of the PCIe side of that - what happens if your 64bit
read straddles the aperture window boundary? You only check that
addr is 32bit-aligned, so what happens if you set it 4 bytes
below the window end and ask to read you 8 bytes?
^ permalink raw reply
* Re: [PATCH] net: dsa: add support for ksz9897 ethernet switch
From: Rob Herring @ 2018-08-17 15:09 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Woojung Huh, Microchip Linux Driver Support, Andrew Lunn,
Vivien Didelot, Florian Fainelli, netdev, devicetree,
Lad, Prabhakar
In-Reply-To: <1534348283-12790-1-git-send-email-prabhakar.csengg@gmail.com>
Hi, this email is from Rob's (experimental) review bot. I found a couple
of common problems with your patch. Please see below.
On Wed, 15 Aug 2018 16:51:23 +0100, Lad Prabhakar wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> ksz9477 is superset of ksz9xx series, driver just works
> out of the box for ksz9897 chip with this patch.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
The preferred subject prefix is "dt-bindings: <binding dir>: ...".
> ---
> Documentation/devicetree/bindings/net/dsa/ksz.txt | 4 +++-
> drivers/net/dsa/microchip/ksz_common.c | 9 +++++++++
> drivers/net/dsa/microchip/ksz_spi.c | 1 +
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
DT bindings (including binding headers) should be a separate patch. See
Documentation/devicetree/bindings/submitting-patches.txt.
^ permalink raw reply
* Re: [PATCH iproute2-next] iproute_lwtunnel: allow specifying 'src' for 'encap ip' / 'encap ip6'
From: Stephen Hemminger @ 2018-08-17 15:00 UTC (permalink / raw)
To: Shmulik Ladkani; +Cc: dsahern, netdev, shmulik.ladkani, Shmulik Ladkani
In-Reply-To: <20180817073134.19569-1-shmulik.ladkani@gmail.com>
On Fri, 17 Aug 2018 10:31:34 +0300
Shmulik Ladkani <shmulik@metanetworks.com> wrote:
> This allows the user to specify the LWTUNNEL_IP_SRC/LWTUNNEL_IP6_SRC
> when setting an lwtunnel encapsulation route.
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
> ---
> ip/iproute_lwtunnel.c | 22 ++++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/ip/iproute_lwtunnel.c b/ip/iproute_lwtunnel.c
> index 740da7c6..20d5545c 100644
> --- a/ip/iproute_lwtunnel.c
> +++ b/ip/iproute_lwtunnel.c
> @@ -671,7 +671,7 @@ static int parse_encap_mpls(struct rtattr *rta, size_t len,
> static int parse_encap_ip(struct rtattr *rta, size_t len,
> int *argcp, char ***argvp)
> {
> - int id_ok = 0, dst_ok = 0, tos_ok = 0, ttl_ok = 0;
> + int id_ok = 0, dst_ok = 0, src_ok = 0, tos_ok = 0, ttl_ok = 0;
> char **argv = *argvp;
> int argc = *argcp;
>
> @@ -694,6 +694,15 @@ static int parse_encap_ip(struct rtattr *rta, size_t len,
> get_addr(&addr, *argv, AF_INET);
> rta_addattr_l(rta, len, LWTUNNEL_IP_DST,
> &addr.data, addr.bytelen);
> + } else if (strcmp(*argv, "src") == 0) {
> + inet_prefix addr;
> +
> + NEXT_ARG();
> + if (src_ok++)
> + duparg2("src", *argv);
> + get_addr(&addr, *argv, AF_INET);
> + rta_addattr_l(rta, len, LWTUNNEL_IP_SRC,
> + &addr.data, addr.bytelen);
> } else if (strcmp(*argv, "tos") == 0) {
> __u32 tos;
>
> @@ -805,7 +814,7 @@ static int parse_encap_ila(struct rtattr *rta, size_t len,
> static int parse_encap_ip6(struct rtattr *rta, size_t len,
> int *argcp, char ***argvp)
> {
> - int id_ok = 0, dst_ok = 0, tos_ok = 0, ttl_ok = 0;
> + int id_ok = 0, dst_ok = 0, src_ok = 0, tos_ok = 0, ttl_ok = 0;
> char **argv = *argvp;
> int argc = *argcp;
>
> @@ -828,6 +837,15 @@ static int parse_encap_ip6(struct rtattr *rta, size_t len,
> get_addr(&addr, *argv, AF_INET6);
> rta_addattr_l(rta, len, LWTUNNEL_IP6_DST,
> &addr.data, addr.bytelen);
> + } else if (strcmp(*argv, "src") == 0) {
> + inet_prefix addr;
> +
> + NEXT_ARG();
> + if (src_ok++)
> + duparg2("src", *argv);
> + get_addr(&addr, *argv, AF_INET6);
> + rta_addattr_l(rta, len, LWTUNNEL_IP6_SRC,
> + &addr.data, addr.bytelen);
> } else if (strcmp(*argv, "tc") == 0) {
> __u32 tc;
>
If you accept an attribute on input you need to parse it and display it the
same way in the show command.
^ permalink raw reply
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Peter Robinson @ 2018-08-17 14:32 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Russell King - ARM Linux, Marc Haber, linux-arm-kernel, netdev,
labbott, Eric Dumazet
In-Reply-To: <1c2218cb-63bf-1528-6156-8ce93f46169c@iogearbox.net>
On Fri, Aug 17, 2018 at 1:40 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 08/17/2018 02:25 PM, Peter Robinson wrote:
>> On Thu, Aug 16, 2018 at 11:58 PM, Russell King - ARM Linux
>> <linux@armlinux.org.uk> wrote:
>>> On Thu, Aug 16, 2018 at 10:35:16PM +0200, Marc Haber wrote:
>>>> On Mon, Jun 25, 2018 at 05:41:27PM +0100, Peter Robinson wrote:
>>>>> So with that and the other fix there was no improvement, with those
>>>>> and the BPF JIT disabled it works, I'm not sure if the two patches
>>>>> have any effect with the JIT disabled though.
>>>>
>>>> I can confirm the crash with the released 4.18.1 on Banana Pi, and I can
>>>> also confirm that disabling BPF JIT makes the Banana Pi work again.,
>>>
>>> I'm afraid that the information in the crash dumps is insufficient
>>> to be able to work very much out about these crashes.
>>>
>>> We need a recipe (kernel configuration and what userspace is doing)
>>> so that it's possible to recreate the crash, or we need responses
>>> to requests for information - I requested the disassembly of
>>> sk_filter_trim_cap and the BPF code dump via setting a sysctl back
>>> in early July. Without this, as I say, I don't see how this problem
>>> can be progressed.
>>
>> I can provide a kernel config [1] but I've not had enough time to sit
>> down and get the rest of the stuff and debug it due to a combination
>> of travel and other priorities.
>
> Did you get a chance to try latest kernel from Linus' tree [1] from last
> few days to see whether the issue is still persistent? There have been
> a number of improvements, bit strange why e.g. Russell didn't run into
> it while others have, hmm. Perhaps due to EABI vs non EABI.
I haven't had a chance to try anything from the 4.19 merge window as
yet, I'm traveling this week so it was on the list for next week to
try.
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
>>> If the problem is at boot, one way to set the sysctl would be to
>>> hack the kernel and explicitly initialise the sysctl to '2', or
>>> boot with init=/bin/sh, then manually mount /proc, set the sysctl,
>>> and then "exec /sbin/init" from that shell. (Remember there's no
>>> job control in that shell, so ^z, ^c, etc do not work.)
>>
>> It starts to happen in the early kernel boot long before we get to any
>> userspace across a number of ARMv7 devices (RPi2/3, BeagleBone and
>> AllWinner H3 based devices at least).
>>
>> [1] https://pbrobinson.fedorapeople.org/kernel-armv7hl.config
>
> I'd have one potential bug suspicion, for the 4.18 one you were trying,
> could you run with the below patch to see whether it would help?
I will try and get someone to test that today, thanks
> Thanks,
> Daniel
>
> diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
> index f6a62ae..c864f6b 100644
> --- a/arch/arm/net/bpf_jit_32.c
> +++ b/arch/arm/net/bpf_jit_32.c
> @@ -238,7 +238,7 @@ static void jit_fill_hole(void *area, unsigned int size)
> #define STACK_SIZE ALIGN(_STACK_SIZE, STACK_ALIGNMENT)
>
> /* Get the offset of eBPF REGISTERs stored on scratch space. */
> -#define STACK_VAR(off) (STACK_SIZE - off)
> +#define STACK_VAR(off) (STACK_SIZE - off - 4)
>
> #if __LINUX_ARM_ARCH__ < 7
>
^ permalink raw reply
* Re: [GIT PULL] 9p updates for 4.19
From: Linus Torvalds @ 2018-08-17 16:37 UTC (permalink / raw)
To: Dominique Martinet
Cc: V9FS Developers, Linux Kernel Mailing List, Network Development
In-Reply-To: <20180817023307.GA32726@nautica>
So this pull request confuses me, and that's not a good thing.
On Thu, Aug 16, 2018 at 7:33 PM Dominique Martinet
<asmadeus@codewreck.org> wrote:
>
> Pull request for inclusion in 4.19 for 9p
So when I pull the tag, I get a different message, talking about
This tag is the same as 9p-for-4.19 without the two MAINTAINERS patches
but I never saw a first version.
And it comes from a github address, with a pgp key that I've not seen
before, and without me having been told about said maintainership
updates. And while the key has a lot of signatures, none of them are
any that I have recognized previously from kernel development.
I'm sure it's all ok, but honestly, there's no way I can pull this
without a bit more clarification.
Linus
^ permalink raw reply
* Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API
From: Boris Brezillon @ 2018-08-17 16:27 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Marek Vasut, Richard Weinberger, Grygorii Strashko,
David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter,
Florian Fainelli
In-Reply-To: <20180810080526.27207-7-brgl@bgdev.pl>
Hi Bartosz,
On Fri, 10 Aug 2018 10:05:03 +0200
Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Alban Bedel <albeu@free.fr>
>
> Allow drivers that use the nvmem API to read data stored on MTD devices.
> For this the mtd devices are registered as read-only NVMEM providers.
>
> Signed-off-by: Alban Bedel <albeu@free.fr>
> [Bartosz:
> - use the managed variant of nvmem_register(),
> - set the nvmem name]
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
What happened to the 2 other patches of Alban's series? I'd really like
the DT case to be handled/agreed on in the same patchset, but IIRC,
Alban and Srinivas disagreed on how this should be represented. I
hope this time we'll come to an agreement, because the MTD <-> NVMEM
glue has been floating around for quite some time...
Regards,
Boris
> ---
> drivers/mtd/Kconfig | 1 +
> drivers/mtd/mtdcore.c | 50 +++++++++++++++++++++++++++++++++++++++++
> include/linux/mtd/mtd.h | 2 ++
> 3 files changed, 53 insertions(+)
>
> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> index 46ab7feec6b6..f5549482d0df 100644
> --- a/drivers/mtd/Kconfig
> +++ b/drivers/mtd/Kconfig
> @@ -1,5 +1,6 @@
> menuconfig MTD
> tristate "Memory Technology Device (MTD) support"
> + imply NVMEM
> help
> Memory Technology Devices are flash, RAM and similar chips, often
> used for solid state file systems on embedded devices. This option
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 42395df06be9..a57302eaceb5 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -488,6 +488,49 @@ int mtd_pairing_groups(struct mtd_info *mtd)
> }
> EXPORT_SYMBOL_GPL(mtd_pairing_groups);
>
> +static int mtd_nvmem_reg_read(void *priv, unsigned int offset,
> + void *val, size_t bytes)
> +{
> + struct mtd_info *mtd = priv;
> + size_t retlen;
> + int err;
> +
> + err = mtd_read(mtd, offset, bytes, &retlen, val);
> + if (err && err != -EUCLEAN)
> + return err;
> +
> + return retlen == bytes ? 0 : -EIO;
> +}
> +
> +static int mtd_nvmem_add(struct mtd_info *mtd)
> +{
> + struct nvmem_config config = { };
> +
> + config.dev = &mtd->dev;
> + config.owner = THIS_MODULE;
> + config.name = mtd->name;
> + config.reg_read = mtd_nvmem_reg_read;
> + config.size = mtd->size;
> + config.word_size = 1;
> + config.stride = 1;
> + config.read_only = true;
> + config.root_only = true;
> + config.priv = mtd;
> +
> + mtd->nvmem = devm_nvmem_register(&mtd->dev, &config);
> + if (IS_ERR(mtd->nvmem)) {
> + /* Just ignore if there is no NVMEM support in the kernel */
> + if (PTR_ERR(mtd->nvmem) == -ENOSYS) {
> + mtd->nvmem = NULL;
> + } else {
> + dev_err(&mtd->dev, "Failed to register NVMEM device\n");
> + return PTR_ERR(mtd->nvmem);
> + }
> + }
> +
> + return 0;
> +}
> +
> static struct dentry *dfs_dir_mtd;
>
> /**
> @@ -570,6 +613,11 @@ int add_mtd_device(struct mtd_info *mtd)
> if (error)
> goto fail_added;
>
> + /* Add the nvmem provider */
> + error = mtd_nvmem_add(mtd);
> + if (error)
> + goto fail_nvmem_add;
> +
> if (!IS_ERR_OR_NULL(dfs_dir_mtd)) {
> mtd->dbg.dfs_dir = debugfs_create_dir(dev_name(&mtd->dev), dfs_dir_mtd);
> if (IS_ERR_OR_NULL(mtd->dbg.dfs_dir)) {
> @@ -595,6 +643,8 @@ int add_mtd_device(struct mtd_info *mtd)
> __module_get(THIS_MODULE);
> return 0;
>
> +fail_nvmem_add:
> + device_unregister(&mtd->dev);
> fail_added:
> of_node_put(mtd_get_of_node(mtd));
> idr_remove(&mtd_idr, i);
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index a86c4fa93115..8121c6582285 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -25,6 +25,7 @@
> #include <linux/notifier.h>
> #include <linux/device.h>
> #include <linux/of.h>
> +#include <linux/nvmem-provider.h>
>
> #include <mtd/mtd-abi.h>
>
> @@ -339,6 +340,7 @@ struct mtd_info {
> struct device dev;
> int usecount;
> struct mtd_debug_info dbg;
> + struct nvmem_device *nvmem;
> };
>
> int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
^ permalink raw reply
* Re: mv88e6xxx: question: can switch irq be shared?
From: Andrew Lunn @ 2018-08-17 13:22 UTC (permalink / raw)
To: Marek Behún; +Cc: netdev
In-Reply-To: <20180817093055.3107-1-marek.behun@nic.cz>
On Fri, Aug 17, 2018 at 11:30:55AM +0200, Marek Behún wrote:
> Hello, I am wondering if the main device irq in
> dsa/mv88e6xxx/chip.c can be requested as shared (see patch below).
This probably works O.K, but its not something anybody else has
done. So there could be some hidden issues.
Andrew
^ permalink raw reply
* Re: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
From: Richard Cochran @ 2018-08-17 16:25 UTC (permalink / raw)
To: Bryan.Whitehead
Cc: arnd, UNGLinuxDriver, davem, yuehaibing, netdev, linux-kernel
In-Reply-To: <90A7E81AE28BAE4CBDDB3B35F187D2644073EA3B@CHN-SV-EXMX02.mchp-main.com>
On Wed, Aug 15, 2018 at 08:50:03PM +0000, Bryan.Whitehead@microchip.com wrote:
> Sounds reasonable to me. I will yield to Richard's insight.
> But it would be nice if requirements like these were documented.
I think the only reason for initializing to the system UTC (as most
drivers do) is historical. The first Intel driver was simply copied.
I've been thinking recently that we should standardize this. I'm open
for suggestions on how to do this. Remember that the system time is
likely wrong at driver initialization time.
Thanks,
Richard
^ permalink raw reply
* [PATCH ethtool] ethtool: document WoL filters option also in help message
From: Michal Kubecek @ 2018-08-17 13:21 UTC (permalink / raw)
To: John W. Linville; +Cc: Florian Fainelli, netdev
Commit eff0bb337223 ("ethtool: Add support for WAKE_FILTER (WoL using
filters)") added option "f" for wake on lan and documented it in man page
but not in the output of "ethtool --help".
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ethtool.c b/ethtool.c
index aa2bbe9e4c65..e8b7703293d2 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -5069,7 +5069,7 @@ static const struct option {
" [ advertise %x ]\n"
" [ phyad %d ]\n"
" [ xcvr internal|external ]\n"
- " [ wol p|u|m|b|a|g|s|d... ]\n"
+ " [ wol p|u|m|b|a|g|s|f|d... ]\n"
" [ sopass %x:%x:%x:%x:%x:%x ]\n"
" [ msglvl %d | msglvl type on|off ... ]\n" },
{ "-a|--show-pause", 1, do_gpause, "Show pause options" },
--
2.18.0
^ permalink raw reply related
* Re: [endianness bug] cxgb4: mk_act_open_req() buggers ->{local,peer}_ip on big-endian hosts
From: Ganesh Goudar @ 2018-08-17 13:05 UTC (permalink / raw)
To: Al Viro; +Cc: Rahul Lakkireddy, David Miller, netdev@vger.kernel.org
In-Reply-To: <20180814212524.GT6515@ZenIV.linux.org.uk>
Thanks, Al. The patch looks good to me but it does not seem
to be showing up in patchwork, should I resend the patch on
your behalf to net tree ?
Ganesh
^ permalink raw reply
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Daniel Borkmann @ 2018-08-17 12:40 UTC (permalink / raw)
To: Peter Robinson, Russell King - ARM Linux
Cc: Marc Haber, linux-arm-kernel, netdev, labbott, Eric Dumazet
In-Reply-To: <CALeDE9Pm7nsqDFL0m0ZsNdnEti6YAbEPhtfbNMPe=UZCUyyHMA@mail.gmail.com>
On 08/17/2018 02:25 PM, Peter Robinson wrote:
> On Thu, Aug 16, 2018 at 11:58 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
>> On Thu, Aug 16, 2018 at 10:35:16PM +0200, Marc Haber wrote:
>>> On Mon, Jun 25, 2018 at 05:41:27PM +0100, Peter Robinson wrote:
>>>> So with that and the other fix there was no improvement, with those
>>>> and the BPF JIT disabled it works, I'm not sure if the two patches
>>>> have any effect with the JIT disabled though.
>>>
>>> I can confirm the crash with the released 4.18.1 on Banana Pi, and I can
>>> also confirm that disabling BPF JIT makes the Banana Pi work again.,
>>
>> I'm afraid that the information in the crash dumps is insufficient
>> to be able to work very much out about these crashes.
>>
>> We need a recipe (kernel configuration and what userspace is doing)
>> so that it's possible to recreate the crash, or we need responses
>> to requests for information - I requested the disassembly of
>> sk_filter_trim_cap and the BPF code dump via setting a sysctl back
>> in early July. Without this, as I say, I don't see how this problem
>> can be progressed.
>
> I can provide a kernel config [1] but I've not had enough time to sit
> down and get the rest of the stuff and debug it due to a combination
> of travel and other priorities.
Did you get a chance to try latest kernel from Linus' tree [1] from last
few days to see whether the issue is still persistent? There have been
a number of improvements, bit strange why e.g. Russell didn't run into
it while others have, hmm. Perhaps due to EABI vs non EABI.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> If the problem is at boot, one way to set the sysctl would be to
>> hack the kernel and explicitly initialise the sysctl to '2', or
>> boot with init=/bin/sh, then manually mount /proc, set the sysctl,
>> and then "exec /sbin/init" from that shell. (Remember there's no
>> job control in that shell, so ^z, ^c, etc do not work.)
>
> It starts to happen in the early kernel boot long before we get to any
> userspace across a number of ARMv7 devices (RPi2/3, BeagleBone and
> AllWinner H3 based devices at least).
>
> [1] https://pbrobinson.fedorapeople.org/kernel-armv7hl.config
I'd have one potential bug suspicion, for the 4.18 one you were trying,
could you run with the below patch to see whether it would help?
Thanks,
Daniel
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index f6a62ae..c864f6b 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -238,7 +238,7 @@ static void jit_fill_hole(void *area, unsigned int size)
#define STACK_SIZE ALIGN(_STACK_SIZE, STACK_ALIGNMENT)
/* Get the offset of eBPF REGISTERs stored on scratch space. */
-#define STACK_VAR(off) (STACK_SIZE - off)
+#define STACK_VAR(off) (STACK_SIZE - off - 4)
#if __LINUX_ARM_ARCH__ < 7
^ permalink raw reply related
* [PATCH]ipv6: multicast: In mld_send_cr function moving read lock to second for loop
From: Guruswamy Basavaiah @ 2018-08-17 12:31 UTC (permalink / raw)
To: netdev, davem, Alexey Kuznetsov, Hideaki YOSHIFUJI
In-Reply-To: <CAHSpA58KdjMLnnGdbyDbASJLFuf2BHLsADBuO1jeT_1uFp9GUA@mail.gmail.com>
In function mld_send_cr, the first loop is already protected by
idev->mc_lock, it dont need idev->lock read lock, hence moving it
only to second for loop.
Signed-off-by: Guruswamy Basavaiah <guru2018@gmail.com>
---
net/ipv6/mcast.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index d64ee7e..d8e7e15 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1860,7 +1860,6 @@ static void mld_send_cr(struct inet6_dev *idev)
struct sk_buff *skb = NULL;
int type, dtype;
- read_lock_bh(&idev->lock);
spin_lock(&idev->mc_lock);
/* deleted MCA's */
@@ -1897,6 +1896,7 @@ static void mld_send_cr(struct inet6_dev *idev)
}
spin_unlock(&idev->mc_lock);
+ read_lock_bh(&idev->lock);
/* change recs */
for (pmc = idev->mc_list; pmc; pmc = pmc->next) {
spin_lock_bh(&pmc->mca_lock);
--
2.9.5
^ permalink raw reply related
* Re: [PATCH 2/2] ethernet: lpc_eth: Use NULL to compare with pointer-typed value rather than 0
From: Vladimir Zapolskiy @ 2018-08-17 15:29 UTC (permalink / raw)
To: zhong jiang, davem; +Cc: slemieux.tyco, keescook, netdev, linux-kernel
In-Reply-To: <1534511933-39236-3-git-send-email-zhongjiang@huawei.com>
Hi zhong jiang,
On 08/17/2018 04:18 PM, zhong jiang wrote:
> We should use NULL to compare with pointer-typed value rather than 0.
> The issue is detected with the help of Coccinelle.
> ---
> drivers/net/ethernet/nxp/lpc_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
> index 08381ef..04d9e62 100644
> --- a/drivers/net/ethernet/nxp/lpc_eth.c
> +++ b/drivers/net/ethernet/nxp/lpc_eth.c
> @@ -1350,7 +1350,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
> "IRAM not big enough for net buffers, using SDRAM instead.\n");
> }
>
> - if (pldat->dma_buff_base_v == 0) {
> + if (pldat->dma_buff_base_v == NULL) {
That's a valid finding, but please use a common 0 and NULL comparison in form of
if (!pldat->dma_buff_base_v)
To the change above please feel free to add my
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
> ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> if (ret)
> goto err_out_free_irq;
>
^ permalink raw reply
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Peter Robinson @ 2018-08-17 12:25 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Marc Haber, linux-arm-kernel, netdev, labbott, Eric Dumazet,
Daniel Borkmann
In-Reply-To: <20180816225844.GW30658@n2100.armlinux.org.uk>
On Thu, Aug 16, 2018 at 11:58 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Aug 16, 2018 at 10:35:16PM +0200, Marc Haber wrote:
>> On Mon, Jun 25, 2018 at 05:41:27PM +0100, Peter Robinson wrote:
>> > So with that and the other fix there was no improvement, with those
>> > and the BPF JIT disabled it works, I'm not sure if the two patches
>> > have any effect with the JIT disabled though.
>>
>> I can confirm the crash with the released 4.18.1 on Banana Pi, and I can
>> also confirm that disabling BPF JIT makes the Banana Pi work again.,
>
> Hi,
>
> I'm afraid that the information in the crash dumps is insufficient
> to be able to work very much out about these crashes.
>
> We need a recipe (kernel configuration and what userspace is doing)
> so that it's possible to recreate the crash, or we need responses
> to requests for information - I requested the disassembly of
> sk_filter_trim_cap and the BPF code dump via setting a sysctl back
> in early July. Without this, as I say, I don't see how this problem
> can be progressed.
I can provide a kernel config [1] but I've not had enough time to sit
down and get the rest of the stuff and debug it due to a combination
of travel and other priorities.
> If the problem is at boot, one way to set the sysctl would be to
> hack the kernel and explicitly initialise the sysctl to '2', or
> boot with init=/bin/sh, then manually mount /proc, set the sysctl,
> and then "exec /sbin/init" from that shell. (Remember there's no
> job control in that shell, so ^z, ^c, etc do not work.)
It starts to happen in the early kernel boot long before we get to any
userspace across a number of ARMv7 devices (RPi2/3, BeagleBone and
AllWinner H3 based devices at least).
[1] https://pbrobinson.fedorapeople.org/kernel-armv7hl.config
^ permalink raw reply
* Re: [PATCH 1/1] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Dan Carpenter @ 2018-08-17 12:06 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Kees Cook, Security Officers, Kevin Deus, Samuel Ortiz,
David S. Miller, Allen Pais, linux-wireless, Network Development,
LKML
In-Reply-To: <CAJuCfpH9n2vVjBF7RoMNng3T=URY1eusKfbVGyq44LWcjwNTPw@mail.gmail.com>
On Wed, Aug 15, 2018 at 09:40:13AM -0700, Suren Baghdasaryan wrote:
> On Wed, Aug 15, 2018 at 1:29 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > On Tue, Aug 14, 2018 at 03:38:14PM -0700, Suren Baghdasaryan wrote:
> >> The separate fix for the size of pipes[] array is posted here:
> >> https://lkml.org/lkml/2018/8/14/1034
> >> Thanks!
> >>
> >
> > That's great! Let's add some bounds checking to nfc_hci_msg_rx_work()
> > and nfc_hci_recv_from_llc() as well and then we can close the chapter on
> > these bugs.
>
> Dan, I don't think we need additional checks there. Here are the
> relevant parts of the code in nfc_hci_recv_from_llc():
>
Sorry, I meant after that at the end of the function:
net/nfc/hci/core.c
902 /* if this is a response, dispatch immediately to
903 * unblock waiting cmd context. Otherwise, enqueue to dispatch
904 * in separate context where handler can also execute command.
905 */
906 packet = (struct hcp_packet *)hcp_skb->data;
907 type = HCP_MSG_GET_TYPE(packet->message.header);
908 if (type == NFC_HCI_HCP_RESPONSE) {
909 pipe = packet->header;
^^^^^^^^^^^^^^^^^^^^^
Pipe can go up to 255.
910 instruction = HCP_MSG_GET_CMD(packet->message.header);
911 skb_pull(hcp_skb, NFC_HCI_HCP_PACKET_HEADER_LEN +
912 NFC_HCI_HCP_MESSAGE_HEADER_LEN);
913 nfc_hci_hcp_message_rx(hdev, pipe, type, instruction, hcp_skb);
^^^^
Then inside the nfc_hci_hcp_message_rx() function we call
nfc_hci_cmd_received() and nfc_hci_event_received() which use it as an
array index.
914 } else {
915 skb_queue_tail(&hdev->msg_rx_queue, hcp_skb);
916 schedule_work(&hdev->msg_rx_work);
917 }
918 }
It's the same thing when nfc_hci_hcp_message_rx() is called from
nfc_hci_msg_rx_work():
138 static void nfc_hci_msg_rx_work(struct work_struct *work)
139 {
140 struct nfc_hci_dev *hdev = container_of(work, struct nfc_hci_dev,
141 msg_rx_work);
142 struct sk_buff *skb;
143 struct hcp_message *message;
144 u8 pipe;
145 u8 type;
146 u8 instruction;
147
148 while ((skb = skb_dequeue(&hdev->msg_rx_queue)) != NULL) {
149 pipe = skb->data[0];
^^^^^^^^^^^^^^^^^^^
150 skb_pull(skb, NFC_HCI_HCP_PACKET_HEADER_LEN);
151 message = (struct hcp_message *)skb->data;
152 type = HCP_MSG_GET_TYPE(message->header);
153 instruction = HCP_MSG_GET_CMD(message->header);
154 skb_pull(skb, NFC_HCI_HCP_MESSAGE_HEADER_LEN);
155
156 nfc_hci_hcp_message_rx(hdev, pipe, type, instruction, skb);
^^^^
157 }
158 }
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/1] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Dan Carpenter @ 2018-08-17 14:47 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Kees Cook, Security Officers, Kevin Deus, Samuel Ortiz,
David S. Miller, Allen Pais, linux-wireless, Network Development,
LKML
In-Reply-To: <20180817120650.6mx6icxif2o52qyx@mwanda>
Never mind. This code is a bit subtle for static analysis so those
warnings are false positives. Thanks for taking a look at this, Suren.
regards,
dan carpenter
^ permalink raw reply
* Re: ANNOUNCE: pahole v1.12 (BTF edition)
From: Arnaldo Carvalho de Melo @ 2018-08-17 14:38 UTC (permalink / raw)
To: Jan Engelhardt
Cc: dwarves, Dodji Seketeli,
Linux Networking Development Mailing List,
Linux Kernel Mailing List
In-Reply-To: <nycvar.YFH.7.76.1808162328040.2839@n3.vanv.qr>
Em Thu, Aug 16, 2018 at 11:49:38PM +0200, Jan Engelhardt escreveu:
> On Thursday 2018-08-16 22:09, Arnaldo Carvalho de Melo wrote:
>
> > After a long time without announces, here is pahole 1.12,
> >available at:
> >
> > https://fedorapeople.org/~acme/dwarves/dwarves-1.12.tar.bz2
> >
> > git://git.kernel.org/pub/scm/devel/pahole/pahole.git
> >
> > Some distros haven't picked 1.11, that comes with several
> >goodies, my bad for not having announced it at that time more widely,
>
> Missing announcements can be forgiven. But there are automatic tools
> that scrape the web for updates (usually something tries to scan
> the enclosing directory of the last known URL), so uploads are
> essential.
> Since 1.11 was never uploaded, it did not find its way..
> (One had to grab a tarball gitweb generated from the tag,
> but had to know there was a 1.11, too).
>
>
> Can we have signatures for the release tarballs?
> (Only if you think it's worth having.)
Yeah, I think I can create a file with sha256 for the tarball and sign
it, just like I signed the v1.12 tag:
https://git.kernel.org/pub/scm/devel/pahole/pahole.git/tag/?h=v1.12
> >Please report any problems to me, I'll try and get problems fixed.
>
> Here's one (or six):
Yeah, C++ has been a second class citizen for all pahole's life, with
progress being made mostly when I collaborate with folks at the ATLAS
project at CERN that had tons of C++ code being ported from 32-bit based
clusters to 64-bit ones.
I'll try to work some time on the reports below to see if we get a bit
more progress there.
> $ cat x.cpp
> #include <utility>
> struct F {
> template<typename T, typename... A> F(T &, T &&, A &&...x) { }
> F clone() const && { int q; return F(q, 3, 4); }
> int xpub() { return xprot(); }
> protected:
> int xprot() { return xpriv(); }
> private:
> int xpriv() { return 0; }
> };
> int z;
> F f(z,2,3,4);
> int main()
> {
> f.xpub();
> std::move(f).clone();
> }
>
>
> $ g++-7 x.cpp -c -ggdb3 -Wall && pahole x.o
> die__process_function: tag not supported 0x2f (template_type_parameter)!
> //expected: handle type
> die__process_function: tag not supported 0x4107 (GNU_template_parameter_pack)!
> //expected: handle type
> die__process_function: tag not supported 0x4108 (GNU_formal_parameter_pack)!
> //expected: handle type
> ftype__recode_dwarf_types: couldn't find 0x321 abstract_origin for 0x397 (formal_parameter)!
> //expected: handle type
> ftype__recode_dwarf_types: couldn't find 0x326 abstract_origin for 0x39f (formal_parameter)!
> ftype__recode_dwarf_types: couldn't find 0x3e0 abstract_origin for 0x447 (formal_parameter)!
> struct F {
> class F clone(const class F *);
> //expected: "struct F clone(const struct F *&&);"
>
> int xpub(class F *);
>
> protected:
>
> int xprot(class F *);
>
> private:
>
> int xpriv(class F *);
>
> //expected: "public:"
>
> void F<int, int, int>(class F *, int &, , , );
> //expected: "void F<int, int, int>(struct F *, int &, int &&, int &&, int &&);
>
> void F<int, int>(class F *, int &, , );
> //expected: "void F<int, int, int>(struct F *, int &, int &&, int &&);
>
> /* size: 1, cachelines: 0, members: 0 */
> /* last cacheline: 1 bytes */
> };
^ permalink raw reply
* [PATCH] dt-bindings: can: rcar_can: Add r8a774a1 support
From: Fabrizio Castro @ 2018-08-17 14:38 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, David S. Miller, linux-can, netdev, devicetree,
Simon Horman, Geert Uytterhoeven, Chris Paterson, Biju Das,
linux-renesas-soc, linux-kernel
Document RZ/G2M (r8a774a1) SoC bindings.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
This patch applies on top of next-20180817
Documentation/devicetree/bindings/net/can/rcar_can.txt | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 94a7f33..84afc78 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -4,6 +4,7 @@ Renesas R-Car CAN controller Device Tree Bindings
Required properties:
- compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
"renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
+ "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC.
"renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
"renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
"renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC.
@@ -16,7 +17,8 @@ Required properties:
"renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
"renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
compatible device.
- "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
+ "renesas,rcar-gen3-can" for a generic R-Car Gen3 or RZ/G2
+ compatible device.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first
followed by the generic version.
@@ -24,7 +26,9 @@ Required properties:
- reg: physical base address and size of the R-Car CAN register map.
- interrupts: interrupt specifier for the sole interrupt.
- clocks: phandles and clock specifiers for 3 CAN clock inputs.
-- clock-names: 3 clock input name strings: "clkp1", "clkp2", "can_clk".
+- clock-names: 2 clock input name strings for RZ/G2: "clkp1", "can_clk", and
+ 3 clock input name strings for every other SoC: "clkp1", "clkp2",
+ "can_clk".
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must be "default".
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/2] net/sched: Add hardware specific counters to TC actions
From: Jakub Kicinski @ 2018-08-17 11:27 UTC (permalink / raw)
To: Eelco Chaudron
Cc: David Miller, netdev, jhs, xiyou.wangcong, jiri, simon.horman,
Marcelo Ricardo Leitner
In-Reply-To: <4E288F34-0559-4C8A-8B3B-4410364791AA@redhat.com>
On Thu, 16 Aug 2018 14:02:44 +0200, Eelco Chaudron wrote:
> On 11 Aug 2018, at 21:06, David Miller wrote:
>
> > From: Jakub Kicinski <jakub.kicinski@netronome.com>
> > Date: Thu, 9 Aug 2018 20:26:08 -0700
> >
> >> It is not immediately clear why this is needed. The memory and
> >> updating two sets of counters won't come for free, so perhaps a
> >> stronger justification than troubleshooting is due? :S
> >>
> >> Netdev has counters for fallback vs forwarded traffic, so you'd know
> >> that traffic hits the SW datapath, plus the rules which are in_hw
> >> will
> >> most likely not match as of today for flower (assuming correctness).
>
> I strongly believe that these counters are a requirement for a mixed
> software/hardware (flow) based forwarding environment. The global
> counters will not help much here as you might have chosen to have
> certain traffic forwarded by software.
>
> These counters are probably the only option you have to figure out why
> forwarding is not as fast as expected, and you want to blame the TC
> offload NIC.
The suggested debugging flow would be:
(1) check the global counter for fallback are incrementing;
(2) find a flow with high stats but no in_hw flag set.
The in_hw indication should be sufficient in most cases (unless there
are shared blocks between netdevs of different ASICs...).
> >> I'm slightly concerned about potential performance impact, would you
> >> be able to share some numbers for non-trivial number of flows (100k
> >> active?)?
> >
> > Agreed, features used for diagnostics cannot have a harmful penalty
> > for fast path performance.
>
> Fast path performance is not affected as these counters are not
> incremented there. They are only incremented by the nic driver when they
> gather their statistics from hardware.
Not by much, you are adding state to performance-critical structures,
though, for what is effectively debugging purposes.
I was mostly talking about the HW offload stat updates (sorry for not
being clear).
We can have some hundreds of thousands active offloaded flows, each of
them can have multiple actions, and stats have to be updated multiple
times per second and dumped probably around once a second, too. On a
busy system the stats will get evicted from cache between each round.
But I'm speculating let's see if I can get some numbers on it (if you
could get some too, that would be great!).
> However, the flow creation is effected, as this is where the extra
> memory gets allocated. I had done some 40K flow tests before and did not
> see any noticeable change in flow insertion performance. As requested by
> Jakub I did it again for 100K (and threw a Netronome blade in the mix
> ;). I used Marcelo’s test tool,
> https://github.com/marceloleitner/perf-flower.git.
>
> Here are the numbers (time in seconds) for 10 runs in sorted order:
>
> +-------------+----------------+
> | Base_kernel | Change_applied |
> +-------------+----------------+
> | 5.684019 | 5.656388 |
> | 5.699658 | 5.674974 |
> | 5.725220 | 5.722107 |
> | 5.739285 | 5.839855 |
> | 5.748088 | 5.865238 |
> | 5.766231 | 5.873913 |
> | 5.842264 | 5.909259 |
> | 5.902202 | 5.912685 |
> | 5.905391 | 5.947138 |
> | 6.032997 | 5.997779 |
> +-------------+----------------+
>
> I guess the deviation is in the userspace part, which is where in real
> life flows get added anyway.
>
> Let me know if more is unclear.
^ permalink raw reply
* Re: [iproute PATCH 07/10] ip: Add missing -M flag to help text
From: Phil Sutter @ 2018-08-17 11:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20180816102802.31782-8-phil@nwl.cc>
Hi Stephen,
On Thu, Aug 16, 2018 at 12:27:59PM +0200, Phil Sutter wrote:
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> ip/ip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Seems like this patch wasn't applied. Did you perhaps drop it by
accident?
Cheers, Phil
^ permalink raw reply
* [PATCH 2/2] ethernet: lpc_eth: Use NULL to compare with pointer-typed value rather than 0
From: zhong jiang @ 2018-08-17 13:18 UTC (permalink / raw)
To: davem; +Cc: vz, slemieux.tyco, keescook, netdev, linux-kernel
In-Reply-To: <1534511933-39236-1-git-send-email-zhongjiang@huawei.com>
We should use NULL to compare with pointer-typed value rather than 0.
The issue is detected with the help of Coccinelle.
---
drivers/net/ethernet/nxp/lpc_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 08381ef..04d9e62 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1350,7 +1350,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
"IRAM not big enough for net buffers, using SDRAM instead.\n");
}
- if (pldat->dma_buff_base_v == 0) {
+ if (pldat->dma_buff_base_v == NULL) {
ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (ret)
goto err_out_free_irq;
--
1.7.12.4
^ permalink raw reply related
* [PATCH 1/2] ethernet: declance: Use NULL to compare with pointer-typed value rather than 0
From: zhong jiang @ 2018-08-17 13:18 UTC (permalink / raw)
To: davem; +Cc: vz, slemieux.tyco, keescook, netdev, linux-kernel
In-Reply-To: <1534511933-39236-1-git-send-email-zhongjiang@huawei.com>
We should use NULL to compare with pointer-typed value rather than
0. The issue is detected with the help of Coccinelle.
---
drivers/net/ethernet/amd/declance.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/declance.c b/drivers/net/ethernet/amd/declance.c
index 116997a..6e035df 100644
--- a/drivers/net/ethernet/amd/declance.c
+++ b/drivers/net/ethernet/amd/declance.c
@@ -607,7 +607,7 @@ static int lance_rx(struct net_device *dev)
len = (*rds_ptr(rd, mblength, lp->type) & 0xfff) - 4;
skb = netdev_alloc_skb(dev, len + 2);
- if (skb == 0) {
+ if (skb == NULL) {
dev->stats.rx_dropped++;
*rds_ptr(rd, mblength, lp->type) = 0;
*rds_ptr(rd, rmd1, lp->type) =
--
1.7.12.4
^ permalink raw reply related
* [PATCH 0/2] ethernet: Use NULL to compare with pointer-typed value rather than 0
From: zhong jiang @ 2018-08-17 13:18 UTC (permalink / raw)
To: davem; +Cc: vz, slemieux.tyco, keescook, netdev, linux-kernel
zhong jiang (2):
ethernet: declance: Use NULL to compare with pointer-typed value
rather than 0
ethernet: lpc_eth: Use NULL to compare with pointer-typed value
rather than 0
drivers/net/ethernet/amd/declance.c | 2 +-
drivers/net/ethernet/nxp/lpc_eth.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
1.7.12.4
^ 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