From owner-freebsd-fs@freebsd.org Sun Nov 15 02:54:26 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF7CEA2811A for ; Sun, 15 Nov 2015 02:54:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C6D41C38 for ; Sun, 15 Nov 2015 02:54:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAF2sQeF041437 for ; Sun, 15 Nov 2015 02:54:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 122588] [lor] 4 Lock Order Reversal Date: Sun, 15 Nov 2015 02:54:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 02:54:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=122588 NGie Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org CC| |ngie@FreeBSD.org --- Comment #2 from NGie Cooper --- Most of these LORs are known, but the 2nd and 4th LORs look interesting (I don't remember seeing LORs with vfslock and pseudofs recently). Reassigning to -fs@ for triage. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sun Nov 15 02:54:44 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75144A28163 for ; Sun, 15 Nov 2015 02:54:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 620DA1CF8 for ; Sun, 15 Nov 2015 02:54:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAF2sico048337 for ; Sun, 15 Nov 2015 02:54:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 122588] [lor] 4 Lock Order Reversal (pseudofs/ufs/vfs) Date: Sun, 15 Nov 2015 02:54:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 02:54:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=122588 NGie Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[lor] 4 Lock Order Reversal |[lor] 4 Lock Order Reversal | |(pseudofs/ufs/vfs) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sun Nov 15 05:46:58 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6D64A2F637 for ; Sun, 15 Nov 2015 05:46:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1F0119DB for ; Sun, 15 Nov 2015 05:46:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAF5kw3H012292 for ; Sun, 15 Nov 2015 05:46:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 127270] fsck_msdosfs(8) may crash if BytesPerSec is zero Date: Sun, 15 Nov 2015 05:46:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 7.1-PRERELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: ngie@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 05:46:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=127270 NGie Cooper changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-fs@FreeBSD.org |ngie@FreeBSD.org CC| |ngie@FreeBSD.org --- Comment #2 from NGie Cooper --- This should avoid the divide by 0, but I'd need to verify that the behavior is correct: https://people.freebsd.org/~ngie/bug127270.patch This situation should occur if and when boot blocks 12 and 13 are 0, but there might need to be some additional conditions that need to be tripped in order for the divide by 0 to occur: 66 boot->bpbBytesPerSec = block[11] + (block[12] << 8); -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sun Nov 15 15:29:24 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A863A2FD9A for ; Sun, 15 Nov 2015 15:29:24 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 07DC41123 for ; Sun, 15 Nov 2015 15:29:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id ED4277815DC for ; Mon, 16 Nov 2015 02:29:14 +1100 (AEDT) Date: Mon, 16 Nov 2015 02:29:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org cc: freebsd-fs@freebsd.org Subject: Re: [Bug 127270] fsck_msdosfs(8) may crash if BytesPerSec is zero In-Reply-To: Message-ID: <20151116021615.X932@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=cK4dyQqN c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=9cW_t1CCXrUA:10 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=Z8M1z4-aN0-FwmMLC9sA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 15:29:24 -0000 On Sun, 15 Nov 2015 bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=127270 > > NGie Cooper changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Assignee|freebsd-fs@FreeBSD.org |ngie@FreeBSD.org > CC| |ngie@FreeBSD.org > > --- Comment #2 from NGie Cooper --- > This should avoid the divide by 0, but I'd need to verify that the behavior is > correct: > https://people.freebsd.org/~ngie/bug127270.patch > > This situation should occur if and when boot blocks 12 and 13 are 0, but there > might need to be some additional conditions that need to be tripped in order > for the divide by 0 to occur: > > 66 boot->bpbBytesPerSec = block[11] + (block[12] << 8); This is fixed as a side effect of other fixes in my version. (The sector size needs to be read from the media. Instead, a hard-coded sector size or a larger size is used in all fsck utilities and kernel code. Sometimes this size is too small or too large to work. ffs probes for some things but not the size.) X Index: boot.c X =================================================================== X RCS file: /home/ncvs/src/sbin/fsck_msdosfs/boot.c,v X retrieving revision 1.6 X diff -u -2 -r1.6 boot.c X --- boot.c 31 Jan 2008 13:16:29 -0000 1.6 X +++ boot.c 3 Jul 2010 16:53:33 -0000 X @@ -48,4 +48,6 @@ X #include "fsutil.h" X X +#define IOSIZE 65536 X + X int X readboot(dosfs, boot) X @@ -53,18 +55,48 @@ X struct bootblock *boot; X { X + u_char ioblock[IOSIZE]; X + u_char iofsinfo[IOSIZE]; X + u_char iobackup[IOSIZE]; X u_char block[DOSBOOTBLOCKSIZE]; X u_char fsinfo[2 * DOSBOOTBLOCKSIZE]; X u_char backup[DOSBOOTBLOCKSIZE]; X + u_char *infop; X + size_t iosize; X + u_int secsize; X int ret = FSOK; X X - if (read(dosfs, block, sizeof block) < sizeof block) { X + /* Search for an i/o size that works. */ X + for (iosize = IOSIZE; iosize >= DOSBOOTBLOCKSIZE; iosize >>= 1) { X + if (lseek(dosfs, (off_t)0, SEEK_SET) == 0 && X + read(dosfs, ioblock, iosize) == (ssize_t)iosize) X + break; X + } X + if (iosize < DOSBOOTBLOCKSIZE) { X perror("could not read boot block"); X return FSFATAL; X } X + memcpy(block, ioblock, sizeof block); X X - if (block[510] != 0x55 || block[511] != 0xaa) { X - pfatal("Invalid signature in boot block: %02x%02x", block[511], block[510]); X + /* X + * Preliminary decode to determine where the signature might be. X + * It is supposed to be at the end of a 512-block, but we used to X + * put it at the end of a sector. Accept the latter so as to fix X + * it someday. X + */ X + secsize = block[11] + (block[12] << 8); X + if (secsize < sizeof block || secsize > IOSIZE) { X + perror("Preposterous or unsupported sector size"); X return FSFATAL; X } A sector size of 0 and some other preposterous sizes are rejected here. Sizes that are not multiples of 512 are still allowed. The signature checks weed out most garbage. X + if (block[510] != 0x55 || block[511] != 0xaa) { X + if (ioblock[secsize - 2] != 0x55 || X + ioblock[secsize - 1] != 0xaa) { X + pfatal("Invalid signature in boot block: %02x%02x", X + block[511], block[510]); X + return FSFATAL; X + } X + pwarn( X + "Invalid primary signature in boot block -- using secondary\n"); X + } X X memset(boot, 0, sizeof *boot); X [... remainder of patch not included] Bruce From owner-freebsd-fs@freebsd.org Sun Nov 15 16:41:02 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD583A30190 for ; Sun, 15 Nov 2015 16:41:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C94CF1FF6 for ; Sun, 15 Nov 2015 16:41:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAFGf2MD006984 for ; Sun, 15 Nov 2015 16:41:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193965] [zfs] zpool coredump on import Date: Sun, 15 Nov 2015 16:41:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: will@worrbase.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 16:41:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193965 --- Comment #4 from will@worrbase.com --- Hey, I know this is a fairly old bug, but I was able to reproduce it on 10.2-STABLE by removing the log device and rebooting. I'll try and produce some more dumps or a patch today. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sun Nov 15 16:41:18 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C207BA301BC for ; Sun, 15 Nov 2015 16:41:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AED06109D for ; Sun, 15 Nov 2015 16:41:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAFGfIjZ007800 for ; Sun, 15 Nov 2015 16:41:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193965] [zfs] zpool coredump on import Date: Sun, 15 Nov 2015 16:41:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: will@worrbase.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: version Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 16:41:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193965 will@worrbase.com changed: What |Removed |Added ---------------------------------------------------------------------------- Version|10.0-RELEASE |10.2-STABLE -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sun Nov 15 21:27:01 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C907A2F397 for ; Sun, 15 Nov 2015 21:27:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E44E415ED for ; Sun, 15 Nov 2015 21:27:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id E2106A2F396; Sun, 15 Nov 2015 21:27:00 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1891A2F394 for ; Sun, 15 Nov 2015 21:27:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 6983015EC for ; Sun, 15 Nov 2015 21:26:59 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id E277C1A26C0; Mon, 16 Nov 2015 07:59:48 +1100 (AEDT) Date: Mon, 16 Nov 2015 07:59:48 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans cc: Konstantin Belousov , Kirk McKusick , fs@freebsd.org Subject: fixing the vnode cache (was: Re: an easy (?) question on namecache sizing) In-Reply-To: <20151105043607.K3175@besplex.bde.org> Message-ID: <20151116035721.H1540@besplex.bde.org> References: <20151102224910.E2203@besplex.bde.org> <201511030447.tA34lo5O090332@chez.mckusick.com> <20151103090448.GC2257@kib.kiev.ua> <20151105043607.K3175@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=R6/+YolX c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=lBPozctHxlCGmP5tV90A:9 a=22Eukok0kU7WRqKD:21 a=E7JcsIwkmnokYeuG:21 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 21:27:01 -0000 On Thu, 5 Nov 2015, Bruce Evans wrote: > ... > Here is my work in progress: > ... Here is my work sort of finished. It was a lot of work, and fixes many bugs, but many fundamental bugs remain to be fixed -- the LRU ordering has been broken since about FreeBSD-3, and new and old fixes are mostly complicated messes to work around that. The main changes here are: - fix watermarks - update comments - add comments X diff -u2 ../../kern/vfs_subr.c~ ../../kern/vfs_subr.c X --- ../../kern/vfs_subr.c~ 2015-09-28 06:29:43.000000000 +0000 X +++ ../../kern/vfs_subr.c 2015-11-15 02:12:51.170795000 +0000 X @@ -98,4 +98,7 @@ X #endif X X +volatile static int vlru_verbose = 1; X +#define DPRINTF(...) do { if (vlru_verbose) printf(__VA_ARGS__); } while (0) X + X static void delmntque(struct vnode *vp); X static int flushbuflist(struct bufv *bufv, int flags, struct bufobj *bo, This patch has too much debugging code for production use or commit, but if you try it then keep the debugging messages on to observe how infrequently reclamation is done and perhaps to see what it does. X @@ -147,22 +150,36 @@ X X /* X - * Free vnode target. Free vnodes may simply be files which have been stat'd X - * but not read. This is somewhat common, and a small cache of such files X - * should be kept to avoid recreation costs. X + * "Free" vnode target. Free vnodes are rarely completely free, but are X + * just ones that are cheap to recycle. Usually they are for files which X + * have been stat'd but not read; these usually have inode and namecache X + * data attached to them. This target is the preferred minimum size of a X + * sub-cache consisting mostly of such files. The system balances the size X + * of this sub-cache with its complement to try to prevent either from X + * thrashing while the other is relatively inactive. The targets express X + * a preference for the best balance. X + * X + * "Above" this target there are 2 further targets (watermarks) related X + * to recyling of free vnodes. In the best-operating case, the cache is X + * exactly full, the free list has size between vlowat and vhiwat above the X + * free target, and recycling from it and normal use maintains this state. X + * Sometimes the free list is below vlowat or even empty, but this state X + * is even better for immediate use provided the cache is not full. X + * Otherwise, vnlru_proc() runs to reclaim enough vnodes (usually non-free X + * ones) to reach one of these states. The watermarks are currently hard- X + * coded as 4% and 9% of the available space higher. These and the default X + * of 25% for wantfreevnodes are too large if the memory size is large. X + * E.g., 9% of 75% of MAXVNODES is more than 566000 vnodes to reclaim X + * whenever vnlru_proc() becomes active. X */ The comment explains lots of what this patch does, but not much of the history that led to this mess. In 4.4BSD-Lite*, the free list contained all inactive vnodes and I think also some really free ones (not pointing to anything, but holding unused malloced memory). getnewvnode() reclaimed directly. desiredvnodes existed and wantvnodes didn't exist, but the cache size was allowed to grow in emerency up to size 2*desiredvnodes and without reclamation up to size desiredvnodes. So it sort of had actual size 2*desiredvnodes and wantvnodes was spelled desiredvnodes and gave its actual size. LRU worked perfectly except in cases where the reclmation had to skip a locked vnode). In FreeBSD-3, wantfreevnodes existed and defaulted to 25. It could be set to 0 to get the old behaviour for for freevnodes <= numvnodes, but growth above desiredvnodes up to 2*desiredvnodes more strongly restricted (perhaps disallowed). I don't see how the small default of 25 could have been right even in 1993 before it was added, when memory and cache sizes were smaller. Reclamation was still done directly in getvnode(), so LRU order was still usually used when reclamation was done. However, FreeBSD-3 hangs on to vnodes more strongly than 4.4BSD, so the free list tends to fill up with old unused garbage. Collection of this garbage is still inadequate. wantfreevnodes had no comment on it in FreeBSD-3. The comment on it that was fixed above was added later, and it was wrong even for FreeBSD-3. In all versions, the reason for "want"ing this number of vnodes seems to be to avoid thashing through a cache of even smaller size, and has nothing to do with reclamation costs like the comment says. The FreeBSD-3 default of 25 looks too small even for a watermark delta, but really was used for the minimum cache size. And it really asked for a negative usuable size, since the cache usually soon fills up with more than 25 unreclaimable garbage vnodes. In FreeBSD-4, reclamation is sometimes done (hopefully in advance) by vnlru_proc(), much like in -current but with differently broken watermarks. Held vnodes are no longer kept on the free list or reclained directly by getnewvnode(). Held vnodes are not kept in LRU order. This breaks LRU order for held vnodes. Held vnode are reclaimed by freeing everything attached and putting them on the free list. LRU order for them is honored only after that. wantfreevnodes is still 25, but it is not as broken as before since the unreclaimable garbage vnodes are not counted in freevnodes. In later versions ending in -current, wantfreevnodes is increased to a reasonably large value. Held vnodes are reclaimed by freeing eveything including themselves and not putting them on the free list. The brokenness in the watermarks was moved by misadjusting for the differences in counts caused by this. The default free list levels in this patch are min = 25%, low = 28%, high = 32% and max = 100% (growing above high is uninhibited and growing below low is inhibited). The corresponding levels in -current are sort of: min = 25%, low1 = 90% (in vnlru_proc()), low2 = 100% (in getnewvnode()), high = 100% and max = 25% (growing in either direction from min = max is inhibited, and low* and high are nonsense). low* and high are actually watermarks on the full cache and only affect the free list and easily reclaimable space indirectly. They are wrong for that too -- 100% for getnewvnode() delays the reclaiiming until it has no chance of completing without waiting, 90% for vnlru_proc() is inconsistent with this the inclosistency is necessary for things to mostly work OK by reclaiming enough in advance, at a cost of wasted space and time. X static u_long wantfreevnodes; X -SYSCTL_ULONG(_vfs, OID_AUTO, wantfreevnodes, CTLFLAG_RW, &wantfreevnodes, 0, ""); X -/* Number of vnodes in the free list. */ X +SYSCTL_ULONG(_vfs, OID_AUTO, wantfreevnodes, CTLFLAG_RW, X + &wantfreevnodes, 0, "Target for minimum number of \"free\" vnodes"); X static u_long freevnodes; X -SYSCTL_ULONG(_vfs, OID_AUTO, freevnodes, CTLFLAG_RD, &freevnodes, 0, X - "Number of vnodes in the free list"); X - X -static int vlru_allow_cache_src; X -SYSCTL_INT(_vfs, OID_AUTO, vlru_allow_cache_src, CTLFLAG_RW, X - &vlru_allow_cache_src, 0, "Allow vlru to reclaim source vnode"); X +SYSCTL_ULONG(_vfs, OID_AUTO, freevnodes, CTLFLAG_RD, X + &freevnodes, 0, "Number of \"free\" vnodes"); X X static u_long recycles_count; X SYSCTL_ULONG(_vfs, OID_AUTO, recycles, CTLFLAG_RD, &recycles_count, 0, X - "Number of vnodes recycled to avoid exceding kern.maxvnodes"); X + "Number of vnodes recycled to meet vnode cache targets"); X X /* Clean up names and descriptions in sysctls a bit too. X @@ -274,12 +291,11 @@ X syncer_state; X X -/* X - * Number of vnodes we want to exist at any one time. This is mostly used X - * to size hash tables in vnode-related code. It is normally not used in X - * getnewvnode(), as wantfreevnodes is normally nonzero.) X - * X - * XXX desiredvnodes is historical cruft and should not exist. X - */ X +/* Target for maximum number of vnodes. */ X int desiredvnodes; The code has been churned so much that this variable was already almost correct again, but its comments were wrong. X +static int gapvnodes; /* gap between wanted and desired */ X +static int vhiwat; /* enough extras after expansion */ X +static int vlowat; /* minimal extras before expansion */ X +static int vstir; /* nonzero to stir non-free vnodes */ X +static volatile int vsmalltrigger = 8; /* pref to keep if > this many pages */ X X static int X @@ -292,4 +308,6 @@ X return (error); X if (old_desiredvnodes != desiredvnodes) { X + wantfreevnodes = desiredvnodes / 4; X + /* XXX locking seems to be incomplete. */ X vfs_hash_changesize(desiredvnodes); X cache_changesize(desiredvnodes); There seems to be only Giant locking for the sysctl. This is more than enough for *vnodes since we allow for them being garbage, but vfs_hash and vfs_cache need more. X @@ -300,7 +318,7 @@ X SYSCTL_PROC(_kern, KERN_MAXVNODES, maxvnodes, X CTLTYPE_INT | CTLFLAG_MPSAFE | CTLFLAG_RW, &desiredvnodes, 0, X - sysctl_update_desiredvnodes, "I", "Maximum number of vnodes"); X + sysctl_update_desiredvnodes, "I", "Target for maximum number of vnodes"); X SYSCTL_ULONG(_kern, OID_AUTO, minvnodes, CTLFLAG_RW, X - &wantfreevnodes, 0, "Minimum number of vnodes (legacy)"); X + &wantfreevnodes, 0, "Old name for vfs.wantfreevnodes (legacy)"); X static int vnlru_nowhere; X SYSCTL_INT(_debug, OID_AUTO, vnlru_nowhere, CTLFLAG_RW, X @@ -310,4 +328,16 @@ X static int vnsz2log; X X +/* Statistics/debugging. */ X +static volatile int vdry; X +static int vexamined; X +static int vdir; X +static int vobj; X +static int vinuse; X +static int vcache; X +static int vfree; X +static int vdoom; X +static int vbig; X +static int vskip; X + X /* X * Support for the bufobj clean & dirty pctrie. vdry can be set using ddb to 1, 2, or these values ORed with 4 or 8, to do a dry reclaim run. X @@ -333,8 +363,8 @@ X * Reevaluate the following cap on the number of vnodes after the physical X * memory size exceeds 512GB. In the limit, as the physical memory size X - * grows, the ratio of physical pages to vnodes approaches sixteen to one. X + * grows, the ratio of the memory size in KB to to vnodes approaches 64:1. X */ X #ifndef MAXVNODES_MAX X -#define MAXVNODES_MAX (512 * (1024 * 1024 * 1024 / (int)PAGE_SIZE / 16)) X +#define MAXVNODES_MAX (512 * 1024 * 1024 / 64) /* 8M */ X #endif X static void X @@ -347,13 +377,14 @@ X * Desiredvnodes is a function of the physical memory size and the X * kernel's heap size. Generally speaking, it scales with the X - * physical memory size. The ratio of desiredvnodes to physical pages X - * is one to four until desiredvnodes exceeds 98,304. Thereafter, the X - * marginal ratio of desiredvnodes to physical pages is one to X - * sixteen. However, desiredvnodes is limited by the kernel's heap X + * physical memory size. The ratio of desiredvnodes to the physical X + * memory size is 1:16 until desiredvnodes exceeds 98,304. X + * Thereafter, the X + * marginal ratio of desiredvnodes to the physical memory size is X + * 1:64. However, desiredvnodes is limited by the kernel's heap X * size. The memory required by desiredvnodes vnodes and vm objects X - * may not exceed one seventh of the kernel's heap size. X + * must not exceed 1/7th of the kernel's heap size. X */ X - physvnodes = maxproc + vm_cnt.v_page_count / 16 + 3 * min(98304 * 4, X - vm_cnt.v_page_count) / 16; X + physvnodes = maxproc + pgtok(vm_cnt.v_page_count) / 64 + X + 3 * min(98304 * 16, pgtok(vm_cnt.v_page_count)) / 64; X virtvnodes = vm_kmem_size / (7 * (sizeof(struct vm_object) + X sizeof(struct vnode))); Start fixing defaults. The comments are still too verbose. The main change here is from sizes in pages to sizes in K. Pages don't scale correctly. E.g., 8K-pages gave half as many vnodes as 4K pages, but the best number of vnodes is unrelated to the page size unless the memory size is very small. I only looked at this because the trigger ppoint depends magically on the scaling here. X @@ -744,28 +775,16 @@ X */ X static int X -vlrureclaim(struct mount *mp) X +vlrureclaim(struct mount *mp, int reclaim_nc_src, int trigger) X { X struct vnode *vp; X - int done; X - int trigger; X - int usevnodes; X - int count; X + int count, done, target; X X - /* X - * Calculate the trigger point, don't allow user X - * screwups to blow us up. This prevents us from X - * recycling vnodes with lots of resident pages. We X - * aren't trying to free memory, we are trying to X - * free vnodes. X - */ X - usevnodes = desiredvnodes; X - if (usevnodes <= 0) X - usevnodes = 1; X - trigger = vm_cnt.v_page_count * 2 / usevnodes; Calculations mostly moved to caller and fixed. X done = 0; X vn_start_write(NULL, &mp, V_WAIT); X MNT_ILOCK(mp); X - count = mp->mnt_nvnodelistsize / 10 + 1; X - while (count != 0) { X + count = mp->mnt_nvnodelistsize; X + target = count * (int64_t)gapvnodes / imax(desiredvnodes, 1); X + target = target / 10 + 1; X + while (count != 0 && done < target) { X vp = TAILQ_FIRST(&mp->mnt_nvnodelist); X while (vp != NULL && vp->v_type == VMARKER) 'count' is now scaled by gapvnodes/desiredvnodes. This ratio is normally not much below 1, but configuring wantfreevnodes much higher is supposed to work well now and this gives smaller ratios (down to about 1/10 is OK). When most vnodes are free, there is no chance of getting 10% of numvnodes from non-free ones here. Getting free ones here was harmful and is no longer done. The mist important fix here is to not stop after looking at just 'count' vnodes. Often the cache consists of mostly unreclaimable vnodes so 10% can't be reclaimed even if you search to the end, or none can be reclaimed if you hit a block of unreclaimable ones and stop early. This caused the "tick" behaviour of 1 vnode creation per 1 or 3 seconds more often than necessary. So the search is now to approximately to the end. This may take a lot of CPU, but only when necessary. In normal use, the search length is extended by 10-100%. Rarely by 1000%. More rarely to the end. X @@ -773,4 +792,22 @@ X if (vp == NULL) X break; X + /* X + * XXX LRU is completely broken for non-free vnodes. First X + * by calling here in mountpoint order, then by moving X + * unselected vnodes to the end here, and most grossly by X + * removing the vlruvp() function that was supposed to X + * maintain the order. (This function was born broken X + * since syncer problems prevented it doing anything.) The X + * order is closer to LRC (C = Created). X + * X + * LRU reclaiming of vnodes seems to have last worked in X + * FreeBSD-3 where LRU wasn't mentioned under any spelling. X + * Then there was no hold count, and inactive vnodes were X + * simply put on the free list in LRU order. The separate X + * lists also break LRU. We prefer to reclaim from the X + * free list for technical reasons. This tends to thrash X + * the free list to keep very unrecently used held vnodes. X + * The problem is mitigated by keeping the free list large. X + */ X TAILQ_REMOVE(&mp->mnt_nvnodelist, vp, v_nmntvnodes); X TAILQ_INSERT_TAIL(&mp->mnt_nvnodelist, vp, v_nmntvnodes); This is wrong about there being no hold count in FreeBSD-3. I don't see any reason why this can't be or wasn't fixed by simply anyother list of all vnodes in LRU order. This function can use this list and the syncer can keep using the old list. This would fix the LRU problem, leaving only the problem of old garbage clogging up the non-free part and being almost unlimited in time and space. X @@ -781,10 +818,35 @@ X * If it's been deconstructed already, it's still X * referenced, or it exceeds the trigger, skip it. X + * XXX reword and update above and merge with the following. X + * Skip free vnodes. We are trying to make space to expand X + * the free list, not reduce it. X */ Reclaiming from the free list here didn't create any useful space, but broke the LRU order for the free list part where it still works. X + if (vdry & 1 && (vp->v_iflag & VI_FREE) == 0) X + goto out; X + if (vdry & 2 && (vp->v_iflag & VI_FREE) != 0) X + goto out; X + vexamined++; X + if (vp->v_type == VDIR) X + vdir++; X + if (vp->v_object != NULL) X + vobj++; X + if (vp->v_usecount != 0) X + vinuse++; X + else if (!reclaim_nc_src && !LIST_EMPTY(&vp->v_cache_src)) X + vcache++; X + else if ((vp->v_iflag & VI_FREE) != 0) X + vfree++; X + else if ((vp->v_iflag & VI_DOOMED) != 0) X + vdoom++; X + else if (vp->v_object != NULL && X + vp->v_object->resident_page_count > trigger) X + vbig++; X +out: Lots of debugging code. X if (vp->v_usecount || X - (!vlru_allow_cache_src && X - !LIST_EMPTY(&(vp)->v_cache_src)) || X + (!reclaim_nc_src && !LIST_EMPTY(&vp->v_cache_src)) || X + ((vp->v_iflag & VI_FREE) != 0) || X (vp->v_iflag & VI_DOOMED) != 0 || (vp->v_object != NULL && X - vp->v_object->resident_page_count > trigger)) { X + vp->v_object->resident_page_count > trigger) || X + vdry) { X VI_UNLOCK(vp); X goto next_iter; The only other changes in this function are: - vlru_allow_cache_src is now a parameter (usually 0, and its sysctl is no longer supported) - never reclaim free vnodes. X @@ -810,8 +872,9 @@ X */ X if (vp->v_usecount || X - (!vlru_allow_cache_src && X - !LIST_EMPTY(&(vp)->v_cache_src)) || X + (!reclaim_nc_src && !LIST_EMPTY(&vp->v_cache_src)) || X + (vp->v_iflag & VI_FREE) != 0 || X (vp->v_object != NULL && X vp->v_object->resident_page_count > trigger)) { X + vskip++; X VOP_UNLOCK(vp, LK_INTERLOCK); X vdrop(vp); X @@ -844,5 +907,5 @@ X X /* X - * Attempt to keep the free list at wantfreevnodes length. X + * Attempt to reduce the free list by the requested amount. X */ X static void X @@ -901,4 +964,22 @@ X } X } X + X +/* XXX some names and initialization are bad for limits and watermarks. */ X +static int X +vspace(void) X +{ X + int space; X + X + gapvnodes = imax(desiredvnodes - wantfreevnodes, 100); X + vhiwat = gapvnodes / 11; /* 9% -- just under the 10% in vlrureclaim() */ X + vlowat = vhiwat / 2; X + if (numvnodes > desiredvnodes) X + return (0); X + space = desiredvnodes - numvnodes; X + if (freevnodes > wantfreevnodes) X + space += freevnodes - wantfreevnodes; X + return (space); X +} X + The easily reclaimable space is: - too many vnodes -- no space - between numvnodes and desiredvnodes -- create a new vnode - just enough vnodes and plenty of free ones -- reclaim a free one - else no space. X /* X * Attempt to recycle vnodes in a context that is always safe to block. X @@ -913,16 +994,35 @@ X { X struct mount *mp, *nmp; X - int done; X struct proc *p = vnlruproc; X + unsigned long ofreevnodes, onumvnodes; X + int done, force, reclaim_nc_src, trigger, usevnodes; Start fixing bogus unsigned/long types. int counters never worked with vnode counts that actually needed to be unsigned/long. The type of desiredvnodes was always correct (int). X X EVENTHANDLER_REGISTER(shutdown_pre_sync, kproc_shutdown, p, X SHUTDOWN_PRI_FIRST); X X + force = 0; X for (;;) { X kproc_suspend_check(p); X mtx_lock(&vnode_free_list_mtx); X - if (freevnodes > wantfreevnodes) X - vnlru_free(freevnodes - wantfreevnodes); X - if (numvnodes <= desiredvnodes * 9 / 10) { X + /* X + * If numvnodes is too large (due to desiredvnodes being X + * adjusted using its sysctl, or emergency growth), first X + * try to reduce it by discarding from the free list. X + */ X + if (numvnodes > desiredvnodes && freevnodes > 0) X + vnlru_free(ulmin(numvnodes - desiredvnodes, X + freevnodes)); X + /* X + * Sleep if the vnode cache is in a good state. This is X + * when it is not over-full and has space for about a 4% X + * or 9% expansion (by growing its size or inexcessively X + * reducing its free list). Otherwise, try to reclaim X + * space for a 10% expansion. X + */ X + if (vstir && force == 0) { X + force = 1; X + vstir = 0; X + } X + if (vspace() >= vlowat && force == 0 && vdry == 0) { X vnlruproc_sig = 0; X wakeup(&vnlruproc_sig); Hopefully the comments are verbose enough to explain this. It is standard watermark stuff, done non-magically. X @@ -933,4 +1033,40 @@ X mtx_unlock(&vnode_free_list_mtx); X done = 0; X + vexamined = 0; X + vdir = 0; X + vobj = 0; X + vinuse = 0; X + vcache = 0; X + vfree = 0; X + vdoom = 0; X + vbig = 0; X + vskip = 0; X + ofreevnodes = freevnodes; X + onumvnodes = numvnodes; Debugging. X + /* X + * Calculate parameters for recycling. These are the same X + * throughout the loop to give some semblance of fairness. X + * The trigger point is to avoid recycling vnodes with lots X + * of resident pages. We aren't trying to free memory; we X + * are trying to recycle or at least free vnodes. X + */ X + if (numvnodes <= desiredvnodes) X + usevnodes = numvnodes - freevnodes; X + else X + usevnodes = numvnodes; X + if (usevnodes <= 0) X + usevnodes = 1; X + /* X + * The trigger value is is chosen to give a conservatively X + * large value to ensure that it alone doesn't prevent X + * making progress. The value can easily be so large that X + * it is effectively infinite in some congested and X + * misconfigured cases, and this is necessary. Normally X + * it is about 8 to 100 (pages), which is quite large. X + */ X + trigger = vm_cnt.v_page_count * 2 / usevnodes; X + if (force < 2 && (vdry & 4) == 0) X + trigger = vsmalltrigger; In the old version, the same basic formula for 'trigger' ends up being a fancy spelling of between 8 and 32 (pages) with the default desiredvnodes. This is because the default desiredvnodes is v_page count scaled by by between 1/4 and 1/16. The formula here inverts this and multiplies by 2. 8 4K pages was about right, but rarely happens now that memory sizes are larger. This 8 is hard-coded in the default for vsmalltrigger. The old scaling makes some sense. If all vnodes were used and had 'trigger' pages, then they would have twice as many pages as possible. So the limit prevents more than half of the vnode cache being clogged up with vnodes too big to be reclaimed. But this barely works even in configurations close to the default. 1/4 of vnodes are now normally free, and reclaiming now starts at 9/10 full instead of full. So where the safety margin was about 1/2, it is now 1/2 - 1/4 - 1/10 = 3/20. My change fixes the scaling so that it gives 1/2 again. Configurations not close to the default were more broken. Suppose desiredvnodes is 100000 and someone changes it to 1000. This explodes 'trigger' by a factor of 1000. And this huge factor is needed to ensure that complete clogging by large vnodes is not possible. Workarounds desribed below. X + reclaim_nc_src = (force >= 3 || (vdry != 0 && (vdry & 8) == 0)); X mtx_lock(&mountlist_mtx); X for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) { X @@ -939,11 +1075,33 @@ X continue; X } X - done += vlrureclaim(mp); X + done += vlrureclaim(mp, reclaim_nc_src, trigger); X mtx_lock(&mountlist_mtx); X nmp = TAILQ_NEXT(mp, mnt_list); X vfs_unbusy(mp); X } X + DPRINTF("targ %d done %d num %lu -> %lu free %lu -> %lu %s\n", X + gapvnodes / 10, done, X + onumvnodes, numvnodes, ofreevnodes, freevnodes, X + vspace() >= vhiwat ? "complete" : X + done != 0 ? "incomplete" : "fail"); X + DPRINTF( X + "exam %d dir %d obj %d inuse %d cache %d free %d doom %d big %d skip %d\n", X + vexamined, vdir, vobj, vinuse, vcache, vfree, vdoom, vbig, X + vskip); Debugging. X mtx_unlock(&mountlist_mtx); X - if (done == 0) { X + if (onumvnodes > desiredvnodes && numvnodes <= desiredvnodes) X + uma_reclaim(); This hack works well for reclaiming from uma after reducing desiredvnodes. X + if (done == 0 && vdry == 0) { X + if (force == 0 || force == 1) { X + force = 2; X + printf("vnlru forcing trigger\n"); X + continue; X + } X + if (force == 2) { X + force = 3; X + printf("vnlru forcing namecache src\n"); X + continue; X + } X + force = 0; This makes several passes: only use the big calculated value for trigger in emergency. Similarly, force reclaiming of all cache_src cloggage in emergency. There should be another pass with an infinite trigger. X #if 0 X /* These messages are temporary debugging aids */ X @@ -953,8 +1111,17 @@ X printf("vnlru process messages stopped.\n"); X #endif X + printf("vnlru process getting nowhere\n"); This is supposed to be unreachable unless usecount > 0 for all vnodes. Set desiredvnodes to 1 to see this. BTW, setting desiredvnodes to 0 used to be robust (one of the imax's above is to convert this 0 to 1), but now it panics in namecache reinitialization. X vnlru_nowhere++; X tsleep(vnlruproc, PPAUSE, "vlrup", hz * 3); X } else X kern_yield(PRI_USER); X + /* X + * After becoming active to expand above low water, keep X + * active until above high water. X + */ X + force = (vspace() < vhiwat && vdry == 0 ? 1 : 0); X + if (force != 0) X + printf("vnlru process retrying\n"); X + vdry = 0; force = 1 is a normal retry case (when we grew the space a little but not enough). In weird configurations/loads, it is possible to grow by a lot in tiny steps, with each pass scanning hundreds of thousands of vnodes. The defaults are supposed to limits the number of steps to 2. X } X } X @@ -1030,6 +1197,16 @@ X } X X +static void X +vcheckspace(void) X +{ X + X + if (vspace() < vlowat && vnlruproc_sig == 0) { X + vnlruproc_sig = 1; X + wakeup(vnlruproc); X + } X +} X + X /* X - * Wait for available vnodes. X + * Wait if necessary for space for a new vnode. X */ X static int X @@ -1038,12 +1215,11 @@ X X mtx_assert(&vnode_free_list_mtx, MA_OWNED); X - if (numvnodes > desiredvnodes) { X + if (numvnodes >= desiredvnodes) { This is getnewvnode_wait(). The changes in it are mostly to fix the watermark. Actually waiting is rare before and after. The 9/10 watermark elsewhere was not as broken as the 10/10 watermark here. The comparison in the above was not exacly an off-by-1 error. It allows numvnodes to grow 1 too large, but the algorithm depended on this. X if (suspended) { X /* X - * File system is beeing suspended, we cannot risk a X - * deadlock here, so allocate new vnode anyway. X + * The file system is being suspended. We cannot X + * risk a deadlock here, so allow allocation of X + * another vnode even if this would give too many. X */ X - if (freevnodes > wantfreevnodes) X - vnlru_free(freevnodes - wantfreevnodes); Freeing like this (but more correct) is now done in callers. X return (0); X } X @@ -1052,10 +1228,18 @@ X wakeup(vnlruproc); X } X + DPRINTF("getnewvnode_wait() actually failed\n"); X msleep(&vnlruproc_sig, &vnode_free_list_mtx, PVFS, X "vlruwk", hz); X } X - return (numvnodes > desiredvnodes ? ENFILE : 0); X + /* Post-adjust like the pre-adjust in getnewvnode(). */ X + if (numvnodes + 1 > desiredvnodes && freevnodes > 1) X + vnlru_free(1); X + return (numvnodes >= desiredvnodes ? ENFILE : 0); This freeing should be in callers too. I put it here to try to keep getnewvnode_reserve() working without changing it more. The whole function is only needed to handle messes from the existence of getnewvnode_reserve(). X } X X +/* X + * This hack is fragile, and probably not needed any more now that the X + * watermark handling works. X + */ X void X getnewvnode_reserve(u_int count) Please delete this bad API. It seems to be only used by zfs, and I didn't test its fixes. X @@ -1063,8 +1247,17 @@ X struct thread *td; X X + /* Pre-adjust like the pre-adjust in getnewvnode(), with any count. */ X + /* XXX no longer so quick, but this part is not racy. */ X + mtx_lock(&vnode_free_list_mtx); X + if (numvnodes + count > desiredvnodes && freevnodes > wantfreevnodes) X + vnlru_free(ulmin(numvnodes + count - desiredvnodes, X + freevnodes - wantfreevnodes)); X + mtx_unlock(&vnode_free_list_mtx); X + X td = curthread; X /* First try to be quick and racy. */ X if (atomic_fetchadd_long(&numvnodes, count) + count <= desiredvnodes) { X td->td_vp_reserv += count; X + vcheckspace(); /* XXX no longer so quick, but more racy */ X return; X } else X @@ -1079,7 +1272,16 @@ X } X } X + vcheckspace(); X mtx_unlock(&vnode_free_list_mtx); X } X X +/* X + * This hack is fragile, especially if desiredvnodes or wantvnodes are X + * misconfgured or changed significantly. Reducing desiredvnodes below X + * the reserved amount should cause bizarre behaviour like reducing it X + * below the number of active vnodes -- the system will try to reduce X + * numvnodes to match, but should fail, so the subtraction below should X + * not overflow. X + */ X void X getnewvnode_drop_reserve(void) X @@ -1102,4 +1304,5 @@ X struct bufobj *bo; X struct thread *td; X + static int cyclecount; X int error; X X @@ -1112,17 +1315,35 @@ X } X mtx_lock(&vnode_free_list_mtx); X - /* X - * Lend our context to reclaim vnodes if they've exceeded the max. X - */ X - if (freevnodes > wantfreevnodes) X + if (numvnodes < desiredvnodes) X + cyclecount = 0; X + else if (cyclecount++ >= freevnodes) { X + cyclecount = 0; X + vstir = 1; X + } This uncommented stirring is a hack to try to grow the free list when it is cycling. I tried many ways to do this and only this one even sort of works. It can happen that the vnodes looked at by a large tree walk can easily fit in the cache, but they don't since old garbage is preferred. After one iteration, the cache state might end up as: - 32% free (at high watermark), all from the tree walk - 10% non-free for directories from the tree walk - 58% non-free (the rest) unrelated to the tree walk and uncached state might end up as - 1% of the cache size for non-directories from the tree walk Then repeating the walk any number of times will thrash the 32% free part in preference to growing it by 1% to hold the uncached part. The hack detects this cycling and discards from the non-free list to make space that the free-list can grow into (if there is no other load). -current does stirring with similar effects (but more bad ones) by discarding from the whole cache every second if it grows larger than 9/10 of what it should grow to. This trashes more than it stirs. It doesn't guarantee growth of the free list since it trashes the free list too, perhaps more than it can grow back. But any sort of stirring gives the cache a chance of coming out of a bad stable state. Random trashing of the clogged part might be a good way of stirring it. X + /* X + * Grow the vnode cache if it will not be above its target max X + * after growing. Otherwise, if the free list is nonempty, try X + * to reclaim 1 item from it before growing the cache (possibly X + * above its target max if the reclamation failed or is delayed). X + * Otherwise, wait for some space. In all cases, schedule X + * vnlru_proc() if we are getting short of space. The watermarks X + * should be chosen so that we never wait or even reclaim from X + * the free list to below its target minimum. X + */ X + if (numvnodes + 1 <= desiredvnodes) X + ; X + else if (freevnodes > 0) X vnlru_free(1); X - error = getnewvnode_wait(mp != NULL && (mp->mnt_kern_flag & X - MNTK_SUSPEND)); X + else { X + error = getnewvnode_wait(mp != NULL && (mp->mnt_kern_flag & X + MNTK_SUSPEND)); X #if 0 /* XXX Not all VFS_VGET/ffs_vget callers check returns. */ X - if (error != 0) { X - mtx_unlock(&vnode_free_list_mtx); X - return (error); X - } X + if (error != 0) { X + mtx_unlock(&vnode_free_list_mtx); X + return (error); X + } X #endif X + } X + vcheckspace(); X atomic_add_long(&numvnodes, 1); X mtx_unlock(&vnode_free_list_mtx); Fiarly standard watermark stuff. We are now happy to let the free list grow below or above its "wanted" size, but expect it to remain beteen the watermarks which are slightly higher. Large tree walks should cause the free list to grow much larger by discarding old non-free garbage, but that rarely happens. X @@ -2524,4 +2745,5 @@ X mp->mnt_activevnodelistsize--; X } X + /* XXX V*AGE hasn't been set since 1997. */ X if (vp->v_iflag & VI_AGE) { X TAILQ_INSERT_HEAD(&vnode_free_list, vp, Please remove VI_AGE. I think it was nonexistent before FreeBSD-3 and never set after FreeBSD-3. Bruce From owner-freebsd-fs@freebsd.org Sun Nov 15 22:41:38 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E6FAA3066B for ; Sun, 15 Nov 2015 22:41:38 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 70FD01F42; Sun, 15 Nov 2015 22:41:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:KPiIghfmv6TlGRGskoivDMudlGMj4u6mDksu8pMizoh2WeGdxc69ZB7h7PlgxGXEQZ/co6odzbGG7ua9ByQp2tWojjMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3DwdpPOO9QteU1JTqkb3ss7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjN92Mq+mwPOQCG0yjMyaS1CnABFDgLe4FT0Rb//qCb3vPFxni6AMpulY6ozXGGY7qxoADrhgyQDOjtxpHvSg8dziK9eiA+mqAFyx5bUJoqcYqktNpjBdM8XEDISFv1aUDZMV8blN9MC X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2B6AgCBB0lW/61jaINWCIUDvkoOgWSDPYJTAoFbFAEBAQEBAQEBgQmCLYIOGgEIBFISATEFFAIEVQIEiEGoS49wAQEBAQEBAQMBAQEBAQEBAQEBAQ8JhlSGUIJjAQwWGRYcDAGCRYFEBYdBhVp2PId7glOFO4Z0hECHNYc/hzQCHwFDghABHYF0IIQ2CBcjgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,299,1444708800"; d="scan'208";a="252009076" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 15 Nov 2015 17:41:28 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 9E1E115F55D; Sun, 15 Nov 2015 17:41:28 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id y8MEEdx1mRmz; Sun, 15 Nov 2015 17:41:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id D28EC15F565; Sun, 15 Nov 2015 17:41:25 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JfjhI3lShTjr; Sun, 15 Nov 2015 17:41:25 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 9CF8515F55D; Sun, 15 Nov 2015 17:41:25 -0500 (EST) Date: Sun, 15 Nov 2015 17:41:25 -0500 (EST) From: Rick Macklem To: FreeBSD FS Cc: Josh Paetzel Message-ID: <615448118.87814648.1447627285484.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <955813846.87814328.1447627236926.JavaMail.zimbra@uoguelph.ca> Subject: adding "-manage-gids" option to the NFS server MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_87814644_309663547.1447627285467" X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: adding "-manage-gids" option to the NFS server Thread-Index: gfIPWAhd/O/Pyk/9Ea3zFo42cpGmOw== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 22:41:38 -0000 ------=_Part_87814644_309663547.1447627285467 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, The attached 3 patches add the "-manage-gids" option to the NFS server. When enabled, for AUTH_SYS RPC requests, the server will use the list of groups that are assigned to the uid on the server instead of the list of gids in the RPC request. This can be used to avoid the limit of 16 groups in the RPC header. It does require that the NFS server be configured with the same passwd and group databases as the NFS client(s). It uses getgrouplist(3) on the server to get the group list, so that must work correctly on the server. It uses the same cache as the name<->id cache used for NFSv4. As such, the option is on the nfsuserd command line and it must be running for this to work for NFSv3 and/or NFSv4. Josh Paetzel already asked if this option was reasonable and got a positive response. Please review and/or test these patches, rick ps: I tried to put them in reviews.freebsd.org, but failed miserably, so I've attached them here. ------=_Part_87814644_309663547.1447627285467 Content-Type: text/x-patch; name=mapgrp-rc.patch Content-Disposition: attachment; filename=mapgrp-rc.patch Content-Transfer-Encoding: base64 LS0tIGV0Yy9yYy5kL25mc2Qub3JpZwkyMDE1LTExLTE1IDE3OjM4OjExLjMxNjU2NDAwMCAtMDUw MAorKysgZXRjL3JjLmQvbmZzZAkyMDE1LTExLTE1IDE3OjQyOjA5LjcyMTk5MTAwMCAtMDUwMApA QCAtMzIsMTAgKzMyLDEzIEBAIG5mc2RfcHJlY21kKCkKIAkJc3lzY3RsIHZmcy5uZnNkLm5mc19w cml2cG9ydD0wID4gL2Rldi9udWxsCiAJZmkKIAotCWlmIGNoZWNreWVzbm8gbmZzdjRfc2VydmVy X2VuYWJsZTsgdGhlbgorCWlmIGNoZWNreWVzbm8gbmZzdjRfc2VydmVyX2VuYWJsZSB8fCBcCisJ ICAgIGNoZWNreWVzbm8gbmZzX3NlcnZlcl9tYW5hZ2VnaWRzOyB0aGVuCiAJCXN5c2N0bCB2ZnMu bmZzZC5zZXJ2ZXJfbWF4X25mc3ZlcnM9NCA+IC9kZXYvbnVsbAogCQlmb3JjZV9kZXBlbmQgbmZz dXNlcmQgfHwgZXJyIDEgIkNhbm5vdCBydW4gbmZzdXNlcmQiCi0JZWxzZQorCWZpCisKKwlpZiAh IGNoZWNreWVzbm8gbmZzdjRfc2VydmVyX2VuYWJsZTsgdGhlbgogCQllY2hvICdORlN2NCBpcyBk aXNhYmxlZCcKIAkJc3lzY3RsIHZmcy5uZnNkLnNlcnZlcl9tYXhfbmZzdmVycz0zID4gL2Rldi9u dWxsCiAJZmkKLS0tIGV0Yy9yYy5kL25mc3VzZXJkLm9yaWcJMjAxNS0xMS0xNSAxNzozODoxMS4z MTgxNzgwMDAgLTA1MDAKKysrIGV0Yy9yYy5kL25mc3VzZXJkCTIwMTUtMTEtMTUgMTc6Mzk6MDMu NTY5NTU1MDAwIC0wNTAwCkBAIC0xNSw1ICsxNSwxNCBAQCBjb21tYW5kPSIvdXNyL3NiaW4vJHtu YW1lfSIKIHNpZ19zdG9wPSJVU1IxIgogCiBsb2FkX3JjX2NvbmZpZyAkbmFtZQorc3RhcnRfcHJl Y21kPSJuZnN1c2VyZF9wcmVjbWQiCisKK25mc3VzZXJkX3ByZWNtZCgpCit7CisJaWYgY2hlY2t5 ZXNubyBuZnNfc2VydmVyX21hbmFnZWdpZHM7IHRoZW4KKwkJcmNfZmxhZ3M9Ii1tYW5hZ2UtZ2lk cyAke25mc3VzZXJkX2ZsYWdzfSIKKwlmaQorCXJldHVybiAwCit9CiAKIHJ1bl9yY19jb21tYW5k ICIkMSIKLS0tIGV0Yy9kZWZhdWx0cy9yYy5jb25mLm9yaWcJMjAxNS0xMS0xNSAxNzozODozMC42 NTMzNjQwMDAgLTA1MDAKKysrIGV0Yy9kZWZhdWx0cy9yYy5jb25mCTIwMTUtMTEtMTUgMTc6NDM6 NDUuNDgwMjE0MDAwIC0wNTAwCkBAIC0zMjUsNiArMzI1LDcgQEAgbmZzX2NsaWVudF9lbmFibGU9 Ik5PIgkJIyBUaGlzIGhvc3QgaXMgYQogbmZzX2FjY2Vzc19jYWNoZT0iNjAiCQkjIENsaWVudCBj YWNoZSB0aW1lb3V0IGluIHNlY29uZHMKIG5mc19zZXJ2ZXJfZW5hYmxlPSJOTyIJCSMgVGhpcyBo b3N0IGlzIGFuIE5GUyBzZXJ2ZXIgKG9yIE5PKS4KIG5mc19zZXJ2ZXJfZmxhZ3M9Ii11IC10Igkj IEZsYWdzIHRvIG5mc2QgKGlmIGVuYWJsZWQpLgorbmZzX3NlcnZlcl9tYW5hZ2VnaWRzPSJOTyIJ IyBUaGUgTkZTIHNlcnZlciBtYXBzIGdpZHMgZm9yIEFVVEhfU1lTIChvciBOTykuCiBtb3VudGRf ZW5hYmxlPSJOTyIJCSMgUnVuIG1vdW50ZCAob3IgTk8pLgogbW91bnRkX2ZsYWdzPSItciIJCSMg RmxhZ3MgdG8gbW91bnRkIChpZiBORlMgc2VydmVyIGVuYWJsZWQpLgogd2Vha19tb3VudGRfYXV0 aGVudGljYXRpb249Ik5PIgkjIEFsbG93IG5vbi1yb290IG1vdW50IHJlcXVlc3RzIHRvIGJlIHNl cnZlZC4K ------=_Part_87814644_309663547.1447627285467 Content-Type: text/x-patch; name=mapgrp-nfsuserd.patch Content-Disposition: attachment; filename=mapgrp-nfsuserd.patch Content-Transfer-Encoding: base64 LS0tIHVzci5zYmluL25mc3VzZXJkL25mc3VzZXJkLmMub3JpZwkyMDE1LTExLTEzIDIwOjM5OjEz LjY4OTU3NDAwMCAtMDUwMAorKysgdXNyLnNiaW4vbmZzdXNlcmQvbmZzdXNlcmQuYwkyMDE1LTEx LTEzIDIwOjQwOjM2LjUzMDg3NTAwMCAtMDUwMApAQCAtOTIsNyArOTIsNyBAQCB1aWRfdCBkZWZh dWx0dWlkID0gKHVpZF90KTMyNzY3OwogdV9jaGFyICpkZWZhdWx0Z3JvdXAgPSAibm9ncm91cCI7 CiBnaWRfdCBkZWZhdWx0Z2lkID0gKGdpZF90KTMyNzY3OwogaW50IHZlcmJvc2UgPSAwLCBpbV9h X3NsYXZlID0gMCwgbmZzdXNlcmRjbnQgPSAtMSwgZm9yY2VzdGFydCA9IDA7Ci1pbnQgZGVmdXNl cnRpbWVvdXQgPSBERUZVU0VSVElNRU9VVDsKK2ludCBkZWZ1c2VydGltZW91dCA9IERFRlVTRVJU SU1FT1VULCBtYW5hZ2VfZ2lkcyA9IDA7CiBwaWRfdCBzbGF2ZXNbTUFYTkZTVVNFUkRdOwogCiBp bnQKQEAgLTExMCw2ICsxMTAsOCBAQCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pCiAJY2hh ciBob3N0bmFtZVtNQVhIT1NUTkFNRUxFTiArIDFdLCAqY3A7CiAJc3RydWN0IGFkZHJpbmZvICph aXAsIGhpbnRzOwogCXN0YXRpYyB1aWRfdCBjaGVja19kdXBzW01BWFVTRVJNQVhdOworCWdpZF90 IGdycHNbTkdST1VQU107CisJaW50IG5ncm91cDsKIAogCWlmIChtb2RmaW5kKCJuZnNjb21tb24i KSA8IDApIHsKIAkJLyogTm90IHByZXNlbnQgaW4ga2VybmVsLCB0cnkgbG9hZGluZyBpdCAqLwpA QCAtMTYwLDYgKzE2Miw4IEBAIG1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKIAkJCXZlcmJv c2UgPSAxOwogCQl9IGVsc2UgaWYgKCFzdHJjbXAoKmFyZ3YsICItZm9yY2UiKSkgewogCQkJZm9y Y2VzdGFydCA9IDE7CisJCX0gZWxzZSBpZiAoIXN0cmNtcCgqYXJndiwgIi1tYW5hZ2UtZ2lkcyIp KSB7CisJCQltYW5hZ2VfZ2lkcyA9IDE7CiAJCX0gZWxzZSBpZiAoIXN0cmNtcCgqYXJndiwgIi11 c2VybWF4IikpIHsKIAkJCWlmIChhcmdjID09IDEpCiAJCQkJdXNhZ2UoKTsKQEAgLTI5NywxMiAr MzAxLDE0IEBAIG1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKIAkJbmlkLm5pZF9naWQgPSBk ZWZhdWx0Z2lkOwogCW5pZC5uaWRfbmFtZSA9IGRuc25hbWU7CiAJbmlkLm5pZF9uYW1lbGVuID0g c3RybGVuKG5pZC5uaWRfbmFtZSk7CisJbmlkLm5pZF9uZ3JvdXAgPSAwOworCW5pZC5uaWRfZ3Jw cyA9IE5VTEw7CiAJbmlkLm5pZF9mbGFnID0gTkZTSURfSU5JVElBTElaRTsKICNpZmRlZiBERUJV RwogCXByaW50ZigiSW5pdGlhbGl6ZSB1aWQ9JWQgZ2lkPSVkIGRucz0lc1xuIiwgbmlkLm5pZF91 aWQsIG5pZC5uaWRfZ2lkLCAKIAkgICAgbmlkLm5pZF9uYW1lKTsKICNlbHNlCi0JZXJyb3IgPSBu ZnNzdmMoTkZTU1ZDX0lETkFNRSwgJm5pZCk7CisJZXJyb3IgPSBuZnNzdmMoTkZTU1ZDX0lETkFN RSB8IE5GU1NWQ19ORVdTVFJVQ1QsICZuaWQpOwogCWlmIChlcnJvcikKIAkJZXJyeCgxLCAiQ2Fu J3QgaW5pdGlhbGl6ZSBuZnMgdXNlci9ncm91cHMiKTsKICNlbmRpZgpAQCAtMzE2LDExICszMjIs MTMgQEAgbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltdKQogCQluaWQubmlkX2dpZCA9IGdycC0+ Z3JfZ2lkOwogCQluaWQubmlkX25hbWUgPSBncnAtPmdyX25hbWU7CiAJCW5pZC5uaWRfbmFtZWxl biA9IHN0cmxlbihncnAtPmdyX25hbWUpOworCQluaWQubmlkX25ncm91cCA9IDA7CisJCW5pZC5u aWRfZ3JwcyA9IE5VTEw7CiAJCW5pZC5uaWRfZmxhZyA9IE5GU0lEX0FEREdJRDsKICNpZmRlZiBE RUJVRwogCQlwcmludGYoImFkZCBnaWQ9JWQgbmFtZT0lc1xuIiwgbmlkLm5pZF9naWQsIG5pZC5u aWRfbmFtZSk7CiAjZWxzZQotCQllcnJvciA9IG5mc3N2YyhORlNTVkNfSUROQU1FLCAmbmlkKTsK KwkJZXJyb3IgPSBuZnNzdmMoTkZTU1ZDX0lETkFNRSB8IE5GU1NWQ19ORVdTVFJVQ1QsICZuaWQp OwogCQlpZiAoZXJyb3IpCiAJCQllcnJ4KDEsICJDYW4ndCBhZGQgZ3JvdXAgJXMiLCBncnAtPmdy X25hbWUpOwogI2VuZGlmCkBAIC0zNTIsMTEgKzM2MCwyMyBAQCBtYWluKGludCBhcmdjLCBjaGFy ICphcmd2W10pCiAJCW5pZC5uaWRfdWlkID0gcHdkLT5wd191aWQ7CiAJCW5pZC5uaWRfbmFtZSA9 IHB3ZC0+cHdfbmFtZTsKIAkJbmlkLm5pZF9uYW1lbGVuID0gc3RybGVuKHB3ZC0+cHdfbmFtZSk7 CisJCWlmIChtYW5hZ2VfZ2lkcyAhPSAwKSB7CisJCQkvKiBHZXQgdGhlIGdyb3VwIGxpc3QgZm9y IHRoaXMgdXNlci4gKi8KKwkJCW5ncm91cCA9IE5HUk9VUFM7CisJCQlpZiAoZ2V0Z3JvdXBsaXN0 KHB3ZC0+cHdfbmFtZSwgcHdkLT5wd19naWQsIGdycHMsCisJCQkgICAgJm5ncm91cCkgPCAwKQor CQkJCXN5c2xvZyhMT0dfRVJSLCAiR3JvdXAgbGlzdCB0b28gc21hbGwiKTsKKwkJCW5pZC5uaWRf bmdyb3VwID0gbmdyb3VwOworCQkJbmlkLm5pZF9ncnBzID0gZ3JwczsKKwkJfSBlbHNlIHsKKwkJ CW5pZC5uaWRfbmdyb3VwID0gMDsKKwkJCW5pZC5uaWRfZ3JwcyA9IE5VTEw7CisJCX0KIAkJbmlk Lm5pZF9mbGFnID0gTkZTSURfQUREVUlEOwogI2lmZGVmIERFQlVHCiAJCXByaW50ZigiYWRkIHVp ZD0lZCBuYW1lPSVzXG4iLCBuaWQubmlkX3VpZCwgbmlkLm5pZF9uYW1lKTsKICNlbHNlCi0JCWVy cm9yID0gbmZzc3ZjKE5GU1NWQ19JRE5BTUUsICZuaWQpOworCQllcnJvciA9IG5mc3N2YyhORlNT VkNfSUROQU1FIHwgTkZTU1ZDX05FV1NUUlVDVCwgJm5pZCk7CiAJCWlmIChlcnJvcikKIAkJCWVy cngoMSwgIkNhbid0IGFkZCB1c2VyICVzIiwgcHdkLT5wd19uYW1lKTsKICNlbmRpZgpAQCAtNDM5 LDYgKzQ1OSw4IEBAIG5mc3VzZXJkc3J2KHN0cnVjdCBzdmNfcmVxICpycXN0cCwgU1ZDWFAKIAlz dHJ1Y3QgaW5mbyBpbmZvOwogCXN0cnVjdCBuZnNkX2lkYXJncyBuaWQ7CiAJdV9pbnQzMl90IHNh ZGRyOworCWdpZF90IGdycHNbTkdST1VQU107CisJaW50IG5ncm91cDsKIAogCS8qCiAJICogT25s eSBoYW5kbGUgcmVxdWVzdHMgZnJvbSAxMjcuMC4wLjEgb24gYSByZXNlcnZlZCBwb3J0IG51bWJl ci4KQEAgLTQ3MiwxNCArNDk0LDI4IEBAIG5mc3VzZXJkc3J2KHN0cnVjdCBzdmNfcmVxICpycXN0 cCwgU1ZDWFAKIAkJCW5pZC5uaWRfdXNlcnRpbWVvdXQgPSBkZWZ1c2VydGltZW91dDsKIAkJCW5p ZC5uaWRfdWlkID0gcHdkLT5wd191aWQ7CiAJCQluaWQubmlkX25hbWUgPSBwd2QtPnB3X25hbWU7 CisJCQlpZiAobWFuYWdlX2dpZHMgIT0gMCkgeworCQkJCS8qIEdldCB0aGUgZ3JvdXAgbGlzdCBm b3IgdGhpcyB1c2VyLiAqLworCQkJCW5ncm91cCA9IE5HUk9VUFM7CisJCQkJaWYgKGdldGdyb3Vw bGlzdChwd2QtPnB3X25hbWUsIHB3ZC0+cHdfZ2lkLAorCQkJCSAgICBncnBzLCAmbmdyb3VwKSA8 IDApCisJCQkJCXN5c2xvZyhMT0dfRVJSLCAiR3JvdXAgbGlzdCB0b28gc21hbGwiKTsKKwkJCQlu aWQubmlkX25ncm91cCA9IG5ncm91cDsKKwkJCQluaWQubmlkX2dycHMgPSBncnBzOworCQkJfSBl bHNlIHsKKwkJCQluaWQubmlkX25ncm91cCA9IDA7CisJCQkJbmlkLm5pZF9ncnBzID0gTlVMTDsK KwkJCX0KIAkJfSBlbHNlIHsKIAkJCW5pZC5uaWRfdXNlcnRpbWVvdXQgPSA1OwogCQkJbmlkLm5p ZF91aWQgPSAodWlkX3QpaW5mby5pZDsKIAkJCW5pZC5uaWRfbmFtZSA9IGRlZmF1bHR1c2VyOwor CQkJbmlkLm5pZF9uZ3JvdXAgPSAwOworCQkJbmlkLm5pZF9ncnBzID0gTlVMTDsKIAkJfQogCQlu aWQubmlkX25hbWVsZW4gPSBzdHJsZW4obmlkLm5pZF9uYW1lKTsKIAkJbmlkLm5pZF9mbGFnID0g TkZTSURfQUREVUlEOwotCQllcnJvciA9IG5mc3N2YyhORlNTVkNfSUROQU1FLCAmbmlkKTsKKwkJ ZXJyb3IgPSBuZnNzdmMoTkZTU1ZDX0lETkFNRSB8IE5GU1NWQ19ORVdTVFJVQ1QsICZuaWQpOwog CQlpZiAoZXJyb3IpIHsKIAkJCWluZm8ucmV0dmFsID0gZXJyb3I7CiAJCQlzeXNsb2coTE9HX0VS UiwgIkNhbid0IGFkZCB1c2VyICVzXG4iLCBwd2QtPnB3X25hbWUpOwpAQCAtNTA5LDggKzU0NSwx MCBAQCBuZnN1c2VyZHNydihzdHJ1Y3Qgc3ZjX3JlcSAqcnFzdHAsIFNWQ1hQCiAJCQluaWQubmlk X25hbWUgPSBkZWZhdWx0Z3JvdXA7CiAJCX0KIAkJbmlkLm5pZF9uYW1lbGVuID0gc3RybGVuKG5p ZC5uaWRfbmFtZSk7CisJCW5pZC5uaWRfbmdyb3VwID0gMDsKKwkJbmlkLm5pZF9ncnBzID0gTlVM TDsKIAkJbmlkLm5pZF9mbGFnID0gTkZTSURfQURER0lEOwotCQllcnJvciA9IG5mc3N2YyhORlNT VkNfSUROQU1FLCAmbmlkKTsKKwkJZXJyb3IgPSBuZnNzdmMoTkZTU1ZDX0lETkFNRSB8IE5GU1NW Q19ORVdTVFJVQ1QsICZuaWQpOwogCQlpZiAoZXJyb3IpIHsKIAkJCWluZm8ucmV0dmFsID0gZXJy b3I7CiAJCQlzeXNsb2coTE9HX0VSUiwgIkNhbid0IGFkZCBncm91cCAlc1xuIiwKQEAgLTU0MSw4 ICs1NzksMTAgQEAgbmZzdXNlcmRzcnYoc3RydWN0IHN2Y19yZXEgKnJxc3RwLCBTVkNYUAogCQkJ bmlkLm5pZF9uYW1lID0gaW5mby5uYW1lOwogCQl9CiAJCW5pZC5uaWRfbmFtZWxlbiA9IHN0cmxl bihuaWQubmlkX25hbWUpOworCQluaWQubmlkX25ncm91cCA9IDA7CisJCW5pZC5uaWRfZ3JwcyA9 IE5VTEw7CiAJCW5pZC5uaWRfZmxhZyA9IE5GU0lEX0FERFVTRVJOQU1FOwotCQllcnJvciA9IG5m c3N2YyhORlNTVkNfSUROQU1FLCAmbmlkKTsKKwkJZXJyb3IgPSBuZnNzdmMoTkZTU1ZDX0lETkFN RSB8IE5GU1NWQ19ORVdTVFJVQ1QsICZuaWQpOwogCQlpZiAoZXJyb3IpIHsKIAkJCWluZm8ucmV0 dmFsID0gZXJyb3I7CiAJCQlzeXNsb2coTE9HX0VSUiwgIkNhbid0IGFkZCB1c2VyICVzXG4iLCBw d2QtPnB3X25hbWUpOwpAQCAtNTcyLDggKzYxMiwxMCBAQCBuZnN1c2VyZHNydihzdHJ1Y3Qgc3Zj X3JlcSAqcnFzdHAsIFNWQ1hQCiAJCQluaWQubmlkX25hbWUgPSBpbmZvLm5hbWU7CiAJCX0KIAkJ bmlkLm5pZF9uYW1lbGVuID0gc3RybGVuKG5pZC5uaWRfbmFtZSk7CisJCW5pZC5uaWRfbmdyb3Vw ID0gMDsKKwkJbmlkLm5pZF9ncnBzID0gTlVMTDsKIAkJbmlkLm5pZF9mbGFnID0gTkZTSURfQURE R1JPVVBOQU1FOwotCQllcnJvciA9IG5mc3N2YyhORlNTVkNfSUROQU1FLCAmbmlkKTsKKwkJZXJy b3IgPSBuZnNzdmMoTkZTU1ZDX0lETkFNRSB8IE5GU1NWQ19ORVdTVFJVQ1QsICZuaWQpOwogCQlp ZiAoZXJyb3IpIHsKIAkJCWluZm8ucmV0dmFsID0gZXJyb3I7CiAJCQlzeXNsb2coTE9HX0VSUiwg IkNhbid0IGFkZCBncm91cCAlc1xuIiwKQEAgLTY3OSw1ICs3MjEsNSBAQCB1c2FnZSh2b2lkKQog ewogCiAJZXJyeCgxLAotCSAgICAidXNhZ2U6IG5mc3VzZXJkIFstdXNlcm1heCBjYWNoZV9zaXpl XSBbLXVzZXJ0aW1lb3V0IG1pbnV0ZXNdIFstdmVyYm9zZV0gWy1kb21haW4gZG9tYWluX25hbWVd IFtuXSIpOworCSAgICAidXNhZ2U6IG5mc3VzZXJkIFstdXNlcm1heCBjYWNoZV9zaXplXSBbLXVz ZXJ0aW1lb3V0IG1pbnV0ZXNdIFstdmVyYm9zZV0gWy1tYW5hZ2UtZ2lkc10gWy1kb21haW4gZG9t YWluX25hbWVdIFtuXSIpOwogfQotLS0gdXNyLnNiaW4vbmZzdXNlcmQvbmZzdXNlcmQuOC5vcmln CTIwMTUtMTEtMTMgMjA6Mzk6MTIuNDAzOTUwMDAwIC0wNTAwCisrKyB1c3Iuc2Jpbi9uZnN1c2Vy ZC9uZnN1c2VyZC44CTIwMTUtMTEtMTMgMjA6NDI6MDYuNzAyNTM5MDAwIC0wNTAwCkBAIC0yNCwx NCArMjQsMTQgQEAKIC5cIgogLlwiICRGcmVlQlNEOiBoZWFkL3Vzci5zYmluL25mc3VzZXJkL25m c3VzZXJkLjggMjc2MjU4IDIwMTQtMTItMjYgMjE6NTY6MjNaIGpvZWwgJAogLlwiCi0uRGQgQXBy aWwgMjUsIDIwMDkKKy5EZCBOb3ZlbWJlciAxLCAyMDE1CiAuRHQgTkZTVVNFUkQgOAogLk9zCiAu U2ggTkFNRQogLk5tIG5mc3VzZXJkCiAuTmQgbG9hZCB1c2VyIGFuZCBncm91cCBpbmZvcm1hdGlv biBpbnRvIHRoZSBrZXJuZWwgZm9yCiAuVG4gTkZTdjQKLXNlcnZpY2VzCitzZXJ2aWNlcyBwbHVz IHN1cHBvcnQgbWFuYWdlLWdpZHMgZm9yIGFsbCBORlMgdmVyc2lvbnMKIC5TaCBTWU5PUFNJUwog Lk5tIG5mc3VzZXJkCiAuT3AgRmwgZG9tYWluIEFyIGRvbWFpbl9uYW1lCkBAIC0zOSwxMSArMzks MTQgQEAgc2VydmljZXMKIC5PcCBGbCB1c2VybWF4IEFyIG1heF9jYWNoZV9zaXplCiAuT3AgRmwg dmVyYm9zZQogLk9wIEZsIGZvcmNlCisuT3AgRmwgbWFuYWdlLWdpZHMKIC5PcCBBciBudW1fc2Vy dmVycwogLlNoIERFU0NSSVBUSU9OCiAuTm0KIGxvYWRzIHVzZXIgYW5kIGdyb3VwIGluZm9ybWF0 aW9uIGludG8gdGhlIGtlcm5lbCBmb3IgTkZTdjQuCiBJdCBtdXN0IGJlIHJ1bm5pbmcgZm9yIE5G U3Y0IHRvIGZ1bmN0aW9uIGNvcnJlY3RseSwgZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIuCitJdCBh bHNvIHByb3ZpZGVzIHN1cHBvcnQgZm9yIG1hbmFnZS1naWRzIGFuZCBtdXN0IGJlIHJ1bm5pbmcg b24gdGhlIHNlcnZlciBpZgordGhpcyBpcyBiZWluZyB1c2VkIGZvciBhbnkgdmVyc2lvbiBvZiBO RlMuCiAuUHAKIFVwb24gc3RhcnR1cCwgaXQgbG9hZHMgdGhlIG1hY2hpbmVzIEROUyBkb21haW4g bmFtZSwgcGx1cyB0aW1lb3V0IGFuZAogY2FjaGUgc2l6ZSBsaW1pdCBpbnRvIHRoZSBrZXJuZWwu IEl0IHRoZW4gcHJlbG9hZHMgdGhlIGNhY2hlIHdpdGggZ3JvdXAKQEAgLTc5LDYgKzgyLDE1IEBA IFdoZW4gc2V0LCB0aGUgc2VydmVyIGxvZ3MgYSBidW5jaCBvZiBpbmYKIFRoaXMgZmxhZyBvcHRp b24gbXVzdCBiZSBzZXQgdG8gcmVzdGFydCB0aGUgZGFlbW9uIGFmdGVyIGl0IGhhcyBnb25lIGF3 YXkKIGFibm9ybWFsbHkgYW5kIHJlZnVzZXMgdG8gc3RhcnQsIGJlY2F1c2UgaXQgdGhpbmtzIG5m c3VzZXJkIGlzIGFscmVhZHkKIHJ1bm5pbmcuCisuSXQgRmwgbWFuYWdlLWdpZHMKK1RoaXMgZmxh ZyBlbmFibGVzIG1hbmFnZS1naWRzIGZvciB0aGUgTkZTIHNlcnZlcgorLlhyIG5mc2QgOCAuCitX aGVuIHRoaXMgaXMgZW5hYmxlZCwgYWxsIE5GUyByZXF1ZXN0cyB1c2luZworQVVUSF9TWVMgYXV0 aGVudGljYXRpb24gdGFrZSB0aGUgdWlkIGZyb20gdGhlIFJQQyByZXF1ZXN0CithbmQgdXNlcyB0 aGUgZ3JvdXAgbGlzdCBmb3IgdGhhdCB1aWQgcHJvdmlkZWQgYnkKKy5YciBnZXRncm91cGxpc3Qg Mworb24gdGhlIHNlcnZlciBpbnN0ZWFkIG9mIHRoZSBsaXN0IG9mIGdyb3VwcyBwcm92aWRlZCBp biB0aGUgUlBDIGF1dGhlbnRpY2F0b3IuCitUaGlzIGNhbiBiZSB1c2VkIHRvIGF2b2lkIHRoZSAx NiBncm91cCBsaW1pdCBmb3IgQVVUSF9TWVMuCiAuSXQgQXIgbnVtX3NlcnZlcnMKIFNwZWNpZmll cyBob3cgbWFueSBzZXJ2ZXJzIHRvIGNyZWF0ZSAobWF4IDIwKS4KIFRoZSBkZWZhdWx0IG9mIDQg bWF5IGJlIHN1ZmZpY2llbnQuIFlvdSBzaG91bGQgcnVuIGVub3VnaCBzZXJ2ZXJzLCBzbyB0aGF0 CkBAIC05MCw2ICsxMDIsNyBAQCBzdWNoIGFzIGEgcHJvY2VzcyB0YWJsZSBlbnRyeSBhbmQgc3dh cCBzCiAuRWwKIC5TaCBTRUUgQUxTTwogLlhyIGdldGdyZW50IDMgLAorLlhyIGdldGdyb3VwbGlz dCAzICwKIC5YciBnZXRwd2VudCAzICwKIC5YciBuZnN2NCA0ICwKIC5YciBncm91cCA1ICwKQEAg LTEwMyw3ICsxMTYsOCBAQCB1dGlsaXR5IHdhcyBpbnRyb2R1Y2VkIHdpdGggdGhlIE5GU3Y0IGV4 CiBUaGUKIC5ObQogdXNlCi0uWHIgZ2V0Z3JlbnQgMworLlhyIGdldGdyZW50IDMgLAorLlhyIGdl dGdyb3VwbGlzdCAzCiBhbmQKIC5YciBnZXRwd2VudCAzCiBsaWJyYXJ5IGNhbGxzIHRvIHJlc29s dmUgcmVxdWVzdHMgYW5kIHdpbGwgaGFuZyBpZiB0aGUgc2VydmVycyBoYW5kbGluZwo= ------=_Part_87814644_309663547.1447627285467 Content-Type: text/x-patch; name=mapgrp-kernel.patch Content-Disposition: attachment; filename=mapgrp-kernel.patch Content-Transfer-Encoding: base64 LS0tIG5mcy9uZnNzdmMuaC5zYXYJMjAxNS0wOS0yOCAxODo0ODoyNi4wMDAwMDAwMDAgLTA0MDAK KysrIG5mcy9uZnNzdmMuaAkyMDE1LTExLTEzIDE5OjM1OjM2LjY3NTYzMDAwMCAtMDUwMApAQCAt NjksNiArNjksNyBAQAogI2RlZmluZQlORlNTVkNfU1VTUEVORE5GU0QJMHgwNDAwMDAwMAogI2Rl ZmluZQlORlNTVkNfUkVTVU1FTkZTRAkweDA4MDAwMDAwCiAjZGVmaW5lCU5GU1NWQ19EVU1QTU5U T1BUUwkweDEwMDAwMDAwCisjZGVmaW5lCU5GU1NWQ19ORVdTVFJVQ1QJMHgyMDAwMDAwMAogCiAv KiBBcmd1bWVudCBzdHJ1Y3R1cmUgZm9yIE5GU1NWQ19EVU1QTU5UT1BUUy4gKi8KIHN0cnVjdCBu ZnNjbF9kdW1wbW50b3B0cyB7Ci0tLSBmcy9uZnNzZXJ2ZXIvbmZzX25mc2Rwb3J0LmMuc2F2CTIw MTUtMDktMjggMTg6NDk6MzMuMDAwMDAwMDAwIC0wNDAwCisrKyBmcy9uZnNzZXJ2ZXIvbmZzX25m c2Rwb3J0LmMJMjAxNS0xMS0xMyAxOTozNTozNi41Mjg0NTYwMDAgLTA1MDAKQEAgLTI2NDksMTQg KzI2NDksMjQgQEAgbmZzZF9leGNyZWQoc3RydWN0IG5mc3J2X2Rlc2NyaXB0ICpuZCwgcwogCSAq ICBGc2luZm8gUlBDLiBJZiBzZXQgZm9yIGFueXRoaW5nIGVsc2UsIHRoaXMgY29kZSBtaWdodCBu ZWVkCiAJICogIHRvIGNoYW5nZS4pCiAJICovCi0JaWYgKE5GU1ZOT19FWFBPUlRFRChleHApICYm Ci0JICAgICgoIShuZC0+bmRfZmxhZyAmIE5EX0dTUykgJiYgbmQtPm5kX2NyZWQtPmNyX3VpZCA9 PSAwKSB8fAotCSAgICAgTkZTVk5PX0VYUE9SVEFOT04oZXhwKSB8fAotCSAgICAgKG5kLT5uZF9m bGFnICYgTkRfQVVUSE5PTkUpKSkgewotCQluZC0+bmRfY3JlZC0+Y3JfdWlkID0gY3JlZGFub24t PmNyX3VpZDsKLQkJbmQtPm5kX2NyZWQtPmNyX2dpZCA9IGNyZWRhbm9uLT5jcl9naWQ7Ci0JCWNy c2V0Z3JvdXBzKG5kLT5uZF9jcmVkLCBjcmVkYW5vbi0+Y3Jfbmdyb3VwcywKLQkJICAgIGNyZWRh bm9uLT5jcl9ncm91cHMpOworCWlmIChORlNWTk9fRVhQT1JURUQoZXhwKSkgeworCQlpZiAoKChu ZC0+bmRfZmxhZyAmIE5EX0dTUykgPT0gMCAmJiBuZC0+bmRfY3JlZC0+Y3JfdWlkID09IDApIHx8 CisJCSAgICAgTkZTVk5PX0VYUE9SVEFOT04oZXhwKSB8fAorCQkgICAgIChuZC0+bmRfZmxhZyAm IE5EX0FVVEhOT05FKSAhPSAwKSB7CisJCQluZC0+bmRfY3JlZC0+Y3JfdWlkID0gY3JlZGFub24t PmNyX3VpZDsKKwkJCW5kLT5uZF9jcmVkLT5jcl9naWQgPSBjcmVkYW5vbi0+Y3JfZ2lkOworCQkJ Y3JzZXRncm91cHMobmQtPm5kX2NyZWQsIGNyZWRhbm9uLT5jcl9uZ3JvdXBzLAorCQkJICAgIGNy ZWRhbm9uLT5jcl9ncm91cHMpOworCQl9IGVsc2UgaWYgKChuZC0+bmRfZmxhZyAmIE5EX0dTUykg PT0gMCkgeworCQkJLyoKKwkJCSAqIElmIHVzaW5nIEFVVEhfU1lTLCBjYWxsIG5mc3J2X2dldGdy cHNjcmVkKCkgdG8gc2VlCisJCQkgKiBpZiB0aGVyZSBpcyBhIHJlcGxhY2VtZW50IGNyZWRlbnRp YWwgd2l0aCBhIGdyb3VwCisJCQkgKiBsaXN0IHNldCB1cCBieSAibmZzdXNlcmQgLW1hbmFnZS1n aWRzIi4KKwkJCSAqIElmIHRoZXJlIGlzIG5vIHJlcGxhY2VtZW50LCBuZnNydl9nZXRncnBzY3Jl ZCgpCisJCQkgKiBzaW1wbHkgcmV0dXJucyBpdHMgYXJndW1lbnQuCisJCQkgKi8KKwkJCW5kLT5u ZF9jcmVkID0gbmZzcnZfZ2V0Z3Jwc2NyZWQobmQtPm5kX2NyZWQpOworCQl9CiAJfQogCiBvdXQ6 Ci0tLSBmcy9uZnMvbmZzcnZzdGF0ZS5oLnNhdgkyMDE1LTA5LTI4IDE4OjQ5OjM1LjAwMDAwMDAw MCAtMDQwMAorKysgZnMvbmZzL25mc3J2c3RhdGUuaAkyMDE1LTExLTEzIDE5OjQ4OjU4LjcxMDE2 ODAwMCAtMDUwMApAQCAtNDgsMjMgKzQ4LDIyIEBAIExJU1RfSEVBRChuZnNzZXNzaW9uaGFzaGhl YWQsIG5mc2RzZXNzaW8KIC8qCiAgKiBMaXN0IGhlYWQgZm9yIG5mc3VzcmdycC4KICAqLwotTElT VF9IRUFEKG5mc3VzZXJoYXNoaGVhZCwgbmZzdXNyZ3JwKTsKLVRBSUxRX0hFQUQobmZzdXNlcmxy dWhlYWQsIG5mc3VzcmdycCk7CitUQUlMUV9IRUFEKG5mc3VzZXJoYXNoaGVhZCwgbmZzdXNyZ3Jw KTsKIAogI2RlZmluZQlORlNDTElFTlRIQVNIKGlkKQkJCQkJCVwKIAkoJm5mc2NsaWVudGhhc2hb KGlkKS5sdmFsWzFdICUgbmZzcnZfY2xpZW50aGFzaHNpemVdKQogI2RlZmluZQlORlNTVEFURUhB U0goY2xwLCBpZCkJCQkJCQlcCiAJKCYoKGNscCktPmxjX3N0YXRlaWRbKGlkKS5vdGhlclsyXSAl IG5mc3J2X3N0YXRlaGFzaHNpemVdKSkKICNkZWZpbmUJTkZTVVNFUkhBU0goaWQpCQkJCQkJCVwK LQkoJm5mc3VzZXJoYXNoWyhpZCkgJSBORlNVU0VSSEFTSFNJWkVdKQorCSgmbmZzdXNlcmhhc2hb KGlkKSAlIG5mc3J2X2x1Z2hhc2hzaXplXSkKICNkZWZpbmUJTkZTVVNFUk5BTUVIQVNIKHAsIGwp CQkJCQkJXAogCSgmbmZzdXNlcm5hbWVoYXNoWygobCk+PTQ/KCoocCkrKigocCkrMSkrKigocCkr MikrKigocCkrMykpOioocCkpIFwKLQkJJSBORlNVU0VSSEFTSFNJWkVdKQorCQklIG5mc3J2X2x1 Z2hhc2hzaXplXSkKICNkZWZpbmUJTkZTR1JPVVBIQVNIKGlkKQkJCQkJCVwKLQkoJm5mc2dyb3Vw aGFzaFsoaWQpICUgTkZTR1JPVVBIQVNIU0laRV0pCisJKCZuZnNncm91cGhhc2hbKGlkKSAlIG5m c3J2X2x1Z2hhc2hzaXplXSkKICNkZWZpbmUJTkZTR1JPVVBOQU1FSEFTSChwLCBsKQkJCQkJCVwK IAkoJm5mc2dyb3VwbmFtZWhhc2hbKChsKT49ND8oKihwKSsqKChwKSsxKSsqKChwKSsyKSsqKChw KSszKSk6KihwKSkgXAotCQklIE5GU0dST1VQSEFTSFNJWkVdKQorCQklIG5mc3J2X2x1Z2hhc2hz aXplXSkKIAogc3RydWN0IG5mc3Nlc3Npb25oYXNoIHsKIAlzdHJ1Y3QgbXR4CQkJbXR4OwpAQCAt MjY0LDE0ICsyNjMsMTQgQEAgc3RydWN0IG5mc2xvY2tmaWxlIHsKICAqIG5hbWVzLgogICovCiBz dHJ1Y3QgbmZzdXNyZ3JwIHsKLQlUQUlMUV9FTlRSWShuZnN1c3JncnApCWx1Z19scnU7CS8qIExS VSBsaXN0ICovCi0JTElTVF9FTlRSWShuZnN1c3JncnApCWx1Z19udW1oYXNoOwkvKiBIYXNoIGJ5 IGlkIyAqLwotCUxJU1RfRU5UUlkobmZzdXNyZ3JwKQlsdWdfbmFtZWhhc2g7CS8qIGFuZCBieSBu YW1lICovCisJVEFJTFFfRU5UUlkobmZzdXNyZ3JwKQlsdWdfbnVtaGFzaDsJLyogSGFzaCBieSBp ZCMgKi8KKwlUQUlMUV9FTlRSWShuZnN1c3JncnApCWx1Z19uYW1laGFzaDsJLyogYW5kIGJ5IG5h bWUgKi8KIAl0aW1lX3QJCQlsdWdfZXhwaXJ5OwkvKiBFeHBpcnkgdGltZSBpbiBzZWMgKi8KIAl1 bmlvbiB7CiAJCXVpZF90CQl1bl91aWQ7CQkvKiBpZCMgKi8KIAkJZ2lkX3QJCXVuX2dpZDsKIAl9 IGx1Z191bjsKKwlzdHJ1Y3QgdWNyZWQJCSpsdWdfY3JlZDsJLyogQ3JlZC4gd2l0aCBncm91cHMg bGlzdCAqLwogCWludAkJCWx1Z19uYW1lbGVuOwkvKiBOYW1lIGxlbmd0aCAqLwogCXVfY2hhcgkJ CWx1Z19uYW1lWzFdOwkvKiBtYWxsb2MnZCBjb3JyZWN0IGxlbmd0aCAqLwogfTsKLS0tIGZzL25m cy9uZnMuaC5zYXYJMjAxNS0wOS0yOCAxODo0OTozNS4wMDAwMDAwMDAgLTA0MDAKKysrIGZzL25m cy9uZnMuaAkyMDE1LTExLTEzIDE5OjUwOjMwLjA4MzE2OTAwMCAtMDUwMApAQCAtOTYsMTIgKzk2 LDYgQEAKICNkZWZpbmUJTkZTU0VTU0lPTkhBU0hTSVpFCTIwCS8qIFNpemUgb2Ygc2VydmVyIHNl c3Npb24gaGFzaCB0YWJsZSAqLwogI2VuZGlmCiAjZGVmaW5lCU5GU1NUQVRFSEFTSFNJWkUJMTAJ LyogU2l6ZSBvZiBzZXJ2ZXIgc3RhdGVpZCBoYXNoIHRhYmxlICovCi0jaWZuZGVmIE5GU1VTRVJI QVNIU0laRQotI2RlZmluZQlORlNVU0VSSEFTSFNJWkUJCTMwCS8qIFNpemUgb2YgdXNlciBpZCBo YXNoIHRhYmxlICovCi0jZW5kaWYKLSNpZm5kZWYgTkZTR1JPVVBIQVNIU0laRQotI2RlZmluZQlO RlNHUk9VUEhBU0hTSVpFCTUJLyogU2l6ZSBvZiBncm91cCBpZCBoYXNoIHRhYmxlICovCi0jZW5k aWYKICNpZm5kZWYJTkZTQ0xERUxFR0hJR0hXQVRFUgogI2RlZmluZQlORlNDTERFTEVHSElHSFdB VEVSCTEwMDAwCS8qIGxpbWl0IGZvciBjbGllbnQgZGVsZWdhdGlvbnMgKi8KICNlbmRpZgpAQCAt MjA0LDYgKzE5OCwxOCBAQCBzdHJ1Y3QgbmZzZF9pZGFyZ3MgewogCWludAkJbmlkX3VzZXJ0aW1l b3V0Oy8qIFVzZXIgbmFtZSB0aW1lb3V0IChtaW51dGVzKSAqLwogCXVfY2hhcgkJKm5pZF9uYW1l OwkvKiBOYW1lICovCiAJaW50CQluaWRfbmFtZWxlbjsJLyogYW5kIGl0cyBsZW5ndGggKi8KKwln aWRfdAkJKm5pZF9ncnBzOwkvKiBhbmQgdGhlIGxpc3QgKi8KKwlpbnQJCW5pZF9uZ3JvdXA7CS8q IFNpemUgb2YgZ3JvdXBzIGxpc3QgKi8KK307CisKK3N0cnVjdCBuZnNkX29pZGFyZ3MgeworCWlu dAkJbmlkX2ZsYWc7CS8qIEZsYWdzIChzZWUgYmVsb3cpICovCisJdWlkX3QJCW5pZF91aWQ7CS8q IHVzZXIvZ3JvdXAgaWQgKi8KKwlnaWRfdAkJbmlkX2dpZDsKKwlpbnQJCW5pZF91c2VybWF4Owkv KiBVcHBlciBib3VuZCBvbiB1c2VyIG5hbWUgY2FjaGUgKi8KKwlpbnQJCW5pZF91c2VydGltZW91 dDsvKiBVc2VyIG5hbWUgdGltZW91dCAobWludXRlcykgKi8KKwl1X2NoYXIJCSpuaWRfbmFtZTsJ LyogTmFtZSAqLworCWludAkJbmlkX25hbWVsZW47CS8qIGFuZCBpdHMgbGVuZ3RoICovCiB9Owog CiBzdHJ1Y3QgbmZzZF9jbGlkIHsKLS0tIGZzL25mcy9uZnNfdmFyLmguc2F2CTIwMTUtMDktMjgg MTg6NDk6MzUuMDAwMDAwMDAwIC0wNDAwCisrKyBmcy9uZnMvbmZzX3Zhci5oCTIwMTUtMTEtMTMg MTk6MzU6MzYuNjA3ODM3MDAwIC0wNTAwCkBAIC0yOTUsNiArMjk1LDcgQEAgdm9pZCBuZnN2NF9z ZXRzZXF1ZW5jZShzdHJ1Y3QgbmZzbW91bnQgKgogaW50IG5mc3Y0X3NlcXVlbmNlbG9va3VwKHN0 cnVjdCBuZnNtb3VudCAqLCBzdHJ1Y3QgbmZzY2xzZXNzaW9uICosIGludCAqLAogICAgIGludCAq LCB1aW50MzJfdCAqLCB1aW50OF90ICopOwogdm9pZCBuZnN2NF9mcmVlc2xvdChzdHJ1Y3QgbmZz Y2xzZXNzaW9uICosIGludCk7CitzdHJ1Y3QgdWNyZWQgKm5mc3J2X2dldGdycHNjcmVkKHN0cnVj dCB1Y3JlZCAqKTsKIAogLyogbmZzX2NsY29tc3Vicy5jICovCiB2b2lkIG5mc21fdWlvbWJ1Zihz dHJ1Y3QgbmZzcnZfZGVzY3JpcHQgKiwgc3RydWN0IHVpbyAqLCBpbnQpOwotLS0gZnMvbmZzL25m c19jb21tb25zdWJzLmMuc2F2CTIwMTUtMDktMjggMTg6NDk6MzUuMDAwMDAwMDAwIC0wNDAwCisr KyBmcy9uZnMvbmZzX2NvbW1vbnN1YnMuYwkyMDE1LTExLTEzIDIwOjEyOjExLjA5MDg3MzAwMCAt MDUwMApAQCAtNDQsNiArNDQsOCBAQCBfX0ZCU0RJRCgiJEZyZWVCU0Q6IGhlYWQvc3lzL2ZzL25m cy9uZnNfCiAKICNpbmNsdWRlIDxmcy9uZnMvbmZzcG9ydC5oPgogCisjaW5jbHVkZSA8c2VjdXJp dHkvbWFjL21hY19mcmFtZXdvcmsuaD4KKwogLyoKICAqIERhdGEgaXRlbXMgY29udmVydGVkIHRv IHhkciBhdCBzdGFydHVwLCBzaW5jZSB0aGV5IGFyZSBjb25zdGFudAogICogVGhpcyBpcyBraW5k YSBob2tleSwgYnV0IG1heSBzYXZlIGEgbGl0dGxlIHRpbWUgZG9pbmcgYnl0ZSBzd2FwcwpAQCAt NjgsNiArNzAsNyBAQCBpbnQgbmNsX21idWZfbWxlbiA9IE1MRU47CiBpbnQgbmZzZF9lbmFibGVf c3RyaW5ndG91aWQgPSAwOwogTkZTTkFNRUlETVVURVg7CiBORlNTT0NLTVVURVg7CitleHRlcm4g aW50IG5mc3J2X2x1Z2hhc2hzaXplOwogCiAvKgogICogVGhpcyBhcnJheSBvZiBzdHJ1Y3R1cmVz IGluZGljYXRlcywgZm9yIFY0OgpAQCAtMTU0LDExICsxNTcsMTQgQEAgc3RhdGljIGludCBuZnNy dl91c2VyY250ID0gMDsKIHN0YXRpYyBpbnQgbmZzcnZfZG5zbmFtZWxlbjsKIHN0YXRpYyB1X2No YXIgKm5mc3J2X2Ruc25hbWUgPSBOVUxMOwogc3RhdGljIGludCBuZnNydl91c2VybWF4ID0gOTk5 OTk5OTk5Owotc3RhdGljIHN0cnVjdCBuZnN1c2VyaGFzaGhlYWQgbmZzdXNlcmhhc2hbTkZTVVNF UkhBU0hTSVpFXTsKLXN0YXRpYyBzdHJ1Y3QgbmZzdXNlcmhhc2hoZWFkIG5mc3VzZXJuYW1laGFz aFtORlNVU0VSSEFTSFNJWkVdOwotc3RhdGljIHN0cnVjdCBuZnN1c2VyaGFzaGhlYWQgbmZzZ3Jv dXBoYXNoW05GU0dST1VQSEFTSFNJWkVdOwotc3RhdGljIHN0cnVjdCBuZnN1c2VyaGFzaGhlYWQg bmZzZ3JvdXBuYW1laGFzaFtORlNHUk9VUEhBU0hTSVpFXTsKLXN0YXRpYyBzdHJ1Y3QgbmZzdXNl cmxydWhlYWQgbmZzdXNlcmxydWhlYWQ7CitzdHJ1Y3QgbmZzcnZfbHVnaGFzaCB7CisJc3RydWN0 IG10eAkJbXR4OworCXN0cnVjdCBuZnN1c2VyaGFzaGhlYWQJbHVnaGVhZDsKK307CitzdGF0aWMg c3RydWN0IG5mc3J2X2x1Z2hhc2gJKm5mc3VzZXJoYXNoOworc3RhdGljIHN0cnVjdCBuZnNydl9s dWdoYXNoCSpuZnN1c2VybmFtZWhhc2g7CitzdGF0aWMgc3RydWN0IG5mc3J2X2x1Z2hhc2gJKm5m c2dyb3VwaGFzaDsKK3N0YXRpYyBzdHJ1Y3QgbmZzcnZfbHVnaGFzaAkqbmZzZ3JvdXBuYW1laGFz aDsKIAogLyoKICAqIFRoaXMgc3RhdGljIGFycmF5IGluZGljYXRlcyB3aGV0aGVyIG9yIG5vdCB0 aGUgUlBDIGdlbmVyYXRlcyBhIGxhcmdlCkBAIC0xNzcsNyArMTgzLDcgQEAgc3RhdGljIHZvaWQg bmZzdjRfd2FudGVkKHN0cnVjdCBuZnN2NGxvYwogc3RhdGljIGludCBuZnNydl9jbXBtaXhlZGNh c2UodV9jaGFyICpjcCwgdV9jaGFyICpjcDIsIGludCBsZW4pOwogc3RhdGljIGludCBuZnNydl9n ZXR1c2VyKGludCBwcm9jbnVtLCB1aWRfdCB1aWQsIGdpZF90IGdpZCwgY2hhciAqbmFtZSwKICAg ICBORlNQUk9DX1QgKnApOwotc3RhdGljIHZvaWQgbmZzcnZfcmVtb3ZldXNlcihzdHJ1Y3QgbmZz dXNyZ3JwICp1c3JwKTsKK3N0YXRpYyB2b2lkIG5mc3J2X3JlbW92ZXVzZXIoc3RydWN0IG5mc3Vz cmdycCAqdXNycCwgaW50IGlzdXNlcik7CiBzdGF0aWMgaW50IG5mc3J2X2dldHJlZnN0cihzdHJ1 Y3QgbmZzcnZfZGVzY3JpcHQgKiwgdV9jaGFyICoqLCB1X2NoYXIgKiosCiAgICAgaW50ICosIGlu dCAqKTsKIHN0YXRpYyB2b2lkIG5mc3J2X3JlZnN0cmJpZ2Vub3VnaChpbnQsIHVfY2hhciAqKiwg dV9jaGFyICoqLCBpbnQgKik7CkBAIC0yNTQ4LDE4ICsyNTU0LDE3IEBAIG5mc3Y0X3VpZHRvc3Ry KHVpZF90IHVpZCwgdV9jaGFyICoqY3BwLCAKIAl1X2NoYXIgKmNwID0gKmNwcDsKIAl1aWRfdCB0 bXA7CiAJaW50IGNudCwgaGFzYW1wZXJzYW5kLCBsZW4gPSBORlNWNF9TTUFMTFNUUiwgcmV0Owor CXN0cnVjdCBuZnNydl9sdWdoYXNoICpocDsKIAogCWNudCA9IDA7CiB0cnlhZ2FpbjoKLQlORlNM T0NLTkFNRUlEKCk7Ci0JaWYgKG5mc3J2X2Ruc25hbWUpIHsKKwlpZiAobmZzcnZfZG5zbmFtZWxl biA+IDApIHsKIAkJLyoKIAkJICogQWx3YXlzIG1hcCBuZnNydl9kZWZhdWx0dWlkIHRvICJub2Jv ZHkiLgogCQkgKi8KIAkJaWYgKHVpZCA9PSBuZnNydl9kZWZhdWx0dWlkKSB7CiAJCQlpID0gbmZz cnZfZG5zbmFtZWxlbiArIDc7CiAJCQlpZiAoaSA+IGxlbikgewotCQkJCU5GU1VOTE9DS05BTUVJ RCgpOwogCQkJCWlmIChsZW4gPiBORlNWNF9TTUFMTFNUUikKIAkJCQkJZnJlZShjcCwgTV9ORlNT VFJJTkcpOwogCQkJCWNwID0gbWFsbG9jKGksIE1fTkZTU1RSSU5HLCBNX1dBSVRPSyk7CkBAIC0y NTcxLDExICsyNTc2LDEyIEBAIHRyeWFnYWluOgogCQkJTkZTQkNPUFkoIm5vYm9keUAiLCBjcCwg Nyk7CiAJCQljcCArPSA3OwogCQkJTkZTQkNPUFkobmZzcnZfZG5zbmFtZSwgY3AsIG5mc3J2X2Ru c25hbWVsZW4pOwotCQkJTkZTVU5MT0NLTkFNRUlEKCk7CiAJCQlyZXR1cm47CiAJCX0KIAkJaGFz YW1wZXJzYW5kID0gMDsKLQkJTElTVF9GT1JFQUNIKHVzcnAsIE5GU1VTRVJIQVNIKHVpZCksIGx1 Z19udW1oYXNoKSB7CisJCWhwID0gTkZTVVNFUkhBU0godWlkKTsKKwkJbXR4X2xvY2soJmhwLT5t dHgpOworCQlUQUlMUV9GT1JFQUNIKHVzcnAsICZocC0+bHVnaGVhZCwgbHVnX251bWhhc2gpIHsK IAkJCWlmICh1c3JwLT5sdWdfdWlkID09IHVpZCkgewogCQkJCWlmICh1c3JwLT5sdWdfZXhwaXJ5 IDwgTkZTRF9NT05PU0VDKQogCQkJCQlicmVhazsKQEAgLTI1OTUsNyArMjYwMSw3IEBAIHRyeWFn YWluOgogCQkJCQlpID0gdXNycC0+bHVnX25hbWVsZW4gKwogCQkJCQkgICAgbmZzcnZfZG5zbmFt ZWxlbiArIDE7CiAJCQkJaWYgKGkgPiBsZW4pIHsKLQkJCQkJTkZTVU5MT0NLTkFNRUlEKCk7CisJ CQkJCW10eF91bmxvY2soJmhwLT5tdHgpOwogCQkJCQlpZiAobGVuID4gTkZTVjRfU01BTExTVFIp CiAJCQkJCQlmcmVlKGNwLCBNX05GU1NUUklORyk7CiAJCQkJCWNwID0gbWFsbG9jKGksIE1fTkZT U1RSSU5HLCBNX1dBSVRPSyk7CkBAIC0yNjEwLDIwICsyNjE2LDE5IEBAIHRyeWFnYWluOgogCQkJ CQkqY3ArKyA9ICdAJzsKIAkJCQkJTkZTQkNPUFkobmZzcnZfZG5zbmFtZSwgY3AsIG5mc3J2X2Ru c25hbWVsZW4pOwogCQkJCX0KLQkJCQlUQUlMUV9SRU1PVkUoJm5mc3VzZXJscnVoZWFkLCB1c3Jw LCBsdWdfbHJ1KTsKLQkJCQlUQUlMUV9JTlNFUlRfVEFJTCgmbmZzdXNlcmxydWhlYWQsIHVzcnAs IGx1Z19scnUpOwotCQkJCU5GU1VOTE9DS05BTUVJRCgpOworCQkJCVRBSUxRX1JFTU9WRSgmaHAt Pmx1Z2hlYWQsIHVzcnAsIGx1Z19udW1oYXNoKTsKKwkJCQlUQUlMUV9JTlNFUlRfVEFJTCgmaHAt Pmx1Z2hlYWQsIHVzcnAsCisJCQkJICAgIGx1Z19udW1oYXNoKTsKKwkJCQltdHhfdW5sb2NrKCZo cC0+bXR4KTsKIAkJCQlyZXR1cm47CiAJCQl9CiAJCX0KLQkJTkZTVU5MT0NLTkFNRUlEKCk7CisJ CW10eF91bmxvY2soJmhwLT5tdHgpOwogCQljbnQrKzsKIAkJcmV0ID0gbmZzcnZfZ2V0dXNlcihS UENORlNVU0VSRF9HRVRVSUQsIHVpZCwgKGdpZF90KTAsCiAJCSAgICBOVUxMLCBwKTsKIAkJaWYg KHJldCA9PSAwICYmIGNudCA8IDIpCiAJCQlnb3RvIHRyeWFnYWluOwotCX0gZWxzZSB7Ci0JCU5G U1VOTE9DS05BTUVJRCgpOwogCX0KIAogCS8qCkBAIC0yNjQ3LDYgKzI2NTIsNTIgQEAgdHJ5YWdh aW46CiB9CiAKIC8qCisgKiBHZXQgYSBjcmVkZW50aWFsIGZvciB0aGUgdWlkIHdpdGggdGhlIHNl cnZlcidzIGdyb3VwIGxpc3QuCisgKiBJZiBub25lIGlzIGZvdW5kLCBqdXN0IHJldHVybiB0aGUg Y3JlZGVudGlhbCBwYXNzZWQgaW4gYWZ0ZXIKKyAqIGxvZ2dpbmcgYSB3YXJuaW5nIG1lc3NhZ2Uu CisgKi8KK3N0cnVjdCB1Y3JlZCAqCituZnNydl9nZXRncnBzY3JlZChzdHJ1Y3QgdWNyZWQgKm9s ZGNyZWQpCit7CisJc3RydWN0IG5mc3VzcmdycCAqdXNycDsKKwlzdHJ1Y3QgdWNyZWQgKm5ld2Ny ZWQ7CisJaW50IGNudCwgcmV0OworCXVpZF90IHVpZDsKKwlzdHJ1Y3QgbmZzcnZfbHVnaGFzaCAq aHA7CisKKwljbnQgPSAwOworCXVpZCA9IG9sZGNyZWQtPmNyX3VpZDsKK3RyeWFnYWluOgorCWlm IChuZnNydl9kbnNuYW1lbGVuID4gMCkgeworCQlocCA9IE5GU1VTRVJIQVNIKHVpZCk7CisJCW10 eF9sb2NrKCZocC0+bXR4KTsKKwkJVEFJTFFfRk9SRUFDSCh1c3JwLCAmaHAtPmx1Z2hlYWQsIGx1 Z19udW1oYXNoKSB7CisJCQlpZiAodXNycC0+bHVnX3VpZCA9PSB1aWQpIHsKKwkJCQlpZiAodXNy cC0+bHVnX2V4cGlyeSA8IE5GU0RfTU9OT1NFQykKKwkJCQkJYnJlYWs7CisJCQkJaWYgKHVzcnAt Pmx1Z19jcmVkICE9IE5VTEwpIHsKKwkJCQkJbmV3Y3JlZCA9IGNyaG9sZCh1c3JwLT5sdWdfY3Jl ZCk7CisJCQkJCWNyZnJlZShvbGRjcmVkKTsKKwkJCQl9IGVsc2UKKwkJCQkJbmV3Y3JlZCA9IG9s ZGNyZWQ7CisJCQkJVEFJTFFfUkVNT1ZFKCZocC0+bHVnaGVhZCwgdXNycCwgbHVnX251bWhhc2gp OworCQkJCVRBSUxRX0lOU0VSVF9UQUlMKCZocC0+bHVnaGVhZCwgdXNycCwKKwkJCQkgICAgbHVn X251bWhhc2gpOworCQkJCW10eF91bmxvY2soJmhwLT5tdHgpOworCQkJCXJldHVybiAobmV3Y3Jl ZCk7CisJCQl9CisJCX0KKwkJbXR4X3VubG9jaygmaHAtPm10eCk7CisJCWNudCsrOworCQlyZXQg PSBuZnNydl9nZXR1c2VyKFJQQ05GU1VTRVJEX0dFVFVJRCwgdWlkLCAoZ2lkX3QpMCwKKwkJICAg IE5VTEwsIGN1cnRocmVhZCk7CisJCWlmIChyZXQgPT0gMCAmJiBjbnQgPCAyKQorCQkJZ290byB0 cnlhZ2FpbjsKKwl9CisJcmV0dXJuIChvbGRjcmVkKTsKK30KKworLyoKICAqIENvbnZlcnQgYSBz dHJpbmcgdG8gYSB1aWQuCiAgKiBJZiBubyBjb252ZXJzaW9uIGlzIHBvc3NpYmxlIHJldHVybiBO RlNFUlJfQkFET1dORVIsIG90aGVyd2lzZQogICogcmV0dXJuIDAuCkBAIC0yNjY0LDYgKzI3MTUs NyBAQCBuZnN2NF9zdHJ0b3VpZChzdHJ1Y3QgbmZzcnZfZGVzY3JpcHQgKm5kCiAJaW50IGNudCwg cmV0OwogCWludCBlcnJvciA9IDA7CiAJdWlkX3QgdHVpZDsKKwlzdHJ1Y3QgbmZzcnZfbHVnaGFz aCAqaHAsICpocDI7CiAKIAlpZiAobGVuID09IDApIHsKIAkJZXJyb3IgPSBORlNFUlJfQkFET1dO RVI7CkBAIC0yNjkzLDQ5ICsyNzQ1LDU1IEBAIG5mc3Y0X3N0cnRvdWlkKHN0cnVjdCBuZnNydl9k ZXNjcmlwdCAqbmQKIAogCWNudCA9IDA7CiB0cnlhZ2FpbjoKLQlORlNMT0NLTkFNRUlEKCk7Ci0J LyoKLQkgKiBJZiBhbiAnQCcgaXMgZm91bmQgYW5kIHRoZSBkb21haW4gbmFtZSBtYXRjaGVzLCBz ZWFyY2ggZm9yIHRoZSBuYW1lCi0JICogd2l0aCBkbnMgc3RyaXBwZWQgb2ZmLgotCSAqIE1peGVk IGNhc2UgYWxwYWhiZXRpY3Mgd2lsbCBtYXRjaCBmb3IgdGhlIGRvbWFpbiBuYW1lLCBidXQgYWxs Ci0JICogdXBwZXIgY2FzZSB3aWxsIG5vdC4KLQkgKi8KLQlpZiAoY250ID09IDAgJiYgaSA8IGxl biAmJiBpID4gMCAmJiBuZnNydl9kbnNuYW1lICYmCi0JICAgIChsZW4gLSAxIC0gaSkgPT0gbmZz cnZfZG5zbmFtZWxlbiAmJgotCSAgICAhbmZzcnZfY21wbWl4ZWRjYXNlKGNwLCBuZnNydl9kbnNu YW1lLCBuZnNydl9kbnNuYW1lbGVuKSkgewotCQlsZW4gLT0gKG5mc3J2X2Ruc25hbWVsZW4gKyAx KTsKLQkJKihjcCAtIDEpID0gJ1wwJzsKLQl9Ci0KLQkvKgotCSAqIENoZWNrIGZvciB0aGUgc3Bl Y2lhbCBjYXNlIG9mICJub2JvZHkiLgotCSAqLwotCWlmIChsZW4gPT0gNiAmJiAhTkZTQkNNUChz dHIsICJub2JvZHkiLCA2KSkgewotCQkqdWlkcCA9IG5mc3J2X2RlZmF1bHR1aWQ7Ci0JCU5GU1VO TE9DS05BTUVJRCgpOwotCQllcnJvciA9IDA7Ci0JCWdvdG8gb3V0OwotCX0KLQotCUxJU1RfRk9S RUFDSCh1c3JwLCBORlNVU0VSTkFNRUhBU0goc3RyLCBsZW4pLCBsdWdfbmFtZWhhc2gpIHsKLQkJ aWYgKHVzcnAtPmx1Z19uYW1lbGVuID09IGxlbiAmJgotCQkgICAgIU5GU0JDTVAodXNycC0+bHVn X25hbWUsIHN0ciwgbGVuKSkgewotCQkJaWYgKHVzcnAtPmx1Z19leHBpcnkgPCBORlNEX01PTk9T RUMpCi0JCQkJYnJlYWs7Ci0JCQkqdWlkcCA9IHVzcnAtPmx1Z191aWQ7Ci0JCQlUQUlMUV9SRU1P VkUoJm5mc3VzZXJscnVoZWFkLCB1c3JwLCBsdWdfbHJ1KTsKLQkJCVRBSUxRX0lOU0VSVF9UQUlM KCZuZnN1c2VybHJ1aGVhZCwgdXNycCwgbHVnX2xydSk7Ci0JCQlORlNVTkxPQ0tOQU1FSUQoKTsK KwlpZiAobmZzcnZfZG5zbmFtZWxlbiA+IDApIHsKKwkJLyoKKwkJICogSWYgYW4gJ0AnIGlzIGZv dW5kIGFuZCB0aGUgZG9tYWluIG5hbWUgbWF0Y2hlcywgc2VhcmNoIGZvcgorCQkgKiB0aGUgbmFt ZSB3aXRoIGRucyBzdHJpcHBlZCBvZmYuCisJCSAqIE1peGVkIGNhc2UgYWxwYWhiZXRpY3Mgd2ls bCBtYXRjaCBmb3IgdGhlIGRvbWFpbiBuYW1lLCBidXQKKwkJICogYWxsIHVwcGVyIGNhc2Ugd2ls bCBub3QuCisJCSAqLworCQlpZiAoY250ID09IDAgJiYgaSA8IGxlbiAmJiBpID4gMCAmJgorCQkg ICAgKGxlbiAtIDEgLSBpKSA9PSBuZnNydl9kbnNuYW1lbGVuICYmCisJCSAgICAhbmZzcnZfY21w bWl4ZWRjYXNlKGNwLCBuZnNydl9kbnNuYW1lLCBuZnNydl9kbnNuYW1lbGVuKSkgeworCQkJbGVu IC09IChuZnNydl9kbnNuYW1lbGVuICsgMSk7CisJCQkqKGNwIC0gMSkgPSAnXDAnOworCQl9CisJ CisJCS8qCisJCSAqIENoZWNrIGZvciB0aGUgc3BlY2lhbCBjYXNlIG9mICJub2JvZHkiLgorCQkg Ki8KKwkJaWYgKGxlbiA9PSA2ICYmICFORlNCQ01QKHN0ciwgIm5vYm9keSIsIDYpKSB7CisJCQkq dWlkcCA9IG5mc3J2X2RlZmF1bHR1aWQ7CiAJCQllcnJvciA9IDA7CiAJCQlnb3RvIG91dDsKIAkJ fQorCQorCQlocCA9IE5GU1VTRVJOQU1FSEFTSChzdHIsIGxlbik7CisJCW10eF9sb2NrKCZocC0+ bXR4KTsKKwkJVEFJTFFfRk9SRUFDSCh1c3JwLCAmaHAtPmx1Z2hlYWQsIGx1Z19uYW1laGFzaCkg eworCQkJaWYgKHVzcnAtPmx1Z19uYW1lbGVuID09IGxlbiAmJgorCQkJICAgICFORlNCQ01QKHVz cnAtPmx1Z19uYW1lLCBzdHIsIGxlbikpIHsKKwkJCQlpZiAodXNycC0+bHVnX2V4cGlyeSA8IE5G U0RfTU9OT1NFQykKKwkJCQkJYnJlYWs7CisJCQkJaHAyID0gTkZTVVNFUkhBU0godXNycC0+bHVn X3VpZCk7CisJCQkJbXR4X2xvY2soJmhwMi0+bXR4KTsKKwkJCQlUQUlMUV9SRU1PVkUoJmhwMi0+ bHVnaGVhZCwgdXNycCwgbHVnX251bWhhc2gpOworCQkJCVRBSUxRX0lOU0VSVF9UQUlMKCZocDIt Pmx1Z2hlYWQsIHVzcnAsCisJCQkJICAgIGx1Z19udW1oYXNoKTsKKwkJCQkqdWlkcCA9IHVzcnAt Pmx1Z191aWQ7CisJCQkJbXR4X3VubG9jaygmaHAyLT5tdHgpOworCQkJCW10eF91bmxvY2soJmhw LT5tdHgpOworCQkJCWVycm9yID0gMDsKKwkJCQlnb3RvIG91dDsKKwkJCX0KKwkJfQorCQltdHhf dW5sb2NrKCZocC0+bXR4KTsKKwkJY250Kys7CisJCXJldCA9IG5mc3J2X2dldHVzZXIoUlBDTkZT VVNFUkRfR0VUVVNFUiwgKHVpZF90KTAsIChnaWRfdCkwLAorCQkgICAgc3RyLCBwKTsKKwkJaWYg KHJldCA9PSAwICYmIGNudCA8IDIpCisJCQlnb3RvIHRyeWFnYWluOwogCX0KLQlORlNVTkxPQ0tO QU1FSUQoKTsKLQljbnQrKzsKLQlyZXQgPSBuZnNydl9nZXR1c2VyKFJQQ05GU1VTRVJEX0dFVFVT RVIsICh1aWRfdCkwLCAoZ2lkX3QpMCwKLQkgICAgc3RyLCBwKTsKLQlpZiAocmV0ID09IDAgJiYg Y250IDwgMikKLQkJZ290byB0cnlhZ2FpbjsKIAllcnJvciA9IE5GU0VSUl9CQURPV05FUjsKIAog b3V0OgpAQCAtMjc1OCwxOCArMjgxNiwxNyBAQCBuZnN2NF9naWR0b3N0cihnaWRfdCBnaWQsIHVf Y2hhciAqKmNwcCwgCiAJdV9jaGFyICpjcCA9ICpjcHA7CiAJZ2lkX3QgdG1wOwogCWludCBjbnQs IGhhc2FtcGVyc2FuZCwgbGVuID0gTkZTVjRfU01BTExTVFIsIHJldDsKKwlzdHJ1Y3QgbmZzcnZf bHVnaGFzaCAqaHA7CiAKIAljbnQgPSAwOwogdHJ5YWdhaW46Ci0JTkZTTE9DS05BTUVJRCgpOwot CWlmIChuZnNydl9kbnNuYW1lKSB7CisJaWYgKG5mc3J2X2Ruc25hbWVsZW4gPiAwKSB7CiAJCS8q CiAJCSAqIEFsd2F5cyBtYXAgbmZzcnZfZGVmYXVsdGdpZCB0byAibm9ncm91cCIuCiAJCSAqLwog CQlpZiAoZ2lkID09IG5mc3J2X2RlZmF1bHRnaWQpIHsKIAkJCWkgPSBuZnNydl9kbnNuYW1lbGVu ICsgODsKIAkJCWlmIChpID4gbGVuKSB7Ci0JCQkJTkZTVU5MT0NLTkFNRUlEKCk7CiAJCQkJaWYg KGxlbiA+IE5GU1Y0X1NNQUxMU1RSKQogCQkJCQlmcmVlKGNwLCBNX05GU1NUUklORyk7CiAJCQkJ Y3AgPSBtYWxsb2MoaSwgTV9ORlNTVFJJTkcsIE1fV0FJVE9LKTsKQEAgLTI3ODEsMTEgKzI4Mzgs MTIgQEAgdHJ5YWdhaW46CiAJCQlORlNCQ09QWSgibm9ncm91cEAiLCBjcCwgOCk7CiAJCQljcCAr PSA4OwogCQkJTkZTQkNPUFkobmZzcnZfZG5zbmFtZSwgY3AsIG5mc3J2X2Ruc25hbWVsZW4pOwot CQkJTkZTVU5MT0NLTkFNRUlEKCk7CiAJCQlyZXR1cm47CiAJCX0KIAkJaGFzYW1wZXJzYW5kID0g MDsKLQkJTElTVF9GT1JFQUNIKHVzcnAsIE5GU0dST1VQSEFTSChnaWQpLCBsdWdfbnVtaGFzaCkg eworCQlocCA9IE5GU0dST1VQSEFTSChnaWQpOworCQltdHhfbG9jaygmaHAtPm10eCk7CisJCVRB SUxRX0ZPUkVBQ0godXNycCwgJmhwLT5sdWdoZWFkLCBsdWdfbnVtaGFzaCkgewogCQkJaWYgKHVz cnAtPmx1Z19naWQgPT0gZ2lkKSB7CiAJCQkJaWYgKHVzcnAtPmx1Z19leHBpcnkgPCBORlNEX01P Tk9TRUMpCiAJCQkJCWJyZWFrOwpAQCAtMjgwNSw3ICsyODYzLDcgQEAgdHJ5YWdhaW46CiAJCQkJ CWkgPSB1c3JwLT5sdWdfbmFtZWxlbiArCiAJCQkJCSAgICBuZnNydl9kbnNuYW1lbGVuICsgMTsK IAkJCQlpZiAoaSA+IGxlbikgewotCQkJCQlORlNVTkxPQ0tOQU1FSUQoKTsKKwkJCQkJbXR4X3Vu bG9jaygmaHAtPm10eCk7CiAJCQkJCWlmIChsZW4gPiBORlNWNF9TTUFMTFNUUikKIAkJCQkJCWZy ZWUoY3AsIE1fTkZTU1RSSU5HKTsKIAkJCQkJY3AgPSBtYWxsb2MoaSwgTV9ORlNTVFJJTkcsIE1f V0FJVE9LKTsKQEAgLTI4MjAsMjAgKzI4NzgsMTkgQEAgdHJ5YWdhaW46CiAJCQkJCSpjcCsrID0g J0AnOwogCQkJCQlORlNCQ09QWShuZnNydl9kbnNuYW1lLCBjcCwgbmZzcnZfZG5zbmFtZWxlbik7 CiAJCQkJfQotCQkJCVRBSUxRX1JFTU9WRSgmbmZzdXNlcmxydWhlYWQsIHVzcnAsIGx1Z19scnUp OwotCQkJCVRBSUxRX0lOU0VSVF9UQUlMKCZuZnN1c2VybHJ1aGVhZCwgdXNycCwgbHVnX2xydSk7 Ci0JCQkJTkZTVU5MT0NLTkFNRUlEKCk7CisJCQkJVEFJTFFfUkVNT1ZFKCZocC0+bHVnaGVhZCwg dXNycCwgbHVnX251bWhhc2gpOworCQkJCVRBSUxRX0lOU0VSVF9UQUlMKCZocC0+bHVnaGVhZCwg dXNycCwKKwkJCQkgICAgbHVnX251bWhhc2gpOworCQkJCW10eF91bmxvY2soJmhwLT5tdHgpOwog CQkJCXJldHVybjsKIAkJCX0KIAkJfQotCQlORlNVTkxPQ0tOQU1FSUQoKTsKKwkJbXR4X3VubG9j aygmaHAtPm10eCk7CiAJCWNudCsrOwogCQlyZXQgPSBuZnNydl9nZXR1c2VyKFJQQ05GU1VTRVJE X0dFVEdJRCwgKHVpZF90KTAsIGdpZCwKIAkJICAgIE5VTEwsIHApOwogCQlpZiAocmV0ID09IDAg JiYgY250IDwgMikKIAkJCWdvdG8gdHJ5YWdhaW47Ci0JfSBlbHNlIHsKLQkJTkZTVU5MT0NLTkFN RUlEKCk7CiAJfQogCiAJLyoKQEAgLTI4NzQsNiArMjkzMSw3IEBAIG5mc3Y0X3N0cnRvZ2lkKHN0 cnVjdCBuZnNydl9kZXNjcmlwdCAqbmQKIAlpbnQgY250LCByZXQ7CiAJaW50IGVycm9yID0gMDsK IAlnaWRfdCB0Z2lkOworCXN0cnVjdCBuZnNydl9sdWdoYXNoICpocCwgKmhwMjsKIAogCWlmIChs ZW4gPT0gMCkgewogCQllcnJvciA9ICBORlNFUlJfQkFET1dORVI7CkBAIC0yOTAzLDQ3ICsyOTYx LDUzIEBAIG5mc3Y0X3N0cnRvZ2lkKHN0cnVjdCBuZnNydl9kZXNjcmlwdCAqbmQKIAogCWNudCA9 IDA7CiB0cnlhZ2FpbjoKLQlORlNMT0NLTkFNRUlEKCk7Ci0JLyoKLQkgKiBJZiBhbiAnQCcgaXMg Zm91bmQgYW5kIHRoZSBkbnMgbmFtZSBtYXRjaGVzLCBzZWFyY2ggZm9yIHRoZSBuYW1lCi0JICog d2l0aCB0aGUgZG5zIHN0cmlwcGVkIG9mZi4KLQkgKi8KLQlpZiAoY250ID09IDAgJiYgaSA8IGxl biAmJiBpID4gMCAmJiBuZnNydl9kbnNuYW1lICYmCi0JICAgIChsZW4gLSAxIC0gaSkgPT0gbmZz cnZfZG5zbmFtZWxlbiAmJgotCSAgICAhbmZzcnZfY21wbWl4ZWRjYXNlKGNwLCBuZnNydl9kbnNu YW1lLCBuZnNydl9kbnNuYW1lbGVuKSkgewotCQlsZW4gLT0gKG5mc3J2X2Ruc25hbWVsZW4gKyAx KTsKLQkJKihjcCAtIDEpID0gJ1wwJzsKLQl9Ci0KLQkvKgotCSAqIENoZWNrIGZvciB0aGUgc3Bl Y2lhbCBjYXNlIG9mICJub2dyb3VwIi4KLQkgKi8KLQlpZiAobGVuID09IDcgJiYgIU5GU0JDTVAo c3RyLCAibm9ncm91cCIsIDcpKSB7Ci0JCSpnaWRwID0gbmZzcnZfZGVmYXVsdGdpZDsKLQkJTkZT VU5MT0NLTkFNRUlEKCk7Ci0JCWVycm9yID0gMDsKLQkJZ290byBvdXQ7Ci0JfQotCi0JTElTVF9G T1JFQUNIKHVzcnAsIE5GU0dST1VQTkFNRUhBU0goc3RyLCBsZW4pLCBsdWdfbmFtZWhhc2gpIHsK LQkJaWYgKHVzcnAtPmx1Z19uYW1lbGVuID09IGxlbiAmJgotCQkgICAgIU5GU0JDTVAodXNycC0+ bHVnX25hbWUsIHN0ciwgbGVuKSkgewotCQkJaWYgKHVzcnAtPmx1Z19leHBpcnkgPCBORlNEX01P Tk9TRUMpCi0JCQkJYnJlYWs7Ci0JCQkqZ2lkcCA9IHVzcnAtPmx1Z19naWQ7Ci0JCQlUQUlMUV9S RU1PVkUoJm5mc3VzZXJscnVoZWFkLCB1c3JwLCBsdWdfbHJ1KTsKLQkJCVRBSUxRX0lOU0VSVF9U QUlMKCZuZnN1c2VybHJ1aGVhZCwgdXNycCwgbHVnX2xydSk7Ci0JCQlORlNVTkxPQ0tOQU1FSUQo KTsKKwlpZiAobmZzcnZfZG5zbmFtZWxlbiA+IDApIHsKKwkJLyoKKwkJICogSWYgYW4gJ0AnIGlz IGZvdW5kIGFuZCB0aGUgZG5zIG5hbWUgbWF0Y2hlcywgc2VhcmNoIGZvciB0aGUKKwkJICogbmFt ZSB3aXRoIHRoZSBkbnMgc3RyaXBwZWQgb2ZmLgorCQkgKi8KKwkJaWYgKGNudCA9PSAwICYmIGkg PCBsZW4gJiYgaSA+IDAgJiYKKwkJICAgIChsZW4gLSAxIC0gaSkgPT0gbmZzcnZfZG5zbmFtZWxl biAmJgorCQkgICAgIW5mc3J2X2NtcG1peGVkY2FzZShjcCwgbmZzcnZfZG5zbmFtZSwgbmZzcnZf ZG5zbmFtZWxlbikpIHsKKwkJCWxlbiAtPSAobmZzcnZfZG5zbmFtZWxlbiArIDEpOworCQkJKihj cCAtIDEpID0gJ1wwJzsKKwkJfQorCQorCQkvKgorCQkgKiBDaGVjayBmb3IgdGhlIHNwZWNpYWwg Y2FzZSBvZiAibm9ncm91cCIuCisJCSAqLworCQlpZiAobGVuID09IDcgJiYgIU5GU0JDTVAoc3Ry LCAibm9ncm91cCIsIDcpKSB7CisJCQkqZ2lkcCA9IG5mc3J2X2RlZmF1bHRnaWQ7CiAJCQllcnJv ciA9IDA7CiAJCQlnb3RvIG91dDsKIAkJfQorCQorCQlocCA9IE5GU0dST1VQTkFNRUhBU0goc3Ry LCBsZW4pOworCQltdHhfbG9jaygmaHAtPm10eCk7CisJCVRBSUxRX0ZPUkVBQ0godXNycCwgJmhw LT5sdWdoZWFkLCBsdWdfbmFtZWhhc2gpIHsKKwkJCWlmICh1c3JwLT5sdWdfbmFtZWxlbiA9PSBs ZW4gJiYKKwkJCSAgICAhTkZTQkNNUCh1c3JwLT5sdWdfbmFtZSwgc3RyLCBsZW4pKSB7CisJCQkJ aWYgKHVzcnAtPmx1Z19leHBpcnkgPCBORlNEX01PTk9TRUMpCisJCQkJCWJyZWFrOworCQkJCWhw MiA9IE5GU0dST1VQSEFTSCh1c3JwLT5sdWdfZ2lkKTsKKwkJCQltdHhfbG9jaygmaHAyLT5tdHgp OworCQkJCVRBSUxRX1JFTU9WRSgmaHAyLT5sdWdoZWFkLCB1c3JwLCBsdWdfbnVtaGFzaCk7CisJ CQkJVEFJTFFfSU5TRVJUX1RBSUwoJmhwMi0+bHVnaGVhZCwgdXNycCwKKwkJCQkgICAgbHVnX251 bWhhc2gpOworCQkJCSpnaWRwID0gdXNycC0+bHVnX2dpZDsKKwkJCQltdHhfdW5sb2NrKCZocDIt Pm10eCk7CisJCQkJbXR4X3VubG9jaygmaHAtPm10eCk7CisJCQkJZXJyb3IgPSAwOworCQkJCWdv dG8gb3V0OworCQkJfQorCQl9CisJCW10eF91bmxvY2soJmhwLT5tdHgpOworCQljbnQrKzsKKwkJ cmV0ID0gbmZzcnZfZ2V0dXNlcihSUENORlNVU0VSRF9HRVRHUk9VUCwgKHVpZF90KTAsIChnaWRf dCkwLAorCQkgICAgc3RyLCBwKTsKKwkJaWYgKHJldCA9PSAwICYmIGNudCA8IDIpCisJCQlnb3Rv IHRyeWFnYWluOwogCX0KLQlORlNVTkxPQ0tOQU1FSUQoKTsKLQljbnQrKzsKLQlyZXQgPSBuZnNy dl9nZXR1c2VyKFJQQ05GU1VTRVJEX0dFVEdST1VQLCAodWlkX3QpMCwgKGdpZF90KTAsCi0JICAg IHN0ciwgcCk7Ci0JaWYgKHJldCA9PSAwICYmIGNudCA8IDIpCi0JCWdvdG8gdHJ5YWdhaW47CiAJ ZXJyb3IgPSBORlNFUlJfQkFET1dORVI7CiAKIG91dDoKQEAgLTMxMDEsMTExICszMTY1LDIxOSBA QCBBUFBMRVNUQVRJQyBpbnQKIG5mc3N2Y19pZG5hbWUoc3RydWN0IG5mc2RfaWRhcmdzICpuaWRw KQogewogCXN0cnVjdCBuZnN1c3JncnAgKm51c3JwLCAqdXNycCwgKm5ld3VzcnA7Ci0Jc3RydWN0 IG5mc3VzZXJoYXNoaGVhZCAqaHA7Ci0JaW50IGk7CisJc3RydWN0IG5mc3J2X2x1Z2hhc2ggKmhw X25hbWUsICpocF9pZG51bSwgKnRocDsKKwlpbnQgaSwgZ3JvdXBfbG9ja2VkLCBncm91cG5hbWVf bG9ja2VkLCB1c2VyX2xvY2tlZCwgdXNlcm5hbWVfbG9ja2VkOwogCWludCBlcnJvciA9IDA7CiAJ dV9jaGFyICpjcDsKKwlnaWRfdCAqZ3JwczsKKwlzdHJ1Y3QgdWNyZWQgKmNyOworCXN0YXRpYyBp bnQgb25ldGhyZWFkID0gMDsKKwlzdGF0aWMgdGltZV90IGxhc3R0aW1lID0gMDsKIAogCWlmIChu aWRwLT5uaWRfZmxhZyAmIE5GU0lEX0lOSVRJQUxJWkUpIHsKLQkgICAgY3AgPSAodV9jaGFyICop bWFsbG9jKG5pZHAtPm5pZF9uYW1lbGVuICsgMSwKLQkJTV9ORlNTVFJJTkcsIE1fV0FJVE9LKTsK LQkgICAgZXJyb3IgPSBjb3B5aW4oQ0FTVF9VU0VSX0FERFJfVChuaWRwLT5uaWRfbmFtZSksIGNw LAotCQluaWRwLT5uaWRfbmFtZWxlbik7Ci0JICAgIE5GU0xPQ0tOQU1FSUQoKTsKLQkgICAgaWYg KG5mc3J2X2Ruc25hbWUpIHsKKwkJY3AgPSAodV9jaGFyICopbWFsbG9jKG5pZHAtPm5pZF9uYW1l bGVuICsgMSwgTV9ORlNTVFJJTkcsCisJCSAgICBNX1dBSVRPSyk7CisJCWVycm9yID0gY29weWlu KENBU1RfVVNFUl9BRERSX1QobmlkcC0+bmlkX25hbWUpLCBjcCwKKwkJICAgIG5pZHAtPm5pZF9u YW1lbGVuKTsKKwkJaWYgKGVycm9yICE9IDApIHsKKwkJCWZyZWUoY3AsIE1fTkZTU1RSSU5HKTsK KwkJCWdvdG8gb3V0OworCQl9CisJCWlmIChhdG9taWNfY21wc2V0X2FjcV9pbnQoJm5mc3J2X2Ru c25hbWVsZW4sIDAsIDApID09IDApIHsKKwkJCS8qCisJCQkgKiBGcmVlIHVwIGFsbCB0aGUgb2xk IHN0dWZmIGFuZCByZWluaXRpYWxpemUgaGFzaAorCQkJICogbGlzdHMuICBBbGwgbXV0ZXhlcyBm b3IgYm90aCBsaXN0cyBtdXN0IGJlIGxvY2tlZCwKKwkJCSAqIHdpdGggdGhlIHVzZXIvZ3JvdXAg bmFtZSBvbmVzIGJlZm9yZSB0aGUgdWlkL2dpZAorCQkJICogb25lcywgdG8gYXZvaWQgYSBMT1Iu CisJCQkgKi8KKwkJCWZvciAoaSA9IDA7IGkgPCBuZnNydl9sdWdoYXNoc2l6ZTsgaSsrKQorCQkJ CW10eF9sb2NrKCZuZnN1c2VybmFtZWhhc2hbaV0ubXR4KTsKKwkJCWZvciAoaSA9IDA7IGkgPCBu ZnNydl9sdWdoYXNoc2l6ZTsgaSsrKQorCQkJCW10eF9sb2NrKCZuZnN1c2VyaGFzaFtpXS5tdHgp OworCQkJZm9yIChpID0gMDsgaSA8IG5mc3J2X2x1Z2hhc2hzaXplOyBpKyspCisJCQkJVEFJTFFf Rk9SRUFDSF9TQUZFKHVzcnAsCisJCQkJICAgICZuZnN1c2VyaGFzaFtpXS5sdWdoZWFkLCBsdWdf bnVtaGFzaCwgbnVzcnApCisJCQkJCW5mc3J2X3JlbW92ZXVzZXIodXNycCwgMSk7CisJCQlmb3Ig KGkgPSAwOyBpIDwgbmZzcnZfbHVnaGFzaHNpemU7IGkrKykKKwkJCQltdHhfdW5sb2NrKCZuZnN1 c2VyaGFzaFtpXS5tdHgpOworCQkJZm9yIChpID0gMDsgaSA8IG5mc3J2X2x1Z2hhc2hzaXplOyBp KyspCisJCQkJbXR4X3VubG9jaygmbmZzdXNlcm5hbWVoYXNoW2ldLm10eCk7CisJCQlmb3IgKGkg PSAwOyBpIDwgbmZzcnZfbHVnaGFzaHNpemU7IGkrKykKKwkJCQltdHhfbG9jaygmbmZzZ3JvdXBu YW1laGFzaFtpXS5tdHgpOworCQkJZm9yIChpID0gMDsgaSA8IG5mc3J2X2x1Z2hhc2hzaXplOyBp KyspCisJCQkJbXR4X2xvY2soJm5mc2dyb3VwaGFzaFtpXS5tdHgpOworCQkJZm9yIChpID0gMDsg aSA8IG5mc3J2X2x1Z2hhc2hzaXplOyBpKyspCisJCQkJVEFJTFFfRk9SRUFDSF9TQUZFKHVzcnAs CisJCQkJICAgICZuZnNncm91cGhhc2hbaV0ubHVnaGVhZCwgbHVnX251bWhhc2gsCisJCQkJICAg IG51c3JwKQorCQkJCQluZnNydl9yZW1vdmV1c2VyKHVzcnAsIDApOworCQkJZm9yIChpID0gMDsg aSA8IG5mc3J2X2x1Z2hhc2hzaXplOyBpKyspCisJCQkJbXR4X3VubG9jaygmbmZzZ3JvdXBoYXNo W2ldLm10eCk7CisJCQlmb3IgKGkgPSAwOyBpIDwgbmZzcnZfbHVnaGFzaHNpemU7IGkrKykKKwkJ CQltdHhfdW5sb2NrKCZuZnNncm91cG5hbWVoYXNoW2ldLm10eCk7CisJCQlmcmVlKG5mc3J2X2Ru c25hbWUsIE1fTkZTU1RSSU5HKTsKKwkJCW5mc3J2X2Ruc25hbWUgPSBOVUxMOworCQl9CisJCWlm IChuZnN1c2VyaGFzaCA9PSBOVUxMKSB7CisJCQkvKiBBbGxvY2F0ZSB0aGUgaGFzaCB0YWJsZXMu ICovCisJCQluZnN1c2VyaGFzaCA9IG1hbGxvYyhzaXplb2Yoc3RydWN0IG5mc3J2X2x1Z2hhc2gp ICoKKwkJCSAgICBuZnNydl9sdWdoYXNoc2l6ZSwgTV9ORlNVU0VSR1JPVVAsIE1fV0FJVE9LIHwK KwkJCSAgICBNX1pFUk8pOworCQkJZm9yIChpID0gMDsgaSA8IG5mc3J2X2x1Z2hhc2hzaXplOyBp KyspCisJCQkJbXR4X2luaXQoJm5mc3VzZXJoYXNoW2ldLm10eCwgIm5mc3VzZXJoYXNoIiwKKwkJ CQkgICAgTlVMTCwgTVRYX0RFRiB8IE1UWF9EVVBPSyk7CisJCQluZnN1c2VybmFtZWhhc2ggPSBt YWxsb2Moc2l6ZW9mKHN0cnVjdCBuZnNydl9sdWdoYXNoKSAqCisJCQkgICAgbmZzcnZfbHVnaGFz aHNpemUsIE1fTkZTVVNFUkdST1VQLCBNX1dBSVRPSyB8CisJCQkgICAgTV9aRVJPKTsKKwkJCWZv ciAoaSA9IDA7IGkgPCBuZnNydl9sdWdoYXNoc2l6ZTsgaSsrKQorCQkJCW10eF9pbml0KCZuZnN1 c2VybmFtZWhhc2hbaV0ubXR4LAorCQkJCSAgICAibmZzdXNlcm5hbWVoYXNoIiwgTlVMTCwgTVRY X0RFRiB8CisJCQkJICAgIE1UWF9EVVBPSyk7CisJCQluZnNncm91cGhhc2ggPSBtYWxsb2Moc2l6 ZW9mKHN0cnVjdCBuZnNydl9sdWdoYXNoKSAqCisJCQkgICAgbmZzcnZfbHVnaGFzaHNpemUsIE1f TkZTVVNFUkdST1VQLCBNX1dBSVRPSyB8CisJCQkgICAgTV9aRVJPKTsKKwkJCWZvciAoaSA9IDA7 IGkgPCBuZnNydl9sdWdoYXNoc2l6ZTsgaSsrKQorCQkJCW10eF9pbml0KCZuZnNncm91cGhhc2hb aV0ubXR4LCAibmZzZ3JvdXBoYXNoIiwKKwkJCQkgICAgTlVMTCwgTVRYX0RFRiB8IE1UWF9EVVBP Syk7CisJCQluZnNncm91cG5hbWVoYXNoID0gbWFsbG9jKHNpemVvZihzdHJ1Y3QgbmZzcnZfbHVn aGFzaCkgKgorCQkJICAgIG5mc3J2X2x1Z2hhc2hzaXplLCBNX05GU1VTRVJHUk9VUCwgTV9XQUlU T0sgfAorCQkJICAgIE1fWkVSTyk7CisJCQlmb3IgKGkgPSAwOyBpIDwgbmZzcnZfbHVnaGFzaHNp emU7IGkrKykKKwkJCSAgICBtdHhfaW5pdCgmbmZzZ3JvdXBuYW1laGFzaFtpXS5tdHgsCisJCQkg ICAgIm5mc2dyb3VwbmFtZWhhc2giLCBOVUxMLCBNVFhfREVGIHwgTVRYX0RVUE9LKTsKKwkJfQor CQkvKiAoUmUpaW5pdGlhbGl6ZSB0aGUgbGlzdCBoZWFkcy4gKi8KKwkJZm9yIChpID0gMDsgaSA8 IG5mc3J2X2x1Z2hhc2hzaXplOyBpKyspCisJCQlUQUlMUV9JTklUKCZuZnN1c2VyaGFzaFtpXS5s dWdoZWFkKTsKKwkJZm9yIChpID0gMDsgaSA8IG5mc3J2X2x1Z2hhc2hzaXplOyBpKyspCisJCQlU QUlMUV9JTklUKCZuZnN1c2VybmFtZWhhc2hbaV0ubHVnaGVhZCk7CisJCWZvciAoaSA9IDA7IGkg PCBuZnNydl9sdWdoYXNoc2l6ZTsgaSsrKQorCQkJVEFJTFFfSU5JVCgmbmZzZ3JvdXBoYXNoW2ld Lmx1Z2hlYWQpOworCQlmb3IgKGkgPSAwOyBpIDwgbmZzcnZfbHVnaGFzaHNpemU7IGkrKykKKwkJ CVRBSUxRX0lOSVQoJm5mc2dyb3VwbmFtZWhhc2hbaV0ubHVnaGVhZCk7CisKIAkJLyoKLQkJICog RnJlZSB1cCBhbGwgdGhlIG9sZCBzdHVmZiBhbmQgcmVpbml0aWFsaXplIGhhc2ggbGlzdHMuCisJ CSAqIFB1dCBuYW1lIGluICJETlMiIHN0cmluZy4KIAkJICovCi0JCVRBSUxRX0ZPUkVBQ0hfU0FG RSh1c3JwLCAmbmZzdXNlcmxydWhlYWQsIGx1Z19scnUsIG51c3JwKSB7Ci0JCQluZnNydl9yZW1v dmV1c2VyKHVzcnApOwotCQl9Ci0JCWZyZWUobmZzcnZfZG5zbmFtZSwgTV9ORlNTVFJJTkcpOwot CQluZnNydl9kbnNuYW1lID0gTlVMTDsKLQkgICAgfQotCSAgICBUQUlMUV9JTklUKCZuZnN1c2Vy bHJ1aGVhZCk7Ci0JICAgIGZvciAoaSA9IDA7IGkgPCBORlNVU0VSSEFTSFNJWkU7IGkrKykKLQkJ TElTVF9JTklUKCZuZnN1c2VyaGFzaFtpXSk7Ci0JICAgIGZvciAoaSA9IDA7IGkgPCBORlNHUk9V UEhBU0hTSVpFOyBpKyspCi0JCUxJU1RfSU5JVCgmbmZzZ3JvdXBoYXNoW2ldKTsKLQkgICAgZm9y IChpID0gMDsgaSA8IE5GU1VTRVJIQVNIU0laRTsgaSsrKQotCQlMSVNUX0lOSVQoJm5mc3VzZXJu YW1laGFzaFtpXSk7Ci0JICAgIGZvciAoaSA9IDA7IGkgPCBORlNHUk9VUEhBU0hTSVpFOyBpKysp Ci0JCUxJU1RfSU5JVCgmbmZzZ3JvdXBuYW1laGFzaFtpXSk7Ci0KLQkgICAgLyoKLQkgICAgICog UHV0IG5hbWUgaW4gIkROUyIgc3RyaW5nLgotCSAgICAgKi8KLQkgICAgaWYgKCFlcnJvcikgewog CQluZnNydl9kbnNuYW1lID0gY3A7Ci0JCW5mc3J2X2Ruc25hbWVsZW4gPSBuaWRwLT5uaWRfbmFt ZWxlbjsKIAkJbmZzcnZfZGVmYXVsdHVpZCA9IG5pZHAtPm5pZF91aWQ7CiAJCW5mc3J2X2RlZmF1 bHRnaWQgPSBuaWRwLT5uaWRfZ2lkOwogCQluZnNydl91c2VyY250ID0gMDsKIAkJbmZzcnZfdXNl cm1heCA9IG5pZHAtPm5pZF91c2VybWF4OwotCSAgICB9Ci0JICAgIE5GU1VOTE9DS05BTUVJRCgp OwotCSAgICBpZiAoZXJyb3IpCi0JCWZyZWUoY3AsIE1fTkZTU1RSSU5HKTsKLQkgICAgZ290byBv dXQ7CisJCWF0b21pY19zdG9yZV9yZWxfaW50KCZuZnNydl9kbnNuYW1lbGVuLCBuaWRwLT5uaWRf bmFtZWxlbik7CisJCWdvdG8gb3V0OwogCX0KIAogCS8qCiAJICogbWFsbG9jIHRoZSBuZXcgb25l IG5vdywgc28gYW55IHBvdGVudGlhbCBzbGVlcCBvY2N1cnMgYmVmb3JlCiAJICogbWFuaXB1bGF0 aW9uIG9mIHRoZSBsaXN0cy4KIAkgKi8KLQlNQUxMT0MobmV3dXNycCwgc3RydWN0IG5mc3Vzcmdy cCAqLCBzaXplb2YgKHN0cnVjdCBuZnN1c3JncnApICsKLQkgICAgbmlkcC0+bmlkX25hbWVsZW4s IE1fTkZTVVNFUkdST1VQLCBNX1dBSVRPSyk7CisJbmV3dXNycCA9IG1hbGxvYyhzaXplb2Yoc3Ry dWN0IG5mc3VzcmdycCkgKyBuaWRwLT5uaWRfbmFtZWxlbiwKKwkgICAgTV9ORlNVU0VSR1JPVVAs IE1fV0FJVE9LIHwgTV9aRVJPKTsKIAllcnJvciA9IGNvcHlpbihDQVNUX1VTRVJfQUREUl9UKG5p ZHAtPm5pZF9uYW1lKSwgbmV3dXNycC0+bHVnX25hbWUsCiAJICAgIG5pZHAtPm5pZF9uYW1lbGVu KTsKKwlpZiAoZXJyb3IgPT0gMCAmJiBuaWRwLT5uaWRfbmdyb3VwID4gMCAmJgorCSAgICAobmlk cC0+bmlkX2ZsYWcgJiBORlNJRF9BRERVSUQpICE9IDApIHsKKwkJZ3JwcyA9IG1hbGxvYyhzaXpl b2YoZ2lkX3QpICogbmlkcC0+bmlkX25ncm91cCwgTV9URU1QLAorCQkgICAgTV9XQUlUT0spOwor CQllcnJvciA9IGNvcHlpbihDQVNUX1VTRVJfQUREUl9UKG5pZHAtPm5pZF9ncnBzKSwgZ3JwcywK KwkJICAgIHNpemVvZihnaWRfdCkgKiBuaWRwLT5uaWRfbmdyb3VwKTsKKwkJaWYgKGVycm9yID09 IDApIHsKKwkJCS8qCisJCQkgKiBDcmVhdGUgYSBjcmVkZW50aWFsIGp1c3QgbGlrZSBzdmNfZ2V0 Y3JlZCgpLAorCQkJICogYnV0IHVzaW5nIHRoZSBncm91cCBsaXN0IHByb3ZpZGVkLgorCQkJICov CisJCQljciA9IGNyZ2V0KCk7CisJCQljci0+Y3JfdWlkID0gY3ItPmNyX3J1aWQgPSBjci0+Y3Jf c3Z1aWQgPSBuaWRwLT5uaWRfdWlkOworCQkJY3JzZXRncm91cHMoY3IsIG5pZHAtPm5pZF9uZ3Jv dXAsIGdycHMpOworCQkJY3ItPmNyX3JnaWQgPSBjci0+Y3Jfc3ZnaWQgPSBjci0+Y3JfZ3JvdXBz WzBdOworCQkJY3ItPmNyX3ByaXNvbiA9ICZwcmlzb24wOworCQkJcHJpc29uX2hvbGQoY3ItPmNy X3ByaXNvbik7CisjaWZkZWYgTUFDCisJCQltYWNfY3JlZF9hc3NvY2lhdGVfbmZzZChjcik7Cisj ZW5kaWYKKwkJCW5ld3VzcnAtPmx1Z19jcmVkID0gY3I7CisJCX0KKwkJZnJlZShncnBzLCBNX1RF TVApOworCX0KIAlpZiAoZXJyb3IpIHsKLQkJZnJlZSgoY2FkZHJfdCluZXd1c3JwLCBNX05GU1VT RVJHUk9VUCk7CisJCWZyZWUobmV3dXNycCwgTV9ORlNVU0VSR1JPVVApOwogCQlnb3RvIG91dDsK IAl9CiAJbmV3dXNycC0+bHVnX25hbWVsZW4gPSBuaWRwLT5uaWRfbmFtZWxlbjsKIAotCU5GU0xP Q0tOQU1FSUQoKTsKKwkvKgorCSAqIFRoZSBsb2NrIG9yZGVyIGlzIHVzZXJuYW1lWzBdLT5bbmZz cnZfbHVnaGFzaHNpemUgLSAxXSBmb2xsb3dlZAorCSAqIGJ5IHVpZFswXS0+W25mc3J2X2x1Z2hh c2hzaXplIC0gMV0sIHdpdGggdGhlIHNhbWUgZm9yIGdyb3VwLgorCSAqIFRoZSBmbGFncyB1c2Vy X2xvY2tlZCwgdXNlcm5hbWVfbG9ja2VkLCBncm91cF9sb2NrZWQgYW5kCisJICogZ3JvdXBuYW1l X2xvY2tlZCBhcmUgc2V0IHRvIGluZGljYXRlIGFsbCBvZiB0aG9zZSBoYXNoIGxpc3RzIGFyZQor CSAqIGxvY2tlZC4gaHBfbmFtZSAhPSBOVUxMICBhbmQgaHBfaWRudW0gIT0gTlVMTCBpbmRpY2F0 ZXMgdGhhdAorCSAqIHRoZSByZXNwZWN0aXZlIG9uZSBtdXRleCBpcyBsb2NrZWQuCisJICovCisJ dXNlcl9sb2NrZWQgPSB1c2VybmFtZV9sb2NrZWQgPSBncm91cF9sb2NrZWQgPSBncm91cG5hbWVf bG9ja2VkID0gMDsKKwlocF9uYW1lID0gaHBfaWRudW0gPSBOVUxMOworCiAJLyoKIAkgKiBEZWxl dGUgb2xkIGVudHJpZXMsIGFzIHJlcXVpcmVkLgogCSAqLwogCWlmIChuaWRwLT5uaWRfZmxhZyAm IChORlNJRF9ERUxVSUQgfCBORlNJRF9BRERVSUQpKSB7Ci0JCWhwID0gTkZTVVNFUkhBU0gobmlk cC0+bmlkX3VpZCk7Ci0JCUxJU1RfRk9SRUFDSF9TQUZFKHVzcnAsIGhwLCBsdWdfbnVtaGFzaCwg bnVzcnApIHsKKwkJLyogTXVzdCBsb2NrIGFsbCB1c2VybmFtZSBoYXNoIGxpc3RzIGZpcnN0LCB0 byBhdm9pZCBhIExPUi4gKi8KKwkJZm9yIChpID0gMDsgaSA8IG5mc3J2X2x1Z2hhc2hzaXplOyBp KyspCisJCQltdHhfbG9jaygmbmZzdXNlcm5hbWVoYXNoW2ldLm10eCk7CisJCXVzZXJuYW1lX2xv Y2tlZCA9IDE7CisJCWhwX2lkbnVtID0gTkZTVVNFUkhBU0gobmlkcC0+bmlkX3VpZCk7CisJCW10 eF9sb2NrKCZocF9pZG51bS0+bXR4KTsKKwkJVEFJTFFfRk9SRUFDSF9TQUZFKHVzcnAsICZocF9p ZG51bS0+bHVnaGVhZCwgbHVnX251bWhhc2gsCisJCSAgICBudXNycCkgewogCQkJaWYgKHVzcnAt Pmx1Z191aWQgPT0gbmlkcC0+bmlkX3VpZCkKLQkJCQluZnNydl9yZW1vdmV1c2VyKHVzcnApOwor CQkJCW5mc3J2X3JlbW92ZXVzZXIodXNycCwgMSk7CiAJCX0KLQl9Ci0JaWYgKG5pZHAtPm5pZF9m bGFnICYgKE5GU0lEX0RFTFVTRVJOQU1FIHwgTkZTSURfQUREVVNFUk5BTUUpKSB7Ci0JCWhwID0g TkZTVVNFUk5BTUVIQVNIKG5ld3VzcnAtPmx1Z19uYW1lLCBuZXd1c3JwLT5sdWdfbmFtZWxlbik7 Ci0JCUxJU1RfRk9SRUFDSF9TQUZFKHVzcnAsIGhwLCBsdWdfbmFtZWhhc2gsIG51c3JwKSB7CisJ fSBlbHNlIGlmIChuaWRwLT5uaWRfZmxhZyAmIChORlNJRF9ERUxVU0VSTkFNRSB8IE5GU0lEX0FE RFVTRVJOQU1FKSkgeworCQlocF9uYW1lID0gTkZTVVNFUk5BTUVIQVNIKG5ld3VzcnAtPmx1Z19u YW1lLAorCQkgICAgbmV3dXNycC0+bHVnX25hbWVsZW4pOworCQltdHhfbG9jaygmaHBfbmFtZS0+ bXR4KTsKKwkJVEFJTFFfRk9SRUFDSF9TQUZFKHVzcnAsICZocF9uYW1lLT5sdWdoZWFkLCBsdWdf bmFtZWhhc2gsCisJCSAgICBudXNycCkgewogCQkJaWYgKHVzcnAtPmx1Z19uYW1lbGVuID09IG5l d3VzcnAtPmx1Z19uYW1lbGVuICYmCiAJCQkgICAgIU5GU0JDTVAodXNycC0+bHVnX25hbWUsIG5l d3VzcnAtPmx1Z19uYW1lLAotCQkJICAgIHVzcnAtPmx1Z19uYW1lbGVuKSkKLQkJCQluZnNydl9y ZW1vdmV1c2VyKHVzcnApOwotCQl9Ci0JfQotCWlmIChuaWRwLT5uaWRfZmxhZyAmIChORlNJRF9E RUxHSUQgfCBORlNJRF9BRERHSUQpKSB7Ci0JCWhwID0gTkZTR1JPVVBIQVNIKG5pZHAtPm5pZF9n aWQpOwotCQlMSVNUX0ZPUkVBQ0hfU0FGRSh1c3JwLCBocCwgbHVnX251bWhhc2gsIG51c3JwKSB7 CisJCQkgICAgdXNycC0+bHVnX25hbWVsZW4pKSB7CisJCQkJdGhwID0gTkZTVVNFUkhBU0godXNy cC0+bHVnX3VpZCk7CisJCQkJbXR4X2xvY2soJnRocC0+bXR4KTsKKwkJCQluZnNydl9yZW1vdmV1 c2VyKHVzcnAsIDEpOworCQkJCW10eF91bmxvY2soJnRocC0+bXR4KTsKKwkJCX0KKwkJfQorCQlo cF9pZG51bSA9IE5GU1VTRVJIQVNIKG5pZHAtPm5pZF91aWQpOworCQltdHhfbG9jaygmaHBfaWRu dW0tPm10eCk7CisJfSBlbHNlIGlmIChuaWRwLT5uaWRfZmxhZyAmIChORlNJRF9ERUxHSUQgfCBO RlNJRF9BRERHSUQpKSB7CisJCS8qIE11c3QgbG9jayBhbGwgZ3JvdXBuYW1lIGhhc2ggbGlzdHMg Zmlyc3QsIHRvIGF2b2lkIGEgTE9SLiAqLworCQlmb3IgKGkgPSAwOyBpIDwgbmZzcnZfbHVnaGFz aHNpemU7IGkrKykKKwkJCW10eF9sb2NrKCZuZnNncm91cG5hbWVoYXNoW2ldLm10eCk7CisJCWdy b3VwbmFtZV9sb2NrZWQgPSAxOworCQlocF9pZG51bSA9IE5GU0dST1VQSEFTSChuaWRwLT5uaWRf Z2lkKTsKKwkJbXR4X2xvY2soJmhwX2lkbnVtLT5tdHgpOworCQlUQUlMUV9GT1JFQUNIX1NBRkUo dXNycCwgJmhwX2lkbnVtLT5sdWdoZWFkLCBsdWdfbnVtaGFzaCwKKwkJICAgIG51c3JwKSB7CiAJ CQlpZiAodXNycC0+bHVnX2dpZCA9PSBuaWRwLT5uaWRfZ2lkKQotCQkJCW5mc3J2X3JlbW92ZXVz ZXIodXNycCk7CisJCQkJbmZzcnZfcmVtb3ZldXNlcih1c3JwLCAwKTsKIAkJfQotCX0KLQlpZiAo bmlkcC0+bmlkX2ZsYWcgJiAoTkZTSURfREVMR1JPVVBOQU1FIHwgTkZTSURfQURER1JPVVBOQU1F KSkgewotCQlocCA9IE5GU0dST1VQTkFNRUhBU0gobmV3dXNycC0+bHVnX25hbWUsIG5ld3VzcnAt Pmx1Z19uYW1lbGVuKTsKLQkJTElTVF9GT1JFQUNIX1NBRkUodXNycCwgaHAsIGx1Z19uYW1laGFz aCwgbnVzcnApIHsKKwl9IGVsc2UgaWYgKG5pZHAtPm5pZF9mbGFnICYgKE5GU0lEX0RFTEdST1VQ TkFNRSB8IE5GU0lEX0FEREdST1VQTkFNRSkpIHsKKwkJaHBfbmFtZSA9IE5GU0dST1VQTkFNRUhB U0gobmV3dXNycC0+bHVnX25hbWUsCisJCSAgICBuZXd1c3JwLT5sdWdfbmFtZWxlbik7CisJCW10 eF9sb2NrKCZocF9uYW1lLT5tdHgpOworCQlUQUlMUV9GT1JFQUNIX1NBRkUodXNycCwgJmhwX25h bWUtPmx1Z2hlYWQsIGx1Z19uYW1laGFzaCwKKwkJICAgIG51c3JwKSB7CiAJCQlpZiAodXNycC0+ bHVnX25hbWVsZW4gPT0gbmV3dXNycC0+bHVnX25hbWVsZW4gJiYKIAkJCSAgICAhTkZTQkNNUCh1 c3JwLT5sdWdfbmFtZSwgbmV3dXNycC0+bHVnX25hbWUsCi0JCQkgICAgdXNycC0+bHVnX25hbWVs ZW4pKQotCQkJCW5mc3J2X3JlbW92ZXVzZXIodXNycCk7CisJCQkgICAgdXNycC0+bHVnX25hbWVs ZW4pKSB7CisJCQkJdGhwID0gTkZTR1JPVVBIQVNIKHVzcnAtPmx1Z19naWQpOworCQkJCW10eF9s b2NrKCZ0aHAtPm10eCk7CisJCQkJbmZzcnZfcmVtb3ZldXNlcih1c3JwLCAwKTsKKwkJCQltdHhf dW5sb2NrKCZ0aHAtPm10eCk7CisJCQl9CiAJCX0KLQl9Ci0JVEFJTFFfRk9SRUFDSF9TQUZFKHVz cnAsICZuZnN1c2VybHJ1aGVhZCwgbHVnX2xydSwgbnVzcnApIHsKLQkJaWYgKHVzcnAtPmx1Z19l eHBpcnkgPCBORlNEX01PTk9TRUMpCi0JCQluZnNydl9yZW1vdmV1c2VyKHVzcnApOwotCX0KLQl3 aGlsZSAobmZzcnZfdXNlcmNudCA+PSBuZnNydl91c2VybWF4KSB7Ci0JCXVzcnAgPSBUQUlMUV9G SVJTVCgmbmZzdXNlcmxydWhlYWQpOwotCQluZnNydl9yZW1vdmV1c2VyKHVzcnApOworCQlocF9p ZG51bSA9IE5GU0dST1VQSEFTSChuaWRwLT5uaWRfZ2lkKTsKKwkJbXR4X2xvY2soJmhwX2lkbnVt LT5tdHgpOwogCX0KIAogCS8qCkBAIC0zMjE3LDIzICszMzg5LDEyOSBAQCBuZnNzdmNfaWRuYW1l KHN0cnVjdCBuZnNkX2lkYXJncyAqbmlkcCkKIAkJbmV3dXNycC0+bHVnX2V4cGlyeSA9IE5GU0Rf TU9OT1NFQyArIDU7CiAJaWYgKG5pZHAtPm5pZF9mbGFnICYgKE5GU0lEX0FERFVJRCB8IE5GU0lE X0FERFVTRVJOQU1FKSkgewogCQluZXd1c3JwLT5sdWdfdWlkID0gbmlkcC0+bmlkX3VpZDsKLQkJ TElTVF9JTlNFUlRfSEVBRChORlNVU0VSSEFTSChuZXd1c3JwLT5sdWdfdWlkKSwgbmV3dXNycCwK LQkJICAgIGx1Z19udW1oYXNoKTsKLQkJTElTVF9JTlNFUlRfSEVBRChORlNVU0VSTkFNRUhBU0go bmV3dXNycC0+bHVnX25hbWUsCi0JCSAgICBuZXd1c3JwLT5sdWdfbmFtZWxlbiksIG5ld3VzcnAs IGx1Z19uYW1laGFzaCk7Ci0JCVRBSUxRX0lOU0VSVF9UQUlMKCZuZnN1c2VybHJ1aGVhZCwgbmV3 dXNycCwgbHVnX2xydSk7Ci0JCW5mc3J2X3VzZXJjbnQrKzsKKwkJdGhwID0gTkZTVVNFUkhBU0go bmV3dXNycC0+bHVnX3VpZCk7CisJCW10eF9hc3NlcnQoJnRocC0+bXR4LCBNQV9PV05FRCk7CisJ CVRBSUxRX0lOU0VSVF9UQUlMKCZ0aHAtPmx1Z2hlYWQsIG5ld3VzcnAsIGx1Z19udW1oYXNoKTsK KwkJdGhwID0gTkZTVVNFUk5BTUVIQVNIKG5ld3VzcnAtPmx1Z19uYW1lLCBuZXd1c3JwLT5sdWdf bmFtZWxlbik7CisJCW10eF9hc3NlcnQoJnRocC0+bXR4LCBNQV9PV05FRCk7CisJCVRBSUxRX0lO U0VSVF9UQUlMKCZ0aHAtPmx1Z2hlYWQsIG5ld3VzcnAsIGx1Z19uYW1laGFzaCk7CisJCWF0b21p Y19hZGRfaW50KCZuZnNydl91c2VyY250LCAxKTsKIAl9IGVsc2UgaWYgKG5pZHAtPm5pZF9mbGFn ICYgKE5GU0lEX0FEREdJRCB8IE5GU0lEX0FEREdST1VQTkFNRSkpIHsKIAkJbmV3dXNycC0+bHVn X2dpZCA9IG5pZHAtPm5pZF9naWQ7Ci0JCUxJU1RfSU5TRVJUX0hFQUQoTkZTR1JPVVBIQVNIKG5l d3VzcnAtPmx1Z19naWQpLCBuZXd1c3JwLAotCQkgICAgbHVnX251bWhhc2gpOwotCQlMSVNUX0lO U0VSVF9IRUFEKE5GU0dST1VQTkFNRUhBU0gobmV3dXNycC0+bHVnX25hbWUsCi0JCSAgICBuZXd1 c3JwLT5sdWdfbmFtZWxlbiksIG5ld3VzcnAsIGx1Z19uYW1laGFzaCk7Ci0JCVRBSUxRX0lOU0VS VF9UQUlMKCZuZnN1c2VybHJ1aGVhZCwgbmV3dXNycCwgbHVnX2xydSk7Ci0JCW5mc3J2X3VzZXJj bnQrKzsKLQl9IGVsc2UKLQkJRlJFRSgoY2FkZHJfdCluZXd1c3JwLCBNX05GU1VTRVJHUk9VUCk7 Ci0JTkZTVU5MT0NLTkFNRUlEKCk7CisJCXRocCA9IE5GU0dST1VQSEFTSChuZXd1c3JwLT5sdWdf Z2lkKTsKKwkJbXR4X2Fzc2VydCgmdGhwLT5tdHgsIE1BX09XTkVEKTsKKwkJVEFJTFFfSU5TRVJU X1RBSUwoJnRocC0+bHVnaGVhZCwgbmV3dXNycCwgbHVnX251bWhhc2gpOworCQl0aHAgPSBORlNH Uk9VUE5BTUVIQVNIKG5ld3VzcnAtPmx1Z19uYW1lLCBuZXd1c3JwLT5sdWdfbmFtZWxlbik7CisJ CW10eF9hc3NlcnQoJnRocC0+bXR4LCBNQV9PV05FRCk7CisJCVRBSUxRX0lOU0VSVF9UQUlMKCZ0 aHAtPmx1Z2hlYWQsIG5ld3VzcnAsIGx1Z19uYW1laGFzaCk7CisJCWF0b21pY19hZGRfaW50KCZu ZnNydl91c2VyY250LCAxKTsKKwl9IGVsc2UgeworCQlpZiAobmV3dXNycC0+bHVnX2NyZWQgIT0g TlVMTCkKKwkJCWNyZnJlZShuZXd1c3JwLT5sdWdfY3JlZCk7CisJCWZyZWUobmV3dXNycCwgTV9O RlNVU0VSR1JPVVApOworCX0KKworCS8qCisJICogT25jZSBwZXIgc2Vjb25kLCBhbGxvdyBvbmUg dGhyZWFkIHRvIHRyaW0gdGhlIGNhY2hlLgorCSAqLworCWlmIChsYXN0dGltZSA8IE5GU0RfTU9O T1NFQyAmJgorCSAgICBhdG9taWNfY21wc2V0X2FjcV9pbnQoJm9uZXRocmVhZCwgMCwgMSkgIT0g MCkgeworCQkvKgorCQkgKiBGaXJzdCwgdW5sb2NrIHRoZSBzaW5nbGUgbXV0ZXhlcywgc28gdGhh dCBhbGwgZW50cmllcworCQkgKiBjYW4gYmUgbG9ja2VkIGFuZCBhbnkgTE9SIGlzIGF2b2lkZWQu CisJCSAqLworCQlpZiAoaHBfbmFtZSAhPSBOVUxMKSB7CisJCQltdHhfdW5sb2NrKCZocF9uYW1l LT5tdHgpOworCQkJaHBfbmFtZSA9IE5VTEw7CisJCX0KKwkJaWYgKGhwX2lkbnVtICE9IE5VTEwp IHsKKwkJCW10eF91bmxvY2soJmhwX2lkbnVtLT5tdHgpOworCQkJaHBfaWRudW0gPSBOVUxMOwor CQl9CisKKwkJaWYgKChuaWRwLT5uaWRfZmxhZyAmIChORlNJRF9ERUxVSUQgfCBORlNJRF9BRERV SUQgfAorCQkgICAgTkZTSURfREVMVVNFUk5BTUUgfCBORlNJRF9BRERVU0VSTkFNRSkpICE9IDAp IHsKKwkJCWlmICh1c2VybmFtZV9sb2NrZWQgPT0gMCkgeworCQkJCWZvciAoaSA9IDA7IGkgPCBu ZnNydl9sdWdoYXNoc2l6ZTsgaSsrKQorCQkJCQltdHhfbG9jaygmbmZzdXNlcm5hbWVoYXNoW2ld Lm10eCk7CisJCQkJdXNlcm5hbWVfbG9ja2VkID0gMTsKKwkJCX0KKwkJCUtBU1NFUlQodXNlcl9s b2NrZWQgPT0gMCwKKwkJCSAgICAoIm5mc3N2Y19pZG5hbWU6IHVzZXJfbG9ja2VkIikpOworCQkJ Zm9yIChpID0gMDsgaSA8IG5mc3J2X2x1Z2hhc2hzaXplOyBpKyspCisJCQkJbXR4X2xvY2soJm5m c3VzZXJoYXNoW2ldLm10eCk7CisJCQl1c2VyX2xvY2tlZCA9IDE7CisJCQlmb3IgKGkgPSAwOyBp IDwgbmZzcnZfbHVnaGFzaHNpemU7IGkrKykgeworCQkJCVRBSUxRX0ZPUkVBQ0hfU0FGRSh1c3Jw LAorCQkJCSAgICAmbmZzdXNlcmhhc2hbaV0ubHVnaGVhZCwgbHVnX251bWhhc2gsCisJCQkJICAg IG51c3JwKQorCQkJCQlpZiAodXNycC0+bHVnX2V4cGlyeSA8IE5GU0RfTU9OT1NFQykKKwkJCQkJ CW5mc3J2X3JlbW92ZXVzZXIodXNycCwgMSk7CisJCQl9CisJCQlmb3IgKGkgPSAwOyBpIDwgbmZz cnZfbHVnaGFzaHNpemU7IGkrKykgeworCQkJCS8qCisJCQkJICogVHJpbSB0aGUgY2FjaGUgdXNp bmcgYW4gYXBwcm94aW1hdGUgTFJVCisJCQkJICogYWxnb3JpdGhtLiAgVGhpcyBjb2RlIGRlbGV0 ZXMgdGhlIGxlYXN0CisJCQkJICogcmVjZW50bHkgdXNlZCBlbnRyeSBvbiBlYWNoIGhhc2ggbGlz dC4KKwkJCQkgKi8KKwkJCQlpZiAobmZzcnZfdXNlcmNudCA8PSBuZnNydl91c2VybWF4KQorCQkJ CQlicmVhazsKKwkJCQl1c3JwID0gVEFJTFFfRklSU1QoJm5mc3VzZXJoYXNoW2ldLmx1Z2hlYWQp OworCQkJCWlmICh1c3JwICE9IE5VTEwpCisJCQkJCW5mc3J2X3JlbW92ZXVzZXIodXNycCwgMSk7 CisJCQl9CisJCX0gZWxzZSB7CisJCQlpZiAoZ3JvdXBuYW1lX2xvY2tlZCA9PSAwKSB7CisJCQkJ Zm9yIChpID0gMDsgaSA8IG5mc3J2X2x1Z2hhc2hzaXplOyBpKyspCisJCQkJCW10eF9sb2NrKCZu ZnNncm91cG5hbWVoYXNoW2ldLm10eCk7CisJCQkJZ3JvdXBuYW1lX2xvY2tlZCA9IDE7CisJCQl9 CisJCQlLQVNTRVJUKGdyb3VwX2xvY2tlZCA9PSAwLAorCQkJICAgICgibmZzc3ZjX2lkbmFtZTog Z3JvdXBfbG9ja2VkIikpOworCQkJZm9yIChpID0gMDsgaSA8IG5mc3J2X2x1Z2hhc2hzaXplOyBp KyspCisJCQkJbXR4X2xvY2soJm5mc2dyb3VwaGFzaFtpXS5tdHgpOworCQkJZ3JvdXBfbG9ja2Vk ID0gMTsKKwkJCWZvciAoaSA9IDA7IGkgPCBuZnNydl9sdWdoYXNoc2l6ZTsgaSsrKSB7CisJCQkJ VEFJTFFfRk9SRUFDSF9TQUZFKHVzcnAsCisJCQkJICAgICZuZnNncm91cGhhc2hbaV0ubHVnaGVh ZCwgbHVnX251bWhhc2gsCisJCQkJICAgIG51c3JwKQorCQkJCQlpZiAodXNycC0+bHVnX2V4cGly eSA8IE5GU0RfTU9OT1NFQykKKwkJCQkJCW5mc3J2X3JlbW92ZXVzZXIodXNycCwgMCk7CisJCQl9 CisJCQlmb3IgKGkgPSAwOyBpIDwgbmZzcnZfbHVnaGFzaHNpemU7IGkrKykgeworCQkJCS8qCisJ CQkJICogVHJpbSB0aGUgY2FjaGUgdXNpbmcgYW4gYXBwcm94aW1hdGUgTFJVCisJCQkJICogYWxn b3JpdGhtLiAgVGhpcyBjb2RlIGRlbGV0ZXMgdGhlIGxlYXN0CisJCQkJICogcmVjZW50bHkgdXNl ciBlbnRyeSBvbiBlYWNoIGhhc2ggbGlzdC4KKwkJCQkgKi8KKwkJCQlpZiAobmZzcnZfdXNlcmNu dCA8PSBuZnNydl91c2VybWF4KQorCQkJCQlicmVhazsKKwkJCQl1c3JwID0gVEFJTFFfRklSU1Qo Jm5mc2dyb3VwaGFzaFtpXS5sdWdoZWFkKTsKKwkJCQlpZiAodXNycCAhPSBOVUxMKQorCQkJCQlu ZnNydl9yZW1vdmV1c2VyKHVzcnAsIDApOworCQkJfQorCQl9CisJCWxhc3R0aW1lID0gTkZTRF9N T05PU0VDOworCQlhdG9taWNfc3RvcmVfcmVsX2ludCgmb25ldGhyZWFkLCAwKTsKKwl9CisKKwkv KiBOb3csIHVubG9jayBhbGwgbG9ja2VkIG11dGV4ZXMuICovCisJaWYgKGhwX2lkbnVtICE9IE5V TEwpCisJCW10eF91bmxvY2soJmhwX2lkbnVtLT5tdHgpOworCWlmIChocF9uYW1lICE9IE5VTEwp CisJCW10eF91bmxvY2soJmhwX25hbWUtPm10eCk7CisJaWYgKHVzZXJfbG9ja2VkICE9IDApCisJ CWZvciAoaSA9IDA7IGkgPCBuZnNydl9sdWdoYXNoc2l6ZTsgaSsrKQorCQkJbXR4X3VubG9jaygm bmZzdXNlcmhhc2hbaV0ubXR4KTsKKwlpZiAodXNlcm5hbWVfbG9ja2VkICE9IDApCisJCWZvciAo aSA9IDA7IGkgPCBuZnNydl9sdWdoYXNoc2l6ZTsgaSsrKQorCQkJbXR4X3VubG9jaygmbmZzdXNl cm5hbWVoYXNoW2ldLm10eCk7CisJaWYgKGdyb3VwX2xvY2tlZCAhPSAwKQorCQlmb3IgKGkgPSAw OyBpIDwgbmZzcnZfbHVnaGFzaHNpemU7IGkrKykKKwkJCW10eF91bmxvY2soJm5mc2dyb3VwaGFz aFtpXS5tdHgpOworCWlmIChncm91cG5hbWVfbG9ja2VkICE9IDApCisJCWZvciAoaSA9IDA7IGkg PCBuZnNydl9sdWdoYXNoc2l6ZTsgaSsrKQorCQkJbXR4X3VubG9jaygmbmZzZ3JvdXBuYW1laGFz aFtpXS5tdHgpOwogb3V0OgogCU5GU0VYSVRDT0RFKGVycm9yKTsKIAlyZXR1cm4gKGVycm9yKTsK QEAgLTMyNDMsMTUgKzM1MjEsMjUgQEAgb3V0OgogICogUmVtb3ZlIGEgdXNlci9ncm91cCBuYW1l IGVsZW1lbnQuCiAgKi8KIHN0YXRpYyB2b2lkCi1uZnNydl9yZW1vdmV1c2VyKHN0cnVjdCBuZnN1 c3JncnAgKnVzcnApCituZnNydl9yZW1vdmV1c2VyKHN0cnVjdCBuZnN1c3JncnAgKnVzcnAsIGlu dCBpc3VzZXIpCiB7CisJc3RydWN0IG5mc3J2X2x1Z2hhc2ggKmhwOwogCi0JTkZTTkFNRUlEUkVR VUlSRUQoKTsKLQlMSVNUX1JFTU9WRSh1c3JwLCBsdWdfbnVtaGFzaCk7Ci0JTElTVF9SRU1PVkUo dXNycCwgbHVnX25hbWVoYXNoKTsKLQlUQUlMUV9SRU1PVkUoJm5mc3VzZXJscnVoZWFkLCB1c3Jw LCBsdWdfbHJ1KTsKLQluZnNydl91c2VyY250LS07Ci0JRlJFRSgoY2FkZHJfdCl1c3JwLCBNX05G U1VTRVJHUk9VUCk7CisJaWYgKGlzdXNlciAhPSAwKSB7CisJCWhwID0gTkZTVVNFUkhBU0godXNy cC0+bHVnX3VpZCk7CisJCVRBSUxRX1JFTU9WRSgmaHAtPmx1Z2hlYWQsIHVzcnAsIGx1Z19udW1o YXNoKTsKKwkJaHAgPSBORlNVU0VSTkFNRUhBU0godXNycC0+bHVnX25hbWUsIHVzcnAtPmx1Z19u YW1lbGVuKTsKKwkJVEFJTFFfUkVNT1ZFKCZocC0+bHVnaGVhZCwgdXNycCwgbHVnX25hbWVoYXNo KTsKKwl9IGVsc2UgeworCQlocCA9IE5GU0dST1VQSEFTSCh1c3JwLT5sdWdfZ2lkKTsKKwkJVEFJ TFFfUkVNT1ZFKCZocC0+bHVnaGVhZCwgdXNycCwgbHVnX251bWhhc2gpOworCQlocCA9IE5GU0dS T1VQTkFNRUhBU0godXNycC0+bHVnX25hbWUsIHVzcnAtPmx1Z19uYW1lbGVuKTsKKwkJVEFJTFFf UkVNT1ZFKCZocC0+bHVnaGVhZCwgdXNycCwgbHVnX25hbWVoYXNoKTsKKwl9CisJYXRvbWljX2Fk ZF9pbnQoJm5mc3J2X3VzZXJjbnQsIC0xKTsKKwlpZiAodXNycC0+bHVnX2NyZWQgIT0gTlVMTCkK KwkJY3JmcmVlKHVzcnAtPmx1Z19jcmVkKTsKKwlmcmVlKHVzcnAsIE1fTkZTVVNFUkdST1VQKTsK IH0KIAogLyoKLS0tIGZzL25mcy9uZnNfY29tbW9ucG9ydC5jLnNhdgkyMDE1LTA5LTI4IDE4OjQ5 OjM1LjAwMDAwMDAwMCAtMDQwMAorKysgZnMvbmZzL25mc19jb21tb25wb3J0LmMJMjAxNS0xMS0x MyAxOTo1Mjo1OC4yODYwNTEwMDAgLTA1MDAKQEAgLTYzLDYgKzYzLDcgQEAgaW50IG5mc19udW1u ZnNjYmQgPSAwOwogaW50IG5mc2NsX2RlYnVnbGV2ZWwgPSAwOwogY2hhciBuZnN2NF9jYWxsYmFj a2FkZHJbSU5FVDZfQUREUlNUUkxFTl07CiBzdHJ1Y3QgY2FsbG91dCBuZXduZnNkX2NhbGxvdXQ7 CitpbnQgbmZzcnZfbHVnaGFzaHNpemUgPSAxMDAwOwogdm9pZCAoKm5mc2RfY2FsbF9zZXJ2ZXJ0 aW1lcikodm9pZCkgPSBOVUxMOwogdm9pZCAoKm5jbF9jYWxsX2ludmFsY2FjaGVzKShzdHJ1Y3Qg dm5vZGUgKikgPSBOVUxMOwogCkBAIC03OSw2ICs4MCw5IEBAIFNZU0NUTF9TVFJJTkcoX3Zmc19u ZnMsIE9JRF9BVVRPLCBjYWxsYmEKICAgICAiTkZTdjQgY2FsbGJhY2sgYWRkciBmb3Igc2VydmVy IHRvIHVzZSIpOwogU1lTQ1RMX0lOVChfdmZzX25mcywgT0lEX0FVVE8sIGRlYnVnbGV2ZWwsIENU TEZMQUdfUlcsICZuZnNjbF9kZWJ1Z2xldmVsLAogICAgIDAsICJEZWJ1ZyBsZXZlbCBmb3IgTkZT IGNsaWVudCIpOworVFVOQUJMRV9JTlQoInZmcy5uZnMudXNlcmhhc2hzaXplIiwgJm5mc3J2X2x1 Z2hhc2hzaXplKTsKK1NZU0NUTF9JTlQoX3Zmc19uZnMsIE9JRF9BVVRPLCB1c2VyaGFzaHNpemUs IENUTEZMQUdfUkRUVU4sICZuZnNydl9sdWdoYXNoc2l6ZSwKKyAgICAwLCAiU2l6ZSBvZiBoYXNo IHRhYmxlcyBmb3IgdWlkL25hbWUgbWFwcGluZyIpOwogCiAvKgogICogRGVmaW5lcyBmb3IgbWFs bG9jCkBAIC00NDUsOSArNDQ5LDI1IEBAIG5mc3N2Y19jYWxsKHN0cnVjdCB0aHJlYWQgKnAsIHN0 cnVjdCBuZnMKIHsKIAlpbnQgZXJyb3IgPSBFSU5WQUw7CiAJc3RydWN0IG5mc2RfaWRhcmdzIG5p ZDsKKwlzdHJ1Y3QgbmZzZF9vaWRhcmdzIG9uaWQ7CiAKIAlpZiAodWFwLT5mbGFnICYgTkZTU1ZD X0lETkFNRSkgewotCQllcnJvciA9IGNvcHlpbih1YXAtPmFyZ3AsIChjYWRkcl90KSZuaWQsIHNp emVvZiAobmlkKSk7CisJCWlmICgodWFwLT5mbGFnICYgTkZTU1ZDX05FV1NUUlVDVCkgIT0gMCkK KwkJCWVycm9yID0gY29weWluKHVhcC0+YXJncCwgKGNhZGRyX3QpJm5pZCwgc2l6ZW9mKG5pZCkp OworCQllbHNlIHsKKwkJCWVycm9yID0gY29weWluKHVhcC0+YXJncCwgKGNhZGRyX3QpJm9uaWQs IHNpemVvZihvbmlkKSk7CisJCQlpZiAoZXJyb3IgPT0gMCkgeworCQkJCW5pZC5uaWRfZmxhZyA9 IG9uaWQubmlkX2ZsYWc7CisJCQkJbmlkLm5pZF91aWQgPSBvbmlkLm5pZF91aWQ7CisJCQkJbmlk Lm5pZF9naWQgPSBvbmlkLm5pZF9naWQ7CisJCQkJbmlkLm5pZF91c2VybWF4ID0gb25pZC5uaWRf dXNlcm1heDsKKwkJCQluaWQubmlkX3VzZXJ0aW1lb3V0ID0gb25pZC5uaWRfdXNlcnRpbWVvdXQ7 CisJCQkJbmlkLm5pZF9uYW1lID0gb25pZC5uaWRfbmFtZTsKKwkJCQluaWQubmlkX25hbWVsZW4g PSBvbmlkLm5pZF9uYW1lbGVuOworCQkJCW5pZC5uaWRfbmdyb3VwID0gMDsKKwkJCQluaWQubmlk X2dycHMgPSBOVUxMOworCQkJfQorCQl9CiAJCWlmIChlcnJvcikKIAkJCWdvdG8gb3V0OwogCQll cnJvciA9IG5mc3N2Y19pZG5hbWUoJm5pZCk7Cg== ------=_Part_87814644_309663547.1447627285467-- From owner-freebsd-fs@freebsd.org Mon Nov 16 12:24:38 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42DE3A2E274 for ; Mon, 16 Nov 2015 12:24:38 +0000 (UTC) (envelope-from ronald.monthero@hpe.com) Received: from g2t1383g.austin.hp.com (g2t1383g.austin.hp.com [15.217.136.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hpe.com", Issuer "Symantec Class 3 Secure Server CA - G4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 190F21877 for ; Mon, 16 Nov 2015 12:24:37 +0000 (UTC) (envelope-from ronald.monthero@hpe.com) Received: from g1t5425.austin.hp.com (g1t5425.austin.hp.com [15.216.225.55]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by g2t1383g.austin.hp.com (Postfix) with ESMTPS id C12282108 for ; Mon, 16 Nov 2015 12:17:15 +0000 (UTC) Received: from G2W4316.americas.hpqcorp.net (g2w4316.austin.hp.com [16.197.9.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t5425.austin.hp.com (Postfix) with ESMTPS id 1B7F68D for ; Mon, 16 Nov 2015 12:17:09 +0000 (UTC) Received: from G1W5783.americas.hpqcorp.net (16.193.26.1) by G2W4316.americas.hpqcorp.net (16.197.9.73) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 16 Nov 2015 12:16:15 +0000 Received: from G2W2529.americas.hpqcorp.net ([169.254.1.101]) by G1W5783.americas.hpqcorp.net ([16.193.26.1]) with mapi id 14.03.0169.001; Mon, 16 Nov 2015 12:14:29 +0000 From: "Monthero, Ronald Hamilton" To: "freebsd-fs@FreeBSD.org" Subject: Mounting the root file system through vfs_mountroot operation in a Stacked File System Thread-Topic: Mounting the root file system through vfs_mountroot operation in a Stacked File System Thread-Index: AdEgaEpcQDK88Co/Tc+uoye758RCxw== Date: Mon, 16 Nov 2015 12:14:29 +0000 Message-ID: <76457345D90D8442AB0703F67C47EA9E096D2442@G2W2529.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.196.64.186] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 12:24:38 -0000 Hi, I have a fundamental question regarding mounting the root file system. I tried to find vfs_mountroot operation in Linux and couldn't find it as p= art of vfsops. I believe that Linux doesn't have the vfs_mountroot as part of the vfsops. I am porting some BSD style code onto Linux and I ran into the issue and could not find an equivalent for vfs_mountroot operation. Any thoughts as to why Linux doesn't seem to have vfs_mountroot as part of = its vfsops Please share your thoughts as they are much valued are welcome. Thanks and Regards, Ronald From owner-freebsd-fs@freebsd.org Tue Nov 17 08:52:26 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B2EDA2EB45 for ; Tue, 17 Nov 2015 08:52:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3800A1047 for ; Tue, 17 Nov 2015 08:52:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAH8qQCK013568 for ; Tue, 17 Nov 2015 08:52:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204622] [zfs] [patch] Improve 'zpool labelclear' command Date: Tue, 17 Nov 2015 08:52:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: feature, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: martymac@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 08:52:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204622 Ganael LAPLANCHE changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |feature Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org CC| |martymac@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Tue Nov 17 19:57:46 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A87CCA3174D for ; Tue, 17 Nov 2015 19:57:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94B221793 for ; Tue, 17 Nov 2015 19:57:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAHJvk4e012071 for ; Tue, 17 Nov 2015 19:57:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 203588] [ufs] fsck_ufs segfaults during journals after powerloss Date: Tue, 17 Nov 2015 19:57:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: amvandemore@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 19:57:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203588 amvandemore@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amvandemore@gmail.com --- Comment #1 from amvandemore@gmail.com --- Yes this is a bug. Unfortunately, this type of PR is almost useless since there is no actionable information included. I don't know any devs who love wild goose chases. If it happens again, better ways to handle this are: 1. Snapshot the underlying block device so there is always access to the problematic state. 2. Run "fsck_ffs -d" and "fsck_ffs -f -d" and ensure the output is saved eg script(1). See bug #187221 for an example of an actionable PR. Also what does this "A full fsck hopefully worked .." mean? Did a full fsck work? If yes then there is no need to mention it and if no it needs to be in the PR. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Tue Nov 17 22:08:35 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 039DFA31768; Tue, 17 Nov 2015 22:08:35 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC5341313; Tue, 17 Nov 2015 22:08:34 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: by ioir85 with SMTP id r85so34205812ioi.1; Tue, 17 Nov 2015 14:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=c6bzUkfOgqEN3rAxugbiP+LAQGCwAaGiN+dfbLw7TV4=; b=U3KyJnatjOltFVD5CjmNYqasV2uRZCO5Bix1uDHgfNMHbtD+3dQeKrSqK3gQ3vEMxn d+D9+QSEytQthLriWZ9f9yq2usuDk8pXKNnRtmw8fmja1s6oExSnnbj9DENKKsRMMfdz 46moPD8ZpYOGIqd6y++HPsYfC8+M9fgsyu0diLW3eRBtmTYhiKCiufoZ9tW6pJv9ePYz ph93c+WTufmmkiAW+Oogk2zYtvpdFvFztX7CqsOeiY2c4P2aB5QIn/xhr9Ea1DWO7SIR bdtMFnK8ZXg/hCnPLdrNEJvQEqkFZNi6LD61iEaTZrxt8Q8iPnivYEOaxzVpMqjpgJC3 a6fQ== MIME-Version: 1.0 X-Received: by 10.107.155.149 with SMTP id d143mr41223533ioe.145.1447798114108; Tue, 17 Nov 2015 14:08:34 -0800 (PST) Received: by 10.36.159.67 with HTTP; Tue, 17 Nov 2015 14:08:34 -0800 (PST) Date: Tue, 17 Nov 2015 18:08:34 -0400 Message-ID: Subject: Bug 204641 - 10.2 UNMAP/TRIM not available on a zfs zpool that uses iSCSI disks, backed on a zpool file target From: Christopher Forgeron To: FreeBSD stable , FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 22:08:35 -0000 I just submitted this as a bug: ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204641 ) ..but I thought I should bring it to the list's attention for more exposure - If that's a no-no, let me know, as I have a few others that are related to this that I'd like to discuss. - - - - Consider this scenario: Virtual FreeBSD Machine, with a zpool created out of iSCSI disks. Physical FreeBSD Machine, with a zpool holding a sparse file that is the target for the iSCSI disk. This setup works in an environment with all 10.1 machines, doesn't with all 10.2 machines. - The 10.2 Machines are 10.2-p7 RELEASE, updated via freebsd-update, no custom. - The 10.1 Machine are 10.1-p24 RELEASE, updated via freebsd-update, no custom. - iSCSI is all CAM iSCSI, not the old istgt platform. - The iSCSI Target is a sparse file, stored on a zpool (not a vdev Target) The target machine is the same physical machine, with the same zpools - I either boot 10.1 or 10.2 for testing, and use the same zpool/disks to ensure nothing is changing. If I have a 10.2 iSCSI Initiator (client) connected to a 10.2 iSCSI Target, TRIM doesn't work (shows as NONE below). If I have a 10.2 iSCSI Initiator (client) connected to a 10.1 iSCSI Target, TRIM does work. (There is another bug with that last scenario as well, but I will open it separately) ...for clarity, a 10.1 iSCSI Initiator connected to a 10.1 iSCSI Target also works perfectly. I have ~20 of these in the field. On the 10.1 / 10.2 Targets, the ctl.conf file is identical. Zpools are identical, because they are shared between reboots of the same iSCSI target machine. On the 10.2 initiator machine, connected to a 10.2 Target machine: # sysctl -a | grep cam.da kern.cam.da.2.minimum_cmd_size: 6 kern.cam.da.2.delete_max: 131072 kern.cam.da.2.delete_method: NONE kern.cam.da.1.error_inject: 0 kern.cam.da.1.sort_io_queue: 0 kern.cam.da.1.minimum_cmd_size: 6 kern.cam.da.1.delete_max: 131072 kern.cam.da.1.delete_method: NONE kern.cam.da.0.error_inject: 0 kern.cam.da.0.sort_io_queue: -1 kern.cam.da.0.minimum_cmd_size: 6 kern.cam.da.0.delete_max: 131072 kern.cam.da.0.delete_method: NONE Note the delete_method is NONE # sysctl -a | grep trim vfs.zfs.trim.max_interval: 1 vfs.zfs.trim.timeout: 30 vfs.zfs.trim.txg_delay: 32 vfs.zfs.trim.enabled: 1 vfs.zfs.vdev.trim_max_pending: 10000 vfs.zfs.vdev.trim_max_active: 64 vfs.zfs.vdev.trim_min_active: 1 vfs.zfs.vdev.trim_on_init: 1 kstat.zfs.misc.zio_trim.failed: 0 kstat.zfs.misc.zio_trim.unsupported: 181 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.bytes: 0 Note no trimmed bytes. On the target machine, 10.1 and 10.2 share the same config file: /etc/ctl.conf portal-group pg0 { discovery-auth-group no-authentication listen 0.0.0.0 listen [::] } lun 0 { path /pool92/iscsi/iscsi.zvol blocksize 4K size 5T option unmap "on" option scsiname "pool92" option vendor "pool92" option insecure_tpc "on" } } target iqn.iscsi1.zvol { auth-group no-authentication portal-group pg0 lun 0 { path /pool92_1/iscsi/iscsi.zvol blocksize 4K size 5T option unmap "on" option scsiname "pool92_1" option vendor "pool92_1" option insecure_tpc "on" } } When I boot a 10.1 Target server, the 10.2 initiator connects, and we do see proper UNMAP ability: kern.cam.da.2.minimum_cmd_size: 6 kern.cam.da.2.delete_max: 5497558138880 kern.cam.da.2.delete_method: UNMAP kern.cam.da.1.error_inject: 0 kern.cam.da.1.sort_io_queue: 0 kern.cam.da.1.minimum_cmd_size: 6 kern.cam.da.1.delete_max: 5497558138880 kern.cam.da.1.delete_method: UNMAP kern.cam.da.0.error_inject: 0 kern.cam.da.0.sort_io_queue: -1 kern.cam.da.0.minimum_cmd_size: 6 kern.cam.da.0.delete_max: 131072 kern.cam.da.0.delete_method: NONE Please let me know what you'd like to know next. Thanks. From owner-freebsd-fs@freebsd.org Tue Nov 17 22:16:50 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E86B8A31B25; Tue, 17 Nov 2015 22:16:50 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4B5A1AC1; Tue, 17 Nov 2015 22:16:50 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: by igl9 with SMTP id 9so89456405igl.0; Tue, 17 Nov 2015 14:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZqYhpOA4p8OqAB18n4A7qXMvcv4PiZYCMTTjb5p5y9c=; b=B67t4ECi11+EzQYrQu+V2v3h2pJa3pfdnJeRuOHs/C1c7zAhEoicBJH4eNGnh13dyu oYfotPEIeHjzaz0M1xIDNvMf+4HuflAsm0Raxdfq/yIZpvxOgFXMDcEkRZRDnZ/tGh74 qCGm7srNNQJAHpX8jirrBPERlD6fNFWtDRQ5oxGq089JYlvxh591YbVHQ5H2rBbUjDb/ kYzenvDy9l50jtuwCPlc7LWI+SIpOz3/MHIfPJ/idBSmYXHc2un22I6CHjh5cNiCvItz ExH6cwLOzKfZrJRuXvMGUB1QEEMcTGbK3Eq1tvZ+nE7hK8BaOs7semnhWqOku2Ii4FOF FQ2w== MIME-Version: 1.0 X-Received: by 10.50.56.114 with SMTP id z18mr4474564igp.62.1447798610172; Tue, 17 Nov 2015 14:16:50 -0800 (PST) Received: by 10.36.159.67 with HTTP; Tue, 17 Nov 2015 14:16:50 -0800 (PST) In-Reply-To: <21685.40094.453028.585630@hergotha.csail.mit.edu> References: <21685.40094.453028.585630@hergotha.csail.mit.edu> Date: Tue, 17 Nov 2015 18:16:50 -0400 Message-ID: Subject: Re: Some filesystem performance numbers From: Christopher Forgeron To: Garrett Wollman Cc: FreeBSD Filesystems , FreeBSD stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 22:16:51 -0000 Sounds interesting. I'd love to see your results when you're ready to share, or even the 'work in progress' if you want to share privately . On Tue, Jan 13, 2015 at 6:30 PM, Garrett Wollman wrote: > I recently bought a copy of the SPECsfs2014 benchmark, and I've been > using it to test out our NFS server platform. One scenario of > interest to me is identifying where the limits are in terms of the > local CAM/storage/filesystem implementation versus bottlenecks unique > to the NFS server, and to that end I've been running the benchmark > suite directly on the server's local disk. (This is of course also > the way you'd benchmark for shared-nothing container-based > virtualization.) > > I have found a few interesting results on my test platform: > > 1) I can quantify the cost of using SHA256 vs. fletcher4 as the ZFS > checksum algorithm. On the VDA workload (essentially a simulated > video streaming/recording application), my server can do about half as > many "streams" with SHA256 as it can with fletcher4. > > 2) Both L2ARC and separate ZIL have small but measurable performance > impacts. I haven't examined the differences closely. > > 3) LZ4 compression also makes a small performance impact, but as > advertised, less than LZJB for mostly-incompressible data. > > I hope to be able to present the actual benchmark results at some > point, as well as some results for the other three workloads. > > -GAWollman > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@freebsd.org Wed Nov 18 10:07:14 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C161A320C5; Wed, 18 Nov 2015 10:07:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9EDA113C; Wed, 18 Nov 2015 10:07:13 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1Zyzdt-0001PA-LE; Wed, 18 Nov 2015 13:07:09 +0300 Date: Wed, 18 Nov 2015 13:07:09 +0300 From: Slawa Olhovchenkov To: Garrett Wollman Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Some filesystem performance numbers Message-ID: <20151118100709.GN48728@zxy.spb.ru> References: <21685.40094.453028.585630@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21685.40094.453028.585630@hergotha.csail.mit.edu> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 10:07:14 -0000 On Tue, Jan 13, 2015 at 05:30:54PM -0500, Garrett Wollman wrote: > I recently bought a copy of the SPECsfs2014 benchmark, and I've been > using it to test out our NFS server platform. One scenario of > interest to me is identifying where the limits are in terms of the > local CAM/storage/filesystem implementation versus bottlenecks unique > to the NFS server, and to that end I've been running the benchmark > suite directly on the server's local disk. (This is of course also > the way you'd benchmark for shared-nothing container-based > virtualization.) > > I have found a few interesting results on my test platform: > > 1) I can quantify the cost of using SHA256 vs. fletcher4 as the ZFS > checksum algorithm. On the VDA workload (essentially a simulated > video streaming/recording application), my server can do about half as > many "streams" with SHA256 as it can with fletcher4. For VDA recordsize=1M (or more) can give performance impcat in case saturated HDD by IOPS. > 2) Both L2ARC and separate ZIL have small but measurable performance > impacts. I haven't examined the differences closely. This is depend of fractions hot/warm/cold content. > 3) LZ4 compression also makes a small performance impact, but as > advertised, less than LZJB for mostly-incompressible data. > > I hope to be able to present the actual benchmark results at some > point, as well as some results for the other three workloads. > > -GAWollman > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Wed Nov 18 18:55:39 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97340A3242E for ; Wed, 18 Nov 2015 18:55:39 +0000 (UTC) (envelope-from sef@ixsystems.com) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78A3D1B09 for ; Wed, 18 Nov 2015 18:55:38 +0000 (UTC) (envelope-from sef@ixsystems.com) X-ASG-Debug-ID: 1447872937-08ca040e853097a0001-3nHGF7 Received: from mail.iXsystems.com ([10.2.55.1]) by barracuda.ixsystems.com with ESMTP id iKwhAoG21ecH3ESQ (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 18 Nov 2015 10:55:38 -0800 (PST) X-Barracuda-Envelope-From: sef@ixsystems.com X-Barracuda-RBL-Trusted-Forwarder: 10.2.55.1 X-ASG-Whitelist: Client Received: from [10.5.0.29] (unknown [10.5.0.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id A914BA08BC for ; Wed, 18 Nov 2015 10:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1447872937; bh=KD2v9GfawG6hW8ZWOg6ofyr8XVf11/q+BpgYNJCR778=; h=From:Subject:Date:To; b=cP9bBMJfmwaOOZh5UypDqi96662ipntzmZFT5sUwPc4YYxSCPYGOAskBTxxjNcmXr ne2A6fGawu+A3Vchok5qVlOBrt0eiMNfH3++RKCH/Wzm3bbohpp6mpuO25BnnoDFc+ nswdyj4f1wKYOkRwaUzXOu7OI2HNLeIM7q9HMVsQ= From: Sean Fagan Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Proposed change to mountd: allow quoted group/user names Message-Id: <87D68C46-C9D7-4B8E-A696-BB1D4FCBC028@ixsystems.com> X-ASG-Orig-Subj: Proposed change to mountd: allow quoted group/user names Date: Wed, 18 Nov 2015 10:55:37 -0800 To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: UNKNOWN[10.2.55.1] X-Barracuda-Start-Time: 1447872938 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 18:55:39 -0000 https://reviews.freebsd.org/D4201 Hopefully I did this correctly. In a nutshell, we=E2=80=99ve run into cases where a directory server = (*cough* windows *cough*) will have group names with spaces in them. = This causes sadness to happen. And mountd doesn=E2=80=99t allow them to = be quoted. This proposed diff allows the quoting. (N.B. I did not yet extend it to pathnames. That could be done, but = it=E2=80=99s not generally as necessary.) Thanks, Sean. From owner-freebsd-fs@freebsd.org Thu Nov 19 09:41:14 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25B43A32CC5 for ; Thu, 19 Nov 2015 09:41:14 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: from mxout01.bytecamp.net (mxout01.bytecamp.net [212.204.60.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAB9213B0 for ; Thu, 19 Nov 2015 09:41:13 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: by mxout01.bytecamp.net (Postfix, from userid 1001) id 31F1E30FD48; Thu, 19 Nov 2015 10:41:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bytecamp.net; h=to:from:subject:message-id:date:mime-version:content-type:content-transfer-encoding; s=20140709; bh=nXtC0Kl58fIOqbfR3FpJJ7zj6lk=; b=E8cgVe8WfEpX8jO26qyuj8r0Yto5hEv5LofSBwyG/+CxK8rwnivIeDl+9O6HM628EM8GAXN2i3wFnQ1aMHthXEOEyY/buO9wSfWoWhhoUVmj1ef386jQWKiJT0NbFerpNfEEMZireOzh+1/g8yVrN7tw1+zoijgoHv878tD0+S4= Received: from mail.bytecamp.net (mailstore.bytecamp.net [212.204.60.20]) by mxout01.bytecamp.net (Postfix) with ESMTP id 03C1530FD41 for ; Thu, 19 Nov 2015 10:41:04 +0100 (CET) Received: (qmail 60619 invoked by uid 89); 19 Nov 2015 10:41:04 +0100 Received: from stella.bytecamp.net (HELO ?212.204.60.37?) (rs%bytecamp.net@212.204.60.37) by mail.bytecamp.net with AES128-SHA encrypted SMTP; 19 Nov 2015 10:41:04 +0100 To: freebsd-fs@freebsd.org From: Robert Schulze Subject: filesystem deadlock, process in vodead state X-Enigmail-Draft-Status: N1110 Organization: bytecamp GmbH Message-ID: <564D9930.1080509@bytecamp.net> Date: Thu, 19 Nov 2015 10:41:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 09:41:14 -0000 Hi, on an SSD-only mirrored pool which was idle for about 30 days, I noticed a stuck chksetuid run from periodic. The "find" process is stuck on vodead state. I found out which directory is affected via procstat -f and tried to ls it, now this ls is stuck in above state, too (no surprise). procstat -kk output is: 1816 102485 find - mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 vnode_create_vobject+0x100 zfs_freebsd_open+0xf5 VOP_OPEN_APV+0xa1 vn_open_vnode+0x234 vn_open_cred+0x33e kern_openat+0x26f amd64_syscall+0x33a Xfast_syscall+0xfb 71376 102400 ls - mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 vnode_create_vobject+0x100 zfs_freebsd_open+0xf5 VOP_OPEN_APV+0xa1 vn_open_vnode+0x234 vn_open_cred+0x33e kern_openat+0x26f amd64_syscall+0x33a Xfast_syscall+0xfb The processes are not killable. So what is this state and how to fix the deadlocked filesystem? I'm able to give any debugging information, just give me some pointers. # uname: FreeBSD 10.2-RELEASE-p5 #1 r289218 # zpool status pool: home state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM home ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/mirror0-a ONLINE 0 0 0 gpt/mirror0-b ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 gpt/mirror1-a ONLINE 0 0 0 gpt/mirror1-b ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 gpt/mirror2-a ONLINE 0 0 0 gpt/mirror2-b ONLINE 0 0 0 mirror-3 ONLINE 0 0 0 gpt/mirror3-a ONLINE 0 0 0 gpt/mirror3-b ONLINE 0 0 0 errors: No known data errors with kind regards, Robert Schulze From owner-freebsd-fs@freebsd.org Thu Nov 19 12:30:24 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61D01A33999 for ; Thu, 19 Nov 2015 12:30:24 +0000 (UTC) (envelope-from supportme@ukr.net) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1.freebsd.org (Postfix) with ESMTP id 50FD21D2A for ; Thu, 19 Nov 2015 12:30:23 +0000 (UTC) (envelope-from supportme@ukr.net) Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id 2223B1A6BDBB for ; Thu, 19 Nov 2015 04:17:48 -0800 (PST) Date: Thu, 19 Nov 2015 05:30:16 -0700 (MST) From: Dmitriy Makarov To: freebsd-fs@freebsd.org Message-ID: <1447936216089-6054111.post@n5.nabble.com> In-Reply-To: <564D9930.1080509@bytecamp.net> References: <564D9930.1080509@bytecamp.net> Subject: Re: filesystem deadlock, process in vodead state MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 12:30:24 -0000 Hi, we has exactly the same issue on our two boxes, running CURRENT. But in our case stuck is on read one exactly file: ls $file - works fine, cat $file - hang. The file is on ZFS pool, stripe of mirrors too. The first box: FreeBSD 11.0-CURRENT #0 r290331 (uptime 15 days) [box92:~]$ ps auxwww|grep cat root 21344 0,0 0,0 8256 2012 6- D+J 13:52 0:00,00 cat .main.lock [box92:~]# procstat -kk 21344 PID TID COMM TDNAME KSTACK 21344 103410 cat - mi_switch+0xd8 sleepq_wait+0x3a _sleep+0x2df vnode_create_vobject+0x131 zfs_freebsd_open+0xf6 VOP_OPEN_APV+0xa0 vn_open_vnode+0x26a vn_open_cred+0x33e kern_openat+0x25f amd64_syscall+0x50b Xfast_syscall+0xfb [box92:~]# procstat -t 21344 PID TID COMM TDNAME CPU PRI STATE WCHAN 21344 103410 cat - -1 120 sleep vodead [box92:~]# procstat -S 21344 PID TID COMM TDNAME CPU CSID CPU MASK 21344 103410 cat - -1 6 0-11 [box92:~]# procstat -H 21344 PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM 21344 84508 21344 9350 9350 1 endo vodead FreeBSD ELF64 cat [box92:~]# procstat -f 21344 PID COMM FD T V FLAGS REF OFFSET PRO NAME 21344 cat text v r r------- - - - /var/jail64/jail1/bin/cat 21344 cat cwd v d r------- - - - /var/jail64/jail1/var/mail/path 21344 cat root v d r------- - - - /var/jail64/jail1 21344 cat jail v d r------- - - - /var/jail64/jail1 21344 cat 0 v x rwa----- 18 635287 - - 21344 cat 1 v x rwa----- 18 635287 - - 21344 cat 2 v x rwa----- 18 635287 - - The second box running FreeBSD 11.0-CURRENT #0 r287745 (uptime 51 days) I'm not familiar with debugging tools, but ready to help if somebody interesting. -- View this message in context: http://freebsd.1045724.n5.nabble.com/filesystem-deadlock-process-in-vodead-state-tp6054087p6054111.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@freebsd.org Thu Nov 19 14:24:02 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38C32A3252B for ; Thu, 19 Nov 2015 14:24:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 243871037 for ; Thu, 19 Nov 2015 14:24:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAJEO2wx026420 for ; Thu, 19 Nov 2015 14:24:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 195303] [zfs] large_blocks enabled on pool, recordsize capped at 1M, minor typo in error message when attempting to create dataset with recordsize=2M Date: Thu, 19 Nov 2015 14:24:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vsasjason@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 14:24:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195303 --- Comment #1 from Anton Sayetsky --- (In reply to Trond.Endrestol from comment #0) The situation is more difficult - maximum record size could be changed, see r374637. So the pseudocode for displaying error message should be like this: if [large_blocks_enabled == true] max_block_size = sysctl(vfs.zfs.max_recordsize) else max_block_size = 128k error("Block size cannot be greater than %d", max_block_size) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Thu Nov 19 14:25:11 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC80EA32575 for ; Thu, 19 Nov 2015 14:25:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7D4C10F3 for ; Thu, 19 Nov 2015 14:25:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAJEPB31028233 for ; Thu, 19 Nov 2015 14:25:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 195303] [zfs] large_blocks enabled on pool, recordsize capped at 1M, minor typo in error message when attempting to create dataset with recordsize=2M Date: Thu, 19 Nov 2015 14:25:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vsasjason@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 14:25:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195303 --- Comment #2 from Anton Sayetsky --- (In reply to Anton Sayetsky from comment #1) Sorry, wrong revision. Correct is r274673 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Thu Nov 19 15:27:03 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F354CA33251 for ; Thu, 19 Nov 2015 15:27:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF6431181 for ; Thu, 19 Nov 2015 15:27:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAJFR2K6033202 for ; Thu, 19 Nov 2015 15:27:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204643] [msdosfs] [panic] Crash while accessing files with large, non-english names Date: Thu, 19 Nov 2015 15:27:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 15:27:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204643 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1418 | |97 Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Thu Nov 19 15:27:03 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC8EAA33254 for ; Thu, 19 Nov 2015 15:27:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 989271187 for ; Thu, 19 Nov 2015 15:27:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAJFR3fM033215 for ; Thu, 19 Nov 2015 15:27:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 141897] [msdosfs] [panic] Kernel panic. msdofs: file name length 266 to large. Date: Thu, 19 Nov 2015 15:27:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 15:27:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=141897 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=2046 | |43 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Thu Nov 19 17:16:28 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4CBFA32889 for ; Thu, 19 Nov 2015 17:16:28 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail1.yamagi.org (yugo.yamagi.org [212.48.122.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AC971D77 for ; Thu, 19 Nov 2015 17:16:27 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from p57b5dddb.dip0.t-ipconnect.de ([87.181.221.219] helo=kosei.home.yamagi.org) by mail1.yamagi.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1ZzSE6-000NCT-Rb; Thu, 19 Nov 2015 17:38:27 +0100 Date: Thu, 19 Nov 2015 17:38:21 +0100 From: Yamagi Burmeister To: rs@bytecamp.net Cc: freebsd-fs@freebsd.org Subject: Re: filesystem deadlock, process in vodead state Message-Id: <20151119173821.b3da4b7d92571b723d4c5e5f@yamagi.org> In-Reply-To: <564D9930.1080509@bytecamp.net> References: <564D9930.1080509@bytecamp.net> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 17:16:28 -0000 Hello, last week I've observed a similar deadlock on a FreeBSD 10.2 machine with UFS filesystem. I haven't saved the procstat output because I suspected broken hardware (The SSD wearout indicator was down to 22. There weren't any ATA errors in dmesg), but as far as I remember the kernel stacks looked similar. ufs_open() instead of zfs_freebsd_open() of course. Regards, Yamagi On Thu, 19 Nov 2015 10:41:04 +0100 Robert Schulze wrote: > Hi, > > on an SSD-only mirrored pool which was idle for about 30 days, I noticed > a stuck chksetuid run from periodic. The "find" process is stuck on > vodead state. > > I found out which directory is affected via procstat -f and tried to ls > it, now this ls is stuck in above state, too (no surprise). > > procstat -kk output is: > > 1816 102485 find - mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 vnode_create_vobject+0x100 > zfs_freebsd_open+0xf5 VOP_OPEN_APV+0xa1 vn_open_vnode+0x234 > vn_open_cred+0x33e kern_openat+0x26f amd64_syscall+0x33a Xfast_syscall+0xfb > > 71376 102400 ls - mi_switch+0xe1 > sleepq_wait+0x3a _sleep+0x287 vnode_create_vobject+0x100 > zfs_freebsd_open+0xf5 VOP_OPEN_APV+0xa1 vn_open_vnode+0x234 > vn_open_cred+0x33e kern_openat+0x26f amd64_syscall+0x33a Xfast_syscall+0xfb > > The processes are not killable. > So what is this state and how to fix the deadlocked filesystem? I'm able > to give any debugging information, just give me some pointers. > > # uname: FreeBSD 10.2-RELEASE-p5 #1 r289218 > > # zpool status > > pool: home > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > home ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/mirror0-a ONLINE 0 0 0 > gpt/mirror0-b ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > gpt/mirror1-a ONLINE 0 0 0 > gpt/mirror1-b ONLINE 0 0 0 > mirror-2 ONLINE 0 0 0 > gpt/mirror2-a ONLINE 0 0 0 > gpt/mirror2-b ONLINE 0 0 0 > mirror-3 ONLINE 0 0 0 > gpt/mirror3-a ONLINE 0 0 0 > gpt/mirror3-b ONLINE 0 0 0 > > errors: No known data errors > > > with kind regards, > Robert Schulze > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-fs@freebsd.org Fri Nov 20 03:10:57 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AB9FA325F7 for ; Fri, 20 Nov 2015 03:10:57 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A3C41B05 for ; Fri, 20 Nov 2015 03:10:56 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: by lfaz4 with SMTP id z4so60856779lfa.0 for ; Thu, 19 Nov 2015 19:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vXqRaX8BMgvG6s0bT79qE/DG+JFXUFb5QPA+8oatdHc=; b=VGuceQ+oxWUmJdwN4q95SLXHrfIJv+LxgvhLCnrCYAnnDbRDvdEIx87CS96ZWQwEjD gWfXMo7OEWMdBZX33NrJ+wnNezYhCBdRKwNIAP2SgOQQ2mE14ttA922AE/2cBR20acyV ZTFpe1kXGEGve085eHnuej3FxEp4RBJHGnn0w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=vXqRaX8BMgvG6s0bT79qE/DG+JFXUFb5QPA+8oatdHc=; b=hKmlEhc1iKw/2aaJKR6hlEJp6CdG+SY1k7sHKCVncbp6CkQCa4u2bLK1lNlXOxnaTT GLfXj8DDcKD7Vn4dE65Wf6G5hXEaRvoosRrwIsTRrqqHexeMOf62uZ9HWhWxvIceN1qw xLhouWYCEmQLrPQkKgxoqRx5y18tnKeqQ0OAmWPe8fe43KGxSQwUsDL3YUcfUV0UuGVw b507z0WLvPsObcJXbrzSwqTJZBMehQf5ebzr5yoSz+0MZKGOZm/3r4Zn7wBRGuizO4O6 jLXm2F1bn5f2caoAjpA6ZOTg4Tn6vvULePYlZ6y8hhjCIHNWBKvn6ZcktaRFHtUmCNvJ Q8dA== X-Gm-Message-State: ALoCoQmxs20VzPsMsnkndwWgEpmVF81aWwy8T144kNVz25o7piWtXt5/lKrY1ATFjeyRbOLT5A3N MIME-Version: 1.0 X-Received: by 10.25.44.213 with SMTP id s204mr4707901lfs.37.1447989053248; Thu, 19 Nov 2015 19:10:53 -0800 (PST) Received: by 10.25.205.200 with HTTP; Thu, 19 Nov 2015 19:10:53 -0800 (PST) Received: by 10.25.205.200 with HTTP; Thu, 19 Nov 2015 19:10:53 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Nov 2015 19:10:53 -0800 Message-ID: Subject: Monitoring nfsd From: Tim Gustafson To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 03:10:57 -0000 Is there any FreeBSD tool to show me real-time nfsd stats grouped by user? Something like iftop but per-nfs-user instead of per-network-host? I'd like to know which nfs users are hitting my nfs server the hardest. From owner-freebsd-fs@freebsd.org Fri Nov 20 08:37:14 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69BDAA3260C for ; Fri, 20 Nov 2015 08:37:14 +0000 (UTC) (envelope-from jg@internetx.com) Received: from mx1.internetx.com (mx1.internetx.com [62.116.129.39]) by mx1.freebsd.org (Postfix) with ESMTP id 2B0DE1EA8 for ; Fri, 20 Nov 2015 08:37:13 +0000 (UTC) (envelope-from jg@internetx.com) Received: from localhost (localhost [127.0.0.1]) by mx1.internetx.com (Postfix) with ESMTP id 8BB3F1472001; Fri, 20 Nov 2015 09:29:52 +0100 (CET) X-Virus-Scanned: InterNetX GmbH amavisd-new at ix-mailer.internetx.de Received: from mx1.internetx.com ([62.116.129.39]) by localhost (ix-mailer.internetx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E-elqyOw0-m; Fri, 20 Nov 2015 09:29:50 +0100 (CET) Received: from [192.168.100.26] (pizza.internetx.de [62.116.129.3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.internetx.com (Postfix) with ESMTPSA id 2FE0D4C4C79E; Fri, 20 Nov 2015 09:29:50 +0100 (CET) Subject: Re: Monitoring nfsd References: To: Tim Gustafson , freebsd-fs@freebsd.org Reply-To: jg@internetx.com From: InterNetX - Juergen Gotteswinter Message-ID: <564ED9F9.5040006@internetx.com> Date: Fri, 20 Nov 2015 09:29:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 08:37:14 -0000 dtrace ? nfswatch? Am 20.11.2015 um 04:10 schrieb Tim Gustafson: > Is there any FreeBSD tool to show me real-time nfsd stats grouped by user? > Something like iftop but per-nfs-user instead of per-network-host? I'd > like to know which nfs users are hitting my nfs server the hardest. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@freebsd.org Fri Nov 20 08:47:37 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11494A32857 for ; Fri, 20 Nov 2015 08:47:37 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5DE81375 for ; Fri, 20 Nov 2015 08:47:36 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 72B3515340D for ; Fri, 20 Nov 2015 09:47:33 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpw95g_SZHri; Fri, 20 Nov 2015 09:47:15 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:8d89:26f8:7566:5e3f] (unknown [IPv6:2001:4cb8:3:1:8d89:26f8:7566:5e3f]) by smtp.digiware.nl (Postfix) with ESMTP id 535B1153408 for ; Fri, 20 Nov 2015 09:47:15 +0100 (CET) Subject: Fwd: Strange behaviour of getcwd for hidden ZFS snapshots. References: <55E437C2.5080609@digiware.nl> To: "freebsd-fs@freebsd.org" From: Willem Jan Withagen Organization: Digiware Management b.v. X-Forwarded-Message-Id: <55E437C2.5080609@digiware.nl> Message-ID: <564EDE1C.7080502@digiware.nl> Date: Fri, 20 Nov 2015 09:47:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <55E437C2.5080609@digiware.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 08:47:37 -0000 [This is repost from an earlier version on current@, but then there were no takers.] Hi, I was trying to restore some deleted files from a snapshot with rsync: [/home/www/.zfs/snapshot/zfs-auto-snap_hourly-2015-08-31-12h00/www.tegenbosch28.nl] root@zfs.digiware.nl# rsync -rav * /tmp rsync: getcwd(): No such file or directory (2) rsync error: errors selecting input/output files, dirs (code 3) at util.c(1101) [Receiver=3.1.1] Exit 3 Turns out that if the snapshots are hidden, then getcwd() errors out? Setting snapdir=visible on the volume gets it to do its job. As does changing out of the snapshot directory and using the full path for source and destination Is this a bug or a feature? 10.2-STABLE FreeBSD 10.2-STABLE #324 r287170: Thu Aug 27 --WjW From owner-freebsd-fs@freebsd.org Fri Nov 20 13:17:36 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49E77A3304A for ; Fri, 20 Nov 2015 13:17:36 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: from mxout01.bytecamp.net (mxout01.bytecamp.net [212.204.60.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AC4A129D for ; Fri, 20 Nov 2015 13:17:35 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: by mxout01.bytecamp.net (Postfix, from userid 1001) id 2A9AB31519E; Fri, 20 Nov 2015 14:17:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bytecamp.net; h=subject:to:references:cc:from:message-id:date:mime-version:in-reply-to:content-type:content-transfer-encoding; s=20140709; bh=j3wHvGCkTy1dc3idv/yzCZpORWs=; b=FYxbNAW8SPEzR1k4v/QyW7OVZKfQneA/PaomcGHn4Psh5HVaWqfwOpN6w+PWswFu+Aeo98VYhHzdj+cnuV+fGJq27ke6AtppVXO+U8UgV+dgWItKZ929w5W5saTgC4wKW5hoWU09VdNHKrcJaMye58Ti9Kk0AqALSSpRmXBoTmA= Received: from mail.bytecamp.net (mailstore.bytecamp.net [212.204.60.20]) by mxout01.bytecamp.net (Postfix) with ESMTP id D5EEE3151A9 for ; Fri, 20 Nov 2015 14:17:26 +0100 (CET) Received: (qmail 50513 invoked by uid 89); 20 Nov 2015 14:17:26 +0100 Received: from stella.bytecamp.net (HELO ?212.204.60.37?) (rs%bytecamp.net@212.204.60.37) by mail.bytecamp.net with AES128-SHA encrypted SMTP; 20 Nov 2015 14:17:26 +0100 Subject: Re: filesystem deadlock, process in vodead state To: Yamagi Burmeister References: <564D9930.1080509@bytecamp.net> <20151119173821.b3da4b7d92571b723d4c5e5f@yamagi.org> Cc: freebsd-fs@freebsd.org From: Robert Schulze Organization: bytecamp GmbH Message-ID: <564F1D66.2060806@bytecamp.net> Date: Fri, 20 Nov 2015 14:17:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151119173821.b3da4b7d92571b723d4c5e5f@yamagi.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 13:17:36 -0000 Hi, Am 19.11.2015 um 17:38 schrieb Yamagi Burmeister: > Hello, > last week I've observed a similar deadlock on a FreeBSD 10.2 machine > with UFS filesystem. I haven't saved the procstat output because I > suspected broken hardware (The SSD wearout indicator was down to 22. > There weren't any ATA errors in dmesg) the SSDs are completely new, SMART wear level indicator is at 100%. By the way, I'm able to list directory entries from the affected tree via zdb. with kind regards, Robert Schulze From owner-freebsd-fs@freebsd.org Fri Nov 20 14:23:01 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5D12A34030 for ; Fri, 20 Nov 2015 14:23:01 +0000 (UTC) (envelope-from lkateley@kateley.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EB7F1F60 for ; Fri, 20 Nov 2015 14:23:01 +0000 (UTC) (envelope-from lkateley@kateley.com) Received: by igbxm8 with SMTP id xm8so12803191igb.1 for ; Fri, 20 Nov 2015 06:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kateley-com.20150623.gappssmtp.com; s=20150623; h=reply-to:subject:references:to:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=eeAiEgNmMJhvb1h+DzezX+KeVfIdIk/daC1tmVvciGY=; b=wzbJh7tzbm5s9SjW2tK3nNAKDqmbvcmHyGp6ZFim+11e+CcL0VTW4p55/IQYXLt28t xhB08M8RxbTMgVVdb2SUQI/Rp9/Eqs0pJlwVz8hk0vrGVL2T9e13cyiOFETHv8sl87S+ k8EU3PAAIjhwkndVoej9Ds62LluWwSTIjubdJ8E4+Iej527v5V+9RebdtEIuQ6mlN3mt V31H56pvtJmzUBVdtBeFi/qYXK2cKnw8OU/Swezq3MSvR6Fb0Dw2kM8fMO6gOP4x5X8p W+ucCgFrknJypARbH1qILMMxDN/JvGhYhq+m5E+aSxl6Z3FYZKeK3gVFAIraUN3lFmOe 8lqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=eeAiEgNmMJhvb1h+DzezX+KeVfIdIk/daC1tmVvciGY=; b=H90fbrpTFQSDbcffpEubx5+Hzo/Xv5P8pu4a54Mf7oI0i+rFO96TMoHtoN8WKST529 uwzCguRMx6AIvho2y9bVM4hiK4Jf1rfRQw4bevbA2SUve9OMdYlR06i8QC98b5jBYTMe T8qWAINKRTyOKGe6tAH3mREm4RBTfcp+14jx41AON9X9xYiWQ1kZewXTYyv/GuI2h7Go OrH6vgLBYDW7DR+Z3fud5q0VglDovtimevQKlxsRqBeHA44xeGvmKOhKHCwP6wghs3Uz ZiSwYfILvHdqYkpPykMSB+dgwO+JpJpijDM4P/39avRtye2lx+5gHvrn+omFyhbSLqpR Z6Yw== X-Gm-Message-State: ALoCoQl3DrYnTcYGrQTZGu1Ravj7FDX2SWZ5VISWueQUSMJY5JlwnyqT6Y0gOaXpFac0dNbW1Zkk X-Received: by 10.50.118.42 with SMTP id kj10mr136658igb.71.1448029380625; Fri, 20 Nov 2015 06:23:00 -0800 (PST) Received: from [192.168.0.4] ([63.231.252.189]) by smtp.googlemail.com with ESMTPSA id p79sm5339432ioi.15.2015.11.20.06.22.59 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Nov 2015 06:22:59 -0800 (PST) Reply-To: linda@kateley.com Subject: Re: Monitoring nfsd References: To: freebsd-fs@freebsd.org From: Linda Kateley Organization: Kateley Company Message-ID: <564F2CC3.7060306@kateley.com> Date: Fri, 20 Nov 2015 08:22:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 14:23:01 -0000 In the dtracetoolkit there is a hotuser script. It can be run to find nfs. linda On 11/19/15 9:10 PM, Tim Gustafson wrote: > Is there any FreeBSD tool to show me real-time nfsd stats grouped by user? > Something like iftop but per-nfs-user instead of per-network-host? I'd > like to know which nfs users are hitting my nfs server the hardest. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Fri Nov 20 17:42:59 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85DC4A33BEF for ; Fri, 20 Nov 2015 17:42:59 +0000 (UTC) (envelope-from AmericanExpress@welcome.aexp.com) Received: from lb4.webmarketingexperts.com.au (vmh17521.hosting24.com.au [111.67.12.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 262B51CC4 for ; Fri, 20 Nov 2015 17:42:58 +0000 (UTC) (envelope-from AmericanExpress@welcome.aexp.com) Received: from [23.227.196.51] (port=51469 helo=Monodc7138) by lb4.webmarketingexperts.com.au with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1ZzkwZ-000DLE-F3 for freebsd-fs@freebsd.org; Fri, 20 Nov 2015 23:37:36 +1100 MIME-Version: 1.0 Date: Fri, 20 Nov 2015 13:17:26 +0100 X-Priority: Normal Subject: Account Alert: Update Required X-Mailer: Rapid Email Sender To: "freebsd-fs" From: "American Express" Message-ID: <89FE32A3B7ECFDC534E01076D31D9D2996DEB6DD@MONODC7138> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - lb4.webmarketingexperts.com.au X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - welcome.aexp.com X-Get-Message-Sender-Via: lb4.webmarketingexperts.com.au: authenticated_id: high@solutionspluspartnership.com.au X-Authenticated-Sender: lb4.webmarketingexperts.com.au: high@solutionspluspartnership.com.au Content-Type: text/plain; charset="windows-1257"; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 17:42:59 -0000 Important Notification Please note that starting from November 27, 2015 we will be introducing new= login authentication procedures in order to protect the information of our= customers. You are required to complete our account verification process and confirm t= he details you have registered with us as you will not be able to have acce= ss to your account until this has been completed, please click the link bel= ow to get started Get Started Please Note: It is essential you complete this process in order for us to s= afeguard your account, failure to do so may lead to permanent restrictions = being place on your account Best regards, American Express Customer Services Copyright =A9 2015 - Please do not reply directly to this email American E= xpress Company From owner-freebsd-fs@freebsd.org Fri Nov 20 23:52:12 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E1D5A33BAF for ; Fri, 20 Nov 2015 23:52:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 143FD1A28 for ; Fri, 20 Nov 2015 23:52:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAKNqBw0048853 for ; Fri, 20 Nov 2015 23:52:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 195303] [zfs] large_blocks enabled on pool, recordsize capped at 1M, minor typo in error message when attempting to create dataset with recordsize=2M Date: Fri, 20 Nov 2015 23:52:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vsasjason@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 23:52:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195303 --- Comment #3 from Anton Sayetsky --- BTW, on 10.2-RELEASE-p7: root@cs0:~# zfs set recordsize=2m ztemp cannot set property for 'ztemp': 'recordsize' must be power of 2 from 512B to 1024KB root@cs0:~# I have no access to any of -CURRENT machines, but I think that problem has been already fixed there too (because of MFC/MFS rule). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sat Nov 21 00:52:04 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32B76A2EBDA for ; Sat, 21 Nov 2015 00:52:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1AD241B4A for ; Sat, 21 Nov 2015 00:52:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAL0q3uB043700 for ; Sat, 21 Nov 2015 00:52:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 18874] [2TB] 32bit NFS servers export wrong negative values to 64bit clients Date: Sat, 21 Nov 2015 00:52:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 5.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 00:52:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=18874 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed --- Comment #25 from Rick Macklem --- Since this cannot happen with the new NFS client and server, I figure it can be closed. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sat Nov 21 08:27:26 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EE5DA341A9 for ; Sat, 21 Nov 2015 08:27:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83B321F84 for ; Sat, 21 Nov 2015 08:27:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAL8RQn8088272 for ; Sat, 21 Nov 2015 08:27:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204705] zfs receive mounts received dataset even if -u is given Date: Sat, 21 Nov 2015 08:27:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 08:27:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204705 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org Keywords| |patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sat Nov 21 18:46:55 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49CDDA34F51 for ; Sat, 21 Nov 2015 18:46:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34538177E for ; Sat, 21 Nov 2015 18:46:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tALIktUA084333 for ; Sat, 21 Nov 2015 18:46:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204705] zfs receive mounts received dataset even if -u is given Date: Sat, 21 Nov 2015 18:46:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vlad-fbsd@acheronmedia.com X-Bugzilla-Status: Open X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 18:46:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204705 --- Comment #6 from Vlad K. --- I tested it against r291085, the line numbers were different but I located the only place in the file where the code appears. It looks like that fixed it. Tried the procedure again and the dataset is not remounted with -Fdu onto existing dataset. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sat Nov 21 20:32:10 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 190D2A345BC for ; Sat, 21 Nov 2015 20:32:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0546F1D9F for ; Sat, 21 Nov 2015 20:32:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tALKW991062707 for ; Sat, 21 Nov 2015 20:32:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204705] zfs receive mounts received dataset even if -u is given Date: Sat, 21 Nov 2015 20:32:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 20:32:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204705 --- Comment #7 from Andriy Gapon --- Thank you! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sat Nov 21 22:10:54 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74687A34C0B for ; Sat, 21 Nov 2015 22:10:54 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 12E3E1FED for ; Sat, 21 Nov 2015 22:10:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:RSzmtBK7DQMK/EQiptmcpTZWNBhigK39O0sv0rFitYgULfTxwZ3uMQTl6Ol3ixeRBMOAu68C1bWd6vu5EUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35nxib/5osaKKyxzxxODIppKZC2sqgvQssREyaBDEY0WjiXzn31TZu5NznlpL1/A1zz158O34YIxu38I46Fp34d6XK77Z6U1S6BDRHRjajhtpZ6jiR6WYxGC61Enfi04qVIcDRLI4RvhUtL/qQP0rOdw0jKWe8rsQuZndy6l6vJRSRTrwAIOPD09/WSf3tZ1halYpB+kjwF4zJPZZJmVcvF3KPCONegGTHZMC54CHxdKBZmxOs5WV7IM X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CmBACi6lBW/61jaINehQPAfYYPgW0RAQEBAQEBAQGBCYItgg4jQyUBIgINGQJbBIhBn12PcI9fDAEggQGFU4kiBhEBAgSDM4FEBYJwiySIPI8Mh2WTCQI3LIQiIIQVCRcDIIEHAQEB X-IronPort-AV: E=Sophos;i="5.20,329,1444708800"; d="scan'208";a="253379002" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 21 Nov 2015 17:10:46 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id C537715F55D for ; Sat, 21 Nov 2015 17:10:46 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id L6N-SVF-gqdM for ; Sat, 21 Nov 2015 17:10:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 5AC5415F565 for ; Sat, 21 Nov 2015 17:10:46 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0ddj8p-WVSy4 for ; Sat, 21 Nov 2015 17:10:46 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 42A2115F55D for ; Sat, 21 Nov 2015 17:10:46 -0500 (EST) Date: Sat, 21 Nov 2015 17:10:46 -0500 (EST) From: Rick Macklem To: FreeBSD FS Message-ID: <903462113.99454723.1448143846156.JavaMail.zimbra@uoguelph.ca> Subject: donation of old laptop for pNFS server development MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: donation of old laptop for pNFS server development Thread-Index: DO6+R63Khi7mDdh3OrAt6t0M5PVJtw== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 22:10:54 -0000 Hi, I hope to do some work (no guarantee w.r.t. timing or results) on using GlusterFS to support a NFSv4.1 pNFS server cluster for FreeBSD. Since I'll be spending the winter "on the road", all I can take with me are laptops. Before you think the request is "extravagant", read what I don't need (after the "what I do need"). What I need: - laptop that runs FreeBSD/amd64 (don't care how fast or how many cores, it just has to be amd64, since that is the only arch that the GlusterFS port builds on) - keyboard/screen as console - working wired ethernet port - some way of installing FreeBSD (CD-reader, USB port that boots a thumb driver or ??) What I don't need: - good battery (I don't care so long as it works plugged into a power brick) - suspend/resume, X-windows, wifi, sound (couldn't care less if any of these work) If you happen to have one of these lying around with a bad battery or ??? and are willing to donate it to me for this work, just email. (I'm in Canada, so parcel post is probably the way you could get it to me.) Thanks, rick