Re: [RFC] Allow m_dup() to use JUMBO clusters

[John-Mark Gurney]

Rick Macklem wrote this message on Tue, Jul 08, 2014 at 16:10 -0400:
> I tried:
>   m = m_getjcl(M_NOWAIT..M_JUMPAGESIZE);
>   if (m == NULL)
>m = getjcl(M_WAITOK..MCLBYTES);
> when I was experimenting with MJUMPAGESIZE clusters for NFS and what happened
> was the thread looped in the first m_getjcl() instead of returning NULL.
> It is about 12 layers of function calls deep and most fail/return NULL, but
> somewhere one of them decides to "try again". I didn't locate the location
> of that and don't know if it would be safe to change it so that m_getjcl()
> returns NULL for this case.

So, I took a quick look at this, and I see a weird issue...

In mb_ctor_mbuf in kern_mbuf.c, the how argument is passed to m_init
instead of flags...  how and flags SHOULD be the same, but it could be
that uma could change how to something else and we are loosing _NOWAIT..

Also, m_getjcl is calling two different uma_zalloc_arg's, know which
one would be useful...

You should be able to verify this w/ dtrace pretty easily in your case..

Brief call path:
m_getjcl -> uma_zalloc_arg -> mb_ctor_mbuf -> m_init -> m_pkthdr_init ->
mac_mbuf_init -> m_tag_get or mac_mbuf_tag_init...

I didn't trace it down beyond mac_mbuf_init..  Verifying that
mac_mbuf_init still has M_NOWAIT would be good...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
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: r268621: panic: shadowed tmpfs v_object [with dump]

[Mattia Rossi]

Got the same panic, is this fix getting committed? Or has it already 
been committed?


Mat

On 23/07/14 18:12, Bryan Drewery wrote:

On 7/23/14, 7:11 AM, Konstantin Belousov wrote:

On Tue, Jul 22, 2014 at 02:53:56PM -0700, Bryan Drewery wrote:

On 7/22/14, 2:26 PM, Bryan Drewery wrote:

On 7/22/14, 2:07 PM, Bryan Drewery wrote:

Meant to send to current@, moving there.

On 7/22/14, 2:07 PM, Bryan Drewery wrote:

On r268621:


panic: shadowed tmpfs v_object 0xf807a7f96600
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe1247d67390
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247d67440
vpanic() at vpanic+0x126/frame 0xfe1247d67480
kassert_panic() at kassert_panic+0x139/frame 0xfe1247d674f0
vm_object_deallocate() at vm_object_deallocate+0x236/frame
0xfe1247d67550
tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfe1247d67580
tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfe1247d675c0
VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfe1247d675f0
vgonel() at vgonel+0x1a1/frame 0xfe1247d67660
vrecycle() at vrecycle+0x3e/frame 0xfe1247d67690
tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfe1247d676b0
VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 
0xfe1247d676e0

vinactive() at vinactive+0xc6/frame 0xfe1247d67730
vputx() at vputx+0x27a/frame 0xfe1247d67790
tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfe1247d67860
VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfe1247d67890
kern_renameat() at kern_renameat+0x3ef/frame 0xfe1247d67ae0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247d67bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247d67bf0
--- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, 
rsp =

0x7fffe238, rbp = 0x7fffe710 ---
Uptime: 6d4h0m3s

Dump failed. Partition too small.


Unfortunately I have no dump to debug.




Running poudriere again after boot hit the issue right away:



(kgdb) bt
#0  doadump (textdump=1) at pcpu.h:219
#1  0x809122a7 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:445
#2  0x809127e5 in vpanic (fmt=, 
ap=
optimized out>) at /usr/src/sys/kern/kern_shutdown.c:744
#3  0x80912679 in kassert_panic (fmt=out>) at

/usr/src/sys/kern/kern_shutdown.c:632
#4  0x80ba7996 in vm_object_deallocate (object=) at /usr/src/sys/vm/vm_object.c:562
#5  0x820a75a8 in tmpfs_free_node (tmp=0xf800b5155980,
node=0xf802716ba740) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:335
#6  0x820a363d in tmpfs_reclaim (v=) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1276
#7  0x80e48717 in VOP_RECLAIM_APV (vop=,
a=) at vnode_if.c:2017
#8  0x809c1381 in vgonel (vp=0xf802716b61d8) at
vnode_if.h:830
#9  0x809c18be in vrecycle (vp=0xf802716b61d8) at
/usr/src/sys/kern/vfs_subr.c:2655
#10 0x820a61cc in tmpfs_inactive (v=) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1242
#11 0x80e485b7 in VOP_INACTIVE_APV (vop=out>,

a=) at vnode_if.c:1951
#12 0x809bfd36 in vinactive (vp=0xf802716b61d8,
td=0xf80187e29920) at vnode_if.h:807
#13 0x809c012a in vputx (vp=0xf802716b61d8, func=2) at
/usr/src/sys/kern/vfs_subr.c:2267
#14 0x820a47c5 in tmpfs_rename (v=) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1023
#15 0x80e47d3c in VOP_RENAME_APV (vop=,
a=) at vnode_if.c:1544
#16 0x809cc77f in kern_renameat (td=,
oldfd=, old=, newfd=, new=,
 pathseg=) at vnode_if.h:636
