On Thu, Jul 19, 2018 at 04:50:05PM +0200, Christoph Hellwig wrote:
> The upper layer is only going to retry after tearing down the transport
> connection. And a tear down of the connection MUST clear all pending
> commands on the way. If it doesn't we are in deep, deep trouble.
>
> A NVMe abort
Commit-ID: 30587589251a00974115e0815ac316980f48dbb5
Gitweb: https://git.kernel.org/tip/30587589251a00974115e0815ac316980f48dbb5
Author: Yi Wang
AuthorDate: Mon, 16 Jul 2018 14:08:57 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 19 Jul 2018 16:52:40 +0200
timer: Fix coding style
On Mon, 16 Jul 2018, Daniel Kurtz wrote:
> The AMD pinctrl driver demultiplexes GPIO interrupts and fires off their
> individual handlers.
>
> If one of these GPIO irqs is configured as a level interrupt, and its
> downstream handler is a threaded ONESHOT interrupt, the GPIO interrupt
> source
On Mon, 16 Jul 2018, Daniel Kurtz wrote:
> The AMD pinctrl driver demultiplexes GPIO interrupts and fires off their
> individual handlers.
>
> If one of these GPIO irqs is configured as a level interrupt, and its
> downstream handler is a threaded ONESHOT interrupt, the GPIO interrupt
> source
Yixun Lan writes:
> On 07/19/2018 10:06 PM, Kevin Hilman wrote:
>> Yixun Lan writes:
>>
>> [...]
>>
As Jerome said, I think consistency is an important goal, so leaving off
the "meson-" for drivers/clk is fine with me.
>>> ok
>>>
Also for consistency, for the rest of
Yixun Lan writes:
> On 07/19/2018 10:06 PM, Kevin Hilman wrote:
>> Yixun Lan writes:
>>
>> [...]
>>
As Jerome said, I think consistency is an important goal, so leaving off
the "meson-" for drivers/clk is fine with me.
>>> ok
>>>
Also for consistency, for the rest of
Commit-ID: 8e974b3b8eddd42a8c43a18e8ea66a3e7b803a0d
Gitweb: https://git.kernel.org/tip/8e974b3b8eddd42a8c43a18e8ea66a3e7b803a0d
Author: Rasmus Villemoes
AuthorDate: Thu, 19 Jul 2018 23:07:58 +0900
Committer: Thomas Gleixner
CommitDate: Thu, 19 Jul 2018 16:46:23 +0200
x86: Avoid
Commit-ID: 8e974b3b8eddd42a8c43a18e8ea66a3e7b803a0d
Gitweb: https://git.kernel.org/tip/8e974b3b8eddd42a8c43a18e8ea66a3e7b803a0d
Author: Rasmus Villemoes
AuthorDate: Thu, 19 Jul 2018 23:07:58 +0900
Committer: Thomas Gleixner
CommitDate: Thu, 19 Jul 2018 16:46:23 +0200
x86: Avoid
Device tree compiler gives a warning if a device node has "@"
but no reg property.
Fix the example in iio: adc: sigma-delta-modulator.
Signed-off-by: Fabrice Gasnier
---
Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Device tree compiler gives a warning if a device node has "@"
but no reg property.
Fix the example in iio: adc: sigma-delta-modulator.
Signed-off-by: Fabrice Gasnier
---
Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Wed, Jul 18, 2018 at 4:52 PM, Geert Uytterhoeven
wrote:
> As PERL uses its own internal character encoding, always calling
> encode("utf8", ...) on the author name may cause corruption, leading to
> an author signoff mismatch.
>
> This happens in the following cases:
> - If a patch is in
On Wed, Jul 18, 2018 at 4:52 PM, Geert Uytterhoeven
wrote:
> As PERL uses its own internal character encoding, always calling
> encode("utf8", ...) on the author name may cause corruption, leading to
> an author signoff mismatch.
>
> This happens in the following cases:
> - If a patch is in
HI Alex,
On Thu, Jul 19, 2018 at 2:55 AM, Alex Williamson
wrote:
> On Thu, 19 Jul 2018 00:05:18 +0530
> Srinath Mannam wrote:
>
>> Hi Alex,
>>
>> On Tue, Jul 17, 2018 at 8:52 PM, Alex Williamson
>> wrote:
>> > On Fri, 13 Jul 2018 10:26:17 +0530
>> > Srinath Mannam wrote:
>> >
>> >> By default
HI Alex,
On Thu, Jul 19, 2018 at 2:55 AM, Alex Williamson
wrote:
> On Thu, 19 Jul 2018 00:05:18 +0530
> Srinath Mannam wrote:
>
>> Hi Alex,
>>
>> On Tue, Jul 17, 2018 at 8:52 PM, Alex Williamson
>> wrote:
>> > On Fri, 13 Jul 2018 10:26:17 +0530
>> > Srinath Mannam wrote:
>> >
>> >> By default
On Thu, Jul 19, 2018 at 04:35:34PM +0200, Johannes Thumshirn wrote:
> > No with the the code following what we have in PCIe that just means
> > we'll eventually controller reset after the I/O command times out
> > the second time as we still won't have seen a completion for it.
>
> Exactly that
On Thu, Jul 19, 2018 at 04:35:34PM +0200, Johannes Thumshirn wrote:
> > No with the the code following what we have in PCIe that just means
> > we'll eventually controller reset after the I/O command times out
> > the second time as we still won't have seen a completion for it.
>
> Exactly that
Hi guys,
On 19/07/18 15:01, Borislav Petkov wrote:
> On Mon, Jul 16, 2018 at 01:26:49PM -0400, Tyler Baicar wrote:
>> Enable per-layer error reporting for ARM systems so that the error
>> counters are incremented per-DIMM.
>>
>> On ARM systems that use firmware first error handling it is
Hi guys,
On 19/07/18 15:01, Borislav Petkov wrote:
> On Mon, Jul 16, 2018 at 01:26:49PM -0400, Tyler Baicar wrote:
>> Enable per-layer error reporting for ARM systems so that the error
>> counters are incremented per-DIMM.
>>
>> On ARM systems that use firmware first error handling it is
Hi Dmitry
On 17/07/18 17:10, Dmitry Osipenko wrote:
> Commit 36b312792b97 ("gpiolib: Respect error code of ->get_direction()")
> broke tegra_gpio_irq_set_type() because requesting of GPIO direction must
> be done after enabling GPIO function for a pin.
>
> This patch fixes drivers probe failure
On Thu, 19 Jul 2018 00:08:30 -0500
"Gustavo A. R. Silva" wrote:
> PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> arch/s390/hypfs/hypfs_diag.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Thu, 19 Jul 2018 00:08:30 -0500
"Gustavo A. R. Silva" wrote:
> PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> arch/s390/hypfs/hypfs_diag.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
Hi Dmitry
On 17/07/18 17:10, Dmitry Osipenko wrote:
> Commit 36b312792b97 ("gpiolib: Respect error code of ->get_direction()")
> broke tegra_gpio_irq_set_type() because requesting of GPIO direction must
> be done after enabling GPIO function for a pin.
>
> This patch fixes drivers probe failure
On Wed, 18 Jul 2018 23:46:53 -0500
"Gustavo A. R. Silva" wrote:
> PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/s390/char/tape_class.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 19.07.2018 06:42, Gustavo A. R. Silva wrote:
> PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/s390/crypto/ap_bus.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/s390/crypto/ap_bus.c
On Wed, 18 Jul 2018 23:46:53 -0500
"Gustavo A. R. Silva" wrote:
> PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/s390/char/tape_class.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 19.07.2018 06:42, Gustavo A. R. Silva wrote:
> PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/s390/crypto/ap_bus.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/s390/crypto/ap_bus.c
On Wed, 18 Jul 2018 23:50:50 -0500
"Gustavo A. R. Silva" wrote:
> PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/s390/block/dasd_eckd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Wed, 18 Jul 2018 23:50:50 -0500
"Gustavo A. R. Silva" wrote:
> PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/s390/block/dasd_eckd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Wed, 18 Jul 2018 23:42:05 -0500
"Gustavo A. R. Silva" wrote:
> PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/s390/crypto/ap_bus.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Wed, 18 Jul 2018 23:42:05 -0500
"Gustavo A. R. Silva" wrote:
> PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/s390/crypto/ap_bus.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Thu, Jul 19, 2018 at 09:22:53PM +0800, YueHaibing wrote:
> Replace IS_ERR/PTR_ERR
That says what you did, not why.
Please fix and resend.
thanks,
greg k-h
On Thu, Jul 19, 2018 at 09:22:53PM +0800, YueHaibing wrote:
> Replace IS_ERR/PTR_ERR
That says what you did, not why.
Please fix and resend.
thanks,
greg k-h
On Thu, Jul 19, 2018 at 04:23:55PM +0200, Christoph Hellwig wrote:
> On Thu, Jul 19, 2018 at 04:10:25PM +0200, Johannes Thumshirn wrote:
> > The problem I'm trying to solve here is really just single commands
> > timing out because of i.e. a bad switch in between which causes frame
> > loss
On Thu, Jul 19, 2018 at 04:23:55PM +0200, Christoph Hellwig wrote:
> On Thu, Jul 19, 2018 at 04:10:25PM +0200, Johannes Thumshirn wrote:
> > The problem I'm trying to solve here is really just single commands
> > timing out because of i.e. a bad switch in between which causes frame
> > loss
There's an issue with using threads::last_match in multithread
mode which is enabled during the perf top synthesize. It might
crash with following assertion:
perf: ...include/linux/refcount.h:109: refcount_inc:
Assertion `!(!refcount_inc_not_zero(r))' failed.
The gdb backtrace looks
There's an issue with using threads::last_match in multithread
mode which is enabled during the perf top synthesize. It might
crash with following assertion:
perf: ...include/linux/refcount.h:109: refcount_inc:
Assertion `!(!refcount_inc_not_zero(r))' failed.
The gdb backtrace looks
Hi Adam,
On Thu, Jul 19, 2018 at 4:29 PM Adam Borowski wrote:
> And vgacon has code that looks like it can do CGA and MDA (redundant with
> mdacon?), either of which I haven't used in... quite a while. Might be
> tricky getting access to such hardware to test...
Mdacon is meant to be used next
Hi Adam,
On Thu, Jul 19, 2018 at 4:29 PM Adam Borowski wrote:
> And vgacon has code that looks like it can do CGA and MDA (redundant with
> mdacon?), either of which I haven't used in... quite a while. Might be
> tricky getting access to such hardware to test...
Mdacon is meant to be used next
We occasionaly hit following assert failure in perf top,
when processing the /proc info in multiple threads.
perf: ...include/linux/refcount.h:109: refcount_inc:
Assertion `!(!refcount_inc_not_zero(r))' failed.
The gdb backtrace looks like this:
[Switching to Thread 0x711ba700
Separating threads::last_match cache read/check into
separate threads__get_last_match function. This will
be useful in following patch.
Link: http://lkml.kernel.org/n/tip-z4zzlpp3vusjued0gzp5u...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/machine.c | 39
hi,
perf top is occasionaly crashes on hitting assert, because of
the synthesize function that runs on multiple threads now.
I found some issues with list/tree accessing and this patchset
is trying to fix them.
I was runing 'perf top' in a loop with attached change below
and haven't hit any
hi,
perf top is occasionaly crashes on hitting assert, because of
the synthesize function that runs on multiple threads now.
I found some issues with list/tree accessing and this patchset
is trying to fix them.
I was runing 'perf top' in a loop with attached change below
and haven't hit any
We occasionaly hit following assert failure in perf top,
when processing the /proc info in multiple threads.
perf: ...include/linux/refcount.h:109: refcount_inc:
Assertion `!(!refcount_inc_not_zero(r))' failed.
The gdb backtrace looks like this:
[Switching to Thread 0x711ba700
Separating threads::last_match cache read/check into
separate threads__get_last_match function. This will
be useful in following patch.
Link: http://lkml.kernel.org/n/tip-z4zzlpp3vusjued0gzp5u...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/machine.c | 39
Separating threads::last_match cache set into
separate threads__set_last_match function.
This will be useful in following patch.
Link: http://lkml.kernel.org/n/tip-r2phhluimtb4747rug66m...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/machine.c | 12 +---
1 file changed, 9
Separating threads::last_match cache set into
separate threads__set_last_match function.
This will be useful in following patch.
Link: http://lkml.kernel.org/n/tip-r2phhluimtb4747rug66m...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/machine.c | 12 +---
1 file changed, 9
On Thu, Jul 19, 2018 at 11:47:49AM +0100, Alan Cox wrote:
> On Wed, 18 Jul 2018 05:01:52 +0200
> Adam Borowski wrote:
>
> > Hi!
> > Here's a patchset with two entangled improvements:
> >
> > * it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
> > allows disabling it,
On Thu, Jul 19, 2018 at 11:47:49AM +0100, Alan Cox wrote:
> On Wed, 18 Jul 2018 05:01:52 +0200
> Adam Borowski wrote:
>
> > Hi!
> > Here's a patchset with two entangled improvements:
> >
> > * it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
> > allows disabling it,
Em Thu, Jul 12, 2018 at 11:18:05PM -0700, Stephane Eranian escreveu:
> Hi Jiri,
> On Thu, Jul 12, 2018 at 9:49 AM Jiri Olsa wrote:
> >
> > On Thu, Jul 12, 2018 at 09:34:45AM -0700, Stephane Eranian wrote:
> > > Hi Jiri,
> > > On Thu, Jul 12, 2018 at 6:52 AM Jiri Olsa wrote:
> > > >
> > > >
Em Thu, Jul 12, 2018 at 11:18:05PM -0700, Stephane Eranian escreveu:
> Hi Jiri,
> On Thu, Jul 12, 2018 at 9:49 AM Jiri Olsa wrote:
> >
> > On Thu, Jul 12, 2018 at 09:34:45AM -0700, Stephane Eranian wrote:
> > > Hi Jiri,
> > > On Thu, Jul 12, 2018 at 6:52 AM Jiri Olsa wrote:
> > > >
> > > >
On Thu, Jul 19, 2018 at 10:03 AM Michal Hocko wrote:
>
> On Thu 19-07-18 15:58:59, Oscar Salvador wrote:
> > On Thu, Jul 19, 2018 at 03:46:22PM +0200, Michal Hocko wrote:
> > > On Thu 19-07-18 15:27:40, osalva...@techadventures.net wrote:
> > > > From: Oscar Salvador
> > > >
> > > > We should
On Thu, Jul 19, 2018 at 10:03 AM Michal Hocko wrote:
>
> On Thu 19-07-18 15:58:59, Oscar Salvador wrote:
> > On Thu, Jul 19, 2018 at 03:46:22PM +0200, Michal Hocko wrote:
> > > On Thu 19-07-18 15:27:40, osalva...@techadventures.net wrote:
> > > > From: Oscar Salvador
> > > >
> > > > We should
On 07/19/2018 10:06 PM, Kevin Hilman wrote:
> Yixun Lan writes:
>
> [...]
>
>>>
>>> As Jerome said, I think consistency is an important goal, so leaving off
>>> the "meson-" for drivers/clk is fine with me.
>>>
>> ok
>>
>>> Also for consistency, for the rest of the drivers, keeping "meson-" is
On 07/19/2018 10:06 PM, Kevin Hilman wrote:
> Yixun Lan writes:
>
> [...]
>
>>>
>>> As Jerome said, I think consistency is an important goal, so leaving off
>>> the "meson-" for drivers/clk is fine with me.
>>>
>> ok
>>
>>> Also for consistency, for the rest of the drivers, keeping "meson-" is
On Thu, Jul 19, 2018 at 6:49 AM Peter Zijlstra wrote:
>
> On Tue, Jul 17, 2018 at 10:22:11PM -0400, Pavel Tatashin wrote:
> > sched_clock_running may be read every time sched_clock_cpu() is called.
> > Yet, this variable is updated only twice during boot, and never changes
> > again, therefore it
On Thu, Jul 19, 2018 at 6:49 AM Peter Zijlstra wrote:
>
> On Tue, Jul 17, 2018 at 10:22:11PM -0400, Pavel Tatashin wrote:
> > sched_clock_running may be read every time sched_clock_cpu() is called.
> > Yet, this variable is updated only twice during boot, and never changes
> > again, therefore it
David,
Now that your patches are about to be dropped from linux-next.git , please try
OOM lockup
(CVE-2016-10723) mitigation patch (
https://marc.info/?l=linux-mm=153112243424285=4 )
and my cleanup patch ( [PATCH 1/2] at
https://marc.info/?l=linux-mm=153119509215026=4 )
on top of linux.git .
David,
Now that your patches are about to be dropped from linux-next.git , please try
OOM lockup
(CVE-2016-10723) mitigation patch (
https://marc.info/?l=linux-mm=153112243424285=4 )
and my cleanup patch ( [PATCH 1/2] at
https://marc.info/?l=linux-mm=153119509215026=4 )
on top of linux.git .
On 07/19/2018 03:21 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 04:19:10PM -0700, Dave Hansen wrote:
>> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
>>> mktme_nr_keyids holds number of KeyIDs available for MKTME, excluding
>>> KeyID zero which used by TME. MKTME KeyIDs start from
On 07/19/2018 03:21 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 04:19:10PM -0700, Dave Hansen wrote:
>> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
>>> mktme_nr_keyids holds number of KeyIDs available for MKTME, excluding
>>> KeyID zero which used by TME. MKTME KeyIDs start from
On Thu, Jul 19, 2018 at 04:10:25PM +0200, Johannes Thumshirn wrote:
> The problem I'm trying to solve here is really just single commands
> timing out because of i.e. a bad switch in between which causes frame
> loss somewhere.
And that is exactly the case where NVMe abort does not actually work
On Thu, Jul 19, 2018 at 04:10:25PM +0200, Johannes Thumshirn wrote:
> The problem I'm trying to solve here is really just single commands
> timing out because of i.e. a bad switch in between which causes frame
> loss somewhere.
And that is exactly the case where NVMe abort does not actually work
On 07/19/2018 02:54 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 04:13:20PM -0700, Dave Hansen wrote:
>> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
>>> + } else {
>>> + /*
>>> +* Reset __PHYSICAL_MASK.
>>> +* Maybe needed if there's
On 07/19/2018 02:54 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 04:13:20PM -0700, Dave Hansen wrote:
>> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
>>> + } else {
>>> + /*
>>> +* Reset __PHYSICAL_MASK.
>>> +* Maybe needed if there's
On Thu, Jul 19, 2018 at 6:40 AM Peter Zijlstra wrote:
>
> On Tue, Jul 17, 2018 at 10:22:10PM -0400, Pavel Tatashin wrote:
>
> > diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
> > index 0e9dbb2d9aea..7a8a63b940ee 100644
> > --- a/kernel/sched/clock.c
> > +++ b/kernel/sched/clock.c
> > @@
On Thu, Jul 19, 2018 at 6:40 AM Peter Zijlstra wrote:
>
> On Tue, Jul 17, 2018 at 10:22:10PM -0400, Pavel Tatashin wrote:
>
> > diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
> > index 0e9dbb2d9aea..7a8a63b940ee 100644
> > --- a/kernel/sched/clock.c
> > +++ b/kernel/sched/clock.c
> > @@
On 07/19/2018 01:59 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 04:11:57PM -0700, Dave Hansen wrote:
>> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
>>> khugepaged allocates page in advance, before we found a VMA for
>>> collapse. We don't yet know which KeyID to use for the
On 07/19/2018 01:59 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 04:11:57PM -0700, Dave Hansen wrote:
>> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
>>> khugepaged allocates page in advance, before we found a VMA for
>>> collapse. We don't yet know which KeyID to use for the
On Thu, Jul 19, 2018 at 11:07:58PM +0900, Tetsuo Handa wrote:
> From: Rasmus Villemoes
>
> Since syzbot is confused by concurrent printk() messages [1],
> this patch changes show_opcodes() to use %ph format string.
>
> When we start adding prefix to each line of printk() output,
> we will be
On Thu, Jul 19, 2018 at 11:07:58PM +0900, Tetsuo Handa wrote:
> From: Rasmus Villemoes
>
> Since syzbot is confused by concurrent printk() messages [1],
> this patch changes show_opcodes() to use %ph format string.
>
> When we start adding prefix to each line of printk() output,
> we will be
On Thu, Jul 19, 2018 at 03:42:03PM +0200, Christoph Hellwig wrote:
> Without even looking at the code yet: why? The nvme abort isn't
> very useful, and due to the lack of ordering between different
> queues almost harmful on fabrics. What problem do you try to
> solve?
The problem I'm trying
On Thu, Jul 19, 2018 at 03:42:03PM +0200, Christoph Hellwig wrote:
> Without even looking at the code yet: why? The nvme abort isn't
> very useful, and due to the lack of ordering between different
> queues almost harmful on fabrics. What problem do you try to
> solve?
The problem I'm trying
From: Masayoshi Mizuma
KASAN reported the following slab-out-of-bounds when sb_edac
module was loaded on Broadwell machine which has two PCI segments.
==
BUG: KASAN: slab-out-of-bounds in
From: Masayoshi Mizuma
KASAN reported the following slab-out-of-bounds when sb_edac
module was loaded on Broadwell machine which has two PCI segments.
==
BUG: KASAN: slab-out-of-bounds in
From: Rasmus Villemoes
Since syzbot is confused by concurrent printk() messages [1],
this patch changes show_opcodes() to use %ph format string.
When we start adding prefix to each line of printk() output,
we will be able to handle concurrent printk() messages.
[1]
From: Rasmus Villemoes
Since syzbot is confused by concurrent printk() messages [1],
this patch changes show_opcodes() to use %ph format string.
When we start adding prefix to each line of printk() output,
we will be able to handle concurrent printk() messages.
[1]
Linus,
please pull sound fixes for v4.18-rc6 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-4.18-rc6
The topmost commit is f3d737b6340b0c7bacd8bc751605f0ed6203f146
sound fixes for 4.18-rc6
A
Linus,
please pull sound fixes for v4.18-rc6 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-4.18-rc6
The topmost commit is f3d737b6340b0c7bacd8bc751605f0ed6203f146
sound fixes for 4.18-rc6
A
Yixun Lan writes:
[...]
>>
>> As Jerome said, I think consistency is an important goal, so leaving off
>> the "meson-" for drivers/clk is fine with me.
>>
> ok
>
>> Also for consistency, for the rest of the drivers, keeping "meson-" is
>> probably the right thing to do.
>>
> ok, for the
Yixun Lan writes:
[...]
>>
>> As Jerome said, I think consistency is an important goal, so leaving off
>> the "meson-" for drivers/clk is fine with me.
>>
> ok
>
>> Also for consistency, for the rest of the drivers, keeping "meson-" is
>> probably the right thing to do.
>>
> ok, for the
On 07/19/2018 01:27 AM, Kirill A. Shutemov wrote:
>> What other code might need prep_encrypted_page()?
>
> Custom pages allocators if these pages can end up in encrypted VMAs.
>
> It this case compaction creates own pool of pages to be used for
> allocation during page migration.
OK, that makes
On 07/19/2018 01:27 AM, Kirill A. Shutemov wrote:
>> What other code might need prep_encrypted_page()?
>
> Custom pages allocators if these pages can end up in encrypted VMAs.
>
> It this case compaction creates own pool of pages to be used for
> allocation during page migration.
OK, that makes
On Thu, Jul 19, 2018 at 03:44:17PM +0200, Michal Hocko wrote:
> On Thu 19-07-18 15:27:38, osalva...@techadventures.net wrote:
> > From: Oscar Salvador
> >
> > In free_area_init_core we calculate the amount of managed pages
> > we are left with, by substracting the memmap pages and the pages
> >
On Thu, Jul 19, 2018 at 03:44:17PM +0200, Michal Hocko wrote:
> On Thu 19-07-18 15:27:38, osalva...@techadventures.net wrote:
> > From: Oscar Salvador
> >
> > In free_area_init_core we calculate the amount of managed pages
> > we are left with, by substracting the memmap pages and the pages
> >
On Thu 19-07-18 15:58:59, Oscar Salvador wrote:
> On Thu, Jul 19, 2018 at 03:46:22PM +0200, Michal Hocko wrote:
> > On Thu 19-07-18 15:27:40, osalva...@techadventures.net wrote:
> > > From: Oscar Salvador
> > >
> > > We should only care about deferred initialization when booting.
> >
> > Again
On Thu 19-07-18 15:58:59, Oscar Salvador wrote:
> On Thu, Jul 19, 2018 at 03:46:22PM +0200, Michal Hocko wrote:
> > On Thu 19-07-18 15:27:40, osalva...@techadventures.net wrote:
> > > From: Oscar Salvador
> > >
> > > We should only care about deferred initialization when booting.
> >
> > Again
On 07/19/2018 12:32 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 10:38:27AM -0700, Dave Hansen wrote:
>> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
>>> Pages encrypted with different encryption keys are not allowed to be
>>> merged by KSM. Otherwise it would cross security
On 07/19/2018 12:32 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 10:38:27AM -0700, Dave Hansen wrote:
>> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
>>> Pages encrypted with different encryption keys are not allowed to be
>>> merged by KSM. Otherwise it would cross security
On Mon, Jul 16, 2018 at 01:26:49PM -0400, Tyler Baicar wrote:
> Enable per-layer error reporting for ARM systems so that the error
> counters are incremented per-DIMM.
>
> On ARM systems that use firmware first error handling it is understood
> that card=channel and module=DIMM on that channel.
On Mon, Jul 16, 2018 at 01:26:49PM -0400, Tyler Baicar wrote:
> Enable per-layer error reporting for ARM systems so that the error
> counters are incremented per-DIMM.
>
> On ARM systems that use firmware first error handling it is understood
> that card=channel and module=DIMM on that channel.
On Wed, Jul 18, 2018 at 06:36:44PM -0400, Johannes Weiner wrote:
> On Wed, Jul 18, 2018 at 02:03:18PM +0200, Peter Zijlstra wrote:
> > On Thu, Jul 12, 2018 at 01:29:40PM -0400, Johannes Weiner wrote:
> > > + /* Time in which tasks wait for the CPU */
> > > + state = PSI_NONE;
> > > + if
On Wed, Jul 18, 2018 at 06:36:44PM -0400, Johannes Weiner wrote:
> On Wed, Jul 18, 2018 at 02:03:18PM +0200, Peter Zijlstra wrote:
> > On Thu, Jul 12, 2018 at 01:29:40PM -0400, Johannes Weiner wrote:
> > > + /* Time in which tasks wait for the CPU */
> > > + state = PSI_NONE;
> > > + if
On Thu, Jul 19, 2018 at 03:46:22PM +0200, Michal Hocko wrote:
> On Thu 19-07-18 15:27:40, osalva...@techadventures.net wrote:
> > From: Oscar Salvador
> >
> > We should only care about deferred initialization when booting.
>
> Again why is this worth doing?
Well, it is not a big win if that is
On Thu, Jul 19, 2018 at 03:46:22PM +0200, Michal Hocko wrote:
> On Thu 19-07-18 15:27:40, osalva...@techadventures.net wrote:
> > From: Oscar Salvador
> >
> > We should only care about deferred initialization when booting.
>
> Again why is this worth doing?
Well, it is not a big win if that is
On 07/19/2018 12:16 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 10:36:24AM -0700, Dave Hansen wrote:
>> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
>>> Zero page is not encrypted and putting it into encrypted VMA produces
>>> garbage.
>>>
>>> We can map zero page with KeyID-0
On 07/19/2018 12:16 AM, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 10:36:24AM -0700, Dave Hansen wrote:
>> On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
>>> Zero page is not encrypted and putting it into encrypted VMA produces
>>> garbage.
>>>
>>> We can map zero page with KeyID-0
Hyper-V supports a pv hypercall HvFlushGuestPhysicalAddressSpace to
flush nested VM address space mapping in l1 hypervisor and it's to
reduce overhead of flushing ept tlb among vcpus. This patch is to
implement it.
Signed-off-by: Lan Tianyu
---
Change since v3
Remove GPL boilerplate.
Hyper-V supports a pv hypercall HvFlushGuestPhysicalAddressSpace to
flush nested VM address space mapping in l1 hypervisor and it's to
reduce overhead of flushing ept tlb among vcpus. This patch is to
implement it.
Signed-off-by: Lan Tianyu
---
Change since v3
Remove GPL boilerplate.
On Thu, Jul 19, 2018 at 10:53:03PM +0900, Tetsuo Handa wrote:
> + if (probe_kernel_read(opcodes, rip - PROLOGUE_SIZE, OPCODE_BUFSIZE))
> + printk("%sCode: Bad RIP value.\n", loglvl);
> + else
> + printk("%sCode: %" __stringify(PROLOGUE_SIZE) "ph <%02x> %"
> +
On 07/19/2018 09:54 AM, Peter Zijlstra wrote:
> On Sun, Jun 24, 2018 at 03:30:40PM +0800, Waiman Long wrote:
>> This patch enables us to report sched domain generation information.
>>
>> If DYNAMIC_DEBUG is enabled, issuing the following command
>>
>> echo "file cpuset.c +p" >
801 - 900 of 1560 matches
Mail list logo
