From: Yu Chen
On Sat, 21 Sep 2019 15:51:38, Russell King - ARM Linux admin wrote:
> On Sat, Sep 21, 2019 at 09:02:49PM +0800, Yu Chen wrote:
> > From: Yu Chen
> >
> > memblock reserved regions are not reported via /proc/iomem on ARM, kexec's
> > user-space doesn't know about
On Thu, Sep 19, 2019 at 12:37:40PM -0400, Boris Ostrovsky wrote:
> On 9/19/19 12:14 PM, James Dingwall wrote:
> > On Thu, Sep 19, 2019 at 03:51:33PM +, Luck, Tony wrote:
> >>> I have been investigating a regression in our environment where pstore
> >>> (efi-pstore specifically but I suspect
On Fri, Sep 20, 2019 at 05:24:52PM -0400, Andrea Arcangeli wrote:
> Andrea Arcangeli (17):
> x86: spec_ctrl: fix SPEC_CTRL initialization after kexec
> KVM: monolithic: x86: convert the kvm_x86_ops methods to external
> functions
> KVM: monolithic: x86: handle the request_immediate_exit
Hi,
> > FYI, we noticed the following commit (built with gcc-7):
> > commit: 12abeb544d548f55f56323fc6e5e6c0fb74f58e1 ("horrible test hack")
> > https://kernel.googlesource.com/pub/scm/linux/kernel/git/luto/linux.git
> > random/kill-it
...
> > tst_test.c:1108: INFO: Timeout per run is 0h 05m
On Mon, Sep 23, 2019 at 08:28:00AM -0700, Alexander Duyck wrote:
> On Mon, Sep 23, 2019 at 8:00 AM Michael S. Tsirkin wrote:
> >
> > On Mon, Sep 23, 2019 at 07:50:15AM -0700, Alexander Duyck wrote:
> > > > > +static inline void
> > > > > +page_reporting_reset_boundary(struct zone *zone, unsigned
On 9/22/2019 11:35 AM, Linus Torvalds wrote:
> On Sat, Sep 21, 2019 at 4:10 PM Paul Burton wrote:
>>
>> Here are the main MIPS changes for v5.4; please pull.
>
> Hmm. I pulled and because initial tests didn't show any issues, I
> already pushed out.
>
> But some unrelated further testing
On Mon, Sep 16, 2019 at 06:22:57PM +0200, Vitaly Kuznetsov wrote:
> Hyper-V 2019 doesn't expose MD_CLEAR CPUID bit to guests when it cannot
> guarantee that two virtual processors won't end up running on sibling SMT
> threads without knowing about it. This is done as an optimization as in
> this
On 9/20/19 5:10 PM, Linus Torvalds wrote:
> On Fri, Sep 20, 2019 at 4:05 PM Linus Torvalds
> wrote:
>>
>>
>> Now, I hear you say "those are so small these days that it doesn't
>> matter". And maybe you're right. But particularly for slow media,
>> triggering good streaming write behavior has been
On 9/20/19 12:00 PM, Jason Baron wrote:
> On 9/19/19 5:24 AM, hev wrote:
>> From: Heiher
>>
>> Take the case where we have:
>>
>> t0
>> | (ew)
>> e0
>> | (et)
>> e1
>> | (lt)
>> s0
>>
>> t0: thread 0
>> e0: epoll fd 0
>> e1: epoll fd 1
On Mon, Sep 23, 2019 at 12:22:23PM +0200, Paolo Bonzini wrote:
> On 20/09/19 23:24, Andrea Arcangeli wrote:
> > We can't assume the SPEC_CTRL msr is zero at boot because it could be
> > left enabled by a previous kernel booted with
> > spec_store_bypass_disable=on.
> >
> > Without this fix a boot
On Mon, Sep 23, 2019 at 8:00 AM Michael S. Tsirkin wrote:
>
> On Mon, Sep 23, 2019 at 07:50:15AM -0700, Alexander Duyck wrote:
> > > > +static inline void
> > > > +page_reporting_reset_boundary(struct zone *zone, unsigned int order,
> > > > int mt)
> > > > +{
> > > > + int index;
> > > > +
>
On 9/20/19 5:41 PM, Eugene Syromiatnikov wrote:
> Hello.
>
> As of now, it's a bit difficult to use SMC protocol, as significant part
> of definitions related to it are defined in private headers and are not
> part of UAPI. The following commits move some definitions to UAPI,
> making them
Hi,
I've found a bug on s390 on small MTU combined with big packet size, using ping
(of course both within valid ranges, e.g. MTU 552 and packet size 61245).
Below is full reproducer on netns.
I tested it on vanilla: v5.3-rc8 and v4.16.
I reproduced it on current iputils master which uses
Apparently even with this (certainly correct) patch attached, users
are still experiencing problems. Bug hunting continues, and I'll
report back if I figure something out.
Jacek
On 9/21/19 10:13 AM, Jacek Anaszewski wrote:
Dan,
On 9/20/19 7:41 PM, Dan Murphy wrote:
Introduce the bindings for the Texas Instruments LP5036, LP5030, LP5024,
LP5018, LP5012 and LP5009 RGB LED device driver. The LP5036/30/24/18/12/9
can control RGB LEDs individually or as part of a
On Mon, Sep 23, 2019 at 11:11:55PM +0800, Sam Shih wrote:
> On Mon, 2019-09-23 at 15:36 +0200, Thierry Reding wrote:
> > On Mon, Sep 23, 2019 at 11:20:57AM +0800, Sam Shih wrote:
> > > On Sat, 2019-09-21 at 02:21 +0200, Thierry Reding wrote:
> > > > On Fri, Sep 20, 2019 at 06:49:07AM +0800, Sam
Hello,
On Mon, Sep 23, 2019 at 06:06:46PM +0300, Konstantin Khlebnikov wrote:
> On 23/09/2019 17.52, Tejun Heo wrote:
> >Hello, Konstantin.
> >
> >On Fri, Sep 20, 2019 at 10:39:33AM +0300, Konstantin Khlebnikov wrote:
> >>With vm.dirty_write_behind 1 or 2 files are written even faster and
> >
>
On Mon, 23 Sep 2019 11:52:49 -0300
Arnaldo Carvalho de Melo wrote:
> Em Mon, Sep 23, 2019 at 11:39:27AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Mon, Sep 23, 2019 at 11:28:39AM -0300, Arnaldo Carvalho de Melo
> > escreveu:
> > > Em Thu, Sep 19, 2019 at 05:23:35PM -0400, Steven Rostedt
On Mon, Sep 23, 2019 at 8:56 AM Sandy Huang wrote:
>
> cpp[BytePerPlane] can't describe the 10bit data format correctly,
> So we use bpp[BitPerPlane] to instead cpp.
>
> Signed-off-by: Sandy Huang
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 ---
>
On Mon, Sep 23, 2019 at 4:31 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:e0bd8d79 usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output:
On Mon, 2019-09-23 at 15:36 +0200, Thierry Reding wrote:
> On Mon, Sep 23, 2019 at 11:20:57AM +0800, Sam Shih wrote:
> > On Sat, 2019-09-21 at 02:21 +0200, Thierry Reding wrote:
> > > On Fri, Sep 20, 2019 at 06:49:07AM +0800, Sam Shih wrote:
> > > > From: Ryder Lee
> > > >
> > > > This adds a
On Mon, Sep 23, 2019 at 12:05:33PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Sep 13, 2019 at 03:22:52PM +0200, Jiri Olsa escreveu:
> > Add the perf_mmap to libperf.
> >
> > The definition is added into:
> >
> > include/internal/mmap.h
> >
> > which is not to be included by users, but
On Mon, 2019-09-23 at 17:06 +0200, Philipp Puschmann wrote:
> Thanks for testing.
> With my local setup i still have very few tx timeouts too. But i think they
> have a different
> cause and especially different consequences. When the problem addressed by
> this series
> appear you get a whole
Jacek
On 9/21/19 8:30 AM, Jacek Anaszewski wrote:
Dan,
On 9/20/19 7:41 PM, Dan Murphy wrote:
Introduce a multicolor class that groups colored LEDs
within a LED node.
The framework allows for dynamically setting individual LEDs
or setting brightness levels of LEDs and updating them virtually
On Wed, Sep 11, 2019 at 08:49:26AM +0200, Michal Hocko wrote:
> On Wed 11-09-19 14:15:51, Yunsheng Lin wrote:
> > >> When passing the return value of dev_to_node() to cpumask_of_node()
> > >> without checking the node id if the node id is not valid, there is
> > >>
On 9/23/2019 7:57 AM, Marc Zyngier wrote:
> On 23/09/2019 15:39, Florian Fainelli wrote:
>>
>>
>> On 9/23/2019 1:52 AM, Marc Zyngier wrote:
>>> On 22/09/2019 20:08, Florian Fainelli wrote:
On 9/22/2019 5:38 AM, Marc Zyngier wrote:
> On Fri, 13 Sep 2019 12:15:42 -0700
>
On 23/09/2019 17.52, Tejun Heo wrote:
Hello, Konstantin.
On Fri, Sep 20, 2019 at 10:39:33AM +0300, Konstantin Khlebnikov wrote:
With vm.dirty_write_behind 1 or 2 files are written even faster and
Is the faster speed reproducible? I don't quite understand why this
would be.
Writing to disk
Hi Adam,
Am 23.09.19 um 16:55 schrieb Adam Ford:
> On Mon, Sep 23, 2019 at 8:58 AM Philipp Puschmann
> wrote:
>>
>> For some years and since many kernel versions there are reports that
>> RX UART DMA channel stops working at one point. So far the usual
>> workaround was to disable RX DMA. This
Jacek
On 9/21/19 1:08 PM, Jacek Anaszewski wrote:
Dan,
One more remark below.
On 9/20/19 7:41 PM, Dan Murphy wrote:
Introduce a multicolor class that groups colored LEDs
within a LED node.
The framework allows for dynamically setting individual LEDs
or setting brightness levels of LEDs and
Em Fri, Sep 13, 2019 at 03:22:52PM +0200, Jiri Olsa escreveu:
> Add the perf_mmap to libperf.
>
> The definition is added into:
>
> include/internal/mmap.h
>
> which is not to be included by users, but shared
> within perf and libperf.
> diff --git a/tools/perf/lib/include/internal/mmap.h
>
On Mon, Sep 23, 2019 at 03:31:59PM +0300, Adrian Hunter wrote:
> Should have Acked this ages ago, sorry :-(
>
> Acked-by: Adrian Hunter
Thanks, and no worries :)
Ulf, The patch set is ready to merge now :)
Hi,
> People are reporting that WireGuard experiences erratic crashes on 5.3,
> and bisected it down to 7d30a7f6424e. Casually flipping through that
> commit I noticed that a flag is checked using `|` instead of `&`, which in
> this current case, means that a reference is never incremented, which
On Mon, 23 Sep 2019, Ran Wang wrote:
> USB 2.0 Embedded Host PET Automated Test (CH6) 6.7.23 A-UUT "Unsupported
> Device" Message require to stop enumerating device with VID=0x1a0a PID=0x0201
> and pop message to declare this device is not supported.
>
> Signed-off-by: Ran Wang
> ---
>
On Mon, Sep 23, 2019 at 07:50:15AM -0700, Alexander Duyck wrote:
> > > +static inline void
> > > +page_reporting_reset_boundary(struct zone *zone, unsigned int order, int
> > > mt)
> > > +{
> > > + int index;
> > > +
> > > + if (order < PAGE_REPORTING_MIN_ORDER)
> > > +
On Mon, 23 Sep 2019, Greg KH wrote:
> On Mon, Sep 23, 2019 at 03:19:21PM +0900, Austin Kim wrote:
> > Normally when creation of workqueue fails, exception handling takes place
> > after the call to alloc_workqueue() is made.
> >
> > But looking into usb_hub_init() function, 'return 0' statement
On 23/09/2019 15:39, Florian Fainelli wrote:
>
>
> On 9/23/2019 1:52 AM, Marc Zyngier wrote:
>> On 22/09/2019 20:08, Florian Fainelli wrote:
>>>
>>>
>>> On 9/22/2019 5:38 AM, Marc Zyngier wrote:
On Fri, 13 Sep 2019 12:15:42 -0700
Florian Fainelli wrote:
> On some specific
From: Thomas Gleixner
Similar to creating timers on a process there is no restriction at all to
read the Posix CPU clocks of any process in the system. Per thread CPU
clock access is limited to threads in the same thread group.
The per process CPU clocks can be used to observe activity of tasks
From: Thomas Gleixner
The thread clock permissions are restricted to tasks of the same thread
group, but that also prevents a ptracer from reading them. This is
inconsistent vs. the process restrictions and unnecessary strict.
Relax it to ptrace permissions in the same way as process
When cleaning up posix-cpu-timers I discovered that the permission checks
for process clocks and process timers are completely bonkers. The only
requirement is that the target PID is a group leader. Which means that any
process can read the clocks and attach timers to any other process without
Returning -EINVAL when a permission check fails is not really intuitive and
can cause hard to diagnose problems.
The POSIX specification for clock_gettime() and timer_create() requires to
obtain the clock id first by invoking clock_getcpuclockid().
clock_getcpuclockid() can return -EPERM if the
From: Thomas Gleixner
If the PID encoded into the clock id is 0 then the target is either the
calling thread itself or the process to which it belongs.
If the current thread encodes its own PID on a process wide clock then
there is no reason not to treat it in the same way as the PID=0 case.
From: Thomas Gleixner
Right now there is no restriction at all to attach a Posix CPU timer to any
process in the system. Per thread CPU timers are limited to be created by
threads in the same thread group.
Timers can be used to observe activity of tasks and also impose overhead on
the process
To prepare for changing the return code to -EPERM when the ptrace
permission check fails, use PTR_ERR() to return the error information from
lookup_task() and fixup all call sites.
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
kernel/time/posix-cpu-timers.c | 22 --
On Mon, Sep 23, 2019 at 8:58 AM Philipp Puschmann
wrote:
>
> For some years and since many kernel versions there are reports that
> RX UART DMA channel stops working at one point. So far the usual
> workaround was to disable RX DMA. This patches fix the underlying
> problem.
>
> When a running
- On Sep 23, 2019, at 5:06 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Thu, Sep 19, 2019 at 01:36:58PM -0400, Mathieu Desnoyers wrote:
>> Hi,
>>
>> Those series of fixes and cleanups are initially motivated by the report
>> of race in membarrier, which can load
The previous inline comment stated that a size of zero would make the
ashmem_read_iter function return EOF, but it returned 0 instead.
Looking at other functions, such as ashmem_llseek or ashmem_mmap, it
appears the convention is to return -EINVAL if the region size is unset or
zero.
To be
People are reporting that WireGuard experiences erratic crashes on 5.3,
and bisected it down to 7d30a7f6424e. Casually flipping through that
commit I noticed that a flag is checked using `|` instead of `&`, which in
this current case, means that a reference is never incremented, which
would result
Hello, Konstantin.
On Fri, Sep 20, 2019 at 10:39:33AM +0300, Konstantin Khlebnikov wrote:
> With vm.dirty_write_behind 1 or 2 files are written even faster and
Is the faster speed reproducible? I don't quite understand why this
would be.
> during copying amount of dirty memory always stays
Em Mon, Sep 23, 2019 at 11:39:27AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Sep 23, 2019 at 11:28:39AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Sep 19, 2019 at 05:23:35PM -0400, Steven Rostedt escreveu:
> > > Hi Arnaldo,
> > >
> > > This is a series of man page updates to
On Mon, Sep 23, 2019 at 1:16 AM Michael S. Tsirkin wrote:
>
> On Wed, Sep 18, 2019 at 10:52:49AM -0700, Alexander Duyck wrote:
> > From: Alexander Duyck
> >
> > In order to pave the way for free page reporting in virtualized
> > environments we will need a way to get pages out of the free lists
On Wed 11-09-19 19:46:46, yoav rubin wrote:
> Apologize in advance if I'm sending this to the wrong place. (It's my
> first time using mailing list...)
>
>
> I need some help understanding the exact relations between the linux
> kernel virtual space , specifically LOWMEM area , and the available
On Thu, Sep 19, 2019 at 02:59:06PM +0100, David Howells wrote:
> But I don't agree with this. You're missing half the barriers. There should
> be *four* barriers. The document mandates only 3 barriers, and uses
> READ_ONCE() where the fourth should be, i.e.:
>
>thread #1thread
Jacek
On 9/21/19 7:57 AM, Jacek Anaszewski wrote:
Dan,
On 9/20/19 7:41 PM, Dan Murphy wrote:
Add DT bindings for the LEDs multicolor class framework.
Signed-off-by: Dan Murphy
---
.../bindings/leds/leds-class-multicolor.txt | 95 +++
1 file changed, 95 insertions(+)
On Mon, Sep 23, 2019 at 12:53:09PM +0200, Florian Weimer wrote:
> * Michael Kerrisk:
>
> > SYNOPSIS
> >int pidfd_open(pid_t pid, unsigned int flags);
>
> Should this mention for pid_t?
>
> > ERRORS
> >EINVAL flags is not 0.
> >
> >EINVAL pid is not valid.
> >
> >
Jacek
Thanks for the review
On 9/21/19 7:28 AM, Jacek Anaszewski wrote:
Dan,
On 9/20/19 7:41 PM, Dan Murphy wrote:
Add the support documentation on the multicolor LED framework.
This document defines the directores and file generated by the
Now there will be one directory created.
Apart
On 9/22/19 5:52 AM, Greg KH wrote:
On Sun, Sep 22, 2019 at 01:25:55PM +0200, Ingo Molnar wrote:
* Linus Torvalds wrote:
On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
wrote:
Sorry about that. I am surprised that none of the other reviewers
brought this up.
I think I'm "special".
On 9/23/2019 1:52 AM, Marc Zyngier wrote:
> On 22/09/2019 20:08, Florian Fainelli wrote:
>>
>>
>> On 9/22/2019 5:38 AM, Marc Zyngier wrote:
>>> On Fri, 13 Sep 2019 12:15:42 -0700
>>> Florian Fainelli wrote:
>>>
On some specific chips like 7211 we need to leave some interrupts
Em Mon, Sep 23, 2019 at 11:28:39AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Sep 19, 2019 at 05:23:35PM -0400, Steven Rostedt escreveu:
> > Hi Arnaldo,
> >
> > This is a series of man page updates to the libtraceevent code, as
> > well as a fix to one missing prototype and some movement
On Mon, Sep 23, 2019 at 11:11:53AM +0200, Michael Kerrisk (man-pages) wrote:
> Hello Christian and all,
>
> Below, I have the rendered version of the current draft of
> the pidfd_open(2) manual page that I have written.
> The page source can be found in a Git branch at:
>
From: Rain River
Yanjun has been spending quite a lot of time fixing bugs
in FORCEDETH source code. I'd like to add Yanjun to maintainers
list.
Signed-off-by: Rain River
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
Since the enabling and disabling of IRQs within preempt_schedule_irq()
is contained in a need_resched() loop, we don't need the outer arch
code loop.
Signed-off-by: Valentin Schneider
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
---
arch/sh/kernel/cpu/sh5/entry.S | 5 +
I've left this to ~rot~ age out in the sun for a while, apologies for that.
One early new-year resolution for me is to maintain a shorter resend
timeout on this.
This is the continuation of [1] where I'm hunting down
preempt_schedule_irq() callers because of [2]. I've looked at users of
Since the enabling and disabling of IRQs within preempt_schedule_irq()
is contained in a need_resched() loop, we don't need the outer arch
code loop.
Acked-by: Mark Salter
Signed-off-by: Valentin Schneider
Cc: Aurelien Jacquiot
Cc: linux-c6x-...@linux-c6x.org
---
arch/c6x/kernel/entry.S | 3
Since the enabling and disabling of IRQs within preempt_schedule_irq()
is contained in a need_resched() loop, we don't need the outer arch
code loop.
Signed-off-by: Valentin Schneider
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
---
arch/sh/kernel/entry-common.S | 4 +---
1
preempt_schedule_irq() is the one that should be called on return from
interrupt, clean up the comment to avoid any ambiguity.
Acked-by: Thomas Gleixner
Signed-off-by: Valentin Schneider
Cc: Ingo Molnar
Cc: Peter Zijlstra
---
kernel/sched/core.c | 7 +++
1 file changed, 3 insertions(+),
Since the enabling and disabling of IRQs within preempt_schedule_irq()
is contained in a need_resched() loop, we don't need the outer arch
code loop.
Signed-off-by: Valentin Schneider
Cc: Yoshinori Sato
Cc: uclinux-h8-de...@lists.sourceforge.jp
---
arch/h8300/kernel/entry.S | 3 +--
1 file
Since the enabling and disabling of IRQs within preempt_schedule_irq()
is contained in a need_resched() loop, we don't need the outer arch
code loop.
Acked-by: Max Filippov
Signed-off-by: Valentin Schneider
Cc: Chris Zankel
Cc: linux-xte...@linux-xtensa.org
---
arch/xtensa/kernel/entry.S | 2
Since the enabling and disabling of IRQs within preempt_schedule_irq()
is contained in a need_resched() loop, we don't need the outer arch
code loop.
Acked-by: Guo Ren
Signed-off-by: Valentin Schneider
---
arch/csky/kernel/entry.S | 4
1 file changed, 4 deletions(-)
diff --git
Since the enabling and disabling of IRQs within preempt_schedule_irq()
is contained in a need_resched() loop, we don't need the outer arch
code loop.
Reviewed-by: Palmer Dabbelt
Signed-off-by: Valentin Schneider
Cc: Albert Ou
Cc: linux-ri...@lists.infradead.org
---
arch/riscv/kernel/entry.S |
Since the enabling and disabling of IRQs within preempt_schedule_irq()
is contained in a need_resched() loop, we don't need the outer arch
code loop.
Signed-off-by: Valentin Schneider
Cc: Michal Simek
---
arch/microblaze/kernel/entry.S | 5 -
1 file changed, 5 deletions(-)
diff --git
On 19/09/2019 13:32, Alyssa Rosenzweig wrote:
>>> By the time MT8183 shows up in more concrete devices, it will, certainly
>>> in kernel-space and likely in userspace as well. At present, the DDK can
>>> be modified to run on top of the in-tree Mali drivers, i.e. "Bifrost on
>>> mainline
On 08:37 Sat 21 Sep 2019, Greg KH wrote:
I'm announcing the release of the 5.3.1 kernel.
All users of the 5.3 kernel series must upgrade.
The updated 5.3.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-5.3.y
and can be browsed at
Hello,
syzbot found the following crash on:
HEAD commit:e0bd8d79 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=14d4b6a160
kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:e0bd8d79 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=1452c6a160
kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:e0bd8d79 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=13714ad960
kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:e0bd8d79 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=14aeeab160
kernel config:
Hello,
syzbot found the following crash on:
HEAD commit:e0bd8d79 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=114d95ad60
kernel config:
We never set this to false. This probably doesn't affect most people's
runtime because GCC will automatically initialize it to false at certain
common optimization levels. But that behavior is related to a bug in
GCC and obviously should not be relied on.
Fixes: 5d6742b37727 ("rcu/nocb: Use
On Mon, Sep 23, 2019 at 11:12:00AM +0200, Michael Kerrisk (man-pages) wrote:
> Hello Christian and all,
>
> Below, I have the rendered version of the current draft of
> the pidfd_send_signal(2) manual page that I have written.
> The page source can be found in a Git branch at:
>
On Mon, Sep 23, 2019 at 09:16:57AM -0500, Josh Poimboeuf wrote:
> On Mon, Sep 23, 2019 at 03:33:52PM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 23, 2019 at 07:49:01AM -0500, Josh Poimboeuf wrote:
> > > On Mon, Sep 23, 2019 at 11:20:24AM +0200, Peter Zijlstra wrote:
> > > > On Wed, Sep 18, 2019
Em Thu, Sep 19, 2019 at 05:23:35PM -0400, Steven Rostedt escreveu:
> Hi Arnaldo,
>
> This is a series of man page updates to the libtraceevent code, as
> well as a fix to one missing prototype and some movement of the location
> of the plugins (to have the plugins in their own directory).
On Mon, Sep 23, 2019 at 05:18:36PM +0300, Dan Carpenter wrote:
> "ret" should be a negative error code here, but it's either success or
> possibly uninitialized.
>
> Fixes: 32fd90c40768 ("nvme: change locking for the per-subsystem controller
> list")
> Signed-off-by: Dan Carpenter
Thanks,
Em Thu, Sep 19, 2019 at 04:51:19PM -0400, Steven Rostedt escreveu:
>
> From: "Steven Rostedt (VMware)"
>
>
> When testing the output of the old trace-cmd compared to the one that uses
> the updated tep_print_event() logic, it was different in that the time stamp
> precision in the old format
On Mon, Sep 23, 2019 at 01:26:34PM +0200, Florian Weimer wrote:
> * Michael Kerrisk:
>
> > SYNOPSIS
> >int pidfd_send_signal(int pidfd, int sig, siginfo_t info,
> > unsigned int flags);
>
> This probably should reference a header for siginfo_t.
Agreed.
>
>
"ret" should be a negative error code here, but it's either success or
possibly uninitialized.
Fixes: 32fd90c40768 ("nvme: change locking for the per-subsystem controller
list")
Signed-off-by: Dan Carpenter
---
drivers/nvme/host/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
The helper pinctrl_dt_has_hogs() was introduced in
99e4f67508e1 (pinctrl: core: Use delayed work for hogs), but the sole
use then got removed shortly after in 950b0d91dc10 (pinctrl: core: Fix
regression caused by delayed work for hogs).
Signed-off-by: Rasmus Villemoes
---
On 13/09/2019 19:19, Cristian Marussi wrote:
> There was a lot of code duplication across architectures regarding the
> SMP stop procedures' logic; moreover some of this duplicated code logic
> happened to be similarly faulty across a few architectures: while fixing
> such logic, move such generic
Jacek
Thanks for the review
On 9/21/19 5:55 AM, Jacek Anaszewski wrote:
Dan,
On 9/20/19 7:41 PM, Dan Murphy wrote:
Add a documentation of LED Multicolor LED class specific
sysfs attributes.
Signed-off-by: Dan Murphy
---
.../ABI/testing/sysfs-class-led-multicolor| 43
On Mon, 23 Sep 2019, Frederic Weisbecker wrote:
> On Thu, Sep 05, 2019 at 02:03:45PM +0200, Thomas Gleixner wrote:
> > If the PID encoded into the clock id is 0 then the target is either the
> > calling thread itself or the process to which it belongs.
> >
> > If the current thread encodes its
Em Mon, Sep 23, 2019 at 11:03:45AM -0300, Arnaldo Carvalho de Melo escreveu:
> Thanks, tested added Jiri's Acked-by, applied, added this note:
>
> Committer testing:
>
> After aplying the patch we get:
>
> [acme@quaco ~]$ perf record -b -e cycles date
> WARNING: Kernel address maps
On Mon, Sep 23, 2019 at 03:33:52PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 23, 2019 at 07:49:01AM -0500, Josh Poimboeuf wrote:
> > On Mon, Sep 23, 2019 at 11:20:24AM +0200, Peter Zijlstra wrote:
> > > On Wed, Sep 18, 2019 at 09:04:21PM -0700, Randy Dunlap wrote:
> > > > On 9/18/19 3:10 PM, Mark
The Ugoos AM6 is based on the Amlogic W400 (G12B) reference design using the
S922X chipset. Hardware specifications:
- 2GB LPDDR4 RAM
- 16GB eMMC storage
- 10/100/1000 Base-T Ethernet using External RGMII PHY
- 802.11 a/b/g/b/ac + BT 5.0 sdio wireless (Ampak 6398S)
- HDMI 2.0 (4k@60p) video
-
On 9/23/19 7:39 PM, Petr Mladek wrote:
> On Mon 2019-09-23 18:45:18, He Zhe wrote:
>>
>> On 9/23/19 6:05 PM, Sergey Senozhatsky wrote:
>>> On (09/18/19 21:31), zhe...@windriver.com wrote:
When users read the buffer from start, there is no need to return -EPIPE
since the possible
Ugoos Industrial Co., Ltd. are a manufacturer of ARM based TV Boxes/Dongles,
Digital Signage and Advertisement Solutions [0].
[0] (https://ugoos.com)
Acked-by: Rob Herring
Signed-off-by: Christian Hewitt
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2
The Ugoos AM6 is based on the Amlogic W400 (G12B) reference design using the
S922X chipset.
Acked-by: Rob Herring
Signed-off-by: Christian Hewitt
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
This patchset adds support for the Ugoos AM6, an Android STB based on
the Amlogic W400 reference design with the S922X chipset.
v2: correction of minor nits
v3: address regulator and GPIO corrections from Neil Armstrong (using
schematic excerpts from Ugoos) and related v2 comments from Martin
This patch adds the node for iMX8MQ Display Controller Subsystem.
Signed-off-by: Laurentiu Palcu
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
Some of its capabilities include:
* 4K@60fps;
* HDR10;
* one graphics and 2 video pipelines;
* on-the-fly decompression of compressed video and graphics;
The reference manual can be found here:
This clock is needed by DCSS when high resolutions are used.
Signed-off-by: Laurentiu Palcu
CC: Abel Vesa
---
drivers/clk/imx/clk-imx8mq.c | 4
include/dt-bindings/clock/imx8mq-clock.h | 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git
Hi,
On Fri 13 Sep 19, 15:36, Rob Herring wrote:
> On Tue, Sep 10, 2019 at 05:28:54PM +0200, Paul Kocialkowski wrote:
> > The Xylon LogiCVC display controller exports some GPIOs, which are
> > exposed as a dedicated driver.
> >
> > This introduces the associated device-tree bindings
401 - 500 of 783 matches
Mail list logo
