Linux Test Project
 help / color / mirror / Atom feed
From: linuxtestproject.agent@gmail.com
To: Jinseok Kim <always.starving0@gmail.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] open01: fix cleanup file descriptor check
Date: Wed, 29 Jul 2026 16:27:58 +0000	[thread overview]
Message-ID: <20260729162758.8946-1-linuxtestproject.agent@gmail.com> (raw)
In-Reply-To: <20260729143243.8433-1-always.starving0@gmail.com>

Hi Jinseok,

On 2026-07-29, Jinseok Kim wrote:
> open01: fix cleanup file descriptor check

--- [PATCH 1/3] ---

> File descriptor 0 is valid, so checking fd > 0 may skip closing an
> successfully opened file.

Typo: "an successfully" -> "a successfully".

--- [PATCH 2/3] ---

>  } tcases[] = {
>  	{TEST_FILE, O_RDWR | O_CREAT, 01444, S_ISVTX, "sticky bit"},
> -	{TEST_DIR, O_DIRECTORY, 0, S_IFDIR, "directory bit"}
>  };

Only one entry is left in tcases[] now.

Is the .test + .tcnt parametrization still worth keeping here? The
convention is .test_all with a plain run() when there is a single test
case, unless more cases are planned on top of this.

>  	SAFE_CLOSE(fd);
>  	if (S_ISREG(buf.st_mode))
>  		SAFE_UNLINK(tc->filename);

This guard existed only to skip the unlink for the O_DIRECTORY case.

With that case removed the only remaining file is a regular one, so the
condition is always true. Can it be dropped and the unlink made
unconditional?

>   * 1. Open a new file with O_CREAT, fstat.st_mode should not have the
>   *    01000 (S_ISVTX) bit on. In Linux, the save text bit is *NOT* cleared.
> - * 2. Open a new directory with O_DIRECTORY, fstat.st_mode should have the
> - *    040000 (S_IFDIR) bit on.
>   */

The numbered list has a single "1." item left. Plain prose would read
better in the test catalog.

--- [PATCH 3/3] ---

> + * Verify that :manpage:`fstat(2)` correctly identifies various
> + * file types.

"various file types" does not say which ones. The commit message already
enumerates them, so how about moving that into the description, e.g.:

  Verify that :manpage:`fstat(2)` reports the correct file type in
  st_mode for regular files, directories, FIFOs, character devices and
  block devices.

> +#include <sys/sysmacros.h>
> +#include <fcntl.h>
> +
> +#include "tst_test.h"

O_PATH is used below but only <fcntl.h> is included. LTP carries a
fallback definition in include/lapi/fcntl.h for headers that predate
O_PATH, so "lapi/fcntl.h" should be included as well.

> +	TST_EXP_EXPR((buf.st_mode & S_IFMT) == tc->exp_type, "checking %s", tc->path);

On failure this only prints the path, not what was expected. Something
like "fstat() reports the expected type for %s" carries more information.

Also, for the character and block device cases only S_IFMT is checked
while st_rdev is ignored. Would it be worth comparing it against
makedev(1, 3) / makedev(7, 3) as well? statx01.c checks major/minor for
its device file.

> +static void cleanup(void)
> +{
> +	if (!access(REG_FILE, F_OK))
> +		SAFE_UNLINK(REG_FILE);
> +
> +	if (!access(DIR_FILE,  F_OK))
> +		SAFE_RMDIR(DIR_FILE);
> +
> +	if (!access(FIFO_FILE, F_OK))
> +		SAFE_UNLINK(FIFO_FILE);
> +
> +	if (!access(CHR_DEV, F_OK))
> +		SAFE_UNLINK(CHR_DEV);
> +
> +	if (!access(BLK_DEV, F_OK))
> +		SAFE_UNLINK(BLK_DEV);
> +}

Is any of this needed? Everything is created inside the framework tmpdir,
which is removed recursively at the end of the test, and MOUNT_PATH is
either a plain directory in that tmpdir or a tmpfs the framework unmounts
itself (prepare_and_mount_dev_fs() in lib/tst_test.c). Nothing here
outlives the test.

open11.c does the same touch/mkdir/mknod setup with .needs_devfs and has
no cleanup() at all.

Minor: "access(DIR_FILE,  F_OK)" has a double space.

> +	.mntpoint = MOUNT_PATH,
> +	.needs_devfs = 1,
> +	.needs_tmpdir = 1,
> +	.needs_root = 1,

.needs_tmpdir is redundant here, .mntpoint already implies the tmpdir
(see needs_tmpdir() in lib/tst_test.c). open11.c and fsetxattr02.c set
only .needs_devfs and .mntpoint.

Verdict - Needs revision

Pre-existing issues:

open01.c includes <errno.h> but never uses errno.

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

      parent reply	other threads:[~2026-07-29 16:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 14:32 [LTP] [PATCH v10 1/3] open01: fix cleanup file descriptor check Jinseok Kim
2026-07-29 14:32 ` [LTP] [PATCH v10 2/3] open01: remove O_DIRECTORY case (move to fstat test) Jinseok Kim
2026-07-29 14:32 ` [LTP] [PATCH v10 3/3] fstat: add test for multiple file types using fstat Jinseok Kim
2026-07-29 16:27 ` linuxtestproject.agent [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=20260729162758.8946-1-linuxtestproject.agent@gmail.com \
    --to=linuxtestproject.agent@gmail.com \
    --cc=always.starving0@gmail.com \
    --cc=ltp@lists.linux.it \
    /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