* Re: KASAN: slab-out-of-bounds Write in validate_chain
From: John Fastabend @ 2019-06-26 22:24 UTC (permalink / raw)
To: Eric Biggers, John Fastabend
Cc: syzbot, akpm, ast, cai, crecklin, daniel, keescook, linux-kernel,
linux-mm, netdev, bpf, syzkaller-bugs
In-Reply-To: <20190625234808.GB116876@gmail.com>
Eric Biggers wrote:
> Hi John,
>
> On Tue, Jun 25, 2019 at 04:07:00PM -0700, syzbot wrote:
> > syzbot has bisected this bug to:
> >
> > commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
> > Author: John Fastabend <john.fastabend@gmail.com>
> > Date: Sat Jun 30 13:17:47 2018 +0000
> >
> > bpf: sockhash fix omitted bucket lock in sock_close
> >
>
> Are you working on this? This is the 6th open syzbot report that has been
> bisected to this commit, and I suspect it's the cause of many of the other
> 30 open syzbot reports I assigned to the bpf subsystem too
> (https://lore.kernel.org/bpf/20190624050114.GA30702@sol.localdomain/).
>
> Also, this is happening in mainline (v5.2-rc6).
>
> - Eric
Should have a fix today. It seems syzbot has found this bug repeatedly.
.John
^ permalink raw reply
* Re: [PATCH v2 bpf-next 3/7] libbpf: add kprobe/uprobe attach API
From: Andrii Nakryiko @ 2019-06-26 22:15 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Andrii Nakryiko, Alexei Starovoitov, Stanislav Fomichev, bpf,
Networking, Kernel Team
In-Reply-To: <a7780057-1d70-9ace-960b-ff65867dc277@iogearbox.net>
On Wed, Jun 26, 2019 at 7:25 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 06/21/2019 06:55 AM, Andrii Nakryiko wrote:
> > Add ability to attach to kernel and user probes and retprobes.
> > Implementation depends on perf event support for kprobes/uprobes.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
<snip>
> > +}
>
> I do like that we facilitate usage by adding these APIs to libbpf, but my $0.02
> would be that they should be designed slightly different. See it as a nit, but
> given it's exposed in libbpf.map and therefore immutable in future it's worth
> considering; right now with this set here you have:
>
> int bpf_program__attach_kprobe(struct bpf_program *prog, bool retprobe,
> const char *func_name)
> int bpf_program__attach_uprobe(struct bpf_program *prog, bool retprobe,
> pid_t pid, const char *binary_path,
> size_t func_offset)
> int bpf_program__attach_tracepoint(struct bpf_program *prog,
> const char *tp_category,
> const char *tp_name)
> int bpf_program__attach_raw_tracepoint(struct bpf_program *prog,
> const char *tp_name)
> int bpf_program__attach_perf_event(struct bpf_program *prog, int pfd)
> int libbpf_perf_event_disable_and_close(int pfd)
>
> So the idea is that all the bpf_program__attach_*() APIs return an fd that you
> can later on pass into libbpf_perf_event_disable_and_close(). I think there is
> a bit of a disconnect in that the bpf_program__attach_*() APIs try to do too
> many things at once. For example, the bpf_program__attach_raw_tracepoint() fd
> has nothing to do with perf, so passing to libbpf_perf_event_disable_and_close()
> kind of works, but is hacky since there's no PERF_EVENT_IOC_DISABLE for it so this
> would always error if a user cares to check the return code. In the kernel, we
Yeah, you are absolutely right, missed that it's not creating perf
event under cover, to be honest.
> use anon inode for this kind of object. Also, if a user tries to add more than
> one program to the same event, we need to recreate a new event fd every time.
>
> What this boils down to is that this should get a proper abstraction, e.g. as
> in struct libbpf_event which holds the event object. There should be helper
> functions like libbpf_event_create_{kprobe,uprobe,tracepoint,raw_tracepoint} returning
> such an struct libbpf_event object on success, and a single libbpf_event_destroy()
> that does the event specific teardown. bpf_program__attach_event() can then take
> care of only attaching the program to it. Having an object for this is also more
> extensible than just a fd number. Nice thing is that this can also be completely
> internal to libbpf.c as with struct bpf_program and other abstractions where we
> don't expose the internals in the public header.
Yeah, I totally agree, I think this is a great idea! I don't
particularly like "event" name, that seems very overloaded term. Do
you mind if I call this "bpf_hook" instead of "libbpf_event"? I've
always thought about these different points in the system to which one
can attach BPF program as hooks exposed from kernel :)
Would it also make sense to do attaching to non-tracing hooks using
the same mechanism (e.g., all the per-cgroup stuff, sysctl, etc)? Not
sure how people do that today, will check to see how it's done, but I
think nothing should conceptually prevent doing that using the same
abstract bpf_hook way, right?
>
> Thanks,
> Daniel
^ permalink raw reply
* Re: linux-next: Fixes tag needs some work in the bpf tree
From: Roman Gushchin @ 2019-06-26 22:13 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, Stephen Rothwell, Networking,
Linux Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20190627080521.5df8ccfc@canb.auug.org.au>
On Thu, Jun 27, 2019 at 08:05:21AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 12771345a467 ("bpf: fix cgroup bpf release synchronization")
>
> Fixes tag
>
> Fixes: 4bfc0bb2c60e ("bpf: decouple the lifetime of cgroup_bpf from
>
> has these problem(s):
>
> - Subject has leading but no trailing parentheses
> - Subject has leading but no trailing quotes
>
> Please don't split Fixes tags across more than one line.
Oops, sorry.
Alexei, can you fix this in place?
Or should I send an updated version?
Thanks.
^ permalink raw reply
* linux-next: Fixes tag needs some work in the bpf tree
From: Stephen Rothwell @ 2019-06-26 22:05 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Roman Gushchin
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
Hi all,
In commit
12771345a467 ("bpf: fix cgroup bpf release synchronization")
Fixes tag
Fixes: 4bfc0bb2c60e ("bpf: decouple the lifetime of cgroup_bpf from
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
Please don't split Fixes tags across more than one line.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] can: dev: call netif_carrier_off() in register_candev()
From: Rasmus Villemoes @ 2019-06-26 21:19 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAF=yD-KyWJwdESFmY=CvbkTBT8yey2atKDY-tgd19yAeMf525g@mail.gmail.com>
On 26/06/2019 16.17, Willem de Bruijn wrote:
> On Wed, Jun 26, 2019 at 5:31 AM Rasmus Villemoes
> <rasmus.villemoes@prevas.dk> wrote:
>>
>> On 24/06/2019 19.26, Willem de Bruijn wrote:
>>> On Mon, Jun 24, 2019 at 4:34 AM Rasmus Villemoes
>>> <rasmus.villemoes@prevas.dk> wrote:
>>>>
>>>> Make sure the LED always reflects the state of the CAN device.
>>>
>>> Should this target net?
>>
>> No, I think this should go through the CAN tree. Perhaps I've
>> misunderstood when to use the net-next prefix - is that only for things
>> that should be applied directly to the net-next tree? If so, sorry.
>
> I don't see consistent behavior on the list, so this is probably fine.
> It would probably help to target can (for fixes) or can-next (for new
> features).
>
> Let me reframe the question: should this target can, instead of can-next?
Ah, now I see what you meant, but at least I learned when to use
net/net-next.
I think can-next is fine, especially this late in the rc cycle. But I'll
leave it to the CAN maintainer(s).
>>> Regardless of CONFIG_CAN_LEDS deprecation,
>>> this is already not initialized properly if that CONFIG is disabled
>>> and a can_led_event call at device probe is a noop.
>>
>> I'm not sure I understand this part. The CONFIG_CAN_LEDS support for
>> showing the state of the interface is implemented via hooking into the
>> ndo_open/ndo_stop callbacks, and does not look at or touch the
>> __LINK_STATE_NOCARRIER bit at all.
>>
>> Other than via the netdev LED trigger I don't think one can even observe
>> the slightly odd initial state of the __LINK_STATE_NOCARRIER bit for CAN
>> devices,
>
> it's still incorrect, though I guess that's moot in practice.
Exactly.
>> which is why I framed this as a fix purely to allow the netdev
>> trigger to be a closer drop-in replacement for CONFIG_CAN_LEDS.
>
> So the entire CONFIG_CAN_LEDS code is to be removed? What exactly is
> this netdev trigger replacement, if not can_led_event? Sorry, I
> probably miss some context.
drivers/net/can/Kconfig contains these comments
# The netdev trigger (LEDS_TRIGGER_NETDEV) should be able to do
# everything that this driver is doing. This is marked as broken
# because it uses stuff that is intended to be changed or removed.
# Please consider switching to the netdev trigger and confirm it
# fulfills your needs instead of fixing this driver.
introduced by the commit 30f3b42147ba6 which also marked CONFIG_CAN_LEDS
as (depends on) BROKEN. So while a .dts for using the CAN led trigger
might be
cana {
label = "cana:green:activity";
gpios = <&gpio0 10 0>;
default-state = "off";
linux,default-trigger = "can0-rxtx";
};
one can achieve mostly the same thing with CAN_LEDS=n,
LEDS_TRIGGER_NETDEV=y setting linux,default-trigger = "netdev" plus a
small init script (or udev rule or whatever works) that does
d=/sys/class/leds/cana:green:activity
echo can0 > $d/device_name
echo 1 > $d/link
echo 1 > $d/rx
echo 1 > $d/tx
to tie the cana LED to the can0 device, plus configure it to show "link"
state as well as blink on rx and tx.
This works just fine, except for the initial state of the LED. AFAIU,
the netdev trigger doesn't need cooperation from each device driver
since it simply works of a timer that periodically checks for changes in
dev_get_stats().
Rasmus
^ permalink raw reply
* Re: [PATCH net] net/sched: flower: fix infinite loop in fl_walk()
From: Cong Wang @ 2019-06-26 21:15 UTC (permalink / raw)
To: Davide Caratti
Cc: Vlad Buslov, David S. Miller, Linux Kernel Network Developers,
Lucas Bates
In-Reply-To: <CAM_iQpXj1A05FdbD93iWQp9Tcd6aW0BQ3_xFx8bNEbqA00RGAg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
Hi, Davide
On Tue, Jun 25, 2019 at 12:29 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> It should handle this overflow case more gracefully, I hope.
>
Please try this attached one and let me know if it works.
Hope I get it right this time.
Thanks!
[-- Attachment #2: idr_get_next_ul.patch --]
[-- Type: application/octet-stream, Size: 4956 bytes --]
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
index c6c28f56aa29..b080e6f3488d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
@@ -102,13 +102,15 @@ static struct list_head *mlx5_fc_counters_lookup_next(struct mlx5_core_dev *dev,
struct mlx5_fc_stats *fc_stats = &dev->priv.fc_stats;
unsigned long next_id = (unsigned long)id + 1;
struct mlx5_fc *counter;
+ unsigned long tmp;
rcu_read_lock();
/* skip counters that are in idr, but not yet in counters list */
- while ((counter = idr_get_next_ul(&fc_stats->counters_idr,
- &next_id)) != NULL &&
- list_empty(&counter->list))
- next_id++;
+ idr_for_each_entry_continue_ul(&fc_stats->counters_idr,
+ counter, tmp, next_id) {
+ if (list_empty(&counter->list))
+ continue;
+ }
rcu_read_unlock();
return counter ? &counter->list : &fc_stats->counters;
diff --git a/include/linux/idr.h b/include/linux/idr.h
index ee7abae143d3..4ec8986e5dfb 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -191,14 +191,17 @@ static inline void idr_preload_end(void)
* idr_for_each_entry_ul() - Iterate over an IDR's elements of a given type.
* @idr: IDR handle.
* @entry: The type * to use as cursor.
+ * @tmp: A temporary placeholder for ID.
* @id: Entry ID.
*
* @entry and @id do not need to be initialized before the loop, and
* after normal termination @entry is left with the value NULL. This
* is convenient for a "not found" value.
*/
-#define idr_for_each_entry_ul(idr, entry, id) \
- for (id = 0; ((entry) = idr_get_next_ul(idr, &(id))) != NULL; ++id)
+#define idr_for_each_entry_ul(idr, entry, tmp, id) \
+ for (tmp = 0, id = 0; \
+ tmp <= id && ((entry) = idr_get_next_ul(idr, &(id))) != NULL; \
+ tmp = id, ++id)
/**
* idr_for_each_entry_continue() - Continue iteration over an IDR's elements of a given type
@@ -213,6 +216,20 @@ static inline void idr_preload_end(void)
entry; \
++id, (entry) = idr_get_next((idr), &(id)))
+/**
+ * idr_for_each_entry_continue_ul() - Continue iteration over an IDR's elements of a given type
+ * @idr: IDR handle.
+ * @entry: The type * to use as a cursor.
+ * @tmp: A temporary placeholder for ID.
+ * @id: Entry ID.
+ *
+ * Continue to iterate over entries, continuing after the current position.
+ */
+#define idr_for_each_entry_continue_ul(idr, entry, tmp, id) \
+ for (tmp = id; \
+ tmp <= id && ((entry) = idr_get_next_ul(idr, &(id))) != NULL; \
+ tmp = id, ++id)
+
/*
* IDA - ID Allocator, use when translation from id to pointer isn't necessary.
*/
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 5567af5d7cb5..835adde28a7e 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -221,12 +221,13 @@ static int tcf_dump_walker(struct tcf_idrinfo *idrinfo, struct sk_buff *skb,
struct idr *idr = &idrinfo->action_idr;
struct tc_action *p;
unsigned long id = 1;
+ unsigned long tmp;
mutex_lock(&idrinfo->lock);
s_i = cb->args[0];
- idr_for_each_entry_ul(idr, p, id) {
+ idr_for_each_entry_ul(idr, p, tmp, id) {
index++;
if (index < s_i)
continue;
@@ -292,6 +293,7 @@ static int tcf_del_walker(struct tcf_idrinfo *idrinfo, struct sk_buff *skb,
struct idr *idr = &idrinfo->action_idr;
struct tc_action *p;
unsigned long id = 1;
+ unsigned long tmp;
nest = nla_nest_start_noflag(skb, 0);
if (nest == NULL)
@@ -300,7 +302,7 @@ static int tcf_del_walker(struct tcf_idrinfo *idrinfo, struct sk_buff *skb,
goto nla_put_failure;
mutex_lock(&idrinfo->lock);
- idr_for_each_entry_ul(idr, p, id) {
+ idr_for_each_entry_ul(idr, p, tmp, id) {
ret = tcf_idr_release_unsafe(p);
if (ret == ACT_P_DELETED) {
module_put(ops->owner);
@@ -533,8 +535,9 @@ void tcf_idrinfo_destroy(const struct tc_action_ops *ops,
struct tc_action *p;
int ret;
unsigned long id = 1;
+ unsigned long tmp;
- idr_for_each_entry_ul(idr, p, id) {
+ idr_for_each_entry_ul(idr, p, tmp, id) {
ret = __tcf_idr_release(p, false, true);
if (ret == ACT_P_DELETED)
module_put(ops->owner);
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index eedd5786c084..01c361eb16a2 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -528,17 +528,19 @@ static struct cls_fl_filter *fl_get_next_filter(struct tcf_proto *tp,
unsigned long *handle)
{
struct cls_fl_head *head = fl_head_dereference(tp);
+ unsigned long id = *handle;
struct cls_fl_filter *f;
+ unsigned long tmp;
rcu_read_lock();
- while ((f = idr_get_next_ul(&head->handle_idr, handle))) {
+ idr_for_each_entry_continue_ul(&head->handle_idr, f, tmp, id) {
/* don't return filters that are being deleted */
if (refcount_inc_not_zero(&f->refcnt))
break;
- ++(*handle);
}
rcu_read_unlock();
+ *handle = id;
return f;
}
^ permalink raw reply related
* Re: net: macb: Fix compilation on systems without COMMON_CLK, v2
From: David Miller @ 2019-06-26 21:09 UTC (permalink / raw)
To: palmer; +Cc: nicolas.ferre, harinik, netdev, linux-kernel
In-Reply-To: <20190625084828.540-1-palmer@sifive.com>
From: Palmer Dabbelt <palmer@sifive.com>
Date: Tue, 25 Jun 2019 01:48:26 -0700
> Our patch to add support for the FU540-C000 broke compilation on at
> least powerpc allyesconfig, which was found as part of the linux-next
> build regression tests. This must have somehow slipped through the
> cracks, as the patch has been reverted in linux-next for a while now.
> This patch applies on top of the offending commit, which is the only one
> I've even tried it on as I'm not sure how this subsystem makes it to
> Linus.
>
> This patch set fixes the issue by adding a dependency of COMMON_CLK to
> the MACB Kconfig entry, which avoids the build failure by disabling MACB
> on systems where it wouldn't compile. All known users of MACB have
> COMMON_CLK, so this shouldn't cause any issues. This is a significantly
> simpler approach than disabling just the FU540-C000 support.
>
> I've also included a second patch to indicate this is a driver for a
> Cadence device that was originally written by an engineer at Atmel. The
> only relation is that I stumbled across it when writing the first patch.
>
> Changes since v1 <20190624061603.1704-1-palmer@sifive.com>:
>
> * Disable MACB on systems without COMMON_CLK, instead of just disabling
> the FU540-C000 support on these systems.
> * Update the commit message to reflect the driver was written by Atmel.
Series applied, thanks.
^ permalink raw reply
* Re: INFO: rcu detected stall in ext4_write_checks
From: Theodore Ts'o @ 2019-06-26 21:03 UTC (permalink / raw)
To: syzbot, adilger.kernel, davem, eladr, idosch, jiri, john.stultz,
linux-ext4, linux-kernel, netdev, syzkaller-bugs, tglx
In-Reply-To: <20190626184251.GE3116@mit.edu>
The reproducer causes similar rcu stalls when using xfs:
RSP: 0018:ffffaae8c0953c58 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000288 RBX: 000000000000b05a RCX: ffffaae8c0953d50
RDX: 000000000000001c RSI: 000000000000001c RDI: ffffdcec41772800
RBP: ffffdcec41772800 R08: 00000015143ceae3 R09: 0000000000000001
R10: 0000000000000000 R11: ffffffff96863980 R12: ffff88d179ac7d80
R13: ffff88d174837ca0 R14: 0000000000000288 R15: 000000000000001c
generic_file_buffered_read+0x2c1/0x8b0
xfs_file_buffered_aio_read+0x5f/0x140
xfs_file_read_iter+0x6e/0xd0
generic_file_splice_read+0x110/0x1d0
splice_direct_to_actor+0xd5/0x230
? pipe_to_sendpage+0x90/0x90
do_splice_direct+0x9f/0xd0
do_sendfile+0x1d4/0x3a0
__se_sys_sendfile64+0x58/0xc0
do_syscall_64+0x50/0x1b0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f8038387469
and btrfs
[ 42.671321] RSP: 0018:ffff960dc0963b90 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
[ 42.673592] RAX: 0000000000000001 RBX: ffff89eb3628ab30 RCX: 00000000ffffffff
[ 42.675775] RDX: ffff89eb3628a380 RSI: 00000000ffffffff RDI: ffffffff9ec63980
[ 42.677851] RBP: ffff89eb3628aaf8 R08: 0000000000000001 R09: 0000000000000001
[ 42.680028] R10: 0000000000000000 R11: ffffffff9ec63980 R12: ffff89eb3628a380
[ 42.682213] R13: 0000000000000246 R14: 0000000000000001 R15: ffffffff9ec63980
[ 42.684509] xas_descend+0xed/0x120
[ 42.685682] xas_load+0x39/0x50
[ 42.686691] find_get_entry+0xa0/0x330
[ 42.687885] pagecache_get_page+0x30/0x2d0
[ 42.689190] generic_file_buffered_read+0xee/0x8b0
[ 42.690708] generic_file_splice_read+0x110/0x1d0
[ 42.692374] splice_direct_to_actor+0xd5/0x230
[ 42.693868] ? pipe_to_sendpage+0x90/0x90
[ 42.695180] do_splice_direct+0x9f/0xd0
[ 42.696407] do_sendfile+0x1d4/0x3a0
[ 42.697551] __se_sys_sendfile64+0x58/0xc0
[ 42.698854] do_syscall_64+0x50/0x1b0
[ 42.700021] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 42.701619] RIP: 0033:0x7f21e8d5f469
So this is probably a generic vfs issue (probably in sendfile). Next
steps is probably for someone to do a bisection search covering
changes to the fs/ and mm/ directories. This should exclude bogus
changes in the networking layer, although it does seem that there is
something very badly wrong which is breaking bisectability, if you
can't even scp to the system under test for certain commit ranges. :-( :-( :-(
- Ted
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/3] libbpf: add perf buffer abstraction and API
From: Toke Høiland-Jørgensen @ 2019-06-26 20:50 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann, bpf,
Networking, Kernel Team
In-Reply-To: <CAEf4BzZozWBanXnjJguYT46v8huAS7Wz44MHFHJkAPBZbT-i6A@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Wed, Jun 26, 2019 at 4:55 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Andrii Nakryiko <andriin@fb.com> writes:
>>
>> > This patchset adds a high-level API for setting up and polling perf buffers
>> > associated with BPF_MAP_TYPE_PERF_EVENT_ARRAY map. Details of APIs are
>> > described in corresponding commit.
>> >
>> > Patch #1 adds a set of APIs to set up and work with perf buffer.
>> > Patch #2 enhances libbpf to supprot auto-setting PERF_EVENT_ARRAY map size.
>> > Patch #3 adds test.
>>
>> Having this in libbpf is great! Do you have a usage example of how a
>> program is supposed to read events from the buffer? This is something we
>> would probably want to add to the XDP tutorial
>
> Did you check patch #3 with selftest? It's essentially an end-to-end
> example of how to set everything up and process data (in my case it's
> just simple int being sent as a sample, but it's exactly the same with
> more complicated structs). I didn't bother to handle lost samples
> notification, but it's just another optional callback with a single
> counter denoting how many samples were dropped.
>
> Let me know if it's still unclear.
I did read the example, but I obviously did not grok how it was supposed
to work; re-reading it now it's quite clear, thanks! :)
-Toke
^ permalink raw reply
* Re: [PATCH net-next] xdp: xdp_umem: fix umem pages mapping for 32bits systems
From: Björn Töpel @ 2019-06-26 20:50 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: Björn Töpel, Karlsson, Magnus, David Miller,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Netdev, bpf, Xdp, LKML
In-Reply-To: <20190626155911.13574-1-ivan.khoronzhuk@linaro.org>
On Wed, 26 Jun 2019 at 17:59, Ivan Khoronzhuk
<ivan.khoronzhuk@linaro.org> wrote:
>
> Use kmap instead of page_address as it's not always in low memory.
>
Ah, some 32-bit love. :-) Thanks for working on this!
For future patches, please base AF_XDP patches on the bpf/bpf-next
tree instead of net/net-next.
Acked-by: Björn Töpel <bjorn.topel@intel.com>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
> net/xdp/xdp_umem.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> index 9c6de4f114f8..d3c1411420fd 100644
> --- a/net/xdp/xdp_umem.c
> +++ b/net/xdp/xdp_umem.c
> @@ -169,6 +169,14 @@ static void xdp_umem_clear_dev(struct xdp_umem *umem)
> }
> }
>
> +static void xdp_umem_unmap_pages(struct xdp_umem *umem)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < umem->npgs; i++)
> + kunmap(umem->pgs[i]);
> +}
> +
> static void xdp_umem_unpin_pages(struct xdp_umem *umem)
> {
> unsigned int i;
> @@ -210,6 +218,7 @@ static void xdp_umem_release(struct xdp_umem *umem)
>
> xsk_reuseq_destroy(umem);
>
> + xdp_umem_unmap_pages(umem);
> xdp_umem_unpin_pages(umem);
>
> kfree(umem->pages);
> @@ -372,7 +381,7 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
> }
>
> for (i = 0; i < umem->npgs; i++)
> - umem->pages[i].addr = page_address(umem->pgs[i]);
> + umem->pages[i].addr = kmap(umem->pgs[i]);
>
> return 0;
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: ipv4: remove erroneous advancement of list pointer
From: Florian Westphal @ 2019-06-26 20:37 UTC (permalink / raw)
To: Ran Rozenstein
Cc: Florian Westphal, Tariq Toukan, netdev@vger.kernel.org,
Maor Gottlieb, edumazet@google.com
In-Reply-To: <AM4PR0501MB2769CE8DC11EE4A076B62CCCC5E20@AM4PR0501MB2769.eurprd05.prod.outlook.com>
Ran Rozenstein <ranro@mellanox.com> wrote:
> The test dose stress on the interface by running this 2 commands in loop:
>
> command is: /sbin/ip -f inet addr add $IP/16 brd + dev ens8f1
> command is: ifconfig ens8f1 $IP netmask 255.255.0.0
>
> when $IP change every iteration.
>
> It execute every second when we see the reproduce somewhere between 40 to 200 seconds of execution.
I tried this without success:
DEV=dummy0
for j in $(seq 2 254);do
for i in $(seq 2 254);do
IP="10.$((RANDOM%254)).$((RANDOM%254)).$i"
ip -f inet addr add $IP/16 brd + dev $DEV
ifconfig $DEV $IP netmask 255.255.0.0
done
done
I'll let this loop overnight, but so far nothing turned up in
dmesg (lockdep/kasan kernel).
^ permalink raw reply
* Re: [PATCH bpf-next V6 00/16] AF_XDP infrastructure improvements and mlx5e support
From: Daniel Borkmann @ 2019-06-26 20:26 UTC (permalink / raw)
To: Tariq Toukan, Alexei Starovoitov, bjorn.topel, Magnus Karlsson
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, Jonathan Lemon,
David S. Miller, Maxim Mikityanskiy
In-Reply-To: <1561559738-4213-1-git-send-email-tariqt@mellanox.com>
On 06/26/2019 04:35 PM, Tariq Toukan wrote:
[...]
> v6 changes:
>
> As Maxim is out of office, I rebased the series on behalf of him,
> solved some conflicts, and re-spinned.
Thanks for taking over the rebase, Tariq!
> Series generated against bpf-next commit:
> 572a6928f9e3 xdp: Make __mem_id_disconnect static
>
>
> Maxim Mikityanskiy (16):
> net/mlx5e: Attach/detach XDP program safely
> xsk: Add API to check for available entries in FQ
> xsk: Add getsockopt XDP_OPTIONS
> libbpf: Support getsockopt XDP_OPTIONS
> xsk: Change the default frame size to 4096 and allow controlling it
> xsk: Return the whole xdp_desc from xsk_umem_consume_tx
> net/mlx5e: Replace deprecated PCI_DMA_TODEVICE
> net/mlx5e: Calculate linear RX frag size considering XSK
> net/mlx5e: Allow ICO SQ to be used by multiple RQs
> net/mlx5e: Refactor struct mlx5e_xdp_info
> net/mlx5e: Share the XDP SQ for XDP_TX between RQs
> net/mlx5e: XDP_TX from UMEM support
> net/mlx5e: Consider XSK in XDP MTU limit calculation
> net/mlx5e: Encapsulate open/close queues into a function
> net/mlx5e: Move queue param structs to en/params.h
> net/mlx5e: Add XSK zero-copy support
Series applied, thanks!
^ permalink raw reply
* Re: [PATCH net v2 0/2] ipv6: fix neighbour resolution with raw socket
From: David Miller @ 2019-06-26 20:26 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, ndesaulniers
In-Reply-To: <20190624140109.14775-1-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon, 24 Jun 2019 16:01:07 +0200
> The first patch prepares the fix, it constify rt6_nexthop().
> The detail of the bug is explained in the second patch.
>
> v1 -> v2:
> - fix compilation warnings
> - split the initial patch
Series applied, thanks Nicolas.
^ permalink raw reply
* Re: [EXT] [PATCH V2] bnx2x: Prevent ptp_task to be rescheduled indefinitely
From: Guilherme Piccoli @ 2019-06-26 20:24 UTC (permalink / raw)
To: Sudarsana Reddy Kalluru
Cc: jay.vosburgh@canonical.com, GR-everest-linux-l2,
netdev@vger.kernel.org, Ariel Elior
In-Reply-To: <MN2PR18MB2528569269272880338B8E4CD3E20@MN2PR18MB2528.namprd18.prod.outlook.com>
On Wed, Jun 26, 2019 at 5:25 AM Sudarsana Reddy Kalluru
<skalluru@marvell.com> wrote:
> > Sudarsana, let me ask you something: why does the register is reading value
> > 0x0 always in the TX timestamp routine if the RX filter is set to None? This is
> > the main cause of the thread reschedule thing.
>
> The register value of zero indicates there is no pending Tx timestamp to be read by the driver.
> FW writes/latches the Tx timestamp for PTP event packet in this register. And it does the latching only if the register is free.
> In this case user/app look to be requesting the Timestamp (via skb->tx_flags) for non-ptp Tx packet. In the Tx path, driver schedules a thread for reading the Tx timestamp,
> bnx2x_start_xmit()
> {
> if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP))
> schedule_work(&bp->ptp_task);
> }
> FW seem to be not timestamping the packet at all and driver is indefinitely waiting for it.
>
Thanks Sudarsana! I've tried to implement the qede-like approach
again, with the 2s timeout before
bailing-out the thread reschedule. This time, I've remove _all_log
messages, including the DP() ones...
Unfortunately kthread is still consuming 100% of CPU, which makes
sense, since it reschedules itself
the most times it can in this 2s window...I think we really should
have small pauses before retrying to
read the registers. I've worked a V3, implementing 1ms-starting
pauses, which worked well:
https://marc.info/?l=linux-netdev&m=156158032618932
I hope this way we don't harm the PTP applications, nor introduce
delays in the FW wait-queue,
and at same time we can fix the indefinitely reschedule in bnx2x.
Thanks again for your support,
Guilherme
^ permalink raw reply
* Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: James Morris @ 2019-06-26 20:22 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Matthew Garrett, linux-security, LKML, Linux API, David Howells,
Alexei Starovoitov, Matthew Garrett, Network Development,
Chun-Yi Lee, Daniel Borkmann, linux-security-module
In-Reply-To: <CALCETrVUwQP7roLnW6kFG80Cc5U6X_T6AW+BTAftLccYGp8+Ow@mail.gmail.com>
[Adding the LSM mailing list: missed this patchset initially]
On Thu, 20 Jun 2019, Andy Lutomirski wrote:
> This patch exemplifies why I don't like this approach:
>
> > @@ -97,6 +97,7 @@ enum lockdown_reason {
> > LOCKDOWN_INTEGRITY_MAX,
> > LOCKDOWN_KCORE,
> > LOCKDOWN_KPROBES,
> > + LOCKDOWN_BPF,
> > LOCKDOWN_CONFIDENTIALITY_MAX,
>
> > --- a/security/lockdown/lockdown.c
> > +++ b/security/lockdown/lockdown.c
> > @@ -33,6 +33,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
> > [LOCKDOWN_INTEGRITY_MAX] = "integrity",
> > [LOCKDOWN_KCORE] = "/proc/kcore access",
> > [LOCKDOWN_KPROBES] = "use of kprobes",
> > + [LOCKDOWN_BPF] = "use of bpf",
> > [LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
>
> The text here says "use of bpf", but what this patch is *really* doing
> is locking down use of BPF to read kernel memory. If the details
> change, then every LSM needs to get updated, and we risk breaking user
> policies that are based on LSMs that offer excessively fine
> granularity.
Can you give an example of how the details might change?
> I'd be more comfortable if the LSM only got to see "confidentiality"
> or "integrity".
These are not sufficient for creating a useful policy for the SELinux
case.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH V2] net: dsa: microchip: Use gpiod_set_value_cansleep()
From: David Miller @ 2019-06-26 20:23 UTC (permalink / raw)
To: marex; +Cc: netdev, andrew, f.fainelli, linus.walleij, Tristram.Ha,
Woojung.Huh
In-Reply-To: <20190623151257.13660-1-marex@denx.de>
From: Marek Vasut <marex@denx.de>
Date: Sun, 23 Jun 2019 17:12:57 +0200
> Replace gpiod_set_value() with gpiod_set_value_cansleep(), as the switch
> reset GPIO can be connected to e.g. I2C GPIO expander and it is perfectly
> fine for the kernel to sleep for a bit in ksz_switch_register().
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Tristram Ha <Tristram.Ha@microchip.com>
> Cc: Woojung Huh <Woojung.Huh@microchip.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
> V2: use _cansleep in .remove as well
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 1/1] Allow 0.0.0.0/8 as a valid address range
From: David Miller @ 2019-06-26 20:20 UTC (permalink / raw)
To: dave.taht; +Cc: netdev, gnu
In-Reply-To: <1561223254-13589-2-git-send-email-dave.taht@gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Sat, 22 Jun 2019 10:07:34 -0700
> The longstanding prohibition against using 0.0.0.0/8 dates back
> to two issues with the early internet.
>
> There was an interoperability problem with BSD 4.2 in 1984, fixed in
> BSD 4.3 in 1986. BSD 4.2 has long since been retired.
>
> Secondly, addresses of the form 0.x.y.z were initially defined only as
> a source address in an ICMP datagram, indicating "node number x.y.z on
> this IPv4 network", by nodes that know their address on their local
> network, but do not yet know their network prefix, in RFC0792 (page
> 19). This usage of 0.x.y.z was later repealed in RFC1122 (section
> 3.2.2.7), because the original ICMP-based mechanism for learning the
> network prefix was unworkable on many networks such as Ethernet (which
> have longer addresses that would not fit into the 24 "node number"
> bits). Modern networks use reverse ARP (RFC0903) or BOOTP (RFC0951)
> or DHCP (RFC2131) to find their full 32-bit address and CIDR netmask
> (and other parameters such as default gateways). 0.x.y.z has had
> 16,777,215 addresses in 0.0.0.0/8 space left unused and reserved for
> future use, since 1989.
>
> This patch allows for these 16m new IPv4 addresses to appear within
> a box or on the wire. Layer 2 switches don't care.
>
> 0.0.0.0/32 is still prohibited, of course.
>
> Signed-off-by: Dave Taht <dave.taht@gmail.com>
> Signed-off-by: John Gilmore <gnu@toad.com>
> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Applied, thanks for following up on this.
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: stmmac: Enable support for > 32 Bits addressing in XGMAC
From: Andrew Lunn @ 2019-06-26 20:19 UTC (permalink / raw)
To: Jose Abreu
Cc: linux-kernel, netdev, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <64b73591f981b3a280ea61d21a0dc7362a25348a.1561556556.git.joabreu@synopsys.com>
> +
> + if (priv->dma_cap.addr64) {
> + ret = dma_set_mask_and_coherent(device,
> + DMA_BIT_MASK(priv->dma_cap.addr64));
> + if (!ret)
> + dev_info(priv->device, "Using %d bits DMA width\n",
> + priv->dma_cap.addr64);
> + }
Hi Jose
If dma_set_mask_and_coherent() fails, i think you are supposed to fall
back to 32 bits. So you might want to clear priv->dma_cap.addr64.
But don't trust my, i could be wrong.
Andrew
^ permalink raw reply
* [PATCH V3] bnx2x: Prevent ptp_task to be rescheduled indefinitely
From: Guilherme G. Piccoli @ 2019-06-26 20:18 UTC (permalink / raw)
To: GR-everest-linux-l2, netdev, skalluru; +Cc: aelior, gpiccoli, jay.vosburgh
Currently bnx2x ptp worker tries to read a register with timestamp
information in case of TX packet timestamping and in case it fails,
the routine reschedules itself indefinitely. This was reported as a
kworker always at 100% of CPU usage, which was narrowed down to be
bnx2x ptp_task.
By following the ioctl handler, we could narrow down the problem to
an NTP tool (chrony) requesting HW timestamping from bnx2x NIC with
RX filter zeroed; this isn't reproducible for example with ptp4l
(from linuxptp) since this tool requests a supported RX filter.
It seems NIC FW timestamp mechanism cannot work well with
RX_FILTER_NONE - driver's PTP filter init routine skips a register
write to the adapter if there's not a supported filter request.
This patch addresses the problem of bnx2x ptp thread's everlasting
reschedule by retrying the register read 10 times; between the read
attempts the thread sleeps for an increasing amount of time starting
in 1ms to give FW some time to perform the timestamping. If it still
fails after all retries, we bail out in order to prevent an unbound
resource consumption from bnx2x.
The patch also adds an ethtool statistic for accounting the skipped
TX timestamp packets and it reduces the priority of timestamping
error messages to prevent log flooding. The code was tested using
both linuxptp and chrony.
Reported-and-tested-by: Przemyslaw Hausman <przemyslaw.hausman@canonical.com>
Suggested-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
---
Sudarsana, thanks again for your feedback. I've reduced the sleep times
to start in 1ms and goes up to 512ms - the sum of sleep times is 1023ms,
but due to the inherent overhead in sleeping/waking-up procedure, I've
measured the total delay in the register read loop (on bnx2x_ptp_task)
to be ~1.6 seconds. It is almost the 2s value you first suggested as
PTP_TIMEOUT.
.../net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 12 +++++--
.../ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 4 ++-
.../net/ethernet/broadcom/bnx2x/bnx2x_main.c | 36 ++++++++++++++-----
.../net/ethernet/broadcom/bnx2x/bnx2x_stats.h | 3 ++
4 files changed, 43 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 008ad0ca89ba..6751cd04e8d8 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3857,9 +3857,17 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
if (!(bp->flags & TX_TIMESTAMPING_EN)) {
- BNX2X_ERR("Tx timestamping was not enabled, this packet will not be timestamped\n");
+ bp->eth_stats.ptp_skip_tx_ts++;
+ netdev_err_once(bp->dev,
+ "Tx timestamping isn't enabled, this packet won't be timestamped\n");
+ DP(BNX2X_MSG_PTP,
+ "Tx timestamping isn't enabled, this packet won't be timestamped\n");
} else if (bp->ptp_tx_skb) {
- BNX2X_ERR("The device supports only a single outstanding packet to timestamp, this packet will not be timestamped\n");
+ bp->eth_stats.ptp_skip_tx_ts++;
+ netdev_err_once(bp->dev,
+ "Device supports only a single outstanding packet to timestamp, this packet won't be timestamped\n");
+ DP(BNX2X_MSG_PTP,
+ "Device supports only a single outstanding packet to timestamp, this packet won't be timestamped\n");
} else {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
/* schedule check for Tx timestamp */
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index 51fc845de31a..4a0ba6801c9e 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -182,7 +182,9 @@ static const struct {
{ STATS_OFFSET32(driver_filtered_tx_pkt),
4, false, "driver_filtered_tx_pkt" },
{ STATS_OFFSET32(eee_tx_lpi),
- 4, true, "Tx LPI entry count"}
+ 4, true, "Tx LPI entry count"},
+ { STATS_OFFSET32(ptp_skip_tx_ts),
+ 4, false, "ptp_skipped_tx_tstamp" },
};
#define BNX2X_NUM_STATS ARRAY_SIZE(bnx2x_stats_arr)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 03ac10b1cd1e..af6e7a950a28 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -15214,11 +15214,27 @@ static void bnx2x_ptp_task(struct work_struct *work)
u32 val_seq;
u64 timestamp, ns;
struct skb_shared_hwtstamps shhwtstamps;
+ bool bail = true;
+ int i;
- /* Read Tx timestamp registers */
- val_seq = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_SEQID :
- NIG_REG_P0_TLLH_PTP_BUF_SEQID);
- if (val_seq & 0x10000) {
+ /* FW may take a while to complete timestamping; try a bit and if it's
+ * still not complete, may indicate an error state - bail out then.
+ */
+ for (i = 0; i < 10; i++) {
+ /* Read Tx timestamp registers */
+ val_seq = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_SEQID :
+ NIG_REG_P0_TLLH_PTP_BUF_SEQID);
+ if (val_seq & 0x10000) {
+ bail = false;
+ break;
+ }
+
+ if (!(i % 4)) /* Avoid log flood */
+ DP(BNX2X_MSG_PTP, "There's no valid Tx timestamp yet\n");
+ msleep(1 << i);
+ }
+
+ if (!bail) {
/* There is a valid timestamp value */
timestamp = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_TS_MSB :
NIG_REG_P0_TLLH_PTP_BUF_TS_MSB);
@@ -15233,16 +15249,18 @@ static void bnx2x_ptp_task(struct work_struct *work)
memset(&shhwtstamps, 0, sizeof(shhwtstamps));
shhwtstamps.hwtstamp = ns_to_ktime(ns);
skb_tstamp_tx(bp->ptp_tx_skb, &shhwtstamps);
- dev_kfree_skb_any(bp->ptp_tx_skb);
- bp->ptp_tx_skb = NULL;
DP(BNX2X_MSG_PTP, "Tx timestamp, timestamp cycles = %llu, ns = %llu\n",
timestamp, ns);
} else {
- DP(BNX2X_MSG_PTP, "There is no valid Tx timestamp yet\n");
- /* Reschedule to keep checking for a valid timestamp value */
- schedule_work(&bp->ptp_task);
+ DP(BNX2X_MSG_PTP,
+ "Tx timestamp is not recorded (register read=%u)\n",
+ val_seq);
+ bp->eth_stats.ptp_skip_tx_ts++;
}
+
+ dev_kfree_skb_any(bp->ptp_tx_skb);
+ bp->ptp_tx_skb = NULL;
}
void bnx2x_set_rx_ts(struct bnx2x *bp, struct sk_buff *skb)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
index b2644ed13d06..d55e63692cf3 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
@@ -207,6 +207,9 @@ struct bnx2x_eth_stats {
u32 driver_filtered_tx_pkt;
/* src: Clear-on-Read register; Will not survive PMF Migration */
u32 eee_tx_lpi;
+
+ /* PTP */
+ u32 ptp_skip_tx_ts;
};
struct bnx2x_eth_q_stats {
--
2.22.0
^ permalink raw reply related
* Re: [PATCH net] net: aquantia: fix vlans not working over bridged network
From: David Miller @ 2019-06-26 20:17 UTC (permalink / raw)
To: Igor.Russkikh; +Cc: netdev, Dmitry.Bogdanov
In-Reply-To: <f9ccf4959d8efed1ee8832c56c59f5adfe2f9fd7.1561028841.git.igor.russkikh@aquantia.com>
From: Igor Russkikh <Igor.Russkikh@aquantia.com>
Date: Sat, 22 Jun 2019 08:46:37 +0000
> From: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
>
> In configuration of vlan over bridge over aquantia device
> it was found that vlan tagged traffic is dropped on chip.
>
> The reason is that bridge device enables promisc mode,
> but in atlantic chip vlan filters will still apply.
> So we have to corellate promisc settings with vlan configuration.
>
> The solution is to track in a separate state variable the
> need of vlan forced promisc. And also consider generic
> promisc configuration when doing vlan filter config.
>
> Fixes: 7975d2aff5af ("net: aquantia: add support of rx-vlan-filter offload")
> Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink: skip metrics loop for dst_default_metrics
From: David Miller @ 2019-06-26 20:15 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20190621232716.26755-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Fri, 21 Jun 2019 16:27:16 -0700
> From: David Ahern <dsahern@gmail.com>
>
> dst_default_metrics has all of the metrics initialized to 0, so nothing
> will be added to the skb in rtnetlink_put_metrics. Avoid the loop if
> metrics is from dst_default_metrics.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied, thanks David.
^ permalink raw reply
* Re: [PATCH 3/3] net: ethernet: atheros: atlx: Remove unused and private PCI definitions
From: David Miller @ 2019-06-26 20:07 UTC (permalink / raw)
To: puranjay12
Cc: skhan, bjorn, netdev, linux-kernel, linux-kernel-mentees,
linux-pci
In-Reply-To: <20190621163921.26188-4-puranjay12@gmail.com>
From: Puranjay Mohan <puranjay12@gmail.com>
Date: Fri, 21 Jun 2019 22:09:21 +0530
> Remove unused private PCI definitions from skfbi.h because generic PCI
> symbols are already included from pci_regs.h.
>
> Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
Please also handle the PCI register bit value define duplications as well,
as pointed out by Bjorn.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v6 1/8] igb: clear out skb->tstamp after reading the txtime
From: Patel, Vedang @ 2019-06-26 20:06 UTC (permalink / raw)
To: Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, David Miller, Jamal Hadi Salim, Cong Wang,
Jiri Pirko, intel-wired-lan@lists.osuosl.org, Gomes, Vinicius,
l@dorileo.org, Jakub Kicinski, Murali Karicheri, Sergei Shtylyov,
Eric Dumazet, Brown, Aaron F
In-Reply-To: <4f0681155a6057bf40e281bfc251aba60c296201.camel@intel.com>
Hi Jeff,
> On Jun 26, 2019, at 12:44 PM, Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com> wrote:
>
> On Tue, 2019-06-25 at 15:07 -0700, Vedang Patel wrote:
>> If a packet which is utilizing the launchtime feature (via SO_TXTIME
>> socket
>> option) also requests the hardware transmit timestamp, the hardware
>> timestamp is not delivered to the userspace. This is because the
>> value in
>> skb->tstamp is mistaken as the software timestamp.
>>
>> Applications, like ptp4l, request a hardware timestamp by setting the
>> SOF_TIMESTAMPING_TX_HARDWARE socket option. Whenever a new timestamp
>> is
>> detected by the driver (this work is done in igb_ptp_tx_work() which
>> calls
>> igb_ptp_tx_hwtstamps() in igb_ptp.c[1]), it will queue the timestamp
>> in the
>> ERR_QUEUE for the userspace to read. When the userspace is ready, it
>> will
>> issue a recvmsg() call to collect this timestamp. The problem is in
>> this
>> recvmsg() call. If the skb->tstamp is not cleared out, it will be
>> interpreted as a software timestamp and the hardware tx timestamp
>> will not
>> be successfully sent to the userspace. Look at skb_is_swtx_tstamp()
>> and the
>> callee function __sock_recv_timestamp() in net/socket.c for more
>> details.
>>
>> Signed-off-by: Vedang Patel <vedang.patel@intel.com>
>> ---
>> drivers/net/ethernet/intel/igb/igb_main.c | 1 +
>> 1 file changed, 1 insertion(+)
>
> Since this fix is really not needed for the rest of the patch series,
> if you have to do another version of the series, can you drop this
> patch from any future version? I don't want to keep spinning my
> validation team on a updated version of this patch, that is not really
> being updated.
>
> I plan to take this version of the patch and will hold onto it for my
> next 1GbE updates to Dave.
This patch is needed for ptp4l to function properly when txtime-assist mode is enabled. So, dropping this patch will break the series. When are you planning to submit the next set of updates to Dave? If a new version is needed, I can plan to send it out after you send your updates.
Thanks,
Vedang
^ permalink raw reply
* Re: [PATCH v5 0/3] net: fddi: skfp: Use PCI generic definitions instead of private duplicates
From: David Miller @ 2019-06-26 20:05 UTC (permalink / raw)
To: puranjay12
Cc: skhan, bjorn, netdev, linux-kernel, linux-kernel-mentees,
linux-pci, stephen
In-Reply-To: <20190621154037.25245-1-puranjay12@gmail.com>
From: Puranjay Mohan <puranjay12@gmail.com>
Date: Fri, 21 Jun 2019 21:10:34 +0530
> This patch series removes the private duplicates of PCI definitions in
> favour of generic definitions defined in pci_regs.h.
>
> This driver only uses some of the generic PCI definitons,
> which are included from pci_regs.h and thier private versions
> are removed from skfbi.h with all other private defines.
>
> The skfbi.h defines PCI_REV_ID and other private defines with different
> names, these are renamed to Generic PCI names to make them
> compatible with defines in pci_regs.h.
>
> All unused defines are removed from skfbi.h.
...
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 0/3] net: fddi: skfp: Use PCI generic definitions instead of private duplicates
From: David Miller @ 2019-06-26 20:03 UTC (permalink / raw)
To: skhan
Cc: gnomes, puranjay12, bjorn, stephen, netdev, linux-kernel,
linux-kernel-mentees, linux-pci
In-Reply-To: <5f04f52d-8911-4db9-4321-00334d357d54@linuxfoundation.org>
From: Shuah Khan <skhan@linuxfoundation.org>
Date: Fri, 21 Jun 2019 10:36:02 -0600
> Stephen Hemminger is suggesting removal as well. Makes sense to me.
...
> What would you recommend the next steps are? Would like driver
> removed?
If you hadn't proposed the cleanups nobody would have said to remove
this driver. Really if someone wants to go through the tree and
send removal patches for seemingly really unused drivers, that is
a separate piece of work unrelated to your cleanup.
While something still is in the tree we should clean it up from
stuff like this.
Therefore, I'll be applying v5 of your changes, thanks.
^ 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