Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-hackers-digest V5 #727

0 views

Skip to first unread message

owner-freebsd-...@freebsd.org

unread,

Feb 23, 2003, 2:40:10 AM2/23/03

freebsd-hackers-digest Saturday, February 22 2003 Volume 05 : Number 727

In this issue:
Re: bleh. Re: ufs_rename panic
Re: bleh. Re: ufs_rename panic
Re: bleh. Re: ufs_rename panic
Re: bleh. Re: ufs_rename panic
Re: bleh. Re: ufs_rename panic
Re: bleh. Re: ufs_rename panic
Re: ***[PATCH] Sound Blaster Audigy*** was (none) - i wasn't awake sorry:)
RE: Need an expert's advise on WITNESS problem(?) (very long)
Re: C coding editor
Re: C coding editor
kernel panic on -current
Re: Broadcom 440x support?
Elaboração de cartas comerciais
Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop
Replacement for get_user_pages() of Linux

----------------------------------------------------------------------

Date: Fri, 21 Feb 2003 14:21:55 -0800
From: Yevgeniy Aleynikov <eug...@infospace.com>
Subject: Re: bleh. Re: ufs_rename panic

As pointed by Ken - we do have alot of file renames (qmail).
But 2-nd solution, directory-only rename serialization, probably won't
affect performance as much.

But i believe it's not only us who's gonna have problem when exploit
code will be known by everybody sooner or later....

Thanks!

Kirk McKusick wrote:
> The potentially slow, but utterly effective way to fix this race
> is to only allow one rename at a time per filesystem. It is
> implemented by adding a flag in the mount structure and using
> it to serialize calls to rename. When only one rename can happen
> at a time, the race cannot occur.
>
> If this proves to be too much of a slow down, it would be possible
> to only serialize directory renames. As these are (presumably) much
> rarer the slow down would be less noticable.
>
> Kirk McKusick
>
> =-=-=-=-=-=
>
> Date: Wed, 19 Feb 2003 15:10:09 -0800
> From: Yevgeniy Aleynikov <eug...@infospace.com>
> To: Matt Dillon <dil...@earth.backplane.com>
> CC: Kirk McKusick <mcku...@mckusick.com>, Ian Dowse <ied...@maths.tcd.ie>,
> pe...@FreeBSD.ORG, ac...@FreeBSD.ORG, Ken Pizzini <ke...@infospace.com>,
> hac...@FreeBSD.ORG, security...@FreeBSD.ORG, nec...@FreeBSD.ORG,
> jed...@FreeBSD.ORG, rwa...@FreeBSD.ORG, i...@FreeBSD.ORG,
> securi...@FreeBSD.ORG, w...@FreeBSD.ORG, gu...@FreeBSD.ORG
> Subject: Re: bleh. Re: ufs_rename panic
> X-ASK-Info: Confirmed by User
>
> Just reminder that this problem is local kernel panic DoS (which can do
> filesystem corruption) with very simple trigger code and it still exists.
>
> And it's been almost 2 years since i wrote about it.
>
>
> Workaround (commenting out panic call) doesnt fix the problem.
> Server still crashes (not so often though) from virtual memory failures
> like this:
>
> panic: vm_fault: fault on nofault entry, addr: d0912000
> mp_lock = 01000002; cpuid = 1; lapic.id = 00000000
> boot() called on cpu#1
>
>
> (kgdb) bt
> #0 0xc0175662 in dumpsys ()
> #1 0xc017542c in boot ()
> #2 0xc0175894 in poweroff_wait ()
> #3 0xc01e7c18 in vm_fault ()
> #4 0xc0219d32 in trap_pfault ()
> #5 0xc021990b in trap ()
> #6 0xc01e008a in ufs_dirrewrite ()
> #7 0xc01e31a4 in ufs_rename ()
> #8 0xc01e4645 in ufs_vnoperate ()
> #9 0xc01a9121 in rename ()
> #10 0xc021a44d in syscall2 ()
> #11 0xc02077cb in Xint0x80_syscall ()
>
>
> How can i help to resolve this problem ASAP?
>
> Thanks!
>
> Matt Dillon wrote:
>
>> Well, I've gone through hell trying to fix the rename()/rmdir()/remove()
>> races and failed utterly. There are far more race conditions then even
>> my last posting indicated, and there are *severe* problems fixing NFS
>> to deal with even Ian's suggestion... it turns out that NFS's nfs_namei()
>> permanently adjusts the mbuf while processing the path name, making
>> restarts impossible.
>>
>> The only solution is to implement namei cache path locking and formalize
>> the 'nameidata' structure, which means ripping up a lot of code because
>> nearly the entire code base currently plays with the contents of
>> 'nameidata' willy-nilly. Nothing else will work. It's not something
>> that I can consider doing now.
>>
>> In the mean time I am going to remove the panic()'s in question. This
>> means that in ufs_rename() the machine will silently ignore the race
>> (not do the rename) instead of panic. It's all that can be done for
>> the moment. It solve the security/attack issue. We'll have to attack
>> the races as a separate issue. The patch to remove the panics is utterly
>> trivial and I will commit it after I test it.
>>
>> -Matt
>>
>>
>>
>
>

