Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1230124 > unrolled thread

[PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault

Started byMel Gorman <mgorman@techsingularity.net>
First post2015-09-22 14:40 +0200
Last post2015-09-24 06:30 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private pages  to satisfy a fault Mel Gorman <mgorman@techsingularity.net> - 2015-09-22 14:40 +0200
    Re: [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private  pages to satisfy a fault Mel Gorman <mgorman@techsingularity.net> - 2015-09-22 17:50 +0200
      Re: [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private  pages to satisfy a fault Michal Hocko <mhocko@kernel.org> - 2015-09-22 18:10 +0200
      Re: [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private  pages to satisfy a fault Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2015-09-24 06:30 +0200

#1230124 — [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault

FromMel Gorman <mgorman@techsingularity.net>
Date2015-09-22 14:40 +0200
Subject[PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault
Message-ID<qbv1v-5qC-7@gated-at.bofh.it>
SunDong reported the following on https://bugzilla.kernel.org/show_bug.cgi?id=103841

	I think I find a linux bug, I have the test cases is constructed. I
	can stable recurring problems in fedora22(4.0.4) kernel version,
	arch for x86_64.  I construct transparent huge page, when the parent
	and child process with MAP_SHARE, MAP_PRIVATE way to access the same
	huge page area, it has the opportunity to lead to huge page copy on
	write failure, and then it will munmap the child corresponding mmap
	area, but then the child mmap area with VM_MAYSHARE attributes, child
	process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
	functions (vma - > vm_flags & VM_MAYSHARE).

There were a number of problems with the report (e.g. it's hugetlbfs that
triggers this, not transparent huge pages) but it was fundamentally correct
in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that looks
like this

	 vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
	 next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
	 prot 8000000000000027 anon_vma           (null) vm_ops ffffffff8182a7a0
	 pgoff 0 file ffff88106bdb9800 private_data           (null)
	 flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
	 ------------
	 kernel BUG at mm/hugetlb.c:462!
	 SMP
	 Modules linked in: xt_pkttype xt_LOG xt_limit iscsi_ibft iscsi_boot_sysfs af_packet ip6t_REJECT nf_reject_ipv6
xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT iptable_filter ip6table_mangle
nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter
ip6_tables x_tables intel_powerclamp coretemp kvm_intel kvm mgag200 ttm drm_kms_helper drm crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel aesni_intel aes_x86_64 lrw ipmi_devintf gf128mul iTCO_wdt gpio_ich iTCO_vendor_support glue_helper ablk_helper
dcdbas i7core_edac cryptd syscopyarea sysfillrect bnx2 sysimgblt lpc_ich serio_raw edac_core i2c_algo_bit shpchp mfd_core ipmi_si
tpm_tis tpm ipmi_msghandler wmi acpi_power_meter button acpi_cpufreq processor dm_mod sr_mod cdrom ata_generic hid_generic usbhid hid
uhci_hcd ehci_pci ehci_hcd usbcore ata_piix usb_common megaraid_sas sg
	 CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
	 Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
	 task: ffff88085ed10490 ti: ffff88085ed14000 task.ti: ffff88085ed14000
	 set_vma_resv_flags+0x2d/0x30

The VM_BUG_ON is correct because private and shared mappings have different
reservation accounting but the warning clearly shows that the VMA is shared.

When a private COW fails to allocate a new page then only the process that
created the VMA gets the page -- all the children unmap the page. If the
children access that data in the future then they get killed.

The problem is that the same file is mapped shared and private. During
the COW, the allocation fails, the VMAs are traversed to unmap the other
private pages but a shared VMA is found and the bug is triggered. This
patch identifies such VMAs and skips them.

Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Reported-by: SunDong <sund_sky@126.com>
Cc: stable@vger.kernel.org
---
 mm/hugetlb.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index caad3c5a926f..6a8d86b0cb50 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2787,6 +2787,14 @@ static void unmap_ref_private(struct mm_struct *mm, struct vm_area_struct *vma,
 			continue;
 
 		/*
+		 * Shared VMAs have their own reserves and do not affect
+		 * MAP_PRIVATE accounting but it is possible that a shared
+		 * VMA is using the same page so check and skip such VMAs.
+		 */
+		if (iter_vma->vm_flags & VM_SHARED)
+			continue;
+
+		/*
 		 * Unmap the page from other VMAs without their own reserves.
 		 * They get marked to be SIGKILLed if they fault in these
 		 * areas. This is because a future no-page fault on this VMA

-- 
Mel Gorman
SUSE Labs
--
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/

[toc] | [next] | [standalone]

#1230369 — Re: [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault

FromMel Gorman <mgorman@techsingularity.net>
Date2015-09-22 17:50 +0200
SubjectRe: [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault
Message-ID<qbxZq-1c3-59@gated-at.bofh.it>
In reply to#1230124
On Tue, Sep 22, 2015 at 01:31:51PM +0100, Mel Gorman wrote:
> SunDong reported the following on https://bugzilla.kernel.org/show_bug.cgi?id=103841
> 

Michal Hocko correctly pointed out privately that this should have
checked VM_MAYSHARE for the reasons outlined in commit f83a275dbc5c ("mm:
account for MAP_SHARED mappings using VM_MAYSHARE and not VM_SHARED in
hugetlbfs"). Please take this version instead if it passes testing

---8<---
mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault

SunDong reported the following on https://bugzilla.kernel.org/show_bug.cgi?id=103841

	I think I find a linux bug, I have the test cases is constructed. I
	can stable recurring problems in fedora22(4.0.4) kernel version,
	arch for x86_64.  I construct transparent huge page, when the parent
	and child process with MAP_SHARE, MAP_PRIVATE way to access the same
	huge page area, it has the opportunity to lead to huge page copy on
	write failure, and then it will munmap the child corresponding mmap
	area, but then the child mmap area with VM_MAYSHARE attributes, child
	process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
	functions (vma - > vm_flags & VM_MAYSHARE).

There were a number of problems with the report (e.g. it's hugetlbfs that
triggers this, not transparent huge pages) but it was fundamentally correct
in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that looks
like this

	 vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
	 next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
	 prot 8000000000000027 anon_vma           (null) vm_ops ffffffff8182a7a0
	 pgoff 0 file ffff88106bdb9800 private_data           (null)
	 flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
	 ------------
	 kernel BUG at mm/hugetlb.c:462!
	 SMP
	 Modules linked in: xt_pkttype xt_LOG xt_limit iscsi_ibft iscsi_boot_sysfs af_packet ip6t_REJECT nf_reject_ipv6
xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT iptable_filter ip6table_mangle
nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter
ip6_tables x_tables intel_powerclamp coretemp kvm_intel kvm mgag200 ttm drm_kms_helper drm crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel aesni_intel aes_x86_64 lrw ipmi_devintf gf128mul iTCO_wdt gpio_ich iTCO_vendor_support glue_helper ablk_helper
dcdbas i7core_edac cryptd syscopyarea sysfillrect bnx2 sysimgblt lpc_ich serio_raw edac_core i2c_algo_bit shpchp mfd_core ipmi_si
tpm_tis tpm ipmi_msghandler wmi acpi_power_meter button acpi_cpufreq processor dm_mod sr_mod cdrom ata_generic hid_generic usbhid hid
uhci_hcd ehci_pci ehci_hcd usbcore ata_piix usb_common megaraid_sas sg
	 CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
	 Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
	 task: ffff88085ed10490 ti: ffff88085ed14000 task.ti: ffff88085ed14000
	 set_vma_resv_flags+0x2d/0x30

The VM_BUG_ON is correct because private and shared mappings have different
reservation accounting but the warning clearly shows that the VMA is shared.

When a private COW fails to allocate a new page then only the process that
created the VMA gets the page -- all the children unmap the page. If the
children access that data in the future then they get killed.

The problem is that the same file is mapped shared and private. During
the COW, the allocation fails, the VMAs are traversed to unmap the other
private pages but a shared VMA is found and the bug is triggered. This
patch identifies such VMAs and skips them.

Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Reported-by: SunDong <sund_sky@126.com>

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 999fb0aef8f1..9cc773483624 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3202,6 +3202,14 @@ static void unmap_ref_private(struct mm_struct *mm, struct vm_area_struct *vma,
 			continue;
 
 		/*
+		 * Shared VMAs have their own reserves and do not affect
+		 * MAP_PRIVATE accounting but it is possible that a shared
+		 * VMA is using the same page so check and skip such VMAs.
+		 */
+		if (iter_vma->vm_flags & VM_MAYSHARE)
+			continue;
+
+		/*
 		 * Unmap the page from other VMAs without their own reserves.
 		 * They get marked to be SIGKILLed if they fault in these
 		 * areas. This is because a future no-page fault on this VMA
--
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/

[toc] | [prev] | [next] | [standalone]

#1230404 — Re: [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault

FromMichal Hocko <mhocko@kernel.org>
Date2015-09-22 18:10 +0200
SubjectRe: [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault
Message-ID<qbyiJ-1PH-7@gated-at.bofh.it>
In reply to#1230369
On Tue 22-09-15 16:49:38, Mel Gorman wrote:
[...]
> mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault
> 
> SunDong reported the following on https://bugzilla.kernel.org/show_bug.cgi?id=103841
> 
> 	I think I find a linux bug, I have the test cases is constructed. I
> 	can stable recurring problems in fedora22(4.0.4) kernel version,
> 	arch for x86_64.  I construct transparent huge page, when the parent
> 	and child process with MAP_SHARE, MAP_PRIVATE way to access the same
> 	huge page area, it has the opportunity to lead to huge page copy on
> 	write failure, and then it will munmap the child corresponding mmap
> 	area, but then the child mmap area with VM_MAYSHARE attributes, child
> 	process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
> 	functions (vma - > vm_flags & VM_MAYSHARE).
> 
> There were a number of problems with the report (e.g. it's hugetlbfs that
> triggers this, not transparent huge pages) but it was fundamentally correct
> in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that looks
> like this
> 
> 	 vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
> 	 next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
> 	 prot 8000000000000027 anon_vma           (null) vm_ops ffffffff8182a7a0
> 	 pgoff 0 file ffff88106bdb9800 private_data           (null)
> 	 flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
> 	 ------------
> 	 kernel BUG at mm/hugetlb.c:462!
> 	 SMP
> 	 Modules linked in: xt_pkttype xt_LOG xt_limit iscsi_ibft iscsi_boot_sysfs af_packet ip6t_REJECT nf_reject_ipv6
> xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT iptable_filter ip6table_mangle
> nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter
> ip6_tables x_tables intel_powerclamp coretemp kvm_intel kvm mgag200 ttm drm_kms_helper drm crct10dif_pclmul crc32_pclmul crc32c_intel
> ghash_clmulni_intel aesni_intel aes_x86_64 lrw ipmi_devintf gf128mul iTCO_wdt gpio_ich iTCO_vendor_support glue_helper ablk_helper
> dcdbas i7core_edac cryptd syscopyarea sysfillrect bnx2 sysimgblt lpc_ich serio_raw edac_core i2c_algo_bit shpchp mfd_core ipmi_si
> tpm_tis tpm ipmi_msghandler wmi acpi_power_meter button acpi_cpufreq processor dm_mod sr_mod cdrom ata_generic hid_generic usbhid hid
> uhci_hcd ehci_pci ehci_hcd usbcore ata_piix usb_common megaraid_sas sg
> 	 CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
> 	 Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
> 	 task: ffff88085ed10490 ti: ffff88085ed14000 task.ti: ffff88085ed14000
> 	 set_vma_resv_flags+0x2d/0x30
> 
> The VM_BUG_ON is correct because private and shared mappings have different
> reservation accounting but the warning clearly shows that the VMA is shared.
> 
> When a private COW fails to allocate a new page then only the process that
> created the VMA gets the page -- all the children unmap the page. If the
> children access that data in the future then they get killed.
> 
> The problem is that the same file is mapped shared and private. During
> the COW, the allocation fails, the VMAs are traversed to unmap the other
> private pages but a shared VMA is found and the bug is triggered. This
> patch identifies such VMAs and skips them.
> 
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
> Reported-by: SunDong <sund_sky@126.com>

Reviewed-by: Michal Hocko <mhocko@suse.com>

I guess you wanted to add Cc: stable back. I believe this goes very long
way back.
 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 999fb0aef8f1..9cc773483624 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3202,6 +3202,14 @@ static void unmap_ref_private(struct mm_struct *mm, struct vm_area_struct *vma,
>  			continue;
>  
>  		/*
> +		 * Shared VMAs have their own reserves and do not affect
> +		 * MAP_PRIVATE accounting but it is possible that a shared
> +		 * VMA is using the same page so check and skip such VMAs.
> +		 */
> +		if (iter_vma->vm_flags & VM_MAYSHARE)
> +			continue;
> +
> +		/*
>  		 * Unmap the page from other VMAs without their own reserves.
>  		 * They get marked to be SIGKILLed if they fault in these
>  		 * areas. This is because a future no-page fault on this VMA

-- 
Michal Hocko
SUSE Labs
--
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/

[toc] | [prev] | [next] | [standalone]

#1231849 — Re: [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault

FromNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date2015-09-24 06:30 +0200
SubjectRe: [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault
Message-ID<qc6kq-DF-9@gated-at.bofh.it>
In reply to#1230369
T24gVHVlLCBTZXAgMjIsIDIwMTUgYXQgMDQ6NDk6MzhQTSArMDEwMCwgTWVsIEdvcm1hbiB3cm90
ZToNCj4gT24gVHVlLCBTZXAgMjIsIDIwMTUgYXQgMDE6MzE6NTFQTSArMDEwMCwgTWVsIEdvcm1h
biB3cm90ZToNCj4gPiBTdW5Eb25nIHJlcG9ydGVkIHRoZSBmb2xsb3dpbmcgb24gaHR0cHM6Ly9i
dWd6aWxsYS5rZXJuZWwub3JnL3Nob3dfYnVnLmNnaT9pZD0xMDM4NDENCj4gPiANCj4gDQo+IE1p
Y2hhbCBIb2NrbyBjb3JyZWN0bHkgcG9pbnRlZCBvdXQgcHJpdmF0ZWx5IHRoYXQgdGhpcyBzaG91
bGQgaGF2ZQ0KPiBjaGVja2VkIFZNX01BWVNIQVJFIGZvciB0aGUgcmVhc29ucyBvdXRsaW5lZCBp
biBjb21taXQgZjgzYTI3NWRiYzVjICgibW06DQo+IGFjY291bnQgZm9yIE1BUF9TSEFSRUQgbWFw
cGluZ3MgdXNpbmcgVk1fTUFZU0hBUkUgYW5kIG5vdCBWTV9TSEFSRUQgaW4NCj4gaHVnZXRsYmZz
IikuIFBsZWFzZSB0YWtlIHRoaXMgdmVyc2lvbiBpbnN0ZWFkIGlmIGl0IHBhc3NlcyB0ZXN0aW5n
DQo+IA0KPiAtLS04PC0tLQ0KPiBtbTogaHVnZXRsYmZzOiBTa2lwIHNoYXJlZCBWTUFzIHdoZW4g
dW5tYXBwaW5nIHByaXZhdGUgcGFnZXMgdG8gc2F0aXNmeSBhIGZhdWx0DQo+IA0KPiBTdW5Eb25n
IHJlcG9ydGVkIHRoZSBmb2xsb3dpbmcgb24gaHR0cHM6Ly9idWd6aWxsYS5rZXJuZWwub3JnL3No
b3dfYnVnLmNnaT9pZD0xMDM4NDENCj4gDQo+IAlJIHRoaW5rIEkgZmluZCBhIGxpbnV4IGJ1Zywg
SSBoYXZlIHRoZSB0ZXN0IGNhc2VzIGlzIGNvbnN0cnVjdGVkLiBJDQo+IAljYW4gc3RhYmxlIHJl
Y3VycmluZyBwcm9ibGVtcyBpbiBmZWRvcmEyMig0LjAuNCkga2VybmVsIHZlcnNpb24sDQo+IAlh
cmNoIGZvciB4ODZfNjQuICBJIGNvbnN0cnVjdCB0cmFuc3BhcmVudCBodWdlIHBhZ2UsIHdoZW4g
dGhlIHBhcmVudA0KPiAJYW5kIGNoaWxkIHByb2Nlc3Mgd2l0aCBNQVBfU0hBUkUsIE1BUF9QUklW
QVRFIHdheSB0byBhY2Nlc3MgdGhlIHNhbWUNCj4gCWh1Z2UgcGFnZSBhcmVhLCBpdCBoYXMgdGhl
IG9wcG9ydHVuaXR5IHRvIGxlYWQgdG8gaHVnZSBwYWdlIGNvcHkgb24NCj4gCXdyaXRlIGZhaWx1
cmUsIGFuZCB0aGVuIGl0IHdpbGwgbXVubWFwIHRoZSBjaGlsZCBjb3JyZXNwb25kaW5nIG1tYXAN
Cj4gCWFyZWEsIGJ1dCB0aGVuIHRoZSBjaGlsZCBtbWFwIGFyZWEgd2l0aCBWTV9NQVlTSEFSRSBh
dHRyaWJ1dGVzLCBjaGlsZA0KPiAJcHJvY2VzcyBtdW5tYXAgdGhpcyBhcmVhIGNhbiB0cmlnZ2Vy
IFZNX0JVR19PTiBpbiBzZXRfdm1hX3Jlc3ZfZmxhZ3MNCj4gCWZ1bmN0aW9ucyAodm1hIC0gPiB2
bV9mbGFncyAmIFZNX01BWVNIQVJFKS4NCj4gDQo+IFRoZXJlIHdlcmUgYSBudW1iZXIgb2YgcHJv
YmxlbXMgd2l0aCB0aGUgcmVwb3J0IChlLmcuIGl0J3MgaHVnZXRsYmZzIHRoYXQNCj4gdHJpZ2dl
cnMgdGhpcywgbm90IHRyYW5zcGFyZW50IGh1Z2UgcGFnZXMpIGJ1dCBpdCB3YXMgZnVuZGFtZW50
YWxseSBjb3JyZWN0DQo+IGluIHRoYXQgYSBWTV9CVUdfT04gaW4gc2V0X3ZtYV9yZXN2X2ZsYWdz
KCkgY2FuIGJlIHRyaWdnZXJlZCB0aGF0IGxvb2tzDQo+IGxpa2UgdGhpcw0KPiANCj4gCSB2bWEg
ZmZmZjg4MDQ2NTFmZDBkMCBzdGFydCAwMDAwN2ZjNDc0ZTAwMDAwIGVuZCAwMDAwN2ZjNDc1ZTAw
MDAwDQo+IAkgbmV4dCBmZmZmODgwNDY1MWZkMDE4IHByZXYgZmZmZjg4MDQ2NTFmZDE4OCBtbSBm
ZmZmODgwNDZiMWIxODAwDQo+IAkgcHJvdCA4MDAwMDAwMDAwMDAwMDI3IGFub25fdm1hICAgICAg
ICAgICAobnVsbCkgdm1fb3BzIGZmZmZmZmZmODE4MmE3YTANCj4gCSBwZ29mZiAwIGZpbGUgZmZm
Zjg4MTA2YmRiOTgwMCBwcml2YXRlX2RhdGEgICAgICAgICAgIChudWxsKQ0KPiAJIGZsYWdzOiAw
eDg0NDAwZmIocmVhZHx3cml0ZXxzaGFyZWR8bWF5cmVhZHxtYXl3cml0ZXxtYXlleGVjfG1heXNo
YXJlfGRvbnRleHBhbmR8aHVnZXRsYikNCj4gCSAtLS0tLS0tLS0tLS0NCj4gCSBrZXJuZWwgQlVH
IGF0IG1tL2h1Z2V0bGIuYzo0NjIhDQo+IAkgU01QDQo+IAkgTW9kdWxlcyBsaW5rZWQgaW46IHh0
X3BrdHR5cGUgeHRfTE9HIHh0X2xpbWl0IGlzY3NpX2liZnQgaXNjc2lfYm9vdF9zeXNmcyBhZl9w
YWNrZXQgaXA2dF9SRUpFQ1QgbmZfcmVqZWN0X2lwdjYNCj4geHRfdGNwdWRwIG5mX2Nvbm50cmFj
a19pcHY2IG5mX2RlZnJhZ19pcHY2IGlwNnRhYmxlX3JhdyBpcHRfUkVKRUNUIG5mX3JlamVjdF9p
cHY0IGlwdGFibGVfcmF3IHh0X0NUIGlwdGFibGVfZmlsdGVyIGlwNnRhYmxlX21hbmdsZQ0KPiBu
Zl9jb25udHJhY2tfbmV0Ymlvc19ucyBuZl9jb25udHJhY2tfYnJvYWRjYXN0IG5mX2Nvbm50cmFj
a19pcHY0IG5mX2RlZnJhZ19pcHY0IGlwX3RhYmxlcyB4dF9jb25udHJhY2sgbmZfY29ubnRyYWNr
IGlwNnRhYmxlX2ZpbHRlcg0KPiBpcDZfdGFibGVzIHhfdGFibGVzIGludGVsX3Bvd2VyY2xhbXAg
Y29yZXRlbXAga3ZtX2ludGVsIGt2bSBtZ2FnMjAwIHR0bSBkcm1fa21zX2hlbHBlciBkcm0gY3Jj
dDEwZGlmX3BjbG11bCBjcmMzMl9wY2xtdWwgY3JjMzJjX2ludGVsDQo+IGdoYXNoX2NsbXVsbmlf
aW50ZWwgYWVzbmlfaW50ZWwgYWVzX3g4Nl82NCBscncgaXBtaV9kZXZpbnRmIGdmMTI4bXVsIGlU
Q09fd2R0IGdwaW9faWNoIGlUQ09fdmVuZG9yX3N1cHBvcnQgZ2x1ZV9oZWxwZXIgYWJsa19oZWxw
ZXINCj4gZGNkYmFzIGk3Y29yZV9lZGFjIGNyeXB0ZCBzeXNjb3B5YXJlYSBzeXNmaWxscmVjdCBi
bngyIHN5c2ltZ2JsdCBscGNfaWNoIHNlcmlvX3JhdyBlZGFjX2NvcmUgaTJjX2FsZ29fYml0IHNo
cGNocCBtZmRfY29yZSBpcG1pX3NpDQo+IHRwbV90aXMgdHBtIGlwbWlfbXNnaGFuZGxlciB3bWkg
YWNwaV9wb3dlcl9tZXRlciBidXR0b24gYWNwaV9jcHVmcmVxIHByb2Nlc3NvciBkbV9tb2Qgc3Jf
bW9kIGNkcm9tIGF0YV9nZW5lcmljIGhpZF9nZW5lcmljIHVzYmhpZCBoaWQNCj4gdWhjaV9oY2Qg
ZWhjaV9wY2kgZWhjaV9oY2QgdXNiY29yZSBhdGFfcGlpeCB1c2JfY29tbW9uIG1lZ2FyYWlkX3Nh
cyBzZw0KPiAJIENQVTogMzggUElEOiAyNjgzOSBDb21tOiBtYXAgTm90IHRhaW50ZWQgNC4wLjQt
ZGVmYXVsdCAjMQ0KPiAJIEhhcmR3YXJlIG5hbWU6IERlbGwgSW5jLiBQb3dlckVkZ2UgUjgxMC8w
VFQ2SkYsIEJJT1MgMi43LjQgMDQvMjYvMjAxMg0KPiAJIHRhc2s6IGZmZmY4ODA4NWVkMTA0OTAg
dGk6IGZmZmY4ODA4NWVkMTQwMDAgdGFzay50aTogZmZmZjg4MDg1ZWQxNDAwMA0KPiAJIHNldF92
bWFfcmVzdl9mbGFncysweDJkLzB4MzANCj4gDQo+IFRoZSBWTV9CVUdfT04gaXMgY29ycmVjdCBi
ZWNhdXNlIHByaXZhdGUgYW5kIHNoYXJlZCBtYXBwaW5ncyBoYXZlIGRpZmZlcmVudA0KPiByZXNl
cnZhdGlvbiBhY2NvdW50aW5nIGJ1dCB0aGUgd2FybmluZyBjbGVhcmx5IHNob3dzIHRoYXQgdGhl
IFZNQSBpcyBzaGFyZWQuDQo+IA0KPiBXaGVuIGEgcHJpdmF0ZSBDT1cgZmFpbHMgdG8gYWxsb2Nh
dGUgYSBuZXcgcGFnZSB0aGVuIG9ubHkgdGhlIHByb2Nlc3MgdGhhdA0KPiBjcmVhdGVkIHRoZSBW
TUEgZ2V0cyB0aGUgcGFnZSAtLSBhbGwgdGhlIGNoaWxkcmVuIHVubWFwIHRoZSBwYWdlLiBJZiB0
aGUNCj4gY2hpbGRyZW4gYWNjZXNzIHRoYXQgZGF0YSBpbiB0aGUgZnV0dXJlIHRoZW4gdGhleSBn
ZXQga2lsbGVkLg0KPiANCj4gVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgc2FtZSBmaWxlIGlzIG1h
cHBlZCBzaGFyZWQgYW5kIHByaXZhdGUuIER1cmluZw0KPiB0aGUgQ09XLCB0aGUgYWxsb2NhdGlv
biBmYWlscywgdGhlIFZNQXMgYXJlIHRyYXZlcnNlZCB0byB1bm1hcCB0aGUgb3RoZXINCj4gcHJp
dmF0ZSBwYWdlcyBidXQgYSBzaGFyZWQgVk1BIGlzIGZvdW5kIGFuZCB0aGUgYnVnIGlzIHRyaWdn
ZXJlZC4gVGhpcw0KPiBwYXRjaCBpZGVudGlmaWVzIHN1Y2ggVk1BcyBhbmQgc2tpcHMgdGhlbS4N
Cj4gDQo+IFNpZ25lZC1vZmYtYnk6IE1lbCBHb3JtYW4gPG1nb3JtYW5AdGVjaHNpbmd1bGFyaXR5
Lm5ldD4NCj4gUmVwb3J0ZWQtYnk6IFN1bkRvbmcgPHN1bmRfc2t5QDEyNi5jb20+DQoNCkxvb2tz
IGdvb2QgdG8gbWUuDQoNClJldmlld2VkLWJ5OiBOYW95YSBIb3JpZ3VjaGkgPG4taG9yaWd1Y2hp
QGFoLmpwLm5lYy5jb20+DQoNCj4gDQo+IGRpZmYgLS1naXQgYS9tbS9odWdldGxiLmMgYi9tbS9o
dWdldGxiLmMNCj4gaW5kZXggOTk5ZmIwYWVmOGYxLi45Y2M3NzM0ODM2MjQgMTAwNjQ0DQo+IC0t
LSBhL21tL2h1Z2V0bGIuYw0KPiArKysgYi9tbS9odWdldGxiLmMNCj4gQEAgLTMyMDIsNiArMzIw
MiwxNCBAQCBzdGF0aWMgdm9pZCB1bm1hcF9yZWZfcHJpdmF0ZShzdHJ1Y3QgbW1fc3RydWN0ICpt
bSwgc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEsDQo+ICAJCQljb250aW51ZTsNCj4gIA0KPiAg
CQkvKg0KPiArCQkgKiBTaGFyZWQgVk1BcyBoYXZlIHRoZWlyIG93biByZXNlcnZlcyBhbmQgZG8g
bm90IGFmZmVjdA0KPiArCQkgKiBNQVBfUFJJVkFURSBhY2NvdW50aW5nIGJ1dCBpdCBpcyBwb3Nz
aWJsZSB0aGF0IGEgc2hhcmVkDQo+ICsJCSAqIFZNQSBpcyB1c2luZyB0aGUgc2FtZSBwYWdlIHNv
IGNoZWNrIGFuZCBza2lwIHN1Y2ggVk1Bcy4NCj4gKwkJICovDQo+ICsJCWlmIChpdGVyX3ZtYS0+
dm1fZmxhZ3MgJiBWTV9NQVlTSEFSRSkNCj4gKwkJCWNvbnRpbnVlOw0KPiArDQo+ICsJCS8qDQo+
ICAJCSAqIFVubWFwIHRoZSBwYWdlIGZyb20gb3RoZXIgVk1BcyB3aXRob3V0IHRoZWlyIG93biBy
ZXNlcnZlcy4NCj4gIAkJICogVGhleSBnZXQgbWFya2VkIHRvIGJlIFNJR0tJTExlZCBpZiB0aGV5
IGZhdWx0IGluIHRoZXNlDQo+ICAJCSAqIGFyZWFzLiBUaGlzIGlzIGJlY2F1c2UgYSBmdXR1cmUg
bm8tcGFnZSBmYXVsdCBvbiB0aGlzIFZNQQ==
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web