Properly sync filesystems during {suspend,hibernate}/resume
After recent reboot related improvements, I have some familiarity with
tricking the vnode layer into a stable state.
This should settle filesystems "clean" onto disk. If one does a
suspend and then runs out of battery.. or experiences a crash or out
of battery during a hibernate, the filesystems will now be in a clean
state and not require an fsck.
After the screen blanks, there may be 1-2 seconds more IO than before.
Those weren't hitting the platter, but remained in the vfs softlayer
through to resume. The new situation is much better.
I have wanted to solve this problem for years..
There may be problems with softraid again, we'll need to see. I
haven't tested softdep but the correct syncronization functions appear
to be called. USB sticks get detached during the suspend phase, and
are as good as before.
This isn't quite finished, and I have a few more tricks up my sleeve,
and the "vfs_stalling" global will probably become a parameter for
VFS_SYNC()...
I'd appreciate reports about how well it delivers and if any new
problems show up.
Index: kern/vfs_subr.c
===
RCS file: /cvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.265
diff -u -p -u -r1.265 vfs_subr.c
--- kern/vfs_subr.c 14 Dec 2017 20:23:15 - 1.265
+++ kern/vfs_subr.c 16 Dec 2017 23:50:21 -
@@ -1583,6 +1583,42 @@ vaccess(enum vtype type, mode_t file_mod
return (file_mode & mask) == mask ? 0 : EACCES;
}
+int vfs_stalling;
+
+int
+vfs_stallmp(struct mount *mp, struct proc *p, int stall)
+{
+ int error;
+
+ if (stall) {
+ error = vfs_busy(mp, VB_WRITE|VB_WAIT);
+ if (error) {
+ printf("%s: busy\n", mp->mnt_stat.f_mntonname);
+ return (error);
+ }
+ uvm_vnp_sync(mp);
+ vfs_stalling = stall;
+ error = VFS_SYNC(mp, MNT_WAIT, p->p_ucred, p);
+ if (error) {
+ printf("%s: failed to sync\n",
mp->mnt_stat.f_mntonname);
+ vfs_unbusy(mp);
+ return (error);
+ }
+ } else {
+ vfs_unbusy(mp);
+ }
+ return (0);
+}
+
+void
+vfs_stall(struct proc *p, int stall)
+{
+ struct mount *mp, *nmp;
+
+ TAILQ_FOREACH_REVERSE_SAFE(mp, &mountlist, mntlist, mnt_list, nmp)
+ (void) vfs_stallmp(mp, p, stall);
+}
+
int
vfs_readonly(struct mount *mp, struct proc *p)
{
@@ -1627,10 +1663,8 @@ vfs_rofs(struct proc *p)
{
struct mount *mp, *nmp;
- TAILQ_FOREACH_REVERSE_SAFE(mp, &mountlist, mntlist, mnt_list, nmp) {
- /* XXX Here is a race, the next pointer is not locked. */
+ TAILQ_FOREACH_REVERSE_SAFE(mp, &mountlist, mntlist, mnt_list, nmp)
(void) vfs_readonly(mp, p);
- }
}
/*
Index: ufs/ffs/ffs_vfsops.c
===
RCS file: /cvs/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.170
diff -u -p -u -r1.170 ffs_vfsops.c
--- ufs/ffs/ffs_vfsops.c14 Dec 2017 20:20:38 - 1.170
+++ ufs/ffs/ffs_vfsops.c17 Dec 2017 03:03:06 -
@@ -1145,7 +1145,8 @@ struct ffs_sync_args {
};
int
-ffs_sync_vnode(struct vnode *vp, void *arg) {
+ffs_sync_vnode(struct vnode *vp, void *arg)
+{
struct ffs_sync_args *fsa = arg;
struct inode *ip;
int error;
@@ -1193,8 +1194,9 @@ ffs_sync(struct mount *mp, int waitfor,
{
struct ufsmount *ump = VFSTOUFS(mp);
struct fs *fs;
- int error, allerror = 0, count;
+ int error, allerror = 0, count, clean, fmod;
struct ffs_sync_args fsa;
+ extern int vfs_stalling;
fs = ump->um_fs;
/*
@@ -1240,12 +1242,23 @@ ffs_sync(struct mount *mp, int waitfor,
VOP_UNLOCK(ump->um_devvp, p);
}
qsync(mp);
+
/*
* Write back modified superblock.
*/
-
+ clean = fs->fs_clean;
+ fmod = fs->fs_fmod;
+ if (vfs_stalling && (fs->fs_ronly == 0)) {
+ fs->fs_fmod = 1;
+ fs->fs_clean = (fs->fs_flags & FS_UNCLEAN) ? 0 : 1;
+// printf("%s clean %d fmod %d\n",
+// mp->mnt_stat.f_mntonname, fs->fs_clean,
+// fs->fs_fmod);
+ }
if (fs->fs_fmod != 0 && (error = ffs_sbupdate(ump, waitfor)) != 0)
allerror = error;
+ fs->fs_clean = clean;
+ fs->fs_fmod = fmod;
return (allerror);
}
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.335
diff -u -p -u -r1.335 acpi.c
--- dev/acpi/acpi.c 29 Nov 2017 22:51:01 - 1.335
+++ dev/acpi/acpi.c 17 Dec 2017 00:05:29 -
@@ -2439,6 +2439,8 @@ acpi_sleep_state(struct acpi_softc *sc,
{
extern int perflevel;
extern int lid_ac
Re: ypldap patch 5: fix aldap_close
On Sat, Dec 16, 2017 at 08:38:59PM +0300, Vadim Zhukov wrote:
> 2017-12-06 19:12 GMT+03:00 Vadim Zhukov :
> >> The aldap_close() return value is never checked, and I do not see
> >> any good reason to do that. Also, in case close(2) fails, it'll miss
> >> freeing other data.
> >
> > I'm blind. :-\
> >
> > The problem I was looking for was right here: the aldap_close() closes
> > the wrong file descriptor. So here is a better patch that solves
> > actual leak. I ever treat this as a candidate for -STABLE, since
> > when ypldap get stuck, you could be locked out of system.
>
> Sorry for noise, I'm just trying to make this patch go in. I think it
> should because it fixes a real issue seen in the wild (if an isolated
> AD-enabled LAN could be called "wild"). Well, actually it fixes two
> issues, but I found zero code paths for making close() fail in current
> code.
>
> The patched version happily runs for more than a week on (otherwise)
> 6.2-STABLE.
Your diff is correct, but only for the non-tls case. I missed cleaning
up the tls context when I added tls support, and we need to keep the fd
around so we can close it, since tls_close doesn't close file descriptors
that libtls didn't open.
ok?
Index: aldap.c
===
RCS file: /cvs/src/usr.sbin/ypldap/aldap.c,v
retrieving revision 1.37
diff -u -p -u -p -r1.37 aldap.c
--- aldap.c 30 May 2017 09:33:31 - 1.37
+++ aldap.c 17 Dec 2017 03:19:02 -
@@ -70,10 +70,11 @@ aldap_application(struct ber_element *el
int
aldap_close(struct aldap *al)
{
- if (al->fd != -1)
- if (close(al->ber.fd) == -1)
- return (-1);
-
+ if (al->tls != NULL) {
+ tls_close(al->tls);
+ tls_free(al->tls);
+ }
+ close(al->fd);
ber_free(&al->ber);
evbuffer_free(al->buf);
free(al);
@@ -120,7 +121,6 @@ aldap_tls(struct aldap *ldap, struct tls
return (-1);
}
- ldap->fd = -1;
return (0);
}
Re: mg: have Insert key toggle overwrite mode by default
On 12/16/17 17:06, Lari Rasku wrote: There's a fairly strong convention among text editors that the Insert key should toggle overwrite mode. This is admittedly far more common among GUI editors, but could mg adopt it as a default anyway? I'm inclined to agree with at least the general direction, as GNU Emacs even in terminal mode does this. ~Brian diff --git usr.bin/mg/ttykbd.c usr.bin/mg/ttykbd.c index 67bc8e4bd..485291a77 100644 --- usr.bin/mg/ttykbd.c +++ usr.bin/mg/ttykbd.c @@ -52,6 +52,8 @@ ttykeymapinit(void) dobindkey(fundamental_map, "scroll-up", key_npage); if (key_ppage) dobindkey(fundamental_map, "scroll-down", key_ppage); + if (key_ic) + dobindkey(fundamental_map, "overwrite-mode", key_ic); if (key_dc) dobindkey(fundamental_map, "delete-char", key_dc);
mg: have Insert key toggle overwrite mode by default
There's a fairly strong convention among text editors that the Insert key should toggle overwrite mode. This is admittedly far more common among GUI editors, but could mg adopt it as a default anyway? diff --git usr.bin/mg/ttykbd.c usr.bin/mg/ttykbd.c index 67bc8e4bd..485291a77 100644 --- usr.bin/mg/ttykbd.c +++ usr.bin/mg/ttykbd.c @@ -52,6 +52,8 @@ ttykeymapinit(void) dobindkey(fundamental_map, "scroll-up", key_npage); if (key_ppage) dobindkey(fundamental_map, "scroll-down", key_ppage); + if (key_ic) + dobindkey(fundamental_map, "overwrite-mode", key_ic); if (key_dc) dobindkey(fundamental_map, "delete-char", key_dc);
Re: less(1): `!' command
> On Sat, 16 Dec 2017 19:39:27 +, Theo de Raadt wrote: > > > On Sat, 16 Dec 2017 18:13:16 +, Jiri B wrote: > > > > On Sat, Dec 16, 2017 at 04:55:44PM +, kshe wrote: > > > > > Hi, > > > > > > > > > > Would a patch to bring back the `!' command to less(1) be accepted? > > > > > The > > > > > commit message for its removal explains that ^Z should be used > > > > > instead, > > > > > but that obviously does not work if less(1) is run from something else > > > > > than an interactive shell, for example when reading manual pages from > > > > > a > > > > > vi(1) instance spawned directly by `xterm -e vi' in a window manager > > > > > or > > > > > by `neww vi' in a tmux(1) session. > > > > > > > > Why should less be able to spawn another programs? This would undermine > > > > all pledge work. > > > > > > Because of at least `v' and `|', less(1) already is able to invoke > > > arbitrary programs, and accordingly needs the "proc exec" promise, so > > > bringing `!' back would not change anything from a security perspective > > > (otherwise, I would obviously not have made such a proposition). > > > > > > In fact, technically, what I want to do is still currently possible: > > > from any less(1) instance, one may use `v' to invoke vi(1), and then use > > > vi(1)'s own `!' command as desired. So the functionality of `!' is > > > still there; it was only made more difficult to reach for no apparent > > > reason. > > > > No apparent reason? > > > > Good you have an opinion. I have a different opinion: We should look > > for rarely used functionality and gut it. > > I completely agree, and I also completely agree with the rest of what > you said. However, in this particular case, the functionality of `!' is > still fully (albeit indirectly) accessible, as shown above, and this is > why its deletion, when not immediately followed by that of `|' and `v', > made little sense for me. Oh, so you don't agree. Or do you. I can't tell. You haven't made up your mind enough to have a final position? > Either the commands that require "proc exec" should all be removed along > with that promise, or `!' should be brought back without any pledge(2) > modifications. That is pretty absolutist. The universe is not always consistant, and neither is OpenBSD. The final decisions haven't been made yet, because we haven't gauged the usage patterns. > But currently it really feels like a big waste (for both > parties) to request such high privileges, and then to do almost nothing > useful with them. Request? pledge isn't a "request" system. It is a 2nd specification of the program about maximum it believes it will use, and therefore it is a hard brake. At the moment the featureset still needs "proc exec". So the specification isn't a waste, it is accurate. > If the plan really was to get rid of all such commands eventually, what > exactly is preventing that from happening now? The plan was to get rid of ! in a few commands, then later get rid of a few more of them, and see where we end up. With such plans, we don't always act all on one step, because then it is too easy to get embroiled in just that one battle and forget about the other things which also need doing. Also it is impossible to ask the community because petty fights result and provide innaccurate usage assessments. There are many other things to do. As a result, our universe is not always consistant. This is an example. > May I go ahead and prepare a patch to remove "proc exec" entirely? Sure you could try, and see who freaks out. Exactly what the plan was all along.
Re: less(1): `!' command
On Sat, 16 Dec 2017 19:39:27 +, Theo de Raadt wrote: > > On Sat, 16 Dec 2017 18:13:16 +, Jiri B wrote: > > > On Sat, Dec 16, 2017 at 04:55:44PM +, kshe wrote: > > > > Hi, > > > > > > > > Would a patch to bring back the `!' command to less(1) be accepted? The > > > > commit message for its removal explains that ^Z should be used instead, > > > > but that obviously does not work if less(1) is run from something else > > > > than an interactive shell, for example when reading manual pages from a > > > > vi(1) instance spawned directly by `xterm -e vi' in a window manager or > > > > by `neww vi' in a tmux(1) session. > > > > > > Why should less be able to spawn another programs? This would undermine > > > all pledge work. > > > > Because of at least `v' and `|', less(1) already is able to invoke > > arbitrary programs, and accordingly needs the "proc exec" promise, so > > bringing `!' back would not change anything from a security perspective > > (otherwise, I would obviously not have made such a proposition). > > > > In fact, technically, what I want to do is still currently possible: > > from any less(1) instance, one may use `v' to invoke vi(1), and then use > > vi(1)'s own `!' command as desired. So the functionality of `!' is > > still there; it was only made more difficult to reach for no apparent > > reason. > > No apparent reason? > > Good you have an opinion. I have a different opinion: We should look > for rarely used functionality and gut it. I completely agree, and I also completely agree with the rest of what you said. However, in this particular case, the functionality of `!' is still fully (albeit indirectly) accessible, as shown above, and this is why its deletion, when not immediately followed by that of `|' and `v', made little sense for me. Either the commands that require "proc exec" should all be removed along with that promise, or `!' should be brought back without any pledge(2) modifications. But currently it really feels like a big waste (for both parties) to request such high privileges, and then to do almost nothing useful with them. If the plan really was to get rid of all such commands eventually, what exactly is preventing that from happening now? May I go ahead and prepare a patch to remove "proc exec" entirely? Regards, kshe
Re: less(1): `!' command
> > Would a patch to bring back the `!' command to less(1) be accepted? The > > commit message for its removal explains that ^Z should be used instead, > > but that obviously does not work if less(1) is run from something else > > than an interactive shell, for example when reading manual pages from a > > vi(1) instance spawned directly by `xterm -e vi' in a window manager or > > by `neww vi' in a tmux(1) session. > > Why should less be able to spawn another programs? This would undermine > all pledge work. It does not undermine any pledge work at all. The strategy is reduction of "many programs have ways to break out to full system call operation, but why?" Fixing all of these concerns won't happen in a day. We are boiling this frog slowly.
Re: less(1): `!' command
> On Sat, 16 Dec 2017 18:13:16 +, Jiri B wrote: > > On Sat, Dec 16, 2017 at 04:55:44PM +, kshe wrote: > > > Hi, > > > > > > Would a patch to bring back the `!' command to less(1) be accepted? The > > > commit message for its removal explains that ^Z should be used instead, > > > but that obviously does not work if less(1) is run from something else > > > than an interactive shell, for example when reading manual pages from a > > > vi(1) instance spawned directly by `xterm -e vi' in a window manager or > > > by `neww vi' in a tmux(1) session. > > > > Why should less be able to spawn another programs? This would undermine > > all pledge work. > > Because of at least `v' and `|', less(1) already is able to invoke > arbitrary programs, and accordingly needs the "proc exec" promise, so > bringing `!' back would not change anything from a security perspective > (otherwise, I would obviously not have made such a proposition). > > In fact, technically, what I want to do is still currently possible: > from any less(1) instance, one may use `v' to invoke vi(1), and then use > vi(1)'s own `!' command as desired. So the functionality of `!' is > still there; it was only made more difficult to reach for no apparent > reason. No apparent reason? Good you have an opinion. I have a different opinion: We should look for rarely used functionality and gut it. Over the last 40 years people have felt a desire to add all possible features and options to all commands, and noone ever considered the impact of having all programs above to reach all system calls, and that these features are being installed in all program operating environents. Then someone adds less(1) to a script which requires security, and just like that it has none. The entire environment is poisoned, and people are pushed to jump to other environments which aren't poisoned in this way, until enough people arrive there, the feature explosion happens there also resulting in "reach all the system calls", and we're stuck in the same rut again. I don't think all programs should be able to run all other programs. As a result I support the idea of trying to find the things people don't actually use, and removing them incrementally. '|' should be on the list next. But you don't. Luckily you have other choices. Are you prepared to die on this hill that less must support '!'? If so, there's that FreeBSD hill over there..
Re: less(1): `!' command
On Sat, 16 Dec 2017 18:13:16 +, Jiri B wrote: > On Sat, Dec 16, 2017 at 04:55:44PM +, kshe wrote: > > Hi, > > > > Would a patch to bring back the `!' command to less(1) be accepted? The > > commit message for its removal explains that ^Z should be used instead, > > but that obviously does not work if less(1) is run from something else > > than an interactive shell, for example when reading manual pages from a > > vi(1) instance spawned directly by `xterm -e vi' in a window manager or > > by `neww vi' in a tmux(1) session. > > Why should less be able to spawn another programs? This would undermine > all pledge work. Because of at least `v' and `|', less(1) already is able to invoke arbitrary programs, and accordingly needs the "proc exec" promise, so bringing `!' back would not change anything from a security perspective (otherwise, I would obviously not have made such a proposition). In fact, technically, what I want to do is still currently possible: from any less(1) instance, one may use `v' to invoke vi(1), and then use vi(1)'s own `!' command as desired. So the functionality of `!' is still there; it was only made more difficult to reach for no apparent reason. Regards, kshe
Re: Add "-c command" option to script(1)
On Sat, Dec 16, 2017 at 09:45:02AM +0100, Paul de Weerd wrote: > On Fri, Dec 15, 2017 at 12:24:45PM +0100, Paul de Weerd wrote: > | I've updated the diff to add this example as per jmc's suggestion. It > | now has: > | > | - add the `-c command` feature > | - updates usage > | - removes /* ARGSUSED */ lint comments > | - documents the -c feature > | - adds an example to the manpage > > jmc@ pointed out a missing colon at the end of the example. Apologies > for the extra noise. Updated diff (still covers the above five > changes) included. OK job@
ps.1: command keyword width
Hi Ingo,
the "command" keyword is restricted in width even if termwidth is
unlimited. See print.c, command():
...
if (ve->next != NULL || termwidth != UNLIMITED) {
It would be nice if this could be documented. Maybe something like this:
Index: ps.1
===
RCS file: /home/vcs/cvs/openbsd/src/bin/ps/ps.1,v
retrieving revision 1.111
diff -u -p -r1.111 ps.1
--- ps.126 Oct 2016 01:20:39 - 1.111
+++ ps.116 Dec 2017 16:40:04 -
@@ -201,6 +201,7 @@ Accounting flag.
Alias:
.Cm args .
Command and arguments.
+Must appear last for unlimited width.
.It Cm cpu
Short-term CPU usage factor (for scheduling).
.It Cm cpuid
Re: less(1): `!' command
On Sat, Dec 16, 2017 at 04:55:44PM +, kshe wrote: > Hi, > > Would a patch to bring back the `!' command to less(1) be accepted? The > commit message for its removal explains that ^Z should be used instead, > but that obviously does not work if less(1) is run from something else > than an interactive shell, for example when reading manual pages from a > vi(1) instance spawned directly by `xterm -e vi' in a window manager or > by `neww vi' in a tmux(1) session. Why should less be able to spawn another programs? This would undermine all pledge work. IIUC your vi scenario, you are not spawing 'vi' from less but the opposite way. That should work. j.
Re: ypldap patch 5: fix aldap_close
2017-12-06 19:12 GMT+03:00 Vadim Zhukov :
>> The aldap_close() return value is never checked, and I do not see
>> any good reason to do that. Also, in case close(2) fails, it'll miss
>> freeing other data.
>
> I'm blind. :-\
>
> The problem I was looking for was right here: the aldap_close() closes
> the wrong file descriptor. So here is a better patch that solves
> actual leak. I ever treat this as a candidate for -STABLE, since
> when ypldap get stuck, you could be locked out of system.
Sorry for noise, I'm just trying to make this patch go in. I think it
should because it fixes a real issue seen in the wild (if an isolated
AD-enabled LAN could be called "wild"). Well, actually it fixes two
issues, but I found zero code paths for making close() fail in current
code.
The patched version happily runs for more than a week on (otherwise) 6.2-STABLE.
> Index: aldap.c
> ===
> RCS file: /cvs/src/usr.sbin/ypldap/aldap.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 aldap.c
> --- aldap.c 30 May 2017 09:33:31 - 1.37
> +++ aldap.c 6 Dec 2017 13:11:59 -
> @@ -67,18 +67,14 @@ aldap_application(struct ber_element *el
> return BER_TYPE_OCTETSTRING;
> }
>
> -int
> +void
> aldap_close(struct aldap *al)
> {
> if (al->fd != -1)
> - if (close(al->ber.fd) == -1)
> - return (-1);
> -
> + close(al->fd);
> ber_free(&al->ber);
> evbuffer_free(al->buf);
> free(al);
> -
> - return (0);
> }
>
> struct aldap *
> Index: aldap.h
> ===
> RCS file: /cvs/src/usr.sbin/ypldap/aldap.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 aldap.h
> --- aldap.h 30 May 2017 09:33:31 - 1.10
> +++ aldap.h 6 Dec 2017 13:11:59 -
> @@ -206,7 +206,7 @@ enum subfilter {
> struct aldap *aldap_init(int);
> int aldap_tls(struct aldap *, struct tls_config *,
> const char *);
> -int aldap_close(struct aldap *);
> +voidaldap_close(struct aldap *);
> struct aldap_message *aldap_parse(struct aldap *);
> voidaldap_freemsg(struct aldap_message *);
>
--
WBR,
Vadim Zhukov
dc(1): properly report errors
Hi,
On error, the BN functions do not set errno, so errx(3) should be used
instead of err(3). Moreover, one may call ERR_reason_error_string(3) to
obtain a real error message from an error code.
$ dc -e '2 2 64^^'
dc: big number failure 3fff072: Undefined error: 0
$ ./dc -e '2 2 64^^'
dc: BN failure: bignum too long
Index: mem.c
===
RCS file: /cvs/src/usr.bin/dc/mem.c,v
retrieving revision 1.9
diff -u -p -r1.9 mem.c
--- mem.c 12 Dec 2017 19:08:57 - 1.9
+++ mem.c 15 Dec 2017 09:35:48 -
@@ -91,13 +91,19 @@ bstrdup(const char *p)
void
bn_check(int x)
{
- if (x == 0)
- err(1, "big number failure %lx", ERR_get_error());
+ if (x == 0) {
+ ERR_load_BN_strings();
+ errx(1, "BN failure: %s",
+ ERR_reason_error_string(ERR_get_error()));
+ }
}
void
bn_checkp(const void *p)
{
- if (p == NULL)
- err(1, "allocation failure %lx", ERR_get_error());
+ if (p == NULL) {
+ ERR_load_BN_strings();
+ errx(1, "BN failure: %s",
+ ERR_reason_error_string(ERR_get_error()));
+ }
}
Regards,
kshe
less(1): `!' command
Hi, Would a patch to bring back the `!' command to less(1) be accepted? The commit message for its removal explains that ^Z should be used instead, but that obviously does not work if less(1) is run from something else than an interactive shell, for example when reading manual pages from a vi(1) instance spawned directly by `xterm -e vi' in a window manager or by `neww vi' in a tmux(1) session. If not, then at least documentation for this command should be removed properly (I cannot provide a diff as this file contains raw backspace characters): $ cd /usr/src/usr.bin/less/ $ printf '99d\nwq\n' | ed - less.hlp Regards, kshe
Re: net/rtsock.c: size to free(9)
On Wed, 13 Dec 2017 08:56:53 +, Martin Pieuchot wrote:
> Thanks. I'd suggest you for the next time to not to mix withespace or
> style changes with a functional change.
>
> That said it'd be great if you could look at other free(9) calls missing
> the size argument.
The diff below deals with the last three calls in rtsock.c. The case of
rt_llinfo when RTF_MPLS is set in rt_flags seems safe as it is similar
to what has already been done in route.c.
Index: rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.258
diff -u -p -r1.258 rtsock.c
--- rtsock.c13 Dec 2017 08:59:02 - 1.258
+++ rtsock.c14 Dec 2017 16:13:04 -
@@ -980,7 +980,8 @@ change:
/* if gateway changed remove MPLS information */
if (rt->rt_llinfo != NULL &&
rt->rt_flags & RTF_MPLS) {
- free(rt->rt_llinfo, M_TEMP, 0);
+ free(rt->rt_llinfo, M_TEMP,
+ sizeof(struct rt_mpls));
rt->rt_llinfo = NULL;
rt->rt_flags &= ~RTF_MPLS;
}
@@ -1363,22 +1364,20 @@ again:
/* align message length to the next natural boundary */
len = ALIGN(len);
if (cp == 0 && w != NULL && !second_time) {
- struct walkarg *rw = w;
-
- rw->w_needed += len;
- if (rw->w_needed <= 0 && rw->w_where) {
- if (rw->w_tmemsize < len) {
- free(rw->w_tmem, M_RTABLE, 0);
- rw->w_tmem = malloc(len, M_RTABLE, M_NOWAIT);
- if (rw->w_tmem)
- rw->w_tmemsize = len;
+ w->w_needed += len;
+ if (w->w_needed <= 0 && w->w_where) {
+ if (w->w_tmemsize < len) {
+ free(w->w_tmem, M_RTABLE, w->w_tmemsize);
+ w->w_tmem = malloc(len, M_RTABLE, M_NOWAIT);
+ if (w->w_tmem)
+ w->w_tmemsize = len;
}
- if (rw->w_tmem) {
- cp = rw->w_tmem;
+ if (w->w_tmem) {
+ cp = w->w_tmem;
second_time = 1;
goto again;
} else
- rw->w_where = 0;
+ w->w_where = 0;
}
}
if (cp && w)/* clear the message header */
@@ -1809,7 +1808,7 @@ sysctl_rtable(int *name, u_int namelen,
NET_UNLOCK();
break;
}
- free(w.w_tmem, M_RTABLE, 0);
+ free(w.w_tmem, M_RTABLE, w.w_tmemsize);
w.w_needed += w.w_given;
if (where) {
*given = w.w_where - (caddr_t)where;
Regards,
kshe
vi(1): cscope leftover
Hi,
Support for cscope connections was removed from vi(1) a few years ago.
Index: ex/ex_cmd.c
===
RCS file: /cvs/src/usr.bin/vi/ex/ex_cmd.c,v
retrieving revision 1.10
diff -u -p -r1.10 ex_cmd.c
--- ex/ex_cmd.c 19 Nov 2015 07:53:31 - 1.10
+++ ex/ex_cmd.c 14 Dec 2017 16:07:48 -
@@ -145,8 +145,8 @@ EXCMDLIST const cmds[] = {
/* C_DISPLAY */
{"display", ex_display, 0,
"w1r",
- "display b[uffers] | c[onnections] | s[creens] | t[ags]",
- "display buffers, connections, screens or tags"},
+ "display b[uffers] | s[creens] | t[ags]",
+ "display buffers, screens or tags"},
/* C_EDIT */
{"edit",ex_edit,E_NEWSCREEN,
"f1o",
@@ -427,6 +427,6 @@ EXCMDLIST const cmds[] = {
{"~", ex_subtilde,E_ADDR2,
"s",
"[line [,line]] ~ [cgr] [count] [#lp]",
- "replace previous RE with previous replacement string,"},
+ "replace previous RE with previous replacement string"},
{NULL},
};
Regards,
kshe
Enforce limits in regulator framework
The regulators defined in the FDT typically have limits associated
with them. The diff below enforces those limits.
Enforcing the limits also happens when the regulator is registered.
As a consequence regulators will be properly initialized even when the
firmware (i.e. U-Boot) doesn't do that.
ok?
Index: dev/ofw/ofw_regulator.c
===
RCS file: /cvs/src/sys/dev/ofw/ofw_regulator.c,v
retrieving revision 1.2
diff -u -p -r1.2 ofw_regulator.c
--- dev/ofw/ofw_regulator.c 18 Nov 2017 13:48:50 - 1.2
+++ dev/ofw/ofw_regulator.c 16 Dec 2017 16:37:46 -
@@ -30,6 +30,18 @@ LIST_HEAD(, regulator_device) regulator_
void
regulator_register(struct regulator_device *rd)
{
+ rd->rd_min = OF_getpropint(rd->rd_node, "regulator-min-microvolt", 0);
+ rd->rd_max = OF_getpropint(rd->rd_node, "regulator-max-microvolt", ~0);
+ KASSERT(rd->rd_min <= rd->rd_max);
+
+ if (rd->rd_get_voltage && rd->rd_set_voltage) {
+ uint32_t voltage = rd->rd_get_voltage(rd->rd_cookie);
+ if (voltage < rd->rd_min)
+ rd->rd_set_voltage(rd->rd_cookie, rd->rd_min);
+ if (voltage > rd->rd_max)
+ rd->rd_set_voltage(rd->rd_cookie, rd->rd_max);
+ }
+
rd->rd_phandle = OF_getpropint(rd->rd_node, "phandle", 0);
if (rd->rd_phandle == 0)
return;
@@ -127,8 +139,12 @@ regulator_set_voltage(uint32_t phandle,
break;
}
+ /* Check limits. */
+ if (rd && (voltage < rd->rd_min || voltage > rd->rd_max))
+ return EINVAL;
+
if (rd && rd->rd_set_voltage)
return rd->rd_set_voltage(rd->rd_cookie, voltage);
- return -1;
+ return ENODEV;
}
Index: dev/ofw/ofw_regulator.h
===
RCS file: /cvs/src/sys/dev/ofw/ofw_regulator.h,v
retrieving revision 1.3
diff -u -p -r1.3 ofw_regulator.h
--- dev/ofw/ofw_regulator.h 18 Nov 2017 21:03:23 - 1.3
+++ dev/ofw/ofw_regulator.h 16 Dec 2017 16:37:46 -
@@ -24,6 +24,8 @@ struct regulator_device {
uint32_t (*rd_get_voltage)(void *);
int (*rd_set_voltage)(void *, uint32_t);
+ uint32_t rd_min, rd_max;
+
LIST_ENTRY(regulator_device) rd_list;
uint32_t rd_phandle;
};
ksh: make home & end keys work out-of-the-box in the console
Tested with vt220 and wsvt25. Hopefully we're close to exhausting
all the different ways to encode these keys by now.
diff --git bin/ksh/emacs.c bin/ksh/emacs.c
index 07bfbd914..4291ce656 100644
--- bin/ksh/emacs.c
+++ bin/ksh/emacs.c
@@ -1536,6 +1536,8 @@ x_init_emacs(void)
kb_add(x_mv_end,NULL, CTRL('['), 'O', 'F', 0); /* end */
kb_add(x_mv_begin, NULL, CTRL('['), '[', '1', '~', 0); /*
home */
kb_add(x_mv_end,NULL, CTRL('['), '[', '4', '~', 0); /*
end */
+ kb_add(x_mv_begin, NULL, CTRL('['), '[', '7', '~', 0); /*
home */
+ kb_add(x_mv_end,NULL, CTRL('['), '[', '8', '~', 0); /*
end */
/* can't be bound */
kb_add(x_set_arg, NULL, CTRL('['), '0', 0);
iwn(4) 4965 background scan workarounds
FreeBSD committed two workarounds for firmware problems during
background scans on iwn(4) 4965 devices in this revision:
r222679 | bschmidt | 2011-06-04 13:43:09 +0200 (Sat, 04 Jun 2011) | 15 lines
The firmware of 4965 series adapters seems to die while trying to send
probe requests at 1Mbps while being associated on a 5GHz channel. Sending
those at 6Mbps does work, so use that instead during a background scan.
This workaround allows us to re-enable background scan support for the
4965 adapters.
Also, just enabling one antenna on 5GHz results in better reception of
beacons:
test00:26:5a:c6:14:1a 40 54M -71:-95 200 EWME HTCAP ATH
vs
test00:26:5a:c6:14:1a 40 54M -92:-95 200 EWME HTCAP ATH
Due to roam:rssi thresholds set to 7 by default it might have been
impossible to associate to that network. While here use
IEEE80211_IS_CHAN_5GHZ() to determine the band.
The diff below ports these fixes to our tree.
Unfortunately I do not have 4965 hardware so I cannot test this myself.
Can someone confirm the SYSASSSERT and/or RSSI problem and verify that
this diff helps?
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.196
diff -u -p -r1.196 if_iwn.c
--- if_iwn.c14 Dec 2017 20:12:32 - 1.196
+++ if_iwn.c15 Dec 2017 20:00:02 -
@@ -4742,7 +4742,7 @@ iwn_scan(struct iwn_softc *sc, uint16_t
if ((flags & IEEE80211_CHAN_5GHZ) &&
sc->hw_type == IWN_HW_REV_TYPE_4965) {
/* Ant A must be avoided in 5GHz because of an HW bug. */
- rxchain |= IWN_RXCHAIN_FORCE_SEL(IWN_ANT_BC);
+ rxchain |= IWN_RXCHAIN_FORCE_SEL(IWN_ANT_B);
} else /* Use all available RX antennas. */
rxchain |= IWN_RXCHAIN_FORCE_SEL(sc->rxchainmask);
hdr->rxchain = htole16(rxchain);
@@ -4759,9 +4759,18 @@ iwn_scan(struct iwn_softc *sc, uint16_t
rs = &ic->ic_sup_rates[IEEE80211_MODE_11A];
} else {
hdr->flags = htole32(IWN_RXON_24GHZ | IWN_RXON_AUTO);
- /* Send probe requests at 1Mbps. */
- tx->plcp = iwn_rates[IWN_RIDX_CCK1].plcp;
- tx->rflags = IWN_RFLAG_CCK;
+ if (bgscan && sc->hw_type == IWN_HW_REV_TYPE_4965 &&
+ sc->rxon.chan > 14) {
+ /*
+* Send probe requests at 6Mbps to work
+* around a firmware SYSASSERT.
+*/
+ tx->plcp = iwn_rates[IWN_RIDX_OFDM6].plcp;
+ } else {
+ /* Send probe requests at 1Mbps. */
+ tx->plcp = iwn_rates[IWN_RIDX_CCK1].plcp;
+ tx->rflags = IWN_RFLAG_CCK;
+ }
rs = &ic->ic_sup_rates[IEEE80211_MODE_11G];
}
/* Use the first valid TX antenna. */
Re: sunxi RSB implementation
On Fri, Dec 15, 2017 at 10:58:22PM +0100, Mark Kettenis wrote:
> Some of the Allwinner SoCs have a so-called Reduces Serial Bus that is
> used to communicate with peripheral chips (mostly power management
> ICs). The diff below adds a driver for the RSB conntroller, named
> sxirsb(4), and a driver for the RTC component of the X-Powers AC100
> audio codec. I deliberately cose not to abstract the RSB bus itself
> as that is a unecessary as long as we only have a single RSB
> controller implementation. But the code is written such that this can
> be easily changed if the need arises. Shows up in dmesg as:
>
> sxirsb0 at simplebus0
> "x-powers,axp809" at sxirsb0 addr 0x3a3 not configured
> "x-powers,axp806" at sxirsb0 addr 0x745 not configured
> acrtc0 at sxirsb0 addr 0xe89
>
> The sxirsb(4) driver attaches early since its children are often used
> for power management.
>
> ok?
>
Looks better than what i've had in my branches,
as faking i2c-controller turned out to be messy.
Besides my personal preference not to mention/compare to linux even in
comments , only change i came up w/reading the diff was the obvious typo
in the name Reduces=Reduced.
-Artturi
>
> Index: arch/armv7/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
> retrieving revision 1.99
> diff -u -p -r1.99 GENERIC
> --- arch/armv7/conf/GENERIC 24 Oct 2017 17:00:34 - 1.99
> +++ arch/armv7/conf/GENERIC 15 Dec 2017 21:53:54 -
> @@ -91,6 +91,8 @@ sxipio* at fdt? early 1 # GPIO pins fo
> gpio*at sxipio?
> sxiccmu* at fdt? early 1 # Clock Control Module/Unit
> sxitimer*at fdt? early 1
> +sxirsb* at fdt? early 1 # Reduces Serial Bus
typo here ^
> +acrtc* at sxirsb?
> sxidog* at fdt? # watchdog timer
> sxirtc* at fdt? # Real Time Clock
> sxie*at fdt?
> Index: arch/armv7/conf/RAMDISK
> ===
> RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v
> retrieving revision 1.92
> diff -u -p -r1.92 RAMDISK
> --- arch/armv7/conf/RAMDISK 24 Oct 2017 17:00:34 - 1.92
> +++ arch/armv7/conf/RAMDISK 15 Dec 2017 21:53:54 -
> @@ -87,6 +87,8 @@ sxipio* at fdt? early 1 # GPIO pins fo
> gpio*at sxipio?
> sxiccmu* at fdt? early 1 # Clock Control Module/Unit
> sxitimer*at fdt? early 1
> +sxirsb* at fdt? early 1 # Reduces Serial Bus
typo here ^
> +acrtc* at sxirsb?
> sxidog* at fdt? # watchdog timer
> sxirtc* at fdt? # Real Time Clock
> sxie*at fdt?
> Index: dev/fdt/acrtc.c
> ===
> RCS file: dev/fdt/acrtc.c
> diff -N dev/fdt/acrtc.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ dev/fdt/acrtc.c 15 Dec 2017 21:53:55 -
> @@ -0,0 +1,186 @@
> +/* $OpenBSD$ */
> +/*
> + * Copyright (c) 2017 Mark Kettenis
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +
> +#include
> +
> +#define isleap(y) y) % 4) == 0 && ((y) % 100) != 0) || ((y) % 400) == 0)
> +
> +extern todr_chip_handle_t todr_handle;
> +
> +#define RTC_CTRL 0xc7
> +#define RTC_CTRL_12H_24H_MODE (1 << 0)
> +#define RTC_SEC 0xc8
> +#define RTC_MIN 0xc9
> +#define RTC_HOU 0xca
> +#define RTC_WEE 0xcb
> +#define RTC_DAY 0xcc
> +#define RTC_MON 0xcd
> +#define RTC_YEA 0xce
> +#define RTC_YEA_LEAP_YEAR (1 << 15)
> +#define RTC_UPD_TRIG 0xcf
> +#define RTC_UPD_TRIG_UPDATE (1 << 15)
> +
> +struct acrtc_softc {
> + struct device sc_dev;
> + void*sc_cookie;
> + uint16_tsc_rta;
> +
> + struct todr_chip_handle sc_todr;
> +};
> +
> +int
Re: csh: NULL checks before free()
On Fri, Dec 15, 2017 at 05:03:40PM +0800, Michael W. Bombardieri wrote: > Hello, > > Previously in csh(1) the xfree() function was removed in favour > of regular free(). This patch removes a couple of NULL checks > before free(). Committed, thanks!
DragonFly BSD fingerprint
Hello, Attached patch adds the fingerprints for DragonFly to pf.os. From http://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/947927fb129de774317974bc923ca1ade3d4cc60:/etc/pf.os Sevan Index: etc/pf.os === RCS file: /cvs/src/etc/pf.os,v retrieving revision 1.27 diff -u -p -r1.27 pf.os --- etc/pf.os 3 Sep 2016 17:08:57 - 1.27 +++ etc/pf.os 16 Dec 2017 07:45:09 - @@ -317,6 +317,14 @@ S22:64:1:52:M*,N,N,S,N,W0: Linux:2.2:ts: 16384:64:1:64:M*,N,N,S,N,W6,N,N,T: OpenBSD:6.1::OpenBSD 6.1 16384:64:0:64:M*,N,N,S,N,W6,N,N,T: OpenBSD:6.1:no-df:OpenBSD 6.1 (scrub no-df) +# - DragonFly BSD - + +57344:64:1:60:M*,N,W0,N,N,T: DragonFly:1.0:A:DragonFly 1.0A +57344:64:0:64:M*,N,W0,N,N,S,N,N,T: DragonFly:1.2-1.12::DragonFly 1.2-1.12 +5840:64:1:60:M*,S,T,N,W4: DragonFly:2.0-2.1::DragonFly 2.0-2.1 +57344:64:0:64:M*,N,W0,N,N,S,N,N,T: DragonFly:2.2-2.3::DragonFly 2.2-2.3 +57344:64:0:64:M*,N,W5,N,N,S,N,N,T: DragonFly:2.4-2.7::DragonFly 2.4-2.7 + # - Solaris - S17:64:1:64:N,W3,N,N,T0,N,N,S,M*: Solaris:8:RFC1323:Solaris 8 RFC1323
Re: Add "-c command" option to script(1)
On Fri, Dec 15, 2017 at 12:24:45PM +0100, Paul de Weerd wrote:
| I've updated the diff to add this example as per jmc's suggestion. It
| now has:
|
| - add the `-c command` feature
| - updates usage
| - removes /* ARGSUSED */ lint comments
| - documents the -c feature
| - adds an example to the manpage
jmc@ pointed out a missing colon at the end of the example. Apologies
for the extra noise. Updated diff (still covers the above five
changes) included.
Cheers,
Paul
Index: script.1
===
RCS file: /cvs/src/usr.bin/script/script.1,v
retrieving revision 1.14
diff -u -p -r1.14 script.1
--- script.115 Jan 2012 20:06:40 - 1.14
+++ script.116 Dec 2017 08:42:24 -
@@ -39,6 +39,7 @@
.Sh SYNOPSIS
.Nm script
.Op Fl a
+.Op Fl c Ar command
.Op Ar file
.Sh DESCRIPTION
.Nm
@@ -65,9 +66,14 @@ Append the output to
or
.Pa typescript ,
retaining the prior contents.
+.It Fl c Ar command
+Run
+.Ar command
+instead of an interactive shell.
+To run a command with arguments, enclose both in quotes.
.El
.Pp
-The script ends when the forked shell exits (a control-D
+The script ends when the forked program exits (a control-D
.Pq Ql ^D
to exit
the Bourne shell
@@ -102,6 +108,11 @@ Name of the shell to be forked by
If not set, the Bourne shell is assumed.
(Most shells set this variable automatically.)
.El
+.Sh EXAMPLES
+Start a virtual machine and log all console output to a file:
+.Bd -literal -offset indent
+$ script -c "vmctl start myvm -c" myvm.typescript
+.Ed
.Sh HISTORY
A predecessor called
.Nm dribble
Index: script.c
===
RCS file: /cvs/src/usr.bin/script/script.c,v
retrieving revision 1.33
diff -u -p -r1.33 script.c
--- script.c12 Apr 2017 14:49:05 - 1.33
+++ script.c14 Dec 2017 07:34:10 -
@@ -89,7 +89,7 @@ int istty;
__dead void done(int);
void dooutput(void);
-void doshell(void);
+void doshell(char *);
void fail(void);
void finish(int);
void scriptflush(int);
@@ -102,17 +102,23 @@ main(int argc, char *argv[])
struct sigaction sa;
struct winsize win;
char ibuf[BUFSIZ];
+ char *cmd;
ssize_t cc, off;
int aflg, ch;
+ cmd = NULL;
aflg = 0;
- while ((ch = getopt(argc, argv, "a")) != -1)
+ while ((ch = getopt(argc, argv, "ac:")) != -1)
switch(ch) {
case 'a':
aflg = 1;
break;
+ case 'c':
+ cmd = optarg;
+ break;
default:
- fprintf(stderr, "usage: %s [-a] [file]\n", __progname);
+ fprintf(stderr, "usage: %s [-a] [-c command] [file]\n",
+ __progname);
exit(1);
}
argc -= optind;
@@ -163,7 +169,7 @@ main(int argc, char *argv[])
if (child)
dooutput();
else
- doshell();
+ doshell(cmd);
}
bzero(&sa, sizeof sa);
@@ -196,7 +202,6 @@ main(int argc, char *argv[])
done(sigdeadstatus);
}
-/* ARGSUSED */
void
finish(int signo)
{
@@ -215,7 +220,6 @@ finish(int signo)
errno = save_errno;
}
-/* ARGSUSED */
void
handlesigwinch(int signo)
{
@@ -294,7 +298,6 @@ dooutput(void)
done(0);
}
-/* ARGSUSED */
void
scriptflush(int signo)
{
@@ -302,9 +305,10 @@ scriptflush(int signo)
}
void
-doshell(void)
+doshell(char *cmd)
{
char *shell;
+ char *argp[] = {"sh", "-c", NULL, NULL};
shell = getenv("SHELL");
if (shell == NULL)
@@ -313,8 +317,15 @@ doshell(void)
(void)close(master);
(void)fclose(fscript);
login_tty(slave);
- execl(shell, shell, "-i", (char *)NULL);
- warn("%s", shell);
+
+ if (cmd != NULL) {
+ argp[2] = cmd;
+ execv(_PATH_BSHELL, argp);
+ warn("unable to execute %s", _PATH_BSHELL);
+ } else {
+ execl(shell, shell, "-i", (char *)NULL);
+ warn("%s", shell);
+ }
fail();
}
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
