date:20111219

Re: ntfs: respect the MNT_FORCE flag upon unmount

2011-12-19 Thread STeve Andre'


On 12/19/11 19:33, Mike Belopuhov wrote:

this is an improved diff that addresses the problem with forced
unmount of the ntfs filesystem in situations like the one described
here:  http://marc.info/?l=openbsd-bugs&m=132257956328474&w=2

ntfs keeps a bunch of vnodes opened and marked as VSYSTEM including
the mount point: it's usecount is 1 and it is incremented if you do
"cd /mnt".  when you pull out a usb stick and ntfs_unmount is called
it flushes all but system vnodes and then checks if system vnodes'
usecount is not more than 1 (somebody is using a vnode).  in case
this is not true (and it's not true for the mount point since shell
process is holding that vnode) it returns EBUSY.

the only thing is ntfs is a read-only filesystem so there's no
real reason to not to succeed and "forceclose" all the vnodes.

the following change makes it respect the MNT_FORCE flag and proceed
even if there's someone holding a vnode.  also it silences the
ntfs_reclaim (like ufs_reclaim is silenced by the prtactive).

it might not be a perfect diff, but it improves the situation by
a vast margin and still reports fs as being busy when unmount is
not forced (e.g. you run umount(1)).



This sounds great, speaking as a user of this when extracting data
from a diseased Windows disk.  Thank you.

--STeve Andre'

Re: ntfs: respect the MNT_FORCE flag upon unmount

2011-12-19 Thread Kenneth R Westerback

On Tue, Dec 20, 2011 at 01:33:37AM +0100, Mike Belopuhov wrote:
> this is an improved diff that addresses the problem with forced
> unmount of the ntfs filesystem in situations like the one described
> here:  http://marc.info/?l=openbsd-bugs&m=132257956328474&w=2
> 
> ntfs keeps a bunch of vnodes opened and marked as VSYSTEM including
> the mount point: it's usecount is 1 and it is incremented if you do
> "cd /mnt".  when you pull out a usb stick and ntfs_unmount is called
> it flushes all but system vnodes and then checks if system vnodes'
> usecount is not more than 1 (somebody is using a vnode).  in case
> this is not true (and it's not true for the mount point since shell
> process is holding that vnode) it returns EBUSY.
> 
> the only thing is ntfs is a read-only filesystem so there's no
> real reason to not to succeed and "forceclose" all the vnodes.
> 
> the following change makes it respect the MNT_FORCE flag and proceed
> even if there's someone holding a vnode.  also it silences the
> ntfs_reclaim (like ufs_reclaim is silenced by the prtactive).
> 
> it might not be a perfect diff, but it improves the situation by
> a vast margin and still reports fs as being busy when unmount is
> not forced (e.g. you run umount(1)).
> 
> comments/ok?

I don't use NTFS, but this makes sense to me. ok krw@.

 Ken

