From: kernel test robot <lkp@intel.com>
To: Ahmet Eray Karadag <eraykrdg1@gmail.com>,
tytso@mit.edu, adilger.kernel@dilger.ca
Cc: oe-kbuild-all@lists.linux.dev, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org, david.hunter.linux@gmail.com,
skhan@linuxfoundation.org,
Ahmet Eray Karadag <eraykrdg1@gmail.com>,
syzbot+f3185be57d7e8dda32b8@syzkaller.appspotmail.com,
Albin Babu Varghese <albinbabuvarghese20@gmail.com>
Subject: Re: [PATCH] Fix: ext4: add sanity check for inode inline write range
Date: Fri, 10 Oct 2025 19:31:00 +0800 [thread overview]
Message-ID: <202510101841.kobch6UW-lkp@intel.com> (raw)
In-Reply-To: <20251007234221.28643-2-eraykrdg1@gmail.com>
Hi Ahmet,
kernel test robot noticed the following build warnings:
[auto build test WARNING on tytso-ext4/dev]
[also build test WARNING on linus/master v6.17 next-20251009]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Ahmet-Eray-Karadag/Fix-ext4-add-sanity-check-for-inode-inline-write-range/20251010-013008
base: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
patch link: https://lore.kernel.org/r/20251007234221.28643-2-eraykrdg1%40gmail.com
patch subject: [PATCH] Fix: ext4: add sanity check for inode inline write range
config: powerpc-randconfig-r073-20251010 (https://download.01.org/0day-ci/archive/20251010/202510101841.kobch6UW-lkp@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 14.3.0
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/202510101841.kobch6UW-lkp@intel.com/
smatch warnings:
fs/ext4/inline.c:789 ext4_write_inline_data_end() warn: inconsistent indenting
fs/ext4/inline.c:854 ext4_write_inline_data_end() error: uninitialized symbol 'ret2'.
vim +789 fs/ext4/inline.c
775
776 int ext4_write_inline_data_end(struct inode *inode, loff_t pos, unsigned len,
777 unsigned copied, struct folio *folio)
778 {
779 handle_t *handle = ext4_journal_current_handle();
780 int no_expand;
781 void *kaddr;
782 struct ext4_iloc iloc;
783 int ret = 0, ret2;
784
785 if ((pos + len) > EXT4_I(inode)->i_inline_size) {
786 ext4_warning_inode(inode,
787 "inline write beyond capacity (pos=%lld, len=%u, inline_size=%d)",
788 pos, len, EXT4_I(inode)->i_inline_size);
> 789 folio_unlock(folio);
790 folio_put(folio);
791 ret = -EINVAL;
792 goto out;
793 }
794
795 if (unlikely(copied < len) && !folio_test_uptodate(folio))
796 copied = 0;
797
798 if (likely(copied)) {
799 ret = ext4_get_inode_loc(inode, &iloc);
800 if (ret) {
801 folio_unlock(folio);
802 folio_put(folio);
803 ext4_std_error(inode->i_sb, ret);
804 goto out;
805 }
806 ext4_write_lock_xattr(inode, &no_expand);
807 BUG_ON(!ext4_has_inline_data(inode));
808
809 /*
810 * ei->i_inline_off may have changed since
811 * ext4_write_begin() called
812 * ext4_try_to_write_inline_data()
813 */
814 (void) ext4_find_inline_data_nolock(inode);
815
816 kaddr = kmap_local_folio(folio, 0);
817 ext4_write_inline_data(inode, &iloc, kaddr, pos, copied);
818 kunmap_local(kaddr);
819 folio_mark_uptodate(folio);
820 /* clear dirty flag so that writepages wouldn't work for us. */
821 folio_clear_dirty(folio);
822
823 ext4_write_unlock_xattr(inode, &no_expand);
824 brelse(iloc.bh);
825
826 /*
827 * It's important to update i_size while still holding folio
828 * lock: page writeout could otherwise come in and zero
829 * beyond i_size.
830 */
831 ext4_update_inode_size(inode, pos + copied);
832 }
833 folio_unlock(folio);
834 folio_put(folio);
835
836 /*
837 * Don't mark the inode dirty under folio lock. First, it unnecessarily
838 * makes the holding time of folio lock longer. Second, it forces lock
839 * ordering of folio lock and transaction start for journaling
840 * filesystems.
841 */
842 if (likely(copied))
843 mark_inode_dirty(inode);
844 out:
845 /*
846 * If we didn't copy as much data as expected, we need to trim back
847 * size of xattr containing inline data.
848 */
849 if (pos + len > inode->i_size && ext4_can_truncate(inode))
850 ext4_orphan_add(handle, inode);
851 if (handle)
852 ret2 = ext4_journal_stop(handle);
853 if (!ret)
> 854 ret = ret2;
855 if (pos + len > inode->i_size) {
856 ext4_truncate_failed_write(inode);
857 /*
858 * If truncate failed early the inode might still be
859 * on the orphan list; we need to make sure the inode
860 * is removed from the orphan list in that case.
861 */
862 if (inode->i_nlink)
863 ext4_orphan_del(NULL, inode);
864 }
865 return ret ? ret : copied;
866 }
867
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
prev parent reply other threads:[~2025-10-10 11:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-07 23:42 [PATCH] Fix: ext4: add sanity check for inode inline write range Ahmet Eray Karadag
2025-10-08 0:47 ` Darrick J. Wong
2025-10-08 12:34 ` Theodore Ts'o
2025-10-08 13:40 ` Ahmet Eray Karadag
2025-10-09 14:21 ` David Hunter
2025-10-10 11:31 ` kernel test robot [this message]
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=202510101841.kobch6UW-lkp@intel.com \
--to=lkp@intel.com \
--cc=adilger.kernel@dilger.ca \
--cc=albinbabuvarghese20@gmail.com \
--cc=david.hunter.linux@gmail.com \
--cc=eraykrdg1@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=skhan@linuxfoundation.org \
--cc=syzbot+f3185be57d7e8dda32b8@syzkaller.appspotmail.com \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).