<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:41:22 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>Whamcloud Community JIRA</title>
    <link>https://jira.whamcloud.com</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.4.14</version>
        <build-number>940014</build-number>
        <build-date>05-12-2023</build-date>
    </build-info>


<item>
            <title>[LU-4287] Kernel update [RHEL6.5 2.6.32-431.3.1.el6]</title>
                <link>https://jira.whamcloud.com/browse/LU-4287</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;This update fixes the following security issues:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;A flaw was found in the way the Linux kernel&apos;s IPv6 implementation&lt;br/&gt;
handled certain UDP packets when the UDP Fragmentation Offload (UFO)&lt;br/&gt;
feature was enabled. A remote attacker could use this flaw to crash the&lt;br/&gt;
system or, potentially, escalate their privileges on the system.&lt;br/&gt;
(CVE-2013-4387, Important)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;A flaw was found in the way the Linux kernel handled the creation of&lt;br/&gt;
temporary IPv6 addresses. If the IPv6 privacy extension was enabled&lt;br/&gt;
(/proc/sys/net/ipv6/conf/eth0/use_tempaddr set to &apos;2&apos;), an attacker on the&lt;br/&gt;
local network could disable IPv6 temporary address generation, leading to a&lt;br/&gt;
potential information disclosure. (CVE-2013-0343, Moderate)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;A flaw was found in the way the Linux kernel handled HID (Human Interface&lt;br/&gt;
Device) reports with an out-of-bounds Report ID. An attacker with physical&lt;br/&gt;
access to the system could use this flaw to crash the system or,&lt;br/&gt;
potentially, escalate their privileges on the system. (CVE-2013-2888,&lt;br/&gt;
Moderate)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;An off-by-one flaw was found in the way the ANSI CPRNG implementation in&lt;br/&gt;
the Linux kernel processed non-block size aligned requests. This could lead&lt;br/&gt;
to random numbers being generated with less bits of entropy than expected&lt;br/&gt;
when ANSI CPRNG was used. (CVE-2013-4345, Moderate)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;It was found that the fix for CVE-2012-2375 released via RHSA-2012:1580&lt;br/&gt;
accidentally removed a check for small-sized result buffers. A local,&lt;br/&gt;
unprivileged user with access to an NFSv4 mount with ACL support could use&lt;br/&gt;
this flaw to crash the system or, potentially, escalate their privileges on&lt;br/&gt;
the system . (CVE-2013-4591, Moderate)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;A flaw was found in the way IOMMU memory mappings were handled when&lt;br/&gt;
moving memory slots. A malicious user on a KVM host who has the ability to&lt;br/&gt;
assign a device to a guest could use this flaw to crash the host.&lt;br/&gt;
(CVE-2013-4592, Moderate)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;Heap-based buffer overflow flaws were found in the way the Zeroplus and&lt;br/&gt;
Pantherlord/GreenAsia game controllers handled HID reports. An attacker&lt;br/&gt;
with physical access to the system could use these flaws to crash the&lt;br/&gt;
system or, potentially, escalate their privileges on the system.&lt;br/&gt;
(CVE-2013-2889, CVE-2013-2892, Moderate)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;Two information leak flaws were found in the logical link control (LLC)&lt;br/&gt;
implementation in the Linux kernel. A local, unprivileged user could use&lt;br/&gt;
these flaws to leak kernel stack memory to user space. (CVE-2012-6542,&lt;br/&gt;
CVE-2013-3231, Low)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;A heap-based buffer overflow in the way the tg3 Ethernet driver parsed&lt;br/&gt;
the vital product data (VPD) of devices could allow an attacker with&lt;br/&gt;
physical access to a system to cause a denial of service or, potentially,&lt;br/&gt;
escalate their privileges. (CVE-2013-1929, Low)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;Information leak flaws in the Linux kernel could allow a privileged,&lt;br/&gt;
local user to leak kernel memory to user space. (CVE-2012-6545,&lt;br/&gt;
CVE-2013-1928, CVE-2013-2164, CVE-2013-2234, Low)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;A format string flaw was found in the Linux kernel&apos;s block layer.&lt;br/&gt;
A privileged, local user could potentially use this flaw to escalate their&lt;br/&gt;
privileges to kernel level (ring0). (CVE-2013-2851, Low)&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Red Hat would like to thank Stephan Mueller for reporting CVE-2013-4345,&lt;br/&gt;
and Kees Cook for reporting CVE-2013-2851.&lt;/p&gt;

&lt;p&gt;This update also fixes several hundred bugs and adds enhancements. Refer to&lt;br/&gt;
the Red Hat Enterprise Linux 6.5 Release Notes for information on the most&lt;br/&gt;
significant of these changes, and the Technical Notes for further&lt;br/&gt;
information, both linked to in the References.&lt;/p&gt;

&lt;p&gt;All Red Hat Enterprise Linux 6 users are advised to install these updated&lt;br/&gt;
packages, which correct these issues, and fix the bugs and add the&lt;br/&gt;
enhancements noted in the Red Hat Enterprise Linux 6.5 Release Notes and&lt;br/&gt;
Technical Notes. The system must be rebooted for this update to take&lt;br/&gt;
effect.&lt;/p&gt;

&lt;p&gt;Bugs fixed (&lt;a href=&quot;https://bugzilla.redhat.com/):&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://bugzilla.redhat.com/):&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;627128 - kernel spec: devel_post macro: hardlink fc typo&lt;br/&gt;
734728 - cifs: asynchronous readpages support&lt;br/&gt;
796364 - sbc_fitpc2_wdt NULL pointer dereference&lt;br/&gt;
815908 - NFSv4 server support for numeric IDs&lt;br/&gt;
831158 - dm-crypt: Fix possible mempool deadlock&lt;br/&gt;
834919 - JBD: Spotted dirty metadata buffer&lt;br/&gt;
851269 - kernel-debug:  enable CONFIG_JBD_DEBUG&lt;br/&gt;
856764 - RHEL 6.5 Common Network Backports Tracker&lt;br/&gt;
859562 - DM RAID: &apos;sync&apos; table argument is ineffective.&lt;br/&gt;
873659 - virt: Clocksource tsc unstable (delta = 474712882 ns).  Enable clocksource failover by adding clocksource_failover kernel parameter.&lt;br/&gt;
876528 - Set-group-ID (SGID) bit not inherited on XFS file system with ACLs on directory&lt;br/&gt;
889973 - &quot;kernel: device-mapper: table: 253:3: snapshot-origin: unknown target type&quot;&lt;br/&gt;
903297 - FCoE target: backport drivers/target from upstream&lt;br/&gt;
908093 - gfs2: withdraw does not wait for gfs_controld&lt;br/&gt;
913660 - nfs client crashes during open&lt;br/&gt;
914664 - CVE-2013-0343 kernel: handling of IPv6 temporary addresses&lt;br/&gt;
918239 - kernel-2.6.32-358.0.1 doesn&apos;t boot at virtual machine on Xen Cloud Platform&lt;br/&gt;
920752 - cannot open device nodes for writing on RO filesystems&lt;br/&gt;
922322 - CVE-2012-6542 Kernel: llc: information leak via getsockname&lt;br/&gt;
922404 - CVE-2012-6545 Kernel: Bluetooth: RFCOMM - information leak&lt;br/&gt;
928207 - transfer data using two port from guest to host,guest hang and call trace&lt;br/&gt;
949567 - CVE-2013-1928 Kernel: information leak in fs/compat_ioctl.c VIDEO_SET_SPU_PALETTE&lt;br/&gt;
949932 - CVE-2013-1929 Kernel: tg3: buffer overflow in VPD firmware parsing&lt;br/&gt;
953097 - virtio-rng, boot the guest with two rng device, cat /dev/hwrng in guest, guest will call trace&lt;br/&gt;
956094 - CVE-2013-3231 Kernel: llc: Fix missing msg_namelen update in llc_ui_recvmsg&lt;br/&gt;
969515 - CVE-2013-2851 kernel: block: passing disk names as format strings&lt;br/&gt;
973100 - CVE-2013-2164 Kernel: information leak in cdrom driver&lt;br/&gt;
980995 - CVE-2013-2234 Kernel: net: information leak in AF_KEY notify&lt;br/&gt;
990806 - BUG: soft lockup - CPU#0 stuck for 63s! &lt;span class=&quot;error&quot;&gt;&amp;#91;killall5:7385&amp;#93;&lt;/span&gt;&lt;br/&gt;
999890 - CVE-2013-2889 Kernel: HID: zeroplus: heap overflow flaw&lt;br/&gt;
1000429 - CVE-2013-2892 Kernel: HID: pantherlord: heap overflow flaw&lt;br/&gt;
1000451 - CVE-2013-2888 Kernel: HID: memory corruption flaw&lt;br/&gt;
1007690 - CVE-2013-4345 kernel: ansi_cprng: off by one error in non-block size request&lt;br/&gt;
1011927 - CVE-2013-4387 Kernel: net: IPv6: panic when UFO=On for an interface&lt;br/&gt;
1014867 - xfssyncd and flush device threads hang in xlog_grant_head_wait&lt;br/&gt;
1031678 - CVE-2013-4591 kernel: nfs: missing check for buffer length in __nfs4_get_acl_uncached&lt;br/&gt;
1031702 - CVE-2013-4592 kernel: kvm: memory leak when memory slot is moved with assigned device&lt;/p&gt;</description>
                <environment></environment>
        <key id="22196">LU-4287</key>
            <summary>Kernel update [RHEL6.5 2.6.32-431.3.1.el6]</summary>
                <type id="4" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11310&amp;avatarType=issuetype">Improvement</type>
                                            <priority id="4" iconUrl="https://jira.whamcloud.com/images/icons/priorities/minor.svg">Minor</priority>
                        <status id="5" iconUrl="https://jira.whamcloud.com/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="1">Fixed</resolution>
                                        <assignee username="ys">Yang Sheng</assignee>
                                    <reporter username="ys">Yang Sheng</reporter>
                        <labels>
                    </labels>
                <created>Thu, 21 Nov 2013 15:59:40 +0000</created>
                <updated>Fri, 14 Feb 2014 17:35:33 +0000</updated>
                            <resolved>Mon, 10 Feb 2014 15:45:38 +0000</resolved>
                                                    <fixVersion>Lustre 2.6.0</fixVersion>
                    <fixVersion>Lustre 2.5.1</fixVersion>
                                        <due></due>
                            <votes>1</votes>
                                    <watches>21</watches>
                                                                            <comments>
                            <comment id="72398" author="nscfreny" created="Wed, 27 Nov 2013 15:49:34 +0000"  >&lt;p&gt;Definition of getname() and putname() in /usr/src/kernels/2.6.32-431.el6.x86_64/include/linux/fs.h has changed.&lt;/p&gt;

&lt;p&gt;I was able to build 1.8 client by introducing local getname() and putname() in lustre/llite/dir.c same way as was done here:&lt;br/&gt;
Change If44cd9f9: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-2800&quot; title=&quot;build: clean out old autoconf options&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-2800&quot;&gt;&lt;del&gt;LU-2800&lt;/del&gt;&lt;/a&gt; llite: introduce local getname()&lt;br/&gt;
&lt;a href=&quot;http://review.whamcloud.com/#/c/5781/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/5781/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I suspect this will also be needed for 2.1.&lt;/p&gt;

&lt;p&gt;Regards / Fredrik&lt;/p&gt;</comment>
                            <comment id="72818" author="bogl" created="Wed, 4 Dec 2013 16:12:15 +0000"  >&lt;p&gt;seeing build failures in 6.5. even a simple client build now fails.  example:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;  CC [M]  /home/bogl/lustre-release/libcfs/libcfs/linux/linux-tracefile.o
In file included from /home/bogl/lustre-release/libcfs/include/libcfs/libcfs.h:304,
                 from /home/bogl/lustre-release/libcfs/libcfs/linux/linux-tracefile.c:40:
/home/bogl/lustre-release/libcfs/include/libcfs/params_tree.h:99: error: conflicting types for &#8216;PDE&#8217;
/usr/src/kernels/2.6.32-431.el6.x86_64/include/linux/proc_fs.h:323: note: previous definition of &#8216;PDE&#8217; was here
make[6]: *** [/home/bogl/lustre-release/libcfs/libcfs/linux/linux-tracefile.o] Error 1
make[5]: *** [/home/bogl/lustre-release/libcfs/libcfs] Error 2
make[4]: *** [/home/bogl/lustre-release/libcfs] Error 2
make[3]: *** [_module_/home/bogl/lustre-release] Error 2
make[3]: Leaving directory `/usr/src/kernels/2.6.32-431.el6.x86_64&apos;
make[2]: *** [modules] Error 2
make[2]: Leaving directory `/home/bogl/lustre-release&apos;
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bogl/lustre-release&apos;
make: *** [all] Error 2
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;I suspect this is due to recent patch for &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3319&quot; title=&quot;Adapt to 3.10 upstream kernel proc_dir_entry change&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3319&quot;&gt;&lt;del&gt;LU-3319&lt;/del&gt;&lt;/a&gt; landed to master.  autoconf is I think misidentifying the 2.6.32 kernel in Centos/RHEL 6.5 as&lt;/p&gt;

&lt;p&gt;#define HAVE_ONLY_PROCFS_SEQ 1&lt;/p&gt;

&lt;p&gt;I believe this lead to build problems.&lt;/p&gt;

&lt;p&gt;Did some client only builds against RHEL 6.5 kernel before the recent patch and didn&apos;t have this problem.&lt;/p&gt;</comment>
                            <comment id="72830" author="simmonsja" created="Wed, 4 Dec 2013 18:04:29 +0000"  >&lt;p&gt;Try this patch - &lt;a href=&quot;http://review.whamcloud.com/#/c/8482&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/8482&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="72831" author="bogl" created="Wed, 4 Dec 2013 18:14:14 +0000"  >&lt;p&gt;tried it in Centos 6.5.  works for me.&lt;/p&gt;</comment>
                            <comment id="72964" author="knweiss" created="Fri, 6 Dec 2013 09:30:01 +0000"  >&lt;p&gt;To which Lustre version does this issue apply?&lt;/p&gt;

&lt;p&gt;I was able to build Lustre client 2.5.0 on RHEL 6.5&apos;s kernel 2.6.32-431.el6 but we ran into &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3889&quot; title=&quot; LBUG: (osc_lock.c:497:osc_lock_upcall()) ASSERTION( lock-&amp;gt;cll_state &amp;gt;= CLS_QUEUING ) &quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3889&quot;&gt;&lt;del&gt;LU-3889&lt;/del&gt;&lt;/a&gt; during our initial tests (with Lustre 2.1.6 servers). I also tried to build Lustre client 2.4.0/2.4.1 packages for 2.6.32-431.el6 but the compilation fails in &lt;tt&gt;ll_dir_ioctl()&lt;/tt&gt; because of the &lt;tt&gt;putname()&lt;/tt&gt; API changes.&lt;/p&gt;

&lt;p&gt;Is there a patch to build Lustre client 2.4.x on 2.6.32-431.el6?&lt;/p&gt;

&lt;p&gt;I also don&apos;t see this issue on the issue list for Lustre 2.4.2.&lt;/p&gt;</comment>
                            <comment id="72969" author="simmonsja" created="Fri, 6 Dec 2013 12:59:14 +0000"  >&lt;p&gt;The build issue only exist for master (2.6 branch) for the RHEL6.5 build.&lt;/p&gt;</comment>
                            <comment id="72972" author="nscfreny" created="Fri, 6 Dec 2013 13:54:32 +0000"  >&lt;blockquote&gt;
&lt;p&gt;Is there a patch to build Lustre client 2.4.x on 2.6.32-431.el6?&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;I was able to build Lustre client 2.4.x on 2.6.32-431.el6 after applying following patch.&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;diff --git a/lustre/llite/dir.c b/lustre/llite/dir.c
index febf6ea..484d177 100644
--- a/lustre/llite/dir.c
+++ b/lustre/llite/dir.c
@@ -1228,6 +1228,30 @@ out:
         RETURN(rc);
 }
 
+static char *
+ll_getname(const char __user *filename)
+{
+	int ret = 0, len;
+	char *tmp = __getname();
+
+	if (!tmp)
+		return ERR_PTR(-ENOMEM);
+
+	len = strncpy_from_user(tmp, filename, PATH_MAX);
+	if (len == 0)
+		ret = -ENOENT;
+	else if (len &amp;gt; PATH_MAX)
+		ret = -ENAMETOOLONG;
+
+	if (ret) {
+		__putname(tmp);
+		tmp =  ERR_PTR(ret);
+	}
+	return tmp;
+}
+
+#define ll_putname(filename) __putname(filename)
+
 static long ll_dir_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 {
         struct inode *inode = file-&amp;gt;f_dentry-&amp;gt;d_inode;
@@ -1430,7 +1454,7 @@ free_lmv:
 		if (!(exp_connect_flags(sbi-&amp;gt;ll_md_exp) &amp;amp; OBD_CONNECT_LVB_TYPE))
 			return -ENOTSUPP;
 
-		filename = getname((const char *)arg);
+		filename = ll_getname((const char *)arg);
 		if (IS_ERR(filename))
 			RETURN(PTR_ERR(filename));
 
@@ -1441,7 +1465,7 @@ free_lmv:
 		rc = ll_rmdir_entry(inode, filename, namelen);
 out_rmdir:
                 if (filename)
-                        putname(filename);
+                        ll_putname(filename);
 		RETURN(rc);
 	}
 	case LL_IOC_LOV_SWAP_LAYOUTS:
@@ -1461,7 +1485,7 @@ out_rmdir:
 
                 if (cmd == IOC_MDC_GETFILEINFO ||
                     cmd == IOC_MDC_GETFILESTRIPE) {
-                        filename = getname((const char *)arg);
+                        filename = ll_getname((const char *)arg);
                         if (IS_ERR(filename))
                                 RETURN(PTR_ERR(filename));
 
@@ -1528,7 +1552,7 @@ out_rmdir:
         out_req:
                 ptlrpc_req_finished(request);
                 if (filename)
-                        putname(filename);
+                        ll_putname(filename);
                 return rc;
         }
         case IOC_LOV_GETINFO: {
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Similar issues with all releases &amp;lt; 2.5&lt;/p&gt;</comment>
                            <comment id="72973" author="bogl" created="Fri, 6 Dec 2013 14:06:55 +0000"  >&lt;p&gt;I think that&apos;s &lt;a href=&quot;http://review.whamcloud.com/5781&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/5781&lt;/a&gt;, in master and b2_5. It is planned to be added to b2_4 before we support Centos/RHEL 6.5 there.&lt;/p&gt;</comment>
                            <comment id="72980" author="knweiss" created="Fri, 6 Dec 2013 15:05:11 +0000"  >&lt;p&gt;Thanks Fredrik, with your patch it finally compiles. (I already tried a similar patch yesterday but probably made a mistake...)&lt;/p&gt;</comment>
                            <comment id="73311" author="ys" created="Wed, 11 Dec 2013 21:45:05 +0000"  >&lt;p&gt;Patch commit to: &lt;a href=&quot;http://review.whamcloud.com/#/c/8549/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/8549/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="73366" author="bogl" created="Thu, 12 Dec 2013 14:59:10 +0000"  >&lt;p&gt;Adding discussion about &lt;a href=&quot;http://review.whamcloud.com/#/c/8549&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/8549&lt;/a&gt; here as I don&apos;t want to fill up the review in gerrit with what may become irrelevant comment.&lt;/p&gt;

&lt;p&gt;I notice you have carefully forked the ldiskfs portions of the mod so we can still build on earlier el6 as well as 6.5.  However the same wasn&apos;t done for the base kernel.  For example the lustre/kernel_patches/patches/raid5-mmp-unplug-dev-rhel6.patch was altered in such a way as it will now only apply onto 6.5 instead of making a new version of this patch for 6.5.   No extensions to lbuild to select between 6.4 and 6.5 were done.  If this strategy is OK and we are agreed to abandon patching and building earlier kernels then this is probably right.  If it&apos;s not OK, then it isn&apos;t right.&lt;/p&gt;

&lt;p&gt;BTW, do the revisions for ldiskfs support here imply that some similar changes will be needed in &lt;a href=&quot;http://review.whamcloud.com/7263&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/7263&lt;/a&gt; ?&lt;/p&gt;

&lt;p&gt;Just as an aside however did you find the issue needing change in the sanity.sh test?  Have been into the release notes for 6.5 and didn&apos;t notice anything about it.&lt;/p&gt;</comment>
                            <comment id="73377" author="ys" created="Thu, 12 Dec 2013 15:52:04 +0000"  >&lt;p&gt;As i know, We just keep earlier version for ldiskfs patches, not base kernel patches. &lt;/p&gt;


&lt;p&gt;Yes, 3.11 will also work in this way. I&apos;ll update it.&lt;/p&gt;

&lt;p&gt;For sanity test_17g failure, Looks like RedHat bring a patch not come from upstream. I think it exist a obvious issue in function do_getname(). So we need skip it for now.&lt;/p&gt;</comment>
                            <comment id="73403" author="morrone" created="Thu, 12 Dec 2013 20:03:30 +0000"  >&lt;blockquote&gt;&lt;p&gt;I notice you have carefully forked the ldiskfs portions of the mod so we can still build on earlier el6 as well as 6.5. However the same wasn&apos;t done for the base kernel.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;I can explain at least the history there. The core lustre folks have historically never cared about making the transition from one kernel to the next easy.  Lustre would just randomly one day stop working with your kernel and only work with some newer version, with no consideration given towards the need for a transition period where it can still compile against both kernels.&lt;/p&gt;

&lt;p&gt;In the past year I worked (with others like James) to get ldiskfs set up to support multiple versions of kernels supported at the same time.  At LLNL we have the lustre tree apply the ldiskfs patches, but we maintain our own kernel independent of Lustre, so we don&apos;t let Lustre apply the kernel patches.  Therefore I was not particularly motivated to look at improving the patching of the kernel.  Since I was driving the ldiskfs changes, they only happened to ldiskfs.&lt;/p&gt;

&lt;p&gt;Further, since we hope to eliminate the necessity for patching one&apos;s kernel soon, it was seen as less important to make that process cleaner.  ldiskfs patches, on the other hand, will exist for quite a long time.&lt;/p&gt;</comment>
                            <comment id="73444" author="ys" created="Fri, 13 Dec 2013 05:03:57 +0000"  >&lt;ul&gt;
	&lt;li&gt;A flaw was found in the way the Linux kernel&apos;s TCP/IP protocol suite&lt;br/&gt;
implementation handled sending of certain UDP packets over sockets that&lt;br/&gt;
used the UDP_CORK option when the UDP Fragmentation Offload (UFO) feature&lt;br/&gt;
was enabled on the output device. A local, unprivileged user could use this&lt;br/&gt;
flaw to cause a denial of service or, potentially, escalate their&lt;br/&gt;
privileges on the system. (CVE-2013-4470, Important)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;A divide-by-zero flaw was found in the apic_get_tmcct() function in KVM&apos;s&lt;br/&gt;
Local Advanced Programmable Interrupt Controller (LAPIC) implementation.&lt;br/&gt;
A privileged guest user could use this flaw to crash the host.&lt;br/&gt;
(CVE-2013-6367, Important)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;A memory corruption flaw was discovered in the way KVM handled virtual&lt;br/&gt;
APIC accesses that crossed a page boundary. A local, unprivileged user&lt;br/&gt;
could use this flaw to crash the system or, potentially, escalate their&lt;br/&gt;
privileges on the system. (CVE-2013-6368, Important)&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;An information leak flaw in the Linux kernel could allow a local,&lt;br/&gt;
unprivileged user to leak kernel memory to user space. (CVE-2013-2141, Low)&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Bugs fixed (&lt;a href=&quot;https://bugzilla.redhat.com/):&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://bugzilla.redhat.com/):&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;970873 - CVE-2013-2141 Kernel: signal: information leak in tkill/tgkill&lt;br/&gt;
1023477 - CVE-2013-4470 Kernel: net: memory corruption with UDP_CORK and UFO&lt;br/&gt;
1032207 - CVE-2013-6367 kvm: division by zero in apic_get_tmcct()&lt;br/&gt;
1032210 - CVE-2013-6368 kvm: cross page vapic_addr access&lt;/p&gt;</comment>
                            <comment id="73862" author="bogl" created="Thu, 19 Dec 2013 17:10:19 +0000"  >&lt;p&gt;the following are needed for client builds on 6.5:&lt;/p&gt;

&lt;p&gt;in b2_4: &lt;a href=&quot;http://review.whamcloud.com/8581&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/8581&lt;/a&gt;&lt;br/&gt;
in b1_8: &lt;a href=&quot;http://review.whamcloud.com/8607&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/8607&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="74254" author="morrone" created="Thu, 2 Jan 2014 18:44:57 +0000"  >&lt;p&gt;Yang Sheng,&lt;/p&gt;

&lt;p&gt;In patch &lt;a href=&quot;http://review.whamcloud.com/8549&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/8549&lt;/a&gt; it is still not clear to me why you think it best to copy the ext4_ext_walk_space() function into osd_io.c.  That function originates from ext4, so it would see to me that ldiskfs would be the more appropriate place to reinsert that function.&lt;/p&gt;

&lt;p&gt;If you add it to ldiskfs for just the RHEL6.5 kernel, you do not need to change all of the other kernels&apos; patch sets.  Also, I suspect that longer term the maintenance will be less difficult, because we won&apos;t need to worry about having a function in Lustre that needs to be fully compatible with multiple kernels&apos; ext4 implementations.  The function can be tweaked as needed for only the kernels that lack that function natively.&lt;/p&gt;
</comment>
                            <comment id="74294" author="ys" created="Fri, 3 Jan 2014 06:37:27 +0000"  >&lt;p&gt;Hi, Christopher,&lt;/p&gt;

&lt;p&gt;I think it should be move to osd since we can use one interface for io map.  Don&apos;t need consider different cases in different distro.  It will reduce the maintenance effort and ldiskfs patches number.  Also we can modify walk_space as needed. Anyway, I don&apos;t think this is a main issue for the patch. I would like we can make decision which interface will be used. map_blocks or walk_space. I am trying to do some test to reveal the performance different.  Hope it can give some judge base.&lt;/p&gt;</comment>
                            <comment id="74407" author="bogl" created="Mon, 6 Jan 2014 17:00:12 +0000"  >&lt;p&gt;The kernel version in 6.5 has been updated to 2.6.32-431.3.1 over the weekend.  Since we haven&apos;t landed 6.5 support yet I suggest we just change our target to the new version, not submit a separate bug.&lt;/p&gt;</comment>
                            <comment id="75093" author="mrfusion" created="Thu, 16 Jan 2014 16:43:17 +0000"  >&lt;p&gt;Bob,&lt;/p&gt;

&lt;p&gt;I can confirm that the patch offered via the URL &lt;a href=&quot;http://review.whamcloud.com/#/c/8607/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/8607/&lt;/a&gt; has functioned without an issue on RHEL 6.x with the new kernel.  Thank you for posting that link.&lt;/p&gt;

&lt;p&gt;John DeSantis&lt;/p&gt;</comment>
                            <comment id="75750" author="ys" created="Tue, 28 Jan 2014 12:06:31 +0000"  >&lt;p&gt;I can sure that Oleg mentioned racer issue just relate to rhel6.5 self.  But still not very clear why it happen. What i can provide is that mnt_count isn&apos;t release so umount cannot success forever. Other thing is &apos;ln&apos; is culprit. Further investigation needed.&lt;/p&gt;

&lt;p&gt;Btw: WangDi, Your patch looks like fixes the &apos;mdc_read_page&apos; error.&lt;/p&gt;</comment>
                            <comment id="75970" author="green" created="Fri, 31 Jan 2014 02:31:34 +0000"  >&lt;p&gt;Okm I traced the issue back to rhel 6.5 patch adding estale-retry logic. in linkat() they leak nameidata in case of ESTALE return which lustre does during racer.&lt;/p&gt;

&lt;p&gt;Patch that fixes the issue for me is:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;--- fs/namei.c-orig	2014-01-30 19:53:32.885946633 -0500
+++ fs/namei.c	2014-01-30 21:10:31.880946625 -0500
@@ -2897,6 +2897,7 @@ out_release:
 	path_put(&amp;amp;nd.path);
 	putname(to);
 	if (retry_estale(error, how)) {
+		path_put(&amp;amp;old_path);
 		how |= LOOKUP_REVAL;
 		goto retry;
 	}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                            <comment id="75973" author="green" created="Fri, 31 Jan 2014 03:11:40 +0000"  >&lt;p&gt;RH ticket filed for this: &lt;a href=&quot;https://bugzilla.redhat.com/show_bug.cgi?id=1059943&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://bugzilla.redhat.com/show_bug.cgi?id=1059943&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="75988" author="bogl" created="Fri, 31 Jan 2014 15:20:01 +0000"  >&lt;p&gt;Seems like we&apos;re stuck until the upstream fix happens.  Even if we added a kernel patch for 6.5, it would only apply in server builds.  We would still hit the problem in clients that we build and run on unpatched, pristine kernels.  Is there some obvious workaround I&apos;m missing?&lt;/p&gt;</comment>
                            <comment id="75989" author="ys" created="Fri, 31 Jan 2014 15:36:47 +0000"  >&lt;p&gt;Why i cannot access RH ticket? Is it need some permit?&lt;/p&gt;</comment>
                            <comment id="76065" author="green" created="Mon, 3 Feb 2014 08:17:47 +0000"  >&lt;p&gt;the RH ticket is restricted to some intel group for some reason I am not sure of.&lt;/p&gt;

&lt;p&gt;Anyway, the bug is also present in upstream kernels, so I also sent a fix there and it was already accepted.&lt;/p&gt;

&lt;p&gt;See here if you are interested in all the details: &lt;a href=&quot;http://comments.gmane.org/gmane.linux.kernel/1638580&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://comments.gmane.org/gmane.linux.kernel/1638580&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="76601" author="pjones" created="Mon, 10 Feb 2014 15:45:38 +0000"  >&lt;p&gt;Landed for 2.6&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                                        </outwardlinks>
                                                                <inwardlinks description="is related to">
                                                        </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                            <customfield id="customfield_10890" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10390" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hzw9vr:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>11766</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>