On Thu, 2012-10-04 at 14:16 -0700, Neil Salstrom wrote:
>
> I've not submitted a kernel bug before but I've read the bug reporting
> pages. I'll try to do my best and if you need more information please
> let me know.
>
> I'm using Linux Mint 13 (64 bit) on AMD hardware with a self compiled
> 3
From: Miklos Szeredi
The PID and the TGID of the process tringgering the mount are sent to the
daemon. Currently the global pid values are sent (ones valid in the initial pid
namespace) but this is wrong if the autofs daemon itself is not running in the
initial pid namespace.
So send the pid
convert oz_pgrp to the value in the initial pid namespace.
Signed-off-by: Sukadev Bhattiprolu
Cc: Serge Hallyn
Cc: Eric Biederman
Signed-off-by: Miklos Szeredi
---
fs/autofs4/autofs_i.h |4 ++--
fs/autofs4/dev-ioctl.c | 16 ++--
fs/autofs4/inode.c | 33 +++
Ian Kent writes:
> On Fri, 2012-11-23 at 11:45 +0800, Ian Kent wrote:
>> On Thu, 2012-11-22 at 17:24 +0100, Miklos Szeredi wrote:
>> > Patches were tested by the customer.
>> >
>> > Ian, Eric, do these patches look OK?
>>
>> They look OK to me
On Sat, Nov 24, 2012 at 1:07 PM, Eric W. Biederman
wrote:
> Ian Kent writes:
>
>> On Sat, 2012-11-24 at 10:23 +0800, Ian Kent wrote:
>>> On Fri, 2012-11-23 at 15:30 +0100, Miklos Szeredi wrote:
>>> AFAICS autofs mounts mounted with MS_PRIVATE in the initial nam
On Mon, Nov 26, 2012 at 3:29 AM, Ian Kent wrote:
>> > > MS_UNBINDABLE says: skip this mount when copying a mount tree, such
>> > > as when the mount namespace is cloned.
>> > >
>> > > If you set MS_UNBINDABLE on autofs mounts then they will simply not
>> > > appear in a cloned namespace. Which s
o fuse_req
fuse: use req->page_descs[] for argpages cases
mm: minor cleanup of iov_iter_single_seg_count()
fuse: pass iov[] to fuse_get_user_pages()
fuse: optimize fuse_get_user_pages()
fuse: optimize __fuse_direct_io()
Miklos Szeredi (3):
fuse: cleanup f
Hi Feng,
On Wed, Jan 16, 2013 at 2:59 PM, Feng Shuo wrote:
> Hi Miklos,
>
> Would you consider the adaptive readdir_plus patch?
Yes, I'm going to go over and review the patches sent in the last month.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
> On Fri, Feb 15, 2008 at 11:23:47AM +0100, Miklos Szeredi wrote:
> > This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y.
> >
> > Thanks,
> > Miklos
> > ----
> >
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > I added a nas
> On Mon, Feb 18, 2008 at 12:47:59PM +0100, Miklos Szeredi wrote:
> > So what should I do?
> >
> > Would Al be wanting to merge this into his VFS tree? (Can't find it
> > on git.kernel.org yet, BTW.)
>
> FWIW, it's on hera right now, should propagat
> > On Sat, Feb 23, 2008 at 10:38:59AM +0100, Miklos Szeredi wrote:
> > > > On Fri, Feb 15, 2008 at 11:23:47AM +0100, Miklos Szeredi wrote:
> > > > > This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y.
> > > > >
> > > > > Th
> On Sat, Feb 23, 2008 at 06:33:13PM +0100, Miklos Szeredi wrote:
> > > c) just what is limited by that sysctl? AFAICS, rbind is allowed
> > > if mountpoint is on user vfsmount and it seems to create vfsmounts without
> > > eating into that limit just fine... Wh
Hi Greg!
> On Fri, Feb 15, 2008 at 11:23:47AM +0100, Miklos Szeredi wrote:
> > This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y.
> >
> > Thanks,
> > Miklos
> > ----
> >
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> >
is not really needed. Just require ->set_page_dirty() be
filled in by filesystems which want swapfiles (and others too, in the
longer term, the fallback is just historical crud).
Here's an incremental patch addressing these issues and beautifying
t
> > mm-page_file_methods.patch
> >
> > This makes page_offset and others more expensive by adding a
> > conditional jump to a function call that is not usually made.
> >
> > Why do swap pages have a different index to everyone else?
>
> Because the page->index of an anonymous page is
> > > > mm-page_file_methods.patch
> > > >
> > > > This makes page_offset and others more expensive by adding a
> > > > conditional jump to a function call that is not usually made.
> > > >
> > > > Why do swap pages have a different index to everyone else?
> > >
> > > Because the pag
It seems as if recent kernles don't cache floppy reads. Is this
intentional? I haven't tried it for a long time, so I have no idea
when this behavior changed.
Miklos
bcica:~> time dd if=/dev/fd0 of=/dev/null bs=2048 count=100
100+0 records in
100+0 records out
0.000u 0.000s 0:07.59 0.0% 0+
We're having a bit of a disagreement with Christoph Hellwig about the
way FUSE does (or should do) permission checking. Comments (either
way) are appreciated.
Here's my side of the story:
FUSE (filesystem in userspace) is designed to allow mounting an FS by
non-privileged users (it can also be u
> > 3) No other user should have access to files under the mount, not
> > even root[5]
>
> > [5] Obviously root cannot be restricted, but accidental access to
> > private data is still a good idea. E.g. root squashing by NFS servers
> > has a similar affect.
>
> Could you explain a little
> > > > 3) No other user should have access to files under the mount, not
> > > > even root[5]
> > >
> > > > [5] Obviously root cannot be restricted, but accidental access to
> > > > private data is still a good idea. E.g. root squashing by NFS servers
> > > > has a similar affect.
> > >
> > 1) User must not be able to modify files or directories in a way
> > which he otherwise could not do (e.g. mount a filesystem over
> > /bin)
> >
> > 2) Suid and device semantics should be disabled within the mount
> >
> > 3) No other user should have access to files under the
> > > Root squashing is actually a much less obnoxious restriction. It means
> > > that local uid 0 doesn't automatically correspond to remote uid 0.
> >
> > I don't agree that it's less obnoxious. Root squashing and a
> > restricted directory (-rwx--) would have exactly the same affect:
> >
> I think that would be _much_ nicer implemented as a mount which is
> invisible to other users, rather than one which causes the admin's
> scripts to spew error messages.
Spew is a strong word. It'll get a single EACCES at the mountpoint.
The same is true for directories not accessible by 'nobod
> > Well the sanity check on the "server" side is always enforced. You
> > can't "trick" sftp or ftp to not check permissions. So checking on
> > the "client" side too (where the fuse daemon is running) makes no
> > sense, does it?
>
> That argument doesn't make much sense to me. But we're at t
> Note that NFS checks the permissions on _both_ the client and server,
> for a reason.
Does it? If I read the code correctly the client checks credentials
supplied by the server (or cached). But the server does the actual
checking of permissions.
Am I missing something?
Thanks,
Miklos
-
To un
> > > With that, the desire for virtual filesystems which cannot be read
> > > by your sysadmin (by accident) is easy to satisfy - and that kind of
> > > mechanism would probably be acceptable to all.
> >
> > The problem is that this way the responsibility goes to the userspace
> > program, which
> If the user wants to edit a read-only file in a tgz owned by himself,
> why can he not _chmod_ the file and _then_ edit it?
>
> That said, I would _usually_ prefer that when I enter a tgz, that I
> see all component files having the same uid/gid/permissions as the tgz
> file itself - the same as
> For 1) your porposal makes sense, however for 2) it's useless, since
> now the user doesn't want the hiding.
I realize that the idea _could_ be used to drop 'allow_root' mount
option from the kernel. Since 'allow_root' doesn't add any security
over 'allow_other' it's safe to do it in userspace.
> > I can accept that usually you are not interested in the stored
> > uid/gid. But doubt that you want to lose permission information when
> > you mount a tar file. Zip is a different kettle of fish since that
> > doesn't contain uid/gid/permissions.
>
> It's not about being not interested.
>
> Indeed, if it can be done with namespaces _and_ mounting on a file
> (that file-as-directory concept), _and_ automounting, then you could
> cd into your tgz files and others could too :)
There's still that little problem of accessing the tgz file both as a
file and a directory. But yes. Maybe
> >
> > > And for either version of NFS, if the uid and gid are non-zero, and
> > > the permission bits indicate that an access is permitted, then the
> > > client does not consult the server for permission.
> >
> > Where's that? I see no such check.
>
> /*
>* Trust UNIX mode bits
> > > Note that NFS checks the permissions on _both_ the client and server,
> > > for a reason.
> >
> > Does it? If I read the code correctly the client checks credentials
> > supplied by the server (or cached). But the server does the actual
> > checking of permissions.
> >
> > Am I missing so
> There was a thread a few months ago where file-as-directory was
> discussed extensively, after Namesys implemented it. That's where the
> conversation on detachable mount points originated AFAIR. It will
> probably happen at some point.
>
> A nice implemention of it in FUSE could push it along
> > Still can't find it :)
> >
> > Which kernel? Which file?
>
> I'm looking at linux-2.4.30/fs/nfs/dir.c.
Ahh, OK.
nfs_permission() in 2.6 looks quite a bit different. And permission
bits are not used if ->access() is available.
Miklos
-
To unsubscribe from this list: send the line "unsubsc
> > There are uses for both. For example today I was updating the tar ball
> > which is used to create the var file system for a new chroot. I certainly
> > want to see corretly setup owner/permissions when I look into that tar
> > ball using a FUSE fs...
>
> If I'm updating a var filesystem
> > Aren't there some assumptions in VFS that currently make this
> > impossible?
>
> I believe it's OK with VFS, but applications would be confused to death.
> Well, there really is one issue -- dentries have exactly one parent, so
> what do you do when opening a file with hardlinks as a director
> Look up the rather large linux-kernel & linux-fsdevel thread "silent
> semantic changes with reiser4" and it's followup threads, from last
> year.
Wow, it's 700+ messages. I got through the first 40, and already feel
dizzy :)
> It's already been tried. You will also find sensible ideas on wha
> > I have a little project to imlement a "userloop" filesystem, which
> > works just like "mount -o loop", but you don't need root privs. This
> > is really simple to do with FUSE and UML.
>
> That would be a nice way to implement those rarely used old
> filesystems that aren't really needed in
> > > Yet, the results from stat() don't distinguish the number spaces,
> > > and "ls" doesn't map the numbers to names properly in the wrong
> > > space.
> >
> > Well you can use "ls -n". It's up to the tools to present the
> > information you want in the way you want it. If a tool can't do tha
> /** The major number of the fuse character device */
> -#define FUSE_MAJOR 10
> +#define FUSE_MAJOR MISC_MAJOR
OK, this makes some sense.
> /** The minor number of the fuse character device */
> -#define FUSE_MINOR 229
> +#define FUSE_MINOR MISC_DYNAMIC_MINOR
Why?
FUSE has an allocated fix
> >> /** The minor number of the fuse character device */
> >> -#define FUSE_MINOR 229
> >> +#define FUSE_MINOR MISC_DYNAMIC_MINOR
> >
> >FUSE has an allocated fix minor. Dynamic minor is much harder to
> >handle with legacy /dev (not udev).
>
> How many users of 2.6.13 and up really do not have
I get the following build failure on 2.6.13-rc3-mm1. It builds fine
on 2.6.13-rc3.
Can anybody help fixing it?
Thanks,
Miklos
/usr/src/quilt/linux$ make ARCH=um V=1
if test ! /usr/src/quilt/linux -ef /usr/src/quilt/linux; then \
/bin/sh /usr/src/quilt/linux/scripts/mkmakefile \
Thanks for the writeup, it helps to understand things a bit better.
However I still don't understand a few things:
> Section 1. mount:
>
> to begin with we have a the following mount tree
>
>root
> / / \ \ \
>/ t1 t2 \
> I think you mis-understand. Mountlo seems to allow one to mount
> (through FUSE) any filesystem image for which there is a linux kernel
> kernel driver available. This is a very nice capability.
>
> But what I speak of is to port the 100% feature-complete (and
> well-tested) befs driver from the
> Could you please explain me, why we need to wake up somebody right
> before freeing an inode? It seems for me, if somebody really wait on
> this inode, then they have a good chance to access already freed memory.
find_inode() needs to be woken up (__wait_on_freeing_inode) when an
inode being f
> When sunrpc is as module, sysctl adds to proc fs proc/sys/sunrpc, adds 1
> to number of proc/sys link (see later), but when it's ls-ed, there is
> still old count.
Does this patch solve it?
Index: linux/fs/proc/generic.c
===
---
I'd like to make my filesystem be able to do file creation and opening
atomically. This is needed for filesystems which cannot separate
checking open permission from the actual open operation.
Usually any filesystem served from userspace by an unprivileged (no
CAP_DAC_OVERRIDE) process will be su
> We've already got a patch that does this, and that I'm queueing up for
> inclusion.
Cool!
> http://client.linux-nfs.org/Linux-2.6.x/2.6.12/linux-2.6.12-63-open_file_intents.dif
Comments:
> /*
> + * Open intents have to release any file pointer that was allocated
> + * but not used by the VFS
> Intents are meant as optimisations, not replacements for existing
> operations. I'm therefore not really comfortable about having them
> return errors at all.
In my case they are not an optimization, rather the only way to
correctly perform an open with O_CREAT.
> > > + nd->intent.open.
> > > > > + nd->intent.open.file = NULL;
> > > >
> > > > Why is this NULL assignment needed? nd will not be used after this.
> > > >
> > > > > + }
> > > > > + path_release(nd);
> > > > > +}
> > > > > +
> > > > >
> > >
> > > It could be dropped. The reason for putting it in
> > > There is quite a bit of code out there that assumes it is free to stuff
> > > things into nd->mnt and nd->dentry. Some of it is Al Viro's code, some
> > > of it is from other people.
> > > For instance, the ESTALE handling will just save nd->mnt/nd->dentry
> > > before calling __link_path_wal
> Really?
>
> static int __emul_lookup_dentry(const char *name, struct nameidata *nd)
> {
> .
> if (path_walk(name, nd) == 0) {
> if (nd->dentry->d_inode) {
> dput(old_dentry);
> mntpu
UML is broken again in -mm.
Maybe UML should be added to one of the automatic build suites.
Miklos
ccache gcc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -ffreestanding -O2 -fno-omit-frame-pointer
-fno-optimize-sibling-calls -g -D__arch_um__ -DSUBARC
> > UML is broken again in -mm.
> >
> > Maybe UML should be added to one of the automatic build suites.
>
> It is, see here: http://l4x.org/k/?d=6080 .
Cool.
> But the maintainer (if he cares) will know that it's broken and send
> a fix in time. -mm is imho designed to be broken from time to t
> On Wed, Aug 17, 2005 at 12:43:37AM -0500, Kumar Gala wrote:
> > >I concur, in fact we should really kill that thing off entirely.
> >
> > I'm all for killing it off entirely but got some feedback that on
> > i386 segment.h can be included by userspace programs.
>
> No kernel headers can be in
> > There are perfectly valid uses of kernel headers from userspace. For
> > example if a program uses the netlink interface, it should include
> > . It's the interface definition after all.
> >
> > Glibc headers also include and in quite few places.
>
> But these files in /usr/include/ aren'
> > They are provided by _one_ kernel, not necessarily the running kernel.
>
> No, they're provided by packages like glibc-kernheaders or similar
> that are maintained separately.
Yes. And "maintenance" I presume means "copy" the kernel headers and
do some cleanup to be compliant to the relevant
> >
> > 1) Only allow mount over a directory for which the user has write
> > access (and is not sticky)
> >
> > 2) Use nosuid,nodev mount options
> >
> > [ parts deleted ]
>
> Do these solve all the security concerns with unprivileged mounts, or
> are there other barriers/concerns? S
This program works similarly to "mount -o loop", but the filesystem
runs in userspace, making it possible for non-root users to safely
loopback mount filesystem images.
It works by starting a UML (User Mode Linux) instance, mounting the
image in there, and exporting the resulting data through FUSE
>
> I think you shouldn't help the admins by creating shoes with target marks.
>
> Allowing user mounts with no* should be allways ok (no config needed
> besides the ulimit), and mounting specified files to defined locations
> is allready supported by fstab.
I tend to agree. It should be obvio
> Likely because its a chroot vulnerability.
>
> It allows a process to obtain a reference to the root vfsmount that
> doesn't have chroot checks performed on it.
>
> Consider the following pseudo example:
>
[...]
>
> if main is run within a chroot where it's "/" is on the same vfsmount as
> it
> Actually, the right question is "how is fuse better than coda". I've
> asked that before; unlike nfs, userspace filesystems implemented with
> coda actually *work*, but do not provide partial-file writes.
You answered your own question.
I did talk to Jan Harkes about the file I/O issue before s
> It is important because on UNIX, "root" rules on local filesystems.
> I dont't like the idea of root not being able to run "find -xdev"
> anymore for administrative tasks, just because something got hidden
> by accident or just for fun by a user. It's not about malicious
> users who want to hide
[CC restored]
> Okay, I just wanted to mention CODA. Modifying CODA is probably still
> better than modifying NFS (as akpm suggested at one point).
Definitely.
Here are some numbers on the size these filesystems as in current -mm
('wc fs/${fs}/* include/linux/${fs}*')
nfs: 25495
9p:6102
co
> "solving it properly" refers to hardening the leaf node constraint
> against circumvention I assume. Suppose there's a script for doing simple
> on-line backups using "find". Now explain to the user why he lost his
> data due to a backup script geting EACCES on a non-leaf FUSE mount.
I see your
> > I see your point. But then this is really not a security issue, but
> > an "are you sure you want to format C:" style protection for the
> > user's own sake. Adding a mount option (checked by the library) for
> > this would be fine. E.g. with "mount_nonempty" it would not refuse to
> > mount
> - Anything which you think needs to go into 2.6.13, please let me know.
FUSE?
I don't see any advantage of holding it off any more.
I feel the slightest of distrust towards the usefulness or quality of
FUSE. Anyway if the users aren't interested enough to complain about
inclusion, it's not re
> I'm inclined to just give up on the permissions thing - if someone comes up
> with something better then fine.
>
> But I do wonder whether v9fs would be a better place to be concentrating
> the development effort.
v9fs is a network filesystem. And it's a network filesystem that's
not even very
> This patch adds the shared/private/slave support for VFS trees.
[...]
> -struct vfsmount *lookup_mnt(struct vfsmount *mnt, struct dentry *dentry)
> +struct vfsmount *lookup_mnt(struct vfsmount *mnt, struct dentry *dentry,
> struct dentry *root)
> {
How about changing it to inline and calling
> > > + * recursively change the type of the mountpoint.
> > > + */
> > > +static int do_change_type(struct nameidata *nd, int flag)
> > > +{
> > > + struct vfsmount *m, *mnt;
> > > + struct vfspnode *old_pnode = NULL;
> > > + int err;
> > > +
> > > + if (!(flag & MS_SHARED) && !(flag & MS_PRIVATE)
> The reason why I implemented that way, is to less confuse the user and
> provide more flexibility. With my implementation, we have the ability
> to share any part of the tree, without bothering if it is a mountpoint
> or not. The side effect of this operation is, it ends up creating
> a vfsmount
> git-kbuild.patch
This breaks building of external modules:
make -C /usr/src/linux-2.6.13-rc3-mm2 M=/home/miko/fuse/kernel modules
make[1]: Entering directory `/usr/src/linux-2.6.13-rc3-mm2'
WARNING: Symbol version dump /usr/src/linux-2.6.13-rc3-mm2/Module.symvers
i
> @@ -54,7 +55,7 @@ static inline unsigned long hash(struct
>
> struct vfsmount *alloc_vfsmnt(const char *name)
> {
> - struct vfsmount *mnt = kmem_cache_alloc(mnt_cache, GFP_KERNEL);
> + struct vfsmount *mnt = kmem_cache_alloc(mnt_cache, GFP_KERNEL);
> if (mnt) {
>
> +static int do_make_shared(struct vfsmount *mnt)
> +{
> + int err=0;
> + struct vfspnode *old_pnode = NULL;
> + /*
> + * if the mount is already a slave mount,
> + * allocate a new pnode and make it
> + * a slave pnode of the original pnode.
> + */
> + if (IS_M
> > This is an example, where having struct pnode just complicates things.
> > If there was no struct pnode, this function would be just one line:
> > setting the shared flag.
> So your comment is mostly about getting rid of pnode and distributing
> the pnode functionality in the vfsmount structure
> Thanks for the report. I had overlooked this usage when modifying this
> part of kbuild.
> The following fix it - and work in the following test setups:
> make
> make O=
> make M=
> make O= M=
Yes, it works now.
Thanks,
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-k
Hi Andrew,
The following patches are minor fixes and enhancements.
Please apply.
Thanks,
Miklos
PS. May I inquire into your plans with FUSE? The last half year in
-mm has been very productive and useful, but I feel it's time to
decide whether to merge or to drop.
-
To unsubscribe from this lis
This patch fixes a signed/unsigned comparison bug found by Franco Broi
after months of filesystem uptime and 2,147,483,648 performed fs
operations.
Since the request identifier is already 64 bits on the userspace ABI,
the counter is now made 64-bit too.
Signed-off-by: Miklos Szeredi <[EM
Don't change mtime/ctime/atime to local time on read/write. Rather
invalidate file attributes, so next stat() will force a GETATTR call.
Bug reported by Ben Grimm.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
diff -rup linux-2.6.13-rc3-mm3/fs/fuse/dir.c linux-fuse/fs/fuse/dir.
the following patch adds MODULE_ALIAS_MISCDEV() definition for fuse
driver. It will enable the auto-loading of the module via access to
the corresponding device file.
From: Takashi Iwai <[EMAIL PROTECTED]>
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
diff -rup linux-2.6.13-rc3
Add homepage pointer.
Clarify security requirements, based on discussion with Frank van
Maarseveen.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
diff -rup linux-2.6.13-rc3-mm3/Documentation/filesystems/fuse.txt
linux-fuse/Documentation/filesystems/fuse.txt
--- linux-2.6.13-r
Check for the presence of all mandatory mount options.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
diff -rup linux-2.6.13-rc3-mm3/fs/fuse/inode.c linux-fuse/fs/fuse/inode.c
--- linux-2.6.13-rc3-mm3/fs/fuse/inode.c2005-07-29 11:03:38.0
+0200
+++ linux-fuse/fs/fuse/i
> > static struct vfsmount *propagation_next(struct vfsmount *p,
> > struct vfsmount *base)
> > {
> > /* first iterate over the slaves */
> > if (!list_empty(&p->mnt_slave_list))
> > return first_slave(p);
>
> I think this code should be
>
> Ok. I have started implementing your idea. But the implementation is no
> simple. Its becomes a complex mess. Atleast in the case of pnode
> datastructure implementation, the propogation was all abstracted and
> concentrated in the pnode datastructure.
>
> Here is a sample implementation of do
> > Do you still believe that your idea is simpler?
>
> Well, you have bundled do_make_slave(), pnode_member_to_slave() and
> empty_pnode() all into one function. I think your original split is
> quite nice. If you'd split this function up like that, I think you'd
> agree, that the end result i
> Well, don't know about anyone else, but I certainly don't use it
> anymore. If anyone needs a fully-functional befs driver, the easiest
> route to that would probably be getting Haiku's befs driver to compile
> in userland as a FUSE fs.
That has already been done:
http://prdownloads.sourcefo
Linus et Al,
Access mode of 3 is undocumented but it does do something halfway sane
on all linuxes (checked back to 2.0.X).
The open requires both read and write permission to succeed, but the
resulting file descriptor can neither be read nor written.
The responsible code in filp_open() is this:
Fix up fuse_follow_link() and fuse_put_link() to conform to the new API.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Index: linux/fs/fuse/dir.c
===
--- linux.orig/fs/fuse/dir.c2005-08-23 21:16:52.0 +0200
+++
Hi Andrew!
The following patches are small cleanups and fixes, I hope none of
them are too controversial.
It's probably safe to apply ;)
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://v
Remove unused ia_attr_flags from struct iattr, and related defines.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Index: linux/fs/hostfs/hostfs.h
===
--- linux.orig/fs/hostfs/hostfs.h 2005-08-19 14:13:47.0
Extract common code into inline functions to make reading easier.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Index: linux/fs/namei.c
===
--- linux.orig/fs/namei.c 2005-08-23 20:25:53.0 +0200
+++ linux/fs/n
This patch cleans up proc_cwd_link() and proc_root_link() by factoring
out common code into get_fs_struct().
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Index: linux/fs/proc/base.c
===
--- linux.orig/fs/proc/base.c 2
This patch fixes wrongly placed elements in the pid_directory_inos
enum. Also add comment so this mistake is not repeated.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Index: linux/fs/proc/base.c
===
--- linux.orig/f
Extract common code used by ptrace_attach() and may_ptrace_attach()
into a separate function.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Index: linux/kernel/ptrace.c
===
--- linux.orig/kernel/ptrace.c 2005-08-19
64 bit architectures all implement their own compatibility sys_open(),
when in fact the difference is simply not forcing the O_LARGEFILE
flag. So use the a common function instead.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Index: linux/include/linu
Deprecate access mode of '3' in open() as suggested by Linus.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Index: linux/fs/open.c
===
--- linux.orig/fs/open.c2005-08-23 13:15:49.0 +0200
+++
cifs_create() did totally the wrong thing with nd->intent.open.flags:
it interpreted nd->intent.open.flags as the original open flags, not
the one transformed for open_namei(). Also it used the intent data
even if it was not filled in (if called from sys_mknod()).
Signed-off-by: Miklos S
> Bad names, IMO.
>
You're probably right. Can you suggest better ones?
Thanks,
Miklos
> > +static inline void dput_path(struct path *path, struct nameidata *nd)
> > +{
> > + dput(path->dentry);
> > + if (path->mnt != nd->mnt)
> > + mntput(path->mnt);
> > +}
> > +
> > +static i
> On Tue, Aug 23, 2005 at 10:43:35PM +0200, Miklos Szeredi wrote:
> > 64 bit architectures all implement their own compatibility sys_open(),
> > when in fact the difference is simply not forcing the O_LARGEFILE
> > flag. So use the a common function instead.
>
> Tradi
in fact the difference is simply not forcing the O_LARGEFILE
flag. So use the a common function instead.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
Index: linux/include/linux/fs.h
===
--- linux.orig/include/linux/fs.h
401 - 500 of 2936 matches
Mail list logo
