Date: Sat, 1 Aug 2009 14:12:01 +0200 From: Attilio Rao <attilio@freebsd.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Peter Holm <pho@freebsd.org>, Giovanni Trematerra <giovanni.trematerra@gmail.com>, freebsd-current@freebsd.org Subject: Re: [PATCH] Newbus locking Message-ID: <3bbf2fe10908010512j6aa02d9bk7a99f0f31ae313b2@mail.gmail.com> In-Reply-To: <200908010630.21366.hselasky@c2i.net> References: <3bbf2fe10907310759o3be1f565t4122fcd66c4531f4@mail.gmail.com> <200907311919.26913.hselasky@c2i.net> <4e6cba830907311917j5d3c0eb6u7f7b1099d3acd504@mail.gmail.com> <200908010630.21366.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/8/1 Hans Petter Selasky <hselasky@c2i.net>: > > Attilio: Your newbus_lock() must be moved into usb_probe_and_attach(), and > maybe in usb_suspend_resume(). newbus_lock() should be locked always after > "udev->default_sx + 1" in usb_device.c. "udev->default_sx + 1" is the lock > protecting enumeration on a per-device level. Try on a usb device: > > usbconfig -u XXX -a YYY set_config 255 > > Then: > > usbconfig -u XXX -a YYY set_config 0 > > And I think you will have a prompt panic, because the newbus lock is not > locked. Nice catch, pho just reported that to me. I'm going to fix it now. Thanks. > BTW: Why do none of the device_get_xxx() functions not have newbus lock > assertions in them? Because not all the device_get_ functions need to be locked. Generally the context alredy provide correct locking for them. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10908010512j6aa02d9bk7a99f0f31ae313b2>