[PATCH 3.18 28/33] xfs: handle array index overrun in xfs_dir2_leaf_readbuf()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Sandeen commit 023cc840b40fad95c6fe26fff1d380a8c9d45939 upstream. Carlos had a case where "find" seemed to start spinning forever and never return. This was on a

[PATCH 3.18 30/33] xfs: fix up quotacheck buffer list error handling

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Brian Foster commit 20e8a063786050083fe05b4f45be338c60b49126 upstream. The quotacheck error handling of the delwri buffer list assumes the resident buffers are locked and

[PATCH 4.4 03/53] ipv6/dccp: do not inherit ipv6_mc_list from parent

4.4-stable review patch. If anyone has any objections, please let me know. -- From: WANG Cong [ Upstream commit 83eaddab4378db256d00d295bda6ca997cd13a52 ] Like commit 657831ffc38e ("dccp/tcp: do not inherit mc_list from parent") we should clear

[PATCH 3.18 25/33] xfs: Fix missed holes in SEEK_HOLE implementation

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Jan Kara commit 5375023ae1266553a7baa0845e82917d8803f48c upstream. XFS SEEK_HOLE implementation could miss a hole in an unwritten extent as can be seen by the following command:

[PATCH 3.18 26/33] xfs: fix off-by-one on max nr_pages in xfs_find_get_desired_pgoff()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eryu Guan commit 8affebe16d79ebefb1d9d6d56a46dc89716f9453 upstream. xfs_find_get_desired_pgoff() is used to search for offset of hole or data in page range [index, end]

[PATCH 4.4 00/53] 4.4.71-stable review

This is the start of the stable review cycle for the 4.4.71 release. There are 53 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Jun 7 15:30:23 UTC 2017. Anything

[PATCH 3.18 30/33] xfs: fix up quotacheck buffer list error handling

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Brian Foster commit 20e8a063786050083fe05b4f45be338c60b49126 upstream. The quotacheck error handling of the delwri buffer list assumes the resident buffers are locked and doesn't clear the

[PATCH 4.4 03/53] ipv6/dccp: do not inherit ipv6_mc_list from parent

4.4-stable review patch. If anyone has any objections, please let me know. -- From: WANG Cong [ Upstream commit 83eaddab4378db256d00d295bda6ca997cd13a52 ] Like commit 657831ffc38e ("dccp/tcp: do not inherit mc_list from parent") we should clear ipv6_mc_list etc. for IPv6

[PATCH 3.18 25/33] xfs: Fix missed holes in SEEK_HOLE implementation

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Jan Kara commit 5375023ae1266553a7baa0845e82917d8803f48c upstream. XFS SEEK_HOLE implementation could miss a hole in an unwritten extent as can be seen by the following command: xfs_io -c

[PATCH 3.18 26/33] xfs: fix off-by-one on max nr_pages in xfs_find_get_desired_pgoff()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eryu Guan commit 8affebe16d79ebefb1d9d6d56a46dc89716f9453 upstream. xfs_find_get_desired_pgoff() is used to search for offset of hole or data in page range [index, end] (both inclusive), and

[PATCH 4.4 00/53] 4.4.71-stable review

This is the start of the stable review cycle for the 4.4.71 release. There are 53 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Jun 7 15:30:23 UTC 2017. Anything

[PATCH 3.18 28/33] xfs: handle array index overrun in xfs_dir2_leaf_readbuf()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Sandeen commit 023cc840b40fad95c6fe26fff1d380a8c9d45939 upstream. Carlos had a case where "find" seemed to start spinning forever and never return. This was on a filesystem with

[PATCH 3.18 22/33] drm/gma500/psb: Actually use VBT mode when it is found

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Patrik Jakobsson commit 82bc9a42cf854fdf63155759c0aa790bd1f361b0 upstream. With LVDS we were incorrectly picking the pre-programmed mode instead of the prefered

[PATCH 3.18 22/33] drm/gma500/psb: Actually use VBT mode when it is found

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Patrik Jakobsson commit 82bc9a42cf854fdf63155759c0aa790bd1f361b0 upstream. With LVDS we were incorrectly picking the pre-programmed mode instead of the prefered mode provided by VBT. Make

