[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference smurf::buildhelp

Title:USG buildhelp questions/answers
Moderator:SMURF::FILTER
Created:Mon Apr 26 1993
Last Modified:Mon Jan 20 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2763
Total number of notes:5802

2141.0. "srequest loses. See %%%%%%% below" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Wed Mar 27 1996 15:43

Date Of Receipt: 	11-MAR-1996 19:46:04.69
From: 	SMURF::GURU::kucherov "sergei kucherov  11-Mar-1996 1942"
To: 	odehelp@dec:.zko.guru
CC: 	kucherov@dec:.zko.guru
Subj: 	srequest loses. See %%%%%%% below

I'm sure I'm not the only one who has recently run into this
(probably new) problem with srequest.
But I may be the first one reporting the problem.
Note that my srequests last week worked perfectly.

	sergei

------- Forwarded Message

Return-Path: kucherov@zk3.dec.com 
Delivery-Date: Mon, 11 Mar 96 19:27:56 -0500
Return-Path: kucherov@zk3.dec.com
Received: by guru.zk3.dec.com; id AA07515; Mon, 11 Mar 1996 19:27:53 -0500
Received: by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM)
	id AA30971; Mon, 11 Mar 1996 19:27:39 -0500
From: sergei kucherov <kucherov@zk3.dec.com>
Received: from secret.zk3.dec.com by falpha.zk3.dec.com; 
(5.65v3.2/1.1.8.2/20May95-1022AM)
	id AA30868; Mon, 11 Mar 1996 19:27:26 -0500
Received: from localhost by secret.zk3.dec.com; 
(5.65v3.2/1.1.8.2/28Oct95-0926PM)
	id AA24396; Mon, 11 Mar 1996 19:27:23 -0500
Message-Id: <9603120027.AA24396@secret.zk3.dec.com>
To: filesystem_submit@secret.zk3.dec.com
Cc: osf_prc@mudrat.zk3.dec.com, osf_submit@secret.zk3.dec.com,
        kenny@zk3.dec.com, brett@zk3.dec.com, kucherov@zk3.dec.com
Subject: Submit request: v32csupportos-148-kucherov
Date: Mon, 11 Mar 96 19:27:23 -0500
X-Mts: smtp
Sender: owner-useg_fs
Precedence: bulk
Reply-To: kucherov@zk3.dec.com


BASELEVEL: 5
USER NAME: kucherov
PRINCIPAL NAME: Sergei_Kucherov
SUBMIT REQUEST DATE: Mon Mar 11 19:27:22 1996
SUBMIT REQUEST DEFECT NUMBER: v32csupportos-148-kucherov
SUBMIT REQUEST STATUS: NEW



                            Submit Request Form

                          Digital Internal Use Only

		     USEG Support Pool Submit Request Form 
			     (Form version 2.3)
	
	================Section 1. Patch Identification=================

1a) Patch Announcement Summary

System panics in AdvFS code when either:
  o ls command is run in the fileset mount directory (containing the .tags file)
  o msfsck is run at least twice and then the AdvFS fileset is unmounted

1b) CLD/SPR/QAR information

CLD/QAR/SPR number(s)    Priority   Component(s)
- ---------------------    --------   ------------
CLD MGO101676               2       FILE SYSTEMS
QAR 35958                   S       ADVFS

1c) Release Note Information
======================================================================
REQUIRED PATCHES (other patches that are MANDATORY to install WITH this patch):

FILES TO BE DISTRIBUTED:
/usr/sys/BINARY/msfs_misc.o    RCS:
INSTALLATION INSTRUCTIONS:
A kernel rebuild is required.
PROBLEM:	( MGO101676 35958 ) (Patch ID: <Ignore this> )

System panics in AdvFS code when either:
 A. ls command is run in the fileset mount directory (containing the .tags file)
 B. msfsck is run at least twice and then the AdvFS fileset is unmounted

Typical stack traces:

PROBLEM A:

