Re: symlink_prefix
In article <[EMAIL PROTECTED]>, Hank Leininger <[EMAIL PROTECTED]> writes: > On 2001-06-03, [EMAIL PROTECTED] wrote: > >> Suppose I have devices /dev/a, /dev/b, /dev/c that contain the >> /, /usr and /usr/spool filesystems for FOO OS. Now >> mount /dev/a /mnt -o symlink_prefix=/mnt >> mount /dev/b /mnt/usr -o symlink_prefix=/mnt >> mount /dev/c /mnt/usr/spool -o symlink_prefix=/mnt > > Cool. > > What happens when someone creates new absolute symlinks under /mnt ? > Will/should the magic /mnt/ header be stripped from any symlink created > under such a path-translated volume? The answer is probably 'yes', but > either one violates POLA :( > I think the semantics should be these that are used in the old usespace nfsd for the "link_relative" option. That one had very intuitive semantics and behaved sanely even if you had insane recursive machine crossmounts - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with "su -" and kernels 2.4.3-ac11 and higher
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> writes:
>> > Did you try nesting more than one "su -"? The first one after a boot
>> > works for me - every other one fails.
>>
>> Same here: the first "su -" works OK, but a second nested one hangs:
>
> It appears to be a bug in PAM. Someone seems to reply on parent/child running
> order and just got caught out
>
I once debugged a very simular sounding problem that I solved with
the following patch to login. It's a wild guess, but you could try if
it happens to solve it. If not it might at least be a hint of what has to
be done to su.
(the problem is that the extra process PAM keeps waiting is process leader)
(I don't have redhat, so I can't check if this is relevant here)
diff -ur util-linux-2.9x/login-utils/login.c util-linux-2.9x-ton/login-utils/login.c
--- util-linux-2.9x/login-utils/login.c Sun Sep 12 23:25:30 1999
+++ util-linux-2.9x-ton/login-utils/login.c Tue Sep 21 03:24:52 1999
@@ -1109,6 +1112,15 @@
exit(0);
}
/* child */
+
+if (tcsetpgrp(0, getpid()) < 0)
+fprintf(stderr,
+_("login: could not become foreground process group: %s\n"),
+strerror(errno));
+if (setpgid(0, 0) < 0)
+fprintf(stderr, _("login: could not become process leader: %s\n"),
+strerror(errno));
+
#endif
signal(SIGINT, SIG_DFL);
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: IP Acounting Idea for 2.5
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> writes: >> > No he isnt confused, you are trying to dictate policy. >> >> What then *is* the policy? > > The policy is not to have policy. It works as well in kernel design as politics. > > Alan > Since my job is in fact mainly this kind of apps, i really feel strongly about this. Resettable counters are evil. Having resettable counters may not sound like it, but it is in fact policy. It forces all apps to add code to detect these resets (and then give warnings/errors, since there is just no way to do anything sensible with them), since ignoring them will seemingly cause up to 2**32 counts suddenly. It is also doing something in kernelspace which can be done in userspace, which is normally considered a big nono. Proposal: have a snapshot command, that remembers the current value of a counter. Then have two interfaces: one that shows the continuous counter and one that shows the subtraction of the current value from the snapshot. The first can be used by used by serious applications (don't have to add code to give warnings about dataloss), and the second can be used by users who want to watch the counters a bit to get a feel for what a rule is doing. I really think cisco got this right: from the commandline interface you can reset counters, and watch them, the SNMP counters however just keep going and going and going independently from this. (I think this snapshotting belongs in the apps reading the counters really, but if you really insist on a kernel based reset, this might be reasonable). - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Another rsync over ssh hang (repeatable, with 2.4.1 on both ends)
Notice also that by default ssh opens stdin/stdout blocking, and can
relatively easily deadlock if the pipes it talks over really want to do
a write before a read or the other way round.
You can try compile the following file, put it in the same directory
as ssh, and then run rsync over this instead of plain ssh (I use it in
fact in all places where I connect to ssh over pipes).
#include
#include
#include
#include
#ifndef HAVE_NO_UNISTD_H
# include
#endif /* HAVE_NO_UNISTD_H */
#include
static char ssh[] = "ssh";
int unblock(FILE *fp) {
int fd, rc, flags;
fd = fileno(fp);
if (isatty(fd)) return 0;
flags = fcntl(fd, F_GETFL, 0);
if (flags < 0) {
fprintf(stderr, "Could not query fd %d: %s\n", fd, strerror(errno));
return 1;
}
rc = fcntl(fd, F_SETFL, flags | O_NONBLOCK);
if (rc < 0) {
fprintf(stderr, "Could not unblock fd %d: %s\n", fd, strerror(errno));
return 1;
}
return 0;
}
int main(int argc, char **argv) {
int rc;
char *ptr, *work;
if (unblock(stdin)) return 1;
if (unblock(stdout)) return 1;
if (unblock(stderr)) return 1;
ptr = strrchr(argv[0], '/');
if (ptr == NULL) ptr = argv[0];
else ptr++;
work = malloc(ptr-argv[0]+sizeof(ssh));
if (!work) {
fprintf(stderr, "Out of memory. Buy more ?\n");
return 1;
}
memcpy(work, argv[0], ptr-argv[0]);
memcpy(work+(ptr-argv[0]), ssh, sizeof(ssh));
argv[0] = work;
rc = execvp(work, argv);
fprintf(stderr, "Could not exec %.300s: %s\n", work, strerror(errno));
return rc;
}
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
In article <[EMAIL PROTECTED]>, Steve VanDevender <[EMAIL PROTECTED]> writes: > Ton Hospel writes: > > In article <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] writes: > > > I am afraid I have missed most earlier messages in this thread. > > > However, let me remark that the problem of assigning a > > > file descriptor is the one that is usually described by > > > "priority queue". The version of Peter van Emde Boas takes > > > time O(loglog N) for both open() and close(). > > > Of course this is not meant to suggest that we use it. > > > > > Fascinating ! But how is this possible ? What stops me from > > using this algorithm from entering N values and extracting > > them again in order and so end up with a O(N*log log N) > > sorting algorithm ? (which would be better than log N! ~ N*logN) > > > > (at least the web pages I found about this seem to suggest you > > can use this on any set with a full order relation) > > How do you know how to extract the items in order, unless you've already > sorted them independently from placing them in this data structure? Because "extract max" is a basic operation of a priority queue, which I just do N times. > > Besides, there are plenty of sorting algorithms that work only on > specific kinds of data sets that are better than the O(n log n) bound > for generalized sorting. For example, there's the O(n) "mailbox sort". > You have an unordered array u of m integers, each in the range 1..n; > allocate an array s of n integers initialized to all zeros, and for i in > 1..m increment s[u[i]]. Then for j in 1..n print j s[j] times. If n is > of reasonable size then you can sort that list of integers in O(m) time. Yes, I know. that's why you see the "any set with a full order relation" in there. That basically disallows using extra structure of the elements. Notice that the radix sort you describe basically hides the log N in the the representation of a number of max n (which has a length that is basically log n). It just doesn't account for that because we do the operation on processors where these bits are basically handled in parallel, and so do not end up in the O-notation. Any attempt to make radix sort handle arbitrary width integers on a fixed width processor will make the log N reappear. Having said that, in the particular case of fd allocation, we DO have additional structure (in fact, it's indeed integers in 0..n). So I can very well imagine the existance of a priority queue for this where the basic operators are better than O(log N). I just don't understand how it can exist for a generic priority queue algorithm (which the Peter van Emde Boas method seems to be. Unfortunately I have found no full description of the algorithm that's used to do the insert/extract in the queue nodes yet). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: > > I am afraid I have missed most earlier messages in this thread. > However, let me remark that the problem of assigning a > file descriptor is the one that is usually described by > "priority queue". The version of Peter van Emde Boas takes > time O(loglog N) for both open() and close(). > Of course this is not meant to suggest that we use it. > Fascinating ! But how is this possible ? What stops me from using this algorithm from entering N values and extracting them again in order and so end up with a O(N*log log N) sorting algorithm ? (which would be better than log N! ~ N*logN) (at least the web pages I found about this seem to suggest you can use this on any set with a full order relation) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: multiple mount of devices possible 2.4.0-test1 - 2.4.0-test13-pre4
In article <[EMAIL PROTECTED]>, Alexander Viro <[EMAIL PROTECTED]> writes: > On Sat, 30 Dec 2000, Ton Hospel wrote: > >> It should still need a special flag or something, since it's >> impossible for userspace to check this atomically. > > To check _what_? Having the same tree mounted in several places is > allowed. End of story. Atomicity of any kind is a non-issue - if you > have processes that do not cooperate and do random mounts you are > getting exactly what you are asking for. > I wasn't talking about mounting the same device on different mount points. If you ask for that, it's good that you nowadays you can get that (though even there it might be a good idea to let the filesystem say if it can support that or not) I was talking about avoiding that the same device gets multiple mounted at the SAME place, e.g. when doing mount -a, which is often used as a quick way to get the new entries in /etc/fstab That would also be no problem if there were a standard about e.g. always flocking /etc/mtab. But as far as I know there isn't such a standard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: multiple mount of devices possible 2.4.0-test1 - 2.4.0-test13-pre4
In article <[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]> writes: > On Sat, 23 Dec 2000 [EMAIL PROTECTED] wrote: >> >> 1. multiple mount of devices possible 2.4.0-test1 - 2.4.0-test13-pre4 >> >> 2. its still possible to mount devices several times. >>IMHO it shouldnt be possible like 2.2.18 > > No. > > The multi-mount thing is a _major_ feature, and the fact that your "mount" > binary seems to be confused by it is a user-level problem and nothing > more. > It should still need a special flag or something, since it's impossible for userspace to check this atomically. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
