Index: sys/net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.418
diff -u -p -r1.418 route.c
--- sys/net/route.c 26 Apr 2023 16:09:44 - 1.418
+++ sys/net/route.c 26 Apr 2023 23:00:02 -
@@
> On 27 Apr 2023, at 15:16, Alexander Bluhm wrote:
>
> On Wed, Apr 26, 2023 at 11:17:37PM +0300, Vitaliy Makkoveev wrote:
>> Route timers and route labels protected by corresponding mutexes. `ifa'
>> uses references counting for protection. No protection requir
On Thu, Apr 27, 2023 at 02:54:38PM +0200, Claudio Jeker wrote:
> On Thu, Apr 27, 2023 at 01:55:33PM +0300, Vitaliy Makkoveev wrote:
> > Now only direct netlock used for inet sockets protection. The unlocked
> > access to all other sockets is safe, but we could lost consistency f
Now only direct netlock used for inet sockets protection. The unlocked
access to all other sockets is safe, but we could lost consistency for a
little. Since the solock() used for sockets protection, make locking
path common and use it. Make it shared because this is read-only access
to sockets
> On 27 Apr 2023, at 15:40, Alexander Bluhm wrote:
>
> On Thu, Apr 27, 2023 at 03:22:10PM +0300, Vitaliy Makkoveev wrote:
>>> On 27 Apr 2023, at 15:16, Alexander Bluhm wrote:
>>>
>>> On Wed, Apr 26, 2023 at 11:17:37PM +0300, Vitaliy Makkoveev wrote
On Tue, Apr 25, 2023 at 11:44:34AM +0200, Alexander Bluhm wrote:
> Hi,
>
> Mutex arp_mtx protects the llinfo_arp la_... fields. So kernel
> lock is only needed for changing the route rt_flags.
>
> Of course there is a race between checking and setting rt_flags.
> But the other checks of the
> On 26 Apr 2023, at 15:30, Hrvoje Popovski wrote:
>
> On 26.4.2023. 12:15, Alexander Bluhm wrote:
>> On Wed, Apr 26, 2023 at 11:17:32AM +0200, Alexander Bluhm wrote:
>>> On Tue, Apr 25, 2023 at 11:57:09PM +0300, Vitaliy Makkoveev wrote:
>>>> On Tue, Apr 25,
Forgot to say, rt_timer_remove_all() and ifafree() could be moved out of
kernel lock too, but with next diff.
On Wed, Apr 19, 2023 at 05:03:00PM +0300, Vitaliy Makkoveev wrote:
> Index: sys/net/route.c
> ===
> RCS file: /cv
Index: sys/net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.416
diff -u -p -r1.416 route.c
--- sys/net/route.c 28 Jan 2023 10:17:16 - 1.416
+++ sys/net/route.c 19 Apr 2023 14:00:31 -
@@
It performs read-only access to netlock protected data.
Index: sys/net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.359
diff -u -p -r1.359 rtsock.c
--- sys/net/rtsock.c22 Jan 2023 12:05:44 -
As sysctl_ifnames(), it performs read-only access to netlock protected
data.
Index: sys/net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.359
diff -u -p -r1.359 rtsock.c
--- sys/net/rtsock.c22 Jan 2023
It seems rt_setsource() needs some attention, but sysctl_source() could
be called with shared netlock just now.
Index: sys/net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.359
diff -u -p -r1.359 rtsock.c
Also performs read-only access to netlock protected data.
Index: sys/net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.359
diff -u -p -r1.359 rtsock.c
--- sys/net/rtsock.c22 Jan 2023 12:05:44 -
We use netlock to protect `if_list' and `ifa_list' lists, and the `ifa'
dereference, so kernel lock within ifa_ifwithaddr() is wrong. We have no
problems, because we call ifadel()/ifafree() with kernel lock held, but
we should not rely on this.
So use netlock assertion within ifa_ifwithaddr()
It does read-olny access to tetlock protected data, so the radix tree
will not be modified during spd_table_walk() run.
The second spd_table_walk() call in PF_KEY layer can't be performed with
shared netlock, because pfkeyv2_policy_flush() modifies tree and the
following tdb_walk() requires
On Mon, Apr 03, 2023 at 02:12:45PM +0200, Alexander Bluhm wrote:
> Hi,
>
> The arp mbuf queue la_mq has its own mutex, la_hold_total uses
> atomic operations. So they don't need the global arp mutex.
>
> Pull them out of arp_mtx blocks to make clear what the scope of
> arp_mtx protection is.
>
On Mon, Feb 06, 2023 at 11:01:00AM +0100, Claudio Jeker wrote:
> On Sat, Feb 04, 2023 at 01:24:58AM +0300, Vitaliy Makkoveev wrote:
> > Hi,
> >
> > kevent(2) system call is ulocked more than year ago. Since select(2)
> > and pselect(2) are kqueue(2)/kevent(
> On 10 Feb 2023, at 17:53, Visa Hankala wrote:
>
> This makes log event filter MP-safe.
>
> OK?
>
ok mvs@
> Index: kern/subr_log.c
> ===
> RCS file: src/sys/kern/subr_log.c,v
> retrieving revision 1.75
> diff -u -p -r1.75
On Tue, Feb 07, 2023 at 02:29:13PM +0100, Claudio Jeker wrote:
> > I could be wrong, but membar_exit_before_atomic(9) between `p_sigmask'
> > assignment and atomic P_SIGSUSPEND flag setting should be enough for
> > that:
> >
> > p->p_oldmask = p->p_sigmask;
> > p->p_sigmask = newmask;
> >
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2021
diff -u -p -r1.2021 pcidevs
--- sys/dev/pci/pcidevs 7 Feb 2023 07:10:43 - 1.2021
+++ sys/dev/pci/pcidevs 11 Feb 2023 19:15:38
On Wed, Feb 08, 2023 at 12:47:23PM +0100, Claudio Jeker wrote:
> On Wed, Feb 08, 2023 at 12:40:50PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 8 Feb 2023 14:17:14 +0300
> > > From: Vitaliy Makkoveev
> > >
> > > On Tue, Feb 07, 2023 at 05
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2021
diff -u -p -r1.2021 pcidevs
--- sys/dev/pci/pcidevs 7 Feb 2023 07:10:43 - 1.2021
+++ sys/dev/pci/pcidevs 13 Feb 2023 10:06:56
On Mon, Feb 13, 2023 at 11:22:36AM +0100, Mark Kettenis wrote:
> > Date: Mon, 13 Feb 2023 13:08:54 +0300
> > From: Vitaliy Makkoveev
>
> What makes you think this is a PEX 8311? The data sheet I found has
> the PCI device ID down as 0x8311, althogh this can be cha
kit. Meanwhile
according "PEX8311AA Data Book" the default PID is 0x9056 as they used
for PLX 9056 PCI bridge. Since PEX 8311 is mostly bit to bit identical
to PLX 9056 this smells like true.
However, want to drop this diff. Sorry for noise.
> On Mon, Feb 13, 2023 at 01:08:54PM +0
Hi,
kevent(2) system call is ulocked more than year ago. Since select(2)
and pselect(2) are kqueue(2)/kevent(2) wrappers, it makes sense to
unlock them too. select(2) does the temporary kernel event queue
initialization for this call only and does queue scan with events
conversion between
On Thu, Feb 02, 2023 at 12:52:14PM +0100, Claudio Jeker wrote:
> In vlan_transmit the IFCAP_VLAN_HWTAGGING cases uses
> sc->sc_tag + (prio << EVL_PRIO_BITS)
> while the non IFCAP_VLAN_HWTAGGING cases uses
> sc->sc_tag | (prio << EVL_PRIO_BITS)
>
> Lets use the same logic in both cases. IMO
> On 30 Jan 2023, at 06:39, Visa Hankala wrote:
>
> Replace selwakeup() with KNOTE() in tun(4) and tap(4).
>
> This patch makes the tun(4) and tap(4) event filters MP-safe.
>
> This is similar to the change that just got committed to pppac(4)
> and pppx(4). However, tun(4) and tap(4) can be
On Tue, Feb 07, 2023 at 04:06:39PM +0100, Mark Kettenis wrote:
> > Date: Tue, 7 Feb 2023 14:29:13 +0100
> > From: Claudio Jeker
> >
> > On Mon, Feb 06, 2023 at 08:28:38PM +0300, Vitaliy Makkoveev wrote:
> > > On Mon, Feb 06, 2023 at 11:01:00AM +0100, Claudio Je
On Tue, Feb 07, 2023 at 05:42:40PM +0300, Vitaliy Makkoveev wrote:
>
> > > Otherwise, if you are concerning about serialized `p_sigmask' and
> > > P_SIGSUSPEND, dosigsuspend() should be left under kernel lock:
> > >
> > > if
> On 28 Apr 2023, at 15:57, Vitaliy Makkoveev wrote:
>
> On Fri, Apr 28, 2023 at 02:13:15PM +0200, Alexander Bluhm wrote:
>> After running stress test successfully with this diff, next day
>> machine crashed while compiling a new kernel. It is unclear whether
>>
n
this cpu could happen on any other. IPL_MPFLOOR has very high level and
I guess it was chosen mostly for insurance.
We do rt allocation and release in the sockets, ioctl and softnet
context, so I see no reason to disable interrupts with priority greater
than IPL_SOFTNET.
>
> On Thu, Apr 27, 2
On Fri, Apr 28, 2023 at 02:13:15PM +0200, Alexander Bluhm wrote:
> After running stress test successfully with this diff, next day
> machine crashed while compiling a new kernel. It is unclear whether
> it is related to the diff. The softdep in ps is problably processing
> make output via ssh.
> On 28 Apr 2023, at 15:38, Alexander Bluhm wrote:
>
> On Fri, Apr 28, 2023 at 02:51:23PM +0300, Vitaliy Makkoveev wrote:
>>> On 28 Apr 2023, at 14:03, Alexander Bluhm wrote:
>>>
>>> That basically means we must never call one of the pool get or put
>&
Ping.
> On 21 Apr 2023, at 17:17, Vitaliy Makkoveev wrote:
>
> At least network subset of sysctl(8) MIBs relies on netlock or another
> locks and doesn't require kernel lock. Also some integers in other
> subsets can be read without kernel lock held.
>
> Diff below actual
On Fri, Jul 07, 2023 at 11:48:13AM +0300, Alexander Bluhm wrote:
> Hi,
>
> When we preserve M_TCP_TSO we also must keep ph_mss. In lo(4)
> LRO/TSO this logic was missing. As this may be relevant only for
> weird pf configs that forward from loopback and ifconfig tcplro is
> disabled by default,
On Fri, Jul 07, 2023 at 12:31:02PM +0300, YASUOKA Masahiko wrote:
> Hi,
>
> I'd like to expand the counters in struct mbstat from u_short to u_long.
>
> When I was debugging a mbuf leak, I saw the result of "netstat -m"
> ---
> 28647 mbufs in use:
> 28551 mbufs allocated to data
>
This is a part of my standalone sblock() work. I need this movement
because buffers related SO_SND* and SO_RCV* socket options modification
should be protected with sblock(). However, standalone sblock() has
different lock orders with solock() for receive and send buffers. At
least sblock() for
> On 9 Jul 2023, at 15:15, Alexander Bluhm wrote:
>
> Hi,
>
> While testing my ART reference couting fix, I discovered a rtentry
> leak that is triggered by regress/sbin/route and detected with
> btrace(8) refcnt.
>
> The reference returned by rtalloc() must be freed with rtfree() in
> all
Use per 'wseventvar' structure `mtx' mutex(9) to protect `put' and `get'
circular buffer indexes together with klist data. Not a big deal, but
Xorg will not kernel lock while polling keyboard and mouse events. Also
removed obsolete selinfo.
Feedback, objections, oks?
Not related to this diff,
On Tue, Jul 04, 2023 at 03:26:30PM +1000, David Gwynne wrote:
> tl;dr: this adds sec(4) p2p ip interfaces. Traffic in and out of these
> interfaces is protected by IPsec security associations (SAs), but
> there's no flows (security policy database (SPD) entries) associated
> with these SAs. The
On Wed, May 17, 2023 at 01:02:58PM +0300, Vitaliy Makkoveev wrote:
> mrt_rtwalk_mfcsysctl() performs read-only access to protected data, so
> rtable_walk() could be called with shared netlock.
>
Regardless on sysctl(2) unlocking backout, the netlock around
mrt_sysctl_mfc() could b
On Fri, May 26, 2023 at 01:03:13PM +, Klemens Nanni wrote:
> snmpd(8) and 'pfctl -s Interfaces' dump pf's internal list of interfaces.
>
> pf.conf's 'set skip on ifN' and 'pfctl -F all|Reset' set and clear flags,
> PFI_IFLAG_SKIP being the only flag.
>
> (There's no other usage of these
On Fri, May 26, 2023 at 05:08:06PM +0200, Alexander Bluhm wrote:
> On Fri, May 26, 2023 at 05:29:58PM +0300, Vitaliy Makkoveev wrote:
> > On Wed, May 17, 2023 at 01:02:58PM +0300, Vitaliy Makkoveev wrote:
> > > mrt_rtwalk_mfcsysctl() performs read-only access to
On Wed, May 17, 2023 at 01:08:52PM +0300, Vitaliy Makkoveev wrote:
> Also read-only access to netlock protected data.
>
Regardless on sysctl(2) unlocking backout, the netlock around
mrt_sysctl_vif() could be relaxed to shared netlock.
> Index: sys/netinet/i
> On 6 Jun 2023, at 19:37, Chris Cappuccio wrote:
>
> Jan Klemkow [j.klem...@wemelug.de] wrote:
>> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote:
>>> On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote:
>>>> I would sugge
> On 6 Jun 2023, at 20:29, Alexander Bluhm wrote:
>
> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote:
>> On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote:
>>> Hi,
>>>
>>> I would suggest to rename ifconfig tcprecvofflo
On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote:
> Hi,
>
> I would suggest to rename ifconfig tcprecvoffload to tcplro. Maybe
> it's just because I had to type that long name too often.
>
> With that we have consistent naming:
> # ifconfig ix0 tcplro
> # sysctl
In this point, the interface is disconnected from everywhere. No need to
hold netlock for dummy 'nd_ifinfo' release. Netlock is also not needed
for TAILQ_EMPTY(>if_*hooks) assertions.
Index: sys/net/if.c
===
RCS file:
On Wed, Jun 07, 2023 at 01:29:09PM +0200, Alexander Bluhm wrote:
> On Wed, Jun 07, 2023 at 12:59:11PM +0300, Vitaliy Makkoveev wrote:
> > On Wed, Jun 07, 2023 at 10:19:32AM +1000, David Gwynne wrote:
> > >
> > >
> > > > On 7 Jun 2023, at 06:33, Vitaliy M
On Wed, Jun 07, 2023 at 10:19:32AM +1000, David Gwynne wrote:
>
>
> > On 7 Jun 2023, at 06:33, Vitaliy Makkoveev wrote:
> >
> >> On 6 Jun 2023, at 20:29, Alexander Bluhm wrote:
> >>
> >> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkove
In this point the interface is already removed from the list of all
interfaces and from the interface index map and all possible
concurrent ioctl() threads finished. Remove this dead code.
Index: sys/net/if.c
===
RCS file:
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > >
> > > schedule_
This is the culprit:
schedule_timeout_uninterruptible(long timeout)
{
tsleep(curproc, PWAIT, "schtou", timeout);
return 0;
}
On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > This is the culprit:
> >
> > schedule_timeout_uninterruptible(long timeout)
> > {
> > tsleep(curproc, PWAIT, "s
On Tue, Aug 01, 2023 at 11:24:01AM +0200, Claudio Jeker wrote:
> Now that the issue in inteldrm was resolved we can finally remove this
> old wakeup of the swapper.
>
> OK?
ok mvs
> --
> :wq Claudio
>
> Index: uvm_meter.c
> ===
>
On Thu, Jul 20, 2023 at 09:57:00PM +0200, Alexander Bluhm wrote:
> Hi,
>
> I wonder why UDP echo does not work with inetd on 127.0.0.1.
>
> Note that it is default off. One of my regress machines has it
> enabled for other tests. There perl dist/Net-Ping/t/510_ping_udp.t
> expects that UDP
It contains SS_CANTSENDMORE, SS_ISSENDING, SS_CANTRCVMORE and
SS_RCVATMARK bits. Also do `sb_flags' output as hex, it contains flags
too.
Index: sys/kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving
On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote:
> proc0 aka the swapper does not do anything. So there is no need to wake it
> up. Now the problem is that last time this was tried some inteldrm systems
> did hang during bootup because the drm code unexpectedly depended on this
>
On Fri, Jul 21, 2023 at 07:38:17PM +0200, Alexander Bluhm wrote:
> On Thu, Jul 13, 2023 at 02:22:17AM +0300, Vitaliy Makkoveev wrote:
> > This is a part of my standalone sblock() work. I need this movement
> > because buffers related SO_SND* and SO_RCV* socket options modifica
On Tue, Aug 08, 2023 at 10:40:46PM +0200, Alexander Bluhm wrote:
> On Fri, Aug 04, 2023 at 12:38:23AM +0300, Vitaliy Makkoveev wrote:
> > @@ -1856,6 +1856,9 @@ sosetopt(struct socket *so, int level, i
> > case SO_SNDLOWAT:
> >
The only difference is the socket buffer.
As bonus, in the future solock() will be easily replaced by sblock()
instead pushing it down to each SO_SND* and SO_RCV* case.
Index: sys/kern/uipc_socket.c
===
RCS file:
> On 22 Jun 2023, at 22:50, Alexander Bluhm wrote:
>
> Hi,
>
> I am working on a diff to run UDP input in parallel. Btrace kstack
> analysis shows that SIP hash for PCB lookup is quite expensive.
> When running in parallel we get lock contention on the PCB table
> mutex.
>
> So it results in
M_TEMP seems unreasonable for interface groups data allocations.
Don't forget to recompile systat(1) and vmstat(8) with new sys/malloc.h.
Index: sys/net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.700
diff -u -p
On Tue, Jun 27, 2023 at 11:09:32AM +, Klemens Nanni wrote:
> On Tue, Jun 27, 2023 at 01:32:37PM +0300, Vitaliy Makkoveev wrote:
> > M_TEMP seems unreasonable for interface groups data allocations.
>
> After claudio pointed out the wrong type, I thought of the same name,
>
Let's start to unlock (*pr_sysctl)() handlers. We have many of them, so
introduce temporary PR_MPSAFE flag to mark MP safe instead of pushing
kernel lock within handlers.
Unlock ip_sysctl(). Still take kernel lock within IPCTL_MRTSTATS case.
It looks like `mrtstat' protection is inconsistent, so
On Thu, Apr 27, 2023 at 02:54:38PM +0200, Claudio Jeker wrote:
> On Thu, Apr 27, 2023 at 01:55:33PM +0300, Vitaliy Makkoveev wrote:
> > Now only direct netlock used for inet sockets protection. The unlocked
> > access to all other sockets is safe, but we could lost consistency f
On Tue, May 16, 2023 at 08:26:37PM +0300, Vitaliy Makkoveev wrote:
> > On 16 May 2023, at 18:35, Alexander Bluhm wrote:
> >
> > I saw one issue in sysctl_niq(). Another CPU could write mq_maxlen
> > and our logic is inconsistent. Below is a fix with read once. Each
> On 16 May 2023, at 18:35, Alexander Bluhm wrote:
>
> I saw one issue in sysctl_niq(). Another CPU could write mq_maxlen
> and our logic is inconsistent. Below is a fix with read once. Each
> CPU detects its own change, last write wins. Or should we protect
> everything with mq_mtx? Then
> On 12 May 2023, at 03:34, David Gwynne wrote:
>
> so in top you see softnet0, softnet1, etc.
>
> the real change is putting a struct softnet in place to wrap the name
> and taskq up with.
>
> ok?
Makes sense. ok mvs
>
> Index: if.c
>
> On 12 May 2023, at 15:07, Alexander Bluhm wrote:
>
> On Fri, May 12, 2023 at 11:43:42AM +, Klemens Nanni wrote:
>>> Access rt_llinfo and check for NULL without checking RTF_LLINFO
>>> flag before. They are changed togehter with the arp or nd6 mutex.
>>
>> It is the same change, but I'd
> On 18 May 2023, at 01:14, Alexander Bluhm wrote:
>
> On Wed, May 17, 2023 at 12:46:02PM +0300, Vitaliy Makkoveev wrote:
>> Introduce `ip6_soiikey_lock' rwlock(9) to protect `ip6_soiikey'. It
>> accessed only by ip6_sysctl_soiikey() and ip6_sysctl() is the only
>> ip6
mrt_rtwalk_mfcsysctl() performs read-only access to protected data, so
rtable_walk() could be called with shared netlock.
Index: sys/netinet/ip_input.c
===
RCS file: /cvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.384
diff -u
Introduce `ip6_soiikey_lock' rwlock(9) to protect `ip6_soiikey'. It
accessed only by ip6_sysctl_soiikey() and ip6_sysctl() is the only
ip6_sysctl_soiikey() caller so context switch is allowed here. Also
remove unused `oldkey' from ip6_sysctl_soiikey().
For IPV6CTL_MRTSTATS, IPV6CTL_MRTMIF and
Also read-only access to netlock protected data.
Index: sys/netinet/ip_input.c
===
RCS file: /cvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.384
diff -u -p -r1.384 ip_input.c
--- sys/netinet/ip_input.c 16 May 2023
701 - 774 of 774 matches
Mail list logo
