Linux USB
 help / color / mirror / Atom feed
From: Zi Yan <ziy@nvidia.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	syzbot <syzbot+805630f1453e490427fa@syzkaller.appspotmail.com>,
	apopple@nvidia.com, byungchul@sk.com, david@kernel.org,
	gourry@gourry.net, joshua.hahnjy@gmail.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	matthew.brost@intel.com, rakie.kim@sk.com,
	syzkaller-bugs@googlegroups.com, ying.huang@linux.alibaba.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, Vlastimil Babka <vbabka@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	Brendan Jackman <brendan.jackman@linux.dev>,
	Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [syzbot] [mm?] WARNING in ep_write_iter
Date: Mon, 17 Aug 2026 14:45:19 -0400	[thread overview]
Message-ID: <6FC11E12-9428-4975-B135-E24805C2D9BF@nvidia.com> (raw)
In-Reply-To: <2bf01548-723c-465d-8368-247a814f61eb@rowland.harvard.edu>

On 17 Aug 2026, at 11:37, Alan Stern wrote:

> On Mon, Aug 17, 2026 at 11:22:47AM -0400, Zi Yan wrote:
>>> Again, I disagree with some of the details of this argument in this
>>> context.  For instance, if all kernel developers are supposed to know
>>> that they shouldn't ask kmalloc() for more than MAX_PAGE_ORDER at the
>>> risk of provoking a WARN, if this is such an important restriction, then
>>> shouldn't this requirement be mentioned in the kerneldoc for kmalloc()?
>>
>>
>> kmalloc is the normal method of allocating memory
>> for objects smaller than page size in the kernel.
>
> This means when you are allocating small objects, kmalloc is the normal
> way to do it.  It says nothing about what you should do when allocating
> large objects.

alloc_pages() or vmalloc or kvmalloc(). kmalloc() is used if you really
want physically contiguous memory.

>
> In particular, it doesn't say that if you ask kmalloc for more than 4 MB
> of memory, your system is likely to crash.

Crash because panic_on_warn is set. You just conflate a sysctl config with
a WARN. I understand panic_on_warn is set by many systems, but that does not
mean every system crashes.

Plus, if you use kvmalloc with a really large size, you also can get
a WARN[1][2].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/slub.c?h=v7.2#n6912
[2] https://lore.kernel.org/all/CAHk-=wiRq+_jd_O1gz3J6-ANtXMY7iLpi8XFUcmtB3rBixvUXQ@mail.gmail.com/

>
>> See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/slab.h?h=v7.2#n1001
>>
>> In this case, kmalloc is used to request > 4MB memory.
>>
>>>
>>> Regardless, if it is important to let kernel developers know that their
>>> code is doing something wrong, why not make the WARN conditional on
>>> CONFIG_EXPERT or something similar?  In other words, prevent it from
>>> crashing production systems.
>
> You didn't respond to this.

I do not get your argument here. Why does this WARN need to be conditional
on CONFIG_EXPERT? What makes it special? Or you mean you want all WARNs
to be conditional CONFIG_EXPERT?

Anyway, if you do not want to check user input len and want core MM to
do the check. I will send a patch to make kmalloc return NULL when
the requested len is bigger than KMALLOC_MAX_SIZE without giving a warning,
based on my discussion with Vlastimil on IRC (he is out until next week).


Best Regards,
Yan, Zi

  reply	other threads:[~2026-08-17 18:45 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com>
2026-08-16 20:52 ` [syzbot] [mm?] WARNING in ep_write_iter Andrew Morton
2026-08-16 21:47   ` Zi Yan
2026-08-16 23:32     ` Alan Stern
2026-08-17  0:13       ` Zi Yan
2026-08-17  1:15         ` Alan Stern
2026-08-17  1:47           ` Zi Yan
2026-08-17  2:42             ` Andrew Morton
2026-08-17 13:55               ` Alan Stern
2026-08-17 14:34                 ` Zi Yan
2026-08-17 14:37                   ` Zi Yan
2026-08-17 15:06                     ` Alan Stern
2026-08-17 15:22                       ` Zi Yan
2026-08-17 15:37                         ` Alan Stern
2026-08-17 18:45                           ` Zi Yan [this message]
2026-08-18  3:12                             ` Alan Stern
2026-08-18 23:45                               ` Zi Yan
2026-08-19  1:30                                 ` Alan Stern
2026-08-17 15:06                   ` Greg Kroah-Hartman
2026-08-17 15:19                     ` Zi Yan
2026-08-17 15:55                       ` Greg Kroah-Hartman
2026-08-17 18:51                         ` Zi Yan
2026-08-17 20:34                           ` John Hubbard
2026-08-20 13:55   ` Zi Yan
2026-08-20 13:59     ` Zi Yan
2026-08-20 14:27       ` Alan Stern
2026-08-21  8:30   ` David Laight
2026-08-21 14:24     ` Zi Yan
2026-08-21 15:13       ` David Laight
2026-08-21 15:31         ` Zi Yan
2026-08-26 10:26           ` Vlastimil Babka (SUSE)
2026-08-17  9:14 ` syzbot
2026-08-17 19:45   ` Zi Yan
2026-08-20 13:15   ` Zi Yan
2026-08-20 13:30     ` syzbot

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=6FC11E12-9428-4975-B135-E24805C2D9BF@nvidia.com \
    --to=ziy@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=brendan.jackman@linux.dev \
    --cc=byungchul@sk.com \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=joshua.hahnjy@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=matthew.brost@intel.com \
    --cc=mhocko@suse.com \
    --cc=rakie.kim@sk.com \
    --cc=stern@rowland.harvard.edu \
    --cc=surenb@google.com \
    --cc=syzbot+805630f1453e490427fa@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=vbabka@kernel.org \
    --cc=ying.huang@linux.alibaba.com \
    /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