Re: kern/156567: [kqueue] [patch] Add EV_CLEAR to AIO events in kqueue

2012-01-31 Thread David Xu 

On 2012/1/31 4:47, igor wrote:



Dear all,

What can I do to get my patch finally applied or
rejected (hope not :) ? My PR is not even assigned to anyone. Should I
do my best to become a committer (how? :-) ?

The solution I propose
finally allows to use kqueue with aio in multi-threaded applications.
The only reason I created it is because I wanted to use it for myself
and it worked flawlessly.

Please, anyone?


It is better to allocate a member field from struct sigevent for kevent
flags, we have spare fields available there, please check the union
_sigev_un.

Regards,
David Xu

___
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/156567: [kqueue] [patch] Add EV_CLEAR to AIO events in kqueue

2012-01-31 Thread David Xu 
The following reply was made to PR kern/156567; it has been noted by GNATS.

From: David Xu 
To: igor 
Cc: bug-follo...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/156567: [kqueue] [patch] Add EV_CLEAR to AIO events in kqueue
Date: Tue, 31 Jan 2012 16:04:06 +0800

 On 2012/1/31 4:47, igor wrote:
 >
 >
 > Dear all,
 >
 > What can I do to get my patch finally applied or
 > rejected (hope not :) ? My PR is not even assigned to anyone. Should I
 > do my best to become a committer (how? :-) ?
 >
 > The solution I propose
 > finally allows to use kqueue with aio in multi-threaded applications.
 > The only reason I created it is because I wanted to use it for myself
 > and it worked flawlessly.
 >
 > Please, anyone?
 >
 It is better to allocate a member field from struct sigevent for kevent
 flags, we have spare fields available there, please check the union
 _sigev_un.
 
 Regards,
 David Xu
 
___
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/156567: [kqueue] [patch] Add EV_CLEAR to AIO events in kqueue

2012-01-31 Thread David Xu 

On 2012/1/31 16:10, David Xu wrote:

The following reply was made to PR kern/156567; it has been noted by GNATS.

From: David Xu
To: igor
Cc: bug-follo...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/156567: [kqueue] [patch] Add EV_CLEAR to AIO events in kqueue
Date: Tue, 31 Jan 2012 16:04:06 +0800

  On 2012/1/31 4:47, igor wrote:
  >
  >
  >  Dear all,
  >
  >  What can I do to get my patch finally applied or
  >  rejected (hope not :) ? My PR is not even assigned to anyone. Should I
  >  do my best to become a committer (how? :-) ?
  >
  >  The solution I propose
  >  finally allows to use kqueue with aio in multi-threaded applications.
  >  The only reason I created it is because I wanted to use it for myself
  >  and it worked flawlessly.
  >
  >  Please, anyone?
  >
  It is better to allocate a member field from struct sigevent for kevent
  flags, we have spare fields available there, please check the union
  _sigev_un.

  Regards,
  David Xu

I propose attached patch. It adds a kevent flags field into sigevent, it 
should provide

binary compatible with existing applications.


Index: /sys/sys/signal.h
===
--- /sys/sys/signal.h   (revision 230761)
+++ /sys/sys/signal.h   (working copy)
@@ -169,12 +169,14 @@
void (*_function)(union sigval);
void *_attribute; /* pthread_attr_t * */
} _sigev_thread;
+   unsigned short _kevent_flags;
long __spare__[8];
} _sigev_un;
 };
 
 #if __BSD_VISIBLE
 #definesigev_notify_kqueue sigev_signo
+#definesigev_notify_kevent_flags   _sigev_un._kevent_flags
 #definesigev_notify_thread_id  _sigev_un._threadid
 #endif
 #definesigev_notify_function   
_sigev_un._sigev_thread._function
Index: /sys/kern/vfs_aio.c
===
--- /sys/kern/vfs_aio.c (revision 230761)
+++ /sys/kern/vfs_aio.c (working copy)
@@ -1649,7 +1649,8 @@
kqfd = aiocbe->uaiocb.aio_sigevent.sigev_notify_kqueue;
kev.ident = (uintptr_t)aiocbe->uuaiocb;
kev.filter = EVFILT_AIO;
-   kev.flags = EV_ADD | EV_ENABLE | EV_FLAG1;
+   kev.flags = EV_ADD | EV_ENABLE | EV_FLAG1 |
+   (aiocbe->uaiocb.aio_sigevent.sigev_notify_kevent_flags & EV_CLEAR);
kev.data = (intptr_t)aiocbe;
kev.udata = aiocbe->uaiocb.aio_sigevent.sigev_value.sival_ptr;
error = kqfd_register(kqfd, &kev, td, 1);
___
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/156567: [kqueue] [patch] Add EV_CLEAR to AIO events in kqueue

