kernel device dependency and sys/conf/files format
I'm revisiting the project to determine device dependency in the kernel, and I've run into a situation where net/if.c requires the ether device, but no device appears to require net/if.c directly. sys/conf/files says that net/if.c is standard, but I have no idea what that means in terms of building a kernel. An entry (filename) in that file can be listed as standard, mandatory, optional, or count. Mandatory and optional seem pretty self-explanatory, but can anyone explain the meaning of standard and count? I assume that net/if.c can be removed from the build or else it would be listed as mandatory, but it does appear that an awful lot of things implicitly depend on it. Geoff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in pw, -STABLE [patch]
On Mon, 24 Jun 2002, Paul Herman wrote: On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote: So we either need to have a compelling solution or get a committer to step in and make up our minds for us. I think the best thing to do is file a PR for this. With or without a patch? Geoff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, -STABLE [patch]
On Mon, 24 Jun 2002, Paul Herman wrote: On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote: So we either need to have a compelling solution or get a committer to step in and make up our minds for us. I think the best thing to do is file a PR for this. More than one person has already beaten us to the punch: bin/23501, closed on Fri Jun 22 08:43:09 PDT 2001, describes the exact same problem with pw(8), and contains a patch that was verified to fix the problem, but it was apparently never committed. bin/38676, submitted on Tue May 28 19:40:08 PDT 2002, requests that the original patch be committed, but has gotten no feedback. Next? Geoff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, -STABLE [patch]
On Sun, 23 Jun 2002, Paul Herman wrote: You see the problem as a deficiency in the implementation itself, and wish to protect the user from shooting themselves in the foot. Not only do I think that's impossible[*], I choose to fight for my right to shoot myself in the foot as quickly and efficiently as possible, but that's where we'll disagree, and I'll just leave it at that and wish you a good night's sleep. Not to be snooty, but there will always be plenty of ways for you to shoot yourself in the foot if you want to play that way. For regular users of pw(8) who don't want to get shot, it needs to be fixed when used within its intended bounds. As far as I'm concerned, it comes down to what is most feasible to implement correctly without an unreasonably large effort. In reality, it comes down to how a committer would like to see it work, since the committers are the ones who ultimately have to deal with and are responsible for the change. So we either need to have a compelling solution or get a committer to step in and make up our minds for us. Geoff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, -STABLE [patch]
[I'm bringing the discussion back to -hackers, since it was omitted in your original reply, Paul. To get everyone up to speed, Paul suggested that calling unlink() _before_ close() should solve the race condition mentioned in my original message. However, that still leads to corruption, and we're trying to figure out why.] On Fri, 17 May 2002, Paul Herman wrote: The file isn't actually unlinked until p1 closes the fd Sure it is. Try a little C: fd = open(watchme, O_CREAT|O_EXLOCK); sleep(10); unlink(watchme); sleep(10); close(fd); You'll see the file disappear after 10 seconds, not 20. Hmm. Rechecking the man page for unlink(2) I see that I worded the above incorrectly. The file is unlinked when you unlink(), but not actually removed until close(). Also, open() looks like it blocks until it can get the lock But when does open() block in the following scenario? p1:open() - open lock file p2:open() - BLOCK p1:unlink()- remove link only, do not remove file p2:open() - WAKEUP p1:close() - close fd Does it block before it opens a fd, or after then but before it gains an exclusive lock? In other words, did p2 open a new file after it woke up, or did it open the same file that p1 had opened? If the latter is true then we could extend the above: p3:open() - open lock file (since p1 unlinked p1 p2's copy) p2/p3:update master.passwd - BOOM If the former is true, then I'm pretty much out of ideas. I don't think the corruption is due to something else, since simply removing the call to unlink() does in fact fix the problem. Geoff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, freebsd 4.5 [patch]
On Mon, 13 May 2002, Geoffrey C. Speicher wrote:
On Thu, 2 May 2002, Matthew D. Fuller wrote:
I'll see if I can put some time over the next few days into delving into
it and at least getting the first step (of making the locking work more
usefully) work.
Hi Matt. Just wondering if you've made any progress on making pw use a
lockfile. Is there anything I can do to help?
OK, I'm answering my own question. Please review the two patches below
and provide feedback. They appear to work for me. Some notes:
1. The lock isn't very fine-grained. We grab one giant lock before
doing any operations at all, and let it go right before we exit.
The alternative is to lock /etc/master.passwd and /etc/group
individually, only when they're updated, but I saw no point in going
that far.
2. The lockfile is /var/run/pw.lock and it always contains the pid of
the pw process that most recently grabbed the lock.
3. The lockfile is never deleted, because doing so seemed to cause a
race condition between the time the file is closed and unlinked,
leading to password file corruption again. If anyone has a solution
to this, please speak up.
4. Should this thread be moved to -stable?
5. To test, backup your /etc/master.passwd and /etc/group, and then try
something like this, several times with the old pw to verify
consistent breakage, and then several times with the new pw to verify
that it doesn't break anymore.
# in one terminal, run this first
i=0
while [ $i -le 1000 ]; do
pw add user testuser$i
i=$(($i+1))
done
# in another terminal, wait about 10-15 seconds and then run this
# (or tail -f /etc/master.passwd and run it when testuser500 shows up)
i=0
while [ $i -le 500 ]; do
pw del user testuser$i
i=$(($i+1))
done
Geoff
--- pwupd.h.origTue May 14 22:06:37 2002
+++ pwupd.h Wed May 15 13:35:14 2002
@@ -110,6 +110,12 @@
#ifndef _GROUP
#define _GROUP group
#endif
+#ifndef _PWLOCK
+#define _PWLOCK/var/run/pw.lock
+#endif
+#ifndef _LOCK_FILE_MODE
+#define _LOCK_FILE_MODE(S_IRUSR | S_IWUSR)
+#endif
__BEGIN_DECLS
int addpwent __P((struct passwd * pwd));
--- pw.c.orig Wed May 15 13:35:21 2002
+++ pw.cWed May 15 13:37:53 2002
@@ -98,10 +98,12 @@
main(int argc, char *argv[])
{
int ch;
+ int lockfd;
int mode = -1;
int which = -1;
char*config = NULL;
struct userconf *cnf;
+ char*pidstr;
static const char *opts[W_NUM][M_NUM] =
{
@@ -202,6 +204,17 @@
errx(EX_NOPERM, you must be root to run this program);
/*
+* Gain exclusive lock before updating any files
+*/
+ lockfd = open(_PWLOCK, O_WRONLY | O_CREAT | O_EXLOCK,
_LOCK_FILE_MODE);
+ if (lockfd == -1)
+ err(EX_UNAVAILABLE, %s, _PWLOCK);
+
+ ftruncate(lockfd,0);
+ write(lockfd, pidstr, asprintf(pidstr, %d, getpid()));
+ free(pidstr);
+
+ /*
* We should immediately look for the -q 'quiet' switch so that we
* don't bother with extraneous errors
*/
@@ -226,7 +239,7 @@
setgrdir(etcpath);
}
}
-
+
/*
* Now, let's do the common initialisation
*/
@@ -259,6 +272,12 @@
pw_log(cnf, mode, which, NIS maps
updated);
}
}
+
+ /*
+* Release the lock
+*/
+ close(lockfd);
+
return ch;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, freebsd 4.5
On Thu, 2 May 2002, Matthew D. Fuller wrote: I'll see if I can put some time over the next few days into delving into it and at least getting the first step (of making the locking work more usefully) work. Hi Matt. Just wondering if you've made any progress on making pw use a lockfile. Is there anything I can do to help? Thanks, Geoff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, freebsd 4.5
On Thu, 2 May 2002, Matthew D. Fuller wrote: Well, the stab didn't go because nobody was interested 8-) Sorry --- I was interested, but I didn't see your original message. This problem has been biting me (and a client) in the ass for quite some time. I actually had in mind some farther-reaching changes, which would (after 'fixing' pw) include potentially rewriting adduser(8) and friends to backend into pw to; sort of consolidate the user-management stuff a bit. While I was looking through the sources yesterday, I was wondering why so many pieces were reimplemented time and again. So I'd say that sounds like a worthwhile cause. What do people think of using the external lock file (well, I can't actually think of any OTHER way to do it, so...)? I'm thinking /var/run, but on the flipside just putting it in /etc might be cleaner. Comments? Hmm. hier(7) describes /var/run thusly: run/ system information files describing various info about system since it was booted I guess it could be easily argued that the password file is currently locked describes information about the system since it was booted. :) Geoff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, freebsd 4.5
On Sat, 9 Mar 2002 04:52:25 -0600, Matthew D. Fuller wrote: [in regard to multiple concurrent pw(8) processes hosing master.passwd] The reason for this is that the only file pw(8) locks is /etc/master.passwd.new when it copies into it. [snip] If anybody's interested, I could take a stab at hacking something together for this sometime over the next week or so. I'm interested. How did the stab go? I'm browsing archives and I can't find any more followups. Geoff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
