All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: oe-kbuild-all@lists.linux.dev
Subject: [amir73il:fan_pre_content 10/10] mm/filemap.c:3300:6: error: call to undeclared function 'fsnotify_inode_has_content_watches'; ISO C99 and later do not support implicit function declarations
Date: Sun, 21 Jul 2024 03:47:41 +0800	[thread overview]
Message-ID: <202407210334.HzApW0Mu-lkp@intel.com> (raw)

tree:   https://github.com/amir73il/linux fan_pre_content
head:   cece9f2c54b579b2dee895863edf16cb3aa791a9
commit: cece9f2c54b579b2dee895863edf16cb3aa791a9 [10/10] fsnotify: generate pre-content permission event on page fault
config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20240721/202407210334.HzApW0Mu-lkp@intel.com/config)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240721/202407210334.HzApW0Mu-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202407210334.HzApW0Mu-lkp@intel.com/

All errors (new ones prefixed by >>):

>> mm/filemap.c:3300:6: error: call to undeclared function 'fsnotify_inode_has_content_watches'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    3300 |             fsnotify_inode_has_content_watches(inode)) {
         |             ^
   mm/filemap.c:3650:6: error: call to undeclared function 'fsnotify_inode_has_content_watches'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    3650 |         if (fsnotify_inode_has_content_watches(inode))
         |             ^
   2 errors generated.


vim +/fsnotify_inode_has_content_watches +3300 mm/filemap.c

  3251	
  3252	/**
  3253	 * filemap_fault - read in file data for page fault handling
  3254	 * @vmf:	struct vm_fault containing details of the fault
  3255	 *
  3256	 * filemap_fault() is invoked via the vma operations vector for a
  3257	 * mapped memory region to read in file data during a page fault.
  3258	 *
  3259	 * The goto's are kind of ugly, but this streamlines the normal case of having
  3260	 * it in the page cache, and handles the special cases reasonably without
  3261	 * having a lot of duplicated code.
  3262	 *
  3263	 * vma->vm_mm->mmap_lock must be held on entry.
  3264	 *
  3265	 * If our return value has VM_FAULT_RETRY set, it's because the mmap_lock
  3266	 * may be dropped before doing I/O or by lock_folio_maybe_drop_mmap().
  3267	 *
  3268	 * If our return value does not have VM_FAULT_RETRY set, the mmap_lock
  3269	 * has not been released.
  3270	 *
  3271	 * We never return with VM_FAULT_RETRY and a bit from VM_FAULT_ERROR set.
  3272	 *
  3273	 * Return: bitwise-OR of %VM_FAULT_ codes.
  3274	 */
  3275	vm_fault_t filemap_fault(struct vm_fault *vmf)
  3276	{
  3277		int error;
  3278		struct file *file = vmf->vma->vm_file;
  3279		struct file *fpin = NULL;
  3280		struct address_space *mapping = file->f_mapping;
  3281		struct inode *inode = mapping->host;
  3282		pgoff_t max_idx, index = vmf->pgoff;
  3283		struct folio *folio;
  3284		vm_fault_t ret = 0;
  3285		bool mapping_locked = false;
  3286	
  3287		max_idx = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
  3288		if (unlikely(index >= max_idx))
  3289			return VM_FAULT_SIGBUS;
  3290	
  3291		/*
  3292		 * If we have pre-content watchers then we need to generate events on
  3293		 * page fault so that we can populate any data before the fault.
  3294		 *
  3295		 * We only do this on the first pass through, otherwise the populating
  3296		 * application could potentially deadlock on the mmap lock if it tries
  3297		 * to populate it with mmap.
  3298		 */
  3299		if (fault_flag_allow_retry_first(vmf->flags) &&
> 3300		    fsnotify_inode_has_content_watches(inode)) {
  3301			int mask = (vmf->flags & FAULT_FLAG_WRITE) ? MAY_WRITE : MAY_READ;
  3302			loff_t pos = vmf->pgoff << PAGE_SHIFT;
  3303	
  3304			fpin = maybe_unlock_mmap_for_io(vmf, fpin);
  3305	
  3306			/*
  3307			 * We can only emit the event if we did actually release the
  3308			 * mmap lock.
  3309			 */
  3310			if (fpin) {
  3311				error = fsnotify_file_area_perm(fpin, mask, &pos,
  3312								PAGE_SIZE);
  3313				if (error) {
  3314					fput(fpin);
  3315					return VM_FAULT_ERROR;
  3316				}
  3317			}
  3318		}
  3319	
  3320		/*
  3321		 * Do we have something in the page cache already?
  3322		 */
  3323		folio = filemap_get_folio(mapping, index);
  3324		if (likely(!IS_ERR(folio))) {
  3325			/*
  3326			 * We found the page, so try async readahead before waiting for
  3327			 * the lock.
  3328			 */
  3329			if (!(vmf->flags & FAULT_FLAG_TRIED))
  3330				fpin = do_async_mmap_readahead(vmf, folio, fpin);
  3331			if (unlikely(!folio_test_uptodate(folio))) {
  3332				filemap_invalidate_lock_shared(mapping);
  3333				mapping_locked = true;
  3334			}
  3335		} else {
  3336			ret = filemap_fault_recheck_pte_none(vmf);
  3337			if (unlikely(ret))
  3338				return ret;
  3339	
  3340			/* No page in the page cache at all */
  3341			count_vm_event(PGMAJFAULT);
  3342			count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
  3343			ret = VM_FAULT_MAJOR;
  3344			fpin = do_sync_mmap_readahead(vmf, fpin);
  3345	retry_find:
  3346			/*
  3347			 * See comment in filemap_create_folio() why we need
  3348			 * invalidate_lock
  3349			 */
  3350			if (!mapping_locked) {
  3351				filemap_invalidate_lock_shared(mapping);
  3352				mapping_locked = true;
  3353			}
  3354			folio = __filemap_get_folio(mapping, index,
  3355						  FGP_CREAT|FGP_FOR_MMAP,
  3356						  vmf->gfp_mask);
  3357			if (IS_ERR(folio)) {
  3358				if (fpin)
  3359					goto out_retry;
  3360				filemap_invalidate_unlock_shared(mapping);
  3361				return VM_FAULT_OOM;
  3362			}
  3363		}
  3364	
  3365		if (!lock_folio_maybe_drop_mmap(vmf, folio, &fpin))
  3366			goto out_retry;
  3367	
  3368		/* Did it get truncated? */
  3369		if (unlikely(folio->mapping != mapping)) {
  3370			folio_unlock(folio);
  3371			folio_put(folio);
  3372			goto retry_find;
  3373		}
  3374		VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio);
  3375	
  3376		/*
  3377		 * We have a locked folio in the page cache, now we need to check
  3378		 * that it's up-to-date. If not, it is going to be due to an error,
  3379		 * or because readahead was otherwise unable to retrieve it.
  3380		 */
  3381		if (unlikely(!folio_test_uptodate(folio))) {
  3382			/*
  3383			 * If the invalidate lock is not held, the folio was in cache
  3384			 * and uptodate and now it is not. Strange but possible since we
  3385			 * didn't hold the page lock all the time. Let's drop
  3386			 * everything, get the invalidate lock and try again.
  3387			 */
  3388			if (!mapping_locked) {
  3389				folio_unlock(folio);
  3390				folio_put(folio);
  3391				goto retry_find;
  3392			}
  3393	
  3394			/*
  3395			 * OK, the folio is really not uptodate. This can be because the
  3396			 * VMA has the VM_RAND_READ flag set, or because an error
  3397			 * arose. Let's read it in directly.
  3398			 */
  3399			goto page_not_uptodate;
  3400		}
  3401	
  3402		/*
  3403		 * We've made it this far and we had to drop our mmap_lock, now is the
  3404		 * time to return to the upper layer and have it re-find the vma and
  3405		 * redo the fault.
  3406		 */
  3407		if (fpin) {
  3408			folio_unlock(folio);
  3409			goto out_retry;
  3410		}
  3411		if (mapping_locked)
  3412			filemap_invalidate_unlock_shared(mapping);
  3413	
  3414		/*
  3415		 * Found the page and have a reference on it.
  3416		 * We must recheck i_size under page lock.
  3417		 */
  3418		max_idx = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
  3419		if (unlikely(index >= max_idx)) {
  3420			folio_unlock(folio);
  3421			folio_put(folio);
  3422			return VM_FAULT_SIGBUS;
  3423		}
  3424	
  3425		vmf->page = folio_file_page(folio, index);
  3426		return ret | VM_FAULT_LOCKED;
  3427	
  3428	page_not_uptodate:
  3429		/*
  3430		 * Umm, take care of errors if the page isn't up-to-date.
  3431		 * Try to re-read it _once_. We do this synchronously,
  3432		 * because there really aren't any performance issues here
  3433		 * and we need to check for errors.
  3434		 */
  3435		fpin = maybe_unlock_mmap_for_io(vmf, fpin);
  3436		error = filemap_read_folio(file, mapping->a_ops->read_folio, folio);
  3437		if (fpin)
  3438			goto out_retry;
  3439		folio_put(folio);
  3440	
  3441		if (!error || error == AOP_TRUNCATED_PAGE)
  3442			goto retry_find;
  3443		filemap_invalidate_unlock_shared(mapping);
  3444	
  3445		return VM_FAULT_SIGBUS;
  3446	
  3447	out_retry:
  3448		/*
  3449		 * We dropped the mmap_lock, we need to return to the fault handler to
  3450		 * re-find the vma and come back and find our hopefully still populated
  3451		 * page.
  3452		 */
  3453		if (!IS_ERR(folio))
  3454			folio_put(folio);
  3455		if (mapping_locked)
  3456			filemap_invalidate_unlock_shared(mapping);
  3457		if (fpin)
  3458			fput(fpin);
  3459		return ret | VM_FAULT_RETRY;
  3460	}
  3461	EXPORT_SYMBOL(filemap_fault);
  3462	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

                 reply	other threads:[~2024-07-20 19:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=202407210334.HzApW0Mu-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=amir73il@gmail.com \
    --cc=oe-kbuild-all@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.