suresh gumpula | 28 Jul 19:40 2014

Allocation/free history

   Knowing the PC of an allocation is very usefull in debugging. Having the
PC hash table and storing the pc hash  either with an object itself( at the
end) or allocate an exra structure to hold the
hash index  help us find out who/where an object was allocated.   We
already have something like this in our own operating system and has been a
useful thing in debugging.
BSD allocator uses power of 2, so storing at the end of an object might be
wasting lot of memory with large objects.

It appears we don’t have something like this in current FBSD codeline and
would like to work on this ?  Any comments   please?

It would be something like below. 8 bytes at the end of each object has
fecepost which is usefull in finding overwrites and 2 hash indices to the
PC table to track allocation history.
(kgdb-amd64-7.4-87) x/40w 0xffffff153728b038
0xffffff153728b038:     0xf6970a05      0x06cb7e0c      0x305a134a
0xc0000bed      0x134a2115

0xffffff153728b050:     0x85687ef8      0xffffffff      0x00000001
                        0xc0000bed      0x1741143b

freebsd-hackers <at> mailing list
(Continue reading)

Baptiste Daroussin | 28 Jul 01:01 2014

Add ohash (OpenBSD hash) into libutil


If noone objects I would like to bring ohash from OpenBSD into our libutil.

Ohash is already in base (usr.bin/m4/ohash) having it into libutil will increase
compatibility with OpenBSD as well as allowing the rest of the base system to be
able to benefit from ohash implementation.

Cy Schubert | 25 Jul 19:19 2014

Re: FreeBSD Quarterly Status Report - Second Quarter 2014

In message <20140724183353.GL1065 <at>>, Glen Barber writes:
> New Automounter
>    Contact: Edward Tomasz Napieral/a <trasz <at>>
>    Deficiencies in the current automounter, amd(8), are a recurring
>    problem reported by many FreeBSD users. A new automounter is being
>    developed to address these concerns.
>    The automounter is a cleanroom implementation of functionality
>    available in most other Unix systems, using proper kernel support
>    implemented via an autofs filesystem. The automounter supports a
>    standard map format, and will integrate with the Lightweight Directory
>    Access Protocol (LDAP) service.

Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd 
currently integrates with NIS as well.


Cy Schubert <Cy.Schubert <at>>
FreeBSD UNIX:  <cy <at>>   Web:

	The need of the many outweighs the greed of the few.

freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"

(Continue reading)

Glen Barber | 24 Jul 20:33 2014

FreeBSD Quarterly Status Report - Second Quarter 2014

FreeBSD Project Quarterly Status Report: April - June 2014

   This report covers FreeBSD-related projects between April and June
   2014. This is the second of four reports planned for 2014.

   The second quarter of 2014 was a very busy and productive time for the
   FreeBSD Project. A new FreeBSD Core Team was elected, the FreeBSD Ports
   Management Team branched the second quarterly "stable" branch, the
   FreeBSD Release Engineering Team was in the process of finalizing the
   FreeBSD 9.3-RELEASE cycle, and many exciting new features have been
   added to FreeBSD.

   Thanks to all the reporters for the excellent work! This report
   contains 24 entries and we hope you enjoy reading it.

   The deadline for submissions covering the period from July to September
   2014 is October 7th, 2014.

FreeBSD Team Reports

     * FreeBSD Core Team
     * FreeBSD Port Management Team
     * FreeBSD Release Engineering Team


     * Chelsio iSCSI Offload Support
     * CUSE4BSD
(Continue reading)

Bryan Drewery | 22 Jul 23:07 2014

r268621: panic: shadowed tmpfs v_object

On r268621:

> panic: shadowed tmpfs v_object 0xfffff807a7f96600
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe1247d67390
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247d67440
> vpanic() at vpanic+0x126/frame 0xfffffe1247d67480
> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247d674f0
> vm_object_deallocate() at vm_object_deallocate+0x236/frame 0xfffffe1247d67550
> tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfffffe1247d67580
> tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfffffe1247d675c0
> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfffffe1247d675f0
> vgonel() at vgonel+0x1a1/frame 0xfffffe1247d67660
> vrecycle() at vrecycle+0x3e/frame 0xfffffe1247d67690
> tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfffffe1247d676b0
> VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfffffe1247d676e0
> vinactive() at vinactive+0xc6/frame 0xfffffe1247d67730
> vputx() at vputx+0x27a/frame 0xfffffe1247d67790
> tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfffffe1247d67860
> VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe1247d67890
> kern_renameat() at kern_renameat+0x3ef/frame 0xfffffe1247d67ae0
> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d67bf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d67bf0
> --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, rsp = 0x7fffffffe238, rbp =
0x7fffffffe710 ---
> Uptime: 6d4h0m3s
> Dump failed. Partition too small.

(Continue reading)

Nidal Khalil | 22 Jul 23:06 2014

Re: freebsd-hackers Digest, Vol 588, Issue 1

Still no go

On Tue, Jul 22, 2014 at 5:00 AM, <freebsd-hackers-request <at>>

