Re: svn commit: r264269 - in head: sys/conf sys/kern sys/modules sys/modules/imgact_binmisc sys/sys usr.sbin usr.sbin/binmiscctl
+--On 8 avril 2014 20:10:22 + Sean Bruno wrote: | Log: | Add Stacey Son's binary activation patches that allow remapping of | execution to a emumation program via parsing of ELF header information. Can you MFC that to stable/10 one day ? -- Mathieu Arnold ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264269 - in head: sys/conf sys/kern sys/modules sys/modules/imgact_binmisc sys/sys usr.sbin usr.sbin/binmiscctl
On Tue, Apr 08, 2014 at 03:01:49PM -0700, Sean Bruno wrote: > I haven't tested on non-x86 h/w and have no idea if it works or not. I > didn't feel comfortable building this driver in the non-x86 case. If > there is a use case/tester for the other arch's, I'll be more than happy > to change this. I'd like to test it on PowerPC. Is there quick start guide available with some examples of usage? ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264295 - in head: share/man/man4 sys/cam/scsi
Author: mav Date: Wed Apr 9 08:57:57 2014 New Revision: 264295 URL: http://svnweb.freebsd.org/changeset/base/264295 Log: Remove support of LUN-based CD changers from cd(4) driver. This code was heavily broken few months ago during CAM locking changes. Fixing it would require almost complete rewrite. Since there are no known devices on market using this interface younger then ~15 years, and they are CD, not even DVD, I don't see much reason to rewrite it. This change does not mean those devices won't work. They will just work slower due to inefficient disks load/unload schedule if several LUNs accessed same time. Discussed with: ken@ Silence on: scsi@, hardware@ MFC after:1 week Modified: head/share/man/man4/cd.4 head/sys/cam/scsi/scsi_cd.c Modified: head/share/man/man4/cd.4 == --- head/share/man/man4/cd.4Wed Apr 9 06:27:04 2014(r264294) +++ head/share/man/man4/cd.4Wed Apr 9 08:57:57 2014(r264295) @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 8, 2012 +.Dd April 9, 2014 .Dt CD 4 .Os .Sh NAME @@ -33,8 +33,6 @@ .Nd SCSI CD-ROM driver .Sh SYNOPSIS .Cd device cd -.Cd "options ""CHANGER_MIN_BUSY_SECONDS=3""" -.Cd "options ""CHANGER_MAX_BUSY_SECONDS=11""" .Sh DESCRIPTION The .Nm @@ -288,65 +286,6 @@ Some work is planned to support some of the more common `broken' .Tn CD-ROM drives; however, this is not yet under way. -.Sh CHANGER OPERATION -This driver has built-in support for LUN-based CD changers. -A LUN-based CD -changer is a drive that can hold two or more CDs, but only has one CD -player mechanism. -Each CD in the drive shows up as a separate logical unit -on the -.Tn SCSI -bus. -The -.Nm -driver automatically recognizes LUN-based changers, and routes commands for -changers through an internal scheduler. -The scheduler prevents changer -"thrashing", which is caused by sending commands to different LUNs in the -changer at the same time. -.Pp -The scheduler honors minimum and maximum time -quanta that the driver will spend on a particular LUN. -The minimum time -is the guaranteed minimum amount of time that the driver will spend on a -given LUN, even if there is no outstanding I/O for that LUN. -The maximum -time is the maximum amount of time the changer will spend on a LUN if there -is outstanding I/O for another LUN. -If there is no outstanding I/O for -another LUN, the driver will allow indefinite access to a given LUN. -.Pp -The minimum and maximum time quanta are configurable via kernel options and -also via sysctl and kernel tunable variables. -The kernel options are: -.Pp -.Bl -item -compact -.It -.Cd "options ""CHANGER_MIN_BUSY_SECONDS=3""" -.It -.Cd "options ""CHANGER_MAX_BUSY_SECONDS=11""" -.El -.Pp -The sysctl/kernel tunable variables are: -.Pp -.Bl -item -compact -.It -.Va kern.cam.cd.changer.min_busy_seconds -.It -.Va kern.cam.cd.changer.max_busy_seconds -.El -.Pp -It is suggested that the user try experimenting with the minimum and -maximum timeouts via the sysctl variables to arrive at the proper values -for your changer. -Once you have settled on the proper timeouts for your -changer, you can then put them in your kernel config file. -.Pp -If your system does have a LUN-based changer, you may notice that the -probe messages for the various LUNs of the changer will continue to appear -while the boot process is going on. -This is normal, and is caused by the -changer scheduling code. .Sh SYSCTL VARIABLES The following variables are available as both .Xr sysctl 8 @@ -397,12 +336,6 @@ Valid minimum command sizes are 6 and 10. Any value above 6 will be rounded to 10, and any value below 6 will be rounded to 6. -.It kern.cam.cd.changer.min_busy_seconds -.It kern.cam.cd.changer.max_busy_seconds -.Pp -Tune how long individual LUNs are 'locked' for I/O operations to -optimize changer operation. -See CHANGER OPERATION section for information on how to use these items. .El .Sh FILES .Bl -tag -width /dev/cd[0-9][a-h] -compact @@ -437,21 +370,3 @@ were poorly chosen, and a number of spel the names of the .Fn ioctl commands. -.Pp -There is no mechanism currently to set different minimum and maximum -timeouts for different CD changers; the timeout values set by the kernel -options or the sysctl variables apply to all LUN-based CD changers in the -system. -It is possible to implement such support, but the sysctl -implementation at least would be rather inelegant, because of the current -inability of the sysctl code to handle the addition of nodes after compile -time. -Thus, it would take one dynamically sized sysctl variable and a -userland utility to get/set the timeout values. -Implementation of separate -timeouts for different CD devices in the kernel config file would likely -require modification of -.Xr config 8 -to support the two timeouts when hardwiring -.Nm -devices. Modified: head/sys/cam/scsi/scsi_cd.c ==
svn commit: r264296 - head/sys/cam/ctl
Author: mav
Date: Wed Apr 9 10:44:09 2014
New Revision: 264296
URL: http://svnweb.freebsd.org/changeset/base/264296
Log:
When splitting huge unmap requests, do it on sector boundary.
Modified:
head/sys/cam/ctl/ctl_backend_block.c
Modified: head/sys/cam/ctl/ctl_backend_block.c
==
--- head/sys/cam/ctl/ctl_backend_block.cWed Apr 9 08:57:57 2014
(r264295)
+++ head/sys/cam/ctl/ctl_backend_block.cWed Apr 9 10:44:09 2014
(r264296)
@@ -766,19 +766,21 @@ ctl_be_block_unmap_dev_range(struct ctl_
{
struct bio *bio;
struct ctl_be_block_devdata *dev_data;
+ uint64_t maxlen;
dev_data = &be_lun->backend.dev;
+ maxlen = LONG_MAX - (LONG_MAX % be_lun->blocksize);
while (len > 0) {
bio = g_alloc_bio();
bio->bio_cmd= BIO_DELETE;
bio->bio_flags |= beio->bio_flags;
bio->bio_dev= dev_data->cdev;
bio->bio_offset = off;
- bio->bio_length = MIN(len, LONG_MAX);
+ bio->bio_length = MIN(len, maxlen);
bio->bio_data = 0;
bio->bio_done = ctl_be_block_biodone;
bio->bio_caller1= beio;
- bio->bio_pblkno = beio->io_offset / be_lun->blocksize;
+ bio->bio_pblkno = off / be_lun->blocksize;
off += bio->bio_length;
len -= bio->bio_length;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264297 - head/sys/cam/ctl
Author: mav
Date: Wed Apr 9 10:58:52 2014
New Revision: 264297
URL: http://svnweb.freebsd.org/changeset/base/264297
Log:
Introduce new serialization type CTL_SERIDX_UNMAP.
Unfortunately we can't check range collisions for UNMAP commands alike
to writes, because they include multiple ranges, which are also passed
in data block, not in CDB. As result, UNMAP commands have to be treated
as colliding with any other command accessing the media.
From the other side all UNMAPs are equal (we don't support ANCHOR flag),
so we can execute several UNMAPs same time.
Modified:
head/sys/cam/ctl/ctl_cmd_table.c
head/sys/cam/ctl/ctl_private.h
head/sys/cam/ctl/ctl_ser_table.c
Modified: head/sys/cam/ctl/ctl_cmd_table.c
==
--- head/sys/cam/ctl/ctl_cmd_table.cWed Apr 9 10:44:09 2014
(r264296)
+++ head/sys/cam/ctl/ctl_cmd_table.cWed Apr 9 10:58:52 2014
(r264297)
@@ -336,7 +336,7 @@ struct ctl_cmd_entry ctl_cmd_table[] =
CTL_LUN_PAT_WRITE | CTL_LUN_PAT_RANGE},
/* 42 READ SUB-CHANNEL / UNMAP */
-{ctl_unmap, CTL_SERIDX_WRITE, CTL_CMD_FLAG_OK_ON_SLUN | CTL_FLAG_DATA_OUT,
+{ctl_unmap, CTL_SERIDX_UNMAP, CTL_CMD_FLAG_OK_ON_SLUN | CTL_FLAG_DATA_OUT,
CTL_LUN_PAT_WRITE},
/* 43 READ TOC/PMA/ATIP */
Modified: head/sys/cam/ctl/ctl_private.h
==
--- head/sys/cam/ctl/ctl_private.h Wed Apr 9 10:44:09 2014
(r264296)
+++ head/sys/cam/ctl/ctl_private.h Wed Apr 9 10:58:52 2014
(r264297)
@@ -156,6 +156,7 @@ typedef enum {
CTL_SERIDX_TUR = 0,
CTL_SERIDX_READ,
CTL_SERIDX_WRITE,
+ CTL_SERIDX_UNMAP,
CTL_SERIDX_MD_SNS,
CTL_SERIDX_MD_SEL,
CTL_SERIDX_RQ_SNS,
Modified: head/sys/cam/ctl/ctl_ser_table.c
==
--- head/sys/cam/ctl/ctl_ser_table.cWed Apr 9 10:44:09 2014
(r264296)
+++ head/sys/cam/ctl/ctl_ser_table.cWed Apr 9 10:58:52 2014
(r264297)
@@ -60,22 +60,23 @@
static ctl_serialize_action
ctl_serialize_table[CTL_SERIDX_COUNT][CTL_SERIDX_COUNT] = {
-/**>IDX_ :: 2nd:TUR RD WRT MDSN MDSL RQSN INQ RDCP RES REL LSNS FMT STR
PRIN PROT MAININ*/
-/*TUR */{ pS, pS, pS, bK, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
-/*READ*/{ pS, pS, xT, bK, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
-/*WRITE */{ pS, xT, xT, bK, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
-/*MD_SNS */{ bK, bK, bK, pS, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
-/*MD_SEL */{ bK, bK, bK, bK, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
-/*RQ_SNS */{ pS, pS, pS, pS, pS, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
-/*INQ */{ pS, pS, pS, pS, pS, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
-/*RD_CAP */{ pS, pS, pS, pS, pS, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
-/*RESV*/{ bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK,
bK, bK, bK},
-/*REL */{ bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK,
bK, bK, bK},
-/*LOG_SNS */{ pS, pS, pS, pS, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
-/*FORMAT */{ pS, bK, bK, bK, bK, pS, pS, bK, bK, bK, bK, bK, bK,
bK, bK, bK},
-/*START */{ bK, bK, bK, bK, bK, bK, pS, bK, bK, bK, bK, bK, bK,
bK, bK, bK},
-/*PRES_IN */{ bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK,
bK, bK, bK},
-/*PRES_OUT*/{ bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK,
bK, bK, bK},
-/*MAIN_IN */{ bK, bK, bK, bK, bK, bK, pS, bK, bK, bK, bK, bK, bK,
bK, bK, pS}
+/**>IDX_ :: 2nd:TUR RD WRT UNM MDSN MDSL RQSN INQ RDCP RES REL LSNS FMT STR
PRIN PROT MAININ*/
+/*TUR */{ pS, pS, pS, pS, bK, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
+/*READ*/{ pS, pS, xT, bK, bK, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
+/*WRITE */{ pS, xT, xT, bK, bK, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
+/*UNMAP */{ pS, bK, bK, pS, bK, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
+/*MD_SNS */{ bK, bK, bK, bK, pS, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
+/*MD_SEL */{ bK, bK, bK, bK, bK, bK, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
+/*RQ_SNS */{ pS, pS, pS, pS, pS, pS, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
+/*INQ */{ pS, pS, pS, pS, pS, pS, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
+/*RD_CAP */{ pS, pS, pS, pS, pS, pS, bK, pS, pS, bK, bK, pS, bK, bK,
bK, bK, bK},
+/*RESV*/{ bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK,
bK, bK, bK},
+/*REL */{ bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK, bK,
bK, bK, bK},
+/*LOG_SNS */{ pS, pS, pS, pS, pS, bK, bK
Re: svn commit: r264265 - in head: crypto/openssl/crypto/bn crypto/openssl/crypto/ec crypto/openssl/ssl sys/fs/nfsserver
Bryan Drewery writes: > Also, that this was a partial release of 1.0.1g is confusing a LOT of > users. They think they are still vulnerable. They expect to see 1.0.1g > in 'openssl version'. We could have our own version string in 'openssl > version' to remedy this. This is no different from what other OSes do, e.g. RHEL6.5: % cat /etc/redhat-release Red Hat Enterprise Linux Workstation release 6.5 (Santiago) % openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 % TZ=UTC rpm -qi openssl Name: openssl Relocations: (not relocatable) Version : 1.0.1eVendor: Red Hat, Inc. Release : 16.el6_5.7Build Date: Mon 07 Apr 2014 11:34:45 AM UTC Install Date: Tue 08 Apr 2014 05:18:52 AM UTC Build Host: x86-027.build.eng.bos.redhat.com [...] which despite the version number and date is *not* vulnerable. DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264265 - in head: crypto/openssl/crypto/bn crypto/openssl/crypto/ec crypto/openssl/ssl sys/fs/nfsserver
On 10/04/2014 12:01 AM, Dag-Erling Smørgrav wrote: > Bryan Drewery writes: >> Also, that this was a partial release of 1.0.1g is confusing a LOT of >> users. They think they are still vulnerable. They expect to see 1.0.1g >> in 'openssl version'. We could have our own version string in 'openssl >> version' to remedy this. > > This is no different from what other OSes do, e.g. RHEL6.5: > > % cat /etc/redhat-release > Red Hat Enterprise Linux Workstation release 6.5 (Santiago) > % openssl version > OpenSSL 1.0.1e-fips 11 Feb 2013 > % TZ=UTC rpm -qi openssl > Name: openssl Relocations: (not relocatable) > Version : 1.0.1eVendor: Red Hat, Inc. > Release : 16.el6_5.7Build Date: Mon 07 Apr 2014 > 11:34:45 AM UTC > Install Date: Tue 08 Apr 2014 05:18:52 AM UTC Build Host: > x86-027.build.eng.bos.redhat.com > [...] > > which despite the version number and date is *not* vulnerable. > > DES > More precisely, users expect *not* to see 1.0.1e That expectation is orthogonal to whether we or other projects do it one way or another. RHEL users may well be as confused as ours (whether of not ours are). It may be relevant as a data point, but not for decision making. Whether its just 1.0.1e, a full 1.0.1g, e+foo, or additional meta obviously matters, but it's not as important as distinguishing 'what we want' with how we're going to do it and why. I'll give it a crack: "Our users can quickly and clearly see and know, on the system, when a vendored library or piece of software in base is patched, or partially updated to account for bugs or security vulnerabilities in a supported version of FreeBSD" ./koobs ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264302 - head/usr.sbin/bhyve
Author: tychon
Date: Wed Apr 9 14:50:55 2014
New Revision: 264302
URL: http://svnweb.freebsd.org/changeset/base/264302
Log:
Constrain the amount of data returned to what is actually available
not the size of the buffer.
Approved by: grehan (co-mentor)
Modified:
head/usr.sbin/bhyve/pci_ahci.c
Modified: head/usr.sbin/bhyve/pci_ahci.c
==
--- head/usr.sbin/bhyve/pci_ahci.c Wed Apr 9 13:35:52 2014
(r264301)
+++ head/usr.sbin/bhyve/pci_ahci.c Wed Apr 9 14:50:55 2014
(r264302)
@@ -543,12 +543,14 @@ write_prdt(struct ahci_port *p, int slot
for (i = 0; i < hdr->prdtl && len; i++) {
uint8_t *ptr;
uint32_t dbcsz;
+ int sublen;
dbcsz = (prdt->dbc & DBCMASK) + 1;
ptr = paddr_guest2host(ahci_ctx(p->pr_sc), prdt->dba, dbcsz);
- memcpy(ptr, from, dbcsz);
- len -= dbcsz;
- from += dbcsz;
+ sublen = len < dbcsz ? len : dbcsz;
+ memcpy(ptr, from, sublen);
+ len -= sublen;
+ from += sublen;
prdt++;
}
hdr->prdbc = size - len;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264265 - in head: crypto/openssl/crypto/bn crypto/openssl/crypto/ec crypto/openssl/ssl sys/fs/nfsserver
On 9 Apr 2014, at 15:19, Kubilay Kocak wrote: > That expectation is orthogonal to whether we or other projects do it one > way or another. RHEL users may well be as confused as ours (whether of > not ours are). It may be relevant as a data point, but not for decision > making. I can confirm that, as a user (albeit a slightly sleep-deprived one at the time) I was confused. I believe that I'm now running the correct version, as my libssl.so has a creation date of yesterday, but I don't have a good way of verifying it. It would be great for future security advisories to have a 'how to tell if you're affected' and 'how to tell if you're patched' section. I noticed that freebsd-update told me (after the fetch phase) that I should rebuild all third-party software. I have been following the instructions that we give to users and not building most software on that machine myself. I don't know if there are any packages that statically link to libssl.a (or even if we have a mechanism for determining that), but I'd hope that these would get separate VuXML reports for pkg audit to pick up. David ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264280 - in head/sys: conf modules
On Tuesday, April 08, 2014 5:39:52 pm Sean Bruno wrote: > Author: sbruno > Date: Tue Apr 8 21:39:51 2014 > New Revision: 264280 > URL: http://svnweb.freebsd.org/changeset/base/264280 > > Log: > Actually, since this is what I thought I was doing, only allow the > binmisc code to be build on amd64/i386 for the kernel. > > Update NOTES with some indication of what this code is used for. > > Pointed out by jhb@ ... thanks! > > Submitted by: jhb@ > > Modified: > head/sys/conf/NOTES > head/sys/conf/options.amd64 > head/sys/conf/options.i386 > head/sys/modules/Makefile Why not enable it on all platforms? I don't see anything inherently MD about it. -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264269 - in head: sys/conf sys/kern sys/modules sys/modules/imgact_binmisc sys/sys usr.sbin usr.sbin/binmiscctl
On Wed, 2014-04-09 at 07:44 +, Alexey Dokuchaev wrote: > On Tue, Apr 08, 2014 at 03:01:49PM -0700, Sean Bruno wrote: > > I haven't tested on non-x86 h/w and have no idea if it works or not. I > > didn't feel comfortable building this driver in the non-x86 case. If > > there is a use case/tester for the other arch's, I'll be more than happy > > to change this. > > I'd like to test it on PowerPC. Is there quick start guide available with > some examples of usage? > > ./danfe > Yeah, most of sson's work is documented on the twiki here: https://wiki.freebsd.org/QemuUserModeHowTo At this point, you can use emulators/qemu-devel from ports as it has all the bsd-user land bits in it (thanks to nox). However, each emulated architecture needs someone to spend time on the qemu bits to make it work. For example, the mips32 emulation that has been worked on for since AsiaBSDCon, needed contributions from people(emaste, peter, nox) in the project to get working. sean signature.asc Description: This is a digitally signed message part
Re: svn commit: r264269 - in head: sys/conf sys/kern sys/modules sys/modules/imgact_binmisc sys/sys usr.sbin usr.sbin/binmiscctl
On Wed, 2014-04-09 at 09:27 +0200, Mathieu Arnold wrote: > +--On 8 avril 2014 20:10:22 + Sean Bruno wrote: > | Log: > | Add Stacey Son's binary activation patches that allow remapping of > | execution to a emumation program via parsing of ELF header information. > > Can you MFC that to stable/10 one day ? > We can, yes. I'd like to have a discussion about an MFC first, probably BSDCan, before we do that however. sean signature.asc Description: This is a digitally signed message part
Re: svn commit: r264265 - in head: crypto/openssl/crypto/bn crypto/openssl/crypto/ec crypto/openssl/ssl sys/fs/nfsserver
David Chisnall writes: > I noticed that freebsd-update told me (after the fetch phase) that I > should rebuild all third-party software. This is boilerplate, just like the section in the advisory that tells you to make buildworld && make installworld when in fact all you have to do is make && make install in a single directory (which was not the case here, but was certainly the case for SA-13:14, SA-14:01 and SA-14:02 as well as EN-13:04 and EN-13:05, to pick a few recent examples). > I don't know if there are any packages that statically link to > libssl.a It seems like a fundamentally dumb thing to do, but you never know... > (or even if we have a mechanism for determining that), You can try grepping the binaries. DES -- Dag-Erling Smørgrav - d...@des.no ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264280 - in head/sys: conf modules
On Wed, 2014-04-09 at 11:47 -0400, John Baldwin wrote: > On Tuesday, April 08, 2014 5:39:52 pm Sean Bruno wrote: > > Author: sbruno > > Date: Tue Apr 8 21:39:51 2014 > > New Revision: 264280 > > URL: http://svnweb.freebsd.org/changeset/base/264280 > > > > Log: > > Actually, since this is what I thought I was doing, only allow the > > binmisc code to be build on amd64/i386 for the kernel. > > > > Update NOTES with some indication of what this code is used for. > > > > Pointed out by jhb@ ... thanks! > > > > Submitted by: jhb@ > > > > Modified: > > head/sys/conf/NOTES > > head/sys/conf/options.amd64 > > head/sys/conf/options.i386 > > head/sys/modules/Makefile > > Why not enable it on all platforms? I don't see anything inherently > MD about it. > This is purely an artifact of my comfort level with the code and the cases that I am using/testing. If someone can verify that it works on other architectures, I'm more than happy to enable on all platforms. sean signature.asc Description: This is a digitally signed message part
Re: svn commit: r264265 - in head: crypto/openssl/crypto/bn crypto/openssl/crypto/ec crypto/openssl/ssl sys/fs/nfsserver
On 2014-04-09 09:01, Dag-Erling Smørgrav wrote: Bryan Drewery writes: Also, that this was a partial release of 1.0.1g is confusing a LOT of users. They think they are still vulnerable. They expect to see 1.0.1g in 'openssl version'. We could have our own version string in 'openssl version' to remedy this. This is no different from what other OSes do, e.g. RHEL6.5: % cat /etc/redhat-release Red Hat Enterprise Linux Workstation release 6.5 (Santiago) % openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 % TZ=UTC rpm -qi openssl Name: openssl Relocations: (not relocatable) Version : 1.0.1eVendor: Red Hat, Inc. Release : 16.el6_5.7Build Date: Mon 07 Apr 2014 11:34:45 AM UTC Install Date: Tue 08 Apr 2014 05:18:52 AM UTC Build Host: x86-027.build.eng.bos.redhat.com [...] which despite the version number and date is *not* vulnerable. DES Yes you're right. We're not those projects though. And just because we have "always" done something a certain way does not mean we must forever. We released 2/3 of 1.0.1g to 10, 1/3 of it to previous releases. I do recognize it was not officially 'g'. I am just giving feedback from many confused users. Many of which were just as confused on Debian and CentOS as well. I often think we forget the average user's perspective. -- Regards, Bryan Drewery ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r264280 - in head/sys: conf modules
On Wed, 2014-04-09 at 14:30 -0400, John Baldwin wrote: > On Wednesday, April 09, 2014 1:45:04 pm Sean Bruno wrote: > > On Wed, 2014-04-09 at 11:47 -0400, John Baldwin wrote: > > > On Tuesday, April 08, 2014 5:39:52 pm Sean Bruno wrote: > > > > Author: sbruno > > > > Date: Tue Apr 8 21:39:51 2014 > > > > New Revision: 264280 > > > > URL: http://svnweb.freebsd.org/changeset/base/264280 > > > > > > > > Log: > > > > Actually, since this is what I thought I was doing, only allow the > > > > binmisc code to be build on amd64/i386 for the kernel. > > > > > > > > Update NOTES with some indication of what this code is used for. > > > > > > > > Pointed out by jhb@ ... thanks! > > > > > > > > Submitted by: jhb@ > > > > > > > > Modified: > > > > head/sys/conf/NOTES > > > > head/sys/conf/options.amd64 > > > > head/sys/conf/options.i386 > > > > head/sys/modules/Makefile > > > > > > Why not enable it on all platforms? I don't see anything inherently > > > MD about it. > > > > > > > > > This is purely an artifact of my comfort level with the code and the > > cases that I am using/testing. > > > > If someone can verify that it works on other architectures, I'm more > > than happy to enable on all platforms. > > Does it build on other platforms? I think it is better to enable it if > it builds to avoid bitrot. > Untested. I agree that its better, I just haven't done it. I think this was a protective measure on my part to not inflict more work upon myself as I was already slight agitated at how long it took to get to the point of getting mips32 support implemented via qemu. sean signature.asc Description: This is a digitally signed message part
Re: svn commit: r264280 - in head/sys: conf modules
On Wednesday, April 09, 2014 1:45:04 pm Sean Bruno wrote: > On Wed, 2014-04-09 at 11:47 -0400, John Baldwin wrote: > > On Tuesday, April 08, 2014 5:39:52 pm Sean Bruno wrote: > > > Author: sbruno > > > Date: Tue Apr 8 21:39:51 2014 > > > New Revision: 264280 > > > URL: http://svnweb.freebsd.org/changeset/base/264280 > > > > > > Log: > > > Actually, since this is what I thought I was doing, only allow the > > > binmisc code to be build on amd64/i386 for the kernel. > > > > > > Update NOTES with some indication of what this code is used for. > > > > > > Pointed out by jhb@ ... thanks! > > > > > > Submitted by: jhb@ > > > > > > Modified: > > > head/sys/conf/NOTES > > > head/sys/conf/options.amd64 > > > head/sys/conf/options.i386 > > > head/sys/modules/Makefile > > > > Why not enable it on all platforms? I don't see anything inherently > > MD about it. > > > > > This is purely an artifact of my comfort level with the code and the > cases that I am using/testing. > > If someone can verify that it works on other architectures, I'm more > than happy to enable on all platforms. Does it build on other platforms? I think it is better to enable it if it builds to avoid bitrot. -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264304 - in head/sys: amd64/conf conf i386/conf
Author: sbruno Date: Wed Apr 9 18:44:54 2014 New Revision: 264304 URL: http://svnweb.freebsd.org/changeset/base/264304 Log: Really, really, really only allow this option for amd64/i386 builds. Submitted by: imp@ and tinderbox Modified: head/sys/amd64/conf/NOTES head/sys/conf/NOTES head/sys/i386/conf/NOTES Modified: head/sys/amd64/conf/NOTES == --- head/sys/amd64/conf/NOTES Wed Apr 9 18:16:58 2014(r264303) +++ head/sys/amd64/conf/NOTES Wed Apr 9 18:44:54 2014(r264304) @@ -649,3 +649,6 @@ device ndis # Linux-specific pseudo devices support device lindev + +# Module to enable execution of application via emulators like QEMU +options IMAGACT_BINMISC Modified: head/sys/conf/NOTES == --- head/sys/conf/NOTES Wed Apr 9 18:16:58 2014(r264303) +++ head/sys/conf/NOTES Wed Apr 9 18:44:54 2014(r264304) @@ -2963,6 +2963,3 @@ options RANDOM_YARROW # Yarrow RNG ##options RANDOM_FORTUNA # Fortuna RNG - not yet implemented optionsRANDOM_DEBUG# Debugging messages optionsRANDOM_RWFILE # Read and write entropy cache - -# Module to enable execution of application via emulators like QEMU -options IMAGACT_BINMISC Modified: head/sys/i386/conf/NOTES == --- head/sys/i386/conf/NOTESWed Apr 9 18:16:58 2014(r264303) +++ head/sys/i386/conf/NOTESWed Apr 9 18:44:54 2014(r264304) @@ -1059,3 +1059,6 @@ options VM_KMEM_SIZE_SCALE # asr old ioctls support, needed by raidutils optionsASR_COMPAT + +# Module to enable execution of application via emulators like QEMU +options IMAGACT_BINMISC ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264307 - head/sys/cam/ctl
Author: mav
Date: Wed Apr 9 19:16:40 2014
New Revision: 264307
URL: http://svnweb.freebsd.org/changeset/base/264307
Log:
Fix three refcounter leaks and lock recursion they covered.
MFC after:1 week
Modified:
head/sys/cam/ctl/ctl_frontend_iscsi.c
Modified: head/sys/cam/ctl/ctl_frontend_iscsi.c
==
--- head/sys/cam/ctl/ctl_frontend_iscsi.c Wed Apr 9 19:01:48 2014
(r264306)
+++ head/sys/cam/ctl/ctl_frontend_iscsi.c Wed Apr 9 19:16:40 2014
(r264307)
@@ -1455,6 +1455,7 @@ cfiscsi_ioctl_handoff(struct ctl_iscsi *
mtx_unlock(&cfiscsi_softc.lock);
snprintf(ci->error_str, sizeof(ci->error_str), "connection not
found");
ci->status = CTL_ISCSI_ERROR;
+ cfiscsi_target_release(ct);
return;
}
mtx_unlock(&cfiscsi_softc.lock);
@@ -2093,15 +2094,9 @@ cfiscsi_target_hold(struct cfiscsi_targe
static void
cfiscsi_target_release(struct cfiscsi_target *ct)
{
- int old;
struct cfiscsi_softc *softc;
softc = ct->ct_softc;
-
- old = ct->ct_refcount;
- if (old > 1 && atomic_cmpset_int(&ct->ct_refcount, old, old - 1))
- return;
-
mtx_lock(&softc->lock);
if (refcount_release(&ct->ct_refcount)) {
TAILQ_REMOVE(&softc->targets, ct, ct_next);
@@ -2278,6 +2273,7 @@ cfiscsi_lun_enable(void *arg, struct ctl
tmp = strtoul(lun, NULL, 10);
cfiscsi_target_set_lun(ct, tmp, lun_id);
+ cfiscsi_target_release(ct);
return (0);
}
@@ -2297,8 +2293,9 @@ cfiscsi_lun_disable(void *arg, struct ct
continue;
if (ct->ct_luns[i] != lun_id)
continue;
+ mtx_unlock(&softc->lock);
cfiscsi_target_unset_lun(ct, i);
- break;
+ return (0);
}
}
mtx_unlock(&softc->lock);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264308 - head/crypto/openssh
Author: des
Date: Wed Apr 9 20:42:00 2014
New Revision: 264308
URL: http://svnweb.freebsd.org/changeset/base/264308
Log:
Restore the pX part to the version number printed in debugging mode.
Modified:
head/crypto/openssh/ssh.c
Modified: head/crypto/openssh/ssh.c
==
--- head/crypto/openssh/ssh.c Wed Apr 9 19:16:40 2014(r264307)
+++ head/crypto/openssh/ssh.c Wed Apr 9 20:42:00 2014(r264308)
@@ -895,7 +895,7 @@ main(int ac, char **av)
SYSLOG_FACILITY_USER, !use_syslog);
if (debug_flag)
- logit("%s, %s", SSH_VERSION, SSLeay_version(SSLEAY_VERSION));
+ logit("%s, %s", SSH_RELEASE, SSLeay_version(SSLEAY_VERSION));
/* Parse the configuration files */
process_config_files(pw);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264310 - head/sys/kern
Author: davidxu
Date: Thu Apr 10 02:30:51 2014
New Revision: 264310
URL: http://svnweb.freebsd.org/changeset/base/264310
Log:
Add kqueue support for devctl.
Reviewed by: kib,mjg
Modified:
head/sys/kern/subr_bus.c
Modified: head/sys/kern/subr_bus.c
==
--- head/sys/kern/subr_bus.cWed Apr 9 21:19:46 2014(r264309)
+++ head/sys/kern/subr_bus.cThu Apr 10 02:30:51 2014(r264310)
@@ -367,6 +367,7 @@ static d_close_tdevclose;
static d_read_tdevread;
static d_ioctl_t devioctl;
static d_poll_tdevpoll;
+static d_kqfilter_tdevkqfilter;
static struct cdevsw dev_cdevsw = {
.d_version =D_VERSION,
@@ -375,6 +376,7 @@ static struct cdevsw dev_cdevsw = {
.d_read = devread,
.d_ioctl = devioctl,
.d_poll = devpoll,
+ .d_kqfilter = devkqfilter,
.d_name = "devctl",
};
@@ -399,6 +401,15 @@ static struct dev_softc
struct sigio *sigio;
} devsoftc;
+static voidfilt_devctl_detach(struct knote *kn);
+static int filt_devctl_read(struct knote *kn, long hint);
+
+struct filterops devctl_rfiltops = {
+ .f_isfd = 1,
+ .f_detach = filt_devctl_detach,
+ .f_event = filt_devctl_read,
+};
+
static struct cdev *devctl_dev;
static void
@@ -409,6 +420,7 @@ devinit(void)
mtx_init(&devsoftc.mtx, "dev mtx", "devd", MTX_DEF);
cv_init(&devsoftc.cv, "dev cv");
TAILQ_INIT(&devsoftc.devq);
+ knlist_init_mtx(&devsoftc.sel.si_note, &devsoftc.mtx);
}
static int
@@ -529,6 +541,34 @@ devpoll(struct cdev *dev, int events, st
return (revents);
}
+static int
+devkqfilter(struct cdev *dev, struct knote *kn)
+{
+ int error;
+
+ if (kn->kn_filter == EVFILT_READ) {
+ kn->kn_fop = &devctl_rfiltops;
+ knlist_add(&devsoftc.sel.si_note, kn, 0);
+ error = 0;
+ } else
+ error = EINVAL;
+ return (error);
+}
+
+static void
+filt_devctl_detach(struct knote *kn)
+{
+
+ knlist_remove(&devsoftc.sel.si_note, kn, 0);
+}
+
+static int
+filt_devctl_read(struct knote *kn, long hint)
+{
+ kn->kn_data = devsoftc.queued;
+ return (kn->kn_data != 0);
+}
+
/**
* @brief Return whether the userland process is running
*/
@@ -576,6 +616,7 @@ devctl_queue_data_f(char *data, int flag
TAILQ_INSERT_TAIL(&devsoftc.devq, n1, dei_link);
devsoftc.queued++;
cv_broadcast(&devsoftc.cv);
+ KNOTE_LOCKED(&devsoftc.sel.si_note, 0);
mtx_unlock(&devsoftc.mtx);
selwakeup(&devsoftc.sel);
if (devsoftc.async && devsoftc.sigio != NULL)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r264311 - head/sys/cam/scsi
Author: smh Date: Thu Apr 10 05:04:23 2014 New Revision: 264311 URL: http://svnweb.freebsd.org/changeset/base/264311 Log: Fix build breakage caused by r264295 X-MFC-With: r264295 MFC after:1 week Modified: head/sys/cam/scsi/scsi_cd.c Modified: head/sys/cam/scsi/scsi_cd.c == --- head/sys/cam/scsi/scsi_cd.c Thu Apr 10 02:30:51 2014(r264310) +++ head/sys/cam/scsi/scsi_cd.c Thu Apr 10 05:04:23 2014(r264311) @@ -205,8 +205,6 @@ static periph_oninv_t cdoninvalidate; static voidcdasync(void *callback_arg, u_int32_t code, struct cam_path *path, void *arg); static int cdcmdsizesysctl(SYSCTL_HANDLER_ARGS); -static voidcdshorttimeout(void *arg); -static voidcdschedule(struct cam_periph *periph, int priority); static int cdrunccb(union ccb *ccb, int (*error_routine)(union ccb *ccb, u_int32_t cam_flags, ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
