date:20010803

Re: keep-state rule for icmp, really stateful ???

2001-08-03 Thread Dennis Berger

Sorry I missed something ...
forget
- Original Message -
From: Peter Pentchev [EMAIL PROTECTED]
To: Dennis Berger [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, August 02, 2001 7:26 PM
Subject: Re: keep-state rule for icmp, really stateful ???

 On Thu, Aug 02, 2001 at 05:22:36PM +0200, Dennis Berger wrote:
  Hi
  I have the following rule allowing traceroute and ping to my server.
  200 allow icmp from any to any keep-state in recv tun0 icmptype 8
  Now I would assume that this rule generate two dynamic rules back.
  The fire one is a rule that initiates ping to work properly it's just a
dynamic ICMP rule
  00200 2623 220332 (T 30, # 43) ty 0 icmp, 134.100.58.115 0 -
213.23.32.88 0
  and the second that the traceroute UDP taffic from port 33434-33960 can
pass in.
  But what happans ... the rule 200 doesn't open a second dynamic rule to
allow udp traffic to specific ports back in, the traceroute UDP traffic will
be blocked. To keep the icmp packetfiltering stateful it would be nice to
implement this clean. Or maybe it is already implemented in CURRENT tree.
What's the current state ?

 E.. maybe it's just me, but I just can't see how a rule that says
 'allow icmp' should allow UDP traffic to pass through..
 Maybe you haven't shown us all the rules?  (And I don't necessarily
 mean 'all the rules pertaining to icmp and traceroute'.. it might
 as well be that some other rule, which you do not consider relevant,
 is blocking your traceroute packets.)

 G'luck,
 Peter

 --
 I am jealous of the first word in this sentence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message

Re: How to visit physical memory above 4G?

2001-08-03 Thread Terry Lambert


mark tinguely wrote:
   Also, the PIII CAN'T natively support more than 4GB of ram. If a
   particular PIII motherboard supports this, then it's using some kind of
   wierd chipset that allows this to happen. 4GB is the limit with a 32 bit
   chip I believe; and the PIII is a 32-bit chip.
 
 Since the Pentium Pro processor, the Intel chipsets support a
 physical address extension (PAE) which has 4 extra addressing
 bits, and a third level of page table indirection called the
 page-directory-pointer-table base address field.

Bit 5 of control register 4, and then it uses the top 27 bits
of control register 3 to select a 32 byte aligned region in
the lower 4G.  It also changes the PSE bit to refer to 2M
instead of 4M pages, so your would needto DISABLE_PSE, or the
FreeBSD kernel would freak when it enabled the 4M page on
the kernel itself.

Then the high 4 bits are used to pick a pointer entry (which
is effectively a software segment register select, for all
practical purposes), giving you 64G of addressable space,
in chunks of 4G at a time.

Practically, you end up having to overlap this, which tends
to cut you down to 32G.


 The addressing use 64 bits for a memory pointer and the additional
 page indirection add to the overhead. The stickler is the MMU is
 still 32 bits. This means the PAE must segment the 64GB space into
 4GB segments or 4 1GB segments. The OS must manage which pages are
 viewable to the process at this time.

Not only that: you reload CR3, and none of these pages are
really global, so you can't set the PG_G bit, and so you
get the full TLB shootdown on everything, so a segment switch
ends up shooting _everything_ down.


 There is a third mode of addressing using 2MB pages (simular to the
 4MB page addressing mode for the 32 bit addressing scheme) that will
 only give a process access to 4GB of memory (not segmentable to
 a larger space, but can address physical memory located above the 4GB
 address).

Not really useful, unless you go back to a task gate, which
itself will limit you to 1024 things; with code + data, you
end up halving that to 512, minus overhead drops it to 510,
so you end up with a limitation on number of processes.  You
could do all the switching manually, but it is very, very hard.

Further, you can write off shared memory and shared libraries,
and some types of IPC (e.g. descriptor passing), unless you
want to rework everything.

IMO, the resulting kernel would be so slow as to prevent the
changes from being useful, due to their expense.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message

Re: How to visit physical memory above 4G?

2001-08-03 Thread Rik van Riel


On Thu, 2 Aug 2001, Julian Elischer wrote:
 On Thu, 2 Aug 2001, Rik van Riel wrote:
 
  On the really large machines, this can lead to the
  situation where even the page tables hardly fit into
  KVA. 4MB pages seem like the only solution ...

 There is no reason why we need to keep the kernel and the user
 process in the same 4GB map except for efficiency.

 There have been many UNIX machines in the past which put them in
 separate virtual spaces

That was on machines where the CPU could actually
address two separate spaces at once, right ?
(like eg. m68k)

 The kernel would haev 4GB for itself and each process would have 4BG.

 System calls would be come more expensive as each would require
 a full page-table swap and a TLB flush.
 However it might be worth it for some people.

Interrupt handling would also require a full page table
swap and TLB flush.

Considering that, I think the number of people for whom
this will be worth it has probably dropped a bit ;)

Rik
--
Executive summary of a recent Microsoft press release:
   we are concerned about the GNU General Public License (GPL)


http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message

6G memory disks?

2001-08-03 Thread David Gilbert