> Send freebsd-hackers mailing list submissions to
>         freebsd-hackers <at>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
>         freebsd-hackers-request <at>
> You can reach the person managing the list at
>         freebsd-hackers-owner <at>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-hackers digest..."
> Today's Topics:
>    1. Remote kernel debugging question (Nidal Khalil)
>    2. Re: Remote kernel debugging question (Benjamin Kaduk)
>    3. Re: Remote kernel debugging question (Nidal Khalil)
>    4. Re: Remote kernel debugging question (Navdeep Parhar)
>    5. Re: Remote kernel debugging question (Nidal Khalil)
>    6. Re: Remote kernel debugging question (Navdeep Parhar)
>    7. Re: Remote kernel debugging question (Nidal Khalil)
(Continue reading)

Nidal Khalil | 21 Jul 21:22 2014

Remote kernel debugging question

Hello All,
I am somewhat new to BSD kernel but I am trying to debug a kernel module
using remote debugging.
I am using 9.2 RELEASE.
I setup and compiled the kernel with the following:

makeoptions DEBUG=-g
options          KDB
options          KDB_TRACE
options          DDB_CTF
options          DDB
options          GDB
options          ALT_BREAK_TO_DEBUGGER

I setup the uart for serial1 flags to 0x90 and I can read and write to the
serial from either machine
Both machines have the same kernel booted.
I can enter ddb but I can not launch gdb
The remote GDB backend could not be selected.
sysctl -a | grep debug.kdb

debug.kdb.available: ddb
Is that correct or it should be:
debug.kdb.available: ddb gdb
How do I enable gdb backend. I appreciate the help.

freebsd-hackers <at> mailing list
(Continue reading)

Jan Kokemüller | 18 Jul 18:21 2014

Fixing fork detection of arc4random by implementing INHERIT_ZERO for minherit?

the issue mentioned at also 
affects FreeBSDs arc4random implementation as its fork detection relies 
on changing pids only. Under FreeBSD, LibreSSL uses arc4random directly, 
and relies on it to be 100% fork safe. They don't provide a way to stir 
the RNG manually. I've brought this up with the LibreSSL developers, who 
think it's a bug in the OS 

I've tried to implement INHERIT_ZERO for minherit to make arc4random 
fork safe (patches attached). It seems to work fine so far, but I'm 
really no expert on FreeBSDs VM system.

Also, the arc4random functions should probably be updated to use 
something more secure like ChaCha20 instead of RC4 

freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"
Ian Lepore | 16 Jul 23:23 2014

[CFR] Adding a function to, how to handle

I need to add an ARM-specific function to to help locate
exception unwind info in shared objects.  I'm confused about how to add
the function to do I have to add a 1.4 section because it
was first added in FreeBSD 11, or does it go into an existing section
because it doesn't introduce changes to an existing ABI?

-- Ian

Attachment (find_exidx2.diff): text/x-patch, 4688 bytes
freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"
Prabhpal S. Mavi | 11 Jul 10:32 2014

Wrong Information From Log Watch Daemon - FreeBSD 9.2 x64

Dear List Members

i did upgrade FreeBSD System From 9.0 T0 9.2 Due to some requirments.
After that i upgraded some packages such as, Apache, MySQL etc..

Problem Statement:
I still receive old package version info from Log Watch, mail that comes
from (Charlie Root) every morning.

How can i fix this behavior ? Kindly advice...

New Version For Upgraded Packages:

[root <at> titan /home/mavi]# apachectl -v
Server version: Apache/2.2.27 (FreeBSD)
Server built:   Jul  9 2014 10:05:55

[root <at> titan /home/mavi]# mysql -uroot -p
Server version: 5.6.19 Source distribution

Package Info From Log Watch Mail:

Checking for packages with security vulnerabilities:
apache-2.2.21  < Previous Version
mysql-server-5.1.60  < Previous Version

(Continue reading)


Re: [CFR] Remove texinfo from base

Warner Losh wrote:
> On Jun 25, 2014, at 8:47 AM, Baptiste Daroussin <bapt <at>> wrote:
>> On Wed, Jun 25, 2014 at 08:20:41AM -0700, Warner Losh wrote:
>>> On Jun 25, 2014, at 4:00 AM, Matthew D. Fuller <fullermd <at>> wrote:
>>>> On Wed, Jun 25, 2014 at 12:52:10PM +0200 I heard the voice of
>>>> Baptiste Daroussin, and lo! it spake thus:
>>>>> I have just committed the support for this in ports, anyway breakage
>>>>> should be reported, right now it seems fine on my exp-run
>>>> Oh, yes.  Sorry, I did phrase that poorly.  This shouldn't _break_
>>>> anything, but I suspect it will uncover existing-but-hidden breakage.
>>>> Which is good.  But does merit awareness that "hey, this will probably
>>>> happen somewhere, so know this is a place to look when a build
>>>> breaks".
>>> I know it will break certain nanobsd configurations that build ports because
>>> dependencies there (at least for the ones I’ve done) aren’t well handled. So
>>> I agree that this patch is missing, at the very least, an UPDATING entry and
>>> a __FreeBSD_version bump.
>> If you build a port that needs texinfo the port framework will do what it needs
> Except in environments that don’t do dependencies quite right, or where only a subset
> of ports tree has been imported and texinfo isn’t part of that…  But people with them
> usually know, which is why UPDATING is needed. That’s all. There’s nothing else for you
> to do.
> Warner

i a few times heard there was and IS a long standing stand-off between 
(Continue reading)