Re: SIOCGIFADDR broken on 9.0-RC1?
Am 15.11.2011 um 23:35 schrieb GR: > So, I switched to static assignement and it changes the behaviour (and > "fixes" the "bug"). > My guess is that during the time waiting for the DHCP offer, all aliases are > already configured on the network interface, and the IP address given by DHCP > is added at the end of the tail. > > Is that a wanted behaviour? I find it dangerous (i.e. not exactly what a user > is expecting). A bit of background, as best I understand it and remember from Stevens: Interfaces in BSD do not have a notion of "primary" and "additional" addresses; interfaces just have any number of addresses associated with them. There's no inherent ordering in this list (except for how the current implementation seems to keep them in the order they were configured). To be able to associate proper routes with interface addresses, the recommendation for multiple IPv4 addresses on an Ethernet interface is to have one of them have the proper netmask for the network, and configure the remainder with a netmask of 255.255.255.255. But that's solely for the benefit of the routing table; the interface itself doesn't really care. Reading the rc.conf man page could give you the impression that there are primary and alias addresses, but the networking code doesn't really work like that. The new ipv4_addrs_ syntax exposes the actual behavior in a more direct way. Jeremy gave you a hint on how to fix your immediate problem, but the real answer is that the program needs to be fixed that makes assumptions about meaning attached to the first configured IPv4 address. HTH, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Enable nxstack by default
On 11/15/11, Jeremie Le Hen wrote:
> Hi,
>
> On Wed, Oct 19, 2011 at 12:37:44AM +0200, Oliver Pinter wrote:
>> In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X
>> (~nxstack), mprotect restriction, veriexec, mmap randomization[2]...)
>>
>> [0] http://pax.grsecurity.net/docs/index.html
>> [1] http://www.netbsd.org/~elad/recent/man/security.8.html
>> [2] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff
>
> Suleiman actually wrought two patches, one randomizing the stack (the
> one you pointed out) and another one randomizing non-fixed mmap(2)
> calls:
>
> http://people.freebsd.org/~ssouhlal/testing/mmap_random-20050528.diff
>
>
> FYI, they do not apply cleanly on recent source trees (the patches were
> made in 2005), but they can be applied with little fiddling. I'm
> running multiple 8.x production machines with them without any problem.
Yeah, I use thins patch in 7-STABLE and 9-STABLE too.
Patch for 9-STABLE has attached.
>
> I've always wanted them to be committed as opt-in knobs, but I can't
> remember why they hadn't at the time.
>
> Cheers,
> --
> Jeremie Le Hen
>
> Men are born free and equal. Later on, they're on their own.
> Jean Yanne
>
commit 779a962519e7ead63dda24348b98f6cde8156752
Author: Oliver Pinter
Date: Tue Oct 4 00:24:01 2011 +0200
forwardport mmap-randomization patch from 7-STABLE-op
Signed-off-by: Oliver Pinter
diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c
index fe01142..dc66db6 100644
--- a/sys/kern/kern_exec.c
+++ b/sys/kern/kern_exec.c
@@ -106,6 +106,7 @@ MALLOC_DEFINE(M_PARGS, "proc-args", "Process arguments");
static int sysctl_kern_ps_strings(SYSCTL_HANDLER_ARGS);
static int sysctl_kern_usrstack(SYSCTL_HANDLER_ARGS);
static int sysctl_kern_stackprot(SYSCTL_HANDLER_ARGS);
+static int sysctl_kern_stackgap_random(SYSCTL_HANDLER_ARGS);
static int do_execve(struct thread *td, struct image_args *args,
struct mac *mac_p);
@@ -120,6 +121,9 @@ SYSCTL_PROC(_kern, KERN_USRSTACK, usrstack, CTLTYPE_ULONG|CTLFLAG_RD|
SYSCTL_PROC(_kern, OID_AUTO, stackprot, CTLTYPE_INT|CTLFLAG_RD,
NULL, 0, sysctl_kern_stackprot, "I", "");
+SYSCTL_PROC(_kern, OID_AUTO, stackgap_random, CTLTYPE_INT|CTLFLAG_RW,
+NULL, 0, sysctl_kern_stackgap_random, "I", "stackgap maximum offset");
+
u_long ps_arg_cache_limit = PAGE_SIZE / 16;
SYSCTL_ULONG(_kern, OID_AUTO, ps_arg_cache_limit, CTLFLAG_RW,
&ps_arg_cache_limit, 0, "");
@@ -177,6 +181,30 @@ sysctl_kern_stackprot(SYSCTL_HANDLER_ARGS)
sizeof(p->p_sysent->sv_stackprot)));
}
+static int stackgap_random = 64 * 1024;
+
+static int
+sysctl_kern_stackgap_random(SYSCTL_HANDLER_ARGS)
+{
+ int err;
+ int val;
+
+ val=stackgap_random;
+ err=sysctl_handle_int(oidp, &val, sizeof(int), req);
+ if (err || !req->newptr) {
+ return (err);
+ }
+
+ if ((val64*1024*1024) {
+ return (EINVAL);
+ }
+
+ stackgap_random=val;
+
+ return (0);
+}
+
/*
* Each of the items is a pointer to a `const struct execsw', hence the
* double pointer here.
@@ -1248,6 +1276,7 @@ exec_copyout_strings(imgp)
size_t execpath_len;
int szsigcode, szps;
char canary[sizeof(long) * 8];
+ int sgap;
szps = sizeof(pagesizes[0]) * MAXPAGESIZES;
/*
@@ -1265,7 +1294,11 @@ exec_copyout_strings(imgp)
if (p->p_sysent->sv_szsigcode != NULL)
szsigcode = *(p->p_sysent->sv_szsigcode);
}
- destp = (caddr_t)arginfo - szsigcode - SPARE_USRSPACE -
+ sgap=0;
+ if (stackgap_random!=0) {
+ sgap=ALIGN(arc4random()&(stackgap_random-1));
+ }
+ destp = (caddr_t)arginfo - szsigcode - SPARE_USRSPACE - sgap -
roundup(execpath_len, sizeof(char *)) -
roundup(sizeof(canary), sizeof(char *)) -
roundup(szps, sizeof(char *)) -
diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c
index e85b681..991a37d 100644
--- a/sys/vm/vm_mmap.c
+++ b/sys/vm/vm_mmap.c
@@ -68,6 +68,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
@@ -99,6 +100,10 @@ static int vm_mmap_cdev(struct thread *, vm_size_t, vm_prot_t, vm_prot_t *,
static int vm_mmap_shm(struct thread *, vm_size_t, vm_prot_t, vm_prot_t *,
int *, struct shmfd *, vm_ooffset_t, vm_object_t *);
+static int mmap_random=1;
+SYSCTL_INT(_vm, OID_AUTO, mmap_random, CTLFLAG_RW, &mmap_random, 0,
+ "random mmap offset");
+
/*
* MPSAFE
*/
@@ -256,7 +261,8 @@ sys_mmap(td, uap)
/*
* XXX for non-fixed mappings where no hint is provided or
* the hint would fall in the potential heap space,
- * place it after the end of the largest possible heap.
+ * place it after the end of the largest possible heap,
+ * plus a random offset, if mmap_random is set.
*
* There should really be a pmap call to determine a reasonable
* location.
@@ -265,9 +271,13 @@ sys_mmap(td, uap)
if (addr == 0 ||
(addr >= round_page((vm_offset_t)vms->vm_taddr) &&
addr < round_page((vm_offset_t)vms->vm_daddr +
- lim_max(td->td_proc, RLIMIT_DATA
+ lim_max(td->td_proc, RLIMI
Re: SIOCGIFADDR broken on 9.0-RC1?
On Tue, Nov 15, 2011 at 11:35:37PM +0100, GR wrote: > >From "Kristof Provost" : > [..] > > The 'ia' pointer is later used to return the IP address. > > > > In other words: it returns the first address on the interface > > of type IF_INET (which isn't assigned to a jail). > > > > I think the order of the addresses is not fixed, or rather it depends > > on > > the order in which you assign addresses. In the handling of > > SIOCSIFADDR > > new addresses are just appended: > > > > TAILQ_INSERT_TAIL(&ifp->if_addrhead, ifa, ifa_link); > > > > I don't believe this has changed since 8.0. Is it possible something > > changed in the network initialisation, leading to the addresses being > > assigned in a different order? > > > > Eagerly awaiting to be told I'm wrong, > > Kristof > > Thanks Kristof. It appears you are right, the order of assignement is > important. > I configured my interface using DHCP, and added aliases (all in /etc/rc.conf). > But on the 8.2-RELEASE, I used static configuration. > > So, I switched to static assignement and it changes the behaviour (and > "fixes" the "bug"). > My guess is that during the time waiting for the DHCP offer, all aliases are > already configured on the network interface, and the IP address given by DHCP > is added at the end of the tail. > > Is that a wanted behaviour? I find it dangerous (i.e. not exactly what a user > is expecting). > > Note: my aliases are attributed to jails. I would recommend adding synchronous_dhclient="yes" to /etc/rc.conf. This will cause dhclient (the DHCP client) to wait until it gets an answer + IP back from the DHCP server before continuing with the rc.d scripts. The default is "no". -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: No disks usable on a P5NE MB (aka regession is r219737)
On Tue, Nov 15, 2011 at 12:46:41PM -0500, John Baldwin wrote: [...] > and > > 10 remove that block : > > http://people.freebsd.org/~bapt/workaround-to-boot-p5ne.diff > > Yeah, the problem is that NVIDIA chipsets seem to have really odd behavior in > that once you turn MSI mapping on for a given node in the HyperTransport tree > it expects all child devices to only use MSI and not INTx. Linux has a lot > of > quirk code to try to handle this by only turning on the mapping window when > MSI is enabled for a given device. However, it has lots of hacks to try to > find the right Host-PCI Bridge that a given device is a child of. I'm mostly > tempted to just disable MSI on NVIDIA chipsets that have these issues rather > than adding the same number of quirks. However I haven't really had time to > sit down and look at this. > Thanks for reply, if you can do some testing for you if you want. regards, Bapt pgpJ14LcnsP9S.pgp Description: PGP signature
Re: SIOCGIFADDR broken on 9.0-RC1?
>From "Kristof Provost" : [..] > The 'ia' pointer is later used to return the IP address. > > In other words: it returns the first address on the interface > of type IF_INET (which isn't assigned to a jail). > > I think the order of the addresses is not fixed, or rather it depends > on > the order in which you assign addresses. In the handling of > SIOCSIFADDR > new addresses are just appended: > > TAILQ_INSERT_TAIL(&ifp->if_addrhead, ifa, ifa_link); > > I don't believe this has changed since 8.0. Is it possible something > changed in the network initialisation, leading to the addresses being > assigned in a different order? > > Eagerly awaiting to be told I'm wrong, > Kristof Thanks Kristof. It appears you are right, the order of assignement is important. I configured my interface using DHCP, and added aliases (all in /etc/rc.conf). But on the 8.2-RELEASE, I used static configuration. So, I switched to static assignement and it changes the behaviour (and "fixes" the "bug"). My guess is that during the time waiting for the DHCP offer, all aliases are already configured on the network interface, and the IP address given by DHCP is added at the end of the tail. Is that a wanted behaviour? I find it dangerous (i.e. not exactly what a user is expecting). Note: my aliases are attributed to jails. Regards, -- ^ ___ ___ http://www.GomoR.org/ <-+ | / __ |__/Senior Security Engineer | | \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]---| +--> Net::Frame <=> http://search.cpan.org/~gomor/ <---+ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SIOCGIFADDR broken on 9.0-RC1?
On (15/11/2011 18:10), GR wrote:
> Hello list,
>
> more insights since my last post. Here is a small code to trigger the bug
> (end of email).
> When you run it on 9.0-RC1, it gets an alias address instead of the main inet
> address:
>
> % ./get-ip re0
> inet: 192.168.2.10
> # Main address being 192.168.1.148
>
> On 8.2-RELEASE, all goes well:
> % ./get-ip re0
> inet: PUBLIC_IP4
>
> Is something broken, or a behaviour has changed since 8.2-RELEASE?
Your test case looks ok and works as expexted for me on 10-CURRENT, both
without aliases and after adding alias to interface. Perhaps it's the way
you add aliases (libdnet ?).
I've used:
ifconfing em0 alias OTHERIP
Thanks,
Gleb.
>
> Best regards,
>
>
> --8<--
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int
> main(int argc, char *argv[])
> {
>int fd;
>struct ifreq ifr;
>const struct sockaddr_in *sa;
>
>fd = socket(AF_INET, SOCK_DGRAM, 0);
>if (fd < 0) {
> perror("socket");
> exit(-1);
>}
>
>memset(&ifr, 0, sizeof(struct ifreq));
>strlcpy(ifr.ifr_name, argv[1], sizeof(ifr.ifr_name));
>
>if (ioctl(fd, SIOCGIFADDR, &ifr) == 0) {
> sa = (const struct sockaddr_in *) &ifr.ifr_addr;
> printf("inet: %s\n", inet_ntoa(sa->sin_addr));
>}
>else {
> perror("ioctl");
> exit(-1);
>}
>
>exit(0);
> }
> --8<--
>
> --
> ^ ___ ___ http://www.GomoR.org/ <-+
> | / __ |__/Senior Security Engineer |
> | \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]---|
> +--> Net::Frame <=> http://search.cpan.org/~gomor/ <---+
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SIOCGIFADDR broken on 9.0-RC1?
On 2011-11-15 18:10:01 (+0100), GR wrote:
> more insights since my last post. Here is a small code to trigger the bug
> (end of email).
> When you run it on 9.0-RC1, it gets an alias address instead of the main inet
> address:
>
> % ./get-ip re0
> inet: 192.168.2.10
> # Main address being 192.168.1.148
>
> On 8.2-RELEASE, all goes well:
> % ./get-ip re0
> inet: PUBLIC_IP4
>
> Is something broken, or a behaviour has changed since 8.2-RELEASE?
>
I think the relevant bit of the code is found in sys/netinet/in.c.
If your ioctl doesn't specify an IP address we end up in this bit:
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
iap = ifatoia(ifa);
if (iap->ia_addr.sin_family == AF_INET) {
if (td != NULL &&
prison_check_ip4(td->td_ucred,
&iap->ia_addr.sin_addr) != 0)
continue;
ia = iap;
break;
}
}
The 'ia' pointer is later used to return the IP address.
In other words: it returns the first address on the interface
of type IF_INET (which isn't assigned to a jail).
I think the order of the addresses is not fixed, or rather it depends on
the order in which you assign addresses. In the handling of SIOCSIFADDR
new addresses are just appended:
TAILQ_INSERT_TAIL(&ifp->if_addrhead, ifa, ifa_link);
I don't believe this has changed since 8.0. Is it possible something
changed in the network initialisation, leading to the addresses being
assigned in a different order?
Eagerly awaiting to be told I'm wrong,
Kristof
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: uhid(4) and report structures
On 15.11.2011 22:54, Marcus von Appen wrote:
On, Tue Nov 15, 2011, Alexander Motin wrote:
On 15.11.2011 21:29, Marcus von Appen wrote:
I wonder, if I am correct with my assumption that the usb_ctl_report*
structures mentioned in uhid(4) have to be defined and created by the
code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(),
... calls.
In FreeBSD< 800063 we defined them in the header files of the USB
subsystem. After the rewrite those struct definitions vanished. Will
the USB_ macros mentioned in uhid(4) "just" return a byte sequence
(that's what I understand from the UHID specification) so that code,
which uses those calls, can implement its own struct container for the
information retrieved?
Thanks for shedding some light on this. In case i am correct with what I
wrote above, it might make sense to mention it in uhid(4).
In new USB stack these calls use struct usb_gen_descriptor argument.
Difficult to say why it was done, but it was. To hide that I've recently
added two wrapper functions to the libusbhid in HEAD: hid_get_report()
and hid_set_report().
So the man page is currently not up to date and can - at least for now -
be assumed to be wrong?
To get the mappings correct, which fields would I have to use from
usb_gen_descriptor? Earlier we had:
struct usb_ctl_report {
int ucr_report;
u_char ucr_data[1024];
};
The mapping might be:
usb_gen_descriptor.ugd_data == usb_ctl_report.ucr_data
usb_gen_descriptor.ugd_report_type == usb_ctl_report.ucr_report
Is that correct? Also, ugd_data is of variable size with ugd_actlen
indicating the size of the ugd_data buffer?
Here is usage example:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libusbhid/data.c.diff?r1=1.9;r2=1.10;f=h
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: uhid(4) and report structures
On Tuesday 15 November 2011 21:54:06 Marcus von Appen wrote:
> struct usb_ctl_report {
> int ucr_report;
> u_char ucr_data[1024];
> };
Hi,
Before the descriptor length was limited to 1024 bytes.
Now it is limited to 65535 bytes, which is the USB maximum for control
endpoints.
Having a buffer this large by default does not make sense, so a pointer and
length is the best solution.
The application also sometimes know about what descriptor size(s) it expects.
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: uhid(4) and report structures
On, Tue Nov 15, 2011, Alexander Motin wrote:
> On 15.11.2011 21:29, Marcus von Appen wrote:
> > I wonder, if I am correct with my assumption that the usb_ctl_report*
> > structures mentioned in uhid(4) have to be defined and created by the
> > code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(),
> > ... calls.
> >
> > In FreeBSD< 800063 we defined them in the header files of the USB
> > subsystem. After the rewrite those struct definitions vanished. Will
> > the USB_ macros mentioned in uhid(4) "just" return a byte sequence
> > (that's what I understand from the UHID specification) so that code,
> > which uses those calls, can implement its own struct container for the
> > information retrieved?
> >
> > Thanks for shedding some light on this. In case i am correct with what I
> > wrote above, it might make sense to mention it in uhid(4).
>
> In new USB stack these calls use struct usb_gen_descriptor argument.
> Difficult to say why it was done, but it was. To hide that I've recently
> added two wrapper functions to the libusbhid in HEAD: hid_get_report()
> and hid_set_report().
So the man page is currently not up to date and can - at least for now -
be assumed to be wrong?
To get the mappings correct, which fields would I have to use from
usb_gen_descriptor? Earlier we had:
struct usb_ctl_report {
int ucr_report;
u_char ucr_data[1024];
};
The mapping might be:
usb_gen_descriptor.ugd_data == usb_ctl_report.ucr_data
usb_gen_descriptor.ugd_report_type == usb_ctl_report.ucr_report
Is that correct? Also, ugd_data is of variable size with ugd_actlen
indicating the size of the ugd_data buffer?
Best regards
Marcus
pgpWVPJ1tOWqP.pgp
Description: PGP signature
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
On Sunday, November 06, 2011 11:42:04 am Kostik Belousov wrote: > On Sun, Nov 06, 2011 at 07:22:51AM -0800, m...@freebsd.org wrote: > > On Sun, Nov 6, 2011 at 4:43 AM, Kostik Belousov wrote: > > > Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has > > > a lot of violations in regard of the namespaces, IMO. The __* namespace > > > is reserved for the language implementation, so our freestanding program > > > (kernel) ignores the requirements of the C standard with the names like > > > __mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes > > > it not unreasonable for other developers to introduce reserved names. > > > So I decided to use the suffixes. vm_map.h locking is free of these > > > violations. > > > > I'm pretty sure that when the C standard says, "the implementation", > > they're referring to the compiler and OS it runs on. Which makes the > > FreeBSD kernel part of "the implementation", which is precisely why so > > many headers have defines that start with __ and then, if certain > > posix defines are set, also uses non-__ versions of the name. > > For libc providing parts, required by standard, you are right. > But our kernel is a freestanding program using a compiler, so in-kernel > uses of the reserved namespace is a violation. I don't buy that argument at all. We have a libc for the kernel, it's called libkern and we own that, too. We depend on using _ and __ prefixes all over the kernel and trying to change that now would be excessively gratuitous. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: uhid(4) and report structures
On 15.11.2011 21:29, Marcus von Appen wrote: I wonder, if I am correct with my assumption that the usb_ctl_report* structures mentioned in uhid(4) have to be defined and created by the code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(), ... calls. In FreeBSD< 800063 we defined them in the header files of the USB subsystem. After the rewrite those struct definitions vanished. Will the USB_ macros mentioned in uhid(4) "just" return a byte sequence (that's what I understand from the UHID specification) so that code, which uses those calls, can implement its own struct container for the information retrieved? Thanks for shedding some light on this. In case i am correct with what I wrote above, it might make sense to mention it in uhid(4). In new USB stack these calls use struct usb_gen_descriptor argument. Difficult to say why it was done, but it was. To hide that I've recently added two wrapper functions to the libusbhid in HEAD: hid_get_report() and hid_set_report(). -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
uhid(4) and report structures
Hi, I wonder, if I am correct with my assumption that the usb_ctl_report* structures mentioned in uhid(4) have to be defined and created by the code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(), ... calls. In FreeBSD < 800063 we defined them in the header files of the USB subsystem. After the rewrite those struct definitions vanished. Will the USB_ macros mentioned in uhid(4) "just" return a byte sequence (that's what I understand from the UHID specification) so that code, which uses those calls, can implement its own struct container for the information retrieved? Thanks for shedding some light on this. In case i am correct with what I wrote above, it might make sense to mention it in uhid(4). Best regards Marcus pgpJsCrM03DjF.pgp Description: PGP signature
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
2011/11/15 : > On Tue, Nov 15, 2011 at 10:15 AM, Attilio Rao wrote: >> 2011/11/7 Kostik Belousov : >>> On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: Ok. I'll offer one final suggestion. Please consider an alternative suffix to "func". Perhaps, "kbi" or "KBI". In other words, something that hints at the function's reason for existing. >>> >>> Sure. Below is the extraction of only vm_page_lock() bits, together >>> with the suggested rename. When Attilio provides the promised simplification >>> of the mutex KPI, this can be reduced. >> >> My tentative patch is here: >> http://www.freebsd.org/~attilio/mutexfileline.patch >> >> I need to make more compile testing later, but it already compiles >> GENERIC + modules fine on HEAD. >> >> The patch provides a common entrypoint, option independent, for both >> fast case and debug/compat case. >> Additively, it almost entirely fixes the standard violation of the >> reserved namespace, as you described (the notable exception being the >> macro used in the fast path, that I want to fix as well, but in a >> separate commit). >> >> Now the file/line couplet can be passed to the "_" suffix variant of >> the flag functions. >> >> eadler@ reviewed the mutex.h comment. >> >> Please let me know what you think about it, as long as we agree on the >> patch I'll commit it. > > Out of curiosity, why are function names explicitly spelled out in > panic and log messages, instead of using %s and __func__? I've seen > this all around FreeBSD, and if there's no reason otherwise, I'd just > as soon change to a version that doesn't need updating when the > function names change. I prefer the __func__ stuff as well but bde isn't in favor of it because it is more difficult to grep for the message in that case. I'm not sure I'd buy his point on this, honestly, but that is why. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
On Tue, Nov 15, 2011 at 10:15 AM, Attilio Rao wrote: > 2011/11/7 Kostik Belousov : >> On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >>> Ok. I'll offer one final suggestion. Please consider an alternative >>> suffix to "func". Perhaps, "kbi" or "KBI". In other words, something >>> that hints at the function's reason for existing. >> >> Sure. Below is the extraction of only vm_page_lock() bits, together >> with the suggested rename. When Attilio provides the promised simplification >> of the mutex KPI, this can be reduced. > > My tentative patch is here: > http://www.freebsd.org/~attilio/mutexfileline.patch > > I need to make more compile testing later, but it already compiles > GENERIC + modules fine on HEAD. > > The patch provides a common entrypoint, option independent, for both > fast case and debug/compat case. > Additively, it almost entirely fixes the standard violation of the > reserved namespace, as you described (the notable exception being the > macro used in the fast path, that I want to fix as well, but in a > separate commit). > > Now the file/line couplet can be passed to the "_" suffix variant of > the flag functions. > > eadler@ reviewed the mutex.h comment. > > Please let me know what you think about it, as long as we agree on the > patch I'll commit it. Out of curiosity, why are function names explicitly spelled out in panic and log messages, instead of using %s and __func__? I've seen this all around FreeBSD, and if there's no reason otherwise, I'd just as soon change to a version that doesn't need updating when the function names change. Thanks, matthew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
2011/11/7 Kostik Belousov : > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >> Ok. I'll offer one final suggestion. Please consider an alternative >> suffix to "func". Perhaps, "kbi" or "KBI". In other words, something >> that hints at the function's reason for existing. > > Sure. Below is the extraction of only vm_page_lock() bits, together > with the suggested rename. When Attilio provides the promised simplification > of the mutex KPI, this can be reduced. My tentative patch is here: http://www.freebsd.org/~attilio/mutexfileline.patch I need to make more compile testing later, but it already compiles GENERIC + modules fine on HEAD. The patch provides a common entrypoint, option independent, for both fast case and debug/compat case. Additively, it almost entirely fixes the standard violation of the reserved namespace, as you described (the notable exception being the macro used in the fast path, that I want to fix as well, but in a separate commit). Now the file/line couplet can be passed to the "_" suffix variant of the flag functions. eadler@ reviewed the mutex.h comment. Please let me know what you think about it, as long as we agree on the patch I'll commit it. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: No disks usable on a P5NE MB (aka regession is r219737)
On Friday, November 11, 2011 5:59:07 pm Baptiste Daroussin wrote: > On Fri, Nov 11, 2011 at 11:10:58PM +0100, Baptiste Daroussin wrote: > > On Thu, Sep 29, 2011 at 12:22:54AM +0200, Baptiste Daroussin wrote: > > > On Sun, Sep 11, 2011 at 10:39:38PM +0200, Baptiste Daroussin wrote: > > > > > > the result is: > > > > > > db> show intrcnt > > > > > > cpu0: timer4510 > > > > > > irq256: hdac0 1 > > > > > > cpu3: timer 29 > > > > > > cpu1: timer 3036 > > > > > > cpu2: timer 31 > > > > > > db> > > > > > > > > > > > > I did break at the mountfrom> prompt > > > > > > If I break before I only have the cpu0 and irq256 entries. > > > > > > > > > > Hmmm, is there any way you can build a 9 kernel without sound support (since > > > > > that clutters up bootverbose) and capture a verbose dmesg, using a serial > > > > > console or PXE booting to an NFS root of some sort? > > > > > > > > > I can't pxe boot, but I can record the build on my camera: > > > > http://people.freebsd.org/~bapt/9-fail.avi (18MB) > > > > > > > > (this is 9.0-BETA2 memstick) > > > > > > > > Hope that could help > > > > > > > > > > Apparently this doesn't help, given that I have no way to netboot this box, may > > > that be from pxe and that there is no serial console, what can I do more to help > > > fixing this? > > > > > > I would love to be able to run 9 on my box > > > > > > regards, > > > Bapt > > > > After trying lots of different kernel it appears that the regression was > > introduce in r219737. I'm trying to figure out to solve this. > > > > If you have any clue tell me. > > > > regards, > > Bapt > > > > With the help of cognet, I workaround this and have been able to boot both 9 and > 10 remove that block : > http://people.freebsd.org/~bapt/workaround-to-boot-p5ne.diff Yeah, the problem is that NVIDIA chipsets seem to have really odd behavior in that once you turn MSI mapping on for a given node in the HyperTransport tree it expects all child devices to only use MSI and not INTx. Linux has a lot of quirk code to try to handle this by only turning on the mapping window when MSI is enabled for a given device. However, it has lots of hacks to try to find the right Host-PCI Bridge that a given device is a child of. I'm mostly tempted to just disable MSI on NVIDIA chipsets that have these issues rather than adding the same number of quirks. However I haven't really had time to sit down and look at this. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Enable nxstack by default
Hi, On Wed, Oct 19, 2011 at 12:37:44AM +0200, Oliver Pinter wrote: > In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X > (~nxstack), mprotect restriction, veriexec, mmap randomization[2]...) > > [0] http://pax.grsecurity.net/docs/index.html > [1] http://www.netbsd.org/~elad/recent/man/security.8.html > [2] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff Suleiman actually wrought two patches, one randomizing the stack (the one you pointed out) and another one randomizing non-fixed mmap(2) calls: http://people.freebsd.org/~ssouhlal/testing/mmap_random-20050528.diff FYI, they do not apply cleanly on recent source trees (the patches were made in 2005), but they can be applied with little fiddling. I'm running multiple 8.x production machines with them without any problem. I've always wanted them to be committed as opt-in knobs, but I can't remember why they hadn't at the time. Cheers, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SIOCGIFADDR broken on 9.0-RC1?
Hello list,
more insights since my last post. Here is a small code to trigger the bug (end
of email).
When you run it on 9.0-RC1, it gets an alias address instead of the main inet
address:
% ./get-ip re0
inet: 192.168.2.10
# Main address being 192.168.1.148
On 8.2-RELEASE, all goes well:
% ./get-ip re0
inet: PUBLIC_IP4
Is something broken, or a behaviour has changed since 8.2-RELEASE?
Best regards,
--8<--
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
int fd;
struct ifreq ifr;
const struct sockaddr_in *sa;
fd = socket(AF_INET, SOCK_DGRAM, 0);
if (fd < 0) {
perror("socket");
exit(-1);
}
memset(&ifr, 0, sizeof(struct ifreq));
strlcpy(ifr.ifr_name, argv[1], sizeof(ifr.ifr_name));
if (ioctl(fd, SIOCGIFADDR, &ifr) == 0) {
sa = (const struct sockaddr_in *) &ifr.ifr_addr;
printf("inet: %s\n", inet_ntoa(sa->sin_addr));
}
else {
perror("ioctl");
exit(-1);
}
exit(0);
}
--8<--
--
^ ___ ___ http://www.GomoR.org/ <-+
| / __ |__/Senior Security Engineer |
| \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]---|
+--> Net::Frame <=> http://search.cpan.org/~gomor/ <---+
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