Discover what you can do.TM

------------------------------

Date: Fri, 21 Feb 2003 15:26:01 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: bleh. Re: ufs_rename panic

Yevgeniy Aleynikov wrote:
> As pointed by Ken - we do have alot of file renames (qmail).
> But 2-nd solution, directory-only rename serialization, probably won't
> affect performance as much.
>
> But i believe it's not only us who's gonna have problem when exploit
> code will be known by everybody sooner or later....

Dan's non-atomicity assumption on renames is incorrect.

Even if it's were correct, it's possible to recover fully following
a failure, because metadata updates are ordered (there is a real
synchronization between dependent operations).

I think that a workaround would be to comment the directory fsync()
code out of qmail, which apparently thinks it's running on extfs
or an async mounted FFS.

- -- Terry

------------------------------

Date: Fri, 21 Feb 2003 15:35:06 -0800
From: Kirk McKusick <mcku...@beastie.mckusick.com>
Subject: Re: bleh. Re: ufs_rename panic

Date: Fri, 21 Feb 2003 15:26:01 -0800
From: Terry Lambert <tlam...@mindspring.com>
To: Yevgeniy Aleynikov <eug...@infospace.com>
CC: Kirk McKusick <mcku...@beastie.mckusick.com>,
Matt Dillon <dil...@earth.backplane.com>,
Ian Dowse <ied...@maths.tcd.ie>,
pe...@FreeBSD.ORG, ac...@FreeBSD.ORG,
Ken Pizzini <ke...@infospace.com>,
hac...@FreeBSD.ORG, security...@FreeBSD.ORG,
nec...@FreeBSD.ORG,
jed...@FreeBSD.ORG, rwa...@FreeBSD.ORG, i...@FreeBSD.ORG,
securi...@FreeBSD.ORG, w...@FreeBSD.ORG, gu...@FreeBSD.ORG
Subject: Re: bleh. Re: ufs_rename panic

Yevgeniy Aleynikov wrote:
> As pointed by Ken - we do have alot of file renames (qmail).
> But 2-nd solution, directory-only rename serialization, probably
> won't affect performance as much.
>
> But i believe it's not only us who's gonna have problem when exploit
> code will be known by everybody sooner or later....

Dan's non-atomicity assumption on renames is incorrect.

Even if it's were correct, it's possible to recover fully following
a failure, because metadata updates are ordered (there is a real
synchronization between dependent operations).

I think that a workaround would be to comment the directory fsync()
code out of qmail, which apparently thinks it's running on extfs
or an async mounted FFS.

-- Terry

You cannot get rid of the fsync calls in qmail. You have to distinguish
between a filesystem that is recoverable and one which loses data.
When receiving an incoming message, SMTP requires that the receiver
have the message in stable store before acknowledging receipt. The
only way to know that it is in stable store is to fsync it before
responding.

Kirk McKusick

------------------------------

