All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sungho Bae <baver.bae@gmail.com>
To: Breno Leitao <leitao@debian.org>, Amit Shah <amit@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sungho Bae <baver.bae@lge.com>
Cc: virtualization@lists.linux.dev, linux-kernel@vger.kernel.org,
	kernel-team@meta.com
Subject: Re: [PATCH] virtio_console: allocate the port_buffer with the caller's gfp
Date: Wed, 19 Aug 2026 11:39:26 +0900	[thread overview]
Message-ID: <6B66D650-D65F-4176-ACBF-DC42488883AB@gmail.com> (raw)
In-Reply-To: <aoQggUaBZC9GeY1Y@gmail.com>

I am sorry for the late reply.
I fully agree with your patch.
It was my mistake. I should have to allocate the buffer with gfp flags.
Thank you for the corrections.


On 2026년 8월 18일 오후 6시 6분 37초 GMT+09:00, Breno Leitao <leitao@debian.org> 작성함:
>On Mon, Aug 10, 2026 at 09:40:00AM -0700, Breno Leitao wrote:
>> put_chars() runs from the hvc console write path with preemption
>> disabled, so it asks alloc_buf() for GFP_ATOMIC. Only the data buffer
>> gets it: the struct port_buffer itself keeps the GFP_KERNEL default, so
>> the allocation can enter direct reclaim and sleep. A write to /dev/kmsg
>> on a CONFIG_DEBUG_ATOMIC_SLEEP kernel splats:
>> 
>>   BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:320
>>   in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: virtme-ng-init
>>   preempt_count: 1, expected: 0
>>   Preemption disabled at:
>>   [<ffffffff813fd90d>] vprintk_emit+0x17d/0x510
>>   Call Trace:
>>    <TASK>
>>    dump_stack_lvl+0x69/0xa0
>>    __might_resched+0x37a/0x4d0
>>    __kmalloc_cache_noprof+0x94/0x5f0
>>    put_chars+0x209/0x3e0
>>    hvc_console_print+0x234/0x640
>>    console_flush_all+0x4fc/0x950
>>    console_unlock+0xbf/0x1b0
>>    vprintk_emit+0x312/0x510
>>    devkmsg_emit+0xba/0x110
>>    devkmsg_write+0x21b/0x2e0
>>    vfs_write+0x4dc/0x9d0
>>    ksys_write+0x108/0x1e0
>>    do_syscall_64+0xfa/0x460
>>    </TASK>
>> 
>> Pass gfp on to that allocation too.
>> 
>> Fixes: fc220d6be3c7 ("virtio_console: refactor __send_to_port() buffer ownership")
>> Signed-off-by: Breno Leitao <leitao@debian.org>
>
>Ping? 
>

  reply	other threads:[~2026-08-19  2:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-10 16:40 [PATCH] virtio_console: allocate the port_buffer with the caller's gfp Breno Leitao
2026-08-18  9:06 ` Breno Leitao
2026-08-19  2:39   ` Sungho Bae [this message]
2026-08-19  8:20     ` Breno Leitao
2026-08-19 11:36 ` Sungho Bae

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6B66D650-D65F-4176-ACBF-DC42488883AB@gmail.com \
    --to=baver.bae@gmail.com \
    --cc=amit@kernel.org \
    --cc=arnd@arndb.de \
    --cc=baver.bae@lge.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-team@meta.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=virtualization@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.