Date: Tue, 27 Jan 2015 21:04:34 +0000 (UTC) From: LinkedIn Security <security-noreply@linkedin.com> To: Sairam Chengala <freebsd-arch@FreeBSD.org> Subject: Sairam, your password was successfully reset Message-ID: <1748019091.10903717.1422392674491.JavaMail.app@lva1-app8991.prod>
next in thread | raw e-mail | index | archive | help
Hi Sairam, You've successfully changed your LinkedIn password. Thanks for using LinkedIn! The LinkedIn Team When and where this happened: Date:January 27, 2015 4:04 PM Browser:Chrome Operating System:OS X IP Address:96.240.100.124 Approximate Location:Hoboken, New Jersey, United States Didn't do this? Be sure to change your password right away: https://www.lin= kedin.com/e/v2?e=3Di9hmy-i5frvfnl-4h&a=3Duas-request-password-reset&midToke= n=3DAQFN2Z6JzeYPdA&ek=3Dsecurity_reset_password_notification From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 22:46:03 2015 Return-Path: <owner-freebsd-arch@FreeBSD.ORG> Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEF6428A for <arch@freebsd.org>; Wed, 28 Jan 2015 22:46:03 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7BDB2DEC for <arch@freebsd.org>; Wed, 28 Jan 2015 22:46:03 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 694FDB926; Wed, 28 Jan 2015 17:46:01 -0500 (EST) From: John Baldwin <jhb@freebsd.org> To: Warner Losh <imp@bsdimp.com> Subject: Re: devctl(8): A device control utility Date: Wed, 28 Jan 2015 17:45:25 -0500 Message-ID: <17592052.bbsckK6u9F@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <E3CAE124-1D8E-4A89-8113-D8301436BFE9@bsdimp.com> References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54B44448.1090901@FreeBSD.org> <E3CAE124-1D8E-4A89-8113-D8301436BFE9@bsdimp.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 28 Jan 2015 17:46:01 -0500 (EST) Cc: Hans Petter Selasky <hps@selasky.org>, arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>; List-Post: <mailto:freebsd-arch@freebsd.org> List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 28 Jan 2015 22:46:03 -0000 On Wednesday, January 14, 2015 04:56:18 PM Warner Losh wrote: > > On Jan 12, 2015, at 3:01 PM, John Baldwin <jhb@FreeBSD.org> wrote: > >=20 > > On 1/12/15 12:01 PM, Warner Losh wrote: > >>> On Jan 12, 2015, at 9:16 AM, John Baldwin <jhb@FreeBSD.org> wrote= : > >>>=20 > >>> On 1/5/15 4:18 PM, John Baldwin wrote: > >>>> On Monday, January 05, 2015 09:58:19 PM Hans Petter Selasky wrot= e: > >>>>> On 01/05/15 21:37, John Baldwin wrote: > >>>>>> On 1/5/15 3:13 PM, Hans Petter Selasky wrote: > >>>>>>> On 01/05/15 21:01, John Baldwin wrote: > >>>>>>>> The devctl(8) utility is then a thin wrapper around libdevct= l (and > >>>>>>>> does not > >>>>>>>> yet have a manpage). > >>>>>>>>=20 > >>>>>>>> Do folks have any feedback? > >>>>>>>=20 > >>>>>>> Hi, > >>>>>>>=20 > >>>>>>> In the USB area attach and detach must be synchronized to the= USB > >>>>>>> stack > >>>>>>> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y rese= t" > >>>>>>> should > >>>>>>> be used to avoid races attaching and detaching drivers! > >>>>>>=20 > >>>>>> I think this points to one or more missing bus methods so that= the > >>>>>> bus > >>>>>> can hook into device_probe_and_attach() to reset a device as n= eeded. > >>>>>> (e.g. if you had bus_probe_started / bus_probe_finished and po= ssibly > >>>>>> similar methods for attach. PCI could use a bus_attach_finish= ed() > >>>>>> callback so that it could clean up any dangling resources and > >>>>>> possibly > >>>>>> power down on a failed attach the way it does in bus_child_det= ached > >>>>>> as > >>>>>> well). > >>>>>=20 > >>>>> Hi, > >>>>>=20 > >>>>> USB has its own threads to allocate/free devices. Another probl= em is > >>>>> how > >>>>> to atomically get a reference count across multiple layers like= PCI > >>>>> and > >>>>> USB. It doesn't allow probe/attach when called from outside the= se > >>>>> threads. > >>>>=20 > >>>> That just means you need to use some locks. :) Cardbus also use= s an > >>>> event > >>>> thread to handle auto-attach of devices when it detected a card = change > >>>> event, but that doesn't prevent it from servicing an ioctl reque= st. > >>>=20 > >>> Another option btw would be to add bus methods that wrap probe an= d > >>> attach (rather than pre and post event hooks). I wish bus_add_ch= ild() > >>> were done this way such that device_add_child_ordered() were rena= med to > >>> bus_generic_add_child() (and was the default add_child method) an= d that > >>> device_add_child_ordered() called 'BUS_ADD_CHILD()' so that > >>> 'device_add_child()' was the proper public API (instead of exposi= ng > >>> BUS_ADD_CHILD()). Similarly, I think that 'device_attach()' and > >>> 'device_probe_and_attach()' should be the public API and that one= way or > >>> another we should add hooks to allow bus drivers to modify their > >>> behavior if needed. However, they should be fine for devctl ioct= ls to > >>> invoke as well as other kernel bits. > >>=20 > >> When I was doing CardBus and PC Card I wished for similar things. = Then > >> I realized I didn=E2=80=99t need them because as the bus author, I= know when > >> these > >> events happened and could take appropriate actions for the bus. I = didn=E2=80=99t > >> have that atomic access issues though, since as the bus author I a= lso > >> controlled how and when mutexes were taken out and when I allowed = access > >> to the bus. I only used mutexes in CardBus and PC Card because mos= t of > >> the sleeps were short, but other ways to do locking are quite > >> possible... > >=20 > > I think the problem here is that devctl introduces events that happ= en > > without the bus's knowledge. >=20 > When we did the kludge sysctl power stuff for cardbus (which was neve= r > committed), we sent a message to the bus to tell it to do the power o= ff and > cope with whatever else was needed. There were times that it couldn=E2= =80=99t > comply, iirc, so this =E2=80=98command=E2=80=99 allowed errors to be = returned for things > that were forbidden / not allowed for some reason at the time rather = than > getting a message that this thing happened and we had to mop up now. devctl requests would always be ones that you can gracefully fail (they= are administrative requests, not a surprise hardware removal). I think we = should able to make that work just fine either by wrapping device_attach, etc.= in new bus methods, or adding hooks into those as bus methods. To that end, I= 'd like to move forward with this current version in HEAD. At some point we ca= n=20 decide which way we want to allow bus drivers to hook into these reques= ts. I=20 don't think that will affect the API exposed to userland at all however= , only=20 the in-kernel implementation. --=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1748019091.10903717.1422392674491.JavaMail.app>