Date: Fri, 21 Feb 2003 15:36:09 -0800 (PST)
From: Julian Elischer <jul...@elischer.org>
Subject: Re: bleh. Re: ufs_rename panic

On Fri, 21 Feb 2003, Terry Lambert wrote:

> Yevgeniy Aleynikov wrote:
> > As pointed by Ken - we do have alot of file renames (qmail).
> > But 2-nd solution, directory-only rename serialization, probably won't
> > affect performance as much.
> >
> > But i believe it's not only us who's gonna have problem when exploit
> > code will be known by everybody sooner or later....
>
> Dan's non-atomicity assumption on renames is incorrect.
>
> Even if it's were correct, it's possible to recover fully following
> a failure, because metadata updates are ordered (there is a real
> synchronization between dependent operations).
>
> I think that a workaround would be to comment the directory fsync()
> code out of qmail, which apparently thinks it's running on extfs
> or an async mounted FFS.

If you don't want to lose mail then qmail needs to do a fsync after it
does the rename.

>
> -- Terry
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>

------------------------------

Date: Fri, 21 Feb 2003 16:03:49 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: bleh. Re: ufs_rename panic

Kirk McKusick wrote:
> Yevgeniy Aleynikov wrote:
> > As pointed by Ken - we do have alot of file renames (qmail).
> > But 2-nd solution, directory-only rename serialization, probably
> > won't affect performance as much.
> >
> > But i believe it's not only us who's gonna have problem when exploit
> > code will be known by everybody sooner or later....
>
> Dan's non-atomicity assumption on renames is incorrect.
>
> Even if it's were correct, it's possible to recover fully following
> a failure, because metadata updates are ordered (there is a real
> synchronization between dependent operations).
>
> I think that a workaround would be to comment the directory fsync()
> code out of qmail, which apparently thinks it's running on extfs
> or an async mounted FFS.
>
> -- Terry
>
> You cannot get rid of the fsync calls in qmail. You have to distinguish
> between a filesystem that is recoverable and one which loses data.
> When receiving an incoming message, SMTP requires that the receiver
> have the message in stable store before acknowledging receipt. The
> only way to know that it is in stable store is to fsync it before
> responding.

The issue is specifically with the rename code, which is a metadata
operation, not with the storing of application data.

The fsync's in question are those to the fd of the directory, not
the fd of the application data. Sorry if it wasn't clear from my
statement that "Dan's non-atomicity assumption on renames is
incorrect" meant that it only applied to the fsync() calls dealing
with the rename.

- -- Terry

------------------------------

Date: Fri, 21 Feb 2003 16:05:31 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: bleh. Re: ufs_rename panic

Julian Elischer wrote:
> On Fri, 21 Feb 2003, Terry Lambert wrote:
> > Dan's non-atomicity assumption on renames is incorrect.
[ ... ]
> > I think that a workaround would be to comment the directory fsync()
> > code out of qmail, which apparently thinks it's running on extfs
> > or an async mounted FFS.
>
> If you don't want to lose mail then qmail needs to do a fsync after it
> does the rename.

See other mail. I was referring only to fsync() of directory
data. Sorry if that wasn't clear because of the intervening
paragraph.

- -- Terry

------------------------------

Date: Sat, 22 Feb 2003 01:15:08 -0000
From: "Markie" <mar...@notwentytwo.freeserve.co.uk>
Subject: Re: ***[PATCH] Sound Blaster Audigy*** was (none) - i wasn't awake sorry:)

I couldnt read :) The patch did patch the header file after all, just wanted
to know where it was.
I have it up and running now, works like a charm!!!!! Been waiting for
Audigy support for a while :)
I'll gladly test out any changes if you need help with testing at all :)

Thanks alot!
Markie :)

- ----- Original Message -----
From: "Markie" <mar...@notwentytwo.freeserve.co.uk>
To: <orlando....@ieo-research.it>; <freebsd...@freebsd.org>
Sent: Friday, February 21, 2003 9:45 PM

> Hi,
> Just wondering how you actually got your Audigy card working, the patch
you
> attach does not fix the header file :)
> Any chance you could make a patch for the header file or send me yours? :)
>
> Thanks
> Markie
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>

