Re: bin/166483: if_nametoindex sends un-initialized bytes to ioctl

2012-03-30 Thread Gleb Smirnoff 
On Thu, Mar 29, 2012 at 03:52:23PM -0700, Xin Li wrote:
X> I think we would probably want to put the proposed change under #ifdef
X> PURIFY -- the initialization is not necessary since the uninitialized
X> part is never touched for the whole codepath.

The function isn't performance important, so I think we can put bzero()
here w/o any defines.

More and more people are using valgrind, we'd better have a libc that
valgrind won't whine at, otherwise we would have more noise on mailing
lists.

-- 
Totus tuus, Glebius.
___
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/166498: libexec

2012-03-30 Thread Sasa Sasa 
Hello  ... 

I don`t no were to go ... And ask for help... And o gona ask you if you want to 
help me ! i dont no were to find this lib ...

ld-elf.so.d  cand you say to me  were i can  finde it Please ! ... 


Thank you very very much !! 



 From: "freebsd-gnats-sub...@freebsd.org" 
To: kelloo  
Sent: Thursday, 29 March 2012, 20:00
Subject: Re: misc/166498: libexec
 
Thank you very much for your problem report.
It has the internal identification `misc/166498'.
The individual assigned to look at your
report is: freebsd-bugs. 

You can access the state of your problem report at any time
via this link:

http://www.freebsd.org/cgi/query-pr.cgi?pr=166498

>Category:       misc
>Responsible:    freebsd-bugs
>Synopsis:       libexec
>Arrival-Date:   Thu Mar 29 18:00:24 UTC 2012
___
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/166498: libexec

2012-03-30 Thread Sasa Sasa 
The following reply was made to PR misc/166498; it has been noted by GNATS.

From: Sasa Sasa 
To: "freebsd-gnats-sub...@freebsd.org" ,
  "freebsd-bugs@FreeBSD.org" 
Cc:  
Subject: Re: misc/166498: libexec
Date: Fri, 30 Mar 2012 11:43:19 +0100 (BST)

 --29941074-773298732-1333104199=:90542
 Content-Type: text/plain; charset=iso-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Hello =A0...=A0=0A=0AI don`t no were to go ... And ask for help... And o go=
 na ask you if you want to help me ! i dont no were to find this lib ...=0A=
 =0Ald-elf.so.d =A0cand you say to me =A0were i can =A0finde it Please ! ...=
 =A0=0A=0A=0AThank you very very much !!=A0=0A=0A=0A=
 =0A From: "freebsd-gnats-sub...@freebsd.org" =0ATo: kelloo  =0ASent: Thursday, 29 March=
  2012, 20:00=0ASubject: Re: misc/166498: libexec=0A =0AThank you very much =
 for your problem report.=0AIt has the internal identification `misc/166498'=
 .=0AThe individual assigned to look at your=0Areport is: freebsd-bugs. =0A=
 =0AYou can access the state of your problem report at any time=0Avia this l=
 ink:=0A=0Ahttp://www.freebsd.org/cgi/query-pr.cgi?pr=3D166498=0A=0A>Categor=
 y:=A0 =A0 =A0  misc=0A>Responsible:=A0 =A0 freebsd-bugs=0A>Synopsis:=A0 =A0=
  =A0  libexec=0A>Arrival-Date:=A0  Thu Mar 29 18:00:24 UTC 2012
 --29941074-773298732-1333104199=:90542
 Content-Type: text/html; charset=iso-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 <=
 span>Hello  ... <=
 /div>I don`t no were to go ... And ask for help... =
 And o gona ask you if you want to help me ! i dont no were to find this lib=
  ...ld-elf=
 .so.d  cand you say to me  were i can  finde it Please ! ...=
  Thank you ver=
 y very much !! From: "FreeBSD-=
 gnats-sub...@freebsd.org"  <=
 span style=3D"font-weight: bold;">To: kelloo   Sent: Thursd=
 ay, 29 March 2012, 20:00 Subject:=
  Re: misc/166498: libexec   Thank you very =
 much for your problem report.It has the internal identification `misc/1=
 66498'.The individual assigned to look at yourreport is: freebsd-bu=
 gs. You can access the state of your problem report at any time=
 via this
  link:http://www.freebsd.org/cgi/query-pr.cgi?pr=3D16649=
 8" target=3D"_blank">http://www.freebsd.org/cgi/query-pr.cgi?pr=3D166498>Category:       misc>Responsible:  =
   freebsd-bugs>Synopsis:       libexec>Ar=
 rival-Date:   Thu Mar 29 18:00:24 UTC 2012=
 
 --29941074-773298732-1333104199=:90542--
