From: Petr Vorel <pvorel@suse.cz>
To: Edward Liaw <edliaw@google.com>
Cc: kernel-team@android.com,
Alessandro Carminati <alessandro.carminati@gmail.com>,
ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2 2/3] set_dev_loop_path: Refactor set_dev_path and check return value
Date: Fri, 24 Mar 2023 07:12:34 +0100 [thread overview]
Message-ID: <20230324061234.GA516079@pevik> (raw)
In-Reply-To: <CAG4es9WSByGyehAh3fvw2W0o-sh974WNBKym-1gMwJUx-V+Bcw@mail.gmail.com>
> On Thu, Mar 23, 2023 at 1:52 AM Petr Vorel <pvorel@suse.cz> wrote:
> > Hi Edward,
> > > tst_find_free_loopdev does not check the return value of set_dev_path
> > > and will return the last attempted path even if it does not pass a stat
> > > check. set_dev_path also has a return value that is not consistent with
> > > the other functions in this file.
> > This change and change of return is a bit burden in loop rename changes.
> > I'm ok it's in single patch, but it'd be more readable if it were separate.
> Not a problem, I will split it.
+1
Also, please rebase (I pushed some changes) which touch files you also modify.
> > set_dev_path() is going to be called only if non-NULL path
> > (see include/tst_device.h). I haven't found a test which uses it this way,
> > but shouldn't it be checking path, instead of !path?
> > if (path && set_dev_loop_path(rc, path, path_len) != 0)
> > Kind regards,
> > Petr
> Oops, I missed that in the comment and thought a NULL path should be
> checked as an error. You are right, I will change it. Also, I wasn't
> sure if I should be explicit with the "!= 0".
I guess we are quite ok with just "!". We try to be precise at syscalls testing
(to check if the return value on error is exactly -1, not just < 0, but with
normal non-testing code like this in tst_kernel.c it's not needed.
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2023-03-24 6:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-20 23:51 [LTP] [PATCH v2 0/3] tst_device.c: Handle Android path for backing device Edward Liaw via ltp
2023-03-20 23:51 ` [LTP] [PATCH v2 1/3] tst_device.c: Use PATH_MAX more consistently Edward Liaw via ltp
2023-03-23 8:13 ` Petr Vorel
2023-03-20 23:51 ` [LTP] [PATCH v2 2/3] set_dev_loop_path: Refactor set_dev_path and check return value Edward Liaw via ltp
2023-03-23 8:52 ` Petr Vorel
2023-03-23 23:47 ` Edward Liaw via ltp
2023-03-24 6:12 ` Petr Vorel [this message]
2023-03-20 23:51 ` [LTP] [PATCH v2 3/3] tst_find_backing_dev: Also check /dev/block/ for backing device Edward Liaw via ltp
2023-03-23 8:53 ` Petr Vorel
2023-03-23 8:24 ` [LTP] [PATCH v2 0/3] tst_device.c: Handle Android path " Petr Vorel
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=20230324061234.GA516079@pevik \
--to=pvorel@suse.cz \
--cc=alessandro.carminati@gmail.com \
--cc=edliaw@google.com \
--cc=kernel-team@android.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 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.