> Date: Thu, 10 Feb 2022 10:19:20 +
> From: Klemens Nanni
>
> On Mon, Feb 07, 2022 at 02:12:52PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 7 Feb 2022 12:11:42 +
> > > From: Klemens Nanni
> > >
> > > On Mon, Feb 07, 2022 at 12:41:27PM +0100, Mark Kettenis wrote:
>
> > > > So there i
On Mon, Feb 07, 2022 at 02:12:52PM +0100, Mark Kettenis wrote:
> > Date: Mon, 7 Feb 2022 12:11:42 +
> > From: Klemens Nanni
> >
> > On Mon, Feb 07, 2022 at 12:41:27PM +0100, Mark Kettenis wrote:
> > > So there is the existing UVM_MAP_REQ_WRITE(). Compared to
> > > vm_map_assert_wrlock() it
> Date: Mon, 7 Feb 2022 12:11:42 +
> From: Klemens Nanni
>
> On Mon, Feb 07, 2022 at 12:41:27PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 7 Feb 2022 11:12:50 +
> > > From: Klemens Nanni
> > >
> > > On Thu, Jan 27, 2022 at 11:11:48AM +, Klemens Nanni wrote:
> > > > On Tue, Jan 2
On Mon, Feb 07, 2022 at 12:41:27PM +0100, Mark Kettenis wrote:
> > Date: Mon, 7 Feb 2022 11:12:50 +
> > From: Klemens Nanni
> >
> > On Thu, Jan 27, 2022 at 11:11:48AM +, Klemens Nanni wrote:
> > > On Tue, Jan 25, 2022 at 07:54:52AM +, Klemens Nanni wrote:
> > > > > Could we use a vm_
> Date: Mon, 7 Feb 2022 11:12:50 +
> From: Klemens Nanni
>
> On Thu, Jan 27, 2022 at 11:11:48AM +, Klemens Nanni wrote:
> > On Tue, Jan 25, 2022 at 07:54:52AM +, Klemens Nanni wrote:
> > > > Could we use a vm_map_assert_locked() or something similar that reflect
> > > > the exclusive
On Thu, Jan 27, 2022 at 11:11:48AM +, Klemens Nanni wrote:
> On Tue, Jan 25, 2022 at 07:54:52AM +, Klemens Nanni wrote:
> > > Could we use a vm_map_assert_locked() or something similar that reflect
> > > the exclusive or shared (read) lock comments? I don't trust comments.
> > > It's too e
On Tue, Jan 25, 2022 at 07:54:52AM +, Klemens Nanni wrote:
> > Could we use a vm_map_assert_locked() or something similar that reflect
> > the exclusive or shared (read) lock comments? I don't trust comments.
> > It's too easy to miss a lock in a code path.
>
> This survives desktop usage, ru
On Mon, Jan 24, 2022 at 12:08:33PM -0300, Martin Pieuchot wrote:
> On 24/01/22(Mon) 12:06, Klemens Nanni wrote:
> > On Sun, Jan 16, 2022 at 09:22:50AM -0300, Martin Pieuchot wrote:
> > > IMHO this approach of let's try if it works now and revert if it isn't
> > > doesn't help us make progress. I'd
On 24/01/22(Mon) 12:06, Klemens Nanni wrote:
> On Sun, Jan 16, 2022 at 09:22:50AM -0300, Martin Pieuchot wrote:
> > IMHO this approach of let's try if it works now and revert if it isn't
> > doesn't help us make progress. I'd be more confident seeing diffs that
> > assert for the right lock in the
On Sun, Jan 16, 2022 at 09:22:50AM -0300, Martin Pieuchot wrote:
> IMHO this approach of let's try if it works now and revert if it isn't
> doesn't help us make progress. I'd be more confident seeing diffs that
> assert for the right lock in the functions called by uvm_mapanon() and
> documentatio
On 14/01/22(Fri) 23:01, Mark Kettenis wrote:
> > Date: Tue, 11 Jan 2022 23:13:20 +
> > From: Klemens Nanni
> >
> > On Tue, Jan 11, 2022 at 09:54:44AM -0700, Theo de Raadt wrote:
> > > > Now this is clearly a "slow" path. I don't think there is any reason
> > > > not to put all the code in th
> Date: Tue, 11 Jan 2022 23:13:20 +
> From: Klemens Nanni
>
> On Tue, Jan 11, 2022 at 09:54:44AM -0700, Theo de Raadt wrote:
> > > Now this is clearly a "slow" path. I don't think there is any reason
> > > not to put all the code in that if (uvw_wxabort) block under the
> > > kernel lock. F
Klemens Nanni:
> > > Now this is clearly a "slow" path. I don't think there is any reason
> > > not to put all the code in that if (uvw_wxabort) block under the
> > > kernel lock. For now I think making access to ps_wxcounter atomic is
> > > just too fine grained.
> >
> > Right. Lock the whole
I am saying I want better study on all architectures, so that I don't
hit problems (first) in the snapshots cluster.
Theo de Raadt wrote:
> I am blocking this.
>
> I don't see any messaging which suggests this has been run on all
> architectures. It might still hit some MD code which is wrong.
I am blocking this.
I don't see any messaging which suggests this has been run on all
architectures. It might still hit some MD code which is wrong.
Klemens Nanni wrote:
> On Tue, Jan 11, 2022 at 09:54:44AM -0700, Theo de Raadt wrote:
> > > Now this is clearly a "slow" path. I don't think the
On Wed, Jan 12, 2022 at 02:32:31AM +0300, Vitaliy Makkoveev wrote:
> Does it make sense to document that kernel lock protects
> `ps_wxcounter’? We have such [K] in other structure definitions.
>
> + u_int64_t ps_wxcounter; /* [K] number of W^X violations */
Yes, that would be in order
Does it make sense to document that kernel lock protects
`ps_wxcounter’? We have such [K] in other structure definitions.
+ u_int64_t ps_wxcounter; /* [K] number of W^X violations */
The rest of diff looks good to me.
> On 12 Jan 2022, at 02:13, Klemens Nanni wrote:
>
> On Tue, J
On Tue, Jan 11, 2022 at 09:54:44AM -0700, Theo de Raadt wrote:
> > Now this is clearly a "slow" path. I don't think there is any reason
> > not to put all the code in that if (uvw_wxabort) block under the
> > kernel lock. For now I think making access to ps_wxcounter atomic is
> > just too fine g
> Now this is clearly a "slow" path. I don't think there is any reason
> not to put all the code in that if (uvw_wxabort) block under the
> kernel lock. For now I think making access to ps_wxcounter atomic is
> just too fine grained.
Right. Lock the whole block.
> Date: Tue, 11 Jan 2022 08:15:13 +
> From: Klemens Nanni
>
> On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> > On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > > The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
> >
> > Right, I did not pay
On 11/01/22 09:57 +0100, Claudio Jeker wrote:
> On Tue, Jan 11, 2022 at 08:15:13AM +, Klemens Nanni wrote:
> > On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> > > On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > > > The uvm_wxabort path within uvm_wxcheck(
On Tue, Jan 11, 2022 at 08:15:13AM +, Klemens Nanni wrote:
> On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> > On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > > The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
> >
> > Right, I did not pay eno
On Tue, Jan 11, 2022 at 08:15:13AM +, Klemens Nanni wrote:
> On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> > On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > > The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
> >
> > Right, I did not pay eno
On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote:
> On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> > The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
>
> Right, I did not pay enough attention to W^X handling.
New diff, either alone or on top of the m
On Fri, Dec 31, 2021 at 09:54:23AM -0700, Theo de Raadt wrote:
> >Now that mpi has unlocked uvm's fault handler, we can unlock the mmap
> >syscall to handle MAP_ANON without the big lock.
> ...
> >So here's a first small step. I've been running with this for months
> >on a few amd64, arm64 and spa
On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote:
> The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
Right, I did not pay enough attention to W^X handling.
I'm not entirely sure about the sigexit() path.
There's `ps_wxcounter' as u_int64_t which needs a lock or atomi
The uvm_wxabort path within uvm_wxcheck() looks not MP-safe.
> On 31 Dec 2021, at 12:14, Klemens Nanni wrote:
>
> Now that mpi has unlocked uvm's fault handler, we can unlock the mmap
> syscall to handle MAP_ANON without the big lock.
>
> sys_mmap() still protects the !MAP_ANON case, i.e. file
>Now that mpi has unlocked uvm's fault handler, we can unlock the mmap
>syscall to handle MAP_ANON without the big lock.
...
>So here's a first small step. I've been running with this for months
>on a few amd64, arm64 and sparc64 boxes without problems
So, 3 architectures have been tested.
I rea
28 matches
Mail list logo
