Re: ipcrm/shmctl failure
I replied privately to Terry, but I perhaps should have mentioned also that some of these segments were days old and they were definitely not in use by any process. I logout at the end of every day. [EMAIL PROTECTED] writes: }All you are doing is marking the segment as removed. The segment }remains attached by the processes which have it open, and those }references don't go awaya until the processes in question detach }the segments, and the reference count goes to zero. } }In other words, shared memory segments are like files; you can't }delete them out from under programs that still hold references }to them. [ snip ] Callum Gibson [EMAIL PROTECTED] Global Markets IT, Deutsche Bank, Australia 61 2 9258 1620 ### The opinions in this message are mine and not Deutsche's ### To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipcrm/shmctl failure
On Tue, 9 Apr 2002 [EMAIL PROTECTED] wrote: I replied privately to Terry, but I perhaps should have mentioned also that some of these segments were days old and they were definitely not in use by any process. I logout at the end of every day. Have you tried ipcs -p? Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote: [snip] It's arguable that / and /usr themselves should be mounted read-only, It's not very practical to have / read-only on a truely multi-user (the only time this linking stuff is much of an issue) 4-STABLE system. The two main reasons being /etc/master.passwd, et al, and the problems with a read-only /dev. It takes extensive customizations and kludges to get this to work. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipcrm/shmctl failure
[EMAIL PROTECTED] wrote: I replied privately to Terry, but I perhaps should have mentioned also that some of these segments were days old and they were definitely not in use by any process. I logout at the end of every day. Logging out does not necessarily stop all processes, or remove the mapping. Note that there was some confusion about shm_open(3), which is totally unrelated to the ipcs/ipcrm/shmat/shmdt/etc. code. I think this is probably a bug in the Linux emulator resource tracking on abort/exit for system V shared memory, since it's a Linux program causing the problem. In any case, disabling the use of the MIT SHM extension for X will make the problem go away by making it not use shared memory segments. You can either do this golbally, with an option to the X server, or you can do it on a program-by-program basis by setting the DISPLAY environment variable so that it uses a real network connection, instead of a UNIX domain socket (and thus allows the use of the MIT SHM extension). E.g., per the previous post: setenv DISPLAY `hostname`:0.0 -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipcrm/shmctl failure
Andrew wrote: On Tue, 9 Apr 2002 [EMAIL PROTECTED] wrote: I replied privately to Terry, but I perhaps should have mentioned also that some of these segments were days old and they were definitely not in use by any process. I logout at the end of every day. Have you tried ipcs -p? I believe this will give incorrect information, as it's pretty obvious that any bug here has to be in the Linux ABI treatment of the _exit() resource tracking cleanup of the segments when a proce (or Linux thread) exits. The information -p gives is the last access. However, if what has happened is that all the programs have been stopped, and the reference count was not decremented by the Linux ABI code, then the last reference you will see is the already exited X server. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
Hi, At 11:41 08/04/02 -0700, Michael Smith wrote: On Mon, 8 Apr 2002, [ISO-8859-2] Pawe³ Jakub Dawidek wrote: Simple example why I think that only owner should have permission to create hardlinks to his files. ... I see you forgot to 'ls -l' the resultant link ... you'll find that it has the same permissions and ownership as the original file. Oops. You misunderstand the original poster's complaint. The issue is that a non-owner can cause the owner's file to remain alive even after the owner has deleted it. Hence the comment about later breakin. You could also use this technique to maliciously exhaust a user's quota, by linking to their temporary files. I'm not sure what the standards have to say about this, but I don't much like the current behaviour. If you have any permissions on the file, you can prolong its life without a link simply by having a process open it. This is 'better' as a DOS because it's harder to spot. -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED]fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[no subject]
subscribe freebsd-hackers [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipcrm/shmctl failure
At 8:45 PM +1000 4/9/02, [EMAIL PROTECTED] wrote: Please don't make me use the kernel debugger... waa I believe Terry suggested: ...set the DISPLAY environment variable so that it uses a real network connection, instead of a UNIX domain socket (and thus allows the use of the MIT SHM extension). E.g., per the previous post: setenv DISPLAY `hostname`:0.0 I (personally would try that, and see what effect it had, before I would dive into a kernel debugger! Maybe it will have no effect, but even then you will at least have eliminated this issue from the discussion. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipcrm/shmctl failure
At 22:06 8-4-2002 -0700, Terry Lambert wrote: All you are doing is marking the segment as removed. The segment remains attached by the processes which have it open, and those references don't go awaya until the processes in question detach the segments, and the reference count goes to zero. It turns out that these segments are not proerly reference counted and tracked, so they are not deleted when the client goes away. This is a bug in the MIT shared memory extension for X design, and can't be fixed for long running programs with lots of bitmaps. I'd like to take a step further and say it's in SYSVSHM design. All a program has to do is forget to do a shm_detach() and you're f#$%ed. Be glad it's just a few bitmaps, and not a 250 meg segment like I had with a certain version of Oracle. It's an X11 question, and it's been that way since at least 1994, so it's a long standing X11 FAQ. You could say that X11 shouldn't use SHMs the way it does now yeah. =) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
subsribe for email address deepti@nttmcl.com
To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
On Tue, 9 Apr 2002, Terry Lambert wrote: Crist J. Clark wrote: On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote: [snip] It depends. If this is a truly multiuser environment, then you are probably getting your authentication from NIX or RADIUS. It's really arguable that /etc should be a nullfs mount off of somewhere else and/or variable information belongs in var or some other place... Sun has been able to do this since 1988 or so (at least). As terry knows of course, the Interjet had the following /etc/symlinks: (excuse linewrap) lrwxrwxrwx 1 root wheel 20 Mr 28 2001 crontab@ - /writable/system/crontab lrwxrwxrwx 1 root wheel 18 Mr 28 2001 group@ - /writable/system/group lrwxrwxrwx 1 root wheel 22 Mr 28 2001 localtime@ - /writable/system/localtime lrwxrwxrwx 1 root wheel 3 Mr 28 2001 malloc.conf@ - A lrwxrwxrwx 1 root wheel 26 Mr 28 2001 master.passwd@ - /writable/system/master.passwd lrwxrwxrwx 1 root wheel 19 Mr 28 2001 pwd.db@ - /writable/system/pwd.db lrwxrwxrwx 1 root wheel 28 Mr 28 2001 resolv.conf@ - /writable/server/dns/resolv.conf lrwxrwxrwx 1 root wheel 31 Mr 28 2001 sendmail.cf@ - /writable/mail/sendmail/sendmail.cf lrwxrwxrwx 1 root wheel 20 Mr 28 2001 spwd.db@ - /writable/system/spwd.db the single root+usr partition is mounted read-only. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipcrm/shmctl failure
Rogier R. Mulhuijzen wrote: This is a bug in the MIT shared memory extension for X design, and can't be fixed for long running programs with lots of bitmaps. I'd like to take a step further and say it's in SYSVSHM design. All a program has to do is forget to do a shm_detach() and you're f#$%ed. Heh. I could make the same argument about open... Be glad it's just a few bitmaps, and not a 250 meg segment like I had with a certain version of Oracle. It's an X11 question, and it's been that way since at least 1994, so it's a long standing X11 FAQ. You could say that X11 shouldn't use SHMs the way it does now yeah. =) The real problem is that over the UNIX domain socket, it doesn't get client disconnect notificiations necessary for resource tracking, AND browser use of these resources is practically the degenerate case. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
Julian Elischer wrote: As terry knows of course, the Interjet had the following /etc/symlinks: (excuse linewrap) lrwxrwxrwx 1 root wheel 20 Mr 28 2001 crontab@ - /writable/system/crontab lrwxrwxrwx 1 root wheel 18 Mr 28 2001 group@ - /writable/system/group [ ... ] the single root+usr partition is mounted read-only. Yes, but appealing to a product I had something to do with, even if that organization wasn't mine in particular, makes a much less powerful argument. The other thing that's a bit painful about that argument is that the symlinks failed to operate as expected for the master.passwd, if the / was mounted read/write. I count this as a bug in the password database generation code, but it should be noted that it can be a problem (e.g the symlink is renamed to the backup, and the replacement file is created in /etc; it does the right thing, if the symlink is read-only, though...). 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipcrm/shmctl failure
I have a theory (and a patch) if you're willing to hear it.
[EMAIL PROTECTED] writes:
} I'd like to take a step further and say it's in SYSVSHM design. All a
} program has to do is forget to do a shm_detach() and you're f#$%ed.
}Heh. I could make the same argument about open...
Except that the kernel seems to keep track of file handles ok.
} You could say that X11 shouldn't use SHMs the way it does now yeah. =)
}The real problem is that over the UNIX domain socket, it doesn't
}get client disconnect notificiations necessary for resource tracking,
}AND browser use of these resources is practically the degenerate case.
I think you're right about the linux stuff. It looks that you _will_ get
an EINVAL on a valid shmid if it has already been marked for deletion
(but presumably still exists due to references). Using the -o to ipcs
I see there are existing references (why didn't anyone suggest that
before) - but these are by non existent processes.
I'm now pretty sure this is caused by the linux implementation of
threads which uses multiple processes instead of a single proces. Now
vm_fork() (vm/vm_glue.c) calls shmfork which increments the shm ref count
for the forked process but this _shouldn't_ get called when rfork is
called with RFMEM (which is what linux_clone() does). So, turning to
the exit side of things, sys_exit() calls exit1() which only calls
shmexit to decrement the count if vm_refcnt == 1. Ok, rfork(RFMEM)
increments vm_refcnt in vm_fork(), and it may be decremented in
vmspace_unshare() or vmspace_free(). However as best I can see, nothing
in exit1() calls any vm stuff unless vm_refcnt is already 1. So unless
someone can point out where I've missed the call, I think the fix is
something like:
--- kern_exit.c.origFri Dec 14 14:33:50 2001
+++ kern_exit.c Wed Apr 10 13:16:01 2002
@@ -218,6 +218,8 @@
VM_MAXUSER_ADDRESS);
(void) vm_map_remove(vm-vm_map, VM_MIN_ADDRESS,
VM_MAXUSER_ADDRESS);
+ } else {
+ vmspace_free(vm);
}
if (SESS_LEADER(p)) {
This will decrement the vm_refcnt for exiting rfork'd processes and allow
the final exit to do all the appropriate cleanup, including the shmexit.
linux-mozilla would be a pretty heavy thread user. If only linux threads
was posix compliant, eh (I know Terry has commented on this before).
Callum Gibson [EMAIL PROTECTED]
Global Markets IT, Deutsche Bank, Australia 61 2 9258 1620
### The opinions in this message are mine and not Deutsche's ###
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: ipcrm/shmctl failure (fix found)
FWIW, This has been fixed in current, kern/kern_exit.c revision 1.147. Someone should MFC it. Callum Gibson [EMAIL PROTECTED] Global Markets IT, Deutsche Bank, Australia 61 2 9258 1620 ### The opinions in this message are mine and not Deutsche's ### To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
floppy install problem from cdrom on adaptec-2940 (ahc)
Hey Hackers, I'm new to the BSD world, and wanted to install 4.5-Stable. I downloaded the ISO, made the floppies and ran into a snag: Hard drive is an IDE and the CDROM is SCSI on an Adaptec 2940 (ahc). It appears (i would love to be wrong) that the Boot floppies only have support for the aha (15x0) cards, and I can't get access to the install media. The card is listed as an unknown device. Question : Is there another boot floppy image around with this driver? Hoping to convert, TIA, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
On Tue, Apr 09, 2002 at 04:42:52PM -0700, Terry Lambert wrote: Julian Elischer wrote: As terry knows of course, the Interjet had the following /etc/symlinks: (excuse linewrap) lrwxrwxrwx 1 root wheel 20 Mr 28 2001 crontab@ - /writable/system/crontab lrwxrwxrwx 1 root wheel 18 Mr 28 2001 group@ - /writable/system/group [ ... ] the single root+usr partition is mounted read-only. Yes, but appealing to a product I had something to do with, even if that organization wasn't mine in particular, makes a much less powerful argument. The other thing that's a bit painful about that argument is that the symlinks failed to operate as expected for the master.passwd, if the / was mounted read/write. I count this as a bug in the password database generation code, but it should be noted that it can be a problem (e.g the symlink is renamed to the backup, and the replacement file is created in /etc; it does the right thing, if the symlink is read-only, though...). Exactly, you can't use symlinks with the passwd(1) and pwd_mkdb(8) commands as they stand. The commands will bail when they try to create a temporary file in /etc, /etc/pw.XX if /etc is read-only. If /etc is not read-only, the symlinks will get removed and the files actually written in /etc. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
