Date: Tue, 18 Apr 2017 23:17:26 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 218597] [CRYPTODEV] spurious wakeup and synchronisation problem Message-ID: <bug-218597-8-Tt2kseaGdD@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-218597-8@https.bugs.freebsd.org/bugzilla/> References: <bug-218597-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218597 --- Comment #3 from John Baldwin <jhb@FreeBSD.org> --- There's certainly nothing to prevent multiple threads from issuing ioctls against the same session. (However, having 'error' in the cse is buggy, bu= t it should also just be removed as all the uses of it check the crp->crp_etype = it is copied from just before using it anyway.) The problem is that CRYPTO_F_DONE isn't really safe for how the /dev/crypto ioctl handlers are using it (and probably isn't safe to use at all and shou= ld arguably be removed). Instead, the sleeps need to be conditional on a flag that the callback function itself sets. Probably the right way to handle t= his is to allocate a separate structure that crp_opaque points to that contains= the "done" flag and a pointer to the cse. The callback would set the done flag under the cse lock and then issue the wakeup, and the ioctl routines would sleep on this done flag in the new structure. Something like: struct crypt_op_data { bool done; struct csession *cse; } crypto_dev_op() { struct crypt_op_data *cod; ... cod =3D malloc(sizeof(*cod), M_WAITOK | M_ZERO); cod->cse =3D cse; ... crp->crp_opaque =3D cod; /* not 'cse' anymore */ ... crypto_dispatch(); mtx_lock(&cse->lock); while (error =3D=3D 0 && !cod->done) mtx_sleep(crp, &cse->lock, ...); mtx_unlock(&cse->lock); ... /* be sure to clear done if retrying */ } cryptodev_cb() { struct cryptop *crp =3D op; struct crypto_op_data *cod =3D crp->crp_opaque; mtx_lock(&cod->cse->lock); cod->done =3D true; mtx_unlock(&cod->cse->lock); wakeup(crp);=20=20=20=20 } --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-218597-8-Tt2kseaGdD>