* [bpf-next PATCH 7/7] bpf: sockmap set rlimit
From: John Fastabend @ 2018-01-08 18:06 UTC (permalink / raw)
To: john.fastabend, ast, daniel; +Cc: netdev
In-Reply-To: <20180108180302.13647.13866.stgit@john-Precision-Tower-5810>
Avoid extra step of setting limit from cmdline and do it directly in
the program.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
samples/sockmap/sockmap_user.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/samples/sockmap/sockmap_user.c b/samples/sockmap/sockmap_user.c
index 0d8950f..2afbefd 100644
--- a/samples/sockmap/sockmap_user.c
+++ b/samples/sockmap/sockmap_user.c
@@ -27,6 +27,7 @@
#include <time.h>
#include <sys/time.h>
+#include <sys/resource.h>
#include <sys/types.h>
#include <linux/netlink.h>
@@ -434,6 +435,7 @@ enum {
int main(int argc, char **argv)
{
int iov_count = 1, length = 1024, rate = 1, verbose = 0;
+ struct rlimit r = {10 * 1024 * 1024, RLIM_INFINITY};
int opt, longindex, err, cg_fd = 0;
int test = PING_PONG;
char filename[256];
@@ -487,6 +489,11 @@ int main(int argc, char **argv)
return -1;
}
+ if (setrlimit(RLIMIT_MEMLOCK, &r)) {
+ perror("setrlimit(RLIMIT_MEMLOCK)");
+ return 1;
+ }
+
snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
running = 1;
^ permalink raw reply related
* Re: [PATCHv3 0/2] capability controlled user-namespaces
From: Serge E. Hallyn @ 2018-01-08 18:11 UTC (permalink / raw)
To: Mahesh Bandewar (महेश बंडेवार)
Cc: Serge E. Hallyn, James Morris, LKML, Netdev, Kernel-hardening,
Linux API, Kees Cook, Eric W . Biederman, Eric Dumazet,
David Miller, Mahesh Bandewar
In-Reply-To: <CAF2d9jgVJpuAH+jgK0v7sQ9Pr75xy=GSnqKDdpeE7d97O0EbcQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
> > Quoting James Morris (james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org):
> >> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
> >> I meant in terms of "marking" a user ns as "controlled" type -- it's
> >> unnecessary jargon from an end user point of view.
> >
> > Ah, yes, that was my point in
> >
> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/01845.html
> > and
> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/02276.html
> >
> >> This may happen internally but don't make it a special case with a
> >> different name and don't bother users with internal concepts: simply
> >> implement capability whitelists with the default having equivalent
So the challenge is to have unprivileged users be contained, while
allowing trusted workloads in containers created by a root user to
bypass the restriction.
Now, the current proposal actually doesn't support a root user starting
an application that it doesn't quite trust in such a way that it *is*
subject to the whitelist. Which is unfortunate. But apart from using
ptags or a cgroup, I can't think of a good way to get us everything we
want:
1. unprivileged users always restricted
2. existing unprivileged containers become restricted when whitelist
is enabled
3. privileged users are able to create containers which are not restricted
4. privileged users are able to create containers which *are* restricted
^ permalink raw reply
* Re: hyperv/netvsc: Delete two error messages for a failed memory allocation in netvsc_init_buf()
From: SF Markus Elfring @ 2018-01-08 18:19 UTC (permalink / raw)
To: Haiyang Zhang, devel@linuxdriverproject.org, netdev
Cc: KY Srinivasan, Stephen Hemminger, LKML, kernel-janitors
In-Reply-To: <CY4PR2101MB0867CEFAF4FB72AF47FA3AA7CA130@CY4PR2101MB0867.namprd21.prod.outlook.com>
> These messages are not displayed anywhere else:
> "unable to allocate receive buffer of size %u\n"
> "unable to allocate send buffer of size %u\n",
>
> After set ret = -ENOMEM; and cleanup, we won't know which buffer allocation failed without the error message.
Do you notice a Linux allocation failure report before them in your system?
> So please do not remove these messages.
How much does the distinction matter for these buffers?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: Ingo Molnar @ 2018-01-08 18:21 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Alexei Starovoitov, Dan Williams, Linus Torvalds, Willy Tarreau,
Alan Cox, Linux Kernel Mailing List, linux-arch, Andi Kleen,
Arnd Bergmann, Greg Kroah-Hartman, Network Development,
Ingo Molnar, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <20180108095154.GD3040@hirez.programming.kicks-ass.net>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Sun, Jan 07, 2018 at 06:24:11PM -0800, Alexei Starovoitov wrote:
> > How about:
> > CONFIG_SPECTRE1_WORKAROUND_INDEX_MASK
> > CONFIG_SPECTRE1_WORKAROUND_LOAD_FENCE
>
> INSTRUCTION_FENCE if anything. LFENCE for Intel (and now also for AMD as
> per 0592b0bce169) is a misnomer, IFENCE would be a better name for it.
Btw., we should probably propagate that naming to most places and only point it
out in comments/documentation that Intel/AMD calls this CPU functionality 'LFENCE'
for historic reasons and that the opcode got stolen for the Spectre fixes.
Thanks,
Ingo
^ permalink raw reply
* Re: [RFC -next 2/2] net: sched: red: don't reset the backlog on every stat dump
From: Jakub Kicinski @ 2018-01-08 18:23 UTC (permalink / raw)
To: Nogah Frankel
Cc: john.fastabend@gmail.com, jiri@resnulli.us,
xiyou.wangcong@gmail.com, Yuval Mintz, netdev@vger.kernel.org,
oss-drivers@netronome.com, edumazet@google.com
In-Reply-To: <DB5PR05MB18954F403296865ABE464362AC130@DB5PR05MB1895.eurprd05.prod.outlook.com>
On Mon, 8 Jan 2018 09:18:08 +0000, Nogah Frankel wrote:
> > Unlike for other statistics new_hw_stat < prev_hw_stat can be true.
> > Adjust mlxsw.
>
> There is one problem with this patch, and that is that we can fail in
> changing RED that is offloaded. In this case, we delete RED from the driver
> but the backlog will still include the hardware backlog.
> The solution is to send in the offload-replace command a pointer to the
> backlog, so failure in updating the hardware can be follow by backlog update,
> if needed.
Thanks, will fix.
^ permalink raw reply
* Re: brcmfmac: Use zeroing memory allocator than allocator/memset
From: Himanshu Jha @ 2018-01-08 18:24 UTC (permalink / raw)
To: Kalle Valo
Cc: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, netdev, linux-kernel, mcgrof
In-Reply-To: <20180108172322.6AD8560B1B@smtp.codeaurora.org>
On Mon, Jan 08, 2018 at 05:23:22PM +0000, Kalle Valo wrote:
> Himanshu Jha <himanshujha199640@gmail.com> wrote:
>
> > Use dma_zalloc_coherent for allocating zeroed
> > memory and remove unnecessary memset function.
> >
> > Done using Coccinelle.
> > Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
> > 0-day tested with no failures.
> >
> > Suggested-by: Luis R. Rodriguez <mcgrof@kernel.org>
> > Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
> Failed to apply:
>
> fatal: corrupt patch at line 29
> error: could not build fake ancestor
> Applying: brcmfmac: Use zeroing memory allocator than allocator/memset
> Patch failed at 0001 brcmfmac: Use zeroing memory allocator than allocator/memset
> The copy of the patch that failed is found in: .git/rebase-apply/patch
>
> Patch set to Changes Requested.
Sorry! That failed because I manually adjusted the arguments to prevent
80 character limit in the patch generated.
I will rebase and send v2 with updates.
--
Thanks
Himanshu Jha
^ permalink raw reply
* Re: [PATCHv3 0/2] capability controlled user-namespaces
From: Mahesh Bandewar (महेश बंडेवार) @ 2018-01-08 18:24 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: James Morris, LKML, Netdev, Kernel-hardening, Linux API,
Kees Cook, Eric W . Biederman, Eric Dumazet, David Miller,
Mahesh Bandewar
In-Reply-To: <20180108181121.GA32302@mail.hallyn.com>
On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com):
>> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
>> > Quoting James Morris (james.l.morris@oracle.com):
>> >> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
>> >> I meant in terms of "marking" a user ns as "controlled" type -- it's
>> >> unnecessary jargon from an end user point of view.
>> >
>> > Ah, yes, that was my point in
>> >
>> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/01845.html
>> > and
>> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/02276.html
>> >
>> >> This may happen internally but don't make it a special case with a
>> >> different name and don't bother users with internal concepts: simply
>> >> implement capability whitelists with the default having equivalent
>
> So the challenge is to have unprivileged users be contained, while
> allowing trusted workloads in containers created by a root user to
> bypass the restriction.
>
> Now, the current proposal actually doesn't support a root user starting
> an application that it doesn't quite trust in such a way that it *is*
> subject to the whitelist.
Well, this is not hard since root process can spawn another process
and loose privileges before creating user-ns to be controlled by the
whitelist.
You need an ability to preserve the creation of user-namespaces that
exhibit 'the uncontrolled behavior' and only trusted/privileged (root)
user should have it which is maintained here.
> Which is unfortunate. But apart from using
> ptags or a cgroup, I can't think of a good way to get us everything we
> want:
>
> 1. unprivileged users always restricted
> 2. existing unprivileged containers become restricted when whitelist
> is enabled
> 3. privileged users are able to create containers which are not restricted
all this is achieved by the patch-set without any changes to the
application with the above knob.
> 4. privileged users are able to create containers which *are* restricted
>
With this patch-set; the root user process can fork another process
with less privileges before creating a user-ns if the exec-ed process
cannot be trusted. So there is a way with little modification as
opposed to nothing available at this moment for this scenario.
^ permalink raw reply
* Re: dvb usb issues since kernel 4.9
From: Linus Torvalds @ 2018-01-08 18:32 UTC (permalink / raw)
To: Ingo Molnar
Cc: Mauro Carvalho Chehab, Josef Griebichler, Greg Kroah-Hartman,
Alan Stern, USB list, Eric Dumazet, Rik van Riel, Paolo Abeni,
Hannes Frederic Sowa, Jesper Dangaard Brouer, linux-kernel,
netdev, Jonathan Corbet, LMML, Peter Zijlstra, David Miller
In-Reply-To: <20180108175551.wp6thxmiozrz4yp2@gmail.com>
On Mon, Jan 8, 2018 at 9:55 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> as I doubt we have enough time to root-case this properly.
Well, it's not like this is a new issue, and we don't have to get it
fixed for 4.15. It's been around since 4.9, it's not a "have to
suddenly fix it this week" issue.
I just think that people should plan on having to maybe revert it and
mark the revert for stable.
But if the USB or DVB layers can instead just make the packet queue a
bit deeper and not react so badly to the latency of a single softirq,
that would obviously be a good thing in general, and maybe fix this
issue. So I'm not saying that the revert is inevitable either.
But I have to say that that commit 4cd13c21b207 ("softirq: Let
ksoftirqd do its job") was a pretty damn big hammer, and entirely
ignored the "softirqs can have latency concerns" issue.
So I do feel like the UDP packet storm thing might want a somewhat
more directed fix than that huge hammer of trying to move softirqs
aggressively into the softirq thread.
This is not that different from threaded irqs. And while you can set
the "thread every irq" flag, that would be largely insane to do by
default and in general. So instead, people do it either for specific
irqs (ie "request_threaded_irq()") or they have a way to opt out of it
(IRQF_NO_THREAD).
I _suspect_ that the softirq thing really just wants the same thing.
Have the networking case maybe set the "prefer threaded" flag just for
networking, if it's less latency-sensitive for softirq handling than
In fact, even for networking, there are separate TX/RX softirqs, maybe
networking would only set it for the RX case? Or maybe even trigger it
only for cases where things queue up and it goes into a "polling mode"
(like NAPI already does).
Of course, I don't even know _which_ softirq it is that the DVB case
has issues with. Maybe it's the same NET_RX case?
But looking at that offending commit, I do note (for example), that we
literally have things like tasklet[_hi]_schedule() that might have
been explicitly expected to just run the tasklet at a fairly low
latency (maybe instead of a workqueue exactly because it doesn't need
to sleep and wants lower latency).
So saying "just because softirqd is possibly already woken up, let's
delay all those tasklets etc" does really seem very wrong to me.
Can somebody tell which softirq it is that dvb/usb cares about?
Linus
^ permalink raw reply
* Re: pull-request: can 2018-01-04
From: Marc Kleine-Budde @ 2018-01-07 12:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-can, kernel
In-Reply-To: <20180105.134839.941290778276014203.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 2007 bytes --]
On 01/05/2018 07:48 PM, David Miller wrote:
> From: Marc Kleine-Budde <mkl@pengutronix.de>
> Date: Thu, 4 Jan 2018 16:33:51 +0100
>
>> this is a pull request for net/master consisting of 4 patches.
>>
>> The first patch is by Oliver Hartkopp, it improves the error checking
>> during the creation of a vxcan link. Wolfgang Grandegger's patch for the
>> gs_usb driver fixes the return value of the "set_bittiming" callback.
>> Luu An Phu provides a patch for the flexcan driver to fix the frame
>> length check in the flexcan_start_xmit() function. The last patch is by
>> Martin Lederhilger for the ems_usb driver and improves the error
>> reporting for error warning and passive frames.
> ...
>> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-4.15-20180104
>
> I think you meant:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-4.15-20180104
No, that was intentional.
> Otherwise can I please have all of your private SSH keys? :-)
As long as you have your SSH keys, you have read only access to my (and
the git repos of the other kernel developers) on git.kernel.org. I'm
already fetching from net and net-next via ssh:
> $ git fetch net
> remote: Counting objects: 70, done.
> remote: Compressing objects: 100% (70/70), done.
> remote: Total 70 (delta 59), reused 0 (delta 0)
> Unpacking objects: 100% (70/70), done.
> From ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/davem/net
> 6926e041a892..5133550296d4 master -> net/master
See Konstantin Ryabitsev's mail "[kernel.org users] Forcing git to
always use gitolite.kernel.org" for more details.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution
From: Ingo Molnar @ 2018-01-08 18:33 UTC (permalink / raw)
To: Alan Cox
Cc: Peter Zijlstra, Dan Williams, Eric W. Biederman,
Linux Kernel Mailing List, Mark Rutland, Alan Cox,
Srinivas Pandruvada, Will Deacon, Solomon Peachy, H. Peter Anvin,
Christian Lamparter, Elena Reshetova, linux-arch, Andi Kleen,
James E.J. Bottomley, linux-scsi, Jonathan Corbet, X86 ML,
Ingo Molnar, Alexey
In-Reply-To: <20180108114342.3b2d99fb@alans-desktop>
* Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
> On Mon, 8 Jan 2018 11:08:36 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote:
> > > On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> > > > In at least one place (mpls) you are patching a fast path. Compile out
> > > > or don't load mpls by all means. But it is not acceptable to change the
> > > > fast path without even considering performance.
> > >
> > > Performance matters greatly, but I need help to identify a workload
> > > that is representative for this fast path to see what, if any, impact
> > > is incurred. Even better is a review that says "nope, 'index' is not
> > > subject to arbitrary userspace control at this point, drop the patch."
> >
> > I think we're focussing a little too much on pure userspace. That is, we
> > should be saying under the attackers control. Inbound network packets
> > could equally be under the attackers control.
>
> Inbound network packets don't come with a facility to read back and do
> cache timimg. [...]
But the reply packets can be measured on the sending side, and the total delay
timing would thus carry the timing information.
Yes, a lot of noise gets added that way if we think 'packet goes through the
Internet' - but with gigabit local network access or even through localhost
access a lot of noise can be removed as well.
It's not as dangerous as a near instantaneous local attack, but 'needs a day of
runtime to brute-force through localhost or 10GigE' is still worrying in many
real-world security contexts.
So I concur with Peter that we should generally consider making all of our
responses to external data (maybe with the exception of pigeon post messages)
Spectre-safe.
Thanks,
Ingo
^ permalink raw reply
* [PATCH net v2] ipv6: remove null_entry before adding default route
From: Wei Wang @ 2018-01-08 18:34 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Martin KaFai Lau, Eric Dumazet, Wei Wang
From: Wei Wang <weiwan@google.com>
In the current code, when creating a new fib6 table, tb6_root.leaf gets
initialized to net->ipv6.ip6_null_entry.
If a default route is being added with rt->rt6i_metric = 0xffffffff,
fib6_add() will add this route after net->ipv6.ip6_null_entry. As
null_entry is shared, it could cause problem.
In order to fix it, set fn->leaf to NULL before calling
fib6_add_rt2node() when trying to add the first default route.
And reset fn->leaf to null_entry when adding fails or when deleting the
last default route.
syzkaller reported the following issue which is fixed by this commit:
WARNING: suspicious RCU usage
4.15.0-rc5+ #171 Not tainted
-----------------------------
net/ipv6/ip6_fib.c:1702 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
4 locks held by swapper/0/0:
#0: ((&net->ipv6.ip6_fib_timer)){+.-.}, at: [<00000000d43f631b>] lockdep_copy_map include/linux/lockdep.h:178 [inline]
#0: ((&net->ipv6.ip6_fib_timer)){+.-.}, at: [<00000000d43f631b>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1310
#1: (&(&net->ipv6.fib6_gc_lock)->rlock){+.-.}, at: [<000000002ff9d65c>] spin_lock_bh include/linux/spinlock.h:315 [inline]
#1: (&(&net->ipv6.fib6_gc_lock)->rlock){+.-.}, at: [<000000002ff9d65c>] fib6_run_gc+0x9d/0x3c0 net/ipv6/ip6_fib.c:2007
#2: (rcu_read_lock){....}, at: [<0000000091db762d>] __fib6_clean_all+0x0/0x3a0 net/ipv6/ip6_fib.c:1560
#3: (&(&tb->tb6_lock)->rlock){+.-.}, at: [<000000009e503581>] spin_lock_bh include/linux/spinlock.h:315 [inline]
#3: (&(&tb->tb6_lock)->rlock){+.-.}, at: [<000000009e503581>] __fib6_clean_all+0x1d0/0x3a0 net/ipv6/ip6_fib.c:1948
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.15.0-rc5+ #171
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4585
fib6_del+0xcaa/0x11b0 net/ipv6/ip6_fib.c:1701
fib6_clean_node+0x3aa/0x4f0 net/ipv6/ip6_fib.c:1892
fib6_walk_continue+0x46c/0x8a0 net/ipv6/ip6_fib.c:1815
fib6_walk+0x91/0xf0 net/ipv6/ip6_fib.c:1863
fib6_clean_tree+0x1e6/0x340 net/ipv6/ip6_fib.c:1933
__fib6_clean_all+0x1f4/0x3a0 net/ipv6/ip6_fib.c:1949
fib6_clean_all net/ipv6/ip6_fib.c:1960 [inline]
fib6_run_gc+0x16b/0x3c0 net/ipv6/ip6_fib.c:2016
fib6_gc_timer_cb+0x20/0x30 net/ipv6/ip6_fib.c:2033
call_timer_fn+0x228/0x820 kernel/time/timer.c:1320
expire_timers kernel/time/timer.c:1357 [inline]
__run_timers+0x7ee/0xb70 kernel/time/timer.c:1660
run_timer_softirq+0x4c/0xb0 kernel/time/timer.c:1686
__do_softirq+0x2d7/0xb85 kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x1cc/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:540 [inline]
smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:904
</IRQ>
Reported-by: syzbot <syzkaller@googlegroups.com>
Fixes: 66f5d6ce53e6 ("ipv6: replace rwlock with rcu and spinlock in fib6_table")
Signed-off-by: Wei Wang <weiwan@google.com>
---
net/ipv6/ip6_fib.c | 38 +++++++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index d11a5578e4f8..9dcc3924a975 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -640,6 +640,11 @@ static struct fib6_node *fib6_add_1(struct net *net,
if (!(fn->fn_flags & RTN_RTINFO)) {
RCU_INIT_POINTER(fn->leaf, NULL);
rt6_release(leaf);
+ /* remove null_entry in the root node */
+ } else if (fn->fn_flags & RTN_TL_ROOT &&
+ rcu_access_pointer(fn->leaf) ==
+ net->ipv6.ip6_null_entry) {
+ RCU_INIT_POINTER(fn->leaf, NULL);
}
return fn;
@@ -1270,13 +1275,17 @@ int fib6_add(struct fib6_node *root, struct rt6_info *rt,
return err;
failure:
- /* fn->leaf could be NULL if fn is an intermediate node and we
- * failed to add the new route to it in both subtree creation
- * failure and fib6_add_rt2node() failure case.
- * In both cases, fib6_repair_tree() should be called to fix
- * fn->leaf.
+ /* fn->leaf could be NULL and fib6_repair_tree() needs to be called if:
+ * 1. fn is an intermediate node and we failed to add the new
+ * route to it in both subtree creation failure and fib6_add_rt2node()
+ * failure case.
+ * 2. fn is the root node in the table and we fail to add the first
+ * default route to it.
*/
- if (fn && !(fn->fn_flags & (RTN_RTINFO|RTN_ROOT)))
+ if (fn &&
+ (!(fn->fn_flags & (RTN_RTINFO|RTN_ROOT)) ||
+ (fn->fn_flags & RTN_TL_ROOT &&
+ !rcu_access_pointer(fn->leaf))))
fib6_repair_tree(info->nl_net, table, fn);
/* Always release dst as dst->__refcnt is guaranteed
* to be taken before entering this function
@@ -1531,6 +1540,12 @@ static struct fib6_node *fib6_repair_tree(struct net *net,
struct fib6_walker *w;
int iter = 0;
+ /* Set fn->leaf to null_entry for root node. */
+ if (fn->fn_flags & RTN_TL_ROOT) {
+ rcu_assign_pointer(fn->leaf, net->ipv6.ip6_null_entry);
+ return fn;
+ }
+
for (;;) {
struct fib6_node *fn_r = rcu_dereference_protected(fn->right,
lockdep_is_held(&table->tb6_lock));
@@ -1685,10 +1700,15 @@ static void fib6_del_route(struct fib6_table *table, struct fib6_node *fn,
}
read_unlock(&net->ipv6.fib6_walker_lock);
- /* If it was last route, expunge its radix tree node */
+ /* If it was last route, call fib6_repair_tree() to:
+ * 1. For root node, put back null_entry as how the table was created.
+ * 2. For other nodes, expunge its radix tree node.
+ */
if (!rcu_access_pointer(fn->leaf)) {
- fn->fn_flags &= ~RTN_RTINFO;
- net->ipv6.rt6_stats->fib_route_nodes--;
+ if (!(fn->fn_flags & RTN_TL_ROOT)) {
+ fn->fn_flags &= ~RTN_RTINFO;
+ net->ipv6.rt6_stats->fib_route_nodes--;
+ }
fn = fib6_repair_tree(net, table, fn);
}
--
2.16.0.rc0.223.g4a4ac83678-goog
^ permalink raw reply related
* Re: [PATCHv3 0/2] capability controlled user-namespaces
From: Serge E. Hallyn @ 2018-01-08 18:36 UTC (permalink / raw)
To: Mahesh Bandewar (महेश बंडेवार)
Cc: Serge E. Hallyn, James Morris, LKML, Netdev, Kernel-hardening,
Linux API, Kees Cook, Eric W . Biederman, Eric Dumazet,
David Miller, Mahesh Bandewar
In-Reply-To: <CAF2d9jgar8J+mQjUfF=+XdvrcS=RvtOpKysxOiZkG-rXgm0KVw@mail.gmail.com>
Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com):
> On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com):
> >> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> >> > Quoting James Morris (james.l.morris@oracle.com):
> >> >> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
> >> >> I meant in terms of "marking" a user ns as "controlled" type -- it's
> >> >> unnecessary jargon from an end user point of view.
> >> >
> >> > Ah, yes, that was my point in
> >> >
> >> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/01845.html
> >> > and
> >> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/02276.html
> >> >
> >> >> This may happen internally but don't make it a special case with a
> >> >> different name and don't bother users with internal concepts: simply
> >> >> implement capability whitelists with the default having equivalent
> >
> > So the challenge is to have unprivileged users be contained, while
> > allowing trusted workloads in containers created by a root user to
> > bypass the restriction.
> >
> > Now, the current proposal actually doesn't support a root user starting
> > an application that it doesn't quite trust in such a way that it *is*
> > subject to the whitelist.
>
> Well, this is not hard since root process can spawn another process
> and loose privileges before creating user-ns to be controlled by the
> whitelist.
It would have to drop cap_sys_admin for the container to be marked as
"controlled", which may prevent the container runtime from properly starting
the container.
> You need an ability to preserve the creation of user-namespaces that
> exhibit 'the uncontrolled behavior' and only trusted/privileged (root)
> user should have it which is maintained here.
>
> > Which is unfortunate. But apart from using
> > ptags or a cgroup, I can't think of a good way to get us everything we
> > want:
> >
> > 1. unprivileged users always restricted
> > 2. existing unprivileged containers become restricted when whitelist
> > is enabled
> > 3. privileged users are able to create containers which are not restricted
>
> all this is achieved by the patch-set without any changes to the
> application with the above knob.
>
> > 4. privileged users are able to create containers which *are* restricted
> >
> With this patch-set; the root user process can fork another process
> with less privileges before creating a user-ns if the exec-ed process
> cannot be trusted. So there is a way with little modification as
> opposed to nothing available at this moment for this scenario.
^ permalink raw reply
* Re: KASAN: use-after-free Read in tipc_group_size
From: Cong Wang @ 2018-01-08 18:43 UTC (permalink / raw)
To: syzbot
Cc: David Miller, Jon Maloy, LKML, Linux Kernel Network Developers,
syzkaller-bugs, tipc-discussion, Ying Xue
In-Reply-To: <001a1144982043d4af05624506fc@google.com>
On Mon, Jan 8, 2018 at 6:58 AM, syzbot
<syzbot+aae58876fb5a1fad0a4b@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzkaller hit the following crash on
> b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+aae58876fb5a1fad0a4b@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> ==================================================================
> BUG: KASAN: use-after-free in tipc_group_size+0x40/0x50 net/tipc/group.c:158
> Read of size 2 at addr ffff8801c08ba280 by task syzkaller447710/3513
>
> CPU: 0 PID: 3513 Comm: syzkaller447710 Not tainted 4.15.0-rc7+ #252
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> print_address_description+0x73/0x250 mm/kasan/report.c:252
> kasan_report_error mm/kasan/report.c:351 [inline]
> kasan_report+0x25b/0x340 mm/kasan/report.c:409
> __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:428
> tipc_group_size+0x40/0x50 net/tipc/group.c:158
> tipc_poll+0x374/0x4f0 net/tipc/socket.c:739
Seems we have to lock the sock for tipc_group_size() in
tipc_poll().
> sock_poll+0x141/0x320 net/socket.c:1117
> do_pollfd fs/select.c:822 [inline]
> do_poll fs/select.c:872 [inline]
> do_sys_poll+0x715/0x10b0 fs/select.c:966
> SYSC_poll fs/select.c:1024 [inline]
> SyS_poll+0x10d/0x450 fs/select.c:1012
> entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x445cb9
> RSP: 002b:00007f04886b1ce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000007
> RAX: ffffffffffffffda RBX: 00000000006dac3c RCX: 0000000000445cb9
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000020fa2ff8
> RBP: 00000000006dac38 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007ffc84d56d7f R14: 00007f04886b29c0 R15: 0000000000000005
>
> Allocated by task 3510:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
> kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3610
> kmalloc include/linux/slab.h:499 [inline]
> kzalloc include/linux/slab.h:688 [inline]
> tipc_group_create+0x116/0x9c0 net/tipc/group.c:167
> tipc_sk_join net/tipc/socket.c:2747 [inline]
> tipc_setsockopt+0x249/0xc10 net/tipc/socket.c:2861
> SYSC_setsockopt net/socket.c:1829 [inline]
> SyS_setsockopt+0x189/0x360 net/socket.c:1808
> entry_SYSCALL_64_fastpath+0x23/0x9a
>
> Freed by task 3510:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
> __cache_free mm/slab.c:3488 [inline]
> kfree+0xd6/0x260 mm/slab.c:3803
> tipc_group_delete+0x2c8/0x3d0 net/tipc/group.c:206
> tipc_sk_join net/tipc/socket.c:2760 [inline]
> tipc_setsockopt+0xb0d/0xc10 net/tipc/socket.c:2861
> SYSC_setsockopt net/socket.c:1829 [inline]
> SyS_setsockopt+0x189/0x360 net/socket.c:1808
> entry_SYSCALL_64_fastpath+0x23/0x9a
>
> The buggy address belongs to the object at ffff8801c08ba200
> which belongs to the cache kmalloc-192 of size 192
> The buggy address is located 128 bytes inside of
> 192-byte region [ffff8801c08ba200, ffff8801c08ba2c0)
> The buggy address belongs to the page:
> page:ffffea0007022e80 count:1 mapcount:0 mapping:ffff8801c08ba000 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffff8801c08ba000 0000000000000000 0000000100000010
> raw: ffffea00071338a0 ffffea0006fe2360 ffff8801dac00040 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801c08ba180: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ffff8801c08ba200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>
>> ffff8801c08ba280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>
> ^
> ffff8801c08ba300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c08ba380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH bpf] bpf: prevent out-of-bounds speculation
From: Linus Torvalds @ 2018-01-08 18:49 UTC (permalink / raw)
To: Mark Rutland
Cc: Alexei Starovoitov, David S . Miller, Daniel Borkmann, Jann Horn,
Dan Williams, Peter Zijlstra, Elena Reshetova, Alan Cox,
Network Development, kernel-team, Will Deacon
In-Reply-To: <20180108170553.yrs46fawfpr62wtr@lakrids.cambridge.arm.com>
On Mon, Jan 8, 2018 at 9:05 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>
> I'm a little worried that in the presence of some CPU/compiler
> optimisations, the masking may effectively be skipped under speculation.
> So I'm not sure how robust this is going to be.
Honestly, I think the masking is a hell of a lot more robust than any
of the "official" fixes.
More generic data speculation (as opposed to control speculation) is
(a) mainly academic masturbation
(b) hasn't even been shown to be a good idea even in _theory_ yet
(except for the "completely unreal hardware" kind of theory where
people assume some data oracle)
(c) isn't actually done in any real CPU's today that I'm aware of
(unless you want to call the return stack data speculation).
and the thing is, we should really not then worry about "... but maybe
future CPU's will be more aggressive", which is the traditional worry
in these kinds of cases.
Why? Because quite honestly, any future CPU's that are more aggressive
about speculating things like this are broken shit that we should call
out as such, and tell people not to use.
Seriously.
In this particular case, we should be very much aware of future CPU's
being more _constrained_, because CPU vendors had better start taking
this thing into account.
So the masking approach is FUNDAMENTALLY SAFER than the "let's try to
limit control speculation".
If somebody can point to a CPU that actually speculates across an
address masking operation, I will be very surprised. And unless you
can point to that, then stop trying to dismiss the masking approach.
The only thing we need to be really really careful about is to make
sure that the mask generation itself is not in a control speculation
path.
IOW, the mask really has to be a true data dependency, and has to be
generated arithmetically. Because if the mask generation has a control
dependency on it, then obviously that defeats the whole "make sure we
don't have control speculation" approach.
Linus
^ permalink raw reply
* Re: [PATCHv3 0/2] capability controlled user-namespaces
From: Mahesh Bandewar (महेश बंडेवार) @ 2018-01-08 18:55 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: James Morris, LKML, Netdev, Kernel-hardening, Linux API,
Kees Cook, Eric W . Biederman, Eric Dumazet, David Miller,
Mahesh Bandewar
In-Reply-To: <20180108183610.GA562@mail.hallyn.com>
On Mon, Jan 8, 2018 at 10:36 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com):
>> On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
>> > Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com):
>> >> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
>> >> > Quoting James Morris (james.l.morris@oracle.com):
>> >> >> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
>> >> >> I meant in terms of "marking" a user ns as "controlled" type -- it's
>> >> >> unnecessary jargon from an end user point of view.
>> >> >
>> >> > Ah, yes, that was my point in
>> >> >
>> >> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/01845.html
>> >> > and
>> >> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/02276.html
>> >> >
>> >> >> This may happen internally but don't make it a special case with a
>> >> >> different name and don't bother users with internal concepts: simply
>> >> >> implement capability whitelists with the default having equivalent
>> >
>> > So the challenge is to have unprivileged users be contained, while
>> > allowing trusted workloads in containers created by a root user to
>> > bypass the restriction.
>> >
>> > Now, the current proposal actually doesn't support a root user starting
>> > an application that it doesn't quite trust in such a way that it *is*
>> > subject to the whitelist.
>>
>> Well, this is not hard since root process can spawn another process
>> and loose privileges before creating user-ns to be controlled by the
>> whitelist.
>
> It would have to drop cap_sys_admin for the container to be marked as
> "controlled", which may prevent the container runtime from properly starting
> the container.
>
Yes, but that's a conflict of trusted operations (that requires
SYS_ADMIN) and untrusted processes it may spawn.
>> You need an ability to preserve the creation of user-namespaces that
>> exhibit 'the uncontrolled behavior' and only trusted/privileged (root)
>> user should have it which is maintained here.
>>
>> > Which is unfortunate. But apart from using
>> > ptags or a cgroup, I can't think of a good way to get us everything we
>> > want:
>> >
>> > 1. unprivileged users always restricted
>> > 2. existing unprivileged containers become restricted when whitelist
>> > is enabled
>> > 3. privileged users are able to create containers which are not restricted
>>
>> all this is achieved by the patch-set without any changes to the
>> application with the above knob.
>>
>> > 4. privileged users are able to create containers which *are* restricted
>> >
>> With this patch-set; the root user process can fork another process
>> with less privileges before creating a user-ns if the exec-ed process
>> cannot be trusted. So there is a way with little modification as
>> opposed to nothing available at this moment for this scenario.
^ permalink raw reply
* Re: [PATCH net-next v3 RESEND 00/10] net: qualcomm: rmnet: Enable csum offloads
From: David Miller @ 2018-01-08 19:01 UTC (permalink / raw)
To: subashab; +Cc: netdev, lkp, edumazet
In-Reply-To: <1515350200-29472-1-git-send-email-subashab@codeaurora.org>
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Sun, 7 Jan 2018 11:36:30 -0700
> This series introduces the MAPv4 packet format for checksum
> offload plus some other minor changes.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 00/20] add some new features and fix some bugs for HNS3 driver
From: David Miller @ 2018-01-08 19:08 UTC (permalink / raw)
To: lipeng321; +Cc: netdev, linux-kernel, linuxarm, salil.mehta
In-Reply-To: <1515147504-86802-1-git-send-email-lipeng321@huawei.com>
From: Peng Li <lipeng321@huawei.com>
Date: Fri, 5 Jan 2018 18:18:04 +0800
> This patchset adds some new features support and fixes some bugs:
> [Patch 1/20] adds support to enable/disable vlan filter with ethtool
> [Patch 2/20] disables VFs change rxvlan offload status
> [Patch 3/20 - 13/120 fix bugs and refine some codes for packet
> statistics, support query with both ifconfig and ethtool.
> [Patch 14/20 - 20/20] fix some other bugs.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH] sh_eth: remove sh_eth_plat_data::edmac_endian
From: David Miller @ 2018-01-08 19:10 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: ysato, dalias, linux-sh, netdev, linux-renesas-soc
In-Reply-To: <20180104212654.038005757@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Fri, 05 Jan 2018 00:26:46 +0300
> Since the commit 888cc8c20cf ("sh_eth: remove EDMAC_BIG_ENDIAN") (geez,
> I didn't realize that was 2 years ago!) the initializers in the SuperH
> platform code for the 'sh_eth_plat_data::edmac_endian' stopped to matter,
> so we can remove that field for good (not sure if it was ever useful --
> SH7786 Ether has been reported to have the same EDMAC descriptor/register
> endiannes as configured for the SuperH CPU)...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> The patch is against DaveM's 'net-next.git' repo.
> Not sure who should apply the patch -- will prolly be faster if DaveM does...
Applied, thanks Sergei.
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Allow connect to linklocal address from socket bound to vrf
From: David Miller @ 2018-01-08 19:11 UTC (permalink / raw)
To: dsahern; +Cc: netdev
In-Reply-To: <20180104220354.30524-1-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Thu, 4 Jan 2018 14:03:54 -0800
> Allow a process bound to a VRF to connect to a linklocal address.
> Currently, this fails because of a mismatch between the scope of the
> linklocal address and the sk_bound_dev_if inherited by the VRF binding:
> $ ssh -6 fe80::70b8:cff:fedd:ead8%eth1
> ssh: connect to host fe80::70b8:cff:fedd:ead8%eth1 port 22: Invalid argument
>
> Relax the scope check to allow the socket to be bound to the same L3
> device as the scope id.
>
> This makes ipv6 linklocal consistent with other relaxed checks enabled
> by commits 1ff23beebdd3 ("net: l3mdev: Allow send on enslaved interface")
> and 7bb387c5ab12a ("net: Allow IP_MULTICAST_IF to set index to L3 slave").
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied, thanks David.
^ permalink raw reply
* Re: [PATCH net-next] tcp: Split BUG_ON() in tcp_tso_should_defer() into two assertions
From: David Miller @ 2018-01-08 19:12 UTC (permalink / raw)
To: sbrivio; +Cc: eric.dumazet, netdev
In-Reply-To: <da6e8a83cd13eebf18aa208a14ddfbeef1fab4a7.1515108700.git.sbrivio@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Fri, 5 Jan 2018 00:38:05 +0100
> The two conditions triggering BUG_ON() are somewhat unrelated:
> the tcp_skb_pcount() check is meant to catch TSO flaws, the
> second one checks sanity of congestion window bookkeeping.
>
> Split them into two separate BUG_ON() assertions on two lines,
> so that we know which one actually triggers, when they do.
>
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/2] bnxt_en: 2 small bug fixes.
From: David Miller @ 2018-01-08 19:13 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1515109615-22695-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Thu, 4 Jan 2018 18:46:53 -0500
> The first one fixes the TC Flower flow parameter passed to firmware. The
> 2nd one fixes the VF index range checking for iproute2 SRIOV related commands.
Series applied, thank you.
^ permalink raw reply
* Re: dvb usb issues since kernel 4.9
From: Alan Stern @ 2018-01-08 19:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, Mauro Carvalho Chehab, Josef Griebichler,
Greg Kroah-Hartman, USB list, Eric Dumazet, Rik van Riel,
Paolo Abeni, Hannes Frederic Sowa, Jesper Dangaard Brouer,
linux-kernel, netdev, Jonathan Corbet, LMML, Peter Zijlstra,
David Miller
In-Reply-To: <CA+55aFx90oOU-3R8pCeM0ESTDYhmugD5znA9LrGj1zhazWBtcg@mail.gmail.com>
On Mon, 8 Jan 2018, Linus Torvalds wrote:
> Can somebody tell which softirq it is that dvb/usb cares about?
I don't know about the DVB part. The USB part is a little difficult to
analyze, mostly because the bug reports I've seen are mostly from
people running non-vanilla kernels. For example, Josef is using a
Raspberry Pi 3B with a non-standard USB host controller driver:
dwc_otg_hcd is built into raspbian in place of the normal dwc2_hsotg
driver.
Both dwc2_hsotg and ehci-hcd use the tasklets embedded in the
giveback_urb_bh member of struct usb_hcd. See usb_hcd_giveback_urb()
in drivers/usb/core/hcd.c; the calls are
else if (high_prio_bh)
tasklet_hi_schedule(&bh->bh);
else
tasklet_schedule(&bh->bh);
As it turns out, high_prio_bh gets set for interrupt and isochronous
URBs but not for bulk and control URBs. The DVB driver in question
uses bulk transfers.
xhci-hcd, on the other hand, does not use these tasklets (it doesn't
set the HCD_BH bit in the hc_driver's .flags member).
Alan Stern
^ permalink raw reply
* Re: [PATCH NET-NEXT 1/1] forcedeth: remove duplicate structure member in rx
From: David Miller @ 2018-01-08 19:15 UTC (permalink / raw)
To: yanjun.zhu; +Cc: keescook, netdev
In-Reply-To: <1515125199-4314-1-git-send-email-yanjun.zhu@oracle.com>
From: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Thu, 4 Jan 2018 23:06:39 -0500
> Since both first_rx and rx_ring are the head of rx ring, it not
> necessary to use two structure members to statically indicate
> the head of rx ring. So first_rx is removed.
>
> CC: Srinivas Eeda <srinivas.eeda@oracle.com>
> CC: Joe Jin <joe.jin@oracle.com>
> CC: Junxiao Bi <junxiao.bi@oracle.com>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net v2] ipv6: remove null_entry before adding default route
From: Martin KaFai Lau @ 2018-01-08 19:15 UTC (permalink / raw)
To: Wei Wang; +Cc: David Miller, netdev, Eric Dumazet
In-Reply-To: <20180108183400.206017-1-tracywwnj@gmail.com>
On Mon, Jan 08, 2018 at 10:34:00AM -0800, Wei Wang wrote:
> From: Wei Wang <weiwan@google.com>
>
> In the current code, when creating a new fib6 table, tb6_root.leaf gets
> initialized to net->ipv6.ip6_null_entry.
> If a default route is being added with rt->rt6i_metric = 0xffffffff,
> fib6_add() will add this route after net->ipv6.ip6_null_entry. As
> null_entry is shared, it could cause problem.
>
> In order to fix it, set fn->leaf to NULL before calling
> fib6_add_rt2node() when trying to add the first default route.
> And reset fn->leaf to null_entry when adding fails or when deleting the
> last default route.
Thanks for the fix!
Acked-by: Martin KaFai Lau <kafai@fb.com>
^ permalink raw reply
* Re: [PATCH] xen-netfront: enable device after manual module load
From: David Miller @ 2018-01-08 19:17 UTC (permalink / raw)
To: otubo
Cc: linux-kernel, netdev, xen-devel, jgross, boris.ostrovsky,
vkuznets, mgamal, cavery
In-Reply-To: <20180105084216.21719-1-otubo@redhat.com>
From: Eduardo Otubo <otubo@redhat.com>
Date: Fri, 5 Jan 2018 09:42:16 +0100
> When loading the module after unloading it, the network interface would
> not be enabled and thus wouldn't have a backend counterpart and unable
> to be used by the guest.
>
> The guest would face errors like:
>
> [root@guest ~]# ethtool -i eth0
> Cannot get driver information: No such device
>
> [root@guest ~]# ifconfig eth0
> eth0: error fetching interface information: Device not found
>
> This patch initializes the state of the netfront device whenever it is
> loaded manually, this state would communicate the netback to create its
> device and establish the connection between them.
>
> Signed-off-by: Eduardo Otubo <otubo@redhat.com>
Applied, thank you.
^ 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