Re: [PATCH -next] kernel/cgroup: Remove the unused variable climit

On 1/14/25 1:28 AM, Jiapeng Chong wrote: Variable climit is not effectively used, so delete it. kernel/cgroup/dmem.c:302:23: warning: variable ‘climit’ set but not used. Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=13512 Signed-off-by: Jiapeng Chong --- ke

Re: RFR: 8339113: AccessFlags can be u2 in metadata [v13]

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore wrote: >> Please review this change that makes AccessFlags and modifier_flags u2 types >> and removes the last remnants of Hotspot adding internal access flags. This >> change moves AccessFlags and modifier_flags in Klass to alignment gaps >>

Re: RFR: 8339113: AccessFlags can be u2 in metadata [v13]

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore wrote: >> Please review this change that makes AccessFlags and modifier_flags u2 types >> and removes the last remnants of Hotspot adding internal access flags. This >> change moves AccessFlags and modifier_flags in Klass to alignment gaps >>

Re: [PATCH v4 2/9] sched/isolation: document HK_TYPE housekeeping option

On 12/17/24 1:29 PM, Daniel Wagner wrote: The enum is a public API which can be used all over the kernel. This warrants a bit of documentation. Signed-off-by: Daniel Wagner --- include/linux/sched/isolation.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/linux/

Re: RFR: 8339113: AccessFlags can be u2 in metadata [v13]

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore wrote: >> Please review this change that makes AccessFlags and modifier_flags u2 types >> and removes the last remnants of Hotspot adding internal access flags. This >> change moves AccessFlags and modifier_flags in Klass to alignment gaps >>

RE: The new SE four

. Sent from my quantum phone!! > On Dec 31, 2024, at 11:18 PM, Dennis Long wrote: > > It is going to be one awesome phone. > > -Original Message- > From: viphone@googlegroups.com On Behalf Of > Carolyn Arnold > Sent: Tuesday, December 31, 2024 8:05 PM > T

RE: Audio Ducking.

Not only that have you adjusted the amount? The higher the amount on ducking amount the more it will duck. -Original Message- From: viphone@googlegroups.com On Behalf Of Carolyn Arnold Sent: Tuesday, December 31, 2024 8:02 PM To: viphone@googlegroups.com Subject: RE: Audio Ducking. I

RE: The new SE four

On Dec 8, 2024, at 9:00 AM, Dennis Long wrote:  This comes from Mark Gurman’s power on newsletter. Q: How do you think the new iPhone SE will be received? A: It’s been a few years since

[kde] [Bug 498079] some app make my mobile slow

https://bugs.kde.org/show_bug.cgi?id=498079 Long Sơn Hải changed: What|Removed |Added URL||https://vinascaffold.com/ -- You are receiving

[kde] [Bug 498079] New: some app make my mobile slow

https://bugs.kde.org/show_bug.cgi?id=498079 Bug ID: 498079 Summary: some app make my mobile slow Classification: I don't know Product: kde Version: unspecified Platform: Other OS: Other Status: REPORTED

doc: flow6 label should be numeric op, not bitmask

