Re: Possible bug in timecounter code
On Monday 03 September 2012, Stefan Fritsch wrote: On Sunday 02 September 2012, s...@sfritsch.de wrote: But it may still be a problem the other way round. If adjtimedelta would go to zero during the lost ticks, there will be some over-compensation that is not detected. After some more hints from Mark (thanks), I think this is very unlikely to cause a problem in practice, possibly except if running on a virtualization host that is overloaded/swapping. There is another issue: If the previous call to tc_windup was more than 1s ago, there is an integer overflow, all complete seconds are lost and only the fractional part is added to th_offset. FreeBSD has a fix for this one: http://svnweb.freebsd.org/base?view=revisionrevision=215665
sendbug.1 (diff), query-pr.html (diff), query-pr-wrapper (404)
When reading sendbug(1) because you -uhm- want to report a bug you should search for older similiar bug reports. This way you end up using query-pr.html [1] and after you've dutifully filled out and hit ``send'' you just get a HTTP 404 for query-pr-wrapper [2]. IIRC there's no intention to revive the bugs database, therefore the sendbug(1) diff removes the reference to [1] and links to marc.info instead. Additionally the query-pr.html diff offers the same link and removes the misleading form. [1] http://www.openbsd.org/query-pr.html [2] http://cvs.openbsd.org/cgi-bin/query-pr-wrapper Bye, Marcus Index: sendbug.1 === RCS file: /cvs/src/usr.bin/sendbug/sendbug.1,v retrieving revision 1.21 diff -u -r1.21 sendbug.1 --- sendbug.1 12 Aug 2012 17:01:36 - 1.21 +++ sendbug.1 4 Sep 2012 07:15:21 - @@ -53,11 +53,9 @@ Any follow up mail to the PR should keep the same mail subject. .Pp -The bugs database can be queried using the online bug tracking system -available at -.Lk http://www.openbsd.org/query-pr.html . -This allows users to search for PRs based on either PR number -or content. +The bug reports can be searched using the various mailing list archives, +like the one at +.Lk http://marc.info/?l=openbsd-bugs . .Pp The options are as follows: .Bl -tag -width Ds Index: query-pr.html === RCS file: /cvs/www/query-pr.html,v retrieving revision 1.4 diff -u -r1.4 query-pr.html --- query-pr.html 28 Nov 2011 03:14:47 - 1.4 +++ query-pr.html 4 Sep 2012 07:36:54 - @@ -16,139 +16,7 @@ h2font color=#e0Bug Tracking system/font/h2 hr -h2a name=specificQuery a specific PR/a/h2 -form method=POST action=http://cvs.openbsd.org/cgi-bin/query-pr-wrapper; -input type=hidden name=full value=yes - -p -If you know the number of the Problem Report (PR) you are looking for, enter -it below and click the strongQuery/strong button. - -br -strongPR number:/strong -input name=numbers type=text size=10 - -input value=Query type=submit -input value=Reset type=reset -/form - -hr - -h2a name=searchSearch for PRs based on their contents/a/h2 -form method=POST action=http://cvs.openbsd.org/cgi-bin/query-pr-wrapper; - -p -To search for PRs based on their contents, fill out the form below. -Multiple selections are ttAND/tted together. -You may use regular expressions for all text boxes other than the -emPR number(s)/em field. -You do not have to fill in everything; fields that are not filled -in will simply be ignored. - -p -This form matches all emopen/em PRs by default; please make your search -as specific as possible. -Note that this form will only display a summary of the matched PRs. - -p -tabletr - -tdstrongCategory/strong:/td -tdselect name=category -option selected value=Any/option -option value=pendingpending/option -option value=systemsystem/option -option value=useruser/option -option value=librarylibrary/option -option value=documentationdocumentation/option -option value=portsports/option -option value=kernelkernel/option -option value=sparcsparc/option -option value=sparc64sparc64/option -option value=i386i386/option -option value=m68km68k/option -option value=mipsmips/option -option value=ppcppc/option -option value=armarm/option -option value=alphaalpha/option -option value=ns32kns32k/option -option value=vaxvax/option -/select/td - -tdstrongSeverity:/strong/td -tdselect name=severity -option selected value=Any/option -option value=non-criticalNon-critical/option -option value=seriousSerious/option -option value=criticalCritical/option -/select/td - -tdstrongPriority:/strong/td -tdselect name=priority -option selected value=Any/option -option value=lowLow/option -option value=mediumMedium/option -option value=highHigh/option -/select/td - -/trtr - -tdstrongClass:/strong/td -tdselect name=class -option selected value=Any/option -option value=sw-bugsw-bug/option -option value=doc-bugdoc-bug/option -option value=change-requestchange-request/option -option value=supportsupport/option -/select/td - -tdstrongState:/strong/td -tdselect name=state -option selected value=Any/option -option value=openOpen/option -option value=analyzedAnalyzed/option -option value=feedbackFeedback/option -option value=suspendedSuspended/option -option value=closedClosed/option -/select/td - -tdstrongSkip closed PRs:/strong/td -tdinput name=skipclosed type=checkbox checked/td - -/tr/table - -p - -tabletr - -tdstrongOriginator (who sent it):/strong/td -tdinput name=originator type=text size=50/td - -/trtr - -tdstrongResponsible Party (who should fix it):/strong/td -tdinput name=responsible type=text size=50/td - -/trtr - -tdstrongSearch text in single-line fields:/strong/td -tdinput name=text type=text size=50/td - -/trtr - -tdstrongSearch text in multi-line fields:/strong/td -tdinput name=multitext type=text size=50/td - -/trtr - -tdstrongPR number(s) (separated by
mg: wrong line number after isearch-backward
On Tue, Sep 04, 2012 at 09:32:21AM +, Mark Lumsden wrote:
If you don't mind, could you send the diff to tech@?
If there are no objections, I'll commit the diff at the weekend.
mark
The while loop in backsrch in search.c decrements nline even if the
pattern ends up not matching.
1) jot -w '%03d' 100 1 100 foo.txt
2) mg foo.txt
3) C-x g 23
4) C-r 010 ( or C-r 0^J01 )
After a tweak by lum@ of my original patch and a small tweak by me:
Index: search.c
===
RCS file: /opt/OpenBSD-CVS/src/usr.bin/mg/search.c,v
retrieving revision 1.40
diff -u -p -r1.40 search.c
--- search.c25 May 2012 05:16:59 - 1.40
+++ search.c4 Sep 2012 08:36:15 -
@@ -737,7 +737,7 @@ backsrch(void)
struct line *clp, *tlp;
int cbo, tbo, c, i, xcase = 0;
char*epp, *pp;
- int nline;
+ int nline, tline;
for (epp = pat[0]; epp[1] != 0; ++epp);
clp = curwp-w_dotp;
@@ -762,6 +762,7 @@ backsrch(void)
tlp = clp;
tbo = cbo;
pp = epp;
+ tline = nline;
while (pp != pat[0]) {
if (tbo == 0) {
tlp = lback(tlp);
@@ -774,8 +775,10 @@ backsrch(void)
c = CCHR('J');
else
c = lgetc(tlp, tbo);
- if (eq(c, *--pp, xcase) == FALSE)
+ if (eq(c, *--pp, xcase) == FALSE) {
+ nline = tline;
goto fail;
+ }
}
curwp-w_dotp = tlp;
curwp-w_doto = tbo;
--
I'm not entirely sure you are real.
msdosfs_vnops.c u_char toname diff [Was: Re: panic: smashed stack in msdosfs_rename]
with the diff below my ``panic: smashed stack in msdosfs_rename'' problem does not appear any more. Index: msdosfs_vnops.c === RCS file: /cvs/src/sys/msdosfs/msdosfs_vnops.c,v retrieving revision 1.82 diff -u -r1.82 msdosfs_vnops.c --- msdosfs_vnops.c 11 Jul 2012 12:39:20 - 1.82 +++ msdosfs_vnops.c 4 Sep 2012 09:28:32 - @@ -860,7 +860,7 @@ struct componentname *fcnp = ap-a_fcnp; struct proc *p = curproc; /* XXX */ struct denode *ip, *xp, *dp, *zp; - u_char toname[11], oldname[11]; + u_char toname[12], oldname[11]; uint32_t from_diroffset, to_diroffset; u_char to_count; int doingdirectory = 0, newparent = 0; below is my lengthy report to bugs@ with some explanation. Bye, Marcus mcmer-open...@tor.at (MERIGHI Marcus), 2012.09.04 (Tue) 11:52 (CEST): context and history: alix machine, connecting external usb hd. hotplugd(8) scripts to rsync larger files (100MB - 1000MB) to external hd. The hd quite often gives: umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR after some unplugging/plugging it works (ms win and a sony tv seem to have no problem with the hd). no suspicious sounds from hd. ms win chkdsk thinks the disk/slice is fine. when mounted the hd looks like this: /dev/sd0i on /mnt/media type msdos (local, uid=1002, gid=10, long) /dev/sd0i 104832 922767424 12555257688%/mnt/media The plug in, rsync, plug out cycle has been running for weeks now, without problems apart from the ``BBB'' thing. The hd is filling up constantly. Yesterday I installed yesterdays snapshot. Saw the panic for the first time later that day. http://readlist.com/lists/freebsd.org/freebsd-current/10/53762.html and http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/fs/msdosfs/msdosfs_vnops.c?only_with_tag=MAIN (rev 1.72) suggest: Index: msdosfs_vnops.c === RCS file: /cvs/src/sys/msdosfs/msdosfs_vnops.c,v retrieving revision 1.82 diff -u -r1.82 msdosfs_vnops.c --- msdosfs_vnops.c 11 Jul 2012 12:39:20 - 1.82 +++ msdosfs_vnops.c 4 Sep 2012 09:28:32 - @@ -860,7 +860,7 @@ struct componentname *fcnp = ap-a_fcnp; struct proc *p = curproc; /* XXX */ struct denode *ip, *xp, *dp, *zp; - u_char toname[11], oldname[11]; + u_char toname[12], oldname[11]; uint32_t from_diroffset, to_diroffset; u_char to_count; int doingdirectory = 0, newparent = 0; I haven't tried with the above patch yet, going to compile a kernel for the first time in ages. Bye, Marcus +++ Disk: sd0 geometry: 91201/255/63 [1465149168 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- *0: 0C 0 32 33 - 65270 245 63 [2048: 1048576000 ] Win95 FAT32L 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused +++ # /dev/rsd0c: type: SCSI disk: SCSI disk label: holmer-medien-01 duid: 94f3e0ef639263f9 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 91201 total sectors: 1465149168 boundstart: 0 boundend: 1465149168 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c: 14651491680 unused i: 1048576000 2048 MSDOS# /mnt/media +++ with ddb.panic=0 and watchdogd_flags=: panic: smashed stack in msdosfs_rename Starting stack trace... panic(d08eecfc,f3886d48,d08cbc44,f3886d48,50) at panic+0x6a panic(d08cbc44,d08d0bb5,f3886dfc,d04305b1,d08d0bb5) at panic+0x6a __stack_smash_handler(d08d0bb5,0,d52dc5d0,d124e820,0) at __stack_smash_handler+0x19 msdosfs_rename(f3886e14,0,0,d5314f0c,d54b7cdc) at msdosfs_rename+0x451 VOP_RENAME(d54b7cdc,d531d1e8,f3886ed0,d54b7cdc,0) at VOP_RENAME+0x41 dorenameat(d52dc5d0,ff9c,cfbe8c68,ff9c,cfbe9468) at dorenameat+0x220 sys_rename(d52dc5d0,f3886f64,f3886f84,106,d52de904) at sys_rename+0x38 syscall() at syscall+0x227 --- syscall (number -809595800) --- 0x2: End of stack trace. syncing disks... 4 3 done dumping to dev 1, offset 503871 dump 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237
Re: allow v6 privacy and static addresses to co-exist again
Le 2012-09-02 08:05, Stefan Sperling a écrit :
Simon's recent commit to prevent SLAAC address formation when
a static address is already configured has a side-effect for
autoconfprivacy users.
With the following in /etc/hostname.if:
dhcp
rtsol
inet6 some-address 64
the netstart script will run rtsol after assigning the static address,
hence preventing privacy addresses from being formed. The only effect
of 'rtsol' in this case is an auto-configured default route.
If a privacy address is manually configured first and a static address
second, the interface initially has both. But the static address prevents
creation of new addresses during RA reception. When the privacy address
becomes deprecated a fresh address is not added, breaking autoconfprivacy.
So using privacy addresses for outgoing connections and static addresses
for incoming connections is no longer possible. Do we want to support
this use case? It used to work ever since privacy addresses were introduced.
The diff below makes static addresses prevent SLAAC addresses in the
no-privacy case but allows static and privacy addresses to co-exist.
Because we create SLAAC addresses alongside privacy addresses, this
effectively reverts the default behaviour to what it was before
Simon's change. With the hostname.if snippet above we get:
- auto-configured default route
- SLAAC address
- privacy addresses (rotating over time)
- a static address
Those who prefer traditional inet6 behaviour can use:
dhcp
-autoconfprivacy
rtsol
This results in:
- auto-configured default route
- SLAAC address
Or:
dhcp
-autoconfprivacy
rtsol
inet6 some-address 64
This results in:
- auto-configured default route
- a static address
ok?
This makes sense, ok.
Please note the last comment in the comment at the top that says:
/*
* 5.5.3 (d). If the prefix advertised does not match the prefix of an
* address already in the list, and the Valid Lifetime is not 0,
* form an address. Note that even a manually configured address
* should reject autoconfiguration of a new address.
*/
This is no longer true. This comment is an excerpt from RFC 2462 which
was obsoleted by RFC 4862. The text was modified to say:
d) If the prefix advertised is not equal to the prefix of an
address configured by stateless autoconfiguration already in the
list of addresses [...]
So this change is not only good, it fits with the intent of the new RFC.
You might want to tweak the comments to reflect that.
Simon
Index: nd6_rtr.c
===
RCS file: /cvs/src/sys/netinet6/nd6_rtr.c,v
retrieving revision 1.62
diff -u -p -r1.62 nd6_rtr.c
--- nd6_rtr.c 28 Aug 2012 20:32:02 - 1.62
+++ nd6_rtr.c 2 Sep 2012 11:33:44 -
@@ -1275,7 +1275,8 @@ prelist_update(struct nd_prefix *new, st
}
if ((!autoconf || ((ifp-if_xflags IFXF_INET6_NOPRIVACY) == 0
- !tempaddr_preferred)) new-ndpr_vltime != 0 !statique) {
+ !tempaddr_preferred)) new-ndpr_vltime != 0
+ !((ifp-if_xflags IFXF_INET6_NOPRIVACY) statique)) {
/*
* There is no SLAAC address and/or there is no preferred RFC
* 4941 temporary address. And the valid prefix lifetime is
fix log_err() messages in sasyncd(8)
I think those were log_msg()s before, as log_msg() has to be called with a
debug level
as first argument. As log_err() doesn't take a debug level, just call it with
the string.
Index: monitor.c
===
RCS file: /cvs/src/usr.sbin/sasyncd/monitor.c,v
retrieving revision 1.15
diff -u -r1.15 monitor.c
--- monitor.c 2 Apr 2012 18:56:15 - 1.15
+++ monitor.c 4 Sep 2012 13:06:37 -
@@ -180,7 +180,7 @@
if (select(m_state.s + 1, rfds, NULL, NULL, tvp) == -1) {
if (errno == EINTR || errno == EAGAIN)
continue;
- log_err(0, monitor_loop: select() );
+ log_err(monitor_loop: select() );
break;
}
@@ -188,7 +188,7 @@
if (FD_ISSET(m_state.s, rfds)) {
if ((r = m_read(m_state.s, v, sizeof v)) 1) {
if (r == -1)
- log_err(0, monitor_loop: read() );
+ log_err(monitor_loop: read() );
break;
}
}
[demime 1.01d removed an attachment of type application/pkcs7-signature which
had a name of smime.p7s]
Re: msdosfs_vnops.c u_char toname diff [Was: Re: panic: smashed stack in msdosfs_rename]
On Tue, Sep 04, 2012 at 02:56:40PM +0200, MERIGHI Marcus wrote:
with the diff below my ``panic: smashed stack in msdosfs_rename''
problem does not appear any more.
Index: msdosfs_vnops.c
===
RCS file: /cvs/src/sys/msdosfs/msdosfs_vnops.c,v
retrieving revision 1.82
diff -u -r1.82 msdosfs_vnops.c
--- msdosfs_vnops.c 11 Jul 2012 12:39:20 - 1.82
+++ msdosfs_vnops.c 4 Sep 2012 09:28:32 -
@@ -860,7 +860,7 @@
struct componentname *fcnp = ap-a_fcnp;
struct proc *p = curproc; /* XXX */
struct denode *ip, *xp, *dp, *zp;
- u_char toname[11], oldname[11];
+ u_char toname[12], oldname[11];
uint32_t from_diroffset, to_diroffset;
u_char to_count;
int doingdirectory = 0, newparent = 0;
below is my lengthy report to bugs@ with some explanation.
Bye, Marcus
The problem seems to be rooted in a desire to printf() the dosname
in a debug statement. Otherwise the dos file names are not treated
as strings anywhere.
An alternate solution, that restores the symmetry between unix2dosfn()
and dos2unixfn(), is to use %.11s to print the dos file name in that
debug chunk, and otherwise consistantly treat the various dos file
names as 11-byte arrays.
Eliminiating one magic number (12) would seem a good thing. :-)
Comments about the non-stringiness of these vars might be good too.
Ken
Index: msdosfs_conv.c
===
RCS file: /cvs/src/sys/msdosfs/msdosfs_conv.c,v
retrieving revision 1.14
diff -u -p -r1.14 msdosfs_conv.c
--- msdosfs_conv.c 13 Aug 2009 22:34:29 - 1.14
+++ msdosfs_conv.c 4 Sep 2012 13:45:37 -
@@ -403,7 +403,7 @@ dos2unixfn(u_char dn[11], u_char *un, in
* 3 if conversion was successful and generation number was inserted
*/
int
-unix2dosfn(u_char *un, u_char dn[12], int unlen, u_int gen)
+unix2dosfn(u_char *un, u_char dn[11], int unlen, u_int gen)
{
int i, j, l;
int conv = 1;
@@ -416,7 +416,6 @@ unix2dosfn(u_char *un, u_char dn[12], in
*/
for (i = 0; i 11; i++)
dn[i] = ' ';
- dn[11] = 0;
/*
* The filenames . and .. are handled specially, since they
Index: msdosfs_lookup.c
===
RCS file: /cvs/src/sys/msdosfs/msdosfs_lookup.c,v
retrieving revision 1.24
diff -u -p -r1.24 msdosfs_lookup.c
--- msdosfs_lookup.c4 Jul 2011 04:30:41 - 1.24
+++ msdosfs_lookup.c4 Sep 2012 13:38:29 -
@@ -104,7 +104,7 @@ msdosfs_lookup(void *v)
struct msdosfsmount *pmp;
struct buf *bp = 0;
struct direntry *dep;
- u_char dosfilename[12];
+ u_char dosfilename[11];
u_char *adjp;
int adjlen;
int flags;
@@ -193,7 +193,7 @@ msdosfs_lookup(void *v)
slotcount = 0;
#ifdef MSDOSFS_DEBUG
- printf(msdosfs_lookup(): dos version of filename %s, length %d\n,
+ printf(msdosfs_lookup(): dos version of filename '%.11s', length %d\n,
dosfilename, cnp-cn_namelen);
#endif
/*
Re: fix log_err() messages in sasyncd(8)
On Tue 2012.09.04 at 15:36 +0200, Patrick Wildt wrote: I think those were log_msg()s before, as log_msg() has to be called with a debug level as first argument. As log_err() doesn't take a debug level, just call it with the string. fixed; thank you
Re: fix sasyncd(8) race condition causing a segfault when getting data from the kernel
I've reviewed this diff with Patrick and I believe it is correct, can
someone else have a look ?
On Tue, Sep 04, 2012 at 04:46:08PM +0200, Patrick Wildt wrote:
When sasyncd(8) dumps data from the kernel, it does a sysctl() for the size to
alloc,
and a second for the actual data. In between, new data can be added/deleted.
Therefore
the kernel might return less data, than actually told. The case that you get
less/more data
isn't handled properly.
In case of less data, it might happen that the child is working on
uninitialized data.
This might lead to a segmentation fault.
In case of more data, the sasyncd(8) parent process handles it as he didn't
get any data.
This diff rewrites that part, so that we try thrice to get the SAs and SPDs.
If getting the SAs
breaks thrice, we tell the child process, that there's no data. Same for the
SPDs.
The case of less data is now handled properly. The case of more data is either
caught
by the for loop, or allocing twice the size of the data we should originally
get.
That might be helpful on bigger vpn setups, when the loop still doesn't catch
the race.
Tested with 7080 SAs. (For real.)
Index: monitor.c
===
RCS file: /cvs/src/usr.sbin/sasyncd/monitor.c,v
retrieving revision 1.15
diff -u -r1.15 monitor.c
--- monitor.c 2 Apr 2012 18:56:15 - 1.15
+++ monitor.c 4 Sep 2012 13:06:37 -
@@ -342,7 +342,7 @@
{
u_int8_t*sadb_buf = 0, *spd_buf = 0;
size_t sadb_buflen = 0, spd_buflen = 0, sz;
- int mib[5];
+ int i, mib[5];
u_int32_tv;
mib[0] = CTL_NET;
@@ -352,59 +352,81 @@
mib[4] = 0; /* Unspec SA type */
/* First, fetch SADB data */
- if (sysctl(mib, sizeof mib / sizeof mib[0], NULL, sz, NULL, 0) == -1
- || sz == 0) {
- sadb_buflen = 0;
- goto try_spd;
- }
-
- sadb_buflen = sz;
- if ((sadb_buf = malloc(sadb_buflen)) == NULL) {
- log_err(m_priv_pfkey_snap: malloc);
- sadb_buflen = 0;
- goto out;
- }
-
- if (sysctl(mib, sizeof mib / sizeof mib[0], sadb_buf, sz, NULL, 0)
- == -1) {
- log_err(m_priv_pfkey_snap: sysctl);
- sadb_buflen = 0;
- goto out;
+ for (i = 0; i 3; i++) {
+ if (sysctl(mib, sizeof mib / sizeof mib[0], NULL, sz, NULL, 0)
+ == -1)
+ break;
+
+ if (!sz)
+ break;
+
+ /* Try to catch newly added data */
+ sz *= 2;
+
+ if ((sadb_buf = malloc(sz)) == NULL)
+ break;
+
+ if (sysctl(mib, sizeof mib / sizeof mib[0], sadb_buf, sz,
NULL, 0)
+ == -1) {
+ free(sadb_buf);
+ sadb_buf = 0;
+ /*
+ * If new SAs were added meanwhile and the given buffer
is
+ * too small, retry.
+ */
+ if (errno == ENOMEM)
+ continue;
+ break;
+ }
+
+ sadb_buflen = sz;
+ break;
}
/* Next, fetch SPD data */
- try_spd:
mib[3] = NET_KEY_SPD_DUMP;
- if (sysctl(mib, sizeof mib / sizeof mib[0], NULL, sz, NULL, 0) == -1
- || sz == 0) {
- spd_buflen = 0;
- goto out;
- }
+ for (i = 0; i 3; i++) {
+ if (sysctl(mib, sizeof mib / sizeof mib[0], NULL, sz, NULL, 0)
+ == -1)
+ break;
- spd_buflen = sz;
- if ((spd_buf = malloc(spd_buflen)) == NULL) {
- log_err(m_priv_pfkey_snap: malloc);
- spd_buflen = 0;
- goto out;
- }
+ if (!sz)
+ break;
+
+ /* Try to catch newly added data */
+ sz *= 2;
+
+ if ((spd_buf = malloc(sz)) == NULL)
+ break;
+
+ if (sysctl(mib, sizeof mib / sizeof mib[0], spd_buf, sz, NULL,
0)
+ == -1) {
+ free(spd_buf);
+ spd_buf = 0;
+ /*
+ * If new SPDs were added meanwhile and the given
buffer is
+ * too small, retry.
+ */
+ if (errno == ENOMEM)
+ continue;
+ break;
+ }
- if (sysctl(mib, sizeof mib / sizeof mib[0], spd_buf, sz, NULL, 0)
- == -1) {
- log_err(m_priv_pfkey_snap: sysctl);
- spd_buflen = 0;
- goto out;
+ spd_buflen = sz;
+ break;
}
- out:
/* Return SADB data */
v =
Aos meus amigos e aos amigos de meus amigos.
Quando a gente vota, escolhe os candidatos que irão nos representar na busca do Bem Comum, que todos nós buscamos.Competência, seriedade, comportamento ético e dignidade são qualidades que, embora raras, todos os polÃticos deviam ter. Mas infelizmente nem todos têm.Por isso, vou votar num polÃtico que sei que, além de cultivar e praticar esses valores, é coerente com eles e trabalha muito, mesmo.Trata-se do JOÃO CARLOS NEDEL â 11633, o vereador que mais trabalha o dia-a-dia da cidade.Para saber a razão da minha escolha, clique aqui.Depois disso, repasse este e-mail a seus amigos e conhecidos, para que também eles possam valorizar os seus votos, votando emJOÃO CARLOS NEDEL nº 11633 Um grande abraço. Walton CarpesÂ
Re: msdosfs_vnops.c u_char toname diff [Was: Re: panic: smashed stack in msdosfs_rename]
On Tue, Sep 04, 2012 at 09:57, Kenneth R Westerback wrote:
The problem seems to be rooted in a desire to printf() the dosname
in a debug statement. Otherwise the dos file names are not treated
as strings anywhere.
An alternate solution, that restores the symmetry between unix2dosfn()
and dos2unixfn(), is to use %.11s to print the dos file name in that
debug chunk, and otherwise consistantly treat the various dos file
names as 11-byte arrays.
Eliminiating one magic number (12) would seem a good thing. :-)
Comments about the non-stringiness of these vars might be good too.
I was looking at this too. There's also de_Name in denode.h and a
printf of that as well. Change that too and ok.
Ken
Index: msdosfs_conv.c
===
RCS file: /cvs/src/sys/msdosfs/msdosfs_conv.c,v
retrieving revision 1.14
diff -u -p -r1.14 msdosfs_conv.c
--- msdosfs_conv.c13 Aug 2009 22:34:29 - 1.14
+++ msdosfs_conv.c4 Sep 2012 13:45:37 -
@@ -403,7 +403,7 @@ dos2unixfn(u_char dn[11], u_char *un, in
* 3 if conversion was successful and generation number was inserted
*/
int
-unix2dosfn(u_char *un, u_char dn[12], int unlen, u_int gen)
+unix2dosfn(u_char *un, u_char dn[11], int unlen, u_int gen)
{
int i, j, l;
int conv = 1;
@@ -416,7 +416,6 @@ unix2dosfn(u_char *un, u_char dn[12], in
*/
for (i = 0; i 11; i++)
dn[i] = ' ';
- dn[11] = 0;
/*
* The filenames . and .. are handled specially, since they
Index: msdosfs_lookup.c
===
RCS file: /cvs/src/sys/msdosfs/msdosfs_lookup.c,v
retrieving revision 1.24
diff -u -p -r1.24 msdosfs_lookup.c
--- msdosfs_lookup.c 4 Jul 2011 04:30:41 - 1.24
+++ msdosfs_lookup.c 4 Sep 2012 13:38:29 -
@@ -104,7 +104,7 @@ msdosfs_lookup(void *v)
struct msdosfsmount *pmp;
struct buf *bp = 0;
struct direntry *dep;
- u_char dosfilename[12];
+ u_char dosfilename[11];
u_char *adjp;
int adjlen;
int flags;
@@ -193,7 +193,7 @@ msdosfs_lookup(void *v)
slotcount = 0;
#ifdef MSDOSFS_DEBUG
- printf(msdosfs_lookup(): dos version of filename %s, length %d\n,
+ printf(msdosfs_lookup(): dos version of filename '%.11s', length %d\n,
dosfilename, cnp-cn_namelen);
#endif
/*
No Te Lo Pierdas -tech- es solo x pocos dias
hola esto es una prueba 120
