Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <202307041023.bcdbbfc0-oliver.sang@intel.com>
In-Reply-To: <202307041023.bcdbbfc0-oliver.sang@intel.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue, 4 Jul 2023 07:12:23 -0700
Message-ID: <CAHk-=wi3Nb4t-JH6BGE5TOynik=-0kXyBGi3bLKTA85rvqHngQ@mail.gmail.com>
Subject: Re: [linus:master] [gup] a425ac5365: WARNING:at_mm/gup.c:#__get_user_pages
To:     kernel test robot <oliver.sang@intel.com>
Cc:     oe-lkp@lists.linux.dev, lkp@intel.com,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org
Content-Type: multipart/mixed; boundary="0000000000004cc04805ffa9e054"
Precedence: bulk

--0000000000004cc04805ffa9e054
Content-Type: text/plain; charset="UTF-8"

On Tue, 4 Jul 2023 at 00:03, kernel test robot <oliver.sang@intel.com> wrote:
>
> we noticed this commit 'add a (temporary) warning' for the case that
> 'anybody actually does anything quite this strange'.
> and in our this test, the warning hits. just FYI.

Yeah, so it looks like this is trinity doing system calls with random
arguments, and that will obviously hit the whole

  "GUP will no longer expand the stack, warn if somebody seems to want
to do GUP under the stack"

test.

So then it will warn if somebody passes in bogus addresses that *used*
to maybe work.

But with a random argument tester like trinity, passing in random
bogus addresses is obviously expected, so the warning will trigger
even if it's not something that we would not want to keep working.

I do not have a good idea for how to not warn for things like syzbot
and trinity that do random system calls, and only warn for any
potential real applications that do crazy things and expect them to
work.

And I *do* want the backtrace from the warning (in this case, it shows
that it's the "process_vm_readv/writev()" path, which actually might
be worth adding stack expansion to, the same way __access_remote_vm()
does).

I guess I can do the limiting manually, and just avoid WARN_ON_ONCE().

If I do just "dump_stack()", will the kernel test robot react to that
too? IOW, would a patch like the attached make the kernel test robot
not react?

              Linus

--0000000000004cc04805ffa9e054
Content-Type: text/x-patch; charset="US-ASCII"; name="patch.diff"
Content-Disposition: attachment; filename="patch.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_ljodbtsf0>
X-Attachment-Id: f_ljodbtsf0

IG1tL2d1cC5jIHwgMTggKysrKysrKysrKysrKysrKystCiAxIGZpbGUgY2hhbmdlZCwgMTcgaW5z
ZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL21tL2d1cC5jIGIvbW0vZ3Vw
LmMKaW5kZXggZWYyOTY0MTY3MWM3Li5jOWQ3OTlkMjhkZTcgMTAwNjQ0Ci0tLSBhL21tL2d1cC5j
CisrKyBiL21tL2d1cC5jCkBAIC0xMDkxLDYgKzEwOTEsMjEgQEAgc3RhdGljIGludCBjaGVja192
bWFfZmxhZ3Moc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEsIHVuc2lnbmVkIGxvbmcgZ3VwX2Zs
YWdzKQogCXJldHVybiAwOwogfQogCitzdGF0aWMgdm9pZCBndXBfc3RhY2tfZXhwYW5zaW9uX3dh
cm5pbmcoY29uc3Qgc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEsCisJdW5zaWduZWQgbG9uZyBh
ZGRyKQoreworCXN0YXRpYyB2b2xhdGlsZSB1bnNpZ25lZCBsb25nIG5leHRfd2FybjsKKwl1bnNp
Z25lZCBsb25nIG5vdyA9IGppZmZpZXMsIG5leHQgPSBuZXh0X3dhcm47CisKKwkvKiBMZXQncyBu
b3Qgd2FybiBtb3JlIHRoYW4gb25jZSBhbiBob3VyLi4gKi8KKwlpZiAobmV4dCAmJiB0aW1lX2Jl
Zm9yZShub3csIG5leHQpKQorCQlyZXR1cm47CisJbmV4dF93YXJuID0gbm93ICsgNjAqNjAqSFo7
CisJcHJfd2FybigiR1VQIG5vIGxvbmdlciBncm93cyB0aGUgc3RhY2sgJWx4LSVseCAoJWx4KVxu
IiwKKwkJdm1hLT52bV9zdGFydCwgdm1hLT52bV9lbmQsIGFkZHIpOworCWR1bXBfc3RhY2soKTsK
K30KKwogLyoqCiAgKiBfX2dldF91c2VyX3BhZ2VzKCkgLSBwaW4gdXNlciBwYWdlcyBpbiBtZW1v
cnkKICAqIEBtbToJCW1tX3N0cnVjdCBvZiB0YXJnZXQgbW0KQEAgLTExNzAsNyArMTE4NSw4IEBA
IHN0YXRpYyBsb25nIF9fZ2V0X3VzZXJfcGFnZXMoc3RydWN0IG1tX3N0cnVjdCAqbW0sCiAJCWlm
ICghdm1hIHx8IHN0YXJ0ID49IHZtYS0+dm1fZW5kKSB7CiAJCQl2bWEgPSBmaW5kX3ZtYShtbSwg
c3RhcnQpOwogCQkJaWYgKHZtYSAmJiAoc3RhcnQgPCB2bWEtPnZtX3N0YXJ0KSkgewotCQkJCVdB
Uk5fT05fT05DRSh2bWEtPnZtX2ZsYWdzICYgVk1fR1JPV1NET1dOKTsKKwkJCQlpZiAodW5saWtl
bHkodm1hLT52bV9mbGFncyAmIFZNX0dST1dTRE9XTikpCisJCQkJCWd1cF9zdGFja19leHBhbnNp
b25fd2FybmluZyh2bWEsIHN0YXJ0KTsKIAkJCQl2bWEgPSBOVUxMOwogCQkJfQogCQkJaWYgKCF2
bWEgJiYgaW5fZ2F0ZV9hcmVhKG1tLCBzdGFydCkpIHsK
--0000000000004cc04805ffa9e054--