Skip site navigation (1)Skip section navigation (2)
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&#39;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>