> 
> Index: ntfs/ntfs_vfsops.c
> ===
> RCS file: /cvs/src/sys/ntfs/ntfs_vfsops.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 ntfs_vfsops.c
> --- ntfs/ntfs_vfsops.c4 Jul 2011 20:35:35 -   1.27
> +++ ntfs/ntfs_vfsops.c20 Dec 2011 00:12:06 -
> @@ -547,10 +547,12 @@ ntfs_unmount( 
>   return (error);
>   }
>  
> - /* Check if only system vnodes are rest */
> - for(i=0;i -  if((ntmp->ntm_sysvn[i]) && 
> - (ntmp->ntm_sysvn[i]->v_usecount > 1)) return (EBUSY);
> + /* Check if system vnodes are still referenced */
> + for(i=0;i + if(((mntflags & MNT_FORCE) == 0) && (ntmp->ntm_sysvn[i] &&
> + ntmp->ntm_sysvn[i]->v_usecount > 1))
> + return (EBUSY);
> + }
>  
>   /* Dereference all system vnodes */
>   for(i=0;i Index: ntfs/ntfs_vnops.c
> ===
> RCS file: /cvs/src/sys/ntfs/ntfs_vnops.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 ntfs_vnops.c
> --- ntfs/ntfs_vnops.c 4 Jul 2011 20:35:35 -   1.24
> +++ ntfs/ntfs_vnops.c 20 Dec 2011 00:12:06 -
> @@ -72,7 +72,7 @@ static int  ntfs_bmap(void *);
>  static int   ntfs_fsync(void *);
>  static int   ntfs_pathconf(void *);
>  
> -int  ntfs_prtactive = 1; /* 1 => print out reclaim of active vnodes */
> +int  ntfs_prtactive = 0; /* 1 => print out reclaim of active vnodes */
>  
>  /*
>   * This is a noop, simply returning what one has been given.

vr(4) suspend/resume.

2011-12-19 Thread Brynet

It seems to work, I'm not really sure if any laptops used rhine, but this 
makes ACPI suspend/resume work on one of my early ACPI-capable systems.

Tested on:
vr0 at pci0 dev 12 function 0 "VIA VT6105 RhineIII" rev 0x86: apic 2 int 19, 
address 00:19:5b:82:a1:e0

-Bryan.

Index: if_vr.c
===
RCS file: /cvs/src/sys/dev/pci/if_vr.c,v
retrieving revision 1.112
diff -u -p -u -r1.112 if_vr.c
--- dev/pci/if_vr.c 8 Dec 2011 20:19:23 -   1.112
+++ dev/pci/if_vr.c 20 Dec 2011 01:02:56 -
@@ -103,9 +103,11 @@
 int vr_probe(struct device *, void *, void *);
 int vr_quirks(struct pci_attach_args *);
 void vr_attach(struct device *, struct device *, void *);
+int vr_activate(struct device *, int);
 
 struct cfattach vr_ca = {
-   sizeof(struct vr_softc), vr_probe, vr_attach
+   sizeof(struct vr_softc), vr_probe, vr_attach, NULL,
+   vr_activate
 };
 struct cfdriver vr_cd = {
NULL, "vr", DV_IFNET
@@ -120,6 +122,7 @@ void vr_rxtick(void *);
 int vr_intr(void *);
 void vr_start(struct ifnet *);
 int vr_ioctl(struct ifnet *, u_long, caddr_t);
+void vr_chipinit(struct vr_softc *);
 void vr_init(void *);
 void vr_stop(struct vr_softc *);
 void vr_watchdog(struct ifnet *);
@@ -567,27 +570,10 @@ vr_attach(struct device *parent, struct 
printf(": %s", intrstr);
 
sc->vr_revid = PCI_REVISION(pa->pa_class);
+   sc->sc_pc = pa->pa_pc;
+   sc->sc_tag = pa->pa_tag;
 
-   /*
-* Windows may put the chip in suspend mode when it
-* shuts down. Be sure to kick it in the head to wake it
-* up again.
-*/
-   if (pci_get_capability(pa->pa_pc, pa->pa_tag,
-   PCI_CAP_PWRMGMT, NULL, NULL))
-   VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1));
-
-   /* Reset the adapter. */
-   vr_reset(sc);
-
-   /*
-* Turn on bit2 (MIION) in PCI configuration register 0x53 during
-* initialization and disable AUTOPOLL.
-*/
-   pci_conf_write(pa->pa_pc, pa->pa_tag, VR_PCI_MODE,
-   pci_conf_read(pa->pa_pc, pa->pa_tag, VR_PCI_MODE) |
-   (VR_MODE3_MIION << 24));
-   VR_CLRBIT(sc, VR_MIICMD, VR_MIICMD_AUTOPOLL);
+   vr_chipinit(sc);
 
/*
 * Get station address. The way the Rhine chips work,
@@ -697,6 +683,31 @@ fail_1:
bus_space_unmap(sc->vr_btag, sc->vr_bhandle, size);
 }
 
+int
+vr_activate(struct device *self, int act)
+{
+   struct vr_softc *sc = (struct vr_softc *)self;
+   struct ifnet *ifp = &sc->arpcom.ac_if;
+   int rv = 0;
+
+   switch (act) {
+   case DVACT_QUIESCE:
+   rv = config_activate_children(self, act);
+   break;
+   case DVACT_SUSPEND:
+   if (ifp->if_flags & IFF_RUNNING)
+   vr_stop(sc);
+   rv = config_activate_children(self, act);
+   break;
+   case DVACT_RESUME:
+   rv = config_activate_children(self, act);
+   if (ifp->if_flags & IFF_UP)
+   vr_init(sc);
+   break;
+   }
+   return (rv);
+}
+
 /*
  * Initialize the transmit descriptors.
  */
