Re: If you are one of the cool kids who cranks kern.bufcachepercent up..

2010-01-13 Thread Tobias Ulmer 
On Tue, Jan 12, 2010 at 04:34:41PM -0700, Bob Beck wrote:
 My conern is what is actually behind your possible panic. We (including
myself)
 have been introducing and removing some dlg inspired breakage at the same
time
 here so it depends what you are doing.

 Please continue and let me know what you see.

ddb show panic
initiate_write_inodeblock: already doing I/O
ddb trace
Debugger(616a34d,0,3ec1,df01,d9fb6000) at Debugger+0x4
panic(d076a0a0,4f,dd02dddc,d037be23,616a34d) at panic+0x55
initiate_write_inodeblock_ufs1(dfb4c3fc,df2d02a4,dd02de1c,d037724b,dd02de04)
at
 initiate_write_inodeblock_ufs1+0xdf
softdep_disk_io_initiation(df2d02a4,d10e95c0,dd02de4c,d0379c79) at
softdep_disk
_io_initiation+0xa1
spec_strategy(dd02de64,df2d02a4,dd02de6c,d03a0e93,50) at spec_strategy+0x46
spec_vnoperate(dd02de64,d9fb6000,dd02de8c,80,d085eb24) at spec_vnoperate+0x16
VOP_STRATEGY(df2d02a4,0,1,0,3000) at VOP_STRATEGY+0x28
bwrite(df2d02a4,0,d9fb6000,50,df2d02a4) at bwrite+0xc8
spec_vnoperate(dd02ded4,d0752d00,d020211e,d6e3c698,d085eb30) at
spec_vnoperate+
0x16
VOP_BWRITE(df2d02a4,0,1,0) at VOP_BWRITE+0x28
ffs_fsync(dd02df24,df5e5518,dd02df2c,d7ad4e64,d085ea40) at ffs_fsync+0x1eb
VOP_FSYNC(d7ad4e64,d7b1b000,3,d7ae52bc,0) at VOP_FSYNC+0x34
sched_sync(d7ae52bc) at sched_sync+0xff
Bad frame pointer: 0xd0a2beb8
ddb ps
   PID   PPID   PGRPUID  S   FLAGS  WAIT  OMMAND
  4996  14371  26283  0  3  0x4082  pipewrgzip
 14371  26283  26283  0  3  0x4002  getblktar
 26283   5155  26283   1001  3  0x4082  pause sh
  5155   9016   5155   1001  3  0x4082  pause ksh
  9016  1   9016   1001  30x80  kqreadtmux
 14229   2711  14229   1001  3  0x4082  kqreadtmux
  2711  20702   2711   1001  3  0x4082  pause ksh
 20702   5204   5204   1001  3   0x180  selectsshd
  5204  22494   5204  0  3  0x4180  netio sshd
 12617  14992  12617   1000  3  0x4082  selectssh
 14992  31368  14992   1000  3  0x4082  pause ksh
 22489  32001  22489   1000  3  0x4082  kqreadtmux
 32001  19207  32001   1000  3  0x4082  pause ksh
 19207   6518   6518   1000  3   0x180  selectsshd
  6518  22494   6518  0  3  0x4180  netio sshd
 29850  25242  29850   1000  3  0x4082  poll  ncmpc
 17806  30978  17806503  30x88  poll  postgres
 30525  30978  30525503  30x88  selectpostgres
 12359  30978  12359503  30x88  selectpostgres
  9772  30978   9772503  30x88  selectpostgres
  6637  27574  16492515  3  0x4080  piperdunlinkd
