|Priority:||4 - Normal|
|Created by:||Jerry Jelinek [X]|
|Reported by:||Jerry Jelinek|
|Assigned to:||Patrick Mooney [X]|
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2017-05-18T15:36:56.000Z)
2017-05-25 ROMANIAN STRIKE (Release Date: 2017-05-25)
On today's platform we're panicing early in boot with this:
SunOS Release 5.11 Version joyent_20170517T115838Z 64-bit Copyright (c) 2010-2017, Joyent Inc. All rights reserved. panic[cpu0]/thread=fffffffffbc386a0: assertion failed: vp->v_path != NULL, file: Warning - stack not written to the dump buffer fffffffffbc7acf0 fffffffffba7ab28 () fffffffffbc7ad20 genunix:vn_recycle+f8 () fffffffffbc7ad40 genunix:vn_reinit+7b () fffffffffbc7ad90 genunix:dnlc_init+17f () fffffffffbc7add0 genunix:main+b8 () fffffffffbc7ade0 unix:_locore_start+90 () skipping system dump - no dump device configured rebooting...
This is due to an interaction between the changes introduced in illumos#8064 and our v_path logic. In two cases (the dnlc and nfs4), vn_reinit() is used to initialize locally defined vnodes. This is a departure from the expected case where vnodes are sourced from vn_alloc() (where they are constructed to have an initialized v_path). As a result, the NULL v_path in those locally defined vnodes will raise an assertion in vn_recycle.
It seems like the simple path forward is to add a v_path == NULL check to vn_reinit(), keeping v_path manipulations abstracted from VFS consumers.