removal of NGROUPS_MAX dependancy from base
attached is the first in a series of patches that is intended to
remove the current limitation on group membership.
this patch should remove the dependancy on the definition of
NGROUPS_MAX as a static constant and implement it as a writable
sysconf variable of the same. it should also make the necessary
changes to the codebase to support those.
i need some guidance as to what i should re-define NGROUPS_MAX to be
(so that code that depends on it can continue to operate, i'm thinking
just make it 16 but perhaps it would be worth extending the default
while we're at it to something like 64??). i also need feedback on
any braindamage in the current changes.
the next step will be to extend the kernel groups and map them back
to the user structs / calls. finally i'll extend the user groups
and implement those calls.
nb: not tested the code (it builds) ... was intending to test it on
my XEN box but only just realised that Xen on amd64 isn't working.
:-(
happy for any questions that may help guide the process.
Index: contrib/openpam/lib/openpam_borrow_cred.c
===
RCS file:
/home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/contrib/openpam/lib/openpam_borrow_cred.c,v
retrieving revision 1.1.1.9
diff -b -u -r1.1.1.9 openpam_borrow_cred.c
--- contrib/openpam/lib/openpam_borrow_cred.c 21 Dec 2007 11:49:29 -
1.1.1.9
+++ contrib/openpam/lib/openpam_borrow_cred.c 4 Feb 2009 16:38:46 -
@@ -60,6 +60,7 @@
struct pam_saved_cred *scred;
const void *scredp;
int r;
+ int ngroups ;
ENTERI(pwd->pw_uid);
r = pam_get_data(pamh, PAM_SAVED_CRED, &scredp);
@@ -73,26 +74,55 @@
(int)geteuid());
RETURNC(PAM_PERM_DENIED);
}
- scred = calloc(1, sizeof *scred);
- if (scred == NULL)
- RETURNC(PAM_BUF_ERR);
- scred->euid = geteuid();
- scred->egid = getegid();
- r = getgroups(NGROUPS_MAX, scred->groups);
- if (r < 0) {
- FREE(scred);
- RETURNC(PAM_SYSTEM_ERR);
- }
- scred->ngroups = r;
+/* get the maximum number of system groups */
+#if _POSIX_VERSION > 199212
+ ngroups = sysconf( _SC_NGROUPS_MAX ) ;
+#elif defined(NGROUPS_MAX)
+ ngroups = NGROUPS_MAX ;
+#else
+ ngroups = _NGROUPS_COMPAT ;
+#endif
+/* initally allocate enough memory for max_groups */
+ scred = malloc( sizeof(struct pam_saved_cred) +
+ ngroups*sizeof(gid_t) ) ;
+ if( scred == NULL )
+ RETURNC( PAM_BUF_ERR ) ;
+/* set the save values */
+ scred->euid = geteuid() ;
+ scred->egid = getegid() ;
+/* save groups into our (probably) oversized memory allocation */
+ r = getgroups( ngroups, scred->groups ) ;
+ if( r < 0 ) {
+ FREE( scred ) ; /* call PAM's free macro */
+ RETURNC( PAM_SYSTEM_ERR ) ;
+ } ;
+ scred->ngroups = r ;
+ ngroups = r < ngroups ? r : ngroups ; /* choose the smallest */
+ /* ... number of groups to allocate */
+ ngroups = ngroups < _NGROUPS_COMPAT ? ngroups : _NGROUPS_COMPAT ;
+ /* but keep it within expected minimum value */
+ /* XXX: we don't really want this but
until we get
+* educated on the implications this is
probably safe
+* and certainaly compatible */
+/* realloc, releasing unneeded memory */
+ scred = realloc( (void*)scred,
+ sizeof(struct pam_saved_cred)+ngroups*sizeof(gid_t) ) ;
+ /* nb: we ignore failure and try to store the
larger
+* ... structure as initially requested.
catching the
+* ... error in 'pam_set_data' if neccessary. */
+/* save the credentials to PAM user data area */
r = pam_set_data(pamh, PAM_SAVED_CRED, scred, &openpam_free_data);
if (r != PAM_SUCCESS) {
FREE(scred);
RETURNC(r);
}
+/* set the new credentials */
if (geteuid() == pwd->pw_uid)
RETURNC(PAM_SUCCESS);
if (initgroups(pwd->pw_name, pwd->pw_gid) < 0 ||
- setegid(pwd->pw_gid) < 0 || seteuid(pwd->pw_uid) < 0) {
+ setegid(pwd->pw_gid) < 0 || seteuid(pwd->pw_uid) < 0)
+ {
+ /* if any of the set calls failed, then restore and fail */
openpam_restore_cred(pamh);
RETURNC(PAM_SYSTEM_ERR);
}
Index: contrib/openpam/lib/openpam_impl.h
===
RCS file:
/home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/contrib/openpam/lib/openpam_impl.h,v
retrieving revision 1.1.1.17
diff -b -u -r1.1.1.17 openpam_impl.h
--- contrib/openpam/lib/openpam_impl.h 21 Dec 2007 11:49:29 -00
bus_dmamem_alloc() and BUS_DMA_WAITOK
Hello, I would like to know if it is safe to use the BUS_DMA_WAITOK flag with bus_dmamem_alloc(), in the context of the device_attach routine? Many drivers use BUS_DMA_NOWAIT. I need a 32Ko buffer and on low memory my driver cannot attach (bus_dmamem_alloc returns ENOMEM). Will BUS_DMA_WAITOK help in this case? Thanks in advance, regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bus_dmamem_alloc() and BUS_DMA_WAITOK
On Friday 13 February 2009 9:22:05 am Patrick Lamaizière wrote: > Hello, > > I would like to know if it is safe to use the BUS_DMA_WAITOK flag with > bus_dmamem_alloc(), in the context of the device_attach routine? Many > drivers use BUS_DMA_NOWAIT. Yes, it is ok to use in an attach routine. > I need a 32Ko buffer and on low memory my driver cannot attach > (bus_dmamem_alloc returns ENOMEM). Will BUS_DMA_WAITOK help in this > case? I'm not sure if it will really help, though. You might end up blocking forever (or a long time) until a 32k region is freed. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Tyan S2895 7.1 amd64 >4Gb RAM support?
Hi, I've a Tyan S2895 (bios 1.04), w/10Gb of ECC RAM onboard using 2 * Opteron 285's. The machine used to run WinXP x64, and Vista x64 (mostly doing video production, ray tracing etc.) I recently switched this machine to FreeBSD 7.1 amd64 - to run ZFS on it, but I've been having horrific problems with it. Basically, with more than ~3Gb of RAM usable in the system - it shows signs of chronic RAM problems (everything from sig11's through to failing to compile the kernel with 'weird' errors - as well as kernel panics, and spontaneous reboots). I've tested all the RAM (ECC is enabled on the BIOS) - it all tests fine (even if I jumble it up between different simms in different sockets etc.) By setting: hw.physmem="3G" In loader.conf - I get a stable system. I've not setup any ZFS pools or anything yet, until I get the system stable. I've also tried changing the BIOS settings for the Memory Hole, IOMMU, MTRR etc. - all to no avail (nor does a BIOS 'use safe defaults' make any difference). It boots off the onboard nVidia RAID controller (a pair of 36Gb drives configured as RAID1), this shows up as: " atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x1440-0x1447,0x1434-0x1437,0x1438-0x143f,0x1430-0x1433,0x1410-0x141f mem 0xc0002000-0xc0002fff irq 22 at device 7.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x1458-0x145f,0x144c-0x144f,0x1450-0x1457,0x1448-0x144b,0x1420-0x142f mem 0xc0003000-0xc0003fff irq 23 at device 8.0 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ... ad8: 35304MB at ata4-master SATA150 ad10: 35304MB at ata5-master SATA150 ... ar0: 35304MB status: READY ar0: disk0 READY (master) using ad10 at ata5-master ar0: disk1 READY (mirror) using ad8 at ata4-master Trying to mount root from ufs:/dev/ar0s1a " Anyone got any ideas? - At this time, I can't prove 100% whether it's the disk controller messing up and corrupting data as it's loaded into RAM, or data getting corrupt once in RAM that's causing the crashes - all I know is with ~3Gb RAM - either by physically pulling SIMMs or using the hw.physmem option - it works fine. I tried booting 8.0-CURRENT-200812-amd64-disc1.iso - to see if anything was different with this hardware in 8.0 - but unfortunately that doesn't boot past the BTX loader on this machine, regardless of how much RAM is / isn't in it :( -Kp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
TUNABLE_INT question
hi
#define TUNABLE_INT(path, var) \
static struct tunable_int __CONCAT(__tunable_int_, __LINE__) = { \
(path), \
(var), \
}; \
SYSINIT(__CONCAT(__Tunable_init_, __LINE__),\
SI_SUB_TUNABLES, SI_ORDER_MIDDLE, tunable_int_init, \
&__CONCAT(__tunable_int_, __LINE__))
this is the code for TUNABLE_INT macro, the first param
to SYSINIT is an "uniquifier" which is "__Tunable_init_X"
where is is a number specifying line.
if I read it correctly there is no protection from collisions, am
I right? is it a proper fix to concat __FILE__ there too?
thnx
roman
pgpx7LGWF2Y4G.pgp
Description: PGP signature
Re: Tyan S2895 7.1 amd64 >4Gb RAM support?
On Friday 13 February 2009 19:00:31 Karl Pielorz wrote: > Hi, > > I've a Tyan S2895 (bios 1.04), w/10Gb of ECC RAM onboard using 2 * Opteron > 285's. The machine used to run WinXP x64, and Vista x64 (mostly doing video > production, ray tracing etc.) > > I recently switched this machine to FreeBSD 7.1 amd64 - to run ZFS on it, > but I've been having horrific problems with it. > > Basically, with more than ~3Gb of RAM usable in the system - it shows signs > of chronic RAM problems (everything from sig11's through to failing to > compile the kernel with 'weird' errors - as well as kernel panics, and > spontaneous reboots). > > I've tested all the RAM (ECC is enabled on the BIOS) - it all tests fine > (even if I jumble it up between different simms in different sockets etc.) > > By setting: > > hw.physmem="3G" > > In loader.conf - I get a stable system. > > I've not setup any ZFS pools or anything yet, until I get the system > stable. I've also tried changing the BIOS settings for the Memory Hole, > IOMMU, MTRR etc. - all to no avail (nor does a BIOS 'use safe defaults' > make any difference). I have a S2882-D populated with 6GB (6x1G) running FreeBSD since early 7. It took some tuning of the memory timing in the BIOS to get it to work, but ever since it works like a charm. > It boots off the onboard nVidia RAID controller (a pair of 36Gb drives > configured as RAID1), this shows up as: Can you maybe try to take the nVidia RAID out of the equation? I figure the "professional" version of the chip is not that common so maybe the corruption stems from the disk controller. > " > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x1440-0x1447,0x1434-0x1437,0x1438-0x143f,0x1430-0x1433,0x1410-0x141f mem > 0xc0002000-0xc0002fff irq 22 at device 7.0 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > atapci2: port > 0x1458-0x145f,0x144c-0x144f,0x1450-0x1457,0x1448-0x144b,0x1420-0x142f mem > 0xc0003000-0xc0003fff irq 23 at device 8.0 on pci0 > atapci2: [ITHREAD] > ata4: on atapci2 > ata4: [ITHREAD] > ata5: on atapci2 > ata5: [ITHREAD] > ... > ad8: 35304MB at ata4-master SATA150 > ad10: 35304MB at ata5-master SATA150 > ... > ar0: 35304MB status: READY > ar0: disk0 READY (master) using ad10 at ata5-master > ar0: disk1 READY (mirror) using ad8 at ata4-master > Trying to mount root from ufs:/dev/ar0s1a > " > > Anyone got any ideas? - At this time, I can't prove 100% whether it's the > disk controller messing up and corrupting data as it's loaded into RAM, or > data getting corrupt once in RAM that's causing the crashes - all I know is > with ~3Gb RAM - either by physically pulling SIMMs or using the hw.physmem > option - it works fine. > > I tried booting 8.0-CURRENT-200812-amd64-disc1.iso - to see if anything was > different with this hardware in 8.0 - but unfortunately that doesn't boot > past the BTX loader on this machine, regardless of how much RAM is / isn't > in it :( Any more details on how it fails would help. -- /"\ Best regards, | mla...@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mla...@efnet / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: TUNABLE_INT question
__FILE__ is a string so you can't concat that with anything to produce an identifier. In any case, the variable is static so there can't be any collision problems with other files. Ryan Stone ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: TUNABLE_INT question
On Fri, Feb 13, 2009 at 03:55:44PM -0500, Ryan Stone wrote: > __FILE__ is a string so you can't concat that with anything to produce an > identifier. In any case, the variable is static so there can't be any > collision problems with other files. I was talking about the SYSINIT parameter. thats a section in a .o file, and I am getting collisions there... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
