Re: panic: random.ko
Roman Neuhauser writes: Did you type the exact THREE commands as shown above? Of course, it's been three weeks since I had that problem so I would be insane to claim I have exact recollection. I might have been typing unload boot /boot/kernel/kernel over and over again in an attempt to convince myself that I had made a typo, but I doubt that. Nevertheless, would that make a difference? Yes. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] Raw sockets in jails
Christian S.J. Peron [EMAIL PROTECTED] scribbled: Poul/group The following patch makes raw sockets comply with prison IP addresses. Some tools such as traceroute(8) may require that the prison IP address be specified on the command line. I.E. traceroute -s prison ip dest address Otherwise it might fail. (because of this we may want to get rid of the create_raw_sockets MIB all together). Anyway, take a gander at it (testers feedback welcome): Regards Christian S.J. Peron Nice work! It doesn't seem that it would be very difficult to get this to comply with Pawels multiple IPs in jail patch, but it would have to be optimized a bit as the IPs are currently stored in a linked list in his patch and traversing that list to determine whether the IP complies with the jails allotted IP range is sub-optimal (as it would have to be done on a per-packet basis). If we could store those IPs in a hash table with a fast algorithm for O(1) lookup times, the prison subsystem would experience significant feature improvements. -- Kind regards, Devon H. O'Dell | [EMAIL PROTECTED] ICQ: 2903604| IRC: [EMAIL PROTECTED]/[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Changing ttl of incoming packets
Hello, Is there any way to change ttl of incoming packet to a lower value ? I had tried min-ttl option in pf packet filter but this option only increase ttl to a given value when ttl is lower than this value. I have searched on google and mailing lists but i do not find any answer. I am running Freebsd 5.2.1 and i am using pf as my packet filter. Thanks for any tips -- Best Regards: GiZmen UNIX is user-friendly; it's just picky about its friends UNIX is simple; it just takes a genius to understand its simplicity ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] Raw sockets in jails
On Tue, Apr 20, 2004 at 08:00:27PM +, Christian S.J. Peron wrote: + Poul/group + + The following patch makes raw sockets comply with prison IP addresses. + Some tools such as traceroute(8) may require that the prison IP address + be specified on the command line. I.E. + + traceroute -s prison ip dest address + + Otherwise it might fail. + + (because of this we may want to get rid of the + create_raw_sockets MIB all together). + + Anyway, take a gander at it (testers feedback welcome): Looks very neat! I've merge your patch to my jail work (pjd_jail perforce branch) and changed it to be usable with my multiple ips stuff. I haven't reviewed nor tested it yet. -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgp0.pgp Description: PGP signature
Re: [patch] Raw sockets in jails
, 22.04.2004, 14:30, Pawel Jakub Dawidek : On Tue, Apr 20, 2004 at 08:00:27PM +, Christian S.J. Peron wrote: + Poul/group + + The following patch makes raw sockets comply with prison IP addresses. + Some tools such as traceroute(8) may require that the prison IP address + be specified on the command line. I.E. + +traceroute -s prison ip dest address + + Otherwise it might fail. + + (because of this we may want to get rid of the + create_raw_sockets MIB all together). + + Anyway, take a gander at it (testers feedback welcome): Looks very neat! I've merge your patch to my jail work (pjd_jail perforce branch) and changed it to be usable with my multiple ips stuff. I haven't reviewed nor tested it yet. You don`t plain do port vimage to -current ? -- Alex Lyashkov [EMAIL PROTECTED] PSoft ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing ttl of incoming packets
On Thu, Apr 22, 2004 at 11:54:15AM +0200, GiZmen wrote: Hello, Is there any way to change ttl of incoming packet to a lower value ? I had tried min-ttl option in pf packet filter but this option only increase ttl to a given value when ttl is lower than this value. I have searched on google and mailing lists but i do not find any answer. I am running Freebsd 5.2.1 and i am using pf as my packet filter. You mean, make the IP forwarding decrement the IP TTL more than by one? Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Changing ttl of incoming packets
Ruslan Ermilov writes: On Thu, Apr 22, 2004 at 11:54:15AM +0200, GiZmen wrote: Hello, Is there any way to change ttl of incoming packet to a lower value ? I had tried min-ttl option in pf packet filter but this option only increase ttl to a given value when ttl is lower than this value. I have searched on google and mailing lists but i do not find any answer. I am running Freebsd 5.2.1 and i am using pf as my packet filter. You mean, make the IP forwarding decrement the IP TTL more than by one? Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer i've seen some cable/dsl ips's to do this, they set the IP TTL to 1 on the downlink to the client. (as a lame attempt to stop people sharing their connection) So if one put some sort of gateway on the dsl/cable modem, all the packets it receives are with IP TTL 1, and the gateway will not able to forward them to the internal network... which is in my opinion 1-st ugly, and 2-nd, easily avoidable with min-ttl for example :) but if pf has min-ttl it seems that max-ttl can be easily added. also i think i've seen somewhere on the net a netgraph module that can modify ttl's and some other things. i think it's name was ng_mangle --niki pgp0.pgp Description: PGP signature
Re: [patch] Raw sockets in jails
I discovered the reason why traceroute breaks without -s with the most
recent patches I posted to the list.
When traceroute can not figure out what its source IP address is, it
generates a RTM_GET routing request through a routing socket and
extracts the source address of the route given the destination.
I have created a new set of patches, the only real difference is I modified
the routing code so that when it receives a RTM_GET request from a jailed
process, it re-defines the source address of the route so that it corresponds with
the prisons IP.
I have tested these patches and they appear to work, however
I ask for people to test and scrutinize these patches.
Feedback/comments are welcome.
Regards
Christian S.J. Peron
new and improved patch ---
--- sys/kern/kern_jail.c.bakMon Apr 19 16:55:40 2004
+++ sys/kern/kern_jail.cMon Apr 19 17:56:03 2004
@@ -53,6 +53,11 @@
jail_sysvipc_allowed, 0,
Processes in jail can use System V IPC primitives);
+intjail_allow_raw_sockets = 0;
+SYSCTL_INT(_security_jail, OID_AUTO, allow_raw_sockets, CTLFLAG_RW,
+jail_allow_raw_sockets, 0,
+Prison root can create raw sockets);
+
/* allprison, lastprid, and prisoncount are protected by allprison_mtx. */
struct prisonlist allprison;
struct mtx allprison_mtx;
--- sys/net/rtsock.c.bakWed Apr 21 03:09:41 2004
+++ sys/net/rtsock.cThu Apr 22 17:37:42 2004
@@ -52,6 +52,8 @@
#include net/raw_cb.h
#include net/route.h
+#include netinet/in.h
+
MALLOC_DEFINE(M_RTABLE, routetbl, routing tables);
/* NB: these are not modified */
@@ -289,6 +291,7 @@
int len, error = 0;
struct ifnet *ifp = 0;
struct ifaddr *ifa = 0;
+ struct sockaddr_in jail;
#define senderr(e) { error = e; goto flush;}
if (m == 0 || ((m-m_len sizeof(long))
@@ -400,8 +403,14 @@
ifp = rt-rt_ifp;
if (ifp) {
info.rti_info[RTAX_IFP] =
TAILQ_FIRST(ifp-if_addrhead)-ifa_addr;
- info.rti_info[RTAX_IFA] =
- rt-rt_ifa-ifa_addr;
+ if (so-so_cred-cr_prison) {
+ jail.sin_family = PF_INET;
+ jail.sin_len = sizeof(jail);
+ jail.sin_addr.s_addr =
htonl(so-so_cred-cr_prison-pr_ip);
+ info.rti_info[RTAX_IFA] = (struct
sockaddr *)jail;
+ } else
+ info.rti_info[RTAX_IFA] =
+ rt-rt_ifa-ifa_addr;
if (ifp-if_flags IFF_POINTOPOINT)
info.rti_info[RTAX_BRD] =
rt-rt_ifa-ifa_dstaddr;
--- sys/netinet/raw_ip.c.b Mon Apr 19 16:23:57 2004
+++ sys/netinet/raw_ip.cThu Apr 22 18:30:42 2004
@@ -40,6 +40,7 @@
#include opt_random_ip_id.h
#include sys/param.h
+#include sys/jail.h
#include sys/kernel.h
#include sys/lock.h
#include sys/mac.h
@@ -215,6 +216,10 @@
if (inp-inp_faddr.s_addr
inp-inp_faddr.s_addr != ip-ip_src.s_addr)
goto docontinue;
+ if (inp-inp_socket-so_cred-cr_prison)
+ if (htonl(inp-inp_socket-so_cred-cr_prison-pr_ip)
+ != ip-ip_dst.s_addr)
+ goto docontinue;
if (last) {
struct mbuf *n;
@@ -270,7 +275,11 @@
ip-ip_off = 0;
ip-ip_p = inp-inp_ip_p;
ip-ip_len = m-m_pkthdr.len;
- ip-ip_src = inp-inp_laddr;
+ if (inp-inp_socket-so_cred-cr_prison)
+ ip-ip_src.s_addr =
+ htonl(inp-inp_socket-so_cred-cr_prison-pr_ip);
+ else
+ ip-ip_src = inp-inp_laddr;
ip-ip_dst.s_addr = dst;
ip-ip_ttl = inp-inp_ip_ttl;
} else {
@@ -279,6 +288,13 @@
return(EMSGSIZE);
}
ip = mtod(m, struct ip *);
+ if (inp-inp_socket-so_cred-cr_prison) {
+ if (ip-ip_src.s_addr !=
+ htonl(inp-inp_socket-so_cred-cr_prison-pr_ip)) {
+ m_freem(m);
+ return (EPERM);
+ }
+ }
/* don't allow both user specified and setsockopt options,
and don't allow packet length sizes that will crash */
if (((ip-ip_hl != (sizeof (*ip) 2))
@@ -505,6 +521,7 @@
}
}
+extern int
Re: panic: random.ko
# [EMAIL PROTECTED] / 2004-04-22 08:02:04 +0100: Roman Neuhauser writes: Did you type the exact THREE commands as shown above? Of course, it's been three weeks since I had that problem so I would be insane to claim I have exact recollection. I might have been typing unload boot /boot/kernel/kernel over and over again in an attempt to convince myself that I had made a typo, but I doubt that. Nevertheless, would that make a difference? Yes. Indeed, booting GENERIC with unload load kernel boot (or load /boot/kernel/kernel) works now, and would have worked then if I didn't screw up somehow. Sorry for the waste of time. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing ttl of incoming packets
Is there any way to change ttl of incoming packet to a lower value ? I had tried min-ttl option in pf packet filter but this option only increase ttl to a given value when ttl is lower than this value. I have searched on google and mailing lists but i do not find any answer. I am running Freebsd 5.2.1 and i am using pf as my packet filter. You mean, make the IP forwarding decrement the IP TTL more than by one? i've seen some cable/dsl ips's to do this, they set the IP TTL to 1 on the downlink to the client. (as a lame attempt to stop people sharing their connection) So if one put some sort of gateway on the dsl/cable modem, all the packets it receives are with IP TTL 1, and the gateway will not able to forward them to the internal network... which is in my opinion 1-st ugly, and 2-nd, easily avoidable with min-ttl for example :) but if pf has min-ttl it seems that max-ttl can be easily added. also i think i've seen somewhere on the net a netgraph module that can modify ttl's and some other things. i think it's name was ng_mangle ---end quoted text--- Yes true i saw some gateways that use this trick too and that was my inspiration to look around how it can be done. But i didnt found any option to do that. max-ttl option would be a good idea to add to pf :) So there is no posibility to change ttl with kernel or some other tool. So how this dsl/cable modem gateways change theirs ttl to 1? thx -- Best Regards: GiZmen UNIX is user-friendly; it's just picky about its friends UNIX is simple; it just takes a genius to understand its simplicity ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing ttl of incoming packets
On Thu, Apr 22, 2004 at 11:54:15AM +0200, GiZmen wrote: Hello, Is there any way to change ttl of incoming packet to a lower value ? I had tried min-ttl option in pf packet filter but this option only increase ttl to a given value when ttl is lower than this value. I have searched on google and mailing lists but i do not find any answer. I am running Freebsd 5.2.1 and i am using pf as my packet filter. You mean, make the IP forwarding decrement the IP TTL more than by one? ---end quoted text--- No, i want to change ttl to whatever value i want. For example i want to changle ttl value for any packet incoming to my iface to 10 value. I only want to know that is there some tool or option or anything else to set this. -- Best Regards: GiZmen UNIX is user-friendly; it's just picky about its friends UNIX is simple; it just takes a genius to understand its simplicity ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to flush out cache.?
Matthew Dillon wrote:
:Yes - but FreeBSD then calls vm_object_page_remove to remove the pages
:from the vnode object. (vm_object_sync for 5.x or vm_map_clean for 4.x )
... SNIP ...
I don't quite see that. Could you point out the code in question?
(And, of course, a test program would tell us for sure whether that
hole exists). There are two different things being removed... the
page table entries are removed from pmap via the vm_map for the process,
and the pages in the underlying object are being cleaned.
Just removing pages from a pmap will not destroy the underlying pages.
For 4.X
msync() - vm_map_clean() - vm_object_page_remove()
4.X vm_map_clean()
if (object invalidate
((object-type == OBJT_VNODE) ||
(object-type == OBJT_DEVICE))) {
vm_object_reference(object);
vm_object_page_remove(object,
OFF_TO_IDX(offset),
OFF_TO_IDX(offset + size + PAGE_MASK),
FALSE);
vm_object_deallocate(object);
}
...
For 5.X (current)
msync() - vm_map_sync() - vm_object_sync() - vm_object_page_remove()
vm_object_page_remove() in 4.X and 5.X calls vm_page_free() for pages that are
not wired and zeroes p-valid for wired pages.
Unfortunately this does not play well together with the buffer layer
(vfs_bio.c).
The layer caches vmio buffers and as such will keep the pages wired.
On a cache hit it does not check if the pages of the vmio buffer are still
valid. ( See test program timetravel why I consider this a bug)
This means that a normal file read() or write() access using these buffers
will act on pages marked invalid.
However accesses through the mmap interface will encounter the invalid pages
and force a reload.
I wrote a few (throw away) test programs attached below.
uncache.c: mmap()s a file and calls msync(...MS_INVALIDATE..)
pagetouch.c: mmap()s a file and reads the first byte from every page to force
the pages to load/reload.
(and prints out the char sum of all the bytes)
timetravel.c: shows an example on how the current vmio/msync interaction
can cause interesting problems.
Try the following:
dd if=/dev/zero of=testfile bs=8k count=32768
time ./pagetouch testfile
time ./pagetouch testfile
./uncache testfile
time ./pagetouch testfile
time ./pagetouch testfile
Run ./timetravel testfile2 and look at the source to see some problems
caused
by the vmio/msync interaction bug.
For the original problem the sequence (./uncache file ; ./pagetouch file)
reloads all file data from stable storage.
All programs were tested on 5.2.1
Stephan
PS: Postponing send-pr for a few days.
#include fcntl.h
#include sys/mman.h
#include unistd.h
#include stdio.h
#include sys/types.h
#include sys/stat.h
#define MMAP_MAX_SIZE (1024 * 1024 * 128)
int main(int argc, char *argv[], char *envp[])
{
int fd;
char* filename;
void* addr;
off_t size,todo,offset;
struct stat stat;
int status;
if (argc != 2)
{
printf(Usage: %s filename\n,argv[0]);
exit(1);
}
filename = argv[1];
fd = open(filename,O_RDWR);
if (fd 0) {
perror(Open failed);
exit(1);
}
status = fstat(fd,stat);
if (status 0) {
perror(fstat failed);
exit(1);
}
size = stat.st_size;
offset = 0;
while(offset size)
{
todo = size - offset;
todo = (todo MMAP_MAX_SIZE) ? todo : MMAP_MAX_SIZE;
addr = mmap(NULL,(size_t) todo,PROT_WRITE | PROT_READ,MAP_SHARED,fd,offset);
if (addr == NULL)
{
perror(mmap failed);
exit(1);
}
status = msync(addr,(size_t) todo,MS_SYNC | MS_INVALIDATE);
if (status 0)
{
perror(msync failed);
exit(1);
}
status = munmap(addr,(size_t) todo);
if (status 0)
{
perror(munmap failed);
exit(1);
}
offset += todo;
}
status = close(fd);
if (status 0)
{
perror(close failed);
exit(1);
}
exit(0);
}
#include fcntl.h
#include sys/mman.h
#include unistd.h
#include stdio.h
#include sys/types.h
#include sys/stat.h
#define MMAP_MAX_SIZE (1024 * 1024 * 128)
int main(int argc, char *argv[], char *envp[])
{
int fd;
char* filename;
void* addr;
off_t size,todo,offset;
struct stat stat;
int status;
char *c;
char s;
int pagesize;
int addrOffset;
if (argc != 2)
{
printf(Usage: %s filename\n,argv[0]);
exit(1);
}
filename = argv[1];
fd = open(filename,O_RDWR);
if (fd 0) {
perror(Open failed);
exit(1);
}
status = fstat(fd,stat);
if (status 0) {
perror(fstat failed);
exit(1);
}
size
Re: events when (de)associating or when cable is (un)plugged
Ok, I tried to implement this tonight but it doesn't work in FreeBSD. I don't
get any notification when the cable is unplugged or plugged. I don't get it,
maybe someone else sees it, I don't.
miibus_linkchg gets called pretty frequently but the detection logic seems to
be flawed. For some reason it doesn't detect cable changes. When I change the
media with ifconfig from auto to 100BaseTX and back it reports correctly.
Tested with fxp and bge interfaces.
In OpenBSD it works perfectly (fxp interface). Unplug cable, message comes
up, plug cable, message comes up. I can't see any logical difference between
OpenBSD/NetBSD and or MII variant.
--
Andre
Index: dev/mii/mii.c
===
RCS file: /home/ncvs/src/sys/dev/mii/mii.c,v
retrieving revision 1.17
diff -u -p -r1.17 mii.c
--- dev/mii/mii.c 24 Aug 2003 17:54:10 - 1.17
+++ dev/mii/mii.c 23 Apr 2004 01:16:06 -
@@ -58,6 +58,7 @@ __FBSDID($FreeBSD: src/sys/dev/mii/mii.
#include net/if.h
#include net/if_media.h
+#include net/route.h
#include dev/mii/mii.h
#include dev/mii/miivar.h
@@ -237,7 +238,7 @@ miibus_linkchg(dev)
struct mii_data *mii;
struct ifnet *ifp;
device_t parent;
- int link;
+ int link, link_state;
parent = device_get_parent(dev);
MIIBUS_LINKCHG(parent);
@@ -249,15 +250,25 @@ miibus_linkchg(dev)
ifp = device_get_softc(parent);
if (mii-mii_media_status IFM_AVALID) {
- if (mii-mii_media_status IFM_ACTIVE)
+ if (mii-mii_media_status IFM_ACTIVE) {
link = NOTE_LINKUP;
- else
+ link_state = LINK_STATE_UP;
+ } else {
link = NOTE_LINKDOWN;
+ link_state = LINK_STATE_DOWN;
+ }
} else {
link = NOTE_LINKINV;
+ link_state = LINK_STATE_UNKNOWN;
}
KNOTE(ifp-if_klist, link);
+
+ /* Notify protocols that the link state has changed */
+ if (link_state != ifp-if_link_state) {
+ ifp-if_link_state = link_state;
+ rt_ifmsg(ifp);
+ }
}
static void
Index: net/if.h
===
RCS file: /home/ncvs/src/sys/net/if.h,v
retrieving revision 1.85
diff -u -p -r1.85 if.h
--- net/if.h11 Apr 2004 13:36:52 - 1.85
+++ net/if.h23 Apr 2004 01:16:06 -
@@ -104,6 +104,7 @@ struct if_data {
u_char ifi_physical; /* e.g., AUI, Thinnet, 10base-T, etc */
u_char ifi_addrlen;/* media address length */
u_char ifi_hdrlen; /* media header length */
+ u_char ifi_link_state; /* current link state */
u_char ifi_recvquota; /* polling quota for receive intrs */
u_char ifi_xmitquota; /* polling quota for xmit intrs */
u_long ifi_mtu;/* maximum transmission unit */
@@ -153,6 +154,13 @@ struct if_data {
(IFF_BROADCAST|IFF_POINTOPOINT|IFF_RUNNING|IFF_OACTIVE|\
IFF_SIMPLEX|IFF_MULTICAST|IFF_ALLMULTI|IFF_SMART|IFF_PROMISC|\
IFF_POLLING)
+
+/*
+ * Values for if_link_state.
+ */
+#define LINK_STATE_UNKNOWN 0 /* link invalid/unknown */
+#define LINK_STATE_DOWN1 /* link is down */
+#define LINK_STATE_UP 2 /* link is up */
/*
* Some convenience macros used for setting ifi_baudrate.
Index: net/if_var.h
===
RCS file: /home/ncvs/src/sys/net/if_var.h,v
retrieving revision 1.73
diff -u -p -r1.73 if_var.h
--- net/if_var.h18 Apr 2004 18:59:44 - 1.73
+++ net/if_var.h23 Apr 2004 01:16:06 -
@@ -197,6 +197,7 @@ typedef void if_init_f_t(void *);
#defineif_addrlen if_data.ifi_addrlen
#defineif_hdrlen if_data.ifi_hdrlen
#defineif_metric if_data.ifi_metric
+#defineif_link_state if_data.ifi_link_state
#defineif_baudrate if_data.ifi_baudrate
#defineif_hwassist if_data.ifi_hwassist
#defineif_ipackets if_data.ifi_ipackets
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing ttl of incoming packets
start with natd and chop it until you have what you want.. On Fri, 23 Apr 2004, GiZmen wrote: On Thu, Apr 22, 2004 at 11:54:15AM +0200, GiZmen wrote: Hello, Is there any way to change ttl of incoming packet to a lower value ? I had tried min-ttl option in pf packet filter but this option only increase ttl to a given value when ttl is lower than this value. I have searched on google and mailing lists but i do not find any answer. I am running Freebsd 5.2.1 and i am using pf as my packet filter. You mean, make the IP forwarding decrement the IP TTL more than by one? ---end quoted text--- No, i want to change ttl to whatever value i want. For example i want to changle ttl value for any packet incoming to my iface to 10 value. I only want to know that is there some tool or option or anything else to set this. -- Best Regards: GiZmen UNIX is user-friendly; it's just picky about its friends UNIX is simple; it just takes a genius to understand its simplicity ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to flush out cache.?
Sigh. Run this program. Note that the file contains an 'A' in the
first byte after you run it (hexdump -C test.dat). Thus, msync()
is not destroying the page until AFTER it finishes flushing it to
disk.
/*
* x.c
*/
#include sys/types.h
#include sys/mman.h
#include stdio.h
#include unistd.h
#include fcntl.h
int
main(int ac, char **av)
{
int fd;
char *ptr;
fd = open(test.dat, O_RDWR|O_CREAT|O_TRUNC, 0666);
ftruncate(fd, 4096);
ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
*ptr = 'A';
msync(ptr, 4096, MS_INVALIDATE);
return(0);
}
Now run this program. Note that the file still contains an 'A'
after you run it. Thus, again, msync() is not destroying the page
until after it has been synchronized with the file.
I also added some additional code to re-read *ptr after the msync
and observed the I/O go through to the disk, so it does appear to
be destroying the page. But it is definitely flushing it to disk
first.
If you can demonstrate a case where the page is being destroying
when it shouldn't be, then there's a bug that needs fixing. Right
now though it seems to operate as expected.
-Matt
/*
* y.c
*/
#include sys/types.h
#include sys/mman.h
#include stdio.h
#include unistd.h
#include fcntl.h
int
main(int ac, char **av)
{
int fd;
char *ptr;
fd = open(test.dat, O_RDWR|O_CREAT|O_TRUNC, 0666);
ftruncate(fd, 4096);
ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
*ptr = 'A';
munmap(ptr, 4096);
ptr = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, 0);
msync(ptr, 4096, MS_INVALIDATE);
return(0);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to flush out cache.?
Ok... I've done some more testing.
Ahh! I finally was able to reproduce the problem with PROT_READ, and
I now see the code bit you were talking about. That's definitely a bug.
Here's the test program that reproduces the problem. This is definitely
a serious bug.
-Matt
/*
* y.c
*/
#include sys/types.h
#include sys/mman.h
#include stdio.h
#include unistd.h
#include fcntl.h
int
main(int ac, char **av)
{
int fd;
char *ptr1;
char *ptr2;
fd = open(test.dat, O_RDWR|O_CREAT|O_TRUNC, 0666);
ftruncate(fd, 4096);
ptr1 = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
*ptr1 = 'A';
ptr2 = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, 0);
if (msync(ptr2, 4096, MS_INVALIDATE | MS_SYNC) 0)
perror(msync);
printf(contents of *ptr1 is %d\n, *ptr1);
printf(contents of *ptr2 is %d\n, *ptr2);
return(0);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to flush out cache.?
(taking hackers off to reduce noise) I think all that needs to happen to fix this problem is to call vm_object_page_remove() with the clean_only flag set to TRUE instead of FALSE. Wired pages, e.g. pages in the buffer cache, will not be removed, but that's ok because memory-mapped pages tend to not get buffer cache associations until the system decides to flush the pages. Fixing the buffer cache issue would have to occur in the actual VNODE I/O operation, which would only occur for VM_PROT_WRITE operations, which I think is just fine. The I/O op will have access to the invalidation request as a flag and it can simply do what NFS does which is flag the buffer to be destroyed on I/O completion. If that is done, then by the time we get to the second pass the buffer should be gone and the vm_object_page_remove() function will find a normal, unwired page and properly remove it. I'll test this out in DragonFly and email Stephan and Julian a followup. -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re99: how to flush out cache.?
:(taking hackers off to reduce noise)
oops. I guess I didn't take it off hackers. Sorry about that.
Yah yah, I know, 'Matt's making a billion postings again'.
In anycase, I sent a patch set to Stephan and julian, and since I didn't
take it off the list like I said I would I guess I might as well post the
patch set and the revised test program too for anyone following along.
Note that the patch set is against DragonFly, but should easily patch into
4.x. Stephan and Julian will deal with 4.xisms and 5.xisms.
The idea with the fix is as follows:
* It's hard to make the VM system invalidate buffers, so don't try.
Instead, make UFS recognize the IO_INVAL ioflag and mark the buffer
appropriately in the putpages - generic put pages - VOP_WRITE() path.
This only occurs if the msync'd map was writable. If the msync'd map was
only readable, then the data is not flushed through the vnode system and
the pages will not be removed if there happens to be a buffer associated
with them, even if the buffer is clean.
I think this is reasonable. Not perfect, but reasonable.
* Set clean_only to TRUE when calling vm_object_page_remove(), which
causes vm_object_page_remove() to ignore wired or dirty pages. This
code is called for both readable and writable maps so we can't just
remove the page unconditionallty, hence clean_only should be
set to TRUE.
This means that any pages associated with the buffer cache will NOT
be removed if the map was read-only. If the map was writable, then
the IO_INVAL fix above will destroy the buffer and the page should
wind up not being wired any more, and thus will be properly removed.
That's it!
-Matt
/*
* y.c
*/
#include sys/types.h
#include sys/mman.h
#include stdio.h
#include unistd.h
#include fcntl.h
int
main(int ac, char **av)
{
int fd;
char *ptr1;
char *ptr2;
char buf[4096];
fd = open(test.dat, O_RDWR|O_CREAT|O_TRUNC, 0666);
ftruncate(fd, 4096);
ptr1 = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
*ptr1 = 'A';
read(fd, buf, 4096);
ptr2 = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, 0);
if (msync(ptr1, 4096, MS_INVALIDATE | MS_SYNC) 0)
perror(msync);
sleep(4);
printf(contents of *ptr1 is %d\n, *ptr1);
printf(contents of *ptr2 is %d\n, *ptr2);
return(0);
}
Index: vm/vm_map.c
===
RCS file: /cvs/src/sys/vm/vm_map.c,v
retrieving revision 1.24
diff -u -r1.24 vm_map.c
--- vm/vm_map.c 23 Mar 2004 22:54:32 - 1.24
+++ vm/vm_map.c 23 Apr 2004 02:56:17 -
@@ -2212,7 +2212,7 @@
vm_object_page_remove(object,
OFF_TO_IDX(offset),
OFF_TO_IDX(offset + size + PAGE_MASK),
- FALSE);
+ TRUE);
vm_object_deallocate(object);
}
start += size;
Index: vfs/ufs/ufs_readwrite.c
===
RCS file: /cvs/src/sys/vfs/ufs/ufs_readwrite.c,v
retrieving revision 1.9
diff -u -r1.9 ufs_readwrite.c
--- vfs/ufs/ufs_readwrite.c 26 Jul 2003 22:04:27 - 1.9
+++ vfs/ufs/ufs_readwrite.c 23 Apr 2004 03:05:50 -
@@ -531,6 +531,8 @@
bp-b_flags |= B_DIRECT;
if (ioflag IO_NOWDRAIN)
bp-b_flags |= B_NOWDRAIN;
+ if ((ioflag (IO_SYNC|IO_INVAL)) == (IO_SYNC|IO_INVAL))
+ bp-b_flags |= B_NOCACHE;
if (uio-uio_offset + xfersize ip-i_size) {
ip-i_size = uio-uio_offset + xfersize;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing ttl of incoming packets
On Thu, Apr 22, 2004 at 07:02:45PM -0700, Julian Elischer wrote: start with natd and chop it until you have what you want.. ports/net/tcpmssd might be easier to adopt. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