------------------------------

Date: Fri, 21 Feb 2003 20:29:56 -0500 (EST)
From: John Baldwin <j...@FreeBSD.org>
Subject: RE: Need an expert's advise on WITNESS problem(?) (very long)

On 17-Feb-2003 Maksim Yevmenkin wrote:
> Dear Hackers,
>
> I need an expert's advice on the small locking/WITNESS problem
> (if this is a real problem of course). It basically boils down
> to the following:
>
> Consider three (3) MTX_DEF mutexes: A, B1 and B2. Mutex A has a
> name "mutex_A" and type "type_A". Mutex B1 has a name "mutex_B1"
> and mutex B2 has name "mutex_B2". Both mutex B1 and B2 have the
> same type "type_B". Please note that mutexes B1 and B2 are
> completely independent from each other. They just have the same
> mutex type (B1 and B2 are used for fine grained locking).
>
> Now consider the code that has two (2) paths: P1 and P2.
>
> On the path P1 the code first acquires mutex A and then mutex
> B1. Then the code releases mutex B1 and then mutex A.
>
> On the path P2 the code first acquires mutex B2 and then mutex
> A. Then the code releases mutex B2 and then mutex A.
>
> So the code's flow looks something like this
>
> --->---\ /--->--- B1 --->--- Code path P1
> A
> ---<---/ \---<--- B2 ---<--- Code path P2
>
> Now the problem (again if this is a problem) is that WITNESS
> code builds relations between mutex types (or at least I think
> it does). So when the code runs, WITNESS will build relations
> between mutex types for the first path the code follows (lets
> say P1). Later when the code follows the second path (in this
> example P2), WITNESS will create "lock order reversal" message.
>
> The questions are:
>
> 1) Is anything wrong with the such code and/or mutex use?
> Since mutexes B1 and B2 are completely independent, there
> is no deadlock danger, right? Please tell me if I'm wrong
> and missing something here.
>
> 2) Is there any way to resolve the problem? I'm prepared to
> change/re-design my code if needed.
>
> 3) Is WITNESS right in this case?

Yes. By saying that two locks are the same type, you are
saying that they should be treated the same. For example,
you could have all process locks have 'process lock' for
their type and have 'pid XXXX' for their name so that the
names are more informative for debugging. Similarly, all
network interface drivers would use the same type for their
driver lock but might use the name of the interface for the
name of the actual lock.

- --

John Baldwin <j...@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/

------------------------------

Date: Sat, 22 Feb 2003 00:36:00 +0200
From: Giorgos Keramidas <kera...@ceid.upatras.gr>
Subject: Re: C coding editor

On 2003-02-21 15:49, Peter Pentchev <ro...@ringlet.net> wrote:
> On Fri, Feb 21, 2003 at 01:21:03PM +0100, Clemens Hermann wrote:
> > what are your favourite editors for coding C? While vi on the first
> > terminal, cc on second and runs on the third is fine for very small
> > things I doubt it is the way people do it here.
>
> [...] both Vim and Emacs/XEmacs can run 'make' just fine, parse its
> output, and locate the actual error positions, much like any GUI IDE
> that people might be used to. Basically, vi and cc need just one
> terminal, no more :)

Then, there's always ^Z. These newcomers of the fancy, "where's my
shiny IDE" persuasion, always keep forgetting about ^Z.

:-)

------------------------------

Date: Fri, 21 Feb 2003 21:24:36 -0500
From: Leo Bicknell <bick...@ufp.org>
Subject: Re: C coding editor

- --ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

In a message written on Fri, Feb 21, 2003 at 03:49:06PM +0200, Peter Pentch=
ev wrote:
> that people might be used to. Basically, vi and cc need just one
> terminal, no more :)

I'll insert one editor comment. While it becomes obvious to most
people who use emacs (doubly true for emacs native in X, or xemacs)
that emacs can do /everything/, it also often seems to people that
vi can do "nothing".

