kern/152768: Weird check in mfi(4)
>Number: 152768 >Category: kern >Synopsis: Weird check in mfi(4) >Confidential: no >Severity: critical >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Dec 02 08:40:10 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Sascha Wildner >Release:none :) >Organization: >Environment: >Description: Hi there, I recently ported FreeBSD's mfi(4) driver to DragonFly BSD and when running clang's static analyzer on the kernel, it found: http://yoyodyne.ath.cx/tmp/scan-build-2010-12-01-1/report-tCmTHj.html#EndPath If device is T_DIRECT (0x00) or T_PROCESSOR (0x03) then (device & 0xe0) can't be true. It kinda smells like the intention was something different here, though I'm not sure which, so I thought I'd report it. Kind regards, Sascha >How-To-Repeat: >Fix: >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"
kern/152781: [patch] decode semget(2) flags in kdump(1)
>Number: 152781
>Category: kern
>Synopsis: [patch] decode semget(2) flags in kdump(1)
>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: Thu Dec 02 15:30:14 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Anton Yuzhaninov
>Release:FreeBSD 9.0-CURRENT i386
>Organization:
Openstat.ru
>Environment:
System: FreeBSD citrin.office.vega.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #2
r215543M: Mon Nov 22 19:38:30 MSK 2010
r...@citrin.office.vega.ru:/usr/obj/usr/src/sys/NK i386
>Description:
kdump(1) decode falgs in syscalls aguments, but decode not all semget(2) flags.
>How-To-Repeat:
1. Run code
semget(IPC_PRIVATE, 3, IPC_CREAT | IPC_EXCL | SEM_R | SEM_A);
semget(IPC_PRIVATE, 3, SEM_R | SEM_A);
under ktrace(1)
2.
> kdump -n | fgrep semget
87823 a.outCALL semget(0,0x3,0x780)
87823 a.outRET semget 0x6
87823 a.outCALL semget(0,0x3,0x180)
87823 a.outRET semget 0x30001
kdump -n show 2 semget(2) syscall with differend flags, all right.
> kdump | fgrep semget
87823 a.outCALL semget(0,0x3,SEM_R|SEM_A)
87823 a.outRET semget 393216/0x6
87823 a.outCALL semget(0,0x3,SEM_R|SEM_A)
87823 a.outRET semget 196609/0x30001
Whitout -n same flags shown - it is a bug.
Whith attached path correct flags shown:
> kdump | fgrep semget
87823 a.outCALL semget(0,0x3,IPC_CREAT|IPC_EXCL|SEM_R|SEM_A)
87823 a.outRET semget 393216/0x6
87823 a.outCALL semget(0,0x3,SEM_R|SEM_A)
87823 a.outRET semget 196609/0x30001
>Fix:
--- mksubr.patch begins here ---
Index: usr.bin/kdump/mksubr
===
--- usr.bin/kdump/mksubr(revision 216121)
+++ usr.bin/kdump/mksubr(working copy)
@@ -254,6 +254,8 @@
void
semgetname (int flag) {
int or = 0;
+ if_print_or(flag, IPC_CREAT, or);
+ if_print_or(flag, IPC_EXCL, or);
if_print_or(flag, SEM_R, or);
if_print_or(flag, SEM_A, or);
if_print_or(flag, (SEM_R>>3), or);
--- mksubr.patch 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/152768: [mfi] Weird check in mfi(4)
Old Synopsis: Weird check in mfi(4) New Synopsis: [mfi] Weird check in mfi(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 2 18:09:11 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=152768 ___ 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/152768: [mfi] Weird check in mfi(4)
Synopsis: [mfi] Weird check in mfi(4) Responsible-Changed-From-To: freebsd-net->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 2 18:09:40 UTC 2010 Responsible-Changed-Why: bah. too early in the morning, I guess. http://www.freebsd.org/cgi/query-pr.cgi?pr=152768 ___ 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/152781: commit references a PR
The following reply was made to PR kern/152781; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/152781: commit references a PR
Date: Thu, 2 Dec 2010 18:24:28 + (UTC)
Author: delphij
Date: Thu Dec 2 18:24:22 2010
New Revision: 216130
URL: http://svn.freebsd.org/changeset/base/216130
Log:
Decode IPC_CREAT and IPC_EXCL for semget(2).
PR: bin/152781
Submitted by:Anton Yuzhaninov
MFC after: 2 weeks
Modified:
head/usr.bin/kdump/mksubr
Modified: head/usr.bin/kdump/mksubr
==
--- head/usr.bin/kdump/mksubr Thu Dec 2 18:01:18 2010(r216129)
+++ head/usr.bin/kdump/mksubr Thu Dec 2 18:24:22 2010(r216130)
@@ -254,6 +254,8 @@ shmctlname (int cmd) {
void
semgetname (int flag) {
int or = 0;
+ if_print_or(flag, IPC_CREAT, or);
+ if_print_or(flag, IPC_EXCL, or);
if_print_or(flag, SEM_R, or);
if_print_or(flag, SEM_A, or);
if_print_or(flag, (SEM_R>>3), or);
___
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"
Re: kern/152768: [mfi] Weird check in mfi(4)
The following reply was made to PR kern/152768; it has been noted by GNATS.
From: John Baldwin
To: bug-follo...@freebsd.org,
s...@online.de
Cc: sco...@freebsd.org
Subject: Re: kern/152768: [mfi] Weird check in mfi(4)
Date: Thu, 2 Dec 2010 13:30:51 -0500
I think it should be 'ccb->csio.data_ptr[0] & 0xe0 | T_NODEVICE', or even
shorter would be to do this:
Index: mfi_cam.c
===
--- mfi_cam.c (revision 216122)
+++ mfi_cam.c (working copy)
@@ -340,14 +340,14 @@
ccbh->status = CAM_REQ_CMP;
csio->scsi_status = pt->header.scsi_status;
if (ccbh->flags & CAM_CDB_POINTER)
- command = ccb->csio.cdb_io.cdb_ptr[0];
+ command = csio->cdb_io.cdb_ptr[0];
else
- command = ccb->csio.cdb_io.cdb_bytes[0];
+ command = csio->cdb_io.cdb_bytes[0];
if (command == INQUIRY) {
- device = ccb->csio.data_ptr[0] & 0x1f;
+ device = csio->data_ptr[0] & 0x1f;
if ((device == T_DIRECT) || (device == T_PROCESSOR))
csio->data_ptr[0] =
- (device & 0xe0) | T_NODEVICE;
+ (csio->data_ptr[0] & 0xe0) | T_NODEVICE;
}
break;
}
The intention from the code seems to be to mask T_DIRECT and T_PROCESSOR
devices by mapping them to T_NODEVICE instead.
--
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: bin/152781: [patch] decode semget(2) flags in kdump(1)
Synopsis: [patch] decode semget(2) flags in kdump(1) State-Changed-From-To: open->patched State-Changed-By: delphij State-Changed-When: Thu Dec 2 18:43:10 UTC 2010 State-Changed-Why: Patch applied against -CURRENT, MFC reminder. Responsible-Changed-From-To: freebsd-bugs->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Thu Dec 2 18:43:10 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=152781 ___ 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/152673: [patch] find(1): correctly find empty dirs.
Synopsis: [patch] find(1): correctly find empty dirs. State-Changed-From-To: open->patched State-Changed-By: arundel State-Changed-When: Thu Dec 2 19:16:02 UTC 2010 State-Changed-Why: Fixed in HEAD (r216106). Responsible-Changed-From-To: freebsd-bugs->kevlo Responsible-Changed-By: arundel Responsible-Changed-When: Thu Dec 2 19:16:02 UTC 2010 Responsible-Changed-Why: Over to committer as MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=152673 ___ 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/152791: ND, ICMPv6 Redirect vs Destination Cache failed in release 8.0
>Number: 152791 >Category: kern >Synopsis: ND, ICMPv6 Redirect vs Destination Cache failed in release 8.0 >Confidential: no >Severity: serious >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Dec 02 20:40:07 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Ted Sun >Release:FreeBSD 8.0-RELEASE i386 >Organization: Datatek >Environment: FreeBSD fosters.datatekcorp.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Sep 9 14:52:35 EDT 2010 r...@fosters.datatekcorp.com:/usr/obj/usr/src/sys/MYKERNEL i386 >Description: The running OS is a 8.0-RELEASE FreeBSD with the IP-SEC support on. Output of command "diff -U5 GENERIC MYKERNEL" at /usr/src/sys/i386/conf shows - --- GENERIC 2009-11-09 18:48:01.0 -0500 +++ MYKERNEL2010-09-09 13:15:51.0 -0400 @@ -330,5 +330,9 @@ #devicesbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip# IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons + +#arndt added- IP-SEC support +device crypto +optionsIPSEC - After receiving an ICMPv6 redirect package with Option ICMPv6_TLL which contains TargetAddress == DestinationAddress == 3ffe:501:fff:109:200:ff:fe00:1c5. The "ndp -a" will output a corresponding entry as "3ffe:501:fff:109:200:ff:fe00:1c5 0:0:0:0:a9:a9vr0 23h58m38s S" But the FreeBSD will continue to echo reply to the old MAC address 0:0:0:0:a0:a0 for IPv6 destination 3ffe:501:fff:109:200:ff:fe00:1c5 The correct echo reply should use the redirected MAC address 0:0:0:0:a9:a9. >How-To-Repeat: Needed test tool are the "IPv6 Conformance Test Tool v6eval-3.0.12.tar.gz or newer one" and the "ct-2.1.1.tar.gz" from "http://www.tahi.org/release";. Set up the TAHI "IPv6 conformance Test For Neighbor discovery" on a BSD machine. Set up a IP-SEC enabled BSD 8.0 release PC as the NUT (node under test). Cross connect the TAHI and the NUT with ethernet cable. 1. Start the TAHI test by "make test". Test will fail at item 66 "Redirect vs Destination Cache; Redirect to a host" should fail. or .. 2. Start the TAHI test of item 66 only by "make AROPT='-s 66 -e 66' test". >Fix: >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/152741: [lor] vfs_bio.c / ufs_dirhash.c
Synopsis: [lor] vfs_bio.c / ufs_dirhash.c State-Changed-From-To: open->closed State-Changed-By: jh State-Changed-When: Thu Dec 2 20:45:13 UTC 2010 State-Changed-Why: Duplicate of kern/137852. http://www.freebsd.org/cgi/query-pr.cgi?pr=152741 ___ 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/145078: [install] [panic] "panic: page fault" and continue writing to disk
Synopsis: [install] [panic] "panic: page fault" and continue writing to disk State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Thu Dec 2 20:54:47 UTC 2010 State-Changed-Why: Note that submitter has been asked for feedback. http://www.freebsd.org/cgi/query-pr.cgi?pr=145078 ___ 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/77091: [keyboard] Keyboard quits working under X with MAXCONS kernel option.
Synopsis: [keyboard] Keyboard quits working under X with MAXCONS kernel option. State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Thu Dec 2 21:00:44 UTC 2010 State-Changed-Why: Feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=77091 ___ 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/152792: [patch] move temperature conversion macros to a common header
>Number: 152792
>Category: kern
>Synopsis: [patch] move temperature conversion macros to a common header
>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: Thu Dec 02 21:10:09 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Mark Johnston
>Release:
>Organization:
Sandvine Inc.
>Environment:
>Description:
There are a few drivers that report system temperatures through sysctls using
the "IK" format. This format expects values that are converted into multiples
of 0.1 degrees Kelvin, and since most sensors report values in Celsius, they
have to be converted. The drivers (acpi, coretemp and amdtemp) all have their
own macros for doing this. This change puts a set of macros in sysctl.h for all
drivers to use; moreover, they allow userspace programs to read temperature
sysctls without having to redefine the macros yet again.
>How-To-Repeat:
>Fix:
Attached is a patch against HEAD (csup'ed about 2 days ago).
Patch attached with submission follows:
diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/dev/acpica/acpi_thermal.c
index ec4178e..f3a283c 100644
--- a/sys/dev/acpica/acpi_thermal.c
+++ b/sys/dev/acpica/acpi_thermal.c
@@ -54,9 +54,6 @@ __FBSDID("$FreeBSD: src/sys/dev/acpica/acpi_thermal.c,v 1.74
2010/06/11 19:27:21
#define _COMPONENT ACPI_THERMAL
ACPI_MODULE_NAME("THERMAL")
-#define TZ_ZEROC 2732
-#define TZ_KELVTOC(x) (((x) - TZ_ZEROC) / 10), abs(((x) - TZ_ZEROC) % 10)
-
#define TZ_NOTIFY_TEMPERATURE 0x80 /* Temperature changed. */
#define TZ_NOTIFY_LEVELS 0x81 /* Cooling levels changed. */
#define TZ_NOTIFY_DEVICES 0x82 /* Device lists changed. */
diff --git a/sys/dev/amdtemp/amdtemp.c b/sys/dev/amdtemp/amdtemp.c
index 8ba46c7..0220b54 100644
--- a/sys/dev/amdtemp/amdtemp.c
+++ b/sys/dev/amdtemp/amdtemp.c
@@ -433,8 +433,6 @@ amdtemp_sysctl(SYSCTL_HANDLER_ARGS)
return (error);
}
-#defineAMDTEMP_ZERO_C_TO_K 2732
-
static int32_t
amdtemp_gettemp0f(device_t dev, amdsensor_t sensor)
{
@@ -468,7 +466,7 @@ amdtemp_gettemp0f(device_t dev, amdsensor_t sensor)
pci_write_config(dev, AMDTEMP_THERMTP_STAT, cfg | sel, 1);
/* CurTmp starts from -49C. */
- offset = AMDTEMP_ZERO_C_TO_K - 490;
+ offset = TZ_ZEROC - 490;
/* Adjust offset if DiodeOffset is set and valid. */
temp = pci_read_config(dev, AMDTEMP_THERMTP_STAT, 4);
@@ -497,7 +495,7 @@ amdtemp_gettemp(device_t dev, amdsensor_t sensor)
int32_t diode_offset, offset;
/* CurTmp starts from 0C. */
- offset = AMDTEMP_ZERO_C_TO_K;
+ offset = TZ_ZEROC;
/* Adjust offset if DiodeOffset is set and valid. */
temp = pci_read_config(dev, AMDTEMP_THERMTP_STAT, 4);
diff --git a/sys/dev/coretemp/coretemp.c b/sys/dev/coretemp/coretemp.c
index 7cfc9c6..cb26b1b 100644
--- a/sys/dev/coretemp/coretemp.c
+++ b/sys/dev/coretemp/coretemp.c
@@ -48,8 +48,6 @@ __FBSDID("$FreeBSD: src/sys/dev/coretemp/coretemp.c,v 1.12
2010/08/04 00:25:13 d
#include
#include
-#defineTZ_ZEROC2732
-
struct coretemp_softc {
device_tsc_dev;
int sc_tjmax;
@@ -331,7 +329,7 @@ coretemp_get_temp_sysctl(SYSCTL_HANDLER_ARGS)
device_t dev = (device_t) arg1;
int temp;
- temp = coretemp_get_temp(dev) * 10 + TZ_ZEROC;
+ temp = TZ_CEL_TO_KEL(coretemp_get_temp(dev));
return (sysctl_handle_int(oidp, &temp, 0, req));
}
diff --git a/sys/sys/sysctl.h b/sys/sys/sysctl.h
index eae9c10..3ffccf9 100644
--- a/sys/sys/sysctl.h
+++ b/sys/sys/sysctl.h
@@ -114,6 +114,19 @@ struct ctlname {
*/
#define CTL_AUTO_START 0x100
+/*
+ * Conversion between Celsius and Kelvin, for drivers that want to
+ * display a temperature reading through a sysctl. The IK sysctl format
+ * expects a value that's converted into multiples of 0.1 degrees Kelvin,
+ * so one multiplies a celsius reading by 10 and adds TZ_ZEROC to get the
+ * correct value.
+ */
+#define TZ_ZEROC 2732
+#define TZ_CTOKELV(x) ((x) * 10 + TZ_ZEROC)
+#define TZ_KELVTOC_INT(x) (((x) - TZ_ZEROC) / 10)
+#define TZ_KELVTOC_FRAC(x) abs(((x) - TZ_ZEROC) % 10)
+#define TZ_KELVTOC(x) TZ_KELVTOC_INT(x), TZ_KELVTOC_FRAC(x)
+
#ifdef _KERNEL
#define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, int arg2, \
struct sysctl_req *req
>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"
misc/152795: Remove old KDE_ORIGVER
>Number: 152795
>Category: misc
>Synopsis: Remove old KDE_ORIGVER
>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: Thu Dec 02 23:10:05 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Eitan Adler
>Release:
>Organization:
>Environment:
>Description:
There is a variable set in bsd.kde.mk that is not used anywhere in the ports
tree
>How-To-Repeat:
#grep -R "ORIGVER" ..
./Mk/bsd.kde.mk:KDE_ORIGVER=${KDE_VERSION}
./Tools/scripts/portsvar.sh:# KDE_ORIGVER = ${KDE_VERSION}
>Fix:
Index: Mk/bsd.kde.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.kde.mk,v
retrieving revision 1.81
diff -u -r1.81 bsd.kde.mk
--- Mk/bsd.kde.mk 11 Jun 2009 09:09:28 - 1.81
+++ Mk/bsd.kde.mk 2 Dec 2010 22:58:11 -
@@ -101,7 +101,6 @@
# Yeah, it's namespace pollution, but this is really the best place for this
# stuff. Arts does NOT use it anymore.
KDE_VERSION= 3.5.10
-KDE_ORIGVER= ${KDE_VERSION}
KDE_PREFIX?= ${LOCALBASE}
QTCPPFLAGS?=
cvs diff: Diffing Tools/scripts
Index: Tools/scripts/portsvar.sh
===
RCS file: /home/ncvs/ports/Tools/scripts/portsvar.sh,v
retrieving revision 1.1
diff -u -r1.1 portsvar.sh
--- Tools/scripts/portsvar.sh 11 Jan 2006 07:06:51 - 1.1
+++ Tools/scripts/portsvar.sh 2 Dec 2010 22:58:11 -
@@ -18,7 +18,6 @@
# RUBY_ARCH = i386-freebsd6
# % portsvar.sh -w kde -e KDE_
# KDE_MAINTAINER = w...@freebsd.org
-# KDE_ORIGVER = ${KDE_VERSION}
# KDE_PREFIX = ${LOCALBASE}
# KDE_VERSION = 3.5.0
# MASTER_SITE_KDE_kde = ${kmaster:s...@%subdir%/@@g}
>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"
kern/152796: fcntl(2) audit records should not be labeled "file attribute modify"
>Number: 152796 >Category: kern >Synopsis: fcntl(2) audit records should not be labeled "file attribute >modify" >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: Fri Dec 03 00:10:11 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Garrett Wollman >Release:FreeBSD 8.1-RELEASE-p2 amd64 >Organization: MIT Computer Science & Artificial Intelligence Lab >Environment: 8.1 system with auditing turned on >Description: /etc/security/audit_class describes class 0x8 as "file attribute modify". This seems like a reasonable thing to audit, but unfortunately, all calls to fcntl(2) -- which does not modify any file attributes -- are included in this category. Any program which uses POSIX-style locking will flood the audit file with spurious audit records, while the interesting system calls (those that call VOP_SETATTR) will be buried. (And for whatever reason, auditreduce(1) deosn't appear to perform as advertised when given the "-v" flag.) >How-To-Repeat: Enable auditing with class "fm". praudit /var/audit/current. Hit ^C when all you see is "fcntl(2)". >Fix: Move fcntl to a different audit class (probably "other" or maybe "ioctl"). >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/152796: fcntl(2) audit records should not be labeled "file attribute modify"
The following reply was made to PR kern/152796; it has been noted by GNATS. From: jhell To: Garrett Wollman Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: kern/152796: fcntl(2) audit records should not be labeled "file attribute modify" Date: Thu, 02 Dec 2010 23:06:29 -0500 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2010 18:43, Garrett Wollman wrote: >> Number: 152796 >> Category: kern >> Synopsis: fcntl(2) audit records should not be labeled "file >> attribute modify" >> 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: Fri Dec 03 00:10:11 UTC 2010 >> Closed-Date: >> Last-Modified: >> Originator: Garrett Wollman >> Release:FreeBSD 8.1-RELEASE-p2 amd64 >> Organization: > MIT Computer Science & Artificial Intelligence Lab >> Environment: > > 8.1 system with auditing turned on > >> Description: > > /etc/security/audit_class describes class 0x8 as "file > attribute modify". This seems like a reasonable thing to audit, but > unfortunately, all calls to fcntl(2) -- which does not modify any file > attributes -- are included in this category. Any program which uses > POSIX-style locking will flood the audit file with spurious audit > records, while the interesting system calls (those that call > VOP_SETATTR) will be buried. (And for whatever reason, auditreduce(1) > deosn't appear to perform as advertised when given the "-v" flag.) > >> How-To-Repeat: > > Enable auditing with class "fm". praudit /var/audit/current. > Hit ^C when all you see is "fcntl(2)". > >> Fix: > > Move fcntl to a different audit class (probably "other" or > maybe "ioctl"). > > > To give a little background with this issue, I had addressed once with Robert, > On Sat, 6 Feb 2010 11:15, sson@ wrote: >> >> On Feb 6, 2010, at 6:48 AM, Robert N. M. Watson wrote: >> >>> >>> On 5 Feb 2010, at 05:28, jhell wrote: >>> I just wanted to run this by you quick informally before I approach any work on audit and changing things around that will never get changed possibly due to strict standards. I was setting up audit on a stable/7 remote booting X machine and wanted to audit any chmod's chflags etc... after final configuration I noticed that fcntl(2) is also included in the "fm" class but had noticed that ioctl(2) has its own class "io". So in my case on a Xserver I get high amounts of fcntl(2) changes logged. I would say at a guess of at the very least 1000 every 5 seconds. The machines these modifications are intended to be placed across are up constantly all week long. Being that these are file descriptors do you think it would possible to change them around and give fcntl(2) its own class "ds" or something similar ? What do you think would be the best way to approach this matter to bring fcntl(2) into its own class ?. >>> >>> Well, I'd be a little worried about using up too many bits, the >>> class mask size is fixed in the ABI and difficult to expand. >>> Perhaps what we should do is move to a group named 'ct' or >>> something to reflect control calls, and put both fcntl and ioctl >>> in that? Christian and Stacey added the CC line as they may have >>> thoughts on this as well. One problem with ioctl, of course, is >>> that some ioctls are queries on pending bytes to sockets and >>> ttys, and others are administrative commands :-). >> > > I agree moving these to something like "ct" would be considerably an > advantage over the current state that they are in. I'm starting to > find that the more I delve into this the more twists and turns I am > coming across as you have pointed out the limits on the mask size > etc. :( > > What this is starting to make me think about is a way that the admin > could control certain aspects of audit. Something like the > audit_control file but only to turn off certain events either > specified by field 1 or 2 in audit_events and then by user or group. > Example idea below. > /etc/security/audit_event_control # (none) Record both successful and failed events. # + Record successful events. # - Record failed events. # ^ Record neither successful nor failed events. # ^+ Do not record successful events. # ^- Do not record failed events. > > # Field 1 event number, field 2 group spec, field 3 user spec # I put > them in this order since the effect of adding groups # could allow > the user field to be omitted entirely if the admin # has no users > he/she wants to specify. > > # Do not audit fcntl events
Re: kern/133583: [libm] fma(3) does not respect rounding mode using extended precision
Synopsis: [libm] fma(3) does not respect rounding mode using extended precision State-Changed-From-To: open->closed State-Changed-By: das State-Changed-When: Fri Dec 3 07:01:28 UTC 2010 State-Changed-Why: Thanks for the report! This limitation is described in the source for fma(), and unfortunately, it is unlikely to ever change. There are several reasons: - We are a long way from having the necessary compiler support to make dynamic precision changes work as expected. - Dynamic FPU precision changes aren't officially supported, and fpsetprec() has been documented as deprecated for many years. - The only supported architecture that can have this problem due to dynamic precision changes is i386, and even then only for non-SSE2 builds. - The cost and complexity associated with making every function in libm detect and adapt to dynamic precision changes is prohibitive. I have updated the manpage for fpsetprec() to explain that changing the FPU precision isn't supported by the compiler or libraries. http://www.freebsd.org/cgi/query-pr.cgi?pr=133583 ___ 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/133583: commit references a PR
The following reply was made to PR kern/133583; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: kern/133583: commit references a PR Date: Fri, 3 Dec 2010 07:01:14 + (UTC) Author: das Date: Fri Dec 3 07:01:07 2010 New Revision: 216142 URL: http://svn.freebsd.org/changeset/base/216142 Log: Explain some of the reasons that fpsetprec() is unlikely to work as one might expect. (These functions have already been deprecated for many years.) PR: 133583 Modified: head/share/man/man3/fpgetround.3 Modified: head/share/man/man3/fpgetround.3 == --- head/share/man/man3/fpgetround.3 Fri Dec 3 04:39:48 2010 (r216141) +++ head/share/man/man3/fpgetround.3 Fri Dec 3 07:01:07 2010 (r216142) @@ -32,7 +32,7 @@ .\" @(#)fpgetround.3 1.0 (Berkeley) 9/23/93 .\" $FreeBSD$ .\" -.Dd August 23, 1993 +.Dd December 3, 2010 .Dt FPGETROUND 3 .Os .Sh NAME @@ -164,6 +164,10 @@ and .Fn fpsetprec functions provide functionality unavailable on many platforms. At present, they are implemented only on the i386 and amd64 platforms. +Changing precision isn't a supported feature: +it may be ineffective when code is compiled to take advantage of SSE, +and many library functions and compiler optimizations depend upon the +default precision for correct behavior. .Sh SEE ALSO .Xr fenv 3 , .Xr isnan 3 ___ 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"
