From: "Ashok Raj" <ashokr2@attbi.com>
To: "Kevin Pedretti" <ktpedre@sandia.gov>, <kernelnewbies@nl.linux.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: RE: do_exit() and lock_kernel() semantics
Date: Mon, 25 Mar 2002 23:53:33 -0800 [thread overview]
Message-ID: <PPENJLMFIMGBGDDHEPBBMEAMCMAA.ashokr2@attbi.com> (raw)
In-Reply-To: <3C9F7993.7050205@sandia.gov>
1. your driver must have a way to syncup with intr routine accesssing this
buffer. The way we do this is by synching access to this buffer and making
sure your file close cleans up this, so intr routine does not touch this
buffer if process is exited. (assuming you provide access via file handles,
and handle the cleanup as file close)
2. you cannot do the user virtual to kernel address during an intr call. You
must do this and cache the list of page numbers. (then convert the page
number to kva before doing the copy). You must also be aware that if the
buffer crosses page boundaries (i.e true virtual addr spanning pages, you
might need to do this copy multiple times.) since there is no function in
linux kernel to obtain a kva for a uva.
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Kevin Pedretti
Sent: Monday, March 25, 2002 11:25 AM
To: kernelnewbies@nl.linux.org
Cc: ktpedre@sandia.gov; linux-kernel@vger.kernel.org
Subject: do_exit() and lock_kernel() semantics
Hello,
do_exit() does a lock_kernel() before it destroys the dying
processes mm context (sets task_struct->mm to NULL in 2.4 and &init_mm
in 2.2). Does lock_kernel() somehow disable interrupts? It doesn't
look like it does.
Is there anyway from an interrupt context to check if a process is still
alive (not exiting) and prevent it from exiting until the ISR is over?
I guess if lock_kernel disables interrupts globally and waits for
inprogress interrupts to complete, then this isn't a problem.
More detail:
The reason I ask is that I'm working on/modifying a set of modules that
accesses user space from interrupt context. I know this is not a good
thing to do generally, but for performance reasons the original author
wanted to copy directly into a mlocked user space buffer from a network
receive interrupt. Since the buffer is mlocked, it is always guaranteed
to be there and no page faults will happen (right??? I'm new at this).
Thus, for each receive we have to convert the virt address of the
user-land receive buffer to a physical address (in the kernel region)
before doing the memcpy (copy_to_user doesn't work from interrupt
context). This all seems to work fine in practice. However, it seems
to me that there is a race that can happen if a process is in the middle
of dying and a receive interrupt happens. task->mm can be set to
NULL/init_mm out from under me while doing a receive (e.g. on another cpu).
Thanks for any help.
Kevin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2002-03-26 7:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-25 19:25 Kevin Pedretti
2002-03-25 20:17 ` Andrew Morton
2002-03-26 7:53 ` Ashok Raj [this message]
2002-03-26 10:11 ` Itai Nahshon
2002-03-25 20:13 Manfred Spraul
2002-03-25 20:46 ` Kevin Pedretti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=PPENJLMFIMGBGDDHEPBBMEAMCMAA.ashokr2@attbi.com \
--to=ashokr2@attbi.com \
--cc=kernelnewbies@nl.linux.org \
--cc=ktpedre@sandia.gov \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®