>  0 boot(0x0, 0x0, 0xffffffff89052f20, 0xfffffc00006e2000, 0x4eb)
	["../../../../src/kernel/arch/alpha/machdep.c":1735, 0xfffffc00004dfbac]
   1 panic(s = 0xffffffff89052f20 = "N1 = -1027")
	["../../../../src/kernel/bsd/subr_prf.c":757, 0xfffffc000043d5b4]
   2 advfs_sad(0x22, 0x658, 0xfffffc00005e2b30, 0x0, 0xfffffffffffffbfd)
	["../../../../src/kernel/msfs/bs/bs_misc.c":322, 0xfffffc00003d62bc]
   3 seq_search(0xfffffc0001e95001, 0x1, 0xffffffff89053dd0, 0xfffffc0000227130,
 0x0)
	["../../../../src/kernel/msfs/fs/fs_dir_lookup.c":1624, 
0xfffffc00004082cc]
   4 msfs_lookup(0xfffffc0002fb1000, 0xffffffff89053d68, 0x3d, 0x0, 0xffffffff89
053508)
	["../../../../src/kernel/msfs/osf/msfs_lookup.c":608, 
0xfffffc00003fdcbc]
   5 namei(0x52000, 0x0, 0x3, 0x0, 0xfffffc0000392328)
	["../../../../src/kernel/vfs/vfs_lookup.c":563, 0xfffffc0000294fec]
   6 stat1(0xfffffc0000efa210, 0xffffffff890538c8, 0xffffffff890538b8, 0xfffffff
f890538c8, 0xfffffc00004ece18)
	["../../../../src/kernel/vfs/vfs_syscalls.c":2327, 0xfffffc00004541f8]
   7 lstat(0xffffffff890538b8, 0xffffffff890538c8, 0xfffffc00004ece18, 0xfffffc0
0004ed484, 0xfffffc00004ec888)
	["../../../../src/kernel/vfs/vfs_syscalls.c":2307, 0xfffffc000045418c]
   8 syscall(0x11fffd890, 0x1, 0x1, 0x0, 0x44)
	["../../../../src/kernel/arch/alpha/syscall_trap.c":519, 
0xfffffc00004ec884]
   9 _Xsyscall(0x8, 0x12001a7a8, 0x14000bba0, 0x1400069b0, 0x11ffff930)
	["../../../../src/kernel/arch/alpha/locore.s":1094, 0xfffffc00004dcaa4]


PROBLEM B:

>  0 boot(0x0, 0x0, 0xffffffff890a3260, 0xfffffc00006e2000, 0x4a2)
	["../../../../src/kernel/arch/alpha/machdep.c":1735, 0xfffffc00004dfbac]
   1 panic(s = 0xffffffff890a3260 = "")
	["../../../../src/kernel/bsd/subr_prf.c":757, 0xfffffc000043d5b4]
   2 advfs_sad(0x24, 0xe40, 0xfffffc000062ea18, 0x0, 0x0)
	["../../../../src/kernel/msfs/bs/bs_misc.c":322, 0xfffffc00003d62bc]
   3 dqflush(0xffffffff890a34b8, 0x0, 0xfffffc0003839260, 0x0, 0xfffffc000000000
0)
	["../../../../src/kernel/msfs/fs/fs_quota.c":3648, 0xfffffc0000411348]
   4 quota_deactivate(0x2000004, 0xfffffc0000000000, 0x1, 0x11ffffb98, 0xfffffc0
0004017bc)
	["../../../../src/kernel/msfs/fs/fs_quota.c":2163, 0xfffffc000040ec6c]
   5 msfs_unmount(0xfffffc0001be6e00, 0x2, 0x1, 0x11ffffb98, 0x140004e98)
	["../../../../src/kernel/msfs/osf/msfs_vfsops.c":1241, 
0xfffffc00004017f8]
   6 dounmount(0x0, 0x0, 0x2, 0xab7703144a15c, 0x1)
	["../../../../src/kernel/vfs/vfs_syscalls.c":1191, 0xfffffc0000451e5c]
   7 unmount(0xfffffc0003975210, 0xffffffff890a38c8, 0xffffffff890a38b8, 0xfffff
c00004ed484, 0x0)
	["../../../../src/kernel/vfs/vfs_syscalls.c":1116, 0xfffffc0000451d64]
   8 syscall(0x14000cd38, 0x1, 0x1, 0x0, 0x16)
	["../../../../src/kernel/arch/alpha/syscall_trap.c":519, 
0xfffffc00004ec884]
   9 _Xsyscall(0x8, 0x1200113c8, 0x14000a310, 0x140004f60, 0x2)
	["../../../../src/kernel/arch/alpha/locore.s":1094, 0xfffffc00004dcaa4]




