Re: rpcbind does not honor -h flag
Please file a PR against rc ASAP. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117711 -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Some performance measurements on the FreeBSD network stack
Hi, On Tue, 24 Apr 2012, 17:40-, Li, Qing wrote: Yup, all good points. In fact we have considered all of these while doing the work. In case you haven't seen it already, we did write about these issues in our paper and how we tried to address those, flow-table was one of the solutions. http://dl.acm.org/citation.cfm?id=1592641 Is this article available for those without ACM subscription? -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: man ugen error
On Fri, 2 Dec 2011, 11:07-, Thomas Mueller wrote: in FreeBSD 10-current. It should be removed and added to old files. Could you make a patch for that? --HPS I found /usr/share/man/man4/ugen.4.gz in FreeBSD 9.0-RC2. What needs to be patched? What file, where? Might it be /usr/src/ObsoleteFiles.inc ? I have extremely limited experience applying patches, no experience writing a patch. Where do I learn what and how to do? I might need to see some examples to get me started. Something like that should work: Index: ObsoleteFiles.inc === --- ObsoleteFiles.inc (revision 231431) +++ ObsoleteFiles.inc (working copy) @@ -38,6 +38,8 @@ # xargs -n1 | sort | uniq -d; # done +# 20120305: ugen(4) is now part of usb(4) +OLD_FILES+=usr/share/man/man4/ugen.4.gz # 20120113: removal of wtmpcvt(1) OLD_FILES+=usr/bin/wtmpcvt OLD_FILES+=usr/share/man/man1/wtmpcvt.1.gz Index: share/man/man4/ng_ubt.4 === --- share/man/man4/ng_ubt.4 (revision 231431) +++ share/man/man4/ng_ubt.4 (working copy) @@ -107,7 +107,6 @@ This node shuts down when the corresponding USB device is un-plugged. .Sh SEE ALSO .Xr netgraph 4 , -.Xr ugen 4 , .Xr usb 4 , .Xr ngctl 8 .Sh HISTORY Index: share/man/man4/ubtbcmfw.4 === --- share/man/man4/ubtbcmfw.4 (revision 231431) +++ share/man/man4/ubtbcmfw.4 (working copy) @@ -93,7 +93,6 @@ .El .Sh SEE ALSO .Xr ng_ubt 4 , -.Xr ugen 4 , .Xr usb 4 , .Xr bcmfw 8 .Sh HISTORY Index: share/man/man4/Makefile === --- share/man/man4/Makefile (revision 231431) +++ share/man/man4/Makefile (working copy) @@ -477,7 +477,6 @@ ufm.4 \ ufoma.4 \ uftdi.4 \ - ugen.4 \ uhci.4 \ uhid.4 \ uhso.4 \ Index: share/man/man9/DEVICE_PROBE.9 === --- share/man/man9/DEVICE_PROBE.9 (revision 231431) +++ share/man/man9/DEVICE_PROBE.9 (working copy) @@ -119,9 +119,6 @@ treatment for some reason. .It BUS_PROBE_HOOVER The driver matches all unclaimed devices on a bus. -The -.Xr ugen 4 -device is one example. .It BUS_PROBE_NOWILDCARD The driver expects its parent to tell it which children to manage and no probing is really done. Index: usr.sbin/bluetooth/bcmfw/bcmfw.8 === --- usr.sbin/bluetooth/bcmfw/bcmfw.8(revision 231431) +++ usr.sbin/bluetooth/bcmfw/bcmfw.8(working copy) @@ -96,8 +96,7 @@ .Pp .Dl bcmfw -n ubtbcmfw0 -m BCM2033-MD.hex -f BCM2033-FW.bin .Sh SEE ALSO -.Xr ubtbcmfw 4 , -.Xr ugen 4 +.Xr ubtbcmfw 4 .Sh AUTHORS .An Maksim Yevmenkin Aq m_evmen...@yahoo.com .Sh BUGS %%% I'm not sure about the date of ugen.4 removal, so I put the current date. Also, there are some references to ugen.4 in the following man pages: ./usr.sbin/bluetooth/ath3kfw/ath3kfw.8 ./usr.sbin/uathload/uathload.8 Not sure how to deal with them. -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: man ugen error
[...] Also, there are some references to ugen.4 in the following man pages: ./usr.sbin/bluetooth/ath3kfw/ath3kfw.8 ./usr.sbin/uathload/uathload.8 Not sure how to deal with them. /dev/ugen is still there, but ugen as a separate and configurable kernel device was removed in FreeBSD-8. Understood. But they do have a reference to ugen(4) man page that we are going to remove, not to /dev/ugen. -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RLIMIT_DATA and malloc(3) use of mmap(2)
Hi Kostik, On Fri, 9 Dec 2011, 13:56+0400, Maxim Konovalov wrote: On Fri, 25 Nov 2011, 22:21+0400, Maxim Konovalov wrote: [...] Fixed patch is available at http://people.freebsd.org/~kib/misc/map_datalimit.2.patch Works as expected without any glitches. I understand that you are busy with the release. But is there a plan to commit this code somewhere in the near future? Are there any news? -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RLIMIT_DATA and malloc(3) use of mmap(2)
Hi Kostik, I understand that you are busy with the release. But is there a plan to commit this code somewhere in the near future? On Fri, 25 Nov 2011, 22:21+0400, Maxim Konovalov wrote: [...] Fixed patch is available at http://people.freebsd.org/~kib/misc/map_datalimit.2.patch Works as expected without any glitches. -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RLIMIT_DATA and malloc(3) use of mmap(2)
[...] Overall, the test is quite curious but absolutely unrealistic. If there is a realistic one I'm open to use it :-) Fixed patch is available at http://people.freebsd.org/~kib/misc/map_datalimit.2.patch OK, will test and report the results shortly. -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RLIMIT_DATA and malloc(3) use of mmap(2)
[...] Fixed patch is available at http://people.freebsd.org/~kib/misc/map_datalimit.2.patch Works as expected without any glitches. -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RLIMIT_DATA and malloc(3) use of mmap(2)
Hi Kostik, On Wed, 23 Nov 2011, 11:22+0400, Maxim Konovalov wrote: [...] Anyway, the patch needs testers before I will push it forward. [igor's email was corrected] We will test it in out environment and let you know. It seems I don't understand how it works. Here is a test program: http://maxim.int.ru/stuff/malloc_test.c.txt It allocates successfully 64x1MB chunks by malloc(), reallocf() and realloc() with the following command line: MALLOC_OPTIONS=JM limits -d 10m ./malloc_test When we add L flag to the MALLOC_OPTIONS it starts to work strange: It allocates 64MB via malloc() but fails to allocate more than 3MB by realloc() and reallocf(). More funny, the result varies from time to time: $ MALLOC_OPTIONS=JML limits -d 10m ./malloc_test | head RLIMIT_DATA: rlim_cur is 10485760, rlim_max is 10485760 1th allocation failed 2th allocation failed 3th allocation failed 4th allocation failed 5th allocation failed 6th allocation failed 7th allocation failed 8th allocation failed 9th allocation failed $ MALLOC_OPTIONS=JML limits -d 10m ./malloc_test | head RLIMIT_DATA: rlim_cur is 10485760, rlim_max is 10485760 1048576 bytes successfuly allocated 2097152 bytes successfuly allocated 3145728 bytes successfuly allocated 4194304 bytes successfuly allocated 5242880 bytes successfuly allocated 6291456 bytes successfuly allocated 7340032 bytes successfuly allocated 8388608 bytes successfuly allocated 9437184 bytes successfuly allocated $ MALLOC_OPTIONS=JML limits -d 10m ./malloc_test | head RLIMIT_DATA: rlim_cur is 10485760, rlim_max is 10485760 1th allocation failed 2th allocation failed 3th allocation failed 4th allocation failed 5th allocation failed 6th allocation failed 7th allocation failed 8th allocation failed 9th allocation failed It's today -current with your patch. -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RLIMIT_DATA and malloc(3) use of mmap(2)
[...] Anyway, the patch needs testers before I will push it forward. [igor's email was corrected] We will test it in out environment and let you know. Thanks for the patch! -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Running all regression tests
On Thu, 3 Jun 2010, 12:02+0200, Erik Cederstrand wrote: Hi, I'd like to run the regression tests in src/tools/regression on a regular basis. What's the official way to do this? Is there some way I can run them all in one go? There is no one. Yet. It seems it's necessary to enter every single subdirectory and execute any Makefiles located there before running 'prove -r'. Some of the tests don't contain .t files, so I assume they can't be run using 'prove'? Yes, correct. Also, I'd like to filter out the tests that don't apply on my system, e.g. zfs tests. Thanks, Erik -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Running all regression tests
On Thu, 3 Jun 2010, 15:15+0200, Erik Cederstrand wrote: Den 03/06/2010 kl. 14.53 skrev Mehmet Erol Sanliturk: I do not know how to perform regression tests , but is it not possible to write a shell script to perform the above manual steps ? I just wrote a shell script to recurse into the subdirectories and run make on the Makefiles found. Unfortunately, some of the Makefiles start running tests immediately, some have syntax errors etc., so I'll have to add some more logic. It would be nice to get patches while you are there. -- Maxim Konovalov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: UFS file system problem in either stable or current
On Sun, 2 Nov 2003, 11:18+0200, Valentin Nechayev wrote: Wed, Oct 22, 2003 at 03:14:33, strick (Dan Strick) wrote about UFS file system problem in either stable or current: DS There seems to be an inconsistency between release 4.9-RC and 5.1 ufs DS support. If I fsck the same ufs (type 1 of course) file system on DS both releases, each claims that the other has left incorrect DS summary data in the superblock. Presumably only one can be correct. DS I just don't know which to blame. Does this require explicit fsck? I have dual-booting between 4.9-release (and all previous 4.* releases earlier) and 5.1 (of 20030526) with shared disks and boot checking required in fstab; sometimes one of them crash and forced checking is made; neither 4.* nor 5.1 claims superblock is bad. mckusick's answer: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=100639+0+archive/2003/freebsd-current/20030323.freebsd-current Dan's PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/58373 -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Mon, 15 Sep 2003, 23:48-0600, Scott Long wrote: All, I'd like to give a status report for 4.x and 5.x for the developers and users who didn't attend the DevSummit this past weekend. 4.9: The 4.9 release is likely going to be pushed back for a few weeks while the recent instability reports are tracked down. The target goal is two weeks, but hopefully things can be resolved before then. The problems appear to stem from the recent PAE import. The consensus reached at the DevSummit is that PAE is a critical feature for 4.x and that removing it isn't desirable unless the problems persist. We encourage anyone to help with this. PAE MFC brought an incredible instability to stable branch. It affects 100% of our user community especially when we issued several SAs since PAE commit. They often can't switch to RELENG_4_x security branches because even RELENG_4_8 misses several critical non-security fixes. I believe stability was a critical feature of stable branch. Not PAE or anything alse. That is why I think we have to back out all that PAE code from stable. [5.x stuff] -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cdcontrol no longer needs 'c' partition?
On Fri, 22 Aug 2003, 19:49+0400, Maxim Konovalov wrote: On Fri, 22 Aug 2003, 10:39-0400, Craig Rodrigues wrote: On Fri, Aug 22, 2003 at 09:00:32AM +0400, Maxim Konovalov wrote: On Sun, 17 Aug 2003, 17:21-0400, Craig Rodrigues wrote: Hi, With GEOM in place, is the 'c' partition for a CD device no longer necessary for cdcontrol? At least on my system, the CD shows up as /dev/acd0, not as /dev/acd0c. What's about CDROM environment var defined in login.conf? I don't understand your question. If the CDROM environment variable is set to a device name, cdcontrol will try to open that device. This is documented in the cdcontrol man page. If the CDROM environment variable is not set, a default device name of of /dev/cd0c is used, unless you override this with the -f flag. Ah, nevermind, I messed with my local login.conf modifications. Your patch looks OK, I will commit it on the next week if nobody objects. done. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cdcontrol no longer needs 'c' partition?
On Fri, 22 Aug 2003, 10:39-0400, Craig Rodrigues wrote: On Fri, Aug 22, 2003 at 09:00:32AM +0400, Maxim Konovalov wrote: On Sun, 17 Aug 2003, 17:21-0400, Craig Rodrigues wrote: Hi, With GEOM in place, is the 'c' partition for a CD device no longer necessary for cdcontrol? At least on my system, the CD shows up as /dev/acd0, not as /dev/acd0c. What's about CDROM environment var defined in login.conf? I don't understand your question. If the CDROM environment variable is set to a device name, cdcontrol will try to open that device. This is documented in the cdcontrol man page. If the CDROM environment variable is not set, a default device name of of /dev/cd0c is used, unless you override this with the -f flag. Ah, nevermind, I messed with my local login.conf modifications. Your patch looks OK, I will commit it on the next week if nobody objects. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cdcontrol no longer needs 'c' partition?
On Sun, 17 Aug 2003, 17:21-0400, Craig Rodrigues wrote: Hi, With GEOM in place, is the 'c' partition for a CD device no longer necessary for cdcontrol? At least on my system, the CD shows up as /dev/acd0, not as /dev/acd0c. What's about CDROM environment var defined in login.conf? [ patch ] -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: authenticated tftp
On Fri, 25 Jul 2003, 13:22-0400, Robert Watson wrote: Yeah, seems like an oxy-moron, but this is a legitimate question, I promise. My linksys wireless router requires me to disable the admin password on it to tftp a firmware update to it--however, the Windows tftp client that Linksys ships appear to support some form of Oh yeah, and here's a password. It probably really doesn't make a difference security-wise, but it would be a lot more convenient to update wireless routers if our tftp client spoke whatever extension they use to carry the password. Does anyone know anything about that protocol extension, or if there are existing tweaks to add it to our tftp? (I saw nothing in the man page). If there's a pointer to the on-the-write bits, I can always stick it in myself, but I have yet to find one. There are several tftp extension that NetBSD folk integrated to their tftpd/tftp recently. IIRC they were 2347 TFTP Option Extension. G. Malkin, A. Harkin. May 1998. (Format: 2348 TFTP Blocksize Option. G. Malkin, A. Harkin. May 1998. (Format: 2349 TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. I know nothing about auth extension yet but the protocol is quite simple (trivial :-)) and if you get a dump of udp session between the router and windows tftp client it would be easy incorporate this one. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: netstat
On Tue, 1 Jul 2003, 22:45+1200, Andrew Thompson wrote: Hi, Is there any reason that the interface name in netstat is truncated at 5 chars? I have a box with ~100 vlans so the interface name gets chopped after vlan9. Here is a patch to increase it to 7 chars. Any probs? bin/52349 -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia kernel driver support for FreeBSD-5.1
On Wed, 18 Jun 2003, 09:14+0200, Juan Rodriguez Hervella wrote: Hello: I've got a PCI-NVidia Riva TNT 64 video card at home, and I've tried to compile the drivers but it doesn't work, and after changing the source to let the compilation progress, when the module is loaded I've received a kernel panic. Im using FreeBSD-5.1 with XFree86-4.3, what can I do to solve this issue ? I can not run the X system using the nv driver, my computer hangs up. Any help will be useful, thanks! Make sure you do not have 'options INVARIANTS' in your kernel config file. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 06/05/2003 breaks nvidia driver
On Thu, 5 Jun 2003, 18:56-0500, [EMAIL PROTECTED] wrote: Thanks for the suggestion about recompiling the nvidia driver, but I do after each kernel compile and install, so that isn't the answer, though not a bad idea. Recompiles of both the Linux-nvidia-port and the standalone-nvidia driver failed, so I am in the process, now, of backing out of everything that was updated. Are there any suggestions for better diagnosing of the problem? nvidia.ko and X work OK for me on yesterday -current: nvidia0: GeForce4 MX 460 mem 0xef80-0xef87,0xf000-0xf7ff,0xed00-0xedff irq 11 at device 0.0 on pci1 Don't know what linux-nvidia-port is for. [...] -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTP client dumping core
On Thu, 5 Jun 2003, 12:57-0300, Fred Souza wrote: Try this patch: Yes, it works now, thanks. Will this patch be commited to src, or should I keep it and apply locally? I have posted the patch to [EMAIL PROTECTED], hope he will commit it soon or later. FreeBSD will get this code with a next lukemftp import. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTP client dumping core
On Wed, 4 Jun 2003, 20:58-0300, Fred Souza wrote: I think what Kris ment was something similiar to cd /usr/src/usr.bin/ftp make clean make DEBUG_FLAGS=-g all install Ahh, yes, with that I can see where the problem is. It's because of my custom prompt, which should look like ftp [EMAIL PROTECTED]:directory Here's the output of gdb+ftp with the above debug flag: (gdb) run x.y.z.w Starting program: /usr/bin/ftp x.y.z.w Connected to x.y.z.w. 220 h4w h4w h4w Name (x.y.z.w:fred): ftp 530 Sorry, no ANONYMOUS access allowed. ftp: Login failed. Program received signal SIGSEGV, Segmentation fault. 0x0805e346 in formatbuf (buf=0x8069780 ftp , len=1024, src=0x806f110 ftp [EMAIL PROTECTED]:%/ ) at /usr/src/contrib/lukemftp/src/util.c:1400 1400for (p2 = connected ? username : -; *p2 ; p2++) (gdb) I see now where the problem is, but shouldn't the client handle this kind of situation better? Try this patch: Index: util.c === RCS file: /home/ncvs/src/contrib/lukemftp/src/util.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 util.c --- util.c 15 Jun 2002 09:40:37 - 1.1.1.2 +++ util.c 5 Jun 2003 05:55:23 - @@ -1397,7 +1397,8 @@ break; case 'n': - for (p2 = connected ? username : -; *p2 ; p2++) + for (p2 = connected username ? username : -; + *p2 ; p2++) ADDBUF(*p2); break; %%% -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: breakage this morning
On 16:51+0200, Apr 2, 2003, Sheldon Hearn wrote: On (2003/04/02 09:43), Michael W . Lucas wrote: You sure you didn't get caught in the middle of a cvsup mirror sync? I have an IP_EVIL world and kernel running fine here. According to some folks on IRC, it was renamed to IP_EF in src/sys/netinet/ip.h, but not renamed in ping.c. I just finished re-supping from cvsup16, and while I got some updates, an update to ping_c was not among them... Ah, so it's me who got lucky, not you who got unlucky. fixed. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
softupdates panic?
= 0
#9 0xc03018c8 in ufs_inactive (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_inode.c:123
vp = (struct vnode *) 0xc4636490
ip = (struct inode *) 0xc4632990
td = (struct thread *) 0xc477b3c0
mode = 29566
error = 0
#10 0xc0308db8 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2787
No locals.
#11 0xc0283c1f in vrele (vp=0xc4636490) at vnode_if.h:930
td = (struct thread *) 0xc477b3c0
#12 0xc028dd8d in vn_close (vp=0xc477b3c0, flags=0, file_cred=0x0, td=0x0)
at /usr/src/sys/kern/vfs_vnops.c:323
error = -1000119152
#13 0xc028ebf0 in vn_closefile (fp=0x0, td=0x0)
---Type return to continue, or q return to quit---
at /usr/src/sys/kern/vfs_vnops.c:894
No locals.
#14 0xc021c30c in fdrop_locked (fp=0xc477b3c0, td=0x0) at file.h:282
lf = {l_start = -4601881725287535548, l_len = 37585162180,
l_pid = -1070006675, l_type = 1662, l_whence = 0}
vp = (struct vnode *) 0xc4636490
error = -1000119152
#15 0xc021bdce in fdrop (fp=0xc4636490, td=0x0)
at /usr/src/sys/kern/kern_descrip.c:1663
No locals.
#16 0xc021bd7c in closef (fp=0xc477b3c0, td=0xc4636490)
at /usr/src/sys/kern/kern_descrip.c:1649
vp = (struct vnode *) 0x0
lf = {l_start = -4601881454704595784, l_len = 37655929908,
l_pid = -1070006675, l_type = 828, l_whence = 0}
#17 0xc021a548 in close (td=0xc477b3c0, uap=0x0)
at /usr/src/sys/kern/kern_descrip.c:830
fdp = (struct filedesc *) 0xc4636490
fp = (struct file *) 0xc47717f8
fd = -998788160
error = -1000119152
#18 0xc0353ebe in syscall (frame=
{tf_fs = 672006191, tf_es = 47, tf_ds = -1078001617, tf_edi = 0, tf_esi =
---Type return to continue, or q return to quit---
673269496, tf_ebp = -1077938616, tf_isp = -505418380, tf_ebx = 673194620, tf_edx = 0,
tf_ecx = 673269496, tf_eax = 6, tf_trapno = 12, tf_err = 2, tf_eip = 672716115, tf_cs
= 31, tf_eflags = 530, tf_esp = -1077938628, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1030
params = 0xbfbff640---Can't read userspace from dump, or kernel process---
(kgdb) quit
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
jail(8) setuid-before-exec patch
Hello,
Here is a patch which gives to jail(8) an ability to specify a user
context before execv(3). Comments/suggestions?
P.S. I am aware of bin/44320.
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/jail/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile20 Jul 2001 06:19:52 - 1.8
+++ Makefile21 Mar 2003 14:16:25 -
@@ -2,6 +2,7 @@
PROG= jail
MAN= jail.8
+LDADD= -lutil
WARNS?=2
Index: jail.8
===
RCS file: /home/ncvs/src/usr.sbin/jail/jail.8,v
retrieving revision 1.41
diff -u -r1.41 jail.8
--- jail.8 18 Mar 2003 14:01:02 - 1.41
+++ jail.8 24 Mar 2003 15:06:08 -
@@ -41,11 +41,28 @@
.Nd imprison process and its descendants
.Sh SYNOPSIS
.Nm
+.Op Fl u Ar username
.Ar path hostname ip-number command ...
.Sh DESCRIPTION
The
.Nm
utility imprisons a process and all future descendants.
+.Pp
+The options are as follows:
+.Bl -tag -width .Fl u Ar username
+.It Fl u Ar username
+The user name as whom the
+.Ar command
+should run.
+.It Ar path
+Directory which is to be the root of the prison.
+.It Ar hostname
+Hostname of the prison.
+.It Ar ip-number
+IP number assigned to the prison.
+.It Ar command
+Pathname of the program which is to be executed.
+.El
.Pp
Please see the
.Xr jail 2
Index: jail.c
===
RCS file: /home/ncvs/src/usr.sbin/jail/jail.c,v
retrieving revision 1.8
diff -u -r1.8 jail.c
--- jail.c 22 Apr 2002 13:44:43 - 1.8
+++ jail.c 21 Mar 2003 16:15:15 -
@@ -10,44 +10,97 @@
*
*/
-#include sys/types.h
+#include sys/param.h
#include sys/jail.h
#include netinet/in.h
#include arpa/inet.h
#include err.h
+#include grp.h
+#include login_cap.h
+#include pwd.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
+static voidusage(void);
+
int
main(int argc, char **argv)
{
+ login_cap_t *lcap;
struct jail j;
- int i;
+ struct passwd *pwd;
struct in_addr in;
+ int ch, groups[NGROUPS], i, ngroups;
+ char *username;
+
+ username = NULL;
+
+ while ((ch = getopt(argc, argv, u:)) != -1)
+ switch (ch) {
+ case 'u':
+ username = optarg;
+ break;
+ default:
+ usage();
+ break;
+ }
+ argc -= optind;
+ argv += optind;
+ if (argc 4)
+ usage();
- if (argc 5)
- errx(1, usage: %s path hostname ip-number command ...\n,
- argv[0]);
- i = chdir(argv[1]);
+ if (username != NULL) {
+ pwd = getpwnam(username);
+ if (pwd == NULL)
+ err(1, getpwnam %s, username);
+ lcap = login_getpwclass(pwd);
+ if (lcap == NULL)
+ err(1, getpwclass failed, username);
+ ngroups = NGROUPS;
+ i = getgrouplist(username, pwd-pw_gid, groups, ngroups);
+ if (i)
+ err(1, getgrouplist %s, username);
+ }
+ i = chdir(argv[0]);
if (i)
- err(1, chdir %s, argv[1]);
+ err(1, chdir %s, argv[0]);
memset(j, 0, sizeof(j));
j.version = 0;
- j.path = argv[1];
- j.hostname = argv[2];
- i = inet_aton(argv[3], in);
+ j.path = argv[0];
+ j.hostname = argv[1];
+ i = inet_aton(argv[2], in);
if (!i)
errx(1, Couldn't make sense of ip-number\n);
j.ip_number = ntohl(in.s_addr);
i = jail(j);
if (i)
err(1, Imprisonment failed);
- i = execv(argv[4], argv + 4);
+ if (username != NULL) {
+ i = setgroups(ngroups, groups);
+ if (i)
+ err(1, setgroups failed);
+ i = setgid(pwd-pw_gid);
+ if (i)
+ err(1, setgid failed);
+ i = setusercontext(lcap, pwd, pwd-pw_uid,
+ LOGIN_SETALL ~LOGIN_SETGROUP);
+ if (i)
+ err(1, setusercontext failed);
+ }
+ i = execv(argv[3], argv + 3);
if (i)
- err(1, execv(%s), argv[4]);
+ err(1, execv(%s), argv[3]);
exit (0);
+}
+
+static void
+usage(void)
+{
+
+ errx(1,
+ Usage: jail [-u username] path hostname ip-number command ...);
}
%%%
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Freeze from pppd
Try a next patch.
Index: if_ppp.c
===
RCS file: /home/ncvs/src/sys/net/if_ppp.c,v
retrieving revision 1.90
diff -u -r1.90 if_ppp.c
--- if_ppp.c4 Mar 2003 23:19:51 - 1.90
+++ if_ppp.c23 Mar 2003 17:05:28 -
@@ -1571,7 +1571,7 @@
rv = IF_HANDOFF(sc-sc_inq, m, NULL);
else
rv = netisr_queue(isr, m);
-if (rv) {
+if (!rv) {
if (sc-sc_flags SC_DEBUG)
if_printf(ifp, input queue full\n);
ifp-if_iqdrops++;
%%%
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Freeze from pppd
On 10:39-0800, Mar 19, 2003, Tod Oace wrote: I'm hoping someone can help me debug the following problem (a fix would be welcome too :) ). I'm using mgetty to receive faxes and to accept a dialup ppp connection. I used to use something called ppplogin to handle the incoming ppp but decided to switch to pppd with FreeBSD 5.0 because my ppplogin is old and I don't even remember where I got it from. So now in /usr/local/etc/mgetty+sendfax/login.config I have: /AutoPPP/ - a_ppp /usr/sbin/pppd auth -chap +pap login debug The problem I'm having is that when an incoming ppp connectionattempt is made my FreeBSD 5.0 machine freezes up. I can't even get to the debugger with Ctrl-Alt-Esc like I normally can. Here are the last few Known bug: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=180644+0+archive/2003/freebsd-current/20030316.freebsd-current I suspect that commit: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1123119+0+archive/2003/cvs-all/20030309.cvs-all [...] -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic at soreceive()?
Hello, Starting pppd(8) on yesterday -current produces a panic: miss# gdb kernel.84 -k vmcore.84 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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-undermydesk-freebsd... panic: KSE not on run queue panic messages: --- panic: receive: m == 0 so-so_rcv.sb_cc == 192 sys/kern/uipc_socket.c, line 856 syncing disks, buffers remaining... 902 902 900 900 900 900 900 panic: KSE not on run queue Uptime: 21m58s Dumping 63 MB ata0: resetting devices .. done [CTRL-C to abort] 16 32 48 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 239 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 #1 0xc01b19bf in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0xc01b1bb4 in poweroff_wait (junk=0xc02dd2bb, howto=-1054260288) at /usr/src/sys/kern/kern_shutdown.c:542 #3 0xc01bf118 in sched_rem (ke=0xc02dd2bb) at /usr/src/sys/kern/sched_4bsd.c:593 #4 0xc01b5288 in adjustrunqueue (td=0xc12943c0, newpri=180) at /usr/src/sys/kern/kern_switch.c:305 #5 0xc01bef90 in sched_prio (td=0x0, prio=0 '\0') at /usr/src/sys/kern/sched_4bsd.c:505 #6 0xc01becb4 in schedcpu (arg=0x0) at /usr/src/sys/kern/sched_4bsd.c:337 #7 0xc01bc579 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:195 #8 0xc01a3200 in ithread_loop (arg=0xc0a01200) at /usr/src/sys/kern/kern_intr.c:536 #9 0xc01a2694 in fork_exit (callout=0xc01a30e0 ithread_loop, arg=0xc0a01200, frame=0xc5ecad48) at /usr/src/sys/kern/kern_fork.c:871 (kgdb) quit -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
4.8-RC / 5-CURRENT UFS1 interoperability problem
Hello, In short, there is a problem using the same UFS1 filesystem under -stable and -current. Please look at an attached typescript for details. I noticed a wrong superblock information either: [EMAIL PROTECTED] ~]$ df /spare Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s2a 22520288 -125476 20844144-1%/spare Is it known bug? -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]golf# uname -a FreeBSD golf.macomnet.net 4.8-PRERELEASE FreeBSD 4.8-PRERELEASE #19: Thu Feb 27 13:33:49 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 golf# fsck /dev/ad0s2a ** /dev/ad0s2a ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 3 files, 3 used, 5630069 free (21 frags, 703756 blocks, 0.0% fragmentation) golf# mount /dev/ad0s2a /mnt golf# mount | grep mnt /dev/ad0s2a on /mnt (ufs, local, soft-updates) golf# exit exit - clean reboot golf# uname -a FreeBSD golf.macomnet.net 5.0-CURRENT FreeBSD 5.0-CURRENT #6: Wed Feb 19 10:01:22 MSK 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GOLF5 i386 golf# fsck /dev/ad0s2a ** /dev/ad0s2a ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups SUMMARY INFORMATION BAD SALVAGE? [yn] y SUMMARY BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y 94155 files, 220230 used, 5409842 free (15210 frags, 674329 blocks, 0.3% fragmentation) * FILE SYSTEM WAS MODIFIED * golf# mount /dev/ad0s2a /mnt golf# mount | grep mnt /dev/ad0s2a on /mnt (ufs, local, nodev, noexec, nosuid, soft-updates) golf# exit
Re: 4.8-RC / 5-CURRENT UFS1 interoperability problem
On 16:46+0200, Mar 6, 2003, Ruslan Ermilov wrote: On Thu, Mar 06, 2003 at 05:21:00PM +0300, Maxim Konovalov wrote: Hello, In short, there is a problem using the same UFS1 filesystem under -stable and -current. Please look at an attached typescript for details. I noticed a wrong superblock information either: [EMAIL PROTECTED] ~]$ df /spare Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s2a 22520288 -125476 20844144-1%/spare Is it known bug? I had this problem at one time, but only with the old 5.0-CURRENT. How fresh your -CURRENT is? Feb 19? Yes. A friend of mine reports the same misbehaviour with 5.0-REL. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
blockable sleep lock panic in latest -current.
Hello, Several identical kernel panics with today -current. I suspect recent commits to subr_witness.c. See an attachment for details. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]Script started on Thu Mar 6 18:42:01 2003 golf# gdb /usr/obj/usr/src/sys/GOLF5/kernel.debug -k vmcore.22 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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-undermydesk-freebsd... panic: bwrite: buffer is not busy??? panic messages: --- panic: blockable sleep lock (sleep mutex) sellck /usr/src/sys/kern/sys_generic.c:1191 syncing disks, buffers remaining... panic: bwrite: buffer is not busy??? Uptime: 1h37m38s Dumping 511 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 239 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 #1 0xc0235eda in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0xc0236143 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 #3 0xc02713c2 in bwrite (bp=0xce55cf28) at /usr/src/sys/kern/vfs_bio.c:795 #4 0xc02730dc in vfs_bio_awrite (bp=0xce55cf28) at /usr/src/sys/kern/vfs_bio.c:1692 #5 0xc0279ed6 in vop_stdfsync (ap=0xc044e4a4) at /usr/src/sys/kern/vfs_default.c:755 #6 0xc02014d0 in spec_fsync (ap=0xc044e4a4) at /usr/src/sys/fs/specfs/spec_vnops.c:420 #7 0xc02009c8 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:123 #8 0xc02fa3cd in ffs_sync (mp=0xc414e200, waitfor=2, cred=0xc150ae80, td=0xc03d3e20) at vnode_if.h:612 #9 0xc028578b in sync (td=0xc03d3e20, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:138 #10 0xc0235b0c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280 #11 0xc0236143 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 #12 0xc0255837 in witness_lock (lock=0xc03db920, flags=8, file=0xc0392734 /usr/src/sys/kern/sys_generic.c, line=1191) at /usr/src/sys/kern/subr_witness.c:552 #13 0xc022d1f3 in _mtx_lock_flags (m=0xc03d82a0, opts=0, file=0xc03db920 \202=]'9]'9, line=1191) ---Type return to continue, or q return to quit--- at /usr/src/sys/kern/kern_mutex.c:337 #14 0xc025955f in selwakeup (sip=0xc03d82a0) at /usr/src/sys/kern/sys_generic.c:1191 #15 0xc02638be in ptcwakeup (tp=0xc414f030, flag=-1069696736) at /usr/src/sys/kern/tty_pty.c:327 #16 0xc0263887 in ptsstart (tp=0x0) at /usr/src/sys/kern/tty_pty.c:316 #17 0xc025f8bb in ttstart (tp=0x0) at /usr/src/sys/kern/tty.c:1459 #18 0xc0261604 in tputchar (c=-1005260800, tp=0xc414f030) at /usr/src/sys/kern/tty.c:2579 #19 0xc0250f1b in putchar (c=10, arg=0xc044e74c) at /usr/src/sys/kern/subr_prf.c:349 #20 0xc025123d in kvprintf (fmt=0xc414f000 , func=0xc0250eb0 putchar, arg=0xc044e74c, radix=10, ap=0xc044e76c ) at /usr/src/sys/kern/subr_prf.c:528 #21 0xc0250e07 in printf (fmt=0x0) at /usr/src/sys/kern/subr_prf.c:305 #22 0xc03522b2 in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:863 (kgdb) up 12 #12 0xc0255837 in witness_lock (lock=0xc03db920, flags=8, file=0xc0392734 /usr/src/sys/kern/sys_generic.c, line=1191) at /usr/src/sys/kern/subr_witness.c:552 552 panic(blockable sleep lock (%s) %s %s:%d, (kgdb) l 547 * Since spin locks include a critical section, this check 548 * impliclty enforces a lock order of all sleep locks before 549 * all spin locks. 550 */ 551 if (td-td_critnest != 0 (flags LOP_TRYLOCK) == 0) 552 panic(blockable sleep lock (%s) %s %s:%d, 553 class-lc_name, lock-lo_name, file, line); 554 lock_list = td-td_sleeplocks; 555 } else 556 lock_list = PCPU_PTR(spinlocks); (kgdb) quit golf# exit exit Script done on Thu Mar 6 18:42:33 2003
Re: SSH (TCP?) lag
On 17:21+0200, Feb 23, 2003, Giorgos Keramidas wrote: On 2003-02-22 22:49, Andre Guibert de Bruet [EMAIL PROTECTED] wrote: I find myself waiting up to two seconds for data to flush to the terminal on a 28 line 'ls -l'. net.inet.tcp.delayed_ack doesn't appear to cause this behavior on 4.7-stable. Did we inadvertently break the 100ms clause with the latest TCP patches? Jonathan Lemon has already posted a message that says he knows there is a bug in the recent changes. He's looking into it. To make things work without delays you should (temporarily) enable net.inet.tcp.delayed_ack=0. This bug is already fixed: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3988161+0+archive/2003/cvs-all/20030223.cvs-all -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic on shutdown of X server.
On 11:50-0800, Feb 23, 2003, walt wrote: This problem started about Feb 19 and continues thru today's updates. Everything seems to work great until I shut down the X server at which time I get a fatal 'page fault while in kernel mode.' I have two -CURRENT machines at the moment and only the one with the nVidia driver (and kernel module) has the page fault problem. I know the nVidia people don't support the driver for -CURRENT but it has been working perfectly until now, so something important in the kernel changed about four days ago, apparently. Anyone else seeing this? Yes. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1225336+0+archive/2003/cvs-all/20030223.cvs-all -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: network stalls in top of the tree current
On 19:48+0200, Feb 22, 2003, Giorgos Keramidas wrote: I've been seeing huge delays and a major drop of performance in network performace in recent -current kernels. I was wondering, has anyone else seen something similar or should I just look at other things? A typical example of what I see the past 2-3 days is: [EMAIL PROTECTED]:40]/home/giorgos$ fetchmail -a -K fetchmail: No mail for keramida at igloo.linux.gr 22 messages for keramida at diogenis.ceid.upatras.gr (85546 octets). reading message [EMAIL PROTECTED]:1 of 22 (8987 octets) flushed reading message [EMAIL PROTECTED]:2 of 22 (3230 octets) ... flushed reading message [EMAIL PROTECTED]:3 of 22 (2615 octets) .fetchmail: timeout after 60 seconds. fetchmail: socket error while fetching from diogenis.ceid.upatras.gr fetchmail: Query status=2 (SOCKET) It used to take just 2-3 seconds to get a message with fetchmail, and now it times out so often that sometimes I have to use scp to copy my mail at home. Similarly long delays often happen with scp too. /me too. Try sysctl net.inet.tcp.delayed_ack=0. I suspect that commit: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=678980+0+current/cvs-src -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IPFW/socheckuid() patch
On 03:18+0200, Feb 18, 2003, Giorgos Keramidas wrote:
On 2003-02-18 00:02, Wiktor Niesiobedzki [EMAIL PROTECTED] wrote:
On Mon, Feb 17, 2003 at 11:47:32PM +0100, Wiktor Niesiobedzki wrote:
There is an obvious mistake in patch (or change in ip_fw2.c should
be considered).
[...]
--- sys/kern/uipc_socket.c 2003/02/17 22:37:58 1.144
+++ sys/kern/uipc_socket.c 2003/02/17 22:56:41
@@ -1846,8 +1846,8 @@
{
if (so == NULL)
- return (EPERM);
- if (so-so_cred-cr_uid == uid)
return (0);
- return (EPERM);
+ if (so-so_cred-cr_uid == uid)
+ return (1);
+ return (0);
}
The rest of the uipc_socket.c functions (socreate, sobind, solisten,
soclose, soabort, ...) that return int's use zero as a success
value, and return errno based errors otherwise. I'm thinking if the
error is ipfw2's fault and should be fixed there. It seems slightly
preferable to me.
Yes, I have already fixed this bug in rev.1.26 src/sys/netinet/ip_fw2.c
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [5.0-RELEASE] uid option in ipfw
On 03:50+0300, Jan 28, 2003, Oleg Baranov wrote:
It looks like firewall in 5.0-RELEASE doesn't respect uid option.
I migrated from 4.7 where the following lines worked fine:
allow tcp from me to any uid 500 setup
allow udp from me to any uid 500 keep-state
I couldn't get these lines working on 5.0 (packets don't match these rules).
it's a little strange thing - the following lines DO work, but they
match for ANY user on the system:
allow tcp from me to any uid 0 setup
allow udp from me to any uid 0 keep-state
also the counters are updated in a mysterious way...
it's a very confusing thing for me. can anyone help to solve the problem
plz?
Please try a patch below.
Index: sys/netinet/ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.25
diff -u -r1.25 ip_fw2.c
--- sys/netinet/ip_fw2.c21 Jan 2003 08:56:03 - 1.25
+++ sys/netinet/ip_fw2.c29 Jan 2003 11:50:32 -
@@ -1515,7 +1515,7 @@
#endif
if (cmd-opcode == O_UID) {
match =
- socheckuid(pcb-inp_socket,
+ !socheckuid(pcb-inp_socket,
(uid_t)((ipfw_insn_u32 *)cmd)-d[0]);
} else {
match = groupmember(
%%%
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
[PATCH]: newfs(8) FS_OPTSPACE vs FS_OPTTIME bug
Hello,
newfs(8) incorrectly claims that FS_OPTTIME is unavailable when
minfree is less than MINFREE. MINFREE is defined in ufs/ffs/fs.h:
#define MINFREE 8
But relevant code in ufs/ffs/ffs_alloc.c uses hardcoded value:
288 if (fs-fs_minfree = 5 ||
289 fs-fs_cstotal.cs_nffree
290 (off_t)fs-fs_dsize * fs-fs_minfree / (2 * 100))
291 break;
292 log(LOG_NOTICE, %s: optimization changed from SPACE to TIME\n,
tunefs(8) metions 5% too.
Any objections to a diff below?
Index: newfs/newfs.c
===
RCS file: /home/ncvs/src/sbin/newfs/newfs.c,v
retrieving revision 1.66
diff -u -r1.66 newfs.c
--- newfs/newfs.c 30 Nov 2002 18:28:26 - 1.66
+++ newfs/newfs.c 23 Jan 2003 10:26:45 -
@@ -327,9 +327,9 @@
maxcontig = MAX(1, MAXPHYS / bsize);
if (density == 0)
density = NFPI * fsize;
- if (minfree MINFREE opt != FS_OPTSPACE) {
+ if (minfree = 5 opt != FS_OPTSPACE) {
fprintf(stderr, Warning: changing optimization to space );
- fprintf(stderr, because minfree is less than %d%%\n, MINFREE);
+ fprintf(stderr, because minfree is less than %d%%\n, 5);
opt = FS_OPTSPACE;
}
if (maxbpg == 0)
%%%
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: IPFW2 skipto + logging
On 00:35+0100, Jan 15, 2003, Wiktor Niesiobedzki wrote: On Tue, Jan 14, 2003 at 01:18:02PM +0300, Maxim Konovalov wrote: On 17:20+0100, Jan 13, 2003, Wiktor Niesiobedzki wrote: It seems, that now logging with skipto is working correctly (I get expected results), but funny thing, when there is no log rule, the skipto command won't work. Yes, my bad. Corrected patch: Now it's working correctly. Thanks. Fixed in rev. 1.24 sys/netinet/ip_fw2.c, thanks for the report. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED], +7 (095) 796979 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Dummynet messages
On 23:43+0100, Jan 19, 2003, Wiktor Niesiobedzki wrote:
Hi,
sys/netinet/ip_dummynet.c:
975: if (q-avg = fs-max_th) { /* average queue = max threshold */
(...)
984:} else {
985:q-count = -1;
986: printf(- drop);
987:return 1 ;
989:}
is quite meaningless. Shouldn't be it at least DEB(printf(- drop)? Or
better drop - max_th exceeded?
Just a small proposition, I was quite confused, when I saw this message.
Fixed in rev. 1.61 sys/netinet/ip_dummynet.c, thanks.
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED], +7 (095) 796979
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic trying to chroot(2) on a script(?)
[ CC: jhb and rwatson ]
On 23:52+0900, Oct 3, 2002, [EMAIL PROTECTED] wrote:
Hello.
Last night I was trying to start an anonymous ftp server on my
-current box for my local network. I made a mistake in vipw:
ftp:*:4:4:Unprivileged user:/sbin/nologin:/home/mp3
i.e., wrote a path to a script where directory is needed, and directory
where path to shell is needed. Without noticing, I started ftpd in
standalone mode, and logged in as user ftp, when the box panicked:
# /usr/libexec/ftpd -AD
# ftp -4 localhost
On 4.7-RC1 box, this just spewed an error message in /var/log/messages
and didn't panic, and man 2 chroot doesn't state it should.
If there's something other than the backtrace(attached), let me know it.
Yep, chroot() panics -current. AFAIU the problem is in rev. 1.268
sys/kern/vfs_syscalls.c, we call vrele(9) in NDFREE(9) on already
vrele-ed vnode (change_dir() cares about that). Here is my patch but
I need someone with more experience in this area.
Index: vfs_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.305
diff -u -r1.305 vfs_syscalls.c
--- vfs_syscalls.c 13 Jan 2003 00:28:55 - 1.305
+++ vfs_syscalls.c 20 Jan 2003 15:51:52 -
@@ -542,8 +542,10 @@
if ((error = change_dir(nd, td)) != 0)
goto error;
#ifdef MAC
- if ((error = mac_check_vnode_chroot(td-td_ucred, nd.ni_vp)))
+ if ((error = mac_check_vnode_chroot(td-td_ucred, nd.ni_vp))) {
+ vput(vp);
goto error;
+ }
#endif
FILEDESC_LOCK(fdp);
if (chroot_allow_open_directories == 0 ||
@@ -567,7 +569,7 @@
FILEDESC_UNLOCK(fdp);
error:
mtx_unlock(Giant);
- NDFREE(nd, 0);
+ NDFREE(nd, NDF_ONLY_PNBUF);
return (error);
}
%%%
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED], +7 (095) 7969079
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: IPFW2 skipto + logging
On 17:20+0100, Jan 13, 2003, Wiktor Niesiobedzki wrote: On Sun, Jan 12, 2003 at 04:52:53PM +0300, Maxim Konovalov wrote: Hello, Please try a next patch: It seems, that now logging with skipto is working correctly (I get expected results), but funny thing, when there is no log rule, the skipto command won't work. Yes, my bad. Corrected patch: Index: sys/netinet/ip_fw2.c === RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.22 diff -u -r1.22 ip_fw2.c --- sys/netinet/ip_fw2.c27 Dec 2002 17:43:25 - 1.22 +++ sys/netinet/ip_fw2.c14 Jan 2003 10:16:30 - @@ -1180,6 +1180,8 @@ /* look for action, in case it is a skipto */ cmd = ACTION_PTR(me); + if (cmd-opcode == O_LOG) + cmd += F_LEN(cmd); if ( cmd-opcode == O_SKIPTO ) for (rule = me-next; rule ; rule = rule-next) if (rule-rulenum = cmd-arg1) %%% -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serious issues with kqueue on sockets on CURRENT.
On 03:51-0800, Jan 12, 2003, Kelly Yancey wrote: [...] I'm sorry, I'm afraid I am not familiar with the issue being discussed. Is there a PR I can reference for more information? Exactly what events aren't being received? Being as the logic for when to return a kevent as of uipc_socket.c:1.136 is exactly the same as before (just the data value in the kevent is different), I can't see how any events could *not* be returned that weren't returned before. But then again, without knowing the symptoms you are seeing, I can't say for sure. Look at the top of the thread: Juli's complain: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=889789+0+archive/2003/freebsd-current/20030112.freebsd-current Tim's test program and a patch: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=889789+0+archive/2003/freebsd-current/20030112.freebsd-current -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IPFW2 skipto + logging
Hello, On 17:34+0100, Nov 10, 2002, Wiktor Niesiobedzki wrote: Hi, Rule of the format: ipfw add 100 skipto 400 log logamount 0 ip from 192.168.0.0/24 to 192.168.0.0/24 Will give this strange result: Nov 10 17:01:05 portal kernel: ipfw: 100 SkipTo 400 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 310 Pipe 2 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 320 Pipe 2 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 340 Pipe 3 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 340 Pipe 4 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 360 Pipe 4 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 380 Pipe 4 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 800 Accept TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 So, clearly saying - will not work, the rule: ipfw add 100 skipto 400 ip from 192.168.0.0/24 to 192.168.0.0/24 is working correctly. Is there any problems with ACTION_PTR macro? Please try a next patch: Index: sys/netinet/ip_fw2.c === RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.22 diff -u -r1.22 ip_fw2.c --- sys/netinet/ip_fw2.c27 Dec 2002 17:43:25 - 1.22 +++ sys/netinet/ip_fw2.c12 Jan 2003 13:49:48 - @@ -1180,6 +1180,7 @@ /* look for action, in case it is a skipto */ cmd = ACTION_PTR(me); + cmd += F_LEN(cmd); if ( cmd-opcode == O_SKIPTO ) for (rule = me-next; rule ; rule = rule-next) if (rule-rulenum = cmd-arg1) %%% -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is this a tool problem or source?
On 17:45+0400, Oct 14, 2002, David O'Brien wrote: On Sun, Oct 13, 2002 at 10:31:13PM -0700, Julian Elischer wrote: ref3# make linking kernel.debug ld: target elf32-i386-freebsd not found *** Error code 1 Stop in /usr/src/sys/i386/compile/REF3. ref3# Please explain exactly what you are trying to do. All I can guess is you are trying to build a RELENG_3 kernel (based on kernel config name), on a 5-CURRENT box (based on the mailing list you sent this to). I've got the same error yesterday building CURRENT on the month old CURRENT. make buildworld installworld _before_ make buildkernel solved the problem. -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pw_scan() allows empty login names
Hello, Is it intentional? Here is a patch: Index: lib/libc/gen/pw_scan.c === RCS file: /home/ncvs/src/lib/libc/gen/pw_scan.c,v retrieving revision 1.23 diff -u -r1.23 pw_scan.c --- lib/libc/gen/pw_scan.c 2 Oct 2002 07:02:46 - 1.23 +++ lib/libc/gen/pw_scan.c 11 Oct 2002 11:36:19 - @@ -78,6 +78,8 @@ pw-pw_fields = 0; if (!(pw-pw_name = strsep(bp, :))) /* login */ goto fmt; + if (pw-pw_name[0] == '\0') + goto fmt; root = !strcmp(pw-pw_name, root); if (pw-pw_name[0] (pw-pw_name[0] != '+' || pw-pw_name[1] == '\0')) pw-pw_fields |= _PWF_NAME; %%% -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:maxim;macomnet.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usermount with devfs
On 21:08+0400, Oct 3, 2002, Lars Eggert wrote: Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Lars Eggert writes: [root@nik: /etc] rm /dev/acd0c [root@nik: /etc] umask 0007 ln -s /dev/acd0c /dev/acd0 ln: /dev/acd0: File exists Which is really a strange error, since /dev/acd0c is gone: Nothing which the kernel has created in /dev/ is really gone when you rm(1) it, it merely gets hidden. Think of it as the kernel has priority in selecting names. Now, if you had rm /dev/null you could recreate it with mknod /dev/null c 0 0 (the c 0 0 arguments have to be there, but are ignored). I guess it's a flaw that you can't recreate the symlink in a similar fashion. So there is no more usermount under -current with devfs? Or is there another way to have the symlinks be created with the different permissions (since devfs rules don't seem to apply to them)? See no problems with my -current: [maxim@miss maxim]$ uname -a FreeBSD miss 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sun Aug 11 13:35:56 MSD 2002 maxim@miss:/vol0/obj/usr/src/sys/MISS i386 [maxim@miss maxim]$ id uid=1001(maxim) gid=20(staff) groups=20(staff), 0(wheel), 5(operator), 68(dialer), 69(network) [maxim@miss maxim]$ ls -ld /cdrom drwxr-xr-x 2 maxim wheel 512 13 ÓÅÎ 2001 /cdrom [maxim@miss maxim]$ ls -l /dev/acd0c lrwxr-xr-x 1 root wheel 5 2 ÏËÔ 01:13 /dev/acd0c - acd0 [maxim@miss maxim]$ mount /dev/ad0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad0s1e on /usr (ufs, local, soft-updates) /dev/ad0s1f on /vol0 (ufs, local, noatime, soft-updates) procfs on /proc (procfs, local) [maxim@miss maxim]$ ls -l /sbin/mount_cd9660 -r-xr-xr-x 1 root wheel 74004 14 ÓÅÎ 22:10 /sbin/mount_cd9660 [maxim@miss maxim]$ /sbin/mount_cd9660 /dev/acd0c /cdrom [maxim@miss maxim]$ mount | grep cdrom /dev/acd0c on /cdrom (cd9660, local, nodev, nosuid, read-only, mounted by maxim) -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NIS broken by pw_scan.c commits?
Hello,
On 07:43+0400, Oct 2, 2002, Robert Watson wrote:
It looks like someone has broken support for NIS in /etc/master.passwd by
tightening the formatting rules for the file incorrectly. Whereas a
perfectly valid NIS password file used to work a month or so ago, it now
generates a syntax error:
www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
+:
cboss# pwd_mkdb -p /etc/master.passwd
pwd_mkdb: uid is incorrect
pwd_mkdb: at line #22
pwd_mkdb: /etc/master.passwd: Inappropriate file type or format
(line 22 is the +::... line)
If whoever did this could please *undo* the change, it would appreciate
it: breaking services like NIS is not a good idea. I won't have a chance
to investigate more tonight, but I strongly suspect pw_scan.c:1.22 by
Maxim. It could be another commit; I'll try backing this out tomorrow
Yes, it is my bug, fixed in rev. 1.23, sorry for inconvenience.
By the way, there is still an issue: pw_scan() allows an empty GID in
non-NIS entries too. Any objections to a patch below?
Index: libc/gen/pw_scan.c
===
RCS file: /home/ncvs/src/lib/libc/gen/pw_scan.c,v
retrieving revision 1.22
diff -u -r1.22 pw_scan.c
--- libc/gen/pw_scan.c 25 Sep 2002 08:49:19 - 1.22
+++ libc/gen/pw_scan.c 2 Oct 2002 07:04:42 -
@@ -124,6 +124,13 @@
goto fmt;
if (p[0])
pw-pw_fields |= _PWF_GID;
+ else {
+ if (pw-pw_name[0] != '+' pw-pw_name[0] != '-') {
+ if (flags _PWSCAN_WARN)
+ warnx(no gid for user %s, pw-pw_name);
+ return (0);
+ }
+ }
id = strtoul(p, ep, 10);
if (errno == ERANGE) {
if (flags _PWSCAN_WARN)
%%%
[ Note: this bug is not my :-) ]
morning and see if things start working. Requiring a valid integer value
is bogus in the case where the field is filled in from NIS.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
--
Maxim Konovalov, [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Trouble Building CURRENT on STABLE, cpp seg. fault
Works for me: Kernel build for GENERIC completed on Sun Sep 22 07:43:35 MSD 2002 $ uname -a FreeBSD golf.macomnet.net 4.6-20020805-MACOMNET-STABLE FreeBSD 4.6-20020805-MACOMNET-STABLE #19: Fri Sep 20 17:09:52 MSD 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GOLF i386. -- Maxim Konovalov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stage 2 build of contrib/file breaks upgrade from 4.7PRE toCURRENT.
On 07:10+0400, Sep 18, 2002, David O'Brien wrote: On Tue, Sep 17, 2002 at 11:39:50AM +0200, Robert Suetterlin wrote: Hello! I currently upgraded my 4.4 to 4.7-PRE and now tried to get from there to -CURRENT. Unfortunately ``make buildworld'' fails during stage 2 when building ``usr.bin/file'': usr/src/usr.bin/file/../../contrib/file/file.h:45: stdint.h: No such file or directory I need more context. Please email a complete build log. Trying to build -CURRENT on -STABLE: $ uname -a FreeBSD golf.macomnet.net 4.6-20020805-MACOMNET-STABLE FreeBSD 4.6-20020805-MACOMNET-STABLE #18: Tue Sep 17 12:09:42 MSD 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GOLF i386 $ cd build/current/src/usr.bin/file $ make cc -O -pipe -DMAGIC='/usr/share/misc/magic' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H -I/home/maxim/build/current/src/usr.bin/file -I/home/maxim/build/current/src/usr.bin/file/../../contrib/file-c /home/maxim/build/current/src/usr.bin/file/../../contrib/file/file.c In file included from /home/maxim/build/current/src/usr.bin/file/../../contrib/file/file.c:28: /home/maxim/build/current/src/usr.bin/file/../../contrib/file/file.h:45: stdint.h: No such file or directory *** Error code 1 Stop in /home/maxim/build/current/src/usr.bin/file. $ -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
vsnprintf(3) memory leak patch, misc/26044 and bin/36175
Hello -current,
Our vsnprintf(3) has a memory leak, take a look at
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/36175 and
http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/26044
for details.
Any objections against a patch below (from OpenBSD)?
Index: libc/stdio/vsnprintf.c
===
RCS file: /home/ncvs/src/lib/libc/stdio/vsnprintf.c,v
retrieving revision 1.20
diff -u -r1.20 vsnprintf.c
--- libc/stdio/vsnprintf.c 6 Sep 2002 11:23:56 - 1.20
+++ libc/stdio/vsnprintf.c 12 Sep 2002 07:55:53 -
@@ -50,6 +50,7 @@
{
size_t on;
int ret;
+ char dummy;
FILE f;
struct __sFILEX ext;
@@ -58,6 +59,11 @@
n--;
if (n INT_MAX)
n = INT_MAX;
+ /* Stdio internals do not deal correctly with zero length buffer */
+ if (n == 0) {
+str = dummy;
+n = 1;
+ }
f._file = -1;
f._flags = __SWR | __SSTR;
f._bf._base = f._p = (unsigned char *)str;
%%%
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: vsnprintf(3) memory leak patch, misc/26044 and bin/36175
On 18:46+0400, Sep 12, 2002, Kris Kennaway wrote:
On Thu, Sep 12, 2002 at 12:02:45PM +0400, Maxim Konovalov wrote:
+ /* Stdio internals do not deal correctly with zero length buffer */
I thought ache fixed a lot of these; are you sure the situation still
applies to -current?
Yes, it still leaks. Testcase from misc/26044:
main() {for(;;) vsnprintf(0, 0, yadda yadda!\n);};
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: buildworld breakage
On 12:10-0700, Aug 15, 2002, Mike Makonnen wrote: I don't know if I'm the only one having this problem, but I haven't been able to make a complete buildworld for a couple of days now. The last time I upgraded was arround August 5. I have been getting a signal 11 consistently in the same spot. === secure/usr.sbin/sshd === share === share/colldef colldef -I /daemon/build/current/src/share/colldef -o bg_BG.CP1251.out /daemon/build/current/src/share/colldef/bg_BG.CP1251.src *** Signal 11 ache has fixed that. -- Maxim Konovalov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: updated to August 5th kernel broke mozilla
On 14:06-0700, Aug 9, 2002, Brooks Davis wrote: I recently updated my laptop's kernel to an August 5th version from an July 23rd one and mozilla started getting connection refused from everything. Lynx worked fine as did other network services like cvsup and ssh. Upgrading mozilla from 1.0_rc? to the latest version corrected the problem, but so did booting with an old kernel so something weird is going on. Try sysctl net.inet6.ip6.v6only=0 or rebuild mozilla. -- Maxim Konovalov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sendfile(2) is broken (Was: ftpd problem: Input/output error)
On 03:37+0700, Aug 12, 2002, Semen A. Ustimenko wrote: Hi! On Sun, 11 Aug 2002, Robert Watson wrote: On Sun, 11 Aug 2002, Maxim Konovalov wrote: This is sendfile(2) mis-behaviour arised after rev.1.109 sys/kern/uipc_syscalls.c but I think the real problem in vn_rdwr(), sys/kern/vfs_vnops.c. Here is my patch but I really need somebody with vfs clue. I CC'ed Robert Watson as an author of sendfile(2) modification and our vfs expert. Semen Ustimenko [EMAIL PROTECTED] ran into a similar problem, but his fix was to teach sendfile() to pass in a non-NULL resid and handle the failure mode better. I suspect this fix is more correct since it will both handle the failure mode and the data delivered, and probably is required for other consumers of vn_rdwr(). He was going to run the patch past dg, and then commit it assuming dg approved it, so hopefully it will go into the tree in the next day or so. David reviewed the patch and I have committed it few minutes ago. Looks like a hack BDE is speaking about: passing a storage for residue but never check it. Anyway I don't understand why VOP_READ in vn_rdwr() returns a residue in uio.uio_resid when all data trasferred actually? -- Maxim Konovalov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sendfile(2) is broken (Was: ftpd problem: Input/output error)
Hello,
On 14:43+0100, Aug 10, 2002, Gavin Atkinson wrote:
Hi,
For a few months now I have been seeing the following problems with the
ftpd in current. When transferring a large file, ftpd seems to
consistantly fail after almost all of the file hass been transferred. The
example transcript below shows all but 4096 bytes of a file being
transferred before stopping. This also happens across networks, with
4-stable ftp clients - i am confident that it is the ftp server in
current.
gavin@epsilon:/home/gavin grep ^ftp /etc/inetd.conf
ftp stream tcp nowait root/usr/libexec/ftpd ftpd -ll
gavin@epsilon:/home/gavin ls -l foo
-rw--- 1 gavin users 31969280 Aug 4 18:19 foo
gavin@epsilon:/home/gavin ftp localhost
Trying ::1...
ftp: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
220 epsilon.ury.york.ac.uk FTP server (Version 6.00LS) ready.
Name (localhost:gavin):
331 Password required for gavin.
Password:
230 User gavin logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp lcd test
Local directory now /usr/home/gavin/test
ftp get foo
local: foo remote: foo
229 Entering Extended Passive Mode (|||49152|)
150 Opening BINARY mode data connection for 'foo' (31969280 bytes).
99% | | 31216 KB3.25 MB/s00:09
426 Data connection: Input/output error.
31965184 bytes received in 00:09 (3.25 MB/s)
ftp
gavin@epsilon:/home/gavin ls -l test/foo
-rw-r--r-- 1 gavin users 31965184 Aug 4 18:19 test/foo
epsilon# tail -3
/var/log/ftp.log
Aug 10 14:28:28 epsilon ftpd[345]: connection from localhost (127.0.0.1)
Aug 10 14:29:03 epsilon ftpd[345]: FTP LOGIN FROM localhost as gavin
Aug 10 14:29:36 epsilon ftpd[345]: get /usr/home/gavin/foo = 31965184 bytes
As can be seen, the file is 31969280 bytes in size, but ftpd only sends
31963184 bytes. The log file reads the smaller size.
World and kernel are from source supped midnight GMT 10th August. I can
help debug this or provide an account for someone else to look at this
problem.
This is sendfile(2) mis-behaviour arised after rev.1.109
sys/kern/uipc_syscalls.c but I think the real problem in vn_rdwr(),
sys/kern/vfs_vnops.c. Here is my patch but I really need somebody with
vfs clue. I CC'ed Robert Watson as an author of sendfile(2)
modification and our vfs expert.
Index: sys/kern/vfs_vnops.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_vnops.c,v
retrieving revision 1.159
diff -u -r1.159 vfs_vnops.c
--- sys/kern/vfs_vnops.c8 Aug 2002 12:45:30 - 1.159
+++ sys/kern/vfs_vnops.c11 Aug 2002 10:19:47 -
@@ -401,7 +401,7 @@
if (aresid)
*aresid = auio.uio_resid;
else
- if (auio.uio_resid error == 0)
+ if (auio.uio_resid error != 0)
error = EIO;
if ((ioflg IO_NODELOCKED) == 0) {
if (rw == UIO_WRITE)
%%%
With this patch sendfile(2) and ftpd(8) work as expected but I cannot
believe vn_rdwr() has been broken since 1994.
As a temporal solution you can revert rev. 1.109 uipc_syscalls.c,
recompile and reinstall your kernel.
--
Maxim Konovalov, [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Removing INET6 does stop the crashes.
[...] Let's get this patch committed then. :) Already done, sys/netinet/tcp_usrreq.c rev. 1.79 -- Maxim Konovalov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dd if=/dev/acd0c of=/tmp/fbsd.raw gives dd: /dev/acd0c: Invalidargument
On 11:57-0700, May 6, 2002, Edwin Culp wrote: Please disregard my previous email. I had forgotten the error message. I can't get dd if=/dev/acd0c of=/tmp/fbsd.raw to work. I get: dd: /dev/acd0c: Invalid argument dd if=/dev/acd0c of=/tmp/fbsd.raw bs=2048 works for me. I'm sure that I've done this before although it has been a long time. It was probably before the devfs. I don't have a current or release box to test on. Does anyone know why or what I am doing wrong? Thanks, ed - http://insourcery.com - Mergence of Business and Technology a Griffin Plaza Partners, LLC Company To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message - http://insourcery.com - Mergence of Business and Technology a Griffin Plaza Partners, LLC Company To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: savecore.c broken now, breaks world
On 15:17+0200, May 5, 2002, Szilveszter Adam wrote:
Hello,
src/sbin/savecore.c has been broken today, with the commit of rev 1.59
by Bill Fenner.
It appears that a new magic value, KERNELDUMPMAGIC_CLEARED, has been
introduced but its value never #define-d in (probably)
src/sys/sys/kerneldump.h. This way, the program does not compile.
There is only so much one can deduce from the code, it is the author who
should know what was intended here.
This breaks the world.
This patch solves the problem:
Index: sys_sys/kerneldump.h
===
RCS file: /home/ncvs/src/sys/sys/kerneldump.h,v
retrieving revision 1.3
diff -u -r1.3 kerneldump.h
--- sys_sys/kerneldump.h3 Apr 2002 07:24:10 - 1.3
+++ sys_sys/kerneldump.h5 May 2002 13:49:04 -
@@ -60,6 +60,7 @@
struct kerneldumpheader {
charmagic[20];
#defineKERNELDUMPMAGIC FreeBSD Kernel Dump
+#defineKERNELDUMPMAGIC_CLEARED FreeBSD Cleard Dump
chararchitecture[12];
uint32_tversion;
#defineKERNELDUMPVERSION 1
%%%
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: your mail
On 18:24+0300, May 3, 2002, Radoslav Vasilev wrote: unsuscribe freebsd-current use [EMAIL PROTECTED] instead of [EMAIL PROTECTED] Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: newsyslog(8) should wait(2) for children
Terry, On 23:11-0700, May 1, 2002, Terry Lambert wrote: Maxim Konovalov wrote: [ ... patch to wait for children, but do nothing with the result ... ] Yes. Why not just set the signal handler for the child process termination to ignore, so that the child processes do not become zombied in the first place, so it's not ever necessary to do a useless loop whose only purpose is to reap zombies without examining their exit status? There are two purposes: a) reap zombies, b) exit after all children have done only. In the current implementation newsyslog(8) forks and execs gzip(1) or bzip2(1) and exits immediately. If a log file(s) is big enough the compress_log() process(es) will work after newsyslog's death and there is no clear way to get know when it(they)'s done. OpenBSD: a) SIGCHLD signal handler: waitpid(2) loop, do not examine status, b) the same waitpid(2) loop before exit(2). I do not think we need a) at all. newsyslog forks/execs all his children and enters into the reap loop like SIGCHLD signal handler does. NetBSD: a) waitpid(2) for a child right after fork/exec, b) examine status and print an exit code. As you see, NetBSD newsyslog serializes fork/exec and there is only one gzip process at the same moment. We can take this way but IMHO it will be a POLA violation. -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: newsyslog(8) should wait(2) for children
On 01:04-0700, May 2, 2002, Terry Lambert wrote: Maxim Konovalov wrote: [ ... patch to wait for children, but do nothing with the result ... ] Why not just set the signal handler for the child process termination to ignore, so that the child processes do not become zombied in the first place, so it's not ever necessary to do a useless loop whose only purpose is to reap zombies without examining their exit status? There are two purposes: a) reap zombies, b) exit after all children have done only. In the current implementation newsyslog(8) forks and execs gzip(1) or bzip2(1) and exits immediately. If a log file(s) is big enough the compress_log() process(es) will work after newsyslog's death and there is no clear way to get know when it(they)'s done. Your (a) is statisfied with either approach. I don't understand why you think (b) is a requirement. Let's imagine: # /usr/sbin/newsyslog ./make_something_with_compressed_log newsyslog exited but there are several compress_log() processes are still running and make_something_with_compressed_log will get a half-compressed logs. OpenBSD: a) SIGCHLD signal handler: waitpid(2) loop, do not examine status, b) the same waitpid(2) loop before exit(2). I do not think we need a) at all. newsyslog forks/execs all his children and enters into the reap loop like SIGCHLD signal handler does. The point of this is to not reap until you have to; the default case will be no reaping necessary, so you are adding overhead unnecessarily by atttempting to reap non-existant children. As you see, OpenBSD has (a) *and* (b). NetBSD: a) waitpid(2) for a child right after fork/exec, b) examine status and print an exit code. As you see, NetBSD newsyslog serializes fork/exec and there is only one gzip process at the same moment. We can take this way but IMHO it will be a POLA violation. [ NetBSD approach arguments ] There are arguments for both approaches, but if you want to wait for the operation to complete, the OpenBSD approach is better than a reap-loop. Again, OpenBSD has a reap loop. [...] -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
newsyslog(8) should wait(2) for children
Does anyone object to the next patch:
Index: newsyslog.c
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.c,v
retrieving revision 1.41
diff -u -r1.41 newsyslog.c
--- newsyslog.c 10 Apr 2002 10:38:44 - 1.41
+++ newsyslog.c 1 May 2002 19:15:40 -
@@ -38,6 +38,7 @@
#include ctype.h
#include err.h
+#include errno.h
#include fcntl.h
#include grp.h
#include paths.h
@@ -135,6 +136,12 @@
p = p-next;
free((char *) q);
q = p;
+ }
+ for (;;) {
+ if (wait(NULL) 0) {
+ if (errno != EINTR)
+ break;
+ }
}
return (0);
}
%%%
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic:bremfree with today's current and linux-netscape
As Adrian Penisoara already reported
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=19645+0+current/freebsd-current
there is panic in -current. I believe it is related to the next
commit:
nectar 2002/04/18 17:45:29 PDT
Modified files:
sys/kern kern_descrip.c kern_exec.c
sys/sys filedesc.h
Log:
When exec'ing a set[ug]id program, make sure that the stdio file descriptors
(0, 1, 2) are allocated by opening /dev/null for any which are not already
open.
Reviewed by:alfred, phk
MFC after: 2 days
Here is my workaround but I am not sure is it correct or not. Seems
falloc() takes care about locking itself.
Index: src/sys/kern/kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.138
diff -u -r1.138 kern_descrip.c
--- src/sys/kern/kern_descrip.c 20 Apr 2002 12:02:52 - 1.138
+++ src/sys/kern/kern_descrip.c 21 Apr 2002 17:04:58 -
@@ -1528,9 +1528,7 @@
if (fdp-fd_ofiles[i] != NULL)
continue;
if (devnull 0) {
- FILEDESC_LOCK(fdp);
error = falloc(td, fp, fd);
- FILEDESC_UNLOCK(fdp);
if (error != 0)
break;
NDINIT(nd, LOOKUP, FOLLOW, UIO_SYSSPACE, /dev/null,
%%%
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: is 'device ether' mandatory now?
Hello Luigi, On 05:20-0800, Mar 24, 2002, Luigi Rizzo wrote: Do you have a suggestion for an #ifdef /#endif to remove the problem you mention ? Frankly speaking, I have no solution atm. But IMHO we should fix LINT and warn our -stable users at least. Something like that: Index: sys/i386/conf/LINT === RCS file: /home/ncvs/src/sys/i386/conf/Attic/LINT,v retrieving revision 1.749.2.106 diff -u -r1.749.2.106 LINT --- sys/i386/conf/LINT 2002/03/11 01:23:05 1.749.2.106 +++ sys/i386/conf/LINT 2002/03/26 08:06:56 @@ -468,8 +468,8 @@ # Network interfaces: # The `loop' pseudo-device is MANDATORY when networking is enabled. # The `ether' pseudo-device provides generic code to handle -# Ethernets; it is MANDATORY when a Ethernet device driver is -# configured or token-ring is enabled. +# Ethernets; it is MANDATORY when the Internet communication +# protocols family (INET) is configured. # The 'fddi' pseudo-device provides generic code to support FDDI. # The `arcnet' pseudo-device provides generic code to support Arcnet. # The `sppp' pseudo-device serves a similar role for certain types Index: NOTES === RCS file: /home/ncvs/src/sys/i386/conf/NOTES,v retrieving revision 1.1011 diff -u -r1.1011 NOTES --- NOTES 2002/03/23 18:39:54 1.1011 +++ NOTES 2002/03/26 08:08:48 @@ -521,8 +521,8 @@ # Network interfaces: # The `loop' device is MANDATORY when networking is enabled. # The `ether' device provides generic code to handle -# Ethernets; it is MANDATORY when a Ethernet device driver is -# configured or token-ring is enabled. +# Ethernets; it is MANDATORY when the Internet communication +# protocols family (INET) is configured. # The `fddi' device provides generic code to support FDDI. # The `arcnet' device provides generic code to support Arcnet. # The `sppp' device serves a similar role for certain types %%% I believe handbook is affected too. cheers luigi On Sat, Mar 23, 2002 at 08:50:19PM +0300, Maxim Konovalov wrote: Hello, After this commit 'device ether' is mandatory if ever there is no any ethernet or token-ring devices. | luigi 2002/02/18 14:50:13 PST | | Modified files: |sys/net if.c | Log: | When the local link address is changed, send out gratuitous ARPs | to notify other nodes about the address change. Otherwise, they | might try and keep using the old address until their arp table | entry times out and the address is refreshed. | | Maybe this ought to be done for INET6 addresses as well but i have | no idea how to do it. It should be pretty straightforward though. | | MFC-after: 10 days | | Revision ChangesPath | 1.128 +11 -0 src/sys/net/if.c -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
is 'device ether' mandatory now?
Hello, After this commit 'device ether' is mandatory if ever there is no any ethernet or token-ring devices. | luigi 2002/02/18 14:50:13 PST | | Modified files: |sys/net if.c | Log: | When the local link address is changed, send out gratuitous ARPs | to notify other nodes about the address change. Otherwise, they | might try and keep using the old address until their arp table | entry times out and the address is refreshed. | | Maybe this ought to be done for INET6 addresses as well but i have | no idea how to do it. It should be pretty straightforward though. | | MFC-after: 10 days | | Revision ChangesPath | 1.128 +11 -0 src/sys/net/if.c -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel build breaks in bktr_i2c.c
just built a -current GENERIC with a patch below. Do not know is it correct or not though. Index: Makefile === RCS file: /home/ncvs/src/sys/modules/bktr/bktr/Makefile,v retrieving revision 1.3 diff -u -r1.3 Makefile --- Makefile23 Mar 2002 15:48:32 - 1.3 +++ Makefile23 Mar 2002 22:00:45 - @@ -6,7 +6,7 @@ KMOD= bktr SRCS= bktr_core.c bktr_os.c bktr_audio.c bktr_tuner.c bktr_card.c \ - bktr.h opt_devfs.h opt_bktr.h smbus.h bus_if.h device_if.h \ + bktr.h opt_devfs.h opt_bktr.h bus_if.h device_if.h \ pci_if.h vnode_if.h CLEANFILES= bktr.h %%% -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel build breakage on if_wi
On 22:14+0300, Mar 22, 2002, Vladimir B. Grebenschikov wrote: Fresh (todays) -current not builds on current machine: vbook#/sys/i386/compile/VBOOK 142_ make kernel-depend make kernel rm -f .olddep if [ -f .depend ]; then mv .depend .olddep; fi make _kernel-depend if [ -f .olddep ]; then mv .olddep .depend; fi rm -f .newdep make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | xargs env MKDEP_CPP=cc -E CC=cc mkdep -a -f .newdep -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -O3 -mpentiumpro -mpreferred-stack-boundary=2 make -V SFILES -V SYSTEM_SFILES | xargs env MKDEP_CPP=cc -E mkdep -a -f .newdep -x assembler-with-cpp -DLOCORE -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -O3 -mpentiumpro -mpreferred-stack-boundary=2 rm -f .depend mv .newdep .depend cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -O3 -mpentiumpro -mpreferred-stack-boundary=2 -Werror ../../../dev/wi/if_wi.c cc1: warnings being treated as errors ../../../dev/wi/if_wi.c: In function `wi_seek': ../../../dev/wi/if_wi.c:1250: warning: `status' might be used uninitialized in this function *** Error code 1 Did you read 20020225: Warnings are now errors in the kernel. Unless you are a developer, you should add -DNO_WERROR to your make line. in UPDATING? Stop in /usr/local/src/sys/i386/compile/VBOOK. vbook#/sys/i386/compile/VBOOK 143_ kernel config attached Any ideas ? -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On 02:00-0800, Mar 13, 2002, Kris Kennaway wrote: On Wed, Mar 13, 2002 at 08:15:30AM +0300, Maxim Konovalov wrote: I can replace my eaccess(2) patch for test(1) by a workaround I am planning to commit to -stable. Is it desirable solution? Well, this won't solve my problem since I'm trying to run the 5.x Maybe I was unclear but it will solve your problem. My proposal is: - back test/test.c rev. 1.43 out, - commit a workaround I sent in previous latter to -current. binary. I'm not immediately familiar with the issues surrounding eaccess(). Kris -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On 03:38-0800, Mar 13, 2002, Kris Kennaway wrote: On Wed, Mar 13, 2002 at 01:24:36PM +0300, Maxim Konovalov wrote: On 02:00-0800, Mar 13, 2002, Kris Kennaway wrote: On Wed, Mar 13, 2002 at 08:15:30AM +0300, Maxim Konovalov wrote: I can replace my eaccess(2) patch for test(1) by a workaround I am planning to commit to -stable. Is it desirable solution? Well, this won't solve my problem since I'm trying to run the 5.x Maybe I was unclear but it will solve your problem. My proposal is: - back test/test.c rev. 1.43 out, - commit a workaround I sent in previous latter to -current. Well, eaccess(2) is presumably a good idea, so it would be better to just MFC it :) Agree. Kris -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
Kris, Robert,
On 20:11-0800, Mar 12, 2002, Kris Kennaway wrote:
On Tue, Mar 12, 2002 at 10:59:07PM -0500, Robert Watson wrote:
On Tue, 12 Mar 2002, Kris Kennaway wrote:
Subject says it all, really; this is the cause of part of my problems in
getting 5.x packages built on the bento cluster, because it seems that
/bin/sh has come to depend on this syscall. Executing a 5.x /bin/sh on
a 4.x system causes a SIGSYS if it hits this code (e.g. test -x
/some/binary)
Can this syscall be MFCed soon?
Today it's eaccess(), tomorrow it's KSE system calls, ACL system calls,
MAC system calls, 64-bit stat and ino_t, dev_t, devfs, ...
Certainly we can MFC eaccess(), but that's not going to make the problem
go away. Fundamentally our model is backward compatibility, not forward
compatibility. We need to build 5.0 packages on 5.0.
Well, I've backed out the eaccess() use in /bin/test for now. I agree
with you that ultimately this model will fail, but the longer we can
delay it the easier my life will be trying to manage the cluster and
get packages built.
I can replace my eaccess(2) patch for test(1) by a workaround I am
planning to commit to -stable. Is it desirable solution?
Index: test.c
===
RCS file: /home/ncvs/src/bin/test/test.c,v
retrieving revision 1.29.2.4
diff -u -r1.29.2.4 test.c
--- test.c 6 Feb 2002 17:37:13 - 1.29.2.4
+++ test.c 24 Feb 2002 21:26:38 -
@@ -195,6 +195,8 @@
int argc;
char **argv;
{
+ gid_t gid, egid;
+ uid_t uid, euid;
int i, res;
char*p;
char**nargv;
@@ -224,14 +226,20 @@
}
/* XXX work around the absence of an eaccess(2) syscall */
- (void)setgid(getegid());
- (void)setuid(geteuid());
+ gid = getgid();
+ egid = getegid();
+ uid = getuid();
+ euid = geteuid();
+ (void)setregid(egid, gid);
+ (void)setreuid(euid, uid);
t_wp = argv[1];
res = !oexpr(t_lex(*t_wp));
if (*t_wp != NULL *++t_wp != NULL)
syntax(*t_wp, unexpected operator);
+ (void)setregid(gid, egid);
+ (void)setreuid(uid, euid);
return res;
}
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On 21:33-0800, Mar 12, 2002, Julian Elischer wrote: any change that has to be added to 4.x tomake it run on 5.x is the wrong answer. 4.x binaries should all run on 5.x (unless something was accidentally committed to 4.x that should be backed out.) any change for allowing 4.x binaries to run on 5.x should be done on the 5.x side of things, (unless I've misunderstood the problem here) I believe you have :-) Kris cannot run /bin/sh from 5.x on 4.x because of absence eaccess(2) in 4.x. regards, Julian On Wed, 13 Mar 2002, Maxim Konovalov wrote: Kris, Robert, On 20:11-0800, Mar 12, 2002, Kris Kennaway wrote: On Tue, Mar 12, 2002 at 10:59:07PM -0500, Robert Watson wrote: On Tue, 12 Mar 2002, Kris Kennaway wrote: Subject says it all, really; this is the cause of part of my problems in getting 5.x packages built on the bento cluster, because it seems that /bin/sh has come to depend on this syscall. Executing a 5.x /bin/sh on a 4.x system causes a SIGSYS if it hits this code (e.g. test -x /some/binary) Can this syscall be MFCed soon? Today it's eaccess(), tomorrow it's KSE system calls, ACL system calls, MAC system calls, 64-bit stat and ino_t, dev_t, devfs, ... Certainly we can MFC eaccess(), but that's not going to make the problem go away. Fundamentally our model is backward compatibility, not forward compatibility. We need to build 5.0 packages on 5.0. Well, I've backed out the eaccess() use in /bin/test for now. I agree with you that ultimately this model will fail, but the longer we can delay it the easier my life will be trying to manage the cluster and get packages built. I can replace my eaccess(2) patch for test(1) by a workaround I am planning to commit to -stable. Is it desirable solution? Index: test.c === RCS file: /home/ncvs/src/bin/test/test.c,v retrieving revision 1.29.2.4 [...] -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: procfs.o undef'd refs
On 11:18+0100, Feb 12, 2002, Christoph Kukulies wrote: I dared to cvsup -current yesterday to my notebook computer (had 4.4 R installed before that) and now being half there (did a buildworld already successfully) kernel compilation fails with a lot of undefined references in procfs.o: pfs_create_file pfs_create_link pfs_mount pfs_init pfs_unint pfs_unmount pfs_root pfs_statfs Am I missing a new config option? more /usr/src/UPDATING, 20011203 -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker Task: ccdinit stack usage.
Hello,
On 12:23+0100, Dec 30, 2001, Poul-Henning Kamp wrote:
sys/dev/ccd/ccd.c:ccdinit() has a couple of very large items on
the stack.
Rewrite ccdinit() to allocate them with MALLOC(9) instead.
tmppath is a rather big one but I can't find the second item. What
about this patch:
Index: ccd.c
===
RCS file: /home/ncvs/src/sys/dev/ccd/ccd.c,v
retrieving revision 1.95
diff -u -r1.95 ccd.c
--- ccd.c 17 Nov 2001 00:46:08 - 1.95
+++ ccd.c 30 Dec 2001 12:15:25 -
@@ -394,7 +394,7 @@
int maxsecsize;
struct partinfo dpart;
struct ccdgeom *ccg = cs-sc_geom;
- char tmppath[MAXPATHLEN];
+ char *tmppath = NULL;
int error = 0;
#ifdef DEBUG
@@ -414,6 +414,7 @@
*/
maxsecsize = 0;
minsize = 0;
+ MALLOC(tmppath, char *, MAXPATHLEN, M_DEVBUF, M_WAITOK);
for (ix = 0; ix cs-sc_nccdisks; ix++) {
vp = cs-sc_vpp[ix];
ci = cs-sc_cinfo[ix];
@@ -422,7 +423,7 @@
/*
* Copy in the pathname of the component.
*/
- bzero(tmppath, sizeof(tmppath));/* sanity */
+ bzero(tmppath, MAXPATHLEN); /* sanity */
if ((error = copyinstr(cpaths[ix], tmppath,
MAXPATHLEN, ci-ci_pathlen)) != 0) {
#ifdef DEBUG
@@ -487,6 +488,8 @@
ci-ci_size = size;
cs-sc_size += size;
}
+
+ FREE(tmppath, M_DEVBUF);
/*
* Don't allow the interleave to be smaller than
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ctm and current q
On Fri, 18 Feb 2000, Bruce Evans wrote: On Thu, 17 Feb 2000, Maxim Konovalov wrote: Hello, I've got a 4.0-2210-CURRENT snapshot and decided to try CTM. I've [...] ps works quite right. It seems like kernel and world are not sync. Where did i make a mistake(s)? The boot blocks must be updated if you are starting from an old (2.2?) version of FreeBSD. I've just got a installed 4.0-2210-CURRENT snapshot and decided to try CTM :-) Bruce Maxim Konovalov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ctm and current q
Hello, I've got a 4.0-2210-CURRENT snapshot and decided to try CTM. I've - read handbook chapter about using CTM - subscribed to ctm-cur, ctm-port, ctm-announce - downloaded all src-cur.42* deltas from ftp://ftp.freebsd.org/pub/FreeBSD/development/CTM/src-cur/ - rm -rf /usr/src/* - applied deltas and got a new src tree - read /usr/src/UPDATING - built and installed world - mergemastered /etc - cd /dev sh MAKEDEV all - built and installed kernel - rebooted When I try: # pstat pstat: undefined symbol: _numvnodes # top top: nlist failed # ps works quite right. It seems like kernel and world are not sync. Where did i make a mistake(s)? Thank you for your help, Maxim Konovalov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
