Re: Useful tools missing from /rescue
On Thu, Nov 01, 2007 at 08:53:39AM -0700, David O'Brien wrote: On Thu, Oct 18, 2007 at 02:04:21AM +0400, Yar Tikhiy wrote: On Mon, Oct 15, 2007 at 10:38:26AM -0700, David O'Brien wrote: I guess I'm not creative enough in the ways I've screwed up my systems and needed tools from /rescue. 8-) Just try to installworld FreeBSD/amd64 over a running FreeBSD/i386. ;-) I strongly feel that shouldn't be supported on a live system. So to me We already got that possibility for free along with src/Makefile.inc1#1.590, so no particular efforts are needed to support it. it shouldn't be an excuse to put a duplicated copy of /usr/[s]bin into /rescue. It's an exaggeration. The most of /usr/[s]bin aren't in /rescue yet. :-) It is a delicate thing to get right - and there are easy ways to do it today: Boot from disc1; mount / and /usr; mv /mnt/etc /mnt/etc.hold; rm -rf the bits in bin,sbin,libexec; then run the install.sh from the disc1; mv /mnt/etc /mnt/etc.new ; mv /mnt/etc.hold /mnt/etc One of the things I love FreeBSD for is being able to do things in different ways and to choose such a way depending on the case. :-) E.g., one may want to go from CURRENT/arch1 to CURRENT/arch2 without having to install a binary release or snapshot for arch2 first. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Mon, Oct 15, 2007 at 10:38:26AM -0700, David O'Brien wrote: On Sat, Oct 13, 2007 at 10:01:39AM +0400, Yar Tikhiy wrote: On Wed, Oct 03, 2007 at 07:23:44PM -0700, David O'Brien wrote: I also don't see the need for pgrep - I think needing that says your system is running multiuser pretty well. First of all, I'd like to point out that /rescue doesn't need to be as minimal as /stand used to. Now, /rescue is a compact yet versatile set of essential tools that can help in any difficult situation when /*bin:/usr/*bin are unusable for some reason, not only in restoring a broken system while in single-user mode. A .. As for pgrep+pkill, it can come handy if one has screwed up his live system and wants to recover it without dropping the system to single-user. But if we take this just a little bit farther then why don't we go back to a static /[s]bin except for the few things one might need LDAP, etc.. for? That is, what's the purpose in continuing to duplicate /[s]bin into /rescue? /rescue should be just enough to reasonably get a system who's shared libs are messed up working again. Note that /rescue includes the most essential tools from /usr/[s]bin, too. Irrespective of its initial purpose, I regard /rescue as an emergency toolset left aside. In particular, it's good to know it's there when you experiment with a live remote system. A valid objection to this point is that pgrep's job can be done with a combination of ps(1) and sed(1), so it's just a matter of convenience. I guess I'm still having trouble understanding why one would need 'ps' to fix a shared libs issue. Now is a reason to keep adding stuff to IMHO it isn't only shared libs issues that /rescue can help with. /rescue. Also why one would be running 'ps -aux', which is the only way I can think of to get more than one screen of output if a system is in trouble. Imagine that you've rm'ed /usr by accident in a remote shell session. With enough tools in /rescue (which doesn't take lots of tools,) you can stop sensitive daemons, find the backup, restore from it, and get a functional system again without a reboot. No doubt, some tools just make the task easier by providing typical command-line idioms. I don't mean I'm so reckless that I need to restore my /usr often, but the 3-4 megabytes occupied by /rescue are a terribly low price today for being able to shoot different parts of one's foot without necessarily hitting the bone. The price for it in terms of disk space is next to nothing, and there are quite useless space hogs in /rescue already (see below on /rescue/vi.) Considering how few people are skilled in ed(1) these days, we have little choice but include vi. Of course, there should be /rescue/vi, and I have an idea on how to remove its dependence on /usr in a more or less elegant way. I mentioned the not-so-functional /rescue/vi here just to show that we can tolerate certain space waste in /rescue. I won't speak for everyone, but I really like to use fancy shell commands, particularly during hard times: loops, pipelines, etc. So I don't have to enter many commands for a single task or browse I guess I'm not creative enough in the ways I've screwed up my systems and needed tools from /rescue. 8-) Just try to installworld FreeBSD/amd64 over a running FreeBSD/i386. ;-) I don't see the purpose of chown - if you have to fall back to /rescue you're user 'root' - and you're trying to fix enough so you can use standard /*lib /*bin .. Having /rescue/chown is just a matter of completeness of the ch* subset of /rescue tools because chown's job can't be done by any other stock tools. If /rescue is complete enough, one can find more applications for it. E.g., the loader, a kernel, and /rescue /rescue wasn't intended to be well orthogonal. /rescue was part of he corner stone of the deal to switch to shared /[s]bin. But it doesn't confine us to the corner forever. Having an emergency toolset independent of the rest of the system is good in any case. I bet people will experiment and have fun with their systems more eagerly if they know they still can recover quickly with ready tools in case of a serious error. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Wed, Oct 03, 2007 at 07:23:44PM -0700, David O'Brien wrote: Yar Tikhiy wrote: I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. I also don't see the need for pgrep - I think needing that says your system is running multiuser pretty well. First of all, I'd like to point out that /rescue doesn't need to be as minimal as /stand used to. Now, /rescue is a compact yet versatile set of essential tools that can help in any difficult situation when /*bin:/usr/*bin are unusable for some reason, not only in restoring a broken system while in single-user mode. A skillful admin needs a rather limited number of tools, but some of them still are missing from /rescue. As for pgrep+pkill, it can come handy if one has screwed up his live system and wants to recover it without dropping the system to single-user. A valid objection to this point is that pgrep's job can be done with a combination of ps(1) and sed(1), so it's just a matter of convenience. The price for it in terms of disk space is next to nothing, and there are quite useless space hogs in /rescue already (see below on /rescue/vi.) Also head and tail - why not just add 'more' as that would give more functionality if you're trying to read a file in /etc to fix something. I won't speak for everyone, but I really like to use fancy shell commands, particularly during hard times: loops, pipelines, etc. So I don't have to enter many commands for a single task or browse through voluminous output for relevant parts. And it's hard to use pipelines w/o basic filters. Again, head(1) and tail(1) can be substituted by sed(1), but my fingers are just used to type head or tail in certain cases. I suspect that I'm not the only one of this kind out there. As for more(1), there is a reason not to include it in /rescue now, besides its rather large size. Namely it uses ncurses and thus depends on /etc/termcap to work well; but in a really tough case when you can mount only /, /etc/termcap is unavailable because it's a symlink to under /usr. This problem plagues /rescue/vi already (see PR bin/80256.) I think we should postpone adding more(1) to /rescue to after the problem has been fixed. And, of course, more(1) is no substitute for head(1) or tail(1) when it comes to pipelines. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. I don't see the purpose of chown - if you have to fall back to /rescue you're user 'root' - and you're trying to fix enough so you can use standard /*lib /*bin chflags is needed so you can overwrite a file and chmod is needed so you can chmod +x something - those needs are clear. Please don't pestimize the build - unless there is a clear benefit. Having /rescue/chown is just a matter of completeness of the ch* subset of /rescue tools because chown's job can't be done by any other stock tools. If /rescue is complete enough, one can find more applications for it. E.g., the loader, a kernel, and /rescue are enough to run single-user and do basic things. (Note that there is /rescue/init.) Of course, what I've just told is my own view of /rescue's role, but it seems to be supported by some other folks. Thank you for your comments! I think this discussion can let us understand better what we need from /rescue. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Sun, Sep 02, 2007 at 09:00:04PM +0200, Simon 'corecode' Schubert wrote: Tim Kientzle wrote: I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful. Mined is a nice editor for this, running without curses. A statically linked, stripped binary is about 100k in size, so if crunched it would have a very small impact. It even used to be in our src tree under release/picobsd. However, if we revive it, we'll have to support as many as 4 text editors in the base system, which can be a bit too many. The main problem with /rescue/vi is its being totally useless without the termcap file from /usr, as discussed under PR bin/80256. The solutions suggested there are more or less based on introducing additional trimmed down termcap files in the src tree, which is no better than having 4 editors to support. I'd rather write a small script to extract a subset of terminal types from the main termcap file, and install it as /rescue/termcap. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Sun, Sep 02, 2007 at 11:18:04AM -0700, Tim Kientzle wrote: Yar Tikhiy wrote: Hi all, I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. Oh, my. chown was definitely an oversight. That should have been in there. My opinions: * head, tail, and tee are no-brainers; just do it. * sed would be a nice addition. (I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful.) Thank you for supporting my idea! * I personally would not add pgrep/pkill because I never use them. They can be handy if you find yourself with a botched system still in multi-user mode and want to fix the things w/o dropping to single-user mode. Now there are ps(1) and kill(1) in rescue, which together with sed(1) can do the same job, but pgrep/pkill is much more convenient. Another option can be killall(1), but pkill(1) has almost superseded it because it is more widely adopted and has richer features without code bloat. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Mon, Sep 03, 2007 at 08:36:58AM -0400, Daniel Eischen wrote: On Mon, 3 Sep 2007, Yar Tikhiy wrote: On Sun, Sep 02, 2007 at 11:18:04AM -0700, Tim Kientzle wrote: Yar Tikhiy wrote: Hi all, I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. Oh, my. chown was definitely an oversight. That should have been in there. My opinions: * head, tail, and tee are no-brainers; just do it. * sed would be a nice addition. (I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful.) Thank you for supporting my idea! I'm surprised no one has mentioned ftp or fetch. I don't know how large they would be if static, but if you have to grab some files over the network, it can be quite convenient. It's just a matter of Someone(tm) building the new rescue with ftp or fetch, testing it, and reporting the size change. ;-) With network setup tools already in /rescue, it sounds as a good idea to consider, at least. The needed code pieces aren't giant: -r-xr-xr-x 1 root wheel 18956 26 авг 03:31 /usr/bin/fetch -r--r--r-- 1 root wheel 54750 26 авг 03:27 /usr/lib/libfetch.a But the crypto bits may need to be disabled: # ldd /usr/bin/fetch /usr/bin/fetch: libfetch.so.5 = /usr/lib/libfetch.so.5 (0x2808) libssl.so.5 = /usr/lib/libssl.so.5 (0x2808d000) libcrypto.so.5 = /lib/libcrypto.so.5 (0x280ce000) libc.so.7 = /lib/libc.so.7 (0x28225000) Another option is tftp(1). :-) -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Mon, Sep 03, 2007 at 03:18:03AM +0300, Giorgos Keramidas wrote:
On 2007-09-02 11:18, Tim Kientzle [EMAIL PROTECTED] wrote:
Yar Tikhiy wrote:
In addition, there are chflags and chmod in /rescue, but there's no
chown in it, so the toolset is a bit incomplete.
Oh, my. chown was definitely an oversight. That
should have been in there.
Probably because chown is a relatively big binary. If build as a static
binary here, it ends up being:
$ pwd
/home/keramida/bsd/src/usr.sbin/chown
$ make DEBUG_FLAGS='' NO_SHARED=yes all
[...]
$ ls -ld chown
-rwxrwxr-x1 keramida users - 2297013 Sep 3 03:06 chown
$ strip -s chown
$ ls -ld chown
-rwxrwxr-x1 keramida users - 550624 Sep 3 03:06 chown
$
This will get smaller when crunched, but it's still almost 4x the size
of chmod:
$ pwd
/home/keramida/bsd/src/bin/chmod
$ make DEBUG_FLAGS='' NO_SHARED=yes all
[...]
$ ls -ld chmod
-rwxrwxr-x 1 keramida users - 662678 Sep 3 03:08 chmod
$ strip -s chmod
$ ls -ld chmod
-rwxrwxr-x 1 keramida users - 165884 Sep 3 03:08 chmod
$
Running nm(1) on the binaries, I see that they have the same symbols
though:
$ nm -S chmod | awk '{print $2,$3,$4}' | sort /tmp/symbols.chmod
$ nm -S chown | awk '{print $2,$3,$4}' | sort /tmp/symbols.chown
$ diff -u /tmp/symbols.chmod /tmp/symbols.chown
$
Does this mean that adding chown to the already crunched binary will not
cause a lot of bloat because of symbols/functions private to chown?
The difference in the static binary sizes is weird, but I don't
have time now to dig the issue deeper, sorry. The rescue binary
grows just slightly when chown is added to it:
-r-xr-xr-x 121 root wheel 3715096 1 сен 10:22 /rescue.old/rescue
-r-xr-xr-x 122 root wheel 3718192 3 сен 17:17 /rescue/rescue
--
Yar
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Useful tools missing from /rescue
Hi all,
I've had to use /rescue recently and felt lack of a few basic tools
in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter,
e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1),
tail(1), and even tee(1) can be emulated if one has sed(1), but the
tools are so tiny and convenient that it's a pity not to have them
all handy during hard times.
In addition, there are chflags and chmod in /rescue, but there's
no chown in it, so the toolset is a bit incomplete.
Would anyone mind if I add those tools to /rescue? The size growth
will be rather small:
-r-xr-xr-x 121 root wheel 3715096 1 сен 10:22 /mnt2/rescue.old/rescue
-r-xr-xr-x 129 root wheel 3761828 1 сен 11:22 /mnt2/rescue/rescue
The patch is attached.
Thanks!
--
Yar
--- //depot/vendor/freebsd/src/rescue/rescue/Makefile 2007/07/14 22:47:42
+++ //depot/user/yar/hack/rescue/rescue/Makefile2007/09/01 07:28:25
@@ -85,6 +85,10 @@
CRUNCH_ALIAS_rm= unlink
CRUNCH_ALIAS_ed= red
+CRUNCH_PROGS_bin+= pkill
+CRUNCH_SRCDIR_pkill= ${.CURDIR}/../../usr.bin/pkill
+CRUNCH_ALIAS_pkill= pgrep
+
.if ${MK_RCMDS} != no
CRUNCH_PROGS_bin+= rcp
.endif
@@ -190,6 +194,8 @@
#
CRUNCH_SRCDIRS+= usr.bin
+CRUNCH_PROGS_usr.bin= head sed tail tee
+
CRUNCH_PROGS_usr.bin+= gzip
CRUNCH_ALIAS_gzip= gunzip gzcat zcat
@@ -211,7 +217,10 @@
#
CRUNCH_SRCDIRS+= usr.sbin
-CRUNCH_PROGS_usr.sbin+= chroot
+CRUNCH_PROGS_usr.sbin= chroot
+
+CRUNCH_PROGS_usr.sbin+= chown
+CRUNCH_ALIAS_chown= chgrp
##
# The following is pretty nearly a generic crunchgen-handling makefile
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Sat, Sep 01, 2007 at 02:40:29PM +0200, Julian Stacey wrote:
Reference:
From: Yar Tikhiy [EMAIL PROTECTED]
Date: Sat, 1 Sep 2007 11:34:40 +0400
Message-id: [EMAIL PROTECTED]
Yar Tikhiy wrote:
Hi all,
I've had to use /rescue recently and felt lack of a few basic tools
in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter,
e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1),
tail(1), and even tee(1) can be emulated if one has sed(1), but the
tools are so tiny and convenient that it's a pity not to have them
all handy during hard times.
In addition, there are chflags and chmod in /rescue, but there's
no chown in it, so the toolset is a bit incomplete.
Would anyone mind if I add those tools to /rescue? The size growth
will be rather small:
-r-xr-xr-x 121 root wheel 3715096 1 сен 10:22 /mnt2/rescue.old/rescue
-r-xr-xr-x 129 root wheel 3761828 1 сен 11:22 /mnt2/rescue/rescue
Don't do it without approval of re@ (who might be too busy just now
Thanks for the reminder. ;-)
anyway) It might blow the limit on the tight packed rescue floppy.
( though desk workstations have CDs, lost of small boxes still
just have floppies for rescue) Best try to build a rescue floppy
yourself before adding bloat.
If you meant the fixit floppy, it is built separately. The rescue(8)
binary is already bigger than a floppy and it isn't supposed to fit
on that media.
BTW I've never used pgrep thus superfluous to rescue. Others also
not really needed, merely nice. True rescue is just to fix FS at
which point you can mount other FS or CDROM or NFS etc for more
tools.
Unlike a fixit floppy, rescue(8) was introduced mostly to help when
shared libraries were damaged badly. In that case, to prevent
system malfunction, you may want to kill daemons starting other
binaries, e.g., cron(8) and sendmail(8), if you don't want to, or
just cannot, drop into single-user mode immediately. Of course,
rescue(8) is also of use in other recovery tasks if one is lucky
enough to be able to mount / and too lazy to reach for a fixit CD.
Before anyone else might discuss which tools might be nice, I'd
suggest build yourself a FIXIT floppy, see what space is left,
what you'd have to chuck out to make space for what you want to
add.
Again, fixit is built using a different configuration file, please
see src/release/${TARGET_ARCH}/fixit_crunch.conf.
--
Yar
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFI: Ethernet driver ported from Linux
On Thu, Apr 19, 2007 at 12:34:16PM -0700, Julian Elischer wrote: Alan Garfield wrote: On Thu, 2007-04-19 at 11:56 +0400, Yar Tikhiy wrote: Apart from using fake MAC addresses, I don't think so. I don't understand the concept of a fake MAC address, sorry. The classic Ethernet is a broadcast medium by design, so a very primitive NIC can just receive all traffic and let the driver or network stack decide if the host wants a particular frame. On output, the network stack can usually put any source MAC address into the frame -- it's true for the most of Ethernet network interfaces. So MAC addresses are always fake in a sense, as neither the hardware nor the medium design enforces them. You're right. I don't fully understand quite what's happening behind the scene it would seem. It sounds like this should be a point-to-point interface, and not an Ethernet interface.. If I understand what you are saying there is only ever communications between 2 entities. What is on the other side of this connection? Alan may be busy debugging the driver, so let me answer for him, as he said my notion of the thing was correct. Sun Fire 20z is a more or less conventional amd64 machine but, besides the usual components forming the main system (CPU, RAM, bus, etc) it contains an additional small embedded-style computer (seems to be m68k based) with the role of monitoring and managing the main system hardware independently from the host OS, which can be overloaded with heavy tasks, unstable, or unresponsive. The small computer has its own external Ethernet interface for remote management and also can communicate with the main host OS via a small hardware buffer. It runs a custom Linux, and there's not much control over its properties. The Linux is hard-coded to send and receive but Ethernet frames via the buffer, so the main host OS has little choice there, too. If I understand your case right, the two processors, CPU and SP, share a hardware buffer, in which they can put some data for the other side, e.g., an Ethernet frame, and then prod the other side with an interrupt. That fits the Ethernet model ideally, so there should be no need for hacks unless the other side, the SP running a special Linux, takes the whole thing wrong. Again, you're correct. The Linux driver does have a certain 'quality' to it, but otherwise it should work as you've said. Alan. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFI: Ethernet driver ported from Linux
On Thu, Apr 19, 2007 at 12:14:50PM +1000, Alan Garfield wrote: On Wed, 2007-04-18 at 11:44 +0400, Yar Tikhiy wrote: Anyway, back to figuring out arp. UGH! As a rule, an Ethernet driver needn't worry about ARP by itself because ARP has own separate module in the network stack. Does your driver have a partucular reason to? Apart from using fake MAC addresses, I don't think so. I don't understand the concept of a fake MAC address, sorry. The classic Ethernet is a broadcast medium by design, so a very primitive NIC can just receive all traffic and let the driver or network stack decide if the host wants a particular frame. On output, the network stack can usually put any source MAC address into the frame -- it's true for the most of Ethernet network interfaces. So MAC addresses are always fake in a sense, as neither the hardware nor the medium design enforces them. If I understand your case right, the two processors, CPU and SP, share a hardware buffer, in which they can put some data for the other side, e.g., an Ethernet frame, and then prod the other side with an interrupt. That fits the Ethernet model ideally, so there should be no need for hacks unless the other side, the SP running a special Linux, takes the whole thing wrong. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf and IP frame lengths
On Mon, Apr 16, 2007 at 05:14:06PM +1000, Alan Garfield wrote: Hi all! A question, is it ok to just say pass an entire rx buffer of your ethernet device up the chain and let the ip stack figure out the frame size. I have a device that can only ever receive 255 bytes of data, I receive this data from a buffer in the PRS. On an interrupt I read this data out of the PRS buffer into a local buffer, which I then :- eh = mtod(m, struct ether_header *); // Copy buf into mbuf Please use plain C comments for the sake of style(9) if you want your driver to be a good example. bcopy(buf + 1, (char *)eh, FIFO_SIZE - 1); See below. // Set the header length m-m_pkthdr.len = m-m_len = FIFO_SIZE - 1; Ditto. JNET_UNLOCK(sc); (*ifp-if_input)(ifp, m); JNET_LOCK(sc); FIFO_SIZE = 256, minus 1 for a control character in the device (which handily keeps under the 256 frame size). The constant 1 there is worth a symbolic name. E.g.: /* The offset of an actual Ethernet frame into the FIFO */ #define FRAME_OFFSET1 /* XXX is frame size fixed? */ #define FRAME_SIZE (FIFO_SIZE - FRAME_OFFSET) The interface is working just fine, but I'm not sure if I'm completely correct in the way I'm doing this. AFAIK it's OK to pass a longer mbuf chain. E.g., real Ethernet has a limit on minimum frame size, which is 46 bytes of payload plus a header and an FCS, and Ethernet II encapsulation doesn't specify payload size; but it doesn't mean that you can't send an IPv4 packet with less than 26 bytes of IP payload over Ethernet. My only reservation is that less data could be copied from the device memory if the driver knew the actual frame size, but your device might have no such notion at all, relying on the upper layer, such as IP, to specify accurate data size. I've tried casting the buffer to struct ip* to get ip-ip_len but I always get a dereferencing pointer to incomplete type error (don't exactly know why). Perhaps it's because your driver doesn't include all IP related headers. But in fact it shouldn't try to analyze IP headers because that isn't its job. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a simple patch to enable RFC2640 for /usr/libexec/ftpd
On Tue, Apr 17, 2007 at 04:43:32PM +0800, Zhang Weiwu wrote: On Tue, 2007-04-17 at 10:37 +0300, Nikos Vassiliadis wrote: On Monday 16 April 2007 21:24, Zhang Weiwu wrote: Pieter de Goeje ??: I think your patch looks good, however there have been some changes to ftpd since 6.1. Also, since lukemftp is imported from NetBSD, you might want to contact the original author so future imports won't discard this new feature. Original author of lukemftp? I never used that software before, but would be glad to try as next option and see if I can patch that too. lukemftp is the former name of tnftp, which is known in FreeBSD as the native ftp client and server. So it would be better to send your pathes directly to them, Luke Mewburn or the NetBSD project. http://freshmeat.net/projects/tnftp/ Okay, now I got it, so /usr/libexec/ftpd is simply /usr/libexec/lukemftpd's copy or reconfigured version. Oh, what sad times are these when passing ruffians can say Ni at will to old ladies. There is a pestilence upon this land! nothing is sacred. Even those who arrange and design shrubberies are under considerable economic stress at this point in time. -- Monty Python and the Holy Grail In fact, it's tnftpd (aka, lukemftpd) that is a copy or reconfigured version. :-) We still stick to the original BSD version of ftpd because it has much less configuration knobs, which means less opportunities for errors and security implications in simple scenarios. FreeBSD ftpd is also believed to perform better than tnftpd when all you need is to serve a bunch of files to the public w/o fine-grained access controls or data rate limits. Nevertheless, an imported version of tnftpd is also available in the base system as /usr/libexec/lukemftpd for more complex cases so that FreeBSD users don't need to install hairy ftpd ports unless they have really peculiar needs. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a simple patch to enable RFC2640 for /usr/libexec/ftpd
On Tue, Apr 17, 2007 at 11:23:00AM +0800, Zhang Weiwu wrote: Giorgos Keramidas : On 2007-04-16 20:07, Zhang Weiwu [EMAIL PROTECTED] wrote: I am not actively involved in FreeBSD development. I am an ordinary user and this is my first post on this list so please just redirect me to correct place if I posted OT. I know probably ftpd is not going to accept changes for a lot of reasons, and I think it's reasonable if ftpd is not accepting anything but patches that satisfies basic requirements. Here is a patch to enable ftpd for RFC2640, I think this is a very basic requirement so I hope it can be accepted and used in next release: That's a reasonable feature request. Can you please file a problem report for this? If you need help with filing a bug report, you can follow the links from: http://www.FreeBSD.org/ = Support = Submit a Problem Report or I can help you with the process of submitting one. Done, id 111714 Thanks! I've had FEAT support for ftpd on my to-do list for quite a while. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFI: Ethernet driver ported from Linux
On Wed, Apr 18, 2007 at 11:00:32AM +1000, Alan Garfield wrote: On Tue, 2007-04-17 at 21:16 +0400, Yar Tikhiy wrote: In addition to the other advise, you might also look at if_ed.c. It is a little complicated since it talks to real hardware, and that hardware is, ummm, a little icky. That little thing Alan is writing a driver for should be simpler and clearer than the ed(4) hw, so Alan's driver will be a source of knowledge itself when it's complete. :-) It can be a good companion for if_edsc, as the latter doesn't work with hardware at all and fails to illustrate some important points due to that. Thanks for your comments. :) I just wish I could figure out what all this rtrequest/arp stuff was about so I could finish it. :) If anyone wants to look at the code just pop me an email. It's based on a GPL driver (although there isn't anything really left of it other than #defines and a few comments, the code is all new) so I don't know how/if I can get it added to FreeBSD HEAD. Anyway, back to figuring out arp. UGH! As a rule, an Ethernet driver needn't worry about ARP by itself because ARP has own separate module in the network stack. Does your driver have a partucular reason to? -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFI: Ethernet driver ported from Linux
On Mon, Apr 09, 2007 at 10:23:00PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Alan Garfield [EMAIL PROTECTED] writes: : I'd like to port/re-write this driver for FreeBSD but I cannot find : enough documentation and examples of a basic Ethernet driver for : FreeBSD. (if_wlan and if_ef look like good candidates but if_clone and : the miibus confuse me a bit and there isn't any clear docs on them) : : Can someone point me in the direction of an example or the relevant man : pages I should be reading to help with this. : : The device driver for Linux seems quite simple. : : Any help would be gratefully appreciated. In addition to the other advise, you might also look at if_ed.c. It is a little complicated since it talks to real hardware, and that hardware is, ummm, a little icky. That little thing Alan is writing a driver for should be simpler and clearer than the ed(4) hw, so Alan's driver will be a source of knowledge itself when it's complete. :-) It can be a good companion for if_edsc, as the latter doesn't work with hardware at all and fails to illustrate some important points due to that. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed -i
On Fri, Mar 30, 2007 at 09:21:33PM +0400, Yar Tikhiy wrote: [...] If we've started to delete the pattern space, we should print the text in place of it because `c' is for `change'. BSD and GNU seds have this bug, but Solaris sed doesn't have it. [...] By the way, I found myself w/o a Solaris account, but I was able to build Solaris sed in FreeBSD quickly from the OpenSolaris sources. All it took was downloading the following files: http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed.h http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed0.c http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed1.c http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbhead/regexp.h and issuing this command: cc -I. -o sed sed*.c Voila! (Their regexp.h offers definitions of its functions, not just their prototypes, which made my task very easy.) Perhaps other basic tools from Solaris could be built in this way for the purpose of testing, too, in case one needs them but has no Solaris account at hand. Another $0.02 from yours truly. :-) -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed -i
On Tue, Mar 27, 2007 at 12:11:06PM +0100, Alex Zbyslaw wrote: Yar Tikhiy wrote: Aren't sed's addresses required to be cumulative across its input files? http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html That makes sense for filter mode because it's equvalent to concatenating the files in advance: cat files ... | sed expression OTOH, in-place mode selected by a -i option can be seen as follows: for f in files ...; do sed expression $f $f.tmp mv $f $f.bak mv $f.tmp $f done I.e., each file preserves its individuality. This can be at logical conflict with cumulative addresses across all files. As a Joe Random sed user, I'd agree with Yar. The GNU behaviour makes more sense in most practical examples I can think of. Perhaps a touch of feaping creaturism, but we could just add a -I flag which behaved as -i does now, and make -i behave as GNU. I bet I *could* construct examples where the current behaviour was what I desired. Thank you for supporting me! I've just looked at the code and it seems to me that it should be rather easy to preserve the current semantics under a -I flag, too. They are too neat to throw them away. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed -i
On Thu, Mar 29, 2007 at 11:19:44AM +0300, Diomidis Spinellis wrote: Yar Tikhiy wrote: Recently noticed that our sed(1) differs from its GNU analog in that in -i mode it considers all files as a single sequence of lines while the latter treats each file independently. The in-line mode isn't in POSIX, so it isn't really clear which way is correct. Here is a couple of practical consequences: - our sed won't act on a numeric range of lines in each file, as in: sed -i '' 2,5d *, which may be counter-intuitive. - our sed's line ranges can span file boundaries in -i mode. If the second feature isn't important, I think we should use a separate line space for each file edited in-line, which is usually desired. Comments? P.S. Attached are a test script and outputs from it for our sed and GNU sed as found in a Linux I have access to. I believe the GNU interpretation of lines in -i makes sense. Hurray! I've got a blessing from the author of BSD sed himself! :-) Thank you! May I take a bit more of your time? I've started playing with the code and noticed another gray area. Namely a `c' command won't print the text if having 2 addresses with the 2nd address beyond the actual end of file. For example: %%% BEGIN $ jot 9 | sed '6,15c\ text ' test 1 2 3 4 5 %%% END Ditto with RE's, if the 2nd RE doesn't match any line: %%% BEGIN $ jot 9 | sed '/6/,/15/c\ text ' test 1 2 3 4 5 %%% END If we've started to delete the pattern space, we should print the text in place of it because `c' is for `change'. BSD and GNU seds have this bug, but Solaris sed doesn't have it. Do you think we should fix it, too? Thanks! -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed -i
On Fri, Mar 30, 2007 at 08:30:54PM +0300, Diomidis Spinellis wrote: Yar Tikhiy wrote: May I take a bit more of your time? I've started playing with the code and noticed another gray area. Namely a `c' command won't print the text if having 2 addresses with the 2nd address beyond the actual end of file. For example: %%% BEGIN $ jot 9 | sed '6,15c\ text ' test 1 2 3 4 5 %%% END Ditto with RE's, if the 2nd RE doesn't match any line: %%% BEGIN $ jot 9 | sed '/6/,/15/c\ text ' test 1 2 3 4 5 %%% END If we've started to delete the pattern space, we should print the text in place of it because `c' is for `change'. BSD and GNU seds have this bug, but Solaris sed doesn't have it. Do you think we should fix it, too? Thanks! Yes, it sounds like a bug to me. Thanks! I hope I'll make a fix for both issues soon, it's in the works already. The issues appear related in the code. Note that a couple of weeks ago I added the regression tests I originally wrote in 1992 to the FreeBSD regression test suite. Given that you are writing test cases it would be very nice to follow the format used in src/tools/regression/usr.bin/sed/regress.t, so that we can add them to the test suite. Thank you for pointing me out at the format! Sorry, I haven't looked at it yet, but I've noticed the tests going into the tree and remembered that I should pay attention to writing new regression tests and running the existing tests if I change sed. Of course, I'll use the standard format. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Locking etc. (Long, boring, redundant, newbie questions)
On Wed, Mar 28, 2007 at 10:40:58AM +0100, Robert Watson wrote: Spin locks are, FYI, slower than default mutexes. The reason is that they have to do more work: they not only perform an atomic operation/memory barrier to set the cross-CPU lock state, but they also have to disable interrupts to synchronize with fast interrupt handlers. In general, you are right: you should only use a spin mutex if you are running in a fast handler, or synchronizing with a fast handler. The one general exception is the scheduler itself, which must protect its data structures with spin locks in order to implement sleeping primitives. As such, the scheduler lock and various other low level locks (such as in turnstiles) are implemented with spin locks and not default mutexes. Since default mutexes spin adaptively, the reduced overhead of contention experienced with spin locks (i.e., no scheduler overhead for simple contention cases) is also experienced with default mutexes. By the way, could the following observation of mine be related to the high cost of spin mutexes? While doing some measurements of the performance of our vlan driver in a router, I found that with RELENG_6 the pps rate through the router degraded considerably (by ~100Kpps) if its physical interfaces used hardware vlan tagging. I attributed that to the overhead of allocating and freeing a mbuf tag for each packet as it entered and then left the router. I used hwpmc and pmcstat to see which kernel functions took most time and found that critical_exit() made top 5 in the list of CPU time eaters if the network interfaces were using hardware vlan tagging. The machine was an UP amd64, but it ran FreeBSD/i386, with an UP kernel. As I can see from the code, critical_exit() may grab and later release a spin mutex. I've got a hazy recollection that our kernel memory allocator uses critical sections to protect its per-CPU structures. That's why I suspect that the effect I observed may have its roots in the behaviour of spin mutexes. Could it be so? Thanks! -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed -i
On Mon, Mar 26, 2007 at 08:57:14PM +0530, Joseph Koshy wrote: Recently noticed that our sed(1) differs from its GNU analog in that in -i mode it considers all files as a single sequence of lines while the latter treats each file independently. The in-line mode isn't in POSIX, so it isn't really clear which way is correct. Aren't sed's addresses required to be cumulative across its input files? http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html That makes sense for filter mode because it's equvalent to concatenating the files in advance: cat files ... | sed expression OTOH, in-place mode selected by a -i option can be seen as follows: for f in files ...; do sed expression $f $f.tmp mv $f $f.bak mv $f.tmp $f done I.e., each file preserves its individuality. This can be at logical conflict with cumulative addresses across all files. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sed -i
Hi,
Recently noticed that our sed(1) differs from its GNU analog in
that in -i mode it considers all files as a single sequence of lines
while the latter treats each file independently. The in-line mode
isn't in POSIX, so it isn't really clear which way is correct.
Here is a couple of practical consequences:
- our sed won't act on a numeric range of lines in each file,
as in: sed -i '' 2,5d *, which may be counter-intuitive.
- our sed's line ranges can span file boundaries in -i mode.
If the second feature isn't important, I think we should use
a separate line space for each file edited in-line, which is
usually desired.
Comments?
P.S. Attached are a test script and outputs from it for our
sed and GNU sed as found in a Linux I have access to.
--
Yar
% sed.t %
#!/bin/sh
files=1 2 3
lines=1 2 3 4 5
makefiles()
{
for f in $files; do
for n in $lines; do
echo $n
done $f
done
}
echo ### Test 1 ###
makefiles
sed -i.bak 1,3d $files
tail $files
echo ### Test 2 ###
makefiles
sed -i.bak /5/,/2/d $files
tail $files
% output using our sed %
### Test 1 ###
== 1 ==
4
5
== 2 ==
1
2
3
4
5
== 3 ==
1
2
3
4
5
### Test 2 ###
== 1 ==
1
2
3
4
== 2 ==
3
4
== 3 ==
3
4
% output using GNU sed %
### Test 1 ###
== 1 ==
4
5
== 2 ==
4
5
== 3 ==
4
5
### Test 2 ###
== 1 ==
1
2
3
4
== 2 ==
1
2
3
4
== 3 ==
1
2
3
4
% END %
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Single UDP sockets : duplex capable?
On Tue, Nov 28, 2006 at 04:24:08PM -0500, Devon H. O'Dell wrote:
2006/11/28, Garrett Cooper [EMAIL PROTECTED]:
Hello,
Just wondering, abstractly..
Both sides can read from and write to the socket file descriptor.
You'll need to develop a protocol to determine when either given side
is expecting to receive or to send data (if both sides sit around in
read(2), you're not going to get much done) :)
... and if you want asynchronous conversation, i.e., data coming
anytime, consider using non-blocking sockets with select(2), poll(2),
or kqueue(2). The particular choice depends upon the requirements
on the portability and performance of the application. If you
target at as much systems as possible, using a ready-made wrapper
library such as libevent can be an option.
-
| A -[socket (UDP)]- B |
-
A creates a UDP socket (call it 's1') to talk to B.
Can B use the same socket ('s2') to talk to A using read(2) or
recv(2), or does A have to accept(2) traffic from B using a different
socket?
The programming language I'm using is C (not C++).
--
Yar
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File trees: the deeper, the weirder
On Mon, Oct 30, 2006 at 03:47:37PM +0200, Kostik Belousov wrote:
On Mon, Oct 30, 2006 at 04:05:19PM +0300, Yar Tikhiy wrote:
On Sun, Oct 29, 2006 at 11:32:58AM -0500, Matt Emmerton wrote:
[ Restoring some OP context.]
On Sun, Oct 29, 2006 at 05:07:16PM +0300, Yar Tikhiy wrote:
As for the said program, it keeps its 1 Hz pace, mostly waiting on
vlruwk. It's killable, after a delay. The system doesn't show ...
Weird, eh? Any ideas what's going on?
I would guess that you need a new vnode to create the new file, but no
vnodes are obvious candidates for freeing because they all have a child
directory in use. Is there some sort of vnode clearing that goes on
every
second if we are short of vnodes?
See sys/vfs_subr.c, subroutine getnewvnode(). We call msleep() if we're
waiting on vnodes to be created (or recycled). And just look at the 'hz'
parameter passed to msleep()!
The calling process's mkdir() will end up waiting in getnewvnode() (in
vlruwk state) while the vnlru kernel thread does it's thing (which is to
recycle vnodes.)
Either the vnlru kernel thread has to work faster, or the caller has to
sleep less, in order to avoid this lock-step behaviour.
I'm afraid that, though your analysis is right, you arrive at wrong
conclusions. The process waits for the whole second in getnewvnode()
because the vnlru thread cannot free as much vnodes as it wants to.
vnlru_proc() will wake up sleepers on vnlruproc_sig (i.e.,
getnewvnode()) only if (numvnodes = desiredvnodes * 9 / 10).
Whether this condition is attainable depends on vlrureclaim() (called
from the vnlru thread) freeing vnodes at a sufficient rate. Perhaps
vlrureclaim() just can't keep the pace at this conditions.
debug.vnlru_nowhere increasing is an indication of that. Consequently,
each getnewvnode() call sleeps 1 second, then grabs a vnode beyond
desiredvnodes. It's no surprise that the 1 second delays start to
appear after approx. kern.maxvnodes directories were created.
I think that David is right. The references _from_ the directory make it
immune
to vnode reclamation. Try this patch. It is very unfair for lsof.
Index: sys/kern/vfs_subr.c
===
RCS file: /usr/local/arch/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.685
diff -u -r1.685 vfs_subr.c
--- sys/kern/vfs_subr.c 2 Oct 2006 07:25:58 - 1.685
+++ sys/kern/vfs_subr.c 30 Oct 2006 13:44:59 -
@@ -582,7 +582,7 @@
* If it's been deconstructed already, it's still
* referenced, or it exceeds the trigger, skip it.
*/
- if (vp-v_usecount || !LIST_EMPTY((vp)-v_cache_src) ||
+ if (vp-v_usecount || /* !LIST_EMPTY((vp)-v_cache_src) || */
(vp-v_iflag VI_DOOMED) != 0 || (vp-v_object != NULL
vp-v_object-resident_page_count trigger)) {
VI_UNLOCK(vp);
@@ -607,7 +607,7 @@
* interlock, the other thread will be unable to drop the
* vnode lock before our VOP_LOCK() call fails.
*/
- if (vp-v_usecount || !LIST_EMPTY((vp)-v_cache_src) ||
+ if (vp-v_usecount || /* !LIST_EMPTY((vp)-v_cache_src) || */
(vp-v_object != NULL
vp-v_object-resident_page_count trigger)) {
VOP_UNLOCK(vp, LK_INTERLOCK, td);
By the way, what do you think v_cache_src is for? The only two
places it is used in the kernel are in the unused function
cache_leaf_test() and this one, in vlrureclaim(). Is its main
purpose just to keep directory vnodes that are referenced by nc_dvp
in some namecache entries?
--
Yar
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File trees: the deeper, the weirder
On Sat, Nov 18, 2006 at 01:05:44PM +0200, Kostik Belousov wrote:
On Sat, Nov 18, 2006 at 12:54:00PM +0300, Yar Tikhiy wrote:
On Mon, Oct 30, 2006 at 03:47:37PM +0200, Kostik Belousov wrote:
On Mon, Oct 30, 2006 at 04:05:19PM +0300, Yar Tikhiy wrote:
On Sun, Oct 29, 2006 at 11:32:58AM -0500, Matt Emmerton wrote:
[ Restoring some OP context.]
On Sun, Oct 29, 2006 at 05:07:16PM +0300, Yar Tikhiy wrote:
As for the said program, it keeps its 1 Hz pace, mostly waiting on
vlruwk. It's killable, after a delay. The system doesn't show
...
Weird, eh? Any ideas what's going on?
I would guess that you need a new vnode to create the new file, but
no
vnodes are obvious candidates for freeing because they all have a
child
directory in use. Is there some sort of vnode clearing that goes on
every
second if we are short of vnodes?
See sys/vfs_subr.c, subroutine getnewvnode(). We call msleep() if
we're
waiting on vnodes to be created (or recycled). And just look at the
'hz'
parameter passed to msleep()!
The calling process's mkdir() will end up waiting in getnewvnode() (in
vlruwk state) while the vnlru kernel thread does it's thing (which
is to
recycle vnodes.)
Either the vnlru kernel thread has to work faster, or the caller has
to
sleep less, in order to avoid this lock-step behaviour.
I'm afraid that, though your analysis is right, you arrive at wrong
conclusions. The process waits for the whole second in getnewvnode()
because the vnlru thread cannot free as much vnodes as it wants to.
vnlru_proc() will wake up sleepers on vnlruproc_sig (i.e.,
getnewvnode()) only if (numvnodes = desiredvnodes * 9 / 10).
Whether this condition is attainable depends on vlrureclaim() (called
from the vnlru thread) freeing vnodes at a sufficient rate. Perhaps
vlrureclaim() just can't keep the pace at this conditions.
debug.vnlru_nowhere increasing is an indication of that. Consequently,
each getnewvnode() call sleeps 1 second, then grabs a vnode beyond
desiredvnodes. It's no surprise that the 1 second delays start to
appear after approx. kern.maxvnodes directories were created.
I think that David is right. The references _from_ the directory make it
immune
to vnode reclamation. Try this patch. It is very unfair for lsof.
Index: sys/kern/vfs_subr.c
===
RCS file: /usr/local/arch/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.685
diff -u -r1.685 vfs_subr.c
--- sys/kern/vfs_subr.c 2 Oct 2006 07:25:58 - 1.685
+++ sys/kern/vfs_subr.c 30 Oct 2006 13:44:59 -
@@ -582,7 +582,7 @@
* If it's been deconstructed already, it's still
* referenced, or it exceeds the trigger, skip it.
*/
- if (vp-v_usecount || !LIST_EMPTY((vp)-v_cache_src) ||
+ if (vp-v_usecount || /* !LIST_EMPTY((vp)-v_cache_src) || */
(vp-v_iflag VI_DOOMED) != 0 || (vp-v_object != NULL
vp-v_object-resident_page_count trigger)) {
VI_UNLOCK(vp);
@@ -607,7 +607,7 @@
* interlock, the other thread will be unable to drop the
* vnode lock before our VOP_LOCK() call fails.
*/
- if (vp-v_usecount || !LIST_EMPTY((vp)-v_cache_src) ||
+ if (vp-v_usecount || /* !LIST_EMPTY((vp)-v_cache_src) || */
(vp-v_object != NULL
vp-v_object-resident_page_count trigger)) {
VOP_UNLOCK(vp, LK_INTERLOCK, td);
By the way, what do you think v_cache_src is for? The only two
places it is used in the kernel are in the unused function
cache_leaf_test() and this one, in vlrureclaim(). Is its main
purpose just to keep directory vnodes that are referenced by nc_dvp
in some namecache entries?
I think that yes. Now, it mostly gives immunity for the vnodes that
could be used for getcwd()/lsof path lookups through namecache.
Another purpose of v_cache_src that I missed is to allow
for removing all namecache entries with nc_dvp pointing
to a particular vnode when the vnode is recycled so that
we don't end up with stale nc_dvp's in the namecache.
Perhaps this is the main role v_cache_src plays.
Does my change helped on you load ?
Your hack works, thanks! Your analysis of the problem proves
correct. And I'm gaining some understanding of it, too :-)
cache_leaf_test() seems to be way to go. By partitioning vlru reclaim into
two stages - first, which reclaim leaf vnodes (that it, vnodes that do
not contain child dirs in namecache), and second, which will be fired only
if first stage failed to free something and simply ignores v_cache_src, as
in my change. See comment for rev
Re: File trees: the deeper, the weirder
On Sun, Oct 29, 2006 at 04:13:24PM +0100, Ulrich Spoerlein wrote: Yar Tikhiy wrote: Weird, eh? Any ideas what's going on? None, but have you tried without soft updates? Yes, I tried, but no soft updates didn't affect the picture. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File trees: the deeper, the weirder
On Sun, Oct 29, 2006 at 03:22:27PM +, David Malone wrote: On Sun, Oct 29, 2006 at 05:07:16PM +0300, Yar Tikhiy wrote: Weird, eh? Any ideas what's going on? I would guess that you need a new vnode to create the new file, but no vnodes are obvious candidates for freeing because they all have a child directory in use. Is there some sort of vnode clearing that goes on every second if we are short of vnodes? It seems to me that in Unix, when a process chdir's to a directory, the parent directory of the latter (and the whole chain of them up to the root dir) isn't kept busy. Is this untrue? -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File trees: the deeper, the weirder
On Sun, Oct 29, 2006 at 11:32:58AM -0500, Matt Emmerton wrote: [ Restoring some OP context.] On Sun, Oct 29, 2006 at 05:07:16PM +0300, Yar Tikhiy wrote: As for the said program, it keeps its 1 Hz pace, mostly waiting on vlruwk. It's killable, after a delay. The system doesn't show ... Weird, eh? Any ideas what's going on? I would guess that you need a new vnode to create the new file, but no vnodes are obvious candidates for freeing because they all have a child directory in use. Is there some sort of vnode clearing that goes on every second if we are short of vnodes? See sys/vfs_subr.c, subroutine getnewvnode(). We call msleep() if we're waiting on vnodes to be created (or recycled). And just look at the 'hz' parameter passed to msleep()! The calling process's mkdir() will end up waiting in getnewvnode() (in vlruwk state) while the vnlru kernel thread does it's thing (which is to recycle vnodes.) Either the vnlru kernel thread has to work faster, or the caller has to sleep less, in order to avoid this lock-step behaviour. I'm afraid that, though your analysis is right, you arrive at wrong conclusions. The process waits for the whole second in getnewvnode() because the vnlru thread cannot free as much vnodes as it wants to. vnlru_proc() will wake up sleepers on vnlruproc_sig (i.e., getnewvnode()) only if (numvnodes = desiredvnodes * 9 / 10). Whether this condition is attainable depends on vlrureclaim() (called from the vnlru thread) freeing vnodes at a sufficient rate. Perhaps vlrureclaim() just can't keep the pace at this conditions. debug.vnlru_nowhere increasing is an indication of that. Consequently, each getnewvnode() call sleeps 1 second, then grabs a vnode beyond desiredvnodes. It's no surprise that the 1 second delays start to appear after approx. kern.maxvnodes directories were created. Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File trees: the deeper, the weirder
On Mon, Oct 30, 2006 at 04:05:19PM +0300, Yar Tikhiy wrote: On Sun, Oct 29, 2006 at 11:32:58AM -0500, Matt Emmerton wrote: [ Restoring some OP context.] On Sun, Oct 29, 2006 at 05:07:16PM +0300, Yar Tikhiy wrote: As for the said program, it keeps its 1 Hz pace, mostly waiting on vlruwk. It's killable, after a delay. The system doesn't show ... Weird, eh? Any ideas what's going on? I would guess that you need a new vnode to create the new file, but no vnodes are obvious candidates for freeing because they all have a child directory in use. Is there some sort of vnode clearing that goes on every second if we are short of vnodes? See sys/vfs_subr.c, subroutine getnewvnode(). We call msleep() if we're waiting on vnodes to be created (or recycled). And just look at the 'hz' parameter passed to msleep()! The calling process's mkdir() will end up waiting in getnewvnode() (in vlruwk state) while the vnlru kernel thread does it's thing (which is to recycle vnodes.) Either the vnlru kernel thread has to work faster, or the caller has to sleep less, in order to avoid this lock-step behaviour. I'm afraid that, though your analysis is right, you arrive at wrong conclusions. The process waits for the whole second in getnewvnode() because the vnlru thread cannot free as much vnodes as it wants to. vnlru_proc() will wake up sleepers on vnlruproc_sig (i.e., getnewvnode()) only if (numvnodes = desiredvnodes * 9 / 10). Whether this condition is attainable depends on vlrureclaim() (called from the vnlru thread) freeing vnodes at a sufficient rate. Perhaps vlrureclaim() just can't keep the pace at this conditions. debug.vnlru_nowhere increasing is an indication of that. Consequently, each getnewvnode() call sleeps 1 second, then grabs a vnode beyond desiredvnodes. It's no surprise that the 1 second delays start to appear after approx. kern.maxvnodes directories were created. Sorry, I hit the send button too early, before telling what my own conclusions were. Well, we may try to sleep less in getnewvnode(), or arrange the vnlru thread to wake up getnewvnode() after a failed attempt to free more vnodes, but this will mean unlimited growth of the number of allocated vnodes. Perhaps we should see what prevents vlrureclaim() from freeing enough vnodes to sustain the vnode pressure of the pattern at issue. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: File trees: the deeper, the weirder
On Mon, Oct 30, 2006 at 03:47:37PM +0200, Kostik Belousov wrote: I think that David is right. The references _from_ the directory make it immune to vnode reclamation. Try this patch. It is very unfair for lsof. Sorry, but I'm leaving now and I'll be unable to play with your patch until I return in a fortnight. I hope I'll have a bit of free time to study our modern namei cache design while off-line. :-) -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
File trees: the deeper, the weirder
Folks,
Here's a funny observation. A program essentially doing:
for (;;) {
mkdir(foo);
chdir(foo);
}
starts as fast as the system permits, but settles to *exactly* one
cycle per second at some depth that seems to depend only on the
amount of RAM in the machine. An array sized at boot time seems
to play a role there: for 128M the depth is ~7800, for 512M it's
~35000. The system feels very slow then, but only due to the fact
that fs-related syscalls often take *exactly* one second to complete.
As for the said program, it keeps its 1 Hz pace, mostly waiting on
vlruwk. It's killable, after a delay. The system doesn't show
any signs of instability, and it's mostly idle according to top or
systat!
Weird, eh? Any ideas what's going on?
--
Yar
P.S. Here's the test program generalised and enhanced with timing
diagnostics (-v). By setting several -v options, you'll get the
diagnostics more often, exponentially.
/*
* Usage:
*
* xdir [-v -v ...] name-length tree-depth
*
* This program will create a chain of subdirectories rooted
* in the current directory. Each subdir's name will be:
*
* 000 ... [ name-lenght times ] ... 000
*
* The total depth will be tree-depth:
*
* 000+/000+/ ... [ tree-depth times] ... /000+/000+
*/
#include sys/types.h
#include sys/stat.h
#include sys/time.h
#include err.h
#include limits.h
#include stdio.h
#include stdlib.h
#include unistd.h
int verbose;
int
main(int argc, char **argv)
{
int i, n, m, r;
double dt;
struct timeval tv0, tv;
char buf[NAME_MAX + 1];
while ((i = getopt(argc, argv, v)) != -1)
switch (i) {
case 'v':
verbose++;
break;
default:
errx(2, bad option);
}
argc -= optind;
argv += optind;
if (argv[0] == NULL || (n = atoi(argv[0])) = 0)
errx(2, bad length);
if (argv[1] == NULL || (m = atoi(argv[1])) = 0)
errx(2, bad depth);
if (n NAME_MAX)
errx(2, too long);
sprintf(buf, %0*d, n, 0);
r = 1000; /* fool gcc */
if (verbose) {
for (i = 1; i verbose r 9; i++)
r /= 10;
gettimeofday(tv0, NULL);
}
for (i = 1; i = m; i++) {
if (mkdir(buf, 0700) == -1)
err(2, mkdir %s, buf);
if (chdir(buf) == -1)
err(2, chdir %s, buf);
if (verbose (i % r) == 0) {
gettimeofday(tv, NULL);
dt = tv.tv_usec - tv0.tv_usec;
dt /= 100;
dt += tv.tv_sec - tv0.tv_sec;
printf(%d (%.1lf)... , i, r / dt);
fflush(stdout);
tv0 = tv;
}
}
return (0);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Real time privileges for non-root users
On Thu, Jun 22, 2006 at 03:47:44PM +0100, mal content wrote:
Hello.
Is it possible to grant real-time privileges to ordinary
users (not root) under FreeBSD? I'm doing some audio
work and I'd like to give real time privileges to my user id.
While I can't think of an existing user-friendly solution, you can
use available tools and interfaces to satisfy your needs.
The easiest, but not the smartest, way is to use rtprio(1).
From rtprio(2):
Realtime and idle priority is inherited through fork() and exec().
That is, you can start a shell with higher real-time priority, and
it will hand its priority down to its children:
$ su
# rtprio 1 su yourself
A smarter way is to use login.conf(5). Idle or real-time priority
can be set for a login class, but the feature doesn't seem to be
documented anywhere except in the code itself. The respective block
from src/lib/libutil/login_class.c is as follows:
/* Set the process priority */
if (flags LOGIN_SETPRIORITY) {
p = login_getcapnum(lc, priority, LOGIN_DEFPRI, LOGIN_DEFPRI);
if(p PRIO_MAX) {
rtp.type = RTP_PRIO_IDLE;
rtp.prio = p - PRIO_MAX - 1;
p = (rtp.prio RTP_PRIO_MAX) ? 31 : p;
if(rtprio(RTP_SET, 0, rtp))
syslog(LOG_WARNING, rtprio '%s' (%s): %m,
pwd-pw_name, lc ? lc-lc_class : LOGIN_DEFCLASS);
} else if(p PRIO_MIN) {
rtp.type = RTP_PRIO_REALTIME;
rtp.prio = abs(p - PRIO_MIN + RTP_PRIO_MAX);
p = (rtp.prio RTP_PRIO_MAX) ? 1 : p;
if(rtprio(RTP_SET, 0, rtp))
syslog(LOG_WARNING, rtprio '%s' (%s): %m,
pwd-pw_name, lc ? lc-lc_class : LOGIN_DEFCLASS);
} else {
if (setpriority(PRIO_PROCESS, 0, (int)p) != 0)
syslog(LOG_WARNING, setpriority '%s' (%s): %m,
pwd-pw_name, lc ? lc-lc_class : LOGIN_DEFCLASS);
}
}
Can you grok it? ;-)
--
Yar
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: curious 6.1 GRE behaviour.
On Wed, Jun 21, 2006 at 12:07:33AM -0400, David Gilbert wrote: I was using some GRE tunnels on 6.1-RELEASE recently. The odd thing I'm finding is that the initial creation of the tunnel using cloned_interfaces and ifconfig_gre0=blah results in the gre0 interface being created without the running bit set. tcpdump on the interface or even ifconfig gre0 up starts it. This is also odd because the UP flag is set. Ie: [1:2:[EMAIL PROTECTED]:~ ifconfig [...] gre0: flags=9011UP,POINTOPOINT,LINK0,MULTICAST mtu 1476 tunnel inet x.x.x.x -- y.y.y.y inet6 fe80::240:63ff:fee2:eae9%gre0 prefixlen 64 scopeid 0x5 inet a.a.a.a -- b.b.b.b netmask 0xfffe [1:2:[EMAIL PROTECTED]:~ ifconfig gre0 up [1:3:[EMAIL PROTECTED]:~ ifconfig [...] gre0: flags=9051UP,POINTOPOINT,RUNNING,LINK0,MULTICAST mtu 1476 tunnel inet x.x.x.x -- y.y.y.y inet6 fe80::240:63ff:fee2:eae9%gre0 prefixlen 64 scopeid 0x5 inet a.a.a.a -- b.b.b.b netmask 0xfffe FWIW, gre(4) in CURRENT doesn't seem to have this problem. However, it has a different one: the system will lose its default route upon the destruction of a gre interface albeit the default route is via a different interface. Aha, it appears to be due to the activity of /etc/pccard_ether, not gre(4) itself. Looks like a way of fast and easy foot-shooting unless one remembers to set removable_route_flush to NO. Are we drifting from the server/router market to the desktop/mobile market?.. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stack frame problem in gdb
On Tue, May 16, 2006 at 11:12:40AM +0400, Yar Tikhiy wrote:
Has our stock GDB lost the ability to set the current stack frame
by its address? In 4.11-STABLE, the old recipe from the Developer's
Handbook still works:
frame frame_addr instruction_ptr
Alas, it no longer works in RELENG_6 or CURRENT (tested on i386 and
amd64.) A sample typescript is attached. It boils down to the
following: The frame command accepts one argument at most in the
new GDB, which is taken for the address of a frame if it's sufficiently
large. Refusing now to read the instruction pointer value from the
command line, GDB sets it to 0 -- a smart guess, damn it. Finally,
GDB crashes on the bogus frame it made up.
It seems to be a genuine GDB 6 i386 bug reported as early as in
2002: http://sourceware.org/ml/gdb/2002-11/msg00263.html. It
exists in Linux, too, as tested in Debian with GDB 6.3.
Moreover, GDB 6 fails to assign correct addresses to stack frames.
This might be related to the former issue, as testing on alpha
showed (see below.)
Does anybody know GDB folks who can help in fixing the issues?
Example:
%%% GDB 6 i386 %%%
(gdb) i f 2
Stack frame at 0xbfbfeca8:
eip = 0x80484ac in b (test.c:13); saved eip 0x80484b8
called by frame at 0xbfbfecb0, caller of frame at 0xbfbfeca0
source language c.
Arglist at 0xbfbfeca0, args:
Locals at 0xbfbfeca0, Previous frame's sp is 0xbfbfeca8
Saved registers:
ebp at 0xbfbfeca0, eip at 0xbfbfeca4
(gdb) i f 3
Stack frame at 0xbfbfecb0:
eip = 0x80484b8 in c (test.c:18); saved eip 0x80484dd
called by frame at 0xbfbfecd0, caller of frame at 0xbfbfeca8
source language c.
Arglist at 0xbfbfeca8, args:
Locals at 0xbfbfeca8, Previous frame's sp is 0xbfbfecb0
Saved registers:
ebp at 0xbfbfeca8, eip at 0xbfbfecac
### The frame addresses were off by one frame. It was a coincidence,
### as the following tests on alpha will show. The addresses are just
### bogus.
%%% GDB 6 alpha %%%
(gdb) i f 2
Stack frame at 0x11ffeb80:
pc = 0x1287c in b (test.c:13); saved pc 0x128ac
called by frame at 0x11ffeb90, caller of frame at 0x11ffeb70
source language c.
Arglist at 0x11ffeb80, args:
Locals at 0x11ffeb80, Previous frame's sp is 0x11ffeb80
Saved registers:
fp at 0x11ffeb78, ra at 0x11ffeb70, pc at 0x11ffeb70
(gdb) i f 3
Stack frame at 0x11ffeb90:
pc = 0x128ac in c (test.c:18); saved pc 0x128dc
called by frame at 0x11ffeba0, caller of frame at 0x11ffeb80
source language c.
Arglist at 0x11ffeb90, args:
Locals at 0x11ffeb90, Previous frame's sp is 0x11ffeb90
Saved registers:
fp at 0x11ffeb88, ra at 0x11ffeb80, pc at 0x11ffeb80
### The frame addresses were just bogus.
### Let's look at frame 2 by its address:
(gdb) i f 0x11ffeb80 0x1287c
Stack frame at 0x11ffeb80:
pc = 0x1287c in b (test.c:14); saved pc 0x1284c
called by frame at 0x11ffeb70
source language c.
Arglist at 0x11ffeb60, args:
Locals at 0x11ffeb60, Previous frame's sp is 0x11ffeb60
Saved registers:
fp at 0x11ffeb58, ra at 0x11ffeb50, pc at 0x11ffeb50
### It's not frame 2! Which frame is it?..
(gdb) i f 0
Stack frame at 0x11ffeb60:
pc = 0x12810 in x (test.c:3); saved pc 0x1284c
called by frame at 0x11ffeb70
source language c.
Arglist at 0x11ffeb60, args:
Locals at 0x11ffeb60, Previous frame's sp is 0x11ffeb60
Saved registers:
fp at 0x11ffeb58, ra at 0x11ffeb50, pc at 0x11ffeb50
### Oops, GDB showed us frame 0 when we tried to look at
### the frame @ 0x11ffeb80!
%%% GDB 4 i386 %%%
(gdb) i f 2
Stack frame at 0xbfbff6f0:
eip = 0x804849f in b (test.c:13); saved eip 0x80484b7
called by frame at 0xbfbff700, caller of frame at 0xbfbff6e0
source language c.
Arglist at 0xbfbff6f0, args:
Locals at 0xbfbff6f0, Previous frame's sp is 0x0
Saved registers:
ebp at 0xbfbff6f0, eip at 0xbfbff6f4
(gdb) i f 3
Stack frame at 0xbfbff700:
eip = 0x80484b7 in c (test.c:18); saved eip 0x80484cf
called by frame at 0xbfbff710, caller of frame at 0xbfbff6f0
source language c.
Arglist at 0xbfbff700, args:
Locals at 0xbfbff700, Previous frame's sp is 0x0
Saved registers:
ebp at 0xbfbff700, eip at 0xbfbff704
### The good old GDB 4 was working OK...
--
Yar
P.S. The program used for the tests was as follows:
x()
{
return 1;
}
a()
{
return x();
}
b()
{
return a();
}
c()
{
return b();
}
main()
{
return c();
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Stack frame problem in gdb
Hi folks,
Has our stock GDB lost the ability to set the current stack frame
by its address? In 4.11-STABLE, the old recipe from the Developer's
Handbook still works:
frame frame_addr instruction_ptr
Alas, it no longer works in RELENG_6 or CURRENT (tested on i386 and
amd64.) A sample typescript is attached. It boils down to the
following: The frame command accepts one argument at most in the
new GDB, which is taken for the address of a frame if it's sufficiently
large. Refusing now to read the instruction pointer value from the
command line, GDB sets it to 0 -- a smart guess, damn it. Finally,
GDB crashes on the bogus frame it made up.
What do you think this is, a GDB bug or my misunderstanding? Thanks!
--
Yar
%cat test.c
main()
{
foo(1);
}
foo(a)
int a;
{
return (a + bar(a));
}
bar(x)
int x;
{
return (x * x);
}
%gcc -g test.c
%gdb a.out
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
(gdb) b bar
Breakpoint 1 at 0x80484d7: file test.c, line 15.
(gdb) r
Starting program: /usr/home/yar/a.out
Breakpoint 1, bar (x=1) at test.c:15
15 return (x * x);
(gdb) bt
#0 bar (x=1) at test.c:15
#1 0x080484c9 in foo (a=1) at test.c:9
#2 0x080484b2 in main () at test.c:3
(gdb) info f 1
Stack frame at 0xbfbfec30:
eip = 0x80484c9 in foo (test.c:9); saved eip 0x80484b2
called by frame at 0xbfbfec60, caller of frame at 0xbfbfec10
source language c.
Arglist at 0xbfbfec28, args: a=1
Locals at 0xbfbfec28, Previous frame's sp is 0xbfbfec30
Saved registers:
ebp at 0xbfbfec28, eip at 0xbfbfec2c
(gdb) frame 0xbfbfec30 0x80484c9
Too many args in frame specification
(gdb) frame 0xbfbfec30
#0 0x in ?? ()
(gdb) info f
Stack level 0, frame at 0xbfbfec30:
eip = 0x0; saved eip
/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/dwarf2-frame.c:613:
internal-error: dwarf2_frame_cache: Assertion `fde != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find(1) -d vs -prune; /etc/periodic/daily/100.clean-disks
On Wed, Mar 08, 2006 at 03:43:51PM +0100, Jilles Tjoelker wrote:
On Wed, Mar 08, 2006 at 02:21:51AM +0300, Yar Tikhiy wrote:
On Mon, Mar 06, 2006 at 06:40:58PM +0100, Jilles Tjoelker wrote:
Possible solutions/workarounds:
1. do still call -prune and some primaries without side effects
in pre-order even if -d is in effect, even though this does not
fit at all in find(1)'s design.
2. document the bug and run a find -x over all local r/w filesystems
in 100.clean-disks (-x and -d work together properly).
What would be the best way to go on?
The property of -prune with respect to -d is already documented on the
find(1) manpage.
Oh, didn't read that bit. Too busy reading the source code :P
As for 100.clean-disks, I fail to see why -prune is needed there.
One can mount a file system read-write at a directory of a read-only
file system. Some bullet-proof installations have their / mounted
read-only. Perhaps the invocation of find(1) in 100.clean-disks
should be as follows:
find / -fstype local ! -fstype rdonly \( $args \) ...
Does it make sense?
No, as that still searches through all the NFS filesystems, so I get the
daily output mail at 4 PM or such. (The effect is the same as the
original command.)
My idea of doing a find -x over each applicable filesystem seems even
better in the light of this. It is just a little hard to get the list of
local read-write filesystems in a shell script (df -l to get the locals,
mount -p to get the read-writes, intersect these). Will look at it
later.
In the good old days when NFS was the only remote file system, the
following trick would do:
localrw=$(mount -p -t nonfs | awk '$4 == rw {print $2}')
find -x $localrw \( $args \) ...
But today some hackery around ${netfs_types} should be added, as in
/etc/rc.d/mountcritlocal.
--
Yar
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find(1) -d vs -prune; /etc/periodic/daily/100.clean-disks
On Mon, Mar 06, 2006 at 06:40:58PM +0100, Jilles Tjoelker wrote: find(1)'s -prune primary does not work if depth-first traversal (-d, -depth, also implied by -delete) is in effect. The reason is that it is (obviously) not possible to prune a directory when visiting it after all entries in it. This causes /etc/periodic/daily/100.clean-disks (if enabled) to recurse through all read-only and NFS filesystems as well. More concrete examples: find -d / \( '!' -fstype local -o -fstype rdonly \) -a -prune -o \( -name '*.core' -o -name '.nfs[A-z][0-9a-f][0-9a-f][0-9a-f][0-9a-f]4.4' \) -atime +1 -print /dev/null 21 find /someserver.mnt \( '!' -fstype local -o -fstype rdonly \) -a -prune -print /dev/null 21 (/someserver.mnt assumed to be not a mount point here) Possible solutions/workarounds: 1. do still call -prune and some primaries without side effects in pre-order even if -d is in effect, even though this does not fit at all in find(1)'s design. 2. document the bug and run a find -x over all local r/w filesystems in 100.clean-disks (-x and -d work together properly). What would be the best way to go on? The property of -prune with respect to -d is already documented on the find(1) manpage. As for 100.clean-disks, I fail to see why -prune is needed there. One can mount a file system read-write at a directory of a read-only file system. Some bullet-proof installations have their / mounted read-only. Perhaps the invocation of find(1) in 100.clean-disks should be as follows: find / -fstype local ! -fstype rdonly \( $args \) ... Does it make sense? -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: world's toolchain CPUTYPE
On Mon, Feb 27, 2006 at 12:03:17AM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Ruslan Ermilov [EMAIL PROTECTED] writes: : On Sun, Feb 26, 2006 at 06:50:09PM +0300, Yar Tikhiy wrote: : Hi all, : : Yesterday I hit the following problem: : : - was given an Athlon XP machine with a fresh CURRENT built with :CPUTYPE=athlon-xp; : : - used it to build a fresh RELENG_6 world with no customizations :at all -- __MAKE_CONF=/dev/null; : : - tried to install the world over NFS on an old Pentium machine :with some 5.3-BETA; : : - make installkernel failed instantly because install(1) died on :signal 4, illegal instruction. : : Quick investigation showed that the world was built using generic : i386 code, as expected, but its toolchain was linked against the : builder system libs contaminated by Athlon-specific code. It was : sufficient to rebuild and reinstall all libs on the builder machine : with no particular CPUTYPE set and then to rebuild the world's : toolchain again to make the latter run well on the Pentium. : : I used to be under impression that a world's toolchain should be : fairly independent from the builder system. However, this case : showed that it wasn't quite true. Is it a known issue, or am I : missing a key point? Thanks! : : Simple answer: we just don't support installing from NFS, : but we do support installing to NFS. Any documentation : that says it's supported is lying. : : More details: during the install, part of the toolchain and : some special install tools that were built on the build : host are used. They have been built using that host's : toolchain, CFLAGS, libraries, etc., but libraries is the : most important factor. That means that the install host : should be CPU/syscall/etc. compatible with the build : host. When build == install, all these conditions are : met. When CPUs match, kernels may be different enough so : there will be missing syscalls. And so far... I've never had issues with doing the install from NFS to a local disk. However, I make sure that all the make config variables are identical, the CPUTYPE is unset, and the systems are otherwise as identical as possible before trying. Also make sure that the file systems are mounted identically as well. I also try to set BOOTSTRAPPING=0 on the build host, which forces the maximum number of helper tools to be built. So while not strictly supported, it can be made to work if you know what you are doing, and take precautions, and live with the limitiations. Setting CPUTYPE falls outside the limitations in the build system. Thank everyone for clarifying this issue! I was short-sighted. Indeed, the toolchain is to work on the builder host in the first place, so it should use the builder's MACHINE_ARCH, CPUTYPE, etc. Therefore it won't be generally possible to run it on the target system. What's really fun is tricking the build system so you can cross build on one system, but native install on another from the same tree... I wondered, too, if it would be possible to cross-build install tools so that they could run on the target system, but I haven't investigated this way yet. Do you have any ideas/recipes? Thanks! -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
world's toolchain CPUTYPE
Hi all, Yesterday I hit the following problem: - was given an Athlon XP machine with a fresh CURRENT built with CPUTYPE=athlon-xp; - used it to build a fresh RELENG_6 world with no customizations at all -- __MAKE_CONF=/dev/null; - tried to install the world over NFS on an old Pentium machine with some 5.3-BETA; - make installkernel failed instantly because install(1) died on signal 4, illegal instruction. Quick investigation showed that the world was built using generic i386 code, as expected, but its toolchain was linked against the builder system libs contaminated by Athlon-specific code. It was sufficient to rebuild and reinstall all libs on the builder machine with no particular CPUTYPE set and then to rebuild the world's toolchain again to make the latter run well on the Pentium. I used to be under impression that a world's toolchain should be fairly independent from the builder system. However, this case showed that it wasn't quite true. Is it a known issue, or am I missing a key point? Thanks! -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: md access permissions during early boot
On Sun, Feb 05, 2006 at 10:56:28PM +0100, Tobias Roth wrote: I am working on an rc.d/ script that creates a memory file-backed memory disk via mdconfig (the file exists already and contains a valid ffs). After md creation, the device is checked with fsck_ffs -p. However, fsck fails with the error NO WRITE ACCESS. The file permissions of the md device under /dev/ are 640, which should not prevent access. The same is true for the file itself, and the path to it. I tried passing the -o noreadonly option to mdconfig, but that didn't result in any different behaviour. My script is running right after the fsck script itself. When I run it from the command line after successful boot and login, fsck does not fail, so somewhere between the early beginning of the rc.d/ sequence (right after fsck is run) and login, something changes which results in root having access to my md. A thing to check is whether the filesystem the file is on is mounted read-write by the time your script is invoked. If your script runs right after fsck, there should be only the root fs mounted, read-only. Any ideas what that could be? Another hint is that some time around 5.3, this was not the default behaviour, fsck was possible back then. I am using 6.0 stable now. The ordering of your script relative to other rc.d scripts could have changed. Your script should specify rcorder(8) keywords to start at the right moment. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SENDMAIL_MC making world
On Sun, Oct 09, 2005 at 09:01:32PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Yar Tikhiy [EMAIL PROTECTED] writes: : On Sun, Oct 09, 2005 at 08:15:12PM +0300, Giorgos Keramidas wrote: : : I've always found __MAKE_CONF very useful, but it's not documented in : the ``obvious'' places (i.e. the manpage). I think I should add at : least a note about it in the manpage of make : : FWIW, we have make.conf(5) manpage already, and __MAKE_CONF seems : to belong to it better than to make(1). make(1) xrefs make.conf(5) : already. I think I can do the job if you are busy with something : else currently. __MAKE_CONF should be documented in make(1) since it is in /usr/share/mk/sys.mk and global to the entire system for all make jobs (not just those controlled by buildworld). It should also be in make.conf(5). Agreed. sys.mk is somewhere between make(1) and make.conf(5), so __MAKE_CONF belongs to both until we decide some day we need manpages for our *.mk files. And make.conf(5) contains an incorrect statement that /etc/make.conf applies to system builds only. I'll fix this. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
SENDMAIL_MC making world
All,
I'd like to set SENDMAIL_MC in my /etc/make.conf files conditionally
so that it is not set when I'm making {build,install}world. I
upgrade several machines over NFS from a single build server, and
of course installworld breaks if SENDMAIL_MC differs from what was
set during buildworld. At the same time, I'd like to have SENDMAIL_MC
set for the rest of the time on the machines because `hostname` is
not a suitable way to construct the .mc names on them due to local
setup peculiarities. Any ideas how to achieve this effect?
--
Yar
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A smarter mergemaster
On Fri, Sep 30, 2005 at 02:37:05PM -0700, Kevin Oberman wrote: You just hit on one of my pet peeves with mergemaster! Contrary to what you say: every single default for mergemaster is to do nothing, when a file is found in /etc/rc.d that is not in /usr/src/etc/rc.d, the default is to delete the file in etc. I think that this is a bad thing(tm). I have to restore my profile.sh (which MUST be in /etc/rc.d as it needs to be run before /usr is mounted). I do have an open PR on this (conf/85449), but it does not seem to have gone anywhere other than being assigned to you last Friday. (No, I didn't expect anything to happen this quickly. You just gave me such a perfect opportunity to gripe!) FWIW, I wondered if my version of mergemaster in p4 was affected by this issue and found to my surprise that I had already addressed it in my changes. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A smarter mergemaster
On Thu, Sep 29, 2005 at 11:41:57PM -0700, Doug Barton wrote: First let me say that you've obviously put a lot of work into this, and you have some very interesting ideas here that are worthy of further discussion. Please don't let any of my comments here be understood as criticism, or an attempt to discourage you. Thanks! Second, I'd like to point out that it's generally a bad idea to cross post to more than one list. I've set a reply-to for hackers@, if you'd rather have the discussion on current@ that's fine too, but please pick one. Well, I just couldn't decide between the two lists because I thought that -current was much devoted to reporting LORs and panics while discussions on -hackers tended to be rather theoretic unless they were about LORs and panics :-) Let's stick to -hackers now. Finally, please be aware that in src/MAINTAINERS I have requested pre-commit approval on changes to mergemaster. I hope that you'll respect that. I have some more specific comments below. No problem with that, I'm by no means going to violate your maintainership over mergemaster. And yes, I should have peeked in src/MAINTAINERS earlier :-) Yar Tikhiy wrote: | Folks, | | I've got tired of dumb default choices mergemaster(8) offers and modified | it to be a bit smarter. While I can appreciate your frustration, the way you've phrased this departs from the project's tradition of respect for fellow developers and their work. A better way for you to deal with your frustration here would have been to send me, or alternatively, one of the mailing lists, a post which stated your frustrations and asked for an explanation of the reasons for the defaults. I am sure that you meant no actual insult here, so I'll not say anything more about this topic. I beg your pardon. Let's say I was over-excited with having mm work the way I always wanted it to :-) And, not being a native English speaker, I didn't imagine that the word dumb could be insulting after I had seen so much references to the illustrious Dumb Terminals of the Golden Era of Computing ;-) | Upgrading /etc often, as when following CURRENT, is much less pain to me | now. One of the design decisions that you need to be aware of for this project since day one was to try and balance intelligent behavior and configuration options that would be useful for the very small percentage of the FreeBSD user community that constitutes our developers, versus the needs of the vast majority of regular users who need to be able to use the tool without becoming experts in either our build system, or the tool itself. That is why every single default for mergemaster is to do nothing. It was a purposeful decision to require the user to examine change requests, and make an affirmative choice to approve them. In fact, following CURRENT is not the only case when expert mode of mm could be desired. People following STABLE branches on their production machines use mm, too, and yours truly is among them. Their case is even more calling for expert mode because numerous machines usually need upgrading in a row. The admins study all the peculiarities of mm as soon as they run it a dozen times, but they still need to run it after that. Our /etc is well-suited for staying just slightly modified in the most common cases, so there is little need in turning each mm session into a school class to the admin. Of course, the admins will be responsible for the massive destruction their errors can cause when using mm in expert mode, but most admins are used to this kind of responsibility :-) I find your idea of an expert mode for mm to be an interesting one, and I think that enough time has gone by so that it will be safe to add this. However I'd like to add a big, hairy warning message that says that users who enable this option do so at their own risk, etc. I need to think more about this. I'm unsure if it is hairy enough, but it's on the manpage already, as well as on the help screen, in my version. | The fruitiest features are as follows: | | - mergemaster no longer teases you with pauses in -v mode. Use -N (novice | mode) if you still want the pauses. I'm inclined to alter this to hide the pauses behind an expert mode flag, but I need to study your patch more before I give a more firm opinion on this. Do you have another strong reason for adding this mode? I just liked mm -v for it showing the list of files added locally, but I wasn't happy with the pauses obviously intended for novices, especially when I had to upgrade several machines in a row. | - Stale rc.d files can be rm'ed or kept on individual basis. I think this is a good compromise for those who insist on polluting /etc/rc.d with non-system stuff. :) If you're so inclined, could you add a knob to specify a list of files to exclude from consideration? If not, I'll take a look at it. Done and doc'ed in my p4 branch as LOCAL_RC_FILES, which can be a list of names
Re: A smarter mergemaster
[Replying to everyone who mentioned etcmerge or 3-way merge in general] On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote: It is worth while to mention sysutils/etcmerge. Having the three-way merge makes the process much better. The primary way I've shot myself with mergemaster is forgetting some local change. Being able to distinguish the class of things that are changing upstream really helps the situation and provides a more reasonable indication of the default: if it changed upstream but not locally = default is install if it changed locally but not upstream = default is keep if it changed locally and upstream = default is merge Obviously, in order to do a 3-way merge, we need information about the old versions of original files as well. However, currently we have only the new versions in /usr/src and local versions in /etc for mergemaster to work with. I'll be glad to hear how etcmerge approaches this issue. In any case, we cannot offer the users to access the CVS repo when merging /etc. Personally, I'd like to see a complete copy of current unmodified /etc files installed to /usr/share/examples/etc. They could serve as the old original versions for the 3-way merge then. Alas, now the copy installed there is rather incomplete, motivation of which is unknown to me yet. Any ideas? -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A smarter mergemaster
On Fri, Sep 30, 2005 at 09:07:16AM -0400, John Baldwin wrote: On Friday 30 September 2005 07:08 am, Yar Tikhiy wrote: [Replying to everyone who mentioned etcmerge or 3-way merge in general] On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote: It is worth while to mention sysutils/etcmerge. Having the three-way merge makes the process much better. The primary way I've shot myself with mergemaster is forgetting some local change. Being able to distinguish the class of things that are changing upstream really helps the situation and provides a more reasonable indication of the default: if it changed upstream but not locally = default is install if it changed locally but not upstream = default is keep if it changed locally and upstream = default is merge Obviously, in order to do a 3-way merge, we need information about the old versions of original files as well. However, currently we have only the new versions in /usr/src and local versions in /etc for mergemaster to work with. I'll be glad to hear how etcmerge approaches this issue. In any case, we cannot offer the users to access the CVS repo when merging /etc. Personally, I'd like to see a complete copy of current unmodified /etc files installed to /usr/share/examples/etc. They could serve as the old original versions for the 3-way merge then. Alas, now the copy installed there is rather incomplete, motivation of which is unknown to me yet. Any ideas? I do the equivalent of etcmerge (sort of) by hand using some old instructions from the handbook (pre-mm). Basically, for each installworld, you do a distribute of src/etc into /var/tmp/root-YYMMDD. Then you keep around the previous tree and just compare the two previous trees and merge those changes into /etc. I'm curious if we can do this in the stock system using the stock tools. We could compare /usr/share/examples/etc with the results of make distrubution and merge the changes into /etc. Mergemaster invokes make distrubution anyway, so it just needs relevant /usr/share/examples/etc to be able to do a 3-way merge. This assumes that /usr/share/examples/etc is in keeping with /etc, of course, but the assumption can be verified using RCS Id strings, which should be the same here and there. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
A smarter mergemaster
Folks, I've got tired of dumb default choices mergemaster(8) offers and modified it to be a bit smarter. Upgrading /etc often, as when following CURRENT, is much less pain to me now. The modified mergemaster is available from P4 for now since I'd like to have it tested well before it hits the src tree. The path is //depot/user/yar/hack/usr.sbin/mergemaster, also accessible via web as http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/yar/hack/usr.sbin/mergemaster Since mergemaster still is a shell script, you can just grab and run it. The manual page there has been updated as well. The fruitiest features are as follows: - mergemaster no longer teases you with pauses in -v mode. Use -N (novice mode) if you still want the pauses. - Stale rc.d files can be rm'ed or kept on individual basis. - There is expert mode, -E. In this mode, mergemaster offers more dangerous defaults, mostly [install] or [delete] depending on the question. So you can just keep hitting Enter most of the time if your /etc is just slightly modified. In addition, you get the 's' choice when in a subdirectory: auto-install all files from this subdirectory -- much useful to deal with sweeping changes to rc.d or periodic. Feedback is welcome. And please please don't skip making a backup of your /etc before running mergemaster! I can't be responsible for its loss due to bugs in my code or whatever. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPDIVERT option not getting compiled?
On Tue, Nov 16, 2004 at 03:08:54PM +0200, Yury Tarasievich wrote: I'm adding IPDIVERT option (options IPDIVERT) to config file and config kernel and compile kernel (alternatively -- buildkernel KERNCONF...) and install kernel and all's fine except that after reboot ipfw.ko tells that divert is disabled and it is, indeed, disabled, as natd starts but there are no divert sockets. It happens both with 4.10-RELEASE and with 4-STABLE. But never you mind. This time I had the luxury of being able to just format the partition and install system from scratch, so I did (there wasn't anything big installed yet). Mighty it would help me with populated system. You seem to be confused by the well-known kernel vs. module configuration issue. Alas, kernel options you specify in your kernel config file affect the kernel binary only, not modules built along with the kernel. If you want IPDIVERT, which is an option to IPFIREWALL, you have to build your kernel with both IPFIREWALL and IPDIVERT: options IPFIREWALL options IPDIVERT or just options IPFIREWALL,IPDIVERT Here IPFIREWALL tells to compile the ipfw firewall into your kernel binary while IPDIVERT indicates that ipfw must be compiled with the divert code enabled. With some options, you can do the trick of building a module separately as follows: cd /sys/modules/foo make obj make -DOPTION make install However, it seems impossible for IPDIVERT since this option affects not only ipfw source files, but the main IP stack, too. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network interface RUNNING and UP flags
On Sat, Aug 07, 2004 at 10:06:17AM +0300, Alex Lyashkov wrote: not better move this under tp-tap_mtx mutex without using splX functions? ...especially taking into account that splX do nothing in CURRENT anyway. Mutex locking framework adopted by the interface driver should be used of course. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network interface RUNNING and UP flags
On Fri, Aug 06, 2004 at 05:50:04PM -0400, Coleman Kane wrote: Hi, I have been having some trouble working with getting tapN network interfaces into the 'RUNNING' state. I have been trying to figure out how to set the RUNNING flag on an interface, which is needed before the kernel will actually begin sending packets from said network interface. So far, the only way I have been able to figure out how to do this is to assign an IPv4 address to the interface, I am guessing that an un-addressed network interface is supposed to remain not RUNNING even if it is UP by design. The problem is that only an IPv4 address assignment will bring it up and running. If I attempt to assign an IPv6 address to the interface, it will go UP, but not RUNNING. I have determined that I can assign an IPv4 address (such as 10.0.0.1) to it, and then subsequently remove it (via -alias) and this will leave the interface in the running state. My questions are: 1) Why doesn't assigning an IPv6 address produce the same side effects and 2) Is there a way to set this interface flag without assigning an IPv4 address (or any address for that matter) first? Mainly for number two, I would like to be able to run interfaces bridged together without having to also give all of them addresses. As a matter of fact, the IFF_RUNNING flag, visible as ``RUNNING'' in the output from ifconfig(8), is intended for interface's internal use and should not influence the interaction of the interface with other modules, except for affecting careful user's experience :-) On the contrary, IFF_UP, a.k.a. ``UP'', is an administrative flag to be toggled from outside an interface driver. A user can flip it to shutdown the interface, or a network stack module may touch it if it needs to (e.g., IP will bring an interface up to send a gratuitous ARP upon configuring an IP address on it.) -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Silent errors when reading CDs
On Wed, Jul 14, 2004 at 03:06:25PM +0200, Jean-Sebastien Roy wrote: Once I had an old noname PC (iP200 in an i430VX motherboard), and I installed a DVD+RW drive into it. Data read from a CD or DVD was damaged with high probability. With hw.ata.atapi_dma set to zero, the probability of data corruption was lower, but still noticable. That's while there were no corruption on burning in DMA or PIO mode. At least I'm not alone ! Of course you are not! A lot of ATA users are in the same boat. I myself managed to get out of it only thanks to VIA ;-) Now I have a VIA KT133-based motherboard, which seems to have no trouble with DMA on ATAPI. Alas, it doesn't mean that other VIA chipsets have bug-free ATAPI support. Moreover, it won't guarantee that another instance of the same chipset would give you no trouble. Are there CDs in your collection that produce no errors? Yes, but I cannot really tell if it's by chance or they really do not produce errors. That's a point to test in order to be completely sure. Just pick such a error-free CD, read it *really many* a time, and compare the checksums. The CDs read well in other computers. FWIW, my ATA controler is an Intel ICH5 : [skip] I think I will live with this bug until I change hardware. In any case, testing the effect of disabling atapi_dma in your system would be interesting. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Silent errors when reading CDs
On Sat, Jul 10, 2004 at 12:07:40AM +0200, Jean-Sebastien Roy wrote: I'm currently using FreeBSD 4.10 on an HP D530 SFF. The system is perfectly stable except for the following problem I'm unable to understand : When I mount a cdrom (mount /cdrom), then calculate the MD5 hash of a big file on a CD (md5 /cdrom/bigfile), the results are often random: unmounting, mounting again and calculating again the MD5 often result in a different value. What disturb me the most is that absolutely no errors are reported in any log (no read errors for example). I thought the CDROM reader, a LITE-ON LTR-48327S PQS3, was the culprit, so I replaced it with a PLEXTOR DVDR PX-712A and got the exact same results (i.e. random MD5 values). I checked the RAM using memtest and got no errors. The problem does not occur for files on the harddisk. Once I had an old noname PC (iP200 in an i430VX motherboard), and I installed a DVD+RW drive into it. Data read from a CD or DVD was damaged with high probability. With hw.ata.atapi_dma set to zero, the probability of data corruption was lower, but still noticable. That's while there were no corruption on burning in DMA or PIO mode. I got used to always checksumming data read or written; it was a real pain in the back. Finally, I dismantled the PC, but kept the DVD-RW drive for a new PC; thus I got rid of the problem once and for all. My conclusion was: If your hardware sucks, you may choose to work around the bugs, but it's usually easier to dump the POS and find a replacement. Of course, you may need to do some testing before you know which part sucks. hw.ata.atapi_dma is set since both drives support it and it seems to be required for proper CD/DVD burning. The CD drive is the master on its own ATA bus. DMA mode on an ATAPI device might be the root of the evil. Alas, a lot of ATA controllers have bugs there. And you'll need DMA mode only for high-speed burning, when PIO mode cannot provide enough throughput--it's not required in general. E.g., I had DVD+Rs burned OK at 2.4x in PIO mode on the P200. Therefore you can at least see if disabling hw.ata.atapi_dma is a workaround for your problem. While the problem occurs on multiple CDs (mostly RW), to my surprise, I was not able to reproduce the problem by reading big files on DVDs. Are there CDs in your collection that produce no errors? Could someone provide me a hint on what to check next or how to fix this problem ? Can errors on CDs generate such a behavior ? Even a badly scratched CD won't produce damaged data unless read in a brain-dead drive. If your drives work OK with a different ATA controller, then it's probably your present ATA controller to blame. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TIME_WAIT sockets from other users (was Re: bin/65928: [PATCH] stock ftpd uses superuser credentials for active mode sockets)
On Sun, May 16, 2004 at 06:16:58PM +0400, Yar Tikhiy wrote
in [EMAIL PROTECTED]:
Note for the impatient: This message does not discuss the well-known
issue of reusing local addresses through setting SO_REUSEADDR. This
message is on reusing local addresses occupied by sockets belonging
to other users.
[...]
Attached below is a patch addressing the issue of the inability to
reuse a local IP:port couple occupied by an established TCP connection
from another user, but by no listeners. Could anybody with fair
understanding of our TCP/IP stack review it please? Thanks.
[...]
One more detail to note:
Currently if another user's socket is in the TIME_WAIT state, it
still counts as occupying the local IP:port couple. I cannot see
the point of such a behaviour. Restricting bind() is to disallow
unprivileged port stealth, but how can one steal a connection in
the TIME_WAIT state?
For FreeBSD-4 the above patch would take care of this case along
with established connections, but in CURRENT TIME_WAIT connections
are a special case since they no longer use full-blown state.
Therefore, for CURRENT the above patch mutates into the below one.
[...]
Since I've got no feedback on this issue, I have little hope that
someone will pay attention to my next patch ;-)
However, I have no experience with IPv6, so currently I've got
no choice but to offer my patch for your review, friends, so that
some kind person might take a glance at it while I'm exercising
myself over IPv6 ;-)
I made this patch by analogy with the IPv4 one, which is already
in the CURRENT kernel--luckily, the IPv6 code is rather comprehensible.
It addresses the same issue I was talking about a month ago, but
for the IPv6 stack: It enables the non-root reuse of local address:port
tuples occupied by established or TIME_WAIT TCP connections from
other local users, as long as these particular cases have no security
implications a.k.a. port theft.
--
Yar
Index: in6_pcb.c
===
RCS file: /home/ncvs/src/sys/netinet6/in6_pcb.c,v
retrieving revision 1.52
diff -u -p -r1.52 in6_pcb.c
--- in6_pcb.c 12 Jun 2004 20:59:48 - 1.52
+++ in6_pcb.c 19 Jun 2004 14:15:14 -
@@ -194,14 +194,10 @@ in6_pcbbind(inp, nam, cred)
t = in6_pcblookup_local(pcbinfo,
sin6-sin6_addr, lport,
INPLOOKUP_WILDCARD);
- if (t (t-inp_vflag INP_TIMEWAIT)) {
- if
((!IN6_IS_ADDR_UNSPECIFIED(sin6-sin6_addr) ||
- !IN6_IS_ADDR_UNSPECIFIED(t-in6p_laddr) ||
- !(intotw(t)-tw_so_options SO_REUSEPORT))
-so-so_cred-cr_uid !=
- intotw(t)-tw_cred-cr_uid)
- return (EADDRINUSE);
- } else if (t
+ if (t
+ ((t-inp_vflag INP_TIMEWAIT) == 0)
+ (so-so_type != SOCK_STREAM ||
+IN6_IS_ADDR_UNSPECIFIED(t-in6p_faddr))
(!IN6_IS_ADDR_UNSPECIFIED(sin6-sin6_addr) ||
!IN6_IS_ADDR_UNSPECIFIED(t-in6p_laddr) ||
(t-inp_socket-so_options SO_REUSEPORT)
@@ -216,17 +212,12 @@ in6_pcbbind(inp, nam, cred)
t = in_pcblookup_local(pcbinfo,
sin.sin_addr, lport,
INPLOOKUP_WILDCARD);
- if (t (t-inp_vflag INP_TIMEWAIT)) {
- if (so-so_cred-cr_uid !=
- intotw(t)-tw_cred-cr_uid
- (ntohl(t-inp_laddr.s_addr) !=
-INADDR_ANY ||
-((inp-inp_vflag
- INP_IPV6PROTO) ==
- (t-inp_vflag
- INP_IPV6PROTO
- return (EADDRINUSE);
- } else if (t
+ if (t
+ ((t-inp_vflag
+ INP_TIMEWAIT) == 0)
+ (so-so_type != SOCK_STREAM ||
+ntohl(t-inp_faddr.s_addr) ==
+ INADDR_ANY
A subtle libstand bug?
Hi there, I'm sorry to report the problem I observed in so little detail, but OTOH I feel I must notify the community about it. I'm afraid there's too little detail for a PR. Yesterday I did binary upgrade of my home system, from 4.9-R to 4.10-R. Then I merged my old /etc into the new one. Of course, I just did mv /etc.old/fstab /etc. After that, the kernel started to ask for the root device. Having played with loader(8) in the past, I concluded that something was wrong with my /etc/fstab, because I knew loader(8) would consult it for the root device name to pass to the kernel. I added some debugging printfs to getrootmount(), in sys/boot/common/boot.c, and saw that /etc/fstab was opened OK, but nothing could be read from it as though it was empty. At the same time, fsck reported no errors in the file system. And then I did a mistake: I issued, cp /etc/fstab /etc/fstab2 mv /etc/fstab2 /etc/fstab. The problem vanished, and I could reproduce it no more. From this experience I suppose that there is a subtle bug in libstand that must be related to reading FFS directories or inodes. A libstand wizard might have insight into it. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bugfix for checksum offload in bge(4)
On Fri, May 21, 2004 at 11:11:41PM +0900, George V.Neville-Neil wrote: While sweeping network interface drivers for incorrect usage of the capabilities framework, I noticed some bugs in bge(4). Unfortunately, I have no such card and I don't know its internals. Therefore I made a patch fixing hw-independent bugs and marking some questionable spots. It would be nice if somebody possessing the knowledge on bge(4) reviewed this patch and used it to really fix the things. If nobody undertakes that, I'll just commit my change since it doesn't seem to affect the functionality while it brings the code into the shape. Thanks! I have such a card and can look into this. It may take a bit though, perhaps a week or so. Thank you George, that would be great. A week is not a problem after it took me two months to spare time to make the patch :-) -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interoperation of flock(2), fcntl(2), and lockf(3)
On Sat, May 15, 2004 at 01:00:13PM +0200, Cyrille Lefevre wrote: Yar Tikhiy [EMAIL PROTECTED] wrote: [snip] Considering all the above, I'd like to add the following paragraph to the flock(2), lockf(3), and fcntl(2) man pages (replacing the sentence quoted from lockf(3)): The flock(2), fcntl(2), and lockf(3) locks are compatible. Processes using different locking interfaces can cooperate over the same file safely. However, only one of such interfaces should be used within a process. If a file is s/a process/the same process/ ? Agreed, thanks! BTW, since no objections were raised and Kirk encouraged me to make the change (thank you Kirk!), I just did so. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Interoperation of flock(2), fcntl(2), and lockf(3)
Hi folks, I've always been confused by the following sentence from the lockf(3) manpage: The lockf(), fcntl(2) and flock(2) locks may be safely used concurrently. Does that mean that each of those calls uses a locking mechanism of its own? Of course, in practice those calls use a mutual mechanism, thus allowing serial access to a file from applications using different calls. However, there's an oddity: While it's possible for a process to obtain the same lock several times w/o error (it's a no-op case of upgrading the lock,) intermixing flock(2) and fcntl(2), or flock(2) and lockf(3), within the same process results in EAGAIN upon the second locking attempt. That's while mixing fcntl(2) and lockf(3) is all right as long as the latter call is just a wrapper for the former one. Of course, intermixing different lock calls within one process is a poor idea at the first place, but I can imagine some mail application that tries to coax all the mailbox locking schemes at once. Considering all the above, I'd like to add the following paragraph to the flock(2), lockf(3), and fcntl(2) man pages (replacing the sentence quoted from lockf(3)): The flock(2), fcntl(2), and lockf(3) locks are compatible. Processes using different locking interfaces can cooperate over the same file safely. However, only one of such interfaces should be used within a process. If a file is locked by a process through flock(2), any record within the file will be seen as locked from the viewpoint of another process using fcntl(2) or lockf(3), and vice versa. Any objections or comments? -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing the NAT IP on demand?
On Sat, Oct 04, 2003 at 07:54:00PM -0400, Leo Bicknell wrote: That, by itself, is not hard. Here's the trick. I want the switch to be seamless. That is, if NAT is translating to ISP #1 and the application says switch to #2 the existing translations to #1 (until they go away naturally) should be kept, while new ones go to #2. Just a random thought: If natd(8) were taught to change its default alias address on the fly (it's just a single variable,) then the desired effect would be achieved exactly. That's because any session already having its own entry in natd's aliasing table would use its old alias address kept in the entry. BTW, one could switch between even more than 2 external connections in that manner. And that's just a step away from session-aware load-balancing with natd(8). -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Mount point mode after mount_mfs(8)
Hi folks,
As some of you could have noticed, mount_mfs(8) in STABLE will leave
the mount point mode 1777, which is not always desired. Doing
chmod(1) on it just after mount_mfs(8) isn't elegant due to a race.
There is a PR open on the issue -- bin/54897.
I've got a patch (see below) that adds a new option to mount_mfs(8),
-P mode, to specify the initial mode for the mount point (i.e., for
the root directory of the MFS created.)
On the one hand, this patch is simple, so it would be rather safe
to commit it to STABLE.
On the other hand, I feel it shouldn't be committed if the originator
of the said PR and yours truly are the only people who need the
functionality in question, particularly granted that 4-STABLE is
gradually reaching its end of life.
Does anybody else think this feature is really needed?
--
Yar
Index: mkfs.c
===
RCS file: /home/ncvs/src/sbin/newfs/mkfs.c,v
retrieving revision 1.29.2.7
diff -u -r1.29.2.7 mkfs.c
--- mkfs.c 12 Aug 2003 13:19:17 - 1.29.2.7
+++ mkfs.c 12 Aug 2003 13:58:51 -
@@ -91,6 +91,7 @@
* variables set up by front end.
*/
extern int mfs;/* run as the memory based filesystem */
+extern mode_t mfs_mode; /* permission bits for mfs root */
extern char*mfs_mtpt; /* mount point for mfs */
extern struct stat mfs_mtstat; /* stat prior to mount */
extern int Nflag; /* run mkfs without writing file system */
@@ -1009,7 +1010,7 @@
* create the root directory
*/
if (mfs)
- node.di_mode = IFDIR | 01777;
+ node.di_mode = IFDIR | mfs_mode;
else
node.di_mode = IFDIR | UMASK;
node.di_nlink = PREDEFDIR;
Index: newfs.8
===
RCS file: /home/ncvs/src/sbin/newfs/newfs.8,v
retrieving revision 1.26.2.15
diff -u -r1.26.2.15 newfs.8
--- newfs.8 13 May 2003 12:16:08 - 1.26.2.15
+++ newfs.8 12 Aug 2003 13:58:51 -
@@ -69,6 +69,7 @@
.Nm mount_mfs
.Op Fl NU
.Op Fl F Ar file
+.Op Fl P Ar mode
.Op Fl T Ar disktype
.Op Fl a Ar maxcontig
.Op Fl b Ar block-size
@@ -149,6 +150,23 @@
format filesystem.
This options is primarily used to build root filesystems
that can be understood by older boot ROMs.
+.It Fl P Ar mode
+Set the file permissions on the root directory of
+the file system created by
+.Nm mount_mfs
+to the specified
+.Ar mode .
+The
+.Ar mode
+argument can be in any of the formats recognized by
+.Xr chmod 1 .
+If a symbolic mode is specified,
+the operation characters
+.Dq +
+and
+.Dq -
+are interpreted relative to the default mode of
+.Dq a=rwxt .
.It Fl T
Use information for the specified disk from
.Pa /etc/disktab
Index: newfs.c
===
RCS file: /home/ncvs/src/sbin/newfs/newfs.c,v
retrieving revision 1.30.2.9
diff -u -r1.30.2.9 newfs.c
--- newfs.c 13 May 2003 12:03:55 - 1.30.2.9
+++ newfs.c 12 Aug 2003 13:58:51 -
@@ -166,6 +166,7 @@
#define NSECTORS 4096/* number of sectors */
intmfs;/* run as the memory based filesystem */
+mode_t mfs_mode = 01777; /* permission bits for mfs root */
char *mfs_mtpt; /* mount point for mfs */
struct stat mfs_mtstat;/* stat prior to mount */
intNflag; /* run without writing file system */
@@ -231,6 +232,7 @@
struct statfs *mp;
int fsi, fso, len, n, vflag;
char *cp, *s1, *s2, *special, *opstring;
+ void *set;
#ifdef MFS
struct vfsconf vfc;
int error;
@@ -249,7 +251,7 @@
}
opstring = mfs ?
- NF:T:Ua:b:c:d:e:f:g:h:i:m:o:s:v :
+ NF:P:T:Ua:b:c:d:e:f:g:h:i:m:o:s:v :
NOS:T:Ua:b:c:d:e:f:g:h:i:k:l:m:n:o:p:r:s:t:u:vx:;
while ((ch = getopt(argc, argv, opstring)) != -1)
switch (ch) {
@@ -271,6 +273,12 @@
case 'F':
filename = optarg;
break;
+ case 'P':
+ if ((set = setmode(optarg)) == NULL)
+ fatal(%s: bad file mode, optarg);
+ mfs_mode = getmode(set, mfs_mode);
+ free(set);
+ break;
case 'U':
Uflag = 1;
break;
@@ -758,6 +766,8 @@
fprintf(stderr,
\t-N do not create file system, just print out parameters\n);
fprintf(stderr, \t-O create a 4.3BSD format filesystem\n);
+ if (mfs)
+ fprintf(stderr, \t-P permissions for the root directory\n);
fprintf(stderr, \t-S sector size\n);
#ifdef COMPAT
fprintf(stderr, \t-T disktype\n);
___
[EMAIL PROTECTED] mailing list
Re: NATD and Address Redirection
On Sat, Jul 26, 2003 at 02:22:05AM +0200, Clement Laforet wrote: for incoming traffic, you must use -redirect_address, but for outgoing you have to set -alias_address. If you want to use a specific public IP to map incoming AND outgoing packets, you need to run 2 natd, using ipfw matching. I'm afraid this is not exactly correct. IIRC when 5 years ago I was hacking natd and libalias to use them for transparent HTTP proxying, their internals looked rather clear. In a nutshell, they were as follows. There was a translation table inside libalias with 3 columns in it: the internal connection point (IPport), alias point, and external point. When a packet was heading outside, its source IPport were matched against the internal column, and its destination IPport against the external column. If an entry were found, the packet's source IPport would be replaced with the values from the alias column. When a packet was going in the opposite direction, inside, its source IPport were matched against the external column, and its destination IPport against the alias column. Then the packet's destination IPport were replaced with the values from the internal column of the entry found. By specifying a redirect_address rule, just an entry was inserted to that table with a wildcard value for all the ports and for the external IP address. Upon matching, such an entry would clone into a new one containing the information specific for a particular session. Thus the solution was symmetric by design, without requiring 2 natd's or additional ipfw rules. P.S. As I can see, today's libalias still uses the same approach. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NATD and Address Redirection
On Fri, Jul 25, 2003 at 01:49:38PM -0400, Jim Durham wrote: The procedure we used was to alias a 2nd public address to the outside interface and use a redirect_address statement in natd.conf to redirect connections to the new public IP to the inside machine. Just a remark: If this 2nd public IP is already routed to your gateway, you don't need to add it as an alias for your gateway's outside interface. But you really need to if the latter interface is on a broadcast network and must do ARP to attract packets destined to the 2nd public IP specified to natd. This doesn't seem to be symmetrical. You can ping the inside machine from outside using the new address and if you connect outwards from the inside machine, the outside world sees the connection as coming form the new public IP. However, a test running VNC server on the inside machine and connecting from outside does not work. You can connect to the inside machine and it sees mouse and keyboard, but the virtual screen does not work. It seems that the connection works properly redirecting inward but not outward. VNC disconnects in about a minute. Could you check if TELNET, HTTP, or SSH from the outside world to the inside machine works? The problem may have to do with VNC protocol peculiarities preventing it from working through NAT. (However, the VNC FAQ claims VNC will work through NAT.) -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ftpd (option -h not working)
On Sat, Jun 21, 2003 at 08:27:39PM +0200, Socketd wrote: When FreeBSD 4.8 was released I reported this bug, but now in 5.1 releaed it is still there. Since http://www.freebsd.org/send-pr.html is down I'll try reporting the bug here (again). Please use the send-pr(1) utility to submit your bug reports. When using ftpd, you have the -h option to prevent the server from giving any info about itself. This works fino regarding the greeting message and when typing stat, but with syst is still gives info to the user. Thanks for reporting. I've already fixed this minor bug in both CURRENT and STABLE branches. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf reference? (and missing man page)
On Fri, May 23, 2003 at 09:53:48PM +0200, Simon L. Nielsen wrote: On 2003.05.23 15:42:36 +, Bosko Milekic wrote: On May 23, 2003 07:07 pm, Michael R. Wayne wrote: Missing man page: 4.8 releasse - man netstat has a reference to mbuf(9) but man mbuf says: No manual entry for mbuf True. This is a bug. Someone from -doc should fix this, because mbuf(9) only exists in 5.0 and later. Try submitting a PR and filing it to -doc. Here's a link to an on-line version of the mbuf(9) man page appearing in 5.x: Actually there is a two PR's open for this already: docs/44337 and docs/50463. So it will be dealt with when someone gets around to it... It was me who has written the initial version of mbuf(9) and now I have a bit of spare time, so I'll deal with this problem immediately. Thank you who have contributed to this thread for collecting together all the relevant pointers. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Expensive timeout(9) function...
On Tue, Apr 01, 2003 at 02:37:45PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Yar Tikhiy writes: Hello, I'm getting the following DIAGNOSTIC messages on my -CURRENT box: Expensive timeout(9) function: 0xc02677e0(0) 0.006095064 s (it's uma_timeout(), which triggers the warning once per boot) Expensive timeout(9) function: 0xc0141610(0xc0dfcc00) 0.006581587 s Expensive timeout(9) function: 0xc0141610(0xc0dfcc00) 0.008510173 s (and this one is fxp_tick(); it triggers the warning from time to time) Are those warnings harmless? Yes, but indicative of code which needs attention, but harmless. As far as my understanding of the issue reaches, a timeout function is called under protection of the Giant mutex unless it's marked as MP-safe, and that's the reason to spend as little time as possible in it. Right? Yes, but there are other reasons why you would generally not want to spend too much time in the timeout function, mostly that it may screw up other time-critical things in the system. Thanks for your explanation! I hope this little thread will draw the attention of the responsible or interested parties to the warnings ;-) -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Build options for kernel modules
On Fri, Mar 21, 2003 at 05:39:07PM +0200, Nikolay Y. Orlyuk wrote: On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? I think this isn't so. I have been already tried to compile some modules without compiling kernel and this trye has successful result, but without change options. I think modules must be build with same or less imports and same or more export to be correct for loading. Yeah, it's all right to compile modules w/o the kernel, but that's not exactly what I was asking about. My question was whether option FOO lines from a kernel configuration file could influence modules. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Build options for kernel modules
On Fri, Mar 21, 2003 at 05:35:22PM +0200, Ruslan Ermilov wrote: On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? There is. It's called ``makeoptions''. It's passed to both kernel and modules builds. I beg your pardon, but makeoptions is just next to editing makefiles in /sys/modules. My dream was that specifying, e.g., options IPFIREWALL_VERBOSE would result in building ipfw.ko inherently chatty :-) BTW, Ruslan, let me ask you another question, as you've been recently working at kern.mk files. Is it on purpose that the target kernel-cleandir doesn't invoke kernel-cleandepend? I've been sure that by common practice cleandir should remove dependency files... -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Port: portupgrade-20021216
On Thu, Jan 23, 2003 at 03:47:49PM +0200, Peter Pentchev wrote: On Thu, Jan 23, 2003 at 10:12:16AM +, Ceri Davies wrote: On Thu, Jan 23, 2003 at 10:12:24AM +0200, Peter Pentchev wrote: On Thu, Jan 23, 2003 at 01:09:29AM +0100, Julian Mayer wrote: hello there is a bug in portupgrade-20021216: when you change the FTP port in /etc/services to run the FTP demon on another port, portupgrade is unable to download ports/packages via ftp is there a workaround? Errr.. this is not a bug in portupgrade, but the way most (all?) FTP clients work. If you change the port for the 'ftp' service, *any* program that asks about the 'ftp' service will use the new port, including all FTP clients that try to make outgoing connections. In that case, it sounds like a bug in our stock ftpd. DESCRIPTION Ftpd is the Internet File Transfer Protocol server process. The server uses the TCP protocol and listens at the port specified in the ``ftp'' service specification; see services(5). If this breaks outgoing ftp connections, then that's quite serious. The appropriate way to fix that problem is to NOT change the port for the 'ftp' service, but merely specify a different port on which to run the FTP server. RTF ftpd(8) manual - there isn't any other (documented) way to do it. If I'm not missing something obvious, then I'll file a PR for this later. Yes, it would seem that the stock ftpd does not provide a way to specify a different port/service to use in daemon mode. In inetd mode, everything is fine and dandy. Attached is a patch to the libexec/ftpd source, which adds a new -P option taking an argument of either a numeric port number or a service name as described in the getaddrinfo(3) manual page. What do people think about adding this functionality? As for me, I think that a) editing standard lines in /etc/services is a rather bad idea since the file lists _standard_ service endpoints; OTOH, adding a site-specific service endpoint to the file is all right, b) the port option to ftpd(8) would be nice. However, there seems to be a hard-coded value for not only the FTP control port, but the FTP default data port as well. I'd like to fix both issues at once since RFC 959 specifies explicitly that the default data port should be 1 less than the control port. I hope I'll introduce the port option to our stock ftpd(8) in a couple of days. Thanks for the patch. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Port: portupgrade-20021216
On Thu, Jan 23, 2003 at 03:47:49PM +0200, Peter Pentchev wrote:
Attached is a patch to the libexec/ftpd source, which adds a new -P
option taking an argument of either a numeric port number or a service
name as described in the getaddrinfo(3) manual page. What do people
think about adding this functionality?
Peter, here is a bit reworked version of your patch.
Does it look reasonable?
--
Yar
Index: ftpd.8
===
RCS file: /home/ncvs/src/libexec/ftpd/ftpd.8,v
retrieving revision 1.56
diff -u -r1.56 ftpd.8
--- ftpd.8 27 Dec 2002 12:15:31 - 1.56
+++ ftpd.8 23 Jan 2003 17:39:59 -
@@ -43,6 +43,7 @@
.Op Fl 46ADdEMmOoRrSUvW
.Op Fl l Op Fl l
.Op Fl a Ar address
+.Op Fl P Ar port
.Op Fl p Ar file
.Op Fl T Ar maxtimeout
.Op Fl t Ar timeout
@@ -55,7 +56,9 @@
server process. The server uses the
.Tn TCP
protocol
-and listens at the port specified in the
+and listens at the port specified with the
+.Fl P
+option or in the
.Dq ftp
service specification; see
.Xr services 5 .
@@ -133,6 +136,14 @@
.It Fl o
Put server in write-only mode.
RETR is disabled, preventing downloads.
+.It Fl P
+When
+.Fl D
+is specified, accept connections at
+.Ar port ,
+specified as a numeric value or service name, instead of at the default
+.Dq ftp
+port.
.It Fl p
When
.Fl D
Index: ftpd.c
===
RCS file: /home/ncvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.133
diff -u -r1.133 ftpd.c
--- ftpd.c 21 Jan 2003 05:13:02 - 1.133
+++ ftpd.c 23 Jan 2003 17:40:01 -
@@ -115,6 +115,7 @@
intdaemon_mode;
intdata;
+intdataport;
intlogged_in;
struct passwd *pw;
intftpdebug;
@@ -277,6 +278,7 @@
FILE *fd;
int error;
char*bindname = NULL;
+ const char *bindport = ftp;
int family = AF_UNSPEC;
int enable_v4 = 0;
struct sigaction sa;
@@ -296,7 +298,7 @@
#endif /* OLD_SETPROCTITLE */
- while ((ch = getopt(argc, argv, 46a:AdDElmMoOp:rRSt:T:u:UvW)) != -1) {
+ while ((ch = getopt(argc, argv, 46a:AdDElmMoOp:P:rRSt:T:u:UvW)) != -1) {
switch (ch) {
case '4':
enable_v4 = 1;
@@ -352,6 +354,10 @@
pid_file = optarg;
break;
+ case 'P':
+ bindport = optarg;
+ break;
+
case 'r':
readonly = 1;
break;
@@ -436,11 +442,11 @@
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = 0;
hints.ai_flags = AI_PASSIVE;
- error = getaddrinfo(bindname, ftp, hints, res);
+ error = getaddrinfo(bindname, bindport, hints, res);
if (error) {
if (family == AF_UNSPEC) {
hints.ai_family = AF_UNSPEC;
- error = getaddrinfo(bindname, ftp, hints,
+ error = getaddrinfo(bindname, bindport, hints,
res);
}
}
@@ -553,6 +559,7 @@
syslog(LOG_ERR, getsockname (%s): %m,argv[0]);
exit(1);
}
+ dataport = ntohs(ctrl_addr.su_port) - 1; /* as per RFC 959 */
#ifdef VIRTUAL_HOSTING
/* select our identity from virtual host table */
selecthost(ctrl_addr);
@@ -1722,7 +1729,7 @@
syslog(LOG_WARNING, data setsockopt (SO_REUSEADDR): %m);
/* anchor socket to avoid multi-homing problems */
data_source = ctrl_addr;
- data_source.su_port = htons(20); /* ftp-data port */
+ data_source.su_port = htons(dataport);
for (tries = 1; ; tries++) {
if (bind(s, (struct sockaddr *)data_source,
data_source.su_len) = 0)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Port: portupgrade-20021216
On Thu, Jan 23, 2003 at 07:53:44PM +0200, Peter Pentchev wrote: Peter, here is a bit reworked version of your patch. Does it look reasonable? Yes, this looks fine; the data connection port issue was brought up by Matthew Seaman in a private message to me, which I did not respond to immediately, because I wanted to feel the general thoughts on the subject. Now that you have incorporated it into your patch, it all sounds great :) Thanks! I see that you have also changed my '.Nm' macro for the 'ftp' service to '.Dq'; that's fine too, I was in quite a bit of doubt myself over exactly which mdoc macro to use. The '.Nm' came from the telnet(1) manual page, but it did not look quite right to me. As far as I know mdoc, .Nm should be used once with an argument, the subject of the page, and then it may be used with no argument to refer to the subject since it remembers its argument. Therefore excuse me, but your using .Nm ftp in the middle of the page to refer to ftp as a TCP service wasn't quite correct :-) -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Review by USB wizard wanted
On Tue, Nov 26, 2002 at 03:26:19PM -0800, Nate Lawson wrote:
I'm not a usb expert but I think your patch deserves some comments.
Thank you!
On Mon, 25 Nov 2002, Yar Tikhiy wrote:
First, sometimes (especially, if twitching a memory stick out of
the reader while the device is being detected) a transfer to the
umass device is initiated *after* the device is already gone. System
panic follows. The transfer is initiated when destroying the default
pipe to the device. Indeed, the current usb_subr.c code will detach
child devices first and destroy the default pipe then. Reverting
this order eliminates the panic.
Second, twitching a memory stick can cause CAM jam. That happens
because the umass detach routine won't wake up the upper layer when
processing a device with a pending transfer on it.
Patches addressing the above problems are attached below.
[...]
--- usb_subr.c.orig Sat Nov 16 12:07:50 2002
+++ usb_subr.c Fri Nov 22 15:45:35 2002
@@ -1292,8 +1292,6 @@
{
int ifcidx, nifc;
- if (dev-default_pipe != NULL)
- usbd_kill_pipe(dev-default_pipe);
if (dev-ifaces != NULL) {
nifc = dev-cdesc-bNumInterface;
for (ifcidx = 0; ifcidx nifc; ifcidx++)
@@ -1340,6 +1338,9 @@
return;
}
#endif
+
+ if (dev-default_pipe != NULL)
+ usbd_kill_pipe(dev-default_pipe);
if (dev-subdevs != NULL) {
DPRINTFN(3,(usb_disconnect_port: disconnect subdevs\n));
This change looks good to me. With your patch, we need to be careful if
anyone ever calls usb_free_device() directly since the default pipe won't
be killed. But since I don't see it called by anyone else, it seems ok.
Of course, I've made sure it's the only point where usb_free_device()
would be called from.
Why not make usb_free_device() static too?
Good point!
--- umass.c.origSat Nov 16 12:07:50 2002
+++ umass.c Fri Nov 22 21:42:10 2002
@@ -1033,6 +1033,13 @@
/* detach the device from the SCSI host controller (SIM) */
err = umass_cam_detach(sc);
+ /* if upper layer is waiting for a transfer to finish, wake it up */
+ if (sc-transfer_state != TSTATE_IDLE) {
+ sc-transfer_state = TSTATE_IDLE;
+ sc-transfer_cb(sc, sc-transfer_priv,
+ sc-transfer_datalen, STATUS_WIRE_FAILED);
+ }
+
for (i = 0; i XFER_NR; i++)
if (sc-transfer_xfer[i])
usbd_free_xfer(sc-transfer_xfer[i]);
This looks good except you're passing the full datalen as the
residue. Does this address the situation where the data has been
partially transferred successfully? Or should you subtract
transfer_actlen in that case? I think your code is correct, I just am not
familiar enough with usb to be sure.
After examining the case, I think transfer_actlen should be subtracted
from transfer_datalen there for consistency. However, Nick Hibma has
told me the residue argument value didn't matter in most cases of error.
--
Yar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Review by USB wizard wanted
Hi folks,
I'm playing with a Sony USB memory stick reader/writer. It's a
pretty slow device, so it triggers some bugs in the FreeBSD USB
code unnoticed before. I'm new to USB programming, so I submit
my notes to a discussion or review.
First, sometimes (especially, if twitching a memory stick out of
the reader while the device is being detected) a transfer to the
umass device is initiated *after* the device is already gone. System
panic follows. The transfer is initiated when destroying the default
pipe to the device. Indeed, the current usb_subr.c code will detach
child devices first and destroy the default pipe then. Reverting
this order eliminates the panic.
Second, twitching a memory stick can cause CAM jam. That happens
because the umass detach routine won't wake up the upper layer when
processing a device with a pending transfer on it.
Patches addressing the above problems are attached below.
--
Yar
--- usb_subr.c.orig Sat Nov 16 12:07:50 2002
+++ usb_subr.c Fri Nov 22 15:45:35 2002
@@ -1292,8 +1292,6 @@
{
int ifcidx, nifc;
- if (dev-default_pipe != NULL)
- usbd_kill_pipe(dev-default_pipe);
if (dev-ifaces != NULL) {
nifc = dev-cdesc-bNumInterface;
for (ifcidx = 0; ifcidx nifc; ifcidx++)
@@ -1340,6 +1338,9 @@
return;
}
#endif
+
+ if (dev-default_pipe != NULL)
+ usbd_kill_pipe(dev-default_pipe);
if (dev-subdevs != NULL) {
DPRINTFN(3,(usb_disconnect_port: disconnect subdevs\n));
--- umass.c.origSat Nov 16 12:07:50 2002
+++ umass.c Fri Nov 22 21:42:10 2002
@@ -1033,6 +1033,13 @@
/* detach the device from the SCSI host controller (SIM) */
err = umass_cam_detach(sc);
+ /* if upper layer is waiting for a transfer to finish, wake it up */
+ if (sc-transfer_state != TSTATE_IDLE) {
+ sc-transfer_state = TSTATE_IDLE;
+ sc-transfer_cb(sc, sc-transfer_priv,
+ sc-transfer_datalen, STATUS_WIRE_FAILED);
+ }
+
for (i = 0; i XFER_NR; i++)
if (sc-transfer_xfer[i])
usbd_free_xfer(sc-transfer_xfer[i]);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Large variables on stack
Hi Terry, On Fri, Jul 12, 2002 at 02:45:08PM -0700, Terry Lambert wrote: My gut feeling is: if you are asking this question, then you are trying to justify doing something that you know is bad, but want to do anyway because it would be easier than doing it right. My answer to that is: trust your instincts, even if it means more work. In fact, I'm trying to justify to myself fixing this issue in existing code along with doing more serious work on it :-) To everybody participating in this thread: Thank you a lot for clarifying this question to me and all the list readers. It has been a really fruitful discussion. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Large variables on stack
Hi there, As I see, there are many spots in the FreeBSD userland sources where multi-kilobyte automatic variables (e.g., string buffers) are used. I've been taught that such variables would better be static or allocated on heap. So the following question comes to my mind: To stay portable to a reasonable degree, how large on-stack variables can be used? -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Get disk device size?
Hi there, Could anyone point out at an ioctl or any other way to get a disk device size granted the device has no BSD label or PC slice table on it? Ways for both the userland and kernel are welcome. Thanks in advance! -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Get disk device size?
On Tue, Feb 05, 2002 at 09:30:06AM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Yar Tikhiy [EMAIL PROTECTED] writes: : Could anyone point out at an ioctl or any other way to get a disk : device size granted the device has no BSD label or PC slice table : on it? Ways for both the userland and kernel are welcome. For userland, look at how fdisk and/or disklabel get it. For kernel, look at kern/subr_disk*.c Thanks, the DIOCGDINFO ioctl is nearly what I was looking for. However, there seems to be a number of problems (or my misunderstandings?) about it. This ioctl can't be used against non-BSD slices; it fails on them with EINVAL due to code in kern/subr_diskslice.c. OTOH, invoking this ioctl on a partition (e.g. ad0s1a) will result in the parameters of the whole slice/disk (i.e. ad0s1.) Isn't all that a bit inconsistent? E.g. a filesystem layer doesn't need to distinguish between say ad0, ad0s1, and ad0s1a -- they're just disk devices for it. Or did I miss any important point? -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: strlcat manpage
Hi Valentin, On Fri, Jan 11, 2002 at 12:22:21AM +0200, Valentin Nechayev wrote: There was a fresh discussion in some maillists (security-audit, glibc-alpha) of strlcpy() and strlcat() in context of possible inclusion to glibc. Among others, the question was spoken that strlcat manpage contains a dark moment of strlcat() return value. One should agree with affirmation that strlcat() must not check characters after dst[size-1], the first reason is that memory block can end here; but, James Antill reported that Sun programmers lost their mind and checks full length of dst as a source nul-terminated string. (I didn't check his report.) In this context, I think the following patch should be applied to provide explicit clarification of this moment and full accordance with source code. First, it's better to submit such fixes as FreeBSD Problem Reports, or they'll have a fair chance to get lost in the high volume of freebsd-hackers. Second, the strlcat(3) manpage language has already been improved with respect to this issue. The upcoming 4.5-RELEASE will contain the corrected manpage. Thank you for your effort. [Not removind freebsd-hackers from CC to show to the world such messages won't be just ignored here :-) ] -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Sun, Dec 23, 2001 at 02:29:14AM +0300, Maxim Konovalov wrote: On 18:51+0300, Dec 21, 2001, Yar Tikhiy wrote: I made a patch that adds the stealthy IP options feature. Honestly, now I'm afraid it's much ado about nothing, given how clumsy solution is needed for such a small problem. Even the way of ignoring IP options completely when doing IPSTEALTH looks way better... IMHO it is not a good idea to forward a packet with possible incorrect ip options. Forwarding a packet without decreasing its TTL may be even worse idea :-) We're breaking the standard with IPSTEALTH anyway, so to my mind the best idea is to avoid spoiling the system code too much. The patch looks OK for me. All right, if anyone else feels committing that patch of mine is OK and tells that to me, I'll commit it. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IP options (was: Processing IP options reveals IPSTEALH router)
On Thu, Dec 20, 2001 at 01:24:48AM +0300, Maxim Konovalov wrote:
Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following:
if a source-routed IP packet reachs the end of its route, but its
destination address doesn't match a current host/router, whether
the packet should be discarded, sent forth through usual routing
or accepted as destined for this host? FreeBSD will route such a
packet as usual.
Stevens, TCP Ill. vII, p.257 says:
If the destination address of the packet does not match one of the
local addresses and the option is a strict source routing
(IPOPT_SSRR), an ICMP source route failure error is sent. If a local
address isn't listed in the route, the previous system sent the packet
to the wrong host. This isn't an error for a loose source route
(IPOPT_LSRR); it means IP must forward the packet toward the
destionation.
That is what ip_input does near the line 1193.
Oops, it appeared that I misunderstood the way the source route
record worked. FreeBSD does it right, except for a host (ipforwarding=0)
replying with error ICMP on some source route attempts.
What about the following small change?
--- /usr/src/sys/netinet.orig/ip_input.cFri Dec 7 00:54:48 2001
+++ netinet/ip_input.c Fri Dec 21 19:08:56 2001
@@ -1212,13 +1212,13 @@
ia = (struct in_ifaddr *)
ifa_ifwithaddr((struct sockaddr *)ipaddr);
if (ia == 0) {
+ if (!ip_dosourceroute)
+ goto nosourcerouting;
if (opt == IPOPT_SSRR) {
type = ICMP_UNREACH;
code = ICMP_UNREACH_SRCFAIL;
goto bad;
}
- if (!ip_dosourceroute)
- goto nosourcerouting;
/*
* Loose routing, and not at next destination
* yet; nothing to do except forward.
@@ -1231,18 +1231,19 @@
* End of source route. Should be for us.
*/
if (!ip_acceptsourceroute)
- goto nosourcerouting;
+ goto logandsendicmp;
save_rte(cp, ip-ip_src);
break;
}
if (!ip_dosourceroute) {
+nosourcerouting:
if (ipforwarding) {
char buf[16]; /* aaa.bbb.ccc.ddd\0 */
/*
* Acting as a router, so generate ICMP
*/
-nosourcerouting:
+logandsendicmp:
strcpy(buf, inet_ntoa(ip-ip_dst));
log(LOG_WARNING,
attempted source route from %s to %s\n,
--
Yar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote:
On 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote:
As for source routing, I believe a stealthy router should just drop
such packets as though it were a host. Of course, source-routed
packets destined for the router itself should be accepted.
So there are three IPSTEALTH cases:
1/ the dst address is not ours, net.inet.ip.sourceroute=0,
net.inet.ip.forwarding=1: process ip options by ip_dooptions().
2/ the dst address is ours: process ip options by ip_dooptions(),
3/ in other cases do not process ip options.
I made a patch that adds the stealthy IP options feature.
Honestly, now I'm afraid it's much ado about nothing, given how
clumsy solution is needed for such a small problem. Even the way
of ignoring IP options completely when doing IPSTEALTH looks way
better...
--
Yar
P.S. Here's the patch:
--- ip_input.c.orig Fri Dec 7 00:54:48 2001
+++ ip_input.c Fri Dec 21 17:59:22 2001
@@ -211,7 +211,7 @@
struct sockaddr_in *ip_fw_fwd_addr;
static voidsave_rte __P((u_char *, struct in_addr));
-static int ip_dooptions __P((struct mbuf *));
+static int ip_dooptions __P((struct mbuf *, int));
static voidip_forward __P((struct mbuf *, int));
static voidip_freef __P((struct ipqhead *, struct ipq *));
#ifdef IPDIVERT
@@ -499,7 +499,7 @@
* to be sent and the original packet to be freed).
*/
ip_nhops = 0; /* for source routed packets */
- if (hlen sizeof (struct ip) ip_dooptions(m)) {
+ if (hlen sizeof (struct ip) ip_dooptions(m, 0)) {
#ifdef IPFIREWALL_FORWARD
ip_fw_fwd_addr = NULL;
#endif
@@ -657,6 +657,19 @@
return;
ours:
+#ifdef IPSTEALTH
+ /*
+* IPSTEALTH: Process non-routing options only
+* if the packet is destined for us.
+*/
+ if (ipstealth hlen sizeof (struct ip) ip_dooptions(m, 1)) {
+#ifdef IPFIREWALL_FORWARD
+ ip_fw_fwd_addr = NULL;
+#endif
+ return;
+ }
+#endif /* IPSTEALTH */
+
/* Count the packet in the ip address stats */
if (ia != NULL) {
ia-ia_ifa.if_ipackets++;
@@ -1150,12 +1163,18 @@
* Do option processing on a datagram,
* possibly discarding it if bad options are encountered,
* or forwarding it if source-routed.
+ * The pass argument is used when operating in the IPSTEALTH
+ * mode to tell what options to process:
+ * [LS]SRR (pass 0) or the others (pass 1).
+ * The reason for as many as two passes is that non-routing options
+ * must not be processed if the packet isn't for us when doing IPSTEALH.
* Returns 1 if packet has been forwarded/freed,
* 0 if the packet should be processed further.
*/
static int
-ip_dooptions(m)
+ip_dooptions(m, pass)
struct mbuf *m;
+ int pass;
{
register struct ip *ip = mtod(m, struct ip *);
register u_char *cp;
@@ -1200,6 +1219,10 @@
*/
case IPOPT_LSRR:
case IPOPT_SSRR:
+#ifdef IPSTEALTH
+ if (ipstealth pass 0)
+ break;
+#endif
if (optlen IPOPT_OFFSET + sizeof(*cp)) {
code = cp[IPOPT_OLEN] - (u_char *)ip;
goto bad;
@@ -1235,7 +1258,10 @@
save_rte(cp, ip-ip_src);
break;
}
-
+#ifdef IPSTEALTH
+ if (ipstealth)
+ goto dropit;
+#endif
if (!ip_dosourceroute) {
if (ipforwarding) {
char buf[16]; /* aaa.bbb.ccc.ddd\0 */
@@ -1254,6 +1280,9 @@
/*
* Not acting as a router, so silently drop.
*/
+#ifdef IPSTEALTH
+dropit:
+#endif
ipstat.ips_cantforward++;
m_freem(m);
return (1);
@@ -1289,6 +1318,10 @@
break;
case IPOPT_RR:
+#ifdef IPSTEALTH
+ if (ipstealth pass == 0)
+ break;
+#endif
if (optlen IPOPT_OFFSET + sizeof(*cp)) {
code = cp[IPOPT_OFFSET] - (u_char *)ip;
goto bad;
@@ -1322,6 +1355,10 @@
break;
case IPOPT_TS:
+#ifdef IPSTEALTH
+ if (ipstealth pass == 0)
+ break;
+#endif
code = cp - (u_char *)ip;
if (optlen 4 || optlen 40) {
code = cp[IPOPT_OLEN] - (u_char *)ip;
To Unsubscribe: send mail to [EMAIL PROTECTED
Processing IP options reveals IPSTEALH router
Hi there, I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? Are there any reasons for a router not to decrement IP TTL besides trying to stay invisible to a third party? As for source routing, I believe a stealthy router should just drop such packets as though it were a host. Of course, source-routed packets destined for the router itself should be accepted. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Wed, Dec 19, 2001 at 05:33:13PM +0200, Ruslan Ermilov wrote: On Wed, Dec 19, 2001 at 06:19:29PM +0300, Yar Tikhiy wrote: I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. What if the packet is directed to us? I think we should still process options in this case, and the patch in the PR doesn't seem to do it. Good point! Indeed, just ignoring IP options would let a third party to identify a FreeBSD host as a stealthy router. I think it's safe to move doing IP options to after identifying an IP packet as destined for this or another host. I'll make a patch and show it here. PS I was going to replace IPSTEALTH functionality with the net.inet.ip.decttl knob. Setting it to 0 would match the IPSTEALTH behavior, the default value will be 1. /PS In fact, IPSTEALTH does already have a sysctl knob: net.inet.ip.stealth, which is initially zero (i.e. don't be stealthy.) To my mind, the stealth name fits its purpose better since just leaving TTL untouched is insufficient for a router to achieve really stealthy behaviour. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
IP options (was: Processing IP options reveals IPSTEALH router)
On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: By the way, is it correct to forward the packet with incorrect ip options? Now we do not. No RFC seems to specify that particularly. However, RFC 1812 reads in general: (1) A router MUST verify the IP header, as described in section [5.2.2], before performing any actions based on the contents of the header. This allows the router to detect and discard bad packets before the expenditure of other resources. Meanwhile more IP option issues came to my attention... Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following: if a source-routed IP packet reachs the end of its route, but its destination address doesn't match a current host/router, whether the packet should be discarded, sent forth through usual routing or accepted as destined for this host? FreeBSD will route such a packet as usual. Then, a FreeBSD host (net.inet.ip.forwarding=0) will respond with Source Route Failed ICMPs to source-routed IP packets if source route processing is prohibited using net.inet.ip.sourceroute or net.inet.ip.accept_sourceroute. To my mind, it may be deduced from RFC 1122 that a host must stay silent in this case... -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Wed, Dec 19, 2001 at 10:32:42PM +0100, Wilko Bulte wrote: First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? I would assume IPSTEALTH is thought to be for firewalls. Allowing source routing thru firewalls is a Bad Thing(TM) anyway, right? Source routing itself is a Bad Thing, as is TELNET or rlogin. However, this isn't a reason strong enough to drop all such stuff from FreeBSD completely. That's why we're trying to consider every possible case. IMHO increasing the number of FOO is incompatible with BAR situations is no good. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Solution for an IPFIREWALL_FORWARD panic?
Hello everybody, A kernel panic has been observed in both branches under the following conditions: o ipfw is configured with a fwd rule for outgoing packets that will match some RIP datagrams o GateD is started with RIP enabled and consequently sends a broadcast UDP datagram that matches the fwd rule The panic happens there (the source file is sys/netinet/ip_output.c; quoted as to rev. 1.99.2.21): 740 if (ro_fwd-ro_rt-rt_flags RTF_HOST) 741 isbroadcast = 742 (ro_fwd-ro_rt-rt_flags RTF_BROADCAST); 743 else 744 isbroadcast = in_broadcast(dst-sin_addr, ifp); 745 RTFREE(ro-ro_rt); ^^^ 746 ro-ro_rt = ro_fwd-ro_rt; 747 dst = (struct sockaddr_in *)ro_fwd-ro_dst; ro-ro_rt is NULL, which causes the panic. As far as I understand the ip_output() code, ro-ro_rt being NULL at that point is actually all right, so to solve the problem, the code just must be changed as follows: RTFREE(ro-ro_rt); -- if (ro-ro_rt) RTFREE(ro-ro_rt); Am I right? Or ro-ro_rt should not be NULL there at all and the actual bug hides somewhere else? -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: utmp(5) manpage revised
Thank you Terry for your comments! On Fri, Oct 12, 2001 at 11:31:01AM -0700, Terry Lambert wrote: Yar Tikhiy wrote: The current utmp(5) manpage language (not markup) has a number of drawbacks and errors: o There is no information for programmers on the actual structure of the files the page describes. It is opaque. You are not supposed to access it directly, you are supposed to use library routines. You could make the same argument about db files... There are no library functions to manage the lastlog file yet, so at least this file's structure should be documented. Why not to stay consistent and document the two other files granted that their structure can be described in a sentence or two? o The C structure members aren't described. The C data structures aren't opaque that much either. The lastlog file is still managed directly, and the login(3) function takes a pointer to struct utmp. o It describes in a wrong way how a user's logout is recorded to wtmp. I'm not sure that that's not an implementation detail that should be reomved from the man page entirely, but what you've done is equally valid. No it shouldn't. The authors of applications similar to SSH or telnetd need to know how to record user logouts. Of course, nobody is likely to start an alternative network terminal access project within the next few years, but... :-) Here's a patch addressing all the issues. Review it please. I'm not sure that the structure should be documented, as it will encourage people to access the data directly. The point of having them access it through library routines is that it's possible to replace the implementation by replacing the libc.so on a system, and have software continue to function. Or, it's possible to install binaries that use libc.so on a system with a different underlying implementaiton, and have them just work for commercial vendors. FreeBSD is an open system, so IMHO people would be better discouraged of accessing the files directly by a paragraph in the manpage, which reads: Don't do it, or this or that trouble will happen because of the following reason -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Valid user name
On Fri, Oct 12, 2001 at 07:24:57PM +0300, Peter Pentchev wrote:
On Fri, Oct 12, 2001 at 09:52:10AM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] Yar Tikhiy writes:
: Is there any reason to omit the period ('.') from the list of valid
: characters? With the period included, the list would conform to
: POSIX's definition of a valid user name.
Not any more. it used to be that chown user.group would be
ambiguous. now it isn't, since user:group is the right syntax.
This might be a problem for NIS or Kerberos domains - an older version
of FreeBSD might be confuzzled by usernames which are perfectly valid
for the rest of the client boxes.
Oh, I see. Given that the only issue about the period in user names
is compatibility, should pw(8) and adduser(8) still reject it or accept
it and print a warning? I think printing a warning is better since
the validity check is by no means a panacea--a stupid admin can always
use vipw(8) to create any kind of an invalid user name.
--
Yar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Valid user name
Hi there,
Now adduser(8) and pw(8) differ in what a valid user name is.
Adduser(8) enforces a user name to match the /^[a-z0-9_][a-z0-9_\-]*$/
regexp. OTOH, pw(8) uses the Good Old Wrong Way of checking validity--
it checks a user name against a list of *invalid* characters.
I'm going to fix pw(8) so its view on valid user names is consistent
with that of adduser(8).
Is there any reason to omit the period ('.') from the list of valid
characters? With the period included, the list would conform to
POSIX's definition of a valid user name.
--
Yar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
utmp(5) manpage revised
Hi everybody,
The current utmp(5) manpage language (not markup)
has a number of drawbacks and errors:
o There is no information for programmers on the actual structure
of the files the page describes.
o The C structure members aren't described.
o Despites the page language, neither utmp nor lastlog grow
continually or need rotation.
o It describes in a wrong way how a user's logout is recorded to wtmp.
o The login(3), logout(3) and logwtmp(3) functions aren't mentioned.
Here's a patch addressing all the issues. Review it please.
--
Yar
Index: utmp.5
===
RCS file: /home/ncvs/src/share/man/man5/utmp.5,v
retrieving revision 1.16
diff -u -r1.16 utmp.5
--- utmp.5 2001/10/11 11:29:37 1.16
+++ utmp.5 2001/10/11 12:59:35
@@ -57,12 +57,6 @@
the
.Nm wtmp
file.
-.Pp
-These files can grow rapidly on busy systems, so daily or weekly rotation
-is recommended.
-If any one of these files does not exist, it is not created.
-They must be created manually and are maintained by
-.Xr newsyslog 8 .
.Bd -literal -offset indent
#define _PATH_UTMP /var/run/utmp
#define _PATH_WTMP /var/log/wtmp
@@ -73,19 +67,39 @@
#define UT_HOSTSIZE 16
struct lastlog {
-time_t ll_time;
-charll_line[UT_LINESIZE];
-charll_host[UT_HOSTSIZE];
+time_t ll_time; /* When user logged in */
+charll_line[UT_LINESIZE]; /* Terminal line name */
+charll_host[UT_HOSTSIZE]; /* Host user came from */
};
struct utmp {
-charut_line[UT_LINESIZE];
-charut_name[UT_NAMESIZE];
-charut_host[UT_HOSTSIZE];
-time_t ut_time;
+charut_line[UT_LINESIZE]; /* Terminal line name */
+charut_name[UT_NAMESIZE]; /* User's login name */
+charut_host[UT_HOSTSIZE]; /* Host user came from */
+time_t ut_time; /* When user logged in */
};
.Ed
.Pp
+The
+.Nm lastlog
+file is a linear array of
+.Fa lastlog
+structures indexed by a user's
+.Tn UID .
+The
+.Nm utmp
+file is a linear array of
+.Fa utmp
+structures indexed by a terminal line number
+(see
+.Xr ttyslot 3 ) .
+The
+.Nm wtmp
+file consists of
+.Fa utmp
+structures and is a binary log file,
+that is, grows linearly at its end.
+.Pp
Each time a user logs in, the
.Xr login 1
program looks up the user's
@@ -132,10 +146,19 @@
and appends the user's
.Fa utmp
record.
-The same
+The user's subsequent logout from the terminal
+line is marked by a special
.Fa utmp
-record, with an updated time stamp is later appended
-to the file when the user logs out (see
+record with
+.Fa ut_line
+set accordingly,
+.Fa ut_time
+updated, but
+.Fa ut_name
+and
+.Fa ut_host
+both empty
+(see
.Xr init 8 ) .
The
.Nm wtmp
@@ -184,6 +207,29 @@
.Ql \{
indicates the new time.
.El
+.Sh NOTES
+The
+.Nm wtmp
+file can grow rapidly on busy systems, so daily or weekly rotation
+is recommended.
+It is maintained by
+.Xr newsyslog 8 .
+.Pp
+If any one of these files does not exist, it is not created by
+.Xr login 1 .
+They must be created manually.
+.Pp
+The supplied
+.Xr login 3 ,
+.Xr logout 3 ,
+and
+.Xr logwtmp 3
+utility functions should be used to perform
+the standard actions on the
+.Nm utmp
+and
+.Nm wtmp
+files.
.Sh FILES
.Bl -tag -width /var/log/lastlog -compact
.It Pa /var/run/utmp
@@ -204,6 +250,10 @@
.Xr login 1 ,
.Xr w 1 ,
.Xr who 1 ,
+.Xr login 3 ,
+.Xr logout 3 ,
+.Xr logwtmp 3 ,
+.Xr ttyslot 3 ,
.Xr ac 8 ,
.Xr init 8
.Sh HISTORY
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Some thoughts on if_ioctl()
On Mon, Oct 08, 2001 at 02:53:32PM -0400, Garrett Wollman wrote:
On Mon, 8 Oct 2001 11:32:14 +0400, Yar Tikhiy [EMAIL PROTECTED] said:
Second, let's look at the handling of SIOCADDMULTI/SIOCDELMULTI.
There is code obviously taken from if_loop.c and used in some
drivers, which tries to do something with the third argument data
of the if_ioctl() driver method if data isn't NULL.
The historic implementation passed SIOCADDMULTI directly down to the
interface to implement, which resulted in lots of duplicated code all
over the place to manage the list of multicast addresses. Several
years ago, I rewrote the multicast management code to simply indicate
to the driver when the list has changed, obviating the need for the
driver itself to manage the list.
If I understand the kernel code right, if_ioctl()'s third argument
is always NULL
Not so. Any ioctl() in class 'i' which is not handled by the generic
code will get passed down to the driver to handle; some of these
requests may require the data pointer.
Sorry, I wrote an unclear phrase. I implied not all possible ioctl(2)
requests, but only the SIOC{ADD|DEL}MULTI case. In that case, data
seems to be always NULL since it's the way if_addmulti() and
if_delmulti() call ifp-if_ioctl(), and there is no other way to
pass SIOC{ADD|DEL}MULTI to a driver's if_ioctl(). If it's true,
all the old ugly code about AF_INET and AF_INET6 multicast groups
may be safely removed from the interface drivers. All the interface
drivers will fall into two categories:
- those which may simply do nothing on these requests (if_loop, if_sl...)
- those which will rebuild some sort of a hardware multicast filter.
--
Yar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Some thoughts on if_ioctl()
Hi there, I'd like to discuss the following issues prior to modifying the kernel. First, the current implementation of the utility function ether_ioctl(), which can do good job common to ethernet drivers, won't indicate the situation when an ioctl command is unsupported by it. It will return 0 in this case. Wouldn't it be better to return EINVAL so the driver can do something about that? Now each driver using ether_ioctl() has to maintain painfully the list of the ioctl commands that may be passed to ether_ioctl(), or the kernel will be likely to panic in copyout() dereferencing a NULL pointer. Second, let's look at the handling of SIOCADDMULTI/SIOCDELMULTI. There is code obviously taken from if_loop.c and used in some drivers, which tries to do something with the third argument data of the if_ioctl() driver method if data isn't NULL. If I understand the kernel code right, if_ioctl()'s third argument is always NULL and serves nothing since these ioctl commands just notify the driver that the list of multicast groups on an interface has been changed. Is it true? If it is, I'd like to remove the questionable code and document the feature in ifnet(9) for newbie kernel hackers will be confused no longer. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Driver structures alignment
On Thu, Sep 13, 2001 at 04:09:57PM -0700, Mike Smith wrote:
Is there a single blessed way to define packed structures
for use in drivers? I suspect that using #pragma pack(1)
will lead to alignment errors in non-Intel architectures.
Any form of packing is going to cause problems for items that are
located in illegal fashions.
Having said that, I recommend using __attribute__ ((packed))
to explicitly request that a structure be packed.
Should the __attribute__ be supplied to each structure's member?
Or can it be the whole structure's attribute?
And is it OK to rely on specially crafted structures, like
struct fs in /sys/ufs/ffs/fs.h where multi-byte elements
are pre-aligned by the structure's design, being contiguous?
rely in what fashion?
E.g., will the following structure:
struct foo {
int16_t a;
int16_t b;
int32_t c; /* 4-byte boundary */
int64_t d; /* 8-byte boundary */
int8_t e[4];
int32_t f; /* 4-byte boundary */
};
contain alignment holes in any architecture/compiler?
--
Yar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Driver structures alignment
Hi there, Is there a single blessed way to define packed structures for use in drivers? I suspect that using #pragma pack(1) will lead to alignment errors in non-Intel architectures. Should char arrays be used for all multi-byte elements to avoid alignment problems? And is it OK to rely on specially crafted structures, like struct fs in /sys/ufs/ffs/fs.h where multi-byte elements are pre-aligned by the structure's design, being contiguous? -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: finger/fingerd home directory permissions
On Thu, Aug 09, 2001 at 12:29:33AM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Yar Tikhiy writes: : The issue I'd like to submit to discussion is what way to choose: : a) Add a command-line option to finger(1) and fingerd(8) telling :them not to reveal user information if the user's homedir is :protected. : b) Similar to a), but hide such users by default. : c) Don't bother at all :-) d) $HOME/.nofinger It's just an equivalent of c) ;-) The top part of my message, which you skipped, I was speaking of the case when finger(1) couldn't access the home directory of a user and see the .nofinger file because of restrictive permission bits set on the directory. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