___
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/75233: [fdc] breaking fdformat /dev/fd0 resets device permissions and perhaps causes unkillable process

2012-03-30 Thread John Baldwin 
The following reply was made to PR kern/75233; it has been noted by GNATS.

From: John Baldwin 
To: bug-follo...@freebsd.org, christoph.mal...@gmx.de
Cc:  
Subject: Re: kern/75233: [fdc] breaking fdformat /dev/fd0 resets device 
permissions
 and perhaps causes unkillable process
Date: Fri, 30 Mar 2012 10:07:15 -0400

 You need to use devfs rules for this instead.  The /dev/fd0 device can
 come and go with media changes.  To make permissions on /dev/fd0
 persistent you need to teach devfs (via a rule) to use the desired
 permissions on each fd0 device.
 
 -- 
 John Baldwin
___
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/166501: FreeBSD 9.0 generates incorrect SEQ/ACK numbers under load

2012-03-30 Thread Sergey Smitienko 
The following reply was made to PR kern/166501; it has been noted by GNATS.

From: Sergey Smitienko 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/166501: FreeBSD 9.0 generates incorrect SEQ/ACK numbers
 under load
Date: Sat, 31 Mar 2012 01:07:40 +0300

 This is a multi-part message in MIME format.
 --080707000708040403050503
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 7bit
 
 I have pf running on the server.  It's has basic ruleset.
 I have table  with 4k+ networks of our web site usual visitors.
 pf rules looks like this:
 
 pass in quick from  to  port 80 keep state
 pass in quick from any to  port 80 synproxy state.
 
 In the tcpdump in report you can see Syn/Ack packet with 0 window size.
 And then one more packet with 8K tcp window.
 
 This packet is generated by pf synproxy. Pf anwers Syn packet with Syn/Ack 
 without knowledge of window size, and then passes connection to the kernel 
 tcp stack and generates "window open" Ack packet.
 
 From the over side, I have 20Gb of tcpdump files with 10^8 packets recorded.
 I've wrote a simple parser, which can detect sessions with incorrect
 seq/ack numbers. Then I've checked all IP addresses with failed TCP sessions 
 and non of them was from  set.
 So, 100% of failed sessions was comming through pf synproxy state.
 Synproxy state includes modulate state function, which is basicky an addition 
 of strong random number to seq/ack numbers.
 So, I think there is a case, then tcp comming from kernel is not
 properly modulated/demodulated
 by pf and this causes generation of incorrect seq/ack numbers.
 
 -- 
 Sergey Smitienko
 
 
 
 --080707000708040403050503
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: 7bit
 
 
   
 
 
   
   
 I have pf running on the server.  It's has basic ruleset.
 I have table  with 4k+ networks of our web site usual visitors.
 pf rules looks like this:
 
 pass in quick from  to  port 80 keep state
 pass in quick from any to  port 80 synproxy state.
 
 In the tcpdump in report you can see Syn/Ack packet with 0 window size.
 And then one more packet with 8K tcp window.
 
 This packet is generated by pf synproxy. Pf anwers Syn packet with Syn/Ack 
 without knowledge of window size, and then passes connection to the kernel 
 tcp stack and generates "window open" Ack packet.
 
 From the over side, I have 20Gb of tcpdump files with 10^8 