--db_more--    30978  1   6831503  3
0x408a  selectpostgres
 27574  16492  16492515  3  0x4180  poll  squid
 16492  1  16492  0  30x80  poll  squid
 26032  1  26032   1000  30x80  poll  mpd
 17929  1  17929  0  3  0x4082  ttyin getty
 25242  31368  25242   1000  3  0x4082  pause ksh
 31368  1  31368   1000  30x80  kqreadtmux
 25796  1  25796  0  3  0x4082  ttyin getty
 26566  1  26566  0  3  0x4082  ttyin getty
 11591  1  11591  0  3  0x4082  ttyin getty
 12998  1  12998  0  3  0x4082  ttyin getty
 16752  1  16752  0  3  0x4082  ttyin getty
  9554  1   9554  0  3 0x40180  selectsendmail
  3160  1   3160  0  30x80  selectcron
 24298  1  17444  0  30x82  nanosleep perl
 32051  1  32051  0  3   0x180  selectinetd
  6565  1   6565 71  3   0x180  kqreadftp-proxy
 32243  1  32243 77  3   0x180  poll  dhcpd
 22494  1  22494  0  30x80  selectsshd
 30471  0  0  0  30x100280  nfsidlnfsio
 30278  0  0  0  30x100280  nfsidlnfsio
 18839  0  0  0  30x100280  nfsidlnfsio
 17005  0  0  0  30x100280  nfsidlnfsio
--db_more--    11650  1  11650  0  3
0x80  poll  ntpd
 27181  30711  27181 83  3   0x180  poll  ntpd
 30711  1  30711 83  3   0x180  poll  ntpd
 25200  27212  27212  0  30x80  nfsd  nfsd
  1514  27212  27212  0  30x80  nfsd  nfsd
 31283  27212  27212  0  30x80  nfsd  nfsd
  7937  27212  27212  0  30x80  nfsd  nfsd
 27212  1  27212  0  30x80  netconnfsd
 23698  1  23698  0  30x80  selectmountd
  1398  1   1398 28  3   0x180  poll  portmap
 11863   6310   6310 70  3   0x180  selectnamed
  6310  1   6310  0  3

pfsync'ing route-to, reply-to rules states OpenBSD v4.6 -stable

2010-01-13 Thread Romey Valadez 
Hi all,

I'm working on a patch to make the rules route-to and reply-to to be
synced between two firewalls in HA schema, pfsync breaks the route-to
state when the state is imported.

This patch will break the pfsync protocol, because the addition of
char rt_ifname[IFNAMSIZ] in pfsync_state struct, for this reason other
utilities that depends of pfvar.h must be recompiled, one of this
application is pfctl that depends of pfsync_state_export to show the
currents states:


--- pfvar.h 2010/01/14 01:04:54 1.290
+++ pfvar.h 2010/01/14 01:08:05
@@ -841,6 +841,7 @@
struct pfsync_state_peer src;
struct pfsync_state_peer dst;
struct pf_addr   rt_addr;
+   char rt_ifname[IFNAMSIZ];
u_int32_trule;
u_int32_tanchor;
u_int32_tnat_rule;


--- if_pfsync.c 2010/01/13 23:06:38 1.127
+++ if_pfsync.c 2010/01/14 01:14:22
@@ -415,6 +415,9 @@
/* copy from state */
strlcpy(sp-ifname, st-kif-pfik_name, sizeof(sp-ifname));
bcopy(st-rt_addr, sp-rt_addr, sizeof(sp-rt_addr));
+   /* if state has route-to option, export rt interface name too*/
+   if(st-rt_kif)
+   strlcpy(sp-rt_ifname, st-rt_kif-pfik_name,
sizeof(sp-rt_ifname));
sp-creation = htonl(time_second - st-creation);
sp-expire = pf_state_expires(st);
if (sp-expire = time_second)
@@ -562,7 +565,12 @@
st-rule.ptr = r;
st-nat_rule.ptr = NULL;
st-anchor.ptr = NULL;
-   st-rt_kif = NULL;
+   /* if the state had mached with ruleset we can bind the
+   interface for route-to, reply-to rules */
+   if(r != pf_default_rule  r-rpool.cur)
+   st-rt_kif = pfi_kif_get(sp-rt_ifname);
+   else
+   st-rt_kif = NULL;

st-pfsync_time = time_uptime;
st-sync_state = PFSYNC_S_NONE;
@@ -916,7 +924,7 @@
st = pf_find_state_byid(id_key);
if (st == NULL) {
/* insert the update */
-   if (pfsync_state_import(sp, 0))
+   if (pfsync_state_import(sp, pkt-flags))
pfsyncstats.pfsyncs_badstate++;
continue;
}


I found that adding rt_ifname data to pfsync_state is the easiest way
to complete the route-to states synchronization.

I tested this patch and it seems to work well, the states are keeped
on a failover or failback. I will test this (with the required
changes) on the -current cvs version.

- Romey