* [PATCH net-next] r8169: add missing Kconfig dependency
From: Heiner Kallweit @ 2018-08-17 18:42 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers
Cc: netdev@vger.kernel.org, Florian Fainelli
Now that we switched the r8169 driver to use phylib, there's a
dependency on the Realtek PHY drivers. This dependency was missing
in Kconfig.
Reported-by: Jouni Mettälä <jtmettala@gmail.com>
Fixes: f1e911d5d0df ("r8169: add basic phylib support")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/realtek/Kconfig b/drivers/net/ethernet/realtek/Kconfig
index e1cd934c2..96d1b9c08 100644
--- a/drivers/net/ethernet/realtek/Kconfig
+++ b/drivers/net/ethernet/realtek/Kconfig
@@ -100,6 +100,7 @@ config R8169
select FW_LOADER
select CRC32
select PHYLIB
+ select REALTEK_PHY
---help---
Say Y here if you have a Realtek 8169 PCI Gigabit Ethernet adapter.
--
2.18.0
^ permalink raw reply related
* [PATCH] sunrpc: Don't use stack buffer with scatterlist
From: Laura Abbott @ 2018-08-17 21:43 UTC (permalink / raw)
To: J. Bruce Fields, Jeff Layton, Trond Myklebust, Anna Schumaker
Cc: Laura Abbott, David S. Miller, linux-nfs, netdev, linux-kernel
Fedora got a bug report from NFS:
kernel BUG at include/linux/scatterlist.h:143!
...
RIP: 0010:sg_init_one+0x7d/0x90
..
make_checksum+0x4e7/0x760 [rpcsec_gss_krb5]
gss_get_mic_kerberos+0x26e/0x310 [rpcsec_gss_krb5]
gss_marshal+0x126/0x1a0 [auth_rpcgss]
? __local_bh_enable_ip+0x80/0xe0
? call_transmit_status+0x1d0/0x1d0 [sunrpc]
call_transmit+0x137/0x230 [sunrpc]
__rpc_execute+0x9b/0x490 [sunrpc]
rpc_run_task+0x119/0x150 [sunrpc]
nfs4_run_exchange_id+0x1bd/0x250 [nfsv4]
_nfs4_proc_exchange_id+0x2d/0x490 [nfsv4]
nfs41_discover_server_trunking+0x1c/0xa0 [nfsv4]
nfs4_discover_server_trunking+0x80/0x270 [nfsv4]
nfs4_init_client+0x16e/0x240 [nfsv4]
? nfs_get_client+0x4c9/0x5d0 [nfs]
? _raw_spin_unlock+0x24/0x30
? nfs_get_client+0x4c9/0x5d0 [nfs]
nfs4_set_client+0xb2/0x100 [nfsv4]
nfs4_create_server+0xff/0x290 [nfsv4]
nfs4_remote_mount+0x28/0x50 [nfsv4]
mount_fs+0x3b/0x16a
vfs_kern_mount.part.35+0x54/0x160
nfs_do_root_mount+0x7f/0xc0 [nfsv4]
nfs4_try_mount+0x43/0x70 [nfsv4]
? get_nfs_version+0x21/0x80 [nfs]
nfs_fs_mount+0x789/0xbf0 [nfs]
? pcpu_alloc+0x6ca/0x7e0
? nfs_clone_super+0x70/0x70 [nfs]
? nfs_parse_mount_options+0xb40/0xb40 [nfs]
mount_fs+0x3b/0x16a
vfs_kern_mount.part.35+0x54/0x160
do_mount+0x1fd/0xd50
ksys_mount+0xba/0xd0
__x64_sys_mount+0x21/0x30
do_syscall_64+0x60/0x1f0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
This is BUG_ON(!virt_addr_valid(buf)) triggered by using a stack
allocated buffer with a scatterlist. Convert the buffer for
rc4salt to be dynamically allocated instead.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1615258
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
Compile tested only.
---
net/sunrpc/auth_gss/gss_krb5_crypto.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c b/net/sunrpc/auth_gss/gss_krb5_crypto.c
index 8654494b4d0a..834eb2b9e41b 100644
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
+++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -169,7 +169,7 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
struct scatterlist sg[1];
int err = -1;
u8 *checksumdata;
- u8 rc4salt[4];
+ u8 *rc4salt;
struct crypto_ahash *md5;
struct crypto_ahash *hmac_md5;
struct ahash_request *req;
@@ -183,14 +183,18 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
return GSS_S_FAILURE;
}
+ rc4salt = kmalloc_array(4, sizeof(*rc4salt), GFP_NOFS);
+ if (!rc4salt)
+ return GSS_S_FAILURE;
+
if (arcfour_hmac_md5_usage_to_salt(usage, rc4salt)) {
dprintk("%s: invalid usage value %u\n", __func__, usage);
- return GSS_S_FAILURE;
+ goto out_free_rc4salt;
}
checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_NOFS);
if (!checksumdata)
- return GSS_S_FAILURE;
+ goto out_free_rc4salt;
md5 = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(md5))
@@ -258,6 +262,8 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
crypto_free_ahash(md5);
out_free_cksum:
kfree(checksumdata);
+out_free_rc4salt:
+ kfree(rc4salt);
return err ? GSS_S_FAILURE : 0;
}
--
2.17.1
^ permalink raw reply related
* Re: [GIT PULL] 9p updates for 4.19
From: Dominique Martinet @ 2018-08-17 21:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: V9FS Developers, Linux Kernel Mailing List, Network Development
In-Reply-To: <CA+55aFzLe7C03-53=0WrXXfZcfsJfTsvRqrrBNqnLvOxUiCJqQ@mail.gmail.com>
Linus Torvalds wrote on Fri, Aug 17, 2018:
> So this pull request confuses me, and that's not a good thing.
I'll hopefully do better next time! Thank you for taking the time to
explain.
> 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.
I thought the the same thing (that you never saw the first version) when
I wrote the request-pull email and adjusted the text -- I wasn't aware
the tag should have the same text as the mail but will pay attention to
that in the future, it does make sense.
For the background, I had used 9p-for-4.19 in a mail to v9fs-developer
asking for testing earlier this week, it is still in the repo as another
signed tag if you'd like to confirm.
I removed the "MAINTAINERS patches" when Andrew picked them up shortly
after the original mail and made the second tag back then.
> 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 agree on this point, and will have a different key with at least some
kernel developers signatures for 4.20 (which will be confusing again as
my key changes, but at least it shold have people you recognize).
I cannot say anything other than "I was not sufficiently prepared" for
4.19 and used whatever key I normally use after checking on pathfinder
that it was still "closeish" to you.
On the maintainership update, while it wasn't direct I believe Andrew
brought it up when adding me to the Cc of a 9p security report after you
added the current maintainers recently -- but, well, yes, it's not like
being told directly.
He has the MAINTAINER file update and am sure will send it to you
shortly so if preferable I can wait until he sends them to you and send
this PR (with a better tag) again at this point?
Thank you,
--
Dominique Martinet
^ permalink raw reply
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Daniel Borkmann @ 2018-08-17 18:30 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Peter Robinson, Marc Haber, linux-arm-kernel, netdev, labbott,
Eric Dumazet
In-Reply-To: <20180817161743.GX30658@n2100.armlinux.org.uk>
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.
Thanks,
Daniel
^ permalink raw reply
* Re: [regression] r8169 without realtek_phy
From: Heiner Kallweit @ 2018-08-17 18:16 UTC (permalink / raw)
To: Florian Fainelli, Jouni Mettälä, netdev
In-Reply-To: <97ad7aae-34f5-a1bc-7131-81eaeea4f4dd@gmail.com>
On 17.08.2018 19:39, Florian Fainelli wrote:
> +Heiner,
>
> On 08/17/2018 01:33 AM, Jouni Mettälä wrote:
>> There is network regression for me. 4.18 was good. 4.18+ is bad. There
>> was some phy changes in r8169 driver. Fortunately adding
>> CONFIG_REALTEK_PHY=m to kernel config fixed the regression.
>>
>> Should r8169 depend on realtek_phy? Does that breaks something else?
>
> That would be reasonable given that there is now a hard dependency on
> the r8169 driver having the right PHY driver, since the Generic PHY
> driver likely wont' do all the workarounds. Heiner, what do you think?
>
Good catch, indeed we need a Kconfig dependency now. I missed this
because I had Realtek PHY support enabled anyway. I will submit a
fix adding this dependency.
Heiner
>
>> Network doesn't work with Generic PHY (output of dmesg)
>> Generic PHY r8169-300:00: attached PHY driver [Generic PHY]
>> (mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
>>
>> When realtek_phy is compiled, r8169 automatically uses it.
>> RTL8211B Gigabit Ethernet r8169-300:00: attached PHY driver [RTL8211B
>> Gigabit Ethernet] (mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
>>
>> Here is Ethernet controller's lspci for reference:
>> 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168]
>> (rev 01)
>> Subsystem: ABIT Computer Corp. RTL8111/8168/8411 PCI Express
>> Gigabit Ethernet Controller [147b:1078]
>> Flags: bus master, fast devsel, latency 0, IRQ 27
>> I/O ports at ce00 [size=256]
>> Memory at fddff000 (64-bit, non-prefetchable) [size=4K]
>> [virtual] Expansion ROM at fdd00000 [disabled] [size=64K]
>> Capabilities: [40] Power Management version 2
>> Capabilities: [48] Vital Product Data
>> Capabilities: [50] MSI: Enable+ Count=1/2 Maskable- 64bit+
>> Capabilities: [60] Express Endpoint, MSI 00
>> Capabilities: [84] Vendor Specific Information: Len=4c <?>
>> Capabilities: [100] Advanced Error Reporting
>> Capabilities: [12c] Virtual Channel
>> Capabilities: [148] Device Serial Number 28-00-00-00-00-00-00-
>> 00
>> Capabilities: [154] Power Budgeting <?>
>> Kernel driver in use: r8169
>> Kernel modules: r8169
>>
>
>
^ permalink raw reply
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: David Ahern @ 2018-08-17 21:15 UTC (permalink / raw)
To: Jason Wang, Jesper Dangaard Brouer
Cc: Alexei Starovoitov, netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <2792239a-ed3b-d66e-0c1c-e99455311eff@redhat.com>
On 8/15/18 9:34 PM, Jason Wang wrote:
> I may miss something but BPF forbids loop. Without a loop how can we
> make sure all stacked devices is enumerated correctly without knowing
> the topology in advance?
netdev_for_each_upper_dev_rcu
BPF helpers allow programs to do lookups in kernel tables, in this case
the ability to find an upper device that would receive the packet.
^ 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 18:09 UTC (permalink / raw)
To: Ganesh Goudar; +Cc: Rahul Lakkireddy, David Miller, netdev@vger.kernel.org
In-Reply-To: <20180817154320.GD6515@ZenIV.linux.org.uk>
On Fri, Aug 17, 2018 at 04:43:20PM +0100, Al Viro wrote:
> 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
... and updated for some of today's catch (== stuff caught while finding the
reply). Another very likely bug hidden by force-casts: in t4_fwcache()
you put host-endian 0 or 1 into __be32 field, hiding that by force-cast.
Then feed that to hardware, which, judging by everything else nearby
expects big-endian there. The only reason it works, AFAICS, is that you
only pass it FW_PARAM_DEV_FWCACHE_FLUSH (== 0); as soon as you get
a caller passing FW_PARAM_DEV_FWCACHE_FLUSHINV, you'll get breakage.
And frankly, comments like
while (count) {
/* the (__force u64) is because the compiler
* doesn't understand the endian swizzling
* going on
*/
writeq((__force u64)*src, dst);
src++;
dst++;
count--;
}
are more than slightly terrifying - piss on compiler, what about reviewers? And
the authors themselves, for that matter... FWIW, see the dmr's comments on
"you are not expected to understand that" story (bell labs site is buggered,
but wayback machine has it on
https://web.archive.org/web/20140724213028/http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)
Especially the "The real problem is that we didn't understand what was going on either"
part...
Re that code - are you sure it doesn't need le64_to_cpu(*src)? Because from what
I understand about PCI (which matches just fine to the comments in the same driver),
you probably do need that. Again, the only real way to find out is to test on
big-endian host...
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: document WoL filters option also in help message
From: Florian Fainelli @ 2018-08-17 17:51 UTC (permalink / raw)
To: Michal Kubecek, John W. Linville; +Cc: netdev
In-Reply-To: <20180817132107.BF630A0A86@unicorn.suse.cz>
On 08/17/2018 06:21 AM, Michal Kubecek wrote:
> 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>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks Michal!
--
Florian
^ permalink raw reply
* Re: [regression] r8169 without realtek_phy
From: Florian Fainelli @ 2018-08-17 17:39 UTC (permalink / raw)
To: Jouni Mettälä, netdev, hkallweit1
In-Reply-To: <9fde169119652baae87d6a0f40e0ccd70e428ea8.camel@gmail.com>
+Heiner,
On 08/17/2018 01:33 AM, Jouni Mettälä wrote:
> There is network regression for me. 4.18 was good. 4.18+ is bad. There
> was some phy changes in r8169 driver. Fortunately adding
> CONFIG_REALTEK_PHY=m to kernel config fixed the regression.
>
> Should r8169 depend on realtek_phy? Does that breaks something else?
That would be reasonable given that there is now a hard dependency on
the r8169 driver having the right PHY driver, since the Generic PHY
driver likely wont' do all the workarounds. Heiner, what do you think?
>
> Network doesn't work with Generic PHY (output of dmesg)
> Generic PHY r8169-300:00: attached PHY driver [Generic PHY]
> (mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
>
> When realtek_phy is compiled, r8169 automatically uses it.
> RTL8211B Gigabit Ethernet r8169-300:00: attached PHY driver [RTL8211B
> Gigabit Ethernet] (mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
>
> Here is Ethernet controller's lspci for reference:
> 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168]
> (rev 01)
> Subsystem: ABIT Computer Corp. RTL8111/8168/8411 PCI Express
> Gigabit Ethernet Controller [147b:1078]
> Flags: bus master, fast devsel, latency 0, IRQ 27
> I/O ports at ce00 [size=256]
> Memory at fddff000 (64-bit, non-prefetchable) [size=4K]
> [virtual] Expansion ROM at fdd00000 [disabled] [size=64K]
> Capabilities: [40] Power Management version 2
> Capabilities: [48] Vital Product Data
> Capabilities: [50] MSI: Enable+ Count=1/2 Maskable- 64bit+
> Capabilities: [60] Express Endpoint, MSI 00
> Capabilities: [84] Vendor Specific Information: Len=4c <?>
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [12c] Virtual Channel
> Capabilities: [148] Device Serial Number 28-00-00-00-00-00-00-
> 00
> Capabilities: [154] Power Budgeting <?>
> Kernel driver in use: r8169
> Kernel modules: r8169
>
--
Florian
^ 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
* 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
* 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
* [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
* [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
* 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
* 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: [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: 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: 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: [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: [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: [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: [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
* [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
* 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
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