packets recorded.
 I've wrote a simple parser, which can detect sessions with incorrect
 seq/ack numbers. Then I've checked all IP addresses with failed TCP sessions 
 and non of them was from  set.
 So, 100% of failed sessions was comming through pf synproxy state.
 Synproxy state includes modulate state function, which is basicky an addition 
 of strong random number to seq/ack numbers.
 So, I think there is a case, then tcp comming from kernel is not
 properly modulated/demodulated
 by pf and this causes generation of incorrect seq/ack numbers.
 
 -- 
 Sergey Smitienko
 
 
   
 
 
 --080707000708040403050503--
___
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: commit references a PR

2012-03-30 Thread dfilter service 
The following reply was made to PR bin/160979; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: bin/160979: commit references a PR
Date: Fri, 30 Mar 2012 23:49:02 + (UTC)

 Author: marius
 Date: Fri Mar 30 23:48:15 2012
 New Revision: 233714
 URL: http://svn.freebsd.org/changeset/base/233714
 
 Log:
   MFC: r226179
   
   Add a "kern.features.ata_cam" sysctl in the kernel when the ATA_CAM kernel
   option is defined.  This sysctl can be queried by feature_present(3).
   
   Query for this feature in /sbin/atacontrol and /usr/sbin/burncd.
   If these utilities detect that ATA_CAM is enabled, then these utilities
   will error out.  These utilities are compatible with the old ATA
   driver, but are incomptible with the new ATA_CAM driver.  By erroring out,
   we give end-users an idea as to what remedies to use, and reduce the need 
for them
   to file PR's.  For atacontrol, camcontrol must be used instead,
   and for burncd, alternative utilties from the ports collection must be used
   such as sysutils/cdrtools.
   
   In future, maybe someone can re-write burncd to work with ATA_CAM,
   but at least for now, we give a somewhat useful error message to end users.
   
   PR:  160979
   Reviewed by: jh, Arnaud Lacombe 
   Reported by: Joe Barbish 
 
 Modified:
   stable/8/sbin/atacontrol/atacontrol.8
   stable/8/sbin/atacontrol/atacontrol.c
   stable/8/sys/dev/ata/ata-all.c
   stable/8/usr.sbin/burncd/burncd.8
   stable/8/usr.sbin/burncd/burncd.c
 Directory Properties:
   stable/8/sbin/atacontrol/   (props changed)
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/boot/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
   stable/8/sys/dev/e1000/   (props changed)
   stable/8/sys/i386/conf/XENHVM   (props changed)
   stable/8/usr.sbin/burncd/   (props changed)
 
 Modified: stable/8/sbin/atacontrol/atacontrol.8
 ==
 --- stable/8/sbin/atacontrol/atacontrol.8  Fri Mar 30 23:39:39 2012
(r233713)
 +++ stable/8/sbin/atacontrol/atacontrol.8  Fri Mar 30 23:48:15 2012
