linux-kernel - Locking function (interrupt handler) in the L1/L2 cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2C15D00D262B7245B1D8D1799F04D88F04A5874B@mtw01ex01.mindtree.com>
Date:	Thu, 8 Mar 2007 12:47:19 +0530
From:	"Parav K Pandit" <parav_pandit@...dtree.com>
To:	<linux-kernel@...r.kernel.org>
Subject: Locking function (interrupt handler) in the L1/L2 cache

Hi,

I have MPC8548 Linux based firewall which will mostly do packet processing
for 80% time.
So obviously most of the time it will RX and TX packets through gianfar
Ethernet driver.

I want to lock my interrupt handler of this driver in the L1 cache.

1. Are there any kernel APIs to lock any function and data in the L1/L2
cache?

2. How can I use "icbtls" - Instruction Cache Block Touch and Lock Set" for
locking my interrupt handler?

3. Is "icbtls" is the correct instruction at which I am looking at?

4. How do I find end address of the interrupt handler or any other function
and how do we pass it to cache locking instructions? (Because it can happen
that interrupt handler size is more than a cache line, not aligned etc)?

5. Can we enhance request_irq() function to take an additional parameter to
lock the interrupt handler in the cache?

I understand that if my interrupt handler is going to be called most of the
time then it is very likely to happen that OS will not flush the same, but
there is no guarantee for it.

Regards,
Parav Pandit

DISCLAIMER:
This message (including attachment if any) is confidential and may be privileged. Before opening attachments please check them for viruses and defects. MindTree Consulting Limited (MindTree) will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. If you have received this message by mistake please notify the sender by return  e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited.  Please note that e-mails are susceptible to change and MindTree shall not be liable for any improper, untimely or incomplete transmission.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/