headers
Ram Pai | 1 Nov 2005 01:01
Picon
Favicon

Re: /etc/mtab and per-process namespaces

On Mon, 2005-10-31 at 15:27, Rob Landley wrote:
> On Monday 31 October 2005 13:11, Ram Pai wrote:
> > > The big thing I've never figured out how to do is make umount -a work in
> > > the presence of multiple namespaces.  (Should it just umount what it
> > > sees?  I don't know how to umount everything because I can't find
> > > everything...)
> >
> > Yes you won't find everything, since some of them are in a different
> > namespaces. Instead unmount whatever you see.  Or use /proc/mounts
> > to unmount whatever is there in its namespace.
> 
> But /proc/mounts is a symlink to self/mounts, and self is a symlink to $PID, 
> so after burrowing through the symlinks you wind up looking 
> at /proc/$PID/mounts.
> 
> My concern is that if I have init, as root, try to perform a umount -a, it 
> _still_ won't get the mounts belonging to child processes with a separate 
> namespace.  There's no "global view" of mounts available anywhere.

and having a "global view" is a debatable issue. What you are asking for
is a way for a process to be able to access all the mounts irrespective
of which namespace it belongs to. 

I think 'umount -a' semantics has to be refined and made as 'unmount all
the mounts belonging its namespace'. And if you agree with the
semantics, than unmouting whatever is found in /proc/mounts would
suffice.

> 
> On the other hand, if we fork a child process with its own namespace, the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Nov 2005 01:05

Re: New (now current development process)

Roman Zippel <zippel <at> linux-m68k.org> wrote:
>
> Here is a different kind of non trivial regression on a common platform:
> 
> $ ll -S /boot/ | grep ...
> -rw-r--r--  1 root root 1518317 2005-11-01 00:38 vmlinuz-2.6.14
> -rw-r--r--  1 root root 1506432 2005-08-30 00:36 vmlinuz-2.6.13
> -rw-r--r--  1 root root 1451154 2004-12-26 16:54 vmlinuz-2.6.10
> -rw-r--r--  1 root root 1432032 2005-06-26 03:50 vmlinuz-2.6.12
> -rw-r--r--  1 root root 1413888 2004-06-21 18:33 vmlinuz-2.6.7
> -rw-r--r--  1 root root 1394801 2004-05-17 22:14 vmlinuz-2.6.5
> -rw-r--r--  1 root root 1390233 2004-05-18 01:54 vmlinuz-2.6.6
> -rw-r--r--  1 root root 1315050 2003-09-12 22:10 vmlinuz-2.6.0-test5
> -rw-r--r--  1 root root 1280189 2003-06-06 01:00 vmlinuz-2.5.70
> -rw-r--r--  1 root root  918663 2002-11-11 22:42 vmlinuz-2.5.47
> -rw-r--r--  1 root root  887758 2004-02-19 01:24 vmlinuz-2.4.25
> -rw-r--r--  1 root root  883868 2003-12-20 21:02 vmlinuz-2.4.23

What does size(1) say?

Are you sure these kernels are feature-equivalent?
Permalink | Reply | 27 comments |
headers
Benjamin Herrenschmidt | 1 Nov 2005 01:05

Re: [PATCH] tpm: support PPC64 hardware

On Mon, 2005-10-31 at 08:37 -0600, Kylene Jo Hall wrote:
> The TPM is discovered differently on PPC64 because the device must be
> discovered through the device tree in order to open the proper holes in
> the io_page_mask for reading and writing in the low memory space.  This
> does not happen automatically like most devices because the tpm is not a
> normal pci device and lives under the root node.
> 
> This patch contains the necessary changes to the tpm logic.
> 
> This depends on patches submitted by Jake Moilanen (10/28) to allow for
> the opening of holes in the io_page_mask for this device.

Please submit to the appropriate list (linuxppc64-dev <at> ozlabs.org). There
are some issues with that patch. One, I intend to get rid of the
io_page_mask, so that part at least is gone. I don't like the exporting
of io_base_phys neither, it's an ugly hack.

Other comments inline.

