Linux-Development-Sys Digest #471, Volume #8 Wed, 7 Feb 01 05:13:15 EST
Contents:
Re: recursive mutex implementation (Kaz Kylheku)
Re: reliable coredump under Linux? ("Gene Soudlenkov")
Re: recursive mutex implementation (Kaz Kylheku)
does 2.4 kernel need 2.4 initrd? (Eric Taylor)
Re: Module Programming Question (Unresolved symbol printk) ([EMAIL PROTECTED])
Re: sleeping inside the kernel (sleep_on ; schedule_timeout) ([EMAIL PROTECTED])
EXPORT Kernel Symbol ([EMAIL PROTECTED])
Re: EXPORT Kernel Symbol ("Gene Soudlenkov")
Sendmail problem... ("avi")
Re: EXPORT Kernel Symbol ([EMAIL PROTECTED])
Re: Isn't ReiserFS in 2.4.1 (Marc SCHAEFER)
EXPORT Kernel Symbol for my own Kernel Function ([EMAIL PROTECTED])
Re: does 2.4 kernel need 2.4 initrd? (Villy Kruse)
Re: Module Programming Question (Unresolved symbol printk) (Josef Moellers)
Re: can Linux be secure? (Kasper Dupont)
Re: Module Programming Question (Unresolved symbol printk) (Kasper Dupont)
Re: does 2.4 kernel need 2.4 initrd? (Anders Larsen)
Re: does 2.4 kernel need 2.4 initrd? (Eric Taylor)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: recursive mutex implementation
Reply-To: [EMAIL PROTECTED]
Date: Wed, 07 Feb 2001 00:09:24 GMT
On Tue, 06 Feb 2001 22:31:46 GMT, Daniele Pallastrelli <[EMAIL PROTECTED]> wrote:
>Hi all,
>I need to implement a my own recursive mutex using only traditional mutexes.
>I think this solution could work:
>
>
>variables:
> m, critSect: mutex;
> lockCount: int;
> owner: thread ID;
>
>
>lock() implementation:
>
>critSect.lock()
>if ( owner == 0 ) // mutex is not owned by anyone...
It's not portable to compare a pthread_t against zero, nor to assume
that zero cannot be a valid thread ID. On some operating systems,
pthread_t is in an integer, and the main thread is assigned the
value zero. On some others, pthread_t is a struct.
This is easy to fix by using an extra flag to indicate that the mutex
is not owned.
> {
> ++lockCount;
> owner = pthread_self();
> m.lock();
This is a problem; while a thread waits here on mutex m, it is holding
mutex critSect. So no other thread can perform any operation on the
lock, including the thread which owns the mutex m.
> }
> else
> if ( owner == pthread_self() ) // I already have this mutex!
> ++lockCount;
> else // someone locks this mutex!
> {
> critSect.unlock();
> m.lock();
> critSect.lock();
> lockCount = 1;
Also, you have a horrible race here that leads to deadlock situation,
because you acquire the locks in an opposite order. Suppose that just
after you call m.lock() some other thread calls this function. That
other thread acquires critSect.lock(), sees that there is not yet any
owner, and so calls m.lock(). However, your thread has already acquired
the lock m, so that other thread has to wait. Meanwhile, your thread
calls critSect.lock() and the deadly embrace is complete.
I believe that the problem can be solved like this:
void lock::acquire()
{
crit_sect.lock();
bool i_am_the_owner = is_locked && owner == pthread_self();
crit_sect.unlock();
if (i_am_the_owner)
lock_count++;
else {
m.lock();
crit_sect.lock();
is_locked = true;
owner = pthread_self();
crit_sect.unlock();
}
}
void lock::release()
{
if (--lock_count == 0) {
crit_sect.lock();
is_locked = false;
crit_sect.unlock();
m.unlock();
}
}
Note that only the lock_count is protected by m. Only the flag is_locked
and the owner variable are protected by crit_sect. The two times
when both locks are held by the caller are in the else clause in
lock::acquire, and in the body of the if in ::release. There is no
opposite locking m is always acquired first, hence no risk of deadlock.
Final remark: you'd be better off working with non-recursive locks.
Recursive locks are error prone.
------------------------------
From: "Gene Soudlenkov" <[EMAIL PROTECTED]>
Subject: Re: reliable coredump under Linux?
Date: Wed, 7 Feb 2001 13:38:17 +1300
Hi,
We've got the same problem with our application. Could you give a clue what
changes have been done in binfmt_elf?
Gene
rachel braverman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> We face a problem after patching the kernel. Maybe you have an idea
> what we need to do:
>
> We run a multithreaded application
> (it happens for any multithreaded applications)
> using our compiled 2.2.17 kernel with glibc-2.1.2-11.
> When we send a
>
> kill -SEGV <thread pid>
>
> When analyzing the core dump we see
> that it has the information of only the
> dumping thread which is not the same
> threads that received the signal
> (it is the last thread which goes down).
>
> To fix that we changed the following files:
> fs/binfmt_elf.c
> kernel/fork.c
> include/linux/sched.h
>
> This fix provides a coredump of the signaled thread
> + the information from the rest of the threads.
> The problem with the fix is that when the
> signaled thread is dumping the core it is prone
> to a context switching. Other threads than assume
> the CPU and corrupt the core image.
>
>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: recursive mutex implementation
Reply-To: [EMAIL PROTECTED]
Date: Wed, 07 Feb 2001 00:44:18 GMT
On Wed, 07 Feb 2001 00:09:24 GMT, Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>void lock::acquire()
>{
> crit_sect.lock();
> bool i_am_the_owner = is_locked && owner == pthread_self();
> crit_sect.unlock();
>
> if (i_am_the_owner)
> lock_count++;
> else {
> m.lock();
>
> crit_sect.lock();
> is_locked = true;
> owner = pthread_self();
> crit_sect.unlock();
BUG! There should be a lock_count++; here, or lock_count = 1.
> }
>}
That can then be factored out:
if (!i_am_the_owner) {
m.lock();
crit_sect.lock();
is_locked = true;
owner = pthread_self();
crit_sect.unlock();
}
lock_count++;
}
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: does 2.4 kernel need 2.4 initrd?
Date: Wed, 07 Feb 2001 01:41:09 GMT
Hi:
I have a kernel building question:
First must I have an initrd lilo entry to
boot a scsi device (an adaptec controller).
If yes, then
Do I need to build a new initrd for 2.4 kernel.
or
Can I use the 2.2 initrd with a 2.4 kernel.
I am upgrading a redhat 7.0 system to use 2.4 kernel.
When I tried to build a new initrd, it complains it cannot
find my AIC-7xxx modules. When I config my scsi devices
as modules I can build a new initrd, but my system won't boot up.
I get a system panic at boot up complaining
about a bad root device.
When I build the drivers in, it seems to work -
but I'm not sure why or if that was what made it
work as I was trying lots of things.
So, I am really confused,
about scsi and initrd, because when
the drivers are built in
I cannot then build a new initrd.
I need to do this upgrade to other systems,
so I need to really understand this.
(Do you really need to first
build the drivers modular to build
initrd, then make the drivers
built-in in order to boot up??
seems strange, I must be doing something
else wrong).
thanks,
confused eric
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Module Programming Question (Unresolved symbol printk)
Date: Wed, 07 Feb 2001 02:57:02 GMT
Cool glad to hear it. I was going to offer attempting to compile it for
you on one of my machines but it sounds like your on the right trail.
Perhaps the SMP kernel you are running doesn't have the symbol for
printk exported... That would seem strange.
I tried to use an unexported function and found I had to use a different
exported function that referenced the unexported function I was after.
I think you can grep for exported symbols in /proc/ksyms of a running
kernel (or may some other /proc file, not sure). So perhaps try
grepping for printk in SMP ksyms versus uniprocessor kernel and see if
there's a difference... Or perhaps it's the way the SMP kernel was
built...
Good luck...
-Eric
In article <95p21m$[EMAIL PROTECTED]>,
"Mudit" <[EMAIL PROTECTED]> wrote:
> So, it was bugging me last night since everything I was doing seemed
right.
> Anyway, I installed RedHat 6.2 on my laptop and everything worked ok;
i.e.
> the module installed, printed the nice text etc.
>
> I began thinking why is it working on my laptop, but not on my
desktop. The
> only thing I can come up with is that the desktop is MP. I'm not up to
speed
> yet on how Linux implements SMP, but perhaps there is an issue here.
>
> (btw, I got the book)
>
> Thoughts?
>
> Mudit
>
> "Mudit" <[EMAIL PROTECTED]> wrote in message
> news:95n5q7$[EMAIL PROTECTED]...
> > Thanks for the info. I added the "-O" (tried "-O3" too per some
other
> > documention) switch and I am still seeing the issue though. I'm
baffled.
> >
> > I'll get the book. Hopefully that'll give me a better understanding
of
> > what's going on and how to solve the problem.
> >
> > Thanks,
> > Mudit
> >
> > <[EMAIL PROTECTED]> wrote in message
> news:95mstb$9kt$[EMAIL PROTECTED]...
> > > I got bit by this when coming up to speed also.
> > >
> > > You'll find that the headers define tons of inline functions.
> > > The compiler will only expand inlines if the optimizer is turned
on.
> > >
> > > Therefore, to solve your problem, turn the optimizer on when you
> > > compile:
> > >
> > > cc -O -c hello.c
> > >
> > > Add to your MODCFLAGS the -O option.
> > >
> > > If you don't have a copy of the book "Linux Device Drivers" by
> > > Alessandro Rubini, get it! It's the best resource I've found so
far.
> > >
> > > bookpool.com usually has almost half off the cover price. Use the
> > > savings to have them ship it to you next day or 2 day!!
> > >
> > > Good luck, and have fun,
> > >
> > > -Eric Malkowski
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux
Subject: Re: sleeping inside the kernel (sleep_on ; schedule_timeout)
Date: Wed, 07 Feb 2001 03:26:39 GMT
I've been digging a lot through the networking code and it sounds like
the traffic shaper device might be able to do what you want. It looks
like that thing can limit bandwidth consumed when packets are sunk
through the shaper device on their way out. I think it said something
like 256 kilobits max.
If you're queueing packets that normally go at 10/100 mbps, then going
through 256 kilobit max shaper device will make it look like some delay
was introduced on the other end.
Another thought-- perhaps a raw socket or packet socket from user space
could be used to grab the packets, sleep from the safety of user space,
and re-transmit them with a raw / packet socket.
Best of luck
-Eric Malkowski
In article <949thj$dlr$[EMAIL PROTECTED]>,
"Arie" <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm doing a project of noise generator over the internet network. This
> project include losing & delaying packets which receive / send q
> forwarding from the computer or a router.
> The problem is in the delaying packets part. The changes been made in
the
> ip_rcv function.
> I try to use sleep_on & wake_up no metter if I use init_waitqueue or
not -
> the kernel crashed. I assume it happened because 'switching task to
null'. I
> try to use schedule_timeout, but with this also the kernel crashed.
> any one have idea what the problem is, or where I can get exaplme for
such
> kind of code? (I look at the kernel code and how they use
sleep_on/wake_up
> and schedule_timeout - and I try to use it in the same way) Is it
possible
> to make the kernel sleep in the ip_rcv, while the computer is
receiving
> packets?
>
> Thanks,
> Arie.
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: EXPORT Kernel Symbol
Date: Wed, 07 Feb 2001 04:26:32 GMT
Hi,
Is there anyone know how to export kenrel symbol for kernel module use ?
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Gene Soudlenkov" <[EMAIL PROTECTED]>
Subject: Re: EXPORT Kernel Symbol
Date: Wed, 7 Feb 2001 18:07:58 +1300
EXPORT_SYMBOL(symbol_name);
<[EMAIL PROTECTED]> wrote in message news:95qiph$ic7$[EMAIL PROTECTED]...
> Hi,
>
> Is there anyone know how to export kenrel symbol for kernel module use ?
>
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: "avi" <[EMAIL PROTECTED]>
Subject: Sendmail problem...
Date: Wed, 7 Feb 2001 07:51:40 +0200
Hi,
I had install my domain and send mail to my server.
I can send mail but I cann't resive any mail.
is there any setting I need to do or somewhere I can check to solve the
problem?
redhat 7.0
Thanks
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: EXPORT Kernel Symbol
Date: Wed, 07 Feb 2001 06:09:15 GMT
If it is new define kernel function on my own, how can I export the
symbol? use EXPORT_SYMBOL() only ?
In article <VP4g6.15486$[EMAIL PROTECTED]>,
"Gene Soudlenkov" <[EMAIL PROTECTED]> wrote:
> EXPORT_SYMBOL(symbol_name);
>
> <[EMAIL PROTECTED]> wrote in message
news:95qiph$ic7$[EMAIL PROTECTED]...
> > Hi,
> >
> > Is there anyone know how to export kenrel symbol for kernel module
use ?
> >
> >
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Marc SCHAEFER <[EMAIL PROTECTED]>
Subject: Re: Isn't ReiserFS in 2.4.1
Date: 6 Feb 2001 16:46:02 GMT
bjrosen <[EMAIL PROTECTED]> wrote:
: Thanks, I didn't know that I had to select Experimental.
Without being nasty, if you didn't know about Experimental, maybe you
shouldn't.
------------------------------
From: [EMAIL PROTECTED]
Subject: EXPORT Kernel Symbol for my own Kernel Function
Date: Wed, 07 Feb 2001 06:55:14 GMT
Hi all,
Do you know how to export kernel symbol for my own kernel function for
the kernel module use ?
Jim
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: does 2.4 kernel need 2.4 initrd?
Date: 7 Feb 2001 07:52:15 GMT
On Wed, 07 Feb 2001 01:41:09 GMT, Eric Taylor <[EMAIL PROTECTED]> wrote:
>When I build the drivers in, it seems to work -
>but I'm not sure why or if that was what made it
>work as I was trying lots of things.
>
>So, I am really confused,
>about scsi and initrd, because when
>the drivers are built in
>I cannot then build a new initrd.
>
If the SCSI driver is built in you don't need initrd. The initrd
is a way to load a disk device driver before you can access the
disk device that needs the disk device driver before the disk
can be accessed. Initrd creates a ramdisk from where the disk
device driver can be installed. If the device driver is built in
there is no need to load the disk device driver, and therefore
there is no need for an initial ramdisk, and thus no initrd.
Villy
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: Module Programming Question (Unresolved symbol printk)
Date: Wed, 07 Feb 2001 09:34:38 +0100
Mudit wrote:
> =
> Greeting,
> =
> I'm trying to get up to speed on module programming. I typed the Hello =
World
> example from http://howto.tucows.com/LDP/LDP/lkmpg/node11.html (include=
d
> below). It compiles ok (makefile also below). When I do an "insmod hell=
o.o"
> from outside of X, I get:
> =
> hello.o: unresolved symbol printk
Although in a later postin you write that it insmod's quite nicely on a
6.2:
Rehat uses MODVERSIONS, so all your interface functions between the
kernel proper and the module should have
_Rxxxxxxxx
or
_Rsmpxxxxxxxx
appended to them, depending on whether it's a single- or multiple-CPU
kernel, where xxxxxxxx is an 8 digit hex number.
Do an "fgrep prink /proc/ksyms" and compare the symbol name to the one
you get in your error message.
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize
-- T. Pratchett
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: can Linux be secure?
Date: Wed, 07 Feb 2001 09:46:51 +0100
Peter T. Breuer wrote:
>
> [EMAIL PROTECTED] wrote:
> > Well, from the sounds of it, it seems I can trust the Linux kernel,
> > though I would have to also continue to watch for any exploits. But
>
> You can do no such thing. Anyone who gets root can do an insmod
> of init_module() { do arbitrary thing to kernel; }. So the kernel
> is exactly as secure as userspace.
>
> Peter
The module syscalls is not a major security problem,
if you have root permitions there are so many other
bad things you can do.
When we say that we trust the Linux kernel, among
other things we trust that it will not give root
permitions without prober authentication.
Even if the kernel is secure, the system as a hole
can be insecure, but that is not what this discussion
is about.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Module Programming Question (Unresolved symbol printk)
Date: Wed, 07 Feb 2001 10:06:21 +0100
Mudit wrote:
>
> So, it was bugging me last night since everything I was doing seemed right.
> Anyway, I installed RedHat 6.2 on my laptop and everything worked ok; i.e.
> the module installed, printed the nice text etc.
>
> I began thinking why is it working on my laptop, but not on my desktop. The
> only thing I can come up with is that the desktop is MP. I'm not up to speed
> yet on how Linux implements SMP, but perhaps there is an issue here.
>
> (btw, I got the book)
>
> Thoughts?
>
> Mudit
>
[...]
I've experienced lots of problems compiling
kernels/modules under the most recent
RedHat distributions.
I have found some of the reasons for my
problems, but perhaps not all of them.
RedHat has a mixture of different compiler
versions. RedHat has shipped kernel and
headers from different versions. RedHat has
applied a patch to the kernel sources
making kernel and modules being marked
with the version number of the runing
kernel instead of the kernel they are
actually being compiled for. An interesting
point here is that the patch is applied to
an auto generated file, if you touch the
Makefile the patched file will be
regenerated which removes the patch.
I've had problems with RH6.2 and RH7.0.
I've never had problems with RH6.0, but I
didn't try to compile that for SMP.
I think the problem you have is coursed by
either wrong header files being used, or
symbol version information.
--
Kasper Dupont
------------------------------
From: [EMAIL PROTECTED] (Anders Larsen)
Subject: Re: does 2.4 kernel need 2.4 initrd?
Date: 7 Feb 2001 09:35:53 GMT
On Wed, 07 Feb 2001 01:41:09 GMT, Eric Taylor <[EMAIL PROTECTED]> wrote:
>I have a kernel building question:
>
>First must I have an initrd lilo entry to
>boot a scsi device (an adaptec controller).
No, not if you build the adaptec driver into the kernel.
>If yes, then
>
>Do I need to build a new initrd for 2.4 kernel.
> or
>Can I use the 2.2 initrd with a 2.4 kernel.
The initrd must match the kernel *exactly*, i.e., you can't even use an
initrd-2.2.14-... with a 2.2.16 kernel.
>I am upgrading a redhat 7.0 system to use 2.4 kernel.
>
>When I tried to build a new initrd, it complains it cannot
>find my AIC-7xxx modules. When I config my scsi devices
>as modules I can build a new initrd, but my system won't boot up.
>I get a system panic at boot up complaining
>about a bad root device.
You *do* have the 2.4 modutils, do you?
>When I build the drivers in, it seems to work -
>but I'm not sure why or if that was what made it
>work as I was trying lots of things.
Sure it was - but you really only have to build the driver of the boot-
device into the kernel - you could leave the rest as modules.
>So, I am really confused,
>about scsi and initrd, because when
>the drivers are built in
>I cannot then build a new initrd.
Should still be possible *if* you have left something as modules.
>I need to do this upgrade to other systems,
>so I need to really understand this.
One pragmatic solution is to build anything that is needed to boot into
the kernel and leave the rest (which can be loaded later) as modules.
In that case, you don't need an initrd at all.
>(Do you really need to first
>build the drivers modular to build
>initrd, then make the drivers
>built-in in order to boot up??
>seems strange, I must be doing something
>else wrong).
Yes. The order should always be
build kernel, build & install modules, mkinitrd
HTH
Anders
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: does 2.4 kernel need 2.4 initrd?
Date: Wed, 07 Feb 2001 09:51:20 GMT
Villy Kruse wrote:
>
> On Wed, 07 Feb 2001 01:41:09 GMT, Eric Taylor <[EMAIL PROTECTED]> wrote:
>
> >When I build the drivers in, it seems to work -
> >but I'm not sure why or if that was what made it
> >work as I was trying lots of things.
> >
> >So, I am really confused,
> >about scsi and initrd, because when
> >the drivers are built in
> >I cannot then build a new initrd.
> >
>
> If the SCSI driver is built in you don't need initrd. The initrd
> is a way to load a disk device driver before you can access the
> disk device that needs the disk device driver before the disk
> can be accessed. Initrd creates a ramdisk from where the disk
> device driver can be installed. If the device driver is built in
> there is no need to load the disk device driver, and therefore
> there is no need for an initial ramdisk, and thus no initrd.
>
> Villy
I am so DUMB!!!
No wonder I got a kernel panic.
If you were asked to read the disk
to get the disk driver that is needed
to read the disk before you can read the disk
then you would panic too!!
But now I am even more confused!!!!!
In order to build initrd, I HAD to do a
config saying that the scsi drivers were
modules. Otherwise building initrd complained
it could not find the scsi module.
But if I make the scsi driver a module, then
how does it get loaded when modules are loaded
after the root device is mounted????
Or does the initrd sort of preload the scsi module
before the root device gets accessed and it remains
loaded while the root device is switched?
Trying to think this one out feels like my brain
is being sucked into a black hole!
eric
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