2012-01-31 Thread igor 
  

Hello David, 

The only thing I changed is the value of the flag,
this is the only meaning of the patch. I do not know who decided to
place the value there. 

On Tue, 31 Jan 2012 16:04:06 +0800, David Xu
wrote: 

> On 2012/1/31 4:47, igor wrote:
> 
>> Dear all, What can I do
to get my patch finally applied or rejected (hope not :) ? My PR is not
even assigned to anyone. Should I do my best to become a committer (how?
:-) ? The solution I propose finally allows to use kqueue with aio in
multi-threaded applications. The only reason I created it is because I
wanted to use it for myself and it worked flawlessly. Please, anyone?
>

> It is better to allocate a member field from struct sigevent for
kevent
> flags, we have spare fields available there, please check the
union
> _sigev_un.
> 
> Regards,
> David Xu

-- 
Igor Soumenkov
  
___
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/156567: [kqueue] [patch] Add EV_CLEAR to AIO events in kqueue

2012-01-31 Thread igor 
The following reply was made to PR kern/156567; it has been noted by GNATS.

From: igor 
To: 
Cc: , 
Subject: Re: kern/156567: [kqueue] [patch] Add =?UTF-8?Q?EV=5FCLEAR=20to?=
 =?UTF-8?Q?=20AIO=20events=20in=20kqueue?=
Date: Tue, 31 Jan 2012 14:52:10 +0400

 --=_3349fc38fa29cf5858e92f7cc8080a49
 Content-Transfer-Encoding: 7bit
 Content-Type: text/plain; charset=UTF-8
 
   
 
 Hello David, 
 
 The only thing I changed is the value of the flag,
 this is the only meaning of the patch. I do not know who decided to
 place the value there. 
 
 On Tue, 31 Jan 2012 16:04:06 +0800, David Xu
 wrote: 
 
 > On 2012/1/31 4:47, igor wrote:
 > 
 >> Dear all, What can I do
 to get my patch finally applied or rejected (hope not :) ? My PR is not
 even assigned to anyone. Should I do my best to become a committer (how?
 :-) ? The solution I propose finally allows to use kqueue with aio in
 multi-threaded applications. The only reason I created it is because I
 wanted to use it for myself and it worked flawlessly. Please, anyone?
 >
 
 > It is better to allocate a member field from struct sigevent for
 kevent
 > flags, we have spare fields available there, please check the
 union
 > _sigev_un.
 > 
 > Regards,
 > David Xu
 
 -- 
 Igor Soumenkov
   
 --=_3349fc38fa29cf5858e92f7cc8080a49
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/html; charset=UTF-8
 
 
 
 Hello David,
 The only thing I changed is the value of the flag, this is the only mean=
 ing of the patch. I do not know who decided to place the value there.
 On Tue, 31 Jan 2012 16:04:06 +0800, David Xu wrote:
 
 On 2012/1/31 4:47, igor wrote:
 Dear all, What can I do to get my pat=
 ch finally applied or rejected (hope not :) ? My PR is not even assigned to=
  anyone. Should I do my best to become a committer (how? :-) ? The solution=
  I propose finally allows to use kqueue with aio in multi-threaded applicat=
 ions. The only reason I created it is because I wanted to use it for myself=
  and it worked flawlessly. Please, anyone?
 It is better to allocate a member field from struct sigevent for keven=
 t
 flags, we have spare fields available there, please check the union
 _sigev_un.
 
 Regards,
 David Xu
 
 
 
  
 
 --=20
 Igor Soumenkov
 
 
 
 --=_3349fc38fa29cf5858e92f7cc8080a49--
 
___
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/156423: [kqueue] [patch] Please add kqueue support for /dev/klog

