Re: remove twm(1) from xenocara ?
I use it, have used it, and will continue to use it full time. It is simple, low resource use and works on any system I have. I don't need any more functionality in a window manager. Anything else can be added on. The argument presented is something like "why would anyone want to do that". geoff steckel On 7/18/22 23:49, Andrei wrote: I would support this. Nobody uses twm for anything other than system rescue, and cwm works great for that. --- Original Message --- On Sunday, July 17th, 2022 at 8:38 AM, Matthieu Herrb wrote:
Re: IPv6 hop-by-hop check in parallel
On 8/13/22 15:08, Alexander Bluhm wrote: Hi, While running forwarding in parallel, I have introduced a hard barrier for parallel local protocol processing. The packets are requeued from shared to exclusive netlock. Unless we unlock all protocol input routines at once, we need some mechanism from to move from one queue to the other. The problem is, that we have to remember next protocol field and offset of the parsed header chain. A simple example is IPv6 hop-by-hop options precessing. This code is MP safe and can be moved from ip6_local() to ip6_ours() to run in parallel. If there were any options, the offset and next protocol are stored in a mbuf tag. Without tag we know that it is a regular IPv6 header. Of course mbuf tags kill performance, but who uses hop-by-hop options anyway? pf drops such packets per default. ok? bluhm This may be totally irrelevant. I may not understand the problem at all. The problem of locking queue-to-queue transfers in a multiprocessor system was addressed at Alliant Computer a very long time ago. Other people probably invented other solutions. They implemented a lock for the queue links only in each type of queue at a higher lock priority than the lock on the data. The sending thread already held a lock on the packet data. It took the queue field lock, transferred the packet and released both locks. I can't be sure which lock(s) the receiving thread held. The point was that neither thread needed to lock both queues. geoff steckel
Re: autopledge
Theo de Raadt wrote: After pledge, 80% of the base programs were converted to pledge-assisted priv-drop, because it was really obvious that "initialization code" could and should be moved earlier in the program, so that pledge (or multiple pledge calls dropping permissions further) could be added to the program. Inside the group, we called this moving of initialization code to earlier "hoisting". Hoisting and cleanup can have very large benefits independent of implementing pledge or other security features. I have seen programs shrink by almost 90% and gain functionality as a result. In one case it -was- a program which ran with privileges equivalent to root. As a byproduct of the cleanup we were later able to assure ourselves that the result needed no more changes to be as secure as we could make it. geoff steckel
newlines and #comments in httpd parse.y
An accidentally unterminated string in httpd.conf results in
the famed yacc "syntax error" message.
For instance:
root "/
}
}
# "hi" <- line xx: syntax error
The loop starting at line 1515 in httpd parse.y
}
switch (c) {
case '\'':
case '"':
quotec = c;
will uncomplainingly eat -anything- up to the matching quote
character even in a comment line.
The resulting error message usually a very long way from
the actual mistake.
Would a change to terminate the string with an error at the
next newline be appropriate? Should quoted newlines be allowed?
Should # comments be allowed and elided, included verbatim,
or cause an error?
I can provide a patch for any of those cases.
geoff steckel
Re: Mention /etc/examples/ in those config files manpages + FILES short description
On 5/1/20 9:13 AM, Theo de Raadt wrote: I think there's a bit of drama going on here. Once a person uses one example in the examples directory, they will become aware of the directory and see it has other files. And possibly use them in the future. It is not clear to me that example discovery has to come via each and every manual page. [snip] Perhaps something like: Index: root.mail === RCS file: /cvs/src/etc/root/root.mail,v retrieving revision 1.137 diff -u -p -u -r1.137 root.mail --- root.mail 5 Apr 2020 16:15:39 - 1.137 +++ root.mail 3 May 2020 01:37:20 - @@ -40,6 +40,8 @@ has been centralized in the file /etc/rc edit the file /etc/rc. The files /etc/rc.securelevel and /etc/rc.local exist for this purpose; the first is run before the system has gone into secure mode; the second is run afterwards (if in doubt, add your tools to rc.local). +The directory /etc/examples contains some sample configuration files +which you can modify to suit your configuration. Please refer to our web pages for any other questions you might have. https://www.OpenBSD.org Geoff Steckel
Re: panic(9): set panicstr atomically
On 5/25/21 10:26 AM, Theo de Raadt wrote: Alexander Bluhm wrote: On Tue, May 25, 2021 at 04:15:26PM +0200, Mark Kettenis wrote: Wouldn't be too hard. But unless you're on a serial console, that will probably be more than a screenful of information, so not terribly useful. The most important things must fit on the first VGA screen. Then user can make a photo. We ship products to customers who only understand this simple step. And when the machine panics, the admin might also panic. Matches my experience. It will be very difficult to show state of multiple cpus on a small screen. On the other hand, only showing the first-panic can hide so much. These garbled reports are actually highlighting a not-simple case. There is big information in the garble. Jumping in, sorry, Some sort of pseudo-ordering where each CPU -mostly- gets to put out more than one character at a time - 2, 3, ... one line max? No guaranteed separation/ordering but might make decipherment easier. No communication or dependence between CPUs needed. Each CPU backs off for a -very- short time after N characters. Nanoseconds or microseconds should work. Initial delay M * CPU ? Spin after N? If clock is ticking, spin for x ticks? Formatting/output time per burst could (maybe) give a little fairness. Apologies if this is nonsense or has been covered already. Geoff Steckel
Re: head(1): fully support the legacy -count syntax
On 10/10/21 5:03 PM, Scott Cheloha wrote:
On Sun, Oct 10, 2021 at 02:36:32PM -0600, Theo de Raadt wrote:
Stuart Henderson wrote:
x1> On 2021/10/10 14:26, Scott Cheloha wrote:
On Sun, Oct 10, 2021 at 12:31:22PM -0600, Theo de Raadt wrote:
Bryan Steele wrote:
On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote:
On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote:
did anyone ever use it this way, or are you getting ahead of yourself.
I don't understand the question.
I've only ever seen it used with -count as the first argument, can't
say it's every occoured to me to type "head file -10".
That is not what I proposed. Reread my first message:
https://marc.info/?l=openbsd-tech&m=163388435528203&w=2
i.e. "head -2 -3 somefile" is taken as -3.
This is unportable syntax, GNU head doesn't support it, current OpenBSD head
doesn't support it,
... obviously. That's why I posted the patch. :)
and it doesn't seem to be really meaningful.
Additionally I don't think we've ever had a problem with this in ports.
I think we would be better served to keep things as-is and not support it.
Seems that FreeBSD is the odd one out here?
If we're only going to support it as the first argument then we've
created a "gotcha", a special exception to the expected behavior. We
claim to support the legacy syntax but we don't actually fully support
it. The requirement that the legacy syntax be the first option
argument to head(1) in order to work as expected is undocumented.
So we could document this peculiarity...
... or we could just use my tiny patch and fully support it and
everything will work as documented today.
Indeed, the problem is our code supports this
but noone else supports it
NetBSD and FreeBSD support it. It was a standard part of the syntax
in SUSv2. I showed you in a private mail that it was supported in
1BSD through 4.3BSD, and then again in 4.4BSD some time in 1992.
Somewhere along the way between CSRG and NetBSD and our repository
the support was removed.
well, someone might accidentally use it in a script they write on OpenBSD
and... it is unportable, the behaviour is either different, or an error
condition
So who benefits? Noone, the way I see it.
If we want to have the unportable legacy syntax then it should work
like other option arguments. Option arguments can be respecified
multiple times in most other utilities. The last such appearance of
an option argument is the one the utility uses. That's how option
arguments work, for the most part.
We could remove the legacy syntax and shave a couple lines of code.
OTOH, supporting it fully is super easy. I've provided a patch.
The man page says head [-count | -n count] [file ...]
There are only two valid switches.
One, the other, or none.
Using more than one is -undefined-.
I doubt it ever has been defined.
It could be asserted that any more than 1 switch is an error.
If you have an old man page that says {[ -count | -n count ] ...}
then your argument has some merit.
geoff steckel
Re: tee(1): increase read buffer to MAXBSIZE bytes
On 11/21/21 10:36 PM, Theo de Raadt wrote: Scott Cheloha wrote: The point of diminishing returns on my machine is 128K. ... So, is 128K ok? Any objections? Many of us have forgotten that our testing machines are at the fast end of the curve. I recommend 64K. I suspect that is still the sweet spot for userland. Above 64K, I think you are hogging the layers of dcache against other processes. Testing this program in isolation is a micro-benchmark. On my slow, small machines transfers > 64K definitely run slower than -exactly- 64K. Any transfer > MAXPHYS needs 2 i/o ops. Anything less wastes time in system calls. My machines are 1.5-2GHz 8GB 2-4 core low end Intel CPUs
Re: scan_ffs(8) and FFS2 filesystems
On 02/08/19 15:35, Jeremie Courreges-Anglas wrote:
I think it's fair to give the user a chance to understand why
scan_ffs(8) won't help in this case.
ok?
--- scan_ffs.8.~1.16.~ Mon Mar 24 00:28:46 2008
+++ scan_ffs.8 Fri Feb 8 21:31:10 2019
@@ -136,6 +136,7 @@ you out of a jam when they happen.
.Sh SEE ALSO
.Xr disklabel 8
.Sh BUGS
-It is not perfect, and could do a lot more things with date/time information
+It is not perfect, does not support FFS2 filesystems,
+and could do a lot more things with date/time information
in the superblocks it finds, but this program has saved more than one butt,
more than once.
Scan_ffs checks for the the magic number of the superblock.
--- scan_ffs.c 23 Nov 2015 19:19:30 - 1.21
+++ scan_ffs.c 9 Feb 2019 02:13:48 -
@@ -67,7 +67,8 @@ ufsscan(int fd, daddr_t beg, daddr_t end
for (n = 0; n < (SBSIZE * SBCOUNT); n += 512){
sb = (struct fs*)(&buf[n]);
- if (sb->fs_magic == FS_MAGIC) {
+ if (sb->fs_magic == FS_UFS1_MAGIC ||
+ sb->fs_magic == FS_UFS2_MAGIC) {
if (flags & FLAG_VERBOSE)
printf("block %lld id %x,%x
size %d\n",
(long long)(blk + (n/512)),
sb->fs_magic == FS_UFS2_MAGIC) {
fixes it.
scan_ffs w/UFS2
This is a patch for scan_ffs to make it find UFS2 partitions. The following test data represents a sample of the various disks available to me at this time. All of the tests are on 6.3 amd64. I haven't updated to 6.4 or snapshots on this machine. By design, scan_ffs can only find intact first superblocks. Backup superblocks do not contain enough data to find the partition start. Deducing partition start addresses from backup superblocks requires interpreting cylinder group data which would be a separate project. The standard warning: if this code melts your machine or makes you turn purple, I told you so. geoff steckel store:gwes:10512$ fdisk sd0 Disk: sd0 geometry: 7783/255/63 [125045424 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 7782 254 63 [ 64: 125033831 ] OpenBSD store:gwes:10513$ disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: SanDisk SDSSDP06 duid: 2a081791fe686cf5 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 7783 total sectors: 125045424 boundstart: 64 boundend: 125033895 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 2097152 64 4.2BSD 2048 16384 1 # / b: 11199210 2097216swap# none c:1250454240 unused d: 8388576 13296448 4.2BSD 2048 16384 1 # /tmp e: 14509792 21685024 4.2BSD 2048 16384 1 # /var f: 4194304 36194816 4.2BSD 2048 16384 1 # /usr g: 2097152 40389120 4.2BSD 2048 16384 1 # /usr/X11R6 h: 15229664 42486272 4.2BSD 2048 16384 1 # /usr/local i: 4194304 57715936 4.2BSD 2048 16384 1 # /usr/src j: 8390200 61910240 4.2BSD 2048 16384 12958 # /usr/obj k: 54733440 70300448 4.2BSD 2048 16384 12958 # /home store:gwes:10517$ obj/scan_ffs -s sd0c ffs at 64 size 2097152 (1.0G) mount / time Wed Feb 13 03:55:34 2019 ffs at 13296448 size 8388576 (4.0G) mount /tmp time Wed Feb 13 03:55:57 2019 ffs at 21685024 size 14509792 (6.9G) mount /var time Wed Feb 13 03:55:51 2019 ffs at 36194816 size 4194304 (2.0G) mount /usr time Wed Feb 13 03:55:42 2019 ffs at 40389120 size 2097152 (1.0G) mount /usr/X11R6 time Wed Feb 13 03:55:53 2019 ffs at 42486272 size 15229664 (7.3G) mount /usr/local time Wed Feb 13 03:55:30 2019 ffs at 57715936 size 4194304 (2.0G) mount /usr/src time Wed Feb 13 03:55:46 2019 ffs at 61910240 size 8390200 (4.0G) mount /usr/obj time Wed Feb 13 03:55:38 2019 ffs at 70300448 size 54733440 (26.1G) mount /home time Wed Feb 13 03:55:55 2019 scan_ffs: read: Invalid argument store:gwes:10518$ fdisk sd5 Disk: sd5 geometry: 267349/255/63 [4294961685 Sectors] Offset: 0 Signature: 0x0 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 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 store:gwes:10519$ disklabel sd5 # /dev/rsd5c: type: SCSI disk: SCSI disk label: SR RAID 1 duid: 3a724c18e7cf99de flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 729340 total sectors: 11716848576 boundstart: 0 boundend: 11716848576 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 5242892928 128 4.2BSD 8192 65536 52270 # /music c: 117168485760 unused d: 5452589440 5242893056 4.2BSD 8192 65536 52270 # /dwar e: 1021366080 10695482496 4.2BSD 4096 32768 26062 # /const store:gwes:10520$ dumpfs -m sd5a # newfs command for sd5a newfs -O 2 -b 65536 -e 8192 -f 8192 -g 2000 -h 64 -m 5 -o time -s 5242892928 sd5a store:gwes:10521$ dumpfs -m sd5d # newfs command for sd5d newfs -O 2 -b 65536 -e 8192 -f 8192 -g 2000 -h 64 -m 5 -o time -s 5452589440 sd5d store:gwes:10522$ dumpfs -m sd5e # newfs command for sd5e newfs -O 1 -b 32768 -e 8192 -f 4096 -g 4 -h 64 -m 5 -o time -s 10213660
scan_ffs, take 2
This is an update to scan_ffs to (a) identify UFS2 superblocks
and (b) output a great deal of information about what it finds.
It distinguishes primary superblocks from alternate ones.
It does its best to give enough information to untangle
good partitions from remnants of obsolete partitions.
It deduces enough information from alternate superblocks
to recreate a disklabel even if the primany superblock is absent.
If alternate superblocks carried their own logical block
number as a back-reference this program would be a lot simpler.
It works on the disks on my systems which are
either 6.3 or 6.4 amd64 with both UFS1 and UFS2 partitions.
Test data (voluminous) available on request.
geoff steckel
Index: scan_ffs.c
===
RCS file: /cvs/src/sbin/scan_ffs/scan_ffs.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 scan_ffs.c
--- scan_ffs.c 23 Nov 2015 19:19:30 - 1.21
+++ scan_ffs.c 17 Feb 2019 02:07:28 -
@@ -1,7 +1,6 @@
-/* $OpenBSD: scan_ffs.c,v 1.21 2015/11/23 19:19:30 deraadt Exp $ */
-
/*
* Copyright (c) 1998 Niklas Hallqvist, Tobias Weingartner
+ * Copyright (c) 2019 Geoff Steckel
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -25,6 +24,7 @@
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include
#include
#include
#include
@@ -37,95 +37,188 @@
#include
#include
-#define SBCOUNT 64 /* XXX - Should be configurable */
+#define RDCOUNT 64 /* XXX - Should be configurable */
/* Flags to control ourselves... */
#define FLAG_VERBOSE 1
#define FLAG_SMART 2
#define FLAG_LABELS4
+#define is_ufs1(fs) ((fs)->fs_magic == FS_UFS1_MAGIC)
+#define is_ufs2(fs) ((fs)->fs_magic == FS_UFS2_MAGIC)
+
+#define x_strof(x) #x
+#define s_strof(y) x_strof(y)
+#define S_MAXMNTLEN s_strof(MAXMNTLEN)
+
+#define NFSIDS 20
+
+struct fsident {
+ int32_t fsi_id[2]; /* id from 1st sb seen */
+ off_t fsi_end;/* last block for this sb */
+ off_t fsi_beg;/* base for this sb */
+ charfsi_mnt[MAXMNTLEN + 1]; /* name of last mount */
+} fsidtab[NFSIDS];
+
+intnfsident ;
+
static void usage(void);
+static void ffs1_compat_read(struct fs *);
+static int is_sblock(const struct fs *);
+static int is_cg(const struct cg *);
+static int ufsscan(daddr_t, daddr_t);
+static daddr_t check_block(struct fs *, daddr_t);
+static int try_find_base(struct fs *, daddr_t, daddr_t *);
+static struct fsident *find_end_id(daddr_t, int *);
+static int find_enter_id(struct fs *, daddr_t, daddr_t);
+static void remove_id(struct fsident *);
+
+int flags;
+int disk_fd;
static int
-ufsscan(int fd, daddr_t beg, daddr_t end, int flags)
+ufsscan(daddr_t beg_blkno, daddr_t end_blkno)
{
- static char lastmount[MAXMNTLEN];
- static u_int8_t buf[SBSIZE * SBCOUNT];
+ static u_int8_t buf[SBSIZE * (RDCOUNT + 1)];
struct fs *sb;
- daddr_t blk, lastblk;
+ daddr_t blk;
int n;
+ ssize_t nread;
+ daddr_t blkno;
+ daddr_t jump;
- lastblk = -1;
- memset(lastmount, 0, MAXMNTLEN);
-
- for (blk = beg; blk <= ((end<0)?blk:end); blk += (SBCOUNT*SBSIZE/512)){
- memset(buf, 0, SBSIZE * SBCOUNT);
- if (lseek(fd, (off_t)blk * 512, SEEK_SET) < 0)
+ for (blk = beg_blkno; blk <= end_blkno; blk += (RDCOUNT * SBSIZE /
DEV_BSIZE)) {
+ if (lseek(disk_fd, (off_t)blk * DEV_BSIZE, SEEK_SET) < 0)
err(1, "lseek");
- if (read(fd, buf, SBSIZE * SBCOUNT) < 0)
+ /* read 1 sblock-size extra to prevent running off end of buf */
+ nread = read(disk_fd, buf, SBSIZE * (RDCOUNT + 1)) ;
+ if (nread == -1)
err(1, "read");
+ nread -= SBSIZE;
- for (n = 0; n < (SBSIZE * SBCOUNT); n += 512){
- sb = (struct fs*)(&buf[n]);
- if (sb->fs_magic == FS_MAGIC) {
- if (flags & FLAG_VERBOSE)
- printf("block %lld id %x,%x size %d\n",
- (long long)(blk + (n/512)),
- sb->fs_id[0], sb->fs_id[1],
- sb->fs_ffs1_size);
-
- if (((blk+(n/512)) - lastblk) == (SBSIZE/512)) {
- if (flags & FLAG_LABELS ) {
- printf("X: %lld %lld 4.2BSD %d
%d %d # %s\n",
- ((off_t)sb->fs_ffs1_size *
- sb->fs_fsize / 512),
- (long long)(blk + (n/512) -
-
scan_ffs minimal ufs2
Fixed 2 bugs:
size output was in bytes not DEV_BSIZE blocks
would not find fs with fs_frag == 4096
Added:
recognize UFS2
Index: scan_ffs.c
===
RCS file: /cvs/src/sbin/scan_ffs/scan_ffs.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 scan_ffs.c
--- scan_ffs.c 23 Nov 2015 19:19:30 - 1.21
+++ scan_ffs.c 18 Feb 2019 02:02:37 -
@@ -45,6 +45,7 @@
#define FLAG_LABELS4
static void usage(void);
+static void ffs1_compat_read(struct fs *);
static int
ufsscan(int fd, daddr_t beg, daddr_t end, int flags)
@@ -66,39 +67,49 @@ ufsscan(int fd, daddr_t beg, daddr_t end
err(1, "read");
for (n = 0; n < (SBSIZE * SBCOUNT); n += 512){
+ long long sboff;
sb = (struct fs*)(&buf[n]);
- if (sb->fs_magic == FS_MAGIC) {
+ if (sb->fs_magic == FS_UFS1_MAGIC ||
+ sb->fs_magic == FS_UFS2_MAGIC) {
+ ffs1_compat_read(sb);
if (flags & FLAG_VERBOSE)
- printf("block %lld id %x,%x size %d\n",
+ printf("block %lld id %x,%x size
%lld\n",
(long long)(blk + (n/512)),
sb->fs_id[0], sb->fs_id[1],
- sb->fs_ffs1_size);
+ sb->fs_size * sb->fs_fsize / 512);
- if (((blk+(n/512)) - lastblk) == (SBSIZE/512)) {
+ if (sb->fs_magic == FS_UFS1_MAGIC)
+ sboff = SBLOCK_UFS1;
+ else
+ sboff = SBLOCK_UFS2;
+ if ((blk+(n/512) - lastblk) ==
+ (fsbtodb(sb, cgsblock(sb, 0)) -
+ sboff / 512)) {
if (flags & FLAG_LABELS ) {
printf("X: %lld %lld 4.2BSD %d
%d %d # %s\n",
- ((off_t)sb->fs_ffs1_size *
+ ((off_t)sb->fs_size *
sb->fs_fsize / 512),
(long long)(blk + (n/512) -
- (2*SBSIZE/512)),
+ fsbtodb(sb, cgsblock(sb,
0))),
sb->fs_fsize, sb->fs_bsize,
sb->fs_cpg, lastmount);
} else {
/* XXX 2038 */
- time_t t = sb->fs_ffs1_time;
+ time_t t = sb->fs_time;
printf("ffs at %lld size %lld "
"mount %s time %s",
(long long)(blk+(n/512) -
- (2*SBSIZE/512)),
- (long
long)(off_t)sb->fs_ffs1_size *
- sb->fs_fsize,
+ fsbtodb(sb, cgsblock(sb,
0))),
+ (long
long)(off_t)sb->fs_size *
+ sb->fs_fsize / 512,
lastmount, ctime(&t));
}
if (flags & FLAG_SMART) {
- off_t size =
(off_t)sb->fs_ffs1_size *
- sb->fs_fsize;
+ off_t size = (off_t)sb->fs_size
*
+ sb->fs_fsize -
+ fsbtodb(sb, cgsblock(sb,
0)) * 512;
if ((n + size) < (SBSIZE *
SBCOUNT))
n += size;
@@ -181,3 +192,22 @@ main(int argc, char *argv[])
return (ufsscan(fd, beg, end, flags));
}
+
+static void
+ffs1_compat_read(struct fs *fs)
+{
+ if (fs->fs_magic == FS_UFS2_MAGIC)
+ return; /* UFS2 */
+ if (fs->fs_sblockloc == 0)
+ fs->fs_sblockloc = SBLOCK_UFS1;
+ fs->fs_flags = fs->fs_ffs1_flags;
+ fs->fs_maxbsize = fs->fs_bsize;
+ fs->fs_time = fs->fs_ffs1
bug in locate
In the 4.7 release of locate there's a bug where
locate -i 'old'
matches Old OLD olD etc
but
locate -i '*old*'
only matches old
There is a missing conditional in fastfind.c:
BEGIN diff -u HERE - fastfind.c 1.10
--- fastfind.c.old Mon Jun 8 16:18:57 2009
+++ fastfind.c Fri May 21 22:17:35 2010
@@ -305,7 +305,11 @@
shortpath = basename(path);
if ((!f_basename && (!globflag ||
+#ifdef FF_ICASE
+ !fnmatch(pathpart, shortpath,
FNM_CASEFOLD)))
+#else /* FF_ICASE */
!fnmatch(pathpart, shortpath, 0)))
+#endif /* FF_ICASE */
|| (strstr(shortpath, pathpart) !=
NULL)) {
if (f_silent)
END diff -u HERE
Thanks!
geoff steckel
thanks for vether
Thank you, Theo (and everyone else who worked on it) for vether. It works beautifully. My firewall now can run with two interfaces where it needed three before and my pf.conf is 30 lines shorter with simpler rules. The configuration iswan <-> sk0 <-> bridge <-> re0 <-> lan ^ | vether0 <-> firewall internal where sk0 and re0 have no IP assigned and vether0 has all of the firewall's IP addresses. This is necessary because Verizon assigned me xxx.178 through 181 routing through .1 - there is no "transit" subnet between the firewall and the remote router, so the firewall IP must be visible both on the WAN and LAN. This is one more step which makes OpenBSD cleaner & easier to use as a network gateway. geoff steckel curmudgeon for hire gwes at oat dot com
Re: Scheduler hack for multi-threaded processes
On 03/23/2016 18:58, Alexandre Ratchov wrote: On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote: This doesn't only change the sched_yield() behaviour, but also modifies how in-kernel yield() calls behave for threaded processes. That is probably not right. So here is a diff that keeps yield() the same and adds the code in the sched_yield(2) implementation instead. It also changes the logic that picks the priority to walk the complete threads listand pick the highest priotity of all the threads. That should be enough to make sure the calling thread is scheduled behind all other threads from the same process. That does require us to grab the kernel lock though. So this removes NOLOCK from sched_yield(2). I don't think that is a big issue. I used to think that this is a hack, but now i think this is necessary. Even if one day we fix the "browsers problem" in the thread library, I think this diff will remain necessary to handle processes calling sched_yield() in a loop, i.e. processes that are spinning. Complete and utter hack: penalize processes or threads on #system calls/time period. Syscalls are more expensive than normal execution because of locking which blocks other processes. Reset the counter when process transitions from inactive->active. I know that some systems have implemented this type of input to scheduling according to use of intangible resources. Geoff Steckel
Re: reloading pf through ansible easy hook
On 11/22/16 15:36, John Boeske wrote: On Tue, Nov 22, 2016 at 10:46 AM, John Boeske wrote I don't understand this philosophical point - why wouldn't you want the rc.d framework to manage pf, quota, etc. whenever it's natural. With pf, for example, it surely is. One of the reasons I loved AIX's System Resource Controller (SRC) was that it did present a unified management interface to all system resources whether daemon or built in. Using a consistent rc.d/rcctl framework to manage system services and daemons - even pkg_add daemons - seems a good idea. Consistent interfaces, fewer interfaces, less special-casing all simplify management, thus minimize the chance of error and enhance security. This is true whether management is local or through a remote tool like ansible. Or? Oops. Meant "pkg_script daemons" above... John I designed a single-point-of-control management system for AIX clusters. It was five software layers - three on the control two on the controlled system. All of the layers were necessary for reliable and reconfigurable operation. As you may think it wasn't easy. It *did* work very well and was configurable. It had to be since it rode on top of all the normal Unix-like system control programs. It *was* reconfigurable so it could track AIX updates (and IBM requirement changes). Before you advocate adding layers consider all the possible error paths including hangs. Consider tracking interactions between subsystems. Consider how you'll report errors and status. To do it right isn't simple. Geoff Steckel
Re: pair(4) (was: connect routing domains on layer 2)
On 10/24/15 06:46, Reyk Floeter wrote: vether doesn't help as it is not transmitting any traffic. in other words, "vether is a bridge endpoint" "pair is a bridge link" This may be a dead topic, but doesn't bridge_output() transmit for vether(4)? Or am I missing the point entirely? pair(4) does look very useful as a "cable". I just wonder why bridge(4) doesn't act more like a physical switch which would accept the single endpoint of a vether(4) Geoff Steckel
restricting DNS to port 53
Will unbound and nsd be restricted to port 53 only? Restricting unbound and nsd to port 53 would be a flag day for me. I am simulating bind's views for my split horizon by using two copies of nsd, one of which serves external queries and one which unbound queries for internal zones. They share some zone files. The internal and external views are split into separate zone files by a script when one or the other changes. The internal nsd serves from port 10053 so that it isn't visible to random programs expecting a recursive server. Note that port options are explicit in release versions of man unbound.conf and nsd.conf. I am using stub-zone in unbound pointing to my internal nsd on port 10053. Using local-data is both ugly and impractical since my internal zone changes frequently. The solutions I see are: Ideally, implement views in nsd. There is no mention of "split horizon" or "views" in the nsd archive. I haven't looked at their repository to see if there is WIP. My probable solution: add a loopback interface on (say) 127.0.1.1 make unbound and nsd communicate there on port 53 Ugly and philosophically bad: generate unbound.conf from zone files or modify unbound to read zone files Comments? Geoff Steckel
Re: restricting DNS to port 53
Apologies... I found a set of how-tos on the web. They suggest the "use a separate address for the internal nsd". I will change my setup accordingly. On 11/04/15 09:31, gwes wrote: Will unbound and nsd be restricted to port 53 only? Restricting unbound and nsd to port 53 would be a flag day for me. I am simulating bind's views for my split horizon by using two copies of nsd, one of which serves external queries and one which unbound queries for internal zones. They share some zone files. The internal and external views are split into separate zone files by a script when one or the other changes. The internal nsd serves from port 10053 so that it isn't visible to random programs expecting a recursive server. Note that port options are explicit in release versions of man unbound.conf and nsd.conf. I am using stub-zone in unbound pointing to my internal nsd on port 10053. Using local-data is both ugly and impractical since my internal zone changes frequently. The solutions I see are: Ideally, implement views in nsd. There is no mention of "split horizon" or "views" in the nsd archive. I haven't looked at their repository to see if there is WIP. My probable solution: add a loopback interface on (say) 127.0.1.1 make unbound and nsd communicate there on port 53 Ugly and philosophically bad: generate unbound.conf from zone files or modify unbound to read zone files Comments? Geoff Steckel
Thanks for pair(4)
Thanks very much to reyk@ and everyone else who helped create pair(4). It makes my configuration much simpler and (more) maintainable. Geoff Steckel
proposed speedup for diff -q
Proposed enhancement to diff:
diff of two very different files can take a very long time
and a lot of memory.
diff -q uses the same algorithm even though the status is
known at the first difference.
I propose ending the comparison at the first difference if
diff is invoked with -q
diff is not invoked with -w, -i, or -b
The changes pass the regression tests and all the tests I've tried.
I believe the changes are not machine dependent.
I invite criticism and counterexamples.
Example:
$ ls -l trash.120403 trash.120711
-rw--- 1 gwes users 249686538 Apr 3 2012 trash.120403
-rw-r--r-- 1 gwes users 142356923 Jul 11 2012 trash.120711
$ time diff -q trash.120403 trash.120711
diff:
1m51.52s real 1m47.66s user 0m2.46s system
top output:
load averages: 1.02, 0.91, 0.58.oat.com 15:41:54
49 processes: 47 idle, 2 on processor
CPU0 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU1 states: 98.4% user, 0.0% nice, 1.6% system, 0.0% interrupt, 0.0% idle
Memory: Real: 403M/785M act/tot Free: 796M Cache: 312M Swap: 0K/1248M
PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
18740 gwes 570 362M 333M onproc/1 biowait 1:05 95.61% diff
$ time work/newdiff/diff -q trash.120403 trash.120711
Files trash.120403 and trash.120711 differ
0m0.00s real 0m0.00s user 0m0.00s system
The code changes
$ diff -u diff.h work/newdiff/diff.h
--- diff.h Thu May 15 16:29:15 2014
+++ work/newdiff/diff.h Thu May 15 15:57:30 2014
@@ -64,6 +64,10 @@
#define D_PROTOTYPE0x080 /* Display C function prototype */
#define D_EXPANDTABS 0x100 /* Expand tabs to spaces */
#define D_IGNOREBLANKS 0x200 /* Ignore white space changes */
+ /* test for possible return at first difference
*/
+#define CANBRIEFRETURN(flags) (((flags) & (D_FOLDBLANKS | D_IGNORECASE \
+ | D_IGNOREBLANKS \
+ )) == 0)
/*
* Status values for print_status() and diffreg() return values
$ diff -u diffreg.c work/newdiff/diffreg.c
--- diffreg.c Thu May 15 16:29:15 2014
+++ work/newdiff/diffreg.c Thu May 15 16:31:19 2014
@@ -366,6 +366,15 @@
status |= 1;
goto closem;
}
+ if ((diff_format == D_BRIEF) && CANBRIEFRETURN(flags)) {
+ anychange = 1;
+ if (flags & D_HEADER) {
+ diff_output("%s %s %s\n", \
+ diffargs, file1, file2);
+ flags &= ~D_HEADER;
+ }
+ goto closem;
+ }
if (lflag) {
/* redirect stdout to pr */
int pfd[2];
kernel crash operating USB device programmer
I'm trying to operate an Atmel AVRISP mkII device programmer using the "avrdude" program. The kernel crashes identically running either 6.0 release or 6.1 snapshot. Is this a known problem? Here is the ddb output and the dmesg. I will try to produce any other useful data or to use ddb to examine the kernel. If a crash dump is useful I can put one on the web for download. I can try to trace the program execution prior to the crash. I don't think ktrace would help unless it does fsync after every entry... Thanks Geoff Steckel Mar 10 19:58:48 store /bsd: panic: ehci_device_clear_toggle: queue active Mar 10 19:58:48 store /bsd: Stopped at Debugger+0x9: leave Mar 10 19:58:48 store /bsd:TIDPIDUID PRFLAGS PFLAGS CPU COMMAND Mar 10 19:58:48 store /bsd: * 2171 2171 0 0x3 00 avrdude Mar 10 19:58:48 store /bsd: Debugger() at Debugger+0x9 Mar 10 19:58:48 store /bsd: panic() at panic+0xfe Mar 10 19:58:48 store /bsd: ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b Mar 10 19:58:48 store /bsd: usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x24 Mar 10 19:58:48 store /bsd: ugen_do_read() at ugen_do_read+0x4e6 Mar 10 19:58:48 store /bsd: ugenread() at ugenread+0x48 Mar 10 19:58:48 store /bsd: spec_read() at spec_read+0x2c5 Mar 10 19:58:48 store /bsd: VOP_READ() at VOP_READ+0x3f Mar 10 19:58:48 store /bsd: vn_read() at vn_read+0xa1 Mar 10 19:58:48 store /bsd: dofilereadv() at dofilereadv+0x204 Mar 10 19:58:48 store /bsd: sys_read() at sys_read+0x89 Mar 10 19:58:48 store /bsd: syscall() at syscall+0x27b Mar 10 19:58:48 store /bsd: --- syscall (number 3) --- Mar 10 19:58:48 store /bsd: end trace frame: 0x0, count: 3 Mar 10 19:58:48 store /bsd: 0x108592d58a1a: Mar 10 20:26:39 store /bsd: OpenBSD 6.1-beta (GENERIC.MP) #224: Thu Mar 9 18:50:15 MST 2017 Mar 10 20:26:39 store /bsd: dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Mar 10 20:26:39 store /bsd: real mem = 8466022400 (8073MB) Mar 10 20:26:39 store /bsd: avail mem = 8204775424 (7824MB) Mar 10 20:26:39 store /bsd: mpath0 at root Mar 10 20:26:39 store /bsd: scsibus0 at mpath0: 256 targets Mar 10 20:26:39 store /bsd: mainbus0 at root Mar 10 20:26:39 store /bsd: bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb450 (20 entries) Mar 10 20:26:39 store /bsd: bios0: vendor American Megatrends Inc. version "4.6.5" date 06/05/2013 Mar 10 20:26:39 store /bsd: bios0: BIOSTAR Group NM70I-1037U Mar 10 20:26:39 store /bsd: acpi0 at bios0: rev 2 Mar 10 20:26:39 store /bsd: acpi0: sleep states S0 S1 S4 S5 Mar 10 20:26:39 store /bsd: acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT Mar 10 20:26:39 store /bsd: acpi0: wakeup devices PS2K(S4) UAR1(S4) P0P1(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) [...] Mar 10 20:26:39 store /bsd: acpitimer0 at acpi0: 3579545 Hz, 24 bits Mar 10 20:26:39 store /bsd: acpimadt0 at acpi0 addr 0xfee0: PC-AT compat Mar 10 20:26:39 store /bsd: cpu0 at mainbus0: apid 0 (boot processor) Mar 10 20:26:39 store /bsd: cpu0: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz, 1796.21 MHz Mar 10 20:26:39 store /bsd: cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT Mar 10 20:26:39 store /bsd: cpu0: 256KB 64b/line 8-way L2 cache Mar 10 20:26:39 store /bsd: cpu0: TSC frequency 1796209080 Hz Mar 10 20:26:39 store /bsd: cpu0: smt 0, core 0, package 0 Mar 10 20:26:39 store /bsd: mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges Mar 10 20:26:39 store /bsd: cpu0: apic clock running at 99MHz Mar 10 20:26:39 store /bsd: cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE Mar 10 20:26:39 store /bsd: cpu1 at mainbus0: apid 2 (application processor) Mar 10 20:26:39 store /bsd: cpu1: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz, 1795.92 MHz Mar 10 20:26:39 store /bsd: cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT Mar 10 20:26:39 store /bsd: cpu1: 256KB 64b/line 8-way L2 cache Mar 10 20:26:39 store /bsd: cpu1: smt 0, core 1, package 0 Mar 10 20:26:39 store /bsd: ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins Mar 10 20:26:39 store /bsd: acpimcfg0 at acpi0 addr 0xf800, bus 0-63 Mar 10 20:26:39 store /bsd: acpihpet0 at acpi0: 14318179 Hz Mar 10 20:26:39 store /bsd: acpiprt0 at acpi0: bus 0 (PCI0) Mar 10 20:26:39 store /bsd: acpiprt1 at acpi0: bus -1 (P0P1) Mar 10 20:26:39 store /bsd: acpiprt2 at acpi0: bus 2 (RP01) Mar 10 20:26:39 st
