On Thu, Feb 26, 2026 at 10:55:21AM -0500, Jeff Layton wrote:
> Update format strings and local variable types in affs for the
> i_ino type change from unsigned long to u64.
>
> Signed-off-by: Jeff Layton <jlayton(a)kernel.org>
Acked-by: David Sterba <dsterba(a)suse.com>
I had a tough time with my crypto assets after a mishap, and I was honestly feeling pretty lost. That’s when I found WHISPERER HACKER RECOVERY. From the get go, they were super approachable and walked me through the entire recovery process step by step.What really impressed me was their level of patience. They took the time to explain things in a way I could understand, which made me feel a lot more at ease. I appreciated that they weren’t just focused on the technical side of things; they genuinely seemed to care about helping me recover my investments.In the end, I was able to recover a significant portion of my crypto, and I couldn't be happier. If you’re facing a similar situation, I’d definitely recommend giving WHISPERER HACKER RECOVERY a try. They made a stressful situation much easier to handle!For More information visit their website at; Homepage > whispershackerrecovery . c o m
WhatApp ; +44 (73 5 22, 191 25
Mailbox; info @ whispershackerrecovery. c o m
On 2/24/26 10:43, Maxime Ripard wrote:
> Hi Christian,
>
> On Fri, Feb 20, 2026 at 10:45:08AM +0100, Christian König wrote:
>> On 2/20/26 02:14, T.J. Mercier wrote:
>>> On Wed, Feb 18, 2026 at 9:15 AM Eric Chanudet <echanude(a)redhat.com> wrote:
>>>
>>> Hi Eric,
>>>
>>>> An earlier series[1] from Maxime introduced dmem to the cma allocator in
>>>> an attempt to use it generally for dma-buf. Restart from there and apply
>>>> the charge in the narrower context of the CMA dma-buf heap instead.
>>>>
>>>> In line with introducing cgroup to the system heap[2], this behavior is
>>>> enabled based on dma_heap.mem_accounting, disabled by default.
>>>>
>>>> dmem is chosen for CMA heaps as it allows limits to be set for each
>>>> region backing each heap. The charge is only put in the dma-buf heap for
>>>> now as it guaranties it can be accounted against a userspace process
>>>> that requested the allocation.
>>>
>>> But CMA memory is system memory, and regular (non-CMA) movable
>>> allocations can occur out of these CMA areas. So this splits system
>>> memory accounting between memcg (from [2]) and dmem. If I want to put
>>> a limit on system memory use I have to adjust multiple limits (memcg +
>>> dmems) and know how to divide the total between them all.
>>>
>>> How do you envision using this combination of different controllers?
>>
>> Yeah we have this problem pretty much everywhere.
>>
>> There are both use cases where you want to account device allocations
>> to memcg and when you don't want that.
>>
>> From what I know at the moment it would be best if the administrator
>> could say for each dmem if it should account additionally to memcg or
>> not.
>>
>> Using module parameters to enable/disable it globally is just a
>> workaround as far as I can see.
>
> That's a pretty good idea! It would indeed be a solution that could
> satisfy everyone (I assume?).
I think so yeah.
From what I have seen we have three different use cases:
1. local device memory (VRAM), GTT/CMA and memcg are completely separate domains and you want to have completely separate values as limit for them.
2. local device memory (VRAM) is separate. GTT/CMA are accounted to memcg, you can still have separate values as limit so that nobody over allocates CMA (for example).
3. All three are accounted to memcg because system memory is actually used as fallback if applications over allocate device local memory.
It's debatable what should be the default, but we clearly need to handle all three use cases. Potentially even on the same system.
Regards,
Christian.
>
> Maxime
Many believe stolen crypto is untraceable due to anonymity. In reality, public blockchains like Bitcoin and Ethereum make tracing possible. Addresses are pseudonymous, but transaction patterns, clusters, and exchange points reveal flows.
Tracing identifies theft points, maps movements, clusters wallets, detects exchanges, and produces reports. Early action is key.
Cryptera Chain Signals leads with 28+ years of experience, hundreds of successes, and high ratings. They trace effectively and educate on prevention.
For tracing help, visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com.
Lost USDT Recovery: Practical Steps and Expert Guidance in 2026
Losing USDT (Tether) whether through a scam, hack, or wallet error hurts because it's a stable coin meant to preserve value. In February 2026, USDT recovery is often more feasible than other tokens due to its heavy use on traceable chains like Ethereum, Tron, and BSC. Here's how to pursue lost USDT recovery.
Step 1: Identify the Loss Type
Scam/hack: funds transferred out. Wallet access loss: forgotten credentials. Mistaken send: wrong address.
Step 2: Gather Evidence
Save TXIDs, addresses, timestamps, scam proof. USDT transactions are visible on Tronscan, Etherscan, or BscScan.
Step 3: Report and Secure
Report to authorities and platforms. Move remaining assets.
Step 4: Tracing USDT Flows
USDT is ERC-20/TRC-20, making it highly traceable. Experts follow approvals, transfers, and exchange deposits.
Cryptera Chain Signals specializes in USDT recovery with 28+ years of experience, hundreds of successes, and strong reviews. They trace flows and prepare evidence for freezes.
Visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com for help.
On 23/02/2026 20:09, Ekansh Gupta wrote:
> Add a DRM_QDA_MAP ioctl and supporting FastRPC plumbing to map GEM
> backed buffers into the DSP virtual address space. The new
> qda_mem_map UAPI structure allows userspace to request legacy MMAP
> style mappings or handle-based MEM_MAP mappings with attributes, and
> encodes flags, offsets and optional virtual address hints that are
> forwarded to the DSP.
>
> On the FastRPC side new method identifiers FASTRPC_RMID_INIT_MMAP
> and FASTRPC_RMID_INIT_MEM_MAP are introduced together with message
> structures for map requests and responses. The fastrpc_prepare_args
> path is extended to build the appropriate request headers, serialize
> the physical page information derived from a GEM object into a
> fastrpc_phy_page array and pack the arguments into the shared message
> buffer used by the existing invoke infrastructure.
>
> The qda_ioctl_mmap() handler dispatches mapping requests based on the
> qda_mem_map request type, reusing the generic fastrpc_invoke()
> machinery and the RPMsg transport to communicate with the DSP. This
> provides the foundation for explicit buffer mapping into the DSP
> address space for subsequent FastRPC calls, aligned with the
> traditional FastRPC user space model.
>
> Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com>
> ---
> arch/arm64/configs/defconfig | 2 +
Not relevan there. Don't stuff other subsystem code into your patches.
Especially without any reasons (your commit msg must explain WHY you are
doing things).
> drivers/accel/qda/qda_drv.c | 1 +
> drivers/accel/qda/qda_fastrpc.c | 217 ++++++++++++++++++++++++++++++++++++++++
> drivers/accel/qda/qda_fastrpc.h | 64 ++++++++++++
> drivers/accel/qda/qda_ioctl.c | 24 +++++
> drivers/accel/qda/qda_ioctl.h | 13 +++
> include/uapi/drm/qda_accel.h | 44 +++++++-
> 7 files changed, 364 insertions(+), 1 deletion(-)
>
Best regards,
Krzysztof