#17 0x80d280fa in amd64_syscall (td=0xf80187e29920,
traced=0) at subr_syscall.c:133
#18 0x80d0a64b in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:407
(kgdb) p *(vm_object_t)0xf8027169f500
$1 = {lock = {lock_object = {lo_name = 0x80fe89f6 "vm 
object",

lo_flags = 90374144, lo_data = 0, lo_witness = 0xfe6e7680},
rw_lock = 18446735284191271200}, object_list = {
 tqe_next = 0xf8027169f400, tqe_prev = 0xf8027169f620},
shadow_head = {lh_first = 0xf801b8489e00}, shadow_list = {le_next
= 0x0, le_prev = 0x0}, memq = {tqh_first = 0xf811d966bc08,
 tqh_last = 0xf811d966bc18}, rtree = {rt_root =
18446735354278362121, rt_flags = 0 '\0'}, size = 1, generation = 1,
ref_count = 1, shadow_count = 1, memattr = 6 '\006', type = 1 '\001',
   flags = 528, pg_color = 0, paging_in_progress = 0,
resident_page_count = 1, backing_object = 0x0, 
backing_object_offset =

0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {
 lh_first = 0x0}, cache = {rt_root = 0, rt_flags = 0 '\0'}, 
handle

= 0x0, un_pager = {vnp = {vnp_size = 0, writemappings = 0}, devp =
{devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0,
   dev = 0x0}, sgp = {sgp_pglist = {tqh_first = 0x0, tqh_last =
0x0}}, swp = {swp_tmpfs = 0x0, swp_bcount = 0}}, cred = 0x0, 
charge = 0}

(kgdb) frame 8
#8  0x809c1381 in vgonel (vp=0xf8027

Re: Future of pf / firewall in FreeBSD ? - does it have one ?

[Fbsd8]

Cy Schubert wrote:

In message <53ccf596.1070...@yandex.ru>, "Andrey V. Elsukov" writes:

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 20.07.2014 18:15, Maxim Khitrov wrote:

In my opinion, the way forward is to forget (at least temporarily) the
SMP changes, bring pf in sync with OpenBSD, put a policy in place to
follow their releases as closely as possible, and then try to
reintroduce all the SMP work. I think the latter has to be done
upstream, otherwise it'll always be a story of diverging codebases.
Furthermore, if FreeBSD developers were willing to spend some time
improving pf performance on OpenBSD, then Henning and other OpenBSD
developers might be more receptive to changes that make the porting
process easier.

Even if you just drop current PF from FreeBSD, there is nobody, who want
to port new PF from OpenBSD. And this is not easy task, as you may
think. Gleb has worked on rewriting PF more than half year. So, return
back all improvements after import will be hard enough and, again,
nobody want to do it. :)


One way or another something needs to be done and agreed it would be a lot 
of work. Our options are,


a) Import OpenBSD pf thereby throwing away our current investment in pf. 
All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would 
be all for naught. We do get a new pf though. Won't be a quality port 
though. Personally, not my #1 option.


b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we 
do save the work we put into our pf. Once again a lot of work. We'd be 
introducing incompatibility.


c) Do nothing. It goes without saying that pf would suffer rot and 
eventually we would need to do something.


d) Yank pf from tree. An option but probably not a great one. We do have 
two other packet filters in the kernel (ipfw and ipfilter) however they are 
different beasts with different capabilities. I think the reason we have 
the packet filters we do have is for the capabilities they bring to the 
table. I for one have run more than one in the same kernel because each has 
different capabilities.


e) We could add capability to pf on a piecemeal basis. Option (b) but as 
time permits. Remember, people have jobs and commitments. Funding would 
help address this.


f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more 
compatible with our IP stack? Could this be an option?


Anything we do should work with VIMAGE and be able to handle nat66 as well.




Hello Cy;
Finally a voice I recognize. If I remember correctly you stepped up to 
the plate earlier this year and did for ipfilter the same kind of things
this thread is talking about for pf. IE; apply upstream maintenance and 
convert to FreeBSD standards. I think your work was a BSD fork of 
Darrow's ipfilter which from this point on all upstream maintenance must 
be hand merged into the BSD fork. I am a long time ipfilter user and 
thank you for your dedication and work ethics getting the updated 
ipfilter into 10.0 and 9.3 so quickly.


So as someone who has been there and done that already you have unique 
experience to really know the size of the task in hours to accomplish a 
pf upgrade. Could you list the tasks and hours it took you to perform 
the ipfilter upgrade so readers can have a real insight into what they 
are asking for?


I agree with your option "e" above, but I would re-word it this way.
Using the pf fork we already have in place, hand merge upstream 
differences in piecemeal chunks as time permits. The openbsd new syntax 
being the first chunk, closely followed by VIMAGE awareness.


When it comes to someone volunteering to do the work, many of us would 
step up, but the fact is only a very very few people have the coding and 
kernel knowledge to even consider doing this.



___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

[Bjoern A. Zeeb]

On 23 Jul 2014, at 20:41 , Allan Jude  wrote:

> On 2014-07-23 16:38, Bjoern A. Zeeb wrote:
>> On 23 Jul 2014, at 15:42 , Cy Schubert  wrote:
>> 
>>> Taking this discussion slightly sideways but touching on this thread a 
>>> little, each of our packet filters will need nat66 support too. Pf doesn't 
>>> support it for sure. I've been told that ipfw may and I suspect ipfilter 
>>> doesn't as it was on Darren's todo list from 2009.
>> 
>> our pf does support IPv6 prefix rewriting quite nicely and has for years.
> 
> Bjoern: What IPv6 stuff does our pf not do well?