1d)	Internal description


    There was a code path in the kernel involving AdvFS private meta files
    which was incorrectly referencing quota data structures.  When an AdvFS
    fileset is unmounted, these quota structures were not being released and
    the above panic is a result.

    Normal use of the AdvFS filesets would not cause this problem to occur,
    however, the unsupported msfsck utility spent most of it time looking at
    the AdvFS private meta files and as a result it caused AdvFS to execute
    the code path with the bug.  The code path could also be executed if the
    ls command is issued in the /mountpoint/.tags/ directory.  The code path
    had to be executed 2 or more times against the same private meta file in
    order to trigger the bug, this is why a single use of msfsck was not a
    problem, but if it was run twice or more, the panic would occur during
    the umount command.


Fixed by:
          /*
           * If this is truly a generic AdvFS file and the context structure's
           * quotaInitialized flag is set to TRUE, we want to attach quota
           * structures to the context structure now.  On the other hand, this
           * may be a non-reserved file (i.e., it has a positive tag) which
           * should never have quota structures attached.  A prime example is
           * the fileset tags directory bitfile.  That file will never end up
           * on the mount queue in the call to bs_insmntque() so it should
           * not have quota structures attached to it.  If it does, then at
           * unmount time, opmntque() won't find them and we will crash in
           * dqflush().  So, in general, we need to see if this is a metadata
           * file and if so, we should not attach quota structures to the
           * context pointer.  Fix for QAR 35958.
           */

	================Section 2. Pool integration=================

2a) Which support pool(s) do you plan to submit to?

	v32de2supportos	[ ]  Support for V3.2D-2 & V3.2E-2 - Hardware Release
	v32de2supportx	[ ]  Support for V3.2D-2 & V3.2E-2 - Hardware Release
	v32de1supportos	[ ]  Support for V3.2D-1 & V3.2E-1
	v32de1supportx	[ ]  Support for V3.2D-1 & V3.2E-1
	v32csupportos	[s]	v32csupportx	[ ]
	v32bsupportos	[s]	v32bsupportx	[ ]	Hardware Release
	v32supportos	[s]	v32supportx	[ ]
	v30bsupportos	[ ]	v30bsupportx	[ ]	Hardware Release
	v30supportos	[ ]	v30supportx	[ ]
	v20bsupportos	[ ]	v20bsupportx	[ ]	Hardware Release
	v20supportos	[ ]	v20supportx	[ ]
	tcr1supportos	[ ]	tcr1supportdx	[ ]
	ase13supportos	[ ]	ase13supportdx	[ ]
	ase3os		[ ]				ASE Hardware Release
	ase12os		[ ]
	ase11supportos	[ ]

2b)	FYI - Does this patch need to be submitted to the development pool(s)?

	HW6		[ ]	platinum	[ ]
	MP2		[ ]	steel		[ ]
	tcr2		[ ]	

2c)	Ported from: 

2d)	Baselevel:

	Baselevel do you wish to submit to?
BL 5 of project v32csupportos

2e)	Integration log:

	cat ../link/Logs/Version.log:

Start build: Fri Mar  8 17:30:12 EST 1996
nightly patch build
project-baselevel: V32CSUPPORTOS-BL5
version.build: 69
version.type: P
version.variant: C
version.patch: -5
Done build: Sat Mar  9 04:53:33 EST 1996
Start install: Sat Mar  9 04:55:33 EST 1996
Done install: Sat Mar  9 06:06:41 EST 1996

	================Section 3. Testing=================

3a) Code Reviewer:

Tim Mark

3b) Functional Testing - Prior to srequest:


A.
mkfdmn /dev/rz8h test_domain
mkfset test_domain foo
mkdir /foo
mount -t advfs test_domain#foo /foo
cd /foo
ls
# observe panic. After fix a similar sequence does not panic.

B.
msfsck test_domain
msfsck test_domain
cd /
umount /foo
# observe panic. After fix a similar sequence does not panic.

# cleanup
rmfset test_domain foo
rm -rf /etc/fdmns/test_domain

3c) Regression Testing:


Tested REALTIME		N/A

Tested SAS		N/A

3d) Test Instruments:


	================Section 4. Customer Impacts=================

4a) For shared libraries only:

ORIGINAL:

CURRENT:

NEW:

4b) Compatibility impacts:

NO:

4c) Standards Compliance:

NO:

	================Section 5. Inventory Content Changes=================

5a) Changed inventories:

NEW inventory files:

DEFUNCT inventory files:

CHANGED	inventory files:

5b) List Source files:

	bstat -all for the list of files and the revs:

[ ./kernel/msfs/osf/msfs_misc.c ]
version 1.1.78.2 selected setname Sergei_Kucherov_mgoc

	================Section 6. Code differences=================

6)	Code Diffs:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
NOTE TO ODE FOLKS: SREQUEST FILLED IN THE BELOW DIFF INCORRECTLY.
IT RETRIEVED THE WRONG VERSION (1.1.33.7 rather than 1.1.62.3).
I LEAVE THE EVIDENCE HERE FOR YOU TO FIX THE SREQUEST TOOL ASAP.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

		bdiff -r$NEW -all -c >& bdiff.log

[ ./kernel/msfs/osf/msfs_misc.c ]
===================================================================
RCS file: ./kernel/msfs/osf/msfs_misc.c,v
retrieving revision 1.1.33.7
diff -c -r1.1.33.7 OdeSrvrTmpSergei_Kucherov011007/msfs_misc.c
*** 1.1.33.7	1995/06/22 20:40:21
- --- OdeSrvrTmpSergei_Kucherov011007/msfs_misc.c	1996/03/11 23:07:29
***************
*** 26,38 ****
  /*
   * HISTORY
   * $Log: msfs_misc.c,v $
   * Revision 1.1.33.7  1995/06/22  20:40:21  Craig_Wright
   * 	In msfs_getpage(), remove the setting of file size, because it is
   * 	only called by fault handlers which can't extend the file, and
   * 	msfs_bread().  Originally fixed for qar 31500 by Ann_Milicia, this
   * 	also fixes 32846 and 32628.
   * 	[1995/06/22  17:25:33  Craig_Wright]
!  *
   * Revision 1.1.33.6  1995/06/13  20:45:27  Seema_Peterson
   * 	Update access time and dirty_stats in the file context structure in
   * 	the bread path. Fix for QAR 32979/33011.
- --- 26,56 ----
  /*
   * HISTORY
   * $Log: msfs_misc.c,v $
+  * Revision 1.1.78.2  1996/03/11  20:10:02  Sergei_Kucherov
+  * 	 Use suggested fix from Tim_Mark to address CLD MGO101676.
+  * 	In bf_get_l(), don't attach quota structures to a context pointer if
+  * 	the file in question is a metadata file.  Fix for QAR 35958.  This
+  * 	problem was trigged by running msfsck 2 or more times against the
+  * 	fileset and then umount'ing the fileset.  It could also be triggered
+  * 	by doing an ls against the metadata files in the .tags directory.
+  * 	This fix prevents AdvFS metadata files from having dQuot structures
+  * 	attached by mistake.
+  *
+  * Revision 1.1.62.3  1995/11/02  18:36:59  Jeff_Dike
+  * 	Backport of domain panic fixes.
+  * 	[1995/10/19  20:38:24  Jeff_Dike]
+  * 
+  * Revision 1.1.62.2  1995/10/18  20:32:03  David_Winchell
+  * 	      Use new ubc_page_wait() macro instead of vm_page_wait() for UBC 
pages.
+  * 	[1995/10/18  16:51:45  David_Winchell]
+  * 
   * Revision 1.1.33.7  1995/06/22  20:40:21  Craig_Wright
   * 	In msfs_getpage(), remove the setting of file size, because it is
   * 	only called by fault handlers which can't extend the file, and
   * 	msfs_bread().  Originally fixed for qar 31500 by Ann_Milicia, this
   * 	also fixes 32846 and 32628.
   * 	[1995/06/22  17:25:33  Craig_Wright]
!  * 
   * Revision 1.1.33.6  1995/06/13  20:45:27  Seema_Peterson
   * 	Update access time and dirty_stats in the file context structure in
   * 	the bread path. Fix for QAR 32979/33011.
***************
*** 373,379 ****
   * 
   * $EndLog$
   */
! #pragma ident "@(#)$RCSfile: msfs_misc.c,v $ $Revision: 1.1.33.7 $ (DEC) 
$Date: 1995/06/22 20:40:21 $"
  
  #include <sys/param.h>
  #include <sys/user.h>
- --- 391,397 ----
   * 
   * $EndLog$
   */
! #pragma ident "@(#)$RCSfile: msfs_misc.c,v $ $Revision: 1.1.78.2 $ (DEC) 
$Date: 1996/03/11 20:10:02 $"
  
  #include <sys/param.h>
  #include <sys/user.h>
