On 2022/06/09 1:55, Michael Lorenz wrote:
Module Name:src
Committed By: macallan
Date: Wed Jun 8 16:55:00 UTC 2022
Modified Files:
src/sys/uvm: uvm_map.c
Log Message:
initialize a variable to appease clang
My bug! Thanks for fixing it.
rin
Hi,
Chuck Silvers writes:
> On Tue, Sep 22, 2020 at 01:51:33AM +0900, Ryo ONODERA wrote:
>> Hi,
>>
>> It seems that r1.124 of uvm_amap.c causes random userland segfaults
>> on my NetBSD/amd64.
>
> this should be fixed now, could you try again?
>
> this was another case of my usual trick "test a
On Tue, Sep 22, 2020 at 01:51:33AM +0900, Ryo ONODERA wrote:
> Hi,
>
> It seems that r1.124 of uvm_amap.c causes random userland segfaults
> on my NetBSD/amd64.
this should be fixed now, could you try again?
this was another case of my usual trick "test a change well, modify
the change at the la
Hi,
It seems that r1.124 of uvm_amap.c causes random userland segfaults
on my NetBSD/amd64.
If you cannot reproduce the random segfaults, I will send my backtraces.
"Chuck Silvers" writes:
> Module Name: src
> Committed By: chs
> Date: Sun Sep 20 23:03:01 UTC 2020
>
> Modified Files:
> Modified Files:
> src/sys/uvm/pmap: pmap_segtab.c
>
> Log Message:
> Remove the #if defined(__mips_n64) && PAGE_SIZE == 8192 and make the
> check MI - all PTs are PAGE_SIZE aligned
thanks! that is a much better way of doing it.
.mrg.
On 2020/07/18 17:30, Jukka Ruohonen wrote:
On Sat, Jul 18, 2020 at 05:19:07PM +0900, Rin Okuyama wrote:
For most (all?) ports, these specifiers are exposed only for
_KERNEL and friends. So, inttypes(*3*) would not be the best
place for them. Currently, I'm not sure where they should be.
/usr/sha
On Sat, Jul 18, 2020 at 05:19:07PM +0900, Rin Okuyama wrote:
> For most (all?) ports, these specifiers are exposed only for
> _KERNEL and friends. So, inttypes(*3*) would not be the best
> place for them. Currently, I'm not sure where they should be.
> /usr/share/misc/style?
Perhaps a new inttypes
On 2020/07/16 16:02, matthew green wrote:
thanks! i'll try to remember we have PRIxPADDR because i
considered looking for it and thought we didn't have it...
My pleasure!
On 2020/07/16 16:10, Jukka Ruohonen wrote:
The whole { PRIxPADDR, PRIxPSIZE, ..., PRIxREGISTER } family
should probably b
On Thu, Jul 16, 2020 at 05:02:18PM +1000, matthew green wrote:
> thanks! i'll try to remember we have PRIxPADDR because i
> considered looking for it and thought we didn't have it...
The whole { PRIxPADDR, PRIxPSIZE, ..., PRIxREGISTER } family
should probably be documented in inttypes(3)?
- Jukk
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Wed Jul 15 15:08:26 UTC 2020
>
> Modified Files:
> src/sys/uvm: uvm_physseg.c
>
> Log Message:
> Fix typo. Use PRIxPADDR rather than casting.
thanks! i'll try to remember we have PRIxPADDR because i
considered l
On Sun, May 10, 2020 at 11:53:00PM +0100, Alexander Nasonov wrote:
> Taylor R Campbell wrote:
> > Log Message:
> > Implement swap encryption.
> >
> > Enabled by sysctl -w vm.swap_encrypt=1.
>
> If secmodel_securelevel(9) is still a thing, locking down this sysctl
> at high securelevel may improve
Taylor R Campbell wrote:
> This sounds entirely reasonable. Would you like to draft an
> implementation of that?
Sure, I can look into this on the weekend.
> Presumably it would require writing a sysctl callback function for
> vm.swap_encrypt, and would somehow involve kauth, but I'm not sure
>
On Sat, 9 May 2020 at 14:50, Taylor R Campbell wrote:
> Module Name:src
> Committed By: riastradh
> Date: Sat May 9 21:50:39 UTC 2020
>
> Modified Files:
> src/sys/uvm: uvm_swap.c
>
> Log Message:
> Implement swap encryption.
>
> Enabled by sysctl -w vm.swap_encrypt=1. K
> Date: Sun, 10 May 2020 23:53:00 +0100
> From: Alexander Nasonov
>
> Taylor R Campbell wrote:
> > Log Message:
> > Implement swap encryption.
> >
> > Enabled by sysctl -w vm.swap_encrypt=1.
>
> If secmodel_securelevel(9) is still a thing, locking down this sysctl
> at high securelevel may impr
Taylor R Campbell wrote:
> Log Message:
> Implement swap encryption.
>
> Enabled by sysctl -w vm.swap_encrypt=1.
If secmodel_securelevel(9) is still a thing, locking down this sysctl
at high securelevel may improve our security. Prior to this change,
swap devices were readable (even if enrypted w
On 2020/04/27 11:47, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Apr 27 02:47:26 UTC 2020
Modified Files:
src/sys/uvm: uvm_extern.h
Log Message:
Add missing \ to fix build for PMAP_CACHE_VIVT, i.e., ARMv4 and prior.
s/v4/v5/
Andrew Doran writes:
> On Wed, Jan 22, 2020 at 10:08:16AM +1100, matthew green wrote:
>
> > Andrew Doran writes:
> > > I also recommend disabling ACPI idle, at least until it can be made less
> > > aggressive by default. It causes a significant slowdown. It can be done
> > > with detaching all a
On Wed, Jan 22, 2020 at 10:08:16AM +1100, matthew green wrote:
> Andrew Doran writes:
> > I also recommend disabling ACPI idle, at least until it can be made less
> > aggressive by default. It causes a significant slowdown. It can be done
> > with detaching all acpicpu devices using "drvctl -d"
Andrew Doran writes:
> I also recommend disabling ACPI idle, at least until it can be made less
> aggressive by default. It causes a significant slowdown. It can be done
> with detaching all acpicpu devices using "drvctl -d" on each.
this disables cpufreq support, doesn't it? that seems like
an
On Fri, Jan 10, 2020 at 10:21:25PM +, Andrew Doran wrote:
> Hi Frank,
>
> On Fri, Jan 10, 2020 at 01:10:02PM +0100, Frank Kardel wrote:
>
> > Hi !
> >
> > With this state of January 2nd we ran some tests for robustness and timing
> > with our database setup:
> >
> > Machine:
> >
> > Mainbo
On 10.01.2020 23:21, Andrew Doran wrote:
> The second is pulling in efficient tracking of page clean/dirty status from
> the yamt-pagecache branch. This reduces the amount of work fsync() needs to
> do, which should be of benefit to the DBMS.
>
We probably should adapt DBMS to use fsync_range(),
Hi Frank,
On Fri, Jan 10, 2020 at 01:10:02PM +0100, Frank Kardel wrote:
> Hi !
>
> With this state of January 2nd we ran some tests for robustness and timing
> with our database setup:
>
> Machine:
>
> Mainboard: S2600WFT
>
> CPU: 2 x Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz
>
> machdep.spec
Hi !
With this state of January 2nd we ran some tests for robustness and
timing with our database setup:
Machine:
Mainboard: S2600WFT
CPU: 2 x Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz
machdep.spectre_v1.mitigated = 0
machdep.spectre_v2.hwmitigated = 1
machdep.spectre_v2.swmitigated = 1
mach
"Andrew Doran" writes:
> Module Name: src
> Committed By: ad
> Date: Fri Dec 27 13:19:25 UTC 2019
>
> Modified Files:
> src/sys/uvm: uvm.h uvm_page.c
>
> Log Message:
> Nothing uses uvm.cpus any more, and we can do the same with cpu_lookup(),
> so get rid of it.
this has been usef
> > So I guess we won't be switching pg->phys_addr from paddr to pfn?
> > Speaking of which, any plans for expanding to >32-bit (or >31-bit, if
> > signed) pfns in the rest of uvm?
>
> That's not part of my current plans for UVM, which right now extend only as
> far as breaking the back of the per
On Tue, Dec 24, 2019 at 03:22:54AM +, Taylor R Campbell wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sat Dec 21 14:41:44 UTC 2019
> >
> > - Add inlines to set/get locator values in the unused lower bits of
> > pg->phys_addr. Begin by using it to cache the freel
> On Dec 23, 2019, at 7:22 PM, Taylor R Campbell
> wrote:
>
> So I guess we won't be switching pg->phys_addr from paddr to pfn?
If that's the case, we should rename the field.
-- thorpej
> Module Name:src
> Committed By: ad
> Date: Sat Dec 21 14:41:44 UTC 2019
>
> - Add inlines to set/get locator values in the unused lower bits of
> pg->phys_addr. Begin by using it to cache the freelist index, because
> computing it is expensive and that shows up during profil
On Sat, Dec 21, 2019 at 03:08:18PM +0100, Christoph Badura wrote:
> On Sat, Dec 21, 2019 at 12:58:26PM +, Andrew Doran wrote:
> > Modified Files:
> > src/sys/uvm: uvm_extern.h uvm_page.c
> > Log Message:
> > Add uvm_free(): returns number of free pages in system.
>
> Can you rename this t
On Sat, Dec 21, 2019 at 12:58:26PM +, Andrew Doran wrote:
> Modified Files:
> src/sys/uvm: uvm_extern.h uvm_page.c
> Log Message:
> Add uvm_free(): returns number of free pages in system.
Can you rename this to a more descriptive name? Say uvm_free_pages() or
something.
Also, we traditi
> Date: Sun, 1 Dec 2019 11:54:24 +
> From: Andrew Doran
>
> On Sun, Dec 01, 2019 at 08:19:09AM +, Maxime Villard wrote:
>
> > Modified Files:
> > src/sys/uvm: uvm_fault.c
> >
> > Log Message:
> > Use atomic_{load,store}_relaxed() on global counters.
>
> If you would be so kind, ple
Hi,
On Sun, Dec 01, 2019 at 08:19:09AM +, Maxime Villard wrote:
> Modified Files:
> src/sys/uvm: uvm_fault.c
>
> Log Message:
> Use atomic_{load,store}_relaxed() on global counters.
If you would be so kind, please don't do any more of the UVM counters. I
have a patch to make these CP
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Tue Aug 6 08:10:27 UTC 2019
>
> Modified Files:
> src/sys/uvm: uvm_mmap.c
>
> Log Message:
> Change 'npgs' from int to size_t. Otherwise the 64bit->32bit conversion
> could lead to npgs=0, which is not expect
Good point, added asserts in genfs_io.c for this.
Le dim. 9 déc. 2018 à 23:56, matthew green a écrit :
>
> "Jaromir Dolecek" writes:
> > Module Name: src
> > Committed By: jdolecek
> > Date: Sun Dec 9 20:45:37 UTC 2018
> >
> > Modified Files:
> > src/sys/uvm: uvm_bio.c
> >
> > Log
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Sun Dec 9 20:45:37 UTC 2018
>
> Modified Files:
> src/sys/uvm: uvm_bio.c
>
> Log Message:
> for direct map case, avoid PGO_NOBLOCKALLOC when writing, it makes
> genfs_getpages() return unallocated pages
On Oct 27, 10:14pm, campbell+netbsd-source-change...@mumble.net (Taylor R
Campbell) wrote:
-- Subject: Re: CVS commit: src/sys/uvm
| > Due to incorrect error recovery mmap requests that were denied due to
| > PaX/MPROTECT ended up not cleaning up, which made processes stuck. I
| > coul
On 28.10.2017 00:14, Taylor R Campbell wrote:
>> Date: Fri, 27 Oct 2017 21:46:48 + (UTC)
>> This needs to be pulled up to -8.
>
> Yes.
>
I've verified that the reported bug is gone.
signature.asc
Description: OpenPGP digital signature
> Date: Fri, 27 Oct 2017 21:46:48 + (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> In article ,
> Paul Goyette wrote:
> >Can you please PLEASE provide an actual description of the problem
> >you're fixing.
>
> Due to incorrect error recovery mmap requests that were denied due to
>
In article ,
Paul Goyette wrote:
>On Fri, 27 Oct 2017, Utkarsh Anand wrote:
>
>> Module Name: src
>> Committed By:utkarsh009
>> Date:Fri Oct 27 12:01:08 UTC 2017
>>
>> Modified Files:
>> src/sys/uvm: uvm_mmap.c
>>
>> Log Message:
>> [syzkaller] Fix for PR #52658 as su
On Fri, 27 Oct 2017, Utkarsh Anand wrote:
Module Name:src
Committed By: utkarsh009
Date: Fri Oct 27 12:01:08 UTC 2017
Modified Files:
src/sys/uvm: uvm_mmap.c
Log Message:
[syzkaller] Fix for PR #52658 as suggested by riastradh@
The bug was found by Dmitry Vyukov (dvyu.
On 20.05.2017 02:02, Kamil Rytarowski wrote:
> On 19.05.2017 17:30, Chuck Silvers wrote:
>> Module Name: src
>> Committed By:chs
>> Date:Fri May 19 15:30:19 UTC 2017
>>
>> Modified Files:
>> src/sys/uvm: uvm_map.c uvm_mmap.c
>>
>> Log Message:
>> make MAP_FIXED mapping
On 19.05.2017 17:30, Chuck Silvers wrote:
> Module Name: src
> Committed By: chs
> Date: Fri May 19 15:30:19 UTC 2017
>
> Modified Files:
> src/sys/uvm: uvm_map.c uvm_mmap.c
>
> Log Message:
> make MAP_FIXED mapping operations atomic. fixes PR 52239.
> previously, unmapping any ent
In article <20170519162231.ga3...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Fri, May 19, 2017 at 04:14:03PM +, co...@sdf.org wrote:
>> On Fri, May 19, 2017 at 03:30:19PM +, Chuck Silvers wrote:
>> > Module Name: src
>> > Committed By: chs
>> > Date: Fri May
On Fri, May 19, 2017 at 04:14:03PM +, co...@sdf.org wrote:
> On Fri, May 19, 2017 at 03:30:19PM +, Chuck Silvers wrote:
> > Module Name:src
> > Committed By: chs
> > Date: Fri May 19 15:30:19 UTC 2017
> >
> > Modified Files:
> > src/sys/uvm: uvm_map.c uvm_mm
On Fri, May 19, 2017 at 03:30:19PM +, Chuck Silvers wrote:
> Module Name: src
> Committed By: chs
> Date: Fri May 19 15:30:19 UTC 2017
>
> Modified Files:
> src/sys/uvm: uvm_map.c uvm_mmap.c
>
> Log Message:
> make MAP_FIXED mapping operations atomic. fixes PR 52239.
> previous
> Log Message:
> Ugh. This stuff is disgusting. We really need an arch dependent
> PRIxOFF (and PRIdOFF) to print off_t's in a way that matches the
> arch's definition of off_t.
off_t is supposed to be more-MI. it comes down to:
sys/types.h:177:typedef __off_t off_t; /* file
Date:Mon, 20 Mar 2017 13:03:31 +0100
From:Joerg Sonnenberger
Message-ID: <20170320120331.ga19...@britannica.bec.de>
| On Mon, Mar 20, 2017 at 10:44:24AM +, Robert Elz wrote:
| > Why is there no PRI[xd]OFF ? How are off_t's intended to be printed?
|
| %j
On Mon, Mar 20, 2017 at 10:44:24AM +, Robert Elz wrote:
> Why is there no PRI[xd]OFF ? How are off_t's intended to be printed?
%jd + cast to intmax_t.
Joerg
On Fri, Dec 23, 2016 at 09:22:22AM +1100, matthew green wrote:
> > Log Message:
> > Use uvm_physseg.h:uvm_page_physload() instead of uvm_extern.h
> >
> > For this, include uvm_physseg.h in the build and include tree, make a
> > cosmetic modification to the prototype for uvm_page_physload().
>
> w
"Cherry G. Mathew" writes:
> Module Name: src
> Committed By: cherry
> Date: Thu Dec 22 13:26:25 UTC 2016
>
> Modified Files:
> src/sys/uvm: Makefile uvm.h uvm_extern.h uvm_page.c
>
> Log Message:
> Use uvm_physseg.h:uvm_page_physload() instead of uvm_extern.h
>
> For this, includ
Le 20/07/2016 à 20:07, matthew green a écrit :
"Maxime Villard" writes:
Module Name:src
Committed By: maxv
Date: Wed Jul 20 12:38:44 UTC 2016
Modified Files:
src/sys/uvm: uvm_extern.h uvm_km.c
Log Message:
Introduce uvm_km_protect.
can you bring this up on tech-kern a
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Wed Jul 20 12:38:44 UTC 2016
>
> Modified Files:
> src/sys/uvm: uvm_extern.h uvm_km.c
>
> Log Message:
> Introduce uvm_km_protect.
can you bring this up on tech-kern and discuss what it is for?
this commit me
On Fri, Feb 28, 2014 at 09:07:40AM +0200, Alan Barrett wrote:
> On Wed, 26 Feb 2014, Matt Thomas wrote:
> >Modified Files:
> > src/sys/uvm: uvm_meter.c uvm_param.h
> >
> >Log Message:
> >Add vm.min_address and vm.max_address which return VM_MIN_ADDRESS and
> >VM_MAXUSER_ADDRESS.
>
> Do these n
On Feb 27, 2014, at 11:07 PM, Alan Barrett wrote:
> On Wed, 26 Feb 2014, Matt Thomas wrote:
>> Modified Files:
>> src/sys/uvm: uvm_meter.c uvm_param.h
>>
>> Log Message:
>> Add vm.min_address and vm.max_address which return VM_MIN_ADDRESS and
>> VM_MAXUSER_ADDRESS.
>
> Do these need to us
On Wed, 26 Feb 2014, Matt Thomas wrote:
Modified Files:
src/sys/uvm: uvm_meter.c uvm_param.h
Log Message:
Add vm.min_address and vm.max_address which return VM_MIN_ADDRESS and
VM_MAXUSER_ADDRESS.
Do these need to use the old style #define constants
instead of the new style (since 2005)
On 4 September 2012 12:32, Mindaugas Rasiukevicius wrote:
> Matt Thomas wrote:
>>
>> On Sep 3, 2012, at 3:33 PM, Mindaugas Rasiukevicius wrote:
>>
>> > "Matt Thomas" wrote:
>> >> Module Name: src
>> >> Committed By: matt
>> >> Date: Mon Sep 3 19:53:43 UTC 2012
>> >>
>> >
Matt Thomas wrote:
>
> On Sep 3, 2012, at 3:33 PM, Mindaugas Rasiukevicius wrote:
>
> > "Matt Thomas" wrote:
> >> Module Name: src
> >> Committed By: matt
> >> Date: Mon Sep 3 19:53:43 UTC 2012
> >>
> >> Modified Files:
> >>src/sys/uvm: uvm_km.c uvm_map.c
> >>
> >
On Sep 3, 2012, at 3:33 PM, Mindaugas Rasiukevicius wrote:
> "Matt Thomas" wrote:
>> Module Name: src
>> Committed By:matt
>> Date:Mon Sep 3 19:53:43 UTC 2012
>>
>> Modified Files:
>> src/sys/uvm: uvm_km.c uvm_map.c
>>
>> Log Message:
>> Switch to a spin lock (uvm
"Matt Thomas" wrote:
> Module Name: src
> Committed By: matt
> Date: Mon Sep 3 19:53:43 UTC 2012
>
> Modified Files:
> src/sys/uvm: uvm_km.c uvm_map.c
>
> Log Message:
> Switch to a spin lock (uvm_kentry_lock) which, fortunately, was sitting
> there unused.
- pmap_growkernel() m
On 2/17/12 6:41 PM, Matt Thomas wrote:
Module Name:src
Committed By: matt
Date: Fri Feb 17 23:41:03 UTC 2012
Modified Files:
src/sys/uvm: uvm_init.c uvm_param.h
Log Message:
Make sure to export uvmexp_* if MODULAR is defined.
Make the uvmexp_page* be a pointer to a const
On Mon, Feb 20, 2012 at 07:49:16PM +, Mindaugas Rasiukevicius wrote:
> "Manuel Bouyer" wrote:
> > Module Name:src
> > Committed By: bouyer
> > Date: Mon Feb 20 19:14:24 UTC 2012
> >
> > Modified Files:
> > src/sys/uvm: uvm_km.c uvm_kmguard.c uvm_map.c
> >
> >
"Manuel Bouyer" wrote:
> Module Name: src
> Committed By: bouyer
> Date: Mon Feb 20 19:14:24 UTC 2012
>
> Modified Files:
> src/sys/uvm: uvm_km.c uvm_kmguard.c uvm_map.c
>
> Log Message:
> When using uvm_km_pgremove_intrsafe() make sure mappings are removed
> before returning the
> > Module Name:src
> > Committed By: matt
> > Date: Wed Sep 28 22:52:16 UTC 2011
> >
> > Modified Files:
> > src/sys/uvm: uvm_page.c uvm_pager.c uvm_pager.h
> >
> > Log Message:
> > Reallocate emergency pager va when ncolors is increased. (modication of
> > patch
>
> On Sep 29, 2011, at 12:52 AM, Matt Thomas wrote:
>
> > Module Name:src
> > Committed By: matt
> > Date: Wed Sep 28 22:52:16 UTC 2011
> >
> > Modified Files:
> > src/sys/uvm: uvm_page.c uvm_pager.c uvm_pager.h
> >
> > Log Message:
> > Reallocate emergency pag
On Sep 29, 2011, at 12:52 AM, Matt Thomas wrote:
> Module Name: src
> Committed By: matt
> Date: Wed Sep 28 22:52:16 UTC 2011
>
> Modified Files:
> src/sys/uvm: uvm_page.c uvm_pager.c uvm_pager.h
>
> Log Message:
> Reallocate emergency pager va when ncolors is increased. (modicat
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> > Right, uvm_anon_locklaonpg() dance can happen only in O->A case.
> > However, having uvm_anfree() able to release the lock by its interface
> > definition is potentially defective. It is the main motivation why I
> > want to slightly rework the
[ moving to tech-kern ]
hi,
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
>> >
>> > Here is the updated patch after your changes:
>> >
>> > http://www.netbsd.org/~rmind/uvm_anon_freelst2.diff
>> >
>> > As you noted, uvm_anfree() can temporarily release the amap lock - that
>> > can happen
On Sat, Aug 06, 2011 at 05:25:04PM +, Mindaugas Rasiukevicius wrote:
> Module Name: src
> Committed By: rmind
> Date: Sat Aug 6 17:25:04 UTC 2011
>
> Modified Files:
> src/sys/uvm: uvm_amap.c uvm_anon.c uvm_anon.h uvm_fault.c uvm_loan.c
> uvm_map.c
>
> Log Message:
>
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> >
> > Here is the updated patch after your changes:
> >
> > http://www.netbsd.org/~rmind/uvm_anon_freelst2.diff
> >
> > As you noted, uvm_anfree() can temporarily release the amap lock - that
> > can happen in amap_copy(). Patch closes the race
hi,
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
>> >> > Log Message:
>> >> > amap_copy(): Keep the source amap locked until its lock has been
>> >> > copied.
>> >>
>> >> btw, this code seems to assume that uvm_anfree does not release the
>> >> lock even temporarily while the comment on uvm
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> >> > Log Message:
> >> > amap_copy(): Keep the source amap locked until its lock has been
> >> > copied.
> >>
> >> btw, this code seems to assume that uvm_anfree does not release the
> >> lock even temporarily while the comment on uvm_anfree1 says
hi,
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
>> > Module Name: src
>> > Committed By: hannken
>> > Date: Mon Jun 27 15:56:37 UTC 2011
>> >
>> > Modified Files:
>> >src/sys/uvm: uvm_amap.c
>> >
>> > Log Message:
>> > amap_copy(): Keep the source amap locked u
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> > Module Name:src
> > Committed By: hannken
> > Date: Mon Jun 27 15:56:37 UTC 2011
> >
> > Modified Files:
> > src/sys/uvm: uvm_amap.c
> >
> > Log Message:
> > amap_copy(): Keep the source amap locked until its loc
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> hi,
>
> > Module Name:src
> > Committed By: hannken
> > Date: Mon Jun 27 15:56:37 UTC 2011
> >
> > Modified Files:
> > src/sys/uvm: uvm_amap.c
> >
> > Log Message:
> > amap_copy(): Keep the source amap locked unti
On Tue, Jun 28, 2011 at 9:39 AM, YAMAMOTO Takashi
wrote:
> hi,
>
>> Module Name: src
>> Committed By: hannken
>> Date: Mon Jun 27 15:56:37 UTC 2011
>>
>> Modified Files:
>> src/sys/uvm: uvm_amap.c
>>
>> Log Message:
>> amap_copy(): Keep the source amap locked until its lock has been
hi,
> Module Name: src
> Committed By: hannken
> Date: Mon Jun 27 15:56:37 UTC 2011
>
> Modified Files:
> src/sys/uvm: uvm_amap.c
>
> Log Message:
> amap_copy(): Keep the source amap locked until its lock has been copied.
btw, this code seems to assume that uvm_anfree does not re
"YAMAMOTO Takashi" wrote:
> Module Name: src
> Committed By: yamt
> Date: Fri Jun 24 01:23:05 UTC 2011
>
> Modified Files:
> src/sys/uvm: uvm_anon.c
>
> Log Message:
> uvm_anon_release: fix a locking error after the rmind-uvmplock merge
>
Thanks a lot! I have been hunting this
tsugutomo.en...@jp.sony.com wrote:
> > Modified Files:
> > src/sys/uvm: uvm_amap.c
> >
> > Log Message:
> > Clean-up, add asserts, slightly simplify.
> >
> >
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.95 -r1.96 src/sys/uvm/uvm_amap.c
>
> In amap_copy(), I guess map entry may b
Mindaugas Rasiukevicius writes:
> Module Name: src
> Committed By: rmind
> Date: Thu Jun 23 18:15:30 UTC 2011
>
> Modified Files:
> src/sys/uvm: uvm_amap.c
>
> Log Message:
> Clean-up, add asserts, slightly simplify.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.95 -r
Hello,
"Juergen Hannken-Illjes" wrote:
> Module Name: src
> Committed By: hannken
> Date: Fri Jun 17 09:50:52 UTC 2011
>
> Modified Files:
> src/sys/uvm: uvm_bio.c
>
> Log Message:
> When ubc_alloc() reuses a cached mapping window remove the object from
> the lists AFTER clearing
On Fri, Feb 11, 2011 at 11:05:55PM +, Jared D. McNeill wrote:
> Module Name: src
> Committed By: jmcneill
> Date: Fri Feb 11 23:05:55 UTC 2011
>
> Modified Files:
> src/sys/uvm: uvm_device.c uvm_pmap.h
>
> Log Message:
> add optional MD pmap_mmap_flags macro for passing flags b
Matt Thomas writes:
> Module Name: src
> Committed By: matt
> Date: Tue Jan 18 21:43:29 UTC 2011
>
> Modified Files:
> src/sys/uvm: uvm_page.h uvm_pglist.c
>
> Log Message:
> Improve the efficiency of searching for a contiguous set of free pages.
>
>
> To generate a diff of thi
hi,
do you have any plan to use pg->offset of anon pages,
or is it an unnecessary side-effect?
YAMAMOTO Takashi
> Module Name: src
> Committed By: matt
> Date: Tue Jan 4 08:26:33 UTC 2011
>
> Modified Files:
> src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c
>
> Log Me
hi,
>> >> (Just in case, have you read my paper?)
>>
>> which paper? i guess no.
>
> http://uebayasi.dyndns.org/~uebayasi/tmp/xip.pdf
i will put it on my todo list. thanks.
YAMAMOTO Takashi
On Thu Jan 06 2011 at 05:51:57 +, enami tsugutomo wrote:
> Module Name: src
> Committed By: enami
> Date: Thu Jan 6 05:51:57 UTC 2011
>
> Modified Files:
> src/sys/uvm: uvm_fault.c
>
> Log Message:
> Fix bugs introduced by previous commit; allocated page needs to be bound
> wi
On Thu, Jan 06, 2011 at 02:11:53AM +0900, Toru Nishimura wrote:
> [...]
> For each port, it's just ok to tell UVM the number of colour
> at boot time. In PIPT system, the number is one, which
> makes whole VM logic works just as before. In VIPT
Not really, the number of coulours is also used fo
Some more rambling commments;
> Colour match between VPN and PFN is *must*
There are two cases when colour match rule does matter;
1. new physical page is assigned for a given va.
-> just make sure to choose matched PFN with VPN.
2. kernel double maps another va, which may be KVA or UVA.
On Wed, Jan 05, 2011 at 05:58:34AM +, YAMAMOTO Takashi wrote:
> hi,
>
> > I take silence as "no objection".
>
> the silence in this case means was-busy-for-other-things-and-forgot.
> sorry.
>
> >> I have no real code for this big picture at this moment. Making
> >> vm_physseg available as r
Masao Uebayashi responds as;
The VIPT rule is simple; just make sure to match colour between
VPN and PFN.
Hmmm. I've thought that the page colouring constraint is *should*,
not *must*.
Colour match between VPN and PFN is *must*
If not obeying the rule, it's possible two or more cache in
On Wed, Jan 05, 2011 at 01:29:02AM +0900, Toru Nishimura wrote:
> Masao Uebayashi responds as;
>
> >>The entire effect is to eliminate the necessity of VIPT fixup efforts in
> >>port-specific pmap.c and ends up with improving the cache effeciency
> >>in large degree. This is _the intent_ behind
hi,
> I take silence as "no objection".
the silence in this case means was-busy-for-other-things-and-forgot.
sorry.
>> I have no real code for this big picture at this moment. Making
>> vm_physseg available as reference is the first step. This only
>> changes uvm_page_physload() to return a po
On Tue, Jan 04, 2011 at 08:35:48AM -0800, Matt Thomas wrote:
>
> On Jan 4, 2011, at 8:33 AM, Manuel Bouyer wrote:
>
> > On Tue, Jan 04, 2011 at 08:03:33AM -0800, Matt Thomas wrote:
> >>> I fixed this issue in arch/x86/x86/x86_machdep.c 1.37, I wonder if your
> >>> change
> >>> has reintroduced t
On Jan 4, 2011, at 8:33 AM, Manuel Bouyer wrote:
> On Tue, Jan 04, 2011 at 08:03:33AM -0800, Matt Thomas wrote:
>>> I fixed this issue in arch/x86/x86/x86_machdep.c 1.37, I wonder if your
>>> change
>>> has reintroduced this problem ...
>>
>> Since it's not turned on by default, I doubt it.
>
On Tue, Jan 04, 2011 at 08:03:33AM -0800, Matt Thomas wrote:
> > I fixed this issue in arch/x86/x86/x86_machdep.c 1.37, I wonder if your
> > change
> > has reintroduced this problem ...
>
> Since it's not turned on by default, I doubt it.
I guess if you wrote it, you expect to use it for somethi
Masao Uebayashi responds as;
The entire effect is to eliminate the necessity of VIPT fixup efforts in
port-specific pmap.c and ends up with improving the cache effeciency
in large degree. This is _the intent_ behind VIPT design. So far OS
virtual memory strategy paid little attention to make
On Jan 4, 2011, at 4:57 AM, Manuel Bouyer wrote:
> On Tue, Jan 04, 2011 at 02:32:02AM -0800, Matt Thomas wrote:
>> Not really. A lot of device can only do 32bit DMA transfers so without some
>> type assistance (like the alpha has) you are restricted to DMA to the first
>> 4GB of RAM. If you a
On Tue, Jan 04, 2011 at 06:25:12PM +0900, Toru Nishimura wrote:
> Matt Thomas modified UVM colour matching scheme;
>
> >Modified Files:
> > src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c
> >
> >Log Message:
> >Add better color matching selecting free pages. KM pages will now allo
On Tue, Jan 04, 2011 at 02:32:02AM -0800, Matt Thomas wrote:
> Not really. A lot of device can only do 32bit DMA transfers so without some
> type assistance (like the alpha has) you are restricted to DMA to the first
> 4GB of RAM. If you are doing DMA to an address >= 4GB, the system will stage
On Jan 4, 2011, at 2:19 AM, Michael Graff wrote:
> On 1/4/11 2:26 AM, Matt Thomas wrote:
>> Module Name: src
>> Committed By:matt
>> Date:Tue Jan 4 08:26:33 UTC 2011
>>
>> Modified Files:
>> src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c
>>
>> Log Messag
On 1/4/11 2:26 AM, Matt Thomas wrote:
> Module Name: src
> Committed By: matt
> Date: Tue Jan 4 08:26:33 UTC 2011
>
> Modified Files:
> src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c
>
> Log Message:
...
> When allocating kernel memory pages, allow the MD to specify a p
1 - 100 of 146 matches
Mail list logo