I suppose a 6G md memory disk is impossible?  I recently applied all 
the patches recomended here and even got a 6G memory disk newfs'd
and mount'd ... but when I ran bonnie (with size 100M) on it, it
failed.

Dave.

-- 

|David Gilbert, Velocet Communications.   | Two things can only be |
|Mail:   [EMAIL PROTECTED] |  equal if and only if they |
|http://www.velocet.net/~dgilbert |   are precisely opposite.  |
=GLO

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message

Re: How to visit physical memory above 4G?

2001-08-03 Thread Julian Elischer




On Thu, 2 Aug 2001, Terry Lambert wrote:

 
 Name an OS that supports this; more than likely, you will
 have to appeal to a purpose built embedded system.


errr, linux?

 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message

Re: How to visit physical memory above 4G?

2001-08-03 Thread Terry Lambert


John Baldwin wrote:
 Err. hang on.  This has zero to do with segmentation.  Zip, nada.
 PAE is completely in the paging side of things.  No matter what
 fun games you play with segmentation, you still end up with a
 32-bit linear address that gets handed off to the paging translations.
 PAE just allows you to use more backing store across multiple
 processes, but you are still stuck with a 4gb virtual address
 space for processes.  (Including KVM)

IMO, the 4 bit selector register is the moral equivalent
of a segment register.

Personally, I think it's much less useful to run the kernel
out of KVA space, than it is to have more memory available
to the kernel for things like mbufs, so I'm not really very
interested in trying to raise the per process address space
limits this way.  You could actually get 4G for the kernel
and 4G for processes using this, but you would only need two
segments to make this happen; mapping the other stuff at
the same time makes little sense: you just map a window on
it to implement region overlays for user or kernel data
paging.

Given the compiler tools we have, this still limits you to
using only 4G in a given VA space, unless you did something
evil, like add HLOCK/HUNLOCK, etc..


  But to directly answer your question: by rewriting much of the
  low core virtual memory and page mapping handling code to know
  about segmentation.
 
 No, to rewrite said code to handle a different type of page table
 structure.

Virtual table structure/segements: same difference: I'm now
wdoing in software what I bought hardware to get away from
having to do in software.

Given the vastly simplified page management in Linux, I
could see how there wouldn't really be a big performance
loss over the way Linux does things without this, so it
might be OK, so long as there were no shared memory regions,
semaphores, etc..  That really makes it pretty useless.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message

Ïðåäëàãàåì ïðèîáðåñòè â ñîáñòâåííîñòü àäìèíèñòðàòèâíîå çäàíèå â Êàçàíè
(Òàòàðñòàí, Ðîññèÿ):
- Îáùàÿ ïëîùàäü 910 êâ. ì;
- 2 ýòàæà;
- Áîëüøîå êîëè÷åñòâî ïîìåùåíèé îò 7 äî 200 êâ.ì;
- Ñîáñòâåííàÿ òåððèòîðèÿ - çåìåëüíûé ó÷àñòîê 0,101 Ãà.

Çäàíèå - áûâøàÿ ñòîëîâàÿ ðå÷íîãî ïîðòà. Èìååò âûãîäíîå ðàñïîëîæåíèå:
- íàïðîòèâ çäàíèÿ - âòîðîé ïî âåëè÷èíå îïòîâûé ïðîäóêòîâûé ãîðîäñêîé ðûíîê;
- óäîáíûå ïîäúåçäíûå ïóòè;
- áëèçêî ê öåíòðó ãîðîäà - 5 ìèí. åçäû;
- áëèçêî ê æ/ä âîêçàëó - 5 ìèí. åçäû;
- ðÿäîì ðå÷íîé ïîðò;
- ðÿäîì æ/ä ïóòè.

Çäàíèå èäåàëüíî ïîäõîäèò äëÿ ðàçìåùåíèÿ îôèñà ïðåäñòàâèòåëüñòâà Âàøåé
êîìïàíèè â Òàòàðñòàíå èëè Ïîâîëæüå. Âîçìîæíà êîìïîíîâêà îôèñ/ñêëàä. Âñå
êîììóíèêàöèè ïîäâåäåíû. Çäàíèå òðåáóåò ðåìîíòà (ïîëíàÿ âíóòðåííÿÿ îòäåëêà,
âêëþ÷àÿ íîâûå îêîííûå è äâåðíûå áëîêè). Çäàíèå íàõîäèòñÿ â ÷àñòíîé
ñîáñòâåííîñòè. Çåìëÿ - â áåññðî÷íîì ïîëüçîâàíèè.

Öåíà çäàíèÿ - ÁÎËÅÅ ×ÅÌ ÄÎÑÒÓÏÍÀ.

Åñëè âû çàèíòåðåñîâàíû â ïîëó÷åíèè îò íàñ áîëåå ïîäðîáíîé èíôîðìàöèè î
äàííîì îáúåêòå, îòïðàâüòå ïóñòîå ïèñüìî ïî àäðåñó: [EMAIL PROTECTED] Ïðè
ýòîì â Òåìå ñîîáùåíèÿ ÎÁßÇÀÒÅËÜÍÎ óêàæèòå:
Ïðèøëèòå ïîäðîáíóþ èíôîðìàöèþ.

87 matches

Mail list logo