[LTP] [PATCH 1/1 1/1] Add ioctl_loop08 test for LOOP_GET_STATUS lock imbalance
xiao shoukui
xiaoshoukui@gmail.com
Fri Feb 10 12:42:19 CET 2023
Sincere thanks for your advice.
Based on my tests,the lockdep will block the ioctl request thread return to
userspace when it detect a lock imbalance. Place ioctl request in the main
thread, there is no chance to execute find_kmsg for determining what
exactly a lock problem happaned and printing the test result.
On Fri, Feb 10, 2023 at 6:47 PM Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
> > +static void verify_ioctl_loop(void)
> > +{
> > + struct tcase *tc = &tcases[0];
> > + pthread_t th1, th2;
> > +
> > + pthread_create(&th1, NULL, ioctl_thread, tc);
> > + usleep(500000);
> > + pthread_create(&th2, NULL, ioctl_thread, tc + 1);
> > + usleep(500000);
>
> This part looks strange, why do we run the code that calls the ioctl in
> a separate thread if we are sleeping after the thread has been created
> and quite likely the thread will finish before the main thread returns
> from the sleep?
>
> Why can we just call the ioctl_thread() sequentially here?
>
> > + if (!find_kmsg(lock_imbalance))
> > + tst_res(TFAIL, "Trigger lock imbalance");
> > + else
> > + tst_res(TPASS, "Nothing bad happened, probably");
> > +}
> > +
> > +static struct tst_test test = {
> > + .test_all = verify_ioctl_loop,
> > + .needs_root = 1,
> > + .needs_kconfigs = (const char *[]) {
> > + "CONFIG_LOCKDEP=y",
> > + NULL },
> > + .tags = (const struct tst_tag[]) {
> > + { "linux-git", "bdac616db9bb "},
> > + {}
> > + },
> > + .needs_drivers = (const char *const[]) {
> > + "loop",
> > + NULL }
>
> The whitespaces here are all messed up.
>
> > +};
> > --
> > 2.20.1
> >
> >
> > --
> > Mailing list info: https://lists.linux.it/listinfo/ltp
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
More information about the ltp
mailing list