svn commit: r343129 - head/sys/cam/ata
Author: gonzo
Date: Fri Jan 18 04:23:52 2019
New Revision: 343129
URL: https://svnweb.freebsd.org/changeset/base/343129
Log:
[ata] Add workaround for KingDian S200 SSD crash on receiving TRIM command
- Add ADA_Q_NO_TRIM quirk to be used with the device that falsely advertise
TRIM support
- Add ADA_Q_NO_TRIM entry for KingDian S200 SSD
PR: 222802
Submitted by: Bertrand Petit
MFC after:1 week
Modified:
head/sys/cam/ata/ata_da.c
Modified: head/sys/cam/ata/ata_da.c
==
--- head/sys/cam/ata/ata_da.c Fri Jan 18 00:39:17 2019(r343128)
+++ head/sys/cam/ata/ata_da.c Fri Jan 18 04:23:52 2019(r343129)
@@ -118,7 +118,8 @@ typedef enum {
ADA_Q_4K= 0x01,
ADA_Q_NCQ_TRIM_BROKEN = 0x02,
ADA_Q_LOG_BROKEN= 0x04,
- ADA_Q_SMR_DM= 0x08
+ ADA_Q_SMR_DM= 0x08,
+ ADA_Q_NO_TRIM = 0x10
} ada_quirks;
#define ADA_Q_BIT_STRING \
@@ -126,7 +127,8 @@ typedef enum {
"\0014K"\
"\002NCQ_TRIM_BROKEN" \
"\003LOG_BROKEN"\
- "\004SMR_DM"
+ "\004SMR_DM"\
+ "\005NO_TRIM"
typedef enum {
ADA_CCB_RAHEAD = 0x01,
@@ -543,6 +545,14 @@ static struct ada_quirk_entry ada_quirk_table[] =
},
{
/*
+* KingDian S200 60GB P0921B
+* Trimming crash the SSD
+*/
+ { T_DIRECT, SIP_MEDIA_FIXED, "*", "KingDian S200 *", "*" },
+ /*quirks*/ADA_Q_NO_TRIM
+ },
+ {
+ /*
* Kingston E100 Series SSDs
* 4k optimised & trim only works in 4k requests + 4k aligned
*/
@@ -1810,6 +1820,10 @@ adaregister(struct cam_periph *periph, void *arg)
softc->disk->d_flags = DISKFLAG_DIRECT_COMPLETION | DISKFLAG_CANZONE;
if (softc->flags & ADA_FLAG_CAN_FLUSHCACHE)
softc->disk->d_flags |= DISKFLAG_CANFLUSHCACHE;
+ /* Device lies about TRIM capability. */
+ if ((softc->quirks & ADA_Q_NO_TRIM) &&
+ (softc->flags & ADA_FLAG_CAN_TRIM))
+ softc->flags &= ~ADA_FLAG_CAN_TRIM;
if (softc->flags & ADA_FLAG_CAN_TRIM) {
softc->disk->d_flags |= DISKFLAG_CANDELETE;
softc->disk->d_delmaxsize = softc->params.secsize *
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
In message , Maxim Sobolev writes: > > What I think we really need is some way to easily porti-ze useful stuff > that would otherwise go into /usr/[s]bin, so adding things would be just as > easy as hooking up SUBDIR into usr.[s]bin/Makefile. Yes, I know, this is > topic almost as old as the FreeBSD Project itself, but perhaps we just did > not approach it the right way. It was always the idea that we would just > move bunch of stuff from src/usr.[s]bin repo into ports/. Which brings > several important question such as "who is to host the distfile"? "where > sources hosted", "who is to update the port when changes happen?" etc. pkgbase might address some of the above. Ports and base might install in a homogeneous manner. > > Perhaps even by forking the whole ports idea into a smaller closely-guarged > subset. Something like a new baseports repository, which might have > structure like baseports/usr.bin/xxx, baseports/usr.sbin/yyy etc. Then add > some automagic glue to kick in on every commit and transfer this into valid > ports, which is going to be packaged by the poudriere and such. This way we > could reduce amount of port-foo average src committer needs in order to > maintain code. I am almost tempted to sit and write something over the next > weekend or few of thereofs. Using usr.sbin/trim as an example. If it's external it should should live in ports and be installed in $LOCALBASE. A quasi src repo in ports to install software outside of $LOCALBASE doesn't make any sense. ALso see my comment about pkgbase. I expect pkgbase to homogenize base and ports into a seamless install. Alternatively pkgbase and ports could use different package repos. For example when I was an MVS sysprog, MVS and JES were installed in one repo while CICS and IMS were installed each in their own repos. That was site specific but not out of the realm of possibilities here either. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
In message , Enji Cooper writes : > > > --Apple-Mail=_6CB1620B-6707-4F06-B7FF-9F1ECBA36F56 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=utf-8 > > > > On Jan 17, 2019, at 2:25 PM, Maxim Sobolev = > wrote: > >=20 > > What I think we really need is some way to easily porti-ze useful = > stuff that would otherwise go into /usr/[s]bin, so adding things would = > be just as easy as hooking up SUBDIR into usr.[s]bin/Makefile. Yes, I = > know, this is topic almost as old as the FreeBSD Project itself, but = > perhaps we just did not approach it the right way. It was always the = > idea that we would just move bunch of stuff from src/usr.[s]bin repo = > into ports/. Which brings several important question such as "who is to = > host the distfile"? "where sources hosted", "who is to update the port = > when changes happen?" etc. > > Projects like this could be hosted on GitHub. Ports supports GitHub out = > of the box, so this seems like a low barrier for entry (the bonus of = > doing this is that the projects could potentially be used by other = > non-FreeBSD projects, and contributed by others outside the FreeBSD = > project; the downside is having to deal with FreeBSD CI, as Travis CI = > only supports Linux (IIRC making Travis support FreeBSD is a non-trivial = > project, but it=E2=80=99s likely a very worthwhile goal, as it would = > make it easier to catch issues upfront with third-party projects that = > FreeBSD consumes, like llvm), enforcing style (can be done with git = > commit hooks and GitHub checks), etc. I would really like to do these = > things because it=E2=80=99s difficult getting folks to support FreeBSD = > in third-party projects as-is. Lowering the barrier of entry would allow = > FreeBSD and its developers to better scale (and make FreeBSD more of a = > first-class OS). Yes. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
In message <201901180008.x0i08thg052...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. Gri mes" writes: > > What I think we really need is some way to easily porti-ze useful stuff > > that would otherwise go into /usr/[s]bin, so adding things would be just as > > easy as hooking up SUBDIR into usr.[s]bin/Makefile. Yes, I know, this is > > topic almost as old as the FreeBSD Project itself, but perhaps we just did > > not approach it the right way. It was always the idea that we would just > > move bunch of stuff from src/usr.[s]bin repo into ports/. Which brings > > several important question such as "who is to host the distfile"? "where > > sources hosted", "who is to update the port when changes happen?" etc. > > > > Perhaps even by forking the whole ports idea into a smaller closely-guarged > > subset. Something like a new baseports repository, which might have > > structure like baseports/usr.bin/xxx, baseports/usr.sbin/yyy etc. Then add > > some automagic glue to kick in on every commit and transfer this into valid > > ports, which is going to be packaged by the poudriere and such. This way we > > could reduce amount of port-foo average src committer needs in order to > > maintain code. I am almost tempted to sit and write something over the next > > weekend or few of thereofs. Using usr.sbin/trim as an example. > > Couldnt the "distribution" just live as files commited into > the ports tree as a "work" hierarcy and the top level file > be marked as no fetch. We use to stick small stuff in ports > by putting there files in files/ and having that work IIRC. If it must live in one of our repositories, then a users, projects or other hierarchy in ports might be acceptable. However there would be too great a temptation to fork a random piece of software on the internet. baseports/usr.bin/whatever doesn't make much sense. If it's in ports it should use the ports infrastructure and install in $LOCALBASE. If it's in ports, it's not in base and should not be installed outside of $LOCALBASE. If it's to be installed in for instance, /usr/bin, then it must live in usr.bin. > > I really really dislike the idea of putting stuff from base in > external repositories and then fetching them, something just > feels fundementally wrong about that. Trim should not be in base/. If it's in ports it should be installed in $LOCALBASE not outside it. The point is, trim should not be in base. It should not live in /usr/src nor should it be installed outside of $LOCALBASE. If anything, as is it could be a port. It should not live in a user or project branch of base nor should it be sourced out of some hypothetical quasi FreeBSD source repository in ports or any other FreeBSD repo for that matter. It doesn't belong here at all. It's function can however be provided by dd. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
On Thu, Jan 17, 2019 at 5:48 PM Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Thu, Jan 17, 2019 at 3:43 PM Conrad Meyer wrote: > > > > > On Thu, Jan 17, 2019 at 1:16 PM Eugene Grosbein > wrote: > > > > > > > > 18.01.2019 3:23, Conrad Meyer ?: > > > > > > > > > Please back it out; stop attributing code review to "hackers@," > which > > > > > can not (it's a list, not individuals) and did not review this > > > > > changeset; and put it on phabricator for actual review. > > > > > > > > There is already https://reviews.freebsd.org/D18380 by imp > > > > and there were over 6 weeks since it had an update. > > > > Newly committed code has most of its changes. > > > > > > Your response does not address *any* of the above concerns. It's just > > > unrelated. > > > > > > > Yes. > > > > > > > The review you linked to isn't one you submitted for this change; it's > > > Warner's, and that one stalled because you were such a jerk to him > > > last time that he needed time off from you. > > > > > > > I abandoned it because dd is the better way to go because it can transfer > > images with 0's and TRIM the zero'd pages (and only the zero'd pages). > Sure > > dd is hard to use, but it's not that hard to use. > > I strongly disagree that dd is the proper place for this tool, > dd is far to easy a way to destroy data when trying to do this > type of operation and should be the last choice for implementing > what is normally a very safe thing to do. > > And as eugene points out dd can not easily be made > to do "trim ada0 ada1 ada4" which is probably the > far more common use of this command > for i in ada0 ada1 ada4; do dd of=/dev/$i if=/dev/zero conv=trim &; done; wait if that's your objection. It's a weak counter argument, but this really isn't the place for the debate. > dd's ability to do sparse(ing) of a file should NOT be > overloaded with a device layer block trimming function. > It's not overloaded. You have to specifically ask for the conversion. It's the right place for it. > > > > > > > If you want to socialize, revive, or expedite someone else's review, > > > maybe add a new comment to the review, or post a discussion hackers@, > > > or something like that. You still can't attribute code review to > > > hackers@, especially as no such review happened. > > > > > > > I think it should be backed out. Especially since it hijacks my work and > my > > name to try to ram it into the tree. > > > > I'm very much not amused. > > Nor am I with some of the reactoin to the commit :-( > I'm sorry, but I fire back when people abuse me. Especially when it's a repeat offender who clearly didn't internalize the feedback given the first time. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343125 - head/sys/dev/ioat
On Thu, Jan 17, 2019 at 4:12 PM Kevin Bowling wrote: > > Out of curiosity are you using this driver? Any performance data? Yep. I don't have any hard numbers on hand but my recollection is it caps out at about 5 GB/s, total, on Broadwell. Our workload with it is predominantly unmapped 8kB copies but includes some 512 byte copies as well. My recollection is that the channels are logical and share a single DMA engine, so there's not much reason to use more than one of them. It may improve on future microarchs but I can't speak to those. Cheers, Conrad ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
> On Thu, Jan 17, 2019 at 3:43 PM Conrad Meyer wrote: > > > On Thu, Jan 17, 2019 at 1:16 PM Eugene Grosbein wrote: > > > > > > 18.01.2019 3:23, Conrad Meyer ?: > > > > > > > Please back it out; stop attributing code review to "hackers@," which > > > > can not (it's a list, not individuals) and did not review this > > > > changeset; and put it on phabricator for actual review. > > > > > > There is already https://reviews.freebsd.org/D18380 by imp > > > and there were over 6 weeks since it had an update. > > > Newly committed code has most of its changes. > > > > Your response does not address *any* of the above concerns. It's just > > unrelated. > > > > Yes. > > > > The review you linked to isn't one you submitted for this change; it's > > Warner's, and that one stalled because you were such a jerk to him > > last time that he needed time off from you. > > > > I abandoned it because dd is the better way to go because it can transfer > images with 0's and TRIM the zero'd pages (and only the zero'd pages). Sure > dd is hard to use, but it's not that hard to use. I strongly disagree that dd is the proper place for this tool, dd is far to easy a way to destroy data when trying to do this type of operation and should be the last choice for implementing what is normally a very safe thing to do. And as eugene points out dd can not easily be made to do "trim ada0 ada1 ada4" which is probably the far more common use of this command. dd's ability to do sparse(ing) of a file should NOT be overloaded with a device layer block trimming function. > > > > If you want to socialize, revive, or expedite someone else's review, > > maybe add a new comment to the review, or post a discussion hackers@, > > or something like that. You still can't attribute code review to > > hackers@, especially as no such review happened. > > > > I think it should be backed out. Especially since it hijacks my work and my > name to try to ram it into the tree. > > I'm very much not amused. Nor am I with some of the reactoin to the commit :-( -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
On Thu, Jan 17, 2019 at 3:43 PM Conrad Meyer wrote: > On Thu, Jan 17, 2019 at 1:16 PM Eugene Grosbein wrote: > > > > 18.01.2019 3:23, Conrad Meyer пишет: > > > > > Please back it out; stop attributing code review to "hackers@," which > > > can not (it's a list, not individuals) and did not review this > > > changeset; and put it on phabricator for actual review. > > > > There is already https://reviews.freebsd.org/D18380 by imp > > and there were over 6 weeks since it had an update. > > Newly committed code has most of its changes. > > Your response does not address *any* of the above concerns. It's just > unrelated. > Yes. > The review you linked to isn't one you submitted for this change; it's > Warner's, and that one stalled because you were such a jerk to him > last time that he needed time off from you. > I abandoned it because dd is the better way to go because it can transfer images with 0's and TRIM the zero'd pages (and only the zero'd pages). Sure dd is hard to use, but it's not that hard to use. > If you want to socialize, revive, or expedite someone else's review, > maybe add a new comment to the review, or post a discussion hackers@, > or something like that. You still can't attribute code review to > hackers@, especially as no such review happened. > I think it should be backed out. Especially since it hijacks my work and my name to try to ram it into the tree. I'm very much not amused. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
On Thu, Jan 17, 2019 at 2:16 PM Eugene Grosbein wrote: > 18.01.2019 3:23, Conrad Meyer пишет: > > > Please back it out; stop attributing code review to "hackers@," which > > can not (it's a list, not individuals) and did not review this > > changeset; and put it on phabricator for actual review. > > There is already https://reviews.freebsd.org/D18380 by imp > and there were over 6 weeks since it had an update. > Newly committed code has most of its changes. > You hijacked that review. Don't you dare use it as evidence of consent to the sh*t you just pulled. Back it out, do a proper review. This one was not proper, nor was it complete. Don't go using my name to support a program I've come to think is a really bad idea. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343128 - head/tools/build/mk
Author: gonzo Date: Fri Jan 18 00:39:17 2019 New Revision: 343128 URL: https://svnweb.freebsd.org/changeset/base/343128 Log: Add ypldap to the list of conditional obsolete files ypldap should be removed during delete-old if WITHOUT_NIS flag is enabled PR: 230727 Submitted by: Dmitry Wagin MFC after:1 week Modified: head/tools/build/mk/OptionalObsoleteFiles.inc Modified: head/tools/build/mk/OptionalObsoleteFiles.inc == --- head/tools/build/mk/OptionalObsoleteFiles.inc Fri Jan 18 00:26:25 2019(r343127) +++ head/tools/build/mk/OptionalObsoleteFiles.inc Fri Jan 18 00:39:17 2019(r343128) @@ -6522,6 +6522,7 @@ OLD_FILES+=usr/bin/ypcat OLD_FILES+=usr/bin/ypchfn OLD_FILES+=usr/bin/ypchpass OLD_FILES+=usr/bin/ypchsh +OLD_FILES+=usr/bin/ypldap OLD_FILES+=usr/bin/ypmatch OLD_FILES+=usr/bin/yppasswd OLD_FILES+=usr/bin/ypwhich ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343127 - head/usr.bin/compress
Author: gonzo
Date: Fri Jan 18 00:26:25 2019
New Revision: 343127
URL: https://svnweb.freebsd.org/changeset/base/343127
Log:
Fix descriptor/memory leak in compress(1) code
This is mostly a style fix since the code in question is not called multiple
times and doesn't have cummulative effect.
PR: 204953
Submitted by: David Binderman
MFC after:1 week
Modified:
head/usr.bin/compress/compress.c
Modified: head/usr.bin/compress/compress.c
==
--- head/usr.bin/compress/compress.cThu Jan 17 23:22:56 2019
(r343126)
+++ head/usr.bin/compress/compress.cFri Jan 18 00:26:25 2019
(r343127)
@@ -322,6 +322,8 @@ decompress(const char *in, const char *out, int bits)
if ((ofp = fopen(out, "w")) == NULL ||
(nr != 0 && fwrite(buf, 1, nr, ofp) != nr)) {
cwarn("%s", out);
+ if (ofp)
+ (void)fclose(ofp);
(void)fclose(ifp);
return;
}
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343125 - head/sys/dev/ioat
Out of curiosity are you using this driver? Any performance data? On Thu, Jan 17, 2019 at 4:21 PM Conrad Meyer wrote: > Author: cem > Date: Thu Jan 17 23:21:02 2019 > New Revision: 343125 > URL: https://svnweb.freebsd.org/changeset/base/343125 > > Log: > ioat(4): Set __result_use_check on ioat_acquire_reserve > > Even M_WAITOK callers must check for failure. For example, if the > device is > quiescing, either due to automatic error-recovery induced reset, or due > to > administrative detach, the routine will return ENXIO and the acquire > reference will not be held. So, there is no mode in which it is safe to > assume the routine succeeds without checking. > > Sponsored by: Dell EMC Isilon > > Modified: > head/sys/dev/ioat/ioat.h > > Modified: head/sys/dev/ioat/ioat.h > > == > --- head/sys/dev/ioat/ioat.hThu Jan 17 22:00:02 2019(r343124) > +++ head/sys/dev/ioat/ioat.hThu Jan 17 23:21:02 2019(r343125) > @@ -173,7 +173,8 @@ void ioat_release(bus_dmaengine_t dmaengine); > * > * On failure, the caller does not hold the dmaengine. > */ > -int ioat_acquire_reserve(bus_dmaengine_t dmaengine, unsigned n, int > mflags); > +int ioat_acquire_reserve(bus_dmaengine_t dmaengine, unsigned n, int > mflags) > +__result_use_check; > > /* > * Issue a blockfill operation. The 64-bit pattern 'fillpattern' is > written to > ___ > svn-src-h...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
> What I think we really need is some way to easily porti-ze useful stuff > that would otherwise go into /usr/[s]bin, so adding things would be just as > easy as hooking up SUBDIR into usr.[s]bin/Makefile. Yes, I know, this is > topic almost as old as the FreeBSD Project itself, but perhaps we just did > not approach it the right way. It was always the idea that we would just > move bunch of stuff from src/usr.[s]bin repo into ports/. Which brings > several important question such as "who is to host the distfile"? "where > sources hosted", "who is to update the port when changes happen?" etc. > > Perhaps even by forking the whole ports idea into a smaller closely-guarged > subset. Something like a new baseports repository, which might have > structure like baseports/usr.bin/xxx, baseports/usr.sbin/yyy etc. Then add > some automagic glue to kick in on every commit and transfer this into valid > ports, which is going to be packaged by the poudriere and such. This way we > could reduce amount of port-foo average src committer needs in order to > maintain code. I am almost tempted to sit and write something over the next > weekend or few of thereofs. Using usr.sbin/trim as an example. Couldnt the "distribution" just live as files commited into the ports tree as a "work" hierarcy and the top level file be marked as no fetch. We use to stick small stuff in ports by putting there files in files/ and having that work IIRC. I really really dislike the idea of putting stuff from base in external repositories and then fetching them, something just feels fundementally wrong about that. > -Max > > On Thu, Jan 17, 2019 at 12:47 PM Cy Schubert > wrote: > > > In message > il.com> > > , Conrad Meyer writes: > > > On Thu, Jan 17, 2019 at 12:22 PM Cy Schubert > > wrot > > > e: > > > > This is wrong. IIRC there was discussion that this should be in dd(1). > > > > Why not submit a revision to add the functionality to dd? > > > > > > Well, it's wrong, but not because we need another weird dd mode. dd > > > is hard enough to use already. > > > > I've never found dd confusing. What's wrong conv=erase? > > > > If it must stay, sderase is a better name. That's really what it does. > > > > Ports maybe? > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > The need of the many outweighs the greed of the few. > > > > > > > > -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343126 - stable/12/sys/sys
Author: brooks Date: Thu Jan 17 23:22:56 2019 New Revision: 343126 URL: https://svnweb.freebsd.org/changeset/base/343126 Log: MFC r342398: Enable sys/random.h #include from C++ And bump __FreeBSD_version, just in case. PR: 234180 Submitted by: Ralf van der Enden Modified: stable/12/sys/sys/param.h stable/12/sys/sys/random.h Directory Properties: stable/12/ (props changed) Modified: stable/12/sys/sys/param.h == --- stable/12/sys/sys/param.h Thu Jan 17 23:21:02 2019(r343125) +++ stable/12/sys/sys/param.h Thu Jan 17 23:22:56 2019(r343126) @@ -60,7 +60,7 @@ * in the range 5 to 9. */ #undef __FreeBSD_version -#define __FreeBSD_version 1200501 /* Master, propagated to newvers */ +#define __FreeBSD_version 1200502 /* Master, propagated to newvers */ /* * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD, Modified: stable/12/sys/sys/random.h == --- stable/12/sys/sys/random.h Thu Jan 17 23:21:02 2019(r343125) +++ stable/12/sys/sys/random.h Thu Jan 17 23:22:56 2019(r343126) @@ -157,6 +157,9 @@ void random_harvest_deregister_source(enum random_entr #define GRND_NONBLOCK 0x1 #define GRND_RANDOM0x2 + +__BEGIN_DECLS ssize_t getrandom(void *buf, size_t buflen, unsigned int flags); +__END_DECLS #endif /* _SYS_RANDOM_H_ */ ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343125 - head/sys/dev/ioat
Author: cem Date: Thu Jan 17 23:21:02 2019 New Revision: 343125 URL: https://svnweb.freebsd.org/changeset/base/343125 Log: ioat(4): Set __result_use_check on ioat_acquire_reserve Even M_WAITOK callers must check for failure. For example, if the device is quiescing, either due to automatic error-recovery induced reset, or due to administrative detach, the routine will return ENXIO and the acquire reference will not be held. So, there is no mode in which it is safe to assume the routine succeeds without checking. Sponsored by: Dell EMC Isilon Modified: head/sys/dev/ioat/ioat.h Modified: head/sys/dev/ioat/ioat.h == --- head/sys/dev/ioat/ioat.hThu Jan 17 22:00:02 2019(r343124) +++ head/sys/dev/ioat/ioat.hThu Jan 17 23:21:02 2019(r343125) @@ -173,7 +173,8 @@ void ioat_release(bus_dmaengine_t dmaengine); * * On failure, the caller does not hold the dmaengine. */ -int ioat_acquire_reserve(bus_dmaengine_t dmaengine, unsigned n, int mflags); +int ioat_acquire_reserve(bus_dmaengine_t dmaengine, unsigned n, int mflags) +__result_use_check; /* * Issue a blockfill operation. The 64-bit pattern 'fillpattern' is written to ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Packaging base system (again) [Was: svn commit: r343118 - in head/usr.sbin: . trim]
On Thu, Jan 17, 2019 at 2:42 PM Enji Cooper wrote: > > Perhaps even by forking the whole ports idea into a smaller > closely-guarged subset. Something like a new baseports repository, which > might have structure like baseports/usr.bin/xxx, baseports/usr.sbin/yyy > etc. Then add some automagic glue to kick in on every commit and transfer > this into valid ports, which is going to be packaged by the poudriere and > such. This way we could reduce amount of port-foo average src committer > needs in order to maintain code. I am almost tempted to sit and write > something over the next weekend or few of thereofs. Using usr.sbin/trim as > an example. > > Please see my above comment. > Well, I don't think your comment really addresses my concerns here. Correct me if I am wrong, but you seem suggesting that every src developer would also need some external account (github in this example) to maintain his or her chunk of code independently of everyone else's. This is pretty much a no-go from starters. There are also many more major issues with such approach, such as completely different branching model for src and ports as an example. ports is a good framework in general, for maintaining software produced by external entities. I don't feel it's very appropriate for maintaining software produced by the Project itself, though, due to complexity inherited with that. We need something simpler and more self-consistent, at the same time I see no reasons why it could not utilize some if not all tooling with we build around ports/Mk over the years. IMHO. -Max ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
On Thu, Jan 17, 2019 at 1:16 PM Eugene Grosbein wrote: > > 18.01.2019 3:23, Conrad Meyer пишет: > > > Please back it out; stop attributing code review to "hackers@," which > > can not (it's a list, not individuals) and did not review this > > changeset; and put it on phabricator for actual review. > > There is already https://reviews.freebsd.org/D18380 by imp > and there were over 6 weeks since it had an update. > Newly committed code has most of its changes. Your response does not address *any* of the above concerns. It's just unrelated. The review you linked to isn't one you submitted for this change; it's Warner's, and that one stalled because you were such a jerk to him last time that he needed time off from you. If you want to socialize, revive, or expedite someone else's review, maybe add a new comment to the review, or post a discussion hackers@, or something like that. You still can't attribute code review to hackers@, especially as no such review happened. Conrad ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
> On Jan 17, 2019, at 2:25 PM, Maxim Sobolev wrote: > > What I think we really need is some way to easily porti-ze useful stuff that > would otherwise go into /usr/[s]bin, so adding things would be just as easy > as hooking up SUBDIR into usr.[s]bin/Makefile. Yes, I know, this is topic > almost as old as the FreeBSD Project itself, but perhaps we just did not > approach it the right way. It was always the idea that we would just move > bunch of stuff from src/usr.[s]bin repo into ports/. Which brings several > important question such as "who is to host the distfile"? "where sources > hosted", "who is to update the port when changes happen?" etc. Projects like this could be hosted on GitHub. Ports supports GitHub out of the box, so this seems like a low barrier for entry (the bonus of doing this is that the projects could potentially be used by other non-FreeBSD projects, and contributed by others outside the FreeBSD project; the downside is having to deal with FreeBSD CI, as Travis CI only supports Linux (IIRC making Travis support FreeBSD is a non-trivial project, but it’s likely a very worthwhile goal, as it would make it easier to catch issues upfront with third-party projects that FreeBSD consumes, like llvm), enforcing style (can be done with git commit hooks and GitHub checks), etc. I would really like to do these things because it’s difficult getting folks to support FreeBSD in third-party projects as-is. Lowering the barrier of entry would allow FreeBSD and its developers to better scale (and make FreeBSD more of a first-class OS). > Perhaps even by forking the whole ports idea into a smaller closely-guarged > subset. Something like a new baseports repository, which might have structure > like baseports/usr.bin/xxx, baseports/usr.sbin/yyy etc. Then add some > automagic glue to kick in on every commit and transfer this into valid ports, > which is going to be packaged by the poudriere and such. This way we could > reduce amount of port-foo average src committer needs in order to maintain > code. I am almost tempted to sit and write something over the next weekend or > few of thereofs. Using usr.sbin/trim as an example. Please see my above comment. Cheers! -Enji signature.asc Description: Message signed with OpenPGP
Re: svn commit: r343122 - head/usr.sbin/freebsd-update
On Thu, 17 Jan 2019 at 16:46, Xin LI wrote: > > On Thu, Jan 17, 2019 at 1:39 PM Ed Maste wrote: >> >> Author: emaste >> Date: Thu Jan 17 21:38:57 2019 >> New Revision: 343122 >> URL: https://svnweb.freebsd.org/changeset/base/343122 >> >> Log: >> freebsd-update: Clarify unsupported release upgrade error message > > I think this would break upgrading from e.g. -BETA or -RC, which is supported? Indeed, followup coming shortly. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343030 - in head/sys: cam conf dev/md dev/nvme fs/fuse fs/nfsclient fs/smbfs kern sys ufs/ffs vm
On WITNESS builds after this change and all followup fixes I can see
(@ r343108), I get a new warning:
Sleeping on "pageprocwait" with the following non-sleepable locks held:
exclusive sleep mutex pbuf (UMA zone) r = 0 (0xf80003033e00)
locked @ .../sys/vm/uma_core.c:1139
stack backtrace:
#0 0x80c0a164 at witness_debugger.part.14+0xa4
#1 0x80c0d465 at witness_warn+0x285
#2 0x80baa3b9 at _sleep+0x59
#3 0x80f03c73 at vm_wait_doms+0x103
#4 0x80eeb8e5 at vm_domainset_iter_policy+0x55
#5 0x80eeab59 at uma_prealloc+0xc9
#6 0x80f0d643 at pbuf_zsecond_create+0x63
#7 0x80ee2c9f at swap_pager_swap_init+0x5f
#8 0x80f0cf57 at vm_pageout+0x27
For what it's worth, this is a bhyve guest with vm.ndomains 1. (The
bhyve host has 2 domains, but I don't see how that would be relevant.)
Best,
Conrad
On Mon, Jan 14, 2019 at 5:02 PM Gleb Smirnoff wrote:
>
> Author: glebius
> Date: Tue Jan 15 01:02:16 2019
> New Revision: 343030
> URL: https://svnweb.freebsd.org/changeset/base/343030
>
> Log:
> Allocate pager bufs from UMA instead of 80-ish mutex protected linked list.
>
> o In vm_pager_bufferinit() create pbuf_zone and start accounting on how many
> pbufs are we going to have set.
> In various subsystems that are going to utilize pbufs create private zones
> via call to pbuf_zsecond_create(). The latter calls uma_zsecond_create(),
> and sets a limit on created zone. After startup preallocate pbufs
> according
> to requirements of all pbuf zones.
>
> Subsystems that used to have a private limit with old allocator now have
> private pbuf zones: md(4), fusefs, NFS client, smbfs, VFS cluster, FFS,
> swap, vnode pager.
>
> The following subsystems use shared pbuf zone: cam(4), nvme(4), physio(9),
> aio(4). They should have their private limits, but changing that is out of
> scope of this commit.
>
> o Fetch tunable value of kern.nswbuf from init_param2() and while here move
> NSWBUF_MIN to opt_param.h and eliminate opt_swap.h, that was holding only
> this option.
> Default values aren't touched by this commit, but they probably should be
> reviewed wrt to modern hardware.
>
> This change removes a tight bottleneck from sendfile(2) operation, that
> uses pbufs in vnode pager. Other pagers also would benefit from faster
> allocation.
>
> Together with:gallatin
> Tested by:pho
>
> Modified:
> head/sys/cam/cam_periph.c
> head/sys/conf/options
> head/sys/dev/md/md.c
> head/sys/dev/nvme/nvme_ctrlr.c
> head/sys/fs/fuse/fuse_main.c
> head/sys/fs/fuse/fuse_vnops.c
> head/sys/fs/nfsclient/nfs_clbio.c
> head/sys/fs/nfsclient/nfs_clport.c
> head/sys/fs/smbfs/smbfs_io.c
> head/sys/fs/smbfs/smbfs_vfsops.c
> head/sys/kern/kern_physio.c
> head/sys/kern/subr_param.c
> head/sys/kern/vfs_aio.c
> head/sys/kern/vfs_bio.c
> head/sys/kern/vfs_cluster.c
> head/sys/sys/buf.h
> head/sys/ufs/ffs/ffs_rawread.c
> head/sys/vm/swap_pager.c
> head/sys/vm/vm_pager.c
> head/sys/vm/vnode_pager.c
>
> Modified: head/sys/cam/cam_periph.c
> ==
> --- head/sys/cam/cam_periph.c Tue Jan 15 00:52:41 2019(r343029)
> +++ head/sys/cam/cam_periph.c Tue Jan 15 01:02:16 2019(r343030)
> @@ -936,7 +936,7 @@ cam_periph_mapmem(union ccb *ccb, struct cam_periph_ma
> /*
> * Get the buffer.
> */
> - mapinfo->bp[i] = getpbuf(NULL);
> + mapinfo->bp[i] = uma_zalloc(pbuf_zone, M_WAITOK);
>
> /* put our pointer in the data slot */
> mapinfo->bp[i]->b_data = *data_ptrs[i];
> @@ -962,9 +962,9 @@ cam_periph_mapmem(union ccb *ccb, struct cam_periph_ma
> for (j = 0; j < i; ++j) {
> *data_ptrs[j] = mapinfo->bp[j]->b_caller1;
> vunmapbuf(mapinfo->bp[j]);
> - relpbuf(mapinfo->bp[j], NULL);
> + uma_zfree(pbuf_zone, mapinfo->bp[j]);
> }
> - relpbuf(mapinfo->bp[i], NULL);
> + uma_zfree(pbuf_zone, mapinfo->bp[i]);
> PRELE(curproc);
> return(EACCES);
> }
> @@ -1052,7 +1052,7 @@ cam_periph_unmapmem(union ccb *ccb, struct cam_periph_
> vunmapbuf(mapinfo->bp[i]);
>
> /* release the buffer */
> - relpbuf(mapinfo->bp[i], NULL);
> + uma_zfree(pbuf_zone, mapinfo->bp[i]);
> }
>
> /* allow ourselves to be swapped once again */
>
> Modified: head/sys/conf/options
> ==
> --- head/sys/conf/options Tue Jan 15 00:52:41 2019(r343029)
> +++ head/sys/conf/options Tue Jan 1
Re: svn commit: r343118 - in head/usr.sbin: . trim
What I think we really need is some way to easily porti-ze useful stuff that would otherwise go into /usr/[s]bin, so adding things would be just as easy as hooking up SUBDIR into usr.[s]bin/Makefile. Yes, I know, this is topic almost as old as the FreeBSD Project itself, but perhaps we just did not approach it the right way. It was always the idea that we would just move bunch of stuff from src/usr.[s]bin repo into ports/. Which brings several important question such as "who is to host the distfile"? "where sources hosted", "who is to update the port when changes happen?" etc. Perhaps even by forking the whole ports idea into a smaller closely-guarged subset. Something like a new baseports repository, which might have structure like baseports/usr.bin/xxx, baseports/usr.sbin/yyy etc. Then add some automagic glue to kick in on every commit and transfer this into valid ports, which is going to be packaged by the poudriere and such. This way we could reduce amount of port-foo average src committer needs in order to maintain code. I am almost tempted to sit and write something over the next weekend or few of thereofs. Using usr.sbin/trim as an example. -Max On Thu, Jan 17, 2019 at 12:47 PM Cy Schubert wrote: > In message il.com> > , Conrad Meyer writes: > > On Thu, Jan 17, 2019 at 12:22 PM Cy Schubert > wrot > > e: > > > This is wrong. IIRC there was discussion that this should be in dd(1). > > > Why not submit a revision to add the functionality to dd? > > > > Well, it's wrong, but not because we need another weird dd mode. dd > > is hard enough to use already. > > I've never found dd confusing. What's wrong conv=erase? > > If it must stay, sderase is a better name. That's really what it does. > > Ports maybe? > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343124 - head/stand/libsa
Author: tsoome
Date: Thu Jan 17 22:00:02 2019
New Revision: 343124
URL: https://svnweb.freebsd.org/changeset/base/343124
Log:
libsa: add asprintf()
asprintf() is a nice tool for string processing.
MFC after:2 weeks
Modified:
head/stand/libsa/printf.c
head/stand/libsa/stand.h
Modified: head/stand/libsa/printf.c
==
--- head/stand/libsa/printf.c Thu Jan 17 21:52:41 2019(r343123)
+++ head/stand/libsa/printf.c Thu Jan 17 22:00:02 2019(r343124)
@@ -122,6 +122,34 @@ snprint_func(int ch, void *arg)
}
int
+asprintf(char **buf, const char *cfmt, ...)
+{
+ int retval;
+ struct print_buf arg;
+ va_list ap;
+
+ *buf = NULL;
+ va_start(ap, cfmt);
+ retval = kvprintf(cfmt, NULL, NULL, 10, ap);
+ va_end(ap);
+ if (retval <= 0)
+ return (-1);
+
+ arg.size = retval + 1;
+ arg.buf = *buf = malloc(arg.size);
+ if (*buf == NULL)
+ return (-1);
+
+ va_start(ap, cfmt);
+ retval = kvprintf(cfmt, &snprint_func, &arg, 10, ap);
+ va_end(ap);
+
+ if (arg.size >= 1)
+ *(arg.buf)++ = 0;
+ return (retval);
+}
+
+int
snprintf(char *buf, size_t size, const char *cfmt, ...)
{
int retval;
Modified: head/stand/libsa/stand.h
==
--- head/stand/libsa/stand.hThu Jan 17 21:52:41 2019(r343123)
+++ head/stand/libsa/stand.hThu Jan 17 22:00:02 2019(r343124)
@@ -268,6 +268,7 @@ extern void *reallocf(void *ptr, size_t size);
extern voidmallocstats(void);
extern int printf(const char *fmt, ...) __printflike(1, 2);
+extern int asprintf(char **buf, const char *cfmt, ...) __printflike(2, 3);
extern int sprintf(char *buf, const char *cfmt, ...) __printflike(2, 3);
extern int snprintf(char *buf, size_t size, const char *cfmt, ...)
__printflike(3, 4);
extern int vprintf(const char *fmt, __va_list);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343123 - head/stand/libsa/zfs
Author: tsoome
Date: Thu Jan 17 21:52:41 2019
New Revision: 343123
URL: https://svnweb.freebsd.org/changeset/base/343123
Log:
loader should ignore active multi_vdev_crash_dump feature on zpool
Since the loader zfs reader does not need to read the dump zvol, we can
just enable the feature.
illumos issue #9051 https://www.illumos.org/issues/9051
MFC after:2 weeks
Modified:
head/stand/libsa/zfs/zfsimpl.c
Modified: head/stand/libsa/zfs/zfsimpl.c
==
--- head/stand/libsa/zfs/zfsimpl.c Thu Jan 17 21:38:57 2019
(r343122)
+++ head/stand/libsa/zfs/zfsimpl.c Thu Jan 17 21:52:41 2019
(r343123)
@@ -62,6 +62,7 @@ static const char *features_for_read[] = {
"org.illumos:sha512",
"org.illumos:skein",
"org.zfsonlinux:large_dnode",
+ "com.joyent:multi_vdev_crash_dump",
NULL
};
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343122 - head/usr.sbin/freebsd-update
On Thu, Jan 17, 2019 at 1:39 PM Ed Maste wrote:
> Author: emaste
> Date: Thu Jan 17 21:38:57 2019
> New Revision: 343122
> URL: https://svnweb.freebsd.org/changeset/base/343122
>
> Log:
> freebsd-update: Clarify unsupported release upgrade error message
>
> Notify users that upgrading from -CURRENT or -STABLE is unsupported by
> freebsd-update.
>
> Also ensure --currently-running provides a correctly formatted release
> (as done by -r).
>
> PR: 234771
> Submitted by: Gerald Aryeetey
> Reported by: yuri
> Reviewed by: bcran
> MFC after:1 month
> Sponsored by: The FreeBSD Foundation
> Differential Revision:https://reviews.freebsd.org/D18803
>
> Modified:
> head/usr.sbin/freebsd-update/freebsd-update.sh
>
> Modified: head/usr.sbin/freebsd-update/freebsd-update.sh
>
> ==
> --- head/usr.sbin/freebsd-update/freebsd-update.sh Thu Jan 17
> 20:01:06 2019(r343121)
> +++ head/usr.sbin/freebsd-update/freebsd-update.sh Thu Jan 17
> 21:38:57 2019(r343122)
> @@ -304,6 +304,14 @@ config_TargetRelease () {
> fi
> }
>
> +# Pretend current release is FreeBSD $1
> +config_SourceRelease () {
> + UNAME_r=$1
> + if echo ${UNAME_r} | grep -qE '^[0-9.]+$'; then
> + UNAME_r="${UNAME_r}-RELEASE"
> + fi
> +}
> +
> # Define what happens to output of utilities
> config_VerboseLevel () {
> if [ -z ${VERBOSELEVEL} ]; then
> @@ -442,7 +450,8 @@ parse_cmdline () {
> NOTTYOK=1
> ;;
> --currently-running)
> - shift; export UNAME_r="$1"
> + shift
> + config_SourceRelease $1 || usage
> ;;
>
> # Configuration file equivalents
> @@ -657,6 +666,18 @@ fetchupgrade_check_params () {
> ARCH=`uname -m`
> FETCHDIR=${RELNUM}/${ARCH}
> PATCHDIR=${RELNUM}/${ARCH}/bp
> +
> + # Disallow upgrade from a version that is not `-RELEASE`
> + if ! echo "${RELNUM}" | grep -qE -- "-RELEASE$"; then
> + echo -n "`basename $0`: "
> + cat <<- EOF
> + Cannot upgrade from a version that is not a
> '-RELEASE' using `basename $0`.
> + Instead, FreeBSD can be directly upgraded by
> source or upgraded to a
> + RELEASE/RELENG version prior to running `basename
> $0`.
> + EOF
> + echo "System version: ${RELNUM}"
> + exit 1
> + fi
>
I think this would break upgrading from e.g. -BETA or -RC, which is
supported?
Cheers,
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343122 - head/usr.sbin/freebsd-update
Author: emaste
Date: Thu Jan 17 21:38:57 2019
New Revision: 343122
URL: https://svnweb.freebsd.org/changeset/base/343122
Log:
freebsd-update: Clarify unsupported release upgrade error message
Notify users that upgrading from -CURRENT or -STABLE is unsupported by
freebsd-update.
Also ensure --currently-running provides a correctly formatted release
(as done by -r).
PR: 234771
Submitted by: Gerald Aryeetey
Reported by: yuri
Reviewed by: bcran
MFC after:1 month
Sponsored by: The FreeBSD Foundation
Differential Revision:https://reviews.freebsd.org/D18803
Modified:
head/usr.sbin/freebsd-update/freebsd-update.sh
Modified: head/usr.sbin/freebsd-update/freebsd-update.sh
==
--- head/usr.sbin/freebsd-update/freebsd-update.sh Thu Jan 17 20:01:06
2019(r343121)
+++ head/usr.sbin/freebsd-update/freebsd-update.sh Thu Jan 17 21:38:57
2019(r343122)
@@ -304,6 +304,14 @@ config_TargetRelease () {
fi
}
+# Pretend current release is FreeBSD $1
+config_SourceRelease () {
+ UNAME_r=$1
+ if echo ${UNAME_r} | grep -qE '^[0-9.]+$'; then
+ UNAME_r="${UNAME_r}-RELEASE"
+ fi
+}
+
# Define what happens to output of utilities
config_VerboseLevel () {
if [ -z ${VERBOSELEVEL} ]; then
@@ -442,7 +450,8 @@ parse_cmdline () {
NOTTYOK=1
;;
--currently-running)
- shift; export UNAME_r="$1"
+ shift
+ config_SourceRelease $1 || usage
;;
# Configuration file equivalents
@@ -657,6 +666,18 @@ fetchupgrade_check_params () {
ARCH=`uname -m`
FETCHDIR=${RELNUM}/${ARCH}
PATCHDIR=${RELNUM}/${ARCH}/bp
+
+ # Disallow upgrade from a version that is not `-RELEASE`
+ if ! echo "${RELNUM}" | grep -qE -- "-RELEASE$"; then
+ echo -n "`basename $0`: "
+ cat <<- EOF
+ Cannot upgrade from a version that is not a '-RELEASE'
using `basename $0`.
+ Instead, FreeBSD can be directly upgraded by source or
upgraded to a
+ RELEASE/RELENG version prior to running `basename $0`.
+ EOF
+ echo "System version: ${RELNUM}"
+ exit 1
+ fi
# Figure out what directory contains the running kernel
BOOTFILE=`sysctl -n kern.bootfile`
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
On Thu, Jan 17, 2019 at 12:22 PM Cy Schubert wrote: > This is wrong. IIRC there was discussion that this should be in dd(1). > Why not submit a revision to add the functionality to dd? Well, it's wrong, but not because we need another weird dd mode. dd is hard enough to use already. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
18.01.2019 3:23, Conrad Meyer пишет: > Please back it out; stop attributing code review to "hackers@," which > can not (it's a list, not individuals) and did not review this > changeset; and put it on phabricator for actual review. There is already https://reviews.freebsd.org/D18380 by imp and there were over 6 weeks since it had an update. Newly committed code has most of its changes. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
18.01.2019 3:22, Cy Schubert wrote: > This is wrong. IIRC there was discussion that this should be in dd(1). > Why not submit a revision to add the functionality to dd? There is already https://reviews.freebsd.org/D18382 that had no code updates over 6 weeks and latest revision needs a fix as it is broken. Also, dd cannot be used to trim whole several devices with one invocation like "trim ada ada1 ada2". ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
In message , Conrad Meyer writes: > On Thu, Jan 17, 2019 at 12:22 PM Cy Schubert wrot > e: > > This is wrong. IIRC there was discussion that this should be in dd(1). > > Why not submit a revision to add the functionality to dd? > > Well, it's wrong, but not because we need another weird dd mode. dd > is hard enough to use already. I've never found dd confusing. What's wrong conv=erase? If it must stay, sderase is a better name. That's really what it does. Ports maybe? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343118 - in head/usr.sbin: . trim
Please back it out; stop attributing code review to "hackers@," which can not (it's a list, not individuals) and did not review this changeset; and put it on phabricator for actual review. I think summary backout is warranted on the basis of your handling of this last time around and lack of attempt to solicit review for this time. On Thu, Jan 17, 2019 at 10:08 AM Eugene Grosbein wrote: > > Author: eugen > Date: Thu Jan 17 18:07:59 2019 > New Revision: 343118 > URL: https://svnweb.freebsd.org/changeset/base/343118 > > Log: > Re-add new small tool trim(8) to delete contents for blocks > on devices using wear-leveling algorithms as a few weeks passed > after review and discussion of trim(8) ceased and > we still have no utility to perform the job. > > Reviewed by: hackers@ > MFC after:2 weeks > > Added: > head/usr.sbin/trim/ > head/usr.sbin/trim/Makefile (contents, props changed) > head/usr.sbin/trim/trim.8 (contents, props changed) > head/usr.sbin/trim/trim.c (contents, props changed) > Modified: > head/usr.sbin/Makefile > > Modified: head/usr.sbin/Makefile > == > --- head/usr.sbin/Makefile Thu Jan 17 17:36:18 2019(r343117) > +++ head/usr.sbin/Makefile Thu Jan 17 18:07:59 2019(r343118) > @@ -92,6 +92,7 @@ SUBDIR= adduser \ > tcpdrop \ > tcpdump \ > traceroute \ > + trim \ > trpt \ > tzsetup \ > ugidfw \ > > Added: head/usr.sbin/trim/Makefile > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/usr.sbin/trim/Makefile Thu Jan 17 18:07:59 2019(r343118) > @@ -0,0 +1,8 @@ > +# $FreeBSD$ > + > +PROG= trim > +MAN= trim.8 > +LIBADD=util > +LDFLAGS= -lutil > + > +.include > > Added: head/usr.sbin/trim/trim.8 > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/usr.sbin/trim/trim.8 Thu Jan 17 18:07:59 2019(r343118) > @@ -0,0 +1,167 @@ > +.\" > +.\" Copyright (c) 2019 Eugene Grosbein . > +.\" All rights reserved. > +.\" > +.\" Redistribution and use in source and binary forms, with or without > +.\" modification, are permitted provided that the following conditions > +.\" are met: > +.\" 1. Redistributions of source code must retain the above copyright > +.\"notice, this list of conditions and the following disclaimer. > +.\" 2. Redistributions in binary form must reproduce the above copyright > +.\"notice, this list of conditions and the following disclaimer in the > +.\"documentation and/or other materials provided with the distribution. > +.\" > +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > CONSEQUENTIAL > +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > STRICT > +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > +.\" SUCH DAMAGE. > +.\" > +.\" $FreeBSD$ > +.\" > +.Dd January 18, 2019 > +.Dt TRIM 8 > +.Os > +.Sh NAME > +.Nm trim > +.Nd erase device blocks that have no needed contents > +.Sh SYNOPSIS > +.Nm > +.Op Fl Nfqv > +.Fl [ [lo] Xo > +.Bk -words > +.Sm off > +.Ar offset > +.Op Cm K | k | M | m | G | g | T | t ] > +.Sm on > +.Xc > +.Ek > +.Bk -words > +.Op Fl r Ar rfile > +.Ek > +.Ar device ... > +.Sh DESCRIPTION > +The > +.Nm > +utility erases specified region of the device. > +It is mostly relevant for storage that implement trim (like flash based, > +or thinly provisioned storage). > +.Sy All erased data is lost. > +.Pp > +The following options are available: > +.Bl -tag -width indent > +.It Fl N > +Do not actually erase anything but show what it would do (dry run). > +Implies > +.Fl v . > +This is the default. Overrides > +.Fl f . > +.It Fl f > +Perform the operation. Overrides > +.Fl N . > +.It Fl l Xo > +.Sm off > +.Ar offset > +.Op Cm K | k | M | m | G | g | T | t > +.Sm on > +.Xc > +.It Fl o Xo > +.Sm off > +.Ar offset > +.Op Cm K | k | M | m | G | g | T | t > +.Sm on > +.Xc > +Specify the length > +.Fl l > +of the region to trim or its offset > +.Fl o > +from the beginning of the device. > +.Sy The whole device is erased by default > +unless one or both of these options are presented. > +.Pp > +The argument may be suffixed
Re: svn commit: r343118 - in head/usr.sbin: . trim
In message <201901171808.x0hi80jc068...@repo.freebsd.org>, Eugene Grosbein writ es: > Author: eugen > Date: Thu Jan 17 18:07:59 2019 > New Revision: 343118 > URL: https://svnweb.freebsd.org/changeset/base/343118 > > Log: > Re-add new small tool trim(8) to delete contents for blocks > on devices using wear-leveling algorithms as a few weeks passed > after review and discussion of trim(8) ceased and > we still have no utility to perform the job. > > Reviewed by:hackers@ > MFC after: 2 weeks > > Added: > head/usr.sbin/trim/ > head/usr.sbin/trim/Makefile (contents, props changed) > head/usr.sbin/trim/trim.8 (contents, props changed) > head/usr.sbin/trim/trim.c (contents, props changed) > Modified: > head/usr.sbin/Makefile > This is wrong. IIRC there was discussion that this should be in dd(1). Why not submit a revision to add the functionality to dd? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343121 - head/usr.sbin/nscd
Author: trasz
Date: Thu Jan 17 20:01:06 2019
New Revision: 343121
URL: https://svnweb.freebsd.org/changeset/base/343121
Log:
Workaround for nscd(8) failure with large entries.
It fixes a case where eg a 2KB group entry would take several seconds
to complete with cache enabled in nsswitch.conf.
MFC after:2 weeks
Sponsored by: Chalmers University of Technology
Differential Revision:https://reviews.freebsd.org/D18392
Modified:
head/usr.sbin/nscd/nscd.c
Modified: head/usr.sbin/nscd/nscd.c
==
--- head/usr.sbin/nscd/nscd.c Thu Jan 17 19:44:47 2019(r343120)
+++ head/usr.sbin/nscd/nscd.c Thu Jan 17 20:01:06 2019(r343121)
@@ -405,6 +405,12 @@ process_socket_event(struct kevent *event_data, struct
* process_socket_event).
*/
if (qstate->kevent_watermark > MAX_SOCKET_IO_SIZE) {
+#if 0
+ /*
+* XXX: Uncommenting this code makes nscd(8) fail for
+* entries larger than a few kB, causing few second
+* worth of delay for each call to retrieve them.
+*/
if (qstate->io_buffer != NULL)
free(qstate->io_buffer);
@@ -421,6 +427,7 @@ process_socket_event(struct kevent *event_data, struct
if (qstate->kevent_filter == EVFILT_READ)
qstate->use_alternate_io = 1;
+#endif
qstate->io_buffer_watermark = MAX_SOCKET_IO_SIZE;
EV_SET(&eventlist[1], event_data->ident,
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343120 - in head/sys/x86: include x86
Author: cem
Date: Thu Jan 17 19:44:47 2019
New Revision: 343120
URL: https://svnweb.freebsd.org/changeset/base/343120
Log:
Add definitions for AMD Spectre/Meltdown CPUID information
No functional change, aside from printing recognized bits in CPU
identification.
The bits are documented in 111006-B "Indirect Branch Control Extension"[1] and
124441 "Speculative Store Bypass Disable."[2]
Notably missing (left as future work):
* Integration with hw.spec_store_bypass_disable and hw_ssb_active flag,
which are currently Intel-specific
* Integration with hw_ibrs_active global flag, which are currently
Intel-specific
* SSB_NO integration in hw_ssb_recalculate()
* Bhyve integration (PR 235010)
[1]:
https://developer.amd.com/wp-content/resources/111006-B_AMD64TechnologyIndirectBranchControlExtenstion_WP_7-18Update_FNL.pdf
[2]:
https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
PR: 235010 (related, but does not fix)
MFC after:a week
Modified:
head/sys/x86/include/specialreg.h
head/sys/x86/x86/identcpu.c
Modified: head/sys/x86/include/specialreg.h
==
--- head/sys/x86/include/specialreg.h Thu Jan 17 18:51:56 2019
(r343119)
+++ head/sys/x86/include/specialreg.h Thu Jan 17 19:44:47 2019
(r343120)
@@ -374,6 +374,17 @@
#defineAMDFEID_CLZERO 0x0001
#defineAMDFEID_IRPERF 0x0002
#defineAMDFEID_XSAVEERPTR 0x0004
+#defineAMDFEID_IBPB0x1000
+#defineAMDFEID_IBRS0x4000
+#defineAMDFEID_STIBP 0x8000
+/* The below are only defined if the corresponding base feature above exists.
*/
+#defineAMDFEID_IBRS_ALWAYSON 0x0001
+#defineAMDFEID_STIBP_ALWAYSON 0x0002
+#defineAMDFEID_PREFER_IBRS 0x0004
+#defineAMDFEID_SSBD0x0100
+/* SSBD via MSRC001_011F instead of MSR 0x48: */
+#defineAMDFEID_VIRT_SSBD 0x0200
+#defineAMDFEID_SSB_NO 0x0400
/*
* AMD extended function 8000_0008h ecx info
@@ -719,6 +730,10 @@
/*
* IA32_SPEC_CTRL and IA32_PRED_CMD MSRs are described in the Intel'
* document 336996-001 Speculative Execution Side Channel Mitigations.
+ *
+ * AMD uses the same MSRs and bit definitions, as described in 111006-B
+ * "Indirect Branch Control Extension" and 124441 "Speculative Store Bypass
+ * Disable."
*/
/* MSR IA32_SPEC_CTRL */
#defineIA32_SPEC_CTRL_IBRS 0x0001
Modified: head/sys/x86/x86/identcpu.c
==
--- head/sys/x86/x86/identcpu.c Thu Jan 17 18:51:56 2019(r343119)
+++ head/sys/x86/x86/identcpu.c Thu Jan 17 19:44:47 2019(r343120)
@@ -1021,13 +1021,34 @@ printcpuinfo(void)
}
if (amd_extended_feature_extensions != 0) {
+ u_int amd_fe_masked;
+
+ amd_fe_masked = amd_extended_feature_extensions;
+ if ((amd_fe_masked & AMDFEID_IBRS) == 0)
+ amd_fe_masked &=
+ ~(AMDFEID_IBRS_ALWAYSON |
+ AMDFEID_PREFER_IBRS);
+ if ((amd_fe_masked & AMDFEID_STIBP) == 0)
+ amd_fe_masked &=
+ ~AMDFEID_STIBP_ALWAYSON;
+
printf("\n "
"AMD Extended Feature Extensions ID EBX="
- "0x%b", amd_extended_feature_extensions,
+ "0x%b", amd_fe_masked,
"\020"
"\001CLZERO"
"\002IRPerf"
- "\003XSaveErPtr");
+ "\003XSaveErPtr"
+ "\015IBPB"
+ "\017IBRS"
+ "\020STIBP"
+ "\021IBRS_ALWAYSON"
+ "\022STIBP_ALWAYSON"
+ "\023PREFER_IBRS"
+ "\031SSBD"
+ "\032VIRT_SSBD"
+ "\033SSB_NO"
+ );
}
if (via_feature_rng != 0 || via_feature_xcrypt != 0)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubs
Re: svn commit: r343113 - head/contrib/libc++/include
> From:Andriy Gapon > Date:Thu, 17 Jan 2019 19:05:20 +0200 > To: Kirk McKusick , src-committ...@freebsd.org, >svn-src-all@freebsd.org, svn-src-h...@freebsd.org > Subject: Re: svn commit: r343113 - head/contrib/libc++/include > > On 17/01/2019 17:35, Kirk McKusick wrote: >> -#ifdef ELAST >> +#if defined(ELAST) > > I think that these are exactly the same, so not sure what the change does. > > -- > Andriy Gapon It was suggested to me that Clang was 'strict' and that it would kick out the first form. That proved to not be true. To compound my goof, I missed the actual fix when I did the commit, so had to do -r343115 to get the needed part of the fix in place. I should learn to have my morning coffee *before* commiting anything. Kirk McKusick ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343119 - head/sys/arm/allwinner
Author: kevans
Date: Thu Jan 17 18:51:56 2019
New Revision: 343119
URL: https://svnweb.freebsd.org/changeset/base/343119
Log:
Revert r343095
This was intended to fix the soft reset timeout on boot for OrangePi One/R1
with internal PHY, but seems to cause other problems later on due to soft
resetting around some state changes that may or may not make the NIC
non-functional.
Reverting this for now while a better solution is sought out.
Modified:
head/sys/arm/allwinner/if_awg.c
Modified: head/sys/arm/allwinner/if_awg.c
==
--- head/sys/arm/allwinner/if_awg.c Thu Jan 17 18:07:59 2019
(r343118)
+++ head/sys/arm/allwinner/if_awg.c Thu Jan 17 18:51:56 2019
(r343119)
@@ -750,31 +750,6 @@ awg_disable_intr(struct awg_softc *sc)
WR4(sc, EMAC_INT_EN, 0);
}
-static int
-awg_reset(struct awg_softc *sc)
-{
- int retry;
-
- /* Soft reset all registers and logic */
- WR4(sc, EMAC_BASIC_CTL_1, BASIC_CTL_SOFT_RST);
-
- /* Wait for soft reset bit to self-clear */
- for (retry = SOFT_RST_RETRY; retry > 0; retry--) {
- if ((RD4(sc, EMAC_BASIC_CTL_1) & BASIC_CTL_SOFT_RST) == 0)
- break;
- DELAY(10);
- }
- if (retry == 0) {
- device_printf(sc->dev, "soft reset timed out\n");
-#ifdef AWG_DEBUG
- awg_dump_regs(sc->dev);
-#endif
- return (ETIMEDOUT);
- }
-
- return (0);
-}
-
static void
awg_init_locked(struct awg_softc *sc)
{
@@ -790,12 +765,6 @@ awg_init_locked(struct awg_softc *sc)
if (if_getdrvflags(ifp) & IFF_DRV_RUNNING)
return;
- awg_reset(sc);
-
- /* Write transmit and receive descriptor base address registers */
- WR4(sc, EMAC_TX_DMA_LIST, sc->tx.desc_ring_paddr);
- WR4(sc, EMAC_RX_DMA_LIST, sc->rx.desc_ring_paddr);
-
awg_setup_rxfilter(sc);
/* Configure DMA burst length and priorities */
@@ -1684,6 +1653,40 @@ awg_phy_reset(device_t dev)
return (0);
}
+static int
+awg_reset(device_t dev)
+{
+ struct awg_softc *sc;
+ int retry;
+
+ sc = device_get_softc(dev);
+
+ /* Reset PHY if necessary */
+ if (awg_phy_reset(dev) != 0) {
+ device_printf(dev, "failed to reset PHY\n");
+ return (ENXIO);
+ }
+
+ /* Soft reset all registers and logic */
+ WR4(sc, EMAC_BASIC_CTL_1, BASIC_CTL_SOFT_RST);
+
+ /* Wait for soft reset bit to self-clear */
+ for (retry = SOFT_RST_RETRY; retry > 0; retry--) {
+ if ((RD4(sc, EMAC_BASIC_CTL_1) & BASIC_CTL_SOFT_RST) == 0)
+ break;
+ DELAY(10);
+ }
+ if (retry == 0) {
+ device_printf(dev, "soft reset timed out\n");
+#ifdef AWG_DEBUG
+ awg_dump_regs(dev);
+#endif
+ return (ETIMEDOUT);
+ }
+
+ return (0);
+}
+
static void
awg_dmamap_cb(void *arg, bus_dma_segment_t *segs, int nseg, int error)
{
@@ -1837,6 +1840,10 @@ awg_setup_dma(device_t dev)
bus_dmamap_sync(sc->rx.desc_tag, sc->rx.desc_map,
BUS_DMASYNC_PREWRITE);
+ /* Write transmit and receive descriptor base address registers */
+ WR4(sc, EMAC_TX_DMA_LIST, sc->tx.desc_ring_paddr);
+ WR4(sc, EMAC_RX_DMA_LIST, sc->rx.desc_ring_paddr);
+
return (0);
}
@@ -1881,12 +1888,10 @@ awg_attach(device_t dev)
/* Read MAC address before resetting the chip */
awg_get_eaddr(dev, eaddr);
- /* Reset PHY if necessary */
- error = awg_phy_reset(dev);
- if (error != 0) {
- device_printf(dev, "failed to reset PHY\n");
+ /* Soft reset EMAC core */
+ error = awg_reset(dev);
+ if (error != 0)
return (error);
- }
/* Setup DMA descriptors */
error = awg_setup_dma(dev);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343118 - in head/usr.sbin: . trim
Author: eugen Date: Thu Jan 17 18:07:59 2019 New Revision: 343118 URL: https://svnweb.freebsd.org/changeset/base/343118 Log: Re-add new small tool trim(8) to delete contents for blocks on devices using wear-leveling algorithms as a few weeks passed after review and discussion of trim(8) ceased and we still have no utility to perform the job. Reviewed by: hackers@ MFC after:2 weeks Added: head/usr.sbin/trim/ head/usr.sbin/trim/Makefile (contents, props changed) head/usr.sbin/trim/trim.8 (contents, props changed) head/usr.sbin/trim/trim.c (contents, props changed) Modified: head/usr.sbin/Makefile Modified: head/usr.sbin/Makefile == --- head/usr.sbin/Makefile Thu Jan 17 17:36:18 2019(r343117) +++ head/usr.sbin/Makefile Thu Jan 17 18:07:59 2019(r343118) @@ -92,6 +92,7 @@ SUBDIR= adduser \ tcpdrop \ tcpdump \ traceroute \ + trim \ trpt \ tzsetup \ ugidfw \ Added: head/usr.sbin/trim/Makefile == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/usr.sbin/trim/Makefile Thu Jan 17 18:07:59 2019(r343118) @@ -0,0 +1,8 @@ +# $FreeBSD$ + +PROG= trim +MAN= trim.8 +LIBADD=util +LDFLAGS= -lutil + +.include Added: head/usr.sbin/trim/trim.8 == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/usr.sbin/trim/trim.8 Thu Jan 17 18:07:59 2019(r343118) @@ -0,0 +1,167 @@ +.\" +.\" Copyright (c) 2019 Eugene Grosbein . +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\"notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\"notice, this list of conditions and the following disclaimer in the +.\"documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd January 18, 2019 +.Dt TRIM 8 +.Os +.Sh NAME +.Nm trim +.Nd erase device blocks that have no needed contents +.Sh SYNOPSIS +.Nm +.Op Fl Nfqv +.Fl [ [lo] Xo +.Bk -words +.Sm off +.Ar offset +.Op Cm K | k | M | m | G | g | T | t ] +.Sm on +.Xc +.Ek +.Bk -words +.Op Fl r Ar rfile +.Ek +.Ar device ... +.Sh DESCRIPTION +The +.Nm +utility erases specified region of the device. +It is mostly relevant for storage that implement trim (like flash based, +or thinly provisioned storage). +.Sy All erased data is lost. +.Pp +The following options are available: +.Bl -tag -width indent +.It Fl N +Do not actually erase anything but show what it would do (dry run). +Implies +.Fl v . +This is the default. Overrides +.Fl f . +.It Fl f +Perform the operation. Overrides +.Fl N . +.It Fl l Xo +.Sm off +.Ar offset +.Op Cm K | k | M | m | G | g | T | t +.Sm on +.Xc +.It Fl o Xo +.Sm off +.Ar offset +.Op Cm K | k | M | m | G | g | T | t +.Sm on +.Xc +Specify the length +.Fl l +of the region to trim or its offset +.Fl o +from the beginning of the device. +.Sy The whole device is erased by default +unless one or both of these options are presented. +.Pp +The argument may be suffixed with one of +.Cm K , +.Cm M , +.Cm G +or +.Cm T +(either upper or lower case) to indicate a multiple of +Kilobytes, Megabytes, Gigabytes or Terabytes +respectively. +.It Fl q +Do not output anything except of possible error messages (quiet mode). +Overrides +.Fl v . +.It Fl r Ar rfile +Uses the length of given +.Ar rfile +as length of the region to erase. +.Sy The whole device is erased by default. +.It Fl v +Show offset and length of actual region being erased, in bytes. +.El +.Pp +Later options override previous ones. +.Pp +Note that actual success of the operation depends of underlying +device driver such as +.Xr ada 4 , +.Xr da 4 +and others. +Refer to corresponding m
svn commit: r343117 - head/usr.bin/cmp
Author: markj
Date: Thu Jan 17 17:36:18 2019
New Revision: 343117
URL: https://svnweb.freebsd.org/changeset/base/343117
Log:
Fix handling of rights on stdio streams.
- Limit rights on stdio before opening input files. Otherwise, open()
may return one of the standard descriptors and we end up limiting
rights such that we cannot read from one of the input files.
- Use caph_limit_stdio(), which suppresses EBADF, to ensure that
we don't emit an error if one of the stdio streams is closed.
- Don't bother further limiting rights on stdin when stdin isn't going
to be used. Doing so correctly requires checking for a number of
edge cases, and it doesn't provide any significant benefit.
PR: 234885
Reviewed by: oshogbo
MFC after:3 days
Sponsored by: The FreeBSD Foundation
Differential Revision:https://reviews.freebsd.org/D18860
Modified:
head/usr.bin/cmp/cmp.c
Modified: head/usr.bin/cmp/cmp.c
==
--- head/usr.bin/cmp/cmp.c Thu Jan 17 16:50:50 2019(r343116)
+++ head/usr.bin/cmp/cmp.c Thu Jan 17 17:36:18 2019(r343117)
@@ -116,14 +116,16 @@ main(int argc, char *argv[])
if (argc < 2 || argc > 4)
usage();
+ if (caph_limit_stdio() == -1)
+ err(ERR_EXIT, "failed to limit stdio");
+
/* Backward compatibility -- handle "-" meaning stdin. */
special = 0;
if (strcmp(file1 = argv[0], "-") == 0) {
special = 1;
- fd1 = 0;
+ fd1 = STDIN_FILENO;
file1 = "stdin";
- }
- else if ((fd1 = open(file1, oflag, 0)) < 0 && errno != EMLINK) {
+ } else if ((fd1 = open(file1, oflag, 0)) < 0 && errno != EMLINK) {
if (!sflag)
err(ERR_EXIT, "%s", file1);
else
@@ -134,10 +136,9 @@ main(int argc, char *argv[])
errx(ERR_EXIT,
"standard input may only be specified once");
special = 1;
- fd2 = 0;
+ fd2 = STDIN_FILENO;
file2 = "stdin";
- }
- else if ((fd2 = open(file2, oflag, 0)) < 0 && errno != EMLINK) {
+ } else if ((fd2 = open(file2, oflag, 0)) < 0 && errno != EMLINK) {
if (!sflag)
err(ERR_EXIT, "%s", file2);
else
@@ -174,16 +175,6 @@ main(int argc, char *argv[])
err(ERR_EXIT, "unable to limit fcntls for %s", file1);
if (caph_fcntls_limit(fd2, fcntls) < 0)
err(ERR_EXIT, "unable to limit fcntls for %s", file2);
-
- if (!special) {
- cap_rights_init(&rights);
- if (caph_rights_limit(STDIN_FILENO, &rights) < 0) {
- err(ERR_EXIT, "unable to limit stdio");
- }
- }
-
- if (caph_limit_stdout() == -1 || caph_limit_stderr() == -1)
- err(ERR_EXIT, "unable to limit stdio");
caph_cache_catpages();
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343113 - head/contrib/libc++/include
On 17/01/2019 17:35, Kirk McKusick wrote: > -#ifdef ELAST > +#if defined(ELAST) I think that these are exactly the same, so not sure what the change does. -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343116 - in head: include lib/libc/gen libexec/rtld-elf
Author: des
Date: Thu Jan 17 16:50:50 2019
New Revision: 343116
URL: https://svnweb.freebsd.org/changeset/base/343116
Log:
Revert r343093 until I can address the issues raised by kib@.
Modified:
head/include/dlfcn.h
head/lib/libc/gen/dlopen.3
head/libexec/rtld-elf/rtld.c
Modified: head/include/dlfcn.h
==
--- head/include/dlfcn.hThu Jan 17 16:26:59 2019(r343115)
+++ head/include/dlfcn.hThu Jan 17 16:50:50 2019(r343116)
@@ -120,7 +120,6 @@ void*dlopen(const char *, int);
void *dlsym(void * __restrict, const char * __restrict);
#if __BSD_VISIBLE
-void *dlopenat(int, const char *, int);
void *fdlopen(int, int);
int dladdr(const void * __restrict, Dl_info * __restrict);
dlfunc_t dlfunc(void * __restrict, const char * __restrict);
Modified: head/lib/libc/gen/dlopen.3
==
--- head/lib/libc/gen/dlopen.3 Thu Jan 17 16:26:59 2019(r343115)
+++ head/lib/libc/gen/dlopen.3 Thu Jan 17 16:50:50 2019(r343116)
@@ -32,12 +32,11 @@
.\" @(#) dlopen.3 1.6 90/01/31 SMI
.\" $FreeBSD$
.\"
-.Dd January 15, 2019
+.Dd January 2, 2019
.Dt DLOPEN 3
.Os
.Sh NAME
.Nm dlopen ,
-.Nm dlopenat ,
.Nm fdlopen ,
.Nm dlsym ,
.Nm dlvsym ,
@@ -52,8 +51,6 @@
.Ft void *
.Fn dlopen "const char *path" "int mode"
.Ft void *
-.Fn dlopenat "int fd" "const char *path" "int mode"
-.Ft void *
.Fn fdlopen "int fd" "int mode"
.Ft void *
.Fn dlsym "void * restrict handle" "const char * restrict symbol"
@@ -172,24 +169,6 @@ If
fails, it returns a null pointer, and sets an error condition which may
be interrogated with
.Fn dlerror .
-.Pp
-The
-.Fn dlopenat
-function is equivalent to
-.Fn dlopen
-except in the case where the path specifies a relative path.
-In this case the file to be opened is determined relative to the
-directory associated with the file descriptor fd instead of the
-current working directory.
-If
-.Fn dlopenat
-is passed the special value
-.Dv AT_FDCWD
-in the
-.Fa fd
-parameter, the current working directory is used and the behavior is
-identical to a call to
-.Fn dlopen .
.Pp
The
.Fn fdlopen
Modified: head/libexec/rtld-elf/rtld.c
==
--- head/libexec/rtld-elf/rtld.cThu Jan 17 16:26:59 2019
(r343115)
+++ head/libexec/rtld-elf/rtld.cThu Jan 17 16:50:50 2019
(r343116)
@@ -93,8 +93,8 @@ static void digest_dynamic(Obj_Entry *, int);
static Obj_Entry *digest_phdr(const Elf_Phdr *, int, caddr_t, const char *);
static Obj_Entry *dlcheck(void *);
static int dlclose_locked(void *, RtldLockState *);
-static Obj_Entry *dlopen_object(int, const char *name, int fd,
-Obj_Entry *refobj, int lo_flags, int mode, RtldLockState *lockstate);
+static Obj_Entry *dlopen_object(const char *name, int fd, Obj_Entry *refobj,
+int lo_flags, int mode, RtldLockState *lockstate);
static Obj_Entry *do_load_object(int, const char *, char *, struct stat *,
int);
static int do_search_info(const Obj_Entry *obj, int, struct dl_serinfo *);
static bool donelist_check(DoneList *, const Obj_Entry *);
@@ -118,7 +118,7 @@ static void load_filtees(Obj_Entry *, int flags, RtldL
static void unload_filtees(Obj_Entry *, RtldLockState *);
static int load_needed_objects(Obj_Entry *, int);
static int load_preload_objects(void);
-static Obj_Entry *load_object(int, const char *, int, const Obj_Entry *, int);
+static Obj_Entry *load_object(const char *, int fd, const Obj_Entry *, int);
static void map_stacks_exec(RtldLockState *);
static int obj_disable_relro(Obj_Entry *);
static int obj_enforce_relro(Obj_Entry *);
@@ -147,7 +147,7 @@ static int relocate_objects(Obj_Entry *, bool, Obj_Ent
static int resolve_object_ifunc(Obj_Entry *, bool, int, RtldLockState *);
static int rtld_dirname(const char *, char *);
static int rtld_dirname_abs(const char *, char *);
-static void *rtld_dlopen(int, const char *name, int fd, int mode);
+static void *rtld_dlopen(const char *name, int fd, int mode);
static void rtld_exit(void);
static char *search_library_path(const char *, const char *, const char *,
int *);
@@ -231,7 +231,6 @@ extern Elf_Dyn _DYNAMIC;
int dlclose(void *) __exported;
char *dlerror(void) __exported;
void *dlopen(const char *, int) __exported;
-void *dlopenat(int, const char *, int) __exported;
void *fdlopen(int, int) __exported;
void *dlsym(void *, const char *) __exported;
dlfunc_t dlfunc(void *, const char *) __exported;
@@ -2293,8 +2292,8 @@ load_filtee1(Obj_Entry *obj, Needed_Entry *needed, int
{
for (; needed != NULL; needed = needed->next) {
- needed->obj = dlopen_object(AT_FDCWD, obj->strtab + needed->name, -1,
- obj, flags, ((ld_loadfltr || obj->z_loadfltr) ? RTLD_NOW : RTLD_LAZY)
|
+ needed->obj = dlopen_object(obj->strtab + needed->name, -1, obj,
+
svn commit: r343115 - head/contrib/libc++/include
Author: mckusick Date: Thu Jan 17 16:26:59 2019 New Revision: 343115 URL: https://svnweb.freebsd.org/changeset/base/343115 Log: Truely fix #if defined broken in -r343111 Pointy-hat-to: mckusick Modified: head/contrib/libc++/include/errno.h Modified: head/contrib/libc++/include/errno.h == --- head/contrib/libc++/include/errno.h Thu Jan 17 15:42:10 2019 (r343114) +++ head/contrib/libc++/include/errno.h Thu Jan 17 16:26:59 2019 (r343115) @@ -56,6 +56,7 @@ static const int __elast3 = 106; #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -63,6 +64,7 @@ static const int __elast3 = 106; #if defined(ELAST) #undef ELAST #define ELAST EOWNERDEAD +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EOWNERDEAD __elast1 @@ -70,12 +72,14 @@ static const int __elast3 = 106; #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define EOWNERDEAD __elast1 #if defined(ELAST) #undef ELAST #define ELAST EOWNERDEAD +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 @@ -83,18 +87,21 @@ static const int __elast3 = 106; #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 #if defined(ELAST) #undef ELAST #define ELAST ENOTRECOVERABLE +#endif #elif defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EINTEGRITY __elast1 #if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY +#endif #endif // !defined(OWNERDEAD) && !defined(NOTRECOVERABLE) && !defined(INTEGRITY) ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343111 - in head: cddl/lib/libdtrace contrib/libc++/include contrib/libxo/tests/gettext contrib/libxo/tests/gettext/po/pig_latin contrib/openbsm/libbsm contrib/openbsm/sys/bsm lib/lib
Per my previous email, it is fixed in -r343114 not -r343113. Kirk McKusick ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343111 - in head: cddl/lib/libdtrace contrib/libc++/include contrib/libxo/tests/gettext contrib/libxo/tests/gettext/po/pig_latin contrib/openbsm/libbsm contrib/openbsm/sys/bsm lib/lib
Thanks for your analysis. Now fixed in -r343113. Kirk McKusick ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r343111 - in head: cddl/lib/libdtrace contrib/libc++/include contrib/libxo/tests/gettext contrib/libxo/tests/gettext/po/pig_latin contrib/openbsm/libbsm contrib/openbsm/sys/bsm lib/lib
Thanks for your pointer to the problem. Now fixed in -r343113. Kirk McKusick ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343114 - head/contrib/libc++/include
Author: mckusick Date: Thu Jan 17 15:42:10 2019 New Revision: 343114 URL: https://svnweb.freebsd.org/changeset/base/343114 Log: Proper definition of elast3. Reported by: Oliver Pinter Modified: head/contrib/libc++/include/errno.h Modified: head/contrib/libc++/include/errno.h == --- head/contrib/libc++/include/errno.h Thu Jan 17 15:35:04 2019 (r343113) +++ head/contrib/libc++/include/errno.h Thu Jan 17 15:42:10 2019 (r343114) @@ -39,13 +39,13 @@ Macros: static const int __elast1 = ELAST+1; static const int __elast2 = ELAST+2; -static const int __elast2 = ELAST+3; +static const int __elast3 = ELAST+3; #else static const int __elast1 = 104; static const int __elast2 = 105; -static const int __elast2 = 106; +static const int __elast3 = 106; #endif ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343113 - head/contrib/libc++/include
Author: mckusick Date: Thu Jan 17 15:35:04 2019 New Revision: 343113 URL: https://svnweb.freebsd.org/changeset/base/343113 Log: Fix #if defined broken in -r343111 Pointy-hat-to: mckusick Modified: head/contrib/libc++/include/errno.h Modified: head/contrib/libc++/include/errno.h == --- head/contrib/libc++/include/errno.h Thu Jan 17 14:09:55 2019 (r343112) +++ head/contrib/libc++/include/errno.h Thu Jan 17 15:35:04 2019 (r343113) @@ -35,7 +35,7 @@ Macros: #if !defined(EOWNERDEAD) || !defined(ENOTRECOVERABLE) || !defined(EINTEGRITY) -#ifdef ELAST +#if defined(ELAST) static const int __elast1 = ELAST+1; static const int __elast2 = ELAST+2; @@ -53,46 +53,46 @@ static const int __elast2 = 106; #define ENOTRECOVERABLE __elast1 #define EOWNERDEAD __elast2 #define EINTEGRITY __elast3 -#ifdef ELAST +#if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY #elif !defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 #define EOWNERDEAD __elast2 -#ifdef ELAST +#if defined(ELAST) #undef ELAST #define ELAST EOWNERDEAD #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EOWNERDEAD __elast1 #define EINTEGRITY __elast2 -#ifdef ELAST +#if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY #elif !defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define EOWNERDEAD __elast1 -#ifdef ELAST +#if defined(ELAST) #undef ELAST #define ELAST EOWNERDEAD #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 #define EINTEGRITY __elast2 -#ifdef ELAST +#if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY #elif defined(EOWNERDEAD) && !defined(ENOTRECOVERABLE) && defined(EINTEGRITY) #define ENOTRECOVERABLE __elast1 -#ifdef ELAST +#if defined(ELAST) #undef ELAST #define ELAST ENOTRECOVERABLE #elif defined(EOWNERDEAD) && defined(ENOTRECOVERABLE) && !defined(EINTEGRITY) #define EINTEGRITY __elast1 -#ifdef ELAST +#if defined(ELAST) #undef ELAST #define ELAST EINTEGRITY ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r343112 - head/usr.sbin/jail
Author: eugen
Date: Thu Jan 17 14:09:55 2019
New Revision: 343112
URL: https://svnweb.freebsd.org/changeset/base/343112
Log:
jail(8): stop crashing with SIGSEGV inside run_command() function
while processing not entirely correct jail.conf(5) file
having something like "ip4.addr = 127.0.0.1;" and no "ip4 = ...;"
so extrap variable stays NULL.
Reported by: marck
MFC after:1 month
Modified:
head/usr.sbin/jail/command.c
Modified: head/usr.sbin/jail/command.c
==
--- head/usr.sbin/jail/command.cThu Jan 17 06:35:45 2019
(r343111)
+++ head/usr.sbin/jail/command.cThu Jan 17 14:09:55 2019
(r343112)
@@ -374,7 +374,7 @@ run_command(struct cfjail *j)
argc = 4;
}
- if (!down) {
+ if (!down && extrap != NULL) {
for (cs = strtok(extrap, " "); cs;
cs = strtok(NULL, " ")) {
size_t len = strlen(cs) + 1;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