I think the most pressing, as Peter said, is fragment handling, though a good 
fraction of major content providers seems to do mss clamping to a min IPv6 mtu 
on IPv6 and drop fragments at the edge (not much different to IPv4, which makes 
you wonder?).Whoever is clever will think of how many different queueing 
and fragment handling implementations we need in the kernel, and how often we 
have to do it on an end node that might also run a firewall,  pick one we have, 
turn it into a library thing, apply it to all places, and then add the latest 
IETF suggestions on top of it.

There was (is?) another case that in certain situations with certain pf options 
IPv6/ULP packets would not pass or get corrupted.  I think no one who 
experienced it never tracked it down to the code but I am sure there are PRs 
for this;  best bet is that not all header sizes are equal and length/offsets 
into IPv6 packets are different to IPv4, especially when you scrub.

Apart from that my knowledge of pf is diminishing.

— 
Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983

___
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: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI

[Anders Bolt-Evensen]

What I did was:
Install subversion either from ports or via pkg install
Get the newest source code from FreeBSD by running the command svn 
checkout svn://svn.freebsd.org/base/head /usr/src (or whatever directory 
you might choose, I used /usr/src)

Then I ran make buildworld from the new /usr/src directory.
When make buildworld had completed, I cd-ed to /usr/src/release and ran 
sh ./generate-release.sh (this basically creates a chroot-ed 
environment, installs some tools, builds kernel and world and creates an 
ISO in /scratch/R/FreeBSD-something-disc1.iso).
When the shell script generate-release.sh had completed, I ran the 
command mdconfig -a -t vnode -f 
/scratch/R/release/FreeBSD-something-disk1.iso -u 1 && mount -t cd9660 
/dev/md1 /mnt.
Then I created a new directory, /root/freebsd_generic_installer, copied 
the contents of /mnt/ to the new /root/freebsd_generic_installer 
directory and unmounted /mnt.


The following commands are taken from 
https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI:

> dd if=/dev/zero of=efiboot.img bs=4k count=100
> mdconfig -a -t vnode -f efiboot.img
> newfs_msdos -F 12 -m 0xf8 -L "FREEBSD_EFI" /dev/md0
> mount -t msdosfs /dev/md0 /mnt
> mkdir -p /mnt/efi/boot
> cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
> umount /mnt
> mdconfig -d -u 0

Finally I created the new custom ISO by running the following command:
makefs -t cd9660 -o bootimage='i386;efiboot.img' -o no-emul-boot -o 
rockridge -o label=“FREEBSD_UEFI_INSTALL" -o publisher="test" 
discname.iso /root/freebsd_generic_installer/


For the above example to work, please make sure that 
/root/freebsd_generic_installer/etc/fstab has the following entry:
/dev/iso9660/FREEBSD_UEFI_INSTALL / cd9660 ro 0 0, otherwise, the boot 
of the install DVD will stop with a mount error.


This is how I got the EFI FreeBSD installer to boot.

On 21/07/14 22:11, David King wrote:

Last week, I created a custom ISO from the latest -CURRENT sources which 
contained an EFI image that is bootable on my MacBook Pro.
Both installation and booting from this new FreeBSD 11 EFI system goes without 
any problems.

Somewhat off-topic, but can you detail how you did this? I've been at this 
unsuccessfully. Did you just do this 
?


___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

[Allan Jude]

On 2014-07-23 16:38, Bjoern A. Zeeb wrote:
> On 23 Jul 2014, at 15:42 , Cy Schubert  wrote:
> 
>> Taking this discussion slightly sideways but touching on this thread a 
>> little, each of our packet filters will need nat66 support too. Pf doesn't 
>> support it for sure. I've been told that ipfw may and I suspect ipfilter 
>> doesn't as it was on Darren's todo list from 2009.
> 
> our pf does support IPv6 prefix rewriting quite nicely and has for years.
> 
> — 
> Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983
> 
> ___
> 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"
> 

Bjoern: What IPv6 stuff does our pf not do well?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Future of pf / firewall in FreeBSD ? - does it have one ?

[Bjoern A. Zeeb]

On 23 Jul 2014, at 15:42 , Cy Schubert  wrote:

> Taking this discussion slightly sideways but touching on this thread a 
> little, each of our packet filters will need nat66 support too. Pf doesn't 
> support it for sure. I've been told that ipfw may and I suspect ipfilter 
> doesn't as it was on Darren's todo list from 2009.

our pf does support IPv6 prefix rewriting quite nicely and has for years.

— 
Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983

___
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: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI

[Lokadamus]

Am 20.07.2014 18:19, schrieb Anders Bolt-Evensen:

Hello, everyone!
Last week, I created a custom ISO from the latest -CURRENT sources 
which contained an EFI image that is bootable on my MacBook Pro.
Both installation and booting from this new FreeBSD 11 EFI system goes 
without any problems.
However, I've also installed X11 and GNOME to get a graphical 
environment to work with, and that's when my problem occurs.


This computer has an Intel HD 3000 card as well as an AMD Radeon 
Mobility HD 6770M card.


The problem is that every time I start up X, using the Intel driver, 
the screen freezes with a cursor in the top left corner of the screen.

