On Mon, 2025-01-20 at 06:28 +0100, Florian Weimer wrote:
> * Xi Ruoyao:
>
> > On Wed, 2024-12-11 at 11:23 +0100, Christian Brauner wrote:
> > > On Tue, Dec 10, 2024 at 07:14:07PM +0100, Florian Weimer wrote:
> > > > * Aleksa Sarai:
> > > >
> >
aviors
> > valid.
> I think in general both behaviors are valid but I would consider zeroing
> the unknown parts of the provided buffer to be the safer option. And all
> newer extensible struct system calls do that.
Florian,
So should we drop the test before Glibc-2.41 release? I'm seeing the
failure during my machine test.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
From: Fangrui Song
glibc added support for DT_GNU_HASH in 2006 and DT_HASH has been
obsoleted for more than one decade in many Linux distributions.
Many vDSOs support DT_GNU_HASH. This patch adds selftests support.
Signed-off-by: Fangrui Song
Tested-by: Xi Ruoyao
Signed-off-by: Xi Ruoyao
. This patch adds selftests support.
> >
> > Signed-off-by: Fangrui Song
> > Tested-by: Xi Ruoyao
> > --
> > Changes from v1:
> > * fix style of a multi-line comment. ignore false positive suggestions from
> > checkpath.pl: `ELF(W
On Sun, 2024-06-23 at 14:04 +0200, Mateusz Guzik wrote:
> On Sun, Jun 23, 2024 at 3:22 AM Xi Ruoyao wrote:
> >
> > On Sun, 2024-06-23 at 03:07 +0200, Mateusz Guzik wrote:
> > > On Sun, Jun 23, 2024 at 2:59 AM Xi Ruoyao
> > > wrote:
> > > >
>
On Sun, 2024-06-23 at 03:07 +0200, Mateusz Guzik wrote:
> On Sun, Jun 23, 2024 at 2:59 AM Xi Ruoyao wrote:
> >
> > On Sat, 2024-06-22 at 15:41 -0700, Linus Torvalds wrote:
> >
> > > I do think that we should make AT_EMPTY_PATH with a NULL path
> > > &quo
gt; disgusting.
The problem is we don't have fstat() for LoongArch, and it'll be
unusable on all 32-bit arch after 2037.
And Arnd hates the idea adding fstat() for LoongArch because there would
be one more 32-bit arch broken in 2037.
Or should we just add something like "fstat_2037()"?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
i Hiramatsu
Cc: Alejandro Colomar
Cc: Arnd Bergmann
Cc: Huacai Chen
Cc: Xuerui Wang
Cc: Jiaxun Yang
Cc: Icenowy Zheng
Cc: linux-fsde...@vger.kernel.org
Cc: linux-trace-ker...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: loonga...@lists.linux.dev
Cc: linux-kernel@vger.kernel.org
Signed-of
in all these years).
I do agree maybe it's the time to move away from MIPS legacy and be more
similar to RISC-V etc now...
In Glibc we can condition __SYSCALL_CLOBBERS with #if
__LINUX_KERNEL_VERSION > xxx to take the advantage.
Huacai, Xuerui, how do you think?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
PT_R12). Not sure if it's worthy
to violate Huacai's "keep things simple" aspiration though.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
SR method since the
> small CSR ID range. However it is easy for cpucfg. Here I doubt whether
> you really know about LoongArch LVZ.
It's unfair to accuse the others for not knowing about LVZ considering
the lack of public documentation.
--
Xi Ruoyao
School of Aerospace Science an
On 2021-03-30 15:24 +0200, Christian König wrote:
> Am 30.03.21 um 15:23 schrieb Dan Horák:
> > On Tue, 30 Mar 2021 21:09:12 +0800
> > Xi Ruoyao wrote:
> >
> > > On 2021-03-30 21:02 +0800, Xi Ruoyao wrote:
> > > > On 2021-03-30 14:55 +0200, Christian Kön
On 2021-03-30 21:02 +0800, Xi Ruoyao wrote:
> On 2021-03-30 14:55 +0200, Christian König wrote:
> >
> > I rather see this as a kernel bug. Can you test if this code fragment
> > fixes your issue:
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
On 2021-03-30 14:55 +0200, Christian König wrote:
> Am 30.03.21 um 14:04 schrieb Xi Ruoyao:
> > On 2021-03-30 03:40 +0800, Xi Ruoyao wrote:
> > > On 2021-03-29 21:36 +0200, Christian König wrote:
> > > > Am 29.03.21 um 21:27 schrieb Xi Ruoyao:
> > > > &g
On 2021-03-30 03:40 +0800, Xi Ruoyao wrote:
> On 2021-03-29 21:36 +0200, Christian König wrote:
> > Am 29.03.21 um 21:27 schrieb Xi Ruoyao:
> > > Hi Christian,
> > >
> > > I don't think there is any constraint implemented to ensure `num_entries %
>
On 2021-03-29 21:36 +0200, Christian König wrote:
> Am 29.03.21 um 21:27 schrieb Xi Ruoyao:
> > Hi Christian,
> >
> > I don't think there is any constraint implemented to ensure `num_entries %
> > AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0`. F
->last - mapping->start + 1) %
AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0, then we should replace "AMDGPU_GPU_PAGE_MASK"
in "validate the parameters" with "PAGE_MASK".
I tried it and it broke userspace: Xorg startup fails with EINVAL with this
change.
On 2021-03-30 02
On 2021-03-30 02:21 +0800, Xi Ruoyao wrote:
> On 2021-03-29 20:10 +0200, Christian König wrote:
> > You need to identify the root cause of this, most likely start or last
> > are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
>
> I printk'ed the value of start & la
-/issues/1549
> > > > Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
> > > > Reported-by: Xi Ruoyao
> > > > Reported-by: Dan Horák
> > > > Cc: sta...@vger.kernel.org
> > > > Signed-off-by: Xi Ruoyao
> > > &
a" from gtk3-demo (which just renders a triangle with GL)
under Xorg, on MIPS64. See the BugLink.
> Christian.
>
> >
> > BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549
> > Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
&g
Hi Greg and Nick,
On 2021-02-11 10:46 -0800, Nick Desaulniers wrote:
> On Thu, Feb 11, 2021 at 5:55 AM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Feb 11, 2021 at 09:32:03PM +0800, Xi Ruoyao wrote:
> > > Hi all,
> > >
> > > The latest GNU assembler
reloc->sym = find_symbol_containing(insn_sec,
> - insn_off - 1);
> - }
> - if (!reloc->sym) {
> - WARN("missing symbol for insn at offset 0x%lx\n",
> - insn_off);
> - return -1;
> - }
> -
> - reloc->addend = insn_off - reloc->sym->offset;
> + insn_to_reloc_sym_addend(insn_sec, insn_off, reloc);
> + if (!reloc->sym) {
> + WARN("missing symbol for insn at offset 0x%lx",
> + insn_off);
> + return -1;
> }
>
> reloc->type = R_X86_64_PC32;
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On 2019-07-10 17:13 +0200, Thomas Gleixner wrote:
> Something like the below. Builds and boots, must be perfect.
>
> Thanks,
>
> tglx
Tested-by: Xi Ruoyao
> 8<
>
> arch/x86/include/asm/processor.h |1
> arch/x86/incl
me time though, it sort of destroys the original intent of Kees'
> patch, right? The exploits will just have to call static_key_disable()
> prior to calling native_write_cr4() again, and the protection is gone.
I think I should do some study and try to understand the full story of Kees'
change...
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
seems the MMU (I guess ?) allows to read it, but disallows to write it:
"supervisor write access in kernel mode".
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
R0 and CR4 commits can "fix" it
(apprently).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
t; + mask = (X86_CR4_SMEP | X86_CR4_SMAP);
> cr4_pinned_bits = this_cpu_read(cpu_tlbstate.cr4) & mask;
> static_key_enable(&cr_pinning.key);
> }
I'll try it.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Introduce a control file memory.watermark showing the watermark
consumption of the cgroup and its descendants, in bytes.
Signed-off-by: Xi Ruoyao
---
mm/memcontrol.c | 12
1 file changed, 12 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index ba9138a4a1de
On 2018-06-17 18:16 +0800, Xi Ruoyao wrote:
> In scripts/Makefile.build, there are two mismatched if/endif pairs.
> They stop the generation of orc unwind table if CONFIG_FTRACE_MCOUNT_RECORD
> is not set. dmesg complains:
Duplication of patch 10455267 in patchwork. Sorry for noise
pairs.
Signed-off-by: Xi Ruoyao
---
scripts/Makefile.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 34d9e9ce97c2..16509a038d77 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -239,6 +239,7
probe them.
To resolve this, specify generic Bluetooth device in the USB device table by
matching Interface Descriptor, to probe all devices with Bluetooth interface
including these "Miscellaneous" ones.
Signed-off-by: Xi Ruoyao
---
The Bluetooth USB driver changed a lot since 4.1 relea
probe them.
To resolve this, specify generic Bluetooth device in the USB device table by
matching Interface Descriptor, to probe all devices with Bluetooth interface
including these "Miscellaneous" ones.
Signed-off-by: Xi Ruoyao
---
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1
atch, I'll send a patch which would modify the
generic USB BT device
entry in the device table to resolve this. You can choose one of the two
patches since
they both make the BT works at least on my tablet.
If there are other alternate patches, I can help to test them.
--
Xi Ruoyao
Scho
which has RTL8723AU USB device, with product ID 0bda:1724.
Signed-off-by: Xi Ruoyao
---
drivers/bluetooth/btusb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..dd87623 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers
On 06/21/2015 12:11 PM, Xi Ruoyao wrote:
On 06/21/2015 09:12 AM, Larry Finger wrote:
On 06/20/2015 04:58 PM, Marcel Holtmann wrote:
Hi Xi,
In 'commit a2698a9bf9b0 ("Bluetooth: btusb: Add Realtek
8723A/8723B/8761A/8821A support"), support of some Realtek
devices was added
h support in the Lenovo Ideapad Yoga 13
which has RTL8723AU USB device, with product ID 0bda:1724.
Signed-off-by: Xi Ruoyao
---
drivers/bluetooth/btusb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..dd87623 100644
-
obe them at all.
To fix this, add four entries in the device table btusb_table,
based on code from <https://github.com/lwfinger/rtl8723au_bt>
('new' branch).
This enables bluetooth support in the Lenovo Ideapad Yoga 13
which has RTL8723AU USB device, with product ID 0bda:1724.
Si
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
On 03/26/2015 at 03:40 AM, Josh Boyer wrote:
drm-Fixup-racy-refcounting-in-plane_force_disable.patch
drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
and this patch:
I hide the patch since it has been managled by Thunderbird.
(BTW, who
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
在 03/26/2015 03:40 AM, Josh Boyer 写道:
Sorry for these Chinese charactor. Thunderbird generated them
and I forgot to change.
On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
Yeah that fail looks like we're freeing an fb that'
break;
}
which is a mash-up of:
"drm/i915: Fix atomic state when reusing the firmware fb"
and
"drm/i915: Fixup legacy plane->crtc link for initial fb config"
which you just sent out.
I think that covers everything.
josh
I've g
On 03/25/2015 at 10:56 PM, Xi Ruoyao wrote:
On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter wrote:
commit f55548b5af87ebfc586ca75748947f1c1b1a4a52
Author: Damien Lespiau
Date: Thu
-16.
So, Daniel and Stephen please check it and end this mess...
It's annoying to see my code caused so much trouble. I didn't test my code
with a HDMI device or I should've found this trouble before commiting. I
apologize for that again.
--
Xi Ruoyao
School of Aerospace Scien
:32 AM, Daniel Vetter wrote:
On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer wrote:
Xi Ruoyao (1):
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
Turns out to be that commit.
git bisect start 'd
to use drm_atomic_set_fb_for_plane since the logic of
Matt's code is duplicated with drm_atomic_set_fb_for_plane.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
On 03/12/2015 04:28 PM, Jani Nikula wrote:
On Thu, 12 Mar 2015, Xi Ruoyao wrote:
In intel_crtc_page_flip, intel_display.c, the code changed the framebuffer
assigned to plane crtc->primary by
crtc->primary->fb = fb;
However, it forgot to change crtc->primary->state->fb
>state->fb
to get the framebuffer assigned to crtc->primaty. Then a framebuffer
object can be unpinned twice and a kernel BUG will be produced in i915_gem.c.
So, update crtc->primary->state->fb in intel_display.c using
drm_atomic_set_fb_for_plane to fix the BUG.
Signed-off
>state->fb
to get the framebuffer assigned to crtc->primaty. Then a framebuffer
object can be unpinned twice and a kernel BUG will be produced in
i915_gem.c.
So, update crtc->primary->state->fb in intel_display.c using
drm_atomic_set_fb_for_plane to fix the BUG.
Signed-off-b
47 matches
Mail list logo