I won't suggest vi can do everything that emacs can do, but about
once every 6 months I reread several vi references, and always
learn a half dozen new things. There are really an amazing number
of useful vi "features" that are not immediately obvious. Since
there are no easy menu's or an easy to understand programming
language they are often missed.

Of course, my personal belief is that you should always know multiple
tools. Program in vi for a while. Then emacs, then kdevel. You'll
find a feature in one that spawns an idea in another, and knowing
something about all of them helps you interact with people who only
use one of them. Indeed, I have been known at times to use vi for
all e-mail, and emacs for all coding, or vice versa. It really
doesn't take that much time, and teaches you so much more.

- --=20
Leo Bicknell - bick...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-lis...@tmbg.org, www.tmbg.org

- --ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE+Vt9kNh6mMG5yMTYRAm3LAJ9wL/8tk81krm1VBsjoViSid5ahbACdFDoL
j5pkwK2MAv/YPUy2Owt3HQk=
=u+G0
- -----END PGP SIGNATURE-----

- --ew6BAiZeqk4r7MaW--

------------------------------

Date: Sat, 22 Feb 2003 11:04:02 +0800
From: leafy <le...@leafy.idv.tw>
Subject: kernel panic on -current

(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01bcab9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01bcd23 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0200cc2 in bwrite (bp=0xc785a060) at /usr/src/sys/kern/vfs_bio.c:842
#4 0xc0202481 in vfs_bio_awrite (bp=0xc785a060)
at /usr/src/sys/kern/vfs_bio.c:1724
#5 0xc0209e17 in vop_stdfsync (ap=0xcd32ca60)
at /usr/src/sys/kern/vfs_default.c:755
#6 0xc01811e0 in spec_fsync (ap=0xcd32ca60)
at /usr/src/sys/fs/specfs/spec_vnops.c:422
#7 0xc01806b8 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:123
#8 0xc026ed67 in ffs_sync (mp=0xc2691400, waitfor=2, cred=0xc0eb5e80,
td=0xc0316c00) at vnode_if.h:612
#9 0xc021763b in sync (td=0xc0316c00, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#10 0xc01bc69c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280
#11 0xc01bcd23 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#12 0xc02c9472 in trap_fatal (frame=0xcd32cc28, eva=0)
at /usr/src/sys/i386/i386/trap.c:844
#13 0xc02c9152 in trap_pfault (frame=0xcd32cc28, usermode=0, eva=3310622)
at /usr/src/sys/i386/i386/trap.c:758
#14 0xc02c8c40 in trap (frame=
- ---Type <return> to continue, or q <return> to quit---
{tf_fs = -1070333928, tf_es = -1058275312, tf_ds = -852361200, tf_edi = -1
071351312, tf_esi = -1030640448, tf_ebp = -852308848, tf_isp = -852308908, tf_eb
x = 3310418, tf_edx = -1058256304, tf_ecx = -1030640408, tf_eax = 4, tf_trapno =
12, tf_err = 2, tf_eip = -1071351204, tf_cs = 8, tf_eflags = 66050, tf_esp = -1
071897635, tf_ss = -1070479488}) at /usr/src/sys/i386/i386/trap.c:445
#15 0xc02b8df8 in calltrap () at {standard input}:96
#16 0xc01cc435 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:195
#17 0xc01a8931 in ithread_loop (arg=0xc0ec2200)
at /usr/src/sys/kern/kern_intr.c:536
#18 0xc01a7823 in fork_exit (callout=0xc01a8760 <ithread_loop>, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:871

FreeBSD leafy.idv.tw 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Feb 22 01:19:49 CST
2003 le...@leafy.idv.tw:/usr/obj/usr/src/sys/CHIHIRO i386

- --
"Without the userland, the kernel is useless."
--inspired by The Tao of Programming

------------------------------

Date: Sat, 22 Feb 2003 10:57:15 +0100
From: Stefan =?iso-8859-1?Q?E=DFer?= <s...@freebsd.org>
Subject: Re: Broadcom 440x support?