(r233714)
 @@ -25,12 +25,19 @@
  .\"
  .\" $FreeBSD$
  .\"
 -.Dd February 21, 2009
 +.Dd October 9, 2011
  .Dt ATACONTROL 8
  .Os
  .Sh NAME
  .Nm atacontrol
  .Nd ATA device driver control program
 +.Pp
 +This utility was
 +.Em deprecated
 +in
 +.Fx 9.0 .
 +See
 +.Sx NOTES .
  .Sh SYNOPSIS
  .Nm
  .Aq Ar command
 @@ -361,11 +368,17 @@ or syslog logging on it as the disk will
  up all the time.
  .Sh SEE ALSO
  .Xr ata 4
 +.Xr cam 4
 +.Xr camcontrol 8
  .Sh HISTORY
  The
  .Nm
  utility first appeared in
  .Fx 4.6 .
 +.Pp
 +.Nm
 +was deprecated in
 +.Fx 9.0 .
  .Sh AUTHORS
  .An -nosplit
  The
 @@ -377,3 +390,16 @@ utility was written by
  This manual page was written by
  .An S\(/oren Schmidt
  .Aq s...@freebsd.org .
 +.Sh NOTES
 +The
 +.Nm
 +utility was deprecated in
 +.Fx 9.0 .
 +When
 +.Bd -ragged -offset indent
 +.Cd "options ATA_CAM"
 +.Ed
 +.Pp
 +is compiled into the kernel, then
 +.Xr camcontrol 8
 +must be used instead.
 
 Modified: stable/8/sbin/atacontrol/atacontrol.c
 ==
 --- stable/8/sbin/atacontrol/atacontrol.c  Fri Mar 30 23:39:39 2012
(r233713)
 +++ stable/8/sbin/atacontrol/atacontrol.c  Fri Mar 30 23:48:15 2012
(r233714)
 @@ -378,6 +378,11 @@ main(int argc, char **argv)
  {
int fd, mode, channel, array;
  
 +  if (feature_present("ata_cam")) {
 +  errx(1, "\nATA_CAM option is enabled in kernel.\n"
 +  "Please use camcontrol instead.");
 +  }
 +
if (argc < 2)
usage();
  
 
 Modified: stable/8/sys/dev/ata/ata-all.c
 ==
 --- stable/8/sys/dev/ata/ata-all.c Fri Mar 30 23:39:39 2012
(r233713)
 +++ stable/8/sys/dev/ata/ata-all.c Fri Mar 30 23:48:15 2012
(r233714)
 @@ -119,6 +119,9 @@ SYSCTL_INT(_hw_ata, OID_AUTO, wc, CTLFLA
  TUNABLE_INT("hw.ata.setmax", &ata_setmax);
  SYSCTL_INT(_hw_ata, OID_AUTO, setmax, CTLFLAG_RDTUN, &ata_setmax, 0,
   "ATA disk set max native address");
 +#ifdef ATA_CAM
 +FEATURE(ata_cam, "ATA devices are accessed through the cam(4) driver");
 +#endif
  
  /*
   * newbus device interface related functions
 
 Modified: stable/8/usr.sbin/burncd/burncd.8
 ==
 --- stable/8/usr.sbin/burncd/burncd.8  Fri Mar 30 23:39:39 2012
(r233713)
 +++ stable/8/usr.sbin/burncd/burncd.8  Fri Mar 30 23:48:15 2012
(r233714)
 @@ -27,12 +27,19 @@
  .\"
  .\" $FreeBSD$
  .\"
 -.Dd December 21, 2009
 +.Dd October 9, 2011
  .Dt B

Re: bin/160979: burncd(8): 9.0 burncd error caused by change to cd0 from acd0

2012-03-30 Thread marius 
Synopsis: burncd(8): 9.0 burncd error caused by change to cd0 from acd0

State-Changed-From-To: patched->closed
State-Changed-By: marius
State-Changed-When: Fri Mar 30 23:58:02 UTC 2012
State-Changed-Why: 
Close; MFC'ed down to stable/8.

http://www.freebsd.org/cgi/query-pr.cgi?pr=160979
___
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/165927: commit references a PR

2012-03-30 Thread dfilter service 
The following reply was made to PR kern/165927; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/165927: commit references a PR
Date: Sat, 31 Mar 2012 06:45:20 + (UTC)

 Author: kib
 Date: Sat Mar 31 06:44:48 2012
 New Revision: 233728
 URL: http://svn.freebsd.org/changeset/base/233728
 
 Log:
   MFC r233100:
   In vm_object_page_clean(), do not clean OBJ_MIGHTBEDIRTY object flag
   if the filesystem performed short write and we are skipping the page
   due to this.
   
   Propogate write error from the pager back to the callers of
   vm_pageout_flush().  Report the failure to write a page from the
   requested range as the FALSE return value from vm_object_page_clean(),
   and propagate it back to msync(2) to return EIO to usermode.
   
   While there, convert the clearobjflags variable in the
   vm_object_page_clean() and arguments of the helper functions to
   boolean.
   
   PR:  kern/165927
 
 Modified:
   stable/9/sys/vm/vm_contig.c
   stable/9/sys/vm/vm_map.c
   stable/9/sys/vm/vm_mmap.c
   stable/9/sys/vm/vm_object.c
   stable/9/sys/vm/vm_object.h
   stable/9/sys/vm/vm_pageout.c
   stable/9/sys/vm/vm_pageout.h
 Directory Properties:
   stable/9/sys/   (props changed)
 
 Modified: stable/9/sys/vm/vm_contig.c
 ==
 --- stable/9/sys/vm/vm_contig.cSat Mar 31 01:21:54 2012
(r233727)
 +++ stable/9/sys/vm/vm_contig.cSat Mar 31 06:44:48 2012
(r233728)
 @@ -139,7 +139,8 @@ vm_contig_launder_page(vm_page_t m, vm_p
   object->type == OBJT_DEFAULT) {
vm_page_unlock_queues();
m_tmp = m;
 -  vm_pageout_flush(&m_tmp, 1, VM_PAGER_PUT_SYNC, 0, NULL);
 +  vm_pageout_flush(&m_tmp, 1, VM_PAGER_PUT_SYNC, 0,
 +  NULL, NULL);
VM_OBJECT_UNLOCK(object);
vm_page_lock_queues();
return (0);
 
 Modified: stable/9/sys/vm/vm_map.c
 ==
 --- stable/9/sys/vm/vm_map.c   Sat Mar 31 01:21:54 2012(r233727)
 +++ stable/9/sys/vm/vm_map.c   Sat Mar 31 06:44:48 2012(r233728)
 @@ -2591,6 +2591,7 @@ vm_map_sync(
vm_object_t object;
vm_ooffset_t offset;
unsigned int last_timestamp;
 +  boolean_t failed;
  
vm_map_lock_read(map);
VM_MAP_RANGE_CHECK(map, start, end);
 @@ -2620,6 +2621,7 @@ vm_map_sync(
  
if (invalidate)
pmap_remove(map->pmap, start, end);
 +  failed = FALSE;
  
/*
 * Make a second pass, cleaning/uncaching pages from the indicated
 @@ -2648,7 +2650,8 @@ vm_map_sync(
vm_object_reference(object);
last_timestamp = map->timestamp;
vm_map_unlock_read(map);
 -  vm_object_sync(object, offset, size, syncio, invalidate);
 +  if (!vm_object_sync(object, offset, size, syncio, invalidate))
 +  failed = TRUE;
start += size;
vm_object_deallocate(object);
vm_map_lock_read(map);
 @@ -2658,7 +2661,7 @@ vm_map_sync(
}
  
vm_map_unlock_read(map);
 -  return (KERN_SUCCESS);
 +  return (failed ? KERN_FAILURE : KERN_SUCCESS);
  }
  
  /*
 
 Modified: stable/9/sys/vm/vm_mmap.c
 ==
 --- stable/9/sys/vm/vm_mmap.c  Sat Mar 31 01:21:54 2012(r233727)
 +++ stable/9/sys/vm/vm_mmap.c  Sat Mar 31 06:44:48 2012(r233728)
 @@ -509,6 +509,8 @@ sys_msync(td, uap)
return (EINVAL);/* Sun returns ENOMEM? */
case KERN_INVALID_ARGUMENT:
return (EBUSY);
 +  case KERN_FAILURE:
 +  return (EIO);
default:
return (EINVAL);
}
 
 Modified: stable/9/sys/vm/vm_object.c
 ==
 --- stable/9/sys/vm/vm_object.cSat Mar 31 01:21:54 2012
(r233727)
 +++ stable/9/sys/vm/vm_object.cSat Mar 31 06:44:48 2012
(r233728)
 @@ -101,9 +101,10 @@ SYSCTL_INT(_vm, OID_AUTO, old_msync, CTL
  "Use old (insecure) msync behavior");
  
  static intvm_object_page_collect_flush(vm_object_t object, vm_page_t p,
 -  int pagerflags, int flags, int *clearobjflags);
 +  int pagerflags, int flags, boolean_t *clearobjflags,
 +  boolean_t *eio);
  static boolean_t vm_object_page_remove_write(vm_page_t p, int flags,
 -  int *clearobjflags);
 +  boolean_t *clearobjflags);
  static void   vm_object_qcollapse(vm_object_t object);
  static void   vm_object_vndeallocate(vm_object_t object);
  
 @@ -774,7 +775,7 @@ vm_o