From owner-freebsd-scsi Sun Dec 8 6: 8:11 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B83DA37B401 for ; Sun, 8 Dec 2002 06:08:10 -0800 (PST) Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id B41B543EBE for ; Sun, 8 Dec 2002 06:08:08 -0800 (PST) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.3/8.12.3) with ESMTP id gB8E83m2076045; Sun, 8 Dec 2002 17:08:03 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.3/8.12.3/Submit) id gB8E7un8076044; Sun, 8 Dec 2002 17:07:56 +0300 (MSK) Date: Sun, 8 Dec 2002 17:07:56 +0300 From: Yar Tikhiy To: "Kenneth D. Merry" Cc: Nate Lawson , freebsd-scsi@FreeBSD.ORG Subject: Re: {da,sa,...}open bug? Message-ID: <20021208170756.A75509@comp.chem.msu.su> References: <20021206145942.I80257@comp.chem.msu.su> <20021206123401.A23249@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021206123401.A23249@panzer.kdm.org>; from ken@kdm.org on Fri, Dec 06, 2002 at 12:34:01PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Dec 06, 2002 at 12:34:01PM -0700, Kenneth D. Merry wrote: > > Yar asked me to review his previous patch to a number of peripheral drivers > that modifed the acquire/unlock/etc. order. I've asked Justin to take a > look at it as well (thus the reason I haven't completed the review yet), > but what you have above will likely cause a panic. > > cam_periph_acquire() only returns an error when periph == NULL. If, for > some wild reason, a locked periph manages to get freed (thus causing > cam_periph_acquire() to return CAM_REQ_CMP_ERR), cam_periph_unlock() > will panic (NULL pointer deference) when called with a NULL periph. First, I'd like to point out that freeing a periph doesn't cause a pointer to it to become NULL. Therefore, cam_periph_unlock() is extremely unlikely to panic since cam_periph_lock(), which in turn calls cam_periph_acquire(), has been successful (i.e., periph != NULL) My general impression is that that NULL check at the beginning of cam_periph_acquire() is one of safety belts for unwary programmers still left out there. I think it should be changed to something like this: KASSERT(periph != NULL, ("cam_periph_acquire: null periph")); After this change, it will be OK to unlock a periph on cam_periph_acquire() failure (granted someone have added code able to fail to the latter function.) -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 8 7:27:13 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E3EA37B401 for ; Sun, 8 Dec 2002 07:27:11 -0800 (PST) Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4FE643EA9 for ; Sun, 8 Dec 2002 07:27:09 -0800 (PST) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.3/8.12.3) with ESMTP id gB8FR7m2080085; Sun, 8 Dec 2002 18:27:07 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.3/8.12.3/Submit) id gB8FR6kp080084; Sun, 8 Dec 2002 18:27:06 +0300 (MSK) Date: Sun, 8 Dec 2002 18:27:06 +0300 From: Yar Tikhiy To: Nate Lawson Cc: freebsd-scsi@freebsd.org Subject: Re: {da,sa,...}open bug? Message-ID: <20021208182706.B75509@comp.chem.msu.su> References: <20021206145942.I80257@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nate@root.org on Fri, Dec 06, 2002 at 11:23:56AM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Dec 06, 2002 at 11:23:56AM -0800, Nate Lawson wrote: > On Fri, 6 Dec 2002, Yar Tikhiy wrote: > > Yet another daopen() issue came to my attention. The DA_OPEN_FLAG bit > > won't be reset back to 0 if daopen() has failed, thus leaving the device > > marked as open. Isn't the below patch necessary? > > > > The rest of scsi_* modules seem to not have this bug. > > > > -- > > Yar > > > > Index: scsi_da.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v > > retrieving revision 1.116 > > diff -u -r1.116 scsi_da.c > > --- scsi_da.c 29 Nov 2002 15:40:10 -0000 1.116 > > +++ scsi_da.c 6 Dec 2002 11:49:57 -0000 > > @@ -612,6 +612,7 @@ > > if ((softc->flags & DA_FLAG_PACK_REMOVABLE) != 0) > > daprevent(periph, PR_PREVENT); > > } else { > > + softc->flags &= ~DA_FLAG_OPEN; > > cam_periph_release(periph); > > } > > cam_periph_unlock(periph); > > You are correct. Ok to commit this w/ re@ approval The other periphs > don't use this flag. While writing a message to re@, I thought if we were propagating bad style with such patches. Wouldn't it be better to set the open flag and acquire the periph if and only if returning success? The open flag seems to be of no use before the return from daopen(). I.e., Index: scsi_da.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v retrieving revision 1.116 diff -u -r1.116 scsi_da.c --- scsi_da.c 29 Nov 2002 15:40:10 -0000 1.116 +++ scsi_da.c 8 Dec 2002 15:12:51 -0000 @@ -545,10 +545,6 @@ if ((error = cam_periph_lock(periph, PRIBIO|PCATCH)) != 0) return (error); /* error code from tsleep */ - if (cam_periph_acquire(periph) != CAM_REQ_CMP) - return(ENXIO); - softc->flags |= DA_FLAG_OPEN; - if ((softc->flags & DA_FLAG_PACK_INVALID) != 0) { /* Invalidate our pack information. */ disk_invalidate(&softc->disk); @@ -607,12 +603,15 @@ softc->device_stats.flags &= ~DEVSTAT_BS_UNAVAILABLE; } } + + if (error == 0) + if (cam_periph_acquire(periph) != CAM_REQ_CMP) + error = ENXIO; if (error == 0) { + softc->flags |= DA_FLAG_OPEN; if ((softc->flags & DA_FLAG_PACK_REMOVABLE) != 0) daprevent(periph, PR_PREVENT); - } else { - cam_periph_release(periph); } cam_periph_unlock(periph); return (error); =================================================================== Notice how we kill two birds with one stone: The "no unlock on error" bug is gone as well. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Dec 8 22:12:17 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BF3337B401; Sun, 8 Dec 2002 22:12:16 -0800 (PST) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FA4A43E4A; Sun, 8 Dec 2002 22:12:13 -0800 (PST) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.6/8.12.5) with ESMTP id gB96BFMj039525; Sun, 8 Dec 2002 23:11:15 -0700 (MST) (envelope-from gibbs@scsiguy.com) Date: Sun, 08 Dec 2002 23:11:15 -0700 From: "Justin T. Gibbs" To: "Kenneth D. Merry" , Nate Lawson Cc: Yar Tikhiy , freebsd-scsi@FreeBSD.ORG Subject: Re: {da,sa,...}open bug? Message-ID: <2179138112.1039414275@aslan.scsiguy.com> In-Reply-To: <20021206123401.A23249@panzer.kdm.org> References: <20021206145942.I80257@comp.chem.msu.su> <20021206123401.A23249@panzer.kdm.org> X-Mailer: Mulberry/3.0.0a5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Yar asked me to review his previous patch to a number of peripheral > drivers that modifed the acquire/unlock/etc. order. I've asked Justin to > take a look at it as well (thus the reason I haven't completed the review > yet), ... The patches look okay to me. Although the lock API was never fully implemented, it was indended to guarantee exclusive access to an underlying device while the lock is held. This is exactly what you might want during a device driver probe where multiple device drivers can attach simultaneously to the same device (e.g. pass and da both attach to direct access devices). If we were to follow the indended use of the API, the probe code would probably look like this: /* * Ensure periph is not de-allocated * out from under us. */ cam_periph_acquire(); /* * Gain exclusive access to the periph. */ cam_periph_lock(); /* * Perform probe. */ /* * Play nice with others. */ cam_periph_unlock(); return (0); with the appropriate release's and unlocks in the error cases of course. The lock and unlock calls would also be used in open during any device validation checks that require exclusive access. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 9 9:43:43 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E57E37B401 for ; Mon, 9 Dec 2002 09:43:42 -0800 (PST) Received: from mail0.lsil.com (mail0.lsil.com [147.145.40.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF9AB43EBE for ; Mon, 9 Dec 2002 09:43:41 -0800 (PST) (envelope-from emoore@lsil.com) Received: from mhbs.lsil.com (mhbs.lsil.com [147.145.31.100]) by mail0.lsil.com (8.12.4/8.12.4) with ESMTP id gB9Hbxtx028757 for ; Mon, 9 Dec 2002 09:43:06 -0800 (PST) Received: from atl1.se.lsil.com by mhbs.lsil.com with ESMTP for freebsd-scsi@FreeBSD.ORG; Mon, 9 Dec 2002 09:43:26 -0800 Received: by EXA-ATLANTA.se.lsil.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 12:43:25 -0500 Message-Id: <0E3FA95632D6D047BA649F95DAB60E57017EF853@EXA-ATLANTA.se.lsil.com> From: "Moore, Eric Dean" To: freebsd-scsi@FreeBSD.ORG Subject: xpt_bus_register() - panic: malloc: wrong bucket Date: Mon, 9 Dec 2002 12:43:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi - When I load/unload/load the megaraid amr driver I get a panic. I'm using the latest -stable. kldload -v amr.ko kldunload amr kldload -v amr.ko (1) This panic is coming from xpt_bus_register() on 4073 in file cam_xpt.c: new_bus = ( struct cam_eb*)malloc(sizeof(*new_bus), M_DEVBUF, M_NOWAIT); (2) This malloc() is allocating 44 bytes for the new_bus structure: In /sys/kern/kern_malloc.c on line 272: kup = btokup(va); if ( kup->ku_indx != indx) panic("malloc: wrong bucket"); Any ideas? Is the amr driver not properly cleaning up the cam interface when deregistering? -Eric Moore To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 9 11: 2:20 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C48F637B404 for ; Mon, 9 Dec 2002 11:02:19 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D1BF43ED4 for ; Mon, 9 Dec 2002 11:02:19 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id gB9J2Jx3087663 for ; Mon, 9 Dec 2002 11:02:19 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id gB9J2Iwb087657 for scsi@freebsd.org; Mon, 9 Dec 2002 11:02:18 -0800 (PST) Date: Mon, 9 Dec 2002 11:02:18 -0800 (PST) Message-Id: <200212091902.gB9J2Iwb087657@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: scsi@FreeBSD.org Subject: Current problem reports assigned to you Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2002/02/18] kern/35082 scsi IBM Intellistation will not reboot with S 1 problem total. Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [1999/12/21] kern/15608 scsi acd0 / cd0 give inconsistent errors on em 1 problem total. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 9 13:50:16 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 491EE37B404 for ; Mon, 9 Dec 2002 13:50:14 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id B221E43EC5 for ; Mon, 9 Dec 2002 13:50:13 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 25662 invoked by uid 1000); 9 Dec 2002 21:50:14 -0000 Date: Mon, 9 Dec 2002 13:50:14 -0800 (PST) From: Nate Lawson To: Yar Tikhiy Cc: "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG Subject: Re: {da,sa,...}open bug? In-Reply-To: <20021208170756.A75509@comp.chem.msu.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 8 Dec 2002, Yar Tikhiy wrote: > On Fri, Dec 06, 2002 at 12:34:01PM -0700, Kenneth D. Merry wrote: > > cam_periph_acquire() only returns an error when periph == NULL. If, for > > some wild reason, a locked periph manages to get freed (thus causing > > cam_periph_acquire() to return CAM_REQ_CMP_ERR), cam_periph_unlock() > > will panic (NULL pointer deference) when called with a NULL periph. > > First, I'd like to point out that freeing a periph doesn't cause a > pointer to it to become NULL. Therefore, cam_periph_unlock() is > extremely unlikely to panic since cam_periph_lock(), which in turn > calls cam_periph_acquire(), has been successful (i.e., periph != NULL) A little confusing here. What do you mean by "freeing a periph"? If you mean remove a reference to a periph, that's in cam_periph_release(). It is always an error to deref a periph pointer after cam_periph_release even though the poniter may still be valid (based on refcount). However, you are right in that if cam_periph_lock has succeeded, it is extremely unlikely a later cam_periph_acquire will fail. > My general impression is that that NULL check at the beginning of > cam_periph_acquire() is one of safety belts for unwary programmers > still left out there. I think it should be changed to something > like this: > > KASSERT(periph != NULL, ("cam_periph_acquire: null periph")); > > After this change, it will be OK to unlock a periph on cam_periph_acquire() > failure (granted someone have added code able to fail to the latter > function.) See Justin's email re: acquire first, lock second. In that case, acquire should continue to return an error since it is first in line in the *open function and ensures we have a referenced periph, allowing us to always back state out of that periph if things later fail. Also, I think the NULL check should be moved inside the splsoftcam to ensure exclusive access. In the future, we'll use mutex(9) for implementing lock and acquire. --- /sys/cam/cam_periph.c 14 Nov 2002 05:35:57 -0000 1.43 +++ /sys/cam/cam_periph.c 9 Dec 2002 21:38:02 -0000 @@ -262,15 +262,17 @@ cam_periph_acquire(struct cam_periph *periph) { int s; + cam_status status; - if (periph == NULL) - return(CAM_REQ_CMP_ERR); - + cam_status = CAM_REQ_CMP; s = splsoftcam(); - periph->refcount++; + if (periph != NULL) + periph->refcount++; + else + status = CAM_REQ_CMP_ERR; splx(s); - return(CAM_REQ_CMP); + return (status); } void If we reorder things according to Justin's suggestion, then we should do the obvious thing and always unroll state on all returns. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Dec 9 13:52:23 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0634D37B401 for ; Mon, 9 Dec 2002 13:52:23 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 3EC2043ED4 for ; Mon, 9 Dec 2002 13:52:22 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 25674 invoked by uid 1000); 9 Dec 2002 21:52:23 -0000 Date: Mon, 9 Dec 2002 13:52:23 -0800 (PST) From: Nate Lawson To: Yar Tikhiy Cc: freebsd-scsi@freebsd.org Subject: Re: {da,sa,...}open bug? In-Reply-To: <20021208182706.B75509@comp.chem.msu.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 8 Dec 2002, Yar Tikhiy wrote: > On Fri, Dec 06, 2002 at 11:23:56AM -0800, Nate Lawson wrote: > > You are correct. Ok to commit this w/ re@ approval The other periphs > > don't use this flag. > > While writing a message to re@, I thought if we were propagating > bad style with such patches. Wouldn't it be better to set the open > flag and acquire the periph if and only if returning success? The > open flag seems to be of no use before the return from daopen(). This patch is bad since you need to move the acquire earlier, not later. By moving it to the end, you increase the window where another proc could release the periph and free it. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 10 3:40:11 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9443537B401 for ; Tue, 10 Dec 2002 03:40:10 -0800 (PST) Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6580E43EC2 for ; Tue, 10 Dec 2002 03:40:06 -0800 (PST) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.3/8.12.3) with ESMTP id gBABdwm2019975; Tue, 10 Dec 2002 14:39:58 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.3/8.12.3/Submit) id gBABdsio019974; Tue, 10 Dec 2002 14:39:54 +0300 (MSK) Date: Tue, 10 Dec 2002 14:39:54 +0300 From: Yar Tikhiy To: Nate Lawson Cc: freebsd-scsi@freebsd.org Subject: Re: {da,sa,...}open bug? Message-ID: <20021210143954.B14989@comp.chem.msu.su> References: <20021208182706.B75509@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nate@root.org on Mon, Dec 09, 2002 at 01:52:23PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Dec 09, 2002 at 01:52:23PM -0800, Nate Lawson wrote: > On Sun, 8 Dec 2002, Yar Tikhiy wrote: > > On Fri, Dec 06, 2002 at 11:23:56AM -0800, Nate Lawson wrote: > > > You are correct. Ok to commit this w/ re@ approval The other periphs > > > don't use this flag. > > > > While writing a message to re@, I thought if we were propagating > > bad style with such patches. Wouldn't it be better to set the open > > flag and acquire the periph if and only if returning success? The > > open flag seems to be of no use before the return from daopen(). > > This patch is bad since you need to move the acquire earlier, not > later. By moving it to the end, you increase the window where another > proc could release the periph and free it. Why, is the knowledge that cam_periph_lock() calls cam_periph_acquire() first of all considered secret? :-) The idea behind my patch was as follows: having called cam_periph_lock() ensures the periph won't disappear while it's being opened; and if the open succeeds, another reference to the periph is obtained so it won't go away until it's closed, and the former reference is released, which is one of cam_periph_unlock() effects. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 10 6:15:46 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2904F37B404 for ; Tue, 10 Dec 2002 06:15:44 -0800 (PST) Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id A453643EA9 for ; Tue, 10 Dec 2002 06:15:38 -0800 (PST) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.3/8.12.3) with ESMTP id gBAEFTm2029093; Tue, 10 Dec 2002 17:15:29 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.3/8.12.3/Submit) id gBAEFSr0029092; Tue, 10 Dec 2002 17:15:28 +0300 (MSK) Date: Tue, 10 Dec 2002 17:15:28 +0300 From: Yar Tikhiy To: Nate Lawson Cc: "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG Subject: Re: {da,sa,...}open bug? Message-ID: <20021210171528.B27181@comp.chem.msu.su> References: <20021208170756.A75509@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nate@root.org on Mon, Dec 09, 2002 at 01:50:14PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Dec 09, 2002 at 01:50:14PM -0800, Nate Lawson wrote: > On Sun, 8 Dec 2002, Yar Tikhiy wrote: > > On Fri, Dec 06, 2002 at 12:34:01PM -0700, Kenneth D. Merry wrote: > > > cam_periph_acquire() only returns an error when periph == NULL. If, for > > > some wild reason, a locked periph manages to get freed (thus causing > > > cam_periph_acquire() to return CAM_REQ_CMP_ERR), cam_periph_unlock() > > > will panic (NULL pointer deference) when called with a NULL periph. > > > > First, I'd like to point out that freeing a periph doesn't cause a > > pointer to it to become NULL. Therefore, cam_periph_unlock() is > > extremely unlikely to panic since cam_periph_lock(), which in turn > > calls cam_periph_acquire(), has been successful (i.e., periph != NULL) > > A little confusing here. What do you mean by "freeing a periph"? If you > mean remove a reference to a periph, that's in cam_periph_release(). It > is always an error to deref a periph pointer after cam_periph_release even > though the poniter may still be valid (based on refcount). I mean that if two program parts hold pointers to the same structure and one of the parts free()'s the structure, the second part won't have its pointer set to NULL automagically :-) That is, we don't need to worry whether the "periph" argument is NULL after we have reached behind cam_periph_lock() even if some bogus piece of code would rip the actual periph from under us. > > My general impression is that that NULL check at the beginning of > > cam_periph_acquire() is one of safety belts for unwary programmers > > still left out there. I think it should be changed to something > > like this: > > > > KASSERT(periph != NULL, ("cam_periph_acquire: null periph")); > > > > After this change, it will be OK to unlock a periph on cam_periph_acquire() > > failure (granted someone have added code able to fail to the latter > > function.) > > See Justin's email re: acquire first, lock second. In that case, acquire > should continue to return an error since it is first in line in the *open > function and ensures we have a referenced periph, allowing us to always > back state out of that periph if things later fail. Also, I think the Justin's point sounds reasonable indeed. If a piece of code were to do something with periph after cam_periph_lock() had failed on it, the code should use this order. On the other hand, it's a bad thing to do anything with unlocked periph's internal data. > NULL check should be moved inside the splsoftcam to ensure exclusive > access. In the future, we'll use mutex(9) for implementing lock and > acquire. > > --- /sys/cam/cam_periph.c 14 Nov 2002 05:35:57 -0000 1.43 > +++ /sys/cam/cam_periph.c 9 Dec 2002 21:38:02 -0000 > @@ -262,15 +262,17 @@ > cam_periph_acquire(struct cam_periph *periph) > { > int s; > + cam_status status; > > - if (periph == NULL) > - return(CAM_REQ_CMP_ERR); > - > + cam_status = CAM_REQ_CMP; > s = splsoftcam(); > - periph->refcount++; > + if (periph != NULL) > + periph->refcount++; > + else > + status = CAM_REQ_CMP_ERR; > splx(s); > > - return(CAM_REQ_CMP); > + return (status); > } > > void > > If we reorder things according to Justin's suggestion, then we should do > the obvious thing and always unroll state on all returns. Excuse me, but I see little reason in this patch. "periph" is a function argument, so its value cannot be changed anywhere else, so there is no need for splsoftcam() before the NULL check. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 10 6:33:31 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 606A037B401 for ; Tue, 10 Dec 2002 06:33:29 -0800 (PST) Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23BB643E4A for ; Tue, 10 Dec 2002 06:33:28 -0800 (PST) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.3/8.12.3) with ESMTP id gBAEXOm2030074; Tue, 10 Dec 2002 17:33:24 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.3/8.12.3/Submit) id gBAEXNfd030073; Tue, 10 Dec 2002 17:33:23 +0300 (MSK) Date: Tue, 10 Dec 2002 17:33:23 +0300 From: Yar Tikhiy To: "Justin T. Gibbs" Cc: "Kenneth D. Merry" , Nate Lawson , freebsd-scsi@FreeBSD.ORG Subject: Re: {da,sa,...}open bug? Message-ID: <20021210173322.C27181@comp.chem.msu.su> References: <20021206145942.I80257@comp.chem.msu.su> <20021206123401.A23249@panzer.kdm.org> <2179138112.1039414275@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2179138112.1039414275@aslan.scsiguy.com>; from gibbs@scsiguy.com on Sun, Dec 08, 2002 at 11:11:15PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Dec 08, 2002 at 11:11:15PM -0700, Justin T. Gibbs wrote: > > Yar asked me to review his previous patch to a number of peripheral > > drivers that modifed the acquire/unlock/etc. order. I've asked Justin to > > take a look at it as well (thus the reason I haven't completed the review > > yet), ... > > The patches look okay to me. Although the lock API was never fully > implemented, it was indended to guarantee exclusive access to an underlying > device while the lock is held. This is exactly what you might want during > a device driver probe where multiple device drivers can attach > simultaneously > to the same device (e.g. pass and da both attach to direct access devices). > If we were to follow the indended use of the API, the probe code would > probably look like this: > > /* > * Ensure periph is not de-allocated > * out from under us. > */ > cam_periph_acquire(); > > /* > * Gain exclusive access to the periph. > */ > cam_periph_lock(); > > /* > * Perform probe. > */ > > /* > * Play nice with others. > */ > cam_periph_unlock(); > > return (0); > > with the appropriate release's and unlocks in the error cases of course. > The lock and unlock calls would also be used in open during any device > validation checks that require exclusive access. Do you imply that the feature that cam_periph_lock() calls cam_periph_acquire() should not be relied upon? If it could be, the driver could call cam_periph_lock() first, thus both locking the device and ensuring its persistence, and invoke cam_periph_acquire() then, only if long-term access to the device is necessary (e.g., a device open routine would acquire the device until it's closed.) -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 10 13:20:42 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D665A37B404 for ; Tue, 10 Dec 2002 13:20:40 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 4026543EDA for ; Tue, 10 Dec 2002 13:20:40 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 28470 invoked by uid 1000); 10 Dec 2002 21:20:41 -0000 Date: Tue, 10 Dec 2002 13:20:41 -0800 (PST) From: Nate Lawson To: Yar Tikhiy Cc: "Justin T. Gibbs" , "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG Subject: Re: {da,sa,...}open bug? In-Reply-To: <20021210173322.C27181@comp.chem.msu.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 10 Dec 2002, Yar Tikhiy wrote: > On Sun, Dec 08, 2002 at 11:11:15PM -0700, Justin T. Gibbs wrote: > > If we were to follow the indended use of the API, the probe code would > > probably look like this: > > > > /* > > * Ensure periph is not de-allocated > > * out from under us. > > */ > > cam_periph_acquire(); > > > > /* > > * Gain exclusive access to the periph. > > */ > > cam_periph_lock(); > > Do you imply that the feature that cam_periph_lock() calls > cam_periph_acquire() should not be relied upon? If it could be, > the driver could call cam_periph_lock() first, thus both locking > the device and ensuring its persistence, and invoke cam_periph_acquire() > then, only if long-term access to the device is necessary (e.g., a > device open routine would acquire the device until it's closed.) The two have different purposes: acquire -- atomically increase refcount so periph is guaranteed to not disappear under us lock -- ensure exclusive access to a periph The fact that lock calls acquire is just to keep the periph from disappearing while sleeping. If a periph is locked already, lock sleeps and depends on a wakeup from the proc that holds the lock calling unlock. If you look at unlock, it decrements the refcount using release and thus calling lock does NOT increase the refcount overall. You still need to call acquire separately. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 10 13:24: 0 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 603C837B401 for ; Tue, 10 Dec 2002 13:23:59 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 8C7A743E4A for ; Tue, 10 Dec 2002 13:23:58 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 28483 invoked by uid 1000); 10 Dec 2002 21:23:59 -0000 Date: Tue, 10 Dec 2002 13:23:59 -0800 (PST) From: Nate Lawson To: Yar Tikhiy Cc: freebsd-scsi@freebsd.org Subject: Re: {da,sa,...}open bug? In-Reply-To: <20021210143954.B14989@comp.chem.msu.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 10 Dec 2002, Yar Tikhiy wrote: > On Mon, Dec 09, 2002 at 01:52:23PM -0800, Nate Lawson wrote: > > This patch is bad since you need to move the acquire earlier, not > > later. By moving it to the end, you increase the window where another > > proc could release the periph and free it. > > Why, is the knowledge that cam_periph_lock() calls cam_periph_acquire() > first of all considered secret? :-) The idea behind my patch was > as follows: having called cam_periph_lock() ensures the periph won't > disappear while it's being opened; and if the open succeeds, another > reference to the periph is obtained so it won't go away until it's > closed, and the former reference is released, which is one of > cam_periph_unlock() effects. Here is what would happen with your patch: open() 1. lock -- refcount +1, get lock, refcount -1 2. [open code runs] 3. acquire -- refcount +1 All throughout step 2, periph could disappear if another proc calls release. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 10 13:29:56 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA11B37B401 for ; Tue, 10 Dec 2002 13:29:54 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 351C243EC2 for ; Tue, 10 Dec 2002 13:29:54 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 28515 invoked by uid 1000); 10 Dec 2002 21:29:55 -0000 Date: Tue, 10 Dec 2002 13:29:55 -0800 (PST) From: Nate Lawson To: Yar Tikhiy Cc: "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG Subject: Re: {da,sa,...}open bug? In-Reply-To: <20021210171528.B27181@comp.chem.msu.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 10 Dec 2002, Yar Tikhiy wrote: > On Mon, Dec 09, 2002 at 01:50:14PM -0800, Nate Lawson wrote: > > NULL check should be moved inside the splsoftcam to ensure exclusive > > access. In the future, we'll use mutex(9) for implementing lock and > > acquire. > > > > --- /sys/cam/cam_periph.c 14 Nov 2002 05:35:57 -0000 1.43 > > +++ /sys/cam/cam_periph.c 9 Dec 2002 21:38:02 -0000 > > @@ -262,15 +262,17 @@ > > cam_periph_acquire(struct cam_periph *periph) > > { > > int s; > > + cam_status status; > > > > - if (periph == NULL) > > - return(CAM_REQ_CMP_ERR); > > - > > + cam_status = CAM_REQ_CMP; > > s = splsoftcam(); > > - periph->refcount++; > > + if (periph != NULL) > > + periph->refcount++; > > + else > > + status = CAM_REQ_CMP_ERR; > > splx(s); > > > > - return(CAM_REQ_CMP); > > + return (status); > > } > > > > void > > Excuse me, but I see little reason in this patch. "periph" is a > function argument, so its value cannot be changed anywhere else, > so there is no need for splsoftcam() before the NULL check. I guess this makes sense since it's too late by the point where *periph has been pushed on the stack and acquire called. My concern was the (very small) possibility that between the NULL check and refcount++, an interrupt could happen and free the periph. But my patch does not fix this, as you point out. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 10 18:12:25 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FA1B37B401 for ; Tue, 10 Dec 2002 18:12:24 -0800 (PST) Received: from msgbas1x.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id C044443EC2 for ; Tue, 10 Dec 2002 18:12:23 -0800 (PST) (envelope-from yiding_wang@agilent.com) Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 6C724ED23 for ; Tue, 10 Dec 2002 19:12:18 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by relcos2.cos.agilent.com (Postfix) with SMTP id 2C90B18 for ; Tue, 10 Dec 2002 19:12:18 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 10 Dec 2002 19:12:17 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 19:12:17 -0700 Message-ID: <334DD5C2ADAB9245B60F213F49C5EBCD05D54F20@axcs03.cos.agilent.com> From: yiding_wang@agilent.com To: freebsd-scsi@freebsd.org Subject: Question on memory allocation Date: Tue, 10 Dec 2002 19:12:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello Team, I have some questions about memory allocation in FreeBSD device driver. I couldn't find answer either from man page or docs. 1, For the function malloc(), what does M_DEVBUF flag represent? 2, What is the syntax and argument for malloc() to allocate N byte of memory with M alignment requirement? 3, Can malloc be used for physical contiguous memory allocation? If so, what is the syntax and argument? 4, If bus_dmamem_alloc() is the one for physical contiguous memory allocation, then what is the syntax and argument? for getting alig 5, Is there any memory size limitation from both memory allocation function? Any direction to source documents regarding these memory allocation function and vtop / ptov function pair are welcomes! Many thanks! Eddie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Dec 10 22: 9: 7 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 417D737B401 for ; Tue, 10 Dec 2002 22:09:06 -0800 (PST) Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97E7B43EA9 for ; Tue, 10 Dec 2002 22:09:05 -0800 (PST) (envelope-from scottl@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6+Sun/8.11.6) with ESMTP id gBB694j05680; Tue, 10 Dec 2002 22:09:04 -0800 (PST) Received: from btc.btc.adaptec.com (btc.btc.adaptec.com [10.100.0.52]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id WAA18810; Tue, 10 Dec 2002 22:08:53 -0800 (PST) Received: from hollin.btc.adaptec.com (hollin [10.100.253.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id XAA22808; Tue, 10 Dec 2002 23:08:49 -0700 (MST) Received: from hollin.btc.adaptec.com (localhost [127.0.0.1]) by hollin.btc.adaptec.com (8.12.6/8.12.5) with ESMTP id gBB65jkY013268; Tue, 10 Dec 2002 23:05:45 -0700 (MST) (envelope-from scottl@hollin.btc.adaptec.com) Received: (from scottl@localhost) by hollin.btc.adaptec.com (8.12.6/8.12.5/Submit) id gBB65jUQ013267; Tue, 10 Dec 2002 23:05:45 -0700 (MST) Date: Tue, 10 Dec 2002 23:05:45 -0700 From: Scott Long To: yiding_wang@agilent.com Cc: freebsd-scsi@freebsd.org Subject: Re: Question on memory allocation Message-ID: <20021211060544.GA12582@hollin.btc.adaptec.com> References: <334DD5C2ADAB9245B60F213F49C5EBCD05D54F20@axcs03.cos.agilent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <334DD5C2ADAB9245B60F213F49C5EBCD05D54F20@axcs03.cos.agilent.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I assume that you're trying to allocate memory that will be shared with the hardware, yes? If so, then you need to use the 'busdma' interface. Unfortunately, it isn't well documented. The only real reference is the source code and other drivers. Anyways, see below: On Tue, Dec 10, 2002 at 07:12:16PM -0700, yiding_wang@agilent.com wrote: > Hello Team, > > I have some questions about memory allocation in FreeBSD device driver. I couldn't find answer either from man page or docs. > > 1, For the function malloc(), what does M_DEVBUF flag represent? malloc requires a cookie that it uses for memory profiling and debugging. You can create you own cookie with MALLOC_DEFINE() > 2, What is the syntax and argument for malloc() to allocate N byte of memory with M alignment requirement? malloc cannot guarantee memory alignment. You need to create a busdma tag via bus_dma_tag_create() in order to specify things like alignment and boundary restricts. YOu then use this tag with bus_dmamem_alloc() to allocate memory with those restrictions. > 3, Can malloc be used for physical contiguous memory allocation? If so, what is the syntax and argument? malloc does not guarantee physcially contiguous allocations. contigmalloc() does. Once again, for the purpose that I think you are going for, busdma is the correct API to use. > 4, If bus_dmamem_alloc() is the one for physical contiguous memory allocation, then what is the syntax and argument? for getting alig Look at other drivers for the answer to this. For what you intend to do, this is the correct way to allocate memory. > 5, Is there any memory size limitation from both memory allocation function? Kind of. The memory allocation routines don't currently try to coalesce and merge free space, so your physical memory map can get quite fragmented over time. This isn't a big problem during boot, but can be one is your driver is loaded as a module after the system has been up for a while. Avoid allocating large slabs of physical memory. > > Any direction to source documents regarding these memory allocation function and vtop / ptov function pair are welcomes! > > Many thanks! > > Eddie > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Dec 11 13:39:41 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B014437B401 for ; Wed, 11 Dec 2002 13:39:40 -0800 (PST) Received: from webspacesolutions.com (ns.webspacesolutions.com [64.29.20.190]) by mx1.FreeBSD.org (Postfix) with SMTP id 21DA543E4A for ; Wed, 11 Dec 2002 13:39:40 -0800 (PST) (envelope-from ntwaddel@webspacesolutions.com) Received: (qmail 25599 invoked from network); 11 Dec 2002 21:39:28 -0000 Received: from 24-205-226-59.ata-cres.charterpipeline.net (HELO beastie) (24.205.226.59) by webspacesolutions.com with SMTP; 11 Dec 2002 21:39:28 -0000 From: "Nick Twaddell" To: Subject: Ibm 4Lx Raid Drivers attn: scott long Date: Wed, 11 Dec 2002 13:39:30 -0800 Organization: WebSpaceSolutions Message-ID: <000e01c2a15d$c9d4eb80$0700a8c0@beastie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Any idea when the drivers will be put into the -current snapshot? Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Dec 12 10:57: 9 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46CA837B401 for ; Thu, 12 Dec 2002 10:57:08 -0800 (PST) Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98E1943ED4 for ; Thu, 12 Dec 2002 10:57:06 -0800 (PST) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.3/8.12.3) with ESMTP id gBCIv0m2094362; Thu, 12 Dec 2002 21:57:00 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.3/8.12.3/Submit) id gBCIuu1r094361; Thu, 12 Dec 2002 21:56:56 +0300 (MSK) Date: Thu, 12 Dec 2002 21:56:56 +0300 From: Yar Tikhiy To: Nate Lawson Cc: freebsd-scsi@freebsd.org Subject: Re: {da,sa,...}open bug? Message-ID: <20021212215655.A92315@comp.chem.msu.su> References: <20021210143954.B14989@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nate@root.org on Tue, Dec 10, 2002 at 01:23:59PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Dec 10, 2002 at 01:23:59PM -0800, Nate Lawson wrote: > On Tue, 10 Dec 2002, Yar Tikhiy wrote: > > On Mon, Dec 09, 2002 at 01:52:23PM -0800, Nate Lawson wrote: > > > This patch is bad since you need to move the acquire earlier, not > > > later. By moving it to the end, you increase the window where another > > > proc could release the periph and free it. > > > > Why, is the knowledge that cam_periph_lock() calls cam_periph_acquire() > > first of all considered secret? :-) The idea behind my patch was > > as follows: having called cam_periph_lock() ensures the periph won't > > disappear while it's being opened; and if the open succeeds, another > > reference to the periph is obtained so it won't go away until it's > > closed, and the former reference is released, which is one of > > cam_periph_unlock() effects. > > Here is what would happen with your patch: > > open() > 1. lock -- refcount +1, get lock, refcount -1 > 2. [open code runs] > 3. acquire -- refcount +1 > > All throughout step 2, periph could disappear if another proc calls > release. I see your point, but your scenario isn't exactly what would happen, to my mind. If periph weren't currently locked, the refcount would change as follows: 1. lock -- refcount +1, get lock 2. [open code runs], refcount >0 3. acquire -- refcount +1 4. unlock -- refcount -1 If periph were already locked by another thread, the following would happen: 1a. lock -- on entry refcount is already >0 since the other thread has called cam_periph_lock() and thus incremented refcount 1b. refcount gets +1 and becomes >=2 1c. this thread sleeps until the other unlocks periph, where refcount gets -1, but stays >0 since it was >1 before the decrement 1d. get lock 2. [open code runs], refcount > 0 3. acquire -- refcount gets +1 and becomes >1 4. unlock -- refcount gets -1, yet stays >0 As you may see, even if cam_periph_acquire() were called lately, right before cam_periph_unlock(), refcount would never drop below 1. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 13 4:16:44 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E377937B401 for ; Fri, 13 Dec 2002 04:16:43 -0800 (PST) Received: from chuggalug.clues.com (chuggalug.clues.com [194.159.1.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06D2743ED4 for ; Fri, 13 Dec 2002 04:16:43 -0800 (PST) (envelope-from geoffb@chuggalug.clues.com) Received: from chuggalug.clues.com (localhost [127.0.0.1]) by chuggalug.clues.com (8.12.6/8.9.3) with ESMTP id gBDChjAR005054 for ; Fri, 13 Dec 2002 12:43:45 GMT (envelope-from geoffb@chuggalug.clues.com) Received: (from geoffb@localhost) by chuggalug.clues.com (8.12.6/8.12.6/Submit) id gBDChj75005053 for freebsd-scsi@freebsd.org; Fri, 13 Dec 2002 12:43:45 GMT Date: Fri, 13 Dec 2002 12:43:45 +0000 From: Geoff Buckingham To: freebsd-scsi@freebsd.org Subject: ciss management tools? Message-ID: <20021213124345.A5030@chuggalug.clues.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org After having a poke around on this list, I am fairly confident that there are no managment tools for the ciss device available under FreeBSD. Is this correct? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 13 7:35:19 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B15B737B401 for ; Fri, 13 Dec 2002 07:35:18 -0800 (PST) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50AC843EB2 for ; Fri, 13 Dec 2002 07:35:16 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.6/8.12.6) with ESMTP id gBDFZCAt030072; Fri, 13 Dec 2002 16:35:12 +0100 (CET) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.6/8.12.6/Submit) id gBDFZCST030071; Fri, 13 Dec 2002 16:35:12 +0100 (CET) Date: Fri, 13 Dec 2002 16:35:12 +0100 From: Wilko Bulte To: Geoff Buckingham Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: ciss management tools? Message-ID: <20021213163512.A30037@freebie.xs4all.nl> References: <20021213124345.A5030@chuggalug.clues.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021213124345.A5030@chuggalug.clues.com>; from geoffb@chuggalug.clues.com on Fri, Dec 13, 2002 at 12:43:45PM +0000 X-OS: FreeBSD 4.7-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Dec 13, 2002 at 12:43:45PM +0000, Geoff Buckingham wrote: Compaq/HP considers the mgmt interface proprietary. W/ > After having a poke around on this list, I am fairly confident that there > are no managment tools for the ciss device available under FreeBSD. > Is this correct? > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message ---end of quoted text--- -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 13 9:14:26 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68A4237B401 for ; Fri, 13 Dec 2002 09:14:25 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EB0843EB2 for ; Fri, 13 Dec 2002 09:14:25 -0800 (PST) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 0DF11AE1C1; Fri, 13 Dec 2002 09:14:25 -0800 (PST) Date: Fri, 13 Dec 2002 09:14:25 -0800 From: Paul Saab To: Geoff Buckingham Cc: freebsd-scsi@freebsd.org Subject: Re: ciss management tools? Message-ID: <20021213171425.GA33318@elvis.mu.org> References: <20021213124345.A5030@chuggalug.clues.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021213124345.A5030@chuggalug.clues.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Geoff Buckingham (geoffb@chuggalug.clues.com) wrote: > > After having a poke around on this list, I am fairly confident that there > are no managment tools for the ciss device available under FreeBSD. > Is this correct? Some stuff may be coming, but all the info to get status of the raid is available at http://sourceforge.net/projects/cciss/. You can write your own if you would like. HP is working out a way to let me release some of the stuff, but right now I cannot do anything. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Dec 13 10:54:47 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9D6237B404 for ; Fri, 13 Dec 2002 10:54:45 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 50A9943ED8 for ; Fri, 13 Dec 2002 10:54:45 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 36801 invoked by uid 1000); 13 Dec 2002 18:54:46 -0000 Date: Fri, 13 Dec 2002 10:54:45 -0800 (PST) From: Nate Lawson To: Yar Tikhiy Cc: freebsd-scsi@freebsd.org Subject: Re: {da,sa,...}open bug? In-Reply-To: <20021212215655.A92315@comp.chem.msu.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 12 Dec 2002, Yar Tikhiy wrote: > On Tue, Dec 10, 2002 at 01:23:59PM -0800, Nate Lawson wrote: > > Here is what would happen with your patch: > > > > open() > > 1. lock -- refcount +1, get lock, refcount -1 > > 2. [open code runs] > > 3. acquire -- refcount +1 > > > > All throughout step 2, periph could disappear if another proc calls > > release. > > I see your point, but your scenario isn't exactly what would happen, to my mind. > If periph weren't currently locked, the refcount would change as follows: > 1. lock -- refcount +1, get lock > 2. [open code runs], refcount >0 > 3. acquire -- refcount +1 > 4. unlock -- refcount -1 > > As you may see, even if cam_periph_acquire() were called lately, > right before cam_periph_unlock(), refcount would never drop below 1. Yes, you are correct. I am still uncomfortable with moving acquire() to the end, depending on the side effect of it staying inside a lock/unlock scope. We may want to push down the locks later to only encapsulate a small portion of shared access routines and that would change this assumption. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message