In other words, the X windowing system does not show up at all.
Pressing i.e. alt+F2 to switch away from this screen does not work.


info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
info: [drm] Driver supports precise vblank timestamp query.
info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off
drmn1: taking over the fictitious range 0xa000-0xb000
fbd1 on drmn1
VT: Replacing driver "efifb" with new "fb".
info: [drm] Initialized i915 1.6.0 20080730

1.6.0 20080730 looks old for me.
Have a look at https://wiki.freebsd.org/Graphics section "Installing KMS 
Ports"


Hope it helps
Regards



___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

[Cy Schubert]

In message , Daniel 
Feenberg
 writes:
> 
> 
> On Sun, 20 Jul 2014, Lars Engels wrote:
> 
> > On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote:
> >> all of that is true, but you are missing the point. Having two versions of
> >> pf on the bsd's at the user level, is a bad thing. It confuses people,
> >> which puts them off. Its a classic case of divide an conquer for other
> >> platforms. I really like the idea of the openpf version, that has been
> >> mentioned in this thread. It would be awesome if it ended up as a supporte
> d
> >> linux thing as well, so the world could be rid of iptables. However i gues
> s
> >> thats just an unrealistic dream
> >
> > And you don't seem to get the point that _someone_ has to do the work.
> > No one has stepped up so far, so nothing is going to change.
> >
> 
> No one with authority has yet said that "If an updated pf were available,
>   would be welcomed". Rather they have said "An updated pf would not be
> suitable, as it would be incompatible with existing configuration files".
> If the latter is indeed the case, there is little incentive for anyone
> to go to the effort of porting the newer pf. After all, the reward for
> the work is chiefly in glory, and if there is to be no glory, the work
> is unlikely to be done.

I disagree. One does not do this for the glory. One does this because the 
nail hurts enough to do something about it.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

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


___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

[Cy Schubert]

In message <53ccf596.1070...@yandex.ru>, "Andrey V. Elsukov" writes:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> On 20.07.2014 18:15, Maxim Khitrov wrote:
> > In my opinion, the way forward is to forget (at least temporarily) the
> > SMP changes, bring pf in sync with OpenBSD, put a policy in place to
> > follow their releases as closely as possible, and then try to
> > reintroduce all the SMP work. I think the latter has to be done
> > upstream, otherwise it'll always be a story of diverging codebases.
> > Furthermore, if FreeBSD developers were willing to spend some time
> > improving pf performance on OpenBSD, then Henning and other OpenBSD
> > developers might be more receptive to changes that make the porting
> > process easier.
> 
> Even if you just drop current PF from FreeBSD, there is nobody, who want
> to port new PF from OpenBSD. And this is not easy task, as you may
> think. Gleb has worked on rewriting PF more than half year. So, return
> back all improvements after import will be hard enough and, again,
> nobody want to do it. :)

One way or another something needs to be done and agreed it would be a lot 
of work. Our options are,

a) Import OpenBSD pf thereby throwing away our current investment in pf. 
All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would 
be all for naught. We do get a new pf though. Won't be a quality port 
though. Personally, not my #1 option.

b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we 
do save the work we put into our pf. Once again a lot of work. We'd be 
introducing incompatibility.

c) Do nothing. It goes without saying that pf would suffer rot and 
eventually we would need to do something.

d) Yank pf from tree. An option but probably not a great one. We do have 
two other packet filters in the kernel (ipfw and ipfilter) however they are 
different beasts with different capabilities. I think the reason we have 
the packet filters we do have is for the capabilities they bring to the 
table. I for one have run more than one in the same kernel because each has 
different capabilities.

e) We could add capability to pf on a piecemeal basis. Option (b) but as 
time permits. Remember, people have jobs and commitments. Funding would 
help address this.

f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more 
compatible with our IP stack? Could this be an option?

Anything we do should work with VIMAGE and be able to handle nat66 as well.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

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


___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

[Cy Schubert]

