On Jan 15, 2008 22:05 -0500, Rik van Riel wrote:
> With a filesystem that is compartmentalized and checksums metadata,
> I believe that an online fsck is absolutely worth having.
>
> Instead of the filesystem resorting to mounting the whole volume
> read-only on certain errors, part of the filesy
In message <[EMAIL PROTECTED]>, Al Viro writes:
> After grep for locking-related things:
[...]
Thanks. I'll start looking at these issues asap.
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
After grep for locking-related things:
* lock_parent(): who said that you won't get dentry moved
before managing to grab i_mutex on parent? While we are at it,
who said that you won't get dentry moved between fetching d_parent
and doing dget()? In that case parent could've been _freed_ b
Serge:
> Right, but one will be preferred by the community - and while I have my
> own preference, I wouldn't put too much faith on that, rather talk with
> the apparmor folks, look over the lkml logs for previous submissions,
> and then decide.
Thanks for your advice.
We got the same advice from [
On Wed, Jan 16, 2008 at 07:13:07PM +1100, David Chinner wrote:
> On Tue, Jan 15, 2008 at 08:36:46PM +0800, Fengguang Wu wrote:
> > Redirtied inodes could be seen in really fast writes.
> > They should really be synced as soon as possible.
> >
> > redirty_tail() could delay the inode for up to 30s.
On Wed, Jan 16, 2008 at 04:09:30PM -0800, Andrew Morton wrote:
> On Thu, 17 Jan 2008 00:58:06 +0100 (CET) Jan Engelhardt <[EMAIL PROTECTED]>
> wrote:
>
> >
> > On Jan 17 2008 00:43, Karel Zak wrote:
> > >>
> > >> Seems like a plain bad idea to me. There will be any number of home-made
> > >> /
On Wed, Jan 16, 2008 at 11:12:31PM +0100, Miklos Szeredi wrote:
> The alternative (and completely safe) solution is to add another file
> to proc. Me no likey.
Since we need saner layout, I would strongly suggest exactly that.
> major:minor -- is the major minor number of the device hosting the
Andrew Morton wrote:
Seems like a plain bad idea to me. There will be any number of home-made
/proc/mounts parsers and we don't know what they do.
There is a lot of precedent for adding fields at the end. Since the
last fields in current /proc/*/mounts are dummy fields anyway, it
doesn't
On Jan 17 2008 11:33, Neil Brown wrote:
>On Thursday January 17, [EMAIL PROTECTED] wrote:
>>
>> On Jan 17 2008 00:43, Karel Zak wrote:
>> >>
>> >> Seems like a plain bad idea to me. There will be any number of home-made
>> >> /proc/mounts parsers and we don't know what they do.
>> >
>> > So, le
On Thursday January 17, [EMAIL PROTECTED] wrote:
>
> On Jan 17 2008 00:43, Karel Zak wrote:
> >>
> >> Seems like a plain bad idea to me. There will be any number of home-made
> >> /proc/mounts parsers and we don't know what they do.
> >
> > So, let's use /proc/mounts_v2 ;-)
>
> Was not it like
On Thu, 17 Jan 2008 00:58:06 +0100 (CET) Jan Engelhardt <[EMAIL PROTECTED]>
wrote:
>
> On Jan 17 2008 00:43, Karel Zak wrote:
> >>
> >> Seems like a plain bad idea to me. There will be any number of home-made
> >> /proc/mounts parsers and we don't know what they do.
> >
> > So, let's use /proc
On Jan 17 2008 00:43, Karel Zak wrote:
>>
>> Seems like a plain bad idea to me. There will be any number of home-made
>> /proc/mounts parsers and we don't know what they do.
>
> So, let's use /proc/mounts_v2 ;-)
Was not it like "don't use /proc for new things"?
-
To unsubscribe from this list:
On Wed, Jan 16, 2008 at 02:30:51PM -0800, Andrew Morton wrote:
> On Wed, 16 Jan 2008 23:12:31 +0100
> Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> >
> > In theory it could break userspace, but I think it's very unlikely to
> > do so, because stuff is added only at the end of the lines, and
> > beca
> > The reason, why this patch was dug up, is that if the bdi-sysfs patch
> > is going to use device numbers to identify BDIs, then there should be
> > a way for the user to map the device number into mount(s).
> >
> > But it's useful regardless of the bdi-sysfs patch.
>
> Don't know what that is
On Wed, 16 Jan 2008 23:12:31 +0100
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> The reason, why this patch was dug up, is that if the bdi-sysfs patch
> is going to use device numbers to identify BDIs, then there should be
> a way for the user to map the device number into mount(s).
>
> But it's us
The reason, why this patch was dug up, is that if the bdi-sysfs patch
is going to use device numbers to identify BDIs, then there should be
a way for the user to map the device number into mount(s).
But it's useful regardless of the bdi-sysfs patch.
Can this be added to -mm?
In theory it could b
In message <[EMAIL PROTECTED]>, Michael Halcrow writes:
> On Thu, Jan 10, 2008 at 10:57:46AM -0500, Erez Zadok wrote:
[...]
> Would the inclusion of Unionfs in mainline really slow down or damage
> the union mount effort? If not, then I think the pragmatic approach
> would be to make it available i
Alan Cox wrote:
>> Writeback cache on disk in iteself is not bad, it only gets bad if the
>> disk is not engineered to save all its dirty cache on power loss,
>> using the disk motor as a generator or alternatively a small battery.
>> It would be awfully nice to know which brands fail here, if any,
On Thu, Jan 10, 2008 at 10:57:46AM -0500, Erez Zadok wrote:
> In message <[EMAIL PROTECTED]>, Christoph Hellwig
> writes:
> > On Thu, Jan 10, 2008 at 09:59:19AM -0500, Erez Zadok wrote:
> > >
> > > Dear Linus, Al, Christoph, and Andrew,
> > >
> > > As per your request, I'm posting for review the
On Jan 16, 2008 3:49 AM, Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> ext3's "lets fsck on every 20 mounts" is good idea, but it can be
> annoying when developing. Having option to fsck while filesystem is
> online takes that annoyance away.
I'm sure everyone on cc: knows this, but for the record y
> > This is an experimental patch for supporing unprivileged mounts and
> > umounts. The following features are added:
>
> same feedback as last time ... the cap stuff needs to be made optional and
> proper header checks added to configure ...
Later, sure. For now, I'm concentrating on the act
On Wednesday 16 January 2008, Miklos Szeredi wrote:
> This is an experimental patch for supporing unprivileged mounts and
> umounts. The following features are added:
same feedback as last time ... the cap stuff needs to be made optional and
proper header checks added to configure ...
> 1) If m
ons, 16 01 2008 kl. 11:02 +0100, skrev Christian Hesse:
> On Tuesday 15 January 2008, Chris Mason wrote:
> > Hello everyone,
> >
> > Btrfs v0.10 is now available for download from:
>
> It does not even compile for me, tested with 2.6.24-rc{7,8}. I will look at
> that later.
>
> fs/built-in.o: I
On Wed, Jan 16, 2008 at 08:43:25AM +1100, David Chinner wrote:
> ext3 is not the only filesystem that will have trouble due to
> volatile write caches. We see problems often enough with XFS
> due to volatile write caches that it's in our FAQ:
In fact it will hit every filesystem. A write-back cac
Quoting Kentaro Takeda ([EMAIL PROTECTED]):
> Hello.
>
> Serge E. Hallyn wrote:
> > I must say I personally prefer the apparmor approach.
> No problem.
>
> > But I'd recommend
> > you get together and get this piece pushed on its own, whichever version
> > you can agree on.
> TOMOYO can use AppAr
Util-linux-ng 2.13.1 Release Notes
==
Fixed security issues:
-
CVE-2007-5191 - mount(8) doesn't drop privileges properly when
calling helpers
Changelog:
-
For more details see ChangeLog files at:
ftp://ftp.kernel.o
From: Miklos Szeredi <[EMAIL PROTECTED]>
This is an experimental patch for supporing unprivileged mounts and
umounts. The following features are added:
1) If mount/umount are suid, first try without privileges.
This is done by forking, dropping privileges in child, and redirecting
stderr to /de
From: Miklos Szeredi <[EMAIL PROTECTED]>
Allow bind mounts to unprivileged users if the following conditions are met:
- mountpoint is not a symlink
- parent mount is owned by the user
- the number of user mounts is below the maximum
Unprivileged mounts imply MS_SETUSER, and will also have
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add sysctl variables for accounting and limiting the number of user
mounts.
The maximum number of user mounts is set to 1024 by default. This
won't in itself enable user mounts, setting a mount to be owned by a
user is first needed.
[akpm]
- don't use e
From: Miklos Szeredi <[EMAIL PROTECTED]>
This patchset adds support for keeping mount ownership information in the
kernel, and allow unprivileged mount(2) and umount(2) in certain cases.
The mount owner has the following privileges:
- unmount the owned mount
- create a submount under the own
Thanks to everyone for the comments on the previous submission.
Christoph, could you please look through the patches if they are
acceptable from the VFS point of view?
Thanks,
Miklos
v6 -> v7:
- add '/proc/sys/fs/types//usermount_safe' tunable (new patch)
- do not make FUSE safe by default, d
From: Miklos Szeredi <[EMAIL PROTECTED]>
Allow clone_mnt() to return errors other than ENOMEM. This will be used for
returning a different error value when the number of user mounts goes over the
limit.
Fix copy_tree() to return EPERM for unbindable mounts.
Signed-off-by: Miklos Szeredi <[EMAIL
From: Miklos Szeredi <[EMAIL PROTECTED]>
On mount propagation, let the owner of the clone be inherited from the
parent into which it has been propagated.
If the parent has the "nosuid" flag, set this flag for the child as
well. This is needed for the suid-less namespace (use case #2 in the
first
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add the following:
/proc/sys/fs/types/${FS_TYPE}/usermount_safe
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/filesystems.c
===
--- linux.orig/fs/filesystems.c 2008
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add a new mount flag "nosubmnt", which denies submounts for the owner.
This would be useful, if we want to support traditional /etc/fstab
based user mounts.
In this case mount(8) would still have to be suid-root, to check the
mountpoint against the user/us
From: Miklos Szeredi <[EMAIL PROTECTED]>
For "safe" filesystems allow unprivileged mounting and forced
unmounting.
A filesystem type is considered "safe", if mounting it by an
unprivileged user may not cause a security problem. This is somewhat
subjective, so setting this property is left to use
From: Miklos Szeredi <[EMAIL PROTECTED]>
Don't require the "user_id=" and "group_id=" options for unprivileged mounts,
but if they are present, verify them for sanity.
Disallow the "allow_other" option for unprivileged mounts.
FUSE was designed from the beginning to be safe for unprivileged
user
From: Miklos Szeredi <[EMAIL PROTECTED]>
The owner doesn't need sysadmin capabilities to call umount().
Similar behavior as umount(8) on mounts having "user=UID" option in /etc/mtab.
The difference is that umount also checks /etc/fstab, presumably to exclude
another mount on the same mountpoint.
On Wed, 16 Jan 2008 12:51:44 +0100, Pavel Machek said:
> I guess I should try to measure it. (Linux already does writeback
> caching, with 2GB of memory. I wonder how important disks's 2MB of
> cache can be).
It serves essentially the same purpose as the 'async' option in /etc/exports
(i.e. we de
On Tue 2008-01-15 18:44:26, Daniel Phillips wrote:
> On Jan 15, 2008 6:07 PM, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > I had write cache enabled on my main computer. Oops. I guess that
> > means we do need better documentation.
>
> Writeback cache on disk in iteself is not bad, it only gets bad
Hi!
> Along with this effort, could you let me know if the world actually
> cares about online fsck?
I'm not the world's spokeperson (yet ;-).
> Now we know how to do it I think, but is it
> worth the effort.
ext3's "lets fsck on every 20 mounts" is good idea, but it can be
annoying when deve
On Tuesday 15 January 2008, Chris Mason wrote:
> Hello everyone,
>
> Btrfs v0.10 is now available for download from:
It does not even compile for me, tested with 2.6.24-rc{7,8}. I will look at
that later.
fs/built-in.o: In function `btrfs_xattr_set_acl':
acl.c:(.text+0x68f33): undefined referenc
> > > Why not "nosubmnt"?
> >
> > Why not indeed. Maybe I should try to use my brain sometime.
>
> Well it really should have 'user' or 'unpriv' in the name
> somewhere. 'nosubmnt' is more confusing than 'nomnt' because
> it no submounts really sounds like a reasonable thing in
> itself...
I s
Hi,
On Tue, 15 Jan 2008, Christoph Hellwig wrote:
> Something like the loop above is not going to go in for sure. Once we
> get rid of the sb->s_files we can put the list_head in struct file to
> new use eventually if we don't want to get rid of it. E.g. and
> per-inode list would be much better
On Tue, Jan 15, 2008 at 08:36:46PM +0800, Fengguang Wu wrote:
> Redirtied inodes could be seen in really fast writes.
> They should really be synced as soon as possible.
>
> redirty_tail() could delay the inode for up to 30s.
> Kill the delay by using requeue_io() instead.
That's actually bad for
45 matches
Mail list logo
