On 09/06/2018 09:12 AM, Pasha Tatashin wrote:
>
> I do not want to make this feature less tested. Poisoning memory allowed
> us to catch corner case bugs like these:
>
> ab1e8d8960b68f54af42b6484b5950bd13a4054b
> mm: don't allow deferred pages with NEED_PER_CPU_KM
>
>
On 09/06/2018 09:12 AM, Pasha Tatashin wrote:
>
> I do not want to make this feature less tested. Poisoning memory allowed
> us to catch corner case bugs like these:
>
> ab1e8d8960b68f54af42b6484b5950bd13a4054b
> mm: don't allow deferred pages with NEED_PER_CPU_KM
>
>
On 09/05/2018 10:44 AM, Kyeongdon Kim wrote:
>
>
> On 2018-09-05 오전 1:24, Andrey Ryabinin wrote:
>>
>>
>> On 09/04/2018 01:10 PM, Andrey Ryabinin wrote:
>> >
>> >
>> > On 09/04/2018 09:59 AM, Kyeongdon Kim wrote:
>> >
>> +#undef strncmp
>> +int strncmp(const char *cs, const char *ct,
On 09/05/2018 10:44 AM, Kyeongdon Kim wrote:
>
>
> On 2018-09-05 오전 1:24, Andrey Ryabinin wrote:
>>
>>
>> On 09/04/2018 01:10 PM, Andrey Ryabinin wrote:
>> >
>> >
>> > On 09/04/2018 09:59 AM, Kyeongdon Kim wrote:
>> >
>> +#undef strncmp
>> +int strncmp(const char *cs, const char *ct,
On Thu, Sep 06, 2018 at 09:58:54AM -0700, Santosh Shilimkar wrote:
> Hi Arnd, Olof,
>
> On 9/6/2018 5:12 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Platform data pointer may be NULL. We check it everywhere but in one
> > place. Fix it.
> >
> > Fixes: 8af70cd2ca50
ARM64 has asm implementations of memchr(), memcmp(), str[r]chr(),
str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm
code, thus it can potentially miss many bugs.
Ifdef out __HAVE_ARCH_* defines of these functions when KASAN is
enabled, so the generic implementations from
Arch code may have asm implementation of string/memory API functions
instead of using generic one from lib/string.c. KASAN don't see
memory accesses in asm code, thus can miss many bugs.
E.g. on ARM64 KASAN don't see bugs in memchr(), memcmp(), str[r]chr(),
str[n]cmp(), str[n]len(). Add tests for
On Thu, Sep 06, 2018 at 09:58:54AM -0700, Santosh Shilimkar wrote:
> Hi Arnd, Olof,
>
> On 9/6/2018 5:12 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Platform data pointer may be NULL. We check it everywhere but in one
> > place. Fix it.
> >
> > Fixes: 8af70cd2ca50
ARM64 has asm implementations of memchr(), memcmp(), str[r]chr(),
str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm
code, thus it can potentially miss many bugs.
Ifdef out __HAVE_ARCH_* defines of these functions when KASAN is
enabled, so the generic implementations from
Arch code may have asm implementation of string/memory API functions
instead of using generic one from lib/string.c. KASAN don't see
memory accesses in asm code, thus can miss many bugs.
E.g. on ARM64 KASAN don't see bugs in memchr(), memcmp(), str[r]chr(),
str[n]cmp(), str[n]len(). Add tests for
Hi,
On Thu, Sep 06, 2018 at 04:10:39PM +0100, Sudeep Holla wrote:
> Firmware can provide zero as values for sustained performance level and
> corresponding sustained frequency in kHz in order to hide the actual
> frequencies and provide only abstract values. It may endup with divide
> by zero
Hi,
On Thu, Sep 06, 2018 at 04:10:39PM +0100, Sudeep Holla wrote:
> Firmware can provide zero as values for sustained performance level and
> corresponding sustained frequency in kHz in order to hide the actual
> frequencies and provide only abstract values. It may endup with divide
> by zero
On Thu 06-09-18 08:41:52, Alexander Duyck wrote:
> On Thu, Sep 6, 2018 at 8:13 AM Michal Hocko wrote:
> >
> > On Thu 06-09-18 07:59:03, Dave Hansen wrote:
> > > On 09/05/2018 10:47 PM, Michal Hocko wrote:
> > > > why do you have to keep DEBUG_VM enabled for workloads where the boot
> > > > time
On Thu 06-09-18 08:41:52, Alexander Duyck wrote:
> On Thu, Sep 6, 2018 at 8:13 AM Michal Hocko wrote:
> >
> > On Thu 06-09-18 07:59:03, Dave Hansen wrote:
> > > On 09/05/2018 10:47 PM, Michal Hocko wrote:
> > > > why do you have to keep DEBUG_VM enabled for workloads where the boot
> > > > time
at 3:16 AM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 10:13:00AM +0200, Peter Zijlstra wrote:
>> No, you got it the first time. There are in fact more fixmap abusers;
>> see drivers/acpi/apei/ghes.c. Also, as long as set_fixmap() allows
>> overwriting a _PAGE_PRESENT pte and has that
at 3:16 AM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 10:13:00AM +0200, Peter Zijlstra wrote:
>> No, you got it the first time. There are in fact more fixmap abusers;
>> see drivers/acpi/apei/ghes.c. Also, as long as set_fixmap() allows
>> overwriting a _PAGE_PRESENT pte and has that
Hi Arnd, Olof,
On 9/6/2018 5:12 AM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Platform data pointer may be NULL. We check it everywhere but in one
place. Fix it.
Fixes: 8af70cd2ca50 ("memory: aemif: add support for board files")
Reported-by: Dan Carpenter
Signed-off-by: Bartosz
Hi Arnd, Olof,
On 9/6/2018 5:12 AM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Platform data pointer may be NULL. We check it everywhere but in one
place. Fix it.
Fixes: 8af70cd2ca50 ("memory: aemif: add support for board files")
Reported-by: Dan Carpenter
Signed-off-by: Bartosz
Hello,
syzbot found the following crash on:
HEAD commit:f2b6e66e9885 Add linux-next specific files for 20180904
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=175217e140
kernel config: https://syzkaller.appspot.com/x/.config?x=15ad48400e39c1b3
Hello,
syzbot found the following crash on:
HEAD commit:f2b6e66e9885 Add linux-next specific files for 20180904
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=175217e140
kernel config: https://syzkaller.appspot.com/x/.config?x=15ad48400e39c1b3
On Thu, Sep 6, 2018 at 12:24 AM, Anson Huang wrote:
> This patch adds wakeup function support for egalax touch
> screen, if "wakeup-source" is added to device tree's egalax
> touch screen node, the wakeup function will be enabled, and
> egalax touch screen will be able to wakeup system from
On Thu, Sep 6, 2018 at 12:24 AM, Anson Huang wrote:
> This patch adds wakeup function support for egalax touch
> screen, if "wakeup-source" is added to device tree's egalax
> touch screen node, the wakeup function will be enabled, and
> egalax touch screen will be able to wakeup system from
On Thu, Sep 06, 2018 at 10:17:01AM -0400, Steven Rostedt wrote:
> I still think checking if IRQS are really disabled or not when lockdep
> thinks it is (or not) is valuable and doesn't cause any other problems.
Since check_flags() is a relatively cheap thing I would rather do
something like so..
On Thu, Sep 06, 2018 at 10:17:01AM -0400, Steven Rostedt wrote:
> I still think checking if IRQS are really disabled or not when lockdep
> thinks it is (or not) is valuable and doesn't cause any other problems.
Since check_flags() is a relatively cheap thing I would rather do
something like so..
Hi,
Looks like next-20180906 now has a regression where mounting
root won't work with commit fd0002870b45 ("vfs: Implement a
filesystem superblock creation/configuration context").
Here's what happens for me on MMC for example:
Waiting for root device /dev/mmcblk0p2...
mmc0:
On Thu, 6 Sep 2018 09:54:34 +0200
Sebastian Andrzej Siewior wrote:
> On 2018-09-05 08:27:54 [-0400], Steven Rostedt wrote:
> > Dear RT Folks,
> >
> > This is the RT stable review cycle of patch 4.14.63-rt41-rc1.
> >
> > Please scream at me if I messed something up. Please test the patches too.
On Thu, 6 Sep 2018 09:54:34 +0200
Sebastian Andrzej Siewior wrote:
> On 2018-09-05 08:27:54 [-0400], Steven Rostedt wrote:
> > Dear RT Folks,
> >
> > This is the RT stable review cycle of patch 4.14.63-rt41-rc1.
> >
> > Please scream at me if I messed something up. Please test the patches too.
Hi,
Looks like next-20180906 now has a regression where mounting
root won't work with commit fd0002870b45 ("vfs: Implement a
filesystem superblock creation/configuration context").
Here's what happens for me on MMC for example:
Waiting for root device /dev/mmcblk0p2...
mmc0:
On Thu, 6 Sep 2018 12:49:39 +0200
Peter Oberparleiter wrote:
> On 28.08.2018 02:43, Masami Hiramatsu wrote:
> > I recently added a gcov profiling for ftrace, following
> > Documentation/dev-tools/gcov.rst.
> > 6b7dca401cb1 ("tracing: Allow gcov profiling on only ftrace subsystem")
> >
> > and
On Thu, 6 Sep 2018 12:49:39 +0200
Peter Oberparleiter wrote:
> On 28.08.2018 02:43, Masami Hiramatsu wrote:
> > I recently added a gcov profiling for ftrace, following
> > Documentation/dev-tools/gcov.rst.
> > 6b7dca401cb1 ("tracing: Allow gcov profiling on only ftrace subsystem")
> >
> > and
Hello,
syzbot found the following crash on:
HEAD commit:b36fdc6853a3 Merge tag 'gpio-v4.19-2' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1716bc9e40
kernel config: https://syzkaller.appspot.com/x/.config?x=6c9564cd177daf0c
This patch adds port and endpoint of i2s and spdif nodes for rk3328.
Because to use modern sound card interface such as audio-graph-card.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 24
1 file changed, 24 insertions(+)
diff --git
Hello,
syzbot found the following crash on:
HEAD commit:b36fdc6853a3 Merge tag 'gpio-v4.19-2' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1716bc9e40
kernel config: https://syzkaller.appspot.com/x/.config?x=6c9564cd177daf0c
This patch adds port and endpoint of i2s and spdif nodes for rk3328.
Because to use modern sound card interface such as audio-graph-card.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 24
1 file changed, 24 insertions(+)
diff --git
On Tue, Sep 04 2018 at 16:00 -0600, Stephen Boyd wrote:
Quoting Lina Iyer (2018-09-04 14:09:34)
On Mon, Aug 27 2018 at 14:01 -0600, Stephen Boyd wrote:
>
>Can't we just configure a different chained IRQ handler with
>irq_set_chained_handler_and_data() for each of the GPIO IRQs that are
>handled
On Tue, Sep 04 2018 at 16:00 -0600, Stephen Boyd wrote:
Quoting Lina Iyer (2018-09-04 14:09:34)
On Mon, Aug 27 2018 at 14:01 -0600, Stephen Boyd wrote:
>
>Can't we just configure a different chained IRQ handler with
>irq_set_chained_handler_and_data() for each of the GPIO IRQs that are
>handled
Rick,
On Wed, 5 Sep 2018, Rick Ratzel wrote:
> We're looking for suggestions on how best to proceed with a new change
> that ideally both supports the use case described above, as well as
> addresses the symptoms brought up in the initial commit (negative boot
> time causes get_expiry() to
Rick,
On Wed, 5 Sep 2018, Rick Ratzel wrote:
> We're looking for suggestions on how best to proceed with a new change
> that ideally both supports the use case described above, as well as
> addresses the symptoms brought up in the initial commit (negative boot
> time causes get_expiry() to
The function clk_round_rate() is defined to return a "long", not an
"unsigned long". That's because it might return a negative error
code. Change the call in geni_se_clk_tbl_get() to check for errors.
While we're at it, get rid of a useless init of "freq".
NOTE: overall the idea that we should
Hi,
On Wed, Sep 5, 2018 at 4:37 PM, Matthias Kaehlcke wrote:
>> int geni_se_clk_tbl_get(struct geni_se *se, unsigned long **tbl)
>> {
>> - unsigned long freq = 0;
>> + long freq = 0;
>
> nit: Since you are already touching this you could also remove the
> pointless initialization,
The function clk_round_rate() is defined to return a "long", not an
"unsigned long". That's because it might return a negative error
code. Change the call in geni_se_clk_tbl_get() to check for errors.
While we're at it, get rid of a useless init of "freq".
NOTE: overall the idea that we should
Hi,
On Wed, Sep 5, 2018 at 4:37 PM, Matthias Kaehlcke wrote:
>> int geni_se_clk_tbl_get(struct geni_se *se, unsigned long **tbl)
>> {
>> - unsigned long freq = 0;
>> + long freq = 0;
>
> nit: Since you are already touching this you could also remove the
> pointless initialization,
The geni_se_clk_freq_match() has some strange semantics. Specifically
it is defined with two modes:
1. It can find a clock that's an exact multiple of the requested rate
2. It can find a non-exact match but it can't handle multiples then
...but callers should always be able to handle a clock
The geni_se_clk_freq_match() has some strange semantics. Specifically
it is defined with two modes:
1. It can find a clock that's an exact multiple of the requested rate
2. It can find a non-exact match but it can't handle multiples then
...but callers should always be able to handle a clock
Hi,
On Wed, Sep 5, 2018 at 5:20 PM, Matthias Kaehlcke wrote:
> On Thu, Aug 30, 2018 at 11:36:12AM -0700, Douglas Anderson wrote:
>> The geni_se_clk_freq_match() has some strange semantics. Specifically
>> it is defined with two modes:
>> 1. It can find a clock that's an exact multiple of the
Hi,
On Wed, Sep 5, 2018 at 5:20 PM, Matthias Kaehlcke wrote:
> On Thu, Aug 30, 2018 at 11:36:12AM -0700, Douglas Anderson wrote:
>> The geni_se_clk_freq_match() has some strange semantics. Specifically
>> it is defined with two modes:
>> 1. It can find a clock that's an exact multiple of the
This patch fixes pin assign of vcc_host1_5v. This regulator is
controlled by USB20_HOST_DRV signal.
ROCK64 schematic says that GPIO0_A2 pin is used as USB20_HOST_DRV.
GPIO0_D3 pin is for SPDIF_TX_M0.
ROCK64 schematic:
http://files.pine64.org/doc/rock64/ROCK64_Schematic_v2.0_20171019.pdf
This patch fixes pin assign of vcc_host1_5v. This regulator is
controlled by USB20_HOST_DRV signal.
ROCK64 schematic says that GPIO0_A2 pin is used as USB20_HOST_DRV.
GPIO0_D3 pin is for SPDIF_TX_M0.
ROCK64 schematic:
http://files.pine64.org/doc/rock64/ROCK64_Schematic_v2.0_20171019.pdf
On Thu, Sep 06, 2018 at 06:15:18PM +0200, Jann Horn wrote:
> On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> > The idea here is that the userspace handler should be able to pass an fd
> > back to the trapped task, for example so it can be returned from socket().
> [...]
> > diff --git
On Thu, Sep 06, 2018 at 06:15:18PM +0200, Jann Horn wrote:
> On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> > The idea here is that the userspace handler should be able to pass an fd
> > back to the trapped task, for example so it can be returned from socket().
> [...]
> > diff --git
Hi,
Please pull this fix for an issue syzbot discovered last week
thanks
- John
The following changes since commit 57361846b52bc686112da6ca5368d11210796804:
Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
are available in the Git repository at:
Hi,
Please pull this fix for an issue syzbot discovered last week
thanks
- John
The following changes since commit 57361846b52bc686112da6ca5368d11210796804:
Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
are available in the Git repository at:
Hi Boris,
Thanks for the review.
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Wednesday, September 5, 2018 3:50 PM
> To: Manish Narani
> Cc: robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> ; mche...@kernel.org; leoyang...@nxp.com;
>
Hi Boris,
Thanks for the review.
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Wednesday, September 5, 2018 3:50 PM
> To: Manish Narani
> Cc: robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> ; mche...@kernel.org; leoyang...@nxp.com;
>
On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> The idea here is that the userspace handler should be able to pass an fd
> back to the trapped task, for example so it can be returned from socket().
[...]
> diff --git a/Documentation/userspace-api/seccomp_filter.rst
>
On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> The idea here is that the userspace handler should be able to pass an fd
> back to the trapped task, for example so it can be returned from socket().
[...]
> diff --git a/Documentation/userspace-api/seccomp_filter.rst
>
On 9/6/18 11:41 AM, Alexander Duyck wrote:
> On Thu, Sep 6, 2018 at 8:13 AM Michal Hocko wrote:
>>
>> On Thu 06-09-18 07:59:03, Dave Hansen wrote:
>>> On 09/05/2018 10:47 PM, Michal Hocko wrote:
why do you have to keep DEBUG_VM enabled for workloads where the boot
time matters so much
On 9/6/18 11:41 AM, Alexander Duyck wrote:
> On Thu, Sep 6, 2018 at 8:13 AM Michal Hocko wrote:
>>
>> On Thu 06-09-18 07:59:03, Dave Hansen wrote:
>>> On 09/05/2018 10:47 PM, Michal Hocko wrote:
why do you have to keep DEBUG_VM enabled for workloads where the boot
time matters so much
On Thu 28-06-18 22:48:51, Anatoly Trosinenko wrote:
> Mounting broken UDF image causes KASAN warning on v4.18-rc2.
>
> How to reproduce:
> 1. Compile v4.18-rc2 kernel with the attached config
> 2. Unpack and mount the attached FS image as UDF
Thanks for the report and reproducer. I'll send fixes
On Thu 28-06-18 22:48:51, Anatoly Trosinenko wrote:
> Mounting broken UDF image causes KASAN warning on v4.18-rc2.
>
> How to reproduce:
> 1. Compile v4.18-rc2 kernel with the attached config
> 2. Unpack and mount the attached FS image as UDF
Thanks for the report and reproducer. I'll send fixes
On 09/06/2018 08:13 AM, Michal Hocko wrote:
>> CONFIG_DEBUG_VM_SLOW_AS_HECK
>>
>> under which we can put this an other really slow VM debugging. Or, we
>> need some kind of boot-time parameter to trigger the extra checking
>> instead of a new CONFIG option.
> I strongly suspect nobody will
On 09/06/2018 08:13 AM, Michal Hocko wrote:
>> CONFIG_DEBUG_VM_SLOW_AS_HECK
>>
>> under which we can put this an other really slow VM debugging. Or, we
>> need some kind of boot-time parameter to trigger the extra checking
>> instead of a new CONFIG option.
> I strongly suspect nobody will
On Thu, Sep 06, 2018 at 09:12:12AM -0400, Theodore Y. Ts'o wrote:
> So I don't see the point of changing return value block_page_mkwrite()
> (although to be honest I haven't see the value of the vm_fault_t
> change at all in the first place, at least not compared to the pain it
> has caused) but
On Thu, Sep 06, 2018 at 09:12:12AM -0400, Theodore Y. Ts'o wrote:
> So I don't see the point of changing return value block_page_mkwrite()
> (although to be honest I haven't see the value of the vm_fault_t
> change at all in the first place, at least not compared to the pain it
> has caused) but
"Gustavo A. R. Silva" wrote:
> The comparison of cid >= 0 is always true because cid is of type u8
> (8 bits, unsigned).
>
> Fix this by removing such comparison and updating the type of
> variable cid to u8 in the caller function.
>
> Addresses-Coverity-ID: 1473079 ("Unsigned compared against
Hi,
On Sat, Sep 1, 2018 at 3:23 PM, Bjorn Andersson
wrote:
> From: Sibi Sankar
>
> This patch adds the node to support AOSS reset driver on
> SDM845
>
> Signed-off-by: Sibi Sankar
> [bjorn: Updated addresses to match the binding that was merged]
> Signed-off-by: Bjorn Andersson
> ---
>
Hi,
On Sat, Sep 1, 2018 at 3:23 PM, Bjorn Andersson
wrote:
> From: Sibi Sankar
>
> This patch adds the node to support AOSS reset driver on
> SDM845
>
> Signed-off-by: Sibi Sankar
> [bjorn: Updated addresses to match the binding that was merged]
> Signed-off-by: Bjorn Andersson
> ---
>
"Gustavo A. R. Silva" wrote:
> The comparison of cid >= 0 is always true because cid is of type u8
> (8 bits, unsigned).
>
> Fix this by removing such comparison and updating the type of
> variable cid to u8 in the caller function.
>
> Addresses-Coverity-ID: 1473079 ("Unsigned compared against
On Thu, Sep 06, 2018 at 03:42:07PM +0800, kbuild test robot wrote:
> Hi Roman,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.19-rc2 next-20180905]
> [if your patch is applied to the wrong git tree, please
On Thu, Sep 06, 2018 at 03:42:07PM +0800, kbuild test robot wrote:
> Hi Roman,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.19-rc2 next-20180905]
> [if your patch is applied to the wrong git tree, please
Hi,
While fuzzing arm64 v4.19-rc2 with Syzkaller, I'm seeing a number of
splats (e.g. use-after-frees) in tty ioctl handling, e.g.
n_tty_set_termios. I've included one such splat at the end of this email.
It looks like syzbot has been hitting these (e.g. [1]) for a number of months,
so I guess
Hi,
While fuzzing arm64 v4.19-rc2 with Syzkaller, I'm seeing a number of
splats (e.g. use-after-frees) in tty ioctl handling, e.g.
n_tty_set_termios. I've included one such splat at the end of this email.
It looks like syzbot has been hitting these (e.g. [1]) for a number of months,
so I guess
Linus,
This fixes two bugs:
- The first one is a side effect caused by using SRCU for rcuidle
tracepoints. It seems that perf was depending on the rcuidle
tracepoints to make RCU watch when it wasn't. The real fix will
be to have perf use SRCU instead of depending on RCU watching,
On Thu, Sep 06, 2018 at 05:19:38PM +0200, Borislav Petkov wrote:
> On Thu, Sep 06, 2018 at 07:56:40AM -0700, Sean Christopherson wrote:
> > Wouldn't that result in @hv_clock_boot being incorrectly freed in the
> > !SEV case?
>
> Ok, maybe I'm missing something but why do we need 4K per CPU? Why
Linus,
This fixes two bugs:
- The first one is a side effect caused by using SRCU for rcuidle
tracepoints. It seems that perf was depending on the rcuidle
tracepoints to make RCU watch when it wasn't. The real fix will
be to have perf use SRCU instead of depending on RCU watching,
On Thu, Sep 06, 2018 at 05:19:38PM +0200, Borislav Petkov wrote:
> On Thu, Sep 06, 2018 at 07:56:40AM -0700, Sean Christopherson wrote:
> > Wouldn't that result in @hv_clock_boot being incorrectly freed in the
> > !SEV case?
>
> Ok, maybe I'm missing something but why do we need 4K per CPU? Why
From: "Steven Rostedt (VMware)"
Borislav reported the following splat:
=
WARNING: suspicious RCU usage
4.19.0-rc1+ #1 Not tainted
-
./include/linux/rcupdate.h:631 rcu_read_lock() used illegally while idle!
other info that might help
From: "Steven Rostedt (VMware)"
I hit the following splat in my tests:
[ cut here ]
IRQs not enabled as expected
WARNING: CPU: 3 PID: 0 at kernel/time/tick-sched.c:982
tick_nohz_idle_enter+0x44/0x8c
Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6table_filter
From: "Steven Rostedt (VMware)"
Borislav reported the following splat:
=
WARNING: suspicious RCU usage
4.19.0-rc1+ #1 Not tainted
-
./include/linux/rcupdate.h:631 rcu_read_lock() used illegally while idle!
other info that might help
From: "Steven Rostedt (VMware)"
I hit the following splat in my tests:
[ cut here ]
IRQs not enabled as expected
WARNING: CPU: 3 PID: 0 at kernel/time/tick-sched.c:982
tick_nohz_idle_enter+0x44/0x8c
Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6table_filter
Hi Boris,
Thanks a lot for the review. Please see my comments inline.
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Tuesday, September 4, 2018 10:28 PM
> To: Manish Narani
> Cc: robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> ; mche...@kernel.org;
Hi Boris,
Thanks a lot for the review. Please see my comments inline.
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Tuesday, September 4, 2018 10:28 PM
> To: Manish Narani
> Cc: robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> ; mche...@kernel.org;
On Wed 05 Sep 11:35 PDT 2018, Niklas Cassel wrote:
> DTS board files should always specify model and compatible.
>
> All DTS board files that includes msm8996.dtsi
> already specifies model and compatible, and will thus
> override the model and compatible in msm8996.dtsi.
>
> Drop model from
On Wed 05 Sep 11:35 PDT 2018, Niklas Cassel wrote:
> DTS board files should always specify model and compatible.
>
> All DTS board files that includes msm8996.dtsi
> already specifies model and compatible, and will thus
> override the model and compatible in msm8996.dtsi.
>
> Drop model from
On Wed 05 Sep 11:35 PDT 2018, Niklas Cassel wrote:
> DTS board files should always specify model and compatible.
>
> All DTS board files that includes msm8916.dtsi
> already specifies model and compatible, and will thus
> override the model and compatible in msm8916.dtsi.
>
> Drop model and
On Wed, 5 Sep 2018 20:07:50 +0100
Grant Likely wrote:
> The dtb= parameter is no longer the primary mechanism for providing a
> devicetree to the kernel. Now either firmware or the boot selector (ex.
> Grub) should provide the devicetree and dtb= should only be used for
> debug or when using
On Wed 05 Sep 11:35 PDT 2018, Niklas Cassel wrote:
> DTS board files should always specify model and compatible.
>
> All DTS board files that includes msm8916.dtsi
> already specifies model and compatible, and will thus
> override the model and compatible in msm8916.dtsi.
>
> Drop model and
On Wed, 5 Sep 2018 20:07:50 +0100
Grant Likely wrote:
> The dtb= parameter is no longer the primary mechanism for providing a
> devicetree to the kernel. Now either firmware or the boot selector (ex.
> Grub) should provide the devicetree and dtb= should only be used for
> debug or when using
On Thu, Sep 6, 2018 at 4:25 PM Arnd Bergmann wrote:
> On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote:
> > --- /dev/null
> > +++ b/arch/csky/abiv1/memset.c
> > @@ -0,0 +1,38 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +#include
>
On Thu, Sep 6, 2018 at 4:25 PM Arnd Bergmann wrote:
> On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote:
> > --- /dev/null
> > +++ b/arch/csky/abiv1/memset.c
> > @@ -0,0 +1,38 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +#include
>
On Thu, Sep 06, 2018 at 05:45:25PM +0200, Jann Horn wrote:
> On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> >
> > As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> > version which can acquire filters is useful. There are at least two reasons
> > this is
On Thu, Sep 06, 2018 at 05:45:25PM +0200, Jann Horn wrote:
> On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> >
> > As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> > version which can acquire filters is useful. There are at least two reasons
> > this is
On 2018/9/6 20:29, Borislav Petkov wrote:
Say what now?! What testing do you do if you boot a kernel which doesn't
even use the functionality you're testing?!
I'm sorry, this case is not good to demonstrate the useage. And I think
there are no other people will do the test without MCE in
On 2018/9/6 20:29, Borislav Petkov wrote:
Say what now?! What testing do you do if you boot a kernel which doesn't
even use the functionality you're testing?!
I'm sorry, this case is not good to demonstrate the useage. And I think
there are no other people will do the test without MCE in
On 09/05/2018 01:31 PM, Dave Jiang wrote:
> copy_to_iter_mcsafe() is passing in the is_source parameter as "false"
> to check_copy_size(). This is different than what copy_to_iter() does.
> Also, the addr parameter passed to check_copy_size() is the source so
> therefore we should be passing in
On 09/05/2018 01:31 PM, Dave Jiang wrote:
> copy_to_iter_mcsafe() is passing in the is_source parameter as "false"
> to check_copy_size(). This is different than what copy_to_iter() does.
> Also, the addr parameter passed to check_copy_size() is the source so
> therefore we should be passing in
On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
>
> As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> version which can acquire filters is useful. There are at least two reasons
> this is preferable, even though it uses ptrace:
>
> 1. You can control tasks that
On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
>
> As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> version which can acquire filters is useful. There are at least two reasons
> this is preferable, even though it uses ptrace:
>
> 1. You can control tasks that
On Thu, Sep 6, 2018 at 8:13 AM Michal Hocko wrote:
>
> On Thu 06-09-18 07:59:03, Dave Hansen wrote:
> > On 09/05/2018 10:47 PM, Michal Hocko wrote:
> > > why do you have to keep DEBUG_VM enabled for workloads where the boot
> > > time matters so much that few seconds matter?
> >
> > There are a
On Thu 06 Sep 06:53 PDT 2018, Amit Kucheria wrote:
> On Tue, Sep 4, 2018 at 10:31 AM, Bjorn Andersson
> > diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> > b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
[..]
> > + tsens0: thermal@10aa000 {
> > +
901 - 1000 of 1950 matches
Mail list logo
