NetBSD Problem Report #50296

From www@NetBSD.org  Sat Oct  3 22:08:05 2015
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 63DCBA57FE
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  3 Oct 2015 22:08:05 +0000 (UTC)
Message-Id: <20151003220804.37296A6555@mollari.NetBSD.org>
Date: Sat,  3 Oct 2015 22:08:04 +0000 (UTC)
From: asjdoran@gmail.com
Reply-To: asjdoran@gmail.com
To: gnats-bugs@NetBSD.org
Subject: gpio driver is marked MPSAFE but is not
X-Send-Pr-Version: www-1.0

>Number:         50296
>Category:       kern
>Synopsis:       gpio driver is marked MPSAFE but is not
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Oct 03 22:10:08 +0000 2015
>Originator:     Andrew Doran
>Release:        Any you like after 2011
>Organization:
The NetBSD Project
>Environment:
NetBSD fab-500.blowback 7.0_RC3 NetBSD 7.0_RC3 (GENERIC.201508110747Z) amd64

>Description:
The gpio driver has the D_MPSAFE flag, but there's very little in the
way of concurrency control.  Multiple threads in the driver at the same
time can be made to cause havoc.

>How-To-Repeat:
Code inspection.
>Fix:
For now remove the D_MPSAFE flag.  Later, fix it properly.  At a guess:

The existing mutex at IPL_VM, seems inappropriate since (1) GPIO often
implies lots of waiting (DELAY) especially if there is a line protocol
to be followed (2) GPIO probably doesn't deal with interrupts.

I suggest loosely following the approach used for locking the audio 
subsystem.

The hardware driver can have multiple attachments, for example multiple
GPIO busses.  The gpio framework doesn't know about that.  So arrange
to have the hardware driver provide an IPL_NONE lock back to the gpio
framework.

gpio probably doesn't need to deal with hardware interrupts.  Exclusion 
of interrupts would be peculiar to the hardware device driver, so keep
that there.

If necessary introduce a longer term lock based on condition variables
if there is some need for it, for example memory allocation.  See for
example audio_enter() and audio_exit().

Home	PR Database Search