In message <20381608.hhy3qfh...@overcee.wemm.org>, Peter Wemm writes:
> On Saturday 19 July 2014 13:06:52 Baptiste Daroussin wrote:
> > On Fri, Jul 18, 2014 at 03:22:18PM -0400, Allan Jude wrote:
> > > On 2014-07-18 15:07, Adrian Chadd wrote:
> > > > On 18 July 2014 07:34, krad  wrote:
> > > >> that is true and I have not problem using man pages, however tha=
> ts not
> > > >> the
> > > >> way most of the world work and search engines arent exactly new =
> either.
> > > >> We
> > > >> should be trying to engage more people not less, and part of tha=
> t is
> > > >> reaching out.
> > > >=20
> > > > Then do the port and maintain it.
> > > >=20
> > > > The problem isn't the desire to keep things up to date, it's a la=
> ck of
> > > > people who want that _and_ are willing/able to do it _and_ are fu=
> nded
> > > > somehow.
> > > >=20
> > > > So, please step up! We'll all love you for it.
> > > >=20
> > > >=20
> > > >=20
> > > > -a
> > > > ___
> > > > 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"
> > >=20
> > > At vBSDCon Bapt@ volunteered to port the newer pf back to FreeBSD, =
> after
> > > spending some hours driving with Henning.
> >=20
> > I tried and broke pf for month and my changes have been reverted, thi=
> s is
> > not as simple as it looks like, our code as diverge a lot in some par=
> t and
> > we do support things that openbsd does not (vimage). Sync features re=
> quires
> > us to be very careful, my priorities went elsewhere since that time, =
> so now
> > I will probably only focus on bringing features I care about, and not=
>  the
> > entirely new pf.
> >=20
> > So no do not count me as volunteer to maintain pf, I ll probably do s=
> ome
> > work but not a full sync.
> 
> If anyone is looking for a really useful chunk to work on, please go ba=
> ck over=20
> the pf history in openbsd and find where they added ipv6 fragment suppo=
> rt.  It=20
> was fairly well contained and didn't appear to be a big deal to port.  =
> They=20
> did do something with mbuf tags that I'm suspicious of though.
> 
> IPv6 fragments are the biggest pain point we have on the freebsd.org cl=
> uster -=20
> yes, we use pf and IPv6 extensively, but dns with ipv6 involved is real=
> ly=20
> painful without fragment support.
> 
> We sort-of work around it by using dedicated IPv6 address that has noth=
> ing but=20
> the dns resolver clients and allow  ipv6 fragments to it.  Its not idea=
> l but=20
> it gets over the worst problems.
> 
> The other thing we had to do for usability is stop state tracking for u=
> dp dns=20
> =2D the sheer update rate was causing collisions and state drops / resets=
>  of=20
> other connections to the point of being really hard to use.
> 
> Those two tweaks - stopping heavy dns use from thrashing the state tabl=
> es, and=20
> having a safe place to send fragments makes it quite usable for freebsd=
> .org.
> 
> But, lack of ipv6 fragment processing still causes ongoing pain.  That'=
> s our=20
> #1 wish list item for the cluster.

Taking this discussion slightly sideways but touching on this thread a 
little, each of our packet filters will need nat66 support too. Pf doesn't 
support it for sure. I've been told that ipfw may and I suspect ipfilter 
doesn't as it was on Darren's todo list from 2009.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

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


___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

[Cy Schubert]

In message 
, Adrian Chadd writes:
> On 18 July 2014 07:34, krad  wrote:
> > that is true and I have not problem using man pages, however thats not the
> > way most of the world work and search engines arent exactly new either. We
> > should be trying to engage more people not less, and part of that is
> > reaching out.
> 
> Then do the port and maintain it.
> 
> The problem isn't the desire to keep things up to date, it's a lack of
> people who want that _and_ are willing/able to do it _and_ are funded
> somehow.

Funding is the issue. Sure, some of us maintain software because a personal 
need however without funding one has to fit maintaining software into 
whatever time is left. For those of us who do this without funding you 
manage to squeeze in an hour here or there.

> So, please step up! We'll all love you for it.

Many hands make light work.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

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


___
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: [ANNOUNCEMENT] pkg 1.3.0 out!

[Kevin Oberman]

On Wed, Jul 23, 2014 at 12:04 PM, Matthew Seaman 
wrote:

> On 23/07/2014 19:38, Kevin Oberman wrote:
> > I think one bullet was a bit mangled in French->English translation,
> > though. What does "The unicity of a package is not anymore origin" mean?
> I
> > have a couple of guesses, but I am not really sure. Ithink the best
> > translations would be "The unicity of a package is no longer the origin",
> > but I am unsure of "unicity". "Uniqueness"? That would make sense, but I
> am
>
> The unique key in the main 'packages' table in local.sqlite has been
> changed from just the package origin to a combination of the package
> origin and the package name.
>
> In essence, this means we can generate and handle several different
> packages from the same origin in the ports.  Or in other words:
> *sub-packages*.
>
> While "unicity" is a legitimate English word, and it actually does mean
> pretty much exactly what Bapt wanted to express here, it isn't the way a
> native speaker would describe the concept.  However I feel disinclined
> to criticize because I'd not have a hope of getting anywhere near the
> right way of saying that in French.
>
> Cheers,
>
> Matthew
>
> --
> Dr Matthew J Seaman MA, D.Phil.
> PGP: http://www.infracaninophile.co.uk/pgpkey
>

Thanks!

No criticism intended. I just was not sure I understood the point. You (and
others) have cleared that up. Thanks!

After carefully re-reading the definition of "unicity" as "the quality of
the unique", I agree that ti is exactly the word Bapt wanted.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
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: [ANNOUNCEMENT] pkg 1.3.0 out!

[Matthew Seaman]

On 23/07/2014 19:38, Kevin Oberman wrote:
> I think one bullet was a bit mangled in French->English translation,
> though. What does "The unicity of a package is not anymore origin" mean? I
> have a couple of guesses, but I am not really sure. Ithink the best
> translations would be "The unicity of a package is no longer the origin",
> but I am unsure of "unicity". "Uniqueness"? That would make sense, but I am

The unique key in the main 'packages' table in local.sqlite has been
changed from just the package origin to a combination of the package
origin and the package name.

In essence, this means we can generate and handle several different
packages from the same origin in the ports.  Or in other words:
*sub-packages*.

While "unicity" is a legitimate English word, and it actually does mean
pretty much exactly what Bapt wanted to express here, it isn't the way a
native speaker would describe the concept.  However I feel disinclined
to criticize because I'd not have a hope of getting anywhere near the
right way of saying that in French.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] pkg 1.3.0 out!

[Kevin Oberman]

On Wed, Jul 23, 2014 at 7:42 AM, Baptiste Daroussin 
wrote:

