Re: [WIP FAQ13] New section for webcam usage
On Sun, Sep 06, 2020 at 07:45:32PM +0200, Stefan Hagen wrote: Hello Stefan, Thanks for this! I'll leave others who are more familiar with the website guidelines to comment on your patch, but I hope something like it can go in, as I found it a bit difficult at first to work out how to use webcams under OpenBSD. I have one tangential comment: > Using a webcam as user > > To use the webcam as regular user, you need to change the device > permissions. This made me wonder if uvideo should have an equivalent sysctl to audio (i.e. kern.audio.record)? Most, but I'm not sure all, webcams do display a light to tell you they're recording, but I can see that there is a security concern here. Laurie
Re: pms(4): fix "pointer skipping" for certain v1 elantech touchpads
Bump. Anyone?
Also sorry for the malformed message, I always default to 80 characters
and forgot that this won't do it here. Here's a more readable version:
On 2020-09-02 17:43, sxv...@firemail.cc wrote:
So, continuing with fixing my netbook, I have another patch which
fixes "pointer skipping". This is a bug in 2 particular (0x20022 and
0x20600) elantech v1 firmwares which causes at least the first packet
(in my tests, only one packet was mangled, but Linux says two and I
don't have a way to test it with 0x20600 FW, so I'm just dropping two
packets, since it doesn't change anything for my FW) to state the
last position and not the current one, thus jumping the cursor
somewhere else.
I'm not really sure about the counter variable, can it be like this
or should it get moved to the softc struct or even somewhere else?
Index: pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.94
diff -u -p -u -p -r1.94 pms.c
--- pms.c 10 Aug 2020 21:55:59 - 1.94
+++ pms.c 8 Sep 2020 14:32:10 -
@@ -2425,8 +2425,27 @@ void
pms_proc_elantech_v1(struct pms_softc *sc)
{
struct elantech_softc *elantech = sc->elantech;
+ static int single_touch_pkt = 0;
int x, y, w, z;
u_int buttons;
+
+ /*
+* Firmwares 0x20022 and 0x20600 have a bug, which makes the first 2
+* position reports mangled, which in turns causes cursor skipping.
+*/
+
+ if (elantech->fw_version == 0x20022 ||
+ elantech->fw_version == 0x20600) {
+ if((sc->packet[0] & 0xc0) >> 6)
+ {
+ if(single_touch_pkt < 2)
+ {
+ single_touch_pkt++;
+ return;
+ }
+ } else
+ single_touch_pkt = 0;
+ }
buttons = butmap[sc->packet[0] & 3];
Re: [WIP FAQ13] New section for webcam usage
Laurence Tratt wrote: > On Sun, Sep 06, 2020 at 07:45:32PM +0200, Stefan Hagen wrote: > I have one tangential comment: > > > Using a webcam as user > > > > To use the webcam as regular user, you need to change the device > > permissions. > > This made me wonder if uvideo should have an equivalent sysctl to audio (i.e. > kern.audio.record)? Most, but I'm not sure all, webcams do display a light to > tell you they're recording, but I can see that there is a security concern > here. An audio device is special in a way that it has playback and recording capabilities in one device. The sysctl is used to allow playback (by default) but not allow recording. Video (as in webcam) is always a recording device, which shouldn't be allowed to access in a default install (in contrast to audio playback). I find the "video" group solution clean and sufficient. I'll send a patch for it, once I've figured out how MAKEDEV works. I say "sufficient", because I believe the best solution would be something like sndiod (vidiod?) that acts as multiplexer and allows multiple applications to access the video stream simultaneously. Best Regards, Stefan
Re: snmpd refactor listen on grammar
On Sun, Sep 06, 2020 at 10:11:02PM +0200, Martijn van Duren wrote:
> Moving towards individual transport mappings, it's becoming more
> convenient to have the protocol directly after the listen on statement.
> This gives me more flexibility in using mapping-specific APIs, also
> when other transport mappings might become available in the future it
> allows for easier mapping-specific features.
>
> While here I decided to also add port support for snmpe, which at this
> point is rather trivial. Traphandler is not my point of focus at this
> time.
>
> having udp|tcp at the last position is still supported, but generates a
> pretty deprecated warning. Probably to be removed after release.
>
> OK?
>
OK denis@
Can you check that port > 0 ? Because it prints "snmpd.conf:7: invalid
address: ::1" which is not correct (though using 0 or -1 for port is a weird
idea).
> martijn@
>
> Index: parse.y
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v
> retrieving revision 1.60
> diff -u -p -r1.60 parse.y
> --- parse.y 6 Sep 2020 15:51:28 - 1.60
> +++ parse.y 6 Sep 2020 20:08:08 -
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -92,6 +93,7 @@ char*symget(const char *);
> struct snmpd *conf = NULL;
> static interrors = 0;
> static struct usmuser*user = NULL;
> +static char *snmpd_port = SNMPD_PORT;
>
> int host(const char *, const char *, int,
> struct sockaddr_storage *, int);
> @@ -122,11 +124,11 @@ typedef struct {
> %token SYSTEM CONTACT DESCR LOCATION NAME OBJECTID SERVICES RTFILTER
> %token READONLY READWRITE OCTETSTRING INTEGER COMMUNITY TRAP RECEIVER
> %token SECLEVEL NONE AUTH ENC USER AUTHKEY ENCKEY ERROR DISABLED
> -%token HANDLE DEFAULT SRCADDR TCP UDP PFADDRFILTER
> +%token HANDLE DEFAULT SRCADDR TCP UDP PFADDRFILTER PORT
> %token STRING
> %token NUMBER
> %type hostcmn
> -%type srcaddr
> +%type srcaddr port
> %type optwrite yesno seclevel proto
> %typeobjtype cmd
> %type oid hostoid trapoid
> @@ -193,28 +195,7 @@ yesno: STRING {
> }
> ;
>
> -main : LISTEN ON STRING proto{
> - struct sockaddr_storage ss[16];
> - int nhosts, i;
> -
> - nhosts = host($3, SNMPD_PORT, $4, ss, nitems(ss));
> - if (nhosts < 1) {
> - yyerror("invalid address: %s", $3);
> - free($3);
> - YYERROR;
> - }
> - if (nhosts > (int)nitems(ss))
> - log_warn("%s resolves to more than %zu hosts",
> - $3, nitems(ss));
> - free($3);
> -
> - for (i = 0; i < nhosts; i++) {
> - if (listen_add(&(ss[i]), $4) == -1) {
> - yyerror("calloc");
> - YYERROR;
> - }
> - }
> - }
> +main : LISTEN ON listenproto
> | READONLY COMMUNITY STRING {
> if (strlcpy(conf->sc_rdcommunity, $3,
> sizeof(conf->sc_rdcommunity)) >=
> @@ -295,6 +276,128 @@ main: LISTEN ON STRING proto{
> }
> ;
>
> +listenproto : UDP listen_udp
> + | TCP listen_tcp
> + | listen_empty
> +
> +listen_udp : STRING port {
> + struct sockaddr_storage ss[16];
> + int nhosts, i;
> +
> + nhosts = host($1, $2, SOCK_DGRAM, ss, nitems(ss));
> + if (nhosts < 1) {
> + yyerror("invalid address: %s", $1);
> + free($1);
> + if ($2 != snmpd_port)
> + free($2);
> + YYERROR;
> + }
> + if (nhosts > (int)nitems(ss))
> + log_warn("%s:%s resolves to more than %zu
> hosts",
> + $1, $2, nitems(ss));
> +
> + free($1);
> + if ($2 != snmpd_port)
> + free($2);
> + for (i = 0; i < nhosts; i++) {
> + if (listen_add(&(ss[i]), SOCK_DGRAM) == -1) {
> + yyerror("calloc");
> + YYERROR;
> +
Re: PATCH: Fix PCI Config Space union size on VMM
> Date: Mon, 7 Sep 2020 17:52:55 -0500
> From: Jordan Hargrave
Yes that would be better. The usage of __packed here is questionable,
but that is not your fault.
ok kettenis@
> Index: pci.h
> ===
> RCS file: /cvs/src/usr.sbin/vmd/pci.h,v
> retrieving revision 1.7
> diff -u -p -u -r1.7 pci.h
> --- pci.h 17 Sep 2017 23:07:56 - 1.7
> +++ pci.h 7 Sep 2020 22:48:09 -
> @@ -32,43 +32,44 @@ typedef int (*pci_iobar_fn_t)(int dir, u
> void *, uint8_t);
> typedef int (*pci_mmiobar_fn_t)(int dir, uint32_t ofs, uint32_t *data);
>
> -union pci_dev {
> - uint32_t pd_cfg_space[PCI_CONFIG_SPACE_SIZE / 4];
>
> - struct {
> - uint16_t pd_vid;
> - uint16_t pd_did;
> - uint16_t pd_cmd;
> - uint16_t pd_status;
> - uint8_t pd_rev;
> - uint8_t pd_prog_if;
> - uint8_t pd_subclass;
> - uint8_t pd_class;
> - uint8_t pd_cache_size;
> - uint8_t pd_lat_timer;
> - uint8_t pd_header_type;
> - uint8_t pd_bist;
> - uint32_t pd_bar[PCI_MAX_BARS];
> - uint32_t pd_cardbus_cis;
> - uint16_t pd_subsys_vid;
> - uint16_t pd_subsys_id;
> - uint32_t pd_exp_rom_addr;
> - uint8_t pd_cap;
> - uint32_t pd_reserved0 : 24;
> - uint32_t pd_reserved1;
> - uint8_t pd_irq;
> - uint8_t pd_int;
> - uint8_t pd_min_grant;
> - uint8_t pd_max_grant;
> +struct pci_dev {
> + union {
> + uint32_t pd_cfg_space[PCI_CONFIG_SPACE_SIZE / 4];
> + struct {
> + uint16_t pd_vid;
> + uint16_t pd_did;
> + uint16_t pd_cmd;
> + uint16_t pd_status;
> + uint8_t pd_rev;
> + uint8_t pd_prog_if;
> + uint8_t pd_subclass;
> + uint8_t pd_class;
> + uint8_t pd_cache_size;
> + uint8_t pd_lat_timer;
> + uint8_t pd_header_type;
> + uint8_t pd_bist;
> + uint32_t pd_bar[PCI_MAX_BARS];
> + uint32_t pd_cardbus_cis;
> + uint16_t pd_subsys_vid;
> + uint16_t pd_subsys_id;
> + uint32_t pd_exp_rom_addr;
> + uint8_t pd_cap;
> + uint32_t pd_reserved0 : 24;
> + uint32_t pd_reserved1;
> + uint8_t pd_irq;
> + uint8_t pd_int;
> + uint8_t pd_min_grant;
> + uint8_t pd_max_grant;
> + } __packed;
> + };
> + uint8_t pd_bar_ct;
> + pci_cs_fn_t pd_csfunc;
>
> - uint8_t pd_bar_ct;
> - pci_cs_fn_t pd_csfunc;
> -
> - uint8_t pd_bartype[PCI_MAX_BARS];
> - uint32_t pd_barsize[PCI_MAX_BARS];
> - void *pd_barfunc[PCI_MAX_BARS];
> - void *pd_bar_cookie[PCI_MAX_BARS];
> - } __packed;
> + uint8_t pd_bartype[PCI_MAX_BARS];
> + uint32_t pd_barsize[PCI_MAX_BARS];
> + void *pd_barfunc[PCI_MAX_BARS];
> + void *pd_bar_cookie[PCI_MAX_BARS];
> };
>
> struct pci {
> @@ -79,7 +80,7 @@ struct pci {
> uint32_t pci_addr_reg;
> uint32_t pci_data_reg;
>
> - union pci_dev pci_devices[PCI_CONFIG_MAX_DEV];
> + struct pci_dev pci_devices[PCI_CONFIG_MAX_DEV];
> };
>
> void pci_handle_address_reg(struct vm_run_params *);
>
>
Re: timeout(9): add clock-based timeouts (attempt 2)
> Date: Mon, 7 Sep 2020 18:50:44 -0500 > From: Scott Cheloha > > On Sat, Sep 05, 2020 at 01:11:59PM +0200, Mark Kettenis wrote: > > > Date: Fri, 4 Sep 2020 17:55:39 -0500 > > > From: Scott Cheloha > > > > > > On Sat, Jul 25, 2020 at 08:46:08PM -0500, Scott Cheloha wrote: > > > > > > > > [...] > > > > > > > > I want to add clock-based timeouts to the kernel because tick-based > > > > timeouts suffer from a few problems: > > > > > > > > [...] > > > > > > > > Basically, ticks are a poor approximation for the system clock. We > > > > should use the real thing where possible. > > > > > > > > [...] > > > > > > > > Thoughts on this approach? Thoughts on the proposed API? > > > > > > 6 week bump. > > > > > > Attached is an rebased and streamlined diff. > > > > > > Let's try again: > > > > > > This patch adds support for timeouts scheduled against the hardware > > > timecounter. I call these "kclock timeouts". They are distinct from > > > the current tick-based timeouts because ticks are "software time", not > > > "real time". > > > > So what's the end game here? Are these kclock-based timeouts going to > > replace the tick-based timeouts at some point in the future? I can > > see why you want to have both in parallel for a while, but long-term I > > don't think we want to keep both. > > Ideally we would replace tick-based timeouts entirely with kclock > timeouts eventually. > > There are a few roadblocks, though: > > 1. The scheduler is tick-based. If you want to wait until the next >tick, the easiest way to do that is with timeout_add(9) or tsleep(9). I don't think this really matters in most cases. Keeping the tick as the base for a scheduling quantum is probably wise for now, but I don't think it matters that timeouts and tsleeps (especially tsleeps) are actually synchronized to the scheduling clock. > 2. Linux has ktimers, which is tick-based. drm uses it. Shouldn't >we have a tick-based timeout interface for compatibility with them? >We could fake it, like FreeBSD does, but doing so is probably more >complicated than just keeping support for tick-based timeouts. You can easily emulate this using an absolute timer that you keep rescheduling. I think that is preferable to keeping a complete separate tick-based timeout system. > 3. Scheduling a timeout with timeout_add(9) is fast. Scheduling a >timeout with timeout_in_nsec(9) involves a clock read. It is slower. >It is probably too slow for some code. > > (1) will be overcome if ever the scheduler is no longer tick-based. > > (2) is tricky. Maybe you or jsg@ have an opinion? Not really. But I don't think the Linux ktimers tick at the same rate as ours so I don't think it matters. > (3) is somewhat easier to fix. I intend to introduce a TIMEOUT_COARSE > flag in the future which causes timeout_in_nsec() to call > getnanouptime(9) instead of nanouptime(9). Reading the timestamp is > faster than reading the clock. You lose accuracy, but any code > worried about the overhead of reading the clock is probably not very > concerned with accuracy. Right. > > We don't really want to do a wholesale conversion of APIs again I'd > > say. So at some point the existing timeout_add_xxx() calls should be > > implemented in terms of "kclock timeouts". > > We can do this, but we'll still need to change the calls that > reschedule a periodic timeout to use the dedicated rescheduling > interface. Otherwise those periodic timeouts will drift. They don't > currently drift because a tick is a very coarse unit of time. With > nanosecond resolution we'll get drift. Periodic timeouts are rare. At least those that care about drift. > > This implementation is still tick driven, so it doesn't really provide > > sub-tick resolution. > > Yes, that's right. Each timeout maintains nanosecond resolution for > its expiration time but will only actually run after hardclock(9) runs > and dumps the timeout to softclock(). > > We would need to implement a more flexible clock interrupt scheduler > to run timeouts in between hardclocks. > > > What does that mean for testing this? I mean if we spend a lot of time > > now to verify that subsystems can tolerate the more fine-grained timeouts, > > we need to that again when you switch from having a period interrupt driving > > the wheel to having a scheduled interrupt isn't it? > > Yes. But both changes can break things. > > I think we should do kclock timeouts before sub-tick timeouts. The > former is a lot less disruptive than the latter, as the timeouts still > run right after the hardclock. > > And you need kclock timeouts to even test sub-tick timeouts anyway. > > > > For now we have one kclock, KCLOCK_UPTIME, which corresponds to > > > nanouptime(9). In the future I intend to add support for runtime and > > > UTC kclocks. > > > > Do we really need that? I suppose it helps implementing something > > like clock_nanosleep() with the TIMER_ABSTIME flag for various >
Re: [PATCH] Adding group "video" for /dev/video*
Stefan Hagen wrote:
> Stefan Hagen wrote:
> > Using a webcam as user
> >
> >
> > To use the webcam as regular user, you need to change the device
> > permissions. Only root is allowed to access video devices by default.
> >
> >
> > One way of allowing your user to access the video devices is to change
> > the permissions from ~/.xsession. You can configure
> > https://man.openbsd.org/doas";>doas(1) to perform
> > https://man.openbsd.org/chmod";>chmod(1) as superuser
> > without asking for a password for your user.
> >
> >
> > Then add the following line to your ~/.xsession:
> >
> >
> > doas chown $USER /dev/video0
> >
>
> What do you think about adding a group "_video" to the default install
> and add /dev/video* devices to it with perm. 660. This would allow us
> to simply instruct users to add their user to group _video to give them
> access to video devices.
This patch changes MAKEDEV to generate /dev/video0..n with permission
660 and group "video". It also adds the group "video" with GID 46 to
/etc/groups.
OK?
Best Regards,
Stefan
Index: etc//MAKEDEV.common
===
RCS file: /cvs/src/etc/MAKEDEV.common,v
retrieving revision 1.111
diff -u -p -u -p -r1.111 MAKEDEV.common
--- etc//MAKEDEV.common 6 Jul 2020 06:11:26 - 1.111
+++ etc//MAKEDEV.common 8 Sep 2020 20:22:09 -
@@ -428,7 +428,7 @@ __devitem(au, audio*, Audio devices,audi
_mkdev(au, audio*, {-M audio$U c major_au_c $U 660 _sndiop
M audioctl$Uc major_au_c Add($U, 192) 660 _sndiop-})dnl
__devitem(vi, video*, Video V4L2 devices,video)dnl
-_mkdev(vi, video*, {-M video$U c major_vi_c $U 600
+_mkdev(vi, video*, {-M video$U c major_vi_c $U 660 video
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"-})dnl
__devitem(asc, asc*, ASC Audio device)dnl
_mkdev(asc, asc*, {-M asc$U major_asc_c 0-})dnl
Index: etc//group
===
RCS file: /cvs/src/etc/group,v
retrieving revision 1.94
diff -u -p -u -p -r1.94 group
--- etc//group 28 Jan 2020 16:51:03 - 1.94
+++ etc//group 8 Sep 2020 20:22:09 -
@@ -21,6 +21,7 @@ _fingerd:*:33:
_sshagnt:*:34:
_x11:*:35:
utmp:*:45:
+video:*:46:
_unwind:*:48:
_switchd:*:49:
_traceroute:*:50:
Index: etc//etc.alpha/MAKEDEV
===
RCS file: /cvs/src/etc/etc.alpha/MAKEDEV,v
retrieving revision 1.215
diff -u -p -u -p -r1.215 MAKEDEV
--- etc//etc.alpha/MAKEDEV 6 Jul 2020 06:12:37 - 1.215
+++ etc//etc.alpha/MAKEDEV 8 Sep 2020 20:22:09 -
@@ -260,7 +260,7 @@ vscsi*)
;;
video*)
- M video$U c 44 $U 600
+ M video$U c 44 $U 660 video
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"
;;
Index: etc//etc.amd64/MAKEDEV
===
RCS file: /cvs/src/etc/etc.amd64/MAKEDEV,v
retrieving revision 1.131
diff -u -p -u -p -r1.131 MAKEDEV
--- etc//etc.amd64/MAKEDEV 6 Jul 2020 06:12:37 - 1.131
+++ etc//etc.amd64/MAKEDEV 8 Sep 2020 20:22:09 -
@@ -272,7 +272,7 @@ vmm)
;;
video*)
- M video$U c 44 $U 600
+ M video$U c 44 $U 660 video
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"
;;
Index: etc//etc.arm64/MAKEDEV
===
RCS file: /cvs/src/etc/etc.arm64/MAKEDEV,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 MAKEDEV
--- etc//etc.arm64/MAKEDEV 6 Jul 2020 06:12:37 - 1.18
+++ etc//etc.arm64/MAKEDEV 8 Sep 2020 20:22:10 -
@@ -248,7 +248,7 @@ vscsi*)
;;
video*)
- M video$U c 44 $U 600
+ M video$U c 44 $U 660 video
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"
;;
Index: etc//etc.armv7/MAKEDEV
===
RCS file: /cvs/src/etc/etc.armv7/MAKEDEV,v
retrieving revision 1.35
diff -u -p -u -p -r1.35 MAKEDEV
--- etc//etc.armv7/MAKEDEV 6 Jul 2020 06:12:37 - 1.35
+++ etc//etc.armv7/MAKEDEV 8 Sep 2020 20:22:10 -
@@ -244,7 +244,7 @@ vscsi*)
;;
video*)
- M video$U c 38 $U 600
+ M video$U c 38 $U 660 video
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"
;;
Index: etc//etc.hppa/MAKEDEV
===
RCS file: /cvs/src/etc/etc.hppa/MAKEDEV,v
retrieving revision 1.154
diff -u -p -u -p -r1.154 MAKEDEV
--- etc//etc.hppa/MAKEDEV 6 Jul 2020 06:12:37 - 1.154
+++ etc//etc.hppa/MAKEDEV 8 Sep 2020 20:22:10 -
@@ -243,7 +243,7 @@ vscsi*)
;;
video*)
- M video$U c 33 $U 600
+ M video$U c 33 $U 660 video
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"
;;
Index: etc//etc.i386/MAKEDEV
==
Re: systat: pf: merge NOTES column into NAME
On Sat, Aug 29, 2020 at 05:13:00PM +0200, Klemens Nanni wrote:
> NOTES stays unused unless pf.conf(5) contains `set loginterface ...' in
> which case it merely amends what can otherwise be part of the NAME
> column.
>
> Merge the constant NOTES values for conditional counters into their NAME
> values to make the `pf' view look a little nicer and less empty by
> default; this also saves screen estate for possible future changes,
> e.g. we could increase column widths.
>
> Here's the difference on my workstation:
>
> $ systat -b pf
>
>0 users Load 0.44 0.42 0.44 (1-21 of 56)eru
> 16:59:13
> TYPE NAME VALUE RATE NOTES
> pf Status Enabled
> pf Since 475:09:16
> pf Debugerr
> pf Hostid0xc4490f26
>
> trunk0 Bytes In 9309436078IPv4
> trunk0 Bytes In 82089344KIPv6
> trunk0 Bytes Out 816675408IPv4
> trunk0 Bytes Out 5264003084IPv6
> trunk0 Packets In 8394222IPv4, Passed
> trunk0 Packets In 58044731IPv6, Passed
> trunk0 Packets In 16593IPv4, Blocked
> trunk0 Packets In 32233IPv6, Blocked
> trunk0 Packets Out 6001617IPv4, Passed
> trunk0 Packets Out 34333653IPv6, Passed
> trunk0 Packets Out 3625IPv4, Blocked
> trunk0 Packets Out 6277IPv6, Blocked
>
>state Count172
>state searches 191574598 112.00
>state inserts 474584 0.28
>
> $ ./obj/systat -b pf
>
>0 users Load 0.17 0.31 0.37 (1-21 of 56)eru
> 17:09:08
> TYPE NAME VALUE RATE
> pf Status Enabled
> pf Since 475:19:11
> pf Debug err
> pf Hostid 0xc4490f26
>
> trunk0 Bytes In IPv49311776112
> trunk0 Bytes In IPv6 82089531K
> trunk0 Bytes Out IPv4817474165
> trunk0 Bytes Out IPv6 5264003084
> trunk0 Packets In Passed IPv4 8398989
> trunk0 Packets In Passed IPv6 58045439
> trunk0 Packets In Blocked IPv4 16908
> trunk0 Packets In Blocked IPv6 32680
> trunk0 Packets Out Passed IPv4 6005423
> trunk0 Packets Out Passed IPv634333653
> trunk0 Packets Out Blocked IPv4 3625
> trunk0 Packets Out Blocked IPv6 6277
>
>state Count 105
>state searches 191584952 111.96
>state inserts 475839 0.28
>
>
> Feedback? OK?
Ping.
Index: pf.c
===
RCS file: /cvs/src/usr.bin/systat/pf.c,v
retrieving revision 1.12
diff -u -p -r1.12 pf.c
--- pf.c15 May 2020 00:56:03 - 1.12
+++ pf.c29 Aug 2020 15:08:54 -
@@ -54,18 +54,16 @@ field_def fields_pf[] = {
{"NAME", 12, 24, 1, FLD_ALIGN_LEFT, -1, 0, 0, 0},
{"VALUE", 8, 10, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
{"RATE", 8, 10, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 60},
- {"NOTES", 10, 20, 1, FLD_ALIGN_LEFT, -1, 0, 0, 60},
};
#define FLD_PF_TYPEFIELD_ADDR(fields_pf,0)
#define FLD_PF_NAMEFIELD_ADDR(fields_pf,1)
#define FLD_PF_VALUE FIELD_ADDR(fields_pf,2)
#define FLD_PF_RATEFIELD_ADDR(fields_pf,3)
-#define FLD_PF_DESCFIELD_ADDR(fields_pf,4)
/* Define views */
field_def *view_pf_0[] = {
- FLD_PF_TYPE, FLD_PF_NAME, FLD_PF_VALUE, FLD_PF_RATE, FLD_PF_DESC, NULL
+ FLD_PF_TYPE, FLD_PF_NAME, FLD_PF_VALUE, FLD_PF_RATE, NULL
};
@@ -187,19 +185,6 @@ print_fld_double(field_def *fld, double
return; \
} while (0)
-#define ADD_LINE_VD(t, n, v, d) \
- do {\
- if (cur >= dispstart && cur < end) {\
- print_fld_str(FLD_PF_TYPE, (t));\
- print_fld_str(FLD_PF_NAME, (n));\
- print_fld_size(FLD_PF_VALUE, (v)); \
- print_fld_str(FLD_PF_DESC, (d));\
- end_line(); \
- } \
- if (++cur >= end)
PATCH: Add helper vm_find_vcpu function to VMD
>From cba617464c71f4d4e4a34728f117ca92145f746f Mon Sep 17 00:00:00 2001
From: Jordan Hargrave
Date: Tue, 18 Aug 2020 15:46:36 -0500
Subject: [PATCH 1/4] Add helper vm_find_vcpu function for VMM
---
sys/arch/amd64/amd64/vmm.c | 63 --
1 file changed, 33 insertions(+), 30 deletions(-)
diff --git a/sys/arch/amd64/amd64/vmm.c b/sys/arch/amd64/amd64/vmm.c
index 84fcb23a5..f6d51737e 100644
--- a/sys/arch/amd64/amd64/vmm.c
+++ b/sys/arch/amd64/amd64/vmm.c
@@ -558,6 +558,34 @@ vmmclose(dev_t dev, int flag, int mode, struct proc *p)
return 0;
}
+/*
+ * vm_find_vcpu
+ *
+ * Lookup VMM VCPU by ID number
+ *
+ * Parameters:
+ * vm: vm structure
+ * id: index id of vcpu
+ *
+ * Returns pointer to vcpu structure if successful, NULL otherwise
+ */
+static struct vcpu *
+vm_find_vcpu(struct vm *vm, uint32_t id)
+{
+ struct vcpu *vcpu;
+
+ if (vm == NULL)
+ return NULL;
+ rw_enter_read(&vm->vm_vcpu_lock);
+ SLIST_FOREACH(vcpu, &vm->vm_vcpu_list, vc_vcpu_link) {
+ if (vcpu->vc_id == id)
+ break;
+ }
+ rw_exit_read(&vm->vm_vcpu_lock);
+ return vcpu;
+}
+
+
/*
* vm_resetcpu
*
@@ -591,12 +619,7 @@ vm_resetcpu(struct vm_resetcpu_params *vrp)
return (error);
}
- rw_enter_read(&vm->vm_vcpu_lock);
- SLIST_FOREACH(vcpu, &vm->vm_vcpu_list, vc_vcpu_link) {
- if (vcpu->vc_id == vrp->vrp_vcpu_id)
- break;
- }
- rw_exit_read(&vm->vm_vcpu_lock);
+ vcpu = vm_find_vcpu(vm, vrp->vrp_vcpu_id);
if (vcpu == NULL) {
DPRINTF("%s: vcpu id %u of vm %u not found\n", __func__,
@@ -657,12 +680,7 @@ vm_intr_pending(struct vm_intr_params *vip)
return (error);
}
- rw_enter_read(&vm->vm_vcpu_lock);
- SLIST_FOREACH(vcpu, &vm->vm_vcpu_list, vc_vcpu_link) {
- if (vcpu->vc_id == vip->vip_vcpu_id)
- break;
- }
- rw_exit_read(&vm->vm_vcpu_lock);
+ vcpu = vm_find_vcpu(vm, vip->vip_vcpu_id);
rw_exit_read(&vmm_softc->vm_lock);
if (vcpu == NULL)
@@ -722,12 +740,7 @@ vm_rwvmparams(struct vm_rwvmparams_params *vpp, int dir) {
return (error);
}
- rw_enter_read(&vm->vm_vcpu_lock);
- SLIST_FOREACH(vcpu, &vm->vm_vcpu_list, vc_vcpu_link) {
- if (vcpu->vc_id == vpp->vpp_vcpu_id)
- break;
- }
- rw_exit_read(&vm->vm_vcpu_lock);
+ vcpu = vm_find_vcpu(vm, vpp->vpp_vcpu_id);
rw_exit_read(&vmm_softc->vm_lock);
if (vcpu == NULL)
@@ -786,12 +799,7 @@ vm_rwregs(struct vm_rwregs_params *vrwp, int dir)
return (error);
}
- rw_enter_read(&vm->vm_vcpu_lock);
- SLIST_FOREACH(vcpu, &vm->vm_vcpu_list, vc_vcpu_link) {
- if (vcpu->vc_id == vrwp->vrwp_vcpu_id)
- break;
- }
- rw_exit_read(&vm->vm_vcpu_lock);
+ vcpu = vm_find_vcpu(vm, vrwp->vrwp_vcpu_id);
rw_exit_read(&vmm_softc->vm_lock);
if (vcpu == NULL)
@@ -858,12 +866,7 @@ vm_mprotect_ept(struct vm_mprotect_ept_params *vmep)
return (ret);
}
- rw_enter_read(&vm->vm_vcpu_lock);
- SLIST_FOREACH(vcpu, &vm->vm_vcpu_list, vc_vcpu_link) {
- if (vcpu->vc_id == vmep->vmep_vcpu_id)
- break;
- }
- rw_exit_read(&vm->vm_vcpu_lock);
+ vcpu = vm_find_vcpu(vm, vmep->vmep_vcpu_id);
if (vcpu == NULL) {
DPRINTF("%s: vcpu id %u of vm %u not found\n", __func__,
--
2.26.2
Re: [PATCH] Add IOMMU support for Intel VT-d and AMD-Vi
Made changes for the iommu_readq -> iommu_read_8 and also now dynamically
allocate
the hwdte for AMD IOMMU.
On Fri, Sep 04, 2020 at 09:17:18PM +0200, Mark Kettenis wrote:
> > Date: Fri, 4 Sep 2020 00:50:44 -0500
> > From: Jordan Hargrave
>
> A few hints below...
>
> > > > +
> > > > +/* Page Table Entry per domain */
> > > > +static struct ivhd_dte hwdte[65536] __aligned(PAGE_SIZE);
> > > > +
> > > > +/* Alias mapping */
> > > > +#define SID_INVALID 0x8000L
> > > > +static uint32_t sid_flag[65536];
> > >
> > > Can we avoid having these large arrays, or at least allocate them
> > > dynamically? That would also avoid the explicit alignment which is
> > > somewhat nasty since it affects the entire kernel.
> >
> > OK. But the hwdte does need the 2M area to be all contiguous but it is not
> > needed for DMAR/Intel. You *can* have up to 8 different device table
> > entries
> > though to split up the area.
>
> The appropriate interface to use in this context is
> bus_dmamem_alloc(9). You can specify alignment, and if you set nsegs
> to 1, you will get memory that is physicaly contiguous.
>
> To map the memory into kernel address space you'll need create a map
> using bus_dmamap_create(9) and map it using bus_dmamem_map(9). Then
> instead of using pmap_extract(9) you use bus_dmamap_load_raw(9) which
> then populates the physical addresses.
>
> Many of the drivers written by dlg@ define convenience functions to do
> all these steps, although interestingly enough he tends to use
> bus_dmamap_load(9) instead of bus_dmamap_load_raw(9) which is
> sub-optimal.
>
> > > > +
> > > > +struct domain_dev {
> > > > + int sid;
> > > > + int sec;
> > > > + int sub;
> > > > + TAILQ_ENTRY(domain_dev) link;
> > > > +};
> > > > +
> > > > +struct domain {
> > > > + struct iommu_softc *iommu;
> > > > + int did;
> > > > + int gaw;
> > > > + struct pte_entry*pte;
> > > > + paddr_t ptep;
> > > > + struct bus_dma_tag dmat;
> > > > + int flag;
> > > > +
> > > > + struct mutexexlck;
> > > > + charexname[32];
> > > > + struct extent *iovamap;
> > > > + TAILQ_HEAD(,domain_dev) devices;
> > > > + TAILQ_ENTRY(domain) link;
> > > > +};
> > > > +
> > > > +#define DOM_DEBUG 0x1
> > > > +#define DOM_NOMAP 0x2
> > > > +
> > > > +struct dmar_devlist {
> > > > + int type;
> > > > + int bus;
> > > > + int ndp;
> > > > + struct acpidmar_devpath *dp;
> > > > + TAILQ_ENTRY(dmar_devlist) link;
> > > > +};
> > > > +
> > > > +TAILQ_HEAD(devlist_head, dmar_devlist);
> > > > +
> > > > +struct ivhd_devlist {
> > > > + int start_id;
> > > > + int end_id;
> > > > + int cfg;
> > > > + TAILQ_ENTRY(ivhd_devlist) link;
> > > > +};
> > > > +
> > > > +struct rmrr_softc {
> > > > + TAILQ_ENTRY(rmrr_softc) link;
> > > > + struct devlist_head devices;
> > > > + int segment;
> > > > + uint64_tstart;
> > > > + uint64_tend;
> > > > +};
> > > > +
> > > > +struct atsr_softc {
> > > > + TAILQ_ENTRY(atsr_softc) link;
> > > > + struct devlist_head devices;
> > > > + int segment;
> > > > + int flags;
> > > > +};
> > > > +
> > > > +struct iommu_pic {
> > > > + struct pic pic;
> > > > + struct iommu_softc *iommu;
> > > > +};
> > > > +
> > > > +#define IOMMU_FLAGS_CATCHALL 0x1
> > > > +#define IOMMU_FLAGS_BAD0x2
> > > > +#define IOMMU_FLAGS_SUSPEND0x4
> > > > +
> > > > +struct iommu_softc {
> > > > + TAILQ_ENTRY(iommu_softc)link;
> > > > + struct devlist_head devices;
> > > > + int id;
> > > > + int flags;
> > > > + int segment;
> > > > +
> > > > + struct mutexreg_lock;
> > > > +
> > > > + bus_space_tag_t iot;
> > > > + bus_space_handle_t ioh;
> > > > +
> > > > + uint64_tcap;
> > > > + uint64_tecap;
> > > > + uint32_tgcmd;
> > > > +
> > > > + int mgaw;
> > > > + int agaw;
> > > > + int ndoms;
> > > > +
> > > > + struct root_entry *root;
> > > > + struct context_entry*ctx[256];
> > > > +
> > > > + void*intr;
> > > > + struct iommu_picpic;
> > > > + int
Re: snmpd refactor listen on grammar
On Tue, 2020-09-08 at 19:33 +0200, Denis Fondras wrote:
> On Sun, Sep 06, 2020 at 10:11:02PM +0200, Martijn van Duren wrote:
> > Moving towards individual transport mappings, it's becoming more
> > convenient to have the protocol directly after the listen on statement.
> > This gives me more flexibility in using mapping-specific APIs, also
> > when other transport mappings might become available in the future it
> > allows for easier mapping-specific features.
> >
> > While here I decided to also add port support for snmpe, which at this
> > point is rather trivial. Traphandler is not my point of focus at this
> > time.
> >
> > having udp|tcp at the last position is still supported, but generates a
> > pretty deprecated warning. Probably to be removed after release.
> >
> > OK?
> >
>
> OK denis@
>
> Can you check that port > 0 ? Because it prints "snmpd.conf:7: invalid
> address: ::1" which is not correct (though using 0 or -1 for port is a weird
> idea).
>
> > martijn@
> >
Sure
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v
retrieving revision 1.60
diff -u -p -r1.60 parse.y
--- parse.y 6 Sep 2020 15:51:28 - 1.60
+++ parse.y 9 Sep 2020 05:45:10 -
@@ -40,9 +40,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -92,6 +94,7 @@ char *symget(const char *);
struct snmpd *conf = NULL;
static int errors = 0;
static struct usmuser *user = NULL;
+static char*snmpd_port = SNMPD_PORT;
int host(const char *, const char *, int,
struct sockaddr_storage *, int);
@@ -122,11 +125,11 @@ typedef struct {
%token SYSTEM CONTACT DESCR LOCATION NAME OBJECTID SERVICES RTFILTER
%token READONLY READWRITE OCTETSTRING INTEGER COMMUNITY TRAP RECEIVER
%token SECLEVEL NONE AUTH ENC USER AUTHKEY ENCKEY ERROR DISABLED
-%token HANDLE DEFAULT SRCADDR TCP UDP PFADDRFILTER
+%token HANDLE DEFAULT SRCADDR TCP UDP PFADDRFILTER PORT
%token STRING
%token NUMBER
%typehostcmn
-%typesrcaddr
+%typesrcaddr port
%typeoptwrite yesno seclevel proto
%type objtype cmd
%type oid hostoid trapoid
@@ -193,28 +196,7 @@ yesno : STRING {
}
;
-main : LISTEN ON STRING proto{
- struct sockaddr_storage ss[16];
- int nhosts, i;
-
- nhosts = host($3, SNMPD_PORT, $4, ss, nitems(ss));
- if (nhosts < 1) {
- yyerror("invalid address: %s", $3);
- free($3);
- YYERROR;
- }
- if (nhosts > (int)nitems(ss))
- log_warn("%s resolves to more than %zu hosts",
- $3, nitems(ss));
- free($3);
-
- for (i = 0; i < nhosts; i++) {
- if (listen_add(&(ss[i]), $4) == -1) {
- yyerror("calloc");
- YYERROR;
- }
- }
- }
+main : LISTEN ON listenproto
| READONLY COMMUNITY STRING {
if (strlcpy(conf->sc_rdcommunity, $3,
sizeof(conf->sc_rdcommunity)) >=
@@ -295,6 +277,132 @@ main : LISTEN ON STRING proto{
}
;
+listenproto: UDP listen_udp
+ | TCP listen_tcp
+ | listen_empty
+
+listen_udp : STRING port {
+ struct sockaddr_storage ss[16];
+ int nhosts, i;
+
+ nhosts = host($1, $2, SOCK_DGRAM, ss, nitems(ss));
+ if (nhosts < 1) {
+ yyerror("invalid address: %s", $1);
+ free($1);
+ if ($2 != snmpd_port)
+ free($2);
+ YYERROR;
+ }
+ if (nhosts > (int)nitems(ss))
+ log_warn("%s:%s resolves to more than %zu
hosts",
+ $1, $2, nitems(ss));
+
+ free($1);
+ if ($2 != snmpd_port)
+ free($2);
+ for (i = 0; i < nhosts; i++) {
+ if (listen_add(&(ss[i]), SOCK_DGRAM) == -1) {
+ yyerror("calloc");
+ YYERROR;
+
issignal() w/o KERNEL_LOCK()
Per-process data structures needed to suspend the execution of threads
are since recently protected by the SCHED_LOCK(). So the KERNEL_LOCK()
dance inside issignal() is no longer necessary and can be removed, ok?
Note that CURSIG() is currently always called with the KERNEL_LOCK()
held so the code below is redundant.
This is a step towards getting signal handling out of ze big lock.
Index: kern/kern_sig.c
===
RCS file: /cvs/src/sys/kern/kern_sig.c,v
retrieving revision 1.260
diff -u -p -r1.260 kern_sig.c
--- kern/kern_sig.c 26 Aug 2020 03:16:53 - 1.260
+++ kern/kern_sig.c 8 Sep 2020 05:48:51 -
@@ -1203,11 +1203,7 @@ issignal(struct proc *p)
signum != SIGKILL) {
pr->ps_xsig = signum;
- if (dolock)
- KERNEL_LOCK();
single_thread_set(p, SINGLE_PTRACE, 0);
- if (dolock)
- KERNEL_UNLOCK();
if (dolock)
SCHED_LOCK(s);
@@ -1215,11 +1211,7 @@ issignal(struct proc *p)
if (dolock)
SCHED_UNLOCK(s);
- if (dolock)
- KERNEL_LOCK();
single_thread_clear(p, 0);
- if (dolock)
- KERNEL_UNLOCK();
/*
* If we are no longer being traced, or the parent
@@ -1484,6 +1476,22 @@ sigexit(struct proc *p, int signum)
}
exit1(p, 0, signum, EXIT_NORMAL);
/* NOTREACHED */
+}
+
+/*
+ * Return 1 if `sig', a given signal, is ignored or masked for `p', a given
+ * thread, and 0 otherwise.
+ */
+int
+sigismasked(struct proc *p, int sig)
+{
+ struct process *pr = p->p_p;
+
+ if ((pr->ps_sigacts->ps_sigignore & sigmask(sig)) ||
+ (p->p_sigmask & sigmask(sig)))
+ return 1;
+
+ return 0;
}
int nosuidcoredump = 1;
sigismasked()
Simple helper function to centralize the manipulation of `ps_sigignore'
and `p_sigmask' in kern/kern_sig.c and later on add the corresponding
asserts, ok?
Index: kern/kern_sig.c
===
RCS file: /cvs/src/sys/kern/kern_sig.c,v
retrieving revision 1.260
diff -u -p -r1.260 kern_sig.c
--- kern/kern_sig.c 26 Aug 2020 03:16:53 - 1.260
+++ kern/kern_sig.c 8 Sep 2020 05:46:25 -
@@ -1486,6 +1486,22 @@ sigexit(struct proc *p, int signum)
/* NOTREACHED */
}
+/*
+ * Return 1 if `sig', a given signal, is ignored or masked for `p', a given
+ * thread, and 0 otherwise.
+ */
+int
+sigismasked(struct proc *p, int sig)
+{
+ struct process *pr = p->p_p;
+
+ if ((pr->ps_sigacts->ps_sigignore & sigmask(sig)) ||
+ (p->p_sigmask & sigmask(sig)))
+ return 1;
+
+ return 0;
+}
+
int nosuidcoredump = 1;
struct coredump_iostate {
Index: kern/tty_pty.c
===
RCS file: /cvs/src/sys/kern/tty_pty.c,v
retrieving revision 1.103
diff -u -p -r1.103 tty_pty.c
--- kern/tty_pty.c 20 Jul 2020 14:34:16 - 1.103
+++ kern/tty_pty.c 8 Sep 2020 05:28:46 -
@@ -289,8 +289,7 @@ ptsread(dev_t dev, struct uio *uio, int
again:
if (pti->pt_flags & PF_REMOTE) {
while (isbackground(pr, tp)) {
- if ((pr->ps_sigacts->ps_sigignore & sigmask(SIGTTIN)) ||
- (p->p_sigmask & sigmask(SIGTTIN)) ||
+ if (sigismasked(p, SIGTTIN) ||
pr->ps_pgrp->pg_jobc == 0 ||
pr->ps_flags & PS_PPWAIT)
return (EIO);
Index: kern/tty.c
===
RCS file: /cvs/src/sys/kern/tty.c,v
retrieving revision 1.163
diff -u -p -r1.163 tty.c
--- kern/tty.c 22 Jul 2020 17:39:50 - 1.163
+++ kern/tty.c 8 Sep 2020 05:28:46 -
@@ -744,8 +744,7 @@ ttioctl(struct tty *tp, u_long cmd, cadd
case TIOCSWINSZ:
while (isbackground(pr, tp) &&
(pr->ps_flags & PS_PPWAIT) == 0 &&
- (pr->ps_sigacts->ps_sigignore & sigmask(SIGTTOU)) == 0 &&
- (p->p_sigmask & sigmask(SIGTTOU)) == 0) {
+ !sigismasked(p, SIGTTOU)) {
if (pr->ps_pgrp->pg_jobc == 0)
return (EIO);
pgsignal(pr->ps_pgrp, SIGTTOU, 1);
@@ -1498,8 +1497,7 @@ loop: lflag = tp->t_lflag;
* Hang process if it's in the background.
*/
if (isbackground(pr, tp)) {
- if ((pr->ps_sigacts->ps_sigignore & sigmask(SIGTTIN)) ||
- (p->p_sigmask & sigmask(SIGTTIN)) ||
+ if (sigismasked(p, SIGTTIN) ||
pr->ps_flags & PS_PPWAIT || pr->ps_pgrp->pg_jobc == 0) {
error = EIO;
goto out;
@@ -1749,8 +1747,7 @@ loop:
pr = p->p_p;
if (isbackground(pr, tp) &&
ISSET(tp->t_lflag, TOSTOP) && (pr->ps_flags & PS_PPWAIT) == 0 &&
- (pr->ps_sigacts->ps_sigignore & sigmask(SIGTTOU)) == 0 &&
- (p->p_sigmask & sigmask(SIGTTOU)) == 0) {
+ !sigismasked(p, SIGTTOU)) {
if (pr->ps_pgrp->pg_jobc == 0) {
error = EIO;
goto out;
Index: sys/signalvar.h
===
RCS file: /cvs/src/sys/sys/signalvar.h,v
retrieving revision 1.41
diff -u -p -r1.41 signalvar.h
--- sys/signalvar.h 10 May 2020 00:56:06 - 1.41
+++ sys/signalvar.h 8 Sep 2020 05:29:10 -
@@ -126,6 +126,7 @@ voidsiginit(struct process *);
void trapsignal(struct proc *p, int sig, u_long code, int type,
union sigval val);
void sigexit(struct proc *, int);
+intsigismasked(struct proc *, int);
intsigonstack(size_t);
void setsigvec(struct proc *, int, struct sigaction *);
intkillpg1(struct proc *, int, int, int);
KASSERT() for VOP_*
This is mostly the same diff that has been backed out months ago with the VOP_CLOSE() case fixed. VOP_CLOSE() can accept a NULL argument instead of `curproc' when garbage collecting passed FDs. The intent is to stop passing a "struct proc *" when a function applies only to `curproc'. Synchronization/locking primitives are obviously different if a CPU can modify the fields of any thread or only of the current one. Index: kern/vfs_vops.c === RCS file: /cvs/src/sys/kern/vfs_vops.c,v retrieving revision 1.28 diff -u -p -r1.28 vfs_vops.c --- kern/vfs_vops.c 8 Apr 2020 08:07:51 - 1.28 +++ kern/vfs_vops.c 27 Apr 2020 08:10:02 - @@ -145,6 +145,8 @@ VOP_OPEN(struct vnode *vp, int mode, str a.a_cred = cred; a.a_p = p; + KASSERT(p == curproc); + if (vp->v_op->vop_open == NULL) return (EOPNOTSUPP); @@ -164,6 +166,7 @@ VOP_CLOSE(struct vnode *vp, int fflag, s a.a_cred = cred; a.a_p = p; + KASSERT(p == NULL || p == curproc); ASSERT_VP_ISLOCKED(vp); if (vp->v_op->vop_close == NULL) @@ -184,6 +187,7 @@ VOP_ACCESS(struct vnode *vp, int mode, s a.a_cred = cred; a.a_p = p; + KASSERT(p == curproc); ASSERT_VP_ISLOCKED(vp); if (vp->v_op->vop_access == NULL) @@ -202,6 +206,7 @@ VOP_GETATTR(struct vnode *vp, struct vat a.a_cred = cred; a.a_p = p; + KASSERT(p == curproc); if (vp->v_op->vop_getattr == NULL) return (EOPNOTSUPP); @@ -219,6 +224,7 @@ VOP_SETATTR(struct vnode *vp, struct vat a.a_cred = cred; a.a_p = p; + KASSERT(p == curproc); ASSERT_VP_ISLOCKED(vp); if (vp->v_op->vop_setattr == NULL) @@ -282,6 +288,7 @@ VOP_IOCTL(struct vnode *vp, u_long comma a.a_cred = cred; a.a_p = p; + KASSERT(p == curproc); if (vp->v_op->vop_ioctl == NULL) return (EOPNOTSUPP); @@ -300,6 +307,7 @@ VOP_POLL(struct vnode *vp, int fflag, in a.a_events = events; a.a_p = p; + KASSERT(p == curproc); if (vp->v_op->vop_poll == NULL) return (EOPNOTSUPP); @@ -344,6 +352,7 @@ VOP_FSYNC(struct vnode *vp, struct ucred a.a_waitfor = waitfor; a.a_p = p; + KASSERT(p == curproc); ASSERT_VP_ISLOCKED(vp); if (vp->v_op->vop_fsync == NULL) @@ -565,6 +574,7 @@ VOP_INACTIVE(struct vnode *vp, struct pr a.a_vp = vp; a.a_p = p; + KASSERT(p == curproc); ASSERT_VP_ISLOCKED(vp); if (vp->v_op->vop_inactive == NULL) @@ -581,6 +591,7 @@ VOP_RECLAIM(struct vnode *vp, struct pro a.a_vp = vp; a.a_p = p; + KASSERT(p == curproc); if (vp->v_op->vop_reclaim == NULL) return (EOPNOTSUPP);