> +/* Verify this is a 1.1 Atmel TPM */
> +static int atmel_verify_tpm11(void)
> +{
> +	struct device_node * dn;
> +	char *compat;
> +	int compat_len;
> +
> +	dn = find_devices("tpm");

find_devices() is a deprecated interface. Use the of_find_node_* series
and do an of_node_put() once done.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linus Torvalds | 1 Nov 2005 01:13

Re: New (now current development process)


On Mon, 31 Oct 2005, Andrew Morton wrote:
> 
> Are you sure these kernels are feature-equivalent?

They may not be feature-equivalent in reality, but it's hard to generate 
something that has the features (or lack there-of) of old kernels these 
days. Which is problematic.

But some of it is likely also compilers. gcc does insane padding in many 
cases these days. 

And a lot of it is us just being bloated. Argh.

		Linus
Permalink | Reply | 24 comments |
headers
Roman Zippel | 1 Nov 2005 01:17

Re: New (now current development process)

Hi,

On Mon, 31 Oct 2005, Andrew Morton wrote:

> Roman Zippel <zippel <at> linux-m68k.org> wrote:
> >
> > Here is a different kind of non trivial regression on a common platform:
> > 
> > $ ll -S /boot/ | grep ...
> > -rw-r--r--  1 root root 1518317 2005-11-01 00:38 vmlinuz-2.6.14
> > -rw-r--r--  1 root root 1506432 2005-08-30 00:36 vmlinuz-2.6.13
> > -rw-r--r--  1 root root 1451154 2004-12-26 16:54 vmlinuz-2.6.10
> > -rw-r--r--  1 root root 1432032 2005-06-26 03:50 vmlinuz-2.6.12
> > -rw-r--r--  1 root root 1413888 2004-06-21 18:33 vmlinuz-2.6.7
> > -rw-r--r--  1 root root 1394801 2004-05-17 22:14 vmlinuz-2.6.5
> > -rw-r--r--  1 root root 1390233 2004-05-18 01:54 vmlinuz-2.6.6
> > -rw-r--r--  1 root root 1315050 2003-09-12 22:10 vmlinuz-2.6.0-test5
> > -rw-r--r--  1 root root 1280189 2003-06-06 01:00 vmlinuz-2.5.70
> > -rw-r--r--  1 root root  918663 2002-11-11 22:42 vmlinuz-2.5.47
> > -rw-r--r--  1 root root  887758 2004-02-19 01:24 vmlinuz-2.4.25
> > -rw-r--r--  1 root root  883868 2003-12-20 21:02 vmlinuz-2.4.23
> 
> What does size(1) say?

This is already stripped and compressed, so it's not directly available.

> Are you sure these kernels are feature-equivalent?

Pretty much, on this machine I generally only include what I need, so only 
a few drivers were added, I even have KALLSYMS disabled.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Benjamin Herrenschmidt | 1 Nov 2005 01:16

Re: Commit "[PATCH] USB: Always do usb-handoff" breaks my powerbook

On Mon, 2005-10-31 at 16:23 +1100, Paul Mackerras wrote:
> My G4 powerbook gets a machine check on boot as a result of commit
> 478a3bab8c87a9ba4a4ba338314e32bb0c378e62.  Putting a return at the
> start of quirk_usb_early_handoff fixes it.
> 
> The code in quirk_usb_handoff_ohci looks rather bogus in that it
> doesn't do pci_enable_device before trying to access the device.

That and it doesn't test if the BARs are assigned at all, doesn't
request the resources, etc... 

I'm not sure it's legal to do pci_enable_device() from within a pci
quirk anyway. I really wonder what that code is doing in the quirks, I
don't think it's the right place, but I may be wrong.

What is the logic supposed to be there ?

Ben.
Permalink | Reply | 26 comments |
headers
David Brownell | 1 Nov 2005 01:24

Re: Linux 2.6.14 ehci-hcd hangs machine

On Monday 31 October 2005 2:15 pm, Borislav Petkov wrote:
> > >and dies. This bug is actually in there since 2.6.14-rc4 (see:
> > >http://bugzilla.kernel.org/show_bug.cgi?id=5428) and David Brownell
> > >supplied a patch which turned out to be useless eventually 
> > >since _rebooting_ 
> > >the kernel with the 'usb-handoff' (and without the patch) 
> > >solved the problem. 

In current GIT kernels (2.6.14+) that patch is now merged, and
also usb-handoff is the default.

> > >As it turns out, it actually solves the problem only for the 
> > >reboot case.
> > >My machine still hangs on an initial boot with and without 
> > >'usb-handoff'.

Huh?  That's not what you'd reported before.  What changed?
You're saying that _with_ that patch, and usb-handoff, it fails?

> >   While running with 'usb-handoff' turned on, do you see something like
> > "EHCI early BIOS handoff failed" (in power on or reboot cases) ? 
>
> Nope,	nothing of the like in the serial console log.

If the problem was IRQs getting somehow enabled after the handoff,
that patch would probably be a very useful thing.  If that does
help, I'll suggest that be merged into 2.6.14.x ... it'd have been
good to merge for 2.6.14.0 but quick merges seem mostly to be a
thing of the past any more.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Mackerras | 1 Nov 2005 01:24
Picon
Favicon

Re: [PATCH 1/20] inflate: lindent and manual formatting changes

Matt,

My concern about this series of patches is that it will make it harder
to keep the kernel zlib in sync with the upstream zlib.

Are you signing up to track the upstream zlib and apply any changes
made there to the kernel version, for the forseeable future?

Paul.
Permalink | Reply | 2 comments |
headers
Grant Grundler | 1 Nov 2005 01:28
Picon
Favicon

Re: [openib-general] [PATCH/RFC] IB: Add SCSI RDMA Protocol (SRP) initiator

On Mon, Oct 31, 2005 at 09:23:06AM -0800, Roland Dreier wrote:
> I've posted this several times for review and gotten some (but not
> very much) feedback.

Has anyone purchased IB SRP target and for use with linux?
I've seen references to "Cisco SFS 3001 Multifabric Server Switch"
(TS90) with the optional FC gateway stuff.

Anyway, while I have a TS90, I don't have the FC GW.  If someone
sent me one, I'd plug it into my test ring. I have a switch and
2Gb/s FC JBODs.

Are any native IB/SRP native storage devices available?

(Note that I'm asking only out of curiosity. I'm not going to
rush out and buy one for developement.)

> Is there any objection to me asking Linus to pull this for 2.6.15?

I don't have anything.

Just some nits:

> +#define DRV_VERSION	"0.01"
> +#define DRV_RELDATE	"January 11, 2005"

Implies the driver hasn't changed since Jan 11. Is that correct?
(I find that hard to believe if you got feedback)

Revision numbers are cheap - just roll it to 0.9 (or whatever)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kay Sievers | 1 Nov 2005 01:28

Re: Race between "mount" uevent and /proc/mounts?

On Wed, Oct 26, 2005 at 08:28:59PM +0100, Al Viro wrote:
> On Wed, Oct 26, 2005 at 04:34:17PM +0200, Kay Sievers wrote:
> > > Semantics for events depends on which objects you are interested in.
> > > Existing ones do not match _any_ of the real objects and I have no
> > > idea what exactly had been intended for them.  I've asked gregkh, but
> > > he didn't remember that either.  Apparently they are used by different
> > > people as (bad) approximations to different things.  Which doesn't work
> > > well.  And until somebody cares to describe what exactly are they trying
> > > to watch the situation obviously won't improve.
> > 
> > They are actually events for claim/release of a block device. As uevents
> > are bound to kobjects we needed to send these events from an existing device
> > which is the blockdev itself.
> > 
> > Sure, the event itself, has nothing to do with a filesystem. The names are
> > like this for historical reasons and "CLAIM/RELEASE" may be less confusing.
> > The events are used as a trigger to rescan /proc/mounts instead of polling
> > it constantly.
> 
> But that makes no sense.  /proc/*/mounts changes when mount tree changes.
> Which is obviously not an event happening to block devices.  Moreover,
> changes of mount tree may involve no changes in the set of active filesystems
> or be separated in time from such changes by arbitrary intervals.
> 
> Looks like seriously wrong assumptions in userland code working with these
> events...  _IF_ you want to keep track of /proc/*/mounts changes, the obvious
> solution would be to implement ->poll() for them.

Ok, makes sense. The attached seems to work for me. If we can get
something like this, we can remove the superblock claim/release events
(Continue reading)

Permalink | Reply | 0 comments |

Gmane