* 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
* 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 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: [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: [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: [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: [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: [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: [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
* 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
* [PATCH bpf] tools/bpf: fix bpf selftest test_cgroup_storage failure
From: Yonghong Song @ 2018-08-17 15:54 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team, Roman Gushchin
The bpf selftest test_cgroup_storage failed in one of
our production test servers.
# sudo ./test_cgroup_storage
Failed to create map: Operation not permitted
It turns out this is due to insufficient locked memory
with system default 16KB.
Similar to other self tests, let us arm the process
with unlimited locked memory. With this change,
the test passed.
# sudo ./test_cgroup_storage
test_cgroup_storage:PASS
Fixes: 68cfa3ac6b8d ("selftests/bpf: add a cgroup storage test")
Cc: Roman Gushchin <guro@fb.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
---
tools/testing/selftests/bpf/test_cgroup_storage.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/bpf/test_cgroup_storage.c b/tools/testing/selftests/bpf/test_cgroup_storage.c
index dc83fb2d3f27..4e196e3bfecf 100644
--- a/tools/testing/selftests/bpf/test_cgroup_storage.c
+++ b/tools/testing/selftests/bpf/test_cgroup_storage.c
@@ -5,6 +5,7 @@
#include <stdio.h>
#include <stdlib.h>
+#include "bpf_rlimit.h"
#include "cgroup_helpers.h"
char bpf_log_buf[BPF_LOG_BUF_SIZE];
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf] tools/bpf: fix bpf selftest test_cgroup_storage failure
From: Roman Gushchin @ 2018-08-17 15:59 UTC (permalink / raw)
To: Yonghong Song; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20180817155415.3357915-1-yhs@fb.com>
On Fri, Aug 17, 2018 at 08:54:15AM -0700, Yonghong Song wrote:
> The bpf selftest test_cgroup_storage failed in one of
> our production test servers.
> # sudo ./test_cgroup_storage
> Failed to create map: Operation not permitted
>
> It turns out this is due to insufficient locked memory
> with system default 16KB.
>
> Similar to other self tests, let us arm the process
> with unlimited locked memory. With this change,
> the test passed.
> # sudo ./test_cgroup_storage
> test_cgroup_storage:PASS
>
> Fixes: 68cfa3ac6b8d ("selftests/bpf: add a cgroup storage test")
> Cc: Roman Gushchin <guro@fb.com>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
> tools/testing/selftests/bpf/test_cgroup_storage.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/bpf/test_cgroup_storage.c b/tools/testing/selftests/bpf/test_cgroup_storage.c
> index dc83fb2d3f27..4e196e3bfecf 100644
> --- a/tools/testing/selftests/bpf/test_cgroup_storage.c
> +++ b/tools/testing/selftests/bpf/test_cgroup_storage.c
> @@ -5,6 +5,7 @@
> #include <stdio.h>
> #include <stdlib.h>
>
> +#include "bpf_rlimit.h"
> #include "cgroup_helpers.h"
>
> char bpf_log_buf[BPF_LOG_BUF_SIZE];
> --
> 2.17.1
>
Acked-by: Roman Gushchin <guro@fb.com>
Thank you, Yonghong!
^ permalink raw reply
* RE: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Steve Wise @ 2018-08-17 16:17 UTC (permalink / raw)
To: 'Sagi Grimberg', 'Max Gurtovoy',
'Jason Gunthorpe'
Cc: 'Leon Romanovsky', 'Doug Ledford',
'RDMA mailing list', 'Saeed Mahameed',
'linux-netdev'
In-Reply-To: <85bba372-049c-2a12-362e-adcb0931cf49@opengridcomputing.com>
> On 8/16/2018 1:26 PM, Sagi Grimberg wrote:
> >
> >> Let me know if you want me to try this or any particular fix.
> >
> > Steve, can you test this one?
>
> Yes! I'll try it out tomorrow.
>
> Stevo
>
Hey Sagi,
The patch works allowing connections for the various affinity mappings below:
One comp_vector per core across all cores, starting with numa-local cores:
[ 3798.494963] iw_cxgb4: comp_vector 0, irq 203 mask 0x100
[ 3798.500717] iw_cxgb4: comp_vector 1, irq 204 mask 0x200
[ 3798.506396] iw_cxgb4: comp_vector 2, irq 205 mask 0x400
[ 3798.512043] iw_cxgb4: comp_vector 3, irq 206 mask 0x800
[ 3798.517675] iw_cxgb4: comp_vector 4, irq 207 mask 0x1000
[ 3798.523382] iw_cxgb4: comp_vector 5, irq 208 mask 0x2000
[ 3798.529075] iw_cxgb4: comp_vector 6, irq 209 mask 0x4000
[ 3798.534754] iw_cxgb4: comp_vector 7, irq 210 mask 0x8000
[ 3798.540425] iw_cxgb4: comp_vector 8, irq 211 mask 0x1
[ 3798.545825] iw_cxgb4: comp_vector 9, irq 212 mask 0x2
[ 3798.551231] iw_cxgb4: comp_vector 10, irq 213 mask 0x4
[ 3798.556713] iw_cxgb4: comp_vector 11, irq 214 mask 0x8
[ 3798.562189] iw_cxgb4: comp_vector 12, irq 215 mask 0x10
[ 3798.567755] iw_cxgb4: comp_vector 13, irq 216 mask 0x20
[ 3798.573312] iw_cxgb4: comp_vector 14, irq 217 mask 0x40
[ 3798.578855] iw_cxgb4: comp_vector 15, irq 218 mask 0x80
[ 3798.584384] set->mq_map[0] queue 8 vector 8
[ 3798.588879] set->mq_map[1] queue 9 vector 9
[ 3798.593358] set->mq_map[2] queue 10 vector 10
[ 3798.598008] set->mq_map[3] queue 11 vector 11
[ 3798.602633] set->mq_map[4] queue 12 vector 12
[ 3798.607260] set->mq_map[5] queue 13 vector 13
[ 3798.611872] set->mq_map[6] queue 14 vector 14
[ 3798.616470] set->mq_map[7] queue 15 vector 15
[ 3798.621059] set->mq_map[8] queue 0 vector 0
[ 3798.625460] set->mq_map[9] queue 1 vector 1
[ 3798.629852] set->mq_map[10] queue 2 vector 2
[ 3798.634331] set->mq_map[11] queue 3 vector 3
[ 3798.638796] set->mq_map[12] queue 4 vector 4
[ 3798.643263] set->mq_map[13] queue 5 vector 5
[ 3798.647727] set->mq_map[14] queue 6 vector 6
[ 3798.652197] set->mq_map[15] queue 7 vector 7
One comp_vector per core, but only numa-local cores:
[ 3855.406027] iw_cxgb4: comp_vector 0, irq 203 mask 0x400
[ 3855.411577] iw_cxgb4: comp_vector 1, irq 204 mask 0x800
[ 3855.417057] iw_cxgb4: comp_vector 2, irq 205 mask 0x1000
[ 3855.422618] iw_cxgb4: comp_vector 3, irq 206 mask 0x2000
[ 3855.428176] iw_cxgb4: comp_vector 4, irq 207 mask 0x4000
[ 3855.433731] iw_cxgb4: comp_vector 5, irq 208 mask 0x8000
[ 3855.439293] iw_cxgb4: comp_vector 6, irq 209 mask 0x100
[ 3855.444770] iw_cxgb4: comp_vector 7, irq 210 mask 0x200
[ 3855.450231] iw_cxgb4: comp_vector 8, irq 211 mask 0x400
[ 3855.455691] iw_cxgb4: comp_vector 9, irq 212 mask 0x800
[ 3855.461144] iw_cxgb4: comp_vector 10, irq 213 mask 0x1000
[ 3855.466768] iw_cxgb4: comp_vector 11, irq 214 mask 0x2000
[ 3855.472379] iw_cxgb4: comp_vector 12, irq 215 mask 0x4000
[ 3855.477992] iw_cxgb4: comp_vector 13, irq 216 mask 0x8000
[ 3855.483599] iw_cxgb4: comp_vector 14, irq 217 mask 0x100
[ 3855.489116] iw_cxgb4: comp_vector 15, irq 218 mask 0x200
[ 3855.494644] set->mq_map[0] queue 8 vector 8
[ 3855.499046] set->mq_map[1] queue 9 vector 9
[ 3855.503445] set->mq_map[2] queue 10 vector 10
[ 3855.508025] set->mq_map[3] queue 11 vector 11
[ 3855.512600] set->mq_map[4] queue 12 vector 12
[ 3855.517176] set->mq_map[5] queue 13 vector 13
[ 3855.521750] set->mq_map[6] queue 14 vector 14
[ 3855.526325] set->mq_map[7] queue 15 vector 15
[ 3855.530902] set->mq_map[8] queue 6 vector 6
[ 3855.535306] set->mq_map[9] queue 7 vector 7
[ 3855.539703] set->mq_map[10] queue 0 vector 0
[ 3855.544197] set->mq_map[11] queue 1 vector 1
[ 3855.548670] set->mq_map[12] queue 2 vector 2
[ 3855.553144] set->mq_map[13] queue 3 vector 3
[ 3855.557630] set->mq_map[14] queue 4 vector 4
[ 3855.562105] set->mq_map[15] queue 5 vector 5
Each comp_vector has affinity to all numa-local cores:
[ 4010.002954] iw_cxgb4: comp_vector 0, irq 203 mask 0xff00
[ 4010.008606] iw_cxgb4: comp_vector 1, irq 204 mask 0xff00
[ 4010.014179] iw_cxgb4: comp_vector 2, irq 205 mask 0xff00
[ 4010.019741] iw_cxgb4: comp_vector 3, irq 206 mask 0xff00
[ 4010.025310] iw_cxgb4: comp_vector 4, irq 207 mask 0xff00
[ 4010.030881] iw_cxgb4: comp_vector 5, irq 208 mask 0xff00
[ 4010.036448] iw_cxgb4: comp_vector 6, irq 209 mask 0xff00
[ 4010.042012] iw_cxgb4: comp_vector 7, irq 210 mask 0xff00
[ 4010.047562] iw_cxgb4: comp_vector 8, irq 211 mask 0xff00
[ 4010.053103] iw_cxgb4: comp_vector 9, irq 212 mask 0xff00
[ 4010.058632] iw_cxgb4: comp_vector 10, irq 213 mask 0xff00
[ 4010.064248] iw_cxgb4: comp_vector 11, irq 214 mask 0xff00
[ 4010.069863] iw_cxgb4: comp_vector 12, irq 215 mask 0xff00
[ 4010.075462] iw_cxgb4: comp_vector 13, irq 216 mask 0xff00
[ 4010.081066] iw_cxgb4: comp_vector 14, irq 217 mask 0xff00
[ 4010.086676] iw_cxgb4: comp_vector 15, irq 218 mask 0xff00
[ 4010.092283] set->mq_map[0] queue 8 vector 8
[ 4010.096683] set->mq_map[1] queue 9 vector 9
[ 4010.101085] set->mq_map[2] queue 10 vector 10
[ 4010.105663] set->mq_map[3] queue 11 vector 11
[ 4010.110239] set->mq_map[4] queue 12 vector 12
[ 4010.114810] set->mq_map[5] queue 13 vector 13
[ 4010.119379] set->mq_map[6] queue 14 vector 14
[ 4010.123942] set->mq_map[7] queue 15 vector 15
[ 4010.128502] set->mq_map[8] queue 0 vector 0
[ 4010.132903] set->mq_map[9] queue 1 vector 1
[ 4010.137299] set->mq_map[10] queue 2 vector 2
[ 4010.141792] set->mq_map[11] queue 3 vector 3
[ 4010.146274] set->mq_map[12] queue 4 vector 4
[ 4010.150754] set->mq_map[13] queue 5 vector 5
[ 4010.155235] set->mq_map[14] queue 6 vector 6
[ 4010.159716] set->mq_map[15] queue 7 vector 7
^ permalink raw reply
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Russell King - ARM Linux @ 2018-08-17 16:17 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Peter Robinson, 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 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).
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: [iproute PATCH v4] Make colored output configurable
From: Stephen Hemminger @ 2018-08-17 16:24 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev, David Ahern, Till Maas
In-Reply-To: <20180816093703.23022-1-phil@nwl.cc>
On Thu, 16 Aug 2018 11:37:03 +0200
Phil Sutter <phil@nwl.cc> wrote:
> Allow for -color={never,auto,always} to have colored output disabled,
> enabled only if stdout is a terminal or enabled regardless of stdout
> state.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> Changes since v1:
> - Allow to override isatty() check by specifying '-color' flag more than
> once.
> - Document new behaviour in man pages.
>
> Changes since v2:
> - Implement new -color=foo syntax.
> - Update commit message and man page texts accordingly.
>
> Changes since v3:
> - Fix typo in tc/tc.c causing compile error.
> ---
> bridge/bridge.c | 3 +--
> include/color.h | 7 +++++++
> ip/ip.c | 3 +--
> lib/color.c | 33 ++++++++++++++++++++++++++++++++-
> man/man8/bridge.8 | 13 +++++++++++--
> man/man8/ip.8 | 13 +++++++++++--
> man/man8/tc.8 | 13 +++++++++++--
> tc/tc.c | 3 +--
> 8 files changed, 75 insertions(+), 13 deletions(-)
>
> diff --git a/bridge/bridge.c b/bridge/bridge.c
> index 451d684e0bcfd..e35e5bdf7fb30 100644
> --- a/bridge/bridge.c
> +++ b/bridge/bridge.c
> @@ -173,8 +173,7 @@ main(int argc, char **argv)
> NEXT_ARG();
> if (netns_switch(argv[1]))
> exit(-1);
> - } else if (matches(opt, "-color") == 0) {
> - ++color;
> + } else if (matches_color(opt, &color) == 0) {
> } else if (matches(opt, "-compressvlans") == 0) {
> ++compress_vlans;
> } else if (matches(opt, "-force") == 0) {
> diff --git a/include/color.h b/include/color.h
> index 4f2c918db7e43..42038dc2e7f87 100644
> --- a/include/color.h
> +++ b/include/color.h
> @@ -12,8 +12,15 @@ enum color_attr {
> COLOR_NONE
> };
>
> +enum color_opt {
> + COLOR_OPT_NEVER = 0,
> + COLOR_OPT_AUTO = 1,
> + COLOR_OPT_ALWAYS = 2
> +};
> +
> void enable_color(void);
> int check_enable_color(int color, int json);
> +int matches_color(const char *arg, int *val);
> void set_color_palette(void);
> int color_fprintf(FILE *fp, enum color_attr attr, const char *fmt, ...);
> enum color_attr ifa_family_color(__u8 ifa_family);
> diff --git a/ip/ip.c b/ip/ip.c
> index 38eac5ec1e17d..893c3c43ef99a 100644
> --- a/ip/ip.c
> +++ b/ip/ip.c
> @@ -283,8 +283,7 @@ int main(int argc, char **argv)
> exit(-1);
> }
> rcvbuf = size;
> - } else if (matches(opt, "-color") == 0) {
> - ++color;
> + } else if (matches_color(opt, &color) == 0) {
> } else if (matches(opt, "-help") == 0) {
> usage();
> } else if (matches(opt, "-netns") == 0) {
> diff --git a/lib/color.c b/lib/color.c
> index edf96e5c6ecd7..3ad1d6d647722 100644
> --- a/lib/color.c
> +++ b/lib/color.c
> @@ -3,11 +3,13 @@
> #include <stdarg.h>
> #include <stdlib.h>
> #include <string.h>
> +#include <unistd.h>
> #include <sys/socket.h>
> #include <sys/types.h>
> #include <linux/if.h>
>
> #include "color.h"
> +#include "utils.h"
>
> enum color {
> C_RED,
> @@ -79,13 +81,42 @@ void enable_color(void)
>
> int check_enable_color(int color, int json)
> {
> - if (color && !json) {
> + if (json || color == COLOR_OPT_NEVER)
> + return 1;
> +
> + if (color == COLOR_OPT_ALWAYS || isatty(fileno(stdout))) {
> enable_color();
> return 0;
> }
> return 1;
> }
>
> +int matches_color(const char *arg, int *val)
> +{
> + char *dup, *p;
> +
> + if (!val)
> + return 1;
I am fine with this even for current version (not next).
Minor nit, is that these functions should be bool.
Most of the iproute2 uses int for booleans for historical reasons
but lets try use bool for new code.
^ permalink raw reply
* Re: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
From: Arnd Bergmann @ 2018-08-17 19:29 UTC (permalink / raw)
To: Richard Cochran
Cc: Bryan.Whitehead, UNGLinuxDriver, David Miller, YueHaibing,
Networking, Linux Kernel Mailing List
In-Reply-To: <20180817162558.GB22210@eeboy>
On Fri, Aug 17, 2018 at 6:26 PM Richard Cochran
<richardcochran@gmail.com> wrote:
>
> 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.
Ah, so you mean the other drivers in fact do initialize the hardware clock,
they just set it to UTC instead of TAI? I must have looked wrong then,
but I see it now in most implementations (exceptions include ravb, sfc
and stmmac).
This certainly seems to be an "interesting" problem, given that the Linux
implementations (other than the new lan743x) then start out with UTC,
while the PTP spec mandates TAI. So even if the system clock is
perfectly synchronized to UTC at boot, we set the PTP hardware 37
seconds slow.
It would not be hard to change all PTP drivers to explicitly initialize to
TAI, but that might create its own set of problems if random code
depends on the current behavior.
I also see that "phc_ctl /dev/ptp0 set" defaults to CLOCK_REALTIME
and has no option to use CLOCK_TAI instead. How is this meant to
work? I see a lot of other code that tries to deal with leap seconds and
the tai offset, so I hope I was just misreading that code.
Arnd
^ permalink raw reply
* Re: mv88e6xxx: question: can switch irq be shared?
From: David Miller @ 2018-08-17 16:28 UTC (permalink / raw)
To: marek.behun; +Cc: andrew, netdev
In-Reply-To: <20180817093055.3107-1-marek.behun@nic.cz>
From: Marek Behún <marek.behun@nic.cz>
Date: Fri, 17 Aug 2018 11:30:55 +0200
> - IRQF_ONESHOT | IRQF_TRIGGER_FALLING,
> + IRQF_ONESHOT | IRQF_TRIGGER_FALLING
> + | IRQF_SHARED,
The "|" operator shoudl end a line not start one.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: mv88e6xxx: Share main switch IRQ
From: David Miller @ 2018-08-17 16:29 UTC (permalink / raw)
To: marek.behun; +Cc: andrew, netdev
In-Reply-To: <20180817100949.6648-1-marek.behun@nic.cz>
From: Marek Behún <marek.behun@nic.cz>
Date: Fri, 17 Aug 2018 12:09:49 +0200
> On some boards the interrupt can be shared between multiple devices.
> For example on Turris Mox the interrupt is shared between all switches.
>
> Signed-off-by: Marek Behun <marek.behun@nic.cz>
The net-next tree is closed, please resubmit when it opens back
up.
^ permalink raw reply
* Re: [PATCH iproute2] ipmaddr: use preferred_family when given
From: Stephen Hemminger @ 2018-08-17 16:29 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: netdev, Mahesh Bandewar
In-Reply-To: <20180815230855.130278-1-mahesh@bandewar.net>
On Wed, 15 Aug 2018 16:08:55 -0700
Mahesh Bandewar <mahesh@bandewar.net> wrote:
> From: Mahesh Bandewar <maheshb@google.com>
>
> When creating socket() AF_INET is used irrespective of the family
> that is given at the command-line (with -4, -6, or -0). This change
> will open the socket with the preferred family.
>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> ---
> ip/ipmaddr.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
What is impact of this? Does ip multicast address changes not work on IPv6?
Or is it just doing the right thing?
^ permalink raw reply
* Re: [endianness bug] cxgb4: mk_act_open_req() buggers ->{local,peer}_ip on big-endian hosts
From: David Miller @ 2018-08-17 16:34 UTC (permalink / raw)
To: viro; +Cc: ganeshgr, rahul.lakkireddy, netdev
In-Reply-To: <20180817154320.GD6515@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Fri, 17 Aug 2018 16:43:20 +0100
> Umm... I thought net-next had been closed until -rc1, hadn't
> it?
That's correct.
^ permalink raw reply
* [iproute PATCH 2/2] lib: Make check_enable_color() return boolean
From: Phil Sutter @ 2018-08-17 16:38 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, David Ahern, Till Maas
In-Reply-To: <20180817163846.27578-1-phil@nwl.cc>
As suggested, turn return code into true/false although it's not checked
anywhere yet.
Fixes: 4d82962cccc6a ("Merge common code for conditionally colored output")
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
include/color.h | 2 +-
lib/color.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/color.h b/include/color.h
index a22a00c2277e0..e30f28c51c844 100644
--- a/include/color.h
+++ b/include/color.h
@@ -21,7 +21,7 @@ enum color_opt {
};
void enable_color(void);
-int check_enable_color(int color, int json);
+bool check_enable_color(int color, int json);
bool matches_color(const char *arg, int *val);
void set_color_palette(void);
int color_fprintf(FILE *fp, enum color_attr attr, const char *fmt, ...);
diff --git a/lib/color.c b/lib/color.c
index 9c9023587748f..eaf69e74d673a 100644
--- a/lib/color.c
+++ b/lib/color.c
@@ -79,16 +79,16 @@ void enable_color(void)
set_color_palette();
}
-int check_enable_color(int color, int json)
+bool check_enable_color(int color, int json)
{
if (json || color == COLOR_OPT_NEVER)
- return 1;
+ return false;
if (color == COLOR_OPT_ALWAYS || isatty(fileno(stdout))) {
enable_color();
- return 0;
+ return true;
}
- return 1;
+ return false;
}
bool matches_color(const char *arg, int *val)
--
2.18.0
^ permalink raw reply related
* [iproute PATCH v5 1/2] Make colored output configurable
From: Phil Sutter @ 2018-08-17 16:38 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, David Ahern, Till Maas
In-Reply-To: <20180817092400.5b2c9173@xeon-e3>
Allow for -color={never,auto,always} to have colored output disabled,
enabled only if stdout is a terminal or enabled regardless of stdout
state.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
Changes since v1:
- Allow to override isatty() check by specifying '-color' flag more than
once.
- Document new behaviour in man pages.
Changes since v2:
- Implement new -color=foo syntax.
- Update commit message and man page texts accordingly.
Changes since v3:
- Fix typo in tc/tc.c causing compile error.
Changes since v4:
- Make matches_color() return boolean.
---
bridge/bridge.c | 3 +--
include/color.h | 9 +++++++++
ip/ip.c | 3 +--
lib/color.c | 33 ++++++++++++++++++++++++++++++++-
man/man8/bridge.8 | 13 +++++++++++--
man/man8/ip.8 | 13 +++++++++++--
man/man8/tc.8 | 13 +++++++++++--
tc/tc.c | 3 +--
8 files changed, 77 insertions(+), 13 deletions(-)
diff --git a/bridge/bridge.c b/bridge/bridge.c
index b3cab717ead30..663a35b2b2e46 100644
--- a/bridge/bridge.c
+++ b/bridge/bridge.c
@@ -173,8 +173,7 @@ main(int argc, char **argv)
NEXT_ARG();
if (netns_switch(argv[1]))
exit(-1);
- } else if (matches(opt, "-color") == 0) {
- ++color;
+ } else if (matches_color(opt, &color)) {
} else if (matches(opt, "-compressvlans") == 0) {
++compress_vlans;
} else if (matches(opt, "-force") == 0) {
diff --git a/include/color.h b/include/color.h
index 4f2c918db7e43..a22a00c2277e0 100644
--- a/include/color.h
+++ b/include/color.h
@@ -2,6 +2,8 @@
#ifndef __COLOR_H__
#define __COLOR_H__ 1
+#include <stdbool.h>
+
enum color_attr {
COLOR_IFNAME,
COLOR_MAC,
@@ -12,8 +14,15 @@ enum color_attr {
COLOR_NONE
};
+enum color_opt {
+ COLOR_OPT_NEVER = 0,
+ COLOR_OPT_AUTO = 1,
+ COLOR_OPT_ALWAYS = 2
+};
+
void enable_color(void);
int check_enable_color(int color, int json);
+bool matches_color(const char *arg, int *val);
void set_color_palette(void);
int color_fprintf(FILE *fp, enum color_attr attr, const char *fmt, ...);
enum color_attr ifa_family_color(__u8 ifa_family);
diff --git a/ip/ip.c b/ip/ip.c
index 72e858eed50d5..58c643df8a366 100644
--- a/ip/ip.c
+++ b/ip/ip.c
@@ -283,8 +283,7 @@ int main(int argc, char **argv)
exit(-1);
}
rcvbuf = size;
- } else if (matches(opt, "-color") == 0) {
- ++color;
+ } else if (matches_color(opt, &color)) {
} else if (matches(opt, "-help") == 0) {
usage();
} else if (matches(opt, "-netns") == 0) {
diff --git a/lib/color.c b/lib/color.c
index edf96e5c6ecd7..9c9023587748f 100644
--- a/lib/color.c
+++ b/lib/color.c
@@ -3,11 +3,13 @@
#include <stdarg.h>
#include <stdlib.h>
#include <string.h>
+#include <unistd.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <linux/if.h>
#include "color.h"
+#include "utils.h"
enum color {
C_RED,
@@ -79,13 +81,42 @@ void enable_color(void)
int check_enable_color(int color, int json)
{
- if (color && !json) {
+ if (json || color == COLOR_OPT_NEVER)
+ return 1;
+
+ if (color == COLOR_OPT_ALWAYS || isatty(fileno(stdout))) {
enable_color();
return 0;
}
return 1;
}
+bool matches_color(const char *arg, int *val)
+{
+ char *dup, *p;
+
+ if (!val)
+ return false;
+
+ dup = strdupa(arg);
+ p = strchrnul(dup, '=');
+ if (*p)
+ *(p++) = '\0';
+
+ if (matches(dup, "-color"))
+ return false;
+
+ if (*p == '\0' || !strcmp(p, "always"))
+ *val = COLOR_OPT_ALWAYS;
+ else if (!strcmp(p, "auto"))
+ *val = COLOR_OPT_AUTO;
+ else if (!strcmp(p, "never"))
+ *val = COLOR_OPT_NEVER;
+ else
+ return false;
+ return true;
+}
+
void set_color_palette(void)
{
char *p = getenv("COLORFGBG");
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index 1d10cb2b6a72c..53cd3d0a3d933 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -172,8 +172,17 @@ If there were any errors during execution of the commands, the application
return code will be non zero.
.TP
-.BR "\-c" , " -color"
-Use color output.
+.BR \-c [ color ][ = { always | auto | never }
+Configure color output. If parameter is omitted or
+.BR always ,
+color output is enabled regardless of stdout state. If parameter is
+.BR auto ,
+stdout is checked to be a terminal before enabling color output. If parameter is
+.BR never ,
+color output is disabled. If specified multiple times, the last one takes
+precedence. This flag is ignored if
+.B \-json
+is also given.
.TP
.BR "\-j", " \-json"
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 0087d18b74706..1d358879ec39c 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -187,8 +187,17 @@ to
executes specified command over all objects, it depends if command supports this option.
.TP
-.BR "\-c" , " -color"
-Use color output.
+.BR \-c [ color ][ = { always | auto | never }
+Configure color output. If parameter is omitted or
+.BR always ,
+color output is enabled regardless of stdout state. If parameter is
+.BR auto ,
+stdout is checked to be a terminal before enabling color output. If parameter is
+.BR never ,
+color output is disabled. If specified multiple times, the last one takes
+precedence. This flag is ignored if
+.B \-json
+is also given.
.TP
.BR "\-t" , " \-timestamp"
diff --git a/man/man8/tc.8 b/man/man8/tc.8
index fd33f9b2f1806..f98398a34bd3e 100644
--- a/man/man8/tc.8
+++ b/man/man8/tc.8
@@ -755,8 +755,17 @@ option was specified. Classes can be filtered only by
option.
.TP
-.BR "\ -color"
-Use color output.
+.BR \-c [ color ][ = { always | auto | never }
+Configure color output. If parameter is omitted or
+.BR always ,
+color output is enabled regardless of stdout state. If parameter is
+.BR auto ,
+stdout is checked to be a terminal before enabling color output. If parameter is
+.BR never ,
+color output is disabled. If specified multiple times, the last one takes
+precedence. This flag is ignored if
+.B \-json
+is also given.
.TP
.BR "\-j", " \-json"
diff --git a/tc/tc.c b/tc/tc.c
index 4c7a128c8103e..4b28e9b182c1d 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -496,8 +496,7 @@ int main(int argc, char **argv)
matches(argv[1], "-conf") == 0) {
NEXT_ARG();
conf_file = argv[1];
- } else if (matches(argv[1], "-color") == 0) {
- ++color;
+ } else if (matches_color(argv[1], &color)) {
} else if (matches(argv[1], "-timestamp") == 0) {
timestamp++;
} else if (matches(argv[1], "-tshort") == 0) {
--
2.18.0
^ permalink raw reply related
* Allocation failure with subsequent kernel crash
From: tedheadster @ 2018-08-17 17:17 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev
Cc: Ingo Molnar, Thomas Gleixner, ast, daniel
I have been trying to bisect this crash but I have not found a
reliable reproducer. My best guess is that it was introduced after the
4.14 release.
This is a 32 bit kernel. It is odd in that it first generates a memory
allocation failure, and then quickly crashes with a succeeding bug.
I'm including the netdev group since there is a lot of BPF stacktrace.
[ 42.512745] systemd: vmalloc: allocation failure: 0 bytes,
mode:0x14080c0(GFP_KERNEL|__GFP_ZERO), nodemask=(null)
[ 42.526396] CPU: 0 PID: 1 Comm: systemd Not tainted
4.14.0.bisect-4.k5-tsc-desktop+ #168
[ 42.535878] Hardware name: AX5TC/AX5TC, BIOS 4.51 PG 03/23/98
[ 42.540944] Call Trace:
[ 42.550334] dump_stack+0x16/0x18
[ 42.558519] warn_alloc+0xa3/0x10b
[ 42.563844] __vmalloc_node_range+0x170/0x17d
[ 42.574293] __vmalloc_node+0x35/0x3a
[ 42.586454] ? bpf_check+0x52/0x2c64
[ 42.594504] vzalloc+0x21/0x23
[ 42.602499] ? bpf_check+0x52/0x2c64
[ 42.614418] bpf_check+0x52/0x2c64
[ 42.622623] ? slob_page_alloc+0x130/0x177
[ 42.642524] ? vmap_page_range_noflush+0xe/0x109
[ 42.655415] ? slob_page_alloc+0x130/0x177
[ 42.666466] ? native_io_delay+0x8/0x2e
[ 42.674455] ? tk_clock_read+0xa/0xd
[ 42.685808] ? timekeeping_get_ns+0x10/0x70
[ 42.688097] ? ktime_get_with_offset+0x49/0x66
[ 42.702478] bpf_prog_load+0x2fc/0x442
[ 42.710467] ? bpf_prog_load+0x2fc/0x442
[ 42.722474] ? bpf_prog_array_alloc+0x1b/0x24
[ 42.734478] ? bpf_prog_array_alloc+0x1b/0x24
[ 42.746532] ? compute_effective_progs+0x5c/0xb7
[ 42.758492] ? css_next_descendant_pre+0xa/0x43
[ 42.766488] ? cap_capable+0xa/0x5d
[ 42.778457] ? security_capable+0x2d/0x40
[ 42.786537] ? __copy_from_user_ll_nocache_nozero+0xb/0x37
[ 42.799175] ? __copy_user_ll+0xd/0xf
[ 42.810492] ? security_bpf+0xc/0x3b
[ 42.816807] SyS_bpf+0x7f7/0xd79
[ 42.822333] ? __rcu_read_unlock+0x9/0x4b
[ 42.834457] ? mntput_no_expire+0x28/0x119
[ 42.842525] do_int80_syscall_32+0x45/0x57
[ 42.854449] ? do_int80_syscall_32+0x45/0x57
[ 42.866486] entry_INT80_32+0x27/0x27
[ 42.878299] EIP: 0xb7a95082
[ 42.881808] EFLAGS: 00000246 CPU: 0
[ 42.886454] EAX: ffffffda EBX: 00000005 ECX: bfe76e40 EDX: 00000048
[ 42.902452] ESI: 00000040 EDI: 00000000 EBP: 00a8a458 ESP: bfe76e0c
[ 42.918413] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[ 42.932627] Mem-Info:
[ 42.936616] active_anon:845 inactive_anon:31 isolated_anon:0
[ 42.936616] active_file:4364 inactive_file:9478 isolated_file:0
[ 42.936616] unevictable:0 dirty:428 writeback:0 unstable:0
[ 42.936616] slab_reclaimable:0 slab_unreclaimable:0
[ 42.936616] mapped:4966 shmem:54 pagetables:46 bounce:0
[ 42.936616] free:47214 free_pcp:25 free_cma:0
[ 42.946479] Node 0 active_anon:3380kB inactive_anon:124kB
active_file:17456kB inactive_file:37912kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB mapped:19928kB dirty:1720kB
writeback:0kB shmem:216kB writeback_tmp:0kB unstable:0kB
all_unreclaimable? no
[ 42.958503] Normal free:188856kB min:2012kB low:2512kB high:3012kB
active_anon:3380kB inactive_anon:124kB active_file:17456kB
inactive_file:37912kB unevictable:0kB writepending:1732kB
present:261756kB managed:254168kB mlocked:0kB kernel_stack:328kB
pagetables:184kB bounce:0kB free_pcp:100kB local_pcp:100kB
free_cma:0kB
[ 42.970387] lowmem_reserve[]: 0 0
[ 42.978444] Normal: 26*4kB (U) 34*8kB (UM) 10*16kB (UM) 5*32kB (U)
4*64kB (U) 4*128kB (U) 4*256kB (UM) 0*512kB 2*1024kB (U) 0*2048kB
45*4096kB (M) = 188856kB
[ 42.986472] 13897 total pagecache pages
[ 42.998400] 0 pages in swap cache
[ 43.007903] Swap cache stats: add 0, delete 0, find 0/0
[ 43.010200] Free swap = 0kB
[ 43.013762] Total swap = 0kB
[ 43.024725] 65439 pages RAM
[ 43.034360] 0 pages HighMem/MovableOnly
[ 43.046385] 1897 pages reserved
[ 43.054521] BUG: unable to handle kernel NULL pointer dereference at 00000004
[ 43.058026] IP: free_used_maps+0xe/0x2a
[ 43.058026] *pde = 00000000
[ 43.058026] Oops: 0000 [#1] PREEMPT
[ 43.058026] Modules linked in: uhci_hcd ehci_pci ehci_hcd usbcore
3c59x i2c_piix4 i2c_core mii usb_common autofs4
[ 43.058026] CPU: 0 PID: 1 Comm: systemd Not tainted
4.14.0.bisect-4.k5-tsc-desktop+ #168
[ 43.058026] Hardware name: AX5TC/AX5TC, BIOS 4.51 PG 03/23/98
[ 43.058026] task: c00177c0 task.stack: c0032000
[ 43.058026] EIP: free_used_maps+0xe/0x2a
[ 43.058026] EFLAGS: 00010246 CPU: 0
[ 43.058026] EAX: 00000000 EBX: 00000000 ECX: cfdf60b0 EDX: cff95274
[ 43.058026] ESI: 00000000 EDI: 00000008 EBP: c0033e50 ESP: c0033e48
[ 43.058026] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[ 43.058026] CR0: 80050033 CR2: 00000004 CR3: 0034b000 CR4: 00000010
[ 43.058026] Call Trace:
[ 43.058026] bpf_prog_load+0x3ce/0x442
[ 43.058026] ? bpf_prog_array_alloc+0x1b/0x24
[ 43.058026] ? bpf_prog_array_alloc+0x1b/0x24
[ 43.058026] ? compute_effective_progs+0x5c/0xb7
[ 43.058026] ? css_next_descendant_pre+0xa/0x43
[ 43.058026] ? cap_capable+0xa/0x5d
[ 43.058026] ? security_capable+0x2d/0x40
[ 43.058026] ? __copy_from_user_ll_nocache_nozero+0xb/0x37
[ 43.058026] ? __copy_user_ll+0xd/0xf
[ 43.058026] ? security_bpf+0xc/0x3b
[ 43.058026] SyS_bpf+0x7f7/0xd79
[ 43.058026] ? __rcu_read_unlock+0x9/0x4b
[ 43.058026] ? mntput_no_expire+0x28/0x119
[ 43.058026] do_int80_syscall_32+0x45/0x57
[ 43.058026] ? do_int80_syscall_32+0x45/0x57
[ 43.058026] entry_INT80_32+0x27/0x27
[ 43.058026] EIP: 0xb7a95082
[ 43.058026] EFLAGS: 00000246 CPU: 0
[ 43.058026] EAX: ffffffda EBX: 00000005 ECX: bfe76e40 EDX: 00000048
[ 43.058026] ESI: 00000040 EDI: 00000000 EBP: 00a8a458 ESP: bfe76e0c
[ 43.058026] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[ 43.058026] Code: 89 43 30 89 43 34 c7 43 38 40 8c 07 c1 8d 4b 2c
b8 01 00 00 00 e8 7b d4 fa ff 5b 5d c3 55 89 e5 56 53 e8 e4 6d f9 ff
31 db 89 c6 <39> 5e 04 8b 46 38 76 0b 8b 04 98 43 e8 9b ff ff ff eb ed
e8 5b
[ 43.058026] EIP: free_used_maps+0xe/0x2a SS:ESP: 0068:c0033e48
[ 43.058026] CR2: 0000000000000004
[ 43.070394] ---[ end trace 76c4354246d4bc3b ]---
[ 43.154492] systemd: 35 output lines suppressed due to ratelimiting
[ 43.172970] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000009
[ 43.172970]
[ 43.174034] Kernel Offset: disabled
[ 43.174034] Rebooting in 45 seconds..
^ permalink raw reply
* Re: [PATCH iproute2] ipmaddr: use preferred_family when given
From: Mahesh Bandewar (महेश बंडेवार) @ 2018-08-17 17:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Mahesh Bandewar, netdev
In-Reply-To: <20180817092952.5f79903f@xeon-e3>
On Fri, Aug 17, 2018 at 9:29 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Wed, 15 Aug 2018 16:08:55 -0700
> Mahesh Bandewar <mahesh@bandewar.net> wrote:
>
>> From: Mahesh Bandewar <maheshb@google.com>
>>
>> When creating socket() AF_INET is used irrespective of the family
>> that is given at the command-line (with -4, -6, or -0). This change
>> will open the socket with the preferred family.
>>
>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>> ---
>> ip/ipmaddr.c | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> What is impact of this? Does ip multicast address changes not work on IPv6?
> Or is it just doing the right thing?
Essentially a no-op. Just doing the right thing. :)
^ permalink raw reply
* Re: [PATCH iproute2-next] iproute_lwtunnel: allow specifying 'src' for 'encap ip' / 'encap ip6'
From: Shmulik Ladkani @ 2018-08-17 17:37 UTC (permalink / raw)
To: Stephen Hemminger, Shmulik Ladkani; +Cc: dsahern, netdev
In-Reply-To: <20180817080022.18e9992d@xeon-e3>
Hi,
On Fri, 17 Aug 2018 08:00:22 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:
> If you accept an attribute on input you need to parse it and display it the
> same way in the show command.
Note print_encap_ip and print_encap_ip6 already handle LWTUNNEL_IP_SRC
and LWTUNNEL_IP6_SRC (since long ago, 1e5293056 and d95cdcf52).
The only missing part is treatment in parse_encap_ip and
parse_encap_ip6, as suggested by this patch.
Best,
Shmulik
^ 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