2012-01-31 Thread Balazs Scheidler 
The following reply was made to PR kern/156423; it has been noted by GNATS.

From: Balazs Scheidler 
To: Mateusz Guzik 
Cc: bug-follo...@freebsd.org
Subject: Re: kern/156423: [kqueue] [patch] Please add kqueue support for
 /dev/klog
Date: Tue, 31 Jan 2012 15:03:05 +0100

 On Tue, 2012-01-31 at 00:02 +, Mateusz Guzik wrote:
 > Can you please try this:
 > 
 > http://student.agh.edu.pl/~mjguzik/patches/dev_klog-kqueue.patch
 > 
 > Tested with this trivial program:
 > http://student.agh.edu.pl/~mjguzik/kqread.c
 > 
 > This code is mostly stolen from audit pipe implementation, patch from
 > dragonfly people was not really helpful. :)
 > 
 
 I'm afraid I don't know FreeBSD enough to give this a spin. Compiling a
 kernel is way above my expertise on that platform.
 
 Can I forward this email to the syslog-ng mailing list? I definitely
 know there are users of syslog-ng on FreeBSD, who should know better
 than me.
 
 -- 
 Bazsi
 
 
___
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"

bin/164672: [patch] usr.sbin/mptutil: fix build error with DEBUG

2012-01-31 Thread Conrad J. Sabatier 

>Number: 164672
>Category:   bin
>Synopsis:   [patch] usr.sbin/mptutil: fix build error with DEBUG
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 31 21:20:08 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Conrad J. Sabatier
>Release:FreeBSD 10.0-CURRENT amd64
>Organization:
>Environment:
System: FreeBSD serene.no-ip.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Tue Jan 
31 14:11:27 CST 2012 conr...@serene.no-ip.org:/usr/obj/usr/src/sys/CUSTOM amd64

>Description:
buildworld fails in usr.sbin/mptutil if DEBUG defined, due to
missing declaration of int error.

>How-To-Repeat:
make buildworld with DEBUG
>Fix:
patch below

