Re: kern/58869: ipmi(4) holds sc_cmd_mtx across copyout, needed for wdog tickle

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/58869; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/58869: ipmi(4) holds sc_cmd_mtx across copyout, needed for wdog tickle
Date: Tue, 3 Dec 2024 14:51:38 +0000

 > Fix:
 > Narrow the scope of sc_cmd_mtx in ipmi_ioctl to
 > ipmi_sendcmd/recvcmd, not malloc/copyin/copyout.
 
 Oops -- it's not quite that simple because there's also a longer-term
 lock, sc_mode.  Need to work around that too.
 
 This is a bit troublesome because in the /dev/ipmi0 ioctl interface,
 when userland invokes ioctl(IPMICTL_SEND_COMMAND) it blocks watchdog
 tickles until userland later invokes ioctl(IPMICTL_RECEIVE_MSG).
 
 It seems to me either
 
 (a) there should just be a combined ioctl for send/recv (but I have no
     idea how widespread this ioctl interface is, maybe it's used by
     important applications like sysutils/ipmitool so we can't just
     remove IPMICTL_SEND_COMMAND and IPMICTL_RECEIVE_MSG); or
 
 (b) IPMICTL_SEND_COMMAND should do ipmi_recvmsg and save it in a
     buffer for the next IPMICTL_RECEIVE_MSG; or
 
 (c) if ipmi_recvmsg might take longer than IPMICTL_SEND_COMMAND is
     supposed to wait, it should be deferred to an asynchronous thread
     so the watchdog tickle is only held up by the ipmi(4)
     responsiveness and not by arbitrary userland dawdling.