Re: bin/174073: [patch] style(9) fixes for xargs(1)
The following reply was made to PR bin/174073; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Garrett Cooper yaneg...@gmail.com, ead...@freebsd.org Cc: bug-follo...@freebsd.org Subject: Re: bin/174073: [patch] style(9) fixes for xargs(1) Date: Thu, 16 May 2013 14:43:37 +0300 On 2012-12-03, Garrett Cooper wrote: The attached patch consists of style(9) fixes for xargs(1) that I submitted to mckay@ and he acked, but weren't committed. Partially(?) committed in r250431. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good
The following reply was made to PR kern/122838; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Alexander Leidinger alexan...@leidinger.net Cc: a...@freebsd.org, bug-follo...@freebsd.org, amd...@amdmi3.ru Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good Date: Fri, 10 May 2013 23:33:05 +0300 Hi, On 2013-05-10, Alexander Leidinger wrote: I've go hit by this behavior of the devfs rule matching and I fully agree to the rationale of Andriy. Can we please agree on going ahead with this? I believe that Andriy is working to get the change committed. See the thread big change to devfs rules path matching on -current. If this is not the case, let me know and I will take care of the patch. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/171865: [geom] g_wither_washer() keeping a core busy
The following reply was made to PR kern/171865; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Fabian Keil f...@fabiankeil.de Cc: bug-follo...@freebsd.org, lu...@freebsd.org Subject: Re: kern/171865: [geom] g_wither_washer() keeping a core busy Date: Tue, 25 Sep 2012 17:06:54 +0300 On 2012-09-22, Fabian Keil wrote: I recently found a way to reproduce the problem without using ZFS or writing to the device. How-To-Repeat: geli onetime /dev/md0 geom sched insert -a rr /dev/md0.eli geli detach /dev/md0.eli.sched. It seems that if you insert a sched geom and do geli detach on it, the geli geom can't be destroyed. After your commands md0.eli still exists: # geli list Geom name: md0.eli Providers: 1. Name: md0.eli Mediasize: 10485760 (10M) Sectorsize: 512 Mode: r0w0e0 # geli detach md0.eli geli: No such device: md0.eli. I didn't find a way to destroy it. I suspect a geom_sched bug. luigi@ cc'd. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/169947: System crash via ioctl() on mdctl.
The following reply was made to PR kern/169947; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Filip Palian filip.pal...@pjwstk.edu.pl Cc: bug-follo...@freebsd.org Subject: Re: misc/169947: System crash via ioctl() on mdctl. Date: Wed, 18 Jul 2012 16:33:39 +0300 On 2012-07-17, Filip Palian wrote: User who has read permission on /dev/mdctl is able to crash the system (also within the jail if only provided by devfs(.rules)) via ioctl() handler in /usr/src/sys/dev/md/md.c:1082. The crash occures in function swap_release_by_cred() (swap_pager.c:285) called in vm_object_deallocate() (md.c:1119). Some detailed information included below. Patch attached with submission follows: #include stdio.h #include stdlib.h I couldn't reproduce the problem with your test program on current or stable/9: $ ./mdtest.orig say goodnight... ioctl(MDIOCATTACH) failed: Invalid argument no +r no fun I tried to modify the test program with following changes but still no success. %%% --- mdtest.c 2012-07-18 16:13:34.0 +0300 +++ mdtest.c 2012-07-18 16:17:05.0 +0300 @@ -21,7 +21,8 @@ s.md_version = MDIOVERSION; // s.md_type = MD_SWAP; s.md_type = MD_PRELOAD; - s.md_options = MD_CLUSTER | MD_AUTOUNIT | MD_COMPRESS; + s.md_base = -1; + s.md_options = MD_AUTOUNIT; // typedef long long = int64 = off_t //s.md_mediasize = 4096*1000; %%% $ ./mdtest say goodnight... no +r no fun A new md device is successfully created. Are you sure that you attached the correct test program and you didn't have local patches applied to your kernel? -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/165873: tar(1) manpage advertises --uid and --gid which seem to be not implemented
On 2012-03-10, Mark wrote: The options are implemented on 8- and 9-stable and current. I'm not sure how exactly this happened - it looks like libarchive and bsdtar were moved to contrib/ right after 9 was released, and some upstream updates were merged in the process. I guess it was an oversight, but there's nothing to do since the options are there now. Thanks for this information. Does this also apply to bin/161749? -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/162407: [rctl] [panic] rctl crashes kernel with a page fault (gdb: corrupt stack?)
On 2012-03-09, Moritz Wilhelmy wrote: crashes have gone away after disabling rctl. I'm a bit anxious to retry for now, because I currently don't want any unnecessary downtime. Have you previously been able to reproduce it? How do you suspect r226092 to fix the issue? r226092 is supposed to fix a rctl related problem with fork() and your latter backtrace involves the fork() system call. I haven't personally tried to reproduce the problem. Also, I wanted to upgrade sooner or later; in case I give it a shot, what branch do I need? 9_STABLE? Right. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/165811: kill(1) doesn't terminate a process group with the command kill -- -117 (from man kill)
On 2012-03-08, Salimane Adjao Moustapha wrote: with /bin/kill I still have this problem. Fb-bj# ps axjf | grep resque myuser 17995 1 17993 179930 I ??0:00.11 /usr/local/bin/php -f scripts/resque/resque.php low myuser 17996 17995 17993 179930 S ??0:42.24 /usr/local/bin/php -f scripts/resque/resque.php low myuser 17997 17995 17993 179930 S ??0:41.67 /usr/local/bin/php -f scripts/resque/resque.php low myuser 18026 1 18024 180240 I ??0:00.16 /usr/local/bin/php -f scripts/resque/resque.php high myuser 18031 18026 18024 180240 S ??0:02.50 /usr/local/bin/php -f scripts/resque/resque.php high myuser 18032 18026 18024 180240 S ??0:02.81 /usr/local/bin/php -f scripts/resque/resque.php high root62234 62209 62233 622042 S+ 00:00.00 grep resque Fb-bj# /bin/kill -- -17995 kill: -17995: No such process i still can't kill the process 17995 and its children 17996, 17997 PGID is the fourth column in your listing. Thus you should use /bin/kill -- -17993. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: conf/163668: fstab 'failok' option has no effect on missing hard drive
The following reply was made to PR conf/163668; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Oleg Baranov o...@csa.ru Cc: bug-follo...@freebsd.org Subject: Re: conf/163668: fstab 'failok' option has no effect on missing hard drive Date: Mon, 2 Jan 2012 17:45:41 +0200 Hi, On 2011-12-28, Oleg Baranov wrote: System drops to Single mode on boot in case special device is missing even corresponding filesystem is marked as 'failok' in /etc/fstab. This is a bug in mount(8). The mountfs() function calls several functions which may cause mount(8) to exit with error status. This breaks the failok functionality. I tried to remove most exit points in the following patch. Changing checkpath() isn't trivial because also file system specific mount commands use the function. http://people.freebsd.org/~jh/patches/mount-failok.diff Please report back if you are able to test the patch. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: conf/163432: Environment variables set from /etc/login.conf do not have surrounding quote characters removed
The following reply was made to PR conf/163432; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Mike Clarke jmc-fbs...@milibyte.co.uk Cc: bug-follo...@freebsd.org Subject: Re: conf/163432: Environment variables set from /etc/login.conf do not have surrounding quote characters removed Date: Mon, 19 Dec 2011 12:34:45 +0200 On 2011-12-18, Mike Clarke wrote: On 8.1-RELEASE the quotes get stripped off. curlew:/home/mike% grep setenv /etc/login.conf :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES,EDITOR=vi,EXINIT=set ai ic sw=3,PAGER=less,EJECT=/dev/acd0:\ curlew:/home/mike% env | grep EXINIT EXINIT=set ai ic sw=3 I still get EXINIT=set ai ic sw=3 on 8.1-RELEASE. Are you sure that your database is up to date (i.e. you have run cap_mkdb /etc/login.conf)? -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: conf/163432: Environment variables set from /etc/login.conf do not have surrounding quote characters removed
The following reply was made to PR conf/163432; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Mike Clarke jmc-fbs...@milibyte.co.uk Cc: bug-follo...@freebsd.org Subject: Re: conf/163432: Environment variables set from /etc/login.conf do not have surrounding quote characters removed Date: Sun, 18 Dec 2011 20:18:37 +0200 Hi, On 2011-12-18, Mike Clarke wrote: If /etc/login.conf is used to set an environment variable and the value is enclosed between quote characters the quotes are not stripped off when setting the variable. This problem only arises with FreeBSD 9, the quotes were removed with earlier versions. :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES,EXINIT=set ai ic sw=3:\ Can you clarify the earlier versions? I get this on 8.2-RELEASE: $ env . . EXINIT=set ai ic sw=3 -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Petr Salinger petr.salin...@seznam.cz, Poul-Henning Kamp p...@phk.freebsd.dk Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= d...@des.no, bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 16 Dec 2011 10:19:35 +0200 On 2011-12-13, Petr Salinger wrote: Will be this regression corrected for 9.0 release ? AFAIK it's too late to get such patch approved for 9.0. Previously (in stable-8), the sbuf_finish() cleared the overflow error. It used to return void, and as noted previously, only 21 of 133 calls check return value of sbuf_finish(), i.e. only 1/6 have been migrated to new API semantics. What about restore clearing of error during sbuf_finish() for stable-9 and do the right thing in HEAD ? If nobody can suggest a better alternative, I am inclined to say that I'd like to see the change reverted until someone volunteers to fix callers. I don't say that r222004 is incorrect but the fact is that sbuf_finish() didn't return an error for a long time (almost 10 years) and when the API was changed it looks like API consumers weren't changed along. I am willing to help but currently I have no idea how to fix pseudofs with the new API semantics. I don't like the patch posted because it allocates an excessively large buffer on every read. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Poul-Henning Kamp p...@phk.freebsd.dk Cc: Petr Salinger petr.salin...@seznam.cz, bug-follo...@freebsd.org, d...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Tue, 13 Dec 2011 17:13:36 +0200 On 2011-12-11, Poul-Henning Kamp wrote: Only 21 of 133 calls I grepped through the FreeBSD source tree did check the return value [of sbuf_finish()] How many of them checked sbuf_error() instead ? I grepped 8 sbuf_error() calls. I'd say that 2 of them were used correctly instead of checking the return value of sbuf_finish(). And seriously: how long would it take to fix 112 calls ? Majority of them seem to be autoextend buffers which are OK in kernel space. Some of the remaining are easy to fix but then there are harder ones like the pseudofs one. It looks like that some applications call sbuf_finish() from functions which are not expected to fail. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Poul-Henning Kamp p...@phk.freebsd.dk Cc: Petr Salinger petr.salin...@seznam.cz, bug-follo...@freebsd.org, d...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Sun, 11 Dec 2011 12:26:08 +0200 On 2011-12-10, Poul-Henning Kamp wrote: I agree with Dag-Erling that it is at least mistake to not have separate sbuf(9) and sbuf(3) pages, possibly also a mistake that they share the implementation. One problem is the different malloc() semantics. The kernel version uses M_WAITOK allocations while user space malloc(3) can fail. Obviously sbuf_finish() should return the error status, and its return value SHALL be checked by applications, before the contents of the sbuf can be used. Only 21 of 133 calls I grepped through the FreeBSD source tree did check the return value. In practice SBUF_AUTOEXTEND buffers can't fail when the kernel version is used (due to M_WAITOK malloc). The argument relating to this bug is about what sbuf_len() and sbuf_data() should return for an error'ed sbuf. Given that the mandatory error-check of the sbuf_finish() call should prevent these two functions from being called in the first place, I'm tempted to say that their return values should be documented as undefined, and implemented to cause the maxium amount of havoc (ie: -1 and NULL). -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= d...@des.no Cc: Poul-Henning Kamp p...@phk.freebsd.dk, Petr Salinger petr.salin...@seznam.cz, bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Sat, 10 Dec 2011 19:35:43 +0200 On 2011-12-10, Dag-Erling Smørgrav wrote: Jaakko Heinonen j...@freebsd.org writes: Could you give an example about such state? Isn't the length first initialized to zero and then increased only when byte(s) has been successfully appended to the buffer? sbuf_len() has worked for unfinished buffers since r71724. A fixed-length sbuf may overflow intentionally (as in pseudofs) or unintentionally; a dynamic sbuf may also overflow due to a memory allocation failure. The first two cases are expected, but the third is not, and I am not sure the sbuf should be considered valid in such a case. Thanks, I see your point. However, currently after a memory allocation failure, finishing the buffer is allowed and sbuf_data() will return the buffer. According to phk@ sbuf_finish() should finish any buffer. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= d...@des.no Cc: Poul-Henning Kamp p...@phk.freebsd.dk, Petr Salinger petr.salin...@seznam.cz, bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 9 Dec 2011 14:36:17 +0200 On 2011-12-09, Dag-Erling Smørgrav wrote: Could we just remove the error check from sbuf_len()? (patch below) I have Cc'd more people. Why? As I wrote existing code depends on sbuf_len() to return the actual length regardless of the error status after sbuf_finish(). I am not willing to through all code using sbufs to check where it causes problems. phk@ asserts that r222004 is correct. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= d...@des.no Cc: Poul-Henning Kamp p...@phk.freebsd.dk, Petr Salinger petr.salin...@seznam.cz, bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 9 Dec 2011 16:35:30 +0200 On 2011-12-09, Dag-Erling Smørgrav wrote: Jaakko Heinonen j...@freebsd.org writes: As I wrote existing code depends on sbuf_len() to return the actual length regardless of the error status after sbuf_finish(). I am not willing to through all code using sbufs to check where it causes problems. phk@ asserts that r222004 is correct. What if the sbuf is in a state where asking for its length is meaningless? Could you give an example about such state? Isn't the length first initialized to zero and then increased only when byte(s) has been successfully appended to the buffer? sbuf_len() has worked for unfinished buffers since r71724. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Poul-Henning Kamp p...@phk.freebsd.dk Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= d...@des.no, Petr Salinger petr.salin...@seznam.cz, bug-follo...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Fri, 9 Dec 2011 18:23:18 +0200 On 2011-12-09, Poul-Henning Kamp wrote: As I wrote existing code depends on sbuf_len() to return the actual length regardless of the error status after sbuf_finish(). What do you mean by actual length ? The length it would have if there hadn't been errors ? No, I mean returning s-s_len instead of -1. s_len is the length of the string without the terminating NUL. s_len doesn't include the bytes that didn't fit to the buffer. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Poul-Henning Kamp p...@phk.freebsd.dk Cc: Petr Salinger petr.salin...@seznam.cz, bug-follo...@freebsd.org, d...@freebsd.org, m...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Wed, 7 Dec 2011 18:08:34 +0200 Hi, On 2011-12-06, Jaakko Heinonen wrote: On 2011-12-06, Poul-Henning Kamp wrote: Shouldn't sbuf_finish() then check s-s_error before appending the trailing '\0' and setting the SBUF_FINISHED flag? The problem in question wasn't caught earlier because sbuf_finish() happily finishes the buffer even if it has an error. I belive the code is written so that there is always reserved space for the final '\0' sbuf_finish() should finish _any_ sbuf, and return zero only if the finished buffer is fully OK. Anyway I find it inconsistent that you can successfully call sbuf_finish() and sbuf_data() but not for example sbuf_len() on an errored buffer. After looking at some code using sbufs I think that the sbuf(9) API change done in r222004 is problematic. Lots of code doesn't check the return value of sbuf_finish() but they expect sbuf_len() to return the actual length regardless of the error status after calling sbuf_finish(). Since r222004 sbuf_len() may return -1 after sbuf_finish(). In user space also SBUF_AUTOEXTEND buffers are affected because malloc(3) can fail and cause the error status to be set. Could we just remove the error check from sbuf_len()? (patch below) I have Cc'd more people. sbuf(9) manual page wrongly claims that sbuf_data() will return NULL if the buffer has overflowed. %%% Index: sys/kern/subr_sbuf.c === --- sys/kern/subr_sbuf.c (revision 228153) +++ sys/kern/subr_sbuf.c (working copy) @@ -725,8 +725,6 @@ sbuf_len(struct sbuf *s) KASSERT(s-s_drain_func == NULL, (%s makes no sense on sbuf %p with drain, __func__, s)); - if (s-s_error != 0) - return (-1); return (s-s_len); } Index: share/man/man9/sbuf.9 === --- share/man/man9/sbuf.9 (revision 228153) +++ share/man/man9/sbuf.9 (working copy) @@ -25,7 +25,7 @@ .\ .\ $FreeBSD$ .\ -.Dd January 25, 2011 +.Dd December 7, 2011 .Dt SBUF 9 .Os .Sh NAME @@ -462,14 +462,6 @@ function returns a non-zero value if the drain error, and zero otherwise. .Pp The -.Fn sbuf_data -and -.Fn sbuf_len -functions return -.Dv NULL -and \-1, respectively, if the buffer overflowed. -.Pp -The .Fn sbuf_copyin function returns \-1 if copying string from userland failed, and number of bytes %%% -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Poul-Henning Kamp p...@phk.freebsd.dk Cc: Petr Salinger petr.salin...@seznam.cz, bug-follo...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Tue, 6 Dec 2011 15:21:36 +0200 On 2011-12-06, Poul-Henning Kamp wrote: Shouldn't sbuf_finish() then check s-s_error before appending the trailing '\0' and setting the SBUF_FINISHED flag? The problem in question wasn't caught earlier because sbuf_finish() happily finishes the buffer even if it has an error. I belive the code is written so that there is always reserved space for the final '\0' sbuf_finish() should finish _any_ sbuf, and return zero only if the finished buffer is fully OK. Anyway I find it inconsistent that you can successfully call sbuf_finish() and sbuf_data() but not for example sbuf_len() on an errored buffer. Thus you can fix the problem with the subtle change below. %%% Index: sys/fs/pseudofs/pseudofs_vnops.c === --- sys/fs/pseudofs/pseudofs_vnops.c (revision 228153) +++ sys/fs/pseudofs/pseudofs_vnops.c (working copy) @@ -651,7 +651,7 @@ pfs_read(struct vop_read_args *va) } sbuf_finish(sb); - error = uiomove_frombuf(sbuf_data(sb), sbuf_len(sb), uio); + error = uiomove_frombuf(sbuf_data(sb), strlen(sbuf_data(sb)), uio); sbuf_delete(sb); ret: vn_lock(vn, locked | LK_RETRY); %%% -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Petr Salinger petr.salin...@seznam.cz Cc: bug-follo...@freebsd.org, p...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Mon, 5 Dec 2011 16:49:47 +0200 Hi, On 2011-12-05, Petr Salinger wrote: It is not possible to read in chunks from linprocfs and procfs. It is a regression against stable-8. I suspect it is due to changes of sbuf implementation between 8 and 9. Yes, r222004 changed sbuf_finish() to not clear s-s_error which causes the regression. I am not sure if we should blame r222004 or the pseudofs code. I have Cc'd the committer of r222004. Some files are rather big (over 4KB) and it is really standard to read them in blocks. How-To-Repeat: dd if=$FILE bs=1, with FILE any file in procfs or linprocfs The result is empty output. Tried with FILE /proc/version from linprocfs and /proc/curproc/map from procfs. For more details see Debian GNU/kFreeBSD bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650667 -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Poul-Henning Kamp p...@phk.freebsd.dk Cc: Petr Salinger petr.salin...@seznam.cz, bug-follo...@freebsd.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs. Date: Mon, 5 Dec 2011 23:42:02 +0200 On 2011-12-05, Poul-Henning Kamp wrote: Yes, r222004 changed sbuf_finish() to not clear s-s_error which causes the regression. I am not sure if we should blame r222004 or the pseudofs code. The sbuf code is correct. Sbufs were designed to have latching error semantics and any errors should not be cleared by sbuf_finish() for exactly that reason. Shouldn't sbuf_finish() then check s-s_error before appending the trailing '\0' and setting the SBUF_FINISHED flag? The problem in question wasn't caught earlier because sbuf_finish() happily finishes the buffer even if it has an error. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/160964: Kernel panic with OSS [9.0-BETA2]
The following reply was made to PR misc/160964; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Jonathan Calmels jbjcalm...@gmail.com Cc: bug-follo...@freebsd.org Subject: Re: misc/160964: Kernel panic with OSS [9.0-BETA2] Date: Sun, 25 Sep 2011 11:02:00 +0300 On 2011-09-24, Jonathan Calmels wrote: However I forgot I had an USB headset plugged in. Therefore the kernel loaded implicitly sound drivers attached to this device (in particular sound.ko), before OSS starts. Unplug the USB headset solved the problem but one question remains :) how can I disable this behaviour so that OSS manage my headset as well ? See /etc/devd/usb.conf and search for uaudio. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
The following reply was made to PR bin/160979; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Joe Barbish fb...@a1poweruser.com Cc: bug-follo...@freebsd.org Subject: Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0 Date: Sun, 25 Sep 2011 13:00:43 +0300 On 2011-09-24, Joe Barbish wrote: It seems that in 9.0 the cd/dvd/drive is now given a dev name of cd0 where in all previous releases it was acd0. Tried to use the system burncd command in 9.0 and got this error msg burncd: ioctl(CDRIOCGETBLOCKSIZE): Inappropriate ioctl for device Tested using burncd -f acd0 and burncd -f cd0. In both cases got the same error message. Looks to me like the burncd command needs to be fixed to work in 9.0. burncd(8) supports only acd(4) driver. In 9.0 the default is the new CAM-based ATA stack which uses cd(4) (UPDATING entry 20110424). It's unlikely that a support for cd(4) will be added to burncd(8). I think this should be mentioned in release notes. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/160964: Kernel panic with OSS [9.0-BETA2]
The following reply was made to PR misc/160964; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Jonathan Calmels jbjcalm...@gmail.com Cc: bug-follo...@freebsd.org Subject: Re: misc/160964: Kernel panic with OSS [9.0-BETA2] Date: Sat, 24 Sep 2011 09:41:37 +0300 Hi, On 2011-09-24, Jonathan Calmels wrote: 118Starting slim. 118Starting Open Sound System panic: make_dev_credv: bad si_name (error=17, si_name=sndstat) The panic happens because /dev/sndstat already exists. There are two things why this happens on 9.0: 1) Sound support has been enabled by default on amd64 and i386 (r222980). 2) make_dev(9) can detect attempts to create duplicate devices on 9.0. I don't really consider this a FreeBSD bug. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/158121: The security run output contains log entries which are a year old.
The following reply was made to PR misc/158121; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Jesper Wallin jes...@ifconfig.se Cc: bug-follo...@freebsd.org Subject: Re: misc/158121: The security run output contains log entries which are a year old. Date: Wed, 22 Jun 2011 07:32:25 +0300 On 2011-06-21, Jesper Wallin wrote: The log entries in /var/log/auth.log does not contain the year. Because of this, if you rarely logon to the machine (or for some other reason doesn't manage to reach the 100K limit before newsyslog rotate your auth.log) the security run output will send you a year old logs. :-) Fix: Make newsyslog rotate auth.log regardless of it's size or make somehow make sshd/syslogd log the year as well. You can configure interval based rotation in /etc/newsyslog.conf . See the description for when field in newsyslog.conf(5) manual page. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/157718: input data trigers a core dump from calendar
The following reply was made to PR bin/157718; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Julian H. Stacey j...@berklix.com Cc: bug-follo...@freebsd.org, ed...@freebsd.org Subject: Re: bin/157718: input data trigers a core dump from calendar Date: Thu, 9 Jun 2011 18:39:43 +0300 On 2011-06-09, Julian H. Stacey wrote: I have verified calendar core dumps on these: 8.2-RELEASE amd64 8.2-RELEASE i386 not on these: 4.11-RELEASE i386 6.2-RELEASE i386 6.3-RELEASE i386 7.3-RELEASE i386 So there's a regression error to be found corrected. It looks like this regression is caused by r212035: r212035 | edwin | 2010-08-31 01:45:32 +0300 (Tue, 31 Aug 2010) | 3 lines For calendars which don't match the solar-based Gregorian calendar, be able to specify a year string in an entry. edwin@ Cc'd. Description: calendar should not core dump How-To-Repeat: fetch http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/calendar/core_dump_input.ignore fetch http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/calendar/core_dump_shell.ignore ./core_dump_shell.ignore calendar -f core_dump_input.ignore (BTW ignore my strange names ending .ignore, its just a prefix to stop my customise shell installing things in my src/ -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/155873: calendar recurring date not working
The following reply was made to PR bin/155873; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: ed...@freebsd.org Cc: Ivana Belgers iv...@giga.giga.nl, bug-follo...@freebsd.org Subject: Re: bin/155873: calendar recurring date not working Date: Mon, 6 Jun 2011 20:22:10 +0300 Hi, On 2011-03-22, Ivana Belgers wrote: Until recently the following line in the .calendar file delivered the expected result: sat+3Every third saturday of each month This worked in 8.1-STABLE installed on 2 august 2010. Now, since we upgraded to 8.2-STABLE on march 25, this does not work anymore, but generates the following message: % calendar Unprocessed: --- date: |Sat+3| flags: 10a - dayofweek modifierindex variable modifierindex: |+3| dayofweek: |Sat| (6) Ignored: Sat+3 Every third saturday of each month Seems that the behavior changed in r205821: r205821 | edwin | 2010-03-29 09:49:20 +0300 (Mon, 29 Mar 2010) | 12 lines Long awaited update to the calendar system: - Repeating events which span multiple years (because of -A, -B or just the three days before the end of the year). - Support for lunar events (full moon, new moon) and solar events (equinox and solstice, chinese new year). Because of this, the options -U (UTC offset) and -l (longitude) are available to compensate if reality doesn't match the calculated values. MFC after: 1 month edwin: Could you comment on this? -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/157499: fetch confused me with it's error message
The following reply was made to PR misc/157499; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Konstantin konstantin.ma...@kaspersky.com Cc: bug-follo...@freebsd.org Subject: Re: misc/157499: fetch confused me with it's error message Date: Thu, 2 Jun 2011 11:01:22 +0300 On 2011-06-01, Konstantin wrote: I have found out some strange error handling in /usr/bin/fetch. Here it is: # fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz: Syntax error, command unrecognized USER anonymous 331 Please specify the password. PASS r...@h-ksn-hkg-fe-2.kaspersky-labs.com 500 OOPS: cannot change directory:/home/ftp fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz: Syntax error, command unrecognized This is how reply code 500 is defined in RFC 959: 500Syntax error, command unrecognized. This may include errors such as command line too long. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/155925: CD tray is not locked even if using /dev/adc0.
The following reply was made to PR misc/155925; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Alexander Best arun...@freebsd.org, k...@suri.co.jp Cc: bug-follo...@freebsd.org Subject: Re: misc/155925: CD tray is not locked even if using /dev/adc0. Date: Sat, 26 Mar 2011 19:10:55 +0200 On 2011-03-25, Alexander Best wrote: this issue is not limited to acd. using cdcontrol -f /dev/cd gives the same behavior. I think this is because cdcontrol(1) first issues the CDIOCALLOW ioctl to unlock the tray. Does this patch fix your problem? http://www.saunalahti.fi/~jh3/patches/cdcontrol-no-CDIOCALLOW.diff I am inclined to think that the behavior is intentional. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/153142: [zfs] ls -l outputs `ls: ./.zfs: Operation not supported'
The following reply was made to PR bin/153142; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Hiroshi Fujishima hir...@tonteki.org Cc: Bruce Cran br...@cran.org.uk, bug-follo...@freebsd.org, tr...@freebsd.org Subject: Re: bin/153142: [zfs] ls -l outputs `ls: ./.zfs: Operation not supported' Date: Fri, 14 Jan 2011 11:00:50 +0200 Hi, On 2010-12-14, Hiroshi Fujishima wrote: Description: 1. filesystem is zfs 2. snapdir property is visible 3. top directory of file system has .a file. with above condition, ls -l outputs `ls: ./.zfs: Operation not supported' How-To-Repeat: backup8y# zfs create -o mountpoint=/test -o snapdir=visible tank/test backup8y# ls -l /test total 0 dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs backup8y# touch /test/.a backup8y# ls -l /test total 1 -rw-r--r-- 1 root wheel 0 Dec 14 15:46 .a ls: /test/.zfs: Operation not supported dr-xr-xr-x 3 root wheel 3 Dec 14 15:46 .zfs ls(1) detects from the first file in the listing if the file system supports ACLs and assumes that all files on the same file system support ACLs. The .zfs directory is special and doesn't support ACLs. Thus ls(1) prints an error message for acl_get_link_np(3) failure. Also, if the .zfs directory is the first entry of a listing, ls(1) assumes that files on the same file system don't have ACLs and doesn't print '+' after mode. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good
The following reply was made to PR kern/122838; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Dmitry Marakasov amd...@amdmi3.ru Cc: bug-follo...@freebsd.org Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good Date: Tue, 21 Dec 2010 21:10:12 +0200 On 2010-12-08, Jaakko Heinonen wrote: On 2008-04-17, Dmitry Marakasov wrote: devfs behavior on nested paths is really unintuitive and pretty hard to tune. The problem is that for directories and symbolic links, rules match against single component name while for device files rules match against full device path (si_name). This may cause unwanted effects. For example, the rule devfs fd hide hides an entry /dev/label/fd/label. Here is an experimental patch to change rules to match against full path for directories and symbolic links: http://people.freebsd.org/~jh/patches/devfs-rule-fullpath.diff The problem with this change is that it breaks existing rulesets if someone relies on rules matching against single component of a path. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good
The following reply was made to PR kern/122838; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Dmitry Marakasov amd...@amdmi3.ru Cc: bug-follo...@freebsd.org Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good Date: Wed, 8 Dec 2010 15:39:10 +0200 On 2008-04-17, Dmitry Marakasov wrote: devfs behavior on nested paths is really unintuitive and pretty hard to tune. I agree that the behavior of rules is confusing with directories. Suppose I have ZFS zvol under pool/vms/win2000 and I want to unhide node for it in the jail. Here's what it look like unhidden: % find /dev/zvol /dev/zvol /dev/zvol/pool /dev/zvol/pool/vms /dev/zvol/pool/vms/win2000 Following rules should do what you want: path zvol/* hide path zvol/pool/vms/win2000 unhide The problem is that for directories and symbolic links, rules match against single component name while for device files rules match against full device path (si_name). This may cause unwanted effects. For example, the rule devfs fd hide hides an entry /dev/label/fd/label. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/151861: dlclose() of library causes separately opened libraries to unload as well
The following reply was made to PR misc/151861; it has been noted by GNATS.
From: Jaakko Heinonen j...@freebsd.org
To: Kostik Belousov kostik...@gmail.com
Cc: Arjan van Leeuwen freebsd-maintai...@opera.com,
bug-follo...@freebsd.org, k...@freebsd.org
Subject: Re: misc/151861: dlclose() of library causes separately opened
libraries to unload as well
Date: Wed, 3 Nov 2010 12:06:49 +0200
On 2010-11-02, Kostik Belousov wrote:
Why do you think that your patch is not correct ?
Well, I didn't say that I think it's incorrect. :)
I feel that more explicit handling of the state of the DAG is cleaner.
I don't disagree but there is a problem with your patch. If an object
has the DF_1_NODELETE flag set, dag is initialized in
load_needed_objects(). In this case the reference count isn't correctly
bumped in dlopen() because dag_inited is already set.
(BTW. I think that there shouldn't be the ref_dag(obj1) call in
load_needed_objects(). Now the reference count is increased twice in the
nodelete case.)
--- a/libexec/rtld-elf/rtld.c
+++ b/libexec/rtld-elf/rtld.c
@@ -1275,8 +1275,11 @@ init_dag(Obj_Entry *root)
{
DoneList donelist;
+if (root-dag_inited)
+return;
Why init_dag() should be allowed to be called multiple times for an
object?
Thanks.
--
Jaakko
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/151861: dlclose() of library causes separately opened libraries to unload as well
The following reply was made to PR misc/151861; it has been noted by GNATS.
From: Jaakko Heinonen j...@freebsd.org
To: Kostik Belousov kostik...@gmail.com
Cc: Arjan van Leeuwen freebsd-maintai...@opera.com,
bug-follo...@freebsd.org, k...@freebsd.org
Subject: Re: misc/151861: dlclose() of library causes separately opened
libraries to unload as well
Date: Wed, 3 Nov 2010 17:02:24 +0200
On 2010-11-03, Kostik Belousov wrote:
Why init_dag() should be allowed to be called multiple times for an
object?
If already loaded object is dlopened, dlclosed, and then again dlopened,
init_dag() will be called twice, one time for each dlopen.
If the object gets unloaded after dlclose(), this will not happen? I am
not sure if I like that it can be called multiple times.
--- a/libexec/rtld-elf/rtld.c
+++ b/libexec/rtld-elf/rtld.c
@@ -1275,11 +1275,12 @@ init_dag(Obj_Entry *root)
{
DoneList donelist;
-if (root-dag_inited)
-return;
-donelist_init(donelist);
-init_dag1(root, root, donelist);
-root-dag_inited = true;
+if (!root-dag_inited) {
+donelist_init(donelist);
+init_dag1(root, root, donelist);
+root-dag_inited = true;
+}
+ref_dag(root);
}
If you are going to take this approach, why not remove init_dag() altogether
and make ref_dag() to initialize the dag when necessary?
Thanks for working on this.
--
Jaakko
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/151861: dlclose() of library causes separately opened libraries to unload as well
The following reply was made to PR misc/151861; it has been noted by GNATS.
From: Jaakko Heinonen j...@freebsd.org
To: Arjan van Leeuwen freebsd-maintai...@opera.com
Cc: bug-follo...@freebsd.org, k...@freebsd.org, k...@freebsd.org
Subject: Re: misc/151861: dlclose() of library causes separately opened
libraries to unload as well
Date: Tue, 2 Nov 2010 19:36:54 +0200
On 2010-11-01, Arjan van Leeuwen wrote:
Assume we have a library liba.so, containing a function a(), and a
library libb.so, containing function b(). liba.so needs functionality
from libb.so, so liba.so links in libb.so.
An application doesn't know about the relation between these
libraries, but needs to call a() and b(). It dlopen()s libb.so and
obtains a pointer to b(), and it dlopen()s liba.so and obtains a
pointer to a().
As soon as the application doesn't need a() anymore, it dlclose()s
liba.so.
Expected result: the pointer to b() is still valid and can be called
Actual result: the pointer to b() has become invalid, even though the
application did not dlclose() the handle to libb.so. On calling b(),
the application crashes with a segmentation fault.
Extract the attached shar archive and execute 'make test'.
Thank you for providing the test case.
This will cause a crash on FreeBSD, and will print 'success' on Linux.
There is a problem with reference counting in dlopen(). If an object has
been loaded by load_needed_objects() its dagmembers list may be empty
after loading. If the list is empty, the ref_dag() call done for already
loaded objects in dlopen() doesn't have effect.
Here is a patch to demonstrate the problem. The test passes with the
patch applied.
%%%
Index: libexec/rtld-elf/rtld.c
===
--- libexec/rtld-elf/rtld.c(revision 214676)
+++ libexec/rtld-elf/rtld.c(working copy)
@@ -2046,7 +2046,10 @@ dlopen(const char *name, int mode)
} else {
/* Bump the reference counts for objects on this DAG. */
- ref_dag(obj);
+ if (STAILQ_EMPTY(obj-dagmembers))
+ init_dag(obj);
+ else
+ ref_dag(obj);
if (ld_tracing)
goto trace;
%%%
I have cc'd kan@ and k...@. Do you have ideas how to fix this correctly?
--
Jaakko
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/69066: [panic] nmdm(4) page fault when slattach on a null modem device
On 2010-10-29, Robert N. M. Watson wrote: Synopsis: [panic] nmdm(4) page fault when slattach on a null modem device State-Changed-From-To: open-feedback State-Changed-By: jh State-Changed-When: Fri Oct 29 08:01:53 UTC 2010 State-Changed-Why: Do you know if this problem still exists? http://www.freebsd.org/cgi/query-pr.cgi?pr=69066 Certainly not in 8.x and 9.x -- SLIP has been removed. Sure, but the panic happens in nmdm(4). -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/96157: Subtle incompatability of FreeBSD and LITE-ON SOHW-1673s drive
On 2010-10-26, Ronald F. Guilmette wrote: State-Changed-Why: Submitter's mail server rejects mail from me. http://www.freebsd.org/cgi/query-pr.cgi?pr=96157 I hope that you will excuse me for saying so, but I do think that that is rather a poor reason for closing the PR. What e-mail address were you sending from? Was it in one of these freemail domains that spew spam continuously, you know, like Hotmail, Yahoo and Gmail? (I have those all blocked here, because life is too short and I don't have time to deal with all of the spam these places generate and send me every damn day.) Didn't the bounce message you got when you tried to e-mail me direct you to the contact form on my web site, where you could have easily reached me and asked to be specially whitelisted? I am sorry but I don't think that we can realistically expect developers to go through such hoops to just reach a PR submitter. Thus by closing the PR I will also save time of the next person trying to contact the submitter. I can reopen the PR, if you provide a working e-mail address. Thanks. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/150859: [tmpfs] tmpfs on stable/8-amd64 panic
The following reply was made to PR kern/150859; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Dmitry Morozovsky ma...@freebsd.org Cc: bug-follo...@freebsd.org, delp...@freebsd.org Subject: Re: kern/150859: [tmpfs] tmpfs on stable/8-amd64 panic Date: Wed, 22 Sep 2010 19:39:25 +0300 On 2010-09-22, Dmitry Morozovsky wrote: at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:383 #11 0x80c23572 in tmpfs_lookup (v=Variable v is not available. ) at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:95 383 panic(tmpfs_alloc_vp: type %p %d, node, (int)node-tn_type); This seems to be a duplicate of kern/122038. r197953 hasn't been MFCd to stable/8. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/147482: mksnap_ffs(8) prints garbage as error message when nmount(2) fails
The following reply was made to PR bin/147482; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: Nicholas Mills nlmi...@g.clemson.edu Cc: bug-follo...@freebsd.org Subject: Re: bin/147482: mksnap_ffs(8) prints garbage as error message when nmount(2) fails Date: Mon, 6 Sep 2010 17:45:48 +0300 On 2010-06-04, Nicholas Mills wrote: Run mksnap_ffs / to get the error message mksnap_ffs: Cannot create snapshot /: garbage: Is a directory. This patch should fix the problem: %%% Index: sbin/mksnap_ffs/mksnap_ffs.c === --- sbin/mksnap_ffs/mksnap_ffs.c (revision 212248) +++ sbin/mksnap_ffs/mksnap_ffs.c (working copy) @@ -121,8 +121,10 @@ main(int argc, char **argv) build_iovec(iov, iovlen, update, NULL, 0); build_iovec(iov, iovlen, snapshot, NULL, 0); + *errmsg = '\0'; if (nmount(iov, iovlen, stfsbuf.f_flags) 0) - err(1, Cannot create snapshot %s: %s, snapname, errmsg); + err(1, Cannot create snapshot %s%s%s, snapname, + *errmsg != '\0' ? : : , errmsg); if ((fd = open(snapname, O_RDONLY)) 0) err(1, Cannot open %s, snapname); if (fstat(fd, stbuf) != 0) %%% -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/149424: fstab and labels with whitespace
The following reply was made to PR conf/149424; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: bug-follo...@freebsd.org, wal...@pelissero.de Cc: Subject: Re: bin/149424: fstab and labels with whitespace Date: Mon, 16 Aug 2010 18:00:31 +0300 On 2010-08-08, Walter C. Pelissero wrote: /etc/fstab currently doesn't allow for whitespace anywhere but between fields (or in comments). This makes impossible to use a label in place of a device name when mounting volumes containing whitespace in the name. This is duplicate of conf/37569, bin/55539 and bin/117687. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/86765: bsdlabel(8) assigning wrong fs type.
The following reply was made to PR bin/86765; it has been noted by GNATS.
From: Jaakko Heinonen j...@freebsd.org
To: bug-follo...@freebsd.org, sha...@psoft.net
Cc:
Subject: Re: bin/86765: bsdlabel(8) assigning wrong fs type.
Date: Fri, 2 Jul 2010 19:23:18 +0300
I can reproduce this. 4.4BSD is not a valid file system type but
bsdlabel(8) mishandles it because it doesn't check if strtoul(3)
succeeds to convert the entire string in getasciipartspec((). Thus it
considers 4.4BSD as 4 which is the type number for System V. Another
bug is that bsdlabel(8) can't parse file system type names with spaces.
There are four type names with a space defined in sys/disklabel.h.
The patch below seems to fix the reported problem for me but there are
more unchecked strtoul(3) calls which I didn't investigate. Also, it
doesn't fix the problem with spaces in type names.
%%%
Index: sbin/bsdlabel/bsdlabel.c
===
--- sbin/bsdlabel/bsdlabel.c (revision 209622)
+++ sbin/bsdlabel/bsdlabel.c (working copy)
@@ -755,7 +755,7 @@ word(char *cp)
static int
getasciilabel(FILE *f, struct disklabel *lp)
{
- char *cp;
+ char *cp, *endp;
const char **cpp;
u_int part;
char *tp, line[BUFSIZ];
@@ -794,7 +794,10 @@ getasciilabel(FILE *f, struct disklabel
}
if (cpp dktypenames[DKMAXTYPES])
continue;
- v = strtoul(tp, NULL, 10);
+ errno = 0;
+ v = strtoul(tp, endp, 10);
+ if (errno != 0 || *endp != '\0')
+ v = DKMAXTYPES;
if (v = DKMAXTYPES)
fprintf(stderr, line %d:%s %lu\n, lineno,
Warning, unknown disk type, v);
@@ -1023,7 +1026,7 @@ static int
getasciipartspec(char *tp, struct disklabel *lp, int part, int lineno)
{
struct partition *pp;
- char *cp;
+ char *cp, *endp;
const char **cpp;
u_long v;
@@ -1059,9 +1062,12 @@ getasciipartspec(char *tp, struct diskla
if (*cpp != NULL) {
pp-p_fstype = cpp - fstypenames;
} else {
- if (isdigit(*cp))
- v = strtoul(cp, NULL, 10);
- else
+ if (isdigit(*cp)) {
+ errno = 0;
+ v = strtoul(cp, endp, 10);
+ if (errno != 0 || *endp != '\0')
+ v = FSMAXTYPES;
+ } else
v = FSMAXTYPES;
if (v = FSMAXTYPES) {
fprintf(stderr,
%%%
--
Jaakko
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/141235: 8.0 no longer provides /dev entries for all disk slices [regression]
The following reply was made to PR kern/141235; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: dieter...@engineer.com Cc: bug-follo...@freebsd.org, free...@sopwith.solgatos.com Subject: Re: kern/141235: 8.0 no longer provides /dev entries for all disk slices [regression] Date: Sun, 30 May 2010 16:51:40 +0300 On 2010-05-28, dieter...@engineer.com wrote: and then I added GEOM_MBR and GEOM_BSD as suggested. So I don't know where GEOM_PART_MBR comes from or how to get rid of it. GEOM_PART_* are in DEFAULTS (sys/amd64/conf/DEFAULTS on amd64). -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/141235: 8.0 no longer provides /dev entries for all disk slices [regression]
The following reply was made to PR kern/141235; it has been noted by GNATS. From: Jaakko Heinonen j...@freebsd.org To: dieter...@engineer.com Cc: bug-follo...@freebsd.org, free...@sopwith.solgatos.com Subject: Re: kern/141235: 8.0 no longer provides /dev entries for all disk slices [regression] Date: Fri, 28 May 2010 12:52:02 +0300 On 2010-05-27, dieter...@engineer.com wrote: opt_geom.h previously contained: #define GEOM_LABEL 1 #define GEOM_PART_EBR 1 #define GEOM_PART_GPT 1 #define GEOM_PART_MBR 1 #define GEOM_PART_EBR_COMPAT 1 #define GEOM_PART_BSD 1 Added GEOM_MBR and GEOM_BSD to config file. (previous config file was stock GENERIC) opt_geom.h now: #define GEOM_BSD 1 #define GEOM_LABEL 1 #define GEOM_PART_EBR 1 #define GEOM_PART_GPT 1 #define GEOM_PART_MBR 1 #define GEOM_PART_EBR_COMPAT 1 #define GEOM_PART_BSD 1 #define GEOM_MBR 1 You should remove GEOM_PART_* entries. I think that the duplicates you saw are because you had geom_part still enabled. 8.0 with GEOM_MBR and GEOM_BSD: [...] So the extended partition showed up, but now I have some duplicate /dev entries and some oddball bogus entries. -- Jaakko ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
