>-----Original Message----- >From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs- >owner@xxxxxxxxxxxxxxx] On Behalf Of andros@xxxxxxxxxx >Sent: Wednesday, July 07, 2010 3:34 PM >To: bhalevy@xxxxxxxxxxx >Cc: linux-nfs@xxxxxxxxxxxxxxx >Subject: [PATCH 0/16] pnfs-submit fix layout allocation and reference >counting > > > >The current nfs_inode has an embedded pnfs_layout_type structure, with per >layout type private data allocated. Change nfs_inode->layout to be a >pointer >to a pnfs_layout_type structure, embed the pnfs_layout_type in the per >layout type structure, and allocate both. > >The current pnfs_layout_type allocation waits on a bit lock to handle >concurrent allocation attempts. Replace this with the normal form. > >The current pnfs_layout_type reference counting is very un-clear, and one >instance of put_layout was called outside the i_lock which probably was >causing the intermittant pnfs_layout_type refcount bug we've been seeing. > >Replace the nfs_inode->layout reference counting with the following scheme: I am a newbee and would appreciate a little enlightenment: I read an article from a few years ago that stated 'The "kobject" structure first made its appearance in the 2.5.45 development kernel. It was initially meant as a simple way of unifying kernel code which manages reference counted objects.' It seems from my naïve viewpoint that a "kobject" might be used here. Why not? Does it have something to do with the "mission creep" mentioned in the article? Thanks for your patients. -=# Paul Gilliam #=- -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
