Anton Blanchard <[EMAIL PROTECTED]> writes:
> Hi,
>
> > Where do you do this? And how do you handle the case of aliases with kseg,
> > the giant kernel mapping.
>
> Aliases between user and kernel mappings of a page are handled by
> flush_page_to_ram the old interface) or
Anton Blanchard [EMAIL PROTECTED] writes:
Hi,
Where do you do this? And how do you handle the case of aliases with kseg,
the giant kernel mapping.
Aliases between user and kernel mappings of a page are handled by
flush_page_to_ram the old interface) or {copy,clear}_user_page,
Hi,
> Where do you do this? And how do you handle the case of aliases with kseg,
> the giant kernel mapping.
Aliases between user and kernel mappings of a page are handled by
flush_page_to_ram the old interface) or {copy,clear}_user_page,
flush_dcache_page and update_mmu_cache (new
> Did you find any software that breaks due to the additional restriction
> on the virtual addresses of mappings?
Not yet. A good test of shared mmap coherency is a recent samba
(2.2 and above) that uses tdb. Tdb relies on shared mmaps heavily and
uncovered the bug when running on a dual
Anton Blanchard <[EMAIL PROTECTED]> writes:
>
>
> > At least for sparc it's already supported. Right now I don't feel like
> > looking into the 2.4 solution but checkout srmmu_vac_update_mmu_cache in
> > the 2.2 kernel.
>
> I killed that hack now that we align all shared mmaps to the same
Anton Blanchard [EMAIL PROTECTED] writes:
At least for sparc it's already supported. Right now I don't feel like
looking into the 2.4 solution but checkout srmmu_vac_update_mmu_cache in
the 2.2 kernel.
I killed that hack now that we align all shared mmaps to the same virtual
Hi,
Where do you do this? And how do you handle the case of aliases with kseg,
the giant kernel mapping.
Aliases between user and kernel mappings of a page are handled by
flush_page_to_ram the old interface) or {copy,clear}_user_page,
flush_dcache_page and update_mmu_cache (new interface).
Did you find any software that breaks due to the additional restriction
on the virtual addresses of mappings?
Not yet. A good test of shared mmap coherency is a recent samba
(2.2 and above) that uses tdb. Tdb relies on shared mmaps heavily and
uncovered the bug when running on a dual
On Mon, Jan 15, 2001 at 10:16:57AM -0700, Eric W. Biederman wrote:
> Heck if we wanted to we could even lie about PAGE_SIZE, and say it was huge.
> I'd have to have a clear example before I give it up that easily.
> mmap has never allowed totally arbitrary offsets, and mmap(MAP_FIXED)
> is
Ralf Baechle <[EMAIL PROTECTED]> writes:
> On Mon, Jan 15, 2001 at 01:41:06AM -0700, Eric W. Biederman wrote:
>
> (Cc list truncated since probably not so many people do care ...)
>
> > shared mmap. This is the important one. Since we have a logical
> > backing store this is easy to handle.
Ralf Baechle wrote:
> > mremap. Linux specific but pretty much the same as mmap, but easier.
> > We just enforce that the virtual address of the source of mremap,
> > and the destination of mremap match on VIRT_INDEX_BITS.
>
> Correct and as mremap doesn't take any address argument we won't
On Mon, Jan 15, 2001 at 11:53:40PM +1100, Anton Blanchard wrote:
> > At least for sparc it's already supported. Right now I don't feel like
> > looking into the 2.4 solution but checkout srmmu_vac_update_mmu_cache in
> > the 2.2 kernel.
>
> I killed that hack now that we align all shared mmaps
> At least for sparc it's already supported. Right now I don't feel like
> looking into the 2.4 solution but checkout srmmu_vac_update_mmu_cache in
> the 2.2 kernel.
I killed that hack now that we align all shared mmaps to the same virtual
colour :)
Anton
-
To unsubscribe from this list:
Hi,
> shared mmap. This is the important one. Since we have a logical
> backing store this is easy to handle. We just enforce that the
> virtual address in a process that we mmap something to must match the
> logical address to VIRT_INDEX_BITS. The effect is the same as a
> larger page
On Mon, Jan 15, 2001 at 01:41:06AM -0700, Eric W. Biederman wrote:
(Cc list truncated since probably not so many people do care ...)
> shared mmap. This is the important one. Since we have a logical
> backing store this is easy to handle. We just enforce that the
> virtual address in a
Ralf Baechle <[EMAIL PROTECTED]> writes:
> On Fri, Jan 12, 2001 at 09:10:54AM -0700, Eric W. Biederman wrote:
>
> > > Having a reverse mappings is the least sucky way to handle virtual aliases
> > > of certain types of MIPS caches.
> >
> > Hmm. I would think that increasing the logical page
Ralf Baechle [EMAIL PROTECTED] writes:
On Fri, Jan 12, 2001 at 09:10:54AM -0700, Eric W. Biederman wrote:
Having a reverse mappings is the least sucky way to handle virtual aliases
of certain types of MIPS caches.
Hmm. I would think that increasing the logical page size in the
Hi,
shared mmap. This is the important one. Since we have a logical
backing store this is easy to handle. We just enforce that the
virtual address in a process that we mmap something to must match the
logical address to VIRT_INDEX_BITS. The effect is the same as a
larger page size
At least for sparc it's already supported. Right now I don't feel like
looking into the 2.4 solution but checkout srmmu_vac_update_mmu_cache in
the 2.2 kernel.
I killed that hack now that we align all shared mmaps to the same virtual
colour :)
Anton
-
To unsubscribe from this list: send
On Mon, Jan 15, 2001 at 11:53:40PM +1100, Anton Blanchard wrote:
At least for sparc it's already supported. Right now I don't feel like
looking into the 2.4 solution but checkout srmmu_vac_update_mmu_cache in
the 2.2 kernel.
I killed that hack now that we align all shared mmaps to the
Ralf Baechle wrote:
mremap. Linux specific but pretty much the same as mmap, but easier.
We just enforce that the virtual address of the source of mremap,
and the destination of mremap match on VIRT_INDEX_BITS.
Correct and as mremap doesn't take any address argument we won't break
any
Ralf Baechle [EMAIL PROTECTED] writes:
On Mon, Jan 15, 2001 at 01:41:06AM -0700, Eric W. Biederman wrote:
(Cc list truncated since probably not so many people do care ...)
shared mmap. This is the important one. Since we have a logical
backing store this is easy to handle. We just
On Mon, Jan 15, 2001 at 10:16:57AM -0700, Eric W. Biederman wrote:
Heck if we wanted to we could even lie about PAGE_SIZE, and say it was huge.
I'd have to have a clear example before I give it up that easily.
mmap has never allowed totally arbitrary offsets, and mmap(MAP_FIXED)
is highly
23 matches
Mail list logo