***************
*** 388,398 ****
  #include <sys/mode.h>
  #include <sys/mount.h>
  #include <msfs/ms_assert.h>
! #ifdef mips
! #include <arch/mips/vm_ubc.h>
! #else /* mips */
! #include <arch/alpha/vm_ubc.h>
! #endif /* mips */
  
  #include <msfs/ms_shelve.h>
  #ifdef ADVFS_SHELVE
- --- 406,412 ----
  #include <sys/mode.h>
  #include <sys/mount.h>
  #include <msfs/ms_assert.h>
! #include <sys/vfs_ubc.h>
  
  #include <msfs/ms_shelve.h>
  #ifdef ADVFS_SHELVE
***************
*** 775,781 ****
  	if (nvp->v_mount == DEADMOUNT) {
  	  file_context->fileSetNode = GETFILESETNODE(mp);
            bs_insmntque(FtxNilFtxH, bf_access, mp);
!           if (file_context->quotaInitialized) 
              /* Attach file quotas. */
              (void) attach_quota(file_context, FtxNilFtxH);
          }
- --- 789,812 ----
  	if (nvp->v_mount == DEADMOUNT) {
  	  file_context->fileSetNode = GETFILESETNODE(mp);
            bs_insmntque(FtxNilFtxH, bf_access, mp);
! 
!           /*
!            * If this is truly a generic AdvFS file and the context structure's
!            * quotaInitialized flag is set to TRUE, we want to attach quota
!            * structures to the context structure now.  On the other hand, this
!            * may be a non-reserved file (i.e., it has a positive tag) which 
!            * should never have quota structures attached.  A prime example is
!            * the fileset tags directory bitfile.  That file will never end up
!            * on the mount queue in the call to bs_insmntque() so it should
!            * not have quota structures attached to it.  If it does, then at
!            * unmount time, opmntque() won't find them and we will crash in
!            * dqflush().  So, in general, we need to see if this is a metadata
!            * file and if so, we should not attach quota structures to the
!            * context pointer.  Fix for QAR 35958.
!            */
!           if ((!(flag & META_OPEN)) &&
!               (!(file_context->fs_flag & META_OPEN)) &&
!               file_context->quotaInitialized)
              /* Attach file quotas. */
              (void) attach_quota(file_context, FtxNilFtxH);
          }
***************
*** 1859,1864 ****
- --- 1890,1896 ----
      int page;
      int i = 0;
      bfAccessHT faccess;
+     bfAccessT *bfap;
      bfDomainHT dmnH = GETDOMAINH( VTOMOUNT( vp ) );
      int error = 0;
      int sparse_write = FALSE;
***************
*** 1886,1891 ****
- --- 1918,1924 ----
      MS_ASSERT(contextp->initialized);
      faccess = VTOA( vp );
      MS_ASSERT(faccess);
+     bfap = bs_bf_htop(faccess);
  
      *pl = VM_PAGE_NULL;
  
***************
*** 1897,1902 ****
- --- 1930,1943 ----
  
      mutex_lock( &contextp->fsContext_mutex );
  
+     /*
+      * screen domain panic
+      */
+     if (bfap->domainp->dmn_panic) {
+         error = EIO;
+ 	goto _error;
+     }
+ 
      fsize = contextp->dir_stats.st_size;
  
      if (sparse_write || ((offset >= fsize ) && !(rwflg & B_READ)) || 
loadFragFlag) {
***************
*** 2578,2584 ****
       * Link pages together
       */
      for (lp = 0, pp = pl; (*pp != VM_PAGE_NULL); pp++) {
!         vm_page_wait( *pp );
  
          if (lp) {
              lp->pg_pnext = *pp;
- --- 2619,2625 ----
       * Link pages together
       */
      for (lp = 0, pp = pl; (*pp != VM_PAGE_NULL); pp++) {
!         ubc_page_wait( *pp );
  
          if (lp) {
              lp->pg_pnext = *pp;

	==================================================================
                          Digital Internal Use Only



*********************************************************************
To unsubscribe from this list, send mail to majordomo@zk3.dec.com or
ALPHA::MAJORDOMO (from VMS) with the following text:
unsubscribe useg_fs

For help with the majordomo commands, the text should be:
help
*********************************************************************


------- End of Forwarded Message


T.RTitleUserPersonal
Name
DateLines