From: "Zi Yan" <zi.yan@cs.rutgers.edu>
To: Michal Hocko <mhocko@kernel.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
syzbot <syzbot+5dcb560fe12aa5091c06@syzkaller.appspotmail.com>,
akpm@linux-foundation.org, aneesh.kumar@linux.vnet.ibm.com,
dan.j.williams@intel.com, kirill.shutemov@linux.intel.com,
linux-mm@kvack.org, mst@redhat.com,
syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk,
ying.huang@intel.com
Subject: Re: kernel BUG at mm/gup.c:LINE!
Date: Wed, 04 Jul 2018 07:48:27 -0400 [thread overview]
Message-ID: <FB141DA1-F8B8-4E9A-84E5-176B07463AEB@cs.rutgers.edu> (raw)
In-Reply-To: <20180704111731.GJ22503@dhcp22.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 3106 bytes --]
On 4 Jul 2018, at 7:17, Michal Hocko wrote:
> On Wed 04-07-18 19:01:51, Tetsuo Handa wrote:
>> +Michal Hocko
>>
>> On 2018/07/04 13:19, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit: d3bc0e67f852 Merge tag 'for-4.18-rc2-tag' of git://git.ker..
>>> git tree: upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1000077c400000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=a63be0c83e84d370
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=5dcb560fe12aa5091c06
>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>> userspace arch: i386
>>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=158577a2400000
>>
>> Here is C reproducer made from syz reproducer. mlockall(MCL_FUTURE) is involved.
>>
>> This problem is triggerable by an unprivileged user.
>> Shows different result on x86_64 (crash) and x86_32 (stall).
>>
>> ------------------------------------------------------------
>> /* Need to compile using "-m32" option if host is 64bit. */
>> #include <sys/types.h>
>> #include <sys/stat.h>
>> #include <fcntl.h>
>> #include <unistd.h>
>> #include <sys/mman.h>
>> int uselib(const char *library);
>>
>> int main(int argc, char *argv[])
>> {
>> int fd = open("file", O_WRONLY | O_CREAT, 0644);
>> write(fd, "\x7f\x45\x4c\x46\x00\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02"
>> "\x00\x06\x00\xca\x3f\x8b\xca\x00\x00\x00\x00\x38\x00\x00\x00\x00\x00"
>> "\x00\xf7\xff\xff\xff\xff\xff\xff\x1f\x00\x02\x00\x00\x00\x00\x00\x00"
>> "\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf8\x7b"
>> "\x66\xff\x00\x00\x05\x00\x00\x00\x76\x86\x00\x00\x00\x00\x00\x00\x00"
>> "\x00\x00\x00\x31\x0f\xf3\xee\xc1\xb0\x00\x0c\x08\x53\x55\xbe\x88\x47"
>> "\xc2\x2e\x30\xf5\x62\x82\xc6\x2c\x95\x72\x3f\x06\x8f\xe4\x2d\x27\x96"
>> "\xcc", 120);
>> fchmod(fd, 0755);
>> close(fd);
>> mlockall(MCL_FUTURE); /* Removing this line avoids the bug. */
>> uselib("file");
>> return 0;
>> }
>> ------------------------------------------------------------
>>
>> ------------------------------------------------------------
>> CentOS Linux 7 (Core)
>> Kernel 4.18.0-rc3 on an x86_64
>>
>> localhost login: [ 81.210241] emacs (9634) used greatest stack depth: 10416 bytes left
>> [ 140.099935] ------------[ cut here ]------------
>> [ 140.101904] kernel BUG at mm/gup.c:1242!
>
> Is this
> VM_BUG_ON(len != PAGE_ALIGN(len));
> in __mm_populate? I do not really get why we should VM_BUG_ON when the
> len is not page aligned to be honest. The library is probably containing
> some funky setup but if we simply cannot round up to the next PAGE_SIZE
> boundary then we should probably just error out and fail. This is an
> area I am really familiar with so I cannot really judge.
A strange thing is that __mm_populate() is only called by do_mlock() from mm/mlock.c,
which makes len PAGE_ALIGN already. That VM_BUG_ON should not be triggered.
—
Best Regards,
Yan Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]
next prev parent reply other threads:[~2018-07-04 11:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-04 4:19 syzbot
2018-07-04 10:01 ` Tetsuo Handa
2018-07-04 11:17 ` Michal Hocko
2018-07-04 11:48 ` Zi Yan [this message]
2018-07-04 12:11 ` Michal Hocko
2018-07-04 15:15 ` Oscar Salvador
2018-07-05 0:35 ` Tetsuo Handa
2018-07-05 7:18 ` Oscar Salvador
2018-07-05 11:40 ` Oscar Salvador
2018-07-05 6:44 ` Michal Hocko
2018-07-05 7:18 ` Oscar Salvador
2018-07-05 12:30 ` Oscar Salvador
2018-07-05 13:40 ` Tetsuo Handa
2018-07-06 5:35 ` Michal Hocko
2018-07-06 7:40 ` Oscar Salvador
2018-07-06 7:50 ` [PATCH] mm: do not bug_on on incorrect lenght in __mm_populate kbuild test robot
2018-07-06 8:23 ` Oscar Salvador
2018-07-06 9:02 ` Michal Hocko
2018-07-04 12:12 ` kernel BUG at mm/gup.c:LINE! Oscar Salvador
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=FB141DA1-F8B8-4E9A-84E5-176B07463AEB@cs.rutgers.edu \
--to=zi.yan@cs.rutgers.edu \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dan.j.williams@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mst@redhat.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=syzbot+5dcb560fe12aa5091c06@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
--cc=ying.huang@intel.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