From owner-xfs@oss.sgi.com Fri Jun 1 10:06:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Jun 2007 10:06:32 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l51H6QWt007883 for ; Fri, 1 Jun 2007 10:06:27 -0700 Received: by wr-out-0506.google.com with SMTP id i22so545183wra for ; Fri, 01 Jun 2007 10:06:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:cc:content-type:date:message-id:mime-version:x-mailer; b=pz8R51Z6i4fOJfGtBhElNE7doQo34Mxu8YBbcj/g6nnTqdxmT2b6Ndl4o9hQ4xs4yCfUqOp0MVBiDsaJv6BZoDeH7Hb7a03ss/hI++nEQdiUbMd8u0bby88XUFTQcbzMsD4N6Dnne8xCpeoMkR2ptMYu4n4ZeleqX+zPb0OvHIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:to:cc:content-type:date:message-id:mime-version:x-mailer; b=RS+qe2Re2iokfmxCG49fuFKhW4o2bj9huEjL2J+HJ47vaj2ba1sFNKlxK5LhpliE7KlNvTJK/JkF0RsNc4HA7LCWG2pQNm28TWS4nIGGqteHerkn3Xoi/wId323QAmk+FceW06rDxk2/qw9hzACnW4dF0KQCHlwF022nOvayuUw= Received: by 10.78.193.19 with SMTP id q19mr1313567huf.1180715979445; Fri, 01 Jun 2007 09:39:39 -0700 (PDT) Received: from ?192.168.1.55? ( [84.59.122.193]) by mx.google.com with ESMTP id f7sm484088nfh.2007.06.01.09.39.36; Fri, 01 Jun 2007 09:39:36 -0700 (PDT) Subject: XFS shrink functionality From: Ruben Porras To: xfs@oss.sgi.com Cc: iusty@k1024.org, cw@f00f.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cNVvu74QiAC041q1y3BN" Date: Fri, 01 Jun 2007 18:39:34 +0200 Message-Id: <1180715974.10796.46.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 X-archive-position: 11572 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nahoo82@gmail.com Precedence: bulk X-list: xfs --=-cNVvu74QiAC041q1y3BN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello,=20 I'm investigating the possibility to write myself the necessary code to shrink an xfs filesystem (I'd be able to dedicate a day/week). Trying to know if something is already done I came across the mails of a previous intent [0], [1] (I'm cc'ing the people involved).=20 At a first glance the patch is a little outdated and will no more apply (as of linux 2.16.18, which is the last customised kernel that I was able to run under a XEN environment), because at least the function xfs_fs_geometry is changed.=20 I'm really curious about what happened to this patches and why they were discontinued. The second part never was made public, and there was also no answer. Was there any flaw in any of the posted code or anything in XFS that makes it especially hard to shrink [3] that discouraged the development? After that, the first questions that arouse are, would there be some assistance/groove in from the developers?=20 How doable is it? What are the programmers requirements from your point of view? Thank you. [1] http://oss.sgi.com/archives/xfs/2005-08/msg00142.html [2] http://oss.sgi.com/archives/xfs/2005-09/msg00038.html [3] the only limitation that I might think of is not being able to shrink past the internal journal. --=-cNVvu74QiAC041q1y3BN Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGYEvGYubrKblAx+oRAhjZAJ4terI47D96a4JX8wsyge5iA/f6nQCgkTeN 3qlB2vKeB7015poCrDexuWQ= =7rZq -----END PGP SIGNATURE----- --=-cNVvu74QiAC041q1y3BN-- From owner-xfs@oss.sgi.com Fri Jun 1 18:14:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Jun 2007 18:14:11 -0700 (PDT) Received: from silver.tritoncore.com (silver.tritoncore.com [209.59.142.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l521E6Wt027310 for ; Fri, 1 Jun 2007 18:14:08 -0700 Received: from powersle by silver.tritoncore.com with local (Exim 4.63) (envelope-from ) id 1HtotX-00045K-VP for xfs@oss.sgi.com; Thu, 31 May 2007 13:57:08 -0400 To: xfs@oss.sgi.com Subject: Vacancy! Vacancy!! Vacancy!!! From: "Kenneth Fabrics Ltd." Reply-To: kennethfabricsltdd@mail2recruiter.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: Date: Thu, 31 May 2007 13:57:07 -0400 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - silver.tritoncore.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [32761 32002] / [47 12] X-AntiAbuse: Sender Address Domain - silver.tritoncore.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 11573 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: employment.dept@kennethfabricsltd.com Precedence: bulk X-list: xfs From The Desk Of The: Recruitment Manager Mr Kenneth Holley Kenneth Fabrics Limited. Dear , KENNETH FABRICS LTD.Is committed to global citizenship by operating in a responsible and sustainable manner around the globe. As part of our Multi Level Marketing scheme, we need capable hands to act as representative/book keeper in the United Kingdom and Canada on the company’s behalf. Kenneth Fabrics Ltd.. Is a new Store under KENNETH FARICS in India? We are into supplies of Raw Materials. We are ranked No.1 among India private enterprises with annual production capacity exceeding 1 million units sold everywhere in India and exported to all over the world including UK, Mexico, Southeast Asia countries and European countries. We have won a good reputation for high-quality products, prompt delivery and close cooperation among our customers. We needs a representative in the United states, United Kingdom, Canada, Mexico, Southeast Asia countries and European countries, to act as our Online Staff through which our customers can pay outstanding bills owed by them to us in your Region via Bank Wire Transfer. JOB DESCRIPTION: 1. Receive payment from Clients by wire transfer and Cheques 2. Deduct 10% which will be your commission on each payment processed. 3. Forward the balance after deducting of 10% commission to offices which shall be provided by you as soon as the fund becomes available. HOW MUCH WILL YOU EARN: 10% from each operation! For instance: you receive £ 5000 or $5000 via wire transfer Or Cheques on our behalf. You will cash the money and keep £ 500 or $500 (10% from £ 5000-$5000) for yourself! At the beginning your commission will equal 10%. After creditable performance, your commission may be reviewed for increment. We are looking only for the Honest and Open – Hearted Individual who satisfies our requirements and glad to offer this job position to you. If our proposals interest you, Do get back to us with your under listed detailed information; Names:.................. Address:................ City:................... Zip Code:............... State:.................. Country;................ Home Phone:............. Cell Phone:............. Gender:................. Age..................... Thanks for Reading Our Job Offer Kenneth Fabrics Limited 301-A, World Trade Tower Barakhamba Lane New Delhi -110001 India From owner-xfs@oss.sgi.com Sat Jun 2 14:25:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 14:25:03 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l52LOxWt024035 for ; Sat, 2 Jun 2007 14:25:00 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 57052B000083; Sat, 2 Jun 2007 17:24:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 51C8350001A7; Sat, 2 Jun 2007 17:24:58 -0400 (EDT) Date: Sat, 2 Jun 2007 17:24:58 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: linux-kernel@vger.kernel.org cc: xfs@oss.sgi.com Subject: Kernel 2.6.22-rc3 safe to migrate to? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 11574 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Wondering as their were a lot of XFS related issues early on in development..? The 2.6.22-rc3 kernel has the core 2 duo coretemp patch by ruik which I want be running as long as 2.6.22-rc3 does not have any severe XFS issues? Justin. From owner-xfs@oss.sgi.com Sat Jun 2 14:35:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 14:35:57 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l52LZsWt026693 for ; Sat, 2 Jun 2007 14:35:54 -0700 Received: by wa-out-1112.google.com with SMTP id l24so1189895waf for ; Sat, 02 Jun 2007 14:35:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=GN6AfKnezeJpV3TkJoPQujAokhgjWw2yXxH39wXfwWmEBMPzjSn5b18uVJz0I44qkZ7JlLX2AjJGOFsCIZ1VL/P3VBlSPD0uHydGGIFfXcrm+nuSlnQGBnj3EUHonhkvz67PqPV03jsfIDTUqzwRMml8yTWRnkwUYfdSXk0+/Ps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=gmPrf1JYRMcZujT3O3OgGZOA+Fet2Agyr5OC5Mv8kUQhx7Whpj/65MZTNhL9JHW3Naw4ZgAhSDyQ5EzvV2c1JT51N+v2KWBIbM/9sl41kS3m0JZ/ljOzE9LANaV3kDL96+kLPIUNYURQZRFa59qIIV0Lz9s4eMysTY8e97RBZ9E= Received: by 10.115.92.2 with SMTP id u2mr3130430wal.1180818448644; Sat, 02 Jun 2007 14:07:28 -0700 (PDT) Received: by 10.114.14.8 with HTTP; Sat, 2 Jun 2007 14:07:28 -0700 (PDT) Message-ID: <5d96567b0706021407q4455b60asd9d23ef82cb90b55@mail.gmail.com> Date: Sun, 3 Jun 2007 00:07:28 +0300 From: "Raz Ben-Jehuda(caro)" To: linux-xfs@oss.sgi.com Subject: corruption bug in 2.6.17 Cc: alkirkco@sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 11575 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs Mandy Hello I have got into a serious trouble with xfs . I had some directories returning "no such file or directory". This xfs file system is over a raid5 of 4 disks, with 1MB stripe unit size. files are hierarchly being "XFS_IOC_FSSETXATTR" extended to 1MB. when I tried to create a new file I got the bellow oops. could it be that your fix for 2.6.17.7 solves this problem ? thank you. raz 4499008.609000] Filesystem "md1": XFS internal error xfs_dir2_block_addname at line 105 of file fs/xfs/xfs_dir2_block.c. Caller 0xc10e7e1c [4499008.634000] xfs_dir2_block_addname+0x88b/0x8a9 xfs_dir2_createname+0x11a/0x179 [4499008.654000] xfs_dir2_createname+0x11a/0x179 xfs_bmap_last_offset+0xce/0x128 [4499008.673000] xfs_dir2_isblock+0x32/0x82 xfs_dir2_createname+0x11a/0x179 [4499008.690000] kmem_zone_alloc+0x57/0xc5 xfs_trans_ijoin+0x35/0x7f [4499008.707000] xfs_create+0x45b/0x7aa xfs_vn_mknod+0x2f9/0x37e [4499008.725000] xfs_vn_lookup+0x79/0x96 lookup_mnt+0x32/0x5c [4499008.741000] do_lookup+0x50/0xa8 dput+0x23/0x183 [4499008.755000] __link_path_walk+0x50/0xe17 lookup_mnt+0x32/0x5c [4499008.772000] mntput_no_expire+0x22/0xb1 mntput_no_expire+0x22/0xb1 [4499008.789000] link_path_walk+0x71/0xc9 permission+0x7e/0x9b [4499008.805000] vfs_create+0x7d/0x122 open_namei+0x69e/0x6ff [4499008.820000] page_add_file_rmap+0x29/0x2b do_filp_open+0x43/0x61 [4499008.837000] do_sys_open+0x57/0xe1 sys_open+0x27/0x2b [4499008.852000] syscall_call+0x7/0xb [4499008.863000] Filesystem "md1": XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c. Caller 0xc112100e [4499008.886000] xfs_trans_cancel+0x103/0x136 xfs_create+0x2ec/0x7aa [4499008.903000] xfs_create+0x2ec/0x7aa xfs_vn_mknod+0x2f9/0x37e [4499008.918000] xfs_vn_lookup+0x79/0x96 lookup_mnt+0x32/0x5c [4499008.935000] do_lookup+0x50/0xa8 dput+0x23/0x183 [4499008.948000] __link_path_walk+0x50/0xe17 lookup_mnt+0x32/0x5c [4499008.966000] mntput_no_expire+0x22/0xb1 mntput_no_expire+0x22/0xb1 [4499008.983000] link_path_walk+0x71/0xc9 permission+0x7e/0x9b [4499008.999000] vfs_create+0x7d/0x122 open_namei+0x69e/0x6ff [4499009.015000] page_add_file_rmap+0x29/0x2b do_filp_open+0x43/0x61 [4499009.031000] do_sys_open+0x57/0xe1 sys_open+0x27/0x2b [4499009.046000] syscall_call+0x7/0xb [4499009.057000] xfs_force_shutdown(md1,0x8) called from line 1151 of file fs/xfs/xfs_trans.c. Return address = 0xc1131b54 [4499009.078000] Filesystem "md1": Corruption of in-memory data detected. Shutting down filesystem: md1 [4499009.097000] Please umount the filesystem, and rectify the problem(s) -- Raz From owner-xfs@oss.sgi.com Sat Jun 2 14:56:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 14:56:37 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l52LuYWt003639 for ; Sat, 2 Jun 2007 14:56:35 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 8B9C4B000083; Sat, 2 Jun 2007 17:39:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 856EA50001A7; Sat, 2 Jun 2007 17:39:13 -0400 (EDT) Date: Sat, 2 Jun 2007 17:39:13 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: "Raz Ben-Jehuda(caro)" cc: linux-xfs@oss.sgi.com, alkirkco@sgi.com Subject: Re: corruption bug in 2.6.17 In-Reply-To: <5d96567b0706021407q4455b60asd9d23ef82cb90b55@mail.gmail.com> Message-ID: References: <5d96567b0706021407q4455b60asd9d23ef82cb90b55@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 11576 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Raz, 2.6.17-2.6.17.6 had the nasty corruption bug you're seeing, best to restore from backup and/or check the FAQ and get off that kernel range asap. On Sun, 3 Jun 2007, Raz Ben-Jehuda(caro) wrote: > Mandy Hello > > I have got into a serious trouble with xfs . I had some directories > returning "no such file or directory". This xfs file system is over a > raid5 of 4 disks, with 1MB stripe unit size. files are hierarchly > being "XFS_IOC_FSSETXATTR" extended to 1MB. > > when I tried to create a new file I got the bellow oops. > could it be that your fix for 2.6.17.7 solves this problem ? > thank you. > raz > > 4499008.609000] Filesystem "md1": XFS internal error > xfs_dir2_block_addname at line 105 of file fs/xfs/xfs_dir2_block.c. > Caller 0xc10e7e1c > [4499008.634000] xfs_dir2_block_addname+0x88b/0x8a9 > xfs_dir2_createname+0x11a/0x179 > [4499008.654000] xfs_dir2_createname+0x11a/0x179 > xfs_bmap_last_offset+0xce/0x128 > [4499008.673000] xfs_dir2_isblock+0x32/0x82 > xfs_dir2_createname+0x11a/0x179 > [4499008.690000] kmem_zone_alloc+0x57/0xc5 > xfs_trans_ijoin+0x35/0x7f > [4499008.707000] xfs_create+0x45b/0x7aa > xfs_vn_mknod+0x2f9/0x37e > [4499008.725000] xfs_vn_lookup+0x79/0x96 > lookup_mnt+0x32/0x5c > [4499008.741000] do_lookup+0x50/0xa8 dput+0x23/0x183 > [4499008.755000] __link_path_walk+0x50/0xe17 > lookup_mnt+0x32/0x5c > [4499008.772000] mntput_no_expire+0x22/0xb1 > mntput_no_expire+0x22/0xb1 > [4499008.789000] link_path_walk+0x71/0xc9 > permission+0x7e/0x9b > [4499008.805000] vfs_create+0x7d/0x122 > open_namei+0x69e/0x6ff > [4499008.820000] page_add_file_rmap+0x29/0x2b > do_filp_open+0x43/0x61 > [4499008.837000] do_sys_open+0x57/0xe1 > sys_open+0x27/0x2b > [4499008.852000] syscall_call+0x7/0xb > [4499008.863000] Filesystem "md1": XFS internal error xfs_trans_cancel > at line 1150 of file fs/xfs/xfs_trans.c. Caller 0xc112100e > [4499008.886000] xfs_trans_cancel+0x103/0x136 > xfs_create+0x2ec/0x7aa > [4499008.903000] xfs_create+0x2ec/0x7aa > xfs_vn_mknod+0x2f9/0x37e > [4499008.918000] xfs_vn_lookup+0x79/0x96 > lookup_mnt+0x32/0x5c > [4499008.935000] do_lookup+0x50/0xa8 dput+0x23/0x183 > [4499008.948000] __link_path_walk+0x50/0xe17 > lookup_mnt+0x32/0x5c > [4499008.966000] mntput_no_expire+0x22/0xb1 > mntput_no_expire+0x22/0xb1 > [4499008.983000] link_path_walk+0x71/0xc9 > permission+0x7e/0x9b > [4499008.999000] vfs_create+0x7d/0x122 > open_namei+0x69e/0x6ff > [4499009.015000] page_add_file_rmap+0x29/0x2b > do_filp_open+0x43/0x61 > [4499009.031000] do_sys_open+0x57/0xe1 > sys_open+0x27/0x2b > [4499009.046000] syscall_call+0x7/0xb > [4499009.057000] xfs_force_shutdown(md1,0x8) called from line 1151 of > file fs/xfs/xfs_trans.c. Return address = 0xc1131b54 > [4499009.078000] Filesystem "md1": Corruption of in-memory data > detected. Shutting down filesystem: md1 > [4499009.097000] Please umount the filesystem, and rectify the problem(s) > > > -- > Raz > > From owner-xfs@oss.sgi.com Sat Jun 2 14:59:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 14:59:14 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l52Lx9Wt005112 for ; Sat, 2 Jun 2007 14:59:10 -0700 Received: from [82.41.246.210] (helo=[10.0.0.30]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Hubck-0003Ai-Dd; Sat, 02 Jun 2007 23:59:02 +0200 Date: Sat, 2 Jun 2007 22:59:01 +0100 (BST) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Justin Piszcz cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-archive-position: 11577 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Sat, 2 Jun 2007, Justin Piszcz wrote: > Wondering as their were a lot of XFS related issues early on in > development..? The 2.6.22-rc3 kernel has the core 2 duo coretemp patch by > ruik which I want be running as long as 2.6.22-rc3 does not have any severe > XFS issues? Tracking -rc and running 2.6.22-rc3 for a couple of days now, no problems with xfs since this infamous 2.6.17 thingy[0]. But that's pretty useless information I guess, since your setup will be different from mine. Did you have anything "special" in mind when asking this? C. [0] http://oss.sgi.com/projects/xfs/faq.html#dir2 -- BOFH excuse #339: manager in the cable duct From owner-xfs@oss.sgi.com Sat Jun 2 15:09:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 15:09:35 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l52M9UWt009389 for ; Sat, 2 Jun 2007 15:09:32 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 1F629B000083; Sat, 2 Jun 2007 18:09:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 1C358500014A; Sat, 2 Jun 2007 18:09:30 -0400 (EDT) Date: Sat, 2 Jun 2007 18:09:30 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Christian Kujau cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 11578 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sat, 2 Jun 2007, Christian Kujau wrote: > On Sat, 2 Jun 2007, Justin Piszcz wrote: >> Wondering as their were a lot of XFS related issues early on in >> development..? The 2.6.22-rc3 kernel has the core 2 duo coretemp patch by >> ruik which I want be running as long as 2.6.22-rc3 does not have any severe >> XFS issues? > > Tracking -rc and running 2.6.22-rc3 for a couple of days now, no problems > with xfs since this infamous 2.6.17 thingy[0]. But that's pretty useless > information I guess, since your setup will be different from mine. Did you > have anything "special" in mind when asking this? > > C. > > [0] http://oss.sgi.com/projects/xfs/faq.html#dir2 > -- > BOFH excuse #339: > > manager in the cable duct > Thanks, I'll give it a go then--! From owner-xfs@oss.sgi.com Sat Jun 2 15:27:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 15:27:09 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l52MR5Wt016783 for ; Sat, 2 Jun 2007 15:27:06 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 8F780B000083; Sat, 2 Jun 2007 18:27:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 8BAB15000149; Sat, 2 Jun 2007 18:27:05 -0400 (EDT) Date: Sat, 2 Jun 2007 18:27:05 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Christian Kujau cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 11579 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Jun 2 18:23:23 p34 upsd[2225]: Can't connect to UPS [belkin] (newhidups-auto): No such file or directory Jun 2 18:24:23 p34 upsmon[2228]: Poll UPS [belkin@localhost] failed - Driver not connected Hmm, something changes with USB in 2.6.22-rc3 form 2.6.21.. On Sat, 2 Jun 2007, Christian Kujau wrote: > On Sat, 2 Jun 2007, Justin Piszcz wrote: >> Wondering as their were a lot of XFS related issues early on in >> development..? The 2.6.22-rc3 kernel has the core 2 duo coretemp patch by >> ruik which I want be running as long as 2.6.22-rc3 does not have any severe >> XFS issues? > > Tracking -rc and running 2.6.22-rc3 for a couple of days now, no problems > with xfs since this infamous 2.6.17 thingy[0]. But that's pretty useless > information I guess, since your setup will be different from mine. Did you > have anything "special" in mind when asking this? > > C. > > [0] http://oss.sgi.com/projects/xfs/faq.html#dir2 > -- > BOFH excuse #339: > > manager in the cable duct > > From owner-xfs@oss.sgi.com Sat Jun 2 15:52:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 15:53:02 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l52MqwWt032611 for ; Sat, 2 Jun 2007 15:52:59 -0700 Received: from [82.41.246.210] (helo=[10.0.0.30]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Hubhc-0003SC-Op; Sun, 03 Jun 2007 00:04:04 +0200 Date: Sat, 2 Jun 2007 23:04:03 +0100 (BST) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: "Raz Ben-Jehuda(caro)" cc: linux-xfs@oss.sgi.com, alkirkco@sgi.com Subject: Re: corruption bug in 2.6.17 In-Reply-To: <5d96567b0706021407q4455b60asd9d23ef82cb90b55@mail.gmail.com> Message-ID: References: <5d96567b0706021407q4455b60asd9d23ef82cb90b55@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed X-archive-position: 11580 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Sun, 3 Jun 2007, Raz Ben-Jehuda(caro) wrote: > when I tried to create a new file I got the bellow oops. > could it be that your fix for 2.6.17.7 solves this problem ? If you're running a 2.6.17 kernel (< 2.6.17.7) when you're getting these errors, I guess it's most likely this particular 2.6.17-bug. Please read http://oss.sgi.com/projects/xfs/faq.html#dir2 very carefully and upgrade xfsprogs and your kernel. C. -- BOFH excuse #55: Plumber mistook routing panel for decorative wall fixture From owner-xfs@oss.sgi.com Sat Jun 2 15:54:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 15:54:18 -0700 (PDT) Received: from mail.goop.org (gw.goop.org [64.81.55.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l52MsEWt000899 for ; Sat, 2 Jun 2007 15:54:14 -0700 Received: by lurch.goop.org (Postfix, from userid 525) id 4E4B72C8058; Sat, 2 Jun 2007 15:53:17 -0700 (PDT) Received: from lurch.goop.org (localhost [127.0.0.1]) by lurch.goop.org (Postfix) with ESMTP id 2EB9B2C8053; Sat, 2 Jun 2007 15:53:17 -0700 (PDT) Received: from [192.168.28.126] (outer-dhcp-126.goop.org [192.168.28.126]) by lurch.goop.org (Postfix) with ESMTP; Sat, 2 Jun 2007 15:53:17 -0700 (PDT) Message-ID: <4661F511.4070207@goop.org> Date: Sat, 02 Jun 2007 15:54:09 -0700 From: Jeremy Fitzhardinge User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Justin Piszcz CC: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 11581 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeremy@goop.org Precedence: bulk X-list: xfs Justin Piszcz wrote: > Wondering as their were a lot of XFS related issues early on in > development..? The 2.6.22-rc3 kernel has the core 2 duo coretemp patch > by ruik which I want be running as long as 2.6.22-rc3 does not have > any severe XFS issues? XFS currently has a data-corrupting bug, where files which were appended by small amounts may lose their updates on umount - I see this corrupting hg repos. There's a patch which works for me, and is in 2.6.22-rc3-mm1, but it hasn't been merged upstream yet. J From owner-xfs@oss.sgi.com Sat Jun 2 15:55:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 15:55:48 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l52MtiWt001689 for ; Sat, 2 Jun 2007 15:55:45 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 33BA8B000083; Sat, 2 Jun 2007 18:55:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 317BD5000091; Sat, 2 Jun 2007 18:55:45 -0400 (EDT) Date: Sat, 2 Jun 2007 18:55:45 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Jeremy Fitzhardinge cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? In-Reply-To: <4661F511.4070207@goop.org> Message-ID: References: <4661F511.4070207@goop.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 11582 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sat, 2 Jun 2007, Jeremy Fitzhardinge wrote: > Justin Piszcz wrote: >> Wondering as their were a lot of XFS related issues early on in >> development..? The 2.6.22-rc3 kernel has the core 2 duo coretemp patch >> by ruik which I want be running as long as 2.6.22-rc3 does not have >> any severe XFS issues? > > XFS currently has a data-corrupting bug, where files which were appended > by small amounts may lose their updates on umount - I see this > corrupting hg repos. There's a patch which works for me, and is in > 2.6.22-rc3-mm1, but it hasn't been merged upstream yet. > > J > > Ah that's it- and USB appears to be broken as well, I'll stick with 2.6.21.3 for now. Thanks! Justin. From owner-xfs@oss.sgi.com Sat Jun 2 16:00:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 16:00:49 -0700 (PDT) Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [207.189.120.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l52N0jWt003744; Sat, 2 Jun 2007 16:00:46 -0700 Received: from localhost (phoenix.linux-foundation.org [207.189.120.27]) by smtp1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id l52Mkqbd009363; Sat, 2 Jun 2007 15:46:53 -0700 Date: Sat, 2 Jun 2007 15:46:47 -0700 (PDT) From: Linus Torvalds To: David Greaves cc: "Rafael J. Wysocki" , xfs@oss.sgi.com, "'linux-kernel@vger.kernel.org'" , netdev@oss.sgi.com, linux-pm Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression In-Reply-To: <4661EFBB.5010406@dgreaves.com> Message-ID: References: <46608E3F.4060201@dgreaves.com> <200706012342.45657.rjw@sisk.pl> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Received-SPF: neutral (207.189.120.27 is neither permitted nor denied by domain of torvalds@linux-foundation.org) X-MIMEDefang-Filter: osdl$Revision: 1.179 $ X-Scanned-By: MIMEDefang 2.53 on 207.189.120.13 X-archive-position: 11583 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: torvalds@linux-foundation.org Precedence: bulk X-list: xfs On Sat, 2 Jun 2007, David Greaves wrote: > > Then 2.6.22-rc3 again but CONFIG_DISABLE_CONSOLE_SUSPEND=y > It suspended again. > Froze on restore. > Screen photo here: > http://www.dgreaves.com/pub/2.6.21-rc3-resume-failure.jpg Ok, it wasn't a hidden oops. The DISABLE_CONSOLE_SUSPEND=y thing sometimes shows oopses that are otherwise hidden, but at other times it just causes more problems (hard hangs when trying to display something on a device that is suspended, or behind a bridge that got suspended). In your case, the screen output just shows normal resume output, and it apparently just hung for some unknown reason. It *may* be worth trying to do a SysRQ + 't' thing to see what tasks are running (or rather, not running), but since you won't be able to capture it, it's probably not going to be useful. > Then 2.6.22-rc3 again but CONFIG_DISABLE_CONSOLE_SUSPEND=y > This time, before suspending I unmounted my xfs/lvm/raid6 filesystem. > Just a umount, I left the devices/array up. > It suspended again. > This time it resumed without fault. It would be interesting to see what triggered it, since it apparently worked before. So yes, a bisection would be great. Linus From owner-xfs@oss.sgi.com Sat Jun 2 16:02:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 16:02:16 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l52N29Wt004683; Sat, 2 Jun 2007 16:02:11 -0700 Received: from localhost (mailman.ukfsn.org [80.168.53.75]) by mail.ukfsn.org (Postfix) with ESMTP id B51C7E6CAD; Sat, 2 Jun 2007 23:31:21 +0100 (BST) Received: from mail.ukfsn.org ([80.168.53.20]) by localhost (smtp-filter.ukfsn.org [80.168.53.75]) (amavisd-new, port 10024) with ESMTP id BfTBdpdPbsQE; Sat, 2 Jun 2007 23:29:21 +0100 (BST) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 2406EE6C62; Sat, 2 Jun 2007 23:31:21 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1Huc83-0003U5-Kv; Sat, 02 Jun 2007 23:31:23 +0100 Message-ID: <4661EFBB.5010406@dgreaves.com> Date: Sat, 02 Jun 2007 23:31:23 +0100 From: David Greaves User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: "Rafael J. Wysocki" , Linus Torvalds , xfs@oss.sgi.com Cc: "'linux-kernel@vger.kernel.org'" , netdev@oss.sgi.com, linux-pm Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression References: <46608E3F.4060201@dgreaves.com> <200706012342.45657.rjw@sisk.pl> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> In-Reply-To: <200706020122.49989.rjw@sisk.pl> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 11584 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs This started as a non-regression bug-report about wakeonlan During tests I found a real regression and this email is only about 2.6.22-rc3 without Rafael's patches - which I'll happily come back to later :) Rafael J. Wysocki wrote: > On Saturday, 2 June 2007 00:37, David Greaves wrote: >> Rafael J. Wysocki wrote: >>> On Friday, 1 June 2007 23:23, David Greaves wrote: >> The real situation is worse :( > > Ouch. > >> 2.6.22-rc3 (no patches) just hangs on suspend at: >> Suspending consoles >> >> console switching works but needs a hard reset to reboot. >> >> 2.6.22-rc3-skge (with Rafael's patches) > Can you set CONFIG_DISABLE_CONSOLE_SUSPEND in .config and see where exactly it > fails? Given that I expected it to fail I unmounted my 1Tb array data before suspending. It succeeded... so I started digging... So I tried again. 2.6.22-rc3 (vanilla) suspended OK this time but on resume hung at: Stopping tasks done Shrinking memory done (0 pages freed) Freed 0 kb in 0.0 secs (0.0MB/s) Suspending console(s) Then 2.6.22-rc3 again but CONFIG_DISABLE_CONSOLE_SUSPEND=y It suspended again. Froze on restore. Screen photo here: http://www.dgreaves.com/pub/2.6.21-rc3-resume-failure.jpg Then 2.6.22-rc3 again but CONFIG_DISABLE_CONSOLE_SUSPEND=y This time, before suspending I unmounted my xfs/lvm/raid6 filesystem. Just a umount, I left the devices/array up. It suspended again. This time it resumed without fault. The machine has another xfs filesystem : /dev/hdb2 on /scratch type xfs (rw) I've started bisecting... any other info needed? David Added Linus as it's a regression Added xfs as unmounting an xfs filesystem 'fixes' it. From owner-xfs@oss.sgi.com Sat Jun 2 17:27:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 17:27:28 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l530RMWt003142 for ; Sat, 2 Jun 2007 17:27:24 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id C6A05B000083; Sat, 2 Jun 2007 20:27:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id C019150025A7; Sat, 2 Jun 2007 20:27:22 -0400 (EDT) Date: Sat, 2 Jun 2007 20:27:22 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Christian Kujau cc: Jeremy Fitzhardinge , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? In-Reply-To: Message-ID: References: <4661F511.4070207@goop.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 11586 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sun, 3 Jun 2007, Christian Kujau wrote: > On Sat, 2 Jun 2007, Justin Piszcz wrote: >> On Sat, 2 Jun 2007, Jeremy Fitzhardinge wrote: >>> XFS currently has a data-corrupting bug, where files which were appended >>> by small amounts may lose their updates on umount - I see this >>> corrupting hg repos. There's a patch which works for me, and is in >>> 2.6.22-rc3-mm1, but it hasn't been merged upstream yet. > > Just for the record, you mean this one: > http://lkml.org/lkml/2007/5/12/93 ..right? (haven't been bitten by this > one...yet) > >> Ah that's it- and USB appears to be broken as well, I'll stick with >> 2.6.21.3 for now. > > Got any pointers? I'm using USB right now, one is i386 with 2.6.22-rc3, > another one is powerpc, tracking -git and USB seems to work. > > C. > -- > BOFH excuse #15: > > temporary routing anomaly > Sent this in another e-mail to LKML, it breaks support for my UPS: From jpiszcz@lucidpixels.com Sat Jun 2 18:43:52 2007 Date: Sat, 2 Jun 2007 18:43:52 -0400 (EDT) From: Justin Piszcz To: linux-kernel@vger.kernel.org Subject: Kernel 2.6.22-rc3 breaks USB: Unable to get HID descriptor (error sending control message: Operation not permitted) I use nut-2.0.4-4 with a UPS attached via USB and from 2.6.21.3 -> 2.6.22-rc3 it stops working, see below. My .config is attached. 2.6.21.3: p34:~# /lib/nut/newhidups -u nut -DDDDDD auto Checking device (050D/0912) (005/002) - VendorID: 050d - ProductID: 0912 - Manufacturer: - Product: UPS - Serial Number: unknown - Bus: 005 Trying to match device Device matches HID descriptor retrieved (Reportlen = 820) Size read for the report descriptor: 820 Report descriptor retrieved (Reportlen = 820) Found HID device Network UPS Tools: New USB/HID UPS driver 0.28 (2.0.4) Report Descriptor size = 820 Report Descriptor: (200 bytes) => 05 84 09 04 A1 01 05 86 09 26 A1 02 85 01 75 08 Detected a UPS: /UPS Using subdriver: Belkin HID 0.1 Looking up 00840004 Looking up 00860026 Looking up 00860040 entering string_to_path() parsing UPS Looking up UPS hid_lookup_usage: found 840004 parsing BELKINConfig Looking up BELKINConfig hid_lookup_usage: found 860026 parsing BELKINConfigVoltage Looking up BELKINConfigVoltage hid_lookup_usage: found 860040 Path depth = 3 0: UPage(84), Usage(4) 1: UPage(86), Usage(26) 2: UPage(86), Usage(40) Entering libusb_get_report =>> Before exponent: 120, 0/0) =>> After conversion: 120.000000 (120), 0/0) Report : (8 bytes) => 01 78 80 00 00 00 00 00 Path: UPS.BELKINConfig.BELKINConfigVoltage, Type: Feature, Value: 120.000000 Looking up 00840004 Looking up 00860026 Looking up 00860042 (works fine) 2.6.22-rc3: p34:~# /lib/nut/newhidups -u nut -DDDDDD auto Checking device (050D/0912) (005/002) - VendorID: 050d - ProductID: 0912 - Manufacturer: unknown - Product: unknown - Serial Number: unknown - Bus: 005 Trying to match device Device matches failed to claim USB device, trying 2 more time(s)... detaching kernel driver from USB device... failed to detach kernel driver from USB device... trying again to claim USB device... failed to claim USB device, trying 1 more time(s)... detaching kernel driver from USB device... failed to detach kernel driver from USB device... trying again to claim USB device... failed to claim USB device, trying 0 more time(s)... detaching kernel driver from USB device... failed to detach kernel driver from USB device... trying again to claim USB device... Unable to get HID descriptor (error sending control message: Operation not permitted) [ Part 2, "" Application/OCTET-STREAM (Name: "config-2.6.22-rc3.bz2") ] [ 10KB. ] [ Unable to print this part. ] From owner-xfs@oss.sgi.com Sat Jun 2 17:26:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 17:26:04 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l530PxWt002207 for ; Sat, 2 Jun 2007 17:26:00 -0700 Received: from [82.41.246.210] (helo=[10.0.0.30]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Hudub-0008LF-CH; Sun, 03 Jun 2007 02:25:37 +0200 Date: Sun, 3 Jun 2007 01:25:35 +0100 (BST) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Justin Piszcz cc: Jeremy Fitzhardinge , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? In-Reply-To: Message-ID: References: <4661F511.4070207@goop.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-archive-position: 11585 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Sat, 2 Jun 2007, Justin Piszcz wrote: > On Sat, 2 Jun 2007, Jeremy Fitzhardinge wrote: >> XFS currently has a data-corrupting bug, where files which were appended >> by small amounts may lose their updates on umount - I see this >> corrupting hg repos. There's a patch which works for me, and is in >> 2.6.22-rc3-mm1, but it hasn't been merged upstream yet. Just for the record, you mean this one: http://lkml.org/lkml/2007/5/12/93 ..right? (haven't been bitten by this one...yet) > Ah that's it- and USB appears to be broken as well, I'll stick with 2.6.21.3 > for now. Got any pointers? I'm using USB right now, one is i386 with 2.6.22-rc3, another one is powerpc, tracking -git and USB seems to work. C. -- BOFH excuse #15: temporary routing anomaly From owner-xfs@oss.sgi.com Sat Jun 2 23:30:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Jun 2007 23:31:01 -0700 (PDT) Received: from mail.goop.org (gw.goop.org [64.81.55.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l536UtWt020599 for ; Sat, 2 Jun 2007 23:30:56 -0700 Received: by lurch.goop.org (Postfix, from userid 525) id D7F6C2C805B; Sat, 2 Jun 2007 23:29:57 -0700 (PDT) Received: from lurch.goop.org (localhost [127.0.0.1]) by lurch.goop.org (Postfix) with ESMTP id A9B452C8056; Sat, 2 Jun 2007 23:29:57 -0700 (PDT) Received: from [192.168.28.126] (outer-dhcp-126.goop.org [192.168.28.126]) by lurch.goop.org (Postfix) with ESMTP; Sat, 2 Jun 2007 23:29:57 -0700 (PDT) Message-ID: <46626019.3070807@goop.org> Date: Sat, 02 Jun 2007 23:30:49 -0700 From: Jeremy Fitzhardinge User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Christian Kujau CC: Justin Piszcz , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? References: <4661F511.4070207@goop.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 11587 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeremy@goop.org Precedence: bulk X-list: xfs Christian Kujau wrote: > Just for the record, you mean this one: > http://lkml.org/lkml/2007/5/12/93 ..right? (haven't been bitten by > this one...yet) That's the one. It's fairly subtle; there's no metadata/filesystem corruption, and the file just reverts back to a previous length, so if it were append-only, it would just return to a previous state. J From owner-xfs@oss.sgi.com Sun Jun 3 00:23:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 00:23:51 -0700 (PDT) Received: from pd3mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l537NhWt020808 for ; Sun, 3 Jun 2007 00:23:44 -0700 Received: from pd2mr4so.prod.shaw.ca (pd2mr4so-qfe3.prod.shaw.ca [10.0.141.107]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JJ10086OR3JP670@l-daemon> for xfs@oss.sgi.com; Sun, 03 Jun 2007 00:23:43 -0600 (MDT) Received: from pn2ml3so.prod.shaw.ca ([10.0.121.147]) by pd2mr4so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JJ100A65R3J1M20@pd2mr4so.prod.shaw.ca> for xfs@oss.sgi.com; Sun, 03 Jun 2007 00:23:43 -0600 (MDT) Received: from [192.168.1.113] ([70.64.1.86]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JJ100DXZR3IE3N3@l-daemon> for xfs@oss.sgi.com; Sun, 03 Jun 2007 00:23:42 -0600 (MDT) Date: Sun, 03 Jun 2007 00:23:48 -0600 From: Robert Hancock Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? In-reply-to: To: Justin Piszcz Cc: Christian Kujau , Jeremy Fitzhardinge , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Message-id: <46625E74.8070800@shaw.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) X-archive-position: 11588 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hancockr@shaw.ca Precedence: bulk X-list: xfs Justin Piszcz wrote: > Sent this in another e-mail to LKML, it breaks support for my UPS: > > From jpiszcz@lucidpixels.com Sat Jun 2 18:43:52 2007 > Date: Sat, 2 Jun 2007 18:43:52 -0400 (EDT) > From: Justin Piszcz > To: linux-kernel@vger.kernel.org > Subject: Kernel 2.6.22-rc3 breaks USB: Unable to get HID descriptor > (error sending control message: Operation not permitted) > > I use nut-2.0.4-4 with a UPS attached via USB and from 2.6.21.3 -> > 2.6.22-rc3 it > stops working, see below. My .config is attached. > I also have seen this on -rc2-mm1, my APC UPS status was not showing up. I haven't investigated in any more detail. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ From owner-xfs@oss.sgi.com Sun Jun 3 01:02:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 01:02:18 -0700 (PDT) Received: from mail.goop.org (gw.goop.org [64.81.55.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l53829Wt008118 for ; Sun, 3 Jun 2007 01:02:12 -0700 Received: by lurch.goop.org (Postfix, from userid 525) id C96452C805B; Sun, 3 Jun 2007 01:01:09 -0700 (PDT) Received: from lurch.goop.org (localhost [127.0.0.1]) by lurch.goop.org (Postfix) with ESMTP id A8CAF2C8056; Sun, 3 Jun 2007 01:01:09 -0700 (PDT) Received: from [192.168.28.126] (outer-dhcp-126.goop.org [192.168.28.126]) by lurch.goop.org (Postfix) with ESMTP; Sun, 3 Jun 2007 01:01:09 -0700 (PDT) Message-ID: <46627579.3040507@goop.org> Date: Sun, 03 Jun 2007 01:02:01 -0700 From: Jeremy Fitzhardinge User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Michal Piotrowski CC: Justin Piszcz , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? References: <4661F511.4070207@goop.org> <6bffcb0e0706030059o3e53e647uf3ae1aa3f16609d8@mail.gmail.com> In-Reply-To: <6bffcb0e0706030059o3e53e647uf3ae1aa3f16609d8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-archive-position: 11589 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeremy@goop.org Precedence: bulk X-list: xfs Michal Piotrowski wrote: > It's already merged into mainline > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=df3c7244264f1d12562413aa32d56be802486516 > Oh, good. I hadn't read through the last couple of days of commits. J From owner-xfs@oss.sgi.com Sun Jun 3 01:25:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 01:25:34 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l538PSWt019301 for ; Sun, 3 Jun 2007 01:25:29 -0700 Received: by wa-out-1112.google.com with SMTP id l24so1348090waf for ; Sun, 03 Jun 2007 01:25:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qnDdIp58N/s+cogb5y3YWwYZrtZxI1esxvfHwQizEwtpia3oz6PydT8YZi95ijOBjo/5uMwzsBKfquAIjMTeqAbygVRGt6oMy6V8E3lYVGnr/Wyq1mNIkx/9rdat6Qa0epYb9PKzbuq3yIoacsHw/w9WxXEvDgfl1luj2nzcKGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aws8cpktjN3Zi3FuT+Fpb2VlzJ4nB826yZaHSW3MqQ50u1MlScXPtrKZdaGBTE6oGq4zP2oUh7TrDdZayX2Nupm+/tZlymSi77iUAYxx1oElfNq1ezg1oKbMUnWY0ALHYkuJS5ss0xZTX0pysXK/1xwxWWScd+Ep4omP2YW1wPo= Received: by 10.114.190.6 with SMTP id n6mr3618372waf.1180857555600; Sun, 03 Jun 2007 00:59:15 -0700 (PDT) Received: by 10.114.182.4 with HTTP; Sun, 3 Jun 2007 00:59:15 -0700 (PDT) Message-ID: <6bffcb0e0706030059o3e53e647uf3ae1aa3f16609d8@mail.gmail.com> Date: Sun, 3 Jun 2007 09:59:15 +0200 From: "Michal Piotrowski" To: "Jeremy Fitzhardinge" Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? Cc: "Justin Piszcz" , linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <4661F511.4070207@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Disposition: inline References: <4661F511.4070207@goop.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id l538PTWt019318 X-archive-position: 11590 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: michal.k.k.piotrowski@gmail.com Precedence: bulk X-list: xfs H, On 03/06/07, Jeremy Fitzhardinge wrote:> Justin Piszcz wrote:> > Wondering as their were a lot of XFS related issues early on in> > development..? The 2.6.22-rc3 kernel has the core 2 duo coretemp patch> > by ruik which I want be running as long as 2.6.22-rc3 does not have> > any severe XFS issues?>> XFS currently has a data-corrupting bug, where files which were appended> by small amounts may lose their updates on umount - I see this> corrupting hg repos. There's a patch which works for me, and is in> 2.6.22-rc3-mm1, but it hasn't been merged upstream yet.> It's already merged into mainline http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=df3c7244264f1d12562413aa32d56be802486516 Regards,Michal -- "Najbardziej brakowa³o mi twojego milczenia."-- Andrzej Sapkowski "Co¶ wiêcej" From owner-xfs@oss.sgi.com Sun Jun 3 01:41:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 01:41:42 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l538fcWt026312 for ; Sun, 3 Jun 2007 01:41:39 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id B9B3FB000083; Sun, 3 Jun 2007 04:41:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id B5DDA500009A; Sun, 3 Jun 2007 04:41:38 -0400 (EDT) Date: Sun, 3 Jun 2007 04:41:38 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Jeremy Fitzhardinge cc: Michal Piotrowski , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: Kernel 2.6.22-rc3 safe to migrate to? In-Reply-To: <46627579.3040507@goop.org> Message-ID: References: <4661F511.4070207@goop.org> <6bffcb0e0706030059o3e53e647uf3ae1aa3f16609d8@mail.gmail.com> <46627579.3040507@goop.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 11591 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sun, 3 Jun 2007, Jeremy Fitzhardinge wrote: > Michal Piotrowski wrote: >> It's already merged into mainline >> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=df3c7244264f1d12562413aa32d56be802486516 >> > > Oh, good. I hadn't read through the last couple of days of commits. > > J > > Nice, any word on the USB bug? From owner-xfs@oss.sgi.com Sun Jun 3 08:03:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 08:03:56 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l53F3oWt017809; Sun, 3 Jun 2007 08:03:51 -0700 Received: from localhost (mailman.ukfsn.org [80.168.53.75]) by mail.ukfsn.org (Postfix) with ESMTP id 44CA5E6E87; Sun, 3 Jun 2007 16:03:42 +0100 (BST) Received: from mail.ukfsn.org ([80.168.53.20]) by localhost (smtp-filter.ukfsn.org [80.168.53.75]) (amavisd-new, port 10024) with ESMTP id E4XNnJ5bECXv; Sun, 3 Jun 2007 16:01:41 +0100 (BST) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 782C3E6D03; Sun, 3 Jun 2007 16:03:40 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1HurcR-0004gS-3f; Sun, 03 Jun 2007 16:03:47 +0100 Message-ID: <4662D852.4000005@dgreaves.com> Date: Sun, 03 Jun 2007 16:03:46 +0100 From: David Greaves User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Linus Torvalds , Tejun Heo Cc: "Rafael J. Wysocki" , xfs@oss.sgi.com, "'linux-kernel@vger.kernel.org'" , netdev@oss.sgi.com, linux-pm , Neil Brown Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression References: <46608E3F.4060201@dgreaves.com> <200706012342.45657.rjw@sisk.pl> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 11592 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Linus Torvalds wrote: > It would be interesting to see what triggered it, since it apparently > worked before. So yes, a bisection would be great. Tejun, all the problematic patches are yours - so adding you. Neil, since the problem only occurs whilst an xfs filesystem is mounted on a raid6 array, I've cc'ed you too... OK Got as far as I could... I've run 9 or 10 kernels/bisects and got to a point with 8 of Tejun's changesets where it wouldn't compile: CC drivers/ata/sata_via.o drivers/ata/sata_via.c:120: error: `ata_scsi_device_suspend' undeclared here (not in a function) drivers/ata/sata_via.c:120: error: initializer element is not constant drivers/ata/sata_via.c:120: error: (near initialization for `svia_sht.suspend') drivers/ata/sata_via.c:121: error: `ata_scsi_device_resume' undeclared here (not in a function) drivers/ata/sata_via.c:121: error: initializer element is not constant drivers/ata/sata_via.c:121: error: (near initialization for `svia_sht.resume') make[2]: *** [drivers/ata/sata_via.o] Error 1 git bisect visualise gave: bad: 48aaae7a2fa46e1ed0d0b7677fde79ccfcb8c963 bisect: 54936f8b099325992f0f212a5e366fd5257c6c9c good: 0a3fd051c7036ef71b58863f8e5da7c3dabd9d3f I used: git reset --hard 8575b814097af648dad284bd3087875a11b13d18 git reset --hard e92351bb53c0849fabfa80be53cbf3b0aa166e54 git reset --hard 3a32a8e96694a243ec7e7feb6d76dfc4b1fe90c1 git reset --hard 9666f4009c22f6520ac3fb8a19c9e32ab973e828 to step through - non compiled git reset --hard 1d30c33d8d07868199560b24f10ed6280e78a89c compiled and hung on resume. given the first patch identified is 9666f4009c22f6520ac3fb8a19c9e32ab973e828: "libata: reimplement suspend/resume support using sdev->manage_start_stop" That seems a good candidate... Incidentally, when I compile 1d30c33d8d07868199560b24f10ed6280e78a89c (far side of the implicated changesets) if I umount my xfs over raid6 filesystem (no lvm as I said in the OP) the resume succeeds. David PS I hope I've interpreted bisect correctly - first use and all that... From owner-xfs@oss.sgi.com Sun Jun 3 14:37:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 14:38:03 -0700 (PDT) Received: from node21.rhrz.uni-bonn.de (node21-gb.rhrz.uni-bonn.de [131.220.15.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l53LbuWt026814 for ; Sun, 3 Jun 2007 14:37:58 -0700 Received: (from wwwserv@localhost) by node21.rhrz.uni-bonn.de (8.9.3/8.9.3) id XAA83218; Sun, 3 Jun 2007 23:37:56 +0200 Date: Sun, 3 Jun 2007 23:37:56 +0200 Message-Id: <200706032137.XAA83218@node21.rhrz.uni-bonn.de> To: xfs@oss.sgi.com Subject: Properties. From: Peter Kok Reply-To: as564ag@yahoo.com.hk MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 11593 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: as564ag@yahoo.com.hk Precedence: bulk X-list: xfs Good Day, I wish to introduce myself to you. I am Peter Kok a top Sudanese Goverment official who opposed the war in Dalfour in my country Sudan.Due to my oppostion to the war, the goverment of my country has been persecuting me and my family.Consequently my wife,children and I managed to enter a red cross airplane that was evacuating foreigners and we are presently in Cape Town, South Africa. We wish to invest in properties in your country with your assistance and cooperation.If you are in a good position to help my family, please send an e-mail to the e-mail address below indicating your desire to help my family invest this funds in your country. best regards Hope to meet you soon. God bless, Peter Kok E-mail:as564ag@yahoo.com.hk From owner-xfs@oss.sgi.com Sun Jun 3 17:16:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 17:16:59 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l540GpWt026604 for ; Sun, 3 Jun 2007 17:16:53 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA27993; Mon, 4 Jun 2007 10:16:41 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l540GcAf113319342; Mon, 4 Jun 2007 10:16:39 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l540GWCC113287721; Mon, 4 Jun 2007 10:16:32 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Jun 2007 10:16:32 +1000 From: David Chinner To: Ruben Porras Cc: xfs@oss.sgi.com, iusty@k1024.org, cw@f00f.org Subject: Re: XFS shrink functionality Message-ID: <20070604001632.GA86004887@sgi.com> References: <1180715974.10796.46.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1180715974.10796.46.camel@localhost> User-Agent: Mutt/1.4.2.1i X-archive-position: 11594 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Jun 01, 2007 at 06:39:34PM +0200, Ruben Porras wrote: > Hello, > > I'm investigating the possibility to write myself the necessary code to > shrink an xfs filesystem (I'd be able to dedicate a day/week). Trying to > know if something is already done I came across the mails of a previous > intent [0], [1] (I'm cc'ing the people involved). Oh, thanks for pointing those out - they're before my time ;) > At a first glance the patch is a little outdated and will no more apply > (as of linux 2.16.18, which is the last customised kernel that I was > able to run under a XEN environment), because at least the function > xfs_fs_geometry is changed. Any work for this would need to be done against current mainline of the xfs-dev tree. Yes, that patch is out of date, and it also did things that were not necessary i.e. walk btrees to work out if AGs are empty or not. > I'm really curious about what happened to this patches and why they were > discontinued. The second part never was made public, and there was also > no answer. Was there any flaw in any of the posted code or anything in > XFS that makes it especially hard to shrink [3] that discouraged the > development? The posted code is only a *tiny* part of the shrink problem. > After that, the first questions that arouse are, > would there be some assistance/groove in from the developers? Certainly there's help available. ;) > How doable is it? It is doable. > What are the programmers requirements from your point of view? Here's the "simple" bits that will allow you to shrink the filesystem down to the end of the internal log: 0. Check space is available for shrink 1. Mark allocation groups as "don't use - going away soon" - so we don't put new stuff in them while we are moving all the bits out of them - requires hooks in the allocators to prevent the AG from being selected for allllocations - must still allow allocations for the free lists so that extent freeing can succeed - *new transaction required*. - also needs an "undo" (e.g. on partial failure) so we need to be able to mark allocation groups online again. 2. Move inodes out of offline AGs - On Irix, we have a program called 'xfs_reno' which converts 64 bit inode filesystems to 32 bit inode filesystems. This needs to be: - released under the GPL (should not be a problem). - ported to linux - modified to understand inodes sit in certain AGs and to move them out of those AGs as needed. - requires filesystem traversal to find all the inodes to be moved. % wc -l xfs_reno.c 1991 xfs_reno.c - even with "-o ikeep", this needs to trigger inode cluster deletion in offline AGs (needs hooks in xfs_ifree()). 3. Move data out of offline AGs. - this is difficult to do efficiently as we do not have a block-to-owner reverse mapping in the filesystem. Hence requires a walk of the *entire* filesystem to find the owners of data blocks in the AGs being offlined. - xfs_db wrapper might be the best way to do this... 4. Execute shrink - new transaction - XFS_TRANS_SHRINKFS - check AGs are empty - icount == 0 - freeblks == mp->m_sb.sb_agblocks (will be a little more than this) - check shrink won't go past end of internal log - free AGs, updating superblock fields - update perag structure - not a simple realloc() as there may be other threads using the structure at the same time.... Initially, I'd say just support shrinking to whole AGs - you've got to empty the whole "partial-last-ag" to ensure we can shrink it anyway, so doing a subsequent grow operation to increase the size afterwards should be trivial. Once this all works, we can then tackle the "move the log" problem which will allow you to shrink to much smaller sizes. As you can see, doing a shrink properly is not trivial, which is probably why it has't gone anywhere fast.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Jun 3 20:09:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 20:10:06 -0700 (PDT) Received: from MFWJ042.mfw.is.co.za (mfwj042.mfw.is.co.za [196.35.77.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l5439rWt028417 for ; Sun, 3 Jun 2007 20:09:54 -0700 Received: from MailMarshal.Engine ([127.0.0.1]) by MFWJ042.mfw.is.co.za with MailMarshal (v5.5.7.1596) id ; Mon, 04 Jun 2007 05:14:35 +0200 Message-ID: From: mailfwadmin@bec.co.za To: linux-xfs@oss.sgi.com CC: archspec@plascon.co.za Date: Mon, 04 Jun 2007 05:14:35 +0200 Subject: Message Stopped ---- Virus Detected ---- MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=614e9445-c29c-4b50-a572-36ff706140c7" X-archive-position: 11595 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mailfwadmin@bec.co.za Precedence: bulk X-list: xfs ----=614e9445-c29c-4b50-a572-36ff706140c7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Barloworld Plascon MailFirewall has stopped the following message: Message: BA02f6702b.00000001.mml From: linux-xfs@oss.sgi.com To: archspec@plascon.co.za Subject: Because it believes the message or an attachment to the message contains a virus. The virus scanning software used was: McAfee for Marshal W32/Mydoom.o@MM!zip Barloworld Plascon MailFirewall Rule: Plascon Inbound : Block Virus Email Content Security provided by NetIQ MailMarshal. ----=614e9445-c29c-4b50-a572-36ff706140c7-- From owner-xfs@oss.sgi.com Sun Jun 3 21:31:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 21:32:12 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l544VoWt011482 for ; Sun, 3 Jun 2007 21:31:58 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA03794; Mon, 4 Jun 2007 14:31:46 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 225DC58C38C1; Mon, 4 Jun 2007 14:31:46 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 964092 - synchronous direct I/O write calls are incomplete when returning to user space Message-Id: <20070604043146.225DC58C38C1@chook.melbourne.sgi.com> Date: Mon, 4 Jun 2007 14:31:46 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 11596 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs QA test to exercise unwritten extent conversion for sync direct I/O Date: Mon Jun 4 14:31:01 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/xfs-cmds Inspected by: donaldd The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:28769a xfstests/167 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/167 xfstests/167.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/167.out xfstests/src/unwritten_sync.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/unwritten_sync.c xfstests/group - 1.105 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/group.diff?r1=text&tr1=1.105&r2=text&tr2=1.104&f=h xfstests/src/Makefile - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/Makefile.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h - QA test to exercise unwritten extent conversion for sync direct I/O. From owner-xfs@oss.sgi.com Sun Jun 3 21:41:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 21:41:06 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l544exWt015527 for ; Sun, 3 Jun 2007 21:41:01 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA03959; Mon, 4 Jun 2007 14:40:54 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id C4CA958C38C1; Mon, 4 Jun 2007 14:40:54 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 965626 - xfsqa - test 030 doesn't test what it's supposed to Message-Id: <20070604044054.C4CA958C38C1@chook.melbourne.sgi.com> Date: Mon, 4 Jun 2007 14:40:54 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 11597 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Make sure the repair tests dirty the filesystem before corrupting it. Date: Mon Jun 4 14:40:06 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/xfs-cmds Inspected by: ddiss The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:28770a xfstests/common.repair - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/common.repair.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfstests/030.out.irix - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/030.out.irix.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfstests/030.out.linux - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/030.out.linux.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfstests/148.out - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/148.out.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - Make sure the repair tests dirty the filesystem before corrupting it. From owner-xfs@oss.sgi.com Sun Jun 3 21:52:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 21:52:33 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l544qPWt021124 for ; Sun, 3 Jun 2007 21:52:28 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA04203; Mon, 4 Jun 2007 14:52:21 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l544qKAf112221586; Mon, 4 Jun 2007 14:52:21 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l544qJKp110131735; Mon, 4 Jun 2007 14:52:19 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Jun 2007 14:52:19 +1000 From: David Chinner To: xfs-dev Cc: xfs-oss Subject: Review: Be smarter about handling ENOSPC during writeback Message-ID: <20070604045219.GG86004887@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 11598 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs During delayed allocation extent conversion or unwritten extent conversion, we need to reserve some blocks for transactions reservations. We need to reserve these blocks in case a btree split occurs and we need to allocate some blocks. Unfortunately, we've only ever reserved the number of data blocks we are allocating, so in both the unwritten and delalloc case we can get ENOSPC to the transaction reservation. This is bad because in both cases we cannot report the failure to the writing application. The fix is two-fold: 1 - leverage the reserved block infrastructure XFS already has to reserve a small pool of blocks by default to allow specially marked transactions to dip into when we are at ENOSPC. Default setting is min(5%, 1024 blocks). 2 - convert critical transaction reservations to be allowed to dip into this pool. Spots changed are delalloc conversion, unwritten extent conversion and growing a filesystem at ENOSPC. Comments? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_fsops.c | 10 +++++++--- fs/xfs/xfs_iomap.c | 22 ++++++++-------------- fs/xfs/xfs_mount.c | 37 +++++++++++++++++++++++++++++++++++-- 3 files changed, 50 insertions(+), 19 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_fsops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_fsops.c 2007-05-11 10:35:29.288847149 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_fsops.c 2007-05-11 11:13:34.195363437 +1000 @@ -179,6 +179,7 @@ xfs_growfs_data_private( up_write(&mp->m_peraglock); } tp = xfs_trans_alloc(mp, XFS_TRANS_GROWFS); + tp->t_flags |= XFS_TRANS_RESERVE; if ((error = xfs_trans_reserve(tp, XFS_GROWFS_SPACE_RES(mp), XFS_GROWDATA_LOG_RES(mp), 0, 0, 0))) { xfs_trans_cancel(tp, 0); @@ -500,8 +501,9 @@ xfs_reserve_blocks( unsigned long s; /* If inval is null, report current values and return */ - if (inval == (__uint64_t *)NULL) { + if (!outval) + return EINVAL; outval->resblks = mp->m_resblks; outval->resblks_avail = mp->m_resblks_avail; return 0; @@ -564,8 +566,10 @@ retry: } } out: - outval->resblks = mp->m_resblks; - outval->resblks_avail = mp->m_resblks_avail; + if (outval) { + outval->resblks = mp->m_resblks; + outval->resblks_avail = mp->m_resblks_avail; + } XFS_SB_UNLOCK(mp, s); if (fdblks_delta) { Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2007-05-11 10:35:29.292846630 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2007-05-11 11:13:47.229662318 +1000 @@ -718,7 +718,7 @@ xfs_mountfs( bhv_vnode_t *rvp = NULL; int readio_log, writeio_log; xfs_daddr_t d; - __uint64_t ret64; + __uint64_t resblks; __int64_t update_flags; uint quotamount, quotaflags; int agno; @@ -835,6 +835,7 @@ xfs_mountfs( */ if ((mfsi_flags & XFS_MFSI_SECOND) == 0 && (mp->m_flags & XFS_MOUNT_NOUUID) == 0) { + __uint64_t ret64; if (xfs_uuid_mount(mp)) { error = XFS_ERROR(EINVAL); goto error1; @@ -1127,13 +1128,27 @@ xfs_mountfs( goto error4; } - /* * Complete the quota initialisation, post-log-replay component. */ if ((error = XFS_QM_MOUNT(mp, quotamount, quotaflags, mfsi_flags))) goto error4; + /* + * Now we are mounted, reserve a small amount of unused space for + * privileged transactions. This is needed so that transaction + * space required for critical operations can dip into this pool + * when at ENOSPC. This is needed for operations like create with + * attr, unwritten extent conversion at ENOSPC, etc. Data allocations + * are not allowed to use this reserved space. + * + * We default to 5% or 1024 fsbs of space reserved, whichever is smaller. + * This may drive us straight to ENOSPC on mount, but that implies + * we were already there on the last unmount. + */ + resblks = min_t(__uint64_t, mp->m_sb.sb_dblocks / 20, 1024); + xfs_reserve_blocks(mp, &resblks, NULL); + return 0; error4: @@ -1172,6 +1187,7 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr #if defined(DEBUG) || defined(INDUCE_IO_ERROR) int64_t fsid; #endif + __uint64_t resblks; /* * We can potentially deadlock here if we have an inode cluster @@ -1200,6 +1216,23 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr xfs_binval(mp->m_rtdev_targp); } + /* + * Unreserve any blocks we have so that when we unmount we don't account + * the reserved free space as used. This is really only necessary for + * lazy superblock counting because it trusts the incore superblock + * counters to be aboslutely correct on clean unmount. + * + * We don't bother correcting this elsewhere for lazy superblock + * counting because on mount of an unclean filesystem we reconstruct the + * correct counter value and this is irrelevant. + * + * For non-lazy counter filesystems, this doesn't matter at all because + * we only every apply deltas to the superblock and hence the incore + * value does not matter.... + */ + resblks = 0; + xfs_reserve_blocks(mp, &resblks, NULL); + xfs_log_sbcount(mp, 1); xfs_unmountfs_writesb(mp); xfs_unmountfs_wait(mp); /* wait for async bufs */ Index: 2.6.x-xfs-new/fs/xfs/xfs_iomap.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_iomap.c 2007-05-11 11:13:13.862017149 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_iomap.c 2007-05-11 11:13:34.199362915 +1000 @@ -489,13 +489,13 @@ xfs_iomap_write_direct( if (unlikely(rt)) { resrtextents = qblocks = resaligned; resrtextents /= mp->m_sb.sb_rextsize; - resblks = XFS_DIOSTRAT_SPACE_RES(mp, 0); - quota_flag = XFS_QMOPT_RES_RTBLKS; - } else { - resrtextents = 0; + resblks = XFS_DIOSTRAT_SPACE_RES(mp, 0); + quota_flag = XFS_QMOPT_RES_RTBLKS; + } else { + resrtextents = 0; resblks = qblocks = XFS_DIOSTRAT_SPACE_RES(mp, resaligned); - quota_flag = XFS_QMOPT_RES_REGBLKS; - } + quota_flag = XFS_QMOPT_RES_REGBLKS; + } /* * Allocate and setup the transaction @@ -788,18 +788,12 @@ xfs_iomap_write_allocate( nimaps = 0; while (nimaps == 0) { tp = xfs_trans_alloc(mp, XFS_TRANS_STRAT_WRITE); + tp->t_flags |= XFS_TRANS_RESERVE; nres = XFS_EXTENTADD_SPACE_RES(mp, XFS_DATA_FORK); error = xfs_trans_reserve(tp, nres, XFS_WRITE_LOG_RES(mp), 0, XFS_TRANS_PERM_LOG_RES, XFS_WRITE_LOG_COUNT); - if (error == ENOSPC) { - error = xfs_trans_reserve(tp, 0, - XFS_WRITE_LOG_RES(mp), - 0, - XFS_TRANS_PERM_LOG_RES, - XFS_WRITE_LOG_COUNT); - } if (error) { xfs_trans_cancel(tp, 0); return XFS_ERROR(error); @@ -917,8 +911,8 @@ xfs_iomap_write_unwritten( * from unwritten to real. Do allocations in a loop until * we have covered the range passed in. */ - tp = xfs_trans_alloc(mp, XFS_TRANS_STRAT_WRITE); + tp->t_flags |= XFS_TRANS_RESERVE; error = xfs_trans_reserve(tp, resblks, XFS_WRITE_LOG_RES(mp), 0, XFS_TRANS_PERM_LOG_RES, From owner-xfs@oss.sgi.com Sun Jun 3 21:53:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 21:53:31 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l544rNWt021743 for ; Sun, 3 Jun 2007 21:53:26 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA04217; Mon, 4 Jun 2007 14:53:19 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l544rIAf110554529; Mon, 4 Jun 2007 14:53:18 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l544rHLO111675106; Mon, 4 Jun 2007 14:53:17 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Jun 2007 14:53:17 +1000 From: David Chinner To: David Chinner Cc: xfs-dev , xfs-oss Subject: Re: Review - writing to multiple non-contiguous unwritten extents within a page is broken. Message-ID: <20070604045317.GH86004887@sgi.com> References: <20070523092103.GT85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070523092103.GT85884050@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 11599 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Ping? On Wed, May 23, 2007 at 07:21:03PM +1000, David Chinner wrote: > [Nathan - probably another one for you] > > This test run on ia64 (16k page size) on a 4k block size filesystem: > > #!/bin/bash > > file=$1 > rm -f $file > > xfs_io -f \ > -c "truncate 1048576" \ > -c "resvsp 1032192 16384" \ > -c "pwrite 1033216 2560" \ > -c "pwrite 1040384 8192" \ > -c "bmap -vvp" \ > -c "fsync" \ > -c "bmap -vvp" \ > -c "close" \ > $file > > Which writes 3 unwritten blocks in a page (first block and last 2) > results in a corrupted write. > > The problem is that the second block on teh page is uninitialised > and so is skipped by xfs_page_state_convert. The problem is that the > xfs_ioend structures are not getting created correctly. > > When we skip the uninitialised block, we add the second unwritten block > we are writing to into the original ioend. While this results in > the correct I/O being sent to disk, it results in a ioend with a > start offset of 0 and a length of 3 blocks. When we do unwritten > extent conversion based on this range, we convert the wrong blocks. > > What we need to be doing is creating two xfs_ioend structures, one > for the first block and one for the second set of blocks in the page. > That way we get two separate I/O completion events and convert the > ranges separately and correctly. > > I've checked xfs_convert_page(), and I don't think it needs any > fix here - it already appears to force multiple ioends to be used in this > case... > > Thoughts? > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > --- > fs/xfs/linux-2.6/xfs_aops.c | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_aops.c 2007-05-23 16:33:04.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c 2007-05-23 17:52:15.540456674 +1000 > @@ -1008,6 +1008,8 @@ xfs_page_state_convert( > if (buffer_unwritten(bh) || buffer_delay(bh) || > ((buffer_uptodate(bh) || PageUptodate(page)) && > !buffer_mapped(bh) && (unmapped || startio))) { > + int new_ioend = 0; > + > /* > * Make sure we don't use a read-only iomap > */ > @@ -1026,6 +1028,15 @@ xfs_page_state_convert( > } > > if (!iomap_valid) { > + /* > + * if we didn't have a valid mapping then we > + * need to ensure that we put the new mapping > + * in a new ioend structure. This needs to be > + * done to ensure that the ioends correctly > + * reflect the block mappings at io completion > + * for unwritten extent conversion. > + */ > + new_ioend = 1; > if (type == IOMAP_NEW) { > size = xfs_probe_cluster(inode, > page, bh, head, 0); > @@ -1045,7 +1056,7 @@ xfs_page_state_convert( > if (startio) { > xfs_add_to_ioend(inode, bh, offset, > type, &ioend, > - !iomap_valid); > + new_ioend); > } else { > set_buffer_dirty(bh); > unlock_buffer(bh); -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Jun 3 22:14:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 22:14:47 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l545EdWt002262 for ; Sun, 3 Jun 2007 22:14:42 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA04599; Mon, 4 Jun 2007 15:14:35 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l545EYAf113392920; Mon, 4 Jun 2007 15:14:35 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l545EXRb113181890; Mon, 4 Jun 2007 15:14:33 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Jun 2007 15:14:33 +1000 From: David Chinner To: xfs-dev Cc: xfs-oss Subject: Review: remount read-only path is as broken as freezing was.... Message-ID: <20070604051433.GP85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 11600 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs I recently had a remount,ro test fail in a way I had previously only seen freezing fail. That is, it failed because we still had active transactions after calling xfs_quiesce_fs(). Further investigation shows that this path is broken in the same ways that the xfs freeze path was broken (and recently fixed). Make the remount,ro path properly flush the filesystem down to a clean state before returning. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/linux-2.6/xfs_super.c | 2 - fs/xfs/linux-2.6/xfs_vfs.h | 10 +++++++ fs/xfs/xfs_vfsops.c | 54 ++++++++++++++++++++++++------------------- 3 files changed, 42 insertions(+), 24 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_super.c 2007-05-10 16:56:09.594774832 +1000 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_super.c 2007-05-10 17:39:02.374544197 +1000 @@ -726,7 +726,7 @@ xfs_fs_sync_super( * occur here so don't bother flushing the buftarg (i.e * SYNC_QUIESCE) because it'll just get dirty again. */ - flags = SYNC_FSDATA | SYNC_DELWRI | SYNC_WAIT | SYNC_IOWAIT; + flags = SYNC_DATA_QUIESCE; } else flags = SYNC_FSDATA | (wait ? SYNC_WAIT : 0); Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_vfs.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_vfs.h 2007-05-10 16:56:09.590775350 +1000 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_vfs.h 2007-05-10 17:39:02.386542627 +1000 @@ -94,6 +94,16 @@ typedef enum { #define SYNC_IOWAIT 0x0100 /* wait for all I/O to complete */ #define SYNC_SUPER 0x0200 /* flush superblock to disk */ +/* + * When remounting a filesystem read-only or freezing the filesystem, + * we have two phases to execute. This first phase is syncing the data + * before we quiesce the filesystem, and the second is flushing all the + * inodes out after we've waited for all the transactions created by + * the first phase to complete. + */ +#define SYNC_DATA_QUIESCE (SYNC_DELWRI|SYNC_FSDATA|SYNC_WAIT|SYNC_IOWAIT) +#define SYNC_INODE_QUIESCE (SYNC_REMOUNT|SYNC_ATTR|SYNC_WAIT) + #define SHUTDOWN_META_IO_ERROR 0x0001 /* write attempt to metadata failed */ #define SHUTDOWN_LOG_IO_ERROR 0x0002 /* write attempt to the log failed */ #define SHUTDOWN_FORCE_UMOUNT 0x0004 /* shutdown from a forced unmount */ Index: 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vfsops.c 2007-05-10 17:38:58.351070788 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c 2007-05-10 17:58:09.958425162 +1000 @@ -665,7 +665,7 @@ xfs_quiesce_fs( * we can write the unmount record. */ do { - xfs_syncsub(mp, SYNC_REMOUNT|SYNC_ATTR|SYNC_WAIT, NULL); + xfs_syncsub(mp, SYNC_INODE_QUIESCE, NULL); pincount = xfs_flush_buftarg(mp->m_ddev_targp, 1); if (!pincount) { count++; @@ -682,6 +682,30 @@ xfs_quiesce_fs( return 0; } +/* + * Second stage of a quiesce. The data is already synced, now we have to take + * care of the metadata. New transactions are already blocked, so we need to + * wait for any remaining transactions to drain out before proceding. + */ +STATIC void +xfs_attr_quiesce( + xfs_mount_t *mp) +{ + /* wait for all modifications to complete */ + while (atomic_read(&mp->m_active_trans) > 0) + delay(100); + + /* flush inodes and push all remaining buffers out to disk */ + xfs_quiesce_fs(mp); + + ASSERT_ALWAYS(atomic_read(&mp->m_active_trans) == 0); + + /* Push the superblock and write an unmount record */ + xfs_log_sbcount(mp, 1); + xfs_log_unmount_write(mp); + xfs_unmountfs_writesb(mp); +} + STATIC int xfs_mntupdate( bhv_desc_t *bdp, @@ -701,11 +725,7 @@ xfs_mntupdate( mp->m_flags &= ~XFS_MOUNT_BARRIER; } } else if (!(vfsp->vfs_flag & VFS_RDONLY)) { /* rw -> ro */ - bhv_vfs_sync(vfsp, SYNC_FSDATA|SYNC_BDFLUSH|SYNC_ATTR, NULL); - xfs_quiesce_fs(mp); - xfs_log_sbcount(mp, 1); - xfs_log_unmount_write(mp); - xfs_unmountfs_writesb(mp); + bhv_vfs_sync(vfsp, SYNC_DATA_QUIESCE, NULL); + xfs_attr_quiesce(mp); vfsp->vfs_flag |= VFS_RDONLY; } return 0; @@ -1998,9 +2018,9 @@ xfs_showargs( } /* - * Second stage of a freeze. The data is already frozen, now we have to take - * care of the metadata. New transactions are already blocked, so we need to - * wait for any remaining transactions to drain out before proceding. + * Second stage of a freeze. The data is already frozen so we only + * need to take care of the metadata. Once that's done write a dummy + * record to dirty the log in case of a crash while frozen. */ STATIC void xfs_freeze( @@ -2008,19 +2028,7 @@ xfs_freeze( { xfs_mount_t *mp = XFS_BHVTOM(bdp); - /* wait for all modifications to complete */ - while (atomic_read(&mp->m_active_trans) > 0) - delay(100); - - /* flush inodes and push all remaining buffers out to disk */ - xfs_quiesce_fs(mp); - - ASSERT_ALWAYS(atomic_read(&mp->m_active_trans) == 0); - - /* Push the superblock and write an unmount record */ - xfs_log_sbcount(mp, 1); - xfs_log_unmount_write(mp); - xfs_unmountfs_writesb(mp); + xfs_attr_quiesce(mp); xfs_fs_log_dummy(mp); } From owner-xfs@oss.sgi.com Sun Jun 3 22:19:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 22:19:57 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l545JoWt004337 for ; Sun, 3 Jun 2007 22:19:54 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA04811; Mon, 4 Jun 2007 15:19:46 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l545JjAf113117607; Mon, 4 Jun 2007 15:19:46 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l545JiJ1113297283; Mon, 4 Jun 2007 15:19:44 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Jun 2007 15:19:44 +1000 From: David Chinner To: xfs-dev Cc: xfs-oss Subject: Review: xfs_bmapi does not update previous extent pointer correctly Message-ID: <20070604051944.GQ85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 11601 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs When looping across multiple extents, xfs_bmapi will fail to update the previous extent pointer which is used in subsequent loops. As a result, we can end up with the second loop in xfs_bmapi trying to use an incorrect previous extent pointer and assert failures or corrupted in-memory extent lists will result. Correctly update the previous extent at the end of each loop so that we DTRT when processing multiple map requests. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_bmap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_bmap.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bmap.c 2007-05-23 16:33:00.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_bmap.c 2007-05-25 11:53:31.949847746 +1000 @@ -5575,10 +5575,10 @@ xfs_bmapi( * Else go on to the next record. */ ep = xfs_iext_get_ext(ifp, ++lastx); - if (lastx >= nextents) { + prev = got; + if (lastx >= nextents) eof = 1; - prev = got; - } else + else xfs_bmbt_get_all(ep, &got); } ifp->if_lastex = lastx; From owner-xfs@oss.sgi.com Sun Jun 3 22:23:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 22:23:48 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l545NdWt006180 for ; Sun, 3 Jun 2007 22:23:43 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA04962; Mon, 4 Jun 2007 15:23:35 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l545NYAf110674749; Mon, 4 Jun 2007 15:23:35 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l545NXlg113315390; Mon, 4 Jun 2007 15:23:33 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Jun 2007 15:23:33 +1000 From: David Chinner To: xfs-dev Cc: xfs-oss Subject: Review: factor extracting extent size hints from the inode Message-ID: <20070604052333.GR85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 11602 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Replace frequently repeated, open coded extraction of the extent size hint from the xfs_inode with a single helper function. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_bmap.c | 33 +++++++++++---------------------- fs/xfs/xfs_iomap.c | 19 ++++--------------- fs/xfs/xfs_rw.h | 22 ++++++++++++++++++++++ fs/xfs/xfs_vnodeops.c | 17 +++++------------ 4 files changed, 42 insertions(+), 49 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vnodeops.c 2007-05-31 17:07:38.421796043 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c 2007-05-31 17:14:29.188303231 +1000 @@ -197,9 +197,8 @@ xfs_getattr( * realtime extent size or the realtime volume's * extent size. */ - vap->va_blocksize = ip->i_d.di_extsize ? - (ip->i_d.di_extsize << mp->m_sb.sb_blocklog) : - (mp->m_sb.sb_rextsize << mp->m_sb.sb_blocklog); + vap->va_blocksize = + xfs_get_extsz_hint(ip) << mp->m_sb.sb_blocklog; } break; } @@ -4094,22 +4093,16 @@ xfs_alloc_file_space( if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); - rt = XFS_IS_REALTIME_INODE(ip); - if (unlikely(rt)) { - if (!(extsz = ip->i_d.di_extsize)) - extsz = mp->m_sb.sb_rextsize; - } else { - extsz = ip->i_d.di_extsize; - } - if ((error = XFS_QM_DQATTACH(mp, ip, 0))) return error; if (len <= 0) return XFS_ERROR(EINVAL); + rt = XFS_IS_REALTIME_INODE(ip); + extsz = xfs_get_extsz_hint(ip); + count = len; - error = 0; imapp = &imaps[0]; nimaps = 1; bmapi_flag = XFS_BMAPI_WRITE | (alloc_type ? XFS_BMAPI_PREALLOC : 0); Index: 2.6.x-xfs-new/fs/xfs/xfs_rw.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_rw.h 2007-05-31 17:07:37.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_rw.h 2007-05-31 17:36:31.711921349 +1000 @@ -77,6 +77,28 @@ xfs_fsb_to_db_io(struct xfs_iocore *io, #define XFS_FREE_EOF_LOCK (1<<0) #define XFS_FREE_EOF_NOLOCK (1<<1) + +/* + * helper function to extract extent size hint from inode + */ +STATIC_INLINE xfs_extlen_t +xfs_get_extsz_hint( + xfs_inode_t *ip) +{ + xfs_extlen_t extsz; + + if (unlikely(ip->i_d.di_flags & XFS_DIFLAG_REALTIME)) { + extsz = (ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE) + ? ip->i_d.di_extsize + : ip->i_mount->m_sb.sb_rextsize; + ASSERT(extsz); + } else { + extsz = (ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE) + ? ip->i_d.di_extsize : 0; + } + return extsz; +} + /* * Prototypes for functions in xfs_rw.c. */ Index: 2.6.x-xfs-new/fs/xfs/xfs_bmap.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bmap.c 2007-05-29 16:40:12.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_bmap.c 2007-05-31 17:38:24.429227867 +1000 @@ -2618,8 +2618,7 @@ xfs_bmap_rtalloc( xfs_rtblock_t rtb; mp = ap->ip->i_mount; - align = ap->ip->i_d.di_extsize ? - ap->ip->i_d.di_extsize : mp->m_sb.sb_rextsize; + align = xfs_get_extsz_hint(ap->ip); prod = align / mp->m_sb.sb_rextsize; error = xfs_bmap_extsize_align(mp, ap->gotp, ap->prevp, align, 1, ap->eof, 0, @@ -2727,9 +2726,7 @@ xfs_bmap_btalloc( if (!args) return XFS_ERROR(ENOMEM); mp = ap->ip->i_mount; - align = (ap->userdata && ap->ip->i_d.di_extsize && - (ap->ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE)) ? - ap->ip->i_d.di_extsize : 0; + align = ap->userdata ? xfs_get_extsz_hint(ap->ip) : 0; if (unlikely(align)) { error = xfs_bmap_extsize_align(mp, ap->gotp, ap->prevp, align, 0, ap->eof, 0, ap->conv, @@ -2829,9 +2826,9 @@ xfs_bmap_btalloc( args->total = ap->total; args->minlen = ap->minlen; } - if (unlikely(ap->userdata && ap->ip->i_d.di_extsize && - (ap->ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE))) { - args->prod = ap->ip->i_d.di_extsize; + /* apply extent size hints if obtained earlier */ + if (unlikely(align)) { + args->prod = align; if ((args->mod = (xfs_extlen_t)do_mod(ap->off, args->prod))) args->mod = (xfs_extlen_t)(args->prod - args->mod); } else if (mp->m_sb.sb_blocksize >= NBPP) { @@ -3018,9 +3015,7 @@ xfs_bmap_filestreams( */ mp = ap->ip->i_mount; rt = (ap->ip->i_d.di_flags & XFS_DIFLAG_REALTIME) && ap->userdata; - align = (ap->userdata && ap->ip->i_d.di_extsize && - (ap->ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE)) ? - ap->ip->i_d.di_extsize : 0; + align = ap->userdata ? xfs_get_extsz_hint(ap->ip) : 0; if (align) { error = xfs_bmap_extsize_align(mp, ap->gotp, ap->prevp, align, rt, @@ -3166,9 +3161,9 @@ xfs_bmap_filestreams( args.total = ap->total; args.minlen = ap->minlen; } - if (ap->userdata && ap->ip->i_d.di_extsize && - (ap->ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE)) { - args.prod = ap->ip->i_d.di_extsize; + /* apply extent size hint if found earlier */ + if (align) { + args.prod = align; if ((args.mod = (xfs_extlen_t)(do_mod(ap->off, args.prod)))) args.mod = (xfs_extlen_t)(args.prod - args.mod); } else if (mp->m_sb.sb_blocksize >= NBPP) { @@ -5224,12 +5219,7 @@ xfs_bmapi( xfs_extlen_t extsz; /* Figure out the extent size, adjust alen */ - if (rt) { - if (!(extsz = ip->i_d.di_extsize)) - extsz = mp->m_sb.sb_rextsize; - } else { - extsz = ip->i_d.di_extsize; - } + extsz = xfs_get_extsz_hint(ip); if (extsz) { error = xfs_bmap_extsize_align(mp, &got, &prev, extsz, @@ -6170,8 +6160,7 @@ xfs_getbmap( ip->i_d.di_format != XFS_DINODE_FMT_LOCAL) return XFS_ERROR(EINVAL); if (whichfork == XFS_DATA_FORK) { - if ((ip->i_d.di_extsize && (ip->i_d.di_flags & - (XFS_DIFLAG_REALTIME|XFS_DIFLAG_EXTSIZE))) || + if (xfs_get_extsz_hint(ip) || ip->i_d.di_flags & (XFS_DIFLAG_PREALLOC|XFS_DIFLAG_APPEND)){ prealloced = 1; fixlen = XFS_MAXIOFFSET(mp); Index: 2.6.x-xfs-new/fs/xfs/xfs_iomap.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_iomap.c 2007-05-31 17:07:38.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_iomap.c 2007-05-31 17:30:22.096110172 +1000 @@ -451,19 +451,14 @@ xfs_iomap_write_direct( return XFS_ERROR(error); rt = XFS_IS_REALTIME_INODE(ip); - if (unlikely(rt)) { - if (!(extsz = ip->i_d.di_extsize)) - extsz = mp->m_sb.sb_rextsize; - } else { - extsz = ip->i_d.di_extsize; - } + extsz = xfs_get_extsz_hint(ip); isize = ip->i_size; if (io->io_new_size > isize) isize = io->io_new_size; - offset_fsb = XFS_B_TO_FSBT(mp, offset); - last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); + offset_fsb = XFS_B_TO_FSBT(mp, offset); + last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); if ((offset + count) > isize) { error = xfs_iomap_eof_align_last_fsb(mp, io, isize, extsz, &last_fsb); @@ -666,13 +661,7 @@ xfs_iomap_write_delay( if (error) return XFS_ERROR(error); - if (XFS_IS_REALTIME_INODE(ip)) { - if (!(extsz = ip->i_d.di_extsize)) - extsz = mp->m_sb.sb_rextsize; - } else { - extsz = ip->i_d.di_extsize; - } - + extsz = xfs_get_extsz_hint(ip); offset_fsb = XFS_B_TO_FSBT(mp, offset); retry: From owner-xfs@oss.sgi.com Sun Jun 3 22:24:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 22:24:16 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l545OAWt006541 for ; Sun, 3 Jun 2007 22:24:13 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA04971; Mon, 4 Jun 2007 15:24:06 +1000 Message-ID: <4663A283.2030205@sgi.com> Date: Mon, 04 Jun 2007 15:26:27 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: David Chinner CC: xfs-dev , xfs-oss Subject: Re: Review: xfs_bmapi does not update previous extent pointer correctly References: <20070604051944.GQ85884050@sgi.com> In-Reply-To: <20070604051944.GQ85884050@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 11603 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs It is looking good Dave, Regards, Vlad David Chinner wrote: > When looping across multiple extents, xfs_bmapi will fail to > update the previous extent pointer which is used in subsequent > loops. > > As a result, we can end up with the second loop in xfs_bmapi trying > to use an incorrect previous extent pointer and assert failures or > corrupted in-memory extent lists will result. > > Correctly update the previous extent at the end of each loop so that > we DTRT when processing multiple map requests. > > Cheers, > > Dave. > From owner-xfs@oss.sgi.com Sun Jun 3 23:13:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 23:13:28 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l546DLWt025059 for ; Sun, 3 Jun 2007 23:13:23 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA05911; Mon, 4 Jun 2007 16:13:16 +1000 Date: Mon, 04 Jun 2007 16:13:12 +1000 From: Timothy Shimmin To: David Chinner , xfs-dev cc: xfs-oss Subject: Re: Review: Be smarter about handling ENOSPC during writeback Message-ID: In-Reply-To: <20070604045219.GG86004887@sgi.com> References: <20070604045219.GG86004887@sgi.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 11604 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs As previously discussed, the idea sounds reasonable to me. I'll look at the patch shortly. --Tim --On 4 June 2007 2:52:19 PM +1000 David Chinner wrote: > > During delayed allocation extent conversion or unwritten extent > conversion, we need to reserve some blocks for transactions > reservations. We need to reserve these blocks in case a btree > split occurs and we need to allocate some blocks. > > Unfortunately, we've only ever reserved the number of data blocks we > are allocating, so in both the unwritten and delalloc case we can > get ENOSPC to the transaction reservation. This is bad because in > both cases we cannot report the failure to the writing application. > > The fix is two-fold: > > 1 - leverage the reserved block infrastructure XFS already > has to reserve a small pool of blocks by default to allow > specially marked transactions to dip into when we are at > ENOSPC. > > Default setting is min(5%, 1024 blocks). > > 2 - convert critical transaction reservations to be allowed > to dip into this pool. Spots changed are delalloc > conversion, unwritten extent conversion and growing a > filesystem at ENOSPC. > > Comments? > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > --- > fs/xfs/xfs_fsops.c | 10 +++++++--- > fs/xfs/xfs_iomap.c | 22 ++++++++-------------- > fs/xfs/xfs_mount.c | 37 +++++++++++++++++++++++++++++++++++-- > 3 files changed, 50 insertions(+), 19 deletions(-) > > Index: 2.6.x-xfs-new/fs/xfs/xfs_fsops.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_fsops.c 2007-05-11 10:35:29.288847149 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_fsops.c 2007-05-11 11:13:34.195363437 +1000 > @@ -179,6 +179,7 @@ xfs_growfs_data_private( > up_write(&mp->m_peraglock); > } > tp = xfs_trans_alloc(mp, XFS_TRANS_GROWFS); > + tp->t_flags |= XFS_TRANS_RESERVE; > if ((error = xfs_trans_reserve(tp, XFS_GROWFS_SPACE_RES(mp), > XFS_GROWDATA_LOG_RES(mp), 0, 0, 0))) { > xfs_trans_cancel(tp, 0); > @@ -500,8 +501,9 @@ xfs_reserve_blocks( > unsigned long s; > > /* If inval is null, report current values and return */ > - > if (inval == (__uint64_t *)NULL) { > + if (!outval) > + return EINVAL; > outval->resblks = mp->m_resblks; > outval->resblks_avail = mp->m_resblks_avail; > return 0; > @@ -564,8 +566,10 @@ retry: > } > } > out: > - outval->resblks = mp->m_resblks; > - outval->resblks_avail = mp->m_resblks_avail; > + if (outval) { > + outval->resblks = mp->m_resblks; > + outval->resblks_avail = mp->m_resblks_avail; > + } > XFS_SB_UNLOCK(mp, s); > > if (fdblks_delta) { > Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2007-05-11 10:35:29.292846630 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2007-05-11 11:13:47.229662318 +1000 > @@ -718,7 +718,7 @@ xfs_mountfs( > bhv_vnode_t *rvp = NULL; > int readio_log, writeio_log; > xfs_daddr_t d; > - __uint64_t ret64; > + __uint64_t resblks; > __int64_t update_flags; > uint quotamount, quotaflags; > int agno; > @@ -835,6 +835,7 @@ xfs_mountfs( > */ > if ((mfsi_flags & XFS_MFSI_SECOND) == 0 && > (mp->m_flags & XFS_MOUNT_NOUUID) == 0) { > + __uint64_t ret64; > if (xfs_uuid_mount(mp)) { > error = XFS_ERROR(EINVAL); > goto error1; > @@ -1127,13 +1128,27 @@ xfs_mountfs( > goto error4; > } > > - > /* > * Complete the quota initialisation, post-log-replay component. > */ > if ((error = XFS_QM_MOUNT(mp, quotamount, quotaflags, mfsi_flags))) > goto error4; > > + /* > + * Now we are mounted, reserve a small amount of unused space for > + * privileged transactions. This is needed so that transaction > + * space required for critical operations can dip into this pool > + * when at ENOSPC. This is needed for operations like create with > + * attr, unwritten extent conversion at ENOSPC, etc. Data allocations > + * are not allowed to use this reserved space. > + * > + * We default to 5% or 1024 fsbs of space reserved, whichever is smaller. > + * This may drive us straight to ENOSPC on mount, but that implies > + * we were already there on the last unmount. > + */ > + resblks = min_t(__uint64_t, mp->m_sb.sb_dblocks / 20, 1024); > + xfs_reserve_blocks(mp, &resblks, NULL); > + > return 0; > > error4: > @@ -1172,6 +1187,7 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr > #if defined(DEBUG) || defined(INDUCE_IO_ERROR) > int64_t fsid; > #endif > + __uint64_t resblks; > > /* > * We can potentially deadlock here if we have an inode cluster > @@ -1200,6 +1216,23 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr > xfs_binval(mp->m_rtdev_targp); > } > > + /* > + * Unreserve any blocks we have so that when we unmount we don't account > + * the reserved free space as used. This is really only necessary for > + * lazy superblock counting because it trusts the incore superblock > + * counters to be aboslutely correct on clean unmount. > + * > + * We don't bother correcting this elsewhere for lazy superblock > + * counting because on mount of an unclean filesystem we reconstruct the > + * correct counter value and this is irrelevant. > + * > + * For non-lazy counter filesystems, this doesn't matter at all because > + * we only every apply deltas to the superblock and hence the incore > + * value does not matter.... > + */ > + resblks = 0; > + xfs_reserve_blocks(mp, &resblks, NULL); > + > xfs_log_sbcount(mp, 1); > xfs_unmountfs_writesb(mp); > xfs_unmountfs_wait(mp); /* wait for async bufs */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_iomap.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_iomap.c 2007-05-11 11:13:13.862017149 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_iomap.c 2007-05-11 11:13:34.199362915 +1000 > @@ -489,13 +489,13 @@ xfs_iomap_write_direct( > if (unlikely(rt)) { > resrtextents = qblocks = resaligned; > resrtextents /= mp->m_sb.sb_rextsize; > - resblks = XFS_DIOSTRAT_SPACE_RES(mp, 0); > - quota_flag = XFS_QMOPT_RES_RTBLKS; > - } else { > - resrtextents = 0; > + resblks = XFS_DIOSTRAT_SPACE_RES(mp, 0); > + quota_flag = XFS_QMOPT_RES_RTBLKS; > + } else { > + resrtextents = 0; > resblks = qblocks = XFS_DIOSTRAT_SPACE_RES(mp, resaligned); > - quota_flag = XFS_QMOPT_RES_REGBLKS; > - } > + quota_flag = XFS_QMOPT_RES_REGBLKS; > + } > > /* > * Allocate and setup the transaction > @@ -788,18 +788,12 @@ xfs_iomap_write_allocate( > nimaps = 0; > while (nimaps == 0) { > tp = xfs_trans_alloc(mp, XFS_TRANS_STRAT_WRITE); > + tp->t_flags |= XFS_TRANS_RESERVE; > nres = XFS_EXTENTADD_SPACE_RES(mp, XFS_DATA_FORK); > error = xfs_trans_reserve(tp, nres, > XFS_WRITE_LOG_RES(mp), > 0, XFS_TRANS_PERM_LOG_RES, > XFS_WRITE_LOG_COUNT); > - if (error == ENOSPC) { > - error = xfs_trans_reserve(tp, 0, > - XFS_WRITE_LOG_RES(mp), > - 0, > - XFS_TRANS_PERM_LOG_RES, > - XFS_WRITE_LOG_COUNT); > - } > if (error) { > xfs_trans_cancel(tp, 0); > return XFS_ERROR(error); > @@ -917,8 +911,8 @@ xfs_iomap_write_unwritten( > * from unwritten to real. Do allocations in a loop until > * we have covered the range passed in. > */ > - > tp = xfs_trans_alloc(mp, XFS_TRANS_STRAT_WRITE); > + tp->t_flags |= XFS_TRANS_RESERVE; > error = xfs_trans_reserve(tp, resblks, > XFS_WRITE_LOG_RES(mp), 0, > XFS_TRANS_PERM_LOG_RES, From owner-xfs@oss.sgi.com Sun Jun 3 23:15:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 23:15:28 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l546FLWt025769 for ; Sun, 3 Jun 2007 23:15:23 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA05952; Mon, 4 Jun 2007 16:15:17 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id AF6EF58C38C1; Mon, 4 Jun 2007 16:15:17 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 965631 - xfs_bmapi() fails to update previous extent pointer Message-Id: <20070604061517.AF6EF58C38C1@chook.melbourne.sgi.com> Date: Mon, 4 Jun 2007 16:15:17 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 11605 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs xfs_bmapi fails to update the previous extent pointer When processing multiple extent maps, xfs_bmapi needs to keep track of the extent behind the one it is currently working on to be able to trim extent ranges correctly. Failing to update the previous pointer can result in corrupted extent lists in memory and this will result in panics or assert failures. Update the previous pointer correctly when we move to the next extent to process. Date: Mon Jun 4 16:14:47 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: vapo@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28773a fs/xfs/xfs_bmap.c - 1.368 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.368&r2=text&tr2=1.367&f=h - Update the previous extent pointer correctly in xfs_bmapi. From owner-xfs@oss.sgi.com Sun Jun 3 23:33:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 23:33:38 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l546XXWt030048 for ; Sun, 3 Jun 2007 23:33:35 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA06451; Mon, 4 Jun 2007 16:33:29 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l546XSAf113366370; Mon, 4 Jun 2007 16:33:29 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l546XSXf113386261; Mon, 4 Jun 2007 16:33:28 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Jun 2007 16:33:28 +1000 From: David Chinner To: xfs-dev Cc: xfs-oss , asg-qa Subject: Review: fix test 004 to account for reserved space Message-ID: <20070604063328.GT85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 11606 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs With the changes to use some space by default in only in memory as a reserved pool, df and statfs will now output a fre block count that is slightly different to what is held in the superblock. Update the qa test to account for this change. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- xfstests/004 | 35 +++++++++++++++++++++++++---------- 1 file changed, 25 insertions(+), 10 deletions(-) Index: xfs-cmds/xfstests/004 =================================================================== --- xfs-cmds.orig/xfstests/004 2006-11-14 19:57:39.000000000 +1100 +++ xfs-cmds/xfstests/004 2007-05-04 16:38:03.957537306 +1000 @@ -67,21 +67,36 @@ xfs_db -r -c "freesp -s" $SCRATCH_DEV >$ echo "xfs_db for $SCRATCH_DEV" >>$seq.full cat $tmp.xfs_db >>$seq.full +eval `$XFS_IO_PROG -x -c resblks $SCRATCH_MNT 2>&1 \ + | $AWK_PROG '/available/ { printf "resblks=%u\n", $5 }'` +echo "resblks gave: resblks=$resblks" >>$seq.full + # check the 'blocks' field from freesp command is OK # since 2.6.18, df does not report the 4 blocks per AG that cannot # be allocated, hence we check for that exact mismatch. +# since ~2.6.22, reserved blocks are used by default and df does +# not report them, hence check for an exact mismatch. perl -ne ' - BEGIN { $avail ='$avail' * 512; - $answer="(no xfs_db free blocks line?)" } - /free blocks (\d+)$/ || next; - $freesp = $1 * '$dbsize'; - if ($freesp == $avail) { $answer = "yes"; } - else { + BEGIN { $avail ='$avail' * 512; + $answer="(no xfs_db free blocks line?)" } + /free blocks (\d+)$/ || next; + $freesp = $1 * '$dbsize'; + if ($freesp == $avail) { + $answer = "yes"; + } else { $avail = $avail + (('$agcount' + 1) * '$dbsize' * 4); - if ($freesp == $avail) { $answer = "yes"; } - else { $answer = "no ($freesp != $avail)"; } - } - END { print "$answer\n" } + if ($freesp == $avail) { + $answer = "yes"; + } else { + $avail = $avail + ('$resblks' * '$dbsize'); + if ($freesp == $avail) { + $answer = "yes"; + } else { + $answer = "no ($freesp != $avail)"; + } + } + } + END { print "$answer\n" } ' <$tmp.xfs_db >$tmp.ans ans="`cat $tmp.ans`" echo "Checking blocks column same as df: $ans" From owner-xfs@oss.sgi.com Sun Jun 3 23:58:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Jun 2007 23:58:49 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l546whWt008370 for ; Sun, 3 Jun 2007 23:58:45 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA06833; Mon, 4 Jun 2007 16:58:39 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 7054B58C38C1; Mon, 4 Jun 2007 16:58:39 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 965630 - xfs should flush the block device on unmount Message-Id: <20070604065839.7054B58C38C1@chook.melbourne.sgi.com> Date: Mon, 4 Jun 2007 16:58:39 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 11607 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Flush the block device before closing it on unmount. Date: Mon Jun 4 16:58:12 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28774a fs/xfs/linux-2.6/xfs_buf.c - 1.242 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.242&r2=text&tr2=1.241&f=h - Flush the block device before closing it on unmount. From owner-xfs@oss.sgi.com Mon Jun 4 00:18:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 00:18:50 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l547IiWt020789 for ; Mon, 4 Jun 2007 00:18:46 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA07298; Mon, 4 Jun 2007 17:18:40 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 341A958C38C1; Mon, 4 Jun 2007 17:18:40 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 964092 - synchronous direct I/O write calls are incomplete when returning to user space Message-Id: <20070604071840.341A958C38C1@chook.melbourne.sgi.com> Date: Mon, 4 Jun 2007 17:18:40 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 11608 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Block on unwritten extent conversion during synchronous direct I/O. Currently we do not wait on extent conversion to occur, and hence we can return to userspace from a sycnhronous direct I/O write without having completed all teh actions in the write. Hence a read after the write may see zeroes (unwritten extent) rather than the data that was written. Block the I/O completion by triggering a synchronous workqueue flush to ensure that the conversion has occurred before we return to userspace. Date: Mon Jun 4 17:18:01 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28775a fs/xfs/linux-2.6/xfs_aops.c - 1.144 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.144&r2=text&tr2=1.143&f=h - Make unwritten extent conversion occur synchronously for synchronous direct I/O to ensure it is completed before we return to userspace. From owner-xfs@oss.sgi.com Mon Jun 4 01:07:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 01:07:47 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l5487SWt011430 for ; Mon, 4 Jun 2007 01:07:31 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA08282; Mon, 4 Jun 2007 18:07:22 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l5487MAf113202618; Mon, 4 Jun 2007 18:07:22 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l5487Ksc113426956; Mon, 4 Jun 2007 18:07:20 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Jun 2007 18:07:20 +1000 From: David Chinner To: xfs-dev Cc: xfs-oss Subject: Review: apply transaction deltas atomically to superblock Message-ID: <20070604080720.GV85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 11609 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs When testing lazy superblock counters and ENOSPC conditions (test 083), I came across semi-regular assert failures in xfs_mod_incore_sb_batch() where the assert failure was occurring as a result of failing to *undo* block reservations for a transaction that had reserved all the blocks it was going to use up front. That is, we failed to apply the transaction delta when it should not have failed, and then we failed to remove the delta's that we had already applied. It turns out that that the problem is an interaction between the per-cpu superblock counters and xfs_trans_unreserve_and_mod_sb(). Prior to the per-cpu superblock counters, transaction delta's were applied under the XFS_SB_LOCK() and so were always applied atomically. The per-cpu superblock counters don't hold the XFS_SB_LOCK() and hence are not applied atomically. This was not thought to be a problem because each cahnge that needed ot be made had already been validated and reserved. It turns out that xfs_trans_unreserve_and_mod_sb() does something incredibly stupid. It applies changes to the free block in *two* separate deltas. The first change puts back the *entire reservation* to the superblock and then it takes away what was actually used. So now we have a window where the transaction reservation is undone and another thread can come along and use that reservation. the result is the second delta to mark the blocks as used fails with ENOSPC, and because the blocks need for the transaction reservation has been taken by something else, we then fail to get them back for the transaction reservation when we try to undo that delta. So, the fix is to simply calculate what the free block delta is and apply it in a single atomic delta. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_trans.c | 77 +++++++++++++++++++++++++++-------------------------- 1 file changed, 40 insertions(+), 37 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_trans.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_trans.c 2007-05-03 15:05:09.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_trans.c 2007-05-09 12:14:18.429409061 +1000 @@ -638,11 +638,23 @@ xfs_trans_apply_sb_deltas( } /* - * xfs_trans_unreserve_and_mod_sb() is called to release unused - * reservations and apply superblock counter changes to the in-core - * superblock. + * xfs_trans_unreserve_and_mod_sb() is called to release unused reservations + * and apply superblock counter changes to the in-core superblock. The + * t_res_fdblocks_delta and t_res_frextents_delta fields are explicitly NOT + * applied to the in-core superblock. The idea is that that has already been + * done. * * This is done efficiently with a single call to xfs_mod_incore_sb_batch(). + * However, we have to ensure that we only modify each superblock field only + * once because the application of the delta values may not be atomic. That can + * lead to ENOSPC races occurring if we have two separate modifcations of the + * free space counter to put back the entire reservation and then take away + * what we used. + * + * If we are not logging superblock counters, then the inode allocated/free and + * used block counts are not updated in the on disk superblock. In this case, + * XFS_TRANS_SB_DIRTY will not be set when the transaction is updated but we + * still need to update the incore superblock with the changes. */ STATIC void xfs_trans_unreserve_and_mod_sb( @@ -654,42 +666,43 @@ xfs_trans_unreserve_and_mod_sb( /* REFERENCED */ int error; int rsvd; + int64_t blkdelta = 0; + int64_t rtxdelta = 0; msbp = msb; rsvd = (tp->t_flags & XFS_TRANS_RESERVE) != 0; - /* - * Release any reserved blocks. Any that were allocated - * will be taken back again by fdblocks_delta below. - */ - if (tp->t_blk_res > 0) { + /* calculate free blocks delta */ + if (tp->t_blk_res > 0) + blkdelta = tp->t_blk_res; + + if ((tp->t_fdblocks_delta != 0) && + (xfs_sb_version_haslazysbcount(&mp->m_sb) || + (tp->t_flags & XFS_TRANS_SB_DIRTY))) + blkdelta += tp->t_fdblocks_delta; + + if (blkdelta != 0) { msbp->msb_field = XFS_SBS_FDBLOCKS; - msbp->msb_delta = tp->t_blk_res; + msbp->msb_delta = blkdelta; msbp++; } - /* - * Release any reserved real time extents . Any that were - * allocated will be taken back again by frextents_delta below. - */ - if (tp->t_rtx_res > 0) { + /* calculate free realtime extents delta */ + if (tp->t_rtx_res > 0) + rtxdelta = tp->t_rtx_res; + + if ((tp->t_frextents_delta != 0) && + (tp->t_flags & XFS_TRANS_SB_DIRTY)) + rtxdelta = tp->t_frextents_delta; + + if (rtxdelta != 0) { msbp->msb_field = XFS_SBS_FREXTENTS; - msbp->msb_delta = tp->t_rtx_res; + msbp->msb_delta = rtxdelta; msbp++; } - /* - * Apply any superblock modifications to the in-core version. - * The t_res_fdblocks_delta and t_res_frextents_delta fields are - * explicitly NOT applied to the in-core superblock. - * The idea is that that has already been done. - * - * If we are not logging superblock counters, then the inode - * allocated/free and used block counts are not updated in the - * on disk superblock. In this case, XFS_TRANS_SB_DIRTY will - * not be set when the transaction is updated but we still need - * to update the incore superblock with the changes. - */ + /* apply remaining deltas */ + if (xfs_sb_version_haslazysbcount(&mp->m_sb) || (tp->t_flags & XFS_TRANS_SB_DIRTY)) { if (tp->t_icount_delta != 0) { @@ -702,19 +715,9 @@ xfs_trans_unreserve_and_mod_sb( msbp->msb_delta = tp->t_ifree_delta; msbp++; } - if (tp->t_fdblocks_delta != 0) { - msbp->msb_field = XFS_SBS_FDBLOCKS; - msbp->msb_delta = tp->t_fdblocks_delta; - msbp++; - } } if (tp->t_flags & XFS_TRANS_SB_DIRTY) { - if (tp->t_frextents_delta != 0) { - msbp->msb_field = XFS_SBS_FREXTENTS; - msbp->msb_delta = tp->t_frextents_delta; - msbp++; - } if (tp->t_dblocks_delta != 0) { msbp->msb_field = XFS_SBS_DBLOCKS; msbp->msb_delta = tp->t_dblocks_delta; From owner-xfs@oss.sgi.com Mon Jun 4 01:28:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 01:28:27 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l548SHWt021598 for ; Mon, 4 Jun 2007 01:28:18 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA08635; Mon, 4 Jun 2007 18:28:12 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 49AF658C38C1; Mon, 4 Jun 2007 18:28:12 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 965636 - xfs_setfilesize panics on null xfs_inode Message-Id: <20070604082812.49AF658C38C1@chook.melbourne.sgi.com> Date: Mon, 4 Jun 2007 18:28:12 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 11610 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Handle null returned from xfs_vtoi() in xfs_setfilesize(). Date: Mon Jun 4 18:27:21 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes@sgi.com, olaf@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28777a fs/xfs/linux-2.6/xfs_aops.c - 1.145 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.145&r2=text&tr2=1.144&f=h - If we get a null xfs_inode in xfs_setfilesize(), we can't update the file size. Don't even bother trying. From owner-xfs@oss.sgi.com Mon Jun 4 01:46:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 01:46:24 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l548kJWt029446 for ; Mon, 4 Jun 2007 01:46:20 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA09062; Mon, 4 Jun 2007 18:46:10 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l548k9Af108660004; Mon, 4 Jun 2007 18:46:10 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l548k8E7113429636; Mon, 4 Jun 2007 18:46:08 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Jun 2007 18:46:08 +1000 From: David Chinner To: Christoph Hellwig Cc: David Chinner , xfs@oss.sgi.com Subject: Re: TAKE 965636 - xfs_setfilesize panics on null xfs_inode Message-ID: <20070604084608.GW85884050@sgi.com> References: <20070604082812.49AF658C38C1@chook.melbourne.sgi.com> <20070604083222.GA16922@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604083222.GA16922@infradead.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 11611 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 09:32:22AM +0100, Christoph Hellwig wrote: > On Mon, Jun 04, 2007 at 06:28:12PM +1000, David Chinner wrote: > > Handle null returned from xfs_vtoi() in xfs_setfilesize(). > > This doesn't make any sense at all. xfs_inodes always live longer than > vnodes. What's the backtrace of the problem you're seeing? The I/O completion handlers are used by CXFS clients as well. Hence we can't assume that the vnode is backed by a xfs_inode.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jun 4 01:49:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 01:49:46 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l548nhWt031500 for ; Mon, 4 Jun 2007 01:49:44 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1Hv7zC-0004QJ-QH; Mon, 04 Jun 2007 09:32:22 +0100 Date: Mon, 4 Jun 2007 09:32:22 +0100 From: Christoph Hellwig To: David Chinner Cc: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: Re: TAKE 965636 - xfs_setfilesize panics on null xfs_inode Message-ID: <20070604083222.GA16922@infradead.org> References: <20070604082812.49AF658C38C1@chook.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604082812.49AF658C38C1@chook.melbourne.sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 11612 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 06:28:12PM +1000, David Chinner wrote: > Handle null returned from xfs_vtoi() in xfs_setfilesize(). This doesn't make any sense at all. xfs_inodes always live longer than vnodes. What's the backtrace of the problem you're seeing? From owner-xfs@oss.sgi.com Mon Jun 4 01:52:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 01:52:32 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l548qTWt032585 for ; Mon, 4 Jun 2007 01:52:30 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1Hv8If-0004ah-Qw; Mon, 04 Jun 2007 09:52:29 +0100 Date: Mon, 4 Jun 2007 09:52:29 +0100 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: TAKE 965636 - xfs_setfilesize panics on null xfs_inode Message-ID: <20070604085229.GA17635@infradead.org> References: <20070604082812.49AF658C38C1@chook.melbourne.sgi.com> <20070604083222.GA16922@infradead.org> <20070604084608.GW85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604084608.GW85884050@sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 11613 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 06:46:08PM +1000, David Chinner wrote: > On Mon, Jun 04, 2007 at 09:32:22AM +0100, Christoph Hellwig wrote: > > On Mon, Jun 04, 2007 at 06:28:12PM +1000, David Chinner wrote: > > > Handle null returned from xfs_vtoi() in xfs_setfilesize(). > > > > This doesn't make any sense at all. xfs_inodes always live longer than > > vnodes. What's the backtrace of the problem you're seeing? > > The I/O completion handlers are used by CXFS clients as well. > Hence we can't assume that the vnode is backed by a xfs_inode.... Please switch them over to something different instead of crapping up the code like this From owner-xfs@oss.sgi.com Mon Jun 4 02:07:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 02:07:53 -0700 (PDT) Received: from mail5.voith.com (mail5.voith.com [62.225.5.140]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l5497iWt003384 for ; Mon, 4 Jun 2007 02:07:46 -0700 Received: from HDHS0111.euro1.voith.net ([172.21.49.6]) by mail5.voith.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jun 2007 10:55:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7A686.1D9B3AE1" Subject: XFS with project quota under linux? Date: Mon, 4 Jun 2007 10:55:35 +0200 Message-ID: <950DD867A5E1B04ABE82A56FCDC03A5E9CE8CF@HDHS0111.euro1.voith.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: XFS with project quota under linux? Thread-Index: Acemhh8K+x24xSSwTcG6vV51EFsg6A== From: "Jahnke, Steffen" To: X-OriginalArrivalTime: 04 Jun 2007 08:55:35.0690 (UTC) FILETIME=[1DAAA6A0:01C7A686] X-archive-position: 11614 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Steffen.Jahnke@vs-hydro.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A686.1D9B3AE1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I recently switched the quota usrquota to pquota on our Altix 4700 under SL= ES10. I then found out that the project quota is not updated if files are m= oved within the same filesystem. E.g. if I move a file from a different pro= ject to a new project it still belongs to the old project. The same thing h= appens if I move a file which not belongs to any project but which is on th= e filesystem mounted with pquota. Some details of our system: hdhu0250:/home/t # cat /etc/*release LSB_VERSION=3D"core-2.0-noarch:core-3.0-noarch:core-2.0-ia64:core-3.0-ia64" SGI ProPack 5SP1 for Linux, Build 501r2-0703010508 SUSE Linux Enterprise Server 10 (ia64) VERSION =3D 10 hdhu0250:/home/t # uname -a Linux hdhu0250 2.6.16.27-0.9-default #1 SMP Tue Feb 13 09:35:18 UTC 2007 ia= 64 ia64 ia64 GNU/Linux hdhu0250:/home # rpm -qa |grep xfs xfsdump-2.2.33-12.2 xfsprogs-2.7.11-18.2 Any help would be very appreciated. Maybe there is a developer version whic= h is already to be able to handle pquota correctly?? Mit freundlichen Gr=FC=DFen / Best regards Steffen Jahnke ---------------------------------------------------------------------------= ---- Voith Siemens Hydro Power Generation GmbH & Co. KG VSEC-International - tts Alexanderstrasse 11 89522 Heidenheim, Germany Tel +49 7321 37 2955 Fax +49 7321 37 7601 E-Mail steffen.jahnke@vs-hydro.com Internet http://www.voithsiemens.com ---------------------------------------------------------------------------= ---- Handelsregister: Reg. Gericht Ulm, HRA 661052 Sitz der Gesellschaft: Heidenheim Gesch=E4ftsf=FChrung: Dr. Hermut Kormann (Vorsitzender), Dr. Hermann Jung,=20 Dr. Hans-Peter Sollinger, Dr. Hubert Lienhard, Peter Edelmann, Martin Hennerici, Bertram Staudenmaier, Dr. Roland M=FCnch Pers=F6nlich haftende Gesellschafterin: J. M. Voith Verwaltungs GmbH Reg. Gericht Ulm, HRB 661225 <>=20 ------_=_NextPart_001_01C7A686.1D9B3AE1 Content-Type: text/x-vcard; name="Jahnke, Steffen.vcf" Content-Transfer-Encoding: base64 Content-Description: Jahnke, Steffen.vcf Content-Disposition: attachment; filename="Jahnke, Steffen.vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkphaG5rZTtTdGVmZmVuDQpG TjpKYWhua2UsIFN0ZWZmZW4NCk9SRzpWU0g7dHRzDQpURUw7V09SSztWT0lD RTorNDkgNzMyMSAzNyAyOTU1DQpBRFI7V09SSzo7dHRzO0FsZXhhbmRlcnN0 cmHfZSAxMTtIZWlkZW5oZWltOzs4OTUyMjtHZXJtYW55DQpMQUJFTDtXT1JL O0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6dHRzPTBEPTBBQWxleGFuZGVy c3RyYT1ERmUgMTE9MEQ9MEFIZWlkZW5oZWltIDg5NTIyPTBEPTBBR2VybWFu eQ0KRU1BSUw7UFJFRjtJTlRFUk5FVDpTdGVmZmVuLkphaG5rZUB2cy1oeWRy by5jb20NClJFVjoyMDA3MDQxMlQxMTM3MDVaDQpFTkQ6VkNBUkQNCg== ------_=_NextPart_001_01C7A686.1D9B3AE1-- From owner-xfs@oss.sgi.com Mon Jun 4 02:15:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 02:15:45 -0700 (PDT) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l549FfWt006143 for ; Mon, 4 Jun 2007 02:15:42 -0700 Received: from teal.hq.k1024.org (84-75-125-186.dclient.hispeed.ch [84.75.125.186]) by astra.simleu.ro (Postfix) with ESMTP id 46E6271; Mon, 4 Jun 2007 11:42:07 +0300 (EEST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id A411D40FE14; Mon, 4 Jun 2007 10:41:54 +0200 (CEST) Date: Mon, 4 Jun 2007 10:41:54 +0200 From: Iustin Pop To: David Chinner Cc: Ruben Porras , xfs@oss.sgi.com, cw@f00f.org Subject: Re: XFS shrink functionality Message-ID: <20070604084154.GA8273@teal.hq.k1024.org> Mail-Followup-To: David Chinner , Ruben Porras , xfs@oss.sgi.com, cw@f00f.org References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604001632.GA86004887@sgi.com> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 11615 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs Disclaimer: all the below is based on my weak understanding of the code, I don't claim I'm right below. On Mon, Jun 04, 2007 at 10:16:32AM +1000, David Chinner wrote: > Any work for this would need to be done against current mainline > of the xfs-dev tree. > > Yes, that patch is out of date, and it also did things that were not > necessary i.e. walk btrees to work out if AGs are empty or not. Well, I did what I could based on my own understanding of the code. Sorry if it's ugly :) > > I'm really curious about what happened to this patches and why they were > > discontinued. The second part never was made public, and there was also > > no answer. Was there any flaw in any of the posted code or anything in > > XFS that makes it especially hard to shrink [3] that discouraged the > > development? > > The posted code is only a *tiny* part of the shrink problem. My ideea at that time is to start small and be able to shrink an empty filesystem (or empty at least regarding the AGs that you want to clear). The point is that if AGs are lockable outside of a transaction (something like the freeze/unfreeze functionality at the fs level), then by simply copying the conflicting files you ensure that they are allocated on an available AG and when you remove the originals, the to-be-shrinked AGs become free. Yes, utterly non-optimal, but it was the simplest way to do it based on what I knew at the time. > > After that, the first questions that arouse are, > > would there be some assistance/groove in from the developers? > > Certainly there's help available. ;) Good to know. If there is at least more documentation about the internals, I could try to find some time to work on this again. > > > What are the programmers requirements from your point of view? > > Here's the "simple" bits that will allow you to shrink > the filesystem down to the end of the internal log: > > 0. Check space is available for shrink Can be done by actually allocating the space to be freed at the beggining of the transaction. Right? This is actually a bit more than needed, since when freeing an AG you also free some non-available space, but it's ok. > 1. Mark allocation groups as "don't use - going away soon" > - so we don't put new stuff in them while we > are moving all the bits out of them > - requires hooks in the allocators to prevent > the AG from being selected for allllocations > - must still allow allocations for the free lists > so that extent freeing can succeed > - *new transaction required*. > - also needs an "undo" (e.g. on partial failure) > so we need to be able to mark allocation groups > online again. So a question: can transaction be nested? Because the offline AG transation needs to live until the shrink transaction is done. I was more thinking that the offline-AG should be a bit on the AG that could be changed by the admin (like xfs_freeze); this could also help for other reasons than shrink (when on a big FS some AGs lie on a physical device and others on a different device, and you would like to restrict writes to a given AG, as much as possible). > 2. Move inodes out of offline AGs > - On Irix, we have a program called 'xfs_reno' which > converts 64 bit inode filesystems to 32 bit inode > filesystems. This needs to be: > - released under the GPL (should not be a problem). > - ported to linux > - modified to understand inodes sit in certain > AGs and to move them out of those AGs as needed. > - requires filesystem traversal to find all the > inodes to be moved. Interesing. I've read on the mail list of this before, but no other details. > > % wc -l xfs_reno.c > 1991 xfs_reno.c > > - even with "-o ikeep", this needs to trigger inode cluster > deletion in offline AGs (needs hooks in xfs_ifree()). This part (removal of inodes) is not actually needed if the icount == ifree (I presume this means that all the existing inodes are free). > 3. Move data out of offline AGs. > - this is difficult to do efficiently as we do not have > a block-to-owner reverse mapping in the filesystem. > Hence requires a walk of the *entire* filesystem to find > the owners of data blocks in the AGs being offlined. > - xfs_db wrapper might be the best way to do this... > > > > 4. Execute shrink > - new transaction - XFS_TRANS_SHRINKFS > - check AGs are empty > - icount == 0 > - freeblks == mp->m_sb.sb_agblocks > (will be a little more than this) > - check shrink won't go past end of internal log > - free AGs, updating superblock fields > - update perag structure > - not a simple realloc() as there may > be other threads using the structure at the > same time.... > My suggestion would be to start implementing these steps in reverse. 4) is the most important as it touches the entire FS. If 4) is working correctly, then 1) would be simpler (I think) and 3) can be implemented by just running a forced xfs_fsr against the conflicting files. I don't know about 2). Sorry if I'm blatantly wrong in my statements. Good to have more information! regards, iustin From owner-xfs@oss.sgi.com Mon Jun 4 02:21:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 02:21:32 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l549LPWt007722 for ; Mon, 4 Jun 2007 02:21:27 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA09755; Mon, 4 Jun 2007 19:21:19 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l549LHAf110747443; Mon, 4 Jun 2007 19:21:18 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l549LFSE112142526; Mon, 4 Jun 2007 19:21:15 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Jun 2007 19:21:15 +1000 From: David Chinner To: David Chinner , Ruben Porras , xfs@oss.sgi.com, cw@f00f.org Subject: Re: XFS shrink functionality Message-ID: <20070604092115.GX85884050@sgi.com> References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> <20070604084154.GA8273@teal.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604084154.GA8273@teal.hq.k1024.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 11616 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 10:41:54AM +0200, Iustin Pop wrote: > Disclaimer: all the below is based on my weak understanding of the code, > I don't claim I'm right below. > > On Mon, Jun 04, 2007 at 10:16:32AM +1000, David Chinner wrote: > > Any work for this would need to be done against current mainline > > of the xfs-dev tree. > > > > Yes, that patch is out of date, and it also did things that were not > > necessary i.e. walk btrees to work out if AGs are empty or not. > > Well, I did what I could based on my own understanding of the code. > Sorry if it's ugly :) > > > > I'm really curious about what happened to this patches and why they were > > > discontinued. The second part never was made public, and there was also > > > no answer. Was there any flaw in any of the posted code or anything in > > > XFS that makes it especially hard to shrink [3] that discouraged the > > > development? > > > > The posted code is only a *tiny* part of the shrink problem. > > My ideea at that time is to start small and be able to shrink an empty > filesystem (or empty at least regarding the AGs that you want to clear). Yes, that is one way of looking at it.... > The point is that if AGs are lockable outside of a transaction > (something like the freeze/unfreeze functionality at the fs level), then > by simply copying the conflicting files you ensure that they are Copying is not good enough - attributes must remain unchanged. The only thing we can't preserve is the inode number.... > allocated on an available AG and when you remove the originals, the > to-be-shrinked AGs become free. Yes, utterly non-optimal, but it was the > simplest way to do it based on what I knew at the time. Not quite that simple, unfortunately. You can't leave the AGs locked in the same way we do for a grow because we need to be able to use the AGs to move stuff about and that requires locking them. Hence we need a separate mechanism to prevent allocation in a given AG outside of locking them. Hence we need: - a transaction to mark AGs "no-allocate" - a transaction to mark AGs "allocatable" - a flag in each AGF/AGI to say the AG is available for allocations (persistent over crashes) - a flag in the per-ag structure to indicate allocation status of the AG. - everywhere we select an AG for allocation, we need to check this flag and skip the AG if it's not available. FWIW, the transactions can probably just be an extension of xfs_alloc_log_agf() and xfs_alloc_log_agi().... > > > What are the programmers requirements from your point of view? > > > > Here's the "simple" bits that will allow you to shrink > > the filesystem down to the end of the internal log: > > > > 0. Check space is available for shrink > Can be done by actually allocating the space to be freed at the > beggining of the transaction. Right? No, I mean that you need to check that there is sufficient space in the untouched AGs to mve all the data from the AG's to be removed into the remaining part of the filesystem. This is not part of a transaction, but still a check that needs to be done before starting.... > > 1. Mark allocation groups as "don't use - going away soon" > > - so we don't put new stuff in them while we > > are moving all the bits out of them > > - requires hooks in the allocators to prevent > > the AG from being selected for allllocations > > - must still allow allocations for the free lists > > so that extent freeing can succeed > > - *new transaction required*. > > - also needs an "undo" (e.g. on partial failure) > > so we need to be able to mark allocation groups > > online again. > > So a question: can transaction be nested? No. > Because the offline AG > transation needs to live until the shrink transaction is done. No it doesn't - the *state* needs to remain until we do the shrink, the transaction only needs to live until it has hit the disk. > I was > more thinking that the offline-AG should be a bit on the AG that could > be changed by the admin (like xfs_freeze); this could also help for > other reasons than shrink (when on a big FS some AGs lie on a physical > device and others on a different device, and you would like to restrict > writes to a given AG, as much as possible). Yes, that's exactly what I'm talking about ;) > > 2. Move inodes out of offline AGs > > - On Irix, we have a program called 'xfs_reno' which > > converts 64 bit inode filesystems to 32 bit inode > > filesystems. This needs to be: > > - released under the GPL (should not be a problem). > > - ported to linux > > - modified to understand inodes sit in certain > > AGs and to move them out of those AGs as needed. > > - requires filesystem traversal to find all the > > inodes to be moved. > Interesing. I've read on the mail list of this before, but no other > details. > > > > > % wc -l xfs_reno.c > > 1991 xfs_reno.c > > > > - even with "-o ikeep", this needs to trigger inode cluster > > deletion in offline AGs (needs hooks in xfs_ifree()). > This part (removal of inodes) is not actually needed if the icount == > ifree (I presume this means that all the existing inodes are free). Yes, I guess that could be done - it means extra stuffing about when doing the final shrink transaction, though. e.g. making sure that free block counts update correctly given that the AGI btrees will be consuming blocks - easier just to free the clusters as they get emptied, I think.... > > 3. Move data out of offline AGs. > > - this is difficult to do efficiently as we do not have > > a block-to-owner reverse mapping in the filesystem. > > Hence requires a walk of the *entire* filesystem to find > > the owners of data blocks in the AGs being offlined. > > - xfs_db wrapper might be the best way to do this... > > > > > > > > 4. Execute shrink > > - new transaction - XFS_TRANS_SHRINKFS > > - check AGs are empty > > - icount == 0 > > - freeblks == mp->m_sb.sb_agblocks > > (will be a little more than this) > > - check shrink won't go past end of internal log > > - free AGs, updating superblock fields > > - update perag structure > > - not a simple realloc() as there may > > be other threads using the structure at the > > same time.... > > > > My suggestion would be to start implementing these steps in reverse. 4) > is the most important as it touches the entire FS. If 4) is working > correctly, then 1) would be simpler (I think) and 3) can be implemented > by just running a forced xfs_fsr against the conflicting files. I don't > know about 2). Yeah, 1) and 4) are separable parts of the problem and can be done in any order. 2) can be implemented relatively easily as stated above. 3) is the hard one - we need to find the owner of each block (metadata and data) remaining in the AGs to be removed. This may be a directory btree block, a inode extent btree block, a data block, and extended attr block, etc. Moving the data blocks is easy to do (swap extents), but moving the metadata blocks is a major PITA as it will need to be done transactionally and that will require a bunch of new (complex) code to be written, I think. It will be of equivalent complexity to defragmenting metadata.... If we ignore the metadata block problem then finding and moving the data blocks should not be a problem - swap extents can be used for that as well - but it will be extremely time consuming and won't scale to large filesystem sizes.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jun 4 02:41:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 02:41:36 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l549fTWt019011 for ; Mon, 4 Jun 2007 02:41:30 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA10180; Mon, 4 Jun 2007 19:41:23 +1000 Date: Mon, 04 Jun 2007 19:41:19 +1000 From: Timothy Shimmin To: David Chinner , xfs-dev cc: xfs-oss Subject: Re: Review: Be smarter about handling ENOSPC during writeback Message-ID: In-Reply-To: <20070604045219.GG86004887@sgi.com> References: <20070604045219.GG86004887@sgi.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 11617 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Hi Dave, As an aside, I don't understand the following bit of code in xfs_reserve_blocks(): /* * If our previous reservation was larger than the current value, * then move any unused blocks back to the free pool. */ fdblks_delta = 0; if (mp->m_resblks > request) { lcounter = mp->m_resblks_avail - request; if (lcounter > 0) { /* release unused blocks */ fdblks_delta = lcounter; mp->m_resblks_avail -= lcounter; } I can't see why it is not calculating a delta for: delta = m_resblks - request and using that to update the m_resblks_avail and fdblks_delta; like we do in the case below where the request is the larger one. Instead it is affectively doing: m_resblks_avail = m_resblks_avail - m_resblks_avail + request = request It looks wrong to me. What am I missing? And why doesn't sb_fdblocks need to be updated in this case. Thanks, --Tim --On 4 June 2007 2:52:19 PM +1000 David Chinner wrote: > > During delayed allocation extent conversion or unwritten extent > conversion, we need to reserve some blocks for transactions > reservations. We need to reserve these blocks in case a btree > split occurs and we need to allocate some blocks. > > Unfortunately, we've only ever reserved the number of data blocks we > are allocating, so in both the unwritten and delalloc case we can > get ENOSPC to the transaction reservation. This is bad because in > both cases we cannot report the failure to the writing application. > > The fix is two-fold: > > 1 - leverage the reserved block infrastructure XFS already > has to reserve a small pool of blocks by default to allow > specially marked transactions to dip into when we are at > ENOSPC. > > Default setting is min(5%, 1024 blocks). > > 2 - convert critical transaction reservations to be allowed > to dip into this pool. Spots changed are delalloc > conversion, unwritten extent conversion and growing a > filesystem at ENOSPC. > > Comments? > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > --- > fs/xfs/xfs_fsops.c | 10 +++++++--- > fs/xfs/xfs_iomap.c | 22 ++++++++-------------- > fs/xfs/xfs_mount.c | 37 +++++++++++++++++++++++++++++++++++-- > 3 files changed, 50 insertions(+), 19 deletions(-) > > Index: 2.6.x-xfs-new/fs/xfs/xfs_fsops.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_fsops.c 2007-05-11 10:35:29.288847149 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_fsops.c 2007-05-11 11:13:34.195363437 +1000 > @@ -179,6 +179,7 @@ xfs_growfs_data_private( > up_write(&mp->m_peraglock); > } > tp = xfs_trans_alloc(mp, XFS_TRANS_GROWFS); > + tp->t_flags |= XFS_TRANS_RESERVE; > if ((error = xfs_trans_reserve(tp, XFS_GROWFS_SPACE_RES(mp), > XFS_GROWDATA_LOG_RES(mp), 0, 0, 0))) { > xfs_trans_cancel(tp, 0); > @@ -500,8 +501,9 @@ xfs_reserve_blocks( > unsigned long s; > > /* If inval is null, report current values and return */ > - > if (inval == (__uint64_t *)NULL) { > + if (!outval) > + return EINVAL; > outval->resblks = mp->m_resblks; > outval->resblks_avail = mp->m_resblks_avail; > return 0; > @@ -564,8 +566,10 @@ retry: > } > } > out: > - outval->resblks = mp->m_resblks; > - outval->resblks_avail = mp->m_resblks_avail; > + if (outval) { > + outval->resblks = mp->m_resblks; > + outval->resblks_avail = mp->m_resblks_avail; > + } > XFS_SB_UNLOCK(mp, s); > > if (fdblks_delta) { > Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2007-05-11 10:35:29.292846630 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2007-05-11 11:13:47.229662318 +1000 > @@ -718,7 +718,7 @@ xfs_mountfs( > bhv_vnode_t *rvp = NULL; > int readio_log, writeio_log; > xfs_daddr_t d; > - __uint64_t ret64; > + __uint64_t resblks; > __int64_t update_flags; > uint quotamount, quotaflags; > int agno; > @@ -835,6 +835,7 @@ xfs_mountfs( > */ > if ((mfsi_flags & XFS_MFSI_SECOND) == 0 && > (mp->m_flags & XFS_MOUNT_NOUUID) == 0) { > + __uint64_t ret64; > if (xfs_uuid_mount(mp)) { > error = XFS_ERROR(EINVAL); > goto error1; > @@ -1127,13 +1128,27 @@ xfs_mountfs( > goto error4; > } > > - > /* > * Complete the quota initialisation, post-log-replay component. > */ > if ((error = XFS_QM_MOUNT(mp, quotamount, quotaflags, mfsi_flags))) > goto error4; > > + /* > + * Now we are mounted, reserve a small amount of unused space for > + * privileged transactions. This is needed so that transaction > + * space required for critical operations can dip into this pool > + * when at ENOSPC. This is needed for operations like create with > + * attr, unwritten extent conversion at ENOSPC, etc. Data allocations > + * are not allowed to use this reserved space. > + * > + * We default to 5% or 1024 fsbs of space reserved, whichever is smaller. > + * This may drive us straight to ENOSPC on mount, but that implies > + * we were already there on the last unmount. > + */ > + resblks = min_t(__uint64_t, mp->m_sb.sb_dblocks / 20, 1024); > + xfs_reserve_blocks(mp, &resblks, NULL); > + > return 0; > > error4: > @@ -1172,6 +1187,7 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr > #if defined(DEBUG) || defined(INDUCE_IO_ERROR) > int64_t fsid; > #endif > + __uint64_t resblks; > > /* > * We can potentially deadlock here if we have an inode cluster > @@ -1200,6 +1216,23 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr > xfs_binval(mp->m_rtdev_targp); > } > > + /* > + * Unreserve any blocks we have so that when we unmount we don't account > + * the reserved free space as used. This is really only necessary for > + * lazy superblock counting because it trusts the incore superblock > + * counters to be aboslutely correct on clean unmount. > + * > + * We don't bother correcting this elsewhere for lazy superblock > + * counting because on mount of an unclean filesystem we reconstruct the > + * correct counter value and this is irrelevant. > + * > + * For non-lazy counter filesystems, this doesn't matter at all because > + * we only every apply deltas to the superblock and hence the incore > + * value does not matter.... > + */ > + resblks = 0; > + xfs_reserve_blocks(mp, &resblks, NULL); > + > xfs_log_sbcount(mp, 1); > xfs_unmountfs_writesb(mp); > xfs_unmountfs_wait(mp); /* wait for async bufs */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_iomap.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_iomap.c 2007-05-11 11:13:13.862017149 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_iomap.c 2007-05-11 11:13:34.199362915 +1000 > @@ -489,13 +489,13 @@ xfs_iomap_write_direct( > if (unlikely(rt)) { > resrtextents = qblocks = resaligned; > resrtextents /= mp->m_sb.sb_rextsize; > - resblks = XFS_DIOSTRAT_SPACE_RES(mp, 0); > - quota_flag = XFS_QMOPT_RES_RTBLKS; > - } else { > - resrtextents = 0; > + resblks = XFS_DIOSTRAT_SPACE_RES(mp, 0); > + quota_flag = XFS_QMOPT_RES_RTBLKS; > + } else { > + resrtextents = 0; > resblks = qblocks = XFS_DIOSTRAT_SPACE_RES(mp, resaligned); > - quota_flag = XFS_QMOPT_RES_REGBLKS; > - } > + quota_flag = XFS_QMOPT_RES_REGBLKS; > + } > > /* > * Allocate and setup the transaction > @@ -788,18 +788,12 @@ xfs_iomap_write_allocate( > nimaps = 0; > while (nimaps == 0) { > tp = xfs_trans_alloc(mp, XFS_TRANS_STRAT_WRITE); > + tp->t_flags |= XFS_TRANS_RESERVE; > nres = XFS_EXTENTADD_SPACE_RES(mp, XFS_DATA_FORK); > error = xfs_trans_reserve(tp, nres, > XFS_WRITE_LOG_RES(mp), > 0, XFS_TRANS_PERM_LOG_RES, > XFS_WRITE_LOG_COUNT); > - if (error == ENOSPC) { > - error = xfs_trans_reserve(tp, 0, > - XFS_WRITE_LOG_RES(mp), > - 0, > - XFS_TRANS_PERM_LOG_RES, > - XFS_WRITE_LOG_COUNT); > - } > if (error) { > xfs_trans_cancel(tp, 0); > return XFS_ERROR(error); > @@ -917,8 +911,8 @@ xfs_iomap_write_unwritten( > * from unwritten to real. Do allocations in a loop until > * we have covered the range passed in. > */ > - > tp = xfs_trans_alloc(mp, XFS_TRANS_STRAT_WRITE); > + tp->t_flags |= XFS_TRANS_RESERVE; > error = xfs_trans_reserve(tp, resblks, > XFS_WRITE_LOG_RES(mp), 0, > XFS_TRANS_PERM_LOG_RES, From owner-xfs@oss.sgi.com Mon Jun 4 07:12:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 07:12:07 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l54EBxWt010770 for ; Mon, 4 Jun 2007 07:12:01 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA16511; Tue, 5 Jun 2007 00:11:57 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l54EBuAf113627423; Tue, 5 Jun 2007 00:11:56 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l54EBs8T112839881; Tue, 5 Jun 2007 00:11:54 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 5 Jun 2007 00:11:54 +1000 From: David Chinner To: Timothy Shimmin Cc: David Chinner , xfs-dev , xfs-oss Subject: Re: Review: Be smarter about handling ENOSPC during writeback Message-ID: <20070604141154.GK86004887@sgi.com> References: <20070604045219.GG86004887@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 11618 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 07:41:19PM +1000, Timothy Shimmin wrote: > Hi Dave, > > As an aside, > I don't understand the following bit of code in xfs_reserve_blocks(): > /* > * If our previous reservation was larger than the current value, > * then move any unused blocks back to the free pool. > */ > fdblks_delta = 0; > if (mp->m_resblks > request) { > lcounter = mp->m_resblks_avail - request; > if (lcounter > 0) { /* release unused blocks */ > fdblks_delta = lcounter; > mp->m_resblks_avail -= lcounter; > } >>>> mp->m_resblks = request; > > I can't see why it is not calculating a delta for: > delta = m_resblks - request Because mp->m_resblks_avail is the amount of reservation space we have *unallocated*. i.e. 0 <= mp->m_resblks_avail <= mp->m_resblks IOWs, when we have used some blocks and then change mp->m_resblks, the amount we can can return is limited by the the available blocks, not the total reservation. > and using that to update the m_resblks_avail and fdblks_delta; > like we do in the case below where the request is the larger one. > Instead it is affectively doing: > m_resblks_avail = m_resblks_avail - m_resblks_avail + request > = request Surprising, but correct. When we reduce mp->m_resblks, mp->m_resblks_avail must be <= mp->m_resblks. IOWs we reduce the available blocks to that of the limit, so any allocated reserved blocks will now immediately be considered as unreserved and when they are freed the space will be immediately returned to the normal pool. Example: resblks = 1000, avail = 750. Set new resblks = 500. avail must be reduced to 500 and 250 must be freed. fdblks_delta = 0 if (1000 > 500) { lcounter = 750 - 500 = 250 if (250 > 0) { fdblks_delta = 250 resblks_avail = 500 } m_resblks = 500; } else { ..... } ..... if (fdblks_delta) { ..... error = xfs_mod_incore_sb(mp, XFS_SBS_FDBLOCKS, fdblks_delta, 0); ..... That "frees" 250 blocks. This is correct behaviour. > It looks wrong to me. > What am I missing? > And why doesn't sb_fdblocks need to be updated in this case. Because if we update mp->m_sb.sb_fdblocks, the value minus the reservation gets written to disk, and that means it is incorrect (xfs-check would fail) as the reservation is purely an in-memory construct... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jun 4 07:33:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 07:33:59 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54EXsWt017205 for ; Mon, 4 Jun 2007 07:33:56 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l54EXro6008984 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 4 Jun 2007 16:33:53 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l54EXqwD008980 for xfs@oss.sgi.com; Mon, 4 Jun 2007 16:33:52 +0200 Date: Mon, 4 Jun 2007 16:33:52 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] get rid of file_count abuse Message-ID: <20070604143352.GA8721@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 11619 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs A check for file_count is always a bad idea. Linux has the ->release method to deal with cleanups on last close and ->flush is only for the very rare case where we want to perform an operation on every drop of a reference to a file struct. This patch gets rid of vop_close and surrounding code in favour of simply doing the page flushing from ->release. Signed-off-by: Christoph Hellwig Index: linux-2.6/fs/xfs/linux-2.6/xfs_file.c =================================================================== --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_file.c 2007-06-01 13:20:26.000000000 +0200 +++ linux-2.6/fs/xfs/linux-2.6/xfs_file.c 2007-06-01 13:20:41.000000000 +0200 @@ -208,15 +208,6 @@ xfs_file_open( } STATIC int -xfs_file_close( - struct file *filp, - fl_owner_t id) -{ - return -bhv_vop_close(vn_from_inode(filp->f_path.dentry->d_inode), 0, - file_count(filp) > 1 ? L_FALSE : L_TRUE, NULL); -} - -STATIC int xfs_file_release( struct inode *inode, struct file *filp) @@ -461,7 +452,6 @@ const struct file_operations xfs_file_op #endif .mmap = xfs_file_mmap, .open = xfs_file_open, - .flush = xfs_file_close, .release = xfs_file_release, .fsync = xfs_file_fsync, #ifdef HAVE_FOP_OPEN_EXEC @@ -484,7 +474,6 @@ const struct file_operations xfs_invis_f #endif .mmap = xfs_file_mmap, .open = xfs_file_open, - .flush = xfs_file_close, .release = xfs_file_release, .fsync = xfs_file_fsync, }; Index: linux-2.6/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_vnode.h 2007-06-01 13:19:59.000000000 +0200 +++ linux-2.6/fs/xfs/linux-2.6/xfs_vnode.h 2007-06-01 13:21:05.000000000 +0200 @@ -129,10 +129,7 @@ typedef enum bhv_vchange { VCHANGE_FLAGS_IOEXCL_COUNT = 4 } bhv_vchange_t; -typedef enum { L_FALSE, L_TRUE } lastclose_t; - typedef int (*vop_open_t)(bhv_desc_t *, struct cred *); -typedef int (*vop_close_t)(bhv_desc_t *, int, lastclose_t, struct cred *); typedef ssize_t (*vop_read_t)(bhv_desc_t *, struct kiocb *, const struct iovec *, unsigned int, loff_t *, int, struct cred *); @@ -203,7 +200,6 @@ typedef int (*vop_iflush_t)(bhv_desc_t * typedef struct bhv_vnodeops { bhv_position_t vn_position; /* position within behavior chain */ vop_open_t vop_open; - vop_close_t vop_close; vop_read_t vop_read; vop_write_t vop_write; vop_sendfile_t vop_sendfile; @@ -249,7 +245,6 @@ typedef struct bhv_vnodeops { #define VNHEAD(vp) ((vp)->v_bh.bh_first) #define VOP(op, vp) (*((bhv_vnodeops_t *)VNHEAD(vp)->bd_ops)->op) #define bhv_vop_open(vp, cr) VOP(vop_open, vp)(VNHEAD(vp),cr) -#define bhv_vop_close(vp, f,last,cr) VOP(vop_close, vp)(VNHEAD(vp),f,last,cr) #define bhv_vop_read(vp,file,iov,segs,offset,ioflags,cr) \ VOP(vop_read, vp)(VNHEAD(vp),file,iov,segs,offset,ioflags,cr) #define bhv_vop_write(vp,file,iov,segs,offset,ioflags,cr) \ Index: linux-2.6/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_vnodeops.c 2007-06-01 13:17:41.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_vnodeops.c 2007-06-01 13:19:54.000000000 +0200 @@ -77,36 +77,6 @@ xfs_open( return 0; } -STATIC int -xfs_close( - bhv_desc_t *bdp, - int flags, - lastclose_t lastclose, - cred_t *credp) -{ - bhv_vnode_t *vp = BHV_TO_VNODE(bdp); - xfs_inode_t *ip = XFS_BHVTOI(bdp); - - if (XFS_FORCED_SHUTDOWN(ip->i_mount)) - return XFS_ERROR(EIO); - - if (lastclose != L_TRUE || !VN_ISREG(vp)) - return 0; - - /* - * If we previously truncated this file and removed old data in - * the process, we want to initiate "early" writeout on the last - * close. This is an attempt to combat the notorious NULL files - * problem which is particularly noticable from a truncate down, - * buffered (re-)write (delalloc), followed by a crash. What we - * are effectively doing here is significantly reducing the time - * window where we'd otherwise be exposed to that problem. - */ - if (VUNTRUNCATE(vp) && VN_DIRTY(vp) && ip->i_delayed_blks > 0) - return bhv_vop_flush_pages(vp, 0, -1, XFS_B_ASYNC, FI_NONE); - return 0; -} - /* * xfs_getattr */ @@ -1560,6 +1530,22 @@ xfs_release( if (vp->v_vfsp->vfs_flag & VFS_RDONLY) return 0; + if (!XFS_FORCED_SHUTDOWN(ip->i_mount)) { + /* + * If we previously truncated this file and removed old data + * in the process, we want to initiate "early" writeout on + * the last close. This is an attempt to combat the notorious + * NULL files problem which is particularly noticable from a + * truncate down, buffered (re-)write (delalloc), followed by + * a crash. What we are effectively doing here is + * significantly reducing the time window where we'd otherwise + * be exposed to that problem. + */ + if (VUNTRUNCATE(vp) && VN_DIRTY(vp) && ip->i_delayed_blks > 0) + bhv_vop_flush_pages(vp, 0, -1, XFS_B_ASYNC, FI_NONE); + } + + #ifdef HAVE_REFCACHE /* If we are in the NFS reference cache then don't do this now */ if (ip->i_refcache) @@ -4678,7 +4664,6 @@ xfs_change_file_space( bhv_vnodeops_t xfs_vnodeops = { BHV_IDENTITY_INIT(VN_BHV_XFS,VNODE_POSITION_XFS), .vop_open = xfs_open, - .vop_close = xfs_close, .vop_read = xfs_read, #ifdef HAVE_SENDFILE .vop_sendfile = xfs_sendfile, From owner-xfs@oss.sgi.com Mon Jun 4 07:36:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 07:36:14 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54Ea5Wt017971 for ; Mon, 4 Jun 2007 07:36:06 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l54Ea3o6009169 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 4 Jun 2007 16:36:03 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l54Ea2Dx009167 for xfs@oss.sgi.com; Mon, 4 Jun 2007 16:36:02 +0200 Date: Mon, 4 Jun 2007 16:36:02 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: Re: [PATCH] kill macro noise in xfs_dir2*.h Message-ID: <20070604143602.GA9081@lst.de> References: <20070418175859.GB18315@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070418175859.GB18315@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 11620 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Wed, Apr 18, 2007 at 07:59:00PM +0200, Christoph Hellwig wrote: > Remove all the macros that just give inline functions uppercase names. > > Signed-off-by: Christoph Hellwig This patch still hasn't made it to mainline, so here's a version rediffed for latest mainline because it's required for the next patch I'll post: Signed-off-by: Christoph Hellwig Index: linux-2.6/fs/xfs/xfs_dir2.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2.c 2007-04-28 09:37:26.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2.c 2007-05-12 13:38:34.000000000 +0200 @@ -55,9 +55,9 @@ xfs_dir_mount( XFS_MAX_BLOCKSIZE); mp->m_dirblksize = 1 << (mp->m_sb.sb_blocklog + mp->m_sb.sb_dirblklog); mp->m_dirblkfsbs = 1 << mp->m_sb.sb_dirblklog; - mp->m_dirdatablk = XFS_DIR2_DB_TO_DA(mp, XFS_DIR2_DATA_FIRSTDB(mp)); - mp->m_dirleafblk = XFS_DIR2_DB_TO_DA(mp, XFS_DIR2_LEAF_FIRSTDB(mp)); - mp->m_dirfreeblk = XFS_DIR2_DB_TO_DA(mp, XFS_DIR2_FREE_FIRSTDB(mp)); + mp->m_dirdatablk = xfs_dir2_db_to_da(mp, XFS_DIR2_DATA_FIRSTDB(mp)); + mp->m_dirleafblk = xfs_dir2_db_to_da(mp, XFS_DIR2_LEAF_FIRSTDB(mp)); + mp->m_dirfreeblk = xfs_dir2_db_to_da(mp, XFS_DIR2_FREE_FIRSTDB(mp)); mp->m_attr_node_ents = (mp->m_sb.sb_blocksize - (uint)sizeof(xfs_da_node_hdr_t)) / (uint)sizeof(xfs_da_node_entry_t); @@ -554,7 +554,7 @@ xfs_dir2_grow_inode( */ if (mapp != &map) kmem_free(mapp, sizeof(*mapp) * count); - *dbp = XFS_DIR2_DA_TO_DB(mp, (xfs_dablk_t)bno); + *dbp = xfs_dir2_da_to_db(mp, (xfs_dablk_t)bno); /* * Update file's size if this is the data space and it grew. */ @@ -706,7 +706,7 @@ xfs_dir2_shrink_inode( dp = args->dp; mp = dp->i_mount; tp = args->trans; - da = XFS_DIR2_DB_TO_DA(mp, db); + da = xfs_dir2_db_to_da(mp, db); /* * Unmap the fsblock(s). */ @@ -742,7 +742,7 @@ xfs_dir2_shrink_inode( /* * If the block isn't the last one in the directory, we're done. */ - if (dp->i_d.di_size > XFS_DIR2_DB_OFF_TO_BYTE(mp, db + 1, 0)) + if (dp->i_d.di_size > xfs_dir2_db_off_to_byte(mp, db + 1, 0)) return 0; bno = da; if ((error = xfs_bmap_last_before(tp, dp, &bno, XFS_DATA_FORK))) { Index: linux-2.6/fs/xfs/xfs_dir2_block.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_block.c 2007-05-10 10:53:16.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_block.c 2007-05-12 13:38:34.000000000 +0200 @@ -115,13 +115,13 @@ xfs_dir2_block_addname( xfs_da_brelse(tp, bp); return XFS_ERROR(EFSCORRUPTED); } - len = XFS_DIR2_DATA_ENTSIZE(args->namelen); + len = xfs_dir2_data_entsize(args->namelen); /* * Set up pointers to parts of the block. */ bf = block->hdr.bestfree; - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); - blp = XFS_DIR2_BLOCK_LEAF_P(btp); + btp = xfs_dir2_block_tail_p(mp, block); + blp = xfs_dir2_block_leaf_p(btp); /* * No stale entries? Need space for entry and new leaf. */ @@ -396,7 +396,7 @@ xfs_dir2_block_addname( * Fill in the leaf entry. */ blp[mid].hashval = cpu_to_be32(args->hashval); - blp[mid].address = cpu_to_be32(XFS_DIR2_BYTE_TO_DATAPTR(mp, + blp[mid].address = cpu_to_be32(xfs_dir2_byte_to_dataptr(mp, (char *)dep - (char *)block)); xfs_dir2_block_log_leaf(tp, bp, lfloglow, lfloghigh); /* @@ -411,7 +411,7 @@ xfs_dir2_block_addname( dep->inumber = cpu_to_be64(args->inumber); dep->namelen = args->namelen; memcpy(dep->name, args->name, args->namelen); - tagp = XFS_DIR2_DATA_ENTRY_TAG_P(dep); + tagp = xfs_dir2_data_entry_tag_p(dep); *tagp = cpu_to_be16((char *)dep - (char *)block); /* * Clean up the bestfree array and log the header, tail, and entry. @@ -455,7 +455,7 @@ xfs_dir2_block_getdents( /* * If the block number in the offset is out of range, we're done. */ - if (XFS_DIR2_DATAPTR_TO_DB(mp, uio->uio_offset) > mp->m_dirdatablk) { + if (xfs_dir2_dataptr_to_db(mp, uio->uio_offset) > mp->m_dirdatablk) { *eofp = 1; return 0; } @@ -471,15 +471,15 @@ xfs_dir2_block_getdents( * Extract the byte offset we start at from the seek pointer. * We'll skip entries before this. */ - wantoff = XFS_DIR2_DATAPTR_TO_OFF(mp, uio->uio_offset); + wantoff = xfs_dir2_dataptr_to_off(mp, uio->uio_offset); block = bp->data; xfs_dir2_data_check(dp, bp); /* * Set up values for the loop. */ - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); + btp = xfs_dir2_block_tail_p(mp, block); ptr = (char *)block->u; - endptr = (char *)XFS_DIR2_BLOCK_LEAF_P(btp); + endptr = (char *)xfs_dir2_block_leaf_p(btp); p.dbp = dbp; p.put = put; p.uio = uio; @@ -502,7 +502,7 @@ xfs_dir2_block_getdents( /* * Bump pointer for the next iteration. */ - ptr += XFS_DIR2_DATA_ENTSIZE(dep->namelen); + ptr += xfs_dir2_data_entsize(dep->namelen); /* * The entry is before the desired starting point, skip it. */ @@ -513,7 +513,7 @@ xfs_dir2_block_getdents( */ p.namelen = dep->namelen; - p.cook = XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk, + p.cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, ptr - (char *)block); p.ino = be64_to_cpu(dep->inumber); #if XFS_BIG_INUMS @@ -531,7 +531,7 @@ xfs_dir2_block_getdents( */ if (!p.done) { uio->uio_offset = - XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk, + xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, (char *)dep - (char *)block); xfs_da_brelse(tp, bp); return error; @@ -545,7 +545,7 @@ xfs_dir2_block_getdents( *eofp = 1; uio->uio_offset = - XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk + 1, 0); + xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk + 1, 0); xfs_da_brelse(tp, bp); @@ -569,8 +569,8 @@ xfs_dir2_block_log_leaf( mp = tp->t_mountp; block = bp->data; - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); - blp = XFS_DIR2_BLOCK_LEAF_P(btp); + btp = xfs_dir2_block_tail_p(mp, block); + blp = xfs_dir2_block_leaf_p(btp); xfs_da_log_buf(tp, bp, (uint)((char *)&blp[first] - (char *)block), (uint)((char *)&blp[last + 1] - (char *)block - 1)); } @@ -589,7 +589,7 @@ xfs_dir2_block_log_tail( mp = tp->t_mountp; block = bp->data; - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); + btp = xfs_dir2_block_tail_p(mp, block); xfs_da_log_buf(tp, bp, (uint)((char *)btp - (char *)block), (uint)((char *)(btp + 1) - (char *)block - 1)); } @@ -623,13 +623,13 @@ xfs_dir2_block_lookup( mp = dp->i_mount; block = bp->data; xfs_dir2_data_check(dp, bp); - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); - blp = XFS_DIR2_BLOCK_LEAF_P(btp); + btp = xfs_dir2_block_tail_p(mp, block); + blp = xfs_dir2_block_leaf_p(btp); /* * Get the offset from the leaf entry, to point to the data. */ dep = (xfs_dir2_data_entry_t *) - ((char *)block + XFS_DIR2_DATAPTR_TO_OFF(mp, be32_to_cpu(blp[ent].address))); + ((char *)block + xfs_dir2_dataptr_to_off(mp, be32_to_cpu(blp[ent].address))); /* * Fill in inode number, release the block. */ @@ -675,8 +675,8 @@ xfs_dir2_block_lookup_int( ASSERT(bp != NULL); block = bp->data; xfs_dir2_data_check(dp, bp); - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); - blp = XFS_DIR2_BLOCK_LEAF_P(btp); + btp = xfs_dir2_block_tail_p(mp, block); + blp = xfs_dir2_block_leaf_p(btp); /* * Loop doing a binary search for our hash value. * Find our entry, ENOENT if it's not there. @@ -713,7 +713,7 @@ xfs_dir2_block_lookup_int( * Get pointer to the entry from the leaf. */ dep = (xfs_dir2_data_entry_t *) - ((char *)block + XFS_DIR2_DATAPTR_TO_OFF(mp, addr)); + ((char *)block + xfs_dir2_dataptr_to_off(mp, addr)); /* * Compare, if it's right give back buffer & entry number. */ @@ -768,20 +768,20 @@ xfs_dir2_block_removename( tp = args->trans; mp = dp->i_mount; block = bp->data; - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); - blp = XFS_DIR2_BLOCK_LEAF_P(btp); + btp = xfs_dir2_block_tail_p(mp, block); + blp = xfs_dir2_block_leaf_p(btp); /* * Point to the data entry using the leaf entry. */ dep = (xfs_dir2_data_entry_t *) - ((char *)block + XFS_DIR2_DATAPTR_TO_OFF(mp, be32_to_cpu(blp[ent].address))); + ((char *)block + xfs_dir2_dataptr_to_off(mp, be32_to_cpu(blp[ent].address))); /* * Mark the data entry's space free. */ needlog = needscan = 0; xfs_dir2_data_make_free(tp, bp, (xfs_dir2_data_aoff_t)((char *)dep - (char *)block), - XFS_DIR2_DATA_ENTSIZE(dep->namelen), &needlog, &needscan); + xfs_dir2_data_entsize(dep->namelen), &needlog, &needscan); /* * Fix up the block tail. */ @@ -843,13 +843,13 @@ xfs_dir2_block_replace( dp = args->dp; mp = dp->i_mount; block = bp->data; - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); - blp = XFS_DIR2_BLOCK_LEAF_P(btp); + btp = xfs_dir2_block_tail_p(mp, block); + blp = xfs_dir2_block_leaf_p(btp); /* * Point to the data entry we need to change. */ dep = (xfs_dir2_data_entry_t *) - ((char *)block + XFS_DIR2_DATAPTR_TO_OFF(mp, be32_to_cpu(blp[ent].address))); + ((char *)block + xfs_dir2_dataptr_to_off(mp, be32_to_cpu(blp[ent].address))); ASSERT(be64_to_cpu(dep->inumber) != args->inumber); /* * Change the inode number to the new value. @@ -912,7 +912,7 @@ xfs_dir2_leaf_to_block( mp = dp->i_mount; leaf = lbp->data; ASSERT(be16_to_cpu(leaf->hdr.info.magic) == XFS_DIR2_LEAF1_MAGIC); - ltp = XFS_DIR2_LEAF_TAIL_P(mp, leaf); + ltp = xfs_dir2_leaf_tail_p(mp, leaf); /* * If there are data blocks other than the first one, take this * opportunity to remove trailing empty data blocks that may have @@ -920,7 +920,7 @@ xfs_dir2_leaf_to_block( * These will show up in the leaf bests table. */ while (dp->i_d.di_size > mp->m_dirblksize) { - bestsp = XFS_DIR2_LEAF_BESTS_P(ltp); + bestsp = xfs_dir2_leaf_bests_p(ltp); if (be16_to_cpu(bestsp[be32_to_cpu(ltp->bestcount) - 1]) == mp->m_dirblksize - (uint)sizeof(block->hdr)) { if ((error = @@ -974,14 +974,14 @@ xfs_dir2_leaf_to_block( /* * Initialize the block tail. */ - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); + btp = xfs_dir2_block_tail_p(mp, block); btp->count = cpu_to_be32(be16_to_cpu(leaf->hdr.count) - be16_to_cpu(leaf->hdr.stale)); btp->stale = 0; xfs_dir2_block_log_tail(tp, dbp); /* * Initialize the block leaf area. We compact out stale entries. */ - lep = XFS_DIR2_BLOCK_LEAF_P(btp); + lep = xfs_dir2_block_leaf_p(btp); for (from = to = 0; from < be16_to_cpu(leaf->hdr.count); from++) { if (be32_to_cpu(leaf->ents[from].address) == XFS_DIR2_NULL_DATAPTR) continue; @@ -1067,7 +1067,7 @@ xfs_dir2_sf_to_block( ASSERT(dp->i_df.if_bytes == dp->i_d.di_size); ASSERT(dp->i_df.if_u1.if_data != NULL); sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data; - ASSERT(dp->i_d.di_size >= XFS_DIR2_SF_HDR_SIZE(sfp->hdr.i8count)); + ASSERT(dp->i_d.di_size >= xfs_dir2_sf_hdr_size(sfp->hdr.i8count)); /* * Copy the directory into the stack buffer. * Then pitch the incore inode data so we can make extents. @@ -1119,10 +1119,10 @@ xfs_dir2_sf_to_block( /* * Fill in the tail. */ - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); + btp = xfs_dir2_block_tail_p(mp, block); btp->count = cpu_to_be32(sfp->hdr.count + 2); /* ., .. */ btp->stale = 0; - blp = XFS_DIR2_BLOCK_LEAF_P(btp); + blp = xfs_dir2_block_leaf_p(btp); endoffset = (uint)((char *)blp - (char *)block); /* * Remove the freespace, we'll manage it. @@ -1138,25 +1138,25 @@ xfs_dir2_sf_to_block( dep->inumber = cpu_to_be64(dp->i_ino); dep->namelen = 1; dep->name[0] = '.'; - tagp = XFS_DIR2_DATA_ENTRY_TAG_P(dep); + tagp = xfs_dir2_data_entry_tag_p(dep); *tagp = cpu_to_be16((char *)dep - (char *)block); xfs_dir2_data_log_entry(tp, bp, dep); blp[0].hashval = cpu_to_be32(xfs_dir_hash_dot); - blp[0].address = cpu_to_be32(XFS_DIR2_BYTE_TO_DATAPTR(mp, + blp[0].address = cpu_to_be32(xfs_dir2_byte_to_dataptr(mp, (char *)dep - (char *)block)); /* * Create entry for .. */ dep = (xfs_dir2_data_entry_t *) ((char *)block + XFS_DIR2_DATA_DOTDOT_OFFSET); - dep->inumber = cpu_to_be64(XFS_DIR2_SF_GET_INUMBER(sfp, &sfp->hdr.parent)); + dep->inumber = cpu_to_be64(xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent)); dep->namelen = 2; dep->name[0] = dep->name[1] = '.'; - tagp = XFS_DIR2_DATA_ENTRY_TAG_P(dep); + tagp = xfs_dir2_data_entry_tag_p(dep); *tagp = cpu_to_be16((char *)dep - (char *)block); xfs_dir2_data_log_entry(tp, bp, dep); blp[1].hashval = cpu_to_be32(xfs_dir_hash_dotdot); - blp[1].address = cpu_to_be32(XFS_DIR2_BYTE_TO_DATAPTR(mp, + blp[1].address = cpu_to_be32(xfs_dir2_byte_to_dataptr(mp, (char *)dep - (char *)block)); offset = XFS_DIR2_DATA_FIRST_OFFSET; /* @@ -1165,7 +1165,7 @@ xfs_dir2_sf_to_block( if ((i = 0) == sfp->hdr.count) sfep = NULL; else - sfep = XFS_DIR2_SF_FIRSTENTRY(sfp); + sfep = xfs_dir2_sf_firstentry(sfp); /* * Need to preserve the existing offset values in the sf directory. * Insert holes (unused entries) where necessary. @@ -1177,7 +1177,7 @@ xfs_dir2_sf_to_block( if (sfep == NULL) newoffset = endoffset; else - newoffset = XFS_DIR2_SF_GET_OFFSET(sfep); + newoffset = xfs_dir2_sf_get_offset(sfep); /* * There should be a hole here, make one. */ @@ -1186,7 +1186,7 @@ xfs_dir2_sf_to_block( ((char *)block + offset); dup->freetag = cpu_to_be16(XFS_DIR2_DATA_FREE_TAG); dup->length = cpu_to_be16(newoffset - offset); - *XFS_DIR2_DATA_UNUSED_TAG_P(dup) = cpu_to_be16( + *xfs_dir2_data_unused_tag_p(dup) = cpu_to_be16( ((char *)dup - (char *)block)); xfs_dir2_data_log_unused(tp, bp, dup); (void)xfs_dir2_data_freeinsert((xfs_dir2_data_t *)block, @@ -1198,22 +1198,22 @@ xfs_dir2_sf_to_block( * Copy a real entry. */ dep = (xfs_dir2_data_entry_t *)((char *)block + newoffset); - dep->inumber = cpu_to_be64(XFS_DIR2_SF_GET_INUMBER(sfp, - XFS_DIR2_SF_INUMBERP(sfep))); + dep->inumber = cpu_to_be64(xfs_dir2_sf_get_inumber(sfp, + xfs_dir2_sf_inumberp(sfep))); dep->namelen = sfep->namelen; memcpy(dep->name, sfep->name, dep->namelen); - tagp = XFS_DIR2_DATA_ENTRY_TAG_P(dep); + tagp = xfs_dir2_data_entry_tag_p(dep); *tagp = cpu_to_be16((char *)dep - (char *)block); xfs_dir2_data_log_entry(tp, bp, dep); blp[2 + i].hashval = cpu_to_be32(xfs_da_hashname( (char *)sfep->name, sfep->namelen)); - blp[2 + i].address = cpu_to_be32(XFS_DIR2_BYTE_TO_DATAPTR(mp, + blp[2 + i].address = cpu_to_be32(xfs_dir2_byte_to_dataptr(mp, (char *)dep - (char *)block)); offset = (int)((char *)(tagp + 1) - (char *)block); if (++i == sfp->hdr.count) sfep = NULL; else - sfep = XFS_DIR2_SF_NEXTENTRY(sfp, sfep); + sfep = xfs_dir2_sf_nextentry(sfp, sfep); } /* Done with the temporary buffer */ kmem_free(buf, buf_len); Index: linux-2.6/fs/xfs/xfs_dir2_block.h =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_block.h 2007-04-28 09:37:26.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_block.h 2007-05-12 13:38:34.000000000 +0200 @@ -60,7 +60,6 @@ typedef struct xfs_dir2_block { /* * Pointer to the leaf header embedded in a data block (1-block format) */ -#define XFS_DIR2_BLOCK_TAIL_P(mp,block) xfs_dir2_block_tail_p(mp,block) static inline xfs_dir2_block_tail_t * xfs_dir2_block_tail_p(struct xfs_mount *mp, xfs_dir2_block_t *block) { @@ -71,7 +70,6 @@ xfs_dir2_block_tail_p(struct xfs_mount * /* * Pointer to the leaf entries embedded in a data block (1-block format) */ -#define XFS_DIR2_BLOCK_LEAF_P(btp) xfs_dir2_block_leaf_p(btp) static inline struct xfs_dir2_leaf_entry * xfs_dir2_block_leaf_p(xfs_dir2_block_tail_t *btp) { Index: linux-2.6/fs/xfs/xfs_dir2_data.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_data.c 2007-05-10 10:53:16.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_data.c 2007-05-12 13:39:34.000000000 +0200 @@ -72,8 +72,8 @@ xfs_dir2_data_check( bf = d->hdr.bestfree; p = (char *)d->u; if (be32_to_cpu(d->hdr.magic) == XFS_DIR2_BLOCK_MAGIC) { - btp = XFS_DIR2_BLOCK_TAIL_P(mp, (xfs_dir2_block_t *)d); - lep = XFS_DIR2_BLOCK_LEAF_P(btp); + btp = xfs_dir2_block_tail_p(mp, (xfs_dir2_block_t *)d); + lep = xfs_dir2_block_leaf_p(btp); endp = (char *)lep; } else endp = (char *)d + mp->m_dirblksize; @@ -107,7 +107,7 @@ xfs_dir2_data_check( */ if (be16_to_cpu(dup->freetag) == XFS_DIR2_DATA_FREE_TAG) { ASSERT(lastfree == 0); - ASSERT(be16_to_cpu(*XFS_DIR2_DATA_UNUSED_TAG_P(dup)) == + ASSERT(be16_to_cpu(*xfs_dir2_data_unused_tag_p(dup)) == (char *)dup - (char *)d); dfp = xfs_dir2_data_freefind(d, dup); if (dfp) { @@ -131,12 +131,12 @@ xfs_dir2_data_check( dep = (xfs_dir2_data_entry_t *)p; ASSERT(dep->namelen != 0); ASSERT(xfs_dir_ino_validate(mp, be64_to_cpu(dep->inumber)) == 0); - ASSERT(be16_to_cpu(*XFS_DIR2_DATA_ENTRY_TAG_P(dep)) == + ASSERT(be16_to_cpu(*xfs_dir2_data_entry_tag_p(dep)) == (char *)dep - (char *)d); count++; lastfree = 0; if (be32_to_cpu(d->hdr.magic) == XFS_DIR2_BLOCK_MAGIC) { - addr = XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk, + addr = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, (xfs_dir2_data_aoff_t) ((char *)dep - (char *)d)); hash = xfs_da_hashname((char *)dep->name, dep->namelen); @@ -147,7 +147,7 @@ xfs_dir2_data_check( } ASSERT(i < be32_to_cpu(btp->count)); } - p += XFS_DIR2_DATA_ENTSIZE(dep->namelen); + p += xfs_dir2_data_entsize(dep->namelen); } /* * Need to have seen all the entries and all the bestfree slots. @@ -346,8 +346,8 @@ xfs_dir2_data_freescan( */ p = (char *)d->u; if (be32_to_cpu(d->hdr.magic) == XFS_DIR2_BLOCK_MAGIC) { - btp = XFS_DIR2_BLOCK_TAIL_P(mp, (xfs_dir2_block_t *)d); - endp = (char *)XFS_DIR2_BLOCK_LEAF_P(btp); + btp = xfs_dir2_block_tail_p(mp, (xfs_dir2_block_t *)d); + endp = (char *)xfs_dir2_block_leaf_p(btp); } else endp = (char *)d + mp->m_dirblksize; /* @@ -360,7 +360,7 @@ xfs_dir2_data_freescan( */ if (be16_to_cpu(dup->freetag) == XFS_DIR2_DATA_FREE_TAG) { ASSERT((char *)dup - (char *)d == - be16_to_cpu(*XFS_DIR2_DATA_UNUSED_TAG_P(dup))); + be16_to_cpu(*xfs_dir2_data_unused_tag_p(dup))); xfs_dir2_data_freeinsert(d, dup, loghead); p += be16_to_cpu(dup->length); } @@ -370,8 +370,8 @@ xfs_dir2_data_freescan( else { dep = (xfs_dir2_data_entry_t *)p; ASSERT((char *)dep - (char *)d == - be16_to_cpu(*XFS_DIR2_DATA_ENTRY_TAG_P(dep))); - p += XFS_DIR2_DATA_ENTSIZE(dep->namelen); + be16_to_cpu(*xfs_dir2_data_entry_tag_p(dep))); + p += xfs_dir2_data_entsize(dep->namelen); } } } @@ -402,7 +402,7 @@ xfs_dir2_data_init( /* * Get the buffer set up for the block. */ - error = xfs_da_get_buf(tp, dp, XFS_DIR2_DB_TO_DA(mp, blkno), -1, &bp, + error = xfs_da_get_buf(tp, dp, xfs_dir2_db_to_da(mp, blkno), -1, &bp, XFS_DATA_FORK); if (error) { return error; @@ -427,7 +427,7 @@ xfs_dir2_data_init( t=mp->m_dirblksize - (uint)sizeof(d->hdr); d->hdr.bestfree[0].length = cpu_to_be16(t); dup->length = cpu_to_be16(t); - *XFS_DIR2_DATA_UNUSED_TAG_P(dup) = cpu_to_be16((char *)dup - (char *)d); + *xfs_dir2_data_unused_tag_p(dup) = cpu_to_be16((char *)dup - (char *)d); /* * Log it and return it. */ @@ -452,7 +452,7 @@ xfs_dir2_data_log_entry( ASSERT(be32_to_cpu(d->hdr.magic) == XFS_DIR2_DATA_MAGIC || be32_to_cpu(d->hdr.magic) == XFS_DIR2_BLOCK_MAGIC); xfs_da_log_buf(tp, bp, (uint)((char *)dep - (char *)d), - (uint)((char *)(XFS_DIR2_DATA_ENTRY_TAG_P(dep) + 1) - + (uint)((char *)(xfs_dir2_data_entry_tag_p(dep) + 1) - (char *)d - 1)); } @@ -497,8 +497,8 @@ xfs_dir2_data_log_unused( * Log the end (tag) of the unused entry. */ xfs_da_log_buf(tp, bp, - (uint)((char *)XFS_DIR2_DATA_UNUSED_TAG_P(dup) - (char *)d), - (uint)((char *)XFS_DIR2_DATA_UNUSED_TAG_P(dup) - (char *)d + + (uint)((char *)xfs_dir2_data_unused_tag_p(dup) - (char *)d), + (uint)((char *)xfs_dir2_data_unused_tag_p(dup) - (char *)d + sizeof(xfs_dir2_data_off_t) - 1)); } @@ -535,8 +535,8 @@ xfs_dir2_data_make_free( xfs_dir2_block_tail_t *btp; /* block tail */ ASSERT(be32_to_cpu(d->hdr.magic) == XFS_DIR2_BLOCK_MAGIC); - btp = XFS_DIR2_BLOCK_TAIL_P(mp, (xfs_dir2_block_t *)d); - endptr = (char *)XFS_DIR2_BLOCK_LEAF_P(btp); + btp = xfs_dir2_block_tail_p(mp, (xfs_dir2_block_t *)d); + endptr = (char *)xfs_dir2_block_leaf_p(btp); } /* * If this isn't the start of the block, then back up to @@ -587,7 +587,7 @@ xfs_dir2_data_make_free( * Fix up the new big freespace. */ be16_add(&prevdup->length, len + be16_to_cpu(postdup->length)); - *XFS_DIR2_DATA_UNUSED_TAG_P(prevdup) = + *xfs_dir2_data_unused_tag_p(prevdup) = cpu_to_be16((char *)prevdup - (char *)d); xfs_dir2_data_log_unused(tp, bp, prevdup); if (!needscan) { @@ -621,7 +621,7 @@ xfs_dir2_data_make_free( else if (prevdup) { dfp = xfs_dir2_data_freefind(d, prevdup); be16_add(&prevdup->length, len); - *XFS_DIR2_DATA_UNUSED_TAG_P(prevdup) = + *xfs_dir2_data_unused_tag_p(prevdup) = cpu_to_be16((char *)prevdup - (char *)d); xfs_dir2_data_log_unused(tp, bp, prevdup); /* @@ -649,7 +649,7 @@ xfs_dir2_data_make_free( newdup = (xfs_dir2_data_unused_t *)((char *)d + offset); newdup->freetag = cpu_to_be16(XFS_DIR2_DATA_FREE_TAG); newdup->length = cpu_to_be16(len + be16_to_cpu(postdup->length)); - *XFS_DIR2_DATA_UNUSED_TAG_P(newdup) = + *xfs_dir2_data_unused_tag_p(newdup) = cpu_to_be16((char *)newdup - (char *)d); xfs_dir2_data_log_unused(tp, bp, newdup); /* @@ -676,7 +676,7 @@ xfs_dir2_data_make_free( newdup = (xfs_dir2_data_unused_t *)((char *)d + offset); newdup->freetag = cpu_to_be16(XFS_DIR2_DATA_FREE_TAG); newdup->length = cpu_to_be16(len); - *XFS_DIR2_DATA_UNUSED_TAG_P(newdup) = + *xfs_dir2_data_unused_tag_p(newdup) = cpu_to_be16((char *)newdup - (char *)d); xfs_dir2_data_log_unused(tp, bp, newdup); (void)xfs_dir2_data_freeinsert(d, newdup, needlogp); @@ -712,7 +712,7 @@ xfs_dir2_data_use_free( ASSERT(be16_to_cpu(dup->freetag) == XFS_DIR2_DATA_FREE_TAG); ASSERT(offset >= (char *)dup - (char *)d); ASSERT(offset + len <= (char *)dup + be16_to_cpu(dup->length) - (char *)d); - ASSERT((char *)dup - (char *)d == be16_to_cpu(*XFS_DIR2_DATA_UNUSED_TAG_P(dup))); + ASSERT((char *)dup - (char *)d == be16_to_cpu(*xfs_dir2_data_unused_tag_p(dup))); /* * Look up the entry in the bestfree table. */ @@ -745,7 +745,7 @@ xfs_dir2_data_use_free( newdup = (xfs_dir2_data_unused_t *)((char *)d + offset + len); newdup->freetag = cpu_to_be16(XFS_DIR2_DATA_FREE_TAG); newdup->length = cpu_to_be16(oldlen - len); - *XFS_DIR2_DATA_UNUSED_TAG_P(newdup) = + *xfs_dir2_data_unused_tag_p(newdup) = cpu_to_be16((char *)newdup - (char *)d); xfs_dir2_data_log_unused(tp, bp, newdup); /* @@ -772,7 +772,7 @@ xfs_dir2_data_use_free( else if (matchback) { newdup = dup; newdup->length = cpu_to_be16(((char *)d + offset) - (char *)newdup); - *XFS_DIR2_DATA_UNUSED_TAG_P(newdup) = + *xfs_dir2_data_unused_tag_p(newdup) = cpu_to_be16((char *)newdup - (char *)d); xfs_dir2_data_log_unused(tp, bp, newdup); /* @@ -799,13 +799,13 @@ xfs_dir2_data_use_free( else { newdup = dup; newdup->length = cpu_to_be16(((char *)d + offset) - (char *)newdup); - *XFS_DIR2_DATA_UNUSED_TAG_P(newdup) = + *xfs_dir2_data_unused_tag_p(newdup) = cpu_to_be16((char *)newdup - (char *)d); xfs_dir2_data_log_unused(tp, bp, newdup); newdup2 = (xfs_dir2_data_unused_t *)((char *)d + offset + len); newdup2->freetag = cpu_to_be16(XFS_DIR2_DATA_FREE_TAG); newdup2->length = cpu_to_be16(oldlen - len - be16_to_cpu(newdup->length)); - *XFS_DIR2_DATA_UNUSED_TAG_P(newdup2) = + *xfs_dir2_data_unused_tag_p(newdup2) = cpu_to_be16((char *)newdup2 - (char *)d); xfs_dir2_data_log_unused(tp, bp, newdup2); /* Index: linux-2.6/fs/xfs/xfs_dir2_data.h =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_data.h 2007-05-10 10:53:16.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_data.h 2007-05-12 13:38:34.000000000 +0200 @@ -44,7 +44,7 @@ struct xfs_trans; #define XFS_DIR2_DATA_SPACE 0 #define XFS_DIR2_DATA_OFFSET (XFS_DIR2_DATA_SPACE * XFS_DIR2_SPACE_SIZE) #define XFS_DIR2_DATA_FIRSTDB(mp) \ - XFS_DIR2_BYTE_TO_DB(mp, XFS_DIR2_DATA_OFFSET) + xfs_dir2_byte_to_db(mp, XFS_DIR2_DATA_OFFSET) /* * Offsets of . and .. in data space (always block 0) @@ -52,9 +52,9 @@ struct xfs_trans; #define XFS_DIR2_DATA_DOT_OFFSET \ ((xfs_dir2_data_aoff_t)sizeof(xfs_dir2_data_hdr_t)) #define XFS_DIR2_DATA_DOTDOT_OFFSET \ - (XFS_DIR2_DATA_DOT_OFFSET + XFS_DIR2_DATA_ENTSIZE(1)) + (XFS_DIR2_DATA_DOT_OFFSET + xfs_dir2_data_entsize(1)) #define XFS_DIR2_DATA_FIRST_OFFSET \ - (XFS_DIR2_DATA_DOTDOT_OFFSET + XFS_DIR2_DATA_ENTSIZE(2)) + (XFS_DIR2_DATA_DOTDOT_OFFSET + xfs_dir2_data_entsize(2)) /* * Structures. @@ -123,7 +123,6 @@ typedef struct xfs_dir2_data { /* * Size of a data entry. */ -#define XFS_DIR2_DATA_ENTSIZE(n) xfs_dir2_data_entsize(n) static inline int xfs_dir2_data_entsize(int n) { return (int)roundup(offsetof(xfs_dir2_data_entry_t, name[0]) + (n) + \ @@ -133,19 +132,16 @@ static inline int xfs_dir2_data_entsize( /* * Pointer to an entry's tag word. */ -#define XFS_DIR2_DATA_ENTRY_TAG_P(dep) xfs_dir2_data_entry_tag_p(dep) static inline __be16 * xfs_dir2_data_entry_tag_p(xfs_dir2_data_entry_t *dep) { return (__be16 *)((char *)dep + - XFS_DIR2_DATA_ENTSIZE(dep->namelen) - sizeof(__be16)); + xfs_dir2_data_entsize(dep->namelen) - sizeof(__be16)); } /* * Pointer to a freespace's tag word. */ -#define XFS_DIR2_DATA_UNUSED_TAG_P(dup) \ - xfs_dir2_data_unused_tag_p(dup) static inline __be16 * xfs_dir2_data_unused_tag_p(xfs_dir2_data_unused_t *dup) { Index: linux-2.6/fs/xfs/xfs_dir2_leaf.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_leaf.c 2007-05-10 10:53:16.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_leaf.c 2007-05-12 13:38:34.000000000 +0200 @@ -92,7 +92,7 @@ xfs_dir2_block_to_leaf( if ((error = xfs_da_grow_inode(args, &blkno))) { return error; } - ldb = XFS_DIR2_DA_TO_DB(mp, blkno); + ldb = xfs_dir2_da_to_db(mp, blkno); ASSERT(ldb == XFS_DIR2_LEAF_FIRSTDB(mp)); /* * Initialize the leaf block, get a buffer for it. @@ -104,8 +104,8 @@ xfs_dir2_block_to_leaf( leaf = lbp->data; block = dbp->data; xfs_dir2_data_check(dp, dbp); - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); - blp = XFS_DIR2_BLOCK_LEAF_P(btp); + btp = xfs_dir2_block_tail_p(mp, block); + blp = xfs_dir2_block_leaf_p(btp); /* * Set the counts in the leaf header. */ @@ -137,9 +137,9 @@ xfs_dir2_block_to_leaf( /* * Set up leaf tail and bests table. */ - ltp = XFS_DIR2_LEAF_TAIL_P(mp, leaf); + ltp = xfs_dir2_leaf_tail_p(mp, leaf); ltp->bestcount = cpu_to_be32(1); - bestsp = XFS_DIR2_LEAF_BESTS_P(ltp); + bestsp = xfs_dir2_leaf_bests_p(ltp); bestsp[0] = block->hdr.bestfree[0].length; /* * Log the data header and leaf bests table. @@ -209,9 +209,9 @@ xfs_dir2_leaf_addname( */ index = xfs_dir2_leaf_search_hash(args, lbp); leaf = lbp->data; - ltp = XFS_DIR2_LEAF_TAIL_P(mp, leaf); - bestsp = XFS_DIR2_LEAF_BESTS_P(ltp); - length = XFS_DIR2_DATA_ENTSIZE(args->namelen); + ltp = xfs_dir2_leaf_tail_p(mp, leaf); + bestsp = xfs_dir2_leaf_bests_p(ltp); + length = xfs_dir2_data_entsize(args->namelen); /* * See if there are any entries with the same hash value * and space in their block for the new entry. @@ -223,7 +223,7 @@ xfs_dir2_leaf_addname( index++, lep++) { if (be32_to_cpu(lep->address) == XFS_DIR2_NULL_DATAPTR) continue; - i = XFS_DIR2_DATAPTR_TO_DB(mp, be32_to_cpu(lep->address)); + i = xfs_dir2_dataptr_to_db(mp, be32_to_cpu(lep->address)); ASSERT(i < be32_to_cpu(ltp->bestcount)); ASSERT(be16_to_cpu(bestsp[i]) != NULLDATAOFF); if (be16_to_cpu(bestsp[i]) >= length) { @@ -378,7 +378,7 @@ xfs_dir2_leaf_addname( */ else { if ((error = - xfs_da_read_buf(tp, dp, XFS_DIR2_DB_TO_DA(mp, use_block), + xfs_da_read_buf(tp, dp, xfs_dir2_db_to_da(mp, use_block), -1, &dbp, XFS_DATA_FORK))) { xfs_da_brelse(tp, lbp); return error; @@ -407,7 +407,7 @@ xfs_dir2_leaf_addname( dep->inumber = cpu_to_be64(args->inumber); dep->namelen = args->namelen; memcpy(dep->name, args->name, dep->namelen); - tagp = XFS_DIR2_DATA_ENTRY_TAG_P(dep); + tagp = xfs_dir2_data_entry_tag_p(dep); *tagp = cpu_to_be16((char *)dep - (char *)data); /* * Need to scan fix up the bestfree table. @@ -529,7 +529,7 @@ xfs_dir2_leaf_addname( * Fill in the new leaf entry. */ lep->hashval = cpu_to_be32(args->hashval); - lep->address = cpu_to_be32(XFS_DIR2_DB_OFF_TO_DATAPTR(mp, use_block, + lep->address = cpu_to_be32(xfs_dir2_db_off_to_dataptr(mp, use_block, be16_to_cpu(*tagp))); /* * Log the leaf fields and give up the buffers. @@ -567,13 +567,13 @@ xfs_dir2_leaf_check( * Should factor in the size of the bests table as well. * We can deduce a value for that from di_size. */ - ASSERT(be16_to_cpu(leaf->hdr.count) <= XFS_DIR2_MAX_LEAF_ENTS(mp)); - ltp = XFS_DIR2_LEAF_TAIL_P(mp, leaf); + ASSERT(be16_to_cpu(leaf->hdr.count) <= xfs_dir2_max_leaf_ents(mp)); + ltp = xfs_dir2_leaf_tail_p(mp, leaf); /* * Leaves and bests don't overlap. */ ASSERT((char *)&leaf->ents[be16_to_cpu(leaf->hdr.count)] <= - (char *)XFS_DIR2_LEAF_BESTS_P(ltp)); + (char *)xfs_dir2_leaf_bests_p(ltp)); /* * Check hash value order, count stale entries. */ @@ -815,12 +815,12 @@ xfs_dir2_leaf_getdents( * Inside the loop we keep the main offset value as a byte offset * in the directory file. */ - curoff = XFS_DIR2_DATAPTR_TO_BYTE(mp, uio->uio_offset); + curoff = xfs_dir2_dataptr_to_byte(mp, uio->uio_offset); /* * Force this conversion through db so we truncate the offset * down to get the start of the data block. */ - map_off = XFS_DIR2_DB_TO_DA(mp, XFS_DIR2_BYTE_TO_DB(mp, curoff)); + map_off = xfs_dir2_db_to_da(mp, xfs_dir2_byte_to_db(mp, curoff)); /* * Loop over directory entries until we reach the end offset. * Get more blocks and readahead as necessary. @@ -870,7 +870,7 @@ xfs_dir2_leaf_getdents( */ if (1 + ra_want > map_blocks && map_off < - XFS_DIR2_BYTE_TO_DA(mp, XFS_DIR2_LEAF_OFFSET)) { + xfs_dir2_byte_to_da(mp, XFS_DIR2_LEAF_OFFSET)) { /* * Get more bmaps, fill in after the ones * we already have in the table. @@ -878,7 +878,7 @@ xfs_dir2_leaf_getdents( nmap = map_size - map_valid; error = xfs_bmapi(tp, dp, map_off, - XFS_DIR2_BYTE_TO_DA(mp, + xfs_dir2_byte_to_da(mp, XFS_DIR2_LEAF_OFFSET) - map_off, XFS_BMAPI_METADATA, NULL, 0, &map[map_valid], &nmap, NULL, NULL); @@ -903,7 +903,7 @@ xfs_dir2_leaf_getdents( map[map_valid + nmap - 1].br_blockcount; else map_off = - XFS_DIR2_BYTE_TO_DA(mp, + xfs_dir2_byte_to_da(mp, XFS_DIR2_LEAF_OFFSET); /* * Look for holes in the mapping, and @@ -931,14 +931,14 @@ xfs_dir2_leaf_getdents( * No valid mappings, so no more data blocks. */ if (!map_valid) { - curoff = XFS_DIR2_DA_TO_BYTE(mp, map_off); + curoff = xfs_dir2_da_to_byte(mp, map_off); break; } /* * Read the directory block starting at the first * mapping. */ - curdb = XFS_DIR2_DA_TO_DB(mp, map->br_startoff); + curdb = xfs_dir2_da_to_db(mp, map->br_startoff); error = xfs_da_read_buf(tp, dp, map->br_startoff, map->br_blockcount >= mp->m_dirblkfsbs ? XFS_FSB_TO_DADDR(mp, map->br_startblock) : @@ -1014,7 +1014,7 @@ xfs_dir2_leaf_getdents( /* * Having done a read, we need to set a new offset. */ - newoff = XFS_DIR2_DB_OFF_TO_BYTE(mp, curdb, 0); + newoff = xfs_dir2_db_off_to_byte(mp, curdb, 0); /* * Start of the current block. */ @@ -1024,7 +1024,7 @@ xfs_dir2_leaf_getdents( * Make sure we're in the right block. */ else if (curoff > newoff) - ASSERT(XFS_DIR2_BYTE_TO_DB(mp, curoff) == + ASSERT(xfs_dir2_byte_to_db(mp, curoff) == curdb); data = bp->data; xfs_dir2_data_check(dp, bp); @@ -1032,7 +1032,7 @@ xfs_dir2_leaf_getdents( * Find our position in the block. */ ptr = (char *)&data->u; - byteoff = XFS_DIR2_BYTE_TO_OFF(mp, curoff); + byteoff = xfs_dir2_byte_to_off(mp, curoff); /* * Skip past the header. */ @@ -1054,15 +1054,15 @@ xfs_dir2_leaf_getdents( } dep = (xfs_dir2_data_entry_t *)ptr; length = - XFS_DIR2_DATA_ENTSIZE(dep->namelen); + xfs_dir2_data_entsize(dep->namelen); ptr += length; } /* * Now set our real offset. */ curoff = - XFS_DIR2_DB_OFF_TO_BYTE(mp, - XFS_DIR2_BYTE_TO_DB(mp, curoff), + xfs_dir2_db_off_to_byte(mp, + xfs_dir2_byte_to_db(mp, curoff), (char *)ptr - (char *)data); if (ptr >= (char *)data + mp->m_dirblksize) { continue; @@ -1091,9 +1091,9 @@ xfs_dir2_leaf_getdents( p->namelen = dep->namelen; - length = XFS_DIR2_DATA_ENTSIZE(p->namelen); + length = xfs_dir2_data_entsize(p->namelen); - p->cook = XFS_DIR2_BYTE_TO_DATAPTR(mp, curoff + length); + p->cook = xfs_dir2_byte_to_dataptr(mp, curoff + length); p->ino = be64_to_cpu(dep->inumber); #if XFS_BIG_INUMS @@ -1121,10 +1121,10 @@ xfs_dir2_leaf_getdents( * All done. Set output offset value to current offset. */ *eofp = eof; - if (curoff > XFS_DIR2_DATAPTR_TO_BYTE(mp, XFS_DIR2_MAX_DATAPTR)) + if (curoff > xfs_dir2_dataptr_to_byte(mp, XFS_DIR2_MAX_DATAPTR)) uio->uio_offset = XFS_DIR2_MAX_DATAPTR; else - uio->uio_offset = XFS_DIR2_BYTE_TO_DATAPTR(mp, curoff); + uio->uio_offset = xfs_dir2_byte_to_dataptr(mp, curoff); kmem_free(map, map_size * sizeof(*map)); kmem_free(p, sizeof(*p)); if (bp) @@ -1159,7 +1159,7 @@ xfs_dir2_leaf_init( /* * Get the buffer for the block. */ - error = xfs_da_get_buf(tp, dp, XFS_DIR2_DB_TO_DA(mp, bno), -1, &bp, + error = xfs_da_get_buf(tp, dp, xfs_dir2_db_to_da(mp, bno), -1, &bp, XFS_DATA_FORK); if (error) { return error; @@ -1181,7 +1181,7 @@ xfs_dir2_leaf_init( * the block. */ if (magic == XFS_DIR2_LEAF1_MAGIC) { - ltp = XFS_DIR2_LEAF_TAIL_P(mp, leaf); + ltp = xfs_dir2_leaf_tail_p(mp, leaf); ltp->bestcount = 0; xfs_dir2_leaf_log_tail(tp, bp); } @@ -1206,9 +1206,9 @@ xfs_dir2_leaf_log_bests( leaf = bp->data; ASSERT(be16_to_cpu(leaf->hdr.info.magic) == XFS_DIR2_LEAF1_MAGIC); - ltp = XFS_DIR2_LEAF_TAIL_P(tp->t_mountp, leaf); - firstb = XFS_DIR2_LEAF_BESTS_P(ltp) + first; - lastb = XFS_DIR2_LEAF_BESTS_P(ltp) + last; + ltp = xfs_dir2_leaf_tail_p(tp->t_mountp, leaf); + firstb = xfs_dir2_leaf_bests_p(ltp) + first; + lastb = xfs_dir2_leaf_bests_p(ltp) + last; xfs_da_log_buf(tp, bp, (uint)((char *)firstb - (char *)leaf), (uint)((char *)lastb - (char *)leaf + sizeof(*lastb) - 1)); } @@ -1268,7 +1268,7 @@ xfs_dir2_leaf_log_tail( mp = tp->t_mountp; leaf = bp->data; ASSERT(be16_to_cpu(leaf->hdr.info.magic) == XFS_DIR2_LEAF1_MAGIC); - ltp = XFS_DIR2_LEAF_TAIL_P(mp, leaf); + ltp = xfs_dir2_leaf_tail_p(mp, leaf); xfs_da_log_buf(tp, bp, (uint)((char *)ltp - (char *)leaf), (uint)(mp->m_dirblksize - 1)); } @@ -1312,7 +1312,7 @@ xfs_dir2_leaf_lookup( */ dep = (xfs_dir2_data_entry_t *) ((char *)dbp->data + - XFS_DIR2_DATAPTR_TO_OFF(dp->i_mount, be32_to_cpu(lep->address))); + xfs_dir2_dataptr_to_off(dp->i_mount, be32_to_cpu(lep->address))); /* * Return the found inode number. */ @@ -1381,7 +1381,7 @@ xfs_dir2_leaf_lookup_int( /* * Get the new data block number. */ - newdb = XFS_DIR2_DATAPTR_TO_DB(mp, be32_to_cpu(lep->address)); + newdb = xfs_dir2_dataptr_to_db(mp, be32_to_cpu(lep->address)); /* * If it's not the same as the old data block number, * need to pitch the old one and read the new one. @@ -1391,7 +1391,7 @@ xfs_dir2_leaf_lookup_int( xfs_da_brelse(tp, dbp); if ((error = xfs_da_read_buf(tp, dp, - XFS_DIR2_DB_TO_DA(mp, newdb), -1, &dbp, + xfs_dir2_db_to_da(mp, newdb), -1, &dbp, XFS_DATA_FORK))) { xfs_da_brelse(tp, lbp); return error; @@ -1404,7 +1404,7 @@ xfs_dir2_leaf_lookup_int( */ dep = (xfs_dir2_data_entry_t *) ((char *)dbp->data + - XFS_DIR2_DATAPTR_TO_OFF(mp, be32_to_cpu(lep->address))); + xfs_dir2_dataptr_to_off(mp, be32_to_cpu(lep->address))); /* * If it matches then return it. */ @@ -1469,20 +1469,20 @@ xfs_dir2_leaf_removename( * Point to the leaf entry, use that to point to the data entry. */ lep = &leaf->ents[index]; - db = XFS_DIR2_DATAPTR_TO_DB(mp, be32_to_cpu(lep->address)); + db = xfs_dir2_dataptr_to_db(mp, be32_to_cpu(lep->address)); dep = (xfs_dir2_data_entry_t *) - ((char *)data + XFS_DIR2_DATAPTR_TO_OFF(mp, be32_to_cpu(lep->address))); + ((char *)data + xfs_dir2_dataptr_to_off(mp, be32_to_cpu(lep->address))); needscan = needlog = 0; oldbest = be16_to_cpu(data->hdr.bestfree[0].length); - ltp = XFS_DIR2_LEAF_TAIL_P(mp, leaf); - bestsp = XFS_DIR2_LEAF_BESTS_P(ltp); + ltp = xfs_dir2_leaf_tail_p(mp, leaf); + bestsp = xfs_dir2_leaf_bests_p(ltp); ASSERT(be16_to_cpu(bestsp[db]) == oldbest); /* * Mark the former data entry unused. */ xfs_dir2_data_make_free(tp, dbp, (xfs_dir2_data_aoff_t)((char *)dep - (char *)data), - XFS_DIR2_DATA_ENTSIZE(dep->namelen), &needlog, &needscan); + xfs_dir2_data_entsize(dep->namelen), &needlog, &needscan); /* * We just mark the leaf entry stale by putting a null in it. */ @@ -1602,7 +1602,7 @@ xfs_dir2_leaf_replace( */ dep = (xfs_dir2_data_entry_t *) ((char *)dbp->data + - XFS_DIR2_DATAPTR_TO_OFF(dp->i_mount, be32_to_cpu(lep->address))); + xfs_dir2_dataptr_to_off(dp->i_mount, be32_to_cpu(lep->address))); ASSERT(args->inumber != be64_to_cpu(dep->inumber)); /* * Put the new inode number in, log it. @@ -1698,7 +1698,7 @@ xfs_dir2_leaf_trim_data( /* * Read the offending data block. We need its buffer. */ - if ((error = xfs_da_read_buf(tp, dp, XFS_DIR2_DB_TO_DA(mp, db), -1, &dbp, + if ((error = xfs_da_read_buf(tp, dp, xfs_dir2_db_to_da(mp, db), -1, &dbp, XFS_DATA_FORK))) { return error; } @@ -1712,7 +1712,7 @@ xfs_dir2_leaf_trim_data( */ leaf = lbp->data; - ltp = XFS_DIR2_LEAF_TAIL_P(mp, leaf); + ltp = xfs_dir2_leaf_tail_p(mp, leaf); ASSERT(be16_to_cpu(data->hdr.bestfree[0].length) == mp->m_dirblksize - (uint)sizeof(data->hdr)); ASSERT(db == be32_to_cpu(ltp->bestcount) - 1); @@ -1727,7 +1727,7 @@ xfs_dir2_leaf_trim_data( /* * Eliminate the last bests entry from the table. */ - bestsp = XFS_DIR2_LEAF_BESTS_P(ltp); + bestsp = xfs_dir2_leaf_bests_p(ltp); be32_add(<p->bestcount, -1); memmove(&bestsp[1], &bestsp[0], be32_to_cpu(ltp->bestcount) * sizeof(*bestsp)); xfs_dir2_leaf_log_tail(tp, lbp); @@ -1838,12 +1838,12 @@ xfs_dir2_node_to_leaf( /* * Set up the leaf tail from the freespace block. */ - ltp = XFS_DIR2_LEAF_TAIL_P(mp, leaf); + ltp = xfs_dir2_leaf_tail_p(mp, leaf); ltp->bestcount = free->hdr.nvalid; /* * Set up the leaf bests table. */ - memcpy(XFS_DIR2_LEAF_BESTS_P(ltp), free->bests, + memcpy(xfs_dir2_leaf_bests_p(ltp), free->bests, be32_to_cpu(ltp->bestcount) * sizeof(leaf->bests[0])); xfs_dir2_leaf_log_bests(tp, lbp, 0, be32_to_cpu(ltp->bestcount) - 1); xfs_dir2_leaf_log_tail(tp, lbp); Index: linux-2.6/fs/xfs/xfs_dir2_leaf.h =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_leaf.h 2007-04-28 09:37:26.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_leaf.h 2007-05-12 13:38:34.000000000 +0200 @@ -32,7 +32,7 @@ struct xfs_trans; #define XFS_DIR2_LEAF_SPACE 1 #define XFS_DIR2_LEAF_OFFSET (XFS_DIR2_LEAF_SPACE * XFS_DIR2_SPACE_SIZE) #define XFS_DIR2_LEAF_FIRSTDB(mp) \ - XFS_DIR2_BYTE_TO_DB(mp, XFS_DIR2_LEAF_OFFSET) + xfs_dir2_byte_to_db(mp, XFS_DIR2_LEAF_OFFSET) /* * Offset in data space of a data entry. @@ -82,7 +82,6 @@ typedef struct xfs_dir2_leaf { * DB blocks here are logical directory block numbers, not filesystem blocks. */ -#define XFS_DIR2_MAX_LEAF_ENTS(mp) xfs_dir2_max_leaf_ents(mp) static inline int xfs_dir2_max_leaf_ents(struct xfs_mount *mp) { return (int)(((mp)->m_dirblksize - (uint)sizeof(xfs_dir2_leaf_hdr_t)) / @@ -92,7 +91,6 @@ static inline int xfs_dir2_max_leaf_ents /* * Get address of the bestcount field in the single-leaf block. */ -#define XFS_DIR2_LEAF_TAIL_P(mp,lp) xfs_dir2_leaf_tail_p(mp, lp) static inline xfs_dir2_leaf_tail_t * xfs_dir2_leaf_tail_p(struct xfs_mount *mp, xfs_dir2_leaf_t *lp) { @@ -104,7 +102,6 @@ xfs_dir2_leaf_tail_p(struct xfs_mount *m /* * Get address of the bests array in the single-leaf block. */ -#define XFS_DIR2_LEAF_BESTS_P(ltp) xfs_dir2_leaf_bests_p(ltp) static inline __be16 * xfs_dir2_leaf_bests_p(xfs_dir2_leaf_tail_t *ltp) { @@ -114,7 +111,6 @@ xfs_dir2_leaf_bests_p(xfs_dir2_leaf_tail /* * Convert dataptr to byte in file space */ -#define XFS_DIR2_DATAPTR_TO_BYTE(mp,dp) xfs_dir2_dataptr_to_byte(mp, dp) static inline xfs_dir2_off_t xfs_dir2_dataptr_to_byte(struct xfs_mount *mp, xfs_dir2_dataptr_t dp) { @@ -124,7 +120,6 @@ xfs_dir2_dataptr_to_byte(struct xfs_moun /* * Convert byte in file space to dataptr. It had better be aligned. */ -#define XFS_DIR2_BYTE_TO_DATAPTR(mp,by) xfs_dir2_byte_to_dataptr(mp,by) static inline xfs_dir2_dataptr_t xfs_dir2_byte_to_dataptr(struct xfs_mount *mp, xfs_dir2_off_t by) { @@ -134,7 +129,6 @@ xfs_dir2_byte_to_dataptr(struct xfs_moun /* * Convert byte in space to (DB) block */ -#define XFS_DIR2_BYTE_TO_DB(mp,by) xfs_dir2_byte_to_db(mp, by) static inline xfs_dir2_db_t xfs_dir2_byte_to_db(struct xfs_mount *mp, xfs_dir2_off_t by) { @@ -145,17 +139,15 @@ xfs_dir2_byte_to_db(struct xfs_mount *mp /* * Convert dataptr to a block number */ -#define XFS_DIR2_DATAPTR_TO_DB(mp,dp) xfs_dir2_dataptr_to_db(mp, dp) static inline xfs_dir2_db_t xfs_dir2_dataptr_to_db(struct xfs_mount *mp, xfs_dir2_dataptr_t dp) { - return XFS_DIR2_BYTE_TO_DB(mp, XFS_DIR2_DATAPTR_TO_BYTE(mp, dp)); + return xfs_dir2_byte_to_db(mp, xfs_dir2_dataptr_to_byte(mp, dp)); } /* * Convert byte in space to offset in a block */ -#define XFS_DIR2_BYTE_TO_OFF(mp,by) xfs_dir2_byte_to_off(mp, by) static inline xfs_dir2_data_aoff_t xfs_dir2_byte_to_off(struct xfs_mount *mp, xfs_dir2_off_t by) { @@ -166,18 +158,15 @@ xfs_dir2_byte_to_off(struct xfs_mount *m /* * Convert dataptr to a byte offset in a block */ -#define XFS_DIR2_DATAPTR_TO_OFF(mp,dp) xfs_dir2_dataptr_to_off(mp, dp) static inline xfs_dir2_data_aoff_t xfs_dir2_dataptr_to_off(struct xfs_mount *mp, xfs_dir2_dataptr_t dp) { - return XFS_DIR2_BYTE_TO_OFF(mp, XFS_DIR2_DATAPTR_TO_BYTE(mp, dp)); + return xfs_dir2_byte_to_off(mp, xfs_dir2_dataptr_to_byte(mp, dp)); } /* * Convert block and offset to byte in space */ -#define XFS_DIR2_DB_OFF_TO_BYTE(mp,db,o) \ - xfs_dir2_db_off_to_byte(mp, db, o) static inline xfs_dir2_off_t xfs_dir2_db_off_to_byte(struct xfs_mount *mp, xfs_dir2_db_t db, xfs_dir2_data_aoff_t o) @@ -189,7 +178,6 @@ xfs_dir2_db_off_to_byte(struct xfs_mount /* * Convert block (DB) to block (dablk) */ -#define XFS_DIR2_DB_TO_DA(mp,db) xfs_dir2_db_to_da(mp, db) static inline xfs_dablk_t xfs_dir2_db_to_da(struct xfs_mount *mp, xfs_dir2_db_t db) { @@ -199,29 +187,25 @@ xfs_dir2_db_to_da(struct xfs_mount *mp, /* * Convert byte in space to (DA) block */ -#define XFS_DIR2_BYTE_TO_DA(mp,by) xfs_dir2_byte_to_da(mp, by) static inline xfs_dablk_t xfs_dir2_byte_to_da(struct xfs_mount *mp, xfs_dir2_off_t by) { - return XFS_DIR2_DB_TO_DA(mp, XFS_DIR2_BYTE_TO_DB(mp, by)); + return xfs_dir2_db_to_da(mp, xfs_dir2_byte_to_db(mp, by)); } /* * Convert block and offset to dataptr */ -#define XFS_DIR2_DB_OFF_TO_DATAPTR(mp,db,o) \ - xfs_dir2_db_off_to_dataptr(mp, db, o) static inline xfs_dir2_dataptr_t xfs_dir2_db_off_to_dataptr(struct xfs_mount *mp, xfs_dir2_db_t db, xfs_dir2_data_aoff_t o) { - return XFS_DIR2_BYTE_TO_DATAPTR(mp, XFS_DIR2_DB_OFF_TO_BYTE(mp, db, o)); + return xfs_dir2_byte_to_dataptr(mp, xfs_dir2_db_off_to_byte(mp, db, o)); } /* * Convert block (dablk) to block (DB) */ -#define XFS_DIR2_DA_TO_DB(mp,da) xfs_dir2_da_to_db(mp, da) static inline xfs_dir2_db_t xfs_dir2_da_to_db(struct xfs_mount *mp, xfs_dablk_t da) { @@ -231,11 +215,10 @@ xfs_dir2_da_to_db(struct xfs_mount *mp, /* * Convert block (dablk) to byte offset in space */ -#define XFS_DIR2_DA_TO_BYTE(mp,da) xfs_dir2_da_to_byte(mp, da) static inline xfs_dir2_off_t xfs_dir2_da_to_byte(struct xfs_mount *mp, xfs_dablk_t da) { - return XFS_DIR2_DB_OFF_TO_BYTE(mp, XFS_DIR2_DA_TO_DB(mp, da), 0); + return xfs_dir2_db_off_to_byte(mp, xfs_dir2_da_to_db(mp, da), 0); } /* Index: linux-2.6/fs/xfs/xfs_dir2_node.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_node.c 2007-05-10 10:53:16.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_node.c 2007-05-12 13:38:34.000000000 +0200 @@ -136,14 +136,14 @@ xfs_dir2_leaf_to_node( /* * Get the buffer for the new freespace block. */ - if ((error = xfs_da_get_buf(tp, dp, XFS_DIR2_DB_TO_DA(mp, fdb), -1, &fbp, + if ((error = xfs_da_get_buf(tp, dp, xfs_dir2_db_to_da(mp, fdb), -1, &fbp, XFS_DATA_FORK))) { return error; } ASSERT(fbp != NULL); free = fbp->data; leaf = lbp->data; - ltp = XFS_DIR2_LEAF_TAIL_P(mp, leaf); + ltp = xfs_dir2_leaf_tail_p(mp, leaf); /* * Initialize the freespace block header. */ @@ -155,7 +155,7 @@ xfs_dir2_leaf_to_node( * Copy freespace entries from the leaf block to the new block. * Count active entries. */ - for (i = n = 0, from = XFS_DIR2_LEAF_BESTS_P(ltp), to = free->bests; + for (i = n = 0, from = xfs_dir2_leaf_bests_p(ltp), to = free->bests; i < be32_to_cpu(ltp->bestcount); i++, from++, to++) { if ((off = be16_to_cpu(*from)) != NULLDATAOFF) n++; @@ -215,7 +215,7 @@ xfs_dir2_leafn_add( * a compact. */ - if (be16_to_cpu(leaf->hdr.count) == XFS_DIR2_MAX_LEAF_ENTS(mp)) { + if (be16_to_cpu(leaf->hdr.count) == xfs_dir2_max_leaf_ents(mp)) { if (!leaf->hdr.stale) return XFS_ERROR(ENOSPC); compact = be16_to_cpu(leaf->hdr.stale) > 1; @@ -327,7 +327,7 @@ xfs_dir2_leafn_add( * Insert the new entry, log everything. */ lep->hashval = cpu_to_be32(args->hashval); - lep->address = cpu_to_be32(XFS_DIR2_DB_OFF_TO_DATAPTR(mp, + lep->address = cpu_to_be32(xfs_dir2_db_off_to_dataptr(mp, args->blkno, args->index)); xfs_dir2_leaf_log_header(tp, bp); xfs_dir2_leaf_log_ents(tp, bp, lfloglow, lfloghigh); @@ -352,7 +352,7 @@ xfs_dir2_leafn_check( leaf = bp->data; mp = dp->i_mount; ASSERT(be16_to_cpu(leaf->hdr.info.magic) == XFS_DIR2_LEAFN_MAGIC); - ASSERT(be16_to_cpu(leaf->hdr.count) <= XFS_DIR2_MAX_LEAF_ENTS(mp)); + ASSERT(be16_to_cpu(leaf->hdr.count) <= xfs_dir2_max_leaf_ents(mp)); for (i = stale = 0; i < be16_to_cpu(leaf->hdr.count); i++) { if (i + 1 < be16_to_cpu(leaf->hdr.count)) { ASSERT(be32_to_cpu(leaf->ents[i].hashval) <= @@ -440,7 +440,7 @@ xfs_dir2_leafn_lookup_int( if (args->addname) { curfdb = curbp ? state->extrablk.blkno : -1; curdb = -1; - length = XFS_DIR2_DATA_ENTSIZE(args->namelen); + length = xfs_dir2_data_entsize(args->namelen); if ((free = (curbp ? curbp->data : NULL))) ASSERT(be32_to_cpu(free->hdr.magic) == XFS_DIR2_FREE_MAGIC); } @@ -465,7 +465,7 @@ xfs_dir2_leafn_lookup_int( /* * Pull the data block number from the entry. */ - newdb = XFS_DIR2_DATAPTR_TO_DB(mp, be32_to_cpu(lep->address)); + newdb = xfs_dir2_dataptr_to_db(mp, be32_to_cpu(lep->address)); /* * For addname, we're looking for a place to put the new entry. * We want to use a data block with an entry of equal @@ -482,7 +482,7 @@ xfs_dir2_leafn_lookup_int( * Convert the data block to the free block * holding its freespace information. */ - newfdb = XFS_DIR2_DB_TO_FDB(mp, newdb); + newfdb = xfs_dir2_db_to_fdb(mp, newdb); /* * If it's not the one we have in hand, * read it in. @@ -497,7 +497,7 @@ xfs_dir2_leafn_lookup_int( * Read the free block. */ if ((error = xfs_da_read_buf(tp, dp, - XFS_DIR2_DB_TO_DA(mp, + xfs_dir2_db_to_da(mp, newfdb), -1, &curbp, XFS_DATA_FORK))) { @@ -517,7 +517,7 @@ xfs_dir2_leafn_lookup_int( /* * Get the index for our entry. */ - fi = XFS_DIR2_DB_TO_FDINDEX(mp, curdb); + fi = xfs_dir2_db_to_fdindex(mp, curdb); /* * If it has room, return it. */ @@ -561,7 +561,7 @@ xfs_dir2_leafn_lookup_int( */ if ((error = xfs_da_read_buf(tp, dp, - XFS_DIR2_DB_TO_DA(mp, newdb), -1, + xfs_dir2_db_to_da(mp, newdb), -1, &curbp, XFS_DATA_FORK))) { return error; } @@ -573,7 +573,7 @@ xfs_dir2_leafn_lookup_int( */ dep = (xfs_dir2_data_entry_t *) ((char *)curbp->data + - XFS_DIR2_DATAPTR_TO_OFF(mp, be32_to_cpu(lep->address))); + xfs_dir2_dataptr_to_off(mp, be32_to_cpu(lep->address))); /* * Compare the entry, return it if it matches. */ @@ -876,9 +876,9 @@ xfs_dir2_leafn_remove( /* * Extract the data block and offset from the entry. */ - db = XFS_DIR2_DATAPTR_TO_DB(mp, be32_to_cpu(lep->address)); + db = xfs_dir2_dataptr_to_db(mp, be32_to_cpu(lep->address)); ASSERT(dblk->blkno == db); - off = XFS_DIR2_DATAPTR_TO_OFF(mp, be32_to_cpu(lep->address)); + off = xfs_dir2_dataptr_to_off(mp, be32_to_cpu(lep->address)); ASSERT(dblk->index == off); /* * Kill the leaf entry by marking it stale. @@ -898,7 +898,7 @@ xfs_dir2_leafn_remove( longest = be16_to_cpu(data->hdr.bestfree[0].length); needlog = needscan = 0; xfs_dir2_data_make_free(tp, dbp, off, - XFS_DIR2_DATA_ENTSIZE(dep->namelen), &needlog, &needscan); + xfs_dir2_data_entsize(dep->namelen), &needlog, &needscan); /* * Rescan the data block freespaces for bestfree. * Log the data block header if needed. @@ -924,8 +924,8 @@ xfs_dir2_leafn_remove( * Convert the data block number to a free block, * read in the free block. */ - fdb = XFS_DIR2_DB_TO_FDB(mp, db); - if ((error = xfs_da_read_buf(tp, dp, XFS_DIR2_DB_TO_DA(mp, fdb), + fdb = xfs_dir2_db_to_fdb(mp, db); + if ((error = xfs_da_read_buf(tp, dp, xfs_dir2_db_to_da(mp, fdb), -1, &fbp, XFS_DATA_FORK))) { return error; } @@ -937,7 +937,7 @@ xfs_dir2_leafn_remove( /* * Calculate which entry we need to fix. */ - findex = XFS_DIR2_DB_TO_FDINDEX(mp, db); + findex = xfs_dir2_db_to_fdindex(mp, db); longest = be16_to_cpu(data->hdr.bestfree[0].length); /* * If the data block is now empty we can get rid of it @@ -1073,7 +1073,7 @@ xfs_dir2_leafn_split( /* * Initialize the new leaf block. */ - error = xfs_dir2_leaf_init(args, XFS_DIR2_DA_TO_DB(mp, blkno), + error = xfs_dir2_leaf_init(args, xfs_dir2_da_to_db(mp, blkno), &newblk->bp, XFS_DIR2_LEAFN_MAGIC); if (error) { return error; @@ -1385,7 +1385,7 @@ xfs_dir2_node_addname_int( dp = args->dp; mp = dp->i_mount; tp = args->trans; - length = XFS_DIR2_DATA_ENTSIZE(args->namelen); + length = xfs_dir2_data_entsize(args->namelen); /* * If we came in with a freespace block that means that lookup * found an entry with our hash value. This is the freespace @@ -1438,7 +1438,7 @@ xfs_dir2_node_addname_int( if ((error = xfs_bmap_last_offset(tp, dp, &fo, XFS_DATA_FORK))) return error; - lastfbno = XFS_DIR2_DA_TO_DB(mp, (xfs_dablk_t)fo); + lastfbno = xfs_dir2_da_to_db(mp, (xfs_dablk_t)fo); fbno = ifbno; } /* @@ -1474,7 +1474,7 @@ xfs_dir2_node_addname_int( * to avoid it. */ if ((error = xfs_da_read_buf(tp, dp, - XFS_DIR2_DB_TO_DA(mp, fbno), -2, &fbp, + xfs_dir2_db_to_da(mp, fbno), -2, &fbp, XFS_DATA_FORK))) { return error; } @@ -1550,9 +1550,9 @@ xfs_dir2_node_addname_int( * Get the freespace block corresponding to the data block * that was just allocated. */ - fbno = XFS_DIR2_DB_TO_FDB(mp, dbno); + fbno = xfs_dir2_db_to_fdb(mp, dbno); if (unlikely(error = xfs_da_read_buf(tp, dp, - XFS_DIR2_DB_TO_DA(mp, fbno), -2, &fbp, + xfs_dir2_db_to_da(mp, fbno), -2, &fbp, XFS_DATA_FORK))) { xfs_da_buf_done(dbp); return error; @@ -1567,14 +1567,14 @@ xfs_dir2_node_addname_int( return error; } - if (unlikely(XFS_DIR2_DB_TO_FDB(mp, dbno) != fbno)) { + if (unlikely(xfs_dir2_db_to_fdb(mp, dbno) != fbno)) { cmn_err(CE_ALERT, "xfs_dir2_node_addname_int: dir ino " "%llu needed freesp block %lld for\n" " data block %lld, got %lld\n" " ifbno %llu lastfbno %d\n", (unsigned long long)dp->i_ino, - (long long)XFS_DIR2_DB_TO_FDB(mp, dbno), + (long long)xfs_dir2_db_to_fdb(mp, dbno), (long long)dbno, (long long)fbno, (unsigned long long)ifbno, lastfbno); if (fblk) { @@ -1598,7 +1598,7 @@ xfs_dir2_node_addname_int( * Get a buffer for the new block. */ if ((error = xfs_da_get_buf(tp, dp, - XFS_DIR2_DB_TO_DA(mp, fbno), + xfs_dir2_db_to_da(mp, fbno), -1, &fbp, XFS_DATA_FORK))) { return error; } @@ -1623,7 +1623,7 @@ xfs_dir2_node_addname_int( /* * Set the freespace block index from the data block number. */ - findex = XFS_DIR2_DB_TO_FDINDEX(mp, dbno); + findex = xfs_dir2_db_to_fdindex(mp, dbno); /* * If it's after the end of the current entries in the * freespace block, extend that table. @@ -1669,7 +1669,7 @@ xfs_dir2_node_addname_int( * Read the data block in. */ if (unlikely( - error = xfs_da_read_buf(tp, dp, XFS_DIR2_DB_TO_DA(mp, dbno), + error = xfs_da_read_buf(tp, dp, xfs_dir2_db_to_da(mp, dbno), -1, &dbp, XFS_DATA_FORK))) { if ((fblk == NULL || fblk->bp == NULL) && fbp != NULL) xfs_da_buf_done(fbp); @@ -1698,7 +1698,7 @@ xfs_dir2_node_addname_int( dep->inumber = cpu_to_be64(args->inumber); dep->namelen = args->namelen; memcpy(dep->name, args->name, dep->namelen); - tagp = XFS_DIR2_DATA_ENTRY_TAG_P(dep); + tagp = xfs_dir2_data_entry_tag_p(dep); *tagp = cpu_to_be16((char *)dep - (char *)data); xfs_dir2_data_log_entry(tp, dbp, dep); /* @@ -1904,7 +1904,7 @@ xfs_dir2_node_replace( ASSERT(be32_to_cpu(data->hdr.magic) == XFS_DIR2_DATA_MAGIC); dep = (xfs_dir2_data_entry_t *) ((char *)data + - XFS_DIR2_DATAPTR_TO_OFF(state->mp, be32_to_cpu(lep->address))); + xfs_dir2_dataptr_to_off(state->mp, be32_to_cpu(lep->address))); ASSERT(inum != be64_to_cpu(dep->inumber)); /* * Fill in the new inode number and log the entry. @@ -1980,7 +1980,7 @@ xfs_dir2_node_trim_free( * Blow the block away. */ if ((error = - xfs_dir2_shrink_inode(args, XFS_DIR2_DA_TO_DB(mp, (xfs_dablk_t)fo), + xfs_dir2_shrink_inode(args, xfs_dir2_da_to_db(mp, (xfs_dablk_t)fo), bp))) { /* * Can't fail with ENOSPC since that only happens with no Index: linux-2.6/fs/xfs/xfs_dir2_node.h =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_node.h 2007-04-28 09:37:26.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_node.h 2007-05-12 13:38:34.000000000 +0200 @@ -36,7 +36,7 @@ struct xfs_trans; #define XFS_DIR2_FREE_SPACE 2 #define XFS_DIR2_FREE_OFFSET (XFS_DIR2_FREE_SPACE * XFS_DIR2_SPACE_SIZE) #define XFS_DIR2_FREE_FIRSTDB(mp) \ - XFS_DIR2_BYTE_TO_DB(mp, XFS_DIR2_FREE_OFFSET) + xfs_dir2_byte_to_db(mp, XFS_DIR2_FREE_OFFSET) #define XFS_DIR2_FREE_MAGIC 0x58443246 /* XD2F */ @@ -60,7 +60,6 @@ typedef struct xfs_dir2_free { /* * Convert data space db to the corresponding free db. */ -#define XFS_DIR2_DB_TO_FDB(mp,db) xfs_dir2_db_to_fdb(mp, db) static inline xfs_dir2_db_t xfs_dir2_db_to_fdb(struct xfs_mount *mp, xfs_dir2_db_t db) { @@ -70,7 +69,6 @@ xfs_dir2_db_to_fdb(struct xfs_mount *mp, /* * Convert data space db to the corresponding index in a free db. */ -#define XFS_DIR2_DB_TO_FDINDEX(mp,db) xfs_dir2_db_to_fdindex(mp, db) static inline int xfs_dir2_db_to_fdindex(struct xfs_mount *mp, xfs_dir2_db_t db) { Index: linux-2.6/fs/xfs/xfs_dir2_sf.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_sf.c 2007-04-28 09:37:26.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_sf.c 2007-05-12 13:38:34.000000000 +0200 @@ -89,8 +89,8 @@ xfs_dir2_block_sfsize( mp = dp->i_mount; count = i8count = namelen = 0; - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); - blp = XFS_DIR2_BLOCK_LEAF_P(btp); + btp = xfs_dir2_block_tail_p(mp, block); + blp = xfs_dir2_block_leaf_p(btp); /* * Iterate over the block's data entries by using the leaf pointers. @@ -102,7 +102,7 @@ xfs_dir2_block_sfsize( * Calculate the pointer to the entry at hand. */ dep = (xfs_dir2_data_entry_t *) - ((char *)block + XFS_DIR2_DATAPTR_TO_OFF(mp, addr)); + ((char *)block + xfs_dir2_dataptr_to_off(mp, addr)); /* * Detect . and .., so we can special-case them. * . is not included in sf directories. @@ -124,7 +124,7 @@ xfs_dir2_block_sfsize( /* * Calculate the new size, see if we should give up yet. */ - size = XFS_DIR2_SF_HDR_SIZE(i8count) + /* header */ + size = xfs_dir2_sf_hdr_size(i8count) + /* header */ count + /* namelen */ count * (uint)sizeof(xfs_dir2_sf_off_t) + /* offset */ namelen + /* name */ @@ -139,7 +139,7 @@ xfs_dir2_block_sfsize( */ sfhp->count = count; sfhp->i8count = i8count; - XFS_DIR2_SF_PUT_INUMBER((xfs_dir2_sf_t *)sfhp, &parent, &sfhp->parent); + xfs_dir2_sf_put_inumber((xfs_dir2_sf_t *)sfhp, &parent, &sfhp->parent); return size; } @@ -199,15 +199,15 @@ xfs_dir2_block_to_sf( * Copy the header into the newly allocate local space. */ sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data; - memcpy(sfp, sfhp, XFS_DIR2_SF_HDR_SIZE(sfhp->i8count)); + memcpy(sfp, sfhp, xfs_dir2_sf_hdr_size(sfhp->i8count)); dp->i_d.di_size = size; /* * Set up to loop over the block's entries. */ - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); + btp = xfs_dir2_block_tail_p(mp, block); ptr = (char *)block->u; - endptr = (char *)XFS_DIR2_BLOCK_LEAF_P(btp); - sfep = XFS_DIR2_SF_FIRSTENTRY(sfp); + endptr = (char *)xfs_dir2_block_leaf_p(btp); + sfep = xfs_dir2_sf_firstentry(sfp); /* * Loop over the active and unused entries. * Stop when we reach the leaf/tail portion of the block. @@ -233,22 +233,22 @@ xfs_dir2_block_to_sf( else if (dep->namelen == 2 && dep->name[0] == '.' && dep->name[1] == '.') ASSERT(be64_to_cpu(dep->inumber) == - XFS_DIR2_SF_GET_INUMBER(sfp, &sfp->hdr.parent)); + xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent)); /* * Normal entry, copy it into shortform. */ else { sfep->namelen = dep->namelen; - XFS_DIR2_SF_PUT_OFFSET(sfep, + xfs_dir2_sf_put_offset(sfep, (xfs_dir2_data_aoff_t) ((char *)dep - (char *)block)); memcpy(sfep->name, dep->name, dep->namelen); temp = be64_to_cpu(dep->inumber); - XFS_DIR2_SF_PUT_INUMBER(sfp, &temp, - XFS_DIR2_SF_INUMBERP(sfep)); - sfep = XFS_DIR2_SF_NEXTENTRY(sfp, sfep); + xfs_dir2_sf_put_inumber(sfp, &temp, + xfs_dir2_sf_inumberp(sfep)); + sfep = xfs_dir2_sf_nextentry(sfp, sfep); } - ptr += XFS_DIR2_DATA_ENTSIZE(dep->namelen); + ptr += xfs_dir2_data_entsize(dep->namelen); } ASSERT((char *)sfep - (char *)sfp == size); xfs_dir2_sf_check(args); @@ -294,11 +294,11 @@ xfs_dir2_sf_addname( ASSERT(dp->i_df.if_bytes == dp->i_d.di_size); ASSERT(dp->i_df.if_u1.if_data != NULL); sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data; - ASSERT(dp->i_d.di_size >= XFS_DIR2_SF_HDR_SIZE(sfp->hdr.i8count)); + ASSERT(dp->i_d.di_size >= xfs_dir2_sf_hdr_size(sfp->hdr.i8count)); /* * Compute entry (and change in) size. */ - add_entsize = XFS_DIR2_SF_ENTSIZE_BYNAME(sfp, args->namelen); + add_entsize = xfs_dir2_sf_entsize_byname(sfp, args->namelen); incr_isize = add_entsize; objchange = 0; #if XFS_BIG_INUMS @@ -392,7 +392,7 @@ xfs_dir2_sf_addname_easy( /* * Grow the in-inode space. */ - xfs_idata_realloc(dp, XFS_DIR2_SF_ENTSIZE_BYNAME(sfp, args->namelen), + xfs_idata_realloc(dp, xfs_dir2_sf_entsize_byname(sfp, args->namelen), XFS_DATA_FORK); /* * Need to set up again due to realloc of the inode data. @@ -403,10 +403,10 @@ xfs_dir2_sf_addname_easy( * Fill in the new entry. */ sfep->namelen = args->namelen; - XFS_DIR2_SF_PUT_OFFSET(sfep, offset); + xfs_dir2_sf_put_offset(sfep, offset); memcpy(sfep->name, args->name, sfep->namelen); - XFS_DIR2_SF_PUT_INUMBER(sfp, &args->inumber, - XFS_DIR2_SF_INUMBERP(sfep)); + xfs_dir2_sf_put_inumber(sfp, &args->inumber, + xfs_dir2_sf_inumberp(sfep)); /* * Update the header and inode. */ @@ -463,14 +463,14 @@ xfs_dir2_sf_addname_hard( * If it's going to end up at the end then oldsfep will point there. */ for (offset = XFS_DIR2_DATA_FIRST_OFFSET, - oldsfep = XFS_DIR2_SF_FIRSTENTRY(oldsfp), - add_datasize = XFS_DIR2_DATA_ENTSIZE(args->namelen), + oldsfep = xfs_dir2_sf_firstentry(oldsfp), + add_datasize = xfs_dir2_data_entsize(args->namelen), eof = (char *)oldsfep == &buf[old_isize]; !eof; - offset = new_offset + XFS_DIR2_DATA_ENTSIZE(oldsfep->namelen), - oldsfep = XFS_DIR2_SF_NEXTENTRY(oldsfp, oldsfep), + offset = new_offset + xfs_dir2_data_entsize(oldsfep->namelen), + oldsfep = xfs_dir2_sf_nextentry(oldsfp, oldsfep), eof = (char *)oldsfep == &buf[old_isize]) { - new_offset = XFS_DIR2_SF_GET_OFFSET(oldsfep); + new_offset = xfs_dir2_sf_get_offset(oldsfep); if (offset + add_datasize <= new_offset) break; } @@ -495,10 +495,10 @@ xfs_dir2_sf_addname_hard( * Fill in the new entry, and update the header counts. */ sfep->namelen = args->namelen; - XFS_DIR2_SF_PUT_OFFSET(sfep, offset); + xfs_dir2_sf_put_offset(sfep, offset); memcpy(sfep->name, args->name, sfep->namelen); - XFS_DIR2_SF_PUT_INUMBER(sfp, &args->inumber, - XFS_DIR2_SF_INUMBERP(sfep)); + xfs_dir2_sf_put_inumber(sfp, &args->inumber, + xfs_dir2_sf_inumberp(sfep)); sfp->hdr.count++; #if XFS_BIG_INUMS if (args->inumber > XFS_DIR2_MAX_SHORT_INUM && !objchange) @@ -508,7 +508,7 @@ xfs_dir2_sf_addname_hard( * If there's more left to copy, do that. */ if (!eof) { - sfep = XFS_DIR2_SF_NEXTENTRY(sfp, sfep); + sfep = xfs_dir2_sf_nextentry(sfp, sfep); memcpy(sfep, oldsfep, old_isize - nbytes); } kmem_free(buf, old_isize); @@ -544,9 +544,9 @@ xfs_dir2_sf_addname_pick( mp = dp->i_mount; sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data; - size = XFS_DIR2_DATA_ENTSIZE(args->namelen); + size = xfs_dir2_data_entsize(args->namelen); offset = XFS_DIR2_DATA_FIRST_OFFSET; - sfep = XFS_DIR2_SF_FIRSTENTRY(sfp); + sfep = xfs_dir2_sf_firstentry(sfp); holefit = 0; /* * Loop over sf entries. @@ -555,10 +555,10 @@ xfs_dir2_sf_addname_pick( */ for (i = 0; i < sfp->hdr.count; i++) { if (!holefit) - holefit = offset + size <= XFS_DIR2_SF_GET_OFFSET(sfep); - offset = XFS_DIR2_SF_GET_OFFSET(sfep) + - XFS_DIR2_DATA_ENTSIZE(sfep->namelen); - sfep = XFS_DIR2_SF_NEXTENTRY(sfp, sfep); + holefit = offset + size <= xfs_dir2_sf_get_offset(sfep); + offset = xfs_dir2_sf_get_offset(sfep) + + xfs_dir2_data_entsize(sfep->namelen); + sfep = xfs_dir2_sf_nextentry(sfp, sfep); } /* * Calculate data bytes used excluding the new entry, if this @@ -617,18 +617,18 @@ xfs_dir2_sf_check( sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data; offset = XFS_DIR2_DATA_FIRST_OFFSET; - ino = XFS_DIR2_SF_GET_INUMBER(sfp, &sfp->hdr.parent); + ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); i8count = ino > XFS_DIR2_MAX_SHORT_INUM; - for (i = 0, sfep = XFS_DIR2_SF_FIRSTENTRY(sfp); + for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); i < sfp->hdr.count; - i++, sfep = XFS_DIR2_SF_NEXTENTRY(sfp, sfep)) { - ASSERT(XFS_DIR2_SF_GET_OFFSET(sfep) >= offset); - ino = XFS_DIR2_SF_GET_INUMBER(sfp, XFS_DIR2_SF_INUMBERP(sfep)); + i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { + ASSERT(xfs_dir2_sf_get_offset(sfep) >= offset); + ino = xfs_dir2_sf_get_inumber(sfp, xfs_dir2_sf_inumberp(sfep)); i8count += ino > XFS_DIR2_MAX_SHORT_INUM; offset = - XFS_DIR2_SF_GET_OFFSET(sfep) + - XFS_DIR2_DATA_ENTSIZE(sfep->namelen); + xfs_dir2_sf_get_offset(sfep) + + xfs_dir2_data_entsize(sfep->namelen); } ASSERT(i8count == sfp->hdr.i8count); ASSERT(XFS_BIG_INUMS || i8count == 0); @@ -671,7 +671,7 @@ xfs_dir2_sf_create( ASSERT(dp->i_df.if_flags & XFS_IFINLINE); ASSERT(dp->i_df.if_bytes == 0); i8count = pino > XFS_DIR2_MAX_SHORT_INUM; - size = XFS_DIR2_SF_HDR_SIZE(i8count); + size = xfs_dir2_sf_hdr_size(i8count); /* * Make a buffer for the data. */ @@ -684,7 +684,7 @@ xfs_dir2_sf_create( /* * Now can put in the inode number, since i8count is set. */ - XFS_DIR2_SF_PUT_INUMBER(sfp, &pino, &sfp->hdr.parent); + xfs_dir2_sf_put_inumber(sfp, &pino, &sfp->hdr.parent); sfp->hdr.count = 0; dp->i_d.di_size = size; xfs_dir2_sf_check(args); @@ -727,12 +727,12 @@ xfs_dir2_sf_getdents( sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data; - ASSERT(dp->i_d.di_size >= XFS_DIR2_SF_HDR_SIZE(sfp->hdr.i8count)); + ASSERT(dp->i_d.di_size >= xfs_dir2_sf_hdr_size(sfp->hdr.i8count)); /* * If the block number in the offset is out of range, we're done. */ - if (XFS_DIR2_DATAPTR_TO_DB(mp, dir_offset) > mp->m_dirdatablk) { + if (xfs_dir2_dataptr_to_db(mp, dir_offset) > mp->m_dirdatablk) { *eofp = 1; return 0; } @@ -747,9 +747,9 @@ xfs_dir2_sf_getdents( * Put . entry unless we're starting past it. */ if (dir_offset <= - XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk, + xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, XFS_DIR2_DATA_DOT_OFFSET)) { - p.cook = XFS_DIR2_DB_OFF_TO_DATAPTR(mp, 0, + p.cook = xfs_dir2_db_off_to_dataptr(mp, 0, XFS_DIR2_DATA_DOTDOT_OFFSET); p.ino = dp->i_ino; #if XFS_BIG_INUMS @@ -762,7 +762,7 @@ xfs_dir2_sf_getdents( if (!p.done) { uio->uio_offset = - XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk, + xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, XFS_DIR2_DATA_DOT_OFFSET); return error; } @@ -772,11 +772,11 @@ xfs_dir2_sf_getdents( * Put .. entry unless we're starting past it. */ if (dir_offset <= - XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk, + xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, XFS_DIR2_DATA_DOTDOT_OFFSET)) { - p.cook = XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk, + p.cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, XFS_DIR2_DATA_FIRST_OFFSET); - p.ino = XFS_DIR2_SF_GET_INUMBER(sfp, &sfp->hdr.parent); + p.ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); #if XFS_BIG_INUMS p.ino += mp->m_inoadd; #endif @@ -787,7 +787,7 @@ xfs_dir2_sf_getdents( if (!p.done) { uio->uio_offset = - XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk, + xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, XFS_DIR2_DATA_DOTDOT_OFFSET); return error; } @@ -796,23 +796,23 @@ xfs_dir2_sf_getdents( /* * Loop while there are more entries and put'ing works. */ - for (i = 0, sfep = XFS_DIR2_SF_FIRSTENTRY(sfp); + for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); i < sfp->hdr.count; - i++, sfep = XFS_DIR2_SF_NEXTENTRY(sfp, sfep)) { + i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { - off = XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk, - XFS_DIR2_SF_GET_OFFSET(sfep)); + off = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, + xfs_dir2_sf_get_offset(sfep)); if (dir_offset > off) continue; p.namelen = sfep->namelen; - p.cook = XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk, - XFS_DIR2_SF_GET_OFFSET(sfep) + - XFS_DIR2_DATA_ENTSIZE(p.namelen)); + p.cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, + xfs_dir2_sf_get_offset(sfep) + + xfs_dir2_data_entsize(p.namelen)); - p.ino = XFS_DIR2_SF_GET_INUMBER(sfp, XFS_DIR2_SF_INUMBERP(sfep)); + p.ino = xfs_dir2_sf_get_inumber(sfp, xfs_dir2_sf_inumberp(sfep)); #if XFS_BIG_INUMS p.ino += mp->m_inoadd; #endif @@ -832,7 +832,7 @@ xfs_dir2_sf_getdents( *eofp = 1; uio->uio_offset = - XFS_DIR2_DB_OFF_TO_DATAPTR(mp, mp->m_dirdatablk + 1, 0); + xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk + 1, 0); return 0; } @@ -865,7 +865,7 @@ xfs_dir2_sf_lookup( ASSERT(dp->i_df.if_bytes == dp->i_d.di_size); ASSERT(dp->i_df.if_u1.if_data != NULL); sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data; - ASSERT(dp->i_d.di_size >= XFS_DIR2_SF_HDR_SIZE(sfp->hdr.i8count)); + ASSERT(dp->i_d.di_size >= xfs_dir2_sf_hdr_size(sfp->hdr.i8count)); /* * Special case for . */ @@ -878,21 +878,21 @@ xfs_dir2_sf_lookup( */ if (args->namelen == 2 && args->name[0] == '.' && args->name[1] == '.') { - args->inumber = XFS_DIR2_SF_GET_INUMBER(sfp, &sfp->hdr.parent); + args->inumber = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); return XFS_ERROR(EEXIST); } /* * Loop over all the entries trying to match ours. */ - for (i = 0, sfep = XFS_DIR2_SF_FIRSTENTRY(sfp); + for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); i < sfp->hdr.count; - i++, sfep = XFS_DIR2_SF_NEXTENTRY(sfp, sfep)) { + i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { if (sfep->namelen == args->namelen && sfep->name[0] == args->name[0] && memcmp(args->name, sfep->name, args->namelen) == 0) { args->inumber = - XFS_DIR2_SF_GET_INUMBER(sfp, - XFS_DIR2_SF_INUMBERP(sfep)); + xfs_dir2_sf_get_inumber(sfp, + xfs_dir2_sf_inumberp(sfep)); return XFS_ERROR(EEXIST); } } @@ -934,19 +934,19 @@ xfs_dir2_sf_removename( ASSERT(dp->i_df.if_bytes == oldsize); ASSERT(dp->i_df.if_u1.if_data != NULL); sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data; - ASSERT(oldsize >= XFS_DIR2_SF_HDR_SIZE(sfp->hdr.i8count)); + ASSERT(oldsize >= xfs_dir2_sf_hdr_size(sfp->hdr.i8count)); /* * Loop over the old directory entries. * Find the one we're deleting. */ - for (i = 0, sfep = XFS_DIR2_SF_FIRSTENTRY(sfp); + for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); i < sfp->hdr.count; - i++, sfep = XFS_DIR2_SF_NEXTENTRY(sfp, sfep)) { + i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { if (sfep->namelen == args->namelen && sfep->name[0] == args->name[0] && memcmp(sfep->name, args->name, args->namelen) == 0) { - ASSERT(XFS_DIR2_SF_GET_INUMBER(sfp, - XFS_DIR2_SF_INUMBERP(sfep)) == + ASSERT(xfs_dir2_sf_get_inumber(sfp, + xfs_dir2_sf_inumberp(sfep)) == args->inumber); break; } @@ -961,7 +961,7 @@ xfs_dir2_sf_removename( * Calculate sizes. */ byteoff = (int)((char *)sfep - (char *)sfp); - entsize = XFS_DIR2_SF_ENTSIZE_BYNAME(sfp, args->namelen); + entsize = xfs_dir2_sf_entsize_byname(sfp, args->namelen); newsize = oldsize - entsize; /* * Copy the part if any after the removed entry, sliding it down. @@ -1027,7 +1027,7 @@ xfs_dir2_sf_replace( ASSERT(dp->i_df.if_bytes == dp->i_d.di_size); ASSERT(dp->i_df.if_u1.if_data != NULL); sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data; - ASSERT(dp->i_d.di_size >= XFS_DIR2_SF_HDR_SIZE(sfp->hdr.i8count)); + ASSERT(dp->i_d.di_size >= xfs_dir2_sf_hdr_size(sfp->hdr.i8count)); #if XFS_BIG_INUMS /* * New inode number is large, and need to convert to 8-byte inodes. @@ -1067,28 +1067,28 @@ xfs_dir2_sf_replace( if (args->namelen == 2 && args->name[0] == '.' && args->name[1] == '.') { #if XFS_BIG_INUMS || defined(DEBUG) - ino = XFS_DIR2_SF_GET_INUMBER(sfp, &sfp->hdr.parent); + ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); ASSERT(args->inumber != ino); #endif - XFS_DIR2_SF_PUT_INUMBER(sfp, &args->inumber, &sfp->hdr.parent); + xfs_dir2_sf_put_inumber(sfp, &args->inumber, &sfp->hdr.parent); } /* * Normal entry, look for the name. */ else { - for (i = 0, sfep = XFS_DIR2_SF_FIRSTENTRY(sfp); + for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); i < sfp->hdr.count; - i++, sfep = XFS_DIR2_SF_NEXTENTRY(sfp, sfep)) { + i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { if (sfep->namelen == args->namelen && sfep->name[0] == args->name[0] && memcmp(args->name, sfep->name, args->namelen) == 0) { #if XFS_BIG_INUMS || defined(DEBUG) - ino = XFS_DIR2_SF_GET_INUMBER(sfp, - XFS_DIR2_SF_INUMBERP(sfep)); + ino = xfs_dir2_sf_get_inumber(sfp, + xfs_dir2_sf_inumberp(sfep)); ASSERT(args->inumber != ino); #endif - XFS_DIR2_SF_PUT_INUMBER(sfp, &args->inumber, - XFS_DIR2_SF_INUMBERP(sfep)); + xfs_dir2_sf_put_inumber(sfp, &args->inumber, + xfs_dir2_sf_inumberp(sfep)); break; } } @@ -1189,22 +1189,22 @@ xfs_dir2_sf_toino4( */ sfp->hdr.count = oldsfp->hdr.count; sfp->hdr.i8count = 0; - ino = XFS_DIR2_SF_GET_INUMBER(oldsfp, &oldsfp->hdr.parent); - XFS_DIR2_SF_PUT_INUMBER(sfp, &ino, &sfp->hdr.parent); + ino = xfs_dir2_sf_get_inumber(oldsfp, &oldsfp->hdr.parent); + xfs_dir2_sf_put_inumber(sfp, &ino, &sfp->hdr.parent); /* * Copy the entries field by field. */ - for (i = 0, sfep = XFS_DIR2_SF_FIRSTENTRY(sfp), - oldsfep = XFS_DIR2_SF_FIRSTENTRY(oldsfp); + for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp), + oldsfep = xfs_dir2_sf_firstentry(oldsfp); i < sfp->hdr.count; - i++, sfep = XFS_DIR2_SF_NEXTENTRY(sfp, sfep), - oldsfep = XFS_DIR2_SF_NEXTENTRY(oldsfp, oldsfep)) { + i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep), + oldsfep = xfs_dir2_sf_nextentry(oldsfp, oldsfep)) { sfep->namelen = oldsfep->namelen; sfep->offset = oldsfep->offset; memcpy(sfep->name, oldsfep->name, sfep->namelen); - ino = XFS_DIR2_SF_GET_INUMBER(oldsfp, - XFS_DIR2_SF_INUMBERP(oldsfep)); - XFS_DIR2_SF_PUT_INUMBER(sfp, &ino, XFS_DIR2_SF_INUMBERP(sfep)); + ino = xfs_dir2_sf_get_inumber(oldsfp, + xfs_dir2_sf_inumberp(oldsfep)); + xfs_dir2_sf_put_inumber(sfp, &ino, xfs_dir2_sf_inumberp(sfep)); } /* * Clean up the inode. @@ -1266,22 +1266,22 @@ xfs_dir2_sf_toino8( */ sfp->hdr.count = oldsfp->hdr.count; sfp->hdr.i8count = 1; - ino = XFS_DIR2_SF_GET_INUMBER(oldsfp, &oldsfp->hdr.parent); - XFS_DIR2_SF_PUT_INUMBER(sfp, &ino, &sfp->hdr.parent); + ino = xfs_dir2_sf_get_inumber(oldsfp, &oldsfp->hdr.parent); + xfs_dir2_sf_put_inumber(sfp, &ino, &sfp->hdr.parent); /* * Copy the entries field by field. */ - for (i = 0, sfep = XFS_DIR2_SF_FIRSTENTRY(sfp), - oldsfep = XFS_DIR2_SF_FIRSTENTRY(oldsfp); + for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp), + oldsfep = xfs_dir2_sf_firstentry(oldsfp); i < sfp->hdr.count; - i++, sfep = XFS_DIR2_SF_NEXTENTRY(sfp, sfep), - oldsfep = XFS_DIR2_SF_NEXTENTRY(oldsfp, oldsfep)) { + i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep), + oldsfep = xfs_dir2_sf_nextentry(oldsfp, oldsfep)) { sfep->namelen = oldsfep->namelen; sfep->offset = oldsfep->offset; memcpy(sfep->name, oldsfep->name, sfep->namelen); - ino = XFS_DIR2_SF_GET_INUMBER(oldsfp, - XFS_DIR2_SF_INUMBERP(oldsfep)); - XFS_DIR2_SF_PUT_INUMBER(sfp, &ino, XFS_DIR2_SF_INUMBERP(sfep)); + ino = xfs_dir2_sf_get_inumber(oldsfp, + xfs_dir2_sf_inumberp(oldsfep)); + xfs_dir2_sf_put_inumber(sfp, &ino, xfs_dir2_sf_inumberp(sfep)); } /* * Clean up the inode. Index: linux-2.6/fs/xfs/xfs_dir2_sf.h =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_sf.h 2007-04-28 09:37:26.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_sf.h 2007-05-12 13:38:34.000000000 +0200 @@ -90,7 +90,6 @@ typedef struct xfs_dir2_sf { xfs_dir2_sf_entry_t list[1]; /* shortform entries */ } xfs_dir2_sf_t; -#define XFS_DIR2_SF_HDR_SIZE(i8count) xfs_dir2_sf_hdr_size(i8count) static inline int xfs_dir2_sf_hdr_size(int i8count) { return ((uint)sizeof(xfs_dir2_sf_hdr_t) - \ @@ -98,14 +97,11 @@ static inline int xfs_dir2_sf_hdr_size(i ((uint)sizeof(xfs_dir2_ino8_t) - (uint)sizeof(xfs_dir2_ino4_t))); } -#define XFS_DIR2_SF_INUMBERP(sfep) xfs_dir2_sf_inumberp(sfep) static inline xfs_dir2_inou_t *xfs_dir2_sf_inumberp(xfs_dir2_sf_entry_t *sfep) { return (xfs_dir2_inou_t *)&(sfep)->name[(sfep)->namelen]; } -#define XFS_DIR2_SF_GET_INUMBER(sfp, from) \ - xfs_dir2_sf_get_inumber(sfp, from) static inline xfs_intino_t xfs_dir2_sf_get_inumber(xfs_dir2_sf_t *sfp, xfs_dir2_inou_t *from) { @@ -114,8 +110,6 @@ xfs_dir2_sf_get_inumber(xfs_dir2_sf_t *s (xfs_intino_t)XFS_GET_DIR_INO8((from)->i8)); } -#define XFS_DIR2_SF_PUT_INUMBER(sfp,from,to) \ - xfs_dir2_sf_put_inumber(sfp,from,to) static inline void xfs_dir2_sf_put_inumber(xfs_dir2_sf_t *sfp, xfs_ino_t *from, xfs_dir2_inou_t *to) { @@ -125,24 +119,18 @@ static inline void xfs_dir2_sf_put_inumb XFS_PUT_DIR_INO8(*(from), (to)->i8); } -#define XFS_DIR2_SF_GET_OFFSET(sfep) \ - xfs_dir2_sf_get_offset(sfep) static inline xfs_dir2_data_aoff_t xfs_dir2_sf_get_offset(xfs_dir2_sf_entry_t *sfep) { return INT_GET_UNALIGNED_16_BE(&(sfep)->offset.i); } -#define XFS_DIR2_SF_PUT_OFFSET(sfep,off) \ - xfs_dir2_sf_put_offset(sfep,off) static inline void xfs_dir2_sf_put_offset(xfs_dir2_sf_entry_t *sfep, xfs_dir2_data_aoff_t off) { INT_SET_UNALIGNED_16_BE(&(sfep)->offset.i, off); } -#define XFS_DIR2_SF_ENTSIZE_BYNAME(sfp,len) \ - xfs_dir2_sf_entsize_byname(sfp,len) static inline int xfs_dir2_sf_entsize_byname(xfs_dir2_sf_t *sfp, int len) { return ((uint)sizeof(xfs_dir2_sf_entry_t) - 1 + (len) - \ @@ -150,8 +138,6 @@ static inline int xfs_dir2_sf_entsize_by ((uint)sizeof(xfs_dir2_ino8_t) - (uint)sizeof(xfs_dir2_ino4_t))); } -#define XFS_DIR2_SF_ENTSIZE_BYENTRY(sfp,sfep) \ - xfs_dir2_sf_entsize_byentry(sfp,sfep) static inline int xfs_dir2_sf_entsize_byentry(xfs_dir2_sf_t *sfp, xfs_dir2_sf_entry_t *sfep) { @@ -160,19 +146,17 @@ xfs_dir2_sf_entsize_byentry(xfs_dir2_sf_ ((uint)sizeof(xfs_dir2_ino8_t) - (uint)sizeof(xfs_dir2_ino4_t))); } -#define XFS_DIR2_SF_FIRSTENTRY(sfp) xfs_dir2_sf_firstentry(sfp) static inline xfs_dir2_sf_entry_t *xfs_dir2_sf_firstentry(xfs_dir2_sf_t *sfp) { return ((xfs_dir2_sf_entry_t *) \ - ((char *)(sfp) + XFS_DIR2_SF_HDR_SIZE(sfp->hdr.i8count))); + ((char *)(sfp) + xfs_dir2_sf_hdr_size(sfp->hdr.i8count))); } -#define XFS_DIR2_SF_NEXTENTRY(sfp,sfep) xfs_dir2_sf_nextentry(sfp,sfep) static inline xfs_dir2_sf_entry_t * xfs_dir2_sf_nextentry(xfs_dir2_sf_t *sfp, xfs_dir2_sf_entry_t *sfep) { return ((xfs_dir2_sf_entry_t *) \ - ((char *)(sfep) + XFS_DIR2_SF_ENTSIZE_BYENTRY(sfp,sfep))); + ((char *)(sfep) + xfs_dir2_sf_entsize_byentry(sfp,sfep))); } /* From owner-xfs@oss.sgi.com Mon Jun 4 07:40:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 07:40:08 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54EdxWt019371 for ; Mon, 4 Jun 2007 07:40:00 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l54Edwo6009368 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 4 Jun 2007 16:39:58 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l54EdwoT009366 for xfs@oss.sgi.com; Mon, 4 Jun 2007 16:39:58 +0200 Date: Mon, 4 Jun 2007 16:39:58 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] use filldir internally Message-ID: <20070604143958.GB9081@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 11621 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Currently xfs has a rather complicated internal scheme to allow for different directory formats in IRIX. This patch rips all code related to this out and pushes useage of the Linux filldir callback into the lowlevel directory code. This does not make the code any less portable because filldir can be used to create dirents of all possible variations (including the IRIX ones as proved by the IRIX binary emulation code under arch/mips/). This patch get rid of an unessecary copy in the readdir path, about 250 lines of code and one of the last two users of the uio structure. Signed-off-by: Christoph Hellwig Index: linux-2.6/fs/xfs/linux-2.6/xfs_file.c =================================================================== --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_file.c 2007-05-19 00:22:40.000000000 +0200 +++ linux-2.6/fs/xfs/linux-2.6/xfs_file.c 2007-06-01 13:17:15.000000000 +0200 @@ -267,74 +267,29 @@ xfs_file_readdir( void *dirent, filldir_t filldir) { - int error = 0; - bhv_vnode_t *vp = vn_from_inode(filp->f_path.dentry->d_inode); - uio_t uio; - iovec_t iov; - int eof = 0; - caddr_t read_buf; - int namelen, size = 0; - size_t rlen = PAGE_CACHE_SIZE; - xfs_off_t start_offset, curr_offset; - xfs_dirent_t *dbp = NULL; - - /* Try fairly hard to get memory */ - do { - if ((read_buf = kmalloc(rlen, GFP_KERNEL))) - break; - rlen >>= 1; - } while (rlen >= 1024); - - if (read_buf == NULL) - return -ENOMEM; - - uio.uio_iov = &iov; - uio.uio_segflg = UIO_SYSSPACE; - curr_offset = filp->f_pos; - if (filp->f_pos != 0x7fffffff) - uio.uio_offset = filp->f_pos; - else - uio.uio_offset = 0xffffffff; - - while (!eof) { - uio.uio_resid = iov.iov_len = rlen; - iov.iov_base = read_buf; - uio.uio_iovcnt = 1; - - start_offset = uio.uio_offset; - - error = bhv_vop_readdir(vp, &uio, NULL, &eof); - if ((uio.uio_offset == start_offset) || error) { - size = 0; - break; - } - - size = rlen - uio.uio_resid; - dbp = (xfs_dirent_t *)read_buf; - while (size > 0) { - namelen = strlen(dbp->d_name); - - if (filldir(dirent, dbp->d_name, namelen, - (loff_t) curr_offset & 0x7fffffff, - (ino_t) dbp->d_ino, - DT_UNKNOWN)) { - goto done; - } - size -= dbp->d_reclen; - curr_offset = (loff_t)dbp->d_off /* & 0x7fffffff */; - dbp = (xfs_dirent_t *)((char *)dbp + dbp->d_reclen); - } - } -done: - if (!error) { - if (size == 0) - filp->f_pos = uio.uio_offset & 0x7fffffff; - else if (dbp) - filp->f_pos = curr_offset; - } + struct inode *inode = filp->f_path.dentry->d_inode; + bhv_vnode_t *vp = vn_from_inode(inode); + int error; + size_t bufsize; + + /* + * The Linux API doesn't pass down the total size of the buffer + * we read into down to the filesystem. With the filldir concept + * it's not needed for correct information, but the XFS dir2 leaf + * code wants an estimate of the buffer size to calculate it's + * readahead window and size the buffers used for mapping to + * physical blocks. + * + * Try to give it an estimate that's good enough, maybe at some + * point we can change the ->readdir prototype to include the + * buffer size. + */ + bufsize = (size_t)min_t(loff_t, PAGE_SIZE, inode->i_size); - kfree(read_buf); - return -error; + error = bhv_vop_readdir(vp, dirent, bufsize, &filp->f_pos, filldir); + if (error) + return -error; + return 0; } STATIC int Index: linux-2.6/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_vnode.h 2007-05-19 00:22:40.000000000 +0200 +++ linux-2.6/fs/xfs/linux-2.6/xfs_vnode.h 2007-06-01 13:17:15.000000000 +0200 @@ -167,8 +167,8 @@ typedef int (*vop_rename_t)(bhv_desc_t * typedef int (*vop_mkdir_t)(bhv_desc_t *, bhv_vname_t *, struct bhv_vattr *, bhv_vnode_t **, struct cred *); typedef int (*vop_rmdir_t)(bhv_desc_t *, bhv_vname_t *, struct cred *); -typedef int (*vop_readdir_t)(bhv_desc_t *, struct uio *, struct cred *, - int *); +typedef int (*vop_readdir_t)(bhv_desc_t *, void *dirent, size_t bufsize, + xfs_off_t *offset, filldir_t filldir); typedef int (*vop_symlink_t)(bhv_desc_t *, bhv_vname_t *, struct bhv_vattr*, char *, bhv_vnode_t **, struct cred *); typedef int (*vop_readlink_t)(bhv_desc_t *, struct uio *, int, @@ -278,8 +278,8 @@ typedef struct bhv_vnodeops { #define bhv_vop_mkdir(dp,d,vap,vpp,cr) \ VOP(vop_mkdir, dp)(VNHEAD(dp),d,vap,vpp,cr) #define bhv_vop_rmdir(dp,d,cr) VOP(vop_rmdir, dp)(VNHEAD(dp),d,cr) -#define bhv_vop_readdir(vp,uiop,cr,eofp) \ - VOP(vop_readdir, vp)(VNHEAD(vp),uiop,cr,eofp) +#define bhv_vop_readdir(vp,dirent,bufsize,offset,filldir) \ + VOP(vop_readdir, vp)(VNHEAD(vp),dirent,bufsize,offset,filldir) #define bhv_vop_symlink(dvp,d,vap,tnm,vpp,cr) \ VOP(vop_symlink, dvp)(VNHEAD(dvp),d,vap,tnm,vpp,cr) #define bhv_vop_readlink(vp,uiop,fl,cr) \ Index: linux-2.6/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_vnodeops.c 2007-05-21 16:15:11.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_vnodeops.c 2007-06-01 13:17:15.000000000 +0200 @@ -3247,37 +3247,6 @@ xfs_rmdir( goto std_return; } - -/* - * Read dp's entries starting at uiop->uio_offset and translate them into - * bufsize bytes worth of struct dirents starting at bufbase. - */ -STATIC int -xfs_readdir( - bhv_desc_t *dir_bdp, - uio_t *uiop, - cred_t *credp, - int *eofp) -{ - xfs_inode_t *dp; - xfs_trans_t *tp = NULL; - int error = 0; - uint lock_mode; - - vn_trace_entry(BHV_TO_VNODE(dir_bdp), __FUNCTION__, - (inst_t *)__return_address); - dp = XFS_BHVTOI(dir_bdp); - - if (XFS_FORCED_SHUTDOWN(dp->i_mount)) - return XFS_ERROR(EIO); - - lock_mode = xfs_ilock_map_shared(dp); - error = xfs_dir_getdents(tp, dp, uiop, eofp); - xfs_iunlock_map_shared(dp, lock_mode); - return error; -} - - STATIC int xfs_symlink( bhv_desc_t *dir_bdp, Index: linux-2.6/fs/xfs/xfs_dir2.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2.c 2007-06-01 13:17:03.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2.c 2007-06-01 13:17:15.000000000 +0200 @@ -43,8 +43,6 @@ #include "xfs_dir2_trace.h" #include "xfs_error.h" -static int xfs_dir2_put_dirent64_direct(xfs_dir2_put_args_t *pa); -static int xfs_dir2_put_dirent64_uio(xfs_dir2_put_args_t *pa); void xfs_dir_mount( @@ -293,47 +291,35 @@ xfs_dir_removename( * Read a directory. */ int -xfs_dir_getdents( - xfs_trans_t *tp, - xfs_inode_t *dp, - uio_t *uio, /* caller's buffer control */ - int *eofp) /* out: eof reached */ +xfs_readdir( + bhv_desc_t *dir_bdp, + void *dirent, + size_t bufsize, + xfs_off_t *offset, + filldir_t filldir) { - int alignment; /* alignment required for ABI */ - xfs_dirent_t *dbp; /* malloc'ed buffer */ - xfs_dir2_put_t put; /* entry formatting routine */ + xfs_inode_t *dp = XFS_BHVTOI(dir_bdp); int rval; /* return value */ int v; /* type-checking value */ + vn_trace_entry(BHV_TO_VNODE(dir_bdp), __FUNCTION__, + (inst_t *)__return_address); + + if (XFS_FORCED_SHUTDOWN(dp->i_mount)) + return XFS_ERROR(EIO); + ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); XFS_STATS_INC(xs_dir_getdents); - /* - * If our caller has given us a single contiguous aligned memory buffer, - * just work directly within that buffer. If it's in user memory, - * lock it down first. - */ - alignment = sizeof(xfs_off_t) - 1; - if ((uio->uio_iovcnt == 1) && - (((__psint_t)uio->uio_iov[0].iov_base & alignment) == 0) && - ((uio->uio_iov[0].iov_len & alignment) == 0)) { - dbp = NULL; - put = xfs_dir2_put_dirent64_direct; - } else { - dbp = kmem_alloc(sizeof(*dbp) + MAXNAMELEN, KM_SLEEP); - put = xfs_dir2_put_dirent64_uio; - } - *eofp = 0; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) - rval = xfs_dir2_sf_getdents(dp, uio, eofp, dbp, put); - else if ((rval = xfs_dir2_isblock(tp, dp, &v))) + rval = xfs_dir2_sf_getdents(dp, dirent, offset, filldir); + else if ((rval = xfs_dir2_isblock(NULL, dp, &v))) ; else if (v) - rval = xfs_dir2_block_getdents(tp, dp, uio, eofp, dbp, put); + rval = xfs_dir2_block_getdents(dp, dirent, offset, filldir); else - rval = xfs_dir2_leaf_getdents(tp, dp, uio, eofp, dbp, put); - if (dbp != NULL) - kmem_free(dbp, sizeof(*dbp) + MAXNAMELEN); + rval = xfs_dir2_leaf_getdents(dp, dirent, bufsize, offset, + filldir); return rval; } @@ -613,77 +599,6 @@ xfs_dir2_isleaf( } /* - * Getdents put routine for 64-bit ABI, direct form. - */ -static int -xfs_dir2_put_dirent64_direct( - xfs_dir2_put_args_t *pa) -{ - xfs_dirent_t *idbp; /* dirent pointer */ - iovec_t *iovp; /* io vector */ - int namelen; /* entry name length */ - int reclen; /* entry total length */ - uio_t *uio; /* I/O control */ - - namelen = pa->namelen; - reclen = DIRENTSIZE(namelen); - uio = pa->uio; - /* - * Won't fit in the remaining space. - */ - if (reclen > uio->uio_resid) { - pa->done = 0; - return 0; - } - iovp = uio->uio_iov; - idbp = (xfs_dirent_t *)iovp->iov_base; - iovp->iov_base = (char *)idbp + reclen; - iovp->iov_len -= reclen; - uio->uio_resid -= reclen; - idbp->d_reclen = reclen; - idbp->d_ino = pa->ino; - idbp->d_off = pa->cook; - idbp->d_name[namelen] = '\0'; - pa->done = 1; - memcpy(idbp->d_name, pa->name, namelen); - return 0; -} - -/* - * Getdents put routine for 64-bit ABI, uio form. - */ -static int -xfs_dir2_put_dirent64_uio( - xfs_dir2_put_args_t *pa) -{ - xfs_dirent_t *idbp; /* dirent pointer */ - int namelen; /* entry name length */ - int reclen; /* entry total length */ - int rval; /* return value */ - uio_t *uio; /* I/O control */ - - namelen = pa->namelen; - reclen = DIRENTSIZE(namelen); - uio = pa->uio; - /* - * Won't fit in the remaining space. - */ - if (reclen > uio->uio_resid) { - pa->done = 0; - return 0; - } - idbp = pa->dbp; - idbp->d_reclen = reclen; - idbp->d_ino = pa->ino; - idbp->d_off = pa->cook; - idbp->d_name[namelen] = '\0'; - memcpy(idbp->d_name, pa->name, namelen); - rval = xfs_uio_read((caddr_t)idbp, reclen, uio); - pa->done = (rval == 0); - return rval; -} - -/* * Remove the given block from the directory. * This routine is used for data and free blocks, leaf/node are done * by xfs_da_shrink_inode. Index: linux-2.6/fs/xfs/xfs_dir2.h =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2.h 2007-05-12 15:16:05.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2.h 2007-06-01 13:17:15.000000000 +0200 @@ -60,21 +60,6 @@ typedef __uint32_t xfs_dir2_db_t; typedef xfs_off_t xfs_dir2_off_t; /* - * For getdents, argument struct for put routines. - */ -typedef int (*xfs_dir2_put_t)(struct xfs_dir2_put_args *pa); -typedef struct xfs_dir2_put_args { - xfs_off_t cook; /* cookie of (next) entry */ - xfs_intino_t ino; /* inode number */ - xfs_dirent_t *dbp; /* buffer pointer */ - char *name; /* directory entry name */ - int namelen; /* length of name */ - int done; /* output: set if value was stored */ - xfs_dir2_put_t put; /* put function ptr (i/o) */ - struct uio *uio; /* uio control structure */ -} xfs_dir2_put_args_t; - -/* * Generic directory interface routines */ extern void xfs_dir_startup(void); @@ -92,8 +77,6 @@ extern int xfs_dir_removename(struct xfs char *name, int namelen, xfs_ino_t ino, xfs_fsblock_t *first, struct xfs_bmap_free *flist, xfs_extlen_t tot); -extern int xfs_dir_getdents(struct xfs_trans *tp, struct xfs_inode *dp, - uio_t *uio, int *eofp); extern int xfs_dir_replace(struct xfs_trans *tp, struct xfs_inode *dp, char *name, int namelen, xfs_ino_t inum, xfs_fsblock_t *first, @@ -101,6 +84,8 @@ extern int xfs_dir_replace(struct xfs_tr extern int xfs_dir_canenter(struct xfs_trans *tp, struct xfs_inode *dp, char *name, int namelen); extern int xfs_dir_ino_validate(struct xfs_mount *mp, xfs_ino_t ino); +extern int xfs_readdir(bhv_desc_t *dir_bdp, void *dirent, size_t bufsize, + xfs_off_t *offset, filldir_t filldir); /* * Utility routines for v2 directories. Index: linux-2.6/fs/xfs/xfs_dir2_block.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_block.c 2007-06-01 13:17:03.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_block.c 2007-06-01 13:17:15.000000000 +0200 @@ -432,12 +432,10 @@ xfs_dir2_block_addname( */ int /* error */ xfs_dir2_block_getdents( - xfs_trans_t *tp, /* transaction (NULL) */ xfs_inode_t *dp, /* incore inode */ - uio_t *uio, /* caller's buffer control */ - int *eofp, /* eof reached? (out) */ - xfs_dirent_t *dbp, /* caller's buffer */ - xfs_dir2_put_t put) /* abi's formatting function */ + void *dirent, + xfs_off_t *offset, + filldir_t filldir) { xfs_dir2_block_t *block; /* directory block structure */ xfs_dabuf_t *bp; /* buffer for block */ @@ -447,31 +445,32 @@ xfs_dir2_block_getdents( char *endptr; /* end of the data entries */ int error; /* error return value */ xfs_mount_t *mp; /* filesystem mount point */ - xfs_dir2_put_args_t p; /* arg package for put rtn */ char *ptr; /* current data entry */ int wantoff; /* starting block offset */ + xfs_ino_t ino; + xfs_off_t cook; mp = dp->i_mount; /* * If the block number in the offset is out of range, we're done. */ - if (xfs_dir2_dataptr_to_db(mp, uio->uio_offset) > mp->m_dirdatablk) { - *eofp = 1; + if (xfs_dir2_dataptr_to_db(mp, *offset) > mp->m_dirdatablk) { return 0; } /* * Can't read the block, give up, else get dabuf in bp. */ - if ((error = - xfs_da_read_buf(tp, dp, mp->m_dirdatablk, -1, &bp, XFS_DATA_FORK))) { + error = xfs_da_read_buf(NULL, dp, mp->m_dirdatablk, -1, + &bp, XFS_DATA_FORK); + if (error) return error; - } + ASSERT(bp != NULL); /* * Extract the byte offset we start at from the seek pointer. * We'll skip entries before this. */ - wantoff = xfs_dir2_dataptr_to_off(mp, uio->uio_offset); + wantoff = xfs_dir2_dataptr_to_off(mp, *offset); block = bp->data; xfs_dir2_data_check(dp, bp); /* @@ -480,9 +479,7 @@ xfs_dir2_block_getdents( btp = xfs_dir2_block_tail_p(mp, block); ptr = (char *)block->u; endptr = (char *)xfs_dir2_block_leaf_p(btp); - p.dbp = dbp; - p.put = put; - p.uio = uio; + /* * Loop over the data portion of the block. * Each object is a real entry (dep) or an unused one (dup). @@ -508,33 +505,24 @@ xfs_dir2_block_getdents( */ if ((char *)dep - (char *)block < wantoff) continue; - /* - * Set up argument structure for put routine. - */ - p.namelen = dep->namelen; - p.cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, + cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, ptr - (char *)block); - p.ino = be64_to_cpu(dep->inumber); + ino = be64_to_cpu(dep->inumber); #if XFS_BIG_INUMS - p.ino += mp->m_inoadd; + ino += mp->m_inoadd; #endif - p.name = (char *)dep->name; - - /* - * Put the entry in the caller's buffer. - */ - error = p.put(&p); /* * If it didn't fit, set the final offset to here & return. */ - if (!p.done) { - uio->uio_offset = - xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, + if (filldir(dirent, dep->name, dep->namelen, cook, + ino, DT_UNKNOWN)) { + *offset = xfs_dir2_db_off_to_dataptr(mp, + mp->m_dirdatablk, (char *)dep - (char *)block); - xfs_da_brelse(tp, bp); - return error; + xfs_da_brelse(NULL, bp); + return 0; } } @@ -542,13 +530,8 @@ xfs_dir2_block_getdents( * Reached the end of the block. * Set the offset to a non-existent block 1 and return. */ - *eofp = 1; - - uio->uio_offset = - xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk + 1, 0); - - xfs_da_brelse(tp, bp); - + *offset = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk + 1, 0); + xfs_da_brelse(NULL, bp); return 0; } Index: linux-2.6/fs/xfs/xfs_dir2_block.h =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_block.h 2007-06-01 13:17:03.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_block.h 2007-06-01 13:17:15.000000000 +0200 @@ -80,9 +80,8 @@ xfs_dir2_block_leaf_p(xfs_dir2_block_tai * Function declarations. */ extern int xfs_dir2_block_addname(struct xfs_da_args *args); -extern int xfs_dir2_block_getdents(struct xfs_trans *tp, struct xfs_inode *dp, - struct uio *uio, int *eofp, - struct xfs_dirent *dbp, xfs_dir2_put_t put); +extern int xfs_dir2_block_getdents(struct xfs_inode *dp, void *dirent, + xfs_off_t *offset, filldir_t filldir); extern int xfs_dir2_block_lookup(struct xfs_da_args *args); extern int xfs_dir2_block_removename(struct xfs_da_args *args); extern int xfs_dir2_block_replace(struct xfs_da_args *args); Index: linux-2.6/fs/xfs/xfs_dir2_leaf.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_leaf.c 2007-06-01 13:17:03.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_leaf.c 2007-06-01 13:17:15.000000000 +0200 @@ -749,12 +749,11 @@ xfs_dir2_leaf_compact_x1( */ int /* error */ xfs_dir2_leaf_getdents( - xfs_trans_t *tp, /* transaction pointer */ xfs_inode_t *dp, /* incore directory inode */ - uio_t *uio, /* I/O control & vectors */ - int *eofp, /* out: reached end of dir */ - xfs_dirent_t *dbp, /* caller's buffer */ - xfs_dir2_put_t put) /* ABI formatting routine */ + void *dirent, + size_t bufsize, + xfs_off_t *offset, + filldir_t filldir) { xfs_dabuf_t *bp; /* data block buffer */ int byteoff; /* offset in current block */ @@ -763,7 +762,6 @@ xfs_dir2_leaf_getdents( xfs_dir2_data_t *data; /* data block structure */ xfs_dir2_data_entry_t *dep; /* data entry */ xfs_dir2_data_unused_t *dup; /* unused entry */ - int eof; /* reached end of directory */ int error = 0; /* error return value */ int i; /* temporary loop index */ int j; /* temporary loop index */ @@ -776,46 +774,38 @@ xfs_dir2_leaf_getdents( xfs_mount_t *mp; /* filesystem mount point */ xfs_dir2_off_t newoff; /* new curoff after new blk */ int nmap; /* mappings to ask xfs_bmapi */ - xfs_dir2_put_args_t *p; /* formatting arg bundle */ char *ptr = NULL; /* pointer to current data */ int ra_current; /* number of read-ahead blks */ int ra_index; /* *map index for read-ahead */ int ra_offset; /* map entry offset for ra */ int ra_want; /* readahead count wanted */ + xfs_ino_t ino; /* * If the offset is at or past the largest allowed value, - * give up right away, return eof. + * give up right away. */ - if (uio->uio_offset >= XFS_DIR2_MAX_DATAPTR) { - *eofp = 1; + if (*offset >= XFS_DIR2_MAX_DATAPTR) return 0; - } + mp = dp->i_mount; - /* - * Setup formatting arguments. - */ - p = kmem_alloc(sizeof(*p), KM_SLEEP); - p->dbp = dbp; - p->put = put; - p->uio = uio; + /* * Set up to bmap a number of blocks based on the caller's * buffer size, the directory block size, and the filesystem * block size. */ - map_size = - howmany(uio->uio_resid + mp->m_dirblksize, - mp->m_sb.sb_blocksize); + map_size = howmany(bufsize + mp->m_dirblksize, mp->m_sb.sb_blocksize); map = kmem_alloc(map_size * sizeof(*map), KM_SLEEP); map_valid = ra_index = ra_offset = ra_current = map_blocks = 0; bp = NULL; - eof = 1; + /* * Inside the loop we keep the main offset value as a byte offset * in the directory file. */ - curoff = xfs_dir2_dataptr_to_byte(mp, uio->uio_offset); + curoff = xfs_dir2_dataptr_to_byte(mp, *offset); + /* * Force this conversion through db so we truncate the offset * down to get the start of the data block. @@ -836,7 +826,7 @@ xfs_dir2_leaf_getdents( * take it out of the mapping. */ if (bp) { - xfs_da_brelse(tp, bp); + xfs_da_brelse(NULL, bp); bp = NULL; map_blocks -= mp->m_dirblkfsbs; /* @@ -862,8 +852,9 @@ xfs_dir2_leaf_getdents( /* * Recalculate the readahead blocks wanted. */ - ra_want = howmany(uio->uio_resid + mp->m_dirblksize, + ra_want = howmany(bufsize + mp->m_dirblksize, mp->m_sb.sb_blocksize) - 1; + /* * If we don't have as many as we want, and we haven't * run out of data blocks, get some more mappings. @@ -876,7 +867,7 @@ xfs_dir2_leaf_getdents( * we already have in the table. */ nmap = map_size - map_valid; - error = xfs_bmapi(tp, dp, + error = xfs_bmapi(NULL, dp, map_off, xfs_dir2_byte_to_da(mp, XFS_DIR2_LEAF_OFFSET) - map_off, @@ -939,7 +930,7 @@ xfs_dir2_leaf_getdents( * mapping. */ curdb = xfs_dir2_da_to_db(mp, map->br_startoff); - error = xfs_da_read_buf(tp, dp, map->br_startoff, + error = xfs_da_read_buf(NULL, dp, map->br_startoff, map->br_blockcount >= mp->m_dirblkfsbs ? XFS_FSB_TO_DADDR(mp, map->br_startblock) : -1, @@ -982,7 +973,7 @@ xfs_dir2_leaf_getdents( * is a very rare case. */ else if (i > ra_current) { - (void)xfs_da_reada_buf(tp, dp, + (void)xfs_da_reada_buf(NULL, dp, map[ra_index].br_startoff + ra_offset, XFS_DATA_FORK); ra_current = i; @@ -1089,46 +1080,39 @@ xfs_dir2_leaf_getdents( */ dep = (xfs_dir2_data_entry_t *)ptr; - p->namelen = dep->namelen; - - length = xfs_dir2_data_entsize(p->namelen); - - p->cook = xfs_dir2_byte_to_dataptr(mp, curoff + length); + length = xfs_dir2_data_entsize(dep->namelen); - p->ino = be64_to_cpu(dep->inumber); + ino = be64_to_cpu(dep->inumber); #if XFS_BIG_INUMS - p->ino += mp->m_inoadd; + ino += mp->m_inoadd; #endif - p->name = (char *)dep->name; - - error = p->put(p); /* * Won't fit. Return to caller. */ - if (!p->done) { - eof = 0; + if (filldir(dirent, dep->name, dep->namelen, + xfs_dir2_byte_to_dataptr(mp, curoff + length), + ino, DT_UNKNOWN)) break; - } + /* * Advance to next entry in the block. */ ptr += length; curoff += length; + bufsize -= length; } /* * All done. Set output offset value to current offset. */ - *eofp = eof; if (curoff > xfs_dir2_dataptr_to_byte(mp, XFS_DIR2_MAX_DATAPTR)) - uio->uio_offset = XFS_DIR2_MAX_DATAPTR; + *offset = XFS_DIR2_MAX_DATAPTR; else - uio->uio_offset = xfs_dir2_byte_to_dataptr(mp, curoff); + *offset = xfs_dir2_byte_to_dataptr(mp, curoff); kmem_free(map, map_size * sizeof(*map)); - kmem_free(p, sizeof(*p)); if (bp) - xfs_da_brelse(tp, bp); + xfs_da_brelse(NULL, bp); return error; } Index: linux-2.6/fs/xfs/xfs_dir2_leaf.h =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_leaf.h 2007-06-01 13:17:03.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_leaf.h 2007-06-01 13:17:15.000000000 +0200 @@ -232,9 +232,9 @@ extern void xfs_dir2_leaf_compact(struct extern void xfs_dir2_leaf_compact_x1(struct xfs_dabuf *bp, int *indexp, int *lowstalep, int *highstalep, int *lowlogp, int *highlogp); -extern int xfs_dir2_leaf_getdents(struct xfs_trans *tp, struct xfs_inode *dp, - struct uio *uio, int *eofp, - struct xfs_dirent *dbp, xfs_dir2_put_t put); +extern int xfs_dir2_leaf_getdents(struct xfs_inode *dp, void *dirent, + size_t bufsize, xfs_off_t *offset, + filldir_t filldir); extern int xfs_dir2_leaf_init(struct xfs_da_args *args, xfs_dir2_db_t bno, struct xfs_dabuf **bpp, int magic); extern void xfs_dir2_leaf_log_ents(struct xfs_trans *tp, struct xfs_dabuf *bp, Index: linux-2.6/fs/xfs/xfs_dir2_sf.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_sf.c 2007-06-01 13:17:03.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_sf.c 2007-06-01 13:17:15.000000000 +0200 @@ -695,19 +695,18 @@ xfs_dir2_sf_create( int /* error */ xfs_dir2_sf_getdents( xfs_inode_t *dp, /* incore directory inode */ - uio_t *uio, /* caller's buffer control */ - int *eofp, /* eof reached? (out) */ - xfs_dirent_t *dbp, /* caller's buffer */ - xfs_dir2_put_t put) /* abi's formatting function */ + void *dirent, + xfs_off_t *offset, + filldir_t filldir) { - int error; /* error return value */ int i; /* shortform entry number */ xfs_mount_t *mp; /* filesystem mount point */ xfs_dir2_dataptr_t off; /* current entry's offset */ - xfs_dir2_put_args_t p; /* arg package for put rtn */ xfs_dir2_sf_entry_t *sfep; /* shortform directory entry */ xfs_dir2_sf_t *sfp; /* shortform structure */ - xfs_off_t dir_offset; + xfs_dir2_dataptr_t dot_offset; + xfs_dir2_dataptr_t dotdot_offset; + xfs_ino_t ino; mp = dp->i_mount; @@ -720,8 +719,6 @@ xfs_dir2_sf_getdents( return XFS_ERROR(EIO); } - dir_offset = uio->uio_offset; - ASSERT(dp->i_df.if_bytes == dp->i_d.di_size); ASSERT(dp->i_df.if_u1.if_data != NULL); @@ -732,108 +729,78 @@ xfs_dir2_sf_getdents( /* * If the block number in the offset is out of range, we're done. */ - if (xfs_dir2_dataptr_to_db(mp, dir_offset) > mp->m_dirdatablk) { - *eofp = 1; + if (xfs_dir2_dataptr_to_db(mp, *offset) > mp->m_dirdatablk) return 0; - } /* - * Set up putargs structure. - */ - p.dbp = dbp; - p.put = put; - p.uio = uio; + * Precalculate offsets for . and .. as we will always need them. + * + * XXX(hch): the second argument is sometimes 0 and sometimes + * mp->m_dirdatablk. + */ + dot_offset = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, + XFS_DIR2_DATA_DOT_OFFSET); + dotdot_offset = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, + XFS_DIR2_DATA_DOTDOT_OFFSET); + /* * Put . entry unless we're starting past it. */ - if (dir_offset <= - xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - XFS_DIR2_DATA_DOT_OFFSET)) { - p.cook = xfs_dir2_db_off_to_dataptr(mp, 0, - XFS_DIR2_DATA_DOTDOT_OFFSET); - p.ino = dp->i_ino; + if (*offset <= dot_offset) { + ino = dp->i_ino; #if XFS_BIG_INUMS - p.ino += mp->m_inoadd; + ino += mp->m_inoadd; #endif - p.name = "."; - p.namelen = 1; - - error = p.put(&p); - - if (!p.done) { - uio->uio_offset = - xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - XFS_DIR2_DATA_DOT_OFFSET); - return error; + if (filldir(dirent, ".", 1, dotdot_offset, ino, DT_DIR)) { + *offset = dot_offset; + return 0; } } /* * Put .. entry unless we're starting past it. */ - if (dir_offset <= - xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - XFS_DIR2_DATA_DOTDOT_OFFSET)) { - p.cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - XFS_DIR2_DATA_FIRST_OFFSET); - p.ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); + if (*offset <= dotdot_offset) { + off = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, + XFS_DIR2_DATA_FIRST_OFFSET); + ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); #if XFS_BIG_INUMS - p.ino += mp->m_inoadd; + ino += mp->m_inoadd; #endif - p.name = ".."; - p.namelen = 2; - - error = p.put(&p); - - if (!p.done) { - uio->uio_offset = - xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - XFS_DIR2_DATA_DOTDOT_OFFSET); - return error; + if (filldir(dirent, "..", 2, off, ino, DT_DIR)) { + *offset = dotdot_offset; + return 0; } } /* * Loop while there are more entries and put'ing works. */ - for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); - i < sfp->hdr.count; - i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { - + sfep = xfs_dir2_sf_firstentry(sfp); + for (i = 0; i < sfp->hdr.count; i++) { off = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, xfs_dir2_sf_get_offset(sfep)); - if (dir_offset > off) + if (*offset > off) { + sfep = xfs_dir2_sf_nextentry(sfp, sfep); continue; + } - p.namelen = sfep->namelen; - - p.cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - xfs_dir2_sf_get_offset(sfep) + - xfs_dir2_data_entsize(p.namelen)); - - p.ino = xfs_dir2_sf_get_inumber(sfp, xfs_dir2_sf_inumberp(sfep)); + ino = xfs_dir2_sf_get_inumber(sfp, xfs_dir2_sf_inumberp(sfep)); #if XFS_BIG_INUMS - p.ino += mp->m_inoadd; + ino += mp->m_inoadd; #endif - p.name = (char *)sfep->name; - error = p.put(&p); - - if (!p.done) { - uio->uio_offset = off; - return error; + if (filldir(dirent, sfep->name, sfep->namelen, + off + xfs_dir2_data_entsize(sfep->namelen), + ino, DT_UNKNOWN)) { + *offset = off; + return 0; } + sfep = xfs_dir2_sf_nextentry(sfp, sfep); } - /* - * They all fit. - */ - *eofp = 1; - - uio->uio_offset = - xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk + 1, 0); - + *offset = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk + 1, 0); return 0; } Index: linux-2.6/fs/xfs/xfs_dir2_sf.h =================================================================== --- linux-2.6.orig/fs/xfs/xfs_dir2_sf.h 2007-06-01 13:17:03.000000000 +0200 +++ linux-2.6/fs/xfs/xfs_dir2_sf.h 2007-06-01 13:17:15.000000000 +0200 @@ -169,9 +169,8 @@ extern int xfs_dir2_block_to_sf(struct x int size, xfs_dir2_sf_hdr_t *sfhp); extern int xfs_dir2_sf_addname(struct xfs_da_args *args); extern int xfs_dir2_sf_create(struct xfs_da_args *args, xfs_ino_t pino); -extern int xfs_dir2_sf_getdents(struct xfs_inode *dp, struct uio *uio, - int *eofp, struct xfs_dirent *dbp, - xfs_dir2_put_t put); +extern int xfs_dir2_sf_getdents(struct xfs_inode *dp, void *dirent, + xfs_off_t *offset, filldir_t filldir); extern int xfs_dir2_sf_lookup(struct xfs_da_args *args); extern int xfs_dir2_sf_removename(struct xfs_da_args *args); extern int xfs_dir2_sf_replace(struct xfs_da_args *args); From owner-xfs@oss.sgi.com Mon Jun 4 07:44:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 07:44:47 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54EihWt020893 for ; Mon, 4 Jun 2007 07:44:45 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l54Eifo6009791 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 4 Jun 2007 16:44:41 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l54EifIt009789 for xfs@oss.sgi.com; Mon, 4 Jun 2007 16:44:41 +0200 Date: Mon, 4 Jun 2007 16:44:41 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: state of the testsuite Message-ID: <20070604144441.GA9672@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 11622 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs When running the testsuite on Debian -testing I constanyly get the 12 failing testcases (016 041 049 064 071 082 084 104 111 136 140 166). Is this expected or are other people seeing better results? From owner-xfs@oss.sgi.com Mon Jun 4 07:50:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 07:51:01 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54EosWt023117 for ; Mon, 4 Jun 2007 07:50:58 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HvDtW-0007Kt-P8; Mon, 04 Jun 2007 15:50:54 +0100 Date: Mon, 4 Jun 2007 15:50:54 +0100 From: Christoph Hellwig To: David Chinner Cc: xfs-dev , xfs-oss Subject: Re: Review - writing to multiple non-contiguous unwritten extents within a page is broken. Message-ID: <20070604145054.GA28033@infradead.org> References: <20070523092103.GT85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070523092103.GT85884050@sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 11623 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, May 23, 2007 at 07:21:03PM +1000, David Chinner wrote: > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_aops.c 2007-05-23 16:33:04.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c 2007-05-23 17:52:15.540456674 +1000 > @@ -1008,6 +1008,8 @@ xfs_page_state_convert( > if (buffer_unwritten(bh) || buffer_delay(bh) || > ((buffer_uptodate(bh) || PageUptodate(page)) && > !buffer_mapped(bh) && (unmapped || startio))) { > + int new_ioend = 0; > + > /* > * Make sure we don't use a read-only iomap > */ > @@ -1026,6 +1028,15 @@ xfs_page_state_convert( > } > > if (!iomap_valid) { > + /* > + * if we didn't have a valid mapping then we > + * need to ensure that we put the new mapping > + * in a new ioend structure. This needs to be > + * done to ensure that the ioends correctly > + * reflect the block mappings at io completion > + * for unwritten extent conversion. > + */ > + new_ioend = 1; > if (type == IOMAP_NEW) { > size = xfs_probe_cluster(inode, > page, bh, head, 0); > @@ -1045,7 +1056,7 @@ xfs_page_state_convert( > if (startio) { > xfs_add_to_ioend(inode, bh, offset, > type, &ioend, > - !iomap_valid); > + new_ioend); Looks good. I'm pretty sure that we had something like a new_ioend variable in the initial versions of this code, but I don't know when and why we got rid of it. From owner-xfs@oss.sgi.com Mon Jun 4 07:53:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 07:53:03 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54EqwWt024112 for ; Mon, 4 Jun 2007 07:52:59 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HvDvW-0007MS-Vp; Mon, 04 Jun 2007 15:52:58 +0100 Date: Mon, 4 Jun 2007 15:52:58 +0100 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" , xfs-dev Subject: Re: [PATCH 1/3] XFS metadump utility Message-ID: <20070604145258.GB28033@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 11624 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, May 28, 2007 at 03:22:52PM +1000, Barry Naujok wrote: > Back in February, I posted a patch to xfs_db to capture metadata from a > filesystem into a file > http://oss.sgi.com/archives/xfs/2007-02/msg00072.html . > > I have now updated it with the following changes: > - obfuscates directory names and attribute names > - zeros attribute values > - better support of stdin/stdout for redirection. Is this the dpprintf to fprintf changes? These changes look like they really want to be in a separate patch with at least a sentence of an explanation. The newly added files look good to me from a quick glance. From owner-xfs@oss.sgi.com Mon Jun 4 07:55:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 07:55:17 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54Et9Wt024954 for ; Mon, 4 Jun 2007 07:55:11 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HvDxd-0007ON-QA; Mon, 04 Jun 2007 15:55:09 +0100 Date: Mon, 4 Jun 2007 15:55:09 +0100 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" , xfs-dev Subject: Re: [PATCH 3/3] XFS metadump utility Message-ID: <20070604145509.GD28033@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 11626 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, May 28, 2007 at 03:22:58PM +1000, Barry Naujok wrote: > xfs_metadump and xfs_mdrestore man pages. Looks fine. From owner-xfs@oss.sgi.com Mon Jun 4 07:54:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 07:54:55 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54EsqWt024842 for ; Mon, 4 Jun 2007 07:54:53 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HvDxM-0007O9-5p; Mon, 04 Jun 2007 15:54:52 +0100 Date: Mon, 4 Jun 2007 15:54:52 +0100 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" , xfs-dev Subject: Re: [PATCH 2/3] XFS metadump utility Message-ID: <20070604145452.GC28033@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 11625 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, May 28, 2007 at 03:22:55PM +1000, Barry Naujok wrote: > xfs_mdrestore Looks good from a quick glance. From owner-xfs@oss.sgi.com Mon Jun 4 07:56:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 07:56:22 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54EuIWt025824 for ; Mon, 4 Jun 2007 07:56:19 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HvDyj-0007Pf-0k; Mon, 04 Jun 2007 15:56:17 +0100 Date: Mon, 4 Jun 2007 15:56:16 +0100 From: Christoph Hellwig To: Timothy Shimmin Cc: David Chinner , Michal Marek , xfs@oss.sgi.com Subject: Re: [patch 1/3] Fix XFS_IOC_FSGEOMETRY_V1 in compat mode Message-ID: <20070604145616.GA28425@infradead.org> References: <20070530125954.706423971@suse.cz> <20070530143043.216024061@suse.cz> <20070531023031.GH85884050@sgi.com> <649C7FF68B1450E03D544BD9@timothy-shimmins-power-mac-g5.local> <20070531132615.GO85884050@sgi.com> <0C1BF59AD81186689933280E@timothy-shimmins-power-mac-g5.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C1BF59AD81186689933280E@timothy-shimmins-power-mac-g5.local> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 11627 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Jun 01, 2007 at 02:39:48PM +1000, Timothy Shimmin wrote: > > > --On 31 May 2007 11:26:15 PM +1000 David Chinner wrote: > >>Who would want to use XFS_IOC_FSGEOMETRY_V1? > >> > >>Okay it turns out a whole bunch of our xfs-cmds :-) > >>(Such as xfsdump as Michal mentioned) > >>On Sep/2002, Nathan changed a bunch of them to use v1. > >> xfsprogs-2.3.0 (03 September 2002) > >> - Several changes to geometry ioctl callers which will make > >> the tools useable on older kernel versions too. > >>So he did this so that new tools would work on the older kernels which > >>didn't support the new geom version. > >>So I guess we are stuck with v1 now. > > > >Not necessarily - we could change the tools to use v4, and if that > >didn't exist, then try v1. That way we don't need to support v1 in > >linux, and the tools still run on old kernels..... > > > The problem with that is the old tools won't run on new kernels. > If you get a new kernel and use an old xfsdump then you are out of luck. > Not sure if we want to require people to bump up to new userspace for this. Yeah, we need to keep supporting this for a while. Fortunately this compat handler is rather trivial. From owner-xfs@oss.sgi.com Mon Jun 4 08:02:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 08:02:42 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l54F2XWt028532 for ; Mon, 4 Jun 2007 08:02:34 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA18220; Tue, 5 Jun 2007 01:02:26 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l54F2OAf113076575; Tue, 5 Jun 2007 01:02:25 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l54F2M9w114109131; Tue, 5 Jun 2007 01:02:22 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 5 Jun 2007 01:02:22 +1000 From: David Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: state of the testsuite Message-ID: <20070604150222.GL86004887@sgi.com> References: <20070604144441.GA9672@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604144441.GA9672@lst.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 11628 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 04:44:41PM +0200, Christoph Hellwig wrote: > When running the testsuite on Debian -testing I constanyly get the > 12 failing testcases (016 041 049 064 071 082 084 104 111 136 140 166). > Is this expected or are other people seeing better results? What kernel+platform and what version of the tests? Prior to 2.6.22-rc2, 016 and 144 are the only ones i saw failing regularly. 166 will fail until we get ->page_mkwrite sorted out (but passes in my tree). With 2.6.22-rc2, all the loopback based tests are failing because someone broke the loopback device so lots of tests fail because of that. The other tests I haven't seen fail for some time... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jun 4 08:08:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 08:08:31 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54F8SWt030604 for ; Mon, 4 Jun 2007 08:08:29 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HvEAW-0007Vn-HN; Mon, 04 Jun 2007 16:08:28 +0100 Date: Mon, 4 Jun 2007 16:08:28 +0100 From: Christoph Hellwig To: David Chinner Cc: xfs-dev , xfs-oss Subject: Re: Review: remount read-only path is as broken as freezing was.... Message-ID: <20070604150828.GB28425@infradead.org> References: <20070604051433.GP85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604051433.GP85884050@sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 11629 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 03:14:33PM +1000, David Chinner wrote: > > I recently had a remount,ro test fail in a way I had previously > only seen freezing fail. That is, it failed because we still > had active transactions after calling xfs_quiesce_fs(). Further > investigation shows that this path is broken in the same ways > that the xfs freeze path was broken (and recently fixed). Actually it became more broken due to the fix changing things a little. In general a mount -o ro should be similar to a quience in most ways, so the closer we can get them the better. The patch looks good to me. One thing is that SYNC_INODE_QUIESCE should probably get a more descriptive name and a comment explaining why it's needed for quience (we want inodes updated not only in the log) and why not for remount r/o (because no one cares for that in this case) From owner-xfs@oss.sgi.com Mon Jun 4 08:10:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 08:10:41 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54FAZWt031602 for ; Mon, 4 Jun 2007 08:10:36 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HvECZ-0007Xm-75; Mon, 04 Jun 2007 16:10:35 +0100 Date: Mon, 4 Jun 2007 16:10:34 +0100 From: Christoph Hellwig To: David Chinner Cc: xfs-dev , xfs-oss Subject: Re: Review: factor extracting extent size hints from the inode Message-ID: <20070604151034.GC28425@infradead.org> References: <20070604052333.GR85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604052333.GR85884050@sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 11630 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 03:23:33PM +1000, David Chinner wrote: > Replace frequently repeated, open coded extraction of the > extent size hint from the xfs_inode with a single helper > function. Looks good, but I'd suggest not putting in the unlikelys. Realtime or alignment are perfectly normal codepaths and hardcoding them to be predicted not taken sounds like a bad idea. unlilely should be limited to exception error handling code. From owner-xfs@oss.sgi.com Mon Jun 4 08:12:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 08:12:20 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l54FCFWt032306 for ; Mon, 4 Jun 2007 08:12:17 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA18592; Tue, 5 Jun 2007 01:12:08 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l54FC6Af114148792; Tue, 5 Jun 2007 01:12:06 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l54FC445114060064; Tue, 5 Jun 2007 01:12:04 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 5 Jun 2007 01:12:04 +1000 From: David Chinner To: David Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: state of the testsuite Message-ID: <20070604151204.GM86004887@sgi.com> References: <20070604144441.GA9672@lst.de> <20070604150222.GL86004887@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604150222.GL86004887@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 11631 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Jun 05, 2007 at 01:02:22AM +1000, David Chinner wrote: > On Mon, Jun 04, 2007 at 04:44:41PM +0200, Christoph Hellwig wrote: > > When running the testsuite on Debian -testing I constanyly get the > > 12 failing testcases (016 041 049 064 071 082 084 104 111 136 140 166). > > Is this expected or are other people seeing better results? > > What kernel+platform and what version of the tests? > > Prior to 2.6.22-rc2, 016 and 144 are the only ones i saw failing > regularly. 166 will fail until we get ->page_mkwrite > sorted out (but passes in my tree). looks like 082 and 088 have been failing for a while in the automated QA as well but there's not a lot of other regular failures.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jun 4 08:12:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 08:12:32 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54FCSWt032372 for ; Mon, 4 Jun 2007 08:12:29 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HvEEO-0007Zu-Si; Mon, 04 Jun 2007 16:12:28 +0100 Date: Mon, 4 Jun 2007 16:12:28 +0100 From: Christoph Hellwig To: David Chinner Cc: xfs-dev , xfs-oss Subject: Re: Review: apply transaction deltas atomically to superblock Message-ID: <20070604151228.GD28425@infradead.org> References: <20070604080720.GV85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604080720.GV85884050@sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 11632 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Looks good and actually makes the code easier to read. From owner-xfs@oss.sgi.com Mon Jun 4 08:13:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 08:13:57 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54FDqWt000912 for ; Mon, 4 Jun 2007 08:13:54 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l54FDpo6011593 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 4 Jun 2007 17:13:52 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l54FDpcf011591; Mon, 4 Jun 2007 17:13:51 +0200 Date: Mon, 4 Jun 2007 17:13:51 +0200 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: state of the testsuite Message-ID: <20070604151351.GA11536@lst.de> References: <20070604144441.GA9672@lst.de> <20070604150222.GL86004887@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604150222.GL86004887@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 11633 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Tue, Jun 05, 2007 at 01:02:22AM +1000, David Chinner wrote: > On Mon, Jun 04, 2007 at 04:44:41PM +0200, Christoph Hellwig wrote: > > When running the testsuite on Debian -testing I constanyly get the > > 12 failing testcases (016 041 049 064 071 082 084 104 111 136 140 166). > > Is this expected or are other people seeing better results? > > What kernel+platform and what version of the tests? Current mainline on i386 (running in qemu) > With 2.6.22-rc2, all the loopback based tests are failing > because someone broke the loopback device so lots of tests > fail because of that. The other tests I haven't seen fail > for some time... Ok, that should account for the loop stuff. I already suspected Ken's unlimited number of loop devices patch breaks something. From owner-xfs@oss.sgi.com Mon Jun 4 10:21:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 10:21:44 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54HLdWt025752 for ; Mon, 4 Jun 2007 10:21:41 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l54HLdo6016961 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 4 Jun 2007 19:21:39 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l54HLcGf016959; Mon, 4 Jun 2007 19:21:38 +0200 Date: Mon, 4 Jun 2007 19:21:38 +0200 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: state of the testsuite Message-ID: <20070604172138.GA16879@lst.de> References: <20070604144441.GA9672@lst.de> <20070604150222.GL86004887@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604150222.GL86004887@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 11634 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Tue, Jun 05, 2007 at 01:02:22AM +1000, David Chinner wrote: > With 2.6.22-rc2, all the loopback based tests are failing > because someone broke the loopback device so lots of tests > fail because of that. The other tests I haven't seen fail > for some time... Backing out the dynamic loop device allocations gets me 049 back to pass. From owner-xfs@oss.sgi.com Mon Jun 4 10:24:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 10:24:07 -0700 (PDT) Received: from server46.publicompserver.de (server46.publicompserver.de [80.190.243.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l54HO0Wt027656 for ; Mon, 4 Jun 2007 10:24:02 -0700 Received: by server46.publicompserver.de (Postfix, from userid 30) id 8490E265D8A; Mon, 4 Jun 2007 19:09:42 +0200 (CEST) To: xfs@oss.sgi.com Subject: Work Less And Earn More !!! From: Ju Lee Corporation Reply-To: sulee@mail2japan.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20070604170942.8490E265D8A@server46.publicompserver.de> Date: Mon, 4 Jun 2007 19:09:42 +0200 (CEST) X-archive-position: 11635 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: employment@juleecorp.co.jp Precedence: bulk X-list: xfs Ju Lee Corporation Vacancy Post For the 2007 Quarter. Ju Lee Corporation is a Japanese textile company.We produce and distribute clothing materials such as batiks,assorted fabrics and traditional costume worldwide.We have reached big sales volume of textile materials in the Europe and now are trying to penetrate the U.K market.Quitesoon we will open representative offices or authorized sales centers in The U.K and therefore we are currently looking for people who will assist us in establishing a new distribution network there.The fact is that despite the U.K market is new for us we already have regular clients also speaks for itself. WHAT YOU NEED TO DO FOR US? The international money transfer tax for legal entities (companies) in Japan is 25%, whereas for the individual it is only 7%.There is no sense for us to work this way,while tax for international money transfer made by a private individual is 7% .That's why we need you!We need agents to receive payment for our textiles to cash payment( in money orders,cheque or bank wire transfers) and to resend the money to us via Money Gram or Western Union Money Transfer.This way we will save money because of tax decreasing. JOB DESCRIPTION? 1) Receive payment from Clients 2) Cash Payments at your Bank 3) Deduct 10% which will be your percentage/pay on Payment processed. 4) Forward balance after deduction of percentage/pay to any of the offices you will be contacted to send payment to(Payment is to forwarded either by Money Gram or Western Union Money Transfer) HOW MUCH WILL YOU EARN? 10% from each operation! For instance: you receive $7000 USD via cheques or money orders on our behalf.You will cash the money and keep $700 (10% from $7000) for yourself! At the beginning your commission will equal 10%,though later it will increase up to 12%! ADVANTAGES You do not have to go out as you will work as an independent contractor right from your home office. Your job is absolutely legal. You can earn up to $3000-$4000 monthly depending on time you will spend for this job. You do not need any capital to start.You can do the Work easily without leaving or affecting your present Job.The employees who make efforts and work hard have a strong possibility to become managers.Anyway our employees never leave us. MAIN REQUIREMENTS 18 years or older Legally capable Responsible Ready to work 3-4 hours per week. With PC knowledge E-mail and Internet experience (minimal) And please know that Everything is absolutely legal,that's why You would be sent the Contract Agreement to see the terms and condition of the company! If you are interested in our offer,please respond with the following details in order for us to reach you: FULL NAME: CONTACT ADDRESS: AGE: SEX: OCCUPATION: PHONE #: FAX #: Response should be sent to the following following email address: Sulee@mail2japan.com Please send your resume so that I can let you know more details as regards the job Please get back to me as soon as you can. Thanks for your anticipated action.And we hope to hear back from you. Very Respectfully, Su Lee Recruitment Officer Ju Lee Corporation From owner-xfs@oss.sgi.com Mon Jun 4 17:43:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 17:43:35 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l550hTWt016204 for ; Mon, 4 Jun 2007 17:43:30 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA03908; Tue, 5 Jun 2007 10:43:22 +1000 Date: Tue, 05 Jun 2007 10:47:24 +1000 To: "Christoph Hellwig" Subject: Re: [PATCH 1/3] XFS metadump utility From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" , xfs-dev Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20070604145258.GB28033@infradead.org> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20070604145258.GB28033@infradead.org> User-Agent: Opera Mail/9.10 (Win32) X-archive-position: 11636 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Tue, 05 Jun 2007 00:52:58 +1000, Christoph Hellwig wrote: > On Mon, May 28, 2007 at 03:22:52PM +1000, Barry Naujok wrote: >> Back in February, I posted a patch to xfs_db to capture metadata from a >> filesystem into a file >> http://oss.sgi.com/archives/xfs/2007-02/msg00072.html . >> >> I have now updated it with the following changes: >> - obfuscates directory names and attribute names >> - zeros attribute values >> - better support of stdin/stdout for redirection. > > Is this the dpprintf to fprintf changes? These changes look like they > really want to be in a separate patch with at least a sentence of an > explanation. Nah, the fprintf instead of dbprintf was required so errors don't go to stdout when using stdout as a target. The better support is using fread/fwrite instead of read/write to a handle. > The newly added files look good to me from a quick glance. > From owner-xfs@oss.sgi.com Mon Jun 4 18:43:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 18:43:48 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l551hfWt032232 for ; Mon, 4 Jun 2007 18:43:43 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA05435; Tue, 5 Jun 2007 11:43:40 +1000 Date: Tue, 05 Jun 2007 11:46:59 +1000 To: "xfs@oss.sgi.com" , xfs-dev Subject: [REVIEW 1/3] - xfs_repair speedups (AG stride) From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------snCyDrAzmtE7lnFw3tZOqj MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-archive-position: 11637 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs ------------snCyDrAzmtE7lnFw3tZOqj Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: Quoted-Printable As an ongoing series from previous xfs_repair patches, this one changes=20= =20 the method of selecting and performing multithreaded AG processing. With most simple filesystems, the current multithreading method actually=20= =20 make xfs_repair slower by increasing the amount of disk seeking between=20= =20 AGs. The biggest benefits for parallel processing of AGs is when the filesystem= =20=20 is across a concat of disks/LUNs. So, now the default is a single thread=20= =20 unless you specify an "ag_stride" using the xfs_repair -o option. Then it= =20=20 will initiate a suitable number of threads based on the number of AGs in=20= =20 the filesystem and the stride value. For example, a 32 AG filesystem with a concat of 2 equal sized disks/LUNs,= =20=20 you would use the "-o ag_stride=3D16" to get one thread to process AGs 0-15= =20=20 and the second thread to process AGs 16-31. Generally, the stride value is set to the AG number that is fully within=20= =20 the second part of the concat.= ------------snCyDrAzmtE7lnFw3tZOqj Content-Disposition: attachment; filename=ag_stride Content-Type: application/octet-stream; name=ag_stride Content-Transfer-Encoding: Base64 SW5kZXg6IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvZ2xvYmFscy5oCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dzL3Jl cGFpci9nbG9iYWxzLmgJMjAwNy0wNC0xMiAxNjoxMzo1OC4wMDAwMDAwMDAg KzEwMDAKKysrIHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvZ2xvYmFscy5oCTIw MDctMDQtMTIgMTc6MDc6MjUuNjU2NjYwNDk4ICsxMDAwCkBAIC0yMDYsNCAr MjA2LDYgQEAKIEVYVEVSTiBpbnQgcmVwb3J0X2ludGVydmFsOwogRVhURVJO IF9fdWludDY0X3QgKnByb2dfcnB0X2RvbmU7CiAKK0VYVEVSTiBpbnQJCWFn X3N0cmlkZTsKKwogI2VuZGlmIC8qIF9YRlNfUkVQQUlSX0dMT0JBTF9IICov CkluZGV4OiByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL2luaXQuYwo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIub3JpZy94ZnNwcm9ncy9yZXBh aXIvaW5pdC5jCTIwMDctMDQtMTIgMTQ6NTU6NTcuMDAwMDAwMDAwICsxMDAw CisrKyByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL2luaXQuYwkyMDA3LTA0LTEy IDE2OjQwOjQwLjUzNzEyMTczOCArMTAwMApAQCAtMTQ5LDUgKzE0OSw0IEBA CiAJCWlmIChkb19wcmVmZXRjaCkKIAkJCWxpYnhmc19saW9fYWxsb2NhdGUo KTsKIAl9Ci0JdGhyZWFkX2luaXQoKTsKIH0KSW5kZXg6IHJlcGFpci94ZnNw cm9ncy9yZXBhaXIvcGhhc2UzLmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVwYWlyL3BoYXNlMy5jCTIwMDct MDQtMTIgMTQ6NTU6NTcuMDAwMDAwMDAwICsxMDAwCisrKyByZXBhaXIveGZz cHJvZ3MvcmVwYWlyL3BoYXNlMy5jCTIwMDctMDQtMTIgMTY6NDU6NTAuNTk2 OTEzNjE1ICsxMDAwCkBAIC0xOTIsOCArMTkyLDE0IEBACiAJICAgICIgICAg ICAgIC0gcHJvY2VzcyBrbm93biBpbm9kZXMgYW5kIHBlcmZvcm0gaW5vZGUg ZGlzY292ZXJ5Li4uXG4iKSk7CiAKIAlzZXRfcHJvZ3Jlc3NfbXNnKFBST0df Rk1UX1BST0NFU1NfSU5PLCAoX191aW50NjRfdCkgbXAtPm1fc2Iuc2JfaWNv dW50KTsKLQlmb3IgKGkgPSAwOyBpIDwgbXAtPm1fc2Iuc2JfYWdjb3VudDsg aSsrKSAgewotCQlxdWV1ZV93b3JrKHBhcmFsbGVsX3AzX3Byb2Nlc3NfYWdp bm9kZXMsIG1wLCBpKTsKKwlpZiAoYWdfc3RyaWRlKSB7CisJCWludCAJc3Rl cHMgPSAobXAtPm1fc2Iuc2JfYWdjb3VudCArIGFnX3N0cmlkZSAtIDEpIC8g YWdfc3RyaWRlOworCQlmb3IgKGkgPSAwOyBpIDwgc3RlcHM7IGkrKykKKwkJ CWZvciAoaiA9IGk7IGogPCBtcC0+bV9zYi5zYl9hZ2NvdW50OyBqICs9IGFn X3N0cmlkZSkKKwkJCQlxdWV1ZV93b3JrKHBhcmFsbGVsX3AzX3Byb2Nlc3Nf YWdpbm9kZXMsIG1wLCBqKTsKKwl9IGVsc2UgeworCQlmb3IgKGkgPSAwOyBp IDwgbXAtPm1fc2Iuc2JfYWdjb3VudDsgaSsrKQorCQkJcGFyYWxsZWxfcDNf cHJvY2Vzc19hZ2lub2RlcyhtcCwgaSk7CiAJfQogCXdhaXRfZm9yX3dvcmtl cnMoKTsKIAlwcmludF9maW5hbF9ycHQoKTsKSW5kZXg6IHJlcGFpci94ZnNw cm9ncy9yZXBhaXIvcGhhc2U0LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVwYWlyL3BoYXNlNC5jCTIwMDct MDQtMTIgMTQ6NTU6NTcuMDAwMDAwMDAwICsxMDAwCisrKyByZXBhaXIveGZz cHJvZ3MvcmVwYWlyL3BoYXNlNC5jCTIwMDctMDQtMTIgMTY6NDU6NTEuNzI0 NzY3MzAwICsxMDAwCkBAIC0xMzQyLDE4ICsxMzQyLDI2IEBACiAKIAlkb19s b2coXygiICAgICAgICAtIGNoZWNrIGZvciBpbm9kZXMgY2xhaW1pbmcgZHVw bGljYXRlIGJsb2Nrcy4uLlxuIikpOwogCXNldF9wcm9ncmVzc19tc2coUFJP R19GTVRfRFVQX0JMT0NLUywgKF9fdWludDY0X3QpIG1wLT5tX3NiLnNiX2lj b3VudCk7Ci0JZm9yIChpID0gMDsgaSA8IG1wLT5tX3NiLnNiX2FnY291bnQ7 IGkrKykgIHsKLQkJLyoKLQkJICogb2ssIG5vdyBwcm9jZXNzIHRoZSBpbm9k ZXMgLS0gc2lnbmFsIDItcGFzcyBjaGVjayBwZXIgaW5vZGUuCi0JCSAqIGZp cnN0IHBhc3MgY2hlY2tzIGlmIHRoZSBpbm9kZSBjb25mbGljdHMgd2l0aCBh IGtub3duCi0JCSAqIGR1cGxpY2F0ZSBleHRlbnQuICBpZiBzbywgdGhlIGlu b2RlIGlzIGNsZWFyZWQgYW5kIHNlY29uZAotCQkgKiBwYXNzIGlzIHNraXBw ZWQuICBzZWNvbmQgcGFzcyBzZXRzIHRoZSBibG9jayBiaXRtYXAKLQkJICog Zm9yIGFsbCBibG9ja3MgY2xhaW1lZCBieSB0aGUgaW5vZGUuICBkaXJlY3Rv cnkKLQkJICogYW5kIGF0dHJpYnV0ZSBwcm9jZXNzaW5nIGlzIHR1cm5lZCBP RkYgc2luY2Ugd2UgZGlkIHRoYXQKLQkJICogYWxyZWFkeSBpbiBwaGFzZSAz LgotCQkgKi8KLQkJcXVldWVfd29yayhwYXJhbGxlbF9wNF9wcm9jZXNzX2Fn aW5vZGVzLCBtcCwgaSk7CisKKwkvKgorCSAqIG9rLCBub3cgcHJvY2VzcyB0 aGUgaW5vZGVzIC0tIHNpZ25hbCAyLXBhc3MgY2hlY2sgcGVyIGlub2RlLgor CSAqIGZpcnN0IHBhc3MgY2hlY2tzIGlmIHRoZSBpbm9kZSBjb25mbGljdHMg d2l0aCBhIGtub3duCisJICogZHVwbGljYXRlIGV4dGVudC4gIGlmIHNvLCB0 aGUgaW5vZGUgaXMgY2xlYXJlZCBhbmQgc2Vjb25kCisJICogcGFzcyBpcyBz a2lwcGVkLiAgc2Vjb25kIHBhc3Mgc2V0cyB0aGUgYmxvY2sgYml0bWFwCisJ ICogZm9yIGFsbCBibG9ja3MgY2xhaW1lZCBieSB0aGUgaW5vZGUuICBkaXJl Y3RvcnkKKwkgKiBhbmQgYXR0cmlidXRlIHByb2Nlc3NpbmcgaXMgdHVybmVk IE9GRiBzaW5jZSB3ZSBkaWQgdGhhdAorCSAqIGFscmVhZHkgaW4gcGhhc2Ug My4KKwkgKi8KKwlpZiAoYWdfc3RyaWRlKSB7CisJCWludCAJc3RlcHMgPSAo bXAtPm1fc2Iuc2JfYWdjb3VudCArIGFnX3N0cmlkZSAtIDEpIC8gYWdfc3Ry aWRlOworCQlmb3IgKGkgPSAwOyBpIDwgc3RlcHM7IGkrKykKKwkJCWZvciAo aiA9IGk7IGogPCBtcC0+bV9zYi5zYl9hZ2NvdW50OyBqICs9IGFnX3N0cmlk ZSkKKwkJCQlxdWV1ZV93b3JrKHBhcmFsbGVsX3A0X3Byb2Nlc3NfYWdpbm9k ZXMsIG1wLCBqKTsKKwl9IGVsc2UgeworCQlmb3IgKGkgPSAwOyBpIDwgbXAt Pm1fc2Iuc2JfYWdjb3VudDsgaSsrKQorCQkJcGFyYWxsZWxfcDRfcHJvY2Vz c19hZ2lub2RlcyhtcCwgaSk7CiAJfQorCiAJd2FpdF9mb3Jfd29ya2Vycygp OwogCXByaW50X2ZpbmFsX3JwdCgpOwogCkluZGV4OiByZXBhaXIveGZzcHJv Z3MvcmVwYWlyL3hmc19yZXBhaXIuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSByZXBhaXIub3JpZy94ZnNwcm9ncy9yZXBhaXIveGZzX3JlcGFpci5j CTIwMDctMDQtMTIgMTY6MTE6MjQuMDAwMDAwMDAwICsxMDAwCisrKyByZXBh aXIveGZzcHJvZ3MvcmVwYWlyL3hmc19yZXBhaXIuYwkyMDA3LTA0LTEyIDE2 OjQ0OjQ2LjIyNTI2Mzc3NiArMTAwMApAQCAtNjUsOCArNjUsOCBAQAogCSJw ZmRpciIsCiAjZGVmaW5lCVBSRUZFVENIX0FJT19DTlQJNgogCSJwZmFpbyIs Ci0jZGVmaW5lCVRIUkVBRF9DTlQJCTcKLQkidGhyZWFkIiwKKyNkZWZpbmUJ QUdfU1RSSURFCQk3CisJImFnX3N0cmlkZSIsCiAJTlVMTAogfTsKIApAQCAt MTg2LDYgKzE4Niw5IEBACiAJZnNfaGFzX2V4dGZsZ2JpdF9hbGxvd2VkID0g MTsKIAlwcmVfNjVfYmV0YSA9IDA7CiAJZnNfc2hhcmVkX2FsbG93ZWQgPSAx OworCWFnX3N0cmlkZSA9IDA7CisJdGhyZWFkX2NvdW50ID0gMDsKKwlkb19w YXJhbGxlbCA9IDA7CiAJcmVwb3J0X2ludGVydmFsID0gUFJPR19SUFRfREVG QVVMVDsKIAogCS8qCkBAIC0yMzMsOCArMjM2LDggQEAKIAkJCQljYXNlIFBS RUZFVENIX0FJT19DTlQ6CiAJCQkJCWxpYnhmc19saW9fYWlvX2NvdW50ID0g KGludCkgc3RydG9sKHZhbCwgMCwgMCk7CiAJCQkJCWJyZWFrOwotCQkJCWNh c2UgVEhSRUFEX0NOVDoKLQkJCQkJdGhyZWFkX2NvdW50ID0gKGludCkgc3Ry dG9sKHZhbCwgMCwgMCk7CisJCQkJY2FzZSBBR19TVFJJREU6CisJCQkJCWFn X3N0cmlkZSA9IChpbnQpIHN0cnRvbCh2YWwsIDAsIDApOwogCQkJCQlicmVh azsKIAkJCQlkZWZhdWx0OgogCQkJCQl1bmtub3duKCdvJywgdmFsKTsKQEAg LTUyNSw2ICs1MjgsMTIgQEAKIAltYXhfc3ltbGlua19ibG9ja3MgPSBob3dt YW55KE1BWFBBVEhMRU4gLSAxLCBtcC0+bV9zYi5zYl9ibG9ja3NpemUpOwog CWlub2Rlc19wZXJfY2x1c3RlciA9IFhGU19JTk9ERV9DTFVTVEVSX1NJWkUo bXApID4+IG1wLT5tX3NiLnNiX2lub2RlbG9nOwogCisJaWYgKGFnX3N0cmlk ZSkgeworCQlkb19wYXJhbGxlbCA9IDE7CisJCXRocmVhZF9jb3VudCA9ICht cC0+bV9zYi5zYl9hZ2NvdW50ICsgYWdfc3RyaWRlIC0gMSkgLyBhZ19zdHJp ZGU7CisJCXRocmVhZF9pbml0KCk7CisJfQorCiAJaWYgKGRvX3BhcmFsbGVs ICYmIHJlcG9ydF9pbnRlcnZhbCkgewogCQlpbml0X3Byb2dyZXNzX3JwdCgp OwogCQltc2didWYgPSBtYWxsb2MoRFVSQVRJT05fQlVGX1NJWkUpOwo= ------------snCyDrAzmtE7lnFw3tZOqj-- From owner-xfs@oss.sgi.com Mon Jun 4 18:50:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 18:50:49 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l551odWt001588 for ; Mon, 4 Jun 2007 18:50:41 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA05642; Tue, 5 Jun 2007 11:50:39 +1000 Date: Tue, 05 Jun 2007 11:54:00 +1000 To: "xfs@oss.sgi.com" , xfs-dev Subject: [REVIEW 2/3] - xfs_repair enhancements (lost+found handling) From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------yUh6rLTYauJAeqPswTCPZX MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-archive-position: 11638 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs ------------yUh6rLTYauJAeqPswTCPZX Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 7bit This particular patch is in the sequence for part 3 which will rely on I/O being uniform for each piece of metadata. It changes the behaviour of lost+found quite substantially in xfs_repair. Currently, xfs_repair deletes any lost+found directories in phase 3, which will orphan inodes that still reside in lost+found. During phase 6, it's recreated and repopulated with orphaned inodes. When one leaves inodes in lost+found between successive runs, it can cause some confusion as xfs_repair keeps on discovering orphaned inodes. This change leaves any lost+found directory or inode alone during phases 3/4 (other than checking for normal consistancy). During phase 6, if it finds lost+found in the root inode, it checks that it's a directory and is consistant and remembers it. If it's corrupted, it's junked or repaired like any other directory. If it's not a directory, it's junked. During the last part of phase 6, if any orphaned inodes are found, it will place them in the previously located lost+found directory, or create it and place them. ------------yUh6rLTYauJAeqPswTCPZX Content-Disposition: attachment; filename=lost+found Content-Type: application/octet-stream; name=lost+found Content-Transfer-Encoding: Base64 SW5kZXg6IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvZGlub19jaHVua3MuYwo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIub3JpZy94ZnNwcm9n cy9yZXBhaXIvZGlub19jaHVua3MuYwkyMDA3LTA0LTI3IDE0OjA5OjA1LjY5 MDc4MzAwNSArMTAwMAorKysgcmVwYWlyL3hmc3Byb2dzL3JlcGFpci9kaW5v X2NodW5rcy5jCTIwMDctMDQtMjcgMTQ6MTE6NDEuMDAwMDAwMDAwICsxMDAw CkBAIC03NjIsMTggKzc2MiwxNCBAQAogCQkgKi8KIAkJaWYgKGlzX3VzZWQp ICB7CiAJCQlpZiAoaXNfaW5vZGVfZnJlZShpbm9fcmVjLCBpcmVjX29mZnNl dCkpICB7Ci0JCQkJaWYgKHZlcmJvc2UgfHwgbm9fbW9kaWZ5IHx8Ci0JCQkJ ICAgIFhGU19BR0lOT19UT19JTk8obXAsIGFnbm8sIGFnaW5vKSAhPQotCQkJ CQkJCW9sZF9vcnBoYW5hZ2VfaW5vKSAgeworCQkJCWlmICh2ZXJib3NlIHx8 IG5vX21vZGlmeSkgIHsKIAkJCQkJZG9fd2FybihfKCJpbWFwIGNsYWltcyBp bi11c2UgaW5vZGUgIgogCQkJCQkJICAiJWxsdSBpcyBmcmVlLCAiKSwKIAkJ CQkJCVhGU19BR0lOT19UT19JTk8obXAsIGFnbm8sCiAJCQkJCQlhZ2lubykp OwogCQkJCX0KIAotCQkJCWlmICh2ZXJib3NlIHx8ICghbm9fbW9kaWZ5ICYm Ci0JCQkJICAgIFhGU19BR0lOT19UT19JTk8obXAsIGFnbm8sIGFnaW5vKSAh PQotCQkJCQkJb2xkX29ycGhhbmFnZV9pbm8pKQorCQkJCWlmICh2ZXJib3Nl IHx8ICFub19tb2RpZnkpCiAJCQkJCWRvX3dhcm4oXygiY29ycmVjdGluZyBp bWFwXG4iKSk7CiAJCQkJZWxzZQogCQkJCQlkb193YXJuKF8oIndvdWxkIGNv cnJlY3QgaW1hcFxuIikpOwpJbmRleDogcmVwYWlyL3hmc3Byb2dzL3JlcGFp ci9kaXIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIub3Jp Zy94ZnNwcm9ncy9yZXBhaXIvZGlyLmMJMjAwNy0wNC0yNyAxMzoxMzozNS45 NzE5OTM0ODkgKzEwMDAKKysrIHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvZGly LmMJMjAwNy0wNC0yNyAxNDoxMTo0MS4wMDAwMDAwMDAgKzEwMDAKQEAgLTE5 NTIsMTIgKzE5NTIsNiBAQAogCQkJCV8oIlx0d291bGQgY2xlYXIgaW5vIG51 bWJlciBpbiBlbnRyeSAlZC4uLlxuIiksCiAJCQkJCWkpOwogCQkJfQotCQl9 IGVsc2UgaWYgKGxpbm8gPT0gb2xkX29ycGhhbmFnZV9pbm8pICB7Ci0JCQkv KgotCQkJICogZG8gbm90aGluZywgc2lsZW50bHkgaWdub3JlIGl0LCBlbnRy eSBoYXMKLQkJCSAqIGFscmVhZHkgYmVlbiBtYXJrZWQgVEJEIHNpbmNlIG9s ZF9vcnBoYW5hZ2VfaW5vCi0JCQkgKiBpcyBzZXQgbm9uLXplcm8uCi0JCQkg Ki8KIAkJfSBlbHNlIGlmICgoaXJlY19wID0gZmluZF9pbm9kZV9yZWMoCiAJ CQkJWEZTX0lOT19UT19BR05PKG1wLCBsaW5vKSwKIAkJCQlYRlNfSU5PX1RP X0FHSU5PKG1wLCBsaW5vKSkpICE9IE5VTEwpICB7CkluZGV4OiByZXBhaXIv eGZzcHJvZ3MvcmVwYWlyL2RpcjIuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSByZXBhaXIub3JpZy94ZnNwcm9ncy9yZXBhaXIvZGlyMi5jCTIwMDct MDQtMjcgMTM6MTM6MzUuOTcxOTkzNDg5ICsxMDAwCisrKyByZXBhaXIveGZz cHJvZ3MvcmVwYWlyL2RpcjIuYwkyMDA3LTA0LTI3IDE0OjExOjQxLjAwMDAw MDAwMCArMTAwMApAQCAtMTQ0MCwxMyArMTQ0MCw2IEBACiAJCX0gZWxzZSBp ZiAoSU5UX0dFVChkZXAtPmludW1iZXIsIEFSQ0hfQ09OVkVSVCkgPT0gbXAt Pm1fc2Iuc2JfZ3F1b3Rpbm8pIHsKIAkJCWNsZWFyaW5vID0gMTsKIAkJCWNs ZWFycmVhc29uID0gXygiZ3JvdXAgcXVvdGEiKTsKLQkJfSBlbHNlIGlmIChJ TlRfR0VUKGRlcC0+aW51bWJlciwgQVJDSF9DT05WRVJUKSA9PSBvbGRfb3Jw aGFuYWdlX2lubykgewotCQkJLyoKLQkJCSAqIERvIG5vdGhpbmcsIHNpbGVu dGx5IGlnbm9yZSBpdCwgZW50cnkgaGFzIGFscmVhZHkKLQkJCSAqIGJlZW4g bWFya2VkIFRCRCBzaW5jZSBvbGRfb3JwaGFuYWdlX2lubyBpcyBzZXQKLQkJ CSAqIG5vbi16ZXJvLgotCQkJICovCi0JCQljbGVhcmlubyA9IDA7CiAJCX0g ZWxzZSBpZiAoKGlyZWNfcCA9IGZpbmRfaW5vZGVfcmVjKAogCQkJCVhGU19J Tk9fVE9fQUdOTyhtcCwgSU5UX0dFVChkZXAtPmludW1iZXIsCiAJCQkJCUFS Q0hfQ09OVkVSVCkpLApJbmRleDogcmVwYWlyL3hmc3Byb2dzL3JlcGFpci9n bG9iYWxzLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gcmVwYWlyLm9y aWcveGZzcHJvZ3MvcmVwYWlyL2dsb2JhbHMuaAkyMDA3LTA0LTI3IDE0OjEx OjQxLjY4MjQxODIzNCArMTAwMAorKysgcmVwYWlyL3hmc3Byb2dzL3JlcGFp ci9nbG9iYWxzLmgJMjAwNy0wNC0yNyAxNDoxMTo0MS4wMDAwMDAwMDAgKzEw MDAKQEAgLTE4OCw5ICsxODgsNiBAQAogRVhURVJOIF9fdWludDY0X3QJc2Jf ZmRibG9ja3M7CS8qIGZyZWUgZGF0YSBibG9ja3MgKi8KIEVYVEVSTiBfX3Vp bnQ2NF90CXNiX2ZyZXh0ZW50czsJLyogZnJlZSByZWFsdGltZSBleHRlbnRz ICovCiAKLUVYVEVSTiB4ZnNfaW5vX3QJb3JwaGFuYWdlX2lubzsKLUVYVEVS TiB4ZnNfaW5vX3QJb2xkX29ycGhhbmFnZV9pbm87Ci0KIC8qIHN1cGVyYmxv Y2sgZ2VvbWV0cnkgaW5mbyAqLwogCiBFWFRFUk4geGZzX2V4dGxlbl90CXNi X2lub2FsaWdubXQ7CkluZGV4OiByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL3Bo YXNlMS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHJlcGFpci5vcmln L3hmc3Byb2dzL3JlcGFpci9waGFzZTEuYwkyMDA3LTA0LTI3IDEzOjEzOjM1 Ljk3MTk5MzQ4OSArMTAwMAorKysgcmVwYWlyL3hmc3Byb2dzL3JlcGFpci9w aGFzZTEuYwkyMDA3LTA0LTI3IDE0OjExOjQxLjc4MjQwNTE4MSArMTAwMApA QCAtNjMsNyArNjMsNiBAQAogCW5lZWRfcmJtaW5vID0gMDsKIAluZWVkX3Jz dW1pbm8gPSAwOwogCWxvc3RfcXVvdGFzID0gMDsKLQlvbGRfb3JwaGFuYWdl X2lubyA9ICh4ZnNfaW5vX3QpIDA7CiAKIAkvKgogCSAqIGdldCBBRyAwIGlu dG8gYWcgaGVhZGVyIGJ1ZgpJbmRleDogcmVwYWlyL3hmc3Byb2dzL3JlcGFp ci9waGFzZTQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIu b3JpZy94ZnNwcm9ncy9yZXBhaXIvcGhhc2U0LmMJMjAwNy0wNC0yNyAxNDox MTo0MS42OTA0MTcxODkgKzEwMDAKKysrIHJlcGFpci94ZnNwcm9ncy9yZXBh aXIvcGhhc2U0LmMJMjAwNy0wNC0yNyAxNDoxMTo0MS4wMDAwMDAwMDAgKzEw MDAKQEAgLTMyLDEwMjAgKzMyLDYgQEAKICNpbmNsdWRlICJwcm9ncmVzcy5o IgogCiAKLS8qIEFSR1NVU0VEICovCi1pbnQKLWxmX2Jsb2NrX2RlbGV0ZV9v cnBoYW5hZ2UoeGZzX21vdW50X3QJCSptcCwKLQkJCXhmc19pbm9fdAkJaW5v LAotCQkJeGZzX2Rpcl9sZWFmYmxvY2tfdAkqbGVhZiwKLQkJCWludAkJCSpk aXJ0eSwKLQkJCXhmc19idWZfdAkJKnJvb3Rpbm9fYnAsCi0JCQlpbnQJCQkq cmJ1Zl9kaXJ0eSkKLXsKLQl4ZnNfZGlyX2xlYWZfZW50cnlfdAkqZW50cnk7 Ci0JeGZzX2Rpbm9kZV90CQkqZGlubzsKLQl4ZnNfYnVmX3QJCSpicDsKLQlp bm9fdHJlZV9ub2RlX3QJCSppcmVjOwotCXhmc19pbm9fdAkJbGlubzsKLQl4 ZnNfZGlyX2xlYWZfbmFtZV90CSpuYW1lc3Q7Ci0JeGZzX2FnaW5vX3QJCWFn aW5vOwotCXhmc19hZ251bWJlcl90CQlhZ25vOwotCXhmc19hZ2lub190CQly b290X2FnaW5vOwotCXhmc19hZ251bWJlcl90CQlyb290X2Fnbm87Ci0JaW50 CQkJaTsKLQlpbnQJCQlpbm9fb2Zmc2V0OwotCWludAkJCWlub19kaXJ0eTsK LQlpbnQJCQl1c2VfcmJ1ZjsKLQlpbnQJCQlsZW47Ci0JY2hhcgkJCWZuYW1l W01BWE5BTUVMRU4gKyAxXTsKLQlpbnQJCQlyZXM7Ci0KLQllbnRyeSA9ICZs ZWFmLT5lbnRyaWVzWzBdOwotCSpkaXJ0eSA9IDA7Ci0JdXNlX3JidWYgPSAw OwotCXJlcyA9IDA7Ci0Jcm9vdF9hZ25vID0gWEZTX0lOT19UT19BR05PKG1w LCBtcC0+bV9zYi5zYl9yb290aW5vKTsKLQlyb290X2FnaW5vID0gWEZTX0lO T19UT19BR0lOTyhtcCwgbXAtPm1fc2Iuc2Jfcm9vdGlubyk7Ci0KLQlmb3Ig KGkgPSAwOyBpIDwgSU5UX0dFVChsZWFmLT5oZHIuY291bnQsIEFSQ0hfQ09O VkVSVCk7IGVudHJ5KyssIGkrKykgewotCQluYW1lc3QgPSBYRlNfRElSX0xF QUZfTkFNRVNUUlVDVChsZWFmLAotCQkJSU5UX0dFVChlbnRyeS0+bmFtZWlk eCwgQVJDSF9DT05WRVJUKSk7Ci0JCVhGU19ESVJfU0ZfR0VUX0RJUklOTygm bmFtZXN0LT5pbnVtYmVyLCAmbGlubyk7Ci0JCWJjb3B5KG5hbWVzdC0+bmFt ZSwgZm5hbWUsIGVudHJ5LT5uYW1lbGVuKTsKLQkJZm5hbWVbZW50cnktPm5h bWVsZW5dID0gJ1wwJzsKLQotCQlpZiAoZm5hbWVbMF0gIT0gJy8nICYmICFz dHJjbXAoZm5hbWUsIE9SUEhBTkFHRSkpICB7Ci0JCQlhZ2lubyA9IFhGU19J Tk9fVE9fQUdJTk8obXAsIGxpbm8pOwotCQkJYWdubyA9IFhGU19JTk9fVE9f QUdOTyhtcCwgbGlubyk7Ci0KLQkJCW9sZF9vcnBoYW5hZ2VfaW5vID0gbGlu bzsKLQotCQkJaXJlYyA9IGZpbmRfaW5vZGVfcmVjKGFnbm8sIGFnaW5vKTsK LQotCQkJLyoKLQkJCSAqIGlmIHRoZSBvcnBoYW5nZSBpbm9kZSBpcyBpbiB0 aGUgdHJlZSwKLQkJCSAqIGdldCBpdCwgY2xlYXIgaXQsIGFuZCBtYXJrIGl0 IGZyZWUuCi0JCQkgKiB0aGUgaW5vZGVzIGluIHRoZSBvcnBoYW5hZ2Ugd2ls bCBnZXQKLQkJCSAqIHJlYXR0YWNoZWQgdG8gdGhlIG5ldyBvcnBoYW5hZ2Uu Ci0JCQkgKi8KLQkJCWlmIChpcmVjICE9IE5VTEwpICB7Ci0JCQkJaW5vX29m ZnNldCA9IGFnaW5vIC0gaXJlYy0+aW5vX3N0YXJ0bnVtOwotCi0JCQkJLyoK LQkJCQkgKiBjaGVjayBpZiB3ZSBoYXZlIHRvIHVzZSB0aGUgcm9vdCBpbm9k ZQotCQkJCSAqIGJ1ZmZlciBvciByZWFkIG9uZSBpbiBvdXJzZWx2ZXMuICBO b3RlCi0JCQkJICogdGhhdCB0aGUgcm9vdCBpbm9kZSBpcyBhbHdheXMgdGhl IGZpcnN0Ci0JCQkJICogaW5vZGUgb2YgdGhlIGNodW5rIHRoYXQgaXQncyBp biBzbyB0aGVyZQotCQkJCSAqIGFyZSB0d28gcG9zc2libGUgY2FzZXMgd2hl cmUgbG9zdCtmb3VuZAotCQkJCSAqIG1pZ2h0IGJlIGluIHRoZSBzYW1lIGJ1 ZmZlciBhcyB0aGUgcm9vdAotCQkJCSAqIGlub2RlLiAgT25lIGNhc2UgaXMg YSBsYXJnZSBibG9jawotCQkJCSAqIGZpbGVzeXN0ZW0gd2hlcmUgdGhlIHR3 byBpbm9kZXMgYXJlCi0JCQkJICogaW4gZGlmZmVyZW50IGlub2RlIGNodW5r cyBidXQgd2luZAotCQkJCSAqIHVwIGluIHRoZSBzYW1lIGJsb2NrIChtdWx0 aXBsZSBjaHVua3MKLQkJCQkgKiBwZXIgYmxvY2spIGFuZCB0aGUgc2Vjb25k IGNhc2UgKG9uZSBvcgotCQkJCSAqIG1vcmUgYmxvY2tzIHBlciBjaHVuaykg aXMgd2hlcmUgdGhlIHR3bwotCQkJCSAqIGlub2RlcyBhcmUgaW4gdGhlIHNh bWUgY2h1bmsuIE5vdGUgdGhhdAotCQkJCSAqIGlub2RlcyBhcmUgYWxsb2Nh dGVkIG9uIGRpc2sgaW4gdW5pdHMKLQkJCQkgKiBvZiBNQVgoWEZTX0lOT0RF U19QRVJfQ0hVTkssc2JfaW5vcGJsb2NrKS4KLQkJCQkgKi8KLQkJCQlpZiAo WEZTX0lOT19UT19GU0IobXAsIG1wLT5tX3NiLnNiX3Jvb3Rpbm8pCi0JCQkJ CQk9PSBYRlNfSU5PX1RPX0ZTQihtcCwgbGlubykgfHwKLQkJCQkgICAgKGFn bm8gPT0gcm9vdF9hZ25vICYmCi0JCQkJICAgICBhZ2lubyA8IHJvb3RfYWdp bm8gKyBYRlNfSU5PREVTX1BFUl9DSFVOSykpIHsKLQkJCQkJdXNlX3JidWYg PSAxOwotCQkJCQlicCA9IHJvb3Rpbm9fYnA7Ci0JCQkJCWRpbm8gPSBYRlNf TUFLRV9JUFRSKG1wLCBicCwgYWdpbm8gLQotCQkJCQkJWEZTX0lOT19UT19B R0lOTyhtcCwKLQkJCQkJCQltcC0+bV9zYi5zYl9yb290aW5vKSk7Ci0JCQkJ fSBlbHNlIHsKLQkJCQkJbGVuID0gKGludClYRlNfRlNCX1RPX0JCKG1wLAot CQkJCQkJTUFYKDEsIFhGU19JTk9ERVNfUEVSX0NIVU5LLwotCQkJCQkJCWlu b2Rlc19wZXJfYmxvY2spKTsKLQkJCQkJYnAgPSBsaWJ4ZnNfcmVhZGJ1Ziht cC0+bV9kZXYsCi0JCQkJCQlYRlNfQUdCX1RPX0RBRERSKG1wLCBhZ25vLAot CQkJCQkJCVhGU19BR0lOT19UT19BR0JOTyhtcCwKLQkJCQkJCQkJaXJlYy0+ aW5vX3N0YXJ0bnVtKSksCi0JCQkJCQlsZW4sIDApOwotCQkJCQlpZiAoIWJw KQotCQkJCQkJZG9fZXJyb3IoCi0JCQkJCV8oImNvdWxkbid0IHJlYWQgJXMg aW5vZGUgJWxsdVxuIiksCi0JCQkJCQkJT1JQSEFOQUdFLCBsaW5vKTsKLQot CQkJCQkvKgotCQkJCQkgKiBnZXQgdGhlIGFnYm5vIGNvbnRhaW5pbmcgdGhl IGZpcnN0Ci0JCQkJCSAqIGlub2RlIGluIHRoZSBjaHVuay4gIEluIG11bHRp LWJsb2NrCi0JCQkJCSAqIGNodW5rcywgdGhpcyBnZXRzIHVzIHRoZSBvZmZz ZXQKLQkJCQkJICogcmVsYXRpdmUgdG8gdGhlIGJlZ2lubmluZyBvZiBhCi0J CQkJCSAqIHByb3Blcmx5IGFsaWduZWQgYnVmZmVyLiAgSW4KLQkJCQkJICog bXVsdGktY2h1bmsgYmxvY2tzLCB0aGlzIGdldHMgdXMKLQkJCQkJICogdGhl IGNvcnJlY3QgYmxvY2sgbnVtYmVyLiAgVGhlbgotCQkJCQkgKiB0dXJuIHRo ZSBibG9jayBudW1iZXIgYmFjayBpbnRvCi0JCQkJCSAqIGFuIGFnaW5vIGFu ZCBjYWxjdWxhdGUgdGhlIG9mZnNldAotCQkJCQkgKiBmcm9tIHRoZXJlIHRv IGZlZWQgdG8gbWFrZSB0aGUgaXB0ci4KLQkJCQkJICogdGhlIGxhc3QgdGVy bSBpbiBlZmZlY3Qgcm91bmRzIGRvd24KLQkJCQkJICogdG8gdGhlIGZpcnN0 IGFnaW5vIGluIHRoZSBidWZmZXIuCi0JCQkJCSAqLwotCQkJCQlkaW5vID0g WEZTX01BS0VfSVBUUihtcCwgYnAsCi0JCQkJCQlhZ2lubyAtIFhGU19PRkZC Tk9fVE9fQUdJTk8obXAsCi0JCQkJCQkJWEZTX0FHSU5PX1RPX0FHQk5PKG1w LAotCQkJCQkJCWlyZWMtPmlub19zdGFydG51bSksCi0JCQkJCQkJMCkpOwot CQkJCX0KLQotCQkJCWRvX3dhcm4oCi0JCQlfKCIgICAgICAgIC0gY2xlYXJp bmcgZXhpc3RpbmcgXCIlc1wiIGlub2RlXG4iKSwKLQkJCQkJT1JQSEFOQUdF KTsKLQotCQkJCWlub19kaXJ0eSA9IGNsZWFyX2Rpbm9kZShtcCwgZGlubywg bGlubyk7Ci0KLQkJCQlpZiAoIXVzZV9yYnVmKSAgewotCQkJCQlBU1NFUlQo aW5vX2RpcnR5ID09IDAgfHwKLQkJCQkJCShpbm9fZGlydHkgJiYgIW5vX21v ZGlmeSkpOwotCi0JCQkJCWlmIChpbm9fZGlydHkgJiYgIW5vX21vZGlmeSkK LQkJCQkJCWxpYnhmc193cml0ZWJ1ZihicCwgMCk7Ci0JCQkJCWVsc2UKLQkJ CQkJCWxpYnhmc19wdXRidWYoYnApOwotCQkJCX0gZWxzZSAgewotCQkJCQlp ZiAoaW5vX2RpcnR5KQotCQkJCQkJKnJidWZfZGlydHkgPSAxOwotCQkJCX0K LQotCQkJCWlmIChpbm9kZV9pc2FkaXIoaXJlYywgaW5vX29mZnNldCkpCi0J CQkJCWNsZWFyX2lub2RlX2lzYWRpcihpcmVjLCBpbm9fb2Zmc2V0KTsKLQot CQkJCXNldF9pbm9kZV9mcmVlKGlyZWMsIGlub19vZmZzZXQpOwotCQkJfQot Ci0JCQkvKgotCQkJICogcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBpbm9k ZSBudW0gaXMgZ29vZCBvcgotCQkJICogYmFkLCBtYXJrIHRoZSBlbnRyeSB0 byBiZSBqdW5rZWQgc28gdGhlCi0JCQkgKiBjcmVhdGVuYW1lIGluIHBoYXNl IDYgd2lsbCBzdWNjZWVkLgotCQkJICovCi0JCQluYW1lc3QtPm5hbWVbMF0g PSAnLyc7Ci0JCQkqZGlydHkgPSAxOwotCQkJZG9fd2FybigKLQkJCV8oIiAg ICAgICAgLSBtYXJraW5nIGVudHJ5IFwiJXNcIiB0byBiZSBkZWxldGVkXG4i KSwKLQkJCQlmbmFtZSk7Ci0JCQlyZXMrKzsKLQkJfQotCX0KLQotCXJldHVy bihyZXMpOwotfQotCi1pbnQKLWxvbmdmb3JtX2RlbGV0ZV9vcnBoYW5hZ2Uo eGZzX21vdW50X3QJKm1wLAotCQkJeGZzX2lub190CWlubywKLQkJCXhmc19k aW5vZGVfdAkqZGlubywKLQkJCXhmc19idWZfdAkqcm9vdGlub19icCwKLQkJ CWludAkJKnJidWZfZGlydHkpCi17Ci0JeGZzX2Rpcl9sZWFmYmxvY2tfdAkq bGVhZjsKLQl4ZnNfYnVmX3QJCSpicDsKLQl4ZnNfZGZzYm5vX3QJCWZzYm5v OwotCXhmc19kYWJsa190CQlkYV9ibm87Ci0JaW50CQkJZGlydHk7Ci0JaW50 CQkJcmVzOwotCi0JZGFfYm5vID0gMDsKLQkqcmJ1Zl9kaXJ0eSA9IDA7Ci0K LQlpZiAoKGZzYm5vID0gZ2V0X2ZpcnN0X2RibG9ja19mc2JubyhtcCwgaW5v LCBkaW5vKSkgPT0gTlVMTERGU0JOTykKLQkJZG9fZXJyb3IoCi0JXygiY291 bGRuJ3QgbWFwIGZpcnN0IGxlYWYgYmxvY2sgb2YgZGlyZWN0b3J5IGlub2Rl ICVsbHVcbiIpLCBpbm8pOwotCi0JLyoKLQkgKiBjeWNsZSB0aHJvdWdoIHRo ZSBlbnRpcmUgZGlyZWN0b3J5IGxvb2tpbmcgdG8gZGVsZXRlCi0JICogZXZl cnkgImxvc3QrZm91bmQiIGVudHJ5LiAgbWFrZSBzdXJlIHRvIGNhdGNoIGR1 cGxpY2F0ZQotCSAqIGVudHJpZXMuCi0JICoKLQkgKiBXZSBjb3VsZCBwcm9i YWJseSBzcGVlZCB0aGlzIHVwIGJ5IGRvaW5nIGEgc21hcnRlciBsb29rdXAK LQkgKiB0byBnZXQgdXMgdG8gdGhlIGZpcnN0IGJsb2NrIHRoYXQgY29udGFp bnMgdGhlIGhhc2h2YWx1ZQotCSAqIG9mICJsb3N0K2ZvdW5kIiBidXQgd2hh dCB0aGUgaGVjay4gIHRoYXQgd291bGQgcmVxdWlyZSBhCi0JICogZG91Ymxl IGxvb2t1cCBmb3IgZWFjaCBsZXZlbC4gIGFuZCBob3cgYmlnIGNhbiAnLycg Z2V0Pz8/Ci0JICogSXQncyBwcm9iYWJseSBub3Qgd29ydGggaXQuCi0JICov Ci0JcmVzID0gMDsKLQotCWRvIHsKLQkJaWYgKGZzYm5vID09IE5VTExERlNC Tk8pCi0JCQlicmVhazsKLQkJYnAgPSBsaWJ4ZnNfcmVhZGJ1ZihtcC0+bV9k ZXYsIFhGU19GU0JfVE9fREFERFIobXAsIGZzYm5vKSwKLQkJCQkJWEZTX0ZT Ql9UT19CQihtcCwgMSksIDApOwotCQlpZiAoIWJwKQotCQkJZG9fZXJyb3Io XygiY2FuJ3QgcmVhZCBibG9jayAldSAoZnNibm8gJWxsdSkgZm9yICIKLQkJ CQkgICAiZGlyZWN0b3J5IGlub2RlICVsbHVcbiIpLAotCQkJCWRhX2Jubywg ZnNibm8sIGlubyk7Ci0KLQkJbGVhZiA9ICh4ZnNfZGlyX2xlYWZibG9ja190 ICopWEZTX0JVRl9QVFIoYnApOwotCi0JCWlmIChJTlRfR0VUKGxlYWYtPmhk ci5pbmZvLm1hZ2ljLCBBUkNIX0NPTlZFUlQpICE9Ci0JCSAgICBYRlNfRElS X0xFQUZfTUFHSUMpCi0JCQlkb19lcnJvcihfKCJiYWQgbWFnaWMgIyAoMHgl eCkgZm9yIGRpcmVjdG9yeSAiCi0JCQkJImxlYWYgYmxvY2sgKGJubyAldSBm c2JubyAlbGx1KVxuIiksCi0JCQkJSU5UX0dFVChsZWFmLT5oZHIuaW5mby5t YWdpYywgQVJDSF9DT05WRVJUKSwKLQkJCQlkYV9ibm8sIGZzYm5vKTsKLQot CQlkYV9ibm8gPSBJTlRfR0VUKGxlYWYtPmhkci5pbmZvLmZvcncsIEFSQ0hf Q09OVkVSVCk7Ci0KLQkJcmVzICs9IGxmX2Jsb2NrX2RlbGV0ZV9vcnBoYW5h Z2UobXAsIGlubywgbGVhZiwgJmRpcnR5LAotCQkJCQlyb290aW5vX2JwLCBy YnVmX2RpcnR5KTsKLQotCQlBU1NFUlQoZGlydHkgPT0gMCB8fCAoZGlydHkg JiYgIW5vX21vZGlmeSkpOwotCi0JCWlmIChkaXJ0eSAmJiAhbm9fbW9kaWZ5 KQotCQkJbGlieGZzX3dyaXRlYnVmKGJwLCAwKTsKLQkJZWxzZQotCQkJbGli eGZzX3B1dGJ1ZihicCk7Ci0KLQkJaWYgKGRhX2JubyAhPSAwKQotCQkJZnNi bm8gPSBnZXRfYm1hcGkobXAsIGRpbm8sIGlubywgZGFfYm5vLCBYRlNfREFU QV9GT1JLKTsKLQotCX0gd2hpbGUgKGRhX2JubyAhPSAwKTsKLQotCXJldHVy bihyZXMpOwotfQotCi0vKgotICogcmV0dXJucyAxIGlmIGEgZGVsZXRpb24g aGFwcGVuZWQsIDAgb3RoZXJ3aXNlLgotICovCi0vKiBBUkdTVVNFRCAqLwot aW50Ci1zaG9ydGZvcm1fZGVsZXRlX29ycGhhbmFnZSh4ZnNfbW91bnRfdAkq bXAsCi0JCQl4ZnNfaW5vX3QJaW5vLAotCQkJeGZzX2Rpbm9kZV90CSpyb290 X2Rpbm8sCi0JCQl4ZnNfYnVmX3QJKnJvb3Rpbm9fYnAsCi0JCQlpbnQJCSpp bm9fZGlydHkpCi17Ci0JeGZzX2Rpcl9zaG9ydGZvcm1fdAkqc2Y7Ci0JeGZz X2Rpbm9kZV90CQkqZGlubzsKLQl4ZnNfZGlyX3NmX2VudHJ5X3QJKnNmX2Vu dHJ5LCAqbmV4dF9zZmUsICp0bXBfc2ZlOwotCXhmc19idWZfdAkJKmJwOwot CXhmc19pbm9fdAkJbGlubzsKLQl4ZnNfYWdpbm9fdAkJYWdpbm87Ci0JeGZz X2FnaW5vX3QJCXJvb3RfYWdpbm87Ci0JaW50CQkJbWF4X3NpemU7Ci0JeGZz X2FnbnVtYmVyX3QJCWFnbm87Ci0JeGZzX2FnbnVtYmVyX3QJCXJvb3RfYWdu bzsKLQlpbnQJCQlpbm9fZGlyX3NpemU7Ci0JaW5vX3RyZWVfbm9kZV90CQkq aXJlYzsKLQlpbnQJCQlpbm9fb2Zmc2V0OwotCWludAkJCWk7Ci0JaW50CQkJ ZGlydHk7Ci0JaW50CQkJdG1wX2xlbjsKLQlpbnQJCQl0bXBfZWxlbjsKLQlp bnQJCQlsZW47Ci0JaW50CQkJdXNlX3JidWY7Ci0JY2hhcgkJCWZuYW1lW01B WE5BTUVMRU4gKyAxXTsKLQlpbnQJCQlyZXM7Ci0KLQlzZiA9ICZyb290X2Rp bm8tPmRpX3UuZGlfZGlyc2Y7Ci0JKmlub19kaXJ0eSA9IDA7Ci0JcmVzID0g MDsKLQlpcmVjID0gTlVMTDsKLQlpbm9fZGlyX3NpemUgPSBJTlRfR0VUKHJv b3RfZGluby0+ZGlfY29yZS5kaV9zaXplLCBBUkNIX0NPTlZFUlQpOwotCW1h eF9zaXplID0gWEZTX0RGT1JLX0RTSVpFKHJvb3RfZGlubywgbXApOwotCXVz ZV9yYnVmID0gMDsKLQlyb290X2Fnbm8gPSBYRlNfSU5PX1RPX0FHTk8obXAs IG1wLT5tX3NiLnNiX3Jvb3Rpbm8pOwotCXJvb3RfYWdpbm8gPSBYRlNfSU5P X1RPX0FHSU5PKG1wLCBtcC0+bV9zYi5zYl9yb290aW5vKTsKLQotCS8qCi0J ICogcnVuIHRocm91Z2ggZW50cmllcyBsb29raW5nIGZvciAibG9zdCtmb3Vu ZCIuCi0JICovCi0Jc2ZfZW50cnkgPSBuZXh0X3NmZSA9ICZzZi0+bGlzdFsw XTsKLQlmb3IgKGkgPSAwOyBpIDwgSU5UX0dFVChzZi0+aGRyLmNvdW50LCBB UkNIX0NPTlZFUlQpICYmIGlub19kaXJfc2l6ZSA+Ci0JCQkoX19wc2ludF90 KW5leHRfc2ZlIC0gKF9fcHNpbnRfdClzZjsgaSsrKSAgewotCQl0bXBfc2Zl ID0gTlVMTDsKLQkJc2ZfZW50cnkgPSBuZXh0X3NmZTsKLQkJWEZTX0RJUl9T Rl9HRVRfRElSSU5PKCZzZl9lbnRyeS0+aW51bWJlciwgJmxpbm8pOwotCQli Y29weShzZl9lbnRyeS0+bmFtZSwgZm5hbWUsIHNmX2VudHJ5LT5uYW1lbGVu KTsKLQkJZm5hbWVbc2ZfZW50cnktPm5hbWVsZW5dID0gJ1wwJzsKLQotCQlp ZiAoIXN0cmNtcChPUlBIQU5BR0UsIGZuYW1lKSkgIHsKLQkJCWFnbm8gPSBY RlNfSU5PX1RPX0FHTk8obXAsIGxpbm8pOwotCQkJYWdpbm8gPSBYRlNfSU5P X1RPX0FHSU5PKG1wLCBsaW5vKTsKLQotCQkJaXJlYyA9IGZpbmRfaW5vZGVf cmVjKGFnbm8sIGFnaW5vKTsKLQotCQkJLyoKLQkJCSAqIGlmIHRoZSBvcnBo YW5nZSBpbm9kZSBpcyBpbiB0aGUgdHJlZSwKLQkJCSAqIGdldCBpdCwgY2xl YXIgaXQsIGFuZCBtYXJrIGl0IGZyZWUuCi0JCQkgKiB0aGUgaW5vZGVzIGlu IHRoZSBvcnBoYW5hZ2Ugd2lsbCBnZXQKLQkJCSAqIHJlYXR0YWNoZWQgdG8g dGhlIG5ldyBvcnBoYW5hZ2UuCi0JCQkgKi8KLQkJCWlmIChpcmVjICE9IE5V TEwpIHsKLQkJCQlkb193YXJuKAotCQkJXygiICAgICAgICAtIGNsZWFyaW5n IGV4aXN0aW5nIFwiJXNcIiBpbm9kZVxuIiksCi0JCQkJCU9SUEhBTkFHRSk7 Ci0KLQkJCQlpbm9fb2Zmc2V0ID0gYWdpbm8gLSBpcmVjLT5pbm9fc3RhcnRu dW07Ci0KLQkJCQkvKgotCQkJCSAqIGNoZWNrIGlmIHdlIGhhdmUgdG8gdXNl IHRoZSByb290IGlub2RlCi0JCQkJICogYnVmZmVyIG9yIHJlYWQgb25lIGlu IG91cnNlbHZlcy4gIE5vdGUKLQkJCQkgKiB0aGF0IHRoZSByb290IGlub2Rl IGlzIGFsd2F5cyB0aGUgZmlyc3QKLQkJCQkgKiBpbm9kZSBvZiB0aGUgY2h1 bmsgdGhhdCBpdCdzIGluIHNvIHRoZXJlCi0JCQkJICogYXJlIHR3byBwb3Nz aWJsZSBjYXNlcyB3aGVyZSBsb3N0K2ZvdW5kCi0JCQkJICogbWlnaHQgYmUg aW4gdGhlIHNhbWUgYnVmZmVyIGFzIHRoZSByb290Ci0JCQkJICogaW5vZGUu ICBPbmUgY2FzZSBpcyBhIGxhcmdlIGJsb2NrCi0JCQkJICogZmlsZXN5c3Rl bSB3aGVyZSB0aGUgdHdvIGlub2RlcyBhcmUKLQkJCQkgKiBpbiBkaWZmZXJl bnQgaW5vZGUgY2h1bmtzIGJ1dCB3aW5kCi0JCQkJICogdXAgaW4gdGhlIHNh bWUgYmxvY2sgKG11bHRpcGxlIGNodW5rcwotCQkJCSAqIHBlciBibG9jaykg YW5kIHRoZSBzZWNvbmQgY2FzZSAob25lIG9yCi0JCQkJICogbW9yZSBibG9j a3MgcGVyIGNodW5rKSBpcyB3aGVyZSB0aGUgdHdvCi0JCQkJICogaW5vZGVz IGFyZSBpbiB0aGUgc2FtZSBjaHVuay4gTm90ZSB0aGF0Ci0JCQkJICogaW5v ZGVzIGFyZSBhbGxvY2F0ZWQgb24gZGlzayBpbiB1bml0cwotCQkJCSAqIG9m IE1BWChYRlNfSU5PREVTX1BFUl9DSFVOSyxzYl9pbm9wYmxvY2spLgotCQkJ CSAqLwotCQkJCWlmIChYRlNfSU5PX1RPX0ZTQihtcCwgbXAtPm1fc2Iuc2Jf cm9vdGlubykKLQkJCQkJCT09IFhGU19JTk9fVE9fRlNCKG1wLCBsaW5vKSB8 fAotCQkJCSAgICAoYWdubyA9PSByb290X2Fnbm8gJiYKLQkJCQkgICAgIGFn aW5vIDwgcm9vdF9hZ2lubyArIFhGU19JTk9ERVNfUEVSX0NIVU5LKSkgewot CQkJCQl1c2VfcmJ1ZiA9IDE7Ci0JCQkJCWJwID0gcm9vdGlub19icDsKLQot CQkJCQlkaW5vID0gWEZTX01BS0VfSVBUUihtcCwgYnAsIGFnaW5vIC0KLQkJ CQkJCVhGU19JTk9fVE9fQUdJTk8obXAsCi0JCQkJCQkJbXAtPm1fc2Iuc2Jf cm9vdGlubykpOwotCQkJCX0gZWxzZSB7Ci0JCQkJCWxlbiA9IChpbnQpWEZT X0ZTQl9UT19CQihtcCwKLQkJCQkJCU1BWCgxLCBYRlNfSU5PREVTX1BFUl9D SFVOSy8KLQkJCQkJCQlpbm9kZXNfcGVyX2Jsb2NrKSk7Ci0JCQkJCWJwID0g bGlieGZzX3JlYWRidWYobXAtPm1fZGV2LAotCQkJCQkJWEZTX0FHQl9UT19E QUREUihtcCwgYWdubywKLQkJCQkJCQlYRlNfQUdJTk9fVE9fQUdCTk8obXAs Ci0JCQkJCQkJCWlyZWMtPmlub19zdGFydG51bSkpLAotCQkJCQkJbGVuLCAw KTsKLQkJCQkJaWYgKCFicCkKLQkJCQkJCWRvX2Vycm9yKAotCQkJCQlfKCJj b3VsZCBub3QgcmVhZCAlcyBpbm9kZSAlbGx1XG4iKSwKLQkJCQkJCQlPUlBI QU5BR0UsIGxpbm8pOwotCi0JCQkJCS8qCi0JCQkJCSAqIGdldCB0aGUgYWdi bm8gY29udGFpbmluZyB0aGUgZmlyc3QKLQkJCQkJICogaW5vZGUgaW4gdGhl IGNodW5rLiAgSW4gbXVsdGktYmxvY2sKLQkJCQkJICogY2h1bmtzLCB0aGlz IGdldHMgdXMgdGhlIG9mZnNldAotCQkJCQkgKiByZWxhdGl2ZSB0byB0aGUg YmVnaW5uaW5nIG9mIGEKLQkJCQkJICogcHJvcGVybHkgYWxpZ25lZCBidWZm ZXIuICBJbgotCQkJCQkgKiBtdWx0aS1jaHVuayBibG9ja3MsIHRoaXMgZ2V0 cyB1cwotCQkJCQkgKiB0aGUgY29ycmVjdCBibG9jayBudW1iZXIuICBUaGVu Ci0JCQkJCSAqIHR1cm4gdGhlIGJsb2NrIG51bWJlciBiYWNrIGludG8KLQkJ CQkJICogYW4gYWdpbm8gYW5kIGNhbGN1bGF0ZSB0aGUgb2Zmc2V0Ci0JCQkJ CSAqIGZyb20gdGhlcmUgdG8gZmVlZCB0byBtYWtlIHRoZSBpcHRyLgotCQkJ CQkgKiB0aGUgbGFzdCB0ZXJtIGluIGVmZmVjdCByb3VuZHMgZG93bgotCQkJ CQkgKiB0byB0aGUgZmlyc3QgYWdpbm8gaW4gdGhlIGJ1ZmZlci4KLQkJCQkJ ICovCi0JCQkJCWRpbm8gPSBYRlNfTUFLRV9JUFRSKG1wLCBicCwKLQkJCQkJ CWFnaW5vIC0gWEZTX09GRkJOT19UT19BR0lOTyhtcCwKLQkJCQkJCQlYRlNf QUdJTk9fVE9fQUdCTk8obXAsCi0JCQkJCQkJaXJlYy0+aW5vX3N0YXJ0bnVt KSwKLQkJCQkJCQkwKSk7Ci0JCQkJfQotCi0JCQkJZGlydHkgPSBjbGVhcl9k aW5vZGUobXAsIGRpbm8sIGxpbm8pOwotCi0JCQkJQVNTRVJUKGRpcnR5ID09 IDAgfHwgKGRpcnR5ICYmICFub19tb2RpZnkpKTsKLQotCQkJCS8qCi0JCQkJ ICogaWYgd2UgcmVhZCB0aGUgbG9zdCtmb3VuZCBpbm9kZSBpbiB0bwotCQkJ CSAqIGl0LCBnZXQgcmlkIG9mIGl0IGhlcmUuICBpZiB0aGUgbG9zdCtmb3Vu ZAotCQkJCSAqIGlub2RlIGlzIGluIHRoZSByb290IGlub2RlIGJ1ZmZlciwg dGhlCi0JCQkJICogYnVmZmVyIHdpbGwgYmUgbWFya2VkIGRpcnR5IGFueXdh eSBzaW5jZQotCQkJCSAqIHRoZSBsb3N0K2ZvdW5kIGVudHJ5IGluIHRoZSBy b290IGlub2RlIGlzCi0JCQkJICogYWxzbyBiZWluZyBkZWxldGVkIHdoaWNo IG1ha2VzIHRoZSByb290Ci0JCQkJICogaW5vZGUgYnVmZmVyIGF1dG9tYXRp Y2FsbHkgZGlydHkuCi0JCQkJICovCi0JCQkJaWYgKCF1c2VfcmJ1ZikgIHsK LQkJCQkJZGlubyA9IE5VTEw7Ci0JCQkJCWlmIChkaXJ0eSAmJiAhbm9fbW9k aWZ5KQotCQkJCQkJbGlieGZzX3dyaXRlYnVmKGJwLCAwKTsKLQkJCQkJZWxz ZQotCQkJCQkJbGlieGZzX3B1dGJ1ZihicCk7Ci0JCQkJfQotCi0JCQkJaWYg KGlub2RlX2lzYWRpcihpcmVjLCBpbm9fb2Zmc2V0KSkKLQkJCQkJY2xlYXJf aW5vZGVfaXNhZGlyKGlyZWMsIGlub19vZmZzZXQpOwotCi0JCQkJc2V0X2lu b2RlX2ZyZWUoaXJlYywgaW5vX29mZnNldCk7Ci0JCQl9Ci0KLQkJCWRvX3dh cm4oXygiICAgICAgICAtIGRlbGV0aW5nIGV4aXN0aW5nIFwiJXNcIiBlbnRy eVxuIiksCi0JCQkJT1JQSEFOQUdFKTsKLQotCQkJLyoKLQkJCSAqIG5vdGUg LS0gZXhhY3RseSB0aGUgc2FtZSBkZWxldGlvbiBjb2RlIGFzIGluCi0JCQkg KiBwcm9jZXNzX3Nob3J0Zm9ybV9kaXIoKQotCQkJICovCi0JCQl0bXBfZWxl biA9IFhGU19ESVJfU0ZfRU5UU0laRV9CWUVOVFJZKHNmX2VudHJ5KTsKLQkJ CUlOVF9NT0Qocm9vdF9kaW5vLT5kaV9jb3JlLmRpX3NpemUsIEFSQ0hfQ09O VkVSVCwKLQkJCQktKHRtcF9lbGVuKSk7Ci0KLQkJCXRtcF9zZmUgPSAoeGZz X2Rpcl9zZl9lbnRyeV90ICopCi0JCQkJKChfX3BzaW50X3QpIHNmX2VudHJ5 ICsgdG1wX2VsZW4pOwotCQkJdG1wX2xlbiA9IG1heF9zaXplIC0gKChfX3Bz aW50X3QpIHRtcF9zZmUKLQkJCQkJLSAoX19wc2ludF90KSBzZik7Ci0KLQkJ CW1lbW1vdmUoc2ZfZW50cnksIHRtcF9zZmUsIHRtcF9sZW4pOwotCi0JCQlJ TlRfTU9EKHNmLT5oZHIuY291bnQsIEFSQ0hfQ09OVkVSVCwgLTEpOwotCi0J CQliemVybygodm9pZCAqKSAoKF9fcHNpbnRfdCkgc2ZfZW50cnkgKyB0bXBf bGVuKSwKLQkJCQl0bXBfZWxlbik7Ci0KLQkJCS8qCi0JCQkgKiBzZXQgdGhl IHRtcCB2YWx1ZSB0byB0aGUgY3VycmVudAotCQkJICogcG9pbnRlciBzbyB3 ZSdsbCBwcm9jZXNzIHRoZSBlbnRyeQotCQkJICogd2UganVzdCBtb3ZlZCB1 cAotCQkJICovCi0JCQl0bXBfc2ZlID0gc2ZfZW50cnk7Ci0KLQkJCS8qCi0J CQkgKiBXQVJOSU5HOiAgZHJvcCB0aGUgaW5kZXggaSBieSBvbmUKLQkJCSAq IHNvIGl0IG1hdGNoZXMgdGhlIGRlY3JlbWVudGVkIGNvdW50IGZvcgotCQkJ ICogYWNjdXJhdGUgY29tcGFyaXNvbnMgaW4gdGhlIGxvb3AgdGVzdC4KLQkJ CSAqIG1hcmsgcm9vdCBpbm9kZSBhcyBkaXJ0eSB0byBtYWtlIGRlbGV0aW9u Ci0JCQkgKiBwZXJtYW5lbnQuCi0JCQkgKi8KLQkJCWktLTsKLQotCQkJKmlu b19kaXJ0eSA9IDE7Ci0JCQlyZXMrKzsKLQotCQl9Ci0JCW5leHRfc2ZlID0g KHRtcF9zZmUgPT0gTlVMTCkKLQkJCT8gKHhmc19kaXJfc2ZfZW50cnlfdCAq KSAoKF9fcHNpbnRfdCkgc2ZfZW50cnkgKwotCQkJCVhGU19ESVJfU0ZfRU5U U0laRV9CWUVOVFJZKHNmX2VudHJ5KSkKLQkJCTogdG1wX3NmZTsKLQl9Ci0K LQlyZXR1cm4ocmVzKTsKLX0KLQotLyogQVJHU1VTRUQgKi8KLWludAotbGYy X2Jsb2NrX2RlbGV0ZV9vcnBoYW5hZ2UoeGZzX21vdW50X3QJCSptcCwKLQkJ CXhmc19pbm9fdAkJaW5vLAotCQkJeGZzX2RpcjJfZGF0YV90CQkqZGF0YSwK LQkJCWludAkJCSpkaXJ0eSwKLQkJCXhmc19idWZfdAkJKnJvb3Rpbm9fYnAs Ci0JCQlpbnQJCQkqcmJ1Zl9kaXJ0eSkKLXsKLQl4ZnNfZGlub2RlX3QJCSpk aW5vOwotCXhmc19idWZfdAkJKmJwOwotCWlub190cmVlX25vZGVfdAkJKmly ZWM7Ci0JeGZzX2lub190CQlsaW5vOwotCXhmc19hZ2lub190CQlhZ2lubzsK LQl4ZnNfYWdudW1iZXJfdAkJYWdubzsKLQl4ZnNfYWdpbm9fdAkJcm9vdF9h Z2lubzsKLQl4ZnNfYWdudW1iZXJfdAkJcm9vdF9hZ25vOwotCWludAkJCWlu b19vZmZzZXQ7Ci0JaW50CQkJaW5vX2RpcnR5OwotCWludAkJCXVzZV9yYnVm OwotCWludAkJCWxlbjsKLQljaGFyCQkJZm5hbWVbTUFYTkFNRUxFTiArIDFd OwotCWludAkJCXJlczsKLQljaGFyCQkJKnB0cjsKLQljaGFyCQkJKmVuZHB0 cjsKLQl4ZnNfZGlyMl9ibG9ja190YWlsX3QJKmJ0cDsKLQl4ZnNfZGlyMl9k YXRhX2VudHJ5X3QJKmRlcDsKLQl4ZnNfZGlyMl9kYXRhX3VudXNlZF90CSpk dXA7Ci0KLQlwdHIgPSAoY2hhciAqKWRhdGEtPnU7Ci0JaWYgKElOVF9HRVQo ZGF0YS0+aGRyLm1hZ2ljLCBBUkNIX0NPTlZFUlQpID09IFhGU19ESVIyX0JM T0NLX01BR0lDKSB7Ci0JCWJ0cCA9IFhGU19ESVIyX0JMT0NLX1RBSUxfUCht cCwgKHhmc19kaXIyX2Jsb2NrX3QgKilkYXRhKTsKLQkJZW5kcHRyID0gKGNo YXIgKilYRlNfRElSMl9CTE9DS19MRUFGX1AoYnRwKTsKLQl9IGVsc2UKLQkJ ZW5kcHRyID0gKGNoYXIgKilkYXRhICsgbXAtPm1fZGlyYmxrc2l6ZTsKLQkq ZGlydHkgPSAwOwotCXVzZV9yYnVmID0gMDsKLQlyZXMgPSAwOwotCXJvb3Rf YWdubyA9IFhGU19JTk9fVE9fQUdOTyhtcCwgbXAtPm1fc2Iuc2Jfcm9vdGlu byk7Ci0Jcm9vdF9hZ2lubyA9IFhGU19JTk9fVE9fQUdJTk8obXAsIG1wLT5t X3NiLnNiX3Jvb3Rpbm8pOwotCi0Jd2hpbGUgKHB0ciA8IGVuZHB0cikgewot CQlkdXAgPSAoeGZzX2RpcjJfZGF0YV91bnVzZWRfdCAqKXB0cjsKLQkJaWYg KElOVF9HRVQoZHVwLT5mcmVldGFnLCBBUkNIX0NPTlZFUlQpID09Ci0JCSAg ICBYRlNfRElSMl9EQVRBX0ZSRUVfVEFHKSB7Ci0JCQlpZiAocHRyICsgSU5U X0dFVChkdXAtPmxlbmd0aCwgQVJDSF9DT05WRVJUKSA+IGVuZHB0ciB8fAot CQkJCUlOVF9HRVQoZHVwLT5sZW5ndGgsIEFSQ0hfQ09OVkVSVCkgPT0gMCB8 fAotCQkJCShJTlRfR0VUKGR1cC0+bGVuZ3RoLCBBUkNIX0NPTlZFUlQpICYK LQkJCQkJCShYRlNfRElSMl9EQVRBX0FMSUdOIC0gMSkpKQotCQkJCWJyZWFr OwotCQkJcHRyICs9IElOVF9HRVQoZHVwLT5sZW5ndGgsIEFSQ0hfQ09OVkVS VCk7Ci0JCQljb250aW51ZTsKLQkJfQotCQlkZXAgPSAoeGZzX2RpcjJfZGF0 YV9lbnRyeV90ICopcHRyOwotCQlsaW5vID0gSU5UX0dFVChkZXAtPmludW1i ZXIsIEFSQ0hfQ09OVkVSVCk7Ci0JCWJjb3B5KGRlcC0+bmFtZSwgZm5hbWUs IGRlcC0+bmFtZWxlbik7Ci0JCWZuYW1lW2RlcC0+bmFtZWxlbl0gPSAnXDAn OwotCi0JCWlmIChmbmFtZVswXSAhPSAnLycgJiYgIXN0cmNtcChmbmFtZSwg T1JQSEFOQUdFKSkgIHsKLQkJCWFnaW5vID0gWEZTX0lOT19UT19BR0lOTyht cCwgbGlubyk7Ci0JCQlhZ25vID0gWEZTX0lOT19UT19BR05PKG1wLCBsaW5v KTsKLQotCQkJb2xkX29ycGhhbmFnZV9pbm8gPSBsaW5vOwotCi0JCQlpcmVj ID0gZmluZF9pbm9kZV9yZWMoYWdubywgYWdpbm8pOwotCi0JCQkvKgotCQkJ ICogaWYgdGhlIG9ycGhhbmdlIGlub2RlIGlzIGluIHRoZSB0cmVlLAotCQkJ ICogZ2V0IGl0LCBjbGVhciBpdCwgYW5kIG1hcmsgaXQgZnJlZS4KLQkJCSAq IHRoZSBpbm9kZXMgaW4gdGhlIG9ycGhhbmFnZSB3aWxsIGdldAotCQkJICog cmVhdHRhY2hlZCB0byB0aGUgbmV3IG9ycGhhbmFnZS4KLQkJCSAqLwotCQkJ aWYgKGlyZWMgIT0gTlVMTCkgIHsKLQkJCQlpbm9fb2Zmc2V0ID0gYWdpbm8g LSBpcmVjLT5pbm9fc3RhcnRudW07Ci0KLQkJCQkvKgotCQkJCSAqIGNoZWNr IGlmIHdlIGhhdmUgdG8gdXNlIHRoZSByb290IGlub2RlCi0JCQkJICogYnVm ZmVyIG9yIHJlYWQgb25lIGluIG91cnNlbHZlcy4gIE5vdGUKLQkJCQkgKiB0 aGF0IHRoZSByb290IGlub2RlIGlzIGFsd2F5cyB0aGUgZmlyc3QKLQkJCQkg KiBpbm9kZSBvZiB0aGUgY2h1bmsgdGhhdCBpdCdzIGluIHNvIHRoZXJlCi0J CQkJICogYXJlIHR3byBwb3NzaWJsZSBjYXNlcyB3aGVyZSBsb3N0K2ZvdW5k Ci0JCQkJICogbWlnaHQgYmUgaW4gdGhlIHNhbWUgYnVmZmVyIGFzIHRoZSBy b290Ci0JCQkJICogaW5vZGUuICBPbmUgY2FzZSBpcyBhIGxhcmdlIGJsb2Nr Ci0JCQkJICogZmlsZXN5c3RlbSB3aGVyZSB0aGUgdHdvIGlub2RlcyBhcmUK LQkJCQkgKiBpbiBkaWZmZXJlbnQgaW5vZGUgY2h1bmtzIGJ1dCB3aW5kCi0J CQkJICogdXAgaW4gdGhlIHNhbWUgYmxvY2sgKG11bHRpcGxlIGNodW5rcwot CQkJCSAqIHBlciBibG9jaykgYW5kIHRoZSBzZWNvbmQgY2FzZSAob25lIG9y Ci0JCQkJICogbW9yZSBibG9ja3MgcGVyIGNodW5rKSBpcyB3aGVyZSB0aGUg dHdvCi0JCQkJICogaW5vZGVzIGFyZSBpbiB0aGUgc2FtZSBjaHVuay4gTm90 ZSB0aGF0Ci0JCQkJICogaW5vZGVzIGFyZSBhbGxvY2F0ZWQgb24gZGlzayBp biB1bml0cwotCQkJCSAqIG9mIE1BWChYRlNfSU5PREVTX1BFUl9DSFVOSyxz Yl9pbm9wYmxvY2spLgotCQkJCSAqLwotCQkJCWlmIChYRlNfSU5PX1RPX0ZT QihtcCwgbXAtPm1fc2Iuc2Jfcm9vdGlubykKLQkJCQkJCT09IFhGU19JTk9f VE9fRlNCKG1wLCBsaW5vKSB8fAotCQkJCSAgICAoYWdubyA9PSByb290X2Fn bm8gJiYKLQkJCQkgICAgIGFnaW5vIDwgcm9vdF9hZ2lubyArIFhGU19JTk9E RVNfUEVSX0NIVU5LKSkgewotCQkJCQl1c2VfcmJ1ZiA9IDE7Ci0JCQkJCWJw ID0gcm9vdGlub19icDsKLQkJCQkJZGlubyA9IFhGU19NQUtFX0lQVFIobXAs IGJwLCBhZ2lubyAtCi0JCQkJCQlYRlNfSU5PX1RPX0FHSU5PKG1wLAotCQkJ CQkJCW1wLT5tX3NiLnNiX3Jvb3Rpbm8pKTsKLQkJCQl9IGVsc2UgIHsKLQkJ CQkJbGVuID0gKGludClYRlNfRlNCX1RPX0JCKG1wLAotCQkJCQkJTUFYKDEs IFhGU19JTk9ERVNfUEVSX0NIVU5LLwotCQkJCQkJCWlub2Rlc19wZXJfYmxv Y2spKTsKLQkJCQkJYnAgPSBsaWJ4ZnNfcmVhZGJ1ZihtcC0+bV9kZXYsCi0J CQkJCQlYRlNfQUdCX1RPX0RBRERSKG1wLCBhZ25vLAotCQkJCQkJCVhGU19B R0lOT19UT19BR0JOTyhtcCwKLQkJCQkJCQkJaXJlYy0+aW5vX3N0YXJ0bnVt KSksCi0JCQkJCQlsZW4sIDApOwotCQkJCQlpZiAoIWJwKQotCQkJCQkJZG9f ZXJyb3IoCi0JCQkJCV8oImNvdWxkbid0IHJlYWQgJXMgaW5vZGUgJWxsdVxu IiksCi0JCQkJCQkJT1JQSEFOQUdFLCBsaW5vKTsKLQotCQkJCQkvKgotCQkJ CQkgKiBnZXQgdGhlIGFnYm5vIGNvbnRhaW5pbmcgdGhlIGZpcnN0Ci0JCQkJ CSAqIGlub2RlIGluIHRoZSBjaHVuay4gIEluIG11bHRpLWJsb2NrCi0JCQkJ CSAqIGNodW5rcywgdGhpcyBnZXRzIHVzIHRoZSBvZmZzZXQKLQkJCQkJICog cmVsYXRpdmUgdG8gdGhlIGJlZ2lubmluZyBvZiBhCi0JCQkJCSAqIHByb3Bl cmx5IGFsaWduZWQgYnVmZmVyLiAgSW4KLQkJCQkJICogbXVsdGktY2h1bmsg YmxvY2tzLCB0aGlzIGdldHMgdXMKLQkJCQkJICogdGhlIGNvcnJlY3QgYmxv Y2sgbnVtYmVyLiAgVGhlbgotCQkJCQkgKiB0dXJuIHRoZSBibG9jayBudW1i ZXIgYmFjayBpbnRvCi0JCQkJCSAqIGFuIGFnaW5vIGFuZCBjYWxjdWxhdGUg dGhlIG9mZnNldAotCQkJCQkgKiBmcm9tIHRoZXJlIHRvIGZlZWQgdG8gbWFr ZSB0aGUgaXB0ci4KLQkJCQkJICogdGhlIGxhc3QgdGVybSBpbiBlZmZlY3Qg cm91bmRzIGRvd24KLQkJCQkJICogdG8gdGhlIGZpcnN0IGFnaW5vIGluIHRo ZSBidWZmZXIuCi0JCQkJCSAqLwotCQkJCQlkaW5vID0gWEZTX01BS0VfSVBU UihtcCwgYnAsCi0JCQkJCQlhZ2lubyAtIFhGU19PRkZCTk9fVE9fQUdJTk8o bXAsCi0JCQkJCQkJWEZTX0FHSU5PX1RPX0FHQk5PKG1wLAotCQkJCQkJCWly ZWMtPmlub19zdGFydG51bSksCi0JCQkJCQkJMCkpOwotCQkJCX0KLQotCQkJ CWRvX3dhcm4oCi0JCQkJXygiICAgICAgICAtIGNsZWFyaW5nIGV4aXN0aW5n IFwiJXNcIiBpbm9kZVxuIiksCi0JCQkJCU9SUEhBTkFHRSk7Ci0KLQkJCQlp bm9fZGlydHkgPSBjbGVhcl9kaW5vZGUobXAsIGRpbm8sIGxpbm8pOwotCi0J CQkJaWYgKCF1c2VfcmJ1ZikgewotCQkJCQlBU1NFUlQoaW5vX2RpcnR5ID09 IDAgfHwKLQkJCQkJCShpbm9fZGlydHkgJiYgIW5vX21vZGlmeSkpOwotCi0J CQkJCWlmIChpbm9fZGlydHkgJiYgIW5vX21vZGlmeSkKLQkJCQkJCWxpYnhm c193cml0ZWJ1ZihicCwgMCk7Ci0JCQkJCWVsc2UKLQkJCQkJCWxpYnhmc19w dXRidWYoYnApOwotCQkJCX0gZWxzZSB7Ci0JCQkJCWlmIChpbm9fZGlydHkp Ci0JCQkJCQkqcmJ1Zl9kaXJ0eSA9IDE7Ci0JCQkJfQotCi0JCQkJaWYgKGlu b2RlX2lzYWRpcihpcmVjLCBpbm9fb2Zmc2V0KSkKLQkJCQkJY2xlYXJfaW5v ZGVfaXNhZGlyKGlyZWMsIGlub19vZmZzZXQpOwotCi0JCQkJc2V0X2lub2Rl X2ZyZWUoaXJlYywgaW5vX29mZnNldCk7Ci0KLQkJCX0KLQotCQkJLyoKLQkJ CSAqIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgaW5vZGUgbnVtIGlzIGdv b2Qgb3IKLQkJCSAqIGJhZCwgbWFyayB0aGUgZW50cnkgdG8gYmUganVua2Vk IHNvIHRoZQotCQkJICogY3JlYXRlbmFtZSBpbiBwaGFzZSA2IHdpbGwgc3Vj Y2VlZC4KLQkJCSAqLwotCQkJZGVwLT5uYW1lWzBdID0gJy8nOwotCQkJKmRp cnR5ID0gMTsKLQkJCWRvX3dhcm4oCi0JCQlfKCIgICAgICAgIC0gbWFya2lu ZyBlbnRyeSBcIiVzXCIgdG8gYmUgZGVsZXRlZFxuIiksCi0JCQkJZm5hbWUp OwotCQkJcmVzKys7Ci0JCX0KLQkJcHRyICs9IFhGU19ESVIyX0RBVEFfRU5U U0laRShkZXAtPm5hbWVsZW4pOwotCX0KLQotCXJldHVybihyZXMpOwotfQot Ci1pbnQKLWxvbmdmb3JtMl9kZWxldGVfb3JwaGFuYWdlKHhmc19tb3VudF90 CSptcCwKLQkJCXhmc19pbm9fdAlpbm8sCi0JCQl4ZnNfZGlub2RlX3QJKmRp bm8sCi0JCQl4ZnNfYnVmX3QJKnJvb3Rpbm9fYnAsCi0JCQlpbnQJCSpyYnVm X2RpcnR5KQotewotCXhmc19kaXIyX2RhdGFfdAkJKmRhdGE7Ci0JeGZzX2Rh YnVmX3QJCSpicDsKLQl4ZnNfZGZzYm5vX3QJCWZzYm5vOwotCXhmc19kYWJs a190CQlkYV9ibm87Ci0JaW50CQkJZGlydHk7Ci0JaW50CQkJcmVzOwotCWJt YXBfZXh0X3QJCSpibXA7Ci0JaW50CQkJaTsKLQotCWRhX2JubyA9IDA7Ci0J KnJidWZfZGlydHkgPSAwOwotCWZzYm5vID0gTlVMTERGU0JOTzsKLQlibXAg PSBtYWxsb2MobXAtPm1fZGlyYmxrZnNicyAqIHNpemVvZigqYm1wKSk7Ci0J aWYgKCFibXApCi0JCWRvX2Vycm9yKAotCV8oIm1hbGxvYyBmYWlsZWQgKCV1 IGJ5dGVzKSBpbiBsb25nZm9ybTJfZGVsZXRlX29ycGhhbmFnZSwgaW5vICVs bHVcbiIpLAotCQkJbXAtPm1fZGlyYmxrZnNicyAqIHNpemVvZigqYm1wKSwg aW5vKTsKLQotCS8qCi0JICogY3ljbGUgdGhyb3VnaCB0aGUgZW50aXJlIGRp cmVjdG9yeSBsb29raW5nIHRvIGRlbGV0ZQotCSAqIGV2ZXJ5ICJsb3N0K2Zv dW5kIiBlbnRyeS4gIG1ha2Ugc3VyZSB0byBjYXRjaCBkdXBsaWNhdGUKLQkg KiBlbnRyaWVzLgotCSAqCi0JICogV2UgY291bGQgcHJvYmFibHkgc3BlZWQg dGhpcyB1cCBieSBkb2luZyBhIHNtYXJ0ZXIgbG9va3VwCi0JICogdG8gZ2V0 IHVzIHRvIHRoZSBmaXJzdCBibG9jayB0aGF0IGNvbnRhaW5zIHRoZSBoYXNo dmFsdWUKLQkgKiBvZiAibG9zdCtmb3VuZCIgYnV0IHdoYXQgdGhlIGhlY2su ICB0aGF0IHdvdWxkIHJlcXVpcmUgYQotCSAqIGRvdWJsZSBsb29rdXAgZm9y IGVhY2ggbGV2ZWwuICBhbmQgaG93IGJpZyBjYW4gJy8nIGdldD8/PwotCSAq IEl0J3MgcHJvYmFibHkgbm90IHdvcnRoIGl0LgotCSAqLwotCXJlcyA9IDA7 Ci0KLQlmb3IgKGRhX2JubyA9IDA7Ci0JICAgICBkYV9ibm8gPCBYRlNfQl9U T19GU0IobXAsIElOVF9HRVQoZGluby0+ZGlfY29yZS5kaV9zaXplLCBBUkNI X0NPTlZFUlQpKTsKLQkgICAgIGRhX2JubyArPSBtcC0+bV9kaXJibGtmc2Jz KSB7Ci0JCWZvciAoaSA9IDA7IGkgPCBtcC0+bV9kaXJibGtmc2JzOyBpKysp IHsKLQkJCWZzYm5vID0gZ2V0X2JtYXBpKG1wLCBkaW5vLCBpbm8sIGRhX2Ju byArIGksCi0JCQkJCSAgWEZTX0RBVEFfRk9SSyk7Ci0JCQlpZiAoZnNibm8g PT0gTlVMTERGU0JOTykKLQkJCQlicmVhazsKLQkJCWJtcFtpXS5zdGFydG9m ZiA9IGRhX2JubyArIGk7Ci0JCQlibXBbaV0uc3RhcnRibG9jayA9IGZzYm5v OwotCQkJYm1wW2ldLmJsb2NrY291bnQgPSAxOwotCQkJYm1wW2ldLmZsYWcg PSAwOwotCQl9Ci0JCWlmIChmc2JubyA9PSBOVUxMREZTQk5PKQotCQkJY29u dGludWU7Ci0JCWJwID0gZGFfcmVhZF9idWYobXAsIG1wLT5tX2RpcmJsa2Zz YnMsIGJtcCk7Ci0JCWlmIChicCA9PSBOVUxMKQotCQkJZG9fZXJyb3IoCi0J XygiY2FuJ3QgcmVhZCBibG9jayAldSAoZnNibm8gJWxsdSkgZm9yIGRpcmVj dG9yeSBpbm9kZSAlbGx1XG4iKSwKLQkJCQlkYV9ibm8sIGJtcFswXS5zdGFy dGJsb2NrLCBpbm8pOwotCi0JCWRhdGEgPSAoeGZzX2RpcjJfZGF0YV90ICop YnAtPmRhdGE7Ci0KLQkJaWYgKElOVF9HRVQoZGF0YS0+aGRyLm1hZ2ljLCBB UkNIX0NPTlZFUlQpICE9Ci0JCQkJCVhGU19ESVIyX0RBVEFfTUFHSUMgJiYK LQkJICAgIElOVF9HRVQoZGF0YS0+aGRyLm1hZ2ljLCBBUkNIX0NPTlZFUlQp ICE9Ci0JCQkJCVhGU19ESVIyX0JMT0NLX01BR0lDKQotCQkJZG9fZXJyb3Io Ci0JXygiYmFkIG1hZ2ljICMgKDB4JXgpIGZvciBkaXJlY3RvcnkgZGF0YSBi bG9jayAoYm5vICV1IGZzYm5vICVsbHUpXG4iKSwKLQkJCQlJTlRfR0VUKGRh dGEtPmhkci5tYWdpYywgQVJDSF9DT05WRVJUKSwKLQkJCQlkYV9ibm8sIGJt cFswXS5zdGFydGJsb2NrKTsKLQotCQlyZXMgKz0gbGYyX2Jsb2NrX2RlbGV0 ZV9vcnBoYW5hZ2UobXAsIGlubywgZGF0YSwgJmRpcnR5LAotCQkJCQlyb290 aW5vX2JwLCByYnVmX2RpcnR5KTsKLQotCQlBU1NFUlQoZGlydHkgPT0gMCB8 fCAoZGlydHkgJiYgIW5vX21vZGlmeSkpOwotCi0JCWlmIChkaXJ0eSAmJiAh bm9fbW9kaWZ5KQotCQkJZGFfYndyaXRlKG1wLCBicCk7Ci0JCWVsc2UKLQkJ CWRhX2JyZWxzZShicCk7Ci0JfQotCWZyZWUoYm1wKTsKLQotCXJldHVybihy ZXMpOwotfQotCi0vKgotICogcmV0dXJucyAxIGlmIGEgZGVsZXRpb24gaGFw cGVuZWQsIDAgb3RoZXJ3aXNlLgotICovCi0vKiBBUkdTVVNFRCAqLwotaW50 Ci1zaG9ydGZvcm0yX2RlbGV0ZV9vcnBoYW5hZ2UoeGZzX21vdW50X3QJKm1w LAotCQkJeGZzX2lub190CWlubywKLQkJCXhmc19kaW5vZGVfdAkqcm9vdF9k aW5vLAotCQkJeGZzX2J1Zl90CSpyb290aW5vX2JwLAotCQkJaW50CQkqaW5v X2RpcnR5KQotewotCXhmc19kaXIyX3NmX3QJCSpzZjsKLQl4ZnNfZGlub2Rl X3QJCSpkaW5vOwotCXhmc19kaXIyX3NmX2VudHJ5X3QJKnNmX2VudHJ5LCAq bmV4dF9zZmUsICp0bXBfc2ZlOwotCXhmc19idWZfdAkJKmJwOwotCXhmc19p bm9fdAkJbGlubzsKLQl4ZnNfYWdpbm9fdAkJYWdpbm87Ci0JeGZzX2FnaW5v X3QJCXJvb3RfYWdpbm87Ci0JaW50CQkJbWF4X3NpemU7Ci0JeGZzX2FnbnVt YmVyX3QJCWFnbm87Ci0JeGZzX2FnbnVtYmVyX3QJCXJvb3RfYWdubzsKLQlp bnQJCQlpbm9fZGlyX3NpemU7Ci0JaW5vX3RyZWVfbm9kZV90CQkqaXJlYzsK LQlpbnQJCQlpbm9fb2Zmc2V0OwotCWludAkJCWk7Ci0JaW50CQkJZGlydHk7 Ci0JaW50CQkJdG1wX2xlbjsKLQlpbnQJCQl0bXBfZWxlbjsKLQlpbnQJCQls ZW47Ci0JaW50CQkJdXNlX3JidWY7Ci0JY2hhcgkJCWZuYW1lW01BWE5BTUVM RU4gKyAxXTsKLQlpbnQJCQlyZXM7Ci0KLQlzZiA9ICZyb290X2Rpbm8tPmRp X3UuZGlfZGlyMnNmOwotCSppbm9fZGlydHkgPSAwOwotCWlyZWMgPSBOVUxM OwotCWlub19kaXJfc2l6ZSA9IElOVF9HRVQocm9vdF9kaW5vLT5kaV9jb3Jl LmRpX3NpemUsIEFSQ0hfQ09OVkVSVCk7Ci0JbWF4X3NpemUgPSBYRlNfREZP UktfRFNJWkUocm9vdF9kaW5vLCBtcCk7Ci0JdXNlX3JidWYgPSAwOwotCXJl cyA9IDA7Ci0Jcm9vdF9hZ25vID0gWEZTX0lOT19UT19BR05PKG1wLCBtcC0+ bV9zYi5zYl9yb290aW5vKTsKLQlyb290X2FnaW5vID0gWEZTX0lOT19UT19B R0lOTyhtcCwgbXAtPm1fc2Iuc2Jfcm9vdGlubyk7Ci0KLQkvKgotCSAqIHJ1 biB0aHJvdWdoIGVudHJpZXMgbG9va2luZyBmb3IgImxvc3QrZm91bmQiLgot CSAqLwotCXNmX2VudHJ5ID0gbmV4dF9zZmUgPSBYRlNfRElSMl9TRl9GSVJT VEVOVFJZKHNmKTsKLQlmb3IgKGkgPSAwOyBpIDwgSU5UX0dFVChzZi0+aGRy LmNvdW50LCBBUkNIX0NPTlZFUlQpICYmIGlub19kaXJfc2l6ZSA+Ci0JCQko X19wc2ludF90KW5leHRfc2ZlIC0gKF9fcHNpbnRfdClzZjsgaSsrKSAgewot CQl0bXBfc2ZlID0gTlVMTDsKLQkJc2ZfZW50cnkgPSBuZXh0X3NmZTsKLQkJ bGlubyA9IFhGU19ESVIyX1NGX0dFVF9JTlVNQkVSKHNmLAotCQkJWEZTX0RJ UjJfU0ZfSU5VTUJFUlAoc2ZfZW50cnkpKTsKLQkJYmNvcHkoc2ZfZW50cnkt Pm5hbWUsIGZuYW1lLCBzZl9lbnRyeS0+bmFtZWxlbik7Ci0JCWZuYW1lW3Nm X2VudHJ5LT5uYW1lbGVuXSA9ICdcMCc7Ci0KLQkJaWYgKCFzdHJjbXAoT1JQ SEFOQUdFLCBmbmFtZSkpICB7Ci0JCQlhZ25vID0gWEZTX0lOT19UT19BR05P KG1wLCBsaW5vKTsKLQkJCWFnaW5vID0gWEZTX0lOT19UT19BR0lOTyhtcCwg bGlubyk7Ci0KLQkJCWlyZWMgPSBmaW5kX2lub2RlX3JlYyhhZ25vLCBhZ2lu byk7Ci0KLQkJCS8qCi0JCQkgKiBpZiB0aGUgb3JwaGFuZ2UgaW5vZGUgaXMg aW4gdGhlIHRyZWUsCi0JCQkgKiBnZXQgaXQsIGNsZWFyIGl0LCBhbmQgbWFy ayBpdCBmcmVlLgotCQkJICogdGhlIGlub2RlcyBpbiB0aGUgb3JwaGFuYWdl IHdpbGwgZ2V0Ci0JCQkgKiByZWF0dGFjaGVkIHRvIHRoZSBuZXcgb3JwaGFu YWdlLgotCQkJICovCi0JCQlpZiAoaXJlYyAhPSBOVUxMKSAgewotCQkJCWRv X3dhcm4oCi0JCQkJXygiICAgICAgICAtIGNsZWFyaW5nIGV4aXN0aW5nIFwi JXNcIiBpbm9kZVxuIiksCi0JCQkJCU9SUEhBTkFHRSk7Ci0KLQkJCQlpbm9f b2Zmc2V0ID0gYWdpbm8gLSBpcmVjLT5pbm9fc3RhcnRudW07Ci0KLQkJCQkv KgotCQkJCSAqIGNoZWNrIGlmIHdlIGhhdmUgdG8gdXNlIHRoZSByb290IGlu b2RlCi0JCQkJICogYnVmZmVyIG9yIHJlYWQgb25lIGluIG91cnNlbHZlcy4g IE5vdGUKLQkJCQkgKiB0aGF0IHRoZSByb290IGlub2RlIGlzIGFsd2F5cyB0 aGUgZmlyc3QKLQkJCQkgKiBpbm9kZSBvZiB0aGUgY2h1bmsgdGhhdCBpdCdz IGluIHNvIHRoZXJlCi0JCQkJICogYXJlIHR3byBwb3NzaWJsZSBjYXNlcyB3 aGVyZSBsb3N0K2ZvdW5kCi0JCQkJICogbWlnaHQgYmUgaW4gdGhlIHNhbWUg YnVmZmVyIGFzIHRoZSByb290Ci0JCQkJICogaW5vZGUuICBPbmUgY2FzZSBp cyBhIGxhcmdlIGJsb2NrCi0JCQkJICogZmlsZXN5c3RlbSB3aGVyZSB0aGUg dHdvIGlub2RlcyBhcmUKLQkJCQkgKiBpbiBkaWZmZXJlbnQgaW5vZGUgY2h1 bmtzIGJ1dCB3aW5kCi0JCQkJICogdXAgaW4gdGhlIHNhbWUgYmxvY2sgKG11 bHRpcGxlIGNodW5rcwotCQkJCSAqIHBlciBibG9jaykgYW5kIHRoZSBzZWNv bmQgY2FzZSAob25lIG9yCi0JCQkJICogbW9yZSBibG9ja3MgcGVyIGNodW5r KSBpcyB3aGVyZSB0aGUgdHdvCi0JCQkJICogaW5vZGVzIGFyZSBpbiB0aGUg c2FtZSBjaHVuay4gTm90ZSB0aGF0Ci0JCQkJICogaW5vZGVzIGFyZSBhbGxv Y2F0ZWQgb24gZGlzayBpbiB1bml0cwotCQkJCSAqIG9mIE1BWChYRlNfSU5P REVTX1BFUl9DSFVOSyxzYl9pbm9wYmxvY2spLgotCQkJCSAqLwotCQkJCWlm IChYRlNfSU5PX1RPX0ZTQihtcCwgbXAtPm1fc2Iuc2Jfcm9vdGlubykKLQkJ CQkJCT09IFhGU19JTk9fVE9fRlNCKG1wLCBsaW5vKSB8fAotCQkJCSAgICAo YWdubyA9PSByb290X2Fnbm8gJiYKLQkJCQkgICAgIGFnaW5vIDwgcm9vdF9h Z2lubyArIFhGU19JTk9ERVNfUEVSX0NIVU5LKSkgewotCQkJCQl1c2VfcmJ1 ZiA9IDE7Ci0JCQkJCWJwID0gcm9vdGlub19icDsKLQotCQkJCQlkaW5vID0g WEZTX01BS0VfSVBUUihtcCwgYnAsIGFnaW5vIC0KLQkJCQkJCVhGU19JTk9f VE9fQUdJTk8obXAsCi0JCQkJCQkJbXAtPm1fc2Iuc2Jfcm9vdGlubykpOwot CQkJCX0gZWxzZSAgewotCQkJCQlsZW4gPSAoaW50KVhGU19GU0JfVE9fQkIo bXAsCi0JCQkJCQlNQVgoMSwgWEZTX0lOT0RFU19QRVJfQ0hVTksvCi0JCQkJ CQkJaW5vZGVzX3Blcl9ibG9jaykpOwotCQkJCQlicCA9IGxpYnhmc19yZWFk YnVmKG1wLT5tX2RldiwKLQkJCQkJCVhGU19BR0JfVE9fREFERFIobXAsIGFn bm8sCi0JCQkJCQkJWEZTX0FHSU5PX1RPX0FHQk5PKG1wLAotCQkJCQkJCQlp cmVjLT5pbm9fc3RhcnRudW0pKSwKLQkJCQkJCWxlbiwgMCk7Ci0JCQkJCWlm ICghYnApCi0JCQkJCQlkb19lcnJvcigKLQkJCQkJXygiY291bGQgbm90IHJl YWQgJXMgaW5vZGUgJWxsdVxuIiksCi0JCQkJCQkJT1JQSEFOQUdFLCBsaW5v KTsKLQotCQkJCQkvKgotCQkJCQkgKiBnZXQgdGhlIGFnYm5vIGNvbnRhaW5p bmcgdGhlIGZpcnN0Ci0JCQkJCSAqIGlub2RlIGluIHRoZSBjaHVuay4gIElu IG11bHRpLWJsb2NrCi0JCQkJCSAqIGNodW5rcywgdGhpcyBnZXRzIHVzIHRo ZSBvZmZzZXQKLQkJCQkJICogcmVsYXRpdmUgdG8gdGhlIGJlZ2lubmluZyBv ZiBhCi0JCQkJCSAqIHByb3Blcmx5IGFsaWduZWQgYnVmZmVyLiAgSW4KLQkJ CQkJICogbXVsdGktY2h1bmsgYmxvY2tzLCB0aGlzIGdldHMgdXMKLQkJCQkJ ICogdGhlIGNvcnJlY3QgYmxvY2sgbnVtYmVyLiAgVGhlbgotCQkJCQkgKiB0 dXJuIHRoZSBibG9jayBudW1iZXIgYmFjayBpbnRvCi0JCQkJCSAqIGFuIGFn aW5vIGFuZCBjYWxjdWxhdGUgdGhlIG9mZnNldAotCQkJCQkgKiBmcm9tIHRo ZXJlIHRvIGZlZWQgdG8gbWFrZSB0aGUgaXB0ci4KLQkJCQkJICogdGhlIGxh c3QgdGVybSBpbiBlZmZlY3Qgcm91bmRzIGRvd24KLQkJCQkJICogdG8gdGhl IGZpcnN0IGFnaW5vIGluIHRoZSBidWZmZXIuCi0JCQkJCSAqLwotCQkJCQlk aW5vID0gWEZTX01BS0VfSVBUUihtcCwgYnAsCi0JCQkJCQlhZ2lubyAtIFhG U19PRkZCTk9fVE9fQUdJTk8obXAsCi0JCQkJCQkJWEZTX0FHSU5PX1RPX0FH Qk5PKG1wLAotCQkJCQkJCWlyZWMtPmlub19zdGFydG51bSksCi0JCQkJCQkJ MCkpOwotCQkJCX0KLQotCQkJCWRpcnR5ID0gY2xlYXJfZGlub2RlKG1wLCBk aW5vLCBsaW5vKTsKLQotCQkJCUFTU0VSVChkaXJ0eSA9PSAwIHx8IChkaXJ0 eSAmJiAhbm9fbW9kaWZ5KSk7Ci0KLQkJCQkvKgotCQkJCSAqIGlmIHdlIHJl YWQgdGhlIGxvc3QrZm91bmQgaW5vZGUgaW4gdG8KLQkJCQkgKiBpdCwgZ2V0 IHJpZCBvZiBpdCBoZXJlLiAgaWYgdGhlIGxvc3QrZm91bmQKLQkJCQkgKiBp bm9kZSBpcyBpbiB0aGUgcm9vdCBpbm9kZSBidWZmZXIsIHRoZQotCQkJCSAq IGJ1ZmZlciB3aWxsIGJlIG1hcmtlZCBkaXJ0eSBhbnl3YXkgc2luY2UKLQkJ CQkgKiB0aGUgbG9zdCtmb3VuZCBlbnRyeSBpbiB0aGUgcm9vdCBpbm9kZSBp cwotCQkJCSAqIGFsc28gYmVpbmcgZGVsZXRlZCB3aGljaCBtYWtlcyB0aGUg cm9vdAotCQkJCSAqIGlub2RlIGJ1ZmZlciBhdXRvbWF0aWNhbGx5IGRpcnR5 LgotCQkJCSAqLwotCQkJCWlmICghdXNlX3JidWYpICB7Ci0JCQkJCWRpbm8g PSBOVUxMOwotCQkJCQlpZiAoZGlydHkgJiYgIW5vX21vZGlmeSkKLQkJCQkJ CWxpYnhmc193cml0ZWJ1ZihicCwgMCk7Ci0JCQkJCWVsc2UKLQkJCQkJCWxp Ynhmc19wdXRidWYoYnApOwotCQkJCX0KLQotCi0JCQkJaWYgKGlub2RlX2lz YWRpcihpcmVjLCBpbm9fb2Zmc2V0KSkKLQkJCQkJY2xlYXJfaW5vZGVfaXNh ZGlyKGlyZWMsIGlub19vZmZzZXQpOwotCi0JCQkJc2V0X2lub2RlX2ZyZWUo aXJlYywgaW5vX29mZnNldCk7Ci0JCQl9Ci0KLQkJCWRvX3dhcm4oXygiICAg ICAgICAtIGRlbGV0aW5nIGV4aXN0aW5nIFwiJXNcIiBlbnRyeVxuIiksCi0J CQkJT1JQSEFOQUdFKTsKLQotCQkJLyoKLQkJCSAqIG5vdGUgLS0gZXhhY3Rs eSB0aGUgc2FtZSBkZWxldGlvbiBjb2RlIGFzIGluCi0JCQkgKiBwcm9jZXNz X3Nob3J0Zm9ybV9kaXIoKQotCQkJICovCi0JCQl0bXBfZWxlbiA9IFhGU19E SVIyX1NGX0VOVFNJWkVfQllFTlRSWShzZiwgc2ZfZW50cnkpOwotCQkJSU5U X01PRChyb290X2Rpbm8tPmRpX2NvcmUuZGlfc2l6ZSwgQVJDSF9DT05WRVJU LAotCQkJCS0odG1wX2VsZW4pKTsKLQotCQkJdG1wX3NmZSA9ICh4ZnNfZGly Ml9zZl9lbnRyeV90ICopCi0JCQkJKChfX3BzaW50X3QpIHNmX2VudHJ5ICsg dG1wX2VsZW4pOwotCQkJdG1wX2xlbiA9IG1heF9zaXplIC0gKChfX3BzaW50 X3QpIHRtcF9zZmUKLQkJCQkJLSAoX19wc2ludF90KSBzZik7Ci0KLQkJCW1l bW1vdmUoc2ZfZW50cnksIHRtcF9zZmUsIHRtcF9sZW4pOwotCi0JCQlJTlRf TU9EKHNmLT5oZHIuY291bnQsIEFSQ0hfQ09OVkVSVCwgLTEpOwotCQkJaWYg KGxpbm8gPiBYRlNfRElSMl9NQVhfU0hPUlRfSU5VTSkKLQkJCQlzZi0+aGRy Lmk4Y291bnQtLTsKLQotCQkJYnplcm8oKHZvaWQgKikgKChfX3BzaW50X3Qp IHNmX2VudHJ5ICsgdG1wX2xlbiksCi0JCQkJdG1wX2VsZW4pOwotCi0JCQkv KgotCQkJICogc2V0IHRoZSB0bXAgdmFsdWUgdG8gdGhlIGN1cnJlbnQKLQkJ CSAqIHBvaW50ZXIgc28gd2UnbGwgcHJvY2VzcyB0aGUgZW50cnkKLQkJCSAq IHdlIGp1c3QgbW92ZWQgdXAKLQkJCSAqLwotCQkJdG1wX3NmZSA9IHNmX2Vu dHJ5OwotCi0JCQkvKgotCQkJICogV0FSTklORzogIGRyb3AgdGhlIGluZGV4 IGkgYnkgb25lCi0JCQkgKiBzbyBpdCBtYXRjaGVzIHRoZSBkZWNyZW1lbnRl ZCBjb3VudCBmb3IKLQkJCSAqIGFjY3VyYXRlIGNvbXBhcmlzb25zIGluIHRo ZSBsb29wIHRlc3QuCi0JCQkgKiBtYXJrIHJvb3QgaW5vZGUgYXMgZGlydHkg dG8gbWFrZSBkZWxldGlvbgotCQkJICogcGVybWFuZW50LgotCQkJICovCi0J CQlpLS07Ci0KLQkJCSppbm9fZGlydHkgPSAxOwotCi0JCQlyZXMrKzsKLQkJ fQotCQluZXh0X3NmZSA9ICh0bXBfc2ZlID09IE5VTEwpCi0JCQk/ICh4ZnNf ZGlyMl9zZl9lbnRyeV90ICopICgoX19wc2ludF90KSBzZl9lbnRyeSArCi0J CQkJWEZTX0RJUjJfU0ZfRU5UU0laRV9CWUVOVFJZKHNmLCBzZl9lbnRyeSkp Ci0JCQk6IHRtcF9zZmU7Ci0JfQotCi0JcmV0dXJuKHJlcyk7Ci19Ci0KLXZv aWQKLWRlbGV0ZV9vcnBoYW5hZ2UoeGZzX21vdW50X3QgKm1wKQotewotCXhm c19pbm9fdCBpbm87Ci0JeGZzX2Rpbm9kZV90ICpkaW5vOwotCXhmc19idWZf dCAqZGJwOwotCWludCBkaXJ0eSwgcmVzLCBsZW47Ci0KLQlBU1NFUlQoIW5v X21vZGlmeSk7Ci0KLQlkYnAgPSBOVUxMOwotCWRpcnR5ID0gcmVzID0gMDsK LQlpbm8gPSBtcC0+bV9zYi5zYl9yb290aW5vOwotCi0JLyoKLQkgKiB3ZSBr bm93IHRoZSByb290IGlzIGluIHVzZSBvciB3ZSB3b3VsZG4ndCBiZSBoZXJl Ci0JICovCi0JbGVuID0gKGludClYRlNfRlNCX1RPX0JCKG1wLAotCQkJTUFY KDEsIFhGU19JTk9ERVNfUEVSX0NIVU5LL2lub2Rlc19wZXJfYmxvY2spKTsK LQlkYnAgPSBsaWJ4ZnNfcmVhZGJ1ZihtcC0+bV9kZXYsCi0JCQlYRlNfRlNC X1RPX0RBRERSKG1wLCBYRlNfSU5PX1RPX0ZTQihtcCwgaW5vKSksIGxlbiwg MCk7Ci0JaWYgKCFkYnApCi0JCWRvX2Vycm9yKF8oImNvdWxkIG5vdCByZWFk IGJ1ZmZlciBmb3Igcm9vdCBpbm9kZSAlbGx1ICIKLQkJCSAgICIoZGFkZHIg JWxsZCwgc2l6ZSAlZClcbiIpLCBpbm8sCi0JCQlYRlNfRlNCX1RPX0RBRERS KG1wLCBYRlNfSU5PX1RPX0ZTQihtcCwgaW5vKSksCi0JCQlYRlNfRlNCX1RP X0JCKG1wLCAxKSk7Ci0KLQkvKgotCSAqIHdlIGFsc28ga25vdyB0aGF0IHRo ZSByb290IGlub2RlIGlzIGFsd2F5cyB0aGUgZmlyc3QgaW5vZGUKLQkgKiBh bGxvY2F0ZWQgaW4gdGhlIHN5c3RlbSwgdGhlcmVmb3JlIGl0J2xsIGJlIGF0 IHRoZSBiZWdpbm5pbmcKLQkgKiBvZiB0aGUgcm9vdCBpbm9kZSBjaHVuawot CSAqLwotCWRpbm8gPSBYRlNfTUFLRV9JUFRSKG1wLCBkYnAsIDApOwotCi0J c3dpdGNoIChkaW5vLT5kaV9jb3JlLmRpX2Zvcm1hdCkgIHsKLQljYXNlIFhG U19ESU5PREVfRk1UX0VYVEVOVFM6Ci0JY2FzZSBYRlNfRElOT0RFX0ZNVF9C VFJFRToKLQkJaWYgKFhGU19TQl9WRVJTSU9OX0hBU0RJUlYyKCZtcC0+bV9z YikpCi0JCQlyZXMgPSBsb25nZm9ybTJfZGVsZXRlX29ycGhhbmFnZShtcCwg aW5vLCBkaW5vLCBkYnAsCi0JCQkJJmRpcnR5KTsKLQkJZWxzZQotCQkJcmVz ID0gbG9uZ2Zvcm1fZGVsZXRlX29ycGhhbmFnZShtcCwgaW5vLCBkaW5vLCBk YnAsCi0JCQkJJmRpcnR5KTsKLQkJYnJlYWs7Ci0JY2FzZSBYRlNfRElOT0RF X0ZNVF9MT0NBTDoKLQkJaWYgKFhGU19TQl9WRVJTSU9OX0hBU0RJUlYyKCZt cC0+bV9zYikpCi0JCQlyZXMgPSBzaG9ydGZvcm0yX2RlbGV0ZV9vcnBoYW5h Z2UobXAsIGlubywgZGlubywgZGJwLAotCQkJCSZkaXJ0eSk7Ci0JCWVsc2UK LQkJCXJlcyA9IHNob3J0Zm9ybV9kZWxldGVfb3JwaGFuYWdlKG1wLCBpbm8s IGRpbm8sIGRicCwKLQkJCQkmZGlydHkpOwotCQlBU1NFUlQoKHJlcyA9PSAw ICYmIGRpcnR5ID09IDApIHx8IChyZXMgPiAwICYmIGRpcnR5ID09IDEpKTsK LQkJYnJlYWs7Ci0JZGVmYXVsdDoKLQkJYnJlYWs7Ci0JfQotCi0JaWYgKHJl cykgIHsKLQkJc3dpdGNoIChkaW5vLT5kaV9jb3JlLmRpX3ZlcnNpb24pICB7 Ci0JCWNhc2UgWEZTX0RJTk9ERV9WRVJTSU9OXzE6Ci0JCQlJTlRfTU9EKGRp bm8tPmRpX2NvcmUuZGlfb25saW5rLCBBUkNIX0NPTlZFUlQsIC1yZXMpOwot CQkJSU5UX1NFVChkaW5vLT5kaV9jb3JlLmRpX25saW5rLCBBUkNIX0NPTlZF UlQsCi0JCQkJSU5UX0dFVChkaW5vLT5kaV9jb3JlLmRpX29ubGluaywgQVJD SF9DT05WRVJUKSk7Ci0JCQlicmVhazsKLQkJY2FzZSBYRlNfRElOT0RFX1ZF UlNJT05fMjoKLQkJCUlOVF9NT0QoZGluby0+ZGlfY29yZS5kaV9ubGluaywg QVJDSF9DT05WRVJULCAtcmVzKTsKLQkJCWJyZWFrOwotCQlkZWZhdWx0Ogot CQkJZG9fZXJyb3IoXygidW5rbm93biB2ZXJzaW9uICMlZCBpbiByb290IGlu b2RlXG4iKSwKLQkJCQkJZGluby0+ZGlfY29yZS5kaV92ZXJzaW9uKTsKLQkJ fQotCi0JCWRpcnR5ID0gMTsKLQl9Ci0KLQlpZiAoZGlydHkpCi0JCWxpYnhm c193cml0ZWJ1ZihkYnAsIDApOwotCWVsc2UKLQkJbGlieGZzX3B1dGJ1Zihk YnApOwotfQotCiAvKgogICogbnVsbCBvdXQgcXVvdGEgaW5vZGUgZmllbGRz IGluIHNiIGlmIHRoZXkgcG9pbnQgdG8gbm9uLWV4aXN0ZW50IGlub2Rlcy4K ICAqIHRoaXMgaXNuJ3QgYXMgcmVkdW5kYW50IGFzIGl0IGxvb2tzIHNpbmNl IGl0J3MgcG9zc2libGUgdGhhdCB0aGUgc2IgZmllbGQKQEAgLTExODAsMTYg KzE2Niw2IEBACiAJCQlkb193YXJuKF8oInJvb3QgaW5vZGUgbG9zdFxuIikp OwogCX0KIAotCS8qCi0JICogaGF2ZSB0byBkZWxldGUgbG9zdCtmb3VuZCBm aXJzdCBzbyB0aGF0IGJsb2NrcyB1c2VkCi0JICogYnkgbG9zdCtmb3VuZCBk b24ndCBzaG93IHVwIGFzIHVzZWQKLQkgKi8KLQlpZiAoIW5vX21vZGlmeSkg IHsKLQkJZG9fbG9nKF8oIiAgICAgICAgLSBjbGVhciBsb3N0K2ZvdW5kIChp ZiBpdCBleGlzdHMpIC4uLlxuIikpOwotCQlpZiAoIW5lZWRfcm9vdF9pbm9k ZSkKLQkJCWRlbGV0ZV9vcnBoYW5hZ2UobXApOwotCX0KLQogCWZvciAoaSA9 IDA7IGkgPCBtcC0+bV9zYi5zYl9hZ2NvdW50OyBpKyspICB7CiAJCWFnX2Vu ZCA9IChpIDwgbXAtPm1fc2Iuc2JfYWdjb3VudCAtIDEpID8gbXAtPm1fc2Iu c2JfYWdibG9ja3MgOgogCQkJbXAtPm1fc2Iuc2JfZGJsb2NrcyAtCkluZGV4 OiByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL3BoYXNlNi5jCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dzL3JlcGFpci9w aGFzZTYuYwkyMDA3LTA0LTI3IDE0OjExOjA5LjM3MDYzNjQyMCArMTAwMAor KysgcmVwYWlyL3hmc3Byb2dzL3JlcGFpci9waGFzZTYuYwkyMDA3LTA0LTI3 IDE0OjExOjQxLjAwMDAwMDAwMCArMTAwMApAQCAtMzEsOSArMzEsMTAgQEAK ICNpbmNsdWRlICJwcm9ncmVzcy5oIgogI2luY2x1ZGUgInZlcnNpb25zLmgi CiAKLXN0YXRpYyBzdHJ1Y3QgY3JlZCB6ZXJvY3I7Ci1zdGF0aWMgc3RydWN0 IGZzeGF0dHIgemVyb2ZzeDsKLXN0YXRpYyBpbnQgb3JwaGFuYWdlX2VudGVy ZWQ7CitzdGF0aWMgc3RydWN0IGNyZWQJCXplcm9jcjsKK3N0YXRpYyBzdHJ1 Y3QgZnN4YXR0ciAJCXplcm9mc3g7CitzdGF0aWMgeGZzX2lub190CQlvcnBo YW5hZ2VfaW5vOworc3RhdGljIHhmc19pbm9kZV90CQkqb3JwaGFuYWdlX2lw OwogCiAvKgogICogRGF0YSBzdHJ1Y3R1cmVzIGFuZCByb3V0aW5lcyB0byBr ZWVwIHRyYWNrIG9mIGRpcmVjdG9yeSBlbnRyaWVzCkBAIC04MDgsNiArODA5 LDI0IEBACiAJY29uc3QgaW50CW1vZGUgPSAwNzU1OwogCWludAkJbnJlczsK IAorCS8qCisJICogY2hlY2sgZm9yIGFuIGV4aXN0aW5nIGxvc3QrZm91bmQg Zmlyc3QsIGlmIGl0IGV4aXN0cywgcmV0dXJuCisJICogaXQncyBpbm9kZS4g T3RoZXJ3aXNlLCB3ZSBjYW4gY3JlYXRlIGl0LiBCYWQgbG9zdCtmb3VuZCBp bm9kZXMKKwkgKiB3b3VsZCBoYXZlIGJlZW4gY2xlYXJlZCBpbiBwaGFzZTMg YW5kIHBoYXNlNC4KKwkgKi8KKworCWlmICgoaSA9IGxpYnhmc19pZ2V0KG1w LCBOVUxMLCBtcC0+bV9zYi5zYl9yb290aW5vLCAwLCAmcGlwLCAwKSkpCisJ CWRvX2Vycm9yKF8oIiVkIC0gY291bGRuJ3QgaWdldCByb290IGlub2RlIHRv IG9idGFpbiAlc1xuIiksCisJCQlpLCBPUlBIQU5BR0UpOworCisJaWYgKGRp cl9sb29rdXAobXAsIE5VTEwsIHBpcCwgT1JQSEFOQUdFLCBzdHJsZW4oT1JQ SEFOQUdFKSwKKwkJCSZpbm8pID09IDApCisJCXJldHVybiBpbm87CisKKwkv KgorCSAqIGNvdWxkIG5vdCBiZSBmb3VuZCwgY3JlYXRlIGl0CisJICovCisK IAl0cCA9IGxpYnhmc190cmFuc19hbGxvYyhtcCwgMCk7CiAJWEZTX0JNQVBf SU5JVCgmZmxpc3QsICZmaXJzdCk7CiAKQEAgLTgyMCw5ICs4MzksOSBAQAog CSAqIHVzZSBpZ2V0L2lqb2luIGluc3RlYWQgb2YgdHJhbnNfaWdldCBiZWNh dXNlIHRoZSBpYWxsb2MKIAkgKiB3cmFwcGVyIGNhbiBjb21taXQgdGhlIHRy YW5zYWN0aW9uIGFuZCBzdGFydCBhIG5ldyBvbmUKIAkgKi8KLQlpZiAoKGkg PSBsaWJ4ZnNfaWdldChtcCwgTlVMTCwgbXAtPm1fc2Iuc2Jfcm9vdGlubywg MCwgJnBpcCwgMCkpKQorLyoJaWYgKChpID0gbGlieGZzX2lnZXQobXAsIE5V TEwsIG1wLT5tX3NiLnNiX3Jvb3Rpbm8sIDAsICZwaXAsIDApKSkKIAkJZG9f ZXJyb3IoXygiJWQgLSBjb3VsZG4ndCBpZ2V0IHJvb3QgaW5vZGUgdG8gbWFr ZSAlc1xuIiksCi0JCQlpLCBPUlBIQU5BR0UpOworCQkJaSwgT1JQSEFOQUdF KTsqLwogCiAJZXJyb3IgPSBsaWJ4ZnNfaW5vZGVfYWxsb2MoJnRwLCBwaXAs IG1vZGV8U19JRkRJUiwKIAkJCQkJMSwgMCwgJnplcm9jciwgJnplcm9mc3gs ICZpcCk7CkBAIC04NDMsMTggKzg2MiwxOSBAQAogCSAqLwogCWlmICgoZXJy b3IgPSBkaXJfY3JlYXRlbmFtZShtcCwgdHAsIHBpcCwgT1JQSEFOQUdFLAog CQkJc3RybGVuKE9SUEhBTkFHRSksIGlwLT5pX2lubywgJmZpcnN0LCAmZmxp c3QsIG5yZXMpKSkgewotCQlkb193YXJuKAotCQlfKCJjYW4ndCBtYWtlICVz LCBjcmVhdGVuYW1lIGVycm9yICVkLCB3aWxsIHRyeSBsYXRlclxuIiksCisJ CWRvX2Vycm9yKAorCQlfKCJjYW4ndCBtYWtlICVzLCBjcmVhdGVuYW1lIGVy cm9yICVkXG4iKSwKIAkJCU9SUEhBTkFHRSwgZXJyb3IpOwotCQlvcnBoYW5h Z2VfZW50ZXJlZCA9IDA7Ci0JfSBlbHNlCi0JCW9ycGhhbmFnZV9lbnRlcmVk ID0gMTsKKwl9CiAKIAkvKgogCSAqIGJ1bXAgdXAgdGhlIGxpbmsgY291bnQg aW4gdGhlIHJvb3QgZGlyZWN0b3J5IHRvIGFjY291bnQKIAkgKiBmb3IgLi4g aW4gdGhlIG5ldyBkaXJlY3RvcnkKIAkgKi8KIAlwaXAtPmlfZC5kaV9ubGlu aysrOworCWFkZF9pbm9kZV9yZWYoZmluZF9pbm9kZV9yZWMoWEZTX0lOT19U T19BR05PKG1wLCBtcC0+bV9zYi5zYl9yb290aW5vKSwKKwkJCQlYRlNfSU5P X1RPX0FHSU5PKG1wLCBtcC0+bV9zYi5zYl9yb290aW5vKSksIDApOworCiAK IAlsaWJ4ZnNfdHJhbnNfbG9nX2lub2RlKHRwLCBwaXAsIFhGU19JTE9HX0NP UkUpOwogCWRpcl9pbml0KG1wLCB0cCwgaXAsIHBpcCk7CkBAIC04NzAsMzYg Kzg5MCw0MyBAQAogCiAJbGlieGZzX3RyYW5zX2NvbW1pdCh0cCwgWEZTX1RS QU5TX1JFTEVBU0VfTE9HX1JFU3xYRlNfVFJBTlNfU1lOQywgMCk7CiAKLQkv KiBuZWVkIGxpYnhmc19pcHV0IGhlcmU/IC0gbmF0aGFucyBUT0RPIC0gcG9z c2libGUgbWVtb3J5IGxlYWs/ICovCi0KIAlyZXR1cm4oaW5vKTsKIH0KIAog LyoKLSAqIG1vdmUgYSBmaWxlIHRvIHRoZSBvcnBoYW5nZS4gIHRoZSBvcnBo YW5hZ2UgaXMgZ3VhcmFudGVlZAotICogYXQgdGhpcyBwb2ludCB0byBvbmx5 IGhhdmUgZmlsZSBpbiBpdCB3aG9zZSBuYW1lID09IGZpbGUgaW5vZGUgIwor ICogbW92ZSBhIGZpbGUgdG8gdGhlIG9ycGhhbmdlLgogICovCi12b2lkCi1t dl9vcnBoYW5hZ2UoeGZzX21vdW50X3QJKm1wLAotCQl4ZnNfaW5vX3QJZGly X2lubywJLyogb3JwaGFuZ2UgaW5vZGUgIyAqLwotCQl4ZnNfaW5vX3QJaW5v LAkJLyogaW5vZGUgIyB0byBiZSBtb3ZlZCAqLwotCQlpbnQJCWlzYV9kaXIp CS8qIDEgaWYgaW5vZGUgaXMgYSBkaXJlY3RvcnkgKi8KLXsKLQl4ZnNfaW5v X3QJZW50cnlfaW5vX251bTsKLQl4ZnNfaW5vZGVfdAkqZGlyX2lub19wOwot CXhmc19pbm9kZV90CSppbm9fcDsKLQl4ZnNfdHJhbnNfdAkqdHA7Ci0JeGZz X2ZzYmxvY2tfdAlmaXJzdDsKLQl4ZnNfYm1hcF9mcmVlX3QJZmxpc3Q7Ci0J aW50CQllcnI7Ci0JaW50CQljb21taXR0ZWQ7Ci0JY2hhcgkJZm5hbWVbTUFY UEFUSExFTiArIDFdOwotCWludAkJbnJlczsKK3N0YXRpYyB2b2lkCittdl9v cnBoYW5hZ2UoCisJeGZzX21vdW50X3QJCSptcCwKKwl4ZnNfaW5vX3QJCWlu bywJCS8qIGlub2RlICMgdG8gYmUgbW92ZWQgKi8KKwlpbnQJCQlpc2FfZGly KQkvKiAxIGlmIGlub2RlIGlzIGEgZGlyZWN0b3J5ICovCit7CisJeGZzX2lu b190CQllbnRyeV9pbm9fbnVtOworCXhmc19pbm9kZV90CQkqaW5vX3A7CisJ eGZzX3RyYW5zX3QJCSp0cDsKKwl4ZnNfZnNibG9ja190CQlmaXJzdDsKKwl4 ZnNfYm1hcF9mcmVlX3QJCWZsaXN0OworCWludAkJCWVycjsKKwlpbnQJCQlj b21taXR0ZWQ7CisJY2hhcgkJCWZuYW1lW01BWFBBVEhMRU4gKyAxXTsKKwlp bnQJCQlmbmFtZWxlbjsKKwlpbnQJCQlucmVzOworCWludAkJCWluY3I7CiAK LQlzbnByaW50ZihmbmFtZSwgc2l6ZW9mKGZuYW1lKSwgIiVsbHUiLCAodW5z aWduZWQgbG9uZyBsb25nKWlubyk7CisJZm5hbWVsZW4gPSBzbnByaW50Zihm bmFtZSwgc2l6ZW9mKGZuYW1lKSwgIiVsbHUiLAorCQkJKHVuc2lnbmVkIGxv bmcgbG9uZylpbm8pOwogCi0JaWYgKChlcnIgPSBsaWJ4ZnNfaWdldChtcCwg TlVMTCwgZGlyX2lubywgMCwgJmRpcl9pbm9fcCwgMCkpKQotCQlkb19lcnJv cihfKCIlZCAtIGNvdWxkbid0IGlnZXQgb3JwaGFuYWdlIGlub2RlXG4iKSwg ZXJyKTsKKwlBU1NFUlQob3JwaGFuYWdlX2lwICE9IE5VTEwpOworCS8qCisJ ICogTWFrZSBzdXJlIHRoZSBmaWxlbmFtZSBpcyB1bmlxdWUgaW4gdGhlIGxv c3QrZm91bmQKKwkgKi8KKwlpbmNyID0gMDsKKwl3aGlsZSAoZGlyX2xvb2t1 cChtcCwgTlVMTCwgb3JwaGFuYWdlX2lwLCBmbmFtZSwgZm5hbWVsZW4sCisJ CQkmZW50cnlfaW5vX251bSkgPT0gMCkgeworCQlmbmFtZWxlbiA9IHNucHJp bnRmKGZuYW1lLCBzaXplb2YoZm5hbWUpLCAiJWxsdS4lZCIsCisJCQkJKHVu c2lnbmVkIGxvbmcgbG9uZylpbm8sICsraW5jcik7CisJfQogCiAJdHAgPSBs aWJ4ZnNfdHJhbnNfYWxsb2MobXAsIDApOwogCkBAIC05MDcsMTAgKzkzNCwx MCBAQAogCQlkb19lcnJvcihfKCIlZCAtIGNvdWxkbid0IGlnZXQgZGlzY29u bmVjdGVkIGlub2RlXG4iKSwgZXJyKTsKIAogCWlmIChpc2FfZGlyKSAgewot CQlucmVzID0gWEZTX0RJUkVOVEVSX1NQQUNFX1JFUyhtcCwgc3RybGVuKGZu YW1lKSkgKworCQlucmVzID0gWEZTX0RJUkVOVEVSX1NQQUNFX1JFUyhtcCwg Zm5hbWVsZW4pICsKIAkJICAgICAgIFhGU19ESVJFTlRFUl9TUEFDRV9SRVMo bXAsIDIpOwotCQlpZiAoKGVyciA9IGRpcl9sb29rdXAobXAsIHRwLCBpbm9f cCwgIi4uIiwgMiwKLQkJCQkmZW50cnlfaW5vX251bSkpKSB7CisJCWVyciA9 IGRpcl9sb29rdXAobXAsIHRwLCBpbm9fcCwgIi4uIiwgMiwgJmVudHJ5X2lu b19udW0pOworCQlpZiAoZXJyKSB7CiAJCQlBU1NFUlQoZXJyID09IEVOT0VO VCk7CiAKIAkJCWlmICgoZXJyID0gbGlieGZzX3RyYW5zX3Jlc2VydmUodHAs IG5yZXMsCkBAIC05MjEsMjIgKzk0OCwyMiBAQAogCV8oInNwYWNlIHJlc2Vy dmF0aW9uIGZhaWxlZCAoJWQpLCBmaWxlc3lzdGVtIG1heSBiZSBvdXQgb2Yg c3BhY2VcbiIpLAogCQkJCQllcnIpOwogCi0JCQlsaWJ4ZnNfdHJhbnNfaWpv aW4odHAsIGRpcl9pbm9fcCwgMCk7CisJCQlsaWJ4ZnNfdHJhbnNfaWpvaW4o dHAsIG9ycGhhbmFnZV9pcCwgMCk7CiAJCQlsaWJ4ZnNfdHJhbnNfaWpvaW4o dHAsIGlub19wLCAwKTsKIAogCQkJWEZTX0JNQVBfSU5JVCgmZmxpc3QsICZm aXJzdCk7Ci0JCQlpZiAoKGVyciA9IGRpcl9jcmVhdGVuYW1lKG1wLCB0cCwg ZGlyX2lub19wLCBmbmFtZSwKLQkJCQkJCXN0cmxlbihmbmFtZSksIGlubywg JmZpcnN0LAorCQkJaWYgKChlcnIgPSBkaXJfY3JlYXRlbmFtZShtcCwgdHAs IG9ycGhhbmFnZV9pcCwgZm5hbWUsCisJCQkJCQlmbmFtZWxlbiwgaW5vLCAm Zmlyc3QsCiAJCQkJCQkmZmxpc3QsIG5yZXMpKSkKIAkJCQlkb19lcnJvcigK IAlfKCJuYW1lIGNyZWF0ZSBmYWlsZWQgaW4gJXMgKCVkKSwgZmlsZXN5c3Rl bSBtYXkgYmUgb3V0IG9mIHNwYWNlXG4iKSwKIAkJCQkJT1JQSEFOQUdFLCBl cnIpOwogCi0JCQlkaXJfaW5vX3AtPmlfZC5kaV9ubGluaysrOwotCQkJbGli eGZzX3RyYW5zX2xvZ19pbm9kZSh0cCwgZGlyX2lub19wLCBYRlNfSUxPR19D T1JFKTsKKwkJCW9ycGhhbmFnZV9pcC0+aV9kLmRpX25saW5rKys7CisJCQls aWJ4ZnNfdHJhbnNfbG9nX2lub2RlKHRwLCBvcnBoYW5hZ2VfaXAsIFhGU19J TE9HX0NPUkUpOwogCiAJCQlpZiAoKGVyciA9IGRpcl9jcmVhdGVuYW1lKG1w LCB0cCwgaW5vX3AsICIuLiIsIDIsCi0JCQkJCQlkaXJfaW5vLCAmZmlyc3Qs ICZmbGlzdCwgbnJlcykpKQorCQkJCQkJb3JwaGFuYWdlX2lubywgJmZpcnN0 LCAmZmxpc3QsIG5yZXMpKSkKIAkJCQlkb19lcnJvcigKIAlfKCJjcmVhdGlv biBvZiAuLiBlbnRyeSBmYWlsZWQgKCVkKSwgZmlsZXN5c3RlbSBtYXkgYmUg b3V0IG9mIHNwYWNlXG4iKSwKIAkJCQkJZXJyKTsKQEAgLTk2MCwyOCArOTg3 LDI4IEBACiAJXygic3BhY2UgcmVzZXJ2YXRpb24gZmFpbGVkICglZCksIGZp bGVzeXN0ZW0gbWF5IGJlIG91dCBvZiBzcGFjZVxuIiksCiAJCQkJCWVycik7 CiAKLQkJCWxpYnhmc190cmFuc19pam9pbih0cCwgZGlyX2lub19wLCAwKTsK KwkJCWxpYnhmc190cmFuc19pam9pbih0cCwgb3JwaGFuYWdlX2lwLCAwKTsK IAkJCWxpYnhmc190cmFuc19pam9pbih0cCwgaW5vX3AsIDApOwogCiAJCQlY RlNfQk1BUF9JTklUKCZmbGlzdCwgJmZpcnN0KTsKIAotCQkJaWYgKChlcnIg PSBkaXJfY3JlYXRlbmFtZShtcCwgdHAsIGRpcl9pbm9fcCwgZm5hbWUsCi0J CQkJCQlzdHJsZW4oZm5hbWUpLCBpbm8sICZmaXJzdCwKKwkJCWlmICgoZXJy ID0gZGlyX2NyZWF0ZW5hbWUobXAsIHRwLCBvcnBoYW5hZ2VfaXAsIGZuYW1l LAorCQkJCQkJZm5hbWVsZW4sIGlubywgJmZpcnN0LAogCQkJCQkJJmZsaXN0 LCBucmVzKSkpCiAJCQkJZG9fZXJyb3IoCiAJXygibmFtZSBjcmVhdGUgZmFp bGVkIGluICVzICglZCksIGZpbGVzeXN0ZW0gbWF5IGJlIG91dCBvZiBzcGFj ZVxuIiksCiAJCQkJCU9SUEhBTkFHRSwgZXJyKTsKIAotCQkJZGlyX2lub19w LT5pX2QuZGlfbmxpbmsrKzsKLQkJCWxpYnhmc190cmFuc19sb2dfaW5vZGUo dHAsIGRpcl9pbm9fcCwgWEZTX0lMT0dfQ09SRSk7CisJCQlvcnBoYW5hZ2Vf aXAtPmlfZC5kaV9ubGluaysrOworCQkJbGlieGZzX3RyYW5zX2xvZ19pbm9k ZSh0cCwgb3JwaGFuYWdlX2lwLCBYRlNfSUxPR19DT1JFKTsKIAogCQkJLyoK IAkJCSAqIGRvbid0IHJlcGxhY2UgLi4gdmFsdWUgaWYgaXQgYWxyZWFkeSBw b2ludHMKIAkJCSAqIHRvIHVzLiAgdGhhdCdsbCBwb3AgYSBsaWJ4ZnMva2Vy bmVsIEFTU0VSVC4KIAkJCSAqLwotCQkJaWYgKGVudHJ5X2lub19udW0gIT0g ZGlyX2lubykgIHsKKwkJCWlmIChlbnRyeV9pbm9fbnVtICE9IG9ycGhhbmFn ZV9pbm8pICB7CiAJCQkJaWYgKChlcnIgPSBkaXJfcmVwbGFjZShtcCwgdHAs IGlub19wLCAiLi4iLAotCQkJCQkJCTIsIGRpcl9pbm8sICZmaXJzdCwKKwkJ CQkJCQkyLCBvcnBoYW5hZ2VfaW5vLCAmZmlyc3QsCiAJCQkJCQkJJmZsaXN0 LCBucmVzKSkpCiAJCQkJCWRvX2Vycm9yKAogCV8oIm5hbWUgcmVwbGFjZSBv cCBmYWlsZWQgKCVkKSwgZmlsZXN5c3RlbSBtYXkgYmUgb3V0IG9mIHNwYWNl XG4iKSwKQEAgLTEwMDQsMTkgKzEwMzEsMTkgQEAKIAkJICogbGlua3MsIHdl J3JlIG5vdCBkb2luZyB0aGUgaW5vZGUgYWxsb2NhdGlvbgogCQkgKiBhbHNv IGFjY291bnRlZCBmb3IgaW4gdGhlIGNyZWF0ZQogCQkgKi8KLQkJbnJlcyA9 IFhGU19ESVJFTlRFUl9TUEFDRV9SRVMobXAsIHN0cmxlbihmbmFtZSkpOwor CQlucmVzID0gWEZTX0RJUkVOVEVSX1NQQUNFX1JFUyhtcCwgZm5hbWVsZW4p OwogCQlpZiAoKGVyciA9IGxpYnhmc190cmFuc19yZXNlcnZlKHRwLCBucmVz LCBYRlNfUkVNT1ZFX0xPR19SRVMobXApLCAwLAogCQkJCVhGU19UUkFOU19Q RVJNX0xPR19SRVMsIFhGU19SRU1PVkVfTE9HX0NPVU5UKSkpCiAJCQlkb19l cnJvcigKIAlfKCJzcGFjZSByZXNlcnZhdGlvbiBmYWlsZWQgKCVkKSwgZmls ZXN5c3RlbSBtYXkgYmUgb3V0IG9mIHNwYWNlXG4iKSwKIAkJCQllcnIpOwog Ci0JCWxpYnhmc190cmFuc19pam9pbih0cCwgZGlyX2lub19wLCAwKTsKKwkJ bGlieGZzX3RyYW5zX2lqb2luKHRwLCBvcnBoYW5hZ2VfaXAsIDApOwogCQls aWJ4ZnNfdHJhbnNfaWpvaW4odHAsIGlub19wLCAwKTsKIAogCQlYRlNfQk1B UF9JTklUKCZmbGlzdCwgJmZpcnN0KTsKLQkJaWYgKChlcnIgPSBkaXJfY3Jl YXRlbmFtZShtcCwgdHAsIGRpcl9pbm9fcCwgZm5hbWUsCi0JCQkJc3RybGVu KGZuYW1lKSwgaW5vLCAmZmlyc3QsICZmbGlzdCwgbnJlcykpKQorCQlpZiAo KGVyciA9IGRpcl9jcmVhdGVuYW1lKG1wLCB0cCwgb3JwaGFuYWdlX2lwLCBm bmFtZSwKKwkJCQlmbmFtZWxlbiwgaW5vLCAmZmlyc3QsICZmbGlzdCwgbnJl cykpKQogCQkJZG9fZXJyb3IoCiAJXygibmFtZSBjcmVhdGUgZmFpbGVkIGlu ICVzICglZCksIGZpbGVzeXN0ZW0gbWF5IGJlIG91dCBvZiBzcGFjZVxuIiks CiAJCQkJT1JQSEFOQUdFLCBlcnIpOwpAQCAtMTM2NSw2ICsxMzkyLDI0IEBA CiAJcmV0dXJuKDEpOwogfQogCitzdGF0aWMgaW50CitlbnRyeV9qdW5rZWQo CisJY29uc3QgY2hhciAJKm1zZywKKwljb25zdCBjaGFyCSppbmFtZSwKKwl4 ZnNfaW5vX3QJaW5vMSwKKwl4ZnNfaW5vX3QJaW5vMikKK3sKKwlkb193YXJu KG1zZywgaW5hbWUsIGlubzEsIGlubzIpOworCWlmICghbm9fbW9kaWZ5KSB7 CisJCWlmICh2ZXJib3NlKQorCQkJZG9fd2FybihfKCIsIG1hcmtpbmcgZW50 cnkgdG8gYmUganVua2VkXG4iKSk7CisJCWVsc2UKKwkJCWRvX3dhcm4oIlxu Iik7CisJfSBlbHNlCisJCWRvX3dhcm4oXygiLCB3b3VsZCBqdW5rIGVudHJ5 XG4iKSk7CisJcmV0dXJuICFub19tb2RpZnk7Cit9CisKIC8qCiAgKiBwcm9j ZXNzIGEgbGVhZiBibG9jaywgYWxzbyBjaGVja3MgZm9yIC4uIGVudHJ5CiAg KiBhbmQgY29ycmVjdHMgaXQgdG8gbWF0Y2ggd2hhdCB3ZSB0aGluayAuLiBz aG91bGQgYmUKQEAgLTE0NDIsOSArMTQ4Nyw5IEBACiAJCSAqIHRha2UgY2Fy ZSBvZiBpdCB0aGVuLgogCQkgKi8KIAkJaWYgKGVudHJ5LT5uYW1lbGVuID09 IDIgJiYgbmFtZXN0LT5uYW1lWzBdID09ICcuJyAmJgotCQkJCW5hbWVzdC0+ bmFtZVsxXSA9PSAnLicpICB7CisJCQkJbmFtZXN0LT5uYW1lWzFdID09ICcu JykKIAkJCWNvbnRpbnVlOwotCQl9CisKIAkJQVNTRVJUKG5vX21vZGlmeSB8 fCAhdmVyaWZ5X2ludW0obXAsIGxpbm8pKTsKIAogCQkvKgpAQCAtMTQ2NCwx NyArMTUwOSw2IEBACiAJCX0KIAogCQkvKgotCQkgKiBzcGVjaWFsIGNhc2Ug dGhlICJsb3N0K2ZvdW5kIiBlbnRyeSBpZiBwb2ludGluZwotCQkgKiB0byB3 aGVyZSB3ZSB0aGluayBsb3N0K2ZvdW5kIHNob3VsZCBiZS4gIGlmIHRoYXQn cwotCQkgKiB0aGUgY2FzZSwgdGhhdCdzIHRoZSBvbmUgd2UgY3JlYXRlZCBp biBwaGFzZSA2LgotCQkgKiBqdXN0IHNraXAgaXQuICBubyBuZWVkIHRvIHBy b2Nlc3MgaXQgYW5kIGl0J3MgLi4KLQkJICogbGluayBpcyBhbHJlYWR5IGFj Y291bnRlZCBmb3IuCi0JCSAqLwotCi0JCWlmIChsaW5vID09IG9ycGhhbmFn ZV9pbm8gJiYgc3RyY21wKGZuYW1lLCBPUlBIQU5BR0UpID09IDApCi0JCQlj b250aW51ZTsKLQotCQkvKgogCQkgKiBza2lwIGVudHJpZXMgd2l0aCBib2d1 cyBpbnVtYmVycyBpZiB3ZSdyZSBpbiBubyBtb2RpZnkgbW9kZQogCQkgKi8K IAkJaWYgKG5vX21vZGlmeSAmJiB2ZXJpZnlfaW51bShtcCwgbGlubykpCkBA IC0xNDg4LDE4ICsxNTIyLDEyIEBACiAKIAkJaWYgKGlyZWMgPT0gTlVMTCkg IHsKIAkJCW5iYWQrKzsKLQkJCWRvX3dhcm4oCi0JXygiZW50cnkgXCIlc1wi IGluIGRpciBpbm9kZSAlbGx1IHBvaW50cyB0byBub24tZXhpc3RlbnQgaW5v ZGUsICIpLAotCQkJCWZuYW1lLCBpbm8pOwotCi0JCQlpZiAoIW5vX21vZGlm eSkgIHsKKwkJCWlmIChlbnRyeV9qdW5rZWQoXygiZW50cnkgXCIlc1wiIGlu IGRpciBpbm9kZSAlbGx1ICIKKwkJCQkJInBvaW50cyB0byBub24tZXhpc3Rl bnQgaW5vZGUgJWxsdSIpLAorCQkJCQlmbmFtZSwgaW5vLCBsaW5vKSkgewog CQkJCW5hbWVzdC0+bmFtZVswXSA9ICcvJzsKIAkJCQkqZGlydHkgPSAxOwot CQkJCWRvX3dhcm4oXygibWFya2luZyBlbnRyeSB0byBiZSBqdW5rZWRcbiIp KTsKLQkJCX0gZWxzZSAgewotCQkJCWRvX3dhcm4oXygid291bGQganVuayBl bnRyeVxuIikpOwogCQkJfQotCiAJCQljb250aW51ZTsKIAkJfQogCkBAIC0x NTExLDUyICsxNTM5LDUxIEBACiAJCSAqIHJlYWxseSBpcyBmcmVlLgogCQkg Ki8KIAkJaWYgKGlzX2lub2RlX2ZyZWUoaXJlYywgaW5vX29mZnNldCkpICB7 Ci0JCQkvKgotCQkJICogZG9uJ3QgY29tcGxhaW4gaWYgdGhpcyBlbnRyeSBw b2ludHMgdG8gdGhlIG9sZAotCQkJICogYW5kIG5vdy1mcmVlIGxvc3QrZm91 bmQgaW5vZGUKLQkJCSAqLwotCQkJaWYgKHZlcmJvc2UgfHwgbm9fbW9kaWZ5 IHx8IGxpbm8gIT0gb2xkX29ycGhhbmFnZV9pbm8pCi0JCQkJZG9fd2FybigK LQkJXygiZW50cnkgXCIlc1wiIGluIGRpciBpbm9kZSAlbGx1IHBvaW50cyB0 byBmcmVlIGlub2RlICVsbHUiKSwKLQkJCQkJZm5hbWUsIGlubywgbGlubyk7 CiAJCQluYmFkKys7Ci0KLQkJCWlmICghbm9fbW9kaWZ5KSAgewotCQkJCWlm ICh2ZXJib3NlIHx8IGxpbm8gIT0gb2xkX29ycGhhbmFnZV9pbm8pCi0JCQkJ CWRvX3dhcm4oCi0JCQkJCV8oIiwgbWFya2luZyBlbnRyeSB0byBiZSBqdW5r ZWRcbiIpKTsKLQotCQkJCWVsc2UKLQkJCQkJZG9fd2FybigiXG4iKTsKKwkJ CWlmIChlbnRyeV9qdW5rZWQoXygiZW50cnkgXCIlc1wiIGluIGRpciBpbm9k ZSAlbGx1ICIKKwkJCQkJInBvaW50cyB0byBmcmVlIGlub2RlICVsbHUiKSwK KwkJCQkJZm5hbWUsIGlubywgbGlubykpIHsKIAkJCQluYW1lc3QtPm5hbWVb MF0gPSAnLyc7CiAJCQkJKmRpcnR5ID0gMTsKLQkJCX0gZWxzZSAgewotCQkJ CWRvX3dhcm4oXygiLCB3b3VsZCBqdW5rIGVudHJ5XG4iKSk7CiAJCQl9Ci0K IAkJCWNvbnRpbnVlOwogCQl9CiAKIAkJLyoKKwkJICogY2hlY2sgaWYgdGhp cyBpbm9kZSBpcyBsb3N0K2ZvdW5kIGRpciBpbiB0aGUgcm9vdAorCQkgKi8K KwkJaWYgKGlubyA9PSBtcC0+bV9zYi5zYl9yb290aW5vICYmIHN0cmNtcChm bmFtZSwgT1JQSEFOQUdFKSA9PSAwKSB7CisJCQkvKiByb290IGlub2RlLCAi bG9zdCtmb3VuZCIsIGlmIGl0J3Mgbm90IGEgZGlyZWN0b3J5LAorCQkJICog dHJhc2ggaXQsIG90aGVyd2lzZSwgYXNzaWduIGl0ICovCisJCQlpZiAoIWlu b2RlX2lzYWRpcihpcmVjLCBpbm9fb2Zmc2V0KSkgeworCQkJCW5iYWQrKzsK KwkJCQlpZiAoZW50cnlfanVua2VkKF8oIiVzIChpbm8gJWxsdSkgaW4gcm9v dCAiCisJCQkJCQkiKCVsbHUpIGlzIG5vdCBhIGRpcmVjdG9yeSIpLAorCQkJ CQkJT1JQSEFOQUdFLCBsaW5vLCBpbm8pKSB7CisJCQkJCW5hbWVzdC0+bmFt ZVswXSA9ICcvJzsKKwkJCQkJKmRpcnR5ID0gMTsKKwkJCQl9CisJCQkJY29u dGludWU7CisJCQl9CisJCQkvKgorCQkJICogaWYgdGhpcyBpcyBhIGR1cCwg aXQgd2lsbCBiZSBwaWNrZWQgdXAgYmVsb3csCisJCQkgKiBvdGhlcndpc2Us IG1hcmsgaXQgYXMgdGhlIG9ycGhhbmFnZSBmb3IgbGF0ZXIuCisJCQkgKi8K KwkJCWlmICghb3JwaGFuYWdlX2lubykKKwkJCQlvcnBoYW5hZ2VfaW5vID0g bGlubzsKKwkJfQorCQkvKgogCQkgKiBjaGVjayBmb3IgZHVwbGljYXRlIG5h bWVzIGluIGRpcmVjdG9yeS4KIAkJICovCiAJCWlmICghZGlyX2hhc2hfYWRk KGhhc2h0YWIsIChkYV9ibm8gPDwgbXAtPm1fc2Iuc2JfYmxvY2tsb2cpICsK LQkJCQkJCWVudHJ5LT5uYW1laWR4LAotCQkJCWxpbm8sIGVudHJ5LT5uYW1l bGVuLCBuYW1lc3QtPm5hbWUpKSB7Ci0JCQlkb193YXJuKAotCQlfKCJlbnRy eSBcIiVzXCIgKGlubyAlbGx1KSBpbiBkaXIgJWxsdSBpcyBhIGR1cGxpY2F0 ZSBuYW1lIiksCi0JCQkJZm5hbWUsIGxpbm8sIGlubyk7CisJCQkJZW50cnkt Pm5hbWVpZHgsIGxpbm8sIGVudHJ5LT5uYW1lbGVuLAorCQkJCW5hbWVzdC0+ bmFtZSkpIHsKIAkJCW5iYWQrKzsKLQkJCWlmICghbm9fbW9kaWZ5KSB7Ci0J CQkJaWYgKHZlcmJvc2UpCi0JCQkJCWRvX3dhcm4oCi0JCQkJCV8oIiwgbWFy a2luZyBlbnRyeSB0byBiZSBqdW5rZWRcbiIpKTsKLQkJCQllbHNlCi0JCQkJ CWRvX3dhcm4oIlxuIik7CisJCQlpZiAoZW50cnlfanVua2VkKF8oImVudHJ5 IFwiJXNcIiAoaW5vICVsbHUpIGluIGRpciAiCisJCQkJCSIlbGx1IGlzIGEg ZHVwbGljYXRlIG5hbWUiKSwKKwkJCQkJZm5hbWUsIGxpbm8sIGlubykpIHsK IAkJCQluYW1lc3QtPm5hbWVbMF0gPSAnLyc7CiAJCQkJKmRpcnR5ID0gMTsK LQkJCX0gZWxzZSB7Ci0JCQkJZG9fd2FybihfKCIsIHdvdWxkIGp1bmsgZW50 cnlcbiIpKTsKIAkJCX0KIAkJCWNvbnRpbnVlOwogCQl9CkBAIC0xNjA0LDcg KzE2MzEsNyBAQAogCQkJaWYgKCFub19tb2RpZnkpICB7CiAJCQkJbmFtZXN0 LT5uYW1lWzBdID0gJy8nOwogCQkJCSpkaXJ0eSA9IDE7Ci0JCQkJaWYgKHZl cmJvc2UgfHwgbGlubyAhPSBvbGRfb3JwaGFuYWdlX2lubykKKwkJCQlpZiAo dmVyYm9zZSkKIAkJCQkJZG9fd2FybigKIAkJCQkJXygiXHR3aWxsIGNsZWFy IGVudHJ5IFwiJXNcIlxuIiksCiAJCQkJCQlmbmFtZSk7CkBAIC0yMTU1LDIx ICsyMTgyLDc1IEBACiAJCXB0ciArPSBYRlNfRElSMl9EQVRBX0VOVFNJWkUo ZGVwLT5uYW1lbGVuKTsKIAkJaW51bSA9IElOVF9HRVQoZGVwLT5pbnVtYmVy LCBBUkNIX0NPTlZFUlQpOwogCQlsYXN0ZnJlZSA9IDA7CisKKwkJaXJlYyA9 IGZpbmRfaW5vZGVfcmVjKFhGU19JTk9fVE9fQUdOTyhtcCwgaW51bSksCisJ CQkJCVhGU19JTk9fVE9fQUdJTk8obXAsIGludW0pKTsKKwkJaWYgKGlyZWMg PT0gTlVMTCkgIHsKKwkJCW5iYWQrKzsKKwkJCWlmIChlbnRyeV9qdW5rZWQo XygiZW50cnkgXCIlc1wiIGluIGRpcmVjdG9yeSBpbm9kZSAiCisJCQkJCSIl bGx1IHBvaW50cyB0byBub24tZXhpc3RlbnQgaW5vZGUgJWxsdSIpLAorCQkJ CQlmbmFtZSwgaXAtPmlfaW5vLCBpbnVtKSkgeworCQkJCWRlcC0+bmFtZVsw XSA9ICcvJzsKKwkJCQlsaWJ4ZnNfZGlyMl9kYXRhX2xvZ19lbnRyeSh0cCwg YnAsIGRlcCk7CisJCQl9CisJCQljb250aW51ZTsKKwkJfQorCQlpbm9fb2Zm c2V0ID0gWEZTX0lOT19UT19BR0lOTyhtcCwgaW51bSkgLSBpcmVjLT5pbm9f c3RhcnRudW07CisKKwkJLyoKKwkJICogaWYgaXQncyBhIGZyZWUgaW5vZGUs IGJsb3cgb3V0IHRoZSBlbnRyeS4KKwkJICogYnkgbm93LCBhbnkgaW5vZGUg dGhhdCB3ZSB0aGluayBpcyBmcmVlCisJCSAqIHJlYWxseSBpcyBmcmVlLgor CQkgKi8KKwkJaWYgKGlzX2lub2RlX2ZyZWUoaXJlYywgaW5vX29mZnNldCkp ICB7CisJCQluYmFkKys7CisJCQlpZiAoZW50cnlfanVua2VkKF8oImVudHJ5 IFwiJXNcIiBpbiBkaXJlY3RvcnkgaW5vZGUgIgorCQkJCQkiJWxsdSBwb2lu dHMgdG8gZnJlZSBpbm9kZSAlbGx1IiksCisJCQkJCWZuYW1lLCBpcC0+aV9p bm8sIGludW0pKSB7CisJCQkJZGVwLT5uYW1lWzBdID0gJy8nOworCQkJCWxp Ynhmc19kaXIyX2RhdGFfbG9nX2VudHJ5KHRwLCBicCwgZGVwKTsKKwkJCX0K KwkJCWNvbnRpbnVlOworCQl9CisKKwkJLyoKKwkJICogY2hlY2sgaWYgdGhp cyBpbm9kZSBpcyBsb3N0K2ZvdW5kIGRpciBpbiB0aGUgcm9vdAorCQkgKi8K KwkJaWYgKGludW0gPT0gbXAtPm1fc2Iuc2Jfcm9vdGlubyAmJiBzdHJjbXAo Zm5hbWUsIE9SUEhBTkFHRSkgPT0gMCkgeworCQkJLyoKKwkJCSAqIGlmIGl0 J3Mgbm90IGEgZGlyZWN0b3J5LCB0cmFzaCBpdAorCQkJICovCisJCQlpZiAo IWlub2RlX2lzYWRpcihpcmVjLCBpbm9fb2Zmc2V0KSkgeworCQkJCW5iYWQr KzsKKwkJCQlpZiAoZW50cnlfanVua2VkKF8oIiVzIChpbm8gJWxsdSkgaW4g cm9vdCAiCisJCQkJCQkiKCVsbHUpIGlzIG5vdCBhIGRpcmVjdG9yeSIpLAor CQkJCQkJT1JQSEFOQUdFLCBpbnVtLCBpcC0+aV9pbm8pKSB7CisJCQkJCWRl cC0+bmFtZVswXSA9ICcvJzsKKwkJCQkJbGlieGZzX2RpcjJfZGF0YV9sb2df ZW50cnkodHAsIGJwLCBkZXApOworCQkJCX0KKwkJCQljb250aW51ZTsKKwkJ CX0KKwkJCS8qCisJCQkgKiBpZiB0aGlzIGlzIGEgZHVwLCBpdCB3aWxsIGJl IHBpY2tlZCB1cCBiZWxvdywKKwkJCSAqIG90aGVyd2lzZSwgbWFyayBpdCBh cyB0aGUgb3JwaGFuYWdlIGZvciBsYXRlci4KKwkJCSAqLworCQkJaWYgKCFv cnBoYW5hZ2VfaW5vKQorCQkJCW9ycGhhbmFnZV9pbm8gPSBpbnVtOworCQl9 CisKKwkJLyoKKwkJICogY2hlY2sgZm9yIGR1cGxpY2F0ZSBuYW1lcyBpbiBk aXJlY3RvcnkuCisJCSAqLwogCQlpZiAoIWRpcl9oYXNoX2FkZChoYXNodGFi LCBhZGRyLCBpbnVtLCBkZXAtPm5hbWVsZW4sCiAJCQkJZGVwLT5uYW1lKSkg ewotCQkJZG9fd2FybigKLQkJXygiZW50cnkgXCIlc1wiIChpbm8gJWxsdSkg aW4gZGlyICVsbHUgaXMgYSBkdXBsaWNhdGUgbmFtZSIpLAotCQkJCWZuYW1l LCBpbnVtLCBpcC0+aV9pbm8pOwotCQkJaWYgKCFub19tb2RpZnkpIHsKLQkJ CQlpZiAodmVyYm9zZSkKLQkJCQkJZG9fd2FybigKLQkJCQkJXygiLCBtYXJr aW5nIGVudHJ5IHRvIGJlIGp1bmtlZFxuIikpOwotCQkJCWVsc2UKLQkJCQkJ ZG9fd2FybigiXG4iKTsKLQkJCX0gZWxzZSB7Ci0JCQkJZG9fd2FybihfKCIs IHdvdWxkIGp1bmsgZW50cnlcbiIpKTsKKwkJCW5iYWQrKzsKKwkJCWlmIChl bnRyeV9qdW5rZWQoXygiZW50cnkgXCIlc1wiIChpbm8gJWxsdSkgaW4gZGly ICIKKwkJCQkJIiVsbHUgaXMgYSBkdXBsaWNhdGUgbmFtZSIpLAorCQkJCQlm bmFtZSwgaW51bSwgaXAtPmlfaW5vKSkgeworCQkJCWRlcC0+bmFtZVswXSA9 ICcvJzsKKwkJCQlsaWJ4ZnNfZGlyMl9kYXRhX2xvZ19lbnRyeSh0cCwgYnAs IGRlcCk7CiAJCQl9Ci0JCQlkZXAtPm5hbWVbMF0gPSAnLyc7CisJCQljb250 aW51ZTsKIAkJfQogCQkvKgogCQkgKiBza2lwIGJvZ3VzIGVudHJpZXMgKGxl YWRpbmcgJy8nKS4gIHRoZXknbGwgYmUgZGVsZXRlZApAQCAtMjIxMiw2OCAr MjI5MywxMSBAQAogCQkJY29udGludWU7CiAJCX0KIAkJLyoKLQkJICogc3Bl Y2lhbCBjYXNlIHRoZSAibG9zdCtmb3VuZCIgZW50cnkgaWYgcG9pbnRpbmcK LQkJICogdG8gd2hlcmUgd2UgdGhpbmsgbG9zdCtmb3VuZCBzaG91bGQgYmUu ICBpZiB0aGF0J3MKLQkJICogdGhlIGNhc2UsIHRoYXQncyB0aGUgb25lIHdl IGNyZWF0ZWQgaW4gcGhhc2UgNi4KLQkJICoganVzdCBza2lwIGl0LiAgbm8g bmVlZCB0byBwcm9jZXNzIGl0IGFuZCBpdCdzIC4uCi0JCSAqIGxpbmsgaXMg YWxyZWFkeSBhY2NvdW50ZWQgZm9yLgotCQkgKi8KLQkJaWYgKGludW0gPT0g b3JwaGFuYWdlX2lubyAmJiBzdHJjbXAoZm5hbWUsIE9SUEhBTkFHRSkgPT0g MCkKLQkJCWNvbnRpbnVlOwotCQkvKgogCQkgKiBza2lwIGVudHJpZXMgd2l0 aCBib2d1cyBpbnVtYmVycyBpZiB3ZSdyZSBpbiBubyBtb2RpZnkgbW9kZQog CQkgKi8KIAkJaWYgKG5vX21vZGlmeSAmJiB2ZXJpZnlfaW51bShtcCwgaW51 bSkpCiAJCQljb250aW51ZTsKIAkJLyoKLQkJICogb2ssIG5vdyBoYW5kbGUg dGhlIHJlc3Qgb2YgdGhlIGNhc2VzIGJlc2lkZXMgJy4nIGFuZCAnLi4nCi0J CSAqLwotCQlpcmVjID0gZmluZF9pbm9kZV9yZWMoWEZTX0lOT19UT19BR05P KG1wLCBpbnVtKSwKLQkJCQkJWEZTX0lOT19UT19BR0lOTyhtcCwgaW51bSkp OwotCQlpZiAoaXJlYyA9PSBOVUxMKSAgewotCQkJbmJhZCsrOwotCQkJZG9f d2FybihfKCJlbnRyeSBcIiVzXCIgaW4gZGlyZWN0b3J5IGlub2RlICVsbHUg cG9pbnRzICIKLQkJCQkgICJ0byBub24tZXhpc3RlbnQgaW5vZGUsICIpLAot CQkJCWZuYW1lLCBpcC0+aV9pbm8pOwotCQkJaWYgKCFub19tb2RpZnkpICB7 Ci0JCQkJZGVwLT5uYW1lWzBdID0gJy8nOwotCQkJCWxpYnhmc19kaXIyX2Rh dGFfbG9nX2VudHJ5KHRwLCBicCwgZGVwKTsKLQkJCQlkb193YXJuKF8oIm1h cmtpbmcgZW50cnkgdG8gYmUganVua2VkXG4iKSk7Ci0JCQl9IGVsc2UgIHsK LQkJCQlkb193YXJuKF8oIndvdWxkIGp1bmsgZW50cnlcbiIpKTsKLQkJCX0K LQkJCWNvbnRpbnVlOwotCQl9Ci0JCWlub19vZmZzZXQgPSBYRlNfSU5PX1RP X0FHSU5PKG1wLCBpbnVtKSAtIGlyZWMtPmlub19zdGFydG51bTsKLQkJLyoK LQkJICogaWYgaXQncyBhIGZyZWUgaW5vZGUsIGJsb3cgb3V0IHRoZSBlbnRy eS4KLQkJICogYnkgbm93LCBhbnkgaW5vZGUgdGhhdCB3ZSB0aGluayBpcyBm cmVlCi0JCSAqIHJlYWxseSBpcyBmcmVlLgotCQkgKi8KLQkJaWYgKGlzX2lu b2RlX2ZyZWUoaXJlYywgaW5vX29mZnNldCkpICB7Ci0JCQkvKgotCQkJICog ZG9uJ3QgY29tcGxhaW4gaWYgdGhpcyBlbnRyeSBwb2ludHMgdG8gdGhlIG9s ZAotCQkJICogYW5kIG5vdy1mcmVlIGxvc3QrZm91bmQgaW5vZGUKLQkJCSAq LwotCQkJaWYgKHZlcmJvc2UgfHwgbm9fbW9kaWZ5IHx8IGludW0gIT0gb2xk X29ycGhhbmFnZV9pbm8pCi0JCQkJZG9fd2FybigKLQlfKCJlbnRyeSBcIiVz XCIgaW4gZGlyZWN0b3J5IGlub2RlICVsbHUgcG9pbnRzIHRvIGZyZWUgaW5v ZGUgJWxsdSIpLAotCQkJCQlmbmFtZSwgaXAtPmlfaW5vLCBpbnVtKTsKLQkJ CW5iYWQrKzsKLQkJCWlmICghbm9fbW9kaWZ5KSAgewotCQkJCWlmICh2ZXJi b3NlIHx8IGludW0gIT0gb2xkX29ycGhhbmFnZV9pbm8pCi0JCQkJCWRvX3dh cm4oCi0JCQkJCV8oIiwgbWFya2luZyBlbnRyeSB0byBiZSBqdW5rZWRcbiIp KTsKLQkJCQllbHNlCi0JCQkJCWRvX3dhcm4oIlxuIik7Ci0JCQkJZGVwLT5u YW1lWzBdID0gJy8nOwotCQkJCWxpYnhmc19kaXIyX2RhdGFfbG9nX2VudHJ5 KHRwLCBicCwgZGVwKTsKLQkJCX0gZWxzZSAgewotCQkJCWRvX3dhcm4oXygi LCB3b3VsZCBqdW5rIGVudHJ5XG4iKSk7Ci0JCQl9Ci0JCQljb250aW51ZTsK LQkJfQotCQkvKgogCQkgKiBjaGVjayBlYXN5IGNhc2UgZmlyc3QsIHJlZ3Vs YXIgaW5vZGUsIGp1c3QgYnVtcAogCQkgKiB0aGUgbGluayBjb3VudCBhbmQg Y29udGludWUKIAkJICovCkBAIC0yMzEyLDcgKzIzMzYsNyBAQAogCQkJaWYg KCFub19tb2RpZnkpICB7CiAJCQkJZGVwLT5uYW1lWzBdID0gJy8nOwogCQkJ CWxpYnhmc19kaXIyX2RhdGFfbG9nX2VudHJ5KHRwLCBicCwgZGVwKTsKLQkJ CQlpZiAodmVyYm9zZSB8fCBpbnVtICE9IG9sZF9vcnBoYW5hZ2VfaW5vKQor CQkJCWlmICh2ZXJib3NlKQogCQkJCQlkb193YXJuKAogCQkJCQlfKCJcdHdp bGwgY2xlYXIgZW50cnkgXCIlc1wiXG4iKSwKIAkJCQkJCWZuYW1lKTsKQEAg LTI3NjcsMzYgKzI3OTEsMTQgQEAKIAkJQVNTRVJUKG5vX21vZGlmeSB8fCBs aW5vICE9IE5VTExGU0lOTyk7CiAJCUFTU0VSVChub19tb2RpZnkgfHwgIXZl cmlmeV9pbnVtKG1wLCBsaW5vKSk7CiAKLQkJLyoKLQkJICogc3BlY2lhbCBj YXNlIHRoZSAibG9zdCtmb3VuZCIgZW50cnkgaWYgaXQncyBwb2ludGluZwot CQkgKiB0byB3aGVyZSB3ZSB0aGluayBsb3N0K2ZvdW5kIHNob3VsZCBiZS4g IGlmIHRoYXQncwotCQkgKiB0aGUgY2FzZSwgdGhhdCdzIHRoZSBvbmUgd2Ug Y3JlYXRlZCBpbiBwaGFzZSA2LgotCQkgKiBqdXN0IHNraXAgaXQuICBubyBu ZWVkIHRvIHByb2Nlc3MgaXQgYW5kIGl0cyAuLgotCQkgKiBsaW5rIGlzIGFs cmVhZHkgYWNjb3VudGVkIGZvci4gIEFsc28gc2tpcCBlbnRyaWVzCi0JCSAq IHdpdGggYm9ndXMgaW5vZGUgbnVtYmVycyBpZiB3ZSdyZSBpbiBubyBtb2Rp ZnkgbW9kZS4KLQkJICovCi0KLQkJaWYgKChsaW5vID09IG9ycGhhbmFnZV9p bm8gJiYgc3RyY21wKGZuYW1lLCBPUlBIQU5BR0UpID09IDApCi0JCQkJfHwg KG5vX21vZGlmeSAmJiB2ZXJpZnlfaW51bShtcCwgbGlubykpKSB7Ci0JCQlu ZXh0X3NmZSA9ICh4ZnNfZGlyX3NmX2VudHJ5X3QgKikKLQkJCQkoKF9fcHNp bnRfdCkgc2ZfZW50cnkgKwotCQkJCVhGU19ESVJfU0ZfRU5UU0laRV9CWUVO VFJZKHNmX2VudHJ5KSk7Ci0JCQljb250aW51ZTsKLQkJfQotCiAJCWlyZWMg PSBmaW5kX2lub2RlX3JlYyhYRlNfSU5PX1RPX0FHTk8obXAsIGxpbm8pLAog CQkJCQlYRlNfSU5PX1RPX0FHSU5PKG1wLCBsaW5vKSk7Ci0KLQkJaWYgKGly ZWMgPT0gTlVMTCAmJiBub19tb2RpZnkpICB7Ci0JCQlkb193YXJuKAotXygi ZW50cnkgXCIlc1wiIGluIHNob3J0Zm9ybSBkaXIgJWxsdSByZWZlcmVuY2Vz IG5vbi1leGlzdGVudCBpbm8gJWxsdVxuIiksCisJCWlmIChpcmVjID09IE5V TEwpIHsKKwkJCWRvX3dhcm4oXygiZW50cnkgXCIlc1wiIGluIHNob3J0Zm9y bSBkaXIgJWxsdSAiCisJCQkJInJlZmVyZW5jZXMgbm9uLWV4aXN0ZW50IGlu byAlbGx1IiksCiAJCQkJZm5hbWUsIGlubywgbGlubyk7Ci0JCQlkb193YXJu KF8oIndvdWxkIGp1bmsgZW50cnlcbiIpKTsKLQkJCWNvbnRpbnVlOworCQkJ Z290byBkb19qdW5raXQ7CiAJCX0KLQotCQlBU1NFUlQoaXJlYyAhPSBOVUxM KTsKLQogCQlpbm9fb2Zmc2V0ID0gWEZTX0lOT19UT19BR0lOTyhtcCwgbGlu bykgLSBpcmVjLT5pbm9fc3RhcnRudW07CiAKIAkJLyoKQEAgLTI4MDQsNDIg KzI4MDYsNDIgQEAKIAkJICogYnkgbm93LCBhbnkgaW5vZGUgdGhhdCB3ZSB0 aGluayBpcyBmcmVlCiAJCSAqIHJlYWxseSBpcyBmcmVlLgogCQkgKi8KLQkJ aWYgKGlzX2lub2RlX2ZyZWUoaXJlYywgaW5vX29mZnNldCkpICB7CisJCWlm ICghaXNfaW5vZGVfZnJlZShpcmVjLCBpbm9fb2Zmc2V0KSkgIHsKKwkJCWRv X3dhcm4oXygiZW50cnkgXCIlc1wiIGluIHNob3J0Zm9ybSBkaXIgaW5vZGUg JWxsdSAiCisJCQkJInBvaW50cyB0byBmcmVlIGlub2RlICVsbHUiKSwgZm5h bWUsIGlubywgbGlubyk7CisJCQlnb3RvIGRvX2p1bmtpdDsKKwkJfQorCQkv KgorCQkgKiBjaGVjayBpZiB0aGlzIGlub2RlIGlzIGxvc3QrZm91bmQgZGly IGluIHRoZSByb290CisJCSAqLworCQlpZiAoaW5vID09IG1wLT5tX3NiLnNi X3Jvb3Rpbm8gJiYgc3RyY21wKGZuYW1lLCBPUlBIQU5BR0UpID09IDApIHsK IAkJCS8qCi0JCQkgKiBkb24ndCBjb21wbGFpbiBpZiB0aGlzIGVudHJ5IHBv aW50cyB0byB0aGUgb2xkCi0JCQkgKiBhbmQgbm93LWZyZWUgbG9zdCtmb3Vu ZCBpbm9kZQorCQkJICogaWYgaXQncyBub3QgYSBkaXJlY3RvcnksIHRyYXNo IGl0CiAJCQkgKi8KLQkJCWlmICh2ZXJib3NlIHx8IG5vX21vZGlmeSB8fCBs aW5vICE9IG9sZF9vcnBoYW5hZ2VfaW5vKQotCQkJCWRvX3dhcm4oCi1fKCJl bnRyeSBcIiVzXCIgaW4gc2hvcnRmb3JtIGRpciBpbm9kZSAlbGx1IHBvaW50 cyB0byBmcmVlIGlub2RlICVsbHVcbiIpLAotCQkJCQlmbmFtZSwgaW5vLCBs aW5vKTsKLQotCQkJaWYgKCFub19tb2RpZnkpICB7Ci0JCQkJanVua2l0ID0g MTsKLQkJCX0gZWxzZSAgewotCQkJCWRvX3dhcm4oXygid291bGQganVuayBl bnRyeSBcIiVzXCJcbiIpLAotCQkJCQlmbmFtZSk7CisJCQlpZiAoIWlub2Rl X2lzYWRpcihpcmVjLCBpbm9fb2Zmc2V0KSkgeworCQkJCWRvX3dhcm4oXygi JXMgKGlubyAlbGx1KSBpbiByb290ICglbGx1KSBpcyBub3QgIgorCQkJCQki YSBkaXJlY3RvcnkiKSwgT1JQSEFOQUdFLCBsaW5vLCBpbm8pOworCQkJCWdv dG8gZG9fanVua2l0OwogCQkJfQotCQl9IGVsc2UgaWYgKCFkaXJfaGFzaF9h ZGQoaGFzaHRhYiwKLQkJCQkoeGZzX2RpcjJfZGF0YXB0cl90KShzZl9lbnRy eSAtICZzZi0+bGlzdFswXSksCi0JCQkJbGlubywgc2ZfZW50cnktPm5hbWVs ZW4sIHNmX2VudHJ5LT5uYW1lKSkgewogCQkJLyoKLQkJCSAqIGNoZWNrIGZv ciBkdXBsaWNhdGUgbmFtZXMgaW4gZGlyZWN0b3J5LgorCQkJICogaWYgdGhp cyBpcyBhIGR1cCwgaXQgd2lsbCBiZSBwaWNrZWQgdXAgYmVsb3csCisJCQkg KiBvdGhlcndpc2UsIG1hcmsgaXQgYXMgdGhlIG9ycGhhbmFnZSBmb3IgbGF0 ZXIuCiAJCQkgKi8KLQkJCWRvX3dhcm4oCi0JCV8oImVudHJ5IFwiJXNcIiAo aW5vICVsbHUpIGluIGRpciAlbGx1IGlzIGEgZHVwbGljYXRlIG5hbWUiKSwK LQkJCQlmbmFtZSwgbGlubywgaW5vKTsKLQkJCWlmICghbm9fbW9kaWZ5KSB7 Ci0JCQkJanVua2l0ID0gMTsKLQkJCQlpZiAodmVyYm9zZSkKLQkJCQkJZG9f d2FybigKLQkJCQkJXygiLCBtYXJraW5nIGVudHJ5IHRvIGJlIGp1bmtlZFxu IikpOwotCQkJCWVsc2UKLQkJCQkJZG9fd2FybigiXG4iKTsKLQkJCX0gZWxz ZSB7Ci0JCQkJZG9fd2FybihfKCIsIHdvdWxkIGp1bmsgZW50cnlcbiIpKTsK LQkJCX0KLQkJfSBlbHNlIGlmICghaW5vZGVfaXNhZGlyKGlyZWMsIGlub19v ZmZzZXQpKSAgeworCQkJaWYgKCFvcnBoYW5hZ2VfaW5vKQorCQkJCW9ycGhh bmFnZV9pbm8gPSBsaW5vOworCQl9CisJCS8qCisJCSAqIGNoZWNrIGZvciBk dXBsaWNhdGUgbmFtZXMgaW4gZGlyZWN0b3J5LgorCQkgKi8KKwkJaWYgKCFk aXJfaGFzaF9hZGQoaGFzaHRhYiwKKwkJCQkoeGZzX2RpcjJfZGF0YXB0cl90 KShzZl9lbnRyeSAtICZzZi0+bGlzdFswXSksCisJCQkJbGlubywgc2ZfZW50 cnktPm5hbWVsZW4sIHNmX2VudHJ5LT5uYW1lKSkgeworCQkJZG9fd2Fybihf KCJlbnRyeSBcIiVzXCIgKGlubyAlbGx1KSBpbiBkaXIgJWxsdSBpcyBhICIK KwkJCQkiZHVwbGljYXRlIG5hbWUiKSwgZm5hbWUsIGxpbm8sIGlubyk7CisJ CQlnb3RvIGRvX2p1bmtpdDsKKwkJfQorCisJCWlmICghaW5vZGVfaXNhZGly KGlyZWMsIGlub19vZmZzZXQpKSAgewogCQkJLyoKIAkJCSAqIGNoZWNrIGVh c3kgY2FzZSBmaXJzdCwgcmVndWxhciBpbm9kZSwganVzdCBidW1wCiAJCQkg KiB0aGUgbGluayBjb3VudCBhbmQgY29udGludWUKQEAgLTI4NjAsOCArMjg2 Miw4IEBACiAJCQkgKi8KIAkJCWlmIChpc19pbm9kZV9yZWFjaGVkKGlyZWMs IGlub19vZmZzZXQpKSAgewogCQkJCWp1bmtpdCA9IDE7Ci0JCQkJZG9fd2Fy bigKLV8oImVudHJ5IFwiJXNcIiBpbiBkaXIgJWxsdSByZWZlcmVuY2VzIGFs cmVhZHkgY29ubmVjdGVkIGRpciBpbm8gJWxsdSxcbiIpLAorCQkJCWRvX3dh cm4oXygiZW50cnkgXCIlc1wiIGluIGRpciAlbGx1IHJlZmVyZW5jZXMgIgor CQkJCQkiYWxyZWFkeSBjb25uZWN0ZWQgZGlyIGlubyAlbGx1LFxuIiksCiAJ CQkJCWZuYW1lLCBpbm8sIGxpbm8pOwogCQkJfSBlbHNlIGlmIChwYXJlbnQg PT0gaW5vKSAgewogCQkJCWFkZF9pbm9kZV9yZWFjaGVkKGlyZWMsIGlub19v ZmZzZXQpOwpAQCAtMjg3MiwxMyArMjg3NCwxNCBAQAogCQkJCQlwdXNoX2Rp cihzdGFjaywgbGlubyk7CiAJCQl9IGVsc2UgIHsKIAkJCQlqdW5raXQgPSAx OwotCQkJCWRvX3dhcm4oCi1fKCJlbnRyeSBcIiVzXCIgaW4gZGlyICVsbHUg bm90IGNvbnNpc3RlbnQgd2l0aCAuLiB2YWx1ZSAoJWxsdSkgaW4gZGlyIGlu byAlbGx1LFxuIiksCisJCQkJZG9fd2FybihfKCJlbnRyeSBcIiVzXCIgaW4g ZGlyICVsbHUgbm90ICIKKwkJCQkJImNvbnNpc3RlbnQgd2l0aCAuLiB2YWx1 ZSAoJWxsdSkgaW4gIgorCQkJCQkiZGlyIGlubyAlbGx1IiksCiAJCQkJCWZu YW1lLCBpbm8sIHBhcmVudCwgbGlubyk7CiAJCQl9CiAJCX0KLQogCQlpZiAo anVua2l0KSAgeworZG9fanVua2l0OgogCQkJaWYgKCFub19tb2RpZnkpICB7 CiAJCQkJdG1wX2VsZW4gPSBYRlNfRElSX1NGX0VOVFNJWkVfQllFTlRSWShz Zl9lbnRyeSk7CiAJCQkJdG1wX3NmZSA9ICh4ZnNfZGlyX3NmX2VudHJ5X3Qg KikKQEAgLTI5MTAsMTIgKzI5MTMsMTIgQEAKIAogCQkJCSppbm9fZGlydHkg PSAxOwogCi0JCQkJaWYgKHZlcmJvc2UgfHwgbGlubyAhPSBvbGRfb3JwaGFu YWdlX2lubykKLQkJCQkJZG9fd2FybigKLQkJCV8oImp1bmtpbmcgZW50cnkg XCIlc1wiIGluIGRpcmVjdG9yeSBpbm9kZSAlbGx1XG4iKSwKLQkJCQkJCWZu YW1lLCBsaW5vKTsKKwkJCQlpZiAodmVyYm9zZSkKKwkJCQkJZG9fd2Fybihf KCJqdW5raW5nIGVudHJ5XG4iKSk7CisJCQkJZWxzZQorCQkJCQlkb193YXJu KCJcbiIpOwogCQkJfSBlbHNlICB7Ci0JCQkJZG9fd2FybihfKCJ3b3VsZCBq dW5rIGVudHJ5IFwiJXNcIlxuIiksIGZuYW1lKTsKKwkJCQlkb193YXJuKF8o IndvdWxkIGp1bmsgZW50cnlcbiIpLCBmbmFtZSk7CiAJCQl9CiAJCX0KIApA QCAtMzE3NCwyMyArMzE3Nyw2IEBACiAJCUFTU0VSVChub19tb2RpZnkgfHwg IXZlcmlmeV9pbnVtKG1wLCBsaW5vKSk7CiAKIAkJLyoKLQkJICogc3BlY2lh bCBjYXNlIHRoZSAibG9zdCtmb3VuZCIgZW50cnkgaWYgaXQncyBwb2ludGlu ZwotCQkgKiB0byB3aGVyZSB3ZSB0aGluayBsb3N0K2ZvdW5kIHNob3VsZCBi ZS4gIGlmIHRoYXQncwotCQkgKiB0aGUgY2FzZSwgdGhhdCdzIHRoZSBvbmUg d2UgY3JlYXRlZCBpbiBwaGFzZSA2LgotCQkgKiBqdXN0IHNraXAgaXQuICBu byBuZWVkIHRvIHByb2Nlc3MgaXQgYW5kIGl0cyAuLgotCQkgKiBsaW5rIGlz IGFscmVhZHkgYWNjb3VudGVkIGZvci4KLQkJICovCi0KLQkJaWYgKGxpbm8g PT0gb3JwaGFuYWdlX2lubyAmJiBzdHJjbXAoZm5hbWUsIE9SUEhBTkFHRSkg PT0gMCkgewotCQkJaWYgKGxpbm8gPiBYRlNfRElSMl9NQVhfU0hPUlRfSU5V TSkKLQkJCQlpOCsrOwotCQkJbmV4dF9zZmVwID0gKHhmc19kaXIyX3NmX2Vu dHJ5X3QgKikKLQkJCQkoKF9fcHNpbnRfdCkgc2ZlcCArCi0JCQkJWEZTX0RJ UjJfU0ZfRU5UU0laRV9CWUVOVFJZKHNmcCwgc2ZlcCkpOwotCQkJY29udGlu dWU7Ci0JCX0KLQotCQkvKgogCQkgKiBBbHNvIHNraXAgZW50cmllcyB3aXRo IGJvZ3VzIGlub2RlIG51bWJlcnMgaWYgd2UncmUKIAkJICogaW4gbm8gbW9k aWZ5IG1vZGUuCiAJCSAqLwpAQCAtMzIwNSwxNiArMzE5MSwxMyBAQAogCQlp cmVjID0gZmluZF9pbm9kZV9yZWMoWEZTX0lOT19UT19BR05PKG1wLCBsaW5v KSwKIAkJCQkJWEZTX0lOT19UT19BR0lOTyhtcCwgbGlubykpOwogCi0JCWlm IChpcmVjID09IE5VTEwgJiYgbm9fbW9kaWZ5KSAgeworCQlpZiAoaXJlYyA9 PSBOVUxMKSAgewogCQkJZG9fd2FybihfKCJlbnRyeSBcIiVzXCIgaW4gc2hv cnRmb3JtIGRpcmVjdG9yeSAlbGx1ICIKLQkJCQkgICJyZWZlcmVuY2VzIG5v bi1leGlzdGVudCBpbm9kZSAlbGx1XG4iKSwKKwkJCQkgICJyZWZlcmVuY2Vz IG5vbi1leGlzdGVudCBpbm9kZSAlbGx1IiksCiAJCQkJZm5hbWUsIGlubywg bGlubyk7Ci0JCQlkb193YXJuKF8oIndvdWxkIGp1bmsgZW50cnlcbiIpKTsK LQkJCWNvbnRpbnVlOworCQkJZ290byBkb19qdW5raXQ7CiAJCX0KIAotCQlB U1NFUlQoaXJlYyAhPSBOVUxMKTsKLQogCQlpbm9fb2Zmc2V0ID0gWEZTX0lO T19UT19BR0lOTyhtcCwgbGlubykgLSBpcmVjLT5pbm9fc3RhcnRudW07CiAK IAkJLyoKQEAgLTMyMjMsNDIgKzMyMDYsNDEgQEAKIAkJICogcmVhbGx5IGlz IGZyZWUuCiAJCSAqLwogCQlpZiAoaXNfaW5vZGVfZnJlZShpcmVjLCBpbm9f b2Zmc2V0KSkgIHsKKwkJCWRvX3dhcm4oXygiZW50cnkgXCIlc1wiIGluIHNo b3J0Zm9ybSBkaXJlY3RvcnkgIgorCQkJCSAgImlub2RlICVsbHUgcG9pbnRz IHRvIGZyZWUgaW5vZGUgJWxsdSIpLAorCQkJCWZuYW1lLCBpbm8sIGxpbm8p OworCQkJZ290byBkb19qdW5raXQ7CisJCX0KKwkJLyoKKwkJICogY2hlY2sg aWYgdGhpcyBpbm9kZSBpcyBsb3N0K2ZvdW5kIGRpciBpbiB0aGUgcm9vdAor CQkgKi8KKwkJaWYgKGlubyA9PSBtcC0+bV9zYi5zYl9yb290aW5vICYmIHN0 cmNtcChmbmFtZSwgT1JQSEFOQUdFKSA9PSAwKSB7CiAJCQkvKgotCQkJICog ZG9uJ3QgY29tcGxhaW4gaWYgdGhpcyBlbnRyeSBwb2ludHMgdG8gdGhlIG9s ZAotCQkJICogYW5kIG5vdy1mcmVlIGxvc3QrZm91bmQgaW5vZGUKKwkJCSAq IGlmIGl0J3Mgbm90IGEgZGlyZWN0b3J5LCB0cmFzaCBpdAogCQkJICovCi0J CQlpZiAodmVyYm9zZSB8fCBub19tb2RpZnkgfHwgbGlubyAhPSBvbGRfb3Jw aGFuYWdlX2lubykKLQkJCQlkb193YXJuKF8oImVudHJ5IFwiJXNcIiBpbiBz aG9ydGZvcm0gZGlyZWN0b3J5ICIKLQkJCQkJICAiaW5vZGUgJWxsdSBwb2lu dHMgdG8gZnJlZSBpbm9kZSAiCi0JCQkJCSAgIiVsbHVcbiIpLAotCQkJCQlm bmFtZSwgaW5vLCBsaW5vKTsKLQotCQkJaWYgKCFub19tb2RpZnkpICB7Ci0J CQkJanVua2l0ID0gMTsKLQkJCX0gZWxzZSAgewotCQkJCWRvX3dhcm4oXygi d291bGQganVuayBlbnRyeSBcIiVzXCJcbiIpLAotCQkJCQlmbmFtZSk7CisJ CQlpZiAoIWlub2RlX2lzYWRpcihpcmVjLCBpbm9fb2Zmc2V0KSkgeworCQkJ CWRvX3dhcm4oXygiJXMgKGlubyAlbGx1KSBpbiByb290ICglbGx1KSBpcyBu b3QgIgorCQkJCQkiYSBkaXJlY3RvcnkiKSwgT1JQSEFOQUdFLCBsaW5vLCBp bm8pOworCQkJCWdvdG8gZG9fanVua2l0OwogCQkJfQotCQl9IGVsc2UgaWYg KCFkaXJfaGFzaF9hZGQoaGFzaHRhYiwgKHhmc19kaXIyX2RhdGFwdHJfdCkK LQkJCQkJKHNmZXAgLSBYRlNfRElSMl9TRl9GSVJTVEVOVFJZKHNmcCkpLAot CQkJCWxpbm8sIHNmZXAtPm5hbWVsZW4sIHNmZXAtPm5hbWUpKSB7CiAJCQkv KgotCQkJICogY2hlY2sgZm9yIGR1cGxpY2F0ZSBuYW1lcyBpbiBkaXJlY3Rv cnkuCisJCQkgKiBpZiB0aGlzIGlzIGEgZHVwLCBpdCB3aWxsIGJlIHBpY2tl ZCB1cCBiZWxvdywKKwkJCSAqIG90aGVyd2lzZSwgbWFyayBpdCBhcyB0aGUg b3JwaGFuYWdlIGZvciBsYXRlci4KIAkJCSAqLwotCQkJZG9fd2FybigKLQkJ XygiZW50cnkgXCIlc1wiIChpbm8gJWxsdSkgaW4gZGlyICVsbHUgaXMgYSBk dXBsaWNhdGUgbmFtZSIpLAotCQkJCWZuYW1lLCBsaW5vLCBpbm8pOwotCQkJ aWYgKCFub19tb2RpZnkpIHsKLQkJCQlqdW5raXQgPSAxOwotCQkJCWlmICh2 ZXJib3NlKQotCQkJCQlkb193YXJuKAotCQkJCQlfKCIsIG1hcmtpbmcgZW50 cnkgdG8gYmUganVua2VkXG4iKSk7Ci0JCQkJZWxzZQotCQkJCQlkb193YXJu KCJcbiIpOwotCQkJfSBlbHNlIHsKLQkJCQlkb193YXJuKF8oIiwgd291bGQg anVuayBlbnRyeVxuIikpOwotCQkJfQotCQl9IGVsc2UgaWYgKCFpbm9kZV9p c2FkaXIoaXJlYywgaW5vX29mZnNldCkpICB7CisJCQlpZiAoIW9ycGhhbmFn ZV9pbm8pCisJCQkJb3JwaGFuYWdlX2lubyA9IGxpbm87CisJCX0KKwkJLyoK KwkJICogY2hlY2sgZm9yIGR1cGxpY2F0ZSBuYW1lcyBpbiBkaXJlY3Rvcnku CisJCSAqLworCQlpZiAoIWRpcl9oYXNoX2FkZChoYXNodGFiLCAoeGZzX2Rp cjJfZGF0YXB0cl90KQorCQkJCQkoc2ZlcCAtIFhGU19ESVIyX1NGX0ZJUlNU RU5UUlkoc2ZwKSksCisJCQkJbGlubywgc2ZlcC0+bmFtZWxlbiwgc2ZlcC0+ bmFtZSkpIHsKKwkJCWRvX3dhcm4oXygiZW50cnkgXCIlc1wiIChpbm8gJWxs dSkgaW4gZGlyICVsbHUgaXMgYSAiCisJCQkJImR1cGxpY2F0ZSBuYW1lIiks IGZuYW1lLCBsaW5vLCBpbm8pOworCQkJZ290byBkb19qdW5raXQ7CisJCX0K KwkJaWYgKCFpbm9kZV9pc2FkaXIoaXJlYywgaW5vX29mZnNldCkpICB7CiAJ CQkvKgogCQkJICogY2hlY2sgZWFzeSBjYXNlIGZpcnN0LCByZWd1bGFyIGlu b2RlLCBqdXN0IGJ1bXAKIAkJCSAqIHRoZSBsaW5rIGNvdW50CkBAIC0zMjk1 LDYgKzMyNzcsNyBAQAogCQl9CiAKIAkJaWYgKGp1bmtpdCkgIHsKK2RvX2p1 bmtpdDoKIAkJCWlmICghbm9fbW9kaWZ5KSAgewogCQkJCXRtcF9lbGVuID0g WEZTX0RJUjJfU0ZfRU5UU0laRV9CWUVOVFJZKHNmcCwgc2ZlcCk7CiAJCQkJ dG1wX3NmZXAgPSAoeGZzX2RpcjJfc2ZfZW50cnlfdCAqKQpAQCAtMzMyNiwx MiArMzMwOSwxMiBAQAogCiAJCQkJKmlub19kaXJ0eSA9IDE7CiAKLQkJCQlp ZiAodmVyYm9zZSB8fCBsaW5vICE9IG9sZF9vcnBoYW5hZ2VfaW5vKQotCQkJ CQlkb193YXJuKF8oImp1bmtpbmcgZW50cnkgXCIlc1wiIGluICIKLQkJCQkJ CSAgImRpcmVjdG9yeSBpbm9kZSAlbGx1XG4iKSwKLQkJCQkJCWZuYW1lLCBs aW5vKTsKKwkJCQlpZiAodmVyYm9zZSkKKwkJCQkJZG9fd2FybihfKCJqdW5r aW5nIGVudHJ5XG4iKSk7CisJCQkJZWxzZQorCQkJCQlkb193YXJuKCJcbiIp OwogCQkJfSBlbHNlICB7Ci0JCQkJZG9fd2FybihfKCJ3b3VsZCBqdW5rIGVu dHJ5IFwiJXNcIlxuIiksIGZuYW1lKTsKKwkJCQlkb193YXJuKF8oIndvdWxk IGp1bmsgZW50cnlcbiIpKTsKIAkJCX0KIAkJfSBlbHNlIGlmIChsaW5vID4g WEZTX0RJUjJfTUFYX1NIT1JUX0lOVU0pCiAJCQlpOCsrOwpAQCAtMzQ2NSwy NSArMzQ0OCw2IEBACiAJCQkgKiBndWFyYW50ZWVkIGJ5IHBoYXNlIDMgYW5k L29yIGJlbG93LgogCQkJICovCiAJCQlhZGRfaW5vZGVfcmVhY2hlZChpcmVj LCBpbm9fb2Zmc2V0KTsKLQkJCS8qCi0JCQkgKiBhY2NvdW50IGZvciBsaW5r IGZvciB0aGUgb3JwaGFuYWdlCi0JCQkgKiAibG9zdCtmb3VuZCIuICBpZiB3 ZSdyZSBydW5uaW5nIGluCi0JCQkgKiBtb2RpZnkgbW9kZSBhbmQgaXQgYWxy ZWFkeSBleGlzdGVkLAotCQkJICogd2UgZGVsZXRlZCBpdCBzbyBpdCdzICcu LicgcmVmZXJlbmNlCi0JCQkgKiBuZXZlciBnb3QgY291bnRlZC4gIHNvIGFk ZCBpdCBoZXJlIGlmCi0JCQkgKiB3ZSdyZSBnb2luZyB0byBjcmVhdGUgbG9z dCtmb3VuZC4KLQkJCSAqCi0JCQkgKiBpZiB3ZSdyZSBydW5uaW5nIGluIG5v X21vZGlmeSBtb2RlLAotCQkJICogd2UgbmV2ZXIgZGVsZXRlZCBsb3N0K2Zv dW5kIGFuZCB3ZSdyZQotCQkJICogbm90IGdvaW5nIHRvIGNyZWF0ZSBpdCBz byBkbyBub3RoaW5nLgotCQkJICoKLQkJCSAqIGVpdGhlciB3YXksIHRoZSBj b3VudHMgd2lsbCBtYXRjaCB3aGVuCi0JCQkgKiB3ZSBsb29rIGF0IHRoZSBy b290IGlub2RlJ3MgbmxpbmtzCi0JCQkgKiBmaWVsZCBhbmQgY29tcGFyZSB0 aGF0IHRvIG91ciBpbmNvcmUKLQkJCSAqIGNvdW50IGluIHBoYXNlIDcuCi0J CQkgKi8KLQkJCWlmICghbm9fbW9kaWZ5KQotCQkJCWFkZF9pbm9kZV9yZWYo aXJlYywgaW5vX29mZnNldCk7CiAJCX0KIAogCQlhZGRfaW5vZGVfcmVmY2hl Y2tlZChpbm8sIGlyZWMsIGlub19vZmZzZXQpOwpAQCAtMzU2MiwzNiArMzUy Niw2IEBACiAKIAkJaGFzaHZhbCA9IDA7CiAKLQkJaWYgKCFub19tb2RpZnkg JiYgIW9ycGhhbmFnZV9lbnRlcmVkICYmCi0JCSAgICBpbm8gPT0gbXAtPm1f c2Iuc2Jfcm9vdGlubykgewotCQkJZG9fd2FybihfKCJyZS1lbnRlcmluZyAl cyBpbnRvIHJvb3QgZGlyZWN0b3J5XG4iKSwKLQkJCQlPUlBIQU5BR0UpOwot CQkJdHAgPSBsaWJ4ZnNfdHJhbnNfYWxsb2MobXAsIDApOwotCQkJbnJlcyA9 IFhGU19NS0RJUl9TUEFDRV9SRVMobXAsIHN0cmxlbihPUlBIQU5BR0UpKTsK LQkJCWVycm9yID0gbGlieGZzX3RyYW5zX3Jlc2VydmUodHAsIG5yZXMsCi0J CQkJCVhGU19NS0RJUl9MT0dfUkVTKG1wKSwgMCwKLQkJCQkJWEZTX1RSQU5T X1BFUk1fTE9HX1JFUywKLQkJCQkJWEZTX01LRElSX0xPR19DT1VOVCk7Ci0J CQlpZiAoZXJyb3IpCi0JCQkJcmVzX2ZhaWxlZChlcnJvcik7Ci0JCQlsaWJ4 ZnNfdHJhbnNfaWpvaW4odHAsIGlwLCAwKTsKLQkJCWxpYnhmc190cmFuc19p aG9sZCh0cCwgaXApOwotCQkJWEZTX0JNQVBfSU5JVCgmZmxpc3QsICZmaXJz dCk7Ci0JCQlpZiAoKGVycm9yID0gZGlyX2NyZWF0ZW5hbWUobXAsIHRwLCBp cCwgT1JQSEFOQUdFLAotCQkJCQkJc3RybGVuKE9SUEhBTkFHRSksCi0JCQkJ CQlvcnBoYW5hZ2VfaW5vLCAmZmlyc3QsICZmbGlzdCwKLQkJCQkJCW5yZXMp KSkKLQkJCQlkb19lcnJvcihfKCJjYW4ndCBtYWtlICVzIGVudHJ5IGluIHJv b3QgaW5vZGUgIgotCQkJCQkgICAiJWxsdSwgY3JlYXRlbmFtZSBlcnJvciAl ZFxuIiksCi0JCQkJCU9SUEhBTkFHRSwgaW5vLCBlcnJvcik7Ci0JCQlsaWJ4 ZnNfdHJhbnNfbG9nX2lub2RlKHRwLCBpcCwgWEZTX0lMT0dfQ09SRSk7Ci0J CQllcnJvciA9IGxpYnhmc19ibWFwX2ZpbmlzaCgmdHAsICZmbGlzdCwgZmly c3QsICZjb21taXR0ZWQpOwotCQkJQVNTRVJUKGVycm9yID09IDApOwotCQkJ bGlieGZzX3RyYW5zX2NvbW1pdCh0cCwKLQkJCQlYRlNfVFJBTlNfUkVMRUFT RV9MT0dfUkVTIHwgWEZTX1RSQU5TX1NZTkMsIDApOwotCQkJb3JwaGFuYWdl X2VudGVyZWQgPSAxOwotCQl9Ci0KIAkJLyoKIAkJICogaWYgd2UgaGF2ZSB0 byBjcmVhdGUgYSAuLiBmb3IgLywgZG8gaXQgbm93ICpiZWZvcmUqCiAJCSAq IHdlIGRlbGV0ZSB0aGUgYm9ndXMgZW50cmllcywgb3RoZXJ3aXNlIHRoZSBk aXJlY3RvcnkKQEAgLTM4MjMsNiArMzc1Nyw1MSBAQAogfQogCiBzdGF0aWMg dm9pZAorY2hlY2tfZm9yX29ycGhhbmVkX2lub2RlcygKKwl4ZnNfbW91bnRf dAkJKm1wLAorCWlub190cmVlX25vZGVfdAkJKmlyZWMpCit7CisJaW50CQkJ aTsKKwlpbnQJCQllcnI7CisJeGZzX2lub190CQlpbm87CisKKwlmb3IgKGkg PSAwOyBpIDwgWEZTX0lOT0RFU19QRVJfQ0hVTks7IGkrKykgIHsKKwkJQVNT RVJUKGlzX2lub2RlX2NvbmZpcm1lZChpcmVjLCBpKSk7CisJCWlmIChpc19p bm9kZV9mcmVlKGlyZWMsIGkpKQorCQkJY29udGludWU7CisKKwkJaWYgKCFp c19pbm9kZV9yZWFjaGVkKGlyZWMsIGkpKSB7CisJCQlBU1NFUlQoaW5vZGVf aXNhZGlyKGlyZWMsIGkpIHx8CisJCQkJbnVtX2lub2RlX3JlZmVyZW5jZXMo aXJlYywgaSkgPT0gMCk7CisJCQlpbm8gPSBYRlNfQUdJTk9fVE9fSU5PKG1w LCBpLCBpICsgaXJlYy0+aW5vX3N0YXJ0bnVtKTsKKwkJCWlmIChpbm9kZV9p c2FkaXIoaXJlYywgaSkpCisJCQkJZG9fd2FybihfKCJkaXNjb25uZWN0ZWQg ZGlyIGlub2RlICVsbHUsICIpLCBpbm8pOworCQkJZWxzZQorCQkJCWRvX3dh cm4oXygiZGlzY29ubmVjdGVkIGlub2RlICVsbHUsICIpLCBpbm8pOworCQkJ aWYgKCFub19tb2RpZnkpICB7CisJCQkgICAgCWlmICghb3JwaGFuYWdlX2lu bykKKwkJCQkJb3JwaGFuYWdlX2lubyA9IG1rX29ycGhhbmFnZShtcCk7CisJ CQkJaWYgKCFvcnBoYW5hZ2VfaXApIHsKKwkJCQkJZXJyID0gbGlieGZzX2ln ZXQobXAsIE5VTEwsIG9ycGhhbmFnZV9pbm8sIDAsICZvcnBoYW5hZ2VfaXAs IDApOworCQkJCQlpZiAoZXJyKQorCQkJCQkJZG9fZXJyb3IoXygiJWQgLSBj b3VsZG4ndCBpZ2V0IG9ycGhhbmFnZSBpbm9kZVxuIiksIGVycik7CisJCQkJ fQorCQkJCWRvX3dhcm4oXygibW92aW5nIHRvICVzXG4iKSwgT1JQSEFOQUdF KTsKKwkJCQltdl9vcnBoYW5hZ2UobXAsIGlubywgaW5vZGVfaXNhZGlyKGly ZWMsIGkpKTsKKwkJCX0gZWxzZSAgeworCQkJCWRvX3dhcm4oXygid291bGQg bW92ZSB0byAlc1xuIiksIE9SUEhBTkFHRSk7CisJCQl9CisJCQkvKgorCQkJ ICogZm9yIHJlYWQtb25seSBjYXNlLCBldmVuIHRob3VnaCB0aGUgaW5vZGUg aXNuJ3QKKwkJCSAqIHJlYWxseSByZWFjaGFibGUsIHNldCB0aGUgZmxhZyAo YW5kIGJ1bXAgb3VyIGxpbmsKKwkJCSAqIGNvdW50KSBhbnl3YXkgdG8gZm9v bCBwaGFzZSA3CisJCQkgKi8KKwkJCWFkZF9pbm9kZV9yZWFjaGVkKGlyZWMs IGkpOworCQl9CisJfQorfQorCitzdGF0aWMgdm9pZAogdHJhdmVyc2VfZnVu Y3Rpb24oeGZzX21vdW50X3QgKm1wLCB4ZnNfYWdudW1iZXJfdCBhZ25vKQog ewogCXJlZ2lzdGVyIGlub190cmVlX25vZGVfdCAqaXJlYzsKQEAgLTM4Nzcs OSArMzg1NiwxMSBAQAogCWRpcl9zdGFja190CQlzdGFjazsKIAlpbnQJCQlp OwogCWludAkJCWo7CisJeGZzX2lub190CQlvcnBoYW5hZ2VfaW5vOwogCiAJ Ynplcm8oJnplcm9jciwgc2l6ZW9mKHN0cnVjdCBjcmVkKSk7CiAJYnplcm8o Jnplcm9mc3gsIHNpemVvZihzdHJ1Y3QgZnN4YXR0cikpOworCW9ycGhhbmFn ZV9pbm8gPSAwOwogCiAJZG9fbG9nKF8oIlBoYXNlIDYgLSBjaGVjayBpbm9k ZSBjb25uZWN0aXZpdHkuLi5cbiIpKTsKIApAQCAtMzk0MywxNSArMzkyNCw2 IEBACiAJCX0KIAl9CiAKLQkvKgotCSAqIG1ha2Ugb3JwaGFuYWdlIChpdCdz IGd1YXJhbnRlZWQgdG8gbm90IGV4aXN0IG5vdykKLQkgKi8KLQlpZiAoIW5v X21vZGlmeSkgIHsKLQkJZG9fbG9nKF8oIiAgICAgICAgLSBlbnN1cmluZyBl eGlzdGVuY2Ugb2YgJXMgZGlyZWN0b3J5XG4iKSwKLQkJCU9SUEhBTkFHRSk7 Ci0JCW9ycGhhbmFnZV9pbm8gPSBta19vcnBoYW5hZ2UobXApOwotCX0KLQog CWRpcl9zdGFja19pbml0KCZzdGFjayk7CiAKIAltYXJrX3N0YW5kYWxvbmVf aW5vZGVzKG1wKTsKQEAgLTQwMzEsNTkgKzQwMDMsMTYgQEAKIAl9CiAKIAlk b19sb2coXygiICAgICAgICAtIHRyYXZlcnNhbHMgZmluaXNoZWQgLi4uIFxu IikpOwotCi0JLyogZmx1c2ggYWxsIGRpcnR5IGRhdGEgYmVmb3JlIGRvaW5n IGxvc3QrZm91bmQgc2VhcmNoICovCi0JbGlieGZzX2JjYWNoZV9mbHVzaCgp OwotCi0JZG9fbG9nKF8oIiAgICAgICAgLSBtb3ZpbmcgZGlzY29ubmVjdGVk IGlub2RlcyB0byBsb3N0K2ZvdW5kIC4uLiBcbiIpKTsKKwlkb19sb2coXygi ICAgICAgICAtIG1vdmluZyBkaXNjb25uZWN0ZWQgaW5vZGVzIHRvICVzIC4u LiBcbiIpLAorCQlPUlBIQU5BR0UpOwogCiAJLyoKIAkgKiBtb3ZlIGFsbCBk aXNjb25uZWN0ZWQgaW5vZGVzIHRvIHRoZSBvcnBoYW5hZ2UKIAkgKi8KIAlm b3IgKGkgPSAwOyBpIDwgZ2xvYl9hZ2NvdW50OyBpKyspICB7CiAJCWlyZWMg PSBmaW5kZmlyc3RfaW5vZGVfcmVjKGkpOwotCi0JCWlmIChpcmVjID09IE5V TEwpCi0JCQljb250aW51ZTsKLQogCQl3aGlsZSAoaXJlYyAhPSBOVUxMKSAg ewotCQkJZm9yIChqID0gMDsgaiA8IFhGU19JTk9ERVNfUEVSX0NIVU5LOyBq KyspICB7Ci0JCQkJQVNTRVJUKGlzX2lub2RlX2NvbmZpcm1lZChpcmVjLCBq KSk7Ci0JCQkJaWYgKGlzX2lub2RlX2ZyZWUoaXJlYywgaikpCi0JCQkJCWNv bnRpbnVlOwotCQkJCWlmICghaXNfaW5vZGVfcmVhY2hlZChpcmVjLCBqKSkg ewotCQkJCQlBU1NFUlQoaW5vZGVfaXNhZGlyKGlyZWMsIGopIHx8Ci0JCQkJ CQludW1faW5vZGVfcmVmZXJlbmNlcyhpcmVjLCBqKQotCQkJCQkJPT0gMCk7 Ci0JCQkJCWlubyA9IFhGU19BR0lOT19UT19JTk8obXAsIGksCi0JCQkJCQlq ICsgaXJlYy0+aW5vX3N0YXJ0bnVtKTsKLQkJCQkJaWYgKGlub2RlX2lzYWRp cihpcmVjLCBqKSkKLQkJCQkJCWRvX3dhcm4oCi0JCQkJCV8oImRpc2Nvbm5l Y3RlZCBkaXIgaW5vZGUgJWxsdSwgIiksCi0JCQkJCQkJaW5vKTsKLQkJCQkJ ZWxzZQotCQkJCQkJZG9fd2FybigKLQkJCQkJXygiZGlzY29ubmVjdGVkIGlu b2RlICVsbHUsICIpLAotCQkJCQkJCWlubyk7Ci0JCQkJCWlmICghbm9fbW9k aWZ5KSAgewotCQkJCQkJZG9fd2FybihfKCJtb3ZpbmcgdG8gJXNcbiIpLAot CQkJCQkJCU9SUEhBTkFHRSk7Ci0JCQkJCQltdl9vcnBoYW5hZ2UobXAsIG9y cGhhbmFnZV9pbm8sCi0JCQkJCQkJaW5vLAotCQkJCQkJCWlub2RlX2lzYWRp cihpcmVjLCBqKSk7Ci0JCQkJCX0gZWxzZSAgewotCQkJCQkJZG9fd2Fybihf KCJ3b3VsZCBtb3ZlIHRvICVzXG4iKSwKLQkJCQkJCQlPUlBIQU5BR0UpOwot CQkJCQl9Ci0JCQkJCS8qCi0JCQkJCSAqIGZvciByZWFkLW9ubHkgY2FzZSwg ZXZlbiB0aG91Z2gKLQkJCQkJICogdGhlIGlub2RlIGlzbid0IHJlYWxseSBy ZWFjaGFibGUsCi0JCQkJCSAqIHNldCB0aGUgZmxhZyAoYW5kIGJ1bXAgb3Vy IGxpbmsKLQkJCQkJICogY291bnQpIGFueXdheSB0byBmb29sIHBoYXNlIDcK LQkJCQkJICovCi0JCQkJCWFkZF9pbm9kZV9yZWFjaGVkKGlyZWMsIGopOwot CQkJCX0KLQkJCX0KKwkJCWNoZWNrX2Zvcl9vcnBoYW5lZF9pbm9kZXMobXAs IGlyZWMpOwogCQkJaXJlYyA9IG5leHRfaW5vX3JlYyhpcmVjKTsKIAkJfQog CX0KSW5kZXg6IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvcGhhc2U3LmMKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gcmVwYWlyLm9yaWcveGZzcHJvZ3Mv cmVwYWlyL3BoYXNlNy5jCTIwMDctMDQtMjcgMTM6MTM6MzUuOTcxOTkzNDg5 ICsxMDAwCisrKyByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL3BoYXNlNy5jCTIw MDctMDQtMjcgMTQ6MTE6NDEuMDAwMDAwMDAwICsxMDAwCkBAIC05NiwxMSAr OTYsOCBAQAogCiAJLyoKIAkgKiBjb21wYXJlIGFuZCBzZXQgbGlua3MgZm9y IGFsbCBpbm9kZXMKLQkgKiBidXQgdGhlIGxvc3QrZm91bmQgaW5vZGUuICB3 ZSBrZWVwCi0JICogdGhhdCBjb3JyZWN0IGFzIHdlIGdvLgogCSAqLwotCWlm IChpbm8gIT0gb3JwaGFuYWdlX2lubykKLQkJc2V0X25saW5rcygmaXAtPmlf ZCwgaW5vLCBubGlua3MsICZkaXJ0eSk7CisJc2V0X25saW5rcygmaXAtPmlf ZCwgaW5vLCBubGlua3MsICZkaXJ0eSk7CiAKIAlpZiAoIWRpcnR5KSAgewog CQlsaWJ4ZnNfdHJhbnNfaXB1dCh0cCwgaXAsIDApOwo= ------------yUh6rLTYauJAeqPswTCPZX-- From owner-xfs@oss.sgi.com Mon Jun 4 19:21:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 19:21:12 -0700 (PDT) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.227]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l552L5Wt008672 for ; Mon, 4 Jun 2007 19:21:06 -0700 Received: by nz-out-0506.google.com with SMTP id 4so1043848nzn for ; Mon, 04 Jun 2007 19:21:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TTTAQNsyhIUi2YqcdKTm/z0hya6pAGR2wiTgS8+GedaxstYt4IrRCEObu6Y6hreRIU3maYJw9E2w0aHXJh9lcUC1jnkBYVJeYNcbjwEAzJBIT2KHymP06Ax8BaYSeFx0GAaM4qkqzRiqRg2Q9bZa5/4cm2aRl0t69DyzdvGjgtw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fwepOvTwoSqSAjTdJe03EiBw89htl7fzYiiUs2L0FD22eKM0mPtsmmOfOjnbtkGnhHAze7H7d3draJXoRAuJSkmbGx4+2rwT68dxuy/4PpT07FQPwoGD4hUSI/ipY1HLM6vLQ2x/Aq3INbSM/Ieec+/Qwr/5bUzrGH7rhjYp8qI= Received: by 10.114.73.1 with SMTP id v1mr5550930waa.1181010065707; Mon, 04 Jun 2007 19:21:05 -0700 (PDT) Received: by 10.115.55.14 with HTTP; Mon, 4 Jun 2007 19:21:05 -0700 (PDT) Message-ID: Date: Mon, 4 Jun 2007 22:21:05 -0400 From: "=?ISO-8859-1?Q?Germ=E1n_Po=F3-Caama=F1o?=" To: xfs@oss.sgi.com Subject: Re: Reporting a bug In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l552L6Wt008682 X-archive-position: 11640 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: german.poo@gmail.com Precedence: bulk X-list: xfs Adding a little more information: Sysrescue has kernel 2.6.20. Filesystem "sda5": corrupt dinode 786561, (btree extents). Unmount and run xfs_repair. Filesystem "sda5": XFS internal error xfs_bmap_read_extents(1) at line 4565 of file fs/xfs/xfs_bmap.c. Caller 0xc02e7c99 [] xfs_bmap_read_extents+0x488/0x4a2 [] xfs_iread_extents+0xa0/0xbb [] xfs_iext_realloc_direct+0xb3/0xc1 [] xfs_iread_extents+0xa0/0xbb [] xfs_bmap_last_offset+0x94/0xdc [] xfs_dir2_isblock+0x1b/0x60 [] __make_request+0x384/0x495 [] xfs_dir_lookup+0x8e/0xeb [] xfs_bmapi+0x25b/0x1fd7 [] xfs_dir_lookup_int+0x2c/0xd4 [] down_write+0x8/0x10 [] xfs_ilock+0x47/0x67 [] xfs_lookup+0x50/0x76 [] __mutex_lock_slowpath+0x1ac/0x1b4 [] xfs_vn_lookup+0x3b/0x70 [] do_lookup+0xa3/0x140 [] __link_path_walk+0x61d/0xa24 [] link_path_walk+0x42/0xaf [] xfs_setattr+0xdbe/0xe7c [] do_path_lookup+0x144/0x164 [] get_empty_filp+0x4f/0xca [] __path_lookup_intent_open+0x43/0x72 [] path_lookup_open+0x20/0x25 [] open_namei+0x6e/0x523 [] do_page_fault+0x278/0x53f [] do_filp_open+0x2a/0x3e [] xfs_setattr+0xdbe/0xe7c [] do_sys_open+0x47/0xcf [] sys_open+0x1c/0x1e [] syscall_call+0x7/0xb [] svcauth_gss_accept+0x76a/0xadb ======================= Filesystem "sda5": corrupt dinode 786561, (btree extents). Unmount and run xfs_repair. Filesystem "sda5": XFS internal error xfs_bmap_read_extents(1) at line 4565 of file fs/xfs/xfs_bmap.c. Caller 0xc02e7c99 [] xfs_bmap_read_extents+0x488/0x4a2 [] xfs_iread_extents+0xa0/0xbb [] xfs_iext_realloc_direct+0xb3/0xc1 [] xfs_iread_extents+0xa0/0xbb [] __make_request+0x384/0x495 [] xfs_bmap_last_offset+0x94/0xdc [] xfs_dir2_isblock+0x1b/0x60 [] xfs_dir_lookup+0x8e/0xeb [] xfs_dir_lookup+0x7d/0xeb [] xfs_dir_lookup_int+0x2c/0xd4 [] down_write+0x8/0x10 [] xfs_ilock+0x47/0x67 [] xfs_lookup+0x50/0x76 [] __mutex_lock_slowpath+0x1ac/0x1b4 [] xfs_dir_lookup_int+0x2c/0xd4 [] xfs_vn_lookup+0x3b/0x70 [] do_lookup+0xa3/0x140 [] __link_path_walk+0x61d/0xa24 [] link_path_walk+0x42/0xaf [] do_path_lookup+0x144/0x164 [] __user_walk_fd+0x30/0x45 [] vfs_stat_fd+0x19/0x40 [] sys_stat64+0xf/0x23 [] syscall_call+0x7/0xb and so on. -- Germán Poó Caamaño http://www.gnome.org/~gpoo/ From owner-xfs@oss.sgi.com Mon Jun 4 19:20:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 19:20:15 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l552K2Wt008374 for ; Mon, 4 Jun 2007 19:20:04 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06631; Tue, 5 Jun 2007 12:20:00 +1000 Date: Tue, 05 Jun 2007 12:23:32 +1000 To: "xfs@oss.sgi.com" , xfs-dev Subject: [REVIEW 3/3] - xfs_repair speedups (enhanced prefetch) From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------IrJlgiTfBCmIeXv1iG6QRc MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-archive-position: 11639 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs ------------IrJlgiTfBCmIeXv1iG6QRc Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Back in Jan 2007, Michael Nishimoto from Agami posted a patch to a 2.7.x based xfs_repair tree to perform prefetch/reahead which primed the linux block buffer for the main xfs_repair processing threads (http://oss.sgi.com/archives/xfs/2007-01/msg00135.html). Benchmarking this and 2.8.1x xfs_repair at the time revealed very interesting numbers. 2.8.x was very slow using direct I/O and the libxfs cache. Researching this technique and intergrating it with the libxfs cache proved rather challenging. Many changes were required : - proper xfs_buf_t locking for multi-threaded access. - unify I/O sizes for inodes and metadata blocks. - try to serialise as much I/O as possible. - handle queuing, I/O and processing in parallel minimising starvation, especially when only a subset of the metadata can be stored in memory. - smarter work queues. The unifying of the I/O sizes was a significant change which resulted in a lot of improvements in both performance and correctness, in particulary, with inode blocks. During phase 6, inodes are accessed using xfs_iread/xfs_iget which using inode "clusters" which are either 8KB or blocksize, whichever is greater. Phases 3/4 read using inode "chunks" which can be 16KB or larger. With libxfs caching method, this meant all data had to be flushed/purged before phase 6 started, and all the inodes read again. Also, one part of the libxfs transaction code didn't release buffers properly. This behaviour has been seen in the past with the infamous "shake on cache 0x######## left # nodes!?" warning. Batch reading/serialising I/O requests in the prefetch code had major benefits when metadata is close together, especially with RAIDs. Also, the AIO/LIO stuff was yanked with threaded I/O prefetch. The queuing/IO/processing threads and synchronising them efficiently, especially in low memory conditions was the most challenging aspect. Most of the changes for this are in prefetch.c with minor changes for I/O in the phases. Phase 6 also eliminated the dir_stack code which is not required. It now processes the directory inodes as per layout the inode AVL tree (which it did anyway after doing a path traversal). The patch will have a lot of apparenty noop changes, these are automatic EOL whitespace cleanups. ------------IrJlgiTfBCmIeXv1iG6QRc Content-Disposition: attachment; filename=prefetch Content-Type: application/octet-stream; name=prefetch Content-Transfer-Encoding: Base64 SW5kZXg6IHJlcGFpci94ZnNwcm9ncy9pbmNsdWRlL2NhY2hlLmgKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvaW5jbHVkZS9jYWNo ZS5oCTIwMDctMDQtMjcgMTM6MTM6MzUuMDAwMDAwMDAwICsxMDAwCisrKyByZXBh aXIveGZzcHJvZ3MvaW5jbHVkZS9jYWNoZS5oCTIwMDctMDYtMDQgMTc6MjM6NDIu NDE0ODQ5MTQwICsxMDAwCkBAIC0xOCw2ICsxOCw4IEBACiAjaWZuZGVmIF9fQ0FD SEVfSF9fCiAjZGVmaW5lIF9fQ0FDSEVfSF9fCiAKKyNkZWZpbmUJSEFTSF9DQUNI RV9SQVRJTwk4CisKIC8qCiAgKiBTaW1wbGUsIGdlbmVyaWMgaW1wbGVtZW50YXRp b24gb2YgYSBjYWNoZSAoYXJiaXRyYXJ5IGRhdGEpLgogICogUHJvdmlkZXMgYSBo YXNoIHRhYmxlIHdpdGggYSBjYXBwZWQgbnVtYmVyIG9mIGNhY2hlIGVudHJpZXMu CkBAIC0yOCw4ICszMCw5IEBACiBzdHJ1Y3QgY2FjaGVfbm9kZTsKIAogdHlwZWRl ZiB2b2lkICpjYWNoZV9rZXlfdDsKKwogdHlwZWRlZiB2b2lkICgqY2FjaGVfd2Fs a190KShzdHJ1Y3QgY2FjaGVfbm9kZSAqKTsKLXR5cGVkZWYgc3RydWN0IGNhY2hl X25vZGUgKiAoKmNhY2hlX25vZGVfYWxsb2NfdCkodm9pZCk7Cit0eXBlZGVmIHN0 cnVjdCBjYWNoZV9ub2RlICogKCpjYWNoZV9ub2RlX2FsbG9jX3QpKGNhY2hlX2tl eV90KTsKIHR5cGVkZWYgdm9pZCAoKmNhY2hlX25vZGVfZmx1c2hfdCkoc3RydWN0 IGNhY2hlX25vZGUgKik7CiB0eXBlZGVmIHZvaWQgKCpjYWNoZV9ub2RlX3JlbHNl X3QpKHN0cnVjdCBjYWNoZV9ub2RlICopOwogdHlwZWRlZiB1bnNpZ25lZCBpbnQg KCpjYWNoZV9ub2RlX2hhc2hfdCkoY2FjaGVfa2V5X3QsIHVuc2lnbmVkIGludCk7 CkBAIC04NCw1ICs4Nyw2IEBACiB2b2lkIGNhY2hlX25vZGVfcHV0KHN0cnVjdCBj YWNoZV9ub2RlICopOwogaW50IGNhY2hlX25vZGVfcHVyZ2Uoc3RydWN0IGNhY2hl ICosIGNhY2hlX2tleV90LCBzdHJ1Y3QgY2FjaGVfbm9kZSAqKTsKIHZvaWQgY2Fj aGVfcmVwb3J0KEZJTEUgKmZwLCBjb25zdCBjaGFyICosIHN0cnVjdCBjYWNoZSAq KTsKK2ludCBjYWNoZV9vdmVyZmxvd2VkKHN0cnVjdCBjYWNoZSAqKTsKIAogI2Vu ZGlmCS8qIF9fQ0FDSEVfSF9fICovCkluZGV4OiByZXBhaXIveGZzcHJvZ3MvaW5j bHVkZS9saWJ4ZnMuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIub3Jp Zy94ZnNwcm9ncy9pbmNsdWRlL2xpYnhmcy5oCTIwMDctMDQtMjcgMTM6MTM6MzUu MDAwMDAwMDAwICsxMDAwCisrKyByZXBhaXIveGZzcHJvZ3MvaW5jbHVkZS9saWJ4 ZnMuaAkyMDA3LTA2LTA1IDEyOjExOjQyLjc1NjI3NTIwNyArMTAwMApAQCAtMTkw LDggKzE5MCw4IEBACiAjZGVmaW5lIExJQlhGU19NT1VOVF8zMkJJVElOT09QVAkw eDAwMDgKICNkZWZpbmUgTElCWEZTX01PVU5UX0NPTVBBVF9BVFRSCTB4MDAxMAog Ci0jZGVmaW5lIExJQlhGU19JSEFTSFNJWkUoc2JwKQkJKDE8PDE2KQkvKiB0d2Vh ayBiYXNlZCBvbiBpY291bnQ/ICovCi0jZGVmaW5lIExJQlhGU19CSEFTSFNJWkUo c2JwKQkJKDE8PDE2KQkvKiBkaXR0bywgb24gYmxvY2tzIHVzZWQ/ICovCisjZGVm aW5lIExJQlhGU19JSEFTSFNJWkUoc2JwKQkJKDE8PDEwKQorI2RlZmluZSBMSUJY RlNfQkhBU0hTSVpFKHNicCkgCQkoMTw8MTApCiAKIGV4dGVybiB4ZnNfbW91bnRf dAkqbGlieGZzX21vdW50ICh4ZnNfbW91bnRfdCAqLCB4ZnNfc2JfdCAqLAogCQkJ CWRldl90LCBkZXZfdCwgZGV2X3QsIGludCk7CkBAIC0yMTUsMTAgKzIxNSwxNyBA QAogCXhmc19kYWRkcl90CQliX2Jsa25vOwogCXVuc2lnbmVkCQliX2Jjb3VudDsK IAlkZXZfdAkJCWJfZGV2OworCXB0aHJlYWRfbXV0ZXhfdAkJYl9sb2NrOwogCXZv aWQJCQkqYl9mc3ByaXZhdGU7CiAJdm9pZAkJCSpiX2ZzcHJpdmF0ZTI7CiAJdm9p ZAkJCSpiX2ZzcHJpdmF0ZTM7CiAJY2hhcgkJCSpiX2FkZHI7CisjaWZkZWYgWEZT X0JVRl9UUkFDSU5HCisJc3RydWN0IGxpc3RfaGVhZAliX2xvY2tfbGlzdDsKKwlj b25zdCBjaGFyCQkqYl9mdW5jOworCWNvbnN0IGNoYXIJCSpiX2ZpbGU7CisJaW50 CQkJYl9saW5lOworI2VuZGlmCiB9IHhmc19idWZfdDsKIAogZW51bSB4ZnNfYnVm X2ZsYWdzX3QgewkvKiBiX2ZsYWdzIGJpdHMgKi8KQEAgLTI0NiwyNSArMjUzLDQ5 IEBACiAjZGVmaW5lIFhGU19CVUZfRlNQUklWQVRFMyhicCx0eXBlKQkoKHR5cGUp KGJwKS0+Yl9mc3ByaXZhdGUzKQogI2RlZmluZSBYRlNfQlVGX1NFVF9GU1BSSVZB VEUzKGJwLHZhbCkJKGJwKS0+Yl9mc3ByaXZhdGUzID0gKHZvaWQgKikodmFsKQog Ci1leHRlcm4geGZzX2J1Zl90CSpsaWJ4ZnNfZ2V0c2IgKHhmc19tb3VudF90ICos IGludCk7Ci1leHRlcm4geGZzX2J1Zl90CSpsaWJ4ZnNfcmVhZGJ1ZiAoZGV2X3Qs IHhmc19kYWRkcl90LCBpbnQsIGludCk7Ci1leHRlcm4gaW50CWxpYnhmc19yZWFk YnVmciAoZGV2X3QsIHhmc19kYWRkcl90LCB4ZnNfYnVmX3QgKiwgaW50LCBpbnQp OwotZXh0ZXJuIGludAlsaWJ4ZnNfd3JpdGVidWYgKHhmc19idWZfdCAqLCBpbnQp OwotZXh0ZXJuIGludAlsaWJ4ZnNfd3JpdGVidWZyICh4ZnNfYnVmX3QgKik7Ci1l eHRlcm4gaW50CWxpYnhmc193cml0ZWJ1Zl9pbnQgKHhmc19idWZfdCAqLCBpbnQp OwotCiAvKiBCdWZmZXIgQ2FjaGUgSW50ZXJmYWNlcyAqLworCiBleHRlcm4gc3Ry dWN0IGNhY2hlCSpsaWJ4ZnNfYmNhY2hlOwogZXh0ZXJuIHN0cnVjdCBjYWNoZV9v cGVyYXRpb25zCWxpYnhmc19iY2FjaGVfb3BlcmF0aW9uczsKLWV4dGVybiB2b2lk CWxpYnhmc19iY2FjaGVfcHVyZ2UgKHZvaWQpOwotZXh0ZXJuIHZvaWQJbGlieGZz X2JjYWNoZV9mbHVzaCAodm9pZCk7Ci1leHRlcm4geGZzX2J1Zl90CSpsaWJ4ZnNf Z2V0YnVmIChkZXZfdCwgeGZzX2RhZGRyX3QsIGludCk7CisKKyNpZmRlZiBYRlNf QlVGX1RSQUNJTkcKKworI2RlZmluZSBsaWJ4ZnNfcmVhZGJ1ZihkZXYsIGRhZGRy LCBsZW4sIGZsYWdzKSBcCisJCWxpYnhmc190cmFjZV9yZWFkYnVmKF9fRlVOQ1RJ T05fXywgX19GSUxFX18sIF9fTElORV9fLCAoZGV2KSwgKGRhZGRyKSwgKGxlbiks IChmbGFncykpCisjZGVmaW5lIGxpYnhmc193cml0ZWJ1ZihidWYsIGZsYWdzKSBc CisJCWxpYnhmc190cmFjZV93cml0ZWJ1ZihfX0ZVTkNUSU9OX18sIF9fRklMRV9f LCBfX0xJTkVfXywgKGJ1ZiksIChmbGFncykpCisjZGVmaW5lIGxpYnhmc19nZXRi dWYoZGV2LCBkYWRkciwgbGVuKSBcCisJCWxpYnhmc190cmFjZV9nZXRidWYoX19G VU5DVElPTl9fLCBfX0ZJTEVfXywgX19MSU5FX18sIChkZXYpLCAoZGFkZHIpLCAo bGVuKSkKKyNkZWZpbmUgbGlieGZzX3B1dGJ1ZihidWYpIFwKKwkJbGlieGZzX3Ry YWNlX3B1dGJ1ZihfX0ZVTkNUSU9OX18sIF9fRklMRV9fLCBfX0xJTkVfXywgKGJ1 ZikpCisKK2V4dGVybiB4ZnNfYnVmX3QgKmxpYnhmc190cmFjZV9yZWFkYnVmKGNv bnN0IGNoYXIgKiwgY29uc3QgY2hhciAqLCBpbnQsIGRldl90LCB4ZnNfZGFkZHJf dCwgaW50LCBpbnQpOworZXh0ZXJuIGludAlsaWJ4ZnNfdHJhY2Vfd3JpdGVidWYo Y29uc3QgY2hhciAqLCBjb25zdCBjaGFyICosIGludCwgeGZzX2J1Zl90ICosIGlu dCk7CitleHRlcm4geGZzX2J1Zl90ICpsaWJ4ZnNfdHJhY2VfZ2V0YnVmKGNvbnN0 IGNoYXIgKiwgY29uc3QgY2hhciAqLCBpbnQsIGRldl90LCB4ZnNfZGFkZHJfdCwg aW50KTsKK2V4dGVybiB2b2lkCWxpYnhmc190cmFjZV9wdXRidWYgKGNvbnN0IGNo YXIgKiwgY29uc3QgY2hhciAqLCBpbnQsIHhmc19idWZfdCAqKTsKKworI2Vsc2UK KworZXh0ZXJuIHhmc19idWZfdCAqbGlieGZzX3JlYWRidWYoZGV2X3QsIHhmc19k YWRkcl90LCBpbnQsIGludCk7CitleHRlcm4gaW50CWxpYnhmc193cml0ZWJ1Zih4 ZnNfYnVmX3QgKiwgaW50KTsKK2V4dGVybiB4ZnNfYnVmX3QgKmxpYnhmc19nZXRi dWYoZGV2X3QsIHhmc19kYWRkcl90LCBpbnQpOwogZXh0ZXJuIHZvaWQJbGlieGZz X3B1dGJ1ZiAoeGZzX2J1Zl90ICopOwotZXh0ZXJuIHZvaWQJbGlieGZzX3B1cmdl YnVmICh4ZnNfYnVmX3QgKik7CisKKyNlbmRpZgorCitleHRlcm4geGZzX2J1Zl90 ICpsaWJ4ZnNfZ2V0c2IoeGZzX21vdW50X3QgKiwgaW50KTsKK2V4dGVybiB2b2lk CWxpYnhmc19iY2FjaGVfcHVyZ2Uodm9pZCk7CitleHRlcm4gdm9pZAlsaWJ4ZnNf YmNhY2hlX2ZsdXNoKHZvaWQpOworZXh0ZXJuIHZvaWQJbGlieGZzX3B1cmdlYnVm KHhmc19idWZfdCAqKTsKK2V4dGVybiBpbnQJbGlieGZzX2JjYWNoZV9vdmVyZmxv d2VkKHZvaWQpOworZXh0ZXJuIGludAlsaWJ4ZnNfYmNhY2hlX3VzYWdlKHZvaWQp OwogCiAvKiBCdWZmZXIgKFJhdykgSW50ZXJmYWNlcyAqLwotZXh0ZXJuIHhmc19i dWZfdAkqbGlieGZzX2dldGJ1ZnIgKGRldl90LCB4ZnNfZGFkZHJfdCwgaW50KTsK LWV4dGVybiB2b2lkCWxpYnhmc19wdXRidWZyICh4ZnNfYnVmX3QgKik7CitleHRl cm4geGZzX2J1Zl90ICpsaWJ4ZnNfZ2V0YnVmcihkZXZfdCwgeGZzX2RhZGRyX3Qs IGludCk7CitleHRlcm4gdm9pZAlsaWJ4ZnNfcHV0YnVmcih4ZnNfYnVmX3QgKik7 CisKK2V4dGVybiBpbnQJbGlieGZzX3dyaXRlYnVmX2ludCh4ZnNfYnVmX3QgKiwg aW50KTsKK2V4dGVybiBpbnQJbGlieGZzX3JlYWRidWZyKGRldl90LCB4ZnNfZGFk ZHJfdCwgeGZzX2J1Zl90ICosIGludCwgaW50KTsKIAogZXh0ZXJuIGludCBsaWJ4 ZnNfYmhhc2hfc2l6ZTsKIGV4dGVybiBpbnQgbGlieGZzX2loYXNoX3NpemU7CkBA IC00NzMsNyArNTA0LDcgQEAKIGV4dGVybiB2b2lkCWxpYnhmc19ibWFwX2NhbmNl bCh4ZnNfYm1hcF9mcmVlX3QgKik7CiBleHRlcm4gaW50CWxpYnhmc19ibWFwX25l eHRfb2Zmc2V0ICh4ZnNfdHJhbnNfdCAqLCB4ZnNfaW5vZGVfdCAqLAogCQkJCXhm c19maWxlb2ZmX3QgKiwgaW50KTsKLWV4dGVybiBpbnQJbGlieGZzX2JtYXBfbGFz dF9vZmZzZXQoeGZzX3RyYW5zX3QgKiwgeGZzX2lub2RlX3QgKiwgCitleHRlcm4g aW50CWxpYnhmc19ibWFwX2xhc3Rfb2Zmc2V0KHhmc190cmFuc190ICosIHhmc19p bm9kZV90ICosCiAJCQkJeGZzX2ZpbGVvZmZfdCAqLCBpbnQpOwogZXh0ZXJuIGlu dAlsaWJ4ZnNfYnVubWFwaSAoeGZzX3RyYW5zX3QgKiwgeGZzX2lub2RlX3QgKiwg eGZzX2ZpbGVvZmZfdCwKIAkJCQl4ZnNfZmlsYmxrc190LCBpbnQsIHhmc19leHRu dW1fdCwKQEAgLTU1NSwyOSArNTg2LDEwIEBACiBleHRlcm4gdm9pZCBjbW5fZXJy KGludCwgY2hhciAqLCAuLi4pOwogZW51bSBjZSB7IENFX0RFQlVHLCBDRV9DT05U LCBDRV9OT1RFLCBDRV9XQVJOLCBDRV9BTEVSVCwgQ0VfUEFOSUMgfTsKIAotLyog bGlvIGludGVyZmFjZSAqLwotLyogbGlvX2xpc3RpbygzKSBpbnRlcmZhY2UgKFBP U0lYIGxpbmtlZCBhc3luY2hyb25vdXMgSS9PKSAqLwotZXh0ZXJuIGludCBsaWJ4 ZnNfbGlvX2lub19jb3VudDsKLWV4dGVybiBpbnQgbGlieGZzX2xpb19kaXJfY291 bnQ7Ci1leHRlcm4gaW50IGxpYnhmc19saW9fYWlvX2NvdW50OwotCi1leHRlcm4g aW50IGxpYnhmc19saW9faW5pdCh2b2lkKTsKLWV4dGVybiB2b2lkIGxpYnhmc19s aW9fYWxsb2NhdGUodm9pZCk7Ci1leHRlcm4gdm9pZCAqbGlieGZzX2dldF9saW9f YnVmZmVyKGludCB0eXBlKTsKLWV4dGVybiB2b2lkIGxpYnhmc19wdXRfbGlvX2J1 ZmZlcih2b2lkICpidWZmZXIpOwotZXh0ZXJuIGludCBsaWJ4ZnNfcmVhZGJ1Zl9s aXN0KGRldl90IGRldiwgaW50IG5lbnQsIHZvaWQgKnZvaWRwLCBpbnQgdHlwZSk7 Ci0KLXR5cGVkZWYgc3RydWN0ICBsaWJ4ZnNfbGlvX3JlcSB7Ci0JeGZzX2RhZGRy X3QJYmxrbm87Ci0JaW50CQlsZW47CS8qIGJicyAqLwotfSBsaWJ4ZnNfbGlvX3Jl cV90OwotCi0jZGVmaW5lCUxJQlhGU19MSU9fVFlQRV9JTk8JCTB4MQotI2RlZmlu ZQlMSUJYRlNfTElPX1RZUEVfRElSCQkweDIKLSNkZWZpbmUJTElCWEZTX0xJT19U WVBFX1JBVwkJMHgzCiAKICNkZWZpbmUgTElCWEZTX0JCVE9PRkY2NChiYnMpCSgo KHhmc19vZmZfdCkoYmJzKSkgPDwgQkJTSElGVCkKLWV4dGVybiBpbnQgbGlieGZz X25wcm9jKHZvaWQpOworZXh0ZXJuIGludAkJbGlieGZzX25wcm9jKHZvaWQpOwor ZXh0ZXJuIHVuc2lnbmVkIGxvbmcJbGlieGZzX3BoeXNtZW0odm9pZCk7CS8qIGlu IGtpbG9ieXRlcyAqLwogCiAjaW5jbHVkZSA8eGZzL3hmc19pYWxsb2MuaD4KICNp bmNsdWRlIDx4ZnMveGZzX3J0YWxsb2MuaD4KSW5kZXg6IHJlcGFpci94ZnNwcm9n cy9saWJ4ZnMvY2FjaGUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIu b3JpZy94ZnNwcm9ncy9saWJ4ZnMvY2FjaGUuYwkyMDA3LTA0LTI3IDEzOjEzOjM1 LjAwMDAwMDAwMCArMTAwMAorKysgcmVwYWlyL3hmc3Byb2dzL2xpYnhmcy9jYWNo ZS5jCTIwMDctMDYtMDQgMTc6MjM6NDIuNDIyODQ4MTE0ICsxMDAwCkBAIC0zMSw3 ICszMSw2IEBACiAjZGVmaW5lIENBQ0hFX0RFQlVHIDEKICN1bmRlZiBDQUNIRV9B Qk9SVAogLyogI2RlZmluZSBDQUNIRV9BQk9SVCAxICovCi0jZGVmaW5lCUhBU0hf Q0FDSEVfUkFUSU8JOAogCiBzdGF0aWMgdW5zaWduZWQgaW50IGNhY2hlX2dlbmVy aWNfYnVsa3JlbHNlKHN0cnVjdCBjYWNoZSAqLCBzdHJ1Y3QgbGlzdF9oZWFkICop OwogCkBAIC0yNzUsNyArMjc0LDggQEAKIHN0cnVjdCBjYWNoZV9ub2RlICoKIGNh Y2hlX25vZGVfYWxsb2NhdGUoCiAJc3RydWN0IGNhY2hlICoJCWNhY2hlLAotCXN0 cnVjdCBjYWNoZV9oYXNoICoJaGFzaGxpc3QpCisJc3RydWN0IGNhY2hlX2hhc2gg KgloYXNobGlzdCwKKwljYWNoZV9rZXlfdAkJa2V5KQogewogCXVuc2lnbmVkIGlu dAkJbm9kZXNmcmVlOwogCXN0cnVjdCBjYWNoZV9ub2RlICoJbm9kZTsKQEAgLTI5 MCw3ICsyOTAsNyBAQAogCXB0aHJlYWRfbXV0ZXhfdW5sb2NrKCZjYWNoZS0+Y19t dXRleCk7CiAJaWYgKCFub2Rlc2ZyZWUpCiAJCXJldHVybiBOVUxMOwotCWlmICgh KG5vZGUgPSBjYWNoZS0+YWxsb2MoKSkpIHsJLyogdWgtb2ggKi8KKwlpZiAoIShu b2RlID0gY2FjaGUtPmFsbG9jKGtleSkpKSB7CS8qIHVoLW9oICovCiAJCXB0aHJl YWRfbXV0ZXhfbG9jaygmY2FjaGUtPmNfbXV0ZXgpOwogCQljYWNoZS0+Y19jb3Vu dC0tOwogCQlwdGhyZWFkX211dGV4X3VubG9jaygmY2FjaGUtPmNfbXV0ZXgpOwpA QCAtMzAyLDYgKzMwMiwxMyBAQAogCXJldHVybiBub2RlOwogfQogCitpbnQKK2Nh Y2hlX292ZXJmbG93ZWQoCisJc3RydWN0IGNhY2hlICoJCWNhY2hlKQoreworCXJl dHVybiAoY2FjaGUtPmNfbWF4Y291bnQgPT0gY2FjaGUtPmNfbWF4KTsKK30KKwog LyoKICAqIExvb2t1cCBpbiB0aGUgY2FjaGUgaGFzaCB0YWJsZS4gIFdpdGggYW55 IGx1Y2sgd2UnbGwgZ2V0IGEgY2FjaGUKICAqIGhpdCwgaW4gd2hpY2ggY2FzZSB0 aGlzIHdpbGwgYWxsIGJlIG92ZXIgcXVpY2tseSBhbmQgcGFpbmxlc3NseS4KQEAg LTM0MSw3ICszNDgsNyBAQAogCQlicmVhazsKIAl9CiAJaWYgKHBvcyA9PSBoZWFk KSB7Ci0JCW5vZGUgPSBjYWNoZV9ub2RlX2FsbG9jYXRlKGNhY2hlLCBoYXNoKTsK KwkJbm9kZSA9IGNhY2hlX25vZGVfYWxsb2NhdGUoY2FjaGUsIGhhc2gsIGtleSk7 CiAJCWlmICghbm9kZSkgewogCQkJcHJpb3JpdHkgPSBjYWNoZV9zaGFrZShjYWNo ZSwgaGFzaCwgcHJpb3JpdHkpOwogCQkJZ290byByZXN0YXJ0OwpAQCAtNDI4LDcg KzQzNSw3IEBACiB9CiAKIC8qCi0gKiBGbHVzaCBhbGwgbm9kZXMgaW4gdGhlIGNh Y2hlIHRvIGRpc2suIAorICogRmx1c2ggYWxsIG5vZGVzIGluIHRoZSBjYWNoZSB0 byBkaXNrLgogICovCiB2b2lkCiBjYWNoZV9mbHVzaCgKQEAgLTQzOSwxMyArNDQ2 LDEzIEBACiAJc3RydWN0IGxpc3RfaGVhZCAqCXBvczsKIAlzdHJ1Y3QgY2FjaGVf bm9kZSAqCW5vZGU7CiAJaW50CQkJaTsKLQkKKwogCWlmICghY2FjaGUtPmZsdXNo KQogCQlyZXR1cm47Ci0JCisKIAlmb3IgKGkgPSAwOyBpIDwgY2FjaGUtPmNfaGFz aHNpemU7IGkrKykgewogCQloYXNoID0gJmNhY2hlLT5jX2hhc2hbaV07Ci0JCQor CiAJCXB0aHJlYWRfbXV0ZXhfbG9jaygmaGFzaC0+Y2hfbXV0ZXgpOwogCQloZWFk ID0gJmhhc2gtPmNoX2xpc3Q7CiAJCWZvciAocG9zID0gaGVhZC0+bmV4dDsgcG9z ICE9IGhlYWQ7IHBvcyA9IHBvcy0+bmV4dCkgewpAQCAtNTA1LDEwICs1MTIsMTAg QEAKIAkJdG90YWwgKz0gaSpoYXNoX2J1Y2tldF9sZW5ndGhzW2ldOwogCQlpZiAo aGFzaF9idWNrZXRfbGVuZ3Roc1tpXSA9PSAwKQogCQkJY29udGludWU7Ci0JCWZw cmludGYoZnAsICJIYXNoIGJ1Y2tldHMgd2l0aCAgJTJkIGVudHJpZXMgJTVsZCAo JTNsZCUlKVxuIiwgCisJCWZwcmludGYoZnAsICJIYXNoIGJ1Y2tldHMgd2l0aCAg JTJkIGVudHJpZXMgJTVsZCAoJTNsZCUlKVxuIiwKIAkJCWksIGhhc2hfYnVja2V0 X2xlbmd0aHNbaV0sIChpKmhhc2hfYnVja2V0X2xlbmd0aHNbaV0qMTAwKS9jYWNo ZS0+Y19jb3VudCk7CiAJfQogCWlmIChoYXNoX2J1Y2tldF9sZW5ndGhzW2ldKQkv KiBsYXN0IHJlcG9ydCBidWNrZXQgaXMgdGhlIG92ZXJmbG93IGJ1Y2tldCAqLwot CQlmcHJpbnRmKGZwLCAiSGFzaCBidWNrZXRzIHdpdGggPiUyZCBlbnRyaWVzICU1 bGQgKCUzbGQlJSlcbiIsIAorCQlmcHJpbnRmKGZwLCAiSGFzaCBidWNrZXRzIHdp dGggPiUyZCBlbnRyaWVzICU1bGQgKCUzbGQlJSlcbiIsCiAJCQlpLTEsIGhhc2hf YnVja2V0X2xlbmd0aHNbaV0sICgoY2FjaGUtPmNfY291bnQtdG90YWwpKjEwMCkv Y2FjaGUtPmNfY291bnQpOwogfQpJbmRleDogcmVwYWlyL3hmc3Byb2dzL2xpYnhm cy9saW8uYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIub3JpZy94ZnNw cm9ncy9saWJ4ZnMvbGlvLmMJMjAwNy0wNC0yNyAxMzoxMzozNS4wMDAwMDAwMDAg KzEwMDAKKysrIC9kZXYvbnVsbAkxOTcwLTAxLTAxIDAwOjAwOjAwLjAwMDAwMDAw MCArMDAwMApAQCAtMSwxOTIgKzAsMCBAQAotI2luY2x1ZGUgPHhmcy9saWJ4ZnMu aD4KLSNpbmNsdWRlICJpbml0LmgiCi0jaW5jbHVkZSAiYWlvLmgiCi0KLSNkZWZp bmUJREVGX1BSRUZFVENIX0lOT1MJMTYKLSNkZWZpbmUJREVGX1BSRUZFVENIX0RJ UlMJMTYKLSNkZWZpbmUJREVGX1BSRUZFVENIX0FJTwkzMgotaW50CWxpYnhmc19s aW9faW5vX2NvdW50ID0gREVGX1BSRUZFVENIX0lOT1M7Ci1pbnQJbGlieGZzX2xp b19kaXJfY291bnQgPSBERUZfUFJFRkVUQ0hfRElSUzsKLWludAlsaWJ4ZnNfbGlv X2Fpb19jb3VudCA9IERFRl9QUkVGRVRDSF9BSU87Ci0KLXN0YXRpYyBwdGhyZWFk X2tleV90IGxpb19pbm9fa2V5Owotc3RhdGljIHB0aHJlYWRfa2V5X3QgbGlvX2Rp cl9rZXk7Ci0KLXZvaWQKLWxpYnhmc19saW9fYWxsb2NhdGUodm9pZCkKLXsKLSNp ZmRlZglfQUlPQ0I2NF9UX0RFRklORUQKLQlzaXplX3QJCXNpemU7Ci0Jdm9pZAkJ KnZvaWRwOwotCi0JLyoKLQkgKiBhbGxvY2F0ZSBhIHBlci10aHJlYWQgYnVmZmVy IHdoaWNoIHdpbGwgYmUgdXNlZCBpbiBsaWJ4ZnNfcmVhZGJ1Zl9saXN0Ci0JICog aW4gdGhlIGZvbGxvd2luZyBvcmRlcjoKLQkgKiBsaWJ4ZnNfbGlvX3JlcV90IGFy cmF5Ci0JICogYWlvY2I2NF90IGFycmF5Ci0JICogYWlvY2I2NF90ICogYXJyYXkK LQkgKiB4ZnNfYnVmX3QgKiBhcnJheQotCSAqLwotCXNpemUgPSBzaXplb2YobGli eGZzX2xpb19yZXFfdCkgKyBzaXplb2YoYWlvY2I2NF90KSArICBzaXplb2YoYWlv Y2I2NF90ICopICsgc2l6ZW9mKHhmc19idWZfdCAqKTsKLQotCXZvaWRwID0gbWFs bG9jKGxpYnhmc19saW9faW5vX2NvdW50KnNpemUpOwotCWlmICh2b2lkcCA9PSBO VUxMKSB7Ci0JCWZwcmludGYoc3RkZXJyLCAibGlvX2FsbG9jYXRlOiBjYW5ub3Qg YWxsb2NhdGUgdGhyZWFkIHNwZWNpZmljIHN0b3JhZ2VcbiIpOwotCQlleGl0KDEp OwotCQkvKiBOTyBSRVRVUk4gKi8KLQkJcmV0dXJuOwotCX0KLQlwdGhyZWFkX3Nl dHNwZWNpZmljKGxpb19pbm9fa2V5LCAgdm9pZHApOwotCi0Jdm9pZHAgPSBtYWxs b2MobGlieGZzX2xpb19kaXJfY291bnQqc2l6ZSk7Ci0JaWYgKHZvaWRwID09IE5V TEwpIHsKLQkJZnByaW50ZihzdGRlcnIsICJsaW9fYWxsb2NhdGU6IGNhbm5vdCBh bGxvY2F0ZSB0aHJlYWQgc3BlY2lmaWMgc3RvcmFnZVxuIik7Ci0JCWV4aXQoMSk7 Ci0JCS8qIE5PIFJFVFVSTiAqLwotCQlyZXR1cm47Ci0JfQotCXB0aHJlYWRfc2V0 c3BlY2lmaWMobGlvX2Rpcl9rZXksICB2b2lkcCk7Ci0jZW5kaWYJLyogX0FJT0NC NjRfVF9ERUZJTkVEICovCi19Ci0KLWludAotbGlieGZzX2xpb19pbml0KHZvaWQp Ci17Ci0jaWZkZWYJX0FJT0NCNjRfVF9ERUZJTkVECi0JaWYgKHBsYXRmb3JtX2Fp b19pbml0KGxpYnhmc19saW9fYWlvX2NvdW50KSkgewotCQlwdGhyZWFkX2tleV9j cmVhdGUoJmxpb19pbm9fa2V5LCBOVUxMKTsKLQkJcHRocmVhZF9rZXlfY3JlYXRl KCZsaW9fZGlyX2tleSwgTlVMTCk7Ci0JCXJldHVybiAoMSk7Ci0JfQotI2VuZGlm CS8qIF9BSU9DQjY0X1RfREVGSU5FRCAqLwotCXJldHVybiAoMCk7Ci19Ci0KLXZv aWQgKgotbGlieGZzX2dldF9saW9fYnVmZmVyKGludCB0eXBlKQotewotI2lmZGVm CV9BSU9DQjY0X1RfREVGSU5FRAotCWlmICh0eXBlID09IExJQlhGU19MSU9fVFlQ RV9JTk8pCi0JCXJldHVybiBwdGhyZWFkX2dldHNwZWNpZmljKGxpb19pbm9fa2V5 KTsKLQlpZiAodHlwZSA9PSBMSUJYRlNfTElPX1RZUEVfRElSKQotCQlyZXR1cm4g cHRocmVhZF9nZXRzcGVjaWZpYyhsaW9fZGlyX2tleSk7Ci0JaWYgKHR5cGUgPT0g TElCWEZTX0xJT19UWVBFX1JBVykgewotCQkvKiB1c2UgdGhlIGlub2RlIGJ1ZmZl cnMgc2luY2UgdGhlcmUgaXMKLQkJICogbm8gb3ZlcmxhcCB3aXRoIHRoZSBvdGhl ciByZXF1ZXN0cy4KLQkJICovCi0JCXJldHVybiBwdGhyZWFkX2dldHNwZWNpZmlj KGxpb19pbm9fa2V5KTsKLQl9Ci0JZnByaW50ZihzdGRlcnIsICJnZXRfbGlvX2J1 ZmZlcjogaW52YWxpZCB0eXBlIDB4JXhcbiIsIHR5cGUpOwotCWV4aXQoMSk7Ci0j ZW5kaWYKLQlyZXR1cm4gTlVMTDsKLX0KLQotLyogQVJHU1VTRUQgKi8KLXZvaWQK LWxpYnhmc19wdXRfbGlvX2J1ZmZlcih2b2lkICpidWZmZXIpCi17Ci0JcmV0dXJu OwkvKiBub3RoaW5nIHRvIGRvICovCi19Ci0KLXN0YXRpYyBpbnQKLWxpb19jb21w YXJlKGNvbnN0IHZvaWQgKmUxLCBjb25zdCB2b2lkICplMikKLXsKLQlsaWJ4ZnNf bGlvX3JlcV90ICpyMSA9IChsaWJ4ZnNfbGlvX3JlcV90ICopIGUxOwotCWxpYnhm c19saW9fcmVxX3QgKnIyID0gKGxpYnhmc19saW9fcmVxX3QgKikgZTI7Ci0KLQly ZXR1cm4gKGludCkgKHIxLT5ibGtubyAtIHIyLT5ibGtubyk7Ci19Ci0KLWludAot bGlieGZzX3JlYWRidWZfbGlzdChkZXZfdCBkZXYsIGludCBuZW50LCB2b2lkICp2 b2lkcCwgaW50IHR5cGUpCi17Ci0jaWZkZWYJX0FJT0NCNjRfVF9ERUZJTkVECi0J bGlieGZzX2xpb19yZXFfdAkqcmJscDsKLQl4ZnNfYnVmX3QJCSpicCwgKipicGxp c3Q7Ci0JYWlvY2I2NF90CQkqYWlvY2xpc3QsICoqYWlvY3B0cjsKLQlpbnQJCQlp LCBuYnAsIGVycjsKLQlpbnQJCQlmZDsKLQotCWlmIChuZW50IDw9IDApCi0JCXJl dHVybiAwOwotCWlmICgodHlwZSA9PSBMSUJYRlNfTElPX1RZUEVfSU5PKSB8fCAo dHlwZSA9PSBMSUJYRlNfTElPX1RZUEVfUkFXKSkgewotCQlpZiAobGlieGZzX2xp b19pbm9fY291bnQgPT0gMCkKLQkJCXJldHVybiAoMCk7Ci0JCWlmIChuZW50ID4g bGlieGZzX2xpb19pbm9fY291bnQpCi0JCQluZW50ID0gbGlieGZzX2xpb19pbm9f Y291bnQ7Ci0JfQotCWVsc2UgaWYgKHR5cGUgPT0gTElCWEZTX0xJT19UWVBFX0RJ UikgewotCQlpZiAobGlieGZzX2xpb19kaXJfY291bnQgPT0gMCkKLQkJCXJldHVy biAoMCk7Ci0JCWlmIChuZW50ID4gbGlieGZzX2xpb19kaXJfY291bnQpCi0JCQlu ZW50ID0gbGlieGZzX2xpb19kaXJfY291bnQ7Ci0JCWlmIChuZW50ID4gMikKLQkJ CXFzb3J0KHZvaWRwLCBuZW50LCBzaXplb2YobGlieGZzX2xpb19yZXFfdCksIGxp b19jb21wYXJlKTsKLQl9Ci0JZWxzZSB7Ci0JCWZwcmludGYoc3RkZXJyLCAiSW52 YWxpZCB0eXBlIDB4JXggaW4gbGlieGZzX3JlYWRidWZfbGlzdFxuIiwgdHlwZSk7 Ci0JCWFib3J0KCk7Ci0JCS8qIE5PIFJFVFVSTiAqLwotCQlyZXR1cm4gKDApOwot CX0KLQotCS8qIHNwYWNlIGZvciBsaW9fbGlzdGlvIHByb2Nlc3NpbmcsIHNlZSBs aWJ4ZnNfbGlvX2FsbG9jYXRlICovCi0JcmJscCA9IChsaWJ4ZnNfbGlvX3JlcV90 ICopIHZvaWRwOwotCWFpb2NsaXN0ID0gKGFpb2NiNjRfdCAqKSAocmJscCArIG5l bnQpOwotCWFpb2NwdHIgPSAoYWlvY2I2NF90ICoqKSAoYWlvY2xpc3QgKyBuZW50 KTsKLQlicGxpc3QgPSAoeGZzX2J1Zl90ICoqKSAoYWlvY3B0ciArIG5lbnQpOwot Ci0JYnplcm8oYWlvY2xpc3QsIG5lbnQqc2l6ZW9mKGFpb2NiNjRfdCkpOwotCi0J LyogbG9vayBpbiBidWZmZXIgY2FjaGUgKi8KLQlmb3IgKGkgPSAwLCBuYnAgPSAw OyBpIDwgbmVudDsgaSsrKSB7Ci0JCUFTU0VSVChyYmxwW2ldLmxlbik7Ci0JCWJw ID0gbGlieGZzX2dldGJ1ZihkZXYsIHJibHBbaV0uYmxrbm8sIHJibHBbaV0ubGVu KTsKLQkJaWYgKGJwID09IE5VTEwpCi0JCQljb250aW51ZTsKLQkJaWYgKGJwLT5i X2ZsYWdzICYgKExJQlhGU19CX1VQVE9EQVRFfExJQlhGU19CX0RJUlRZKSkgewot CQkJLyogYWxyZWFkeSBpbiBjYWNoZSAqLwotCQkJbGlieGZzX3B1dGJ1ZihicCk7 Ci0JCQljb250aW51ZTsKLQkJfQotCQlicGxpc3RbbmJwKytdID0gYnA7Ci0JfQot Ci0JaWYgKG5icCA9PSAwKQotCQlyZXR1cm4gKDApOyAvKiBOb3RoaW5nIHRvIGRv ICovCi0KLQlpZiAobmJwID09IDEpIHsKLQkJbGlieGZzX3B1dGJ1ZihicGxpc3Rb MF0pOwkvKiBzaW5nbGUgYnVmZmVyLCBubyBwb2ludCAqLwotCQlyZXR1cm4gKDAp OwotCX0KLQotCWZkID0gbGlieGZzX2RldmljZV90b19mZChkZXYpOwotCi0JZm9y IChpID0gMDsgaSA8IG5icDsgaSsrKSB7Ci0JCWFpb2NsaXN0W2ldLmFpb19maWxk ZXMgPSBmZDsKLQkJYWlvY2xpc3RbaV0uYWlvX25ieXRlcyA9IFhGU19CVUZfQ09V TlQoYnBsaXN0W2ldKTsKLQkJYWlvY2xpc3RbaV0uYWlvX2J1ZiA9IFhGU19CVUZf UFRSKGJwbGlzdFtpXSk7Ci0JCWFpb2NsaXN0W2ldLmFpb19vZmZzZXQgPSBMSUJY RlNfQkJUT09GRjY0KFhGU19CVUZfQUREUihicGxpc3RbaV0pKTsKLQkJYWlvY2xp c3RbaV0uYWlvX2xpb19vcGNvZGUgPSBMSU9fUkVBRDsKLQkJYWlvY3B0cltpXSA9 ICZhaW9jbGlzdFtpXTsKLQl9Ci0KLQllcnIgPSBsaW9fbGlzdGlvNjQoTElPX1dB SVQsIGFpb2NwdHIsIG5icCwgTlVMTCk7Ci0KLQlpZiAoZXJyICE9IDApIHsKLQkJ ZnByaW50ZihzdGRlcnIsICJsaW9fbGlzdGlvICglZCBlbnRyaWVzKSBmYWlsdXJl IGVyciA9ICVkXG4iLCBuYnAsIGVycik7Ci0JfQotCi0JZm9yIChpID0gMDsgaSA8 IG5icDsgaSsrKSB7Ci0JCS8qIGJ1ZmZlciB3aXRoIGRhdGEgaW4gY2FjaGUgYXZh aWxhYmxlIHZpYSBmdXR1cmUgbGlieGZzX3JlYWRidWYgKi8KLQkJaWYgKGVyciA9 PSAwKQotCQkJYnBsaXN0W2ldLT5iX2ZsYWdzIHw9IExJQlhGU19CX1VQVE9EQVRF OwotCQlsaWJ4ZnNfcHV0YnVmKGJwbGlzdFtpXSk7Ci0JfQotCi0JcmV0dXJuIChl cnIgPT0gMD8gbmJwIDogLTEpOwotI2Vsc2UJLyogX0FJT0NCNjRfVF9ERUZJTkVE ICovCi0JcmV0dXJuIC0xOwotI2VuZGlmCS8qIF9BSU9DQjY0X1RfREVGSU5FRCAq LwotfQpJbmRleDogcmVwYWlyL3hmc3Byb2dzL2xpYnhmcy9yZHdyLmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvbGlieGZzL3Jk d3IuYwkyMDA3LTA0LTI3IDEzOjEzOjM1LjAwMDAwMDAwMCArMTAwMAorKysgcmVw YWlyL3hmc3Byb2dzL2xpYnhmcy9yZHdyLmMJMjAwNy0wNi0wNCAxNDowNDozNC42 MTk1NjIxNjkgKzEwMDAKQEAgLTI0LDYgKzI0LDggQEAKICNkZWZpbmUgQkRTVFJB VF9TSVpFCSgyNTYgKiAxMDI0KQogI2RlZmluZSBtaW4oeCwgeSkJKCh4KSA8ICh5 KSA/ICh4KSA6ICh5KSkKIAorI2RlZmluZSBJT19CQ09NUEFSRV9DSEVDSworCiB2 b2lkCiBsaWJ4ZnNfZGV2aWNlX3plcm8oZGV2X3QgZGV2LCB4ZnNfZGFkZHJfdCBz dGFydCwgdWludCBsZW4pCiB7CkBAIC0xODMsNiArMTg1LDcxIEBACiAJcmV0dXJu IEJCVE9CKGxlbik7CiB9CiAKKy8qCisgKiBTaW1wbGUgSS9PIChidWZmZXIgY2Fj aGUpIGludGVyZmFjZQorICovCisKKworI2lmZGVmIFhGU19CVUZfVFJBQ0lORwor CisjdW5kZWYgbGlieGZzX3JlYWRidWYKKyN1bmRlZiBsaWJ4ZnNfd3JpdGVidWYK KyN1bmRlZiBsaWJ4ZnNfZ2V0YnVmCisjdW5kZWYgbGlieGZzX3B1dGJ1ZgorCit4 ZnNfYnVmX3QgCSpsaWJ4ZnNfcmVhZGJ1ZihkZXZfdCwgeGZzX2RhZGRyX3QsIGlu dCwgaW50KTsKK2ludAkJbGlieGZzX3dyaXRlYnVmKHhmc19idWZfdCAqLCBpbnQp OworeGZzX2J1Zl90IAkqbGlieGZzX2dldGJ1ZihkZXZfdCwgeGZzX2RhZGRyX3Qs IGludCk7Cit2b2lkCQlsaWJ4ZnNfcHV0YnVmICh4ZnNfYnVmX3QgKik7CisKK3hm c19idWZfdCAqCitsaWJ4ZnNfdHJhY2VfcmVhZGJ1Zihjb25zdCBjaGFyICpmdW5j LCBjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgZGV2X3QgZGV2LCB4ZnNfZGFk ZHJfdCBibGtubywgaW50IGxlbiwgaW50IGZsYWdzKQoreworCXhmc19idWZfdAkq YnAgPSBsaWJ4ZnNfcmVhZGJ1ZihkZXYsIGJsa25vLCBsZW4sIGZsYWdzKTsKKwor CWJwLT5iX2Z1bmMgPSBmdW5jOworCWJwLT5iX2ZpbGUgPSBmaWxlOworCWJwLT5i X2xpbmUgPSBsaW5lOworCisJcmV0dXJuIGJwOworfQorCitpbnQKK2xpYnhmc190 cmFjZV93cml0ZWJ1Zihjb25zdCBjaGFyICpmdW5jLCBjb25zdCBjaGFyICpmaWxl LCBpbnQgbGluZSwgeGZzX2J1Zl90ICpicCwgaW50IGZsYWdzKQoreworCWJwLT5i X2Z1bmMgPSBmdW5jOworCWJwLT5iX2ZpbGUgPSBmaWxlOworCWJwLT5iX2xpbmUg PSBsaW5lOworCisJcmV0dXJuIGxpYnhmc193cml0ZWJ1ZihicCwgZmxhZ3MpOwor fQorCit4ZnNfYnVmX3QgKgorbGlieGZzX3RyYWNlX2dldGJ1Zihjb25zdCBjaGFy ICpmdW5jLCBjb25zdCBjaGFyICpmaWxlLCBpbnQgbGluZSwgZGV2X3QgZGV2aWNl LCB4ZnNfZGFkZHJfdCBibGtubywgaW50IGxlbikKK3sKKwl4ZnNfYnVmX3QJKmJw ID0gbGlieGZzX2dldGJ1ZihkZXZpY2UsIGJsa25vLCBsZW4pOworCisJYnAtPmJf ZnVuYyA9IGZ1bmM7CisJYnAtPmJfZmlsZSA9IGZpbGU7CisJYnAtPmJfbGluZSA9 IGxpbmU7CisKKwlyZXR1cm4gYnA7Cit9CisKK3ZvaWQKK2xpYnhmc190cmFjZV9w dXRidWYoY29uc3QgY2hhciAqZnVuYywgY29uc3QgY2hhciAqZmlsZSwgaW50IGxp bmUsIHhmc19idWZfdCAqYnApCit7CisJYnAtPmJfZnVuYyA9IGZ1bmM7CisJYnAt PmJfZmlsZSA9IGZpbGU7CisJYnAtPmJfbGluZSA9IGxpbmU7CisKKwlsaWJ4ZnNf cHV0YnVmKGJwKTsKK30KKworCisjZW5kaWYKKworCiB4ZnNfYnVmX3QgKgogbGli eGZzX2dldHNiKHhmc19tb3VudF90ICptcCwgaW50IGZsYWdzKQogewpAQCAtMTkw LDIzICsyNTcsMTggQEAKIAkJCQlYRlNfRlNTX1RPX0JCKG1wLCAxKSwgZmxhZ3Mp OwogfQogCi0KLS8qCi0gKiBTaW1wbGUgSS9PIChidWZmZXIgY2FjaGUpIGludGVy ZmFjZQotICovCi0KIHhmc196b25lX3QJKnhmc19idWZfem9uZTsKIAogdHlwZWRl ZiBzdHJ1Y3QgewogCWRldl90CQlkZXZpY2U7CiAJeGZzX2RhZGRyX3QJYmxrbm87 Ci0JdW5zaWduZWQgaW50CWNvdW50OworCXVuc2lnbmVkIGludAliYmxlbjsKIH0g eGZzX2J1ZmtleV90OwogCiBzdGF0aWMgdW5zaWduZWQgaW50CiBsaWJ4ZnNfYmhh c2goY2FjaGVfa2V5X3Qga2V5LCB1bnNpZ25lZCBpbnQgaGFzaHNpemUpCiB7Ci0J cmV0dXJuICgodW5zaWduZWQgaW50KSgoeGZzX2J1ZmtleV90ICopa2V5KS0+Ymxr bm8pICUgaGFzaHNpemU7CisJcmV0dXJuICgoKHVuc2lnbmVkIGludCkoKHhmc19i dWZrZXlfdCAqKWtleSktPmJsa25vKSA+PiA1KSAlIGhhc2hzaXplOwogfQogCiBz dGF0aWMgaW50CkBAIC0yMTgsMTYgKzI4MCwxNyBAQAogI2lmZGVmIElPX0JDT01Q QVJFX0NIRUNLCiAJaWYgKGJwLT5iX2RldiA9PSBia2V5LT5kZXZpY2UgJiYKIAkg ICAgYnAtPmJfYmxrbm8gPT0gYmtleS0+Ymxrbm8gJiYKLQkgICAgYnAtPmJfYmNv dW50ICE9IGJrZXktPmNvdW50KQotCQlmcHJpbnRmKHN0ZGVyciwgIkJhZG5lc3Mg aW4ga2V5IGxvb2t1cCAobGVuZ3RoKVxuIgotCQkJImJwPShibm8gJWxsdSwgbGVu ICV1IGJiKSBrZXk9KGJubyAlbGx1LCBsZW4gJXUgYmJzKVxuIiwKKwkgICAgYnAt PmJfYmNvdW50ICE9IEJCVE9CKGJrZXktPmJibGVuKSkKKwkJZnByaW50ZihzdGRl cnIsICIlbHg6IEJhZG5lc3MgaW4ga2V5IGxvb2t1cCAobGVuZ3RoKVxuIgorCQkJ ImJwPShibm8gJWxsdSwgbGVuICV1IGJ5dGVzKSBrZXk9KGJubyAlbGx1LCBsZW4g JXUgYnl0ZXMpXG4iLAorCQkJcHRocmVhZF9zZWxmKCksCiAJCQkodW5zaWduZWQg bG9uZyBsb25nKWJwLT5iX2Jsa25vLCAoaW50KWJwLT5iX2Jjb3VudCwKLQkJCSh1 bnNpZ25lZCBsb25nIGxvbmcpYmtleS0+Ymxrbm8sIChpbnQpYmtleS0+Y291bnQp OworCQkJKHVuc2lnbmVkIGxvbmcgbG9uZylia2V5LT5ibGtubywgQkJUT0IoYmtl eS0+YmJsZW4pKTsKICNlbmRpZgogCiAJcmV0dXJuIChicC0+Yl9kZXYgPT0gYmtl eS0+ZGV2aWNlICYmCiAJCWJwLT5iX2Jsa25vID09IGJrZXktPmJsa25vICYmCi0J CWJwLT5iX2Jjb3VudCA9PSBia2V5LT5jb3VudCk7CisJCWJwLT5iX2Jjb3VudCA9 PSBCQlRPQihia2V5LT5iYmxlbikpOwogfQogCiB2b2lkCkBAIC0yMzksMjcgKzMw Miw2IEBACiB9CiAKIHN0YXRpYyB2b2lkCi1saWJ4ZnNfYnJlbHNlKHN0cnVjdCBj YWNoZV9ub2RlICpub2RlKQotewotCXhmc19idWZfdAkJKmJwID0gKHhmc19idWZf dCAqKW5vZGU7Ci0JeGZzX2J1Zl9sb2dfaXRlbV90CSpiaXA7Ci0JZXh0ZXJuIHhm c196b25lX3QJKnhmc19idWZfaXRlbV96b25lOwotCi0JaWYgKGJwICE9IE5VTEwp IHsKLQkJaWYgKGJwLT5iX2ZsYWdzICYgTElCWEZTX0JfRElSVFkpCi0JCQlsaWJ4 ZnNfd3JpdGVidWZyKGJwKTsKLQkJYmlwID0gWEZTX0JVRl9GU1BSSVZBVEUoYnAs IHhmc19idWZfbG9nX2l0ZW1fdCAqKTsKLQkJaWYgKGJpcCkKLQkJICAgIGxpYnhm c196b25lX2ZyZWUoeGZzX2J1Zl9pdGVtX3pvbmUsIGJpcCk7Ci0JCWZyZWUoYnAt PmJfYWRkcik7Ci0JCWJwLT5iX2FkZHIgPSBOVUxMOwotCQlicC0+Yl9mbGFncyA9 IDA7Ci0JCWZyZWUoYnApOwotCQlicCA9IE5VTEw7Ci0JfQotfQotCi1zdGF0aWMg dm9pZAogbGlieGZzX2luaXRidWYoeGZzX2J1Zl90ICpicCwgZGV2X3QgZGV2aWNl LCB4ZnNfZGFkZHJfdCBibm8sIHVuc2lnbmVkIGludCBieXRlcykKIHsKIAlicC0+ Yl9mbGFncyA9IDA7CkBAIC0yNzQsNiArMzE2LDEwIEBACiAJCQlzdHJlcnJvcihl cnJubykpOwogCQlleGl0KDEpOwogCX0KKyNpZmRlZiBYRlNfQlVGX1RSQUNJTkcK KwlsaXN0X2hlYWRfaW5pdCgmYnAtPmJfbG9ja19saXN0KTsKKyNlbmRpZgorCXB0 aHJlYWRfbXV0ZXhfaW5pdCgmYnAtPmJfbG9jaywgTlVMTCk7CiB9CiAKIHhmc19i dWZfdCAqCkBAIC0yODIsNDEgKzMyOCw2MyBAQAogCXhmc19idWZfdAkqYnA7CiAK IAlicCA9IGxpYnhmc196b25lX3phbGxvYyh4ZnNfYnVmX3pvbmUpOwotCWxpYnhm c19pbml0YnVmKGJwLCBkZXZpY2UsIGJsa25vLCBCQlRPQihsZW4pKTsKKwlpZiAo YnAgIT0gTlVMTCkKKwkJbGlieGZzX2luaXRidWYoYnAsIGRldmljZSwgYmxrbm8s IEJCVE9CKGxlbikpOworI2lmZGVmIElPX0RFQlVHCisJcHJpbnRmKCIlbHg6ICVz OiBhbGxvY2F0ZWQgJXUgYnl0ZXMgYnVmZmVyLCBrZXk9JWxsdSglbGx1KSwgJXBc biIsCisJCXB0aHJlYWRfc2VsZigpLCBfX0ZVTkNUSU9OX18sIEJCVE9CKGxlbiks CisJCShsb25nIGxvbmcpTElCWEZTX0JCVE9PRkY2NChibGtubyksIChsb25nIGxv bmcpYmxrbm8sIGJwKTsKKyNlbmRpZgogCXJldHVybiBicDsKIH0KIAotdm9pZAot bGlieGZzX3B1dGJ1ZnIoeGZzX2J1Zl90ICpicCkKLXsKLQlsaWJ4ZnNfYnJlbHNl KChzdHJ1Y3QgY2FjaGVfbm9kZSAqKWJwKTsKLX0KKworI2lmZGVmIFhGU19CVUZf VFJBQ0lORworc3RydWN0IGxpc3RfaGVhZAlsb2NrX2J1Zl9saXN0ID0geyZsb2Nr X2J1Zl9saXN0LCAmbG9ja19idWZfbGlzdH07CitpbnQJCQlsb2NrX2J1Zl9jb3Vu dCA9IDA7CisjZW5kaWYKIAogeGZzX2J1Zl90ICoKIGxpYnhmc19nZXRidWYoZGV2 X3QgZGV2aWNlLCB4ZnNfZGFkZHJfdCBibGtubywgaW50IGxlbikKIHsKIAl4ZnNf YnVmX3QJKmJwOwogCXhmc19idWZrZXlfdAlrZXk7Ci0JdW5zaWduZWQgaW50CWJ5 dGVzID0gQkJUT0IobGVuKTsKKwlpbnQJCW1pc3M7CiAKIAlrZXkuZGV2aWNlID0g ZGV2aWNlOwogCWtleS5ibGtubyA9IGJsa25vOwotCWtleS5jb3VudCA9IGJ5dGVz OworCWtleS5iYmxlbiA9IGxlbjsKIAotCWlmIChjYWNoZV9ub2RlX2dldChsaWJ4 ZnNfYmNhY2hlLCAma2V5LCAoc3RydWN0IGNhY2hlX25vZGUgKiopJmJwKSkgewor CW1pc3MgPSBjYWNoZV9ub2RlX2dldChsaWJ4ZnNfYmNhY2hlLCAma2V5LCAoc3Ry dWN0IGNhY2hlX25vZGUgKiopJmJwKTsKKwlpZiAoYnApIHsKKwkJcHRocmVhZF9t dXRleF9sb2NrKCZicC0+Yl9sb2NrKTsKKyNpZmRlZiBYRlNfQlVGX1RSQUNJTkcK KwkJcHRocmVhZF9tdXRleF9sb2NrKCZsaWJ4ZnNfYmNhY2hlLT5jX211dGV4KTsK KwkJbG9ja19idWZfY291bnQrKzsKKwkJbGlzdF9hZGQoJmJwLT5iX2xvY2tfbGlz dCwgJmxvY2tfYnVmX2xpc3QpOworCQlwdGhyZWFkX211dGV4X3VubG9jaygmbGli eGZzX2JjYWNoZS0+Y19tdXRleCk7CisjZW5kaWYKICNpZmRlZiBJT19ERUJVRwot CQlmcHJpbnRmKHN0ZGVyciwgIiVzOiBhbGxvY2F0ZWQgJXVieXRlcyBidWZmZXIs IGtleT0lbGx1KCVsbHUpLCAlcFxuIiwKLQkJCV9fRlVOQ1RJT05fXywgQkJUT0Io bGVuKSwKLQkJCShsb25nIGxvbmcpTElCWEZTX0JCVE9PRkY2NChibGtubyksIChs b25nIGxvbmcpYmxrbm8sIGJwKTsKKwkJcHJpbnRmKCIlbHggJXM6ICVzIGJ1ZmZl ciAlcCBmb3IgYm5vID0gJWxsdVxuIiwKKwkJCXB0aHJlYWRfc2VsZigpLCBfX0ZV TkNUSU9OX18sIG1pc3MgPyAibWlzcyIgOiAiaGl0IiwKKwkJCWJwLCAobG9uZyBs b25nKUxJQlhGU19CQlRPT0ZGNjQoYmxrbm8pKTsKICNlbmRpZgotCQlsaWJ4ZnNf aW5pdGJ1ZihicCwgZGV2aWNlLCBibGtubywgYnl0ZXMpOwogCX0KKwogCXJldHVy biBicDsKIH0KIAogdm9pZAogbGlieGZzX3B1dGJ1Zih4ZnNfYnVmX3QgKmJwKQog eworI2lmZGVmIFhGU19CVUZfVFJBQ0lORworCXB0aHJlYWRfbXV0ZXhfbG9jaygm bGlieGZzX2JjYWNoZS0+Y19tdXRleCk7CisJbG9ja19idWZfY291bnQtLTsKKwlB U1NFUlQobG9ja19idWZfY291bnQgPj0gMCk7CisJbGlzdF9kZWxfaW5pdCgmYnAt PmJfbG9ja19saXN0KTsKKwlwdGhyZWFkX211dGV4X3VubG9jaygmbGlieGZzX2Jj YWNoZS0+Y19tdXRleCk7CisjZW5kaWYKKwlwdGhyZWFkX211dGV4X3VubG9jaygm YnAtPmJfbG9jayk7CiAJY2FjaGVfbm9kZV9wdXQoKHN0cnVjdCBjYWNoZV9ub2Rl ICopYnApOwogfQogCkBAIC0zMjcsMTUgKzM5NSwxOCBAQAogCiAJa2V5LmRldmlj ZSA9IGJwLT5iX2RldjsKIAlrZXkuYmxrbm8gPSBicC0+Yl9ibGtubzsKLQlrZXku Y291bnQgPSBicC0+Yl9iY291bnQ7CisJa2V5LmJibGVuID0gYnAtPmJfYmNvdW50 ID4+IEJCU0hJRlQ7CiAKIAljYWNoZV9ub2RlX3B1cmdlKGxpYnhmc19iY2FjaGUs ICZrZXksIChzdHJ1Y3QgY2FjaGVfbm9kZSAqKWJwKTsKIH0KIAogc3RhdGljIHN0 cnVjdCBjYWNoZV9ub2RlICoKLWxpYnhmc19iYWxsb2Modm9pZCkKK2xpYnhmc19i YWxsb2MoY2FjaGVfa2V5X3Qga2V5KQogewotCXJldHVybiBsaWJ4ZnNfem9uZV96 YWxsb2MoeGZzX2J1Zl96b25lKTsKKwl4ZnNfYnVma2V5X3QJKmJ1ZmtleSA9ICh4 ZnNfYnVma2V5X3QgKilrZXk7CisKKwlyZXR1cm4gKHN0cnVjdCBjYWNoZV9ub2Rl ICopbGlieGZzX2dldGJ1ZnIoYnVma2V5LT5kZXZpY2UsCisJCQkJCWJ1ZmtleS0+ Ymxrbm8sIGJ1ZmtleS0+YmJsZW4pOwogfQogCiBpbnQKQEAgLTM1NCw4ICs0MjUs OSBAQAogCQlyZXR1cm4gZXJybm87CiAJfQogI2lmZGVmIElPX0RFQlVHCi0JZnBy aW50ZihzdGRlcnIsICJyZWFkYnVmciByZWFkICV1Ynl0ZXMsIGJsa25vPSVsbHUo JWxsdSksICVwXG4iLAotCQlieXRlcywgKGxvbmcgbG9uZylMSUJYRlNfQkJUT09G RjY0KGJsa25vKSwgKGxvbmcgbG9uZylibGtubywgYnApOworCXByaW50ZigiJWx4 OiAlczogcmVhZCAldSBieXRlcywgYmxrbm89JWxsdSglbGx1KSwgJXBcbiIsCisJ CXB0aHJlYWRfc2VsZigpLCBfX0ZVTkNUSU9OX18sIGJ5dGVzLAorCQkobG9uZyBs b25nKUxJQlhGU19CQlRPT0ZGNjQoYmxrbm8pLCAobG9uZyBsb25nKWJsa25vLCBi cCk7CiAjZW5kaWYKIAlpZiAoYnAtPmJfZGV2ID09IGRldiAmJgogCSAgICBicC0+ Yl9ibGtubyA9PSBibGtubyAmJgpAQCAtMzcxLDcgKzQ0Myw3IEBACiAJaW50CQll cnJvcjsKIAogCWJwID0gbGlieGZzX2dldGJ1ZihkZXYsIGJsa25vLCBsZW4pOwot CWlmICghKGJwLT5iX2ZsYWdzICYgKExJQlhGU19CX1VQVE9EQVRFfExJQlhGU19C X0RJUlRZKSkpIHsKKwlpZiAoYnAgJiYgIShicC0+Yl9mbGFncyAmIChMSUJYRlNf Ql9VUFRPREFURXxMSUJYRlNfQl9ESVJUWSkpKSB7CiAJCWVycm9yID0gbGlieGZz X3JlYWRidWZyKGRldiwgYmxrbm8sIGJwLCBsZW4sIGZsYWdzKTsKIAkJaWYgKGVy cm9yKSB7CiAJCQlsaWJ4ZnNfcHV0YnVmKGJwKTsKQEAgLTQwMyw5ICs0NzUsMTAg QEAKIAkJcmV0dXJuIEVJTzsKIAl9CiAjaWZkZWYgSU9fREVCVUcKLQlmcHJpbnRm KHN0ZGVyciwgIndyaXRlYnVmciB3cm90ZSAldWJ5dGVzLCBibGtubz0lbGx1KCVs bHUpLCAlcFxuIiwKLQkJYnAtPmJfYmNvdW50LCAobG9uZyBsb25nKUxJQlhGU19C QlRPT0ZGNjQoYnAtPmJfYmxrbm8pLAotCQkobG9uZyBsb25nKWJwLT5iX2Jsa25v LCBicCk7CisJcHJpbnRmKCIlbHg6ICVzOiB3cm90ZSAldSBieXRlcywgYmxrbm89 JWxsdSglbGx1KSwgJXBcbiIsCisJCQlwdGhyZWFkX3NlbGYoKSwgX19GVU5DVElP Tl9fLCBicC0+Yl9iY291bnQsCisJCQkobG9uZyBsb25nKUxJQlhGU19CQlRPT0ZG NjQoYnAtPmJfYmxrbm8pLAorCQkJKGxvbmcgbG9uZylicC0+Yl9ibGtubywgYnAp OwogI2VuZGlmCiAJYnAtPmJfZmxhZ3MgfD0gTElCWEZTX0JfVVBUT0RBVEU7CiAJ YnAtPmJfZmxhZ3MgJj0gfihMSUJYRlNfQl9ESVJUWSB8IExJQlhGU19CX0VYSVQp OwpAQCAtNDMyLDcgKzUwNSw3IEBACiB7CiAjaWZkZWYgSU9fREVCVUcKIAlpZiAo Ym9mZiArIGxlbiA+IGJwLT5iX2Jjb3VudCkgewotCQlmcHJpbnRmKHN0ZGVyciwg IkJhZG5lc3MsIGlvbW92ZSBvdXQgb2YgcmFuZ2UhXG4iCisJCXByaW50ZigiQmFk bmVzcywgaW9tb3ZlIG91dCBvZiByYW5nZSFcbiIKIAkJCSJicD0oYm5vICVsbHUs IGJ5dGVzICV1KSByYW5nZT0oYm9mZiAldSwgYnl0ZXMgJXUpXG4iLAogCQkJKGxv bmcgbG9uZylicC0+Yl9ibGtubywgYnAtPmJfYmNvdW50LCBib2ZmLCBsZW4pOwog CQlhYm9ydCgpOwpAQCAtNDYwLDYgKzUzMywzNSBAQAogCQlsaWJ4ZnNfd3JpdGVi dWZyKGJwKTsKIH0KIAorc3RhdGljIHZvaWQKK2xpYnhmc19icmVsc2Uoc3RydWN0 IGNhY2hlX25vZGUgKm5vZGUpCit7CisJeGZzX2J1Zl90CQkqYnAgPSAoeGZzX2J1 Zl90ICopbm9kZTsKKwl4ZnNfYnVmX2xvZ19pdGVtX3QJKmJpcDsKKwlleHRlcm4g eGZzX3pvbmVfdAkqeGZzX2J1Zl9pdGVtX3pvbmU7CisKKwlpZiAoYnAgIT0gTlVM TCkgeworCQlpZiAoYnAtPmJfZmxhZ3MgJiBMSUJYRlNfQl9ESVJUWSkKKwkJCWxp Ynhmc193cml0ZWJ1ZnIoYnApOworCQliaXAgPSBYRlNfQlVGX0ZTUFJJVkFURShi cCwgeGZzX2J1Zl9sb2dfaXRlbV90ICopOworCQlpZiAoYmlwKQorCQkJbGlieGZz X3pvbmVfZnJlZSh4ZnNfYnVmX2l0ZW1fem9uZSwgYmlwKTsKKwkJZnJlZShicC0+ Yl9hZGRyKTsKKwkJcHRocmVhZF9tdXRleF9kZXN0cm95KCZicC0+Yl9sb2NrKTsK KwkJYnAtPmJfYWRkciA9IE5VTEw7CisJCWJwLT5iX2ZsYWdzID0gMDsKKwkJZnJl ZShicCk7CisJCWJwID0gTlVMTDsKKwl9Cit9CisKK3ZvaWQKK2xpYnhmc19wdXRi dWZyKHhmc19idWZfdCAqYnApCit7CisJbGlieGZzX2JyZWxzZSgoc3RydWN0IGNh Y2hlX25vZGUgKilicCk7Cit9CisKKwogdm9pZAogbGlieGZzX2JjYWNoZV9wdXJn ZSh2b2lkKQogewpAQCAtNDcyLDYgKzU3NCwxMiBAQAogCWNhY2hlX2ZsdXNoKGxp Ynhmc19iY2FjaGUpOwogfQogCitpbnQKK2xpYnhmc19iY2FjaGVfb3ZlcmZsb3dl ZCh2b2lkKQoreworCXJldHVybiBjYWNoZV9vdmVyZmxvd2VkKGxpYnhmc19iY2Fj aGUpOworfQorCiBzdHJ1Y3QgY2FjaGVfb3BlcmF0aW9ucyBsaWJ4ZnNfYmNhY2hl X29wZXJhdGlvbnMgPSB7CiAJLyogLmhhc2ggKi8JbGlieGZzX2JoYXNoLAogCS8q IC5hbGxvYyAqLwlsaWJ4ZnNfYmFsbG9jLApAQCAtNjM3LDcgKzc0NSw3IEBACiB9 CiAKIHN0YXRpYyBzdHJ1Y3QgY2FjaGVfbm9kZSAqCi1saWJ4ZnNfaWFsbG9jKHZv aWQpCitsaWJ4ZnNfaWFsbG9jKGNhY2hlX2tleV90IGtleSkKIHsKIAlyZXR1cm4g bGlieGZzX3pvbmVfemFsbG9jKHhmc19pbm9kZV96b25lKTsKIH0KSW5kZXg6IHJl cGFpci94ZnNwcm9ncy9yZXBhaXIvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVwYWlyL01ha2VmaWxlCTIwMDct MDQtMjcgMTM6MTM6MzUuMDAwMDAwMDAwICsxMDAwCisrKyByZXBhaXIveGZzcHJv Z3MvcmVwYWlyL01ha2VmaWxlCTIwMDctMDYtMDQgMTc6Mzk6NTkuMTIxMDAwNTA2 ICsxMDAwCkBAIC04LDE1ICs4LDE2IEBACiBMVENPTU1BTkQgPSB4ZnNfcmVwYWly CiAKIEhGSUxFUyA9IGFnaGVhZGVyLmggYXR0cl9yZXBhaXIuaCBhdmwuaCBhdmw2 NC5oIGJtYXAuaCBkaW5vZGUuaCBkaXIuaCBcCi0JZGlyMi5oIGRpcl9zdGFjay5o IGVycl9wcm90b3MuaCBnbG9iYWxzLmggaW5jb3JlLmggcHJvdG9zLmggcnQuaCBc Ci0JcHJvZ3Jlc3MuaCBzY2FuLmggdmVyc2lvbnMuaCBwcmVmZXRjaC5oIHRocmVh ZHMuaCB0cmFja21lbS5oCisJZGlyMi5oIGVycl9wcm90b3MuaCBnbG9iYWxzLmgg aW5jb3JlLmggcHJvdG9zLmggcnQuaCBcCisJcHJvZ3Jlc3MuaCBzY2FuLmggdmVy c2lvbnMuaCBwcmVmZXRjaC5oIHJhZGl4LXRyZWUuaCB0aHJlYWRzLmggXAorCXRy YWNrbWVtLmgKIAogQ0ZJTEVTID0gYWdoZWFkZXIuYyBhdHRyX3JlcGFpci5jIGF2 bC5jIGF2bDY0LmMgYm1hcC5jIGRpbm9fY2h1bmtzLmMgXAotCWRpbm9kZS5jIGRp ci5jIGRpcjIuYyBkaXJfc3RhY2suYyBnbG9iYWxzLmMgaW5jb3JlLmMgXAorCWRp bm9kZS5jIGRpci5jIGRpcjIuYyBnbG9iYWxzLmMgaW5jb3JlLmMgXAogCWluY29y ZV9ibWMuYyBpbml0LmMgaW5jb3JlX2V4dC5jIGluY29yZV9pbm8uYyBwaGFzZTEu YyBcCi0JcGhhc2UyLmMgcGhhc2UzLmMgcGhhc2U0LmMgcGhhc2U1LmMgcGhhc2U2 LmMgcGhhc2U3LmMgcnQuYyBzYi5jIFwKLQlwcm9ncmVzcy5jIHByZWZldGNoLmMg c2Nhbi5jIHRocmVhZHMuYyB0cmFja21lbS5jIHZlcnNpb25zLmMgXAotCXhmc19y ZXBhaXIuYworCXBoYXNlMi5jIHBoYXNlMy5jIHBoYXNlNC5jIHBoYXNlNS5jIHBo YXNlNi5jIHBoYXNlNy5jIFwKKwlwcm9ncmVzcy5jIHByZWZldGNoLmMgcmFkaXgt dHJlZS5jIHJ0LmMgc2IuYyBzY2FuLmMgdGhyZWFkcy5jIFwKKwl0cmFja21lbS5j IHZlcnNpb25zLmMgeGZzX3JlcGFpci5jCiAKIExMRExJQlMgPSAkKExJQlhGUykg JChMSUJYTE9HKSAkKExJQlVVSUQpICQoTElCUFRIUkVBRCkgJChMSUJSVCkKIExU REVQRU5ERU5DSUVTID0gJChMSUJYRlMpICQoTElCWExPRykKQEAgLTQwLDYgKzQx LDggQEAKICMgLURYUl9CTERfSU5PX1RSQUNFCWJ1aWxkaW5nIG9uLWRpc2sgaW5v ZGUgYWxsb2NhdGlvbiBidHJlZXMKICMgLURYUl9CTERfQUREX0VYVEVOVAl0cmFj ayBwaGFzZSA1IGJsb2NrIGV4dGVudCBjcmVhdGlvbgogIyAtRFhSX0JDS1BUUl9E QkcJcGFyZW50IGxpc3QgZGVidWdnaW5nIGluZm8KKyMgLURYUl9QRl9UUkFDRQkJ cHJlZmV0Y2ggdHJhY2UKKyMgLURUUkFDRV9NRU1PUlkJdHJhY2sgbWVtb3J5IHVz YWdlCiAjCiAjQ0ZMQUdTICs9IC4uLgogCkluZGV4OiByZXBhaXIveGZzcHJvZ3Mv cmVwYWlyL2Rpbm9fY2h1bmtzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gcmVw YWlyLm9yaWcveGZzcHJvZ3MvcmVwYWlyL2Rpbm9fY2h1bmtzLmMJMjAwNy0wNC0y NyAxNDoxMTo0MS4wMDAwMDAwMDAgKzEwMDAKKysrIHJlcGFpci94ZnNwcm9ncy9y ZXBhaXIvZGlub19jaHVua3MuYwkyMDA3LTA1LTI5IDExOjE4OjI4LjU4NTA2OTY0 OSArMTAwMApAQCAtMjUsOSArMjUsOCBAQAogI2luY2x1ZGUgImVycl9wcm90b3Mu aCIKICNpbmNsdWRlICJkaXIuaCIKICNpbmNsdWRlICJkaW5vZGUuaCIKLSNpbmNs dWRlICJwcmVmZXRjaC5oIgotI2luY2x1ZGUgInRocmVhZHMuaCIKICNpbmNsdWRl ICJ2ZXJzaW9ucy5oIgorI2luY2x1ZGUgInByZWZldGNoLmgiCiAjaW5jbHVkZSAi cHJvZ3Jlc3MuaCIKIAogLyoKQEAgLTE1MCwxOSArMTQ5LDE4IEBACiAJCWlmIChj aGVja19pbm9kZV9ibG9jayhtcCwgaW5vKSA9PSAwKQogCQkJcmV0dXJuKDApOwog Ci0JCVBSRVBBSVJfUldfV1JJVEVfTE9DSygmcGVyX2FnX2xvY2tbYWdub10pOwor CQlwdGhyZWFkX211dGV4X2xvY2soJmFnX2xvY2tzW2Fnbm9dKTsKKwogCQlzd2l0 Y2ggKHN0YXRlID0gZ2V0X2FnYm5vX3N0YXRlKG1wLCBhZ25vLCBhZ2JubykpICB7 CiAJCWNhc2UgWFJfRV9JTk86CiAJCQlkb193YXJuKAogCQlfKCJ1bmNlcnRhaW4g aW5vZGUgYmxvY2sgJWQvJWQgYWxyZWFkeSBrbm93blxuIiksCiAJCQkJYWdubywg YWdibm8pOwotCQkJUFJFUEFJUl9SV19VTkxPQ0soJnBlcl9hZ19sb2NrW2Fnbm9d KTsKIAkJCWJyZWFrOwogCQljYXNlIFhSX0VfVU5LTk9XTjoKIAkJY2FzZSBYUl9F X0ZSRUUxOgogCQljYXNlIFhSX0VfRlJFRToKIAkJCXNldF9hZ2Jub19zdGF0ZSht cCwgYWdubywgYWdibm8sIFhSX0VfSU5PKTsKLQkJCVBSRVBBSVJfUldfVU5MT0NL KCZwZXJfYWdfbG9ja1thZ25vXSk7CiAJCQlicmVhazsKIAkJY2FzZSBYUl9FX01V TFQ6CiAJCWNhc2UgWFJfRV9JTlVTRToKQEAgLTE3NSwxNyArMTczLDE4IEBACiAJ CV8oImlub2RlIGJsb2NrICVkLyVkIG11bHRpcGx5IGNsYWltZWQsIChzdGF0ZSAl ZClcbiIpLAogCQkJCWFnbm8sIGFnYm5vLCBzdGF0ZSk7CiAJCQlzZXRfYWdibm9f c3RhdGUobXAsIGFnbm8sIGFnYm5vLCBYUl9FX01VTFQpOwotCQkJUFJFUEFJUl9S V19VTkxPQ0soJnBlcl9hZ19sb2NrW2Fnbm9dKTsKKwkJCXB0aHJlYWRfbXV0ZXhf dW5sb2NrKCZhZ19sb2Nrc1thZ25vXSk7CiAJCQlyZXR1cm4oMCk7CiAJCWRlZmF1 bHQ6CiAJCQlkb193YXJuKAogCQlfKCJpbm9kZSBibG9jayAlZC8lZCBiYWQgc3Rh dGUsIChzdGF0ZSAlZClcbiIpLAogCQkJCWFnbm8sIGFnYm5vLCBzdGF0ZSk7CiAJ CQlzZXRfYWdibm9fc3RhdGUobXAsIGFnbm8sIGFnYm5vLCBYUl9FX0lOTyk7Ci0J CQlQUkVQQUlSX1JXX1VOTE9DSygmcGVyX2FnX2xvY2tbYWdub10pOwogCQkJYnJl YWs7CiAJCX0KIAorCQlwdGhyZWFkX211dGV4X3VubG9jaygmYWdfbG9ja3NbYWdu b10pOworCiAJCXN0YXJ0X2FnaW5vID0gWEZTX09GRkJOT19UT19BR0lOTyhtcCwg YWdibm8sIDApOwogCQkqc3RhcnRfaW5vID0gWEZTX0FHSU5PX1RPX0lOTyhtcCwg YWdubywgc3RhcnRfYWdpbm8pOwogCkBAIC00MzIsNyArNDMxLDcgQEAKIAkgKiB1 c2VyIGRhdGEgLS0gd2UncmUgcHJvYmFibHkgaGVyZSBhcyBhIHJlc3VsdCBvZiBh IGRpcmVjdG9yeQogCSAqIGVudHJ5IG9yIGFuIGl1bmxpbmtlZCBwb2ludGVyCiAJ ICovCi0JUFJFUEFJUl9SV19XUklURV9MT0NLKCZwZXJfYWdfbG9ja1thZ25vXSk7 CisJcHRocmVhZF9tdXRleF9sb2NrKCZhZ19sb2Nrc1thZ25vXSk7CiAJZm9yIChq ID0gMCwgY3VyX2FnYm5vID0gY2h1bmtfc3RhcnRfYWdibm87CiAJCQljdXJfYWdi bm8gPCBjaHVua19zdG9wX2FnYm5vOyBjdXJfYWdibm8rKykgIHsKIAkJc3dpdGNo IChzdGF0ZSA9IGdldF9hZ2Jub19zdGF0ZShtcCwgYWdubywgY3VyX2FnYm5vKSkg IHsKQEAgLTQ1NiwxMSArNDU1LDExIEBACiAJCX0KIAogCQlpZiAoaikgewotCQkJ UFJFUEFJUl9SV19VTkxPQ0soJnBlcl9hZ19sb2NrW2Fnbm9dKTsKKwkJCXB0aHJl YWRfbXV0ZXhfdW5sb2NrKCZhZ19sb2Nrc1thZ25vXSk7CiAJCQlyZXR1cm4oMCk7 CiAJCX0KIAl9Ci0JUFJFUEFJUl9SV19VTkxPQ0soJnBlcl9hZ19sb2NrW2Fnbm9d KTsKKwlwdGhyZWFkX211dGV4X3VubG9jaygmYWdfbG9ja3NbYWdub10pOwogCiAJ LyoKIAkgKiBvaywgY2h1bmsgaXMgZ29vZC4gIHB1dCB0aGUgcmVjb3JkIGludG8g dGhlIHRyZWUgaWYgcmVxdWlyZWQsCkBAIC00ODMsNyArNDgyLDggQEAKIAogCXNl dF9pbm9kZV91c2VkKGlyZWNfcCwgYWdpbm8gLSBzdGFydF9hZ2lubyk7CiAKLQlQ UkVQQUlSX1JXX1dSSVRFX0xPQ0soJnBlcl9hZ19sb2NrW2Fnbm9dKTsKKwlwdGhy ZWFkX211dGV4X2xvY2soJmFnX2xvY2tzW2Fnbm9dKTsKKwogCWZvciAoY3VyX2Fn Ym5vID0gY2h1bmtfc3RhcnRfYWdibm87CiAJCQljdXJfYWdibm8gPCBjaHVua19z dG9wX2FnYm5vOyBjdXJfYWdibm8rKykgIHsKIAkJc3dpdGNoIChzdGF0ZSA9IGdl dF9hZ2Jub19zdGF0ZShtcCwgYWdubywgY3VyX2FnYm5vKSkgIHsKQEAgLTUxMyw3 ICs1MTMsNyBAQAogCQkJYnJlYWs7CiAJCX0KIAl9Ci0JUFJFUEFJUl9SV19VTkxP Q0soJnBlcl9hZ19sb2NrW2Fnbm9dKTsKKwlwdGhyZWFkX211dGV4X3VubG9jaygm YWdfbG9ja3NbYWdub10pOwogCiAJcmV0dXJuKGlub19jbnQpOwogfQpAQCAtNTY2 LDIxICs1NjYsMjcgQEAKICAqCiAgKiAqYm9ndXMgaXMgc2V0IHRvIDEgaWYgdGhl IGVudGlyZSBzZXQgb2YgaW5vZGVzIGlzIGJhZC4KICAqLworCiAvKiBBUkdTVVNF RCAqLwotaW50Ci1wcm9jZXNzX2lub2RlX2NodW5rKHhmc19tb3VudF90ICptcCwg eGZzX2FnbnVtYmVyX3QgYWdubywgaW50IG51bV9pbm9zLAotCQkJaW5vX3RyZWVf bm9kZV90ICpmaXJzdF9pcmVjLCBpbnQgaW5vX2Rpc2NvdmVyeSwKLQkJCWludCBj aGVja19kdXBzLCBpbnQgZXh0cmFfYXR0cl9jaGVjaywgaW50ICpib2d1cykKK3N0 YXRpYyBpbnQKK3Byb2Nlc3NfaW5vZGVfY2h1bmsoCisJeGZzX21vdW50X3QgCQkq bXAsCisJeGZzX2FnbnVtYmVyX3QJCWFnbm8sCisJaW50IAkJCW51bV9pbm9zLAor CWlub190cmVlX25vZGVfdCAJKmZpcnN0X2lyZWMsCisJaW50IAkJCWlub19kaXNj b3ZlcnksCisJaW50IAkJCWNoZWNrX2R1cHMsCisJaW50IAkJCWV4dHJhX2F0dHJf Y2hlY2ssCisJaW50IAkJCSpib2d1cykKIHsKIAl4ZnNfaW5vX3QJCXBhcmVudDsK IAlpbm9fdHJlZV9ub2RlX3QJCSppbm9fcmVjOwotCXhmc19idWZfdAkJKmJwOwor CXhmc19idWZfdAkJKipicGxpc3Q7CiAJeGZzX2Rpbm9kZV90CQkqZGlubzsKIAlp bnQJCQlpY250OwogCWludAkJCXN0YXR1czsKIAlpbnQJCQlpc191c2VkOwogCWlu dAkJCXN0YXRlOwotCWludAkJCWRvbmU7CiAJaW50CQkJaW5vX2RpcnR5OwogCWlu dAkJCWlyZWNfb2Zmc2V0OwogCWludAkJCWlidWZfb2Zmc2V0OwpAQCAtNTg5LDYg KzU5NSwxMCBAQAogCWludAkJCWRpcnR5ID0gMDsKIAlpbnQJCQljbGVhcmVkID0g MDsKIAlpbnQJCQlpc2FfZGlyID0gMDsKKwlpbnQJCQlibGtzX3Blcl9jbHVzdGVy OworCWludAkJCWNsdXN0ZXJfY291bnQ7CisJaW50CQkJYnBfaW5kZXg7CisJaW50 CQkJY2x1c3Rlcl9vZmZzZXQ7CiAKIAlBU1NFUlQoZmlyc3RfaXJlYyAhPSBOVUxM KTsKIAlBU1NFUlQoWEZTX0FHSU5PX1RPX09GRlNFVChtcCwgZmlyc3RfaXJlYy0+ aW5vX3N0YXJ0bnVtKSA9PSAwKTsKQEAgLTU5Niw0NCArNjA2LDc3IEBACiAJKmJv Z3VzID0gMDsKIAlBU1NFUlQoWEZTX0lBTExPQ19CTE9DS1MobXApID4gMCk7CiAK KwlibGtzX3Blcl9jbHVzdGVyID0gWEZTX0lOT0RFX0NMVVNURVJfU0laRShtcCkg Pj4gbXAtPm1fc2Iuc2JfYmxvY2tsb2c7CisJaWYgKGJsa3NfcGVyX2NsdXN0ZXIg PT0gMCkKKwkJYmxrc19wZXJfY2x1c3RlciA9IDE7CisJY2x1c3Rlcl9jb3VudCA9 IFhGU19JTk9ERVNfUEVSX0NIVU5LIC8gaW5vZGVzX3Blcl9jbHVzdGVyOworCUFT U0VSVChjbHVzdGVyX2NvdW50ID4gMCk7CisKIAkvKgogCSAqIGdldCBhbGwgYmxv Y2tzIHJlcXVpcmVkIHRvIHJlYWQgaW4gdGhpcyBjaHVuayAobWF5IHdpbmQgdXAK IAkgKiBoYXZpbmcgdG8gcHJvY2VzcyBtb3JlIGNodW5rcyBpbiBhIG11bHRpLWNo dW5rIHBlciBibG9jayBmcykKIAkgKi8KIAlhZ2JubyA9IFhGU19BR0lOT19UT19B R0JOTyhtcCwgZmlyc3RfaXJlYy0+aW5vX3N0YXJ0bnVtKTsKIAotCWJwID0gbGli eGZzX3JlYWRidWYobXAtPm1fZGV2LCBYRlNfQUdCX1RPX0RBRERSKG1wLCBhZ25v LCBhZ2JubyksCi0JCQlYRlNfRlNCX1RPX0JCKG1wLCBYRlNfSUFMTE9DX0JMT0NL UyhtcCkpLCAwKTsKLQlpZiAoIWJwKSB7Ci0JCWRvX3dhcm4oXygiY2Fubm90IHJl YWQgaW5vZGUgJWxsdSwgZGlzayBibG9jayAlbGxkLCBjbnQgJWRcbiIpLAotCQkJ WEZTX0FHSU5PX1RPX0lOTyhtcCwgYWdubywgZmlyc3RfaXJlYy0+aW5vX3N0YXJ0 bnVtKSwKLQkJCVhGU19BR0JfVE9fREFERFIobXAsIGFnbm8sIGFnYm5vKSwKLQkJ CShpbnQpWEZTX0ZTQl9UT19CQihtcCwgWEZTX0lBTExPQ19CTE9DS1MobXApKSk7 Ci0JCXJldHVybigxKTsKLQl9Ci0KIAkvKgogCSAqIHNldCB1cCBmaXJzdCBpcmVj CiAJICovCiAJaW5vX3JlYyA9IGZpcnN0X2lyZWM7CisKKwlicGxpc3QgPSBtYWxs b2MoY2x1c3Rlcl9jb3VudCAqIHNpemVvZih4ZnNfYnVmX3QgKikpOworCWlmIChi cGxpc3QgPT0gTlVMTCkKKwkJZG9fZXJyb3IoXygiZmFpbGVkIHRvIGFsbG9jYXRl ICVkIGJ5dGVzIG9mIG1lbW9yeVxuIiksCisJCQljbHVzdGVyX2NvdW50ICogc2l6 ZW9mKHhmc19idWZfdCopKTsKKworCWZvciAoYnBfaW5kZXggPSAwOyBicF9pbmRl eCA8IGNsdXN0ZXJfY291bnQ7IGJwX2luZGV4KyspIHsKKyNpZmRlZiBYUl9QRl9U UkFDRQorCQlwZnRyYWNlKCJhYm91dCB0byByZWFkIG9mZiAlbGx1IGluIEFHICVk IiwKKwkJCShsb25nIGxvbmcpWEZTX0FHQl9UT19EQUREUihtcCwgYWdubywgYWdi bm8pLCBhZ25vKTsKKyNlbmRpZgorCQlicGxpc3RbYnBfaW5kZXhdID0gbGlieGZz X3JlYWRidWYobXAtPm1fZGV2LAorCQkJCQlYRlNfQUdCX1RPX0RBRERSKG1wLCBh Z25vLCBhZ2JubyksCisJCQkJCVhGU19GU0JfVE9fQkIobXAsIGJsa3NfcGVyX2Ns dXN0ZXIpLCAwKTsKKwkJaWYgKCFicGxpc3RbYnBfaW5kZXhdKSB7CisJCQlkb193 YXJuKF8oImNhbm5vdCByZWFkIGlub2RlICVsbHUsIGRpc2sgYmxvY2sgJWxsZCwg Y250ICVkXG4iKSwKKwkJCQlYRlNfQUdJTk9fVE9fSU5PKG1wLCBhZ25vLCBmaXJz dF9pcmVjLT5pbm9fc3RhcnRudW0pLAorCQkJCVhGU19BR0JfVE9fREFERFIobXAs IGFnbm8sIGFnYm5vKSwKKwkJCQkoaW50KVhGU19GU0JfVE9fQkIobXAsIGJsa3Nf cGVyX2NsdXN0ZXIpKTsKKwkJCXdoaWxlIChicF9pbmRleCA+IDApIHsKKwkJCQli cF9pbmRleC0tOworCQkJCWxpYnhmc19wdXRidWYoYnBsaXN0W2JwX2luZGV4XSk7 CisJCQl9CisJCQlmcmVlKGJwbGlzdCk7CisJCQlyZXR1cm4oMSk7CisJCX0KKwkJ YWdibm8gKz0gYmxrc19wZXJfY2x1c3RlcjsKKworI2lmZGVmIFhSX1BGX1RSQUNF CisJCXBmdHJhY2UoInJlYWRidWYgJXAgKCVsbHUsICVkKSBpbiBBRyAlZCIsIGJw bGlzdFticF9pbmRleF0sCisJCQkobG9uZyBsb25nKVhGU19CVUZfQUREUihicGxp c3RbYnBfaW5kZXhdKSwKKwkJCVhGU19CVUZfQ09VTlQoYnBsaXN0W2JwX2luZGV4 XSksIGFnbm8pOworI2VuZGlmCisJfQorCWFnYm5vID0gWEZTX0FHSU5PX1RPX0FH Qk5PKG1wLCBmaXJzdF9pcmVjLT5pbm9fc3RhcnRudW0pOworCiAJLyoKIAkgKiBp bml0aWFsaXplIGNvdW50ZXJzCiAJICovCiAJaXJlY19vZmZzZXQgPSAwOwogCWli dWZfb2Zmc2V0ID0gMDsKKwljbHVzdGVyX29mZnNldCA9IDA7CiAJaWNudCA9IDA7 CiAJc3RhdHVzID0gMDsKLQlkb25lID0gMDsKKwlicF9pbmRleCA9IDA7CiAKIAkv KgogCSAqIHZlcmlmeSBpbm9kZSBjaHVuayBpZiBuZWNlc3NhcnkKIAkgKi8KIAlp ZiAoaW5vX2Rpc2NvdmVyeSkgIHsKLQkJd2hpbGUgKCFkb25lKSAgeworCQlmb3Ig KDs7KSAgewogCQkJLyoKIAkJCSAqIG1ha2UgaW5vZGUgcG9pbnRlcgogCQkJICov Ci0JCQlkaW5vID0gWEZTX01BS0VfSVBUUihtcCwgYnAsIGljbnQpOworCQkJZGlu byA9IFhGU19NQUtFX0lQVFIobXAsIGJwbGlzdFticF9pbmRleF0sIGNsdXN0ZXJf b2Zmc2V0KTsKIAkJCWFnaW5vID0gaXJlY19vZmZzZXQgKyBpbm9fcmVjLT5pbm9f c3RhcnRudW07CiAKIAkJCS8qCkBAIC02NTEsNiArNjk0LDcgQEAKIAogCQkJaXJl Y19vZmZzZXQrKzsKIAkJCWljbnQrKzsKKwkJCWNsdXN0ZXJfb2Zmc2V0Kys7CiAK IAkJCWlmIChpY250ID09IFhGU19JQUxMT0NfSU5PREVTKG1wKSAmJgogCQkJCQlp cmVjX29mZnNldCA9PSBYRlNfSU5PREVTX1BFUl9DSFVOSykgIHsKQEAgLTY1OCw4 ICs3MDIsNiBAQAogCQkJCSAqIGRvbmUhIC0gZmluaXNoZWQgdXAgaXJlYyBhbmQg YmxvY2sKIAkJCQkgKiBzaW11bHRhbmVvdXNseQogCQkJCSAqLwotCQkJCWxpYnhm c19wdXRidWYoYnApOwotCQkJCWRvbmUgPSAxOwogCQkJCWJyZWFrOwogCQkJfSBl bHNlIGlmIChpcmVjX29mZnNldCA9PSBYRlNfSU5PREVTX1BFUl9DSFVOSykgIHsK IAkJCQkvKgpAQCAtNjY5LDYgKzcxMSwxMCBAQAogCQkJCUFTU0VSVChpbm9fcmVj LT5pbm9fc3RhcnRudW0gPT0gYWdpbm8gKyAxKTsKIAkJCQlpcmVjX29mZnNldCA9 IDA7CiAJCQl9CisJCQlpZiAoY2x1c3Rlcl9vZmZzZXQgPT0gaW5vZGVzX3Blcl9j bHVzdGVyKSB7CisJCQkJYnBfaW5kZXgrKzsKKwkJCQljbHVzdGVyX29mZnNldCA9 IDA7CisJCQl9CiAJCX0KIAogCQkvKgpAQCAtNjc3LDggKzcyMyw5IEBACiAJCSAq LwogCQlpZiAoIXN0YXR1cykgIHsKIAkJCSpib2d1cyA9IDE7Ci0JCQlpZiAoIWRv bmUpIC8qIGFscmVhZHkgZnJlZSdkICovCi0JCQkgIGxpYnhmc19wdXRidWYoYnAp OworCQkJZm9yIChicF9pbmRleCA9IDA7IGJwX2luZGV4IDwgY2x1c3Rlcl9jb3Vu dDsgYnBfaW5kZXgrKykKKwkJCQlsaWJ4ZnNfcHV0YnVmKGJwbGlzdFticF9pbmRl eF0pOworCQkJZnJlZShicGxpc3QpOwogCQkJcmV0dXJuKDApOwogCQl9CiAKQEAg LTY4OCw1NiArNzM1LDQwIEBACiAJCWlub19yZWMgPSBmaXJzdF9pcmVjOwogCiAJ CWlyZWNfb2Zmc2V0ID0gMDsKLQkJaWJ1Zl9vZmZzZXQgPSAwOworCQljbHVzdGVy X29mZnNldCA9IDA7CisJCWJwX2luZGV4ID0gMDsKIAkJaWNudCA9IDA7CiAJCXN0 YXR1cyA9IDA7Ci0JCWRvbmUgPSAwOwotCi0JCS8qIG5hdGhhbnMgVE9ETyAuLi4g bWVtb3J5IGxlYWsgaGVyZT86ICovCi0KLQkJLyoKLQkJICogZ2V0IGZpcnN0IGJs b2NrCi0JCSAqLwotCQlicCA9IGxpYnhmc19yZWFkYnVmKG1wLT5tX2RldiwKLQkJ CQlYRlNfQUdCX1RPX0RBRERSKG1wLCBhZ25vLCBhZ2JubyksCi0JCQkJWEZTX0ZT Ql9UT19CQihtcCwgWEZTX0lBTExPQ19CTE9DS1MobXApKSwgMCk7Ci0JCWlmICgh YnApIHsKLQkJCWRvX3dhcm4oXygiY2FuJ3QgcmVhZCBpbm9kZSAlbGx1LCBkaXNr IGJsb2NrICVsbGQsICIKLQkJCQkiY250ICVkXG4iKSwgWEZTX0FHSU5PX1RPX0lO TyhtcCwgYWdubywgYWdpbm8pLAotCQkJCVhGU19BR0JfVE9fREFERFIobXAsIGFn bm8sIGFnYm5vKSwKLQkJCQkoaW50KVhGU19GU0JfVE9fQkIobXAsIFhGU19JQUxM T0NfQkxPQ0tTKG1wKSkpOwotCQkJcmV0dXJuKDEpOwotCQl9CiAJfQogCiAJLyoK IAkgKiBtYXJrIGJsb2NrIGFzIGFuIGlub2RlIGJsb2NrIGluIHRoZSBpbmNvcmUg Yml0bWFwCiAJICovCi0JUFJFUEFJUl9SV19XUklURV9MT0NLKCZwZXJfYWdfbG9j a1thZ25vXSk7CisJcHRocmVhZF9tdXRleF9sb2NrKCZhZ19sb2Nrc1thZ25vXSk7 CiAJc3dpdGNoIChzdGF0ZSA9IGdldF9hZ2Jub19zdGF0ZShtcCwgYWdubywgYWdi bm8pKSAgewotCWNhc2UgWFJfRV9JTk86CS8qIGFscmVhZHkgbWFya2VkICovCi0J CWJyZWFrOwotCWNhc2UgWFJfRV9VTktOT1dOOgotCWNhc2UgWFJfRV9GUkVFOgot CWNhc2UgWFJfRV9GUkVFMToKLQkJc2V0X2FnYm5vX3N0YXRlKG1wLCBhZ25vLCBh Z2JubywgWFJfRV9JTk8pOwotCQlicmVhazsKLQljYXNlIFhSX0VfQkFEX1NUQVRF OgotCQlkb19lcnJvcihfKCJiYWQgc3RhdGUgaW4gYmxvY2sgbWFwICVkXG4iKSwg c3RhdGUpOwotCQlicmVhazsKLQlkZWZhdWx0OgotCQlzZXRfYWdibm9fc3RhdGUo bXAsIGFnbm8sIGFnYm5vLCBYUl9FX01VTFQpOwotCQlkb193YXJuKF8oImlub2Rl IGJsb2NrICVsbHUgbXVsdGlwbHkgY2xhaW1lZCwgc3RhdGUgd2FzICVkXG4iKSwK LQkJCVhGU19BR0JfVE9fRlNCKG1wLCBhZ25vLCBhZ2JubyksIHN0YXRlKTsKLQkJ YnJlYWs7CisJCWNhc2UgWFJfRV9JTk86CS8qIGFscmVhZHkgbWFya2VkICovCisJ CQlicmVhazsKKwkJY2FzZSBYUl9FX1VOS05PV046CisJCWNhc2UgWFJfRV9GUkVF OgorCQljYXNlIFhSX0VfRlJFRTE6CisJCQlzZXRfYWdibm9fc3RhdGUobXAsIGFn bm8sIGFnYm5vLCBYUl9FX0lOTyk7CisJCQlicmVhazsKKwkJY2FzZSBYUl9FX0JB RF9TVEFURToKKwkJCWRvX2Vycm9yKF8oImJhZCBzdGF0ZSBpbiBibG9jayBtYXAg JWRcbiIpLCBzdGF0ZSk7CisJCQlicmVhazsKKwkJZGVmYXVsdDoKKwkJCXNldF9h Z2Jub19zdGF0ZShtcCwgYWdubywgYWdibm8sIFhSX0VfTVVMVCk7CisJCQlkb193 YXJuKF8oImlub2RlIGJsb2NrICVsbHUgbXVsdGlwbHkgY2xhaW1lZCwgc3RhdGUg d2FzICVkXG4iKSwKKwkJCQlYRlNfQUdCX1RPX0ZTQihtcCwgYWdubywgYWdibm8p LCBzdGF0ZSk7CisJCQlicmVhazsKIAl9Ci0JUFJFUEFJUl9SV19VTkxPQ0soJnBl cl9hZ19sb2NrW2Fnbm9dKTsKKwlwdGhyZWFkX211dGV4X3VubG9jaygmYWdfbG9j a3NbYWdub10pOwogCi0Jd2hpbGUgKCFkb25lKSAgeworCWZvciAoOzspIHsKIAkJ LyoKIAkJICogbWFrZSBpbm9kZSBwb2ludGVyCiAJCSAqLwotCQlkaW5vID0gWEZT X01BS0VfSVBUUihtcCwgYnAsIGljbnQpOworCQlkaW5vID0gWEZTX01BS0VfSVBU UihtcCwgYnBsaXN0W2JwX2luZGV4XSwgY2x1c3Rlcl9vZmZzZXQpOwogCQlhZ2lu byA9IGlyZWNfb2Zmc2V0ICsgaW5vX3JlYy0+aW5vX3N0YXJ0bnVtOwogCiAJCWlz X3VzZWQgPSAzOwpAQCAtODY4LDE4ICs4OTksMjQgQEAKIAkJaXJlY19vZmZzZXQr KzsKIAkJaWJ1Zl9vZmZzZXQrKzsKIAkJaWNudCsrOworCQljbHVzdGVyX29mZnNl dCsrOwogCiAJCWlmIChpY250ID09IFhGU19JQUxMT0NfSU5PREVTKG1wKSAmJgog CQkJCWlyZWNfb2Zmc2V0ID09IFhGU19JTk9ERVNfUEVSX0NIVU5LKSAgewogCQkJ LyoKIAkJCSAqIGRvbmUhIC0gZmluaXNoZWQgdXAgaXJlYyBhbmQgYmxvY2sgc2lt dWx0YW5lb3VzbHkKIAkJCSAqLwotCQkJaWYgKGRpcnR5ICYmICFub19tb2RpZnkp Ci0JCQkJbGlieGZzX3dyaXRlYnVmKGJwLCAwKTsKLQkJCWVsc2UKLQkJCQlsaWJ4 ZnNfcHV0YnVmKGJwKTsKLQotCQkJZG9uZSA9IDE7CisJCQlmb3IgKGJwX2luZGV4 ID0gMDsgYnBfaW5kZXggPCBjbHVzdGVyX2NvdW50OyBicF9pbmRleCsrKSB7Cisj aWZkZWYgWFJfUEZfVFJBQ0UKKwkJCQlwZnRyYWNlKCJwdXQvd3JpdGVidWYgJXAg KCVsbHUpIGluIEFHICVkIiwgYnBsaXN0W2JwX2luZGV4XSwKKwkJCQkJKGxvbmcg bG9uZylYRlNfQlVGX0FERFIoYnBsaXN0W2JwX2luZGV4XSksIGFnbm8pOworI2Vu ZGlmCisJCQkJaWYgKGRpcnR5ICYmICFub19tb2RpZnkpCisJCQkJCWxpYnhmc193 cml0ZWJ1ZihicGxpc3RbYnBfaW5kZXhdLCAwKTsKKwkJCQllbHNlCisJCQkJCWxp Ynhmc19wdXRidWYoYnBsaXN0W2JwX2luZGV4XSk7CisJCQl9CisJCQlmcmVlKGJw bGlzdCk7CiAJCQlicmVhazsKIAkJfSBlbHNlIGlmIChpYnVmX29mZnNldCA9PSBt cC0+bV9zYi5zYl9pbm9wYmxvY2spICB7CiAJCQkvKgpAQCAtODg5LDcgKzkyNiw3 IEBACiAJCQlpYnVmX29mZnNldCA9IDA7CiAJCQlhZ2JubysrOwogCi0JCQlQUkVQ QUlSX1JXX1dSSVRFX0xPQ0soJnBlcl9hZ19sb2NrW2Fnbm9dKTsKKwkJCXB0aHJl YWRfbXV0ZXhfbG9jaygmYWdfbG9ja3NbYWdub10pOwogCQkJc3dpdGNoIChzdGF0 ZSA9IGdldF9hZ2Jub19zdGF0ZShtcCwgYWdubywgYWdibm8pKSAgewogCQkJY2Fz ZSBYUl9FX0lOTzoJLyogYWxyZWFkeSBtYXJrZWQgKi8KIAkJCQlicmVhazsKQEAg LTkwOSw3ICs5NDYsNyBAQAogCQkJCQlYRlNfQUdCX1RPX0ZTQihtcCwgYWdubywg YWdibm8pLCBzdGF0ZSk7CiAJCQkJYnJlYWs7CiAJCQl9Ci0JCQlQUkVQQUlSX1JX X1VOTE9DSygmcGVyX2FnX2xvY2tbYWdub10pOworCQkJcHRocmVhZF9tdXRleF91 bmxvY2soJmFnX2xvY2tzW2Fnbm9dKTsKIAogCQl9IGVsc2UgaWYgKGlyZWNfb2Zm c2V0ID09IFhGU19JTk9ERVNfUEVSX0NIVU5LKSAgewogCQkJLyoKQEAgLTkxOSw2 ICs5NTYsMTAgQEAKIAkJCUFTU0VSVChpbm9fcmVjLT5pbm9fc3RhcnRudW0gPT0g YWdpbm8gKyAxKTsKIAkJCWlyZWNfb2Zmc2V0ID0gMDsKIAkJfQorCQlpZiAoY2x1 c3Rlcl9vZmZzZXQgPT0gaW5vZGVzX3Blcl9jbHVzdGVyKSB7CisJCQlicF9pbmRl eCsrOworCQkJY2x1c3Rlcl9vZmZzZXQgPSAwOworCQl9CiAJfQogCXJldHVybigw KTsKIH0KQEAgLTkzNiwxNiArOTc3LDIxIEBACiAgKiBwaGFzZSA0IGFmdGVyIHdl J3ZlIHJ1biB0aHJvdWdoIGFuZCBzZXQgdGhlIGJpdG1hcCBvbmNlLgogICovCiB2 b2lkCi1wcm9jZXNzX2FnaW5vZGVzKHhmc19tb3VudF90ICptcCwgeGZzX2FnbnVt YmVyX3QgYWdubywKLQkJaW50IGlub19kaXNjb3ZlcnksIGludCBjaGVja19kdXBz LCBpbnQgZXh0cmFfYXR0cl9jaGVjaykKK3Byb2Nlc3NfYWdpbm9kZXMoCisJeGZz X21vdW50X3QJCSptcCwKKwlwcmVmZXRjaF9hcmdzX3QJCSpwZl9hcmdzLAorCXhm c19hZ251bWJlcl90CQlhZ25vLAorCWludCAJCQlpbm9fZGlzY292ZXJ5LAorCWlu dCAJCQljaGVja19kdXBzLAorCWludCAJCQlleHRyYV9hdHRyX2NoZWNrKQogewot CWludCBudW1faW5vcywgYm9ndXM7Ci0JaW5vX3RyZWVfbm9kZV90ICppbm9fcmVj LCAqZmlyc3RfaW5vX3JlYywgKnByZXZfaW5vX3JlYzsKLQlpbm9fdHJlZV9ub2Rl X3QgKmlub19yYTsKLQotCWlub19yYSA9IGRvX3ByZWZldGNoID8gcHJlZmV0Y2hf aW5vZGVfY2h1bmtzKG1wLCBhZ25vLCBOVUxMKSA6IE5VTEw7Ci0KKwlpbnQgCQkJ bnVtX2lub3MsIGJvZ3VzOworCWlub190cmVlX25vZGVfdCAJKmlub19yZWMsICpm aXJzdF9pbm9fcmVjLCAqcHJldl9pbm9fcmVjOworI2lmZGVmIFhSX1BGX1RSQUNF CisJaW50CQkJY291bnQ7CisjZW5kaWYKIAlmaXJzdF9pbm9fcmVjID0gaW5vX3Jl YyA9IGZpbmRmaXJzdF9pbm9kZV9yZWMoYWdubyk7CisKIAl3aGlsZSAoaW5vX3Jl YyAhPSBOVUxMKSAgewogCQkvKgogCQkgKiBwYXJhbm9pYSAtIHN0ZXAgdGhyb3Vn aCBpbm9kZSByZWNvcmRzIHVudGlsIHdlIHN0ZXAKQEAgLTk1Nyw3ICsxMDAzLDYg QEAKIAkJICovCiAJCW51bV9pbm9zID0gWEZTX0lOT0RFU19QRVJfQ0hVTks7CiAJ CXdoaWxlIChudW1faW5vcyA8IFhGU19JQUxMT0NfSU5PREVTKG1wKSAmJiBpbm9f cmVjICE9IE5VTEwpICB7Ci0JCQlBU1NFUlQoaW5vX3JlYyAhPSBOVUxMKTsKIAkJ CS8qCiAJCQkgKiBpbm9kZXMgY2h1bmtzIHdpbGwgYWx3YXlzIGJlIGFsaWduZWQg YW5kIHNpemVkCiAJCQkgKiBjb3JyZWN0bHkKQEAgLTk2OCwxMSArMTAxMywxOCBA QAogCiAJCUFTU0VSVChudW1faW5vcyA9PSBYRlNfSUFMTE9DX0lOT0RFUyhtcCkp OwogCi0JCWlmIChkb19wcmVmZXRjaCAmJiBpbm9fcmEgJiYgKGZpcnN0X2lub19y ZWMtPmlub19zdGFydG51bSA+PSBpbm9fcmEtPmlub19zdGFydG51bSkpCi0JCQlp bm9fcmEgPSBwcmVmZXRjaF9pbm9kZV9jaHVua3MobXAsIGFnbm8sIGlub19yYSk7 CisJCWlmIChwZl9hcmdzKSB7CisJCQlzZW1fcG9zdCgmcGZfYXJncy0+cmFfY291 bnQpOworI2lmZGVmIFhSX1BGX1RSQUNFCisJCQlzZW1fZ2V0dmFsdWUoJnBmX2Fy Z3MtPnJhX2NvdW50LCAmY291bnQpOworCQkJcGZ0cmFjZSgicHJvY2Vzc2luZyBp bm9kZSBjaHVuayAlcCBpbiBBRyAlZCAoc2VtIGNvdW50ID0gJWQpIiwKKwkJCQlm aXJzdF9pbm9fcmVjLCBhZ25vLCBjb3VudCk7CisjZW5kaWYKKwkJfQogCiAJCWlm IChwcm9jZXNzX2lub2RlX2NodW5rKG1wLCBhZ25vLCBudW1faW5vcywgZmlyc3Rf aW5vX3JlYywKLQkJCQlpbm9fZGlzY292ZXJ5LCBjaGVja19kdXBzLCBleHRyYV9h dHRyX2NoZWNrLCAmYm9ndXMpKSAgeworCQkJCWlub19kaXNjb3ZlcnksIGNoZWNr X2R1cHMsIGV4dHJhX2F0dHJfY2hlY2ssCisJCQkJJmJvZ3VzKSkgIHsKIAkJCS8q IFhYWCAtIGkvbyBlcnJvciwgd2UndmUgZ290IGEgcHJvYmxlbSAqLwogCQkJYWJv cnQoKTsKIAkJfQpJbmRleDogcmVwYWlyL3hmc3Byb2dzL3JlcGFpci9kaXIuYwo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIub3JpZy94ZnNwcm9ncy9yZXBh aXIvZGlyLmMJMjAwNy0wNC0yNyAxNDoxMTo0MS4wMDAwMDAwMDAgKzEwMDAKKysr IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvZGlyLmMJMjAwNy0wNC0yNyAxNDoxMjoz NC4xMzk1NzAyODkgKzEwMDAKQEAgLTI2LDcgKzI2LDYgQEAKICNpbmNsdWRlICJk aW5vZGUuaCIKICNpbmNsdWRlICJkaXIuaCIKICNpbmNsdWRlICJibWFwLmgiCi0j aW5jbHVkZSAicHJlZmV0Y2guaCIKIAogI2lmIFhGU19ESVJfTEVBRl9NQVBTSVpF ID49IFhGU19BVFRSX0xFQUZfTUFQU0laRQogI2RlZmluZSBYUl9EQV9MRUFGX01B UFNJWkUJWEZTX0RJUl9MRUFGX01BUFNJWkUKQEAgLTc4MSw5ICs3ODAsNiBAQAog CW5vZGUgPSBOVUxMOwogCWRhX2N1cnNvci0+YWN0aXZlID0gMDsKIAotCWlmIChk b19wcmVmZXRjaCAmJiAod2hpY2hmb3JrID09IFhGU19EQVRBX0ZPUkspKQotCQlw cmVmZXRjaF9kaXIxKG1wLCBibm8sIGRhX2N1cnNvcik7Ci0KIAlkbyB7CiAJCS8q CiAJCSAqIHJlYWQgaW4gZWFjaCBibG9jayBhbG9uZyB0aGUgd2F5IGFuZCBzZXQg dXAgY3Vyc29yCkluZGV4OiByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL2RpcjIuYwo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIub3JpZy94ZnNwcm9ncy9yZXBh aXIvZGlyMi5jCTIwMDctMDQtMjcgMTQ6MTE6NDEuMDAwMDAwMDAwICsxMDAwCisr KyByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL2RpcjIuYwkyMDA3LTA1LTI5IDExOjIy OjEyLjY4NDE2MDE1MSArMTAwMApAQCAtMjYsNiArMjYsNyBAQAogI2luY2x1ZGUg ImRpcjIuaCIKICNpbmNsdWRlICJibWFwLmgiCiAjaW5jbHVkZSAicHJlZmV0Y2gu aCIKKyNpbmNsdWRlICJwcm9ncmVzcy5oIgogCiAvKgogICogVGFnIGJhZCBkaXJl Y3RvcnkgZW50cmllcyB3aXRoIHRoaXMuCkBAIC04NywxMCArODgsMTkgQEAKIAl4 ZnNfYnVmX3QJKmJwYXJyYXlbNF07CiAJeGZzX2J1Zl90CSoqYnBsaXN0OwogCXhm c19kYWJ1Zl90CSpkYWJ1ZjsKLQlpbnQJCWk7CisJaW50CQlpLCBqOwogCWludAkJ b2ZmOworCWludAkJbmJsb2NrczsKKworCS8qCisJICogZHVlIHRvIGxpbWl0YXRp b25zIGluIGxpYnhmc19jYWNoZSwgd2UgbmVlZCB0byByZWFkIHRoZQorCSAqIGJs b2NrcyBpbiBmc2Jsb2NrIHNpemUgY2h1bmtzCisJICovCisKKwlmb3IgKGkgPSAw LCBuYmxvY2tzID0gMDsgaSA8IG5leDsgaSsrKQorCQluYmxvY2tzICs9IGJtcFtp XS5ibG9ja2NvdW50OwogCi0JaWYgKG5leCA+IChzaXplb2YoYnBhcnJheSkvc2l6 ZW9mKHhmc19idWZfdCAqKSkpIHsKKwlpZiAobmJsb2NrcyA+IChzaXplb2YoYnBh cnJheSkvc2l6ZW9mKHhmc19idWZfdCAqKSkpIHsKIAkJYnBsaXN0ID0gY2FsbG9j KG5leCwgc2l6ZW9mKCpicGxpc3QpKTsKIAkJaWYgKGJwbGlzdCA9PSBOVUxMKSB7 CiAJCQlkb19lcnJvcihfKCJjb3VsZG4ndCBtYWxsb2MgZGlyMiBidWZmZXIgbGlz dFxuIikpOwpAQCAtMTAxLDIxICsxMTEsMzkgQEAKIAkJLyogY29tbW9uIGNhc2Ug YXZvaWRzIGNhbGxvYy9mcmVlICovCiAJCWJwbGlzdCA9IGJwYXJyYXk7CiAJfQot CWZvciAoaSA9IDA7IGkgPCBuZXg7IGkrKykgewotCQlicGxpc3RbaV0gPSBsaWJ4 ZnNfcmVhZGJ1ZihtcC0+bV9kZXYsCi0JCQkJWEZTX0ZTQl9UT19EQUREUihtcCwg Ym1wW2ldLnN0YXJ0YmxvY2spLAotCQkJCVhGU19GU0JfVE9fQkIobXAsIGJtcFtp XS5ibG9ja2NvdW50KSwgMCk7Ci0JCWlmICghYnBsaXN0W2ldKQotCQkJZ290byBm YWlsZWQ7CisJZm9yIChpID0gMCwgaiA9IDA7IGogPCBuZXg7IGorKykgeworCQl4 ZnNfZGZzYm5vX3QJYm5vOworCQlpbnQJCWM7CisKKwkJYm5vID0gYm1wW2pdLnN0 YXJ0YmxvY2s7CisJCWZvciAoYyA9IDA7IGMgPCBibXBbal0uYmxvY2tjb3VudDsg YysrLCBibm8rKykgeworI2lmZGVmIFhSX1BGX1RSQUNFCisJCQlwZnRyYWNlKCJh Ym91dCB0byByZWFkIG9mZiAlbGx1IiwKKwkJCQkobG9uZyBsb25nKVhGU19GU0Jf VE9fREFERFIobXAsIGJubykpOworI2VuZGlmCisJCQlicGxpc3RbaV0gPSBsaWJ4 ZnNfcmVhZGJ1ZihtcC0+bV9kZXYsCisJCQkJCVhGU19GU0JfVE9fREFERFIobXAs IGJubyksCisJCQkJCVhGU19GU0JfVE9fQkIobXAsIDEpLCAwKTsKKwkJCWlmICgh YnBsaXN0W2ldKQorCQkJCWdvdG8gZmFpbGVkOworI2lmZGVmIFhSX1BGX1RSQUNF CisJCQlwZnRyYWNlKCJyZWFkYnVmICVwICglbGx1LCAlZCkiLCBicGxpc3RbaV0s CisJCQkJKGxvbmcgbG9uZylYRlNfQlVGX0FERFIoYnBsaXN0W2ldKSwKKwkJCQlY RlNfQlVGX0NPVU5UKGJwbGlzdFtpXSkpOworI2VuZGlmCisJCQlpKys7CisJCX0K IAl9Ci0JZGFidWYgPSBtYWxsb2MoWEZTX0RBX0JVRl9TSVpFKG5leCkpOworCUFT U0VSVChpID09IG5ibG9ja3MpOworCisJZGFidWYgPSBtYWxsb2MoWEZTX0RBX0JV Rl9TSVpFKG5ibG9ja3MpKTsKIAlpZiAoZGFidWYgPT0gTlVMTCkgewogCQlkb19l cnJvcihfKCJjb3VsZG4ndCBtYWxsb2MgZGlyMiBidWZmZXIgaGVhZGVyXG4iKSk7 CiAJCWV4aXQoMSk7CiAJfQogCWRhYnVmLT5kaXJ0eSA9IDA7CiAJZGFidWYtPm5i dWYgPSBuZXg7Ci0JaWYgKG5leCA9PSAxKSB7CisJaWYgKG5ibG9ja3MgPT0gMSkg ewogCQlicCA9IGJwbGlzdFswXTsKIAkJZGFidWYtPmJiY291bnQgPSAoc2hvcnQp QlRPQkIoWEZTX0JVRl9DT1VOVChicCkpOwogCQlkYWJ1Zi0+ZGF0YSA9IFhGU19C VUZfUFRSKGJwKTsKQEAgLTEzMCw3ICsxNTgsNyBAQAogCQkJZG9fZXJyb3IoXygi Y291bGRuJ3QgbWFsbG9jIGRpcjIgYnVmZmVyIGRhdGFcbiIpKTsKIAkJCWV4aXQo MSk7CiAJCX0KLQkJZm9yIChpID0gb2ZmID0gMDsgaSA8IG5leDsgaSsrLCBvZmYg Kz0gWEZTX0JVRl9DT1VOVChicCkpIHsKKwkJZm9yIChpID0gb2ZmID0gMDsgaSA8 IG5ibG9ja3M7IGkrKywgb2ZmICs9IFhGU19CVUZfQ09VTlQoYnApKSB7CiAJCQli cCA9IGJwbGlzdFtpXTsKIAkJCWJjb3B5KFhGU19CVUZfUFRSKGJwKSwgKGNoYXIg KilkYWJ1Zi0+ZGF0YSArIG9mZiwKIAkJCQlYRlNfQlVGX0NPVU5UKGJwKSk7CkBA IC0xNDAsNyArMTY4LDcgQEAKIAkJZnJlZShicGxpc3QpOwogCXJldHVybiBkYWJ1 ZjsKIGZhaWxlZDoKLQlmb3IgKGkgPSAwOyBpIDwgbmV4OyBpKyspCisJZm9yIChp ID0gMDsgaSA8IG5ibG9ja3M7IGkrKykKIAkJbGlieGZzX3B1dGJ1ZihicGxpc3Rb aV0pOwogCWlmIChicGxpc3QgIT0gYnBhcnJheSkKIAkJZnJlZShicGxpc3QpOwpA QCAtMjM2LDggKzI2NCwxMiBAQAogCQliY29weShkYWJ1Zi0+YnBzLCBicGxpc3Qs IG5idWYgKiBzaXplb2YoKmJwbGlzdCkpOwogCX0KIAlkYV9idWZfZG9uZShkYWJ1 Zik7Ci0JZm9yIChpID0gMDsgaSA8IG5idWY7IGkrKykKKwlmb3IgKGkgPSAwOyBp IDwgbmJ1ZjsgaSsrKSB7CisjaWZkZWYgWFJfUEZfVFJBQ0UKKwkJcGZ0cmFjZSgi cHV0YnVmICVwICglbGx1KSIsIGJwbGlzdFtpXSwgKGxvbmcgbG9uZylYRlNfQlVG X0FERFIoYnBsaXN0W2ldKSk7CisjZW5kaWYKIAkJbGlieGZzX3B1dGJ1ZihicGxp c3RbaV0pOworCX0KIAlpZiAoYnBsaXN0ICE9ICZicCkKIAkJZnJlZShicGxpc3Qp OwogfQpAQCAtODUzLDcgKzg4NSw3IEBACiAKIAlzZnAgPSAmZGlwLT5kaV91LmRp X2RpcjJzZjsKIAltYXhfc2l6ZSA9IFhGU19ERk9SS19EU0laRShkaXAsIG1wKTsK LQludW1fZW50cmllcyA9IElOVF9HRVQoc2ZwLT5oZHIuY291bnQsIEFSQ0hfQ09O VkVSVCk7CisJbnVtX2VudHJpZXMgPSBzZnAtPmhkci5jb3VudDsKIAlpbm9fZGly X3NpemUgPSBJTlRfR0VUKGRpcC0+ZGlfY29yZS5kaV9zaXplLCBBUkNIX0NPTlZF UlQpOwogCW9mZnNldCA9IFhGU19ESVIyX0RBVEFfRklSU1RfT0ZGU0VUOwogCWJh ZF9vZmZzZXQgPSAqcmVwYWlyID0gMDsKQEAgLTE5ODYsOSArMjAxOCw2IEBACiAJ aW50CQkJdDsKIAlibWFwX2V4dF90CQlsYm1wOwogCi0JaWYgKGRvX3ByZWZldGNo KQotCQlwcmVmZXRjaF9kaXIyKG1wLCBibGttYXApOwotCiAJKnJlcGFpciA9ICpk b3QgPSAqZG90ZG90ID0gZ29vZCA9IDA7CiAJKnBhcmVudCA9IE5VTExGU0lOTzsK IAluZGJubyA9IE5VTExERklMT0ZGOwpJbmRleDogcmVwYWlyL3hmc3Byb2dzL3Jl cGFpci9kaXJfc3RhY2suYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIu b3JpZy94ZnNwcm9ncy9yZXBhaXIvZGlyX3N0YWNrLmMJMjAwNy0wNC0yNyAxMzox MzozNS4wMDAwMDAwMDAgKzEwMDAKKysrIC9kZXYvbnVsbAkxOTcwLTAxLTAxIDAw OjAwOjAwLjAwMDAwMDAwMCArMDAwMApAQCAtMSwxMzYgKzAsMCBAQAotLyoKLSAq IENvcHlyaWdodCAoYykgMjAwMC0yMDAxLDIwMDUgU2lsaWNvbiBHcmFwaGljcywg SW5jLgotICogQWxsIFJpZ2h0cyBSZXNlcnZlZC4KLSAqCi0gKiBUaGlzIHByb2dy YW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5k L29yCi0gKiBtb2RpZnkgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2Vu ZXJhbCBQdWJsaWMgTGljZW5zZSBhcwotICogcHVibGlzaGVkIGJ5IHRoZSBGcmVl IFNvZnR3YXJlIEZvdW5kYXRpb24uCi0gKgotICogVGhpcyBwcm9ncmFtIGlzIGRp c3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd291bGQgYmUgdXNlZnVsLAot ICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGlt cGxpZWQgd2FycmFudHkgb2YKLSAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNT IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKLSAqIEdOVSBHZW5l cmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCi0gKgotICogWW91 IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwg UHVibGljIExpY2Vuc2UKLSAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBu b3QsIHdyaXRlIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sCi0gKiBJbmMu LCAgNTEgRnJhbmtsaW4gU3QsIEZpZnRoIEZsb29yLCBCb3N0b24sIE1BICAwMjEx MC0xMzAxICBVU0EKLSAqLwotCi0jaW5jbHVkZSA8bGlieGZzLmg+Ci0jaW5jbHVk ZSAiZGlyX3N0YWNrLmgiCi0jaW5jbHVkZSAiZXJyX3Byb3Rvcy5oIgotI2luY2x1 ZGUgInRocmVhZHMuaCIKLQotLyoKLSAqIGEgZGlyZWN0b3J5IHN0YWNrIGZvciBo b2xkaW5nIGRpcmVjdG9yaWVzIHdoaWxlCi0gKiB3ZSB0cmF2ZXJzZSBmaWxlc3lz dGVtIGhpZXJhcmNoeSBzdWJ0cmVlcy4KLSAqIG5hbWVzIGFyZSBraW5kIG9mIG1p c2xlYWRpbmcgYXMgdGhpcyBpcyByZWFsbHkKLSAqIGltcGxlbWVudGVkIGFzIGFu IGlub2RlIHN0YWNrLiAgc28gc3VlIG1lLi4uCi0gKi8KLQotc3RhdGljIGRpcl9z dGFja190CWRpcnN0YWNrX2ZyZWVsaXN0Owotc3RhdGljIGludAkJZGlyc3RhY2tf aW5pdCA9IDA7Ci1zdGF0aWMgcHRocmVhZF9tdXRleF90CWRpcnN0YWNrX211dGV4 Owotc3RhdGljIHB0aHJlYWRfbXV0ZXhhdHRyX3QgZGlyc3RhY2tfbXV0ZXhhdHRy OwotCi0KLXZvaWQKLWRpcl9zdGFja19pbml0KGRpcl9zdGFja190ICpzdGFjaykK LXsKLQlzdGFjay0+Y250ID0gMDsKLQlzdGFjay0+aGVhZCA9IE5VTEw7Ci0KLQlp ZiAoZGlyc3RhY2tfaW5pdCA9PSAwKSAgewotCQlkaXJzdGFja19pbml0ID0gMTsK LQkJUFJFUEFJUl9NVFhfQVRUUl9JTklUKCZkaXJzdGFja19tdXRleGF0dHIpOwot I2lmZGVmIFBUSFJFQURfTVVURVhfU1BJTkJMT0NLX05QCi0JCVBSRVBBSVJfTVRY X0FUVFJfU0VUKCZkaXJzdGFja19tdXRleGF0dHIsIFBUSFJFQURfTVVURVhfU1BJ TkJMT0NLX05QKTsKLSNlbmRpZgotCQlQUkVQQUlSX01UWF9MT0NLX0lOSVQoJmRp cnN0YWNrX211dGV4LCAmZGlyc3RhY2tfbXV0ZXhhdHRyKTsKLQkJZGlyX3N0YWNr X2luaXQoJmRpcnN0YWNrX2ZyZWVsaXN0KTsKLQl9Ci0KLQlzdGFjay0+Y250ID0g MDsKLQlzdGFjay0+aGVhZCA9IE5VTEw7Ci0KLQlyZXR1cm47Ci19Ci0KLXN0YXRp YyB2b2lkCi1kaXJfc3RhY2tfcHVzaChkaXJfc3RhY2tfdCAqc3RhY2ssIGRpcl9z dGFja19lbGVtX3QgKmVsZW0pCi17Ci0JQVNTRVJUKHN0YWNrLT5jbnQgPiAwIHx8 IChzdGFjay0+Y250ID09IDAgJiYgc3RhY2stPmhlYWQgPT0gTlVMTCkpOwotCi0J ZWxlbS0+bmV4dCA9IHN0YWNrLT5oZWFkOwotCXN0YWNrLT5oZWFkID0gZWxlbTsK LQlzdGFjay0+Y250Kys7Ci0KLQlyZXR1cm47Ci19Ci0KLXN0YXRpYyBkaXJfc3Rh Y2tfZWxlbV90ICoKLWRpcl9zdGFja19wb3AoZGlyX3N0YWNrX3QgKnN0YWNrKQot ewotCWRpcl9zdGFja19lbGVtX3QgKmVsZW07Ci0KLQlpZiAoc3RhY2stPmNudCA9 PSAwKSAgewotCQlBU1NFUlQoc3RhY2stPmhlYWQgPT0gTlVMTCk7Ci0JCXJldHVy bihOVUxMKTsKLQl9Ci0KLQllbGVtID0gc3RhY2stPmhlYWQ7Ci0KLQlBU1NFUlQo ZWxlbSAhPSBOVUxMKTsKLQotCXN0YWNrLT5oZWFkID0gZWxlbS0+bmV4dDsKLQll bGVtLT5uZXh0ID0gTlVMTDsKLQlzdGFjay0+Y250LS07Ci0KLQlyZXR1cm4oZWxl bSk7Ci19Ci0KLXZvaWQKLXB1c2hfZGlyKGRpcl9zdGFja190ICpzdGFjaywgeGZz X2lub190IGlubykKLXsKLQlkaXJfc3RhY2tfZWxlbV90ICplbGVtOwotCi0JUFJF UEFJUl9NVFhfTE9DSygmZGlyc3RhY2tfbXV0ZXgpOwotCWlmIChkaXJzdGFja19m cmVlbGlzdC5jbnQgPT0gMCkgIHsKLQkJaWYgKChlbGVtID0gbWFsbG9jKHNpemVv ZihkaXJfc3RhY2tfZWxlbV90KSkpID09IE5VTEwpICB7Ci0JCQlQUkVQQUlSX01U WF9VTkxPQ0soJmRpcnN0YWNrX211dGV4KTsKLQkJCWRvX2Vycm9yKAotCQlfKCJj b3VsZG4ndCBtYWxsb2MgZGlyIHN0YWNrIGVsZW1lbnQsIHRyeSBtb3JlIHN3YXBc biIpKTsKLQkJCWV4aXQoMSk7Ci0JCX0KLQl9IGVsc2UgIHsKLQkJZWxlbSA9IGRp cl9zdGFja19wb3AoJmRpcnN0YWNrX2ZyZWVsaXN0KTsKLQl9Ci0JUFJFUEFJUl9N VFhfVU5MT0NLKCZkaXJzdGFja19tdXRleCk7Ci0KLQllbGVtLT5pbm8gPSBpbm87 Ci0KLQlkaXJfc3RhY2tfcHVzaChzdGFjaywgZWxlbSk7Ci0KLQlyZXR1cm47Ci19 Ci0KLXhmc19pbm9fdAotcG9wX2RpcihkaXJfc3RhY2tfdCAqc3RhY2spCi17Ci0J ZGlyX3N0YWNrX2VsZW1fdCAqZWxlbTsKLQl4ZnNfaW5vX3QgaW5vOwotCi0JZWxl bSA9IGRpcl9zdGFja19wb3Aoc3RhY2spOwotCi0JaWYgKGVsZW0gPT0gTlVMTCkK LQkJcmV0dXJuKE5VTExGU0lOTyk7Ci0KLQlpbm8gPSBlbGVtLT5pbm87Ci0JZWxl bS0+aW5vID0gTlVMTEZTSU5POwotCi0JUFJFUEFJUl9NVFhfTE9DSygmZGlyc3Rh Y2tfbXV0ZXgpOwotCWRpcl9zdGFja19wdXNoKCZkaXJzdGFja19mcmVlbGlzdCwg ZWxlbSk7Ci0JUFJFUEFJUl9NVFhfVU5MT0NLKCZkaXJzdGFja19tdXRleCk7Ci0K LQlyZXR1cm4oaW5vKTsKLX0KSW5kZXg6IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIv Z2xvYmFscy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHJlcGFpci5vcmlnL3hm c3Byb2dzL3JlcGFpci9nbG9iYWxzLmgJMjAwNy0wNC0yNyAxNDoxMTo0MS4wMDAw MDAwMDAgKzEwMDAKKysrIHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvZ2xvYmFscy5o CTIwMDctMDYtMDQgMTc6MjI6NTkuMTA0NDA0ODgzICsxMDAwCkBAIC0yMyw4ICsy Myw2IEBACiAjZGVmaW5lIEVYVEVSTiBleHRlcm4KICNlbmRpZgogCi0jZGVmaW5l IFRSQUNLX01FTU9SWQotCiAjaWZkZWYgVFJBQ0tfTUVNT1JZCiAjaW5jbHVkZSAi dHJhY2ttZW0uaCIKICNlbmRpZgpAQCAtMTU0LDcgKzE1Miw3IEBACiAvKiBjb25m aWd1cmF0aW9uIHZhcnMgLS0gZnMgZ2VvbWV0cnkgZGVwZW5kZW50ICovCiAKIEVY VEVSTiBpbnQJCWlub2Rlc19wZXJfYmxvY2s7Ci1FWFRFUk4gaW50CQlpbm9kZXNf cGVyX2NsdXN0ZXI7CS8qIGlub2RlcyBwZXIgaW5vZGUgYnVmZmVyICovCitFWFRF Uk4gaW50CQlpbm9kZXNfcGVyX2NsdXN0ZXI7CiBFWFRFUk4gdW5zaWduZWQgaW50 CWdsb2JfYWdjb3VudDsKIEVYVEVSTiBpbnQJCWNodW5rc19wYmxvY2s7CS8qICMg b2YgNjQtaW5vIGNodW5rcyBwZXIgYWxsb2NhdGlvbiAqLwogRVhURVJOIGludAkJ bWF4X3N5bWxpbmtfYmxvY2tzOwpAQCAtMTk4LDExICsxOTYsMTYgQEAKIGV4dGVy biBzaXplX3QgCQl0c19kaXJfZnJlZW1hcF9zaXplOwogZXh0ZXJuIHNpemVfdCAJ CXRzX2F0dHJfZnJlZW1hcF9zaXplOwogCi1FWFRFUk4gcHRocmVhZF9yd2xvY2tf dAkqcGVyX2FnX2xvY2s7CitFWFRFUk4gcHRocmVhZF9tdXRleF90CSphZ19sb2Nr czsKKworRVhURVJOIGludCAJCXJlcG9ydF9pbnRlcnZhbDsKK0VYVEVSTiBfX3Vp bnQ2NF90IAkqcHJvZ19ycHRfZG9uZTsKIAotRVhURVJOIGludCByZXBvcnRfaW50 ZXJ2YWw7Ci1FWFRFUk4gX191aW50NjRfdCAqcHJvZ19ycHRfZG9uZTsKKyNpZmRl ZiBYUl9QRl9UUkFDRQorRVhURVJOIEZJTEUJCSpwZl90cmFjZV9maWxlOworI2Vu ZGlmCiAKIEVYVEVSTiBpbnQJCWFnX3N0cmlkZTsKK0VYVEVSTiBpbnQJCXRocmVh ZF9jb3VudDsKIAogI2VuZGlmIC8qIF9YRlNfUkVQQUlSX0dMT0JBTF9IICovCklu ZGV4OiByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL2luY29yZS5jCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dzL3JlcGFpci9pbmNvcmUu YwkyMDA3LTA0LTI3IDEzOjEzOjM1LjAwMDAwMDAwMCArMTAwMAorKysgcmVwYWly L3hmc3Byb2dzL3JlcGFpci9pbmNvcmUuYwkyMDA3LTA1LTE2IDEyOjAyOjM5LjYx MjY1NDUzMCArMTAwMApAQCAtNjEsMTEgKzYxLDEyIEBACiAJc2l6ZV90IHNpemUg PSAwOwogCiAJYmFfYm1hcCA9IChfX3VpbnQ2NF90KiopbWFsbG9jKGFnbm8qc2l6 ZW9mKF9fdWludDY0X3QgKikpOwotCWlmICghYmFfYm1hcCkgIHsKKwlpZiAoIWJh X2JtYXApCiAJCWRvX2Vycm9yKF8oImNvdWxkbid0IGFsbG9jYXRlIGJsb2NrIG1h cCBwb2ludGVyc1xuIikpOwotCQlyZXR1cm47Ci0JfQotCVBSRVBBSVJfUldfTE9D S19BTExPQyhwZXJfYWdfbG9jaywgYWdubyk7CisJYWdfbG9ja3MgPSBtYWxsb2Mo YWdubyAqIHNpemVvZihwdGhyZWFkX211dGV4X3QpKTsKKwlpZiAoIWFnX2xvY2tz KQorCQlkb19lcnJvcihfKCJjb3VsZG4ndCBhbGxvY2F0ZSBibG9jayBtYXAgbG9j a3NcbiIpKTsKKwogCWZvciAoaSA9IDA7IGkgPCBhZ25vOyBpKyspICB7CiAJCXNp emUgPSByb3VuZHVwKChudW1ibG9ja3MrKE5CQlkvWFJfQkIpLTEpIC8gKE5CQlkv WFJfQkIpLAogCQkgICAgICAgCQlzaXplb2YoX191aW50NjRfdCkpOwpAQCAtNzcs NyArNzgsNyBAQAogCQkJcmV0dXJuOwogCQl9CiAJCWJ6ZXJvKGJhX2JtYXBbaV0s IHNpemUpOwotCQlQUkVQQUlSX1JXX0xPQ0tfSU5JVCgmcGVyX2FnX2xvY2tbaV0s IE5VTEwpOworCQlwdGhyZWFkX211dGV4X2luaXQoJmFnX2xvY2tzW2ldLCBOVUxM KTsKIAl9CiAKIAlpZiAocnRibG9ja3MgPT0gMCkgIHsKSW5kZXg6IHJlcGFpci94 ZnNwcm9ncy9yZXBhaXIvaW5jb3JlLmgKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g cmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVwYWlyL2luY29yZS5oCTIwMDctMDQtMjcg MTM6NDY6NTEuMDAwMDAwMDAwICsxMDAwCisrKyByZXBhaXIveGZzcHJvZ3MvcmVw YWlyL2luY29yZS5oCTIwMDctMDUtMTYgMTI6MDI6MzkuNjEyNjU0NTMwICsxMDAw CkBAIC0xNiw2ICsxNiwxMCBAQAogICogSW5jLiwgIDUxIEZyYW5rbGluIFN0LCBG aWZ0aCBGbG9vciwgQm9zdG9uLCBNQSAgMDIxMTAtMTMwMSAgVVNBCiAgKi8KIAor I2lmbmRlZiBYRlNfUkVQQUlSX0lOQ09SRV9ICisjZGVmaW5lIFhGU19SRVBBSVJf SU5DT1JFX0gKKworI2luY2x1ZGUgImF2bC5oIgogLyoKICAqIGNvbnRhaW5zIGRl ZmluaXRpb24gaW5mb3JtYXRpb24uICBpbXBsZW1lbnRhdGlvbiAoY29kZSkKICAq IGlzIHNwcmVhZCBvdXQgaW4gc2VwYXJhdGUgZmlsZXMuCkBAIC02MDMsNyArNjA3 LDcgQEAKICNkZWZpbmUgYWRkX2lub2RlX3JlZmNoZWNrZWQoaW5vLCBpbm9fcmVj LCBpbm9fb2Zmc2V0KSBcCiAJCVhGU19JTk9QUk9DX1NFVF9QUk9DKChpbm9fcmVj KSwgKGlub19vZmZzZXQpKQogI2RlZmluZSBpc19pbm9kZV9yZWZjaGVja2VkKGlu bywgaW5vX3JlYywgaW5vX29mZnNldCkgXAotCQkoWEZTX0lOT1BST0NfSVNfUFJP Qyhpbm9fcmVjLCBpbm9fb2Zmc2V0KSA9PSAwTEwgPyAwIDogMSkKKwkJKFhGU19J Tk9QUk9DX0lTX1BST0MoaW5vX3JlYywgaW5vX29mZnNldCkgIT0gMExMKQogI2Vs c2UKIHZvaWQgYWRkX2lub2RlX3JlZmNoZWNrZWQoeGZzX2lub190IGlubywKIAkJ CWlub190cmVlX25vZGVfdCAqaW5vX3JlYywgaW50IGlub19vZmZzZXQpOwpAQCAt NjQ3LDMgKzY1MSw1IEBACiB9IGJtYXBfY3Vyc29yX3Q7CiAKIHZvaWQgaW5pdF9i bV9jdXJzb3IoYm1hcF9jdXJzb3JfdCAqY3Vyc29yLCBpbnQgbnVtX2xldmVsKTsK KworI2VuZGlmIC8qIFhGU19SRVBBSVJfSU5DT1JFX0ggKi8KSW5kZXg6IHJlcGFp ci94ZnNwcm9ncy9yZXBhaXIvaW5jb3JlX2V4dC5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dzL3JlcGFpci9pbmNvcmVfZXh0LmMJ MjAwNy0wNC0yNyAxMzoxMzozNS4wMDAwMDAwMDAgKzEwMDAKKysrIHJlcGFpci94 ZnNwcm9ncy9yZXBhaXIvaW5jb3JlX2V4dC5jCTIwMDctMDQtMjcgMTQ6MTI6MzQu MTUxNTY4NzIyICsxMDAwCkBAIC05NSw5ICs5NSw5IEBACiAvKgogICogbG9ja3Mu CiAgKi8KLXN0YXRpYyBwdGhyZWFkX3J3bG9ja190IGV4dF9mbGlzdF9sb2NrOwot c3RhdGljIHB0aHJlYWRfcndsb2NrX3QgcnRfZXh0X3RyZWVfbG9jazsKLXN0YXRp YyBwdGhyZWFkX3J3bG9ja190IHJ0X2V4dF9mbGlzdF9sb2NrOworc3RhdGljIHB0 aHJlYWRfbXV0ZXhfdAlleHRfZmxpc3RfbG9jazsKK3N0YXRpYyBwdGhyZWFkX211 dGV4X3QJcnRfZXh0X3RyZWVfbG9jazsKK3N0YXRpYyBwdGhyZWFkX211dGV4X3QJ cnRfZXh0X2ZsaXN0X2xvY2s7CiAKIC8qCiAgKiBleHRlbnQgdHJlZSBzdHVmZiBp cyBhdmwgdHJlZXMgb2YgZHVwbGljYXRlIGV4dGVudHMsCkBAIC0xMTIsNyArMTEy LDcgQEAKIAlleHRlbnRfdHJlZV9ub2RlX3QgKm5ldzsKIAlleHRlbnRfYWxsb2Nf cmVjX3QgKnJlYzsKIAotCVBSRVBBSVJfUldfV1JJVEVfTE9DSygmZXh0X2ZsaXN0 X2xvY2spOworCXB0aHJlYWRfbXV0ZXhfbG9jaygmZXh0X2ZsaXN0X2xvY2spOwog CWlmIChleHRfZmxpc3QuY250ID09IDApICB7CiAJCUFTU0VSVChleHRfZmxpc3Qu bGlzdCA9PSBOVUxMKTsKIApAQCAtMTM5LDcgKzEzOSw3IEBACiAJZXh0X2ZsaXN0 Lmxpc3QgPSAoZXh0ZW50X3RyZWVfbm9kZV90ICopIG5ldy0+YXZsX25vZGUuYXZs X25leHRpbm87CiAJZXh0X2ZsaXN0LmNudC0tOwogCW5ldy0+YXZsX25vZGUuYXZs X25leHRpbm8gPSBOVUxMOwotCVBSRVBBSVJfUldfVU5MT0NLKCZleHRfZmxpc3Rf bG9jayk7CisJcHRocmVhZF9tdXRleF91bmxvY2soJmV4dF9mbGlzdF9sb2NrKTsK IAogCS8qIGluaXRpYWxpemUgbm9kZSAqLwogCkBAIC0xNTUsMTEgKzE1NSwxMSBA QAogdm9pZAogcmVsZWFzZV9leHRlbnRfdHJlZV9ub2RlKGV4dGVudF90cmVlX25v ZGVfdCAqbm9kZSkKIHsKLQlQUkVQQUlSX1JXX1dSSVRFX0xPQ0soJmV4dF9mbGlz dF9sb2NrKTsKKwlwdGhyZWFkX211dGV4X2xvY2soJmV4dF9mbGlzdF9sb2NrKTsK IAlub2RlLT5hdmxfbm9kZS5hdmxfbmV4dGlubyA9IChhdmxub2RlX3QgKikgZXh0 X2ZsaXN0Lmxpc3Q7CiAJZXh0X2ZsaXN0Lmxpc3QgPSBub2RlOwogCWV4dF9mbGlz dC5jbnQrKzsKLQlQUkVQQUlSX1JXX1VOTE9DSygmZXh0X2ZsaXN0X2xvY2spOwor CXB0aHJlYWRfbXV0ZXhfdW5sb2NrKCZleHRfZmxpc3RfbG9jayk7CiAKIAlyZXR1 cm47CiB9CkBAIC0zMjcsMTEgKzMyNywxMSBAQAogCQkgKiBhdmwgdHJlZSBjb2Rl IGRvZXNuJ3QgaGFuZGxlIGR1cHMgc28gaW5zZXJ0CiAJCSAqIG9udG8gbGlua2Vk IGxpc3QgaW4gaW5jcmVhc2luZyBzdGFydGJsb2NrIG9yZGVyCiAJCSAqCi0JCSAq IHdoZW4gY2FsbGVkIGZyb20gbWtfaW5jb3JlX2ZzdHJlZSwgCisJCSAqIHdoZW4g Y2FsbGVkIGZyb20gbWtfaW5jb3JlX2ZzdHJlZSwKIAkJICogc3RhcnRibG9jayBp cyBpbiBpbmNyZWFzaW5nIG9yZGVyLgogCQkgKiBjdXJyZW50IGlzIGFuICJhbmNo b3IiIG5vZGUuCiAJCSAqIHF1aWNrIGNoZWNrIGlmIHRoZSBuZXcgZXh0IGdvZXMg dG8gdGhlIGVuZC4KLQkJICogaWYgc28sIGFwcGVuZCBhdCB0aGUgZW5kLCB1c2lu ZyB0aGUgbGFzdCBmaWVsZCAKKwkJICogaWYgc28sIGFwcGVuZCBhdCB0aGUgZW5k LCB1c2luZyB0aGUgbGFzdCBmaWVsZAogCQkgKiBvZiB0aGUgImFuY2hvciIuCiAJ CSAqLwogCQlBU1NFUlQoY3VycmVudC0+bGFzdCAhPSBOVUxMKTsKQEAgLTM0MSw3 ICszNDEsNyBAQAogCQkJcmV0dXJuOwogCQl9CiAKLQkJLyogCisJCS8qCiAJCSAq IHNjYW4sIHRvIGZpbmQgdGhlIHByb3BlciBsb2NhdGlvbiBmb3IgbmV3IGVudHJ5 LgogCQkgKiB0aGlzIHNjYW4gaXMgKnZlcnkqIGV4cGVuc2l2ZSBhbmQgZ2V0cyB3 b3JzZSB3aXRoCiAJCSAqIHdpdGggaW5jcmVhc2luZyBlbnRyaWVzLgpAQCAtNjcw LDcgKzY3MCw3IEBACiAJcnRfZXh0ZW50X3RyZWVfbm9kZV90ICpuZXc7CiAJcnRf ZXh0ZW50X2FsbG9jX3JlY190ICpyZWM7CiAKLQlQUkVQQUlSX1JXX1dSSVRFX0xP Q0soJnJ0X2V4dF9mbGlzdF9sb2NrKTsKKwlwdGhyZWFkX211dGV4X2xvY2soJnJ0 X2V4dF9mbGlzdF9sb2NrKTsKIAlpZiAocnRfZXh0X2ZsaXN0LmNudCA9PSAwKSAg ewogCQlBU1NFUlQocnRfZXh0X2ZsaXN0Lmxpc3QgPT0gTlVMTCk7CiAKQEAgLTY5 Nyw3ICs2OTcsNyBAQAogCXJ0X2V4dF9mbGlzdC5saXN0ID0gKHJ0X2V4dGVudF90 cmVlX25vZGVfdCAqKSBuZXctPmF2bF9ub2RlLmF2bF9uZXh0aW5vOwogCXJ0X2V4 dF9mbGlzdC5jbnQtLTsKIAluZXctPmF2bF9ub2RlLmF2bF9uZXh0aW5vID0gTlVM TDsKLQlQUkVQQUlSX1JXX1VOTE9DSygmcnRfZXh0X2ZsaXN0X2xvY2spOworCXB0 aHJlYWRfbXV0ZXhfdW5sb2NrKCZydF9leHRfZmxpc3RfbG9jayk7CiAKIAkvKiBp bml0aWFsaXplIG5vZGUgKi8KIApAQCAtNzc2LDcgKzc3Niw3IEBACiAJeGZzX2Ry dGJub190IG5ld19zdGFydGJsb2NrOwogCXhmc19leHRsZW5fdCBuZXdfYmxvY2tj b3VudDsKIAotCVBSRVBBSVJfUldfV1JJVEVfTE9DSygmcnRfZXh0X3RyZWVfbG9j ayk7CisJcHRocmVhZF9tdXRleF9sb2NrKCZydF9leHRfdHJlZV9sb2NrKTsKIAlh dmw2NF9maW5kcmFuZ2VzKHJ0X2V4dF90cmVlX3B0ciwgc3RhcnRibG9jayAtIDEs CiAJCXN0YXJ0YmxvY2sgKyBibG9ja2NvdW50ICsgMSwKIAkJKGF2bDY0bm9kZV90 ICoqKSAmZmlyc3QsIChhdmw2NG5vZGVfdCAqKikgJmxhc3QpOwpAQCAtNzk0LDcg Kzc5NCw3IEBACiAJCQlkb19lcnJvcihfKCJkdXBsaWNhdGUgZXh0ZW50IHJhbmdl XG4iKSk7CiAJCX0KIAotCQlQUkVQQUlSX1JXX1VOTE9DSygmcnRfZXh0X3RyZWVf bG9jayk7CisJCXB0aHJlYWRfbXV0ZXhfdW5sb2NrKCZydF9leHRfdHJlZV9sb2Nr KTsKIAkJcmV0dXJuOwogCX0KIApAQCAtODE5LDcgKzgxOSw3IEBACiAJCSAqLwog CQlpZiAoZXh0LT5ydF9zdGFydGJsb2NrIDw9IHN0YXJ0YmxvY2sgJiYKIAkJCQll eHQtPnJ0X2Jsb2NrY291bnQgPj0gYmxvY2tjb3VudCkgewotCQkJUFJFUEFJUl9S V19VTkxPQ0soJnJ0X2V4dF90cmVlX2xvY2spOworCQkJcHRocmVhZF9tdXRleF91 bmxvY2soJnJ0X2V4dF90cmVlX2xvY2spOwogCQkJcmV0dXJuOwogCQl9CiAJCS8q CkBAIC04NDksNyArODQ5LDcgQEAKIAkJZG9fZXJyb3IoXygiZHVwbGljYXRlIGV4 dGVudCByYW5nZVxuIikpOwogCX0KIAotCVBSRVBBSVJfUldfVU5MT0NLKCZydF9l eHRfdHJlZV9sb2NrKTsKKwlwdGhyZWFkX211dGV4X3VubG9jaygmcnRfZXh0X3Ry ZWVfbG9jayk7CiAJcmV0dXJuOwogfQogCkBAIC04NjIsMTIgKzg2MiwxMiBAQAog ewogCWludCByZXQ7CiAKLQlQUkVQQUlSX1JXX1JFQURfTE9DSygmcnRfZXh0X3Ry ZWVfbG9jayk7CisJcHRocmVhZF9tdXRleF9sb2NrKCZydF9leHRfdHJlZV9sb2Nr KTsKIAlpZiAoYXZsNjRfZmluZHJhbmdlKHJ0X2V4dF90cmVlX3B0ciwgYm5vKSAh PSBOVUxMKQogCQlyZXQgPSAxOwogCWVsc2UKIAkJcmV0ID0gMDsKLQlQUkVQQUlS X1JXX1VOTE9DSygmcnRfZXh0X3RyZWVfbG9jayk7CisJcHRocmVhZF9tdXRleF91 bmxvY2soJnJ0X2V4dF90cmVlX2xvY2spOwogCXJldHVybihyZXQpOwogfQogCkBA IC04OTcsOSArODk3LDkgQEAKIAogCWJhX2xpc3QgPSBOVUxMOwogCXJ0X2JhX2xp c3QgPSBOVUxMOwotCVBSRVBBSVJfUldfTE9DS19JTklUKCZleHRfZmxpc3RfbG9j aywgTlVMTCk7Ci0JUFJFUEFJUl9SV19MT0NLX0lOSVQoJnJ0X2V4dF90cmVlX2xv Y2ssIE5VTEwpOwotCVBSRVBBSVJfUldfTE9DS19JTklUKCZydF9leHRfZmxpc3Rf bG9jaywgTlVMTCk7CisJcHRocmVhZF9tdXRleF9pbml0KCZleHRfZmxpc3RfbG9j aywgTlVMTCk7CisJcHRocmVhZF9tdXRleF9pbml0KCZydF9leHRfdHJlZV9sb2Nr LCBOVUxMKTsKKwlwdGhyZWFkX211dGV4X2luaXQoJnJ0X2V4dF9mbGlzdF9sb2Nr LCBOVUxMKTsKIAogCWlmICgoZXh0ZW50X3RyZWVfcHRycyA9IG1hbGxvYyhhZ2Nv dW50ICoKIAkJCQkJc2l6ZW9mKGF2bHRyZWVfZGVzY190ICopKSkgPT0gTlVMTCkK SW5kZXg6IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvaW5jb3JlX2luby5jCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dzL3JlcGFpci9p bmNvcmVfaW5vLmMJMjAwNy0wNC0yNyAxNDowOTozNy4wMDAwMDAwMDAgKzEwMDAK KysrIHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvaW5jb3JlX2luby5jCTIwMDctMDQt MjcgMTQ6MTI6MzQuMTU1NTY4MjAwICsxMDAwCkBAIC0yNSw3ICsyNSw3IEBACiAj aW5jbHVkZSAidGhyZWFkcy5oIgogI2luY2x1ZGUgImVycl9wcm90b3MuaCIKIAot c3RhdGljIHB0aHJlYWRfcndsb2NrX3QgaW5vX2ZsaXN0X2xvY2s7CitzdGF0aWMg cHRocmVhZF9tdXRleF90CWlub19mbGlzdF9sb2NrOwogZXh0ZXJuIGF2bG5vZGVf dAkqYXZsX2ZpcnN0aW5vKGF2bG5vZGVfdCAqcm9vdCk7CiAKIC8qCkBAIC0yNTks NyArMjU5LDcgQEAKIAlpbm9fdHJlZV9ub2RlX3QgCSppbm9fcmVjOwogCWF2bG5v ZGVfdCAJCSpub2RlOwogCi0JUFJFUEFJUl9SV19XUklURV9MT0NLKCZpbm9fZmxp c3RfbG9jayk7CisJcHRocmVhZF9tdXRleF9sb2NrKCZpbm9fZmxpc3RfbG9jayk7 CiAJaWYgKGlub19mbGlzdC5jbnQgPT0gMCkgIHsKIAkJQVNTRVJUKGlub19mbGlz dC5saXN0ID09IE5VTEwpOwogCkBAIC0yODMsNyArMjgzLDcgQEAKIAlpbm9fZmxp c3QuY250LS07CiAJbm9kZSA9ICZpbm9fcmVjLT5hdmxfbm9kZTsKIAlub2RlLT5h dmxfbmV4dGlubyA9IG5vZGUtPmF2bF9mb3J3ID0gbm9kZS0+YXZsX2JhY2sgPSBO VUxMOwotCVBSRVBBSVJfUldfVU5MT0NLKCZpbm9fZmxpc3RfbG9jayk7CisJcHRo cmVhZF9tdXRleF91bmxvY2soJmlub19mbGlzdF9sb2NrKTsKIAogCS8qIGluaXRp YWxpemUgbm9kZSAqLwogCkBAIC0zMTEsNyArMzExLDcgQEAKIAlpbm9fcmVjLT5h dmxfbm9kZS5hdmxfZm9ydyA9IE5VTEw7CiAJaW5vX3JlYy0+YXZsX25vZGUuYXZs X2JhY2sgPSBOVUxMOwogCi0JUFJFUEFJUl9SV19XUklURV9MT0NLKCZpbm9fZmxp c3RfbG9jayk7CisJcHRocmVhZF9tdXRleF9sb2NrKCZpbm9fZmxpc3RfbG9jayk7 CiAJaWYgKGlub19mbGlzdC5saXN0ICE9IE5VTEwpICB7CiAJCUFTU0VSVChpbm9f Zmxpc3QuY250ID4gMCk7CiAJCWlub19yZWMtPmF2bF9ub2RlLmF2bF9uZXh0aW5v ID0gKGF2bG5vZGVfdCAqKSBpbm9fZmxpc3QubGlzdDsKQEAgLTMzMyw5ICszMzMs NyBAQAogCQlmcmVlKGlub19yZWMtPmlub191bi5leF9kYXRhKTsKIAogCX0KLQlQ UkVQQUlSX1JXX1VOTE9DSygmaW5vX2ZsaXN0X2xvY2spOwotCi0JcmV0dXJuOwor CXB0aHJlYWRfbXV0ZXhfdW5sb2NrKCZpbm9fZmxpc3RfbG9jayk7CiB9CiAKIC8q CkBAIC00MDMsOCArNDAxLDYgQEAKIAkgKiBzZXQgY2FjaGUgZW50cnkKIAkgKi8K IAlsYXN0X3JlY1thZ25vXSA9IGlub19yZWM7Ci0KLQlyZXR1cm47CiB9CiAKIC8q CkBAIC00NTIsOCArNDQ4LDYgQEAKIGNsZWFyX3VuY2VydGFpbl9pbm9fY2FjaGUo eGZzX2FnbnVtYmVyX3QgYWdubykKIHsKIAlsYXN0X3JlY1thZ25vXSA9IE5VTEw7 Ci0KLQlyZXR1cm47CiB9CiAKIApAQCAtNTIxLDggKzUxNSw2IEBACiBmcmVlX2lu b2RlX3JlYyh4ZnNfYWdudW1iZXJfdCBhZ25vLCBpbm9fdHJlZV9ub2RlX3QgKmlu b19yZWMpCiB7CiAJZnJlZV9pbm9fdHJlZV9ub2RlKGlub19yZWMpOwotCi0JcmV0 dXJuOwogfQogCiB2b2lkCkBAIC01MzQsNyArNTI2LDYgQEAKIAogCWF2bF9maW5k cmFuZ2VzKGlub2RlX3RyZWVfcHRyc1thZ25vXSwgc3RhcnRfaW5vLAogCQllbmRf aW5vLCAoYXZsbm9kZV90ICoqKSBmaXJzdCwgKGF2bG5vZGVfdCAqKikgbGFzdCk7 Ci0JcmV0dXJuOwogfQogCiAvKgpAQCAtNzE2LDggKzcwNyw2IEBACiAjZW5kaWYK IAlpcmVjLT5pbm9fdW4ucGxpc3QtPnBlbnRyaWVzW3RhcmdldF0gPSBwYXJlbnQ7 CiAJaXJlYy0+aW5vX3VuLnBsaXN0LT5wbWFzayB8PSAoMUxMIDw8IG9mZnNldCk7 Ci0KLQlyZXR1cm47CiB9CiAKIHhmc19pbm9fdApAQCAtODEwLDcgKzc5OSw3IEBA CiAJaW50IGk7CiAJaW50IGFnY291bnQgPSBtcC0+bV9zYi5zYl9hZ2NvdW50Owog Ci0JUFJFUEFJUl9SV19MT0NLX0lOSVQoJmlub19mbGlzdF9sb2NrLCBOVUxMKTsK KwlwdGhyZWFkX211dGV4X2luaXQoJmlub19mbGlzdF9sb2NrLCBOVUxMKTsKIAlp ZiAoKGlub2RlX3RyZWVfcHRycyA9IG1hbGxvYyhhZ2NvdW50ICoKIAkJCQkJc2l6 ZW9mKGF2bHRyZWVfZGVzY190ICopKSkgPT0gTlVMTCkKIAkJZG9fZXJyb3IoXygi Y291bGRuJ3QgbWFsbG9jIGlub2RlIHRyZWUgZGVzY3JpcHRvciB0YWJsZVxuIikp OwpAQCAtODQyLDggKzgzMSw2IEBACiAJYnplcm8obGFzdF9yZWMsIHNpemVvZihp bm9fdHJlZV9ub2RlX3QgKikgKiBhZ2NvdW50KTsKIAogCWZ1bGxfaW5vX2V4X2Rh dGEgPSAwOwotCi0JcmV0dXJuOwogfQogCiAjaWZkZWYgWFJfSU5PX1JFRl9ERUJV RwpAQCAtODUzLDggKzg0MCw2IEBACiAJWEZTX0lOT1BST0NfU0VUX1BST0MoKGlu b19yZWMpLCAoaW5vX29mZnNldCkpOwogCiAJQVNTRVJUKGlzX2lub2RlX3JlZmNo ZWNrZWQoaW5vLCBpbm9fcmVjLCBpbm9fb2Zmc2V0KSk7Ci0KLQlyZXR1cm47CiB9 CiAKIGludApJbmRleDogcmVwYWlyL3hmc3Byb2dzL3JlcGFpci9pbml0LmMKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVwYWly L2luaXQuYwkyMDA3LTA0LTI3IDE0OjExOjQxLjAwMDAwMDAwMCArMTAwMAorKysg cmVwYWlyL3hmc3Byb2dzL3JlcGFpci9pbml0LmMJMjAwNy0wNC0yNyAxNDoxMjoz NC4xNTU1NjgyMDAgKzEwMDAKQEAgLTIyLDcgKzIyLDExIEBACiAjaW5jbHVkZSAi cHJvdG9zLmgiCiAjaW5jbHVkZSAiZXJyX3Byb3Rvcy5oIgogI2luY2x1ZGUgInB0 aHJlYWQuaCIKKyNpbmNsdWRlICJhdmwuaCIKKyNpbmNsdWRlICJkaXIuaCIKKyNp bmNsdWRlICJpbmNvcmUuaCIKICNpbmNsdWRlICJwcmVmZXRjaC5oIgorI2luY2x1 ZGUgInJhZGl4LXRyZWUuaCIKICNpbmNsdWRlIDxzeXMvcmVzb3VyY2UuaD4KIAog c3RhdGljIHB0aHJlYWRfa2V5X3QgZGlyYnVmX2tleTsKQEAgLTE0NCw5ICsxNDgs NSBAQAogCXRzX2NyZWF0ZSgpOwogCXRzX2luaXQoKTsKIAlpbmNyZWFzZV9ybGlt aXQoKTsKLQlpZiAoZG9fcHJlZmV0Y2gpIHsKLQkJZG9fcHJlZmV0Y2ggPSBsaWJ4 ZnNfbGlvX2luaXQoKTsKLQkJaWYgKGRvX3ByZWZldGNoKQotCQkJbGlieGZzX2xp b19hbGxvY2F0ZSgpOwotCX0KKwlyYWRpeF90cmVlX2luaXQoKTsKIH0KSW5kZXg6 IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvcGhhc2UzLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVwYWlyL3BoYXNlMy5jCTIw MDctMDQtMjcgMTQ6MTE6NDEuMDAwMDAwMDAwICsxMDAwCisrKyByZXBhaXIveGZz cHJvZ3MvcmVwYWlyL3BoYXNlMy5jCTIwMDctMDUtMDEgMTY6NTQ6NTguNzExMTc0 NDUyICsxMDAwCkBAIC0yNiw2ICsyNiw3IEBACiAjaW5jbHVkZSAiZGlub2RlLmgi CiAjaW5jbHVkZSAidGhyZWFkcy5oIgogI2luY2x1ZGUgInByb2dyZXNzLmgiCisj aW5jbHVkZSAicHJlZmV0Y2guaCIKIAogLyoKICAqIHdhbGtzIGFuIHVubGlua2Vk IGxpc3QsIHJldHVybnMgMSBvbiBhbiBlcnJvciAoYm9ndXMgcG9pbnRlcikgb3IK QEAgLTU5LDcgKzYwLDcgQEAKIAkJCQlhZGRfYWdpbm9kZV91bmNlcnRhaW4oYWdu bywgY3VycmVudF9pbm8sIDEpOwogCQkJCWFnYm5vID0gWEZTX0FHSU5PX1RPX0FH Qk5PKG1wLCBjdXJyZW50X2lubyk7CiAKLQkJCQlQUkVQQUlSX1JXX1dSSVRFX0xP Q0soJnBlcl9hZ19sb2NrW2Fnbm9dKTsKKwkJCQlwdGhyZWFkX211dGV4X2xvY2so JmFnX2xvY2tzW2Fnbm9dKTsKIAkJCQlzd2l0Y2ggKHN0YXRlID0gZ2V0X2FnYm5v X3N0YXRlKG1wLAogCQkJCQkJCWFnbm8sIGFnYm5vKSkgIHsKIAkJCQljYXNlIFhS X0VfVU5LTk9XTjoKQEAgLTY3LDE0ICs2OCwxMSBAQAogCQkJCWNhc2UgWFJfRV9G UkVFMToKIAkJCQkJc2V0X2FnYm5vX3N0YXRlKG1wLCBhZ25vLCBhZ2JubywKIAkJ CQkJCVhSX0VfSU5PKTsKLQkJCQkJUFJFUEFJUl9SV19VTkxPQ0soJnBlcl9hZ19s b2NrW2Fnbm9dKTsKIAkJCQkJYnJlYWs7CiAJCQkJY2FzZSBYUl9FX0JBRF9TVEFU RToKLQkJCQkJUFJFUEFJUl9SV19VTkxPQ0soJnBlcl9hZ19sb2NrW2Fnbm9dKTsK IAkJCQkJZG9fZXJyb3IoXygKIAkJCQkJCSJiYWQgc3RhdGUgaW4gYmxvY2sgbWFw ICVkXG4iKSwKIAkJCQkJCXN0YXRlKTsKLQkJCQkJYWJvcnQoKTsKIAkJCQkJYnJl YWs7CiAJCQkJZGVmYXVsdDoKIAkJCQkJLyoKQEAgLTg5LDkgKzg3LDkgQEAKIAkJ CQkJICovCiAJCQkJCXNldF9hZ2Jub19zdGF0ZShtcCwgYWdubywgYWdibm8sCiAJ CQkJCQlYUl9FX0lOTyk7Ci0JCQkJCVBSRVBBSVJfUldfVU5MT0NLKCZwZXJfYWdf bG9ja1thZ25vXSk7CiAJCQkJCWJyZWFrOwogCQkJCX0KKwkJCQlwdGhyZWFkX211 dGV4X3VubG9jaygmYWdfbG9ja3NbYWdub10pOwogCQkJfQogCQkJY3VycmVudF9p bm8gPSBkaXAtPmRpX25leHRfdW5saW5rZWQ7CiAJCX0gZWxzZSAgewpAQCAtMTQ5 LDIxICsxNDcsNjcgQEAKIAkJbGlieGZzX3B1dGJ1ZihicCk7CiB9CiAKLXZvaWQK LXBhcmFsbGVsX3AzX3Byb2Nlc3NfYWdpbm9kZXMoeGZzX21vdW50X3QgKm1wLCB4 ZnNfYWdudW1iZXJfdCBhZ25vKQorc3RhdGljIHZvaWQKK3Byb2Nlc3NfYWdfZnVu YygKKwl3b3JrX3F1ZXVlX3QJCSp3cSwKKwl4ZnNfYWdudW1iZXJfdCAJCWFnbm8s CisJdm9pZAkJCSphcmcpCiB7CiAJLyoKIAkgKiB0dXJuIG9uIGRpcmVjdG9yeSBw cm9jZXNzaW5nIChpbm9kZSBkaXNjb3ZlcnkpIGFuZAogCSAqIGF0dHJpYnV0ZSBw cm9jZXNzaW5nIChleHRyYV9hdHRyX2NoZWNrKQogCSAqLworCXdhaXRfZm9yX2lu b2RlX3ByZWZldGNoKGFyZyk7CiAJZG9fbG9nKF8oIiAgICAgICAgLSBhZ25vID0g JWRcbiIpLCBhZ25vKTsKLQlwcm9jZXNzX2FnaW5vZGVzKG1wLCBhZ25vLCAxLCAw LCAxKTsKKwlwcm9jZXNzX2FnaW5vZGVzKHdxLT5tcCwgYXJnLCBhZ25vLCAxLCAw LCAxKTsKKwljbGVhbnVwX2lub2RlX3ByZWZldGNoKGFyZyk7Cit9CisKK3N0YXRp YyB2b2lkCitwcm9jZXNzX2FncygKKwl4ZnNfbW91bnRfdAkJKm1wKQoreworCWlu dCAJCQlpLCBqOworCXdvcmtfcXVldWVfdAkJKnF1ZXVlczsKKwlwcmVmZXRjaF9h cmdzX3QJCSpwZl9hcmdzWzJdOworCisJcXVldWVzID0gbWFsbG9jKHRocmVhZF9j b3VudCAqIHNpemVvZih3b3JrX3F1ZXVlX3QpKTsKKworCWlmIChhZ19zdHJpZGUp IHsKKwkJLyoKKwkJICogY3JlYXRlIG9uZSB3b3JrZXIgdGhyZWFkIGZvciBlYWNo IHNlZ21lbnQgb2YgdGhlIHZvbHVtZQorCQkgKi8KKwkJZm9yIChpID0gMDsgaSA8 IHRocmVhZF9jb3VudDsgaSsrKSB7CisJCQljcmVhdGVfd29ya19xdWV1ZSgmcXVl dWVzW2ldLCBtcCwgMSk7CisJCQlwZl9hcmdzWzBdID0gTlVMTDsKKwkJCWZvciAo aiA9IGk7IGogPCBtcC0+bV9zYi5zYl9hZ2NvdW50OyBqICs9IGFnX3N0cmlkZSkg eworCQkJCXBmX2FyZ3NbMF0gPSBzdGFydF9pbm9kZV9wcmVmZXRjaChqLCAwLCBw Zl9hcmdzWzBdKTsKKwkJCQlxdWV1ZV93b3JrKCZxdWV1ZXNbaV0sIHByb2Nlc3Nf YWdfZnVuYywgaiwgcGZfYXJnc1swXSk7CisJCQl9CisJCX0KKwkJLyoKKwkJICog d2FpdCBmb3Igd29ya2VycyB0byBjb21wbGV0ZQorCQkgKi8KKwkJZm9yIChpID0g MDsgaSA8IHRocmVhZF9jb3VudDsgaSsrKQorCQkJZGVzdHJveV93b3JrX3F1ZXVl KCZxdWV1ZXNbaV0pOworCX0gZWxzZSB7CisJCXF1ZXVlc1swXS5tcCA9IG1wOwor CQlwZl9hcmdzWzBdID0gc3RhcnRfaW5vZGVfcHJlZmV0Y2goMCwgMCwgTlVMTCk7 CisJCWZvciAoaSA9IDA7IGkgPCBtcC0+bV9zYi5zYl9hZ2NvdW50OyBpKyspIHsK KwkJCXBmX2FyZ3NbKH5pKSAmIDFdID0gc3RhcnRfaW5vZGVfcHJlZmV0Y2goaSAr IDEsIDAsCisJCQkJCXBmX2FyZ3NbaSAmIDFdKTsKKwkJCXByb2Nlc3NfYWdfZnVu YygmcXVldWVzWzBdLCBpLCBwZl9hcmdzW2kgJiAxXSk7CisJCX0KKwl9CisJZnJl ZShxdWV1ZXMpOwogfQogCiB2b2lkCiBwaGFzZTMoeGZzX21vdW50X3QgKm1wKQog ewotCWludCBpLCBqOworCWludCAJCQlpLCBqOworCisJcHJpbnRmKCJNYWluIHRo cmVhZCA9ICVseFxuIiwgcHRocmVhZF9zZWxmKCkpOwogCiAJZG9fbG9nKF8oIlBo YXNlIDMgLSBmb3IgZWFjaCBBRy4uLlxuIikpOwogCWlmICghbm9fbW9kaWZ5KQpA QCAtMTkyLDE2ICsyMzYsOSBAQAogCSAgICAiICAgICAgICAtIHByb2Nlc3Mga25v d24gaW5vZGVzIGFuZCBwZXJmb3JtIGlub2RlIGRpc2NvdmVyeS4uLlxuIikpOwog CiAJc2V0X3Byb2dyZXNzX21zZyhQUk9HX0ZNVF9QUk9DRVNTX0lOTywgKF9fdWlu dDY0X3QpIG1wLT5tX3NiLnNiX2ljb3VudCk7Ci0JaWYgKGFnX3N0cmlkZSkgewot CQlpbnQgCXN0ZXBzID0gKG1wLT5tX3NiLnNiX2FnY291bnQgKyBhZ19zdHJpZGUg LSAxKSAvIGFnX3N0cmlkZTsKLQkJZm9yIChpID0gMDsgaSA8IHN0ZXBzOyBpKysp Ci0JCQlmb3IgKGogPSBpOyBqIDwgbXAtPm1fc2Iuc2JfYWdjb3VudDsgaiArPSBh Z19zdHJpZGUpCi0JCQkJcXVldWVfd29yayhwYXJhbGxlbF9wM19wcm9jZXNzX2Fn aW5vZGVzLCBtcCwgaik7Ci0JfSBlbHNlIHsKLQkJZm9yIChpID0gMDsgaSA8IG1w LT5tX3NiLnNiX2FnY291bnQ7IGkrKykKLQkJCXBhcmFsbGVsX3AzX3Byb2Nlc3Nf YWdpbm9kZXMobXAsIGkpOwotCX0KLQl3YWl0X2Zvcl93b3JrZXJzKCk7CisKKwlw cm9jZXNzX2FncyhtcCk7CisKIAlwcmludF9maW5hbF9ycHQoKTsKIAogCS8qCklu ZGV4OiByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL3BoYXNlNC5jCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dzL3JlcGFpci9waGFzZTQu YwkyMDA3LTA0LTI3IDE0OjExOjQxLjAwMDAwMDAwMCArMTAwMAorKysgcmVwYWly L3hmc3Byb2dzL3JlcGFpci9waGFzZTQuYwkyMDA3LTA0LTI3IDE0OjEyOjM0LjE3 MTU2NjExMiArMTAwMApAQCAtMzAsNiArMzAsNyBAQAogI2luY2x1ZGUgImRpcjIu aCIKICNpbmNsdWRlICJ0aHJlYWRzLmgiCiAjaW5jbHVkZSAicHJvZ3Jlc3MuaCIK KyNpbmNsdWRlICJwcmVmZXRjaC5oIgogCiAKIC8qCkBAIC0xMTQsMTEgKzExNSwx NiBAQAogfQogCiAKLXZvaWQKLXBhcmFsbGVsX3A0X3Byb2Nlc3NfYWdpbm9kZXMo eGZzX21vdW50X3QgKm1wLCB4ZnNfYWdudW1iZXJfdCBhZ25vKQorc3RhdGljIHZv aWQKK3Byb2Nlc3NfYWdfZnVuYygKKwl3b3JrX3F1ZXVlX3QJCSp3cSwKKwl4ZnNf YWdudW1iZXJfdCAJCWFnbm8sCisJdm9pZAkJCSphcmcpCiB7CisJd2FpdF9mb3Jf aW5vZGVfcHJlZmV0Y2goYXJnKTsKIAlkb19sb2coXygiICAgICAgICAtIGFnbm8g PSAlZFxuIiksIGFnbm8pOwotCXByb2Nlc3NfYWdpbm9kZXMobXAsIGFnbm8sIDAs IDEsIDApOworCXByb2Nlc3NfYWdpbm9kZXMod3EtPm1wLCBhcmcsIGFnbm8sIDAs IDEsIDApOworCWNsZWFudXBfaW5vZGVfcHJlZmV0Y2goYXJnKTsKIAogCS8qCiAJ ICogbm93IHJlY3ljbGUgdGhlIHBlci1BRyBkdXBsaWNhdGUgZXh0ZW50IHJlY29y ZHMKQEAgLTEyNiw2ICsxMzIsNTQgQEAKIAlyZWxlYXNlX2R1cF9leHRlbnRfdHJl ZShhZ25vKTsKIH0KIAorc3RhdGljIHZvaWQKK3Byb2Nlc3NfYWdzKAorCXhmc19t b3VudF90CQkqbXApCit7CisJaW50IAkJCWksIGo7CisJd29ya19xdWV1ZV90CQkq cXVldWVzOworCXByZWZldGNoX2FyZ3NfdAkJKnBmX2FyZ3NbMl07CisKKwlxdWV1 ZXMgPSBtYWxsb2ModGhyZWFkX2NvdW50ICogc2l6ZW9mKHdvcmtfcXVldWVfdCkp OworCisJaWYgKCFsaWJ4ZnNfYmNhY2hlX292ZXJmbG93ZWQoKSkgeworCQlxdWV1 ZXNbMF0ubXAgPSBtcDsKKwkJY3JlYXRlX3dvcmtfcXVldWUoJnF1ZXVlc1swXSwg bXAsIGxpYnhmc19ucHJvYygpKTsKKwkJZm9yIChpID0gMDsgaSA8IG1wLT5tX3Ni LnNiX2FnY291bnQ7IGkrKykKKwkJCXF1ZXVlX3dvcmsoJnF1ZXVlc1swXSwgcHJv Y2Vzc19hZ19mdW5jLCBpLCBOVUxMKTsKKwkJZGVzdHJveV93b3JrX3F1ZXVlKCZx dWV1ZXNbMF0pOworCX0gZWxzZSB7CisJCWlmIChhZ19zdHJpZGUpIHsKKwkJCS8q CisJCQkgKiBjcmVhdGUgb25lIHdvcmtlciB0aHJlYWQgZm9yIGVhY2ggc2VnbWVu dCBvZiB0aGUgdm9sdW1lCisJCQkgKi8KKwkJCWZvciAoaSA9IDA7IGkgPCB0aHJl YWRfY291bnQ7IGkrKykgeworCQkJCWNyZWF0ZV93b3JrX3F1ZXVlKCZxdWV1ZXNb aV0sIG1wLCAxKTsKKwkJCQlwZl9hcmdzWzBdID0gTlVMTDsKKwkJCQlmb3IgKGog PSBpOyBqIDwgbXAtPm1fc2Iuc2JfYWdjb3VudDsgaiArPSBhZ19zdHJpZGUpIHsK KwkJCQkJcGZfYXJnc1swXSA9IHN0YXJ0X2lub2RlX3ByZWZldGNoKGosIDAsIHBm X2FyZ3NbMF0pOworCQkJCQlxdWV1ZV93b3JrKCZxdWV1ZXNbaV0sIHByb2Nlc3Nf YWdfZnVuYywgaiwgcGZfYXJnc1swXSk7CisJCQkJfQorCQkJfQorCQkJLyoKKwkJ CSAqIHdhaXQgZm9yIHdvcmtlcnMgdG8gY29tcGxldGUKKwkJCSAqLworCQkJZm9y IChpID0gMDsgaSA8IHRocmVhZF9jb3VudDsgaSsrKQorCQkJCWRlc3Ryb3lfd29y a19xdWV1ZSgmcXVldWVzW2ldKTsKKwkJfSBlbHNlIHsKKwkJCXF1ZXVlc1swXS5t cCA9IG1wOworCQkJcGZfYXJnc1swXSA9IHN0YXJ0X2lub2RlX3ByZWZldGNoKDAs IDAsIE5VTEwpOworCQkJZm9yIChpID0gMDsgaSA8IG1wLT5tX3NiLnNiX2FnY291 bnQ7IGkrKykgeworCQkJCXBmX2FyZ3NbKH5pKSAmIDFdID0gc3RhcnRfaW5vZGVf cHJlZmV0Y2goaSArIDEsCisJCQkJCQkwLCBwZl9hcmdzW2kgJiAxXSk7CisJCQkJ cHJvY2Vzc19hZ19mdW5jKCZxdWV1ZXNbMF0sIGksIHBmX2FyZ3NbaSAmIDFdKTsK KwkJCX0KKwkJfQorCX0KKwlmcmVlKHF1ZXVlcyk7Cit9CisKKwogdm9pZAogcGhh c2U0KHhmc19tb3VudF90ICptcCkKIHsKQEAgLTMyOCwxNyArMzgyLDcgQEAKIAkg KiBhbmQgYXR0cmlidXRlIHByb2Nlc3NpbmcgaXMgdHVybmVkIE9GRiBzaW5jZSB3 ZSBkaWQgdGhhdAogCSAqIGFscmVhZHkgaW4gcGhhc2UgMy4KIAkgKi8KLQlpZiAo YWdfc3RyaWRlKSB7Ci0JCWludCAJc3RlcHMgPSAobXAtPm1fc2Iuc2JfYWdjb3Vu dCArIGFnX3N0cmlkZSAtIDEpIC8gYWdfc3RyaWRlOwotCQlmb3IgKGkgPSAwOyBp IDwgc3RlcHM7IGkrKykKLQkJCWZvciAoaiA9IGk7IGogPCBtcC0+bV9zYi5zYl9h Z2NvdW50OyBqICs9IGFnX3N0cmlkZSkKLQkJCQlxdWV1ZV93b3JrKHBhcmFsbGVs X3A0X3Byb2Nlc3NfYWdpbm9kZXMsIG1wLCBqKTsKLQl9IGVsc2UgewotCQlmb3Ig KGkgPSAwOyBpIDwgbXAtPm1fc2Iuc2JfYWdjb3VudDsgaSsrKQotCQkJcGFyYWxs ZWxfcDRfcHJvY2Vzc19hZ2lub2RlcyhtcCwgaSk7Ci0JfQotCi0Jd2FpdF9mb3Jf d29ya2VycygpOworCXByb2Nlc3NfYWdzKG1wKTsKIAlwcmludF9maW5hbF9ycHQo KTsKIAogCS8qCkluZGV4OiByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL3BoYXNlNS5j Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dzL3Jl cGFpci9waGFzZTUuYwkyMDA3LTA0LTI3IDEzOjEzOjM1LjAwMDAwMDAwMCArMTAw MAorKysgcmVwYWlyL3hmc3Byb2dzL3JlcGFpci9waGFzZTUuYwkyMDA3LTA0LTI3 IDE0OjEyOjM0LjE3NTU2NTU5MCArMTAwMApAQCAtMTQxOSw4ICsxNDE5LDEwIEBA CiAJCXNldF9pbm9kZV91c2VkKGlyZWMsIGkpOwogfQogCi12b2lkCi1waGFzZTVf ZnVuY3Rpb24oeGZzX21vdW50X3QgKm1wLCB4ZnNfYWdudW1iZXJfdCBhZ25vKQor c3RhdGljIHZvaWQKK3BoYXNlNV9mdW5jKAorCXhmc19tb3VudF90CSptcCwKKwl4 ZnNfYWdudW1iZXJfdAlhZ25vKQogewogCV9fdWludDY0X3QJbnVtX2lub3M7CiAJ X191aW50NjRfdAludW1fZnJlZV9pbm9zOwpAQCAtMTU5OCw3ICsxNjAwLDcgQEAK IHZvaWQKIHBoYXNlNSh4ZnNfbW91bnRfdCAqbXApCiB7Ci0JeGZzX2FnbnVtYmVy X3QgYWdubzsKKwl4ZnNfYWdudW1iZXJfdAkJYWdubzsKIAogCWRvX2xvZyhfKCJQ aGFzZSA1IC0gcmVidWlsZCBBRyBoZWFkZXJzIGFuZCB0cmVlcy4uLlxuIikpOwog CXNldF9wcm9ncmVzc19tc2coUFJPR19GTVRfUkVCVUlMRF9BRywgKF9fdWludDY0 X3QgKWdsb2JfYWdjb3VudCk7CkBAIC0xNjQxLDEwICsxNjQzLDkgQEAKIAlpZiAo c2JfZmRibG9ja3NfYWcgPT0gTlVMTCkKIAkJZG9fZXJyb3IoXygiY2Fubm90IGFs bG9jIHNiX2ZkYmxvY2tzX2FnIGJ1ZmZlcnNcbiIpKTsKIAotCWZvciAoYWdubyA9 IDA7IGFnbm8gPCBtcC0+bV9zYi5zYl9hZ2NvdW50OyBhZ25vKyspICB7Ci0JCXF1 ZXVlX3dvcmsocGhhc2U1X2Z1bmN0aW9uLCBtcCwgYWdubyk7Ci0JfQotCXdhaXRf Zm9yX3dvcmtlcnMoKTsKKwlmb3IgKGFnbm8gPSAwOyBhZ25vIDwgbXAtPm1fc2Iu c2JfYWdjb3VudDsgYWdubysrKQorCQlwaGFzZTVfZnVuYyhtcCwgYWdubyk7CisK IAlwcmludF9maW5hbF9ycHQoKTsKIAogCS8qIGFnZ3JlZ2F0ZSBwZXIgYWcgY291 bnRlcnMgKi8KSW5kZXg6IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvcGhhc2U2LmMK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVw YWlyL3BoYXNlNi5jCTIwMDctMDQtMjcgMTQ6MTE6NDEuMDAwMDAwMDAwICsxMDAw CisrKyByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL3BoYXNlNi5jCTIwMDctMDUtMjIg MTE6NTc6MzMuMDA3NTQ5Njc0ICsxMDAwCkBAIC0yMywxOCArMjMsMTcgQEAKICNp bmNsdWRlICJpbmNvcmUuaCIKICNpbmNsdWRlICJkaXIuaCIKICNpbmNsdWRlICJk aXIyLmgiCi0jaW5jbHVkZSAiZGlyX3N0YWNrLmgiCiAjaW5jbHVkZSAicHJvdG9z LmgiCiAjaW5jbHVkZSAiZXJyX3Byb3Rvcy5oIgogI2luY2x1ZGUgImRpbm9kZS5o IgogI2luY2x1ZGUgInByZWZldGNoLmgiCiAjaW5jbHVkZSAicHJvZ3Jlc3MuaCIK KyNpbmNsdWRlICJ0aHJlYWRzLmgiCiAjaW5jbHVkZSAidmVyc2lvbnMuaCIKIAog c3RhdGljIHN0cnVjdCBjcmVkCQl6ZXJvY3I7CiBzdGF0aWMgc3RydWN0IGZzeGF0 dHIgCQl6ZXJvZnN4Owogc3RhdGljIHhmc19pbm9fdAkJb3JwaGFuYWdlX2lubzsK LXN0YXRpYyB4ZnNfaW5vZGVfdAkJKm9ycGhhbmFnZV9pcDsKIAogLyoKICAqIERh dGEgc3RydWN0dXJlcyBhbmQgcm91dGluZXMgdG8ga2VlcCB0cmFjayBvZiBkaXJl Y3RvcnkgZW50cmllcwpAQCAtMjM2LDggKzIzNSw4IEBACiAJaW50CQloc2l6ZTsK IAogCWhzaXplID0gc2l6ZSAvICgxNiAqIDQpOwotCWlmIChoc2l6ZSA+IDEwMjQp Ci0JCWhzaXplID0gMTAyNDsKKwlpZiAoaHNpemUgPiA2NTUzNikKKwkJaHNpemUg PSA2MzMzNjsKIAllbHNlIGlmIChoc2l6ZSA8IDE2KQogCQloc2l6ZSA9IDE2Owog CWlmICgoaGFzaHRhYiA9IGNhbGxvYyhESVJfSEFTSF9UQUJfU0laRShoc2l6ZSks IDEpKSA9PSBOVUxMKQpAQCAtOTAyLDYgKzkwMSw3IEBACiAJeGZzX2lub190CQlp bm8sCQkvKiBpbm9kZSAjIHRvIGJlIG1vdmVkICovCiAJaW50CQkJaXNhX2RpcikJ LyogMSBpZiBpbm9kZSBpcyBhIGRpcmVjdG9yeSAqLwogeworCXhmc19pbm9kZV90 CQkqb3JwaGFuYWdlX2lwOwogCXhmc19pbm9fdAkJZW50cnlfaW5vX251bTsKIAl4 ZnNfaW5vZGVfdAkJKmlub19wOwogCXhmc190cmFuc190CQkqdHA7CkBAIC05MTcs NyArOTE3LDkgQEAKIAlmbmFtZWxlbiA9IHNucHJpbnRmKGZuYW1lLCBzaXplb2Yo Zm5hbWUpLCAiJWxsdSIsCiAJCQkodW5zaWduZWQgbG9uZyBsb25nKWlubyk7CiAK LQlBU1NFUlQob3JwaGFuYWdlX2lwICE9IE5VTEwpOworCWVyciA9IGxpYnhmc19p Z2V0KG1wLCBOVUxMLCBvcnBoYW5hZ2VfaW5vLCAwLCAmb3JwaGFuYWdlX2lwLCAw KTsKKwlpZiAoZXJyKQorCQlkb19lcnJvcihfKCIlZCAtIGNvdWxkbid0IGlnZXQg b3JwaGFuYWdlIGlub2RlXG4iKSwgZXJyKTsKIAkvKgogCSAqIE1ha2Ugc3VyZSB0 aGUgZmlsZW5hbWUgaXMgdW5pcXVlIGluIHRoZSBsb3N0K2ZvdW5kCiAJICovCkBA IC0xMDY4LDcgKzEwNzAsNyBAQAogICogUmV0dXJucyB0aGUgZnNibm8gb2YgdGhl IGZpcnN0IChsZWZ0bW9zdCkgYmxvY2sgaW4gdGhlIGRpcmVjdG9yeSBsZWFmLgog ICogc2V0cyAqYm5vIHRvIHRoZSBkaXJlY3RvcnkgYmxvY2sgIyBjb3JyZXNwb25k aW5nIHRvIHRoZSByZXR1cm5lZCBmc2Juby4KICAqLwoteGZzX2Rmc2Jub190Citz dGF0aWMgeGZzX2Rmc2Jub190CiBtYXBfZmlyc3RfZGJsb2NrX2ZzYm5vKHhmc19t b3VudF90CSptcCwKIAkJCXhmc19pbm9fdAlpbm8sCiAJCQl4ZnNfaW5vZGVfdAkq aXAsCkBAIC0xMDg0LDcgKzEwODYsNiBAQAogCWludAkJCWk7CiAJaW50CQkJZXJy b3I7CiAJY2hhcgkJCSpmdHlwZTsKLQl4ZnNfZnNibG9ja190CQlmYmxvY2syOwog CiAJLyoKIAkgKiB0cmF2ZXJzZSBkb3duIGxlZnQtc2lkZSBvZiB0cmVlIHVudGls IHdlIGhpdCB0aGUKQEAgLTExMzIsMTEgKzExMzMsNiBAQAogCWlmIChYRlNfU0Jf VkVSU0lPTl9IQVNESVJWMigmbXAtPm1fc2IpKQogCQlyZXR1cm4oZnNibm8pOwog Ci0JaWYgKGRvX3ByZWZldGNoKSB7Ci0gICAgICAgICAgICAgICAgZmJsb2NrMiA9 IE5VTExGU0JMT0NLOwotICAgICAgICAgICAgICAgIHByZWZldGNoX3A2X2RpcjEo bXAsIGlubywgaXAsIDAsICZmYmxvY2syKTsKLSAgICAgICAgfQotCiAJZG8gewog CQkvKgogCQkgKiB3YWxrIGRvd24gbGVmdCBzaWRlIG9mIGJ0cmVlLCByZWxlYXNl IGJ1ZmZlcnMgYXMgeW91CkBAIC0xMjE5LDcgKzEyMTUsNyBAQAogICoKICAqIHRo aXMgcm91dGluZSBjYW4gTk9UIGJlIGNhbGxlZCBpZiBydW5uaW5nIGluIG5vIG1v ZGlmeSBtb2RlCiAgKi8KLWludAorc3RhdGljIGludAogcHJ1bmVfbGZfZGlyX2Vu dHJ5KHhmc19tb3VudF90ICptcCwgeGZzX2lub190IGlubywgeGZzX2lub2RlX3Qg KmlwLAogCQkJeGZzX2RhaGFzaF90ICpoYXNodmFsKQogewpAQCAtMTQxNCwxNCAr MTQxMCwxMyBAQAogICogcHJvY2VzcyBhIGxlYWYgYmxvY2ssIGFsc28gY2hlY2tz IGZvciAuLiBlbnRyeQogICogYW5kIGNvcnJlY3RzIGl0IHRvIG1hdGNoIHdoYXQg d2UgdGhpbmsgLi4gc2hvdWxkIGJlCiAgKi8KLXZvaWQKK3N0YXRpYyB2b2lkCiBs Zl9ibG9ja19kaXJfZW50cnlfY2hlY2soeGZzX21vdW50X3QJCSptcCwKIAkJCXhm c19pbm9fdAkJaW5vLAogCQkJeGZzX2Rpcl9sZWFmYmxvY2tfdAkqbGVhZiwKIAkJ CWludAkJCSpkaXJ0eSwKIAkJCWludAkJCSpudW1faWxsZWdhbCwKIAkJCWludAkJ CSpuZWVkX2RvdCwKLQkJCWRpcl9zdGFja190CQkqc3RhY2ssCiAJCQlpbm9fdHJl ZV9ub2RlX3QJCSpjdXJyZW50X2lyZWMsCiAJCQlpbnQJCQljdXJyZW50X2lub19v ZmZzZXQsCiAJCQlkaXJfaGFzaF90YWJfdAkJKmhhc2h0YWIsCkBAIC0xNjE0LDkg KzE2MDksNiBAQAogCQl9IGVsc2UgaWYgKHBhcmVudCA9PSBpbm8pICB7CiAJCQlh ZGRfaW5vZGVfcmVhY2hlZChpcmVjLCBpbm9fb2Zmc2V0KTsKIAkJCWFkZF9pbm9k ZV9yZWYoY3VycmVudF9pcmVjLCBjdXJyZW50X2lub19vZmZzZXQpOwotCi0JCQlp ZiAoIWRvX3ByZWZldGNoICYmICFpc19pbm9kZV9yZWZjaGVja2VkKGxpbm8sIGly ZWMsIGlub19vZmZzZXQpKQotCQkJCXB1c2hfZGlyKHN0YWNrLCBsaW5vKTsKIAkJ fSBlbHNlICB7CiAJCQlqdW5raXQgPSAxOwogCQkJZG9fd2FybigKQEAgLTE2NTAs MTMgKzE2NDIsMTIgQEAKICAqIGhhcHBlbiBpbiBmaWxlIGJsb2Nrcy4gIHRoZSBp bm9kZSBzaXplIGFuZCBvdGhlciBjb3JlIGluZm8KICAqIGlzIGFscmVhZHkgY29y cmVjdCwgaXQncyBqdXN0IHRoZSBsZWFmIGVudHJpZXMgdGhhdCBnZXQgYWx0ZXJl ZC4KICAqLwotdm9pZAorc3RhdGljIHZvaWQKIGxvbmdmb3JtX2Rpcl9lbnRyeV9j aGVjayh4ZnNfbW91bnRfdAkqbXAsCiAJCQl4ZnNfaW5vX3QJaW5vLAogCQkJeGZz X2lub2RlX3QJKmlwLAogCQkJaW50CQkqbnVtX2lsbGVnYWwsCiAJCQlpbnQJCSpu ZWVkX2RvdCwKLQkJCWRpcl9zdGFja190CSpzdGFjaywKIAkJCWlub190cmVlX25v ZGVfdAkqaXJlYywKIAkJCWludAkJaW5vX29mZnNldCwKIAkJCWRpcl9oYXNoX3Rh Yl90CSpoYXNodGFiKQpAQCAtMTcyMiw3ICsxNzEzLDcgQEAKIAogCQlpZiAoIXNr aXBpdCkKIAkJCWxmX2Jsb2NrX2Rpcl9lbnRyeV9jaGVjayhtcCwgaW5vLCBsZWFm LCAmZGlydHksCi0JCQkJCW51bV9pbGxlZ2FsLCBuZWVkX2RvdCwgc3RhY2ssIGly ZWMsCisJCQkJCW51bV9pbGxlZ2FsLCBuZWVkX2RvdCwgaXJlYywKIAkJCQkJaW5v X29mZnNldCwgaGFzaHRhYiwgZGFfYm5vKTsKIAogCQlkYV9ibm8gPSBJTlRfR0VU KGxlYWYtPmhkci5pbmZvLmZvcncsIEFSQ0hfQ09OVkVSVCk7CkBAIC0xNzg2LDgg KzE3NzcsNyBAQAogCXhmc19maWxlb2ZmX3QJCWxhc3RibG9jazsKIAl4ZnNfZnNi bG9ja190CQlmaXJzdGJsb2NrOwogCXhmc19ibWFwX2ZyZWVfdAkJZmxpc3Q7Ci0J eGZzX2lub190CQlwYXJlbnRpbm87Ci0JeGZzX2lub2RlX3QJCSpwaXA7CisJeGZz X2lub2RlX3QJCXBpcDsKIAlpbnQJCQlieWhhc2g7CiAJZGlyX2hhc2hfZW50X3QJ CSpwOwogCWludAkJCWNvbW1pdHRlZDsKQEAgLTE4MDIsMTMgKzE3OTIsMTUgQEAK IAogCS8qCiAJICogZmlyc3QgYXR0ZW1wdCB0byBsb2NhdGUgdGhlIHBhcmVudCBp bm9kZSwgaWYgaXQgY2FuJ3QgYmUgZm91bmQsCi0JICogd2UnbGwgdXNlIHRoZSBs b3N0K2ZvdW5kIGlub2RlCisJICogc2V0IGl0IHRvIHRoZSByb290IGlub2RlIGFu ZCBpdCdsbCBiZSBhZGp1c3RlZCBvciBmaXhlZCBsYXRlcgorCSAqIGlmIGluY29y cmVjdCAodGhlIGlub2RlIG51bWJlciBoZXJlIG5lZWRzIHRvIGJlIHZhbGlkIGZv ciB0aGUKKwkgKiBsaWJ4ZnNfZGlyMl9pbml0KCkgY2FsbCkuCiAJICovCiAJYnlo YXNoID0gRElSX0hBU0hfRlVOQyhoYXNodGFiLCBsaWJ4ZnNfZGFfaGFzaG5hbWUo KHVjaGFyX3QqKSIuLiIsIDIpKTsKLQlwYXJlbnRpbm8gPSBvcnBoYW5hZ2VfaW5v OworCXBpcC5pX2lubyA9IG1wLT5tX3NiLnNiX3Jvb3Rpbm87CiAJZm9yIChwID0g aGFzaHRhYi0+YnloYXNoW2J5aGFzaF07IHA7IHAgPSBwLT5uZXh0YnloYXNoKSB7 CiAJCWlmIChwLT5uYW1lbGVuID09IDIgJiYgcC0+bmFtZVswXSA9PSAnLicgJiYg cC0+bmFtZVsxXSA9PSAnLicpIHsKLQkJCXBhcmVudGlubyA9IHAtPmludW07CisJ CQlwaXAuaV9pbm8gPSBwLT5pbnVtOwogCQkJYnJlYWs7CiAJCX0KIAl9CkBAIC0x ODI5LDE5ICsxODIxLDYgQEAKIAkJZG9fZXJyb3IoXygieGZzX2JtYXBfbGFzdF9v ZmZzZXQgZmFpbGVkIC0tIGVycm9yIC0gJWRcbiIpLAogCQkJZXJyb3IpOwogCi0J LyogcmUtaW5pdCB0aGUgZGlyZWN0b3J5IHRvIHNob3J0Zm9ybSAqLwotCWlmICgo ZXJyb3IgPSBsaWJ4ZnNfdHJhbnNfaWdldChtcCwgdHAsIHBhcmVudGlubywgMCwg MCwgJnBpcCkpKSB7Ci0JCWRvX3dhcm4oCi0JCV8oImNvdWxkbid0IGlnZXQgcGFy ZW50IGlub2RlICVsbHUgLS0gZXJyb3IgLSAlZFxuIiksCi0JCQlwYXJlbnRpbm8s IGVycm9yKTsKLQkJLyogd2UnbGwgdHJ5IHRvIHVzZSB0aGUgb3JwaGFuYWdlIGlu byB0aGVuICovCi0JCXBhcmVudGlubyA9IG9ycGhhbmFnZV9pbm87Ci0JCWlmICgo ZXJyb3IgPSBsaWJ4ZnNfdHJhbnNfaWdldChtcCwgdHAsIHBhcmVudGlubywgMCwg MCwgJnBpcCkpKQotCQkJZG9fZXJyb3IoCi0JCV8oImNvdWxkbid0IGlnZXQgbG9z dCtmb3VuZCBpbm9kZSAlbGx1IC0tIGVycm9yIC0gJWRcbiIpLAotCQkJCXBhcmVu dGlubywgZXJyb3IpOwotCX0KLQogCS8qIGZyZWUgYWxsIGRhdGEsIGxlYWYsIG5v ZGUgYW5kIGZyZWVzcGFjZSBibG9ja3MgKi8KIAogCWlmICgoZXJyb3IgPSBsaWJ4 ZnNfYnVubWFwaSh0cCwgaXAsIDAsIGxhc3RibG9jaywKQEAgLTE4NTUsNyArMTgz NCw3IEBACiAKIAlBU1NFUlQoZG9uZSk7CiAKLQlsaWJ4ZnNfZGlyMl9pbml0KHRw LCBpcCwgcGlwKTsKKwlsaWJ4ZnNfZGlyMl9pbml0KHRwLCBpcCwgJnBpcCk7CiAK IAllcnJvciA9IGxpYnhmc19ibWFwX2ZpbmlzaCgmdHAsICZmbGlzdCwgZmlyc3Ri bG9jaywgJmNvbW1pdHRlZCk7CiAKQEAgLTE5NzEsNyArMTk1MCw2IEBACiAJeGZz X2lub2RlX3QJCSppcCwKIAlpbnQJCQkqbnVtX2lsbGVnYWwsCiAJaW50CQkJKm5l ZWRfZG90LAotCWRpcl9zdGFja190CQkqc3RhY2ssCiAJaW5vX3RyZWVfbm9kZV90 CQkqY3VycmVudF9pcmVjLAogCWludAkJCWN1cnJlbnRfaW5vX29mZnNldCwKIAl4 ZnNfZGFidWZfdAkJKipicHAsCkBAIC0yMTgyLDYgKzIxNjAsMTcgQEAKIAkJcHRy ICs9IFhGU19ESVIyX0RBVEFfRU5UU0laRShkZXAtPm5hbWVsZW4pOwogCQlpbnVt ID0gSU5UX0dFVChkZXAtPmludW1iZXIsIEFSQ0hfQ09OVkVSVCk7CiAJCWxhc3Rm cmVlID0gMDsKKwkJLyoKKwkJICogc2tpcCBib2d1cyBlbnRyaWVzIChsZWFkaW5n ICcvJykuICB0aGV5J2xsIGJlIGRlbGV0ZWQKKwkJICogbGF0ZXIuICBtdXN0IHN0 aWxsIGxvZyBpdCwgZWxzZSB3ZSBsZWFrIHJlZmVyZW5jZXMgdG8KKwkJICogYnVm ZmVycy4KKwkJICovCisJCWlmIChkZXAtPm5hbWVbMF0gPT0gJy8nKSAgeworCQkJ bmJhZCsrOworCQkJaWYgKCFub19tb2RpZnkpCisJCQkJbGlieGZzX2RpcjJfZGF0 YV9sb2dfZW50cnkodHAsIGJwLCBkZXApOworCQkJY29udGludWU7CisJCX0KIAog CQlpcmVjID0gZmluZF9pbm9kZV9yZWMoWEZTX0lOT19UT19BR05PKG1wLCBpbnVt KSwKIAkJCQkJWEZTX0lOT19UT19BR0lOTyhtcCwgaW51bSkpOwpAQCAtMjI1Miwx NyArMjI0MSw3IEBACiAJCQl9CiAJCQljb250aW51ZTsKIAkJfQotCQkvKgotCQkg KiBza2lwIGJvZ3VzIGVudHJpZXMgKGxlYWRpbmcgJy8nKS4gIHRoZXknbGwgYmUg ZGVsZXRlZAotCQkgKiBsYXRlci4gIG11c3Qgc3RpbGwgbG9nIGl0LCBlbHNlIHdl IGxlYWsgcmVmZXJlbmNlcyB0bwotCQkgKiBidWZmZXJzLgotCQkgKi8KLQkJaWYg KGRlcC0+bmFtZVswXSA9PSAnLycpICB7Ci0JCQluYmFkKys7Ci0JCQlpZiAoIW5v X21vZGlmeSkKLQkJCQlsaWJ4ZnNfZGlyMl9kYXRhX2xvZ19lbnRyeSh0cCwgYnAs IGRlcCk7Ci0JCQljb250aW51ZTsKLQkJfQorCiAJCWp1bmtpdCA9IDA7CiAJCWJj b3B5KGRlcC0+bmFtZSwgZm5hbWUsIGRlcC0+bmFtZWxlbik7CiAJCWZuYW1lW2Rl cC0+bmFtZWxlbl0gPSAnXDAnOwpAQCAtMjMyMiw4ICsyMzAxLDYgQEAKIAkJfSBl bHNlIGlmIChwYXJlbnQgPT0gaXAtPmlfaW5vKSAgewogCQkJYWRkX2lub2RlX3Jl YWNoZWQoaXJlYywgaW5vX29mZnNldCk7CiAJCQlhZGRfaW5vZGVfcmVmKGN1cnJl bnRfaXJlYywgY3VycmVudF9pbm9fb2Zmc2V0KTsKLQkJCWlmICghZG9fcHJlZmV0 Y2ggJiYgIWlzX2lub2RlX3JlZmNoZWNrZWQoaW51bSwgaXJlYywgaW5vX29mZnNl dCkpCi0JCQkJcHVzaF9kaXIoc3RhY2ssIGludW0pOwogCQl9IGVsc2UgIHsKIAkJ CWp1bmtpdCA9IDE7CiAJCQlkb193YXJuKApAQCAtMjM2MCw3ICsyMzM3LDcgQEAK IC8qCiAgKiBDaGVjayBjb250ZW50cyBvZiBsZWFmLWZvcm0gYmxvY2suCiAgKi8K LWludAorc3RhdGljIGludAogbG9uZ2Zvcm1fZGlyMl9jaGVja19sZWFmKAogCXhm c19tb3VudF90CQkqbXAsCiAJeGZzX2lub2RlX3QJCSppcCwKQEAgLTI0MjcsNyAr MjQwNCw3IEBACiAgKiBDaGVjayBjb250ZW50cyBvZiB0aGUgbm9kZSBibG9ja3Mg KGxlYXZlcykKICAqIExvb2tzIGZvciBtYXRjaGluZyBoYXNoIHZhbHVlcyBmb3Ig dGhlIGRhdGEgZW50cmllcy4KICAqLwotaW50CitzdGF0aWMgaW50CiBsb25nZm9y bV9kaXIyX2NoZWNrX25vZGUoCiAJeGZzX21vdW50X3QJCSptcCwKIAl4ZnNfaW5v ZGVfdAkJKmlwLApAQCAtMjU2MCwxMyArMjUzNywxMiBAQAogICogZGVzdHJveSB0 aGUgZW50cnkgYW5kIGNyZWF0ZSBhIG5ldyBvbmUgd2l0aCByZWNvdmVyZWQgbmFt ZS9pbm9kZSBwYWlycy4KICAqIChpZS4gZ2V0IGxpYnhmcyB0byBkbyBhbGwgdGhl IGdydW50IHdvcmspCiAgKi8KLXZvaWQKK3N0YXRpYyB2b2lkCiBsb25nZm9ybV9k aXIyX2VudHJ5X2NoZWNrKHhmc19tb3VudF90CSptcCwKIAkJCXhmc19pbm9fdAlp bm8sCiAJCQl4ZnNfaW5vZGVfdAkqaXAsCiAJCQlpbnQJCSpudW1faWxsZWdhbCwK IAkJCWludAkJKm5lZWRfZG90LAotCQkJZGlyX3N0YWNrX3QJKnN0YWNrLAogCQkJ aW5vX3RyZWVfbm9kZV90CSppcmVjLAogCQkJaW50CQlpbm9fb2Zmc2V0LAogCQkJ ZGlyX2hhc2hfdGFiX3QJKmhhc2h0YWIpCkBAIC0yNjA2LDkgKzI1ODIsNiBAQAog CWxpYnhmc19kaXIyX2lzYmxvY2soTlVMTCwgaXAsICZpc2Jsb2NrKTsKIAlsaWJ4 ZnNfZGlyMl9pc2xlYWYoTlVMTCwgaXAsICZpc2xlYWYpOwogCi0JaWYgKGRvX3By ZWZldGNoICYmICFpc2Jsb2NrKQotCQlwcmVmZXRjaF9wNl9kaXIyKG1wLCBpcCk7 Ci0KIAkvKiBjaGVjayBkaXJlY3RvcnkgImRhdGEiIGJsb2NrcyAoaWUuIG5hbWUv aW5vZGUgcGFpcnMpICovCiAJZm9yIChkYV9ibm8gPSAwLCBuZXh0X2RhX2JubyA9 IDA7CiAJICAgICBuZXh0X2RhX2JubyAhPSBOVUxMRklMRU9GRiAmJiBkYV9ibm8g PCBtcC0+bV9kaXJsZWFmYmxrOwpAQCAtMjYzNSw3ICsyNjA4LDcgQEAKIAkJCWNv bnRpbnVlOwkvKiB0cnkgYW5kIHJlYWQgYWxsICJkYXRhIiBibG9ja3MgKi8KIAkJ fQogCQlsb25nZm9ybV9kaXIyX2VudHJ5X2NoZWNrX2RhdGEobXAsIGlwLCBudW1f aWxsZWdhbCwgbmVlZF9kb3QsCi0JCQkJc3RhY2ssIGlyZWMsIGlub19vZmZzZXQs ICZicGxpc3RbZGJdLCBoYXNodGFiLAorCQkJCWlyZWMsIGlub19vZmZzZXQsICZi cGxpc3RbZGJdLCBoYXNodGFiLAogCQkJCSZmcmVldGFiLCBkYV9ibm8sIGlzYmxv Y2spOwogCX0KIAlmaXhpdCA9ICgqbnVtX2lsbGVnYWwgIT0gMCkgfHwgZGlyMl9p c19iYWRpbm8oaW5vKTsKQEAgLTI2NzYsMTIgKzI2NDksMTEgQEAKICAqIHNob3J0 Zm9ybSBkaXJlY3RvcnkgcHJvY2Vzc2luZyByb3V0aW5lcyAtLSBlbnRyeSB2ZXJp ZmljYXRpb24gYW5kCiAgKiBiYWQgZW50cnkgZGVsZXRpb24gKHBydW5pbmcpLgog ICovCi12b2lkCitzdGF0aWMgdm9pZAogc2hvcnRmb3JtX2Rpcl9lbnRyeV9jaGVj ayh4ZnNfbW91bnRfdAkqbXAsCiAJCQl4ZnNfaW5vX3QJaW5vLAogCQkJeGZzX2lu b2RlX3QJKmlwLAogCQkJaW50CQkqaW5vX2RpcnR5LAotCQkJZGlyX3N0YWNrX3QJ KnN0YWNrLAogCQkJaW5vX3RyZWVfbm9kZV90CSpjdXJyZW50X2lyZWMsCiAJCQlp bnQJCWN1cnJlbnRfaW5vX29mZnNldCwKIAkJCWRpcl9oYXNoX3RhYl90CSpoYXNo dGFiKQpAQCAtMjg2OCwxMCArMjg0MCw2IEBACiAJCQl9IGVsc2UgaWYgKHBhcmVu dCA9PSBpbm8pICB7CiAJCQkJYWRkX2lub2RlX3JlYWNoZWQoaXJlYywgaW5vX29m ZnNldCk7CiAJCQkJYWRkX2lub2RlX3JlZihjdXJyZW50X2lyZWMsIGN1cnJlbnRf aW5vX29mZnNldCk7Ci0KLQkJCQlpZiAoIWRvX3ByZWZldGNoICYmICFpc19pbm9k ZV9yZWZjaGVja2VkKGxpbm8sIGlyZWMsCi0JCQkJCQlpbm9fb2Zmc2V0KSkKLQkJ CQkJcHVzaF9kaXIoc3RhY2ssIGxpbm8pOwogCQkJfSBlbHNlICB7CiAJCQkJanVu a2l0ID0gMTsKIAkJCQlkb193YXJuKF8oImVudHJ5IFwiJXNcIiBpbiBkaXIgJWxs dSBub3QgIgpAQCAtMjk2NCw3ICsyOTMyLDcgQEAKIH0KIAogLyogQVJHU1VTRUQg Ki8KLXZvaWQKK3N0YXRpYyB2b2lkCiBwcnVuZV9zZl9kaXJfZW50cnkoeGZzX21v dW50X3QgKm1wLCB4ZnNfaW5vX3QgaW5vLCB4ZnNfaW5vZGVfdCAqaXApCiB7CiAJ CQkJLyogUkVGRVJFTkNFRCAqLwpAQCAtMzA2MSwxMiArMzAyOSwxMSBAQAogICog c2hvcnRmb3JtIGRpcmVjdG9yeSB2MiBwcm9jZXNzaW5nIHJvdXRpbmVzIC0tIGVu dHJ5IHZlcmlmaWNhdGlvbiBhbmQKICAqIGJhZCBlbnRyeSBkZWxldGlvbiAocHJ1 bmluZykuCiAgKi8KLXZvaWQKK3N0YXRpYyB2b2lkCiBzaG9ydGZvcm1fZGlyMl9l bnRyeV9jaGVjayh4ZnNfbW91bnRfdAkqbXAsCiAJCQl4ZnNfaW5vX3QJaW5vLAog CQkJeGZzX2lub2RlX3QJKmlwLAogCQkJaW50CQkqaW5vX2RpcnR5LAotCQkJZGly X3N0YWNrX3QJKnN0YWNrLAogCQkJaW5vX3RyZWVfbm9kZV90CSpjdXJyZW50X2ly ZWMsCiAJCQlpbnQJCWN1cnJlbnRfaW5vX29mZnNldCwKIAkJCWRpcl9oYXNoX3Rh Yl90CSpoYXNodGFiKQpAQCAtMzI2MywxMCArMzIzMCw2IEBACiAJCQl9IGVsc2Ug aWYgKHBhcmVudCA9PSBpbm8pICB7CiAJCQkJYWRkX2lub2RlX3JlYWNoZWQoaXJl YywgaW5vX29mZnNldCk7CiAJCQkJYWRkX2lub2RlX3JlZihjdXJyZW50X2lyZWMs IGN1cnJlbnRfaW5vX29mZnNldCk7Ci0KLQkJCQlpZiAoIWRvX3ByZWZldGNoICYm ICFpc19pbm9kZV9yZWZjaGVja2VkKGxpbm8sIGlyZWMsCi0JCQkJCQlpbm9fb2Zm c2V0KSkKLQkJCQkJcHVzaF9kaXIoc3RhY2ssIGxpbm8pOwogCQkJfSBlbHNlICB7 CiAJCQkJanVua2l0ID0gMTsKIAkJCQlkb193YXJuKF8oImVudHJ5IFwiJXNcIiBp biBkaXJlY3RvcnkgaW5vZGUgJWxsdSIKQEAgLTMzNzcsODcgKzMzNDAsNzggQEAK IH0KIAogLyoKLSAqIHByb2Nlc3NlcyBhbGwgZGlyZWN0b3JpZXMgcmVhY2hhYmxl IHZpYSB0aGUgaW5vZGVzIG9uIHRoZSBzdGFjawotICogcmV0dXJucyAwIGlmIHRo aW5ncyBhcmUgZ29vZCwgMSBpZiB0aGVyZSdzIGEgcHJvYmxlbQorICogcHJvY2Vz c2VzIGFsbCByZWFjaGFibGUgaW5vZGVzIGluIGRpcmVjdG9yaWVzCiAgKi8KLXZv aWQKLXByb2Nlc3NfZGlyc3RhY2soeGZzX21vdW50X3QgKm1wLCBkaXJfc3RhY2tf dCAqc3RhY2spCitzdGF0aWMgdm9pZAorcHJvY2Vzc19kaXJfaW5vZGUoCisJeGZz X21vdW50X3QgCQkqbXAsCisJeGZzX2lub190CQlpbm8sCisJaW5vX3RyZWVfbm9k ZV90CQkqaXJlYywKKwlpbnQJCQlpbm9fb2Zmc2V0KQogewogCXhmc19ibWFwX2Zy ZWVfdAkJZmxpc3Q7CiAJeGZzX2ZzYmxvY2tfdAkJZmlyc3Q7Ci0JeGZzX2lub190 CQlpbm87CiAJeGZzX2lub2RlX3QJCSppcDsKIAl4ZnNfdHJhbnNfdAkJKnRwOwog CXhmc19kYWhhc2hfdAkJaGFzaHZhbDsKLQlpbm9fdHJlZV9ub2RlX3QJCSppcmVj OwogCWRpcl9oYXNoX3RhYl90CQkqaGFzaHRhYjsKLQlpbnQJCQlpbm9fb2Zmc2V0 LCBuZWVkX2RvdCwgY29tbWl0dGVkOworCWludAkJCW5lZWRfZG90LCBjb21taXR0 ZWQ7CiAJaW50CQkJZGlydHksIG51bV9pbGxlZ2FsLCBlcnJvciwgbnJlczsKIAog CS8qCi0JICogcHVsbCBkaXJlY3RvcnkgaW5vZGUgIyBvZmYgZGlyZWN0b3J5IHN0 YWNrCi0JICoKIAkgKiBvcGVuIHVwIGRpcmVjdG9yeSBpbm9kZSwgY2hlY2sgYWxs IGVudHJpZXMsCiAJICogdGhlbiBjYWxsIHBydW5lX2Rpcl9lbnRyaWVzIHRvIHJl bW92ZSBhbGwKIAkgKiByZW1haW5pbmcgaWxsZWdhbCBkaXJlY3RvcnkgZW50cmll cy4KIAkgKi8KIAotCXdoaWxlICgoaW5vID0gcG9wX2RpcihzdGFjaykpICE9IE5V TExGU0lOTykgIHsKLQkJaXJlYyA9IGZpbmRfaW5vZGVfcmVjKFhGU19JTk9fVE9f QUdOTyhtcCwgaW5vKSwKLQkJCQkJWEZTX0lOT19UT19BR0lOTyhtcCwgaW5vKSk7 Ci0JCUFTU0VSVChpcmVjICE9IE5VTEwpOwotCi0JCWlub19vZmZzZXQgPSBYRlNf SU5PX1RPX0FHSU5PKG1wLCBpbm8pIC0gaXJlYy0+aW5vX3N0YXJ0bnVtOwotCi0J CUFTU0VSVCghaXNfaW5vZGVfcmVmY2hlY2tlZChpbm8sIGlyZWMsIGlub19vZmZz ZXQpKTsKLQotCQlpZiAoKGVycm9yID0gbGlieGZzX2lnZXQobXAsIE5VTEwsIGlu bywgMCwgJmlwLCAwKSkpIHsKLQkJCWlmICghbm9fbW9kaWZ5KQotCQkJCWRvX2Vy cm9yKAotCQkJCV8oImNvdWxkbid0IG1hcCBpbm9kZSAlbGx1LCBlcnIgPSAlZFxu IiksCi0JCQkJCWlubywgZXJyb3IpOwotCQkJZWxzZSAgewotCQkJCWRvX3dhcm4o Ci0JCQkJXygiY291bGRuJ3QgbWFwIGlub2RlICVsbHUsIGVyciA9ICVkXG4iKSwK LQkJCQkJaW5vLCBlcnJvcik7Ci0JCQkJLyoKLQkJCQkgKiBzZWUgYmVsb3cgZm9y IHdoYXQgd2UncmUgZG9pbmcgaWYgdGhpcwotCQkJCSAqIGlzIHJvb3QuICBXaHkg ZG8gd2UgbmVlZCB0byBkbyB0aGlzIGhlcmU/Ci0JCQkJICogdG8gZW5zdXJlIHRo YXQgdGhlIHJvb3QgZG9lc24ndCBzaG93IHVwCi0JCQkJICogYXMgYmVpbmcgZGlz Y29ubmVjdGVkIGluIHRoZSBub19tb2RpZnkgY2FzZS4KLQkJCQkgKi8KLQkJCQlp ZiAobXAtPm1fc2Iuc2Jfcm9vdGlubyA9PSBpbm8pICB7Ci0JCQkJCWFkZF9pbm9k ZV9yZWFjaGVkKGlyZWMsIDApOwotCQkJCQlhZGRfaW5vZGVfcmVmKGlyZWMsIDAp OwotCQkJCX0KLQkJCX0KKwlBU1NFUlQoIWlzX2lub2RlX3JlZmNoZWNrZWQoaW5v LCBpcmVjLCBpbm9fb2Zmc2V0KSk7CiAKLQkJCWFkZF9pbm9kZV9yZWZjaGVja2Vk KGlubywgaXJlYywgMCk7Ci0JCQljb250aW51ZTsKLQkJfQotCi0JCW5lZWRfZG90 ID0gZGlydHkgPSBudW1faWxsZWdhbCA9IDA7Ci0KLQkJaWYgKG1wLT5tX3NiLnNi X3Jvb3Rpbm8gPT0gaW5vKSAgeworCWVycm9yID0gbGlieGZzX2lnZXQobXAsIE5V TEwsIGlubywgMCwgJmlwLCAwKTsKKwlpZiAoZXJyb3IpIHsKKwkJaWYgKCFub19t b2RpZnkpCisJCQlkb19lcnJvcihfKCJjb3VsZG4ndCBtYXAgaW5vZGUgJWxsdSwg ZXJyID0gJWRcbiIpLAorCQkJCWlubywgZXJyb3IpOworCQllbHNlICB7CisJCQlk b193YXJuKF8oImNvdWxkbid0IG1hcCBpbm9kZSAlbGx1LCBlcnIgPSAlZFxuIiks CisJCQkJaW5vLCBlcnJvcik7CiAJCQkvKgotCQkJICogbWFyayByb290IGlub2Rl IHJlYWNoZWQgYW5kIGJ1bXAgdXAKLQkJCSAqIGxpbmsgY291bnQgZm9yIHJvb3Qg aW5vZGUgdG8gYWNjb3VudAotCQkJICogZm9yICcuLicgZW50cnkgc2luY2UgdGhl IHJvb3QgaW5vZGUgaXMKLQkJCSAqIG5ldmVyIHJlYWNoZWQgYnkgYSBwYXJlbnQu ICB3ZSBrbm93Ci0JCQkgKiB0aGF0IHJvb3QncyAnLi4nIGlzIGFsd2F5cyBnb29k IC0tCi0JCQkgKiBndWFyYW50ZWVkIGJ5IHBoYXNlIDMgYW5kL29yIGJlbG93Lgor CQkJICogc2VlIGJlbG93IGZvciB3aGF0IHdlJ3JlIGRvaW5nIGlmIHRoaXMKKwkJ CSAqIGlzIHJvb3QuICBXaHkgZG8gd2UgbmVlZCB0byBkbyB0aGlzIGhlcmU/CisJ CQkgKiB0byBlbnN1cmUgdGhhdCB0aGUgcm9vdCBkb2Vzbid0IHNob3cgdXAKKwkJ CSAqIGFzIGJlaW5nIGRpc2Nvbm5lY3RlZCBpbiB0aGUgbm9fbW9kaWZ5IGNhc2Uu CiAJCQkgKi8KLQkJCWFkZF9pbm9kZV9yZWFjaGVkKGlyZWMsIGlub19vZmZzZXQp OworCQkJaWYgKG1wLT5tX3NiLnNiX3Jvb3Rpbm8gPT0gaW5vKSAgeworCQkJCWFk ZF9pbm9kZV9yZWFjaGVkKGlyZWMsIDApOworCQkJCWFkZF9pbm9kZV9yZWYoaXJl YywgMCk7CisJCQl9CiAJCX0KIAotCQlhZGRfaW5vZGVfcmVmY2hlY2tlZChpbm8s IGlyZWMsIGlub19vZmZzZXQpOworCQlhZGRfaW5vZGVfcmVmY2hlY2tlZChpbm8s IGlyZWMsIDApOworCQlyZXR1cm47CisJfQogCi0JCWhhc2h0YWIgPSBkaXJfaGFz aF9pbml0KGlwLT5pX2QuZGlfc2l6ZSk7CisJbmVlZF9kb3QgPSBkaXJ0eSA9IG51 bV9pbGxlZ2FsID0gMDsKIAorCWlmIChtcC0+bV9zYi5zYl9yb290aW5vID09IGlu bykgIHsKIAkJLyoKLQkJICogbG9vayBmb3IgYm9ndXMgZW50cmllcworCQkgKiBt YXJrIHJvb3QgaW5vZGUgcmVhY2hlZCBhbmQgYnVtcCB1cAorCQkgKiBsaW5rIGNv dW50IGZvciByb290IGlub2RlIHRvIGFjY291bnQKKwkJICogZm9yICcuLicgZW50 cnkgc2luY2UgdGhlIHJvb3QgaW5vZGUgaXMKKwkJICogbmV2ZXIgcmVhY2hlZCBi eSBhIHBhcmVudC4gIHdlIGtub3cKKwkJICogdGhhdCByb290J3MgJy4uJyBpcyBh bHdheXMgZ29vZCAtLQorCQkgKiBndWFyYW50ZWVkIGJ5IHBoYXNlIDMgYW5kL29y IGJlbG93LgogCQkgKi8KLQkJc3dpdGNoIChpcC0+aV9kLmRpX2Zvcm1hdCkgIHsK KwkJYWRkX2lub2RlX3JlYWNoZWQoaXJlYywgaW5vX29mZnNldCk7CisJfQorCisJ YWRkX2lub2RlX3JlZmNoZWNrZWQoaW5vLCBpcmVjLCBpbm9fb2Zmc2V0KTsKKwor CWhhc2h0YWIgPSBkaXJfaGFzaF9pbml0KGlwLT5pX2QuZGlfc2l6ZSk7CisKKwkv KgorCSAqIGxvb2sgZm9yIGJvZ3VzIGVudHJpZXMKKwkgKi8KKwlzd2l0Y2ggKGlw LT5pX2QuZGlfZm9ybWF0KSAgewogCQljYXNlIFhGU19ESU5PREVfRk1UX0VYVEVO VFM6CiAJCWNhc2UgWEZTX0RJTk9ERV9GTVRfQlRSRUU6CiAJCQkvKgpAQCAtMzQ2 OSwxNiArMzQyMywxNSBAQAogCQkJaWYgKFhGU19TQl9WRVJTSU9OX0hBU0RJUlYy KCZtcC0+bV9zYikpCiAJCQkJbG9uZ2Zvcm1fZGlyMl9lbnRyeV9jaGVjayhtcCwg aW5vLCBpcCwKIAkJCQkJCQkmbnVtX2lsbGVnYWwsICZuZWVkX2RvdCwKLQkJCQkJ CQlzdGFjaywgaXJlYywKLQkJCQkJCQlpbm9fb2Zmc2V0LAorCQkJCQkJCWlyZWMs IGlub19vZmZzZXQsCiAJCQkJCQkJaGFzaHRhYik7CiAJCQllbHNlCiAJCQkJbG9u Z2Zvcm1fZGlyX2VudHJ5X2NoZWNrKG1wLCBpbm8sIGlwLAogCQkJCQkJCSZudW1f aWxsZWdhbCwgJm5lZWRfZG90LAotCQkJCQkJCXN0YWNrLCBpcmVjLAotCQkJCQkJ CWlub19vZmZzZXQsCisJCQkJCQkJaXJlYywgaW5vX29mZnNldCwKIAkJCQkJCQlo YXNodGFiKTsKIAkJCWJyZWFrOworCiAJCWNhc2UgWEZTX0RJTk9ERV9GTVRfTE9D QUw6CiAJCQl0cCA9IGxpYnhmc190cmFuc19hbGxvYyhtcCwgMCk7CiAJCQkvKgpA QCAtMzUwMCw1MiArMzQ1MywxNjcgQEAKIAogCQkJaWYgKFhGU19TQl9WRVJTSU9O X0hBU0RJUlYyKCZtcC0+bV9zYikpCiAJCQkJc2hvcnRmb3JtX2RpcjJfZW50cnlf Y2hlY2sobXAsIGlubywgaXAsICZkaXJ0eSwKLQkJCQkJCQlzdGFjaywgaXJlYywK LQkJCQkJCQlpbm9fb2Zmc2V0LAorCQkJCQkJCWlyZWMsIGlub19vZmZzZXQsCiAJ CQkJCQkJaGFzaHRhYik7CiAJCQllbHNlCiAJCQkJc2hvcnRmb3JtX2Rpcl9lbnRy eV9jaGVjayhtcCwgaW5vLCBpcCwgJmRpcnR5LAotCQkJCQkJCXN0YWNrLCBpcmVj LAotCQkJCQkJCWlub19vZmZzZXQsCisJCQkJCQkJaXJlYywgaW5vX29mZnNldCwK IAkJCQkJCQloYXNodGFiKTsKIAogCQkJQVNTRVJUKGRpcnR5ID09IDAgfHwgKGRp cnR5ICYmICFub19tb2RpZnkpKTsKIAkJCWlmIChkaXJ0eSkgIHsKIAkJCQlsaWJ4 ZnNfdHJhbnNfbG9nX2lub2RlKHRwLCBpcCwKIAkJCQkJWEZTX0lMT0dfQ09SRSB8 IFhGU19JTE9HX0REQVRBKTsKLQkJCQlsaWJ4ZnNfdHJhbnNfY29tbWl0KHRwLCBY RlNfVFJBTlNfUkVMRUFTRV9MT0dfUkVTCi0JCQkJCQl8WEZTX1RSQU5TX1NZTkMs IDApOworCQkJCWxpYnhmc190cmFuc19jb21taXQodHAsCisJCQkJCVhGU19UUkFO U19SRUxFQVNFX0xPR19SRVMgfAorCQkJCQlYRlNfVFJBTlNfU1lOQywgMCk7CiAJ CQl9IGVsc2UgIHsKLQkJCQlsaWJ4ZnNfdHJhbnNfY2FuY2VsKHRwLCBYRlNfVFJB TlNfUkVMRUFTRV9MT0dfUkVTKTsKKwkJCQlsaWJ4ZnNfdHJhbnNfY2FuY2VsKHRw LAorCQkJCQlYRlNfVFJBTlNfUkVMRUFTRV9MT0dfUkVTKTsKIAkJCX0KIAkJCWJy ZWFrOworCiAJCWRlZmF1bHQ6CiAJCQlicmVhazsKLQkJfQotCQlkaXJfaGFzaF9k b25lKGhhc2h0YWIpOworCX0KKwlkaXJfaGFzaF9kb25lKGhhc2h0YWIpOworCisJ aGFzaHZhbCA9IDA7CisKKwkvKgorCSAqIGlmIHdlIGhhdmUgdG8gY3JlYXRlIGEg Li4gZm9yIC8sIGRvIGl0IG5vdyAqYmVmb3JlKgorCSAqIHdlIGRlbGV0ZSB0aGUg Ym9ndXMgZW50cmllcywgb3RoZXJ3aXNlIHRoZSBkaXJlY3RvcnkKKwkgKiBjb3Vs ZCB0cmFuc2Zvcm0gaW50byBhIHNob3J0Zm9ybSBkaXIgd2hpY2ggd291bGQKKwkg KiBwcm9iYWJseSBjYXVzZSB0aGUgc2ltdWxhdGlvbiB0byBjaG9rZS4gIEV2ZW4K KwkgKiBpZiB0aGUgaWxsZWdhbCBlbnRyaWVzIGdldCBzaGlmdGVkIGFyb3VuZCwg aXQncyBvaworCSAqIGJlY2F1c2UgdGhlIGVudHJpZXMgYXJlIHN0cnVjdHVyYWxs eSBpbnRhY3QgYW5kIGluCisJICogaW4gaGFzaC12YWx1ZSBvcmRlciBzbyB0aGUg c2ltdWxhdGlvbiB3b24ndCBnZXQgY29uZnVzZWQKKwkgKiBpZiBpdCBoYXMgdG8g bW92ZSB0aGVtIGFyb3VuZC4KKwkgKi8KKwlpZiAoIW5vX21vZGlmeSAmJiBuZWVk X3Jvb3RfZG90ZG90ICYmIGlubyA9PSBtcC0+bV9zYi5zYl9yb290aW5vKSAgewor CQlBU1NFUlQoaXAtPmlfZC5kaV9mb3JtYXQgIT0gWEZTX0RJTk9ERV9GTVRfTE9D QUwpOwogCi0JCWhhc2h2YWwgPSAwOworCQlkb193YXJuKF8oInJlY3JlYXRpbmcg cm9vdCBkaXJlY3RvcnkgLi4gZW50cnlcbiIpKTsKKworCQl0cCA9IGxpYnhmc190 cmFuc19hbGxvYyhtcCwgMCk7CisJCUFTU0VSVCh0cCAhPSBOVUxMKTsKKworCQlu cmVzID0gWEZTX01LRElSX1NQQUNFX1JFUyhtcCwgMik7CisJCWVycm9yID0gbGli eGZzX3RyYW5zX3Jlc2VydmUodHAsIG5yZXMsIFhGU19NS0RJUl9MT0dfUkVTKG1w KSwKKwkJCQkwLCBYRlNfVFJBTlNfUEVSTV9MT0dfUkVTLCBYRlNfTUtESVJfTE9H X0NPVU5UKTsKKwkJaWYgKGVycm9yKQorCQkJcmVzX2ZhaWxlZChlcnJvcik7CisK KwkJbGlieGZzX3RyYW5zX2lqb2luKHRwLCBpcCwgMCk7CisJCWxpYnhmc190cmFu c19paG9sZCh0cCwgaXApOworCisJCVhGU19CTUFQX0lOSVQoJmZsaXN0LCAmZmly c3QpOworCisJCWVycm9yID0gZGlyX2NyZWF0ZW5hbWUobXAsIHRwLCBpcCwgIi4u IiwgMiwgaXAtPmlfaW5vLCAmZmlyc3QsCisJCQkJJmZsaXN0LCBucmVzKTsKKwkJ aWYgKGVycm9yKQorCQkJZG9fZXJyb3IoXygiY2FuJ3QgbWFrZSBcIi4uXCIgZW50 cnkgaW4gcm9vdCBpbm9kZSAiCisJCQkJIiVsbHUsIGNyZWF0ZW5hbWUgZXJyb3Ig JWRcbiIpLCBpbm8sIGVycm9yKTsKKworCQlsaWJ4ZnNfdHJhbnNfbG9nX2lub2Rl KHRwLCBpcCwgWEZTX0lMT0dfQ09SRSk7CisKKwkJZXJyb3IgPSBsaWJ4ZnNfYm1h cF9maW5pc2goJnRwLCAmZmxpc3QsIGZpcnN0LCAmY29tbWl0dGVkKTsKKwkJQVNT RVJUKGVycm9yID09IDApOworCQlsaWJ4ZnNfdHJhbnNfY29tbWl0KHRwLCBYRlNf VFJBTlNfUkVMRUFTRV9MT0dfUkVTIHwKKwkJCQlYRlNfVFJBTlNfU1lOQywgMCk7 CisKKwkJbmVlZF9yb290X2RvdGRvdCA9IDA7CisJfSBlbHNlIGlmIChuZWVkX3Jv b3RfZG90ZG90ICYmIGlubyA9PSBtcC0+bV9zYi5zYl9yb290aW5vKSAgeworCQlk b193YXJuKF8oIndvdWxkIHJlY3JlYXRlIHJvb3QgZGlyZWN0b3J5IC4uIGVudHJ5 XG4iKSk7CisJfQorCisJLyoKKwkgKiBkZWxldGUgYW55IGlsbGVnYWwgZW50cmll cyAtLSB3aGljaCBzaG91bGQgb25seSBleGlzdAorCSAqIGlmIHRoZSBkaXJlY3Rv cnkgaXMgYSBsb25nZm9ybSBkaXJlY3RvcnkuICBib2d1cworCSAqIHNob3J0Zm9y bSBkaXJlY3RvcnkgZW50cmllcyB3ZXJlIGRlbGV0ZWQgaW4gcGhhc2UgNC4KKwkg Ki8KKwlpZiAoIW5vX21vZGlmeSAmJiBudW1faWxsZWdhbCA+IDApICB7CisJCUFT U0VSVChpcC0+aV9kLmRpX2Zvcm1hdCAhPSBYRlNfRElOT0RFX0ZNVF9MT0NBTCk7 CisJCUFTU0VSVCghWEZTX1NCX1ZFUlNJT05fSEFTRElSVjIoJm1wLT5tX3NiKSk7 CisKKwkJd2hpbGUgKG51bV9pbGxlZ2FsID4gMCAmJiBpcC0+aV9kLmRpX2Zvcm1h dCAhPQorCQkJCVhGU19ESU5PREVfRk1UX0xPQ0FMKSAgeworCQkJcHJ1bmVfbGZf ZGlyX2VudHJ5KG1wLCBpbm8sIGlwLCAmaGFzaHZhbCk7CisJCQludW1faWxsZWdh bC0tOworCQl9CiAKIAkJLyoKLQkJICogaWYgd2UgaGF2ZSB0byBjcmVhdGUgYSAu LiBmb3IgLywgZG8gaXQgbm93ICpiZWZvcmUqCi0JCSAqIHdlIGRlbGV0ZSB0aGUg Ym9ndXMgZW50cmllcywgb3RoZXJ3aXNlIHRoZSBkaXJlY3RvcnkKLQkJICogY291 bGQgdHJhbnNmb3JtIGludG8gYSBzaG9ydGZvcm0gZGlyIHdoaWNoIHdvdWxkCi0J CSAqIHByb2JhYmx5IGNhdXNlIHRoZSBzaW11bGF0aW9uIHRvIGNob2tlLiAgRXZl bgotCQkgKiBpZiB0aGUgaWxsZWdhbCBlbnRyaWVzIGdldCBzaGlmdGVkIGFyb3Vu ZCwgaXQncyBvawotCQkgKiBiZWNhdXNlIHRoZSBlbnRyaWVzIGFyZSBzdHJ1Y3R1 cmFsbHkgaW50YWN0IGFuZCBpbgotCQkgKiBpbiBoYXNoLXZhbHVlIG9yZGVyIHNv IHRoZSBzaW11bGF0aW9uIHdvbid0IGdldCBjb25mdXNlZAotCQkgKiBpZiBpdCBo YXMgdG8gbW92ZSB0aGVtIGFyb3VuZC4KLQkJICovCi0JCWlmICghbm9fbW9kaWZ5 ICYmIG5lZWRfcm9vdF9kb3Rkb3QgJiYKLQkJCQlpbm8gPT0gbXAtPm1fc2Iuc2Jf cm9vdGlubykgIHsKLQkJCUFTU0VSVChpcC0+aV9kLmRpX2Zvcm1hdCAhPSBYRlNf RElOT0RFX0ZNVF9MT0NBTCk7CisJCSogaGFuZGxlIGNhc2Ugd2hlcmUgd2UndmUg ZGVsZXRlZCBzbyBtYW55CisJCSogZW50cmllcyB0aGF0IHRoZSBkaXJlY3Rvcnkg aGFzIGNoYW5nZWQgZnJvbQorCQkqIGEgbG9uZ2Zvcm0gdG8gYSBzaG9ydGZvcm0g ZGlyZWN0b3J5LiAgaGF2ZQorCQkqIHRvIGFsbG9jYXRlIGEgdHJhbnNhY3Rpb24g c2luY2Ugd2UncmUgd29ya2luZworCQkqIHdpdGggdGhlIGluY29yZSBkYXRhIGZv cmsuCisJCSovCisJCWlmIChudW1faWxsZWdhbCA+IDApICB7CisJCQlBU1NFUlQo aXAtPmlfZC5kaV9mb3JtYXQgPT0gWEZTX0RJTk9ERV9GTVRfTE9DQUwpOworCQkJ dHAgPSBsaWJ4ZnNfdHJhbnNfYWxsb2MobXAsIDApOworCQkJLyoKKwkJCSogdXNp bmcgdGhlIHJlbW92ZSByZXNlcnZhdGlvbiBpcyBvdmVya2lsbAorCQkJKiBzaW5j ZSBhdCBtb3N0IHdlJ2xsIG9ubHkgbmVlZCB0byBsb2cgdGhlCisJCQkqIGlub2Rl IGJ1dCBpdCdzIGVhc2llciB0aGFuIHdlZGdpbmcgYQorCQkJKiBuZXcgZGVmaW5l IGluIG91cnNlbHZlcy4gIDEwIGJsb2NrIGZzCisJCQkqIHNwYWNlIHJlc2VydmF0 aW9uIGlzIGFsc28gb3ZlcmtpbGwgYnV0CisJCQkqIHdoYXQgdGhlIGhlY2suLi4K KwkJCSovCisJCQlucmVzID0gWEZTX1JFTU9WRV9TUEFDRV9SRVMobXApOworCQkJ ZXJyb3IgPSBsaWJ4ZnNfdHJhbnNfcmVzZXJ2ZSh0cCwgbnJlcywKKwkJCQkJWEZT X1JFTU9WRV9MT0dfUkVTKG1wKSwgMCwKKwkJCQkJWEZTX1RSQU5TX1BFUk1fTE9H X1JFUywKKwkJCQkJWEZTX1JFTU9WRV9MT0dfQ09VTlQpOworCQkJaWYgKGVycm9y KQorCQkJCXJlc19mYWlsZWQoZXJyb3IpOwogCi0JCQlkb193YXJuKF8oInJlY3Jl YXRpbmcgcm9vdCBkaXJlY3RvcnkgLi4gZW50cnlcbiIpKTsKKwkJCWxpYnhmc190 cmFuc19pam9pbih0cCwgaXAsIDApOworCQkJbGlieGZzX3RyYW5zX2lob2xkKHRw LCBpcCk7CisKKwkJCXBydW5lX3NmX2Rpcl9lbnRyeShtcCwgaW5vLCBpcCk7CisK KwkJCWxpYnhmc190cmFuc19sb2dfaW5vZGUodHAsIGlwLAorCQkJCQlYRlNfSUxP R19DT1JFIHwgWEZTX0lMT0dfRERBVEEpOworCQkJQVNTRVJUKGVycm9yID09IDAp OworCQkJbGlieGZzX3RyYW5zX2NvbW1pdCh0cCwgWEZTX1RSQU5TX1JFTEVBU0Vf TE9HX1JFUworCQkJCQl8WEZTX1RSQU5TX1NZTkMsIDApOworCQl9CisJfQorCisJ LyoKKwkgKiBpZiB3ZSBuZWVkIHRvIGNyZWF0ZSB0aGUgJy4nIGVudHJ5LCBkbyBz byBvbmx5IGlmCisJICogdGhlIGRpcmVjdG9yeSBpcyBhIGxvbmdmb3JtIGRpci4g IGl0IGl0J3MgYmVlbgorCSAqIHR1cm5lZCBpbnRvIGEgc2hvcnRmb3JtIGRpciwg dGhlbiB0aGUgaW5vZGUgaXMgb2sKKwkgKiBzaW5jZSBzaG9ydGZvcm0gZGlycyBo YXZlIG5vICcuJyBlbnRyeSBhbmQgdGhlIGlub2RlCisJICogaGFzIGFscmVhZHkg YmVlbiBjb21taXR0ZWQgYnkgcHJ1bmVfbGZfZGlyX2VudHJ5KCkuCisJICovCisJ aWYgKG5lZWRfZG90KSAgeworCQkvKgorCQkgKiBidW1wIHVwIG91ciBsaW5rIGNv dW50IGJ1dCBkb24ndAorCQkgKiBidW1wIHVwIHRoZSBpbm9kZSBsaW5rIGNvdW50 LiAgY2hhbmNlcworCQkgKiBhcmUgZ29vZCB0aGF0IGV2ZW4gdGhvdWdoIHdlIGxv c3QgJy4nCisJCSAqIHRoZSBpbm9kZSBsaW5rIGNvdW50cyByZWZsZWN0ICcuJyBz bworCQkgKiBsZWF2ZSB0aGUgaW5vZGUgbGluayBjb3VudCBhbG9uZSBhbmQgaWYK KwkJICogaXQgdHVybnMgb3V0IHRvIGJlIHdyb25nLCB3ZSdsbCBjYXRjaAorCQkg KiB0aGF0IGluIHBoYXNlIDcuCisJCSAqLworCQlhZGRfaW5vZGVfcmVmKGlyZWMs IGlub19vZmZzZXQpOworCisJCWlmIChub19tb2RpZnkpICB7CisJCQlkb193YXJu KF8oIndvdWxkIGNyZWF0ZSBtaXNzaW5nIFwiLlwiIGVudHJ5IGluIGRpciBpbm8g JWxsdVxuIiksCisJCQkJaW5vKTsKKwkJfSBlbHNlIGlmIChpcC0+aV9kLmRpX2Zv cm1hdCAhPSBYRlNfRElOT0RFX0ZNVF9MT0NBTCkgIHsKKwkJCS8qCisJCQkgKiBu ZWVkIHRvIGNyZWF0ZSAuIGVudHJ5IGluIGxvbmdmb3JtIGRpci4KKwkJCSAqLwor CQkJZG9fd2FybihfKCJjcmVhdGluZyBtaXNzaW5nIFwiLlwiIGVudHJ5IGluIGRp ciBpbm8gJWxsdVxuIiksCisJCQkJaW5vKTsKIAogCQkJdHAgPSBsaWJ4ZnNfdHJh bnNfYWxsb2MobXAsIDApOwogCQkJQVNTRVJUKHRwICE9IE5VTEwpOwogCi0JCQlu cmVzID0gWEZTX01LRElSX1NQQUNFX1JFUyhtcCwgMik7CisJCQlucmVzID0gWEZT X01LRElSX1NQQUNFX1JFUyhtcCwgMSk7CiAJCQllcnJvciA9IGxpYnhmc190cmFu c19yZXNlcnZlKHRwLCBucmVzLAogCQkJCQlYRlNfTUtESVJfTE9HX1JFUyhtcCks CiAJCQkJCTAsCkBAIC0zNTYwLDEwICszNjI4LDExIEBACiAKIAkJCVhGU19CTUFQ X0lOSVQoJmZsaXN0LCAmZmlyc3QpOwogCi0JCQlpZiAoKGVycm9yID0gZGlyX2Ny ZWF0ZW5hbWUobXAsIHRwLCBpcCwgIi4uIiwgMiwKLQkJCQkJaXAtPmlfaW5vLCAm Zmlyc3QsICZmbGlzdCwgbnJlcykpKQotCQkJCWRvX2Vycm9yKAotXygiY2FuJ3Qg bWFrZSBcIi4uXCIgZW50cnkgaW4gcm9vdCBpbm9kZSAlbGx1LCBjcmVhdGVuYW1l IGVycm9yICVkXG4iKSwKKwkJCWlmICgoZXJyb3IgPSBkaXJfY3JlYXRlbmFtZSht cCwgdHAsIGlwLCAiLiIsCisJCQkJCTEsIGlwLT5pX2lubywgJmZpcnN0LCAmZmxp c3QsCisJCQkJCW5yZXMpKSkKKwkJCQlkb19lcnJvcihfKCJjYW4ndCBtYWtlIFwi LlwiIGVudHJ5IGluIGRpciBpbm8gIgorCQkJCQkiJWxsdSwgY3JlYXRlbmFtZSBl cnJvciAlZFxuIiksCiAJCQkJCWlubywgZXJyb3IpOwogCiAJCQlsaWJ4ZnNfdHJh bnNfbG9nX2lub2RlKHRwLCBpcCwgWEZTX0lMT0dfQ09SRSk7CkBAIC0zNTczLDEz NSArMzY0MiwxMCBAQAogCQkJQVNTRVJUKGVycm9yID09IDApOwogCQkJbGlieGZz X3RyYW5zX2NvbW1pdCh0cCwgWEZTX1RSQU5TX1JFTEVBU0VfTE9HX1JFUwogCQkJ CQl8WEZTX1RSQU5TX1NZTkMsIDApOwotCi0JCQluZWVkX3Jvb3RfZG90ZG90ID0g MDsKLQkJfSBlbHNlIGlmIChuZWVkX3Jvb3RfZG90ZG90ICYmIGlubyA9PSBtcC0+ bV9zYi5zYl9yb290aW5vKSAgewotCQkJZG9fd2FybihfKCJ3b3VsZCByZWNyZWF0 ZSByb290IGRpcmVjdG9yeSAuLiBlbnRyeVxuIikpOwotCQl9Ci0KLQkJLyoKLQkJ ICogZGVsZXRlIGFueSBpbGxlZ2FsIGVudHJpZXMgLS0gd2hpY2ggc2hvdWxkIG9u bHkgZXhpc3QKLQkJICogaWYgdGhlIGRpcmVjdG9yeSBpcyBhIGxvbmdmb3JtIGRp cmVjdG9yeS4gIGJvZ3VzCi0JCSAqIHNob3J0Zm9ybSBkaXJlY3RvcnkgZW50cmll cyB3ZXJlIGRlbGV0ZWQgaW4gcGhhc2UgNC4KLQkJICovCi0JCWlmICghbm9fbW9k aWZ5ICYmIG51bV9pbGxlZ2FsID4gMCkgIHsKLQkJCUFTU0VSVChpcC0+aV9kLmRp X2Zvcm1hdCAhPSBYRlNfRElOT0RFX0ZNVF9MT0NBTCk7Ci0JCQlBU1NFUlQoIVhG U19TQl9WRVJTSU9OX0hBU0RJUlYyKCZtcC0+bV9zYikpOwotCi0JCQl3aGlsZSAo bnVtX2lsbGVnYWwgPiAwICYmIGlwLT5pX2QuZGlfZm9ybWF0ICE9Ci0JCQkJCVhG U19ESU5PREVfRk1UX0xPQ0FMKSAgewotCQkJCXBydW5lX2xmX2Rpcl9lbnRyeSht cCwgaW5vLCBpcCwgJmhhc2h2YWwpOwotCQkJCW51bV9pbGxlZ2FsLS07Ci0JCQl9 Ci0KLQkJCS8qCi0JCQkgKiBoYW5kbGUgY2FzZSB3aGVyZSB3ZSd2ZSBkZWxldGVk IHNvIG1hbnkKLQkJCSAqIGVudHJpZXMgdGhhdCB0aGUgZGlyZWN0b3J5IGhhcyBj aGFuZ2VkIGZyb20KLQkJCSAqIGEgbG9uZ2Zvcm0gdG8gYSBzaG9ydGZvcm0gZGly ZWN0b3J5LiAgaGF2ZQotCQkJICogdG8gYWxsb2NhdGUgYSB0cmFuc2FjdGlvbiBz aW5jZSB3ZSdyZSB3b3JraW5nCi0JCQkgKiB3aXRoIHRoZSBpbmNvcmUgZGF0YSBm b3JrLgotCQkJICovCi0JCQlpZiAobnVtX2lsbGVnYWwgPiAwKSAgewotCQkJCUFT U0VSVChpcC0+aV9kLmRpX2Zvcm1hdCA9PQotCQkJCQlYRlNfRElOT0RFX0ZNVF9M T0NBTCk7Ci0JCQkJdHAgPSBsaWJ4ZnNfdHJhbnNfYWxsb2MobXAsIDApOwotCQkJ CS8qCi0JCQkJICogdXNpbmcgdGhlIHJlbW92ZSByZXNlcnZhdGlvbiBpcyBvdmVy a2lsbAotCQkJCSAqIHNpbmNlIGF0IG1vc3Qgd2UnbGwgb25seSBuZWVkIHRvIGxv ZyB0aGUKLQkJCQkgKiBpbm9kZSBidXQgaXQncyBlYXNpZXIgdGhhbiB3ZWRnaW5n IGEKLQkJCQkgKiBuZXcgZGVmaW5lIGluIG91cnNlbHZlcy4gIDEwIGJsb2NrIGZz Ci0JCQkJICogc3BhY2UgcmVzZXJ2YXRpb24gaXMgYWxzbyBvdmVya2lsbCBidXQK LQkJCQkgKiB3aGF0IHRoZSBoZWNrLi4uCi0JCQkJICovCi0JCQkJbnJlcyA9IFhG U19SRU1PVkVfU1BBQ0VfUkVTKG1wKTsKLQkJCQllcnJvciA9IGxpYnhmc190cmFu c19yZXNlcnZlKHRwLCBucmVzLAotCQkJCQkJWEZTX1JFTU9WRV9MT0dfUkVTKG1w KSwgMCwKLQkJCQkJCVhGU19UUkFOU19QRVJNX0xPR19SRVMsCi0JCQkJCQlYRlNf UkVNT1ZFX0xPR19DT1VOVCk7Ci0JCQkJaWYgKGVycm9yKQotCQkJCQlyZXNfZmFp bGVkKGVycm9yKTsKLQotCQkJCWxpYnhmc190cmFuc19pam9pbih0cCwgaXAsIDAp OwotCQkJCWxpYnhmc190cmFuc19paG9sZCh0cCwgaXApOwotCi0JCQkJcHJ1bmVf c2ZfZGlyX2VudHJ5KG1wLCBpbm8sIGlwKTsKLQotCQkJCWxpYnhmc190cmFuc19s b2dfaW5vZGUodHAsIGlwLAotCQkJCQkJWEZTX0lMT0dfQ09SRSB8IFhGU19JTE9H X0REQVRBKTsKLQkJCQlBU1NFUlQoZXJyb3IgPT0gMCk7Ci0JCQkJbGlieGZzX3Ry YW5zX2NvbW1pdCh0cCwgWEZTX1RSQU5TX1JFTEVBU0VfTE9HX1JFUwotCQkJCQkJ fFhGU19UUkFOU19TWU5DLCAwKTsKLQkJCX0KIAkJfQotCi0JCS8qCi0JCSAqIGlm IHdlIG5lZWQgdG8gY3JlYXRlIHRoZSAnLicgZW50cnksIGRvIHNvIG9ubHkgaWYK LQkJICogdGhlIGRpcmVjdG9yeSBpcyBhIGxvbmdmb3JtIGRpci4gIGl0IGl0J3Mg YmVlbgotCQkgKiB0dXJuZWQgaW50byBhIHNob3J0Zm9ybSBkaXIsIHRoZW4gdGhl IGlub2RlIGlzIG9rCi0JCSAqIHNpbmNlIHNob3J0Zm9ybSBkaXJzIGhhdmUgbm8g Jy4nIGVudHJ5IGFuZCB0aGUgaW5vZGUKLQkJICogaGFzIGFscmVhZHkgYmVlbiBj b21taXR0ZWQgYnkgcHJ1bmVfbGZfZGlyX2VudHJ5KCkuCi0JCSAqLwotCQlpZiAo bmVlZF9kb3QpICB7Ci0JCQkvKgotCQkJICogYnVtcCB1cCBvdXIgbGluayBjb3Vu dCBidXQgZG9uJ3QKLQkJCSAqIGJ1bXAgdXAgdGhlIGlub2RlIGxpbmsgY291bnQu ICBjaGFuY2VzCi0JCQkgKiBhcmUgZ29vZCB0aGF0IGV2ZW4gdGhvdWdoIHdlIGxv c3QgJy4nCi0JCQkgKiB0aGUgaW5vZGUgbGluayBjb3VudHMgcmVmbGVjdCAnLicg c28KLQkJCSAqIGxlYXZlIHRoZSBpbm9kZSBsaW5rIGNvdW50IGFsb25lIGFuZCBp ZgotCQkJICogaXQgdHVybnMgb3V0IHRvIGJlIHdyb25nLCB3ZSdsbCBjYXRjaAot CQkJICogdGhhdCBpbiBwaGFzZSA3LgotCQkJICovCi0JCQlhZGRfaW5vZGVfcmVm KGlyZWMsIGlub19vZmZzZXQpOwotCi0JCQlpZiAobm9fbW9kaWZ5KSAgewotCQkJ CWRvX3dhcm4oCi0JXygid291bGQgY3JlYXRlIG1pc3NpbmcgXCIuXCIgZW50cnkg aW4gZGlyIGlubyAlbGx1XG4iKSwKLQkJCQkJaW5vKTsKLQkJCX0gZWxzZSBpZiAo aXAtPmlfZC5kaV9mb3JtYXQgIT0gWEZTX0RJTk9ERV9GTVRfTE9DQUwpICB7Ci0J CQkJLyoKLQkJCQkgKiBuZWVkIHRvIGNyZWF0ZSAuIGVudHJ5IGluIGxvbmdmb3Jt IGRpci4KLQkJCQkgKi8KLQkJCQlkb193YXJuKAotCV8oImNyZWF0aW5nIG1pc3Np bmcgXCIuXCIgZW50cnkgaW4gZGlyIGlubyAlbGx1XG4iKSwKLQkJCQkJaW5vKTsK LQotCQkJCXRwID0gbGlieGZzX3RyYW5zX2FsbG9jKG1wLCAwKTsKLQkJCQlBU1NF UlQodHAgIT0gTlVMTCk7Ci0KLQkJCQlucmVzID0gWEZTX01LRElSX1NQQUNFX1JF UyhtcCwgMSk7Ci0JCQkJZXJyb3IgPSBsaWJ4ZnNfdHJhbnNfcmVzZXJ2ZSh0cCwg bnJlcywKLQkJCQkJCVhGU19NS0RJUl9MT0dfUkVTKG1wKSwKLQkJCQkJCTAsCi0J CQkJCQlYRlNfVFJBTlNfUEVSTV9MT0dfUkVTLAotCQkJCQkJWEZTX01LRElSX0xP R19DT1VOVCk7Ci0KLQkJCQlpZiAoZXJyb3IpCi0JCQkJCXJlc19mYWlsZWQoZXJy b3IpOwotCi0JCQkJbGlieGZzX3RyYW5zX2lqb2luKHRwLCBpcCwgMCk7Ci0JCQkJ bGlieGZzX3RyYW5zX2lob2xkKHRwLCBpcCk7Ci0KLQkJCQlYRlNfQk1BUF9JTklU KCZmbGlzdCwgJmZpcnN0KTsKLQotCQkJCWlmICgoZXJyb3IgPSBkaXJfY3JlYXRl bmFtZShtcCwgdHAsIGlwLCAiLiIsCi0JCQkJCQkxLCBpcC0+aV9pbm8sICZmaXJz dCwgJmZsaXN0LAotCQkJCQkJbnJlcykpKQotCQkJCQlkb19lcnJvcigKLQlfKCJj YW4ndCBtYWtlIFwiLlwiIGVudHJ5IGluIGRpciBpbm8gJWxsdSwgY3JlYXRlbmFt ZSBlcnJvciAlZFxuIiksCi0JCQkJCQlpbm8sIGVycm9yKTsKLQotCQkJCWxpYnhm c190cmFuc19sb2dfaW5vZGUodHAsIGlwLCBYRlNfSUxPR19DT1JFKTsKLQotCQkJ CWVycm9yID0gbGlieGZzX2JtYXBfZmluaXNoKCZ0cCwgJmZsaXN0LCBmaXJzdCwK LQkJCQkJCSZjb21taXR0ZWQpOwotCQkJCUFTU0VSVChlcnJvciA9PSAwKTsKLQkJ CQlsaWJ4ZnNfdHJhbnNfY29tbWl0KHRwLCBYRlNfVFJBTlNfUkVMRUFTRV9MT0df UkVTCi0JCQkJCQl8WEZTX1RSQU5TX1NZTkMsIDApOwotCQkJfQotCQl9Ci0KLQkJ bGlieGZzX2lwdXQoaXAsIDApOwogCX0KKworCWxpYnhmc19pcHV0KGlwLCAwKTsK IH0KIAogLyoKQEAgLTM3NTksMTAgKzM3MDMsMTAgQEAKIHN0YXRpYyB2b2lkCiBj aGVja19mb3Jfb3JwaGFuZWRfaW5vZGVzKAogCXhmc19tb3VudF90CQkqbXAsCisJ eGZzX2FnbnVtYmVyX3QJCWFnbm8sCiAJaW5vX3RyZWVfbm9kZV90CQkqaXJlYykK IHsKIAlpbnQJCQlpOwotCWludAkJCWVycjsKIAl4ZnNfaW5vX3QJCWlubzsKIAog CWZvciAoaSA9IDA7IGkgPCBYRlNfSU5PREVTX1BFUl9DSFVOSzsgaSsrKSAgewpA QCAtMzc3MCw5MyArMzcxNCwxMDEgQEAKIAkJaWYgKGlzX2lub2RlX2ZyZWUoaXJl YywgaSkpCiAJCQljb250aW51ZTsKIAotCQlpZiAoIWlzX2lub2RlX3JlYWNoZWQo aXJlYywgaSkpIHsKLQkJCUFTU0VSVChpbm9kZV9pc2FkaXIoaXJlYywgaSkgfHwK LQkJCQludW1faW5vZGVfcmVmZXJlbmNlcyhpcmVjLCBpKSA9PSAwKTsKLQkJCWlu byA9IFhGU19BR0lOT19UT19JTk8obXAsIGksIGkgKyBpcmVjLT5pbm9fc3RhcnRu dW0pOwotCQkJaWYgKGlub2RlX2lzYWRpcihpcmVjLCBpKSkKLQkJCQlkb193YXJu KF8oImRpc2Nvbm5lY3RlZCBkaXIgaW5vZGUgJWxsdSwgIiksIGlubyk7Ci0JCQll bHNlCi0JCQkJZG9fd2FybihfKCJkaXNjb25uZWN0ZWQgaW5vZGUgJWxsdSwgIiks IGlubyk7Ci0JCQlpZiAoIW5vX21vZGlmeSkgIHsKLQkJCSAgICAJaWYgKCFvcnBo YW5hZ2VfaW5vKQotCQkJCQlvcnBoYW5hZ2VfaW5vID0gbWtfb3JwaGFuYWdlKG1w KTsKLQkJCQlpZiAoIW9ycGhhbmFnZV9pcCkgewotCQkJCQllcnIgPSBsaWJ4ZnNf aWdldChtcCwgTlVMTCwgb3JwaGFuYWdlX2lubywgMCwgJm9ycGhhbmFnZV9pcCwg MCk7Ci0JCQkJCWlmIChlcnIpCi0JCQkJCQlkb19lcnJvcihfKCIlZCAtIGNvdWxk bid0IGlnZXQgb3JwaGFuYWdlIGlub2RlXG4iKSwgZXJyKTsKLQkJCQl9Ci0JCQkJ ZG9fd2FybihfKCJtb3ZpbmcgdG8gJXNcbiIpLCBPUlBIQU5BR0UpOwotCQkJCW12 X29ycGhhbmFnZShtcCwgaW5vLCBpbm9kZV9pc2FkaXIoaXJlYywgaSkpOwotCQkJ fSBlbHNlICB7Ci0JCQkJZG9fd2FybihfKCJ3b3VsZCBtb3ZlIHRvICVzXG4iKSwg T1JQSEFOQUdFKTsKLQkJCX0KLQkJCS8qCi0JCQkgKiBmb3IgcmVhZC1vbmx5IGNh c2UsIGV2ZW4gdGhvdWdoIHRoZSBpbm9kZSBpc24ndAotCQkJICogcmVhbGx5IHJl YWNoYWJsZSwgc2V0IHRoZSBmbGFnIChhbmQgYnVtcCBvdXIgbGluawotCQkJICog Y291bnQpIGFueXdheSB0byBmb29sIHBoYXNlIDcKLQkJCSAqLwotCQkJYWRkX2lu b2RlX3JlYWNoZWQoaXJlYywgaSk7CisJCWlmIChpc19pbm9kZV9yZWFjaGVkKGly ZWMsIGkpKQorCQkJY29udGludWU7CisKKwkJQVNTRVJUKGlub2RlX2lzYWRpcihp cmVjLCBpKSB8fAorCQkJbnVtX2lub2RlX3JlZmVyZW5jZXMoaXJlYywgaSkgPT0g MCk7CisKKwkJaW5vID0gWEZTX0FHSU5PX1RPX0lOTyhtcCwgYWdubywgaSArIGly ZWMtPmlub19zdGFydG51bSk7CisJCWlmIChpbm9kZV9pc2FkaXIoaXJlYywgaSkp CisJCQlkb193YXJuKF8oImRpc2Nvbm5lY3RlZCBkaXIgaW5vZGUgJWxsdSwgIiks IGlubyk7CisJCWVsc2UKKwkJCWRvX3dhcm4oXygiZGlzY29ubmVjdGVkIGlub2Rl ICVsbHUsICIpLCBpbm8pOworCQlpZiAoIW5vX21vZGlmeSkgIHsKKwkJICAgIAlp ZiAoIW9ycGhhbmFnZV9pbm8pCisJCQkJb3JwaGFuYWdlX2lubyA9IG1rX29ycGhh bmFnZShtcCk7CisJCQlkb193YXJuKF8oIm1vdmluZyB0byAlc1xuIiksIE9SUEhB TkFHRSk7CisJCQltdl9vcnBoYW5hZ2UobXAsIGlubywgaW5vZGVfaXNhZGlyKGly ZWMsIGkpKTsKKwkJfSBlbHNlICB7CisJCQlkb193YXJuKF8oIndvdWxkIG1vdmUg dG8gJXNcbiIpLCBPUlBIQU5BR0UpOwogCQl9CisJCS8qCisJCSAqIGZvciByZWFk LW9ubHkgY2FzZSwgZXZlbiB0aG91Z2ggdGhlIGlub2RlIGlzbid0CisJCSAqIHJl YWxseSByZWFjaGFibGUsIHNldCB0aGUgZmxhZyAoYW5kIGJ1bXAgb3VyIGxpbmsK KwkJICogY291bnQpIGFueXdheSB0byBmb29sIHBoYXNlIDcKKwkJICovCisJCWFk ZF9pbm9kZV9yZWFjaGVkKGlyZWMsIGkpOwogCX0KIH0KIAogc3RhdGljIHZvaWQK LXRyYXZlcnNlX2Z1bmN0aW9uKHhmc19tb3VudF90ICptcCwgeGZzX2FnbnVtYmVy X3QgYWdubykKK3RyYXZlcnNlX2Z1bmN0aW9uKAorCXdvcmtfcXVldWVfdAkJKndx LAorCXhmc19hZ251bWJlcl90IAkJYWdubywKKwl2b2lkCQkJKmFyZykKIHsKLQly ZWdpc3RlciBpbm9fdHJlZV9ub2RlX3QgKmlyZWM7Ci0JaW50CQkJajsKLQl4ZnNf aW5vX3QJCWlubzsKLQlkaXJfc3RhY2tfdAkJc3RhY2s7CisJaW5vX3RyZWVfbm9k ZV90IAkqaXJlYzsKKwlpbnQJCQlpOworCXByZWZldGNoX2FyZ3NfdAkJKnBmX2Fy Z3MgPSBhcmc7CisKKwl3YWl0X2Zvcl9pbm9kZV9wcmVmZXRjaChwZl9hcmdzKTsK IAogCWlmICh2ZXJib3NlKQogCQlkb19sb2coXygiICAgICAgICAtIGFnbm8gPSAl ZFxuIiksIGFnbm8pOwogCi0JZGlyX3N0YWNrX2luaXQoJnN0YWNrKTsKLQlpcmVj ID0gZmluZGZpcnN0X2lub2RlX3JlYyhhZ25vKTsKLQotCXdoaWxlIChpcmVjICE9 IE5VTEwpICB7Ci0JCWZvciAoaiA9IDA7IGogPCBYRlNfSU5PREVTX1BFUl9DSFVO SzsgaisrKSAgewotCQkJaWYgKCFpbm9kZV9pc2FkaXIoaXJlYywgaikpIHsKLQkJ CQlpbm8gPSBYRlNfQUdJTk9fVE9fSU5PKG1wLCBhZ25vLAotCQkJCQlpcmVjLT5p bm9fc3RhcnRudW0gKyBqKTsKLQkJCQlpZiAobXAtPm1fc2Iuc2Jfcm9vdGlubyAh PSBpbm8pCi0JCQkJCWNvbnRpbnVlOwotCQkJfQorCWZvciAoaXJlYyA9IGZpbmRm aXJzdF9pbm9kZV9yZWMoYWdubyk7IGlyZWM7IGlyZWMgPSBuZXh0X2lub19yZWMo aXJlYykpIHsKKwkJaWYgKGlyZWMtPmlub19pc2FfZGlyID09IDApCisJCQljb250 aW51ZTsKIAotCQkJaW5vID0gWEZTX0FHSU5PX1RPX0lOTyhtcCwgYWdubywKLQkJ CQlpcmVjLT5pbm9fc3RhcnRudW0gKyBqKTsKKwkJaWYgKHBmX2FyZ3MpCisJCQlz ZW1fcG9zdCgmcGZfYXJncy0+cmFfY291bnQpOwogCi0JCQlwdXNoX2Rpcigmc3Rh Y2ssIGlubyk7Ci0JCQlwcm9jZXNzX2RpcnN0YWNrKG1wLCAmc3RhY2spOworCQlm b3IgKGkgPSAwOyBpIDwgWEZTX0lOT0RFU19QRVJfQ0hVTks7IGkrKykgIHsKKwkJ CWlmIChpbm9kZV9pc2FkaXIoaXJlYywgaSkpCisJCQkJcHJvY2Vzc19kaXJfaW5v ZGUod3EtPm1wLAorCQkJCQlYRlNfQUdJTk9fVE9fSU5PKHdxLT5tcCwgYWdubywK KwkJCQkJaXJlYy0+aW5vX3N0YXJ0bnVtICsgaSksIGlyZWMsIGkpOwogCQl9Ci0J CWlyZWMgPSBuZXh0X2lub19yZWMoaXJlYyk7CiAJfQotCXJldHVybjsKKwljbGVh bnVwX2lub2RlX3ByZWZldGNoKHBmX2FyZ3MpOwogfQogCiBzdGF0aWMgdm9pZAot dHJhdmVyc2VfYWx0KHhmc19tb3VudF90ICptcCkKK3RyYXZlcnNlX2FncygKKwl4 ZnNfbW91bnRfdCAJCSptcCkKIHsKIAlpbnQJCQlpOworCXdvcmtfcXVldWVfdAkJ KnF1ZXVlczsKKwlwcmVmZXRjaF9hcmdzX3QJCSpwZl9hcmdzWzJdOworCisJcXVl dWVzID0gbWFsbG9jKHRocmVhZF9jb3VudCAqIHNpemVvZih3b3JrX3F1ZXVlX3Qp KTsKKwlxdWV1ZXNbMF0ubXAgPSBtcDsKIAotCXNldF9wcm9ncmVzc19tc2coUFJP R19GTVRfVFJBVkVSU0FMLCAoX191aW50NjRfdCkgZ2xvYl9hZ2NvdW50KTsKLQlm b3IgKGkgPSAwOyBpIDwgbXAtPm1fc2Iuc2JfYWdjb3VudDsgaSsrKSAgewotCQl0 cmF2ZXJzZV9mdW5jdGlvbihtcCwgaSk7Ci0JCVBST0dfUlBUX0lOQyhwcm9nX3Jw dF9kb25lW2ldLCAxKTsKKwlpZiAoIWxpYnhmc19iY2FjaGVfb3ZlcmZsb3dlZCgp KSB7CisJCS8qY3JlYXRlX3dvcmtfcXVldWUoJnF1ZXVlc1swXSwgbXAsIGxpYnhm c19ucHJvYygpKTsKKwkJZm9yIChpID0gMDsgaSA8IGdsb2JfYWdjb3VudDsgaSsr KQorCQkJcXVldWVfd29yaygmcXVldWVzWzBdLCB0cmF2ZXJzZV9mdW5jdGlvbiwg aSwgTlVMTCk7CisJCWRlc3Ryb3lfd29ya19xdWV1ZSgmcXVldWVzWzBdKTsqLwor CQlmb3IgKGkgPSAwOyBpIDwgZ2xvYl9hZ2NvdW50OyBpKyspCisJCQl0cmF2ZXJz ZV9mdW5jdGlvbigmcXVldWVzWzBdLCBpLCBOVUxMKTsKKwl9IGVsc2UgeworCQkv KiBUT0RPOiBBRyBzdHJpZGUgc3VwcG9ydCAqLworCQlwZl9hcmdzWzBdID0gc3Rh cnRfaW5vZGVfcHJlZmV0Y2goMCwgMSwgTlVMTCk7CisJCWZvciAoaSA9IDA7IGkg PCBnbG9iX2FnY291bnQ7IGkrKykgeworCQkJcGZfYXJnc1sofmkpICYgMV0gPSBz dGFydF9pbm9kZV9wcmVmZXRjaChpICsgMSwgMSwKKwkJCQkJcGZfYXJnc1tpICYg MV0pOworCQkJdHJhdmVyc2VfZnVuY3Rpb24oJnF1ZXVlc1swXSwgaSwgcGZfYXJn c1tpICYgMV0pOworCQl9CiAJfQotCXByaW50X2ZpbmFsX3JwdCgpOworCWZyZWUo cXVldWVzKTsKIH0KIAogdm9pZAogcGhhc2U2KHhmc19tb3VudF90ICptcCkKIHsK LQl4ZnNfaW5vX3QJCWlubzsKIAlpbm9fdHJlZV9ub2RlX3QJCSppcmVjOwotCWRp cl9zdGFja190CQlzdGFjazsKIAlpbnQJCQlpOwotCWludAkJCWo7Ci0JeGZzX2lu b190CQlvcnBoYW5hZ2VfaW5vOwogCiAJYnplcm8oJnplcm9jciwgc2l6ZW9mKHN0 cnVjdCBjcmVkKSk7CiAJYnplcm8oJnplcm9mc3gsIHNpemVvZihzdHJ1Y3QgZnN4 YXR0cikpOwpAQCAtMzkyNCwzNCArMzg3Niw5IEBACiAJCX0KIAl9CiAKLQlkaXJf c3RhY2tfaW5pdCgmc3RhY2spOwotCiAJbWFya19zdGFuZGFsb25lX2lub2Rlcyht cCk7CiAKLQkvKgotCSAqIHB1c2ggcm9vdCBkaXIgb24gc3RhY2ssIHRoZW4gZ28K LQkgKi8KLQlpZiAoIW5lZWRfcm9vdF9pbm9kZSkgIHsKLQkJZG9fbG9nKF8oIiAg ICAgICAgLSB0cmF2ZXJzaW5nIGZpbGVzeXN0ZW0gc3RhcnRpbmcgYXQgLyAuLi4g XG4iKSk7Ci0KLQkJaWYgKGRvX3ByZWZldGNoKSB7Ci0JCQl0cmF2ZXJzZV9hbHQo bXApOwotCQl9IGVsc2UgewotCQkJcHVzaF9kaXIoJnN0YWNrLCBtcC0+bV9zYi5z Yl9yb290aW5vKTsKLQkJCXByb2Nlc3NfZGlyc3RhY2sobXAsICZzdGFjayk7Ci0J CX0KLQotCQlkb19sb2coXygiICAgICAgICAtIHRyYXZlcnNhbCBmaW5pc2hlZCAu Li4gXG4iKSk7Ci0JfSBlbHNlICB7Ci0JCUFTU0VSVChub19tb2RpZnkgIT0gMCk7 Ci0KLQkJZG9fbG9nKAotXygiICAgICAgICAtIHJvb3QgaW5vZGUgbG9zdCwgY2Fu bm90IG1ha2UgbmV3IG9uZSBpbiBubyBtb2RpZnkgbW9kZSAuLi4gXG4iKSk7Ci0J CWRvX2xvZygKLV8oIiAgICAgICAgLSBza2lwcGluZyBmaWxlc3lzdGVtIHRyYXZl cnNhbCBmcm9tIC8gLi4uIFxuIikpOwotCX0KLQotCWRvX2xvZyhfKCIgICAgICAg IC0gdHJhdmVyc2luZyBhbGwgdW5hdHRhY2hlZCBzdWJ0cmVlcyAuLi4gXG4iKSk7 CisJZG9fbG9nKF8oIiAgICAgICAgLSB0cmF2ZXJzaW5nIGZpbGVzeXN0ZW0gLi4u IFxuIikpOwogCiAJaXJlYyA9IGZpbmRfaW5vZGVfcmVjKFhGU19JTk9fVE9fQUdO TyhtcCwgbXAtPm1fc2Iuc2Jfcm9vdGlubyksCiAJCQkJWEZTX0lOT19UT19BR0lO TyhtcCwgbXAtPm1fc2Iuc2Jfcm9vdGlubykpOwpAQCAtMzk2NSw0MiArMzg5Miw5 IEBACiAJfQogCiAJLyoKLQkgKiB0aGVuIHByb2Nlc3MgYWxsIHVucmVhY2hlZCBp bm9kZXMKLQkgKiBieSB3YWxraW5nIGluY29yZSBpbm9kZSB0cmVlCi0JICoKLQkg KglnZXQgbmV4dCB1bnJlYWNoZWQgZGlyZWN0b3J5IGlub2RlICMgZnJvbQotCSAq CQlpbmNvcmUgbGlzdAotCSAqCXB1c2ggaW5vZGUgb24gZGlyIHN0YWNrCi0JICoJ Y2FsbCBwcm9jZXNzX2RpcnN0YWNrCisJICogdGhlbiBwcm9jZXNzIGFsbCBpbm9k ZXMgYnkgd2Fsa2luZyBpbmNvcmUgaW5vZGUgdHJlZQogCSAqLwotCWZvciAoaSA9 IDA7IGkgPCBnbG9iX2FnY291bnQ7IGkrKykgIHsKLQkJaXJlYyA9IGZpbmRmaXJz dF9pbm9kZV9yZWMoaSk7Ci0KLQkJaWYgKGlyZWMgPT0gTlVMTCkKLQkJCWNvbnRp bnVlOwotCi0JCXdoaWxlIChpcmVjICE9IE5VTEwpICB7Ci0JCQlmb3IgKGogPSAw OyBqIDwgWEZTX0lOT0RFU19QRVJfQ0hVTks7IGorKykgIHsKLQkJCQlpZiAoIWlz X2lub2RlX2NvbmZpcm1lZChpcmVjLCBqKSkKLQkJCQkJY29udGludWU7Ci0JCQkJ LyoKLQkJCQkgKiBza2lwIGRpcmVjdG9yaWVzIHRoYXQgaGF2ZSBhbHJlYWR5IGJl ZW4KLQkJCQkgKiBwcm9jZXNzZWQsIGV2ZW4gaWYgdGhleSBoYXZlbid0IGJlZW4K LQkJCQkgKiByZWFjaGVkLiAgSWYgdGhleSBhcmUgcmVhY2hhYmxlLCB3ZSdsbAot CQkJCSAqIHBpY2sgdGhlbSB1cCB3aGVuIHdlIHByb2Nlc3MgdGhlaXIgcGFyZW50 LgotCQkJCSAqLwotCQkJCWlubyA9IFhGU19BR0lOT19UT19JTk8obXAsIGksCi0J CQkJCQlqICsgaXJlYy0+aW5vX3N0YXJ0bnVtKTsKLQkJCQlpZiAoaW5vZGVfaXNh ZGlyKGlyZWMsIGopICYmCi0JCQkJCQkhaXNfaW5vZGVfcmVmY2hlY2tlZChpbm8s Ci0JCQkJCQkJaXJlYywgaikpIHsKLQkJCQkJcHVzaF9kaXIoJnN0YWNrLCBpbm8p OwotCQkJCQlwcm9jZXNzX2RpcnN0YWNrKG1wLCAmc3RhY2spOwotCQkJCX0KLQkJ CX0KLQkJCWlyZWMgPSBuZXh0X2lub19yZWMoaXJlYyk7Ci0JCX0KLQl9CisJdHJh dmVyc2VfYWdzKG1wKTsKIAogCWRvX2xvZyhfKCIgICAgICAgIC0gdHJhdmVyc2Fs cyBmaW5pc2hlZCAuLi4gXG4iKSk7CiAJZG9fbG9nKF8oIiAgICAgICAgLSBtb3Zp bmcgZGlzY29ubmVjdGVkIGlub2RlcyB0byAlcyAuLi4gXG4iKSwKQEAgLTQwMTIs NyArMzkwNiw3IEBACiAJZm9yIChpID0gMDsgaSA8IGdsb2JfYWdjb3VudDsgaSsr KSAgewogCQlpcmVjID0gZmluZGZpcnN0X2lub2RlX3JlYyhpKTsKIAkJd2hpbGUg KGlyZWMgIT0gTlVMTCkgIHsKLQkJCWNoZWNrX2Zvcl9vcnBoYW5lZF9pbm9kZXMo bXAsIGlyZWMpOworCQkJY2hlY2tfZm9yX29ycGhhbmVkX2lub2RlcyhtcCwgaSwg aXJlYyk7CiAJCQlpcmVjID0gbmV4dF9pbm9fcmVjKGlyZWMpOwogCQl9CiAJfQpJ bmRleDogcmVwYWlyL3hmc3Byb2dzL3JlcGFpci9waGFzZTcuYwo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSByZXBhaXIub3JpZy94ZnNwcm9ncy9yZXBhaXIvcGhhc2U3 LmMJMjAwNy0wNC0yNyAxNDoxMTo0MS4wMDAwMDAwMDAgKzEwMDAKKysrIHJlcGFp ci94ZnNwcm9ncy9yZXBhaXIvcGhhc2U3LmMJMjAwNy0wNC0yNyAxNDoxMjozNC4x OTE1NjM1MDEgKzEwMDAKQEAgLTI1LDkgKzI1LDcgQEAKICNpbmNsdWRlICJlcnJf cHJvdG9zLmgiCiAjaW5jbHVkZSAiZGlub2RlLmgiCiAjaW5jbHVkZSAidmVyc2lv bnMuaCIKLSNpbmNsdWRlICJwcmVmZXRjaC5oIgogI2luY2x1ZGUgInByb2dyZXNz LmgiCi0jaW5jbHVkZSAidGhyZWFkcy5oIgogCiAvKiBkaW5vYyBpcyBhIHBvaW50 ZXIgdG8gdGhlIElOLUNPUkUgZGlub2RlIGNvcmUgKi8KIHN0YXRpYyB2b2lkCkBA IC0xMTYsNTcgKzExNCw2IEBACiAJfQogfQogCi1zdGF0aWMgdm9pZAotcGhhc2U3 X2FsdF9mdW5jdGlvbih4ZnNfbW91bnRfdCAqbXAsIHhmc19hZ251bWJlcl90IGFn bm8pCi17Ci0JaW5vX3RyZWVfbm9kZV90IAkqaXJlYzsKLQlpbnQJCQlqOwotCV9f dWludDMyX3QJCW5yZWZzOwotCi0JLyoKLQkgKiB1c2luZyB0aGUgbmxpbmsgdmFs dWVzIG1lbW9yaXNlZCBkdXJpbmcgcGhhc2UzLzQsIGNvbXBhcmUgdG8gdGhlCi0J ICogbmxpbmsgY291bnRlZCBpbiBwaGFzZSA2LCBhbmQgaWYgZGlmZmVyZW50LCB1 cGRhdGUgb24tZGlzay4KLQkgKi8KLQotCWlyZWMgPSBmaW5kZmlyc3RfaW5vZGVf cmVjKGFnbm8pOwotCi0Jd2hpbGUgKGlyZWMgIT0gTlVMTCkgIHsKLQkJZm9yIChq ID0gMDsgaiA8IFhGU19JTk9ERVNfUEVSX0NIVU5LOyBqKyspICB7Ci0JCQlhc3Nl cnQoaXNfaW5vZGVfY29uZmlybWVkKGlyZWMsIGopKTsKLQotCQkJaWYgKGlzX2lu b2RlX2ZyZWUoaXJlYywgaikpCi0JCQkJY29udGludWU7Ci0KLQkJCWFzc2VydChu b19tb2RpZnkgfHwgaXNfaW5vZGVfcmVhY2hlZChpcmVjLCBqKSk7Ci0JCQlhc3Nl cnQobm9fbW9kaWZ5IHx8IGlzX2lub2RlX3JlZmVyZW5jZWQoaXJlYywgaikpOwot Ci0JCQlucmVmcyA9IG51bV9pbm9kZV9yZWZlcmVuY2VzKGlyZWMsIGopOwotCi0g CQkJaWYgKGdldF9pbm9kZV9kaXNrX25saW5rcyhpcmVjLCBqKSAhPSBucmVmcykK LSAJCQkJdXBkYXRlX2lub2RlX25saW5rcyhtcCwgWEZTX0FHSU5PX1RPX0lOTyht cCwKLSAJCQkJCQlhZ25vLCBpcmVjLT5pbm9fc3RhcnRudW0gKyBqKSwKLSAJCQkJ CQlucmVmcyk7Ci0JCX0KLQkJaXJlYyA9IG5leHRfaW5vX3JlYyhpcmVjKTsKLQkJ UFJPR19SUFRfSU5DKHByb2dfcnB0X2RvbmVbYWdub10sIFhGU19JTk9ERVNfUEVS X0NIVU5LKTsKLQl9Ci19Ci0KLXN0YXRpYyB2b2lkCi1waGFzZTdfYWx0KHhmc19t b3VudF90ICptcCkKLXsKLQlpbnQJCWk7Ci0KLQlzZXRfcHJvZ3Jlc3NfbXNnKG5v X21vZGlmeSA/IFBST0dSRVNTX0ZNVF9WUkZZX0xJTksgOiBQUk9HUkVTU19GTVRf Q09SUl9MSU5LLAotCQkoX191aW50NjRfdCkgbXAtPm1fc2Iuc2JfaWNvdW50KTsK LQotCWZvciAoaSA9IDA7IGkgPCBnbG9iX2FnY291bnQ7IGkrKykgIHsKLQkJcXVl dWVfd29yayhwaGFzZTdfYWx0X2Z1bmN0aW9uLCBtcCwgaSk7Ci0JfQotCXdhaXRf Zm9yX3dvcmtlcnMoKTsKLQlwcmludF9maW5hbF9ycHQoKTsKLX0KLQogdm9pZAog cGhhc2U3KHhmc19tb3VudF90ICptcCkKIHsKQEAgLTE4MCwxMSArMTI3LDYgQEAK IAllbHNlCiAJCWRvX2xvZyhfKCJQaGFzZSA3IC0gdmVyaWZ5IGxpbmsgY291bnRz Li4uXG4iKSk7CiAKLQlpZiAoZG9fcHJlZmV0Y2gpIHsKLQkJcGhhc2U3X2FsdCht cCk7Ci0JCXJldHVybjsKLQl9Ci0KIAkvKgogCSAqIGZvciBlYWNoIGFnLCBsb29r IGF0IGVhY2ggaW5vZGUgMSBhdCBhIHRpbWUuIElmIHRoZSBudW1iZXIgb2YKIAkg KiBsaW5rcyBpcyBiYWQsIHJlc2V0IGl0LCBsb2cgdGhlIGlub2RlIGNvcmUsIGNv bW1pdCB0aGUgdHJhbnNhY3Rpb24KSW5kZXg6IHJlcGFpci94ZnNwcm9ncy9yZXBh aXIvcHJlZmV0Y2guYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIub3Jp Zy94ZnNwcm9ncy9yZXBhaXIvcHJlZmV0Y2guYwkyMDA3LTA0LTI3IDEzOjEzOjM1 LjAwMDAwMDAwMCArMTAwMAorKysgcmVwYWlyL3hmc3Byb2dzL3JlcGFpci9wcmVm ZXRjaC5jCTIwMDctMDYtMDUgMTE6MzQ6MDEuOTU3NzMyOTY0ICsxMDAwCkBAIC0x LDYgKzEsNiBAQAogI2luY2x1ZGUgPGxpYnhmcy5oPgotI2luY2x1ZGUgInByZWZl dGNoLmgiCi0jaW5jbHVkZSAiYWlvLmgiCisjaW5jbHVkZSA8cHRocmVhZC5oPgor I2luY2x1ZGUgPHNjaGVkLmg+CiAjaW5jbHVkZSAiYXZsLmgiCiAjaW5jbHVkZSAi Z2xvYmFscy5oIgogI2luY2x1ZGUgImFnaGVhZGVyLmgiCkBAIC0xMyw0NTQgKzEz LDc4MiBAQAogI2luY2x1ZGUgImRpbm9kZS5oIgogI2luY2x1ZGUgImJtYXAuaCIK ICNpbmNsdWRlICJ2ZXJzaW9ucy5oIgorI2luY2x1ZGUgInRocmVhZHMuaCIKKyNp bmNsdWRlICJwcmVmZXRjaC5oIgorI2luY2x1ZGUgInByb2dyZXNzLmgiCisjaW5j bHVkZSAicmFkaXgtdHJlZS5oIgogCiBpbnQgZG9fcHJlZmV0Y2ggPSAxOwogCi1p bm9fdHJlZV9ub2RlX3QgKgotcHJlZmV0Y2hfaW5vZGVfY2h1bmtzKHhmc19tb3Vu dF90ICptcCwKLQkJeGZzX2FnbnVtYmVyX3QgYWdubywKLQkJaW5vX3RyZWVfbm9k ZV90ICppbm9fcmEpCi17Ci0JeGZzX2FnYmxvY2tfdCBhZ2JubzsKLQlsaWJ4ZnNf bGlvX3JlcV90ICpsaW9wOwotCWludCBpOwotCi0JaWYgKGxpYnhmc19saW9faW5v X2NvdW50ID09IDApCi0JCXJldHVybiBOVUxMOwotCi0JbGlvcCA9IChsaWJ4ZnNf bGlvX3JlcV90ICopIGxpYnhmc19nZXRfbGlvX2J1ZmZlcihMSUJYRlNfTElPX1RZ UEVfSU5PKTsKLQlpZiAobGlvcCA9PSBOVUxMKSB7Ci0JCWRvX3ByZWZldGNoID0g MDsKLQkJcmV0dXJuIE5VTEw7CisvKgorICogUGVyZm9ybXMgcHJlZmV0Y2hpbmcg YnkgcHJpbWluZyB0aGUgbGlieGZzIGNhY2hlIGJ5IHVzaW5nIGEgZGVkaWNhdGUg dGhyZWFkCisgKiBzY2FubmluZyBpbm9kZXMgYW5kIHJlYWRpbmcgYmxvY2tzIGlu IGFoZWFkIG9mIHRpbWUgdGhleSBhcmUgcmVxdWlyZWQuCisgKgorICogQW55IEkv TyBlcnJvcnMgY2FuIGJlIHNhZmVseSBpZ25vcmVkLgorICovCisKK3N0YXRpYyB4 ZnNfbW91bnRfdAkqbXA7CitzdGF0aWMgaW50IAkJbXBfZmQ7CitzdGF0aWMgaW50 CQlwZl9tYXhfYnl0ZXM7CitzdGF0aWMgaW50CQlwZl9tYXhfYmJzOworc3RhdGlj IGludAkJcGZfbWF4X2ZzYnM7CitzdGF0aWMgaW50CQlwZl9iYXRjaF9ieXRlczsK K3N0YXRpYyBpbnQJCXBmX2JhdGNoX2ZzYnM7CisKKyNkZWZpbmUgQl9JTk9ERQkJ MHgxMDAwMDAwCisjZGVmaW5lIEJfTUVUQQkJMHgyMDAwMDAwCisKKyNkZWZpbmUg SU9fVEhSRVNIT0xECTIwMAorCisjZGVmaW5lIERFRl9CQVRDSF9CWVRFUwkweDEw MDAwCisKK3N0YXRpYyBpbmxpbmUgdm9pZAorcGZfc3RhcnRfcHJvY2Vzc2luZygK KwlwcmVmZXRjaF9hcmdzX3QJCSphcmdzKQoreworCWlmICghYXJncy0+Y2FuX3N0 YXJ0X3Byb2Nlc3NpbmcpIHsKKyNpZmRlZiBYUl9QRl9UUkFDRQorCQlwZnRyYWNl KCJzaWduYWxsaW5nIHByb2Nlc3NpbmcgZm9yIEFHICVkIiwgYXJncy0+YWdubyk7 CisjZW5kaWYKKwkJYXJncy0+Y2FuX3N0YXJ0X3Byb2Nlc3NpbmcgPSAxOworCQlw dGhyZWFkX2NvbmRfc2lnbmFsKCZhcmdzLT5zdGFydF9wcm9jZXNzaW5nKTsKIAl9 Cit9CiAKLQlpZiAoaW5vX3JhID09IE5VTEwpCi0JCWlub19yYSA9IGZpbmRmaXJz dF9pbm9kZV9yZWMoYWdubyk7Ci0KLQlpID0gMDsKLQl3aGlsZSAoaW5vX3JhKSB7 Ci0JCWFnYm5vID0gWEZTX0FHSU5PX1RPX0FHQk5PKG1wLCBpbm9fcmEtPmlub19z dGFydG51bSk7Ci0JCWxpb3BbaV0uYmxrbm8gPSBYRlNfQUdCX1RPX0RBRERSKG1w LCBhZ25vLCBhZ2Jubyk7Ci0JCWxpb3BbaV0ubGVuID0gKGludCkgWEZTX0ZTQl9U T19CQihtcCwgWEZTX0lBTExPQ19CTE9DS1MobXApKTsKLQkJaSsrOwotCQlpbm9f cmEgPSBuZXh0X2lub19yZWMoaW5vX3JhKTsKLQkJaWYgKGkgPj0gbGlieGZzX2xp b19pbm9fY291bnQpCi0JCQlicmVhazsKLQl9Ci0JaWYgKGkpIHsKLQkJaWYgKGxp Ynhmc19yZWFkYnVmX2xpc3QobXAtPm1fZGV2LCBpLCAodm9pZCAqKSBsaW9wLCBM SUJYRlNfTElPX1RZUEVfSU5PKSA9PSAtMSkKLQkJCWRvX3ByZWZldGNoID0gMDsK K3N0YXRpYyBpbmxpbmUgdm9pZAorcGZfc3RhcnRfaW9fd29ya2VycygKKwlwcmVm ZXRjaF9hcmdzX3QJCSphcmdzKQoreworCWlmICghYXJncy0+Y2FuX3N0YXJ0X3Jl YWRpbmcpIHsKKyNpZmRlZiBYUl9QRl9UUkFDRQorCQlwZnRyYWNlKCJzaWduYWxs aW5nIHJlYWRpbmcgZm9yIEFHICVkIiwgYXJncy0+YWdubyk7CisjZW5kaWYKKwkJ YXJncy0+Y2FuX3N0YXJ0X3JlYWRpbmcgPSAxOworCQlwdGhyZWFkX2NvbmRfYnJv YWRjYXN0KCZhcmdzLT5zdGFydF9yZWFkaW5nKTsKIAl9Ci0JbGlieGZzX3B1dF9s aW9fYnVmZmVyKCh2b2lkICopIGxpb3ApOwotCXJldHVybiAoaW5vX3JhKTsKIH0K IAorCiBzdGF0aWMgdm9pZAotcHJlZmV0Y2hfbm9kZSgKLQl4ZnNfbW91bnRfdAkJ Km1wLAotCXhmc19idWZfdAkJKmJwLAotCWRhX2J0X2N1cnNvcl90CQkqZGFfY3Vy c29yKQorcGZfcXVldWVfaW8oCisJcHJlZmV0Y2hfYXJnc190CQkqYXJncywKKwl4 ZnNfZnNibG9ja190CQlmc2JubywKKwlpbnQJCQlibGVuLAorCWludAkJCWZsYWcp CiB7Ci0JeGZzX2RhX2ludG5vZGVfdAkqbm9kZTsKLQlsaWJ4ZnNfbGlvX3JlcV90 CSpsaW9wOwotCWludAkJCWk7Ci0JeGZzX2Rmc2Jub190CQlmc2JubzsKKwl4ZnNf YnVmX3QJCSpicDsKIAotCW5vZGUgPSAoeGZzX2RhX2ludG5vZGVfdCAqKVhGU19C VUZfUFRSKGJwKTsKLQlpZiAoSU5UX0dFVChub2RlLT5oZHIuY291bnQsIEFSQ0hf Q09OVkVSVCkgPD0gMSkKKwlicCA9IGxpYnhmc19nZXRidWYobXAtPm1fZGV2LCBY RlNfRlNCX1RPX0RBRERSKG1wLCBmc2JubyksCisJCQlYRlNfRlNCX1RPX0JCKG1w LCBibGVuKSk7CisJaWYgKGJwLT5iX2ZsYWdzICYgTElCWEZTX0JfVVBUT0RBVEUp IHsKKwkJbGlieGZzX3B1dGJ1ZihicCk7CiAJCXJldHVybjsKKwl9CisJYnAtPmJf ZmxhZ3MgfD0gZmxhZzsKIAotCWlmICgobGlvcCA9IChsaWJ4ZnNfbGlvX3JlcV90 ICopIGxpYnhmc19nZXRfbGlvX2J1ZmZlcihMSUJYRlNfTElPX1RZUEVfRElSKSkg PT0gTlVMTCkgewotCQlyZXR1cm47CisJcHRocmVhZF9tdXRleF9sb2NrKCZhcmdz LT5sb2NrKTsKKworCWlmIChmc2JubyA+IGFyZ3MtPmxhc3RfYm5vX3JlYWQpIHsK KwkJcmFkaXhfdHJlZV9pbnNlcnQoJmFyZ3MtPnByaW1hcnlfaW9fcXVldWUsIGZz Ym5vLCBicCk7CisJCWlmIChmbGFnID09IEJfTUVUQSkKKwkJCXJhZGl4X3RyZWVf dGFnX3NldCgmYXJncy0+cHJpbWFyeV9pb19xdWV1ZSwgZnNibm8sIDApOworCQll bHNlIHsKKwkJCWFyZ3MtPmlub2RlX2J1ZnNfcXVldWVkKys7CisJCQlpZiAoYXJn cy0+aW5vZGVfYnVmc19xdWV1ZWQgPT0gSU9fVEhSRVNIT0xEKQorCQkJCXBmX3N0 YXJ0X2lvX3dvcmtlcnMoYXJncyk7CisJCX0KKyNpZmRlZiBYUl9QRl9UUkFDRQor CQlwZnRyYWNlKCJnZXRidWYgJXAgKCVsbHUpIGluIEFHICVkIChmc2JubyA9ICVs dSkgYWRkZWQgdG8gIgorCQkJInByaW1hcnkgcXVldWUgKGlub2RlX2J1ZnNfcXVl dWVkID0gJWQsIGxhc3RfYm5vID0gJWx1KSIsIGJwLAorCQkJKGxvbmcgbG9uZylY RlNfQlVGX0FERFIoYnApLCBhcmdzLT5hZ25vLCBmc2JubywKKwkJCWFyZ3MtPmlu b2RlX2J1ZnNfcXVldWVkLCBhcmdzLT5sYXN0X2Jub19yZWFkKTsKKyNlbmRpZgor CX0gZWxzZSB7CisJCUFTU0VSVChmbGFnID09IEJfTUVUQSk7CisJCXJhZGl4X3Ry ZWVfaW5zZXJ0KCZhcmdzLT5zZWNvbmRhcnlfaW9fcXVldWUsIGZzYm5vLCBicCk7 CisjaWZkZWYgWFJfUEZfVFJBQ0UKKwkJcGZ0cmFjZSgiZ2V0YnVmICVwICglbGx1 KSBpbiBBRyAlZCAoZnNibm8gPSAlbHUpIGFkZGVkIHRvICIKKwkJCSJzZWNvbmRh cnkgcXVldWUgKGxhc3RfYm5vID0gJWx1KSIsIGJwLAorCQkJKGxvbmcgbG9uZylY RlNfQlVGX0FERFIoYnApLCBhcmdzLT5hZ25vLCBmc2JubywKKwkJCWFyZ3MtPmxh c3RfYm5vX3JlYWQpOworI2VuZGlmCiAJfQogCi0JZm9yIChpID0gMDsgaSA8IElO VF9HRVQobm9kZS0+aGRyLmNvdW50LCBBUkNIX0NPTlZFUlQpOyBpKyspIHsKLQkJ aWYgKGkgPT0gbGlieGZzX2xpb19kaXJfY291bnQpCi0JCQlicmVhazsKKwlwZl9z dGFydF9wcm9jZXNzaW5nKGFyZ3MpOwogCi0JCWZzYm5vID0gYmxrbWFwX2dldChk YV9jdXJzb3ItPmJsa21hcCwgSU5UX0dFVChub2RlLT5idHJlZVtpXS5iZWZvcmUs IEFSQ0hfQ09OVkVSVCkpOwotCQlpZiAoZnNibm8gPT0gTlVMTERGU0JOTykgewot CQkJbGlieGZzX3B1dF9saW9fYnVmZmVyKCh2b2lkICopIGxpb3ApOwotCQkJcmV0 dXJuOwotCQl9CisJcHRocmVhZF9tdXRleF91bmxvY2soJmFyZ3MtPmxvY2spOwor fQogCi0JCWxpb3BbaV0uYmxrbm8gPSBYRlNfRlNCX1RPX0RBRERSKG1wLCBmc2Ju byk7Ci0JCWxpb3BbaV0ubGVuID0gIFhGU19GU0JfVE9fQkIobXAsIDEpOworc3Rh dGljIGludAorcGZfcmVhZF9ibWJ0X3JlY2xpc3QoCisJcHJlZmV0Y2hfYXJnc190 CQkqYXJncywKKwl4ZnNfYm1idF9yZWNfdAkJKnJwLAorCWludAkJCW51bXJlY3Mp Cit7CisJaW50CQkJaTsKKwl4ZnNfZGZzYm5vX3QJCXM7CQkvKiBzdGFydCAqLwor CXhmc19kZmlsYmxrc190CQljOwkJLyogY291bnQgKi8KKwl4ZnNfZGZpbG9mZl90 CQlvOwkJLyogb2Zmc2V0ICovCisJeGZzX2RmaWxibGtzX3QJCWNwID0gMDsJCS8q IHByZXYgY291bnQgKi8KKwl4ZnNfZGZpbG9mZl90CQlvcCA9IDA7CQkvKiBwcmV2 IG9mZnNldCAqLworCWludAkJCWZsYWc7CQkvKiBleHRlbnQgZmxhZyAqLworCisJ Zm9yIChpID0gMDsgaSA8IG51bXJlY3M7IGkrKywgcnArKykgeworCQljb252ZXJ0 X2V4dGVudCgoeGZzX2JtYnRfcmVjXzMyX3QqKXJwLCAmbywgJnMsICZjLCAmZmxh Zyk7CisKKwkJaWYgKCgoaSA+IDApICYmIChvcCArIGNwID4gbykpIHx8IChjID09 IDApIHx8CisJCQkJKG8gPj0gZnNfbWF4X2ZpbGVfb2Zmc2V0KSkKKwkJCXJldHVy biAwOworCisJCWlmICghdmVyaWZ5X2Rmc2JubyhtcCwgcykgfHwgIXZlcmlmeV9k ZnNibm8obXAsIHMgKyBjIC0gMSkpCisJCQlyZXR1cm4gMDsKKworCQlvcCA9IG87 CisJCWNwID0gYzsKKworCQl3aGlsZSAoYykgeworI2lmZGVmIFhSX1BGX1RSQUNF CisJCQlwZnRyYWNlKCJxdWV1aW5nIGRpciBleHRlbnQgaW4gQUcgJWQiLCBhcmdz LT5hZ25vKTsKKyNlbmRpZgorCQkJcGZfcXVldWVfaW8oYXJncywgcywgMSwgQl9N RVRBKTsKKwkJCWMtLTsKKwkJCXMrKzsKKwkJfQogCX0KKwlyZXR1cm4gMTsKK30K IAotCWlmIChpID4gMSkgewotCQlpZiAobGlieGZzX3JlYWRidWZfbGlzdChtcC0+ bV9kZXYsIGksICh2b2lkICopIGxpb3AsIExJQlhGU19MSU9fVFlQRV9ESVIpID09 IC0xKQotCQkJZG9fcHJlZmV0Y2ggPSAwOwotCX0KKy8qCisgKiBzaW1wbGlmaWVk IHZlcnNpb24gb2YgdGhlIG1haW4gc2Nhbl9sYnRyZWUuIFJldHVybnMgMCB0byBz dG9wLgorICovCisKK3N0YXRpYyBpbnQKK3BmX3NjYW5fbGJ0cmVlKAorCXhmc19k ZnNibm9fdAkJZGJubywKKwlpbnQJCQlsZXZlbCwKKwlwcmVmZXRjaF9hcmdzX3QJ CSphcmdzLAorCWludAkJCSgqZnVuYykoeGZzX2J0cmVlX2xibG9ja190CSpibG9j aywKKwkJCQkJaW50CQkJbGV2ZWwsCisJCQkJCXByZWZldGNoX2FyZ3NfdAkJKmFy Z3MpKQoreworCXhmc19idWZfdAkJKmJwOworCWludAkJCXJjOworCisJYnAgPSBs aWJ4ZnNfcmVhZGJ1ZihtcC0+bV9kZXYsIFhGU19GU0JfVE9fREFERFIobXAsIGRi bm8pLAorCQkJWEZTX0ZTQl9UT19CQihtcCwgMSksIDApOworCWlmICghYnApCisJ CXJldHVybiAwOwogCi0JbGlieGZzX3B1dF9saW9fYnVmZmVyKCh2b2lkICopIGxp b3ApOwotCXJldHVybjsKKwlyYyA9ICgqZnVuYykoKHhmc19idHJlZV9sYmxvY2tf dCAqKVhGU19CVUZfUFRSKGJwKSwgbGV2ZWwgLSAxLCBhcmdzKTsKKworCWxpYnhm c19wdXRidWYoYnApOworCisJcmV0dXJuIHJjOwogfQogCi12b2lkCi1wcmVmZXRj aF9kaXIxKAotCXhmc19tb3VudF90CQkqbXAsCi0JeGZzX2RhYmxrX3QJCWJubywK LQlkYV9idF9jdXJzb3JfdAkJKmRhX2N1cnNvcikKK3N0YXRpYyBpbnQKK3BmX3Nj YW5mdW5jX2JtYXAoCisJeGZzX2J0cmVlX2xibG9ja190CSpibG9jaywKKwlpbnQJ CQlsZXZlbCwKKwlwcmVmZXRjaF9hcmdzX3QJCSphcmdzKQogewotCXhmc19kYV9p bnRub2RlX3QJKm5vZGU7Ci0JeGZzX2J1Zl90CQkqYnA7Ci0JeGZzX2Rmc2Jub190 CQlmc2JubzsKKwl4ZnNfYm1idF9yZWNfdAkJKnJwOworCXhmc19ibWJ0X3B0cl90 CQkqcHA7CisJaW50IAkJCW51bXJlY3M7CiAJaW50CQkJaTsKKwl4ZnNfZGZzYm5v X3QJCWRibm87CiAKLQlmc2JubyA9IGJsa21hcF9nZXQoZGFfY3Vyc29yLT5ibGtt YXAsIGJubyk7Ci0JaWYgKGZzYm5vID09IE5VTExERlNCTk8pCi0JCXJldHVybjsK KwkvKgorCSAqIGRvIHNvbWUgdmFsaWRhdGlvbiBvbiB0aGUgYmxvY2sgY29udGVu dHMKKwkgKi8KKwlpZiAoKGJlMzJfdG9fY3B1KGJsb2NrLT5iYl9tYWdpYykgIT0g WEZTX0JNQVBfTUFHSUMpIHx8CisJCQkoYmUxNl90b19jcHUoYmxvY2stPmJiX2xl dmVsKSAhPSBsZXZlbCkpCisJCXJldHVybiAwOwogCi0JYnAgPSBsaWJ4ZnNfcmVh ZGJ1ZihtcC0+bV9kZXYsIFhGU19GU0JfVE9fREFERFIobXAsIGZzYm5vKSwKLQkJ CVhGU19GU0JfVE9fQkIobXAsIDEpLCAwKTsKKwludW1yZWNzID0gYmUxNl90b19j cHUoYmxvY2stPmJiX251bXJlY3MpOwogCi0JaWYgKGJwID09IE5VTEwpCi0JIAly ZXR1cm47CisJaWYgKGxldmVsID09IDApIHsKKwkJaWYgKG51bXJlY3MgPiBtcC0+ bV9ibWFwX2RteHJbMF0pCisJCQlyZXR1cm4gMDsKIAorCQlycCA9IFhGU19CVFJF RV9SRUNfQUREUihtcC0+bV9zYi5zYl9ibG9ja3NpemUsIHhmc19ibWJ0LAorCQkJ CWJsb2NrLCAxLCBtcC0+bV9ibWFwX2RteHJbMF0pOwogCi0Jbm9kZSA9ICh4ZnNf ZGFfaW50bm9kZV90ICopWEZTX0JVRl9QVFIoYnApOwotCWlmIChJTlRfR0VUKG5v ZGUtPmhkci5pbmZvLm1hZ2ljLCBBUkNIX0NPTlZFUlQpICE9IFhGU19EQV9OT0RF X01BR0lDKSAgewotCQlsaWJ4ZnNfcHV0YnVmKGJwKTsKLQkJcmV0dXJuOworCQly ZXR1cm4gcGZfcmVhZF9ibWJ0X3JlY2xpc3QoYXJncywgcnAsIG51bXJlY3MpOwog CX0KIAotCXByZWZldGNoX25vZGUobXAsIGJwLCBkYV9jdXJzb3IpOworCWlmIChu dW1yZWNzID4gbXAtPm1fYm1hcF9kbXhyWzFdKQorCQlyZXR1cm4gMDsKIAotCS8q IHNraXAgcHJlZmV0Y2hpbmcgaWYgbmV4dCBsZXZlbCBpcyBsZWFmIGxldmVsICov Ci0JaWYgKElOVF9HRVQobm9kZS0+aGRyLmxldmVsLCBBUkNIX0NPTlZFUlQpID4g MSkgewotCQlmb3IgKGkgPSAwOyBpIDwgSU5UX0dFVChub2RlLT5oZHIuY291bnQs IEFSQ0hfQ09OVkVSVCk7IGkrKykgewotCQkJcHJlZmV0Y2hfZGlyMShtcCwKLQkJ CQlJTlRfR0VUKG5vZGUtPmJ0cmVlW2ldLmJlZm9yZSwgQVJDSF9DT05WRVJUKSwK LQkJCQlkYV9jdXJzb3IpOwotCQl9CisJcHAgPSBYRlNfQlRSRUVfUFRSX0FERFIo bXAtPm1fc2Iuc2JfYmxvY2tzaXplLCB4ZnNfYm1idCwgYmxvY2ssIDEsCisJCQlt cC0+bV9ibWFwX2RteHJbMV0pOworCisJZm9yIChpID0gMDsgaSA8IG51bXJlY3M7 IGkrKykgeworCQlkYm5vID0gYmU2NF90b19jcHUocHBbaV0pOworCQlpZiAoIXZl cmlmeV9kZnNibm8obXAsIGRibm8pKQorCQkJcmV0dXJuIDA7CisJCWlmICghcGZf c2Nhbl9sYnRyZWUoZGJubywgbGV2ZWwsIGFyZ3MsIHBmX3NjYW5mdW5jX2JtYXAp KQorCQkJcmV0dXJuIDA7CiAJfQotCQotCWxpYnhmc19wdXRidWYoYnApOwotCXJl dHVybjsKKwlyZXR1cm4gMTsKIH0KIAotdm9pZAotcHJlZmV0Y2hfZGlyMigKLQl4 ZnNfbW91bnRfdCAgICAgKm1wLAotCWJsa21hcF90ICAgICAgICAqYmxrbWFwKQot ewotCXhmc19kZmlsb2ZmX3QJCWRibm87Ci0JeGZzX2RmaWxvZmZfdAkJcGRibm87 Ci0JYm1hcF9leHRfdAkJKmJtcDsJCi0JaW50CQkJbmV4OwotCWludAkJCWksIGos IHQ7Ci0JbGlieGZzX2xpb19yZXFfdAkqbGlvcDsKIAotCWxpb3AgPSAobGlieGZz X2xpb19yZXFfdCAqKSBsaWJ4ZnNfZ2V0X2xpb19idWZmZXIoTElCWEZTX0xJT19U WVBFX0RJUik7Ci0JaWYgKGxpb3AgPT0gTlVMTCkKK3N0YXRpYyB2b2lkCitwZl9y ZWFkX2J0aW5vZGUoCisJcHJlZmV0Y2hfYXJnc190CQkqYXJncywKKwl4ZnNfZGlu b2RlX3QJCSpkaW5vKQoreworCXhmc19ibWRyX2Jsb2NrX3QJKmRpYjsKKwl4ZnNf Ym1idF9wdHJfdAkJKnBwOworCWludAkJCWk7CisJaW50CQkJbGV2ZWw7CisJaW50 CQkJbnVtcmVjczsKKwlpbnQJCQlkc2l6ZTsKKwl4ZnNfZGZzYm5vX3QJCWRibm87 CisKKwlkaWIgPSAoeGZzX2JtZHJfYmxvY2tfdCAqKVhGU19ERk9SS19EUFRSKGRp bm8pOworCisJbGV2ZWwgPSBiZTE2X3RvX2NwdShkaWItPmJiX2xldmVsKTsKKwlu dW1yZWNzID0gYmUxNl90b19jcHUoZGliLT5iYl9udW1yZWNzKTsKKworCWlmICgo bnVtcmVjcyA9PSAwKSB8fCAobGV2ZWwgPT0gMCkgfHwKKwkJCShsZXZlbCA+IFhG U19CTV9NQVhMRVZFTFMobXAsIFhGU19EQVRBX0ZPUkspKSkKKwkJcmV0dXJuOwor CS8qCisJICogdXNlIGJtZHIvZGZvcmtfZHNpemUgc2luY2UgdGhlIHJvb3QgYmxv Y2sgaXMgaW4gdGhlIGRhdGEgZm9yaworCSAqLworCWlmIChYRlNfQk1EUl9TUEFD RV9DQUxDKG51bXJlY3MpID4gWEZTX0RGT1JLX0RTSVpFKGRpbm8sIG1wKSkKIAkJ cmV0dXJuOwogCi0JcGRibm8gPSBOVUxMREZJTE9GRjsJLyogcHJldmlvdXMgZGJu byBpcyBOVUxMREZJTE9GRiAqLwotCWkgPSAwOwotCXdoaWxlICgoZGJubyA9IGJs a21hcF9uZXh0X29mZihibGttYXAsIHBkYm5vLCAmdCkpIDwgbXAtPm1fZGlyZnJl ZWJsaykgewotCQlpZiAoaSA9PSBsaWJ4ZnNfbGlvX2Rpcl9jb3VudCkKKwlkc2l6 ZSA9IFhGU19ERk9SS19EU0laRShkaW5vLCBtcCk7CisJcHAgPSBYRlNfQlRSRUVf UFRSX0FERFIoZHNpemUsIHhmc19ibWRyLCBkaWIsIDEsCisJCQlYRlNfQlRSRUVf QkxPQ0tfTUFYUkVDUyhkc2l6ZSwgeGZzX2JtZHIsIDApKTsKKworCWZvciAoaSA9 IDA7IGkgPCBudW1yZWNzOyBpKyspIHsKKwkJZGJubyA9IGJlNjRfdG9fY3B1KHBw W2ldKTsKKwkJaWYgKCF2ZXJpZnlfZGZzYm5vKG1wLCBkYm5vKSkKIAkJCWJyZWFr OwotCQlpZiAoZGJubyA9PSBOVUxMREZJTE9GRikKKwkJaWYgKCFwZl9zY2FuX2xi dHJlZShkYm5vLCBsZXZlbCwgYXJncywgcGZfc2NhbmZ1bmNfYm1hcCkpCiAJCQli cmVhazsKLQkJaWYgKG1wLT5tX2RpcmJsa2ZzYnMgPT0gMSkgewotCQkJeGZzX2Rm c2Jub190IGJsazsKLQotCQkJLyogYXZvaWQgYm1wIHJlYWxsb2MvZnJlZSBvdmVy aGVhZCwgdXNlIGJsa21hcF9nZXQgKi8KLQkJCWJsayA9IGJsa21hcF9nZXQoYmxr bWFwLCBkYm5vKTsKLQkJCWlmIChibGsgPT0gTlVMTERGU0JOTykKLQkJCQlicmVh azsKLQkJCXBkYm5vID0gZGJubzsKLQkJCWxpb3BbaV0uYmxrbm8gPSBYRlNfRlNC X1RPX0RBRERSKG1wLCBibGspOwotCQkJbGlvcFtpXS5sZW4gPSAoaW50KSBYRlNf RlNCX1RPX0JCKG1wLCAxKTsKLQkJCWkrKzsKLQkJfQotCQllbHNlIGlmIChtcC0+ bV9kaXJibGtmc2JzID4gMSkgewotCQkJbmV4ID0gYmxrbWFwX2dldG4oYmxrbWFw LCBkYm5vLCBtcC0+bV9kaXJibGtmc2JzLCAmYm1wLCBOVUxMKTsKLQkJCWlmIChu ZXggPT0gMCkKLQkJCQlicmVhazsKLQkJCXBkYm5vID0gZGJubyArIG1wLT5tX2Rp cmJsa2ZzYnMgLSAxOwotCQkJZm9yIChqID0gMDsgaiA8IG5leDsgaisrKSB7Ci0J CQkJbGlvcFtpXS5ibGtubyA9IFhGU19GU0JfVE9fREFERFIobXAsIGJtcFtqXS5z dGFydGJsb2NrKTsKLQkJCQlsaW9wW2ldLmxlbiA9IChpbnQpIFhGU19GU0JfVE9f QkIobXAsIGJtcFtqXS5ibG9ja2NvdW50KTsKLQkJCQlpKys7Ci0JCQkJaWYgKGkg PT0gbGlieGZzX2xpb19kaXJfY291bnQpCi0JCQkJCWJyZWFrOwkvKiBmb3IgbG9v cCAqLwotCQkJfQotCQkJZnJlZShibXApOwotCQl9Ci0JCWVsc2UgewotCQkJZG9f ZXJyb3IoImludmFsaWQgbXAtPm1fZGlyYmxrZnNicyAlZFxuIiwgbXAtPm1fZGly YmxrZnNicyk7Ci0JCX0KLQl9Ci0JaWYgKGkgPiAxKSB7Ci0JCWlmIChsaWJ4ZnNf cmVhZGJ1Zl9saXN0KG1wLT5tX2RldiwgaSwgKHZvaWQgKikgbGlvcCwgTElCWEZT X0xJT19UWVBFX0RJUikgPT0gLTEpCi0JCQlkb19wcmVmZXRjaCA9IDA7CiAJfQot CWxpYnhmc19wdXRfbGlvX2J1ZmZlcigodm9pZCAqKSBsaW9wKTsKIH0KIAogc3Rh dGljIHZvaWQKLXByZWZldGNoX3A2X25vZGUoCi0JeGZzX21vdW50X3QJCSptcCwK LQl4ZnNfaW5vZGVfdAkJKmlwLAotCXhmc19idWZfdAkJKmJwKQorcGZfcmVhZF9l eGlub2RlKAorCXByZWZldGNoX2FyZ3NfdAkJKmFyZ3MsCisJeGZzX2Rpbm9kZV90 CQkqZGlubykKIHsKLQl4ZnNfZGFfaW50bm9kZV90CSpub2RlOwotCWxpYnhmc19s aW9fcmVxX3QJKmxpb3A7Ci0JaW50CQkJaTsKLQl4ZnNfZnNibG9ja190CQlmYmxv Y2s7Ci0JeGZzX2Rmc2Jub190CQlmc2JubzsKLQl4ZnNfYm1idF9pcmVjX3QJCW1h cDsKLQlpbnQJCQlubWFwOwotCWludAkJCWVycm9yOwotCi0Jbm9kZSA9ICh4ZnNf ZGFfaW50bm9kZV90ICopWEZTX0JVRl9QVFIoYnApOwotCWlmIChJTlRfR0VUKG5v ZGUtPmhkci5jb3VudCwgQVJDSF9DT05WRVJUKSA8PSAxKQotCQlyZXR1cm47CisJ cGZfcmVhZF9ibWJ0X3JlY2xpc3QoYXJncywgKHhmc19ibWJ0X3JlY190ICopWEZT X0RGT1JLX0RQVFIoZGlubyksCisJCQliZTMyX3RvX2NwdShkaW5vLT5kaV9jb3Jl LmRpX25leHRlbnRzKSk7Cit9CiAKLQlpZiAoKGxpb3AgPSAobGlieGZzX2xpb19y ZXFfdCAqKSBsaWJ4ZnNfZ2V0X2xpb19idWZmZXIoTElCWEZTX0xJT19UWVBFX0RJ UikpID09IE5VTEwpIHsKLQkJcmV0dXJuOworc3RhdGljIHZvaWQKK3BmX3JlYWRf aW5vZGVfZGlycygKKwlwcmVmZXRjaF9hcmdzX3QJCSphcmdzLAorCXhmc19idWZf dAkJKmJwKQoreworCXhmc19kaW5vZGVfdAkJKmRpbm87CisJaW50CQkJaWNudCA9 IDA7CisJeGZzX2Rpbm9kZV9jb3JlX3QJKmRpbm9jOworCisJZm9yIChpY250ID0g MDsgaWNudCA8IChYRlNfQlVGX0NPVU5UKGJwKSA+PiBtcC0+bV9zYi5zYl9pbm9k ZWxvZyk7IGljbnQrKykgeworCQlkaW5vID0gWEZTX01BS0VfSVBUUihtcCwgYnAs IGljbnQpOworCQlkaW5vYyA9ICZkaW5vLT5kaV9jb3JlOworCisJCS8qCisJCSAq IFdlIGFyZSBvbmx5IHByZWZldGNoaW5nIGRpcmVjdG9yeSBjb250ZW50cyBpbiBl eHRlbnRzCisJCSAqLworCQlpZiAoKChiZTE2X3RvX2NwdShkaW5vYy0+ZGlfbW9k ZSkgJiBTX0lGTVQpICE9IFNfSUZESVIpIHx8CisJCQkJKGRpbm9jLT5kaV9mb3Jt YXQgIT0gWEZTX0RJTk9ERV9GTVRfRVhURU5UUyAmJgorCQkJCWRpbm9jLT5kaV9m b3JtYXQgIT0gWEZTX0RJTk9ERV9GTVRfQlRSRUUpKQorCQkJY29udGludWU7CisK KwkJLyoKKwkJICogZG8gc29tZSBjaGVja3Mgb24gdGhlIGlub2RlIHRvIHNlZSBp ZiB3ZSBjYW4gcHJlZmV0Y2gKKwkJICogaXRzIGRpcmVjdG9yeSBkYXRhLiBJdCdz IGEgY3V0IGRvd24gdmVyc2lvbiBvZgorCQkgKiBwcm9jZXNzX2Rpbm9kZV9pbnQo KSBpbiBkaW5vZGUuYy4KKwkJICovCisJCWlmIChiZTE2X3RvX2NwdShkaW5vYy0+ ZGlfbWFnaWMpICE9IFhGU19ESU5PREVfTUFHSUMpCisJCQljb250aW51ZTsKKwor CQlpZiAoIVhGU19ESU5PREVfR09PRF9WRVJTSU9OKGRpbm9jLT5kaV92ZXJzaW9u KSB8fAorCQkJCSghZnNfaW5vZGVfbmxpbmsgJiYgZGlub2MtPmRpX3ZlcnNpb24g PgorCQkJCQlYRlNfRElOT0RFX1ZFUlNJT05fMSkpCisJCQljb250aW51ZTsKKwor CQlpZiAoYmU2NF90b19jcHUoZGlub2MtPmRpX3NpemUpIDw9IFhGU19ERk9SS19E U0laRShkaW5vLCBtcCkpCisJCQljb250aW51ZTsKKworCQlpZiAoKGRpbm9jLT5k aV9mb3Jrb2ZmICE9IDApICYmCisJCQkJKGRpbm9jLT5kaV9mb3Jrb2ZmID49IChY RlNfTElUSU5PKG1wKSA+PiAzKSkpCisJCQljb250aW51ZTsKKworCQlzd2l0Y2gg KGRpbm9jLT5kaV9mb3JtYXQpIHsKKwkJCWNhc2UgWEZTX0RJTk9ERV9GTVRfRVhU RU5UUzoKKwkJCQlwZl9yZWFkX2V4aW5vZGUoYXJncywgZGlubyk7CisJCQkJYnJl YWs7CisJCQljYXNlIFhGU19ESU5PREVfRk1UX0JUUkVFOgorCQkJCXBmX3JlYWRf YnRpbm9kZShhcmdzLCBkaW5vKTsKKwkJCQlicmVhazsKKwkJfQogCX0KK30KIAot CWZibG9jayA9IE5VTExGU0JMT0NLOwotCi0JZm9yIChpID0gMDsgaSA8IElOVF9H RVQobm9kZS0+aGRyLmNvdW50LCBBUkNIX0NPTlZFUlQpOyBpKyspIHsKLQkJaWYg KGkgPT0gbGlieGZzX2xpb19kaXJfY291bnQpCi0JCQlicmVhazsKKyNkZWZpbmUg TUFYX0JVRlMJMTI4CiAKLQkJbm1hcCA9IDE7Ci0JCWVycm9yID0gbGlieGZzX2Jt YXBpKE5VTEwsIGlwLCAoeGZzX2ZpbGVvZmZfdCkKLQkJCQlJTlRfR0VUKG5vZGUt PmJ0cmVlW2ldLmJlZm9yZSwgQVJDSF9DT05WRVJUKSwgMSwKLQkJCQlYRlNfQk1B UElfTUVUQURBVEEsICZmYmxvY2ssIDAsCi0JCQkJJm1hcCwgJm5tYXAsIE5VTEwp OwordHlwZWRlZiBlbnVtIHBmX3doaWNoCit7CisJUEZfUFJJTUFSWSwKKwlQRl9T RUNPTkRBUlksCisJUEZfTUVUQV9PTkxZCit9IHBmX3doaWNoX3Q7CisKKy8qCisg KiBwZl9iYXRjaF9yZWFkIG11c3QgYmUgY2FsbGVkIHdpdGggdGhlIGxvY2sgbG9j a2VkLgorICovCiAKLQkJaWYgKGVycm9yIHx8IChubWFwICE9IDEpKSB7Ci0JCQls aWJ4ZnNfcHV0X2xpb19idWZmZXIoKHZvaWQgKikgbGlvcCk7Ci0JCQlyZXR1cm47 CitzdGF0aWMgdm9pZAorcGZfYmF0Y2hfcmVhZCgKKwlwcmVmZXRjaF9hcmdzX3QJ CSphcmdzLAorCXBmX3doaWNoX3QJCXdoaWNoLAorCXZvaWQJCQkqYnVmKQorewor CXN0cnVjdCByYWRpeF90cmVlX3Jvb3QJKnF1ZXVlOworCXhmc19idWZfdAkJKmJw bGlzdFtNQVhfQlVGU107CisJdW5zaWduZWQgaW50CQludW07CisJb2ZmNjRfdAkJ CWZpcnN0X29mZiwgbGFzdF9vZmYsIG5leHRfb2ZmOworCWludAkJCWxlbiwgc2l6 ZTsKKwlpbnQJCQlpOworCWludAkJCWlub2RlX2J1ZnM7CisJdW5zaWduZWQgbG9u ZwkJZnNibm87CisJY2hhcgkJCSpwYnVmOworCisJcXVldWUgPSAod2hpY2ggIT0g UEZfU0VDT05EQVJZKSA/ICZhcmdzLT5wcmltYXJ5X2lvX3F1ZXVlCisJCQkJOiAm YXJncy0+c2Vjb25kYXJ5X2lvX3F1ZXVlOworCisJd2hpbGUgKHJhZGl4X3RyZWVf bG9va3VwX2ZpcnN0KHF1ZXVlLCAmZnNibm8pICE9IE5VTEwpIHsKKworCQlpZiAo d2hpY2ggIT0gUEZfTUVUQV9PTkxZKSB7CisJCQludW0gPSByYWRpeF90cmVlX2dh bmdfbG9va3VwX2V4KHF1ZXVlLAorCQkJCQkodm9pZCoqKSZicGxpc3RbMF0sIGZz Ym5vLAorCQkJCQlmc2JubyArIHBmX21heF9mc2JzLCBNQVhfQlVGUyk7CisJCQlB U1NFUlQobnVtID4gMCk7CisJCQlBU1NFUlQoWEZTX0ZTQl9UT19EQUREUihtcCwg ZnNibm8pID09CisJCQkJWEZTX0JVRl9BRERSKGJwbGlzdFswXSkpOworCQl9IGVs c2UgeworCQkJbnVtID0gcmFkaXhfdHJlZV9nYW5nX2xvb2t1cF90YWcocXVldWUs CisJCQkJCSh2b2lkKiopJmJwbGlzdFswXSwgZnNibm8sCisJCQkJCU1BWF9CVUZT IC8gNCwgMCk7CisJCQlpZiAobnVtID09IDApCisJCQkJcmV0dXJuOwogCQl9CiAK LQkJaWYgKChmc2JubyA9IG1hcC5icl9zdGFydGJsb2NrKSA9PSBIT0xFU1RBUlRC TE9DSykgewotCQkJbGlieGZzX3B1dF9saW9fYnVmZmVyKCh2b2lkICopIGxpb3Ap OwotCQkJcmV0dXJuOworCQkvKgorCQkgKiBkbyBhIGJpZyByZWFkIGlmIDI1JSBv ZiB0aGUgcG90ZW50aWFsIGJ1ZmZlciBpcyB1c2VmdWwsCisJCSAqIG90aGVyd2lz ZSwgZmluZCBhcyBtYW55IGNsb3NlIHRvZ2V0aGVyIGJsb2NrcyBhbmQKKwkJICog cmVhZCB0aGVtIGluIG9uZSByZWFkCisJCSAqLworCQlmaXJzdF9vZmYgPSBMSUJY RlNfQkJUT09GRjY0KFhGU19CVUZfQUREUihicGxpc3RbMF0pKTsKKwkJbGFzdF9v ZmYgPSBMSUJYRlNfQkJUT09GRjY0KFhGU19CVUZfQUREUihicGxpc3RbbnVtLTFd KSkgKworCQkJWEZTX0JVRl9TSVpFKGJwbGlzdFtudW0tMV0pOworCQl3aGlsZSAo bGFzdF9vZmYgLSBmaXJzdF9vZmYgPiBwZl9tYXhfYnl0ZXMpIHsKKwkJCW51bS0t OworCQkJbGFzdF9vZmYgPSBMSUJYRlNfQkJUT09GRjY0KFhGU19CVUZfQUREUihi cGxpc3RbbnVtLTFdKSkgKworCQkJCVhGU19CVUZfU0laRShicGxpc3RbbnVtLTFd KTsKKwkJfQorCQlpZiAobnVtIDwgKChsYXN0X29mZiAtIGZpcnN0X29mZikgPj4g KG1wLT5tX3NiLnNiX2Jsb2NrbG9nICsgMykpKSB7CisJCQkvKgorCQkJICogbm90 IGVub3VnaCBibG9ja3MgZm9yIG9uZSBiaWcgcmVhZCwgc28gZGV0ZXJtaW5lCisJ CQkgKiB0aGUgbnVtYmVyIG9mIGJsb2NrcyB0aGF0IGFyZSBjbG9zZSBlbm91Z2gu CisJCQkgKi8KKwkJCWxhc3Rfb2ZmID0gZmlyc3Rfb2ZmICsgWEZTX0JVRl9TSVpF KGJwbGlzdFswXSk7CisJCQlmb3IgKGkgPSAxOyBpIDwgbnVtOyBpKyspIHsKKwkJ CQluZXh0X29mZiA9IExJQlhGU19CQlRPT0ZGNjQoWEZTX0JVRl9BRERSKGJwbGlz dFtpXSkpICsKKwkJCQkJCVhGU19CVUZfU0laRShicGxpc3RbaV0pOworCQkJCWlm IChuZXh0X29mZiAtIGxhc3Rfb2ZmID4gcGZfYmF0Y2hfYnl0ZXMpCisJCQkJCWJy ZWFrOworCQkJCWxhc3Rfb2ZmID0gbmV4dF9vZmY7CisJCQl9CisJCQludW0gPSBp OwogCQl9Ci0JCWxpb3BbaV0uYmxrbm8gPSBYRlNfRlNCX1RPX0RBRERSKG1wLCBm c2Jubyk7Ci0JCWxpb3BbaV0ubGVuID0gIFhGU19GU0JfVE9fQkIobXAsIDEpOwot CX0KIAotCWlmIChpID4gMSkgewotCQlpZiAobGlieGZzX3JlYWRidWZfbGlzdCht cC0+bV9kZXYsIGksICh2b2lkICopIGxpb3AsIExJQlhGU19MSU9fVFlQRV9ESVIp ID09IC0xKQotCQkJZG9fcHJlZmV0Y2ggPSAwOworCQlmb3IgKGkgPSAwOyBpIDwg bnVtOyBpKyspIHsKKwkJCWlmIChyYWRpeF90cmVlX2RlbGV0ZShxdWV1ZSwgWEZT X0RBRERSX1RPX0ZTQihtcCwKKwkJCQkJWEZTX0JVRl9BRERSKGJwbGlzdFtpXSkp KSA9PSBOVUxMKQorCQkJCWRvX2Vycm9yKF8oInByZWZldGNoIGNvcnJ1cHRpb25c biIpKTsKKwkJfQorCisJCWlmICh3aGljaCA9PSBQRl9QUklNQVJZKSB7CisJCQlp ZiAoKGZpcnN0X29mZiA+PiBtcC0+bV9zYi5zYl9ibG9ja2xvZykgPiBwZl9iYXRj aF9mc2JzKQorCQkJCWFyZ3MtPmxhc3RfYm5vX3JlYWQgPSAoZmlyc3Rfb2ZmID4+ IG1wLT5tX3NiLnNiX2Jsb2NrbG9nKTsKKwkJfQorCisJCXB0aHJlYWRfbXV0ZXhf dW5sb2NrKCZhcmdzLT5sb2NrKTsKKworI2lmZGVmIFhSX1BGX1RSQUNFCisJCXBm dHJhY2UoInJlYWRpbmcgYmJzICVsbHUgdG8gJWxsdSAoJWQgYnVmcykgZnJvbSAl cyBxdWV1ZSBpbiBBRyAlZCAobGFzdF9ibm8gPSAlbHUpIiwKKwkJCShsb25nIGxv bmcpWEZTX0JVRl9BRERSKGJwbGlzdFswXSksCisJCQkobG9uZyBsb25nKVhGU19C VUZfQUREUihicGxpc3RbbnVtLTFdKSwgbnVtLAorCQkJKHdoaWNoICE9IFBGX1NF Q09OREFSWSkgPyAicHJpIiA6ICJzZWMiLCBhcmdzLT5hZ25vLAorCQkJYXJncy0+ bGFzdF9ibm9fcmVhZCk7CisjZW5kaWYKKwkJLyoKKwkJICogbm93IHJlYWQgdGhl IGRhdGEgYW5kIHB1dCBpbnRvIHRoZSB4ZnNfYnV0X3QncworCQkgKi8KKwkJbGVu ID0gcHJlYWQ2NChtcF9mZCwgYnVmLCAoaW50KShsYXN0X29mZiAtIGZpcnN0X29m ZiksIGZpcnN0X29mZik7CisJCWlmIChsZW4gPiAwKSB7CisJCQkvKgorCQkJICog Z28gdGhyb3VnaCB0aGUgeGZzX2J1Zl90IGxpc3QgY29weWluZyBmcm9tIHRoZQor CQkJICogcmVhZCBidWZmZXIgaW50byB0aGUgeGZzX2J1Zl90J3MgYW5kIHJlbGVh c2UgdGhlbS4KKwkJCSAqLworCQkJbGFzdF9vZmYgPSBmaXJzdF9vZmY7CisJCQlm b3IgKGkgPSAwOyBpIDwgbnVtOyBpKyspIHsKKworCQkJCXBidWYgPSAoKGNoYXIg KilidWYpICsgKExJQlhGU19CQlRPT0ZGNjQoWEZTX0JVRl9BRERSKGJwbGlzdFtp XSkpIC0gZmlyc3Rfb2ZmKTsKKwkJCQlzaXplID0gWEZTX0JVRl9TSVpFKGJwbGlz dFtpXSk7CisJCQkJaWYgKGxlbiA8IHNpemUpCisJCQkJCWJyZWFrOworCQkJCW1l bWNweShYRlNfQlVGX1BUUihicGxpc3RbaV0pLCBwYnVmLCBzaXplKTsKKwkJCQli cGxpc3RbaV0tPmJfZmxhZ3MgfD0gTElCWEZTX0JfVVBUT0RBVEU7CisJCQkJbGVu IC09IHNpemU7CisJCQkJaWYgKGJwbGlzdFtpXS0+Yl9mbGFncyAmIEJfSU5PREUp CisJCQkJCXBmX3JlYWRfaW5vZGVfZGlycyhhcmdzLCBicGxpc3RbaV0pOworI2lm ZGVmIFhSX1BGX1RSQUNFCisJCQkJcGZ0cmFjZSgicHV0YnVmICVwICglbGx1KSBp biBBRyAlZCIsIGJwbGlzdFtpXSwKKwkJCQkJKGxvbmcgbG9uZylYRlNfQlVGX0FE RFIoYnBsaXN0W2ldKSwKKwkJCQkJYXJncy0+YWdubyk7CisjZW5kaWYKKwkJCX0K KwkJfQorCQlpbm9kZV9idWZzID0gMDsKKwkJZm9yIChpID0gMDsgaSA8IG51bTsg aSsrKSB7CisJCQlpZiAoYnBsaXN0W2ldLT5iX2ZsYWdzICYgQl9JTk9ERSkKKwkJ CQlpbm9kZV9idWZzKys7CisJCQlsaWJ4ZnNfcHV0YnVmKGJwbGlzdFtpXSk7CisJ CX0KKwkJcHRocmVhZF9tdXRleF9sb2NrKCZhcmdzLT5sb2NrKTsKKwkJaWYgKHdo aWNoICE9IFBGX1NFQ09OREFSWSkgeworCQkJYXJncy0+aW5vZGVfYnVmc19xdWV1 ZWQgLT0gaW5vZGVfYnVmczsKKyNpZmRlZiBYUl9QRl9UUkFDRQorCQkJcGZ0cmFj ZSgiaW5vZGVfYnVmc19xdWV1ZWQgZm9yIEFHICVkID0gJWQiLCBhcmdzLT5hZ25v LAorCQkJCWFyZ3MtPmlub2RlX2J1ZnNfcXVldWVkKTsKKyNlbmRpZgorCQkJLyoK KwkJCSAqIGlmIHByaW1hcnkgaW5vZGUgcXVldWUgcnVubmluZyBsb3csIHByb2Nl c3MgbWV0YWRhdGEKKwkJCSAqIGluIGJvdGhzIHF1ZXVlcyB0byBhdm9pZCBJL08g c3RhcnZhdGlvbiBhcyB0aGUKKwkJCSAqIHByb2Nlc3NpbmcgdGhyZWFkIHdvdWxk IGJlIHdhaXRpbmcgZm9yIGEgbWV0YWRhdGEKKwkJCSAqIGJ1ZmZlcgorCQkJICov CisJCQlpZiAod2hpY2ggPT0gUEZfUFJJTUFSWSAmJiAhYXJncy0+cXVldWluZ19k b25lICYmCisJCQkJCWFyZ3MtPmlub2RlX2J1ZnNfcXVldWVkIDwgSU9fVEhSRVNI T0xEKSB7CisjaWZkZWYgWFJfUEZfVFJBQ0UKKwkJCQlwZnRyYWNlKCJyZWFkaW5n IG1ldGFkYXRhIGJ1ZnMgZnJvbSBwcmltYXJ5IHF1ZXVlIGZvciBBRyAlZCIsCisJ CQkJCWFyZ3MtPmFnbm8pOworI2VuZGlmCisJCQkJcGZfYmF0Y2hfcmVhZChhcmdz LCBQRl9NRVRBX09OTFksIGJ1Zik7CisjaWZkZWYgWFJfUEZfVFJBQ0UKKwkJCQlw ZnRyYWNlKCJyZWFkaW5nIGJ1ZnMgZnJvbSBzZWNvbmRhcnkgcXVldWUgZm9yIEFH ICVkIiwKKwkJCQkJYXJncy0+YWdubyk7CisjZW5kaWYKKwkJCQlwZl9iYXRjaF9y ZWFkKGFyZ3MsIFBGX1NFQ09OREFSWSwgYnVmKTsKKwkJCX0KKwkJfQogCX0KK30K IAotCWxpYnhmc19wdXRfbGlvX2J1ZmZlcigodm9pZCAqKSBsaW9wKTsKLQlyZXR1 cm47CitzdGF0aWMgdm9pZCAqCitwZl9pb193b3JrZXIoCisJdm9pZAkJCSpwYXJh bSkKK3sKKwlwcmVmZXRjaF9hcmdzX3QJCSphcmdzID0gcGFyYW07CisJdm9pZAkJ CSpidWYgPSBtZW1hbGlnbihsaWJ4ZnNfZGV2aWNlX2FsaWdubWVudCgpLCBwZl9t YXhfYnl0ZXMpOworCXN0cnVjdCBzY2hlZF9wYXJhbQlzcGFyYW07CisJaW50CQkJ cG9saWN5OworCisJcHRocmVhZF9nZXRzY2hlZHBhcmFtKHB0aHJlYWRfc2VsZigp LCAmcG9saWN5LCAmc3BhcmFtKTsKKwlzcGFyYW0uc2NoZWRfcHJpb3JpdHkrKzsK KwlwdGhyZWFkX3NldHNjaGVkcGFyYW0ocHRocmVhZF9zZWxmKCksIHBvbGljeSwg JnNwYXJhbSk7CisKKwlwdGhyZWFkX211dGV4X2xvY2soJmFyZ3MtPmxvY2spOwor CXdoaWxlICghYXJncy0+cXVldWluZ19kb25lIHx8IGFyZ3MtPnByaW1hcnlfaW9f cXVldWUuaGVpZ2h0KSB7CisKKyNpZmRlZiBYUl9QRl9UUkFDRQorCQlwZnRyYWNl KCJ3YWl0aW5nIHRvIHN0YXJ0IHByZWZldGNoIEkvTyBmb3IgQUcgJWQiLCBhcmdz LT5hZ25vKTsKKyNlbmRpZgorCQl3aGlsZSAoIWFyZ3MtPmNhbl9zdGFydF9yZWFk aW5nICYmICFhcmdzLT5xdWV1aW5nX2RvbmUpCisJCQlwdGhyZWFkX2NvbmRfd2Fp dCgmYXJncy0+c3RhcnRfcmVhZGluZywgJmFyZ3MtPmxvY2spOworI2lmZGVmIFhS X1BGX1RSQUNFCisJCXBmdHJhY2UoInN0YXJ0aW5nIHByZWZldGNoIEkvTyBmb3Ig QUcgJWQiLCBhcmdzLT5hZ25vKTsKKyNlbmRpZgorCQlwZl9iYXRjaF9yZWFkKGFy Z3MsIFBGX1BSSU1BUlksIGJ1Zik7CisJCXBmX2JhdGNoX3JlYWQoYXJncywgUEZf U0VDT05EQVJZLCBidWYpOworCisjaWZkZWYgWFJfUEZfVFJBQ0UKKwkJcGZ0cmFj ZSgicmFuIG91dCBvZiBidWZzIHRvIHByZWZldGNoIGZvciBBRyAlZCIsIGFyZ3Mt PmFnbm8pOworI2VuZGlmCisJCWlmICghYXJncy0+cXVldWluZ19kb25lKQorCQkJ YXJncy0+Y2FuX3N0YXJ0X3JlYWRpbmcgPSAwOworCX0KKwlwdGhyZWFkX211dGV4 X3VubG9jaygmYXJncy0+bG9jayk7CisKKwlmcmVlKGJ1Zik7CisKKyNpZmRlZiBY Ul9QRl9UUkFDRQorCXBmdHJhY2UoImZpbmlzaGVkIHByZWZldGNoIEkvTyBmb3Ig QUcgJWQiLCBhcmdzLT5hZ25vKTsKKyNlbmRpZgorCXJldHVybiBOVUxMOwogfQog Ci12b2lkCi1wcmVmZXRjaF9wNl9kaXIxKAotCXhmc19tb3VudF90CQkqbXAsCi0J eGZzX2lub190CQlpbm8sCi0JeGZzX2lub2RlX3QJCSppcCwKLQl4ZnNfZGFibGtf dAkJZGFfYm5vLAotCXhmc19mc2Jsb2NrX3QJCSpmYmxvY2twKQorc3RhdGljIGlu dAorcGZfY3JlYXRlX3ByZWZldGNoX3RocmVhZCgKKwlwcmVmZXRjaF9hcmdzX3QJ CSphcmdzKTsKKworc3RhdGljIHZvaWQgKgorcGZfcXVldWluZ193b3JrZXIoCisJ dm9pZAkJCSpwYXJhbSkKIHsKLQl4ZnNfZGFfaW50bm9kZV90CSpub2RlOwotCXhm c19idWZfdAkJKmJwOwotCXhmc19kZnNibm9fdAkJZnNibm87Ci0JeGZzX2JtYnRf aXJlY190CQltYXA7Ci0JaW50CQkJbm1hcDsKKwlwcmVmZXRjaF9hcmdzX3QJCSph cmdzID0gcGFyYW07CisJaW50CQkJbnVtX2lub3M7CisJaW5vX3RyZWVfbm9kZV90 CQkqaXJlYzsKKwlpbm9fdHJlZV9ub2RlX3QJCSpjdXJfaXJlYzsKKwlpbnQJCQli bGtzX3Blcl9jbHVzdGVyOworCWludAkJCWlub3NfcGVyX2NsdXN0ZXI7CisJeGZz X2FnYmxvY2tfdAkJYm5vOwogCWludAkJCWk7Ci0JaW50CQkJZXJyb3I7CisJaW50 CQkJZXJyOwogCi0Jbm1hcCA9IDE7Ci0JZXJyb3IgPSBsaWJ4ZnNfYm1hcGkoTlVM TCwgaXAsICh4ZnNfZmlsZW9mZl90KSBkYV9ibm8sIDEsCi0JCQlYRlNfQk1BUElf TUVUQURBVEEsIGZibG9ja3AsIDAsCi0JCQkmbWFwLCAmbm1hcCwgTlVMTCk7Ci0J aWYgKGVycm9yIHx8IChubWFwICE9IDEpKSAgewotCQlyZXR1cm47CisJYmxrc19w ZXJfY2x1c3RlciA9ICBYRlNfSU5PREVfQ0xVU1RFUl9TSVpFKG1wKSA+PiBtcC0+ bV9zYi5zYl9ibG9ja2xvZzsKKwlpZiAoYmxrc19wZXJfY2x1c3RlciA9PSAwKQor CQlibGtzX3Blcl9jbHVzdGVyID0gMTsKKwlpbm9zX3Blcl9jbHVzdGVyID0gYmxr c19wZXJfY2x1c3RlciAqIG1wLT5tX3NiLnNiX2lub3BibG9jazsKKworCWZvciAo aSA9IDA7IGkgPCBQRl9USFJFQURfQ09VTlQ7IGkrKykgeworCQllcnIgPSBwdGhy ZWFkX2NyZWF0ZSgmYXJncy0+aW9fdGhyZWFkc1tpXSwgTlVMTCwKKwkJCQlwZl9p b193b3JrZXIsIGFyZ3MpOworCQlpZiAoZXJyICE9IDApIHsKKwkJCWRvX3dhcm4o XygiZmFpbGVkIHRvIGNyZWF0ZSBwcmVmZXRjaCB0aHJlYWQ6ICVzXG4iKSwKKwkJ CQlzdHJlcnJvcihlcnIpKTsKKwkJCWlmIChpID09IDApIHsKKwkJCQlwZl9zdGFy dF9wcm9jZXNzaW5nKGFyZ3MpOworCQkJCXJldHVybiBOVUxMOworCQkJfQorCQkJ LyoKKwkJCSAqIHNpbmNlIHdlIGhhdmUgYXQgbGVhc3Qgb25lIEkvTyB0aHJlYWQs IHVzZSB0aGVtIGZvcgorCQkJICogcHJlZmV0Y2gKKwkJCSAqLworCQkJYnJlYWs7 CisJCX0KIAl9CiAKLQlpZiAoKGZzYm5vID0gbWFwLmJyX3N0YXJ0YmxvY2spID09 IEhPTEVTVEFSVEJMT0NLKQotCQlyZXR1cm47CisjaWZkZWYgWFJfUEZfVFJBQ0UK KwlwZnRyYWNlKCJzdGFydGluZyBwcmVmZXRjaCBmb3IgQUcgJWQiLCBhcmdzLT5h Z25vKTsKKyNlbmRpZgorCisJZm9yIChpcmVjID0gZmluZGZpcnN0X2lub2RlX3Jl YyhhcmdzLT5hZ25vKTsgaXJlYyAhPSBOVUxMOworCQkJaXJlYyA9IG5leHRfaW5v X3JlYyhpcmVjKSkgeworCisJCWN1cl9pcmVjID0gaXJlYzsKKworCQludW1faW5v cyA9IFhGU19JTk9ERVNfUEVSX0NIVU5LOworCQl3aGlsZSAobnVtX2lub3MgPCBY RlNfSUFMTE9DX0lOT0RFUyhtcCkgJiYgaXJlYyAhPSBOVUxMKSB7CisJCQlpcmVj ID0gbmV4dF9pbm9fcmVjKGlyZWMpOworCQkJbnVtX2lub3MgKz0gWEZTX0lOT0RF U19QRVJfQ0hVTks7CisJCX0KKworCQlpZiAoYXJncy0+ZGlyc19vbmx5ICYmIGN1 cl9pcmVjLT5pbm9faXNhX2RpciA9PSAwKQorCQkJY29udGludWU7CisjaWZkZWYg WFJfUEZfVFJBQ0UKKwkJc2VtX2dldHZhbHVlKCZhcmdzLT5yYV9jb3VudCwgJmkp OworCQlwZnRyYWNlKCJxdWV1aW5nIGlyZWMgJXAgaW4gQUcgJWQsIHNlbSBjb3Vu dCA9ICVkIiwKKwkJCWlyZWMsIGFyZ3MtPmFnbm8sIGkpOworI2VuZGlmCisJCXNl bV93YWl0KCZhcmdzLT5yYV9jb3VudCk7CisKKwkJbnVtX2lub3MgPSAwOworCQli bm8gPSBYRlNfQUdJTk9fVE9fQUdCTk8obXAsIGN1cl9pcmVjLT5pbm9fc3RhcnRu dW0pOworCisJCWRvIHsKKwkJCXBmX3F1ZXVlX2lvKGFyZ3MsIFhGU19BR0JfVE9f RlNCKG1wLCBhcmdzLT5hZ25vLCBibm8pLAorCQkJCQlibGtzX3Blcl9jbHVzdGVy LCBCX0lOT0RFKTsKKwkJCWJubyArPSBibGtzX3Blcl9jbHVzdGVyOworCQkJbnVt X2lub3MgKz0gaW5vc19wZXJfY2x1c3RlcjsKKwkJfSB3aGlsZSAobnVtX2lub3Mg PCBYRlNfSUFMTE9DX0lOT0RFUyhtcCkpOworCX0KKworCXB0aHJlYWRfbXV0ZXhf bG9jaygmYXJncy0+bG9jayk7CisKKyNpZmRlZiBYUl9QRl9UUkFDRQorCXBmdHJh Y2UoImZpbmlzaGVkIHF1ZXVpbmcgaW5vZGVzIGZvciBBRyAlZCAoaW5vZGVfYnVm c19xdWV1ZWQgPSAlZCkiLAorCQlhcmdzLT5hZ25vLCBhcmdzLT5pbm9kZV9idWZz X3F1ZXVlZCk7CisjZW5kaWYKKwlhcmdzLT5xdWV1aW5nX2RvbmUgPSAxOworCXBm X3N0YXJ0X2lvX3dvcmtlcnMoYXJncyk7CisJcGZfc3RhcnRfcHJvY2Vzc2luZyhh cmdzKTsKKwlwdGhyZWFkX211dGV4X3VubG9jaygmYXJncy0+bG9jayk7CisKKwkv KiBub3cgd2FpdCBmb3IgdGhlIHJlYWRlcnMgdG8gZmluaXNoICovCisJZm9yIChp ID0gMDsgaSA8IFBGX1RIUkVBRF9DT1VOVDsgaSsrKQorCQlpZiAoYXJncy0+aW9f dGhyZWFkc1tpXSkKKwkJCXB0aHJlYWRfam9pbihhcmdzLT5pb190aHJlYWRzW2ld LCBOVUxMKTsKKworI2lmZGVmIFhSX1BGX1RSQUNFCisJcGZ0cmFjZSgicHJlZmV0 Y2ggZm9yIEFHICVkIGZpbmlzaGVkIiwgYXJncy0+YWdubyk7CisjZW5kaWYKKwlw dGhyZWFkX211dGV4X2xvY2soJmFyZ3MtPmxvY2spOworCisJQVNTRVJUKGFyZ3Mt PnByaW1hcnlfaW9fcXVldWUuaGVpZ2h0ID09IDApOworCUFTU0VSVChhcmdzLT5z ZWNvbmRhcnlfaW9fcXVldWUuaGVpZ2h0ID09IDApOworCisJYXJncy0+cHJlZmV0 Y2hfZG9uZSA9IDE7CisJaWYgKGFyZ3MtPm5leHRfYXJncykKKwkJcGZfY3JlYXRl X3ByZWZldGNoX3RocmVhZChhcmdzLT5uZXh0X2FyZ3MpOwogCi0JYnAgPSBsaWJ4 ZnNfcmVhZGJ1ZihtcC0+bV9kZXYsIFhGU19GU0JfVE9fREFERFIobXAsIGZzYm5v KSwKLQkJCVhGU19GU0JfVE9fQkIobXAsIDEpLCAwKTsKKwlwdGhyZWFkX211dGV4 X3VubG9jaygmYXJncy0+bG9jayk7CiAKLQlpZiAoYnAgPT0gTlVMTCkKLQkgCXJl dHVybjsKKwlyZXR1cm4gTlVMTDsKK30KIAorc3RhdGljIGludAorcGZfY3JlYXRl X3ByZWZldGNoX3RocmVhZCgKKwlwcmVmZXRjaF9hcmdzX3QJCSphcmdzKQorewor CWludAkJCWVycjsKIAotCW5vZGUgPSAoeGZzX2RhX2ludG5vZGVfdCAqKVhGU19C VUZfUFRSKGJwKTsKLQlpZiAoSU5UX0dFVChub2RlLT5oZHIuaW5mby5tYWdpYywg QVJDSF9DT05WRVJUKSAhPSBYRlNfREFfTk9ERV9NQUdJQykgIHsKLQkJbGlieGZz X3B1dGJ1ZihicCk7Ci0JCXJldHVybjsKKyNpZmRlZiBYUl9QRl9UUkFDRQorCXBm dHJhY2UoImNyZWF0aW5nIHF1ZXVlIHRocmVhZCBmb3IgQUcgJWQiLCBhcmdzLT5h Z25vKTsKKyNlbmRpZgorCWVyciA9IHB0aHJlYWRfY3JlYXRlKCZhcmdzLT5xdWV1 aW5nX3RocmVhZCwgTlVMTCwKKwkJCXBmX3F1ZXVpbmdfd29ya2VyLCBhcmdzKTsK KwlpZiAoZXJyICE9IDApIHsKKwkJZG9fd2FybihfKCJmYWlsZWQgdG8gY3JlYXRl IHByZWZldGNoIHRocmVhZDogJXNcbiIpLAorCQkJc3RyZXJyb3IoZXJyKSk7CisJ CWNsZWFudXBfaW5vZGVfcHJlZmV0Y2goYXJncyk7CiAJfQogCi0JcHJlZmV0Y2hf cDZfbm9kZShtcCwgaXAsIGJwKTsKLQotCS8qIHNraXAgcHJlZmV0Y2hpbmcgaWYg bmV4dCBsZXZlbCBpcyBsZWFmIGxldmVsICovCi0JaWYgKElOVF9HRVQobm9kZS0+ aGRyLmxldmVsLCBBUkNIX0NPTlZFUlQpID4gMSkgewotCQlmb3IgKGkgPSAwOyBp IDwgSU5UX0dFVChub2RlLT5oZHIuY291bnQsIEFSQ0hfQ09OVkVSVCk7IGkrKykg ewotCQkJKHZvaWQpIHByZWZldGNoX3A2X2RpcjEobXAsIGlubywgaXAsCi0JCQkJ SU5UX0dFVChub2RlLT5idHJlZVtpXS5iZWZvcmUsIEFSQ0hfQ09OVkVSVCksCi0J CQkJZmJsb2NrcCk7Ci0JCX0KLQl9Ci0JCi0JbGlieGZzX3B1dGJ1ZihicCk7Ci0J cmV0dXJuOworCXJldHVybiBlcnIgPT0gMDsKIH0KIAotI2RlZmluZQlOTUFQUAk0 Ci0KIHZvaWQKLXByZWZldGNoX3A2X2RpcjIoCi0JeGZzX21vdW50X3QgICAgICpt cCwKLQl4ZnNfaW5vZGVfdAkqaXApCi17Ci0JeGZzX2ZpbGVvZmZfdAkJZGFfYm5v OwotCXhmc19maWxlb2ZmX3QJCW5leHRfZGFfYm5vOwotCWludAkJCWksIGo7Ci0J bGlieGZzX2xpb19yZXFfdAkqbGlvcDsKLQl4ZnNfZnNibG9ja190CQlmc2I7Ci0J aW50CQkJbmZzYjsKLQlpbnQJCQllcnJvcjsKK2luaXRfcHJlZmV0Y2goCisJeGZz X21vdW50X3QJCSpwbXApCit7CisJbXAgPSBwbXA7CisJbXBfZmQgPSBsaWJ4ZnNf ZGV2aWNlX3RvX2ZkKG1wLT5tX2Rldik7CisJcGZfbWF4X2J5dGVzID0gc3lzY29u ZihfU0NfUEFHRV9TSVpFKSA8PCA3OworCXBmX21heF9iYnMgPSBwZl9tYXhfYnl0 ZXMgPj4gQkJTSElGVDsKKwlwZl9tYXhfZnNicyA9IHBmX21heF9ieXRlcyA+PiBt cC0+bV9zYi5zYl9ibG9ja2xvZzsKKwlwZl9iYXRjaF9ieXRlcyA9IERFRl9CQVRD SF9CWVRFUzsKKwlwZl9iYXRjaF9mc2JzID0gREVGX0JBVENIX0JZVEVTID4+ICht cC0+bV9zYi5zYl9ibG9ja2xvZyArIDEpOworfQogCi0JaWYgKChsaW9wID0gKGxp Ynhmc19saW9fcmVxX3QgKikgbGlieGZzX2dldF9saW9fYnVmZmVyKExJQlhGU19M SU9fVFlQRV9ESVIpKSA9PSBOVUxMKSB7Ci0JCXJldHVybjsKLQl9Ci0JaSA9IDA7 Ci0JZm9yIChkYV9ibm8gPSAwLCBuZXh0X2RhX2JubyA9IDA7IG5leHRfZGFfYm5v ICE9IE5VTExGSUxFT0ZGOyBkYV9ibm8gPSBuZXh0X2RhX2JubykgewotCQlpZiAo aSA9PSBsaWJ4ZnNfbGlvX2Rpcl9jb3VudCkKLQkJCWJyZWFrOwotCQluZXh0X2Rh X2JubyA9IGRhX2JubyArIG1wLT5tX2RpcmJsa2ZzYnMgLSAxOwotCQlpZiAobGli eGZzX2JtYXBfbmV4dF9vZmZzZXQoTlVMTCwgaXAsICZuZXh0X2RhX2JubywgWEZT X0RBVEFfRk9SSykpCi0JCQlicmVhazsKK3ByZWZldGNoX2FyZ3NfdCAqCitzdGFy dF9pbm9kZV9wcmVmZXRjaCgKKwl4ZnNfYWdudW1iZXJfdAkJYWdubywKKwlpbnQJ CQlkaXJzX29ubHksCisJcHJlZmV0Y2hfYXJnc190CQkqcHJldl9hcmdzKQorewor CXByZWZldGNoX2FyZ3NfdAkJKmFyZ3M7CiAKLQkJaWYgKG1wLT5tX2RpcmJsa2Zz YnMgPT0gMSkgewotCQkJaWYgKChlcnJvciA9IGxpYnhmc19ibWFwaV9zaW5nbGUo TlVMTCwgaXAsIFhGU19EQVRBX0ZPUkssICZmc2IsIGRhX2JubykpICE9IDApIHsK LQkJCQlsaWJ4ZnNfcHV0X2xpb19idWZmZXIoKHZvaWQgKikgbGlvcCk7Ci0JCQkJ ZG9fcHJlZmV0Y2ggPSAwOwotCQkJCWRvX3dhcm4oInBoYXNlNiBwcmVmZXRjaDog Y2Fubm90IGJtYXAgc2luZ2xlIGJsb2NrIGVyciA9ICVkXG4iLCBlcnJvcik7Ci0J CQkJcmV0dXJuOwotCQkJfQotCQkJaWYgKGZzYiA9PSBOVUxMRlNCTE9DSykgewot CQkJCWxpYnhmc19wdXRfbGlvX2J1ZmZlcigodm9pZCAqKSBsaW9wKTsKLQkJCQly ZXR1cm47Ci0JCQl9CisJaWYgKGFnbm8gPj0gbXAtPm1fc2Iuc2JfYWdjb3VudCB8 fCAhZG9fcHJlZmV0Y2gpCisJCXJldHVybiBOVUxMOwogCi0JCQlsaW9wW2ldLmJs a25vID0gWEZTX0ZTQl9UT19EQUREUihtcCwgZnNiKTsKLQkJCWxpb3BbaV0ubGVu ID0gIFhGU19GU0JfVE9fQkIobXAsIDEpOwotCQkJaSsrOwotCQl9Ci0JCWVsc2Ug aWYgKChuZnNiID0gbXAtPm1fZGlyYmxrZnNicykgPiAxKSB7Ci0JCQl4ZnNfZnNi bG9ja190ICAgZmlyc3RibG9jazsKLQkJCXhmc19ibWJ0X2lyZWNfdCBtYXBbTk1B UFBdOwotCQkJeGZzX2JtYnRfaXJlY190ICptYXBwOwotCQkJaW50ICAgICAgICAg ICAgIG5tYXA7Ci0KLQkJCWlmIChuZnNiID4gTk1BUFApIHsKLSAgICAgICAgICAg ICAgICAgICAgICAgIAltYXBwID0gbWFsbG9jKHNpemVvZigqbWFwcCkgKiBuZnNi KTsKLQkJCQlpZiAobWFwcCA9PSBOVUxMKSB7Ci0JCQkJCWxpYnhmc19wdXRfbGlv X2J1ZmZlcigodm9pZCAqKSBsaW9wKTsKLQkJCQkJZG9fcHJlZmV0Y2ggPSAwOwot CQkJCQlkb193YXJuKCJwaGFzZTYgcHJlZmV0Y2g6IGNhbm5vdCBhbGxvY2F0ZSBt ZW0gZm9yIG1hcFxuIik7Ci0JCQkJCXJldHVybjsKLQkJCQl9Ci0JCQl9Ci0JCQll bHNlIHsKLQkJCQltYXBwID0gbWFwOwotCQkJfQotICAgICAgICAgICAgICAgICAg ICAgICAgZmlyc3RibG9jayA9IE5VTExGU0JMT0NLOwotICAgICAgICAgICAgICAg ICAgICAgICAgbm1hcCA9IG5mc2I7Ci0gICAgICAgICAgICAgICAgICAgICAgICBp ZiAoKGVycm9yID0gbGlieGZzX2JtYXBpKE5VTEwsIGlwLCBkYV9ibm8sCi0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmZzYiwKLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBYRlNfQk1BUElfTUVU QURBVEEgfCBYRlNfQk1BUElfQUZMQUcoWEZTX0RBVEFfRk9SSyksCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmZpcnN0YmxvY2ssIDAs IG1hcHAsICZubWFwLCBOVUxMKSkpIHsKLQkJCQlsaWJ4ZnNfcHV0X2xpb19idWZm ZXIoKHZvaWQgKikgbGlvcCk7Ci0JCQkJZG9fcHJlZmV0Y2ggPSAwOwotCQkJCWRv X3dhcm4oInBoYXNlNiBwcmVmZXRjaDogY2Fubm90IGJtYXAgZXJyID0gJWRcbiIs IGVycm9yKTsKLQkJCQlyZXR1cm47Ci0JCQl9Ci0JCQlmb3IgKGogPSAwOyBqIDwg bm1hcDsgaisrKSB7Ci0JCQkJbGlvcFtpXS5ibGtubyA9IFhGU19GU0JfVE9fREFE RFIobXAsIG1hcHBbal0uYnJfc3RhcnRibG9jayk7Ci0JCQkJbGlvcFtpXS5sZW4g PSAoaW50KVhGU19GU0JfVE9fQkIobXAsIG1hcHBbal0uYnJfYmxvY2tjb3VudCk7 Ci0JCQkJaSsrOwotCQkJCWlmIChpID09IGxpYnhmc19saW9fZGlyX2NvdW50KQot CQkJCQlicmVhazsgLyogZm9yIGxvb3AgKi8KLQkJCX0KLQkJCWlmIChtYXBwICE9 IG1hcCkKLQkJCQlmcmVlKG1hcHApOworCWFyZ3MgPSBjYWxsb2MoMSwgc2l6ZW9m KHByZWZldGNoX2FyZ3NfdCkpOwogCi0JCX0KLQkJZWxzZSB7Ci0JCQlkb19lcnJv cigicGhhc2U2OiBpbnZhbGlkIG1wLT5tX2RpcmJsa2ZzYnMgJWRcbiIsIG1wLT5t X2RpcmJsa2ZzYnMpOwotCQl9Ci0JfQotCWlmIChpID4gMSkgewotCQlpZiAobGli eGZzX3JlYWRidWZfbGlzdChtcC0+bV9kZXYsIGksICh2b2lkICopIGxpb3AsIExJ QlhGU19MSU9fVFlQRV9ESVIpID09IC0xKQotCQkJZG9fcHJlZmV0Y2ggPSAwOwor CUlOSVRfUkFESVhfVFJFRSgmYXJncy0+cHJpbWFyeV9pb19xdWV1ZSwgMCk7CisJ SU5JVF9SQURJWF9UUkVFKCZhcmdzLT5zZWNvbmRhcnlfaW9fcXVldWUsIDApOwor CXB0aHJlYWRfbXV0ZXhfaW5pdCgmYXJncy0+bG9jaywgTlVMTCk7CisJcHRocmVh ZF9jb25kX2luaXQoJmFyZ3MtPnN0YXJ0X3JlYWRpbmcsIE5VTEwpOworCXB0aHJl YWRfY29uZF9pbml0KCZhcmdzLT5zdGFydF9wcm9jZXNzaW5nLCBOVUxMKTsKKwlh cmdzLT5hZ25vID0gYWdubzsKKwlhcmdzLT5kaXJzX29ubHkgPSBkaXJzX29ubHk7 CisKKwkvKgorCSAqIHVzZSBvbmx5IDEvNCBvZiB0aGUgbGlieGZzIGNhY2hlIGFz IHdlIGFyZSBvbmx5IGNvdW50aW5nIGlub2RlcworCSAqIGFuZCBub3QgYW55IG90 aGVyIGFzc29jaWF0ZWQgbWV0YWRhdGEgbGlrZSBkaXJlY3RvcmllcworCSAqLwor CisJc2VtX2luaXQoJmFyZ3MtPnJhX2NvdW50LCAwLCBsaWJ4ZnNfYmNhY2hlLT5j X21heGNvdW50IC8gdGhyZWFkX2NvdW50IC8KKwkJKFhGU19JQUxMT0NfQkxPQ0tT KG1wKSAvIChYRlNfSU5PREVfQ0xVU1RFUl9TSVpFKG1wKSA+PiBtcC0+bV9zYi5z Yl9ibG9ja2xvZykpIC8gNCk7CisKKwlpZiAoIXByZXZfYXJncykgeworCQlpZiAo IXBmX2NyZWF0ZV9wcmVmZXRjaF90aHJlYWQoYXJncykpCisJCQlyZXR1cm4gTlVM TDsKKwl9IGVsc2UgeworCQlwdGhyZWFkX211dGV4X2xvY2soJnByZXZfYXJncy0+ bG9jayk7CisJCWlmIChwcmV2X2FyZ3MtPnByZWZldGNoX2RvbmUpIHsKKwkJCWlm ICghcGZfY3JlYXRlX3ByZWZldGNoX3RocmVhZChhcmdzKSkKKwkJCQlhcmdzID0g TlVMTDsKKwkJfSBlbHNlCisJCQlwcmV2X2FyZ3MtPm5leHRfYXJncyA9IGFyZ3M7 CisJCXB0aHJlYWRfbXV0ZXhfdW5sb2NrKCZwcmV2X2FyZ3MtPmxvY2spOwogCX0K LQlsaWJ4ZnNfcHV0X2xpb19idWZmZXIoKHZvaWQgKikgbGlvcCk7CisKKwlyZXR1 cm4gYXJnczsKIH0KIAogdm9pZAotcHJlZmV0Y2hfc2IoeGZzX21vdW50X3QgKm1w LCB4ZnNfYWdudW1iZXJfdCAgYWdubykKK3dhaXRfZm9yX2lub2RlX3ByZWZldGNo KAorCXByZWZldGNoX2FyZ3NfdAkJKmFyZ3MpCiB7Ci0JbGlieGZzX2xpb19yZXFf dAkqbGlvcDsKLQotCWlmICgobGlvcCA9IChsaWJ4ZnNfbGlvX3JlcV90ICopIGxp Ynhmc19nZXRfbGlvX2J1ZmZlcihMSUJYRlNfTElPX1RZUEVfUkFXKSkgPT0gTlVM TCkgewotCQlkb19wcmVmZXRjaCA9IDA7CisJaWYgKGFyZ3MgPT0gTlVMTCkKIAkJ cmV0dXJuOwotCX0KIAotCWxpb3BbMF0uYmxrbm8gPSBYRlNfQUdfREFERFIobXAs IGFnbm8sIFhGU19TQl9EQUREUik7Ci0JbGlvcFsxXS5ibGtubyA9IFhGU19BR19E QUREUihtcCwgYWdubywgWEZTX0FHRl9EQUREUihtcCkpOwotCWxpb3BbMl0uYmxr bm8gPSBYRlNfQUdfREFERFIobXAsIGFnbm8sIFhGU19BR0lfREFERFIobXApKTsK LQlsaW9wWzBdLmxlbiA9IFhGU19GU1NfVE9fQkIobXAsIDEpOwotCWxpb3BbMV0u bGVuID0gWEZTX0ZTU19UT19CQihtcCwgMSk7Ci0JbGlvcFsyXS5sZW4gPSBYRlNf RlNTX1RPX0JCKG1wLCAxKTsKLQlpZiAobGlieGZzX3JlYWRidWZfbGlzdChtcC0+ bV9kZXYsIDMsICh2b2lkICopIGxpb3AsIExJQlhGU19MSU9fVFlQRV9SQVcpID09 IC0xKQotCQlkb19wcmVmZXRjaCA9IDA7CisJcHRocmVhZF9tdXRleF9sb2NrKCZh cmdzLT5sb2NrKTsKIAotCWxpYnhmc19wdXRfbGlvX2J1ZmZlcigodm9pZCAqKSBs aW9wKTsKKwl3aGlsZSAoIWFyZ3MtPmNhbl9zdGFydF9wcm9jZXNzaW5nKSB7Cisj aWZkZWYgWFJfUEZfVFJBQ0UKKwkJcGZ0cmFjZSgid2FpdGluZyB0byBzdGFydCBw cm9jZXNzaW5nIEFHICVkIiwgYXJncy0+YWdubyk7CisjZW5kaWYKKwkJcHRocmVh ZF9jb25kX3dhaXQoJmFyZ3MtPnN0YXJ0X3Byb2Nlc3NpbmcsICZhcmdzLT5sb2Nr KTsKKwl9CisjaWZkZWYgWFJfUEZfVFJBQ0UKKwlwZnRyYWNlKCJjYW4gc3RhcnQg cHJvY2Vzc2luZyBBRyAlZCIsIGFyZ3MtPmFnbm8pOworI2VuZGlmCisJcHRocmVh ZF9tdXRleF91bmxvY2soJmFyZ3MtPmxvY2spOwogfQogCiB2b2lkCi1wcmVmZXRj aF9yb290cyh4ZnNfbW91bnRfdCAqbXAsIHhmc19hZ251bWJlcl90IGFnbm8sCi0J CXhmc19hZ2ZfdCAqYWdmLCB4ZnNfYWdpX3QgKmFnaSkKK2NsZWFudXBfaW5vZGVf cHJlZmV0Y2goCisJcHJlZmV0Y2hfYXJnc190CQkqYXJncykKIHsKLQlpbnQJCQlp OwotCWxpYnhmc19saW9fcmVxX3QJKmxpb3A7Ci0KLQlpZiAoKGxpb3AgPSAobGli eGZzX2xpb19yZXFfdCAqKSBsaWJ4ZnNfZ2V0X2xpb19idWZmZXIoTElCWEZTX0xJ T19UWVBFX1JBVykpID09IE5VTEwpIHsKLQkJZG9fcHJlZmV0Y2ggPSAwOworCWlm IChhcmdzID09IE5VTEwpCiAJCXJldHVybjsKLQl9CiAKLQlpID0gMDsKLQlpZiAo YWdmLT5hZ2Zfcm9vdHNbWEZTX0JUTlVNX0JOT10gIT0gMCAmJgotCQkJdmVyaWZ5 X2FnYm5vKG1wLCBhZ25vLCBhZ2YtPmFnZl9yb290c1tYRlNfQlROVU1fQk5PXSkp IHsKLQkJbGlvcFtpXS5ibGtubyA9IFhGU19BR0JfVE9fREFERFIobXAsIGFnbm8s IGFnZi0+YWdmX3Jvb3RzW1hGU19CVE5VTV9CTk9dKTsKLQkJbGlvcFtpXS5sZW4g PSBYRlNfRlNCX1RPX0JCKG1wLCAxKTsKLQkJaSsrOwotCX0KLQlpZiAoYWdmLT5h Z2Zfcm9vdHNbWEZTX0JUTlVNX0NOVF0gIT0gMCAmJgotCQkJdmVyaWZ5X2FnYm5v KG1wLCBhZ25vLCBhZ2YtPmFnZl9yb290c1tYRlNfQlROVU1fQ05UXSkpIHsKLQkJ bGlvcFtpXS5ibGtubyA9IFhGU19BR0JfVE9fREFERFIobXAsIGFnbm8sIGFnZi0+ YWdmX3Jvb3RzW1hGU19CVE5VTV9DTlRdKTsKLQkJbGlvcFtpXS5sZW4gPSBYRlNf RlNCX1RPX0JCKG1wLCAxKTsKLQkJaSsrOwotCX0KLQlpZiAoYWdpLT5hZ2lfcm9v dCAhPSAwICYmIHZlcmlmeV9hZ2JubyhtcCwgYWdubywgYWdpLT5hZ2lfcm9vdCkp IHsKLQkJbGlvcFtpXS5ibGtubyA9IFhGU19BR0JfVE9fREFERFIobXAsIGFnbm8s IGFnaS0+YWdpX3Jvb3QpOwotCQlsaW9wW2ldLmxlbiA9IFhGU19GU0JfVE9fQkIo bXAsIDEpOwotCQlpKys7Ci0JfQotCWlmIChpID4gMSkgewotCQlpZiAobGlieGZz X3JlYWRidWZfbGlzdChtcC0+bV9kZXYsIGksICh2b2lkICopIGxpb3AsIExJQlhG U19MSU9fVFlQRV9SQVcpID09IC0xKQotCQkJZG9fcHJlZmV0Y2ggPSAwOwotCX0K KyNpZmRlZiBYUl9QRl9UUkFDRQorCXBmdHJhY2UoIndhaXRpbmcgQUcgJWQgcHJl ZmV0Y2ggdG8gZmluaXNoIiwgYXJncy0+YWdubyk7CisjZW5kaWYKKwlpZiAoYXJn cy0+cXVldWluZ190aHJlYWQpCisJCXB0aHJlYWRfam9pbihhcmdzLT5xdWV1aW5n X3RocmVhZCwgTlVMTCk7CisKKyNpZmRlZiBYUl9QRl9UUkFDRQorCXBmdHJhY2Uo IkFHICVkIHByZWZldGNoIGRvbmUiLCBhcmdzLT5hZ25vKTsKKyNlbmRpZgorCXB0 aHJlYWRfbXV0ZXhfZGVzdHJveSgmYXJncy0+bG9jayk7CisJcHRocmVhZF9jb25k X2Rlc3Ryb3koJmFyZ3MtPnN0YXJ0X3JlYWRpbmcpOworCXB0aHJlYWRfY29uZF9k ZXN0cm95KCZhcmdzLT5zdGFydF9wcm9jZXNzaW5nKTsKKwlzZW1fZGVzdHJveSgm YXJncy0+cmFfY291bnQpOworCisJZnJlZShhcmdzKTsKK30KKworI2lmZGVmIFhS X1BGX1RSQUNFCiAKLQlsaWJ4ZnNfcHV0X2xpb19idWZmZXIoKHZvaWQgKikgbGlv cCk7Cit2b2lkCitfcGZ0cmFjZShjb25zdCBjaGFyICpmdW5jLCBjb25zdCBjaGFy ICptc2csIC4uLikKK3sKKwljaGFyCQlidWZbMTI4XTsKKwlzdHJ1Y3QgdGltZXZh bAl0djsKKwl2YV9saXN0IAlhcmdzOworCisJZ2V0dGltZW9mZGF5KCZ0diwgTlVM TCk7CisKKwl2YV9zdGFydChhcmdzLCBtc2cpOworCXZzbnByaW50ZihidWYsIHNp emVvZihidWYpLCBtc2csIGFyZ3MpOworCWJ1ZltzaXplb2YoYnVmKS0xXSA9ICdc MCc7CisJdmFfZW5kKGFyZ3MpOworCisJZnByaW50ZihwZl90cmFjZV9maWxlLCAi JWx1LiUwNmx1ICAlczogJXNcbiIsIHR2LnR2X3NlYywgdHYudHZfdXNlYywgZnVu YywgYnVmKTsKIH0KKworI2VuZGlmCkluZGV4OiByZXBhaXIveGZzcHJvZ3MvcmVw YWlyL3ByZWZldGNoLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gcmVwYWlyLm9y aWcveGZzcHJvZ3MvcmVwYWlyL3ByZWZldGNoLmgJMjAwNy0wNC0yNyAxMzoxMzoz NS4wMDAwMDAwMDAgKzEwMDAKKysrIHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvcHJl ZmV0Y2guaAkyMDA3LTA2LTA1IDEyOjA3OjIyLjUwMjI3MjU3MiArMTAwMApAQCAt MSw0NSArMSw1OSBAQAogI2lmbmRlZiBfWEZTX1JFUEFJUl9QUkVGRVRDSF9ICiAj ZGVmaW5lCV9YRlNfUkVQQUlSX1BSRUZFVENIX0gKIAotc3RydWN0IGJsa21hcDsK LXN0cnVjdCBkYV9idF9jdXJzb3I7Ci1zdHJ1Y3QgeGZzX21vdW50OwotCi1leHRl cm4gCWludCBkb19wcmVmZXRjaDsKLQotc3RydWN0IGlub190cmVlX25vZGUgKnBy ZWZldGNoX2lub2RlX2NodW5rcygKLQlzdHJ1Y3QgeGZzX21vdW50ICosCi0JeGZz X2FnbnVtYmVyX3QsCi0Jc3RydWN0IGlub190cmVlX25vZGUgKik7Ci0KLWV4dGVy biB2b2lkIHByZWZldGNoX2RpcjEoCi0Jc3RydWN0IHhmc19tb3VudAkqbXAsCi0J eGZzX2RhYmxrX3QJCWJubywKLQlzdHJ1Y3QgZGFfYnRfY3Vyc29yCSpkYV9jdXJz b3IpOwotCi1leHRlcm4gdm9pZCBwcmVmZXRjaF9kaXIyKAotCXN0cnVjdCB4ZnNf bW91bnQJKm1wLAotCXN0cnVjdCBibGttYXAJCSpibGttYXApOwotCi1leHRlcm4g dm9pZCBwcmVmZXRjaF9wNl9kaXIxKAotCXN0cnVjdCB4ZnNfbW91bnQJKm1wLAot CXhmc19pbm9fdAkJaW5vLAotCXN0cnVjdCB4ZnNfaW5vZGUJKmlwLAotCXhmc19k YWJsa190CQlkYV9ibm8sCi0JeGZzX2ZzYmxvY2tfdAkJKmZibG9ja3ApOwotCi1l eHRlcm4gdm9pZCBwcmVmZXRjaF9wNl9kaXIyKAotCXN0cnVjdCB4ZnNfbW91bnQJ Km1wLAotCXN0cnVjdCB4ZnNfaW5vZGUJKmlwKTsKLQotZXh0ZXJuIHZvaWQgcHJl ZmV0Y2hfc2IoCi0Jc3RydWN0IHhmc19tb3VudAkqbXAsCi0JeGZzX2FnbnVtYmVy X3QJCWFnbm8pOwotCi1leHRlcm4gdm9pZCBwcmVmZXRjaF9yb290cygKLQlzdHJ1 Y3QgeGZzX21vdW50IAkqbXAsCi0JeGZzX2FnbnVtYmVyX3QgCQlhZ25vLAotCXhm c19hZ2ZfdAkJKmFnZiwKLQl4ZnNfYWdpX3QJCSphZ2kpOworI2luY2x1ZGUgPHNl bWFwaG9yZS5oPgorI2luY2x1ZGUgImluY29yZS5oIgorI2luY2x1ZGUgInJhZGl4 LXRyZWUuaCIKKworCitleHRlcm4gaW50IAlkb19wcmVmZXRjaDsKKworI2RlZmlu ZSBQRl9USFJFQURfQ09VTlQJNAorCit0eXBlZGVmIHN0cnVjdCBwcmVmZXRjaF9h cmdzIHsKKwlwdGhyZWFkX211dGV4X3QJCWxvY2s7CisJcHRocmVhZF90CQlxdWV1 aW5nX3RocmVhZDsKKwlwdGhyZWFkX3QJCWlvX3RocmVhZHNbUEZfVEhSRUFEX0NP VU5UXTsKKwlzdHJ1Y3QgcmFkaXhfdHJlZV9yb290CXByaW1hcnlfaW9fcXVldWU7 CisJc3RydWN0IHJhZGl4X3RyZWVfcm9vdAlzZWNvbmRhcnlfaW9fcXVldWU7CisJ cHRocmVhZF9jb25kX3QJCXN0YXJ0X3JlYWRpbmc7CisJcHRocmVhZF9jb25kX3QJ CXN0YXJ0X3Byb2Nlc3Npbmc7CisJaW50CQkJYWdubzsKKwlpbnQJCQlkaXJzX29u bHk7CisJdm9sYXRpbGUgaW50CQljYW5fc3RhcnRfcmVhZGluZzsKKwl2b2xhdGls ZSBpbnQJCWNhbl9zdGFydF9wcm9jZXNzaW5nOworCXZvbGF0aWxlIGludAkJcHJl ZmV0Y2hfZG9uZTsKKwl2b2xhdGlsZSBpbnQJCXF1ZXVpbmdfZG9uZTsKKwl2b2xh dGlsZSBpbnQJCWlub2RlX2J1ZnNfcXVldWVkOworCXZvbGF0aWxlIHhmc19mc2Js b2NrX3QJbGFzdF9ibm9fcmVhZDsKKwlzZW1fdAkJCXJhX2NvdW50OworCXN0cnVj dCBwcmVmZXRjaF9hcmdzCSpuZXh0X2FyZ3M7Cit9IHByZWZldGNoX2FyZ3NfdDsK KworCisKK3ZvaWQKK2luaXRfcHJlZmV0Y2goCisJeGZzX21vdW50X3QJCSpwbXAp OworCitwcmVmZXRjaF9hcmdzX3QgKgorc3RhcnRfaW5vZGVfcHJlZmV0Y2goCisJ eGZzX2FnbnVtYmVyX3QJCWFnbm8sCisJaW50CQkJZGlyc19vbmx5LAorCXByZWZl dGNoX2FyZ3NfdAkJKnByZXZfYXJncyk7CisKK3ZvaWQKK3dhaXRfZm9yX2lub2Rl X3ByZWZldGNoKAorCXByZWZldGNoX2FyZ3NfdAkJKmFyZ3MpOworCit2b2lkCitj bGVhbnVwX2lub2RlX3ByZWZldGNoKAorCXByZWZldGNoX2FyZ3NfdAkJKmFyZ3Mp OworCisKKyNpZmRlZiBYUl9QRl9UUkFDRQorI2RlZmluZSBwZnRyYWNlKG1zZy4u LikJX3BmdHJhY2UoX19GVU5DVElPTl9fLCAjIyBtc2cpCit2b2lkCV9wZnRyYWNl KGNvbnN0IGNoYXIgKiwgY29uc3QgY2hhciAqLCAuLi4pOworI2VuZGlmCiAKICNl bmRpZiAvKiBfWEZTX1JFUEFJUl9QUkVGRVRDSF9IICovCkluZGV4OiByZXBhaXIv eGZzcHJvZ3MvcmVwYWlyL3Byb2dyZXNzLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVwYWlyL3Byb2dyZXNzLmMJMjAwNy0w NC0yNyAxMzoxMzozNS4wMDAwMDAwMDAgKzEwMDAKKysrIHJlcGFpci94ZnNwcm9n cy9yZXBhaXIvcHJvZ3Jlc3MuYwkyMDA3LTA2LTA1IDEyOjE0OjIzLjgzMTI0MDg5 NSArMTAwMApAQCAtMSw3ICsxLDcgQEAKIAogI2luY2x1ZGUgPGxpYnhmcy5oPgot I2luY2x1ZGUgInByb2dyZXNzLmgiCiAjaW5jbHVkZSAiZ2xvYmFscy5oIgorI2lu Y2x1ZGUgInByb2dyZXNzLmgiCiAjaW5jbHVkZSAiZXJyX3Byb3Rvcy5oIgogI2lu Y2x1ZGUgPHNpZ25hbC5oPgogCkBAIC05Niw3ICs5Niw3IEBACiAJdGltZV90CQlz dGFydDsKIAl0aW1lX3QJCWVuZDsKIAl0aW1lX3QJCWR1cmF0aW9uOwotCV9fdWlu dDY0X3QJaXRlbV9jb3VudHNbNF07CQorCV9fdWludDY0X3QJaXRlbV9jb3VudHNb NF07CiB9IHBoYXNlX3RpbWVzX3Q7CiBzdGF0aWMgcGhhc2VfdGltZXNfdCBwaGFz ZV90aW1lc1s4XTsKIApAQCAtMTc3LDcgKzE3Nyw3IEBACiAJLyoKIAkgKiBTcGVj aWZ5IGEgcmVwZWF0aW5nIHRpbWVyIHRoYXQgZmlyZXMgZWFjaCBNU0dfSU5URVJW QUwgc2Vjb25kcy4KIAkgKi8KLQkKKwogCXRpbWVzcGVjLml0X3ZhbHVlLnR2X3Nl YyA9IG1zZ3AtPmludGVydmFsOwogCXRpbWVzcGVjLml0X3ZhbHVlLnR2X25zZWMg PSAwOwogCXRpbWVzcGVjLml0X2ludGVydmFsLnR2X3NlYyA9IG1zZ3AtPmludGVy dmFsOwpAQCAtMjg1LDcgKzI4NSw3IEBACiBzZXRfcHJvZ3Jlc3NfbXNnIChpbnQg cmVwb3J0LCBfX3VpbnQ2NF90IHRvdGFsKQogewogCi0JaWYgKCFkb19wYXJhbGxl bCkKKwlpZiAoIWFnX3N0cmlkZSkKIAkJcmV0dXJuICgwKTsKIAogCWlmIChwdGhy ZWFkX211dGV4X2xvY2soJmdsb2JhbF9tc2dzLm11dGV4KSkKQEAgLTMxNCw4ICsz MTQsOCBAQAogCV9fdWludDY0X3Qgc3VtOwogCW1zZ19ibG9ja190IAkqbXNncCA9 ICZnbG9iYWxfbXNnczsKIAljaGFyCQltc2didWZbRFVSQVRJT05fQlVGX1NJWkVd OwotCQotCWlmICghZG9fcGFyYWxsZWwpCisKKwlpZiAoIWFnX3N0cmlkZSkKIAkJ cmV0dXJuIDA7CiAKIAlpZiAocHRocmVhZF9tdXRleF9sb2NrKCZnbG9iYWxfbXNn cy5tdXRleCkpCkBAIC0zNzksNiArMzc5LDkgQEAKIAl0aW1lX3QgICAgbm93Owog CXN0cnVjdCB0bSAqdG1wOwogCisJaWYgKHZlcmJvc2UgPiAxKQorCQljYWNoZV9y ZXBvcnQoc3RkZXJyLCAibGlieGZzX2JjYWNoZSIsIGxpYnhmc19iY2FjaGUpOwor CiAJbm93ID0gdGltZShOVUxMKTsKIAogCWlmIChlbmQpIHsKQEAgLTQ2MSw3ICs0 NjQsNyBAQAogCQkJfQogCQkJc3RyY2F0KGJ1ZiwgdGVtcCk7CiAJCX0KLQkJCQor CiAJfQogCWlmIChsZW5ndGggPj0gT05FTUlOVVRFKSB7CiAJCW1pbnV0ZXMgPSAo bGVuZ3RoIC0gc3VtKSAvIE9ORU1JTlVURTsKQEAgLTQ4OCw3ICs0OTEsNyBAQAog CQkJc3RyY2F0KGJ1ZiwgXygiLCAiKSk7CiAJCXN0cmNhdChidWYsIHRlbXApOwog CX0KLQkJCisKIAlyZXR1cm4oYnVmKTsKIH0KIApJbmRleDogcmVwYWlyL3hmc3By b2dzL3JlcGFpci9wcm9ncmVzcy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHJl cGFpci5vcmlnL3hmc3Byb2dzL3JlcGFpci9wcm9ncmVzcy5oCTIwMDctMDQtMjcg MTM6MTM6MzUuMDAwMDAwMDAwICsxMDAwCisrKyByZXBhaXIveGZzcHJvZ3MvcmVw YWlyL3Byb2dyZXNzLmgJMjAwNy0wNS0yOSAxMToyMTowMS40NjkzNDc0MjUgKzEw MDAKQEAgLTIxLDggKzIxLDggQEAKICNkZWZpbmUJUFJPR19GTVRfUkVCVUlMRF9B Rwk5CS8qIFBoYXNlIDUgKi8KIAogI2RlZmluZQlQUk9HX0ZNVF9UUkFWRVJTQUwJ MTAJLyogUGhhc2UgNiAqLwotI2RlZmluZQlQUk9HX0ZNVF9UUkFWRVJTU1VCCTEx CQotI2RlZmluZQlQUk9HX0ZNVF9ESVNDT05JTk9ERQkxMgkKKyNkZWZpbmUJUFJP R19GTVRfVFJBVkVSU1NVQgkxMQorI2RlZmluZQlQUk9HX0ZNVF9ESVNDT05JTk9E RQkxMgogCiAjZGVmaW5lCVBST0dSRVNTX0ZNVF9DT1JSX0xJTksJMTMJLyogUGhh c2UgNyAqLwogI2RlZmluZQlQUk9HUkVTU19GTVRfVlJGWV9MSU5LIAkxNApAQCAt MzgsNiArMzgsNiBAQAogZXh0ZXJuIGNoYXIgKmR1cmF0aW9uKGludCB2YWwsIGNo YXIgKmJ1Zik7CiBleHRlcm4gaW50IGRvX3BhcmFsbGVsOwogCi0jZGVmaW5lCVBS T0dfUlBUX0lOQyhhLGIpIGlmIChkb19wYXJhbGxlbCAmJiBwcm9nX3JwdF9kb25l KSAoYSkgKz0gKGIpCisjZGVmaW5lCVBST0dfUlBUX0lOQyhhLGIpIGlmIChhZ19z dHJpZGUgJiYgcHJvZ19ycHRfZG9uZSkgKGEpICs9IChiKQogCiAjZW5kaWYJLyog X1hGU19SRVBBSVJfUFJPR1JFU1NfUlBUX0hfICovCkluZGV4OiByZXBhaXIveGZz cHJvZ3MvcmVwYWlyL3JhZGl4LXRyZWUuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSAvZGV2L251bGwJMTk3MC0wMS0wMSAwMDowMDowMC4wMDAwMDAwMDAgKzAwMDAK KysrIHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvcmFkaXgtdHJlZS5jCTIwMDctMDUt MTcgMTM6MDg6MjYuMzYxMjM5ODEyICsxMDAwCkBAIC0wLDAgKzEsODA1IEBACisv KgorICogQ29weXJpZ2h0IChDKSAyMDAxIE1vbWNoaWwgVmVsaWtvdgorICogUG9y dGlvbnMgQ29weXJpZ2h0IChDKSAyMDAxIENocmlzdG9waCBIZWxsd2lnCisgKiBD b3B5cmlnaHQgKEMpIDIwMDUgU0dJLCBDaHJpc3RvcGggTGFtZXRlciA8Y2xhbWV0 ZXJAc2dpLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2Fy ZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBtb2RpZnkgaXQg dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z ZSBhcworICogcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp b247IGVpdGhlciB2ZXJzaW9uIDIsIG9yIChhdAorICogeW91ciBvcHRpb24pIGFu eSBsYXRlciB2ZXJzaW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmli dXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyAq IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQg d2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBB IFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VCisgKiBHZW5lcmFsIFB1 YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3Vs ZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGlj IExpY2Vuc2UKKyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdy aXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA2 NzUgTWFzcyBBdmUsIENhbWJyaWRnZSwgTUEgMDIxMzksIFVTQS4KKyAqLworCisj aW5jbHVkZSA8bGlieGZzLmg+CisjaW5jbHVkZSAicmFkaXgtdHJlZS5oIgorCisj aWZuZGVmIEFSUkFZX1NJWkUKKyNkZWZpbmUgQVJSQVlfU0laRSh4KSAoc2l6ZW9m KHgpIC8gc2l6ZW9mKCh4KVswXSkpCisjZW5kaWYKKworI2RlZmluZSBSQURJWF9U UkVFX01BUF9TSElGVAk2CisjZGVmaW5lIFJBRElYX1RSRUVfTUFQX1NJWkUJKDFV TCA8PCBSQURJWF9UUkVFX01BUF9TSElGVCkKKyNkZWZpbmUgUkFESVhfVFJFRV9N QVBfTUFTSwkoUkFESVhfVFJFRV9NQVBfU0laRS0xKQorCisjaWZkZWYgUkFESVhf VFJFRV9UQUdTCisjZGVmaW5lIFJBRElYX1RSRUVfVEFHX0xPTkdTCVwKKwkoKFJB RElYX1RSRUVfTUFQX1NJWkUgKyBCSVRTX1BFUl9MT05HIC0gMSkgLyBCSVRTX1BF Ul9MT05HKQorI2VuZGlmCisKK3N0cnVjdCByYWRpeF90cmVlX25vZGUgeworCXVu c2lnbmVkIGludAljb3VudDsKKwl2b2lkCQkqc2xvdHNbUkFESVhfVFJFRV9NQVBf U0laRV07CisjaWZkZWYgUkFESVhfVFJFRV9UQUdTCisJdW5zaWduZWQgbG9uZwl0 YWdzW1JBRElYX1RSRUVfTUFYX1RBR1NdW1JBRElYX1RSRUVfVEFHX0xPTkdTXTsK KyNlbmRpZgorfTsKKworc3RydWN0IHJhZGl4X3RyZWVfcGF0aCB7CisJc3RydWN0 IHJhZGl4X3RyZWVfbm9kZSAqbm9kZTsKKwlpbnQgb2Zmc2V0OworfTsKKworI2Rl ZmluZSBSQURJWF9UUkVFX0lOREVYX0JJVFMgICg4IC8qIENIQVJfQklUICovICog c2l6ZW9mKHVuc2lnbmVkIGxvbmcpKQorI2RlZmluZSBSQURJWF9UUkVFX01BWF9Q QVRIIChSQURJWF9UUkVFX0lOREVYX0JJVFMvUkFESVhfVFJFRV9NQVBfU0hJRlQg KyAyKQorCitzdGF0aWMgdW5zaWduZWQgbG9uZyBoZWlnaHRfdG9fbWF4aW5kZXhb UkFESVhfVFJFRV9NQVhfUEFUSF07CisKKy8qCisgKiBSYWRpeCB0cmVlIG5vZGUg Y2FjaGUuCisgKi8KKworI2RlZmluZSByYWRpeF90cmVlX25vZGVfYWxsb2Mocikg CSgoc3RydWN0IHJhZGl4X3RyZWVfbm9kZSAqKSBcCisJCWNhbGxvYygxLCBzaXpl b2Yoc3RydWN0IHJhZGl4X3RyZWVfbm9kZSkpKQorI2RlZmluZSByYWRpeF90cmVl X25vZGVfZnJlZShuKSAJZnJlZShuKQorCisjaWZkZWYgUkFESVhfVFJFRV9UQUdT CisKK3N0YXRpYyBpbmxpbmUgdm9pZCB0YWdfc2V0KHN0cnVjdCByYWRpeF90cmVl X25vZGUgKm5vZGUsIHVuc2lnbmVkIGludCB0YWcsCisJCWludCBvZmZzZXQpCit7 CisJKigoX191aW50MzJfdCAqKW5vZGUtPnRhZ3NbdGFnXSArIChvZmZzZXQgPj4g NSkpIHw9ICgxIDw8IChvZmZzZXQgJiAzMSkpOworfQorCitzdGF0aWMgaW5saW5l IHZvaWQgdGFnX2NsZWFyKHN0cnVjdCByYWRpeF90cmVlX25vZGUgKm5vZGUsIHVu c2lnbmVkIGludCB0YWcsCisJCWludCBvZmZzZXQpCit7CisJX191aW50MzJfdCAJ KnAgPSAoX191aW50MzJfdCopbm9kZS0+dGFnc1t0YWddICsgKG9mZnNldCA+PiA1 KTsKKwlfX3VpbnQzMl90IAltID0gMSA8PCAob2Zmc2V0ICYgMzEpOworCSpwICY9 IH5tOworfQorCitzdGF0aWMgaW5saW5lIGludCB0YWdfZ2V0KHN0cnVjdCByYWRp eF90cmVlX25vZGUgKm5vZGUsIHVuc2lnbmVkIGludCB0YWcsCisJCWludCBvZmZz ZXQpCit7CisJcmV0dXJuIDEgJiAoKChjb25zdCBfX3VpbnQzMl90ICopbm9kZS0+ dGFnc1t0YWddKVtvZmZzZXQgPj4gNV0gPj4gKG9mZnNldCAmIDMxKSk7Cit9CisK Ky8qCisgKiBSZXR1cm5zIDEgaWYgYW55IHNsb3QgaW4gdGhlIG5vZGUgaGFzIHRo aXMgdGFnIHNldC4KKyAqIE90aGVyd2lzZSByZXR1cm5zIDAuCisgKi8KK3N0YXRp YyBpbmxpbmUgaW50IGFueV90YWdfc2V0KHN0cnVjdCByYWRpeF90cmVlX25vZGUg Km5vZGUsIHVuc2lnbmVkIGludCB0YWcpCit7CisJaW50IGlkeDsKKwlmb3IgKGlk eCA9IDA7IGlkeCA8IFJBRElYX1RSRUVfVEFHX0xPTkdTOyBpZHgrKykgeworCQlp ZiAobm9kZS0+dGFnc1t0YWddW2lkeF0pCisJCQlyZXR1cm4gMTsKKwl9CisJcmV0 dXJuIDA7Cit9CisKKyNlbmRpZgorCisvKgorICoJUmV0dXJuIHRoZSBtYXhpbXVt IGtleSB3aGljaCBjYW4gYmUgc3RvcmUgaW50byBhCisgKglyYWRpeCB0cmVlIHdp dGggaGVpZ2h0IEhFSUdIVC4KKyAqLworc3RhdGljIGlubGluZSB1bnNpZ25lZCBs b25nIHJhZGl4X3RyZWVfbWF4aW5kZXgodW5zaWduZWQgaW50IGhlaWdodCkKK3sK KwlyZXR1cm4gaGVpZ2h0X3RvX21heGluZGV4W2hlaWdodF07Cit9CisKKy8qCisg KglFeHRlbmQgYSByYWRpeCB0cmVlIHNvIGl0IGNhbiBzdG9yZSBrZXkgQGluZGV4 LgorICovCitzdGF0aWMgaW50IHJhZGl4X3RyZWVfZXh0ZW5kKHN0cnVjdCByYWRp eF90cmVlX3Jvb3QgKnJvb3QsIHVuc2lnbmVkIGxvbmcgaW5kZXgpCit7CisJc3Ry dWN0IHJhZGl4X3RyZWVfbm9kZSAqbm9kZTsKKwl1bnNpZ25lZCBpbnQgaGVpZ2h0 OworI2lmZGVmIFJBRElYX1RSRUVfVEFHUworCWNoYXIgdGFnc1tSQURJWF9UUkVF X01BWF9UQUdTXTsKKwlpbnQgdGFnOworI2VuZGlmCisKKwkvKiBGaWd1cmUgb3V0 IHdoYXQgdGhlIGhlaWdodCBzaG91bGQgYmUuICAqLworCWhlaWdodCA9IHJvb3Qt PmhlaWdodCArIDE7CisJd2hpbGUgKGluZGV4ID4gcmFkaXhfdHJlZV9tYXhpbmRl eChoZWlnaHQpKQorCQloZWlnaHQrKzsKKworCWlmIChyb290LT5ybm9kZSA9PSBO VUxMKSB7CisJCXJvb3QtPmhlaWdodCA9IGhlaWdodDsKKwkJZ290byBvdXQ7CisJ fQorCisjaWZkZWYgUkFESVhfVFJFRV9UQUdTCisJLyoKKwkgKiBQcmVwYXJlIHRo ZSB0YWcgc3RhdHVzIG9mIHRoZSB0b3AtbGV2ZWwgbm9kZSBmb3IgcHJvcGFnYXRp b24KKwkgKiBpbnRvIHRoZSBuZXdseS1wdXNoZWQgdG9wLWxldmVsIG5vZGUocykK KwkgKi8KKwlmb3IgKHRhZyA9IDA7IHRhZyA8IFJBRElYX1RSRUVfTUFYX1RBR1M7 IHRhZysrKSB7CisJCXRhZ3NbdGFnXSA9IDA7CisJCWlmIChhbnlfdGFnX3NldChy b290LT5ybm9kZSwgdGFnKSkKKwkJCXRhZ3NbdGFnXSA9IDE7CisJfQorI2VuZGlm CisJZG8geworCQlpZiAoIShub2RlID0gcmFkaXhfdHJlZV9ub2RlX2FsbG9jKHJv b3QpKSkKKwkJCXJldHVybiAtRU5PTUVNOworCisJCS8qIEluY3JlYXNlIHRoZSBo ZWlnaHQuICAqLworCQlub2RlLT5zbG90c1swXSA9IHJvb3QtPnJub2RlOworCisj aWZkZWYgUkFESVhfVFJFRV9UQUdTCisJCS8qIFByb3BhZ2F0ZSB0aGUgYWdncmVn YXRlZCB0YWcgaW5mbyBpbnRvIHRoZSBuZXcgcm9vdCAqLworCQlmb3IgKHRhZyA9 IDA7IHRhZyA8IFJBRElYX1RSRUVfTUFYX1RBR1M7IHRhZysrKSB7CisJCQlpZiAo dGFnc1t0YWddKQorCQkJCXRhZ19zZXQobm9kZSwgdGFnLCAwKTsKKwkJfQorI2Vu ZGlmCisJCW5vZGUtPmNvdW50ID0gMTsKKwkJcm9vdC0+cm5vZGUgPSBub2RlOwor CQlyb290LT5oZWlnaHQrKzsKKwl9IHdoaWxlIChoZWlnaHQgPiByb290LT5oZWln aHQpOworb3V0OgorCXJldHVybiAwOworfQorCisvKioKKyAqCXJhZGl4X3RyZWVf aW5zZXJ0ICAgIC0gICAgaW5zZXJ0IGludG8gYSByYWRpeCB0cmVlCisgKglAcm9v dDoJCXJhZGl4IHRyZWUgcm9vdAorICoJQGluZGV4OgkJaW5kZXgga2V5CisgKglA aXRlbToJCWl0ZW0gdG8gaW5zZXJ0CisgKgorICoJSW5zZXJ0IGFuIGl0ZW0gaW50 byB0aGUgcmFkaXggdHJlZSBhdCBwb3NpdGlvbiBAaW5kZXguCisgKi8KK2ludCBy YWRpeF90cmVlX2luc2VydChzdHJ1Y3QgcmFkaXhfdHJlZV9yb290ICpyb290LAor CQkJdW5zaWduZWQgbG9uZyBpbmRleCwgdm9pZCAqaXRlbSkKK3sKKwlzdHJ1Y3Qg cmFkaXhfdHJlZV9ub2RlICpub2RlID0gTlVMTCwgKnNsb3Q7CisJdW5zaWduZWQg aW50IGhlaWdodCwgc2hpZnQ7CisJaW50IG9mZnNldDsKKwlpbnQgZXJyb3I7CisK KwkvKiBNYWtlIHN1cmUgdGhlIHRyZWUgaXMgaGlnaCBlbm91Z2guICAqLworCWlm ICgoIWluZGV4ICYmICFyb290LT5ybm9kZSkgfHwKKwkJCWluZGV4ID4gcmFkaXhf dHJlZV9tYXhpbmRleChyb290LT5oZWlnaHQpKSB7CisJCWVycm9yID0gcmFkaXhf dHJlZV9leHRlbmQocm9vdCwgaW5kZXgpOworCQlpZiAoZXJyb3IpCisJCQlyZXR1 cm4gZXJyb3I7CisJfQorCisJc2xvdCA9IHJvb3QtPnJub2RlOworCWhlaWdodCA9 IHJvb3QtPmhlaWdodDsKKwlzaGlmdCA9IChoZWlnaHQtMSkgKiBSQURJWF9UUkVF X01BUF9TSElGVDsKKworCW9mZnNldCA9IDA7CQkJLyogdW5pbml0aWFsaXNlZCB2 YXIgd2FybmluZyAqLworCWRvIHsKKwkJaWYgKHNsb3QgPT0gTlVMTCkgeworCQkJ LyogSGF2ZSB0byBhZGQgYSBjaGlsZCBub2RlLiAgKi8KKwkJCWlmICghKHNsb3Qg PSByYWRpeF90cmVlX25vZGVfYWxsb2Mocm9vdCkpKQorCQkJCXJldHVybiAtRU5P TUVNOworCQkJaWYgKG5vZGUpIHsKKwkJCQlub2RlLT5zbG90c1tvZmZzZXRdID0g c2xvdDsKKwkJCQlub2RlLT5jb3VudCsrOworCQkJfSBlbHNlCisJCQkJcm9vdC0+ cm5vZGUgPSBzbG90OworCQl9CisKKwkJLyogR28gYSBsZXZlbCBkb3duICovCisJ CW9mZnNldCA9IChpbmRleCA+PiBzaGlmdCkgJiBSQURJWF9UUkVFX01BUF9NQVNL OworCQlub2RlID0gc2xvdDsKKwkJc2xvdCA9IG5vZGUtPnNsb3RzW29mZnNldF07 CisJCXNoaWZ0IC09IFJBRElYX1RSRUVfTUFQX1NISUZUOworCQloZWlnaHQtLTsK Kwl9IHdoaWxlIChoZWlnaHQgPiAwKTsKKworCWlmIChzbG90ICE9IE5VTEwpCisJ CXJldHVybiAtRUVYSVNUOworCisJQVNTRVJUKG5vZGUpOworCW5vZGUtPmNvdW50 Kys7CisJbm9kZS0+c2xvdHNbb2Zmc2V0XSA9IGl0ZW07CisjaWZkZWYgUkFESVhf VFJFRV9UQUdTCisJQVNTRVJUKCF0YWdfZ2V0KG5vZGUsIDAsIG9mZnNldCkpOwor CUFTU0VSVCghdGFnX2dldChub2RlLCAxLCBvZmZzZXQpKTsKKyNlbmRpZgorCXJl dHVybiAwOworfQorCitzdGF0aWMgaW5saW5lIHZvaWQgKipfX2xvb2t1cF9zbG90 KHN0cnVjdCByYWRpeF90cmVlX3Jvb3QgKnJvb3QsCisJCQkJICAgdW5zaWduZWQg bG9uZyBpbmRleCkKK3sKKwl1bnNpZ25lZCBpbnQgaGVpZ2h0LCBzaGlmdDsKKwlz dHJ1Y3QgcmFkaXhfdHJlZV9ub2RlICoqc2xvdDsKKworCWhlaWdodCA9IHJvb3Qt PmhlaWdodDsKKwlpZiAoaW5kZXggPiByYWRpeF90cmVlX21heGluZGV4KGhlaWdo dCkpCisJCXJldHVybiBOVUxMOworCisJc2hpZnQgPSAoaGVpZ2h0LTEpICogUkFE SVhfVFJFRV9NQVBfU0hJRlQ7CisJc2xvdCA9ICZyb290LT5ybm9kZTsKKworCXdo aWxlIChoZWlnaHQgPiAwKSB7CisJCWlmICgqc2xvdCA9PSBOVUxMKQorCQkJcmV0 dXJuIE5VTEw7CisKKwkJc2xvdCA9IChzdHJ1Y3QgcmFkaXhfdHJlZV9ub2RlICoq KQorCQkJKCgqc2xvdCktPnNsb3RzICsKKwkJCQkoKGluZGV4ID4+IHNoaWZ0KSAm IFJBRElYX1RSRUVfTUFQX01BU0spKTsKKwkJc2hpZnQgLT0gUkFESVhfVFJFRV9N QVBfU0hJRlQ7CisJCWhlaWdodC0tOworCX0KKworCXJldHVybiAodm9pZCAqKilz bG90OworfQorCisvKioKKyAqCXJhZGl4X3RyZWVfbG9va3VwX3Nsb3QgICAgLSAg ICBsb29rdXAgYSBzbG90IGluIGEgcmFkaXggdHJlZQorICoJQHJvb3Q6CQlyYWRp eCB0cmVlIHJvb3QKKyAqCUBpbmRleDoJCWluZGV4IGtleQorICoKKyAqCUxvb2t1 cCB0aGUgc2xvdCBjb3JyZXNwb25kaW5nIHRvIHRoZSBwb3NpdGlvbiBAaW5kZXgg aW4gdGhlIHJhZGl4IHRyZWUKKyAqCUByb290LiBUaGlzIGlzIHVzZWZ1bCBmb3Ig dXBkYXRlLWlmLWV4aXN0cyBvcGVyYXRpb25zLgorICovCit2b2lkICoqcmFkaXhf dHJlZV9sb29rdXBfc2xvdChzdHJ1Y3QgcmFkaXhfdHJlZV9yb290ICpyb290LCB1 bnNpZ25lZCBsb25nIGluZGV4KQoreworCXJldHVybiBfX2xvb2t1cF9zbG90KHJv b3QsIGluZGV4KTsKK30KKworLyoqCisgKglyYWRpeF90cmVlX2xvb2t1cCAgICAt ICAgIHBlcmZvcm0gbG9va3VwIG9wZXJhdGlvbiBvbiBhIHJhZGl4IHRyZWUKKyAq CUByb290OgkJcmFkaXggdHJlZSByb290CisgKglAaW5kZXg6CQlpbmRleCBrZXkK KyAqCisgKglMb29rdXAgdGhlIGl0ZW0gYXQgdGhlIHBvc2l0aW9uIEBpbmRleCBp biB0aGUgcmFkaXggdHJlZSBAcm9vdC4KKyAqLwordm9pZCAqcmFkaXhfdHJlZV9s b29rdXAoc3RydWN0IHJhZGl4X3RyZWVfcm9vdCAqcm9vdCwgdW5zaWduZWQgbG9u ZyBpbmRleCkKK3sKKwl2b2lkICoqc2xvdDsKKworCXNsb3QgPSBfX2xvb2t1cF9z bG90KHJvb3QsIGluZGV4KTsKKwlyZXR1cm4gc2xvdCAhPSBOVUxMID8gKnNsb3Qg OiBOVUxMOworfQorCisvKioKKyAqCXJhaWRfdHJlZV9maXJzdF9rZXkgLSBmaW5k IHRoZSBmaXJzdCBpbmRleCBrZXkgaW4gdGhlIHJhZGl4IHRyZWUKKyAqCUByb290 OgkJcmFkaXggdHJlZSByb290CisgKglAaW5kZXg6CQl3aGVyZSB0aGUgZmlyc3Qg aW5kZXggd2lsbCBiZSBwbGFjZWQKKyAqCisgKglSZXR1cm5zIHRoZSBmaXJzdCBl bnRyeSBhbmQgaW5kZXgga2V5IGluIHRoZSByYWRpeCB0cmVlIEByb290LgorICov Cit2b2lkICpyYWRpeF90cmVlX2xvb2t1cF9maXJzdChzdHJ1Y3QgcmFkaXhfdHJl ZV9yb290ICpyb290LCB1bnNpZ25lZCBsb25nICppbmRleCkKK3sKKwl1bnNpZ25l ZCBpbnQgaGVpZ2h0LCBzaGlmdDsKKwlzdHJ1Y3QgcmFkaXhfdHJlZV9ub2RlICpz bG90OworCXVuc2lnbmVkIGxvbmcgaTsKKworCWhlaWdodCA9IHJvb3QtPmhlaWdo dDsKKwkqaW5kZXggPSAwOworCWlmIChoZWlnaHQgPT0gMCkKKwkJcmV0dXJuIE5V TEw7CisKKwlzaGlmdCA9IChoZWlnaHQtMSkgKiBSQURJWF9UUkVFX01BUF9TSElG VDsKKwlzbG90ID0gcm9vdC0+cm5vZGU7CisKKwlmb3IgKDsgaGVpZ2h0ID4gMTsg aGVpZ2h0LS0pIHsKKwkJZm9yIChpID0gMDsgaSA8IFJBRElYX1RSRUVfTUFQX1NJ WkU7IGkrKykgeworCQkJaWYgKHNsb3QtPnNsb3RzW2ldICE9IE5VTEwpCisJCQkJ YnJlYWs7CisJCX0KKwkJQVNTRVJUKGkgPCBSQURJWF9UUkVFX01BUF9TSVpFKTsK KworCQkqaW5kZXggfD0gKGkgPDwgc2hpZnQpOworCQlzaGlmdCAtPSBSQURJWF9U UkVFX01BUF9TSElGVDsKKwkJc2xvdCA9IHNsb3QtPnNsb3RzW2ldOworCX0KKwlm b3IgKGkgPSAwOyBpIDwgUkFESVhfVFJFRV9NQVBfU0laRTsgaSsrKSB7CisJCWlm IChzbG90LT5zbG90c1tpXSAhPSBOVUxMKSB7CisJCQkqaW5kZXggfD0gaTsKKwkJ CXJldHVybiBzbG90LT5zbG90c1tpXTsKKwkJfQorCX0KKwlyZXR1cm4gTlVMTDsK K30KKworI2lmZGVmIFJBRElYX1RSRUVfVEFHUworCisvKioKKyAqCXJhZGl4X3Ry ZWVfdGFnX3NldCAtIHNldCBhIHRhZyBvbiBhIHJhZGl4IHRyZWUgbm9kZQorICoJ QHJvb3Q6CQlyYWRpeCB0cmVlIHJvb3QKKyAqCUBpbmRleDoJCWluZGV4IGtleQor ICoJQHRhZzogCQl0YWcgaW5kZXgKKyAqCisgKglTZXQgdGhlIHNlYXJjaCB0YWcg KHdoaWNoIG11c3QgYmUgPCBSQURJWF9UUkVFX01BWF9UQUdTKQorICoJY29ycmVz cG9uZGluZyB0byBAaW5kZXggaW4gdGhlIHJhZGl4IHRyZWUuICBGcm9tCisgKgl0 aGUgcm9vdCBhbGwgdGhlIHdheSBkb3duIHRvIHRoZSBsZWFmIG5vZGUuCisgKgor ICoJUmV0dXJucyB0aGUgYWRkcmVzcyBvZiB0aGUgdGFnZ2VkIGl0ZW0uICAgU2V0 dGluZyBhIHRhZyBvbiBhIG5vdC1wcmVzZW50CisgKglpdGVtIGlzIGEgYnVnLgor ICovCit2b2lkICpyYWRpeF90cmVlX3RhZ19zZXQoc3RydWN0IHJhZGl4X3RyZWVf cm9vdCAqcm9vdCwKKwkJCXVuc2lnbmVkIGxvbmcgaW5kZXgsIHVuc2lnbmVkIGlu dCB0YWcpCit7CisJdW5zaWduZWQgaW50IGhlaWdodCwgc2hpZnQ7CisJc3RydWN0 IHJhZGl4X3RyZWVfbm9kZSAqc2xvdDsKKworCWhlaWdodCA9IHJvb3QtPmhlaWdo dDsKKwlpZiAoaW5kZXggPiByYWRpeF90cmVlX21heGluZGV4KGhlaWdodCkpCisJ CXJldHVybiBOVUxMOworCisJc2hpZnQgPSAoaGVpZ2h0IC0gMSkgKiBSQURJWF9U UkVFX01BUF9TSElGVDsKKwlzbG90ID0gcm9vdC0+cm5vZGU7CisKKwl3aGlsZSAo aGVpZ2h0ID4gMCkgeworCQlpbnQgb2Zmc2V0OworCisJCW9mZnNldCA9IChpbmRl eCA+PiBzaGlmdCkgJiBSQURJWF9UUkVFX01BUF9NQVNLOworCQlpZiAoIXRhZ19n ZXQoc2xvdCwgdGFnLCBvZmZzZXQpKQorCQkJdGFnX3NldChzbG90LCB0YWcsIG9m ZnNldCk7CisJCXNsb3QgPSBzbG90LT5zbG90c1tvZmZzZXRdOworCQlBU1NFUlQo c2xvdCAhPSBOVUxMKTsKKwkJc2hpZnQgLT0gUkFESVhfVFJFRV9NQVBfU0hJRlQ7 CisJCWhlaWdodC0tOworCX0KKworCXJldHVybiBzbG90OworfQorCisvKioKKyAq CXJhZGl4X3RyZWVfdGFnX2NsZWFyIC0gY2xlYXIgYSB0YWcgb24gYSByYWRpeCB0 cmVlIG5vZGUKKyAqCUByb290OgkJcmFkaXggdHJlZSByb290CisgKglAaW5kZXg6 CQlpbmRleCBrZXkKKyAqCUB0YWc6IAkJdGFnIGluZGV4CisgKgorICoJQ2xlYXIg dGhlIHNlYXJjaCB0YWcgKHdoaWNoIG11c3QgYmUgPCBSQURJWF9UUkVFX01BWF9U QUdTKQorICoJY29ycmVzcG9uZGluZyB0byBAaW5kZXggaW4gdGhlIHJhZGl4IHRy ZWUuICBJZgorICoJdGhpcyBjYXVzZXMgdGhlIGxlYWYgbm9kZSB0byBoYXZlIG5v IHRhZ3Mgc2V0IHRoZW4gY2xlYXIgdGhlIHRhZyBpbiB0aGUKKyAqCW5leHQtdG8t bGVhZiBub2RlLCBldGMuCisgKgorICoJUmV0dXJucyB0aGUgYWRkcmVzcyBvZiB0 aGUgdGFnZ2VkIGl0ZW0gb24gc3VjY2VzcywgZWxzZSBOVUxMLiAgaWU6CisgKglo YXMgdGhlIHNhbWUgcmV0dXJuIHZhbHVlIGFuZCBzZW1hbnRpY3MgYXMgcmFkaXhf dHJlZV9sb29rdXAoKS4KKyAqLwordm9pZCAqcmFkaXhfdHJlZV90YWdfY2xlYXIo c3RydWN0IHJhZGl4X3RyZWVfcm9vdCAqcm9vdCwKKwkJCXVuc2lnbmVkIGxvbmcg aW5kZXgsIHVuc2lnbmVkIGludCB0YWcpCit7CisJc3RydWN0IHJhZGl4X3RyZWVf cGF0aCBwYXRoW1JBRElYX1RSRUVfTUFYX1BBVEhdLCAqcGF0aHAgPSBwYXRoOwor CXN0cnVjdCByYWRpeF90cmVlX25vZGUgKnNsb3Q7CisJdW5zaWduZWQgaW50IGhl aWdodCwgc2hpZnQ7CisJdm9pZCAqcmV0ID0gTlVMTDsKKworCWhlaWdodCA9IHJv b3QtPmhlaWdodDsKKwlpZiAoaW5kZXggPiByYWRpeF90cmVlX21heGluZGV4KGhl aWdodCkpCisJCWdvdG8gb3V0OworCisJc2hpZnQgPSAoaGVpZ2h0IC0gMSkgKiBS QURJWF9UUkVFX01BUF9TSElGVDsKKwlwYXRocC0+bm9kZSA9IE5VTEw7CisJc2xv dCA9IHJvb3QtPnJub2RlOworCisJd2hpbGUgKGhlaWdodCA+IDApIHsKKwkJaW50 IG9mZnNldDsKKworCQlpZiAoc2xvdCA9PSBOVUxMKQorCQkJZ290byBvdXQ7CisK KwkJb2Zmc2V0ID0gKGluZGV4ID4+IHNoaWZ0KSAmIFJBRElYX1RSRUVfTUFQX01B U0s7CisJCXBhdGhwWzFdLm9mZnNldCA9IG9mZnNldDsKKwkJcGF0aHBbMV0ubm9k ZSA9IHNsb3Q7CisJCXNsb3QgPSBzbG90LT5zbG90c1tvZmZzZXRdOworCQlwYXRo cCsrOworCQlzaGlmdCAtPSBSQURJWF9UUkVFX01BUF9TSElGVDsKKwkJaGVpZ2h0 LS07CisJfQorCisJcmV0ID0gc2xvdDsKKwlpZiAocmV0ID09IE5VTEwpCisJCWdv dG8gb3V0OworCisJZG8geworCQlpZiAoIXRhZ19nZXQocGF0aHAtPm5vZGUsIHRh ZywgcGF0aHAtPm9mZnNldCkpCisJCQlnb3RvIG91dDsKKwkJdGFnX2NsZWFyKHBh dGhwLT5ub2RlLCB0YWcsIHBhdGhwLT5vZmZzZXQpOworCQlpZiAoYW55X3RhZ19z ZXQocGF0aHAtPm5vZGUsIHRhZykpCisJCQlnb3RvIG91dDsKKwkJcGF0aHAtLTsK Kwl9IHdoaWxlIChwYXRocC0+bm9kZSk7CitvdXQ6CisJcmV0dXJuIHJldDsKK30K KworI2VuZGlmCisKK3N0YXRpYyB1bnNpZ25lZCBpbnQKK19fbG9va3VwKHN0cnVj dCByYWRpeF90cmVlX3Jvb3QgKnJvb3QsIHZvaWQgKipyZXN1bHRzLCB1bnNpZ25l ZCBsb25nIGluZGV4LAorCXVuc2lnbmVkIGludCBtYXhfaXRlbXMsIHVuc2lnbmVk IGxvbmcgKm5leHRfaW5kZXgpCit7CisJdW5zaWduZWQgaW50IG5yX2ZvdW5kID0g MDsKKwl1bnNpZ25lZCBpbnQgc2hpZnQsIGhlaWdodDsKKwlzdHJ1Y3QgcmFkaXhf dHJlZV9ub2RlICpzbG90OworCXVuc2lnbmVkIGxvbmcgaTsKKworCWhlaWdodCA9 IHJvb3QtPmhlaWdodDsKKwlpZiAoaGVpZ2h0ID09IDApCisJCWdvdG8gb3V0Owor CisJc2hpZnQgPSAoaGVpZ2h0LTEpICogUkFESVhfVFJFRV9NQVBfU0hJRlQ7CisJ c2xvdCA9IHJvb3QtPnJub2RlOworCisJZm9yICggOyBoZWlnaHQgPiAxOyBoZWln aHQtLSkgeworCisJCWZvciAoaSA9IChpbmRleCA+PiBzaGlmdCkgJiBSQURJWF9U UkVFX01BUF9NQVNLIDsKKwkJCQlpIDwgUkFESVhfVFJFRV9NQVBfU0laRTsgaSsr KSB7CisJCQlpZiAoc2xvdC0+c2xvdHNbaV0gIT0gTlVMTCkKKwkJCQlicmVhazsK KwkJCWluZGV4ICY9IH4oKDFVTCA8PCBzaGlmdCkgLSAxKTsKKwkJCWluZGV4ICs9 IDFVTCA8PCBzaGlmdDsKKwkJCWlmIChpbmRleCA9PSAwKQorCQkJCWdvdG8gb3V0 OwkvKiAzMi1iaXQgd3JhcGFyb3VuZCAqLworCQl9CisJCWlmIChpID09IFJBRElY X1RSRUVfTUFQX1NJWkUpCisJCQlnb3RvIG91dDsKKworCQlzaGlmdCAtPSBSQURJ WF9UUkVFX01BUF9TSElGVDsKKwkJc2xvdCA9IHNsb3QtPnNsb3RzW2ldOworCX0K KworCS8qIEJvdHRvbSBsZXZlbDogZ3JhYiBzb21lIGl0ZW1zICovCisJZm9yIChp ID0gaW5kZXggJiBSQURJWF9UUkVFX01BUF9NQVNLOyBpIDwgUkFESVhfVFJFRV9N QVBfU0laRTsgaSsrKSB7CisJCWluZGV4Kys7CisJCWlmIChzbG90LT5zbG90c1tp XSkgeworCQkJcmVzdWx0c1tucl9mb3VuZCsrXSA9IHNsb3QtPnNsb3RzW2ldOwor CQkJaWYgKG5yX2ZvdW5kID09IG1heF9pdGVtcykKKwkJCQlnb3RvIG91dDsKKwkJ fQorCX0KK291dDoKKwkqbmV4dF9pbmRleCA9IGluZGV4OworCXJldHVybiBucl9m b3VuZDsKK30KKworLyoqCisgKglyYWRpeF90cmVlX2dhbmdfbG9va3VwIC0gcGVy Zm9ybSBtdWx0aXBsZSBsb29rdXAgb24gYSByYWRpeCB0cmVlCisgKglAcm9vdDoJ CXJhZGl4IHRyZWUgcm9vdAorICoJQHJlc3VsdHM6CXdoZXJlIHRoZSByZXN1bHRz IG9mIHRoZSBsb29rdXAgYXJlIHBsYWNlZAorICoJQGZpcnN0X2luZGV4OglzdGFy dCB0aGUgbG9va3VwIGZyb20gdGhpcyBrZXkKKyAqCUBtYXhfaXRlbXM6CXBsYWNl IHVwIHRvIHRoaXMgbWFueSBpdGVtcyBhdCAqcmVzdWx0cworICoKKyAqCVBlcmZv cm1zIGFuIGluZGV4LWFzY2VuZGluZyBzY2FuIG9mIHRoZSB0cmVlIGZvciBwcmVz ZW50IGl0ZW1zLiAgUGxhY2VzCisgKgl0aGVtIGF0ICpAcmVzdWx0cyBhbmQgcmV0 dXJucyB0aGUgbnVtYmVyIG9mIGl0ZW1zIHdoaWNoIHdlcmUgcGxhY2VkIGF0Cisg KgkqQHJlc3VsdHMuCisgKgorICoJVGhlIGltcGxlbWVudGF0aW9uIGlzIG5haXZl LgorICovCit1bnNpZ25lZCBpbnQKK3JhZGl4X3RyZWVfZ2FuZ19sb29rdXAoc3Ry dWN0IHJhZGl4X3RyZWVfcm9vdCAqcm9vdCwgdm9pZCAqKnJlc3VsdHMsCisJCQl1 bnNpZ25lZCBsb25nIGZpcnN0X2luZGV4LCB1bnNpZ25lZCBpbnQgbWF4X2l0ZW1z KQoreworCWNvbnN0IHVuc2lnbmVkIGxvbmcgbWF4X2luZGV4ID0gcmFkaXhfdHJl ZV9tYXhpbmRleChyb290LT5oZWlnaHQpOworCXVuc2lnbmVkIGxvbmcgY3VyX2lu ZGV4ID0gZmlyc3RfaW5kZXg7CisJdW5zaWduZWQgaW50IHJldCA9IDA7CisKKwl3 aGlsZSAocmV0IDwgbWF4X2l0ZW1zKSB7CisJCXVuc2lnbmVkIGludCBucl9mb3Vu ZDsKKwkJdW5zaWduZWQgbG9uZyBuZXh0X2luZGV4OwkvKiBJbmRleCBvZiBuZXh0 IHNlYXJjaCAqLworCisJCWlmIChjdXJfaW5kZXggPiBtYXhfaW5kZXgpCisJCQli cmVhazsKKwkJbnJfZm91bmQgPSBfX2xvb2t1cChyb290LCByZXN1bHRzICsgcmV0 LCBjdXJfaW5kZXgsCisJCQkJCW1heF9pdGVtcyAtIHJldCwgJm5leHRfaW5kZXgp OworCQlyZXQgKz0gbnJfZm91bmQ7CisJCWlmIChuZXh0X2luZGV4ID09IDApCisJ CQlicmVhazsKKwkJY3VyX2luZGV4ID0gbmV4dF9pbmRleDsKKwl9CisJcmV0dXJu IHJldDsKK30KKworLyoqCisgKglyYWRpeF90cmVlX2dhbmdfbG9va3VwX2V4IC0g cGVyZm9ybSBtdWx0aXBsZSBsb29rdXAgb24gYSByYWRpeCB0cmVlCisgKglAcm9v dDoJCXJhZGl4IHRyZWUgcm9vdAorICoJQHJlc3VsdHM6CXdoZXJlIHRoZSByZXN1 bHRzIG9mIHRoZSBsb29rdXAgYXJlIHBsYWNlZAorICoJQGZpcnN0X2luZGV4Oglz dGFydCB0aGUgbG9va3VwIGZyb20gdGhpcyBrZXkKKyAqCUBsYXN0X2luZGV4Oglk b24ndCBsb29rdXAgcGFzdCB0aGlzIGtleQorICoJQG1heF9pdGVtczoJcGxhY2Ug dXAgdG8gdGhpcyBtYW55IGl0ZW1zIGF0ICpyZXN1bHRzCisgKgorICoJUGVyZm9y bXMgYW4gaW5kZXgtYXNjZW5kaW5nIHNjYW4gb2YgdGhlIHRyZWUgZm9yIHByZXNl bnQgaXRlbXMgc3RhcnRpbmcKKyAqCUBmaXJzdF9pbmRleCB1bnRpbCBAbGFzdF9p bmRleCB1cCB0byBhcyBtYW55IGFzIEBtYXhfaXRlbXMuICBQbGFjZXMKKyAqCXRo ZW0gYXQgKkByZXN1bHRzIGFuZCByZXR1cm5zIHRoZSBudW1iZXIgb2YgaXRlbXMg d2hpY2ggd2VyZSBwbGFjZWQKKyAqCWF0ICpAcmVzdWx0cy4KKyAqCisgKglUaGUg aW1wbGVtZW50YXRpb24gaXMgbmFpdmUuCisgKi8KK3Vuc2lnbmVkIGludAorcmFk aXhfdHJlZV9nYW5nX2xvb2t1cF9leChzdHJ1Y3QgcmFkaXhfdHJlZV9yb290ICpy b290LCB2b2lkICoqcmVzdWx0cywKKwkJCXVuc2lnbmVkIGxvbmcgZmlyc3RfaW5k ZXgsIHVuc2lnbmVkIGxvbmcgbGFzdF9pbmRleCwKKwkJCXVuc2lnbmVkIGludCBt YXhfaXRlbXMpCit7CisJY29uc3QgdW5zaWduZWQgbG9uZyBtYXhfaW5kZXggPSBy YWRpeF90cmVlX21heGluZGV4KHJvb3QtPmhlaWdodCk7CisJdW5zaWduZWQgbG9u ZyBjdXJfaW5kZXggPSBmaXJzdF9pbmRleDsKKwl1bnNpZ25lZCBpbnQgcmV0ID0g MDsKKworCXdoaWxlIChyZXQgPCBtYXhfaXRlbXMgJiYgY3VyX2luZGV4IDwgbGFz dF9pbmRleCkgeworCQl1bnNpZ25lZCBpbnQgbnJfZm91bmQ7CisJCXVuc2lnbmVk IGxvbmcgbmV4dF9pbmRleDsJLyogSW5kZXggb2YgbmV4dCBzZWFyY2ggKi8KKwor CQlpZiAoY3VyX2luZGV4ID4gbWF4X2luZGV4KQorCQkJYnJlYWs7CisJCW5yX2Zv dW5kID0gX19sb29rdXAocm9vdCwgcmVzdWx0cyArIHJldCwgY3VyX2luZGV4LAor CQkJCQltYXhfaXRlbXMgLSByZXQsICZuZXh0X2luZGV4KTsKKwkJcmV0ICs9IG5y X2ZvdW5kOworCQlpZiAobmV4dF9pbmRleCA9PSAwKQorCQkJYnJlYWs7CisJCWN1 cl9pbmRleCA9IG5leHRfaW5kZXg7CisJfQorCXJldHVybiByZXQ7Cit9CisKKyNp ZmRlZiBSQURJWF9UUkVFX1RBR1MKKworc3RhdGljIHVuc2lnbmVkIGludAorX19s b29rdXBfdGFnKHN0cnVjdCByYWRpeF90cmVlX3Jvb3QgKnJvb3QsIHZvaWQgKipy ZXN1bHRzLCB1bnNpZ25lZCBsb25nIGluZGV4LAorCXVuc2lnbmVkIGludCBtYXhf aXRlbXMsIHVuc2lnbmVkIGxvbmcgKm5leHRfaW5kZXgsIHVuc2lnbmVkIGludCB0 YWcpCit7CisJdW5zaWduZWQgaW50IG5yX2ZvdW5kID0gMDsKKwl1bnNpZ25lZCBp bnQgc2hpZnQ7CisJdW5zaWduZWQgaW50IGhlaWdodCA9IHJvb3QtPmhlaWdodDsK KwlzdHJ1Y3QgcmFkaXhfdHJlZV9ub2RlICpzbG90OworCisJc2hpZnQgPSAoaGVp Z2h0IC0gMSkgKiBSQURJWF9UUkVFX01BUF9TSElGVDsKKwlzbG90ID0gcm9vdC0+ cm5vZGU7CisKKwl3aGlsZSAoaGVpZ2h0ID4gMCkgeworCQl1bnNpZ25lZCBsb25n IGkgPSAoaW5kZXggPj4gc2hpZnQpICYgUkFESVhfVFJFRV9NQVBfTUFTSzsKKwor CQlmb3IgKCA7IGkgPCBSQURJWF9UUkVFX01BUF9TSVpFOyBpKyspIHsKKwkJCWlm ICh0YWdfZ2V0KHNsb3QsIHRhZywgaSkpIHsKKwkJCQlBU1NFUlQoc2xvdC0+c2xv dHNbaV0gIT0gTlVMTCk7CisJCQkJYnJlYWs7CisJCQl9CisJCQlpbmRleCAmPSB+ KCgxVUwgPDwgc2hpZnQpIC0gMSk7CisJCQlpbmRleCArPSAxVUwgPDwgc2hpZnQ7 CisJCQlpZiAoaW5kZXggPT0gMCkKKwkJCQlnb3RvIG91dDsJLyogMzItYml0IHdy YXBhcm91bmQgKi8KKwkJfQorCQlpZiAoaSA9PSBSQURJWF9UUkVFX01BUF9TSVpF KQorCQkJZ290byBvdXQ7CisJCWhlaWdodC0tOworCQlpZiAoaGVpZ2h0ID09IDAp IHsJLyogQm90dG9tIGxldmVsOiBncmFiIHNvbWUgaXRlbXMgKi8KKwkJCXVuc2ln bmVkIGxvbmcgaiA9IGluZGV4ICYgUkFESVhfVFJFRV9NQVBfTUFTSzsKKworCQkJ Zm9yICggOyBqIDwgUkFESVhfVFJFRV9NQVBfU0laRTsgaisrKSB7CisJCQkJaW5k ZXgrKzsKKwkJCQlpZiAodGFnX2dldChzbG90LCB0YWcsIGopKSB7CisJCQkJCUFT U0VSVChzbG90LT5zbG90c1tqXSAhPSBOVUxMKTsKKwkJCQkJcmVzdWx0c1tucl9m b3VuZCsrXSA9IHNsb3QtPnNsb3RzW2pdOworCQkJCQlpZiAobnJfZm91bmQgPT0g bWF4X2l0ZW1zKQorCQkJCQkJZ290byBvdXQ7CisJCQkJfQorCQkJfQorCQl9CisJ CXNoaWZ0IC09IFJBRElYX1RSRUVfTUFQX1NISUZUOworCQlzbG90ID0gc2xvdC0+ c2xvdHNbaV07CisJfQorb3V0OgorCSpuZXh0X2luZGV4ID0gaW5kZXg7CisJcmV0 dXJuIG5yX2ZvdW5kOworfQorCisvKioKKyAqCXJhZGl4X3RyZWVfZ2FuZ19sb29r dXBfdGFnIC0gcGVyZm9ybSBtdWx0aXBsZSBsb29rdXAgb24gYSByYWRpeCB0cmVl CisgKgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJhc2VkIG9uIGEgdGFn CisgKglAcm9vdDoJCXJhZGl4IHRyZWUgcm9vdAorICoJQHJlc3VsdHM6CXdoZXJl IHRoZSByZXN1bHRzIG9mIHRoZSBsb29rdXAgYXJlIHBsYWNlZAorICoJQGZpcnN0 X2luZGV4OglzdGFydCB0aGUgbG9va3VwIGZyb20gdGhpcyBrZXkKKyAqCUBtYXhf aXRlbXM6CXBsYWNlIHVwIHRvIHRoaXMgbWFueSBpdGVtcyBhdCAqcmVzdWx0cwor ICoJQHRhZzoJCXRoZSB0YWcgaW5kZXggKDwgUkFESVhfVFJFRV9NQVhfVEFHUykK KyAqCisgKglQZXJmb3JtcyBhbiBpbmRleC1hc2NlbmRpbmcgc2NhbiBvZiB0aGUg dHJlZSBmb3IgcHJlc2VudCBpdGVtcyB3aGljaAorICoJaGF2ZSB0aGUgdGFnIGlu ZGV4ZWQgYnkgQHRhZyBzZXQuICBQbGFjZXMgdGhlIGl0ZW1zIGF0ICpAcmVzdWx0 cyBhbmQKKyAqCXJldHVybnMgdGhlIG51bWJlciBvZiBpdGVtcyB3aGljaCB3ZXJl IHBsYWNlZCBhdCAqQHJlc3VsdHMuCisgKi8KK3Vuc2lnbmVkIGludAorcmFkaXhf dHJlZV9nYW5nX2xvb2t1cF90YWcoc3RydWN0IHJhZGl4X3RyZWVfcm9vdCAqcm9v dCwgdm9pZCAqKnJlc3VsdHMsCisJCXVuc2lnbmVkIGxvbmcgZmlyc3RfaW5kZXgs IHVuc2lnbmVkIGludCBtYXhfaXRlbXMsCisJCXVuc2lnbmVkIGludCB0YWcpCit7 CisJY29uc3QgdW5zaWduZWQgbG9uZyBtYXhfaW5kZXggPSByYWRpeF90cmVlX21h eGluZGV4KHJvb3QtPmhlaWdodCk7CisJdW5zaWduZWQgbG9uZyBjdXJfaW5kZXgg PSBmaXJzdF9pbmRleDsKKwl1bnNpZ25lZCBpbnQgcmV0ID0gMDsKKworCXdoaWxl IChyZXQgPCBtYXhfaXRlbXMpIHsKKwkJdW5zaWduZWQgaW50IG5yX2ZvdW5kOwor CQl1bnNpZ25lZCBsb25nIG5leHRfaW5kZXg7CS8qIEluZGV4IG9mIG5leHQgc2Vh cmNoICovCisKKwkJaWYgKGN1cl9pbmRleCA+IG1heF9pbmRleCkKKwkJCWJyZWFr OworCQlucl9mb3VuZCA9IF9fbG9va3VwX3RhZyhyb290LCByZXN1bHRzICsgcmV0 LCBjdXJfaW5kZXgsCisJCQkJCW1heF9pdGVtcyAtIHJldCwgJm5leHRfaW5kZXgs IHRhZyk7CisJCXJldCArPSBucl9mb3VuZDsKKwkJaWYgKG5leHRfaW5kZXggPT0g MCkKKwkJCWJyZWFrOworCQljdXJfaW5kZXggPSBuZXh0X2luZGV4OworCX0KKwly ZXR1cm4gcmV0OworfQorCisjZW5kaWYKKworLyoqCisgKglyYWRpeF90cmVlX3No cmluayAgICAtICAgIHNocmluayBoZWlnaHQgb2YgYSByYWRpeCB0cmVlIHRvIG1p bmltYWwKKyAqCUByb290CQlyYWRpeCB0cmVlIHJvb3QKKyAqLworc3RhdGljIGlu bGluZSB2b2lkIHJhZGl4X3RyZWVfc2hyaW5rKHN0cnVjdCByYWRpeF90cmVlX3Jv b3QgKnJvb3QpCit7CisJLyogdHJ5IHRvIHNocmluayB0cmVlIGhlaWdodCAqLwor CXdoaWxlIChyb290LT5oZWlnaHQgPiAxICYmCisJCQlyb290LT5ybm9kZS0+Y291 bnQgPT0gMSAmJgorCQkJcm9vdC0+cm5vZGUtPnNsb3RzWzBdKSB7CisJCXN0cnVj dCByYWRpeF90cmVlX25vZGUgKnRvX2ZyZWUgPSByb290LT5ybm9kZTsKKworCQly b290LT5ybm9kZSA9IHRvX2ZyZWUtPnNsb3RzWzBdOworCQlyb290LT5oZWlnaHQt LTsKKwkJLyogbXVzdCBvbmx5IGZyZWUgemVyb2VkIG5vZGVzIGludG8gdGhlIHNs YWIgKi8KKyNpZmRlZiBSQURJWF9UUkVFX1RBR1MKKwkJdGFnX2NsZWFyKHRvX2Zy ZWUsIDAsIDApOworCQl0YWdfY2xlYXIodG9fZnJlZSwgMSwgMCk7CisjZW5kaWYK KwkJdG9fZnJlZS0+c2xvdHNbMF0gPSBOVUxMOworCQl0b19mcmVlLT5jb3VudCA9 IDA7CisJCXJhZGl4X3RyZWVfbm9kZV9mcmVlKHRvX2ZyZWUpOworCX0KK30KKwor LyoqCisgKglyYWRpeF90cmVlX2RlbGV0ZSAgICAtICAgIGRlbGV0ZSBhbiBpdGVt IGZyb20gYSByYWRpeCB0cmVlCisgKglAcm9vdDoJCXJhZGl4IHRyZWUgcm9vdAor ICoJQGluZGV4OgkJaW5kZXgga2V5CisgKgorICoJUmVtb3ZlIHRoZSBpdGVtIGF0 IEBpbmRleCBmcm9tIHRoZSByYWRpeCB0cmVlIHJvb3RlZCBhdCBAcm9vdC4KKyAq CisgKglSZXR1cm5zIHRoZSBhZGRyZXNzIG9mIHRoZSBkZWxldGVkIGl0ZW0sIG9y IE5VTEwgaWYgaXQgd2FzIG5vdCBwcmVzZW50LgorICovCit2b2lkICpyYWRpeF90 cmVlX2RlbGV0ZShzdHJ1Y3QgcmFkaXhfdHJlZV9yb290ICpyb290LCB1bnNpZ25l ZCBsb25nIGluZGV4KQoreworCXN0cnVjdCByYWRpeF90cmVlX3BhdGggcGF0aFtS QURJWF9UUkVFX01BWF9QQVRIXSwgKnBhdGhwID0gcGF0aDsKKwlzdHJ1Y3QgcmFk aXhfdHJlZV9wYXRoICpvcmlnX3BhdGhwOworCXN0cnVjdCByYWRpeF90cmVlX25v ZGUgKnNsb3Q7CisJdW5zaWduZWQgaW50IGhlaWdodCwgc2hpZnQ7CisJdm9pZCAq cmV0ID0gTlVMTDsKKyNpZmRlZiBSQURJWF9UUkVFX1RBR1MKKwljaGFyIHRhZ3Nb UkFESVhfVFJFRV9NQVhfVEFHU107CisJaW50IG5yX2NsZWFyZWRfdGFnczsKKwlp bnQgdGFnOworI2VuZGlmCisJaW50IG9mZnNldDsKKworCWhlaWdodCA9IHJvb3Qt PmhlaWdodDsKKwlpZiAoaW5kZXggPiByYWRpeF90cmVlX21heGluZGV4KGhlaWdo dCkpCisJCWdvdG8gb3V0OworCisJc2hpZnQgPSAoaGVpZ2h0IC0gMSkgKiBSQURJ WF9UUkVFX01BUF9TSElGVDsKKwlwYXRocC0+bm9kZSA9IE5VTEw7CisJc2xvdCA9 IHJvb3QtPnJub2RlOworCisJZm9yICggOyBoZWlnaHQgPiAwOyBoZWlnaHQtLSkg eworCQlpZiAoc2xvdCA9PSBOVUxMKQorCQkJZ290byBvdXQ7CisKKwkJcGF0aHAr KzsKKwkJb2Zmc2V0ID0gKGluZGV4ID4+IHNoaWZ0KSAmIFJBRElYX1RSRUVfTUFQ X01BU0s7CisJCXBhdGhwLT5vZmZzZXQgPSBvZmZzZXQ7CisJCXBhdGhwLT5ub2Rl ID0gc2xvdDsKKwkJc2xvdCA9IHNsb3QtPnNsb3RzW29mZnNldF07CisJCXNoaWZ0 IC09IFJBRElYX1RSRUVfTUFQX1NISUZUOworCX0KKworCXJldCA9IHNsb3Q7CisJ aWYgKHJldCA9PSBOVUxMKQorCQlnb3RvIG91dDsKKworCW9yaWdfcGF0aHAgPSBw YXRocDsKKworI2lmZGVmIFJBRElYX1RSRUVfVEFHUworCS8qCisJICogQ2xlYXIg YWxsIHRhZ3MgYXNzb2NpYXRlZCB3aXRoIHRoZSBqdXN0LWRlbGV0ZWQgaXRlbQor CSAqLworCW5yX2NsZWFyZWRfdGFncyA9IDA7CisJZm9yICh0YWcgPSAwOyB0YWcg PCBSQURJWF9UUkVFX01BWF9UQUdTOyB0YWcrKykgeworCQl0YWdzW3RhZ10gPSAx OworCQlpZiAodGFnX2dldChwYXRocC0+bm9kZSwgdGFnLCBwYXRocC0+b2Zmc2V0 KSkgeworCQkJdGFnX2NsZWFyKHBhdGhwLT5ub2RlLCB0YWcsIHBhdGhwLT5vZmZz ZXQpOworCQkJaWYgKCFhbnlfdGFnX3NldChwYXRocC0+bm9kZSwgdGFnKSkgewor CQkJCXRhZ3NbdGFnXSA9IDA7CisJCQkJbnJfY2xlYXJlZF90YWdzKys7CisJCQl9 CisJCX0KKwl9CisKKwlmb3IgKHBhdGhwLS07IG5yX2NsZWFyZWRfdGFncyAmJiBw YXRocC0+bm9kZTsgcGF0aHAtLSkgeworCQlmb3IgKHRhZyA9IDA7IHRhZyA8IFJB RElYX1RSRUVfTUFYX1RBR1M7IHRhZysrKSB7CisJCQlpZiAodGFnc1t0YWddKQor CQkJCWNvbnRpbnVlOworCisJCQl0YWdfY2xlYXIocGF0aHAtPm5vZGUsIHRhZywg cGF0aHAtPm9mZnNldCk7CisJCQlpZiAoYW55X3RhZ19zZXQocGF0aHAtPm5vZGUs IHRhZykpIHsKKwkJCQl0YWdzW3RhZ10gPSAxOworCQkJCW5yX2NsZWFyZWRfdGFn cy0tOworCQkJfQorCQl9CisJfQorI2VuZGlmCisJLyogTm93IGZyZWUgdGhlIG5v ZGVzIHdlIGRvIG5vdCBuZWVkIGFueW1vcmUgKi8KKwlmb3IgKHBhdGhwID0gb3Jp Z19wYXRocDsgcGF0aHAtPm5vZGU7IHBhdGhwLS0pIHsKKwkJcGF0aHAtPm5vZGUt PnNsb3RzW3BhdGhwLT5vZmZzZXRdID0gTlVMTDsKKwkJcGF0aHAtPm5vZGUtPmNv dW50LS07CisKKwkJaWYgKHBhdGhwLT5ub2RlLT5jb3VudCkgeworCQkJaWYgKHBh dGhwLT5ub2RlID09IHJvb3QtPnJub2RlKQorCQkJCXJhZGl4X3RyZWVfc2hyaW5r KHJvb3QpOworCQkJZ290byBvdXQ7CisJCX0KKworCQkvKiBOb2RlIHdpdGggemVy byBzbG90cyBpbiB1c2Ugc28gZnJlZSBpdCAqLworCQlyYWRpeF90cmVlX25vZGVf ZnJlZShwYXRocC0+bm9kZSk7CisJfQorCXJvb3QtPnJub2RlID0gTlVMTDsKKwly b290LT5oZWlnaHQgPSAwOworb3V0OgorCXJldHVybiByZXQ7Cit9CisKKyNpZmRl ZiBSQURJWF9UUkVFX1RBR1MKKy8qKgorICoJcmFkaXhfdHJlZV90YWdnZWQgLSB0 ZXN0IHdoZXRoZXIgYW55IGl0ZW1zIGluIHRoZSB0cmVlIGFyZSB0YWdnZWQKKyAq CUByb290OgkJcmFkaXggdHJlZSByb290CisgKglAdGFnOgkJdGFnIHRvIHRlc3QK KyAqLworaW50IHJhZGl4X3RyZWVfdGFnZ2VkKHN0cnVjdCByYWRpeF90cmVlX3Jv b3QgKnJvb3QsIHVuc2lnbmVkIGludCB0YWcpCit7CisgIAlzdHJ1Y3QgcmFkaXhf dHJlZV9ub2RlICpybm9kZTsKKyAgCXJub2RlID0gcm9vdC0+cm5vZGU7CisgIAlp ZiAoIXJub2RlKQorICAJCXJldHVybiAwOworCXJldHVybiBhbnlfdGFnX3NldChy bm9kZSwgdGFnKTsKK30KKyNlbmRpZgorCitzdGF0aWMgdW5zaWduZWQgbG9uZyBf X21heGluZGV4KHVuc2lnbmVkIGludCBoZWlnaHQpCit7CisJdW5zaWduZWQgaW50 IHRtcCA9IGhlaWdodCAqIFJBRElYX1RSRUVfTUFQX1NISUZUOworCXVuc2lnbmVk IGxvbmcgaW5kZXggPSAofjBVTCA+PiAoUkFESVhfVFJFRV9JTkRFWF9CSVRTIC0g dG1wIC0gMSkpID4+IDE7CisKKwlpZiAodG1wID49IFJBRElYX1RSRUVfSU5ERVhf QklUUykKKwkJaW5kZXggPSB+MFVMOworCXJldHVybiBpbmRleDsKK30KKworc3Rh dGljIHZvaWQgcmFkaXhfdHJlZV9pbml0X21heGluZGV4KHZvaWQpCit7CisJdW5z aWduZWQgaW50IGk7CisKKwlmb3IgKGkgPSAwOyBpIDwgQVJSQVlfU0laRShoZWln aHRfdG9fbWF4aW5kZXgpOyBpKyspCisJCWhlaWdodF90b19tYXhpbmRleFtpXSA9 IF9fbWF4aW5kZXgoaSk7Cit9CisKK3ZvaWQgcmFkaXhfdHJlZV9pbml0KHZvaWQp Cit7CisJcmFkaXhfdHJlZV9pbml0X21heGluZGV4KCk7Cit9CkluZGV4OiByZXBh aXIveGZzcHJvZ3MvcmVwYWlyL3JhZGl4LXRyZWUuaAo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSAvZGV2L251bGwJMTk3MC0wMS0wMSAwMDowMDowMC4wMDAwMDAwMDAg KzAwMDAKKysrIHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvcmFkaXgtdHJlZS5oCTIw MDctMDUtMDMgMTg6Mzk6MDYuNzA1ODE1Njg3ICsxMDAwCkBAIC0wLDAgKzEsNzYg QEAKKy8qCisgKiBDb3B5cmlnaHQgKEMpIDIwMDEgTW9tY2hpbCBWZWxpa292Cisg KiBQb3J0aW9ucyBDb3B5cmlnaHQgKEMpIDIwMDEgQ2hyaXN0b3BoIEhlbGx3aWcK KyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiBy ZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBtb2RpZnkgaXQgdW5kZXIgdGhlIHRl cm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcworICogcHVi bGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2 ZXJzaW9uIDIsIG9yIChhdAorICogeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJz aW9uLgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUg aG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyAqIFdJVEhPVVQgQU5Z IFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YK KyAqIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg UFVSUE9TRS4gIFNlZSB0aGUgR05VCisgKiBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl IGZvciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2Vp dmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAq IGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBG cmVlIFNvZnR3YXJlCisgKiBGb3VuZGF0aW9uLCBJbmMuLCA2NzUgTWFzcyBBdmUs IENhbWJyaWRnZSwgTUEgMDIxMzksIFVTQS4KKyAqLworI2lmbmRlZiBfX1hGU19T VVBQT1JUX1JBRElYX1RSRUVfSF9fCisjZGVmaW5lIF9fWEZTX1NVUFBPUlRfUkFE SVhfVFJFRV9IX18KKworI2RlZmluZSBSQURJWF9UUkVFX1RBR1MKKworc3RydWN0 IHJhZGl4X3RyZWVfcm9vdCB7CisJdW5zaWduZWQgaW50CQloZWlnaHQ7CisJc3Ry dWN0IHJhZGl4X3RyZWVfbm9kZQkqcm5vZGU7Cit9OworCisjZGVmaW5lIFJBRElY X1RSRUVfSU5JVChtYXNrKQl7CQkJCQlcCisJLmhlaWdodCA9IDAsCQkJCQkJCVwK Kwkucm5vZGUgPSBOVUxMLAkJCQkJCQlcCit9CisKKyNkZWZpbmUgUkFESVhfVFJF RShuYW1lLCBtYXNrKSBcCisJc3RydWN0IHJhZGl4X3RyZWVfcm9vdCBuYW1lID0g UkFESVhfVFJFRV9JTklUKG1hc2spCisKKyNkZWZpbmUgSU5JVF9SQURJWF9UUkVF KHJvb3QsIG1hc2spCQkJCQlcCitkbyB7CQkJCQkJCQkJXAorCShyb290KS0+aGVp Z2h0ID0gMDsJCQkJCQlcCisJKHJvb3QpLT5ybm9kZSA9IE5VTEw7CQkJCQkJXAor fSB3aGlsZSAoMCkKKworI2lmZGVmIFJBRElYX1RSRUVfVEFHUworI2RlZmluZSBS QURJWF9UUkVFX01BWF9UQUdTIDIKKyNlbmRpZgorCitpbnQgcmFkaXhfdHJlZV9p bnNlcnQoc3RydWN0IHJhZGl4X3RyZWVfcm9vdCAqLCB1bnNpZ25lZCBsb25nLCB2 b2lkICopOwordm9pZCAqcmFkaXhfdHJlZV9sb29rdXAoc3RydWN0IHJhZGl4X3Ry ZWVfcm9vdCAqLCB1bnNpZ25lZCBsb25nKTsKK3ZvaWQgKipyYWRpeF90cmVlX2xv b2t1cF9zbG90KHN0cnVjdCByYWRpeF90cmVlX3Jvb3QgKiwgdW5zaWduZWQgbG9u Zyk7Cit2b2lkICpyYWRpeF90cmVlX2xvb2t1cF9maXJzdChzdHJ1Y3QgcmFkaXhf dHJlZV9yb290ICosIHVuc2lnbmVkIGxvbmcgKik7Cit2b2lkICpyYWRpeF90cmVl X2RlbGV0ZShzdHJ1Y3QgcmFkaXhfdHJlZV9yb290ICosIHVuc2lnbmVkIGxvbmcp OwordW5zaWduZWQgaW50CityYWRpeF90cmVlX2dhbmdfbG9va3VwKHN0cnVjdCBy YWRpeF90cmVlX3Jvb3QgKnJvb3QsIHZvaWQgKipyZXN1bHRzLAorCQkJdW5zaWdu ZWQgbG9uZyBmaXJzdF9pbmRleCwgdW5zaWduZWQgaW50IG1heF9pdGVtcyk7Cit1 bnNpZ25lZCBpbnQKK3JhZGl4X3RyZWVfZ2FuZ19sb29rdXBfZXgoc3RydWN0IHJh ZGl4X3RyZWVfcm9vdCAqcm9vdCwgdm9pZCAqKnJlc3VsdHMsCisJCQl1bnNpZ25l ZCBsb25nIGZpcnN0X2luZGV4LCB1bnNpZ25lZCBsb25nIGxhc3RfaW5kZXgsCisJ CQl1bnNpZ25lZCBpbnQgbWF4X2l0ZW1zKTsKKwordm9pZCByYWRpeF90cmVlX2lu aXQodm9pZCk7CisKKyNpZmRlZiBSQURJWF9UUkVFX1RBR1MKK3ZvaWQgKnJhZGl4 X3RyZWVfdGFnX3NldChzdHJ1Y3QgcmFkaXhfdHJlZV9yb290ICpyb290LAorCQkJ dW5zaWduZWQgbG9uZyBpbmRleCwgdW5zaWduZWQgaW50IHRhZyk7Cit2b2lkICpy YWRpeF90cmVlX3RhZ19jbGVhcihzdHJ1Y3QgcmFkaXhfdHJlZV9yb290ICpyb290 LAorCQkJdW5zaWduZWQgbG9uZyBpbmRleCwgdW5zaWduZWQgaW50IHRhZyk7Citp bnQgcmFkaXhfdHJlZV90YWdfZ2V0KHN0cnVjdCByYWRpeF90cmVlX3Jvb3QgKnJv b3QsCisJCQl1bnNpZ25lZCBsb25nIGluZGV4LCB1bnNpZ25lZCBpbnQgdGFnKTsK K3Vuc2lnbmVkIGludAorcmFkaXhfdHJlZV9nYW5nX2xvb2t1cF90YWcoc3RydWN0 IHJhZGl4X3RyZWVfcm9vdCAqcm9vdCwgdm9pZCAqKnJlc3VsdHMsCisJCQl1bnNp Z25lZCBsb25nIGZpcnN0X2luZGV4LCB1bnNpZ25lZCBpbnQgbWF4X2l0ZW1zLAor CQkJdW5zaWduZWQgaW50IHRhZyk7CitpbnQgcmFkaXhfdHJlZV90YWdnZWQoc3Ry dWN0IHJhZGl4X3RyZWVfcm9vdCAqcm9vdCwgdW5zaWduZWQgaW50IHRhZyk7Cisj ZW5kaWYKKworI2VuZGlmIC8qIF9fWEZTX1NVUFBPUlRfUkFESVhfVFJFRV9IX18g Ki8KSW5kZXg6IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvc2Nhbi5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dzL3JlcGFpci9zY2Fu LmMJMjAwNy0wNC0yNyAxMzoxMzozNS4wMDAwMDAwMDAgKzEwMDAKKysrIHJlcGFp ci94ZnNwcm9ncy9yZXBhaXIvc2Nhbi5jCTIwMDctMDUtMTYgMTI6MDI6MzkuNjQw NjUwOTEwICsxMDAwCkBAIC0yNyw3ICsyNyw2IEBACiAjaW5jbHVkZSAic2Nhbi5o IgogI2luY2x1ZGUgInZlcnNpb25zLmgiCiAjaW5jbHVkZSAiYm1hcC5oIgotI2lu Y2x1ZGUgInByZWZldGNoLmgiCiAjaW5jbHVkZSAicHJvZ3Jlc3MuaCIKIAogZXh0 ZXJuIGludCB2ZXJpZnlfc2V0X2FnaGVhZGVyKHhmc19tb3VudF90ICptcCwgeGZz X2J1Zl90ICpzYnVmLCB4ZnNfc2JfdCAqc2IsCkBAIC0xMTQ3LDkgKzExNDYsNiBA QAogCiAJYWdpX2RpcnR5ID0gYWdmX2RpcnR5ID0gc2JfZGlydHkgPSAwOwogCi0J aWYgKGRvX3ByZWZldGNoKQotCQlwcmVmZXRjaF9zYihtcCwgYWdubyk7Ci0KIAlz YmJ1ZiA9IGxpYnhmc19yZWFkYnVmKG1wLT5tX2RldiwgWEZTX0FHX0RBRERSKG1w LCBhZ25vLCBYRlNfU0JfREFERFIpLAogCQkJCVhGU19GU1NfVE9fQkIobXAsIDEp LCAwKTsKIAlpZiAoIXNiYnVmKSAgewpAQCAtMTI0MSw5ICsxMjM3LDYgQEAKIAog CXNjYW5fZnJlZWxpc3QoYWdmKTsKIAotCWlmIChkb19wcmVmZXRjaCkKLQkJIHBy ZWZldGNoX3Jvb3RzKG1wLCBhZ25vLCBhZ2YsIGFnaSk7Ci0KIAlpZiAoSU5UX0dF VChhZ2YtPmFnZl9yb290c1tYRlNfQlROVU1fQk5PXSwgQVJDSF9DT05WRVJUKSAh PSAwICYmCiAJICAgIHZlcmlmeV9hZ2JubyhtcCwgYWdubywKIAkJCUlOVF9HRVQo YWdmLT5hZ2Zfcm9vdHNbWEZTX0JUTlVNX0JOT10sIEFSQ0hfQ09OVkVSVCkpKQpJ bmRleDogcmVwYWlyL3hmc3Byb2dzL3JlcGFpci90aHJlYWRzLmMKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVwYWlyL3RocmVh ZHMuYwkyMDA3LTA0LTI3IDEzOjEzOjM1LjAwMDAwMDAwMCArMTAwMAorKysgcmVw YWlyL3hmc3Byb2dzL3JlcGFpci90aHJlYWRzLmMJMjAwNy0wNC0yNyAxNDoxMjoz NC4yMTk1NTk4NDcgKzEwMDAKQEAgLTEsMTM4ICsxLDYwIEBACiAjaW5jbHVkZSA8 bGlieGZzLmg+Ci0jaW5jbHVkZSAicHRocmVhZC5oIgotI2luY2x1ZGUgInNpZ25h bC5oIgorI2luY2x1ZGUgPHB0aHJlYWQuaD4KKyNpbmNsdWRlIDxzaWduYWwuaD4K ICNpbmNsdWRlICJ0aHJlYWRzLmgiCiAjaW5jbHVkZSAiZXJyX3Byb3Rvcy5oIgog I2luY2x1ZGUgInByb3Rvcy5oIgorI2luY2x1ZGUgImdsb2JhbHMuaCIKIAotaW50 IGRvX3BhcmFsbGVsID0gMTsKLWludCB0aHJlYWRfY291bnQ7Ci0KLS8qIEEgcXVh bnR1bSBvZiB3b3JrICovCi10eXBlZGVmIHN0cnVjdCB3b3JrX3MgewotCXN0cnVj dCB3b3JrX3MJKm5leHQ7Ci0JZGlzcF9mdW5jX3QJKmZ1bmN0aW9uOwotCXhmc19t b3VudF90CSptcDsKLQl4ZnNfYWdudW1iZXJfdAlhZ25vOwotfSB3b3JrX3Q7Ci0K LXR5cGVkZWYgc3RydWN0ICB3b3JrX3F1ZXVlX3MgewotCXdvcmtfdAkJKm5leHQ7 Ci0Jd29ya190CQkqbGFzdDsKLQlpbnQJCWFjdGl2ZV90aHJlYWRzOwotCWludAkJ d29ya19jb3VudDsKLQlwdGhyZWFkX2NvbmRfdAltY3Y7CS8qIG1haW4gdGhyZWFk IGNvbmRpdGlvbmFsIHZhcmlhYmxlICovCi0JcHRocmVhZF9jb25kX3QJd2N2Owkv KiB3b3JrZXIgdGhyZWFkcyBjb25kaXRpb25hbCB2YXJpYWJsZSAqLwotCXB0aHJl YWRfbXV0ZXhfdAltdXRleDsKLX0gd29ya19xdWV1ZV90OwotCi1zdGF0aWMJd29y a19xdWV1ZV90CXdvcmtfcXVldWU7Ci1zdGF0aWMJcHRocmVhZF90CSp3b3JrX3Ro cmVhZHM7Ci0KLXN0YXRpYwl2b2lkCSp3b3JrZXJfdGhyZWFkKHZvaWQgKmFyZyk7 Ci0KLXN0YXRpYyB2b2lkCi1pbml0X3dvcmtlcnMod29ya19xdWV1ZV90ICp3cSwg aW50IG53KQorc3RhdGljIHZvaWQgKgord29ya2VyX3RocmVhZCh2b2lkICphcmcp CiB7Ci0JaW50CQkJZXJyOwotCXB0aHJlYWRfbXV0ZXhhdHRyX3QJbXR4YXR0cjsK LQotCW1lbXNldCh3cSwgMCwgc2l6ZW9mKHdvcmtfcXVldWVfdCkpOwotCXdxLT5h Y3RpdmVfdGhyZWFkcyA9IG53OwotCi0JcHRocmVhZF9jb25kX2luaXQoJndxLT5t Y3YsIE5VTEwpOwotCXB0aHJlYWRfY29uZF9pbml0KCZ3cS0+d2N2LCBOVUxMKTsK LQlwdGhyZWFkX211dGV4YXR0cl9pbml0KCZtdHhhdHRyKTsKLQotI2lmZGVmCVBU SFJFQURfTVVURVhfU1BJTkJMT0NLX05QCi0JLyogTlAgLSBOb24gUG9ydGFibGUg LSBJcml4ICovCi0JaWYgKChlcnIgPSBwdGhyZWFkX211dGV4YXR0cl9zZXR0eXBl KCZtdHhhdHRyLAotCQkJUFRIUkVBRF9NVVRFWF9TUElOQkxPQ0tfTlApKSA+IDAp IHsKLQkJZG9fZXJyb3IoXygiaW5pdF93b3JrZXJzOiB0aHJlYWQgMHgleDogcHRo cmVhZF9tdXRleGF0dHJfc2V0dHlwZSBlcnJvciAlZDogJXNcbiIpLAotCQkJcHRo cmVhZF9zZWxmKCksIGVyciwgc3RyZXJyb3IoZXJyKSk7Ci0JfQotI2VuZGlmCi0j aWZkZWYJUFRIUkVBRF9NVVRFWF9GQVNUX05QCi0JLyogTlAgLSBOb24gUG9ydGFi bGUgLSBMaW51eCAqLwotCWlmICgoZXJyID0gcHRocmVhZF9tdXRleGF0dHJfc2V0 dHlwZSgmbXR4YXR0ciwKLQkJCVBUSFJFQURfTVVURVhfRkFTVF9OUCkpID4gMCkg ewotCQlkb19lcnJvcihfKCJpbml0X3dvcmtlcnM6IHRocmVhZCAweCV4OiBwdGhy ZWFkX211dGV4YXR0cl9zZXR0eXBlIGVycm9yICVkOiAlc1xuIiksCi0JCQlwdGhy ZWFkX3NlbGYoKSwgZXJyLCBzdHJlcnJvcihlcnIpKTsKLQl9Ci0jZW5kaWYKLQlp ZiAoKGVyciA9IHB0aHJlYWRfbXV0ZXhfaW5pdCgmd3EtPm11dGV4LCAmbXR4YXR0 cikpID4gMCkgewotCQlkb19lcnJvcihfKCJpbml0X3dvcmtlcnM6IHRocmVhZCAw eCV4OiBwdGhyZWFkX211dGV4X2luaXQgZXJyb3IgJWQ6ICVzXG4iKSwKLQkJCXB0 aHJlYWRfc2VsZigpLCBlcnIsIHN0cmVycm9yKGVycikpOwotCX0KLX0KKwl3b3Jr X3F1ZXVlX3QJKndxOworCXdvcmtfaXRlbV90CSp3aTsKIAotc3RhdGljIHZvaWQK LXF1aWVzY2Vfd29ya2Vycyh3b3JrX3F1ZXVlX3QgKndxKQotewotCWludAllcnI7 CisJd3EgPSAod29ya19xdWV1ZV90Kilhcmc7CiAKLQlpZiAoKGVyciA9IHB0aHJl YWRfbXV0ZXhfbG9jaygmd3EtPm11dGV4KSkgPiAwKQotCQlkb19lcnJvcihfKCJx dWllc2NlX3dvcmtlcnM6IHRocmVhZCAweCV4OiBwdGhyZWFkX211dGV4X2xvY2sg ZXJyb3IgJWQ6ICVzXG4iKSwKLQkJCXB0aHJlYWRfc2VsZigpLCBlcnIsIHN0cmVy cm9yKGVycikpOwotCWlmICh3cS0+YWN0aXZlX3RocmVhZHMgPiAwKSB7Ci0JCWlm ICgoZXJyID0gcHRocmVhZF9jb25kX3dhaXQoJndxLT5tY3YsICZ3cS0+bXV0ZXgp KSA+IDApCi0JCQlkb19lcnJvcihfKCJxdWllc2NlX3dvcmtlcnM6IHRocmVhZCAw eCV4OiBwdGhyZWFkX2NvbmRfd2FpdCBlcnJvciAlZDogJXNcbiIpLAotCQkJCXB0 aHJlYWRfc2VsZigpLCBlcnIsIHN0cmVycm9yKGVycikpOwotCX0KLQlBU1NFUlQo d3EtPmFjdGl2ZV90aHJlYWRzID09IDApOwotCWlmICgoZXJyID0gcHRocmVhZF9t dXRleF91bmxvY2soJndxLT5tdXRleCkpID4gMCkKLQkJZG9fZXJyb3IoXygicXVp ZXNjZV93b3JrZXJzOiB0aHJlYWQgMHgleDogcHRocmVhZF9tdXRleF91bmxvY2sg ZXJyb3IgJWQ6ICVzXG4iKSwKLQkJCXB0aHJlYWRfc2VsZigpLCBlcnIsIHN0cmVy cm9yKGVycikpOwotfQorCS8qCisJICogTG9vcCBwdWxsaW5nIHdvcmsgZnJvbSB0 aGUgcGFzc2VkIGluIHdvcmsgcXVldWUuCisJICogQ2hlY2sgZm9yIG5vdGlmaWNh dGlvbiB0byBleGl0IGFmdGVyIGV2ZXJ5IGNodW5rIG9mIHdvcmsuCisJICovCisJ d2hpbGUgKDEpIHsKKwkJcHRocmVhZF9tdXRleF9sb2NrKCZ3cS0+bG9jayk7CiAK LXN0YXRpYyB2b2lkCi1zdGFydF93b3JrZXJzKHdvcmtfcXVldWVfdCAqd3EsIHVu c2lnbmVkIHRoY250LCBwdGhyZWFkX2F0dHJfdCAqYXR0cnApCi17Ci0JaW50CQll cnI7Ci0JdW5zaWduZWQgbG9uZwlpOworCQkvKgorCQkgKiBXYWl0IGZvciB3b3Jr LgorCQkgKi8KKwkJd2hpbGUgKHdxLT5uZXh0X2l0ZW0gPT0gTlVMTCAmJiAhd3Et PnRlcm1pbmF0ZSkgeworCQkJQVNTRVJUKHdxLT5pdGVtX2NvdW50ID09IDApOwor CQkJcHRocmVhZF9jb25kX3dhaXQoJndxLT53YWtldXAsICZ3cS0+bG9jayk7CisJ CX0KKwkJaWYgKHdxLT5uZXh0X2l0ZW0gPT0gTlVMTCAmJiB3cS0+dGVybWluYXRl KSB7CisJCQlwdGhyZWFkX211dGV4X3VubG9jaygmd3EtPmxvY2spOworCQkJYnJl YWs7CisJCX0KIAotCWluaXRfd29ya2Vycyh3cSwgdGhjbnQpOworCQkvKgorCQkg KiAgRGVxdWV1ZSB3b3JrIGZyb20gdGhlIGhlYWQgb2YgdGhlIGxpc3QuCisJCSAq LworCQlBU1NFUlQod3EtPml0ZW1fY291bnQgPiAwKTsKKwkJd2kgPSB3cS0+bmV4 dF9pdGVtOworCQl3cS0+bmV4dF9pdGVtID0gd2ktPm5leHQ7CisJCXdxLT5pdGVt X2NvdW50LS07CiAKLQlpZiAoKHdvcmtfdGhyZWFkcyA9IChwdGhyZWFkX3QgKilt YWxsb2Moc2l6ZW9mKHB0aHJlYWRfdCkgKiB0aGNudCkpID09IE5VTEwpCi0JCWRv X2Vycm9yKF8oImNhbm5vdCBtYWxsb2MgJWxkIGJ5dGVzIGZvciB3b3JrX3RocmVh ZHMgYXJyYXlcbiIpLAotCQkJCXNpemVvZihwdGhyZWFkX3QpICogdGhjbnQpOwor CQlwdGhyZWFkX211dGV4X3VubG9jaygmd3EtPmxvY2spOwogCi0JLyoKLQkqKiAg Q3JlYXRlIHdvcmtlciB0aHJlYWRzCi0JKi8KLQlmb3IgKGkgPSAwOyBpIDwgdGhj bnQ7IGkrKykgewotCQllcnIgPSBwdGhyZWFkX2NyZWF0ZSgmd29ya190aHJlYWRz W2ldLCBhdHRycCwgd29ya2VyX3RocmVhZCwgKHZvaWQgKikgaSk7Ci0JCWlmKGVy ciA+IDApIHsKLQkJICAgICAgICBkb19lcnJvcihfKCJjYW5ub3QgY3JlYXRlIHdv cmtlciB0aHJlYWRzLCBzdGF0dXMgPSBbJWRdICVzXG4iKSwKLQkJCQllcnIsIHN0 cmVycm9yKGVycikpOwotCQl9CisJCSh3aS0+ZnVuY3Rpb24pKHdpLT5xdWV1ZSwg d2ktPmFnbm8sIHdpLT5hcmcpOworCQlmcmVlKHdpKTsKIAl9Ci0JZG9fbG9nKF8o IiAgICAgICAgLSBjcmVhdGluZyAlZCB3b3JrZXIgdGhyZWFkKHMpXG4iKSwgdGhj bnQpOwogCi0JLyoKLQkqKiAgV2FpdCBmb3IgYWxsIHdvcmtlciB0aHJlYWRzIHRv IGluaXRpYWxpemUKLQkqLwotCXF1aWVzY2Vfd29ya2Vycyh3cSk7CisJcmV0dXJu IE5VTEw7CiB9CiAKIHZvaWQKIHRocmVhZF9pbml0KHZvaWQpCiB7Ci0JaW50CQlz dGF0dXM7Ci0JcHRocmVhZF9hdHRyX3QJYXR0cjsKIAlzaWdzZXRfdAlibG9ja2Vk OwogCi0JaWYgKGRvX3BhcmFsbGVsID09IDApCi0JCXJldHVybjsKLQlpZiAodGhy ZWFkX2NvdW50ID09IDApCi0JCXRocmVhZF9jb3VudCA9IDIgKiBsaWJ4ZnNfbnBy b2MoKTsKLQotCWlmICgoc3RhdHVzID0gcHRocmVhZF9hdHRyX2luaXQoJmF0dHIp KSAhPSAwKQotCQlkb19lcnJvcihfKCJzdGF0dXMgZnJvbSBwdGhyZWFkX2F0dHJf aW5pdDogJWQiKSxzdGF0dXMpOwotCi0JaWYgKChzdGF0dXMgPSBwdGhyZWFkX3Nl dGNvbmN1cnJlbmN5KHRocmVhZF9jb3VudCkpICE9IDApCi0JCWRvX2Vycm9yKF8o IlN0YXR1cyBmcm9tIHB0aHJlYWRfc2V0Y29uY3VycmVuY3koJWQpOiAlZCIpLCB0 aHJlYWRfY291bnQsIHN0YXR1cyk7Ci0KIAkvKgogCSAqICBibG9jayBkZWxpdmVy eSBvZiBwcm9ncmVzcyByZXBvcnQgc2lnbmFsIHRvIGFsbCB0aHJlYWRzCiAgICAg ICAgICAqLwpAQCAtMTQwLDE2MCArNjIsOTAgQEAKIAlzaWdhZGRzZXQoJmJsb2Nr ZWQsIFNJR0hVUCk7CiAJc2lnYWRkc2V0KCZibG9ja2VkLCBTSUdBTFJNKTsKIAlw dGhyZWFkX3NpZ21hc2soU0lHX0JMT0NLLCAmYmxvY2tlZCwgTlVMTCk7Ci0KLQlz dGFydF93b3JrZXJzKCZ3b3JrX3F1ZXVlLCB0aHJlYWRfY291bnQsICZhdHRyKTsK IH0KIAotLyoKLSAqIERlcXVldWUgZnJvbSB0aGUgaGVhZCBvZiB0aGUgbGlzdC4K LSAqIHdxLT5tdXRleCBoZWxkLgotICovCi1zdGF0aWMgd29ya190ICoKLWRlcXVl dWUod29ya19xdWV1ZV90ICp3cSkKKwordm9pZAorY3JlYXRlX3dvcmtfcXVldWUo CisJd29ya19xdWV1ZV90CQkqd3EsCisJeGZzX21vdW50X3QJCSptcCwKKwlpbnQJ CQlud29ya2VycykKIHsKLQl3b3JrX3QJKndwOworCWludAkJCWVycjsKKwlpbnQJ CQlpOwogCi0JQVNTRVJUKHdxLT53b3JrX2NvdW50ID4gMCk7Ci0Jd3AgPSB3cS0+ bmV4dDsKLQl3cS0+bmV4dCA9IHdwLT5uZXh0OwotCXdxLT53b3JrX2NvdW50LS07 Ci0JaWYgKHdxLT5uZXh0ID09IE5VTEwpIHsKLQkJQVNTRVJUKHdxLT53b3JrX2Nv dW50ID09IDApOwotCQl3cS0+bGFzdCA9IE5VTEw7Ci0JfQotCXdwLT5uZXh0ID0g TlVMTDsKLQlyZXR1cm4gKHdwKTsKLX0KKwltZW1zZXQod3EsIDAsIHNpemVvZih3 b3JrX3F1ZXVlX3QpKTsKIAotc3RhdGljIHZvaWQgKgotd29ya2VyX3RocmVhZCh2 b2lkICphcmcpCi17Ci0Jd29ya19xdWV1ZV90CSp3cTsKLQl3b3JrX3QJCSp3cDsK LQlpbnQJCWVycjsKLQl1bnNpZ25lZCBsb25nCW15aWQ7Ci0KLQl3cSA9ICZ3b3Jr X3F1ZXVlOwotCW15aWQgPSAodW5zaWduZWQgbG9uZykgYXJnOwotCXRzX2luaXQo KTsKLQlsaWJ4ZnNfbGlvX2FsbG9jYXRlKCk7CisJcHRocmVhZF9jb25kX2luaXQo JndxLT53YWtldXAsIE5VTEwpOworCXB0aHJlYWRfbXV0ZXhfaW5pdCgmd3EtPmxv Y2ssIE5VTEwpOwogCi0JLyoKLQkgKiBMb29wIHB1bGxpbmcgd29yayBmcm9tIHRo ZSBnbG9iYWwgd29yayBxdWV1ZS4KLQkgKiBDaGVjayBmb3Igbm90aWZpY2F0aW9u IHRvIGV4aXQgYWZ0ZXIgZXZlcnkgY2h1bmsgb2Ygd29yay4KLQkgKi8KLQl3aGls ZSAoMSkgewotCQlpZiAoKGVyciA9IHB0aHJlYWRfbXV0ZXhfbG9jaygmd3EtPm11 dGV4KSkgPiAwKQotCQkJZG9fZXJyb3IoXygid29ya190aHJlYWQlZDogdGhyZWFk IDB4JXg6IHB0aHJlYWRfbXV0ZXhfbG9jayBlcnJvciAlZDogJXNcbiIpLAotCQkJ CW15aWQsIHB0aHJlYWRfc2VsZigpLCBlcnIsIHN0cmVycm9yKGVycikpOwotCQkv KgotCQkgKiBXYWl0IGZvciB3b3JrLgotCQkgKi8KLQkJd2hpbGUgKHdxLT5uZXh0 ID09IE5VTEwpIHsKLQkJCUFTU0VSVCh3cS0+d29ya19jb3VudCA9PSAwKTsKLQkJ CS8qCi0JCQkgKiBMYXN0IHRocmVhZCBnb2luZyB0byBpZGxlIHNsZWVwIG11c3Qg d2FrZXVwCi0JCQkgKiB0aGUgbWFzdGVyIHRocmVhZC4gIFNhbWUgbXV0ZXggaXMg dXNlZCB0byBsb2NrCi0JCQkgKiBhcm91bmQgdHdvIGRpZmZlcmVudCBjb25kaXRp b24gdmFyaWFibGVzLgotCQkJICovCi0JCQl3cS0+YWN0aXZlX3RocmVhZHMtLTsK LQkJCUFTU0VSVCh3cS0+YWN0aXZlX3RocmVhZHMgPj0gMCk7Ci0JCQlpZiAoIXdx LT5hY3RpdmVfdGhyZWFkcykgewotCQkJCWlmICgoZXJyID0gcHRocmVhZF9jb25k X3NpZ25hbCgmd3EtPm1jdikpID4gMCkKLQkJCQkJZG9fZXJyb3IoXygid29ya190 aHJlYWQlZDogdGhyZWFkIDB4JXg6IHB0aHJlYWRfY29uZF9zaWduYWwgZXJyb3Ig JWQ6ICVzXG4iKSwKLQkJCQkJCW15aWQsIHB0aHJlYWRfc2VsZigpLCBlcnIsIHN0 cmVycm9yKGVycikpOwotCQkJfQotCQkJaWYgKChlcnIgPSBwdGhyZWFkX2NvbmRf d2FpdCgmd3EtPndjdiwgJndxLT5tdXRleCkpID4gMCkKLQkJCQlkb19lcnJvcihf KCJ3b3JrX3RocmVhZCVkOiB0aHJlYWQgMHgleDogcHRocmVhZF9jb25kX3dhaXQg ZXJyb3IgJWQ6ICVzXG4iKSwKLQkJCQkJbXlpZCwgcHRocmVhZF9zZWxmKCksIGVy ciwgc3RyZXJyb3IoZXJyKSk7Ci0JCQl3cS0+YWN0aXZlX3RocmVhZHMrKzsKKwl3 cS0+bXAgPSBtcDsKKwl3cS0+dGhyZWFkX2NvdW50ID0gbndvcmtlcnM7CisJd3Et PnRocmVhZHMgPSBtYWxsb2MobndvcmtlcnMgKiBzaXplb2YocHRocmVhZF90KSk7 CisJd3EtPnRlcm1pbmF0ZSA9IDA7CisKKwlmb3IgKGkgPSAwOyBpIDwgbndvcmtl cnM7IGkrKykgeworCQllcnIgPSBwdGhyZWFkX2NyZWF0ZSgmd3EtPnRocmVhZHNb aV0sIE5VTEwsIHdvcmtlcl90aHJlYWQsIHdxKTsKKwkJaWYgKGVyciAhPSAwKSB7 CisJCQlkb19lcnJvcihfKCJjYW5ub3QgY3JlYXRlIHdvcmtlciB0aHJlYWRzLCBl cnJvciA9IFslZF0gJXNcbiIpLAorCQkJCWVyciwgc3RyZXJyb3IoZXJyKSk7CiAJ CX0KLQkJLyoKLQkJICogIERlcXVldWUgd29yayBmcm9tIHRoZSBoZWFkIG9mIHRo ZSBsaXN0LgotCQkgKi8KLQkJQVNTRVJUKHdxLT53b3JrX2NvdW50ID4gMCk7Ci0J CXdwID0gZGVxdWV1ZSh3cSk7Ci0JCWlmICgoZXJyID0gcHRocmVhZF9tdXRleF91 bmxvY2soJndxLT5tdXRleCkpID4gMCkKLQkJCWRvX2Vycm9yKF8oIndvcmtfdGhy ZWFkJWQ6IHRocmVhZCAweCV4OiBwdGhyZWFkX211dGV4X3VubG9jayBlcnJvciAl ZDogJXNcbiIpLAotCQkJCW15aWQsIHB0aHJlYWRfc2VsZigpLCBlcnIsIHN0cmVy cm9yKGVycikpOwotCQkvKgotCQkgKiAgRG8gdGhlIHdvcmsuCi0JCSAqLwotCQko d3AtPmZ1bmN0aW9uKSh3cC0+bXAsIHdwLT5hZ25vKTsKLQotCQlmcmVlKHdwKTsK IAl9Ci0JLyogTk9UIFJFQUNIRUQgKi8KLQlwdGhyZWFkX2V4aXQoTlVMTCk7Ci0J cmV0dXJuIChOVUxMKTsKLX0KIAotaW50Ci1xdWV1ZV93b3JrKGRpc3BfZnVuY190 IGZ1bmMsIHhmc19tb3VudF90ICptcCwgeGZzX2FnbnVtYmVyX3QgYWdubykKLXsK LQl3b3JrX3F1ZXVlX3QgKndxOwotCXdvcmtfdAkqd3A7Cit9CiAKLQlpZiAoZG9f cGFyYWxsZWwgPT0gMCkgewotCQlmdW5jKG1wLCBhZ25vKTsKLQkJcmV0dXJuIDA7 Ci0JfQotCXdxID0gJndvcmtfcXVldWU7Ci0JLyoKLQkgKiBHZXQgbWVtb3J5IGZv ciBhIG5ldyB3b3JrIHN0cnVjdHVyZS4KLQkgKi8KLQlpZiAoKHdwID0gKHdvcmtf dCAqKW1lbWFsaWduKDgsIHNpemVvZih3b3JrX3QpKSkgPT0gTlVMTCkKLQkJcmV0 dXJuIChFTk9NRU0pOwotCS8qCi0JICogSW5pdGlhbGl6ZSB0aGUgbmV3IHdvcmsg c3RydWN0dXJlLgotCSAqLwotCXdwLT5mdW5jdGlvbiA9IGZ1bmM7Ci0Jd3AtPm1w ID0gbXA7Ci0Jd3AtPmFnbm8gPSBhZ25vOwordm9pZAorcXVldWVfd29yaygKKwl3 b3JrX3F1ZXVlX3QJKndxLAorCXdvcmtfZnVuY190CWZ1bmMsCisJeGZzX2FnbnVt YmVyX3QJYWdubywKKwl2b2lkCQkqYXJnKQoreworCXdvcmtfaXRlbV90CSp3aTsK KworCXdpID0gKHdvcmtfaXRlbV90ICopbWFsbG9jKHNpemVvZih3b3JrX2l0ZW1f dCkpOworCWlmICh3aSA9PSBOVUxMKQorCQlkb19lcnJvcihfKCJjYW5ub3QgYWxs b2NhdGUgd29ya2VyIGl0ZW0sIGVycm9yID0gWyVkXSAlc1xuIiksCisJCQllcnJu bywgc3RyZXJyb3IoZXJybm8pKTsKKworCXdpLT5mdW5jdGlvbiA9IGZ1bmM7CisJ d2ktPmFnbm8gPSBhZ25vOworCXdpLT5hcmcgPSBhcmc7CisJd2ktPnF1ZXVlID0g d3E7CisJd2ktPm5leHQgPSBOVUxMOwogCiAJLyoKIAkgKiAgTm93IHF1ZXVlIHRo ZSBuZXcgd29yayBzdHJ1Y3R1cmUgdG8gdGhlIHdvcmsgcXVldWUuCiAJICovCi0J aWYgKHdxLT5uZXh0ID09IE5VTEwpIHsKLQkJd3EtPm5leHQgPSB3cDsKKwlwdGhy ZWFkX211dGV4X2xvY2soJndxLT5sb2NrKTsKKwlpZiAod3EtPm5leHRfaXRlbSA9 PSBOVUxMKSB7CisJCXdxLT5uZXh0X2l0ZW0gPSB3aTsKKwkJQVNTRVJUKHdxLT5p dGVtX2NvdW50ID09IDApOworCQlwdGhyZWFkX2NvbmRfc2lnbmFsKCZ3cS0+d2Fr ZXVwKTsKIAl9IGVsc2UgewotCQl3cS0+bGFzdC0+bmV4dCA9IHdwOworCQl3cS0+ bGFzdF9pdGVtLT5uZXh0ID0gd2k7CiAJfQotCXdxLT5sYXN0ID0gd3A7Ci0Jd3At Pm5leHQgPSBOVUxMOwotCXdxLT53b3JrX2NvdW50Kys7Ci0KLQlyZXR1cm4gKDAp OworCXdxLT5sYXN0X2l0ZW0gPSB3aTsKKwl3cS0+aXRlbV9jb3VudCsrOworCXB0 aHJlYWRfbXV0ZXhfdW5sb2NrKCZ3cS0+bG9jayk7CiB9CiAKIHZvaWQKLXdhaXRf Zm9yX3dvcmtlcnModm9pZCkKK2Rlc3Ryb3lfd29ya19xdWV1ZSgKKwl3b3JrX3F1 ZXVlX3QJKndxKQogewotCWludAkJZXJyOwotCXdvcmtfcXVldWVfdAkqd3E7CisJ aW50CQlpOwogCi0JaWYgKGRvX3BhcmFsbGVsID09IDApCi0JCXJldHVybjsKLQl3 cSA9ICZ3b3JrX3F1ZXVlOwotCWlmICgoZXJyID0gcHRocmVhZF9tdXRleF9sb2Nr KCZ3cS0+bXV0ZXgpKSA+IDApCi0JCWRvX2Vycm9yKF8oIndhaXRfZm9yX3dvcmtl cnM6IHRocmVhZCAweCV4OiBwdGhyZWFkX211dGV4X2xvY2sgZXJyb3IgJWQ6ICVz XG4iKSwKLQkJCXB0aHJlYWRfc2VsZigpLCBlcnIsIHN0cmVycm9yKGVycikpOwot Ci0JQVNTRVJUKHdxLT5hY3RpdmVfdGhyZWFkcyA9PSAwKTsKLQlpZiAod3EtPndv cmtfY291bnQgPiAwKSB7Ci0JCS8qIGdldCB0aGUgd29ya2VycyBnb2luZyAqLwot CQlpZiAoKGVyciA9IHB0aHJlYWRfY29uZF9icm9hZGNhc3QoJndxLT53Y3YpKSA+ IDApCi0JCQlkb19lcnJvcihfKCJ3YWl0X2Zvcl93b3JrZXJzOiB0aHJlYWQgMHgl eDogcHRocmVhZF9jb25kX2Jyb2FkY2FzdCBlcnJvciAlZDogJXNcbiIpLAotCQkJ CXB0aHJlYWRfc2VsZigpLCBlcnIsIHN0cmVycm9yKGVycikpOwotCQkvKiBhbmQg d2FpdCBmb3IgdGhlbSAqLwotCQlpZiAoKGVyciA9IHB0aHJlYWRfY29uZF93YWl0 KCZ3cS0+bWN2LCAmd3EtPm11dGV4KSkgPiAwKQotCQkJZG9fZXJyb3IoXygid2Fp dF9mb3Jfd29ya2VyczogdGhyZWFkIDB4JXg6IHB0aHJlYWRfY29uZF93YWl0IGVy cm9yICVkOiAlc1xuIiksCi0JCQkJcHRocmVhZF9zZWxmKCksIGVyciwgc3RyZXJy b3IoZXJyKSk7Ci0JfQotCUFTU0VSVCh3cS0+YWN0aXZlX3RocmVhZHMgPT0gMCk7 Ci0JQVNTRVJUKHdxLT53b3JrX2NvdW50ID09IDApOworCXB0aHJlYWRfbXV0ZXhf bG9jaygmd3EtPmxvY2spOworCXdxLT50ZXJtaW5hdGUgPSAxOworCXB0aHJlYWRf bXV0ZXhfdW5sb2NrKCZ3cS0+bG9jayk7CisKKwlwdGhyZWFkX2NvbmRfYnJvYWRj YXN0KCZ3cS0+d2FrZXVwKTsKKworCWZvciAoaSA9IDA7IGkgPCB3cS0+dGhyZWFk X2NvdW50OyBpKyspCisJCXB0aHJlYWRfam9pbih3cS0+dGhyZWFkc1tpXSwgTlVM TCk7CiAKLQlpZiAoKGVyciA9IHB0aHJlYWRfbXV0ZXhfdW5sb2NrKCZ3cS0+bXV0 ZXgpKSA+IDApCi0JCWRvX2Vycm9yKF8oIndhaXRfZm9yX3dvcmtlcnM6IHRocmVh ZCAweCV4OiBwdGhyZWFkX211dGV4X3VubG9jayBlcnJvciAlZDogJXNcbiIpLAot CQkJcHRocmVhZF9zZWxmKCksIGVyciwgc3RyZXJyb3IoZXJyKSk7CisJZnJlZSh3 cS0+dGhyZWFkcyk7CisJcHRocmVhZF9tdXRleF9kZXN0cm95KCZ3cS0+bG9jayk7 CisJcHRocmVhZF9jb25kX2Rlc3Ryb3koJndxLT53YWtldXApOwogfQpJbmRleDog cmVwYWlyL3hmc3Byb2dzL3JlcGFpci90aHJlYWRzLmgKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVwYWlyL3RocmVhZHMuaAky MDA3LTA0LTI3IDEzOjEzOjM1LjAwMDAwMDAwMCArMTAwMAorKysgcmVwYWlyL3hm c3Byb2dzL3JlcGFpci90aHJlYWRzLmgJMjAwNy0wNC0yNyAxNDoxMjozNC4yMTk1 NTk4NDcgKzEwMDAKQEAgLTEsMzcgKzEsNDcgQEAKICNpZm5kZWYJX1hGU19SRVBB SVJfVEhSRUFEU19IXwogI2RlZmluZQlfWEZTX1JFUEFJUl9USFJFQURTX0hfCiAK LWV4dGVybiBpbnQJCWRvX3BhcmFsbGVsOwotZXh0ZXJuIGludAkJdGhyZWFkX2Nv dW50OwotLyoKLSoqICBsb2NraW5nIHZhcmlhbnRzIC0gcndsb2NrL211dGV4Ci0q LwotI2RlZmluZSBQUkVQQUlSX1JXX0xPQ0tfQVRUUgkJUFRIUkVBRF9QUk9DRVNT X1BSSVZBVEUKLQotI2RlZmluZQlQUkVQQUlSX1JXX0xPQ0tfQUxMT0MobGtwLCBu KQkJCQlcCi0JaWYgKGRvX3BhcmFsbGVsKSB7CQkJCQlcCi0JCWxrcCA9IG1hbGxv YyhuKnNpemVvZihwdGhyZWFkX3J3bG9ja190KSk7CVwKLQkJaWYgKGxrcCA9PSBO VUxMKQkJCQlcCi0JCQlkb19lcnJvcigiY2Fubm90IGFsbG9jICVkIGxvY2tzXG4i LCBuKTsJXAotCQkJLyogTk8gUkVUVVJOICovCQkJCVwKLQl9Ci0jZGVmaW5lIFBS RVBBSVJfUldfTE9DS19JTklUKGwsYSkJaWYgKGRvX3BhcmFsbGVsKSBwdGhyZWFk X3J3bG9ja19pbml0KChsKSwoYSkpCi0jZGVmaW5lIFBSRVBBSVJfUldfUkVBRF9M T0NLKGwpIAlpZiAoZG9fcGFyYWxsZWwpIHB0aHJlYWRfcndsb2NrX3JkbG9jaygo bCkpCi0jZGVmaW5lIFBSRVBBSVJfUldfV1JJVEVfTE9DSyhsKQlpZiAoZG9fcGFy YWxsZWwpIHB0aHJlYWRfcndsb2NrX3dybG9jaygobCkpCi0jZGVmaW5lIFBSRVBB SVJfUldfVU5MT0NLKGwpCQlpZiAoZG9fcGFyYWxsZWwpIHB0aHJlYWRfcndsb2Nr X3VubG9jaygobCkpCi0jZGVmaW5lIFBSRVBBSVJfUldfV1JJVEVfTE9DS19OT1RF U1QobCkJcHRocmVhZF9yd2xvY2tfd3Jsb2NrKChsKSkKLSNkZWZpbmUgUFJFUEFJ Ul9SV19VTkxPQ0tfTk9URVNUKGwpCXB0aHJlYWRfcndsb2NrX3VubG9jaygobCkp Ci0jZGVmaW5lIFBSRVBBSVJfUldfTE9DS19ERUxFVEUobCkJaWYgKGRvX3BhcmFs bGVsKSBwdGhyZWFkX3J3bG9ja19kZXN0cm95KChsKSkKLQotI2RlZmluZSBQUkVQ QUlSX01UWF9MT0NLX0lOSVQobSwgYSkJaWYgKGRvX3BhcmFsbGVsKSBwdGhyZWFk X211dGV4X2luaXQoKG0pLCAoYSkpCi0jZGVmaW5lIFBSRVBBSVJfTVRYX0FUVFJf SU5JVChhKQlpZiAoZG9fcGFyYWxsZWwpIHB0aHJlYWRfbXV0ZXhhdHRyX2luaXQo KGEpKQotI2RlZmluZSBQUkVQQUlSX01UWF9BVFRSX1NFVChhLCBsKQlpZiAoZG9f cGFyYWxsZWwpIHB0aHJlYWRfbXV0ZXhhdHRyX3NldHR5cGUoKGEpLCBsKQotI2Rl ZmluZSBQUkVQQUlSX01UWF9MT0NLKG0pCQlpZiAoZG9fcGFyYWxsZWwpIHB0aHJl YWRfbXV0ZXhfbG9jayhtKQotI2RlZmluZSBQUkVQQUlSX01UWF9VTkxPQ0sobSkJ CWlmIChkb19wYXJhbGxlbCkgcHRocmVhZF9tdXRleF91bmxvY2sobSkKLQotCi10 eXBlZGVmIHZvaWQJZGlzcF9mdW5jX3QoeGZzX21vdW50X3QgKm1wLCB4ZnNfYWdu dW1iZXJfdCBhZ25vKTsKLWV4dGVybglpbnQJcXVldWVfd29yayhkaXNwX2Z1bmNf dCBmdW5jLCB4ZnNfbW91bnRfdCAqbXAsIHhmc19hZ251bWJlcl90IGFnbm8pOwot ZXh0ZXJuCXZvaWQJd2FpdF9mb3Jfd29ya2Vycyh2b2lkKTsKK3ZvaWQJdGhyZWFk X2luaXQodm9pZCk7CisKK3N0cnVjdCAgd29ya19xdWV1ZTsKKwordHlwZWRlZiB2 b2lkIHdvcmtfZnVuY190KHN0cnVjdCB3b3JrX3F1ZXVlICosIHhmc19hZ251bWJl cl90LCB2b2lkICopOworCit0eXBlZGVmIHN0cnVjdCB3b3JrX2l0ZW0geworCXN0 cnVjdCB3b3JrX2l0ZW0JKm5leHQ7CisJd29ya19mdW5jX3QJCSpmdW5jdGlvbjsK KwlzdHJ1Y3Qgd29ya19xdWV1ZQkqcXVldWU7CisJeGZzX2FnbnVtYmVyX3QJCWFn bm87CisJdm9pZAkJCSphcmc7Cit9IHdvcmtfaXRlbV90OworCit0eXBlZGVmIHN0 cnVjdCAgd29ya19xdWV1ZSB7CisJd29ya19pdGVtX3QJCSpuZXh0X2l0ZW07CisJ d29ya19pdGVtX3QJCSpsYXN0X2l0ZW07CisJaW50CQkJaXRlbV9jb3VudDsKKwlp bnQJCQl0aHJlYWRfY291bnQ7CisJcHRocmVhZF90CQkqdGhyZWFkczsKKwl4ZnNf bW91bnRfdAkJKm1wOworCXB0aHJlYWRfbXV0ZXhfdAkJbG9jazsKKwlwdGhyZWFk X2NvbmRfdAkJd2FrZXVwOworCWludAkJCXRlcm1pbmF0ZTsKK30gd29ya19xdWV1 ZV90OworCit2b2lkCitjcmVhdGVfd29ya19xdWV1ZSgKKwl3b3JrX3F1ZXVlX3QJ CSp3cSwKKwl4ZnNfbW91bnRfdAkJKm1wLAorCWludAkJCW53b3JrZXJzKTsKKwor dm9pZAorcXVldWVfd29yaygKKwl3b3JrX3F1ZXVlX3QJCSp3cSwKKwl3b3JrX2Z1 bmNfdCAJCWZ1bmMsCisJeGZzX2FnbnVtYmVyX3QgCQlhZ25vLAorCXZvaWQJCQkq YXJnKTsKKwordm9pZAorZGVzdHJveV93b3JrX3F1ZXVlKAorCXdvcmtfcXVldWVf dAkJKndxKTsKIAogI2VuZGlmCS8qIF9YRlNfUkVQQUlSX1RIUkVBRFNfSF8gKi8K SW5kZXg6IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIveGZzX3JlcGFpci5jCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dzL3JlcGFpci94 ZnNfcmVwYWlyLmMJMjAwNy0wNC0yNyAxNDoxMTo0MS4wMDAwMDAwMDAgKzEwMDAK KysrIHJlcGFpci94ZnNwcm9ncy9yZXBhaXIveGZzX3JlcGFpci5jCTIwMDctMDUt MzEgMTE6MjM6MjUuMjQ0NjI3MDUwICsxMDAwCkBAIC01OSwxNyArNTksMTQgQEAK IAkiaWhhc2giLAogI2RlZmluZQlCSEFTSF9TSVpFCTMKIAkiYmhhc2giLAotI2Rl ZmluZQlQUkVGRVRDSF9JTk9fQ05UCTQKLQkicGZpbm8iLAotI2RlZmluZQlQUkVG RVRDSF9ESVJfQ05UCTUKLQkicGZkaXIiLAotI2RlZmluZQlQUkVGRVRDSF9BSU9f Q05UCTYKLQkicGZhaW8iLAotI2RlZmluZQlBR19TVFJJREUJCTcKKyNkZWZpbmUJ QUdfU1RSSURFCTQKIAkiYWdfc3RyaWRlIiwKIAlOVUxMCiB9OwogCitzdGF0aWMg aW50CWloYXNoX29wdGlvbl91c2VkOworc3RhdGljIGludAliaGFzaF9vcHRpb25f dXNlZDsKKwogc3RhdGljIHZvaWQKIHVzYWdlKHZvaWQpCiB7CkBAIC0xODcsOCAr MTg0LDcgQEAKIAlwcmVfNjVfYmV0YSA9IDA7CiAJZnNfc2hhcmVkX2FsbG93ZWQg PSAxOwogCWFnX3N0cmlkZSA9IDA7Ci0JdGhyZWFkX2NvdW50ID0gMDsKLQlkb19w YXJhbGxlbCA9IDA7CisJdGhyZWFkX2NvdW50ID0gMTsKIAlyZXBvcnRfaW50ZXJ2 YWwgPSBQUk9HX1JQVF9ERUZBVUxUOwogCiAJLyoKQEAgLTIyMywxOCArMjE5LDEx IEBACiAJCQkJCWJyZWFrOwogCQkJCWNhc2UgSUhBU0hfU0laRToKIAkJCQkJbGli eGZzX2loYXNoX3NpemUgPSAoaW50KSBzdHJ0b2wodmFsLCAwLCAwKTsKKwkJCQkJ aWhhc2hfb3B0aW9uX3VzZWQgPSAxOwogCQkJCQlicmVhazsKIAkJCQljYXNlIEJI QVNIX1NJWkU6CiAJCQkJCWxpYnhmc19iaGFzaF9zaXplID0gKGludCkgc3RydG9s KHZhbCwgMCwgMCk7Ci0JCQkJCWJyZWFrOwotCQkJCWNhc2UgUFJFRkVUQ0hfSU5P X0NOVDoKLQkJCQkJbGlieGZzX2xpb19pbm9fY291bnQgPSAoaW50KSBzdHJ0b2wo dmFsLCAwLCAwKTsKLQkJCQkJYnJlYWs7Ci0JCQkJY2FzZSBQUkVGRVRDSF9ESVJf Q05UOgotCQkJCQlsaWJ4ZnNfbGlvX2Rpcl9jb3VudCA9IChpbnQpIHN0cnRvbCh2 YWwsIDAsIDApOwotCQkJCQlicmVhazsKLQkJCQljYXNlIFBSRUZFVENIX0FJT19D TlQ6Ci0JCQkJCWxpYnhmc19saW9fYWlvX2NvdW50ID0gKGludCkgc3RydG9sKHZh bCwgMCwgMCk7CisJCQkJCWJoYXNoX29wdGlvbl91c2VkID0gMTsKIAkJCQkJYnJl YWs7CiAJCQkJY2FzZSBBR19TVFJJREU6CiAJCQkJCWFnX3N0cmlkZSA9IChpbnQp IHN0cnRvbCh2YWwsIDAsIDApOwpAQCAtMjcyLDEwICsyNjEsNyBAQAogCQkJcHJp bnRmKF8oIiVzIHZlcnNpb24gJXNcbiIpLCBwcm9nbmFtZSwgVkVSU0lPTik7CiAJ CQlleGl0KDApOwogCQljYXNlICdQJzoKLQkJCWRvX3ByZWZldGNoIF49IDE7Ci0J CQlicmVhazsKLQkJY2FzZSAnTSc6Ci0JCQlkb19wYXJhbGxlbCBePSAxOworCQkJ ZG9fcHJlZmV0Y2ggPSAwOwogCQkJYnJlYWs7CiAJCWNhc2UgJ3QnOgogCQkJcmVw b3J0X2ludGVydmFsID0gKGludCkgc3RydG9sKG9wdGFyZywgMCwgMCk7CkBAIC00 ODMsMTIgKzQ2OSwxOSBAQAogCWJpbmR0ZXh0ZG9tYWluKFBBQ0tBR0UsIExPQ0FM RURJUik7CiAJdGV4dGRvbWFpbihQQUNLQUdFKTsKIAorI2lmZGVmIFhSX1BGX1RS QUNFCisJcGZfdHJhY2VfZmlsZSA9IGZvcGVuKCIvdG1wL3hmc19yZXBhaXJfcHJl ZmV0Y2gudHJhY2UiLCAidyIpOworCXNldHZidWYocGZfdHJhY2VfZmlsZSwgTlVM TCwgX0lPTEJGLCAxMDI0KTsKKyNlbmRpZgorCiAJdGVtcF9tcCA9ICZ4ZnNfbTsK IAlzZXRidWYoc3Rkb3V0LCBOVUxMKTsKIAogCXByb2Nlc3NfYXJncyhhcmdjLCBh cmd2KTsKIAl4ZnNfaW5pdCgmeCk7CiAKKwltc2didWYgPSBtYWxsb2MoRFVSQVRJ T05fQlVGX1NJWkUpOworCiAJdGltZXN0YW1wKFBIQVNFX1NUQVJULCAwLCBOVUxM KTsKIAl0aW1lc3RhbXAoUEhBU0VfRU5ELCAwLCBOVUxMKTsKIApAQCAtNTI5LDIy ICs1MjIsNzcgQEAKIAlpbm9kZXNfcGVyX2NsdXN0ZXIgPSBYRlNfSU5PREVfQ0xV U1RFUl9TSVpFKG1wKSA+PiBtcC0+bV9zYi5zYl9pbm9kZWxvZzsKIAogCWlmIChh Z19zdHJpZGUpIHsKLQkJZG9fcGFyYWxsZWwgPSAxOwotCQl0aHJlYWRfY291bnQg PSAobXAtPm1fc2Iuc2JfYWdjb3VudCArIGFnX3N0cmlkZSAtIDEpIC8gYWdfc3Ry aWRlOworCQl0aHJlYWRfY291bnQgPSAoZ2xvYl9hZ2NvdW50ICsgYWdfc3RyaWRl IC0gMSkgLyBhZ19zdHJpZGU7CiAJCXRocmVhZF9pbml0KCk7CiAJfQogCi0JaWYg KGRvX3BhcmFsbGVsICYmIHJlcG9ydF9pbnRlcnZhbCkgeworCWlmIChhZ19zdHJp ZGUgJiYgcmVwb3J0X2ludGVydmFsKSB7CiAJCWluaXRfcHJvZ3Jlc3NfcnB0KCk7 Ci0JCW1zZ2J1ZiA9IG1hbGxvYyhEVVJBVElPTl9CVUZfU0laRSk7CiAJCWlmICht c2didWYpIHsKIAkJCWRvX2xvZyhfKCIgICAgICAgIC0gcmVwb3J0aW5nIHByb2dy ZXNzIGluIGludGVydmFscyBvZiAlc1xuIiksCiAJCQlkdXJhdGlvbihyZXBvcnRf aW50ZXJ2YWwsIG1zZ2J1ZikpOwotCQkJZnJlZShtc2didWYpOwogCQl9CiAJfQog CiAJLyoKKwkgKiBBZGp1c3QgbGlieGZzIGNhY2hlIHNpemVzIGJhc2VkIG9uIHN5 c3RlbSBtZW1vcnksCisJICogZmlsZXN5c3RlbSBzaXplIGFuZCBpbm9kZSBjb3Vu dC4KKwkgKgorCSAqIFdlJ2xsIHNldCB0aGUgY2FjaGUgc2l6ZSBiYXNlZCBvbiAz LzRzIHRoZSBtZW1vcnkgbWludXMKKwkgKiBzcGFjZSB1c2VkIGJ5IHRoZSBpbm9k ZSBBVkwgdHJlZSBhbmQgYmxvY2sgdXNhZ2UgbWFwLgorCSAqCisJICogSW5vZGUg QVZMIHRyZWUgc3BhY2UgaXMgYXBwcm94aW1hdGVseSA0IGJ5dGVzIHBlciBpbm9k ZSwKKwkgKiBibG9jayB1c2FnZSBtYXAgaXMgY3VycmVudGx5IDEgYnl0ZSBmb3Ig MiBibG9ja3MuCisJICoKKwkgKiBXZSBhc3N1bWUgbW9zdCBibG9ja3Mgd2lsbCBi ZSBpbm9kZSBjbHVzdGVycy4KKwkgKgorCSAqIENhbGN1bGF0aW9ucyBhcmUgZG9u ZSBpbiBraWxvYnl0ZSB1bml0cy4KKwkgKi8KKworCWlmICghYmhhc2hfb3B0aW9u X3VzZWQpIHsKKwkJdW5zaWduZWQgbG9uZyAJbWVtX3VzZWQ7CisJCXVuc2lnbmVk IGxvbmcJcGh5c19tZW07CisKKwkJbGlieGZzX2ljYWNoZV9wdXJnZSgpOworCQls aWJ4ZnNfYmNhY2hlX3B1cmdlKCk7CisJCWNhY2hlX2Rlc3Ryb3kobGlieGZzX2lj YWNoZSk7CisJCWNhY2hlX2Rlc3Ryb3kobGlieGZzX2JjYWNoZSk7CisKKwkJbWVt X3VzZWQgPSAobXAtPm1fc2Iuc2JfaWNvdW50ID4+ICgxMCAtIDIpKSArCisJCQkJ CShtcC0+bV9zYi5zYl9kYmxvY2tzID4+ICgxMCArIDEpKTsKKwkJcGh5c19tZW0g PSBsaWJ4ZnNfcGh5c21lbSgpICogMyAvIDQ7CisKKwkJaWYgKHBoeXNfbWVtIDw9 IG1lbV91c2VkKSB7CisJCQkvKgorCQkJICogVHVybiBvZmYgcHJlZmV0Y2ggYW5k IG1pbmltaXNlIGxpYnhmcyBjYWNoZSBpZgorCQkJICogcGh5c2ljYWwgbWVtb3J5 IGlzIGRlZW1lZCBpbnN1ZmZpY2llbnQKKwkJCSAqLworCQkJZG9fcHJlZmV0Y2gg PSAwOworCQkJbGlieGZzX2JoYXNoX3NpemUgPSA2NDsKKwkJfSBlbHNlIHsKKwkJ CXBoeXNfbWVtIC09IG1lbV91c2VkOworCQkJaWYgKHBoeXNfbWVtID49ICgxIDw8 IDMwKSkKKwkJCQlwaHlzX21lbSA9IDEgPDwgMzA7CisJCQlsaWJ4ZnNfYmhhc2hf c2l6ZSA9IHBoeXNfbWVtIC8gKEhBU0hfQ0FDSEVfUkFUSU8gKgorCQkJCQkobXAt Pm1faW5vZGVfY2x1c3Rlcl9zaXplID4+IDEwKSk7CisJCQlpZiAobGlieGZzX2Jo YXNoX3NpemUgPCA1MTIpCisJCQkJbGlieGZzX2JoYXNoX3NpemUgPSA1MTI7CisJ CX0KKworCQlpZiAodmVyYm9zZSkKKwkJCWRvX2xvZyhfKCIgICAgICAgIC0gYmxv Y2sgY2FjaGUgc2l6ZSBzZXQgdG8gJWQgZW50cmllc1xuIiksCisJCQkJbGlieGZz X2JoYXNoX3NpemUgKiBIQVNIX0NBQ0hFX1JBVElPKTsKKworCQlpZiAoIWloYXNo X29wdGlvbl91c2VkKQorCQkJbGlieGZzX2loYXNoX3NpemUgPSBsaWJ4ZnNfYmhh c2hfc2l6ZTsKKworCQlsaWJ4ZnNfaWNhY2hlID0gY2FjaGVfaW5pdChsaWJ4ZnNf aWhhc2hfc2l6ZSwKKwkJCQkJCSZsaWJ4ZnNfaWNhY2hlX29wZXJhdGlvbnMpOwor CQlsaWJ4ZnNfYmNhY2hlID0gY2FjaGVfaW5pdChsaWJ4ZnNfYmhhc2hfc2l6ZSwK KwkJCQkJCSZsaWJ4ZnNfYmNhY2hlX29wZXJhdGlvbnMpOworCX0KKworCS8qCiAJ ICogY2FsY3VsYXRlIHdoYXQgbWtmcyB3b3VsZCBkbyB0byB0aGlzIGZpbGVzeXN0 ZW0KIAkgKi8KIAljYWxjX21rZnMobXApOwpAQCAtNTY0LDE2ICs2MTIsMTUgQEAK IAlwaGFzZTIobXApOwogCXRpbWVzdGFtcChQSEFTRV9FTkQsIDIsIE5VTEwpOwog CisJaWYgKGRvX3ByZWZldGNoKQorCQlpbml0X3ByZWZldGNoKG1wKTsKKwogCXBo YXNlMyhtcCk7CiAJdGltZXN0YW1wKFBIQVNFX0VORCwgMywgTlVMTCk7CiAKIAlw aGFzZTQobXApOwogCXRpbWVzdGFtcChQSEFTRV9FTkQsIDQsIE5VTEwpOwogCi0J LyogWFhYOiBuYXRoYW5zIC0gc29tZXRoaW5nIGluIHBoYXNlNCBhaW4ndCBwbGF5 aW5nIGJ5ICovCi0JLyogdGhlIGJ1ZmZlciBjYWNoZSBydWxlcy4uIHdoeSBkb2Vz bid0IElSSVggaGl0IHRoaXM/ICovCi0JbGlieGZzX2JjYWNoZV9mbHVzaCgpOwot CiAJaWYgKG5vX21vZGlmeSkKIAkJcHJpbnRmKF8oIk5vIG1vZGlmeSBmbGFnIHNl dCwgc2tpcHBpbmcgcGhhc2UgNVxuIikpOwogCWVsc2UgewpAQCAtNTg1LDggKzYz Miw2IEBACiAJCXBoYXNlNihtcCk7CiAJCXRpbWVzdGFtcChQSEFTRV9FTkQsIDYs IE5VTEwpOwogCi0JCWxpYnhmc19iY2FjaGVfZmx1c2goKTsKLQogCQlwaGFzZTco bXApOwogCQl0aW1lc3RhbXAoUEhBU0VfRU5ELCA3LCBOVUxMKTsKIAl9IGVsc2Ug IHsKQEAgLTY0OCw3ICs2OTMsNyBAQAogCQl9CiAJfQogCi0JaWYgKGRvX3BhcmFs bGVsICYmIHJlcG9ydF9pbnRlcnZhbCkKKwlpZiAoYWdfc3RyaWRlICYmIHJlcG9y dF9pbnRlcnZhbCkKIAkJc3RvcF9wcm9ncmVzc19ycHQoKTsKIAogI2lmZGVmIFRS QUNLX01FTU9SWQpAQCAtNjY3LDEyICs3MTIsNiBAQAogCX0KIAogCS8qCi0JICog RG9uZSwgZmx1c2ggYWxsIGNhY2hlZCBidWZmZXJzIGFuZCBpbm9kZXMuCi0JICov Ci0JbGlieGZzX2ljYWNoZV9wdXJnZSgpOwotCWxpYnhmc19iY2FjaGVfcHVyZ2Uo KTsKLQotCS8qCiAJICogQ2xlYXIgdGhlIHF1b3RhIGZsYWdzIGlmIHRoZXkncmUg b24uCiAJICovCiAJc2JwID0gbGlieGZzX2dldHNiKG1wLCAwKTsKQEAgLTY5OCw2 ICs3MzcsMTEgQEAKIAogCWxpYnhmc193cml0ZWJ1ZihzYnAsIDApOwogCisJLyoK KwkgKiBEb25lLCBmbHVzaCBhbGwgY2FjaGVkIGJ1ZmZlcnMgYW5kIGlub2Rlcy4K KwkgKi8KKwlsaWJ4ZnNfYmNhY2hlX2ZsdXNoKCk7CisKIAlsaWJ4ZnNfdW1vdW50 KG1wKTsKIAlpZiAoeC5ydGRldikKIAkJbGlieGZzX2RldmljZV9jbG9zZSh4LnJ0 ZGV2KTsKQEAgLTcwOCw1ICs3NTIsOCBAQAogCWlmICh2ZXJib3NlKQogCQlzdW1t YXJ5X3JlcG9ydCgpOwogCWRvX2xvZyhfKCJkb25lXG4iKSk7CisjaWZkZWYgWFJf UEZfVFJBQ0UKKwlmY2xvc2UocGZfdHJhY2VfZmlsZSk7CisjZW5kaWYKIAlyZXR1 cm4gKDApOwogfQpJbmRleDogcmVwYWlyL3hmc3Byb2dzL3JlcGFpci9kaW5vZGUu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIub3JpZy94ZnNwcm9ncy9y ZXBhaXIvZGlub2RlLmMJMjAwNy0wNC0yNyAxNDoxMTo0MS4wMDAwMDAwMDAgKzEw MDAKKysrIHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvZGlub2RlLmMJMjAwNy0wNS0x NiAxMjowMjozOS42MTI2NTQ1MzAgKzEwMDAKQEAgLTUxNCwyOCArNTE0LDYgQEAK IAlyZXR1cm4oTlVMTERGU0JOTyk7CiB9CiAKLS8qCi0gKiBwcm9jZXNzX2JtYnRf cmVjbGlzdF9pbnQgaXMgdGhlIG1vc3QgY29tcHV0ZSBpbnRlbnNpdmUKLSAqIGZ1 bmN0aW9uIGluIHJlcGFpci4gVGhlIGZvbGxvd2luZyBtYWNyb3MgcmVkdWNlIHRo ZQotICogdGhlIGxhcmdlIG51bWJlciBvZiBsb2NrL3VubG9jayBzdGVwcyBpdCB3 b3VsZCBvdGhlcndpc2UKLSAqIGNhbGwuCi0gKi8KLSNkZWZpbmUJUFJPQ0VTU19C TUJUX0RFQ0wodHlwZSwgdmFyKQl0eXBlIHZhcgotCi0jZGVmaW5lCVBST0NFU1Nf Qk1CVF9MT0NLKGFnbm8pCQkJCQkJCVwKLQlpZiAoZG9fcGFyYWxsZWwgJiYgKGFn bm8gIT0gbG9ja2VkX2Fnbm8pKSB7CQkJCVwKLQkJaWYgKGxvY2tlZF9hZ25vICE9 IC0xKQkvKiByZWxlYXNlIG9sZCBhZyBsb2NrICovCQlcCi0JCQlQUkVQQUlSX1JX X1VOTE9DS19OT1RFU1QoJnBlcl9hZ19sb2NrW2xvY2tlZF9hZ25vXSk7CVwKLQkJ UFJFUEFJUl9SV19XUklURV9MT0NLX05PVEVTVCgmcGVyX2FnX2xvY2tbYWdub10p OwkJXAotCQlsb2NrZWRfYWdubyA9IGFnbm87CQkJCQkJXAotCX0KLQotI2RlZmlu ZQlQUk9DRVNTX0JNQlRfVU5MT0NLX1JFVFVSTih2YWwpCQkJCQkJXAotCWRvIHsJ CQkJCQkJCQlcCi0JCWlmIChsb2NrZWRfYWdubyAhPSAtMSkgCQkJCQkJXAotCQkJ UFJFUEFJUl9SV19VTkxPQ0tfTk9URVNUKCZwZXJfYWdfbG9ja1tsb2NrZWRfYWdu b10pOwlcCi0JCXJldHVybiAodmFsKTsJCQkJCQkJXAotCX0gd2hpbGUgKDApCiAK IHN0YXRpYyBpbnQKIHByb2Nlc3NfcnRfcmVjKApAQCAtNjg5LDggKzY2Nyw4IEBA CiAJeGZzX2Rmc2Jub190CQllOwogCXhmc19hZ251bWJlcl90CQlhZ25vOwogCXhm c19hZ2Jsb2NrX3QJCWFnYm5vOwotCVBST0NFU1NfQk1CVF9ERUNMCi0JCQkJKHhm c19hZ251bWJlcl90LCBsb2NrZWRfYWdubz0tMSk7CisJeGZzX2FnbnVtYmVyX3QJ CWxvY2tlZF9hZ25vID0gLTE7CisJaW50CQkJZXJyb3IgPSAxOwogCiAJaWYgKHdo aWNoZm9yayA9PSBYRlNfREFUQV9GT1JLKQogCQlmb3JrbmFtZSA9IF8oImRhdGEi KTsKQEAgLTcwOSwxMSArNjg3LDEwIEBACiAJCWVsc2UKIAkJCSpsYXN0X2tleSA9 IG87CiAJCWlmIChpID4gMCAmJiBvcCArIGNwID4gbykgIHsKLQkJCWRvX3dhcm4o Ci0JXygiYm1hcCByZWMgb3V0IG9mIG9yZGVyLCBpbm9kZSAlbGx1IGVudHJ5ICVk ICIKLQkgICJbbyBzIGNdIFslbGx1ICVsbHUgJWxsdV0sICVkIFslbGx1ICVsbHUg JWxsdV1cbiIpLAorCQkJZG9fd2FybihfKCJibWFwIHJlYyBvdXQgb2Ygb3JkZXIs IGlub2RlICVsbHUgZW50cnkgJWQgIgorCSAgCQkJIltvIHMgY10gWyVsbHUgJWxs dSAlbGx1XSwgJWQgWyVsbHUgJWxsdSAlbGx1XVxuIiksCiAJCQkJaW5vLCBpLCBv LCBzLCBjLCBpLTEsIG9wLCBzcCwgY3ApOwotCQkJUFJPQ0VTU19CTUJUX1VOTE9D S19SRVRVUk4oMSk7CisJCQlnb3RvIGRvbmU7CiAJCX0KIAkJb3AgPSBvOwogCQlj cCA9IGM7CkBAIC03MjMsMTAgKzcwMCw5IEBACiAJCSAqIGNoZWNrIG51bWVyaWMg dmFsaWRpdHkgb2YgdGhlIGV4dGVudAogCQkgKi8KIAkJaWYgKGMgPT0gMCkgIHsK LQkJCWRvX3dhcm4oCi0JXygiemVybyBsZW5ndGggZXh0ZW50IChvZmYgPSAlbGx1 LCBmc2JubyA9ICVsbHUpIGluIGlubyAlbGx1XG4iKSwKLQkJCQlvLCBzLCBpbm8p OwotCQkJUFJPQ0VTU19CTUJUX1VOTE9DS19SRVRVUk4oMSk7CisJCQlkb193YXJu KF8oInplcm8gbGVuZ3RoIGV4dGVudCAob2ZmID0gJWxsdSwgIgorCQkJCSJmc2Ju byA9ICVsbHUpIGluIGlubyAlbGx1XG4iKSwgbywgcywgaW5vKTsKKwkJCWdvdG8g ZG9uZTsKIAkJfQogCiAJCWlmICh0eXBlID09IFhSX0lOT19SVERBVEEgJiYgd2hp Y2hmb3JrID09IFhGU19EQVRBX0ZPUkspIHsKQEAgLTc0MywzOSArNzE5LDM4IEBA CiAJCQljb250aW51ZTsKIAkJfQogCisJCS8qCisJCSAqIHJlZ3VsYXIgZmlsZSBk YXRhIGZvcmsgb3IgYXR0cmlidXRlIGZvcmsKKwkJICovCiAJCXN3aXRjaCAodmVy aWZ5X2Rmc2Jub19yYW5nZShtcCwgcywgYykpIHsKIAkJCWNhc2UgWFJfREZTQk5P UkFOR0VfVkFMSUQ6CiAJCQkJYnJlYWs7CisKIAkJCWNhc2UgWFJfREZTQk5PUkFO R0VfQkFEU1RBUlQ6Ci0JCQkJZG9fd2FybigKLQlfKCJpbm9kZSAlbGx1IC0gYmFk IGV4dGVudCBzdGFydGluZyBibG9jayBudW1iZXIgJWxsdSwgb2Zmc2V0ICVsbHVc biIpLAorCQkJCWRvX3dhcm4oXygiaW5vZGUgJWxsdSAtIGJhZCBleHRlbnQgc3Rh cnRpbmcgIgorCQkJCQkiYmxvY2sgbnVtYmVyICVsbHUsIG9mZnNldCAlbGx1XG4i KSwKIAkJCQkJaW5vLCBzLCBvKTsKLQkJCQlQUk9DRVNTX0JNQlRfVU5MT0NLX1JF VFVSTigxKTsKKwkJCQlnb3RvIGRvbmU7CisKIAkJCWNhc2UgWFJfREZTQk5PUkFO R0VfQkFERU5EOgotCQkJCWRvX3dhcm4oCi0JXygiaW5vZGUgJWxsdSAtIGJhZCBl eHRlbnQgbGFzdCBibG9jayBudW1iZXIgJWxsdSwgb2Zmc2V0ICVsbHVcbiIpLAor CQkJCWRvX3dhcm4oXygiaW5vZGUgJWxsdSAtIGJhZCBleHRlbnQgbGFzdCBibG9j ayAiCisJCQkJCSJudW1iZXIgJWxsdSwgb2Zmc2V0ICVsbHVcbiIpLAogCQkJCQlp bm8sIHMgKyBjIC0gMSwgbyk7Ci0JCQkJUFJPQ0VTU19CTUJUX1VOTE9DS19SRVRV Uk4oMSk7Ci0JCQljYXNlIFhSX0RGU0JOT1JBTkdFX09WRVJGTE9XOgotCQkJCWRv X3dhcm4oCisJCQkJZ290byBkb25lOwogCi0JXygiaW5vZGUgJWxsdSAtIGJhZCBl eHRlbnQgb3ZlcmZsb3dzIC0gc3RhcnQgJWxsdSwgZW5kICVsbHUsICIKLQkgICJv ZmZzZXQgJWxsdVxuIiksCisJCQljYXNlIFhSX0RGU0JOT1JBTkdFX09WRVJGTE9X OgorCQkJCWRvX3dhcm4oXygiaW5vZGUgJWxsdSAtIGJhZCBleHRlbnQgb3ZlcmZs b3dzIC0gIgorCQkJCQkic3RhcnQgJWxsdSwgZW5kICVsbHUsIG9mZnNldCAlbGx1 XG4iKSwKIAkJCQkJaW5vLCBzLCBzICsgYyAtIDEsIG8pOwotCQkJCVBST0NFU1Nf Qk1CVF9VTkxPQ0tfUkVUVVJOKDEpOworCQkJCWdvdG8gZG9uZTsKIAkJfQogCQlp ZiAobyA+PSBmc19tYXhfZmlsZV9vZmZzZXQpICB7Ci0JCQlkb193YXJuKAotCV8o Imlub2RlICVsbHUgLSBleHRlbnQgb2Zmc2V0IHRvbyBsYXJnZSAtIHN0YXJ0ICVs bHUsIGNvdW50ICVsbHUsICIKLQkgICJvZmZzZXQgJWxsdVxuIiksCisJCQlkb193 YXJuKF8oImlub2RlICVsbHUgLSBleHRlbnQgb2Zmc2V0IHRvbyBsYXJnZSAtICIK KwkJCQkic3RhcnQgJWxsdSwgY291bnQgJWxsdSwgb2Zmc2V0ICVsbHVcbiIpLAog CQkJCWlubywgcywgYywgbyk7Ci0JCQlQUk9DRVNTX0JNQlRfVU5MT0NLX1JFVFVS TigxKTsKKwkJCWdvdG8gZG9uZTsKIAkJfQogCi0KLQkJLyoKLQkJICogcmVndWxh ciBmaWxlIGRhdGEgZm9yayBvciBhdHRyaWJ1dGUgZm9yawotCQkgKi8KIAkJaWYg KGJsa21hcHAgJiYgKmJsa21hcHApCiAJCQlibGttYXBfc2V0X2V4dChibGttYXBw LCBvLCBzLCBjKTsKIAkJLyoKQEAgLTc4NSwyNiArNzYwLDM2IEBACiAJCWFnbm8g PSBYRlNfRlNCX1RPX0FHTk8obXAsIHMpOwogCQlhZ2JubyA9IFhGU19GU0JfVE9f QUdCTk8obXAsIHMpOwogCQllID0gcyArIGM7Ci0JCVBST0NFU1NfQk1CVF9MT0NL KGFnbm8pOwotCQlmb3IgKGIgPSBzOyBiIDwgZTsgYisrLCBhZ2JubysrKSAgewot CQkJaWYgKGNoZWNrX2R1cHMgPT0gMSkgIHsKLQkJCQkvKgotCQkJCSAqIGlmIHdl J3JlIGp1c3QgY2hlY2tpbmcgdGhlIGJtYXAgZm9yIGR1cHMsCi0JCQkJICogcmV0 dXJuIGlmIHdlIGZpbmQgb25lLCBvdGhlcndpc2UsIGNvbnRpbnVlCi0JCQkJICog Y2hlY2tpbmcgZWFjaCBlbnRyeSB3aXRob3V0IHNldHRpbmcgdGhlCi0JCQkJICog YmxvY2sgYml0bWFwCi0JCQkJICovCisJCWlmIChhZ25vICE9IGxvY2tlZF9hZ25v KSB7CisJCQlpZiAobG9ja2VkX2Fnbm8gIT0gLTEpCisJCQkJcHRocmVhZF9tdXRl eF91bmxvY2soJmFnX2xvY2tzW2xvY2tlZF9hZ25vXSk7CisJCQlwdGhyZWFkX211 dGV4X2xvY2soJmFnX2xvY2tzW2Fnbm9dKTsKKwkJCWxvY2tlZF9hZ25vID0gYWdu bzsKKwkJfQorCisJCWlmIChjaGVja19kdXBzKSB7CisJCQkvKgorCQkJICogaWYg d2UncmUganVzdCBjaGVja2luZyB0aGUgYm1hcCBmb3IgZHVwcywKKwkJCSAqIHJl dHVybiBpZiB3ZSBmaW5kIG9uZSwgb3RoZXJ3aXNlLCBjb250aW51ZQorCQkJICog Y2hlY2tpbmcgZWFjaCBlbnRyeSB3aXRob3V0IHNldHRpbmcgdGhlCisJCQkgKiBi bG9jayBiaXRtYXAKKwkJCSAqLworCQkJZm9yIChiID0gczsgYiA8IGU7IGIrKywg YWdibm8rKykgIHsKIAkJCQlpZiAoc2VhcmNoX2R1cF9leHRlbnQobXAsIGFnbm8s IGFnYm5vKSkgewotCQkJCQlkb193YXJuKAotCV8oIiVzIGZvcmsgaW4gaW5vICVs bHUgY2xhaW1zIGR1cCBleHRlbnQsIG9mZiAtICVsbHUsICIKLQkgICJzdGFydCAt ICVsbHUsIGNudCAlbGx1XG4iKSwKKwkJCQkJZG9fd2FybihfKCIlcyBmb3JrIGlu IGlubyAlbGx1IGNsYWltcyAiCisJCQkJCQkiZHVwIGV4dGVudCwgb2ZmIC0gJWxs dSwgIgorCQkJCQkJInN0YXJ0IC0gJWxsdSwgY250ICVsbHVcbiIpLAogCQkJCQkJ Zm9ya25hbWUsIGlubywgbywgcywgYyk7Ci0JCQkJCVBST0NFU1NfQk1CVF9VTkxP Q0tfUkVUVVJOKDEpOworCQkJCQlnb3RvIGRvbmU7CiAJCQkJfQotCQkJCWNvbnRp bnVlOwogCQkJfQorCQkJKnRvdCArPSBjOworCQkJY29udGludWU7CisJCX0KIAot CQkJLyogUHJvY2VzcyBpbiBjaHVua3Mgb2YgMTYgKFhSX0JCX1VOSVQvWFJfQkIp CisJCWZvciAoYiA9IHM7IGIgPCBlOyBiKyssIGFnYm5vKyspICB7CisJCQkvKgor CQkJICogUHJvY2VzcyBpbiBjaHVua3Mgb2YgMTYgKFhSX0JCX1VOSVQvWFJfQkIp CiAJCQkgKiBmb3IgY29tbW9uIFhSX0VfVU5LTk9XTiB0byBYUl9FX0lOVVNFIHRy YW5zaXRpb24KIAkJCSAqLwogCQkJaWYgKCgoYWdibm8gJiBYUl9CQl9NQVNLKSA9 PSAwKSAmJiAoKHMgKyBjIC0gYikgPj0gKFhSX0JCX1VOSVQvWFJfQkIpKSkgewpA QCAtODE4LDQ1ICs4MDMsNDkgQEAKIAkJCX0KIAogCQkJc3RhdGUgPSBnZXRfYWdi bm9fc3RhdGUobXAsIGFnbm8sIGFnYm5vKTsKKwogCQkJc3dpdGNoIChzdGF0ZSkg IHsKIAkJCWNhc2UgWFJfRV9GUkVFOgogCQkJY2FzZSBYUl9FX0ZSRUUxOgotCQkJ CWRvX3dhcm4oCi0JCQlfKCIlcyBmb3JrIGluIGlubyAlbGx1IGNsYWltcyBmcmVl IGJsb2NrICVsbHVcbiIpLAorCQkJCWRvX3dhcm4oXygiJXMgZm9yayBpbiBpbm8g JWxsdSBjbGFpbXMgZnJlZSAiCisJCQkJCSJibG9jayAlbGx1XG4iKSwKIAkJCQkJ Zm9ya25hbWUsIGlubywgKF9fdWludDY0X3QpIGIpOwogCQkJCS8qIGZhbGwgdGhy b3VnaCAuLi4gKi8KIAkJCWNhc2UgWFJfRV9VTktOT1dOOgogCQkJCXNldF9hZ2Ju b19zdGF0ZShtcCwgYWdubywgYWdibm8sIFhSX0VfSU5VU0UpOwogCQkJCWJyZWFr OworCiAJCQljYXNlIFhSX0VfQkFEX1NUQVRFOgogCQkJCWRvX2Vycm9yKF8oImJh ZCBzdGF0ZSBpbiBibG9jayBtYXAgJWxsdVxuIiksIGIpOwotCQkJCWFib3J0KCk7 Ci0JCQkJYnJlYWs7CisKIAkJCWNhc2UgWFJfRV9GU19NQVA6CiAJCQljYXNlIFhS X0VfSU5POgogCQkJY2FzZSBYUl9FX0lOVVNFX0ZTOgotCQkJCWRvX3dhcm4oCi0J CQlfKCIlcyBmb3JrIGluIGlub2RlICVsbHUgY2xhaW1zIG1ldGFkYXRhIGJsb2Nr ICVsbHVcbiIpLAorCQkJCWRvX3dhcm4oXygiJXMgZm9yayBpbiBpbm9kZSAlbGx1 IGNsYWltcyAiCisJCQkJCSJtZXRhZGF0YSBibG9jayAlbGx1XG4iKSwKIAkJCQkJ Zm9ya25hbWUsIGlubywgKF9fdWludDY0X3QpIGIpOwotCQkJCVBST0NFU1NfQk1C VF9VTkxPQ0tfUkVUVVJOKDEpOworCQkJCWdvdG8gZG9uZTsKKwogCQkJY2FzZSBY Ul9FX0lOVVNFOgogCQkJY2FzZSBYUl9FX01VTFQ6CiAJCQkJc2V0X2FnYm5vX3N0 YXRlKG1wLCBhZ25vLCBhZ2JubywgWFJfRV9NVUxUKTsKLQkJCQlkb193YXJuKAot CQkJXygiJXMgZm9yayBpbiAlcyBpbm9kZSAlbGx1IGNsYWltcyB1c2VkIGJsb2Nr ICVsbHVcbiIpLAorCQkJCWRvX3dhcm4oXygiJXMgZm9yayBpbiAlcyBpbm9kZSAl bGx1IGNsYWltcyAiCisJCQkJCSJ1c2VkIGJsb2NrICVsbHVcbiIpLAogCQkJCQlm b3JrbmFtZSwgZnR5cGUsIGlubywgKF9fdWludDY0X3QpIGIpOwotCQkJCVBST0NF U1NfQk1CVF9VTkxPQ0tfUkVUVVJOKDEpOworCQkJCWdvdG8gZG9uZTsKKwogCQkJ ZGVmYXVsdDoKLQkJCQlkb19lcnJvcigKLQkJCV8oImlsbGVnYWwgc3RhdGUgJWQg aW4gYmxvY2sgbWFwICVsbHVcbiIpLAorCQkJCWRvX2Vycm9yKF8oImlsbGVnYWwg c3RhdGUgJWQgaW4gYmxvY2sgbWFwICVsbHVcbiIpLAogCQkJCQlzdGF0ZSwgYik7 Ci0JCQkJYWJvcnQoKTsKIAkJCX0KIAkJfQogCQkqdG90ICs9IGM7CiAJfQotCi0J UFJPQ0VTU19CTUJUX1VOTE9DS19SRVRVUk4oMCk7CisJZXJyb3IgPSAwOworZG9u ZToKKwlpZiAobG9ja2VkX2Fnbm8gIT0gLTEpCisJCXB0aHJlYWRfbXV0ZXhfdW5s b2NrKCZhZ19sb2Nrc1tsb2NrZWRfYWdub10pOworCXJldHVybiBlcnJvcjsKIH0K IAogLyoKSW5kZXg6IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvZGlub2RlLmgKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVwYWly L2Rpbm9kZS5oCTIwMDctMDQtMjcgMTM6MTM6MzUuMDAwMDAwMDAwICsxMDAwCisr KyByZXBhaXIveGZzcHJvZ3MvcmVwYWlyL2Rpbm9kZS5oCTIwMDctMDQtMjcgMTQ6 MTI6MzQuMzExNTQ3ODM4ICsxMDAwCkBAIC0xOCw2ICsxOCw4IEBACiAjaWZuZGVm IF9YUl9ESU5PREVfSAogI2RlZmluZSBfWFJfRElOT0RFX0gKIAorI2luY2x1ZGUg InByZWZldGNoLmgiCisKIHN0cnVjdCBibGttYXA7CiAKIGludApAQCAtMTE2LDYg KzExOCw3IEBACiAJCQkJeGZzX2FnbnVtYmVyX3QJYWdubyk7CiB2b2lkCiBwcm9j ZXNzX2FnaW5vZGVzKHhmc19tb3VudF90CSptcCwKKwkJcHJlZmV0Y2hfYXJnc190 CSpwZl9hcmdzLAogCQl4ZnNfYWdudW1iZXJfdAlhZ25vLAogCQlpbnQJCWNoZWNr X2RpcnMsCiAJCWludAkJY2hlY2tfZHVwcywKSW5kZXg6IHJlcGFpci94ZnNwcm9n cy9saWJ4ZnMvdHJhbnMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSByZXBhaXIu b3JpZy94ZnNwcm9ncy9saWJ4ZnMvdHJhbnMuYwkyMDA3LTA0LTI3IDEzOjEzOjM1 LjAwMDAwMDAwMCArMTAwMAorKysgcmVwYWlyL3hmc3Byb2dzL2xpYnhmcy90cmFu cy5jCTIwMDctMDQtMjcgMTQ6MTI6MzQuMzExNTQ3ODM4ICsxMDAwCkBAIC02NDQs MTggKzY0NCwxNyBAQAogCVhGU19CVUZfU0VUX0ZTUFJJVkFURTIoYnAsIE5VTEwp OwkvKiByZW1vdmUgeGFjdCBwdHIgKi8KIAogCWhvbGQgPSAoYmlwLT5ibGlfZmxh Z3MgJiBYRlNfQkxJX0hPTEQpOwotCWlmIChiaXAtPmJsaV9mbGFncyAmIChYRlNf QkxJX0RJUlRZfFhGU19CTElfU1RBTEUpKSB7CisJaWYgKGJpcC0+YmxpX2ZsYWdz ICYgWEZTX0JMSV9ESVJUWSkgewogI2lmZGVmIFhBQ1RfREVCVUcKIAkJZnByaW50 ZihzdGRlcnIsICJmbHVzaGluZy9zdGFsaW5nIGJ1ZmZlciAlcCAoaG9sZD0lZClc biIsCiAJCQlicCwgaG9sZCk7CiAjZW5kaWYKLQkJaWYgKGJpcC0+YmxpX2ZsYWdz ICYgWEZTX0JMSV9ESVJUWSkKLQkJCWxpYnhmc193cml0ZWJ1Zl9pbnQoYnAsIDAp OwotCQlpZiAoaG9sZCkKLQkJCWJpcC0+YmxpX2ZsYWdzICY9IH5YRlNfQkxJX0hP TEQ7Ci0JCWVsc2UKLQkJCWxpYnhmc19wdXRidWYoYnApOworCQlsaWJ4ZnNfd3Jp dGVidWZfaW50KGJwLCAwKTsKIAl9CisJaWYgKGhvbGQpCisJCWJpcC0+YmxpX2Zs YWdzICY9IH5YRlNfQkxJX0hPTEQ7CisJZWxzZQorCQlsaWJ4ZnNfcHV0YnVmKGJw KTsKIAkvKiByZWxlYXNlIHRoZSBidWYgaXRlbSAqLwogCWttZW1fem9uZV9mcmVl KHhmc19idWZfaXRlbV96b25lLCBiaXApOwogfQpJbmRleDogcmVwYWlyL3hmc3By b2dzL2xpYnhmcy9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSByZXBh aXIub3JpZy94ZnNwcm9ncy9saWJ4ZnMvTWFrZWZpbGUJMjAwNy0wNC0xMiAxNDo1 NTo1My4wMDAwMDAwMDAgKzEwMDAKKysrIHJlcGFpci94ZnNwcm9ncy9saWJ4ZnMv TWFrZWZpbGUJMjAwNy0wNS0yOSAxMDo1NzozOC44NzA1MTk5ODggKzEwMDAKQEAg LTExLDcgKzExLDcgQEAKIExUX0FHRSA9IDAKIAogSEZJTEVTID0geGZzLmggaW5p dC5oCi1DRklMRVMgPSBiaXQuYyBjYWNoZS5jIGluaXQuYyBsaW8uYyBsb2dpdGVt LmMgcmR3ci5jIHRyYW5zLmMgdXRpbC5jIFwKK0NGSUxFUyA9IGJpdC5jIGNhY2hl LmMgaW5pdC5jIGxvZ2l0ZW0uYyByZHdyLmMgdHJhbnMuYyB1dGlsLmMgXAogCXhm c19hbGxvYy5jIHhmc19pYWxsb2MuYyB4ZnNfcnRhbGxvYy5jIFwKIAl4ZnNfaW5v ZGUuYyB4ZnNfYnRyZWUuYyB4ZnNfYWxsb2NfYnRyZWUuYyB4ZnNfaWFsbG9jX2J0 cmVlLmMgXAogCXhmc19ibWFwX2J0cmVlLmMgeGZzX2RhX2J0cmVlLmMgeGZzX2Rp ci5jIHhmc19kaXJfbGVhZi5jIFwKSW5kZXg6IHJlcGFpci94ZnNwcm9ncy9pbmNs dWRlL2xpbnV4LmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gcmVwYWlyLm9yaWcv eGZzcHJvZ3MvaW5jbHVkZS9saW51eC5oCTIwMDctMDQtMTIgMTQ6NTU6NTIuMDAw MDAwMDAwICsxMDAwCisrKyByZXBhaXIveGZzcHJvZ3MvaW5jbHVkZS9saW51eC5o CTIwMDctMDUtMjkgMTE6MDY6MDEuMDI5NTI5Njk2ICsxMDAwCkBAIC0xMTksOSAr MTE5LDQgQEAKICNkZWZpbmUgX0JPT0xFQU5fVF9ERUZJTkVECTEKICNlbmRpZgog Ci0jaWZkZWYgX19VU0VfR05VCi10eXBlZGVmIHN0cnVjdCBhaW9jYjY0IGFpb2Ni NjRfdDsKLSNkZWZpbmUJX0FJT0NCNjRfVF9ERUZJTkVECTEKLSNlbmRpZgotCiAj ZW5kaWYJLyogX19YRlNfTElOVVhfSF9fICovCkluZGV4OiByZXBhaXIveGZzcHJv Z3MvbGlieGZzL2Rhcndpbi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHJlcGFp ci5vcmlnL3hmc3Byb2dzL2xpYnhmcy9kYXJ3aW4uYwkyMDA3LTA0LTEyIDE0OjU1 OjUzLjAwMDAwMDAwMCArMTAwMAorKysgcmVwYWlyL3hmc3Byb2dzL2xpYnhmcy9k YXJ3aW4uYwkyMDA3LTA1LTMwIDEzOjQ4OjI1Ljk4OTY2NDE1NCArMTAwMApAQCAt MjEsNiArMjEsNyBAQAogI2luY2x1ZGUgPHN5cy9tb3VudC5oPgogI2luY2x1ZGUg PHN5cy9pb2N0bC5oPgogI2luY2x1ZGUgPHhmcy9saWJ4ZnMuaD4KKyNpbmNsdWRl IDxzeXMvc3lzY3RsLmg+CiAKIGludCBwbGF0Zm9ybV9oYXNfdXVpZCA9IDE7CiBl eHRlcm4gY2hhciAqcHJvZ25hbWU7CkBAIC05MCwxMyArOTEsNiBAQAogCSpic3og PSBCQlNJWkU7CiB9CiAKLS8qIEFSR1NVU0VEICovCi1pbnQKLXBsYXRmb3JtX2Fp b19pbml0KGludCBhaW9fY291bnQpCi17Ci0JcmV0dXJuIDA7CQkvKiBhaW8vbGlv X2xpc3RpbyBub3QgYXZhaWxhYmxlICovCi19Ci0KIGNoYXIgKgogcGxhdGZvcm1f ZmluZHJhd3BhdGgoY2hhciAqcGF0aCkKIHsKQEAgLTEyNCw1ICsxMTgsMjggQEAK IGludAogcGxhdGZvcm1fbnByb2Modm9pZCkKIHsKLQlyZXR1cm4gMTsKKwlpbnQJ CW5jcHU7CisJc2l6ZV90CQlsZW4gPSBzaXplb2YobmNwdSk7CisJc3RhdGljIGlu dAltaWJbMl0gPSB7Q1RMX0hXLCBIV19OQ1BVfTsKKworCWlmIChzeXNjdGwobWli LCAyLCAmbmNwdSwgJmxlbiwgTlVMTCwgMCkgPCAwKQorCQluY3B1ID0gMTsKKwor CXJldHVybiBuY3B1OwogfQorCit1bnNpZ25lZCBsb25nCitwbGF0Zm9ybV9waHlz bWVtKHZvaWQpCit7CisJdW5zaWduZWQgbG9uZwlwaHlzbWVtOworCXNpemVfdAkJ bGVuID0gc2l6ZW9mKHBoeXNtZW0pOworCXN0YXRpYyBpbnQJbWliWzJdID0ge0NU TF9IVywgSFdfUEhZU01FTX07CisKKwlpZiAoc3lzY3RsKG1pYiwgMiwgJnBoeXNt ZW0sICZsZW4sIE5VTEwsIDApIDwgMCkgeworCQlmcHJpbnRmKHN0ZGVyciwgXygi JXM6IGNhbid0IGRldGVybWluZSBtZW1vcnkgc2l6ZVxuIiksCisJCQlwcm9nbmFt ZSk7CisJCWV4aXQoMSk7CisJfQorCXJldHVybiBwaHlzbWVtID4+IDEwOworfQor CkluZGV4OiByZXBhaXIveGZzcHJvZ3MvbGlieGZzL2ZyZWVic2QuYwo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSByZXBhaXIub3JpZy94ZnNwcm9ncy9saWJ4ZnMvZnJl ZWJzZC5jCTIwMDctMDQtMTIgMTQ6NTU6NTMuMDAwMDAwMDAwICsxMDAwCisrKyBy ZXBhaXIveGZzcHJvZ3MvbGlieGZzL2ZyZWVic2QuYwkyMDA3LTA1LTMwIDEzOjQ4 OjE3LjU4Njc1Mjk1NSArMTAwMApAQCAtMTQ5LDEzICsxNDksNiBAQAogCSpic3og PSAoaW50KXNzaXplOwogfQogCi0vKiBBUkdTVVNFRCAqLwotaW50Ci1wbGF0Zm9y bV9haW9faW5pdChpbnQgYWlvX2NvdW50KQotewotCXJldHVybiAwOwkJLyogYWlv L2xpb19saXN0aW8gbm90IGF2YWlsYWJsZSAqLwotfQotCiBjaGFyICoKIHBsYXRm b3JtX2ZpbmRyYXdwYXRoKGNoYXIgKnBhdGgpCiB7CkBAIC0xODMsNSArMTc2LDI3 IEBACiBpbnQKIHBsYXRmb3JtX25wcm9jKHZvaWQpCiB7Ci0JcmV0dXJuIDE7CisJ aW50CQluY3B1OworCXNpemVfdAkJbGVuID0gc2l6ZW9mKG5jcHUpOworCXN0YXRp YyBpbnQJbWliWzJdID0ge0NUTF9IVywgSFdfTkNQVX07CisKKwlpZiAoc3lzY3Rs KG1pYiwgMiwgJm5jcHUsICZsZW4sIE5VTEwsIDApIDwgMCkKKwkJbmNwdSA9IDE7 CisKKwlyZXR1cm4gbmNwdTsKK30KKwordW5zaWduZWQgbG9uZworcGxhdGZvcm1f cGh5c21lbSh2b2lkKQoreworCXVuc2lnbmVkIGxvbmcJcGh5c21lbTsKKwlzaXpl X3QJCWxlbiA9IHNpemVvZihwaHlzbWVtKTsKKwlzdGF0aWMgaW50CW1pYlsyXSA9 IHtDVExfSFcsIEhXX1BIWVNNRU19OworCisJaWYgKHN5c2N0bChtaWIsIDIsICZw aHlzbWVtLCAmbGVuLCBOVUxMLCAwKSA8IDApIHsKKwkJZnByaW50ZihzdGRlcnIs IF8oIiVzOiBjYW4ndCBkZXRlcm1pbmUgbWVtb3J5IHNpemVcbiIpLAorCQkJcHJv Z25hbWUpOworCQlleGl0KDEpOworCX0KKwlyZXR1cm4gcGh5c21lbSA+PiAxMDsK IH0KSW5kZXg6IHJlcGFpci94ZnNwcm9ncy9saWJ4ZnMvaW5pdC5oCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dzL2xpYnhmcy9pbml0 LmgJMjAwNy0wNC0xMiAxNDo1NTo1My4wMDAwMDAwMDAgKzEwMDAKKysrIHJlcGFp ci94ZnNwcm9ncy9saWJ4ZnMvaW5pdC5oCTIwMDctMDUtMzAgMTI6NTE6MTkuNDE5 MTY2NDg2ICsxMDAwCkBAIC0zMiw4ICszMiw4IEBACiBleHRlcm4gY2hhciAqcGxh dGZvcm1fZmluZGJsb2NrcGF0aCAoY2hhciAqcGF0aCk7CiBleHRlcm4gaW50IHBs YXRmb3JtX2RpcmVjdF9ibG9ja2RldiAodm9pZCk7CiBleHRlcm4gaW50IHBsYXRm b3JtX2FsaWduX2Jsb2NrZGV2ICh2b2lkKTsKLWV4dGVybiBpbnQgcGxhdGZvcm1f YWlvX2luaXQgKGludCBhaW9fY291bnQpOwogZXh0ZXJuIGludCBwbGF0Zm9ybV9u cHJvYyh2b2lkKTsKK2V4dGVybiB1bnNpZ25lZCBsb25nIHBsYXRmb3JtX3BoeXNt ZW0odm9pZCk7CS8qIGluIGtpbG9ieXRlcyAqLwogZXh0ZXJuIGludCBwbGF0Zm9y bV9oYXNfdXVpZDsKIAogI2VuZGlmCS8qIExJQlhGU19JTklUX0ggKi8KSW5kZXg6 IHJlcGFpci94ZnNwcm9ncy9saWJ4ZnMvaXJpeC5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dzL2xpYnhmcy9pcml4LmMJMjAwNy0w NC0xMiAxNDo1NTo1My4wMDAwMDAwMDAgKzEwMDAKKysrIHJlcGFpci94ZnNwcm9n cy9saWJ4ZnMvaXJpeC5jCTIwMDctMDUtMzAgMTM6NDg6MzQuMTQwNjA3OTk2ICsx MDAwCkBAIC0xNyw3ICsxNyw2IEBACiAgKi8KIAogI2luY2x1ZGUgPHhmcy9saWJ4 ZnMuaD4KLSNpbmNsdWRlIDxhaW8uaD4KICNpbmNsdWRlIDxkaXNraW5mby5oPgog I2luY2x1ZGUgPHN5cy9zeXNtcC5oPgogCkBAIC02OCwxOSArNjcsNiBAQAogCSpi c3ogPSBCQlNJWkU7CiB9CiAKLWludAotcGxhdGZvcm1fYWlvX2luaXQoaW50IGFp b19jb3VudCkKLXsKLQlzdHJ1Y3QgYWlvaW5pdCBhaW9faW5pdDsKLQotCW1lbXNl dCgmYWlvX2luaXQsIDAsIHNpemVvZihhaW9faW5pdCkpOwotCWFpb19pbml0LmFp b190aHJlYWRzID0gYWlvX2NvdW50OwotCWFpb19pbml0LmFpb19udW11c2VycyA9 IGFpb19jb3VudDsKLQotCWFpb19zZ2lfaW5pdDY0KCZhaW9faW5pdCk7Ci0JcmV0 dXJuICgxKTsJCS8qIGFpby9saW9fbGlzdGlvIGF2YWlsYWJsZSAqLwotfQotCiBj aGFyICoKIHBsYXRmb3JtX2ZpbmRyYXdwYXRoKGNoYXIgKnBhdGgpCiB7CkBAIC0x MTEsMyArOTcsMTUgQEAKIAlyZXR1cm4gc3lzbXAoTVBfTlBST0NTKTsKIH0KIAor dW5zaWduZWQgbG9uZworcGxhdGZvcm1fcGh5c21lbSh2b2lkKQoreworCXN0cnVj dCBybWluZm8gcmk7CisKKwlpZiAoc3lzbXAoTVBfU0FHRVQsIE1QU0FfUk1JTkZP LCAmcmksIHNpemVvZihyaSkpIDwgMCkKKwkJZnByaW50ZihzdGRlcnIsIF8oIiVz OiBjYW4ndCBkZXRlcm1pbmUgbWVtb3J5IHNpemVcbiIpLAorCQkJcHJvZ25hbWUp OworCQlleGl0KDEpOworCX0KKwlyZXR1cm4gKHJpLnBoeXNtZW0gPj4gMTApICog Z2V0cGFnZXNpemUoKTsJLyoga2lsb2J5dGVzICovCit9ClwgTm8gbmV3bGluZSBh dCBlbmQgb2YgZmlsZQpJbmRleDogcmVwYWlyL3hmc3Byb2dzL2xpYnhmcy9saW51 eC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHJlcGFpci5vcmlnL3hmc3Byb2dz L2xpYnhmcy9saW51eC5jCTIwMDctMDQtMTIgMTQ6NTU6NTMuMDAwMDAwMDAwICsx MDAwCisrKyByZXBhaXIveGZzcHJvZ3MvbGlieGZzL2xpbnV4LmMJMjAwNy0wNS0z MCAxMzo0NzozNC41ODQzMjQ4OTQgKzEwMDAKQEAgLTIwLDExICsyMCwxMSBAQAog I2luY2x1ZGUgPHhmcy9saWJ4ZnMuaD4KICNpbmNsdWRlIDxtbnRlbnQuaD4KICNp bmNsdWRlIDxzeXMvc3RhdC5oPgotI2luY2x1ZGUgPGFpby5oPgogI3VuZGVmIHVz dGF0CiAjaW5jbHVkZSA8c3lzL3VzdGF0Lmg+CiAjaW5jbHVkZSA8c3lzL21vdW50 Lmg+CiAjaW5jbHVkZSA8c3lzL2lvY3RsLmg+CisjaW5jbHVkZSA8c3lzL3N5c2lu Zm8uaD4KIAogaW50IHBsYXRmb3JtX2hhc191dWlkID0gMTsKIGV4dGVybiBjaGFy ICpwcm9nbmFtZTsKQEAgLTE3NCwxOSArMTc0LDYgQEAKIAkJbWF4X2Jsb2NrX2Fs aWdubWVudCA9ICpic3o7CiB9CiAKLWludAotcGxhdGZvcm1fYWlvX2luaXQoaW50 IGFpb19jb3VudCkKLXsKLQlzdHJ1Y3QgYWlvaW5pdCBsY2xfYWlvX2luaXQ7Ci0K LQltZW1zZXQoJmxjbF9haW9faW5pdCwgMCwgc2l6ZW9mKGxjbF9haW9faW5pdCkp OwotCWxjbF9haW9faW5pdC5haW9fdGhyZWFkcyA9IGFpb19jb3VudDsKLQlsY2xf YWlvX2luaXQuYWlvX251bXVzZXJzID0gYWlvX2NvdW50OwotCi0JYWlvX2luaXQo JmxjbF9haW9faW5pdCk7Ci0JcmV0dXJuICgxKTsJCS8qIGFpby9saW9fbGlzdGlv IGF2YWlsYWJsZSAqLwotfQotCiBjaGFyICoKIHBsYXRmb3JtX2ZpbmRyYXdwYXRo KGNoYXIgKnBhdGgpCiB7CkBAIC0yMTgsMyArMjA1LDE2IEBACiB7CiAJcmV0dXJu IHN5c2NvbmYoX1NDX05QUk9DRVNTT1JTX09OTE4pOwogfQorCit1bnNpZ25lZCBs b25nCitwbGF0Zm9ybV9waHlzbWVtKHZvaWQpCit7CisJc3RydWN0IHN5c2luZm8g IHNpOworCisJaWYgKHN5c2luZm8oJnNpKSA8IDApIHsKKwkJZnByaW50ZihzdGRl cnIsIF8oIiVzOiBjYW4ndCBkZXRlcm1pbmUgbWVtb3J5IHNpemVcbiIpLAorCQkJ cHJvZ25hbWUpOworCQlleGl0KDEpOworCX0KKwlyZXR1cm4gKHNpLnRvdGFscmFt ID4+IDEwKSAqIHNpLm1lbV91bml0OwkvKiBraWxvYnl0ZXMgKi8KK30KSW5kZXg6 IHJlcGFpci94ZnNwcm9ncy9yZXBhaXIvZGlyX3N0YWNrLmgKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gcmVwYWlyLm9yaWcveGZzcHJvZ3MvcmVwYWlyL2Rpcl9zdGFj ay5oCTIwMDctMDQtMTIgMTQ6NTU6NTcuMDAwMDAwMDAwICsxMDAwCisrKyAvZGV2 L251bGwJMTk3MC0wMS0wMSAwMDowMDowMC4wMDAwMDAwMDAgKzAwMDAKQEAgLTEs MzMgKzAsMCBAQAotLyoKLSAqIENvcHlyaWdodCAoYykgMjAwMC0yMDAxLDIwMDUg U2lsaWNvbiBHcmFwaGljcywgSW5jLgotICogQWxsIFJpZ2h0cyBSZXNlcnZlZC4K LSAqCi0gKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiBy ZWRpc3RyaWJ1dGUgaXQgYW5kL29yCi0gKiBtb2RpZnkgaXQgdW5kZXIgdGhlIHRl cm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcwotICogcHVi bGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCi0gKgotICog VGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQg d291bGQgYmUgdXNlZnVsLAotICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3 aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKLSAqIE1FUkNIQU5U QUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNl ZSB0aGUKLSAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRl dGFpbHMuCi0gKgotICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBv ZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKLSAqIGFsb25nIHdpdGgg dGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRoZSBGcmVlIFNvZnR3YXJlIEZv dW5kYXRpb24sCi0gKiBJbmMuLCAgNTEgRnJhbmtsaW4gU3QsIEZpZnRoIEZsb29y LCBCb3N0b24sIE1BICAwMjExMC0xMzAxICBVU0EKLSAqLwotCi10eXBlZGVmIHN0 cnVjdCBkaXJfc3RhY2tfZWxlbSAgewotCXhmc19pbm9fdAkJaW5vOwotCXN0cnVj dCBkaXJfc3RhY2tfZWxlbQkqbmV4dDsKLX0gZGlyX3N0YWNrX2VsZW1fdDsKLQot dHlwZWRlZiBzdHJ1Y3QgZGlyX3N0YWNrICB7Ci0JaW50CQkJY250OwotCWRpcl9z dGFja19lbGVtX3QJKmhlYWQ7Ci19IGRpcl9zdGFja190OwotCi0KLXZvaWQJCWRp cl9zdGFja19pbml0KGRpcl9zdGFja190ICpzdGFjayk7Ci0KLXZvaWQJCXB1c2hf ZGlyKGRpcl9zdGFja190ICpzdGFjaywgeGZzX2lub190IGlubyk7Ci14ZnNfaW5v X3QJcG9wX2RpcihkaXJfc3RhY2tfdCAqc3RhY2spOwo= ------------IrJlgiTfBCmIeXv1iG6QRc-- From owner-xfs@oss.sgi.com Mon Jun 4 19:37:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 19:37:09 -0700 (PDT) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l552b4Wt011960 for ; Mon, 4 Jun 2007 19:37:05 -0700 Received: by nz-out-0506.google.com with SMTP id 4so1046391nzn for ; Mon, 04 Jun 2007 19:37:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=V2hx4hEtayAjXpYjkPPxDHkfDO9Z4FDZJzq6O0MNMn6F6x3/0Gu6l2V1eOk5leHqvC68Y10Z+g8vzmVymMx36mVzHIW2KPfE/J7pEqVXFRMbCWLKuUJL5GT1/E1RHopwtQkMwzUwZog0YvonwnSXbX/URiAqBO/I6hyWBQQUGC8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fU2KeVCrzy/Oqr2KILX/7Em+v5q6CdR9yqCYFqwXTG3UoYcysH2yHNTUu8WBIKvEQLpwEQCoqZVvWnzLcBp/QwVC2gp2XpjzqtWELH3aEmXF5zFRPtb+LN7a9LsZtBc1oOX6vBvPM91vPiXo7uX6716pvp3DSEG3Rymp/VAsV2E= Received: by 10.114.106.1 with SMTP id e1mr5450745wac.1181009406802; Mon, 04 Jun 2007 19:10:06 -0700 (PDT) Received: by 10.115.55.14 with HTTP; Mon, 4 Jun 2007 19:10:06 -0700 (PDT) Message-ID: Date: Mon, 4 Jun 2007 22:10:06 -0400 From: "=?ISO-8859-1?Q?Germ=E1n_Po=F3-Caama=F1o?=" To: xfs@oss.sgi.com Subject: Reporting a bug MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l552b6Wt011965 X-archive-position: 11641 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: german.poo@gmail.com Precedence: bulk X-list: xfs I having have some problems with a XFS partition in Debian Sarge: After a clean reboot (it supposed to be), my machine started with kernel messages of problems, such us XFS_WANT_CORRUPTED_GOTO and XFS_WANT_CORRUPTED_RETURN. It mainly was located in /var. But, after cleaning that, I checked other partitions. I guessed that my root partition (/dev/sda5) was in problems also. I mounted as readonly partition and I ran xfs_repair on it. xfs_repair moved 6 files (all of them ELF binaries) to lost+found. After reboot the machine, it can't boot anymore. Trying with Sysrescue 0.3.5 I get the following: # xfs_check /dev/sda5 [...] dir 1310848 block 8388608 extra leaf entry fc4e7e74 e7 dir 1310848 block 8388608 extra leaf entry fcdbb5f3 8f dir 1310848 block 8388608 extra leaf entry fddcbf74 164 /usr/bin/xfs_check: line 28: 14691 Segmentation fault xfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1 # xfs_repair -n /dev/sda5 Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 bad nextents 12 for inode 786561, would reset to 13 bad directory leaf magic # 0x46e for directory inode 786561 block 8388610 - agno = 4 - agno = 5 bmap rec out of order, inode 1310848 entry 2 [o s c] [8388608 81946 1], 1 [8388608 81946 1] bad data fork in inode 1310848 would have cleared inode 1310848 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 entry "etc" at block 0 offset 128 in directory inode 128 references free inode 1310848 would clear inode number in entry at offset 128... entry ".." at block 0 offset 32 in directory inode 149 references free inode 1310848 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 970 references free inode 1310848 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 17805 references free inode 1310848 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 42528 references free inode 1310848 would clear inode number in entry at offset 32... - agno = 1 entry ".." at block 0 offset 32 in directory inode 262276 references free inode 1310848 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 262288 references free inode 1310848 would clear inode number in entry at offset 32... - agno = 2 entry ".." at block 0 offset 32 in directory inode 524569 references free inode 1310848 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 560783 references free inode 1310848 would clear inode number in entry at offset 32... - agno = 3 bad nextents 12 for inode 786561, would reset to 13 entry ".." at block 0 offset 32 in directory inode 786608 references free inode 1310848 would clear inode number in entry at offset 32... - agno = 4 entry ".." at block 0 offset 32 in directory inode 1067905 references free inode 1310848 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 1067924 references free inode 1310848 would clear inode number in entry at offset 32... - agno = 5 bmap rec out of order, inode 1310848 entry 2 [o s c] [8388608 81946 1], 1 [8388608 81946 1] bad data fork in inode 1310848 would have cleared inode 1310848 entry ".." at block 0 offset 32 in directory inode 1310944 references free inode 1310848 would clear inode number in entry at offset 32... - agno = 6 entry ".." at block 0 offset 32 in directory inode 1573000 references free inode 1310848 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 1573094 references free inode 1310848 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 1573120 references free inode 1310848 would clear inode number in entry at offset 32... - agno = 7 entry ".." at block 0 offset 32 in directory inode 1835140 references free inode 1310848 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 1835168 references free inode 1310848 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 1854273 references free inode 1310848 would clear inode number in entry at offset 32... entry ".." at block 0 offset 32 in directory inode 1854300 references free inode 1310848 would clear inode number in entry at offset 32... No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... entry "etc" in directory inode 128 points to free inode 1310848, would junk entry corrupt dinode 786561, (btree extents). This is a bug. Please report it to xfs@oss.sgi.com. corrupt dinode 786561, (btree extents). This is a bug. Please report it to xfs@oss.sgi.com. corrupt dinode 786561, (btree extents). This is a bug. Please report it to xfs@oss.sgi.com. Segmentation fault -- Germán Poó Caamaño http://www.gnome.org/~gpoo/ From owner-xfs@oss.sgi.com Mon Jun 4 19:44:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Jun 2007 19:44:10 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l552i4Wt013922 for ; Mon, 4 Jun 2007 19:44:06 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA07293; Tue, 5 Jun 2007 12:43:59 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 18DCB58C38C1; Tue, 5 Jun 2007 12:43:59 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 957724 - need an xfsdump/xfscopy style tools that collects metadata only Message-Id: <20070605024359.18DCB58C38C1@chook.melbourne.sgi.com> Date: Tue, 5 Jun 2007 12:43:59 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-archive-position: 11642 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs XFS metadata dump tool Date: Tue Jun 5 12:43:11 AEST 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/metadump Inspected by: Christoph Hellwig The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:28782a xfsprogs/mdrestore/xfs_mdrestore.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mdrestore/xfs_mdrestore.c xfsprogs/mdrestore/Makefile - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mdrestore/Makefile - Metadump restore tool xfsprogs/db/metadump.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/metadump.c - Add metadump to xfs_db xfsprogs/man/man8/xfs_mdrestore.8 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_mdrestore.8 - Update man page for xfs_metadump xfsprogs/db/xfs_metadump.sh - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/xfs_metadump.sh - Scripto wrapper for xfs_db metadump command xfsprogs/include/xfs_metadump.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_metadump.h - Header for xfs_metadump structures xfsprogs/db/metadump.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/metadump.h - Add metadump to xfs_db xfsprogs/man/man8/xfs_metadump.8 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_metadump.8 - Update man page for xfs_metadump xfsprogs/db/init.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/init.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/db/Makefile - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/Makefile.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/db/command.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/command.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h - Add metadump to xfs_db xfsprogs/Makefile - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/Makefile.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h - Add xfs_mdrestore directory to makefile xfsprogs/VERSION - 1.172 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.172&r2=text&tr2=1.171&f=h xfsprogs/doc/CHANGES - 1.241 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.241&r2=text&tr2=1.240&f=h - Update to version 2.9.0 xfsprogs/man/man8/xfs_db.8 - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_db.8.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/man/man8/xfs_repair.8 - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_repair.8.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h - Update man page for xfs_metadump From owner-xfs@oss.sgi.com Tue Jun 5 00:40:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 00:40:38 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l557eVWt008006 for ; Tue, 5 Jun 2007 00:40:34 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA14559; Tue, 5 Jun 2007 17:40:26 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id B7F6358C38C1; Tue, 5 Jun 2007 17:40:26 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 964465 - Transaction delta counts are not applied atomically Message-Id: <20070605074026.B7F6358C38C1@chook.melbourne.sgi.com> Date: Tue, 5 Jun 2007 17:40:26 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 11643 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Apply transaction delta counts atomically to incore counters With the per-cpu superblock counters, batch updates are no longer atomic across the entire batch of changes. This is not an issue if each individual change in teh batch is applied atomically. Unfortunately, free block count changes are not applied atomically, and they are applied in a manner guaranteed to cause problems. Essentially, the free block count reservation that the transaction took initially is returned to the in core counters before a second delta takes away what is used. because these two operations are not atomic, we can race with another thread that can use the returned transaction reservation before the transaction takes the space away again and we can then get ENOSPC being reported in a spot where we don't have an ENOSPC condition, nor should we ever see one there. Fix it up by rolling the two deltas into the one so it can be applied safely (i.e. atomically) to the incore counters. Date: Tue Jun 5 17:39:41 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28796a fs/xfs/xfs_trans.c - 1.181 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.c.diff?r1=text&tr1=1.181&r2=text&tr2=1.180&f=h - Apply transaction deltas atomically by ensuring we only ever update each counter once per transaction. From owner-xfs@oss.sgi.com Tue Jun 5 00:52:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 00:52:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l557qGWt011448 for ; Tue, 5 Jun 2007 00:52:18 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA14851; Tue, 5 Jun 2007 17:52:12 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id B502958C38C1; Tue, 5 Jun 2007 17:52:12 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 964647 - file corruption seen when DMF recalls files with buffered i/o Message-Id: <20070605075212.B502958C38C1@chook.melbourne.sgi.com> Date: Tue, 5 Jun 2007 17:52:12 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 11644 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Map unwritten extents correctly for I/o completion processing If we have multiple unwritten extents within a single page, we fail to tell the I/o completion construction handlers we need a new handle for the second and subsequent blocks in teh page. While we still issue the I/O correctly, we do not have the correct ranges recorded in the ioend structures and hence when we go to convert the unwritten extents we screw it up. Make sure we start a new ioend every time the mapping changes so that we convert the correct ranges on I/O completion. Date: Tue Jun 5 17:51:26 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28797a fs/xfs/linux-2.6/xfs_aops.c - 1.146 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.146&r2=text&tr2=1.145&f=h - If the mapping changes between blocks in xfs_page_state_convert, make sure that we also start a new ioend for the new mapping. From owner-xfs@oss.sgi.com Tue Jun 5 01:23:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 01:23:50 -0700 (PDT) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l558NjWt020118 for ; Tue, 5 Jun 2007 01:23:47 -0700 Received: from teal.hq.k1024.org (84-75-124-135.dclient.hispeed.ch [84.75.124.135]) by astra.simleu.ro (Postfix) with ESMTP id 276AD152; Tue, 5 Jun 2007 11:23:43 +0300 (EEST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 181F0411159; Tue, 5 Jun 2007 10:00:13 +0200 (CEST) Date: Tue, 5 Jun 2007 10:00:12 +0200 From: Iustin Pop To: David Chinner Cc: Ruben Porras , xfs@oss.sgi.com, cw@f00f.org Subject: Re: XFS shrink functionality Message-ID: <20070605080012.GA10677@teal.hq.k1024.org> Mail-Followup-To: David Chinner , Ruben Porras , xfs@oss.sgi.com, cw@f00f.org References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> <20070604084154.GA8273@teal.hq.k1024.org> <20070604092115.GX85884050@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604092115.GX85884050@sgi.com> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 11645 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 07:21:15PM +1000, David Chinner wrote: > > allocated on an available AG and when you remove the originals, the > > to-be-shrinked AGs become free. Yes, utterly non-optimal, but it was the > > simplest way to do it based on what I knew at the time. > > Not quite that simple, unfortunately. You can't leave the > AGs locked in the same way we do for a grow because we need > to be able to use the AGs to move stuff about and that > requires locking them. Hence we need a separate mechanism > to prevent allocation in a given AG outside of locking them. > > Hence we need: > > - a transaction to mark AGs "no-allocate" > - a transaction to mark AGs "allocatable" > - a flag in each AGF/AGI to say the AG is available for > allocations (persistent over crashes) > - a flag in the per-ag structure to indicate allocation > status of the AG. > - everywhere we select an AG for allocation, we need to > check this flag and skip the AG if it's not available. > > FWIW, the transactions can probably just be an extension of > xfs_alloc_log_agf() and xfs_alloc_log_agi().... A question: do you think that the cost of having this in the code (especially the last part, check that flag in every allocation function) is acceptable? I mean, let's say one would write the patch to implement all this. Does it have a chance to be accepted? Or will people say it's only bloat? ... > > I was > > more thinking that the offline-AG should be a bit on the AG that could > > be changed by the admin (like xfs_freeze); this could also help for > > other reasons than shrink (when on a big FS some AGs lie on a physical > > device and others on a different device, and you would like to restrict > > writes to a given AG, as much as possible). > > Yes, that's exactly what I'm talking about ;) Ah, I see now what did you mean by having a transaction for locking/unlocking AGs for allocation. > Yeah, 1) and 4) are separable parts of the problem and can be done > in any order. 2) can be implemented relatively easily as stated > above. > > 3) is the hard one - we need to find the owner of each block > (metadata and data) remaining in the AGs to be removed. This may be > a directory btree block, a inode extent btree block, a data block, > and extended attr block, etc. Moving the data blocks is easy to > do (swap extents), but moving the metadata blocks is a major PITA > as it will need to be done transactionally and that will require > a bunch of new (complex) code to be written, I think. It will be > of equivalent complexity to defragmenting metadata.... > > If we ignore the metadata block problem then finding and moving the > data blocks should not be a problem - swap extents can be used for > that as well - but it will be extremely time consuming and won't > scale to large filesystem sizes.... So given these caveats, is there a chance that a) this will be actually useful and b) will this be accepted? The last time I tried to work on this there has been no real feedback and I'm thinking that maybe the code will be too intrusive and will give to little gain to be accepted. Thanks for your comments, iustin From owner-xfs@oss.sgi.com Tue Jun 5 07:49:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 07:49:59 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l55EnsWt015560 for ; Tue, 5 Jun 2007 07:49:55 -0700 Received: by wa-out-1112.google.com with SMTP id k22so2207115waf for ; Tue, 05 Jun 2007 07:49:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=BplMohzWFsZ9B3BPPIPJb4TGByD38KRXhTn2NbKnYyC5aftP7StMktGhFg6p3Jj4OfyIsiHnc81qCwm76HGCpi3OXMVedjvn73HExVsMNJGB/0g8aK2Ag1L9vzR3/DYnW8bB1/bmmhrrl2OMn5FRn1LcBHqDaDNTqBjPCs+MRlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=QZog1A56EtcUVQSsXmFa4Elx51uOvudJg7/hRwMbW1/NTj0a6rYWsAk9fWJXmJr8QoeJtviW1/kNgXliABv0tc796GZwAgOubxu8nqQ/WhfZuvYWaV/qwTnjW8eSQIEvD4cRvkcm/yBFuAWFSFVQ/jh/Cfrys3ZY1sOiNWqIlSg= Received: by 10.114.201.1 with SMTP id y1mr5995386waf.1181054994139; Tue, 05 Jun 2007 07:49:54 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Tue, 5 Jun 2007 07:49:54 -0700 (PDT) Message-ID: <5d96567b0706050749o74bc7701g154e836c43a511be@mail.gmail.com> Date: Tue, 5 Jun 2007 16:49:54 +0200 From: "Raz Ben-Jehuda(caro)" To: linux-xfs@oss.sgi.com Subject: building xfstests MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 11646 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs Hello I have downloaded from the web the cvs repository of the module xfs-cmds. I failing to build it. the bellow is the "make" output. ... == dist, log is Logs/dist Wrote: /d1/rt/raz/downloads/xfs-cmds/xfsprogs/build/xfsprogs-2.9.0.src.tar.gz Wrote: /d1/rt/raz/downloads/xfs-cmds/xfsprogs/build/tar/xfsprogs-2.9.0.tar.gz == Building dmapi == clean, log is Logs/clean == configure, log is Logs/configure == default, log is Logs/default == dist, log is Logs/dist Wrote: /d1/rt/raz/downloads/xfs-cmds/dmapi/build/dmapi-2.2.8.src.tar.gz Wrote: /d1/rt/raz/downloads/xfs-cmds/dmapi/build/tar/dmapi-2.2.8.tar.gz == Building xfsdump == clean, log is Logs/clean == configure, log is Logs/configure == default, log is Logs/default = dist, log is Logs/dist Wrote: /d1/rt/raz/downloads/xfs-cmds/xfsdump/build/xfsdump-2.2.45.src.tar.gz Wrote: /d1/rt/raz/downloads/xfs-cmds/xfsdump/build/tar/xfsdump-2.2.45.tar.gz for d in attr acl xfsprogs dmapi xfsdump; do \ ( cd /d1/rt/raz/downloads/xfs-cmds && /bin/cp $d/build/rpm/*.src.rpm /d1/rt/raz/downloads/xfs-cmds/SRPMS ) \ done /bin/cp: cannot stat `attr/build/rpm/*.src.rpm': No such file or directory /bin/cp: cannot stat `acl/build/rpm/*.src.rpm': No such file or directory /bin/cp: cannot stat `xfsprogs/build/rpm/*.src.rpm': No such file or directory /bin/cp: cannot stat `dmapi/build/rpm/*.src.rpm': No such file or directory /bin/cp: cannot stat `xfsdump/build/rpm/*.src.rpm': No such file or directory make: *** [cmds] Error 1 anyone ? -- Raz From owner-xfs@oss.sgi.com Tue Jun 5 08:07:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 08:07:09 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l55F75Wt021248 for ; Tue, 5 Jun 2007 08:07:06 -0700 Received: from Liberator.local (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id DB0D91806631F; Tue, 5 Jun 2007 10:07:04 -0500 (CDT) Message-ID: <46657C17.1090105@sandeen.net> Date: Tue, 05 Jun 2007 10:07:03 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: "Raz Ben-Jehuda(caro)" CC: linux-xfs@oss.sgi.com Subject: Re: building xfstests References: <5d96567b0706050749o74bc7701g154e836c43a511be@mail.gmail.com> In-Reply-To: <5d96567b0706050749o74bc7701g154e836c43a511be@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 11647 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Raz Ben-Jehuda(caro) wrote: > Hello > I have downloaded from the web the cvs repository of the > module xfs-cmds. > > I failing to build it. the bellow is the "make" output. ... > Wrote: > /d1/rt/raz/downloads/xfs-cmds/xfsdump/build/xfsdump-2.2.45.src.tar.gz > Wrote: > /d1/rt/raz/downloads/xfs-cmds/xfsdump/build/tar/xfsdump-2.2.45.tar.gz So, everything built - but it just did not build rpms - which is maybe fine with you? > for d in attr acl xfsprogs dmapi xfsdump; do \ > ( cd /d1/rt/raz/downloads/xfs-cmds && /bin/cp > $d/build/rpm/*.src.rpm /d1/rt/raz/downloads/xfs-cmds/SRPMS ) \ > done > /bin/cp: cannot stat `attr/build/rpm/*.src.rpm': No such file or directory > /bin/cp: cannot stat `acl/build/rpm/*.src.rpm': No such file or directory > /bin/cp: cannot stat `xfsprogs/build/rpm/*.src.rpm': No such file or > directory > /bin/cp: cannot stat `dmapi/build/rpm/*.src.rpm': No such file or directory > /bin/cp: cannot stat `xfsdump/build/rpm/*.src.rpm': No such file or > directory It's just trying to copy rpms to a central location, and they didn't build for you (maybe you're on debian or similar?) So kind of a dumb top-level makefile (hmm who wrote that stuff... ;-) but it looks like all of your packages built as tarballs. -Eric > make: *** [cmds] Error 1 > > anyone ? > > From owner-xfs@oss.sgi.com Tue Jun 5 13:24:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 13:24:38 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l55KOWWt021662 for ; Tue, 5 Jun 2007 13:24:33 -0700 Received: from [89.54.183.197] (helo=noname) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1HvfZs-0006xy-Pu; Tue, 05 Jun 2007 22:24:29 +0200 Date: Tue, 5 Jun 2007 22:24:32 +0200 (CEST) From: Christian Kujau X-X-Sender: dummy@foobar-g4 To: "Raz Ben-Jehuda(caro)" cc: xfs@oss.sgi.com Subject: Re: corruption bug in 2.6.17 In-Reply-To: <5d96567b0706050127y7f5eap7b92cddb5cdae02d@mail.gmail.com> Message-ID: References: <5d96567b0706021407q4455b60asd9d23ef82cb90b55@mail.gmail.com> <5d96567b0706050127y7f5eap7b92cddb5cdae02d@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-archive-position: 11648 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs [please reply on-list, so that everbody can help. and top-posting is evil;) ] On Tue, 5 Jun 2007, Raz Ben-Jehuda(caro) wrote: > It is unclear from the web page how can reproduce this bug. Can you > think of a several steps that produces it so I will be able to know > whether 2.7.17.7 fix had fixed it ? I have been bitten by this one too and to "reproduce" it I only had to 1) boot 2.6.17.x (x<17) 2) generate some IO on the xfs-mounted partition...and wait until the fs shut down. The fix is really to use a 2.7.17.7 or later kernel and check your xfs with xfsprogs (version 2.8.10 or later) - if no corruptions are found, you should be fine. C. -- make bzImage, not war From owner-xfs@oss.sgi.com Tue Jun 5 15:23:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 15:23:40 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l55MNbWt025377 for ; Tue, 5 Jun 2007 15:23:38 -0700 Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id l55MN79r028549 for ; Tue, 5 Jun 2007 15:23:13 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id l55MNRre022798 for ; Tue, 5 Jun 2007 15:23:27 -0700 Received: from [10.123.4.142] ([10.123.4.142]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 15:23:50 -0700 Message-ID: <4665E276.9020406@agami.com> Date: Tue, 05 Jun 2007 15:23:50 -0700 From: Michael Nishimoto User-Agent: Mail/News 1.5.0.4 (X11/20060629) MIME-Version: 1.0 To: David Chinner CC: Michael Nishimoto , xfs@oss.sgi.com Subject: Re: Reducing memory requirements for high extent xfs files References: <200705301649.l4UGnckA027406@oss.sgi.com> <20070530225516.GB85884050@sgi.com> In-Reply-To: <20070530225516.GB85884050@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2007 22:23:50.0448 (UTC) FILETIME=[31353B00:01C7A7C0] X-Scanned-By: MIMEDefang 2.58 on 192.168.168.13 X-archive-position: 11649 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miken@agami.com Precedence: bulk X-list: xfs David Chinner wrote: > On Wed, May 30, 2007 at 09:49:38AM -0700, Michael Nishimoto wrote: > > Hello, > > > > Has anyone done any work or had thoughts on changes required > > to reduce the total memory footprint of high extent xfs files? > > We changed the way we do memory allocation to avoid needing > large contiguous chunks of memory a bit over a year ago; > that solved the main OOM problem we were getting reported > with highly fragmented files. > > > Obviously, it is important to reduce fragmentation as files > > are generated and to regularly defrag files, but both of these > > alternatives are not complete solutions. > > > > To reduce memory consumption, xfs could bring in extents > > from disk as needed (or just before needed) and could free > > up mappings when certain extent ranges have not been recently > > accessed. A solution should become more aggressive about > > reclaiming extent mapping memory as free memory becomes limited. > > Yes, it could, but that's a pretty major overhaul of the extent > interface which currently assumes everywhere that the entire > extent tree is in core. > > Can you describe the problem you are seeing that leads you to > ask this question? What's the problem you need to solve? > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group I realize that this work won't be trivial which is why I asked if anyone has thought about all relevant issues. When using NFS over XFS, slowly growing files (can be ascii log files) tend to fragment quite a bit. One system had several hundred files which required more than one page to store the extents. Quite a few files had extent counts greater than 10k, and one file had 120k extents. Besides the memory consumption, latency to return the first byte of the file can get noticeable. Michael From owner-xfs@oss.sgi.com Tue Jun 5 16:00:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 16:00:12 -0700 (PDT) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l55N06Wt003482 for ; Tue, 5 Jun 2007 16:00:07 -0700 Received: from [192.168.5.76] (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 17FF892C3E1; Wed, 6 Jun 2007 09:00:05 +1000 (EST) Subject: Re: corruption bug in 2.6.17 From: Nathan Scott To: Christian Kujau Cc: "Raz Ben-Jehuda(caro)" , xfs@oss.sgi.com In-Reply-To: References: <5d96567b0706021407q4455b60asd9d23ef82cb90b55@mail.gmail.com> <5d96567b0706050127y7f5eap7b92cddb5cdae02d@mail.gmail.com> Content-Type: text/plain Date: Wed, 06 Jun 2007 08:58:47 +1000 Message-Id: <1181084327.3176.4.camel@edge.yarra.acx> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0 (2.8.0-33.el5) Content-Transfer-Encoding: 7bit X-archive-position: 11650 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Tue, 2007-06-05 at 22:24 +0200, Christian Kujau wrote: > ... > 2) generate some IO on the xfs-mounted partition...and wait until > the > fs shut down. The problem was actually related to a particular form of btree dir2 transition - so, certain combinations of file names in a relatively large directory with size changes would trigger it. "generate some IO" is a bit too vague to be helpful. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jun 5 16:01:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 16:01:19 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l55N1FWt003808 for ; Tue, 5 Jun 2007 16:01:16 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 25B72B000867; Tue, 5 Jun 2007 19:01:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 243865000168; Tue, 5 Jun 2007 19:01:15 -0400 (EDT) Date: Tue, 5 Jun 2007 19:01:15 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Nathan Scott cc: Christian Kujau , "Raz Ben-Jehuda(caro)" , xfs@oss.sgi.com Subject: Re: corruption bug in 2.6.17 In-Reply-To: <1181084327.3176.4.camel@edge.yarra.acx> Message-ID: References: <5d96567b0706021407q4455b60asd9d23ef82cb90b55@mail.gmail.com> <5d96567b0706050127y7f5eap7b92cddb5cdae02d@mail.gmail.com> <1181084327.3176.4.camel@edge.yarra.acx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 11651 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Wed, 6 Jun 2007, Nathan Scott wrote: > On Tue, 2007-06-05 at 22:24 +0200, Christian Kujau wrote: >> ... >> 2) generate some IO on the xfs-mounted partition...and wait until >> the >> fs shut down. > > The problem was actually related to a particular form of btree > dir2 transition - so, certain combinations of file names in a > relatively large directory with size changes would trigger it. > > "generate some IO" is a bit too vague to be helpful. > > cheers. > > -- > Nathan > > The patch that fixed it: --- linux-2.6.17.6.orig/fs/xfs/xfs_dir2_node.c +++ linux-2.6.17.6/fs/xfs/xfs_dir2_node.c @@ -970,7 +970,7 @@ xfs_dir2_leafn_remove( /* * One less used entry in the free table. */ - free->hdr.nused = cpu_to_be32(-1); + be32_add(&free->hdr.nused, -1); xfs_dir2_free_log_header(tp, fbp); /* * If this was the last entry in the table, we can From owner-xfs@oss.sgi.com Tue Jun 5 16:08:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 16:08:58 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l55N8qWt006311 for ; Tue, 5 Jun 2007 16:08:54 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07154; Wed, 6 Jun 2007 09:08:44 +1000 Message-ID: <4665ED89.4090202@sgi.com> Date: Wed, 06 Jun 2007 09:11:05 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Michael Nishimoto CC: David Chinner , Michael Nishimoto , xfs@oss.sgi.com Subject: Re: Reducing memory requirements for high extent xfs files References: <200705301649.l4UGnckA027406@oss.sgi.com> <20070530225516.GB85884050@sgi.com> <4665E276.9020406@agami.com> In-Reply-To: <4665E276.9020406@agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 11652 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Michael Nishimoto wrote: > > > David Chinner wrote: >> On Wed, May 30, 2007 at 09:49:38AM -0700, Michael Nishimoto wrote: >> > Hello, >> > >> > Has anyone done any work or had thoughts on changes required >> > to reduce the total memory footprint of high extent xfs files? >> >> We changed the way we do memory allocation to avoid needing >> large contiguous chunks of memory a bit over a year ago; >> that solved the main OOM problem we were getting reported >> with highly fragmented files. >> >> > Obviously, it is important to reduce fragmentation as files >> > are generated and to regularly defrag files, but both of these >> > alternatives are not complete solutions. >> > >> > To reduce memory consumption, xfs could bring in extents >> > from disk as needed (or just before needed) and could free >> > up mappings when certain extent ranges have not been recently >> > accessed. A solution should become more aggressive about >> > reclaiming extent mapping memory as free memory becomes limited. >> >> Yes, it could, but that's a pretty major overhaul of the extent >> interface which currently assumes everywhere that the entire >> extent tree is in core. >> >> Can you describe the problem you are seeing that leads you to >> ask this question? What's the problem you need to solve? >> >> Cheers, >> >> Dave. >> -- >> Dave Chinner >> Principal Engineer >> SGI Australian Software Group > > I realize that this work won't be trivial which is why I asked if anyone > has thought about all relevant issues. > > When using NFS over XFS, slowly growing files (can be ascii log files) > tend to fragment quite a bit. One system had several hundred files > which required more than one page to store the extents. Quite a few > files had extent counts greater than 10k, and one file had 120k extents. > Besides the memory consumption, latency to return the first byte of the > file can get noticeable. > > Michael > Hi Michael, You could use XFS_XFLAG_EXTSIZE and XFS_XFLAG_RTINHERIT flags to set extent hint size, which would reduce the file fragmentation in this scenario. Please check xfcntl man page for more details. Regards, Vlad / / From owner-xfs@oss.sgi.com Tue Jun 5 16:15:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 16:15:18 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l55NFDWt009150 for ; Tue, 5 Jun 2007 16:15:14 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07227; Wed, 6 Jun 2007 09:15:04 +1000 Message-ID: <4665EF04.5020803@sgi.com> Date: Wed, 06 Jun 2007 09:17:24 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Vlad Apostolov CC: Michael Nishimoto , David Chinner , Michael Nishimoto , xfs@oss.sgi.com Subject: Re: Reducing memory requirements for high extent xfs files References: <200705301649.l4UGnckA027406@oss.sgi.com> <20070530225516.GB85884050@sgi.com> <4665E276.9020406@agami.com> <4665ED89.4090202@sgi.com> In-Reply-To: <4665ED89.4090202@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 11653 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Vlad Apostolov wrote: > Michael Nishimoto wrote: >> >> >> David Chinner wrote: >>> On Wed, May 30, 2007 at 09:49:38AM -0700, Michael Nishimoto wrote: >>> > Hello, >>> > >>> > Has anyone done any work or had thoughts on changes required >>> > to reduce the total memory footprint of high extent xfs files? >>> >>> We changed the way we do memory allocation to avoid needing >>> large contiguous chunks of memory a bit over a year ago; >>> that solved the main OOM problem we were getting reported >>> with highly fragmented files. >>> >>> > Obviously, it is important to reduce fragmentation as files >>> > are generated and to regularly defrag files, but both of these >>> > alternatives are not complete solutions. >>> > >>> > To reduce memory consumption, xfs could bring in extents >>> > from disk as needed (or just before needed) and could free >>> > up mappings when certain extent ranges have not been recently >>> > accessed. A solution should become more aggressive about >>> > reclaiming extent mapping memory as free memory becomes limited. >>> >>> Yes, it could, but that's a pretty major overhaul of the extent >>> interface which currently assumes everywhere that the entire >>> extent tree is in core. >>> >>> Can you describe the problem you are seeing that leads you to >>> ask this question? What's the problem you need to solve? >>> >>> Cheers, >>> >>> Dave. >>> -- >>> Dave Chinner >>> Principal Engineer >>> SGI Australian Software Group >> >> I realize that this work won't be trivial which is why I asked if anyone >> has thought about all relevant issues. >> >> When using NFS over XFS, slowly growing files (can be ascii log files) >> tend to fragment quite a bit. One system had several hundred files >> which required more than one page to store the extents. Quite a few >> files had extent counts greater than 10k, and one file had 120k extents. >> Besides the memory consumption, latency to return the first byte of the >> file can get noticeable. >> >> Michael >> > Hi Michael, > > You could use XFS_XFLAG_EXTSIZE and XFS_XFLAG_RTINHERIT flags to > set extent hint size, which would reduce the file fragmentation in > this scenario. > Please check xfcntl man page for more details. > > Regards, > Vlad I meant XFS_XFLAG_EXTSZINHERIT not XFS_XFLAG_RTINHERIT. This one should be set on a parent directory. Regards, Vlad From owner-xfs@oss.sgi.com Tue Jun 5 16:20:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 16:20:49 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l55NKiWt013845 for ; Tue, 5 Jun 2007 16:20:46 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07545; Wed, 6 Jun 2007 09:20:38 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l55NKaAf114653268; Wed, 6 Jun 2007 09:20:37 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l55NKXvw114255060; Wed, 6 Jun 2007 09:20:33 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 6 Jun 2007 09:20:33 +1000 From: David Chinner To: "Jahnke, Steffen" Cc: xfs@oss.sgi.com Subject: Re: XFS with project quota under linux? Message-ID: <20070605232033.GZ85884050@sgi.com> References: <950DD867A5E1B04ABE82A56FCDC03A5E9CE8CF@HDHS0111.euro1.voith.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <950DD867A5E1B04ABE82A56FCDC03A5E9CE8CF@HDHS0111.euro1.voith.net> User-Agent: Mutt/1.4.2.1i X-archive-position: 11654 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 10:55:35AM +0200, Jahnke, Steffen wrote: > I recently switched the quota usrquota to pquota on our Altix 4700 under > SLES10. I then found out that the project quota is not updated if files are > moved within the same filesystem. E.g. if I move a file from a different > project to a new project it still belongs to the old project. The same thing > happens if I move a file which not belongs to any project but which is on > the filesystem mounted with pquota. Working as designed, by the sounds of it. Moving a file around the filesystem does not change the project it is assigned to. Files created (i.e. moved into the filesystem) get assigned a new project id on create which is why there is different behaviour there. Are you trying to use directory quotas here rather than just plain project quotas? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Jun 5 16:25:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 16:25:10 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l55NP4Wt015325 for ; Tue, 5 Jun 2007 16:25:06 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07628; Wed, 6 Jun 2007 09:24:59 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l55NOwAf114351195; Wed, 6 Jun 2007 09:24:59 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l55NOv3M114474218; Wed, 6 Jun 2007 09:24:57 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 6 Jun 2007 09:24:57 +1000 From: David Chinner To: =?iso-8859-1?Q?Germ=E1n_Po=F3-Caama=F1o?= Cc: xfs@oss.sgi.com Subject: Re: Reporting a bug Message-ID: <20070605232457.GA85884050@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 11655 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 10:10:06PM -0400, Germán Poó-Caamaño wrote: > I having have some problems with a XFS partition in Debian Sarge: > > After a clean reboot (it supposed to be), my machine started with > kernel messages of problems, such us XFS_WANT_CORRUPTED_GOTO and > XFS_WANT_CORRUPTED_RETURN. > > It mainly was located in /var. But, after cleaning that, I checked > other partitions. I guessed that my root partition (/dev/sda5) was in > problems also. I mounted as readonly partition and I ran xfs_repair > on it. xfs_repair moved 6 files (all of them ELF binaries) to > lost+found. After reboot the machine, it can't boot anymore. Sounds like a critical binary for boot got lost... > Trying with Sysrescue 0.3.5 I get the following: What version of the XFS utilities has that got? You might do better booting knoppix and then downloading the latest tools and running them.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Jun 5 18:36:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 18:36:13 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l561a7Wt014049 for ; Tue, 5 Jun 2007 18:36:09 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11001; Wed, 6 Jun 2007 11:36:07 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l561a5Af115221377; Wed, 6 Jun 2007 11:36:05 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l561a1HD115123473; Wed, 6 Jun 2007 11:36:01 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 6 Jun 2007 11:36:01 +1000 From: David Chinner To: Michael Nishimoto Cc: David Chinner , Michael Nishimoto , xfs@oss.sgi.com Subject: Re: Reducing memory requirements for high extent xfs files Message-ID: <20070606013601.GR86004887@sgi.com> References: <200705301649.l4UGnckA027406@oss.sgi.com> <20070530225516.GB85884050@sgi.com> <4665E276.9020406@agami.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4665E276.9020406@agami.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 11656 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Jun 05, 2007 at 03:23:50PM -0700, Michael Nishimoto wrote: > David Chinner wrote: > >On Wed, May 30, 2007 at 09:49:38AM -0700, Michael Nishimoto wrote: > > > Hello, > > > > > > Has anyone done any work or had thoughts on changes required > > > to reduce the total memory footprint of high extent xfs files? ..... > >Yes, it could, but that's a pretty major overhaul of the extent > >interface which currently assumes everywhere that the entire > >extent tree is in core. > > > >Can you describe the problem you are seeing that leads you to > >ask this question? What's the problem you need to solve? > > I realize that this work won't be trivial which is why I asked if anyone > has thought about all relevant issues. > > When using NFS over XFS, slowly growing files (can be ascii log files) > tend to fragment quite a bit. Oh, that problem. The issue is that allocation beyond EOF (the normal way we prevent fragmentation in this case) gets truncated off on file close. Even NFS request is processed by doing: open write close And so XFS truncates the allocation beyond EOF on close. Hence the next write requires a new allocation and that results in a non-contiguous file because the adjacent blocks have already been used.... Options: - NFS server open file cache to avoid the close. - add detection to XFS to determine if the called is an NFS thread and don't truncate on close. - use preallocation. - preallocation on the file once will result in the XFS_DIFLAG_PREALLOC being set on the inode and it won't truncate on close. - append only flag will work in the same way as the prealloc flag w.r.t preventing truncation on close. - run xfs_fsr Note - i don't think extent size hints alone will help as they don't prevent EOF truncation on close. > One system had several hundred files > which required more than one page to store the extents. I don't consider that a problem as such. We'll always get some level of fragmentation if we don't preallocate. > Quite a few > files had extent counts greater than 10k, and one file had 120k extents. you should run xfs_fsr occassionally.... > Besides the memory consumption, latency to return the first byte of the > file can get noticeable. Yes, that too :/ However, I think we should be trying to fix the root cause of this worst case fragmentation rather than trying to make the rest of the filesystem accommodate an extreme corner case efficiently. i.e. let's look at the test cases and determine what piece of logic we need to add or remove to prevent this cause of fragmentation. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Jun 5 18:51:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 18:51:44 -0700 (PDT) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l561pbWt017857 for ; Tue, 5 Jun 2007 18:51:39 -0700 Received: from edge.local (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 9F07C92C53D; Wed, 6 Jun 2007 11:51:25 +1000 (EST) Subject: Re: XFS shrink functionality From: Nathan Scott Reply-To: nscott@aconex.com To: Iustin Pop Cc: David Chinner , Ruben Porras , xfs@oss.sgi.com, cw@f00f.org In-Reply-To: <20070605080012.GA10677@teal.hq.k1024.org> References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> <20070604084154.GA8273@teal.hq.k1024.org> <20070604092115.GX85884050@sgi.com> <20070605080012.GA10677@teal.hq.k1024.org> Content-Type: text/plain Organization: Aconex Date: Wed, 06 Jun 2007 11:50:10 +1000 Message-Id: <1181094610.3758.2.camel@edge.yarra.acx> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 11657 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Tue, 2007-06-05 at 10:00 +0200, Iustin Pop wrote: > > > So given these caveats, is there a chance that a) this will be > actually > useful and b) will this be accepted? Theres no doubt that its useful, its probably the most frequently requested feature for XFS from the community. I'd imagine its acceptance will depend on code quality, testing, etc, etc. > The last time I tried to work on this there has been no real feedback > and I'm thinking that maybe the code will be too intrusive and will > give > to little gain to be accepted. IIRC, most people missed the patch last time cos it got bounced by the list (cant remember why) - that was why I missed it for a long time, anyway. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jun 5 18:58:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 18:58:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l561wFWt019745 for ; Tue, 5 Jun 2007 18:58:17 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11655; Wed, 6 Jun 2007 11:58:08 +1000 Message-ID: <4666153C.9050409@sgi.com> Date: Wed, 06 Jun 2007 12:00:28 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: David Chinner CC: Michael Nishimoto , Michael Nishimoto , xfs@oss.sgi.com Subject: Re: Reducing memory requirements for high extent xfs files References: <200705301649.l4UGnckA027406@oss.sgi.com> <20070530225516.GB85884050@sgi.com> <4665E276.9020406@agami.com> <20070606013601.GR86004887@sgi.com> In-Reply-To: <20070606013601.GR86004887@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 11658 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Tue, Jun 05, 2007 at 03:23:50PM -0700, Michael Nishimoto wrote: > >> David Chinner wrote: >> >>> On Wed, May 30, 2007 at 09:49:38AM -0700, Michael Nishimoto wrote: >>> >>>> Hello, >>>> >>>> Has anyone done any work or had thoughts on changes required >>>> to reduce the total memory footprint of high extent xfs files? >>>> > ..... > >>> Yes, it could, but that's a pretty major overhaul of the extent >>> interface which currently assumes everywhere that the entire >>> extent tree is in core. >>> >>> Can you describe the problem you are seeing that leads you to >>> ask this question? What's the problem you need to solve? >>> >> I realize that this work won't be trivial which is why I asked if anyone >> has thought about all relevant issues. >> >> When using NFS over XFS, slowly growing files (can be ascii log files) >> tend to fragment quite a bit. >> > > Oh, that problem. > > The issue is that allocation beyond EOF (the normal way we prevent > fragmentation in this case) gets truncated off on file close. > > Even NFS request is processed by doing: > > open > write > close > > And so XFS truncates the allocation beyond EOF on close. Hence > the next write requires a new allocation and that results in > a non-contiguous file because the adjacent blocks have already > been used.... > > Options: > > - NFS server open file cache to avoid the close. > - add detection to XFS to determine if the called is > an NFS thread and don't truncate on close. > - use preallocation. > - preallocation on the file once will result in the > XFS_DIFLAG_PREALLOC being set on the inode and it > won't truncate on close. > - append only flag will work in the same way as the > prealloc flag w.r.t preventing truncation on close. > - run xfs_fsr > > Note - i don't think extent size hints alone will help as they > don't prevent EOF truncation on close. > Dave, I think extent hint should help in this situation. Here is an example of writing 4 chars in a file with extent hint of 16Kb. The file ends up with size of 4 and 8 basic blocks (512 bytes each) allocation in one extent. emu:/mnt/scratch1/temp # xfs_io -c "extsize 16384" -f foo emu:/mnt/scratch1/temp # ls -al foo -rw------- 1 root root 0 2007-06-06 12:33 foo emu:/mnt/scratch1/temp # xfs_bmap -l -v foo foo: no extents emu:/mnt/scratch1/temp # echo "abc" > foo emu:/mnt/scratch1/temp # ls -al foo -rw------- 1 root root 4 2007-06-06 12:35 foo emu:/mnt/scratch1/temp # xfs_bmap -l -v foo foo: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 326088..326095 0 (326088..326095) 8 Just a warning that the extent hint works at the moment only for contiguous files. There are problems for sparse files (with holes) and extent hint. Regards, Vlad From owner-xfs@oss.sgi.com Tue Jun 5 19:03:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 19:03:03 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l5622wWt021282 for ; Tue, 5 Jun 2007 19:03:00 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA11835; Wed, 6 Jun 2007 12:02:50 +1000 Message-ID: <46661657.2060507@sgi.com> Date: Wed, 06 Jun 2007 12:05:11 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Vlad Apostolov CC: David Chinner , Michael Nishimoto , Michael Nishimoto , xfs@oss.sgi.com Subject: Re: Reducing memory requirements for high extent xfs files References: <200705301649.l4UGnckA027406@oss.sgi.com> <20070530225516.GB85884050@sgi.com> <4665E276.9020406@agami.com> <20070606013601.GR86004887@sgi.com> <4666153C.9050409@sgi.com> In-Reply-To: <4666153C.9050409@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 11659 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Vlad Apostolov wrote: No, Dave is right. The example worked because the extent hint was the same size as the filesystem block. Regards, Vlad >> >> Note - i don't think extent size hints alone will help as they >> don't prevent EOF truncation on close. > Dave, > > I think extent hint should help in this situation. Here is an example > of writing 4 chars in a file with extent hint of 16Kb. The file ends > up with size of 4 and 8 basic blocks (512 bytes each) allocation in > one extent. > > emu:/mnt/scratch1/temp # xfs_io -c "extsize 16384" -f foo > emu:/mnt/scratch1/temp # ls -al foo > -rw------- 1 root root 0 2007-06-06 12:33 foo > emu:/mnt/scratch1/temp # xfs_bmap -l -v foo > foo: no extents > emu:/mnt/scratch1/temp # echo "abc" > foo > emu:/mnt/scratch1/temp # ls -al foo > -rw------- 1 root root 4 2007-06-06 12:35 foo > emu:/mnt/scratch1/temp # xfs_bmap -l -v foo > foo: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > 0: [0..7]: 326088..326095 0 (326088..326095) 8 > > Just a warning that the extent hint works at the moment only for > contiguous files. There are problems for sparse files (with holes) > and extent hint. > > Regards, > Vlad > From owner-xfs@oss.sgi.com Tue Jun 5 20:52:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 20:52:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.4 required=5.0 tests=AWL,BAYES_99,J_CHICKENPOX_45, MIME_8BIT_HEADER autolearn=no version=3.2.0-pre1-r499012 Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l563q0Wt022962 for ; Tue, 5 Jun 2007 20:52:03 -0700 Received: by nz-out-0506.google.com with SMTP id 4so13363nzn for ; Tue, 05 Jun 2007 20:52:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sRmJ6tg3vCZMVqHk/6fLRdqezLf0PnioW3qhNKkwLbbCHoxx20CIRdFcnXk9elvledYCx8C2fim85q2EoLTgw81UpbJrxWvuVuV9UUHl2d1hBgmXKTpQ9TRB7v8Nwr+dJ7iNuzmYl/LKt0MjPudkkGokdv8ju2lqCyBqlwsP5eY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h7Ix38OeVtJCLx8xV1UH4i9OvvNmW5lG5IzP+ljrgnhWs+B1EQmn51IcDs0oHGwOmaVVvzVfH0zAGnfwe6P3YSNcdVjUgrKGENzxh7E1uVwb03hRbC3+0V5FOURXHdBXc46WDGpVl9WpOzc/b2AGwPTVkGE67OP18twSII9BtBU= Received: by 10.115.32.1 with SMTP id k1mr39676waj.1181100176606; Tue, 05 Jun 2007 20:22:56 -0700 (PDT) Received: by 10.115.55.14 with HTTP; Tue, 5 Jun 2007 20:22:56 -0700 (PDT) Message-ID: Date: Tue, 5 Jun 2007 23:22:56 -0400 From: "=?ISO-8859-1?Q?Germ=E1n_Po=F3-Caama=F1o?=" To: "David Chinner" Subject: Re: Reporting a bug Cc: xfs@oss.sgi.com In-Reply-To: <20070605232457.GA85884050@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <20070605232457.GA85884050@sgi.com> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l563q3Wt022992 X-archive-position: 11660 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: german.poo@gmail.com Precedence: bulk X-list: xfs 2007/6/5, David Chinner : > On Mon, Jun 04, 2007 at 10:10:06PM -0400, Germán Poó-Caamaño wrote: > > I having have some problems with a XFS partition in Debian Sarge: > > > > After a clean reboot (it supposed to be), my machine started with > > kernel messages of problems, such us XFS_WANT_CORRUPTED_GOTO and > > XFS_WANT_CORRUPTED_RETURN. > > > > It mainly was located in /var. But, after cleaning that, I checked > > other partitions. I guessed that my root partition (/dev/sda5) was in > > problems also. I mounted as readonly partition and I ran xfs_repair > > on it. xfs_repair moved 6 files (all of them ELF binaries) to > > lost+found. After reboot the machine, it can't boot anymore. > > Sounds like a critical binary for boot got lost... I thought that in the beginning. But, the crash and segfaults I pasted in my second message were produced also when I ran Sysrescue (LiveCD) and tried to work with that filesystem. Anyway, I applied objdump -T to each file in lost+found. A lot of them were important (libgcc, tls/lpthreads, tls/libm, and such). It seems there were duplicates, because for each file in lost+found was a library in /lib or /lib/tls. Some nasty behavior was something like: # mkdir foo # cd foo # foo: No such file or directory ls over /etc was able to show me group, passwd and shadow. But none of them was available. I copied group- to group. ls show me two 'group' files. > > Trying with Sysrescue 0.3.5 I get the following: > > What version of the XFS utilities has that got? > You might do better booting knoppix and then downloading the > latest tools and running them.... I used xfsprogs 2.8.18. Unfortunately I haven't had another disk/partition to apply 'dd' to the conflictive partition. I discarded a memory problem, it passed a night session of memtest without errors. In another partition (137 GB) with *.a lot of* files (think it's used for maildir). I got 17000+ files in lost+found). It passed xfs_repair. After mounted it again, and a little load, some files were deleted, but still listed with ls. If I try to stat that file I get 'No such file or directory', but still listed in the directory. I knew that XFS required a robust hardware, I'm not sure if still is true that statement. Anyway, I thought the hardware was robust and probably made a mistake. -- Germán Poó Caamaño http://www.gnome.org/~gpoo/ From owner-xfs@oss.sgi.com Tue Jun 5 22:37:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 22:38:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l565btWt017471 for ; Tue, 5 Jun 2007 22:37:57 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA17089; Wed, 6 Jun 2007 15:37:50 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l565bnAf113526369; Wed, 6 Jun 2007 15:37:50 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l565bmtC115116202; Wed, 6 Jun 2007 15:37:48 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 6 Jun 2007 15:37:48 +1000 From: David Chinner To: xfs-dev Cc: xfs-oss Subject: review: prevent log tail-pushing unmount deadlock Message-ID: <20070606053748.GV86004887@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11661 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs When we are unmounting the filesystem, we flush all the inodes to disk. Unfortunately, if we have an inode cluster that has just been freed and marked stale sitting in an incore log buffer (i.e. hasn't been flushed to disk), it will be holding all the flush locks on the inodes in that cluster. xfs_iflush_all() which is called during unmount walks all the inodes trying to reclaim them, and it doing so calls xfs_finish_reclaim() on each inode. If the inode is dirty, if grabs the flush lock and flushes it. Unfortunately, find dirty inodes that already have their flush lock held and so we sleep. At this point in the unmount process, we are running single-threaded. There is nothing more that can push on the log to force the transaction holding the inode flush locks to disk and hence we deadlock. The fix is to issue a log force before flushing the inodes on unmount so that all the flush locks will be released before we start flushing the inodes. Recently discovered during testing with filestreams enabled. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_mount.c | 11 +++++++++++ 1 file changed, 11 insertions(+) Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2007-04-19 13:47:41.272642686 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2007-04-19 13:49:53.643581957 +1000 @@ -1162,6 +1162,17 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr int64_t fsid; #endif + /* + * We can potentially deadlock here if we have an inode cluster + * that has been freed has it's buffer still pinned in memory because + * the transaction is still sitting in a iclog. The stale inodes + * on that buffer will have their flush locks held until the + * transaction hits the disk and the callbacks run. the inode + * flush takes the flush lock unconditionally and with nothing to + * push out the iclog we will never get that unlocked. hence we + * need to force the log first. + */ + xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE | XFS_LOG_SYNC); xfs_iflush_all(mp); XFS_QM_DQPURGEALL(mp, XFS_QMOPT_QUOTALL | XFS_QMOPT_UMOUNTING); From owner-xfs@oss.sgi.com Tue Jun 5 22:45:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 22:45:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l565jZWt019371 for ; Tue, 5 Jun 2007 22:45:37 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA17475; Wed, 6 Jun 2007 15:45:32 +1000 Message-ID: <46664A88.2000807@sgi.com> Date: Wed, 06 Jun 2007 15:47:52 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: xfs-dev CC: xfs@oss.sgi.com Subject: [REVIEW 1/2] - setting realtime and extent size hint flags via fcntl(XFS_IOC_FSSETXATTR) Content-Type: multipart/mixed; boundary="------------080609010505080602030404" X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11662 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------080609010505080602030404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This patch fixes error handling when setting realtime and extent size hint flags via fcntl(XFS_IOC_FSSETXATTR). It also makes XFS_XFLAG_RTINHERIT/XFS_XFLAG_EXTSZINHERIT and XFS_XFLAG_REALTIME/XFS_XFLAG_EXTSIZE flags mutually exclusive. Currently both, the realtime and extent hint flags could be set at the same time, which is not how the code is designed to work and could cause unexpected behavior. The realtime extent size is taken either from the on disk xfs inode di_extsize (if set to non zero) or from the supperblock sb_rextsize fields. The parent directory inheritance didn't inherit the di_extsize, which is also fixed in this patch. Regards, Vlad --------------080609010505080602030404 Content-Type: text/plain; name="fix_realtime_and_extent_hint_size_error_handling" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fix_realtime_and_extent_hint_size_error_handling" Index: linux-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-xfs.orig/fs/xfs/xfs_inode.c +++ linux-xfs/fs/xfs/xfs_inode.c @@ -793,6 +793,8 @@ _xfs_dic2xflags( if (di_flags & XFS_DIFLAG_ANY) { if (di_flags & XFS_DIFLAG_REALTIME) flags |= XFS_XFLAG_REALTIME; + else if (di_flags & XFS_DIFLAG_EXTSIZE) + flags |= XFS_XFLAG_EXTSIZE; if (di_flags & XFS_DIFLAG_PREALLOC) flags |= XFS_XFLAG_PREALLOC; if (di_flags & XFS_DIFLAG_IMMUTABLE) @@ -807,14 +809,12 @@ _xfs_dic2xflags( flags |= XFS_XFLAG_NODUMP; if (di_flags & XFS_DIFLAG_RTINHERIT) flags |= XFS_XFLAG_RTINHERIT; + else if (di_flags & XFS_DIFLAG_EXTSZINHERIT) + flags |= XFS_XFLAG_EXTSZINHERIT; if (di_flags & XFS_DIFLAG_PROJINHERIT) flags |= XFS_XFLAG_PROJINHERIT; if (di_flags & XFS_DIFLAG_NOSYMLINKS) flags |= XFS_XFLAG_NOSYMLINKS; - if (di_flags & XFS_DIFLAG_EXTSIZE) - flags |= XFS_XFLAG_EXTSIZE; - if (di_flags & XFS_DIFLAG_EXTSZINHERIT) - flags |= XFS_XFLAG_EXTSZINHERIT; if (di_flags & XFS_DIFLAG_NODEFRAG) flags |= XFS_XFLAG_NODEFRAG; } @@ -1200,9 +1200,12 @@ xfs_ialloc( uint di_flags = 0; if ((mode & S_IFMT) == S_IFDIR) { - if (pip->i_d.di_flags & XFS_DIFLAG_RTINHERIT) + if (pip->i_d.di_flags & XFS_DIFLAG_RTINHERIT) { di_flags |= XFS_DIFLAG_RTINHERIT; - if (pip->i_d.di_flags & XFS_DIFLAG_EXTSZINHERIT) { + ip->i_d.di_extsize = pip->i_d.di_extsize; + } + else if (pip->i_d.di_flags & + XFS_DIFLAG_EXTSZINHERIT) { di_flags |= XFS_DIFLAG_EXTSZINHERIT; ip->i_d.di_extsize = pip->i_d.di_extsize; } @@ -1210,8 +1213,10 @@ xfs_ialloc( if (pip->i_d.di_flags & XFS_DIFLAG_RTINHERIT) { di_flags |= XFS_DIFLAG_REALTIME; ip->i_iocore.io_flags |= XFS_IOCORE_RT; + ip->i_d.di_extsize = pip->i_d.di_extsize; } - if (pip->i_d.di_flags & XFS_DIFLAG_EXTSZINHERIT) { + else if (pip->i_d.di_flags & + XFS_DIFLAG_EXTSZINHERIT) { di_flags |= XFS_DIFLAG_EXTSIZE; ip->i_d.di_extsize = pip->i_d.di_extsize; } Index: linux-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-xfs.orig/fs/xfs/xfs_vnodeops.c +++ linux-xfs/fs/xfs/xfs_vnodeops.c @@ -547,15 +547,35 @@ xfs_setattr( } /* - * Can't change realtime flag if any extents are allocated. + * Can't have both realtime and extent hint flags set at + * the same time. + */ + if ((mask & XFS_AT_XFLAGS) && + (((vap->va_xflags & + (XFS_XFLAG_REALTIME | XFS_XFLAG_EXTSIZE)) == + (XFS_XFLAG_REALTIME | XFS_XFLAG_EXTSIZE)) || + ((vap->va_xflags & XFS_XFLAG_REALTIME) && + (ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE)) || + ((vap->va_xflags & XFS_XFLAG_EXTSIZE) && + (ip->i_d.di_flags & XFS_DIFLAG_REALTIME)))) { + code = XFS_ERROR(EINVAL); + goto error_return; + } + + /* + * Can't change realtime and extent hint flags if any extents + * are allocated. */ if ((ip->i_d.di_nextents || ip->i_delayed_blks) && (mask & XFS_AT_XFLAGS) && - (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != - (vap->va_xflags & XFS_XFLAG_REALTIME)) { + (((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != + (vap->va_xflags & XFS_XFLAG_REALTIME)) || + ((ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE) != + (vap->va_xflags & XFS_XFLAG_EXTSIZE)))) { code = XFS_ERROR(EINVAL); /* EFBIG? */ goto error_return; } + /* * Extent size must be a multiple of the appropriate block * size, if set at all. @@ -563,6 +583,16 @@ xfs_setattr( if ((mask & XFS_AT_EXTSIZE) && vap->va_extsize != 0) { xfs_extlen_t size; + /* + * Either realtime or extent hint flags must be set + * when extent size is non zero + */ + if (!(vap->va_xflags & + (XFS_XFLAG_REALTIME | XFS_XFLAG_EXTSIZE))) { + code = XFS_ERROR(EINVAL); + goto error_return; + } + if ((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) || ((mask & XFS_AT_XFLAGS) && (vap->va_xflags & XFS_XFLAG_REALTIME))) { @@ -817,10 +847,11 @@ xfs_setattr( if ((ip->i_d.di_mode & S_IFMT) == S_IFDIR) { if (vap->va_xflags & XFS_XFLAG_RTINHERIT) di_flags |= XFS_DIFLAG_RTINHERIT; + else if (vap->va_xflags & + XFS_XFLAG_EXTSZINHERIT) + di_flags |= XFS_DIFLAG_EXTSZINHERIT; if (vap->va_xflags & XFS_XFLAG_NOSYMLINKS) di_flags |= XFS_DIFLAG_NOSYMLINKS; - if (vap->va_xflags & XFS_XFLAG_EXTSZINHERIT) - di_flags |= XFS_DIFLAG_EXTSZINHERIT; } else if ((ip->i_d.di_mode & S_IFMT) == S_IFREG) { if (vap->va_xflags & XFS_XFLAG_REALTIME) { di_flags |= XFS_DIFLAG_REALTIME; --------------080609010505080602030404-- From owner-xfs@oss.sgi.com Tue Jun 5 22:47:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 22:47:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l565lAWt019909 for ; Tue, 5 Jun 2007 22:47:12 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA17579; Wed, 6 Jun 2007 15:47:07 +1000 Message-ID: <46664AE7.7070600@sgi.com> Date: Wed, 06 Jun 2007 15:49:27 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: xfs-dev CC: xfs@oss.sgi.com Subject: [REVIEW 2/2] - setting realtime and extent size hint flags via fcntl(XFS_IOC_FSSETXATTR) Content-Type: multipart/mixed; boundary="------------050606040702010003040602" X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11663 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------050606040702010003040602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This patch updates the xfsctl(XFS_IOC_FSSETXATTR) and xfsctl(XFS_IOC_RESVSP64) man page. Regards, Vlad --------------050606040702010003040602 Content-Type: text/plain; name*0="update_XFS_IOC_FSSETXATTR_and_XFS_IOC_RESVSP64_xfsctl_man_page" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="update_XFS_IOC_FSSETXATTR_and_XFS_IOC_RESVSP64_xfsctl_man_pa"; filename*1="ge" Index: xfs-cmds/xfsprogs/man/man3/xfsctl.3 =================================================================== --- xfs-cmds.orig/xfsprogs/man/man3/xfsctl.3 +++ xfs-cmds/xfsprogs/man/man3/xfsctl.3 @@ -251,11 +251,17 @@ and .BR fsx_extsize . The .B fsx_xflags -realtime file bit and the file's extent size may be changed only +realtime file bit +.B XFS_XFLAG_REALTIME, +extent hint bit +.B XFS_XFLAG_EXTSIZE +and the file's extent size may be changed only when the file is empty, except in the case of a directory where the extent size can be set at any time (this value is only used for regular file allocations, so should only be set on a directory in conjunction with the XFS_XFLAG_EXTSZINHERIT flag). +The extent size has to be aligned to the filesystem block size or +when the XFS_XFLAG_REALTIME flag is set to the realtime extent size. .TP .B XFS_IOC_GETBMAP @@ -325,7 +331,15 @@ The blocks are allocated, but not zeroed If the XFS filesystem is configured to flag unwritten file extents, performance will be negatively affected when writing to preallocated space, since extra filesystem transactions are required to convert extent flags on -the range of the file written. +the range of the file written. The +.B l_len +field is rounded to the filesystem block size. +For realtime files the +.B l_len +field is rounded to the realtime extent size. If the extent hint is set, the +.B l_len +is rounded to the extent hint size. + If .IR xfs_info (8) reports unwritten=1, then the filesystem was made to flag unwritten extents. --------------050606040702010003040602-- From owner-xfs@oss.sgi.com Tue Jun 5 22:55:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Jun 2007 22:55:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_99,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l565t1Wt021651 for ; Tue, 5 Jun 2007 22:55:03 -0700 Received: from [89.54.183.197] (helo=noname) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1HvoTw-0007SG-8G; Wed, 06 Jun 2007 07:54:56 +0200 Date: Wed, 6 Jun 2007 07:54:58 +0200 (CEST) From: Christian Kujau X-X-Sender: dummy@foobar-g4 To: Nathan Scott cc: "Raz Ben-Jehuda(caro)" , xfs@oss.sgi.com Subject: Re: corruption bug in 2.6.17 In-Reply-To: <1181084327.3176.4.camel@edge.yarra.acx> Message-ID: References: <5d96567b0706021407q4455b60asd9d23ef82cb90b55@mail.gmail.com> <5d96567b0706050127y7f5eap7b92cddb5cdae02d@mail.gmail.com> <1181084327.3176.4.camel@edge.yarra.acx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11664 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Wed, 6 Jun 2007, Nathan Scott wrote: > The problem was actually related to a particular form of btree > dir2 transition - so, certain combinations of file names in a > relatively large directory with size changes would trigger it. Sorry, I did not intend to confuse. But all I noticed when the fs was shut down, was that a backup script was running and triggering the bug every morning. I was not aware of any large directories.... thanks, Christian. -- make bzImage, not war From owner-xfs@oss.sgi.com Wed Jun 6 03:18:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Jun 2007 03:18:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.5 required=5.0 tests=AWL,BAYES_60 autolearn=no version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l56AIiWt006814 for ; Wed, 6 Jun 2007 03:18:45 -0700 Received: by wa-out-1112.google.com with SMTP id k22so115953waf for ; Wed, 06 Jun 2007 03:18:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=quj5J5RUiGykyy4ZYKHZ1ITdmVDDvpbZ59/g51x+SztIe5z1Bab9TR38KwoO+Z50mNI2tdppZ5rfXEce4MKmGOrWt6Jrz9g1SD3q/02UnOGs+arTN2vmJzeobLjvFTl+TNhKD1nghxTsq6R2KHMdNzz/944d96FfJYGPWAOQx/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=j8PyBB4Wplqq0GaWavWUCxz5vtZKbVJKPyQhufZ1VSaQxa8gkd+G9htR3Vq/yUiBUdrm8c2wlre4b8gFIvJosgImAnCSdLPtZMfVUSciRXlgAEB4Wa2TjHuFqhSQbzFlpyDXsdapSEV8dd5DMvUg1xPsC1s2AGW3G9cba09D3MI= Received: by 10.114.175.16 with SMTP id x16mr274636wae.1181125124381; Wed, 06 Jun 2007 03:18:44 -0700 (PDT) Received: from htj.dyndns.org ( [221.139.199.126]) by mx.google.com with ESMTP id m24sm4647644waf.2007.06.06.03.18.41; Wed, 06 Jun 2007 03:18:43 -0700 (PDT) Received: by htj.dyndns.org (Postfix, from userid 1000) id 018C323D4BBB; Wed, 6 Jun 2007 19:18:37 +0900 (KST) Date: Wed, 6 Jun 2007 19:18:37 +0900 From: Tejun Heo To: David Greaves Cc: Linus Torvalds , "Rafael J. Wysocki" , xfs@oss.sgi.com, "'linux-kernel@vger.kernel.org'" , netdev@oss.sgi.com, linux-pm , Neil Brown , mikpe@it.uu.se Subject: [PATCH] sata_promise: use TF interface for polling NODATA commands Message-ID: <20070606101837.GC29122@htj.dyndns.org> References: <46608E3F.4060201@dgreaves.com> <200706012342.45657.rjw@sisk.pl> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46667160.80905@gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11665 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: htejun@gmail.com Precedence: bulk X-list: xfs sata_promise uses two different command modes - packet and TF. Packet mode is intelligent low-overhead mode while TF is the same old taskfile interface. As with other advanced interface (ahci/sil24), ATA_TFLAG_POLLING has no effect in packet mode. However, PIO commands are issued using TF interface in polling mode, so pdc_interrupt() considers interrupts spurious if ATA_TFLAG_POLLING is set. This is broken for polling NODATA commands because command is issued using packet mode but the interrupt handler ignores it due to ATA_TFLAG_POLLING. Fix pdc_qc_issue_prot() such that ATA/ATAPI NODATA commands are issued using TF interface if ATA_TFLAG_POLLING is set. This patch fixes detection failure introduced by polling SETXFERMODE. Signed-off-by: Tejun Heo --- David, please verify this patch. Mikael, does this look okay? Please push this upstream after David and Mikael's ack. Thanks. drivers/ata/sata_promise.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/ata/sata_promise.c b/drivers/ata/sata_promise.c index 2b924a6..6dc0b01 100644 --- a/drivers/ata/sata_promise.c +++ b/drivers/ata/sata_promise.c @@ -784,9 +784,12 @@ static unsigned int pdc_qc_issue_prot(struct ata_queued_cmd *qc) if (qc->dev->flags & ATA_DFLAG_CDB_INTR) break; /*FALLTHROUGH*/ + case ATA_PROT_NODATA: + if (qc->tf.flags & ATA_TFLAG_POLLING) + break; + /*FALLTHROUGH*/ case ATA_PROT_ATAPI_DMA: case ATA_PROT_DMA: - case ATA_PROT_NODATA: pdc_packet_start(qc); return 0; @@ -800,7 +803,7 @@ static unsigned int pdc_qc_issue_prot(struct ata_queued_cmd *qc) static void pdc_tf_load_mmio(struct ata_port *ap, const struct ata_taskfile *tf) { WARN_ON (tf->protocol == ATA_PROT_DMA || - tf->protocol == ATA_PROT_NODATA); + tf->protocol == ATA_PROT_ATAPI_DMA); ata_tf_load(ap, tf); } @@ -808,7 +811,7 @@ static void pdc_tf_load_mmio(struct ata_port *ap, const struct ata_taskfile *tf) static void pdc_exec_command_mmio(struct ata_port *ap, const struct ata_taskfile *tf) { WARN_ON (tf->protocol == ATA_PROT_DMA || - tf->protocol == ATA_PROT_NODATA); + tf->protocol == ATA_PROT_ATAPI_DMA); ata_exec_command(ap, tf); } From owner-xfs@oss.sgi.com Wed Jun 6 03:39:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Jun 2007 03:39:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.7 required=5.0 tests=AWL,BAYES_99,J_CHICKENPOX_16, J_CHICKENPOX_32,J_CHICKENPOX_33,J_CHICKENPOX_62 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l56AdXWt012234 for ; Wed, 6 Jun 2007 03:39:34 -0700 Received: from localhost (mailman.ukfsn.org [80.168.53.75]) by mail.ukfsn.org (Postfix) with ESMTP id 43E21E7328; Wed, 6 Jun 2007 11:39:19 +0100 (BST) Received: from mail.ukfsn.org ([80.168.53.20]) by localhost (smtp-filter.ukfsn.org [80.168.53.75]) (amavisd-new, port 10024) with ESMTP id K10DXX16RMnQ; Wed, 6 Jun 2007 11:37:07 +0100 (BST) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 69B14E7358; Wed, 6 Jun 2007 11:39:17 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1HvsvJ-0003D3-Be; Wed, 06 Jun 2007 11:39:29 +0100 Message-ID: <46668EE0.2030509@dgreaves.com> Date: Wed, 06 Jun 2007 11:39:28 +0100 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Tejun Heo Cc: Linus Torvalds , "Rafael J. Wysocki" , xfs@oss.sgi.com, "'linux-kernel@vger.kernel.org'" , linux-pm , Neil Brown Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6) References: <46608E3F.4060201@dgreaves.com> <200706012342.45657.rjw@sisk.pl> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> In-Reply-To: <46667160.80905@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11666 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Tejun Heo wrote: > Hello, > > David Greaves wrote: >> Linus Torvalds wrote: >>> It would be interesting to see what triggered it, since it apparently >>> worked before. So yes, a bisection would be great. >> Tejun, all the problematic patches are yours - so adding you. > > Ouch.... that's what everyone says! Just to be clear. This problem is where my system won't resume after s2d unless I umount my xfs over raid6 filesystem. >> given the first patch identified is >> 9666f4009c22f6520ac3fb8a19c9e32ab973e828: "libata: reimplement suspend/resume >> support using sdev->manage_start_stop" >> That seems a good candidate... > > 9ce3075c20d458040138690edfdf6446664ec3ee works, right? Yes git reset --hard ec4883b015c3212f6f6d04fb2ff45f528492f598 vi Makefile make oldconfig make && make install && make modules_install && update-grub init 6 > Can you test > 9666f4009c22f6520ac3fb8a19c9e32ab973e828 by removing > ata_scsi_device_suspend/resume callbacks from sata_via.c? Just delete > all lines referencing those two functions. There were one or two > fallouts from the conversion. Yes, after I posted I realised that Andrews patch fixed the compile failure :) git reset --hard 9666f4009c22f6520ac3fb8a19c9e32ab973e828 diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c index 939c924..bad87b5 100644 --- a/drivers/ata/sata_via.c +++ b/drivers/ata/sata_via.c @@ -117,8 +117,6 @@ static struct scsi_host_template svia_sht = { .slave_destroy = ata_scsi_slave_destroy, .bios_param = ata_std_bios_param, #ifdef CONFIG_PM - .suspend = ata_scsi_device_suspend, - .resume = ata_scsi_device_resume, #endif }; So now this compiles but it does cause the problem: umount /huge echo platform > /sys/power/disk echo disk > /sys/power/state # resumes fine mount /huge echo platform > /sys/power/disk echo disk > /sys/power/state # won't resume FWIW, /huge is: /dev/md0 on /huge type xfs (rw) cu:~# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid6] [raid5] [raid4] md0 : active raid6 sdf1[0] sde1[1] sdd1[2] sdc1[3] sdb1[4] sda1[5] hdb1[6] 1225557760 blocks level 6, 256k chunk, algorithm 2 [7/7] [UUUUUUU] bitmap: 0/234 pages [0KB], 512KB chunk unused devices: > > How many drives do you have? 8 in total 2 pata : VIA vt8237 2 sata on sata_via 4 sata on sata_promise +1 pata cdrom Behavior difference introduced by the > reimplementation is serialization of resume sequence, so it takes more > time. My test machine had problems resuming if resume took too long > even with the previous implementation. It didn't matter whether the > long resuming sequence is caused by too many controllers or explicit > ssleep(). If time needed for resume sequence is over certain threshold, > machine hangs while resuming. I thought it was a BIOS glitch and didn't > dig into it but you might be seeing the same issue. given the mount/umount thing this sounds unlikely... but what do I know? resume does throw up: ATA: abnormal status 0x7F on port 0x0001b007 ATA: abnormal status 0x7F on port 0x0001b007 ATA: abnormal status 0x7F on port 0x0001a407 ATA: abnormal status 0x7F on port 0x0001a407 which I've not noticed before... oh, alright, I'll check... reboots to 2.6.21, suspend, resume... nope, not output on resume in 2.6.21 > Please post dmesg too. Thanks. > Here is: dmesg from 2.6.22-9666f4009c22f6520ac3fb8a19c9e32ab973e828 (ie with sata_via fix) dmesg from resume of above when /huge is unmounted dmesg from resume of 2.6.21 Linux version 2.6.21-TejunTst2-g9666f400-dirty (root@cu.dgreaves.com) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #13 Wed Jun 6 10:16:03 BST 2007 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009c400 (usable) BIOS-e820: 000000000009c400 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003fffc000 (usable) BIOS-e820: 000000003fffc000 - 000000003ffff000 (ACPI data) BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. Entering add_active_range(0, 0, 262140) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem 229376 -> 262140 early_node_map[1] active PFN ranges 0: 0 -> 262140 On node 0 totalpages: 262140 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 255 pages used for memmap HighMem zone: 32509 pages, LIFO batch:7 DMI 2.3 present. ACPI: RSDP 000F62A0, 0014 (r0 ASUS ) ACPI: RSDT 3FFFC000, 0030 (r1 ASUS A7V600 42302E31 MSFT 31313031) ACPI: FACP 3FFFC0B2, 0074 (r1 ASUS A7V600 42302E31 MSFT 31313031) ACPI: DSDT 3FFFC126, 2C4F (r1 ASUS A7V600 1000 MSFT 100000B) ACPI: FACS 3FFFF000, 0040 ACPI: BOOT 3FFFC030, 0028 (r1 ASUS A7V600 42302E31 MSFT 31313031) ACPI: APIC 3FFFC058, 005A (r1 ASUS A7V600 42302E31 MSFT 31313031) ACPI: PM-Timer IO Port: 0xe408 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:10 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000) Built 1 zonelists. Total pages: 260093 Kernel command line: root=/dev/hda2 ro log_buf_len=128k log_buf_len: 131072 mapped APIC to ffffd000 (fee00000) mapped IOAPIC to ffffc000 (fec00000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 1999.872 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1034940k/1048560k available (2426k kernel code, 12968k reserved, 888k data, 188k init, 131056k highmem) virtual kernel memory layout: fixmap : 0xfffaa000 - 0xfffff000 ( 340 kB) pkmap : 0xff800000 - 0xffc00000 (4096 kB) vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) .init : 0xc0440000 - 0xc046f000 ( 188 kB) .data : 0xc035e9ef - 0xc043cb90 ( 888 kB) .text : 0xc0100000 - 0xc035e9ef (2426 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4003.08 BogoMIPS (lpj=8006169) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383fbff c1cbfbff 00000000 00000000 00000000 00000000 00000000 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1cbfbff 00000000 00000420 00000000 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Compat vDSO mapped to ffffe000. CPU: AMD Athlon(TM) MP stepping 00 Checking 'hlt' instruction... OK. ACPI: Core revision 20070126 ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf1970, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: (supports S0 S1 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Probing PCI hardware (bus 00) PCI: enabled onboard AC97/MC97 devices ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 *6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12) *15, disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered pnp: ACPI device : hid PNP0C01 pnp: ACPI device : hid PNP0A03 pnp: ACPI device : hid PNP0C02 pnp: ACPI device : hid PNP0C02 pnp: ACPI device : hid PNP0200 pnp: ACPI device : hid PNP0B00 pnp: ACPI device : hid PNP0800 pnp: ACPI device : hid PNP0C04 pnp: ACPI device : hid PNP0501 pnp: ACPI device : hid PNP0501 pnp: ACPI device : hid PNP0303 pnp: ACPI device : hid PNP0F03 pnp: ACPI device : hid PNPB02F pnp: ACPI device : hid PNP0C02 pnp: PnP ACPI: found 14 devices ACPI: ACPI bus type pnp unregistered SCSI subsystem initialized libata version 2.20 loaded. PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report pnp: the driver 'system' has been registered pnp: match found with the PnP device '00:00' and the driver 'system' pnp: 00:00: iomem range 0x0-0x9ffff could not be reserved pnp: 00:00: iomem range 0xf0000-0xfffff could not be reserved pnp: 00:00: iomem range 0x100000-0x3fffffff could not be reserved pnp: 00:00: iomem range 0xfec00000-0xfec000ff could not be reserved pnp: match found with the PnP device '00:02' and the driver 'system' pnp: 00:02: ioport range 0xe400-0xe47f has been reserved pnp: 00:02: ioport range 0xe800-0xe81f has been reserved pnp: 00:02: iomem range 0xfff80000-0xffffffff could not be reserved pnp: 00:02: iomem range 0xffb80000-0xffbfffff has been reserved pnp: match found with the PnP device '00:03' and the driver 'system' pnp: match found with the PnP device '00:0d' and the driver 'system' pnp: 00:0d: ioport range 0x290-0x297 has been reserved pnp: 00:0d: ioport range 0x370-0x375 has been reserved Time: tsc clocksource has been installed. PCI: Bridge: 0000:00:01.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Setting latency timer of device 0000:00:01.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered Simple Boot Flag at 0x3a set to 0x1 Machine check exception polling timer started. highmem bounce pool size: 64 pages SGI XFS with ACLs, no debug enabled io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Boot video device is 0000:00:0a.0 PCI: Bypassing VIA 8237 APIC De-Assert Message atyfb: using auxiliary register aperture atyfb: 3D RAGE II+ (Mach64 GU) [0x4755 rev 0x9a] atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000. atyfb: BIOS frequency table: atyfb: PCLK_min_freq 926, PCLK_max_freq 22216, ref_freq 1432, ref_divider 33 atyfb: MCLK_pwd 4200, MCLK_max_freq 6000, XCLK_max_freq 6000, SCLK_freq 5000 atyfb: 4M EDO, 14.31818 MHz XTAL, 222 MHz PLL, 60 Mhz MCLK, 60 MHz XCLK Console: switching to colour frame buffer device 80x30 atyfb: fb0: ATY Mach64 frame buffer device on PCI input: Power Button (FF) as /class/input/input0 ACPI: Power Button (FF) [PWRF] input: Power Button (CM) as /class/input/input1 ACPI: Power Button (CM) [PWRB] netconsole: not configured, aborting Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:0f.1 ACPI: PCI Interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 16 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:pio, hdd:DMA Probing IDE interface ide0... Switched to high resolution mode on CPU 0 hda: ST320420A, ATA DISK drive hdb: Maxtor 5A300J0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdd: PLEXTOR CD-R PX-W2410A, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 39851760 sectors (20404 MB) w/2048KiB Cache, CHS=39535/16/63, UDMA(66) hda: cache flushes not supported hda: hda1 hda2 hda3 hdb: max request size: 512KiB hdb: 585940320 sectors (300001 MB) w/2048KiB Cache, CHS=36473/255/63, UDMA(133) hdb: cache flushes supported hdb: hdb1 hdb2 hdd: ATAPI 40X CD-ROM CD-R/RW drive, 4096kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 sata_promise 0000:00:0d.0: version 2.07 ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17 scsi0 : sata_promise scsi1 : sata_promise scsi2 : sata_promise scsi3 : sata_promise ata1: SATA max UDMA/133 cmd 0xf880a200 ctl 0xf880a238 bmdma 0x00000000 irq 0 ata2: SATA max UDMA/133 cmd 0xf880a280 ctl 0xf880a2b8 bmdma 0x00000000 irq 0 ata3: SATA max UDMA/133 cmd 0xf880a300 ctl 0xf880a338 bmdma 0x00000000 irq 0 ata4: SATA max UDMA/133 cmd 0xf880a380 ctl 0xf880a3b8 bmdma 0x00000000 irq 0 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata1.00: ATA-7: Maxtor 6B250S0, BANC19J0, max UDMA/133 ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 0/32) ata1.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata1.00: configured for UDMA/133 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata2.00: ATA-7: Maxtor 7Y250M0, YAR51EW0, max UDMA/133 ata2.00: 490234752 sectors, multi 0: LBA48 ata2.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata2.00: configured for UDMA/133 ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata3.00: ATA-7: Maxtor 7Y250M0, YAR51EW0, max UDMA/133 ata3.00: 490234752 sectors, multi 0: LBA48 ata3.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata3.00: configured for UDMA/133 ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata4.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata4.00: ATA-7: Maxtor 6B250S0, BANC1980, max UDMA/133 ata4.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 0/32) ata4.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata4.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA Maxtor 6B250S0 BANC PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 490234752 512-byte hardware sectors (251000 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 490234752 512-byte hardware sectors (251000 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sd 0:0:0:0: [sda] Attached SCSI disk scsi 1:0:0:0: Direct-Access ATA Maxtor 7Y250M0 YAR5 PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 490234752 512-byte hardware sectors (251000 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sdb] 490234752 512-byte hardware sectors (251000 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 1:0:0:0: [sdb] Attached SCSI disk scsi 2:0:0:0: Direct-Access ATA Maxtor 7Y250M0 YAR5 PQ: 0 ANSI: 5 sd 2:0:0:0: [sdc] 490234752 512-byte hardware sectors (251000 MB) sd 2:0:0:0: [sdc] Write Protect is off sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sdc] 490234752 512-byte hardware sectors (251000 MB) sd 2:0:0:0: [sdc] Write Protect is off sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sd 2:0:0:0: [sdc] Attached SCSI disk scsi 3:0:0:0: Direct-Access ATA Maxtor 6B250S0 BANC PQ: 0 ANSI: 5 sd 3:0:0:0: [sdd] 490234752 512-byte hardware sectors (251000 MB) sd 3:0:0:0: [sdd] Write Protect is off sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:0:0:0: [sdd] 490234752 512-byte hardware sectors (251000 MB) sd 3:0:0:0: [sdd] Write Protect is off sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdd: sdd1 sd 3:0:0:0: [sdd] Attached SCSI disk sata_via 0000:00:0f.0: version 2.1 ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 16 sata_via 0000:00:0f.0: routed to hard irq line 0 scsi4 : sata_via scsi5 : sata_via ata5: SATA max UDMA/133 cmd 0x0001b000 ctl 0x0001a802 bmdma 0x00019800 irq 0 ata6: SATA max UDMA/133 cmd 0x0001a400 ctl 0x0001a002 bmdma 0x00019808 irq 0 ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ATA: abnormal status 0x7F on port 0x0001b007 ATA: abnormal status 0x7F on port 0x0001b007 ata5.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata5.00: ATA-7: Maxtor 7B250S0, BANC1980, max UDMA/133 ata5.00: 490234752 sectors, multi 16: LBA48 NCQ (depth 0/32) ata5.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata5.00: configured for UDMA/133 ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ATA: abnormal status 0x7F on port 0x0001a407 ATA: abnormal status 0x7F on port 0x0001a407 ata6.00: ata_hpa_resize 1: sectors = 781422768, hpa_sectors = 781422768 ata6.00: ATA-7: ST3400620AS, 3.AAK, max UDMA/133 ata6.00: 781422768 sectors, multi 16: LBA48 NCQ (depth 0/32) ata6.00: ata_hpa_resize 1: sectors = 781422768, hpa_sectors = 781422768 ata6.00: configured for UDMA/133 scsi 4:0:0:0: Direct-Access ATA Maxtor 7B250S0 BANC PQ: 0 ANSI: 5 sd 4:0:0:0: [sde] 490234752 512-byte hardware sectors (251000 MB) sd 4:0:0:0: [sde] Write Protect is off sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00 sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 4:0:0:0: [sde] 490234752 512-byte hardware sectors (251000 MB) sd 4:0:0:0: [sde] Write Protect is off sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00 sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sde: sde1 sd 4:0:0:0: [sde] Attached SCSI disk scsi 5:0:0:0: Direct-Access ATA ST3400620AS 3.AA PQ: 0 ANSI: 5 sd 5:0:0:0: [sdf] 781422768 512-byte hardware sectors (400088 MB) sd 5:0:0:0: [sdf] Write Protect is off sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 5:0:0:0: [sdf] 781422768 512-byte hardware sectors (400088 MB) sd 5:0:0:0: [sdf] Write Protect is off sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdf: sdf1 sdf2 sd 5:0:0:0: [sdf] Attached SCSI disk pnp: the driver 'i8042 kbd' has been registered pnp: match found with the PnP device '00:0a' and the driver 'i8042 kbd' pnp: the driver 'i8042 aux' has been registered pnp: match found with the PnP device '00:0b' and the driver 'i8042 aux' PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12 serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard as /class/input/input2 md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 raid6: int32x1 806 MB/s raid6: int32x2 1097 MB/s raid6: int32x4 694 MB/s raid6: int32x8 648 MB/s raid6: mmxx1 1683 MB/s raid6: mmxx2 3028 MB/s raid6: sse1x1 1622 MB/s raid6: sse1x2 2655 MB/s raid6: using algorithm sse1x2 (2655 MB/s) md: raid6 personality registered for level 6 md: raid5 personality registered for level 5 md: raid4 personality registered for level 4 raid5: automatically using best checksumming function: pIII_sse pIII_sse : 4201.000 MB/sec raid5: using function: pIII_sse (4201.000 MB/sec) device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com TCP cubic registered Using IPI Shortcut mode input: ImPS/2 Logitech Wheel Mouse as /class/input/input3 md: Autodetecting RAID arrays. md: autorun ... md: considering sdf1 ... md: adding sdf1 ... md: adding sde1 ... md: adding sdd1 ... md: adding sdc1 ... md: adding sdb1 ... md: adding sda1 ... md: adding hdb1 ... md: created md0 md: bind md: bind md: bind md: bind md: bind md: bind md: bind md: running: raid5: device sdf1 operational as raid disk 0 raid5: device sde1 operational as raid disk 1 raid5: device sdd1 operational as raid disk 2 raid5: device sdc1 operational as raid disk 3 raid5: device sdb1 operational as raid disk 4 raid5: device sda1 operational as raid disk 5 raid5: device hdb1 operational as raid disk 6 raid5: allocated 7316kB for md0 raid5: raid level 6 set md0 active with 7 out of 7 devices, algorithm 2 RAID5 conf printout: --- rd:7 wd:7 disk 0, o:1, dev:sdf1 disk 1, o:1, dev:sde1 disk 2, o:1, dev:sdd1 disk 3, o:1, dev:sdc1 disk 4, o:1, dev:sdb1 disk 5, o:1, dev:sda1 disk 6, o:1, dev:hdb1 md0: bitmap initialized from disk: read 15/15 pages, set 2 bits, status: 0 created bitmap (234 pages) for device md0 md: ... autorun DONE. Filesystem "hda2": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda2 Ending clean XFS mount for filesystem: hda2 VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 188k freed NET: Registered protocol family 1 PCI: Enabling device 0000:00:09.0 (0014 -> 0017) ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 18 (level, low) -> IRQ 18 skge 1.11 addr 0xf6000000 irq 18 chip Yukon rev 1 skge eth0: addr 00:0c:6e:f6:47:ee usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb USB Universal Host Controller Interface driver v3.0 ACPI: PCI Interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 19 uhci_hcd 0000:00:10.0: UHCI Host Controller uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1 uhci_hcd 0000:00:10.0: irq 19, io base 0x00008800 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 19 uhci_hcd 0000:00:10.1: UHCI Host Controller uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2 uhci_hcd 0000:00:10.1: irq 19, io base 0x00008400 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected sk98lin: driver has been replaced by the skge driver and is scheduled for removal ACPI: PCI Interrupt 0000:00:10.2[B] -> GSI 21 (level, low) -> IRQ 19 uhci_hcd 0000:00:10.2: UHCI Host Controller uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3 uhci_hcd 0000:00:10.2: irq 19, io base 0x00008000 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:10.3[B] -> GSI 21 (level, low) -> IRQ 19 uhci_hcd 0000:00:10.3: UHCI Host Controller uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4 uhci_hcd 0000:00:10.3: irq 19, io base 0x00007800 usb usb4: configuration #1 chosen from 1 choice hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected vt596_smbus 0000:00:11.0: VT596_smba = 0xE800 i2c-adapter i2c-0: adapter [SMBus Via Pro adapter at e800] registered ACPI: PCI Interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 19 ehci_hcd 0000:00:10.4: EHCI Host Controller ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 5 ehci_hcd 0000:00:10.4: irq 19, io mem 0xf4000000 ehci_hcd 0000:00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb5: configuration #1 chosen from 1 choice hub 5-0:1.0: USB hub found hub 5-0:1.0: 8 ports detected ACPI: PCI Interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:11.5 to 64 codec_read: codec 0 is not valid [0xfe0000] codec_read: codec 0 is not valid [0xfe0000] codec_read: codec 0 is not valid [0xfe0000] codec_read: codec 0 is not valid [0xfe0000] Adding 522100k swap on /dev/hda3. Priority:-1 extents:1 across:522100k Filesystem "hda2": Disabling barriers, not supported by the underlying device i2c-core: driver [eeprom] registered i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x50 i2c-adapter i2c-0: Transaction (pre): STS=42 CNT=14 CMD=00 ADD=a0 DAT=11,00 i2c-adapter i2c-0: SMBus busy (0x42). Resetting... i2c-adapter i2c-0: Transaction (post): STS=00 CNT=00 CMD=00 ADD=a0 DAT=11,00 i2c-adapter i2c-0: Transaction (pre): STS=40 CNT=00 CMD=00 ADD=a0 DAT=11,00 i2c-adapter i2c-0: Transaction (post): STS=00 CNT=00 CMD=00 ADD=a0 DAT=11,00 i2c-adapter i2c-0: client [eeprom] registered with bus id 0-0050 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x51 i2c-adapter i2c-0: Transaction (pre): STS=40 CNT=00 CMD=00 ADD=a2 DAT=11,00 i2c-adapter i2c-0: Transaction (post): STS=00 CNT=00 CMD=00 ADD=a2 DAT=11,00 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x52 i2c-adapter i2c-0: Transaction (pre): STS=40 CNT=00 CMD=00 ADD=a4 DAT=11,00 i2c-adapter i2c-0: Transaction (post): STS=00 CNT=00 CMD=00 ADD=a4 DAT=11,00 i2c-adapter i2c-0: Transaction (pre): STS=40 CNT=00 CMD=00 ADD=a4 DAT=11,00 i2c-adapter i2c-0: Transaction (post): STS=00 CNT=00 CMD=00 ADD=a4 DAT=11,00 i2c-adapter i2c-0: client [eeprom] registered with bus id 0-0052 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x53 i2c-adapter i2c-0: Transaction (pre): STS=40 CNT=00 CMD=00 ADD=a6 DAT=11,00 i2c-adapter i2c-0: Transaction (post): STS=00 CNT=00 CMD=00 ADD=a6 DAT=11,00 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x54 i2c-adapter i2c-0: Transaction (pre): STS=40 CNT=00 CMD=00 ADD=a8 DAT=11,00 i2c-adapter i2c-0: Transaction (post): STS=00 CNT=00 CMD=00 ADD=a8 DAT=11,00 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x55 i2c-adapter i2c-0: Transaction (pre): STS=40 CNT=00 CMD=00 ADD=aa DAT=11,00 i2c-adapter i2c-0: Transaction (post): STS=00 CNT=00 CMD=00 ADD=aa DAT=11,00 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x56 i2c-adapter i2c-0: Transaction (pre): STS=40 CNT=00 CMD=00 ADD=ac DAT=11,00 i2c-adapter i2c-0: Transaction (post): STS=00 CNT=00 CMD=00 ADD=ac DAT=11,00 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x57 i2c-adapter i2c-0: Transaction (pre): STS=40 CNT=00 CMD=00 ADD=ae DAT=11,00 i2c-adapter i2c-0: Transaction (post): STS=00 CNT=00 CMD=00 ADD=ae DAT=11,00 i2c-adapter i2c-9191: ISA main adapter registered it87: Found IT8712F chip at 0x290, revision 5 i2c-adapter i2c-9191: Driver it87-isa registered i2c-adapter i2c-9191: client [it8712] registered with bus id 9191-0290 Installing knfsd (copyright (C) 1996 okir@monad.swb.de). kjournald starting. Commit interval 5 seconds EXT3 FS on hda1, internal journal EXT3-fs: mounted filesystem with ordered data mode. Filesystem "md0": Disabling barriers, not supported by the underlying device XFS mounting filesystem md0 Ending clean XFS mount for filesystem: md0 XFS mounting filesystem hdb2 Ending clean XFS mount for filesystem: hdb2 skge eth0: enabling interface skge eth0: Link is up at 1000 Mbps, full duplex, flow control both [I umount /dev/md0 here and then suspend2disk/resume] swsusp: Basic memory bitmaps created Stopping tasks ... done. Shrinking memory... done (0 pages freed) Freed 0 kbytes in 0.03 seconds (0.00 MB/s) Suspending console(s) sd 5:0:0:0: [sdf] Synchronizing SCSI cache sd 4:0:0:0: [sde] Synchronizing SCSI cache sd 3:0:0:0: [sdd] Synchronizing SCSI cache sd 2:0:0:0: [sdc] Synchronizing SCSI cache sd 1:0:0:0: [sdb] Synchronizing SCSI cache sd 0:0:0:0: [sda] Synchronizing SCSI cache ACPI: PCI interrupt for device 0000:00:11.5 disabled ACPI: PCI interrupt for device 0000:00:10.4 disabled ACPI: PCI interrupt for device 0000:00:10.3 disabled ACPI: PCI interrupt for device 0000:00:10.2 disabled ACPI: PCI interrupt for device 0000:00:10.1 disabled ACPI: PCI interrupt for device 0000:00:10.0 disabled ACPI: PCI interrupt for device 0000:00:0f.0 disabled skge eth0: disabling interface swsusp: critical section: swsusp: Need to copy 34443 pages Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. PCI: Setting latency timer of device 0000:00:01.0 to 64 PM: Writing back config space on device 0000:00:09.0 at offset 1 (was 2b00014, writing 2b00017) skge eth0: enabling interface Clocksource tsc unstable (delta = 4327744420428 ns) ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17 PM: Writing back config space on device 0000:00:0f.0 at offset 1 (was 2900003, writing 2900007) ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 16 ACPI: PCI Interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 16 Time: acpi_pm clocksource has been installed. ACPI: PCI Interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 19 usb usb1: root hub lost power or was reset ACPI: PCI Interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 19 usb usb2: root hub lost power or was reset ACPI: PCI Interrupt 0000:00:10.2[B] -> GSI 21 (level, low) -> IRQ 19 usb usb3: root hub lost power or was reset ACPI: PCI Interrupt 0000:00:10.3[B] -> GSI 21 (level, low) -> IRQ 19 usb usb4: root hub lost power or was reset ACPI: PCI Interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 19 PM: Writing back config space on device 0000:00:10.4 at offset 3 (was 802008, writing 802010) usb usb5: root hub lost power or was reset ACPI: PCI Interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:11.5 to 64 pnp: Res cnt 3 pnp: res cnt 3 pnp: Encode io pnp: Encode io pnp: Encode irq pnp: Failed to activate device 00:0a. pnp: Res cnt 1 pnp: res cnt 1 pnp: Encode irq pnp: Failed to activate device 00:0b. sd 0:0:0:0: [sda] Starting disk sd 1:0:0:0: [sdb] Starting disk sd 2:0:0:0: [sdc] Starting disk sd 3:0:0:0: [sdd] Starting disk sd 4:0:0:0: [sde] Starting disk ATA: abnormal status 0x7F on port 0x0001b007 ATA: abnormal status 0x7F on port 0x0001b007 ATA: abnormal status 0x7F on port 0x0001a407 ATA: abnormal status 0x7F on port 0x0001a407 ata5.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata5.00: ata_hpa_resize 1: sectors = 490234752, hpa_sectors = 490234752 ata5.00: configured for UDMA/133 sd 4:0:0:0: [sde] 490234752 512-byte hardware sectors (251000 MB) sd 5:0:0:0: [sdf] Starting disk sd 4:0:0:0: [sde] Write Protect is off sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00 sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata6.00: ata_hpa_resize 1: sectors = 781422768, hpa_sectors = 781422768 ata6.00: ata_hpa_resize 1: sectors = 781422768, hpa_sectors = 781422768 ata6.00: configured for UDMA/133 sd 5:0:0:0: [sdf] 781422768 512-byte hardware sectors (400088 MB) sd 5:0:0:0: [sdf] Write Protect is off sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Restarting tasks ... done. swsusp: Basic memory bitmaps freed skge eth0: Link is up at 1000 Mbps, full duplex, flow control both [following is the dmesg of 2.6.21 post resume] Stopping tasks ... done. Shrinking memory... done (0 pages freed) Freed 0 kbytes in 0.03 seconds (0.00 MB/s) Suspending console(s) ACPI: PCI interrupt for device 0000:00:11.5 disabled ACPI: PCI interrupt for device 0000:00:10.4 disabled ACPI: PCI interrupt for device 0000:00:10.3 disabled ACPI: PCI interrupt for device 0000:00:10.2 disabled ACPI: PCI interrupt for device 0000:00:10.1 disabled ACPI: PCI interrupt for device 0000:00:10.0 disabled skge eth0: disabling interface swsusp: critical section: swsusp: Need to copy 34078 pages Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. PCI: Setting latency timer of device 0000:00:01.0 to 64 Clocksource tsc unstable (delta = 4337118157984 ns) Time: acpi_pm clocksource has been installed. PM: Writing back config space on device 0000:00:09.0 at offset 1 (was 2b00014, writing 2b00017) skge eth0: enabling interface ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 16 (level, low) -> IRQ 17 ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 16 ACPI: PCI Interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 16 ACPI: PCI Interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 19 usb usb1: root hub lost power or was reset ACPI: PCI Interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 19 usb usb2: root hub lost power or was reset ACPI: PCI Interrupt 0000:00:10.2[B] -> GSI 21 (level, low) -> IRQ 19 usb usb3: root hub lost power or was reset ACPI: PCI Interrupt 0000:00:10.3[B] -> GSI 21 (level, low) -> IRQ 19 usb usb4: root hub lost power or was reset ACPI: PCI Interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 19 PM: Writing back config space on device 0000:00:10.4 at offset 3 (was 802008, writing 802010) usb usb5: root hub lost power or was reset ACPI: PCI Interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 20 PCI: Setting latency timer of device 0000:00:11.5 to 64 pnp: Res cnt 3 pnp: res cnt 3 pnp: Encode io pnp: Encode io pnp: Encode irq pnp: Failed to activate device 00:0a. pnp: Res cnt 1 pnp: res cnt 1 pnp: Encode irq pnp: Failed to activate device 00:0b. logips2pp: Detected unknown logitech mouse model 1 Restarting tasks ... done. skge eth0: Link is up at 1000 Mbps, full duplex, flow control both From owner-xfs@oss.sgi.com Wed Jun 6 10:18:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Jun 2007 10:18:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_50,FH_HOST_EQ_D_D_D_D, FH_HOST_EQ_D_D_D_DB,RDNS_DYNAMIC autolearn=no version=3.2.0-pre1-r499012 Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l56HIGWt008456 for ; Wed, 6 Jun 2007 10:18:17 -0700 Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id l56HHq9r012920 for ; Wed, 6 Jun 2007 10:17:52 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id l56HICDM007023 for ; Wed, 6 Jun 2007 10:18:12 -0700 Received: from [127.0.0.1] ([10.123.0.56]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 10:18:34 -0700 Message-ID: <4666EC56.9000606@agami.com> Date: Wed, 06 Jun 2007 10:18:14 -0700 From: Michael Nishimoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com Subject: Re: Reducing memory requirements for high extent xfs files References: <200705301649.l4UGnckA027406@oss.sgi.com> <20070530225516.GB85884050@sgi.com> <4665E276.9020406@agami.com> <20070606013601.GR86004887@sgi.com> In-Reply-To: <20070606013601.GR86004887@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2007 17:18:35.0049 (UTC) FILETIME=[B6CAE190:01C7A85E] X-Scanned-By: MIMEDefang 2.58 on 192.168.168.13 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11667 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miken@agami.com Precedence: bulk X-list: xfs David Chinner wrote: > On Tue, Jun 05, 2007 at 03:23:50PM -0700, Michael Nishimoto wrote: > > David Chinner wrote: > > >On Wed, May 30, 2007 at 09:49:38AM -0700, Michael Nishimoto wrote: > > > > Hello, > > > > > > > > Has anyone done any work or had thoughts on changes required > > > > to reduce the total memory footprint of high extent xfs files? > ..... > > >Yes, it could, but that's a pretty major overhaul of the extent > > >interface which currently assumes everywhere that the entire > > >extent tree is in core. > > > > > >Can you describe the problem you are seeing that leads you to > > >ask this question? What's the problem you need to solve? > > > > I realize that this work won't be trivial which is why I asked if anyone > > has thought about all relevant issues. > > > > When using NFS over XFS, slowly growing files (can be ascii log files) > > tend to fragment quite a bit. > > Oh, that problem. > > The issue is that allocation beyond EOF (the normal way we prevent > fragmentation in this case) gets truncated off on file close. > > Even NFS request is processed by doing: > > open > write > close > > And so XFS truncates the allocation beyond EOF on close. Hence > the next write requires a new allocation and that results in > a non-contiguous file because the adjacent blocks have already > been used.... > Yes, we diagnosed this same issue. > > Options: > > 1 NFS server open file cache to avoid the close. > 2 add detection to XFS to determine if the called is > an NFS thread and don't truncate on close. > 3 use preallocation. > 4 preallocation on the file once will result in the > XFS_DIFLAG_PREALLOC being set on the inode and it > won't truncate on close. > 5 append only flag will work in the same way as the > prealloc flag w.r.t preventing truncation on close. > 6 run xfs_fsr > We have discussed doing number 1. The problem with number 2, 3, 4, & 5 is that we ended up with a bunch of files which appeared to leak space. If the truncate isn't done at file close time, the extra space sits around forever. > > Note - i don't think extent size hints alone will help as they > don't prevent EOF truncation on close. > > > One system had several hundred files > > which required more than one page to store the extents. > > I don't consider that a problem as such. We'll always get some > level of fragmentation if we don't preallocate. > > > Quite a few > > files had extent counts greater than 10k, and one file had 120k extents. > > you should run xfs_fsr occassionally.... > > > Besides the memory consumption, latency to return the first byte of the > > file can get noticeable. > > Yes, that too :/ > > However, I think we should be trying to fix the root cause of this > worst case fragmentation rather than trying to make the rest of the > filesystem accommodate an extreme corner case efficiently. i.e. > let's look at the test cases and determine what piece of logic we > need to add or remove to prevent this cause of fragmentation. > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > I guess there are multiple ways to look at this problem. I have been going under the assumption that xfs' inability to handle a large number of extents is the root cause. When a filesystem is full, defragmentation might not be possible. Also, should we consider a file with 1MB extents as fragmented? A 100GB file with 1MB extents has 100k extents. As disks and, hence, filesystems get larger, it's possible to have a larger number of such files in a filesystem. I still think that trying to not fragment up front is required as well as running xfs_fsr, but I don't think those alone can be a complete solution. Getting back to the original question, has there ever been serious thought in what it might take to handle large extent files? What might be involved with trying to page extent blocks? I'm most concerned about the potential locking consequences and streaming performance implications. thanks, Michael From owner-xfs@oss.sgi.com Wed Jun 6 16:47:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Jun 2007 16:47:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l56NleWt018353 for ; Wed, 6 Jun 2007 16:47:42 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA15787; Thu, 7 Jun 2007 09:47:31 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l56NlTAf116274519; Thu, 7 Jun 2007 09:47:30 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l56NlN7Y116352085; Thu, 7 Jun 2007 09:47:23 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 7 Jun 2007 09:47:23 +1000 From: David Chinner To: Michael Nishimoto Cc: David Chinner , xfs@oss.sgi.com Subject: Re: Reducing memory requirements for high extent xfs files Message-ID: <20070606234723.GC86004887@sgi.com> References: <200705301649.l4UGnckA027406@oss.sgi.com> <20070530225516.GB85884050@sgi.com> <4665E276.9020406@agami.com> <20070606013601.GR86004887@sgi.com> <4666EC56.9000606@agami.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4666EC56.9000606@agami.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11668 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Jun 06, 2007 at 10:18:14AM -0700, Michael Nishimoto wrote: > David Chinner wrote: > >On Tue, Jun 05, 2007 at 03:23:50PM -0700, Michael Nishimoto wrote: > >> When using NFS over XFS, slowly growing files (can be ascii log files) > >> tend to fragment quite a bit. > > > >Oh, that problem. ..... > >And so XFS truncates the allocation beyond EOF on close. Hence > >the next write requires a new allocation and that results in > >a non-contiguous file because the adjacent blocks have already > >been used.... > > > Yes, we diagnosed this same issue. > > >Options: > > > > 1 NFS server open file cache to avoid the close. > > 2 add detection to XFS to determine if the called is > > an NFS thread and don't truncate on close. > > 3 use preallocation. > > 4 preallocation on the file once will result in the > > XFS_DIFLAG_PREALLOC being set on the inode and it > > won't truncate on close. > > 5 append only flag will work in the same way as the > > prealloc flag w.r.t preventing truncation on close. > > 6 run xfs_fsr > > > We have discussed doing number 1. So has the community - there may even be patches floating around... > The problem with number 2, > 3, 4, & 5 is that we ended up with a bunch of files which appeared > to leak space. If the truncate isn't done at file close time, the extra > space sits around forever. That's not a problem for slowly growing log files - they will eventually use the space. I'm not saying that the truncate should be avoided on all files, just the slow growing ones that get fragmented.... > >However, I think we should be trying to fix the root cause of this > >worst case fragmentation rather than trying to make the rest of the > >filesystem accommodate an extreme corner case efficiently. i.e. > >let's look at the test cases and determine what piece of logic we > >need to add or remove to prevent this cause of fragmentation. > I guess there are multiple ways to look at this problem. I have been > going under the assumption that xfs' inability to handle a large number > of extents is the root cause. Fair enough. > When a filesystem is full, defragmentation > might not be possible. Yes, that's true. > Also, should we consider a file with 1MB extents as > fragmented? A 100GB file with 1MB extents has 100k extents. Yes, that's fragmented - it has 4 orders of magnitude more extents than optimal - and the extents are too small to allow reads or writes to acheive full bandwidth on high end raid configs.... > As disks > and, hence, filesystems get larger, it's possible to have a larger number > of such files in a filesystem. Yes. But as disks get larger, there's more space available from which to allocate contiguous ranges and so that sort of problem is less likely to occur (until filesytsem gets full). > I still think that trying to not fragment up front is required as well > as running > xfs_fsr, but I don't think those alone can be a complete solution. > > Getting back to the original question, has there ever been serious thought > in what it might take to handle large extent files? Yes, I've thought about it from a relatively high level, but enough to indicate real problems that breed complexity. > What might be involved > with trying to page extent blocks? - Rewriting all of the incore extent handling code to support missing extent ranges (currently uses deltas from the previous block for file offset). - changing the bmap btree code to convert to incore, uncompressed format on a block by block basis rather than into a global table - add code to demand read the extent list - needs to use cursors to pin blocks in memory while doing traversals - needs to work in ENOMEM conditions - convert xfs_buf.c to be able to use mempools for both xfs_buf_t and block dev page cache so that we can read blocks when ENOMEM in the writeback path - convert in-core extent structures to use mempools so we can read blocks when -ENOMEM in the writeback path - any new allocated structures will also have to use mempools - add memory shaker interfaces > I'm most concerned about the potential locking consequences and streaming > performance implications. In reality, the worst problem is writeback at ENOMEM. Who cares about locking and performance if it's fundamentally unworkable when the machine is out of memory? Even using mempools we may not be able to demand page extent blocks safely in all cases. This is my big worry about it, and the more I thought about it, the less that demand paging made sense - it gets horrendously complex when you have to start playing by mempool rules and given that the lifetime of modified buffers is determined by the log and AIL flushing behaviour we have serious problems guaranteeing when objects would be returned to the mempool. This is a showstopper issue, IMO. I'm happy to be proven wrong, but it looks *extremely* messy and complex at this point.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Jun 6 23:44:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Jun 2007 23:44:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l576hxWt020613 for ; Wed, 6 Jun 2007 23:44:02 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA25574; Thu, 7 Jun 2007 16:43:55 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l576hrAf116326687; Thu, 7 Jun 2007 16:43:55 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l576hq5k115417772; Thu, 7 Jun 2007 16:43:52 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 7 Jun 2007 16:43:52 +1000 From: David Chinner To: xfs-dev Cc: xfs-oss Subject: review: fix i386 build Message-ID: <20070607064352.GN86004887@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11669 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Don't use type-unsafe macros. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/dmapi/xfs_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/dmapi/xfs_dm.c 2007-06-06 15:55:00.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c 2007-06-06 15:56:00.613530262 +1000 @@ -2654,7 +2654,7 @@ xfs_dm_punch_hole( * make sure we punch the block and not just zero it. */ if (punch_to_eof) - len = roundup((realsize - off), bsize); + len = roundup_64((realsize - off), bsize); xfs_iunlock(xip, XFS_ILOCK_EXCL); From owner-xfs@oss.sgi.com Thu Jun 7 00:03:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 00:03:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l5773oWt032118 for ; Thu, 7 Jun 2007 00:03:52 -0700 Received: from [134.15.64.54] (cf-vpn-sw-corp-64-54.corp.sgi.com [134.15.64.54]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA26284; Thu, 7 Jun 2007 17:03:35 +1000 Message-ID: <4667ADAF.7000904@sgi.com> Date: Thu, 07 Jun 2007 17:03:11 +1000 From: Tim Shimmin User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: xfs-dev@sgi.com CC: xfs@oss.sgi.com Subject: review: xfs_growfs_data_private() not logging agf length change Content-Type: multipart/mixed; boundary="------------000807030904070307000007" X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11670 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------000807030904070307000007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Looks like we forgot to log the agf_length change here. (cut 'n' pasted patch) --Tim =========================================================================== Index: fs/xfs/xfs_fsops.c =========================================================================== --- a/fs/xfs/xfs_fsops.c 2007-04-17 18:02:46.000000000 +1000 +++ b/fs/xfs/xfs_fsops.c 2007-04-17 17:59:44.467987572 +1000 @@ -328,6 +328,7 @@ xfs_growfs_data_private( be32_add(&agf->agf_length, new); ASSERT(be32_to_cpu(agf->agf_length) == be32_to_cpu(agi->agi_length)); + xfs_alloc_log_agf(tp, bp, XFS_AGF_LENGTH); /* * Free the new space. */ --------------000807030904070307000007 Content-Type: text/plain; name="agf_length.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="agf_length.patch" --- .pc/agf_length.patch/fs/xfs/xfs_fsops.c 2007-06-07 16:19:27.000000000 +1000 +++ fs/xfs/xfs_fsops.c 2007-06-07 16:23:41.302363734 +1000 @@ -332,6 +332,7 @@ xfs_growfs_data_private( be32_add(&agf->agf_length, new); ASSERT(be32_to_cpu(agf->agf_length) == be32_to_cpu(agi->agi_length)); + xfs_alloc_log_agf(tp, bp, XFS_AGF_LENGTH); /* * Free the new space. */ --------------000807030904070307000007-- From owner-xfs@oss.sgi.com Thu Jun 7 00:30:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 00:30:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l577UkWt011519 for ; Thu, 7 Jun 2007 00:30:49 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA27101; Thu, 7 Jun 2007 17:30:36 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l577UZAf114495412; Thu, 7 Jun 2007 17:30:36 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l577UYRL113570304; Thu, 7 Jun 2007 17:30:34 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 7 Jun 2007 17:30:34 +1000 From: David Chinner To: Tim Shimmin Cc: xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: review: xfs_growfs_data_private() not logging agf length change Message-ID: <20070607073034.GP86004887@sgi.com> References: <4667ADAF.7000904@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4667ADAF.7000904@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11671 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Jun 07, 2007 at 05:03:11PM +1000, Tim Shimmin wrote: > Looks like we forgot to log the agf_length change here. > > (cut 'n' pasted patch) > > --Tim > > =========================================================================== > Index: fs/xfs/xfs_fsops.c > =========================================================================== > > --- a/fs/xfs/xfs_fsops.c 2007-04-17 18:02:46.000000000 +1000 > +++ b/fs/xfs/xfs_fsops.c 2007-04-17 17:59:44.467987572 +1000 > @@ -328,6 +328,7 @@ xfs_growfs_data_private( > be32_add(&agf->agf_length, new); > ASSERT(be32_to_cpu(agf->agf_length) == > be32_to_cpu(agi->agi_length)); > + xfs_alloc_log_agf(tp, bp, XFS_AGF_LENGTH); > /* > * Free the new space. > */ Yup, looks ok to me. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jun 7 00:57:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 00:57:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_80,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from bay0-omc2-s6.bay0.hotmail.com (bay0-omc2-s6.bay0.hotmail.com [65.54.246.142]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l577vKWt018537 for ; Thu, 7 Jun 2007 00:57:21 -0700 Received: from hotmail.com ([65.54.174.79]) by bay0-omc2-s6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 7 Jun 2007 00:45:19 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 Jun 2007 00:45:19 -0700 Message-ID: Received: from 85.36.106.198 by BAY103-DAV7.phx.gbl with DAV; Thu, 07 Jun 2007 07:45:16 +0000 X-Originating-IP: [85.36.106.198] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: "David Chinner" Cc: "David Chinner" , , , "Marco Berizzi" References: <20070316012520.GN5743@melbourne.sgi.com> <20070316195951.GB5743@melbourne.sgi.com> <20070320064632.GO32602149@melbourne.sgi.com> Subject: Re: XFS internal error xfs_da_do_buf(2) at line 2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b00bd Date: Thu, 7 Jun 2007 09:44:51 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 07 Jun 2007 07:45:19.0188 (UTC) FILETIME=[CBACC140:01C7A8D7] X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11672 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs Hi David. Three months ago I wrote the message below. I had built various 2.6.20.x and 2.6.21.x vanilla kernel with all the debug options enabled and linux had never crashed. On june 4, I have builded linux 2.6.21.3 without any debugging options and after 2 days linux has starting print these errors: Jun 6 09:47:09 Pleiadi kernel: ======================= Jun 6 09:47:09 Pleiadi kernel: 0x0: 28 f1 45 d4 22 53 35 11 09 80 37 5a 47 8a 22 ee Jun 6 09:47:09 Pleiadi kernel: Filesystem "sda8": XFS internal error xfs_da_do_buf(2) at line 2086 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b2301 Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_do_buf+0x70c/0x7b1 Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_read_buf+0x30/0x35 Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_read_buf+0x30/0x35 Jun 6 09:47:09 Pleiadi kernel: [] _xfs_buf_lookup_pages+0x1e8/0x2ea Jun 6 09:47:09 Pleiadi kernel: [] _xfs_buf_initialize+0xc8/0xf6 Jun 6 09:47:09 Pleiadi kernel: [] xfs_trans_unreserve_and_mod_sb+0x241/0x264 Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_read_buf+0x30/0x35 Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_leaf_lookup_int+0x5c/0x2b6 Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_leaf_lookup_int+0x5c/0x2b6 Jun 6 09:47:09 Pleiadi kernel: [] __next_cpu+0x12/0x1f Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_leaf_lookup+0x2b/0xe2 Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_isleaf+0x1a/0x4f Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir_lookup+0xc1/0x11d Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir_lookup_int+0x34/0x10e Jun 6 09:47:09 Pleiadi kernel: [] _xfs_trans_commit+0x1c7/0x3a2 Jun 6 09:47:09 Pleiadi kernel: [] xfs_lookup+0x5a/0x90 Jun 6 09:47:09 Pleiadi kernel: [] xfs_vn_lookup+0x52/0x93 Jun 6 09:47:09 Pleiadi kernel: [] real_lookup+0xbb/0x116 Jun 6 09:47:09 Pleiadi kernel: [] do_lookup+0x90/0xc2 Jun 6 09:47:09 Pleiadi kernel: [] xfs_vn_lookup+0x0/0x93 Jun 6 09:47:09 Pleiadi kernel: [] __link_path_walk+0x10c/0xcf1 Jun 6 09:47:09 Pleiadi kernel: [] pipe_read+0x23b/0x2bf Jun 6 09:47:09 Pleiadi kernel: [] link_path_walk+0x3e/0xac Jun 6 09:47:09 Pleiadi kernel: [] vfs_read+0xee/0x141 Jun 6 09:47:09 Pleiadi kernel: [] sys_read+0x41/0x6a Jun 6 09:47:09 Pleiadi kernel: [] do_path_lookup+0x11a/0x1ba Jun 6 09:47:09 Pleiadi kernel: [] do_unlinkat+0x41/0x114 Jun 6 09:47:09 Pleiadi kernel: [] vfs_read+0xee/0x141 Jun 6 09:47:09 Pleiadi kernel: [] sys_read+0x41/0x6a Jun 6 09:47:09 Pleiadi kernel: [] syscall_call+0x7/0xb Jun 6 09:47:09 Pleiadi kernel: ======================= PS: I haven't rebooted the system. It is printing this message every few seconds on the console: Filesystem "sda8": XFS internal error xfs_da_do_buf(2) at line 2086 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b2301 Here is dmesg output: Jun 4 20:53:05 Pleiadi kernel: sanitize start Jun 4 20:53:05 Pleiadi kernel: sanitize end Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 0000000000000000 size: 000000000009ac00 end: 000000000009ac00 type: 1 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() type is E820_RAM Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 000000000009ac00 size: 0000000000005400 end: 00000000000a0000 type: 2 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 00000000000ce000 size: 0000000000002000 end: 00000000000d0000 type: 2 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 00000000000e0000 size: 0000000000020000 end: 0000000000100000 type: 2 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 0000000000100000 size: 000000003fdf0000 end: 000000003fef0000 type: 1 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() type is E820_RAM Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 000000003fef0000 size: 000000000000b000 end: 000000003fefb000 type: 3 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 000000003fefb000 size: 0000000000005000 end: 000000003ff00000 type: 4 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 000000003ff00000 size: 0000000000080000 end: 000000003ff80000 type: 1 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() type is E820_RAM Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 000000003ff80000 size: 0000000000080000 end: 0000000040000000 type: 2 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 00000000e0000000 size: 0000000010000000 end: 00000000f0000000 type: 2 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 00000000fec00000 size: 0000000000100400 end: 00000000fed00400 type: 2 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 00000000fee00000 size: 0000000000100000 end: 00000000fef00000 type: 2 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 00000000ffb00000 size: 0000000000100000 end: 00000000ffc00000 type: 2 Jun 4 20:53:05 Pleiadi kernel: copy_e820_map() start: 00000000fff00000 size: 0000000000100000 end: 0000000100000000 type: 2 Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 0000000000000000 - 000000000009ac00 (usable) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 000000000009ac00 - 00000000000a0000 (reserved) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 00000000000ce000 - 00000000000d0000 (reserved) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 0000000000100000 - 000000003fef0000 (usable) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 000000003fef0000 - 000000003fefb000 (ACPI data) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 000000003fefb000 - 000000003ff00000 (ACPI NVS) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 000000003ff00000 - 000000003ff80000 (usable) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 00000000ffb00000 - 00000000ffc00000 (reserved) Jun 4 20:53:05 Pleiadi kernel: BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) Jun 4 20:53:05 Pleiadi kernel: Zone PFN ranges: Jun 4 20:53:05 Pleiadi kernel: DMA 0 -> 4096 Jun 4 20:53:05 Pleiadi kernel: Normal 4096 -> 229376 Jun 4 20:53:05 Pleiadi kernel: HighMem 229376 -> 262016 Jun 4 20:53:05 Pleiadi kernel: early_node_map[1] active PFN ranges Jun 4 20:53:05 Pleiadi kernel: 0: 0 -> 262016 Jun 4 20:53:05 Pleiadi kernel: ACPI: RSDP 000F6BA0, 0024 (r2 PTLTD ) Jun 4 20:53:05 Pleiadi kernel: ACPI: XSDT 3FEF5381, 004C (r1 PTLTD ^I XSDT 6040001 LTP 0) Jun 4 20:53:05 Pleiadi kernel: ACPI: FACP 3FEF5441, 00F4 (r3 FSC 6040001 F4240) Jun 4 20:53:05 Pleiadi kernel: ACPI: DSDT 3FEF5535, 597B (r1 FSC D1649 6040001 MSFT 2000002) Jun 4 20:53:05 Pleiadi kernel: ACPI: FACS 3FEFBFC0, 0040 Jun 4 20:53:05 Pleiadi kernel: ACPI: SPCR 3FEFAEB0, 0050 (r1 PTLTD $UCRTBL$ 6040001 PTL 1) Jun 4 20:53:05 Pleiadi kernel: ACPI: MCFG 3FEFAF00, 0040 (r1 PTLTD MCFG 6040001 LTP 0) Jun 4 20:53:05 Pleiadi kernel: ACPI: APIC 3FEFAF40, 0098 (r1 PTLTD ^I APIC 6040001 LTP 0) Jun 4 20:53:05 Pleiadi kernel: ACPI: BOOT 3FEFAFD8, 0028 (r1 PTLTD $SBFTBL$ 6040001 LTP 1) Jun 4 20:53:05 Pleiadi kernel: Processor #0 15:4 APIC version 20 Jun 4 20:53:05 Pleiadi kernel: Processor #1 15:4 APIC version 20 Jun 4 20:53:05 Pleiadi kernel: IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 Jun 4 20:53:05 Pleiadi kernel: IOAPIC[1]: apic_id 3, version 32, address 0xfec80000, GSI 24-47 Jun 4 20:53:05 Pleiadi kernel: IOAPIC[2]: apic_id 4, version 32, address 0xfec80800, GSI 48-71 Jun 4 20:53:05 Pleiadi kernel: IOAPIC[3]: apic_id 5, version 32, address 0xfec84000, GSI 72-95 Jun 4 20:53:05 Pleiadi kernel: IOAPIC[4]: apic_id 6, version 32, address 0xfec84800, GSI 96-119 Jun 4 20:53:05 Pleiadi kernel: Enabling APIC mode: Flat. Using 5 I/O APICs Jun 4 20:53:05 Pleiadi kernel: Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000) Jun 4 20:53:05 Pleiadi kernel: Built 1 zonelists. Total pages: 259969 Jun 4 20:53:05 Pleiadi kernel: PID hash table entries: 4096 (order: 12, 16384 bytes) Jun 4 20:53:05 Pleiadi kernel: Detected 3200.428 MHz processor. Jun 4 20:53:05 Pleiadi kernel: Console: colour VGA+ 80x25 Jun 4 20:53:05 Pleiadi kernel: Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Jun 4 20:53:05 Pleiadi kernel: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Jun 4 20:53:05 Pleiadi kernel: virtual kernel memory layout: Jun 4 20:53:05 Pleiadi kernel: fixmap : 0xfff9d000 - 0xfffff000 ( 392 kB) Jun 4 20:53:05 Pleiadi kernel: pkmap : 0xff800000 - 0xffc00000 (4096 kB) Jun 4 20:53:05 Pleiadi kernel: vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) Jun 4 20:53:05 Pleiadi kernel: lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) Jun 4 20:53:05 Pleiadi kernel: .init : 0xc039f000 - 0xc03ce000 ( 188 kB) Jun 4 20:53:05 Pleiadi kernel: .data : 0xc02fd400 - 0xc0398114 ( 619 kB) Jun 4 20:53:05 Pleiadi kernel: .text : 0xc0100000 - 0xc02fd400 (2037 kB) Jun 4 20:53:05 Pleiadi kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok. Jun 4 20:53:05 Pleiadi kernel: Calibrating delay using timer specific routine.. 6403.78 BogoMIPS (lpj=32018905) Jun 4 20:53:05 Pleiadi kernel: Mount-cache hash table entries: 512 Jun 4 20:53:05 Pleiadi kernel: monitor/mwait feature present. Jun 4 20:53:05 Pleiadi kernel: using mwait in idle threads. Jun 4 20:53:05 Pleiadi kernel: CPU0: Intel(R) Xeon(TM) CPU 3.20GHz stepping 0a Jun 4 20:53:05 Pleiadi kernel: Booting processor 1/1 eip 2000 Jun 4 20:53:05 Pleiadi kernel: Calibrating delay using timer specific routine.. 6400.45 BogoMIPS (lpj=32002267) Jun 4 20:53:05 Pleiadi kernel: monitor/mwait feature present. Jun 4 20:53:05 Pleiadi kernel: CPU1: Intel(R) Xeon(TM) CPU 3.20GHz stepping 0a Jun 4 20:53:05 Pleiadi kernel: ENABLING IO-APIC IRQs Jun 4 20:53:05 Pleiadi kernel: migration_cost=142 Jun 4 20:53:05 Pleiadi kernel: Setting up standard PCI resources Jun 4 20:53:05 Pleiadi kernel: ACPI: Device [PS2M] status [00000008]: functional but not present; setting present Jun 4 20:53:05 Pleiadi kernel: ACPI: Device [ECP] status [00000008]: functional but not present; setting present Jun 4 20:53:05 Pleiadi kernel: ACPI: Device [COM1] status [00000008]: functional but not present; setting present Jun 4 20:53:05 Pleiadi kernel: PCI quirk: region f000-f07f claimed by ICH4 ACPI/GPIO/TCO Jun 4 20:53:05 Pleiadi kernel: PCI quirk: region f180-f1bf claimed by ICH4 GPIO Jun 4 20:53:05 Pleiadi kernel: PCI: PXH quirk detected, disabling MSI for SHPC device Jun 4 20:53:05 Pleiadi kernel: PCI: PXH quirk detected, disabling MSI for SHPC device Jun 4 20:53:05 Pleiadi kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) Jun 4 20:53:05 Pleiadi kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) Jun 4 20:53:05 Pleiadi kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) Jun 4 20:53:05 Pleiadi kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) Jun 4 20:53:05 Pleiadi kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. Jun 4 20:53:05 Pleiadi kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. Jun 4 20:53:05 Pleiadi kernel: ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. Jun 4 20:53:05 Pleiadi kernel: ACPI: PCI Interrupt Link [LNKH] (IRQs 3 *4 5 6 7 9 10 11 12 14 15) Jun 4 20:53:05 Pleiadi kernel: IP route cache hash table entries: 32768 (order: 5, 131072 bytes) Jun 4 20:53:05 Pleiadi kernel: TCP established hash table entries: 131072 (order: 8, 1572864 bytes) Jun 4 20:53:05 Pleiadi kernel: TCP bind hash table entries: 65536 (order: 7, 524288 bytes) Jun 4 20:53:05 Pleiadi kernel: highmem bounce pool size: 64 pages Jun 4 20:53:05 Pleiadi kernel: PNP: PS/2 controller doesn't have AUX irq; using default 12 Jun 4 20:53:05 Pleiadi kernel: nf_conntrack version 0.5.0 (8188 buckets, 65504 max) Jun 4 20:53:05 Pleiadi kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Jun 4 20:53:05 Pleiadi kernel: Using IPI Shortcut mode Jun 4 20:53:05 Pleiadi kernel: VFS: Mounted root (xfs filesystem) readonly. Jun 6 09:47:09 Pleiadi kernel: 0x0: 28 f1 45 d4 22 53 35 11 09 80 37 5a 47 8a 22 ee Jun 6 09:47:09 Pleiadi kernel: Filesystem "sda8": XFS internal error xfs_da_do_buf(2) at line 2086 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b2301 Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_do_buf+0x70c/0x7b1 Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_read_buf+0x30/0x35 Jun 6 09:47:09 Pleiadi last message repeated 2 times Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_leaf_lookup_int+0x5c/0x2b6 Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_leaf_lookup_int+0x5c/0x2b6 Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_leaf_lookup+0x2b/0xe2 Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_isleaf+0x1a/0x4f Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir_lookup+0xc1/0x11d Jun 6 09:47:09 Pleiadi kernel: [] __block_commit_write+0x7d/0xb0 Jun 6 09:47:09 Pleiadi kernel: [] generic_file_buffered_write+0x2d1/0x682 Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir_lookup_int+0x34/0x10e Jun 6 09:47:09 Pleiadi kernel: [] xfs_lookup+0x5a/0x90 Jun 6 09:47:09 Pleiadi kernel: [] xfs_vn_lookup+0x52/0x93 Jun 6 09:47:09 Pleiadi kernel: [] real_lookup+0xbb/0x116 Jun 6 09:47:09 Pleiadi kernel: [] do_lookup+0x90/0xc2 Jun 6 09:47:09 Pleiadi kernel: [] xfs_vn_lookup+0x0/0x93 Jun 6 09:47:09 Pleiadi kernel: [] __link_path_walk+0x10c/0xcf1 Jun 6 09:47:09 Pleiadi kernel: [] link_path_walk+0x3e/0xac Jun 6 09:47:09 Pleiadi kernel: [] get_unused_fd+0x2e/0xb6 Jun 6 09:47:09 Pleiadi kernel: [] do_path_lookup+0x11a/0x1ba Jun 6 09:47:09 Pleiadi kernel: [] __path_lookup_intent_open+0x50/0x90 Jun 6 09:47:09 Pleiadi kernel: [] path_lookup_open+0x20/0x25 Jun 6 09:47:09 Pleiadi kernel: [] open_namei+0x7a/0x550 Jun 6 09:47:09 Pleiadi kernel: [] do_wp_page+0x20e/0x3ec Jun 6 09:47:09 Pleiadi kernel: [] do_filp_open+0x2e/0x5b Jun 6 09:47:09 Pleiadi kernel: [] get_unused_fd+0x2e/0xb6 Jun 6 09:47:09 Pleiadi kernel: [] do_sys_open+0x4e/0xdb Jun 6 09:47:09 Pleiadi kernel: [] sys_open+0x1c/0x20 Jun 6 09:47:09 Pleiadi kernel: [] syscall_call+0x7/0xb Jun 6 09:47:09 Pleiadi kernel: ======================= Jun 6 09:47:09 Pleiadi kernel: 0x0: 28 f1 45 d4 22 53 35 11 09 80 37 5a 47 8a 22 ee Jun 6 09:47:09 Pleiadi kernel: Filesystem "sda8": XFS internal error xfs_da_do_buf(2) at line 2086 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b2301 Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_do_buf+0x70c/0x7b1 Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_read_buf+0x30/0x35 Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_read_buf+0x30/0x35 Jun 6 09:47:09 Pleiadi kernel: [] _xfs_buf_lookup_pages+0x1e8/0x2ea Jun 6 09:47:09 Pleiadi kernel: [] _xfs_buf_initialize+0xc8/0xf6 Jun 6 09:47:09 Pleiadi kernel: [] xfs_trans_unreserve_and_mod_sb+0x241/0x264 Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_read_buf+0x30/0x35 Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_leaf_lookup_int+0x5c/0x2b6 Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_leaf_lookup_int+0x5c/0x2b6 Jun 6 09:47:09 Pleiadi kernel: [] __next_cpu+0x12/0x1f Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_leaf_lookup+0x2b/0xe2 Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir2_isleaf+0x1a/0x4f Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir_lookup+0xc1/0x11d Jun 6 09:47:09 Pleiadi kernel: [] xfs_dir_lookup_int+0x34/0x10e Jun 6 09:47:09 Pleiadi kernel: [] _xfs_trans_commit+0x1c7/0x3a2 Jun 6 09:47:09 Pleiadi kernel: [] xfs_lookup+0x5a/0x90 Jun 6 09:47:09 Pleiadi kernel: [] xfs_vn_lookup+0x52/0x93 Jun 6 09:47:09 Pleiadi kernel: [] real_lookup+0xbb/0x116 Jun 6 09:47:09 Pleiadi kernel: [] do_lookup+0x90/0xc2 Jun 6 09:47:09 Pleiadi kernel: [] xfs_vn_lookup+0x0/0x93 Jun 6 09:47:09 Pleiadi kernel: [] __link_path_walk+0x10c/0xcf1 Jun 6 09:47:09 Pleiadi kernel: [] pipe_read+0x23b/0x2bf Jun 6 09:47:09 Pleiadi kernel: [] link_path_walk+0x3e/0xac Jun 6 09:47:09 Pleiadi kernel: [] vfs_read+0xee/0x141 Jun 6 09:47:09 Pleiadi kernel: [] sys_read+0x41/0x6a Jun 6 09:47:09 Pleiadi kernel: [] do_path_lookup+0x11a/0x1ba Jun 6 09:47:09 Pleiadi kernel: [] do_unlinkat+0x41/0x114 Jun 6 09:47:09 Pleiadi kernel: [] vfs_read+0xee/0x141 Jun 6 09:47:09 Pleiadi kernel: [] sys_read+0x41/0x6a Jun 6 09:47:09 Pleiadi kernel: [] syscall_call+0x7/0xb Jun 6 09:47:09 Pleiadi kernel: ======================= .. David Chinner wrote: > On Mon, Mar 19, 2007 at 11:32:27AM +0100, Marco Berizzi wrote: > > Marco Berizzi wrote: > > > David Chinner wrote: > > > > > >> Ok, so an ipsec change. And I see from the history below it > > >> really has nothing to do with this problem. it seems the problem > > >> has something to do with changes between 2.6.19.1 and 2.6.19.2. > > > > > > indeed. Yesterday at 13:00 I have switched from 2.6.19.1 to 2.6.19.2 > > > (without the ipsec fix) and at about 17:30 linux has crashed again. > > > I have recompiled 2.6.19.2 with all kernel debugging options enabled > > > and rebooted. Now I'm waiting for the crash... > > > > Linux has not been crashed. However here is dmesg output > > with all debugging option enabled: (search for 'INFO: > > possible recursive locking detected'). Is that normal? > > ..... > > ============================================= > > [ INFO: possible recursive locking detected ] > > 2.6.19.2 #1 > > --------------------------------------------- > > rm/470 is trying to acquire lock: > > (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x5b/0xa1 > > > > but task is already holding lock: > > (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x5b/0xa1 > > > > other info that might help us debug this: > > 3 locks held by rm/470: > > #0: (&inode->i_mutex/1){--..}, at: [] do_unlinkat+0x70/0x115 > > #1: (&inode->i_mutex){--..}, at: [] mutex_lock+0x1c/0x1f > > #2: (&(&ip->i_lock)->mr_lock){----}, at: [] > > xfs_ilock+0x5b/0xa1 > > > > stack backtrace: > > [] dump_trace+0x215/0x21a > > [] show_trace_log_lvl+0x1a/0x30 > > [] show_trace+0x12/0x14 > > [] dump_stack+0x19/0x1b > > [] print_deadlock_bug+0xc0/0xcf > > [] check_deadlock+0x6a/0x79 > > [] __lock_acquire+0x350/0x970 > > [] lock_acquire+0x75/0x97 > > [] down_write+0x3a/0x54 > > [] xfs_ilock+0x5b/0xa1 > > [] xfs_lock_dir_and_entry+0x105/0x11b > > [] xfs_remove+0x180/0x47f > > [] xfs_vn_unlink+0x22/0x4f > > [] vfs_unlink+0x9e/0xa2 > > [] do_unlinkat+0xa8/0x115 > > [] sys_unlink+0x10/0x12 > > [] syscall_call+0x7/0xb > > [] 0xb7efaa7d > > ======================= > > That's no problem - lockdep just doesn't know that we can nest i_lock > (we've got to get the annotations for this sorted out). > > > Here is the relevant results: > > > > Phase 2 - found root inode chunk > > Phase 3 - ... > > agno = 0 > > ... > > agno = 12 > > LEAFN node level is 1 inode 1610612918 bno = 8388608 > > Hmmm - single bit error in the bno - that reminds of this: > > http://oss.sgi.com/projects/xfs/faq.html#dir2 > > So I'd definitely make sure that is repaired.... > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > From owner-xfs@oss.sgi.com Thu Jun 7 01:18:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 01:18:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_60 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l578IfWt026810 for ; Thu, 7 Jun 2007 01:18:43 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA28327; Thu, 7 Jun 2007 18:18:35 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l578IXAf108741981; Thu, 7 Jun 2007 18:18:33 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l578IUuT115565036; Thu, 7 Jun 2007 18:18:30 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 7 Jun 2007 18:18:30 +1000 From: David Chinner To: David Chinner , Ruben Porras , xfs@oss.sgi.com, cw@f00f.org Subject: Re: XFS shrink functionality Message-ID: <20070607081830.GR86004887@sgi.com> References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> <20070604084154.GA8273@teal.hq.k1024.org> <20070604092115.GX85884050@sgi.com> <20070605080012.GA10677@teal.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070605080012.GA10677@teal.hq.k1024.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11673 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Jun 05, 2007 at 10:00:12AM +0200, Iustin Pop wrote: > On Mon, Jun 04, 2007 at 07:21:15PM +1000, David Chinner wrote: > > > allocated on an available AG and when you remove the originals, the > > > to-be-shrinked AGs become free. Yes, utterly non-optimal, but it was the > > > simplest way to do it based on what I knew at the time. > > > > Not quite that simple, unfortunately. You can't leave the > > AGs locked in the same way we do for a grow because we need > > to be able to use the AGs to move stuff about and that > > requires locking them. Hence we need a separate mechanism > > to prevent allocation in a given AG outside of locking them. > > > > Hence we need: > > > > - a transaction to mark AGs "no-allocate" > > - a transaction to mark AGs "allocatable" > > - a flag in each AGF/AGI to say the AG is available for > > allocations (persistent over crashes) > > - a flag in the per-ag structure to indicate allocation > > status of the AG. > > - everywhere we select an AG for allocation, we need to > > check this flag and skip the AG if it's not available. > > > > FWIW, the transactions can probably just be an extension of > > xfs_alloc_log_agf() and xfs_alloc_log_agi().... > > A question: do you think that the cost of having this in the code > (especially the last part, check that flag in every allocation function) > is acceptable? I mean, let's say one would write the patch to implement > all this. Does it have a chance to be accepted? Or will people say it's > only bloat? ... Lots of ppl ask for shrink capability on XFS, so if it's implemented and reviewed and passes QA tests, then I see no reason why it wouldn't be accepted... > > Yeah, 1) and 4) are separable parts of the problem and can be done > > in any order. 2) can be implemented relatively easily as stated > > above. > > > > 3) is the hard one - we need to find the owner of each block > > (metadata and data) remaining in the AGs to be removed. This may be > > a directory btree block, a inode extent btree block, a data block, > > and extended attr block, etc. Moving the data blocks is easy to > > do (swap extents), but moving the metadata blocks is a major PITA > > as it will need to be done transactionally and that will require > > a bunch of new (complex) code to be written, I think. It will be > > of equivalent complexity to defragmenting metadata.... > > > > If we ignore the metadata block problem then finding and moving the > > data blocks should not be a problem - swap extents can be used for > > that as well - but it will be extremely time consuming and won't > > scale to large filesystem sizes.... > > So given these caveats, is there a chance that a) this will be actually > useful and b) will this be accepted? Look at it this way - if we get to the point where 3 is a problem, then we've got most of a useful shrinker. That's way ahead of what we have now and in a lot of cases it will just work. The corner cases are the hard bit, but we can work on them incrementally once the rest is done, and in doing so we'll also be introducing the means by which to defragment metadata. IOWs, we kill two birds with one stone at that point in time. Likewise for the shrink case that needs to move the log - we've got hooks for userspace tools to move the log, just no implementation. Implementing log moving for shrink will also enable us to do online log resize and internal/external log switching. Once again, two birds with one stone. Hence I don't see these issues as showstoppers at all - getting to the point of a full shrink implementation will give us other features that we need to have anyway.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jun 7 03:30:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 03:30:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l57AU8Wt028993 for ; Thu, 7 Jun 2007 03:30:09 -0700 Received: from localhost (mailman.ukfsn.org [80.168.53.75]) by mail.ukfsn.org (Postfix) with ESMTP id 5F34CE6C44; Thu, 7 Jun 2007 11:29:48 +0100 (BST) Received: from mail.ukfsn.org ([80.168.53.20]) by localhost (smtp-filter.ukfsn.org [80.168.53.75]) (amavisd-new, port 10024) with ESMTP id XBwCbLFtQcNW; Thu, 7 Jun 2007 11:27:36 +0100 (BST) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 9A42BE6C57; Thu, 7 Jun 2007 11:29:46 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1HwFFl-0001eM-Jk; Thu, 07 Jun 2007 11:30:05 +0100 Message-ID: <4667DE2D.6050903@dgreaves.com> Date: Thu, 07 Jun 2007 11:30:05 +0100 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Tejun Heo Cc: Linus Torvalds , "Rafael J. Wysocki" , xfs@oss.sgi.com, "'linux-kernel@vger.kernel.org'" , linux-pm , Neil Brown Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6) References: <46608E3F.4060201@dgreaves.com> <200706012342.45657.rjw@sisk.pl> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> <46668EE0.2030509@dgreaves.com> <46679D56.7040001@gmail.com> In-Reply-To: <46679D56.7040001@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11674 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Tejun Heo wrote: > Hello, > > David Greaves wrote: >> Just to be clear. This problem is where my system won't resume after s2d >> unless I umount my xfs over raid6 filesystem. > > This is really weird. I don't see how xfs mount can affect this at all. Indeed. It does :) > How hard does the machine freeze? Can you use sysrq? If so, please > dump sysrq-t. I suspect there is a problem writing to the consoles... I recompiled (rc4+patch) with sysrq support, suspended, resumed and tried sysrq-t but got no output. I *can* change VTs and see the various login prompts, bitmap messages and the console messages. Caps/Num lock lights work. Fearing incompetence I tried sysrq-s sysrq-u sysrq-b and got a reboot so sysrq is OK. Any suggestions on how to see more? Or what to try next? Any other kernel debug options to set? David PS Back in a couple of hours... From owner-xfs@oss.sgi.com Thu Jun 7 04:07:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 04:07:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l57B7TWt004799 for ; Thu, 7 Jun 2007 04:07:30 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA01980; Thu, 7 Jun 2007 21:07:22 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l57B7HAf115363674; Thu, 7 Jun 2007 21:07:18 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l57B7Aqi116423461; Thu, 7 Jun 2007 21:07:10 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 7 Jun 2007 21:07:10 +1000 From: David Chinner To: David Greaves Cc: Tejun Heo , Linus Torvalds , "Rafael J. Wysocki" , xfs@oss.sgi.com, "'linux-kernel@vger.kernel.org'" , linux-pm , Neil Brown Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6) Message-ID: <20070607110708.GS86004887@sgi.com> References: <200706012342.45657.rjw@sisk.pl> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> <46668EE0.2030509@dgreaves.com> <46679D56.7040001@gmail.com> <4667DE2D.6050903@dgreaves.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4667DE2D.6050903@dgreaves.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11675 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Jun 07, 2007 at 11:30:05AM +0100, David Greaves wrote: > Tejun Heo wrote: > >Hello, > > > >David Greaves wrote: > >>Just to be clear. This problem is where my system won't resume after s2d > >>unless I umount my xfs over raid6 filesystem. > > > >This is really weird. I don't see how xfs mount can affect this at all. > Indeed. > It does :) Ok, so lets determine if it really is XFS. Does the lockup happen with a different filesystem on the md device? Or if you can't test that, does any other XFS filesystem you have show the same problem? If it is xfs that is causing the problem, what happens if you remount read-only instead of unmounting before shutting down? What about freezing the filesystem? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jun 7 05:34:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 05:34:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l57CYiWt031174 for ; Thu, 7 Jun 2007 05:34:46 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HwGx3-00089a-SQ; Thu, 07 Jun 2007 13:18:53 +0100 Date: Thu, 7 Jun 2007 13:18:53 +0100 From: Christoph Hellwig To: David Chinner Cc: Tim Shimmin , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: review: xfs_growfs_data_private() not logging agf length change Message-ID: <20070607121853.GA29442@infradead.org> References: <4667ADAF.7000904@sgi.com> <20070607073034.GP86004887@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070607073034.GP86004887@sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11676 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Thu, Jun 07, 2007 at 05:30:34PM +1000, David Chinner wrote: > On Thu, Jun 07, 2007 at 05:03:11PM +1000, Tim Shimmin wrote: > > Looks like we forgot to log the agf_length change here. > > > > (cut 'n' pasted patch) > > > > --Tim > > > > =========================================================================== > > Index: fs/xfs/xfs_fsops.c > > =========================================================================== > > > > --- a/fs/xfs/xfs_fsops.c 2007-04-17 18:02:46.000000000 +1000 > > +++ b/fs/xfs/xfs_fsops.c 2007-04-17 17:59:44.467987572 +1000 > > @@ -328,6 +328,7 @@ xfs_growfs_data_private( > > be32_add(&agf->agf_length, new); > > ASSERT(be32_to_cpu(agf->agf_length) == > > be32_to_cpu(agi->agi_length)); > > + xfs_alloc_log_agf(tp, bp, XFS_AGF_LENGTH); > > /* > > * Free the new space. > > */ > > Yup, looks ok to me. Except for the whitespace damage, of course - but that might have been the cut & pasting. From owner-xfs@oss.sgi.com Thu Jun 7 05:49:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 05:49:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l57CnKWt003194 for ; Thu, 7 Jun 2007 05:49:23 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA04257; Thu, 7 Jun 2007 22:49:16 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l57CnFAf116466952; Thu, 7 Jun 2007 22:49:16 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l57CnEPg116437643; Thu, 7 Jun 2007 22:49:14 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 7 Jun 2007 22:49:14 +1000 From: David Chinner To: Christoph Hellwig Cc: David Chinner , Tim Shimmin , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: review: xfs_growfs_data_private() not logging agf length change Message-ID: <20070607124914.GD85884050@sgi.com> References: <4667ADAF.7000904@sgi.com> <20070607073034.GP86004887@sgi.com> <20070607121853.GA29442@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070607121853.GA29442@infradead.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11677 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Jun 07, 2007 at 01:18:53PM +0100, Christoph Hellwig wrote: > On Thu, Jun 07, 2007 at 05:30:34PM +1000, David Chinner wrote: > > On Thu, Jun 07, 2007 at 05:03:11PM +1000, Tim Shimmin wrote: > > > Looks like we forgot to log the agf_length change here. > > > > > > (cut 'n' pasted patch) > > > > > > --Tim ..... > > > > Yup, looks ok to me. > > Except for the whitespace damage, of course - but that might have been > the cut & pasting. The attached patch had no ws damage. ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jun 7 06:05:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 06:05:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l57D5CWt009284 for ; Thu, 7 Jun 2007 06:05:13 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA04636; Thu, 7 Jun 2007 23:05:10 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l57D58Af115711774; Thu, 7 Jun 2007 23:05:09 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l57D55AW116168152; Thu, 7 Jun 2007 23:05:05 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 7 Jun 2007 23:05:05 +1000 From: David Chinner To: Marco Berizzi Cc: David Chinner , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS internal error xfs_da_do_buf(2) at line 2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b00bd Message-ID: <20070607130505.GE85884050@sgi.com> References: <20070316012520.GN5743@melbourne.sgi.com> <20070316195951.GB5743@melbourne.sgi.com> <20070320064632.GO32602149@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11678 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Jun 07, 2007 at 09:44:51AM +0200, Marco Berizzi wrote: > Hi David. > Three months ago I wrote the message below. > I had built various 2.6.20.x and 2.6.21.x > vanilla kernel with all the debug options > enabled and linux had never crashed. > On june 4, I have builded linux 2.6.21.3 without > any debugging options and after 2 days linux > has starting print these errors: > > Jun 6 09:47:09 Pleiadi kernel: ======================= > Jun 6 09:47:09 Pleiadi kernel: 0x0: 28 f1 45 d4 22 53 35 11 09 80 37 5a > 47 8a 22 ee > Jun 6 09:47:09 Pleiadi kernel: Filesystem "sda8": XFS internal error > xfs_da_do_buf(2) at line 2086 of file fs/xfs/xfs_da_btree.c. Caller > 0xc01b2301 > Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_do_buf+0x70c/0x7b1 > Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_read_buf+0x30/0x35 > Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_read_buf+0x30/0x35 These above stack trace is the sign of a corrupted directory. Chopping out the rest of the top posting (please don't do that) we get down to 3 months ago: > > On Mon, Mar 19, 2007 at 11:32:27AM +0100, Marco Berizzi wrote: > > > Marco Berizzi wrote: > > > Here is the relevant results: > > > > > > Phase 2 - found root inode chunk > > > Phase 3 - ... > > > agno = 0 > > > ... > > > agno = 12 > > > LEAFN node level is 1 inode 1610612918 bno = 8388608 > > > > Hmmm - single bit error in the bno - that reminds of this: > > > > http://oss.sgi.com/projects/xfs/faq.html#dir2 > > > > So I'd definitely make sure that is repaired.... Where we saw signs of on disk directory corruption. Have you run xfs_repair successfully on the filesystem since you reported this? If you did clean up the error, does xfs_repair report the same sort of error again? Have you run a 2.6.16-rcX or 2.6.17.[0-6] kernel since you last reported this problem? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jun 7 07:00:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 07:00:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=AWL,BAYES_95 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l57E01Wt025578 for ; Thu, 7 Jun 2007 07:00:02 -0700 Received: from localhost (mailman.ukfsn.org [80.168.53.75]) by mail.ukfsn.org (Postfix) with ESMTP id 4A27CE6AD6; Thu, 7 Jun 2007 14:59:41 +0100 (BST) Received: from mail.ukfsn.org ([80.168.53.20]) by localhost (smtp-filter.ukfsn.org [80.168.53.75]) (amavisd-new, port 10024) with ESMTP id nhKk-zsWb0CF; Thu, 7 Jun 2007 14:57:29 +0100 (BST) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 60B9BE7406; Thu, 7 Jun 2007 14:59:39 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1HwIWt-0001x1-0i; Thu, 07 Jun 2007 14:59:59 +0100 Message-ID: <46680F5E.6070806@dgreaves.com> Date: Thu, 07 Jun 2007 14:59:58 +0100 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: David Chinner Cc: Tejun Heo , Linus Torvalds , "Rafael J. Wysocki" , xfs@oss.sgi.com, "'linux-kernel@vger.kernel.org'" , linux-pm , Neil Brown Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6) References: <200706012342.45657.rjw@sisk.pl> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> <46668EE0.2030509@dgreaves.com> <46679D56.7040001@gmail.com> <4667DE2D.6050903@dgreaves.com> <20070607110708.GS86004887@sgi.com> In-Reply-To: <20070607110708.GS86004887@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11679 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs David Chinner wrote: > On Thu, Jun 07, 2007 at 11:30:05AM +0100, David Greaves wrote: >> Tejun Heo wrote: >>> Hello, >>> >>> David Greaves wrote: >>>> Just to be clear. This problem is where my system won't resume after s2d >>>> unless I umount my xfs over raid6 filesystem. >>> This is really weird. I don't see how xfs mount can affect this at all. >> Indeed. >> It does :) > > Ok, so lets determine if it really is XFS. Seems like a good next step... > Does the lockup happen with a > different filesystem on the md device? Or if you can't test that, does > any other XFS filesystem you have show the same problem? It's a rather full 1.2Tb raid6 array - can't reformat it - sorry :) I only noticed the problem when I umounted the fs during tests to prevent corruption - and it worked. I'm doing a sync each time it hibernates (see below) and a couple of paranoia xfs_repairs haven't shown any problems. I do have another xfs filesystem on /dev/hdb2 (mentioned when I noticed the md/XFS correlation). It doesn't seem to have/cause any problems. > If it is xfs that is causing the problem, what happens if you > remount read-only instead of unmounting before shutting down? Yes, I'm happy to try these tests. nb, the hibernate script is: ethtool -s eth0 wol g sync echo platform > /sys/power/disk echo disk > /sys/power/state So there has always been a sync before any hibernate. cu:~# mount -oremount,ro /huge cu:~# mount /dev/hda2 on / type xfs (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) usbfs on /proc/bus/usb type usbfs (rw) tmpfs on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) nfsd on /proc/fs/nfsd type nfsd (rw) /dev/hda1 on /boot type ext3 (rw) /dev/md0 on /huge type xfs (ro) /dev/hdb2 on /scratch type xfs (rw) tmpfs on /dev type tmpfs (rw,size=10M,mode=0755) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) cu:(pid2862,port1022) on /net type nfs (intr,rw,port=1022,toplvl,map=/usr/share/am-utils/amd.net,noac) elm:/space on /amd/elm/root/space type nfs (rw,vers=3,proto=tcp) elm:/space-backup on /amd/elm/root/space-backup type nfs (rw,vers=3,proto=tcp) elm:/usr/src on /amd/elm/root/usr/src type nfs (rw,vers=3,proto=tcp) cu:~# /usr/net/bin/hibernate [this works and resumes] cu:~# mount -oremount,rw /huge cu:~# /usr/net/bin/hibernate [this works and resumes too !] cu:~# touch /huge/tst cu:~# /usr/net/bin/hibernate [but this doesn't even hibernate] > What about freezing the filesystem? cu:~# xfs_freeze -f /huge cu:~# /usr/net/bin/hibernate [but this doesn't even hibernate - same as the 'touch'] Nb the screen looks like this: http://www.dgreaves.com/pub/2.6.21-rc4-ptched-suspend-failure.jpg whether it hangs on suspend or resume. So I wouldn't say it *is* XFS at fault - but there certainly seems to be an interaction... At least it's easily reproducible :) Shame about the sysrq I can think of other permutations of freeze/ro/writing tests but I'm just thrashing really. Happy for you to tell me what to try next ... David From owner-xfs@oss.sgi.com Thu Jun 7 07:00:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 07:00:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=AWL,BAYES_60 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l57E0CWt025620 for ; Thu, 7 Jun 2007 07:00:15 -0700 Received: from localhost (mailman.ukfsn.org [80.168.53.75]) by mail.ukfsn.org (Postfix) with ESMTP id 93B80E749F; Thu, 7 Jun 2007 14:59:52 +0100 (BST) Received: from mail.ukfsn.org ([80.168.53.20]) by localhost (smtp-filter.ukfsn.org [80.168.53.75]) (amavisd-new, port 10024) with ESMTP id k9BV9fJ1zdaB; Thu, 7 Jun 2007 14:57:41 +0100 (BST) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id E3F91E74A8; Thu, 7 Jun 2007 14:59:49 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1HwIX3-0001x8-UO; Thu, 07 Jun 2007 15:00:10 +0100 Message-ID: <46680F69.60105@dgreaves.com> Date: Thu, 07 Jun 2007 15:00:09 +0100 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Duane Griffin Cc: Tejun Heo , Linus Torvalds , "Rafael J. Wysocki" , xfs@oss.sgi.com, "linux-kernel@vger.kernel.org" , linux-pm , Neil Brown Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6) References: <46608E3F.4060201@dgreaves.com> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> <46668EE0.2030509@dgreaves.com> <46679D56.7040001@gmail.com> <4667DE2D.6050903@dgreaves.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11680 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Duane Griffin wrote: > On 07/06/07, David Greaves wrote: >> > How hard does the machine freeze? Can you use sysrq? If so, please >> > dump sysrq-t. >> I suspect there is a problem writing to the consoles... >> >> I recompiled (rc4+patch) with sysrq support, suspended, resumed and tried >> sysrq-t but got no output. >> >> I *can* change VTs and see the various login prompts, bitmap messages >> and the >> console messages. Caps/Num lock lights work. >> >> Fearing incompetence I tried sysrq-s sysrq-u sysrq-b and got a reboot >> so sysrq >> is OK. > > Try sysrq-9 before the sysrq-t. Probably the messages are not being > printed to console with your default output level. Good idea :) Didn't work :( Cheers David From owner-xfs@oss.sgi.com Thu Jun 7 07:11:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 07:11:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l57EB8Wt029216 for ; Thu, 7 Jun 2007 07:11:09 -0700 Received: by wa-out-1112.google.com with SMTP id k22so624779waf for ; Thu, 07 Jun 2007 07:11:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=M0IaTuJ825OavE+MTk2aaoQvpIED68gS1d6DnNcgJl1Qu+aKLqIHc+RA3T/AjK+DMyl0E3TjZj9MfQP9cdGpt5FhqBQwjGYCEf4At0vJUp62NvMPW/k0gAoZUnNvm/mauP5ozbz9JgTMXZaDwp+RN7q0z9VJggCafpX6TQzGdgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Gx1aMSxT6YyS+GXubG8hK0AH6GXpsEgR5tOF/8lxXl1sfv7QR7LsEj+d7vJBNWSIpgL1TOlTNsZ7p9VOXPnexcpwHKK5hqMZndyWMzCjX+JFiipp9I4ZAj4Q9Yqif6sGMiAm4t4SrjTvZ6sfPr8EgYNjenTompjakNVX3/Qc6co= Received: by 10.114.156.1 with SMTP id d1mr1555351wae.1181223951301; Thu, 07 Jun 2007 06:45:51 -0700 (PDT) Received: by 10.141.76.3 with HTTP; Thu, 7 Jun 2007 06:45:51 -0700 (PDT) Message-ID: Date: Thu, 7 Jun 2007 14:45:51 +0100 From: "Duane Griffin" To: "David Greaves" Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6) Cc: "Tejun Heo" , "Linus Torvalds" , "Rafael J. Wysocki" , xfs@oss.sgi.com, "linux-kernel@vger.kernel.org" , linux-pm , "Neil Brown" In-Reply-To: <4667DE2D.6050903@dgreaves.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46608E3F.4060201@dgreaves.com> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> <46668EE0.2030509@dgreaves.com> <46679D56.7040001@gmail.com> <4667DE2D.6050903@dgreaves.com> X-Google-Sender-Auth: 749024c516b999cd X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11681 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: duaneg@dghda.com Precedence: bulk X-list: xfs On 07/06/07, David Greaves wrote: > > How hard does the machine freeze? Can you use sysrq? If so, please > > dump sysrq-t. > I suspect there is a problem writing to the consoles... > > I recompiled (rc4+patch) with sysrq support, suspended, resumed and tried > sysrq-t but got no output. > > I *can* change VTs and see the various login prompts, bitmap messages and the > console messages. Caps/Num lock lights work. > > Fearing incompetence I tried sysrq-s sysrq-u sysrq-b and got a reboot so sysrq > is OK. Try sysrq-9 before the sysrq-t. Probably the messages are not being printed to console with your default output level. Cheers, Duane Griffin. -- "I never could learn to drink that blood and call it wine" - Bob Dylan From owner-xfs@oss.sgi.com Thu Jun 7 08:05:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 08:05:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.rtr.ca (rtr.ca [64.26.128.89]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l57F5UWt012159 for ; Thu, 7 Jun 2007 08:05:31 -0700 Received: by mail.rtr.ca (Postfix, from userid 1002) id AE1FB25C0C6; Thu, 7 Jun 2007 10:36:31 -0400 (EDT) Received: from [10.0.0.6] (corey.localnet [10.0.0.6]) by mail.rtr.ca (Postfix) with ESMTP id 856AA25C0B9; Thu, 7 Jun 2007 10:36:31 -0400 (EDT) Message-ID: <466817EF.7090707@rtr.ca> Date: Thu, 07 Jun 2007 10:36:31 -0400 From: Mark Lord User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Tejun Heo Cc: David Greaves , Duane Griffin , Linus Torvalds , "Rafael J. Wysocki" , xfs@oss.sgi.com, "linux-kernel@vger.kernel.org" , linux-pm , Neil Brown Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6) References: <46608E3F.4060201@dgreaves.com> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> <46668EE0.2030509@dgreaves.com> <46679D56.7040001@gmail.com> <4667DE2D.6050903@dgreaves.com> <46680F69.60105@dgreaves.com> <46681094.4070103@gmail.com> In-Reply-To: <46681094.4070103@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11682 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lkml@rtr.ca Precedence: bulk X-list: xfs Tejun Heo wrote: > > Can you setup serial console and/or netconsole (not sure whether this > would work tho)? Since he has good console output already, capturable by digicam, I think a better approach might be to provide a patch with extra instrumentation.. You know.. progress messages and the like, so we can see at what step things stop working. Or would that not help ? David, does scrollback work on your dead console? Cheers From owner-xfs@oss.sgi.com Thu Jun 7 08:20:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 08:20:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.4 required=5.0 tests=AWL,BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l57FK6Wt019413 for ; Thu, 7 Jun 2007 08:20:07 -0700 Received: from localhost (mailman.ukfsn.org [80.168.53.75]) by mail.ukfsn.org (Postfix) with ESMTP id 119D9E6AF4; Thu, 7 Jun 2007 16:19:46 +0100 (BST) Received: from mail.ukfsn.org ([80.168.53.20]) by localhost (smtp-filter.ukfsn.org [80.168.53.75]) (amavisd-new, port 10024) with ESMTP id FDynGbWwD5hc; Thu, 7 Jun 2007 16:17:34 +0100 (BST) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id A67A0E6AE7; Thu, 7 Jun 2007 16:19:43 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1HwJmL-00026m-V3; Thu, 07 Jun 2007 16:20:01 +0100 Message-ID: <46682221.8070705@dgreaves.com> Date: Thu, 07 Jun 2007 16:20:01 +0100 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Mark Lord Cc: Tejun Heo , Duane Griffin , Linus Torvalds , "Rafael J. Wysocki" , xfs@oss.sgi.com, "linux-kernel@vger.kernel.org" , linux-pm , Neil Brown Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6) References: <46608E3F.4060201@dgreaves.com> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> <46668EE0.2030509@dgreaves.com> <46679D56.7040001@gmail.com> <4667DE2D.6050903@dgreaves.com> <46680F69.60105@dgreaves.com> <46681094.4070103@gmail.com> <466817EF.7090707@rtr.ca> In-Reply-To: <466817EF.7090707@rtr.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11683 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Mark Lord wrote: > Tejun Heo wrote: >> >> Can you setup serial console and/or netconsole (not sure whether this >> would work tho)? > > Since he has good console output already, capturable by digicam, > I think a better approach might be to provide a patch with extra > instrumentation.. > You know.. progress messages and the like, so we can see at what step > things stop working. Or would that not help ? > > David, does scrollback work on your dead console? hmmmm, scrollback doesn't currently _do_ anything. But the messages didn't scroll there, they just appear (as the memory is restored I assume). The same messages appear during the fail-to-suspend case too. Linus said at one point: > Ok, it wasn't a hidden oops. The DISABLE_CONSOLE_SUSPEND=y thing sometimes > shows oopses that are otherwise hidden, but at other times it just causes > more problems (hard hangs when trying to display something on a device > that is suspended, or behind a bridge that got suspended). > In your case, the screen output just shows normal resume output, and it > apparently just hung for some unknown reason. It *may* be worth trying to > do a SysRQ + 't' thing to see what tasks are running (or rather, not > running), but since you won't be able to capture it, it's probably not > going to be useful. So I've since removed DISABLE_CONSOLE_SUSPEND=y Should I put it back? I was actually doing the netconsole anyway - but skge is currently a module - I've avoided making any changes to the config during all these tests but what the heck... And wouldn't you know it. Get netconsole working (ie new kernel with skge builtin) and I get the hang on suspend. Here's the netconsole output... swsusp: Basic memory bitmaps created Stopping tasks ... done. Shrinking memory... done (0 pages freed) Freed 0 kbytes in 0.03 seconds (0.00 MB/s) Suspending console(s) Given that moving something from module to builtin changes the behaviour I thought I'd bring these warnings up again (Andrew or Alan mentioned similar warnings being problems in another thread...) Now, I have mentioned these before but there's been a lot going on so here you go: MODPOST vmlinux WARNING: arch/i386/kernel/built-in.o(.text+0x968f): Section mismatch: reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init') WARNING: arch/i386/kernel/built-in.o(.text+0x9781): Section mismatch: reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init') WARNING: arch/i386/kernel/built-in.o(.text+0x9786): Section mismatch: reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init') WARNING: arch/i386/kernel/built-in.o(.text+0xa25c): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: arch/i386/kernel/built-in.o(.text+0xa303): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: arch/i386/kernel/built-in.o(.text+0xa31b): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: arch/i386/kernel/built-in.o(.text+0xa344): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: arch/i386/kernel/built-in.o(.exit.text+0x19): Section mismatch: reference to .init.text: (between 'cache_remove_dev' and 'powernow_k6_exit') WARNING: arch/i386/kernel/built-in.o(.data+0x2160): Section mismatch: reference to .init.text: (between 'thermal_throttle_cpu_notifier' and 'mce_work') WARNING: kernel/built-in.o(.text+0x14502): Section mismatch: reference to .init.text: (between 'kthreadd' and 'init_waitqueue_head') David PS Gotta go - back in a couple of hours - let me know if there are any more tests to try. From owner-xfs@oss.sgi.com Thu Jun 7 11:22:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 11:23:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.4 required=5.0 tests=AWL,BAYES_80 autolearn=no version=3.2.0-pre1-r499012 Received: from smtp14.wxs.nl (smtp14.wxs.nl [195.121.247.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l57IMuWt006080 for ; Thu, 7 Jun 2007 11:22:57 -0700 Received: from mail.deserver.nl (ip565e92ac.direct-adsl.nl [86.94.146.172]) by smtp14.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JJA0085L2LHA6@smtp14.wxs.nl> for xfs@oss.sgi.com; Thu, 07 Jun 2007 20:12:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.deserver.nl (Postfix) with ESMTP id D9310236CD for ; Thu, 07 Jun 2007 20:12:52 +0200 (CEST) Received: from [192.168.0.14] (unknown [192.168.0.14]) by mail.deserver.nl (Postfix) with ESMTP id 21E3A236C4 for ; Thu, 07 Jun 2007 20:12:44 +0200 (CEST) Date: Thu, 07 Jun 2007 20:12:43 +0200 From: Jaap Struyk Subject: Re: ways to restore data from crashed disk In-reply-to: <465ECF9B.2000500@sandeen.net> To: xfs@oss.sgi.com Message-id: <46684A9B.90908@deserver.nl> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.0 (X11/20070326) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Scanned: by mailscan at deserver.nl X-Enigmail-Version: 0.95.0 References: <465EA882.3030403@deserver.nl> <465ECF9B.2000500@sandeen.net> X-Virus-Status: Clean X-archive-position: 11684 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: japie@deserver.nl Precedence: bulk X-list: xfs Eric Sandeen schreef: > For starters, is the file really that big? (9397895168 bytes?) dd_rhelp /dev/hdd4 hdd4.img xfs_repair hdd4.img Phase 1 - find and verify superblock... superblock read failed, offset 103376846848, size 2048, ag 11, rval 0 fatal error -- Gelukt (gelukt is dutch for sucses or done) The image is 92G. big but my original filesystem was about 120G. but the 92G is about the size of the data that was on the disc. dd_rhelp /dev/hdd4 hdd4.img info: - Jump pos : 96365061.0 - max file size : 156019623.0 - Biggest hole size : 119309126 k - total holes : 0k - xferd(succ/err) : 36710498.0k(36710496.0k/2.0k) - EOF is not found, but between 36710498.0k and 156019623.0k. ALL your data has been dd_rescued !! -- Groetjes Japie From owner-xfs@oss.sgi.com Thu Jun 7 11:56:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 11:56:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=AWL,BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from psmtp13.wxs.nl (psmtp13.wxs.nl [195.121.247.25]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l57IuaWt014628 for ; Thu, 7 Jun 2007 11:56:37 -0700 Received: from mail.deserver.nl (ip565e92ac.direct-adsl.nl [86.94.146.172]) by psmtp13.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JJA003NG4M9XH@psmtp13.wxs.nl> for xfs@oss.sgi.com; Thu, 07 Jun 2007 20:56:34 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mail.deserver.nl (Postfix) with ESMTP id C160F236CE for ; Thu, 07 Jun 2007 20:56:32 +0200 (CEST) Received: from [192.168.0.14] (unknown [192.168.0.14]) by mail.deserver.nl (Postfix) with ESMTP id 38E8C236C6 for ; Thu, 07 Jun 2007 20:56:26 +0200 (CEST) Date: Thu, 07 Jun 2007 20:56:25 +0200 From: Jaap Struyk Subject: Re: ways to restore data from crashed disk In-reply-to: <46684A9B.90908@deserver.nl> To: xfs@oss.sgi.com Message-id: <466854D9.3070903@deserver.nl> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.0 (X11/20070326) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Scanned: by mailscan at deserver.nl X-Enigmail-Version: 0.95.0 References: <465EA882.3030403@deserver.nl> <465ECF9B.2000500@sandeen.net> <46684A9B.90908@deserver.nl> X-Virus-Status: Clean X-archive-position: 11685 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: japie@deserver.nl Precedence: bulk X-list: xfs xfs_db hdd4.img xfs_db> sb 0 xfs_db> p magicnum = 0x58465342 blocksize = 4096 dblocks = 36710528 rblocks = 0 rextents = 0 uuid = 9b1a2a9c-9572-426f-b234-b6ba89bae713 logstart = 33554436 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 2294408 agcount = 16 rbmblocks = 0 logblocks = 17925 versionnum = 0x3084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 22 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 76864 ifree = 20402 fdblocks = 8890535 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 -- Groetjes Japie From owner-xfs@oss.sgi.com Thu Jun 7 12:32:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 12:32:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.3 required=5.0 tests=AWL,BAYES_60,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l57JWmWt028000 for ; Thu, 7 Jun 2007 12:32:49 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l57JVkCI022126; Thu, 7 Jun 2007 15:31:47 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l57JVkoj011286; Thu, 7 Jun 2007 15:31:46 -0400 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l57JViEw019118; Thu, 7 Jun 2007 15:31:45 -0400 Message-ID: <46685C5F.5090804@sandeen.net> Date: Thu, 07 Jun 2007 14:28:31 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Jaap Struyk CC: xfs@oss.sgi.com Subject: Re: ways to restore data from crashed disk References: <465EA882.3030403@deserver.nl> <465ECF9B.2000500@sandeen.net> <46684A9B.90908@deserver.nl> In-Reply-To: <46684A9B.90908@deserver.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11686 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Jaap Struyk wrote: > Eric Sandeen schreef: > >> For starters, is the file really that big? (9397895168 bytes?) > > dd_rhelp /dev/hdd4 hdd4.img > xfs_repair hdd4.img > Phase 1 - find and verify superblock... > superblock read failed, offset 103376846848, size 2048, ag 11, rval 0 > fatal error -- Gelukt (gelukt is dutch for sucses or done) > > The image is 92G. big but my original filesystem was about 120G. but the > 92G is about the size of the data that was on the disc. when you are talking about sizes, do you mean space used (du) or max offset (ls -l?) max offset should be the same for your image file as for your original device... 120G. -Eric > dd_rhelp /dev/hdd4 hdd4.img info: > - Jump pos : 96365061.0 - max file size : 156019623.0 > - Biggest hole size : 119309126 k - total holes : 0k > - xferd(succ/err) : 36710498.0k(36710496.0k/2.0k) > - EOF is not found, but between 36710498.0k and 156019623.0k. > ALL your data has been dd_rescued !! From owner-xfs@oss.sgi.com Thu Jun 7 15:28:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 15:28:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l57MSZWt007786 for ; Thu, 7 Jun 2007 15:28:37 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA21270; Fri, 8 Jun 2007 08:28:27 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l57MSLAf116143884; Fri, 8 Jun 2007 08:28:22 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l57MSD7a101597986; Fri, 8 Jun 2007 08:28:13 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 8 Jun 2007 08:28:13 +1000 From: David Chinner To: David Greaves Cc: David Chinner , Tejun Heo , Linus Torvalds , "Rafael J. Wysocki" , xfs@oss.sgi.com, "'linux-kernel@vger.kernel.org'" , linux-pm , Neil Brown Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6) Message-ID: <20070607222813.GG85884050@sgi.com> References: <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> <46668EE0.2030509@dgreaves.com> <46679D56.7040001@gmail.com> <4667DE2D.6050903@dgreaves.com> <20070607110708.GS86004887@sgi.com> <46680F5E.6070806@dgreaves.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46680F5E.6070806@dgreaves.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11687 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Jun 07, 2007 at 02:59:58PM +0100, David Greaves wrote: > David Chinner wrote: > >On Thu, Jun 07, 2007 at 11:30:05AM +0100, David Greaves wrote: > >>Tejun Heo wrote: > >>>Hello, > >>> > >>>David Greaves wrote: > >>>>Just to be clear. This problem is where my system won't resume after s2d > >>>>unless I umount my xfs over raid6 filesystem. > >>>This is really weird. I don't see how xfs mount can affect this at all. > >>Indeed. > >>It does :) > > > >Ok, so lets determine if it really is XFS. > Seems like a good next step... > > >Does the lockup happen with a > >different filesystem on the md device? Or if you can't test that, does > >any other XFS filesystem you have show the same problem? > It's a rather full 1.2Tb raid6 array - can't reformat it - sorry :) I suspected as much :/ > I only noticed the problem when I umounted the fs during tests to prevent > corruption - and it worked. I'm doing a sync each time it hibernates (see > below) and a couple of paranoia xfs_repairs haven't shown any problems. sync just guarantees that metadata changes are logged and data is on disk - it doesn't stop the filesystem from doing anything after the sync... > I do have another xfs filesystem on /dev/hdb2 (mentioned when I noticed the > md/XFS correlation). It doesn't seem to have/cause any problems. Ok, so it's not an obvious XFS problem... > >If it is xfs that is causing the problem, what happens if you > >remount read-only instead of unmounting before shutting down? > Yes, I'm happy to try these tests. > nb, the hibernate script is: > ethtool -s eth0 wol g > sync > echo platform > /sys/power/disk > echo disk > /sys/power/state > > So there has always been a sync before any hibernate. > > > cu:~# mount -oremount,ro /huge ..... > [this works and resumes] Ok. > cu:~# mount -oremount,rw /huge > cu:~# /usr/net/bin/hibernate > [this works and resumes too !] Interesting. That means something in the generic remount code is affecting this. > cu:~# touch /huge/tst > cu:~# /usr/net/bin/hibernate > [but this doesn't even hibernate] Ok, so a clean inode is sufficient to prevent hibernate from working. So, what's different between a sync and a remount? do_remount_sb() does: 599 shrink_dcache_sb(sb); 600 fsync_super(sb); of which a sync does neither. sync does what fsync_super() does in different sort of way, but does not call sync_blockdev() on each block device. It looks like that is the two main differences between sync and remount - remount trims the dentry cache and syncs the blockdev, sync doesn't. > > What about freezing the filesystem? > cu:~# xfs_freeze -f /huge > cu:~# /usr/net/bin/hibernate > [but this doesn't even hibernate - same as the 'touch'] I suspect that the frozen filesystem might cause other problems in the hibernate process. However, while a freeze calls sync_blockdev() it does not trim the dentry cache..... So, rather than a remount before hibernate, lets see if we can remove the dentries some other way to determine if removing excess dentries/inodes from the caches makes a difference. Can you do: # touch /huge/foo # sync # echo 1 > /proc/sys/vm/drop_caches # hibernate # touch /huge/bar # sync # echo 2 > /proc/sys/vm/drop_caches # hibernate # touch /huge/baz # sync # echo 3 > /proc/sys/vm/drop_caches # hibernate And see if any of those survive the suspend/resume? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jun 7 16:24:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 16:24:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l57NOTWt025708 for ; Thu, 7 Jun 2007 16:24:30 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA22930; Fri, 8 Jun 2007 09:24:22 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l57NOKAf117183128; Fri, 8 Jun 2007 09:24:21 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l57NOI61117076029; Fri, 8 Jun 2007 09:24:18 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 8 Jun 2007 09:24:18 +1000 From: David Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] kill macro noise in xfs_dir2*.h Message-ID: <20070607232418.GJ85884050@sgi.com> References: <20070418175859.GB18315@lst.de> <20070604143602.GA9081@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604143602.GA9081@lst.de> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11688 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 04:36:02PM +0200, Christoph Hellwig wrote: > On Wed, Apr 18, 2007 at 07:59:00PM +0200, Christoph Hellwig wrote: > > Remove all the macros that just give inline functions uppercase names. > > > > Signed-off-by: Christoph Hellwig > > This patch still hasn't made it to mainline, so here's a version > rediffed for latest mainline because it's required for the next patch It's in my test tree - I just haven't had a chance to review it properly and check it in yet because of all the other stuff I've got to do right now. Cleanups are not high priority compared to finding and fixing the numerous data corruption problems that have been uncovered recently... At least it's being QA'd regularly. ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jun 7 16:27:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 16:27:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l57NROWt027299 for ; Thu, 7 Jun 2007 16:27:25 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA22989; Fri, 8 Jun 2007 09:27:20 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l57NRIAf117166048; Fri, 8 Jun 2007 09:27:19 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l57NRGoG117141858; Fri, 8 Jun 2007 09:27:16 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 8 Jun 2007 09:27:16 +1000 From: David Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] use filldir internally Message-ID: <20070607232716.GK85884050@sgi.com> References: <20070604143958.GB9081@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604143958.GB9081@lst.de> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11689 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 04:39:58PM +0200, Christoph Hellwig wrote: > Currently xfs has a rather complicated internal scheme to allow for > different directory formats in IRIX. This patch rips all code related > to this out and pushes useage of the Linux filldir callback into the > lowlevel directory code. This does not make the code any less portable > because filldir can be used to create dirents of all possible variations > (including the IRIX ones as proved by the IRIX binary emulation code > under arch/mips/). > > This patch get rid of an unessecary copy in the readdir path, about > 250 lines of code and one of the last two users of the uio structure. Looks like a nice cleanup at a quick glance, but I need to spend more time looking at it which I don't have right now. I'll add it to my QA in the meantime.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jun 7 17:21:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 17:21:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l580L2Wt006351 for ; Thu, 7 Jun 2007 17:21:04 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA24352; Fri, 8 Jun 2007 10:20:53 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l580KpAf117146869; Fri, 8 Jun 2007 10:20:52 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l580KnVi115373524; Fri, 8 Jun 2007 10:20:49 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 8 Jun 2007 10:20:49 +1000 From: David Chinner To: David Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] use filldir internally Message-ID: <20070608002049.GM85884050@sgi.com> References: <20070604143958.GB9081@lst.de> <20070607232716.GK85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070607232716.GK85884050@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11690 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Jun 08, 2007 at 09:27:16AM +1000, David Chinner wrote: > On Mon, Jun 04, 2007 at 04:39:58PM +0200, Christoph Hellwig wrote: > > Currently xfs has a rather complicated internal scheme to allow for > > different directory formats in IRIX. This patch rips all code related > > to this out and pushes useage of the Linux filldir callback into the > > lowlevel directory code. This does not make the code any less portable > > because filldir can be used to create dirents of all possible variations > > (including the IRIX ones as proved by the IRIX binary emulation code > > under arch/mips/). > > > > This patch get rid of an unessecary copy in the readdir path, about > > 250 lines of code and one of the last two users of the uio structure. > > Looks like a nice cleanup at a quick glance, but I need to spend more time > looking at it which I don't have right now. I'll add it to my QA in the > meantime.... FYI: CC fs/xfs/linux-2.6/xfs_file.o fs/xfs/linux-2.6/xfs_file.c: In function "xfs_file_readdir": fs/xfs/linux-2.6/xfs_file.c:289: warning: passing argument 4 of â(vp->v_bh.bh_first->bd_ops)->vop_readdirâ from incompatible pointer type loff_t * for f_pos, vs xfs_off_t * which is what the interface is defined to take. typedef __kernel_loff_t loff_t; typedef long long __kernel_loff_t; typedef __s64 xfs_off_t; So they are both signed 64 bit types on all platforms so the compiler warning is spurious. Just add a cast to bhv_vop_readdir()? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jun 7 17:39:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 17:40:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l580dtWt011168 for ; Thu, 7 Jun 2007 17:39:57 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA24781; Fri, 8 Jun 2007 10:39:45 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l580dhAf116632057; Fri, 8 Jun 2007 10:39:44 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l580dfW5117130920; Fri, 8 Jun 2007 10:39:41 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 8 Jun 2007 10:39:41 +1000 From: David Chinner To: David Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] use filldir internally Message-ID: <20070608003941.GN85884050@sgi.com> References: <20070604143958.GB9081@lst.de> <20070607232716.GK85884050@sgi.com> <20070608002049.GM85884050@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070608002049.GM85884050@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11691 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Jun 08, 2007 at 10:20:49AM +1000, David Chinner wrote: > On Fri, Jun 08, 2007 at 09:27:16AM +1000, David Chinner wrote: > > On Mon, Jun 04, 2007 at 04:39:58PM +0200, Christoph Hellwig wrote: > > > Currently xfs has a rather complicated internal scheme to allow for > > > different directory formats in IRIX. This patch rips all code related > > > to this out and pushes useage of the Linux filldir callback into the > > > lowlevel directory code. This does not make the code any less portable > > > because filldir can be used to create dirents of all possible variations > > > (including the IRIX ones as proved by the IRIX binary emulation code > > > under arch/mips/). > > > > > > This patch get rid of an unessecary copy in the readdir path, about > > > 250 lines of code and one of the last two users of the uio structure. > > > > Looks like a nice cleanup at a quick glance, but I need to spend more time > > looking at it which I don't have right now. I'll add it to my QA in the > > meantime.... Hmmmm, this breaks dmapi which calls xfs_get_dirents() directly and that function was removed by this patch. I'm going to have to drop this patch for the moment because I don't have time to fix it up.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jun 7 21:03:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 21:03:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.2 required=5.0 tests=AWL,BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from psmtp09.wxs.nl (psmtp09.wxs.nl [195.121.247.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l5843kWt027652 for ; Thu, 7 Jun 2007 21:03:47 -0700 Received: from mail.deserver.nl (ip565e92ac.direct-adsl.nl [86.94.146.172]) by psmtp09.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JJA00CCSTY9M4@psmtp09.wxs.nl> for xfs@oss.sgi.com; Fri, 08 Jun 2007 06:03:46 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mail.deserver.nl (Postfix) with ESMTP id 662A8236CD for ; Fri, 08 Jun 2007 06:03:45 +0200 (CEST) Received: from [192.168.0.14] (unknown [192.168.0.14]) by mail.deserver.nl (Postfix) with ESMTP id 89C31236C4 for ; Fri, 08 Jun 2007 06:03:43 +0200 (CEST) Date: Fri, 08 Jun 2007 06:03:43 +0200 From: Jaap Struyk Subject: Re: ways to restore data from crashed disk In-reply-to: <46685C5F.5090804@sandeen.net> To: xfs@oss.sgi.com Message-id: <4668D51F.8010804@deserver.nl> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.0 (X11/20070326) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Scanned: by mailscan at deserver.nl X-Enigmail-Version: 0.95.0 References: <465EA882.3030403@deserver.nl> <465ECF9B.2000500@sandeen.net> <46684A9B.90908@deserver.nl> <46685C5F.5090804@sandeen.net> X-Virus-Status: Clean X-archive-position: 11692 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: japie@deserver.nl Precedence: bulk X-list: xfs Eric Sandeen schreef: > when you are talking about sizes, do you mean space used (du) or max > offset (ls -l?) max offset should be the same for your image file as > for your original device... 120G. ls -l But I don't know what tot trust anymore, if I look with gparted at my partitions the old disk gaves me a partition of 140G with 106G used space. My new disk has a partition of 200G with 166G used space. If I create a new xfs partition it has about 10% used space (according to gparted, I suspect thats the size of the logfiles?) so from the 166G on the new disk 146G is the "real" used space so that should be the size of the image file. (nomather what ls -l tells me) Is this correct? -- Groetjes Japie From owner-xfs@oss.sgi.com Thu Jun 7 22:28:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 22:28:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l585SLWt013610 for ; Thu, 7 Jun 2007 22:28:22 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA03067; Fri, 8 Jun 2007 15:28:14 +1000 Date: Fri, 08 Jun 2007 15:28:14 +1000 From: Timothy Shimmin To: David Chinner , xfs-dev cc: xfs-oss Subject: Re: Review: Be smarter about handling ENOSPC during writeback Message-ID: In-Reply-To: References: <20070604045219.GG86004887@sgi.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11693 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Hi Dave, Putting the xfs_reserve_blocks discussion to the side.... (discussed separately) Back to the review, looking at the changes: --On 4 June 2007 2:52:19 PM +1000 David Chinner wrote: > > During delayed allocation extent conversion or unwritten extent > conversion, we need to reserve some blocks for transactions > reservations. We need to reserve these blocks in case a btree > split occurs and we need to allocate some blocks. > > Unfortunately, we've only ever reserved the number of data blocks we > are allocating, so in both the unwritten and delalloc case we can > get ENOSPC to the transaction reservation. This is bad because in > both cases we cannot report the failure to the writing application. > > The fix is two-fold: > > 1 - leverage the reserved block infrastructure XFS already > has to reserve a small pool of blocks by default to allow > specially marked transactions to dip into when we are at > ENOSPC. > > Default setting is min(5%, 1024 blocks). > > 2 - convert critical transaction reservations to be allowed > to dip into this pool. Spots changed are delalloc > conversion, unwritten extent conversion and growing a > filesystem at ENOSPC. > > Comments? > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > --- > fs/xfs/xfs_fsops.c | 10 +++++++--- * allow xfs_reserve_blocks() to handle a null outval so that we can call xfs_reserve_blocks other than thru ioctl, where we don't care about outval * xfs_growfs_data_private() or's in XFS_TRANS_RESERVE like we do for root EAs -> allow growfs transaction to dip in to reserve space > fs/xfs/xfs_mount.c | 37 +++++++++++++++++++++++++++++++++++-- * xfs_mountfs(): cleanup - restrict a variable (ret64) to the block its used in * xfs_mountfs(): do our xfs_reserve_blocks() for what we think we'll need - pass NULL for 2nd param to it as we don't care (why we changed xfs_fsops.c) - defaults to min(1024 FSBs, 5% dblocks) -> not sure how one would choose this but it sounds big enough * xfs_unmountfs(): xfs_reserve_blocks of zero and so restoring the sb free counter Q: so I guess, for DMF systems which presumably turn this stuff on using the ioctl; we should tell them to stop doing this - they could stuff us up by overriding it maybe and they don't need to. > fs/xfs/xfs_iomap.c | 22 ++++++++-------------- * some whitespace cleanup xfs_iomap_write_allocate(): * delalloc extent conversion - mark transaction for reserved blocks space * don't handle ENOSPC here, as we shouldn't get it now I presume xfs_iomap_write_unwritten * unwritten extent conversion - mark trans for reserved blocks Seems simple enough :) Will we get questions from people about reduced space from df? :) --Tim > 3 files changed, 50 insertions(+), 19 deletions(-) > > Index: 2.6.x-xfs-new/fs/xfs/xfs_fsops.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_fsops.c 2007-05-11 10:35:29.288847149 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_fsops.c 2007-05-11 11:13:34.195363437 +1000 > @@ -179,6 +179,7 @@ xfs_growfs_data_private( > up_write(&mp->m_peraglock); > } > tp = xfs_trans_alloc(mp, XFS_TRANS_GROWFS); > + tp->t_flags |= XFS_TRANS_RESERVE; > if ((error = xfs_trans_reserve(tp, XFS_GROWFS_SPACE_RES(mp), > XFS_GROWDATA_LOG_RES(mp), 0, 0, 0))) { > xfs_trans_cancel(tp, 0); > @@ -500,8 +501,9 @@ xfs_reserve_blocks( > unsigned long s; > > /* If inval is null, report current values and return */ > - > if (inval == (__uint64_t *)NULL) { > + if (!outval) > + return EINVAL; > outval->resblks = mp->m_resblks; > outval->resblks_avail = mp->m_resblks_avail; > return 0; > @@ -564,8 +566,10 @@ retry: > } > } > out: > - outval->resblks = mp->m_resblks; > - outval->resblks_avail = mp->m_resblks_avail; > + if (outval) { > + outval->resblks = mp->m_resblks; > + outval->resblks_avail = mp->m_resblks_avail; > + } > XFS_SB_UNLOCK(mp, s); > > if (fdblks_delta) { > Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2007-05-11 10:35:29.292846630 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2007-05-11 11:13:47.229662318 +1000 > @@ -718,7 +718,7 @@ xfs_mountfs( > bhv_vnode_t *rvp = NULL; > int readio_log, writeio_log; > xfs_daddr_t d; > - __uint64_t ret64; > + __uint64_t resblks; > __int64_t update_flags; > uint quotamount, quotaflags; > int agno; > @@ -835,6 +835,7 @@ xfs_mountfs( > */ > if ((mfsi_flags & XFS_MFSI_SECOND) == 0 && > (mp->m_flags & XFS_MOUNT_NOUUID) == 0) { > + __uint64_t ret64; > if (xfs_uuid_mount(mp)) { > error = XFS_ERROR(EINVAL); > goto error1; > @@ -1127,13 +1128,27 @@ xfs_mountfs( > goto error4; > } > > - > /* > * Complete the quota initialisation, post-log-replay component. > */ > if ((error = XFS_QM_MOUNT(mp, quotamount, quotaflags, mfsi_flags))) > goto error4; > > + /* > + * Now we are mounted, reserve a small amount of unused space for > + * privileged transactions. This is needed so that transaction > + * space required for critical operations can dip into this pool > + * when at ENOSPC. This is needed for operations like create with > + * attr, unwritten extent conversion at ENOSPC, etc. Data allocations > + * are not allowed to use this reserved space. > + * > + * We default to 5% or 1024 fsbs of space reserved, whichever is smaller. > + * This may drive us straight to ENOSPC on mount, but that implies > + * we were already there on the last unmount. > + */ > + resblks = min_t(__uint64_t, mp->m_sb.sb_dblocks / 20, 1024); > + xfs_reserve_blocks(mp, &resblks, NULL); > + > return 0; > > error4: > @@ -1172,6 +1187,7 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr > #if defined(DEBUG) || defined(INDUCE_IO_ERROR) > int64_t fsid; > #endif > + __uint64_t resblks; > > /* > * We can potentially deadlock here if we have an inode cluster > @@ -1200,6 +1216,23 @@ xfs_unmountfs(xfs_mount_t *mp, struct cr > xfs_binval(mp->m_rtdev_targp); > } > > + /* > + * Unreserve any blocks we have so that when we unmount we don't account > + * the reserved free space as used. This is really only necessary for > + * lazy superblock counting because it trusts the incore superblock > + * counters to be aboslutely correct on clean unmount. > + * > + * We don't bother correcting this elsewhere for lazy superblock > + * counting because on mount of an unclean filesystem we reconstruct the > + * correct counter value and this is irrelevant. > + * > + * For non-lazy counter filesystems, this doesn't matter at all because > + * we only every apply deltas to the superblock and hence the incore > + * value does not matter.... > + */ > + resblks = 0; > + xfs_reserve_blocks(mp, &resblks, NULL); > + > xfs_log_sbcount(mp, 1); > xfs_unmountfs_writesb(mp); > xfs_unmountfs_wait(mp); /* wait for async bufs */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_iomap.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_iomap.c 2007-05-11 11:13:13.862017149 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_iomap.c 2007-05-11 11:13:34.199362915 +1000 > @@ -489,13 +489,13 @@ xfs_iomap_write_direct( > if (unlikely(rt)) { > resrtextents = qblocks = resaligned; > resrtextents /= mp->m_sb.sb_rextsize; > - resblks = XFS_DIOSTRAT_SPACE_RES(mp, 0); > - quota_flag = XFS_QMOPT_RES_RTBLKS; > - } else { > - resrtextents = 0; > + resblks = XFS_DIOSTRAT_SPACE_RES(mp, 0); > + quota_flag = XFS_QMOPT_RES_RTBLKS; > + } else { > + resrtextents = 0; > resblks = qblocks = XFS_DIOSTRAT_SPACE_RES(mp, resaligned); > - quota_flag = XFS_QMOPT_RES_REGBLKS; > - } > + quota_flag = XFS_QMOPT_RES_REGBLKS; > + } > > /* > * Allocate and setup the transaction > @@ -788,18 +788,12 @@ xfs_iomap_write_allocate( > nimaps = 0; > while (nimaps == 0) { > tp = xfs_trans_alloc(mp, XFS_TRANS_START_WRITE); > + tp->t_flags |= XFS_TRANS_RESERVE; > nres = XFS_EXTENTADD_SPACE_RES(mp, XFS_DATA_FORK); > error = xfs_trans_reserve(tp, nres, > XFS_WRITE_LOG_RES(mp), > 0, XFS_TRANS_PERM_LOG_RES, > XFS_WRITE_LOG_COUNT); > - if (error == ENOSPC) { > - error = xfs_trans_reserve(tp, 0, > - XFS_WRITE_LOG_RES(mp), > - 0, > - XFS_TRANS_PERM_LOG_RES, > - XFS_WRITE_LOG_COUNT); > - } > if (error) { > xfs_trans_cancel(tp, 0); > return XFS_ERROR(error); > @@ -917,8 +911,8 @@ xfs_iomap_write_unwritten( > * from unwritten to real. Do allocations in a loop until > * we have covered the range passed in. > */ > - > tp = xfs_trans_alloc(mp, XFS_TRANS_START_WRITE); > + tp->t_flags |= XFS_TRANS_RESERVE; > error = xfs_trans_reserve(tp, resblks, > XFS_WRITE_LOG_RES(mp), 0, > XFS_TRANS_PERM_LOG_RES, From owner-xfs@oss.sgi.com Thu Jun 7 23:24:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Jun 2007 23:24:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l586OfWt023758 for ; Thu, 7 Jun 2007 23:24:43 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA04426; Fri, 8 Jun 2007 16:24:34 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l586OWAf115248565; Fri, 8 Jun 2007 16:24:33 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l586OUaL115423795; Fri, 8 Jun 2007 16:24:30 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 8 Jun 2007 16:24:30 +1000 From: David Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] get rid of file_count abuse Message-ID: <20070608062430.GY86004887@sgi.com> References: <20070604143352.GA8721@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604143352.GA8721@lst.de> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11694 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jun 04, 2007 at 04:33:52PM +0200, Christoph Hellwig wrote: > A check for file_count is always a bad idea. Linux has the ->release > method to deal with cleanups on last close and ->flush is only for the > very rare case where we want to perform an operation on every drop of > a reference to a file struct. *nod* > This patch gets rid of vop_close and surrounding code in favour of > simply doing the page flushing from ->release. Added to my qa tree, and mangled to move the filestreams stuff from xfs_close to xfs_release as well. Thanks, Christoph. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Jun 8 00:33:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 00:33:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l587XkWt007805 for ; Fri, 8 Jun 2007 00:33:48 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA06910; Fri, 8 Jun 2007 17:33:45 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l587XiAf117249269; Fri, 8 Jun 2007 17:33:44 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l587Xgak115891519; Fri, 8 Jun 2007 17:33:42 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 8 Jun 2007 17:33:42 +1000 From: David Chinner To: Timothy Shimmin Cc: David Chinner , xfs-dev , xfs-oss Subject: Re: Review: Be smarter about handling ENOSPC during writeback Message-ID: <20070608073342.GW85884050@sgi.com> References: <20070604045219.GG86004887@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11695 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Jun 08, 2007 at 03:28:14PM +1000, Timothy Shimmin wrote: > Hi Dave, > > Putting the xfs_reserve_blocks discussion to the side.... > (discussed separately) *nod* BTW, did you try that patch I sent? > > fs/xfs/xfs_fsops.c | 10 +++++++--- > > * allow xfs_reserve_blocks() to handle a null outval so that > we can call xfs_reserve_blocks other than thru ioctl, > where we don't care about outval > * xfs_growfs_data_private() or's in XFS_TRANS_RESERVE like we do for root > EAs > -> allow growfs transaction to dip in to reserve space Yes, and so now you can grow a completely full filesystem :) > > fs/xfs/xfs_mount.c | 37 +++++++++++++++++++++++++++++++++++-- > > * xfs_mountfs(): cleanup - restrict a variable (ret64) to the block its > used in > * xfs_mountfs(): do our xfs_reserve_blocks() for what we think we'll need > - pass NULL for 2nd param to it as we don't care (why we changed > xfs_fsops.c) > - defaults to min(1024 FSBs, 5% dblocks) > -> not sure how one would choose this but it sounds big enough It's a SWAG. I think it's sufficient to begin with. If it proves to be a problem, then we can change it later.... > * xfs_unmountfs(): xfs_reserve_blocks of zero and so restoring the sb free > counter > > Q: so I guess, for DMF systems which presumably turn this stuff on using > the ioctl; yeah - the rope is long enough ;) > we should tell them to stop doing this - they could stuff us up by > overriding it > maybe and they don't need to. All they need to do is check first before setting a new value... > > fs/xfs/xfs_iomap.c | 22 ++++++++-------------- > > * some whitespace cleanup > xfs_iomap_write_allocate(): > * delalloc extent conversion - mark transaction for reserved blocks space > * don't handle ENOSPC here, as we shouldn't get it now I presume We still can, just much more unlikely. I need to do another set of patches for ENOSPC notification but I haven't had a chance yet. > xfs_iomap_write_unwritten > * unwritten extent conversion - mark trans for reserved blocks Ditto. > Seems simple enough :) It's just one of a few to begin with? > Will we get questions from people about reduced space from df? :) If we do, I think you just volunteered to write the FAQ entry ;) Thanks for the review. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Jun 8 00:53:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 00:53:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_50,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l587rVWt011344 for ; Fri, 8 Jun 2007 00:53:32 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA07763; Fri, 8 Jun 2007 17:53:27 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 35F7B58C38C1; Fri, 8 Jun 2007 17:53:27 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 963528 - xfs_growfs_data_private not logging agf length change Message-Id: <20070608075327.35F7B58C38C1@chook.melbourne.sgi.com> Date: Fri, 8 Jun 2007 17:53:27 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11696 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Log the agf_length change in xfs_growfs_data_private(). Date: Fri Jun 8 17:52:33 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs Inspected by: dgc@sgi.com,hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28856a fs/xfs/xfs_fsops.c - 1.125 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h - Log the agf_length change in xfs_growfs_data_private(). From owner-xfs@oss.sgi.com Fri Jun 8 01:35:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 01:35:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l588ZXWt018792 for ; Fri, 8 Jun 2007 01:35:35 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA10349; Fri, 8 Jun 2007 18:35:29 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id D7EC658C38F2; Fri, 8 Jun 2007 18:35:28 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 964538 - tail-pushing deadlock when flushing inodes on unmount Message-Id: <20070608083528.D7EC658C38F2@chook.melbourne.sgi.com> Date: Fri, 8 Jun 2007 18:35:28 +1000 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11697 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Prevent deadlock when flushing inodes on unmount When we are unmounting the filesystem, we flush all the inodes to disk. Unfortunately, if we have an inode cluster that has just been freed and marked stale sitting in an incore log buffer (i.e. hasn't been flushed to disk), it will be holding all the flush locks on the inodes in that cluster. xfs_iflush_all() which is called during unmount walks all the inodes trying to reclaim them, and it doing so calls xfs_finish_reclaim() on each inode. If the inode is dirty, if grabs the flush lock and flushes it. Unfortunately, find dirty inodes that already have their flush lock held and so we sleep. At this point in the unmount process, we are running single-threaded. There is nothing more that can push on the log to force the transaction holding the inode flush locks to disk and hence we deadlock. The fix is to issue a log force before flushing the inodes on unmount so that all the flush locks will be released before we start flushing the inodes. Date: Fri Jun 8 18:34:39 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28862a fs/xfs/xfs_mount.c - 1.396 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.396&r2=text&tr2=1.395&f=h - Force the log before we flush all the inodes on unmount to prevent a deadlock if any inode flush locks are held by transactions that are not yet on disk. From owner-xfs@oss.sgi.com Fri Jun 8 01:44:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 01:44:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l588ihWt020811 for ; Fri, 8 Jun 2007 01:44:44 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA11195; Fri, 8 Jun 2007 18:44:39 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 1558C58C38F3; Fri, 8 Jun 2007 18:44:38 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 964468 - XFS can ENOSPC in bad places Message-Id: <20070608084439.1558C58C38F3@chook.melbourne.sgi.com> Date: Fri, 8 Jun 2007 18:44:38 +1000 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11698 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Prevent ENOSPC from aborting transactions that need to succeed During delayed allocation extent conversion or unwritten extent conversion, we need to reserve some blocks for transactions reservations. We need to reserve these blocks in case a btree split occurs and we need to allocate some blocks. Unfortunately, we've only ever reserved the number of data blocks we are allocating, so in both the unwritten and delalloc case we can get ENOSPC to the transaction reservation. This is bad because in both cases we cannot report the failure to the writing application. The fix is two-fold: 1 - leverage the reserved block infrastructure XFS already has to reserve a small pool of blocks by default to allow specially marked transactions to dip into when we are at ENOSPC. Default setting is min(5%, 1024 blocks). 2 - convert critical transaction reservations to be allowed to dip into this pool. Spots changed are delalloc conversion, unwritten extent conversion and growing a filesystem at ENOSPC. This also allows growing the filesytsem to succeed at ENOSPC. Date: Fri Jun 8 18:44:10 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28865a fs/xfs/xfs_mount.c - 1.397 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.397&r2=text&tr2=1.396&f=h - reserve a small amount of disk blocks by default to use in emergency ENOSPC situations. fs/xfs/xfs_fsops.c - 1.126 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h - Allow growfs transaction to use reserved space. fs/xfs/xfs_iomap.c - 1.53 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h - Allow unwritten extent conversion and delayed allocation tranactions to use reserved space instead of silently failing at ENOSPC. From owner-xfs@oss.sgi.com Fri Jun 8 01:52:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 01:52:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=AWL,BAYES_95,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l588q6Wt022501 for ; Fri, 8 Jun 2007 01:52:08 -0700 Received: by ug-out-1314.google.com with SMTP id 74so1052176ugb for ; Fri, 08 Jun 2007 01:52:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=l+hkMqNQSlCffzVw4PM5LprHWtx4J3Qa7r5Yzg8sTKjztjvweDzUQpRCiZSqe2y3P3m0c1vsnQxJVUq0kp9+X7TYm40uLbL62uJDVH2Q2laSsJIVfJb9OGdz/I3zRDnLyQYtJ+NnGnG22MQmiKLoeOvISDBSEV0wJ9/+O7xKEoo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=aJiW94djuLDMCsrCU+/8vzLqjVEbn3v6zcj9/PZnkzfQHQ9VKRfQcApKnfwxhm00Jf2ITUSukWLuARmM364P8VHBU1BYW7rNyFIbl0pAZT6QgBLYJ9uCDebK273/0Tt+ovOCOH8WO999Qr9m8u1VuxoJ2NbzBwfopvmln8vDRaA= Received: by 10.66.248.8 with SMTP id v8mr1809102ugh.1181291038937; Fri, 08 Jun 2007 01:23:58 -0700 (PDT) Received: from ?192.168.1.10? ( [84.59.101.174]) by mx.google.com with ESMTP id 27sm4511853ugp.2007.06.08.01.23.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 Jun 2007 01:23:56 -0700 (PDT) Subject: Re: XFS shrink functionality From: Ruben Porras To: Iustin Pop Cc: David Chinner , xfs@oss.sgi.com, cw@f00f.org In-Reply-To: <20070604084154.GA8273@teal.hq.k1024.org> References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> <20070604084154.GA8273@teal.hq.k1024.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LdQDPymmi+rBggGPnr8T" Date: Fri, 08 Jun 2007 10:23:53 +0200 Message-Id: <1181291033.7510.40.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11699 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nahoo82@gmail.com Precedence: bulk X-list: xfs --=-LdQDPymmi+rBggGPnr8T Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Am Montag, den 04.06.2007, 10:41 +0200 schrieb Iustin Pop: > Good to know. If there is at least more documentation about the > internals, I could try to find some time to work on this again. there is now a document explaining the XFS on disk format [0] and some presentations for training courses, I think none of this were available at the time you made the first try. Although they are not enough for our purpose.=20 > My suggestion would be to start implementing these steps in reverse. 4) > is the most important as it touches the entire FS. If 4) is working > correctly, then 1) would be simpler (I think) Why do you think that 1) would be simpler after 4)? For what I understand, they are independent. 3) worries me, if walking the entire filesystem is needed, it want scale... =20=20 Since I don't know yet the xfs code I would like to begin with 1), I see it independent from the other parts, and I can then learn more about the transactions, allocators, and walking through the xfs structures. As you did 4) one time, maybe you could try with this part of the problem if you find the needed time, taking David's suggestions into account. [0] http://oss.sgi.com/projects/xfs/papers/xfs_filesystem_structure.pdf Cheers -- Ruben Porras LinWorks GmbH --=-LdQDPymmi+rBggGPnr8T Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGaRIZYubrKblAx+oRAgScAJ908dJzI9U9BLjh5ePQZkp6AfjSSgCgh6gL 5ON+D15BpF2nkNqM/LCiM8w= =b01I -----END PGP SIGNATURE----- --=-LdQDPymmi+rBggGPnr8T-- From owner-xfs@oss.sgi.com Fri Jun 8 02:01:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 02:01:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l5890xWt024214 for ; Fri, 8 Jun 2007 02:01:00 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11950; Fri, 8 Jun 2007 19:00:55 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 7309658C38F3; Fri, 8 Jun 2007 19:00:55 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 966004 - cleanup obtaining extent size hints from the inode Message-Id: <20070608090055.7309658C38F3@chook.melbourne.sgi.com> Date: Fri, 8 Jun 2007 19:00:55 +1000 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11700 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Cleanup inode extent size hint extraction Date: Fri Jun 8 19:00:21 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28866a fs/xfs/xfs_rw.h - 1.82 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rw.h.diff?r1=text&tr1=1.82&r2=text&tr2=1.81&f=h - Define a common function for extracting the valid extent size hint from a given inode. fs/xfs/xfs_vnodeops.c - 1.698 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.698&r2=text&tr2=1.697&f=h - Use xfs_get_extsz_hint rather than open coded statements. fs/xfs/xfs_bmap.c - 1.369 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.369&r2=text&tr2=1.368&f=h - Use xfs_get_extsz_hint rather than open coded statements. fs/xfs/xfs_iomap.c - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h - Use xfs_get_extsz_hint rather than open coded statements. From owner-xfs@oss.sgi.com Fri Jun 8 02:39:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 02:39:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_72, URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l589dPWt030741 for ; Fri, 8 Jun 2007 02:39:26 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA13459; Fri, 8 Jun 2007 19:39:20 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id CA13C58C38C1; Fri, 8 Jun 2007 19:39:20 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 964464 - remount r/o path has same flush problems as freeze path Message-Id: <20070608093920.CA13C58C38C1@chook.melbourne.sgi.com> Date: Fri, 8 Jun 2007 19:39:20 +1000 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11701 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Fix remount,readonly path to flush everything correctly. The remount readonly path can fail to writeback properly because we still have active transactions after calling xfs_quiesce_fs(). Further investigation shows that this path is broken in the same ways that the xfs freeze path was broken so fix it the same way. Date: Fri Jun 8 19:38:52 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28869a fs/xfs/xfs_vfsops.c - 1.521 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.521&r2=text&tr2=1.520&f=h - Modify remount,ro path to use data and inode quiesce code. Factor common inode quiesce code. fs/xfs/linux-2.6/xfs_vfs.h - 1.71 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h - Define data and inode quiesce flush flags and document what they do. fs/xfs/linux-2.6/xfs_super.c - 1.383 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.383&r2=text&tr2=1.382&f=h - Clean up data quiesce flags. From owner-xfs@oss.sgi.com Fri Jun 8 02:43:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 02:43:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l589hNWt031969 for ; Fri, 8 Jun 2007 02:43:25 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA13530; Fri, 8 Jun 2007 19:43:19 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 924C058C38C1; Fri, 8 Jun 2007 19:43:19 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 965784 - i386 linker error: xfs_dm_punch_hole - undefined ref to `__divdi3' Message-Id: <20070608094319.924C058C38C1@chook.melbourne.sgi.com> Date: Fri, 8 Jun 2007 19:43:19 +1000 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11702 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Fix i386 dmapi build - use roundup_64 for 64 bit types. Date: Fri Jun 8 19:42:38 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: donaldd@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28870a fs/xfs/dmapi/xfs_dm.c - 1.37 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h - Use roundup_64() instead of roundup() which cannot handle 64 bit types on 32bit platforms. From owner-xfs@oss.sgi.com Fri Jun 8 03:15:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 03:15:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.7 required=5.0 tests=AWL,BAYES_99,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l58AFdWt005106 for ; Fri, 8 Jun 2007 03:15:41 -0700 Received: from teal.hq.k1024.org (84-75-124-135.dclient.hispeed.ch [84.75.124.135]) by astra.simleu.ro (Postfix) with ESMTP id 67DD0134; Fri, 8 Jun 2007 13:15:39 +0300 (EEST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id CEC8C40FE2A; Fri, 8 Jun 2007 12:15:32 +0200 (CEST) Date: Fri, 8 Jun 2007 12:15:32 +0200 From: Iustin Pop To: Ruben Porras Cc: David Chinner , xfs@oss.sgi.com, cw@f00f.org Subject: Re: XFS shrink functionality Message-ID: <20070608101532.GA18788@teal.hq.k1024.org> Mail-Followup-To: Ruben Porras , David Chinner , xfs@oss.sgi.com, cw@f00f.org References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> <20070604084154.GA8273@teal.hq.k1024.org> <1181291033.7510.40.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1181291033.7510.40.camel@localhost> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11703 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Fri, Jun 08, 2007 at 10:23:53AM +0200, Ruben Porras wrote: > Am Montag, den 04.06.2007, 10:41 +0200 schrieb Iustin Pop: > > Good to know. If there is at least more documentation about the > > internals, I could try to find some time to work on this again. > > there is now a document explaining the XFS on disk format [0] and some > presentations for training courses, I think none of this were available > at the time you made the first try. Although they are not enough for our > purpose. > Yes, just yesterday I found the document and it helps. > > My suggestion would be to start implementing these steps in reverse. 4) > > is the most important as it touches the entire FS. If 4) is working > > correctly, then 1) would be simpler (I think) > > Why do you think that 1) would be simpler after 4)? For what I > understand, they are independent. Not after that in the cronological sense, but in the importance part. Yes, it was a bad choice of words. > 3) worries me, if walking the entire filesystem is needed, it want > scale... > > Since I don't know yet the xfs code I would like to begin with 1), I see > it independent from the other parts, and I can then learn more about the > transactions, allocators, and walking through the xfs structures. As you > did 4) one time, maybe you could try with this part of the problem if > you find the needed time, taking David's suggestions into account. I took a look at both items since this discussion started. And honestly, I think 1) is harder that 4), so you're welcome to work on it :) The points that make it harder is that, per David's suggestion, there needs to be: - define two new transaction types - define two new ioctls - update the ondisk-format (!), if we want persistence of these flags; luckily, there are two spare fields in the AGF structure. - check the list of allocation functions that allocate space from the AG I did some preliminary work on this but just a little. I think that after the weekend I'll send an updated patch of 4). I have one working now with the current CVS tree, just that it's still ugly and needs polishing. Open questions (re. point 4): - the filesystem document says the agf->agf_btreeblks is held only in case we have an extended flag active for the filesystem (XFS_SB_VERSION2_LAZYSBCOUNTBIT); is this true? without this, I'm not sure how to calculate this number of blocks nicely - or can I assume that an empty AG will *always* have agf_levels = 1 for both Btrees, so there are no extra blocks actually used for the btrees (except for the two reserved ones at the beggining of the AG - can I assume that an AG with agi->icount == agi->ifree == 0 will have no blocks used for the inode btrees (logically yes, but I'm not sure) thanks, iustin From owner-xfs@oss.sgi.com Fri Jun 8 06:59:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 06:59:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_45, URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from bay0-omc1-s13.bay0.hotmail.com (bay0-omc1-s13.bay0.hotmail.com [65.54.246.85]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l58DxcWt010121 for ; Fri, 8 Jun 2007 06:59:40 -0700 Received: from hotmail.com ([65.54.174.86]) by bay0-omc1-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 8 Jun 2007 06:59:38 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 8 Jun 2007 06:59:38 -0700 Message-ID: Received: from 85.36.106.214 by BAY103-DAV14.phx.gbl with DAV; Fri, 08 Jun 2007 13:59:37 +0000 X-Originating-IP: [85.36.106.214] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: "David Chinner" Cc: "David Chinner" , , , "Marco Berizzi" References: <20070316012520.GN5743@melbourne.sgi.com> <20070316195951.GB5743@melbourne.sgi.com> <20070320064632.GO32602149@melbourne.sgi.com> <20070607130505.GE85884050@sgi.com> Subject: Re: XFS internal error xfs_da_do_buf(2) at line 2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b00bd Date: Fri, 8 Jun 2007 15:59:39 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 08 Jun 2007 13:59:38.0538 (UTC) FILETIME=[40E758A0:01C7A9D5] X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11704 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs David Chinner wrote: > > Jun 6 09:47:09 Pleiadi kernel: ======================= > > Jun 6 09:47:09 Pleiadi kernel: 0x0: 28 f1 45 d4 22 53 35 11 09 80 37 5a > > 47 8a 22 ee > > Jun 6 09:47:09 Pleiadi kernel: Filesystem "sda8": XFS internal error > > xfs_da_do_buf(2) at line 2086 of file fs/xfs/xfs_da_btree.c. Caller > > 0xc01b2301 > > Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_do_buf+0x70c/0x7b1 > > Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_read_buf+0x30/0x35 > > Jun 6 09:47:09 Pleiadi kernel: [] xfs_da_read_buf+0x30/0x35 > > These above stack trace is the sign of a corrupted directory. > > Chopping out the rest of the top posting (please don't do that) apologies > we get down to 3 months ago: > > > > On Mon, Mar 19, 2007 at 11:32:27AM +0100, Marco Berizzi wrote: > > > > Marco Berizzi wrote: > > > > Here is the relevant results: > > > > > > > > Phase 2 - found root inode chunk > > > > Phase 3 - ... > > > > agno = 0 > > > > ... > > > > agno = 12 > > > > LEAFN node level is 1 inode 1610612918 bno = 8388608 > > > > > > Hmmm - single bit error in the bno - that reminds of this: > > > > > > http://oss.sgi.com/projects/xfs/faq.html#dir2 > > > > > > So I'd definitely make sure that is repaired.... > > Where we saw signs of on disk directory corruption. Have you run > xfs_repair successfully on the filesystem since you reported > this? yes. > If you did clean up the error, does xfs_repair report the same sort > of error again? I have run xfs_repair this morning. Here is the report: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done > Have you run a 2.6.16-rcX or 2.6.17.[0-6] kernel since you last > reported this problem? No. I have run only 2.6.19.x and 2.6.21.x After the xfs_repair I have remounted the file system. After few hours linux has crashed with this message: BUG: at arch/i386/kernel/smp.c:546 smp_call_function() I have also the monitor bitmap. From owner-xfs@oss.sgi.com Fri Jun 8 07:45:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 07:45:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l58EjEWt017931 for ; Fri, 8 Jun 2007 07:45:15 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA19896; Sat, 9 Jun 2007 00:45:03 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l58EiwAf117628356; Sat, 9 Jun 2007 00:45:00 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l58EitYa117895070; Sat, 9 Jun 2007 00:44:55 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sat, 9 Jun 2007 00:44:55 +1000 From: David Chinner To: Ruben Porras Cc: Iustin Pop , David Chinner , xfs@oss.sgi.com, cw@f00f.org Subject: Re: XFS shrink functionality Message-ID: <20070608144455.GE86004887@sgi.com> References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> <20070604084154.GA8273@teal.hq.k1024.org> <1181291033.7510.40.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1181291033.7510.40.camel@localhost> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11705 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Jun 08, 2007 at 10:23:53AM +0200, Ruben Porras wrote: > Am Montag, den 04.06.2007, 10:41 +0200 schrieb Iustin Pop: > > Good to know. If there is at least more documentation about the > > internals, I could try to find some time to work on this again. > > there is now a document explaining the XFS on disk format [0] and some > presentations for training courses, I think none of this were available > at the time you made the first try. Although they are not enough for our > purpose. There's thousands of lines of code documenting that format as well ;) > > My suggestion would be to start implementing these steps in reverse. 4) > > is the most important as it touches the entire FS. If 4) is working > > correctly, then 1) would be simpler (I think) > > Why do you think that 1) would be simpler after 4)? For what I > understand, they are independent. > > 3) worries me, if walking the entire filesystem is needed, it want > scale... I think walking the filesystem can be avoided effectively by introducing an reverse map that points to the owner of the block. (i.e. another btree). Reverse mapping provides other benefits as well e.g. somewhere to put block checksums and more information for repair and scrubbing. The hard part is the moving of metadata. I haven't really though deeply on the best method for this; there's lots of options and I don't know what is the best way to proceed there yet. That's not something I need to think about right now, though ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Jun 8 08:12:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 08:12:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l58FCYWt022306 for ; Fri, 8 Jun 2007 08:12:36 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA20640; Sat, 9 Jun 2007 01:12:28 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l58FCQAf117389659; Sat, 9 Jun 2007 01:12:27 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l58FCNN8116731816; Sat, 9 Jun 2007 01:12:23 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sat, 9 Jun 2007 01:12:23 +1000 From: David Chinner To: Ruben Porras , David Chinner , xfs@oss.sgi.com, cw@f00f.org Subject: Re: XFS shrink functionality Message-ID: <20070608151223.GF86004887@sgi.com> References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> <20070604084154.GA8273@teal.hq.k1024.org> <1181291033.7510.40.camel@localhost> <20070608101532.GA18788@teal.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070608101532.GA18788@teal.hq.k1024.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11706 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Jun 08, 2007 at 12:15:32PM +0200, Iustin Pop wrote: > On Fri, Jun 08, 2007 at 10:23:53AM +0200, Ruben Porras wrote: > > Am Montag, den 04.06.2007, 10:41 +0200 schrieb Iustin Pop: > > > Good to know. If there is at least more documentation about the > > > internals, I could try to find some time to work on this again. > > > > there is now a document explaining the XFS on disk format [0] and some > > presentations for training courses, I think none of this were available > > at the time you made the first try. Although they are not enough for our > > purpose. > > > > Yes, just yesterday I found the document and it helps. > > > > My suggestion would be to start implementing these steps in reverse. 4) > > > is the most important as it touches the entire FS. If 4) is working > > > correctly, then 1) would be simpler (I think) > > > > Why do you think that 1) would be simpler after 4)? For what I > > understand, they are independent. > Not after that in the cronological sense, but in the importance part. > Yes, it was a bad choice of words. > > > 3) worries me, if walking the entire filesystem is needed, it want > > scale... > > > > Since I don't know yet the xfs code I would like to begin with 1), I see > > it independent from the other parts, and I can then learn more about the > > transactions, allocators, and walking through the xfs structures. As you > > did 4) one time, maybe you could try with this part of the problem if > > you find the needed time, taking David's suggestions into account. > > I took a look at both items since this discussion started. And honestly, > I think 1) is harder that 4), so you're welcome to work on it :) The > points that make it harder is that, per David's suggestion, there needs > to be: > - define two new transaction types one new transaction type: XFS_TRANS_AGF_FLAGS and and extension to xfs_alloc_log_agf(). Is about all that is needed there. See the patch here: http://oss.sgi.com/archives/xfs/2007-04/msg00103.html For an example of a very simlar transaction to what is needed (look at xfs_log_sbcount()) and very similar addition to the AGF (xfs_btreeblks). > - define two new ioctls XFS_IOC_ALLOC_ALLOW_AG, parameter xfsagnumber_t. XFS_IOC_ALLOC_DENY_AG, parameter xfsagnumber_t. > - update the ondisk-format (!), if we want persistence of these flags; > luckily, there are two spare fields in the AGF structure. Better to expand, I think. The AGF is a sector in length - we can expand the structure as we need to this size without fear, esp. as the part of the sector outside the structure is guaranteed to be zero. i.e. we can add a fields flag to the end of the AGF structure - old filesystems simple read as "no flags set" and old kernels never look at those bits.... > - check the list of allocation functions that allocate space from the > AG > I did some preliminary work on this but just a little. > > I think that after the weekend I'll send an updated patch of 4). I have > one working now with the current CVS tree, just that it's still ugly and > needs polishing. > > Open questions (re. point 4): > - the filesystem document says the agf->agf_btreeblks is held only in > case we have an extended flag active for the filesystem > (XFS_SB_VERSION2_LAZYSBCOUNTBIT); is this true? without this, I'm not > sure how to calculate this number of blocks nicely Yes, that is true. There's a pre-req for shrinking for the moment :/ > - or can I assume that an empty AG will *always* have agf_levels = 1 > for both Btrees, so there are no extra blocks actually used for the > btrees (except for the two reserved ones at the beggining of the AG Yes, that is a valid assumption. > - can I assume that an AG with agi->icount == agi->ifree == 0 will have > no blocks used for the inode btrees (logically yes, but I'm not sure) yes. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Jun 8 08:19:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 08:19:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from webmail3.sd.dreamhost.com (webmail3.sd.dreamhost.com [64.111.100.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l58FJqWt027705 for ; Fri, 8 Jun 2007 08:19:52 -0700 Received: from webmail.ff-service-online.net (localhost [127.0.0.1]) by webmail3.sd.dreamhost.com (Postfix) with ESMTP id E169A142ED; Fri, 8 Jun 2007 08:07:20 -0700 (PDT) Received: from 80.88.141.75 (SquirrelMail authenticated user etrader@ff-service-online.net) by webmail.ff-service-online.net with HTTP; Fri, 8 Jun 2007 08:07:21 -0700 (PDT) Message-ID: <3199.80.88.141.75.1181315241.squirrel@webmail.ff-service-online.net> Date: Fri, 8 Jun 2007 08:07:21 -0700 (PDT) Subject: Assistance Needed.. From: "info@grandimport.com" Reply-To: donpard56@yahoo.com.mx User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: undisclosed-recipients:; X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11707 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Garrson@GrandImport.com Precedence: bulk X-list: xfs GRAND IMPORT AND EXPORT COMPANy I am Garry Anderson, we are a group of business enterpreneurs who deal on raw materials and export into america/europe. We are searching for representatives who can help us establish a medium of getting to our costumers in america/europe as well as making payments through you to us. Please if you are interested in transacting business with us we will be very glad. Please contact us for more information. Contact our procurement officer Mr.Don Lampard through the e-mail below: donpard56@yahoo.com.mx Tel: +(44) 704 572 2185 Fax: +(44) 871 263 6749 Subject to your satisfaction you will be given the opportunity to negotiate your mode of which we will pay for your services as our representative in america/europe. Please if you are interested forward to us your phone number/fax and your full contact addresses. Thanks Garry Anderson, President Units 2A & 2B, Olympic Way, Sefton Business Park, Aintree Liverpool, L30 1RD, UNITED KINGDOM +44-772-9380-810 GRAND IMPORT AND EXPORT Goods for Import / Export & Freight Fwdg. Svcs. --------- and --------------- President , Veinna M ARKET SOLUTIONS Import / Export & Freight Fwdg. Svcs From owner-xfs@oss.sgi.com Fri Jun 8 08:26:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 08:26:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from spitz.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l58FQkWt028881 for ; Fri, 8 Jun 2007 08:26:50 -0700 Received: by spitz.ucw.cz (Postfix, from userid 0) id B2A7B279F5; Thu, 7 Jun 2007 20:12:59 +0000 (UTC) Date: Thu, 7 Jun 2007 20:12:58 +0000 From: Pavel Machek To: David Greaves Cc: Tejun Heo , Linus Torvalds , "Rafael J. Wysocki" , xfs@oss.sgi.com, "'linux-kernel@vger.kernel.org'" , linux-pm , Neil Brown Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6) Message-ID: <20070607201258.GB10323@ucw.cz> References: <200706012342.45657.rjw@sisk.pl> <46609FAD.7010203@dgreaves.com> <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> <46668EE0.2030509@dgreaves.com> <46679D56.7040001@gmail.com> <4667DE2D.6050903@dgreaves.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4667DE2D.6050903@dgreaves.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11708 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pavel@ucw.cz Precedence: bulk X-list: xfs Hi! > >How hard does the machine freeze? Can you use sysrq? > >If so, please > >dump sysrq-t. > I suspect there is a problem writing to the consoles... > > I recompiled (rc4+patch) with sysrq support, suspended, > resumed and tried sysrq-t but got no output. > > I *can* change VTs and see the various login prompts, > bitmap messages and the console messages. Caps/Num lock > lights work. > > Fearing incompetence I tried sysrq-s sysrq-u sysrq-b and > got a reboot so sysrq is OK. Increase console loglevel by killing klogd/sysrq-9? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From owner-xfs@oss.sgi.com Fri Jun 8 08:58:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 08:58:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=AWL,BAYES_60,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l58FwDWt001714 for ; Fri, 8 Jun 2007 08:58:14 -0700 Received: from Liberator.local (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 5ECC9180741F8; Fri, 8 Jun 2007 10:58:12 -0500 (CDT) Message-ID: <46697C94.40401@sandeen.net> Date: Fri, 08 Jun 2007 10:58:12 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Jaap Struyk CC: xfs@oss.sgi.com Subject: Re: ways to restore data from crashed disk References: <465EA882.3030403@deserver.nl> <465ECF9B.2000500@sandeen.net> <46684A9B.90908@deserver.nl> <46685C5F.5090804@sandeen.net> <4668D51F.8010804@deserver.nl> In-Reply-To: <4668D51F.8010804@deserver.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11709 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Jaap Struyk wrote: > Eric Sandeen schreef: > >> when you are talking about sizes, do you mean space used (du) or max >> offset (ls -l?) max offset should be the same for your image file as >> for your original device... 120G. > > ls -l > But I don't know what tot trust anymore, if I look with gparted at my > partitions the old disk gaves me a partition of 140G with 106G used space. > My new disk has a partition of 200G with 166G used space. > If I create a new xfs partition it has about 10% used space (according > to gparted, I suspect thats the size of the logfiles?) so from the 166G > on the new disk 146G is the "real" used space so that should be the size > of the image file. (nomather what ls -l tells me) > Is this correct? Ok. repair is trying to read a superblock at: superblock read failed, offset 103376846848, size 2048, ag 11, rval 0 103376846848 bytes... or about 96 MB (base 2) (or 103 base 10) if ls -l on your image file is not at least that big, of course it can't read it. And if that's smaller than your filesystem, then the image isn't right... from your db output: xfs_db> sb 0 xfs_db> p magicnum = 0x58465342 blocksize = 4096 dblocks = 36710528 it looks like the original filesystem was bigger than your image: 4096*36710528 150366322688 <-- 140 MB so it looks like your image file is not correct... I'm not familiar with the tool you're using, is it somehow compressing a sparse file or something like that? -Eric From owner-xfs@oss.sgi.com Fri Jun 8 09:04:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 09:04:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.8 required=5.0 tests=AWL,BAYES_60,SPF_HELO_PASS, URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l58G3wWt002739 for ; Fri, 8 Jun 2007 09:03:59 -0700 Received: from teal.hq.k1024.org (84-75-124-135.dclient.hispeed.ch [84.75.124.135]) by astra.simleu.ro (Postfix) with ESMTP id 8345573; Fri, 8 Jun 2007 19:03:58 +0300 (EEST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 7E3A640FE2A; Fri, 8 Jun 2007 18:03:18 +0200 (CEST) Date: Fri, 8 Jun 2007 18:03:18 +0200 From: Iustin Pop To: David Chinner Cc: Ruben Porras , xfs@oss.sgi.com, cw@f00f.org Subject: Re: XFS shrink functionality Message-ID: <20070608160318.GA25579@teal.hq.k1024.org> Mail-Followup-To: David Chinner , Ruben Porras , xfs@oss.sgi.com, cw@f00f.org References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> <20070604084154.GA8273@teal.hq.k1024.org> <1181291033.7510.40.camel@localhost> <20070608101532.GA18788@teal.hq.k1024.org> <20070608151223.GF86004887@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070608151223.GF86004887@sgi.com> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11710 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Sat, Jun 09, 2007 at 01:12:23AM +1000, David Chinner wrote: > > I took a look at both items since this discussion started. And honestly, > > I think 1) is harder that 4), so you're welcome to work on it :) The > > points that make it harder is that, per David's suggestion, there needs > > to be: > > - define two new transaction types > > one new transaction type: > > XFS_TRANS_AGF_FLAGS > > and and extension to xfs_alloc_log_agf(). Is about all that is > needed there. > > See the patch here: > > http://oss.sgi.com/archives/xfs/2007-04/msg00103.html Ah, I see now. I was wondering how one can enable the new bits (CVS xfs_db shows the btreeblks but 'version' cmd doesn't allow to change them), it seems that manual xfs_db work + xfs_repair allows them. > For an example of a very simlar transaction to what is needed > (look at xfs_log_sbcount()) and very similar addition to > the AGF (xfs_btreeblks). Just a question: why do you think this per-ag-bit to be persistent? I'm just curious. When I first thought about this, I was thinking more like this should be an in-core flag only, like the freeze flag is for the filesystem. The idea being that you don't need to recover this state after a crash - there is no actual state, just restart the shrink operation if you want. And no actual filesystem state (e.g. space allocation or such) is happenning when you toggle the AGs not allocatable. This would allow a much simpler implementation of the 'no-alloc' part. > > - update the ondisk-format (!), if we want persistence of these flags; > > luckily, there are two spare fields in the AGF structure. > > Better to expand, I think. The AGF is a sector in length - we can > expand the structure as we need to this size without fear, esp. as > the part of the sector outside the structure is guaranteed to be > zero. i.e. we can add a fields flag to the end of the AGF > structure - old filesystems simple read as "no flags set" and > old kernels never look at those bits.... Yes, makes sense. Just to make sure: the xfs_agf_t, xfs_agi_t and xfs_sb_t structures as defined in xfs_sb.h and xfs_ag.h are what actually is on-disk, right? Adding to them, defining the new bits i.e. XFS_AGF_FLAGS and bumping up XFS_AGF_ALL_BITS should take care of the on-disk part? > > Open questions (re. point 4): > > - the filesystem document says the agf->agf_btreeblks is held only in > > case we have an extended flag active for the filesystem > > (XFS_SB_VERSION2_LAZYSBCOUNTBIT); is this true? without this, I'm not > > sure how to calculate this number of blocks nicely > > Yes, that is true. There's a pre-req for shrinking for the moment :/ > > > - or can I assume that an empty AG will *always* have agf_levels = 1 > > for both Btrees, so there are no extra blocks actually used for the > > btrees (except for the two reserved ones at the beggining of the AG > > Yes, that is a valid assumption. Ok, perfect. This then eliminates the need for LAZYSBCOUNTBIT. Just one more question: can I *read* from the mp->m_perag structure or do I need a lock (even for read), i.e. down_read, read the fields, up_read? (As you can see, I don't have much experience w.r.t. kernel programming). > > - can I assume that an AG with agi->icount == agi->ifree == 0 will have > > no blocks used for the inode btrees (logically yes, but I'm not sure) > > yes. Good. Thanks for your explanations. Patch for shrink if the AGs are empty will be simpler and nicer then as opposed to what I have now. iustin From owner-xfs@oss.sgi.com Fri Jun 8 11:59:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 11:59:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from web09.talkactive.net (web09.talkactive.net [195.128.174.109]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l58IxiWt032159 for ; Fri, 8 Jun 2007 11:59:45 -0700 Received: from web09.talkactive.net (localhost.talkactive.net [127.0.0.1]) by web09.talkactive.net (8.12.11/8.12.11) with ESMTP id l58IOD2H063775 for ; Fri, 8 Jun 2007 20:24:13 +0200 (CEST) (envelope-from wse35263.studioshania.com@web09.talkactive.net) Received: (from www@localhost) by web09.talkactive.net (8.12.11/8.12.11/Submit) id l58IOC0M063772; Fri, 8 Jun 2007 20:24:12 +0200 (CEST) (envelope-from wse35263.studioshania.com) Date: Fri, 8 Jun 2007 20:24:12 +0200 (CEST) Message-Id: <200706081824.l58IOC0M063772@web09.talkactive.net> X-Authentication-Warning: web09.talkactive.net: www set sender to wse35263.studioshania.com using -f To: xfs@oss.sgi.com Subject: Vacancy For Online Payroll Manager!!! From: "Kenneth Fabrics Ltd." Reply-To: kennethfabricsltdd@mail2recruiter.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11711 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: employment.dept@kennethfabricsltd.com.talkactive.net Precedence: bulk X-list: xfs From The Desk Of The: Recruitment Manager Mr. Kenneth Holley Kenneth Fabrics Limited. Dear Employee, KENNETH FABRICS LTD.Is committed to global citizenship by operating in a responsible and sustainable manner around the globe. As part of our Multi Level Marketing scheme, we need capable hands to act as representative/book keeper in the United Kingdom and Canada on the company's behalf. Kenneth Fabrics Ltd.. Is a new Store under KENNETH FARICS in India? We are into supplies of Raw Materials. We are ranked No.1 among India private enterprises with annual production capacity exceeding 1 million units sold everywhere in India and exported to all over the world including UK, Mexico, Southeast Asia countries and European countries. We have won a good reputation for high-quality products, prompt delivery and close cooperation among our customers. We needs a representative in the United states, United Kingdom, Canada, Mexico, Southeast Asia countries and European countries, to act as our Online Staff through which our customers can pay outstanding bills owed by them to us in your Region via Bank Wire Transfer. JOB DESCRIPTION: 1. Receive payment from Clients by wire transfer and Cheques 2. Deduct 10% which will be your commission on each payment processed. 3. Forward the balance after deducting of 10% commission to offices which shall be provided by you as soon as the fund becomes available. HOW MUCH WILL YOU EARN: 10% from each operation! For instance: you receive £ 5000 or $5000 via wire transfer Or Cheques on our behalf. You will cash the money and keep £ 500 or $500 (10% from £ 5000-$5000) for yourself! At the beginning your commission will equal 10%. After creditable performance, your commission may be reviewed for increment. We are looking only for the Honest and Open – Hearted Individual who satisfies our requirements and glad to offer this job position to you. If our proposals and Position interest you, Do get back to us with your under listed detailed information to Mr. Kenneth Holley on kennethfabricsltdd@mail2recruiter.com Names:.................. Address:................ City:................... Zip Code:............... State:.................. Country;................ Home Phone:............. Cell Phone:............. Gender:................. Age..................... Thanks for Reading Our Job Offer Kenneth Fabrics Limited 301-A, World Trade Tower Barakhamba Lane New Delhi -110001 India From owner-xfs@oss.sgi.com Fri Jun 8 12:09:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 12:09:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l58J9TWt001590 for ; Fri, 8 Jun 2007 12:09:30 -0700 Received: from localhost (mailman.ukfsn.org [80.168.53.75]) by mail.ukfsn.org (Postfix) with ESMTP id 445C9E6BCC; Fri, 8 Jun 2007 20:09:01 +0100 (BST) Received: from mail.ukfsn.org ([80.168.53.20]) by localhost (smtp-filter.ukfsn.org [80.168.53.75]) (amavisd-new, port 10024) with ESMTP id Iro7JFlI6S8m; Fri, 8 Jun 2007 20:06:49 +0100 (BST) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id D0498E6C2B; Fri, 8 Jun 2007 20:08:58 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1Hwjpu-0004YE-3G; Fri, 08 Jun 2007 20:09:26 +0100 Message-ID: <4669A965.20403@dgreaves.com> Date: Fri, 08 Jun 2007 20:09:25 +0100 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: David Chinner Cc: Tejun Heo , Linus Torvalds , "Rafael J. Wysocki" , xfs@oss.sgi.com, "'linux-kernel@vger.kernel.org'" , linux-pm , Neil Brown Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6) References: <200706020122.49989.rjw@sisk.pl> <4661EFBB.5010406@dgreaves.com> <4662D852.4000005@dgreaves.com> <46667160.80905@gmail.com> <46668EE0.2030509@dgreaves.com> <46679D56.7040001@gmail.com> <4667DE2D.6050903@dgreaves.com> <20070607110708.GS86004887@sgi.com> <46680F5E.6070806@dgreaves.com> <20070607222813.GG85884050@sgi.com> In-Reply-To: <20070607222813.GG85884050@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11712 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs I had this as a PS, then I thought, we could all be wasting our time... I don't like these "Section mismatch" warnings but that's because I'm paranoid rather than because I know what they mean. I'll be happier when someone says "That's OK, I know about them, they're not the problem" WARNING: arch/i386/kernel/built-in.o(.text+0x968f): Section mismatch: reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init') WARNING: arch/i386/kernel/built-in.o(.text+0x9781): Section mismatch: reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init') WARNING: arch/i386/kernel/built-in.o(.text+0x9786): Section mismatch: reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init') WARNING: arch/i386/kernel/built-in.o(.text+0xa25c): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: arch/i386/kernel/built-in.o(.text+0xa303): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: arch/i386/kernel/built-in.o(.text+0xa31b): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: arch/i386/kernel/built-in.o(.text+0xa344): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: arch/i386/kernel/built-in.o(.exit.text+0x19): Section mismatch: reference to .init.text: (between 'cache_remove_dev' and 'powernow_k6_exit') WARNING: arch/i386/kernel/built-in.o(.data+0x2160): Section mismatch: reference to .init.text: (between 'thermal_throttle_cpu_notifier' and 'mce_work') WARNING: kernel/built-in.o(.text+0x14502): Section mismatch: reference to .init.text: (between 'kthreadd' and 'init_waitqueue_head') Andrew Morton said a couple of weeks ago: > Could the people who write these bugs, please, like, fix them? > It's not trivial noise. These things lead to kernel crashes. Anyhow... David Chinner wrote: > sync just guarantees that metadata changes are logged and data is > on disk - it doesn't stop the filesystem from doing anything after > the sync... No, but there are no apps accessing the filesystem. It's just available for NFS serving. Seems safer before potentially hanging the machine? Also I made these changes to the kernel: cu:/boot# diff config-2.6.22-rc4-TejuTst-dbg3-dirty config-2.6.22-rc4-TejuTst-dbg1-dirty 3,4c3,4 < # Linux kernel version: 2.6.22-rc4-TejuTst-dbg3 < # Thu Jun 7 20:00:34 2007 --- > # Linux kernel version: 2.6.22-rc4-TejuTst3 > # Thu Jun 7 10:59:21 2007 242,244c242 < CONFIG_PM_DEBUG=y < CONFIG_DISABLE_CONSOLE_SUSPEND=y < # CONFIG_PM_TRACE is not set --- > # CONFIG_PM_DEBUG is not set positive: I can now get sysrq-t :) negative: if I build skge into the kernel the behaviour changes so I can't run netconsole Just to be sure I tested and this kernel suspends/restores with /huge unmounted. It also hangs without an umount so the behaviour is the same. > Ok, so a clean inode is sufficient to prevent hibernate from working. > > So, what's different between a sync and a remount? > > do_remount_sb() does: > > 599 shrink_dcache_sb(sb); > 600 fsync_super(sb); > > of which a sync does neither. sync does what fsync_super() does in > different sort of way, but does not call sync_blockdev() on each > block device. It looks like that is the two main differences between > sync and remount - remount trims the dentry cache and syncs the blockdev, > sync doesn't. > >>> What about freezing the filesystem? >> cu:~# xfs_freeze -f /huge >> cu:~# /usr/net/bin/hibernate >> [but this doesn't even hibernate - same as the 'touch'] > > I suspect that the frozen filesystem might cause other problems > in the hibernate process. However, while a freeze calls sync_blockdev() > it does not trim the dentry cache..... > > So, rather than a remount before hibernate, lets see if we can > remove the dentries some other way to determine if removing excess > dentries/inodes from the caches makes a difference. Can you do: > > # touch /huge/foo > # sync > # echo 1 > /proc/sys/vm/drop_caches > # hibernate success > > # touch /huge/bar > # sync > # echo 2 > /proc/sys/vm/drop_caches > # hibernate success > > # touch /huge/baz > # sync > # echo 3 > /proc/sys/vm/drop_caches > # hibernate success So I added # touch /huge/bork # sync # hibernate And it still succeeded - sigh. So I thought a bit and did: rm /huge/b* /huge/foo > Clean boot > # touch /huge/bar > # sync > # echo 2 > /proc/sys/vm/drop_caches > # hibernate hangs on suspend (sysrq-b doesn't work) > Clean boot > # touch /huge/baz > # sync > # echo 3 > /proc/sys/vm/drop_caches > # hibernate hangs on suspend (sysrq-b doesn't work) So I rebooted and hibernated to make sure I'm not having random behaviour - yep, hang on resume (as per usual). Now I wonder if any other mounts have an effect... reboot and umount /dev/hdb2 xfs fs, - hang on hibernate I'm confused. I'm going to order chinese takeaway and then find a serial cable... David PS 2.6.21.1 works fine. From owner-xfs@oss.sgi.com Fri Jun 8 12:47:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 12:47:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l58JleWt012890 for ; Fri, 8 Jun 2007 12:47:42 -0700 Received: by ug-out-1314.google.com with SMTP id 74so1211612ugb for ; Fri, 08 Jun 2007 12:47:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=EubcWQ0yEyBofEfnU54hnmsdVXIQoABXNn7IGN3Y3yBKyQ22ECl7cfd/pVcHW5emyIeUMlxqHuZZ+G0QliqzKpLXnVvLzbjCHPbrbcYRmZUW6KnxCDWsjTABC7nkew3aNflQnpGshyzVuyVqtxnljHPXFlU+0/mKKfOeya8K8YA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=UVrlTczKUm+FS2prASslsL1gZDODiNf3jUU5/tIoRgA5JMeyeelc0MI8bkHNyVqG3y/IIfPQcUqgMgxhBSskObEvE4DpNaWk4bO7LEDBlbVq+6jX7hQj81V6zlqUO0mH8ahg/3gATC2lrEKPdCkK7VJpu6iDV+UWKM3oplF88V0= Received: by 10.67.121.15 with SMTP id y15mr3004294ugm.1181332060820; Fri, 08 Jun 2007 12:47:40 -0700 (PDT) Received: from ?192.168.1.10? ( [84.59.115.46]) by mx.google.com with ESMTP id y7sm4136404ugc.2007.06.08.12.47.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 Jun 2007 12:47:40 -0700 (PDT) Subject: Re: XFS shrink functionality From: Ruben Porras To: David Chinner Cc: xfs@oss.sgi.com, cw@f00f.org In-Reply-To: <20070608151223.GF86004887@sgi.com> References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> <20070604084154.GA8273@teal.hq.k1024.org> <1181291033.7510.40.camel@localhost> <20070608101532.GA18788@teal.hq.k1024.org> <20070608151223.GF86004887@sgi.com> Content-Type: text/plain Date: Fri, 08 Jun 2007 21:47:38 +0200 Message-Id: <1181332058.6790.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11713 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nahoo82@gmail.com Precedence: bulk X-list: xfs Am Samstag, den 09.06.2007, 01:12 +1000 schrieb David Chinner: Thank you, these last mail explains the pieces I should do pretty well :) Cheers From owner-xfs@oss.sgi.com Fri Jun 8 19:15:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Jun 2007 19:15:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l592FnWt016208 for ; Fri, 8 Jun 2007 19:15:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06381; Sat, 9 Jun 2007 12:15:41 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l592FdAf118212540; Sat, 9 Jun 2007 12:15:39 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l592FZFC118181307; Sat, 9 Jun 2007 12:15:35 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sat, 9 Jun 2007 12:15:35 +1000 From: David Chinner To: David Chinner , Ruben Porras , xfs@oss.sgi.com, cw@f00f.org Subject: Re: XFS shrink functionality Message-ID: <20070609021535.GG86004887@sgi.com> References: <1180715974.10796.46.camel@localhost> <20070604001632.GA86004887@sgi.com> <20070604084154.GA8273@teal.hq.k1024.org> <1181291033.7510.40.camel@localhost> <20070608101532.GA18788@teal.hq.k1024.org> <20070608151223.GF86004887@sgi.com> <20070608160318.GA25579@teal.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070608160318.GA25579@teal.hq.k1024.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11714 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Jun 08, 2007 at 06:03:18PM +0200, Iustin Pop wrote: > On Sat, Jun 09, 2007 at 01:12:23AM +1000, David Chinner wrote: > > > I took a look at both items since this discussion started. And honestly, > > > I think 1) is harder that 4), so you're welcome to work on it :) The > > > points that make it harder is that, per David's suggestion, there needs > > > to be: > > > - define two new transaction types > > > > one new transaction type: > > > > XFS_TRANS_AGF_FLAGS > > > > and and extension to xfs_alloc_log_agf(). Is about all that is > > needed there. > > > > See the patch here: > > > > http://oss.sgi.com/archives/xfs/2007-04/msg00103.html > > Ah, I see now. I was wondering how one can enable the new bits (CVS > xfs_db shows the btreeblks but 'version' cmd doesn't allow to change > them), it seems that manual xfs_db work + xfs_repair allows them. The xfs_db work needs to be wrapped up in xfs_admin. That's relatively simple to do, but the repair stage is needed to count the btree blocks and update the counter in eah AGF. That could probably also be wrapped up in an xfs_db script so conversion wouldn't require you to run repair.... > > For an example of a very simlar transaction to what is needed > > (look at xfs_log_sbcount()) and very similar addition to > > the AGF (xfs_btreeblks). > Just a question: why do you think this per-ag-bit to be persistent? Shrinking is not the only reason why you might want to prevent allocation within an AG. While we might be able to get away with a totally in memory flag for a shrink, I really don't want to have multiple mechanisms for doing roughly the same thing. e.g. Think of fault tolerance - you detect a free space btree corruption, so you prevent allocation and freeing in that AG (by setting the relevant bits) until you can come along and repair it. If you want to do online repair of this sort of corruption, then you need to be able to stop the trees from being used between the time that the corruption is detected and the time it is repair. That may be longer than the filesystem is currently mounted... > I'm > just curious. When I first thought about this, I was thinking more like > this should be an in-core flag only, like the freeze flag is for the > filesystem. The idea being that you don't need to recover this state > after a crash But a freeze is different - it's not modifying the filesystem, just bringing it down into a consistent state. A shrink is a modification operation, and so if it crashes half way though, we need to ensure that recovery doesn't do silly things. Hence it is best to have all the state associated with the shrink journalled and recoverable. i.e. persistent. > - there is no actual state, just restart the shrink > operation if you want. And no actual filesystem state (e.g. space > allocation or such) is happenning when you toggle the AGs not > allocatable. This would allow a much simpler implementation of the > 'no-alloc' part. True, but much it would be much more limited in it's potential use. > > > - update the ondisk-format (!), if we want persistence of these flags; > > > luckily, there are two spare fields in the AGF structure. > > > > Better to expand, I think. The AGF is a sector in length - we can > > expand the structure as we need to this size without fear, esp. as > > the part of the sector outside the structure is guaranteed to be > > zero. i.e. we can add a fields flag to the end of the AGF > > structure - old filesystems simple read as "no flags set" and > > old kernels never look at those bits.... > Yes, makes sense. Just to make sure: the xfs_agf_t, xfs_agi_t and > xfs_sb_t structures as defined in xfs_sb.h and xfs_ag.h are what > actually is on-disk, right? Adding to them, defining the new bits i.e. > XFS_AGF_FLAGS and bumping up XFS_AGF_ALL_BITS should take care of the > on-disk part? Don't forget to modify xfs_alloc_log_agf() as well ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sat Jun 9 00:50:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 09 Jun 2007 00:50:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.4 required=5.0 tests=AWL,BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from psmtp08.wxs.nl (psmtp08.wxs.nl [195.121.247.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l597osWt001879 for ; Sat, 9 Jun 2007 00:50:56 -0700 Received: from mail.deserver.nl (ip565e92ac.direct-adsl.nl [86.94.146.172]) by psmtp08.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JJC00LE9Z4U9Z@psmtp08.wxs.nl> for xfs@oss.sgi.com; Sat, 09 Jun 2007 09:50:54 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mail.deserver.nl (Postfix) with ESMTP id 1E8B6236CE for ; Sat, 09 Jun 2007 09:50:54 +0200 (CEST) Received: from [192.168.0.14] (unknown [192.168.0.14]) by mail.deserver.nl (Postfix) with ESMTP id 484D2236C4 for ; Sat, 09 Jun 2007 09:50:51 +0200 (CEST) Date: Sat, 09 Jun 2007 09:50:49 +0200 From: Jaap Struyk Subject: Re: ways to restore data from crashed disk In-reply-to: <46697C94.40401@sandeen.net> To: xfs@oss.sgi.com Message-id: <466A5BD9.7010604@deserver.nl> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.0 (X11/20070326) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Scanned: by mailscan at deserver.nl X-Enigmail-Version: 0.95.0 References: <465EA882.3030403@deserver.nl> <465ECF9B.2000500@sandeen.net> <46684A9B.90908@deserver.nl> <46685C5F.5090804@sandeen.net> <4668D51F.8010804@deserver.nl> <46697C94.40401@sandeen.net> X-Virus-Status: Clean X-archive-position: 11715 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: japie@deserver.nl Precedence: bulk X-list: xfs Eric Sandeen schreef: > it looks like the original filesystem was bigger than your image: > > 4096*36710528 > 150366322688 <-- 140 MB > > so it looks like your image file is not correct... I'm not familiar with > the tool you're using, is it somehow compressing a sparse file or > something like that? You are completely right! I used dd_rhelp instead of dd_rescue since everytime a bad block is hit my disk isn't acceseble anymore and I have to reboot. So I tryed another aproach and used a knoppix cd to boot and used dd_rescue right away and with knoppix the disk keeps readable. (so it seems the kernel knoppix is using isn't killed by bad blocks, mine is) In concreto: I dumped my disk on another, used xfs_repair without problems and got almost all my data back (except for the last 2G that was written) Thanks for pointing me the right track, or else I was still wrestling to recover an incomplete image file! -- Groetjes Japie From owner-xfs@oss.sgi.com Sat Jun 9 03:26:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 09 Jun 2007 03:26:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l59AQbWt029229 for ; Sat, 9 Jun 2007 03:26:39 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l59AQbo6023340 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 9 Jun 2007 12:26:37 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l59AQboW023338 for xfs@oss.sgi.com; Sat, 9 Jun 2007 12:26:37 +0200 Date: Sat, 9 Jun 2007 12:26:37 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] fix 32bit build Message-ID: <20070609102637.GA23294@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11716 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_mount.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c 2007-06-09 11:20:51.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_mount.c 2007-06-09 11:21:43.000000000 +0200 @@ -1154,7 +1154,9 @@ xfs_mountfs( * This may drive us straight to ENOSPC on mount, but that implies * we were already there on the last unmount. */ - resblks = min_t(__uint64_t, mp->m_sb.sb_dblocks / 20, 1024); + resblks = mp->m_sb.sb_dblocks; + do_div(resblks, 20); + resblks = min_t(__uint64_t, resblks, 1024); xfs_reserve_blocks(mp, &resblks, NULL); return 0; From owner-xfs@oss.sgi.com Sun Jun 10 09:40:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 10 Jun 2007 09:40:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.1 required=5.0 tests=AWL,BAYES_99,J_CHICKENPOX_28, J_CHICKENPOX_34,J_CHICKENPOX_55,J_CHICKENPOX_65,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l5AGeoWt024818 for ; Sun, 10 Jun 2007 09:40:51 -0700 Received: from teal.hq.k1024.org (84-75-124-135.dclient.hispeed.ch [84.75.124.135]) by astra.simleu.ro (Postfix) with ESMTP id 7700A69 for ; Sun, 10 Jun 2007 19:40:45 +0300 (EEST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 01F8040A0A6; Sun, 10 Jun 2007 18:40:14 +0200 (CEST) Date: Sun, 10 Jun 2007 18:40:14 +0200 From: Iustin Pop To: xfs@oss.sgi.com Subject: [PATCH] Implement shrink of empty AGs Message-ID: <20070610164014.GA10936@teal.hq.k1024.org> Mail-Followup-To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ" Content-Disposition: inline X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 11717 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs --eHhjakXzOLJAF9wJ Content-Type: multipart/mixed; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The attached patch implements shrinking of completely empty allocation groups. The patch is against current CVS and modifies two files: - xfs_trans.c to remove two asserts in which prevent lowering the number of AGs or filesystem blocks; - xfs_fsops.c where it does: - modify xfs_growfs_data() to branch to either xfs_growfs_data_private or xfs_shrinkfs_data private depending on the new size of the fs - abstract the last part of xfs_growfs_data_private (the modify of all the superblocks) into a separate function, xfs_update_sb(), which is called both from shrink and grow - add the new xfs_shrinkfs_data_private function, mostly based on the growfs function There are many printk()'s left in the patch, I left them as they show where I compute some important values. There are also many FIXMEs in the comments showing what parts I didn't understand or was not sure about (not that these are the only ones...). Probably for a real patch, xfs-specific debug hooks need to be added and the printk()s removed. The patch works on UML and QEMU virtual machines, both in UP and SMP. I just tested many shrink/grow operations and verified with xfs_repair that the fs is not corrupted. The free space counters seem to be correct after shrink. Note that you also need to remove the check from xfs_growfs.c of not allowing to shrink the filesystem. regards, iustin --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-nice-4 Content-Transfer-Encoding: quoted-printable diff -X ignore -urN linux-2.6-xfs.cvs-orig/fs/xfs/xfs_fsops.c linux-2.6-xfs= .shrink/fs/xfs/xfs_fsops.c --- linux-2.6-xfs.cvs-orig/fs/xfs/xfs_fsops.c 2007-06-09 18:56:21.509308225= +0200 +++ linux-2.6-xfs.shrink/fs/xfs/xfs_fsops.c 2007-06-10 18:32:36.074856477 += 0200 @@ -112,6 +112,53 @@ return 0; } =20 +static void xfs_update_sb( + xfs_mount_t *mp, /* mount point for filesystem */ + xfs_agnumber_t nagimax, + xfs_agnumber_t nagcount) /* new number of a.g. */ +{ + xfs_agnumber_t agno; + xfs_buf_t *bp; + xfs_sb_t *sbp; + int error; + + /* New allocation groups fully initialized, so update mount struct */ + if (nagimax) + mp->m_maxagi =3D nagimax; + if (mp->m_sb.sb_imax_pct) { + __uint64_t icount =3D mp->m_sb.sb_dblocks * mp->m_sb.sb_imax_pct; + do_div(icount, 100); + mp->m_maxicount =3D icount << mp->m_sb.sb_inopblog; + } else + mp->m_maxicount =3D 0; + for (agno =3D 1; agno < nagcount; agno++) { + error =3D xfs_read_buf(mp, mp->m_ddev_targp, + XFS_AGB_TO_DADDR(mp, agno, XFS_SB_BLOCK(mp)), + XFS_FSS_TO_BB(mp, 1), 0, &bp); + if (error) { + xfs_fs_cmn_err(CE_WARN, mp, + "error %d reading secondary superblock for ag %d", + error, agno); + break; + } + sbp =3D XFS_BUF_TO_SBP(bp); + xfs_xlatesb(sbp, &mp->m_sb, -1, XFS_SB_ALL_BITS); + /* + * If we get an error writing out the alternate superblocks, + * just issue a warning and continue. The real work is + * already done and committed. + */ + if (!(error =3D xfs_bwrite(mp, bp))) { + continue; + } else { + xfs_fs_cmn_err(CE_WARN, mp, + "write error %d updating secondary superblock for ag %d", + error, agno); + break; /* no point in continuing */ + } + } +} + static int xfs_growfs_data_private( xfs_mount_t *mp, /* mount point for filesystem */ @@ -135,7 +182,6 @@ xfs_rfsblock_t nfree; xfs_agnumber_t oagcount; int pct; - xfs_sb_t *sbp; xfs_trans_t *tp; =20 nb =3D in->newblocks; @@ -356,44 +402,228 @@ if (error) { return error; } - /* New allocation groups fully initialized, so update mount struct */ - if (nagimax) - mp->m_maxagi =3D nagimax; - if (mp->m_sb.sb_imax_pct) { - __uint64_t icount =3D mp->m_sb.sb_dblocks * mp->m_sb.sb_imax_pct; - do_div(icount, 100); - mp->m_maxicount =3D icount << mp->m_sb.sb_inopblog; - } else - mp->m_maxicount =3D 0; - for (agno =3D 1; agno < nagcount; agno++) { - error =3D xfs_read_buf(mp, mp->m_ddev_targp, - XFS_AGB_TO_DADDR(mp, agno, XFS_SB_BLOCK(mp)), - XFS_FSS_TO_BB(mp, 1), 0, &bp); + xfs_update_sb(mp, nagimax, nagcount); + return 0; + + error0: + xfs_trans_cancel(tp, XFS_TRANS_ABORT); + return error; +} + +static int +xfs_shrinkfs_data_private( + xfs_mount_t *mp, /* mount point for filesystem */ + xfs_growfs_data_t *in) /* growfs data input struct */ +{ + xfs_agf_t *agf; + xfs_agnumber_t agno; + xfs_buf_t *bp; + int dpct; + int error; + xfs_agnumber_t nagcount; /* new AG count */ + xfs_agnumber_t oagcount; /* old AG count */ + xfs_agnumber_t nagimax =3D 0; + xfs_rfsblock_t nb, nb_mod; + xfs_rfsblock_t dbdelta; /* will be used as a + check that we + shrink the fs by + the correct number + of blocks */ + xfs_rfsblock_t fdbdelta; /* will keep track of + how many ag blocks + we need to + remove */ + int pct; + xfs_trans_t *tp; + + nb =3D in->newblocks; + pct =3D in->imaxpct; + if (nb >=3D mp->m_sb.sb_dblocks || pct < 0 || pct > 100) + return XFS_ERROR(EINVAL); + dpct =3D pct - mp->m_sb.sb_imax_pct; + error =3D xfs_read_buf(mp, mp->m_ddev_targp, + XFS_FSB_TO_BB(mp, nb) - XFS_FSS_TO_BB(mp, 1), + XFS_FSS_TO_BB(mp, 1), 0, &bp); + if (error) + return error; + ASSERT(bp); + /* FIXME: we release the buffer here manually because we are + * outside of a transaction? The other buffers read using the + * functions which take a tp parameter are not released in + * growfs + */ + xfs_buf_relse(bp); + + /* Do basic checks (at the fs level) */ + oagcount =3D mp->m_sb.sb_agcount; + nagcount =3D nb; + nb_mod =3D do_div(nagcount, mp->m_sb.sb_agblocks); + if(nb_mod) { + printk("not shrinking on an AG boundary (diff=3D%d)\n", nb_mod); + return XFS_ERROR(ENOSPC); + } + if(nagcount < 2) { + printk("refusing to shrink below 2 AGs\n"); + return XFS_ERROR(ENOSPC); + } + if(nagcount >=3D oagcount) { + printk("number of AGs will not decrease\n"); + return XFS_ERROR(EINVAL); + } + printk("Cur ag=3D%d, cur blocks=3D%llu\n", + mp->m_sb.sb_agcount, mp->m_sb.sb_dblocks); + printk("New ag=3D%d, new blocks=3D%d\n", nagcount, nb); + + printk("Will resize from %llu to %d, delta is %llu\n", + mp->m_sb.sb_dblocks, nb, mp->m_sb.sb_dblocks - nb); + /* Check to see if we trip over the log section */ + printk("logstart=3D%llu logblocks=3D%u\n", + mp->m_sb.sb_logstart, mp->m_sb.sb_logblocks); + if (nb < mp->m_sb.sb_logstart + mp->m_sb.sb_logblocks) + return XFS_ERROR(EINVAL); + /* dbdelta starts at the diff and must become zero */ + dbdelta =3D mp->m_sb.sb_dblocks - nb; + tp =3D xfs_trans_alloc(mp, XFS_TRANS_GROWFS); + printk("reserving %d\n", XFS_GROWFS_SPACE_RES(mp) + dbdelta); + if ((error =3D xfs_trans_reserve(tp, XFS_GROWFS_SPACE_RES(mp) + dbdelta, + XFS_GROWDATA_LOG_RES(mp), 0, 0, 0))) { + xfs_trans_cancel(tp, 0); + return error; + } + + fdbdelta =3D 0; + + /* Per-AG checks */ + /* FIXME: do we need to hold m_peraglock while doing this? */ + /* I think that since we do read and write to the m_perag + * stuff, we should be holding the lock for the entire walk & + * modify of the fs + */ + /* Note that because we hold the lock, on any error+early + * return, we must either release manually and return, or + * jump to error0 + */ + down_write(&mp->m_peraglock); + for(agno =3D oagcount - 1; agno >=3D nagcount; agno--) { + xfs_extlen_t usedblks; /* total used blocks in this a.g. */ + xfs_extlen_t freeblks; /* free blocks in this a.g. */ + xfs_agblock_t aglen; /* this ag's len */ + struct xfs_perag *pag; /* the m_perag structure */ + + printk("doing agno=3D%d\n", agno); + + pag =3D &mp->m_perag[agno]; + + error =3D xfs_alloc_read_agf(mp, tp, agno, 0, &bp); if (error) { - xfs_fs_cmn_err(CE_WARN, mp, - "error %d reading secondary superblock for ag %d", - error, agno); - break; + goto error0; } - sbp =3D XFS_BUF_TO_SBP(bp); - xfs_xlatesb(sbp, &mp->m_sb, -1, XFS_SB_ALL_BITS); + ASSERT(bp); + agf =3D XFS_BUF_TO_AGF(bp); + aglen =3D INT_GET(agf->agf_length, ARCH_CONVERT); + + /* read the pagf/pagi if not already initialized */ + /* agf should be initialized because of the ablove read_agf */ + ASSERT(pag->pagf_init); + if (!pag->pagi_init) { + if ((error =3D xfs_ialloc_read_agi(mp, tp, agno, &bp))) + goto error0; + ASSERT(pag->pagi_init); + } + /* - * If we get an error writing out the alter