Hi, In User's Guide Section 6.6 (Protocol :: Static) [0], IPv6 flowspec's flow label component is documented as: > label bitmask-match > >Set a 20-bit bitmask for matching Flow Label field in packets (e.g. >label 0x8e5/0x8e5). However in RFC 8956 (Dissemination of Flow Specification R

Bug#1089574: blender:FTBFS:build failure on riscv (error: #error Please add support for your architecture in BLI_build_config.h)

Hi Yue, Seems you can try to upstream this patch to https://projects.blender.org/blender/blender/pulls. Cheers, Eric On Mon, 9 Dec 2024 14:43:11 +0800 Yue Gui wrote: Source: blender Version: 4.3.0+dfsg-1 Severity: serious Tags: FTBFS, patch User: debian-ri...@lists.debian.org Usertags: ris

Bug#1089574: blender:FTBFS:build failure on riscv (error: #error Please add support for your architecture in BLI_build_config.h)

Hi Yue, Seems you can try to upstream this patch to https://projects.blender.org/blender/blender/pulls. Cheers, Eric On Mon, 9 Dec 2024 14:43:11 +0800 Yue Gui wrote: Source: blender Version: 4.3.0+dfsg-1 Severity: serious Tags: FTBFS, patch User: debian-ri...@lists.debian.org Usertags: ris

Bug#1089574: blender:FTBFS:build failure on riscv (error: #error Please add support for your architecture in BLI_build_config.h)

Hi Yue, Seems you can try to upstream this patch to https://projects.blender.org/blender/blender/pulls. Cheers, Eric On Mon, 9 Dec 2024 14:43:11 +0800 Yue Gui wrote: Source: blender Version: 4.3.0+dfsg-1 Severity: serious Tags: FTBFS, patch User: debian-ri...@lists.debian.org Usertags: ris

Re: RFR: 8339113: AccessFlags can be u2 in metadata [v5]

On Fri, 20 Dec 2024 13:17:17 GMT, Coleen Phillimore wrote: >> Please review this change that makes AccessFlags and modifier_flags u2 types >> and removes the last remnants of Hotspot adding internal access flags. This >> change moves AccessFlags and modifier_flags in Klass to alignment gaps >

Re: RFR: 8339113: AccessFlags can be u2 in metadata [v2]

On Thu, 19 Dec 2024 12:52:34 GMT, Coleen Phillimore wrote: >> Please review this change that makes AccessFlags and modifier_flags u2 types >> and removes the last remnants of Hotspot adding internal access flags. This >> change moves AccessFlags and modifier_flags in Klass to alignment gaps >

Re: [blind-gamers] Looking for old games for the Blind

Chris email me off list dennisl1...@gmail.com From: blind-gamers@groups.io On Behalf Of Chris via groups.io Sent: Sunday, December 15, 2024 4:22 AM To: blind-gamers@groups.io Subject: Re: [blind-gamers] Looking for old games for the Blind Hello Sirajudin,

RE: [EXTERNAL] Re: [PATCH] hv_netvsc: Set device flags for properly indicating bonding

ensively when looking > > for master/slave devices. > > > > Make hv_netvsc properly setup those flags. > > > > Signed-off-by: Long Li > > Linux networking has evolved a patch work of flags to network devices but > never > really standardized on a way to express l

Re: [mailop] The "NEW" Outlook

Opinions are like arseholes, Graeme, everyone has one. Pete. > On 11 Dec 2024, at 17:21, Graeme Fowler via mailop wrote: > > Evening folks > > Small admin nit follows. > > On 11 Dec 2024, at 16:51, Marco Moock via mailop wrote: >> MS's slaves love that like they love any other privacy or s

[dspace-tech] Re: DSpace 7 & Symplectic Elements Integration

Dear Rachel, As far as I'm aware, for deposits the symplectic user you configure in DSpace needs to be a full Administrator as it uses a number of Administrator only API endpoints. Aside from the issues you raise you will also likely experience issues with workflow items if you try and constrai

Re: [mailop] Gmail emoji reactions

On Mon, Dec 9, 2024 at 2:25 AM Jaroslaw Rafa via mailop wrote: > Dnia 8.12.2024 o godz. 20:27:51 postfix--- via mailop pisze: > > FACT: languages are living bodies of conventions common to two or > > more individuals. Emojis are the glyphs of new languages in the > > making. I get to learn eve

From Mark Gurman's newsletter

This comes from Mark Gurman’s power on newsletter. Q: How do you think the new iPhone SE will be received? A: It’s been a few years since Apple last rolled out an iPhone SE, its budget-minded model. With the previous versions, Apple followed the same basic strategy: They were cheaper than a flagsh

[PATCH] cgroup/cpuset: Prevent leakage of isolated CPUs into sched domains

he way the boot time isolated CPUs are handled in test_cpuset_prs.sh to make sure that those isolated CPUs are really isolated instead of just skipping them in the tests. Fixes: ccac8e8de99c ("cgroup/cpuset: Fix remote root partition creation problem") Signed-off-by: Waiman Long --- ke

RE: [EXTERNAL] Re: [PATCH] hv_netvsc: Set device flags for properly indicating bonding

is to use the IFF_BONDING, as it is the closest representation of this relationship. Another way would be adding a new IFF flag (e.g. IFF_PERMSLAVE) to netdev_priv_flags. I feel this is not needed for this special use-case in netvsc. Thanks, Long

RE: [EXTERNAL] Re: [PATCH rdma-next 1/1] RDMA/mana_ib: Set correct device into ib

> Subject: Re: [EXTERNAL] Re: [PATCH rdma-next 1/1] RDMA/mana_ib: Set correct > device into ib > > On Wed, Nov 27, 2024 at 07:46:39PM +, Long Li wrote: > > > > > > > I think Konstantin's suggestion makes sense, how about we do > > > >

Re: Token Assignment Strategy for Single-Token Nodes with Multi-Datacenter

Thanks Jeff for the inspiring reply!

RE: [EXTERNAL] Re: [PATCH rdma-next 1/1] RDMA/mana_ib: Set correct device into ib

return res; > > > > > > > > > is_eth_port_of_netdev_filter() should not return true if this netdev > > > is a bonded slave. In this case, only use the address of its bonded > > > master. > > > > > Right. This change makes sense to me. > > I

Re: [PATCH] test: raise fast test timeout to 60s on RISC-V

On 27/11/2024 04:29, David Marchand wrote: You can extend the timeout via the multiplier option (default timeout of 10s * multiplier). So in your case: $ meson test -C --suite fast-tests -t 6 I hope the RISC-V specific extended timeout could be upstreamed though, in this way we won't need to

[PATCH] test: raise fast test timeout to 60s on RISC-V

al 15 SIGTERM ``` On HiFive Unmatched, the longest test takes 53 seconds: ``` 37/77 DPDK:fast-tests / lpm6_autotest OK 53.29s ``` Raising timeout to 60s on RISC-V target will help test effectiveness on it. Signed-off-by: Eric Long --- .mailmap| 1 + app

Bug#1087945: RFS: mimic/0.6.0+ds-1 [ITP] -- eBPF UDP -> TCP obfuscator

Hi mentors, I fixed some issues regarding DKMS packaging and Vcs-* field pointing to upstream (I package Mimic in the upstream too, and I forgot to modify the fields). A new version is available at mentors.d.o: dget -x https://mentors.debian.net/debian/pool/main/m/mimic/mimic_0.6.1+ds-1.ds

Bug#1087945: RFS: mimic/0.6.0+ds-1 [ITP] -- eBPF UDP -> TCP obfuscator

Hi mentors, I fixed some issues regarding DKMS packaging and Vcs-* field pointing to upstream (I package Mimic in the upstream too, and I forgot to modify the fields). A new version is available at mentors.d.o: dget -x https://mentors.debian.net/debian/pool/main/m/mimic/mimic_0.6.1+ds-1.ds

Bug#1087945: RFS: mimic/0.6.0+ds-1 [ITP] -- eBPF UDP -> TCP obfuscator

Hi Phil, Just want to say thank you to you and your test script; it really helps for a new contributor like me :) Cheers, Eric On 23/11/2024 03:25, Phil Wyett wrote: Control: tags -1 +confirmed Eric, Preamble... Thank you for taking the time to prepare this package and your contribution t

Re: [PATCH v2] kasan: Make kasan_record_aux_stack_noalloc() the default behaviour

oc() behaviour default as kasan_record_aux_stack(). [bigeasy: Dressed the diff as patch. ] Reported-by: syzbot+39f85d612b7c20d8d...@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67275485.050a0220.3c8d68.0a37@google.com Acked-by: Waiman Long Reviewed-by: Andrey Konovalov Review

Re: RFR: 8344168: Change Unsafe base offset from int to long

On Fri, 15 Nov 2024 01:05:10 GMT, ExE Boss wrote: >> Doesn't this break any apps that use these offsets? Aren't these fields >> part of the public API of Unsafe, so changing them requires a CSR? > > @dean-long >> Doesn't this break any apps that use

Bug#1087945: RFS: mimic/0.6.0+ds-1 [ITP] -- eBPF UDP -> TCP obfuscator

Control: tags -1 -moreinfo Hi mentors, I've fixed lintian warnings and other issues listed in the mentors.d.n package page. The autopkgtest failure from Phil('s bot) is false positive due to server issue (no space left on device). Therefore I think it's ready for sponsorship. Please feel free

Bug#1087945: RFS: mimic/0.6.0+ds-1 [ITP] -- eBPF UDP -> TCP obfuscator

Control: tags -1 -moreinfo Hi mentors, I've fixed lintian warnings and other issues listed in the mentors.d.n package page. The autopkgtest failure from Phil('s bot) is false positive due to server issue (no space left on device). Therefore I think it's ready for sponsorship. Please feel free

Re: [Wien] NEC01 charge leakage too large

occurred in MIXER, thus you should not only provide the "stop > Error" statement, but check*.error files and *scfm, *outputm (m for > mixer) and *dayfile. > You may find more information which may give you a hint what was wrong. > > > > Am 12.11.2024 um 04:25 schrie

RE: [PATCH rdma-next 1/1] RDMA/mana_ib: Set correct device into ib

(); return res; is_eth_port_of_netdev_filter() should not return true if this netdev is a bonded slave. In this case, only use the address of its bonded master. Thanks, Long

Bug#1087945: RFS: mimic/0.6.0+ds-1 [ITP] -- eBPF UDP -> TCP obfuscator

Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: i...@hack3r.moe Dear mentors, I am looking for a sponsor for my package "mimic": * Package name : mimic Version : 0.6.0+ds-1 Upstream contact : Eric Long * URL : https://github.com/hack

Bug#1087945: RFS: mimic/0.6.0+ds-1 [ITP] -- eBPF UDP -> TCP obfuscator

Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: i...@hack3r.moe Dear mentors, I am looking for a sponsor for my package "mimic": * Package name : mimic Version : 0.6.0+ds-1 Upstream contact : Eric Long * URL : https://github.com/hack

Ecolog-L Summer internship opportunity: UChicago Data Science Institute Summer Lab

Applications for the 2025 University of Chicago Data Science University Summer Lab are now open. In this paid summer research program, undergraduate students and Chicago-area high schoolers are paired with faculty mentors to conduct research i

Bug#1087937: ITP: mimic -- eBPF UDP -> TCP obfuscator

On 20/11/2024 22:46, Eric Long wrote: My own network setup heavily relies on it to hide my WireGuard tunnel traffic from ISP, and many others have shown interest in (or have already done) into theirs. have shown interest in integrating* Also include the message in the reopen control message

Bug#1087937: ITP: mimic -- eBPF UDP -> TCP obfuscator

On 20/11/2024 22:46, Eric Long wrote: My own network setup heavily relies on it to hide my WireGuard tunnel traffic from ISP, and many others have shown interest in (or have already done) into theirs. have shown interest in integrating* Also include the message in the reopen control message

Bug#1087937: ITP: mimic -- eBPF UDP -> TCP obfuscator

On Wed, 20 Nov 2024 14:52:22 + ba...@debian.org wrote: close 1087937 stop there is already an RFP RFP 869106 ITP 1087937 Hi Bart, It's a different package with different functionalities. Should I open a new ITP with a different name (say mimic-bpf), or reopen this and change its packag

Bug#1087937: ITP: mimic -- eBPF UDP -> TCP obfuscator

On Wed, 20 Nov 2024 14:52:22 + ba...@debian.org wrote: close 1087937 stop there is already an RFP RFP 869106 ITP 1087937 Hi Bart, It's a different package with different functionalities. Should I open a new ITP with a different name (say mimic-bpf), or reopen this and change its packag

Bug#1087937: ITP: mimic -- eBPF UDP -> TCP obfuscator

Package: wnpp Severity: wishlist Owner: Eric Long X-Debbugs-Cc: debian-devel@lists.debian.org, i...@hack3r.moe * Package name: mimic Version : 0.6.0 Upstream Contact: Eric Long * URL : https://github.com/hack3ric/mimic * License : GPL-2.0-only Programming

Bug#1087937: ITP: mimic -- eBPF UDP -> TCP obfuscator

Package: wnpp Severity: wishlist Owner: Eric Long X-Debbugs-Cc: debian-de...@lists.debian.org, i...@hack3r.moe * Package name: mimic Version : 0.6.0 Upstream Contact: Eric Long * URL : https://github.com/hack3ric/mimic * License : GPL-2.0-only Programming

Bug#1087937: ITP: mimic -- eBPF UDP -> TCP obfuscator

Package: wnpp Severity: wishlist Owner: Eric Long X-Debbugs-Cc: debian-de...@lists.debian.org, i...@hack3r.moe * Package name: mimic Version : 0.6.0 Upstream Contact: Eric Long * URL : https://github.com/hack3ric/mimic * License : GPL-2.0-only Programming

Re: [PATCH] kasan: Remove kasan_record_aux_stack_noalloc().

eric: introduce kasan_record_aux_stack_noalloc()") there. Right now task_work_add() is the only caller of kasan_record_aux_stack(). So it essentially make all its callers use the noalloc version of kasan_record_aux_stack(). Acked-by: Waiman Long include/linux/kasan.h |

Re: RFR: 8344168: Change Unsafe base offset from int to long [v2]

ort and CRC32C are >> still unfixed. >> >> @liach proposed the idea of ​​changing the Unsafe base offset to long, which >> is a complete solution to the Unsafe offset overflow. After discussing with >> @liach, I submitted this PR to implement @liach's idea. >

Re: RFR: 8344168: Change Unsafe base offset from int to long

> still unfixed. > > @liach proposed the idea of ​​changing the Unsafe base offset to long, which > is a complete solution to the Unsafe offset overflow. After discussing with > @liach, I submitted this PR to implement @liach's idea. Doesn't this break any apps tha

[frameworks-kio] [Bug 494994] Launching terminal based apps from launcher results in error if konsole isn't installed

https://bugs.kde.org/show_bug.cgi?id=494994 --- Comment #2 from Long Vu --- It is set as the default, if I have konsole installed kitty does open correctly when set. With the konsole packages uninstalled I run into the error. -- You are receiving this mail because: You are watching all bug

Re: [ccp4bb] acedrg error in gui, command line only cif no pdb output

the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1 --- Dr. Fei Long Structural Studies Division UKRI Laboratory of Molecular Biology Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge CB2 0QH UK Email:fl...@mrc

Re: [mailop] Not receiving messages from Gmail

> On 13 Nov 2024, at 13:28, Adriano Barbosa via mailop > wrote: > > Hi, > Anyone having issues in receiving (yes, receiving, not sending to) > emails from Gmail today? I can receive from other domains and from other > big ones like Microsoft and Apple, but only not from Gmail. > I tested sendi

[Wien] NEC01 charge leakage too large

c 1" with no other options. I did it, for both cases, but it's not helping. What else can I do to fix the too large charge leakage? Best regards, Long SrVO3.struct Description: Binary data MnO.struct Description: Binary data __

Re: [Wien] beginner's init_lapw error

dn't find a similar error description, > so I am seeking help here. > > I am not sure if it's something very basic (files, commands) that I > handled wrong, > or if there's any problem in my input file or even compiled anything wrong. > > Thanks for any

Re: [mailop] Reject "likely unsolicited" from Google to completely normal mail

> On 6 Nov 2024, at 20:52, Jaroslaw Rafa via mailop wrote: > > In addition to previous mail, I have just looked at Google Postmaster Tools. > It says that my user-reported spam rate is 0,0% (which is no surprise as I > send very few emails to Google at all), but the new "Compliance status" > da

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Mon, 28 Oct 2024 21:13:33 GMT, Patricio Chilano Mateo wrote: >> If preemption was cancelled, we skip over the cleanup. The native frames >> haven't been unwound yet. So when we call thaw, does it cleanup the native >> frames first, or does it copy the frames back on top of the existing fr

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Mon, 28 Oct 2024 21:13:33 GMT, Patricio Chilano Mateo wrote: >> If preemption was cancelled, we skip over the cleanup. The native frames >> haven't been unwound yet. So when we call thaw, does it cleanup the native >> frames first, or does it copy the frames back on top of the existing fr

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Mon, 28 Oct 2024 20:49:45 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382: >> >>> 2380: __ bind(after_transition); >>> 2381: >>> 2382: if (LockingMode != LM_LEGACY && method->is_object_wait0()) { >> >> It bothers me that we have to add a che

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Mon, 28 Oct 2024 20:49:45 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382: >> >>> 2380: __ bind(after_transition); >>> 2381: >>> 2382: if (LockingMode != LM_LEGACY && method->is_object_wait0()) { >> >> It bothers me that we have to add a che

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Mon, 28 Oct 2024 22:52:40 GMT, Coleen Phillimore wrote: >> When creating the bitmap, processing oops in an interpreter frame is done >> with `frame::oops_interpreted_do()` which already counts this extra oop for >> native methods. > > What are we counting now with MaskFillerForNativeFrame th

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Mon, 28 Oct 2024 22:52:40 GMT, Coleen Phillimore wrote: >> When creating the bitmap, processing oops in an interpreter frame is done >> with `frame::oops_interpreted_do()` which already counts this extra oop for >> native methods. > > What are we counting now with MaskFillerForNativeFrame th

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Mon, 28 Oct 2024 16:39:14 GMT, Coleen Phillimore wrote: >> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119: >> >>> 117: return mask.num_oops() >>> 118: + 1 // for the mirror oop >>> 119: + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Mon, 28 Oct 2024 16:39:14 GMT, Coleen Phillimore wrote: >> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119: >> >>> 117: return mask.num_oops() >>> 118: + 1 // for the mirror oop >>> 119: + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Sat, 26 Oct 2024 06:51:08 GMT, Richard Reingruber wrote: >> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555: >> >>> 1553: // Make VM call. In case of preemption set last_pc to the one we >>> want to resume to. >>> 1554: adr(rscratch1, resume_pc); >>> 1555: str(rscratch1, Addr

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Sat, 26 Oct 2024 06:51:08 GMT, Richard Reingruber wrote: >> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555: >> >>> 1553: // Make VM call. In case of preemption set last_pc to the one we >>> want to resume to. >>> 1554: adr(rscratch1, resume_pc); >>> 1555: str(rscratch1, Addr

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long wrote: >>> OK, so you're saying it's the stack adjustment that's the problem. It >>> sounds like there is code that is using rsp instead of last_Java_sp to >>> compute the frame boundary. Isn't that a

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long wrote: >>> OK, so you're saying it's the stack adjustment that's the problem. It >>> sounds like there is code that is using rsp instead of last_Java_sp to >>> compute the frame boundary. Isn't that a

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo wrote: >> OK, so you're saying it's the stack adjustment that's the problem. It >> sounds like there is code that is using rsp instead of last_Java_sp to >> compute the frame boundary. Isn't that a bug that should be fixed? I also >>

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo wrote: >> OK, so you're saying it's the stack adjustment that's the problem. It >> sounds like there is code that is using rsp instead of last_Java_sp to >> compute the frame boundary. Isn't that a bug that should be fixed? I also >>

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Tue, 29 Oct 2024 19:01:03 GMT, Patricio Chilano Mateo wrote: >>> One way to get rid of this would be to have c2 just set last_Java_pc too >>> along with last_Java_sp, so we don't need to push lr to be able to do >>> last_Java_sp[-1] to make the frame walkable. >> >> If that would solve the

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Tue, 29 Oct 2024 19:01:03 GMT, Patricio Chilano Mateo wrote: >>> One way to get rid of this would be to have c2 just set last_Java_pc too >>> along with last_Java_sp, so we don't need to push lr to be able to do >>> last_Java_sp[-1] to make the frame walkable. >> >> If that would solve the

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Mon, 28 Oct 2024 18:56:58 GMT, Patricio Chilano Mateo wrote: >> The issue with the c2 runtime stub on aarch64 (and riscv) is that >> cb->frame_size() doesn't match the size of the physical frame, it's short by >> 2 words. I explained the reason for that in the comment above. So for a >> re

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Mon, 28 Oct 2024 18:56:58 GMT, Patricio Chilano Mateo wrote: >> The issue with the c2 runtime stub on aarch64 (and riscv) is that >> cb->frame_size() doesn't match the size of the physical frame, it's short by >> 2 words. I explained the reason for that in the comment above. So for a >> re

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Sat, 26 Oct 2024 00:27:25 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without >> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for >> further details. >> >> In order to make the code revie

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Sat, 26 Oct 2024 00:27:25 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without >> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for >> further details. >> >> In order to make the code revie

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Tue, 22 Oct 2024 02:18:19 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300: >> >>> 298: CodeBlob* cb = top.cb(); >>> 299: >>> 300: if (cb->frame_size() == 2) { >> >> Is this a filter to identify c2 runtime stubs? Is there

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

On Tue, 22 Oct 2024 02:18:19 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300: >> >>> 298: CodeBlob* cb = top.cb(); >>> 299: >>> 300: if (cb->frame_size() == 2) { >> >> Is this a filter to identify c2 runtime stubs? Is there

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

rch64.inline.hpp line 159: >> >>> 157: >>> 158: // The interpreter native wrapper code adds space in the stack equal >>> to size_of_parameters() >>> 159: // after the fixed part of the frame. For wait0 this is equal to 3 >>> words (this + lon

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

rch64.inline.hpp line 159: >> >>> 157: >>> 158: // The interpreter native wrapper code adds space in the stack equal >>> to size_of_parameters() >>> 159: // after the fixed part of the frame. For wait0 this is equal to 3 >>> words (this + lon

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

d from the physical stack, and > will return to `Continuation.run()` to proceed with the unmount logic. During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the pr

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

d from the physical stack, and > will return to `Continuation.run()` to proceed with the unmount logic. During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the pr

Permissions Required to Read LDAP Configuration

Am I missing something, or is this expected behavior? -- Benjamin Long Chief Information Officer Security Service Company 1-484-575-8116

Re: [OS-BUILD PATCH] [redhat] New configs in init/Kconfig

From: Waiman Long on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3377#note_2194793203 Thanks for making the change. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le

Re: [OS-BUILD PATCH] [redhat] New configs in arch/x86

From: Waiman Long on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3351#note_2192507240 LGTM, thanks for making the changes. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le

RE: Bug with moving apps in to folders with latest iOS?

As pointed out on applevis this doesn't always work. it may or may not work for you. -Original Message- From: viphone@googlegroups.com On Behalf Of Mariarosa Chapman Sent: Monday, November 4, 2024 7:21 AM To: viphone@googlegroups.com Subject: Re: Bug with moving apps in to folders with

[clang] [llvm] [BPF] Add load-acquire and store-release instructions under -mcpu=v4 (PR #108636)

https://github.com/inclyc edited https://github.com/llvm/llvm-project/pull/108636 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [BPF] Add load-acquire and store-release instructions under -mcpu=v4 (PR #108636)

https://github.com/inclyc edited https://github.com/llvm/llvm-project/pull/108636 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [BPF] Add load-acquire and store-release instructions under -mcpu=v4 (PR #108636)

@@ -0,0 +1,142 @@ +; RUN: llc < %s -march=bpfel -mcpu=v4 -verify-machineinstrs -show-mc-encoding \ inclyc wrote: ```suggestion ; RUN: llc < %s -march=bpfel -mcpu=v4 -verify-machineinstrs \ ``` Maybe not test mc encoding again https://github.com/llvm/llvm-projec

[clang] [llvm] [BPF] Add load-acquire and store-release instructions under -mcpu=v4 (PR #108636)

https://github.com/inclyc approved this pull request. LGTM, just some nit picking https://github.com/llvm/llvm-project/pull/108636 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [BPF] Add load-acquire and store-release instructions under -mcpu=v4 (PR #108636)

@@ -0,0 +1,142 @@ +; RUN: llc < %s -march=bpfel -mcpu=v4 -verify-machineinstrs -show-mc-encoding \ +; RUN: | FileCheck -check-prefixes=CHECK-LE %s +; RUN: llc < %s -march=bpfeb -mcpu=v4 -verify-machineinstrs -show-mc-encoding \ inclyc wrote: same https://githu

[f2fs-dev] [PATCH v2] f2fs: fix race in concurrent f2fs_stop_gc_thread

shutdown and remount threads, but it fails to prevent all race conditions. Fix it by converting to write lock of s_umount in f2fs_do_shutdown(). Fixes: 7950e9ac638e ("f2fs: stop gc/discard thread after fs shutdown") Signed-off-by: Long Li --- fs/f2fs/file.c | 9 ++--- 1 file changed,

Re: [f2fs-dev] [PATCH 1/2] f2fs: fix race in concurrent f2fs_stop_gc_thread

On Fri, Nov 01, 2024 at 10:56:59AM +0800, Chao Yu wrote: > On 2024/10/31 14:45, Long Li wrote: > > In my test case, concurrent calls to f2fs shutdown report the following > > stack trace: > > > > Oops: general protection fault, probably for non-canonical address &

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28]

On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without >> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for >> further details. >> >> In order to make the code review easier the changes

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28]

On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without >> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for >> further details. >> >> In order to make the code review easier the changes

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12]

On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long wrote: >>> OK, so you're saying it's the stack adjustment that's the problem. It >>> sounds like there is code that is using rsp instead of last_Java_sp to >>> compute the frame boundary. Isn't that a

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12]

On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long wrote: >>> OK, so you're saying it's the stack adjustment that's the problem. It >>> sounds like there is code that is using rsp instead of last_Java_sp to >>> compute the frame boundary. Isn't that a

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12]

On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo wrote: >> OK, so you're saying it's the stack adjustment that's the problem. It >> sounds like there is code that is using rsp instead of last_Java_sp to >> compute the frame boundary. Isn't that a bug that should be fixed? I also >>

Re: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12]

On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo wrote: >> OK, so you're saying it's the stack adjustment that's the problem. It >> sounds like there is code that is using rsp instead of last_Java_sp to >> compute the frame boundary. Isn't that a bug that should be fixed? I also >>

  1   2   3   4   5   6   7   8   9   10   >