From owner-freebsd-arch@freebsd.org Mon May 8 19:48:44 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16E08D63E79 for ; Mon, 8 May 2017 19:48:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB5B417E1 for ; Mon, 8 May 2017 19:48:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x242.google.com with SMTP id 67so3775439itx.2 for ; Mon, 08 May 2017 12:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3peXJ0wZKGtPtCfQhxN6AbwRzxUMGinjB7ec9XqR2D8=; b=rqklCcS742FYLeyyuupKp5fySExM4WZzd7BRsa049jTqnSUvoy6zDDkPqYxQWvwvhV mjSgfHraJ5P0fq2FUWg45I2NwccCsvSz9xneVwsQABE6RAa+Ly2vXEuQUPDTAZ9BTm6k yFJ3qAg0oOPzwcXOSS6oxVg2el9KSUZBLtxTmCPFCXb529HhHdbnmBnGIpwi/Qh9jYzj dJRZ4TmX37kSbn3aFpaGGPoJVG/f9XbPZTQCU4+eHmuXgzCYuh8Sgi9fdAhKDW4CaUJc 2nPlgtPjj7t++misgArwxjgp9J22Wi+oRwLbWZ8LUX/Cn6mWlaNoNu/TAp9p/FHo3EFJ Bz5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3peXJ0wZKGtPtCfQhxN6AbwRzxUMGinjB7ec9XqR2D8=; b=df0LpwgCvipyRXPCG5JSunbiBQqD1zztaA3ZLL6D/ZqlzsrYteqgHbGmwrdWyInUpd INXftn9OoRRe9HX/SMyqZdQ0iHqfTU2rQWdhABr/xlnNU+u68j340Y8fGGnmITAl5Q43 bJFPcDCQ0nFpJqqM6vXWRbAcW1/pMD5FTEpC0znqIJOdvpaRiE8ym5SEH5YHttffV3kx u2e3DYiyFlGO94jHI5/9LnX4yZmNCQjcnR1jDwm0ygddnAjbyre6TVFGzIkc/IuAwT2Z tOpippmGzHCpMVqzLsMWl8MNOSCxzcC4Na7+tYgr/NQRef8wkpEHZotsdrU1iMQji6dM EOSw== X-Gm-Message-State: AN3rC/4S+gfCGt8LdEZbaQu4vsqilnV8O5ltCzUVc654ESfZx3QyTEtE BCnwYN6Biy7XA7Kj0OLZnme0dlga5Q== X-Received: by 10.36.3.136 with SMTP id e130mr21528388ite.64.1494272922577; Mon, 08 May 2017 12:48:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.126.6 with HTTP; Mon, 8 May 2017 12:48:42 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::333f] In-Reply-To: <20170508193935.GE1622@kib.kiev.ua> References: <80600e8d3da7725a66e2a1e24cbfd916@kondratyev.su> <20170508193935.GE1622@kib.kiev.ua> From: Warner Losh Date: Mon, 8 May 2017 13:48:42 -0600 X-Google-Sender-Auth: am7YQ9GvqW3v0KNZ6clj3BIlRow Message-ID: Subject: Re: psm(4) & atkbdc(4) locking To: Konstantin Belousov Cc: Vladimir Kondratyev , owner-freebsd-arch@freebsd.org, "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 19:48:44 -0000 On Mon, May 8, 2017 at 1:39 PM, Konstantin Belousov wrote: > On Mon, May 08, 2017 at 09:58:27PM +0300, Vladimir Kondratyev wrote: >> On 2017-05-08 21:39, Warner Losh wrote: >> > On Mon, May 8, 2017 at 12:33 PM, Vladimir Kondratyev >> > wrote: >> >> Hi All >> >> >> >> In order to implement evdev support in psm(4) driver I`m going to add >> >> mutexes to psm and atkbdc drivers and mark psm interrupt and cdev >> >> handlers >> >> MPSAFE. >> >> Atkbd(4) is depending on Giant like before. >> >> >> >> Locking of these drivers seems to be low-hanging fruit as spl() calls >> >> are >> >> still in place but it has not occurred. >> >> >> >> Does someone know why it is not done yet? For reasons other than >> >> "Nobody >> >> took care of it"? >> >> Any hidden traps? >> > >> > Working rock-solid reliably in ddb(4) is what tripped me up when I >> > started down this path 10 years ago. >> >> I tried to avoid atkbd changes as much as possible. Patch adds atkbdc >> mutex acquisition >> before each hardware access and nothing more. I think mutexes should be >> ignored in ddb mode. > Locks are not ignored in kdb_active mode, and this is reasonable. > Instead, kdb should not acquire locks at all. > > Consider a situation where you need to send a composite command to > the hardware, which consists of several registers accesses, and the > whole sequence of accesses is covered by a lock to ensure atomicity. > Kdb may be entered at arbitrary moment, including the middle of the > lock-protected section. This means that kdb might be entered with the > lock owned by some thread, not neccessary the thread which was executing > when entrance occured. More, the hardware state is some intermediate > state of being commanded the composite sequence, not yet finished. Yes. This is the snag I ran into... > I do not think that atkbd code correctly handles this situation now, > and simply adding a lock there probably make things worse. It did for me, since breaking to keyboard was totally broken by the changes I made to try to lock things since it was quite likely to interrupt things when locks were held... I had a very naive implementation, which wasn't up to the task, so some care is needed. But this was in the 5.x or 6.x time frame, and the locking situation wrt GIANT is much better today than then... I don't think it's a huge problem, but just one that the implementor needs to be aware of... Since I was unaware of all the details up front, I came up with a solution that couldn't possibly work so I abandoned it. Warner >> > Understanding all the rules for >> > that was a bridge too far for me given the time I had for the project >> > then. If you have that covered (I haven't looked at the diffs yet), >> > you're golden. >> >> I`m not familiar with ddb internals, that is why i wrote first mail. >> >> > >> > Warner >> >> >> >> Patches can be found here: >> >> https://reviews.freebsd.org/D10263 (atkbdc, serialize hw registers >> >> access) >> >> https://reviews.freebsd.org/D10264 (psm, serialize softc access, mark >> >> interrupt and cdev handlers MPSAFE) >> >> >> >> -- >> WBR >> Vladimir Kondratyev >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"