Re: [PATCH v2] irqchip/gicv3-its: fix some definitions of inner cacheability attributes
Hi Marc,
sorry for ping you...
What's your suggestion for this patch? I look forward to your reply.
Thanks,
Hongbo.
On 4/8/2019 10:01 PM, Hongbo Yao wrote:
> Some definitions of Inner Cacheability attibutes need to be corrected.
>
> Fixes: 8c828a535e29f ("irqchip/gicv3-its: Restore all cacheability
> attributes")
>
> Signed-off-by: Hongbo Yao
> ---
> include/linux/irqchip/arm-gic-v3.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/irqchip/arm-gic-v3.h
> b/include/linux/irqchip/arm-gic-v3.h
> index 95b69d3006ee..1f33daa5c674 100644
> --- a/include/linux/irqchip/arm-gic-v3.h
> +++ b/include/linux/irqchip/arm-gic-v3.h
> @@ -165,7 +165,7 @@
> #define GICR_PROPBASER_nCnB GIC_BASER_CACHEABILITY(GICR_PROPBASER, INNER,
> nCnB)
> #define GICR_PROPBASER_nCGIC_BASER_CACHEABILITY(GICR_PROPBASER, INNER,
> nC)
> #define GICR_PROPBASER_RaWt GIC_BASER_CACHEABILITY(GICR_PROPBASER, INNER,
> RaWt)
> -#define GICR_PROPBASER_RaWb GIC_BASER_CACHEABILITY(GICR_PROPBASER, INNER,
> RaWt)
> +#define GICR_PROPBASER_RaWb GIC_BASER_CACHEABILITY(GICR_PROPBASER, INNER,
> RaWb)
> #define GICR_PROPBASER_WaWt GIC_BASER_CACHEABILITY(GICR_PROPBASER, INNER,
> WaWt)
> #define GICR_PROPBASER_WaWb GIC_BASER_CACHEABILITY(GICR_PROPBASER, INNER,
> WaWb)
> #define GICR_PROPBASER_RaWaWtGIC_BASER_CACHEABILITY(GICR_PROPBASER,
> INNER, RaWaWt)
> @@ -192,7 +192,7 @@
> #define GICR_PENDBASER_nCnB GIC_BASER_CACHEABILITY(GICR_PENDBASER, INNER,
> nCnB)
> #define GICR_PENDBASER_nCGIC_BASER_CACHEABILITY(GICR_PENDBASER, INNER,
> nC)
> #define GICR_PENDBASER_RaWt GIC_BASER_CACHEABILITY(GICR_PENDBASER, INNER,
> RaWt)
> -#define GICR_PENDBASER_RaWb GIC_BASER_CACHEABILITY(GICR_PENDBASER, INNER,
> RaWt)
> +#define GICR_PENDBASER_RaWb GIC_BASER_CACHEABILITY(GICR_PENDBASER, INNER,
> RaWb)
> #define GICR_PENDBASER_WaWt GIC_BASER_CACHEABILITY(GICR_PENDBASER, INNER,
> WaWt)
> #define GICR_PENDBASER_WaWb GIC_BASER_CACHEABILITY(GICR_PENDBASER, INNER,
> WaWb)
> #define GICR_PENDBASER_RaWaWtGIC_BASER_CACHEABILITY(GICR_PENDBASER,
> INNER, RaWaWt)
> @@ -251,7 +251,7 @@
> #define GICR_VPROPBASER_nCnB GIC_BASER_CACHEABILITY(GICR_VPROPBASER, INNER,
> nCnB)
> #define GICR_VPROPBASER_nC GIC_BASER_CACHEABILITY(GICR_VPROPBASER, INNER,
> nC)
> #define GICR_VPROPBASER_RaWt GIC_BASER_CACHEABILITY(GICR_VPROPBASER, INNER,
> RaWt)
> -#define GICR_VPROPBASER_RaWb GIC_BASER_CACHEABILITY(GICR_VPROPBASER, INNER,
> RaWt)
> +#define GICR_VPROPBASER_RaWb GIC_BASER_CACHEABILITY(GICR_VPROPBASER, INNER,
> RaWb)
> #define GICR_VPROPBASER_WaWt GIC_BASER_CACHEABILITY(GICR_VPROPBASER, INNER,
> WaWt)
> #define GICR_VPROPBASER_WaWb GIC_BASER_CACHEABILITY(GICR_VPROPBASER, INNER,
> WaWb)
> #define GICR_VPROPBASER_RaWaWt GIC_BASER_CACHEABILITY(GICR_VPROPBASER,
> INNER, RaWaWt)
> @@ -277,7 +277,7 @@
> #define GICR_VPENDBASER_nCnB GIC_BASER_CACHEABILITY(GICR_VPENDBASER, INNER,
> nCnB)
> #define GICR_VPENDBASER_nC GIC_BASER_CACHEABILITY(GICR_VPENDBASER, INNER,
> nC)
> #define GICR_VPENDBASER_RaWt GIC_BASER_CACHEABILITY(GICR_VPENDBASER, INNER,
> RaWt)
> -#define GICR_VPENDBASER_RaWb GIC_BASER_CACHEABILITY(GICR_VPENDBASER, INNER,
> RaWt)
> +#define GICR_VPENDBASER_RaWb GIC_BASER_CACHEABILITY(GICR_VPENDBASER, INNER,
> RaWb)
> #define GICR_VPENDBASER_WaWt GIC_BASER_CACHEABILITY(GICR_VPENDBASER, INNER,
> WaWt)
> #define GICR_VPENDBASER_WaWb GIC_BASER_CACHEABILITY(GICR_VPENDBASER, INNER,
> WaWb)
> #define GICR_VPENDBASER_RaWaWt GIC_BASER_CACHEABILITY(GICR_VPENDBASER,
> INNER, RaWaWt)
> @@ -351,7 +351,7 @@
> #define GITS_CBASER_nCnB GIC_BASER_CACHEABILITY(GITS_CBASER, INNER, nCnB)
> #define GITS_CBASER_nC GIC_BASER_CACHEABILITY(GITS_CBASER,
> INNER, nC)
> #define GITS_CBASER_RaWt GIC_BASER_CACHEABILITY(GITS_CBASER, INNER, RaWt)
> -#define GITS_CBASER_RaWb GIC_BASER_CACHEABILITY(GITS_CBASER, INNER, RaWt)
> +#define GITS_CBASER_RaWb GIC_BASER_CACHEABILITY(GITS_CBASER, INNER, RaWb)
> #define GITS_CBASER_WaWt GIC_BASER_CACHEABILITY(GITS_CBASER, INNER, WaWt)
> #define GITS_CBASER_WaWb GIC_BASER_CACHEABILITY(GITS_CBASER, INNER, WaWb)
> #define GITS_CBASER_RaWaWt GIC_BASER_CACHEABILITY(GITS_CBASER, INNER,
> RaWaWt)
> @@ -375,7 +375,7 @@
> #define GITS_BASER_nCnB GIC_BASER_CACHEABILITY(GITS_BASER,
> INNER, nCnB)
> #define GITS_BASER_nCGIC_BASER_CACHEABILITY(GITS_BASER,
> INNER, nC)
> #define GITS_BASER_RaWt GIC_BASER_CACHEABILITY(GITS_BASER,
> INNER, RaWt)
> -#define GITS_BASER_RaWb GIC_BASER_CACHEABILITY(GITS_BASER,
> INNER, RaWt)
> +#define GITS_BASER_RaWb GIC_BASER_CACHEABILITY(GITS_BASER,
> INNER, RaWb)
> #define GITS_BASER_WaWt GIC_BASER_CACHEABILITY(GITS_BASER,
> INNER, WaWt)
> #define GITS_BASER_WaWb GIC_BASER_CACHEABILITY(GITS_BASER,
> INNER, WaWb)
> #define GITS_BASER_RaWaWt
Re: [PATCH] time64: Avoid undefined behaviour in timespec64_add()
On 2/25/2019 12:53 PM, Deepa Dinamani wrote:
> On Sun, Feb 24, 2019 at 7:13 PM Hongbo Yao wrote:
>>
>> I ran into this:
>>
>> =
>> UBSAN: Undefined behaviour in ./include/linux/time64.h:70:2
>> signed integer overflow:
>> 1551059291 + 9223372036854775807 cannot be represented in type 'long
>> long int'
>> CPU: 5 PID: 20064 Comm: syz-executor.2 Not tainted 4.19.24 #4
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> 1.10.2-1ubuntu1 04/01/2014
>> Call Trace:
>> __dump_stack lib/dump_stack.c:77 [inline]
>> dump_stack+0xca/0x13e lib/dump_stack.c:113
>> ubsan_epilogue+0xe/0x81 lib/ubsan.c:159
>> handle_overflow+0x193/0x1e2 lib/ubsan.c:190
>> timespec64_add include/linux/time64.h:70 [inline]
>> timekeeping_inject_offset+0x3ed/0x4e0 kernel/time/timekeeping.c:1301
>> do_adjtimex+0x1e5/0x6c0 kernel/time/timekeeping.c:2360
>> __do_sys_clock_adjtime+0x122/0x200 kernel/time/posix-timers.c:1086
>> do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x462eb9
>> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48
>> 89
>> f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
>> 01
>> f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
>> RSP: 002b:7f888aa2dc58 EFLAGS: 0246 ORIG_RAX:
>> 0131
>> RAX: ffda RBX: 0073bf00 RCX: 00462eb9
>> RDX: RSI: 23c0 RDI:
>> RBP: 0002 R08: R09:
>> R10: R11: 0246 R12: 7f888aa2e6bc
>> R13: 004bcae8 R14: 006f6868 R15:
>>
>> ==
>>
>> Since lhs.tv_sec and rhs.tv_sec are both time64_t, this is a signed
>> addition which will cause undefined behaviour on overflow.
>>
>> The easiest way to avoid the overflow is to cast one of the arguments to
>> unsigned (so the addition will be done using unsigned arithmetic).
>> This patch doesn't change generated code.
>>
>> Signed-off-by: Hongbo Yao
>> ---
>> include/linux/time64.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/time64.h b/include/linux/time64.h
>> index 05634afba0db..5926bdd4167f 100644
>> --- a/include/linux/time64.h
>> +++ b/include/linux/time64.h
>> @@ -67,7 +67,7 @@ static inline struct timespec64 timespec64_add(struct
>> timespec64 lhs,
>> struct timespec64 rhs)
>> {
>> struct timespec64 ts_delta;
>> - set_normalized_timespec64(_delta, lhs.tv_sec + rhs.tv_sec,
>> + set_normalized_timespec64(_delta, (timeu64_t)lhs.tv_sec +
>> rhs.tv_sec,
>> lhs.tv_nsec + rhs.tv_nsec);
>> return ts_delta;
>> }
>
> There is already a timespec64_add_safe() to account for such
> overflows. That assumes both the timespec64 values are positive.
> But, timekeeping_inject_offset() cannot use that as one of the values
> can be negative.
Thanks for your reply.
> Are you running some kind of a fuzzer that would cause a overflow?
Yes, I am running syzkaller testsuite.
> You seem to be adding INT64_MAX here. Maybe the right thing to do is
> to add a check at the syscall interface rather than here.
Thanks for this suggestion. Looks like that is a better way.
I will try it.
Thanks,
HongBo
> -Deepa
>
> .
>
Re: possible deadlock in console_unlock
On 2/19/2019 9:32 AM, Sergey Senozhatsky wrote: > On (02/18/19 22:07), Yao HongBo wrote: >>>> I have tried GFP_NOWARN, but the problem still exists. >>>> Only print_safe contexts for tty locks can solve the problem. >>>> My test scenario is falt-injection. >>> >>> Oh, I see. Yes, fault-injection is special. >>> >>> I suspect that this patch series can be helpful then >>> https://lore.kernel.org/lkml/20181016050428.17966-1-sergey.senozhat...@gmail.com/T/#u >> >> hi, sergey. > > Hello, > >> I merged this patch series on linux-4.19.18, but it didn't work for the >> fault-injection cases. > > Thanks! > >> The failure seems to be the same as before. > > OK... So tty_port lock must switch to printk_safe, after all... > I had it in one of the previous versions of the patchset which you > have tested, but people were strictly against new locking rules > in TTY, so I dropped that part. Need to think what we can do here. > > BTW, > we are now looking at a completely new printk implementation; which > would not use printk_safe at all: > https://lore.kernel.org/lkml/20190212143003.48446-1-john.ogn...@linutronix.de/T/#u Ok, i understand it. Anyway, thank you for your help. Best regards, Hongbo. > -ss > >
Re: possible deadlock in console_unlock
On 2/18/2019 1:46 PM, Sergey Senozhatsky wrote: > Hi, > > On (02/16/19 15:59), Yao HongBo wrote: >>> GFP_NOWARN is probably the best option for now. Yes, it, maybe, >>> will not work for fault-injection cases; but printk_safe approach >>> is harder to push for, especially given that printk_safe maybe will >>> not even exist in the future. >> >> I have tried GFP_NOWARN, but the problem still exists. >> Only print_safe contexts for tty locks can solve the problem. >> My test scenario is falt-injection. > > Oh, I see. Yes, fault-injection is special. > > I suspect that this patch series can be helpful then > https://lore.kernel.org/lkml/20181016050428.17966-1-sergey.senozhat...@gmail.com/T/#u hi, sergey. I merged this patch series on linux-4.19.18, but it didn't work for the fault-injection cases. The failure seems to be the same as before. deadlock log: --- [ 193.213385] FAULT_INJECTION: forcing a failure. [ 193.213385] name failslab, interval 1, probability 0, space 0, times 1 [ 193.216518] CPU: 1 PID: 6317 Comm: syz-executor0 Not tainted 4.19.18-514.55.6.9.x86_64+ #5 [ 193.217383] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 193.217383] Call Trace: [ 193.217383] dump_stack+0xca/0x13e [ 193.217383] should_fail+0x607/0x700 [ 193.217383] ? fault_create_debugfs_attr+0x1d0/0x1d0 [ 193.217383] ? __lock_is_held+0xbc/0x160 [ 193.225711] __should_failslab+0x110/0x180 [ 193.225711] should_failslab+0xa/0x20 [ 193.225711] __kmalloc+0x6e/0x350 [ 193.225711] ? tty_write+0x65e/0x8a0 [ 193.225711] tty_write+0x65e/0x8a0 [ 193.225711] ? process_echoes+0x140/0x140 [ 193.225711] ? rw_verify_area+0xe2/0x2b0 [ 193.225711] do_iter_write+0x3dc/0x580 [ 193.233550] vfs_writev+0x16c/0x300 [ 193.233550] ? vfs_iter_write+0xa0/0xa0 [ 193.233550] ? lock_downgrade+0x5e0/0x5e0 [ 193.233550] ? __lock_is_held+0xbc/0x160 [ 193.233550] ? __fget+0x336/0x540 [ 193.238589] ? do_dup2+0x3d0/0x3d0 [ 193.239291] ? __mutex_unlock_slowpath+0xe1/0x690 [ 193.239291] ? do_writev+0xd1/0x230 [ 193.239291] do_writev+0xd1/0x230 [ 193.239291] ? vfs_writev+0x300/0x300 [ 193.239291] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 193.239291] ? trace_hardirqs_off_caller+0x40/0x190 [ 193.239291] ? do_syscall_64+0x3b/0x580 [ 193.239291] do_syscall_64+0xc8/0x580 [ 193.239291] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 193.239291] RIP: 0033:0x462589 [ 193.239291] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 [ 193.239291] RSP: 002b:7f2a92dbcc58 EFLAGS: 0246 ORIG_RAX: 0014 [ 193.239291] RAX: ffda RBX: 0072bf00 RCX: 00462589 [ 193.239291] RDX: 0001 RSI: 2040 RDI: 0003 [ 193.239291] RBP: 7f2a92dbcc70 R08: R09: [ 193.239291] R10: R11: 0246 R12: 7f2a92dbd6bc [ 193.239291] R13: 004c222e R14: 00702110 R15: 0004 [ 193.266429] FAULT_INJECTION: forcing a failure. [ 193.266429] name failslab, interval 1, probability 0, space 0, times 0 [ 193.266767] CPU: 0 PID: 6340 Comm: syz-executor13 Not tainted 4.19.18-514.55.6.9.x86_64+ #5 [ 193.266767] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 193.266767] Call Trace: [ 193.266767] dump_stack+0xca/0x13e [ 193.266767] should_fail+0x607/0x700 [ 193.266767] ? n_tty_write+0x96a/0xd90 [ 193.266767] ? fault_create_debugfs_attr+0x1d0/0x1d0 [ 193.266767] ? mark_held_locks+0x120/0x120 [ 193.266767] __should_failslab+0x110/0x180 [ 193.266767] should_failslab+0xa/0x20 [ 193.266767] __kmalloc+0x6e/0x350 [ 193.266767] ? __tty_buffer_request_room+0x1cf/0x5e0 [ 193.266767] __tty_buffer_request_room+0x1cf/0x5e0 [ 193.266767] tty_insert_flip_string_fixed_flag+0x8f/0x220 [ 193.266767] pty_write+0x104/0x1d0 [ 193.266767] n_tty_write+0x9a3/0xd90 [ 193.266767] ? process_echoes+0x140/0x140 [ 193.266767] ? do_wait_intr_irq+0x2a0/0x2a0 [ 193.266767] ? __might_fault+0x17c/0x1c0 [ 193.266767] tty_write+0x451/0x8a0 [ 193.266767] ? process_echoes+0x140/0x140 [ 193.266767] do_iter_write+0x3dc/0x580 [ 193.266767] vfs_writev+0x16c/0x300 [ 193.266767] ? vfs_iter_write+0xa0/0xa0 [ 193.266767] ? lock_downgrade+0x5e0/0x5e0 [ 193.266767] ? __lock_is_held+0xbc/0x160 [ 193.266767] ? __fget+0x336/0x540 [ 193.266767] ? do_dup2+0x3d0/0x3d0 [ 193.266767] ? __mutex_unlock_slowpath+0xe1/0x690 [ 193.266767] ? do_writev+0xd1/0x230 [ 193.266767] do_writev+0xd1/0x230 [ 193.266767] ? vfs_writev+0x300/0x300 [ 193.266767] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 193.266767] ? trace_hardirqs_off_caller+0x40/0x190 [ 193.
Re: possible deadlock in console_unlock
On 2/18/2019 1:46 PM, Sergey Senozhatsky wrote: > Hi, > > On (02/16/19 15:59), Yao HongBo wrote: >>> GFP_NOWARN is probably the best option for now. Yes, it, maybe, >>> will not work for fault-injection cases; but printk_safe approach >>> is harder to push for, especially given that printk_safe maybe will >>> not even exist in the future. >> >> I have tried GFP_NOWARN, but the problem still exists. >> Only print_safe contexts for tty locks can solve the problem. >> My test scenario is falt-injection. > > Oh, I see. Yes, fault-injection is special. > > I suspect that this patch series can be helpful then > https://lore.kernel.org/lkml/20181016050428.17966-1-sergey.senozhat...@gmail.com/T/#u ok, i'll try it. Thanks. > but first we need to figure out if printk_safe will > stay in the kernel (this will take some time). > > -ss > >
Re: possible deadlock in console_unlock
On 2/16/2019 3:46 PM, Sergey Senozhatsky wrote:
> On (02/16/19 16:21), Sergey Senozhatsky wrote:
>> On (02/16/19 14:36), Yao HongBo wrote:
>>> hi, sergey:
>>>
>>> As shown in that link, https://lkml.org/lkml/2018/6/6/397
>>>
>>> On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in
>>> console_unlock'
>>> bug for several times in my environment.
>>>
>>> This solution fixes things for me. Do you have a plan to submit patches to
>>> solve this problem.
>>>
>>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>>> __printk_safe_enter();
>>> kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
>>> __printk_safe_exit();
>>
>> I would probably try the following:
>
> Yao HongBo, could you please post the lockdep splat?
>
> GFP_NOWARN is probably the best option for now. Yes, it, maybe,
> will not work for fault-injection cases; but printk_safe approach
> is harder to push for, especially given that printk_safe maybe will
> not even exist in the future.
I have tried GFP_NOWARN, but the problem still exists.
Only print_safe contexts for tty locks can solve the problem.
My test scenario is falt-injection.
deadlock report is shown as below:
RBP: 7f1cf76cbc70 R08: R09:
R10: R11: 0246 R12: 7f1cf76cc6bc
R13: 004c473d R14: 00701f18 R15: 0005
==
WARNING: possible circular locking dependency detected
4.19.18-514.55.6.9.x86_64+ #1 Not tainted
--
syz-executor0/23291 is trying to acquire lock:
d73d87c0 (console_owner){-.-.}, at: log_next kernel/printk/printk.c:495
[inline]
d73d87c0 (console_owner){-.-.}, at: console_unlock+0x36d/0xb30
kernel/printk/printk.c:2397
but task is already holding lock:
dfbab914 (&(>lock)->rlock){-.-.}, at: pty_write+0xd2/0x1d0
drivers/tty/pty.c:119
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&(>lock)->rlock){-.-.}:
tty_port_tty_get+0x20/0x80 drivers/tty/tty_port.c:288
tty_port_default_wakeup+0x16/0x40 drivers/tty/tty_port.c:47
serial8250_tx_chars+0x4dc/0xa80 drivers/tty/serial/8250/8250_port.c:1806
serial8250_handle_irq.part.12+0x198/0x220
drivers/tty/serial/8250/8250_port.c:1879
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1899 [inline]
serial8250_default_handle_irq+0xf8/0x120
drivers/tty/serial/8250/8250_port.c:1895
serial8250_interrupt+0xfe/0x250 drivers/tty/serial/8250/8250_core.c:125
__handle_irq_event_percpu+0xf5/0x730 kernel/irq/handle.c:149
handle_irq_event_percpu+0x7b/0x170 kernel/irq/handle.c:189
handle_irq_event+0xa6/0x140 kernel/irq/handle.c:206
handle_edge_irq+0x1eb/0xa90 kernel/irq/chip.c:791
generic_handle_irq_desc include/linux/irqdesc.h:154 [inline]
handle_irq+0x3e/0x50 arch/x86/kernel/irq_64.c:78
do_IRQ+0x92/0x200 arch/x86/kernel/irq.c:246
ret_from_intr+0x0/0x22
native_safe_halt+0x2/0x10 arch/x86/include/asm/irqflags.h:57
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0x24/0x2b0 arch/x86/kernel/process.c:561
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x2ca/0x420 kernel/sched/idle.c:262
cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:368
start_secondary+0x421/0x570 arch/x86/kernel/smpboot.c:271
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
-> #1 (_lock_key){-.-.}:
serial8250_console_write+0x68a/0x820
drivers/tty/serial/8250/8250_port.c:3247
call_console_drivers kernel/printk/printk.c:1729 [inline]
console_unlock+0x66a/0xb30 kernel/printk/printk.c:2410
vprintk_emit+0x181/0x570 kernel/printk/printk.c:1927
vprintk_default+0x68/0xe0 kernel/printk/printk.c:1968
vprintk_func+0x57/0xf0 kernel/printk/printk_safe.c:398
printk+0xb7/0xe2 kernel/printk/printk.c:2001
register_console+0x752/0xc60 kernel/printk/printk.c:2725
univ8250_console_init+0x31/0x3a drivers/tty/serial/8250/8250_core.c:685
console_init+0x3ad/0x567 kernel/printk/printk.c:2811
start_kernel+0x4c3/0x7e1 init/main.c:661
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
-> #0 (console_owner){-.-.}:
console_lock_spinning_enable kernel/printk/printk.c:1592 [inline]
console_unlock+0x3d9/0xb30 kernel/printk/printk.c:2407
vprintk_emit+0x181/0x570 kernel/printk/printk.c:1927
vprintk_default+0x68/0xe0 kernel/printk/printk.c:1968
vprintk_func+0x57/0xf0 kernel/printk/printk_safe.c:398
printk+0xb7/0xe2 kernel/print
possible deadlock in console_unlock
hi, sergey: As shown in that link, https://lkml.org/lkml/2018/6/6/397 On the linux kernel 5.0-rc6, Syzkaller also hit 'possible deadlock in console_unlock' bug for several times in my environment. This solution fixes things for me. Do you have a plan to submit patches to solve this problem. diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c __printk_safe_enter(); kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC); __printk_safe_exit(); Best regards, Hongbo
Re: [PATCH] nvme: fix out of bounds access in nvme_cqe_pending
On 1/10/2019 2:39 AM, Christoph Hellwig wrote:
> On Mon, Jan 07, 2019 at 10:22:07AM +0800, Hongbo Yao wrote:
>> There is an out of bounds array access in nvme_cqe_peding().
>>
>> When enable irq_thread for nvme interrupt, there is racing between the
>> nvmeq->cq_head updating and reading.
>
> Just curious: why did you enable this option? Do you have a workload
> where it matters?
Yes, there were a lot of hard interrupts reported when reading the nvme disk,
the OS can not schedule and result in the soft lockup.so i enabled the
irq_thread.
>> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
>> index d668682..68375d4 100644
>> --- a/drivers/nvme/host/pci.c
>> +++ b/drivers/nvme/host/pci.c
>> @@ -908,9 +908,11 @@ static void nvme_complete_cqes(struct nvme_queue
>> *nvmeq, u16 start, u16 end)
>>
>> static inline void nvme_update_cq_head(struct nvme_queue *nvmeq)
>> {
>> -if (++nvmeq->cq_head == nvmeq->q_depth) {
>> +if (nvmeq->cq_head == (nvmeq->q_depth - 1)) {
>> nvmeq->cq_head = 0;
>> nvmeq->cq_phase = !nvmeq->cq_phase;
>> +} else {
>> +++nvmeq->cq_head;
>
> No need for the braces above, but otherwise this looks fine. I'll apply
> it to nvme-4.21.
>
> .
>
Need i send a v2 version?
