From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 3 16:41:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BBC5782 for ; Mon, 3 Feb 2014 16:41:14 +0000 (UTC) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 08EE51A35 for ; Mon, 3 Feb 2014 16:41:13 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i7so8457090oag.1 for ; Mon, 03 Feb 2014 08:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kR0OulDm3lFV8i8mWtuk4IUUfE28slL9y57IUaKg3rA=; b=cDvSzEg2gawMTYhN3ltNEjQOjWcQLSC7cHygWphp8Bu4Gzcv+dBM1W+VJRV74Bcqag JPtGRT6fkSBNueUju0RVzBsiOaV89XrnJ80gtFYPkWwRWJMqDqpGLDdboWiyJLj5YsS6 ZACHTjxFXg9Bhy4VSQEERDgXvAxj7utBPd64hv0MDNYpi3inPZ8ffo4jShROiR9V9uvT PI7MVgp98K5ps7/hQIpmKWv0P8N5KgfeWrKzcsiPvWPMwdBpw4dxBkh4dVYm+APgGYRS CTqoSea6cxb9CWyPPqh5YgTIIYP3lVB6W0jru1qTTlsVbWXeWpprrrUrr3EOanv1tICD V2BQ== MIME-Version: 1.0 X-Received: by 10.60.233.136 with SMTP id tw8mr641882oec.84.1391445673098; Mon, 03 Feb 2014 08:41:13 -0800 (PST) Received: by 10.76.130.196 with HTTP; Mon, 3 Feb 2014 08:41:13 -0800 (PST) Date: Mon, 3 Feb 2014 11:41:13 -0500 Message-ID: Subject: Races in ichsmb(9) when accessed from a multithreaded process From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 16:41:14 -0000 ichsmb.c has the following rather worrisome comment: * This driver assumes that the generic SMBus code will ensure that * at most one process at a time calls into the SMBus methods below. However, when I look at the code is sys/dev/smbus, I see nothing that actually guarantees this if two threads in the same process call ioctls on the same file descriptor. It does call smbus_request_bus, but mostly that just calls down into the smbus implementation (in this case ichsmb) with SMBUS_CALLBACK. ichsmb always just acks the request, so no actual locking ends up occurring. Is it intended that smb(9) clients be required to do their own locking? It seems to me that that is way more fragile than it needs to be.