> Hi all,
>
> I'm very please to announce the release of pkg 1.3.0
> This version is the result of almost 9 month of hard work
>
> Here are the statistics for the version:
> - 373 files changed, 66973 insertions(+), 38512 deletions(-)
> - 29 different contributors
>
> Please not that for the first time I'm not the main contributor, and I
> would
> like to particularly thanks Vsevold Stakhov for all the hard work he has
> done to
> allow us to get this release out. I would like also to give a special
> thanks to
> Andrej Zverev for the tons of hours spending on testing and cleaning the
> bug
> tracker!
>
> So much has happened that it is hard to summarize so I'll try to highlight
> the
> major points:
> - New solver, now pkg has a real SAT solver able to automatically handle
>   conflicts and dynamically discover them. (yes pkg set -o is deprecated
> now)
> - pkg install now able to install local files as well and resolve their
>   dependencies from the remote repositories
> - Lots of parts of the code has been sandboxed
> - Lots of rework to improve portability
> - Package installation process has been reworked to be safer and handle
> properly
>   the schg flags
> - Important modification of the locking system for finer grain locks
> - Massive usage of libucl
> - Simplification of the API
> - Lots of improvements on the UI to provide a better user experience.
> - Lots of improvements in multi repository mode
> - pkg audit code has been moved into the library
> - pkg -o A=B that will overwrite configuration file from cli
> - The ui now support long options
> - The unicity of a package is not anymore origin
> - Tons of bug fixes
> - Tons of behaviours fixes
> - Way more!
>
> Thank you to all contributors:
> Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis,
> Bryan Drewery, Dag-Erling Smørgrav, Dmitry Marakasov, Elvira Khabirova,
> Jamie
> Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold,
> Matthew Seaman, Maximilian Gaß, Michael Gehring, Michael Gmelin, Nicolas
> Szalay,
> Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E.
> Putrya,
> Vsevolod Stakhov, Xin Li, coctic
>
> Regards,
> Bapt on behalf of the pkg@
>

Really, really great news! Congrats to Bapt and all of the contributors,
large and small, for doing the work to make this happen. The real, live,
provable solver is something that was desperately needed. Thaqt is followed
closely with multi-repository mode. All of the rest is great, too.

I think one bullet was a bit mangled in French->English translation,
though. What does "The unicity of a package is not anymore origin" mean? I
have a couple of guesses, but I am not really sure. Ithink the best
translations would be "The unicity of a package is no longer the origin",
but I am unsure of "unicity". "Uniqueness"? That would make sense, but I am
not quite sure that is what was meant.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
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: r268621: panic: shadowed tmpfs v_object [with dump]

[Bryan Drewery]

On 7/23/14, 7:11 AM, Konstantin Belousov wrote:

On Tue, Jul 22, 2014 at 02:53:56PM -0700, Bryan Drewery wrote:

On 7/22/14, 2:26 PM, Bryan Drewery wrote:

On 7/22/14, 2:07 PM, Bryan Drewery wrote:

Meant to send to current@, moving there.

On 7/22/14, 2:07 PM, Bryan Drewery wrote:

On r268621:


panic: shadowed tmpfs v_object 0xf807a7f96600
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe1247d67390
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247d67440
vpanic() at vpanic+0x126/frame 0xfe1247d67480
kassert_panic() at kassert_panic+0x139/frame 0xfe1247d674f0
vm_object_deallocate() at vm_object_deallocate+0x236/frame
0xfe1247d67550
tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfe1247d67580
tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfe1247d675c0
VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfe1247d675f0
vgonel() at vgonel+0x1a1/frame 0xfe1247d67660
vrecycle() at vrecycle+0x3e/frame 0xfe1247d67690
tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfe1247d676b0
VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfe1247d676e0
vinactive() at vinactive+0xc6/frame 0xfe1247d67730
vputx() at vputx+0x27a/frame 0xfe1247d67790
tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfe1247d67860
VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfe1247d67890
kern_renameat() at kern_renameat+0x3ef/frame 0xfe1247d67ae0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247d67bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247d67bf0
--- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, rsp =
0x7fffe238, rbp = 0x7fffe710 ---
Uptime: 6d4h0m3s

Dump failed. Partition too small.


Unfortunately I have no dump to debug.




Running poudriere again after boot hit the issue right away:



(kgdb) bt
#0  doadump (textdump=1) at pcpu.h:219
#1  0x809122a7 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:445
#2  0x809127e5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:744
#3  0x80912679 in kassert_panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:632
#4  0x80ba7996 in vm_object_deallocate (object=) at /usr/src/sys/vm/vm_object.c:562
#5  0x820a75a8 in tmpfs_free_node (tmp=0xf800b5155980,
node=0xf802716ba740) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:335
#6  0x820a363d in tmpfs_reclaim (v=) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1276
#7  0x80e48717 in VOP_RECLAIM_APV (vop=,
a=) at vnode_if.c:2017
#8  0x809c1381 in vgonel (vp=0xf802716b61d8) at
vnode_if.h:830
#9  0x809c18be in vrecycle (vp=0xf802716b61d8) at
/usr/src/sys/kern/vfs_subr.c:2655
#10 0x820a61cc in tmpfs_inactive (v=) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1242
#11 0x80e485b7 in VOP_INACTIVE_APV (vop=,
a=) at vnode_if.c:1951
#12 0x809bfd36 in vinactive (vp=0xf802716b61d8,
td=0xf80187e29920) at vnode_if.h:807
#13 0x809c012a in vputx (vp=0xf802716b61d8, func=2) at
/usr/src/sys/kern/vfs_subr.c:2267
#14 0x820a47c5 in tmpfs_rename (v=) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1023
#15 0x80e47d3c in VOP_RENAME_APV (vop=,
a=) at vnode_if.c:1544
#16 0x809cc77f in kern_renameat (td=,
oldfd=, old=, newfd=, new=,
 pathseg=) at vnode_if.h:636