There are Linux drivers available for download and it seems,
that the 440x and 520x drivers are very similar. I intended
to make the bge driver support the 440x in my ASUS A7K8X, but
have not had time to actually start that project (beyond the
initial diff of the two official drivers.)

If anybody is interested, I can provide the diffs, which
amount to 2620 lines (diff -u1). But many differences are
cosmetic ("b44_" prepended to function names and bcm5700
replaced by bcm4400 in many identifiers). The actual driver
change will probably amount to just a few hundred lines,
at most ...

Regards, STefan

On 2003-02-21 13:58 -0800, Julian Elischer <jul...@elischer.org> wrote:
> We just got 40 of them...
> answer.. "no" :-(
>
> On Fri, 21 Feb 2003, Lars Eggert wrote:
> > we just got an Asus P4PE board with a Broadcom 440x NIC on it - is there
> > any driver that supports it yet?

------------------------------

Date: Sat, 22 Feb 2003 14:04:53 -0300
From: "Redação Comercial" <redac...@bol.com.br>
Subject: Elaboração de cartas comerciais

COMUNICADO IMPORTANTE!!

Estamos lançando o KIT DE CARTAS COMERCIAIS, que sana suas dúvidas na
elaboração de: agradecimentos, atestados e declarações, avisos, cartas de
cobrança, cartas em inglês, comunicados, convites, contratos, propostas,
empregos, solicitações e pedidos, telegramas, cartas por e-mail, etc.
Composto de 02 (dois) disquetes com 150 modelos de documentos cada um,
mais livreto 20 páginas, com técnicas de redação comercial. Indicado para:
secretárias em geral, gerências, Rh, executivos, estudantes e empresas de
toda ordem.
Este kit possui um preço ínfimo em relação ao que poderá gerar no
aperfeiçoamento da comunicação de sua empresa.

Acesse nossa Home Page para mais detalhes:

http://www.redacaodecartas.ihp.com.br

Ps: Caso não queira receber novas mensagens e novidades sobre esse
assunto, acesse:

http://www.remova-me.ihp.com.br

------------------------------

Date: Sat, 22 Feb 2003 11:26:54 -0800 (PST)
From: John Polstra <j...@polstra.com>
Subject: Re: Raising SIGSEGV in SIGSEGV handler makes FreeBSD loop

In article <3E5437CB...@mindspring.com>,
Terry Lambert <tlam...@mindspring.com> wrote:
> Vaclav Haisman wrote:
> > Besides, this doesn't explain anything. I see I haven't asked any question in
> > my previous post. So, why does FreeBSD behave different?
>
> Because POSIX mandates that it do so?
>
> man 3 signal tells us:
>
> The handled signal is unblocked when the function returns and the process
> continues from where it left off when the signal occurred. Unlike previ-
> ous signal facilities, the handler func() remains installed after a sig-
> nal has been delivered.

POSIX mandates no such thing. You missed the part of the POSIX spec
that says:

The behavior of a process is undefined after it returns normally
from a signal-catching function for a SIGFPE, SIGILL, SIGSEGV,
or SIGBUS signal that was not generated by the kill() function,
the sigqueue() function, or the raise() function as defined by
the C Standard.

It's in ANSI/IEEE Std 1003.1 section 3.3.1.3.

POSIX permits the FreeBSD behavior but does not mandate it.

John
- --
John Polstra
John D. Polstra & Co., Inc. Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa

------------------------------

Date: Sun, 23 Feb 2003 16:37:46 +0900
From: Byunghyun Oh <octp...@postech.ac.kr>
Subject: Replacement for get_user_pages() of Linux

I'm porting Plex86 x86 VM, which uses get_user_pages() function at
Linux-version kernel module to find and pin physical pages of memory
in user space (according to its documentation). I tried many
candidates as its replacement (PHYS_TO_VM_PAGE() macro in vm/vm_page.h
seems most useful now), but they haven't worked at all.

Any experience about porting VM-related things in Linux will be
appreciated. :)

Byunghyun Oh octphial _at_ postech.ac.kr

------------------------------

End of freebsd-hackers-digest V5 #727
*************************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-hackers-digest in the body of the message

0 new messages