@@ -1296,6 +1307,29 @@ vr_start(struct ifnet *ifp)
 }
 
 void
+vr_chipinit(struct vr_softc *sc)
+{
+   /*
+* Make sure it isn't suspended.
+*/
+   if (pci_get_capability(sc->sc_pc, sc->sc_tag,
+   PCI_CAP_PWRMGMT, NULL, NULL))
+   VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1));
+
+   /* Reset the adapter. */
+   vr_reset(sc);
+
+   /*
+* Turn on bit2 (MIION) in PCI configuration register 0x53 during
+* initialization and disable AUTOPOLL.
+*/
+   pci_conf_write(sc->sc_pc, sc->sc_tag, VR_PCI_MODE,
+   pci_conf_read(sc->sc_pc, sc->sc_tag, VR_PCI_MODE) |
+   (VR_MODE3_MIION << 24));
+   VR_CLRBIT(sc, VR_MIICMD, VR_MIICMD_AUTOPOLL);
+}
+
+void
 vr_init(void *xsc)
 {
struct vr_softc *sc = xsc;
@@ -1309,7 +1343,7 @@ vr_init(void *xsc)
 * Cancel pending I/O and free all RX/TX buffers.
 */
vr_stop(sc);
-   vr_reset(sc);
+   vr_chipinit(sc);
 
/*
 * Set our station address.
Index: if_vrreg.h
===
RCS file: /cvs/src/sys/dev/pci/if_vrreg.h,v
retrieving revision 1.29
diff -u -p -u -r1.29 if_vrreg.h
--- dev/pci/if_vrreg.h  8 Dec 2011 20:19:24 -   1.29
+++ dev/pci/if_vrreg.h  20 Dec 2011 01:02:57 -
@@ -481,6 +481,8 @@ struct vr_mii_frame {
 
 struct vr_softc {
struct device   sc_dev; /* generic device structure */
+   pci_chipset_tag_t   sc_pc;  /* PCI registers info */
+   pcitag_tsc_tag;
void *  sc_ih;  /* interrupt handler cookie */
struct arpcom   arpcom; /* interface info */
bus_space_ha

ntfs: respect the MNT_FORCE flag upon unmount

2011-12-19 Thread Mike Belopuhov

this is an improved diff that addresses the problem with forced
unmount of the ntfs filesystem in situations like the one described
here:  http://marc.info/?l=openbsd-bugs&m=132257956328474&w=2

ntfs keeps a bunch of vnodes opened and marked as VSYSTEM including
the mount point: it's usecount is 1 and it is incremented if you do
"cd /mnt".  when you pull out a usb stick and ntfs_unmount is called
it flushes all but system vnodes and then checks if system vnodes'
usecount is not more than 1 (somebody is using a vnode).  in case
this is not true (and it's not true for the mount point since shell
process is holding that vnode) it returns EBUSY.

the only thing is ntfs is a read-only filesystem so there's no
real reason to not to succeed and "forceclose" all the vnodes.

the following change makes it respect the MNT_FORCE flag and proceed
even if there's someone holding a vnode.  also it silences the
ntfs_reclaim (like ufs_reclaim is silenced by the prtactive).

it might not be a perfect diff, but it improves the situation by
a vast margin and still reports fs as being busy when unmount is
not forced (e.g. you run umount(1)).

comments/ok?

Index: ntfs/ntfs_vfsops.c
===
RCS file: /cvs/src/sys/ntfs/ntfs_vfsops.c,v
retrieving revision 1.27
diff -u -p -r1.27 ntfs_vfsops.c
--- ntfs/ntfs_vfsops.c  4 Jul 2011 20:35:35 -   1.27
+++ ntfs/ntfs_vfsops.c  20 Dec 2011 00:12:06 -
@@ -547,10 +547,12 @@ ntfs_unmount( 
return (error);
}
 
-   /* Check if only system vnodes are rest */
-   for(i=0;intm_sysvn[i]) && 
-   (ntmp->ntm_sysvn[i]->v_usecount > 1)) return (EBUSY);
+   /* Check if system vnodes are still referenced */
+   for(i=0;intm_sysvn[i] &&
+   ntmp->ntm_sysvn[i]->v_usecount > 1))
+   return (EBUSY);
+   }
 
