Re: [CFR] ucred.cr_gid
On Tue, Jun 26, 2001 at 11:18:56AM -0400, Robert Watson wrote: > > On Tue, 26 Jun 2001, Ruslan Ermilov wrote: > > > Could someone please take a look at it before I commit this? > > I won't get a chance to properly review this until I'm at USENIX tomorrow. > If you're willing to hold off for about a week, I'd be happy to give it a > fairly detailed review: I had some thoughts of doing this when I > originally merged ucred and pcred a few weeks ago, but decided to hold > off. I'm generally fairly positive about this change, but would be > interested in hearing Bruce's thoughts on any compatibility issues, in > particular, with respects to the behavior of userland processes with > expectations about the old behavior. Obviously, this is a change that is > very sensitive to subtle semantic changes on calls--on the other hand, I > think moving towards making the supplementary groups being independent > from the effect gid is a good goal, as it simplifies our credential code, > and improves compatibility. > At least one compatibility issue here is that it's no longer possible to use initgroups(3) to set the effective group ID. > > Date: Fri, 22 Jun 2001 18:05:09 +0300 > > From: Ruslan Ermilov <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > > Subject: ucred.cr_gid > > Message-ID: <[EMAIL PROTECTED]> > > Mail-Followup-To: [EMAIL PROTECTED], [EMAIL PROTECTED] > > > > Hi! > > > > The attached patch replaces ucred.cr_groups[0] with ucred.cr_gid. This > > is mostly needed for POSIX alignment. setegid(2) etc. should not change > > supplementary groups set. > > > > Also, type of 's group.gr_gid changed to a more natural gid_t > > (also as in POSIX). > > Sounds good, I think this change was bandied about once before and perhaps > simply didn't get committed. > Some of the assorted changes were committed as part of Hesiod import from NetBSD. > > getgrouplist(3)'s and initgroups(3)'s prototypes fixed. getgrouplist(3) > > has been also fixed to not duplicate the primary group, and always > > return number of suplementary groups, even if ngroups is zero (similar > > to sysctl(3)). > > Having not looked at the patch yet, just need to make sure I point out the > following areas that are sensitive to this type of change: linux and other > ABI emulation, where semantic mapping of this sort is already performed, > as well as userland applications managing groups. > I think my patch handles these. > > Assorted changes: > > > > cmsgcred.cmcred_egidNew > > This is an ABI change that will break applications compiled for older > versions of FreeBSD. Is this a change that applications can detect via > some sort of sizeof/sanity check on cmsg results? > I can't see how this would break old applications. > > kproc_info.ki_gid New > > portal_cred.pcr_gid New > > xucred.cr_gid New > > > > I'm not sure what to do with xucred. > > Probably reflect changes made in ucred fairly closely. > I mean, I'm not sure if we should preserve the 4.2's size of this structure or no, and if so, how to actually do it. Theoretically, this could be done by placing cr_gid in a union with _cr_unused1 and #define that untangles the fact that cr_gid is in a union, but that define would have to be ``#define cr_gid ...'' which is too bad. > I'll try to give you a detailed code review in a couple of days. > Thanks! Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal
On 27-Jun-01 Makoto MATSUSHITA wrote:
>
> matusita> lock order reversal
> matusita> 1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487
> matusita> 2nd 0xc05a9ec0 lockmgr interlock @ ../../kern/kern_lock.c:239
>
> I've caught tracelog of this reversal, with debug.witness_ddb=1.
> Here's console log:
>
> lock order reversal
> 1st 0xc5e3cfdc process lock @ ../../vm/vm_glue.c:487
> 2nd 0xc05a9f80 lockmgr interlock @ ../../kern/kern_lock.c:239
> Debugger("witness_lock")
> Stopped at Debugger+0x44: pushl %ebx
> db> trace
> Debugger(c02bd5ae) at Debugger+0x44
> witness_lock(c05a9f80,8,c02b8d54,ef) at witness_lock+0x90d
> lockmgr(c5dbe7d0,12,0,c5420640) at lockmgr+0x97
> swapout_procs(1,c02686e0,c5420640,0,c582df94) at swapout_procs+0xc46
> vm_daemon(0,c582dfa8) at vm_daemon+0x128
> fork_exit(c02686e0,0,c582dfa8) at fork_exit+0xb4
> fork_trampoline() at fork_trampoline+0x8
> db>
>
> I don't know whether it is reproducible, but it's early morning (6 AM),
> mkisofs(1) is just running to make an ISO image for me (for backup).
Ok, this one is due to braindeadedness in lockmgr(), and will just have to stay
the way it is until vm map locks switch to being sx locks instead of lockmgr
locks.
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal
matusita> lock order reversal
matusita> 1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487
matusita> 2nd 0xc05a9ec0 lockmgr interlock @ ../../kern/kern_lock.c:239
I've caught tracelog of this reversal, with debug.witness_ddb=1.
Here's console log:
lock order reversal
1st 0xc5e3cfdc process lock @ ../../vm/vm_glue.c:487
2nd 0xc05a9f80 lockmgr interlock @ ../../kern/kern_lock.c:239
Debugger("witness_lock")
Stopped at Debugger+0x44: pushl %ebx
db> trace
Debugger(c02bd5ae) at Debugger+0x44
witness_lock(c05a9f80,8,c02b8d54,ef) at witness_lock+0x90d
lockmgr(c5dbe7d0,12,0,c5420640) at lockmgr+0x97
swapout_procs(1,c02686e0,c5420640,0,c582df94) at swapout_procs+0xc46
vm_daemon(0,c582dfa8) at vm_daemon+0x128
fork_exit(c02686e0,0,c582dfa8) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
db>
I don't know whether it is reproducible, but it's early morning (6 AM),
mkisofs(1) is just running to make an ISO image for me (for backup).
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: GNU ld(1) dumps core
On Wed, Jun 27, 2001 at 02:16:48AM +0900, NAKAMURA Kazushi wrote: > Not only nasm, but also gas has same problem. In case of > ports/audio/gogo and ports/audio/lame, nasm outputs object which > make ld dumps core. While gcc+gas outputs object which can't link > by ld. I think the problem occures when "SSE instructions" and > "align" are used. (Unfortunatry, most SSE instructions need > 16Byte(=128bit) alined operands.) For example: I just committed Binutils 2.11.2. Please let me know if this helps or not. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
>> That won't catch all interrupts. Most notably, you won't know >> if commands are completing. Command completions are much more >> prevalent than sequencer or scsi interrupts. > >should I try and catch the command completions? which routine is best >to do this in? ahc_intr() in aic7xxx_inline.h gates all interrupt activity. I don't know that it will tell you why you are hung though. All that is clear is that interrupts at least work for a time. >btw, thanks very much for your help! Sure. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
Justin T. Gibbs wrote: > >John Baldwin wrote: > >> Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try > >> this: find the ahc driver's interrupt handler, and add a printf. > >> Then see if the printf fires while the machine is hung. > > > >Ok, I put a printf in ahc_handle_seqint() and ahc_handle_scsiint(). > > That won't catch all interrupts. Most notably, you won't know > if commands are completing. Command completions are much more > prevalent than sequencer or scsi interrupts. should I try and catch the command completions? which routine is best to do this in? btw, thanks very much for your help! dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) "There aren't any monkeys chasing us..." - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GNU ld(1) dumps core
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>> Oops. I wanted to say: Every software which has a problem with ld
>> dumping core uses nasm (so far). The core dump is a bug in ld, but I
>> didn't know if the condition which triggers the core dump is a problem
>> with nasm, the input of nasm, or a bug in ld.
>
>If someone could provide me with the minal input to nasm which then fed
>to `ld' dumps core, it would really speed up a fix. :-)
Not only nasm, but also gas has same problem. In case of
ports/audio/gogo and ports/audio/lame, nasm outputs object which
make ld dumps core. While gcc+gas outputs object which can't link
by ld. I think the problem occures when "SSE instructions" and
"align" are used. (Unfortunatry, most SSE instructions need
16Byte(=128bit) alined operands.) For example:
==> bug.C <==
/* test program for SSE by kaz @ kobe1995.net
% c++ -g bug.C && ./a.out
But it fails. So,
% c++ -g -S bug.C
And change loop.s to avoid bug of gcc (may be):
#APP
- movaps ($A.15),%xmm0
- movaps ($B.16),%xmm1
+ movaps A.15,%xmm0
+ movaps B.16,%xmm1
#NO_APP
% c++ loop.s && ./a.out
*/
#include
#include
#include
#include
#include
main(){
static float __attribute__((aligned(16)))
A[4]={1.,1.,1.,1.},
B[4]={0.,1.,2.,3.},
C[4];
int i;
printf("float A=(");
for(i=0;i<4;i++)printf("%f,",A[i]);
printf("\b)\n");
printf("float B=(");
for(i=0;i<4;i++)printf("%f,",B[i]);
printf("\b)\n");
asm("movaps (%0),%%xmm0"//SSE
:
:"g"(A));
asm("movaps (%0),%%xmm1"//SSE
:
:"g"(B));
asm("addps %xmm1,%xmm0"); //SSE
// asm("mulps %xmm1,%xmm0"); //SSE
asm("movaps %%xmm0,%0":"=g"(C));//SSE
printf("float C=(");
for(i=0;i<4;i++)printf("%f,",C[i]);
printf("\b)\n");
}
--
NAKAMURA Kazushi@KOBE
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: GNU ld(1) dumps core
Nevermind -- let's try binutils-2.11.2. :-) Thanks David! -- FUJISHIMA Satsuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GNU ld(1) dumps core
At Tue, 26 Jun 2001 07:23:57 -0700, David O'Brien wrote: > If someone could provide me with the minal input to nasm which then fed > to `ld' dumps core, it would really speed up a fix. :-) I'm not sure when but this problem seems to be fixed in CVS at sources.redhat.com. I built binutils from sources a few days ago and their ld works as expected. -- FUJISHIMA Satsuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] ucred.cr_gid
On Tue, 26 Jun 2001, Ruslan Ermilov wrote: > Could someone please take a look at it before I commit this? I won't get a chance to properly review this until I'm at USENIX tomorrow. If you're willing to hold off for about a week, I'd be happy to give it a fairly detailed review: I had some thoughts of doing this when I originally merged ucred and pcred a few weeks ago, but decided to hold off. I'm generally fairly positive about this change, but would be interested in hearing Bruce's thoughts on any compatibility issues, in particular, with respects to the behavior of userland processes with expectations about the old behavior. Obviously, this is a change that is very sensitive to subtle semantic changes on calls--on the other hand, I think moving towards making the supplementary groups being independent from the effect gid is a good goal, as it simplifies our credential code, and improves compatibility. > Date: Fri, 22 Jun 2001 18:05:09 +0300 > From: Ruslan Ermilov <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: ucred.cr_gid > Message-ID: <[EMAIL PROTECTED]> > Mail-Followup-To: [EMAIL PROTECTED], [EMAIL PROTECTED] > > Hi! > > The attached patch replaces ucred.cr_groups[0] with ucred.cr_gid. This > is mostly needed for POSIX alignment. setegid(2) etc. should not change > supplementary groups set. > > Also, type of 's group.gr_gid changed to a more natural gid_t > (also as in POSIX). Sounds good, I think this change was bandied about once before and perhaps simply didn't get committed. > getgrouplist(3)'s and initgroups(3)'s prototypes fixed. getgrouplist(3) > has been also fixed to not duplicate the primary group, and always > return number of suplementary groups, even if ngroups is zero (similar > to sysctl(3)). Having not looked at the patch yet, just need to make sure I point out the following areas that are sensitive to this type of change: linux and other ABI emulation, where semantic mapping of this sort is already performed, as well as userland applications managing groups. > Assorted changes: > > cmsgcred.cmcred_egid New This is an ABI change that will break applications compiled for older versions of FreeBSD. Is this a change that applications can detect via some sort of sizeof/sanity check on cmsg results? > kproc_info.ki_gid New > portal_cred.pcr_gid New > xucred.cr_gid New > > I'm not sure what to do with xucred. Probably reflect changes made in ucred fairly closely. I'll try to give you a detailed code review in a couple of days. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
>John Baldwin wrote: >> Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try >> this: find the ahc driver's interrupt handler, and add a printf. >> Then see if the printf fires while the machine is hung. > >Ok, I put a printf in ahc_handle_seqint() and ahc_handle_scsiint(). That won't catch all interrupts. Most notably, you won't know if commands are completing. Command completions are much more prevalent than sequencer or scsi interrupts. >My current (freshly cvsupped sources) kernel with the printf()s in it >is pretty consistent in it's behavior: with SMP it hangs soon after >the 15 second SCSI delay and keystrokes will not cause it to continue >to boot. > >The order that they print out on the screen is this: > >message "Waiting 15 seconds for SCSI devices to settle" > >(approximately 15 second delay) > >26 times scsiint called with intstat = 0x4, status0 = 0, status = 0x88 > (SELTO & BUSFREE?) So 26 of the 30 possible target ID positions on the controller are empty. >2 times seqint called with instat = 0x71 (BAD_STATUS?) Two commands returned status other than 0 - most likely "check condition". >36 times seqint called with intstat = 0x61 (HOST_MSG_LOOP?) We negotiated transfer settings with some devices. These all seem quite normal. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GNU ld(1) dumps core
On Tue, Jun 26, 2001 at 01:15:17PM +0200, Alexander Leidinger wrote: > Oops. I wanted to say: Every software which has a problem with ld > dumping core uses nasm (so far). The core dump is a bug in ld, but I > didn't know if the condition which triggers the core dump is a problem > with nasm, the input of nasm, or a bug in ld. If someone could provide me with the minal input to nasm which then fed to `ld' dumps core, it would really speed up a fix. :-) -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GNU ld(1) dumps core
On 25 Jun, An: [EMAIL PROTECTED] wrote: >> It seems that there is a bug in the GNU ld(1) in -CURRENT. Currently it can't >> link SDL library from ports/devel/sdl12 port (confirmed by bento). When I'm >> replacing /usr/libexec/elf/ld with the corresponding file from my 4.3-STABLE >> system the problem disappears. Please check what's wrong or pass this report >> to the toolchain developers. Attached please find relevant log with backtrace. > > It seems to be a problem with nasm. I've the same problem with lame > (3.89alpha), same backtrace. Oops. I wanted to say: Every software which has a problem with ld dumping core uses nasm (so far). The core dump is a bug in ld, but I didn't know if the condition which triggers the core dump is a problem with nasm, the input of nasm, or a bug in ld. Bye, Alexander. -- It is easier to fix Unix than to live with NT. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[CFR] ucred.cr_gid
Could someone please take a look at it before I commit this? - Forwarded message from Ruslan Ermilov <[EMAIL PROTECTED]> - Date: Fri, 22 Jun 2001 18:05:09 +0300 From: Ruslan Ermilov <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: ucred.cr_gid Message-ID: <[EMAIL PROTECTED]> Mail-Followup-To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hi! The attached patch replaces ucred.cr_groups[0] with ucred.cr_gid. This is mostly needed for POSIX alignment. setegid(2) etc. should not change supplementary groups set. Also, type of 's group.gr_gid changed to a more natural gid_t (also as in POSIX). getgrouplist(3)'s and initgroups(3)'s prototypes fixed. getgrouplist(3) has been also fixed to not duplicate the primary group, and always return number of suplementary groups, even if ngroups is zero (similar to sysctl(3)). Assorted changes: cmsgcred.cmcred_egidNew kproc_info.ki_gid New portal_cred.pcr_gid New xucred.cr_gid New I'm not sure what to do with xucred. Also, I'm not sure about KINFO_PROC_SIZE on ia64 and PowerPC. Please review. See also ChangeLog. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
