From: kbuild test robot <lkp@intel.com>
To: Peter Xu <peterx@redhat.com>
Cc: kbuild-all@lists.01.org, Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: [hnaz-linux-mm:master 90/340] arch/x86/mm/fault.c:1468:34: sparse: sparse: incorrect type in argument 1 (different base types)
Date: Wed, 11 Mar 2020 12:30:41 +0800 [thread overview]
Message-ID: <202003111238.LoxsD1le%lkp@intel.com> (raw)
tree: https://github.com/hnaz/linux-mm master
head: 5d9ee416b5701096536c7a63c04dbe25012baa9e
commit: 79181dfcc4b8c2091126a8b3175957a598ae61e1 [90/340] x86/mm: use helper fault_signal_pending()
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-174-g094d5a94-dirty
git checkout 79181dfcc4b8c2091126a8b3175957a598ae61e1
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> arch/x86/mm/fault.c:1468:34: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int fault_flags @@ got restricted vm_fault_t [assignedunsigned int fault_flags @@
>> arch/x86/mm/fault.c:1468:34: sparse: expected unsigned int fault_flags
>> arch/x86/mm/fault.c:1468:34: sparse: got restricted vm_fault_t [assigned] [usertype] fault
>> include/linux/sched/signal.h:381:16: sparse: sparse: restricted vm_fault_t degrades to integer
vim +1468 arch/x86/mm/fault.c
1392
1393 /*
1394 * Kernel-mode access to the user address space should only occur
1395 * on well-defined single instructions listed in the exception
1396 * tables. But, an erroneous kernel fault occurring outside one of
1397 * those areas which also holds mmap_sem might deadlock attempting
1398 * to validate the fault against the address space.
1399 *
1400 * Only do the expensive exception table search when we might be at
1401 * risk of a deadlock. This happens if we
1402 * 1. Failed to acquire mmap_sem, and
1403 * 2. The access did not originate in userspace.
1404 */
1405 if (unlikely(!down_read_trylock(&mm->mmap_sem))) {
1406 if (!user_mode(regs) && !search_exception_tables(regs->ip)) {
1407 /*
1408 * Fault from code in kernel from
1409 * which we do not expect faults.
1410 */
1411 bad_area_nosemaphore(regs, hw_error_code, address);
1412 return;
1413 }
1414 retry:
1415 down_read(&mm->mmap_sem);
1416 } else {
1417 /*
1418 * The above down_read_trylock() might have succeeded in
1419 * which case we'll have missed the might_sleep() from
1420 * down_read():
1421 */
1422 might_sleep();
1423 }
1424
1425 vma = find_vma(mm, address);
1426 if (unlikely(!vma)) {
1427 bad_area(regs, hw_error_code, address);
1428 return;
1429 }
1430 if (likely(vma->vm_start <= address))
1431 goto good_area;
1432 if (unlikely(!(vma->vm_flags & VM_GROWSDOWN))) {
1433 bad_area(regs, hw_error_code, address);
1434 return;
1435 }
1436 if (unlikely(expand_stack(vma, address))) {
1437 bad_area(regs, hw_error_code, address);
1438 return;
1439 }
1440
1441 /*
1442 * Ok, we have a good vm_area for this memory access, so
1443 * we can handle it..
1444 */
1445 good_area:
1446 if (unlikely(access_error(hw_error_code, vma))) {
1447 bad_area_access_error(regs, hw_error_code, address, vma);
1448 return;
1449 }
1450
1451 /*
1452 * If for any reason at all we couldn't handle the fault,
1453 * make sure we exit gracefully rather than endlessly redo
1454 * the fault. Since we never set FAULT_FLAG_RETRY_NOWAIT, if
1455 * we get VM_FAULT_RETRY back, the mmap_sem has been unlocked.
1456 *
1457 * Note that handle_userfault() may also release and reacquire mmap_sem
1458 * (and not return with VM_FAULT_RETRY), when returning to userland to
1459 * repeat the page fault later with a VM_FAULT_NOPAGE retval
1460 * (potentially after handling any pending signal during the return to
1461 * userland). The return to userland is identified whenever
1462 * FAULT_FLAG_USER|FAULT_FLAG_KILLABLE are both set in flags.
1463 */
1464 fault = handle_mm_fault(vma, address, flags);
1465 major |= fault & VM_FAULT_MAJOR;
1466
1467 /* Quick path to respond to signals */
> 1468 if (fault_signal_pending(fault, regs)) {
1469 if (!user_mode(regs))
1470 no_context(regs, hw_error_code, address, SIGBUS,
1471 BUS_ADRERR);
1472 return;
1473 }
1474
1475 /*
1476 * If we need to retry the mmap_sem has already been released,
1477 * and if there is a fatal signal pending there is no guarantee
1478 * that we made any progress. Handle this case first.
1479 */
1480 if (unlikely((fault & VM_FAULT_RETRY) &&
1481 (flags & FAULT_FLAG_ALLOW_RETRY))) {
1482 /* Retry at most once */
1483 flags &= ~FAULT_FLAG_ALLOW_RETRY;
1484 flags |= FAULT_FLAG_TRIED;
1485 goto retry;
1486 }
1487
1488 up_read(&mm->mmap_sem);
1489 if (unlikely(fault & VM_FAULT_ERROR)) {
1490 mm_fault_error(regs, hw_error_code, address, fault);
1491 return;
1492 }
1493
1494 /*
1495 * Major/minor page fault accounting. If any of the events
1496 * returned VM_FAULT_MAJOR, we account it as a major fault.
1497 */
1498 if (major) {
1499 tsk->maj_flt++;
1500 perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1, regs, address);
1501 } else {
1502 tsk->min_flt++;
1503 perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1, regs, address);
1504 }
1505
1506 check_v8086_mode(regs, address, tsk);
1507 }
1508 NOKPROBE_SYMBOL(do_user_addr_fault);
1509
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
next reply other threads:[~2020-03-11 4:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-11 4:30 kbuild test robot [this message]
2020-03-11 14:59 ` Peter Xu
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=202003111238.LoxsD1le%lkp@intel.com \
--to=lkp@intel.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=kbuild-all@lists.01.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.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