5.3 scheduler problem reborn in 5.4-rel-p5?
in searching for an answer to my problem, i came across this thread, to which there doesn't seem to have been a resolve: http://www.monkey.org/freebsd/archive/freebsd-hackers/200504/msg7.html i must say that my problem is almost identical, per my dump: http://undef.net/2005-08-02-dump.txt 'sio' is compiled into my kernel, although there was no serial in use at the time of my crash. FreeBSD juanita.undef.net 5.4-RELEASE-p5 FreeBSD 5.4-RELEASE-p5 #1: Mon Jul 25 14:26:34 PDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/JUANITA i386 need more details? thanks, -g -- Greg Albrecht ([EMAIL PROTECTED]) * -0700 GMT/UTC http://undef.net * +1 213 447 3089 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD desktop?
Hi, [EMAIL PROTECTED] wrote: At 08:10 AM 8/2/2005 +0200, Karel Miklav wrote: | [EMAIL PROTECTED] wrote: Thanks Karel. I got my FreeBSD desktop up and running. It's on X window and gnome. I am not sure about setting up the window manager, but may try that You have already one window manager running. Gnome uses its own default windows manager which name I forgot but can you many others. Just stick to it as long as you are happy with it. If you later feel that Gnome as a bit fat, you then can start using other Gnome compatible window managers. This gives you the option to switch between Gnome and your new window manager and it also gives you the option to tell Gnome to use that window manager. Get used now to your 'new' desktop and scout out what possibilities it has. Erich ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[Fwd: Porting FreeBSD NDIS to NetBSD/nmb_fddirxindicate_func()]
Oops, there is no [EMAIL PROTECTED] I hope this is the correct list for this message :-) Original Message Subject: Porting FreeBSD NDIS to NetBSD/nmb_fddirxindicate_func() From:"Alan Ritter" <[EMAIL PROTECTED]> Date:Tue, August 2, 2005 4:26 pm To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED] -- Hi, I'm trying to port the FreeBSD NDIS code to NetBSD as part of Google's "Summer of Code" project (http://code.google.com/summerofcode.html). I'm having a little problem right now, when the attach function calls ndis_init_nic(), which calls the MiniportInitalize() function from the binary Windows driver for my network card (I got this working on FreeBSD) it blows up on the following instruction: call DWORD PTR [eax+380] After playing around with the debugger a bit I'm quite certain that eax is a pointer to the ndis_miniport_block, and 380 is the offset of the nmb_fddirxindicate_func() field within it. All there is at this address, however is 0x0: (gdb) x/8a $eax + 380 0xc15b2d7c: 0x0 0x0 0x0 0x0 0xc15b2d8c: 0xc07459550xc07459ad 0x0 0xc0745a32 I'm assuming that this should have been initialized somewhere, but I can't find any place in the code where nmb_fddirxindicate_func() is referenced. Maybe it is supposed to be initialized inside the binary Windows driver? I also tried jumping past the offending instruction, and there appeared to be more calls to uninitialized functions in the ndis_miniport_block(). Anyway, I just thought I'd check and see if you knew more about the nmb_fddirxindicate_func() member of the ndis_miniport_block structure. Thanks. P.S. here's some pointers to more information: My blog for the project: http://ndis-netbsd.blogspot.com/ Links to my sources online: http://cvs.sourceforge.net/viewcvs.py/netbsd-soc/ndis/ The project's webpage: http://netbsd-soc.sourceforge.net/projects/ndis/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
How to do proper locking
Hi,
I am looking for a safe way to access structures that can be freed. The
solution I am looking for must not:
- hinder scaleability
- lead to use of a single lock
- lead to lock order reversal
Here is the solution I have landed on so far:
First I plan to make a reference count manager that has the following extern
functions:
u_int32_t *ref_alloc(); // will allocate a reference count
void ref_free(u_int32_t *); // will free a reference count and increment it.
// Note that the pointer passed to this function
// is still valid after its call
u_int32_t ref_atomic_read(u_int32_t *); // will read the value
// of a reference count
void ref_atomic_increment(u_int32_t *); // will increment the value
// of a reference count
Assume that we have the following structure:
struct my_struct {
struct mtx *p_mtx;
u_int32_t *p_ref;
u_int8_t my_data[256];
};
At some point this structure is allocated:
static struct my_struct *ptr;
mtx_lock(lock_A);
if(ptr == NULL)
{
ptr = malloc(...);
if(ptr)
{
ptr->p_ref = ref_alloc();
ptr->p_mtx = mtx_alloc();
}
}
mtx_unlock(lock_A);
At some other point it is freed:
mtx_lock(lock_A);
ptr_copy = ptr;
ptr = NULL;
mtx_unlock(lock_A);
if(ptr_copy)
{
mtx_lock(ptr_copy->p_mtx); // we want to hold this lock
// to block the callback while
// incrementing refcount
ref_free(ptr_copy->p_ref); // will increment the refcount
mtx_unlock(ptr_copy->p_mtx);
mtx_free(ptr_copy->p_mtx); // Note: mutex is still valid after this!
free(ptr_copy);
}
Then at the last point we want to access this structure, but we don't want to
hold "lock_A", but rather "ptr->p_mtx", to increase performance.
FIRST_PART:
mtx_lock(lock_A);
if(ptr)
{
p_ref_copy = ptr->p_ref;
ref_value = ref_atomic_read(ptr->p_ref);
p_mtx_copy = ptr->p_mtx;
}
else
{
p_ref_copy = NULL;
}
mtx_unlock(lock_A);
SECOND_PART:
if(p_ref_copy)
{
mtx_lock(p_mtx_copy);
if(ref_value == ref_atomic_read(p_ref_copy))
{
/* this structure is still allocated */
CALLBACK_CODE_HERE:
}
else
{
/* this structure has been freed */
}
mtx_unlock(p_mtx_copy);
}
To access a memory structure safely, one needs three parameters, according to
my theory: "p_ref_copy", "ref_value", "p_mtx_copy". Then I thought that one
might prestore these, so that the "FIRST_PART" can be skipped, left with only
the "SECOND_PART". Then I thought that the "SECOND_PART" could be implemented
by existing callbacks, so that we stay out of trouble.
Any comments ?
(Hence todays computers are so fast, one might want to use a 64-bit reference
count. So after some billion years my model will fail, but one will probably
reboot long before that :-)
--HPS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d/tmp (silly mkdir usage)
On Tue, 2 Aug 2005 11:47:19 -0500 (CDT) [EMAIL PROTECTED] wrote: > "When all you've got is a hammer, everything looks like a nail." Sorry, maybe it didn't have to be said. I tried, though, I did. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: booting gbde-encrypted filesystem
On Tue, Aug 02, 2005 at 10:30:22AM +0800, Ronnel P. Maglasang wrote: > What I had in mind is perhaps I could find a way to > enter the passphrase at the loader prompt, or configure > the loader to get the passphrase from an external > device or hardcoded the passphrase in the bootloader(really > insecure). I understand you model which is to have something required to ensure the disks cannot be read w/o physical token. Theoretically the loader could allow you to fetch some memory address and insert it into a boot variable. If you just want to ensure a token is required to enable access to a machine you could add something in the root-FS patch which reads directly from the hardware device, though this is before the full device infrastructure is bootstrapped IRC. What about the idea of adding support for HSM and TPMs? Hardware keystores and other similar authentication mechanisms which push a key into a secure memory accessible by the crypto API might be the answer. I am looking at similar solutions. My idea is to enable remote authentication through a secure means. So there are multiple options: to secure console access. * Some IPMI hardware has an ethernet accessible console, that can then be routed through a secure tunnel. * There is the idea of ethercons if it can be extended to support encryption. * A serial console can be accessed through another machine securely This one has been around since a few years back, but the below patch brings it closer to being workable. > Alexander Leidinger wrote: > > >Pawel Jakub Dawidek <[EMAIL PROTECTED]> wrote: > > > >>This is not not possible with current GBDE. > >>I've patches which allows this here: > >> > >>http://people.freebsd.org/~pjd/patches/gbde.patch > > > > > >I fail to see how this allows an encryted root-FS, it doesn't add gbde > >support to boot0(ext) or to the loader. It needs access to an unencrypted > >kernel. I don't think this is what Ronnel had in mind (overlooking the > >fact > >that his suggestion to save the passphrase in the loader is insecure). An unencrypted kernel can be read off of another device and then used to mount the encrypted root. > >Bye, > >Alexander. > > -- Allan Fields (afields) - Ottawa, Canada (45"10'N 75"56'W) Himeji Systems http://himejisystems.com Afields Research/AFRSL http://afields.ca pgpCmMZ2DX9RW.pgp Description: PGP signature
GTK+
Does anyone on the hackers list develop in GTK+ ? I was thinking about trying my hand at some applications for BSD and would like to make contact with anyone else who programs for FreeBSD using the GTK frame work. Thanks. Ray ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d/tmp (silly mkdir usage)
Sigh, that's what I get for editing before I finish writing. On Tue, Aug 02, 2005 at 12:44:45PM -0500, Craig Boston wrote: > It's a very remote chance yes, but why ...but why take that chance when mkdir works perfectly fine? Chances are mkdir will be used at some point during the rc.d startup anyway, so forking a process for an executable in the cache (or bringing it into the cache so it can be used later) is a negligible performance loss, especially when it only happens once. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d/tmp (silly mkdir usage)
On Tue, Aug 02, 2005 at 11:47:19AM -0500, [EMAIL PROTECTED] wrote: > Well these notions have nothing todo with the way it works, but they are > interesting still. I would imagine a dir could be linked too if somebody > managed to insert a rc.d script in that was ordered sufficiently early > enough to do the evil tasks you are thinking about. Even if mktemp(1) were > available at this stage, I wouldn't use it here. A link could also be left over from before the boot. rc.d/tmp runs before cleartmp. > Let me be clear about this, the ONLY reason mkdir is used here is > because touch is under /usr somewhere which isn't even mounted at this > point (assuming /usr is mounted seperatly, as is the case on nfs > diskless systems). No, touch has different behavior than mkdir. Whether it was done intentionally or just happens to be the case because /usr is not available, mkdir is the most secure and robust way to go, because it covers all of the cases: 1) /tmp/.diskless doesn't exist -> A directory .diskless is created, which is then removed 2) /tmp/.diskless is a link to a file -> mkdir fails because "File exists" 3) /tmp/.diskless is a link to a directory -> mkdir succeeds but does nothing because -p was specified. The link is then removed. 4) /tmp/.diskless is a link to a nonexistent path or name -> mkdir fails (even with -p) because it can't follow the link: "No such file or directory" 5) /tmp/.diskless exists and is a file -> mkdir fails: "File exists" 6) /tmp/.diskless exists and is a directory -> mkdir succeeds. Later, /tmp/.diskless is removed _only_ if it is empty. Even though touch doesn't change file contents, it could potentially be abused to change the timestamp on an arbitrary file if a link were left in /tmp. The only way to securely use touch or ">" would be to rm -f /tmp/.diskless first, and that is a potentially destructive operation on the off chance the administrator created a file called /tmp/.diskless. It's a very remote chance yes, but why Creating a file called that may cause undesired effects such as mounting an mfs /tmp when you didn't want one, but it won't cause any data loss. > So we are left with what is availabile in /bin, /sbin, /rescue. > Therefore mkdir was used as a work-around. What I'm saying is this > entire thought process is overly-engineered when the shell can simply > "touch" a file with stdout or stderr. This is indeed the most minor of > optimizations. It's not a minor optimization if it changes the semantics of what happens. > is very dangerous because it could nuke a random file if a symlink exists. Even >> or touch can mess with timestamps or create files that don't exist, all with the power of root. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d/tmp (silly mkdir usage)
On Tue, Aug 02, 2005 at 11:47:19AM -0500, [EMAIL PROTECTED] wrote: > > On Mon, Aug 01, 2005 at 11:37:05PM -0500, [EMAIL PROTECTED] wrote: > >> Howdy hackers, > >> > >> I'm sorry for the previous patch, so here is at least one item that > >> really > >> bugs me that isn't obfuscation. In short, I don't see any reason to fork > >> some process to simply "touch" a file (is a filesystem writable) when > >> built-in shell i/o does this: > >> > >> --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 > >> +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 > >> @@ -48,8 +48,8 @@ > >> [Nn][Oo]) > >> ;; > >> *) > >> - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then > >> - rmdir /tmp/.diskless > >> + if ( > /tmp/.diskless 2> /dev/null); then > >> + rm /tmp/.diskless > >> else > >> if [ -h /tmp ]; then > >> echo "*** /tmp is a symlink to a non-writable > >> area!" > >> > > > > The thing you suggest is bloody insecure. Just imagine some baduser > > doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > > I guess this is the reason why directory creation is used instead of > > file creation. > > Well these notions have nothing todo with the way it works, but they are > interesting still. I would imagine a dir could be linked too if somebody > managed to insert a rc.d script in that was ordered sufficiently early > enough to do the evil tasks you are thinking about. Even if mktemp(1) were > available at this stage, I wouldn't use it here. No, mkdir won't act through the link so it's the best option here: $ rm nonexistant $ ls nonexistant ls: nonexistant: No such file or directory $ ln -s nonexistant n1 $ mkdir n1 mkdir: n1: File exists $ ls nonexistant ls: nonexistant: No such file or directory $ > n1 $ ls n1 n1 $ ls nonexistant nonexistant $ echo foobar >> nonexistant $ cat nonexistant foobar $ > n1 $ cat nonexistant $ mkdir n1 mkdir: n1: File exists $ > > I just wonder why a new shell is forked for this test. Simply > > if /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then > > would do the same thing without forking a new shell that only executes > > /bin/mkdir > > Let me be clear about this, the ONLY reason mkdir is used here is because > touch is under /usr somewhere which isn't even mounted at this point > (assuming /usr is mounted seperatly, as is the case on nfs diskless > systems). So we are left with what is availabile in /bin, /sbin, /rescue. > Therefore mkdir was used as a work-around. What I'm saying is this entire > thought process is overly-engineered when the shell can simply "touch" a > file with stdout or stderr. This is indeed the most minor of > optimizations. Nope. $ rm nonexistant $ touch n1 $ ls nonexistant nonexistant -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpLr4Yzs7c0M.pgp Description: PGP signature
Re: [patch] rc.d/tmp (silly mkdir usage)
> On Mon, Aug 01, 2005 at 11:37:05PM -0500, [EMAIL PROTECTED] wrote: >> Howdy hackers, >> >> I'm sorry for the previous patch, so here is at least one item that >> really >> bugs me that isn't obfuscation. In short, I don't see any reason to fork >> some process to simply "touch" a file (is a filesystem writable) when >> built-in shell i/o does this: >> >> --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 >> +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 >> @@ -48,8 +48,8 @@ >> [Nn][Oo]) >> ;; >> *) >> - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then >> - rmdir /tmp/.diskless >> + if ( > /tmp/.diskless 2> /dev/null); then >> + rm /tmp/.diskless >> else >> if [ -h /tmp ]; then >> echo "*** /tmp is a symlink to a non-writable >> area!" >> > > The thing you suggest is bloody insecure. Just imagine some baduser > doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > I guess this is the reason why directory creation is used instead of > file creation. Well these notions have nothing todo with the way it works, but they are interesting still. I would imagine a dir could be linked too if somebody managed to insert a rc.d script in that was ordered sufficiently early enough to do the evil tasks you are thinking about. Even if mktemp(1) were available at this stage, I wouldn't use it here. > > I just wonder why a new shell is forked for this test. Simply > if /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then > would do the same thing without forking a new shell that only executes > /bin/mkdir Let me be clear about this, the ONLY reason mkdir is used here is because touch is under /usr somewhere which isn't even mounted at this point (assuming /usr is mounted seperatly, as is the case on nfs diskless systems). So we are left with what is availabile in /bin, /sbin, /rescue. Therefore mkdir was used as a work-around. What I'm saying is this entire thought process is overly-engineered when the shell can simply "touch" a file with stdout or stderr. This is indeed the most minor of optimizations. > > Even we can use > if [ -d /tmp -a -w /tmp ] ; then > or (which is equivalent) > if [ -d /tmp ] && [ -w /tmp ] ; then > and save external commands (mkdir) execution and directory > creation/deletion at all. > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d/tmp (silly mkdir usage)
On Tue, Aug 02, 2005 at 02:38:36PM +0300, Giorgos Keramidas wrote: > On 2005-08-02 14:05, Vasil Dimov <[EMAIL PROTECTED]> wrote: > >On Tue, Aug 02, 2005 at 12:33:48PM +0300, Giorgos Keramidas wrote: > >>On 2005-08-02 09:29, Vasil Dimov <[EMAIL PROTECTED]> wrote: > *) > - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then > - rmdir /tmp/.diskless > + if ( > /tmp/.diskless 2> /dev/null); then > + rm /tmp/.diskless > else > if [ -h /tmp ]; then > echo "*** /tmp is a symlink to a non-writable > area!" > >>> > >>> The thing you suggest is bloody insecure. Just imagine some baduser > >>> doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > >>> I guess this is the reason why directory creation is used instead of > >>> file creation. > >>> > >>> I just wonder why a new shell is forked for this test. Simply if > >>> /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then would do the same > >>> thing without forking a new shell that only executes /bin/mkdir > >> > >> I think it's because the current shell is allowed to exit if a command > >> fails while a conditional test like this is run: > >> > >>if mkdir /tmp/foo; then > >>echo foo > >>rmdir /tmp/foo > >>fi > >> > >> and mkdir may fail. > > > > What do you mean by "allowed to exit"? > > sh -e? > > You're right, of course. I forgot the script I was looking at had the -e > option enabled. > Hmmz, I don't think /etc/rc.d/tmp is started with sh -e. Anyway even if it is, this will not cause sh to exit if mkdir fails. from sh(1): -e errexit Exit immediately if any untested command fails in non-interactive mode. The exit status of a command is considered to be explic- itly tested if the command is used to control an if, elif, while, # sh -e -c 'if mkdir /a/b ; then echo t ; else echo f ; fi ; echo still alive' mkdir: /a: No such file or directory f still alive # And even more - the braces () would not save us if the command were intested because the forked shell exits with the exit status of the last command executed (e.g. if mkdir fails it will fail too): # sh -e -c '( mkdir /a/b ) ; echo still alive' mkdir: /a: No such file or directory # So what is the point of doing "if ( mkdir ... ) ; then" instead of "if mkdir ... ; then"? Did I miss something... pgpgsRSStoakd.pgp Description: PGP signature
Re: [patch] rc.d/tmp (silly mkdir usage)
On Tue, Aug 02, 2005 at 04:08:12PM +0300, Vasil Dimov wrote: > On Tue, Aug 02, 2005 at 01:15:35PM +0200, Joerg Sonnenberger wrote: > > On Tue, Aug 02, 2005 at 02:06:32PM +0300, Vasil Dimov wrote: > > > On Tue, Aug 02, 2005 at 12:52:34PM +0200, Dario Freni wrote: > > > > Vasil Dimov wrote: > > > > > Even we can use > > > > > if [ -d /tmp -a -w /tmp ] ; then > > > > > or (which is equivalent) > > > > > if [ -d /tmp ] && [ -w /tmp ] ; then > > > > > and save external commands (mkdir) execution and directory > > > > > creation/deletion at all. > > > > > > > > You can't use test -w here. The script is checking if there is a > > > > read-only filesystem. -w checks only the file flags (according to the > > > > man page, at least). > > > > > > > That's correct, -w cannot be used to check read-only filesystem. > > > > Actually, you can. That's not portable behaviour though. > > > > Well, look what I discovered: As I said, it is not portable. > > # mount |grep read-only > /usr/ports on /mnt/ar0s2d/usr/ports5 (nullfs, local, read-only) > # sh -c '[ -w /mnt/ar0s2d/usr/ports5 ] && echo writeable' > # bash -c '[ -w /mnt/ar0s2d/usr/ports5 ] && echo writeable' > writeable I'd say this is a bug in the bash builtin :-) Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d/tmp (silly mkdir usage)
On Tue, Aug 02, 2005 at 01:15:35PM +0200, Joerg Sonnenberger wrote: > On Tue, Aug 02, 2005 at 02:06:32PM +0300, Vasil Dimov wrote: > > On Tue, Aug 02, 2005 at 12:52:34PM +0200, Dario Freni wrote: > > > Vasil Dimov wrote: > > > > Even we can use > > > > if [ -d /tmp -a -w /tmp ] ; then > > > > or (which is equivalent) > > > > if [ -d /tmp ] && [ -w /tmp ] ; then > > > > and save external commands (mkdir) execution and directory > > > > creation/deletion at all. > > > > > > You can't use test -w here. The script is checking if there is a > > > read-only filesystem. -w checks only the file flags (according to the > > > man page, at least). > > > > > That's correct, -w cannot be used to check read-only filesystem. > > Actually, you can. That's not portable behaviour though. > Well, look what I discovered: # mount |grep read-only /usr/ports on /mnt/ar0s2d/usr/ports5 (nullfs, local, read-only) # sh -c '[ -w /mnt/ar0s2d/usr/ports5 ] && echo writeable' # bash -c '[ -w /mnt/ar0s2d/usr/ports5 ] && echo writeable' writeable # One should really not rely on this. pgpSOOCQPo2Pj.pgp Description: PGP signature
(no subject)
Subject: Re: FreeBSD desktop? In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Bcc: [EMAIL PROTECTED] X-Primary-Address: [EMAIL PROTECTED] X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ --text follows this line-- In <[EMAIL PROTECTED]>, Michael Carlson <[EMAIL PROTECTED]> typed: > But if you dont want to wait a couple of days, XFCE is probably the > lightest Window Manager. Not a chance. It uses gtk, which is bigger than lwm (/usr/ports/x11-wm/lwm) all by itself. And lwm isn't the lightest WM around - it's just the one I'm familiar with. The catch with the real lightweight window managers is that you configure them with cc. But if small and fast is what you want, they're the ticket. If you've been using Windows, you might prefer qvwm (/usr/ports/x11-wm/qvwm), which is a Windows 95/98/NT like window manager. I don't see one that emulates XP, and a quick google only turns up XPde, which appears to be a dead. If you think window management is to important to be left to such a low-bandwidth device as a mouse(*), then you might try ratpoison (/usr/ports/x11-wm/ratpoison). It's not for everyone, but it *really* confuses Mac and Windows users. Personally, I prefer plpwm (an example manager in /usr/ports/x11-wm/plwm), but I wrote it. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: per file lock list
Matt, Thank you very much for response. This is a general solution, but it not sufficient for our needs. I guess I should have been more clear while explaining what we need. We want list of these locks for a group of processes. We made an implementation based on your suggestion, but there is one problem... Unfortunately this method does not return all shared locks for a range. For example, if several processes have placed a shared lock on a range [1000 - 2000], F_GETLK returns a flock structure where l_pid field contains a pid of process that takes the lock first. While, we want to know all processes that takes this lock. Is there any way to retrieve such information without using of internal kernel structures (inode information)? Thank you in advance, igor On 7/21/05, Matthew Dillon <[EMAIL PROTECTED]> wrote: > :Hi, > : > :We have a question: how to get all POSIX locks for a given file? > :.. > : > :As far as I know, existing API does not allow to retrieve all file > :locks. Therefore, we need to use kernel internal structures to get all > :... > :So the question: is there an elegant way to get the lock list for a given > file? > : > :Thank you in advance. > > You can use F_GETLK to iterate through all posix locks held on a file. > From man fcntl: > > F_GETLKGet the first lock that blocks the lock description pointed to > by the third argument, arg, taken as a pointer to a struct > flock (see above). The information retrieved overwrites the > information passed to fcntl() in the flock structure. If no > lock is found that would prevent this lock from being created, > the structure is left unchanged by this function call except > for the lock type which is set to F_UNLCK. > > So what you do is you specify a lock description that covers the whole > file and call F_GETLK. You then use the results to modify the lock > description to a range that starts just past the returned lock > for the next call. You continue iterating until F_GETLK tells you that > there are no more locks. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible softupdates bug when a indirect block buffer is reused
This has been a long nagging problem that was finally tracked down and
fixed by Stephan Uphoff <[EMAIL PROTECTED]>. See revision 1.182 on 2005/07/31
to sys/ufs/ffs/ffs_softdep.c.
Kirk McKusick
=-=-=-=-=-=-=
Date: Sun, 31 Jul 2005 11:40:32 -0700 (PDT)
From: Matthew Dillon <[EMAIL PROTECTED]>
To: Kirk McKusick <[EMAIL PROTECTED]>
Cc: freebsd-hackers@freebsd.org
Subject: Possible softupdates bug when a indirect block buffer is reused
X-ASK-Info: Whitelist match [from [EMAIL PROTECTED] (2005/07/31 11:40:52)
Hi Kirk, hackers!
I'm trying to track down a bug that is causing a buffer to be left
in a locked state and then causes the filesystem to lock up because
of that.
The symptoms are that a heavily used filesystem suddenly starts running
out of space. It isn't due to deleted files with open descriptors, it's
due to the syncer getting stuck in a getblk state. This is in DragonFly,
but I can't find anything DFlyish wrong so I'm beginning to think it may
be an actual bug in softupdates.
I have wound up with a situation where a getblk()'d bp has been
associated with a indirdep dependancy, i.e. stored in
indirdep->ir_savebp, but is never released. When something like
the syncer comes along and tries to access it, it locks up, and this
of course leads to inodes not getting cleared and the filesystem
eventually runs out of space when a lot of files are being created and
deleted.
What has got me really confused is that the buffer in question seems to
wind up with a D_INDIRDEP dependancy that points back to itself.
Here's the situation from a live gdb. Here is where the syncer is
stuck:
(kgdb) back
#0 lwkt_switch () at thread2.h:95
#1 0xc02a8a79 in tsleep (ident=0x0, flags=0, wmesg=0xc04eadb0 "getblk",
timo=0) at /usr/src-125beta/sys/kern/kern_synch.c:428
#2 0xc02956bb in acquire (lkp=0xc758b4e0, extflags=33554464, wanted=1536)
at /usr/src-125beta/sys/kern/kern_lock.c:127
#3 0xc0295a92 in lockmgr (lkp=0xc758b4e0, flags=33620002, interlkp=0x0,
td=0xd68f6400) at /usr/src-125beta/sys/kern/kern_lock.c:354
#4 0xc02d6828 in getblk (vp=0xc71b3058, blkno=94440240, size=8192, slpflag=0,
slptimeo=0) at thread.h:79
#5 0xc02d4404 in bread (vp=0xc71b3058, blkno=0, size=0, bpp=0x0)
at /usr/src-125beta/sys/kern/vfs_bio.c:567
#6 0xc03f24fe in indir_trunc (ip=0xe048fc0c, dbn=94440240, level=1, lbn=2060,
countp=0xe048fbf8) at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:2221
#7 0xc03f22df in handle_workitem_freeblocks (freeblks=0xe2fcef98)
at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:2138
#8 0xc03f0462 in process_worklist_item (matchmnt=0x0, flags=0)
at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:726
#9 0xc03f026c in softdep_process_worklist (matchmnt=0x0)
at /usr/src-125beta/sys/vfs/ufs/ffs_softdep.c:625
#10 0xc02e5ff3 in sched_sync () at /usr/src-125beta/sys/kern/vfs_sync.c:244
#11 0xc0294863 in kthread_create_stk (func=0, arg=0x0, tdp=0xff80,
stksize=0, fmt=0x0) at /usr/src-125beta/sys/kern/kern_kthread.c:104
(kgdb)
The buffer it is stuck on:
(kgdb) print bp
$62 = (struct buf *) 0xc758b4b8
(kgdb) print *bp
$63 = {
b_hash = {
le_next = 0x0,
le_prev = 0xc7391348
},
b_vnbufs = {
tqe_next = 0xc739b890,
tqe_prev = 0xc76f32b8
},
b_freelist = {
tqe_next = 0xc768d610,
tqe_prev = 0xc0565ac0
},
b_act = {
tqe_next = 0x0,
tqe_prev = 0x0
},
b_flags = 536870912, < 0x2000 (getblk with no bread, etc)
b_qindex = 0,
b_xflags = 2 '\002',
b_lock = {
lk_interlock = {
t_cpu = 0xff80,
t_reqcpu = 0xff80,
t_unused01 = 0
},
lk_flags = 2098176,
lk_sharecount = 0,
lk_waitcount = 1,
lk_exclusivecount = 1,
lk_prio = 0,
lk_wmesg = 0xc04eadb0 "getblk",
lk_timo = 0,
lk_lockholder = 0xfffe
},
b_error = 0,
b_bufsize = 8192,
b_runningbufspace = 0,
b_bcount = 8192,
b_resid = 0,
b_dev = 0xde0f0e38,
b_data = 0xcf824000 "¨\205Ð\002",
b_kvabase = 0xcf824000 "¨\205Ð\002",
b_kvasize = 16384,
b_lblkno = 94440240,
b_blkno = 94440240,
b_offset = 48353402880,
b_iodone = 0,
b_iodone_chain = 0x0,
b_vp = 0xc71b3058,
b_dirtyoff = 0,
b_dirtyend = 0,
b_pblkno = 87503631,
b_saveaddr = 0x0,
b_driver1 = 0x0,
b_caller1 = 0x0,
b_pager = {
pg_spc = 0x0,
pg_reqpage = 0
},
b_cluster = {
cluster_head = {
tqh_first = 0x0,
tqh_last = 0xc768d6bc
---Type to continue, or q to quit---
},
cluster_entry = {
tqe_next = 0x0,
tqe_prev = 0xc768d6bc
}
},
b_xio = {
xio_pages = 0xc758b584,
xio_npages = 2,
xio_offset = 0,
xio_bytes = 0,
xio_flags = 0,
xio_error = 0,
xio_internal_pages = {0xc34e5870, 0xc4aeb2b4, 0x0 }
},
b_dep = {
lh_first = 0xc7045040
},
b_chain = {
parent = 0x0,
count = 0
}
}
As y
Re: [patch] rc.d/tmp (silly mkdir usage)
On 2005-08-02 14:05, Vasil Dimov <[EMAIL PROTECTED]> wrote: >On Tue, Aug 02, 2005 at 12:33:48PM +0300, Giorgos Keramidas wrote: >>On 2005-08-02 09:29, Vasil Dimov <[EMAIL PROTECTED]> wrote: *) - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then - rmdir /tmp/.diskless + if ( > /tmp/.diskless 2> /dev/null); then + rm /tmp/.diskless else if [ -h /tmp ]; then echo "*** /tmp is a symlink to a non-writable area!" >>> >>> The thing you suggest is bloody insecure. Just imagine some baduser >>> doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. >>> I guess this is the reason why directory creation is used instead of >>> file creation. >>> >>> I just wonder why a new shell is forked for this test. Simply if >>> /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then would do the same >>> thing without forking a new shell that only executes /bin/mkdir >> >> I think it's because the current shell is allowed to exit if a command >> fails while a conditional test like this is run: >> >> if mkdir /tmp/foo; then >> echo foo >> rmdir /tmp/foo >> fi >> >> and mkdir may fail. > > What do you mean by "allowed to exit"? > sh -e? You're right, of course. I forgot the script I was looking at had the -e option enabled. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d/tmp (silly mkdir usage)
On Tue, Aug 02, 2005 at 02:06:32PM +0300, Vasil Dimov wrote: > On Tue, Aug 02, 2005 at 12:52:34PM +0200, Dario Freni wrote: > > Vasil Dimov wrote: > > > Even we can use > > > if [ -d /tmp -a -w /tmp ] ; then > > > or (which is equivalent) > > > if [ -d /tmp ] && [ -w /tmp ] ; then > > > and save external commands (mkdir) execution and directory > > > creation/deletion at all. > > > > You can't use test -w here. The script is checking if there is a > > read-only filesystem. -w checks only the file flags (according to the > > man page, at least). > > > That's correct, -w cannot be used to check read-only filesystem. Actually, you can. That's not portable behaviour though. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d/tmp (silly mkdir usage)
On Tue, Aug 02, 2005 at 12:52:34PM +0200, Dario Freni wrote: > Vasil Dimov wrote: > > Even we can use > > if [ -d /tmp -a -w /tmp ] ; then > > or (which is equivalent) > > if [ -d /tmp ] && [ -w /tmp ] ; then > > and save external commands (mkdir) execution and directory > > creation/deletion at all. > > You can't use test -w here. The script is checking if there is a > read-only filesystem. -w checks only the file flags (according to the > man page, at least). > That's correct, -w cannot be used to check read-only filesystem. pgpOMP99R16AY.pgp Description: PGP signature
Re: [patch] rc.d/tmp (silly mkdir usage)
On Tue, Aug 02, 2005 at 12:33:48PM +0300, Giorgos Keramidas wrote: > On 2005-08-02 09:29, Vasil Dimov <[EMAIL PROTECTED]> wrote: > > > --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 > > > +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 > > > @@ -48,8 +48,8 @@ > > > [Nn][Oo]) > > > ;; > > > *) > > > - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then > > > - rmdir /tmp/.diskless > > > + if ( > /tmp/.diskless 2> /dev/null); then > > > + rm /tmp/.diskless > > > else > > > if [ -h /tmp ]; then > > > echo "*** /tmp is a symlink to a non-writable > > > area!" > > > > The thing you suggest is bloody insecure. Just imagine some baduser > > doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > > I guess this is the reason why directory creation is used instead of > > file creation. > > > > I just wonder why a new shell is forked for this test. Simply if > > /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then would do the same > > thing without forking a new shell that only executes /bin/mkdir > > I think it's because the current shell is allowed to exit if a command > fails while a conditional test like this is run: > > if mkdir /tmp/foo; then > echo foo > rmdir /tmp/foo > fi > > and mkdir may fail. > What do you mean by "allowed to exit"? sh -e? pgpqaGBu55T5M.pgp Description: PGP signature
Re: [patch] rc.d/tmp (silly mkdir usage)
Vasil Dimov wrote: > Even we can use > if [ -d /tmp -a -w /tmp ] ; then > or (which is equivalent) > if [ -d /tmp ] && [ -w /tmp ] ; then > and save external commands (mkdir) execution and directory > creation/deletion at all. You can't use test -w here. The script is checking if there is a read-only filesystem. -w checks only the file flags (according to the man page, at least). -- Dario Freni ([EMAIL PROTECTED]) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc signature.asc Description: OpenPGP digital signature
Re: [patch] rc.d/tmp (silly mkdir usage)
On 2005-08-02 09:29, Vasil Dimov <[EMAIL PROTECTED]> wrote: > > --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 > > +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 > > @@ -48,8 +48,8 @@ > > [Nn][Oo]) > > ;; > > *) > > - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then > > - rmdir /tmp/.diskless > > + if ( > /tmp/.diskless 2> /dev/null); then > > + rm /tmp/.diskless > > else > > if [ -h /tmp ]; then > > echo "*** /tmp is a symlink to a non-writable area!" > > The thing you suggest is bloody insecure. Just imagine some baduser > doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > I guess this is the reason why directory creation is used instead of > file creation. > > I just wonder why a new shell is forked for this test. Simply if > /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then would do the same > thing without forking a new shell that only executes /bin/mkdir I think it's because the current shell is allowed to exit if a command fails while a conditional test like this is run: if mkdir /tmp/foo; then echo foo rmdir /tmp/foo fi and mkdir may fail. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
