Re: [Patch 04/18] include/linux/logfs.h
On Tue, 2007-06-05 at 20:49 +0200, Segher Boessenkool wrote:
It would be better if GCC had a 'nopadding' attribute which gave us
what we need without the _extra_ implications about alignment.
That's impossible; removing the padding from a struct
_will_ make accesses to its members unaligned (think
about arrays of that struct).
It _might_ make accesses to _some_ of its members unaligned.
It _will_ make accesses to _at least one_ of the members
unaligned, in the second array element.
It _might_, but not necessarily.
Won't a simple struct { uint16_t } get padded to a size of 4 bytes on
ARM? Even if I'm misremembering that, I certainly can't guarantee that
such a thing will _never_ happen on any newly-invented ABI. If you had
'nopadding' instead of 'packed', then there's no need to emit code to
handle unaligned loads.
Likewise, with a struct which looks like this:
{ uint32_t, uint16_t, uint16_t, uint32_t, uint32_t }
I cannot _guarantee_ that there will never be an architecture on which
we'll end up using 32 bits of space for each uint16_t. I might _guess_
that and hope, but that's precisely the kind of moronic empirical
behaviour which caused Linux to have so many problems with newer
compilers in the past. If it isn't _guaranteed_ then I shouldn't be
assuming it.
Thus, I want a way to tell the compiler not to insert _any_ padding. But
without the compiler making extra inferences about the whole thing being
found at arbitrary alignments.
And if I had something like this (which is admittedly contrived, but
hardware people _do_ do stupid things to us):
{ uint32_t, uint8_t, uint16_t, uint8_t, uint32_t, uint32_t }
With the 'packed' attribute the compiler would assume arbitrary
alignment of all the 32-bit integers. But in reality it's only necessary
for the uint16_t in the middle. A 'nopadding' attribute would deal with
that correctly.
--
dwmw2
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] CIFS: make cifsd (more) signal-safe
On Tue, Jun 05, 2007 at 03:23:40PM -0400, Jeff Layton wrote: I recently sent a similar, smaller patch for this problem. After some discussion with Steve and Shaggy, I think I better understand why cifsd allows signals through, and I realize that my earlier patch wasn't comprehensive enough The mount and unmount calls will send a KILL signal to cifsd to wake it up if it happens to be blocked in kernel_recvmsg. The problem is that it doesn't distinguish between legitimate signals sent for this reason and spurious signals sent by a userspace process (for instance). While this is definitely a don't do that sort of situation, we might as well try to have cifsd be as signal-safe as possible. The following patch does this by making sure that we set tcpStatus to CifsExiting before sending cifsd a signal, and having cifsd check for that when it sees that it's been signalled. If the tcpStatus is not set correctly, it ignores it, flushes signals and moves on. I've tested a similar backported version of this on an earlier kernel, but have not tested this particular patch as of yet. The right way to fix this is to stop sending signals at all and have a kernel-internal way to get out of kernel_recvmsg. Uses of signals by kernel thread generally are bugs. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 04/18] include/linux/logfs.h
David Woodhouse [EMAIL PROTECTED] writes:
Won't a simple struct { uint16_t } get padded to a size of 4 bytes on
ARM? Even if I'm misremembering that, I certainly can't guarantee that
such a thing will _never_ happen on any newly-invented ABI. If you had
'nopadding' instead of 'packed', then there's no need to emit code to
handle unaligned loads.
You can add aligned(N) to increase the alignment again.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 05/18] fs/logfs/logfs.h
On Wed, 6 June 2007 12:29:13 +0100, Paulo Marques wrote: Jörn Engel wrote: --- /dev/null2007-03-13 19:15:28.862769062 +0100 +++ linux-2.6.21logfs/fs/logfs/logfs.h 2007-06-03 19:34:07.0 +0200 @@ -0,0 +1,398 @@ +/* + * fs/logfs/logfs.h + * + * As should be obvious for Linux kernel code, license is GPLv2 + * + * Copyright (c) 2005-2007 Joern Engel + * + * Private header for logfs. + */ +#ifndef fs_logfs_logfs_h +#define fs_logfs_logfs_h + +#define __CHECK_ENDIAN__ + + +#include linux/crc32.h +#include linux/fs.h +#include linux/kallsyms.h Including kallsyms.h is not really needed in this header file, is it? Another piece of historic cruft to remove. Thanks for spotting. Jörn -- Joern's library part 5: http://www.faqs.org/faqs/compression-faq/part2/section-9.html - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 05/18] fs/logfs/logfs.h
Jörn Engel wrote: --- /dev/null 2007-03-13 19:15:28.862769062 +0100 +++ linux-2.6.21logfs/fs/logfs/logfs.h 2007-06-03 19:34:07.0 +0200 @@ -0,0 +1,398 @@ +/* + * fs/logfs/logfs.h + * + * As should be obvious for Linux kernel code, license is GPLv2 + * + * Copyright (c) 2005-2007 Joern Engel + * + * Private header for logfs. + */ +#ifndef fs_logfs_logfs_h +#define fs_logfs_logfs_h + +#define __CHECK_ENDIAN__ + + +#include linux/crc32.h +#include linux/fs.h +#include linux/kallsyms.h Including kallsyms.h is not really needed in this header file, is it? I don't have time / knowledge to review the rest of the code, but I always keep an eye out for kallsyms usage... -- Paulo Marques - www.grupopie.com Very funny Scotty. Now beam up my clothes. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 04/18] include/linux/logfs.h
On Wednesday 06 June 2007, David Woodhouse wrote:
And if I had something like this (which is admittedly contrived, but
hardware people _do_ do stupid things to us):
{ uint32_t, uint8_t, uint16_t, uint8_t, uint32_t, uint32_t }
With the 'packed' attribute the compiler would assume arbitrary
alignment of all the 32-bit integers. But in reality it's only necessary
for the uint16_t in the middle. A 'nopadding' attribute would deal with
that correctly.
I would argue that a newly invented 'nopadding' attribute should reject
such a structure as invalid, because it should not let members be
unaligned. Unfortunately, this also gets tricky if you consider
struct {
uint32_t a;
uint64_t b;
uint32_t c;
};
which does have an unaligned member by default in i386, but not on
any modern platform.
Arnd
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote: On Monday 04 June 2007 15:12, Pavel Machek wrote: How will kernel work with very long paths? I'd suspect some problems, if path is 1MB long and I attempt to print it in /proc somewhere. Pathnames are only used for informational purposes in the kernel, except in AppArmor of course. I don't mean this as a flame, but isn't the above statement the very crux of this discussion? Why should AppArmor be different from the rest of the kernel in its usage of pathnames (basis for decisions vs. informational reporting to userspace)? And if it is ok for AppArmor to generate and use pathnames as its basis of decisions on each open, then is it also ok for audit, inotify, and others to use them in the same manner? If the audit developers or inotify developers had come with patches that used d_path or equivalent in the same manner as AppArmor, don't you think they would have gotten the same resistance? And if you are truly trying to create a mechanism (in AppArmor) that you can ultimately apply widely to the system (going beyond AppArmor's original limited focus on a small set of network-facing daemons), aren't you concerned about the implications of having to generate a pathname on each open just to decide what to do? Is this really the path you want to take ;)? Another question: it seems like the read-only bind mount folks gave up on propagating the vfsmounts down and switched to a rather different approach (checking near the entry points, using mount writer counters). So similarly, what makes AppArmor fundamentally different that it wouldn't take a similar approach to what they are doing vs. propagating the vfsmounts down? Or do you think they made the wrong choice? If so, why? Just trying to understand your position better... -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote: On Tuesday 15 May 2007 11:20, Pavel Machek wrote: Hi! Pathname matching, transition table loading, profile loading and manipulation. So we get small interpretter of state machines, and reason we need is is 'apparmor is misdesigned and works with paths when it should have worked with handles'. I assume you mean labels instead of handles. AppArmor's design is around paths not labels, and independent of whether or not you like AppArmor, this design leads to a useful security model distinct from the SELinux security model (which is useful in its own ways). The differences between those models cannot be argued away, neither is a subset of the other, and neither is a misdesign. I would be thankful if you could stop spreading this lie. I have a hard time distinguishing AppArmor's model from its implementation; every time we suggest that one might emulate much of AppArmor's functionality on SELinux (as in SEEdit), someone points to a specific characteristic of the AppArmor implementation that cannot be emulated in this manner. But is that implementation characteristic an actual requirement or just how it happens to have been done to date in AA? And I get the impression that even if we extended SELinux in certain ways to ease such emulation, the AA folks would never be satisfied because the implementation would still differ. Can we separate the desired functionality and actual requirements from the implementation specifics? If you solve the 'new file problem', aa becomes subset of selinux. And I'm pretty sure patch will be nicer than this. You are quite mistaken. SELinux turns pathnames into labels when it initially labels all files (when a policy is rolled out), whereas AppArmor computes the label of each file when a file is opened. The two models start to diverge as soon as files are renamed: in SELinux, labels stick with the files. In AppArmor, labels stick with the names. I'd argue a bit with that characterization, given that: - in the case of SELinux, the pathname is never used as a basis for decisions by the kernel, - under AA, each file may have an arbitrary set of labels or policies applied to it depending on what programs are accessing it and what names are being used to reference it - there is no system view of the subjects and objects and thus no way to identify the overall system policy for a given file. - names are far less tranquil than labels. So what you advocate for is a hybrid between the SELinux and the AppArmor model, not a superset. It could be that the SELinux folks will solve the issues they are having with new files using something better than restorecond in the future, perhaps even an in-kernel mechanism (although I somewhat doubt it). But then again, their basic model makes sense even without any live file relabeling, and so that's probably not very high up on the priority list. Live file relabeling (non-tranquility) tends to break one's ability to show anything about preservation of confidentiality or integrity (particularly in the absence of complete revocation support). On the new files issue, it wouldn't be difficult or even a real divergence from our existing model to introduce the component name (not a full pathname, but the last component) as an additional input to the decision for labeling new files (along with the existing use of the creating process' label, the parent directory label, and the kind of new file) at creation time, and that would reduce the need somewhat to modify some applications that create files of multiple security contexts in the same directory. That would further help the SEEdit folks in emulating AA on top of SELinux, but as before, I don't get the impression that the AA folks will ever be satisfied with such an emulation, not because of any real requirement but merely because they are tied to their implementation specifics. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On Thu, 2007-05-31 at 18:29 +0200, Miklos Szeredi wrote: I started working on adding support for unprivileged mounts[1] to util-linux. The big obstacle seems to be the reliance on /etc/mtab, since that won't be kept up-to-date after mount(2) or umount(2) calls by unprivileged users. snip ... Can someone think of any other problem with getting rid of /etc/mtab? This presents a couple of problems for autofs, version 5. First, autofs will function if /etc/mtab is a symlink to /proc/mounts (or better if we could mount /proc/mounts as the file /etc/mtab). There are however two problems, first for people that have a large number of mounts, particularly direct mounts, the listing of mounts would be terrible. An implementation of automount on an old version of AIX did this and it was just about impossible to tell what mounts where present besides the autofs internal mounts. Solaris uses a mount option, hide or hidden or something which prevents them from being listed and that works fine. We would need to do something like that in all the utilities that read /etc/mtab. The second, and also maybe not such a big issue, is that if there are many autofs entries to read through this has the potential to kill autofs performance for mounting, expiring and checking if something is mounted, whether the entries have a hidden flag or not utilities will still need to read through all the entries. The same performance issue applies for all the utilities that read the mount table. I'd expect a typical small to medium site that makes wide use of direct mounts to have between 500 and 1000 entries in their maps, and so 500 - 1000 autofs direct mount triggers, similar to Solaris. Also, people that have large filers with many exports will have many internal autofs mounts if using the commonly used hosts map, we use a different implementation for this than Solaris so there are less internal autofs mounts than in Solaris, but still many. Ideas? Ian - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] unionfs section mismatch
From: Randy Dunlap [EMAIL PROTECTED]
Fix section marker in header file:
WARNING: fs/unionfs/unionfs.o(.init.text+0x56): Section mismatch: reference to
.exit.text:stop_sioq (between 'init_module' and 'init_sioq')
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
fs/unionfs/sioq.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.22-rc4-mm1.orig/fs/unionfs/sioq.h
+++ linux-2.6.22-rc4-mm1/fs/unionfs/sioq.h
@@ -76,7 +76,7 @@ struct sioq_args {
/* Extern definitions for SIOQ functions */
extern int __init init_sioq(void);
-extern __exit void stop_sioq(void);
+extern void stop_sioq(void);
extern void run_sioq(work_func_t func, struct sioq_args *args);
/* Extern definitions for our privilege escalation helpers */
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] unionfs section mismatch
On Wed, Jun 06, 2007 at 02:51:02PM -0700, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Applied. Thanks. Josef Jeff Sipek. -- Don't drink and derive. Alcohol and algebra don't mix. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
