Linux virtualization list
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox