From BATV+67b1563f91cc02798c7c+2047+infradead.org+hch@bombadil.srs.infradead.org Wed Apr 1 02:09:34 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n31798fm056891 for ; Wed, 1 Apr 2009 02:09:24 -0500 X-ASG-Debug-ID: 1238569756-7b5b01630000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A6F6213E48C8 for ; Wed, 1 Apr 2009 00:09:16 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 7PqwkGmTfpsPRlTu for ; Wed, 01 Apr 2009 00:09:16 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LouYh-00040T-D0; Wed, 01 Apr 2009 07:08:23 +0000 Date: Wed, 1 Apr 2009 03:08:23 -0400 From: Christoph Hellwig To: "Josef 'Jeff' Sipek" Cc: xfs@oss.sgi.com, "Josef 'Jeff' Sipek" X-ASG-Orig-Subj: Re: [PATCH 1/2] xfstests: make the mode consistent for all the test scripts Subject: Re: [PATCH 1/2] xfstests: make the mode consistent for all the test scripts Message-ID: <20090401070823.GA3044@infradead.org> References: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> <1238536234-26969-2-git-send-email-jsipek@eecs.umich.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1238536234-26969-2-git-send-email-jsipek@eecs.umich.edu> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1238569777 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean A consistant mode sounds fine to me, but we'd have to pull this in as git-pull not as patch, right? Also for some reason some modes seem to change when actually running xfstests which makes git barf when pulling into such a tree again, not sure where that comes from. From BATV+67b1563f91cc02798c7c+2047+infradead.org+hch@bombadil.srs.infradead.org Wed Apr 1 02:09:52 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3179Rkc056909 for ; Wed, 1 Apr 2009 02:09:42 -0500 X-ASG-Debug-ID: 1238569724-220501fc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DF2371DCC99 for ; Wed, 1 Apr 2009 00:08:44 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id lm6zpLMjbXCcN6mu for ; Wed, 01 Apr 2009 00:08:44 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LouZ2-0004GC-Fx; Wed, 01 Apr 2009 07:08:44 +0000 Date: Wed, 1 Apr 2009 03:08:44 -0400 From: Christoph Hellwig To: "Josef 'Jeff' Sipek" Cc: xfs@oss.sgi.com, "Josef 'Jeff' Sipek" X-ASG-Orig-Subj: Re: [PATCH 2/2] xfstests: Add an ignore file Subject: Re: [PATCH 2/2] xfstests: Add an ignore file Message-ID: <20090401070843.GB3044@infradead.org> References: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> <1238536234-26969-3-git-send-email-jsipek@eecs.umich.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1238536234-26969-3-git-send-email-jsipek@eecs.umich.edu> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1238569744 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Mar 31, 2009 at 05:50:34PM -0400, Josef 'Jeff' Sipek wrote: > From: Josef 'Jeff' Sipek > > Ignore generated files. Sounds good. The other packages want the same treatment. From BATV+67b1563f91cc02798c7c+2047+infradead.org+hch@bombadil.srs.infradead.org Wed Apr 1 02:22:06 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14, J_CHICKENPOX_53 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n317LfUR057550 for ; Wed, 1 Apr 2009 02:21:56 -0500 X-ASG-Debug-ID: 1238570530-4f9600290000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 062D513E4939; Wed, 1 Apr 2009 00:22:10 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id HMYTFKrTMZFBsYZi; Wed, 01 Apr 2009 00:22:10 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LoulB-00058N-Rl; Wed, 01 Apr 2009 07:21:17 +0000 Date: Wed, 1 Apr 2009 03:21:17 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfstests: fix async io error handling in fsx Subject: Re: [PATCH] xfstests: fix async io error handling in fsx Message-ID: <20090401072117.GA25131@infradead.org> References: <1238442101-24311-1-git-send-email-felixb@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1238442101-24311-1-git-send-email-felixb@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1238570531 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Mar 30, 2009 at 02:41:41PM -0500, Felix Blyakher wrote: > The result of async io returned in the event.res in addition > to the number of bytes read/written provides negated error > number. The broken libaio defines event.res as unsigned > while the same structure in the kernel defines it as signed. > The kernel indeed treat it as signed, and returns the > negated error number. Till libaio is fixed we provide > the signed long temp var. > Also set errno for each error condition in aio_rw, as the > caller is not aio aware and expects ret(-1)+errno by the > traditional libc convention. > > Signed-off-by: Felix Blyakher > --- > ltp/fsx.c | 42 +++++++++++++++++++++++++++++++++++------- > 1 files changed, 35 insertions(+), 7 deletions(-) > if (len != event.res) { > - fprintf(stderr, "bad read length: %lu instead of %u\n", > - event.res, len); > + /* > + * The b0rked libaio defines event.res as unsigned. > + * However the kernel strucuture has it signed, > + * and it's used to pass negated error value. > + * Till the library is fixed use the temp var. > + */ > + res = (long)event.res; > + if (res >= 0) > + fprintf(stderr, "bad io length: %lu instead of %u\n", > + res, len); > + else { > + fprintf(stderr, "errcode=%d\n", -res); > + fprintf(stderr, "aio_rw: async io failed: %s\n", > + strerror(-res)); > + goto out_error; > + } > + > } > return event.res; > + > +out_error: > + /* > + * The caller expects error return in traditional libc > + * convention, i.e. -1 and the errno set to error. > + */ > + errno = ret <= 0 ? -ret : -res; > + return -1; I wonder why this doesn't give a compiler warning. res is only initialized in that last branch above. Wouldn't it be better to set ret to res inside that branch and only use ret down here? From jeffpc@josefsipek.net Wed Apr 1 09:36:06 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n31EZk2C087759 for ; Wed, 1 Apr 2009 09:35:56 -0500 X-ASG-Debug-ID: 1238596522-4c2401a50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from josefsipek.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 020321C890FB for ; Wed, 1 Apr 2009 07:35:22 -0700 (PDT) Received: from josefsipek.net (josefsipek.net [141.211.133.196]) by cuda.sgi.com with ESMTP id 5YeIZyn3ggiCLpDt for ; Wed, 01 Apr 2009 07:35:22 -0700 (PDT) Received: by josefsipek.net (Postfix, from userid 1000) id 7DBC91C00DEC; Wed, 1 Apr 2009 10:35:22 -0400 (EDT) Date: Wed, 1 Apr 2009 10:35:22 -0400 From: "Josef 'Jeff' Sipek" To: Christoph Hellwig Cc: "Josef 'Jeff' Sipek" , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] xfstests: make the mode consistent for all the test scripts Subject: Re: [PATCH 1/2] xfstests: make the mode consistent for all the test scripts Message-ID: <20090401143522.GO19690@josefsipek.net> References: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> <1238536234-26969-2-git-send-email-jsipek@eecs.umich.edu> <20090401070823.GA3044@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090401070823.GA3044@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: josefsipek.net[141.211.133.196] X-Barracuda-Start-Time: 1238596523 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.21957 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Apr 01, 2009 at 03:08:23AM -0400, Christoph Hellwig wrote: > A consistant mode sounds fine to me, but we'd have to pull this in as > git-pull not as patch, right? Depends on how you manage xfs-dev.git. patch(1) won't work, but git-apply will. Personally, I use guilt [1], which let's me push/pop patches much like quilt, but since it uses git-apply, it works with all the fancy things git diffs offer. > Also for some reason some modes seem to change when actually running > xfstests which makes git barf when pulling into such a tree again, not > sure where that comes from. Hrm, I haven't seen this yet. Josef 'Jeff' Sipek. [1] http://git.kernel.org/?p=linux/kernel/git/jsipek/guilt.git;a=summary -- The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers. - Bill Gates, The Road Ahead, pg. 265 From felixb@oss.sgi.com Wed Apr 1 17:00:51 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n31M0kTN105169 for ; Wed, 1 Apr 2009 17:00:51 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n31M0kVg105127; Wed, 1 Apr 2009 17:00:46 -0500 Date: Wed, 1 Apr 2009 17:00:46 -0500 Message-Id: <200904012200.n31M0kVg105127@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, for-linus, updated. v2.6.28-rc3-21331-gf36345f X-Git-Refname: refs/heads/for-linus X-Git-Reftype: branch X-Git-Oldrev: 1aacc064e029f0017384e463121b98f06d3a2cc3 X-Git-Newrev: f36345ff9a4a77f2cc576a2777b6256d5c8798fa This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, for-linus has been updated f36345f Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 into for-linus c2ec175 mm: page_mkwrite change prototype to match fault from 1aacc064e029f0017384e463121b98f06d3a2cc3 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit f36345ff9a4a77f2cc576a2777b6256d5c8798fa Merge: 1aacc064e029f0017384e463121b98f06d3a2cc3 8b53ef33d9d8fa5f771ae11cc6a6e7bc0182beec Author: Felix Blyakher Date: Wed Apr 1 16:58:39 2009 -0500 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 into for-linus commit c2ec175c39f62949438354f603f4aa170846aabb Author: Nick Piggin Date: Tue Mar 31 15:23:21 2009 -0700 mm: page_mkwrite change prototype to match fault Change the page_mkwrite prototype to take a struct vm_fault, and return VM_FAULT_xxx flags. There should be no functional change. This makes it possible to return much more detailed error information to the VM (and also can provide more information eg. virtual_address to the driver, which might be important in some special cases). This is required for a subsequent fix. And will also make it easier to merge page_mkwrite() with fault() in future. Signed-off-by: Nick Piggin Cc: Chris Mason Cc: Trond Myklebust Cc: Miklos Szeredi Cc: Steven Whitehouse Cc: Mark Fasheh Cc: Joel Becker Cc: Artem Bityutskiy Cc: Felix Blyakher Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_file.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- XFS development tree From clayne@signalpunk.com Wed Apr 1 21:48:50 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n322mUi5116649 for ; Wed, 1 Apr 2009 21:48:40 -0500 X-ASG-Debug-ID: 1238640521-0ab701710000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ns1.signalpunk.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E28EB13E9BFE for ; Wed, 1 Apr 2009 19:48:41 -0700 (PDT) Received: from ns1.signalpunk.com (ns1.signalpunk.com [74.86.59.106]) by cuda.sgi.com with ESMTP id 8bnHERHSUDXD47Cl for ; Wed, 01 Apr 2009 19:48:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns1.signalpunk.com (Postfix) with ESMTP id E96D358172800 for ; Thu, 2 Apr 2009 02:47:44 +0000 (GMT) Received: from localhost ([127.0.0.1] helo=localhost) by ns1.signalpunk.com; 2 Apr 2009 02:47:44 +0000 Date: Thu, 2 Apr 2009 02:47:44 +0000 From: Christopher Layne To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_trans_log_inode: OOPS in 2.6.28.7 Subject: xfs_trans_log_inode: OOPS in 2.6.28.7 Message-ID: <20090402024744.GB23044@ns1.signalpunk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Barracuda-Connect: ns1.signalpunk.com[74.86.59.106] X-Barracuda-Start-Time: 1238640543 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.21998 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean While I think I might be able to reproduce this it's not something I particularly want to reproduce. The precursor was cancelling an already running xfs_fsr, removing the .fsr_last, and immediately restarting it (forcing a new cycle). Right after I received an OOPS and all file system access was blocked necessitating a hard reboot and xfs_repair. -cl [493260.254041] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 [493260.254041] IP: [] xfs_trans_find_item+0x1/0xa [493260.254041] PGD 63143067 PUD 41bf067 PMD 0 [493260.254041] Oops: 0000 [#1] SMP [493260.254041] last sysfs file: /sys/devices/pci0000:00/0000:00:05.1/host2/target2:0:0/2:0:0:0/queue_depth [493260.254286] CPU 0 [493260.254443] Modules linked in: hid_dell hid_pl hid_cypress hid_gyration hid_bright hid_sony hid_samsung hid_microsoft hid_monterey hid_ezkey hid_apple hid_a4tech hid_logitech hid_cherry hid_sunplus hid_petalynx hid_belkin hid_chicony usbhid hid usb_storage ohci_hcd ehci_hcd k8temp hwmon usbcore [493260.255847] Pid: 4024, comm: xfs_fsr Not tainted 2.6.28.7 #3 [493260.255847] RIP: 0010:[] [] xfs_trans_find_item+0x1/0xa [493260.255847] RSP: 0018:ffff880002ec1b78 EFLAGS: 00010296 [493260.255847] RAX: 0000000000000008 RBX: ffff88006759d048 RCX: ffff88002ccf7c20 [493260.256085] RDX: 0000000000000005 RSI: 0000000000000000 RDI: ffff88006759d048 [493260.256398] RBP: ffff880002ec1ba8 R08: 0000000000000000 R09: ffff88002ccf7c50 [493260.256710] R10: ffa5a5a5a5a5a5a5 R11: 0000000204cb1be0 R12: ffff88002ccf7bc0 [493260.257025] R13: 0000000000000005 R14: 0000000000000000 R15: 0000000000000005 [493260.257342] FS: 00007f633b1f46f0(0000) GS:ffffffff80664040(0000) knlGS:0000000000000000 [493260.257659] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [493260.257821] CR2: 0000000000000018 CR3: 000000006183b000 CR4: 00000000000006e0 [493260.258138] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [493260.258455] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [493260.258771] Process xfs_fsr (pid: 4024, threadinfo ffff880002ec0000, task ffff880002e48740) [493260.259090] Stack: [493260.259247] ffff880002ec1ba8 ffffffff8031586c ffff88002ccf7bc0 0000000000000000 [493260.259415] ffff88002ccf7bc0 ffff88002ccf7c50 ffff880002ec1cd8 ffffffff802e8a8f [493260.259735] ffff880002ec1c9c 0000000000000000 ffff880000000000 0000000000000000 [493260.260209] Call Trace: [493260.260367] [] ? xfs_trans_log_inode+0x22/0x4c [493260.260531] [] xfs_bunmapi+0x738/0x782 [493260.260695] [] xfs_itruncate_finish+0x160/0x27b [493260.260860] [] xfs_inactive+0x1e3/0x411 [493260.261023] [] ? __up_read+0x8f/0x98 [493260.263061] [] xfs_fs_clear_inode+0xbf/0x106 [493260.263061] [] clear_inode+0x71/0xca [493260.263061] [] generic_delete_inode+0x8b/0xf3 [493260.263061] [] generic_drop_inode+0x17/0x169 [493260.263061] [] iput+0x61/0x65 [493260.263061] [] dentry_iput+0x8e/0x9e [493260.263061] [] d_kill+0x34/0x54 [493260.263061] [] dput+0x130/0x13d [493260.263061] [] __fput+0x16b/0x18f [493260.263061] [] fput+0x15/0x17 [493260.263061] [] filp_close+0x67/0x72 [493260.263061] [] sys_close+0x99/0xd2 [493260.263061] [] system_call_fastpath+0x16/0x1b [493260.263061] Code: 66 83 4b 64 04 48 8b 45 d0 4c 89 a0 a0 00 00 00 48 8b 45 d0 49 89 07 48 83 c4 28 44 89 e8 5b 41 5c 41 5d 41 5e 41 5f c9 c3 90 55 <48> 8b 46 18 48 89 e5 c9 c3 55 8a 56 0b 31 ff 41 ba 01 00 00 00 [493260.263061] RIP [] xfs_trans_find_item+0x1/0xa [493260.263061] RSP [493260.263061] CR2: 0000000000000018 [493260.263067] ---[ end trace 9923f588304d7b6d ]--- From deni@nbnet.nb.ca Thu Apr 2 08:31:02 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_20,J_CHICKENPOX_43, TVD_SPACE_RATIO autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n32DUgqS144455 for ; Thu, 2 Apr 2009 08:30:52 -0500 X-ASG-Debug-ID: 1238679057-6dbc00ce0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from simmts6-srv.bellnexxia.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5B8AA13EBB84 for ; Thu, 2 Apr 2009 06:30:57 -0700 (PDT) Received: from simmts6-srv.bellnexxia.net (simmts6.bellnexxia.net [206.47.199.164]) by cuda.sgi.com with ESMTP id J0qO4UTmOwjtPFfk for ; Thu, 02 Apr 2009 06:30:57 -0700 (PDT) Received: from simip9-ac.srvr.bell.ca ([206.47.199.87]) by simmts6-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20090402132953.VGAL1652.simmts6-srv.bellnexxia.net@simip9-ac.srvr.bell.ca> for ; Thu, 2 Apr 2009 09:29:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ako1AIVa1EnOL8eh/2dsb2JhbACBUoNvh1zDB4NqBg Received: from simfep6.srvr.bell.ca (HELO smtpacout.sympatico.ca) ([206.47.199.161]) by simip9-ac.srvr.bell.ca with SMTP; 02 Apr 2009 09:36:39 -0400 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) X-Originating-IP: [207.58.168.86] From: Irish Online-Draw Reply-To: sofiadavidclaim@btinternet.com To: ..@nbnet.nb.ca X-ASG-Orig-Subj: Re Subject: Re Date: Thu, 2 Apr 2009 9:29:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20090402132953.VGAL1652.simmts6-srv.bellnexxia.net@simip9-ac.srvr.bell.ca> X-Barracuda-Connect: simmts6.bellnexxia.net[206.47.199.164] X-Barracuda-Start-Time: 1238679078 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5228 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.76 X-Barracuda-Spam-Status: No, SCORE=0.76 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22037 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean You Won 750,000Pounds.Send Name,Age,Occupation,Country. Agent Email:sofiadavidclaim@btinternet.com From gnb@sgi.com Thu Apr 2 09:59:01 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n32Ewf2v148510 for ; Thu, 2 Apr 2009 09:58:51 -0500 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by relay2.corp.sgi.com (Postfix) with SMTP id 2768E30408B for ; Thu, 2 Apr 2009 07:58:17 -0700 (PDT) Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA03161; Fri, 3 Apr 2009 01:29:18 +1100 Message-ID: <49D4CBA0.40408@sgi.com> Date: Fri, 03 Apr 2009 01:28:48 +1100 From: Greg Banks Reply-To: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: NFS list , Linux Filesystem list , XFS OSS list , Linux kernel list Subject: [ANNOUNCE] Filesystem test tools open-sourced by SGI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean G'day, SGI is releasing to the Open Source community a number of internal SGI testing and debugging tools for NFS. Some of these tools are also applicable to filesystems in general. These tools are being released under the GNU General Public License (GPL) version 2, in the hope that the Linux filesystem development community may find them useful. They are provided as-is, without any support. Please do not contact SGI for support on any of these tools. Some of these tools are unfinished. Others rely on build infrastructure in internal SGI trees which cannot be released. The tools are provided as tarball snapshots of internal SGI source control trees; for a number of technical reasons it is not possible to provide access to those trees or to create external repositories. The tools are available for download now at http://oss.sgi.com/projects/nfs/testtools/ A brief description of each tool follows. Checkstream ----------- Simple data corruption testing utilities based on the concept of generating a stream of small self-contained records which can be decoded in a way which makes certain common data corruption modes automatically diagnosable. Has been useful for automated testing of NFS, XFS, and CXFS in SGI. Weber ----- Test load generator for NFS. Uses multiple threads, multiple sockets and multiple IP addresses to simulate loads from many machines, thus enabling testing of NFS server setups with larger client counts than can be tested with physical infrastructure (or Virtual Machine clients). Has been useful in automated NFS testing and as a pinpoint NFS load generator tool for performance development. NFS PMDA -------- PCP Data Agent for extended NFS server statistics. Exports to PCP the new statistics (measuring per-client and per-server performance) which are provided by SGI's EnhancedNFS kernel patches. Samba PMDA ---------- PCP Data Agent for extended Samba server statistics. Exports to PCP the additional statistics (measuring per-client and per-server performance) which are provided by SGI's patches to Samba. Ddnfs ----- Filesystem load generation program designed to simulate the IO load placed on an XFS filesystem by the NFS server in response to certain NFS loads. Intended for use in XFS automated testing, to test performance and correctness of certain XFS functionality not otherwise exercised by the existing XFS test suite, but never integrated into XFSQA. Pmapload -------- Test suite for the portmap and rpcbind programs (which are NFS infrastructure components based on code open-sourced by Sun Microsystems and used by every Unix and Linux). Developed by SGI to test changes imported into those programs from newer Sun source code during the NFS on IPv6 work for Irix several years ago. RPC Exerciser ------------- Test suite for the userspace RPC infrastructure libraries, (which are NFS infrastructure components based on code open-sourced by Sun Microsystems and used by every Unix and Linux). Developed by SGI to test changes imported into those libraries from newer Sun source code during the NFS on IPv6 work for Irix several years ago. Testfs ------ Linux kernel module which provides an in-memory filesystem which forgets all data written to it. Also can be configured to simulate timing behaviour on reads and writes. This is useful for NFS performance testing without a fast disk subsystem. StReplay -------- Program which reads the system call trace of another program (obtained using the widely available strace utility) and replays the IO pattern. This was intended to be used for automated NFS and XFS testing and for NFS and XFS problem diagnosis, but was never completed as the author transferred to another team. Could be the basis for a very useful filesystem test tool. -- Greg Banks, P.Engineer, SGI Australian Software Group. the brightly coloured sporks of revolution. I don't speak for SGI. From tosubrata@gmail.com Thu Apr 2 10:06:16 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n32F5ub6148752 for ; Thu, 2 Apr 2009 10:06:06 -0500 X-ASG-Debug-ID: 1238684711-0c3f029f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-fx0-f177.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C03CE1C8F1DF for ; Thu, 2 Apr 2009 08:05:11 -0700 (PDT) Received: from mail-fx0-f177.google.com (mail-fx0-f177.google.com [209.85.220.177]) by cuda.sgi.com with ESMTP id RiXhZPx18PYg9fRc for ; Thu, 02 Apr 2009 08:05:11 -0700 (PDT) Received: by fxm25 with SMTP id 25so562238fxm.20 for ; Thu, 02 Apr 2009 08:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vRB9koxHztzmNKNoix46hsYRQlmkaU0N3V/wg8babTs=; b=YFf+BsilIULuuE4C9tcPI4nnnqcWJS/Hdoe7ES1bURBcugt4am8166qsNghQoZTwwF BpuNHRp8iD/RqxnzTjCGMCdT4trdEOLzlEx+q63dQLqDdGV97D0uGC3+jELKEJ5LjaAi GWQgD/ahBFFGu0plxXWsrny1L4McMktBQMFeg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hESuikZxDPO9W9OVMfFEHGu1ZRYqxTRjJnvrg0vHw9IVBHV/VNkzO3Qg8UOy96Z0cz JYExdecBqgV/sASD9SqZLtyG7veRfEpilDsvA7sIxDFkcMBOnNmcU4W3yKNUUefDmcjF whtfKohHbVvX4etd1pZjPiUQ8c5hmYIOrk3qE= MIME-Version: 1.0 Received: by 10.103.193.12 with SMTP id v12mr62696mup.23.1238684710490; Thu, 02 Apr 2009 08:05:10 -0700 (PDT) In-Reply-To: <49D4CBA0.40408@sgi.com> References: <49D4CBA0.40408@sgi.com> Date: Thu, 2 Apr 2009 20:35:10 +0530 Message-ID: X-ASG-Orig-Subj: Re: [ANNOUNCE] Filesystem test tools open-sourced by SGI Subject: Re: [ANNOUNCE] Filesystem test tools open-sourced by SGI From: Subrata Modak To: Greg Banks Cc: NFS list , Linux Filesystem list , XFS OSS list , ltp-list , Subrata Modak , Nate Straz Content-Type: multipart/alternative; boundary=0016e652f9f4285b3a046693c233 X-Barracuda-Connect: mail-fx0-f177.google.com[209.85.220.177] X-Barracuda-Start-Time: 1238684732 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22044 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0016e652f9f4285b3a046693c233 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Greg, On Thu, Apr 2, 2009 at 7:58 PM, Greg Banks wrote: > G'day, > > SGI is releasing to the Open Source community a number of internal > SGI testing and debugging tools for NFS. Some of these tools are > also applicable to filesystems in general. > > These tools are being released under the GNU General Public License > (GPL) version 2, in the hope that the Linux filesystem development > community may find them useful. They are provided as-is, without any > support. Please do not contact SGI for support on any of these tools. > > Some of these tools are unfinished. Others rely on build > infrastructure in internal SGI trees which cannot be released. > The tools are provided as tarball snapshots of internal SGI source > control trees; for a number of technical reasons it is not possible > to provide access to those trees or to create external repositories. > > The tools are available for download now at > > http://oss.sgi.com/projects/nfs/testtools/ Since, these are released under GPL, i hope integrating them inside LTP ( http://ltp.sf.net) after proper analysis will not be an issue. Since, no support for these tests will be available from SGI, i am hoping that having them inside LTP will be beneficial and help these tests to evolve in the long run. Regards-- Subrata (Happens to maintain LTP :-)) > > A brief description of each tool follows. > > Checkstream > ----------- > > Simple data corruption testing utilities based on the concept of > generating a stream of small self-contained records which can be > decoded in a way which makes certain common data corruption modes > automatically diagnosable. Has been useful for automated testing of > NFS, XFS, and CXFS in SGI. > > Weber > ----- > > Test load generator for NFS. Uses multiple threads, multiple sockets > and multiple IP addresses to simulate loads from many machines, > thus enabling testing of NFS server setups with larger client counts > than can be tested with physical infrastructure (or Virtual Machine > clients). Has been useful in automated NFS testing and as a pinpoint > NFS load generator tool for performance development. > > NFS PMDA > -------- > > PCP Data Agent for extended NFS server statistics. Exports to PCP > the new statistics (measuring per-client and per-server performance) > which are provided by SGI's EnhancedNFS kernel patches. > > Samba PMDA > ---------- > > PCP Data Agent for extended Samba server statistics. Exports to > PCP the additional statistics (measuring per-client and per-server > performance) which are provided by SGI's patches to Samba. > > Ddnfs > ----- > > Filesystem load generation program designed to simulate the IO > load placed on an XFS filesystem by the NFS server in response > to certain NFS loads. Intended for use in XFS automated testing, > to test performance and correctness of certain XFS functionality > not otherwise exercised by the existing XFS test suite, but never > integrated into XFSQA. > > Pmapload > -------- > > Test suite for the portmap and rpcbind programs (which are > NFS infrastructure components based on code open-sourced by Sun > Microsystems and used by every Unix and Linux). Developed by SGI to > test changes imported into those programs from newer Sun source code > during the NFS on IPv6 work for Irix several years ago. > > RPC Exerciser > ------------- > > Test suite for the userspace RPC infrastructure libraries, (which > are NFS infrastructure components based on code open-sourced by Sun > Microsystems and used by every Unix and Linux). Developed by SGI to > test changes imported into those libraries from newer Sun source code > during the NFS on IPv6 work for Irix several years ago. > > Testfs > ------ > > Linux kernel module which provides an in-memory filesystem which > forgets all data written to it. Also can be configured to simulate > timing behaviour on reads and writes. This is useful for NFS > performance testing without a fast disk subsystem. > > StReplay > -------- > > Program which reads the system call trace of another program (obtained > using the widely available strace utility) and replays the IO pattern. > This was intended to be used for automated NFS and XFS testing and > for NFS and XFS problem diagnosis, but was never completed as the > author transferred to another team. Could be the basis for a very > useful filesystem test tool. > > > -- > Greg Banks, P.Engineer, SGI Australian Software Group. > the brightly coloured sporks of revolution. > I don't speak for SGI. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Regards & Thanks-- Subrata --0016e652f9f4285b3a046693c233 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg,

On Thu, Apr 2, 2009 at 7:58 PM, = Greg Banks <gnb@sgi.com= > wrote:
G'day,

SGI is releasing to the Open Source community a number of internal
SGI testing and debugging tools for NFS. =C2=A0Some of these tools are
also applicable to filesystems in general.

These tools are being released under the GNU General Public License
(GPL) version 2, in the hope that the Linux filesystem development
community may find them useful. =C2=A0They are provided as-is, without any<= br> support. =C2=A0Please do not contact SGI for support on any of these tools.=

Some of these tools are unfinished. =C2=A0Others rely on build
infrastructure in internal SGI trees which cannot be released.
The tools are provided as tarball snapshots of internal SGI source
control trees; for a number of technical reasons it is not possible
to provide access to those trees or to create external repositories.

The tools are available for download now at

ht= tp://oss.sgi.com/projects/nfs/testtools/

Since, th= ese are released under GPL, i hope integrating them inside LTP (http://ltp.sf.net) after proper analysis will not be= an issue. Since, no support for these tests will be available from SGI, i = am hoping that having them inside LTP will be beneficial and help these tes= ts to evolve in the long run.

Regards--
Subrata
(Happens to maintain LTP :-))



A brief description of each tool follows.

Checkstream
-----------

Simple data corruption testing utilities based on the concept of
generating a stream of small self-contained records which can be
decoded in a way which makes certain common data corruption modes
automatically diagnosable. =C2=A0Has been useful for automated testing of NFS, XFS, and CXFS in SGI.

Weber
-----

Test load generator for NFS. =C2=A0Uses multiple threads, multiple sockets<= br> and multiple IP addresses to simulate loads from many machines,
thus enabling testing of NFS server setups with larger client counts
than can be tested with physical infrastructure (or Virtual Machine
clients). =C2=A0Has been useful in automated NFS testing and as a pinpoint<= br> NFS load generator tool for performance development.

NFS PMDA
--------

PCP Data Agent for extended NFS server statistics. =C2=A0Exports to PCP
the new statistics (measuring per-client and per-server performance)
which are provided by SGI's EnhancedNFS kernel patches.

Samba PMDA
----------

PCP Data Agent for extended Samba server statistics. =C2=A0Exports to
PCP the additional statistics (measuring per-client and per-server
performance) which are provided by SGI's patches to Samba.

Ddnfs
-----

Filesystem load generation program designed to simulate the IO
load placed on an XFS filesystem by the NFS server in response
to certain NFS loads. =C2=A0Intended for use in XFS automated testing,
to test performance and correctness of certain XFS functionality
not otherwise exercised by the existing XFS test suite, but never
integrated into XFSQA.

Pmapload
--------

Test suite for the portmap and rpcbind programs (which are
NFS infrastructure components based on code open-sourced by Sun
Microsystems and used by every Unix and Linux). =C2=A0Developed by SGI to test changes imported into those programs from newer Sun source code
during the NFS on IPv6 work for Irix several years ago.

RPC Exerciser
-------------

Test suite for the userspace RPC infrastructure libraries, (which
are NFS infrastructure components based on code open-sourced by Sun
Microsystems and used by every Unix and Linux). =C2=A0Developed by SGI to test changes imported into those libraries from newer Sun source code
during the NFS on IPv6 work for Irix several years ago.

Testfs
------

Linux kernel module which provides an in-memory filesystem which
forgets all data written to it. =C2=A0Also can be configured to simulate timing behaviour on reads and writes. =C2=A0This is useful for NFS
performance testing without a fast disk subsystem.

StReplay
--------

Program which reads the system call trace of another program (obtained
using the widely available strace utility) and replays the IO pattern.
This was intended to be used for automated NFS and XFS testing and
for NFS and XFS problem diagnosis, but was never completed as the
author transferred to another team. =C2=A0Could be the basis for a very
useful filesystem test tool.


--
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel= " in
the body of a message to major= domo@vger.kernel.org
More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html Please read the FAQ at =C2=A0http://www.tux.org/lkml/



--
Regards & Th= anks--
Subrata
--0016e652f9f4285b3a046693c233-- From felixb@sgi.com Thu Apr 2 11:35:15 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n32GYsbk152091 for ; Thu, 2 Apr 2009 11:35:05 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id BF6628F80B7 for ; Thu, 2 Apr 2009 09:34:32 -0700 (PDT) Received: from eagdhcp-232-185.americas.sgi.com (eagdhcp-232-185.americas.sgi.com [128.162.232.185]) by estes.americas.sgi.com (Postfix) with ESMTP id E311E7000103; Thu, 2 Apr 2009 11:26:23 -0500 (CDT) Cc: Andrew Morton , LKML , xfs mailing list , Felix Blyakher Message-Id: From: Felix Blyakher To: Linus Torvalds In-Reply-To: <20090331053013.7642414167108@attica.americas.sgi.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: [GIT PULL] XFS update for 2.6.30 Date: Thu, 2 Apr 2009 11:26:23 -0500 References: <20090331053013.7642414167108@attica.americas.sgi.com> X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi Linus, Were there any problems pulling from the xfs repository? Thanks, Felix On Mar 31, 2009, at 12:30 AM, Felix Blyakher wrote: > The following changes since commit > 15f7176eb1cccec0a332541285ee752b935c1c85: > Linus Torvalds (1): > Merge git://git.kernel.org/.../davem/net-2.6 > > are available in the git repository at: > > git://oss.sgi.com/xfs/xfs for-linus > > Christoph Hellwig (39): > xfs: fix dentry aliasing issues in open_by_handle > xfs: use mnt_want_write in compat_attrmulti ioctl > xfs: add a separate lock class for the per-mount list of dquots > xfs: lockdep annotations for xfs_dqlock2 > xfs: add a lock class for group/project dquots > xfs: fix bad_features2 fixups for the root filesystem > xfs: sanity check attr fork size > xfs: cleanup error handling in xfs_mountfs: > xfs: make sure to free the real-time inodes in the mount error > path > xfs: tiny cleanup for xfs_link > xfs: remove unused XFS_MOUNT_ILOCK/XFS_MOUNT_IUNLOCK > xfs: factor out attr fork reset handling > xfs: merge xfs_inode_flush into xfs_fs_write_inode > xfs: cleanup xfs_find_handle > xfs: remove the unused XFS_QMOPT_DQLOCK flag > xfs: remove iclog calculation special cases > xfs: remove superflous inobt macros > xfs: remove uchar_t/ushort_t/uint_t/ulong_t types > xfs: merge xfs_mkdir into xfs_create > xfs: remove XFS_QM_LOCK/XFS_QM_UNLOCK/XFS_QM_HOLD/XFS_QM_RELE > xfs: use mutex_is_locked in XFS_DQ_IS_LOCKED > xfs: sanitize qh_lock wrappers > xfs: get rid of indirections in the quotaops implementation > xfs: fix error handling in xfs_log_mount > xfs: reject swapext ioctl on swapfiles > xfs: prevent kernel crash due to corrupted inode log format > xfs: prevent lockdep false positive in xfs_iget_cache_miss > xfs: only issues a cache flush on unmount if barriers are enabled > xfs: cleanup log unmount handling > xfs: remove another leftover of the old inode log item format > xfs: cleanup xlog_recover_do_trans > xfs: cleanup xlog_bread > xfs: kill vn_atime_* helpers. > xfs: kill VN_BAD > xfs: kill mutex_t typedef > xfs: kill ino64 mount option > xfs: remove m_litino > xfs: remove m_attroffset > xfs: cleanup uuid handling > > Dave Chinner (3): > Long btree pointers are still 64 bit on disk > xfs: Check buffer lengths in log recovery > xfs: factor out code to find the longest free extent in the AG > > Eric Sandeen (3): > [XFS] Remove the rest of the macro-to-function indirections. > [XFS] remove always-true #ifndef HAVE_FORMAT32 tests > don't reallocate sxp variable passed into xfs_swapext > > Felix Blyakher (25): > Merge branch 'master' of git+ssh://oss.sgi.com/oss/git/xfs/xfs > [XFS] Warn on transaction in flight on read-only remount > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > xfs: Update maintainers > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs > Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > Revert "[XFS] use scalable vmap API" > Revert "[XFS] remove old vmap cache" > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > Fix xfs debug build breakage by pushing xfs_error.h after > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > xfs: increase the maximum number of supported ACL entries > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs > Revert "xfs: increase the maximum number of supported ACL > entries" > > Hannes Eder (3): > xfs: move declaration to header file > xfs: make symbols static > xfs: include header files for prototypes > > Hisashi Hifumi (1): > xfs: pagecache usage optimization > > Josef 'Jeff' Sipek (1): > xfs: cleanup error handling in xfs_swap_extents > > Lachlan McIlroy (6): > [XFS] Update maintainers > Merge git://git.kernel.org/.../torvalds/linux-2.6 > Merge branch 'for-linus' of git+ssh://git.melbourne.sgi.com/git/ > xfs > Merge branch 'master' of git://git.kernel.org/.../torvalds/ > linux-2.6 > Merge git://git.kernel.org/.../torvalds/linux-2.6 > Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs > > Malcolm Parsons (1): > xfs: fix various typos > > Nick Piggin (2): > [XFS] remove old vmap cache > [XFS] use scalable vmap API > > MAINTAINERS | 3 +- > fs/xfs/Makefile | 1 + > fs/xfs/linux-2.6/mutex.h | 25 --- > fs/xfs/linux-2.6/xfs_aops.c | 1 + > fs/xfs/linux-2.6/xfs_ioctl.c | 117 +++++------- > fs/xfs/linux-2.6/xfs_iops.c | 33 +--- > fs/xfs/linux-2.6/xfs_linux.h | 13 +-- > fs/xfs/linux-2.6/xfs_quotaops.c | 157 +++++++++++++++ > fs/xfs/linux-2.6/xfs_super.c | 137 +++++--------- > fs/xfs/linux-2.6/xfs_super.h | 1 + > fs/xfs/linux-2.6/xfs_sync.h | 1 + > fs/xfs/linux-2.6/xfs_vnode.h | 32 --- > fs/xfs/quota/xfs_dquot.c | 28 ++-- > fs/xfs/quota/xfs_dquot.h | 18 +-- > fs/xfs/quota/xfs_qm.c | 212 ++++++--------------- > fs/xfs/quota/xfs_qm.h | 26 ++-- > fs/xfs/quota/xfs_qm_bhv.c | 1 - > fs/xfs/quota/xfs_qm_syscalls.c | 190 +----------------- > fs/xfs/quota/xfs_quota_priv.h | 38 ++--- > fs/xfs/quota/xfs_trans_dquot.c | 16 +- > fs/xfs/support/debug.c | 1 + > fs/xfs/support/uuid.c | 71 ------- > fs/xfs/support/uuid.h | 4 - > fs/xfs/xfs_ag.h | 4 +- > fs/xfs/xfs_alloc.c | 26 ++- > fs/xfs/xfs_alloc.h | 6 + > fs/xfs/xfs_attr_leaf.c | 58 +++--- > fs/xfs/xfs_bmap.c | 76 +++++--- > fs/xfs/xfs_bmap.h | 6 +- > fs/xfs/xfs_btree.c | 4 +- > fs/xfs/xfs_btree.h | 2 +- > fs/xfs/xfs_da_btree.c | 2 +- > fs/xfs/xfs_da_btree.h | 9 +- > fs/xfs/xfs_dfrag.c | 68 +++---- > fs/xfs/xfs_dinode.h | 4 +- > fs/xfs/xfs_dir2.c | 2 - > fs/xfs/xfs_dir2_block.c | 7 +- > fs/xfs/xfs_dir2_data.h | 2 +- > fs/xfs/xfs_dir2_leaf.c | 17 +-- > fs/xfs/xfs_dir2_node.c | 2 +- > fs/xfs/xfs_dir2_sf.c | 13 +-- > fs/xfs/xfs_extfree_item.h | 6 - > fs/xfs/xfs_filestream.c | 9 +- > fs/xfs/xfs_fsops.c | 2 +- > fs/xfs/xfs_ialloc.c | 12 +- > fs/xfs/xfs_ialloc_btree.c | 2 +- > fs/xfs/xfs_ialloc_btree.h | 22 +-- > fs/xfs/xfs_inode.h | 2 +- > fs/xfs/xfs_inode_item.h | 2 - > fs/xfs/xfs_iomap.h | 2 +- > fs/xfs/xfs_itable.c | 9 +- > fs/xfs/xfs_log.c | 67 ++----- > fs/xfs/xfs_log.h | 3 +- > fs/xfs/xfs_log_priv.h | 3 +- > fs/xfs/xfs_log_recover.c | 308 +++++++++++++++++------------- > fs/xfs/xfs_mount.c | 253 ++++++++++++++----------- > fs/xfs/xfs_mount.h | 19 +-- > fs/xfs/xfs_qmops.c | 1 - > fs/xfs/xfs_quota.h | 3 +- > fs/xfs/xfs_rtalloc.c | 10 + > fs/xfs/xfs_rtalloc.h | 8 +- > fs/xfs/xfs_trans.h | 24 ++-- > fs/xfs/xfs_trans_ail.c | 4 +- > fs/xfs/xfs_trans_item.c | 2 +- > fs/xfs/xfs_trans_space.h | 2 +- > fs/xfs/xfs_types.h | 8 - > fs/xfs/xfs_utils.c | 2 +- > fs/xfs/xfs_vnodeops.c | 408 ++++++++ > +------------------------------ > fs/xfs/xfs_vnodeops.h | 3 - > 69 files changed, 1031 insertions(+), 1599 deletions(-) > delete mode 100644 fs/xfs/linux-2.6/mutex.h > create mode 100644 fs/xfs/linux-2.6/xfs_quotaops.c > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From greg.n.banks@gmail.com Thu Apr 2 16:45:11 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n32LipoY165284 for ; Thu, 2 Apr 2009 16:45:01 -0500 X-ASG-Debug-ID: 1238708668-0f2400640000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B4EC91C914D7 for ; Thu, 2 Apr 2009 14:44:28 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.250]) by cuda.sgi.com with ESMTP id Ld5X9kQSuu0YalOX for ; Thu, 02 Apr 2009 14:44:28 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id c5so685695rvf.32 for ; Thu, 02 Apr 2009 14:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=2HGOczOEoGAVpy3VzXFKd7iKlpjKNi8hV0jHwbXhpSY=; b=op1J9s7I5xUbnqcPBBCUaKlv1BabozOXJEI03nx09dtyUffe01RVTG09dcqIre18g5 IQSV6CSQjOn6s2Pi0fgGiNpwESTYWZqoy6GCo0LjrvWRt1dGNjzjGoqtR/QzosUtDGsU qBBDKQD5xfeUubQ5ub63xBX0XPtCrZnabjDnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fDlfgiBhMQyu4kb2BkxQE76RVmMfCQpLStt3GZdInPGBtI73uxd9VNV6eOMzo8PNRV VsQFRFoMPlTUJtIK0oKhKTX4CfQvzvUiF1gvRCYzScRrytsN8x8cD/7zl6ClMgChCMke 7HUB3xOpxphjZqYKBDKJ4swJnTronKPDwAUD4= MIME-Version: 1.0 Sender: greg.n.banks@gmail.com Received: by 10.141.205.10 with SMTP id h10mr168124rvq.225.1238708667317; Thu, 02 Apr 2009 14:44:27 -0700 (PDT) In-Reply-To: References: <49D4CBA0.40408@sgi.com> Date: Fri, 3 Apr 2009 08:44:27 +1100 X-Google-Sender-Auth: a62c95194f89871f Message-ID: X-ASG-Orig-Subj: Re: [ANNOUNCE] Filesystem test tools open-sourced by SGI Subject: Re: [ANNOUNCE] Filesystem test tools open-sourced by SGI From: Greg Banks To: Subrata Modak Cc: NFS list , Linux Filesystem list , XFS OSS list , ltp-list , Subrata Modak , Nate Straz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.250] X-Barracuda-Start-Time: 1238708668 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22069 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, Apr 3, 2009 at 2:05 AM, Subrata Modak wrote: > Hi Greg, > > On Thu, Apr 2, 2009 at 7:58 PM, Greg Banks wrote: >> >> The tools are available for download now at >> >> http://oss.sgi.com/projects/nfs/testtools/ > > Since, these are released under GPL, i hope integrating them inside LTP > (http://ltp.sf.net) after proper analysis will not be an issue. Not an issue at all, in fact it would be the optimal result. The question was asked during the open source review process :-) > Since, no > support for these tests will be available from SGI, i am hoping that having > them inside LTP will be beneficial and help these tests to evolve in the > long run. Great. I'll have some spare time starting from next week and I'm familiar with the tools: how can I help? -- Greg. From curtis@alopias.GreenKey.net Thu Apr 2 18:49:38 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n32NnSl0171133 for ; Thu, 2 Apr 2009 18:49:38 -0500 X-ASG-Debug-ID: 1238716125-0f2402080000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from alopias.GreenKey.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 13E9D1C91C4E for ; Thu, 2 Apr 2009 16:48:45 -0700 (PDT) Received: from alopias.GreenKey.net (alopias.GreenKey.net [209.209.60.60]) by cuda.sgi.com with ESMTP id 9sTHfyG8xZcNayHU for ; Thu, 02 Apr 2009 16:48:45 -0700 (PDT) Received: by alopias.GreenKey.net (Postfix, from userid 500) id AA78E6F064; Thu, 2 Apr 2009 16:48:44 -0700 (PDT) Date: Thu, 2 Apr 2009 16:48:44 -0700 (PDT) From: Curtis Doty To: XFS X-ASG-Orig-Subj: Re: why xfs_write() race with O_DIRECT only? Subject: Re: why xfs_write() race with O_DIRECT only? In-Reply-To: <49CD7912.6080508@GreenKey.net> References: <49CD7912.6080508@GreenKey.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Fortune: :sodium substrate: n. Syn {salt substrate}. Message-Id: <20090402234844.AA78E6F064@alopias.GreenKey.net> X-Barracuda-Connect: alopias.GreenKey.net[209.209.60.60] X-Barracuda-Start-Time: 1238716146 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22076 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Mar 27 Curtis Doty said: > I'm guessing this is the race fixed in 2.6.29. > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=25051158 > > But my app is running O_DIRECT and only calls pwrite(). Is there > something I'm missing that explains the aio stuff etc.? > > ------------[ cut here ]------------ > WARNING: at fs/xfs/linux-2.6/xfs_lrw.c:724 xfs_write+0x364/0x694() > Modules linked in: dm_mod sg usbhid usbkbd usbmouse qla2xxx > firmware_class scsi_transport_fc bnx2 hpilo ipmi_si ipmi_msghandler > container shpchp pci_hotplug rng_core iTCO_wdt iTCO_vendor_support > thermal button processor rtc_cmos rtc_core rtc_lib ehci_hcd uhci_hcd usbcore > Pid: 5789, comm: myServer Not tainted 2.6.28.9 #1 > No luck with 2.6.29. It's still occuring. ------------[ cut here ]------------ WARNING: at fs/xfs/linux-2.6/xfs_lrw.c:715 xfs_write+0x34b/0x67e() Hardware name: ProLiant DL360 G5 Modules linked in: dm_mod sg usbhid usbkbd usbmouse qla2xxx firmware_class scsi_transport_fc ipmi_si ipmi_msghandler hpilo bnx2 container thermal button processor ehci_hcd rtc_cmos rng_core rtc_core shpchp rtc_lib iTCO_wdt pci_hotplug iTCO_vendor_support uhci_hcd usbcore Pid: 5681, comm: diskServer Not tainted 2.6.29 #1 Call Trace: [] warn_slowpath+0x74/0x8a [] ? __pagevec_release+0x18/0x21 [] ? invalidate_inode_pages2_range+0x1c4/0x20c [] ? __xfs_get_blocks+0x179/0x239 [] ? xfs_end_io_direct+0x0/0x66 [] ? generic_file_direct_write+0xfe/0x1dc [] ? xfs_trans_unlocked_item+0x2a/0x41 [] xfs_write+0x34b/0x67e [] ? default_wake_function+0xb/0xd [] ? __wake_up_common+0x2f/0x5a [] ? wake_futex+0x22/0x2f [] xfs_file_aio_write+0x5b/0x63 [] do_sync_write+0xab/0xe6 [] ? autoremove_wake_function+0x0/0x33 [] ? do_sync_write+0x0/0xe6 [] vfs_write+0x8c/0x108 [] sys_pwrite64+0x45/0x60 [] sysenter_do_call+0x12/0x21 [] ? mxcsr_feature_mask_init+0xe/0x47 ---[ end trace f75be9e7e7f9aa47 ]--- From subrata@linux.vnet.ibm.com Fri Apr 3 03:18:45 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n338IKS3193726 for ; Fri, 3 Apr 2009 03:18:35 -0500 X-ASG-Debug-ID: 1238746657-2e0001160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e34.co.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 13DAB1E7F3C for ; Fri, 3 Apr 2009 01:17:37 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by cuda.sgi.com with ESMTP id 4dfosuYrvlxzMz0H for ; Fri, 03 Apr 2009 01:17:37 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n338FO9f021539 for ; Fri, 3 Apr 2009 02:15:24 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n338HZTH225798 for ; Fri, 3 Apr 2009 02:17:36 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n338HZ1F006617 for ; Fri, 3 Apr 2009 02:17:35 -0600 Received: from [9.124.158.88] ([9.124.158.88]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n338HVfh006342; Fri, 3 Apr 2009 02:17:32 -0600 X-ASG-Orig-Subj: Re: [ANNOUNCE] Filesystem test tools open-sourced by SGI Subject: Re: [ANNOUNCE] Filesystem test tools open-sourced by SGI From: Subrata Modak Reply-To: subrata@linux.vnet.ibm.com To: Greg Banks Cc: Subrata Modak , NFS list , Linux Filesystem list , XFS OSS list , ltp-list , Nate Straz In-Reply-To: References: <49D4CBA0.40408@sgi.com> Content-Type: text/plain Organization: IBM Date: Fri, 03 Apr 2009 13:47:39 +0530 Message-Id: <1238746659.4871.11.camel@subratamodak.linux.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.2) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e34.co.us.ibm.com[32.97.110.152] X-Barracuda-Start-Time: 1238746678 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22108 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi Greg, On Fri, 2009-04-03 at 08:44 +1100, Greg Banks wrote: > On Fri, Apr 3, 2009 at 2:05 AM, Subrata Modak wrote: > > Hi Greg, > > > > On Thu, Apr 2, 2009 at 7:58 PM, Greg Banks wrote: > >> > >> The tools are available for download now at > >> > >> http://oss.sgi.com/projects/nfs/testtools/ > > > > Since, these are released under GPL, i hope integrating them inside LTP > > (http://ltp.sf.net) after proper analysis will not be an issue. > > Not an issue at all, in fact it would be the optimal result. The > question was asked during the open source review process :-) > > > Since, no > > support for these tests will be available from SGI, i am hoping that having > > them inside LTP will be beneficial and help these tests to evolve in the > > long run. > > Great. I'll have some spare time starting from next week and I'm > familiar with the tools: how can I help? Thanks for offering to help. I will get back to you sooner on any issue(s) i face. Regards-- Subrata > From torvalds@linux-foundation.org Fri Apr 3 11:56:09 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n33Gtn8W225369 for ; Fri, 3 Apr 2009 11:55:59 -0500 X-ASG-Debug-ID: 1238777766-747902670000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp1.linux-foundation.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8076A13F27AF; Fri, 3 Apr 2009 09:56:06 -0700 (PDT) Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13]) by cuda.sgi.com with ESMTP id vIwIUtiocg0oUdvj; Fri, 03 Apr 2009 09:56:06 -0700 (PDT) Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id n33GqvxI029735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 09:53:30 -0700 Received: from localhost (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id n33Gqume016378; Fri, 3 Apr 2009 09:52:57 -0700 Date: Fri, 3 Apr 2009 09:52:56 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Felix Blyakher cc: Andrew Morton , LKML , xfs mailing list X-ASG-Orig-Subj: Re: [GIT PULL] XFS update for 2.6.30 Subject: Re: [GIT PULL] XFS update for 2.6.30 In-Reply-To: Message-ID: References: <20090331053013.7642414167108@attica.americas.sgi.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 X-Barracuda-Connect: smtp1.linux-foundation.org[140.211.169.13] X-Barracuda-Start-Time: 1238777792 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22143 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, 2 Apr 2009, Felix Blyakher wrote: > > Were there any problems pulling from the xfs repository? Sorry, no - just too much email, too many trees to look at, too many people to argue with. Pulled. Linus From torvalds@linux-foundation.org Fri Apr 3 12:14:23 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n33HE3Uj226187 for ; Fri, 3 Apr 2009 12:14:13 -0500 X-ASG-Debug-ID: 1238778820-5eeb03cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp1.linux-foundation.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6D1731EA55D for ; Fri, 3 Apr 2009 10:13:40 -0700 (PDT) Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13]) by cuda.sgi.com with ESMTP id B3PS6G39mIeMq0hD for ; Fri, 03 Apr 2009 10:13:40 -0700 (PDT) Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id n33HA4sl031704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 10:11:40 -0700 Received: from localhost (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id n33H2F63019073; Fri, 3 Apr 2009 10:02:15 -0700 Date: Fri, 3 Apr 2009 10:02:15 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Felix Blyakher , Lachlan McIlroy cc: Andrew Morton , LKML , xfs mailing list X-ASG-Orig-Subj: Re: [GIT PULL] XFS update for 2.6.30 Subject: Re: [GIT PULL] XFS update for 2.6.30 In-Reply-To: Message-ID: References: <20090331053013.7642414167108@attica.americas.sgi.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 X-Barracuda-Connect: smtp1.linux-foundation.org[140.211.169.13] X-Barracuda-Start-Time: 1238778821 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22143 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, 3 Apr 2009, Linus Torvalds wrote: > > > On Thu, 2 Apr 2009, Felix Blyakher wrote: > > > > Were there any problems pulling from the xfs repository? > > Sorry, no - just too much email, too many trees to look at, too many > people to argue with. > > Pulled. Side note - I almost unpulled afterwards. You've done several apparently totally useless pulls from my tree at random points. Daily "keep up-to-date with Linus' tree" pulls are _strongly_ discouraged (read: if this continues, I'll just stop pulling from you), because it makes the history totally unreadable after-the-fact. It has some direct technical downsides (it makes it much harder to run "git bisect" and see what is going on), but apart from those direct downsides it just makes it much harder for me - or anybody else who wants to get an overview of what happened - to visualize things when history is messy. Instead of having a clear nice line of development that says "this is what happened to XFS", those merges have basically mixed up all your changes with all the random _other_ changes in the tree. In other words, having those extra merges makes the graphical tools almost useless for getting some kind of "what happened" overview. I realize that an occasional back-merge may be required to resolve big conflicts early, but they really have to be pretty big and immediate for it to be a win. Linus From felixb@sgi.com Fri Apr 3 12:51:47 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n33HpQWV227653 for ; Fri, 3 Apr 2009 12:51:36 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id 5BE538F80C4 for ; Fri, 3 Apr 2009 10:51:05 -0700 (PDT) Received: from eagdhcp-232-185.americas.sgi.com (eagdhcp-232-185.americas.sgi.com [128.162.232.185]) by estes.americas.sgi.com (Postfix) with ESMTP id 397F1700016A; Fri, 3 Apr 2009 12:41:20 -0500 (CDT) Cc: Lachlan McIlroy , Andrew Morton , LKML , xfs mailing list Message-Id: <8A177E56-84E9-487E-930E-9C6805E17184@sgi.com> From: Felix Blyakher To: Linus Torvalds In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: [GIT PULL] XFS update for 2.6.30 Date: Fri, 3 Apr 2009 12:41:18 -0500 References: <20090331053013.7642414167108@attica.americas.sgi.com> X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Apr 3, 2009, at 12:02 PM, Linus Torvalds wrote: > On Fri, 3 Apr 2009, Linus Torvalds wrote: > >> On Thu, 2 Apr 2009, Felix Blyakher wrote: >>> >>> Were there any problems pulling from the xfs repository? >> >> Sorry, no - just too much email, too many trees to look at, too many >> people to argue with. >> >> Pulled. > > Side note - I almost unpulled afterwards. That was my concern, i.e. it's not pulled without explicit NAK. I knew about your possible concerns. > You've done several apparently totally useless pulls from my tree at > random points. Yes, I noticed that, and agree with all your points even before you brought them up. I already started talking to people to improve my process. The reason the intermediate pulls from your tree were done is to make sure that new xfs patches would not conflict with some other changes already in the mainline. That was part of the maintainer cheat sheet given to me, and I didn't realize the side effects of it. I probably can verify the possible conflicts without pushing the merges into the repository and reset the working tree to pre pull state. At any rate, I'll find some way to manage that without cluttering the history with the merges. Any suggestions are welcome. Thanks, Felix > > > Daily "keep up-to-date with Linus' tree" pulls are _strongly_ > discouraged > (read: if this continues, I'll just stop pulling from you), because it > makes the history totally unreadable after-the-fact. It has some > direct > technical downsides (it makes it much harder to run "git bisect" and > see > what is going on), but apart from those direct downsides it just > makes it > much harder for me - or anybody else who wants to get an overview of > what > happened - to visualize things when history is messy. > > Instead of having a clear nice line of development that says "this > is what > happened to XFS", those merges have basically mixed up all your > changes > with all the random _other_ changes in the tree. > > In other words, having those extra merges makes the graphical tools > almost > useless for getting some kind of "what happened" overview. > > I realize that an occasional back-merge may be required to resolve big > conflicts early, but they really have to be pretty big and immediate > for > it to be a win. > > Linus From david@lang.hm Fri Apr 3 20:21:59 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n341LaIS242920 for ; Fri, 3 Apr 2009 20:21:48 -0500 X-ASG-Debug-ID: 1238808119-48f702090000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bifrost.lang.hm (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E558413F3CFF; Fri, 3 Apr 2009 18:21:59 -0700 (PDT) Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) by cuda.sgi.com with ESMTP id XEDpWFmx16PJ6VyT; Fri, 03 Apr 2009 18:21:59 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id n341J8wl014315; Fri, 3 Apr 2009 17:19:08 -0800 Date: Fri, 3 Apr 2009 18:19:08 -0700 (PDT) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: Felix Blyakher cc: Linus Torvalds , Lachlan McIlroy , Andrew Morton , LKML , xfs mailing list X-ASG-Orig-Subj: Re: [GIT PULL] XFS update for 2.6.30 Subject: Re: [GIT PULL] XFS update for 2.6.30 In-Reply-To: <8A177E56-84E9-487E-930E-9C6805E17184@sgi.com> Message-ID: References: <20090331053013.7642414167108@attica.americas.sgi.com> <8A177E56-84E9-487E-930E-9C6805E17184@sgi.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: mail.lang.hm[64.81.33.126] X-Barracuda-Start-Time: 1238808140 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22175 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, 3 Apr 2009, Felix Blyakher wrote: > On Apr 3, 2009, at 12:02 PM, Linus Torvalds wrote: > >> On Fri, 3 Apr 2009, Linus Torvalds wrote: >> >>> On Thu, 2 Apr 2009, Felix Blyakher wrote: >>>> >>>> Were there any problems pulling from the xfs repository? >>> >>> Sorry, no - just too much email, too many trees to look at, too many >>> people to argue with. >>> >>> Pulled. >> >> Side note - I almost unpulled afterwards. > > That was my concern, i.e. it's not pulled without explicit > NAK. I knew about your possible concerns. > >> You've done several apparently totally useless pulls from my tree at >> random points. > > Yes, I noticed that, and agree with all your points even > before you brought them up. > I already started talking to people to improve my process. > The reason the intermediate pulls from your tree were done > is to make sure that new xfs patches would not conflict > with some other changes already in the mainline. That was > part of the maintainer cheat sheet given to me, and I > didn't realize the side effects of it. > I probably can verify the possible conflicts without pushing > the merges into the repository and reset the working tree to > pre pull state. create a temporary branch and do the merge in that. then throw away the test branch and there is no harm to the main tree. David Lang > At any rate, I'll find some way to manage that without > cluttering the history with the merges. > Any suggestions are welcome. > > Thanks, > Felix > >> >> >> Daily "keep up-to-date with Linus' tree" pulls are _strongly_ discouraged >> (read: if this continues, I'll just stop pulling from you), because it >> makes the history totally unreadable after-the-fact. It has some direct >> technical downsides (it makes it much harder to run "git bisect" and see >> what is going on), but apart from those direct downsides it just makes it >> much harder for me - or anybody else who wants to get an overview of what >> happened - to visualize things when history is messy. >> >> Instead of having a clear nice line of development that says "this is what >> happened to XFS", those merges have basically mixed up all your changes >> with all the random _other_ changes in the tree. >> >> In other words, having those extra merges makes the graphical tools almost >> useless for getting some kind of "what happened" overview. >> >> I realize that an occasional back-merge may be required to resolve big >> conflicts early, but they really have to be pretty big and immediate for >> it to be a win. >> >> Linus > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From felixb@sgi.com Fri Apr 3 21:58:00 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n342veXL246209 for ; Fri, 3 Apr 2009 21:57:50 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay2.corp.sgi.com (Postfix) with ESMTP id C0A8C3040C8 for ; Fri, 3 Apr 2009 19:57:18 -0700 (PDT) Received: from [IPv6???1] (sshgate.corp.sgi.com [198.149.20.12]) by estes.americas.sgi.com (Postfix) with ESMTP id 5E1CA700016A; Fri, 3 Apr 2009 20:54:57 -0500 (CDT) Cc: Linus Torvalds , Lachlan McIlroy , Andrew Morton , LKML , xfs mailing list Message-Id: <60503DAA-7DA4-467C-A21E-B02D61FA9390@sgi.com> From: Felix Blyakher To: david@lang.hm In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [GIT PULL] XFS update for 2.6.30 Date: Fri, 3 Apr 2009 20:54:55 -0500 References: <20090331053013.7642414167108@attica.americas.sgi.com> <8A177E56-84E9-487E-930E-9C6805E17184@sgi.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Apr 3, 2009, at 8:19 PM, david@lang.hm wrote: > On Fri, 3 Apr 2009, Felix Blyakher wrote: > >> On Apr 3, 2009, at 12:02 PM, Linus Torvalds wrote: >> >>> On Fri, 3 Apr 2009, Linus Torvalds wrote: >>>> On Thu, 2 Apr 2009, Felix Blyakher wrote: >>>>> Were there any problems pulling from the xfs repository? >>>> Sorry, no - just too much email, too many trees to look at, too >>>> many >>>> people to argue with. >>>> Pulled. >>> Side note - I almost unpulled afterwards. >> >> That was my concern, i.e. it's not pulled without explicit >> NAK. I knew about your possible concerns. >> >>> You've done several apparently totally useless pulls from my tree at >>> random points. >> >> Yes, I noticed that, and agree with all your points even >> before you brought them up. >> I already started talking to people to improve my process. >> The reason the intermediate pulls from your tree were done >> is to make sure that new xfs patches would not conflict >> with some other changes already in the mainline. That was >> part of the maintainer cheat sheet given to me, and I >> didn't realize the side effects of it. >> I probably can verify the possible conflicts without pushing >> the merges into the repository and reset the working tree to >> pre pull state. > > create a temporary branch and do the merge in that. then throw away > the test branch and there is no harm to the main tree. That was suggested among other things by Ingo Molnar as well. I'm planing to follow this approach. Thanks, Felix > > > David Lang > >> At any rate, I'll find some way to manage that without >> cluttering the history with the merges. >> Any suggestions are welcome. >> >> Thanks, >> Felix >> >>> Daily "keep up-to-date with Linus' tree" pulls are _strongly_ >>> discouraged >>> (read: if this continues, I'll just stop pulling from you), >>> because it >>> makes the history totally unreadable after-the-fact. It has some >>> direct >>> technical downsides (it makes it much harder to run "git bisect" >>> and see >>> what is going on), but apart from those direct downsides it just >>> makes it >>> much harder for me - or anybody else who wants to get an overview >>> of what >>> happened - to visualize things when history is messy. >>> Instead of having a clear nice line of development that says "this >>> is what >>> happened to XFS", those merges have basically mixed up all your >>> changes >>> with all the random _other_ changes in the tree. >>> In other words, having those extra merges makes the graphical >>> tools almost >>> useless for getting some kind of "what happened" overview. >>> I realize that an occasional back-merge may be required to resolve >>> big >>> conflicts early, but they really have to be pretty big and >>> immediate for >>> it to be a win. >>> >>> Linus >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux- >> kernel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ From arekm@maven.pl Sat Apr 4 07:47:07 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BRBL autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n34Ckl0d009447 for ; Sat, 4 Apr 2009 07:46:57 -0500 X-ASG-Debug-ID: 1238849232-243301d60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from main.carme.maven.pl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 57E7513F4B5C for ; Sat, 4 Apr 2009 05:47:12 -0700 (PDT) Received: from main.carme.maven.pl (main.carme.maven.pl [193.239.45.138]) by cuda.sgi.com with ESMTP id SdHClO1VYygMHmWA for ; Sat, 04 Apr 2009 05:47:12 -0700 (PDT) Received: from chello089076029166.chello.pl ([89.76.29.166]:39312 helo=maven.pl) by main.carme.maven.pl with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Lq5G2-0001g0-Hc; Sat, 04 Apr 2009 14:45:59 +0200 Received: from arekm by maven.pl with local (Exim 4.69) (envelope-from ) id 1Lq4Wm-0002iv-GL; Sat, 04 Apr 2009 13:59:12 +0200 From: Arkadiusz Miskiewicz To: Christoph Hellwig X-ASG-Orig-Subj: Re: [PATCH] xfs: validate quota log items during log recovery Subject: Re: [PATCH] xfs: validate quota log items during log recovery Date: Sat, 4 Apr 2009 13:59:12 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.29; KDE/4.2.2; x86_64; ; ) Cc: xfs@oss.sgi.com References: <20090303175427.GA20582@infradead.org> In-Reply-To: <20090303175427.GA20582@infradead.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904041359.12439.arekm@maven.pl> X-Barracuda-Connect: main.carme.maven.pl[193.239.45.138] X-Barracuda-Start-Time: 1238849254 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22220 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tuesday 03 of March 2009, Christoph Hellwig wrote: > Arkadiusz has been seeing really strange crashes in xfs_qm_dqcheck that > I can only explain by a log item beeing too smal to actually fit the > xfs_dqblk_t we're dereferencing all over xfs_qm_dqcheck. So add > graceful checks for NULL or too small quota items to the log recovery > code. Unfortunately this validation doesn't cover my case. I still got oops even with the patch applied 1). I also tried xfs debug enabled kernel 2) 1) oops with "[PATCH] xfs: validate quota log items during log recovery" [ 37.379658] Filesystem "dm-0": Disabling barriers, trial barrier write f= ailed =20 [ 37.445959] XFS mounting filesystem dm-0 = =20 [ 39.478398] Starting XFS recovery on filesystem: dm-0 (logdev: internal)= =20 [ 42.833274] BUG: unable to handle kernel paging request at fffffffffffff= c00 =20 [ 42.835651] IP: [] xfs_qm_dqcheck+0x9ca/0x2270 [xfs] = =20 [ 42.835651] PGD 549067 PUD 54b067 PMD 0 = =20 [ 42.876885] Oops: 0002 [#1] SMP = =20 [ 42.876885] last sysfs file: /sys/devices/virtual/block/md3/dev = =20 [ 42.906879] CPU 2 = =20 [ 42.906879] Modules linked in: ext3 jbd mbcache raid456 async_xor async_= memcpy async_tx xor raid1 dm_mod e1000 e1000e ipmi_devintf ipmi_si ipmi_msg= handler 8021q garp stp xfs=20 scsi_wait_scan sd_mod crc_t10dif mptsas mptscsih mptbase scsi_transport_sas= scsi_mod raid10 md_mod =20 [ 42.976880] Pid: 1718, comm: mount Not tainted 2.6.28.9-2 #1 = = =20 [ 42.976880] RIP: 0010:[] [] xfs_qm_= dqcheck+0x9ca/0x2270 [xfs] = =20 [ 42.976880] RSP: 0018:ffff88015b53fa58 EFLAGS: 00010256 = = =20 [ 42.976880] RAX: 0000000000000000 RBX: ffff88015bcaee40 RCX: 00000000000= 00000 = =20 [ 42.976880] RDX: fffffffffffffc00 RSI: 0000000000000000 RDI: fffffffffff= ffc00 = =20 [ 42.976880] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffffffff= ffc00 = =20 [ 42.976880] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88015bc= aebc0 = =20 [ 42.976880] R13: ffff88015bcaeb40 R14: 0000000000001000 R15: ffff88015e5= 5d000 = =20 [ 42.976880] FS: 00007f3de87f27d0(0000) GS:ffff88015fa4c180(0000) knlGS:= 0000000000000000 = =20 [ 43.176886] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b = = =20 [ 43.176886] CR2: fffffffffffffc00 CR3: 000000015b501000 CR4: 00000000000= 006e0 = =20 [ 43.176886] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000= 00000 = =20 [ 43.176886] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000= 00400 = =20 [ 43.176886] Process mount (pid: 1718, threadinfo ffff88015b53e000, task = ffff88015ccd9470) = =20 [ 43.276880] Stack: = = =20 [ 43.276880] ffff88015bcaeb40 000000005d34a0c8 ffff88015b53fb98 ffffc200= 115e839c = =20 [ 43.313546] ffffc200115e83a8 0000000000000003 ffffc200115e9e00 ffffffff= a010351c = =20 [ 43.313546] 0000000000039c4a 000000015b5ab000 ffff88015b5ab000 ffff8801= 5b53fb88 = =20 [ 43.340212] Call Trace: = = =20 [ 43.340212] [] xfs_qm_dqcheck+0x208c/0x2270 [xfs] = = =20 [ 43.340212] [] xlog_get_bp+0x1e9/0x1750 [xfs] = = =20 [ 43.340212] [] xfs_dir_file_operations+0x2290/0xe906 = [xfs] = =20 [ 43.340212] [] xlog_get_bp+0x7f7/0x1750 [xfs] = = =20 [ 43.340212] [] xlog_get_bp+0x85a/0x1750 [xfs] = = =20 [ 43.340212] [] xlog_recover+0x7a/0x90 [xfs] = = =20 [ 43.340212] [] xfs_log_mount+0xa6/0xd30 [xfs] = = =20 [ 43.340212] [] xfs_mountfs+0x33b/0x680 [xfs] = = =20 [ 43.340212] [] xfs_filestream_lookup_ag+0x60/0x4f0 [x= fs] = =20 [ 43.340212] [] kmem_zalloc+0x2b/0x40 [xfs] = = =20 [ 43.340212] [] xfs_mru_cache_create+0x12f/0x160 [xfs]= = =20 [ 43.340212] [] xfs_blkdev_get+0x492/0x660 [xfs] = = =20 [ 43.340212] [] get_sb_bdev+0x174/0x1a0 = = =20 [ 43.340212] [] xfs_blkdev_get+0x230/0x660 [xfs] = = =20 [ 43.340212] [] kstrdup+0x54/0x70 = = =20 [ 43.340212] [] vfs_kern_mount+0x86/0x250 = = =20 [ 43.340212] [] do_kern_mount+0x53/0x120 = = =20 [ 43.340212] [] do_mount+0x2ed/0xa50 = = =20 [ 43.340212] [] sys_mount+0xf9/0x110 = = =20 [ 43.340212] [] system_call_fastpath+0x16/0x1b = = =20 [ 43.340212] Code: 49 8b 54 24 08 8b 42 18 85 c0 75 65 49 8b 45 28 48 8b = 58 08 8b 6b 18 85 ed 0f 84 92 00 00 00 48 63 43 14 48 8b 53 20 48 c1 e0 04 = <4c> 89 3c 02 48 63 43 14 48 8b 53 20=20 48 c1 e0 04 44 89 74 02 08 = =20 [ 43.340212] RIP [] xfs_qm_dqcheck+0x9ca/0x2270 [xfs] = = =20 [ 43.340212] RSP = = =20 [ 43.340212] CR2: fffffffffffffc00 = = =20 [ 43.340212] ---[ end trace 3fb966a92b4fc211 ]--- = = =20 [ 60.803310] 0000:05:00.0: eth0: changing MTU from 1500 to 9000 2) ops without "[PATCH] xfs: validate quota log items during log recovery" = but with xfs debug enabled kernel [ 37.768605] Filesystem "dm-0": Disabling barriers, trial barrier write f= ailed =20 [ 37.831256] XFS mounting filesystem dm-0 = =20 [ 39.575446] Starting XFS recovery on filesystem: dm-0 (logdev: internal)= =20 [ 42.482802] Assertion failed: item->ri_total > item->ri_cnt, file: fs/xf= s/xfs_log_recover.c, line: 1452 =20 [ 42.482841] ------------[ cut here ]------------ = =20 [ 42.486059] kernel BUG at fs/xfs/support/debug.c:81! = =20 [ 42.486059] invalid opcode: 0000 [#1] SMP = =20 [ 42.486059] last sysfs file: /sys/devices/virtual/block/md3/dev = =20 [ 42.486059] CPU 3 = =20 [ 42.486059] Modules linked in: ext3 jbd mbcache raid456 async_xor async_= memcpy async_tx xor raid1 dm_mod e1000 e1000e ipmi_devintf ipmi_si ipmi_msg= handler 8021q garp stp xfs=20 scsi_wait_scan sd_mod crc_t10dif mptsas mptscsih mptbase scsi_transport_sas= scsi_mod raid10 md_mod =20 [ 42.486059] Pid: 1718, comm: mount Not tainted 2.6.28.7-1 #1 = = =20 [ 42.486059] RIP: 0010:[] [] assfail= +0x1a/0x20 [xfs] = =20 [ 42.486059] RSP: 0018:ffff88015bc7ba48 EFLAGS: 00010292 = = =20 [ 42.486059] RAX: 000000000000006e RBX: ffff88015bc723c0 RCX: 00000000000= 00004 = =20 [ 42.486059] RDX: 0000000000000d0d RSI: 0000000000000046 RDI: ffffffff808= 4d310 = =20 [ 42.486059] RBP: ffffc200115e63a8 R08: 0000000000000000 R09: 00000000000= 00006 = =20 [ 42.486059] R10: ffff88015bc7b7e8 R11: 000000005bc7b8e8 R12: ffff88015bc= 72180 = =20 [ 42.486059] R13: ffff88015bc722c0 R14: 0000000000001000 R15: ffff88015e0= fb000 = =20 [ 42.486059] FS: 00007ff1ac5557d0(0000) GS:ffff88015fa4c500(0000) knlGS:= 0000000000000000 = =20 [ 42.486059] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b = = =20 [ 42.486059] CR2: 00000000006e3000 CR3: 000000015bc6d000 CR4: 00000000000= 006e0 = =20 [ 42.486059] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000= 00000 = =20 [ 42.486059] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000= 00400 = =20 [ 42.486059] Process mount (pid: 1718, threadinfo ffff88015bc7a000, task = ffff88015d0ba210) = =20 [ 42.486059] Stack: = = =20 [ 42.486059] ffffc200115e63a8 ffffffffa0119883 ffff88015bc72180 ffffc200= 115e639c = =20 [ 42.486059] ffffc200115e63a8 ffffc200115e7e00 0000000000000003 ffff8801= 5bc7bb78 = =20 [ 42.486059] ffff88015b4b4000 ffffffffa011b47e ffff88015d455680 00000001= a0132b9d = =20 [ 42.486059] Call Trace: = = =20 [ 42.486059] [] ? xlog_recover_add_to_trans+0xa3/0x1f0= [xfs] = =20 [ 42.486059] [] ? xlog_recover_process_data+0x23e/0x29= 0 [xfs] = =20 [ 42.486059] [] ? xlog_do_recovery_pass+0x389/0x810 [x= fs] = =20 [ 42.486059] [] ? default_wake_function+0x0/0x10 = = =20 [ 42.486059] [] ? xfs_dir_file_operations+0xbd20/0x245= 71 [xfs] = =20 [ 42.486059] [] ? xlog_do_log_recovery+0x56/0x100 [xfs= ] = =20 [ 42.486059] [] ? xlog_do_recover+0x20/0x250 [xfs] = = =20 [ 42.486059] [] ? xlog_recover+0x7a/0x90 [xfs] = = =20 [ 42.486059] [] ? xfs_log_mount+0xaa/0x1b0 [xfs] = = =20 [ 42.486059] [] ? xfs_mountfs+0x32b/0x6b0 [xfs] = = =20 [ 42.486059] [] ? xfs_fstrm_free_func+0x0/0xc0 [xfs] = = =20 [ 42.486059] [] ? kmem_zalloc+0x2b/0x40 [xfs] = = =20 [ 42.486059] [] ? xfs_mru_cache_create+0x12f/0x160 [xf= s] = =20 [ 42.486059] [] ? xfs_fs_fill_super+0x262/0x430 [xfs] = = =20 [ 42.486059] [] ? get_sb_bdev+0x174/0x1a0 = = =20 [ 42.486059] [] ? xfs_fs_fill_super+0x0/0x430 [xfs] = = =20 [ 42.486059] [] ? kstrdup+0x54/0x70 = = =20 [ 42.486059] [] ? vfs_kern_mount+0x86/0x250 = = =20 [ 42.486059] [] ? do_kern_mount+0x53/0x120 = = =20 [ 42.486059] [] ? do_mount+0x2ed/0xa50 = = =20 [ 42.486059] [] ? sys_mount+0xf9/0x110 = = =20 [ 42.486059] [] ? system_call_fastpath+0x16/0x1b = = =20 [ 42.486059] Code: 08 01 00 00 00 e8 77 df 26 e0 48 83 c4 18 c3 66 90 89 = d1 48 83 ec 08 48 89 f2 31 c0 48 89 fe 48 c7 c7 e0 d2 14 a0 e8 57 4b 3f e0 = <0f> 0b eb fe 66 90 41 55 41 54 49 89 f4 55=20 89 fd 48 c7 c7 80 19 = =20 [ 42.486059] RIP [] assfail+0x1a/0x20 [xfs] = = =20 [ 42.486059] RSP = = =20 [ 43.497724] ---[ end trace 07b3fe479be2dbfb ]--- = = =20 [ 59.200404] 0000:05:00.0: eth0: changing MTU from 1500 to 9000 =20 =2D-=20 Arkadiusz Mi=C5=9Bkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From felixb@sgi.com Mon Apr 6 10:32:28 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14, J_CHICKENPOX_53 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n36FW8IT174728 for ; Mon, 6 Apr 2009 10:32:18 -0500 Received: from snoot.americas.sgi.com (cxfsopus16.americas.sgi.com [128.162.240.194]) by relay1.corp.sgi.com (Postfix) with ESMTP id CFF1E8F8094 for ; Mon, 6 Apr 2009 08:31:42 -0700 (PDT) Received: by snoot.americas.sgi.com (Postfix, from userid 29043) id AA9E41A8CD10; Mon, 6 Apr 2009 10:26:16 -0500 (CDT) From: Felix Blyakher To: xfs@oss.sgi.com Cc: Felix Blyakher Subject: [PATCH] xfstests: fix async io error handling in fsx Date: Mon, 6 Apr 2009 10:26:16 -0500 Message-Id: <1239031576-26279-1-git-send-email-felixb@sgi.com> X-Mailer: git-send-email 1.5.4.rc3 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean The result of async io returned in the event.res in addition to the number of bytes read/written provides negated error number. The broken libaio defines event.res as unsigned while the same structure in the kernel defines it as signed. The kernel indeed treats it as signed, and returns the negated error number. Till libaio is fixed we provide the signed long temp var. Also set errno for each error condition in aio_rw, as the caller is not aio aware and expects ret(-1)+errno by the traditional libc convention. Signed-off-by: Felix Blyakher --- ltp/fsx.c | 43 ++++++++++++++++++++++++++++++++++++------- 1 files changed, 36 insertions(+), 7 deletions(-) diff --git a/ltp/fsx.c b/ltp/fsx.c index ebe5324..210afd5 100644 --- a/ltp/fsx.c +++ b/ltp/fsx.c @@ -962,6 +962,7 @@ __aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) static struct timespec ts; struct iocb *iocbs[] = { &iocb }; int ret; + long res; if (rw == READ) { io_prep_pread(&iocb, fd, buf, len, offset); @@ -976,21 +977,49 @@ __aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) fprintf(stderr, "errcode=%d\n", ret); fprintf(stderr, "aio_rw: io_submit failed: %s\n", strerror(ret)); - return(-1); + goto out_error; } ret = io_getevents(io_ctx, 1, 1, &event, &ts); if (ret != 1) { - fprintf(stderr, "errcode=%d\n", ret); - fprintf(stderr, "aio_rw: io_getevents failed: %s\n", - strerror(ret)); - return -1; + if (ret == 0) + fprintf(stderr, "aio_rw: no events available\n"); + else { + fprintf(stderr, "errcode=%d\n", -ret); + fprintf(stderr, "aio_rw: io_getevents failed: %s\n", + strerror(-ret)); + } + goto out_error; } if (len != event.res) { - fprintf(stderr, "bad read length: %lu instead of %u\n", - event.res, len); + /* + * The b0rked libaio defines event.res as unsigned. + * However the kernel strucuture has it signed, + * and it's used to pass negated error value. + * Till the library is fixed use the temp var. + */ + res = (long)event.res; + if (res >= 0) + fprintf(stderr, "bad io length: %lu instead of %u\n", + res, len); + else { + fprintf(stderr, "errcode=%d\n", -res); + fprintf(stderr, "aio_rw: async io failed: %s\n", + strerror(-res)); + ret = res; + goto out_error; + } + } return event.res; + +out_error: + /* + * The caller expects error return in traditional libc + * convention, i.e. -1 and the errno set to error. + */ + errno = -ret; + return -1; } int aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) -- 1.5.4.rc3 From BATV+40151ff64ec39679e1dc+2052+infradead.org+hch@bombadil.srs.infradead.org Mon Apr 6 11:34:18 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_53 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n36GXqX7177782 for ; Mon, 6 Apr 2009 11:34:08 -0500 X-ASG-Debug-ID: 1239035611-2aad032a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E399C1C9AF1F; Mon, 6 Apr 2009 09:33:31 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id nMLDHOv4hUQZOlAx; Mon, 06 Apr 2009 09:33:31 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LqrlL-00048E-IY; Mon, 06 Apr 2009 16:33:31 +0000 Date: Mon, 6 Apr 2009 12:33:31 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfstests: fix async io error handling in fsx Subject: Re: [PATCH] xfstests: fix async io error handling in fsx Message-ID: <20090406163331.GA22240@infradead.org> References: <1239031576-26279-1-git-send-email-felixb@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1239031576-26279-1-git-send-email-felixb@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239035611 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Apr 06, 2009 at 10:26:16AM -0500, Felix Blyakher wrote: > The result of async io returned in the event.res in addition > to the number of bytes read/written provides negated error > number. The broken libaio defines event.res as unsigned > while the same structure in the kernel defines it as signed. > The kernel indeed treats it as signed, and returns the > negated error number. Till libaio is fixed we provide > the signed long temp var. > Also set errno for each error condition in aio_rw, as the > caller is not aio aware and expects ret(-1)+errno by the > traditional libc convention. Looks good. Reviewed-by: Christoph Hellwig From BATV+40151ff64ec39679e1dc+2052+infradead.org+hch@bombadil.srs.infradead.org Mon Apr 6 12:39:44 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n36HdHkY181222 for ; Mon, 6 Apr 2009 12:39:34 -0500 X-ASG-Debug-ID: 1239039537-34a402a10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4F0711F17D6 for ; Mon, 6 Apr 2009 10:38:57 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id AW6JgA8uxm3llbHz for ; Mon, 06 Apr 2009 10:38:57 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lqsmd-00027T-ES; Mon, 06 Apr 2009 17:38:56 +0000 Date: Mon, 6 Apr 2009 13:38:55 -0400 From: Christoph Hellwig To: Curtis Doty Cc: XFS X-ASG-Orig-Subj: Re: why xfs_write() race with O_DIRECT only? Subject: Re: why xfs_write() race with O_DIRECT only? Message-ID: <20090406173846.GA30403@infradead.org> References: <49CD7912.6080508@GreenKey.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49CD7912.6080508@GreenKey.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239039537 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, Mar 27, 2009 at 06:10:42PM -0700, Curtis Doty wrote: > I'm guessing this is the race fixed in 2.6.29. > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=25051158 > > But my app is running O_DIRECT and only calls pwrite(). Is there > something I'm missing that explains the aio stuff etc.? The aboe patch only matters when using dmapi. Can you send a simple sample program or other kind of testcases that reproduces the bug that you see? From BATV+40151ff64ec39679e1dc+2052+infradead.org+hch@bombadil.srs.infradead.org Mon Apr 6 12:42:23 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n36Hfweu181344 for ; Mon, 6 Apr 2009 12:42:13 -0500 X-ASG-Debug-ID: 1239039758-6de903c60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 84CC313FA4FD for ; Mon, 6 Apr 2009 10:42:39 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id JNd6xoQLUliazkMG for ; Mon, 06 Apr 2009 10:42:39 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LqsoB-0005IR-PJ; Mon, 06 Apr 2009 17:40:35 +0000 Date: Mon, 6 Apr 2009 13:40:31 -0400 From: Christoph Hellwig To: Christopher Layne Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_trans_log_inode: OOPS in 2.6.28.7 Subject: Re: xfs_trans_log_inode: OOPS in 2.6.28.7 Message-ID: <20090406174030.GA8943@infradead.org> References: <20090402024744.GB23044@ns1.signalpunk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090402024744.GB23044@ns1.signalpunk.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239039779 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Apr 02, 2009 at 02:47:44AM +0000, Christopher Layne wrote: > While I think I might be able to reproduce this it's not something I > particularly want to reproduce. The precursor was cancelling an > already running xfs_fsr, removing the .fsr_last, and immediately > restarting it (forcing a new cycle). Right after I received an OOPS and > all file system access was blocked necessitating a hard reboot and > xfs_repair. The a5a5a5 in there looks like slab poisoning. I'll try to come up with a testcase based on your above report to try to reproduce it. From felixb@sgi.com Mon Apr 6 17:15:13 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n36MErxk218053 for ; Mon, 6 Apr 2009 17:15:03 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id 09F728F8078 for ; Mon, 6 Apr 2009 15:14:33 -0700 (PDT) Received: from eagdhcp-232-146.americas.sgi.com (eagdhcp-232-146.americas.sgi.com [128.162.232.146]) by estes.americas.sgi.com (Postfix) with ESMTP id 6837E7000103; Mon, 6 Apr 2009 17:11:57 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: <6DD58BEE-122C-4283-A9C8-AA3EEE50D60D@sgi.com> From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090318094132.430583000@bombadil.infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: [PATCH 5/5] xfs: remove m_attroffset Date: Mon, 6 Apr 2009 17:11:57 -0500 References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.430583000@bombadil.infradead.org> X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mar 18, 2009, at 4:41 AM, Christoph Hellwig wrote: > With the upcoming v3 inodes the default attroffset needs to be > calculated > for each specific inode, so we can't cache it in the superblock > anymore. > > Also replace the assert for wrong inode sizes with a proper error > check > also included in non-debug builds. Note that the ENOSYS retourn for > that might seem odd, but that error is returned by > xfs_mount_validate_sb > for all theoretically valid but not supported filesystem geometries. > > > Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher > > > Index: xfs/fs/xfs/xfs_mount.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_mount.c 2009-03-18 07:37:20.566978952 +0100 > +++ xfs/fs/xfs/xfs_mount.c 2009-03-18 07:47:49.573979000 +0100 > @@ -333,6 +333,22 @@ xfs_mount_validate_sb( > return XFS_ERROR(ENOSYS); > } > > + /* > + * Currently only very few inode sizes are supported. > + */ > + switch (sbp->sb_inodesize) { > + case 256: > + case 512: > + case 1024: > + case 2048: > + break; > + default: > + xfs_fs_mount_cmn_err(flags, > + "inode size of %d bytes not supported", > + sbp->sb_inodesize); > + return XFS_ERROR(ENOSYS); > + } > + > if (xfs_sb_validate_fsb_count(sbp, sbp->sb_dblocks) || > xfs_sb_validate_fsb_count(sbp, sbp->sb_rblocks)) { > xfs_fs_mount_cmn_err(flags, > @@ -655,27 +671,6 @@ xfs_mount_common(xfs_mount_t *mp, xfs_sb > mp->m_blockwsize = sbp->sb_blocksize >> XFS_WORDLOG; > mp->m_blockwmask = mp->m_blockwsize - 1; > > - /* > - * Setup for attributes, in case they get created. > - * This value is for inodes getting attributes for the first time, > - * the per-inode value is for old attribute values. > - */ > - ASSERT(sbp->sb_inodesize >= 256 && sbp->sb_inodesize <= 2048); > - switch (sbp->sb_inodesize) { > - case 256: > - mp->m_attroffset = XFS_LITINO(mp) - > - XFS_BMDR_SPACE_CALC(MINABTPTRS); > - break; > - case 512: > - case 1024: > - case 2048: > - mp->m_attroffset = XFS_BMDR_SPACE_CALC(6 * MINABTPTRS); > - break; > - default: > - ASSERT(0); > - } > - ASSERT(mp->m_attroffset < XFS_LITINO(mp)); > - > mp->m_alloc_mxr[0] = xfs_allocbt_maxrecs(mp, sbp->sb_blocksize, 1); > mp->m_alloc_mxr[1] = xfs_allocbt_maxrecs(mp, sbp->sb_blocksize, 0); > mp->m_alloc_mnr[0] = mp->m_alloc_mxr[0] / 2; > Index: xfs/fs/xfs/xfs_attr_leaf.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_attr_leaf.c 2009-03-18 07:37:20.570978763 > +0100 > +++ xfs/fs/xfs/xfs_attr_leaf.c 2009-03-18 07:37:23.768978423 +0100 > @@ -155,7 +155,8 @@ xfs_attr_shortform_bytesfit(xfs_inode_t > * minimum offset only needs to be the space required for > * the btree root. > */ > - if (!dp->i_d.di_forkoff && dp->i_df.if_bytes > mp->m_attroffset) > + if (!dp->i_d.di_forkoff && dp->i_df.if_bytes > > + xfs_default_attroffset(dp)) > dsize = XFS_BMDR_SPACE_CALC(MINDBTPTRS); > break; > > Index: xfs/fs/xfs/xfs_bmap.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_bmap.c 2009-03-18 07:37:20.575978772 +0100 > +++ xfs/fs/xfs/xfs_bmap.c 2009-03-18 07:37:23.770978468 +0100 > @@ -3569,6 +3569,27 @@ xfs_bmap_extents_to_btree( > } > > /* > + * Calculate the default attribute fork offset for newly created > inodes. > + */ > +uint > +xfs_default_attroffset( > + struct xfs_inode *ip) > +{ > + struct xfs_mount *mp = ip->i_mount; > + uint offset; > + > + if (mp->m_sb.sb_inodesize == 256) { > + offset = XFS_LITINO(mp) - > + XFS_BMDR_SPACE_CALC(MINABTPTRS); > + } else { > + offset = XFS_BMDR_SPACE_CALC(6 * MINABTPTRS); > + } > + > + ASSERT(offset < XFS_LITINO(mp)); > + return offset; > +} > + > +/* > * Helper routine to reset inode di_forkoff field when switching > * attribute fork from local to extent format - we reset it where > * possible to make space available for inline data fork extents. > @@ -3580,15 +3601,18 @@ xfs_bmap_forkoff_reset( > int whichfork) > { > if (whichfork == XFS_ATTR_FORK && > - (ip->i_d.di_format != XFS_DINODE_FMT_DEV) && > - (ip->i_d.di_format != XFS_DINODE_FMT_UUID) && > - (ip->i_d.di_format != XFS_DINODE_FMT_BTREE) && > - ((mp->m_attroffset >> 3) > ip->i_d.di_forkoff)) { > - ip->i_d.di_forkoff = mp->m_attroffset >> 3; > - ip->i_df.if_ext_max = XFS_IFORK_DSIZE(ip) / > - (uint)sizeof(xfs_bmbt_rec_t); > - ip->i_afp->if_ext_max = XFS_IFORK_ASIZE(ip) / > - (uint)sizeof(xfs_bmbt_rec_t); > + ip->i_d.di_format != XFS_DINODE_FMT_DEV && > + ip->i_d.di_format != XFS_DINODE_FMT_UUID && > + ip->i_d.di_format != XFS_DINODE_FMT_BTREE) { > + uint dfl_forkoff = xfs_default_attroffset(ip) >> 3; > + > + if (dfl_forkoff > ip->i_d.di_forkoff) { > + ip->i_d.di_forkoff = dfl_forkoff; > + ip->i_df.if_ext_max = > + XFS_IFORK_DSIZE(ip) / sizeof(xfs_bmbt_rec_t); > + ip->i_afp->if_ext_max = > + XFS_IFORK_ASIZE(ip) / sizeof(xfs_bmbt_rec_t); > + } > } > } > > @@ -4057,7 +4081,7 @@ xfs_bmap_add_attrfork( > case XFS_DINODE_FMT_BTREE: > ip->i_d.di_forkoff = xfs_attr_shortform_bytesfit(ip, size); > if (!ip->i_d.di_forkoff) > - ip->i_d.di_forkoff = mp->m_attroffset >> 3; > + ip->i_d.di_forkoff = xfs_default_attroffset(ip) >> 3; > else if (mp->m_flags & XFS_MOUNT_ATTR2) > version = 2; > break; > @@ -4204,12 +4228,12 @@ xfs_bmap_compute_maxlevels( > * (a signed 16-bit number, xfs_aextnum_t). > * > * Note that we can no longer assume that if we are in ATTR1 that > - * the fork offset of all the inodes will be (m_attroffset >> 3) > - * because we could have mounted with ATTR2 and then mounted back > - * with ATTR1, keeping the di_forkoff's fixed but probably at > - * various positions. Therefore, for both ATTR1 and ATTR2 > - * we have to assume the worst case scenario of a minimum size > - * available. > + * the fork offset of all the inodes will be > + * (xfs_default_attroffset(ip) >> 3) because we could have mounted > + * with ATTR2 and then mounted back with ATTR1, keeping the > + * di_forkoff's fixed but probably at various positions. Therefore, > + * for both ATTR1 and ATTR2 we have to assume the worst case > scenario > + * of a minimum size available. > */ > if (whichfork == XFS_DATA_FORK) { > maxleafents = MAXEXTNUM; > Index: xfs/fs/xfs/xfs_bmap.h > =================================================================== > --- xfs.orig/fs/xfs/xfs_bmap.h 2009-03-18 07:37:20.579979142 +0100 > +++ xfs/fs/xfs/xfs_bmap.h 2009-03-18 07:37:23.772979002 +0100 > @@ -338,6 +338,10 @@ xfs_check_nostate_extents( > xfs_extnum_t idx, > xfs_extnum_t num); > > +uint > +xfs_default_attroffset( > + struct xfs_inode *ip); > + > #ifdef __KERNEL__ > > /* > Index: xfs/fs/xfs/xfs_mount.h > =================================================================== > --- xfs.orig/fs/xfs/xfs_mount.h 2009-03-18 07:37:20.585978718 +0100 > +++ xfs/fs/xfs/xfs_mount.h 2009-03-18 07:37:23.772979002 +0100 > @@ -198,7 +198,6 @@ typedef struct xfs_mount { > int m_fixedfsid[2]; /* unchanged for life of FS */ > uint m_dmevmask; /* DMI events for this FS */ > __uint64_t m_flags; /* global mount flags */ > - uint m_attroffset; /* inode attribute offset */ > uint m_dir_node_ents; /* #entries in a dir danode */ > uint m_attr_node_ents; /* #entries in attr danode */ > int m_ialloc_inos; /* inodes in inode allocation */ > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From BATV+40151ff64ec39679e1dc+2052+infradead.org+hch@bombadil.srs.infradead.org Mon Apr 6 17:29:39 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n36MTEqu218745 for ; Mon, 6 Apr 2009 17:29:29 -0500 X-ASG-Debug-ID: 1239056912-5bd3006b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D16131C9D627; Mon, 6 Apr 2009 15:28:32 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 4OqZVXTiFyu0MGqk; Mon, 06 Apr 2009 15:28:32 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LqxIu-0003E7-4V; Mon, 06 Apr 2009 22:28:32 +0000 Date: Mon, 6 Apr 2009 18:28:32 -0400 From: Christoph Hellwig To: Felix Blyakher , Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/2, RESEND] [XFS] a couple of fixes Subject: Re: [PATCH 0/2, RESEND] [XFS] a couple of fixes Message-ID: <20090406222831.GA12016@infradead.org> References: <1237116342-25701-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237116342-25701-1-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239056933 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I've sucked these patches into my tree after reviewin and QAing them. Felix, can you pull this and send it to Linus for 2.6.30? git://git.kernel.org/pub/scm/fs/xfs/xfs.git From sandeen@sandeen.net Mon Apr 6 18:11:31 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_64 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n36NBB51220387 for ; Mon, 6 Apr 2009 18:11:21 -0500 X-ASG-Debug-ID: 1239059449-77c6013e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9D0441F28D6 for ; Mon, 6 Apr 2009 16:10:50 -0700 (PDT) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id Msqs4FR3Kjfcm4GJ for ; Mon, 06 Apr 2009 16:10:50 -0700 (PDT) Received: from Liberator.local (72-254-110-249.client.stsn.net [72.254.110.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 51403AA60DE; Mon, 6 Apr 2009 18:10:45 -0500 (CDT) Message-ID: <49DA8BF2.20206@sandeen.net> Date: Mon, 06 Apr 2009 16:10:42 -0700 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com, Felix Blyakher X-ASG-Orig-Subj: Re: [PATCH 1/2] xfs: a couple getbmap cleanups Subject: Re: [PATCH 1/2] xfs: a couple getbmap cleanups References: <20090224133858.GB15820@infradead.org> In-Reply-To: <20090224133858.GB15820@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1239059450 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22441 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > - reshuffle various conditionals for data vs attr fork to make the code > more readable > - do fine-grainded goto-based error handling > - exit early from conditionals instead of keeping a long else branch > around > - allow kmem_alloc to fail > > Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen > Index: xfs/fs/xfs/xfs_bmap.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_bmap.c 2009-02-23 18:08:35.352924726 +0100 > +++ xfs/fs/xfs/xfs_bmap.c 2009-02-23 18:23:49.527051836 +0100 > @@ -5857,7 +5857,7 @@ xfs_getbmap( > void *arg) /* formatter arg */ > { > __int64_t bmvend; /* last block requested */ > - int error; /* return value */ > + int error = 0; /* return value */ > __int64_t fixlen; /* length for -1 case */ > int i; /* extent number */ > int lock; /* lock state */ > @@ -5876,30 +5876,8 @@ xfs_getbmap( > > mp = ip->i_mount; > iflags = bmv->bmv_iflags; > - > whichfork = iflags & BMV_IF_ATTRFORK ? XFS_ATTR_FORK : XFS_DATA_FORK; > > - /* If the BMV_IF_NO_DMAPI_READ interface bit specified, do not > - * generate a DMAPI read event. Otherwise, if the DM_EVENT_READ > - * bit is set for the file, generate a read event in order > - * that the DMAPI application may do its thing before we return > - * the extents. Usually this means restoring user file data to > - * regions of the file that look like holes. > - * > - * The "old behavior" (from XFS_IOC_GETBMAP) is to not specify > - * BMV_IF_NO_DMAPI_READ so that read events are generated. > - * If this were not true, callers of ioctl( XFS_IOC_GETBMAP ) > - * could misinterpret holes in a DMAPI file as true holes, > - * when in fact they may represent offline user data. > - */ > - if ((iflags & BMV_IF_NO_DMAPI_READ) == 0 && > - DM_EVENT_ENABLED(ip, DM_EVENT_READ) && > - whichfork == XFS_DATA_FORK) { > - error = XFS_SEND_DATA(mp, DM_EVENT_READ, ip, 0, 0, 0, NULL); > - if (error) > - return XFS_ERROR(error); > - } > - > if (whichfork == XFS_ATTR_FORK) { > if (XFS_IFORK_Q(ip)) { > if (ip->i_d.di_aformat != XFS_DINODE_FMT_EXTENTS && > @@ -5913,11 +5891,37 @@ xfs_getbmap( > ip->i_mount); > return XFS_ERROR(EFSCORRUPTED); > } > - } else if (ip->i_d.di_format != XFS_DINODE_FMT_EXTENTS && > - ip->i_d.di_format != XFS_DINODE_FMT_BTREE && > - ip->i_d.di_format != XFS_DINODE_FMT_LOCAL) > - return XFS_ERROR(EINVAL); > - if (whichfork == XFS_DATA_FORK) { > + > + prealloced = 0; > + fixlen = 1LL << 32; > + } else { > + /* > + * If the BMV_IF_NO_DMAPI_READ interface bit specified, do > + * not generate a DMAPI read event. Otherwise, if the > + * DM_EVENT_READ bit is set for the file, generate a read > + * event in order that the DMAPI application may do its thing > + * before we return the extents. Usually this means restoring > + * user file data to regions of the file that look like holes. > + * > + * The "old behavior" (from XFS_IOC_GETBMAP) is to not specify > + * BMV_IF_NO_DMAPI_READ so that read events are generated. > + * If this were not true, callers of ioctl(XFS_IOC_GETBMAP) > + * could misinterpret holes in a DMAPI file as true holes, > + * when in fact they may represent offline user data. > + */ > + if (DM_EVENT_ENABLED(ip, DM_EVENT_READ) && > + !(iflags & BMV_IF_NO_DMAPI_READ)) { > + error = XFS_SEND_DATA(mp, DM_EVENT_READ, ip, > + 0, 0, 0, NULL); > + if (error) > + return XFS_ERROR(error); > + } > + > + if (ip->i_d.di_format != XFS_DINODE_FMT_EXTENTS && > + ip->i_d.di_format != XFS_DINODE_FMT_BTREE && > + ip->i_d.di_format != XFS_DINODE_FMT_LOCAL) > + return XFS_ERROR(EINVAL); > + > if (xfs_get_extsz_hint(ip) || > ip->i_d.di_flags & (XFS_DIFLAG_PREALLOC|XFS_DIFLAG_APPEND)){ > prealloced = 1; > @@ -5926,42 +5930,34 @@ xfs_getbmap( > prealloced = 0; > fixlen = ip->i_size; > } > - } else { > - prealloced = 0; > - fixlen = 1LL << 32; > } > > if (bmv->bmv_length == -1) { > fixlen = XFS_FSB_TO_BB(mp, XFS_B_TO_FSB(mp, fixlen)); > - bmv->bmv_length = MAX( (__int64_t)(fixlen - bmv->bmv_offset), > - (__int64_t)0); > - } else if (bmv->bmv_length < 0) > - return XFS_ERROR(EINVAL); > - if (bmv->bmv_length == 0) { > + bmv->bmv_length = > + max_t(__int64_t, fixlen - bmv->bmv_offset, 0); > + } else if (bmv->bmv_length == 0) { > bmv->bmv_entries = 0; > return 0; > + } else if (bmv->bmv_length < 0) { > + return XFS_ERROR(EINVAL); > } > + > nex = bmv->bmv_count - 1; > if (nex <= 0) > return XFS_ERROR(EINVAL); > bmvend = bmv->bmv_offset + bmv->bmv_length; > > xfs_ilock(ip, XFS_IOLOCK_SHARED); > - > - if (((iflags & BMV_IF_DELALLOC) == 0) && > - (whichfork == XFS_DATA_FORK) && > - (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size)) { > - /* xfs_fsize_t last_byte = xfs_file_last_byte(ip); */ > - error = xfs_flush_pages(ip, (xfs_off_t)0, > - -1, 0, FI_REMAPF); > - if (error) { > - xfs_iunlock(ip, XFS_IOLOCK_SHARED); > - return error; > + if (whichfork == XFS_DATA_FORK && !(iflags & BMV_IF_DELALLOC)) { > + if (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size) { > + error = xfs_flush_pages(ip, 0, -1, 0, FI_REMAPF); > + if (error) > + goto out_unlock_iolock; > } > - } > > - ASSERT(whichfork == XFS_ATTR_FORK || (iflags & BMV_IF_DELALLOC) || > - ip->i_delayed_blks == 0); > + ASSERT(ip->i_delayed_blks == 0); > + } > > lock = xfs_ilock_map_shared(ip); > > @@ -5972,23 +5968,24 @@ xfs_getbmap( > if (nex > XFS_IFORK_NEXTENTS(ip, whichfork) * 2 + 1) > nex = XFS_IFORK_NEXTENTS(ip, whichfork) * 2 + 1; > > - bmapi_flags = xfs_bmapi_aflag(whichfork) | > - ((iflags & BMV_IF_PREALLOC) ? 0 : XFS_BMAPI_IGSTATE); > + bmapi_flags = xfs_bmapi_aflag(whichfork); > + if (!(iflags & BMV_IF_PREALLOC)) > + bmapi_flags |= XFS_BMAPI_IGSTATE; > > /* > * Allocate enough space to handle "subnex" maps at a time. > */ > subnex = 16; > - map = kmem_alloc(subnex * sizeof(*map), KM_SLEEP); > + map = kmem_alloc(subnex * sizeof(*map), KM_MAYFAIL); > + if (!map) > + goto out_unlock_ilock; > > bmv->bmv_entries = 0; > > - if ((XFS_IFORK_NEXTENTS(ip, whichfork) == 0)) { > - if (((iflags & BMV_IF_DELALLOC) == 0) || > - whichfork == XFS_ATTR_FORK) { > - error = 0; > - goto unlock_and_return; > - } > + if (XFS_IFORK_NEXTENTS(ip, whichfork) == 0 && > + (whichfork == XFS_ATTR_FORK || !(iflags & BMV_IF_DELALLOC))) { > + error = 0; > + goto out_free_map; > } > > nexleft = nex; > @@ -6000,10 +5997,12 @@ xfs_getbmap( > bmapi_flags, NULL, 0, map, &nmap, > NULL, NULL); > if (error) > - goto unlock_and_return; > + goto out_free_map; > ASSERT(nmap <= subnex); > > for (i = 0; i < nmap && nexleft && bmv->bmv_length; i++) { > + int full = 0; /* user array is full */ > + > out.bmv_oflags = 0; > if (map[i].br_state == XFS_EXT_UNWRITTEN) > out.bmv_oflags |= BMV_OF_PREALLOC; > @@ -6018,36 +6017,32 @@ xfs_getbmap( > whichfork == XFS_ATTR_FORK) { > /* came to the end of attribute fork */ > out.bmv_oflags |= BMV_OF_LAST; > - goto unlock_and_return; > - } else { > - int full = 0; /* user array is full */ > - > - if (!xfs_getbmapx_fix_eof_hole(ip, &out, > - prealloced, bmvend, > - map[i].br_startblock)) { > - goto unlock_and_return; > - } > - > - /* format results & advance arg */ > - error = formatter(&arg, &out, &full); > - if (error || full) > - goto unlock_and_return; > - nexleft--; > - bmv->bmv_offset = > - out.bmv_offset + out.bmv_length; > - bmv->bmv_length = MAX((__int64_t)0, > - (__int64_t)(bmvend - bmv->bmv_offset)); > - bmv->bmv_entries++; > + goto out_free_map; > } > + > + if (!xfs_getbmapx_fix_eof_hole(ip, &out, prealloced, > + bmvend, map[i].br_startblock)) > + goto out_free_map; > + > + /* format results & advance arg */ > + error = formatter(&arg, &out, &full); > + if (error || full) > + goto out_free_map; > + nexleft--; > + bmv->bmv_offset = > + out.bmv_offset + out.bmv_length; > + bmv->bmv_length = > + max_t(__int64_t, 0, bmvend - bmv->bmv_offset); > + bmv->bmv_entries++; > } > } while (nmap && nexleft && bmv->bmv_length); > > -unlock_and_return: > + out_free_map: > + kmem_free(map); > + out_unlock_ilock: > xfs_iunlock_map_shared(ip, lock); > + out_unlock_iolock: > xfs_iunlock(ip, XFS_IOLOCK_SHARED); > - > - kmem_free(map); > - > return error; > } > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From sandeen@sandeen.net Mon Apr 6 18:57:08 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64, J_CHICKENPOX_66 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n36Numse222785 for ; Mon, 6 Apr 2009 18:56:58 -0500 X-ASG-Debug-ID: 1239062186-77c702150000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 795E51F3408 for ; Mon, 6 Apr 2009 16:56:27 -0700 (PDT) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 3Fb6byx39tqeyA6e for ; Mon, 06 Apr 2009 16:56:27 -0700 (PDT) Received: from Liberator.local (72-254-110-249.client.stsn.net [72.254.110.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 8B5CBAA60DE; Mon, 6 Apr 2009 18:56:25 -0500 (CDT) Message-ID: <49DA96A6.2010201@sandeen.net> Date: Mon, 06 Apr 2009 16:56:22 -0700 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/2] xfs: fix getbmap vs mmap deadlock Subject: Re: [PATCH 2/2] xfs: fix getbmap vs mmap deadlock References: <20090224133902.GC15820@infradead.org> In-Reply-To: <20090224133902.GC15820@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1239062187 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22445 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > xfs_getbmap (or rather the formatters called by it) copy out the getbmap > structures under the ilock, which can deadlock against mmap. This has > been reported via bugzilla a while ago (#717) and has recently also > shown up via lockdep. > > So allocate a temporary buffer to format the kernel getbmap structures > into and then copy them out after dropping the locks. > > A little problem with this is that we limit the number of extents we > can copy out by the maximum allocation size, but I see no real way > around that. > > > Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen > Index: xfs/fs/xfs/xfs_bmap.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_bmap.c 2009-02-23 20:38:27.512925014 +0100 > +++ xfs/fs/xfs/xfs_bmap.c 2009-02-23 20:40:46.720926193 +0100 > @@ -5867,12 +5867,13 @@ xfs_getbmap( > int nexleft; /* # of user extents left */ > int subnex; /* # of bmapi's can do */ > int nmap; /* number of map entries */ > - struct getbmapx out; /* output structure */ > + struct getbmapx *out; /* output structure */ > int whichfork; /* data or attr fork */ > int prealloced; /* this is a file with > * preallocated data space */ > int iflags; /* interface flags */ > int bmapi_flags; /* flags for xfs_bmapi */ > + int cur_ext = 0; > > mp = ip->i_mount; > iflags = bmv->bmv_iflags; > @@ -5948,6 +5949,13 @@ xfs_getbmap( > return XFS_ERROR(EINVAL); > bmvend = bmv->bmv_offset + bmv->bmv_length; > > + > + if (bmv->bmv_count > ULONG_MAX / sizeof(struct getbmapx)) > + return XFS_ERROR(ENOMEM); > + out = kmem_zalloc(bmv->bmv_count * sizeof(struct getbmapx), KM_MAYFAIL); > + if (!out) > + return XFS_ERROR(ENOMEM); > + > xfs_ilock(ip, XFS_IOLOCK_SHARED); > if (whichfork == XFS_DATA_FORK && !(iflags & BMV_IF_DELALLOC)) { > if (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size) { > @@ -6001,39 +6009,39 @@ xfs_getbmap( > ASSERT(nmap <= subnex); > > for (i = 0; i < nmap && nexleft && bmv->bmv_length; i++) { > - int full = 0; /* user array is full */ > - > - out.bmv_oflags = 0; > + out[cur_ext].bmv_oflags = 0; > if (map[i].br_state == XFS_EXT_UNWRITTEN) > - out.bmv_oflags |= BMV_OF_PREALLOC; > + out[cur_ext].bmv_oflags |= BMV_OF_PREALLOC; > else if (map[i].br_startblock == DELAYSTARTBLOCK) > - out.bmv_oflags |= BMV_OF_DELALLOC; > - out.bmv_offset = XFS_FSB_TO_BB(mp, map[i].br_startoff); > - out.bmv_length = XFS_FSB_TO_BB(mp, map[i].br_blockcount); > - out.bmv_unused1 = out.bmv_unused2 = 0; > + out[cur_ext].bmv_oflags |= BMV_OF_DELALLOC; > + out[cur_ext].bmv_offset = > + XFS_FSB_TO_BB(mp, map[i].br_startoff); > + out[cur_ext].bmv_length = > + XFS_FSB_TO_BB(mp, map[i].br_blockcount); > + out[cur_ext].bmv_unused1 = 0; > + out[cur_ext].bmv_unused2 = 0; > ASSERT(((iflags & BMV_IF_DELALLOC) != 0) || > (map[i].br_startblock != DELAYSTARTBLOCK)); > if (map[i].br_startblock == HOLESTARTBLOCK && > whichfork == XFS_ATTR_FORK) { > /* came to the end of attribute fork */ > - out.bmv_oflags |= BMV_OF_LAST; > + out[cur_ext].bmv_oflags |= BMV_OF_LAST; > goto out_free_map; > } > > - if (!xfs_getbmapx_fix_eof_hole(ip, &out, prealloced, > - bmvend, map[i].br_startblock)) > + if (!xfs_getbmapx_fix_eof_hole(ip, &out[cur_ext], > + prealloced, bmvend, > + map[i].br_startblock)) > goto out_free_map; > > - /* format results & advance arg */ > - error = formatter(&arg, &out, &full); > - if (error || full) > - goto out_free_map; > nexleft--; > bmv->bmv_offset = > - out.bmv_offset + out.bmv_length; > + out[cur_ext].bmv_offset + > + out[cur_ext].bmv_length; > bmv->bmv_length = > max_t(__int64_t, 0, bmvend - bmv->bmv_offset); > bmv->bmv_entries++; > + cur_ext++; > } > } while (nmap && nexleft && bmv->bmv_length); > > @@ -6043,6 +6051,16 @@ xfs_getbmap( > xfs_iunlock_map_shared(ip, lock); > out_unlock_iolock: > xfs_iunlock(ip, XFS_IOLOCK_SHARED); > + > + for (i = 0; i < cur_ext; i++) { > + int full = 0; /* user array is full */ > + > + /* format results & advance arg */ > + error = formatter(&arg, &out[i], &full); > + if (error || full) > + break; > + } > + > return error; > } > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From felixb@sgi.com Mon Apr 6 19:58:30 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n370w9U3225603 for ; Mon, 6 Apr 2009 19:58:20 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id D48628F8078 for ; Mon, 6 Apr 2009 17:57:49 -0700 (PDT) Received: from [IPv6???1] (sshgate.corp.sgi.com [198.149.20.12]) by estes.americas.sgi.com (Postfix) with ESMTP id 77D3370001C8; Mon, 6 Apr 2009 19:57:49 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: <9EF64CF3-FDFC-4777-94A5-7295E827ABA4@sgi.com> From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090224133858.GB15820@infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [PATCH 1/2] xfs: a couple getbmap cleanups Date: Mon, 6 Apr 2009 19:57:48 -0500 References: <20090224133858.GB15820@infradead.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Feb 24, 2009, at 7:38 AM, Christoph Hellwig wrote: > - reshuffle various conditionals for data vs attr fork to make the > code > more readable > - do fine-grainded goto-based error handling > - exit early from conditionals instead of keeping a long else branch > around > - allow kmem_alloc to fail > > Signed-off-by: Christoph Hellwig > > Index: xfs/fs/xfs/xfs_bmap.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_bmap.c 2009-02-23 18:08:35.352924726 +0100 > +++ xfs/fs/xfs/xfs_bmap.c 2009-02-23 18:23:49.527051836 +0100 > @@ -5857,7 +5857,7 @@ xfs_getbmap( > void *arg) /* formatter arg */ > { > __int64_t bmvend; /* last block requested */ > - int error; /* return value */ > + int error = 0; /* return value */ > __int64_t fixlen; /* length for -1 case */ > int i; /* extent number */ > int lock; /* lock state */ > @@ -5876,30 +5876,8 @@ xfs_getbmap( > > mp = ip->i_mount; > iflags = bmv->bmv_iflags; > - > whichfork = iflags & BMV_IF_ATTRFORK ? XFS_ATTR_FORK : XFS_DATA_FORK; > > - /* If the BMV_IF_NO_DMAPI_READ interface bit specified, do not > - * generate a DMAPI read event. Otherwise, if the DM_EVENT_READ > - * bit is set for the file, generate a read event in order > - * that the DMAPI application may do its thing before we return > - * the extents. Usually this means restoring user file data to > - * regions of the file that look like holes. > - * > - * The "old behavior" (from XFS_IOC_GETBMAP) is to not specify > - * BMV_IF_NO_DMAPI_READ so that read events are generated. > - * If this were not true, callers of ioctl( XFS_IOC_GETBMAP ) > - * could misinterpret holes in a DMAPI file as true holes, > - * when in fact they may represent offline user data. > - */ > - if ((iflags & BMV_IF_NO_DMAPI_READ) == 0 && > - DM_EVENT_ENABLED(ip, DM_EVENT_READ) && > - whichfork == XFS_DATA_FORK) { > - error = XFS_SEND_DATA(mp, DM_EVENT_READ, ip, 0, 0, 0, NULL); > - if (error) > - return XFS_ERROR(error); > - } > - > if (whichfork == XFS_ATTR_FORK) { > if (XFS_IFORK_Q(ip)) { > if (ip->i_d.di_aformat != XFS_DINODE_FMT_EXTENTS && > @@ -5913,11 +5891,37 @@ xfs_getbmap( > ip->i_mount); > return XFS_ERROR(EFSCORRUPTED); > } > - } else if (ip->i_d.di_format != XFS_DINODE_FMT_EXTENTS && > - ip->i_d.di_format != XFS_DINODE_FMT_BTREE && > - ip->i_d.di_format != XFS_DINODE_FMT_LOCAL) > - return XFS_ERROR(EINVAL); > - if (whichfork == XFS_DATA_FORK) { > + > + prealloced = 0; > + fixlen = 1LL << 32; > + } else { > + /* > + * If the BMV_IF_NO_DMAPI_READ interface bit specified, do > + * not generate a DMAPI read event. Otherwise, if the > + * DM_EVENT_READ bit is set for the file, generate a read > + * event in order that the DMAPI application may do its thing > + * before we return the extents. Usually this means restoring > + * user file data to regions of the file that look like holes. > + * > + * The "old behavior" (from XFS_IOC_GETBMAP) is to not specify > + * BMV_IF_NO_DMAPI_READ so that read events are generated. > + * If this were not true, callers of ioctl(XFS_IOC_GETBMAP) > + * could misinterpret holes in a DMAPI file as true holes, > + * when in fact they may represent offline user data. > + */ > + if (DM_EVENT_ENABLED(ip, DM_EVENT_READ) && > + !(iflags & BMV_IF_NO_DMAPI_READ)) { > + error = XFS_SEND_DATA(mp, DM_EVENT_READ, ip, > + 0, 0, 0, NULL); > + if (error) > + return XFS_ERROR(error); > + } > + > + if (ip->i_d.di_format != XFS_DINODE_FMT_EXTENTS && > + ip->i_d.di_format != XFS_DINODE_FMT_BTREE && > + ip->i_d.di_format != XFS_DINODE_FMT_LOCAL) > + return XFS_ERROR(EINVAL); > + > if (xfs_get_extsz_hint(ip) || > ip->i_d.di_flags & (XFS_DIFLAG_PREALLOC|XFS_DIFLAG_APPEND)){ > prealloced = 1; > @@ -5926,42 +5930,34 @@ xfs_getbmap( > prealloced = 0; > fixlen = ip->i_size; > } > - } else { > - prealloced = 0; > - fixlen = 1LL << 32; > } > > if (bmv->bmv_length == -1) { > fixlen = XFS_FSB_TO_BB(mp, XFS_B_TO_FSB(mp, fixlen)); > - bmv->bmv_length = MAX( (__int64_t)(fixlen - bmv->bmv_offset), > - (__int64_t)0); > - } else if (bmv->bmv_length < 0) > - return XFS_ERROR(EINVAL); > - if (bmv->bmv_length == 0) { > + bmv->bmv_length = > + max_t(__int64_t, fixlen - bmv->bmv_offset, 0); > + } else if (bmv->bmv_length == 0) { > bmv->bmv_entries = 0; > return 0; > + } else if (bmv->bmv_length < 0) { > + return XFS_ERROR(EINVAL); > } > + > nex = bmv->bmv_count - 1; > if (nex <= 0) > return XFS_ERROR(EINVAL); > bmvend = bmv->bmv_offset + bmv->bmv_length; > > xfs_ilock(ip, XFS_IOLOCK_SHARED); > - > - if (((iflags & BMV_IF_DELALLOC) == 0) && > - (whichfork == XFS_DATA_FORK) && > - (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size)) { > - /* xfs_fsize_t last_byte = xfs_file_last_byte(ip); */ > - error = xfs_flush_pages(ip, (xfs_off_t)0, > - -1, 0, FI_REMAPF); > - if (error) { > - xfs_iunlock(ip, XFS_IOLOCK_SHARED); > - return error; > + if (whichfork == XFS_DATA_FORK && !(iflags & BMV_IF_DELALLOC)) { > + if (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size) { > + error = xfs_flush_pages(ip, 0, -1, 0, FI_REMAPF); > + if (error) > + goto out_unlock_iolock; > } > - } > > - ASSERT(whichfork == XFS_ATTR_FORK || (iflags & BMV_IF_DELALLOC) || > - ip->i_delayed_blks == 0); > + ASSERT(ip->i_delayed_blks == 0); > + } > > lock = xfs_ilock_map_shared(ip); > > @@ -5972,23 +5968,24 @@ xfs_getbmap( > if (nex > XFS_IFORK_NEXTENTS(ip, whichfork) * 2 + 1) > nex = XFS_IFORK_NEXTENTS(ip, whichfork) * 2 + 1; > > - bmapi_flags = xfs_bmapi_aflag(whichfork) | > - ((iflags & BMV_IF_PREALLOC) ? 0 : XFS_BMAPI_IGSTATE); > + bmapi_flags = xfs_bmapi_aflag(whichfork); > + if (!(iflags & BMV_IF_PREALLOC)) > + bmapi_flags |= XFS_BMAPI_IGSTATE; > > /* > * Allocate enough space to handle "subnex" maps at a time. > */ > subnex = 16; > - map = kmem_alloc(subnex * sizeof(*map), KM_SLEEP); > + map = kmem_alloc(subnex * sizeof(*map), KM_MAYFAIL); > + if (!map) > + goto out_unlock_ilock; Shouldn't we set error to ENOMEM here? Should the callers be taught to handle ENOMEM now? Felix > > > bmv->bmv_entries = 0; > > - if ((XFS_IFORK_NEXTENTS(ip, whichfork) == 0)) { > - if (((iflags & BMV_IF_DELALLOC) == 0) || > - whichfork == XFS_ATTR_FORK) { > - error = 0; > - goto unlock_and_return; > - } > + if (XFS_IFORK_NEXTENTS(ip, whichfork) == 0 && > + (whichfork == XFS_ATTR_FORK || !(iflags & BMV_IF_DELALLOC))) { > + error = 0; > + goto out_free_map; > } > > nexleft = nex; > @@ -6000,10 +5997,12 @@ xfs_getbmap( > bmapi_flags, NULL, 0, map, &nmap, > NULL, NULL); > if (error) > - goto unlock_and_return; > + goto out_free_map; > ASSERT(nmap <= subnex); > > for (i = 0; i < nmap && nexleft && bmv->bmv_length; i++) { > + int full = 0; /* user array is full */ > + > out.bmv_oflags = 0; > if (map[i].br_state == XFS_EXT_UNWRITTEN) > out.bmv_oflags |= BMV_OF_PREALLOC; > @@ -6018,36 +6017,32 @@ xfs_getbmap( > whichfork == XFS_ATTR_FORK) { > /* came to the end of attribute fork */ > out.bmv_oflags |= BMV_OF_LAST; > - goto unlock_and_return; > - } else { > - int full = 0; /* user array is full */ > - > - if (!xfs_getbmapx_fix_eof_hole(ip, &out, > - prealloced, bmvend, > - map[i].br_startblock)) { > - goto unlock_and_return; > - } > - > - /* format results & advance arg */ > - error = formatter(&arg, &out, &full); > - if (error || full) > - goto unlock_and_return; > - nexleft--; > - bmv->bmv_offset = > - out.bmv_offset + out.bmv_length; > - bmv->bmv_length = MAX((__int64_t)0, > - (__int64_t)(bmvend - bmv->bmv_offset)); > - bmv->bmv_entries++; > + goto out_free_map; > } > + > + if (!xfs_getbmapx_fix_eof_hole(ip, &out, prealloced, > + bmvend, map[i].br_startblock)) > + goto out_free_map; > + > + /* format results & advance arg */ > + error = formatter(&arg, &out, &full); > + if (error || full) > + goto out_free_map; > + nexleft--; > + bmv->bmv_offset = > + out.bmv_offset + out.bmv_length; > + bmv->bmv_length = > + max_t(__int64_t, 0, bmvend - bmv->bmv_offset); > + bmv->bmv_entries++; > } > } while (nmap && nexleft && bmv->bmv_length); > > -unlock_and_return: > + out_free_map: > + kmem_free(map); > + out_unlock_ilock: > xfs_iunlock_map_shared(ip, lock); > + out_unlock_iolock: > xfs_iunlock(ip, XFS_IOLOCK_SHARED); > - > - kmem_free(map); > - > return error; > } > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From felixb@sgi.com Mon Apr 6 20:47:53 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64, J_CHICKENPOX_66 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n371lXZe228607 for ; Mon, 6 Apr 2009 20:47:43 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id 778568F8073 for ; Mon, 6 Apr 2009 18:47:13 -0700 (PDT) Received: from [IPv6???1] (sshgate.corp.sgi.com [198.149.20.12]) by estes.americas.sgi.com (Postfix) with ESMTP id BEC247000103; Mon, 6 Apr 2009 19:43:06 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: <2B47193B-9486-4500-80C4-E96750BEA54B@sgi.com> From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090224133902.GC15820@infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [PATCH 2/2] xfs: fix getbmap vs mmap deadlock Date: Mon, 6 Apr 2009 19:42:57 -0500 References: <20090224133902.GC15820@infradead.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Feb 24, 2009, at 7:39 AM, Christoph Hellwig wrote: > xfs_getbmap (or rather the formatters called by it) copy out the > getbmap > structures under the ilock, which can deadlock against mmap. This has > been reported via bugzilla a while ago (#717) and has recently also > shown up via lockdep. > > So allocate a temporary buffer to format the kernel getbmap structures > into and then copy them out after dropping the locks. > > A little problem with this is that we limit the number of extents we > can copy out by the maximum allocation size, Actually with the patch we either get all requested extents, or none if we fail to get memory for them. Should we teach the callers to expect ENOMEM and repeat the call to xfs_getbmap with smaller number of extents? Felix > but I see no real way > around that. > > > > Signed-off-by: Christoph Hellwig > > Index: xfs/fs/xfs/xfs_bmap.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_bmap.c 2009-02-23 20:38:27.512925014 +0100 > +++ xfs/fs/xfs/xfs_bmap.c 2009-02-23 20:40:46.720926193 +0100 > @@ -5867,12 +5867,13 @@ xfs_getbmap( > int nexleft; /* # of user extents left */ > int subnex; /* # of bmapi's can do */ > int nmap; /* number of map entries */ > - struct getbmapx out; /* output structure */ > + struct getbmapx *out; /* output structure */ > int whichfork; /* data or attr fork */ > int prealloced; /* this is a file with > * preallocated data space */ > int iflags; /* interface flags */ > int bmapi_flags; /* flags for xfs_bmapi */ > + int cur_ext = 0; > > mp = ip->i_mount; > iflags = bmv->bmv_iflags; > @@ -5948,6 +5949,13 @@ xfs_getbmap( > return XFS_ERROR(EINVAL); > bmvend = bmv->bmv_offset + bmv->bmv_length; > > + > + if (bmv->bmv_count > ULONG_MAX / sizeof(struct getbmapx)) > + return XFS_ERROR(ENOMEM); > + out = kmem_zalloc(bmv->bmv_count * sizeof(struct getbmapx), > KM_MAYFAIL); > + if (!out) > + return XFS_ERROR(ENOMEM); > + > xfs_ilock(ip, XFS_IOLOCK_SHARED); > if (whichfork == XFS_DATA_FORK && !(iflags & BMV_IF_DELALLOC)) { > if (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size) { > @@ -6001,39 +6009,39 @@ xfs_getbmap( > ASSERT(nmap <= subnex); > > for (i = 0; i < nmap && nexleft && bmv->bmv_length; i++) { > - int full = 0; /* user array is full */ > - > - out.bmv_oflags = 0; > + out[cur_ext].bmv_oflags = 0; > if (map[i].br_state == XFS_EXT_UNWRITTEN) > - out.bmv_oflags |= BMV_OF_PREALLOC; > + out[cur_ext].bmv_oflags |= BMV_OF_PREALLOC; > else if (map[i].br_startblock == DELAYSTARTBLOCK) > - out.bmv_oflags |= BMV_OF_DELALLOC; > - out.bmv_offset = XFS_FSB_TO_BB(mp, map[i].br_startoff); > - out.bmv_length = XFS_FSB_TO_BB(mp, map[i].br_blockcount); > - out.bmv_unused1 = out.bmv_unused2 = 0; > + out[cur_ext].bmv_oflags |= BMV_OF_DELALLOC; > + out[cur_ext].bmv_offset = > + XFS_FSB_TO_BB(mp, map[i].br_startoff); > + out[cur_ext].bmv_length = > + XFS_FSB_TO_BB(mp, map[i].br_blockcount); > + out[cur_ext].bmv_unused1 = 0; > + out[cur_ext].bmv_unused2 = 0; > ASSERT(((iflags & BMV_IF_DELALLOC) != 0) || > (map[i].br_startblock != DELAYSTARTBLOCK)); > if (map[i].br_startblock == HOLESTARTBLOCK && > whichfork == XFS_ATTR_FORK) { > /* came to the end of attribute fork */ > - out.bmv_oflags |= BMV_OF_LAST; > + out[cur_ext].bmv_oflags |= BMV_OF_LAST; > goto out_free_map; > } > > - if (!xfs_getbmapx_fix_eof_hole(ip, &out, prealloced, > - bmvend, map[i].br_startblock)) > + if (!xfs_getbmapx_fix_eof_hole(ip, &out[cur_ext], > + prealloced, bmvend, > + map[i].br_startblock)) > goto out_free_map; > > - /* format results & advance arg */ > - error = formatter(&arg, &out, &full); > - if (error || full) > - goto out_free_map; > nexleft--; > bmv->bmv_offset = > - out.bmv_offset + out.bmv_length; > + out[cur_ext].bmv_offset + > + out[cur_ext].bmv_length; > bmv->bmv_length = > max_t(__int64_t, 0, bmvend - bmv->bmv_offset); > bmv->bmv_entries++; > + cur_ext++; > } > } while (nmap && nexleft && bmv->bmv_length); > > @@ -6043,6 +6051,16 @@ xfs_getbmap( > xfs_iunlock_map_shared(ip, lock); > out_unlock_iolock: > xfs_iunlock(ip, XFS_IOLOCK_SHARED); > + > + for (i = 0; i < cur_ext; i++) { > + int full = 0; /* user array is full */ > + > + /* format results & advance arg */ > + error = formatter(&arg, &out[i], &full); > + if (error || full) > + break; > + } > + > return error; > } > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From armando@escortguide.com Tue Apr 7 08:54:03 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_20,MIME_8BIT_HEADER, THEBAT_UNREG autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n37Drfq7007104 for ; Tue, 7 Apr 2009 08:53:53 -0500 X-ASG-Debug-ID: 1239112486-787300260000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from 186-48.static.alkar.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7FCC013FE77D for ; Tue, 7 Apr 2009 06:54:46 -0700 (PDT) Received: from 186-48.static.alkar.net (186-48.static.alkar.net [77.239.186.48]) by cuda.sgi.com with ESMTP id 9gz28O52UDZFIlfg for ; Tue, 07 Apr 2009 06:54:46 -0700 (PDT) Date: Tue, 07 Apr 2009 17:53:18 +0300 From: Richards X-Mailer: The Bat! (v3.99.3) UNREG Organization: ldlzfrm X-Priority: 3 (Normal) Message-Id: <314283216.200904071753@escortguide.com> To: xfs@oss.sgi.com X-ASG-Orig-Subj: =?windows-1251?b?wO3y6Orw6Ofo8e375SDo5OXoIOzg6+7j7iDh6Oft5fHgLiA4XzgwOQ==?= =?windows-1251?b?XzMzM18xMDA0ICBb5+Jv7W/qX+/rYfLt++lfMTXwL+x17V0=?= Subject: =?windows-1251?b?wO3y6Orw6Ofo8e375SDo5OXoIOzg6+7j7iDh6Oft5fHgLiA4XzgwOQ==?= =?windows-1251?b?XzMzM18xMDA0ICBb5+Jv7W/qX+/rYfLt++lfMTXwL+x17V0=?= MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: 186-48.static.alkar.net[77.239.186.48] X-Barracuda-Start-Time: 1239112487 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1598 1.0000 -1.0462 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.05 X-Barracuda-Spam-Status: No, SCORE=-1.05 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22498 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean =C8=ED=F4o=F0=ECa=F6uo=ED=EDa=FF_=F2e=EBe=F4o=ED=EDa=FF_=F1=EBy=E6=E1a_<=C8= =E4eu_=CCa=EBo=E3o_=C1u=E7=EDe=F1a> =C7=E2o=EDu=F2e u =EFo=EBy=F7a=E9=F2e =EFo=EBe=E7=EDy=FE u=ED=F4o=F0=ECa=F6= u=FE! 8 809 333 1004 (=E7=E2=EE=ED=EE=EA =EF=EB=E0=F2=ED=FB=E9 15=F0/=EC=E8=ED= ) =C3=E4=E5 =F7=E5=F0=F2 =ED=E8 =EC=EE=EB=EE=EB, =EA =ED=E0=EC =F1 =EC=F3=EA= =EE=E9 =ED=E0 =E4=E2=EE=F0. =C2=E8=E4=E8=F8=FC, =E4=E0 =ED=E5 =E2=FB=F0=E2=E5=F8=FC; =EF=EE=EA=E0=E6=F3= , =E4=E0 =ED=E5 =E2=EE=E7=FC=EC=E5=F8=FC. From BATV+6fbc271676f34c316c01+2053+infradead.org+hch@bombadil.srs.infradead.org Tue Apr 7 11:01:59 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n37G1WfF013921 for ; Tue, 7 Apr 2009 11:01:49 -0500 X-ASG-Debug-ID: 1239120072-71cf026c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 245041CA0CFD; Tue, 7 Apr 2009 09:01:13 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id uajh2beHfRECBHdU; Tue, 07 Apr 2009 09:01:13 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LrDja-0003xN-5o; Tue, 07 Apr 2009 16:01:10 +0000 Date: Tue, 7 Apr 2009 12:01:10 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 5/5] xfs: remove m_attroffset Subject: Re: [PATCH 5/5] xfs: remove m_attroffset Message-ID: <20090407160109.GA14912@infradead.org> References: <20090318094119.561416000@bombadil.infradead.org> <20090318094132.430583000@bombadil.infradead.org> <6DD58BEE-122C-4283-A9C8-AA3EEE50D60D@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6DD58BEE-122C-4283-A9C8-AA3EEE50D60D@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239120073 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This one already was in the last pull request :) From SEMA-CR-1-4673CR@ptcmarketing.com Tue Apr 7 11:24:46 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.6 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_QP_LONG_LINE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n37GOKLt014930 for ; Tue, 7 Apr 2009 11:24:35 -0500 X-ASG-Debug-ID: 1239121505-788803480000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from crmmaxx.ptc.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2186313FF9E9 for ; Tue, 7 Apr 2009 09:25:06 -0700 (PDT) Received: from crmmaxx.ptc.com (crmmaxx.ptc.com [12.11.148.125]) by cuda.sgi.com with ESMTP id NAW8w3eRf9llXtj9 for ; Tue, 07 Apr 2009 09:25:06 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation X-IronPort-AV: E=Sophos;i="4.39,338,1235970000"; d="scan'208,217";a="295910569" Received: from unknown (HELO HQCRMINT1.ptcnet.ptc.com) ([132.253.202.83]) by crmmaxx.ptc.com with ESMTP; 07 Apr 2009 12:20:09 -0400 Date: Tue, 7 Apr 2009 12:14:42 -0400 To: X-Mailer: Siebel EMS 78 [EMS 1098] main/200512201810 MIME-Version: 1.0 Reply-To: noreply@ptc.com From: "PTC Communications" X-ASG-Orig-Subj: Get More Design Power - Upgrade to Pro/ENGINEER Advanced XE Subject: Get More Design Power - Upgrade to Pro/ENGINEER Advanced XE Sender: "PTC Communications" Message-ID: Content-Type: multipart/alternative; boundary=BF_1239120924840_541107316 X-Barracuda-Connect: crmmaxx.ptc.com[12.11.148.125] X-Barracuda-Start-Time: 1239121527 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --BF_1239120924840_541107316 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: Quoted-Printable Upgrade Pro/ENGINEER Foundation XE to Advanced XE Now is the best time to upgrade to a Pro/ENGINEER package that features the = advanced tools and technology you need to invigorate your designs, boost you= r productivity, and solve your unique product development challenges. Pro/ENGINEER Advanced XE=20 (http://www.ptc.com/read?&u=3D= 1-5LWLN-2077= &c=3D= 1-3V2RCL= &o=3D= 1-445OPX= &w=3D= 2354034= &t=3Dhttp%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D90217) Designed for engineers who need more design power and more efficient design = processes, this package includes everything you already have in the Pro/ENGI= NEER Foundation XE package, plus: * Choice of data management option: - Pro/INTRALINK=C2=AE for Pro/ENGINEER data management - Windchill PDMLink for broader engineering content and process manageme= nt * Choice of one high-performance design module: - Pro/ENGINEER Advanced Assembly - Pro/ENGINEER Behavioral Modeling - Pro/ENGINEER Interactive Surface Design - Pro/ENGINEER Mechanism Dynamics - Pro/ENGINEER Piping and Cabling Click here to learn more about the Pro/ENGINEER Advanced XE package. (http://www.ptc.com/read?&u=3D= 1-5LWLN-2077= &c=3D= 1-3V2RCL= &o=3D= 1-445OPX= &w=3D= 2354034= &t=3Dhttp%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D90217)=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D contact PTC http://www.ptc.com/company/contacts/index.htm privacy policy http://www.ptc.com/company/policies/index.htm unsubscribe http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=3D= 1-445OPX= &campd=3D= 1-3V2RCL= &conud=3D= 1-5LWLN-2077= &mailkey=3D= 2354034= &email=3D= xfs@oss.sgi.com= change preferences http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=3D= 1-445OPX= &campd=3D= 1-3V2RCL= &conud=3D= 1-5LWLN-2077= &mailkey=3D= 2354034= &email=3D= xfs@oss.sgi.com= edit profile http://www.ptc.com/read?&w=3D= 2354034= &t=3D/common/account/index.htm ----------------------------------------------------------------------------= --- This email was sent to: = xfs@oss.sgi.com= PTC, 140 Kendrick Street, Needham, MA 02494 USA If you wish to unsubscribe from all PTC Emails, please send a blank email to= . --BF_1239120924840_541107316 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: Quoted-Printable Email ProE Foundation XE Upgrade NA FY09
3D"PTC.com"
3D"

Upgrade Pro/ENGINEER Foundation XE to Advanced XE=20

Now is the best time to upgrade to a Pro/ENGINEER packa= ge that features the advanced tools and technology you need to invigorate yo= ur designs, boost your productivity, and solve your unique product developme= nt challenges.

Pro/ENGINEER Ad= vanced XE

Designed for engineers who need more design power and m= ore efficient design processes, this package includes everything you already= have in the Pro/ENGINEER Foundation XE package, plus:

  • Choice of data management option:

        o  Pro/= INTRALINK® for Pro/ENGINEER data management

        o  Windchill= PDMLink for broader engineering content and process management

  • Choice of one high-performance design module:

        o  = ;Pro/ENGINEER Advanced Assembly

        o  = ;Pro/ENGINEER Behavioral Modeling

        o  Pro/= ENGINEER Interactive Surface Design

        o  Pro/= ENGINEER Mechanism Dynamics

        o  Pro/= ENGINEER Piping and Cabling

Click here<= /strong> to learn more about the Pro/ENGINEER Advanced XE package.

3D""
contact PTC | privacy policy | edit profile
This email was sent to: = xfs@oss.sgi.com=     PTC, 140 Kendrick Street, Needham, MA 02494 USA
If you wish to unsubscribe from all PTC Emails, please send a blank ema= il to unsubscribe@ptc.com.
--BF_1239120924840_541107316-- From felixb@oss.sgi.com Tue Apr 7 16:28:59 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n37LSsrC040107 for ; Tue, 7 Apr 2009 16:28:59 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n37LSsUJ040065; Tue, 7 Apr 2009 16:28:54 -0500 Date: Tue, 7 Apr 2009 16:28:54 -0500 Message-Id: <200904072128.n37LSsUJ040065@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, mainline, updated. v2.6.28-rc3-21503-g8fe74cf X-Git-Refname: refs/heads/mainline X-Git-Reftype: branch X-Git-Oldrev: 15f7176eb1cccec0a332541285ee752b935c1c85 X-Git-Newrev: 8fe74cf053de7ad2124a894996f84fa890a81093 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, mainline has been updated 8fe74cf Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 c2ec175 mm: page_mkwrite change prototype to match fault ce3b0f8 New helper - current_umask() from 15f7176eb1cccec0a332541285ee752b935c1c85 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 8fe74cf053de7ad2124a894996f84fa890a81093 Merge: c2eb2fa6d2b6fe122d3479ec5b28d978418b2698 ced117c73edc917e96dea7cca98c91383f0792f7 Author: Linus Torvalds Date: Thu Apr 2 21:09:10 2009 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6: Remove two unneeded exports and make two symbols static in fs/mpage.c Cleanup after commit 585d3bc06f4ca57f975a5a1f698f65a45ea66225 Trim includes of fdtable.h Don't crap into descriptor table in binfmt_som Trim includes in binfmt_elf Don't mess with descriptor table in load_elf_binary() Get rid of indirect include of fs_struct.h New helper - current_umask() check_unsafe_exec() doesn't care about signal handlers sharing New locking/refcounting for fs_struct Take fs_struct handling to new file (fs/fs_struct.c) Get rid of bumping fs_struct refcount in pivot_root(2) Kill unsharing fs_struct in __set_personality() commit ce3b0f8d5c2203301fc87f3aaaed73e5819e2a48 Author: Al Viro Date: Sun Mar 29 19:08:22 2009 -0400 New helper - current_umask() current->fs->umask is what most of fs_struct users are doing. Put that into a helper function. Signed-off-by: Al Viro ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_file.c | 4 ++-- fs/xfs/linux-2.6/xfs_iops.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) hooks/post-receive -- XFS development tree From felixb@oss.sgi.com Tue Apr 7 16:29:20 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n37LTE2t040218 for ; Tue, 7 Apr 2009 16:29:20 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n37LTEPg040121; Tue, 7 Apr 2009 16:29:14 -0500 Date: Tue, 7 Apr 2009 16:29:14 -0500 Message-Id: <200904072129.n37LTEPg040121@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-20848-g8de2bf9 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 1aacc064e029f0017384e463121b98f06d3a2cc3 X-Git-Newrev: 8de2bf937a6bea8f0f775fd5399ba20c1a0c3d77 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, master has been updated 8de2bf9 xfs: remove xfs_flush_space 153fec4 xfs: flush delayed allcoation blocks on ENOSPC in create e43afd7 xfs: block callers of xfs_flush_inodes() correctly 5825294 xfs: make inode flush at ENOSPC synchronous a8d770d xfs: use xfs_sync_inodes() for device flushing 9d7fef7 xfs: inform the xfsaild of the push target before sleeping c626d17 xfs: prevent unwritten extent conversion from blocking I/O completion 705db3f xfs: fix double free of inode a6cb767 xfs: validate log feature fields correctly from 1aacc064e029f0017384e463121b98f06d3a2cc3 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 8de2bf937a6bea8f0f775fd5399ba20c1a0c3d77 Author: Dave Chinner Date: Mon Apr 6 18:49:12 2009 +0200 xfs: remove xfs_flush_space The only thing we need to do now when we get an ENOSPC condition during delayed allocation reservation is flush all the other inodes with delalloc blocks on them and retry without EOF preallocation. Remove the unneeded mess that is xfs_flush_space() and just call xfs_flush_inodes() directly from xfs_iomap_write_delay(). Also, change the location of the retry label to avoid trying to do EOF preallocation because we don't want to do that at ENOSPC. This enables us to remove the BMAPI_SYNC flag as it is no longer used. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit 153fec43ce5264dfe9f3530b281a2e940b25a0a8 Author: Dave Chinner Date: Mon Apr 6 18:48:30 2009 +0200 xfs: flush delayed allcoation blocks on ENOSPC in create If we are creating lots of small files, we can fail to get a reservation for inode create earlier than we should due to EOF preallocation done during delayed allocation reservation. Hence on the first reservation ENOSPC failure flush all the delayed allocation blocks out of the system and retry. This fixes the last commonly triggered spurious ENOSPC issue that has been reported. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit e43afd72d2455defd63a3f94f22fa09b586e58ed Author: Dave Chinner Date: Mon Apr 6 18:47:27 2009 +0200 xfs: block callers of xfs_flush_inodes() correctly xfs_flush_inodes() currently uses a magic timeout to wait for some inodes to be flushed before returning. This isn't really reliable but used to be the best that could be done due to deadlock potential of waiting for the entire flush. Now the inode flush is safe to execute while we hold page and inode locks, we can wait for all the inodes to flush synchronously. Convert the wait mechanism to a completion to do this efficiently. This should remove all remaining spurious ENOSPC errors from the delayed allocation reservation path. This is extracted almost line for line from a larger patch from Mikulas Patocka. Signed-off-by: Mikulas Patocka Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit 5825294edd3364cbba6514f70d88debec4f6cec7 Author: Dave Chinner Date: Mon Apr 6 18:45:44 2009 +0200 xfs: make inode flush at ENOSPC synchronous When we are writing to a single file and hit ENOSPC, we trigger a background flush of the inode and try again. Because we hold page locks and the iolock, the flush won't proceed until after we release these locks. This occurs once we've given up and ENOSPC has been reported. Hence if this one is the only dirty inode in the system, we'll get an ENOSPC prematurely. To fix this, remove the async flush from the allocation routines and move it to the top of the write path where we can do a synchronous flush and retry the write again. Only retry once as a second ENOSPC indicates that we really are ENOSPC. This avoids a page cache deadlock when trying to do this flush synchronously in the allocation layer that was identified by Mikulas Patocka. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit a8d770d987ee20b59fba6c37d7f0f2a351913c4b Author: Dave Chinner Date: Mon Apr 6 18:44:54 2009 +0200 xfs: use xfs_sync_inodes() for device flushing Currently xfs_device_flush calls sync_blockdev() which is a no-op for XFS as all it's metadata is held in a different address to the one sync_blockdev() works on. Call xfs_sync_inodes() instead to flush all the delayed allocation blocks out. To do this as efficiently as possible, do it via two passes - one to do an async flush of all the dirty blocks and a second to wait for all the IO to complete. This requires some modification to the xfs-sync_inodes_ag() flush code to do efficiently. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit 9d7fef74b23fe57803c5f71fab11630d9ec2cb4b Author: Dave Chinner Date: Mon Apr 6 18:42:59 2009 +0200 xfs: inform the xfsaild of the push target before sleeping When trying to reserve log space, we find the amount of space we need, then go to sleep waiting for space. When we are woken, we try to push the tail of the log forward to make sure we have space available. Unfortunately, this means that if there is not space available, and everyone who needs space goes to sleep there is no-one left to push the tail of the log to make space available. Once we have a thread waiting for space to become available, the others queue up behind it in a FIFO, and none of them push the tail of the log. This can result in everyone going to sleep in xlog_grant_log_space() if the first sleeper races with the last I/O that moves the tail of the log forward. With no further I/O tomove the tail of the log, there is nothing to wake the sleepers and hence all transactions just stop. Fix this by making sure the xfsaild will create enough space for the transaction that is about to sleep by moving the push target far enough forwards to ensure that that the curent proceeees will have enough space available when it is woken. That is, we push the AIL before we go to sleep. Because we've inserted the log ticket into the queue before we've pushed and gone to sleep, subsequent transactions will wait behind this one. Hence we are guaranteed to have space available when we are woken. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit c626d174cfe38e7f0545d074c299527892cd8c45 Author: Dave Chinner Date: Mon Apr 6 18:42:11 2009 +0200 xfs: prevent unwritten extent conversion from blocking I/O completion Unwritten extent conversion can recurse back into the filesystem due to memory allocation. Memory reclaim requires I/O completions to be processed to allow the callers to make progress. If the I/O completion workqueue thread is doing the recursion, then we have a deadlock situation. Move unwritten extent completion into it's own workqueue so it doesn't block I/O completions for normal delayed allocation or overwrite data. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit 705db3fd4660174a27418bbcb874d209a76044eb Author: Dave Chinner Date: Mon Apr 6 18:40:17 2009 +0200 xfs: fix double free of inode If we fail to initialise the VFS inode in inode_init_always(), it will call ->delete_inode internally resulting in the inode being freed. Hence we need to delay the call to inode_init_always() until after the XFS inode is sufficient set up to handle a call to ->delete_inode, and then if that fails do not touch the inode again at all as it has been freed. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit a6cb767e24b1dbedfcfa8077eab0aa2eab224038 Author: Dave Chinner Date: Mon Apr 6 18:39:27 2009 +0200 xfs: validate log feature fields correctly If the large log sector size feature bit is set in the superblock by accident (say disk corruption), the then fields that are now considered valid are not checked on production kernels. The checks are present as ASSERT statements so cause a panic on a debug kernel. Change this so that the fields are validity checked if the feature bit is set and abort the log mount if the fields do not contain valid values. Reported-by: Eric Sesterhenn Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_aops.c | 38 +++++++++++--------- fs/xfs/linux-2.6/xfs_aops.h | 1 + fs/xfs/linux-2.6/xfs_buf.c | 9 +++++ fs/xfs/linux-2.6/xfs_fs_subr.c | 14 ++++---- fs/xfs/linux-2.6/xfs_lrw.c | 18 +++++++++- fs/xfs/linux-2.6/xfs_sync.c | 78 +++++++++++++++++----------------------- fs/xfs/linux-2.6/xfs_sync.h | 9 +++-- fs/xfs/xfs_iget.c | 23 +++++++----- fs/xfs/xfs_iomap.c | 61 ++++++++----------------------- fs/xfs/xfs_iomap.h | 3 +- fs/xfs/xfs_log.c | 78 +++++++++++++++++++++++++--------------- fs/xfs/xfs_mount.h | 2 +- fs/xfs/xfs_vnodeops.c | 7 ++++ 13 files changed, 180 insertions(+), 161 deletions(-) hooks/post-receive -- XFS development tree From thomas@nchc.org.tw Tue Apr 7 21:06:53 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3826SBb053929 for ; Tue, 7 Apr 2009 21:06:43 -0500 X-ASG-Debug-ID: 1239156347-5d8d01300000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.nchc.org.tw (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C24651F8B95 for ; Tue, 7 Apr 2009 19:05:48 -0700 (PDT) Received: from smtp.nchc.org.tw (smtp.nchc.org.tw [140.110.16.10]) by cuda.sgi.com with ESMTP id fIV8FEi7j4aJYVnr for ; Tue, 07 Apr 2009 19:05:48 -0700 (PDT) Received: from smtp.nchc.org.tw (localhost [127.0.0.1]) by smtp.nchc.org.tw (Postfix) with ESMTP id 2AC1CE7072; Wed, 8 Apr 2009 10:05:46 +0800 (CST) Received: from thomas-desktop.nchc.org.tw (pika017.nchc.org.tw [140.110.61.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.nchc.org.tw (Postfix) with ESMTP id 09E9AE7071; Wed, 8 Apr 2009 10:05:46 +0800 (CST) Date: Wed, 8 Apr 2009 10:05:45 +0800 From: Thomas Tsai To: xfs@oss.sgi.com X-ASG-Orig-Subj: Build xfs 3.0 deb problem Subject: Build xfs 3.0 deb problem Message-Id: <20090408100545.2354f572.thomas@nchc.org.tw> Organization: NCHC X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__8_Apr_2009_10_05_45_+0800_7HkNsx9dhK+G4FLi" X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: ClamAV using ClamSMTP X-Barracuda-Connect: smtp.nchc.org.tw[140.110.16.10] X-Barracuda-Start-Time: 1239156368 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22547 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean --Signature=_Wed__8_Apr_2009_10_05_45_+0800_7HkNsx9dhK+G4FLi Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello xfs, I get the source tarball and easy run Makepkgs debian The build result look fine but lose some library files like libxfs.a.... I really need libxfs-dev to build my package. Please give me a hand, tkx. -- dpkg -L xfslibs-dev /. /lib /usr /usr/lib /usr/lib/libhandle.la /usr/lib/libhandle.a /usr/lib/libdisk.a /usr/share /usr/share/doc /usr/share/doc/xfslibs-dev /usr/share/doc/xfslibs-dev/copyright /usr/share/doc/xfslibs-dev/changelog.Debian.gz /usr/share/man /usr/share/man/man3 /usr/share/man/man3/path_to_handle.3.gz =20 /usr/share/man/man3/xfsctl.3.gz /usr/include /usr/include/xfs /usr/include/xfs/jdm.h /usr/include/xfs/xfs.h /usr/include/xfs/xqm.h /usr/include/xfs/linux.h /usr/include/xfs/handle.h /usr/include/xfs/platform_defs.h /usr/include/xfs/xfs_fs.h /lib/libhandle.la /lib/libhandle.so /lib/libhandle.a /usr/lib/libhandle.so /usr/share/man/man3/attr_list_by_handle.3.gz /usr/share/man/man3/path_to_fshandle.3.gz /usr/share/man/man3/handle_to_fshandle.3.gz ...more man files --=20 Thomas Tsai --Signature=_Wed__8_Apr_2009_10_05_45_+0800_7HkNsx9dhK+G4FLi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJ3AZ8XpcitEY3ms8RApmzAJ4u6SZDy8hi7DHLa8cjFSpczrjQuACcDjmr 3FvWyR4UyagFW55fiFImrT8= =GEcJ -----END PGP SIGNATURE----- --Signature=_Wed__8_Apr_2009_10_05_45_+0800_7HkNsx9dhK+G4FLi-- From MAILER-DAEMON@oss.sgi.com Tue Apr 7 21:24:22 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,MISSING_MIME_HB_SEP autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n382O7wi054705 for ; Tue, 7 Apr 2009 21:24:12 -0500 X-ASG-Debug-ID: 1239157494-2a8501c60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail37.opentransfer.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 28F121401EB9 for ; Tue, 7 Apr 2009 19:24:55 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by cuda.sgi.com with SMTP id nuZVELkwNYFw6CcO for ; Tue, 07 Apr 2009 19:24:55 -0700 (PDT) Received: (qmail 27820 invoked for bounce); 8 Apr 2009 02:23:25 -0000 Date: 8 Apr 2009 02:23:25 -0000 From: MAILER-DAEMON@mail37.opentransfer.com To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1239157405mail37.opentransfer.com10322621" X-ASG-Orig-Subj: failure notice Subject: failure notice X-Barracuda-Connect: mail37.opentransfer.com[76.162.254.37] X-Barracuda-Start-Time: 1239157516 Message-Id: <20090408022455.28F121401EB9@cuda.sgi.com> X-Barracuda-Bayes: INNOCENT GLOBAL 0.4110 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=ANY_BOUNCE_MESSAGE, BOUNCE_MESSAGE, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22548 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 BOUNCE_MESSAGE MTA bounce message 0.00 ANY_BOUNCE_MESSAGE Message is some kind of bounce message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --1239157405mail37.opentransfer.com10322621 Hi. This is the qmail-send program at mail37.opentransfer.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : 205.188.159.216 does not like recipient. Remote host said: 550 MAILBOX NOT FOUND Giving up on 205.188.159.216. --- Enclosed are the original headers of the message. --1239157405mail37.opentransfer.com10322621 Content-Type: message/rfc822 Return-Path: Received: (qmail 27772 invoked by uid 399); 8 Apr 2009 02:23:23 -0000 Received: from unknown (HELO oss.sgi.com) (58.187.2.244) by mail37.opentransfer.com with SMTP; 8 Apr 2009 02:23:23 -0000 From: xfs@oss.sgi.com To: more@aol.com Subject: Mail System Error - Returned Mail Date: Wed, 8 Apr 2009 09:23:59 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_7B33D160.99227518" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 (Body supressed) ------=_NextPart_000_0008_7B33D160.99227518-- --1239157405mail37.opentransfer.com10322621-- From nscott@aconex.com Tue Apr 7 21:47:11 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n382kpFQ055664 for ; Tue, 7 Apr 2009 21:47:01 -0500 X-ASG-Debug-ID: 1239158790-5d8f01d20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice2.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AC21B1F8CE7 for ; Tue, 7 Apr 2009 19:46:31 -0700 (PDT) Received: from postoffice2.aconex.com (mail.aconex.com [203.89.202.182]) by cuda.sgi.com with ESMTP id EEKiAL6xmUSCMhTl for ; Tue, 07 Apr 2009 19:46:31 -0700 (PDT) Received: from postoffice.aconex.com (localhost [127.0.0.1]) by postoffice2.aconex.com (Spam Firewall) with ESMTP id C6A8E4418E0; Wed, 8 Apr 2009 12:46:28 +1000 (EST) Received: from postoffice.aconex.com (postoffice.yarra.acx [192.168.102.1]) by postoffice2.aconex.com with ESMTP id ceq4vlDNbNP4OzWo; Wed, 08 Apr 2009 12:46:28 +1000 (EST) Received: from gatekeeper.aconex.com (unknown [192.168.102.10]) by postoffice.aconex.com (Postfix) with ESMTP id B819B92C2C4; Wed, 8 Apr 2009 12:46:28 +1000 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by gatekeeper.aconex.com (Postfix) with ESMTP id C9E714FD99; Wed, 8 Apr 2009 12:46:41 +1000 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: amavisd-new at gatekeeper.yarra.acx Received: from gatekeeper.aconex.com ([127.0.0.1]) by localhost (gatekeeper.aconex.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OaVaEaW6llZ; Wed, 8 Apr 2009 12:46:37 +1000 (EST) Received: from mail-au.aconex.com (mail-au.aconex.com [192.168.102.12]) by gatekeeper.aconex.com (Postfix) with ESMTP id 1E0FA4FDA1; Wed, 8 Apr 2009 12:46:37 +1000 (EST) Date: Wed, 8 Apr 2009 12:46:24 +1000 (EST) From: Nathan Scott To: Thomas Tsai Cc: xfs@oss.sgi.com Message-ID: <732332763.3161411239158784001.JavaMail.root@mail-au.aconex.com> In-Reply-To: <20090408100545.2354f572.thomas@nchc.org.tw> X-ASG-Orig-Subj: Re: Build xfs 3.0 deb problem Subject: Re: Build xfs 3.0 deb problem MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [203.89.192.141] X-Mailer: Zimbra 5.0.13_GA_2791.RHEL5_64 (ZimbraWebClient - [unknown] (Linux)/5.0.13_GA_2791.RHEL5_64) X-Barracuda-Connect: mail.aconex.com[203.89.202.182] X-Barracuda-Start-Time: 1239158791 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0038 1.0000 -1.9964 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.00 X-Barracuda-Spam-Status: No, SCORE=-2.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22549 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean ----- "Thomas Tsai" wrote: > Hello xfs, > > I get the source tarball and easy run Makepkgs debian > The build result look fine but lose some library files like > libxfs.a.... > > I really need libxfs-dev to build my package. > Please give me a hand, tkx. What is your package, and what libxfs calls does it make? libxfs.a was never intended as a published API, and nothing outside xfsprogs should be using it. cheers. -- Nathan From thomas@nchc.org.tw Tue Apr 7 22:57:30 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_83 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n383v3Db059095 for ; Tue, 7 Apr 2009 22:57:20 -0500 X-ASG-Debug-ID: 1239163092-2fde03940000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.nchc.org.tw (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 417D21402412 for ; Tue, 7 Apr 2009 20:58:12 -0700 (PDT) Received: from smtp.nchc.org.tw (smtp.nchc.org.tw [140.110.16.10]) by cuda.sgi.com with ESMTP id NmSwMoECdPKchJoC for ; Tue, 07 Apr 2009 20:58:12 -0700 (PDT) Received: from smtp.nchc.org.tw (localhost [127.0.0.1]) by smtp.nchc.org.tw (Postfix) with ESMTP id 60AA1E7093; Wed, 8 Apr 2009 11:56:42 +0800 (CST) Received: from thomas-desktop.nchc.org.tw (pika017.nchc.org.tw [140.110.61.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.nchc.org.tw (Postfix) with ESMTP id 3EDECE7090; Wed, 8 Apr 2009 11:56:42 +0800 (CST) Date: Wed, 8 Apr 2009 11:56:48 +0800 From: Thomas Tsai To: Nathan Scott Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Build xfs 3.0 deb problem Subject: Re: Build xfs 3.0 deb problem Message-Id: <20090408115648.efaee933.thomas@nchc.org.tw> In-Reply-To: <732332763.3161411239158784001.JavaMail.root@mail-au.aconex.com> References: <20090408100545.2354f572.thomas@nchc.org.tw> <732332763.3161411239158784001.JavaMail.root@mail-au.aconex.com> Organization: NCHC X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__8_Apr_2009_11_56_48_+0800_Gfi2XFHPDXIwPYcd" X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: ClamAV using ClamSMTP X-Barracuda-Connect: smtp.nchc.org.tw[140.110.16.10] X-Barracuda-Start-Time: 1239163093 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22554 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean --Signature=_Wed__8_Apr_2009_11_56_48_+0800_Gfi2XFHPDXIwPYcd Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable tkx for reply soon. My package name is partclone(partclone.org), like partimage, but I used lib= xfs to check bitmap/super block and backup xfs partition. It's GPL licensed. We need GPL tool to backup XFS partition. The partimage can do that but get= some problems(not based on the xfs library). The xfs library you maintained well, and it's why I use xfslibs-dev's liarb= ry to write backup tool, "partclone.xfs" . so..., may I use xfslibs-dev to build partclone? or stop it and remove? tkx. Thomas On Wed, 8 Apr 2009 12:46:24 +1000 (EST) Nathan Scott wrote: >=20 > ----- "Thomas Tsai" wrote: >=20 > > Hello xfs, > >=20 > > I get the source tarball and easy run Makepkgs debian > > The build result look fine but lose some library files like > > libxfs.a.... > >=20 > > I really need libxfs-dev to build my package. > > Please give me a hand, tkx. >=20 > What is your package, and what libxfs calls does it make? > libxfs.a was never intended as a published API, and nothing > outside xfsprogs should be using it. >=20 > cheers. >=20 > --=20 > Nathan --=20 Thomas Tsai --Signature=_Wed__8_Apr_2009_11_56_48_+0800_Gfi2XFHPDXIwPYcd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJ3CCBXpcitEY3ms8RAiPaAKCFvHXN8YHFHa6++Wk9ezydG3wndACg3/H6 i7vm09poO//2YAp1iAOBd6g= =XDKj -----END PGP SIGNATURE----- --Signature=_Wed__8_Apr_2009_11_56_48_+0800_Gfi2XFHPDXIwPYcd-- From nscott@aconex.com Tue Apr 7 23:11:01 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_83 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n384AeRn059783 for ; Tue, 7 Apr 2009 23:10:50 -0500 X-ASG-Debug-ID: 1239163908-2fa403b50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice2.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E14B614024B4 for ; Tue, 7 Apr 2009 21:11:49 -0700 (PDT) Received: from postoffice2.aconex.com (mail.aconex.com [203.89.202.182]) by cuda.sgi.com with ESMTP id 82FdMytUfx5QSJf0 for ; Tue, 07 Apr 2009 21:11:49 -0700 (PDT) Received: from postoffice.aconex.com (localhost [127.0.0.1]) by postoffice2.aconex.com (Spam Firewall) with ESMTP id 6AA7943C29C; Wed, 8 Apr 2009 14:10:18 +1000 (EST) Received: from postoffice.aconex.com (postoffice.yarra.acx [192.168.102.1]) by postoffice2.aconex.com with ESMTP id QIq1EtqpJdmg9BAc; Wed, 08 Apr 2009 14:10:18 +1000 (EST) Received: from gatekeeper.aconex.com (unknown [192.168.102.10]) by postoffice.aconex.com (Postfix) with ESMTP id 4D43892C2F8; Wed, 8 Apr 2009 14:10:18 +1000 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by gatekeeper.aconex.com (Postfix) with ESMTP id D00164FDA0; Wed, 8 Apr 2009 14:10:31 +1000 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: amavisd-new at gatekeeper.yarra.acx Received: from gatekeeper.aconex.com ([127.0.0.1]) by localhost (gatekeeper.aconex.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kq0krqWZ6Gh; Wed, 8 Apr 2009 14:10:27 +1000 (EST) Received: from mail-au.aconex.com (mail-au.aconex.com [192.168.102.12]) by gatekeeper.aconex.com (Postfix) with ESMTP id A859D4FD99; Wed, 8 Apr 2009 14:10:27 +1000 (EST) Date: Wed, 8 Apr 2009 14:10:14 +1000 (EST) From: Nathan Scott To: Thomas Tsai Cc: xfs@oss.sgi.com Message-ID: <430737146.3196421239163814099.JavaMail.root@mail-au.aconex.com> In-Reply-To: <20090408115648.efaee933.thomas@nchc.org.tw> X-ASG-Orig-Subj: Re: Build xfs 3.0 deb problem Subject: Re: Build xfs 3.0 deb problem MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [203.89.192.141] X-Mailer: Zimbra 5.0.13_GA_2791.RHEL5_64 (ZimbraWebClient - [unknown] (Linux)/5.0.13_GA_2791.RHEL5_64) X-Barracuda-Connect: mail.aconex.com[203.89.202.182] X-Barracuda-Start-Time: 1239163909 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0013 1.0000 -2.0127 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22556 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean ----- "Thomas Tsai" wrote: > tkx for reply soon. > > My package name is partclone(partclone.org), like partimage, but I Sounds like xfs_copy(8)? > used libxfs to check bitmap/super block and backup xfs partition. It's > GPL licensed. > > We need GPL tool to backup XFS partition. The partimage can do that > but get some problems(not based on the xfs library). > The xfs library you maintained well, and it's why I use xfslibs-dev's > liarbry to write backup tool, "partclone.xfs" . Can this use xfs_copy directly? > so..., may I use xfslibs-dev to build partclone? > or stop it and remove? Its historically proved disasterous having ondisk filesystem knowledge in tools (e.g. grub) ... and restricts what filesystem developers can do in terms of extending their ondisk formats, somewhat. It'd be alot better if you could use a tool shipped by the XFS folk rather than one you write yourself (libxfs is a very error prone interface modelled on kernel code, it wasn't designed as a general purpose API). cheers. -- Nathan From felixb@sgi.com Tue Apr 7 23:48:25 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n384m5XM061911 for ; Tue, 7 Apr 2009 23:48:15 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id 6D2BD8F8068 for ; Tue, 7 Apr 2009 21:47:46 -0700 (PDT) Received: from [IPv6???1] (sshgate.corp.sgi.com [198.149.20.12]) by estes.americas.sgi.com (Postfix) with ESMTP id 762EA70001C8; Tue, 7 Apr 2009 23:45:35 -0500 (CDT) Cc: Dave Chinner , xfs@oss.sgi.com Message-Id: <09C35383-EA8E-4EC2-A067-B3FA327AFF4C@sgi.com> From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090406222831.GA12016@infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [PATCH 0/2, RESEND] [XFS] a couple of fixes Date: Tue, 7 Apr 2009 23:45:33 -0500 References: <1237116342-25701-1-git-send-email-david@fromorbit.com> <20090406222831.GA12016@infradead.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Apr 6, 2009, at 5:28 PM, Christoph Hellwig wrote: > I've sucked these patches into my tree after reviewin and QAing them. > Felix, can you pull this and send it to Linus for 2.6.30? > > git://git.kernel.org/pub/scm/fs/xfs/xfs.git I did pull from your tree, and pushed to oss. But I stopped short from pushing the for-linus branch, and generating the pull request, as I'm again seeing the 'merge' commits. I'll try to sort it out tomorrow. Felix From lizf@cn.fujitsu.com Wed Apr 8 02:08:29 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,J_CHICKENPOX_73, J_CHICKENPOX_74 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n38789wl072317 for ; Wed, 8 Apr 2009 02:08:19 -0500 X-ASG-Debug-ID: 1239174447-665f01680000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from song.cn.fujitsu.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7F4B21F91F3 for ; Wed, 8 Apr 2009 00:07:28 -0700 (PDT) Received: from song.cn.fujitsu.com (cn.fujitsu.com [222.73.24.84]) by cuda.sgi.com with ESMTP id PO5FDKmsJRUf96te for ; Wed, 08 Apr 2009 00:07:28 -0700 (PDT) Received: from tang.cn.fujitsu.com (tang.cn.fujitsu.com [10.167.250.3]) by song.cn.fujitsu.com (Postfix) with ESMTP id 4ABA717008E; Wed, 8 Apr 2009 15:52:01 +0800 (CST) Received: from fnst.cn.fujitsu.com (localhost.localdomain [127.0.0.1]) by tang.cn.fujitsu.com (8.13.1/8.13.1) with ESMTP id n387BKKO028942; Wed, 8 Apr 2009 15:11:20 +0800 Received: from localhost.localdomain (unknown [10.167.141.140]) by fnst.cn.fujitsu.com (Postfix) with ESMTPA id 784E2290E10; Wed, 8 Apr 2009 15:12:31 +0800 (CST) Message-ID: <49DC4D54.3020001@cn.fujitsu.com> Date: Wed, 08 Apr 2009 15:08:04 +0800 From: Li Zefan User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: felixb@sgi.com CC: LKML , Andrew Morton , xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 4/6] xfs: use memdup_user() Subject: [PATCH 4/6] xfs: use memdup_user() References: <49DC4CC0.9050805@cn.fujitsu.com> In-Reply-To: <49DC4CC0.9050805@cn.fujitsu.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: cn.fujitsu.com[222.73.24.84] X-Barracuda-Start-Time: 1239174469 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.32 X-Barracuda-Spam-Status: No, SCORE=-1.32 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, BSF_SC0_MJ615 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22567 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_MJ615 Custom Rule MJ615 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Remove open-coded memdup_user() Signed-off-by: Li Zefan --- fs/xfs/linux-2.6/xfs_ioctl.c | 23 +++++++---------------- fs/xfs/linux-2.6/xfs_ioctl32.c | 12 ++++-------- 2 files changed, 11 insertions(+), 24 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_ioctl.c b/fs/xfs/linux-2.6/xfs_ioctl.c index d0b4994..34eaab6 100644 --- a/fs/xfs/linux-2.6/xfs_ioctl.c +++ b/fs/xfs/linux-2.6/xfs_ioctl.c @@ -489,17 +489,12 @@ xfs_attrmulti_attr_set( if (len > XATTR_SIZE_MAX) return EINVAL; - kbuf = kmalloc(len, GFP_KERNEL); - if (!kbuf) - return ENOMEM; - - if (copy_from_user(kbuf, ubuf, len)) - goto out_kfree; + kbuf = memdup_user(ubuf, len); + if (IS_ERR(kbuf)) + return PTR_ERR(kbuf); error = xfs_attr_set(XFS_I(inode), name, kbuf, len, flags); - out_kfree: - kfree(kbuf); return error; } @@ -540,20 +535,16 @@ xfs_attrmulti_by_handle( if (!size || size > 16 * PAGE_SIZE) goto out_dput; - error = ENOMEM; - ops = kmalloc(size, GFP_KERNEL); - if (!ops) + ops = memdup_user(am_hreq.ops, size); + if (IS_ERR(ops)) { + error = PTR_ERR(ops); goto out_dput; - - error = EFAULT; - if (copy_from_user(ops, am_hreq.ops, size)) - goto out_kfree_ops; + } attr_name = kmalloc(MAXNAMELEN, GFP_KERNEL); if (!attr_name) goto out_kfree_ops; - error = 0; for (i = 0; i < am_hreq.opcount; i++) { ops[i].am_error = strncpy_from_user(attr_name, diff --git a/fs/xfs/linux-2.6/xfs_ioctl32.c b/fs/xfs/linux-2.6/xfs_ioctl32.c index c70c4e3..0882d16 100644 --- a/fs/xfs/linux-2.6/xfs_ioctl32.c +++ b/fs/xfs/linux-2.6/xfs_ioctl32.c @@ -427,20 +427,16 @@ xfs_compat_attrmulti_by_handle( if (!size || size > 16 * PAGE_SIZE) goto out_dput; - error = ENOMEM; - ops = kmalloc(size, GFP_KERNEL); - if (!ops) + ops = memdup_user(compat_ptr(am_hreq.ops), size); + if (IS_ERR(ops)) { + error = PTR_ERR(ops); goto out_dput; - - error = EFAULT; - if (copy_from_user(ops, compat_ptr(am_hreq.ops), size)) - goto out_kfree_ops; + } attr_name = kmalloc(MAXNAMELEN, GFP_KERNEL); if (!attr_name) goto out_kfree_ops; - error = 0; for (i = 0; i < am_hreq.opcount; i++) { ops[i].am_error = strncpy_from_user(attr_name, -- 1.5.4.rc3 From MAILER-DAEMON@oss.sgi.com Wed Apr 8 04:32:35 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=ANY_BOUNCE_MESSAGE,AWL, BAYES_00,URIBL_PH_SURBL,VBOUNCE_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n389WKMb080545 for ; Wed, 8 Apr 2009 04:32:25 -0500 X-ASG-Debug-ID: 1239183100-379101040000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from omr-m25.mx.aol.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CFCF11F96DC for ; Wed, 8 Apr 2009 02:31:40 -0700 (PDT) Received: from omr-m25.mx.aol.com (omr-m25.mx.aol.com [64.12.136.133]) by cuda.sgi.com with ESMTP id JRZ2xfBUU80fxVEG for ; Wed, 08 Apr 2009 02:31:40 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from rly-de10.mx.aol.com (rly-de10.mx.aol.com [205.188.249.86]) by omr-m25.mx.aol.com (v117.7) with ESMTP id MAILOMRM253-7e1449dc6ef6147; Wed, 08 Apr 2009 05:31:34 -0400 Received: from localhost (localhost) by rly-de10.mx.aol.com (8.14.1/8.14.1) id n389VT48016275; Wed, 8 Apr 2009 05:31:34 -0400 Date: Wed, 8 Apr 2009 05:31:34 -0400 From: Mail Delivery Subsystem Message-Id: <200904080931.n389VT48016275@rly-de10.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="n389VT48016275.1239183094/rly-de10.mx.aol.com" X-ASG-Orig-Subj: Returned mail: see transcript for details Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-AOL-INRLY: ctb-mesg-1-1.saix.net [196.25.240.79] rly-de10 X-AOL-IP: 205.188.249.86 X-Barracuda-Connect: omr-m25.mx.aol.com[64.12.136.133] X-Barracuda-Start-Time: 1239183120 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This is a MIME-encapsulated message --n389VT48016275.1239183094/rly-de10.mx.aol.com The original message was received at Wed, 8 Apr 2009 05:31:14 -0400 from ctb-mesg-1-1.saix.net [196.25.240.79] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- (reason: 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent.) ----- Transcript of session follows ----- ... while talking to air-de01.mail.aol.com.: >>> DATA <<< 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. 554 5.0.0 Service unavailable --n389VT48016275.1239183094/rly-de10.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-de10.mx.aol.com Arrival-Date: Wed, 8 Apr 2009 05:31:14 -0400 Final-Recipient: RFC822; ksamra@aol.com Action: failed Status: 5.0.0 Remote-MTA: DNS; air-de01.mail.aol.com Diagnostic-Code: SMTP; 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. Last-Attempt-Date: Wed, 8 Apr 2009 05:31:34 -0400 --n389VT48016275.1239183094/rly-de10.mx.aol.com Content-Type: text/rfc822-headers Received: from ctb-mesg-1-1.saix.net (ctb-mesg-1-1.saix.net [196.25.240.79]) by rly-de10.mx.aol.com (v123.4) with ESMTP id MAILRELAYINDE101-50649dc6ee0275; Wed, 08 Apr 2009 05:31:13 -0400 Received: from oss.sgi.com (dsl-145-16-113.telkomadsl.co.za [165.145.16.113]) by ctb-mesg-1-1.saix.net (Postfix) with ESMTP id 250A62A222 for ; Wed, 8 Apr 2009 11:34:45 +0200 (SAST) From: xfs@oss.sgi.com To: ksamra@aol.com Subject: Returned mail: see transcript for details Date: Wed, 8 Apr 2009 11:24:17 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_F8720032.0217B85C" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20090408093447.250A62A222@ctb-mesg-1-1.saix.net> X-AOL-IP: 196.25.240.79 X-AOL-SCOLL-SCORE:0:2:295954496:93952408 X-AOL-SCOLL-URL_COUNT:0 --n389VT48016275.1239183094/rly-de10.mx.aol.com-- From BATV+65849a2756afd0739cf0+2054+infradead.org+hch@bombadil.srs.infradead.org Wed Apr 8 08:24:00 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_73 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n38DNYZx091757 for ; Wed, 8 Apr 2009 08:23:50 -0500 X-ASG-Debug-ID: 1239196974-787800e90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3FB2A1CA593A; Wed, 8 Apr 2009 06:22:54 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 98JwgwWrxRCvk863; Wed, 08 Apr 2009 06:22:54 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LrXjy-0006Mi-8P; Wed, 08 Apr 2009 13:22:54 +0000 Date: Wed, 8 Apr 2009 09:22:54 -0400 From: Christoph Hellwig To: Li Zefan Cc: felixb@sgi.com, Andrew Morton , LKML , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 4/6] xfs: use memdup_user() Subject: Re: [PATCH 4/6] xfs: use memdup_user() Message-ID: <20090408132254.GA5957@infradead.org> References: <49DC4CC0.9050805@cn.fujitsu.com> <49DC4D54.3020001@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49DC4D54.3020001@cn.fujitsu.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239196995 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Apr 08, 2009 at 03:08:04PM +0800, Li Zefan wrote: > Remove open-coded memdup_user() > > Signed-off-by: Li Zefan > --- > fs/xfs/linux-2.6/xfs_ioctl.c | 23 +++++++---------------- > fs/xfs/linux-2.6/xfs_ioctl32.c | 12 ++++-------- > 2 files changed, 11 insertions(+), 24 deletions(-) > > diff --git a/fs/xfs/linux-2.6/xfs_ioctl.c b/fs/xfs/linux-2.6/xfs_ioctl.c > index d0b4994..34eaab6 100644 > --- a/fs/xfs/linux-2.6/xfs_ioctl.c > +++ b/fs/xfs/linux-2.6/xfs_ioctl.c > @@ -489,17 +489,12 @@ xfs_attrmulti_attr_set( > if (len > XATTR_SIZE_MAX) > return EINVAL; > > - kbuf = kmalloc(len, GFP_KERNEL); > - if (!kbuf) > - return ENOMEM; > - > - if (copy_from_user(kbuf, ubuf, len)) > - goto out_kfree; > + kbuf = memdup_user(ubuf, len); > + if (IS_ERR(kbuf)) > + return PTR_ERR(kbuf); wouldn't NULL be a better error return for this kind of interface, matching kmalloc? Otherwise the patch looks good to me. Reviewed-by: Christoph Hellwig From BATV+65849a2756afd0739cf0+2054+infradead.org+hch@bombadil.srs.infradead.org Wed Apr 8 08:34:35 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n38DYAVm092220 for ; Wed, 8 Apr 2009 08:34:25 -0500 X-ASG-Debug-ID: 1239197630-7858011f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 22E8F1CA4ADB; Wed, 8 Apr 2009 06:33:51 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id LMYmZWmAaJL4W71A; Wed, 08 Apr 2009 06:33:51 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LrXuY-000579-QT; Wed, 08 Apr 2009 13:33:50 +0000 Date: Wed, 8 Apr 2009 09:33:50 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/2, RESEND] [XFS] a couple of fixes Subject: Re: [PATCH 0/2, RESEND] [XFS] a couple of fixes Message-ID: <20090408133350.GA12013@infradead.org> References: <1237116342-25701-1-git-send-email-david@fromorbit.com> <20090406222831.GA12016@infradead.org> <09C35383-EA8E-4EC2-A067-B3FA327AFF4C@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09C35383-EA8E-4EC2-A067-B3FA327AFF4C@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239197631 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Apr 07, 2009 at 11:45:33PM -0500, Felix Blyakher wrote: > > On Apr 6, 2009, at 5:28 PM, Christoph Hellwig wrote: > >> I've sucked these patches into my tree after reviewin and QAing them. >> Felix, can you pull this and send it to Linus for 2.6.30? >> >> git://git.kernel.org/pub/scm/fs/xfs/xfs.git > > I did pull from your tree, and pushed to oss. > But I stopped short from pushing the for-linus branch, > and generating the pull request, as I'm again seeing > the 'merge' commits. I'll try to sort it out tomorrow. Note that you will always see some merge commits of both merged trees touched the same files. What Linus objected was the large amount of merge commits. The way to bring them down is to simply do less merges, just stay on the same mainline level for a longer time and only merge with mainline short before you prepare a pull or when you really need it due to conflicting changes making it in. From rdreier@cisco.com Wed Apr 8 12:33:39 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n38HXJKt107706 for ; Wed, 8 Apr 2009 12:33:29 -0500 X-ASG-Debug-ID: 1239212050-1d4600a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sj-iport-3.cisco.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D65C2140656D for ; Wed, 8 Apr 2009 10:34:10 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by cuda.sgi.com with ESMTP id ZSEDhQXTUjirZgm0 for ; Wed, 08 Apr 2009 10:34:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,345,1235952000"; d="scan'208";a="151695606" Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2009 17:31:27 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n38HVQLd032728; Thu, 9 Apr 2009 03:31:26 +1000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n38HVPZL010988; Wed, 8 Apr 2009 17:31:25 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 10:31:25 -0700 Received: from roland-conroe ([10.33.42.9]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 10:31:25 -0700 Received: by roland-conroe (Postfix, from userid 33217) id 3F148E7207; Wed, 8 Apr 2009 10:31:25 -0700 (PDT) From: Roland Dreier To: Christoph Hellwig Cc: Li Zefan , felixb@sgi.com, Andrew Morton , LKML , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 4/6] xfs: use memdup_user() Subject: Re: [PATCH 4/6] xfs: use memdup_user() References: <49DC4CC0.9050805@cn.fujitsu.com> <49DC4D54.3020001@cn.fujitsu.com> <20090408132254.GA5957@infradead.org> X-Message-Flag: Warning: May contain useful information Date: Wed, 08 Apr 2009 10:31:25 -0700 In-Reply-To: <20090408132254.GA5957@infradead.org> (Christoph Hellwig's message of "Wed, 8 Apr 2009 09:22:54 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 08 Apr 2009 17:31:25.0424 (UTC) FILETIME=[D790C700:01C9B86F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=301; t=1239211886; x=1240075886; c=relaxed/simple; s=syddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdreier@cisco.com; z=From:=20Roland=20Dreier=20 |Subject:=20Re=3A=20[PATCH=204/6]=20xfs=3A=20use=20memdup_u ser() |Sender:=20; bh=D9O1kDG8ifNkpuUOdMD/LKAg7MKrXL3IQfI1o3uCciI=; b=wV4bTr0y1fTAUlhuM1UM0U1erQTGUUV/7CgPQrRnF+c/avWBHSKTD4scA+ OrpIiZE3yei0lt2fSxwi/NYuh027pWxv+q/qsZWqne1CGbsAh6y7oMGhaDsK 6LtkD55uAcKWTJlfKHATyQUzoNkphUbZJxAvxixh0CS/4ece9/gag=; Authentication-Results: syd-dkim-1; header.From=rdreier@cisco.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; ); X-Barracuda-Connect: sj-iport-3.cisco.com[171.71.176.72] X-Barracuda-Start-Time: 1239212071 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22608 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > wouldn't NULL be a better error return for this kind of interface, > matching kmalloc? I guess returning an error code from memdup_user() lets callers distinguish between ENOMEM and EFAULT. Not sure if that's important or not but there probably are at least some sites that care. - R. From felixb@sgi.com Wed Apr 8 13:58:32 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n38IwCL2112117 for ; Wed, 8 Apr 2009 13:58:22 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay2.corp.sgi.com (Postfix) with ESMTP id 0F1BD3040C0 for ; Wed, 8 Apr 2009 11:57:53 -0700 (PDT) Received: from eagdhcp-232-161.americas.sgi.com (eagdhcp-232-161.americas.sgi.com [128.162.232.161]) by estes.americas.sgi.com (Postfix) with ESMTP id ED4A87000103; Wed, 8 Apr 2009 13:47:08 -0500 (CDT) Cc: xfs-oss Message-Id: <578FD09C-C517-48C8-9299-7EB805D8337B@sgi.com> From: Felix Blyakher To: Eric Sandeen In-Reply-To: <49CE3A1A.9020103@sandeen.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: xfstests license clarification? Date: Wed, 8 Apr 2009 13:47:08 -0500 References: <49CE3A1A.9020103@sandeen.net> X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mar 28, 2009, at 9:54 AM, Eric Sandeen wrote: > Since most of the scripts themselves in xfstests make no mention of > redistribution, and only say "copyright sgi, all rights reserved" etc: > > #----------------------------------------------------------------------- > # Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved. > #----------------------------------------------------------------------- > > do we need to do anything in terms of making this look more like Free > Software (assuming that's the intent?) Yes, it was intent. And it's OK to add the GPL license blob there. Can't speak for non sgi files. Felix > It might be a rats-nest, there are a several testcases in src/ gleaned > from mailing lists & bugs with little or no attribution; OTOH maybe > this > stuff is trivial enough that it doesn't warrant copyright, I dunno. > > Is it worth trying to clarify the license on the collection, or is > this > just a can of worms? > > -Eric > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From felixb@sgi.com Wed Apr 8 15:34:40 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_73 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n38KYKpR126261 for ; Wed, 8 Apr 2009 15:34:30 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay3.corp.sgi.com (Postfix) with ESMTP id 3433DAC001 for ; Wed, 8 Apr 2009 13:34:01 -0700 (PDT) Received: from eagdhcp-232-161.americas.sgi.com (eagdhcp-232-161.americas.sgi.com [128.162.232.161]) by estes.americas.sgi.com (Postfix) with ESMTP id 0609A7000103; Wed, 8 Apr 2009 15:06:41 -0500 (CDT) Cc: Li Zefan , Andrew Morton , LKML , xfs@oss.sgi.com Message-Id: From: Felix Blyakher To: Christoph Hellwig In-Reply-To: <20090408132254.GA5957@infradead.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: [PATCH 4/6] xfs: use memdup_user() Date: Wed, 8 Apr 2009 15:06:40 -0500 References: <49DC4CC0.9050805@cn.fujitsu.com> <49DC4D54.3020001@cn.fujitsu.com> <20090408132254.GA5957@infradead.org> X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Apr 8, 2009, at 8:22 AM, Christoph Hellwig wrote: > On Wed, Apr 08, 2009 at 03:08:04PM +0800, Li Zefan wrote: >> Remove open-coded memdup_user() >> >> Signed-off-by: Li Zefan >> --- >> fs/xfs/linux-2.6/xfs_ioctl.c | 23 +++++++---------------- >> fs/xfs/linux-2.6/xfs_ioctl32.c | 12 ++++-------- >> 2 files changed, 11 insertions(+), 24 deletions(-) >> >> diff --git a/fs/xfs/linux-2.6/xfs_ioctl.c b/fs/xfs/linux-2.6/ >> xfs_ioctl.c >> index d0b4994..34eaab6 100644 >> --- a/fs/xfs/linux-2.6/xfs_ioctl.c >> +++ b/fs/xfs/linux-2.6/xfs_ioctl.c >> @@ -489,17 +489,12 @@ xfs_attrmulti_attr_set( >> if (len > XATTR_SIZE_MAX) >> return EINVAL; >> >> - kbuf = kmalloc(len, GFP_KERNEL); >> - if (!kbuf) >> - return ENOMEM; >> - >> - if (copy_from_user(kbuf, ubuf, len)) >> - goto out_kfree; >> + kbuf = memdup_user(ubuf, len); >> + if (IS_ERR(kbuf)) >> + return PTR_ERR(kbuf); > > wouldn't NULL be a better error return for this kind of interface, > matching kmalloc? > > > Otherwise the patch looks good to me. > > Reviewed-by: Christoph Hellwig Looks good to me too. Reviewed-by: Felix Blyakher p.s. Replying to reply as I couldn't find the original post. From lizf@cn.fujitsu.com Wed Apr 8 19:43:52 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n390hW1F140961 for ; Wed, 8 Apr 2009 19:43:42 -0500 X-ASG-Debug-ID: 1239237771-470701790000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from song.cn.fujitsu.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AD70D1CA8BDE for ; Wed, 8 Apr 2009 17:42:51 -0700 (PDT) Received: from song.cn.fujitsu.com (cn.fujitsu.com [222.73.24.84]) by cuda.sgi.com with ESMTP id oWECQrkUtJ4zB3TZ for ; Wed, 08 Apr 2009 17:42:51 -0700 (PDT) Received: from tang.cn.fujitsu.com (tang.cn.fujitsu.com [10.167.250.3]) by song.cn.fujitsu.com (Postfix) with ESMTP id 9B074170130; Thu, 9 Apr 2009 09:28:00 +0800 (CST) Received: from fnst.cn.fujitsu.com (localhost.localdomain [127.0.0.1]) by tang.cn.fujitsu.com (8.13.1/8.13.1) with ESMTP id n390hMXl011735; Thu, 9 Apr 2009 08:43:22 +0800 Received: from localhost.localdomain (unknown [10.167.141.140]) by fnst.cn.fujitsu.com (Postfix) with ESMTPA id A5179292C8E; Thu, 9 Apr 2009 08:48:04 +0800 (CST) Message-ID: <49DD44B5.9040702@cn.fujitsu.com> Date: Thu, 09 Apr 2009 08:43:33 +0800 From: Li Zefan User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Roland Dreier CC: Christoph Hellwig , felixb@sgi.com, Andrew Morton , LKML , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 4/6] xfs: use memdup_user() Subject: Re: [PATCH 4/6] xfs: use memdup_user() References: <49DC4CC0.9050805@cn.fujitsu.com> <49DC4D54.3020001@cn.fujitsu.com> <20090408132254.GA5957@infradead.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: cn.fujitsu.com[222.73.24.84] X-Barracuda-Start-Time: 1239237792 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22636 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Roland Dreier wrote: > > wouldn't NULL be a better error return for this kind of interface, > > matching kmalloc? > > I guess returning an error code from memdup_user() lets callers > distinguish between ENOMEM and EFAULT. Not sure if that's important or > not but there probably are at least some sites that care. > Right, and this API is simlilar to strndup_user(). From vegard.nossum@gmail.com Thu Apr 9 09:08:22 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n39E81EQ248006 for ; Thu, 9 Apr 2009 09:08:12 -0500 X-ASG-Debug-ID: 1239286061-61b100be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-fx0-f177.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4B9DB200554 for ; Thu, 9 Apr 2009 07:07:41 -0700 (PDT) Received: from mail-fx0-f177.google.com (mail-fx0-f177.google.com [209.85.220.177]) by cuda.sgi.com with ESMTP id bkVMeGeAqQfD8Ju0 for ; Thu, 09 Apr 2009 07:07:41 -0700 (PDT) Received: by fxm25 with SMTP id 25so629149fxm.20 for ; Thu, 09 Apr 2009 07:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Qj2473DTmZQK6hUpzQlYjnpTFWHdzpP0LzoiPUQRrXs=; b=DYss9nYD8Hq2ee72BgW05Gqe1hycKai2vz7B3u1cVzWXktKVmmcyJfdPU5ryCId6T4 hxsBUT0DIvmNJPptFTN6kqFtgvUwQVeRtDiJoOQD4epxm20o11MvSqfvIoG+8YtxsYir dDe/rZHU24z93oGdPysnbKOatMIh6iZEr2IcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W5HSKjAjQOhPSJISml9DvtpAtXTXgCX/Tfu6E44DPRyjqAJfclRjZ77t51+/Nr2B6Z 1UUoFi+akrYJO+46JPYq97bCc1RB1MVYfDnMNW2gpcPuBs53f/Gd59qG5nLWOKnCpkTt Ed/Ssi8aMnP/4+cyLmfpfAttQgSXsB8RAGJQ8= MIME-Version: 1.0 Received: by 10.204.59.65 with SMTP id k1mr2231978bkh.174.1239286060639; Thu, 09 Apr 2009 07:07:40 -0700 (PDT) In-Reply-To: <200903301936.08477.cova@ferrara.linux.it> References: <200903301936.08477.cova@ferrara.linux.it> Date: Thu, 9 Apr 2009 16:07:40 +0200 Message-ID: <19f34abd0904090707v7eb8b677gbda42595aa04a090@mail.gmail.com> X-ASG-Orig-Subj: Re: [BUG] spinlock lockup on CPU#0 Subject: Re: [BUG] spinlock lockup on CPU#0 From: Vegard Nossum To: Fabio Coatti Cc: Felix Blyakher , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Content-Type: multipart/mixed; boundary=001636c5b0546b679804671fc55a X-Barracuda-Connect: mail-fx0-f177.google.com[209.85.220.177] X-Barracuda-Start-Time: 1239286062 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22690 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --001636c5b0546b679804671fc55a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2009/3/30 Fabio Coatti : > Hi all, I've got the following BUG: report on one of our servers running > 2.6.28.8; some background: > we are seeing several lockups in db (mysql) servers that shows up as a su= dden > load increase and then, very quickly, the server freezes. It happens in a > random way, sometimes after weeks, sometimes very quickly after a system > reboot. Trying to discover the problem we installed latest (at the time o= f > test) 2.6.28.X kernel and loaded it with some high disk I/O operations (f= ind, > dd, rsync and so on). > We have been able =C2=A0to crash a server with these tests; unfortunately= we have > been able to capture only a remote screen snapshot so I copied by hand > (hopefully without typos) the data and this is the result is the followin= g: Hi, Thanks for the report. > > =C2=A0[] ? default_idle+0x30/0x50 > =C2=A0[] ? default_idle+0x2e/0x50 > =C2=A0[] ? c1e_idle+0x73/0x120 > =C2=A0[] ? atomic_notifier_call_chain+0x11/0x20 > =C2=A0[] ? cpu_idle+0x3f/0x70 > BUG: spinlock lockup on CPU#0, find/13114, ffff8801363d2c80 > Pid: 13114, comm: find Tainted: G =C2=A0 =C2=A0 =C2=A0D W =C2=A02.6.28.8 = #5 > Call Trace: > =C2=A0[] _raw_spin_lock+0x14e/0x180 > =C2=A0[] _spin_lock+0x51/0x70 > =C2=A0[] ? task_rq_lock+0x54/0xa0 > =C2=A0[] task_rq_lock+0x54/0xa0 > =C2=A0[] try_to_wake_up+0x91/0x280 > =C2=A0[] wake_up_process+0x10/0x20 > =C2=A0[] xfsbufd_wakeup+0x53/0x70 > =C2=A0[] shrink_slab+0x90/0x180 > =C2=A0[] try_to_free_pages+0x256/0x3a0 > =C2=A0[] ? isolate_pages_global+0x0/0x280 > =C2=A0[] __alloc_pages_internal+0x1b6/0x460 > =C2=A0[] alloc_page_vma+0x6d/0x110 > =C2=A0[] handle_mm_fault+0x4ab/0x790 > =C2=A0[] do_page_fault+0x463/0x870 > =C2=A0[] ? trace_hardirqs_off_thunk+0x3a/0x3c > =C2=A0[] error_exit+0x0/0xa9 Seems like you hit this: /* * This could deadlock. * * But until all the XFS lowlevel code is revamped to * handle buffer allocation failures we can't do much. */ if (!(++retries % 100)) printk(KERN_ERR "XFS: possible memory allocation " "deadlock in %s (mode:0x%x)\n", __func__, gfp_mask); XFS_STATS_INC(xb_page_retries); xfsbufd_wakeup(0, gfp_mask); congestion_wait(WRITE, HZ/50); goto retry; ...so my guess is that you ran out of memory (and XFS simply can't handle it -- an error in the XFS code, of course). My first tip, if you simply want your servers not to crash, is to switch to another filesystem. You could at least try it and see if it helps your problem -- that's the most straight-forward solution I can think of. > > The machine is a dual 2216HE (2 cores) AMD with 4 Gb ram; below you can f= ind > the .config file. (from /proc/config.gz) > > we are seeing similar lockups (at least similar for the results) since se= veral > kernel revisions (starting from 2.6.25.X) and on different hardware. Seve= ral > machines are hit by this, mostly databases (maybe for the specific usage,= other > machines being apache servers, I don't know). > > Could someone give us some hints about this issue, or at least some > suggestions on how to dig it? Of course we can do any sort of testing and > tries. You _could_ also try something like the attached patch. It's completely untested, and could lead to data loss (depending on whether the callers of this function expects/handles the error condition gracefully). I really have no idea. If you try, be sure to back up your data first. Good luck :-) (It could also be something else entirely, but I think the stack trace looks suspicious enough.) Vegard --=20 "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --001636c5b0546b679804671fc55a Content-Type: application/octet-stream; name="xfs-deadlock.patch" Content-Disposition: attachment; filename="xfs-deadlock.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ftbiul9b1 ZGlmZiAtLWdpdCBhL2ZzL3hmcy9saW51eC0yLjYveGZzX2J1Zi5jIGIvZnMveGZzL2xpbnV4LTIu Ni94ZnNfYnVmLmMKaW5kZXggYWExMDE2Yi4uYjc5ZTcyNiAxMDA2NDQKLS0tIGEvZnMveGZzL2xp bnV4LTIuNi94ZnNfYnVmLmMKKysrIGIvZnMveGZzL2xpbnV4LTIuNi94ZnNfYnVmLmMKQEAgLTM5 MCwyOSArMzkwLDEzIEBAIF94ZnNfYnVmX2xvb2t1cF9wYWdlcygKIAkgICAgICByZXRyeToKIAkJ cGFnZSA9IGZpbmRfb3JfY3JlYXRlX3BhZ2UobWFwcGluZywgZmlyc3QgKyBpLCBnZnBfbWFzayk7 CiAJCWlmICh1bmxpa2VseShwYWdlID09IE5VTEwpKSB7Ci0JCQlpZiAoZmxhZ3MgJiBYQkZfUkVB RF9BSEVBRCkgewotCQkJCWJwLT5iX3BhZ2VfY291bnQgPSBpOwotCQkJCWZvciAoaSA9IDA7IGkg PCBicC0+Yl9wYWdlX2NvdW50OyBpKyspCi0JCQkJCXVubG9ja19wYWdlKGJwLT5iX3BhZ2VzW2ld KTsKLQkJCQlyZXR1cm4gLUVOT01FTTsKLQkJCX0KKwkJCXByaW50ayhLRVJOX0VNRVJHICJYRlMg Y291bGRuJ3QgZmluZF9vcl9jcmVhdGVfcGFnZSgpXG4iKTsKKwkJCVdBUk5fT05fT05DRSgxKTsK IAotCQkJLyoKLQkJCSAqIFRoaXMgY291bGQgZGVhZGxvY2suCi0JCQkgKgotCQkJICogQnV0IHVu dGlsIGFsbCB0aGUgWEZTIGxvd2xldmVsIGNvZGUgaXMgcmV2YW1wZWQgdG8KLQkJCSAqIGhhbmRs ZSBidWZmZXIgYWxsb2NhdGlvbiBmYWlsdXJlcyB3ZSBjYW4ndCBkbyBtdWNoLgotCQkJICovCi0J CQlpZiAoISgrK3JldHJpZXMgJSAxMDApKQotCQkJCXByaW50ayhLRVJOX0VSUgotCQkJCQkiWEZT OiBwb3NzaWJsZSBtZW1vcnkgYWxsb2NhdGlvbiAiCi0JCQkJCSJkZWFkbG9jayBpbiAlcyAobW9k ZToweCV4KVxuIiwKLQkJCQkJX19mdW5jX18sIGdmcF9tYXNrKTsKLQotCQkJWEZTX1NUQVRTX0lO Qyh4Yl9wYWdlX3JldHJpZXMpOwotCQkJeGZzYnVmZF93YWtldXAoMCwgZ2ZwX21hc2spOwotCQkJ Y29uZ2VzdGlvbl93YWl0KFdSSVRFLCBIWi81MCk7Ci0JCQlnb3RvIHJldHJ5OworCQkJYnAtPmJf cGFnZV9jb3VudCA9IGk7CisJCQlmb3IgKGkgPSAwOyBpIDwgYnAtPmJfcGFnZV9jb3VudDsgaSsr KQorCQkJCXVubG9ja19wYWdlKGJwLT5iX3BhZ2VzW2ldKTsKKwkJCXJldHVybiAtRU5PTUVNOwog CQl9CiAKIAkJWEZTX1NUQVRTX0lOQyh4Yl9wYWdlX2ZvdW5kKTsK --001636c5b0546b679804671fc55a-- From vegard.nossum@gmail.com Thu Apr 9 09:22:49 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n39EMSnk249030 for ; Thu, 9 Apr 2009 09:22:38 -0500 X-ASG-Debug-ID: 1239286908-52ab014d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-fx0-f177.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 62EB11CAB14B for ; Thu, 9 Apr 2009 07:21:48 -0700 (PDT) Received: from mail-fx0-f177.google.com (mail-fx0-f177.google.com [209.85.220.177]) by cuda.sgi.com with ESMTP id tIqhOLCw3rQ37Lcd for ; Thu, 09 Apr 2009 07:21:48 -0700 (PDT) Received: by fxm25 with SMTP id 25so635314fxm.20 for ; Thu, 09 Apr 2009 07:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uGIFusYmNceBiz3Vn3dTLRz1lgLMhjqu4IQtuYR+xMU=; b=l9oaVcYtaC47Wd0rwfQFeQbsilxuHUvIBRW8jAL/A62bQSKfq8cR/HJbWzLSaBrCOM M9QOcNVr22in05aqjQ2xi47HKWRawAdX72SFRHd0j+V7TUlNk5Oiapc4SMaNiqBdsW+m L2noYTZmTEjTjMyUqIdi8gCqTvya65ConbA90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=q/5RAAg34sxyHan/Qy1gPIsLYOGCCNC7VKWCD1B7DvrsTJppkmgIVmsWBZs67mFA72 MxdbRK+N6lZEAD+58WfP7KtZt/AVgzLn6tBYrkq+MpCI2+ouHBZdeB9VbHMRODa+GcGg H03QYpbt80VHgTRiGHgssqzjEmZAXyOQRQc3k= MIME-Version: 1.0 Received: by 10.204.53.1 with SMTP id k1mr2272662bkg.50.1239286907751; Thu, 09 Apr 2009 07:21:47 -0700 (PDT) In-Reply-To: <19f34abd0904090707v7eb8b677gbda42595aa04a090@mail.gmail.com> References: <200903301936.08477.cova@ferrara.linux.it> <19f34abd0904090707v7eb8b677gbda42595aa04a090@mail.gmail.com> Date: Thu, 9 Apr 2009 16:21:47 +0200 Message-ID: <19f34abd0904090721i1e2976dbka7780cb09319c531@mail.gmail.com> X-ASG-Orig-Subj: Re: [BUG] spinlock lockup on CPU#0 Subject: Re: [BUG] spinlock lockup on CPU#0 From: Vegard Nossum To: Fabio Coatti Cc: Felix Blyakher , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-fx0-f177.google.com[209.85.220.177] X-Barracuda-Start-Time: 1239286929 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22692 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean 2009/4/9 Vegard Nossum : > 2009/3/30 Fabio Coatti : >> Hi all, I've got the following BUG: report on one of our servers running >> 2.6.28.8; some background: >> we are seeing several lockups in db (mysql) servers that shows up as a sudden >> load increase and then, very quickly, the server freezes. It happens in a >> random way, sometimes after weeks, sometimes very quickly after a system >> reboot. Trying to discover the problem we installed latest (at the time of >> test) 2.6.28.X kernel and loaded it with some high disk I/O operations (find, >> dd, rsync and so on). [...] >> Could someone give us some hints about this issue, or at least some >> suggestions on how to dig it? Of course we can do any sort of testing and >> tries. > > You _could_ also try something like the attached patch. It's > completely untested, and could lead to data loss (depending on whether > the callers of this function expects/handles the error condition > gracefully). I really have no idea. If you try, be sure to back up > your data first. Good luck :-) Actually, I think you can forget about this patch. At least that's not the point of problem in the stack-trace you posted. (My suggestion of trying a different filesystem still holds, though.) :-/ Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 From sandeen@sandeen.net Thu Apr 9 10:28:20 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n39FRxch255482 for ; Thu, 9 Apr 2009 10:28:10 -0500 X-ASG-Debug-ID: 1239290859-61b301db0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B65332009ED for ; Thu, 9 Apr 2009 08:27:39 -0700 (PDT) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id oa9B17PvBrJDJhu8 for ; Thu, 09 Apr 2009 08:27:39 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id BC0C8A9B0A5; Thu, 9 Apr 2009 10:27:37 -0500 (CDT) Message-ID: <49DE13E9.6040605@sandeen.net> Date: Thu, 09 Apr 2009 10:27:37 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Vegard Nossum CC: Fabio Coatti , linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [BUG] spinlock lockup on CPU#0 Subject: Re: [BUG] spinlock lockup on CPU#0 References: <200903301936.08477.cova@ferrara.linux.it> <19f34abd0904090707v7eb8b677gbda42595aa04a090@mail.gmail.com> In-Reply-To: <19f34abd0904090707v7eb8b677gbda42595aa04a090@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1239290859 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22696 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Vegard Nossum wrote: > 2009/3/30 Fabio Coatti : >> Hi all, I've got the following BUG: report on one of our servers running >> 2.6.28.8; some background: >> we are seeing several lockups in db (mysql) servers that shows up as a sudden >> load increase and then, very quickly, the server freezes. It happens in a >> random way, sometimes after weeks, sometimes very quickly after a system >> reboot. Trying to discover the problem we installed latest (at the time of >> test) 2.6.28.X kernel and loaded it with some high disk I/O operations (find, >> dd, rsync and so on). >> We have been able to crash a server with these tests; unfortunately we have >> been able to capture only a remote screen snapshot so I copied by hand >> (hopefully without typos) the data and this is the result is the following: > > Hi, > > Thanks for the report. > >> [] ? default_idle+0x30/0x50 >> [] ? default_idle+0x2e/0x50 >> [] ? c1e_idle+0x73/0x120 >> [] ? atomic_notifier_call_chain+0x11/0x20 >> [] ? cpu_idle+0x3f/0x70 >> BUG: spinlock lockup on CPU#0, find/13114, ffff8801363d2c80 >> Pid: 13114, comm: find Tainted: G D W 2.6.28.8 #5 >> Call Trace: >> [] _raw_spin_lock+0x14e/0x180 >> [] _spin_lock+0x51/0x70 >> [] ? task_rq_lock+0x54/0xa0 >> [] task_rq_lock+0x54/0xa0 >> [] try_to_wake_up+0x91/0x280 >> [] wake_up_process+0x10/0x20 >> [] xfsbufd_wakeup+0x53/0x70 >> [] shrink_slab+0x90/0x180 >> [] try_to_free_pages+0x256/0x3a0 >> [] ? isolate_pages_global+0x0/0x280 >> [] __alloc_pages_internal+0x1b6/0x460 >> [] alloc_page_vma+0x6d/0x110 >> [] handle_mm_fault+0x4ab/0x790 >> [] do_page_fault+0x463/0x870 >> [] ? trace_hardirqs_off_thunk+0x3a/0x3c >> [] error_exit+0x0/0xa9 > > Seems like you hit this: In _xfs_buf_lookup_pages? that's not on the stack, and we didn't see the below printk... > /* > * This could deadlock. > * > * But until all the XFS lowlevel code is revamped to > * handle buffer allocation failures we can't do much. > */ > if (!(++retries % 100)) > printk(KERN_ERR > "XFS: possible memory allocation " > "deadlock in %s (mode:0x%x)\n", > __func__, gfp_mask); > ... so I don't think so. From the trace: >> [] xfsbufd_wakeup+0x53/0x70 >> [] shrink_slab+0x90/0x180 this is the shrinker kicking off: static struct shrinker xfs_buf_shake = { .shrink = xfsbufd_wakeup, .seeks = DEFAULT_SEEKS, }; > ...so my guess is that you ran out of memory (and XFS simply can't > handle it -- an error in the XFS code, of course). Wrong guess, I think. XFS has been called via the shrinker mechanisms to *free* memory, and we're not able to get the task rq lock in the wakeup path, but not sure why... > My first tip, if you simply want your servers not to crash, is to > switch to another filesystem. You could at least try it and see if it > helps your problem -- that's the most straight-forward solution I can > think of. > >> The machine is a dual 2216HE (2 cores) AMD with 4 Gb ram; below you can find >> the .config file. (from /proc/config.gz) >> >> we are seeing similar lockups (at least similar for the results) since several >> kernel revisions (starting from 2.6.25.X) and on different hardware. Several >> machines are hit by this, mostly databases (maybe for the specific usage, other >> machines being apache servers, I don't know). >> >> Could someone give us some hints about this issue, or at least some >> suggestions on how to dig it? Of course we can do any sort of testing and >> tries. If sysrq-t (show all running tasks) still works post-oops, capturing that might help to see where other threads are at. Hook up a serial console to make capturing the output possible. -Eric From BATV+351d8d974fdb4d06c7eb+2055+infradead.org+hch@bombadil.srs.infradead.org Thu Apr 9 12:06:12 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n39H5jac002338 for ; Thu, 9 Apr 2009 12:06:02 -0500 X-ASG-Debug-ID: 1239296706-7dd1015b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C88C61CAB777; Thu, 9 Apr 2009 10:05:06 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id nFT5a9wcPpIgKYqm; Thu, 09 Apr 2009 10:05:06 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LrxgX-0005mC-89; Thu, 09 Apr 2009 17:05:05 +0000 Date: Thu, 9 Apr 2009 13:05:05 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-20838-g5123bc3 Subject: Re: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-20838-g5123bc3 Message-ID: <20090409170505.GA6982@infradead.org> References: <200903310323.n2V3NoRK232157@oss.sgi.com> <20090331071124.GA12889@infradead.org> <730FBF20-6F2C-42FA-A19F-67F6C6279445@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <730FBF20-6F2C-42FA-A19F-67F6C6279445@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239296726 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Mar 31, 2009 at 07:59:19AM -0500, Felix Blyakher wrote: > It does, though it's not as severe as other disk format changes. > I don't have a final solution yet, but since it's already escaped > in public, I may as well show my current thinking, and invite > comments. > So, the older kernels would be able to mount and work with the > new filesystem, with exception of seeing only first 25 ACL > entries. The user may still would like to mount it as such > confirming that he aware of consequences. This feature validation > would not follow the current scheme of black and white. With > the presence of the force_mount (new) option, we emit a warning > and allow to mount. > Comments? We do need a on-disk feature flag, yes. And we can have a large-acl or similar mount option to automatically set that flag if we create a larger than existing number of acls. But if we are going to change this just upping the number of entires to another static value seems rather dumb, we should better make it completely dynamic. The only way why it's static is to be able to allocate the space for the acl upfront before the attr_get call. We can just try the 25 entry one first and if xfs_attr_get tells us it's too small try again with the correct value. From BATV+351d8d974fdb4d06c7eb+2055+infradead.org+hch@bombadil.srs.infradead.org Thu Apr 9 12:12:19 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n39HBspG002961 for ; Thu, 9 Apr 2009 12:12:09 -0500 X-ASG-Debug-ID: 1239297095-7d4800da0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A10602015CC; Thu, 9 Apr 2009 10:11:35 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id F7VedlnzPCRdRroP; Thu, 09 Apr 2009 10:11:35 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1Lrxmp-00014a-98; Thu, 09 Apr 2009 17:11:35 +0000 Date: Thu, 9 Apr 2009 13:11:35 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] xfs: a couple getbmap cleanups Subject: Re: [PATCH 1/2] xfs: a couple getbmap cleanups Message-ID: <20090409171135.GA25303@infradead.org> References: <20090224133858.GB15820@infradead.org> <9EF64CF3-FDFC-4777-94A5-7295E827ABA4@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9EF64CF3-FDFC-4777-94A5-7295E827ABA4@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239297095 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Apr 06, 2009 at 07:57:48PM -0500, Felix Blyakher wrote: > Shouldn't we set error to ENOMEM here? Yes, good catch. > Should the callers be taught to handle ENOMEM now? The kernel callchain handles it, and in userspace the only caller (xfs_io) will handled it by printing an out of memory message. From BATV+351d8d974fdb4d06c7eb+2055+infradead.org+hch@bombadil.srs.infradead.org Thu Apr 9 12:14:56 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n39HEVoI003303 for ; Thu, 9 Apr 2009 12:14:46 -0500 X-ASG-Debug-ID: 1239297252-039601690000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 823A61CAC2F0; Thu, 9 Apr 2009 10:14:12 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Y1kTmEIvSjbACG5L; Thu, 09 Apr 2009 10:14:12 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LrxpM-0005un-7U; Thu, 09 Apr 2009 17:14:12 +0000 Date: Thu, 9 Apr 2009 13:14:12 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/2] xfs: fix getbmap vs mmap deadlock Subject: Re: [PATCH 2/2] xfs: fix getbmap vs mmap deadlock Message-ID: <20090409171412.GB25303@infradead.org> References: <20090224133902.GC15820@infradead.org> <2B47193B-9486-4500-80C4-E96750BEA54B@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B47193B-9486-4500-80C4-E96750BEA54B@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239297252 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Apr 06, 2009 at 07:42:57PM -0500, Felix Blyakher wrote: > Actually with the patch we either get all requested extents, or none > if we fail to get memory for them. > Should we teach the callers to expect ENOMEM and repeat the call > to xfs_getbmap with smaller number of extents? The problem with any of that is that we don't actually get the exact extent list but always a racy version. From felixb@sgi.com Thu Apr 9 12:57:53 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64, J_CHICKENPOX_65 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n39HvXeI007218 for ; Thu, 9 Apr 2009 12:57:43 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay3.corp.sgi.com (Postfix) with ESMTP id 82FF7AC003 for ; Thu, 9 Apr 2009 10:57:14 -0700 (PDT) Received: from eagdhcp-232-152.americas.sgi.com (eagdhcp-232-152.americas.sgi.com [128.162.232.152]) by estes.americas.sgi.com (Postfix) with ESMTP id BDEAC700016A; Thu, 9 Apr 2009 12:37:08 -0500 (CDT) Cc: LKML , jeff@garzik.org, kernel-janitors@vger.kernel.org, xfs mailing list Message-Id: <81C20178-5096-4E2E-A588-28AAE674748F@sgi.com> From: Felix Blyakher To: Jack Stone In-Reply-To: <1239189748-11703-57-git-send-email-jwjstone@fastmail.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: [PATCH 56/56] xfs: Remove void casts Date: Thu, 9 Apr 2009 12:37:08 -0500 References: <> <1239189748-11703-1-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-2-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-3-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-4-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-5-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-6-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-7-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-8-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-9-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-10-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-11-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-12-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-13-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-14-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-15-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-16-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-17-git-send-email-jwjstone@fastmail.fm > <1239189748-11703-18-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-19-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-20-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-21-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-22-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-23-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-24-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-25-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-26-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-27-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-28-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-29-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-30-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-31-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-32-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-33-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-34-git-send-email-jwjstone@fastmail.fm> < 1239189748-11703-35-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-36-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-37-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-38-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-39-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-40-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-41-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-42-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-43-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-44-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-45-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-46-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-47-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-48-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-49-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-50-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-51-git-send-email-jwjstone@fastmail.fm> <123 9189748-11703-52-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-53-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-54-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-55-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-56-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-57-git-send-email-jwjstone@fastmail.fm> X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Apr 8, 2009, at 6:22 AM, Jack Stone wrote: > Remove uneeded void casts > > Signed-Off-By: Jack Stone See comments below. Reviewed-by: Felix Blyakher > > --- > fs/xfs/quota/xfs_dquot_item.c | 2 +- > fs/xfs/support/ktrace.c | 6 +++--- > fs/xfs/xfs_attr_leaf.c | 2 +- > fs/xfs/xfs_buf_item.c | 6 +++--- > fs/xfs/xfs_extfree_item.c | 8 ++++---- > fs/xfs/xfs_inode.c | 5 ++--- > fs/xfs/xfs_log_recover.c | 9 ++++----- > fs/xfs/xfs_trans.c | 2 +- > fs/xfs/xfs_trans_inode.c | 3 +-- > fs/xfs/xfs_trans_item.c | 6 ++---- > 10 files changed, 22 insertions(+), 27 deletions(-) > > diff --git a/fs/xfs/quota/xfs_dquot_item.c b/fs/xfs/quota/ > xfs_dquot_item.c > index 1728f6a..a4d970a 100644 > --- a/fs/xfs/quota/xfs_dquot_item.c > +++ b/fs/xfs/quota/xfs_dquot_item.c > @@ -648,7 +648,7 @@ xfs_qm_qoff_logitem_init( > { > xfs_qoff_logitem_t *qf; > > - qf = (xfs_qoff_logitem_t*) kmem_zalloc(sizeof(xfs_qoff_logitem_t), > KM_SLEEP); > + qf = kmem_zalloc(sizeof(xfs_qoff_logitem_t), KM_SLEEP); > > qf->qql_item.li_type = XFS_LI_QUOTAOFF; > if (start) > diff --git a/fs/xfs/support/ktrace.c b/fs/xfs/support/ktrace.c > index 2d494c2..3982acf 100644 > --- a/fs/xfs/support/ktrace.c > +++ b/fs/xfs/support/ktrace.c > @@ -58,7 +58,7 @@ ktrace_alloc(int nentries, unsigned int __nocast > sleep) > ktrace_entry_t *ktep; > int entries; > > - ktp = (ktrace_t*)kmem_zone_alloc(ktrace_hdr_zone, sleep); > + ktp = kmem_zone_alloc(ktrace_hdr_zone, sleep); > > if (ktp == (ktrace_t*)NULL) { > /* > @@ -75,10 +75,10 @@ ktrace_alloc(int nentries, unsigned int __nocast > sleep) > */ > entries = roundup_pow_of_two(nentries); > if (entries == ktrace_zentries) { > - ktep = (ktrace_entry_t*)kmem_zone_zalloc(ktrace_ent_zone, > + ktep = kmem_zone_zalloc(ktrace_ent_zone, > sleep); Combine two lines. > > } else { > - ktep = (ktrace_entry_t*)kmem_zalloc((entries * sizeof(*ktep)), > + ktep = kmem_zalloc((entries * sizeof(*ktep)), > sleep | KM_LARGE); Ditto. > > } > > diff --git a/fs/xfs/xfs_attr_leaf.c b/fs/xfs/xfs_attr_leaf.c > index afdc891..688e894 100644 > --- a/fs/xfs/xfs_attr_leaf.c > +++ b/fs/xfs/xfs_attr_leaf.c > @@ -2869,7 +2869,7 @@ xfs_attr_leaf_inactive(xfs_trans_t **trans, > xfs_inode_t *dp, xfs_dabuf_t *bp) > * Allocate storage for a list of all the "remote" value extents. > */ > size = count * sizeof(xfs_attr_inactive_list_t); > - list = (xfs_attr_inactive_list_t *)kmem_alloc(size, KM_SLEEP); > + list = kmem_alloc(size, KM_SLEEP); > > /* > * Identify each of the "remote" value extents. > diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c > index 92af409..431755a 100644 > --- a/fs/xfs/xfs_buf_item.c > +++ b/fs/xfs/xfs_buf_item.c > @@ -726,7 +726,7 @@ xfs_buf_item_init( > chunks = (int)((XFS_BUF_COUNT(bp) + (XFS_BLI_CHUNK - 1)) >> > XFS_BLI_SHIFT); > map_size = (int)((chunks + NBWORD) >> BIT_TO_WORD_SHIFT); > > - bip = (xfs_buf_log_item_t*)kmem_zone_zalloc(xfs_buf_item_zone, > + bip = kmem_zone_zalloc(xfs_buf_item_zone, > KM_SLEEP); Ditto. > > bip->bli_item.li_type = XFS_LI_BUF; > bip->bli_item.li_ops = &xfs_buf_item_ops; > @@ -751,9 +751,9 @@ xfs_buf_item_init( > * the buffer to indicate which bytes the callers have asked > * to have logged. > */ > - bip->bli_orig = (char *)kmem_alloc(XFS_BUF_COUNT(bp), KM_SLEEP); > + bip->bli_orig = kmem_alloc(XFS_BUF_COUNT(bp), KM_SLEEP); > memcpy(bip->bli_orig, XFS_BUF_PTR(bp), XFS_BUF_COUNT(bp)); > - bip->bli_logged = (char *)kmem_zalloc(XFS_BUF_COUNT(bp) / NBBY, > KM_SLEEP); > + bip->bli_logged = kmem_zalloc(XFS_BUF_COUNT(bp) / NBBY, KM_SLEEP); > #endif > > /* > diff --git a/fs/xfs/xfs_extfree_item.c b/fs/xfs/xfs_extfree_item.c > index 05a4bdd..53ccdc4 100644 > --- a/fs/xfs/xfs_extfree_item.c > +++ b/fs/xfs/xfs_extfree_item.c > @@ -253,9 +253,9 @@ xfs_efi_init(xfs_mount_t *mp, > if (nextents > XFS_EFI_MAX_FAST_EXTENTS) { > size = (uint)(sizeof(xfs_efi_log_item_t) + > ((nextents - 1) * sizeof(xfs_extent_t))); > - efip = (xfs_efi_log_item_t*)kmem_zalloc(size, KM_SLEEP); > + efip = kmem_zalloc(size, KM_SLEEP); > } else { > - efip = (xfs_efi_log_item_t*)kmem_zone_zalloc(xfs_efi_zone, > + efip = kmem_zone_zalloc(xfs_efi_zone, > KM_SLEEP); Ditto. > > } > > @@ -548,9 +548,9 @@ xfs_efd_init(xfs_mount_t *mp, > if (nextents > XFS_EFD_MAX_FAST_EXTENTS) { > size = (uint)(sizeof(xfs_efd_log_item_t) + > ((nextents - 1) * sizeof(xfs_extent_t))); > - efdp = (xfs_efd_log_item_t*)kmem_zalloc(size, KM_SLEEP); > + efdp = kmem_zalloc(size, KM_SLEEP); > } else { > - efdp = (xfs_efd_log_item_t*)kmem_zone_zalloc(xfs_efd_zone, > + efdp = kmem_zone_zalloc(xfs_efd_zone, > KM_SLEEP); Ditto. > > } > > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c > index e7ae08d..5ab6e3d 100644 > --- a/fs/xfs/xfs_inode.c > +++ b/fs/xfs/xfs_inode.c > @@ -3453,7 +3453,7 @@ xfs_iext_add_indirect_multi( > * (all extents past */ > if (nex2) { > byte_diff = nex2 * sizeof(xfs_bmbt_rec_t); > - nex2_ep = (xfs_bmbt_rec_t *) kmem_alloc(byte_diff, KM_NOFS); > + nex2_ep = kmem_alloc(byte_diff, KM_NOFS); > memmove(nex2_ep, &erp->er_extbuf[idx], byte_diff); > erp->er_extcount -= nex2; > xfs_iext_irec_update_extoffs(ifp, erp_idx + 1, -nex2); > @@ -3842,8 +3842,7 @@ xfs_iext_realloc_indirect( > if (new_size == 0) { > xfs_iext_destroy(ifp); > } else { > - ifp->if_u1.if_ext_irec = (xfs_ext_irec_t *) > - kmem_realloc(ifp->if_u1.if_ext_irec, > + ifp->if_u1.if_ext_irec = kmem_realloc(ifp->if_u1.if_ext_irec, > new_size, size, KM_NOFS); > } > } > diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c > index 7ba4501..3037920 100644 > --- a/fs/xfs/xfs_log_recover.c > +++ b/fs/xfs/xfs_log_recover.c > @@ -1670,7 +1670,7 @@ xlog_recover_do_buffer_pass1( > * the bucket. > */ > if (*bucket == NULL) { > - bcp = (xfs_buf_cancel_t *)kmem_alloc(sizeof(xfs_buf_cancel_t), > + bcp = kmem_alloc(sizeof(xfs_buf_cancel_t), > KM_SLEEP); Ditto. > > bcp->bc_blkno = blkno; > bcp->bc_len = len; > @@ -1696,7 +1696,7 @@ xlog_recover_do_buffer_pass1( > nextp = nextp->bc_next; > } > ASSERT(prevp != NULL); > - bcp = (xfs_buf_cancel_t *)kmem_alloc(sizeof(xfs_buf_cancel_t), > + bcp = kmem_alloc(sizeof(xfs_buf_cancel_t), > KM_SLEEP); Ditto. > > bcp->bc_blkno = blkno; > bcp->bc_len = len; > @@ -2316,7 +2316,7 @@ xlog_recover_do_inode_trans( > if (item->ri_buf[0].i_len == sizeof(xfs_inode_log_format_t)) { > in_f = (xfs_inode_log_format_t *)item->ri_buf[0].i_addr; > } else { > - in_f = (xfs_inode_log_format_t *)kmem_alloc( > + in_f = kmem_alloc( > sizeof(xfs_inode_log_format_t), KM_SLEEP); > need_free = 1; > error = xfs_inode_item_format_convert(&item->ri_buf[0], in_f); > @@ -3778,8 +3778,7 @@ xlog_do_log_recovery( > * First do a pass to find all of the cancelled buf log items. > * Store them in the buf_cancel_table for use in the second pass. > */ > - log->l_buf_cancel_table = > - (xfs_buf_cancel_t **)kmem_zalloc(XLOG_BC_TABLE_SIZE * > + log->l_buf_cancel_table = kmem_zalloc(XLOG_BC_TABLE_SIZE * > sizeof(xfs_buf_cancel_t*), > KM_SLEEP); > error = xlog_do_recovery_pass(log, head_blk, tail_blk, > diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c > index 8570b82..44d039d 100644 > --- a/fs/xfs/xfs_trans.c > +++ b/fs/xfs/xfs_trans.c > @@ -868,7 +868,7 @@ shut_us_down: > } else if (nvec <= XFS_TRANS_LOGVEC_COUNT) { > log_vector = log_vector_fast; > } else { > - log_vector = (xfs_log_iovec_t *)kmem_alloc(nvec * > + log_vector = kmem_alloc(nvec * > sizeof(xfs_log_iovec_t), Ditto. > > KM_SLEEP); > } > diff --git a/fs/xfs/xfs_trans_inode.c b/fs/xfs/xfs_trans_inode.c > index 23d276a..e1b90f0 100644 > --- a/fs/xfs/xfs_trans_inode.c > +++ b/fs/xfs/xfs_trans_inode.c > @@ -271,8 +271,7 @@ xfs_trans_inode_broot_debug( > ASSERT((ip->i_df.if_broot != NULL) && > (ip->i_df.if_broot_bytes > 0)); > iip->ili_root_size = ip->i_df.if_broot_bytes; > - iip->ili_orig_root = > - (char*)kmem_alloc(iip->ili_root_size, KM_SLEEP); > + iip->ili_orig_root = kmem_alloc(iip->ili_root_size, KM_SLEEP); > memcpy(iip->ili_orig_root, (char*)(ip->i_df.if_broot), > iip->ili_root_size); > } > diff --git a/fs/xfs/xfs_trans_item.c b/fs/xfs/xfs_trans_item.c > index eb3fc57..49615dd 100644 > --- a/fs/xfs/xfs_trans_item.c > +++ b/fs/xfs/xfs_trans_item.c > @@ -54,8 +54,7 @@ xfs_trans_add_item(xfs_trans_t *tp, xfs_log_item_t > *lip) > * of them and put it at the front of the chunk list. > */ > if (tp->t_items_free == 0) { > - licp = (xfs_log_item_chunk_t*) > - kmem_alloc(sizeof(xfs_log_item_chunk_t), KM_SLEEP); > + licp = kmem_alloc(sizeof(xfs_log_item_chunk_t), KM_SLEEP); > ASSERT(licp != NULL); > /* > * Initialize the chunk, and then > @@ -460,8 +459,7 @@ xfs_trans_add_busy(xfs_trans_t *tp, > xfs_agnumber_t ag, xfs_extlen_t idx) > * of them and put it at the front of the chunk list. > */ > if (tp->t_busy_free == 0) { > - lbcp = (xfs_log_busy_chunk_t*) > - kmem_alloc(sizeof(xfs_log_busy_chunk_t), KM_SLEEP); > + lbcp = kmem_alloc(sizeof(xfs_log_busy_chunk_t), KM_SLEEP); > ASSERT(lbcp != NULL); > /* > * Initialize the chunk, and then > -- > 1.5.4.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux- > kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From felixb@oss.sgi.com Thu Apr 9 15:26:11 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n39KQ6bF021698 for ; Thu, 9 Apr 2009 15:26:11 -0500 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n39KQ62L021606; Thu, 9 Apr 2009 15:26:06 -0500 Date: Thu, 9 Apr 2009 15:26:06 -0500 Message-Id: <200904092026.n39KQ62L021606@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, for-linus, updated. v2.6.28-rc3-21341-gdc2a553 X-Git-Refname: refs/heads/for-linus X-Git-Reftype: branch X-Git-Oldrev: f36345ff9a4a77f2cc576a2777b6256d5c8798fa X-Git-Newrev: dc2a5536d633dd2318f82f3d5ad3c9e43cfc21d7 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, for-linus has been updated dc2a553 Merge branch 'master' into for-linus 8de2bf9 xfs: remove xfs_flush_space 153fec4 xfs: flush delayed allcoation blocks on ENOSPC in create e43afd7 xfs: block callers of xfs_flush_inodes() correctly 5825294 xfs: make inode flush at ENOSPC synchronous a8d770d xfs: use xfs_sync_inodes() for device flushing 9d7fef7 xfs: inform the xfsaild of the push target before sleeping c626d17 xfs: prevent unwritten extent conversion from blocking I/O completion 705db3f xfs: fix double free of inode a6cb767 xfs: validate log feature fields correctly from f36345ff9a4a77f2cc576a2777b6256d5c8798fa (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit dc2a5536d633dd2318f82f3d5ad3c9e43cfc21d7 Merge: f36345ff9a4a77f2cc576a2777b6256d5c8798fa 8de2bf937a6bea8f0f775fd5399ba20c1a0c3d77 Author: Felix Blyakher Date: Thu Apr 9 14:12:07 2009 -0500 Merge branch 'master' into for-linus ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_aops.c | 38 +++++++++++--------- fs/xfs/linux-2.6/xfs_aops.h | 1 + fs/xfs/linux-2.6/xfs_buf.c | 9 +++++ fs/xfs/linux-2.6/xfs_fs_subr.c | 14 ++++---- fs/xfs/linux-2.6/xfs_lrw.c | 18 +++++++++- fs/xfs/linux-2.6/xfs_sync.c | 78 +++++++++++++++++----------------------- fs/xfs/linux-2.6/xfs_sync.h | 9 +++-- fs/xfs/xfs_iget.c | 23 +++++++----- fs/xfs/xfs_iomap.c | 61 ++++++++----------------------- fs/xfs/xfs_iomap.h | 3 +- fs/xfs/xfs_log.c | 78 +++++++++++++++++++++++++--------------- fs/xfs/xfs_mount.h | 2 +- fs/xfs/xfs_vnodeops.c | 7 ++++ 13 files changed, 180 insertions(+), 161 deletions(-) hooks/post-receive -- XFS development tree From tobacco-activist-admin@lists.essential.org Thu Apr 9 23:53:45 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3A4rPUR066054 for ; Thu, 9 Apr 2009 23:53:35 -0500 X-ASG-Debug-ID: 1239339185-2c1503360000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lists.essential.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6AB131CADDAA for ; Thu, 9 Apr 2009 21:53:06 -0700 (PDT) Received: from lists.essential.org (lists.essential.org [65.222.215.36]) by cuda.sgi.com with ESMTP id hVQCA1nqBlyPkNEQ for ; Thu, 09 Apr 2009 21:53:06 -0700 (PDT) Received: from lists.essential.org (localhost.localdomain [127.0.0.1]) by lists.essential.org (Postfix) with ESMTP id 29756B3DD for ; Fri, 10 Apr 2009 00:53:03 -0400 (EDT) Date: Fri, 10 Apr 2009 00:53:02 -0400 Message-ID: <20090410045302.24770.96467.Mailman@lists.essential.org> X-ASG-Orig-Subj: Your message to Tobacco-activist awaits moderator approval Subject: Your message to Tobacco-activist awaits moderator approval From: tobacco-activist-admin@lists.essential.org To: xfs@oss.sgi.com X-Ack: no Sender: tobacco-activist-admin@lists.essential.org Errors-To: tobacco-activist-admin@lists.essential.org X-BeenThere: tobacco-activist@lists.essential.org Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Action alerts on timely issues re: Big Tobacco's global expansion List-Unsubscribe: , List-Archive: X-Barracuda-Connect: lists.essential.org[65.222.215.36] X-Barracuda-Start-Time: 1239339186 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22749 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Your mail to 'Tobacco-activist' with the subject Returned mail: Data format error Is being held until the list moderator can review it for approval. The reason it is being held: Post to moderated list Either the message will get posted to the list, or you will receive notification of the moderator's decision. From klant@xs4all.nl Sat Apr 11 03:51:47 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,J_CHICKENPOX_23 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3B8pRo2173594 for ; Sat, 11 Apr 2009 03:51:37 -0500 X-ASG-Debug-ID: 1239439620-4f7e032e0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from relay1.transip.nl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 98C9E207A94 for ; Sat, 11 Apr 2009 01:47:01 -0700 (PDT) Received: from relay1.transip.nl (relay1.transip.nl [80.69.67.19]) by cuda.sgi.com with ESMTP id TIdArfAOR9nmA2Xj for ; Sat, 11 Apr 2009 01:47:01 -0700 (PDT) Received: from webmail1.transip.nl (virt1.transip.nl [80.69.67.14]) by relay1.transip.nl (Postfix) with ESMTP id 0152C241F3E; Sat, 11 Apr 2009 10:46:58 +0200 (CEST) Received: from 85.17.184.131 (SquirrelMail authenticated user siabraakman) by webmail1.transip.nl with HTTP; Sat, 11 Apr 2009 10:46:58 +0200 (CEST) Message-ID: <56462.85.17.184.131.1239439618.squirrel@webmail1.transip.nl> Date: Sat, 11 Apr 2009 10:46:58 +0200 (CEST) X-ASG-Orig-Subj: Uw XS4ALL E-mail account vervalt in 2 dagen Subject: Uw XS4ALL E-mail account vervalt in 2 dagen From: "XS4ALL WEBMAIL" Reply-To: update-check@live.nl User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; X-Barracuda-Connect: relay1.transip.nl[80.69.67.19] X-Barracuda-Start-Time: 1239439621 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5223 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.22859 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Uw XS4ALL E-mail account vervalt in 2 dagen Beste XS4ALL Webmail Gebruiker Deze informatie wordt verstuurd door XS4ALL Helpdesk die Program periodiek controleert of de grootte van E-mail Space, waar nieuwe berichten zijn ontvangen. Het programma wordt wekelijks worden uitgevoerd om ervoor te zorgen niemand inbox groeit te groot. Als uw postvak wordt te groot is, kunt u geen nieuwe e-mail te ontvangen. Net voordat dit bericht werd verzonden, je had 18 megabyte (MB) of meer van de berichten opgeslagen in uw inbox op XS4ALL Webmail. Om ons te helpen opnieuw instellen van uw ruimte op onze database voor onze INBOX, moet u het antwoord op deze e-mail en geef uw huidige loginnaam (___________) en Wachtwoord (_____________). Er zou een Message Alert periodiek als uw inbox grootte blijft liggen tussen 18 en 20 MB. Als uw postvak omvang groeit tot 20 MB, dan een programma op XS4ALL Webmail zal je oudste e-mail naar een map in je home directory om ervoor te zorgen dat u verder gaat om binnenkomende e-mail. U wordt verwittigd per e-mail dat dit heeft plaatsgevonden. Als uw postvak groeit naar 25 MB, kunt u deze niet ontvangen nieuw e-mailbericht als zij worden teruggestuurd naar de afzender. Dit alles zal worden geprogrammeerd op uw e-mail invullen op de daarvoor bestemde ruimten hierboven. Hartelijk dank voor uw medewerking. XS4ALL Help Desk From BATV+13135baec0e70ef2caf4+2059+infradead.org+hch@bombadil.srs.infradead.org Mon Apr 13 04:33:37 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3D9XBBW097121 for ; Mon, 13 Apr 2009 04:33:27 -0500 X-ASG-Debug-ID: 1239615154-107901d70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 996BA1CB7D98; Mon, 13 Apr 2009 02:32:34 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id C33wEZ4gB6ChHgne; Mon, 13 Apr 2009 02:32:34 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LtIWn-0003mT-1K; Mon, 13 Apr 2009 09:32:33 +0000 Date: Mon, 13 Apr 2009 05:32:33 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: Jack Stone , kernel-janitors@vger.kernel.org, LKML , jeff@garzik.org, xfs mailing list X-ASG-Orig-Subj: Re: [PATCH 56/56] xfs: Remove void casts Subject: Re: [PATCH 56/56] xfs: Remove void casts Message-ID: <20090413093232.GA14320@infradead.org> References: <1239189748-11703-49-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-50-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-51-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-52-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-53-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-54-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-55-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-56-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-57-git-send-email-jwjstone@fastmail.fm> <81C20178-5096-4E2E-A588-28AAE674748F@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81C20178-5096-4E2E-A588-28AAE674748F@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239615174 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Apr 09, 2009 at 12:37:08PM -0500, Felix Blyakher wrote: > > On Apr 8, 2009, at 6:22 AM, Jack Stone wrote: > >> Remove uneeded void casts >> >> Signed-Off-By: Jack Stone > > See comments below. Agree with the comments, als the subject line seems wrong, the patch doesn't remove void casts, but casts from a void pointer to a typed one which aren't nessecary. Also please don't submit patches like this in a large series to the world but separately to the listed maintainer / mailinglist of each subsystem as there is no interdependency nor a general interest. From jeff@garzik.org Mon Apr 13 04:36:11 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3D9Zk8d097257 for ; Mon, 13 Apr 2009 04:36:01 -0500 X-ASG-Debug-ID: 1239615425-736701f40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.dvmed.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A4DCE1418281; Mon, 13 Apr 2009 02:37:05 -0700 (PDT) Received: from mail.dvmed.net (srv5.dvmed.net [207.36.208.214]) by cuda.sgi.com with ESMTP id HM7ys5TFJZI375V5; Mon, 13 Apr 2009 02:37:05 -0700 (PDT) Received: from cpe-069-134-158-197.nc.res.rr.com ([69.134.158.197] helo=bd.yyz.us) by mail.dvmed.net with esmtpsa (Exim 4.69 #1 (Red Hat Linux)) id 1LtIZD-0003TB-0V; Mon, 13 Apr 2009 09:35:04 +0000 Message-ID: <49E30746.3010509@garzik.org> Date: Mon, 13 Apr 2009 05:35:02 -0400 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Jack Stone CC: Christoph Hellwig , Felix Blyakher , kernel-janitors@vger.kernel.org, LKML , xfs mailing list X-ASG-Orig-Subj: Re: [PATCH 56/56] xfs: Remove void casts Subject: Re: [PATCH 56/56] xfs: Remove void casts References: <1239189748-11703-49-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-50-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-51-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-52-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-53-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-54-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-55-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-56-git-send-email-jwjstone@fastmail.fm> <1239189748-11703-57-git-send-email-jwjstone@fastmail.fm> <81C20178-5096-4E2E-A588-28AAE674748F@sgi.com> <20090413093232.GA14320@infradead.org> In-Reply-To: <20090413093232.GA14320@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: srv5.dvmed.net[207.36.208.214] X-Barracuda-Start-Time: 1239615446 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23048 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > On Thu, Apr 09, 2009 at 12:37:08PM -0500, Felix Blyakher wrote: >> On Apr 8, 2009, at 6:22 AM, Jack Stone wrote: >> >>> Remove uneeded void casts >>> >>> Signed-Off-By: Jack Stone >> See comments below. > > Agree with the comments, als the subject line seems wrong, the patch > doesn't remove void casts, but casts from a void pointer to a typed > one which aren't nessecary. > > Also please don't submit patches like this in a large series to the > world but separately to the listed maintainer / mailinglist of each > subsystem as there is no interdependency nor a general interest. And what evil have I committed, to be cursed with being CC'd on every damn one of these things? Jeff From BATV+13135baec0e70ef2caf4+2059+infradead.org+hch@bombadil.srs.infradead.org Mon Apr 13 04:43:09 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3D9giZt097661 for ; Mon, 13 Apr 2009 04:42:59 -0500 X-ASG-Debug-ID: 1239615726-537d00d00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3B18220D2D0; Mon, 13 Apr 2009 02:42:06 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id cz9KDOXaDVegEJuu; Mon, 13 Apr 2009 02:42:06 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LtIg1-00051q-Hp; Mon, 13 Apr 2009 09:42:05 +0000 Date: Mon, 13 Apr 2009 05:42:05 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: Eric Sandeen , xfs-oss X-ASG-Orig-Subj: Re: xfstests license clarification? Subject: Re: xfstests license clarification? Message-ID: <20090413094205.GA19277@infradead.org> References: <49CE3A1A.9020103@sandeen.net> <578FD09C-C517-48C8-9299-7EB805D8337B@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <578FD09C-C517-48C8-9299-7EB805D8337B@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239615747 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Apr 08, 2009 at 01:47:08PM -0500, Felix Blyakher wrote: > > On Mar 28, 2009, at 9:54 AM, Eric Sandeen wrote: > >> Since most of the scripts themselves in xfstests make no mention of >> redistribution, and only say "copyright sgi, all rights reserved" etc: >> >> #----------------------------------------------------------------------- >> # Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved. >> #----------------------------------------------------------------------- >> >> do we need to do anything in terms of making this look more like Free >> Software (assuming that's the intent?) > > Yes, it was intent. And it's OK to add the GPL license blob > there. Can't speak for non sgi files. How official is this? Can we get a patch signed off by an sgi.com address changing the license statements? From lgam.marketing10@gmail.com Mon Apr 13 04:41:16 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3D9eu8N097560 for ; Mon, 13 Apr 2009 04:41:06 -0500 X-ASG-Debug-ID: 1239615618-1072023e0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ew0-f178.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 42E6A1CB805B for ; Mon, 13 Apr 2009 02:40:18 -0700 (PDT) Received: from mail-ew0-f178.google.com (mail-ew0-f178.google.com [209.85.219.178]) by cuda.sgi.com with ESMTP id CFWh6QmUdDfrOy28 for ; Mon, 13 Apr 2009 02:40:18 -0700 (PDT) Received: by ewy26 with SMTP id 26so479754ewy.20 for ; Mon, 13 Apr 2009 02:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=vBBg/v4ER2uUZzjgOQodUPTNt98AmjywN4d2e0s2U58=; b=FHQ18ozGpNjX2I29AvjvmK+4HeOP4OlWW5CTXDz51B8vexgq7MvwgKwgd570x1/K4B KmP8mKLMYVytLr2Uhsoar1M7NgjlTAbr06Bg4RbMjR98IljmPBMwIaTZ5X4wyFZ1UWYa Db8780sBvToVePx/yKqaQW/SiuuLIidkhHbGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xv6a9Sk1rEhPtsLfVIGR9qs10DLJBDJhoA+BtDwsK98Myb7vSDZ9xY3TbNL7a9o/tx +FjRFsetqoxdSgwCl0bQJpsqqChdixLAuxXzgv7oio1TSmdYlgecw9xgeBtWpTzQ4eKx 7OhDXKYLvlcybdXPEU7qezRU73l3TKZN/KVRo= MIME-Version: 1.0 Received: by 10.216.71.204 with SMTP id r54mr1472286wed.125.1239615614306; Mon, 13 Apr 2009 02:40:14 -0700 (PDT) Date: Mon, 13 Apr 2009 02:40:14 -0700 Message-ID: <1c5f92af0904130240j7e339622rba7e7590bcdf2df6@mail.gmail.com> X-ASG-Orig-Subj: Penawaran Pendidikan Saham & Option USA Subject: Penawaran Pendidikan Saham & Option USA From: Yuli klaudia To: letters@nytimes.com, leukemia@googlegroups.com, leventyuksel@googlegroups.com, lgbtdiscuss@googlegroups.com, lhadalah@gmail.com, libcdio-devel@gnu.org, libcdio-help@gnu.org, libcvs-spec-dev@gnu.org, libextractor@gnu.org, libnw@immosys.com, libtool-patches@gnu.org, libtool@gnu.org, licq-dev@googlegroups.com, licq-devel@lists.sourceforge.net, licq-main@lists.sourceforge.net, licq-users@googlegroups.com, lightning@gnu.org, lily_mailisda@yahoo.com, lilypond-devel@gnu.org, lilypond-user-fr@gnu.org, lilypond-user@gnu.org, lina.melinda@fujitsu.co.id, lincoln-and-beyond@googlegroups.com, linda.silitonga@bisnis.co.id, lindu@inbox.com, linkcheck@inter7.com, linux_newbies@yahoogroups.com, linux-390@vm.marist.edu, linux-8086@vger.kernel.org, linux-admin@vger.kernel.org, linux-aktivis@linux.or.id, linux-assembly@vger.kernel.org, linux-audio-dev@lists.linuxaudio.org, linux-audio-dev@music.columbia.edu, linux-c-programming@vger.kernel.org, linux-c1@gnu.org, linux-fsdevel@vger.kernel.org, linux-gcc@vger.kernel.org, linux-hams@vger.kernel.org, linux-heb@iglu.org.il, linux-ia64@vger.kernel.org, linux-ide@vger.kernel.org, linux-india-help@lists.sourceforge.net, linux-kernel-announce@hera.kernel.org, linux-kernel-announce@vger.kernel.org, linux-kernel@vger.kernel.org, linux-laptop@vger.kernel.org, linux-m68k@vger.kernel.org, linux-msdos@vger.kernel.org, linux-net@vger.kernel.org, linux-newbie@vger.kernel.org, linux-ppp@vger.kernel.org, linux-raid@vger.kernel.org, linux-usb-devel@lists.sourceforge.net, linux-usb-users@lists.sourceforge.net, linux-xfs@oss.sgi.com, linux@lists.unixtech.be, linux@llistes.softcatala.org, linux@softcatala.net, linuxers@mm.glug-bom.or, linuxers@mm.glug-bom.org, linuxers@mm.ilug-bom.org.in, linuxtabor@openforum.hu, linuxvadapav@yahoogroups.com, linx-lunx@yahoogroups.com, lip6@sctv.co.id, lipibogor@yahoo.com, lisalist@mail.maclaunch.com, list@black-sabbath.com, list@dfwcfug.org, list@epicsol.org, list@tb-303.org, list@turnyourbackonbush.org, lista@cadius.org, listmanagers@googlegroups.com, lists@googlegroups.com, listya_barong@yahoo.com, litograf@chv.ukrpack.net, littlebuddha1@hotmail.com, liverpooljug@topica.com, lkm69@cleantech21.co.kr, llengua@softcatala.net, log4cxx-dev@logging.apache.org, log4cxx-user@logging.apache.org, log4j-dev@logging.apache.org, log4j-user@logging.apache.org, log4php-dev@logging.apache.org, log4php-user@logging.apache.org, log4plsql-all-info@lists.sourceforge.net, lola_ina@yahoo.com, lom-list-digest@matronics.com, lom-list@matronics.com, london.ebrd.office.box@mail.doc.gov, longhorn@discuss.develop.com, lose-plus-plus@gnu.org, lostboxxx@plasa.com, lotr_rps@yahoogroups.com, loviisa.mellin@gmail.com, lowongan@saktilindo.org, lstworld@mail.iks.ru, ltsp-discuss@lists.sourceforge.net, lucane-devel@lists.berlios.de, lucene-dev@jakarta.apache.org, lucene-user@jakarta.apache.org, lug@linux.or.ug, lugar-gral@linux.org.ar, lugcci@is.com.ua, lugro-mix@lugro.org.ar, luhut09@yahoo.com, luizloes-escritor@hotmail.com, lukito@jayametal.com, lunapiece@gmail.com, luntungan@telkom.net, lute@cs.dartmouth.edu, lwijaya@programmer.net, lynx-dev@nongnu.org, m_ihwan@yahoo.com, m_nasxxx@yahoo.co.id, m.evans@pnl.gov, m.rafli@gmail.com, mage_geffen@yahoo.com, magnus@dps.centrin.net.id, mahntunmya@gmail.com, mail@biz.net.id, majinbhu@googlegroups.com, majuanugrah@cbn.net.id, makassar@bisnis.co.id, malaysia-online@yahoogroups.com, manager@webkreasi.com, marangkir@yahoo.com, marco_hardy68@yahoo.com, marco@aol.com, mardauspurba@yahoo.com, margy_ann@yahoo.com Content-Type: multipart/alternative; boundary=00504502d2b05955c004676c8001 X-Barracuda-Connect: mail-ew0-f178.google.com[209.85.219.178] X-Barracuda-Start-Time: 1239615639 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23047 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --00504502d2b05955c004676c8001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Anda ingin belajar Investasi Saham dan Option dengan harga terjangkau? Bagaimana membeli saham ratusan juta dengan uang Rp 10 jutaan Bagaimana memperoleh keuntungan walau saham sedang naik, turun atau diam sekalipun Bagaimana memperoleh uang sewa dari saham yang kita miliki HADIRI PREVIEW SEMINAR KAMI *GRATIS !* DAFTAR SEGERA, TEMPAT TERBATAS YULI ( 0813 1414 3978 ) YATI ( 0813 8274 6555 ) JADWAL ACARA Sabtu, 18 April 2009 Sesi I : 10.00 sd 12.00 Sesi II: 14.00 sd 16.00 TEMPAT Taman Palem , Ruko Fantasy Blok Z No. 28 Cengkareng, Jakarta Barat 11730 *021 5596 0195* Yang kami berikan: - Pelatihan mencakup teori dan praktek, dijamin bisa - Diajarkan oleh investor yang berpengalaman lebih dari 10 tahun di bursa saham INVESTASI ANDA AMAN KARENA DIJAMIN OLEH PEMERINTAH USA SEBESAR US$ 25 JUTA PER ACCOUNT Investasi mudah: - Tidak perlu kemampuan khusus untuk berinvestasi di saham dan option - Siapapun bisa, cocok bagi pengusaha, ibu rumah tangga, karyawan dll... JANGAN PERCAYAKAN INVESTASI ANDA KE ORANG LAIN, BELAJARLAH SENDIRI KARENA INVESTASI ITU SEDERHANA --00504502d2b05955c004676c8001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Anda ingin belajar Investasi Saham = dan Option dengan harga terjangkau?

Bagaimana membeli saham ratusan juta den= gan uang Rp 10 jutaan
Bagaimana memperoleh keuntungan walau sa= ham sedang naik, turun atau diam sekalipun
Bagaimana memperoleh uang sewa dari saha= m yang kita miliki

HADIRI PREVIEW SEMINAR KAMI

GRATIS !

DAFTAR SEGERA, TEMPAT TERBATAS YULI ( 0813 1414 3978 )
YATI ( 0813 8274 6555 )



JADWAL ACARA

Sabtu, 18 April 2009

Sesi I : 10.00 sd 12.00
Sesi II: 14.00 sd 16.00



TEMPAT

Taman Palem , Ruko Fantasy Blok Z No. 28=
Cengkareng, Jakarta Barat 11730 021 5596 0195


Yang kami berikan:
- Pelatihan mencakup teori dan praktek, = dijamin bisa
- Diajarkan oleh investor yang berpengal= aman lebih dari 10 tahun di bursa saham



INVESTASI ANDA AMAN KARENA DIJAMIN OLEH PEMERINTAH USA SEBESAR US$ 25 JUTA PER ACCOUNT



Investasi mudah:
- Tidak perlu kemampuan khusus untuk berinvestasi di saham dan option
- Siapapun bisa, cocok bagi pengusaha, i= bu rumah tangga, karyawan dll...




JANGAN PERCAYAKAN INVESTASI ANDA KE ORAN= G LAIN, BELAJARLAH SENDIRI KARENA INVESTASI ITU SEDERHANA

=A0

--00504502d2b05955c004676c8001-- From cantonhotel.org12@gmail.com Mon Apr 13 05:49:48 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3DAnSP4101285 for ; Mon, 13 Apr 2009 05:49:38 -0500 X-ASG-Debug-ID: 1239619747-539102820000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ew0-f178.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A758320D1D3 for ; Mon, 13 Apr 2009 03:49:08 -0700 (PDT) Received: from mail-ew0-f178.google.com (mail-ew0-f178.google.com [209.85.219.178]) by cuda.sgi.com with ESMTP id ZaU3EUwdA17Ifkfo for ; Mon, 13 Apr 2009 03:49:08 -0700 (PDT) Received: by ewy26 with SMTP id 26so487254ewy.20 for ; Mon, 13 Apr 2009 03:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=OfguhiB/DaiHZynHWwajpLkVTGJclXWYgqpAVMn5l8E=; b=VQAOJQJNPF7oJ6/NntFKGGf7gve3mfQ1+QE3tvPxkJ/muP5jedB7R1AchV73QlwjAh VH7oTByFDBXzN3miJHFh5gZ/VVmLTeniQx1Ph1dtKsg9AzrRfzm2HEH6yX8Kq3RT+63j /ERhfFlP1+kTSmIXv+c7eVGVrd2LpbxVl9P+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=T43UPkNaBbY3Gv5P2ystQTPLOfogwNWIeuSX63RHMsz1JphsM9x3xibjuGy715/K/H USrrFLGS7TVohDc77rGmwuHjOopmjJOBq9IYdh0LZjmx+7dDLKOeewmkmbzms/jQXPnK 8NrV+LkNNEEtQdZqnzmsQNslwzBnTP+fJU4Ko= MIME-Version: 1.0 Received: by 10.216.13.194 with SMTP id b44mr1485483web.139.1239618152064; Mon, 13 Apr 2009 03:22:32 -0700 (PDT) Date: Mon, 13 Apr 2009 18:22:32 +0800 Message-ID: <7891dfd90904130322u516b59d4q276e9f9d65d48d39@mail.gmail.com> X-ASG-Orig-Subj: Canton hotels are on sale here! 13th April, 2009 Subject: Canton hotels are on sale here! 13th April, 2009 From: kitty leung To: info@woodworkingb2b.com, info@worcell.com, info@workpermitsolutions.co.uk, info@steenbali.co.uk, info@worldchemcn.com, jackliu84@gmail.com, info@worlddidac.org, info@WorldFamousSuperStarProductions.com, goldenstar6066@yahoo.com, media.relations@endemol.com, time.to.meet.your.connect@gmail.com, info@worldhalalfood.com, Info@WorldWideTradeServices.Net, Webmaster@WorldWideTradeServices.Net, info@worthy.ca, info@wsphl.com, info@ws-sh.com, info@wtia.com.au, jpeterson@csi.edu, cmit.enquiries@csiro.au, ASKWHENG@ntu.edu.sg, info@wwesolutions.com, info@wyless.com, info@wtcak.org, inoue-y@nhk.jn.co.jp, michishita-s@nhk-jn.co.jp, mark@marktucker.net, info@wyomingfilm.org, hahsa@unimelb.edu.au, rdavidson@conferenceworld.com.au, info@xcyaan.com, info@xeico.com, anglexinyuan@hotmail.com, info@xeltek.com, sgrafika@mt.net, michael.pk@cytanet.com.cy, kodi@kodi.com, marco@cytanet.com.cy, ling@techonomy.se, info@xgmjt.com, info@xiadaifang.com, info@xiam.nl, info@xiamenguide.cn, info@chinesemol.com, sales@gaike.com, info@xianden.com, buy@mail.china.cn, info@xichun-buzzer.com, xyj@xichun-buzzer.com, info@xicomlogistics.com, abraham@Ja-tethrtologles.to, dve@mento.no, ghader@polfzco.com, avi17403@emirates.net.ae, gulfco1@emirates.net.ae, info@xierkangtai.com, jxmedicine@yahoo.com.cn, info@xiermei-f.com, mxq0296@163.com, info@xindelw.com, libbybecky@hotmail.com, info@xinhaityre.com, info@xinlongnw.com, info@xinzehao.com, info@xmgiftshow.com, xmgiftshow@yahoo.com, info@Ariketravel.com, ariketravel02@yahoo.com, info@xmlinyo.com, info@xsinvests.gov.cn, info@xtremepowersports.com, info@xycase.com, xycase@hotmail.com, info@xyvehicle.com, info@yaleconsultant.com, music@voize.my, info@paneagle.com.my, Info@Yangyangsolar.com, info@yanisilver.com, info@yarmax.com, info@yasn.com.cn, poolong@streamyx.com, yasn_intl@163.com, info@yastextile.com, info@yathreb-marble.com, info@ydjie.net, zhiwang@yahoo.cn, zhiwang@wz.zj.cn, Info@yecherng.com, mailbox@yecherng.com, inquiry@yecherng.com, vietnam@ambexpo.com, yatesch@atomic.net, information@nsf-isr.org, info@yeksanpazarlama.com, info@yhak.org, info@yhdingsheng.com, berg@vip.sina.com, Marketing@zjport.gov.cn, info@yingangmotorcycle.com, kevin7901@gmail.com, Kevin7911@hotmail.com, chinaexported@gmail.com, liangfudan@yahoo.com.cn, mayyly@yahoo.co.in, LYSchina@188.com, info@yitaish.com, info@yj-plastic.com, info@yjt.cn, info@ykharvest.com, info@yki.se, info@yl-wiremesh.com, info@yogoimports.com, info@youhaolu.com, info@yourname.com, dajoint@dajoint.com.hk, choushumin@gmail.com, eddiewhymart@hotmail.com, frenemma@yahoo.com, hnstyle360@yahoo.com.cn, info@professionalaccess.com, intl@orcad.com, missouritrading@gmail.com, smcsakura@myanmar.com.mm, sales@noveltism.com, technicalsupport@tradeservice.com, info@yoursourcingconnection.com, info@your-website.com, hello@nuviotemplates.com, info@yscal.org, info@yukkee.com.hk, info@yumetals.com, info@ywguoli.com, topdairyexport@yahoo.com, contact@zitic.com.cn, info@yx-gas.com, info@yypacking.com, silvialee8@hotmail.com, deary_26@hotmail.com, yaolh2002@hotmail.com, betseyliugd@hotmail.com, info@zamanitrading.com, ir@gmail.com, info@zapadpribor.com, info@zarasplanet.co.uk, info@nu-car.com, info@southfares.com, info@zbpit.com, zbpit@yahoo.cn, info@zealtop.com, info@zeetex.com, info@zenriverllc.com, info@zentis.de, nyfb@hkstar.com, roukes@caltech.edu, info@indonesia.de, coney@ic24.net, info@zeropointsystems.at, info@zgztrade.com, info@zhendajz.com, info@zhenghe.net.my, info@zhengshuntyre.com, info@zh-warmth.com, info@zhyqsensor.com, zhyqsensor@yahoo.com, info@zimtrade.co.zw, info@byo.zimtrade.co.zw, sebastien_dumont@hiperdistafrica.com, info@zimzum.co.kr, info@zjgmetal.com, jiancai365@126.com, info@zonvan.com, info@zoosa.co.uk, kbharv@hotmail.com, info@zsmotor.cn, info@zonesun-motor.com.cn, owen_power@hotmail.com, arthurbrother2008@yahoo.com, info@zwf6.com, info@zxlamps.com, info_advance@188.com, info_chantilly@dolce.com, info_globeunion@yahoo.co.uk, info_hiroshisunoiljp@yahoo.co, info_umbrella@yahoo.com.cn, info07@EventTrip.com, info1@qjiang.com.cn, info2@qjiang.com.cn, info3@qjiang.com.cn, xfs@oss.sgi.com, info1@schuetz.net Content-Type: multipart/alternative; boundary=0016e64c1bbe9c6ef304676d1715 X-Barracuda-Connect: mail-ew0-f178.google.com[209.85.219.178] X-Barracuda-Start-Time: 1239619748 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4835 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23051 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0016e64c1bbe9c6ef304676d1715 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear MR. /MS, Thank you for looking at this mail. We are a professional work team for your hotel reservation. We have large quantities of hotels in Guangzhou with low price and good service. Give you the excellent and huge discount rate hotels during canton fair and the other times. You can easy book a valuable hotel anytime you want by our online reserving service during. Your sincerely, Kitty Leung Website: http://www.cantonhotel.org Email: cantonhotel.org@gmail.com FAX: 86-20-34792925 MSN: cantonhotel.org@hotmail.com ICQ: 498829004 Skype: cantonhotel.org --0016e64c1bbe9c6ef304676d1715 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear MR. /MS,

Thank you for looki= ng at this mail. We are a professional work team for your hotel reservation= . We have large quantities of hotels in Guangzhou with low price and good s= ervice. Give you the excellent and huge discount rate hotels during canton = fair and the other times. You can easy book a valuable hotel anytime you wa= nt by our online reserving service during.

Your sincerely,

Kitty Leung<= /span>

=A0

Website: http://= www.cantonhotel.org

Email: c= antonhotel.org@gmail.com <= /font>

FAX: 86-20-34792925=

MSN: cantonhotel.org@hot= mail.com

ICQ: 498829004

Skype: cantonhotel.org

--0016e64c1bbe9c6ef304676d1715-- From BATV+13135baec0e70ef2caf4+2059+infradead.org+hch@bombadil.srs.infradead.org Mon Apr 13 08:50:19 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3DDnsix110407 for ; Mon, 13 Apr 2009 08:50:09 -0500 X-ASG-Debug-ID: 1239630577-02f200be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5093520D9C5 for ; Mon, 13 Apr 2009 06:49:37 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id eVCpH3jgLs1FXfIR for ; Mon, 13 Apr 2009 06:49:37 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LtMXY-0007qK-JV; Mon, 13 Apr 2009 13:49:36 +0000 Date: Mon, 13 Apr 2009 09:49:36 -0400 From: Christoph Hellwig To: "Josef 'Jeff' Sipek" Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/2] Misc xfstests patches Subject: Re: [PATCH 0/2] Misc xfstests patches Message-ID: <20090413134936.GA18708@infradead.org> References: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1238536234-26969-1-git-send-email-jsipek@eecs.umich.edu> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239630577 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Mar 31, 2009 at 05:50:32PM -0400, Josef 'Jeff' Sipek wrote: > Just two simple patches to clean things up a little bit. I've sucked the two patches into the xfstests-dev tree, thanks! From BATV+13135baec0e70ef2caf4+2059+infradead.org+hch@bombadil.srs.infradead.org Mon Apr 13 08:59:17 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_53 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3DDwqiW110804 for ; Mon, 13 Apr 2009 08:59:07 -0500 X-ASG-Debug-ID: 1239631115-2f06013b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8A0CD1CB87ED; Mon, 13 Apr 2009 06:58:35 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 8MVoDlcVmdWHvJFd; Mon, 13 Apr 2009 06:58:35 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LtMgE-0001IE-Uo; Mon, 13 Apr 2009 13:58:34 +0000 Date: Mon, 13 Apr 2009 09:58:34 -0400 From: Christoph Hellwig To: Felix Blyakher Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfstests: fix async io error handling in fsx Subject: Re: [PATCH] xfstests: fix async io error handling in fsx Message-ID: <20090413135834.GA3196@infradead.org> References: <1239031576-26279-1-git-send-email-felixb@sgi.com> <20090406163331.GA22240@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090406163331.GA22240@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239631115 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Apr 06, 2009 at 12:33:31PM -0400, Christoph Hellwig wrote: > On Mon, Apr 06, 2009 at 10:26:16AM -0500, Felix Blyakher wrote: > > The result of async io returned in the event.res in addition > > to the number of bytes read/written provides negated error > > number. The broken libaio defines event.res as unsigned > > while the same structure in the kernel defines it as signed. > > The kernel indeed treats it as signed, and returns the > > negated error number. Till libaio is fixed we provide > > the signed long temp var. > > Also set errno for each error condition in aio_rw, as the > > caller is not aio aware and expects ret(-1)+errno by the > > traditional libc convention. > > Looks good. > > Reviewed-by: Christoph Hellwig Do you plan to commit this? Otherwise I'll just suck it into the xfstests-dev tree. From trx.lists@gmail.com Mon Apr 13 09:13:54 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.4 required=5.0 tests=BAYES_00,HTML_MESSAGE, LOCALPART_IN_SUBJECT autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3DEDXxj111655 for ; Mon, 13 Apr 2009 09:13:44 -0500 X-ASG-Debug-ID: 1239631994-02f501210000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ew0-f158.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EA6BC20DC2A for ; Mon, 13 Apr 2009 07:13:15 -0700 (PDT) Received: from mail-ew0-f158.google.com (mail-ew0-f158.google.com [209.85.219.158]) by cuda.sgi.com with ESMTP id i82hJUEu98TTYtwV for ; Mon, 13 Apr 2009 07:13:15 -0700 (PDT) Received: by ewy2 with SMTP id 2so2505844ewy.20 for ; Mon, 13 Apr 2009 07:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=+LuTODc8w3jx2VveiXR9b0OWvAvGigJZCBRntKh5VnQ=; b=KxKN5QxoG+J57c5YEb/2esmFefQO5OX48vSW8ODpXMbEO1+xVea58qk1206SiDo4hY 9JJnk55y2L0K2WvoJAiRfJfWZjktm11SZlZW9wUbU5uM3miRf0GScA5gHjxZK7+zlfJT N+tBOtgLDA88GmE4ezByWRcEqKFuijviGMPN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Rs15+5OJCNr5+VDA0JAAIZ/ktuq41fATpDuCDW/6vFCrsj30bUgjHwghoi77wrCXBB y7NN/FRQ9E/LcL7B5mPb/RTWHodORRmh5rEIPsreF+gy5/CeXK3h0QpNsgMMlCo/3Kzd gAvDn3ZwnbD6pTxOPaIgtJCHOIGlBhxfqWxMY= MIME-Version: 1.0 Received: by 10.210.91.17 with SMTP id o17mr1990236ebb.92.1239631994260; Mon, 13 Apr 2009 07:13:14 -0700 (PDT) Date: Mon, 13 Apr 2009 16:13:14 +0200 Message-ID: X-ASG-Orig-Subj: xfs - fixing wrong xfs size Subject: xfs - fixing wrong xfs size From: Nebojsa Trpkovic To: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=0015174c3e9eab8dac04677050a7 X-Barracuda-Connect: mail-ew0-f158.google.com[209.85.219.158] X-Barracuda-Start-Time: 1239631995 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.02 X-Barracuda-Spam-Status: No, SCORE=-1.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE, LOCALPART_IN_SUBJECT, LOCALPART_IN_SUBJECT_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23065 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 LOCALPART_IN_SUBJECT Local part of To: address appears in Subject 0.00 HTML_MESSAGE BODY: HTML included in message 1.00 LOCALPART_IN_SUBJECT_2 Local part of To: address appears in Subject X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0015174c3e9eab8dac04677050a7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hello. I had problem with raid5 on my system. after recovering of the array, I can not mount XFS that resides on it. I've run xfs_check and xfs_repair (which fixed some errors) and now I can run them all day long without any errors. but, when I try to mount that partition, I get: mount: /dev/md0: can't read superblock and there's Filesystem "md0": Disabling barriers, not supported by the underlying device attempt to access beyond end of device md0: rw=0, want=123024384, limit=123023488 I/O error in filesystem ("md0") meta-data dev md0 block 0x75533f8 ("xfs_read_buf") error 5 buf count 4096 XFS: size check 2 failed in the dmesg. is there any way to "fix" this wrong size of XFS ? thx. --0015174c3e9eab8dac04677050a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hello.

I had problem with raid5 on my system.
after recovering o= f the array, I can not mount XFS that resides on it.
I've run xfs_ch= eck and xfs_repair (which fixed some errors) and now I can run them all day= long without any errors.

but, when I try to mount that partition, I get:

mount: /dev/md0=
: can't read superblock

and there's 

Filesystem "md0": Disabling barriers=
, not supported by the underlying device

attempt to access beyond end of device
md0: rw=3D0, want=3D123024384, li=
mit=3D123023488
I/O error in filesystem ("md0") meta-data dev =
md0 block 0x75533f8       ("xfs_read_buf") error 5 buf count 4096=


XFS: size check 2 failed


in the dmesg.


is there any= way to "fix" this wrong size of XFS ?

thx.


--0015174c3e9eab8dac04677050a7-- From sandeen@sandeen.net Mon Apr 13 10:03:03 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3DF2h7N115147 for ; Mon, 13 Apr 2009 10:02:53 -0500 X-ASG-Debug-ID: 1239634945-377a01ca0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 56E191CB8819 for ; Mon, 13 Apr 2009 08:02:26 -0700 (PDT) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id KajmLPIAhBunDsgB for ; Mon, 13 Apr 2009 08:02:26 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 974AAAA60C0; Mon, 13 Apr 2009 10:02:22 -0500 (CDT) Message-ID: <49E353FD.5060207@sandeen.net> Date: Mon, 13 Apr 2009 10:02:21 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nebojsa Trpkovic CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs - fixing wrong xfs size Subject: Re: xfs - fixing wrong xfs size References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1239634946 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23069 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Nebojsa Trpkovic wrote: > hello. > > I had problem with raid5 on my system. > after recovering of the array, I can not mount XFS that resides on it. > I've run xfs_check and xfs_repair (which fixed some errors) and now I > can run them all day long without any errors. > > but, when I try to mount that partition, I get: > > mount: /dev/md0: can't read superblock > > > and there's > > Filesystem "md0": Disabling barriers, not supported by the underlying device > > attempt to access beyond end of device > md0: rw=0, want=123024384, limit=123023488 > I/O error in filesystem ("md0") meta-data dev md0 block 0x75533f8 ("xfs_read_buf") error 5 buf count 4096 > > XFS: size check 2 failed So, the superblock says that the fs is 896 1k-blocks longer than the device actually is. > in the dmesg. > > > is there any way to "fix" this wrong size of XFS ? hard to say, almost certainly sounds like an md problem; is there a chance that your raid recovery led to a device which is somehow smaller than it started? You could change the superblock block-count value, but I'm guessing that something else has gone wrong. It might be useful to know what errors xfs_repair found. -Eric From trx.lists@gmail.com Mon Apr 13 11:34:55 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.9 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, SUBJ_FORWARDED autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3DGYZix120022 for ; Mon, 13 Apr 2009 11:34:45 -0500 X-ASG-Debug-ID: 1239640436-030703920000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ew0-f158.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B1C4920DF81 for ; Mon, 13 Apr 2009 09:33:56 -0700 (PDT) Received: from mail-ew0-f158.google.com (mail-ew0-f158.google.com [209.85.219.158]) by cuda.sgi.com with ESMTP id L4qav8Wf9f6CdMHo for ; Mon, 13 Apr 2009 09:33:56 -0700 (PDT) Received: by ewy2 with SMTP id 2so2596952ewy.20 for ; Mon, 13 Apr 2009 09:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=uNgMi+AP9UJRdedBDeXjixSgWm+11xkBsx62Oidh1uA=; b=cChAqHwdt52t4iej6XNJz1A+VN5jsCvfYMoIWxGMROc6tf1ONfJYYxhiDYYO9KfyBY 6QZnWSs+SmT+MFNsu0BVzpfFhI0xTBqGALzWUkXV0HGCkppq4bbEYyfbrvoKJtAZPdxo uQPFKp9iyB70it5/ZFYN0FRSkCyCrWojRWVqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=QFXx4WCj3dHHtP/+UjgThd+dlVwkwi+HgoQSLtpLTm3OkMUd/BnImsFYb4sP1T799r sQ+oemJFJBxzf9HkrL6BkDp95plYgwOCgMrgt4Pn3+jMcs8CdhcOi4rqVgo0dKEh8VfO uihgXk7Tf+Y9LcsTr158d6hXnnkdndXRxY6bM= MIME-Version: 1.0 Received: by 10.210.89.4 with SMTP id m4mr4768036ebb.95.1239640436042; Mon, 13 Apr 2009 09:33:56 -0700 (PDT) In-Reply-To: References: <49E353FD.5060207@sandeen.net> Date: Mon, 13 Apr 2009 18:33:55 +0200 Message-ID: X-ASG-Orig-Subj: Fwd: xfs - fixing wrong xfs size Subject: Fwd: xfs - fixing wrong xfs size From: Nebojsa Trpkovic To: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=0015174bde84d709a9046772475a X-Barracuda-Connect: mail-ew0-f158.google.com[209.85.219.158] X-Barracuda-Start-Time: 1239640457 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0006 1.0000 -2.0174 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23075 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0015174bde84d709a9046772475a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Apr 13, 2009 at 5:02 PM, Eric Sandeen wrote: > Nebojsa Trpkovic wrote: > > hello. > > > > I had problem with raid5 on my system. > > after recovering of the array, I can not mount XFS that resides on it. > > I've run xfs_check and xfs_repair (which fixed some errors) and now I > > can run them all day long without any errors. > > > > but, when I try to mount that partition, I get: > > > > mount: /dev/md0: can't read superblock > > > > > > and there's > > > > Filesystem "md0": Disabling barriers, not supported by the underlying > device > > > > attempt to access beyond end of device > > md0: rw=0, want=123024384, limit=123023488 > > I/O error in filesystem ("md0") meta-data dev md0 block 0x75533f8 > > ("xfs_read_buf") error 5 buf count 4096 > > > > XFS: size check 2 failed > > So, the superblock says that the fs is 896 1k-blocks longer than the > device actually is. > > > in the dmesg. > > > > > > is there any way to "fix" this wrong size of XFS ? > > hard to say, almost certainly sounds like an md problem; is there a > chance that your raid recovery led to a device which is somehow smaller > than it started? You could change the superblock block-count value, but > I'm guessing that something else has gone wrong. > > It might be useful to know what errors xfs_repair found. > > -Eric > thx for quick reply. yes, I definitely had md problem - my raid5 made of 6 drives connected to ICH9R and 2 drives connected to the masterpeace of hardware called JMicron fell apart when later one just stopped working out of nowhere. after reboot, JMicron worked well, but raid was out of sync with 2 members failed. I've zeroed superblocks of raid partitions and created new one with "assume-clear". partition tables stayed intact - I had no need to change anything in them. that worked fine with /dev/md1 wich had reiserfs: after long and slow reiserfs --rebuild-tree I'm able to access all files on that partition. unforutuately, I have no way to mount xfs partition although xfs_check and xfs_repair give no errors (I had to run xfs_repair -L /dev/md0 to get in this error-free situation). how can I set superblock block-count value (now I have realy nothing to loose - the only other option is to give up of that data) ? --0015174bde84d709a9046772475a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 13, 2009 at 5:02 PM, Eric Sandeen <sandeen@sand= een.net> wrote:
Nebojsa Trpkovic wrote:
> hello.
>
> I had problem with raid5 on my system.
> after recovering of the array, I can not mount XFS that resides on it.=
> I've run xfs_check and xfs_repair (which fixed some errors) and no= w I
> can run them all day long without any errors.
>
> but, when I try to mount that partition, I get:
>
> mount: /dev/md0: can't read superblock
>
>
> and there's
>
> Filesystem "md0": Disabling barriers, not supported by the u= nderlying device
>
> attempt to access beyond end of device
> md0: rw=3D0, want=3D123024384, limit=3D123023488
> I/O error in filesystem ("md0") meta-data dev md0 block 0x75= 533f8

=A0 =A0 =A0 ("xfs_read_buf") error 5 buf count 4096
>
> XFS: size check 2 failed

So, the superblock says that the fs is 896 1k-blocks longer than the<= br> device actually is.

> in the dmesg.
>
>
> is there any way to "fix" this wrong size of XFS ?

hard to say, almost certainly sounds like an md problem; is there a chance that your raid recovery led to a device which is somehow smaller
than it started? =A0You could change the superblock block-count value, but<= br> I'm guessing that something else has gone wrong.

It might be useful to know what errors xfs_repair found.

-Eric


thx for quick reply.

y= es, I definitely had md problem - my raid5 made of 6 drives connected to IC= H9R and 2 drives connected to the masterpeace of hardware called JMicron fe= ll apart when later one just stopped working out of nowhere. after reboot, = JMicron worked well, but raid was out of sync with 2 members failed. I'= ve zeroed superblocks of raid partitions and created new one with "ass= ume-clear". partition tables stayed intact - I had no need to change a= nything in them. that worked fine with /dev/md1 wich had reiserfs: after lo= ng and slow reiserfs --rebuild-tree I'm able to access all files on tha= t partition. unforutuately, I have no way to mount xfs partition although x= fs_check and xfs_repair give no errors (I had to run xfs_repair -L /dev/md0= to get in this error-free situation).

how can I set superblock block-count value (now I have realy nothing to= loose - the only other option is to give up of that data) ?



--0015174bde84d709a9046772475a-- From stuart.menefy@st.com Mon Apr 13 12:43:00 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3DHgdZv123409 for ; Mon, 13 Apr 2009 12:42:50 -0500 X-ASG-Debug-ID: 1239644537-145e02f10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from eu1sys200aog111.obsmtp.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D650820E6BE for ; Mon, 13 Apr 2009 10:42:17 -0700 (PDT) Received: from eu1sys200aog111.obsmtp.com (eu1sys200aog111.obsmtp.com [207.126.144.131]) by cuda.sgi.com with ESMTP id IdM0ikBDp2RNKBvb for ; Mon, 13 Apr 2009 10:42:17 -0700 (PDT) Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob111.postini.com ([207.126.147.11]) with SMTP ID DSNKSeN5eMDfS0pAy2KQcl0yO+oFSeKRJmYi@postini.com; Mon, 13 Apr 2009 17:42:18 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 94215DA4B for ; Mon, 13 Apr 2009 17:41:01 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 573DC4C3E9 for ; Mon, 13 Apr 2009 17:42:11 +0000 (GMT) Received: from adelie.bri.st.com (adelie.bri.st.com [164.129.14.72]) by mail1.bri.st.com (MOS 3.8.7a) with ESMTP id CLM70355 (AUTH stuart); Mon, 13 Apr 2009 18:42:10 +0100 (BST) Message-ID: <49E37972.1070101@st.com> Date: Mon, 13 Apr 2009 18:42:10 +0100 From: Stuart MENEFY User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Help debugging a use after free Subject: Help debugging a use after free X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: eu1sys200aog111.obsmtp.com[207.126.144.131] X-Barracuda-Start-Time: 1239644541 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23079 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Folks For the last few days I've been trying to debug an apparent use after free in XFS code. This is in a 2.6.23.17 kernel on an SH4 processor, so this could easily be an XFS problem which has already been solved, or an architecture problem. This started because I've been trying to work around the D-cache aliasing problems which the SH4 suffers from because of XFS's use of vmap, so its also possible this is an obscure aliasing problem. I've also been unable to reproduce it on an x86_64, albeit with a slightly later kernel. The problem occurs when running a loop which is essentially: mount /dev/sda1 /mnt bonnie++ -u root -f -s0 -n16:1024:1024 -b -d /mnt umount /mnt on an otherwise clean partition, and usually takes at least 24 hours to appear. The problem only occurs with SLAB poisoning enabled, and results in a misaligned access because the poison value when treated as a pointer is an illegal misaligned: Unaligned kernel access on behalf of "bonnie++" pid=22419 pc=0x841a6c6c ins=0x8433 Pid : 22419, Comm: bonnie++ PC is at xfs_trans_unlocked_item+0xc/0x60 PC : 841a6c6c SP : 87f29d3c SR : 40008000 TEA : 00402ebe Not tainted R0 : 00000000 R1 : 841a6c60 R2 : 87f28000 R3 : 00000001 R4 : 6b6b6b6b R5 : 6b6b6b6b R6 : 843342ac R7 : 840139c0 R8 : 6b6b6b6b R9 : 6b6b6b6b R10 : 878cb000 R11 : 8452eb8c R12 : 00003255 R13 : 00000625 R14 : 87f29d4c MACH: 00000000 MACL: 0df75800 GBR : 297f9658 PR : 84189d20 Call trace: [<84189d20>] xfs_iunlock+0x60/0xc0 [<841915da>] xfs_inode_item_push+0x1a/0x40 [<841a6ff4>] xfs_trans_push_ail+0x1b4/0x240 [<841971b6>] xlog_grant_push_ail+0xf6/0x180 [<8419961c>] xfs_log_reserve+0x3c/0xc0 [<841a540a>] xfs_trans_reserve+0x8a/0x220 [<8418d6f0>] xfs_itruncate_finish+0x170/0x420 [<841a7de0>] xfs_trans_ihold+0x0/0x20 [<841a7de0>] xfs_trans_ihold+0x0/0x20 [<841a7e60>] xfs_trans_ijoin+0x0/0xa0 [<841b112a>] xfs_inactive+0x3ea/0x500 [<84189da0>] xfs_ilock+0x0/0xe0 [<841bf75c>] xfs_fs_clear_inode+0x3c/0xa0 [<843379a0>] _spin_unlock+0x0/0x60 [<840818da>] clear_inode+0x5a/0x140 [<84081a92>] generic_delete_inode+0xd2/0x120 [<84081bc6>] generic_drop_inode+0xe6/0x1c0 [<84080e2e>] iput+0x4e/0x80 [<840764ba>] do_unlinkat+0xfa/0x1a0 [<8408fdba>] do_fsync+0x7a/0xe0 [<8408fe40>] __do_fsync+0x20/0x60 [<8407656e>] sys_unlink+0xe/0x20 [<84076560>] sys_unlink+0x0/0x20 [<840088f8>] syscall_call+0xa/0xe (Note that due to the way backtrace is implemented on SH architectures there are spurious values in this backtrace, so it is probably safe to ignore any entries of the form FN+0x0.) The problem is caused by the "xfs_inode_t" which is passed into xfs_iunlock() having already been freed at the SLAB level. Putting some additional tracing code into the free path, this structure is being freed by xfs_inode_item_destroy(), which is called from from xfs_idestroy() which is called from xfs_ireclaim(). In between the free and use there appears to be some disk activity, as I see an allocate from the SCSI layer, plus a few other kmalloc and kfree's. Running with XFS_DEBUG enabled hasn't shown any problems, and still failed in the same way. So, does this sound like a problem which has been seen before? Alternatively can anyone suggest what would normally prevent this happening, and I can look into that (although I know next to nothing about the guts of the XFS code, so please don't be afraid to state the obvious!). Or any other suggestions welcome. Stuart From felixb@sgi.com Mon Apr 13 16:16:54 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3DLGXrl132487 for ; Mon, 13 Apr 2009 16:16:44 -0500 Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by relay3.corp.sgi.com (Postfix) with ESMTP id E4C9FAC01A for ; Mon, 13 Apr 2009 14:16:16 -0700 (PDT) Received: by attica.americas.sgi.com (Postfix, from userid 29043) id A986BA24F540; Mon, 13 Apr 2009 16:09:39 -0500 (CDT) Date: Mon, 13 Apr 2009 16:09:39 -0500 To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.30-rc2 User-Agent: Heirloom mailx 12.2 01/07/07 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20090413210939.A986BA24F540@attica.americas.sgi.com> From: felixb@sgi.com (Felix Blyakher) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean The following changes since commit 62b8e680e61d3f48f2a12ee248ca03ea8f376926: David Howells (1): MN10300: Kill MN10300's own profiling Kconfig are available in the git repository at: git://oss.sgi.com/xfs/xfs for-linus Dave Chinner (9): xfs: validate log feature fields correctly xfs: fix double free of inode xfs: prevent unwritten extent conversion from blocking I/O completion xfs: inform the xfsaild of the push target before sleeping xfs: use xfs_sync_inodes() for device flushing xfs: make inode flush at ENOSPC synchronous xfs: block callers of xfs_flush_inodes() correctly xfs: flush delayed allcoation blocks on ENOSPC in create xfs: remove xfs_flush_space Felix Blyakher (1): Merge branch 'master' into for-linus fs/xfs/linux-2.6/xfs_aops.c | 38 +++++++++++--------- fs/xfs/linux-2.6/xfs_aops.h | 1 + fs/xfs/linux-2.6/xfs_buf.c | 9 +++++ fs/xfs/linux-2.6/xfs_fs_subr.c | 14 ++++---- fs/xfs/linux-2.6/xfs_lrw.c | 18 +++++++++- fs/xfs/linux-2.6/xfs_sync.c | 78 +++++++++++++++++----------------------- fs/xfs/linux-2.6/xfs_sync.h | 9 +++-- fs/xfs/xfs_iget.c | 23 +++++++----- fs/xfs/xfs_iomap.c | 61 ++++++++----------------------- fs/xfs/xfs_iomap.h | 3 +- fs/xfs/xfs_log.c | 78 +++++++++++++++++++++++++--------------- fs/xfs/xfs_mount.h | 2 +- fs/xfs/xfs_vnodeops.c | 7 ++++ 13 files changed, 180 insertions(+), 161 deletions(-) From sandeen@sandeen.net Mon Apr 13 16:49:17 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3DLmvt3133886 for ; Mon, 13 Apr 2009 16:49:07 -0500 X-ASG-Debug-ID: 1239659419-2573024b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 446CB141AB2F for ; Mon, 13 Apr 2009 14:50:19 -0700 (PDT) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id LZxbzOTlFI3JTD3O for ; Mon, 13 Apr 2009 14:50:19 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 8110FAA60C0; Mon, 13 Apr 2009 16:48:18 -0500 (CDT) Message-ID: <49E3B321.3060605@sandeen.net> Date: Mon, 13 Apr 2009 16:48:17 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Kevin Xu CC: xfscn@googlegroups.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH]fix fbno in xfs_dir2_node_addname_int Subject: Re: [PATCH]fix fbno in xfs_dir2_node_addname_int References: <47E5A982.8010002@gmail.com> In-Reply-To: <47E5A982.8010002@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1239659440 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23096 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Kevin Xu wrote: > if we didn't find a freespace block for our new entry in the current > freeindex block, > return to the first freeindex block and continue to check. > Kevin, you sent this and another patch a while ago, and we had asked for more information in the changelogs, a Signed-off-by: line, and a testcase if at all possible. Any chance that you can provide these things? Thanks, -Eric From knikanth@suse.de Tue Apr 14 06:11:01 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3EBAeVq182391 for ; Tue, 14 Apr 2009 06:10:51 -0500 X-ASG-Debug-ID: 1239707403-62ba02f10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0624D211B2C; Tue, 14 Apr 2009 04:10:03 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id FoEMMjAJvYxVrrBN; Tue, 14 Apr 2009 04:10:03 -0700 (PDT) Received: from Relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 020578640B; Tue, 14 Apr 2009 13:10:03 +0200 (CEST) From: Nikanth Karthikesan Organization: suse.de X-ASG-Orig-Subj: [PATCH 5/6] Handle possible bio_alloc failure in xfs Subject: [PATCH 5/6] Handle possible bio_alloc failure in xfs Date: Tue, 14 Apr 2009 16:36:45 +0530 User-Agent: KMail/1.11.1 (Linux/2.6.27.21-0.1-default; KDE/4.2.1; x86_64; ; ) MIME-Version: 1.0 Content-Disposition: inline To: xfs-masters@oss.sgi.com Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Jens Axboe Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200904141636.45463.knikanth@suse.de> X-Barracuda-Connect: cantor2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1239707424 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23139 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Handle bio_alloc failure in xfs. Signed-off-by: Nikanth Karthikesan --- Index: linux-2.6/fs/xfs/linux-2.6/xfs_buf.c =================================================================== --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_buf.c +++ linux-2.6/fs/xfs/linux-2.6/xfs_buf.c @@ -1196,6 +1196,8 @@ _xfs_buf_ioapply( (XBF_READ|_XBF_PAGE_LOCKED)) && (blocksize >= PAGE_CACHE_SIZE)) { bio = bio_alloc(GFP_NOIO, 1); + if (unlikely(!bio)) + goto out_enomem; bio->bi_bdev = bp->b_target->bt_bdev; bio->bi_sector = sector - (offset >> BBSHIFT); @@ -1217,6 +1219,9 @@ next_chunk: nr_pages = total_nr_pages; bio = bio_alloc(GFP_NOIO, nr_pages); + if (unlikely(!bio)) + goto out_enomem; + bio->bi_bdev = bp->b_target->bt_bdev; bio->bi_sector = sector; bio->bi_end_io = xfs_buf_bio_end_io; @@ -1247,6 +1252,11 @@ submit_io: bio_put(bio); xfs_buf_ioerror(bp, EIO); } + return; + +out_enomem: + xfs_buf_ioerror(bp, ENOMEM); + } int From niemayer@isg.de Tue Apr 14 09:45:04 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3EEiiKl196450 for ; Tue, 14 Apr 2009 09:44:54 -0500 X-ASG-Debug-ID: 1239720244-759f02ad0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.isg.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 564311CBD47D for ; Tue, 14 Apr 2009 07:44:04 -0700 (PDT) Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by cuda.sgi.com with ESMTP id 3M5KHISXz6MCA3ho for ; Tue, 14 Apr 2009 07:44:04 -0700 (PDT) Received: from embargo.is-teledata.com (unknown [192.168.5.53]) by mail.isg.de (Postfix) with ESMTP id C46371AB57D6; Tue, 14 Apr 2009 16:44:01 +0200 (CEST) Message-ID: <49E4A131.5040309@isg.de> Date: Tue, 14 Apr 2009 16:44:01 +0200 From: Peter Niemayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14 MIME-Version: 1.0 Newsgroups: gmane.linux.kernel To: Felix Blyakher Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS support for TRIM / blkdev_issue_discard? Subject: XFS support for TRIM / blkdev_issue_discard? References: <20090331053013.7642414167108@attica.americas.sgi.com> In-Reply-To: <20090331053013.7642414167108@attica.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: rzfoobar.is-asp.com[217.11.194.155] X-Barracuda-Start-Time: 1239720266 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085, BSF_SC0_SA085b X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23153 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 BSF_SC0_SA085 Custom Rule SA085 0.40 BSF_SC0_SA085b Custom Rule SA085b X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dear Felix Blyakher, do you know whether there are plans to support the ATA TRIM command / blkdev_issue_discard() call in XFS for Linux anytime soon? I ask because as someone who is currently benchmarking solid state disks for certain usage scenarios I noticed that other filesystems are starting to support the discarding of unused blocks, which allows to prevent performance-degradation of SSDs during heavy use. (See e.g. http://www.mail-archive.com/cluster-devel@redhat.com/msg03401.html on the GFS2 support for the discard feature, it seems not too hard to implement the support) Amongst other SSDs, we have one in our tests that supports the ATA TRIM command, and I would like to test the benefits of it, even if that requires me to install an early kernel pre-release. (Currently, XFS is our favorite filesystem for several reasons, so it would be great if we could run our TRIM-support-benchmarks using it) Regards, Peter Niemayer From BATV+884bc5685e7843c777ed+2060+infradead.org+hch@bombadil.srs.infradead.org Tue Apr 14 11:23:44 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3EGNITv203656 for ; Tue, 14 Apr 2009 11:23:34 -0500 X-ASG-Debug-ID: 1239726181-6c42039d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F2ABD1CBD7A9; Tue, 14 Apr 2009 09:23:01 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 4wDTZvS4LLslSo0k; Tue, 14 Apr 2009 09:23:01 -0700 (PDT) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LtlPZ-00084T-A6; Tue, 14 Apr 2009 16:23:01 +0000 Date: Tue, 14 Apr 2009 12:23:01 -0400 From: Christoph Hellwig To: Nikanth Karthikesan Cc: xfs-masters@oss.sgi.com, Jens Axboe , linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 5/6] Handle possible bio_alloc failure in xfs Subject: Re: [PATCH 5/6] Handle possible bio_alloc failure in xfs Message-ID: <20090414162301.GA24967@infradead.org> References: <200904141636.45463.knikanth@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904141636.45463.knikanth@suse.de> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1239726181 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Apr 14, 2009 at 04:36:45PM +0530, Nikanth Karthikesan wrote: > Handle bio_alloc failure in xfs. > > Signed-off-by: Nikanth Karthikesan NAK, as already explained by Jens. From felixb@sgi.com Tue Apr 14 13:35:14 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3EIYr1R210584 for ; Tue, 14 Apr 2009 13:35:04 -0500 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id 79AB38F80D7 for ; Tue, 14 Apr 2009 11:34:37 -0700 (PDT) Received: from eagdhcp-232-152.americas.sgi.com (eagdhcp-232-152.americas.sgi.com [128.162.232.152]) by estes.americas.sgi.com (Postfix) with ESMTP id A92837000103; Tue, 14 Apr 2009 13:32:35 -0500 (CDT) Cc: xfs@oss.sgi.com Message-Id: From: Felix Blyakher To: Peter Niemayer In-Reply-To: <49E4A131.5040309@isg.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: XFS support for TRIM / blkdev_issue_discard? Date: Tue, 14 Apr 2009 13:32:35 -0500 References: <20090331053013.7642414167108@attica.americas.sgi.com> <49E4A131.5040309@isg.de> X-Mailer: Apple Mail (2.926) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Apr 14, 2009, at 9:44 AM, Peter Niemayer wrote: > Dear Felix Blyakher, Hi Peter, > do you know whether there are plans to support the ATA TRIM command / > blkdev_issue_discard() call in XFS for Linux anytime soon? This topic was indeed brought up in xfs discussions. Though, we don't have any definite plans on supporting it yet. That doesn't mean that we oppose to it, just the lack of resources at the moment. Your mail will bring it up for discussion again. Stay tuned, Felix > > > I ask because as someone who is currently benchmarking solid state > disks > for certain usage scenarios I noticed that other filesystems are > starting > to support the discarding of unused blocks, which allows to prevent > performance-degradation of SSDs during heavy use. > (See e.g. http://www.mail-archive.com/cluster-devel@redhat.com/msg03401.html > on the GFS2 support for the discard feature, it seems not too hard > to implement the support) > > Amongst other SSDs, we have one in our tests that supports the ATA > TRIM command, > and I would like to test the benefits of it, even if that requires me > to install an early kernel pre-release. > > (Currently, XFS is our favorite filesystem for several reasons, so > it would > be great if we could run our TRIM-support-benchmarks using it) > > Regards, > > Peter Niemayer From cattelan@thebarn.com Tue Apr 14 14:11:13 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3EJAmsS212613 for ; Tue, 14 Apr 2009 14:11:03 -0500 X-ASG-Debug-ID: 1239736334-063d01400000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from slurp.thebarn.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9F4DF141F630 for ; Tue, 14 Apr 2009 12:12:15 -0700 (PDT) Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by cuda.sgi.com with ESMTP id 1mKBXqVg00pXGrb2 for ; Tue, 14 Apr 2009 12:12:15 -0700 (PDT) Received: from Russell-Cattelans-MacBook.local (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.3/8.14.0) with ESMTP id n3EJA4tE015840; Tue, 14 Apr 2009 14:10:05 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <49E4DF8C.4050800@thebarn.com> Date: Tue, 14 Apr 2009 14:10:04 -0500 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Stuart MENEFY CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Help debugging a use after free Subject: Re: Help debugging a use after free References: <49E37972.1070101@st.com> In-Reply-To: <49E37972.1070101@st.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: cattelan-host202.dsl.visi.com[208.42.117.202] X-Barracuda-Start-Time: 1239736356 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.92 X-Barracuda-Spam-Status: No, SCORE=-0.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23172 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stuart MENEFY wrote: > Folks > > For the last few days I've been trying to debug an apparent use > after free in XFS code. This is in a 2.6.23.17 kernel on an SH4 > processor, so this could easily be an XFS problem which has already > been solved, or an architecture problem. This started because I've > been trying to work around the D-cache aliasing problems which the > SH4 suffers from because of XFS's use of vmap, so its also possible > this is an obscure aliasing problem. I've also been unable to > reproduce it on an x86_64, albeit with a slightly later kernel. > > The problem occurs when running a loop which is essentially: mount > /dev/sda1 /mnt bonnie++ -u root -f -s0 -n16:1024:1024 -b -d /mnt > umount /mnt on an otherwise clean partition, and usually takes at > least 24 hours to appear. The problem only occurs with SLAB > poisoning enabled, and results in a misaligned access because the > poison value when treated as a pointer is an illegal misaligned: > > Unaligned kernel access on behalf of "bonnie++" pid=22419 > pc=0x841a6c6c ins=0x8433 Pid : 22419, Comm: bonnie++ PC > is at xfs_trans_unlocked_item+0xc/0x60 PC : 841a6c6c SP : > 87f29d3c SR : 40008000 TEA : 00402ebe Not tainted R0 : > 00000000 R1 : 841a6c60 R2 : 87f28000 R3 : 00000001 R4 : > 6b6b6b6b R5 : 6b6b6b6b R6 : 843342ac R7 : 840139c0 R8 : > 6b6b6b6b R9 : 6b6b6b6b R10 : 878cb000 R11 : 8452eb8c R12 : > 00003255 R13 : 00000625 R14 : 87f29d4c MACH: 00000000 MACL: > 0df75800 GBR : 297f9658 PR : 84189d20 > > Call trace: [<84189d20>] xfs_iunlock+0x60/0xc0 [<841915da>] > xfs_inode_item_push+0x1a/0x40 [<841a6ff4>] > xfs_trans_push_ail+0x1b4/0x240 [<841971b6>] > xlog_grant_push_ail+0xf6/0x180 [<8419961c>] > xfs_log_reserve+0x3c/0xc0 [<841a540a>] xfs_trans_reserve+0x8a/0x220 > [<8418d6f0>] xfs_itruncate_finish+0x170/0x420 [<841a7de0>] > xfs_trans_ihold+0x0/0x20 [<841a7de0>] xfs_trans_ihold+0x0/0x20 > [<841a7e60>] xfs_trans_ijoin+0x0/0xa0 [<841b112a>] > xfs_inactive+0x3ea/0x500 [<84189da0>] xfs_ilock+0x0/0xe0 > [<841bf75c>] xfs_fs_clear_inode+0x3c/0xa0 [<843379a0>] > _spin_unlock+0x0/0x60 [<840818da>] clear_inode+0x5a/0x140 > [<84081a92>] generic_delete_inode+0xd2/0x120 [<84081bc6>] > generic_drop_inode+0xe6/0x1c0 [<84080e2e>] iput+0x4e/0x80 > [<840764ba>] do_unlinkat+0xfa/0x1a0 [<8408fdba>] do_fsync+0x7a/0xe0 > [<8408fe40>] __do_fsync+0x20/0x60 [<8407656e>] sys_unlink+0xe/0x20 > [<84076560>] sys_unlink+0x0/0x20 [<840088f8>] syscall_call+0xa/0xe > > > (Note that due to the way backtrace is implemented on SH > architectures there are spurious values in this backtrace, so it is > probably safe to ignore any entries of the form FN+0x0.) > > The problem is caused by the "xfs_inode_t" which is passed into > xfs_iunlock() having already been freed at the SLAB level. Putting > some additional tracing code into the free path, this structure is > being freed by xfs_inode_item_destroy(), which is called from from > xfs_idestroy() which is called from xfs_ireclaim(). I guess the first question is which thread has actually free'ed the inode? it sounds like a race that seems unlikely unless you are on a multi processor system. I don't know anything about the SH4 architecture but I assume this is a single processor system? If you can instrument actually free that is causing the problem it would be good to print out the actually pid doing the free and as many return addresses that you can, so we can get an idea of the actual call chain. > > In between the free and use there appears to be some disk activity, > as I see an allocate from the SCSI layer, plus a few other kmalloc > and kfree's. > > Running with XFS_DEBUG enabled hasn't shown any problems, and still > failed in the same way. I wouldn't expect XFS_DEBUG to point out anything particularly interesting in this area, but it never hurts to try. > > So, does this sound like a problem which has been seen before? > Alternatively can anyone suggest what would normally prevent this > happening, and I can look into that (although I know next to > nothing about the guts of the XFS code, so please don't be afraid > to state the obvious!). Or any other suggestions welcome. > > Stuart > > _______________________________________________ xfs mailing list > xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ5N+LNRmM+OaGhBgRAn8vAJoCUKDPYWEyZlXs+PgwASpXSfLT9gCfRQja 9TX1Y/ntxb8Ux9pzvg3V0Yg= =2Rcd -----END PGP SIGNATURE----- From bemossedxzyyv@embedmore-talent-2ourworld.cn Tue Apr 14 20:26:43 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_40 autolearn=unavailable version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3F1QMVO239278 for ; Tue, 14 Apr 2009 20:26:33 -0500 X-ASG-Debug-ID: 1239758735-5cd902490002-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from embedmore-talent-2ourworld.cn (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 4415F1CC0061; Tue, 14 Apr 2009 18:26:03 -0700 (PDT) Received: from embedmore-talent-2ourworld.cn (BeaverNet-161.caltech.edu [131.215.220.161]) by cuda.sgi.com with SMTP id JRI3f8XWewfeOtES; Tue, 14 Apr 2009 18:26:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s168111; d=embedmore-talent-2ourworld.cn; h=Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Cc:Subject:Content-Type:Content-Transfer-Encoding; b=QDO1ou7KjGkUkUeaV6KNnFSRNlGFfqLScgV0rPg11LxNKf4IS5ZjduCm2u897doN9Opqtp70bgt7BK4HLU2lyg==; Message-ID: Date: Wed, 15 Apr 2009 02:04:18 +0100 From: "Joseph" User-Agent: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en-us MIME-Version: 1.0 To: "Walter" Cc: "Patrick" X-ASG-Orig-Subj: No time left Subject: No time left Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Barracuda-Connect: BeaverNet-161.caltech.edu[131.215.220.161] X-Barracuda-Start-Time: 1239758764 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4581 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23196 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Guess what his brother has found last Friday? www.embedmore-talent-2ourworld.cn mass rid tree "As for me, my heart shock is overflowing with happiness sip drop "Yes, cup yes, hurt yes," motioned the invalid. From knikanth@suse.de Wed Apr 15 00:10:56 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3F5AaEP247404 for ; Wed, 15 Apr 2009 00:10:46 -0500 X-ASG-Debug-ID: 1239772198-3e3401f60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C2EEB1CC0769; Tue, 14 Apr 2009 22:09:58 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id 4PtVY6DhHdQJw0ji; Tue, 14 Apr 2009 22:09:58 -0700 (PDT) Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 6238679727; Wed, 15 Apr 2009 07:09:55 +0200 (CEST) From: Nikanth Karthikesan Organization: suse.de To: xfs-masters@oss.sgi.com X-ASG-Orig-Subj: [PATCH 6/7] xfs: Remove code handling bio_alloc failure with __GFP_WAIT Subject: [PATCH 6/7] xfs: Remove code handling bio_alloc failure with __GFP_WAIT Date: Wed, 15 Apr 2009 10:36:48 +0530 User-Agent: KMail/1.11.1 (Linux/2.6.27.21-0.1-default; KDE/4.2.1; x86_64; ; ) Cc: xfs@oss.sgi.com, Christoph Hellwig MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904151036.49241.knikanth@suse.de> X-Barracuda-Connect: cantor2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1239772219 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23210 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Remove code handling bio_alloc failure with __GFP_WAIT. GFP_NOIO implies __GFP_WAIT. Signed-off-by: Nikanth Karthikesan --- diff --git a/fs/xfs/linux-2.6/xfs_aops.c b/fs/xfs/linux-2.6/xfs_aops.c index 7ec89fc..fb4f516 100644 --- a/fs/xfs/linux-2.6/xfs_aops.c +++ b/fs/xfs/linux-2.6/xfs_aops.c @@ -421,10 +421,7 @@ xfs_alloc_ioend_bio( struct bio *bio; int nvecs = bio_get_nr_vecs(bh->b_bdev); - do { - bio = bio_alloc(GFP_NOIO, nvecs); - nvecs >>= 1; - } while (!bio); + bio = bio_alloc(GFP_NOIO, nvecs); ASSERT(bio->bi_private == NULL); bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9); From SEMA-CR-1-476QIO@ptcmarketing.com Wed Apr 15 03:14:21 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.1 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_8BIT_HEADER autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3F8DuEa253239 for ; Wed, 15 Apr 2009 03:14:11 -0500 X-ASG-Debug-ID: 1239783346-26e900970000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from crmmaxx.ptc.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 95B891421AC5 for ; Wed, 15 Apr 2009 01:15:46 -0700 (PDT) Received: from crmmaxx.ptc.com (crmmaxx.ptc.com [12.11.148.125]) by cuda.sgi.com with ESMTP id 4DW8MaZeBAvAk4mS for ; Wed, 15 Apr 2009 01:15:46 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation X-IronPort-AV: E=Sophos;i="4.40,191,1238990400"; d="scan'208,217";a="296703154" Received: from unknown (HELO HQCRMINT1.ptcnet.ptc.com) ([132.253.202.83]) by crmmaxx.ptc.com with ESMTP; 15 Apr 2009 03:45:06 -0400 Date: Wed, 15 Apr 2009 03:44:36 -0400 To: X-Mailer: Siebel EMS 78 [EMS 1098] main/200512201810 MIME-Version: 1.0 Reply-To: noreply@ptc.com From: "PTC Communications" X-ASG-Orig-Subj: =?utf-8?q?You=E2=80=99re?= Invited =?utf-8?q?=E2=80=93?= ECAD and MCAD Co-Design Best Practices Forum =?utf-8?q?=E2=80=93?= 05/13/09 Subject: =?utf-8?q?You=E2=80=99re?= Invited =?utf-8?q?=E2=80=93?= ECAD and MCAD Co-Design Best Practices Forum =?utf-8?q?=E2=80=93?= 05/13/09 Sender: "PTC Communications" Message-ID: Content-Type: multipart/alternative; boundary=BF_1239781476001_1266893679 X-Barracuda-Connect: crmmaxx.ptc.com[12.11.148.125] X-Barracuda-Start-Time: 1239783347 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --BF_1239781476001_1266893679 Content-Type: text/plain; charset=UTF-8 ECAD and MCAD Co-Design Best Practices Forum PTC and Cadence Design Systems invite you to attend an exclusive co-design educational forum to discuss strategies and practices around ECAD/MCAD/DDM requirements and hear first hand our joint PTC/CDN integration and collaboration plans. Join PTC and Cadence Design Systems for the opportunity to network with peers and discuss industry and market trends. Date: Wednesday, May 13, 2009 Location: Cadence Design Systems, Inc. San Jose, California Agenda: Sign up for one, two or all three sessions! Session 1: What's New in Pro/ENGINEER Wildfire 4.0 Time: 10:00AM - 11:30AM PT Audience: MCAD Users, MCAD Consumers and Managers Focus: Pro/ENGINEER Wildfire 4.0 Modules and ProductView Presenter: Jason Petersen, Senior Generalist Applications Engineer, PTC Session 2: ECAD/MCAD Co-Design Collaboration and Best Practice Disucssion Time: 11:30AM - 1:00PM PT (Lunch will be provided) Audience: ECAD and MCAD Users and Managers Focus: Pro/ENGINEER ECAD-MCAD Collaboration ECX Presenters: Pawel Chadzynski, VP Product Management, PTC Linda Mazzitelli, Allegro Product Marketing Director, Cadence Design Systems Session 3: ECAD Design Review, Change Verification and Design Data Management Time: 1:00PM - 2:30PM PT Audience: ECAD Users, ECAD Data Consumers and ECAD Managers Focus: InterComm Expert Suite, ECAD WGM Suite and Cadence Design Systems Allegro Design Workbench for Library and Design Data Management Presenters: Pawel Chadznski, VP Product Management, PTC Linda Mazzitelli, Allegro Product Marketing Director, Cadence Design Systems Seating is limited! To reserve yours, register today (http://www.ptc.com/read?&u=1-5LWLN-2077&c=1-3XZ5Y8&o=1-46K1QB&w=2354034&t=http%3A%2F%2Fwww.ptc.com%2Fview%3Fim_dbkey%3D90706). =============================================================================== contact PTC http://www.ptc.com/company/contacts/index.htm privacy policy http://www.ptc.com/company/policies/index.htm unsubscribe http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=1-46K1QB&campd=1-3XZ5Y8&conud=1-5LWLN-2077&mailkey=2354034&email=xfs@oss.sgi.com change preferences http://www.ptc.com/appserver/mkt/mail/preferences.jsp?&offd=1-46K1QB&campd=1-3XZ5Y8&conud=1-5LWLN-2077&mailkey=2354034&email=xfs@oss.sgi.com edit profile http://www.ptc.com/read?&w=2354034&t=/common/account/index.htm ------------------------------------------------------------------------------- This email was sent to: xfs@oss.sgi.com PTC, 140 Kendrick Street, Needham, MA 02494 USA If you wish to unsubscribe from all PTC Emails, please send a blank email to . --BF_1239781476001_1266893679 Content-Type: text/html; charset=UTF-8 Santa Clara Email 1 NA ECADMCAD Road Show FY09
PTC.com

ECAD and MCAD Co-Design Best Practices Forum

PTC and Cadence Design Systems invite you to attend an exclusive co-design educational forum to discuss strategies and practices around ECAD/MCAD/DDM requirements and hear first hand our joint PTC/CDN integration and collaboration plans. 

Join PTC and Cadence Design Systems for the opportunity to network with peers and discuss industry and market trends.

Date:
Wednesday, May 13, 2009

Location:
Cadence Design Systems, Inc.
San Jose, California

Agenda:
Sign up for one, two or all three sessions!

Session 1:

What's New in Pro/ENGINEER Wildfire 4.0

Time:

10:00AM - 11:30AM PT

Audience:

MCAD Users, MCAD Consumers and Managers

Focus:

Pro/ENGINEER Wildfire 4.0 Modules and ProductView

Presenter:

Jason Petersen, Senior Generalist Applications Engineer, PTC

 

  

Session 2:

ECAD/MCAD Co-Design Collaboration and Best Practice Disucssion

Time:

11:30AM - 1:00PM PT (Lunch will be provided)

Audience:

ECAD and MCAD Users and Managers

Focus:

Pro/ENGINEER ECAD-MCAD Collaboration ECX

Presenters:

Pawel Chadzynski, VP Product Management, PTC
 

Linda Mazzitelli, Allegro Product Marketing Director, Cadence Design Systems
   

Session 3:

ECAD Design Review, Change Verification and Design Data Management

Time:

1:00PM - 2:30PM PT

Audience:

ECAD Users, ECAD Data Consumers and ECAD Managers

Focus:

InterComm Expert Suite, ECAD WGM Suite and Cadence Design Systems Allegro Design Workbench for Library and Design Data Management

Presenters:

Pawel Chadznski, VP Product Management, PTC
 

Linda Mazzitelli, Allegro Product Marketing Director, Cadence Design Systems

Seating is limited! To reserve yours, register today.

contact PTC | privacy policy | unsubscribe | change preferences | edit profile
This email was sent to: xfs@oss.sgi.com     PTC, 140 Kendrick Street, Needham, MA 02494 USA
If you wish to unsubscribe from all PTC Emails, please send a blank email to unsubscribe@ptc.com.
--BF_1239781476001_1266893679-- From niemayer@isg.de Wed Apr 15 04:44:37 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3F9iGru255734 for ; Wed, 15 Apr 2009 04:44:27 -0500 X-ASG-Debug-ID: 1239788639-130f00240000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.isg.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 68A42216DFF for ; Wed, 15 Apr 2009 02:43:59 -0700 (PDT) Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by cuda.sgi.com with ESMTP id AsEIGazili25m9HP for ; Wed, 15 Apr 2009 02:43:59 -0700 (PDT) Received: from embargo.is-teledata.com (unknown [192.168.5.53]) by mail.isg.de (Postfix) with ESMTP id 32F9F1AB6D72; Wed, 15 Apr 2009 11:43:58 +0200 (CEST) Message-ID: <49E5AC5E.90103@isg.de> Date: Wed, 15 Apr 2009 11:43:58 +0200 From: Peter Niemayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Felix Blyakher Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS support for TRIM / blkdev_issue_discard? Subject: Re: XFS support for TRIM / blkdev_issue_discard? References: <20090331053013.7642414167108@attica.americas.sgi.com> <49E4A131.5040309@isg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: rzfoobar.is-asp.com[217.11.194.155] X-Barracuda-Start-Time: 1239788640 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23227 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Felix Blyakher wrote: >> do you know whether there are plans to support the ATA TRIM command / >> blkdev_issue_discard() call in XFS for Linux anytime soon? > > This topic was indeed brought up in xfs discussions. > Though, we don't have any definite plans on supporting it yet. > That doesn't mean that we oppose to it, just the lack of > resources at the moment. > Your mail will bring it up for discussion again. Thanks a lot for your information! Of course, I volunteer to help with testing & qualified feed-back. I might even help with the implementation if you can tell me where to look for the (hopefully well defined ;-) place in the filesystem code where sectors become known not to contain relevant data anymore. But since I'm unfamiliar with kernel-filesystem programming, it might take longer answering my questions then somebody involved with XFS already would need to insert the blkdev_issue_discard() calls. Regards, Peter Niemayer From knikanth@suse.de Wed Apr 15 05:42:51 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3FAgV9A257560 for ; Wed, 15 Apr 2009 05:42:41 -0500 X-ASG-Debug-ID: 1239792113-136b00c20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D1B3F216FC8; Wed, 15 Apr 2009 03:41:53 -0700 (PDT) Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id 64IUI6oPbsf7Lv5v; Wed, 15 Apr 2009 03:41:53 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from Relay2.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id AA8676CB00; Wed, 15 Apr 2009 12:41:51 +0200 (CEST) To: xfs-masters@oss.sgi.com X-ASG-Orig-Subj: [RESEND][PATCH 6/7] xfs: Remove code handling bio_alloc failure with __GFP_WAIT Subject: [RESEND][PATCH 6/7] xfs: Remove code handling bio_alloc failure with __GFP_WAIT Cc: xfs@oss.sgi.com, Christoph Hellwig , Jens Axboe Content-Disposition: inline From: Nikanth Karthikesan Organization: suse.de Date: Wed, 15 Apr 2009 16:09:30 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200904151609.30677.knikanth@suse.de> X-Barracuda-Connect: cantor.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1239792134 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Resending as I accidentally missed Jens earlier. Jens, can you merge this as well. Thanks Nikanth Remove code handling bio_alloc failure with __GFP_WAIT. GFP_NOIO implies __GFP_WAIT. Signed-off-by: Nikanth Karthikesan --- diff --git a/fs/xfs/linux-2.6/xfs_aops.c b/fs/xfs/linux-2.6/xfs_aops.c index 7ec89fc..fb4f516 100644 --- a/fs/xfs/linux-2.6/xfs_aops.c +++ b/fs/xfs/linux-2.6/xfs_aops.c @@ -421,10 +421,7 @@ xfs_alloc_ioend_bio( struct bio *bio; int nvecs = bio_get_nr_vecs(bh->b_bdev); - do { - bio = bio_alloc(GFP_NOIO, nvecs); - nvecs >>= 1; - } while (!bio); + bio = bio_alloc(GFP_NOIO, nvecs); ASSERT(bio->bi_private == NULL); bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9); From niemayer@isg.de Wed Apr 15 06:59:01 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3FBwfYY260398 for ; Wed, 15 Apr 2009 06:58:51 -0500 X-ASG-Debug-ID: 1239796702-138101c50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.isg.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 478932172E0 for ; Wed, 15 Apr 2009 04:58:22 -0700 (PDT) Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by cuda.sgi.com with ESMTP id VniAPHVRpA6btEda for ; Wed, 15 Apr 2009 04:58:22 -0700 (PDT) Received: from embargo.is-teledata.com (unknown [192.168.5.53]) by mail.isg.de (Postfix) with ESMTP id 25F5E1A97F07; Wed, 15 Apr 2009 13:58:22 +0200 (CEST) Message-ID: <49E5CBDD.3070302@isg.de> Date: Wed, 15 Apr 2009 13:58:21 +0200 From: Peter Niemayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Felix Blyakher Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS support for TRIM / blkdev_issue_discard? Subject: Re: XFS support for TRIM / blkdev_issue_discard? References: <20090331053013.7642414167108@attica.americas.sgi.com> <49E4A131.5040309@isg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: rzfoobar.is-asp.com[217.11.194.155] X-Barracuda-Start-Time: 1239796704 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23237 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 BSF_SC0_SA085 Custom Rule SA085 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean FYI: I added my proposal to the Wiki: http://xfs.org/index.php/Support_discarding_of_unused_sectors (plus a reference at http://xfs.org/index.php/Ideas_for_XFS ) Regards, Peter Niemayer From kirillvyacheslavovich@xx0007xx.net Wed Apr 15 09:56:59 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=5.0 tests=BAYES_50,MIME_8BIT_HEADER, MIME_BASE64_BLANKS,MIME_BASE64_TEXT autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3FEudks007800 for ; Wed, 15 Apr 2009 09:56:49 -0500 X-ASG-Debug-ID: 1239807381-704401fc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from nattytc.frinick.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 7E41A217DF0 for ; Wed, 15 Apr 2009 07:56:21 -0700 (PDT) Received: from nattytc.frinick.com (nattytc.frinick.com [195.209.36.214]) by cuda.sgi.com with SMTP id oKdoMz45dXIXNHK9 for ; Wed, 15 Apr 2009 07:56:21 -0700 (PDT) Received: from rev-net-0e9p-0165-013x-01j5cv5r.mtb ([10.167.41.179]) by nattytc.frinick.com () with ESMTP id 2943076FC6 for ;Wed, 15 Apr 2009 18:55:45 +0400 From: Kirill Vyacheslavovich To: Xfs X-ASG-Orig-Subj: =?Windows-1251?B?x+Di5fD45e3o5SDv8O725fHx4CDv8O7k4OboIPLu4uDw7uIv8/Hr8+Mg?= =?Windows-1251?B?yuvo5e3y8w==?= Subject: =?Windows-1251?B?x+Di5fD45e3o5SDv8O725fHx4CDv8O7k4OboIPLu4uDw7uIv8/Hr8+Mg?= =?Windows-1251?B?yuvo5e3y8w==?= Date: Wed, 15 Apr 2009 18:55:45 +0400 Message-ID: <0007050791.20090415185545@xx0007xx.net> X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Bad Seeds Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 Sensitivity: Company-Confidential MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: base64 X-Barracuda-Connect: nattytc.frinick.com[195.209.36.214] X-Barracuda-Start-Time: 1239807382 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6033 1.0000 0.7648 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.29 X-Barracuda-Spam-Status: No, SCORE=1.29 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MIME_BASE64_BLANKS, MIME_BASE64_TEXT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23249 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MIME_BASE64_BLANKS RAW: Extra blank lines in base64 encoding 0.52 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean xO7h8PvpIOLl9+XwISD98u4gwfDu7ejx6+DiDQoNCj4gMjgg4O/w5ev/Lg0KICDjLiDK6OXi LCDh8+v84i4g2OXi9+Xt6u4sIDQNCg0KICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KPiDP8O7k4ujm5e3o5SDy7uLg8O7iIOgg8/Hr8+Mg7eAg8e7i8OXs5e3t7uwg8Pvt 6uU6IOjt7e7i4Pbo7u3t++Ug8fLw4PLl4+joIOgg8uX17e7r7uPo6C4NCiAgPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCg0KPiDW5evl4uD/IODz5Ojy7vDo/zoNCiAgUPPq 7uLu5Ojy5evoIOgg7eD34Ov87ejq6CDu8uTl6+7iIO/w7uTg5iDy7uLg8O7iIOgg8/Hr8+Mg 8e7i8OXs5e3t+/Ug6u7s7+Dt6OksIPDg4e7y7ejq6CDu8uTl6+Ag8eH78uAsIA0KICDs5e3l 5Obl8Psg7+4g8ODh7vLlIPEgVklQLSDq6+jl7fLg7OgsIOHw5e3kLezl7eXk5uXw+yDoIOzg 8Orl8u7r7uPoIOru7O/g7ejpLCDt4Pfg6/zt6OroIPHh+/LgIPDu5+3o9+3u6SDoIO7v8u7i 7ukg8u7w4+7i6+guDQogIM7tIO/w5eTt4Oft4Pfl7SDy4Orm5SDk6/8g8uX1LCDq8u4g7eD1 7uTo8vH/IPMgq+jx8u7q7uK7IPDg8erw8/Lq6CDt7uLu6SDy7vDj7uLu6SDs4PDq6CDy7uLg 8OAv8/Hr8+PoLiANCiAgzuTt6Owg8evu4u7sLCDk6/8g8uX1LCDq8u4g8+Hl5uTl7Swg9/Lu IO/w7uTg8vwg7O7m7e4g4vHlLiDN8+bt7iDy7uv86u4g5+3g8vwgys7M0yDoIMrAyi4NCg0K PiDP8O7j8ODs7OANCg0KPiDC4uXk5e3o5S4gz+7k4+7y7uLq4CDqIO/w7uTg5uUg8u7i4PDu 4iDoIPPx6/PjIO3gIPHu4vDl7OXt7e7sIPD77erlDQogIM3u4vvlIPLl7eTl7fbo6CDiIO/w 7uTi6Obl7ejoIPLu4uDw7uIv8/Hr8+Mg7eAg8e7i8OXs5e3t7uwg8Pvt6uUuIMzg8Orl8ujt 4+7i++kg8e/u8CDi5ergIOzl5uTzINQuIMru8uvl8O7sIOggxOYuINLw4PPy7uwuIA0KICDX 8u4g4uDm7eXlOiDv8O7k4ObgIOjr6CDv8O7k4ujm5e3o5T8gz/Du5OLo5uXt6OUg8u7i4PDu 4iDoIPPx6/PjOiDu4fnl5SDoIO7x7uHl7e3u5S4gyu7t9uXv9uj/IPHu4vDl7OXt7e7pIO/w 7uTg5uguIA0KICDP5e3y4OPw4Ozs4CDRLiDD6O3j5fDgLiDA7eDr6PLo9+Xx6ujpIOzu5+Pu 4u7pIPjy8/DsLiA1IO/u6/7x7uIg8e7i8OXs5e3t7uPuIO/w7uTi6Obl7ej/IOgg7/Du5ODm 6CDy7uLg8OAv8/Hr8+PoLg0KDQo+INfg8fL8IDEuIMjk5e7r7uPo9+Xx6ujpIO/u6/7xIO/w 7uTi6Obl7ej/IPLu4uDw4C/z8evz4+gg6u7s7+Dt6OgNCiAglSDD5OUg6PHq4PL8IO/w6Pfo 7fMg7+vu9e7pIPPn7eDi4OXs7vHy6CDy7vDj7uLu6SDs4PDq6D8gwfDl7eTo7ePu4vvlIOjn 7OXw5e3o/yDiIO/w7vbl8fHlIO/w7uTi6Obl7ej/IPLu4uDw4C/z8evz4+guDQogIJUg0O7r /CDv7ufo9uju7ejw7uLg7ej/IOjr6CD96vHq6/7n6OLt+/Ug7/Dl6Ozz+eXx8uIg4iDv8O7k 4ujm5e3o6CDy7vDj7uLu6SDs4PDq6Cwg8u7i4PDgL/Px6/Pj6A0KICCVIMru8O/u8ODy6OLt 4P8g6vPr/PLz8OAg6CD25e3t7vHy6CDq7uzv4O3o6Cwg6u7y7vD75SDi6+j//vIg7eAg8O7x 8iDv8O7k4OYg6CDz5+3g4uDl7O7x8vwg8u7w4+7i7ukg7ODw6ugNCg0KPiDX4PHy/CAyLiDO 8OPg7ejn4Pbo/yDoIO/u8fLw7uXt6OUg7vLk5evgIO/w7uTg5iDiIOru7O/g7ejoLg0KICCV INLw6CDn4OTg9+gg8+/w4OLr5e3o/yDv8O7k4Obg7OguIMTo4OPt7vHy6OrgIPHu4fHy4uXt 7e7j7iDx8ujr/yDv8O7k4OboLiDM5fLu5Ojq4CCr1/LuIOL7IOfgIO/y6PbgP7suDQogIJUg 0ujv+yDoIPHy6OvoIO/w7uTg5i4gwvv/4uvl7ejlIPHo6/zt+/Ug6CDx6+Dh+/Ug8fLu8O7t IO/w7uTg4vbu4iDu8uTl6+Ag4u4g4ufg6Ozu5OXp8fLi6Ogg8SDK6+jl7fLg7Ogg4iD17uTl IA0KICAgIO/w7uTg5ugg8u7i4PDu4i/z8evz4yDq7uzv4O3o6C4gyvLuIOzu5uXyLCDgIOry 7iDt5SDs7ubl8iDv8O7k4OLg8vwg5O7w7uPuPyDD5OUg6CDt4CD35ewg6u7s7+Dt6Ogg8uXw //7yIOjs6OTm6CDk5e384+g/DQogIJUgz+735ezzIPXu8O746Okg7/Du9OXx8eju7eDrIO3l IOzu5uXyIP309OXq8uji7e4g7/Du5ODi4PL8PyDX8u4g8uDq7uUgq/fl8O3g/yDk+/DguyDi IO/w7uTg5uD1IOru7O/g7ejoPw0KICCVIM/u9+Xs8yDq7uzv4O3o6CDy5fD//vIgyuvo5e3y 7uI/INTg6vLu8Psg6PUg8+Tl8Obg7ej/Lg0KICCVIMLo5Psg6u7t8vDu6/8g6CDx4Ozu6u7t 8vDu6/8g8OXn8+v88uDy6OLt7vHy6CDv8O7k4OYg7/Du5ODi9uAuDQogIJUg0e7x8uDi6+Xt 6OUg6uDw8vsg6uv+9+Xi+/Ug8OXn8+v88uDy6OLt+/Ug7uHr4PHy5ekg8ODh7vL7ICjK0M4p IO/w7uTg4vbgDQogIJUgy+jx8iDu9uXt6ugg8u7w4+7i7ukg8u736uggKOzg4+Dn6O3gKQ0K DQo+INfg8fL8IDMuINLl9e3u6+7j6P8g8/Hv5fjt7ukg7/Du5ODm6CDy7uLg8O7iIOgg8/Hr 8+Mg7eAg8e7i8OXs5e3t7uwg8Pvt6uUNCiAg3fLg7yAxLiDM5fLu5Psg7+7o8ergIMrr6OXt 8u7iLiDP8ODi6OvgIPHu8fLg4uvl7ej/IOru7Ozl8Pfl8eru4+4g7/Dl5Ovu5uXt6P8uDQog IN3y4O8gMi4g0/Hy4O3u4uvl7ejlIOru7fLg6vLgIO/uIPLl6+X07u3zIOgg5O7j7uLu8OXt 7e7x8vwg7iDi8fLw5fflLg0KICDd8uDvIDMuIM/w4OLo6+Ag4vXu5uTl7ej/IOIg6u7t8uDq 8iDiIO/w7vbl8fHlIO3l7+7x8OXk8fLi5e3t+/Ug7+Xw5ePu4u7w7uIg8SDK6+jl7fLu7C4N CiAgz/Dl5+Xt8uD26P8g6u7s7OXw9+Xx6u7j7iDv8OXk6+7m5e3o/yDK6+jl7fLzLiDM5fLu 5CDB5e3k5uDs6O3gINTw4O3q6+jt4C4NCiAg0+/w4Obt5e3o5SCrwOvj7vDo8uwg1S3PLcIg 4iDv8O7k4ujm5e3o6CDy7uLg8O7iL/Px6/Pjuy4NCiAg3fLg7yA0LiDQ4OHu8uAg8SDi7ufw 4Obl7ej/7Ogg6CDx7uzt5e3o/+zoIOrr6OXt8uAuIM7x7e7i7fvlIPLo7/sg6CDi6OT7IOLu 5/Dg5uXt6OkuDQogIN3y4O8gNS4gx+Di5fD45e3o5SDv8O725fHx4CDv8O7k4OboIPLu4uDw 7uIv8/Hr8+Mgyuvo5e3y8y4gz/Do5ez7IOgg8uX17e7r7uPo6C4NCg0KPiDX4PHy/CA0LiDM 4PDq5fLo7ePu4vvpIO/u6/7xIO/w7uTg5ugNCiAglSDP7vfl7PMgwuD4IPLu4uDwLCDq7vLu 8PvpIO/w7uTg4uDr8f8g4vHl4+TgLCDt5SDv8O7k4OXy8f8/INHu4vDl7OXt7fvlIOzg8Orl 8ujt4+7i++Ug8fLw4PLl4+joLCANCiAgICDi6+j//vno5Swg7eAg/fT05ery6OLt7vHy/CDx 4fvy4CDy7uLg8OAv8/Hr8+PoDQogIJUg1ODq8u7w+ywg4uvo//756OUsIO3gIPHh+/IuDQog IJUgwe7x8u7t8erg/yDs4PLw6PbgIOrg6iDi++Hu8CDv6+Dt7uzl8O3u6SDx8vDg8uXj6Ogg 7/Du5OLo5uXt6P8g8u7w4+7i7ukg7ODw6ugNCiAglSDK4O3g6/sg8eH78uAuIN309OXq8uji 7e7x8vwg6uDt4Ovu4iDx4fvy4C4g2Org6+Ag0C4gy+Xp6uDw8uAuDQogIJUgwOr26Ogg8fLo 7PPr6PDu4uDt6P8g8eH78uAuIEJUTC3s5fDu7/Do//Lo/yDiIP309OXq8uji7e7pIO/w7uTg 5uUg8u7i4PDgL/Px6/Pj6C4NCiAglSDP6+Dt6PDu4uDt6OUg6CDv8O7i5eTl7ejlIEJUTC3s 5fDu7/Do//Lo6SDiIOfg4ujx6Ozu8fLoIO7yIPHy4OTo6CDw4Ofi6PLo/yDy7vDj7uLu6SDs 4PDq6C4gDQogICAg0ujv6Pft++Ug7vjo4eroIO/w6CDv8O7i5eTl7ejoIODq9ujpIPHy6Ozz 6+jw7uLg7ej/IPHh+/LgLg0KDQo+INfg8fL8IDUuIFBSIOgg4ufg6Ozu5OXp8fLi6OUg8e4g 0czIIOrg6iDx8OXk8fLi7iDv8O7k4ujm5e3o/yDy7vDj7uLu6SDs4PDq6CAo8u7i4PDgLCDz 8evz4+gpIOIg8e7i8OXs5e3t+/Ug8/Hr7uLo//UNCiAglSDP7ujx6iDq7u3q8/Dl7fLt+/Ug 7/Dl6Ozz+eXx8uIuIM7y8fLw7unq4CDu8iDq7u3q8/Dl7fLu4i4gNSDx6Osg6u7t6vPw5e3y 7fv1IOTl6fHy4ujpIO/uIM/u8vLl8PMuIKvR5fD76SBQUrsg4iDw4OHu8uUg8SDq7u3q8/Dl 7fLg7OguDQogIJUg0e7h+/Lo6e376SBQUiwg6uDqIOLg5u376SD04Ory7vAg7/Du5OLo5uXt 6P8g8e7i8OXs5e3t7ukg8u7w4+7i7ukg7ODw6ugNCiAglSDC6OT7IOgg8ujv+yBQUi3s5fDu 7/Do//Lo6Swg4uvo//756PUg7eAg4u7n4vv45e3o5SDo7Ojk5uAg6CDv7uL7+OXt6P8g8+ft 4OLg5ezu8fLoIPLu8OPu4u7pIOzg8OroLiDK8ODy6ujlIPH25e3g8OjoIOj1IO/w7uLl5OXt 6P8uDQogIJUg0ODh7vLgIPHuINHMyCDoIObz8O3g6+jx8uDs6CDxIPbl6/z+IP309OXq8uji 7e7x8ugg7/Du5OLo5uXt6P8g8u7w4+7i7ukg7ODw6ugv8/Hr8+PoIO3gIPD77erlLg0KDQo+ INTu8Oz7IOgg7OXy7uT7IO/w7uLl5OXt6P86DQogIJUgzOjt6C3r5er26OgsIOzu5+Pu4u7p IPjy8/DsDQogIJUgw/Dz7+/u4vvlIOTo8erz8fHo6A0KICCVINDu6+Xi++Ug6OPw+yDoIOTl 6+7i++UNCiAglSDQ4Ofh7vAg6u7t6vDl8u379SDv8ODq8uj35fHq6PUg8ejy8+D26OkgKGNh c2Utc3R1ZGllcykuDQogIJUgwvHlIPP34PHy7ejq6CDu4eXx7+X36OLg/vLx/yDs5fLu5Oj3 5fHq6OzoIO/u8e7h6P/s6C4NCg0KPiBDVE/ITU9DVNwg09dBQ9LI3yBPxEhPw08g09dBQ9LN yMpBOg0KICCVIDgwMC4wMCDj8O0uIOfgIO7k7e7j7iDvcGXkY/Jh4ujyZev/Lg0KICCVIMTr /yDi8u7w7uPuIOgg8vDl8vzl4+4g8/fg8fLt6OrgIPHq6OTq4CAtIDUlIOggNyUg8e7u8uLl 8vHy4uXt7e4uDQoNCj4gQiBj8m/o7G9j8vwg4mvr/vdl7fs6DQogICAg6O307vDs4Pbo7u3t 7i3q7u3x8+v88uD26O7t7e7lIO7h8evz5uji4O3o5SwNCiAgICD96vHq6/7n6OLt++kg8eHu 8O3o6iDs4PLl8Ojg6+7iLCDh6+7q7e7yLA0KICAgIPDz9+rgLCDq7vTlLeHw5enqLCDu4eXk IOIg8OXx8u7w4O3lLg0KDQoqIFBFw8tBTUVIVDogOS4zMC0xNy4zMC4gz+Xw5fD74iAxMy4z MC0xNC4zMC4NCiog0OXj6PHy8OD26P8g8SA5LjAwIOIg9e7r6+UuDQoNCj4g0uXrLjogKzM4 ICgwNDQpIDIzMyA0NiA2OSAvIDIzNyA5TyBPNQ0KDQoNCj4g0+Tg9+3u4+4g4ejn7eXx4CEN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQrx6/P34Ont++Ug8fLw7uroOusg zuvl4y4gzPPmIO735e38IPcgYmF4bWF0QHlhLnJ18fwhYW5uYW1AcHN0dS5ydQkhIMvz9/jl 4+4g7OXx8mFrb25AcGF0cmlhcmNoLnJ1CcPLIDM2MzhAcGVjaGtpbi5pcHRlbGVjb20ubmV0 LnVh From xfs@tlinx.org Wed Apr 15 16:24:19 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3FLNvgV026783 for ; Wed, 15 Apr 2009 16:24:09 -0500 X-ASG-Debug-ID: 1239830730-7b4f03660000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ishtar.tlinx.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3D7F514250FF for ; Wed, 15 Apr 2009 14:25:30 -0700 (PDT) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by cuda.sgi.com with ESMTP id XHUcTPJwft5T97RI for ; Wed, 15 Apr 2009 14:25:30 -0700 (PDT) Received: from [192.168.3.11] (Athena [192.168.3.11]) by ishtar.tlinx.org (8.14.1/8.12.10/SuSE Linux 0.7) with ESMTP id n3FLNHgm012209 for ; Wed, 15 Apr 2009 14:23:17 -0700 Message-ID: <49E65044.8080802@tlinx.org> Date: Wed, 15 Apr 2009 14:23:16 -0700 From: "Linda A. Walsh" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: xfs-oss X-ASG-Orig-Subj: future of xfs, oss.sgi.com after sgi purchased? Subject: future of xfs, oss.sgi.com after sgi purchased? X-Stationery: 0.4.8.14 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ishtar.tlinx.org[64.81.245.74] X-Barracuda-Start-Time: 1239830752 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.23273 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Not one to beat about the bush, but curious from a practical sense, If sgi is being bought by another company, is there any idea about the plans for the xfs file system or the source code on 'oss.sgi.com'? I'm _guessing_ that there is some interest in users and developers to keep xfs alive after the 'sgi' moniker is purchased, but that begs the question about the new company wanting to support the old 'sgi.com' websites including oss.sgi.com. Is there a danger of oss.sgi.com suddenly being yanked offline with little to no warning, such that community members should start keeping up-to-date, or is it already mirrored? I'm assuming that the current source code repository only exists on oss.sgi.com? Should it be mirrored on some other external open-source site? sourceforge? google? mozilla? Is completely worthless to discuss new, desired features in some of the utils? Will it be possible to support the xfs codebase if its development no longer becomes necessary to sgi (or its parent company)? *sigh*, -linda From martingeng@martinlinkingbiz.com Wed Apr 15 20:29:23 2009 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n3G1T24A036817 for ; Wed, 15 Apr 2009 20:29:12 -0500 X-ASG-Debug-ID: 1239845304-63fc01c50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from www.martinlinkingbiz.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A25421CC4B9E for ; Wed, 15 Apr 2009 18:28:24 -0700 (PDT) Received: from www.martinlinkingbiz.com ([67.222.146.102]) by cuda.sgi.com with ESMTP id 56GnFuS7BkxaN957 for ; Wed, 15 Apr 2009 18:28:24 -0700 (PDT) Received: (qmail 25756 invoked by uid 0); 16 Apr 2009 01:21:38 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=private; d=martinlinkingbiz.com; b=0py0ElRjSGe0ppDu7vICckcxPVgcCIyf0iZsBMkdOqRvLGRPI9/xngx3f64EjqJc; Received: from unknown (HELO MartinThinkpad) (martingeng@martinlinkingbiz.com@218.104.206.238) by 67.222.146.102 with ESMTPA; 16 Apr 2009 01:20:57 -0000 Reply-To: From: "Martin Geng" To: "Martin Geng" X-ASG-Orig-Subj: The 2nd Plant Managers Forum 2009 -- **Last Reminder to Register- 5 Seats Left** Subject: The 2nd Plant Managers Forum 2009 -- **Last Reminder to Register- 5 Seats Left** Date: Thu, 16 Apr 2009 09:07:18 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_044C_01C9BE74.A5CC8E60" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclaibrZee3ttqYUT9ik0WbSsgdFtgAAHrjAAABlmJAAACqREAAAKOGAAAB3YQAAAgABAAAAsg8gAA/kOdAAAB3l4AAXqWiQAMmD6/AAAIpIQAAAU5CQAAAxmwAAL3jl4AAALapgAABIFIAAAE5qsAAAPp2AAAAr/OAAAF8TkAAGrboQADkFk8AAADJxkAAAEIeQAAAgfQAAIbvtUAAAPBdwAAAYnXAAABqp4AAAKgIwAAA0IPAAABDesAAAgrvgAAAz22AAAEwSEAAAGAbgAAC77PAA+emHUAAATZdgAAAfJvAAAEUYcAAAHNzAAABbW7AAMjIDsAAASnQQAABMOEAAADctsAAAJYMgAAA4pZAAACLgkAAusJ2gAABAwdAAABMo8AAAO+iAAAAeZDAAMXdGIAAATttQAAAc4dAAABEQwAAALuYAAAAY9YAAADprUAAA7/hwAJXbF1AAAl5oMAOKlKMwBMKy7/AAACJG4AAADZLwACMHsaAAAGNzYAABwaHwAAAYhXAAARfS8AAALdsAAAAMTpAAAdtqcAAAFtmwAAAUWUAAACFHQAAAHbMwAAjsQ2AAABpCEAAAM0RwAAApXHAAAA0lsAAACyLAAAAVQ2AAACFAEAAAEE8gAAAhR2AAAAtmAAAABpswAAAW8ZAAABEegAAACtygAAAgyNAAAAtm8ABY9IagAAzPsDAAuUTiUAAADg9gAAAgfNAAAA3zcAAAGWtQAAAJjyAAACcoIAAACzRQAAAPHAAAABqIYAAADA8AAAARZQAAABrb4AAAFTpQAAAVnRAAAA4KwAAACrUQAAALORAAAAvoUAA/Mo8wAAANJsAAiMfEUAAAxipAAAAQYIAAApeKkAAADrGgAAOhE6AAAAycMAAACIyQAAAJSMAAABoW8AAAEp+wAAA9dqAAABi0kAAACk5wAAA8aiAAAAqc8AAAENJQAAAosnAAAApXAAAADG5g AAAJZjAAAAsjwAAACddgAA AH0rAAAAh8kAAACs6QAAAxa9AAAA7zsAAAFGowAAAIcwAAAAjaQAAAE2sQAAAM7RAAjs6AUAAAOMfgAAAPDLAAAAoJcAAAJJVQAAHDcqAAAAsZEAAFCa2wAAWJshAAAA/VYAAADNKAAAAIyuAAAAtRMAAAECRwAAAJToAAAAi8kAAACrbQAAAFd3AAAA4ScAAAC+RgAAAME4AAABDowAAAHGrgAAAPPMAAK8eI8AAADMoQAAAI/3AAAA5YYAAACc+wAAAI/QAABeoAgAAPATiAABTq6yAABxyp4ABHPHyQABn4stAAAtDQUAAAZkXAAAA0JsAAABunwAAAsP+wAAA3kIAAAEOqYAAAPFAwAASlLWAAiL0vsAAAfQVQAAB4HwAAACRy4AAAlRmAAC6kn1AAAM6W0AAAGaBAAAAX3IAAAEkoUAAAHAnwADTNtdAAACG+8AA4kCgwAAB654AAAFMKMAAAoz9QADEUEiAAjfQd0ABANfrgACOpViAACNL38AAAVIcwADHyAaAABR5mUAAo1iWAAJKn4OAANpKK4AAtETJwAACzNoAABBt9MAAukpugADLt4sAAmMc00AAA0b/gADEDt/AAAhBm4AAAPKqQADDMhZAAa09GQAABAzlQAPtFgIAAAH5/UAAEXLggACKjieAAAImpkAAxF8ngAA6T06AAAQlRcADJmY/gAAEX/WAAAB1OEABWfB/AABJ9fhAAACUcEAAu0w6QAJhTJNAAALEHcABRZQQwAAFIpHAALz5bAA== Importance: High Disposition-Notification-To: "Martin Geng" X-Barracuda-Connect: UNKNOWN[67.222.146.102] X-Barracuda-Start-Time: 1239845325 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1001.00 X-Barracuda-Spam-Status: No, SCORE=-1001.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This is a multi-part message in MIME format. ------=_NextPart_000_044C_01C9BE74.A5CC8E60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_044D_01C9BE74.A5CC8E60" ------=_NextPart_001_044D_01C9BE74.A5CC8E60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit This is your last chance to register for The 2nd Plant Managers Forum 2009. We have only 5 seats left; therefore, do not miss this opportunity to register! The 2nd Plant Managers Forum 2009 Achieving best practices in maintaining excellence in plant management 21st & 22nd May 2009 Millennium Hongqiao Hotel Shanghai China Hello, How are you? MARTIN LINKING is convening the 2nd Plant Managers Forum in Shanghai on 21st & 22nd May 2009. This event will offer effective tools and strategies responding to the challenges brought by the international financial crisis. It will also cover such key issues as workplace regulation and labour laws, personnel management, cost cutting and financial controlling practices, optimized operations and maintenance schedules and continuous improvement that will guarantee the plant survives amidst the economic turmoil and prospers long into the future. If you are not relevant, could you help me to forward this information to the people who are related. Thanks for that! Topics for discussion: * Examining Chinese manufacturing on how to improve cash flow in the face of an unprecedented financial market crisis * Looking at ways to make sure the efficient execution of company strategies and planning amidst the economic turmoil * Examining the updated implementation for the labor contract law to cope with the deteriorating market conditions * Achieving optimum energy management goals by creating and implementing a strategic action plan * Discussing solutions to improve accuracy of sales and production planning * Identifying and managing health and safety hazards within your business * Effectively assessing and handling the potential risks in your supply chain * Providing ideas and thought-processes relating to concepts of Demand-Driven manufacturing * Creating the vision for a Kaizen culture and ensure long-term cohesiveness Some of the eminent speakers we are inviting include: * Glenn Rosenholmer Global Partner/Project Director UnitedLog Consulting * Guillaume de Roquefeuil Managing Director BravoSolution * Kien Leong General Manager JCIT Asia Pacific * Yongchun Dai JXG Site Director , RM of Supply College MARS CHINA * Baldwin Hui President Institute of Business Engineering * Gary Ching VP Institute of Business Engineering * Michael Sherretz Former China Country Manager and VP Manufacturing PPG Industries, Tyco Fire & Security, Gambro * Douglas McLachlin Partner, Director of Resources Management Services Environmental Resources Management (ERM) * Dr. Iris Duchetsmann German-attorney-at-law Beiten Burkhardt Law Firm Please find an agenda in both English and Chinese attached with this email. Please do not hesitate to contact me should you have any queries, 15% special offer is available for all the attendees of the first Plant Managers Forum 2008. To register the very limited 10% off seats, simply fill out the registration form, attention it to Martin Geng and fax it to + 86 28 6552 1233. If you don't want to receive any further email from us, please reply this email to unsubscribe with correct email address. Best Regards, Martin Geng __________________________________________ Martin Linking Business Consulting Company Limited Room 808A, Times Plaza, No.2 Zongfu Road, Chengdu, Sichuan 610016, China T: +86 28 65521255 F: +86 28 65521233 E: martin.geng@martinlinking.net www.martinlinking.com We are dedicated to offer our clients cutting edge information they can use immediately. Upcoming Martin Linking events: Title : Best Practices for Sustainable Corporate Social Responsibility 2009 Date : 20th & 21st August 2009 Venue : Shanghai, China Link : http://www.martinlinking.com/documents/ws/csr_ws.pdf Title : Total Productive Maintenance (TPM) Best Practice 2009 Date : 30th & 31st July 2009 Venue : Shanghai, China Link : http://www.martinlinking.com/documents/ws/tpm_ws.pdf Title : Continuous Application of Behavior-Based Safety 2009 Date : 30th & 31st July 2009 Venue : Shanghai, China Link : http://www.martinlinking.com/documents/ws/bbs_ws.pdf Title : Upgrade the Practical Skills of Business Channels of Pharmaceutical Enterprises under the New Medicine Situation Date : 18th & 19th June 2009 Venue : Shanghai, China Link : http://www.martinlinking.com/documents/ws/pbc_ws.pdf Title : Best Practices for Machinery Lubrication Date : 21st& 22nd May 2009 Venue : Shanghai, China Link : http://www.martinlinking.com/documents/ws/ml_ws.pdf This message and any attachment is intended only for the use of the Addressee and may contain information that is PRIVILEGED. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. Thank You. Security Warning: Please note that this e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium. We advise that you understand and observe this lack of security when e-mailing us. Viruses: Although we have taken steps to ensure that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. ------=_NextPart_001_044D_01C9BE74.A5CC8E60 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

This is your last chance to = register for The 2nd Plant Managers Forum = 2009. We have only 5 = seats left; therefore, do not miss this opportunity to = register!

 

 

The 2nd Plant Managers Forum = 2009

Achieving best practices in = maintaining excellence in plant management

21st & 22nd May = 2009

Millennium Hongqiao = Hotel

Shanghai China

Hello,

How are you?

 

MARTIN LINKING is convening the 2nd = Plant Managers = Forum in Shanghai on 21st &  22nd May 2009. This event will offer = effective tools and strategies responding to the challenges brought by the = international financial crisis. It will also cover such key issues as = workplace regulation and labour laws, personnel management, cost cutting and = financial controlling practices, optimized operations and maintenance schedules = and continuous improvement that will guarantee the plant survives amidst the economic turmoil and prospers long into the = future.

 

If you are not = relevant, could you help me to forward this information to the people who are = related. Thanks for that! 

 

Topics for discussion:

l   = Examining<= /strong> Chinese manufacturing on how to improve cash flow in the face of an = unprecedented financial market crisis

l   = Looking = at ways to make sure the efficient execution of company strategies and planning = amidst the economic = turmoil

l   = Examining<= /strong> the updated implementation for the labor contract law to cope with the deteriorating = market conditions

l   = Achieving<= /strong> optimum energy management goals by creating and implementing a strategic action = plan

l   = Discussing= solutions to improve accuracy of sales and production = planning

l   = Identifying and managing health and safety hazards within your = business

l   = Effectively assessing and handling the potential = risks in your supply chain

l   = Providing<= /strong> ideas and thought-processes relating to concepts of Demand-Driven manufacturing =

l   = Creating the vision for a Kaizen culture and ensure long-term = cohesiveness

 <= /p>

Some of the eminent speakers we are inviting = include:

·         Glenn = Rosenholmer Global Partner/Project Director  UnitedLog Consulting

·         Guillaume = de Roquefeuil  Managing Director  BravoSolution

·         Kien Leong General Manager JCIT Asia = Pacific

·         Yongchun = Dai  JXG Site Director , RM of = Supply College MARS CHINA

·        Baldwin = Hui  President =   Institute of Business = Engineering

·         Gary = Ching  VP  Institute of Business = Engineering

·         Michael Sherretz  Former China Country = Manager and VP Manufacturing  PPG = Industries, Tyco Fire & Security, Gambro

·         Douglas McLachlin  Partner, Director of = Resources Management Services  = Environmental Resources Management (ERM)

·         Dr. Iris Duchetsmann  German-attorney-at-law  Beiten Burkhardt Law = Firm

 

Please find an agenda in both English and Chinese = attached with this email.

Please do not hesitate to contact me should you have any = queries, 15% special offer is = available for all the attendees of the first Plant Managers Forum 2008. =

To register the very limited 10% off = seats, = simply fill out the registration form, attention it to Martin Geng and fax it to + 86 = 28 6552 1233. 

If you don't want to receive any further = email from us, please reply this email to unsubscribe with correct email address. 

Best Regards, 

Martin Geng

__________________________________________

Martin Linking Business Consulting Company = Limited

Room 808A, = Times = Plaza, No.2 Zongfu = Road, Chengdu,

Sichuan= 610016, China

 

T: +86 28 = 65521255

F: +86 28 = 65521233

E: martin.geng@martinlinking.net

www.martinlinking.com

We are = dedicated to offer our clients cutting edge information they can use = immediately.

 =

Upcoming Martin Linking events:  

Title      : Best Practices for Sustainable Corporate = Social Responsibility 2009

Date     :  20th = & 21st August 2009

Venue   : Shanghai, China

Link    =   : h= ttp://www.martinlinking.com/documents/ws/csr_ws.pdf=

 =

Title      : Total Productive Maintenance (TPM) Best = Practice 2009

Date     :  30th = & 31st July 2009

Venue   : Shanghai, China

Link    =   : http://www.= martinlinking.com/documents/ws/tpm_ws.pdf

 =

Title      : Continuous Application of Behavior-Based = Safety 2009

Date     :  30th = & 31st July 2009

Venue   : Shanghai, China

Link    =   : http://www.= martinlinking.com/documents/ws/bbs_ws.pdf

 =

Title      : Upgrade the Practical Skills of Business = Channels of Pharmaceutical Enterprises under the New Medicine = Situation

Date     :  18th = & 19th June = 2009

Venue   : Shanghai, China

Link    =   : http://www.= martinlinking.com/documents/ws/pbc_ws.pdf

 

Title      :  = Best Practices for Machinery = Lubrication

Date     :  21st& = 22nd May = 2009

Venue   : Shanghai, China

Link    =   : http://www.m= artinlinking.com/documents/ws/ml_ws.pdf

 

This message = and any attachment is intended only for the use of the Addressee and may contain information that is PRIVILEGED. If you are not the intended recipient, = you are hereby notified that any dissemination of this communication is = strictly prohibited. If you have received this communication in error, please = erase all copies of the message and its attachments and notify us immediately. = Thank You. Security Warning: Please note that this e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications = medium. We advise that you understand and observe this lack of security when = e-mailing us. Viruses: Although we have taken steps to ensure that this e-mail and = attachments are free from any virus, we advise that in keeping with good computing = practice the recipient should ensure they are actually virus free. =

 

 

 

------=_NextPart_001_044D_01C9BE74.A5CC8E60-- ------=_NextPart_000_044C_01C9BE74.A5CC8E60 Content-Type: application/pdf; name="The 2nd Plant Managers Forum 2009.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="The 2nd Plant Managers Forum 2009.pdf" JVBERi0xLjYNJeLjz9MNCjc4OSAwIG9iag08PC9MaW5lYXJpemVkIDEvTCA0OTQ5OTgvTyA3OTEv RSAyMjU2ODYvTiA0L1QgNDc5MTcwL0ggWyAxNDU2IDQ1NV0+Pg1lbmRvYmoNICAgICAgICAgICAg DQp4cmVmDQo3ODkgNTgNCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTkxMSAwMDAwMCBuDQow MDAwMDAyMDQxIDAwMDAwIG4NCjAwMDAwMDI1NjYgMDAwMDAgbg0KMDAwMDAwMzAxOSAwMDAwMCBu DQowMDAwMDAzMTUyIDAwMDAwIG4NCjAwMDAwMDMxODkgMDAwMDAgbg0KMDAwMDAwMzIzNyAwMDAw MCBuDQowMDAwMDAzNDY2IDAwMDAwIG4NCjAwMDAwMDM1NDQgMDAwMDAgbg0KMDAwMDAwNDI5OSAw MDAwMCBuDQowMDAwMDA0NDMxIDAwMDAwIG4NCjAwMDAwMDQ4MTEgMDAwMDAgbg0KMDAwMDAwNTIw MSAwMDAwMCBuDQowMDAwMDA1MzI2IDAwMDAwIG4NCjAwMDAwMDU1NDkgMDAwMDAgbg0KMDAwMDAw NjAwNSAwMDAwMCBuDQowMDAwMDA2MTQzIDAwMDAwIG4NCjAwMDAwMDcxMzUgMDAwMDAgbg0KMDAw MDAwNzk2NyAwMDAwMCBuDQowMDAwMDA4MDk5IDAwMDAwIG4NCjAwMDAwMDkwODcgMDAwMDAgbg0K MDAwMDAwOTQyMSAwMDAwMCBuDQowMDAwMDA5NTc2IDAwMDAwIG4NCjAwMDAwMTA0ODUgMDAwMDAg bg0KMDAwMDAxMTQ5NiAwMDAwMCBuDQowMDAwMDE0MTkwIDAwMDAwIG4NCjAwMDAwMTc2NzAgMDAw MDAgbg0KMDAwMDAxNzkxMiAwMDAwMCBuDQowMDAwMDE4MTM2IDAwMDAwIG4NCjAwMDAxMTM0NTAg MDAwMDAgbg0KMDAwMDExMzc3MyAwMDAwMCBuDQowMDAwMTE1MDMzIDAwMDAwIG4NCjAwMDAxMjQ3 MzUgMDAwMDAgbg0KMDAwMDEzMTg4NyAwMDAwMCBuDQowMDAwMTQ1MTc1IDAwMDAwIG4NCjAwMDAx NDkwNDYgMDAwMDAgbg0KMDAwMDE1NDE2MSAwMDAwMCBuDQowMDAwMTY0MTk1IDAwMDAwIG4NCjAw MDAxNjQ0NTEgMDAwMDAgbg0KMDAwMDE2NTY3NiAwMDAwMCBuDQowMDAwMTY1OTEwIDAwMDAwIG4N CjAwMDAxNzQ2NjUgMDAwMDAgbg0KMDAwMDE3NDkxNCAwMDAwMCBuDQowMDAwMTc1MTE5IDAwMDAw IG4NCjAwMDAxNzU0MDUgMDAwMDAgbg0KMDAwMDE5NDgwNCAwMDAwMCBuDQowMDAwMTk1MDQ0IDAw MDAwIG4NCjAwMDAxOTUyNDggMDAwMDAgbg0KMDAwMDE5NTYyNyAwMDAwMCBuDQowMDAwMjAzMjE5 IDAwMDAwIG4NCjAwMDAyMDM0NzQgMDAwMDAgbg0KMDAwMDIwMzY4NCAwMDAwMCBuDQowMDAwMjAz OTcyIDAwMDAwIG4NCjAwMDAyMjQ5NTYgMDAwMDAgbg0KMDAwMDIyNTE5NiAwMDAwMCBuDQowMDAw MjI1NDAwIDAwMDAwIG4NCjAwMDAwMDE0NTYgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSA4NDcv UHJldiA0NzkxNTgvUm9vdCA3OTAgMCBSL0luZm8gNzg4IDAgUi9JRFs8MkRBNTU2OUQ5OTMzQjk0 RjlBNzRCREMwMDZGMTEwRTg+PDY3MkIxQTREODdDRERBNDM5MkUyRTdBMUY2MEE2RkI3Pl0+Pg0K c3RhcnR4cmVmDQowDQolJUVPRg0KICAgICAgICANCjg0NiAwIG9iag08PC9MZW5ndGggMzYwL0Mg Mzg2L0ZpbHRlci9GbGF0ZURlY29kZS9JIDQwOC9PIDM3MC9TIDE2Mj4+c3RyZWFtDQp42mJgYGBn YGAzYmBjYDDZyCDEgABCDKxAORYGjgOFDWetGdwEGBiO3pmmN4EBDUgENi48mvfxD8fRM5ImX7+4 58VaNHMABRefmqgWc+h9vEvZ08sdBj2SJjwJAVfUzs+JAZmtZJrW0QHSzRjRAQZgoyDMBpChcBuB HGUGlhvyQNociAPBClUZBBm+MGQw8IA4EcwMDEFM5xj0G0IP6CiwNrBeYOthOMW8m7G3QfxA2QOh CcwbeBewz+FKZNvZYOwgXu50geODsIx3k/RpyYfN+5qqDhVcYLshNIGxS4mPIYtBi0FeZZcCWwTT HKY1ss0MuQzaDvKpsgYgAcZPDHGVhxtMGEQWaikwPQivYFzGkMKg3WDqILpAToDVgn0BwzfGuwz6 DOIMtgfYHJh2sIcw1jFmMpxoQA0xWwY2ngdAmpuBgVkdSHswsAkAY4HpFAOj3gOYImYRBnZfXVAI AfEhgAADAC1uZTgNCmVuZHN0cmVhbQ1lbmRvYmoNNzkwIDAgb2JqDTw8L01hcmtJbmZvPDwvTWFy a2VkIGZhbHNlPj4vT3V0bGluZXMgNjEgMCBSL01ldGFkYXRhIDc4NyAwIFIvUGFnZXMgNzg2IDAg Ui9TdHJ1Y3RUcmVlUm9vdCA3MiAwIFIvVHlwZS9DYXRhbG9nPj4NZW5kb2JqDTc5MSAwIG9iag08 PC9Dcm9wQm94WzAgMCA1OTUuMjIgODQyXS9QYXJlbnQgNzg2IDAgUi9TdHJ1Y3RQYXJlbnRzIDAv Q29udGVudHNbNzk4IDAgUiA4MDAgMCBSIDgwNCAwIFIgODA2IDAgUiA4MDcgMCBSIDgwOSAwIFIg ODEyIDAgUiA4MTMgMCBSXS9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNTk1LjIyIDg0Ml0vUmVzb3Vy Y2VzPDwvWE9iamVjdDw8L0ltMCA4MTggMCBSL0ltMSA4MjAgMCBSL0ltMiA4MjEgMCBSL0ltMyA4 MjIgMCBSL0ltNCA4MjMgMCBSL0ltNSA4MjQgMCBSL0ltNiA4MjUgMCBSPj4vQ29sb3JTcGFjZTw8 L0NTMCA3OTQgMCBSL0NTMSA3OTUgMCBSPj4vRm9udDw8L1RUMCA3OTIgMCBSL1RUMSA4MDEgMCBS L1RUMiA4MTAgMCBSL1RUMyA4MTEgMCBSL0MyXzAgNzkzIDAgUi9DMl8xIDc5OSAwIFIvQzJfMiA4 MDIgMCBSL0MyXzMgODA1IDAgUi9DMl80IDgwOCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFn ZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzAgNzk3IDAgUj4+Pj4vVHlwZS9QYWdlPj4NZW5kb2Jq DTc5MiAwIG9iag08PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDc5NiAwIFIvTGFz dENoYXIgMTIyL1dpZHRoc1syNzggMCAwIDAgMCAwIDcyMiAwIDAgMCAwIDU4NCAwIDMzMyAyNzgg MCA1NTYgNTU2IDU1NiAwIDAgNTU2IDU1NiAwIDU1NiA1NTYgMzMzIDAgMCAwIDAgMCA5NzUgNzIy IDcyMiA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggMCA3MjIgNjExIDgzMyA3MjIgNzc4IDY2 NyAwIDcyMiA2NjcgNjExIDcyMiAwIDk0NCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgNjExIDU1NiA2 MTEgNTU2IDMzMyA2MTEgNjExIDI3OCAwIDU1NiAyNzggODg5IDYxMSA2MTEgNjExIDYxMSAzODkg NTU2IDMzMyA2MTEgNTU2IDc3OCA1NTYgNTU2IDUwMF0vQmFzZUZvbnQvQXJpYWwtQm9sZE1UL0Zp cnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTc5 MyAwIG9iag08PC9TdWJ0eXBlL1R5cGUwL0Rlc2NlbmRhbnRGb250c1s4MzIgMCBSXS9CYXNlRm9u dC9FR0JJUEIrQ2FsaWJyaS9Ub1VuaWNvZGUgODMzIDAgUi9FbmNvZGluZy9JZGVudGl0eS1IL1R5 cGUvRm9udD4+DWVuZG9iag03OTQgMCBvYmoNWy9JQ0NCYXNlZCA4MTQgMCBSXQ1lbmRvYmoNNzk1 IDAgb2JqDVsvSW5kZXhlZCA3OTQgMCBSIDI1NSA4MTkgMCBSXQ1lbmRvYmoNNzk2IDAgb2JqDTw8 L1N0ZW1WIDEzOC9Gb250TmFtZS9BcmlhbC1Cb2xkTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRX ZWlnaHQgNzAwL0ZsYWdzIDMyL0Rlc2NlbnQgLTIxMS9Gb250QkJveFstNjI4IC0zNzYgMjAwMCAx MDEwXS9Bc2NlbnQgOTA1L0ZvbnRGYW1pbHkoQXJpYWwpL0NhcEhlaWdodCA3MTgvWEhlaWdodCA1 MTUvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTc5NyAwIG9iag08 PC9PUE0gMS9PUCBmYWxzZS9vcCBmYWxzZS9UeXBlL0V4dEdTdGF0ZS9TQSBmYWxzZS9TTSAwLjAy Pj4NZW5kb2JqDTc5OCAwIG9iag08PC9MZW5ndGggNjg0L0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry ZWFtDQpIiaxVW2vbMBR+9684j90gsq6WBCHQpt3oQyGlhj4Oz3FSj0bt7HRj/35H8iV2467bCIFE QTrf5Xw69kUaxSuYz+Ob5fUlUFgsLi6XEMWf7yhs6yhe8i8UGKSbiFGi8AD+axZGUJJQKiDdRXOK i0X6Lbq68cUHQNYBMthGcZq2WDNKsAKXOYRVAulPEEmAx5+EE2VACUa0pNITnHG3htVj5vZwk7ls W1Q1fHqqXnbwAVkDBg9oHkgRgbJmjHBrIF1jMaU2HAzyrtDytXssXXH3kD0XvVbeaf0ezVhCpARp ENmAlJJwicIEVEV0Dw5P0H6Ta2JwjxHLh9tGclBWEdQ1k4oSI8Pux34bC0w4gQfaf325Z2TaWst1 0xODZiSaVAoabd5wJ9C30kC+Q1s7CpdP0W1j9Lb9XIwyFp1N6iM55EsJ1yxEMk66MdgyHdJ+K3FU 3OOHeDVPQAjic1y/fVG46a9ef0vQVFCB7EIR7Cc6JUnSiDg7BDqEsR2M9g315WHRAmh0YfmfAEQ/ AqhcSWwRVx1Ss5Iiwa5oaYltb/9ZOrxbr8P32Zrkr8OPlzh5ee0JSWLxy0oGUOfO11GE6oAlJSxU bSZC1myU8njwsAynhLUZK1BehmGa8K415/lDWfwo3Ra+FvUenqss35d5UUPp4DlM4S5M4a7A5Ytb FxVsSpe5vMweIa/KuqwH3T2v9uUGEby69BdOXLyqSrf38H2vmTQoNIzvccMxO4bTpXGMrPF3dNTz YXrsdXrYRMXA28ZI/LPg4X90tfWTKAN2/i57cRL2YpJdTLDTEXv7sHwDtd3tagUf1fKTKOeTyuWx coXBD9jdSdjdJLt6N7X1SdjXk+zJFLv8x9SOUPVr1Jkg2qrwUmwLVycxtZqkN8emNL6CD6bgtwAD AC3W5y4NCmVuZHN0cmVhbQ1lbmRvYmoNNzk5IDAgb2JqDTw8L1N1YnR5cGUvVHlwZTAvRGVzY2Vu ZGFudEZvbnRzWzgzNiAwIFJdL0Jhc2VGb250L0VHQkpQQitTaW1IZWkvVG9Vbmljb2RlIDgzNyAw IFIvRW5jb2RpbmcvSWRlbnRpdHktSC9UeXBlL0ZvbnQ+Pg1lbmRvYmoNODAwIDAgb2JqDTw8L0xl bmd0aCAzMDkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJvNXPb4IwFAfwO3/FO24HSlta CokxQUWzZKjR+gcsTg0ezGK47L8fThMLfQuXxy4cCO996K9vAQBe3l/tOSjKKQRRfq2r48e+htEo st9fB4jW1+pSV5cTjMeTWfMJZ0KlcApCzriScH/az8Dtsr6Vl9O3GcTZs85o1dRxlmgB4bMuJ9Fz TFfc101iXH1Joi9RXWC6cnVLoltUl9jMt3S41f3ZFdCucbdrGDOZJRAKJh+FJcmgSpRX/qBSo/9r O+neBR1yOyW9+pBjN736gkRfoHqKrLt08YIEL1AcyTDDM1ffkOgbTNdohrUmfuue4+Y15wrsHrz+ W/RIaz+mfqs1EzJzz/WcZJBz9B/QsGpdEysSfYXqXqh1d9eQ64tEWueO2pHoO1Tvj7QB4hx+BBgA aI/2lQ0KZW5kc3RyZWFtDWVuZG9iag04MDEgMCBvYmoNPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250 RGVzY3JpcHRvciA4MDMgMCBSL0xhc3RDaGFyIDEyMS9XaWR0aHNbMjc4IDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAyNzggMCAyNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjY3 IDAgMCAwIDY2NyA2MTEgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDU1NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAgMjIy IDgzMyA1NTYgNTU2IDU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwIDUwMF0vQmFz ZUZvbnQvQXJpYWxNVC9GaXJzdENoYXIgMzIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUv Rm9udD4+DWVuZG9iag04MDIgMCBvYmoNPDwvU3VidHlwZS9UeXBlMC9EZXNjZW5kYW50Rm9udHNb ODE3IDAgUl0vQmFzZUZvbnQvRUdCSk5BK1dpbmdkaW5ncy1SZWd1bGFyL0VuY29kaW5nL0lkZW50 aXR5LUgvVHlwZS9Gb250Pj4NZW5kb2JqDTgwMyAwIG9iag08PC9TdGVtViA4OC9Gb250TmFtZS9B cmlhbE1UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMC9GbGFncyAzMi9EZXNjZW50 IC0yMTEvRm9udEJCb3hbLTY2NSAtMzI1IDIwMDAgMTAwNl0vQXNjZW50IDkwNS9Gb250RmFtaWx5 KEFyaWFsKS9DYXBIZWlnaHQgNzE4L1hIZWlnaHQgNTE1L1R5cGUvRm9udERlc2NyaXB0b3IvSXRh bGljQW5nbGUgMD4+DWVuZG9iag04MDQgMCBvYmoNPDwvTGVuZ3RoIDM4NS9GaWx0ZXIvRmxhdGVE ZWNvZGU+PnN0cmVhbQ0KSInElc9LwzAUx+/9K95RD83y8qsJlIFt5/Aw2KF3Ed1GBYeWgfjf+2q3 NVmd9BCQHl5JyCefPMI3AAB5PluVDxVoA/N5UZWQcJZpBTuqNtOQcsaVgPoluYHb+pVGUVmaPY5f zC5WBJitB2p2SUVaQx8VJTVzYKRlynIJ9dtphxP9B/4H246Nu7qkaix8AsKKFpTiEem33ibk2YJU jPcK/Z+ShlkD2lmmjxq5RCPm5x3v2kOzfXo+dBvXX+8bmK3bZn9o9rth/74nfV2OenMB9I7grh0B aa3xmp9zVcZ1CoGDk+GTnVBYHtUpBHpOOL1PnMu4fQqAnpO45pQK5ugCpsgU2mOvTWSpAOhJyemN qmRkpwDoOanpTq6wcZ0CoOekJzupotBRnUKg5/RLAv/7JR/l9/mSS+Yy4V9yjXwRVSoEelJXg3+c UFKYuAkVAD2n6Umu8D5uaobAwSmbnuS8chg5DDzgok4+6Fm3NKed7l7d1Crsnt12k8C3AAMA5Cbq SQ0KZW5kc3RyZWFtDWVuZG9iag04MDUgMCBvYmoNPDwvU3VidHlwZS9UeXBlMC9EZXNjZW5kYW50 Rm9udHNbODQwIDAgUl0vQmFzZUZvbnQvRUdCSk5CK0NhbGlicmktQm9sZC9Ub1VuaWNvZGUgODQx IDAgUi9FbmNvZGluZy9JZGVudGl0eS1IL1R5cGUvRm9udD4+DWVuZG9iag04MDYgMCBvYmoNPDwv TGVuZ3RoIDkyMS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImsVVuPm0YUfudXnEeoBJ4Z Bgaq1UpZ7AdH2bYJVHmIqorgwaZrwAtsN/n3PWcGbKfattq2tjzXc/2+c8YAAB+/g855dBgkkgdp AlEaBQL8eTdo5yPer7KcQTUCAxbEKQ6p5ABj1aGeRMkkNnpMQJgGQpJa7bzH713hrH6Cm5vVfbZd g4Tb27t1Bs6qKBhwKGqHBYwxXFXg05KHUDyjm2IAnpA7miIRiBhkFAVhzFCgdT652Ydtsc3evPN4 4sI2z3/e5FDQ5kePu3C3AS9U7pv1+sMmzzfr78H7pXjrbO7R96aY0xVLzCZZTIGSfRUaAUcYGCas cAxVbCHhZFOEqEgeJAiWBNEFErIuQoW6i38SUHKx/mgwjQJlMY3APxu4iu5fB//o0LGSCHsUGYSt e7tHErhAGpi0MYYpfiRUrbPathzWvUnh/TmR/4piliNyUSJxVGiDBYkMAfLsB4fDMyRwj1XyFhwL xIyK/2dYzni1zsHJX6i7aKk7BnuqPT7XHpUdo4LjjDIw5WZWKogTkCFSm9iCc8ErfrP1c2U3Ptdz Jn4V1mhqzKQgEspVcomTtXHDWJjevmBGXbXFElqgEkWx7WbX33YMVyZ06p3INMxF/BPK+0KoZVo3 oxe5Ff6ePJ+7tKFf0+29GGWUezqWuO/ocoIeD0+01Hg2eNKluwlbquk7Wh5hnA8Gc0Ni+0bPRtGl codld+q73exm6s14oCugWA7kwxg80lm31x63wcHnoX/aHyYP+/rzVzpd9JrOuBu6q5jQrA2rbsxx R8Ybe1TNKTQoZFIer16BK/iTF1i8lIbPg0iFNKkwJID/ksb0VTTa504uPIbxP/C4+VK2DbKE+Zhx TwPxlx0uh3rU0JbEJSe6pVuX1WQWA+F1pdh3i75R773UfUZH9gjposumRRJOi3b/O+605xODJU2j 0YT6+K1y43HmWuuTkdCAUWgwNmsUc6G01yawzgsvPnSld0bFCEx2Q9zSXKKAWVSUS3kkZ205eH7s PugJqqHBvBlSzQ3VM3gvMc7Z/0Q556/nnCVnzv+Wcua+6/sHbCAoJ0oVEeZU7cL9iniPOGNbIdsP GsanQRPYlKv1IRYf+GeMTpADXddN1ehuAv1FV08TNg/0NVQ9hWiVzsUoTDHiC0b5z6G1Jw8JLjty DuNkOr2cNDb/iHzuAJ+RrjPRts1uRKGJWpx6F3TVd33bVCY+Qhyf+D8EGABsyO/aDQplbmRzdHJl YW0NZW5kb2JqDTgwNyAwIG9iag08PC9MZW5ndGggNzYxL0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry ZWFtDQpIiaxVTW/bMAy951fwKB2cRnYSJ0ARYGt76IACO/g2DIMbO4lWf8FW1mW/fnyUnaVY2q5D D5YtfjxSfBRNRGQo2YwmlKyJl0e6nEwm0Sr5PrpIkkmvHLNsCYtwNjZT2GUj5fZtWduCNNve3F3R 6OIzXV5e3F3dXpMJabX6eA3hVfgtPIkRzGbj6TSmwIzjKAIQB4yWq3Mg0REkScyQSryI+wQk8tMs zUzOgXxjHObE/AvbB2EYD6+bn3qqUn5Kfmxl9VxVW3J6oXY6MCpnKe0bHYUqg5WDICNbNkXeO+Fd wdbpcCFQztYVbRiihrgltxOYArr7uqW1NkbVlWshWMNBG1GbhXrktHijY+VqrFDXjfhrE/VqZOl2 vAzQbJjlQ3qtrQUZqJYPw8oS+/ahz1bCCXCVWSTbISHSX5NPf1d/+hyF0ibM3yyO/onG2ZtpDI8s hi+xGEXqgw5RyZna2VwHC/UDpcTZ68bZcl9SzroKS8vP9qBNqIiLwkIsW2hKsXG0rSEqOl7o3luu e8ccGgdccc3AAFqBKywIMBGQwYSAwn2hWvGEcmuBJtp1r0S7NIVAAvE8D/P34iF+Ew/B0/sUvXaf rm233utgqrrOVnhvdST92dXYFaJDz4kNOZFCz3XEZ8u9iWtjwCGXk2Fjla51wOXae4NgzrfMKJEd +JaRYGw4Ptc75XvJ8g4tnuJLAmUS5U8A2Qsc30Wkg88KmYpNgSUVz+r0FGeJWbwXMcv/ICY+ErN8 kZiJupUz55Wv/waFG47WM5CelKr0G9RZ9NYXaKjETrDSwskH9Z5c/U3udLD0tOwGhF9pm3m6QSaP MMN0M4z39lnQwc/LnhawRPe+kbxB3nWg8zwJ4eSdSAjN2382y+OYil772Ww2+em9RzlkVEFaYHfw kxg9r9HFeLiv8+EDkuP84WGR0e44igoLyfDzmosTNbVMHf+DsjLZqLUy8B/6CGQrkrj1vpWBtW+a wiciIxWuqcR9pvjP/uVfKT79FmAAPxX6mQ0KZW5kc3RyZWFtDWVuZG9iag04MDggMCBvYmoNPDwv U3VidHlwZS9UeXBlMC9EZXNjZW5kYW50Rm9udHNbODQ0IDAgUl0vQmFzZUZvbnQvRUdCS0xCK1Np bVN1bi9Ub1VuaWNvZGUgODQ1IDAgUi9FbmNvZGluZy9JZGVudGl0eS1IL1R5cGUvRm9udD4+DWVu ZG9iag04MDkgMCBvYmoNPDwvTGVuZ3RoIDkxNy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K SImsVVmP2zYQfvevmKeCKiAuL5ESsNiH2AGaBEa3WAF9CIpAsWlbgS3tSnKD9Nd3hjqsXW+CFKgM UyPOcI5vDgIAvF0vYXFzD7e3N+vluxUoDXd3b1a0mecSJOS7heAudSAg3y4YRPkXYomeFQsuhEBy A0Th6fwrzOQ/4oFYKTe+7ps6ijP2d6Q0K7dltYdy64sWimoL3aE+7w9d/NjUG9+2voXGH4uOhLo6 +it/vxCTHUV2lOHZZGZTVxv/2EXKsjbSDOodrPwJ9carpoximaBRaZmvADfPu2LTnRtSTX4JdI/0 X4FhJjCW6pMa0CDTsbLcOA2x5E5rcuFWCJ3dIThXSpKfQRT165GnnM76SCcp1C40/e+u4ZduhIWO fYWPbNlEMYZK2EWxYXtaEF6PwUpN4EtGkAjWljXxghTsAt1AAZFjH4ryH9/vb870Onbh1USSeUwX 0dvA7qXanuvheNEY7Madb06YHaIPviW7jlKRMI+qgpyP4oS1bUjBHIgQFkWk7Zjo2xGDK5TtPFUD PFLwBM/hFxGO2xSzkXJnhIH89ELZ23zxhDZToyDJEi4UxKmRPLVYhos/f4VqYEuepUFiEMAvEkD+ zfJBwKYli9yiwzwzEqDdVHhOSY0uDIoTzWVQu1v8gb83+TwSp8ZIBJcmhf1Vu9kx38KFNlCkk8Ls KSkTnljs5IybVGiKdGhDzZSEX1AM1sU3UEJk8HAoqv2hKGF5KKvi9TZw00wQ6E0wrKZOJA9kbx5f MsOGwGAzblVvmq3L49FXVXk+wW91Fc3gnpuYOu1pMepwBJKSGJMBQs+OOBNeEySXKrl4oVJJh565 sQ+W8974FebzHv3RaJvbSLm2z208lUWNQXb+GHD9Xqz2/4xVu4yS/h9idd+JVb6mPbVcv0ASqyV6 pQNd9rJun1eKCMMJg8OGCdoDpTDYFMtGc2vGWv292RcVjp8tfI5ix771s5/jICWdSpls8hS909k4 SIeHnLu4gOIpiRtESU63xfQ84E2UscdIKcVqXC2OJBXuEGqXfqcJNFw/a2TQHCP2NoiWuBpW9AcC fR/Rvdfv9Iq6sPZm/Gx/8H4eLDmuUvxI55fFVFPvqmNZeSy1Rz+lIRWz6sJhl2CbC6MD5DgRtBVh giDuVmf4YL0ZRMshqRxsTqj1pGBVY90EO8+LJ5XzUUCj1gyj9jICUkXFHLQO42e6vX70p0EM/wow AJnl55oNCmVuZHN0cmVhbQ1lbmRvYmoNODEwIDAgb2JqDTw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9u dERlc2NyaXB0b3IgODI3IDAgUi9MYXN0Q2hhciAxMTkvV2lkdGhzWzI2NyAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDk0IDAgNDE4IDAgMCAwIDQ3NCAwIDI0NiAw IDQ4MCAyNDYgODEzIDUzNyA1MzggMCAwIDM1NSAwIDM0NyAwIDAgNzQ1XS9CYXNlRm9udC9FR0JL SUIrQ2FsaWJyaS1Cb2xkL0ZpcnN0Q2hhciA0Ni9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlw ZS9Gb250Pj4NZW5kb2JqDTgxMSAwIG9iag08PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlw dG9yIDgyOSAwIFIvTGFzdENoYXIgMC9XaWR0aHNbMF0vQmFzZUZvbnQvRUdCS0lBK1pXQWRvYmVG L0ZpcnN0Q2hhciAwL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoN ODEyIDAgb2JqDTw8L0xlbmd0aCA4MzgvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJ1FTL btpQEN37K2ZpL7jct+0qQmogi0SiSoV3VVU5YIITY7s2NMnfd+aaVwigVuqmWNij+zhzzrwAAG7G Q/BuEq9/WxZ5mU0WaZ3B1VV/PLwdQSRhMLge4YmfntAxU0rFcWyB46Mss5ZzrkKQaIuNLTRnIsRT MoTpEmGXCkaV99Vzjq7R0f0eXm3h+0P5Q4OAZO4J6eDxoyLDVNQhRlxBsvSuyMm5/yB58i7L0Xs5 UcS4xFtadWokszFpi0HLEN3SVnxCjT6vxlxUY6Rg+s/FnBV36NEeeuSdR85kKNCaguDMdN7JkIoZ DKYwzGquyf83R2DQszsif2v/D/cH35O7j5ELt5G7HIR/QpAIYNZ1BI9eP0l2ecLNiPKEGZNY58kL CMXiqEuZs5QImbbvk+bfp82qzBrY/sbZLE8hkFIfbAUnVUdb1eRSO+c9x0OQ9x5WKJcSeprF3EIy 83y4/AtOFWW8Cy1dD3qGS4dDlvUPmJ1r05jv21RHmxo2mnGDjRhajIrYN2u4W+7605ztz1js1B8l AmPRNcx+9FjDcPgRuu2a1f8o+iz/g6kZWWbOjRn+kb09YN8fTjhMWyRJD7TT0rMMk6YRQ4KMaeZi tHGoNJk3744PJ1hN2qIzZkJ6S2UAJsMvqDI08AIRjBHsDjzFEQbnETLimPINXA/xlAN0rja7S2/h TY6jqfa1pAR6UjhdscpN2FE9KnTVFTpWWuwK/d1oEpqhRMlpIquuyG9eF/lDvsqrMjA+pOUM2roq 26ppF3kNVV1XzSqI/HWJZ7L20+l6j/VRxsWekTyofkuUwg2jcEdIbJkToc8B1m6RL/NVFoT+LOgJ H0q01mQtH9DCvkNG1dy96xpXqgbN1RotohnEftaiDSktZ5D+CoTx07xIcfGhIFiYV/hu4I12KkKm y7CqCPOpIojSeaYrnUVQRb4icLIfCZtA1vWWTTd+UIjZKRaKFHPoCaYoECMU2FZFILi/RqL4qUq6 XjeIWyFP6+ezrGlxiZbTgtazFM3ZG23CKn3OS3LvtmfuRloSq/TRia3wPQ+QL60tMgLKXunUtFi3 uTufYYqJMuG0dN75w3TT4ZqcTZ8J3QG2qAvgtwADAI0w7sQNCmVuZHN0cmVhbQ1lbmRvYmoNODEz IDAgb2JqDTw8L0xlbmd0aCA5NDAvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJhFVtb9s2 EP7uX3EfqW2iRUqUpSIItiYpugEBslVAPxRFoTq0rcWiUome0X+/u6MlK6mBxgh9Rx7v5bmHZwCo /lokMklSDdUaYhJLqI6QQKxkmuZQ3S4+ic5Bt9lEpbBRrEQPtQe/i1bCQvQZHSyrKgEF1WbBDrQi XyRlKfnKZWZy9Fg9oisdxblw6OoRHvZ1UJTwUWwE3Aed163tB/qGd11Ph4cW+GoSafxHoRxDq1no LB9D5wWFVoaLOMWWcIe+C7GO4lLsYHgmpXO0Dh2tFBJPSGwwDp9DVIjn87UnQoDVreXjhu8EIBhJ NSEZoIy1kqtST4BSJr5u9ogBllYI+0ghfEfrV4uoDp7E4YBig0Ye8YHvkTKiO/TAN77xGYutdSh7 tBsoM6hRc+yxI6OeXdX7sXcD7oGnKHULx0ilotnvg9Bxb59gzZmRIZntMToHB6o23KCG7Vg/pRWq 55rVmT26COyxjpwdKN2Gkt0CpburaR0Lg61ltaZ8HynwpnFcvaWdnnY8u3BcZkdlsjQhQ9a89R/t hGo9wkN+ZTS26O7+BhbLB7i6Wt7f/HkLpYHr67e3uMnNS5k/L8j/LsqxUUD0P/ScuaWMMJ5KhNt0 pLSR0qL2DSnuN6bMno5tTfBzCWs+o/v12k/pvHo6ycRfHfi7kmo18fd+kPBx13iHxekEwU/z0JYP O+vg1XvgcorgTqssI3eFLHQWvNGbhqj690dA8hGQc27sy5wnRBp4nb/g9K9FDph1brBOo3FRtBhS L+Wmz/6KNCSXFMVYKgJu2/BIuELfXZw0kw+l2Ecm85UefSCtY20EAkYDxFlkSoFMiJHCPFqwjzRu fm954PCUYcuGzfeNe6L9oG2lY2t/qRIdSBPmTT4CLBneGYihF6uxnyKc3+gvE8pZeTq7Qiqk12N3 7qrFN7xeZBpMaWSCs6TIlES8e7v4+Au407GSZcEWJwPUyADPlzcfElgP6DyReYlLmSmAYe0WtKMm v+kKGUKXNou/8fO2mjNjVfzIjMuspRYk9KUzibe0lhnWA1WLXfnHbpvB9/RYHLzvPOJs38BEHqOV NgZ7rjXPnPD1GnSt56CXEn9oTpj+5O9CS9TLflSVnpE+FGZGSh2Px8gQiYxo8Qei7qMMKUGUyXD2 GJyW2SQ/NbRu0UyucVp17SsGh+AYJTPzBMJ7/KP3zQYHBYFffX+2sHzoG+cbt531IA2OFHWOASch Mwa7O8dcvI9mTEIQ/hdgAGka12INCmVuZHN0cmVhbQ1lbmRvYmoNODE0IDAgb2JqDTw8L0xlbmd0 aCAyNTk4L0ZpbHRlci9GbGF0ZURlY29kZS9OIDMvQWx0ZXJuYXRlL0RldmljZVJHQj4+c3RyZWFt DQpo3pyWd1RU1xaHz713eqHNMNIZepMuMID0LiAdBFEYZgYYygDDDE1siKhARBERAUWQoIABo6FI rIhiISioYA9IEFBiMIqoqGRG1kp8eXnv5eX3x73f2mfvc/fZe5+1LgAkTx8uLwWWAiCZJ+AHejjT V4VH0LH9AAZ4gAGmADBZ6am+Qe7BQCQvNxd6usgJ/IveDAFI/L5l6OlPp4P/T9KsVL4AAMhfxOZs TjpLxPkiTsoUpIrtMyKmxiSKGUaJmS9KUMRyYo5b5KWffRbZUczsZB5bxOKcU9nJbDH3iHh7hpAj YsRHxAUZXE6miG+LWDNJmMwV8VtxbDKHmQ4AiiS2CziseBGbiJjEDw50EfFyAHCkuC845gsWcLIE 4kO5pKRm87lx8QK6LkuPbmptzaB7cjKTOAKBoT+Tlcjks+kuKcmpTF42AItn/iwZcW3poiJbmlpb WhqaGZl+Uaj/uvg3Je7tIr0K+NwziNb3h+2v/FLqAGDMimqz6w9bzH4AOrYCIHf/D5vmIQAkRX1r v/HFeWjieYkXCFJtjI0zMzONuByWkbigv+t/OvwNffE9I/F2v5eH7sqJZQqTBHRx3VgpSSlCPj09 lcni0A3/PMT/OPCv81gayInl8Dk8UUSoaMq4vDhRu3lsroCbwqNzef+pif8w7E9anGuRKPWfADXK CEjdoALk5z6AohABEnlQ3PXf++aDDwXimxemOrE4958F/fuucIn4kc6N+xznEhhMZwn5GYtr4msJ 0IAAJAEVyAMVoAF0gSEwA1bAFjgCN7AC+IFgEA7WAhaIB8mADzJBLtgMCkAR2AX2gkpQA+pBI2gB J0AHOA0ugMvgOrgJ7oAHYASMg+dgBrwB8xAEYSEyRIHkIVVICzKAzCAGZA+5QT5QIBQORUNxEA8S QrnQFqgIKoUqoVqoEfoWOgVdgK5CA9A9aBSagn6F3sMITIKpsDKsDRvDDNgJ9oaD4TVwHJwG58D5 8E64Aq6Dj8Ht8AX4OnwHHoGfw7MIQIgIDVFDDBEG4oL4IRFILMJHNiCFSDlSh7QgXUgvcgsZQaaR dygMioKiowxRtihPVAiKhUpDbUAVoypRR1HtqB7ULdQoagb1CU1GK6EN0DZoL/QqdBw6E12ALkc3 oNvQl9B30OPoNxgMhobRwVhhPDHhmATMOkwx5gCmFXMeM4AZw8xisVh5rAHWDuuHZWIF2ALsfuwx 7DnsIHYc+xZHxKnizHDuuAgcD5eHK8c14c7iBnETuHm8FF4Lb4P3w7Px2fgSfD2+C38DP46fJ0gT dAh2hGBCAmEzoYLQQrhEeEh4RSQS1YnWxAAil7iJWEE8TrxCHCW+I8mQ9EkupEiSkLSTdIR0nnSP 9IpMJmuTHckRZAF5J7mRfJH8mPxWgiJhJOElwZbYKFEl0S4xKPFCEi+pJekkuVYyR7Jc8qTkDclp KbyUtpSLFFNqg1SV1CmpYalZaYq0qbSfdLJ0sXST9FXpSRmsjLaMmwxbJl/msMxFmTEKQtGguFBY lC2UesolyjgVQ9WhelETqEXUb6j91BlZGdllsqGyWbJVsmdkR2gITZvmRUuildBO0IZo75coL3Fa wlmyY0nLksElc3KKco5yHLlCuVa5O3Lv5enybvKJ8rvlO+QfKaAU9BUCFDIVDipcUphWpCraKrIU CxVPKN5XgpX0lQKV1ikdVupTmlVWUfZQTlXer3xReVqFpuKokqBSpnJWZUqVomqvylUtUz2n+owu S3eiJ9Er6D30GTUlNU81oVqtWr/avLqOeoh6nnqr+iMNggZDI1ajTKNbY0ZTVdNXM1ezWfO+Fl6L oRWvtU+rV2tOW0c7THubdof2pI6cjpdOjk6zzkNdsq6Dbppune5tPYweQy9R74DeTX1Y30I/Xr9K /4YBbGBpwDU4YDCwFL3Ueilvad3SYUOSoZNhhmGz4agRzcjHKM+ow+iFsaZxhPFu417jTyYWJkkm 9SYPTGVMV5jmmXaZ/mqmb8YyqzK7bU42dzffaN5p/nKZwTLOsoPL7lpQLHwttll0W3y0tLLkW7ZY TllpWkVbVVsNM6gMf0Yx44o12trZeqP1aet3NpY2ApsTNr/YGtom2jbZTi7XWc5ZXr98zE7djmlX azdiT7ePtj9kP+Kg5sB0qHN44qjhyHZscJxw0nNKcDrm9MLZxJnv3OY852Ljst7lvCvi6uFa6Nrv JuMW4lbp9thd3T3Ovdl9xsPCY53HeU+0p7fnbs9hL2Uvllej18wKqxXrV/R4k7yDvCu9n/jo+/B9 unxh3xW+e3wfrtRayVvZ4Qf8vPz2+D3y1/FP8/8+ABPgH1AV8DTQNDA3sDeIEhQV1BT0Jtg5uCT4 QYhuiDCkO1QyNDK0MXQuzDWsNGxklfGq9auuhyuEc8M7I7ARoRENEbOr3VbvXT0eaRFZEDm0RmdN 1pqraxXWJq09EyUZxYw6GY2ODotuiv7A9GPWMWdjvGKqY2ZYLqx9rOdsR3YZe4pjxynlTMTaxZbG TsbZxe2Jm4p3iC+Pn+a6cCu5LxM8E2oS5hL9Eo8kLiSFJbUm45Kjk0/xZHiJvJ4UlZSslIFUg9SC 1JE0m7S9aTN8b35DOpS+Jr1TQBX9TPUJdYVbhaMZ9hlVGW8zQzNPZkln8bL6svWzd2RP5LjnfL0O tY61rjtXLXdz7uh6p/W1G6ANMRu6N2pszN84vslj09HNhM2Jm3/IM8krzXu9JWxLV75y/qb8sa0e W5sLJAr4BcPbbLfVbEdt527v32G+Y/+OT4XswmtFJkXlRR+KWcXXvjL9quKrhZ2xO/tLLEsO7sLs 4u0a2u2w+2ipdGlO6dge3z3tZfSywrLXe6P2Xi1fVl6zj7BPuG+kwqeic7/m/l37P1TGV96pcq5q rVaq3lE9d4B9YPCg48GWGuWaopr3h7iH7tZ61LbXadeVH8Yczjj8tD60vvdrxteNDQoNRQ0fj/CO jBwNPNrTaNXY2KTUVNIMNwubp45FHrv5jes3nS2GLbWttNai4+C48Pizb6O/HTrhfaL7JONky3da 31W3UdoK26H27PaZjviOkc7wzoFTK051d9l2tX1v9P2R02qnq87Inik5Szibf3bhXM652fOp56cv xF0Y647qfnBx1cXbPQE9/Ze8L1257H75Yq9T77krdldOX7W5euoa41rHdcvr7X0WfW0/WPzQ1m/Z 337D6kbnTeubXQPLB84OOgxeuOV66/Jtr9vX76y8MzAUMnR3OHJ45C777uS9pHsv72fcn3+w6SH6 YeEjqUflj5Ue1/2o92PriOXImVHX0b4nQU8ejLHGnv+U/tOH8fyn5KflE6oTjZNmk6en3KduPlv9 bPx56vP56YKfpX+ufqH74rtfHH/pm1k1M/6S/3Lh1+JX8q+OvF72unvWf/bxm+Q383OFb+XfHn3H eNf7Puz9xHzmB+yHio96H7s+eX96uJC8sPCbAAMA94Tz+woNCmVuZHN0cmVhbQ1lbmRvYmoNODE1 IDAgb2JqDTw8L0xlbmd0aCAzMzk1L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDYyODg+PnN0 cmVhbQ0KSIncVmtsVMcVPmfmPrx+xHixsWsIzHJjQ/D6zRsKNt414MgEPwg2z117197Fa6+zu1hA KDKBBlg7Vaq4SKGkMSlEQCC6xiSBlFYpLcRSWlKkpAJBaCs5AqVxlKi4VInAPfd6a5E0qMqfROr9 dmbOOfPNmXNm7sxdQABIgE7gUPB4TX5R4aXBKIDqIOsTjR0R8Vr+sWOkHwSQ5ze1N7f+/vYCHSDx CoC0sTmwtelX3VmkwzkATPR53Z6r+M4tgJS5ZJvtI4N1fPxPSG8n/RFfa2TL8iXRfaT3APC9gWCj 285yLtLYASoXW91b2vkTygyAtEnEF23uVu/h66nnifsclVPtIW/74+9M20j9C0mvBUZxA++UByh6 FbSSZPV9lN7HX1JwIyCP8LP4EUD+vaFxQ7D4U6oLC4pTbClZthRbJ4e7nQzugTzwxdxOyZgeeuBL eUQRkApZbyajlJRsleEMa3hDBUm1SniW1UBS/lD6PDCq/MICTFeAq4qaPW1adva02cVF6elWkK9r f757O1qxzpZkn7SwuSSwpnLDlGPMqoiiQ3cb7n1YVDIlv6W0+5kJocvl+DDLpHlPQo+8Qp5Ju5D6 a+CsGyyg4JcU+BD9CgvGz4TiIkhLBW0qnMS1w8O47t7h4eF7R9jgMK69d8QQcS2tV/Z3jobvHc/8 n8F4EmE/IIw+RQAxmUMGaaOyRHJFTFZIbojJKp2HbcQEyUKaB76IyQgCN8RkBg/hjphMZx67Y7JE 8rmYrJD8SUxWEdikY6KooGC2qPQ3hoLhYFNElAVD7cGQO+IPtuWJ0kBAVPubfZGwqPaGvaEOryfP uXRJxYrSnNX+tmYPlXButbd5c8Ad+rb2MYPwh4XXH/F5Q8ItQt5mfzjiDXk9IhJye7yt7lCLCBo9 96lN3xyv8LcJciNWtfkjNL4m4o54w8Ld5sknB0Fzgsbg5rZIyO8N5wk4BoLWvYAwm6RK8EMjhCAI YSpNECFbGUkhaDdrN1n8JLVBHvWUQoAgoJpszeCjvrCpean1EruDag8xnbAUltCOrqARObCa2G3E 98TasDmiGTaTLzeN+l/s3O+Y/98MQZJRe6mNUN5GroK4glpjpNEbMa1G/oJkY+U8pLWaHlvIFhwb 8829Td9qN4QZm4hFI2AVaX4zBmP+GpLcphY252wja34sguB9GTSStpl6jYj8JtvYZTqh6mR8DmSI ky5Jl+ioTvhPCx4uEqnjQU9ljRBQ8pn4bETJwcNQqBai3vlA9vf+XH5gTyGhEevYTraGpJ/TjVQI B6h4qLxAX9Ye1j/KgWIqOkkVcJO+20W0koa9GLZT7YB/4VG6BQ3LQmig/gZiX6B2EfU1Uoumjx66 tYz2R7CbfH/O+tl5dt7sXUx+KwzGKFi/PEB2w98ueA1u4NvEeQqep76zcNkYRZ576At8B6cTuvAj HGIryYrG/OSnhdg9FO9v4Cr8A1NxEUbxHHGsbKcZy+hsncS5QLhsejFQiQEMYgj3kc9Bxtks8hpk e1kv09l5Xi8tkgcUqzJHDZAXumDprk2hDCvMU1djftmeHPM6ij8hwyqsRR/ux16K4QIOEW6zXLaY Vt3Az7hLSpRuyS3yy4QBZZX6YpxCvmW6zzPpPc2CmZSVk+aoopg9sIm+FQaeImyntXwaXoJeOEQ3 Xh+8Bb815oRrcAPu0OokE4y85uA8XE2oJ4RwB+6m9ei6D8/iQezHtyi+d/EDNoWyHkWAsh+Nchc7 wE6zd9kf2F/YIPuYfc6BW/hG3sDD/Ag/zt/j70nLpF7pkHRdui6jrJsrZVVSlfVKF6Fbtagt6m71 p+qL6hvxeZBOedkprwq6hxphK2WyHfZC1Ny1PsJpeJ0wAB8beRBGYpkYmIcOLMdVhHpcgy5sxTBu GcvoML6CR/E05fIB4Qpew7/h3/FTE3eYwiawnLH8VrIatpq1sP3sBXaQvUpvZD87x66wG5TjIBum HBO4lafxydzJywm1fC3fwnfxk/w8v8aHaN8SpR9Ki6RV0nrK/aI0KN2inWQyl7PkWfJ8gk9uk3fI XfIv6I0ekoeURHNVrMp4ZYGyR3lJ6VeuKnfVNHWCOpWQpxaqNWpA7VCPq4PqzbgTllKL3xKKt8Nx +pK9+bXT+zq93b9j65V8yMRr9DY8yZOJZdx3F1iiGrD4Wb8RnVqD02mnPoQ73AKPSRdhNV8LAbmB J6ifwFEMSzvxVV4OJ+CI2oHnuIsP8SNylrJgdD3ZAX5c3aq61JsU6W3+vOxT87BU7sKjbDGd6BBW wT9xGDbQzBE2Ay7CPtiLHRAHPXEnMInO2gU2Bbvkl/kpqZc75R34KO3gRHmA/xhmQRr9a5oOU+ld l+n/O124JXPmzplZXFRYkJ+Xa8+Z8ej0adlZj2hTbWLK5IcnTcz8QUb6hLTU8daUcckPJSUmxFvi VEWWOEOwO7Vyl9CzXbqUrS1blmvompsM7vsMLp3+aujlX+XowmXSxFeZJcRs+hqzZJRZMsbEcWIh LMy1C6cm9D86NHEG11TVkfysQ6sX+pApV5qylG0qSaTYbD