/* Dereference all system vnodes */
for(i=0;i print out reclaim of active vnodes */
+intntfs_prtactive = 0; /* 1 => print out reclaim of active vnodes */
 
 /*
  * This is a noop, simply returning what one has been given.

Re: uvm_fault in Dec. 15 amd64 snapshot

2011-12-19 Thread Mike Belopuhov

On Mon, Dec 19, 2011 at 21:46 +0100, Mike Belopuhov wrote:
> On Sun, Dec 18, 2011 at 18:50 -0800, James A. Peltier wrote:
> > - Original Message -
> > | Hi All,
> > | 
> > | Today is our semester maintenance day and we've upgraded our backup
> > | bridge firewall to the Dec. 15, 2011 snapshot available from
> > | ftp.openbsd.org and I'm getting this odd error when I boot it up.
> > | Oddly enough, this only happens when connected to the switch that
> > | original one is connected to (we swap them out each semester).
> > | 
> > | First, I use the upgrade method to go from snapshot to snapshot and
> > | reboot
> > | I run sysmerge to bring in the new configuration files from etc50.tgz
> > | and xetc50.tgz ( I only have bsd* man* base* xbase* installed) and
> > | reboot.
> > | 
> > | So as you can see the standard running -current and I've done several
> > | upgrades now.
> > | 
> > | On my test switch (HP5304XL) it boots okay and I can reload the
> > | firewall rules with no problem. When I connect it to my HP2910 where
> > | the current firewall is running I cannot fully boot. If I press CTRL+C
> > | during the starting network section it will continue to boot. If I
> > | then run pfctl -e it states that PF is already enabled enabled but if
> > | I run pfctl -Fr -f /etc/pf.conf I get the following.
> > | 
> > | # uvm_fault(0x80d2ff40, 0x0, 0, 1) -> e
> > | kernel: page fault trap, code=0
> > | Stopped at pf_translate+0x154: cmpw %r13w,0(%rsi)
> > | ddb{0}>
> > | 
> > | keyboard is dead, no response at all from console. Any ideas?
> > 
> > Okay, I've gotten some off list requests for more information, which
> > I'm hoping I'll be able to get for those people, but I'm now outside
> > of my maintenance window and will likely need to schedule another
> > outage or figure out how to reproduce it again.  The current bridge
> > firewall running the following version does not exhibit the problem,
> > but I'm not able to get a trace output at this time.  Maybe it's
> > still at least somewhat useful reference for updates that may have
> > happened. ( Yeah right, from Aug 8th until now.  Thousands of
> > commits. ;) )
> > 
> > OpenBSD 5.0 (GENERIC.MP) #57: Mon Aug  8 14:58:00 MDT 2011
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> >
> 
> pf_translate+0x154 corresponds to the condition at pf.c:3765.
> *pd->sport doesn't point to anything.  pd->sport is set to point
> to the extracted header in the pf_setup_pdesc.  the problem is
> that the header extraction happens based on the virtual_proto,
> not proto, which can be different in the case of a fragment.
> 
> now, pf.c got it covered by the condition on line 3476 which
> prevents pf_translate from running on fragments.  the only
> other invocation of pf_translate is in the if_pflog.c:407
> where we don't check for fragments.  therefore i think that
> this is the problem.
> 
> the diff below should fix the problem.  it also doesn't make
> sense to do af translation if we didn't manage to get our
> shit done in the pf_translate and in the subsequent block.
> 
> ok?
> 

ugh, typo has crawled into the diff...
in the meantime, i've confirmed that james is using logging facility.

Index: net/if_pflog.c
===
RCS file: /cvs/src/sys/net/if_pflog.c,v
retrieving revision 1.45
diff -u -p -r1.45 if_pflog.c
--- net/if_pflog.c  21 Oct 2011 15:45:55 -  1.45
+++ net/if_pflog.c  19 Dec 2011 23:13:55 -
@@ -404,7 +404,8 @@ pflog_bpfcopy(const void *src_arg, void 
if (pd.dport)
odport = *pd.dport;
 
-   if ((pfloghdr->rewritten = pf_translate(&pd, &pfloghdr->saddr,
+   if (pd.virtual_proto != PF_VPROTO_FRAGMENT &&
+   (pfloghdr->rewritten = pf_translate(&pd, &pfloghdr->saddr,
pfloghdr->sport, &pfloghdr->daddr, pfloghdr->dport, 0,
pfloghdr->dir))) {
m_copyback(pd.m, pd.off, min(pd.m->m_len - pd.off, pd.hdrlen),
@@ -422,7 +423,7 @@ pflog_bpfcopy(const void *src_arg, void 
pd.tot_len = min(pd.tot_len, len);
pd.tot_len -= pd.m->m_data - pd.m->m_pktdat;
 
-   if (afto)
+   if (pfloghdr->rewritten && afto)
pf_translate_af(&pd);
 
mlen = min(pd.m->m_pkthdr.len, len);

Re: pf: fix icmp direction check

2011-12-19 Thread Mike Belopuhov

i've decided to rewrite the description to faciliate the review
process.

currently icmp6->icmp translation fails because of the incorrect
"icmp direction" check in pf_icmp_state_lookup.  first of all it
checks all icmp packets except for the "echo reply".  the reasons
for this are unknown.  it works pretty well in my tests.

incidentally, when af-to is used there's only one state for both
input and output and it's direction is always PF_IN. therefore,
it's pointless to check it.  instead we should derive direction
from the difference of address families in PF_SK_WIRE and
PF_SK_STACK state keys.

i've beaten this diff for quite some time and have tried
different kinds of icmp combinations including "inner" ones:
icmp as a payload of another icmp (e.g. destination unreachable
for an icmp echo request) and it works just fine.

i'd like to commit it soon and got only a tentative ok from
henning.

Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.787
diff -u -p -r1.787 pf.c
--- pf.c26 Nov 2011 03:28:46 -  1.787
+++ pf.c28 Nov 2011 00:08:09 -
@@ -4557,6 +4557,8 @@ pf_icmp_state_lookup(struct pf_pdesc *pd
 struct pf_state **state, u_int16_t icmpid, u_int16_t type,
 int icmp_dir, int *iidx, int multi, int inner)
 {
+   int direction;
+
key->af = pd->af;
key->proto = pd->proto;
key->rdomain = pd->rdomain;
@@ -4592,9 +4594,13 @@ pf_icmp_state_lookup(struct pf_pdesc *pd
STATE_LOOKUP(pd->kif, key, pd->dir, *state, pd->m);
 
/* Is this ICMP message flowing in right direction? */
-   if ((*state)->rule.ptr->type &&
-   (((!inner && (*state)->direction == pd->dir) ||
-   (inner && (*state)->direction != pd->dir)) ?
+   if ((*state)->key[PF_SK_WIRE]->af != (*state)->key[PF_SK_STACK]->af)
+   direction = (pd->af == (*state)->key[PF_SK_WIRE]->af) ?
+   PF_IN : PF_OUT;
+   else
+   direction = (*state)->direction;
+   if !inner && direction == pd->dir) ||
+   (inner && direction != pd->dir)) ?
PF_IN : PF_OUT) != icmp_dir) {
if (pf_status.debug >= LOG_NOTICE) {
log(LOG_NOTICE,

Re: uvm_fault in Dec. 15 amd64 snapshot

2011-12-19 Thread Mike Belopuhov

On Sun, Dec 18, 2011 at 18:50 -0800, James A. Peltier wrote:
> - Original Message -
> | Hi All,
> | 
> | Today is our semester maintenance day and we've upgraded our backup
> | bridge firewall to the Dec. 15, 2011 snapshot available from
> | ftp.openbsd.org and I'm getting this odd error when I boot it up.
> | Oddly enough, this only happens when connected to the switch that
> | original one is connected to (we swap them out each semester).
> | 
> | First, I use the upgrade method to go from snapshot to snapshot and
> | reboot
> | I run sysmerge to bring in the new configuration files from etc50.tgz
> | and xetc50.tgz ( I only have bsd* man* base* xbase* installed) and
> | reboot.
> | 
> | So as you can see the standard running -current and I've done several
> | upgrades now.
> | 
> | On my test switch (HP5304XL) it boots okay and I can reload the
> | firewall rules with no problem. When I connect it to my HP2910 where
> | the current firewall is running I cannot fully boot. If I press CTRL+C
> | during the starting network section it will continue to boot. If I
> | then run pfctl -e it states that PF is already enabled enabled but if
> | I run pfctl -Fr -f /etc/pf.conf I get the following.
> | 
> | # uvm_fault(0x80d2ff40, 0x0, 0, 1) -> e
> | kernel: page fault trap, code=0
> | Stopped at pf_translate+0x154: cmpw %r13w,0(%rsi)
> | ddb{0}>
> | 
> | keyboard is dead, no response at all from console. Any ideas?
> 
> Okay, I've gotten some off list requests for more information, which
> I'm hoping I'll be able to get for those people, but I'm now outside
> of my maintenance window and will likely need to schedule another
> outage or figure out how to reproduce it again.  The current bridge
> firewall running the following version does not exhibit the problem,
> but I'm not able to get a trace output at this time.  Maybe it's
> still at least somewhat useful reference for updates that may have
> happened. ( Yeah right, from Aug 8th until now.  Thousands of
> commits. ;) )
> 
> OpenBSD 5.0 (GENERIC.MP) #57: Mon Aug  8 14:58:00 MDT 2011
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>

pf_translate+0x154 corresponds to the condition at pf.c:3765.
*pd->sport doesn't point to anything.  pd->sport is set to point
to the extracted header in the pf_setup_pdesc.  the problem is
that the header extraction happens based on the virtual_proto,
not proto, which can be different in the case of a fragment.

now, pf.c got it covered by the condition on line 3476 which
prevents pf_translate from running on fragments.  the only
other invocation of pf_translate is in the if_pflog.c:407
where we don't check for fragments.  therefore i think that
this is the problem.

the diff below should fix the problem.  it also doesn't make
sense to do af translation if we didn't manage to get our
shit done in the pf_translate and in the subsequent block.

ok?

Index: if_pflog.c
===
RCS file: /cvs/src/sys/net/if_pflog.c,v
retrieving revision 1.45
diff -u -p -r1.45 if_pflog.c
--- if_pflog.c  21 Oct 2011 15:45:55 -  1.45
+++ if_pflog.c  19 Dec 2011 20:36:32 -
@@ -404,7 +404,8 @@ pflog_bpfcopy(const void *src_arg, void 
if (pd.dport)
odport = *pd.dport;
 
-   if ((pfloghdr->rewritten = pf_translate(&pd, &pfloghdr->saddr,
+   if (pd->virtual_proto != PF_VPROTO_FRAGMENT &&
+   (pfloghdr->rewritten = pf_translate(&pd, &pfloghdr->saddr,
pfloghdr->sport, &pfloghdr->daddr, pfloghdr->dport, 0,
pfloghdr->dir))) {
m_copyback(pd.m, pd.off, min(pd.m->m_len - pd.off, pd.hdrlen),
@@ -422,7 +423,7 @@ pflog_bpfcopy(const void *src_arg, void 
pd.tot_len = min(pd.tot_len, len);
pd.tot_len -= pd.m->m_data - pd.m->m_pktdat;
 
-   if (afto)
+   if (pfloghdr->rewritten && afto)
pf_translate_af(&pd);
 
mlen = min(pd.m->m_pkthdr.len, len);

Re: pfctl: ubreak optimizer

2011-12-19 Thread Mike Belopuhov

got an ok from henning, anyone else cares to comment?

On Tue, Dec 13, 2011 at 00:40 +0100, Mike Belopuhov wrote:
> updating regress tests, i've noticed that some of the optimizer
> tests are failing with additional (unoptimized) rules popping out.
> digging deeper has shown that is indeed a bug introduced by af-to
> (sorry!).  the fix is simple though.
> 
> ok?
> 
> Index: parse.y
> ===
> RCS file: /cvs/src/sbin/pfctl/parse.y,v
> retrieving revision 1.612
> diff -u -p -r1.612 parse.y
> --- parse.y   12 Dec 2011 21:30:27 -  1.612
> +++ parse.y   12 Dec 2011 23:37:03 -
> @@ -4890,7 +4890,7 @@ expand_rule(struct pf_rule *r, int keepr
>   LOOP_THROUGH(struct node_uid, uid, uids,
>   LOOP_THROUGH(struct node_gid, gid, gids,
>  
> - r->af = r->naf = af;
> + r->af = af;
>  
>   error += collapse_redirspec(&r->rdr, r, rdr, 0);
>   error += collapse_redirspec(&r->nat, r, nat, 0);
> Index: pfctl_optimize.c
> ===
> RCS file: /cvs/src/sbin/pfctl/pfctl_optimize.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 pfctl_optimize.c
> --- pfctl_optimize.c  23 Nov 2011 10:24:37 -  1.30
> +++ pfctl_optimize.c  12 Dec 2011 23:37:03 -
> @@ -175,6 +175,7 @@ struct pf_rule_field {
>  PF_RULE_FIELD(dst.neg,   NOMERGE),
>  PF_RULE_FIELD(rtableid,  NOMERGE),
>  PF_RULE_FIELD(onrdomain, NOMERGE),
> +PF_RULE_FIELD(naf,   NOMERGE),
>  
>  /* These fields can be merged */
>  PF_RULE_FIELD(src.addr,  COMBINED),

АВТОГИПЕРМАРКЕТ. Товар месяца!

2011-12-19 Thread info

table{border:1px solid #99;border-collapse:collapse;}table 
td{text-align:center;border:1px solid #99;}



 
P"PPPP  PPP!P/P&P
+ P=P>P2P0Q QP>QP:P0 P2QP4P0QP8 P7P0P:P0P7P>P2

PP5P:P0P1QQ 2011 


Verke Auto GmbH P8PP?QQ P=P0 QQP=P:P5 
P0P2QP>P7P0P?QP0QQP5P9.
PP;QQP5P2QPP P?QP>P4QP:QP8P8 P8 P2QQP>P:P8P9 
QQP>P2P5P=Q QP5QP2P8QP0.
PP>PP=P8PP5P3P> P?P>QQP5P1P8QP5P;Q. Verke QP5P=P8Q PP0QQ 
P?QP0P:QP8QP=P>QQQ P8 P4P5P;P0P5P< P2QQ, QQP>P1Q QP4P5P;P0QQ 
P=P0QP5 QP>QQQP4P=P8QP5QQP2P> P?QP8QQP=QP< P4P;Q PP0Q.


 

PP0QP0P;P>P3 Verke
http://www.autohypermarket.ru/catalog/232/
 

PP>P4QP>P1P=P5P5 P> Verke
http://www.autohypermarket.ru/manufacturer/53/


 

Eberspecher QP0P7QP0P1P>QP0P; P?QP8P1P;P8P7P8QP5P;QP=P> 2 
P2QQP;P>P?P=QQ QP8QQP5P< P8 P8PP:P>P;P> 1200 P4P5P9QQP2QQQ 
  P8Q P?P0QP5P=QP>P2 - Q
QP8 QP8QQQ QP0P QP5P1P5 QP2P8P4P5QP5P;QQQP2QP5Q P> 
P=P0QP8Q P?QP>P4P>P;P6P0QQ   P8QQQ QQP?P5QP0Q P2 P>P1P;P0QQP8 
P2QQP;P>P?P=QQ QP5QP=P>P;P>P3P8P8.


PP0QP0P;P>P3 P7P0P?QP0QQP5P9 Eberspecher
http://www.autohypermarket.ru/catalog/229/


Delphi P?QP5P4P;P0P3P0P5Q P;QQQQQ P;P8P=P5P9P:Q 
P?P=P5P2PQQP>P5P: P2 P>QQP0QP;P8. P!P?QP>P5P:QP8QP>P2P0P=P=QP5, 
QP0P7QP0P1P>QP0P=P=QP5 P8 P?QP>P8P7P2P5P4P5P=P=QP5 P?P> QQP0P=P4P0QQP0P< 
P4P;Q P>QP8P3P8P=P0P;QP=P>P3P> P>P1P>QQP4P>P2P0P=P8Q, 
P?P=P5P2PQQP>P9P:P8 P>P1P;P0P4P0QQ P:P0QP5QQP2P>P< P8 Q
P:QP?P;QP0QP0QP8P>P=P=QPP>QP2P5QQQP2QQQ  P8PPP8P7P2P>P4QQ  P5P9 P4P5QP0P;P8, Q P:P>QP>QQPP7P4P0QQQQ P0P2QP>PP1P8P;P8.

PP0QP0P;P>P3 P7P0P?QP0QQP5P9 Delphi
http://www.autohypermarket.ru/catalog/231/


 

P!P> 
QQP5P:P;P>P>QP8QQP8QP5P;QPP;P>P3P8P8 
P8P7P3P>QP>P2P;P5P=P8Q P8 P>P?QP8PP5 QP>QP5QP0P=P8P5 
P>QP>P1P5P=P=P>QQP5P9 P8 P?QP5P8PP6P5QP5 P1QQQ
 QP2P5QP5P=Q P2 P8P4P5P0P;QP=P>P9 P>P1P7P>QP=P>QQP8.


PP0QP0P;P>P3 P7P0P?QP0QQP5P9 Q P5QP>P: CHAMPION
http://www.autohypermarket.ru/catalog/141/


 


DENSO QQQP0P=P0P2P;P8P2P0P5Q QQP0P=P4P0QQQ 
P2 QP5QP=P>P;P>P3P8P8 P?QP>P8P7P2P>P4QQP2P0 QP2P5QP5P9 P7P0P6P8P3P0P=P8Q 
Q 1959 P3P>P4P0, QP0P7QP0P1P0QQP2P0Q P2QP5 QP8P?Q QP2P5QP5P9 P8 
P?QP>P8P7P2P>P4Q P8Q P=P0 QP>P1QQP2P5P=P=QQ P7P0P2P>P4P0Q, 
QP5QQP8QP8QP8QP>P2P0P=P=QQ P?P> QS 9000 P8 ISO 9000, 
QP0QP?P>P;P>P6P5P=P=QQ P2 QP0P7P=QQ QP5P3P8P>P=P0Q PP< QP2P;QP5QQQ «PP>P;Q P4P5QP5P:QP>P2». 
PP1P5QP?P5QP8P2P0P5Q P:P0QP5QQP2P> P>QP8P3P8P=P0P;QP=P>P3P> 
P?QP>P4QP:QP0 P8 P4P;Q P2QP>QP8QP=P>P3P> QQP=P:P0.



PP0QP0P;P>P3 QP2P5QP5P9 DENSO
http://www.autohypermarket.ru/catalog/157/

 

 

PP;Q PP0QP5P3P> QP4P>P1QQP2P0 
P>QP:QQP;P0QQ P=P>P2P0Q QP>QP:P0 P2QP4P0QP8 
P7P0P:P0P7P>P2. 
P P>P7P=P8QP=P0Q P?QP>P4P0P6P0. P!QP>P; 
P7P0P:P0P7P>P2.
QP;. PP0QQP0P;P0 PP>P2P8P:P>P2P0, P4.41, P"P 
"P-P2QP8P:P0"
QP5P;: +7 (812) 309-73-13  
 


P?P>PQ   Q P2 P?P>P8QP:P5 QP>P2P0QP0;

P>P?P;P0QP0 QP>P2P0QP0;

P2QP4P0QP0 QP>P2P0QP0;

PP3P8P?P5QPP=QP0P:QP=QP5 QP5P;P5QP>P=Q:

+7(812) 309-73-13;   +7(812) 966-75-47

ICQ: 605-719-062

www.autohypermarket.ru;   
s...@autohypermarket.ru

PP0QP5QQP2P> P2 P4P5QP0P;QQ!

PP;Q QP>P3P> QQP>P1Q P>QP?P8QP0QQQQ 
P>Q QP0QQQP;P:P8, P?P>P6P0P;QP9QQP0, P=P0P?P8QP8QP5 P>P1 Q
QP>P< P=P0 P0P4QP5Q  s...@autohypermarket.ru PQP1QP5 P2P0QP8 
P2P>P?QP>QQ P8 P?P>P6P5P;P0P=P8Q P2Q PP6P5QP5 P>QP?QP0P2P8QQ 
i...@autohypermarket.ru


PP=P8PP;-P2P> QP>P2P0QP0 
P>P3QP0P=P8QP5P=P>. P&P5P=P0 P=P0 QP>P2P0Q PP6P5Q P1QQQ 
QP:P>QQP5P:QP8QP>P2P0P=P0 P2 P1P>P;QQQQ P8P;P8 PQP>P=Q.




Its simple text. Switch to HTML view!

Re: ntfs: respect the MNT_FORCE flag upon unmount

Re: ntfs: respect the MNT_FORCE flag upon unmount

vr(4) suspend/resume.

ntfs: respect the MNT_FORCE flag upon unmount

Re: uvm_fault in Dec. 15 amd64 snapshot

Re: pf: fix icmp direction check

Re: uvm_fault in Dec. 15 amd64 snapshot

Re: pfctl: ubreak optimizer

АВТОГИПЕРМАРКЕТ. Товар месяца!

9 matches

Site Navigation

Mail list logo

Footer information