* Re: can chroot be made safe for non-root?
From: Bernd Eckenfels @ 2002-10-20 10:40 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200210191942.g9JJg2U26376@marc2.theaimsgroup.com>
In article <200210191942.g9JJg2U26376@marc2.theaimsgroup.com> you wrote:
> directory (I decided against making the chroot call fail, as any software
> buggy enough to chroot with open directory fds is likely to not check the
> return value of chroot(2), and blindly continue on failure--even worse).
> I'd be happy to hear about (and fix ;) anything I've missed.
One idea would be to sigsegv the program which is doing a chroot with open
fds :)
> IIRC, FreeBSD allow a chroot'ed process to chroot again if and only if
> the
> new root is a subdirectory of the initial chroot. This allows things
> like
> traditional, chrooting anonymous FTP to be run under an initial chroot.
well, you can only changeroot in a subdir anyway, so this is not the point
that freebsd is allowing a chroot in a chroot. As far as I know they simply
solved the break out issue.
BTW: kill on open fd would solve the breakout issue, too.
Greetings
Bernd
^ permalink raw reply
* Re: [LARGE patch 23/124] sets sent over and over again Re: [PATCH] ext2/3 updates for 2.5.44 (1/11): Default mount options in superblock
From: Arjan van de Ven @ 2002-10-20 10:35 UTC (permalink / raw)
To: Russell King
In-Reply-To: <20021020113135.A25278@flint.arm.linux.org.uk>
On Sun, Oct 20, 2002 at 11:31:35AM +0100, Russell King wrote:
> On Sun, Oct 20, 2002 at 12:09:35PM +0200, Arjan van de Ven wrote:
> > I hereby politely ask EVERYONE who wants to (re)posts large patchsets,
> > to at minimum try to follow something like the following politeness
> > guidelines
> >
> > 1) Make it ONE thread. Do this by cc or bcc'ing yourself on the mails
> > and use the reply feature of your mailer to reply each next number of
> > the set to the previous one. This allows people that use mail/news
> > readers that can do threading to properly sort it. This is not hard,
> > and I consider it the least you can do for the people that read lklm.
>
> It would be nice if someone scripted this - then people will be much more
> likely to follow it. It should be relatively trivial to script; you
> just need to generate the message id's and add the relevant headers.
>
> I'd like to question the appropriateness of such a blanket rule. I agree
> that it is appropriate for patches that are all part of the same area of
> the kernel (eg, ext2fs, ext3fs, trace toolkits, etc)
>
> However, is it appropriate to make one thread of a small set of unrelated
> patches that touch different, unrelated parts of the kernel?
That I would consider not "one patchkit" personally. And in general people
who have a set of such varying patches don't post [Patch 5/19].... Eg if a
patch makes sense on it's own (and I don't mean just the first
one) I don't think anyone would consider threading it appropriate. The
LTT, ext3, s390, lkcd, ALSA, hotplug (thanks for threading those Gregh!)
series however are obviously different from that.
> If all you want to do is delete them, I agree it does. However, that
> doesn't help the sender, who's reason for sending them is to get comments
> from the community.
It's not to "just" delete them. It's to *GROUP* them properly.
Greetings,
Arjan van de Ven
^ permalink raw reply
* YOUR STRICTEST CONFIDENCE REQUIRED.
From: Benson Cisse Traore @ 2002-10-20 12:44 UTC (permalink / raw)
To: linux-kernel
Hello,
However strange or surprising this contact might seem to you, I ask that you give due consideration to its importance, as we both stand to benefit immensely. Though we have not met or know each other, this is a criteria I have used to select you, as I wish to cut off all ties with my people for security and safety reasons.
At this point I wish to introduce myself properly to you. My name is Benson Cisse Traore, I am a personal aide to the Late General Robert Guei of blessed memory, former President of Cote de Ivoire (Ivory Coast).
I do not know if you are conversant with the present situation in my country, which has gradually become a civil war. For the sake of what I envisage we achieve together, I wish to give you a general overview.
We have had an undefined polity in my country. Founding president, Felix Houphouet-Boigny ruled us with individual blend of paternalism from independence in 1960 until his death in December 1993. He bowed to pressure for multi-party politics in 1990. In 1993, National Assembly president Henri Konan Bedie won a brief power struggle with Prime Minister Alassane Ouattara to succeed Houphouet-Boigny. The following month, the former single Ruling democratic Party set up by Houphouet-Boigny, then headed by Bedie won an overwhelming majority in the National assembly.
On December 24, 1999, my mentor Gen. Robert Guei ousted Bedie in a coup de tat. Although this was highly criticized, but it was the right thing to do. In July 2000, Gen. Guei approved a new constitution in referendum with tough eligibility conditions for presidential candidates. In spite of criticism, he registered as a candidate. The Supreme Court intervened, and he was cleared. This was not totally acceptable to the other candidates from the ruling Democratic Party (PDCI-RDA), the country's largest. The only opponent was Socialist candidate Laurent Gbagbo. Admittedly, Gbagbo won the election of October 22, 2000, but his political immaturity, led to Gen. Guei being reluctant to relinquish power. There were allegations of election rigging etc. Ouattara who was previously barred by the referendum to contest election, was excluded from the December 10 parliamentary election because of doubts about his nationality and his supporters announced they would boycott the election. Gbagbo’s Popular Front (FPI) was victorious in the election, and there were demonstrations due to propaganda that Gen. Guei tried to rig the election. Under pressure from international donors, Gbagbo agreed to hold a reconciliation forum to draw a line under the political strife that followed the 1999 coup, but key players including Outtara failed to show up for the opening.
After two years of build up, On September 19, 2002, Gen. Guei led a failed coup de tat against Gbagbo, in a bid to restore political stability. Unfortunately, he was killed. After Gen. Guei’s death, there was turmoil in our camp; this has led to us losing half our strength. Although we still control the north and Central regions of the country. It is now a question of who will give in between us (now referred to as “rebels”) and Gbagbo’s government. There seem to be no chance for peace, as several attempts has been botched by Gbagbo. The US and France has since evacuated their citizens from our country. Destruction is imminent, as ECOWAS (Economy Community of West African States) has been called in to mediate. Their only way of doing this is to bring in ECOMOG (A monitoring group). We witnessed the horror they caused trying to restore peace to Liberia and Sierra Leone during the civil war. Thus I have lost faith and hope in the struggle.
To the point, the essence of my contact with you is to seek your most needed assistance to siphon US$18,500,000 given to me for the purchase of arms and ammunination. Our Armory is seriously depleting, and I was sent on an emissary to make the purchase to strengthen our armory to prosecute the war. I have now decided to abandon the war and use this money for my personal benefit (as well as yours if you accept to be my partner). I see justification in diverting the money, rather than proceeding with the purchase of weapons for destruction of innocent lives and properties.
This money was moved in cash to my present location in Europe through diplomatic means, and I have since deposited the trunk containing the funds with a private security company. If you accept to offer me your assistance, I will require that you assist me in claiming the box as a gift from me to you from the security company. Be informed that I am confiding in you by disclosing this to you, as it is only me (apparently you now) that have knowledge of this. When the box is claimed, we shall then have the money deposited into an account in your name, as I am being discrete of using my name for now. Then you shall have your own share withdrawn to an account of your choice, and leaving the rest as fixed deposit, for release to me at the appropriate time.
The importance of prosecuting this in the next few days cannot be overlooked; hence your immediate response will be highly appreciated.
On hearing from you, I shall disclose my location to you, and discuss the share of the money you will be entitled to for offering me your most needed assistance.
In case you are not inclined to render me your assistance, endeavor to respond, so that I may move ahead.
You may click this link http://news.bbc.co.uk/1/hi/world/africa/930254.stm to see me with my mentor Gen. Guei in 1999, so that you may associate this correspondence to my face.
Sincerely,
B. C. Traore.
^ permalink raw reply
* Re: Problem with sending to the ELKS list :( (fwd)
From: Paul Nasrat @ 2002-10-20 10:43 UTC (permalink / raw)
To: linux-8086; +Cc: harkal
In-Reply-To: <Pine.LNX.4.33.0210200300290.18923-100000@olympus.btstream.com>
On Sun, Oct 20, 2002 at 03:10:56AM -0700, jb1@btstream.com wrote:
>
> IS YOUR SPAM FILTER CRAZY??? I HAD A PERFECTLY LEGITIMATE MESSAGE REFUSED
Umm, no need to shout.
AFAIK vger doesn't have any spam filtering.
Have just run mxverify on harkal@gmx.net and that seems ok - although it
may be an ECN issue.
I know vger will drop people if the mailserver is down.
http://www.tux.org/lkml/#s3-14
I'd recommend Harry resubscribe. It's happened to me before when my
mail servers were upgraded and fscked for a bit.
HTH
Paul
^ permalink raw reply
* Re: [discuss] Re: [PATCH] linux-2.5.43_vsyscall_A0
From: Elladan @ 2002-10-20 10:58 UTC (permalink / raw)
To: Andi Kleen
Cc: Elladan, Andi Kleen, Andrea Arcangeli, Jeff Dike, john stultz,
lkml, george anzinger, Stephen Hemminger, discuss, aj
In-Reply-To: <20021020112730.A29357@wotan.suse.de>
On Sun, Oct 20, 2002 at 11:27:30AM +0200, Andi Kleen wrote:
> On Sat, Oct 19, 2002 at 11:44:33PM -0700, Elladan wrote:
> > The problem with modifying the executable code/pages in the vsyscall
> > area is that it's going to be very tricky to implement, if I understand
> > this discussion properly.
>
> Modifying the pages or variables in the pages from the kernel is no
> problem. It just would affect all processes on the system
>
> What's tricky is to give it per process state (which would
> be needed to make a vsyscall/novsyscall flag process local)
Not really any more tricky than turning it off globally with a flag.
It's just more expensive, because you have to propagate the flag into
vsyscall space on the context switch. In the per-process case,
self-modifying code would be a less non-viable approach than it is
globally.
> > There may be any number of user processes idling in these pages on the
> > runqueue (or off it if say one received a SIGSTOP), and if you just go
> > change the instruction code on them, unless you're incredibly careful
> > and come up with some subtly safe machine code sequence, they're going
> > crash when you call this sysctl().
>
> Nobody proposed to use self modifying code, it would just be a global
> variable located in the vsyscall area that is tested by the vsyscall
> code.
Well, self modifying code certainly looked like what Andrea was talking
about, to avoid the branch overhead on the userspace gettimeofday()
call.
I suspect that outside of a few database apps, it's pretty unlikely that
there will be any vsyscalls in your average time slice, so putting the
overhead into the vsyscall itself seems like a better idea than paying
the price during every context switch.
Of course, if you're really strictly worried about being able to fully
virtualize the vsyscalls, a global flag isn't really enough. A user app
running under the virtual machine will still be able to manually access
the data on the vsyscall pages, and if it wants, jump into the middle of
a function or something like that. So eg. a UML instance being used as
a sandbox would still expose the host time and such to its hostile
userspace, which could then execute subsets of vsyscall code at will.
It seems that to fix this with proper data-hiding, it would really need
to be possible to set the vsyscall pages as invalid for the UML process
(so it could manually emulate the vsyscall), which would then either
require expensive contex-switching costs to make it a per-process flag,
or we're back to global self-modifying-code fixups.
Better to just ignore that particular issue.
-J
^ permalink raw reply
* Re: PROBLEM: ide-related kernel panic in 2.4.19 and 2.4.20-pre11
From: Denis Vlasenko @ 2002-10-20 15:46 UTC (permalink / raw)
To: Andre Hedrick, Brian Gerst; +Cc: Christian Borntraeger, linux-kernel
In-Reply-To: <Pine.LNX.4.10.10210191738160.24031-100000@master.linux-ide.org>
On 19 October 2002 22:41, Andre Hedrick wrote:
> > Nobody asked you to bypass the protection, only to sanely error out
> > when it is found. Refusing to read the disk is ok, but allowing
> > the system to crash is not.
>
> I thought I specified what was need to decode the issue, maybe since
> there are two multiple threads now I have lost track of which one I
> am responding. Thus I will repeat in this thread.
>
> True, however since I suspect the device was attempting to thwart and
> crash the system, until a trace of the sense data returns from the
> device and the re-action of the kernel to those target responses, not
> much can be done to prevent such a crash.
So how Christian Borntraeger <linux@borntraeger.net> can help you?
Is there any way to dump sense data and record kernel responses?
--
vda
^ permalink raw reply
* Re: [linux-lvm] creating a LVM ontop of a cryptated (ppdd) loop back device
From: Jon Bendtsen @ 2002-10-20 10:58 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20021020153212.GA2950@localhost>
Jose Luis Domingo Lopez wrote:
>
> On Sunday, 20 October 2002, at 10:19:11 +0200,
> Jon Bendtsen wrote:
>
> > > As said in my first post to this thread, the encryption layer is
> > > provided by loop-aes (loop-aes.sourceforge.net), which is easy to setup
> > > and is quite well documented (except for one little but annoying detail:
> > > instead of "AES", the algorithm is called "rijndael", otherwise "loop"
> > > complains loudly about an "unknown algorithm type").
> >
> > hmm ?? rijndael ?
> > I've used it just fine with losetup -e AES256
> >
> Just a final note, and trying not to go too off-topic, this is maybe an
> issue with my "mount" package version more than a "loop-aes" problem.
> But I am not sure of which program or code checks for the "correctness"
> of an algorithm name when you use "losetup" (in fact, the /proc/cipher
> files don't appear on my system :-).
>
> I will investigate it further, but this is off-topic here, so end of
> thread on my part ;-).
Not completely offtopic.
Why are you using mount ??
I'm talking about running LVM ontop of a encrypted loopback device, not
encrypting a lv.
JonB
^ permalink raw reply
* Re: ELKS FAQ Translated in Italian !
From: Paul Nasrat @ 2002-10-20 10:58 UTC (permalink / raw)
To: linux-8086
In-Reply-To: <200210201232.50647.pctips@hardwaretips.com>
On Sun, Oct 20, 2002 at 12:32:50PM +0000, pctips wrote:
> Did I do a stupid work ?
> There isn't anyone interested ?
No, it's just that the main developers seem a bit quiet atm.
Sadly I don't read Italian, but I'll have a look.
Thanks - don't think people aren't reading the list, it's just often too
busy with *work* to reply.
I don't think anyone is going to pay me to work on ELKS atm :)
I'm going to try and spend some time today doing some clean up, maybe
update the website, etc. If that happens and life doesn't get in the
way I'll put up the Italian translation.
Paul
^ permalink raw reply
* longjmp/setjmp in kernel
From: Keith Owens @ 2002-10-20 11:07 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20021020113135.A25278@flint.arm.linux.org.uk>
On Sun, 20 Oct 2002 11:31:35 +0100,
Russell King <rmk@arm.linux.org.uk> wrote:
>For instance, one of my patches - the rdunzip one. It would be _really_
>nice to get some feedback on it; it isn't perfect, because the behaviour
>of gunzip is inherently undeterministic when given bad input data. The
>only real solution IMHO is setjmp/longjmp, which I think would suck in
>the kernel. I would have expected _this_ to attract some comments from
>people like you. Maybe you feel that setjmp/longjmp is an approprate
>solution. Unfortunately, I don't know that because no one has replied
>to tell me so.
Why should setjmp/longjmp suck in kernel? I use it in kdb to recover
from debugging errors and to quit large amounts of output without
overloading every bit of debugging code with checks for "has the user
typed q?". It meant I had to write/modify setjmp/longjmp code to work in
the kernel for i386 and ia64, no big deal.
Given the kernel model, there are few places where setjmp/longjmp make
sense. If the code takes locks, disables interrupts etc. then forget
setjmp, cleanup after longjmp is too messy. But if you want to recover
from unexpected events in a large body of code which does not take
locks then it is a valid use for longjmp, especially if the code
requires several levels of function calls and you want to bail out from
a low level function.
^ permalink raw reply
* Re: [discuss] Re: [PATCH] linux-2.5.43_vsyscall_A0
From: Andi Kleen @ 2002-10-20 11:20 UTC (permalink / raw)
To: Elladan
Cc: Andi Kleen, Andi Kleen, Andrea Arcangeli, Jeff Dike, john stultz,
lkml, george anzinger, Stephen Hemminger, discuss, aj
In-Reply-To: <20021020105841.GA1024@eskimo.com>
On Sun, Oct 20, 2002 at 03:58:41AM -0700, Elladan wrote:
> Not really any more tricky than turning it off globally with a flag.
> It's just more expensive, because you have to propagate the flag into
> vsyscall space on the context switch. In the per-process case,
> self-modifying code would be a less non-viable approach than it is
> globally.
Umm, you forgot about SMP. Modifying it on context switch would require
per CPU mappings and vsyscall pages. Currently the kernel page tables
are shared globally, changing them to be CPU local would be somewhat
involved. While it would be doable as long as x86-64 is limited to three
level page tables for user space it would be a major pain as soon
as four level page tables were supported. In this case multiple threads
sharing the same mm but running on multiple CPUs couldn't share the same
page table anymore, and changing that would make threading significantly
more complicated. On i386 this problem is always there.
Also the context switch is a very critical path, we don't want to add
random junk like this in there.
> Well, self modifying code certainly looked like what Andrea was talking
> about, to avoid the branch overhead on the userspace gettimeofday()
> call.
A test+branch here is completely lost in the noise, not even
worth thinking about.
> It seems that to fix this with proper data-hiding, it would really need
> to be possible to set the vsyscall pages as invalid for the UML process
> (so it could manually emulate the vsyscall), which would then either
> require expensive contex-switching costs to make it a per-process flag,
> or we're back to global self-modifying-code fixups.
I have no problems at all with a system global flag. After all vsyscalls
are just an optimization. When you use UML you can't use that optimization,
very simple. It's similar to other circumstances that have an impact
on the whole system, e.g. when you use floating point in any process
then the context switch becomes slower for everybody. Not a big deal.
-Andi
^ permalink raw reply
* Re: Use of yield() in the kernel
From: Duncan Sands @ 2002-10-20 11:22 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel, Andrew Morton
In-Reply-To: <20021019220000.GC28445@atrey.karlin.mff.cuni.cz>
Well goodness me! That just goes to show that spending
all your time programming in other languages can be harmful
to your C (or: to your brain)! Let me just crawl away and find
a hole to die in before someone pours salt on me...
Ciao,
Duncan.
^ permalink raw reply
* ELKS site
From: Paul Nasrat @ 2002-10-20 11:39 UTC (permalink / raw)
To: linux-8086
I've just added the italian faq and updated the changelog.
I'm getting 404 on /faq/ now :(
Is this part of the standard sourceforge stuff which happens when you
update <project>web cvs repo or have I fscked the site? Or is it my
evil tranparent proxy of my upstream ISP.
Can someone have a peek and let me know if the site is there. It may
take a bit for the updates to propagate though.
Paul
^ permalink raw reply
* Re: Re: 2.4.19 orinoco_cs with Lucent WaveLAN "bronze"
From: Denis Vlasenko @ 2002-10-20 16:35 UTC (permalink / raw)
To: Bert Barbe, rmk; +Cc: jt, linux-kernel
In-Reply-To: <3187992.1035061003952.JavaMail.nobody@web54.us.oracle.com>
On 19 October 2002 18:56, Bert Barbe wrote:
> > On Sat, Oct 19, 2002 at 02:14:57PM +0000, Denis Vlasenko wrote:
> > > Today I played with wireless LAN euqipment for the first time.
> > > I have ISA-to-PCMCIA converter and a Lucent (IEEE) PCMCIA card.
> > > I set up everything as directed by HOWTOs. I do:
> >
> > Yes, I also noticed many problems with the current orinoco_cs
> > driver.
>
> I have an orinocco gold. In 2.4.x<19 it gave me some errors in the
> logs also, but despite that it seemed to work after setting the right
> options with iwconfig. I haven't tested 2.4.19 with the orinioco_cs
> driver yet since I had other problems with .19 before i got to that.
Can you be a bit more specific on that iwconfig options? ;-)
Also folks directed me to firmware upgrade, but it is for
Windows. Is there any for Linux? Did you upgrade yours?
--
vda
^ permalink raw reply
* Re: [linux-lvm] creating a LVM ontop of a cryptated (ppdd) loop back device
From: Jose Luis Domingo Lopez @ 2002-10-20 11:43 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <3DB2D26E.498738EC@silicide.dk>
On Sunday, 20 October 2002, at 17:57:34 +0200,
Jon Bendtsen wrote:
> Not completely offtopic.
>
I hope so :)
> Why are you using mount ??
>
What I described is an encrypted filesystem over a plain-and-simple LV,
and the procedure you could follow to take snapshots from this LV,
which holds an encrypted filesystem, and make filesystem-level backups
(such as those made with tar, cpio, rsync and others).
At least in Debian, "losetup" comes with the "mount" package.
> I'm talking about running LVM ontop of a encrypted loopback device, not
> encrypting a lv.
>
Then maybe we are talking about different things here. I used an
encrypted filesystem over an unencrypted LV but, as loop-aes needs the
loop device to operate, I need to loop-mount the encrypted filesystem for
the system to be able to on-the-fly decrypt its contents.
Maybe I am confused, because I don't fully understand what you mean by
"running LVM ontop of a encrypted loopback device".
--
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1)
^ permalink raw reply
* [2.5 patch] fix kbuild breakage in drivers/net/hamradio/soundmodem
From: Adrian Bunk @ 2002-10-20 12:06 UTC (permalink / raw)
To: sailer; +Cc: linux-kernel, trivial
drivers/net/hamradio/soundmodem/Makefile includes the following:
<-- snip -->
...
$(obj)/sm_tbl_%: $(obj)/gentbl
$(obj)/gentbl
<-- snip -->
gentbl is a program that generates some header files. The recent kbuild
changes have the "interesting" effect that this now outputs the header
files to the root directory of the kernel tree instead of
drivers/net/hamradio/soundmodem ...
The following patch fixes this breakage:
--- linux-2.5.44-full/drivers/net/hamradio/soundmodem/Makefile.old 2002-10-20 13:58:47.000000000 +0200
+++ linux-2.5.44-full/drivers/net/hamradio/soundmodem/Makefile 2002-10-20 13:59:04.000000000 +0200
@@ -38,5 +38,5 @@
$(obj)/sm_fsk9600.o: $(obj)/sm_tbl_fsk9600.h
$(obj)/sm_tbl_%: $(obj)/gentbl
- $(obj)/gentbl
+ cd $(obj) && ./gentbl
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [patch] Correct colour handling
From: Thiemo Seufer @ 2002-10-20 12:02 UTC (permalink / raw)
To: Martin Schulze; +Cc: linux-mips
In-Reply-To: <20021019165053.GR14430@finlandia.infodrom.north.de>
Martin Schulze wrote:
> Moin Ralf,
>
> please apply the patch below which will correct colour handling. The
> outcome of this patch will only be visible with a monochrome graphics
> card since they can see what is written on the screen again.
>
> As you can see, not all occasions where the currently used colour is
> changed, isn't protected by the 'if (can_do_color)' check. Some
> occurrences though use it.
>
> This patch is done basically by Thiemo Seufer during this years'
> Oldenburg meeting.
This is not-so-true, I didn't even touch the keyboard. ;-)
Thiemo
^ permalink raw reply
* Re: [linux-lvm] creating a LVM ontop of a cryptated (ppdd) loop back device
From: Jon Bendtsen @ 2002-10-20 12:04 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20021020164309.GA6596@localhost>
Jose Luis Domingo Lopez wrote:
>
> On Sunday, 20 October 2002, at 17:57:34 +0200,
> Jon Bendtsen wrote:
> Then maybe we are talking about different things here. I used an
> encrypted filesystem over an unencrypted LV but, as loop-aes needs the
> loop device to operate, I need to loop-mount the encrypted filesystem for
> the system to be able to on-the-fly decrypt its contents.
>
> Maybe I am confused, because I don't fully understand what you mean by
> "running LVM ontop of a encrypted loopback device".
We are talking different things.
I'll sum up what i did with 2 lines
losetup -e AES256 /dev/loop0 /dev/sdb1
pvcreate /dev/loop0
JonB
^ permalink raw reply
* Re: [LARTC] htb limiting trouble: no overlimit or dropped packets
From: Walter Haidinger @ 2002-10-20 12:18 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103480767301168@msgid-missing>
On Sat, 19 Oct 2002, Joseph Watson wrote:
> I don't see any mention of filters?? Don't you have to use a filter to put
> the traffic into the correct class?
Yes, if you want to distribute traffic between multiple classes. No, if
you're only using the default class (doesn't make much sense but for
testing only, of course).
Quoting from my inital post:
* All filters are scrapped for testing purposes, leaving only
unclassified packets which go the default class (this works)
My setup works now, if was using the wrong interface...
Regards, Walter
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [LARTC] HTB on 2.4.20pre10 kernel
From: Walter Haidinger @ 2002-10-20 12:26 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103446806913454@msgid-missing>
On Sun, 20 Oct 2002, Joseph Watson wrote:
> [root@dw jtwatson]# uname -a
> Linux 2.4.18-6mdk #1 Fri Mar 15 02:59:08 CET 2002 i586 unknown
> [root@dwwireless jtwatson]# lsmod
> Module Size Used by Not tainted
> sch_htb 12960 0 (autoclean) (unused)
> .....
>
> All looks good to me, I have the new tc binary in the current directory, and
> issue the following command:
>
> [root@dw jtwatson]# ./tc qdisc add dev eth1 root handle 1: htb default 12
> RTNETLINK answers: Invalid argument
From "Changes" on the HTB homepage:
* 15.8.2002
o HTB included in 2.4.20pre1 and next 2.5.x patch.
You're using kernel 2.4.18. Perhaps it does not include the HTB v3.6
patch, only HTB2. Then the kernel module would not understand the "new"
HTB3 tc commands.
Check your kernel syslog messages! 2.4.20pre10 gives me the following:
kernel: HTB init,kernel part version 3.7
Walter
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [2.5 patch] remove 2.4 compatibility code from irda/vlsi_ir.h
From: Adrian Bunk @ 2002-10-20 12:34 UTC (permalink / raw)
To: linux-irda, jt, Martin Diehl; +Cc: linux-kernel, trivial
I got the following compile error in 2.5.44:
<-- snip -->
...
gcc -Wp,-MD,drivers/net/irda/.vlsi_ir.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing
-fno-common -pipe -mpreferred-stack-boundary=2 -march=k6
-Iarch/i386/mach-generic -nostdinc -iwithprefix include -DKBUILD_BASENAME=vlsi_ir -c -o
drivers/net/irda/vlsi_ir.o drivers/net/irda/vlsi_ir.c
In file included from drivers/net/irda/vlsi_ir.c:53:
include/net/irda/vlsi_ir.h:30: parse error
make[3]: *** [drivers/net/irda/vlsi_ir.o] Error 1
<-- snip -->
vlsi_ir.h in 2.4 and 2.5 differ significantly, and I therefore suggest the
following patch to remove the compatibility stuff that caused this problem
(IMHO a better solution than an #include <linux/version.h>):
--- linux-2.5.44-full/include/net/irda/vlsi_ir.h~ 2002-10-19 06:01:59.000000000 +0200
+++ linux-2.5.44-full/include/net/irda/vlsi_ir.h 2002-10-20 14:23:32.000000000 +0200
@@ -27,26 +27,6 @@
#ifndef IRDA_VLSI_FIR_H
#define IRDA_VLSI_FIR_H
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,4)
-#ifdef CONFIG_PROC_FS
-/* PDE() introduced in 2.5.4 */
-#define PDE(inode) ((inode)->u.generic_ip)
-#endif
-#endif
-
-/*
- * #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,xx)
- *
- * missing pci-dma api call to give streaming dma buffer back to hw
- * patch floating on lkml - probably present in 2.5.26 or later
- * otherwise defining it as noop is ok, since the vlsi-ir is only
- * used on two oldish x86-based notebooks which are cache-coherent
- */
-#define pci_dma_prep_single(dev, addr, size, direction) /* nothing */
-/*
- * #endif
- */
-
/* ================================================================ */
/* non-standard PCI registers */
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: ELKS FAQ Translated in Italian !
From: pctips @ 2002-10-20 12:32 UTC (permalink / raw)
To: linux-8086
In-Reply-To: <200210161938.06649.windcd@genie.it>
Did I do a stupid work ?
There isn't anyone interested ?
ok
byez
pctips
^ permalink raw reply
* Re: [LARGE patch 23/124] sets sent over and over again Re: [PATCH] ext2/3 updates for 2.5.44 (1/11): Default mount options in superblock
From: Nicholas Wourms @ 2002-10-20 12:39 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1035108575.3130.10.camel@localhost.localdomain>
Arjan van de Ven wrote:
>
> 1) Make it ONE thread. Do this by cc or bcc'ing yourself on the mails
> and use the reply feature of your mailer to reply each next number of
> the set to the previous one. This allows people that use mail/news
> readers that can do threading to properly sort it. This is not hard,
> and I consider it the least you can do for the people that read lklm.
>
As someone who reads this list via Gmane, I couldn't agree more!
One other thing for IBM folk who are forced to use Lotus Notes:
Please, Please, Please set up Notes to post RFC 2822 compiant messages when
posting patches! Otherwise, the default Notes settings will litter these
messages (and smoetimes the text attachments) will all sorts of non-RFC
compliant MIME crap. Some mailers are able to cope with this, but many
aren't. If you don't believe me, check out some of the posts in the
Archives (note the "=3D" for CR\LF's). My thanks, however, for those IBM
folk who have already compensated for this.
Cheers,
Nicholas
^ permalink raw reply
* Re: Raid5, LVM and Reiserfs
From: Lars Marowsky-Bree @ 2002-10-20 12:33 UTC (permalink / raw)
To: darren, reiserfs-list
In-Reply-To: <000701c277c9$ef8d6c70$0101a8c0@bummer>
On 2002-10-20T07:47:50,
darren <teodarren@myrealbox.com> said:
> I need on RedHat 7.3 with 2.4.19:
>
> 1) Software RAID5 (any recommended settings?)
Just as recommended per man 5 raidtab -> parity-algorithm left-symmetric,
chunk-size might need some experimentation, but I recall 32k is usually OK.
> 2) Reiserfs (how do I make reiser over raid?)
The software raid device will show up as /dev/md0 (or similar); use that
blockdevice for creating the filesystem on.
> 3) I was told I need LVM too??
This is certainly a good idea. LVM will allow you to create many logical
volumes on a single software raid device; otherwise every block device you
want (ie, a separate filesystem) will require its own software raid device,
which will be a pain. Especially if you ever need to change sizes of the
devices or add/delete some, LVM will be a god-send.
> Any advise abt how I should go about this?
Carefully, as always ;-)
I suggest you read the software RAID howto. I am surprised that RHAT doesn't
offer selecting software raid right in the installer?
Sincerely,
Lars Marowsky-Brée <lmb@suse.de>
--
Principal Squirrel
SuSE Labs - Research & Development, SuSE Linux AG
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
-- Capt. Edward A. Murphy -- Louis Pasteur
^ permalink raw reply
* [PATCH][TRIVIAL] 2.5.44 Typo in include/linux/pnp.h
From: Andreas Tscharner @ 2002-10-20 12:50 UTC (permalink / raw)
To: Linux Kernel Mailinglist
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
Heelo World,
The attached patch corrects a typo in include/linux/pnp.h (A ')' instead
of a '}') that avoids compiling.
Regards
Andreas
--
Andreas Tscharner starfire@dplanet.ch
----------------------------------------------------------------------
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning."
-- Rich Cook
[-- Attachment #2: pnp_h.patch --]
[-- Type: application/octet-stream, Size: 694 bytes --]
--- include/linux/pnp.h.orig 2002-10-20 14:27:06.000000000 +0200
+++ include/linux/pnp.h 2002-10-20 14:29:24.000000000 +0200
@@ -245,7 +245,7 @@
/* just in case anyone decides to call these without PnP Support Enabled */
static inline int pnp_protocol_register(struct pnp_protocol *protocol) { return -ENODEV; }
-static inline void pnp_protocol_unregister(struct pnp_protocol *protocol) { ; )
+static inline void pnp_protocol_unregister(struct pnp_protocol *protocol) { ; }
static inline int pnp_init_device(struct pnp_dev *dev) { return -ENODEV; }
static inline int pnp_add_device(struct pnp_dev *dev) { return -ENODEV; }
static inline void pnp_remove_device(struct pnp_dev *dev) { ; }
^ permalink raw reply
* Re: [PATCH] work around duff ABIs
From: Matthew Wilcox @ 2002-10-20 12:51 UTC (permalink / raw)
To: Erik Andersen, Matthew Wilcox, Alexander Viro, linux-kernel
In-Reply-To: <20021020045149.GA27887@codepoet.org>
On Sat, Oct 19, 2002 at 10:51:49PM -0600, Erik Andersen wrote:
> Nonono. Please see __LONG_LONG_PAIR in /usr/include/endian.h.
> Your user space code should be doing something like this:
>
> static inline _syscall5(ssize_t, __syscall_pread, int, fd, void *, buf,
> size_t, count, off_t, offset_hi, off_t, offset_lo);
>
> ssize_t __libc_pread(int fd, void *buf, size_t count, off_t offset)
> {
> return(__syscall_pread(fd,buf,count,__LONG_LONG_PAIR((off_t)0,offset)));
> }
>
> ssize_t __libc_pread64(int fd, void *buf, size_t count, off64_t offset)
> {
> return(__syscall_pread(fd, buf, count,
> __LONG_LONG_PAIR((off_t)(offset>>32),
> (off_t)(offset&0xffffffff))));
> }
>
> Your patch is going to break GNU libc, uClibc, and anyone else in
> userspace that is doing pread and pread64 correctly....
Well... since you just proved that you don't understand the problem,
I'd hazard a guess that uClibc is also broken, as well as glibc.
Here's how the ABI specifies that pread() shall take its arguments:
asmlinkage ssize_t sys_pread64(unsigned int fd, char *buf, size_t count,
loff_t pos)
fd arg0
buf arg1
count arg2
pos arg4 & arg5
Here's what __LONG_LONG_PAIR does:
fd arg0
buf arg1
count arg2
pos(HI) arg3
pos(LO) arg4
--
Revolutions do not require corporate support.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.