it, but it is most likely
detrimental by now. If it is to be kept, a pagezero variant utilizing
non-temporal stores still makes sense but a different function should be
created for on-demand zeroing.
That said, it should be easy to lift a lot of this code. Could you please
benchmark with memcpy as implemented above? Not saying this particular
patch is wrong, but that the bigger problem should be addressed first.
Cheers,
--
Mateusz Guzik
//lists.freebsd.org/pipermail/svn-src-projects/2019-April/013336.html
--
Mateusz Guzik
On Wed, Dec 20, 2017 at 12:17:27PM +0100, Martin Pieuchot wrote:
> On 15/12/17(Fri) 22:03, Mateusz Guzik wrote:
> > > +void
> > > +__mtx_enter(struct mutex *mtx)
> > > +{
> > > +#ifdef MP_LOCKDEBUG
> > > + int nticks = __mp_lock_spinout;
> >
= 0)
- return (error);
+ error = copyout(buf, SCARG(uap, buf), SCARG(uap, nbyte));
explicit_bzero(buf, sizeof(buf));
- retval[0] = 0;
- return (0);
+ if (error == 0)
+ retval[0] = 0;
+ return (error);
}
--
Mateusz Guzik
On Wed, Feb 21, 2018 at 10:28 PM, Ted Unangst wrote:
> Mateusz Guzik wrote:
> > As the subject states. By the time the code gets to copyout, buf is
> > already populated. Clearing it only if copyout succeeds looks like a
> > braino, thus the following trivial proposal:
>
children on exit), while ptrace will skip that part.
Side effect of such a change be that getppid will stop requiring the
kernel lock.
--
Mateusz Guzik
On 9/4/20, Vitaliy Makkoveev wrote:
> On Fri, Sep 04, 2020 at 05:24:42PM +0200, Mateusz Guzik wrote:
>> getppid blindly follows the parent pointer and reads the pid.
>>
>> The problem is that ptrace reparents the traced process, so in
>> particular if you gdb -p $some
On 9/5/20, Philip Guenther wrote:
> On Fri, Sep 4, 2020 at 1:06 PM Mateusz Guzik wrote:
>
>> On 9/4/20, Vitaliy Makkoveev wrote:
>> > On Fri, Sep 04, 2020 at 05:24:42PM +0200, Mateusz Guzik wrote:
>> >> getppid blindly follows the parent pointer and reads th
On 9/5/20, Philip Guenther wrote:
> On Fri, Sep 4, 2020 at 2:59 PM Mateusz Guzik wrote:
>
>> On 9/5/20, Philip Guenther wrote:
>> > On Fri, Sep 4, 2020 at 1:06 PM Mateusz Guzik wrote:
>> >
>> >> On 9/4/20, Vitaliy Makkoveev wrote:
>> >&g
BSD
contain the necessary crappery to copy-paste including linker script
support.
Cheers,
--
Mateusz Guzik
On Tue, Oct 10, 2017 at 10:15:48AM +0200, Martin Pieuchot wrote:
> Hello Mateusz,
>
> On 09/10/17(Mon) 21:43, Mateusz Guzik wrote:
> > I was looking at rw lock code out of curiosity and noticed you always do
> > membar_enter which on MP-enabled amd64 kernel translates to mfenc
On Wed, Oct 11, 2017 at 03:15:42PM +0200, Martin Pieuchot wrote:
> On 10/10/17(Tue) 20:19, Mateusz Guzik wrote:
> > On Tue, Oct 10, 2017 at 10:15:48AM +0200, Martin Pieuchot wrote:
> > > Hello Mateusz,
> > >
> > > On 09/10/17(Mon) 21:43, Mateusz Guzik wrote:
&
primitive would - just provide a compiler barrier on
amd64/i386.
>From what I gather you are trying to mimick illumos nomenclature, but
they don't have an equivalent afaics. (perhaps Solaris grew one in the
meantime?)
In FreeBSD an appropriate routine is named atomic_thread_fence_rel
tion. */
> +void
> +rw_do_exit(struct rwlock *rwl, unsigned long wrlock)
> +{
> + unsigned long owner, set;
> +
> do {
> owner = rwl->rwl_owner;
> if (wrlock)
> @@ -337,7 +346,7 @@ rw_exit(struct rwlock *rwl)
> else
> set = (owner - RWLOCK_READ_INCR) &
> ~(RWLOCK_WAIT|RWLOCK_WRWANT);
> - } while (rw_cas(&rwl->rwl_owner, owner, set));
> + } while (__predict_false(rw_cas(&rwl->rwl_owner, owner, set)));
>
> if (owner & RWLOCK_WAIT)
> wakeup(rwl);
>
>
--
Mateusz Guzik
Oops, sorry for the mixup below. I got the e-mail bounced from someone
and it used their 'From' instead of the original. Regardless,
technical contend stands. :)
On 3/2/20, Mateusz Guzik wrote:
> On 2/29/20, Visa Hankala wrote:
>> There is a bug in how rw_exit_read() and
at happens if the access results in a page
fault and the area comes from a nfs mapped file? If network i/o is done
from the same context, this should result in 'locking against myself'
assertion failure.
That said, I'm not exactly familiar with the area, so maybe that's a
false alarm.
--
Mateusz Guzik
On Mon, Jan 16, 2017 at 07:34:43PM +, Alexander Bluhm wrote:
> On Mon, Jan 09, 2017 at 11:55:55PM +0100, Alexander Bluhm wrote:
> > On Thu, Dec 22, 2016 at 01:38:17AM +0100, Mateusz Guzik wrote:
> > > In this particular case, what happens if the access results in a page
&
added value is that programs can now use
different places in the tree with directory granulalrity as opposed to
having to chroot to the common parent.
This poses a problem with confining ".." lookups. There is a hack in
FreeBSD to explicitly track them, but perhaps you will be fine enough
with disallowing ".."s in the first place.
--
Mateusz Guzik
On Fri, Mar 24, 2017 at 4:56 PM, Alexander Bluhm
wrote:
> Hi,
>
> There is a race in dosendsyslog() which resulted in a crash on a
> 5.9 system. sosend(syslogf->f_data, ...) was called with a NULL
> pointer. So syslogf is not NULL, f_data is NULL and f_count is 1.
>
> The file structure is ref
On Sun, Mar 26, 2017 at 10:04 PM, Alexander Bluhm
wrote:
> On Sun, Mar 26, 2017 at 05:00:12PM +0200, Mateusz Guzik wrote:
> > The patch is somewhat incorrect, although from what I checked it happens
> > to generate the expected outcome in terms of assembly (the global pointer
>
On Mon, Mar 27, 2017 at 6:09 PM, Alexander Bluhm
wrote:
> On Mon, Mar 27, 2017 at 05:39:27PM +0200, Mateusz Guzik wrote:
> > The previous patch replaced multiple reads of the global var with just
> > one read and had the result stored in a local variable, which then is
> >
21 matches
Mail list logo