[PATCH 3.18 24/33] mlock: fix mlock count can not decrease in race condition

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Yisheng Xie commit 70feee0e1ef331b22cc51f383d532a0d043fbdcc upstream. Kefeng reported that when running the follow test, the mlock count in meminfo will increase

[PATCH 3.18 24/33] mlock: fix mlock count can not decrease in race condition

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Yisheng Xie commit 70feee0e1ef331b22cc51f383d532a0d043fbdcc upstream. Kefeng reported that when running the follow test, the mlock count in meminfo will increase permanently: [1] testcase

[PATCH 3.18 15/33] tcp: avoid fastopen API to be used on AF_UNSPEC

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Wei Wang [ Upstream commit ba615f675281d76fd19aa03558777f81fb6b6084 ] Fastopen API should be used to perform fastopen operations on the TCP socket. It does not make sense

Re: [PATCH v4 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

Steven Rostedt writes: > On Wed, 24 May 2017 14:04:05 +0200 > Vitaly Kuznetsov wrote: > >> Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others(). >> Tracing is done the same way we do xen_mmu_flush_tlb_others(). >> >> Signed-off-by:

[PATCH 3.18 15/33] tcp: avoid fastopen API to be used on AF_UNSPEC

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Wei Wang [ Upstream commit ba615f675281d76fd19aa03558777f81fb6b6084 ] Fastopen API should be used to perform fastopen operations on the TCP socket. It does not make sense to use fastopen API

Re: [PATCH v4 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

Steven Rostedt writes: > On Wed, 24 May 2017 14:04:05 +0200 > Vitaly Kuznetsov wrote: > >> Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others(). >> Tracing is done the same way we do xen_mmu_flush_tlb_others(). >> >> Signed-off-by: Vitaly Kuznetsov >> Acked-by: K. Y.

[PATCH 3.18 09/33] sctp: do not inherit ipv6_{mc|ac|fl}_list from parent

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit fdcee2cbb8438702ea1b328fb6e0ac5e9a40c7f8 ] SCTP needs fixes similar to 83eaddab4378 ("ipv6/dccp: do not inherit ipv6_mc_list from

[PATCH 3.18 17/33] i2c: i2c-tiny-usb: fix buffer not being DMA capable

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Reichel commit 5165da5923d6c7df6f2927b0113b2e4d9288661e upstream. Since v4.9 i2c-tiny-usb generates the below call trace and longer works, since

[PATCH 3.18 23/33] mm/migrate: fix refcount handling when !hugepage_migration_supported()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Punit Agrawal commit 30809f559a0d348c2dfd7ab05e9a451e2384962e upstream. On failing to migrate a page, soft_offline_huge_page() performs the necessary update to the

[PATCH 3.18 09/33] sctp: do not inherit ipv6_{mc|ac|fl}_list from parent

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit fdcee2cbb8438702ea1b328fb6e0ac5e9a40c7f8 ] SCTP needs fixes similar to 83eaddab4378 ("ipv6/dccp: do not inherit ipv6_mc_list from parent"), otherwise bad

[PATCH 3.18 17/33] i2c: i2c-tiny-usb: fix buffer not being DMA capable

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Reichel commit 5165da5923d6c7df6f2927b0113b2e4d9288661e upstream. Since v4.9 i2c-tiny-usb generates the below call trace and longer works, since it can't communicate with the USB

[PATCH 3.18 23/33] mm/migrate: fix refcount handling when !hugepage_migration_supported()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Punit Agrawal commit 30809f559a0d348c2dfd7ab05e9a451e2384962e upstream. On failing to migrate a page, soft_offline_huge_page() performs the necessary update to the hugepage ref-count. But

[PATCH 3.18 16/33] sctp: fix ICMP processing if skb is non-linear

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Davide Caratti [ Upstream commit 804ec7ebe8ea003999ca8d1bfc499edc6a9e07df ] sometimes ICMP replies to INIT chunks are ignored by the client, even if the encapsulated

[PATCH 3.18 16/33] sctp: fix ICMP processing if skb is non-linear

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Davide Caratti [ Upstream commit 804ec7ebe8ea003999ca8d1bfc499edc6a9e07df ] sometimes ICMP replies to INIT chunks are ignored by the client, even if the encapsulated SCTP headers match an

[PATCH 3.18 20/33] ALSA: hda - apply STAC_9200_DELL_M22 quirk for Dell Latitude D430

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Alexander Tsoy commit 1fc2e41f7af4572b07190f9dec28396b418e9a36 upstream. This model is actually called 92XXM2-8 in Windows driver. But since pin configs for M22 and M28 are

[PATCH 3.18 20/33] ALSA: hda - apply STAC_9200_DELL_M22 quirk for Dell Latitude D430

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Alexander Tsoy commit 1fc2e41f7af4572b07190f9dec28396b418e9a36 upstream. This model is actually called 92XXM2-8 in Windows driver. But since pin configs for M22 and M28 are identical, just

[PATCH 3.18 10/33] tcp: eliminate negative reordering in tcp_clean_rtx_queue

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Soheil Hassas Yeganeh [ Upstream commit bafbb9c73241760023d8981191ddd30bb1c6dbac ] tcp_ack() can call tcp_fragment() which may dededuct the value tp->fackets_out when MSS

[PATCH 3.18 06/33] s390/qeth: avoid null pointer dereference on OSN

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Julian Wiedmann [ Upstream commit 25e2c341e7818a394da9abc403716278ee646014 ] Access card->dev only after checking whether's its valid. Signed-off-by: Julian

[PATCH 3.18 02/33] netem: fix skb_orphan_partial()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet commit f6ba8d33cfbb46df569972e64dbb5bb7e929bfd9 upstream. I should have known that lowering skb->truesize was dangerous :/ In case packets are not leaving

[PATCH 3.18 04/33] s390/qeth: handle sysfs error during initialization

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Ursula Braun [ Upstream commit 9111e7880ccf419548c7b0887df020b08eadb075 ] When setting up the device from within the layer discipline's probe routine, creating the

[PATCH 3.18 10/33] tcp: eliminate negative reordering in tcp_clean_rtx_queue

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Soheil Hassas Yeganeh [ Upstream commit bafbb9c73241760023d8981191ddd30bb1c6dbac ] tcp_ack() can call tcp_fragment() which may dededuct the value tp->fackets_out when MSS changes. When

[PATCH 3.18 06/33] s390/qeth: avoid null pointer dereference on OSN

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Julian Wiedmann [ Upstream commit 25e2c341e7818a394da9abc403716278ee646014 ] Access card->dev only after checking whether's its valid. Signed-off-by: Julian Wiedmann Reviewed-by: Ursula

[PATCH 3.18 02/33] netem: fix skb_orphan_partial()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet commit f6ba8d33cfbb46df569972e64dbb5bb7e929bfd9 upstream. I should have known that lowering skb->truesize was dangerous :/ In case packets are not leaving the host via a

[PATCH 3.18 04/33] s390/qeth: handle sysfs error during initialization

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Ursula Braun [ Upstream commit 9111e7880ccf419548c7b0887df020b08eadb075 ] When setting up the device from within the layer discipline's probe routine, creating the layer-specific sysfs

[PATCH 3.18 07/33] tcp: avoid fragmenting peculiar skbs in SACK

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Yuchung Cheng [ Upstream commit b451e5d24ba6687c6f0e7319c727a709a1846c06 ] This patch fixes a bug in splitting an SKB during SACK processing. Specifically if an skb

[PATCH 3.18 05/33] s390/qeth: unbreak OSM and OSN support

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Julian Wiedmann [ Upstream commit 2d2ebb3ed0c6acfb014f98e427298673a5d07b82 ] commit b4d72c08b358 ("qeth: bridgeport support - basic control") broke the support for

[PATCH 3.18 07/33] tcp: avoid fragmenting peculiar skbs in SACK

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Yuchung Cheng [ Upstream commit b451e5d24ba6687c6f0e7319c727a709a1846c06 ] This patch fixes a bug in splitting an SKB during SACK processing. Specifically if an skb contains multiple packets

[PATCH 3.18 05/33] s390/qeth: unbreak OSM and OSN support

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Julian Wiedmann [ Upstream commit 2d2ebb3ed0c6acfb014f98e427298673a5d07b82 ] commit b4d72c08b358 ("qeth: bridgeport support - basic control") broke the support for OSM and OSN devices as

[PATCH 3.18 00/33] 3.18.56-stable review

This is the start of the stable review cycle for the 3.18.56 release. There are 33 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Jun 7 15:30:04 UTC 2017. Anything

[PATCH 3.18 00/33] 3.18.56-stable review

This is the start of the stable review cycle for the 3.18.56 release. There are 33 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Jun 7 15:30:04 UTC 2017. Anything

Re: [Xen-devel] [PATCH] xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU

On 05/06/17 16:32, Boris Ostrovsky wrote: I believe we do need to take affinity into consideration even if the chance that it is non-default is small. Agreed. I am not opposed to having bind_last_selected_cpu percpu, I just wanted to understand the reason better. Additional locking would be

Re: [Xen-devel] [PATCH] xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU

On 05/06/17 16:32, Boris Ostrovsky wrote: I believe we do need to take affinity into consideration even if the chance that it is non-default is small. Agreed. I am not opposed to having bind_last_selected_cpu percpu, I just wanted to understand the reason better. Additional locking would be

Re: [PATCH 01/13] x86/efi: Clean up efi CR3 save/restore

On Mon, Jun 5, 2017 at 9:03 AM, Ard Biesheuvel wrote: > On 5 June 2017 at 15:40, Ingo Molnar wrote: >> >> * Ard Biesheuvel wrote: >> >>> From: Andy Lutomirski >>> >>> efi_call_phys_prolog() used to return

Re: [PATCH 01/13] x86/efi: Clean up efi CR3 save/restore

On Mon, Jun 5, 2017 at 9:03 AM, Ard Biesheuvel wrote: > On 5 June 2017 at 15:40, Ingo Molnar wrote: >> >> * Ard Biesheuvel wrote: >> >>> From: Andy Lutomirski >>> >>> efi_call_phys_prolog() used to return a "pgd_t *" that meant one of >>> three different things depending on kernel and system

[PATCH 0/2] amd: uncore: Fix for AMD Uncore driver

The following series provides fixes for the AMD Uncore driver. * Renamed cache counters cpufeatures macro to better reflect different last level cache for different families * Get correct information about number of cores sharing last level of cache Janakarajan Natarajan (2): amd: uncore:

[PATCH 2/2] amd: uncore: Get correct number of cores sharing last level cache

In Family 17h, the number of cores sharing a cache level is obtained from the Cache Properties CPUID leaf (0x801d) by passing in the cache level in ECX. In prior families, a cache level of 2 was used to determine this information. To get the right information, irrespective of Family, iterate

[PATCH 1/2] amd: uncore: Rename cpufeatures macro for cache counters

In Family 17h, L3 is the last level cache as opposed to L2 in previous families. Avoid this name confusion and rename X86_FEATURE_PERFCT_L2 to X86_FEATURE_PERFCTR_LLC to indicate the performance counter on the last level of cache. Signed-off-by: Janakarajan Natarajan

[PATCH 0/2] amd: uncore: Fix for AMD Uncore driver

The following series provides fixes for the AMD Uncore driver. * Renamed cache counters cpufeatures macro to better reflect different last level cache for different families * Get correct information about number of cores sharing last level of cache Janakarajan Natarajan (2): amd: uncore:

[PATCH 2/2] amd: uncore: Get correct number of cores sharing last level cache

In Family 17h, the number of cores sharing a cache level is obtained from the Cache Properties CPUID leaf (0x801d) by passing in the cache level in ECX. In prior families, a cache level of 2 was used to determine this information. To get the right information, irrespective of Family, iterate

[PATCH 1/2] amd: uncore: Rename cpufeatures macro for cache counters

In Family 17h, L3 is the last level cache as opposed to L2 in previous families. Avoid this name confusion and rename X86_FEATURE_PERFCT_L2 to X86_FEATURE_PERFCTR_LLC to indicate the performance counter on the last level of cache. Signed-off-by: Janakarajan Natarajan ---

Re: [PATCH 10/13] efi/capsule: Add support for Quark security header

* Ard Biesheuvel wrote: > >> +config EFI_CAPSULE_QUIRK_QUARK_CSH > >> + boolean "Add support for Quark capsules with non-standard headers" > >> + depends on X86 && !64BIT > >> + select EFI_CAPSULE_LOADER > >> + default y > >> + help > >> +

Re: [PATCH 10/13] efi/capsule: Add support for Quark security header

* Ard Biesheuvel wrote: > >> +config EFI_CAPSULE_QUIRK_QUARK_CSH > >> + boolean "Add support for Quark capsules with non-standard headers" > >> + depends on X86 && !64BIT > >> + select EFI_CAPSULE_LOADER > >> + default y > >> + help > >> + Add support for processing

Re: [PATCH v4 4/5] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension

On Mon, Jun 05, 2017 at 10:55:16AM -0500, Kim Phillips wrote: > On Mon, 5 Jun 2017 16:22:56 +0100 > Will Deacon wrote: > > > +/* Perf callbacks */ > > +static int arm_spe_pmu_event_init(struct perf_event *event) > > +{ > > + u64 reg; > > + struct perf_event_attr *attr =

Re: [PATCH v4 4/5] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension

On Mon, Jun 05, 2017 at 10:55:16AM -0500, Kim Phillips wrote: > On Mon, 5 Jun 2017 16:22:56 +0100 > Will Deacon wrote: > > > +/* Perf callbacks */ > > +static int arm_spe_pmu_event_init(struct perf_event *event) > > +{ > > + u64 reg; > > + struct perf_event_attr *attr = >attr; > > + struct

Re: [PATCH v2 4/5] ACPI / extlog: Switch to use new generic UUID API

> @@ -165,11 +165,11 @@ static int extlog_print(struct notifier_block *nb, > unsigned long val, > err_seq++; > gdata = (struct acpi_hest_generic_data *)(tmp + 1); > if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID) > - fru_id = (uuid_le *)gdata->fru_id; > +

Re: [PATCH v2 4/5] ACPI / extlog: Switch to use new generic UUID API

> @@ -165,11 +165,11 @@ static int extlog_print(struct notifier_block *nb, > unsigned long val, > err_seq++; > gdata = (struct acpi_hest_generic_data *)(tmp + 1); > if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID) > - fru_id = (uuid_le *)gdata->fru_id; > +

Re: [PATCH v2 3/5] ACPI / bus: Switch to use new generic UUID API

> + in_params[0].buffer.pointer = (u8 *) Any idea why the pointer is defined as a u8 * in union acpi_object instead of a void?

Re: [PATCH v2 3/5] ACPI / bus: Switch to use new generic UUID API

> + in_params[0].buffer.pointer = (u8 *) Any idea why the pointer is defined as a u8 * in union acpi_object instead of a void?

Re: [PATCH 01/13] x86/efi: Clean up efi CR3 save/restore

On 5 June 2017 at 15:40, Ingo Molnar wrote: > > * Ard Biesheuvel wrote: > >> From: Andy Lutomirski >> >> efi_call_phys_prolog() used to return a "pgd_t *" that meant one of >> three different things depending on kernel and system

Re: [PATCH 01/13] x86/efi: Clean up efi CR3 save/restore

On 5 June 2017 at 15:40, Ingo Molnar wrote: > > * Ard Biesheuvel wrote: > >> From: Andy Lutomirski >> >> efi_call_phys_prolog() used to return a "pgd_t *" that meant one of >> three different things depending on kernel and system configuration. >> Clean it up so it uses a union and is more

Re: [PATCH v2 2/5] ACPI / APEI: Switch to use new generic UUID API

> - if (!uuid_le_cmp(*(uuid_le *)gdata->section_type, > - CPER_SEC_PLATFORM_MEM)) { > + if (!guid_equal(sec_type, _SEC_PLATFORM_MEM)) { The "!" here seems incorrect. > #ifdef CONFIG_ACPI_APEI_PCIEAER > - else if

Re: [PATCH v2 2/5] ACPI / APEI: Switch to use new generic UUID API

> - if (!uuid_le_cmp(*(uuid_le *)gdata->section_type, > - CPER_SEC_PLATFORM_MEM)) { > + if (!guid_equal(sec_type, _SEC_PLATFORM_MEM)) { The "!" here seems incorrect. > #ifdef CONFIG_ACPI_APEI_PCIEAER > - else if

Re: [PATCH v2 1/5] acpi, nfit: Switch to use new generic UUID API

> for (i = 0; i < NFIT_UUID_MAX; i++) > - if (memcmp(to_nfit_uuid(i), spa->range_guid, 16) == 0) > + if (!guid_equal(to_nfit_uuid(i), (guid_t *)>range_guid)) > return i; I think this should be guid_equal without the "!"

Re: [PATCH v2 1/5] acpi, nfit: Switch to use new generic UUID API

> for (i = 0; i < NFIT_UUID_MAX; i++) > - if (memcmp(to_nfit_uuid(i), spa->range_guid, 16) == 0) > + if (!guid_equal(to_nfit_uuid(i), (guid_t *)>range_guid)) > return i; I think this should be guid_equal without the "!"

Re: [PATCH 10/13] efi/capsule: Add support for Quark security header

On 5 June 2017 at 15:50, Ingo Molnar wrote: > > * Ard Biesheuvel wrote: > >> From: Jan Kiszka >> >> The firmware for Quark X102x prepends a security header to the capsule >> which is needed to support the mandatory secure boot

Re: [PATCH 10/13] efi/capsule: Add support for Quark security header

On 5 June 2017 at 15:50, Ingo Molnar wrote: > > * Ard Biesheuvel wrote: > >> From: Jan Kiszka >> >> The firmware for Quark X102x prepends a security header to the capsule >> which is needed to support the mandatory secure boot on this processor. >> The header can be detected by checking for the

Re: sparc64 gcc 7.1 compile error

From: Waldemar Brodkorb Date: Mon, 5 Jun 2017 11:19:41 +0200 > I get a compile/linking error with gcc 7.1 when targeting qemu system > sparc64. > > + objects='arch/sparc/kernel/head_64.o init/built-in.o > --start-group usr/built-in.o arch/sparc/built-in.o >

Re: sparc64 gcc 7.1 compile error

From: Waldemar Brodkorb Date: Mon, 5 Jun 2017 11:19:41 +0200 > I get a compile/linking error with gcc 7.1 when targeting qemu system > sparc64. > > + objects='arch/sparc/kernel/head_64.o init/built-in.o > --start-group usr/built-in.o arch/sparc/built-in.o > kernel/built-in.o

Re: [PATCH] qla2xxx: remove writeq/readq function definitions

> On Jun 2, 2017, at 4:32 AM, Corentin Labbe wrote: > > Instead of rewriting write/readq, use linux/io-64-nonatomic-lo-hi.h which > already have them. > > Signed-off-by: Corentin Labbe > --- > drivers/scsi/qla2xxx/qla_nx.h | 17

Re: [PATCH 2/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK

On Sat, 2017-06-03 at 22:10 +, Nicholas A. Bellinger wrote: > +static bool target_lookup_lun_from_tag(struct se_session *se_sess, u64 tag, > +u64 *unpacked_lun) > +{ > + struct se_cmd *se_cmd; > + unsigned long flags; > + bool ret = false; > + >

Re: [PATCH] qla2xxx: remove writeq/readq function definitions

> On Jun 2, 2017, at 4:32 AM, Corentin Labbe wrote: > > Instead of rewriting write/readq, use linux/io-64-nonatomic-lo-hi.h which > already have them. > > Signed-off-by: Corentin Labbe > --- > drivers/scsi/qla2xxx/qla_nx.h | 17 ++--- > 1 file changed, 2 insertions(+), 15

Re: [PATCH 2/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK

On Sat, 2017-06-03 at 22:10 +, Nicholas A. Bellinger wrote: > +static bool target_lookup_lun_from_tag(struct se_session *se_sess, u64 tag, > +u64 *unpacked_lun) > +{ > + struct se_cmd *se_cmd; > + unsigned long flags; > + bool ret = false; > + >

Re: [PATCH v4 4/5] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension

On Mon, 5 Jun 2017 16:22:56 +0100 Will Deacon wrote: > +/* Perf callbacks */ > +static int arm_spe_pmu_event_init(struct perf_event *event) > +{ > + u64 reg; > + struct perf_event_attr *attr = >attr; > + struct arm_spe_pmu *spe_pmu = to_spe_pmu(event->pmu); > + >

Re: [PATCH v4 4/5] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension

On Mon, 5 Jun 2017 16:22:56 +0100 Will Deacon wrote: > +/* Perf callbacks */ > +static int arm_spe_pmu_event_init(struct perf_event *event) > +{ > + u64 reg; > + struct perf_event_attr *attr = >attr; > + struct arm_spe_pmu *spe_pmu = to_spe_pmu(event->pmu); > + > + /* This is, of

Re: [PATCH 05/14] mwifiex: re-register wiphy across reset

Brian Norris writes: > On Thu, Jun 01, 2017 at 12:15:45PM +0300, Kalle Valo wrote: >> Brian Norris writes: >> >> > In general, it's helpful to use the same code for device removal as for >> > device reset, as this tends to have fewer bugs.

Re: [PATCH 05/14] mwifiex: re-register wiphy across reset

Brian Norris writes: > On Thu, Jun 01, 2017 at 12:15:45PM +0300, Kalle Valo wrote: >> Brian Norris writes: >> >> > In general, it's helpful to use the same code for device removal as for >> > device reset, as this tends to have fewer bugs. Let's move the wiphy >> > unregistration code into the

Re: [GIT PULL 00/13] First batch of EFI updates for v4.13

* Ard Biesheuvel wrote: > > It would be nice to fix your SOB flow: the maintainer who queues up a patch > > should > > add the SOB, and add an Acked-by of the co-maintainer if the co-maintainer > > agrees > > with the patch as well. The tree should typically not be

Re: [GIT PULL 00/13] First batch of EFI updates for v4.13

* Ard Biesheuvel wrote: > > It would be nice to fix your SOB flow: the maintainer who queues up a patch > > should > > add the SOB, and add an Acked-by of the co-maintainer if the co-maintainer > > agrees > > with the patch as well. The tree should typically not be rebased after that > >

Re: [PATCH] media: platform: s3c-camif: fix arguments position in function call

Hi Sylwester, Quoting Sylwester Nawrocki : On 06/02/2017 05:43 AM, Gustavo A. R. Silva wrote: Hi Sylwester, Here is another patch in case you decide that it is better to apply this one. Thanks, I applied this patch. In future please put any comments only after the

Re: [PATCH] media: platform: s3c-camif: fix arguments position in function call

Hi Sylwester, Quoting Sylwester Nawrocki : On 06/02/2017 05:43 AM, Gustavo A. R. Silva wrote: Hi Sylwester, Here is another patch in case you decide that it is better to apply this one. Thanks, I applied this patch. In future please put any comments only after the scissors ("---") line,

Re: [PATCH 10/13] efi/capsule: Add support for Quark security header

* Ard Biesheuvel wrote: > From: Jan Kiszka > > The firmware for Quark X102x prepends a security header to the capsule > which is needed to support the mandatory secure boot on this processor. > The header can be detected by checking for the

Re: [PATCH v4 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Wed, 24 May 2017 14:04:05 +0200 Vitaly Kuznetsov wrote: > Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others(). > Tracing is done the same way we do xen_mmu_flush_tlb_others(). > > Signed-off-by: Vitaly Kuznetsov > Acked-by: K. Y.

Re: [PATCH 10/13] efi/capsule: Add support for Quark security header

* Ard Biesheuvel wrote: > From: Jan Kiszka > > The firmware for Quark X102x prepends a security header to the capsule > which is needed to support the mandatory secure boot on this processor. > The header can be detected by checking for the "_CSH" signature and - > to avoid any GUID conflict

Re: [PATCH v4 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Wed, 24 May 2017 14:04:05 +0200 Vitaly Kuznetsov wrote: > Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others(). > Tracing is done the same way we do xen_mmu_flush_tlb_others(). > > Signed-off-by: Vitaly Kuznetsov > Acked-by: K. Y. Srinivasan > Tested-by: Simon Xiao >

RE: [PATCH v3 19/27] thunderbolt: Add new Thunderbolt PCI IDs

> -Original Message- > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > Sent: Monday, June 5, 2017 10:41 AM > To: Greg Kroah-Hartman > Cc: Andy Shevchenko ; Lukas Wunner > ; Andreas Noever

RE: [PATCH v3 19/27] thunderbolt: Add new Thunderbolt PCI IDs

> -Original Message- > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > Sent: Monday, June 5, 2017 10:41 AM > To: Greg Kroah-Hartman > Cc: Andy Shevchenko ; Lukas Wunner > ; Andreas Noever ; Michael > Jamet ; Yehezkel Bernat ; > Amir Levy ; Andy Lutomirski ; > Limonciello,

Re: [PATCH v3 19/27] thunderbolt: Add new Thunderbolt PCI IDs

On Mon, Jun 05, 2017 at 05:20:36PM +0200, Greg Kroah-Hartman wrote: > On Mon, Jun 05, 2017 at 05:21:34PM +0300, Andy Shevchenko wrote: > > On Mon, 2017-06-05 at 16:33 +0300, Mika Westerberg wrote: > > > On Mon, Jun 05, 2017 at 03:55:07PM +0300, Mika Westerberg wrote: > > > > > > > > > > It turns

Re: [PATCH v3 19/27] thunderbolt: Add new Thunderbolt PCI IDs

On Mon, Jun 05, 2017 at 05:20:36PM +0200, Greg Kroah-Hartman wrote: > On Mon, Jun 05, 2017 at 05:21:34PM +0300, Andy Shevchenko wrote: > > On Mon, 2017-06-05 at 16:33 +0300, Mika Westerberg wrote: > > > On Mon, Jun 05, 2017 at 03:55:07PM +0300, Mika Westerberg wrote: > > > > > > > > > > It turns

Re: [bisected] Re: tty lockdep trace

On Mon, 2017-06-05 at 16:09 +0100, Alan Cox wrote: > On Sun, 04 Jun 2017 13:34:31 +0200 > Mike Galbraith wrote: > > > On Sun, 2017-06-04 at 12:00 +0200, Vegard Nossum wrote: > > > > > > I don't know how you did it, but this passes my testing (reproducers for > > > both the

Re: [bisected] Re: tty lockdep trace

On Mon, 2017-06-05 at 16:09 +0100, Alan Cox wrote: > On Sun, 04 Jun 2017 13:34:31 +0200 > Mike Galbraith wrote: > > > On Sun, 2017-06-04 at 12:00 +0200, Vegard Nossum wrote: > > > > > > I don't know how you did it, but this passes my testing (reproducers for > > > both the original issue and

Re: [PATCH 01/13] x86/efi: Clean up efi CR3 save/restore

* Ard Biesheuvel wrote: > From: Andy Lutomirski > > efi_call_phys_prolog() used to return a "pgd_t *" that meant one of > three different things depending on kernel and system configuration. > Clean it up so it uses a union and is more explicit

Re: [PATCH 01/13] x86/efi: Clean up efi CR3 save/restore

* Ard Biesheuvel wrote: > From: Andy Lutomirski > > efi_call_phys_prolog() used to return a "pgd_t *" that meant one of > three different things depending on kernel and system configuration. > Clean it up so it uses a union and is more explicit about what's > going on. > > Signed-off-by:

Re: [PATCH 0/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support

> On Jun 3, 2017, at 3:10 PM, Nicholas A. Bellinger > wrote: > > From: Nicholas Bellinger > > Hi Himanshu + Quinn, > > Here is a small series to introduce proper percpu se_lun->lun_ref > counting for TMR, and add common code in target_submit_tmr()

Re: [PATCH 0/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support

> On Jun 3, 2017, at 3:10 PM, Nicholas A. Bellinger > wrote: > > From: Nicholas Bellinger > > Hi Himanshu + Quinn, > > Here is a small series to introduce proper percpu se_lun->lun_ref > counting for TMR, and add common code in target_submit_tmr() to > do tag lookup for unpacked_lun in

Re: [PATCH v2 7/7] drm/atmel-hlcdc: Replace the panel usage with drm_panel_bridge.

Hi, When pushing to drm-misc-next, I got a minor merge conflict when dim tried to rebuild drm-tip. The reason for the conflict was because the following commit was present in drm-tip but not in drm-misc:

Re: [PATCH v2 7/7] drm/atmel-hlcdc: Replace the panel usage with drm_panel_bridge.

Hi, When pushing to drm-misc-next, I got a minor merge conflict when dim tried to rebuild drm-tip. The reason for the conflict was because the following commit was present in drm-tip but not in drm-misc:

<    9   10   11   12   13   14   15   16   17   18   >