Re: I'd like to donate a MacBook Pro
On 04.05.2017 05:34, Alex Henrie wrote: 2017-05-03 8:58 GMT-06:00 Joerg Roedel : On Wed, May 03, 2017 at 08:35:47AM -0600, Alex Henrie wrote: 2017-05-03 5:58 GMT-06:00 Greg KH : On Tue, May 02, 2017 at 10:55:09PM -0600, Alex Henrie wrote: Today I ran a regression test to determine which commit made the keyboard stop working entirely. The last commit that worked for me was c09e22d5370739e16463c113525df51b5980b1d5. After that, there is a long series of commits where the screen stays black, and after that, I start getting errors like the one above. So git bisect said that commit was a good change, what one was the "bad" commit that git bisect pointed at? The commit right after that, but it's not clear whether the screen blanking problem was part of the same bug or just another bug that was introduced at about the same time. That would be 39ab9555c24110671f8dc671311a26e5c985b592: iommu: Add sysfs bindings for struct iommu_device And it introduced a regression when iommu-sysfs entries are accessed. This is fixed in a7fdb6e648fb. Does that commit fix the screen blanking problem? At a7fdb6e648fb the screen works but the keyboard is broken. I think that the screen was actually fixed by an earlier commit, but when I tried to run a regression test to find when the keyboard problem appeared after the screen was fixed, I gave up because testing each revision takes about half an hour and the keyboard problem appears to be somewhat intermittent. -Alex Looks like there are a few people suffering from macbook xhci related issues From the bugs linked it looks like there are both some UEFI issues and a non-responsive usb device at boot. at least one USB device does not respond to a address device command, and driver times out and aborts the command after 5 second. I don't think I can do anything about the UEFI or the first 5 second command timeout from the xhci driver, but after that some improvement could be done. This timeout code path in the xhci driver is not exercised that often. Some minor races were fixed in 4.11 in this area, and better tracing added, but unfortunately I just discovered there is also has a regression in 4.11 If you can help me debug this by compiling some new kernels and taking logs and traces on your MacBook we could get this forward. I set up a branch for this issue, it has the race-fixes, tracing and regression fixes: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git xhci-macbook Remember to check out the xhci-macbook branch. Can you compile and run that kernel on yout MacBook, and take logs? Traces can be enabled by adding "trace_event=xhci-hcd" to you kernel command line, then send me the output of both dmesg and /sys/kernel/debug/tracing/trace after the issue is seen. Thanks -Mathias
Re: [PATCH] x86/efi: Add EFI_PGT_DUMP support for x86_32, kexec and efi=old_map
On Wed, May 10, 2017 at 03:49:05PM -0700, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > EFI_PGT_DUMP, as the name suggests dumps efi page tables to dmesg during > kernel boot. This feature is very useful while debugging page > faults/null pointer dereferences to efi related addresses. Presently, > this feature is limited only to x86_64, so let's extend it to other efi > configurations like kexec kernel, efi=old_map and to x86_32 as well. > This doesn't effect normal boot path because this config option should > be used only for debug purposes. > > Signed-off-by: Sai Praneeth Prakhya > Cc: Borislav Petkov > Cc: Ricardo Neri > Cc: Matt Fleming > Cc: Ard Biesheuvel > Cc: Ravi Shankar > --- > arch/x86/platform/efi/efi.c| 2 ++ > arch/x86/platform/efi/efi_32.c | 9 - > arch/x86/platform/efi/efi_64.c | 5 - > 3 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c > index 217dc166c649..a6d6cd8fe78a 100644 > --- a/arch/x86/platform/efi/efi.c > +++ b/arch/x86/platform/efi/efi.c > @@ -890,6 +890,8 @@ static void __init kexec_enter_virtual_mode(void) > if (efi_enabled(EFI_OLD_MEMMAP) && (__supported_pte_mask & _PAGE_NX)) > runtime_code_page_mkexec(); > > + efi_dump_pagetable(); You can call that only once at the end of efi_enter_virtual_mode() instead of adding it here and leaving it in __efi_enter_virtual_mode(). -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode
On Tue, May 09, 2017 at 04:31:00PM -0700, Kees Cook wrote: > > I don't like silent fixups. If we want to do this, we should BUG or > > at least WARN, not just change the addr limit. But I'm also not > > convinced it's indicative of an actual bug here. > > Nothing should enter that function with KERNEL_DS set, right? > > BUG_ON(get_fs() != USER_DS); We're feeling triggerhappy, aren't we? A nice juicy WARN-splat along with a fixup looks much better than killing the box, to me. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH 1/2] KVM: nVMX: fix EPT permissions as reported in exit qualification
This fixes the new ept_access_test_read_only and ept_access_test_read_write
testcases from vmx.flat.
The problem is that gpte_access moves bits around to switch from EPT
bit order (XWR) to ACC_*_MASK bit order (RWX). This results in an
incorrect exit qualification. To fix this, make pt_access and
pte_access operate on raw PTE values (only with NX flipped to mean
"can execute") and call gpte_access at the end of the walk. This
lets us use pte_access to compute the exit qualification with XWR
bit order.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/paging_tmpl.h | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 56241746abbd..b0454c7e4cff 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -283,11 +283,13 @@ static int FNAME(walk_addr_generic)(struct guest_walker
*walker,
pt_element_t pte;
pt_element_t __user *uninitialized_var(ptep_user);
gfn_t table_gfn;
- unsigned index, pt_access, pte_access, accessed_dirty, pte_pkey;
+ u64 pt_access, pte_access;
+ unsigned index, accessed_dirty, pte_pkey;
unsigned nested_access;
gpa_t pte_gpa;
bool have_ad;
int offset;
+ u64 walk_nx_mask = 0;
const int write_fault = access & PFERR_WRITE_MASK;
const int user_fault = access & PFERR_USER_MASK;
const int fetch_fault = access & PFERR_FETCH_MASK;
@@ -302,6 +304,7 @@ static int FNAME(walk_addr_generic)(struct guest_walker
*walker,
have_ad = PT_HAVE_ACCESSED_DIRTY(mmu);
#if PTTYPE == 64
+ walk_nx_mask = 1ULL << PT64_NX_SHIFT;
if (walker->level == PT32E_ROOT_LEVEL) {
pte = mmu->get_pdptr(vcpu, (addr >> 30) & 3);
trace_kvm_mmu_paging_element(pte, walker->level);
@@ -313,8 +316,6 @@ static int FNAME(walk_addr_generic)(struct guest_walker
*walker,
walker->max_level = walker->level;
ASSERT(!(is_long_mode(vcpu) && !is_pae(vcpu)));
- accessed_dirty = have_ad ? PT_GUEST_ACCESSED_MASK : 0;
-
/*
* FIXME: on Intel processors, loads of the PDPTE registers for PAE
paging
* by the MOV to CR instruction are treated as reads and do not cause
the
@@ -322,14 +323,14 @@ static int FNAME(walk_addr_generic)(struct guest_walker
*walker,
*/
nested_access = (have_ad ? PFERR_WRITE_MASK : 0) | PFERR_USER_MASK;
- pt_access = pte_access = ACC_ALL;
+ pte_access = ~0;
++walker->level;
do {
gfn_t real_gfn;
unsigned long host_addr;
- pt_access &= pte_access;
+ pt_access = pte_access;
--walker->level;
index = PT_INDEX(addr, walker->level);
@@ -371,6 +372,12 @@ static int FNAME(walk_addr_generic)(struct guest_walker
*walker,
trace_kvm_mmu_paging_element(pte, walker->level);
+ /*
+* Inverting the NX it lets us AND it like other
+* permission bits.
+*/
+ pte_access = pt_access & (pte ^ walk_nx_mask);
+
if (unlikely(!FNAME(is_present_gpte)(pte)))
goto error;
@@ -379,14 +386,16 @@ static int FNAME(walk_addr_generic)(struct guest_walker
*walker,
goto error;
}
- accessed_dirty &= pte;
- pte_access = pt_access & FNAME(gpte_access)(vcpu, pte);
-
walker->ptes[walker->level - 1] = pte;
} while (!is_last_gpte(mmu, walker->level, pte));
pte_pkey = FNAME(gpte_pkeys)(vcpu, pte);
- errcode = permission_fault(vcpu, mmu, pte_access, pte_pkey, access);
+ accessed_dirty = have_ad ? pte_access & PT_GUEST_ACCESSED_MASK : 0;
+
+ /* Convert to ACC_*_MASK flags for struct guest_walker. */
+ walker->pt_access = FNAME(gpte_access)(vcpu, pt_access ^ walk_nx_mask);
+ walker->pte_access = FNAME(gpte_access)(vcpu, pte_access ^
walk_nx_mask);
+ errcode = permission_fault(vcpu, mmu, walker->pte_access, pte_pkey,
access);
if (unlikely(errcode))
goto error;
@@ -403,7 +412,7 @@ static int FNAME(walk_addr_generic)(struct guest_walker
*walker,
walker->gfn = real_gpa >> PAGE_SHIFT;
if (!write_fault)
- FNAME(protect_clean_gpte)(mmu, &pte_access, pte);
+ FNAME(protect_clean_gpte)(mmu, &walker->pte_access, pte);
else
/*
* On a write fault, fold the dirty bit into accessed_dirty.
@@ -421,10 +430,8 @@ static int FNAME(walk_addr_generic)(struct guest_walker
*walker,
goto retry_walk;
}
- walker->pt_access = pt_access;
- walker->pte_access = pte_access;
pgprintk("%s: pte %llx pte_access %x pt_access %x\n",
-__func__, (u64)pte, pte_access, p
[PATCH 2/2] KVM: nVMX: fix nEPT handling of guest page table accesses
The new ept_access_test_paddr_read_only_ad_disabled testcase
caused an infinite stream of EPT violations because KVM did not
find anything bad in the page tables and kept re-executing the
faulting instruction.
This is because the exit qualification said we were reading from
the page tables, but actually writing the cause of the EPT violation
was writing the A/D bits. This happened even with eptad=0, quite
surprisingly.
Thus, always treat guest page table accesses as read+write operations,
even if the exit qualification says otherwise. This fixes the
testcase.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/vmx.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c6f4ad44aa95..c868cbdad29a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6209,17 +6209,19 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu)
u32 error_code;
exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
+ gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS);
+ trace_kvm_page_fault(gpa, exit_qualification);
- if (is_guest_mode(vcpu)
- && !(exit_qualification & EPT_VIOLATION_GVA_TRANSLATED)) {
- /*
-* Fix up exit_qualification according to whether guest
-* page table accesses are reads or writes.
-*/
- u64 eptp = nested_ept_get_cr3(vcpu);
- if (!(eptp & VMX_EPT_AD_ENABLE_BIT))
- exit_qualification &= ~EPT_VIOLATION_ACC_WRITE;
- }
+ /*
+* All guest page table accesses are potential writes to A/D bits.
+* but EPT microcode only reports them as such when EPT A/D is
+* enabled. Tracing ept_access_test_paddr_read_only_ad_disabled (from
+* kvm-unit-tests) with eptad=0 and eptad=1 shows that the processor
+* does not change its behavior when EPTP enables A/D bits; the only
+* difference is in the exit qualification. So fix this up here.
+*/
+ if (!(exit_qualification & EPT_VIOLATION_GVA_TRANSLATED))
+ exit_qualification |= EPT_VIOLATION_ACC_WRITE;
/*
* EPT violation happened while executing iret from NMI,
@@ -6231,9 +6233,6 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu)
(exit_qualification & INTR_INFO_UNBLOCK_NMI))
vmcs_set_bits(GUEST_INTERRUPTIBILITY_INFO,
GUEST_INTR_STATE_NMI);
- gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS);
- trace_kvm_page_fault(gpa, exit_qualification);
-
/* Is it a read fault? */
error_code = (exit_qualification & EPT_VIOLATION_ACC_READ)
? PFERR_USER_MASK : 0;
@@ -6250,6 +6249,17 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu)
? PFERR_PRESENT_MASK : 0;
vcpu->arch.gpa_available = true;
+
+ if (is_guest_mode(vcpu)
+ && !(exit_qualification & EPT_VIOLATION_GVA_TRANSLATED)) {
+ /*
+* Now fix up exit_qualification according to what the
+* L1 hypervisor expects to see.
+*/
+ u64 eptp = nested_ept_get_cr3(vcpu);
+ if (!(eptp & VMX_EPT_AD_ENABLE_BIT))
+ exit_qualification &= ~EPT_VIOLATION_ACC_WRITE;
+ }
vcpu->arch.exit_qualification = exit_qualification;
return kvm_mmu_page_fault(vcpu, gpa, error_code, NULL, 0);
--
1.8.3.1
[PATCH 0/2] KVM: nVMX: nested EPT fixes
These two patches fix a couple corner cases identified by the new tests in vmx.flat. See the individual patches for more information. Paolo Paolo Bonzini (2): KVM: nVMX: fix EPT permissions as reported in exit qualification KVM: nVMX: fix nEPT handling of guest page table accesses arch/x86/kvm/paging_tmpl.h | 35 +-- arch/x86/kvm/vmx.c | 36 +++- 2 files changed, 44 insertions(+), 27 deletions(-) -- 1.8.3.1
Re: [PATCH v9 3/3] printk: fix double printing with earlycon
On (05/11/17 17:41), Sergey Senozhatsky wrote: [..] > Alexey, > can we have preferred console at offset 0 (not at console_cmdline_cnt - 1) > and restore the previous register_console() iteration order? btw, what if someone has configured the system as console= non-braille non-braille braille non-braille? "The last non-braille console is always the preferred one" is not true in this case. -ss
Re: [PATCH] gpio: aspeed: Don't attempt to debounce if disabled
On Tue, May 2, 2017 at 8:08 AM, Joel Stanley wrote: > We warn the user at driver probe time that debouncing is disabled. > However, if they request debouncing later on we print a confusing error > message: > > gpio_aspeed 1e78.gpio: Failed to convert 5000us to cycles at 0Hz: -524 > > Instead bail out when the clock is not present. > > Fixes: 5ae4cb94b3133 (gpio: aspeed: Add debounce support) > Signed-off-by: Joel Stanley Patch applied for fixes. Yours, Linus Walleij
Re: [PATCH 1/9] pinctrl: Use seq_putc() in three functions
On Tue, May 2, 2017 at 11:21 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 1 May 2017 22:24:29 +0200 > > A single character (line break) should be put into a sequence. > Thus use the corresponding function "seq_putc". > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Looks reasonable. Patch applied. Yours, Linus Walleij
[PATCH] ovl: select EXPORTFS
We get a link error when EXPORTFS is not enabled:
ERROR: "exportfs_encode_fh" [fs/overlayfs/overlay.ko] undefined!
ERROR: "exportfs_decode_fh" [fs/overlayfs/overlay.ko] undefined!
This adds a Kconfig 'select' statement for overlayfs, the same way that
it is done for the other users of exportfs.
Fixes: 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up")
Signed-off-by: Arnd Bergmann
---
fs/overlayfs/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/overlayfs/Kconfig b/fs/overlayfs/Kconfig
index 0daac5112f7a..c0c9683934b7 100644
--- a/fs/overlayfs/Kconfig
+++ b/fs/overlayfs/Kconfig
@@ -1,5 +1,6 @@
config OVERLAY_FS
tristate "Overlay filesystem support"
+ select EXPORTFS
help
An overlay filesystem combines two filesystems - an 'upper' filesystem
and a 'lower' filesystem. When a name exists in both filesystems, the
--
2.9.0
[PATCH] iommu/mediatek: include linux/dma-mapping.h
The mediatek iommu driver relied on an implicit include of dma-mapping.h, but for some reason that is no longer there in 4.12-rc1: drivers/iommu/mtk_iommu_v1.c: In function 'mtk_iommu_domain_finalise': drivers/iommu/mtk_iommu_v1.c:233:16: error: implicit declaration of function 'dma_zalloc_coherent'; did you mean 'debug_dma_alloc_coherent'? [-Werror=implicit-function-declaration] drivers/iommu/mtk_iommu_v1.c: In function 'mtk_iommu_domain_free': drivers/iommu/mtk_iommu_v1.c:265:2: error: implicit declaration of function 'dma_free_coherent'; did you mean 'debug_dma_free_coherent'? [-Werror=implicit-function-declaration] This adds an explicit #include to make it build again. Signed-off-by: Arnd Bergmann --- drivers/iommu/mtk_iommu_v1.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c index a27ef570c328..bc1efbfb9ddf 100644 --- a/drivers/iommu/mtk_iommu_v1.c +++ b/drivers/iommu/mtk_iommu_v1.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include -- 2.9.0
Re: [PATCH 03/16] uuid: rename uuid types
On Wed, 2017-05-10 at 19:20 +0100, David Howells wrote: > Christoph Hellwig wrote: > > > -#define NULL_UUID_LE > > \ > > - UUID_LE(0x, 0x, 0x, 0x00, 0x00, 0x00, 0x00, > > \ > > - 0x00, 0x00, 0x00, 0x00) > > +#define NULL_GUID > > \ > > + GUID(0x, 0x, 0x, 0x00, 0x00, 0x00, 0x00, > > \ > > + 0x00, 0x00, 0x00, 0x00) > > > > -#define NULL_UUID_BE > > \ > > - UUID_BE(0x, 0x, 0x, 0x00, 0x00, 0x00, 0x00, > > \ > > - 0x00, 0x00, 0x00, 0x00) > > +#define NULL_UUID > > \ > > + UUID(0x, 0x, 0x, 0x00, 0x00, 0x00, 0x00, > > \ > > + 0x00, 0x00, 0x00, 0x00) > > These are UAPI and ought not to be renamed. > Good point. I see in the branch it's already fixed. -- Andy Shevchenko Intel Finland Oy
[PATCH] staging: ccree: remove unused function argument
"gcc -Wunused" warns about one argument being assigned but not used:
drivers/staging/ccree/ssi_cipher.c: In function 'ssi_blkcipher_complete':
drivers/staging/ccree/ssi_cipher.c:747:41: error: parameter 'info' set but not
used [-Werror=unused-but-set-parameter]
We can simply drop that argument here and in its callers.
Fixes: 302ef8ebb4b2 ("staging: ccree: add skcipher support")
Signed-off-by: Arnd Bergmann
---
drivers/staging/ccree/ssi_cipher.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/ccree/ssi_cipher.c
b/drivers/staging/ccree/ssi_cipher.c
index 664ed7e52cf2..d114cd07e729 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -744,7 +744,6 @@ static int ssi_blkcipher_complete(struct device *dev,
struct ssi_ablkcipher_ctx *ctx_p,
struct blkcipher_req_ctx *req_ctx,
struct scatterlist *dst, struct scatterlist
*src,
- void *info, //req info
unsigned int ivsize,
void *areq,
void __iomem *cc_base)
@@ -755,7 +754,6 @@ static int ssi_blkcipher_complete(struct device *dev,
START_CYCLE_COUNT();
ssi_buffer_mgr_unmap_blkcipher_request(dev, req_ctx, ivsize, src, dst);
- info = req_ctx->backup_info;
END_CYCLE_COUNT(STAT_OP_TYPE_GENERIC, STAT_PHASE_4);
@@ -895,7 +893,7 @@ static int ssi_blkcipher_process(
END_CYCLE_COUNT(ssi_req.op_type, STAT_PHASE_3);
} else {
END_CYCLE_COUNT(ssi_req.op_type, STAT_PHASE_3);
- rc = ssi_blkcipher_complete(dev, ctx_p, req_ctx, dst,
src, info, ivsize, NULL, ctx_p->drvdata->cc_base);
+ rc = ssi_blkcipher_complete(dev, ctx_p, req_ctx, dst,
src, ivsize, NULL, ctx_p->drvdata->cc_base);
}
}
@@ -916,7 +914,7 @@ static void ssi_ablkcipher_complete(struct device *dev,
void *ssi_req, void __io
CHECK_AND_RETURN_VOID_UPON_FIPS_ERROR();
- ssi_blkcipher_complete(dev, ctx_p, req_ctx, areq->dst, areq->src,
areq->info, ivsize, areq, cc_base);
+ ssi_blkcipher_complete(dev, ctx_p, req_ctx, areq->dst, areq->src,
ivsize, areq, cc_base);
}
--
2.9.0
[PATCH] soc: imx: add PM dependency for IMX7_PM_DOMAINS
The new pm domain driver causes a build failure when CONFIG_PM
is not set:
warning: (IMX7_PM_DOMAINS) selects PM_GENERIC_DOMAINS which has unmet direct
dependencies (PM)
drivers/base/power/domain_governor.c: In function 'default_suspend_ok':
drivers/base/power/domain_governor.c:75:17: error: 'struct dev_pm_info' has no
member named 'ignore_children'
This adds a dependency to ensure that we don't attempt to build the
driver without CONFIG_PM.
Fixes: 03aa12629fc4 ("soc: imx: Add GPCv2 power gating driver")
Signed-off-by: Arnd Bergmann
---
drivers/soc/imx/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
index 357a5d8f8da0..a5b86a28f343 100644
--- a/drivers/soc/imx/Kconfig
+++ b/drivers/soc/imx/Kconfig
@@ -2,8 +2,9 @@ menu "i.MX SoC drivers"
config IMX7_PM_DOMAINS
bool "i.MX7 PM domains"
- select PM_GENERIC_DOMAINS
depends on SOC_IMX7D || (COMPILE_TEST && OF)
+ depends on PM
+ select PM_GENERIC_DOMAINS
default y if SOC_IMX7D
endmenu
--
2.9.0
Re: [PATCH] soc: imx: add PM dependency for IMX7_PM_DOMAINS
On Thu, May 11, 2017 at 8:37 AM, Arnd Bergmann wrote:
> The new pm domain driver causes a build failure when CONFIG_PM
> is not set:
>
> warning: (IMX7_PM_DOMAINS) selects PM_GENERIC_DOMAINS which has unmet direct
> dependencies (PM)
> drivers/base/power/domain_governor.c: In function 'default_suspend_ok':
> drivers/base/power/domain_governor.c:75:17: error: 'struct dev_pm_info' has
> no member named 'ignore_children'
>
> This adds a dependency to ensure that we don't attempt to build the
> driver without CONFIG_PM.
>
> Fixes: 03aa12629fc4 ("soc: imx: Add GPCv2 power gating driver")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Fabio Estevam
[PATCH] bluetooth: hci_ll: add proper SERDEV dependency
When SERDEV is a loadable module, and the HCI code is built-in, we
get a link error:
drivers/bluetooth/built-in.o: In function `ll_close':
hci_ll.c:(.text+0x278d): undefined reference to `serdev_device_close'
drivers/bluetooth/built-in.o: In function `hci_ti_probe':
hci_ll.c:(.text+0x283c): undefined reference to `hci_uart_register_device'
drivers/bluetooth/built-in.o: In function `ll_setup':
hci_ll.c:(.text+0x289e): undefined reference to `serdev_device_set_flow_control'
hci_ll.c:(.text+0x2b9c): undefined reference to `serdev_device_set_baudrate'
drivers/bluetooth/built-in.o: In function `ll_open':
hci_ll.c:(.text+0x2c77): undefined reference to `serdev_device_open'
drivers/bluetooth/built-in.o: In function `ll_init':
(.init.text+0x10d): undefined reference to `__serdev_device_driver_register'
We already have CONFIG_BT_HCIUART_SERDEV as a Kconfig symbol that is
set when the serdev code is reachable by a driver. Unlike the nokia
driver, this one can also be built when serdev is completely disabled,
so we add a dependency on serdev either being usable or disabled here.
Fixes: 371805522f87 ("bluetooth: hci_uart: add LL protocol serdev driver
support")
Cc: Rob Herring
Signed-off-by: Arnd Bergmann
---
drivers/bluetooth/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index a63130ef2b98..b2cf0ae6b62d 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -133,6 +133,7 @@ config BT_HCIUART_ATH3K
config BT_HCIUART_LL
bool "HCILL protocol support"
depends on BT_HCIUART
+ depends on BT_HCIUART_SERDEV || SERIAL_DEV_BUS=n
help
HCILL (HCI Low Level) is a serial protocol for communication
between Bluetooth device and host. This protocol is required for
--
2.9.0
Re: [PATCH 05/16] uuid: add the v1 layout to uuid_t
On Wed, 2017-05-10 at 20:02 +0200, Christoph Hellwig wrote:
> Turn the content of uuid_t into a union and add the fields for the v1
> interpretation to it.
In the branch it has fix for UUID() wrt union change, but there missed
similar for GUID().
+#define UUID(a, _b, c, d0, d1, d2, d3, d4, d5, d6,
d7) \
+{ .b = { \
^^^ This should be done for GUID() as well.
While here, can we indent \ to be the same as of the rest lines in
macro(s) ?
--
Andy Shevchenko
Intel Finland Oy
[PATCH] efi: remove duplicate 'const' specifiers
gcc-7 shows a harmless warning:
drivers/firmware/efi/libstub/secureboot.c:19:27: error: duplicate 'const'
declaration specifier [-Werror=duplicate-decl-specifier]
static const efi_char16_t const efi_SecureBoot_name[] = {
drivers/firmware/efi/libstub/secureboot.c:22:27: error: duplicate 'const'
declaration specifier [-Werror=duplicate-decl-specifier]
Removing one of the specifiers gives us the expected behavior.
Fixes: de8cb458625c ("efi: Get and store the secure boot status")
Signed-off-by: Arnd Bergmann
---
drivers/firmware/efi/libstub/secureboot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/efi/libstub/secureboot.c
b/drivers/firmware/efi/libstub/secureboot.c
index 8c34d50a4d80..959777ec8a77 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -16,10 +16,10 @@
/* BIOS variables */
static const efi_guid_t efi_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
-static const efi_char16_t const efi_SecureBoot_name[] = {
+static const efi_char16_t efi_SecureBoot_name[] = {
'S', 'e', 'c', 'u', 'r', 'e', 'B', 'o', 'o', 't', 0
};
-static const efi_char16_t const efi_SetupMode_name[] = {
+static const efi_char16_t efi_SetupMode_name[] = {
'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
};
--
2.9.0
[PATCH 1/2] ASoC: rt5514: fix gcc-7 warning
gcc-7 warns that there is a duplicate 'const' specifier in some
variables that are declared using the SOC_ENUM_SINGLE_DECL macro:
sound/soc/codecs/rt5514.c:398:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(
sound/soc/codecs/rt5514.c:405:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(
This removes one to fix the warning.
Fixes: 4a6180ea7399 ("ASoC: rt5514: add rt5514 codec driver")
Signed-off-by: Arnd Bergmann
---
sound/soc/codecs/rt5514.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/rt5514.c b/sound/soc/codecs/rt5514.c
index f91221b1ddf0..28ab9e2bb051 100644
--- a/sound/soc/codecs/rt5514.c
+++ b/sound/soc/codecs/rt5514.c
@@ -395,14 +395,14 @@ static const char * const rt5514_dmic_src[] = {
"DMIC1", "DMIC2"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5514_stereo1_dmic_enum, RT5514_DIG_SOURCE_CTRL,
RT5514_AD0_DMIC_INPUT_SEL_SFT, rt5514_dmic_src);
static const struct snd_kcontrol_new rt5514_sto1_dmic_mux =
SOC_DAPM_ENUM("Stereo1 DMIC Source", rt5514_stereo1_dmic_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5514_stereo2_dmic_enum, RT5514_DIG_SOURCE_CTRL,
RT5514_AD1_DMIC_INPUT_SEL_SFT, rt5514_dmic_src);
--
2.9.0
[PATCH] V4L/DVB: ir-core: fix gcc-7 warning on bool arithmetic
gcc-7 suggests that an expression using a bitwise not and a bitmask
on a 'bool' variable is better written using boolean logic:
drivers/media/rc/imon.c: In function 'imon_incoming_scancode':
drivers/media/rc/imon.c:1725:22: error: '~' on a boolean expression
[-Werror=bool-operation]
ictx->pad_mouse = ~(ictx->pad_mouse) & 0x1;
^
drivers/media/rc/imon.c:1725:22: note: did you mean to use logical not?
I agree.
Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver")
Signed-off-by: Arnd Bergmann
---
drivers/media/rc/imon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 3489010601b5..bd76534a2749 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1722,7 +1722,7 @@ static void imon_incoming_scancode(struct imon_context
*ictx,
if (kc == KEY_KEYBOARD && !ictx->release_code) {
ictx->last_keycode = kc;
if (!nomouse) {
- ictx->pad_mouse = ~(ictx->pad_mouse) & 0x1;
+ ictx->pad_mouse = !ictx->pad_mouse;
dev_dbg(dev, "toggling to %s mode\n",
ictx->pad_mouse ? "mouse" : "keyboard");
spin_unlock_irqrestore(&ictx->kc_lock, flags);
--
2.9.0
[PATCH 2/2] ASoC: rt5665: fix gcc-7 warning
gcc-7 warns that there is a duplicate 'const' specifier in some
variables that are declared using the SOC_ENUM_SINGLE_DECL macro:
sound/soc/codecs/rt5665.c:915:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_01_adc_enum,
sound/soc/codecs/rt5665.c:918:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_23_adc_enum,
sound/soc/codecs/rt5665.c:921:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_45_adc_enum,
sound/soc/codecs/rt5665.c:924:14: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_67_adc_enum,
...
This removes one to fix the 68 warnings in this file
Fixes: 33ada14a26c8 ("ASoC: add rt5665 codec driver")
Signed-off-by: Arnd Bergmann
---
sound/soc/codecs/rt5665.c | 136 +++---
1 file changed, 68 insertions(+), 68 deletions(-)
diff --git a/sound/soc/codecs/rt5665.c b/sound/soc/codecs/rt5665.c
index 8cd22307f5b6..14b0cf89edf5 100644
--- a/sound/soc/codecs/rt5665.c
+++ b/sound/soc/codecs/rt5665.c
@@ -912,46 +912,46 @@ static const char * const rt5665_data_select[] = {
"L/R", "R/L", "L/L", "R/R"
};
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_01_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_1_01_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_1_DS_ADC_SLOT01_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_23_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_1_23_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_1_DS_ADC_SLOT23_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_45_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_1_45_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_1_DS_ADC_SLOT45_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_1_67_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_1_67_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_1_DS_ADC_SLOT67_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_2_01_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_2_01_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_2_DS_ADC_SLOT01_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_2_23_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_2_23_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_2_DS_ADC_SLOT23_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_2_45_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_2_45_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_2_DS_ADC_SLOT45_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if1_2_67_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if1_2_67_adc_enum,
RT5665_TDM_CTRL_2, RT5665_I2S1_2_DS_ADC_SLOT67_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if2_1_dac_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if2_1_dac_enum,
RT5665_DIG_INF2_DATA, RT5665_IF2_1_DAC_SEL_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if2_1_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if2_1_adc_enum,
RT5665_DIG_INF2_DATA, RT5665_IF2_1_ADC_SEL_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if2_2_dac_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if2_2_dac_enum,
RT5665_DIG_INF2_DATA, RT5665_IF2_2_DAC_SEL_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if2_2_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if2_2_adc_enum,
RT5665_DIG_INF2_DATA, RT5665_IF2_2_ADC_SEL_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if3_dac_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if3_dac_enum,
RT5665_DIG_INF3_DATA, RT5665_IF3_DAC_SEL_SFT, rt5665_data_select);
-static const SOC_ENUM_SINGLE_DECL(rt5665_if3_adc_enum,
+static SOC_ENUM_SINGLE_DECL(rt5665_if3_adc_enum,
RT5665_DIG_INF3_DATA, RT5665_IF3_ADC_SEL_SFT, rt5665_data_select);
static const struct snd_kcontrol_new rt5665_if1_1_01_adc_swap_mux =
@@ -1819,14 +1819,14 @@ static const char * const rt5665_dac2_src[] = {
"IF1 DAC2", "IF2_1 DAC", "IF2_2 DAC", "IF3 DAC", "Mono ADC MIX"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5665_dac_l2_enum, RT5665_DAC2_CTRL,
RT5665_DAC_L2_SEL_SFT, rt5665_dac2_src);
static const struct snd_kcontrol_new rt5665_dac_l2_mux =
SOC_DAPM_ENUM("Digital DAC L2 Source", rt5665_dac_l2_enum);
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SINGLE_DECL(
rt5665_dac_r2_enum, RT5665_DAC2_CTRL,
RT5665_DAC_R2_SEL_SFT, rt5665_dac2_src);
@@ -1839,14 +1839,14 @@ static const char * const rt5665_dac3_src[] = {
"IF1 DAC2", "IF2_1 DAC", "IF2_2 DAC", "IF3 DAC", "STO2 ADC MIX"
};
-static const SOC_ENUM_SINGLE_DECL(
+static SOC_ENUM_SI
[PATCH] input: cros_ec_keyb: remove extraneous 'const'
gcc-7 warns about 'const SIMPLE_DEV_PM_OPS', as that macro already constains
a 'const' keyword:
drivers/input/keyboard/cros_ec_keyb.c:663:14: error: duplicate 'const'
declaration specifier [-Werror=duplicate-decl-specifier]
static const SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);
This removes the extra one.
Fixes: 6af6dc2d2aa6 ("input: Add ChromeOS EC keyboard driver")
Signed-off-by: Arnd Bergmann
---
drivers/input/keyboard/cros_ec_keyb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index c7a8120b13c0..79eb29550c34 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -660,7 +660,7 @@ static const struct of_device_id cros_ec_keyb_of_match[] = {
MODULE_DEVICE_TABLE(of, cros_ec_keyb_of_match);
#endif
-static const SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);
+static SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);
static struct platform_driver cros_ec_keyb_driver = {
.probe = cros_ec_keyb_probe,
--
2.9.0
[PATCH] ARM: remove duplicate 'const' annotations'
gcc-7 warns about some declarations that are more 'const' than necessary:
arch/arm/mach-at91/pm.c:338:34: error: duplicate 'const' declaration specifier
[-Werror=duplicate-decl-specifier]
static const struct of_device_id const ramc_ids[] __initconst = {
arch/arm/mach-bcm/bcm_kona_smc.c:36:34: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const struct of_device_id const bcm_kona_smc_ids[] __initconst = {
arch/arm/mach-spear/time.c:207:34: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const struct of_device_id const timer_of_match[] __initconst = {
arch/arm/mach-omap2/prm_common.c:714:34: error: duplicate 'const' declaration
specifier [-Werror=duplicate-decl-specifier]
static const struct of_device_id const omap_prcm_dt_match_table[] __initconst
= {
arch/arm/mach-omap2/vc.c:562:35: error: duplicate 'const' declaration specifier
[-Werror=duplicate-decl-specifier]
static const struct i2c_init_data const omap4_i2c_timing_data[] __initconst = {
The ones in arch/arm were apparently all introduced accidentally by one
commit that correctly marked a lot of variables as __initconst.
Cc: Nicolas Pitre
Fixes: 19c233b79d1a ("ARM: appropriate __init annotation for const data")
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-at91/pm.c | 2 +-
arch/arm/mach-bcm/bcm_kona_smc.c | 2 +-
arch/arm/mach-cns3xxx/core.c | 2 +-
arch/arm/mach-omap2/prm_common.c | 2 +-
arch/arm/mach-omap2/vc.c | 2 +-
arch/arm/mach-spear/time.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 2cd27c830ab6..283e79ab587d 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -335,7 +335,7 @@ static const struct ramc_info ramc_infos[] __initconst = {
{ .idle = sama5d3_ddr_standby, .memctrl = AT91_MEMCTRL_DDRSDR},
};
-static const struct of_device_id const ramc_ids[] __initconst = {
+static const struct of_device_id ramc_ids[] __initconst = {
{ .compatible = "atmel,at91rm9200-sdramc", .data = &ramc_infos[0] },
{ .compatible = "atmel,at91sam9260-sdramc", .data = &ramc_infos[1] },
{ .compatible = "atmel,at91sam9g45-ddramc", .data = &ramc_infos[2] },
diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
index 5157faa502eb..3937bd5d452f 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.c
+++ b/arch/arm/mach-bcm/bcm_kona_smc.c
@@ -33,7 +33,7 @@ struct bcm_kona_smc_data {
unsigned result;
};
-static const struct of_device_id const bcm_kona_smc_ids[] __initconst = {
+static const struct of_device_id bcm_kona_smc_ids[] __initconst = {
{.compatible = "brcm,kona-smc"},
{.compatible = "bcm,kona-smc"}, /* deprecated name */
{},
diff --git a/arch/arm/mach-cns3xxx/core.c b/arch/arm/mach-cns3xxx/core.c
index 03da3813f1ab..7d5a44a06648 100644
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -346,7 +346,7 @@ static struct usb_ohci_pdata cns3xxx_usb_ohci_pdata = {
.power_off = csn3xxx_usb_power_off,
};
-static const struct of_dev_auxdata const cns3xxx_auxdata[] __initconst = {
+static const struct of_dev_auxdata cns3xxx_auxdata[] __initconst = {
{ "intel,usb-ehci", CNS3XXX_USB_BASE, "ehci-platform",
&cns3xxx_usb_ehci_pdata },
{ "intel,usb-ohci", CNS3XXX_USB_OHCI_BASE, "ohci-platform",
&cns3xxx_usb_ohci_pdata },
{ "cavium,cns3420-ahci", CNS3XXX_SATA2_BASE, "ahci", NULL },
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 2b138b65129a..dc11841ca334 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -711,7 +711,7 @@ static struct omap_prcm_init_data scrm_data __initdata = {
};
#endif
-static const struct of_device_id const omap_prcm_dt_match_table[] __initconst
= {
+static const struct of_device_id omap_prcm_dt_match_table[] __initconst = {
#ifdef CONFIG_SOC_AM33XX
{ .compatible = "ti,am3-prcm", .data = &am3_prm_data },
#endif
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 2028167fff31..d76b1e5eb8ba 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -559,7 +559,7 @@ struct i2c_init_data {
u8 hsscll_12;
};
-static const struct i2c_init_data const omap4_i2c_timing_data[] __initconst = {
+static const struct i2c_init_data omap4_i2c_timing_data[] __initconst = {
{
.load = 50,
.loadbits = 0x3,
diff --git a/arch/arm/mach-spear/time.c b/arch/arm/mach-spear/time.c
index 4878ba90026d..289e036c9c30 100644
--- a/arch/arm/mach-spear/time.c
+++ b/arch/arm/mach-spear/time.c
@@ -204,7 +204,7 @@ static void __init spear_clockevent_init(int irq)
setup_irq(irq, &spear_timer_irq);
}
-static const struct of_device_id const timer_of_match[] __initconst = {
+static const struct of_device_id timer_of_match[] __initconst = {
[PATCH] wlcore: fix 64K page support
In the stable linux-3.16 branch, I ran into a warning in the wlcore driver: drivers/net/wireless/ti/wlcore/spi.c: In function 'wl12xx_spi_raw_write': drivers/net/wireless/ti/wlcore/spi.c:315:1: error: the frame size of 12848 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Newer kernels no longer show the warning, but the bug is still there, as the allocation is based on the CPU page size rather than the actual capabilities of the hardware. This replaces the PAGE_SIZE macro with the SZ_4K macro, i.e. 4096 bytes per buffer. Cc: sta...@vger.kernel.org Signed-off-by: Arnd Bergmann --- drivers/net/wireless/ti/wlcore/spi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ti/wlcore/spi.c b/drivers/net/wireless/ti/wlcore/spi.c index f949ad2bd898..fa3547e06424 100644 --- a/drivers/net/wireless/ti/wlcore/spi.c +++ b/drivers/net/wireless/ti/wlcore/spi.c @@ -70,10 +70,10 @@ #define WSPI_MAX_CHUNK_SIZE4092 /* - * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to - * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx + * wl18xx driver aggregation buffer size is (13 * 4K) compared to + * (4 * 4K) for wl12xx, so use the larger buffer needed for wl18xx */ -#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE) +#define SPI_AGGR_BUFFER_SIZE (13 * SZ_4K) /* Maximum number of SPI write chunks */ #define WSPI_MAX_NUM_OF_CHUNKS \ -- 2.9.0
[PATCH 0/2] alpha-module: Adjustments for module_frob_arch_sections()
From: Markus Elfring Date: Thu, 11 May 2017 13:11:23 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Improve a size determination Delete an error message for a failed memory allocation arch/alpha/kernel/module.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) -- 2.12.3
[PATCH 1/4] crypto: handle EBUSY due to backlog correctly
public_key_verify_signature() was passing the CRYPTO_TFM_REQ_MAY_BACKLOG
flag to akcipher_request_set_callback() but was not handling correctly
the case where a -EBUSY error could be returned from the call to
crypto_akcipher_verify() if backlog was used, possibly casuing
data corruption due to use-after-free of buffers.
Resolve this by handling -EBUSY correctly.
Signed-off-by: Gilad Ben-Yossef
CC: sta...@vger.kernel.org
---
crypto/asymmetric_keys/public_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/public_key.c
b/crypto/asymmetric_keys/public_key.c
index d3a989e..3cd6e12 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -141,7 +141,7 @@ int public_key_verify_signature(const struct public_key
*pkey,
* signature and returns that to us.
*/
ret = crypto_akcipher_verify(req);
- if (ret == -EINPROGRESS) {
+ if ((ret == -EINPROGRESS) || (ret == -EBUSY)) {
wait_for_completion(&compl.completion);
ret = compl.err;
}
--
2.1.4
[PATCH 4/4] crypto: Documentation: fix none signal safe sample
The sample code was showing use of wait_for_completion_interruptible()
for waiting for an async. crypto op to finish. However, if a signal
arrived it would free the buffers used even while crypto HW might
still DMA from/into the buffers.
Resolve this by using wait_for_completion() instead.
Reported-by: Eric Biggers
Signed-off-by: Gilad Ben-Yossef
---
Documentation/crypto/api-samples.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/crypto/api-samples.rst
b/Documentation/crypto/api-samples.rst
index d021fd9..944f08b 100644
--- a/Documentation/crypto/api-samples.rst
+++ b/Documentation/crypto/api-samples.rst
@@ -48,7 +48,7 @@ Code Example For Symmetric Key Cipher Operation
break;
case -EINPROGRESS:
case -EBUSY:
-rc = wait_for_completion_interruptible(
+rc = wait_for_completion(
&sk->result.completion);
if (!rc && !sk->result.err) {
reinit_completion(&sk->result.completion);
--
2.1.4
[PATCH 3/4] crypto: gcm wait for crypto op not signal safe
crypto_gcm_setkey() was using wait_for_completion_interruptible() to
wait for completion of async crypto op but if a signal occurs it
may return before DMA ops of HW crypto provider finish, thus
corrupting the data buffer that is kfree'ed in this case.
Resolve this by using wait_for_completion() instead.
Reported-by: Eric Biggers
Signed-off-by: Gilad Ben-Yossef
CC: sta...@vger.kernel.org
---
crypto/drbg.c | 4 ++--
crypto/gcm.c | 6 ++
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index fa9054d..cdb27ac 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1767,8 +1767,8 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
break;
case -EINPROGRESS:
case -EBUSY:
- ret = wait_for_completion(&drbg->ctr_completion);
- if (!ret && !drbg->ctr_async_err) {
+ wait_for_completion(&drbg->ctr_completion);
+ if (!drbg->ctr_async_err) {
reinit_completion(&drbg->ctr_completion);
break;
}
diff --git a/crypto/gcm.c b/crypto/gcm.c
index b7ad808..3841b5e 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -152,10 +152,8 @@ static int crypto_gcm_setkey(struct crypto_aead *aead,
const u8 *key,
err = crypto_skcipher_encrypt(&data->req);
if (err == -EINPROGRESS || err == -EBUSY) {
- err = wait_for_completion_interruptible(
- &data->result.completion);
- if (!err)
- err = data->result.err;
+ wait_for_completion(&data->result.completion);
+ err = data->result.err;
}
if (err)
--
2.1.4
[PATCH 2/4] crypto: drbg wait for crypto op not signal safe
drbg_kcapi_sym_ctr() was using wait_for_completion_interruptible() to
wait for completion of async crypto op but if a signal occurs it
may return before DMA ops of HW crypto provider finish, thus
corrupting the output buffer.
Resolve this by using wait_for_completion() instead.
Reported-by: Eric Biggers
Signed-off-by: Gilad Ben-Yossef
CC: sta...@vger.kernel.org
---
crypto/drbg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index fa749f4..fa9054d 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1767,8 +1767,7 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
break;
case -EINPROGRESS:
case -EBUSY:
- ret = wait_for_completion_interruptible(
- &drbg->ctr_completion);
+ ret = wait_for_completion(&drbg->ctr_completion);
if (!ret && !drbg->ctr_async_err) {
reinit_completion(&drbg->ctr_completion);
break;
--
2.1.4
[PATCH 1/2] alpha-module: Improve a size determination in module_frob_arch_sections()
From: Markus Elfring
Date: Thu, 11 May 2017 12:54:29 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring
---
arch/alpha/kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/alpha/kernel/module.c b/arch/alpha/kernel/module.c
index 936bc8f89a67..387d9c500e48 100644
--- a/arch/alpha/kernel/module.c
+++ b/arch/alpha/kernel/module.c
@@ -105,5 +105,5 @@ module_frob_arch_sections(Elf64_Ehdr *hdr, Elf64_Shdr
*sechdrs,
}
nsyms = symtab->sh_size / sizeof(Elf64_Sym);
- chains = kcalloc(nsyms, sizeof(struct got_entry), GFP_KERNEL);
+ chains = kcalloc(nsyms, sizeof(*chains), GFP_KERNEL);
if (!chains) {
--
2.12.3
[PATCH 0/4] crypto: async crypto op fixes
This patch set fixes various usage and documentation errors in waiting for async crypto op to complete which can result in data corruption. Note: these were discovered in the process of working on a patch set that replaces these call sites and more with a generic implementation that will prevent these problems going forward. These are just the fix ups for current code. Signed-off-by: Gilad Ben-Yossef CC: sta...@vger.kernel.org CC: Eric Biggers Gilad Ben-Yossef (4): crypto: handle EBUSY due to backlog correctly crypto: drbg wait for crypto op not signal safe crypto: gcm wait for crypto op not signal safe crypto: Documentation: fix none signal safe sample Documentation/crypto/api-samples.rst | 2 +- crypto/asymmetric_keys/public_key.c | 2 +- crypto/drbg.c| 5 ++--- crypto/gcm.c | 6 ++ 4 files changed, 6 insertions(+), 9 deletions(-) -- 2.1.4
[PATCH 2/2] alpha-module: Delete an error message for a failed memory allocation in module_frob_arch_sections()
From: Markus Elfring
Date: Thu, 11 May 2017 13:00:34 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
---
arch/alpha/kernel/module.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/alpha/kernel/module.c b/arch/alpha/kernel/module.c
index 387d9c500e48..211e62e9a0af 100644
--- a/arch/alpha/kernel/module.c
+++ b/arch/alpha/kernel/module.c
@@ -109,9 +109,5 @@ module_frob_arch_sections(Elf64_Ehdr *hdr, Elf64_Shdr
*sechdrs,
- if (!chains) {
- printk(KERN_ERR
- "module %s: no memory for symbol chain buffer\n",
- me->name);
+ if (!chains)
return -ENOMEM;
- }
got->sh_size = 0;
got->sh_addralign = 8;
--
2.12.3
[PATCH v2] xen-netfront: avoid crashing on resume after a failure in talk_to_netback()
Unavoidable crashes in netfront_resume() and netback_changed() after a previous fail in talk_to_netback() (e.g. when we fail to read MAC from xenstore) were discovered. The failure path in talk_to_netback() does unregister/free for netdev but we don't reset drvdata and we try accessing it after resume. Fix the bug by removing the whole xen device completely with device_unregister(), this guarantees we won't have any calls into netfront after a failure. Signed-off-by: Vitaly Kuznetsov --- Changes since v1: instead of cleaning drvdata and checking for it in netfront_resume() and netback_changed() remove the device completely with device_unregister() [David Miller] --- drivers/net/xen-netfront.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 6ffc482..7b61adb 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -1934,8 +1934,7 @@ static int talk_to_netback(struct xenbus_device *dev, xennet_disconnect_backend(info); xennet_destroy_queues(info); out: - unregister_netdev(info->netdev); - xennet_free_netdev(info->netdev); + device_unregister(&dev->dev); return err; } -- 2.9.3
Re: [PATCH] ARM: remove duplicate 'const' annotations'
On 11/05/2017 at 13:50:16 +0200, Arnd Bergmann wrote:
> gcc-7 warns about some declarations that are more 'const' than necessary:
>
> arch/arm/mach-at91/pm.c:338:34: error: duplicate 'const' declaration
> specifier [-Werror=duplicate-decl-specifier]
> static const struct of_device_id const ramc_ids[] __initconst = {
> arch/arm/mach-bcm/bcm_kona_smc.c:36:34: error: duplicate 'const' declaration
> specifier [-Werror=duplicate-decl-specifier]
> static const struct of_device_id const bcm_kona_smc_ids[] __initconst = {
> arch/arm/mach-spear/time.c:207:34: error: duplicate 'const' declaration
> specifier [-Werror=duplicate-decl-specifier]
> static const struct of_device_id const timer_of_match[] __initconst = {
> arch/arm/mach-omap2/prm_common.c:714:34: error: duplicate 'const' declaration
> specifier [-Werror=duplicate-decl-specifier]
> static const struct of_device_id const omap_prcm_dt_match_table[]
> __initconst = {
> arch/arm/mach-omap2/vc.c:562:35: error: duplicate 'const' declaration
> specifier [-Werror=duplicate-decl-specifier]
> static const struct i2c_init_data const omap4_i2c_timing_data[] __initconst
> = {
>
> The ones in arch/arm were apparently all introduced accidentally by one
> commit that correctly marked a lot of variables as __initconst.
>
> Cc: Nicolas Pitre
> Fixes: 19c233b79d1a ("ARM: appropriate __init annotation for const data")
> Signed-off-by: Arnd Bergmann
Acked-by: Alexandre Belloni
> ---
> arch/arm/mach-at91/pm.c | 2 +-
> arch/arm/mach-bcm/bcm_kona_smc.c | 2 +-
> arch/arm/mach-cns3xxx/core.c | 2 +-
> arch/arm/mach-omap2/prm_common.c | 2 +-
> arch/arm/mach-omap2/vc.c | 2 +-
> arch/arm/mach-spear/time.c | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index 2cd27c830ab6..283e79ab587d 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -335,7 +335,7 @@ static const struct ramc_info ramc_infos[] __initconst = {
> { .idle = sama5d3_ddr_standby, .memctrl = AT91_MEMCTRL_DDRSDR},
> };
>
> -static const struct of_device_id const ramc_ids[] __initconst = {
> +static const struct of_device_id ramc_ids[] __initconst = {
> { .compatible = "atmel,at91rm9200-sdramc", .data = &ramc_infos[0] },
> { .compatible = "atmel,at91sam9260-sdramc", .data = &ramc_infos[1] },
> { .compatible = "atmel,at91sam9g45-ddramc", .data = &ramc_infos[2] },
> diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c
> b/arch/arm/mach-bcm/bcm_kona_smc.c
> index 5157faa502eb..3937bd5d452f 100644
> --- a/arch/arm/mach-bcm/bcm_kona_smc.c
> +++ b/arch/arm/mach-bcm/bcm_kona_smc.c
> @@ -33,7 +33,7 @@ struct bcm_kona_smc_data {
> unsigned result;
> };
>
> -static const struct of_device_id const bcm_kona_smc_ids[] __initconst = {
> +static const struct of_device_id bcm_kona_smc_ids[] __initconst = {
> {.compatible = "brcm,kona-smc"},
> {.compatible = "bcm,kona-smc"}, /* deprecated name */
> {},
> diff --git a/arch/arm/mach-cns3xxx/core.c b/arch/arm/mach-cns3xxx/core.c
> index 03da3813f1ab..7d5a44a06648 100644
> --- a/arch/arm/mach-cns3xxx/core.c
> +++ b/arch/arm/mach-cns3xxx/core.c
> @@ -346,7 +346,7 @@ static struct usb_ohci_pdata cns3xxx_usb_ohci_pdata = {
> .power_off = csn3xxx_usb_power_off,
> };
>
> -static const struct of_dev_auxdata const cns3xxx_auxdata[] __initconst = {
> +static const struct of_dev_auxdata cns3xxx_auxdata[] __initconst = {
> { "intel,usb-ehci", CNS3XXX_USB_BASE, "ehci-platform",
> &cns3xxx_usb_ehci_pdata },
> { "intel,usb-ohci", CNS3XXX_USB_OHCI_BASE, "ohci-platform",
> &cns3xxx_usb_ohci_pdata },
> { "cavium,cns3420-ahci", CNS3XXX_SATA2_BASE, "ahci", NULL },
> diff --git a/arch/arm/mach-omap2/prm_common.c
> b/arch/arm/mach-omap2/prm_common.c
> index 2b138b65129a..dc11841ca334 100644
> --- a/arch/arm/mach-omap2/prm_common.c
> +++ b/arch/arm/mach-omap2/prm_common.c
> @@ -711,7 +711,7 @@ static struct omap_prcm_init_data scrm_data __initdata = {
> };
> #endif
>
> -static const struct of_device_id const omap_prcm_dt_match_table[]
> __initconst = {
> +static const struct of_device_id omap_prcm_dt_match_table[] __initconst = {
> #ifdef CONFIG_SOC_AM33XX
> { .compatible = "ti,am3-prcm", .data = &am3_prm_data },
> #endif
> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
> index 2028167fff31..d76b1e5eb8ba 100644
> --- a/arch/arm/mach-omap2/vc.c
> +++ b/arch/arm/mach-omap2/vc.c
> @@ -559,7 +559,7 @@ struct i2c_init_data {
> u8 hsscll_12;
> };
>
> -static const struct i2c_init_data const omap4_i2c_timing_data[] __initconst
> = {
> +static const struct i2c_init_data omap4_i2c_timing_data[] __initconst = {
> {
> .load = 50,
> .loadbits = 0x3,
> diff --git a/arch/arm/mach-spear/time.c b/arch/arm/mach-spear/time.c
> index 4878ba90026d..289e036c9c30 100644
> --- a/arch/arm/mach-spear/time.c
> +++ b/arch/arm/mach-spe
[PATCH] KVM: x86: Fix potential preemption when get the current kvmclock timestamp
From: Wanpeng Li BUG: using __this_cpu_read() in preemptible [] code: qemu-system-x86/2809 caller is __this_cpu_preempt_check+0x13/0x20 CPU: 2 PID: 2809 Comm: qemu-system-x86 Not tainted 4.11.0+ #13 Call Trace: dump_stack+0x99/0xce check_preemption_disabled+0xf5/0x100 __this_cpu_preempt_check+0x13/0x20 get_kvmclock_ns+0x6f/0x110 [kvm] get_time_ref_counter+0x5d/0x80 [kvm] kvm_hv_process_stimers+0x2a1/0x8a0 [kvm] ? kvm_hv_process_stimers+0x2a1/0x8a0 [kvm] ? kvm_arch_vcpu_ioctl_run+0xac9/0x1ce0 [kvm] kvm_arch_vcpu_ioctl_run+0x5bf/0x1ce0 [kvm] kvm_vcpu_ioctl+0x384/0x7b0 [kvm] ? kvm_vcpu_ioctl+0x384/0x7b0 [kvm] ? __fget+0xf3/0x210 do_vfs_ioctl+0xa4/0x700 ? __fget+0x114/0x210 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x23/0xc2 RIP: 0033:0x7f9d164ed357 RSP: 002b:7f9d0f6768f8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: a64d53c3 RCX: 7f9d164ed357 RDX: RSI: ae80 RDI: 000d RBP: bb260856bf88 R08: 556b2a13eeb0 R09: R10: 7f9d08c8 R11: 0246 R12: R13: 7f9d1853d000 R14: R15: ae80 ? __this_cpu_preempt_check+0x13/0x20 This can be reproduced by run kvm-unit-tests/hyperv_stimer.flat w/ CONFIG_PREEMPT and CONFIG_DEBUG_PREEMPT enabled. Safe access to per-CPU data requires a couple of constraints, though: the thread working with the data cannot be preempted and it cannot be migrated while it manipulates per-CPU variables. If the thread is preempted, the thread that replaces it could try to work with the same variables; migration to another CPU could also cause confusion. However there is no preemption disable when reads host per-CPU tsc rate to calculate the current kvmclock timestamp. This patch fix it by holding pvclock_gtod_sync_lock lock when calculates pvclock's time scale in order to disable preemption for host per-CPU tsc rate read. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kvm/x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index b54125b..8008d56 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1772,11 +1772,11 @@ u64 get_kvmclock_ns(struct kvm *kvm) hv_clock.tsc_timestamp = ka->master_cycle_now; hv_clock.system_time = ka->master_kernel_ns + ka->kvmclock_offset; - spin_unlock(&ka->pvclock_gtod_sync_lock); kvm_get_time_scale(NSEC_PER_SEC, __this_cpu_read(cpu_tsc_khz) * 1000LL, &hv_clock.tsc_shift, &hv_clock.tsc_to_system_mul); + spin_unlock(&ka->pvclock_gtod_sync_lock); return __pvclock_read_cycles(&hv_clock, rdtsc()); } -- 2.7.4
Re: [PATCH] drm: mediatek: change the variable type of rdma threshold
Hi Bibby, [auto build test ERROR on v4.9-rc8] [cannot apply to drm/drm-next next-20170510] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Bibby-Hsieh/drm-mediatek-change-the-variable-type-of-rdma-threshold/20170510-114823 config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): >> ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/mediatek/mediatek-drm.ko] >> undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 05/16] uuid: add the v1 layout to uuid_t
On Thu, May 11, 2017 at 02:40:38PM +0300, Andy Shevchenko wrote: > On Wed, 2017-05-10 at 20:02 +0200, Christoph Hellwig wrote: > > Turn the content of uuid_t into a union and add the fields for the v1 > > interpretation to it. > > In the branch it has fix for UUID() wrt union change, but there missed > similar for GUID(). Actually UUID needed this because uuid_t has a unіon inside, GUID should not need it because it doesn't. > While here, can we indent \ to be the same as of the rest lines in > macro(s) ? Sure.
Re: [PATCH] KVM: x86: Fix potential preemption when get the current kvmclock timestamp
On 11/05/2017 14:00, Wanpeng Li wrote: > From: Wanpeng Li > > BUG: using __this_cpu_read() in preemptible [] code: > qemu-system-x86/2809 > caller is __this_cpu_preempt_check+0x13/0x20 > CPU: 2 PID: 2809 Comm: qemu-system-x86 Not tainted 4.11.0+ #13 > Call Trace: > dump_stack+0x99/0xce > check_preemption_disabled+0xf5/0x100 > __this_cpu_preempt_check+0x13/0x20 > get_kvmclock_ns+0x6f/0x110 [kvm] > get_time_ref_counter+0x5d/0x80 [kvm] > kvm_hv_process_stimers+0x2a1/0x8a0 [kvm] > ? kvm_hv_process_stimers+0x2a1/0x8a0 [kvm] > ? kvm_arch_vcpu_ioctl_run+0xac9/0x1ce0 [kvm] > kvm_arch_vcpu_ioctl_run+0x5bf/0x1ce0 [kvm] > kvm_vcpu_ioctl+0x384/0x7b0 [kvm] > ? kvm_vcpu_ioctl+0x384/0x7b0 [kvm] > ? __fget+0xf3/0x210 > do_vfs_ioctl+0xa4/0x700 > ? __fget+0x114/0x210 > SyS_ioctl+0x79/0x90 > entry_SYSCALL_64_fastpath+0x23/0xc2 > RIP: 0033:0x7f9d164ed357 > RSP: 002b:7f9d0f6768f8 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: a64d53c3 RCX: 7f9d164ed357 > RDX: RSI: ae80 RDI: 000d > RBP: bb260856bf88 R08: 556b2a13eeb0 R09: > R10: 7f9d08c8 R11: 0246 R12: > R13: 7f9d1853d000 R14: R15: ae80 > ? __this_cpu_preempt_check+0x13/0x20 > > This can be reproduced by run kvm-unit-tests/hyperv_stimer.flat w/ > CONFIG_PREEMPT and CONFIG_DEBUG_PREEMPT enabled. > > Safe access to per-CPU data requires a couple of constraints, though: the > thread working with the data cannot be preempted and it cannot be migrated > while it manipulates per-CPU variables. If the thread is preempted, the > thread that replaces it could try to work with the same variables; migration > to another CPU could also cause confusion. However there is no preemption > disable when reads host per-CPU tsc rate to calculate the current kvmclock > timestamp. > > This patch fix it by holding pvclock_gtod_sync_lock lock when calculates > pvclock's time scale in order to disable preemption for host per-CPU tsc > rate read. > > Cc: Paolo Bonzini > Cc: Radim Krčmář > Signed-off-by: Wanpeng Li > --- > arch/x86/kvm/x86.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index b54125b..8008d56 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -1772,11 +1772,11 @@ u64 get_kvmclock_ns(struct kvm *kvm) > > hv_clock.tsc_timestamp = ka->master_cycle_now; > hv_clock.system_time = ka->master_kernel_ns + ka->kvmclock_offset; > - spin_unlock(&ka->pvclock_gtod_sync_lock); > > kvm_get_time_scale(NSEC_PER_SEC, __this_cpu_read(cpu_tsc_khz) * 1000LL, > &hv_clock.tsc_shift, > &hv_clock.tsc_to_system_mul); > + spin_unlock(&ka->pvclock_gtod_sync_lock); > return __pvclock_read_cycles(&hv_clock, rdtsc()); > } > > This would not be enough for PREEMPT_RT. You need to use get_cpu/put_cpu (including __pvclock_read_cycles in the non-preemptable section). Thanks, Paolo
Re: [PATCH] wcn36xx: Close SMD channel on device removal
Bjorn Andersson writes: > On Wed 10 May 00:27 PDT 2017, Arend van Spriel wrote: > >> On 5/10/2017 1:03 AM, Bjorn Andersson wrote: >> >> > AFAICT this never worked, as it seems I did the rework in SMD while we >> > tried to figure out the dependency issues we had with moving to SMD. So >> > v4.9 through v4.11 has SMD support - with this bug. >> > >> > How do I proceed, do you want me to write up a fix for stable@? Do I >> > send that out as an ordinary patch? >> >> If the patch applies cleanly on branches linux-4.9.y through linux-4.11.y in >> the stable repository you can go for '--- Option 1 ---' as described in >> /Documentation/stable_kernel_rules.txt. >> > > It does not, before v4.12 it's a completely different function to call > to close the channel. > > But "Option 3" describes the situation, thanks for the reference. I'll > try to find the time to verify the patch on v4.11 and send it to > stable@. Great, thanks. This seems to be that serious that better to fix this also in older releases. -- Kalle Valo
[PATCH] Bluetooth: hci_nokia: select CONFIG_BT_HCIUART_H4
Like the other H4 variants, this only builds when the base
H4 support is enabled, otherwise we get a build error:
drivers/bluetooth/hci_nokia.c:624:33: error: array type has incomplete element
type 'struct h4_recv_pkt'
Fixes: 7bb318680e86 ("Bluetooth: add nokia driver")
Signed-off-by: Arnd Bergmann
---
drivers/bluetooth/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 40994d96d151..b2cf0ae6b62d 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -97,6 +97,7 @@ config BT_HCIUART_NOKIA
depends on BT_HCIUART
depends on BT_HCIUART_SERDEV
depends on PM
+ select BT_HCIUART_H4
help
Nokia H4+ is serial protocol for communication between Bluetooth
device and host. This protocol is required for Bluetooth devices
--
2.9.0
Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
Hi Arnd, I want to further explain what I have discussed in previous mail. On Thu, 2017-05-11 at 17:08 +0800, Ryder Lee wrote: > On Thu, 2017-05-11 at 09:17 +0200, Arnd Bergmann wrote: > > On Thu, May 11, 2017 at 4:44 AM, Ryder Lee wrote: > > > On Wed, 2017-05-10 at 12:01 +0200, Arnd Bergmann wrote: > > >> On Wed, May 10, 2017 at 11:31 AM, Ryder Lee > > >> wrote: > > >> > On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote: > > > > >> >> > +Required properties: > > >> >> > +- device_type: Must be "pci" > > >> >> > +- assigned-addresses: Address and size of the port configuration > > >> >> > registers > > >> >> > +- reg: Only the first four bytes are used to refer to the correct > > >> >> > bus number > > >> >> > + and device number. > > >> >> > +- #address-cells: Must be 3 > > >> >> > +- #size-cells: Must be 2 > > >> >> > +- #interrupt-cells: Must be 1 > > >> >> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping > > >> >> > properties > > >> >> > + Please refer to the standard PCI bus binding document for a more > > >> >> > detailed > > >> >> > + explanation. > > >> >> > > >> >> Child nodes do not normally have interrupt-map properties. Isn't this > > >> >> already covered by the interrupt-map in the parent? > > >> >> > > >> > > > >> > I have one Intel 4 port ethernet card(:00:01) and MTK WLAN card > > >> > (:00:02), probe message looks good to me. > > >> > > > >> > pci :00:01.0: fixup irq: got 224 > > >> > pci :00:01.0: assigning IRQ 224 > > >> > pci :00:02.0: fixup irq: got 225 > > >> > pci :00:02.0: assigning IRQ 225 > > >> > > > >> > pci :01:00.0: fixup irq: got 224 > > >> > pci :01:00.0: assigning IRQ 224 > > >> > pci :01:00.1: fixup irq: got 224 > > >> > pci :01:00.1: assigning IRQ 224 > > >> > pci :01:00.2: fixup irq: got 224 > > >> > pci :01:00.2: assigning IRQ 224 > > >> > pci :01:00.3: fixup irq: got 224 > > >> > pci :01:00.3: assigning IRQ 224 > > >> > > > >> > pci :02:00.0: fixup irq: got 225 > > >> > pci :02:00.0: assigning IRQ 225 > > >> > > > >> > > > >> > But child nodes without interrupt-map properties: > > >> > It seems incorrect. > > >> > > > >> > pci :00:01.0: fixup irq: got 224 > > >> > pci :00:01.0: assigning IRQ 224 > > >> > pci :00:02.0: fixup irq: got 225 > > >> > pci :00:02.0: assigning IRQ 225 > > >> > > > >> > pci :01:00.0: fixup irq: got 223 > > >> > pci :01:00.0: assigning IRQ 223 > > >> > > >> Not entirely sure what happens here, but I guess the problem > > >> is that the 'reg' portion of the parent interrupt-map refers to > > >> the port devices, not the devices attached the devices behind > > >> them. > > > > > > I agree with you. That's why I need additional interrupt-map properties > > > to resolve IRQ correctly for the devices behind root ports. > > > > > > Not sure whether other platforms have similar case like me here. > > > > I think it's just a bug in this specific chip where the HW designers > > wired the IRQs in a nonstandard way. > > > > However, you really should not need the interrupt-map properties > > in the child nodes, just change the address part in the parent > > interrupt-map. Specifically, the 'bus' portion of the device address > > in the interrupt-map would have to be nonzero to refer to > > child devices. > > This is what I modify for the parent node and remove interrupt-map > properties from child.. > > interrupt-map-mask = <0xff800 0 0 0>; > interrupt-map = <0x 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>, ><0x0800 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>, ><0x1000 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>, > >/* workaround here*/ ><0x1 0 0 0 &gic GIC_SPI 193 IRQ_TYPE_NONE>, ><0x2 0 0 0 &gic GIC_SPI 194 IRQ_TYPE_NONE>, ><0x3 0 0 0 &gic GIC_SPI 195 IRQ_TYPE_NONE>; > > It works well. But how could we handle the situation if root port0 > status = "disabled" ? I think we cannot assign child bus number > dynamically from binding. That is to say, we route it statically if port0 (or port1) is unavailable. The PCI child bus enumeration should look something like this: pci :00:01.0: fixup irq: got 224 pci :00:01.0: assigning IRQ 224 pci :00:02.0: fixup irq: got 225 pci :00:02.0: assigning IRQ 225 Go wrong here! IRQ 223/224 should be assigned to the devices behind port0 and port1. pci :01:00.0: fixup irq: got 223 pci :01:00.0: assigning IRQ 223 pci :02:00.0: fixup irq: got 224 pci :02:00.0: assigning IRQ 224 > > >> On a related note, I see that you still list > > >> > > >> > +- interrupts: Three interrupt outputs of the controller. Must contain > > >> > an > > >> > + entry for each entry in the interrupt-names property. > > >> > +- interrupt-names: Must include the following names > > >> > + - "pcie-int0" > > >> > + - "pcie-int1" > > >> > + - "pcie-int2" > > >> > > >> This seems to be an art
[PATCH] cpufreq: dbx500: add a Kconfig symbol
Moving the cooling code into the cpufreq driver caused a possible build failure
when the cpu_thermal helper code is a loadable module or disabled:
drivers/cpufreq/dbx500-cpufreq.o: In function `dbx500_cpufreq_ready':
dbx500-cpufreq.c:(.text.dbx500_cpufreq_ready+0x4): undefined reference to
`cpufreq_cooling_register'
This adds the same dependency that we have in other cpufreq drivers,
forcing the driver to be disabled when we can't possibly link it.
Fixes: 19678ffb9fd6 ("cpufreq: dbx500: Manage cooling device from cpufreq
driver")
Signed-off-by: Arnd Bergmann
---
drivers/cpufreq/Kconfig.arm | 9 +
drivers/cpufreq/Makefile| 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 74ed7e9a7f27..2011fec2d6ad 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -71,6 +71,15 @@ config ARM_HIGHBANK_CPUFREQ
If in doubt, say N.
+config ARM_DB8500_CPUFREQ
+ tristate "ST-Ericsson DB8500 cpufreq" if COMPILE_TEST && !ARCH_U8500
+ default ARCH_U8500
+ depends on HAS_IOMEM
+ depends on !CPU_THERMAL || THERMAL
+ help
+ This adds the CPUFreq driver for ST-Ericsson Ux500 (DB8500) SoC
+ series.
+
config ARM_IMX6Q_CPUFREQ
tristate "Freescale i.MX6 cpufreq support"
depends on ARCH_MXC
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index b7e78f063c4f..ab3a42cd29ef 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -53,7 +53,7 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) +=
arm_big_little_dt.o
obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ) += brcmstb-avs-cpufreq.o
obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
-obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
+obj-$(CONFIG_ARM_DB8500_CPUFREQ) += dbx500-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
--
2.9.0
Fwd: Re: [RFC 0/6] optimize ctx switch with rb-tree
Forwarded Message
Subject: Re: [RFC 0/6] optimize ctx switch with rb-tree
Date: Thu, 11 May 2017 14:53:48 +0300
From: Alexey Budankov
Organization: Intel Corp.
To: davi...@google.com
CC: alexey.budan...@linux.intel.com
On 02.05.2017 23:59, Budankov, Alexey wrote:
Subject: Re: [RFC 0/6] optimize ctx switch with rb-tree
On Wed, Apr 26, 2017 at 3:34 AM, Budankov, Alexey
wrote:
Hi David,
I would like to take over on the patches development relying on your help with
reviews.
Sounds good.
Hi,
Sorry for long reply due to Russian holidays joined with vacations.
So, I see that event_sched_out() function (4.11.0-rc6+) additionally to
disabling an active (PERF_EVENT_STATE_ACTIVE) event in HW also performs
updates of tstamp fields for inactive (PERF_EVENT_STATE_INACTIVE) events
assigned to "the other" cpus (different from the one that is executing
the function):
static void
event_sched_out(struct perf_event *event,
struct perf_cpu_context *cpuctx,
struct perf_event_context *ctx)
{
u64 tstamp = perf_event_time(event);
u64 delta;
WARN_ON_ONCE(event->ctx != ctx);
lockdep_assert_held(&ctx->lock);
/*
* An event which could not be activated because of
* filter mismatch still needs to have its timings
* maintained, otherwise bogus information is return
* via read() for time_enabled, time_running:
*/
-> if (event->state == PERF_EVENT_STATE_INACTIVE &&
-> !event_filter_match(event)) {
-> delta = tstamp - event->tstamp_stopped;
-> event->tstamp_running += delta;
-> event->tstamp_stopped = tstamp;
-> }
->
-> if (event->state != PERF_EVENT_STATE_ACTIVE)
-> return;
I suggest moving this updating work to the context of
perf_event_task_tick() callback. It goes per-cpu with 1ms interval by
default so the inactive events will get their tstamp fields updated
aside of this critical path:
event_sched_out()
group_sched_out()
ctx_sched_out()
perf_rotate_context()
perf_mux_hrtimer_handler()
This change will shorten performance critical processing to active
events only as the amount of the events is always HW-limited.
Could you provide me with the cumulative patch set to expedite the ramp up?
This RFC is my latest version. I did not have a good solution on how to solve
the problem of handling failure of PMUs that share contexts, and to
activate/inactivate them.
Some things to keep in mind when dealing with task-contexts are:
1. The number of PMUs is large and growing, iterating over all PMUs may be
expensive (see https://lkml.org/lkml/2017/1/18/859 ).
2. event_filter_match in this RFC is only used because I did not find a better ways to
filter out events with the rb-tree. It would be nice if we wouldn't have to check
event->cpu != -1 && event->cpu ==
smp_processor_id() and cgroup stuff for every event in task contexts.
Checking an event for cpu affinity will be avoided, at least for the
critical path mentioned above.
3. I used the inactive events list in this RFC as a cheaper alternative to
threading the rb-tree but it has the problem that events that are removed due to
conflict would be placed at the end of the list even if didn't run. I cannot
recall if that ever happens. > Using this list also causes problem (2.) maybe
threading the tree isa better alternative?
The simplest RB-tree key for the change being suggested could be like
{event->cpu, event->id} so events could be organized into per-cpu
sub-trees for fast search and enumeration. All software event could be
grouped under event->cpu == -1.
4. Making the key in task-events to be {PMU,CPU,last_time_scheduled} (as
opposed to {CPU,last_time_scheduled} in the RFC) may simplify sched in by
helping to iterate over all events in same PMU at once, simplifying the
activation/inactivation of the PMU and making it simple to move to the next PMU
on pmu::add errors. The problem with this approach is to find only the PMUs
with inactive events without traversing a list of all PMUs. Maybe a per-context
list of active PMUs may help (see 1.).
cpu-contexts are much simpler and I think work well with what the RFC does
(they are per-pmu already).
This thread has Peter and Mark's original discussion of the rb-tree
(https://patchwork.kernel.org/patch/9176121/).
Thanks,
David
What do you think?
Thanks,
Alexey
Re: future of sounds/oss
On Thu, 11 May 2017 12:36:47 +0200, Takashi Sakamoto wrote: > > Oops. I misunderstand to have discussion about stuffs in > 'sound/core/oss/*', because the compatibility layer also includes > abuses of set_fs() and I'm interested in it today... Yes, the stuff in sound/core/oss required an intensive surgery to get rid of set_fs(). But this resulted in a good cleanup of the duplicated copy/silence callbacks in the end. > For stuffs in 'sound/oss', we should certainly have care of points > which Iwai-san mentioned. If we get rid of it, we can also apply diet > to 'soundcore' module which gives 'sound' class but include some > helper functions just for Open Sound System drivers. Right, that's low-hanging fruits we can take once after confirming the removal of OSS drivers. The soundcore module can be removed and integrated into the ALSA OSS emulation stuff, for example. thanks, Takashi
[PATCH] misc: pci_endpoint_test: select CONFIG_CRC32
Without CRC32, we get this link error:
pci_endpoint_test.c:(.text+0x2509e): undefined reference to `crc32_le'
Fixes: 58c89c8aa0e8 ("misc: Add host side PCI driver for PCI test function
device")
Signed-off-by: Arnd Bergmann
---
drivers/misc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 2cba76e6fa3c..07bbd4cc1852 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -492,6 +492,7 @@ config ASPEED_LPC_CTRL
config PCI_ENDPOINT_TEST
depends on PCI
+ select CRC32
tristate "PCI Endpoint Test driver"
---help---
Enable this configuration option to enable the host side test driver
--
2.9.0
[PATCH] IB/IPoIB: Replace netdev_priv with ipoib_priv for ipoib_get_link_ksettings
From: Honggang Li
ipoib_dev_init accesses the private data for IPoIB net_device with
ipoib_priv. ipoib_get_link_ksettings should do as ipoib_dev_init.
Otherwise kernel panic.
[ 27.271938] IPv6: ADDRCONF(NETDEV_CHANGE): mlx5_ib0.8006: link becomes ready
[ 28.156790] BUG: unable to handle kernel NULL pointer dereference at
067c
[ 28.166309] IP: ib_query_port+0x30/0x180 [ib_core]
[ 28.172364] PGD 0
[ 28.172364] P4D 0
[ 28.175307]
[ 28.180595] Oops: [#1] SMP
[ 28.184802] Modules linked in: bridge 8021q garp mrp stp llc rpcrdma
ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt
target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs
ib_umad rdma_cm ib_cm iw_cm mlx5_ib ib_core intel_rapl sb_edac
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel ipmi_ssif
crypto_simd glue_helper cryptd iTCO_wdt ipmi_si iTCO_vendor_support wmi pcspkr
ipmi_devintf dcdbas ipmi_msghandler lpc_ich sg mei_me mei shpchp
acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc
ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper syscopyarea
sysfillrect sysimgblt fb_sys_fops ttm mlx5_core drm tg3 devlink ahci libahci
ptp libata
[ 28.270227] crc32c_intel i2c_core pps_core dm_mirror dm_region_hash dm_log
dm_mod
[ 28.279674] CPU: 0 PID: 1766 Comm: libvirtd Not tainted
4.11.0.56868a4.20170510+ #1
[ 28.289242] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.6.2
01/08/2016
[ 28.298628] task: 8b4777311680 task.stack: b9ab0f7ac000
[ 28.306282] RIP: 0010:ib_query_port+0x30/0x180 [ib_core]
[ 28.313249] RSP: 0018:b9ab0f7afbb0 EFLAGS: 00010246
[ 28.320128] RAX: RBX: RCX:
[ 28.329169] RDX: b9ab0f7afc00 RSI: RDI:
[ 28.338202] RBP: b9ab0f7afbf0 R08: R09:
[ 28.347246] R10: 1000 R11: R12:
[ 28.356284] R13: b9ab0f7afc00 R14: b9ab0f7afef0 R15: 8b377eae9b80
[ 28.365316] FS: 7f9aed612700() GS:8b377f80()
knlGS:
[ 28.375431] CS: 0010 DS: ES: CR0: 80050033
[ 28.383724] CR2: 067c CR3: 00202aa7c000 CR4: 001406f0
[ 28.393337] Call Trace:
[ 28.397594] ipoib_get_link_ksettings+0x66/0xe0 [ib_ipoib]
[ 28.405274] __ethtool_get_link_ksettings+0xa0/0x1c0
[ 28.412353] speed_show+0x74/0xa0
[ 28.417503] dev_attr_show+0x20/0x50
[ 28.422922] ? mutex_lock+0x12/0x40
[ 28.428179] sysfs_kf_seq_show+0xbf/0x1a0
[ 28.434002] kernfs_seq_show+0x21/0x30
[ 28.439470] seq_read+0x116/0x3b0
[ 28.45] ? do_filp_open+0xa5/0x100
[ 28.449774] kernfs_fop_read+0xff/0x180
[ 28.455220] __vfs_read+0x37/0x150
[ 28.460167] ? security_file_permission+0x9d/0xc0
[ 28.466560] vfs_read+0x8c/0x130
[ 28.471318] SyS_read+0x55/0xc0
[ 28.475950] do_syscall_64+0x67/0x150
[ 28.481163] entry_SYSCALL64_slow_path+0x25/0x25
[ 28.487425] RIP: 0033:0x7f9b1bf4a70d
[ 28.492522] RSP: 002b:7f9aed611a40 EFLAGS: 0293 ORIG_RAX:
[ 28.502097] RAX: ffda RBX: RCX: 7f9b1bf4a70d
[ 28.511178] RDX: 0401 RSI: 7f9ae8183650 RDI: 0017
[ 28.520261] RBP: 0401 R08: 0080 R09: 2001
[ 28.529322] R10: 006b R11: 0293 R12: 7f9ae8183650
[ 28.538368] R13: R14: 0017 R15: 2001
[ 28.547432] Code: 55 48 89 e5 41 55 49 89 d5 41 54 44 0f b6 e6 53 48 89 fb
48 83 e4 f0 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0 87
7c 06 00 00 01 75 2d 45 85 e4 0f 85 ca 00 00 00 b8 ea ff
[ 28.570861] RIP: ib_query_port+0x30/0x180 [ib_core] RSP: b9ab0f7afbb0
[ 28.579601] CR2: 067c
[ 28.584493] ---[ end trace 3549968a4bf0aa5d ]---
Fixes: 0d7e2d2166f6 ('IB/ipoib: add get_link_ksettings in ethtool')
Signed-off-by: Honggang Li
---
drivers/infiniband/ulp/ipoib/ipoib_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
b/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
index 874b243..7871379 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
@@ -178,7 +178,7 @@ static inline int ib_speed_enum_to_int(int speed)
static int ipoib_get_link_ksettings(struct net_device *netdev,
struct ethtool_link_ksettings *cmd)
{
- struct ipoib_dev_priv *priv = netdev_priv(netdev);
+ struct ipoib_dev_priv *priv = ipoib_priv(netdev);
struct ib_port_attr attr;
int ret, speed, width;
--
1.8.3.1
Re: [PATCH] KVM: x86: Fix potential preemption when get the current kvmclock timestamp
2017-05-11 20:10 GMT+08:00 Paolo Bonzini : > > > On 11/05/2017 14:00, Wanpeng Li wrote: >> From: Wanpeng Li >> >> BUG: using __this_cpu_read() in preemptible [] code: >> qemu-system-x86/2809 >> caller is __this_cpu_preempt_check+0x13/0x20 >> CPU: 2 PID: 2809 Comm: qemu-system-x86 Not tainted 4.11.0+ #13 >> Call Trace: >> dump_stack+0x99/0xce >> check_preemption_disabled+0xf5/0x100 >> __this_cpu_preempt_check+0x13/0x20 >> get_kvmclock_ns+0x6f/0x110 [kvm] >> get_time_ref_counter+0x5d/0x80 [kvm] >> kvm_hv_process_stimers+0x2a1/0x8a0 [kvm] >> ? kvm_hv_process_stimers+0x2a1/0x8a0 [kvm] >> ? kvm_arch_vcpu_ioctl_run+0xac9/0x1ce0 [kvm] >> kvm_arch_vcpu_ioctl_run+0x5bf/0x1ce0 [kvm] >> kvm_vcpu_ioctl+0x384/0x7b0 [kvm] >> ? kvm_vcpu_ioctl+0x384/0x7b0 [kvm] >> ? __fget+0xf3/0x210 >> do_vfs_ioctl+0xa4/0x700 >> ? __fget+0x114/0x210 >> SyS_ioctl+0x79/0x90 >> entry_SYSCALL_64_fastpath+0x23/0xc2 >> RIP: 0033:0x7f9d164ed357 >> RSP: 002b:7f9d0f6768f8 EFLAGS: 0246 ORIG_RAX: 0010 >> RAX: ffda RBX: a64d53c3 RCX: 7f9d164ed357 >> RDX: RSI: ae80 RDI: 000d >> RBP: bb260856bf88 R08: 556b2a13eeb0 R09: >> R10: 7f9d08c8 R11: 0246 R12: >> R13: 7f9d1853d000 R14: R15: ae80 >> ? __this_cpu_preempt_check+0x13/0x20 >> >> This can be reproduced by run kvm-unit-tests/hyperv_stimer.flat w/ >> CONFIG_PREEMPT and CONFIG_DEBUG_PREEMPT enabled. >> >> Safe access to per-CPU data requires a couple of constraints, though: the >> thread working with the data cannot be preempted and it cannot be migrated >> while it manipulates per-CPU variables. If the thread is preempted, the >> thread that replaces it could try to work with the same variables; migration >> to another CPU could also cause confusion. However there is no preemption >> disable when reads host per-CPU tsc rate to calculate the current kvmclock >> timestamp. >> >> This patch fix it by holding pvclock_gtod_sync_lock lock when calculates >> pvclock's time scale in order to disable preemption for host per-CPU tsc >> rate read. >> >> Cc: Paolo Bonzini >> Cc: Radim Krčmář >> Signed-off-by: Wanpeng Li >> --- >> arch/x86/kvm/x86.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index b54125b..8008d56 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -1772,11 +1772,11 @@ u64 get_kvmclock_ns(struct kvm *kvm) >> >> hv_clock.tsc_timestamp = ka->master_cycle_now; >> hv_clock.system_time = ka->master_kernel_ns + ka->kvmclock_offset; >> - spin_unlock(&ka->pvclock_gtod_sync_lock); >> >> kvm_get_time_scale(NSEC_PER_SEC, __this_cpu_read(cpu_tsc_khz) * 1000LL, >> &hv_clock.tsc_shift, >> &hv_clock.tsc_to_system_mul); >> + spin_unlock(&ka->pvclock_gtod_sync_lock); >> return __pvclock_read_cycles(&hv_clock, rdtsc()); >> } >> >> > > This would not be enough for PREEMPT_RT. You need to use > get_cpu/put_cpu (including __pvclock_read_cycles in the non-preemptable > section). Actually the splat is for __this_cpu_read(cpu_tsc_khz), so I just protect it. Regards, Wanpeng Li
[PATCH] qed: fix uninitialized data in aRFS intrastructure
The new code contains an incredibly elaborate way of setting a 64-bit
register, which went subtly wrong due to the wrong size in a memset():
ethernet/qlogic/qed/qed_init_fw_funcs.c: In function 'qed_set_rfs_mode_disable':
ethernet/qlogic/qed/qed_init_fw_funcs.c:993:3: error: '*((void *)&ramline+4)'
is used uninitialized in this function [-Werror=uninitialized]
This removes the silly loop and memset, and instead directly writes
the correct value to the register.
Fixes: d51e4af5c209 ("qed: aRFS infrastructure support")
Signed-off-by: Arnd Bergmann
---
.../net/ethernet/qlogic/qed/qed_init_fw_funcs.c| 48 +-
1 file changed, 11 insertions(+), 37 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_init_fw_funcs.c
b/drivers/net/ethernet/qlogic/qed/qed_init_fw_funcs.c
index 67200c5498ab..a7c2c147a738 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_init_fw_funcs.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_init_fw_funcs.c
@@ -966,45 +966,29 @@ void qed_set_geneve_enable(struct qed_hwfn *p_hwfn,
#define PARSER_ETH_CONN_CM_HDR (0x0)
#define CAM_LINE_SIZE sizeof(u32)
#define RAM_LINE_SIZE sizeof(u64)
-#define REG_SIZE sizeof(u32)
+#define CAM_REG(pf_id) (PRS_REG_GFT_CAM + CAM_LINE_SIZE * (pf_id))
+#define RAM_REG(pf_id) (PRS_REG_GFT_PROFILE_MASK_RAM + RAM_LINE_SIZE * (pf_id))
void qed_set_rfs_mode_disable(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt, u16 pf_id)
{
- union gft_cam_line_union camline;
- struct gft_ram_line ramline;
- u32 *p_ramline, i;
-
- p_ramline = (u32 *)&ramline;
-
/*stop using gft logic */
qed_wr(p_hwfn, p_ptt, PRS_REG_SEARCH_GFT, 0);
qed_wr(p_hwfn, p_ptt, PRS_REG_CM_HDR_GFT, 0x0);
- memset(&camline, 0, sizeof(union gft_cam_line_union));
- qed_wr(p_hwfn, p_ptt, PRS_REG_GFT_CAM + CAM_LINE_SIZE * pf_id,
- camline.cam_line_mapped.camline);
- memset(&ramline, 0, sizeof(union gft_cam_line_union));
-
- for (i = 0; i < RAM_LINE_SIZE / REG_SIZE; i++) {
- u32 hw_addr = PRS_REG_GFT_PROFILE_MASK_RAM;
-
- hw_addr += (RAM_LINE_SIZE * pf_id + i * REG_SIZE);
-
- qed_wr(p_hwfn, p_ptt, hw_addr, *(p_ramline + i));
- }
+ qed_wr(p_hwfn, p_ptt, CAM_REG(pf_id), 0);
+ qed_wr(p_hwfn, p_ptt, RAM_REG(pf_id), 0);
+ qed_wr(p_hwfn, p_ptt, RAM_REG(pf_id) + 4, 0);
}
void qed_set_rfs_mode_enable(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
u16 pf_id, bool tcp, bool udp,
bool ipv4, bool ipv6)
{
- u32 rfs_cm_hdr_event_id, *p_ramline;
+ u32 rfs_cm_hdr_event_id;
union gft_cam_line_union camline;
struct gft_ram_line ramline;
- int i;
rfs_cm_hdr_event_id = qed_rd(p_hwfn, p_ptt, PRS_REG_CM_HDR_GFT);
- p_ramline = (u32 *)&ramline;
if (!ipv6 && !ipv4)
DP_NOTICE(p_hwfn,
@@ -1060,8 +1044,7 @@ void qed_set_rfs_mode_enable(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt,
}
/* write characteristics to cam */
- qed_wr(p_hwfn, p_ptt, PRS_REG_GFT_CAM + CAM_LINE_SIZE * pf_id,
- camline.cam_line_mapped.camline);
+ qed_wr(p_hwfn, p_ptt, CAM_REG(pf_id), camline.cam_line_mapped.camline);
camline.cam_line_mapped.camline = qed_rd(p_hwfn, p_ptt,
PRS_REG_GFT_CAM +
CAM_LINE_SIZE * pf_id);
@@ -1074,19 +1057,10 @@ void qed_set_rfs_mode_enable(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt,
SET_FIELD(ramline.low32bits, GFT_RAM_LINE_SRC_PORT, 1);
SET_FIELD(ramline.low32bits, GFT_RAM_LINE_DST_PORT, 1);
- /* each iteration write to reg */
- for (i = 0; i < RAM_LINE_SIZE / REG_SIZE; i++)
- qed_wr(p_hwfn, p_ptt,
- PRS_REG_GFT_PROFILE_MASK_RAM + RAM_LINE_SIZE * pf_id +
- i * REG_SIZE, *(p_ramline + i));
+ qed_wr(p_hwfn, p_ptt, RAM_REG(pf_id), ramline.low32bits);
+ qed_wr(p_hwfn, p_ptt, RAM_REG(pf_id) + 4, ramline.high32bits);
/* set default profile so that no filter match will happen */
- ramline.low32bits = 0x;
- ramline.high32bits = 0x;
-
- for (i = 0; i < RAM_LINE_SIZE / REG_SIZE; i++)
- qed_wr(p_hwfn, p_ptt,
- PRS_REG_GFT_PROFILE_MASK_RAM + RAM_LINE_SIZE *
- PRS_GFT_CAM_LINES_NO_MATCH + i * REG_SIZE,
- *(p_ramline + i));
+ qed_wr(p_hwfn, p_ptt, RAM_REG(PRS_GFT_CAM_LINES_NO_MATCH), 0x);
+ qed_wr(p_hwfn, p_ptt, RAM_REG(PRS_GFT_CAM_LINES_NO_MATCH) + 4, 0x);
}
--
2.9.0
Re: [GIT PULL] Please pull NFS client fixes for 4.12
On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote: > On Thu 11-05-17 10:53:27, Nikolay Borisov wrote: > > > > > > On 10.05.2017 19:47, Trond Myklebust wrote: > > [...] > > > - Cleanup and removal of some memory failure paths now that > > > GFP_NOFS is guaranteed to never fail. > > > > What guarantees that? Since if this is the case then this can > > result in > > a lot of opportunities for cleanup across the whole kernel tree. > > After > > discussing with mhocko (cc'ed) it seems that in practice everything > > below COSTLY_ORDER which are not GFP_NORETRY will never fail. But > > this > > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees > > that > > this will stay like that in the future? > > In practice it is hard to change the semantic of small allocations > never > fail _practically_. But this is absolutely not guaranteed! They can > fail > e.g. when the allocation context is the oom victim. Removing error > paths > for allocation failures is just wrong. OK, this makes no fucking sense at all. Either allocations can fail or they can't. 1) If they can't fail, then we don't need the checks. 2) If they can fail, then we do need them, and this hand wringing in the MM community about GFP_* semantics and how we need to prevent failure is fucking pointless. So which is it? (1) or (2)? -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.mykleb...@primarydata.com
Re: [PATCH v1 3/3] crypto: cavium - Register the CNN55XX supported crypto algorithms.
Hi Stephan,
On Wednesday 10 May 2017 07:26 PM, Stephan Müller wrote:
> Am Mittwoch, 10. Mai 2017, 15:06:40 CEST schrieb Srikanth Jampala:
>
> Hi Srikanth,
>
> In general: you are using the ablkcipher API. I think it is on its way out
> and
> being replaced with skcipher.
>
> Maybe it makes sense to replace it here too. It could be as simple as s/
> ablkcipher/skcipher/g
>
Sure, I will do the changes accordingly.
As per my understanding, I see the following changes,
1. CRYPTO_ALG_TYPE_ABLKCIPHER changed to CRYPTO_ALG_TYPE_SKCIPHER
2. nitrox_ablkcipher_foo() changed to nitrox_skcipher_foo()
Please let me know, any other changes I have to consider?
>> +static inline int nitrox_ablkcipher_setkey(struct crypto_ablkcipher
>> *cipher,
>> + int aes_keylen, const u8 *key,
>> + unsigned int keylen)
>> +{
>> + struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
>> + struct nitrox_crypto_instance *inst = crypto_tfm_ctx(tfm);
>> + struct flexi_crypto_context *fctx;
>> + enum flexi_cipher cipher_type;
>> + const char *name;
>> +
>> + name = crypto_tfm_alg_name(tfm);
>> + cipher_type = flexi_cipher_type(name);
>> + if (cipher_type == CIPHER_INVALID) {
>> + pr_err("unsupported cipher: %s\n", name);
>> + return -EINVAL;
>> + }
>> +
>> + /* fill crypto context */
>> + fctx = inst->u.fctx;
>> + fctx->flags = 0;
>> + fctx->w0.cipher_type = cipher_type;
>> + fctx->w0.aes_keylen = aes_keylen;
>> + fctx->w0.iv_source = IV_FROM_DPTR;
>> + fctx->flags = cpu_to_be64(*(u64 *)&fctx->w0);
>> + /* copy the key to context */
>> + memcpy(fctx->crypto.u.key, key, keylen);
>
> Could you help me finding the location where this memory is zeroized upon
> release?
Currently, we are not zeroized the context in release.
We are doing it at the time of allocation.
+void *crypto_alloc_context(struct nitrox_device *ndev)
+{
+ struct ctx_hdr *ctx;
+ void *vaddr;
+ dma_addr_t dma;
+
+ vaddr = dma_pool_alloc(ndev->ctx_pool, (GFP_ATOMIC | __GFP_ZERO), &dma);
+ if (!vaddr)
+ return NULL;
+
+ /* fill meta data */
+ ctx = vaddr;
+ ctx->pool = ndev->ctx_pool;
+ ctx->dma = dma;
+ ctx->ctx_dma = dma + sizeof(struct ctx_hdr);
+
+ return ((u8 *)vaddr + sizeof(struct ctx_hdr));
+}
>> +
>> + return 0;
>> +}
Re: [stable-4.10: PATCH] xen: revert commits 72a9b186292 and da72ff5bfcb0
On Mon, May 08, 2017 at 07:12:13AM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more. As commit da72ff5bfcb0
> ("partially revert xen: Remove event channel notification through Xen
> PCI platform device") reverted already some parts of it revert this
> commit, too.
>
> It is still necessary for old Xen versions (< 4.0) and for being able
> to run the Linux kernel as dom0 in a nested Xen environment.
>
> This is a backport of upstream commit 84d582d236dc1f9085e741affc72e9ba061a67c2
Now applied, thanks.
greg k-h
Re: [stable-4.9: PATCH] xen: revert commit 72a9b186292
On Mon, May 08, 2017 at 07:11:56AM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more.
>
> It is still necessary for old Xen versions (< 4.0) and for being able
> to run the Linux kernel as dom0 in a nested Xen environment.
>
> This is a backport of upstream commit 84d582d236dc1f9085e741affc72e9ba061a67c2
Now applied, thanks.
greg k-h
Re: [stable-4.11: PATCH] xen: revert commits 72a9b186292 and da72ff5bfcb0
On Mon, May 08, 2017 at 08:12:47AM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more. As commit da72ff5bfcb0
> ("partially revert xen: Remove event channel notification through Xen
> PCI platform device") reverted already some parts of it revert this
> commit, too.
>
> It is still necessary for old Xen versions (< 4.0) and for being able
> to run the Linux kernel as dom0 in a nested Xen environment.
>
> This is a backport of upstream commit 84d582d236dc1f9085e741affc72e9ba061a67c2
Now applied, thanks.
greg k-h
Re: [PATCH v1 3/3] crypto: cavium - Register the CNN55XX supported crypto algorithms.
Am Donnerstag, 11. Mai 2017, 14:18:34 CEST schrieb srikanth jampala:
Hi srikanth,
> Hi Stephan,
>
> On Wednesday 10 May 2017 07:26 PM, Stephan Müller wrote:
> > Am Mittwoch, 10. Mai 2017, 15:06:40 CEST schrieb Srikanth Jampala:
> >
> > Hi Srikanth,
> >
> > In general: you are using the ablkcipher API. I think it is on its way out
> > and being replaced with skcipher.
> >
> > Maybe it makes sense to replace it here too. It could be as simple as s/
> > ablkcipher/skcipher/g
>
> Sure, I will do the changes accordingly.
> As per my understanding, I see the following changes,
> 1. CRYPTO_ALG_TYPE_ABLKCIPHER changed to CRYPTO_ALG_TYPE_SKCIPHER
> 2. nitrox_ablkcipher_foo() changed to nitrox_skcipher_foo()
>
> Please let me know, any other changes I have to consider?
What about all crypto_ablkcipher* function calls / structs? Also all
ablkcipher_request function calls/structs?
>
> >> +static inline int nitrox_ablkcipher_setkey(struct crypto_ablkcipher
> >> *cipher,
> >> + int aes_keylen, const u8 *key,
> >> + unsigned int keylen)
> >> +{
> >> + struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
> >> + struct nitrox_crypto_instance *inst = crypto_tfm_ctx(tfm);
> >> + struct flexi_crypto_context *fctx;
> >> + enum flexi_cipher cipher_type;
> >> + const char *name;
> >> +
> >> + name = crypto_tfm_alg_name(tfm);
> >> + cipher_type = flexi_cipher_type(name);
> >> + if (cipher_type == CIPHER_INVALID) {
> >> + pr_err("unsupported cipher: %s\n", name);
> >> + return -EINVAL;
> >> + }
> >> +
> >> + /* fill crypto context */
> >> + fctx = inst->u.fctx;
> >> + fctx->flags = 0;
> >> + fctx->w0.cipher_type = cipher_type;
> >> + fctx->w0.aes_keylen = aes_keylen;
> >> + fctx->w0.iv_source = IV_FROM_DPTR;
> >> + fctx->flags = cpu_to_be64(*(u64 *)&fctx->w0);
> >> + /* copy the key to context */
> >> + memcpy(fctx->crypto.u.key, key, keylen);
> >
> > Could you help me finding the location where this memory is zeroized upon
> > release?
>
> Currently, we are not zeroized the context in release.
> We are doing it at the time of allocation.
You store a key in a piece of heap memory. I guess you want to zeroize that
key memory before releasing?
Ciao
Stephan
[PATCH 1/2] of: remove extraneous 'const' in typedef
One change that was meant to address a sparse warning turned out
to cause hundreds of new gcc-7 warnings:
include/linux/of_irq.h:11:13: error: type qualifiers ignored on function return
type [-Werror=ignored-qualifiers]
After reverting the change, the gcc warnings are gone again, and I
can't reproduce the sparse warnings either.
Fixes: 17a70355ea57 ("of: fix sparse warnings in fdt, irq, reserved mem, and
resolver code")
Signed-off-by: Arnd Bergmann
---
include/linux/of_irq.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index ec6b11deb773..1e0deb8e8494 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -8,7 +8,7 @@
#include
#include
-typedef int const (*of_irq_init_cb_t)(struct device_node *, struct device_node
*);
+typedef int (*of_irq_init_cb_t)(struct device_node *, struct device_node *);
/*
* Workarounds only applied to 32bit powermac machines
--
2.9.0
[PATCH 2/2] of: reserved_mem: fix 'const' annotation
It's the pointer that is supposed to be const, not the return
type of the function.
drivers/of/of_reserved_mem.c: In function '__reserved_mem_init_node':
drivers/of/of_reserved_mem.c:200:7: error: type qualifiers ignored on function
return type [-Werror=ignored-qualifiers]
int const (*initfn)(struct reserved_mem *rmem) = i->data;
Fixes: 17a70355ea57 ("of: fix sparse warnings in fdt, irq, reserved mem, and
resolver code")
Signed-off-by: Arnd Bergmann
---
drivers/of/of_reserved_mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 4dec07ea510f..3f03ec004829 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -197,7 +197,7 @@ static int __init __reserved_mem_init_node(struct
reserved_mem *rmem)
const struct of_device_id *i;
for (i = __reservedmem_of_table; i < &__rmem_of_table_sentinel; i++) {
- int const (*initfn)(struct reserved_mem *rmem) = i->data;
+ int (* const initfn)(struct reserved_mem *rmem) = i->data;
const char *compat = i->compatible;
if (!of_flat_dt_is_compatible(rmem->fdt_node, compat))
--
2.9.0
Re: [PATCH] KVM: x86: Fix potential preemption when get the current kvmclock timestamp
On 11/05/2017 14:15, Wanpeng Li wrote: > 2017-05-11 20:10 GMT+08:00 Paolo Bonzini : >> >> >> On 11/05/2017 14:00, Wanpeng Li wrote: >>> From: Wanpeng Li >>> >>> BUG: using __this_cpu_read() in preemptible [] code: >>> qemu-system-x86/2809 >>> caller is __this_cpu_preempt_check+0x13/0x20 >>> CPU: 2 PID: 2809 Comm: qemu-system-x86 Not tainted 4.11.0+ #13 >>> Call Trace: >>> dump_stack+0x99/0xce >>> check_preemption_disabled+0xf5/0x100 >>> __this_cpu_preempt_check+0x13/0x20 >>> get_kvmclock_ns+0x6f/0x110 [kvm] >>> get_time_ref_counter+0x5d/0x80 [kvm] >>> kvm_hv_process_stimers+0x2a1/0x8a0 [kvm] >>> ? kvm_hv_process_stimers+0x2a1/0x8a0 [kvm] >>> ? kvm_arch_vcpu_ioctl_run+0xac9/0x1ce0 [kvm] >>> kvm_arch_vcpu_ioctl_run+0x5bf/0x1ce0 [kvm] >>> kvm_vcpu_ioctl+0x384/0x7b0 [kvm] >>> ? kvm_vcpu_ioctl+0x384/0x7b0 [kvm] >>> ? __fget+0xf3/0x210 >>> do_vfs_ioctl+0xa4/0x700 >>> ? __fget+0x114/0x210 >>> SyS_ioctl+0x79/0x90 >>> entry_SYSCALL_64_fastpath+0x23/0xc2 >>> RIP: 0033:0x7f9d164ed357 >>> RSP: 002b:7f9d0f6768f8 EFLAGS: 0246 ORIG_RAX: 0010 >>> RAX: ffda RBX: a64d53c3 RCX: 7f9d164ed357 >>> RDX: RSI: ae80 RDI: 000d >>> RBP: bb260856bf88 R08: 556b2a13eeb0 R09: >>> R10: 7f9d08c8 R11: 0246 R12: >>> R13: 7f9d1853d000 R14: R15: ae80 >>> ? __this_cpu_preempt_check+0x13/0x20 >>> >>> This can be reproduced by run kvm-unit-tests/hyperv_stimer.flat w/ >>> CONFIG_PREEMPT and CONFIG_DEBUG_PREEMPT enabled. >>> >>> Safe access to per-CPU data requires a couple of constraints, though: the >>> thread working with the data cannot be preempted and it cannot be migrated >>> while it manipulates per-CPU variables. If the thread is preempted, the >>> thread that replaces it could try to work with the same variables; migration >>> to another CPU could also cause confusion. However there is no preemption >>> disable when reads host per-CPU tsc rate to calculate the current kvmclock >>> timestamp. >>> >>> This patch fix it by holding pvclock_gtod_sync_lock lock when calculates >>> pvclock's time scale in order to disable preemption for host per-CPU tsc >>> rate read. >>> >>> Cc: Paolo Bonzini >>> Cc: Radim Krčmář >>> Signed-off-by: Wanpeng Li >>> --- >>> arch/x86/kvm/x86.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>> index b54125b..8008d56 100644 >>> --- a/arch/x86/kvm/x86.c >>> +++ b/arch/x86/kvm/x86.c >>> @@ -1772,11 +1772,11 @@ u64 get_kvmclock_ns(struct kvm *kvm) >>> >>> hv_clock.tsc_timestamp = ka->master_cycle_now; >>> hv_clock.system_time = ka->master_kernel_ns + ka->kvmclock_offset; >>> - spin_unlock(&ka->pvclock_gtod_sync_lock); >>> >>> kvm_get_time_scale(NSEC_PER_SEC, __this_cpu_read(cpu_tsc_khz) * >>> 1000LL, >>> &hv_clock.tsc_shift, >>> &hv_clock.tsc_to_system_mul); >>> + spin_unlock(&ka->pvclock_gtod_sync_lock); >>> return __pvclock_read_cycles(&hv_clock, rdtsc()); >>> } >>> >>> >> >> This would not be enough for PREEMPT_RT. You need to use >> get_cpu/put_cpu (including __pvclock_read_cycles in the non-preemptable >> section). > > Actually the splat is for __this_cpu_read(cpu_tsc_khz), so I just protect it. Yes, but spin_lock/spin_unlock would still be preemptable on PREEMPT_RT. Also, rdtsc() should really be on the same CPU as __this_cpu_read. We know it's not really really necessary because the master clock is active, but since we need a get_cpu/put_cpu pair, better be clean. Paolo
Re: [GIT PULL] Please pull NFS client fixes for 4.12
On Thu 11-05-17 12:16:37, Trond Myklebust wrote: > On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote: > > On Thu 11-05-17 10:53:27, Nikolay Borisov wrote: > > > > > > > > > On 10.05.2017 19:47, Trond Myklebust wrote: > > > > [...] > > > > - Cleanup and removal of some memory failure paths now that > > > > GFP_NOFS is guaranteed to never fail. > > > > > > What guarantees that? Since if this is the case then this can > > > result in > > > a lot of opportunities for cleanup across the whole kernel tree. > > > After > > > discussing with mhocko (cc'ed) it seems that in practice everything > > > below COSTLY_ORDER which are not GFP_NORETRY will never fail. But > > > this > > > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees > > > that > > > this will stay like that in the future? > > > > In practice it is hard to change the semantic of small allocations > > never > > fail _practically_. But this is absolutely not guaranteed! They can > > fail > > e.g. when the allocation context is the oom victim. Removing error > > paths > > for allocation failures is just wrong. > > OK, this makes no fucking sense at all. > > Either allocations can fail or they can't. > 1) If they can't fail, then we don't need the checks. > 2) If they can fail, then we do need them, and this hand wringing in > the MM community about GFP_* semantics and how we need to prevent > failure is fucking pointless. everything which is not __GFP_NOFAIL might fail. We try hard not to fail small allocations requests as much as we can in general but you _have_ to check for failures. There is simply no way to guarantee "never fail" semantic for all allocation requests. This has been like that basically since years. And even this try-to-be-nofailing for small allocations has been PITA for some corner cases. -- Michal Hocko SUSE Labs
Re: [PATCH] IB/IPoIB: Replace netdev_priv with ipoib_priv for ipoib_get_link_ksettings
On Thu, May 11, 2017 at 08:14:28PM +0800, Honggang LI wrote:
> From: Honggang Li
>
> ipoib_dev_init accesses the private data for IPoIB net_device with
> ipoib_priv. ipoib_get_link_ksettings should do as ipoib_dev_init.
> Otherwise kernel panic.
>
> [ 27.271938] IPv6: ADDRCONF(NETDEV_CHANGE): mlx5_ib0.8006: link becomes
> ready
> [ 28.156790] BUG: unable to handle kernel NULL pointer dereference at
> 067c
> [ 28.166309] IP: ib_query_port+0x30/0x180 [ib_core]
> [ 28.172364] PGD 0
> [ 28.172364] P4D 0
> [ 28.175307]
> [ 28.180595] Oops: [#1] SMP
> [ 28.184802] Modules linked in: bridge 8021q garp mrp stp llc rpcrdma
> ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt
> target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs
> ib_umad rdma_cm ib_cm iw_cm mlx5_ib ib_core intel_rapl sb_edac
> x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass
> crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel ipmi_ssif
> crypto_simd glue_helper cryptd iTCO_wdt ipmi_si iTCO_vendor_support wmi
> pcspkr ipmi_devintf dcdbas ipmi_msghandler lpc_ich sg mei_me mei shpchp
> acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc
> ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit drm_kms_helper
> syscopyarea sysfillrect sysimgblt fb_sys_fops ttm mlx5_core drm tg3 devlink
> ahci libahci ptp libata
> [ 28.270227] crc32c_intel i2c_core pps_core dm_mirror dm_region_hash
> dm_log dm_mod
> [ 28.279674] CPU: 0 PID: 1766 Comm: libvirtd Not tainted
> 4.11.0.56868a4.20170510+ #1
> [ 28.289242] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.6.2
> 01/08/2016
> [ 28.298628] task: 8b4777311680 task.stack: b9ab0f7ac000
> [ 28.306282] RIP: 0010:ib_query_port+0x30/0x180 [ib_core]
> [ 28.313249] RSP: 0018:b9ab0f7afbb0 EFLAGS: 00010246
> [ 28.320128] RAX: RBX: RCX:
>
> [ 28.329169] RDX: b9ab0f7afc00 RSI: RDI:
>
> [ 28.338202] RBP: b9ab0f7afbf0 R08: R09:
>
> [ 28.347246] R10: 1000 R11: R12:
>
> [ 28.356284] R13: b9ab0f7afc00 R14: b9ab0f7afef0 R15:
> 8b377eae9b80
> [ 28.365316] FS: 7f9aed612700() GS:8b377f80()
> knlGS:
> [ 28.375431] CS: 0010 DS: ES: CR0: 80050033
> [ 28.383724] CR2: 067c CR3: 00202aa7c000 CR4:
> 001406f0
> [ 28.393337] Call Trace:
> [ 28.397594] ipoib_get_link_ksettings+0x66/0xe0 [ib_ipoib]
> [ 28.405274] __ethtool_get_link_ksettings+0xa0/0x1c0
> [ 28.412353] speed_show+0x74/0xa0
> [ 28.417503] dev_attr_show+0x20/0x50
> [ 28.422922] ? mutex_lock+0x12/0x40
> [ 28.428179] sysfs_kf_seq_show+0xbf/0x1a0
> [ 28.434002] kernfs_seq_show+0x21/0x30
> [ 28.439470] seq_read+0x116/0x3b0
> [ 28.45] ? do_filp_open+0xa5/0x100
> [ 28.449774] kernfs_fop_read+0xff/0x180
> [ 28.455220] __vfs_read+0x37/0x150
> [ 28.460167] ? security_file_permission+0x9d/0xc0
> [ 28.466560] vfs_read+0x8c/0x130
> [ 28.471318] SyS_read+0x55/0xc0
> [ 28.475950] do_syscall_64+0x67/0x150
> [ 28.481163] entry_SYSCALL64_slow_path+0x25/0x25
> [ 28.487425] RIP: 0033:0x7f9b1bf4a70d
> [ 28.492522] RSP: 002b:7f9aed611a40 EFLAGS: 0293 ORIG_RAX:
>
> [ 28.502097] RAX: ffda RBX: RCX:
> 7f9b1bf4a70d
> [ 28.511178] RDX: 0401 RSI: 7f9ae8183650 RDI:
> 0017
> [ 28.520261] RBP: 0401 R08: 0080 R09:
> 2001
> [ 28.529322] R10: 006b R11: 0293 R12:
> 7f9ae8183650
> [ 28.538368] R13: R14: 0017 R15:
> 2001
> [ 28.547432] Code: 55 48 89 e5 41 55 49 89 d5 41 54 44 0f b6 e6 53 48 89 fb
> 48 83 e4 f0 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0
> 87 7c 06 00 00 01 75 2d 45 85 e4 0f 85 ca 00 00 00 b8 ea ff
> [ 28.570861] RIP: ib_query_port+0x30/0x180 [ib_core] RSP: b9ab0f7afbb0
> [ 28.579601] CR2: 067c
> [ 28.584493] ---[ end trace 3549968a4bf0aa5d ]---
>
> Fixes: 0d7e2d2166f6 ('IB/ipoib: add get_link_ksettings in ethtool')
>
> Signed-off-by: Honggang Li
> ---
> drivers/infiniband/ulp/ipoib/ipoib_ethtool.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
> b/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
> index 874b243..7871379 100644
> --- a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
> @@ -178,7 +178,7 @@ static inline int ib_speed_enum_to_int(int speed)
> static int ipoib_get_link_ksettings(struct net_device *netdev,
> struct ethtool_link_ksettings *cmd)
> {
> - struct ipoib_
[PATCH v4] sd: Ignore sync cache failures when not supported
From: Derek Basehore
Some external hard drives don't support the sync command even though the
hard drive has write cache enabled. In this case, upon suspend request,
sync cache failures are ignored if the error code in the sense header is
ILLEGAL_REQUEST. There's not much we can do for these drives, so we
shouldn't fail to suspend for this error case. The drive may stay
powered if that's the setup for the port it's plugged into.
Signed-off-by: Derek Basehore
Signed-off-by: Thierry Escande
---
v4 changes:
- Check sense header validity before checking the sense_key field
- Get rid of both goto statements (the one in the previous patch and the
one in the existing code)
v3 changes:
- Pass the sense_hdr structure to sd_sync_cache() instead of the
lonely sense_key field
v2 changes:
- Change sense_key type to u8 in sd_sync_cache()
drivers/scsi/sd.c | 40
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index fcfeddc..823ab8b 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1489,17 +1489,21 @@ static unsigned int sd_check_events(struct gendisk
*disk, unsigned int clearing)
return retval;
}
-static int sd_sync_cache(struct scsi_disk *sdkp)
+static int sd_sync_cache(struct scsi_disk *sdkp, struct scsi_sense_hdr *sshdr)
{
int retries, res;
struct scsi_device *sdp = sdkp->device;
const int timeout = sdp->request_queue->rq_timeout
* SD_FLUSH_TIMEOUT_MULTIPLIER;
- struct scsi_sense_hdr sshdr;
+ struct scsi_sense_hdr my_sshdr;
if (!scsi_device_online(sdp))
return -ENODEV;
+ /* caller might not be interested in sense, but we need it */
+ if (!sshdr)
+ sshdr = &my_sshdr;
+
for (retries = 3; retries > 0; --retries) {
unsigned char cmd[10] = { 0 };
@@ -1508,7 +1512,7 @@ static int sd_sync_cache(struct scsi_disk *sdkp)
* Leave the rest of the command zero to indicate
* flush everything.
*/
- res = scsi_execute(sdp, cmd, DMA_NONE, NULL, 0, NULL, &sshdr,
+ res = scsi_execute(sdp, cmd, DMA_NONE, NULL, 0, NULL, sshdr,
timeout, SD_MAX_RETRIES, 0, RQF_PM, NULL);
if (res == 0)
break;
@@ -1518,11 +1522,12 @@ static int sd_sync_cache(struct scsi_disk *sdkp)
sd_print_result(sdkp, "Synchronize Cache(10) failed", res);
if (driver_byte(res) & DRIVER_SENSE)
- sd_print_sense_hdr(sdkp, &sshdr);
+ sd_print_sense_hdr(sdkp, sshdr);
+
/* we need to evaluate the error return */
- if (scsi_sense_valid(&sshdr) &&
- (sshdr.asc == 0x3a || /* medium not present */
-sshdr.asc == 0x20))/* invalid command */
+ if (scsi_sense_valid(sshdr) &&
+ (sshdr->asc == 0x3a || /* medium not present */
+sshdr->asc == 0x20)) /* invalid command */
/* this is no error here */
return 0;
@@ -3323,7 +3328,7 @@ static void sd_shutdown(struct device *dev)
if (sdkp->WCE && sdkp->media_present) {
sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
- sd_sync_cache(sdkp);
+ sd_sync_cache(sdkp, NULL);
}
if (system_state != SYSTEM_RESTART && sdkp->device->manage_start_stop) {
@@ -3335,6 +3340,7 @@ static void sd_shutdown(struct device *dev)
static int sd_suspend_common(struct device *dev, bool ignore_stop_errors)
{
struct scsi_disk *sdkp = dev_get_drvdata(dev);
+ struct scsi_sense_hdr sshdr;
int ret = 0;
if (!sdkp) /* E.g.: runtime suspend following sd_remove() */
@@ -3342,12 +3348,23 @@ static int sd_suspend_common(struct device *dev, bool
ignore_stop_errors)
if (sdkp->WCE && sdkp->media_present) {
sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
- ret = sd_sync_cache(sdkp);
+ ret = sd_sync_cache(sdkp, &sshdr);
+
if (ret) {
/* ignore OFFLINE device */
if (ret == -ENODEV)
- ret = 0;
- goto done;
+ return 0;
+
+ if (!scsi_sense_valid(&sshdr) ||
+ sshdr.sense_key != ILLEGAL_REQUEST)
+ return ret;
+
+ /*
+* sshdr.sense_key == ILLEGAL_REQUEST means this drive
+* doesn't support sync. There's not much to do and
+* suspend shouldn't fail.
+*/
+ret = 0;
Re: [PATCH] IB/IPoIB: Replace netdev_priv with ipoib_priv for ipoib_get_link_ksettings
On Thu, May 11, 2017 at 03:31:10PM +0300, Yuval Shaia wrote:
> On Thu, May 11, 2017 at 08:14:28PM +0800, Honggang LI wrote:
> > From: Honggang Li
> >
> > ipoib_dev_init accesses the private data for IPoIB net_device with
> > ipoib_priv. ipoib_get_link_ksettings should do as ipoib_dev_init.
> > Otherwise kernel panic.
> >
> > [ 27.271938] IPv6: ADDRCONF(NETDEV_CHANGE): mlx5_ib0.8006: link becomes
> > ready
> > [ 28.156790] BUG: unable to handle kernel NULL pointer dereference at
> > 067c
> > [ 28.166309] IP: ib_query_port+0x30/0x180 [ib_core]
> > [ 28.172364] PGD 0
> > [ 28.172364] P4D 0
> > [ 28.175307]
> > [ 28.180595] Oops: [#1] SMP
> > [ 28.184802] Modules linked in: bridge 8021q garp mrp stp llc rpcrdma
> > ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt
> > target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm
> > ib_uverbs ib_umad rdma_cm ib_cm iw_cm mlx5_ib ib_core intel_rapl sb_edac
> > x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass
> > crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel
> > ipmi_ssif crypto_simd glue_helper cryptd iTCO_wdt ipmi_si
> > iTCO_vendor_support wmi pcspkr ipmi_devintf dcdbas ipmi_msghandler lpc_ich
> > sg mei_me mei shpchp acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace
> > sunrpc binfmt_misc ip_tables xfs libcrc32c sd_mod mgag200 i2c_algo_bit
> > drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm mlx5_core
> > drm tg3 devlink ahci libahci ptp libata
> > [ 28.270227] crc32c_intel i2c_core pps_core dm_mirror dm_region_hash
> > dm_log dm_mod
> > [ 28.279674] CPU: 0 PID: 1766 Comm: libvirtd Not tainted
> > 4.11.0.56868a4.20170510+ #1
> > [ 28.289242] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.6.2
> > 01/08/2016
> > [ 28.298628] task: 8b4777311680 task.stack: b9ab0f7ac000
> > [ 28.306282] RIP: 0010:ib_query_port+0x30/0x180 [ib_core]
> > [ 28.313249] RSP: 0018:b9ab0f7afbb0 EFLAGS: 00010246
> > [ 28.320128] RAX: RBX: RCX:
> >
> > [ 28.329169] RDX: b9ab0f7afc00 RSI: RDI:
> >
> > [ 28.338202] RBP: b9ab0f7afbf0 R08: R09:
> >
> > [ 28.347246] R10: 1000 R11: R12:
> >
> > [ 28.356284] R13: b9ab0f7afc00 R14: b9ab0f7afef0 R15:
> > 8b377eae9b80
> > [ 28.365316] FS: 7f9aed612700() GS:8b377f80()
> > knlGS:
> > [ 28.375431] CS: 0010 DS: ES: CR0: 80050033
> > [ 28.383724] CR2: 067c CR3: 00202aa7c000 CR4:
> > 001406f0
> > [ 28.393337] Call Trace:
> > [ 28.397594] ipoib_get_link_ksettings+0x66/0xe0 [ib_ipoib]
> > [ 28.405274] __ethtool_get_link_ksettings+0xa0/0x1c0
> > [ 28.412353] speed_show+0x74/0xa0
> > [ 28.417503] dev_attr_show+0x20/0x50
> > [ 28.422922] ? mutex_lock+0x12/0x40
> > [ 28.428179] sysfs_kf_seq_show+0xbf/0x1a0
> > [ 28.434002] kernfs_seq_show+0x21/0x30
> > [ 28.439470] seq_read+0x116/0x3b0
> > [ 28.45] ? do_filp_open+0xa5/0x100
> > [ 28.449774] kernfs_fop_read+0xff/0x180
> > [ 28.455220] __vfs_read+0x37/0x150
> > [ 28.460167] ? security_file_permission+0x9d/0xc0
> > [ 28.466560] vfs_read+0x8c/0x130
> > [ 28.471318] SyS_read+0x55/0xc0
> > [ 28.475950] do_syscall_64+0x67/0x150
> > [ 28.481163] entry_SYSCALL64_slow_path+0x25/0x25
> > [ 28.487425] RIP: 0033:0x7f9b1bf4a70d
> > [ 28.492522] RSP: 002b:7f9aed611a40 EFLAGS: 0293 ORIG_RAX:
> >
> > [ 28.502097] RAX: ffda RBX: RCX:
> > 7f9b1bf4a70d
> > [ 28.511178] RDX: 0401 RSI: 7f9ae8183650 RDI:
> > 0017
> > [ 28.520261] RBP: 0401 R08: 0080 R09:
> > 2001
> > [ 28.529322] R10: 006b R11: 0293 R12:
> > 7f9ae8183650
> > [ 28.538368] R13: R14: 0017 R15:
> > 2001
> > [ 28.547432] Code: 55 48 89 e5 41 55 49 89 d5 41 54 44 0f b6 e6 53 48 89
> > fb 48 83 e4 f0 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0
> > 87 7c 06 00 00 01 75 2d 45 85 e4 0f 85 ca 00 00 00 b8 ea ff
> > [ 28.570861] RIP: ib_query_port+0x30/0x180 [ib_core] RSP: b9ab0f7afbb0
> > [ 28.579601] CR2: 067c
> > [ 28.584493] ---[ end trace 3549968a4bf0aa5d ]---
> >
> > Fixes: 0d7e2d2166f6 ('IB/ipoib: add get_link_ksettings in ethtool')
> >
> > Signed-off-by: Honggang Li
> > ---
> > drivers/infiniband/ulp/ipoib/ipoib_ethtool.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
> > b/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
> > index 874b243..7871379 100644
> > --- a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
> > +++ b/drivers/infiniband/ulp/
Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code
Being somewhat late to the party I missed all the fun... On Wed, 10 May 2017, Josh Poimboeuf wrote: > On Wed, May 10, 2017 at 06:04:23PM +0200, Petr Mladek wrote: > > > IMHO, the point is that RCU must be aware when we call > > rcu_read_lock()/unlock(). > > > > My understanding is that rcu_irq_enter() tries to make RCU watching > > when it was not. Then rcu_is_watching() reports if we are on > > the safe side. > > > > But it is possible that I miss something. One question is if > > rcu_irq_enter()/exit() calls can be nested. > > > > I still need to think about it. > > The code looks ok to me now, except for a few minor issues: > > - The warning message should be more specific. > > - The documentation should probably mention the name of the specific RCU > function which shouldn't be patched. > > - The documentation might also mention that the warning could also be > triggered in early NMI or exception code, e.g. if there are any calls > to functions with fentry calls which have been patched. > > - The code comment should probably refer to the documentation, otherwise > nobody will ever read it ;-) Agreed. Petr, could you also improve the changelog a bit? Certain parts confuse me and I think that your changes to the documentation describe it better. I mean these two paragraphs: "Unfortunately, the ftrace handler might be called when the problematic patch has already been removed from ops->func stack. In this case, it is not able to read the immediate flag. It makes the check unreliable. We rather avoid it and report the problem even when the system stability is not affected. It would be possible to add some more complex logic to avoid warnings when RCU infrastructure is modified using immediate patches. But let's keep it simple until real life experience forces us to do the opposite." I'm still not sure if we know for 100 percent what we're doing :) Miroslav
Re: [PATCH v1 3/3] crypto: cavium - Register the CNN55XX supported crypto algorithms.
Hi Stephan,
On Thursday 11 May 2017 05:52 PM, Stephan Müller wrote:
> Am Donnerstag, 11. Mai 2017, 14:18:34 CEST schrieb srikanth jampala:
>
> Hi srikanth,
>
>> Hi Stephan,
>>
>> On Wednesday 10 May 2017 07:26 PM, Stephan Müller wrote:
>>> Am Mittwoch, 10. Mai 2017, 15:06:40 CEST schrieb Srikanth Jampala:
>>>
>>> Hi Srikanth,
>>>
>>> In general: you are using the ablkcipher API. I think it is on its way out
>>> and being replaced with skcipher.
>>>
>>> Maybe it makes sense to replace it here too. It could be as simple as s/
>>> ablkcipher/skcipher/g
>>
>> Sure, I will do the changes accordingly.
>> As per my understanding, I see the following changes,
>> 1. CRYPTO_ALG_TYPE_ABLKCIPHER changed to CRYPTO_ALG_TYPE_SKCIPHER
>> 2. nitrox_ablkcipher_foo() changed to nitrox_skcipher_foo()
>>
>> Please let me know, any other changes I have to consider?
>
> What about all crypto_ablkcipher* function calls / structs? Also all
> ablkcipher_request function calls/structs?
I will work on the changes suggested.
>>
+static inline int nitrox_ablkcipher_setkey(struct crypto_ablkcipher
*cipher,
+ int aes_keylen, const u8 *key,
+ unsigned int keylen)
+{
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
+ struct nitrox_crypto_instance *inst = crypto_tfm_ctx(tfm);
+ struct flexi_crypto_context *fctx;
+ enum flexi_cipher cipher_type;
+ const char *name;
+
+ name = crypto_tfm_alg_name(tfm);
+ cipher_type = flexi_cipher_type(name);
+ if (cipher_type == CIPHER_INVALID) {
+ pr_err("unsupported cipher: %s\n", name);
+ return -EINVAL;
+ }
+
+ /* fill crypto context */
+ fctx = inst->u.fctx;
+ fctx->flags = 0;
+ fctx->w0.cipher_type = cipher_type;
+ fctx->w0.aes_keylen = aes_keylen;
+ fctx->w0.iv_source = IV_FROM_DPTR;
+ fctx->flags = cpu_to_be64(*(u64 *)&fctx->w0);
+ /* copy the key to context */
+ memcpy(fctx->crypto.u.key, key, keylen);
>>>
>>> Could you help me finding the location where this memory is zeroized upon
>>> release?
>>
>> Currently, we are not zeroized the context in release.
>> We are doing it at the time of allocation.
>
> You store a key in a piece of heap memory. I guess you want to zeroize that
> key memory before releasing?
>
I will do the changes.
>
> Ciao
> Stephan
>
Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code
On Mon 2017-05-08 11:51:08, Josh Poimboeuf wrote:
> On Thu, May 04, 2017 at 12:55:15PM +0200, Petr Mladek wrote:
> > RCU is not watching inside some RCU code. As a result, the livepatch
> > ftrace handler might see ops->func_stack and some other flags in
> > a wrong state. Then a livepatch might make the system unstable.
> >
> > diff --git a/kernel/livepatch/patch.c b/kernel/livepatch/patch.c
> > index 4c4fbe409008..ffdf5fa8005b 100644
> > --- a/kernel/livepatch/patch.c
> > +++ b/kernel/livepatch/patch.c
> > @@ -62,6 +62,14 @@ static void notrace klp_ftrace_handler(unsigned long ip,
> > /* RCU may not be watching, make it see us. */
> > rcu_irq_enter_irqson();
> >
> > + /*
> > +* RCU still might not see us if we patch a function inside
> > +* the RCU infrastructure. Then we might see wrong state of
> > +* func->stack and other flags.
> > +*/
> > + if (unlikely(!rcu_is_watching()))
> > + WARN_ONCE(1, "Livepatch modified a function that can not be
> > handled a safe way.!");
> > +
> > rcu_read_lock();
> >
> > func = list_first_or_null_rcu(&ops->func_stack, struct klp_func,
>
> Also I wonder if we can constrain the warning somehow. I think the
> warning only applies if a patch is in progress, right?
I think that this was not addressed in the other mails.
I wanted to add some constrains but all my attempts have failed
so far. For example, I wanted to avoid the warning when the function
was patched with the immediate flag set. We would be on the safe side.
Such a patch could not be removed. And the consistency model is week
enough.
The problem is that the transaction might finish too early when a
patched function cannot be watched by RCU. It means that the finished
transaction does not mean that we are safe. Also a finished transaction
allows to start a new one. Then the ftrace handler might see an
outdated function stack. Therefore it is not sure if the previously
used patch was immediate ("safely" handled) ...
Fortunately, this situation is a real corner case. It might actually be
good that the problem is always reported. It helps to detect it during
testing and avoid sending such a patch to users.
> In that case, if RCU is broken, would it be feasible to
> mutex_trylock() the klp mutex to try to ensure that no patches are
> being applied while the ftrace handler is running? Then it wouldn't
> matter if RCU were broken because the func stack wouldn't be
> changing anyway. Then it could only warn if it failed to get the
> mutex.
If we could not guarantee that a function might be patched a safe way,
we should not allow the patching in the first place.
The problem here is that this situation is detected at runtime.
We should do our best to avoid a damage if this happens. The 3rd patch
is from this category. But we should make it as easy as possible
to catch potential problems during patch creation or testing.
Best Regards,
Petr
Re: [GIT PULL] Please pull NFS client fixes for 4.12
On Thu, 2017-05-11 at 14:26 +0200, Michal Hocko wrote: > On Thu 11-05-17 12:16:37, Trond Myklebust wrote: > > On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote: > > > On Thu 11-05-17 10:53:27, Nikolay Borisov wrote: > > > > > > > > > > > > On 10.05.2017 19:47, Trond Myklebust wrote: > > > > > > [...] > > > > > - Cleanup and removal of some memory failure paths now that > > > > > GFP_NOFS is guaranteed to never fail. > > > > > > > > What guarantees that? Since if this is the case then this can > > > > result in > > > > a lot of opportunities for cleanup across the whole kernel > > > > tree. > > > > After > > > > discussing with mhocko (cc'ed) it seems that in practice > > > > everything > > > > below COSTLY_ORDER which are not GFP_NORETRY will never fail. > > > > But > > > > this > > > > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees > > > > that > > > > this will stay like that in the future? > > > > > > In practice it is hard to change the semantic of small > > > allocations > > > never > > > fail _practically_. But this is absolutely not guaranteed! They > > > can > > > fail > > > e.g. when the allocation context is the oom victim. Removing > > > error > > > paths > > > for allocation failures is just wrong. > > > > OK, this makes no fucking sense at all. > > > > Either allocations can fail or they can't. > > 1) If they can't fail, then we don't need the checks. > > 2) If they can fail, then we do need them, and this hand wringing > > in > > the MM community about GFP_* semantics and how we need to prevent > > failure is fucking pointless. > > everything which is not __GFP_NOFAIL might fail. We try hard not to > fail > small allocations requests as much as we can in general but you > _have_ to > check for failures. There is simply no way to guarantee "never fail" > semantic for all allocation requests. This has been like that > basically > since years. And even this try-to-be-nofailing for small allocations > has > been PITA for some corner cases. I'll take that as a vote for (2), then. I know that failures could occur in the past. That's why those code paths were there. The problem is that the MM community has been making lots of noise on mailing lists, conferences and LWN articles about how we must not fail small allocations because the MM community believes that nobody expects it. This is confusing everyone... It confused Neil Brown, who contributed these patches, and it confused me and all the other reviewers of these patches on the linux-nfs mailing list. So if indeed (2) is correct, then please can we have a clear statement _when discussing improvements to memory allocation semantics_ that GFP_* still can fail, still will fail, and that callers should assume it will fail and should test their code paths assuming the failure case. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.mykleb...@primarydata.com
[PATCH v2 1/2] KVM: arm: plug potential guest hardware debug leakage
From: Zhichao Huang
Hardware debugging in guests is not intercepted currently, it means
that a malicious guest can bring down the entire machine by writing
to the debug registers.
This patch enable trapping of all debug registers, preventing the
guests to access the debug registers. This includes access to the
debug mode(DBGDSCR) in the guest world all the time which could
otherwise mess with the host state. Reads return 0 and writes are
ignored (RAZ_WI).
The result is the guest cannot detect any working hardware based debug
support. As debug exceptions are still routed to the guest normal
debug using software based breakpoints still works.
To support debugging using hardware registers we need to implement a
debug register aware world switch as well as special trapping for
registers that may affect the host state.
Signed-off-by: Zhichao Huang
Signed-off-by: Alex Bennée
---
ajb v2:
- don't (void) unused return value
- fix some 0/1 bool usage
- further re-factor to avoid hacky if (cp15) in trap path
ajb v1:
- convert to C world switch
- reword commit message
---
arch/arm/include/asm/kvm_coproc.h | 3 +-
arch/arm/kvm/coproc.c | 77 ++-
arch/arm/kvm/handle_exit.c| 4 +-
arch/arm/kvm/hyp/switch.c | 4 +-
4 files changed, 66 insertions(+), 22 deletions(-)
diff --git a/arch/arm/include/asm/kvm_coproc.h
b/arch/arm/include/asm/kvm_coproc.h
index 4917c2f7e459..e74ab0fbab79 100644
--- a/arch/arm/include/asm/kvm_coproc.h
+++ b/arch/arm/include/asm/kvm_coproc.h
@@ -31,7 +31,8 @@ void kvm_register_target_coproc_table(struct
kvm_coproc_target_table *table);
int kvm_handle_cp10_id(struct kvm_vcpu *vcpu, struct kvm_run *run);
int kvm_handle_cp_0_13_access(struct kvm_vcpu *vcpu, struct kvm_run *run);
int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_handle_cp14_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 3e5e4194ef86..c3ed6bd5ddf3 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -93,12 +93,6 @@ int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct
kvm_run *run)
return 1;
}
-int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run)
-{
- kvm_inject_undefined(vcpu);
- return 1;
-}
-
static void reset_mpidr(struct kvm_vcpu *vcpu, const struct coproc_reg *r)
{
/*
@@ -514,12 +508,7 @@ static int emulate_cp15(struct kvm_vcpu *vcpu,
return 1;
}
-/**
- * kvm_handle_cp15_64 -- handles a mrrc/mcrr trap on a guest CP15 access
- * @vcpu: The VCPU pointer
- * @run: The kvm_run struct
- */
-int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static struct coproc_params decode_64bit_hsr(struct kvm_vcpu *vcpu)
{
struct coproc_params params;
@@ -533,9 +522,38 @@ int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct
kvm_run *run)
params.Rt2 = (kvm_vcpu_get_hsr(vcpu) >> 10) & 0xf;
params.CRm = 0;
+ return params;
+}
+
+/**
+ * kvm_handle_cp15_64 -- handles a mrrc/mcrr trap on a guest CP15 access
+ * @vcpu: The VCPU pointer
+ * @run: The kvm_run struct
+ */
+int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ struct coproc_params params = decode_64bit_hsr(vcpu);
+
return emulate_cp15(vcpu, ¶ms);
}
+/**
+ * kvm_handle_cp14_64 -- handles a mrrc/mcrr trap on a guest CP14 access
+ * @vcpu: The VCPU pointer
+ * @run: The kvm_run struct
+ */
+int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ struct coproc_params params = decode_64bit_hsr(vcpu);
+
+ /* raz_wi cp14 */
+ pm_fake(vcpu, ¶ms, NULL);
+
+ /* handled */
+ kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
+ return 1;
+}
+
static void reset_coproc_regs(struct kvm_vcpu *vcpu,
const struct coproc_reg *table, size_t num)
{
@@ -546,12 +564,7 @@ static void reset_coproc_regs(struct kvm_vcpu *vcpu,
table[i].reset(vcpu, &table[i]);
}
-/**
- * kvm_handle_cp15_32 -- handles a mrc/mcr trap on a guest CP15 access
- * @vcpu: The VCPU pointer
- * @run: The kvm_run struct
- */
-int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static struct coproc_params decode_32bit_hsr(struct kvm_vcpu *vcpu)
{
struct coproc_params params;
@@ -565,9 +578,37 @@ int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct
kvm_run *run)
params.Op2 = (kvm_vcpu_get_hsr(vcpu) >> 17) & 0x7;
params.Rt2 = 0;
+ return params;
+}
+
+/**
+ * kvm_handle_cp15_32 -- handles a mrc/mcr trap on a guest CP15 access
+ * @vcpu: The VCPU pointe
[PATCH v2 2/2] KVM: arm: rename pm_fake handler to trap_raz_wi
From: Zhichao Huang
pm_fake doesn't quite describe what the handler does (ignoring writes
and returning 0 for reads).
As we're about to use it (a lot) in a different context, rename it
with a (admitedly cryptic) name that make sense for all users.
Signed-off-by: Zhichao Huang
Reviewed-by: Alex Bennee
Acked-by: Christoffer Dall
Acked-by: Marc Zyngier
Signed-off-by: Alex Bennée
---
v2:
- fix minor merge conflicts
- add maz a-b
---
arch/arm/kvm/coproc.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index c3ed6bd5ddf3..31bd9bb0b765 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -260,7 +260,7 @@ static bool access_gic_sre(struct kvm_vcpu *vcpu,
* must always support PMCCNTR (the cycle counter): we just RAZ/WI for
* all PM registers, which doesn't crash the guest kernel at least.
*/
-static bool pm_fake(struct kvm_vcpu *vcpu,
+static bool trap_raz_wi(struct kvm_vcpu *vcpu,
const struct coproc_params *p,
const struct coproc_reg *r)
{
@@ -270,19 +270,19 @@ static bool pm_fake(struct kvm_vcpu *vcpu,
return read_zero(vcpu, p);
}
-#define access_pmcr pm_fake
-#define access_pmcntenset pm_fake
-#define access_pmcntenclr pm_fake
-#define access_pmovsr pm_fake
-#define access_pmselr pm_fake
-#define access_pmceid0 pm_fake
-#define access_pmceid1 pm_fake
-#define access_pmccntr pm_fake
-#define access_pmxevtyper pm_fake
-#define access_pmxevcntr pm_fake
-#define access_pmuserenr pm_fake
-#define access_pmintenset pm_fake
-#define access_pmintenclr pm_fake
+#define access_pmcr trap_raz_wi
+#define access_pmcntenset trap_raz_wi
+#define access_pmcntenclr trap_raz_wi
+#define access_pmovsr trap_raz_wi
+#define access_pmselr trap_raz_wi
+#define access_pmceid0 trap_raz_wi
+#define access_pmceid1 trap_raz_wi
+#define access_pmccntr trap_raz_wi
+#define access_pmxevtyper trap_raz_wi
+#define access_pmxevcntr trap_raz_wi
+#define access_pmuserenr trap_raz_wi
+#define access_pmintenset trap_raz_wi
+#define access_pmintenclr trap_raz_wi
/* Architected CP15 registers.
* CRn denotes the primary register number, but is copied to the CRm in the
@@ -547,7 +547,7 @@ int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct
kvm_run *run)
struct coproc_params params = decode_64bit_hsr(vcpu);
/* raz_wi cp14 */
- pm_fake(vcpu, ¶ms, NULL);
+ trap_raz_wi(vcpu, ¶ms, NULL);
/* handled */
kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
@@ -602,7 +602,7 @@ int kvm_handle_cp14_32(struct kvm_vcpu *vcpu, struct
kvm_run *run)
struct coproc_params params = decode_32bit_hsr(vcpu);
/* raz_wi cp14 */
- pm_fake(vcpu, ¶ms, NULL);
+ trap_raz_wi(vcpu, ¶ms, NULL);
/* handled */
kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
--
2.11.0
Re: [PATCH v3] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen
On Thu, 11 May 2017, Juergen Gross wrote: > On 27/04/17 07:01, Juergen Gross wrote: > > When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set > > on AMD cpus. > > > > This bug/feature bit is kind of special as it will be used very early > > when switching threads. Setting the bit and clearing it a little bit > > later leaves a critical window where things can go wrong. This time > > window has enlarged a little bit by using setup_clear_cpu_cap() instead > > of the hypervisor's set_cpu_features callback. It seems this larger > > window now makes it rather easy to hit the problem. > > > > The proper solution is to never set the bit in case of Xen. > > > > Signed-off-by: Juergen Gross > > Any objections for carrying this through the Xen tree? Acked-by: Thomas Gleixner
[PATCH] fbdev: avoid int-in-bool-context warning
gcc-7 suspects this code might be wrong because we use the result of a multiplication as a bool: drivers/video/fbdev/core/fbmon.c: In function 'fb_edid_add_monspecs': drivers/video/fbdev/core/fbmon.c:1051:84: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context] It's actually fine, so let's add a comparison to zero to make that clear to the compiler too. Signed-off-by: Arnd Bergmann --- drivers/video/fbdev/core/fbmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c index eaa6bab21839..99e45a49e435 100644 --- a/drivers/video/fbdev/core/fbmon.c +++ b/drivers/video/fbdev/core/fbmon.c @@ -1048,7 +1048,7 @@ void fb_edid_add_monspecs(unsigned char *edid, struct fb_monspecs *specs) for (i = 0; i < (128 - edid[2]) / DETAILED_TIMING_DESCRIPTION_SIZE; i++, block += DETAILED_TIMING_DESCRIPTION_SIZE) - if (PIXEL_CLOCK) + if (PIXEL_CLOCK != 0) edt[num++] = block - edid; /* Yikes, EDID data is totally useless */ -- 2.9.0
[PATCH] xfs: avoid harmless gcc-7 warnings
gcc-7 flags the use of integer math inside of a condition
as a potential bug:
fs/xfs/xfs_bmap_util.c: In function 'xfs_swap_extents_check_format':
fs/xfs/xfs_bmap_util.c:1619:8: error: '<<' in boolean context, did you mean '<'
? [-Werror=int-in-bool-context]
fs/xfs/xfs_bmap_util.c:1629:8: error: '<<' in boolean context, did you mean '<'
? [-Werror=int-in-bool-context]
This one is clearly fine, and we can add a comparison to zero
to shut up the warning.
Signed-off-by: Arnd Bergmann
---
fs/xfs/xfs_bmap_util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index 2b954308a1d6..cbd3ffe42f39 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -1613,7 +1613,7 @@ xfs_swap_extents_check_format(
* extent format...
*/
if (tip->i_d.di_format == XFS_DINODE_FMT_BTREE) {
- if (XFS_IFORK_BOFF(ip) &&
+ if ((XFS_IFORK_BOFF(ip) != 0) &&
XFS_BMAP_BMDR_SPACE(tip->i_df.if_broot) >
XFS_IFORK_BOFF(ip))
return -EINVAL;
if (XFS_IFORK_NEXTENTS(tip, XFS_DATA_FORK) <=
@@ -1623,7 +1623,7 @@ xfs_swap_extents_check_format(
/* Reciprocal target->temp btree format checks */
if (ip->i_d.di_format == XFS_DINODE_FMT_BTREE) {
- if (XFS_IFORK_BOFF(tip) &&
+ if ((XFS_IFORK_BOFF(tip) != 0) &&
XFS_BMAP_BMDR_SPACE(ip->i_df.if_broot) >
XFS_IFORK_BOFF(tip))
return -EINVAL;
if (XFS_IFORK_NEXTENTS(ip, XFS_DATA_FORK) <=
--
2.9.0
Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code
On Mon, 8 May 2017, Steven Rostedt wrote: > On Mon, 8 May 2017 14:47:29 -0500 > Josh Poimboeuf wrote: > > > > Although you should have: > > > > > > if (WARN_ONCE(!rcu_is_watching, > > > "Livepatch ...")) > > > return; > > > > > > or something to not cause any damage. > > > > My understanding is that returning would be more dangerous than > > continuing here. > > > > By continuing to run, there's only a small chance that it will get stale > > data, which would break the consistency model by executing an old > > version of the function and possibly crashing the system. > > > > On the other hand, returning would unconditionally break the consistency > > model by *always* executing an old version of the function. So that > > greatly increases the risk of a crash. > > I was being oversimplified by saying 'return', perhaps go into a > critical mode that can try again, or perhaps even back out the patch. > As in a transaction style. Yes, this will need to be thought through to > know how to get out. My comment wasn't meant to be simple. Well, live patching is in fact transactional. To some extent. If we fail during ftrace registration we abort the action gracefully. After the registration it gets more interesting because the whole system is "asynchronously" migrated to a final patched state. Even during this stage we can reverse the process (klp_reverse_transition()), but it was not easy to get it right... ... and to implement or start this logic from the handler sends shivers down my spine. We still can try. Thanks, Miroslav
[GIT PULL] fbdev changes for v4.12
Hi Linus, Please pull fbdev changes for v4.12. There is nothing really major here, just a couple of small bugfixes, improvements and cleanups. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: https://github.com/bzolnier/linux.git tags/fbdev-v4.12 for you to fetch changes up to 34bf129a7f068e3108dbb051b4b05674e2a270e7: fbdev: sti: don't select CONFIG_VT (2017-05-05 17:25:12 +0200) fbdev changes for v4.12: - fix handling of probing errors in omapfb (Arvind Yadav) - remove incorrect __exit markups in few drivers (Dmitry Torokhov) - fix boot time logo support for drivers using deferred probe (Takeshi Kihara) - fix DMA allocation size for ARM CLCD driver (Liam Beguin) - add support for specifying size via xenstore in xen-frontfb (Juergen Gross) - support for AUS mode in imxfb driver (Martin Kaiser) - fix buffer on stack usage in udlfb driver (Maksim Salau) - probe failure path fixup in sm501fb driver (Alexey Khoroshilov) - fix config dependency loop for stifb driver (Arnd Bergmann) - misc cleanups (Joe Perches, Christophe Leroy, Karim Eshapa, Pushkar Jambhlekar) Alexey Khoroshilov (1): sm501fb: don't return zero on failure path in sm501fb_start() Arnd Bergmann (1): fbdev: sti: don't select CONFIG_VT Arvind Yadav (1): omapfb: dss: Handle return errors in dss_init_ports() Christophe Leroy (1): video: console: Remove reference to CONFIG_8xx Dmitry Torokhov (4): video: fbdev: pmag-ba-fb: remove incorrect __exit markups video: fbdev: pmagb-b-fb: remove incorrect __exit markups video: fbdev: pmag-aa-fb: remove incorrect __exit markups video: fbdev: i810: remove incorrect __exit markups Joe Perches (1): drivers/video: Convert remaining uses of pr_warning to pr_warn Juergen Gross (1): xen, fbfront: add support for specifying size via xenstore Karim Eshapa (1): drivers/video/fbdev/omap/lcd_mipid.c: Use time comparison kernel macros Liam Beguin (1): video: ARM CLCD: fix dma allocation size Maksim Salau (1): video: fbdev: udlfb: Fix buffer on stack Martin Kaiser (2): video: fbdev: imxfb: support AUS mode dt-bindings: display: imx: entry for AUS mode Pushkar Jambhlekar (1): drivers/video/fbdev: Fixing coding guidelines in acornfb.c Takeshi Kihara (1): video/logo: tidyup fb_logo_late_init initcall timing .../devicetree/bindings/display/imx/fsl,imx-fb.txt | 2 ++ drivers/video/Makefile | 1 + drivers/video/console/Kconfig | 2 +- drivers/video/fbdev/Kconfig | 2 -- drivers/video/fbdev/acornfb.c | 12 +--- drivers/video/fbdev/amba-clcd.c | 4 ++-- drivers/video/fbdev/aty/radeon_base.c | 4 ++-- drivers/video/fbdev/core/fbmon.c| 4 ++-- drivers/video/fbdev/i810/i810_main.c| 6 +++--- drivers/video/fbdev/imxfb.c | 17 + drivers/video/fbdev/omap/lcd_mipid.c| 2 +- drivers/video/fbdev/omap2/omapfb/dss/dss.c | 16 +++- drivers/video/fbdev/pmag-aa-fb.c| 4 ++-- drivers/video/fbdev/pmag-ba-fb.c| 4 ++-- drivers/video/fbdev/pmagb-b-fb.c| 4 ++-- drivers/video/fbdev/pxafb.c | 7 +++ drivers/video/fbdev/sm501fb.c | 1 + drivers/video/fbdev/udlfb.c | 14 -- drivers/video/fbdev/xen-fbfront.c | 10 ++ drivers/video/logo/logo.c | 2 +- include/linux/platform_data/video-imxfb.h | 1 + 21 files changed, 81 insertions(+), 38 deletions(-)
[PATCH] ide: avoid warning for timings calculation
gcc-7 warns about the result of a constant multiplication used as
a boolean:
drivers/ide/ide-timings.c: In function 'ide_timing_quantize':
drivers/ide/ide-timings.c:112:24: error: '*' in boolean context, suggest '&&'
instead [-Werror=int-in-bool-context]
q->setup = EZ(t->setup * 1000, T);
This slightly rearranges the macro to simplify the code and avoid
the warning at the same time.
Signed-off-by: Arnd Bergmann
---
drivers/ide/ide-timings.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/ide/ide-timings.c b/drivers/ide/ide-timings.c
index 0e05f75934c9..9da64c1de85c 100644
--- a/drivers/ide/ide-timings.c
+++ b/drivers/ide/ide-timings.c
@@ -104,19 +104,19 @@ u16 ide_pio_cycle_time(ide_drive_t *drive, u8 pio)
EXPORT_SYMBOL_GPL(ide_pio_cycle_time);
#define ENOUGH(v, unit)(((v) - 1) / (unit) + 1)
-#define EZ(v, unit)((v) ? ENOUGH(v, unit) : 0)
+#define EZ(v, unit)((v) ? ENOUGH(v * 1000, unit) : 0)
static void ide_timing_quantize(struct ide_timing *t, struct ide_timing *q,
int T, int UT)
{
- q->setup = EZ(t->setup * 1000, T);
- q->act8b = EZ(t->act8b * 1000, T);
- q->rec8b = EZ(t->rec8b * 1000, T);
- q->cyc8b = EZ(t->cyc8b * 1000, T);
- q->active = EZ(t->active * 1000, T);
- q->recover = EZ(t->recover * 1000, T);
- q->cycle = EZ(t->cycle * 1000, T);
- q->udma= EZ(t->udma* 1000, UT);
+ q->setup = EZ(t->setup, T);
+ q->act8b = EZ(t->act8b, T);
+ q->rec8b = EZ(t->rec8b, T);
+ q->cyc8b = EZ(t->cyc8b, T);
+ q->active = EZ(t->active, T);
+ q->recover = EZ(t->recover, T);
+ q->cycle = EZ(t->cycle, T);
+ q->udma= EZ(t->udma,UT);
}
void ide_timing_merge(struct ide_timing *a, struct ide_timing *b,
--
2.9.0
[PATCH] ata: avoid gcc-7 warning in ata_timing_quantize
gcc-7 warns about the result of a constant multiplication used as
a boolean:
drivers/ata/libata-core.c: In function 'ata_timing_quantize':
drivers/ata/libata-core.c:3164:30: warning: '*' in boolean context, suggest
'&&' instead [-Wint-in-bool-context]
This slightly rearranges the macro to simplify the code and avoid
the warning at the same time.
Signed-off-by: Arnd Bergmann
---
drivers/ata/libata-core.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 2d83b8c75965..3fc4c35425f6 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3157,19 +3157,19 @@ static const struct ata_timing ata_timing[] = {
};
#define ENOUGH(v, unit)(((v)-1)/(unit)+1)
-#define EZ(v, unit)((v)?ENOUGH(v, unit):0)
+#define EZ(v, unit)((v)?ENOUGH((v * 1000), unit):0)
static void ata_timing_quantize(const struct ata_timing *t, struct ata_timing
*q, int T, int UT)
{
- q->setup= EZ(t->setup * 1000, T);
- q->act8b= EZ(t->act8b * 1000, T);
- q->rec8b= EZ(t->rec8b * 1000, T);
- q->cyc8b= EZ(t->cyc8b * 1000, T);
- q->active = EZ(t->active * 1000, T);
- q->recover = EZ(t->recover* 1000, T);
- q->dmack_hold = EZ(t->dmack_hold * 1000, T);
- q->cycle= EZ(t->cycle * 1000, T);
- q->udma = EZ(t->udma * 1000, UT);
+ q->setup= EZ(t->setup, T);
+ q->act8b= EZ(t->act8b, T);
+ q->rec8b= EZ(t->rec8b, T);
+ q->cyc8b= EZ(t->cyc8b, T);
+ q->active = EZ(t->active, T);
+ q->recover = EZ(t->recover, T);
+ q->dmack_hold = EZ(t->dmack_hold, T);
+ q->cycle= EZ(t->cycle, T);
+ q->udma = EZ(t->udma, UT);
}
void ata_timing_merge(const struct ata_timing *a, const struct ata_timing *b,
--
2.9.0
[PATCH] watchdog: core: add option to avoid early handling of watchdog
On some systems its desirable to have watchdog reboot the system
when it does not come up fast enough. This adds a kernel parameter
to disable the auto-update of watchdog before userspace takes over
and a kernel option to set the default. The info messages were
added to shorten error searching on misconfigured systems.
Signed-off-by: Sebastian Reichel
---
drivers/watchdog/Kconfig| 11 +++
drivers/watchdog/watchdog_dev.c | 16
2 files changed, 27 insertions(+)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 52a70ee6014f..4e08b2b97941 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -46,6 +46,17 @@ config WATCHDOG_NOWAYOUT
get killed. If you say Y here, the watchdog cannot be stopped once
it has been started.
+config WATCHDOG_HANDLE_BOOT_ENABLED
+ bool "Disable watchdog shutdown on close"
+ default y
+ help
+ The default watchdog behaviour (which you get if you say Y here) is
+ to ping watchdog devices, that were enabled before the driver has
+ been loaded until control is taken over from userspace using the
+ /dev/watchdog file. If you say N here, the kernel will not update
+ the watchdog on its own. Thus if your userspace does not start fast
+ enough your device will reboot.
+
config WATCHDOG_SYSFS
bool "Read different watchdog information through sysfs"
help
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index d5d2bbd8f428..5e6d6d4db82f 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -80,6 +80,9 @@ static struct watchdog_core_data *old_wd_data;
static struct workqueue_struct *watchdog_wq;
+static bool handle_boot_enabled =
+ IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED);
+
static inline bool watchdog_need_worker(struct watchdog_device *wdd)
{
/* All variables in milli-seconds */
@@ -956,6 +959,14 @@ static int watchdog_cdev_register(struct watchdog_device
*wdd, dev_t devno)
* and schedule an immediate ping.
*/
if (watchdog_hw_running(wdd)) {
+ if (!handle_boot_enabled) {
+ pr_info("watchdog%d running and kernel based
pre-userspace handler disabled\n",
+ wdd->id);
+ return 0;
+ }
+
+ pr_info("auto-update boot-enabled watchdog%d until userspace
takes over\n",
+ wdd->id);
__module_get(wdd->ops->owner);
kref_get(&wd_data->kref);
queue_delayed_work(watchdog_wq, &wd_data->work, 0);
@@ -1106,3 +1117,8 @@ void __exit watchdog_dev_exit(void)
class_unregister(&watchdog_class);
destroy_workqueue(watchdog_wq);
}
+
+module_param(handle_boot_enabled, bool, 0444);
+MODULE_PARM_DESC(handle_boot_enabled,
+ "Watchdog core auto-updates boot enabled watchdogs before userspace
takes over (default="
+ __MODULE_STRING(IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED)) ")");
--
2.11.0
Re: [PATCHv3 0/2] arm64: fix hotplug rwsem boot fallout
On Thu, May 11, 2017 at 12:01:21PM +0200, Thomas Gleixner wrote: > On Thu, 11 May 2017, Mark Rutland wrote: > > On Thu, May 11, 2017 at 10:30:39AM +0200, Thomas Gleixner wrote: > > > On Wed, 10 May 2017, Thomas Gleixner wrote: > > > secondary_start_kernel() > > > check_local_cpu_capabilities() > > > update_cpu_errata_workarounds() > > > update_cpu_capabilities() > > > static_key_enable() > > > __static_key_slow_inc() > > > jump_label_lock() > > > mutex_lock(&jump_label_mutex); > > > > > > How is that supposed to work? > > > > > > That call path is the low level CPU bringup, running in the context of the > > > idle task of that CPU with interrupts and preemption disabled. Taking a > > > mutex in that context, even if in that case the mutex is uncontended, is a > > > NONO. > > As an aside, do we have anything that should detect the broken mutex > > usage? I've been testing kernels with LOCKDEP, PROVE_LOCKING, > > DEBUG_ATOMIC_SLEEP, and friends, and nothing has complained so far. > > Peter and myself were wondering about that already. No idea why that > doesn't yell at you. AFAICT, this happens early enough that system_state is SYSTEM_BOOTING. In ___might_sleep(), we see this and bail out without a splat. Thanks, Mark.
Re: [GIT PULL] Please pull NFS client fixes for 4.12
On Thu 11-05-17 12:45:00, Trond Myklebust wrote: > On Thu, 2017-05-11 at 14:26 +0200, Michal Hocko wrote: > > On Thu 11-05-17 12:16:37, Trond Myklebust wrote: > > > On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote: > > > > On Thu 11-05-17 10:53:27, Nikolay Borisov wrote: > > > > > > > > > > > > > > > On 10.05.2017 19:47, Trond Myklebust wrote: > > > > > > > > [...] > > > > > > - Cleanup and removal of some memory failure paths now that > > > > > > GFP_NOFS is guaranteed to never fail. > > > > > > > > > > What guarantees that? Since if this is the case then this can > > > > > result in > > > > > a lot of opportunities for cleanup across the whole kernel > > > > > tree. > > > > > After > > > > > discussing with mhocko (cc'ed) it seems that in practice > > > > > everything > > > > > below COSTLY_ORDER which are not GFP_NORETRY will never fail. > > > > > But > > > > > this > > > > > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees > > > > > that > > > > > this will stay like that in the future? > > > > > > > > In practice it is hard to change the semantic of small > > > > allocations > > > > never > > > > fail _practically_. But this is absolutely not guaranteed! They > > > > can > > > > fail > > > > e.g. when the allocation context is the oom victim. Removing > > > > error > > > > paths > > > > for allocation failures is just wrong. > > > > > > OK, this makes no fucking sense at all. > > > > > > Either allocations can fail or they can't. > > > 1) If they can't fail, then we don't need the checks. > > > 2) If they can fail, then we do need them, and this hand wringing > > > in > > > the MM community about GFP_* semantics and how we need to prevent > > > failure is fucking pointless. > > > > everything which is not __GFP_NOFAIL might fail. We try hard not to > > fail > > small allocations requests as much as we can in general but you > > _have_ to > > check for failures. There is simply no way to guarantee "never fail" > > semantic for all allocation requests. This has been like that > > basically > > since years. And even this try-to-be-nofailing for small allocations > > has > > been PITA for some corner cases. > > I'll take that as a vote for (2), then. > > I know that failures could occur in the past. That's why those code > paths were there. The problem is that the MM community has been making > lots of noise on mailing lists, conferences and LWN articles about how > we must not fail small allocations because the MM community believes > that nobody expects it. This is confusing everyone... It was exactly other way around. We would like to _get_rid_of_ this do not fail behavior because it is causing a major headaches in out of memory corner cases. Just take GFP_NOFS as an example. It is a weak reclaim context because we cannot reclaim fs metadata and that might be a lot of memory so we cannot trigger the OOM killer and have to rely on a different allocation context or kswapd to make a progress on our behalf. We would really like to fail those requests instead. I've tried that in the past but it was deemed to dangerous because _all_ kernel paths would have to be checked for a sane failure behavior. So we are keeping status quo instead. > It confused Neil Brown, who contributed these patches, and it confused > me and all the other reviewers of these patches on the linux-nfs > mailing list. > > So if indeed (2) is correct, then please can we have a clear statement > _when discussing improvements to memory allocation semantics_ that > GFP_* still can fail, still will fail, and that callers should assume > it will fail and should test their code paths assuming the failure > case. I do not see any explicit documentation which would encourage users to not check for the allocation failure. Only __GFP_NOFAIL is documented it _must_ retry for ever. Of course I am open for any documentation improvements. -- Michal Hocko SUSE Labs
[PATCH v3 1/2] selinux: add brief info to policydb
Add policybrief field to struct policydb. It holds a brief info
of the policydb, in the following form:
<0 or 1 for enforce>:<0 or 1 for checkreqprot>:=
Policy brief is computed every time the policy is loaded, and when
enforce or checkreqprot are changed.
Add security_policy_brief hook to give access to policy brief to
the rest of the kernel. Lustre client makes use of this information
to detect changes to the policy, and forward it to Lustre servers.
Depending on how the policy is enforced on Lustre client side,
Lustre servers can refuse connection.
Signed-off-by: Sebastien Buisson
---
include/linux/lsm_hooks.h | 16
include/linux/security.h| 7
security/security.c | 6 +++
security/selinux/hooks.c| 7
security/selinux/include/security.h | 2 +
security/selinux/selinuxfs.c| 2 +
security/selinux/ss/policydb.c | 76 +
security/selinux/ss/policydb.h | 2 +
security/selinux/ss/services.c | 62 ++
9 files changed, 180 insertions(+)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 080f34e..9cac282 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1336,6 +1336,20 @@
* @inode we wish to get the security context of.
* @ctx is a pointer in which to place the allocated security context.
* @ctxlen points to the place to put the length of @ctx.
+ *
+ * Security hooks for policy brief
+ *
+ * @policy_brief:
+ *
+ * Returns a string containing a brief info of the policydb, in the
+ * following form:
+ * <0 or 1 for enforce>:<0 or 1 for checkreqprot>:=
+ *
+ * @brief: pointer to buffer holding brief
+ * @len: in: brief buffer length if no alloc, out: brief string len
+ * @alloc: whether to allocate buffer for brief or not
+ * On success 0 is returned , or negative value on error.
+ *
* This is the main security structure.
*/
@@ -1568,6 +1582,7 @@
int (*inode_setsecctx)(struct dentry *dentry, void *ctx, u32 ctxlen);
int (*inode_getsecctx)(struct inode *inode, void **ctx, u32 *ctxlen);
+ int (*policy_brief)(char **brief, size_t *len, bool alloc);
#ifdef CONFIG_SECURITY_NETWORK
int (*unix_stream_connect)(struct sock *sock, struct sock *other,
struct sock *newsk);
@@ -1813,6 +1828,7 @@ struct security_hook_heads {
struct list_head inode_notifysecctx;
struct list_head inode_setsecctx;
struct list_head inode_getsecctx;
+ struct list_head policy_brief;
#ifdef CONFIG_SECURITY_NETWORK
struct list_head unix_stream_connect;
struct list_head unix_may_send;
diff --git a/include/linux/security.h b/include/linux/security.h
index af675b5..3b72053 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -377,6 +377,8 @@ int security_sem_semop(struct sem_array *sma, struct sembuf
*sops,
int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen);
int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen);
+
+int security_policy_brief(char **brief, size_t *len, bool alloc);
#else /* CONFIG_SECURITY */
struct security_mnt_opts {
};
@@ -1166,6 +1168,11 @@ static inline int security_inode_getsecctx(struct inode
*inode, void **ctx, u32
{
return -EOPNOTSUPP;
}
+
+static inline int security_policy_brief(char **brief, size_t *len, bool alloc)
+{
+ return -EOPNOTSUPP;
+}
#endif /* CONFIG_SECURITY */
#ifdef CONFIG_SECURITY_NETWORK
diff --git a/security/security.c b/security/security.c
index b9fea39..954b391 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1285,6 +1285,12 @@ int security_inode_getsecctx(struct inode *inode, void
**ctx, u32 *ctxlen)
}
EXPORT_SYMBOL(security_inode_getsecctx);
+int security_policy_brief(char **brief, size_t *len, bool alloc)
+{
+ return call_int_hook(policy_brief, -EOPNOTSUPP, brief, len, alloc);
+}
+EXPORT_SYMBOL(security_policy_brief);
+
#ifdef CONFIG_SECURITY_NETWORK
int security_unix_stream_connect(struct sock *sock, struct sock *other, struct
sock *newsk)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e67a526..da245e8 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -6063,6 +6063,11 @@ static int selinux_inode_getsecctx(struct inode *inode,
void **ctx, u32 *ctxlen)
*ctxlen = len;
return 0;
}
+
+static int selinux_policy_brief(char **brief, size_t *len, bool alloc)
+{
+ return security_policydb_brief(brief, len, alloc);
+}
#ifdef CONFIG_KEYS
static int selinux_key_alloc(struct key *k, const struct cred *cred,
@@ -6277,6 +6282,8 @@ static int selinux_key_getsecurity(struct key *key, char
**_buffer)
LSM_HOOK_INIT(inode_setsecctx, selinux_inode_setsecctx),
LSM_HOOK_IN
[PATCH v3 2/2] selinux: expose policy brief via selinuxfs
Expose policy brief via selinuxfs.
Signed-off-by: Sebastien Buisson
---
security/selinux/selinuxfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 8c9f5b7..50f69c5 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -99,6 +99,7 @@ enum sel_inos {
SEL_STATUS, /* export current status using mmap() */
SEL_POLICY, /* allow userspace to read the in kernel policy */
SEL_VALIDATE_TRANS, /* compute validatetrans decision */
+ SEL_POLICYBRIEF,/* return policy summary */
SEL_INO_NEXT, /* The next inode number to use */
};
@@ -314,6 +315,29 @@ static ssize_t sel_read_policyvers(struct file *filp, char
__user *buf,
.llseek = generic_file_llseek,
};
+static ssize_t sel_read_policybrief(struct file *filp, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ char *tmpbuf;
+ size_t len;
+ ssize_t rc;
+
+ rc = security_policydb_brief(&tmpbuf, &len, true);
+ if (rc)
+ return rc;
+
+ rc = simple_read_from_buffer(buf, count, ppos, tmpbuf, len);
+
+ kfree(tmpbuf);
+
+ return rc;
+}
+
+static const struct file_operations sel_policybrief_ops = {
+ .read = sel_read_policybrief,
+ .llseek = generic_file_llseek,
+};
+
/* declaration for sel_write_load */
static int sel_make_bools(void);
static int sel_make_classes(void);
@@ -1827,6 +1851,8 @@ static int sel_fill_super(struct super_block *sb, void
*data, int silent)
[SEL_POLICY] = {"policy", &sel_policy_ops, S_IRUGO},
[SEL_VALIDATE_TRANS] = {"validatetrans", &sel_transition_ops,
S_IWUGO},
+ [SEL_POLICYBRIEF] = {"policybrief", &sel_policybrief_ops,
+S_IRUGO},
/* last one */ {""}
};
ret = simple_fill_super(sb, SELINUX_MAGIC, selinux_files);
--
1.8.3.1
Re: [PATCH v2 1/2] selinux: add brief info to policydb
2017-05-05 20:33 GMT+02:00 Casey Schaufler : > How do you see policy_brief being used by a modules > with dynamic policy? Policy's brief is computed on the binary representation every time the policy is loaded, and when enforce or checkreqprot are changed. It should not be a problem with a dynamic policy, unless I am missing something.
[PATCH 3.18 00/39] 3.18.53-stable review
This is the start of the stable review cycle for the 3.18.53 release. There are 39 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 Sat May 13 13:02:15 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.53-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 3.18.53-rc1 Nicolai Hähnle drm/ttm: fix use-after-free races in vm fault handling Jin Qian f2fs: sanity check segment count Eric Dumazet tcp: fix wraparound issue in tcp_lp WANG Cong ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf WANG Cong ipv6: initialize route null entry in addrconf_init() Alexander Potapenko ipv4, ipv6: ensure raw socket message is big enough to hold an IP header Eric Dumazet tcp: do not underestimate skb->truesize in tcp_trim_head() Arnd Bergmann staging: emxx_udc: remove incorrect __init annotations James Hughes brcmfmac: Make skb header writable before use James Hughes brcmfmac: Ensure pointer correctly set if skb data location changes Dan Carpenter scsi: scsi_dh_emc: return success in clariion_std_inquiry() Johan Hovold USB: serial: sierra: fix bogus alternate-setting assumption Johan Hovold USB: serial: io_edgeport: fix descriptor error handling Johan Hovold USB: serial: mct_u232: fix modem-status error handling Johan Hovold USB: serial: quatech2: fix control-message error handling Johan Hovold USB: serial: ftdi_sio: fix latency-timer error handling Johan Hovold USB: serial: ark3116: fix open error handling Johan Hovold USB: serial: ti_usb_3410_5052: fix control-message error handling Johan Hovold USB: serial: io_edgeport: fix epic-descriptor handling Johan Hovold USB: serial: ssu100: fix control-message error handling Johan Hovold USB: serial: digi_acceleport: fix incomplete rx sanity check Johan Hovold USB: serial: keyspan_pda: fix receive sanity checks Krzysztof Kozlowski usb: host: ohci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths Krzysztof Kozlowski usb: host: ehci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths Jim Mattson Revert "KVM: nested VMX: disable perf cpuid reporting" Andy Shevchenko x86/platform/intel-mid: Correct MSI IRQ line for watchdog device Masami Hiramatsu kprobes/x86: Fix kernel panic when certain exception-handling addresses are probed Nikola Pajkovsky x86/pci-calgary: Fix iommu_free() comparison of unsigned expression >= 0 Ganapathi Bhat mwifiex: Avoid skipping WEP key deletion for AP Brian Norris mwifiex: debugfs: Fix (sometimes) off-by-1 SSID print Matthijs van Duin ARM: OMAP5 / DRA7: Fix HYP mode boot for thumb2 build Liam Breck power: supply: bq24190_charger: Call set_mode_host() on pm_resume() Liam Breck power: supply: bq24190_charger: Fix irq trigger to IRQF_TRIGGER_FALLING Michael Ellerman powerpc/powernv: Fix opal_exit tracepoint opcode Ben Hutchings cpupower: Fix turbo frequency reporting for pre-Sandy Bridge cores Ard Biesheuvel ARM: 8452/3: PJ4: make coprocessor access sequences buildable in Thumb2 mode Arnd Bergmann mtd: cfi: reduce stack size Arnd Bergmann tty: remove platform_sysrq_reset_seq Cong Wang 9p: fix a potential acl leak - Diffstat: Makefile | 4 +- arch/arm/kernel/Makefile | 1 - arch/arm/kernel/pj4-cp0.c | 4 ++ arch/arm/mach-omap2/omap-headsmp.S | 3 +- arch/powerpc/platforms/powernv/opal-wrappers.S | 2 +- arch/x86/kernel/kprobes/common.h | 2 +- arch/x86/kernel/kprobes/core.c | 6 +-- arch/x86/kernel/kprobes/opt.c | 2 +- arch/x86/kernel/pci-calgary_64.c | 2 +- arch/x86/kvm/cpuid.c | 6 --- arch/x86/kvm/vmx.c | 2 - .../platform/intel-mid/device_libs/platform_wdt.c | 2 +- drivers/gpu/drm/ttm/ttm_bo_vm.c| 12 ++ .../net/wireless/brcm80211/brcmfmac/dhd_linux.c| 23 --- drivers/net/wireless/mwifiex/debugfs.c | 3 +- drivers/net/wireless/mwifiex/sta_ioctl.c | 2 - drivers/power/bq24190_charger.c| 3 +- drivers/scsi/device_handler/scsi_dh_emc.c | 2 +- drivers/staging/emxx_udc/emxx_udc.c| 4 +- drivers/tty/sysrq.c| 19 +
[PATCH 3.18 01/39] 9p: fix a potential acl leak
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Cong Wang
commit b5c66bab72a6a65edb15beb60b90d3cb84c5763b upstream.
posix_acl_update_mode() could possibly clear 'acl', if so we leak the
memory pointed by 'acl'. Save this pointer before calling
posix_acl_update_mode() and release the memory if 'acl' really gets
cleared.
Link:
http://lkml.kernel.org/r/1486678332-2430-1-git-send-email-xiyou.wangc...@gmail.com
Signed-off-by: Cong Wang
Reported-by: Mark Salyzyn
Reviewed-by: Jan Kara
Reviewed-by: Greg Kurz
Cc: Eric Van Hensbergen
Cc: Ron Minnich
Cc: Latchesar Ionkov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/9p/acl.c |2 ++
1 file changed, 2 insertions(+)
--- a/fs/9p/acl.c
+++ b/fs/9p/acl.c
@@ -321,6 +321,7 @@ static int v9fs_xattr_set_acl(struct den
name = POSIX_ACL_XATTR_ACCESS;
if (acl) {
struct iattr iattr;
+ struct posix_acl *old_acl = acl;
retval = posix_acl_update_mode(inode, &iattr.ia_mode,
&acl);
if (retval)
@@ -331,6 +332,7 @@ static int v9fs_xattr_set_acl(struct den
* by the mode bits. So don't
* update ACL.
*/
+ posix_acl_release(old_acl);
value = NULL;
size = 0;
}
[PATCH 3.18 04/39] ARM: 8452/3: PJ4: make coprocessor access sequences buildable in Thumb2 mode
3.18-stable review patch. If anyone has any objections, please let me know. -- From: Ard Biesheuvel commit 5008efc83bf85b647aa1cbc44718b1675bbb7444 upstream. The PJ4 inline asm sequence to write to cp15 cannot be built in Thumb-2 mode, due to the way it performs arithmetic on the program counter, so it is built in ARM mode instead. However, building C files in ARM mode under CONFIG_THUMB2_KERNEL is problematic, since the instrumentation performed by subsystems like ftrace does not expect having to deal with interworking branches. Since the sequence in question is simply a poor man's ISB instruction, let's use a straight 'isb' instead when building in Thumb2 mode. Thumb2 implies V7, so 'isb' should always be supported in that case. Acked-by: Arnd Bergmann Acked-by: Nicolas Pitre Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman --- arch/arm/kernel/Makefile |1 - arch/arm/kernel/pj4-cp0.c |4 2 files changed, 4 insertions(+), 1 deletion(-) --- a/arch/arm/kernel/Makefile +++ b/arch/arm/kernel/Makefile @@ -84,7 +84,6 @@ obj-$(CONFIG_CPU_PJ4B)+= pj4-cp0.o obj-$(CONFIG_IWMMXT) += iwmmxt.o obj-$(CONFIG_PERF_EVENTS) += perf_regs.o obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o perf_event_cpu.o -CFLAGS_pj4-cp0.o := -marm AFLAGS_iwmmxt.o:= -Wa,-mcpu=iwmmxt obj-$(CONFIG_ARM_CPU_TOPOLOGY) += topology.o --- a/arch/arm/kernel/pj4-cp0.c +++ b/arch/arm/kernel/pj4-cp0.c @@ -66,9 +66,13 @@ static void __init pj4_cp_access_write(u __asm__ __volatile__ ( "mcrp15, 0, %1, c1, c0, 2\n\t" +#ifdef CONFIG_THUMB2_KERNEL + "isb\n\t" +#else "mrcp15, 0, %0, c1, c0, 2\n\t" "mov%0, %0\n\t" "subpc, pc, #4\n\t" +#endif : "=r" (temp) : "r" (value)); }
[PATCH 3.18 07/39] power: supply: bq24190_charger: Fix irq trigger to IRQF_TRIGGER_FALLING
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Liam Breck
commit 767eee362fd72bb2ca44cc80419ca4b38c6d8369 upstream.
The interrupt signal is TRIGGER_FALLING. This is is specified in the
data sheet PIN FUNCTIONS: "The INT pin sends active low, 256us
pulse to host to report charger device status and fault."
Also the direction can be seen in the data sheet Figure 37 "BQ24190
with D+/D- Detection and USB On-The-Go (OTG)" which shows a 10k
pull-up resistor installed for the sample configurations.
Fixes: d7bf353fd0aa3 ("bq24190_charger: Add support for TI BQ24190 Battery
Charger")
Signed-off-by: Liam Breck
Acked-by: Mark Greer
Acked-by: Tony Lindgren
Signed-off-by: Sebastian Reichel
Signed-off-by: Greg Kroah-Hartman
---
drivers/power/bq24190_charger.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/power/bq24190_charger.c
+++ b/drivers/power/bq24190_charger.c
@@ -1400,7 +1400,7 @@ static int bq24190_probe(struct i2c_clie
ret = devm_request_threaded_irq(dev, bdi->irq, NULL,
bq24190_irq_handler_thread,
- IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
"bq24190-charger", bdi);
if (ret < 0) {
dev_err(dev, "Can't set up irq handler\n");
[PATCH 3.18 18/39] USB: serial: keyspan_pda: fix receive sanity checks
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold
commit c528fcb116e61afc379a2e0a0f70906b937f1e2c upstream.
Make sure to check for short transfers before parsing the receive buffer
to avoid acting on stale data.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/keyspan_pda.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
--- a/drivers/usb/serial/keyspan_pda.c
+++ b/drivers/usb/serial/keyspan_pda.c
@@ -139,6 +139,7 @@ static void keyspan_pda_rx_interrupt(str
{
struct usb_serial_port *port = urb->context;
unsigned char *data = urb->transfer_buffer;
+ unsigned int len = urb->actual_length;
int retval;
int status = urb->status;
struct keyspan_pda_private *priv;
@@ -159,18 +160,26 @@ static void keyspan_pda_rx_interrupt(str
goto exit;
}
+ if (len < 1) {
+ dev_warn(&port->dev, "short message received\n");
+ goto exit;
+ }
+
/* see if the message is data or a status interrupt */
switch (data[0]) {
case 0:
/* rest of message is rx data */
- if (urb->actual_length) {
- tty_insert_flip_string(&port->port, data + 1,
- urb->actual_length - 1);
- tty_flip_buffer_push(&port->port);
- }
+ if (len < 2)
+ break;
+ tty_insert_flip_string(&port->port, data + 1, len - 1);
+ tty_flip_buffer_push(&port->port);
break;
case 1:
/* status interrupt */
+ if (len < 3) {
+ dev_warn(&port->dev, "short interrupt message
received\n");
+ break;
+ }
dev_dbg(&port->dev, "rx int, d1=%d, d2=%d\n", data[1], data[2]);
switch (data[1]) {
case 1: /* modemline change */
[PATCH 3.18 31/39] brcmfmac: Make skb header writable before use
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: James Hughes
commit 9cc4b7cb86cbcc6330a3faa8cd65268cd2d3c227 upstream.
The driver was making changes to the skb_header without
ensuring it was writable (i.e. uncloned).
This patch also removes some boiler plate header size
checking/adjustment code as that is also handled by the
skb_cow_header function used to make header writable.
Signed-off-by: James Hughes
Acked-by: Arend van Spriel
Signed-off-by: Kalle Valo
Signed-off-by: Arend van Spriel
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
@@ -213,22 +213,13 @@ static netdev_tx_t brcmf_netdev_start_xm
goto done;
}
- /* Make sure there's enough room for any header */
- if (skb_headroom(skb) < drvr->hdrlen) {
- struct sk_buff *skb2;
-
- brcmf_dbg(INFO, "%s: insufficient headroom\n",
+ /* Make sure there's enough writable headroom*/
+ ret = skb_cow_head(skb, drvr->hdrlen);
+ if (ret < 0) {
+ brcmf_err("%s: skb_cow_head failed\n",
brcmf_ifname(drvr, ifp->bssidx));
- drvr->bus_if->tx_realloc++;
- skb2 = skb_realloc_headroom(skb, drvr->hdrlen);
dev_kfree_skb(skb);
- skb = skb2;
- if (skb == NULL) {
- brcmf_err("%s: skb_realloc_headroom failed\n",
- brcmf_ifname(drvr, ifp->bssidx));
- ret = -ENOMEM;
- goto done;
- }
+ goto done;
}
/* validate length for ether packet */
[PATCH 3.18 11/39] mwifiex: Avoid skipping WEP key deletion for AP
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Ganapathi Bhat
commit a5b60de6972decc6b50a39abb376077c3c3621c8 upstream.
This patch fixes the issue specific to AP. AP is started with WEP
security and external station is connected to it. Data path works
in this case. Now if AP is restarted with WPA/WPA2 security,
station is able to connect but ping fails.
Driver skips the deletion of WEP keys if interface type is AP.
Removing that redundant check resolves the issue.
Fixes: e57f1734d87a ("mwifiex: add key material v2 support")
Signed-off-by: Ganapathi Bhat
Signed-off-by: Amitkumar Karwar
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/mwifiex/sta_ioctl.c |2 --
1 file changed, 2 deletions(-)
--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -1074,8 +1074,6 @@ int mwifiex_set_encode(struct mwifiex_pr
encrypt_key.is_rx_seq_valid = true;
}
} else {
- if (GET_BSS_ROLE(priv) == MWIFIEX_BSS_ROLE_UAP)
- return 0;
encrypt_key.key_disable = true;
if (mac_addr)
memcpy(encrypt_key.mac_addr, mac_addr, ETH_ALEN);
[PATCH 3.18 02/39] tty: remove platform_sysrq_reset_seq
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Arnd Bergmann
commit ffb6e0c9a0572f8e5f8e9337a1b40ac2ec1493a1 upstream.
The platform_sysrq_reset_seq code was intended as a way for an embedded
platform to provide its own sysrq sequence at compile time. After over two
years, nobody has started using it in an upstream kernel, and the platforms
that were interested in it have moved on to devicetree, which can be used
to configure the sequence without requiring kernel changes. The method is
also incompatible with the way that most architectures build support for
multiple platforms into a single kernel.
Now the code is producing warnings when built with gcc-5.1:
drivers/tty/sysrq.c: In function 'sysrq_init':
drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds
[-Warray-bounds]
key = platform_sysrq_reset_seq[i];
We could fix this, but it seems unlikely that it will ever be used, so
let's just remove the code instead. We still have the option to pass the
sequence either in DT, using the kernel command line, or using the
/sys/module/sysrq/parameters/reset_seq file.
Fixes: 154b7a489a ("Input: sysrq - allow specifying alternate reset sequence")
Signed-off-by: Arnd Bergmann
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/sysrq.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -55,9 +55,6 @@
static int __read_mostly sysrq_enabled = CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE;
static bool __read_mostly sysrq_always_enabled;
-unsigned short platform_sysrq_reset_seq[] __weak = { KEY_RESERVED };
-int sysrq_reset_downtime_ms __weak;
-
static bool sysrq_on(void)
{
return sysrq_enabled || sysrq_always_enabled;
@@ -567,6 +564,7 @@ void handle_sysrq(int key)
EXPORT_SYMBOL(handle_sysrq);
#ifdef CONFIG_INPUT
+static int sysrq_reset_downtime_ms;
/* Simple translation table for the SysRq keys */
static const unsigned char sysrq_xlate[KEY_CNT] =
@@ -947,23 +945,8 @@ static bool sysrq_handler_registered;
static inline void sysrq_register_handler(void)
{
- unsigned short key;
int error;
- int i;
-
- /* First check if a __weak interface was instantiated. */
- for (i = 0; i < ARRAY_SIZE(sysrq_reset_seq); i++) {
- key = platform_sysrq_reset_seq[i];
- if (key == KEY_RESERVED || key > KEY_MAX)
- break;
-
- sysrq_reset_seq[sysrq_reset_seq_len++] = key;
- }
- /*
-* DT configuration takes precedence over anything that would
-* have been defined via the __weak interface.
-*/
sysrq_of_get_keyreset_config();
error = input_register_handler(&sysrq_handler);
[PATCH 3.18 22/39] USB: serial: ti_usb_3410_5052: fix control-message error handling
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold
commit 39712e8bfa8d3aa6ce1e60fc9d62c9b076c17a30 upstream.
Make sure to detect and return an error on zero-length control-message
transfers when reading from the device.
This addresses a potential failure to detect an empty transmit buffer
during close.
Also remove a redundant check for short transfer when sending a command.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/ti_usb_3410_5052.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -1343,13 +1343,10 @@ static int ti_command_out_sync(struct ti
(USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT),
value, moduleid, data, size, 1000);
- if (status == size)
- status = 0;
-
- if (status > 0)
- status = -ECOMM;
+ if (status < 0)
+ return status;
- return status;
+ return 0;
}
@@ -1365,8 +1362,7 @@ static int ti_command_in_sync(struct ti_
if (status == size)
status = 0;
-
- if (status > 0)
+ else if (status >= 0)
status = -ECOMM;
return status;
[PATCH 3.18 24/39] USB: serial: ftdi_sio: fix latency-timer error handling
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold
commit e3e574ad85a208cb179f33720bb5f12b453de33c upstream.
Make sure to detect short responses when reading the latency timer to
avoid using stale buffer data.
Note that no heap data would currently leak through sysfs as
ASYNC_LOW_LATENCY is set by default.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/ftdi_sio.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1437,10 +1437,13 @@ static int read_latency_timer(struct usb
FTDI_SIO_GET_LATENCY_TIMER_REQUEST_TYPE,
0, priv->interface,
buf, 1, WDR_TIMEOUT);
- if (rv < 0)
+ if (rv < 1) {
dev_err(&port->dev, "Unable to read latency timer: %i\n", rv);
- else
+ if (rv >= 0)
+ rv = -EIO;
+ } else {
priv->latency = buf[0];
+ }
kfree(buf);
[PATCH 3.18 17/39] usb: host: ohci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Krzysztof Kozlowski
commit 68bd6fc3cfa98ef253e17307ccafd8ef907b5556 upstream.
Returning from for_each_available_child_of_node() loop requires cleaning
up node refcount. Error paths lacked it so for example in case of
deferred probe, the refcount of phy node was left increased.
Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when
getting PHYs")
Signed-off-by: Krzysztof Kozlowski
Acked-by: Alan Stern
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/ohci-exynos.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -67,10 +67,12 @@ static int exynos_ohci_get_phy(struct de
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {
+ of_node_put(child);
return ret;
} else if (ret != -ENOSYS && ret != -ENODEV) {
dev_err(dev,
"Error retrieving usb2 phy: %d\n", ret);
+ of_node_put(child);
return ret;
}
}
[PATCH 3.18 26/39] USB: serial: mct_u232: fix modem-status error handling
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold
commit 36356a669eddb32917fc4b5c2b9b8bf80ede69de upstream.
Make sure to detect short control-message transfers so that errors are
logged when reading the modem status at open.
Note that while this also avoids initialising the modem status using
uninitialised heap data, these bits could not leak to user space as they
are currently not used.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/mct_u232.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/usb/serial/mct_u232.c
+++ b/drivers/usb/serial/mct_u232.c
@@ -322,8 +322,12 @@ static int mct_u232_get_modem_stat(struc
MCT_U232_GET_REQUEST_TYPE,
0, 0, buf, MCT_U232_GET_MODEM_STAT_SIZE,
WDR_TIMEOUT);
- if (rc < 0) {
+ if (rc < MCT_U232_GET_MODEM_STAT_SIZE) {
dev_err(&port->dev, "Get MODEM STATus failed (error = %d)\n",
rc);
+
+ if (rc >= 0)
+ rc = -EIO;
+
*msr = 0;
} else {
*msr = buf[0];
[PATCH 3.18 27/39] USB: serial: io_edgeport: fix descriptor error handling
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold
commit 3c0e25d883d06a1fbd1ad35257e8abaa57befb37 upstream.
Make sure to detect short control-message transfers and log an error
when reading incomplete manufacturer and boot descriptors.
Note that the default all-zero descriptors will now be used after a
short transfer is detected instead of partially initialised ones.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/io_edgeport.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
--- a/drivers/usb/serial/io_edgeport.c
+++ b/drivers/usb/serial/io_edgeport.c
@@ -2109,8 +2109,7 @@ static int rom_write(struct usb_serial *
* rom_read
* reads a number of bytes from the Edgeport device starting at the given
* address.
- * If successful returns the number of bytes read, otherwise it returns
- * a negative error number of the problem.
+ * Returns zero on success or a negative error number.
/
static int rom_read(struct usb_serial *serial, __u16 extAddr,
__u16 addr, __u16 length, __u8 *data)
@@ -2135,12 +2134,17 @@ static int rom_read(struct usb_serial *s
USB_REQUEST_ION_READ_ROM,
0xC0, addr, extAddr, transfer_buffer,
current_length, 300);
- if (result < 0)
+ if (result < current_length) {
+ if (result >= 0)
+ result = -EIO;
break;
+ }
memcpy(data, transfer_buffer, current_length);
length -= current_length;
addr += current_length;
data += current_length;
+
+ result = 0;
}
kfree(transfer_buffer);
@@ -2597,9 +2601,10 @@ static void get_manufacturing_desc(struc
EDGE_MANUF_DESC_LEN,
(__u8 *)(&edge_serial->manuf_descriptor));
- if (response < 1)
- dev_err(dev, "error in getting manufacturer descriptor\n");
- else {
+ if (response < 0) {
+ dev_err(dev, "error in getting manufacturer descriptor: %d\n",
+ response);
+ } else {
char string[30];
dev_dbg(dev, "**Manufacturer Descriptor\n");
dev_dbg(dev, " RomSize:%dK\n",
@@ -2656,9 +2661,10 @@ static void get_boot_desc(struct edgepor
EDGE_BOOT_DESC_LEN,
(__u8 *)(&edge_serial->boot_descriptor));
- if (response < 1)
- dev_err(dev, "error in getting boot descriptor\n");
- else {
+ if (response < 0) {
+ dev_err(dev, "error in getting boot descriptor: %d\n",
+ response);
+ } else {
dev_dbg(dev, "**Boot Descriptor:\n");
dev_dbg(dev, " BootCodeLength: %d\n",
le16_to_cpu(edge_serial->boot_descriptor.BootCodeLength));
[PATCH 3.18 13/39] kprobes/x86: Fix kernel panic when certain exception-handling addresses are probed
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Masami Hiramatsu
commit 75013fb16f8484898eaa8d0b08fed942d790f029 upstream.
Fix to the exception table entry check by using probed address
instead of the address of copied instruction.
This bug may cause unexpected kernel panic if user probe an address
where an exception can happen which should be fixup by __ex_table
(e.g. copy_from_user.)
Unless user puts a kprobe on such address, this doesn't
cause any problem.
This bug has been introduced years ago, by commit:
464846888d9a ("x86/kprobes: Fix a bug which can modify kernel code
permanently").
Signed-off-by: Masami Hiramatsu
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: 464846888d9a ("x86/kprobes: Fix a bug which can modify kernel code
permanently")
Link:
http://lkml.kernel.org/r/148829899399.28855.12581062400757221722.stgit@devbox
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/kprobes/common.h |2 +-
arch/x86/kernel/kprobes/core.c |6 +++---
arch/x86/kernel/kprobes/opt.c|2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
--- a/arch/x86/kernel/kprobes/common.h
+++ b/arch/x86/kernel/kprobes/common.h
@@ -67,7 +67,7 @@
#endif
/* Ensure if the instruction can be boostable */
-extern int can_boost(kprobe_opcode_t *instruction);
+extern int can_boost(kprobe_opcode_t *instruction, void *addr);
/* Recover instruction if given address is probed */
extern unsigned long recover_probed_instruction(kprobe_opcode_t *buf,
unsigned long addr);
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -163,12 +163,12 @@ NOKPROBE_SYMBOL(skip_prefixes);
* Returns non-zero if opcode is boostable.
* RIP relative instructions are adjusted at copying time in 64 bits mode
*/
-int can_boost(kprobe_opcode_t *opcodes)
+int can_boost(kprobe_opcode_t *opcodes, void *addr)
{
kprobe_opcode_t opcode;
kprobe_opcode_t *orig_opcodes = opcodes;
- if (search_exception_tables((unsigned long)opcodes))
+ if (search_exception_tables((unsigned long)addr))
return 0; /* Page fault may occur on this address. */
retry:
@@ -385,7 +385,7 @@ static int arch_copy_kprobe(struct kprob
* __copy_instruction can modify the displacement of the instruction,
* but it doesn't affect boostable check.
*/
- if (can_boost(p->ainsn.insn))
+ if (can_boost(p->ainsn.insn, p->addr))
p->ainsn.boostable = 0;
else
p->ainsn.boostable = -1;
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -177,7 +177,7 @@ static int copy_optimized_instructions(u
while (len < RELATIVEJUMP_SIZE) {
ret = __copy_instruction(dest + len, src + len);
- if (!ret || !can_boost(dest + len))
+ if (!ret || !can_boost(dest + len, src + len))
return -EINVAL;
len += ret;
}
[PATCH 3.18 37/39] tcp: fix wraparound issue in tcp_lp
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit a9f11f963a546fea9144f6a6d1a307e814a387e7 ]
Be careful when comparing tcp_time_stamp to some u32 quantity,
otherwise result can be surprising.
Fixes: 7c106d7e782b ("[TCP]: TCP Low Priority congestion control")
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/ipv4/tcp_lp.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/net/ipv4/tcp_lp.c
+++ b/net/ipv4/tcp_lp.c
@@ -264,13 +264,15 @@ static void tcp_lp_pkts_acked(struct soc
{
struct tcp_sock *tp = tcp_sk(sk);
struct lp *lp = inet_csk_ca(sk);
+ u32 delta;
if (rtt_us > 0)
tcp_lp_rtt_sample(sk, rtt_us);
/* calc inference */
- if (tcp_time_stamp > tp->rx_opt.rcv_tsecr)
- lp->inference = 3 * (tcp_time_stamp - tp->rx_opt.rcv_tsecr);
+ delta = tcp_time_stamp - tp->rx_opt.rcv_tsecr;
+ if ((s32)delta > 0)
+ lp->inference = 3 * delta;
/* test if within inference */
if (lp->last_drop && (tcp_time_stamp - lp->last_drop < lp->inference))
[PATCH 3.18 38/39] f2fs: sanity check segment count
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jin Qian
commit b9dd46188edc2f0d1f37328637860bb65a771124 upstream.
F2FS uses 4 bytes to represent block address. As a result, supported
size of disk is 16 TB and it equals to 16 * 1024 * 1024 / 2 segments.
Signed-off-by: Jin Qian
Signed-off-by: Jaegeuk Kim
Signed-off-by: Greg Kroah-Hartman
---
fs/f2fs/super.c |7 +++
include/linux/f2fs_fs.h |6 ++
2 files changed, 13 insertions(+)
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -913,6 +913,13 @@ static int sanity_check_raw_super(struct
return 1;
}
+ if (le32_to_cpu(raw_super->segment_count) > F2FS_MAX_SEGMENT) {
+ f2fs_msg(sb, KERN_INFO,
+ "Invalid segment count (%u)",
+ le32_to_cpu(raw_super->segment_count));
+ return 1;
+ }
+
/* check CP/SIT/NAT/SSA/MAIN_AREA area boundary */
if (sanity_check_area_boundary(sb, raw_super))
return 1;
--- a/include/linux/f2fs_fs.h
+++ b/include/linux/f2fs_fs.h
@@ -269,6 +269,12 @@ struct f2fs_nat_block {
#define SIT_ENTRY_PER_BLOCK (PAGE_CACHE_SIZE / sizeof(struct f2fs_sit_entry))
/*
+ * F2FS uses 4 bytes to represent block address. As a result, supported size of
+ * disk is 16 TB and it equals to 16 * 1024 * 1024 / 2 segments.
+ */
+#define F2FS_MAX_SEGMENT ((16 * 1024 * 1024) / 2)
+
+/*
* Note that f2fs_sit_entry->vblocks has the following bit-field information.
* [15:10] : allocation type such as CURSEG__TYPE
* [9:0] : valid block count
[PATCH 3.18 35/39] ipv6: initialize route null entry in addrconf_init()
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: WANG Cong
[ Upstream commit 2f460933f58eee3393aba64f0f6d14acb08d1724 ]
Andrey reported a crash on init_net.ipv6.ip6_null_entry->rt6i_idev
since it is always NULL.
This is clearly wrong, we have code to initialize it to loopback_dev,
unfortunately the order is still not correct.
loopback_dev is registered very early during boot, we lose a chance
to re-initialize it in notifier. addrconf_init() is called after
ip6_route_init(), which means we have no chance to correct it.
Fix it by moving this initialization explicitly after
ipv6_add_dev(init_net.loopback_dev) in addrconf_init().
Reported-by: Andrey Konovalov
Signed-off-by: Cong Wang
Tested-by: Andrey Konovalov
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
include/net/ip6_route.h |1 +
net/ipv6/addrconf.c |2 ++
net/ipv6/route.c| 26 +++---
3 files changed, 18 insertions(+), 11 deletions(-)
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -69,6 +69,7 @@ struct dst_entry *ip6_route_output(struc
struct dst_entry *ip6_route_lookup(struct net *net, struct flowi6 *fl6,
int flags);
+void ip6_route_init_special_entries(void);
int ip6_route_init(void);
void ip6_route_cleanup(void);
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -5441,6 +5441,8 @@ int __init addrconf_init(void)
goto errlo;
}
+ ip6_route_init_special_entries();
+
for (i = 0; i < IN6_ADDR_HSIZE; i++)
INIT_HLIST_HEAD(&inet6_addr_lst[i]);
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3133,6 +3133,21 @@ static struct notifier_block ip6_route_d
.priority = 0,
};
+void __init ip6_route_init_special_entries(void)
+{
+ /* Registering of the loopback is done before this portion of code,
+* the loopback reference in rt6_info will not be taken, do it
+* manually for init_net */
+ init_net.ipv6.ip6_null_entry->dst.dev = init_net.loopback_dev;
+ init_net.ipv6.ip6_null_entry->rt6i_idev =
in6_dev_get(init_net.loopback_dev);
+ #ifdef CONFIG_IPV6_MULTIPLE_TABLES
+ init_net.ipv6.ip6_prohibit_entry->dst.dev = init_net.loopback_dev;
+ init_net.ipv6.ip6_prohibit_entry->rt6i_idev =
in6_dev_get(init_net.loopback_dev);
+ init_net.ipv6.ip6_blk_hole_entry->dst.dev = init_net.loopback_dev;
+ init_net.ipv6.ip6_blk_hole_entry->rt6i_idev =
in6_dev_get(init_net.loopback_dev);
+ #endif
+}
+
int __init ip6_route_init(void)
{
int ret;
@@ -3158,17 +3173,6 @@ int __init ip6_route_init(void)
ip6_dst_blackhole_ops.kmem_cachep = ip6_dst_ops_template.kmem_cachep;
- /* Registering of the loopback is done before this portion of code,
-* the loopback reference in rt6_info will not be taken, do it
-* manually for init_net */
- init_net.ipv6.ip6_null_entry->dst.dev = init_net.loopback_dev;
- init_net.ipv6.ip6_null_entry->rt6i_idev =
in6_dev_get(init_net.loopback_dev);
- #ifdef CONFIG_IPV6_MULTIPLE_TABLES
- init_net.ipv6.ip6_prohibit_entry->dst.dev = init_net.loopback_dev;
- init_net.ipv6.ip6_prohibit_entry->rt6i_idev =
in6_dev_get(init_net.loopback_dev);
- init_net.ipv6.ip6_blk_hole_entry->dst.dev = init_net.loopback_dev;
- init_net.ipv6.ip6_blk_hole_entry->rt6i_idev =
in6_dev_get(init_net.loopback_dev);
- #endif
ret = fib6_init();
if (ret)
goto out_register_subsys;
[PATCH 3.18 30/39] brcmfmac: Ensure pointer correctly set if skb data location changes
3.18-stable review patch. If anyone has any objections, please let me know. -- From: James Hughes commit 455a1eb4654c24560eb9dfc634f29cba3d87601e upstream. The incoming skb header may be resized if header space is insufficient, which might change the data adddress in the skb. Ensure that a cached pointer to that data is correctly set by moving assignment to after any possible changes. Signed-off-by: James Hughes Acked-by: Arend van Spriel Signed-off-by: Kalle Valo Signed-off-by: Arend van Spriel Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c +++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c @@ -192,7 +192,7 @@ static netdev_tx_t brcmf_netdev_start_xm int ret; struct brcmf_if *ifp = netdev_priv(ndev); struct brcmf_pub *drvr = ifp->drvr; - struct ethhdr *eh = (struct ethhdr *)(skb->data); + struct ethhdr *eh; brcmf_dbg(DATA, "Enter, idx=%d\n", ifp->bssidx); @@ -238,6 +238,8 @@ static netdev_tx_t brcmf_netdev_start_xm goto done; } + eh = (struct ethhdr *)(skb->data); + if (eh->h_proto == htons(ETH_P_PAE)) atomic_inc(&ifp->pend_8021x_cnt);
[PATCH 3.18 36/39] ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: WANG Cong
[ Upstream commit 242d3a49a2a1a71d8eb9f953db1bcaa9d698ce00 ]
For each netns (except init_net), we initialize its null entry
in 3 places:
1) The template itself, as we use kmemdup()
2) Code around dst_init_metrics() in ip6_route_net_init()
3) ip6_route_dev_notify(), which is supposed to initialize it after
loopback registers
Unfortunately the last one still happens in a wrong order because
we expect to initialize net->ipv6.ip6_null_entry->rt6i_idev to
net->loopback_dev's idev, thus we have to do that after we add
idev to loopback. However, this notifier has priority == 0 same as
ipv6_dev_notf, and ipv6_dev_notf is registered after
ip6_route_dev_notifier so it is called actually after
ip6_route_dev_notifier. This is similar to commit 2f460933f58e
("ipv6: initialize route null entry in addrconf_init()") which
fixes init_net.
Fix it by picking a smaller priority for ip6_route_dev_notifier.
Also, we have to release the refcnt accordingly when unregistering
loopback_dev because device exit functions are called before subsys
exit functions.
Acked-by: David Ahern
Tested-by: David Ahern
Signed-off-by: Cong Wang
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
include/net/addrconf.h |2 ++
net/ipv6/addrconf.c|1 +
net/ipv6/route.c | 13 +++--
3 files changed, 14 insertions(+), 2 deletions(-)
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -19,6 +19,8 @@
#define ADDRCONF_TIMER_FUZZ(HZ / 4)
#define ADDRCONF_TIMER_FUZZ_MAX(HZ)
+#define ADDRCONF_NOTIFY_PRIORITY 0
+
#include
#include
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2984,6 +2984,7 @@ static int addrconf_notify(struct notifi
*/
static struct notifier_block ipv6_dev_notf = {
.notifier_call = addrconf_notify,
+ .priority = ADDRCONF_NOTIFY_PRIORITY,
};
static void addrconf_type_change(struct net_device *dev, unsigned long event)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2815,7 +2815,10 @@ static int ip6_route_dev_notify(struct n
struct net_device *dev = netdev_notifier_info_to_dev(ptr);
struct net *net = dev_net(dev);
- if (event == NETDEV_REGISTER && (dev->flags & IFF_LOOPBACK)) {
+ if (!(dev->flags & IFF_LOOPBACK))
+ return NOTIFY_OK;
+
+ if (event == NETDEV_REGISTER) {
net->ipv6.ip6_null_entry->dst.dev = dev;
net->ipv6.ip6_null_entry->rt6i_idev = in6_dev_get(dev);
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
@@ -2824,6 +2827,12 @@ static int ip6_route_dev_notify(struct n
net->ipv6.ip6_blk_hole_entry->dst.dev = dev;
net->ipv6.ip6_blk_hole_entry->rt6i_idev = in6_dev_get(dev);
#endif
+} else if (event == NETDEV_UNREGISTER) {
+ in6_dev_put(net->ipv6.ip6_null_entry->rt6i_idev);
+#ifdef CONFIG_IPV6_MULTIPLE_TABLES
+ in6_dev_put(net->ipv6.ip6_prohibit_entry->rt6i_idev);
+ in6_dev_put(net->ipv6.ip6_blk_hole_entry->rt6i_idev);
+#endif
}
return NOTIFY_OK;
@@ -3130,7 +3139,7 @@ static struct pernet_operations ip6_rout
static struct notifier_block ip6_route_dev_notifier = {
.notifier_call = ip6_route_dev_notify,
- .priority = 0,
+ .priority = ADDRCONF_NOTIFY_PRIORITY - 10,
};
void __init ip6_route_init_special_entries(void)
[PATCH 3.18 28/39] USB: serial: sierra: fix bogus alternate-setting assumption
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold
commit 16620b483eaf7750413bae472f4363b6b959fcaa upstream.
Interface numbers do not change when enabling alternate settings as
comment and code in this driver suggested.
Remove the confusing comment and redundant retrieval of the interface
number in probe, while simplifying and renaming the interface-number
helper.
Fixes: 4db2299da213 ("sierra: driver interface blacklisting")
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/sierra.c | 28 +---
1 file changed, 5 insertions(+), 23 deletions(-)
--- a/drivers/usb/serial/sierra.c
+++ b/drivers/usb/serial/sierra.c
@@ -137,24 +137,9 @@ static int is_himemory(const u8 ifnum,
return 0;
}
-static int sierra_calc_interface(struct usb_serial *serial)
+static u8 sierra_interface_num(struct usb_serial *serial)
{
- int interface;
- struct usb_interface *p_interface;
- struct usb_host_interface *p_host_interface;
-
- /* Get the interface structure pointer from the serial struct */
- p_interface = serial->interface;
-
- /* Get a pointer to the host interface structure */
- p_host_interface = p_interface->cur_altsetting;
-
- /* read the interface descriptor for this active altsetting
-* to find out the interface number we are on
- */
- interface = p_host_interface->desc.bInterfaceNumber;
-
- return interface;
+ return serial->interface->cur_altsetting->desc.bInterfaceNumber;
}
static int sierra_probe(struct usb_serial *serial,
@@ -165,7 +150,7 @@ static int sierra_probe(struct usb_seria
u8 ifnum;
udev = serial->dev;
- ifnum = sierra_calc_interface(serial);
+ ifnum = sierra_interface_num(serial);
/*
* If this interface supports more than 1 alternate
@@ -178,9 +163,6 @@ static int sierra_probe(struct usb_seria
usb_set_interface(udev, ifnum, 1);
}
- /* ifnum could have changed - by calling usb_set_interface */
- ifnum = sierra_calc_interface(serial);
-
if (is_blacklisted(ifnum,
(struct sierra_iface_info *)id->driver_info)) {
dev_dbg(&serial->dev->dev,
@@ -342,7 +324,7 @@ static int sierra_send_setup(struct usb_
/* If composite device then properly report interface */
if (serial->num_ports == 1) {
- interface = sierra_calc_interface(serial);
+ interface = sierra_interface_num(serial);
/* Control message is sent only to interfaces with
* interrupt_in endpoints
*/
@@ -916,7 +898,7 @@ static int sierra_port_probe(struct usb_
/* Determine actual memory requirements */
if (serial->num_ports == 1) {
/* Get interface number for composite device */
- ifnum = sierra_calc_interface(serial);
+ ifnum = sierra_interface_num(serial);
himemoryp = &typeB_interface_list;
} else {
/* This is really the usb-serial port number of the interface