#17 0x80d280fa in amd64_syscall (td=0xf80187e29920,
traced=0) at subr_syscall.c:133
#18 0x80d0a64b in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:407
(kgdb) p *(vm_object_t)0xf8027169f500
$1 = {lock = {lock_object = {lo_name = 0x80fe89f6 "vm object",
lo_flags = 90374144, lo_data = 0, lo_witness = 0xfe6e7680},
rw_lock = 18446735284191271200}, object_list = {
 tqe_next = 0xf8027169f400, tqe_prev = 0xf8027169f620},
shadow_head = {lh_first = 0xf801b8489e00}, shadow_list = {le_next
= 0x0, le_prev = 0x0}, memq = {tqh_first = 0xf811d966bc08,
 tqh_last = 0xf811d966bc18}, rtree = {rt_root =
18446735354278362121, rt_flags = 0 '\0'}, size = 1, generation = 1,
ref_count = 1, shadow_count = 1, memattr = 6 '\006', type = 1 '\001',
   flags = 528, pg_color = 0, paging_in_progress = 0,
resident_page_count = 1, backing_object = 0x0, backing_object_offset =
0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {
 lh_first = 0x0}, cache = {rt_root = 0, rt_flags = 0 '\0'}, handle
= 0x0, un_pager = {vnp = {vnp_size = 0, writemappings = 0}, devp =
{devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0,
   dev = 0x0}, sgp = {sgp_pglist = {tqh_first = 0x0, tqh_last =
0x0}}, swp = {swp_tmpfs = 0x0, swp_bcount = 0}}, cred = 0x0, charge = 0}
(kgdb) frame 8
#8  0x809c1381 in vgonel (vp=0xf802716b61d8) at
vnode_if.h:830
830 return (VOP_RECLAIM_APV(vp->v_op, &a));
(kgdb) p *vp
$2 = {v_tag = 0x820abf96 "tmpfs", v_op = 0x820ac938,
v_data

[ANNOUNCEMENT] pkg 1.3.0 out!

[Baptiste Daroussin]

Hi all,

I'm very please to announce the release of pkg 1.3.0
This version is the result of almost 9 month of hard work

Here are the statistics for the version:
- 373 files changed, 66973 insertions(+), 38512 deletions(-)
- 29 different contributors

Please not that for the first time I'm not the main contributor, and I would
like to particularly thanks Vsevold Stakhov for all the hard work he has done to
allow us to get this release out. I would like also to give a special thanks to
Andrej Zverev for the tons of hours spending on testing and cleaning the bug
tracker!

So much has happened that it is hard to summarize so I'll try to highlight the
major points:
- New solver, now pkg has a real SAT solver able to automatically handle
  conflicts and dynamically discover them. (yes pkg set -o is deprecated now)
- pkg install now able to install local files as well and resolve their
  dependencies from the remote repositories
- Lots of parts of the code has been sandboxed
- Lots of rework to improve portability
- Package installation process has been reworked to be safer and handle properly
  the schg flags
- Important modification of the locking system for finer grain locks
- Massive usage of libucl
- Simplification of the API
- Lots of improvements on the UI to provide a better user experience.
- Lots of improvements in multi repository mode
- pkg audit code has been moved into the library
- pkg -o A=B that will overwrite configuration file from cli
- The ui now support long options
- The unicity of a package is not anymore origin
- Tons of bug fixes
- Tons of behaviours fixes
- Way more!

Thank you to all contributors:
Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis,
Bryan Drewery, Dag-Erling Smørgrav, Dmitry Marakasov, Elvira Khabirova, Jamie
Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold,
Matthew Seaman, Maximilian Gaß, Michael Gehring, Michael Gmelin, Nicolas Szalay,
Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya,
Vsevolod Stakhov, Xin Li, coctic

Regards,
Bapt on behalf of the pkg@


pgpbWq9_DzDN2.pgp
Description: PGP signature

Re: r268621: panic: shadowed tmpfs v_object [with dump]

[Konstantin Belousov]

On Tue, Jul 22, 2014 at 02:53:56PM -0700, Bryan Drewery wrote:
> On 7/22/14, 2:26 PM, Bryan Drewery wrote:
> > On 7/22/14, 2:07 PM, Bryan Drewery wrote:
> >> Meant to send to current@, moving there.
> >>
> >> On 7/22/14, 2:07 PM, Bryan Drewery wrote:
> >>> On r268621:
> >>>
>  panic: shadowed tmpfs v_object 0xf807a7f96600
>  cpuid = 0
>  KDB: stack backtrace:
>  db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>  0xfe1247d67390
>  kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247d67440
>  vpanic() at vpanic+0x126/frame 0xfe1247d67480
>  kassert_panic() at kassert_panic+0x139/frame 0xfe1247d674f0
>  vm_object_deallocate() at vm_object_deallocate+0x236/frame
>  0xfe1247d67550
>  tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfe1247d67580
>  tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfe1247d675c0
>  VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfe1247d675f0
>  vgonel() at vgonel+0x1a1/frame 0xfe1247d67660
>  vrecycle() at vrecycle+0x3e/frame 0xfe1247d67690
>  tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfe1247d676b0
>  VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfe1247d676e0
>  vinactive() at vinactive+0xc6/frame 0xfe1247d67730
>  vputx() at vputx+0x27a/frame 0xfe1247d67790
>  tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfe1247d67860
>  VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfe1247d67890
>  kern_renameat() at kern_renameat+0x3ef/frame 0xfe1247d67ae0
>  amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247d67bf0
>  Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247d67bf0
>  --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, rsp =
>  0x7fffe238, rbp = 0x7fffe710 ---
>  Uptime: 6d4h0m3s
> 
>  Dump failed. Partition too small.
> >>>
> >>> Unfortunately I have no dump to debug.
> >>>
> >>
> > Running poudriere again after boot hit the issue right away:
> >
> >
> >> (kgdb) bt
> >> #0  doadump (textdump=1) at pcpu.h:219
> >> #1  0x809122a7 in kern_reboot (howto=260) at
> >> /usr/src/sys/kern/kern_shutdown.c:445
> >> #2  0x809127e5 in vpanic (fmt=, ap= >> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:744
> >> #3  0x80912679 in kassert_panic (fmt=) at
> >> /usr/src/sys/kern/kern_shutdown.c:632
> >> #4  0x80ba7996 in vm_object_deallocate (object= >> optimized out>) at /usr/src/sys/vm/vm_object.c:562
> >> #5  0x820a75a8 in tmpfs_free_node (tmp=0xf800b5155980,
> >> node=0xf802716ba740) at
> >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:335
> >> #6  0x820a363d in tmpfs_reclaim (v=) at
> >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1276
> >> #7  0x80e48717 in VOP_RECLAIM_APV (vop=,
> >> a=) at vnode_if.c:2017
> >> #8  0x809c1381 in vgonel (vp=0xf802716b61d8) at
> >> vnode_if.h:830
> >> #9  0x809c18be in vrecycle (vp=0xf802716b61d8) at
> >> /usr/src/sys/kern/vfs_subr.c:2655
> >> #10 0x820a61cc in tmpfs_inactive (v=) at
> >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1242
> >> #11 0x80e485b7 in VOP_INACTIVE_APV (vop=,
> >> a=) at vnode_if.c:1951
> >> #12 0x809bfd36 in vinactive (vp=0xf802716b61d8,
> >> td=0xf80187e29920) at vnode_if.h:807
> >> #13 0x809c012a in vputx (vp=0xf802716b61d8, func=2) at
> >> /usr/src/sys/kern/vfs_subr.c:2267
> >> #14 0x820a47c5 in tmpfs_rename (v=) at
> >> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1023
> >> #15 0x80e47d3c in VOP_RENAME_APV (vop=,
> >> a=) at vnode_if.c:1544
> >> #16 0x809cc77f in kern_renameat (td=,
> >> oldfd=, old=, newfd= >> optimized out>, new=,
> >> pathseg=) at vnode_if.h:636
> >> #17 0x80d280fa in amd64_syscall (td=0xf80187e29920,
> >> traced=0) at subr_syscall.c:133
> >> #18 0x80d0a64b in Xfast_syscall () at
> >> /usr/src/sys/amd64/amd64/exception.S:407
> >> (kgdb) p *(vm_object_t)0xf8027169f500
> >> $1 = {lock = {lock_object = {lo_name = 0x80fe89f6 "vm object",
> >> lo_flags = 90374144, lo_data = 0, lo_witness = 0xfe6e7680},
> >> rw_lock = 18446735284191271200}, object_list = {
> >> tqe_next = 0xf8027169f400, tqe_prev = 0xf8027169f620},
> >> shadow_head = {lh_first = 0xf801b8489e00}, shadow_list = {le_next
> >> = 0x0, le_prev = 0x0}, memq = {tqh_first = 0xf811d966bc08,
> >> tqh_last = 0xf811d966bc18}, rtree = {rt_root =
> >> 18446735354278362121, rt_flags = 0 '\0'}, size = 1, generation = 1,
> >> ref_count = 1, shadow_count = 1, memattr = 6 '\006', type = 1 '\001',
> >>   flags = 528, pg_color = 0, paging_in_progress = 0,
> >> resident_page_count = 1, backing_object = 0x0, backing_object_offset =
> >> 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {
> >> lh_first = 0x0}, cache = {rt_root = 0, rt_flags = 0 '\0'

Re: Future of pf / firewall in FreeBSD ? - does it have one ?

[Darren Reed]

On 21/07/2014 5:14 AM, Eric Masson wrote:
> krad  writes:
>
> Hi,
>
>> I really like the idea of the openpf version, that has been mentioned
>> in this thread.
> It would be nice but as it's been written in this thread, Open & Free
> internals are quite different beasts, goals are different on both
> platforms, so I doubt OpenPF will exist in the future.
>
>> It would be awesome if it ended up as a supported linux thing as well,
>> so the world could be rid of iptables.
> Linux world will get rid of iptables one of these days, nftables
> inclusion in mainline is a clear signal.
>

And the design behind nftables is similar to that of NetBSD's npf.

Darren

___
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"