~shrik3

~shrik3/test

Last active a month ago

~shrik3/rustubs

Last active 2 months ago

~shrik3/vnil-devel

Last active 2 months ago

~shrik3/srht-test-mailinglist

Last active 2 months ago

~shrik3/syswiki

Last active 2 months ago

~shrik3/public-inbox

Last active 2 months ago

~shrik3/aarch64-paging

Last active 4 months ago
View more

Recent activity

Re: [PATCH aerc v3] vaxis: update to 0.9.2 2 days ago

From Tianhao Wang to ~rjarry/aerc-devel

On Mon Jun 17, 2024 at 5:04 PM CEST, Tim Culverhouse wrote:
> Fixes several behind the scenes issues, but notably addresses scrolling
> of CJK characters in the terminal widget as well as wrapping of wide
> characters
>
> Reported-by: Tianhao Wang <shrik3@mailbox.org>
> Reported-by: ~runxiyu
> Signed-off-by: Tim Culverhouse <tim@timculverhouse.com>
> ---
> v3: Fix an issue v0.9.1 created regarding wrapping of text 
>
>  go.mod | 2 +-
>  go.sum | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)

Re: Character width detection with CJK text 4 days ago

From Tianhao Wang to ~rjarry/aerc-devel

On Sat Jun 15, 2024 at 5:54 PM CEST, Runxi Yu wrote:
> I was reading an email with interwoven English and Chinese via `aerc`
> and I noticed that CJK text (which is usually double the width of latin
> characters) is handled incorrectly. If I have a line full of `测试`
> proceeded a blank line followed by lines of `AAAAAA`, and I scroll down,
> sometimes the blank line will have ghost `A`s floating around, usually
> aligned with the right half of each CJK character.
> [...]
> Screencast: https://www.andrewyu.org/aerc.mkv (link may expire)
> Demo file: https://paste.sr.ht/blob/838a040bcd13a511a88e3910c4eeba7927f68058

Hi,

I think the is the same issue I reported earlier..

[PATCH] epoll: use repr(packed) for EpollEvent 26 days ago

From to ~quark/QuarkContainer

From: Tianhao Wang <shrik3@mailbox.org>

otherwise it may cause alignment issue

Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
Suggested-by: Yiliang Dong  <dongyiliangsteven@163.com>
---
 qlib/kernel/kernel/epoll/epoll.rs | 2 ++
 qlib/linux_def.rs                 | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/qlib/kernel/kernel/epoll/epoll.rs b/qlib/kernel/kernel/epoll/epoll.rs
index 5094f678..2e922ad4 100644
--- a/qlib/kernel/kernel/epoll/epoll.rs
[message trimmed]

Re: HYPERCALL_MMIO_BASE a month ago

From Tianhao Wang to ~quark/QuarkContainer

On Sun May 19, 2024 at 11:41 PM CEST, Yulin Sun wrote:
> I see there is one page HYPERCALL_MMIO_BASE is mapped in physical
> address space. But I see the memory range is not allocated in the
> kvm_userspace_memory_region.
>
> So is this by intention?

this is intentional. This page is mapped, but not backed by any host
memory. When this (one page) memory is accessed, it will trigger a
KVM_EXIT with MMIO read or write. You have to map it in guest pagetable
otherwise it would be a pagefault exception instead of a MMIO.

The Hypercall ID is calculated from addr - HYPERCALL_MMIO_BASE.

Re: mprotect syscall no longer writes to PTE flags? a month ago

From Tianhao Wang to ~quark/QuarkContainer

On Tue May 14, 2024 at 4:00 PM CEST, Yulin Sun wrote:
> Yes. When mprotect doing RO-->RW change, if we change pagetable flags, the CoW
> process will be disabled. For example, for private mapping of readonly file,
> when change to RW pagetable flags, the system will try to write the file and
> system will crash.
>

I intuitively think ... MProtect operation on a RO page should be treated as a
COW event as well, i.e. allocate/copy the child page before applying PTE flag
changes to either parent or child.

Also, if a process is requesting RO->RW, it  would very likely do write to that
memory afterwards, and COW would be triggered anyways. Why not proactively do
the COW upon RO->RW sys_mprotect calls?

Re: Armdev rebase - vdso makefile a month ago

From Tianhao Wang to ~quark/QuarkContainer

On Wed May 15, 2024 at 12:39 AM CEST, Christo Bita wrote:
> Name of linker-script for x86_64 hosts matches only amd machines.

Thanks! btw. perhaps try to send patches inline, i.e. simply use git send-email.
IMO it's easier than using attachments. it's also easier to review and comment.
(for this one thought it's fine because this patch is trivial)

wth

[PATCH] (local) clear PAN for armv8.4+ a month ago

From to ~quark/QuarkContainer

From: Tianhao Wang <shrik3@mailbox.org>

newer arm64 archs add PAN (Privilege Access Never) bit in the pstate
which prevents the kernel (el1) from accessing user (el0) memory. Full
support is WIP. As a temporary workaround we simply clear the PAN in the
qkernel.

Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
---
 qkernel/Cargo.toml                    |  4 ++++
 qkernel/aarch64-qkernel.json          |  2 +-
 qlib/kernel/threadmgr/task_usermem.rs | 12 ++++++++++++
 3 files changed, 17 insertions(+), 1 deletion(-)
[message trimmed]

Re: merging arm branch; regression introduced by OpenAt optimization a month ago

From Tianhao Wang to ~quark/QuarkContainer

> As far as I can tell, the regression is caused by PR #1029 in the main [1]
> merge commit id: 8e95ebdc6508ff95aafe98d0e2cb4c0d5af4ba94
>
> [1] https://github.com/QuarkContainer/Quark/pull/1029/

I'll drop the OpenAt optimization for aarch64 for the moment. I'll track this in
an issue. Let's get things merged first, this is blocking.

wth.

Re: merging arm branch; regression 2, memory leak, more info a month ago

From Tianhao Wang to ~quark/QuarkContainer

On Mon May 13, 2024 at 12:37 PM CEST, Tianhao Wang wrote:
>
> A second regression I can find is memory leak:
>
> to reproduce: run busybox sh, then run the some programs many times, e.g. 50
> times ls. We will hit either an OOM, or overflow in mm [1].
>
> I have a feeling that this comes from the nvidia addition, as we have extra
> mappings that may not be handled correctly in the arm branch. I don't have time
> to confirm this though. Testing is appreciated.
>
> wth
>
> ---

Re: merging arm branch; regression introduced by OpenAt optimization a month ago

From Tianhao Wang to ~quark/QuarkContainer

On Mon May 13, 2024 at 1:51 PM CEST, Yulin Sun wrote:
> The background of the PR is as below.
>
> In Quark file system virtualization, multiple guest user fds will be mapped
> to one host fd, i.e. for the same file in the host file system, no matter
> how many times opened by guest application, QVisor only opens the host file
> one time.
>
> Before the PR, when user application open one file, no matter user open the
> file ReadOnly or Read/Write, QVisor will open the host file with maximum
> permissions, i.e. Read/Write to simplify the SysOpen process.
>
> Docker will use a layered file system for the docker image files. When
> opening the file with R/W, the layered file system will do the Copy on