From: kernel test robot <lkp@intel.com>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: oe-kbuild-all@lists.linux.dev, fuse-devel@lists.sourceforge.net
Subject: [mszeredi-fuse:extent-map-v2 22/28] fs/fuse/iomode.c:231:11: warning: variable 'err' is used uninitialized whenever 'if' condition is false
Date: Fri, 02 Oct 2026 08:11:29 +0200 [thread overview]
Message-ID: <202610020858.9R8H2Vqa-lkp@intel.com> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git extent-map-v2
head: 5c4fbaa4906d18f12935a5920c3b789b827a1b01
commit: ba6831ba66ccaf841f3cda3e6fc8dca0d8689cf1 [22/28] fuse: add helpers for EIO return value with kernel message
config: sparc64-randconfig-r2307-20261001 (https://download.01.org/0day-ci/archive/20261002/202610020858.9R8H2Vqa-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
sparse: v0.6.5-rc1
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261002/202610020858.9R8H2Vqa-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/202610020858.9R8H2Vqa-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> fs/fuse/iomode.c:231:11: warning: variable 'err' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
231 | else if (!fuse_file_cached_io_open(inode, ff))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fs/fuse/iomode.c:234:9: note: uninitialized use occurs here
234 | return err;
| ^~~
fs/fuse/iomode.c:231:7: note: remove the 'if' if its condition is always true
231 | else if (!fuse_file_cached_io_open(inode, ff))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
232 | err = fuse_EIO("conflicting passthrough open");
fs/fuse/iomode.c:193:9: note: initialize the variable 'err' to silence this warning
193 | int err;
| ^
| = 0
1 warning generated.
vim +231 fs/fuse/iomode.c
187
188 /* Request access to submit new io to inode via open file */
189 int fuse_file_io_open(struct file *file, struct inode *inode)
190 {
191 struct fuse_file *ff = file->private_data;
192 struct fuse_inode *fi = get_fuse_inode(inode);
193 int err;
194
195 /*
196 * io modes are not relevant with virtiofs DAX and with server that does not
197 * implement open.
198 */
199 if (FUSE_IS_VDAX(inode) || !ff->args)
200 return 0;
201
202 /*
203 * Server is expected to use FOPEN_PASSTHROUGH for all opens of an inode
204 * which is already open for passthrough. Using incorrect open mode is
205 * a server mistake, which results in user visible failure of open()
206 * with EIO error.
207 */
208 if (fuse_inode_backing(fi) && !(ff->open_flags & FOPEN_PASSTHROUGH))
209 return fuse_EIO("FOPEN_PASSTHROUGH expected");
210
211 /*
212 * FOPEN_PARALLEL_DIRECT_WRITES requires FOPEN_DIRECT_IO.
213 */
214 if (!(ff->open_flags & FOPEN_DIRECT_IO))
215 ff->open_flags &= ~FOPEN_PARALLEL_DIRECT_WRITES;
216
217 /*
218 * First passthrough file open denies caching inode io mode.
219 * First caching file open enters caching inode io mode.
220 *
221 * Note that if user opens a file open with O_DIRECT, but server did
222 * not specify FOPEN_DIRECT_IO, a later fcntl() could remove O_DIRECT,
223 * so we put the inode in caching mode to prevent parallel dio.
224 */
225 if ((ff->open_flags & FOPEN_DIRECT_IO) &&
226 !(ff->open_flags & FOPEN_PASSTHROUGH))
227 return 0;
228
229 if (ff->open_flags & FOPEN_PASSTHROUGH)
230 err = fuse_file_passthrough_open(inode, file);
> 231 else if (!fuse_file_cached_io_open(inode, ff))
232 err = fuse_EIO("conflicting passthrough open");
233
234 return err;
235 }
236
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
reply other threads:[~2026-10-02 6:11 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=202610020858.9R8H2Vqa-lkp@intel.com \
--to=lkp@intel.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=mszeredi@redhat.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.