linux-kernel - Re: [PATCH] Open Firmware device tree virtual filesystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070102.203417.102576086.davem@davemloft.net>
Date:	Tue, 02 Jan 2007 20:34:17 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	segher@...nel.crashing.org
Cc:	linux-kernel@...r.kernel.org, devel@...top.org, dmk@...x.com,
	benh@...nel.crashing.org, wmb@...mworks.com, jg@...top.org
Subject: Re: [PATCH] Open Firmware device tree virtual filesystem

From: Segher Boessenkool <segher@...nel.crashing.org>
Date: Wed, 3 Jan 2007 01:48:02 +0100

> > therefore you can't let multiple CPUs call
> > into OFW at one time.  You must use some kind of locking mechanism,
> > and that locking mechanism is not simple because it has to not just
> > stop the other cpus, it has to be able to stop the other cpus yet
> > still allow them to receive SMP cross-calls from the firmware if the
> > OFW call is 'stop' or similar.
> 
> YOu don't need to *stop* the other CPUs, you just need to
> prevent them from entering the client interface.  Put a lock
> in front.

That's not the issue.

If the global OFW lock disables interrupts, other cpus trying to get
that lock can't receive CPU cross calls since they are delivered via
interrupts, get it?  That's the issue you need to be careful about.

> > Please let's get over this memory consumption non-issue and move
> > on to more productive talk.
> 
> Okay -- so answer the second part of my concern please: if you keep
> a copy, you need to keep both in sync -- that means every change
> by the kernel has to be done twice, and you won't ever be told about
> changes by the OF, so you have to get a full fresh copy every single
> time you return from an OF client call that could have changed a
> property.

Sure, you need to call OFW when a property is changed, and we have
code to handle that perfectly fine in the sparc of_*() code.

There are mechanisms on the OFW implementations that do hot plugging
to learn about the OFW tree changes.  On some sparc64 platforms,
for example, you have to do a "SUNW,foo-operation" OFW call when a
board is hot-plugged in an Ex000 enterprise box, and after that call
finishes successfully, you know where the new board is in the OFW
tree so you import everything underneath.  You do the opposite for
a hot-unplug sequence.

Every platform is going to handle this differently.

But there is nothing about it that precludes doing an in-kernel
OFW tree.

Even the most brute-force implementation is possible.  When any
hot-plug event occurs, validate the current in-kernel tree.  It's that
easy.

I guess it's good to have someone like you, the dissenter in the
group, but Ben and I will snuff you out completely soon enough :-)))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/