Re: svn commit: r250435 - head/sys/boot/fdt/dts
On 2013-05-09, at 10:34 PM, Tim Kientzle kient...@freebsd.org wrote: Author: kientzle Date: Fri May 10 05:34:08 2013 New Revision: 250435 URL: http://svnweb.freebsd.org/changeset/base/250435 Log: Move 'compatible' line out of the common am335x.dtsi and into the beaglebone-specific .dts file. Add a new .dts for the BeagleBone Black with more memory, slightly different pinmux initialization, and with mmchs1 configured (though the latter doesn't quite work yet). Thanks for sorting this out, Tim. ___ 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: r250436 - head/sys/contrib/octeon-sdk
Author: imp Date: Fri May 10 06:28:01 2013 New Revision: 250436 URL: http://svnweb.freebsd.org/changeset/base/250436 Log: Make the read/write routines default to the newer DS1337 part, but keep the supported bits board specific. Modified: head/sys/contrib/octeon-sdk/cvmx-rtc.h Modified: head/sys/contrib/octeon-sdk/cvmx-rtc.h == --- head/sys/contrib/octeon-sdk/cvmx-rtc.h Fri May 10 05:34:08 2013 (r250435) +++ head/sys/contrib/octeon-sdk/cvmx-rtc.h Fri May 10 06:28:01 2013 (r250436) @@ -126,18 +126,9 @@ static inline uint32_t cvmx_rtc_read(voi return cvmx_rtc_ds1374_read(); break; -case CVMX_BOARD_TYPE_EBH3000: -case CVMX_BOARD_TYPE_CN3010_EVB_HS5: -case CVMX_BOARD_TYPE_EBH5200: -#if defined(OCTEON_VENDOR_GEFES) -case CVMX_BOARD_TYPE_CUST_W63XX: -#endif +default: return cvmx_rtc_ds1337_read(); break; - -default: -return 0; -break; } } @@ -156,18 +147,9 @@ static inline uint32_t cvmx_rtc_write(ui return cvmx_rtc_ds1374_write(time); break; -case CVMX_BOARD_TYPE_EBH3000: -case CVMX_BOARD_TYPE_CN3010_EVB_HS5: -case CVMX_BOARD_TYPE_EBH5200: -#if defined(OCTEON_VENDOR_GEFES) -case CVMX_BOARD_TYPE_CUST_W63XX: -#endif +default: return cvmx_rtc_ds1337_write(time); break; - -default: -return 0; -break; } } ___ 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: r250430 - head/sbin/dmesg
On Fri, May 10, 2013 at 03:42:48AM +, Eitan Adler wrote:
New Revision: 250430
URL: http://svnweb.freebsd.org/changeset/base/250430
@@ -79,15 +80,20 @@ main(int argc, char *argv[])
kvm_t *kd;
size_t buflen, bufpos;
long pri;
- int all, ch;
+ int ch, clear;
+ bool all;
- all = 0;
+ all = false;
+ clear = false;
(void) setlocale(LC_CTYPE, );
It's a bit weird that you've left the cast here...
@@ -190,12 +196,16 @@ main(int argc, char *argv[])
(void)strvisx(visbp, p, nextp - p, 0);
(void)printf(%s, visbp);
... and here (also: notice inconsistent spacing),
}
+ if (clear)
+ if (sysctlbyname(kern.msgbuf_clear, NULL, NULL, clear,
sizeof(int)))
+ err(1, sysctl kern.msgbuf_clear);
+
exit(0);
}
void
usage(void)
{
- (void)fprintf(stderr, usage: dmesg [-a] [-M core [-N system]]\n);
+ fprintf(stderr, usage: dmesg [-ac] [-M core [-N system]]\n);
but removed it here for no particular reason.
./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
Re: svn commit: r250431 - head/usr.bin/xargs
Eitan,
Are other changes coming to xargs for which these style changes make
sense? If not, I'd say that style changes which only adjust vertical
whitespace, especially those which mostly add vertical whitespace at
the start of functions with no local variables (which is one of the
most archaic and unusual things style(9) requires), are probably the
most gratuitous and silly style changes to make. That doesn't even
rise to being a style change, it's just a whitespace change. And I
really do believe that vertical whitespace changes are much, much
sillier than horizontal whitespace changes.
Curious what the motivation was here; was xargs the only utility in
usr.bin which didn't conform to style(9) in this regard? (No.) Was
this part of a tree-wide sweep to finally bring conformity to these
rules? (I hope not.) What's the point?*
Juli.
*: Not that I've never made changes equally-gratuitous; I certainly
have, and so would more strongly discourage people from making them
given the regret and embarrassment I feel about having done so with
the aid of years of hindsight, and a greater awareness of how easy it
is to make minor functional improvements, or at least do refactoring
with some purpose in mind, if one just wants to leave one's
thumbprint. (Watch for standalone commits from people who used to be
very active developers who have recently hit the threshold for getting
commit bit reaper E-Mails. They're fairly instructive in the art of
making occasional insignificant changes for the sake of making
changes.)
On Thu, May 9, 2013 at 8:49 PM, Eitan Adler ead...@freebsd.org wrote:
Author: eadler
Date: Fri May 10 03:49:05 2013
New Revision: 250431
URL: http://svnweb.freebsd.org/changeset/base/250431
Log:
Style(9) changes fo xargs.c
Modified:
head/usr.bin/xargs/xargs.c
Modified: head/usr.bin/xargs/xargs.c
==
--- head/usr.bin/xargs/xargs.c Fri May 10 03:42:48 2013(r250430)
+++ head/usr.bin/xargs/xargs.c Fri May 10 03:49:05 2013(r250431)
@@ -670,12 +670,14 @@ pids_init(void)
static int
pids_empty(void)
{
+
return (curprocs == 0);
}
static int
pids_full(void)
{
+
return (curprocs = maxprocs);
}
@@ -709,7 +711,6 @@ findfreeslot(void)
if ((slot = findslot(NOPID)) 0)
errx(1, internal error: no free pid slot);
-
return (slot);
}
@@ -721,13 +722,13 @@ findslot(pid_t pid)
for (slot = 0; slot maxprocs; slot++)
if (childpids[slot] == pid)
return (slot);
-
return (-1);
}
static void
clearslot(int slot)
{
+
childpids[slot] = NOPID;
}
@@ -762,6 +763,7 @@ prompt(void)
static void
usage(void)
{
+
fprintf(stderr,
usage: xargs [-0opt] [-E eofstr] [-I replstr [-R replacements] [-S
replsize]]\n
[-J replstr] [-L number] [-n number [-x]] [-P maxprocs]\n
___
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: r250441 - head/sys/dev/netmap
Author: luigi Date: Fri May 10 08:46:10 2013 New Revision: 250441 URL: http://svnweb.freebsd.org/changeset/base/250441 Log: another minor bugfix in the memory allocator, this time in the free routine. Modified: head/sys/dev/netmap/netmap_mem2.c Modified: head/sys/dev/netmap/netmap_mem2.c == --- head/sys/dev/netmap/netmap_mem2.c Fri May 10 06:46:52 2013 (r250440) +++ head/sys/dev/netmap/netmap_mem2.c Fri May 10 08:46:10 2013 (r250441) @@ -381,7 +381,7 @@ netmap_obj_free_va(struct netmap_obj_poo ssize_t relofs = (ssize_t) vaddr - (ssize_t) base; /* Given address, is out of the scope of the current cluster.*/ - if (vaddr base || relofs p-_clustsize) + if (vaddr base || relofs = p-_clustsize) continue; j = j + relofs / p-_objsize; ___ 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: r250442 - head/sys/net80211
Author: adrian
Date: Fri May 10 09:37:58 2013
New Revision: 250442
URL: http://svnweb.freebsd.org/changeset/base/250442
Log:
Fix a VAP BSS node reference in the HT code to actually take a reference
before using said node.
The blessed way here is to take a node reference before referencing
anything inside the node, otherwise the node can be freed between
the time the pointer is copied/dereferenced and the time the node contents
are used.
This mirrors fixes that I've done elsewhere in the net80211/driver
stack.
PR: kern/178470
Modified:
head/sys/net80211/ieee80211_ht.c
Modified: head/sys/net80211/ieee80211_ht.c
==
--- head/sys/net80211/ieee80211_ht.cFri May 10 08:46:10 2013
(r250441)
+++ head/sys/net80211/ieee80211_ht.cFri May 10 09:37:58 2013
(r250442)
@@ -2773,11 +2773,15 @@ ieee80211_ht_update_beacon(struct ieee80
struct ieee80211_beacon_offsets *bo)
{
#definePROTMODE
(IEEE80211_HTINFO_OPMODE|IEEE80211_HTINFO_NONHT_PRESENT)
- const struct ieee80211_channel *bsschan = vap-iv_bss-ni_chan;
+ struct ieee80211_node *ni;
+ const struct ieee80211_channel *bsschan;
struct ieee80211com *ic = vap-iv_ic;
struct ieee80211_ie_htinfo *ht =
(struct ieee80211_ie_htinfo *) bo-bo_htinfo;
+ ni = ieee80211_ref_node(vap-iv_bss);
+ bsschan = ni-ni_chan;
+
/* XXX only update on channel change */
ht-hi_ctrlchannel = ieee80211_chan2ieee(ic, bsschan);
if (vap-iv_flags_ht IEEE80211_FHT_RIFS)
@@ -2796,6 +2800,8 @@ ieee80211_ht_update_beacon(struct ieee80
/* protection mode */
ht-hi_byte2 = (ht-hi_byte2 ~ PROTMODE) | ic-ic_curhtprotmode;
+ ieee80211_free_node(ni);
+
/* XXX propagate to vendor ie's */
#undef PROTMODE
}
___
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: r250443 - head/usr.sbin/ctladm
Author: jh
Date: Fri May 10 09:58:32 2013
New Revision: 250443
URL: http://svnweb.freebsd.org/changeset/base/250443
Log:
Check the return value of sbuf_finish().
MFC after:1 week
Modified:
head/usr.sbin/ctladm/ctladm.c
Modified: head/usr.sbin/ctladm/ctladm.c
==
--- head/usr.sbin/ctladm/ctladm.c Fri May 10 09:37:58 2013
(r250442)
+++ head/usr.sbin/ctladm/ctladm.c Fri May 10 09:58:32 2013
(r250443)
@@ -546,7 +546,8 @@ retry:
}
if (xml != 0) {
sbuf_printf(sb, /ctlfelist\n);
- sbuf_finish(sb);
+ if (sbuf_finish(sb) != 0)
+ err(1, %s: sbuf_finish, __func__);
printf(%s, sbuf_data(sb));
sbuf_delete(sb);
}
@@ -3493,7 +3494,8 @@ cctl_end_element(void *user_data, const
errx(1, %s: no valid sbuf at level %d (name %s), __func__,
devlist-level, name);
- sbuf_finish(devlist-cur_sb[devlist-level]);
+ if (sbuf_finish(devlist-cur_sb[devlist-level]) != 0)
+ err(1, %s: sbuf_finish, __func__);
str = strdup(sbuf_data(devlist-cur_sb[devlist-level]));
if (str == NULL)
err(1, %s can't allocate %zd bytes for string, __func__,
___
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: r250444 - head/sys/dev/ath
Author: adrian
Date: Fri May 10 10:06:45 2013
New Revision: 250444
URL: http://svnweb.freebsd.org/changeset/base/250444
Log:
Make sure the holding descriptor and link pointer are both freed during
a non-loss reset.
When the drain functions are called, the holding descriptor and link pointers
are NULLed out.
But when the processq function is called during a non-loss reset, this
doesn't occur. So the next time a DMA occurs, it's chained to a descriptor
that no longer exists and the hardware gets angry.
Tested:
* AR5416, STA mode; use sysctl dev.ath.X.forcebstuck=1 to force a non-loss
reset.
TODO:
* Further AR9380 testing just to check that the behaviour for the EDMA
chips is sane.
PR: kern/178477
Modified:
head/sys/dev/ath/if_ath.c
head/sys/dev/ath/if_ath_tx_edma.c
Modified: head/sys/dev/ath/if_ath.c
==
--- head/sys/dev/ath/if_ath.c Fri May 10 09:58:32 2013(r250443)
+++ head/sys/dev/ath/if_ath.c Fri May 10 10:06:45 2013(r250444)
@@ -4668,9 +4668,21 @@ ath_legacy_tx_drain(struct ath_softc *sc
if (sc-sc_debug ATH_DEBUG_RESET)
ath_tx_dump(sc, sc-sc_txq[i]);
#endif /* ATH_DEBUG */
- if (reset_type == ATH_RESET_NOLOSS)
+ if (reset_type == ATH_RESET_NOLOSS) {
ath_tx_processq(sc, sc-sc_txq[i], 0);
- else
+ ATH_TXQ_LOCK(sc-sc_txq[i]);
+ /*
+* Free the holding buffer; DMA is now
+* stopped.
+*/
+ ath_txq_freeholdingbuf(sc, sc-sc_txq[i]);
+ /*
+* Reset the link pointer to NULL; there's
+* no frames to chain DMA to.
+*/
+ sc-sc_txq[i].axq_link = NULL;
+ ATH_TXQ_UNLOCK(sc-sc_txq[i]);
+ } else
ath_tx_draintxq(sc, sc-sc_txq[i]);
}
}
Modified: head/sys/dev/ath/if_ath_tx_edma.c
==
--- head/sys/dev/ath/if_ath_tx_edma.c Fri May 10 09:58:32 2013
(r250443)
+++ head/sys/dev/ath/if_ath_tx_edma.c Fri May 10 10:06:45 2013
(r250444)
@@ -551,6 +551,22 @@ ath_edma_tx_drain(struct ath_softc *sc,
*/
if (reset_type == ATH_RESET_NOLOSS) {
ath_edma_tx_processq(sc, 0);
+ for (i = 0; i HAL_NUM_TX_QUEUES; i++) {
+ if (ATH_TXQ_SETUP(sc, i)) {
+ ATH_TXQ_LOCK(sc-sc_txq[i]);
+ /*
+* Free the holding buffer; DMA is now
+* stopped.
+*/
+ ath_txq_freeholdingbuf(sc, sc-sc_txq[i]);
+ /*
+* Reset the link pointer to NULL; there's
+* no frames to chain DMA to.
+*/
+ sc-sc_txq[i].axq_link = NULL;
+ ATH_TXQ_UNLOCK(sc-sc_txq[i]);
+ }
+ }
} else {
for (i = 0; i HAL_NUM_TX_QUEUES; i++) {
if (ATH_TXQ_SETUP(sc, i))
___
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: r250431 - head/usr.bin/xargs
On Fri 10/05/13 17:50 , Juli Mallett jmall...@freebsd.org sent: Eitan, Are other changes coming to xargs for which these style changes make sense? If not, I'd say that style changes which only adjust vertical whitespace, especially those which mostly add vertical whitespace at the start of functions with no local variables (which is one of the most archaic and unusual things style(9) requires), are probably the most gratuitous and silly style changes to make. That doesn't even rise to being a style change, it's just a whitespace change. And I really do believe that vertical whitespace changes are much, much sillier than horizontal whitespace changes. Juli, it seems we're bothered by the same thing here: that at least some of the vertical white space requirements of style(9) are silly and (rightly) widely ignored. So I think we should change the guide to fix this rather than damaging a lot of perfectly readable code. I'd like to emphasise that I'm not even slightly cranky at Eitan for his commit since we committers are presumed to have agreed to follow style(9) and he's just changing code to match the official style. My complaint is that the official style isn't useful in this small regard and should be changed. (Watch for standalone commits from people who used to be very active developers who have recently hit the threshold for getting commit bit reaper E-Mails. They're fairly instructive in the art of making occasional insignificant changes for the sake of making changes.) Well, I used to be a low activity developer and have transitioned to being a very low activity developer, so I know the reaper and the temptation of a quick fix to get it off your back. However it's better to let the reaper pester you than to make a low quality commit. After all, if you haven't anything new and interesting to add, there is always that convenient list of bugs that could be fixed... Cheers, Stephen. ___ 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: r250430 - head/sbin/dmesg
On 10 May 2013 03:42, Alexey Dokuchaev da...@freebsd.org wrote:
On Fri, May 10, 2013 at 03:42:48AM +, Eitan Adler wrote:
New Revision: 250430
URL: http://svnweb.freebsd.org/changeset/base/250430
@@ -79,15 +80,20 @@ main(int argc, char *argv[])
kvm_t *kd;
size_t buflen, bufpos;
long pri;
- int all, ch;
+ int ch, clear;
+ bool all;
- all = 0;
+ all = false;
+ clear = false;
(void) setlocale(LC_CTYPE, );
It's a bit weird that you've left the cast here...
I didn't modify this line
... and here (also: notice inconsistent spacing),
Or this one.
void
usage(void)
{
- (void)fprintf(stderr, usage: dmesg [-a] [-M core [-N system]]\n);
+ fprintf(stderr, usage: dmesg [-ac] [-M core [-N system]]\n);
but removed it here for no particular reason.
Notice the additional 'c' in usage().
--
Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams
___
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: r250451 - in head: sbin/dmesg usr.bin/split
Author: eadler Date: Fri May 10 12:49:16 2013 New Revision: 250451 URL: http://svnweb.freebsd.org/changeset/base/250451 Log: Bump .Dd for recent content change. Reported by: delphij Modified: head/sbin/dmesg/dmesg.8 head/usr.bin/split/split.1 Modified: head/sbin/dmesg/dmesg.8 == --- head/sbin/dmesg/dmesg.8 Fri May 10 11:17:58 2013(r250450) +++ head/sbin/dmesg/dmesg.8 Fri May 10 12:49:16 2013(r250451) @@ -28,7 +28,7 @@ .\ @(#)dmesg.88.1 (Berkeley) 6/5/93 .\ $FreeBSD$ .\ -.Dd June 5, 1993 +.Dd May 9, 2013 .Dt DMESG 8 .Os .Sh NAME Modified: head/usr.bin/split/split.1 == --- head/usr.bin/split/split.1 Fri May 10 11:17:58 2013(r250450) +++ head/usr.bin/split/split.1 Fri May 10 12:49:16 2013(r250451) @@ -28,7 +28,7 @@ .\@(#)split.1 8.3 (Berkeley) 4/16/94 .\ $FreeBSD$ .\ -.Dd September 2, 2010 +.Dd May 9, 2013 .Dt SPLIT 1 .Os .Sh NAME ___ 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: r250430 - head/sbin/dmesg
On Fri, May 10, 2013 at 08:43:37AM -0400, Eitan Adler wrote: On 10 May 2013 03:42, Alexey Dokuchaev da...@freebsd.org wrote: On Fri, May 10, 2013 at 03:42:48AM +, Eitan Adler wrote: New Revision: 250430 URL: http://svnweb.freebsd.org/changeset/base/250430 (void) setlocale(LC_CTYPE, ); It's a bit weird that you've left the cast here... I didn't modify this line OK. - (void)fprintf(stderr, usage: dmesg [-a] [-M core [-N system]]\n); + fprintf(stderr, usage: dmesg [-ac] [-M core [-N system]]\n); but removed it here for no particular reason. Notice the additional 'c' in usage(). Of course. But my question was about dropping the cast, not adding new option. Adding a new option should have resulted in the following diff: - (void)fprintf(stderr, usage: dmesg [-a] [-M core [-N system]]\n); + (void)fprintf(stderr, usage: dmesg [-ac] [-M core [-N system]]\n); ./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: r250453 - head/etc
Author: eadler Date: Fri May 10 13:57:44 2013 New Revision: 250453 URL: http://svnweb.freebsd.org/changeset/base/250453 Log: Bring /etc/protocols up to date. PR: conf/175397 Submitted by: ak Modified: head/etc/protocols Modified: head/etc/protocols == --- head/etc/protocols Fri May 10 13:09:44 2013(r250452) +++ head/etc/protocols Fri May 10 13:57:44 2013(r250453) @@ -92,6 +92,7 @@ vmtp 81 VMTP# Versatile Message Transp secure-vmtp82 SECURE-VMTP # SECURE-VMTP vines 83 VINES # VINES ttp84 TTP # TTP +#iptm 84 IPTM# Protocol Internet Protocol Traffic nsfnet-igp 85 NSFNET-IGP # NSFNET-IGP dgp86 DGP # Dissimilar Gateway Protocol tcf87 TCF # TCF @@ -145,7 +146,13 @@ rsvp-e2e-ignore134 RSVP-E2E-IGNORE # Ag mobility-header135 Mobility-Header # Mobility Support in IPv6 udplite136 UDPLite # The UDP-Lite Protocol mpls-in-ip 137 MPLS-IN-IP # Encapsulating MPLS in IP +manet 138 MANET # MANET Protocols (RFC5498) +hip139 HIP # Host Identity Protocol (RFC5201) +shim6 140 SHIM6 # Shim6 Protocol (RFC5533) +wesp 141 WESP# Wrapped Encapsulating Security Payload (RFC5840) +rohc 142 ROHC# Robust Header Compression (RFC5858) # 138-254 # Unassigned pfsync 240 PFSYNC # PF Synchronization +# 253-254 # Use for experimentation and testing (RFC3692) # 255 # Reserved divert 258 DIVERT # Divert pseudo-protocol [non IANA] ___ 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: r250411 - in head/sys: conf kern sys
On Thursday, May 09, 2013 4:56:33 pm Marcel Moolenaar wrote: On May 9, 2013, at 9:46 AM, Attilio Rao atti...@freebsd.org wrote: On Thu, May 9, 2013 at 6:28 PM, Marcel Moolenaar mar...@freebsd.org wrote: Author: marcel Date: Thu May 9 16:28:18 2013 New Revision: 250411 URL: http://svnweb.freebsd.org/changeset/base/250411 Log: Add option WITNESS_NO_VNODE to suppress printing LORs between VNODE locks. To support this, VNODE locks are created with the LK_IS_VNODE flag. This flag is propagated down using the LO_IS_VNODE flag. Note that WITNESS still records the LOR. Only the printing and the optional entering into the kernel debugger is bypassed with the WITNESS_NO_VNODE option. This is the wrong way to deal with such problem and I avoided to do something like that on purpose. I disagree. We have known LOR messages between VNODE locks that pollute the console and so far we haven't fixed the root cause in some form or shape. Silencing this known case is good to maximize the attention LORs need to be given while still have witness involved to catch locking problems with vnodes that are of a different nature. The way to fix this is to implement LK_NOWITNESS on a per-lock basis into lockmgr, propagate the same concept to the vn_lock() (which should be basically done automatically) and finally identify the false-positive case and commit for them explicitely LK_NOWITNESS on a per-call basis, explaining in detail why the single case reported is a false-positive. This is worse. You want witness involved. Well, I disagree with both of you a bit. I mostly agree with Attilio in that the committed change is a really large sledgehammer. If we want to ignore all LORs for a large number of locks in the system we might as well remove WITNESS altogether. However, I think LK_NOWITNESS is also too large of a sledgehammer for this as well. AFAIK there are two vnode-related LORs that I can think of: 1) between bufwait vs dirhash (so not even vnode locks) which is well documented in ufs_dirhash.c. I would much prefer to add a flag (maybe have somethign set a flag in the thread) to disable witness checking for the few known safe reversals and let WITNESS still check all other operations for the relevant locks. 2) vnode locks from a local filesystem that report a LOR with a devfs vnode. Typical reports are either ufs - devfs or in some cases ufs - devfs - ufs. As with 1), I would much rather tag the offending location than to disable all WITNESS checking on vnode locks. I had originally thought of doing this by passing a flag in the relevant lock call, but that requires having a flags variant of all lock calls and passing the flag down, etc. While writing this I thought of an alternative which would be to have a WITNESS_SUSPEND/WITNESS_RESUME pair of macros that either set a per-thread flag that we can invoke around known cases where a reversal is ok. When witness is suspended it would still remember that the lock was acquired, but it would not report a LOR due to that acquisition (we may have to set a flag in the lock instance so that future LORs related to that acquisition are also ignored) and it would not learn any new orders from that acquisition. So in code it would look like: WITNESS_SUSPEND(); vn_lock(...); WITNESS_RESTORE(); Does this sound agreeable? If so, I definitely think Marcel's change should be reverted in favor of this (more general yet more fine-grained) approach instead. -- 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: r250430 - head/sbin/dmesg
On 10 May 2013 09:36, Alexey Dokuchaev da...@freebsd.org wrote: Of course. But my question was about dropping the cast, not adding new option. Adding a new option should have resulted in the following diff: - (void)fprintf(stderr, usage: dmesg [-a] [-M core [-N system]]\n); + (void)fprintf(stderr, usage: dmesg [-ac] [-M core [-N system]]\n); I thought style(9) disliked the leading (void) but I could be wrong. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ 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: r250430 - head/sbin/dmesg
On 10 May 2013, at 10:01, Eitan Adler ead...@freebsd.org wrote: I thought style(9) disliked the leading (void) but I could be wrong. The cast to (void) tells the compiler that you are ignoring the return result. Without it, you will introduce new warnings and break the build on certain compiler versions with -Werror. 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: r250430 - head/sbin/dmesg
On 10 May 2013 10:08, David Chisnall thera...@freebsd.org wrote: On 10 May 2013, at 10:01, Eitan Adler ead...@freebsd.org wrote: I thought style(9) disliked the leading (void) but I could be wrong. The cast to (void) tells the compiler that you are ignoring the return result. Without it, you will introduce new warnings and break the build on certain compiler versions with -Werror. I know why the (void) is there. lint(1) is the main program which cares about it. I don't remember any recent tool which uses that cast to remove errors. This has nothing to do with my change though. That said I remembered some prior discussion claiming that style(9) does not require them. A quick recheck shows (void)fprintf(stderr, usage: f [-ab]\n); as an example, so clearly I was wrong. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ 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: r250430 - head/sbin/dmesg
On 10 May 2013, at 10:12, Eitan Adler ead...@freebsd.org wrote: I don't remember any recent tool which uses that cast to remove errors. clang -Wunused-result gcc -Wunused-result 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: r250411 - in head/sys: conf kern sys
On May 10, 2013, at 6:52 AM, John Baldwin j...@freebsd.org wrote: The way to fix this is to implement LK_NOWITNESS on a per-lock basis into lockmgr, propagate the same concept to the vn_lock() (which should be basically done automatically) and finally identify the false-positive case and commit for them explicitely LK_NOWITNESS on a per-call basis, explaining in detail why the single case reported is a false-positive. This is worse. You want witness involved. Well, I disagree with both of you a bit. I mostly agree with Attilio in that the committed change is a really large sledgehammer. I do not disagree that it isn't a fix. I wasn't aiming to fix it. However, I think LK_NOWITNESS is also too large of a sledgehammer for this as well. I agree. I think it's worse, by virtue of it being presented as both better as well as a fix. 2) vnode locks from a local filesystem that report a LOR with a devfs vnode. Typical reports are either ufs - devfs or in some cases ufs - devfs - ufs. As with 1), I would much rather tag the offending location than to disable all WITNESS checking on vnode locks. With more file system types in use, this will get mixed up with the other file systems and noise you get is rather severe. It is a big problem for us at Juniper. I had originally thought of doing this by passing a flag in the relevant lock call, but that requires having a flags variant of all lock calls and passing the flag down, etc. While writing this I thought of an alternative which would be to have a WITNESS_SUSPEND/WITNESS_RESUME pair of macros that either set a per-thread flag that we can invoke around known cases where a reversal is ok. When witness is suspended it would still remember that the lock was acquired, but it would not report a LOR due to that acquisition (we may have to set a flag in the lock instance so that future LORs related to that acquisition are also ignored) and it would not learn any new orders from that acquisition. So in code it would look like: WITNESS_SUSPEND(); vn_lock(...); WITNESS_RESTORE(); Does this sound agreeable? If so, I definitely think Marcel's change should be reverted in favor of this (more general yet more fine-grained) approach instead. This is a similar approach to what Attilio suggested (IMO) and I'm very concerned on 2 grounds: 1. Disable/suspending witness and making it easy to do so has known side-effects: people will use it simple to get rid of witness warnings and not even bother to understand the root cause of the witness complaints and thus fix the root cause problem. Fixing the root cause could be improving witness, or fixing the locks. If we add means and ways to have locks not checked by witness then witness stops being the useful tool it mostly is now. 2. This, to me, also doesn't come close to fixing the root cause problem. It's a just a different bandaid. What I would like to see is a statement as to why witness reports LORs (in this case) and why they are not, so that we can improve witness. For example, a statement could go like this: witness operates on lock names. All vnode structures have a lock and they bare the name of the file system. Consequently, we have many instances of a particular lock type that share the same name. This causes, ... (please complete this statement appropriately). If our root cause problem is fundamentally that witness cannot distinguish 1 UFS vnode lock from another UFS vnode lock then we should fix that. Either: 1. Construct unique lock names when witness is enabled, or 2. Create the lock with a flag to tell witness that there are multiple locks of the same name and as such does not have enough the knowledge to report LORs adequately. How we change witness in the face of such a flag is another story and a good subject for ongoing discussion. I'm all for fixing this. My change should be backed out if we have a real fix. But I must say that I'm disappointed by the responses of both you and Attilio. I do not get a sense that either of you knows what the problem is. I definitely do not have had time to understand the problem, let alone work up a real fix, so I claim ignorance without prejudice and I'm the first to admit that this is not a fix. But the best suggestion I get is to exclude the locks from any consideration by witness and that's worse than what I did. I merely added a kernel option to supressing the printing. Not even the checking. And all I did is to allow someone (= Juniper) to not print the LOR for this well-known and mostly ignored case that is impacting our ability to keep witness enabled. And the reason I had to do that is that this is a long-standing LOR that isn't being addressed. The FreeBSD community apparently has settled on just ignoring it. Let's do better. Let's understand the root cause and work up a real fix
Re: svn commit: r250220 - head/sys/kern
On Thursday, May 09, 2013 11:05:46 pm Bruce Evans wrote:
On Mon, 6 May 2013, John Baldwin wrote:
On Saturday, May 04, 2013 4:47:43 am Bruce Evans wrote:
Log:
Fix FIONREAD on regular files. The computed result was being ignored and
it was being passed down to VOP_IOCTL() where it promptly resulted in
ENOTTY due to a missing else for the past 8 years. While here, use a
shared vnode lock while fetching the current file's size.
In another thread I complained to kib about using the bad style of not
returning as soon as possible, but instead sometimes returning and
sometimes
falling through a complicated if-else ladder to get to the return at the
end.
What about this:
My mail is barely working while I'm away. This is the only reply that
I received recently.
static int
vn_ioctl(fp, com, data, active_cred, td)
struct file *fp;
u_long com;
void *data;
struct ucred *active_cred;
struct thread *td;
{
struct vnode *vp = fp-f_vnode;
struct vattr vattr;
switch (vp-v_type) {
case VREG:
case VDIR:
switch (com) {
case FIONREAD:
vn_lock(vp, LK_SHARED | LK_RETRY);
error = VOP_GETATTR(vp, vattr, active_cred);
VOP_UNLOCK(vp, 0);
if (!error)
*(int *)data = vattr.va_size - fp-f_offset;
return (error);
case FIONBIO:
case FIOASYNC:
return (0); /* XXX */
default:
return (VOP_IOCTL(vp, com, data, fp-f_flag,
active_cred, td));
}
default:
return (ENOTTY);
}
}
Yes, that is the simplification for the logic that I want.
This function has many other style bugs, starting witht the unsorting of
vp relative to vattr and the initialization of vp in its declaration.
I don't count the old-style function definition as a style bug :).
Also, the case statment is unsorted (which used to be needed for the
logic of falling through), and !error is used for the non-boolean
'error'. !error is near the overflow bug in *(int *) for large files.
INT_MAX should probably be returned when the correct value is
unrepresentable. This can't be worse than overflowing to a garbage
(possibly small or negative value). Testing 'error' is not even needed,
since *(int *)data is indeterminate after an error.
I'll do only style fixes first and then the overflow check.
(The 'XXX' comment could perhaps be expanded to something along the lines of
'Allow fcntl() to toggle FNONBLOCK and FASYNC.')
Is that what it is about? IIRC, upper layers do some partial handling
and then call lower layers to possibly do some more handling. But here
and in some other places there is nothing more to be done. No comment
is needed, but maybe the XXX's were reminders to clean up the layering.
FreeBSD has cleaned up the layering a bit, by using differnt fops for
different file types.
The problem is this code in fcntl() which I ran into when working on a
tutorial for writing character devices:
case F_SETFL:
error = fget_unlocked(fdp, fd, CAP_FCNTL, F_SETFL, fp, NULL);
if (error != 0)
break;
do {
tmp = flg = fp-f_flag;
tmp = ~FCNTLFLAGS;
tmp |= FFLAGS(arg ~O_ACCMODE) FCNTLFLAGS;
} while(atomic_cmpset_int(fp-f_flag, flg, tmp) == 0);
tmp = fp-f_flag FNONBLOCK;
error = fo_ioctl(fp, FIONBIO, tmp, td-td_ucred, td);
if (error != 0) {
fdrop(fp, td);
break;
}
tmp = fp-f_flag FASYNC;
error = fo_ioctl(fp, FIOASYNC, tmp, td-td_ucred, td);
if (error == 0) {
fdrop(fp, td);
break;
}
atomic_clear_int(fp-f_flag, FNONBLOCK);
tmp = 0;
(void)fo_ioctl(fp, FIONBIO, tmp, td-td_ucred, td);
fdrop(fp, td);
break;
Hmm, this seems to have the bug that if you had FNONBLOCK set and
tried to set FASYNC via fcntl() but FIOASYNC isn't supported,
FNONBLOCK is cleared. It seems we should only clear FNONBLOCK
if it wasn't set in 'flg'. I think this would fix that:
Index: kern_descrip.c
===
--- kern_descrip.c (revision 250451)
+++ kern_descrip.c (working copy)
@@ -539,7 +539,7 @@ kern_fcntl(struct thread *td, int fd, int cmd, int
}
tmp = fp-f_flag FASYNC;
error = fo_ioctl(fp, FIOASYNC, tmp, td-td_ucred, td);
- if (error == 0) {
+ if (error == 0
Re: svn commit: r250411 - in head/sys: conf kern sys
On Friday, May 10, 2013 11:46:54 am Marcel Moolenaar wrote: 2) vnode locks from a local filesystem that report a LOR with a devfs vnode. Typical reports are either ufs - devfs or in some cases ufs - devfs - ufs. As with 1), I would much rather tag the offending location than to disable all WITNESS checking on vnode locks. With more file system types in use, this will get mixed up with the other file systems and noise you get is rather severe. It is a big problem for us at Juniper. Note, it is very specific that the second lock is always devfs. I think that points to this being isolated to a few specific places, not a generic ordering problem. This is a similar approach to what Attilio suggested (IMO) and I'm very concerned on 2 grounds: 1. Disable/suspending witness and making it easy to do so has known side-effects: people will use it simple to get rid of witness warnings and not even bother to understand the root cause of the witness complaints and thus fix the root cause problem. Fixing the root cause could be improving witness, or fixing the locks. If we add means and ways to have locks not checked by witness then witness stops being the useful tool it mostly is now. The goal is to make the disabling as fine-grained as possible because... 2. This, to me, also doesn't come close to fixing the root cause problem. It's a just a different bandaid. What I would like to see is a statement as to why witness reports LORs (in this case) and why they are not, so that we can improve witness. For example, a statement could go like this: witness operates on lock names. All vnode structures have a lock and they bare the name of the file system. Consequently, we have many instances of a particular lock type that share the same name. This causes, ... (please complete this statement appropriately). If our root cause problem is fundamentally that witness cannot distinguish 1 UFS vnode lock from another UFS vnode lock then we should fix that. Either: 1. Construct unique lock names when witness is enabled, or 2. Create the lock with a flag to tell witness that there are multiple locks of the same name and as such does not have enough the knowledge to report LORs adequately. How we change witness in the face of such a flag is another story and a good subject for ongoing discussion. Some things witness can't really grok (at least not well). It's really that simple. Take the dirhash case. Here is the comment in the code: /* * Locking: * * The relationship between inode and dirhash is protected either by an * exclusive vnode lock or the vnode interlock where a shared vnode lock * may be used. The dirhash_mtx is acquired after the dirhash lock. To * handle teardown races, code wishing to lock the dirhash for an inode * when using a shared vnode lock must obtain a private reference on the * dirhash while holding the vnode interlock. They can drop it once they * have obtained the dirhash lock and verified that the dirhash wasn't * recycled while they waited for the dirhash lock. * * ufsdirhash_build() acquires a shared lock on the dirhash when it is * successful. This lock is released after a call to ufsdirhash_lookup(). * * Functions requiring exclusive access use ufsdirhash_acquire() which may * free a dirhash structure that was recycled by ufsdirhash_recycle(). * * The dirhash lock may be held across io operations. * * WITNESS reports a lock order reversal between the bufwait lock * and the dirhash lock. However, this specific reversal will not * cause a deadlock. To get a deadlock, one would have to lock a * buffer followed by the dirhash while a second thread locked a * buffer while holding the dirhash lock. The second order can happen * under a shared or exclusive vnode lock for the associated directory * in lookup(). The first order, however, can only happen under an * exclusive vnode lock (e.g. unlink(), rename(), etc.). Thus, for * a thread to be doing a bufwait - dirhash order, it has to hold * an exclusive vnode lock. That exclusive vnode lock will prevent * any other threads from doing a dirhash - bufwait order. */ So the issue here is that shared locks and exclusive locks are not quite the same. Perhaps this is something that WITNESS could know generically, and one solution might be to use separate witness objects for shared acquires on a lock vs exclusive acquires on a lock, but I'm not sure that wouldn't result in false negatives (i.e. WITNESS not reporting a LOR that can deadlock). My intuition is that the general rule would not be safe, so I would rather annotate the specific false positive in this case to remove the noise of a known-false-positive. Note that there are other instances where we make WITNESS less specific because it doesn't know about details. For example, almost all uses of the DUPOK
svn commit: r250459 - head/share/syscons/fonts
Author: eadler Date: Fri May 10 16:30:39 2013 New Revision: 250459 URL: http://svnweb.freebsd.org/changeset/base/250459 Log: Add the letter 'q' to the font iso05-8x16.fnt PR: 72585 PR: 169797 Submitted by: Takefu tak...@airport.fm Submitted by: Satoshi KImura satosi.kim...@nifty.ne.jp Modified: head/share/syscons/fonts/iso05-8x16.fnt Modified: head/share/syscons/fonts/iso05-8x16.fnt == --- head/share/syscons/fonts/iso05-8x16.fnt Fri May 10 16:16:33 2013 (r250458) +++ head/share/syscons/fonts/iso05-8x16.fnt Fri May 10 16:30:39 2013 (r250459) @@ -40,7 +40,7 @@ M`'S_L#`QGPX;1@\!@8#P``` M`.!@8QV9F9F9N88``X!@8!@\!@8`#@8!@8!F9F M/.!@89L'AL9N8X!@8!@8!@\[/[6UM;6 MQ@```-QF9F9F9F8```!\QL;QL9\W9F -M9F9F?!@\`#=F9@8#P +M9F9F?!@\';,S,S,S'P,#!X```#=F9@8#P M?,9@.`S?!`P,/PP,#`P-AP```#,S,S,S,QV M9F9F9F8\,;UM;6_FP```#;#@X.S MQL;QL;?@8,^/[,#!@QOX.!@8!@8!@. ___ 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: r250460 - in head: share/examples/ppi share/misc sys/cam/ctl sys/cam/scsi sys/dev/aic7xxx sys/dev/cp sys/dev/ctau sys/dev/cx sys/dev/hptmv sys/dev/isci/scil sys/dev/nsp sys/dev/sfxge/co...
Author: eadler Date: Fri May 10 16:41:26 2013 New Revision: 250460 URL: http://svnweb.freebsd.org/changeset/base/250460 Log: Fxi a bunch of typos. PR: misc/174625 Submitted by: Jeremy Chadwick j...@koitsu.org Modified: head/share/examples/ppi/ppilcd.c head/share/misc/pci_vendors head/sys/cam/ctl/scsi_ctl.c head/sys/cam/scsi/scsi_da.c head/sys/cam/scsi/scsi_pt.c head/sys/dev/aic7xxx/aic7xxx.h head/sys/dev/cp/if_cp.c head/sys/dev/ctau/if_ct.c head/sys/dev/cx/csigma.c head/sys/dev/cx/if_cx.c head/sys/dev/hptmv/entry.c head/sys/dev/isci/scil/scif_sas_domain.c head/sys/dev/nsp/nsp.c head/sys/dev/sfxge/common/efx_mcdi.c head/sys/dev/sn/if_sn.c head/sys/dev/stg/tmc18c30.c head/sys/kern/uipc_usrreq.c head/sys/netgraph/bluetooth/l2cap/ng_l2cap_cmds.c head/sys/ofed/drivers/net/mlx4/eq.c head/usr.sbin/bluetooth/hccontrol/link_control.c head/usr.sbin/dumpcis/printcis.c Modified: head/share/examples/ppi/ppilcd.c == --- head/share/examples/ppi/ppilcd.cFri May 10 16:30:39 2013 (r250459) +++ head/share/examples/ppi/ppilcd.cFri May 10 16:41:26 2013 (r250460) @@ -269,7 +269,7 @@ do_char(struct lcd_driver *driver, char * one of the ground pins (eg. pin 25). * * Note that the pinning on some LCD modules has the odd and even pins - * arranged as though reversed; check carefully before conecting a module + * arranged as though reversed; check carefully before connecting a module * as it is possible to toast the HD44780 if the power is reversed. */ Modified: head/share/misc/pci_vendors == --- head/share/misc/pci_vendors Fri May 10 16:30:39 2013(r250459) +++ head/share/misc/pci_vendors Fri May 10 16:41:26 2013(r250460) @@ -11402,7 +11402,7 @@ 0040 QSC-200/300 0050 ESC-100D 0060 ESC-100M - 00f0 MPAC-100 Syncronous Serial Card (Zilog 85230) + 00f0 MPAC-100 Synchronous Serial Card (Zilog 85230) 0170 QSCLP-100 0180 DSCLP-100 0190 SSCLP-100 Modified: head/sys/cam/ctl/scsi_ctl.c == --- head/sys/cam/ctl/scsi_ctl.c Fri May 10 16:30:39 2013(r250459) +++ head/sys/cam/ctl/scsi_ctl.c Fri May 10 16:41:26 2013(r250460) @@ -2137,7 +2137,7 @@ ctlfe_dump_queue(struct ctlfe_lun_softc xpt_print(periph-path, %d requests total waiting for CCBs\n, num_items); - xpt_print(periph-path, %ju CCBs oustanding (%ju allocated, %ju + xpt_print(periph-path, %ju CCBs outstanding (%ju allocated, %ju freed)\n, (uintmax_t)(softc-ccbs_alloced - softc-ccbs_freed), (uintmax_t)softc-ccbs_alloced, (uintmax_t)softc-ccbs_freed); Modified: head/sys/cam/scsi/scsi_da.c == --- head/sys/cam/scsi/scsi_da.c Fri May 10 16:30:39 2013(r250459) +++ head/sys/cam/scsi/scsi_da.c Fri May 10 16:41:26 2013(r250460) @@ -2328,7 +2328,7 @@ skipstate: out: /* -* Block out any asyncronous callbacks +* Block out any asynchronous callbacks * while we touch the pending ccb list. */ LIST_INSERT_HEAD(softc-pending_ccbs, @@ -2729,7 +2729,7 @@ dadone(struct cam_periph *periph, union } /* -* Block out any asyncronous callbacks +* Block out any asynchronous callbacks * while we touch the pending ccb list. */ LIST_REMOVE(done_ccb-ccb_h, periph_links.le); Modified: head/sys/cam/scsi/scsi_pt.c == --- head/sys/cam/scsi/scsi_pt.c Fri May 10 16:30:39 2013(r250459) +++ head/sys/cam/scsi/scsi_pt.c Fri May 10 16:41:26 2013(r250460) @@ -455,7 +455,7 @@ ptstart(struct cam_periph *periph, union start_ccb-ccb_h.ccb_state = PT_CCB_BUFFER_IO_UA; /* -* Block out any asyncronous callbacks +* Block out any asynchronous callbacks * while we touch the pending ccb list. */ LIST_INSERT_HEAD(softc-pending_ccbs, start_ccb-ccb_h, @@ -549,7 +549,7 @@ ptdone(struct cam_periph *periph, union } /* -* Block out any asyncronous callbacks +* Block out any asynchronous callbacks * while we touch the pending ccb list. */ LIST_REMOVE(done_ccb-ccb_h, periph_links.le); Modified: head/sys/dev/aic7xxx/aic7xxx.h == ---
Re: svn commit: r250411 - in head/sys: conf kern sys
On 5/10/13 8:46 AM, Marcel Moolenaar wrote: And all I did is to allow someone (= Juniper) to not print the LOR for this well-known and mostly ignored case that is impacting our ability to keep witness enabled. And the reason I had to do that is that this is a long-standing LOR that isn't being addressed. The FreeBSD community apparently has settled on just ignoring it. This whole issue about not allowing developers to mute warnings stems from some FreeBSD developers inability to imagine that they are not locus of architecture at an organization. We really need to gain the ability to put ourselves in the shoes of someone that is just one of MANY people working on a product, a product that can choose its platform, FreeBSD, or if FreeBSD fails, then Linux or whatever works. Allowing people to customize and/or mute these error messages, when they are often superfluous is good. It allows the team to work on the parts that they need to work on and ignore the noise from other broken parts of FreeBSD that will eventually be fixed by the community. If FreeBSD is supposed to be for the community, then why does it have portions (WITNESS/INVARIANTS/etc?) that are not for the community? -Alfred ___ 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: r250432 - head/usr.bin/split
On Fri, May 10, 2013 at 12:23 AM, Eitan Adler ead...@freebsd.org wrote:
Modified: head/usr.bin/split/split.c
==
--- head/usr.bin/split/split.c Fri May 10 03:49:05 2013(r250431)
+++ head/usr.bin/split/split.c Fri May 10 04:23:03 2013(r250432)
@@ -359,9 +367,19 @@ newfile(void)
ofd = fileno(stdout);
}
- /* maxfiles = 26^sufflen, but don't use libm. */
+ if (dflag) {
+ beg = '0';
+ end = '9';
+ }
+ else {
+ beg = 'a';
+ end = 'z';
+ }
+ pattlen = end - beg + 1;
+
+ /* maxfiles = pattlen^sufflen, but don't use libm. */
for (maxfiles = 1, i = 0; i sufflen; i++)
- if ((maxfiles *= 26) = 0)
+ if ((maxfiles *= pattlen) = 0)
This check relies on signed integer overflow, which is undefined behavior.
Furthermore, even if one assumes a non-evil compiler and two's complement
representation, this check fails for pattlen == 10.
10**9 is representable as both a signed and unsigned 32-bit integer, but
10**10 overflows both variants and ends up in the positive side of the
signed space.
With a fixed number of bases to be exponentiated here (10 or 26), it would
seem much simpler to do the logarithm manually out-of-band and just
hardcode a check on sufflen (noting that maxfiles is of type long which can
be either 32 or 64 bits).
-Ben
errx(EX_USAGE, suffix is too long (max %ld), i);
if (fnum == maxfiles)
___
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: r250462 - head/usr.bin/lockf
Author: eadler
Date: Fri May 10 17:30:29 2013
New Revision: 250462
URL: http://svnweb.freebsd.org/changeset/base/250462
Log:
Add option to lockf to avoid creating a file if it does not exist.
PR: bin/170775
Submitted by: Matthew Story matthewst...@gmail.com
Reviewed by: scottl
MFC after:1 week
Modified:
head/usr.bin/lockf/lockf.1
head/usr.bin/lockf/lockf.c
Modified: head/usr.bin/lockf/lockf.1
==
--- head/usr.bin/lockf/lockf.1 Fri May 10 16:48:21 2013(r250461)
+++ head/usr.bin/lockf/lockf.1 Fri May 10 17:30:29 2013(r250462)
@@ -32,7 +32,7 @@
.Nd execute a command while holding a file lock
.Sh SYNOPSIS
.Nm
-.Op Fl ks
+.Op Fl kns
.Op Fl t Ar seconds
.Ar file
.Ar command
@@ -90,6 +90,18 @@ Causes
.Nm
to operate silently.
Failure to acquire the lock is indicated only in the exit status.
+.It Fl n
+Causes
+.Nm
+to fail if the specified lock
+.Ar file
+does not exist. If
+.Fl n
+is not specified,
+.Nm
+will create
+.Ar file
+if necessary.
.It Fl t Ar seconds
Specifies a timeout for waiting for the lock.
By default,
@@ -130,6 +142,10 @@ The
utility
was unable to create the lock file, e.g., because of insufficient access
privileges.
+.It Dv EX_UNAVAILABLE
+The
+.Fl n
+option is specified and the specified lock file does not exist.
.It Dv EX_USAGE
There was an error on the
.Nm
Modified: head/usr.bin/lockf/lockf.c
==
--- head/usr.bin/lockf/lockf.c Fri May 10 16:48:21 2013(r250461)
+++ head/usr.bin/lockf/lockf.c Fri May 10 17:30:29 2013(r250462)
@@ -56,16 +56,20 @@ static volatile sig_atomic_t timed_out;
int
main(int argc, char **argv)
{
- int ch, silent, status, waitsec;
+ int ch, flags, silent, status, waitsec;
pid_t child;
silent = keep = 0;
+ flags = O_CREAT;
waitsec = -1; /* Infinite. */
- while ((ch = getopt(argc, argv, skt:)) != -1) {
+ while ((ch = getopt(argc, argv, sknt:)) != -1) {
switch (ch) {
case 'k':
keep = 1;
break;
+ case 'n':
+ flags = ~O_CREAT;
+ break;
case 's':
silent = 1;
break;
@@ -118,13 +122,13 @@ main(int argc, char **argv)
* avoiding the separate step of waiting for the lock. This
* yields fairness and improved performance.
*/
- lockfd = acquire_lock(lockname, O_NONBLOCK);
+ lockfd = acquire_lock(lockname, flags | O_NONBLOCK);
while (lockfd == -1 !timed_out waitsec != 0) {
if (keep)
- lockfd = acquire_lock(lockname, 0);
+ lockfd = acquire_lock(lockname, flags);
else {
wait_for_lock(lockname);
- lockfd = acquire_lock(lockname, O_NONBLOCK);
+ lockfd = acquire_lock(lockname, flags | O_NONBLOCK);
}
}
if (waitsec 0)
@@ -165,7 +169,7 @@ acquire_lock(const char *name, int flags
{
int fd;
- if ((fd = open(name, O_RDONLY|O_CREAT|O_EXLOCK|flags, 0666)) == -1) {
+ if ((fd = open(name, flags|O_RDONLY|O_EXLOCK|flags, 0666)) == -1) {
if (errno == EAGAIN || errno == EINTR)
return (-1);
err(EX_CANTCREAT, cannot open %s, name);
@@ -215,7 +219,7 @@ usage(void)
{
fprintf(stderr,
- usage: lockf [-ks] [-t seconds] file command [arguments]\n);
+ usage: lockf [-kns] [-t seconds] file command [arguments]\n);
exit(EX_USAGE);
}
___
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: r250463 - head/usr.sbin/mergemaster
Author: eadler
Date: Fri May 10 17:42:13 2013
New Revision: 250463
URL: http://svnweb.freebsd.org/changeset/base/250463
Log:
Permit relative paths with mergemaster -m
Reviewed by: dim, brooks
MFC after:3 days
Modified:
head/usr.sbin/mergemaster/mergemaster.sh
Modified: head/usr.sbin/mergemaster/mergemaster.sh
==
--- head/usr.sbin/mergemaster/mergemaster.shFri May 10 17:30:29 2013
(r250462)
+++ head/usr.sbin/mergemaster/mergemaster.shFri May 10 17:42:13 2013
(r250463)
@@ -483,6 +483,7 @@ if [ ! -f ${SOURCEDIR}/Makefile.inc1 -a
sleep 3
SOURCEDIR=${SOURCEDIR}/..
fi
+SOURCEDIR=$(realpath $SOURCEDIR)
# Setup make to use system files from SOURCEDIR
MM_MAKE=make ${ARCHSTRING} -m ${SOURCEDIR}/share/mk
___
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: r250462 - head/usr.bin/lockf
On Fri, May 10, 2013 at 05:30:30PM +, Eitan Adler wrote:
Author: eadler
Date: Fri May 10 17:30:29 2013
New Revision: 250462
URL: http://svnweb.freebsd.org/changeset/base/250462
Log:
Add option to lockf to avoid creating a file if it does not exist.
Patch seems to be incomplete.
+.It Dv EX_UNAVAILABLE
+The
+.Fl n
+option is specified and the specified lock file does not exist.
.It Dv EX_USAGE
There was an error on the
.Nm
- if ((fd = open(name, O_RDONLY|O_CREAT|O_EXLOCK|flags, 0666)) == -1) {
+ if ((fd = open(name, flags|O_RDONLY|O_EXLOCK|flags, 0666)) == -1) {
if (errno == EAGAIN || errno == EINTR)
return (-1);
err(EX_CANTCREAT, cannot open %s, name);
EX_UNAVAILABLE is never returned.
--
Mateusz Guzik mjguzik gmail.com
___
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: r250466 - in head/sys: netinet netinet6
Author: tuexen
Date: Fri May 10 18:09:38 2013
New Revision: 250466
URL: http://svnweb.freebsd.org/changeset/base/250466
Log:
Honor the net.inet6.ip6.v6only sysctl variable and the IPV6_V6ONLY
socket option for SCTP sockets in the same way as for UDP or TCP
sockets.
MFC after: 2 weeks
Modified:
head/sys/netinet/sctp_pcb.c
head/sys/netinet6/sctp6_usrreq.c
Modified: head/sys/netinet/sctp_pcb.c
==
--- head/sys/netinet/sctp_pcb.c Fri May 10 18:05:45 2013(r250465)
+++ head/sys/netinet/sctp_pcb.c Fri May 10 18:09:38 2013(r250466)
@@ -2376,8 +2376,13 @@ sctp_inpcb_alloc(struct socket *so, uint
inp-sctp_socket = so;
inp-ip_inp.inp.inp_socket = so;
#ifdef INET6
- if (MODULE_GLOBAL(ip6_auto_flowlabel)) {
- inp-ip_inp.inp.inp_flags |= IN6P_AUTOFLOWLABEL;
+ if (INP_SOCKAF(so) == AF_INET6) {
+ if (MODULE_GLOBAL(ip6_auto_flowlabel)) {
+ inp-ip_inp.inp.inp_flags |= IN6P_AUTOFLOWLABEL;
+ }
+ if (MODULE_GLOBAL(ip6_v6only)) {
+ inp-ip_inp.inp.inp_flags |= IN6P_IPV6_V6ONLY;
+ }
}
#endif
inp-sctp_associd_counter = 1;
Modified: head/sys/netinet6/sctp6_usrreq.c
==
--- head/sys/netinet6/sctp6_usrreq.cFri May 10 18:05:45 2013
(r250465)
+++ head/sys/netinet6/sctp6_usrreq.cFri May 10 18:09:38 2013
(r250466)
@@ -787,18 +787,11 @@ sctp6_send(struct socket *so, int flags,
}
}
if (IN6_IS_ADDR_V4MAPPED(sin6-sin6_addr)) {
- if (!MODULE_GLOBAL(ip6_v6only)) {
- struct sockaddr_in sin;
+ struct sockaddr_in sin;
- /* convert v4-mapped into v4 addr and send */
- in6_sin6_2_sin(sin, sin6);
- return (sctp_sendm(so, flags, m, (struct sockaddr
*)sin,
- control, p));
- } else {
- /* mapped addresses aren't enabled */
- SCTP_LTRACE_ERR_RET(inp, NULL, NULL,
SCTP_FROM_SCTP6_USRREQ, EINVAL);
- return (EINVAL);
- }
+ /* convert v4-mapped into v4 addr and send */
+ in6_sin6_2_sin(sin, sin6);
+ return (sctp_sendm(so, flags, m, (struct sockaddr *)sin,
control, p));
}
#endif /* INET */
connected_type:
@@ -932,17 +925,9 @@ sctp6_connect(struct socket *so, struct
}
}
if (IN6_IS_ADDR_V4MAPPED(sin6-sin6_addr)) {
- if (!MODULE_GLOBAL(ip6_v6only)) {
- /* convert v4-mapped into v4 addr */
- in6_sin6_2_sin((struct sockaddr_in *)ss, sin6);
- addr = (struct sockaddr *)ss;
- } else {
- /* mapped addresses aren't enabled */
- SCTP_INP_RUNLOCK(inp);
- SCTP_ASOC_CREATE_UNLOCK(inp);
- SCTP_LTRACE_ERR_RET(inp, NULL, NULL,
SCTP_FROM_SCTP6_USRREQ, EINVAL);
- return (EINVAL);
- }
+ /* convert v4-mapped into v4 addr */
+ in6_sin6_2_sin((struct sockaddr_in *)ss, sin6);
+ addr = (struct sockaddr *)ss;
}
#endif /* INET */
/* Now do we connect? */
___
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: r250469 - head/bin/dd
Author: eadler
Date: Fri May 10 18:43:36 2013
New Revision: 250469
URL: http://svnweb.freebsd.org/changeset/base/250469
Log:
Make dd's signal handler async safe.
PR: bin/75258
Submitted by: Oleg V. Nauman o...@reis.zp.ua
Arrival Date: Sun Dec 19 14:50:21 GMT 2004
Reviewed by: mjg, jhb
Reviewed by: jilles (earlier version)
MFC after:1 week
Modified:
head/bin/dd/args.c
head/bin/dd/conv_tab.c
head/bin/dd/dd.c
head/bin/dd/extern.h
head/bin/dd/misc.c
head/bin/dd/position.c
Modified: head/bin/dd/args.c
==
--- head/bin/dd/args.c Fri May 10 18:41:14 2013(r250468)
+++ head/bin/dd/args.c Fri May 10 18:43:36 2013(r250469)
@@ -45,6 +45,7 @@ __FBSDID($FreeBSD$);
#include errno.h
#include inttypes.h
#include limits.h
+#include signal.h
#include stdlib.h
#include string.h
Modified: head/bin/dd/conv_tab.c
==
--- head/bin/dd/conv_tab.c Fri May 10 18:41:14 2013(r250468)
+++ head/bin/dd/conv_tab.c Fri May 10 18:43:36 2013(r250469)
@@ -41,6 +41,7 @@ __FBSDID($FreeBSD$);
#include sys/types.h
+#include signal.h
#include stdint.h
#include dd.h
Modified: head/bin/dd/dd.c
==
--- head/bin/dd/dd.cFri May 10 18:41:14 2013(r250468)
+++ head/bin/dd/dd.cFri May 10 18:43:36 2013(r250469)
@@ -81,6 +81,7 @@ size_tcbsz; /* conversion block
size
uintmax_t files_cnt = 1; /* # of files to copy */
const u_char *ctab; /* conversion table */
char fill_char; /* Character to fill with if defined */
+volatile sig_atomic_t need_summary;
int
main(int argc __unused, char *argv[])
@@ -89,7 +90,7 @@ main(int argc __unused, char *argv[])
jcl(argv);
setup();
- (void)signal(SIGINFO, summaryx);
+ (void)signal(SIGINFO, siginfo_handler);
(void)signal(SIGINT, terminate);
atexit(summary);
@@ -375,6 +376,9 @@ dd_in(void)
in.dbp += in.dbrcnt;
(*cfunc)();
+ if (need_summary) {
+ summary();
+ }
}
}
Modified: head/bin/dd/extern.h
==
--- head/bin/dd/extern.hFri May 10 18:41:14 2013(r250468)
+++ head/bin/dd/extern.hFri May 10 18:43:36 2013(r250469)
@@ -43,7 +43,7 @@ void jcl(char **);
void pos_in(void);
void pos_out(void);
void summary(void);
-void summaryx(int);
+void siginfo_handler(int);
void terminate(int);
void unblock(void);
void unblock_close(void);
@@ -61,3 +61,4 @@ extern const u_char e2a_32V[], e2a_POSIX
extern const u_char a2ibm_32V[], a2ibm_POSIX[];
extern u_char casetab[];
extern char fill_char;
+extern volatile sig_atomic_t need_summary;
Modified: head/bin/dd/misc.c
==
--- head/bin/dd/misc.c Fri May 10 18:41:14 2013(r250468)
+++ head/bin/dd/misc.c Fri May 10 18:43:36 2013(r250469)
@@ -44,6 +44,7 @@ __FBSDID($FreeBSD$);
#include errno.h
#include inttypes.h
+#include signal.h
#include stdio.h
#include stdlib.h
#include string.h
@@ -57,41 +58,32 @@ summary(void)
{
struct timeval tv;
double secs;
- char buf[100];
(void)gettimeofday(tv, NULL);
secs = tv.tv_sec + tv.tv_usec * 1e-6 - st.start;
if (secs 1e-6)
secs = 1e-6;
- /* Use snprintf(3) so that we don't reenter stdio(3). */
- (void)snprintf(buf, sizeof(buf),
+ (void)fprintf(stderr,
%ju+%ju records in\n%ju+%ju records out\n,
st.in_full, st.in_part, st.out_full, st.out_part);
- (void)write(STDERR_FILENO, buf, strlen(buf));
- if (st.swab) {
- (void)snprintf(buf, sizeof(buf), %ju odd length swab %s\n,
+ if (st.swab)
+ (void)fprintf(stderr, %ju odd length swab %s\n,
st.swab, (st.swab == 1) ? block : blocks);
- (void)write(STDERR_FILENO, buf, strlen(buf));
- }
- if (st.trunc) {
- (void)snprintf(buf, sizeof(buf), %ju truncated %s\n,
+ if (st.trunc)
+ (void)fprintf(stderr, %ju truncated %s\n,
st.trunc, (st.trunc == 1) ? block : blocks);
- (void)write(STDERR_FILENO, buf, strlen(buf));
- }
- (void)snprintf(buf, sizeof(buf),
+ (void)fprintf(stderr,
%ju bytes transferred in %.6f secs (%.0f bytes/sec)\n,
st.bytes, secs, st.bytes / secs);
- (void)write(STDERR_FILENO, buf, strlen(buf));
+ need_summary = 0;
}
/* ARGSUSED */
void
-summaryx(int notused __unused)
+siginfo_handler(int signo __unused)
{
- int save_errno
Re: svn commit: r250411 - in head/sys: conf kern sys
On May 10, 2013, at 9:11 AM, John Baldwin j...@freebsd.org wrote: On Friday, May 10, 2013 11:46:54 am Marcel Moolenaar wrote: 2) vnode locks from a local filesystem that report a LOR with a devfs vnode. Typical reports are either ufs - devfs or in some cases ufs - devfs - ufs. As with 1), I would much rather tag the offending location than to disable all WITNESS checking on vnode locks. With more file system types in use, this will get mixed up with the other file systems and noise you get is rather severe. It is a big problem for us at Juniper. Note, it is very specific that the second lock is always devfs. I think that points to this being isolated to a few specific places, not a generic ordering problem. Alas, that's not the case. These LORs are reported between ufs and unionfs, or ufs and isofs, etc. It's not just between something and devfs. /* * Locking: * * The relationship between inode and dirhash is protected either by an * exclusive vnode lock or the vnode interlock where a shared vnode lock * may be used. The dirhash_mtx is acquired after the dirhash lock. To * handle teardown races, code wishing to lock the dirhash for an inode * when using a shared vnode lock must obtain a private reference on the * dirhash while holding the vnode interlock. They can drop it once they * have obtained the dirhash lock and verified that the dirhash wasn't * recycled while they waited for the dirhash lock. * * ufsdirhash_build() acquires a shared lock on the dirhash when it is * successful. This lock is released after a call to ufsdirhash_lookup(). * * Functions requiring exclusive access use ufsdirhash_acquire() which may * free a dirhash structure that was recycled by ufsdirhash_recycle(). * * The dirhash lock may be held across io operations. * * WITNESS reports a lock order reversal between the bufwait lock * and the dirhash lock. However, this specific reversal will not * cause a deadlock. To get a deadlock, one would have to lock a * buffer followed by the dirhash while a second thread locked a * buffer while holding the dirhash lock. The second order can happen * under a shared or exclusive vnode lock for the associated directory * in lookup(). The first order, however, can only happen under an * exclusive vnode lock (e.g. unlink(), rename(), etc.). Thus, for * a thread to be doing a bufwait - dirhash order, it has to hold * an exclusive vnode lock. That exclusive vnode lock will prevent * any other threads from doing a dirhash - bufwait order. */ So the issue here is that shared locks and exclusive locks are not quite the same. Perhaps this is something that WITNESS could know generically, and one solution might be to use separate witness objects for shared acquires on a lock vs exclusive acquires on a lock, but I'm not sure that wouldn't result in false negatives (i.e. WITNESS not reporting a LOR that can deadlock). My intuition is that the general rule would not be safe, so I would rather annotate the specific false positive in this case to remove the noise of a known-false-positive. I'm not sure the only options we have are to ignore the problem or implement a general fix. If we set out to silence witness for the known false positives then it's ok to handle them on a case by case basis. We'll see patterns soon enough and then re-code the solutions in terms of those patterns. If we're lucky we see a single general solution, but if not, then it's fine to have a handful of special case. The worse we can do is not address it at all. My commit was met with a statement that comes really close to you made witness useless, after which the argument changed to we can't make witness better. At this time my change seems like the best of all possible suggestions. rules to the duplicate check currently). Vnode locks are another example of this actually. You can lock a child of a directory while holding the vnode lock of the parent directory but not vice versa. That particular rule would be very hard to verify in WITNESS directly (given two vnode lock pointers, could you prove that one is a parent directory of the other non-trivially in witness_checkorder()? I seriously doubt it), so we accept some false-negatives to avoid false-positive LORs on every path lookup. Thus, in practice I think your goal of having WITNESS understand every possible nuance is a bit unrealistic and not consistent with our use of it historically. I'm not sure where you get the notion that my goal is to have witness understand every possible nuance. My commit certainly is not achieving such a goal. In fact, it's accepting the imperfections we have by not have those imperfections render to tool unusable. All I want is for witness to be silent about false positives or known uncertainties so that we can establish clear processes in case witness does warn. The extend to which we can be successful is not known to me, but I do know that keeping
Re: svn commit: r250379 - in head/usr.sbin/bsnmpd/modules: . snmp_hast
On Thu, May 09, 2013 at 01:05:35PM +0300, Mikolaj Golub wrote: On Thu, May 09, 2013 at 11:22:43AM +0300, Konstantin Belousov wrote: Why do you need libl.a ? If only for yywrap(), then re-implementing it for the module seems to be trivial. Yes, it is like so. Thanks! I am now considering two possible solutions: 1) As it is suggested above, add trivial yywrap() and link without -ll. 2) Add '%option noyywrap' to hastd/token.l, and link hastd, hastctl and snmp_hast without -ll (it looks like yywrap is needed only when parsing more than one file). See the patches below. It looks both solutions work for me and I personally prefer the second one. Me too. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com pgpibIQ2kP5s3.pgp Description: PGP signature
Re: svn commit: r250463 - head/usr.sbin/mergemaster
On Fri, May 10, 2013 at 10:42 AM, Eitan Adler ead...@freebsd.org wrote: Author: eadler Date: Fri May 10 17:42:13 2013 New Revision: 250463 URL: http://svnweb.freebsd.org/changeset/base/250463 Log: Permit relative paths with mergemaster -m Reviewed by: dim, brooks MFC after:3 days Modified: head/usr.sbin/mergemaster/mergemaster.sh Modified: head/usr.sbin/mergemaster/mergemaster.sh bin/173929 ? ___ 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: r250463 - head/usr.sbin/mergemaster
On 10 May 2013 15:09, Garrett Cooper yaneurab...@gmail.com wrote: On Fri, May 10, 2013 at 10:42 AM, Eitan Adler ead...@freebsd.org wrote: Author: eadler Date: Fri May 10 17:42:13 2013 New Revision: 250463 URL: http://svnweb.freebsd.org/changeset/base/250463 Log: Permit relative paths with mergemaster -m Reviewed by: dim, brooks MFC after:3 days Modified: head/usr.sbin/mergemaster/mergemaster.sh Modified: head/usr.sbin/mergemaster/mergemaster.sh bin/173929 ? Yes, sorry for not including the PR number. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ 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: r250463 - head/usr.sbin/mergemaster
On Fri, May 10, 2013 at 12:32 PM, Eitan Adler ead...@freebsd.org wrote: ... Yes, sorry for not including the PR number. No worries :). Thanks for the fix! -Garrett ___ 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: r250477 - head/usr.bin/calendar/calendars
Author: delphij Date: Fri May 10 20:02:15 2013 New Revision: 250477 URL: http://svnweb.freebsd.org/changeset/base/250477 Log: REST IN PEACE Alexander Botero-Lowry Born June 2, 1986 in Austin, Texas Died August 24, 2012 in San Francisco, California Thank you for your contributions, you will be greatly missed. Modified: head/usr.bin/calendar/calendars/calendar.freebsd Modified: head/usr.bin/calendar/calendars/calendar.freebsd == --- head/usr.bin/calendar/calendars/calendar.freebsdFri May 10 19:44:02 2013(r250476) +++ head/usr.bin/calendar/calendars/calendar.freebsdFri May 10 20:02:15 2013(r250477) @@ -258,6 +258,7 @@ 08/19 Pav Lucistnik p...@freebsd.org born in Kutna Hora, Czech Republic, 1980 08/20 Michael Heffner mi...@freebsd.org born in Cleona, Pennsylvania, United States, 1981 08/24 Mark Linimon lini...@freebsd.org born in Houston, Texas, United States, 1955 +08/24 Alexander Botero-Lowry ale...@freebsd.org died in San Francisco, California, United States, 2012 08/25 Beech Rintoul be...@freebsd.org born in Oakland, California, United States, 1952 08/25 Jean Milanez Melo jm...@freebsd.org born in Divinopolis, Minas Gerais, Brazil, 1982 08/26 Dima Ruban d...@freebsd.org born in Nalchik, USSR, 1970 ___ 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: r250411 - in head/sys: conf kern sys
On Friday, May 10, 2013 2:51:20 pm Marcel Moolenaar wrote: On May 10, 2013, at 9:11 AM, John Baldwin j...@freebsd.org wrote: On Friday, May 10, 2013 11:46:54 am Marcel Moolenaar wrote: 2) vnode locks from a local filesystem that report a LOR with a devfs vnode. Typical reports are either ufs - devfs or in some cases ufs - devfs - ufs. As with 1), I would much rather tag the offending location than to disable all WITNESS checking on vnode locks. With more file system types in use, this will get mixed up with the other file systems and noise you get is rather severe. It is a big problem for us at Juniper. Note, it is very specific that the second lock is always devfs. I think that points to this being isolated to a few specific places, not a generic ordering problem. Alas, that's not the case. These LORs are reported between ufs and unionfs, or ufs and isofs, etc. It's not just between something and devfs. Ugh, I have only seen them with devfs so had presumed them to be more localized (and thus more easily targeted). In that case your change may be as fine-grained as we can get. I would also like to still keep WITNESS checking between vnode locks and other lock types, and LK_NOWITNESS would remove that, so between your change and Attilio's approach I do prefer yours. I'm not sure the only options we have are to ignore the problem or implement a general fix. If we set out to silence witness for the known false positives then it's ok to handle them on a case by case basis. We'll see patterns soon enough and then re-code the solutions in terms of those patterns. If we're lucky we see a single general solution, but if not, then it's fine to have a handful of special case. The worse we can do is not address it at all. I was assuming that the reversals were far more specific, and knowing about other false positives like the dirhash one, I want a generic way to do more fine-grained marking of false positives. If there were only a few places we would need to mark to fix the reversals you see, then I would prefer the suspend/resume approach for your case. However, the reversals you are masking sound too widespread to support that. -- 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: r250487 - head/sys/x86/cpufreq
Author: hiren
Date: Fri May 10 22:43:27 2013
New Revision: 250487
URL: http://svnweb.freebsd.org/changeset/base/250487
Log:
Adding a detach method to p4tcc driver.
PR: 118739
Submitted by: Dan Lukes d...@obluda.cz (earlier version)
Reviewed by: jhb
Approved by: sbruno (mentor)
MFC after:1 week
Modified:
head/sys/x86/cpufreq/p4tcc.c
Modified: head/sys/x86/cpufreq/p4tcc.c
==
--- head/sys/x86/cpufreq/p4tcc.cFri May 10 21:39:41 2013
(r250486)
+++ head/sys/x86/cpufreq/p4tcc.cFri May 10 22:43:27 2013
(r250487)
@@ -73,6 +73,7 @@ static intp4tcc_features(driver_t *driv
static voidp4tcc_identify(driver_t *driver, device_t parent);
static int p4tcc_probe(device_t dev);
static int p4tcc_attach(device_t dev);
+static int p4tcc_detach(device_t dev);
static int p4tcc_settings(device_t dev, struct cf_setting *sets,
int *count);
static int p4tcc_set(device_t dev, const struct cf_setting *set);
@@ -84,6 +85,7 @@ static device_method_t p4tcc_methods[] =
DEVMETHOD(device_identify, p4tcc_identify),
DEVMETHOD(device_probe, p4tcc_probe),
DEVMETHOD(device_attach,p4tcc_attach),
+ DEVMETHOD(device_detach,p4tcc_detach),
/* cpufreq interface */
DEVMETHOD(cpufreq_drv_set, p4tcc_set),
@@ -213,6 +215,24 @@ p4tcc_attach(device_t dev)
}
static int
+p4tcc_detach(device_t dev)
+{
+ struct cf_setting set;
+ int error;
+
+ error = cpufreq_unregister(dev);
+ if (error)
+ return (error);
+
+ /*
+* Before we finish detach, switch to Automatic mode.
+*/
+ set.freq = 1;
+ p4tcc_set(dev, set);
+ return(0);
+}
+
+static int
p4tcc_settings(device_t dev, struct cf_setting *sets, int *count)
{
struct p4tcc_softc *sc;
___
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: r250495 - head/sys/amd64/amd64
Author: rpaulo Date: Sat May 11 01:31:51 2013 New Revision: 250495 URL: http://svnweb.freebsd.org/changeset/base/250495 Log: Fix several standard extended feature bits. Submitted by: Oliver Pinter oliver.pntr at gmail.com Modified: head/sys/amd64/amd64/identcpu.c Modified: head/sys/amd64/amd64/identcpu.c == --- head/sys/amd64/amd64/identcpu.c Sat May 11 01:03:29 2013 (r250494) +++ head/sys/amd64/amd64/identcpu.c Sat May 11 01:31:51 2013 (r250495) @@ -407,11 +407,11 @@ printcpuinfo(void) /* Restricted Transactional Memory */ \014RTM /* Enhanced NRBG */ - \022RDSEED + \023RDSEED /* ADCX + ADOX */ - \023ADX + \024ADX /* Supervisor Mode Access Prevention */ - \024SMAP + \025SMAP ); } ___ 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: r250432 - head/usr.bin/split
On 10 May 2013 13:05, Benjamin Kaduk bjkf...@gmail.com wrote: This check relies on signed integer overflow, which is undefined behavior. Furthermore, even if one assumes a non-evil compiler and two's complement representation, this check fails for pattlen == 10. 10**9 is representable as both a signed and unsigned 32-bit integer, but 10**10 overflows both variants and ends up in the positive side of the signed space. With a fixed number of bases to be exponentiated here (10 or 26), it would seem much simpler to do the logarithm manually out-of-band and just hardcode a check on sufflen (noting that maxfiles is of type long which can be either 32 or 64 bits). ... Good point. I did not look closely at this code and assumed it was correct. I shall fix it. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ 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
