Core Dump / panic sleeping thread

[Konstantin Belousov]

On Wed, Mar 20, 2013 at 08:58:08PM +0200, Konstantin Belousov wrote:
> On Wed, Mar 20, 2013 at 09:43:20AM -0400, John Baldwin wrote:
> > On Wednesday, March 20, 2013 9:22:22 am Konstantin Belousov wrote:
> > > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek wrote:
> > > > 
> > > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov <kostikbel at gmail.com> 
> > wrote:
> > > > > 
> > > > > I do not like it. As I said in the previous response to Andrey,
> > > > > I think that moving the vnode_pager_setsize() after the unlock is
> > > > > better, since it reduces races with other thread seeing half-done
> > > > > attribute update or making attribute change simultaneously.
> > > > 
> > > > OK - so should I wait for another patch - or? 
> > > 
> > > I think the following is what I mean. As an additional note, why nfs
> > > client does not trim the buffers when server reported node size change ?
> > 
> > Will changing the size always result in an mtime change forcing the client to
> > throw away the data on the next read or fault anyway (or does it only affect
> > ctime)?
> 
> UFS only modifies ctime on truncation, it seems.

No, I was wrong. ffs_truncate() indeed only sets both IN_CHANGE | IN_UPDATE
flags for the inode, and IN_UPDATE causes mtime update in ufs_itimes(),
called from UFS_UPDATE().

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130320/d2151ac6/attachment.sig>