--- patch-mptutil begins here ---
Index: src/usr.sbin/mptutil/mpt_show.c
===
RCS file: /home/ncvs/src/usr.sbin/mptutil/mpt_show.c,v
retrieving revision 1.3
diff -u -r1.3 mpt_show.c
--- src/usr.sbin/mptutil/mpt_show.c 9 Nov 2010 19:28:06 -   1.3
+++ src/usr.sbin/mptutil/mpt_show.c 31 Jan 2012 19:22:16 -
@@ -538,7 +538,7 @@
 {
CONFIG_PAGE_RAID_PHYS_DISK_0 *pinfo;
U16 IOCStatus;
-   int fd, i;
+   int error, fd, i;
 
if (ac != 1) {
warnx("show drives: extra arguments");
--- patch-mptutil ends here ---


>Release-Note:
>Audit-Trail:
>Unformatted:
___
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/164258: [mfi] mfi does not work with PERC5/i in AMD M350 motherboard

2012-01-31 Thread James Mansion 
The following reply was made to PR kern/164258; it has been noted by GNATS.

From: James Mansion 
To: bug-follo...@freebsd.org, ja...@mansionfamily.plus.com
Cc:  
Subject: Re: kern/164258: [mfi] mfi does not work with PERC5/i in AMD M350
 motherboard
Date: Tue, 31 Jan 2012 22:41:07 +

 Note sure this looks quite as I was expecting.  I added:
 
 verbose_loading="YES"
 kern.msgbufsize="655360"
 
 in loader.conf.  The msgbufsize didn't seem to extend the dmesg output much.
 
 Copyright (c) 1992-2012 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
  The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012
  r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
 CPU: AMD E-350 Processor (1600.06-MHz K8-class CPU)
Origin = "AuthenticAMD"  Id = 0x500f10  Family = 14  Model = 1  
 Stepping = 0

 
Features=0x178bfbff
AMD Features=0x2e500800
AMD 
 
Features2=0x35ff
TSC: P-state invariant, performance statistics
 real memory  = 8589934592 (8192 MB)
 avail memory = 7811166208 (7449 MB)
 Event timer "LAPIC" quality 400
 ACPI APIC Table: 
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 1 package(s) x 2 core(s)
   cpu0 (BSP): APIC ID:  0
   cpu1 (AP): APIC ID:  1
 ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 
 0x/0x1 (20110527/tbfadt-586)
 ioapic0: Changing APIC ID to 0
 ioapic0  irqs 0-23 on motherboard
 kbd1 at kbdmux0
 acpi0:  on motherboard
 acpi0: Power Button (fixed)
 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
 cpu0:  on acpi0
 cpu1:  on acpi0
 hpet0:  iomem 0xfed0-0xfed003ff on acpi0
 Timecounter "HPET" frequency 14318180 Hz quality 950
 Event timer "HPET" frequency 14318180 Hz quality 550
 Event timer "HPET1" frequency 14318180 Hz quality 450
 pcib0:  port 0xcf8-0xcff on acpi0
 pci0:  on pcib0
 vgapci0:  port 0xf000-0xf0ff mem 
 0xc000-0xcfff,0xfeb0-0xfeb3 irq 18 at device 1$
 hdac0:  mem 
 0xfeb44000-0xfeb47fff irq 19 at device 1.1 on pci0
 pcib1:  irq 16 at device 4.0 on pci0
 pci1:  on pcib1
 pcib2:  at device 0.0 on pci1
 pci2:  on pcib2
 pcib1: no PRT entry for 1.0.INTC
 mfi0:  mem 0xd000-0xd000,0xfea0-0xfea1 
 irq 96 at device 14.0 on pci2
 mfi0: Megaraid SAS driver Ver 3.00
 mfi0: 10970 (379716350s/0x0020/info) - Hibernate command received from host
 mfi0: 10971 (boot + 0s/0x0020/info) - Firmware initialization started 
 (PCI ID 0015/1028/1f02/1028)
 mfi0: 10972 (boot + 0s/0x0020/info) - Firmware version 1.03.40-0232
 mfi0: 10973 (boot + 0s/0x0020/info) - Firmware initialization started 
 (PCI ID 0015/1028/1f02/1028)
 mfi0: 10974 (boot + 0s/0x0020/info) - Firmware version 1.03.40-0232
 mfi0: 10975 (boot + 0s/0x0020/info) - Firmware initialization started 
 (PCI ID 0015/1028/1f02/1028)
 mfi0: 10976 (boot + 0s/0x0020/info) - Firmware version 1.03.40-0232
 mfi0: 10977 (boot + 0s/0x0020/info) - Firmware initialization started 
 (PCI ID 0015/1028/1f02/1028)
 mfi0: 10978 (boot + 0s/0x0020/info) - Firmware version 1.03.40-0232
 mfi0: 10979 (boot + 0s/0x0020/info) - Firmware initialization started 
 (PCI ID 0015/1028/1f02/1028)
 mfi0: 10980 (boot + 0s/0x0020/info) - Firmware version 1.03.40-0232
 mfi0: 10981 (boot + 2s/0x0008/info) - Battery Present
 mfi0: 10982 (boot + 2s/0x0020/info) - Package version 5.1.1-0050
 mfi0: 10983 (boot + 29s/0x0002/info) - Inserted: PD 00(e0/s0)
 mfi0: 10984 (boot + 29s/0x0002/info) - Inserted: PD 00(e0/s0) Info: 
 enclPd=, scsiType=0, portMap=01, sasAddr=5000c5$
 mfi0: 10985 (boot + 29s/0x0002/info) - Inserted: PD 01(e0/s1)
 mfi0: 10986 (boot + 29s/0x0002/info) - Inserted: PD 01(e0/s1) Info: 
 enclPd=, scsiType=0, portMap=02, sasAddr=5000c5$
 mfi0: 10987 (379880550s/0x0020/info) - Time established as 01/14/12 
 18:22:30; (30 seconds since power on)
 mfi0: 10988 (379880551s/0x0020/info) - Patrol Read started
 mfi0: 10989 (boot + 0s/0x0020/info) - Firmware initialization started 
 (PCI ID 0015/1028/1f02/1028)
 mfi0: 10990 (boot + 0s/0x0020/info) - Firmware version 1.03.40-0232
 mfi0: 10991 (boot + 2s/0x0008/info) - Battery Present
 mfi0: 10992 (boot + 2s/0x0020/info) - Package version 5.1.1-0050
 mfi0: 10993 (boot + 29s/0x0002/info) - Inserted: PD 00(e0/s0)
 mfi0: 10994 (boot + 29s/0x0002/info) - Inserted: PD 00(e0/s0) Info: 
 enclPd=, scsiType=0, portMap=01, sasAddr=5000c5$
 mfi0: 10995 (boot + 29s/0x0002/info) - Inserted: PD 01(e0/s1)
 mfi0: 10996 (boot + 29s/0x0002/info) - Inserted: PD 01(e0/s1) Info: 
 enclPd=, scsiType=0, portMap=02, sasAddr=5000c5$
 mfi0: 10997 (boot + 29s/0x0020/info) - Patrol Read resumed
 mfi0: 10998 (379880607s/0x0020/info) - Time established as 01/14/12 
 18:23:27; (30 seconds since power on)
 mfi0: 11001 (379880664s/0x0008/info) - Battery temperat

kern/164674: vsprintf/vswprintf return error (EOF) on success if __SERR flag is already set on file

2012-01-31 Thread Matthew Story 

>Number: 164674
>Category:   kern
>Synopsis:   vsprintf/vswprintf return error (EOF) on success if __SERR 
>flag is already set on file
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 31 23:10:09 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Matthew Story
>Release:9.0-Release
>Organization:
>Environment:
FreeBSD matt9fromouterspace 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 
07:15:25 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  
i386
>Description:
The printf family of functions behaves unpredictably if the file passed to the 
function has the __SERR flag set in _flags.  The one consistency across all of 
the cases detailed below is that regardless of the number of bytes written to 
the file, and the success/failure of that operation, the printf functions 
(printf, fprintf, wprintf, fwprintf) will always return -1 (EOF).

 * For the case of an unbuffered file,  the operation currently fails 
transmitting no bytes, and returns -1.
 * For the case of a buffered file, the operation transmits all bytes and the 
function returns -1.  

The problem is that the behavior here is inconsistent, and should not be.   The 
question is wether all should be made to fail consistently and transmit no 
bytes if __SERR is set on _flags, or if failure should be determined based on 
the success of byte transmission, discounting file state.

Per the ISO/IEC 9899:201x (C11) Section 7.21.6.1, 14:

The fprintf function returns the number of characters transmitted, or a 
negative value if an output or encoding error occurred.

My reading of this specification is that success should be determined based on 
byte-transmission, and should not factor-in file state.  In addition to the ISO 
standard, the glibc implementation will reliably succeed with any error flag 
set if bytes are successfully transmitted (although it will transmit partial 
messages prior to successful conversion, which is unfortunate).

The attached patch makes the operation on buffered and unbuffered files 
consistent across the affected printf/wprintf functions, determines 
success/failure based on successful byte-transmission alone, and preserves 
_flags state for __SERR as passed in.

I originally discovered this behavior through black-box testing ``%'' 
behavior against data-types through programmatic exhaustion, although a more 
likely cause of file error state is reading from a file open in write mode, 
prior to writing to that file (which is the example used in the repeat steps 
below).
>How-To-Repeat:
/* this simple program demonstrates behavior on buffered (stdout) and 
unbuffered (stderr) files */
#include 
#define HELLO   "Hello, world\n"

int
main() {
/* make sure everything is nice and clean */
clearerr(stdout);
/* read from write-only file, should cause an error */
fgetc(stdout);
printf("stdout is buffered, and %s an error\n",
ferror(stdout) ? "has":"doesn't have");

printf("bytes transmitted without replace: %d\n",
printf(HELLO));
printf("bytes transmitted with replace: %d\n",
printf("%s", HELLO));

clearerr(stderr);
/* read from write-only file, should cause an error */
fgetc(stderr);
/*
 * print diagnostics to stdout, because some will not
 * print to stderr correctly if stderr has an error
 */
printf("stderr is unbuffered, and %s an error\n",
ferror(stderr) ? "has":"doesn't have");
printf("bytes transmitted without replace: %d\n",
fprintf(stderr, HELLO));
printf("bytes transmitted with replace: %d\n",
fprintf(stderr, "%s", HELLO));

return 0;
}
>Fix:
See patch, my fix is to store and then unset the error flag inside of the 
exclusive lock, and then to reset the error flag to the original (or new) state 
after the vs(w)printf prior to releasing the exclusive lock.

this change maintains the ferror state of the file as passed in or as set by 
__vfprintf, but allows for vs(w)printf to determine success of the print 
operation independent of the state of the file as passed in.  there may be 
other ways to handle this more gracefully, but this change seems to me to be 
the safest and most minimally impacting solution.

The patch applies cleanly on both 8.2/9.0, and includes an additional 
regression test for stdio pertaining to correctness of return codes.

Patch attached with submission follows:

diff -urN old/lib/libc/stdio/vfprintf.c new/lib/libc/stdio/vfprintf.c
--- old/lib/libc/stdio/vfprintf.c   2012-01-31 17:35:31.025336246 -0500
+++ new/lib/libc/stdio/vfprintf.c   2012-01-31 17:44:50.078652303 -0500
@@ -265,14 +265,24 @@
 
 {
in

Re: kern/164674: vsprintf/vswprintf return error (EOF) on success if __SERR flag is already set on file

2012-01-31 Thread Matthew Story 
On Tue, Jan 31, 2012 at 6:06 PM, Matthew Story wrote:

> >Synopsis:   vsprintf/vswprintf return error (EOF) on success if
> __SERR flag is already set on file
>

this synopsis should read "vfprintf/vfwprintf return ...", apologies for
the typo, can someone with appropriate edit privileges change this?

thanks
___
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/164674: vsprintf/vswprintf return error (EOF) on success if __SERR flag is already set on file

2012-01-31 Thread Matthew Story 
The following reply was made to PR kern/164674; it has been noted by GNATS.

From: Matthew Story 
To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Cc:  
Subject: Re: kern/164674: vsprintf/vswprintf return error (EOF) on success if
 __SERR flag is already set on file
Date: Tue, 31 Jan 2012 18:16:22 -0500

 --20cf3071cee2bd737d04b7db2626
 Content-Type: text/plain; charset=ISO-8859-1
 
 On Tue, Jan 31, 2012 at 6:06 PM, Matthew Story wrote:
 
 > >Synopsis:   vsprintf/vswprintf return error (EOF) on success if
 > __SERR flag is already set on file
 >
 
 this synopsis should read "vfprintf/vfwprintf return ...", apologies for
 the typo, can someone with appropriate edit privileges change this?
 
 thanks
 
 --20cf3071cee2bd737d04b7db2626
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Jan 31, 2012 at 6:06 PM, Matthew Story matthewst...@gmail.com> w=
 rote:
 >Synopsis: =A0 =A0 =A0 vsprintf/vswprintf return error (EOF) on success =
 if __SERR flag is already set on filet=
 his synopsis should read "vfprintf/vfwprintf return ...", apologi=
 es for the typo, can someone with appropriate edit privileges change this? =
 =A0
 thanks
 
 --20cf3071cee2bd737d04b7db2626--
___
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/164674: vsprintf/vswprintf return error (EOF) on success if __SERR flag is already set on file

2012-01-31 Thread Mark Linimon 
The following reply was made to PR kern/164674; it has been noted by GNATS.

From: Mark Linimon 
To: Matthew Story 
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/164674: vsprintf/vswprintf return error (EOF) on success
 if __SERR flag is already set on file
Date: Tue, 31 Jan 2012 18:47:13 -0600

 On Tue, Jan 31, 2012 at 06:16:22PM -0500, Matthew Story wrote:
 > this synopsis should read "vfprintf/vfwprintf return ...", apologies for
 > the typo, can someone with appropriate edit privileges change this?
 
 done.
 
 mcl
___
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/164651: [cam] Disabling DMA in new Freebsd 9.0 CAM drivers does not work

2012-01-31 Thread linimon 
Old Synopsis: Disabling DMA in new Freebsd 9.0 CAM drivers does not work
New Synopsis: [cam] Disabling DMA in new Freebsd 9.0 CAM drivers does not work

Responsible-Changed-From-To: freebsd-bugs->ken
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Feb 1 01:33:36 UTC 2012
Responsible-Changed-Why: 
Ken, is this your area of expertise?  If not, please just assign it over
to freebsd-scsi@.  Thanks.

http://www.freebsd.org/cgi/query-pr.cgi?pr=164651
___
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/164674: vsprintf/vswprintf return error (EOF) on success if __SERR flag is already set on file

2012-01-31 Thread Matthew Story 
The following reply was made to PR kern/164674; it has been noted by GNATS.

From: Matthew Story 
To: Mark Linimon 
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/164674: vsprintf/vswprintf return error (EOF) on success if
 __SERR flag is already set on file
Date: Tue, 31 Jan 2012 20:52:20 -0500

 --f46d0438936d80ad7204b7dd5444
 Content-Type: text/plain; charset=ISO-8859-1
 
 thanks!
 
 On Tue, Jan 31, 2012 at 7:47 PM, Mark Linimon  wrote:
 
 > On Tue, Jan 31, 2012 at 06:16:22PM -0500, Matthew Story wrote:
 > > this synopsis should read "vfprintf/vfwprintf return ...", apologies for
 > > the typo, can someone with appropriate edit privileges change this?
 >
 > done.
 >
 > mcl
 >
 
 
 
 -- 
 regards,
 matt
 
 --f46d0438936d80ad7204b7dd5444
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 thanks!On Tue, Jan 31, 2012 at 7:47 PM, =
 Mark Linimon =
 lini...@lonesome.com> wrote:On Tue, Jan 31, 2012 at 06:16:22PM -0500, Matthew Story w=
 rote:
 > this synopsis should read "vfprintf/vfwprintf return ...", a=
 pologies for
 > the typo, can someone with appropriate edit privileges change this?
 
 done.
 
 mcl
 -- regards,=
 matt
 
 --f46d0438936d80ad7204b7dd5444--
___
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/156567: commit references a PR

2012-01-31 Thread dfilter service 
The following reply was made to PR kern/156567; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/156567: commit references a PR
Date: Wed,  1 Feb 2012 02:53:15 + (UTC)

 Author: davidxu
 Date: Wed Feb  1 02:53:06 2012
 New Revision: 230857
 URL: http://svn.freebsd.org/changeset/base/230857
 
 Log:
   If multiple threads call kevent() to get AIO events on same kqueue fd,
   it is possible that a single AIO event will be reported to multiple
   threads, it is not threading friendly, and the existing API can not
   control this behavior.
   Allocate a kevent flags field sigev_notify_kevent_flags for AIO event
   notification in sigevent, and allow user to pass EV_CLEAR, EV_DISPATCH
   or EV_ONESHOT to AIO kernel code, user can control whether the event
   should be cleared once it is retrieved by a thread. This change should
   be comptaible with existing application, because the field should have
   already been zero-filled, and no additional action will be taken by
   kernel.
   
   PR:  kern/156567
 
 Modified:
   head/sys/kern/vfs_aio.c
   head/sys/sys/signal.h
 
 Modified: head/sys/kern/vfs_aio.c
 ==
 --- head/sys/kern/vfs_aio.cWed Feb  1 02:16:15 2012(r230856)
 +++ head/sys/kern/vfs_aio.cWed Feb  1 02:53:06 2012(r230857)
 @@ -1524,6 +1524,7 @@ aio_aqueue(struct thread *td, struct aio
int error;
int fd, kqfd;
int jid;
 +  u_short evflags;
  
if (p->p_aioinfo == NULL)
aio_init_aioinfo(p);
 @@ -1646,10 +1647,15 @@ aio_aqueue(struct thread *td, struct aio
  
if (aiocbe->uaiocb.aio_sigevent.sigev_notify != SIGEV_KEVENT)
goto no_kqueue;
 +  evflags = aiocbe->uaiocb.aio_sigevent.sigev_notify_kevent_flags;
 +  if ((evflags & ~(EV_CLEAR | EV_DISPATCH | EV_ONESHOT)) != 0) {
 +  error = EINVAL;
 +  goto aqueue_fail;
 +  }
kqfd = aiocbe->uaiocb.aio_sigevent.sigev_notify_kqueue;
kev.ident = (uintptr_t)aiocbe->uuaiocb;
kev.filter = EVFILT_AIO;
 -  kev.flags = EV_ADD | EV_ENABLE | EV_FLAG1;
 +  kev.flags = EV_ADD | EV_ENABLE | EV_FLAG1 | evflags;
kev.data = (intptr_t)aiocbe;
kev.udata = aiocbe->uaiocb.aio_sigevent.sigev_value.sival_ptr;
error = kqfd_register(kqfd, &kev, td, 1);
 
 Modified: head/sys/sys/signal.h
 ==
 --- head/sys/sys/signal.h  Wed Feb  1 02:16:15 2012(r230856)
 +++ head/sys/sys/signal.h  Wed Feb  1 02:53:06 2012(r230857)
 @@ -169,12 +169,14 @@ struct sigevent {
void (*_function)(union sigval);
void *_attribute; /* pthread_attr_t * */
} _sigev_thread;
 +  unsigned short _kevent_flags;
long __spare__[8];
} _sigev_un;
  };
  
  #if __BSD_VISIBLE
  #define   sigev_notify_kqueue sigev_signo
 +#define   sigev_notify_kevent_flags   _sigev_un._kevent_flags
  #define   sigev_notify_thread_id  _sigev_un._threadid
  #endif
  #define   sigev_notify_function   
_sigev_un._sigev_thread._function
 ___
 svn-src-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
 
___
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"

kern/164684: [kern][patch] Zero out dynamically allocated sbufs

2012-01-31 Thread Yuri Pankov 

>Number: 164684
>Category:   kern
>Synopsis:   [kern][patch] Zero out dynamically allocated sbufs
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Feb 01 06:30:14 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Yuri Pankov
>Release:FreeBSD 10.0-CURRENT amd64
>Organization:
>Environment:
System: FreeBSD sirius.xvoid.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r230537: 
Wed Jan 25 16:28:58 MSK 2012 
y...@sirius.xvoid.org:/usr/obj/data/src/freebsd/head/sys/GENERIC amd64
>Description:
Filing this against kernel (as the source is in sys/kern), but got the problem 
itself using libsbuf - sbuf_newbuf() and sbuf_extend() don't zero out the 
malloc'ed memory, leading to issues when malloc debugging is enabled.
>How-To-Repeat:
#include 
#include 

#include 

int
main(void)
{
struct sbuf *sb = sbuf_new_auto();

sbuf_cat(sb, "TEST TEST");

printf("s_buf=%s\n", sbuf_data(sb));

return(0);
}


$ MALLOC_OPTIONS=J ./sbuf
s_buf=TEST TEST▒▒▒▒▒▒▒
$ MALLOC_OPTIONS=j ./sbuf
s_buf=TEST TEST
>Fix:
--- sbuf-dynamic.diff begins here ---
Index: sys/kern/subr_sbuf.c
===
--- sys/kern/subr_sbuf.c(revision 230853)
+++ sys/kern/subr_sbuf.c(working copy)
@@ -159,6 +159,7 @@
newbuf = SBMALLOC(newsize);
if (newbuf == NULL)
return (-1);
+   memset(newbuf, 0, newsize);
memcpy(newbuf, s->s_buf, s->s_size);
if (SBUF_ISDYNAMIC(s))
SBFREE(s->s_buf);
@@ -197,6 +198,7 @@
s->s_buf = SBMALLOC(s->s_size);
if (s->s_buf == NULL)
return (NULL);
+   memset(s->s_buf, 0, s->s_size);
SBUF_SETFLAG(s, SBUF_DYNAMIC);
return (s);
 }
--- sbuf-dynamic.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
___
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/164684: [kern][patch] Zero out dynamically allocated sbufs

2012-01-31 Thread Yuri Pankov 
The following reply was made to PR kern/164684; it has been noted by GNATS.

From: Yuri Pankov 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/164684: [kern][patch] Zero out dynamically allocated sbufs
Date: Wed, 1 Feb 2012 11:19:43 +0400

 The test code is obviously missing sbuf_finish. Please close the PR.
 
 
 Yuri
___
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/164684: [kern][patch] Zero out dynamically allocated sbufs

2012-01-31 Thread ae 
Synopsis: [kern][patch] Zero out dynamically allocated sbufs

State-Changed-From-To: open->closed
State-Changed-By: ae
State-Changed-When: Wed Feb 1 07:28:12 UTC 2012
State-Changed-Why: 
Not a bug.

http://www.freebsd.org/cgi/query-pr.cgi?pr=164684
___
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"