Re: [PATCH v4] x86/suspend: fix false positive KASAN warning on suspend/resume
On 12/02/2016 08:42 PM, Josh Poimboeuf wrote: > Resuming from a suspend operation is showing a KASAN false positive > warning: > > BUG: KASAN: stack-out-of-bounds in unwind_get_return_address+0x11d/0x130 at > addr 8803867d7878 > Read of size 8 by task pm-suspend/7774 > page:ea000e19f5c0 count:0 mapcount:0 mapping: (null) index:0x0 > flags: 0x200() > page dumped because: kasan: bad access detected > CPU: 0 PID: 7774 Comm: pm-suspend Tainted: GB 4.9.0-rc7+ #8 > Hardware name: Gigabyte Technology Co., Ltd. Z170X-UD5/Z170X-UD5-CF, BIOS > F5 03/07/2016 > Call Trace: > dump_stack+0x63/0x82 > kasan_report_error+0x4b4/0x4e0 > ? acpi_hw_read_port+0xd0/0x1ea > ? kfree_const+0x22/0x30 > ? acpi_hw_validate_io_request+0x1a6/0x1a6 > __asan_report_load8_noabort+0x61/0x70 > ? unwind_get_return_address+0x11d/0x130 > unwind_get_return_address+0x11d/0x130 > ? unwind_next_frame+0x97/0xf0 > __save_stack_trace+0x92/0x100 > save_stack_trace+0x1b/0x20 > save_stack+0x46/0xd0 > ? save_stack_trace+0x1b/0x20 > ? save_stack+0x46/0xd0 > ? kasan_kmalloc+0xad/0xe0 > ? kasan_slab_alloc+0x12/0x20 > ? acpi_hw_read+0x2b6/0x3aa > ? acpi_hw_validate_register+0x20b/0x20b > ? acpi_hw_write_port+0x72/0xc7 > ? acpi_hw_write+0x11f/0x15f > ? acpi_hw_read_multiple+0x19f/0x19f > ? memcpy+0x45/0x50 > ? acpi_hw_write_port+0x72/0xc7 > ? acpi_hw_write+0x11f/0x15f > ? acpi_hw_read_multiple+0x19f/0x19f > ? kasan_unpoison_shadow+0x36/0x50 > kasan_kmalloc+0xad/0xe0 > kasan_slab_alloc+0x12/0x20 > kmem_cache_alloc_trace+0xbc/0x1e0 > ? acpi_get_sleep_type_data+0x9a/0x578 > acpi_get_sleep_type_data+0x9a/0x578 > acpi_hw_legacy_wake_prep+0x88/0x22c > ? acpi_hw_legacy_sleep+0x3c7/0x3c7 > ? acpi_write_bit_register+0x28d/0x2d3 > ? acpi_read_bit_register+0x19b/0x19b > acpi_hw_sleep_dispatch+0xb5/0xba > acpi_leave_sleep_state_prep+0x17/0x19 > acpi_suspend_enter+0x154/0x1e0 > ? trace_suspend_resume+0xe8/0xe8 > suspend_devices_and_enter+0xb09/0xdb0 > ? printk+0xa8/0xd8 > ? arch_suspend_enable_irqs+0x20/0x20 > ? try_to_freeze_tasks+0x295/0x600 > pm_suspend+0x6c9/0x780 > ? finish_wait+0x1f0/0x1f0 > ? suspend_devices_and_enter+0xdb0/0xdb0 > state_store+0xa2/0x120 > ? kobj_attr_show+0x60/0x60 > kobj_attr_store+0x36/0x70 > sysfs_kf_write+0x131/0x200 > kernfs_fop_write+0x295/0x3f0 > __vfs_write+0xef/0x760 > ? handle_mm_fault+0x1346/0x35e0 > ? do_iter_readv_writev+0x660/0x660 > ? __pmd_alloc+0x310/0x310 > ? do_lock_file_wait+0x1e0/0x1e0 > ? apparmor_file_permission+0x18/0x20 > ? security_file_permission+0x73/0x1c0 > ? rw_verify_area+0xbd/0x2b0 > vfs_write+0x149/0x4a0 > SyS_write+0xd9/0x1c0 > ? SyS_read+0x1c0/0x1c0 > entry_SYSCALL_64_fastpath+0x1e/0xad > Memory state around the buggy address: >8803867d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >8803867d7780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >8803867d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4 > ^ >8803867d7880: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >8803867d7900: 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3 00 > > KASAN instrumentation poisons the stack when entering a function and > unpoisons it when exiting the function. However, in the suspend path, > some functions never return, so their stack never gets unpoisoned, > resulting in stale KASAN shadow data which can cause later false > positive warnings like the one above. > > Reported-by: Scott Bauer > Signed-off-by: Josh Poimboeuf Acked-by: Andrey Ryabinin
Re: [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR
Hi Michael,
[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on v4.9-rc7]
[cannot apply to next-20161202]
[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/Michael-Ellerman/lkdtm-Add-tests-for-LIST_POISON-and-ZERO_SIZE_PTR/20161203-124958
config: blackfin-allyesconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All error/warnings (new ones prefixed by >>):
In file included from include/linux/cache.h:4:0,
from include/linux/printk.h:8,
from include/linux/kernel.h:13,
from drivers/misc/lkdtm.h:6,
from drivers/misc/lkdtm_bugs.c:7:
drivers/misc/lkdtm_bugs.c: In function 'test_poison_ptr':
>> drivers/misc/lkdtm_bugs.c:160:20: error: 'CONFIG_DEFAULT_MMAP_MIN_ADDR'
>> undeclared (first use in this function)
bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
^
include/uapi/linux/kernel.h:10:41: note: in definition of macro
'__ALIGN_KERNEL_MASK'
#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
^
>> include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
#define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
^~
>> include/linux/mm.h:126:26: note: in expansion of macro 'ALIGN'
#define PAGE_ALIGN(addr) ALIGN(addr, PAGE_SIZE)
^
>> drivers/misc/lkdtm_bugs.c:160:9: note: in expansion of macro 'PAGE_ALIGN'
bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
^~
drivers/misc/lkdtm_bugs.c:160:20: note: each undeclared identifier is
reported only once for each function it appears in
bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
^
include/uapi/linux/kernel.h:10:41: note: in definition of macro
'__ALIGN_KERNEL_MASK'
#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
^
>> include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
#define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
^~
>> include/linux/mm.h:126:26: note: in expansion of macro 'ALIGN'
#define PAGE_ALIGN(addr) ALIGN(addr, PAGE_SIZE)
^
>> drivers/misc/lkdtm_bugs.c:160:9: note: in expansion of macro 'PAGE_ALIGN'
bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
^~
vim +/CONFIG_DEFAULT_MMAP_MIN_ADDR +160 drivers/misc/lkdtm_bugs.c
1 /*
2 * This is for all the tests related to logic bugs (e.g. bad
dereferences,
3 * bad alignment, bad loops, bad locking, bad scheduling, deep stacks,
and
4 * lockups) along with other things that don't fit well into existing
LKDTM
5 * test source files.
6 */
> 7 #include "lkdtm.h"
8 #include
9 #include
10 #include
11 #include
12
13 /*
14 * Make sure our attempts to over run the kernel stack doesn't trigger
15 * a compiler warning when CONFIG_FRAME_WARN is set. Then make sure we
16 * recurse past the end of THREAD_SIZE by default.
17 */
18 #if defined(CONFIG_FRAME_WARN) && (CONFIG_FRAME_WARN > 0)
19 #define REC_STACK_SIZE (CONFIG_FRAME_WARN / 2)
20 #else
21 #define REC_STACK_SIZE (THREAD_SIZE / 8)
22 #endif
23 #define REC_NUM_DEFAULT ((THREAD_SIZE / REC_STACK_SIZE) * 2)
24
25 static int recur_count = REC_NUM_DEFAULT;
26
27 static DEFINE_SPINLOCK(lock_me_up);
28
29 static int recursive_loop(int remaining)
30 {
31 char buf[REC_STACK_SIZE];
32
33 /* Make sure compiler does not optimize this away. */
34 memset(buf, (remaining & 0xff) | 0x1, REC_STACK_SIZE);
35 if (!remaining)
36 return 0;
37 else
38 return recursive_loop(remaining - 1);
39 }
40
41 /* If the depth is negative, use the default, otherwise keep parameter.
*/
42 void __init lkdtm_bugs_init(int *recur_param)
43 {
44 if (*recur_param < 0)
45 *recur_param = recur_count;
46 else
47 recur_count = *recur_param;
48 }
49
50 void lkdtm_PANIC(void)
51 {
52 panic("dumptest");
5
3.5%LOAN OFFER
APPLY 3.5%LOAN.pdf Description: Adobe PDF document Application Form.pdf Description: Adobe PDF document
Re: [PATCH] hotplug: make register and unregister notifier API symmetric
Hi Michal, [auto build test ERROR on linus/master] [also build test ERROR on v4.9-rc7 next-20161202] [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/Michal-Hocko/hotplug-make-register-and-unregister-notifier-API-symmetric/20161203-114815 config: i386-randconfig-s1-201648 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): mm/built-in.o: In function `zs_unregister_cpu_notifier': >> zsmalloc.c:(.text.unlikely+0xc7e): undefined reference to >> `__unregister_cpu_notifier' arch/x86/oprofile/built-in.o: In function `nmi_timer_shutdown': nmi_timer_int.c:(.text+0x1c7d): undefined reference to `__unregister_cpu_notifier' arch/x86/oprofile/built-in.o: In function `nmi_shutdown': nmi_int.c:(.text+0x2319): undefined reference to `__unregister_cpu_notifier' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[x86/asm] cdfac81296: kernel_BUG_at_arch/x86/kernel/alternative.c
FYI, we noticed the following commit:
commit: cdfac8129693572ef91b9e7022d6ae07f1c8cc38 ("x86/asm: Rewrite sync_core()
to use IRET-to-self")
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/boot
in testcase: boot
on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 256M
caused below changes:
+-+++
| | 535a025bb9 | cdfac81296 |
+-+++
| boot_successes | 6 | 0 |
| boot_failures | 0 | 4 |
| kernel_BUG_at_arch/x86/kernel/alternative.c | 0 | 4 |
| invalid_opcode:#[##]SMP | 0 | 4 |
| EIP_is_at_apply_alternatives| 0 | 4 |
| Kernel_panic-not_syncing:Fatal_exception| 0 | 4 |
+-+++
[0.429066] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.447516] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.455310] [ cut here ]
[0.459612] kernel BUG at arch/x86/kernel/alternative.c:386!
[0.465842] invalid opcode: [#1] SMP
[0.469305] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.9.0-rc7-00027-gcdfac81 #1
[0.476137] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[0.483617] task: c84cb040 task.stack: c84c4000
[0.486773] EIP: 0060:[] EFLAGS: 00210246 CPU: 0
[0.490857] EIP is at apply_alternatives+0xa5/0x7e3
[0.494426] EAX: d83b0ff0 EBX: c84abb75 ECX: EDX: 00ae
[0.499509] ESI: 0004 EDI: c84c5eb6 EBP: c84c5fbc ESP: c84c5e90
[0.503883] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
[0.508031] CR0: 80050033 CR2: CR3: 089df000 CR4: 0690
[0.512150] Stack:
[0.514412] c69f2b7c 0003 0004 fbfb 0ff0ae0f 0089 c84abb81
d83b6984
[0.529825] e58900e8 cf49340f c84c5eec 0002 c888dba0 c84c5f74 c84c5ed4
c683cc1e
[0.537271] c84c5f00 c84c5f14 c683d4f7 c84c5f00 002b c84c5f60 0143
03c0003f
[0.545924] Call Trace:
[0.548885] [] ? __kmem_cache_create+0x37d/0x5c7
[0.552895] [] ? __cpuid+0x1a/0x2e
[0.556362] [] ? cpuid4_cache_lookup_regs+0x4ad/0x52f
To reproduce:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.9.0-rc7 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_KERNEL_LZ4=y
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONF
Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
On Fri, Dec 2, 2016 at 3:39 PM, Bjorn Helgaas wrote:
>
> On Thu, Dec 01, 2016 at 11:08:23PM -0500, Jon Masters wrote:
> > Hi Bjorn, Duc, Mark,
> >
> > I switched my brain to the on mode and went and read some specs, and a few
> > tables, so here's my 2 cents on this...
> >
> > On 12/01/2016 06:22 PM, Duc Dang wrote:
> > > On Thu, Dec 1, 2016 at 3:07 PM, Bjorn Helgaas wrote:
> > >> On Thu, Dec 01, 2016 at 02:10:10PM -0800, Duc Dang wrote:
> >
> > > The SoC provide some number of RC bridges, each with a different base
> > > for some mmio registers. Even if segment is legitimate in MCFG, there
> > > is still a problem if a platform doesn't use the segment ordering
> > > implied by the code. But the PNP0A03 _CRS does have this base address
> > > as the first memory resource, so we could get it from there and not
> > > have hard-coded addresses and implied ording in the quirk code.
> >
> > I'm confused. Doesn't the current code treat every item in PNP0A03
> > _CRS as a window? Do you mean the first resource is handled
> > differently somehow? The Consumer/Producer bit could allow us to do
> > this by marking the RC MMIO space as "Consumer", but I didn't think
> > that strategy was quite working yet.
> >
> > Let's see if I summarized this correctly...
> >
> > 1. The MMIO registers for the host bridge itself need to be described
> >somewhere, especially if we need to find those in a quirk and poke
> >them. Since those registers are very much part of the bridge device,
> >it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.
> >
> > 2. The address space covering these registers MUST be described as a
> >ResourceConsumer in order to avoid accidentally exposing them as
> >available for use by downstream devices on the PCI bus.
> >
> > 3. The ACPI specification allows for resources of the type "Memory32Fixed".
> >This is a macro that doesn't have the notion of a producer or consumer.
> >HOWEVER various interpretations seem to be that this could/should
> >default to being interpreted as a consumed region.
>
> I agree; I think that per spec, Memory24, Memory32, Memory32Fixed, IO,
> and FixedIO should all be for consumed resources, not for bridge
> windows, since they don't have the notion of producer.
>
> I'm pretty sure there's x86 firmware in the field that uses these for
> windows, so I think we have to accept that usage, at least on x86.
>
> > 4. At one point, a regression was added to the kernel:
> >
> >63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
> >host bridge itself")
> >
> >Which lead to a series on conversations about what should happen
> >for bridge resources (e.g. https://lkml.org/lkml/2015/3/24/962 )
> >
> > 5. This resulted in the following commit reverting point 4:
> >
> >2c62e8492ed7 ("x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff]
> >available on PCI bus")
> >
> >Which also stated that:
> >
> >"This solution will also ease the way to consolidate ACPI PCI host
> > bridge common code from x86, ia64 and ARM64"
> >
> > End of summary.
> >
> > So it seems that generally there is an aversion to having bridge resources
> > be described in this manner and you would like to require that they be
> > described e.g. using QWordMemory with a ResourceConsumer type?
>
> Per spec, we should ignore the Consumer/Producer bit in Word/DWord/QWord
> descriptors. In bridge devices on x86, I think we have to treat them as
> producers (windows) because that's how they've been typically used.
>
> > BUT if we were to do that, it would break existing shipping systems since
> > there are quirks out there that use this form to find the base CSR:
> >
> >if (acpi_res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
> > fixed32 = &acpi_res->data.fixed_memory32;
> > port->csr_base = ioremap(fixed32->address,
> > fixed32->address_length);
> > return AE_CTRL_TERMINATE;
> > }
>
> I think this is a valid usage of FixedMemory32 in terms of the spec.
> Linux currently handles this as a window if it appears in a PNP0A03
> device because some x86 firmware used it that way.
>
> We might be able to handle it differently on arm64, e.g., by making an
> arm64 version of pci_acpi_root_prepare_resources() that checks for
> IORESOURCE_WINDOW.
>
> > 2. What would happen if we had a difference policy on arm64 for such
> >resources. x86 has an "exception" for accessing the config space
> >using IO port 0xCF8-0xCFF (a fairly reasonable exception!) and
> >we can make the rules for a new platform (i.e. actually prescribe
> >exactly what the behavior is, rather than have it not be defined).
> >This is of course terrible in that existing BIOS vendors and so on
> >won't necessarily know this when working on ARM ACPI later on.
>
> > Indeed. And in the case of m400, it is currentl
Re: [PATCH] staging: Replaced BUG_ON with warnings
On Sat, Dec 3, 2016 at 12:32 PM, Shilpa Puttegowda wrote: > From: Shilpa P > > Don't crash the Kernel for driver errors > > Signed-off-by: Shilpa P > --- > drivers/staging/media/bcm2048/radio-bcm2048.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > Acked-by: Allen Pais
[PATCH] staging: Replaced BUG_ON with warnings
From: Shilpa P
Don't crash the Kernel for driver errors
Signed-off-by: Shilpa P
---
drivers/staging/media/bcm2048/radio-bcm2048.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 4d9bd02..05f5918 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -1538,7 +1538,11 @@ static int bcm2048_parse_rt_match_c(struct
bcm2048_device *bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return 0;
- BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);
+ if ((index + 2) >= BCM2048_MAX_RDS_RT) {
+ dev_err(&bdev->client->dev,
+ "Incorrect index = %d\n", index);
+ return 0;
+ }
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_C) {
@@ -1561,7 +1565,11 @@ static void bcm2048_parse_rt_match_d(struct
bcm2048_device *bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return;
- BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);
+ if ((index + 4) >= BCM2048_MAX_RDS_RT) {
+ dev_err(&bdev->client->dev,
+ "Incorrect index = %d\n", index);
+ return;
+ }
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_D)
--
1.9.1
Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup
On December 2, 2016 9:49:50 PM PST, Ingo Molnar wrote: > >* Boris Ostrovsky wrote: > >> > It is tricky to do so safely, because at this stage almost nothing >of the C >> > execution environment has been set up. > >Yeah - but we do have a fair amount of early C code though. > >> I can still give it a try but I'd rather not tie it to this (Xen PVH) >patch >> series. Which would leave me with two options: either keep what this >patch does, >> leaving it as assembly (requires your ack), or have Xen code build >the pages on >> its own. > >If you give it a try in a subsequent patch (please Cc: me) then it's OK >to me: > > Acked-by: Ingo Molnar > >Feel free to carry it in the Xen tree. > >Thanks, > > Ingo It's true that it is now possible to run pre-paging C code. It would be so much better if Xen could simply go though the normal code path like any civilized machine. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[PATCH] btrfs: limit async_work allocation and worker func duration
Problem statement: unprivileged user who has read-write access to more than
one btrfs subvolume may easily consume all kernel memory (eventually
triggering oom-killer).
Reproducer (./mkrmdir below essentially loops over mkdir/rmdir):
[root@kteam1 ~]# cat prep.sh
DEV=/dev/sdb
mkfs.btrfs -f $DEV
mount $DEV /mnt
for i in `seq 1 16`
do
mkdir /mnt/$i
btrfs subvolume create /mnt/SV_$i
ID=`btrfs subvolume list /mnt |grep "SV_$i$" |cut -d ' ' -f 2`
mount -t btrfs -o subvolid=$ID $DEV /mnt/$i
chmod a+rwx /mnt/$i
done
[root@kteam1 ~]# sh prep.sh
[maxim@kteam1 ~]$ for i in `seq 1 16`; do ./mkrmdir /mnt/$i 2000 2000 & done
[root@kteam1 ~]# for i in `seq 1 4`; do grep "kmalloc-128" /proc/slabinfo |
grep -v dma; sleep 60; done
kmalloc-12810144 10144128 321 : tunables000 :
slabdata317317 0
kmalloc-128 9992352 9992352128 321 : tunables000 :
slabdata 312261 312261 0
kmalloc-128 24226752 24226752128 321 : tunables000
: slabdata 757086 757086 0
kmalloc-128 42754240 42754240128 321 : tunables000
: slabdata 1336070 1336070 0
The huge numbers above come from insane number of async_work-s allocated
and queued by btrfs_wq_run_delayed_node.
The problem is caused by btrfs_wq_run_delayed_node() queuing more and more
works if the number of delayed items is above BTRFS_DELAYED_BACKGROUND. The
worker func (btrfs_async_run_delayed_root) processes at least
BTRFS_DELAYED_BATCH items (if they are present in the list). So, the machinery
works as expected while the list is almost empty. As soon as it is getting
bigger, worker func starts to process more than one item at a time, it takes
longer, and the chances to have async_works queued more than needed is getting
higher.
The problem above is worsened by another flaw of delayed-inode implementation:
if async_work was queued in a throttling branch (number of items >=
BTRFS_DELAYED_WRITEBACK), corresponding worker func won't quit until
the number of items < BTRFS_DELAYED_BACKGROUND / 2. So, it is possible that
the func occupies CPU infinitely (up to 30sec in my experiments): while the
func is trying to drain the list, the user activity may add more and more
items to the list.
The patch fixes both problems in straightforward way: refuse queuing too
many works in btrfs_wq_run_delayed_node and bail out of worker func if
at least BTRFS_DELAYED_WRITEBACK items are processed.
Signed-off-by: Maxim Patlasov
---
fs/btrfs/async-thread.c |8
fs/btrfs/async-thread.h |1 +
fs/btrfs/delayed-inode.c |6 --
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
index e0f071f..29f6252 100644
--- a/fs/btrfs/async-thread.c
+++ b/fs/btrfs/async-thread.c
@@ -86,6 +86,14 @@ btrfs_work_owner(struct btrfs_work *work)
return work->wq->fs_info;
}
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq)
+{
+ int thresh = wq->normal->thresh != NO_THRESHOLD ?
+ wq->normal->thresh : num_possible_cpus();
+
+ return atomic_read(&wq->normal->pending) > thresh * 2;
+}
+
BTRFS_WORK_HELPER(worker_helper);
BTRFS_WORK_HELPER(delalloc_helper);
BTRFS_WORK_HELPER(flush_delalloc_helper);
diff --git a/fs/btrfs/async-thread.h b/fs/btrfs/async-thread.h
index 8e52484..1f95973 100644
--- a/fs/btrfs/async-thread.h
+++ b/fs/btrfs/async-thread.h
@@ -84,4 +84,5 @@ void btrfs_workqueue_set_max(struct btrfs_workqueue *wq, int
max);
void btrfs_set_work_high_priority(struct btrfs_work *work);
struct btrfs_fs_info *btrfs_work_owner(struct btrfs_work *work);
struct btrfs_fs_info *btrfs_workqueue_owner(struct __btrfs_workqueue *wq);
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq);
#endif
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 3eeb9cd..de946dd 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1356,7 +1356,8 @@ release_path:
total_done++;
btrfs_release_prepared_delayed_node(delayed_node);
- if (async_work->nr == 0 || total_done < async_work->nr)
+ if ((async_work->nr == 0 && total_done < BTRFS_DELAYED_WRITEBACK) ||
+ total_done < async_work->nr)
goto again;
free_path:
@@ -1372,7 +1373,8 @@ static int btrfs_wq_run_delayed_node(struct
btrfs_delayed_root *delayed_root,
{
struct btrfs_async_delayed_work *async_work;
- if (atomic_read(&delayed_root->items) < BTRFS_DELAYED_BACKGROUND)
+ if (atomic_read(&delayed_root->items) < BTRFS_DELAYED_BACKGROUND ||
+ btrfs_workqueue_normal_congested(fs_info->delayed_workers))
return 0;
async_work = kmalloc(sizeof(*async_work), GFP_NOFS);
[PATCH] Fix style issues in kernel/cpu.c
This patch fixes style issues in kernel/cpu.c such as wrapping an 80
character line, calling EXPORT_SYMBOL() immediately after a function is
defined, and whitespace and spacing issues.
Signed-off-by: Thomas Casey
---
kernel/cpu.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 29de1a9..15a90ba 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -228,7 +228,8 @@ static struct {
.wq = __WAIT_QUEUE_HEAD_INITIALIZER(cpu_hotplug.wq),
.lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
#ifdef CONFIG_DEBUG_LOCK_ALLOC
- .dep_map = STATIC_LOCKDEP_MAP_INIT("cpu_hotplug.dep_map",
&cpu_hotplug.dep_map),
+ .dep_map = STATIC_LOCKDEP_MAP_INIT("cpu_hotplug.dep_map",
+ &cpu_hotplug.dep_map),
#endif
};
@@ -304,7 +305,7 @@ void cpu_hotplug_begin(void)
mutex_lock(&cpu_hotplug.lock);
prepare_to_wait(&cpu_hotplug.wq, &wait, TASK_UNINTERRUPTIBLE);
if (likely(!atomic_read(&cpu_hotplug.refcount)))
- break;
+ break;
mutex_unlock(&cpu_hotplug.lock);
schedule();
}
@@ -353,6 +354,7 @@ EXPORT_SYMBOL_GPL(cpu_hotplug_enable);
int register_cpu_notifier(struct notifier_block *nb)
{
int ret;
+
cpu_maps_update_begin();
ret = raw_notifier_chain_register(&cpu_chain, nb);
cpu_maps_update_done();
@@ -363,6 +365,7 @@ int __register_cpu_notifier(struct notifier_block *nb)
{
return raw_notifier_chain_register(&cpu_chain, nb);
}
+EXPORT_SYMBOL(__register_cpu_notifier);
static int __cpu_notify(unsigned long val, unsigned int cpu, int nr_to_call,
int *nr_calls)
@@ -661,7 +664,6 @@ void __init cpuhp_threads_init(void)
#ifdef CONFIG_HOTPLUG_CPU
EXPORT_SYMBOL(register_cpu_notifier);
-EXPORT_SYMBOL(__register_cpu_notifier);
void unregister_cpu_notifier(struct notifier_block *nb)
{
cpu_maps_update_begin();
@@ -1250,7 +1252,7 @@ static struct cpuhp_step cpuhp_bp_states[] = {
.teardown.single= NULL,
},
#ifdef CONFIG_SMP
- [CPUHP_CREATE_THREADS]= {
+ [CPUHP_CREATE_THREADS] = {
.name = "threads:prepare",
.startup.single = smpboot_create_threads,
.teardown.single= NULL,
@@ -1366,7 +1368,8 @@ static struct cpuhp_step cpuhp_ap_states[] = {
.teardown.single= rcutree_dying_cpu,
},
/* Entry state on starting. Interrupts enabled from here on. Transient
-* state for synchronsization */
+* state for synchronsization
+*/
[CPUHP_AP_ONLINE] = {
.name = "ap:online",
},
--
2.10.2
Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup
* Boris Ostrovsky wrote: > > It is tricky to do so safely, because at this stage almost nothing of the C > > execution environment has been set up. Yeah - but we do have a fair amount of early C code though. > I can still give it a try but I'd rather not tie it to this (Xen PVH) patch > series. Which would leave me with two options: either keep what this patch > does, > leaving it as assembly (requires your ack), or have Xen code build the pages > on > its own. If you give it a try in a subsequent patch (please Cc: me) then it's OK to me: Acked-by: Ingo Molnar Feel free to carry it in the Xen tree. Thanks, Ingo
Re: [PATCH] clk: Register clkdev after setup of fixed-rate and fixed-factor clocks
On 二, 11月 29, 2016 at 01:10:54下午 -0800, Stephen Boyd wrote: > On 11/24, Xiaolong Zhang wrote: > > On 三, 11月 23, 2016 at 04:38:33下午 -0800, Stephen Boyd wrote: > > > > > We're really off track now though. Can you please point to some > > > code that needs this change? If we're using DT then we should be > > > able to use the of_clk_*() path to find the clk. > > > > > > > Actually, the requirement is raised by our GPU driver. In the > > early stage of the GPU DT driver, the GPU driver use the > > clk_get(NULL, con_id) to get the clock instance for compatible > > with non-DT GPU driver. The new driver have used the of_clk_get() > > instead of the clk_get. And we reserved the modification in clock. > > > > Ok the non-DT version of the GPU driver should be modified to > call clk_get() and pass in the device. The con_id argument there > should be something specific to the GPU device, and not a global > name of a clock on the system. When the clkdev lookup is > populated on the non-DT board make sure to set the dev_id string > to match the device name of the GPU device. > Ok, Thanks sBoyd! > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project
Re: [PATCH] hotplug: make register and unregister notifier API symmetric
Hi Michal, [auto build test ERROR on linus/master] [also build test ERROR on v4.9-rc7 next-20161202] [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/Michal-Hocko/hotplug-make-register-and-unregister-notifier-API-symmetric/20161203-114815 config: i386-randconfig-r0-201648 (attached as .config) compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): arch/x86/oprofile/built-in.o: In function `nmi_timer_shutdown': >> nmi_timer_int.c:(.text+0x238b): undefined reference to >> `__unregister_cpu_notifier' arch/x86/oprofile/built-in.o: In function `nmi_shutdown': nmi_int.c:(.text+0x2793): undefined reference to `__unregister_cpu_notifier' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 1/7] vfs - merge path_is_mountpoint() and path_is_mountpoint_rcu()
FWIW, I've folded that pile into vfs.git#work.autofs. Problems: * (fixed) __path_is_mountpoint() should _not_ treat NULL from __lookup_mnt() as "nothing's mounted there" until it has checked that mount_lock hadn't been touched - mount --move on something unrelated can race with lockless hash lookup and lead to false negatives. * linux/mount.h might be the wrong place for path_is_mountpoint(). Or it shouldn't be inlined. I don't like the includes you've added there. * path_has_submounts() is broken. At the very least, it's AB-BA between mount_lock and rename_lock. I would suggest trying to put read_seqlock_excl(&mount_lock) around the call of d_walk() in there, and using __lookup_mnt() in the callback (without retries on the mount_lock, of course - read_seqlock_excl done on the outside is enough). I'm not sure if it won't cause trouble with contention, though; that needs testing. As it is, that function is broken in #work.autofs, same as it is in -mm and -next. * the last one (propagation-related) is too ugly to live - at the very least, its pieces should live in fs/pnode.c; exposing propagate_next() is simply wrong. I hadn't picked that one at all, and I would suggest coordinating anything in that area with ebiederman - he has some work around fs/pnode.c and you risk stepping on his toes.
Re: [PATCH 1/3] remoteproc: qcom: mdt_loader: add include for sizes
On Tue 22 Nov 09:02 PST 2016, Stanimir Varbanov wrote: > Add linux/sizes.h to prevent build failure on non ARM architectures > as: > > CC [M] drivers/remoteproc/qcom_mdt_loader.o > In file included from include/linux/cache.h:4:0, > from include/linux/printk.h:8, > from include/linux/kernel.h:13, > from include/asm-generic/bug.h:13, > from arch/x86/include/asm/bug.h:35, > from include/linux/bug.h:4, > from include/linux/thread_info.h:11, > from arch/x86/include/asm/elf.h:7, > from include/linux/elf.h:4, > from drivers/remoteproc/qcom_mdt_loader.c:18: > drivers/remoteproc/qcom_mdt_loader.c: In function ‘qcom_mdt_parse’: > drivers/remoteproc/qcom_mdt_loader.c:90:52: error: ‘SZ_4K’ undeclared > (first use in this function) > > Signed-off-by: Stanimir Varbanov Applied Thanks, Bjorn > --- > drivers/remoteproc/qcom_mdt_loader.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/remoteproc/qcom_mdt_loader.c > b/drivers/remoteproc/qcom_mdt_loader.c > index 114e8e4cef67..2ff18cd6c096 100644 > --- a/drivers/remoteproc/qcom_mdt_loader.c > +++ b/drivers/remoteproc/qcom_mdt_loader.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > > #include "remoteproc_internal.h" > -- > 2.7.4 >
[PATCH] remoteproc: Remove "experimental" warning
Warning users that remoteproc and it's binary format are under development doesn't serve much of a purpose. Different drivers support different image formats and the resource table has a version field that would need to be bumped when incompatible changes are introduced. So lets drop this warning to clean up the kernel log. Signed-off-by: Bjorn Andersson --- drivers/remoteproc/remoteproc_core.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index f0f6ec1ab12b..fc2ebff7d332 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -1298,9 +1298,6 @@ int rproc_add(struct rproc *rproc) dev_info(dev, "%s is available\n", rproc->name); - dev_info(dev, "Note: remoteproc is still under development and considered experimental.\n"); - dev_info(dev, "THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.\n"); - /* create debugfs entries */ rproc_create_debug_dir(rproc); ret = rproc_add_virtio_devices(rproc); -- 2.5.0
Re: [RFC, PATCH, v3.9] default exported asm symbols to zero
On Fri, 2016-12-02 at 13:40 +0100, Arnd Bergmann wrote: > With binutils-2.16 and before, a weak missing symbol was kept during the > final link, and a missing CRC for an export would lead to that CRC > being treated as zero implicitly. With binutils-2.17, the crc > symbol gets dropped, and any module trying to use it will fail to > load. > > This sets the weak CRC symbol to zero explicitly, making it defined > in vmlinux, which in turn lets us load the modules referring to > that CRC. > > The comment above the __CRC_SYMBOL macro suggests that this was > always the intention, although it also seems that all symbols > defined in C have a correct CRC these days, and only the exports > that are now done in assembly need this. > > > Signed-off-by: Arnd Bergmann > --- > Not sure if this is the correct way of doing it, but this seems trivial > enough and lets me build the kernel with missing CRCs with any binutils > version. I tried this along with Adam's patch on x86_64, with Debian's binutils 2.27.51.20161127. The result was that the kernel's __kcrctab held 0 for several symbols, even though there was type information in asm- prototypes.h and Module.symvers and the modules had a non-zero CRC for those symbols. With just Adam's patch, the kernel and modules agreed. Ben. > diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h > index 63554e9..59a3b2f 100644 > --- a/include/asm-generic/export.h > +++ b/include/asm-generic/export.h > @@ -54,6 +54,7 @@ KSYM(__kstrtab_\name): > KSYM(__kcrctab_\name): > > __put KSYM(__crc_\name) > > .weak KSYM(__crc_\name) > > + .set KSYM(__crc_\name), 0 > > .previous > #endif > #endif > -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Re: [PATCH] blk-stat: fix a typo
On 12/02/2016 08:16 PM, Jens Axboe wrote:
> On 12/02/2016 06:13 PM, Shaohua Li wrote:
>> Signed-off-by: Shaohua Li
>> ---
>> block/blk-stat.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/block/blk-stat.c b/block/blk-stat.c
>> index 688c958..4d01185 100644
>> --- a/block/blk-stat.c
>> +++ b/block/blk-stat.c
>> @@ -12,7 +12,7 @@
>> static void blk_stat_flush_batch(struct blk_rq_stat *stat)
>> {
>> const s32 nr_batch = READ_ONCE(stat->nr_batch);
>> -const s32 nr_samples = READ_ONCE(stat->nr_batch);
>> +const s32 nr_samples = READ_ONCE(stat->nr_samples);
>>
>> if (!nr_batch)
>> return;
>>
>
> Gah, that sucks. Thanks, added for 4.10.
BTW, this was added right before inclusion, all the previously posted
versions were not broken in this way. So thanks for spotting this!
--
Jens Axboe
Re: [PATCH] Revert "Btrfs: don't delay inode ref updates during log, replay"
Whoops, the [PATCH] line should've specified more clearly: This only applies to linux-stable, 3.12.y. Sorry for any confusion. -Jeff On 12/2/16 10:21 PM, Jeff Mahoney wrote: > This reverts commit 644d10716875b24388680925d6c7502420987bfe. > > The original patch for mainline, 6f8960541b1 (Btrfs: don't delay > inode ref updates during log replay) lists 1d52c78afbb (Btrfs: try > not to ENOSPC on log replay) as the only pre-3.18 dependency, but it > also depends on 67de11769bd (Btrfs: introduce the delayed inode ref > deletion for the single link inode), which was introduced in 3.14 > and isn't in 3.12.y. > > The -stable commit added the check to btrfs_delayed_update_inode, > which may look similar to btrfs_delayed_delete_inode_ref, but it's > only superficial. The tops of both functions handle typical > delayed node boilerplate. The upshot is that the patch is harmless > since the caller already checks to see if we're doing log recovery, > so we're not breaking anything. It should be reverted because it > makes it appear as if this issue was fixed for users who did > backport 67de11769bd, when it is not. > > Signed-off-by: Jeff Mahoney > --- > fs/btrfs/delayed-inode.c | 8 > 1 file changed, 8 deletions(-) > > diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c > index 34f33e1..269ac79 100644 > --- a/fs/btrfs/delayed-inode.c > +++ b/fs/btrfs/delayed-inode.c > @@ -1805,14 +1805,6 @@ int btrfs_delayed_update_inode(struct > btrfs_trans_handle *trans, > struct btrfs_delayed_node *delayed_node; > int ret = 0; > > - /* > - * we don't do delayed inode updates during log recovery because it > - * leads to enospc problems. This means we also can't do > - * delayed inode refs > - */ > - if (BTRFS_I(inode)->root->fs_info->log_root_recovering) > - return -EAGAIN; > - > delayed_node = btrfs_get_or_create_delayed_node(inode); > if (IS_ERR(delayed_node)) > return PTR_ERR(delayed_node); > -- Jeff Mahoney SUSE Labs signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group
On Fri, Nov 25, 2016 at 7:34 AM, Vincent Guittot wrote: > > find_idlest_group() only compares the runnable_load_avg when looking for > the least loaded group. But on fork intensive use case like hackbench > where tasks blocked quickly after the fork, this can lead to selecting the > same CPU instead of other CPUs, which have similar runnable load but a > lower load_avg. > > When the runnable_load_avg of 2 CPUs are close, we now take into account > the amount of blocked load as a 2nd selection factor. There is now 3 zones > for the runnable_load of the rq: > -[0 .. (runnable_load - imbalance)] : Select the new rq which has > significantly less runnable_load > -](runnable_load - imbalance) .. (runnable_load + imbalance)[ : The > runnable load are close so we use load_avg to chose between the 2 rq > -[(runnable_load + imbalance) .. ULONG_MAX] : Keep the current rq which > has significantly less runnable_load > For background, is this from the "A decade of wasted cores" paper's patches? What's the expected typical gain? Thanks, Brendan
[PATCH] Revert "Btrfs: don't delay inode ref updates during log, replay"
This reverts commit 644d10716875b24388680925d6c7502420987bfe. The original patch for mainline, 6f8960541b1 (Btrfs: don't delay inode ref updates during log replay) lists 1d52c78afbb (Btrfs: try not to ENOSPC on log replay) as the only pre-3.18 dependency, but it also depends on 67de11769bd (Btrfs: introduce the delayed inode ref deletion for the single link inode), which was introduced in 3.14 and isn't in 3.12.y. The -stable commit added the check to btrfs_delayed_update_inode, which may look similar to btrfs_delayed_delete_inode_ref, but it's only superficial. The tops of both functions handle typical delayed node boilerplate. The upshot is that the patch is harmless since the caller already checks to see if we're doing log recovery, so we're not breaking anything. It should be reverted because it makes it appear as if this issue was fixed for users who did backport 67de11769bd, when it is not. Signed-off-by: Jeff Mahoney --- fs/btrfs/delayed-inode.c | 8 1 file changed, 8 deletions(-) diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c index 34f33e1..269ac79 100644 --- a/fs/btrfs/delayed-inode.c +++ b/fs/btrfs/delayed-inode.c @@ -1805,14 +1805,6 @@ int btrfs_delayed_update_inode(struct btrfs_trans_handle *trans, struct btrfs_delayed_node *delayed_node; int ret = 0; - /* -* we don't do delayed inode updates during log recovery because it -* leads to enospc problems. This means we also can't do -* delayed inode refs -*/ - if (BTRFS_I(inode)->root->fs_info->log_root_recovering) - return -EAGAIN; - delayed_node = btrfs_get_or_create_delayed_node(inode); if (IS_ERR(delayed_node)) return PTR_ERR(delayed_node); -- 2.7.1 -- Jeff Mahoney SUSE Labs
Re: [PATCH] blk-stat: fix a typo
On 12/02/2016 06:13 PM, Shaohua Li wrote:
> Signed-off-by: Shaohua Li
> ---
> block/blk-stat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block/blk-stat.c b/block/blk-stat.c
> index 688c958..4d01185 100644
> --- a/block/blk-stat.c
> +++ b/block/blk-stat.c
> @@ -12,7 +12,7 @@
> static void blk_stat_flush_batch(struct blk_rq_stat *stat)
> {
> const s32 nr_batch = READ_ONCE(stat->nr_batch);
> - const s32 nr_samples = READ_ONCE(stat->nr_batch);
> + const s32 nr_samples = READ_ONCE(stat->nr_samples);
>
> if (!nr_batch)
> return;
>
Gah, that sucks. Thanks, added for 4.10.
--
Jens Axboe
Re: [mnt] 81e3bb1b6f: BUG:sleeping_function_called_from_invalid_context_at_fs/dcache.c
kernel test robot writes:
> FYI, we noticed the following commit:
>
> commit: 81e3bb1b6f6d84d47e773f34a14b0955e528c6eb ("mnt: Tuck mounts under
> others instead of creating shadow/side mounts.")
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> for-testing
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G
>
> caused below changes:
Bah. Obvious in hind site...
Thank you testing robot,
Eric
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
On 12/03/2016 03:41 AM, Masahiro Yamada wrote: > Hi Rob, Hi! > 2016-12-03 1:26 GMT+09:00 Rob Herring : > >>> >>> >>> (Plan A) >>> "denali,socfpga-nand" (for Altera SOCFPGA variant) >>> "denali,uniphier-nand-v1" (for old Socionext UniPhier family >>> variant) >>> "denali,uniphier-nand-v2" (for new Socionext UniPhier family >>> variant) >>> >>> (Plan B) >>> "altera,denali-nand"(for Altera SOCFPGA variant) >>> "socionext,denali-nand-v5a" (for old Socionext UniPhier family >>> variant) >>> "socionext,denali-nand-v5b" (for new Socionext UniPhier family >>> variant) > >> Let the Altera folks worry about their stuff. At least for soft IP in >> FPGA, it's a bit of a special case. The old string can remain as bad >> as it is. > > > Hmm, I am not sure if this IP would fit in FPGA > (to use it along with NIOS-II?) > > (even if it happened, nothing of this IP would be customizable on users' side. > When buying the IP, SoC vendors submit a list of desired features. > Denali (now Cadence) generates the RTL according to the configuration sheet. > The function is fixed at this point. So, generic compatible would be > useless anyway.) > > > If we are talking about SOCFPGA, > SOCFPGA is not only FPGA. Rather "SOC" + "FPGA". > It consists of two parts: > [1] SOC part (Cortex-A9 + various hard-wired peripherals such UART, > USB, SD, NAND, ...) > [2] FPGA part (User design logic) > > The Denali NAND controller is included in [1]. > So, as far as we talk about the Denali on SOCFPGA, > it is as hard-wired as Intel, Socionext's ones. That's correct, the Denali NAND IP in altera socfpga is a hardware block. You can make it available to the fabric too, but by default it's used by the ARM part of the chip, so for this discussion, you can forget that the FPGA part exists altogether. I would be in favor of plan B, since it seems to be the more often taken approach. A nice example is ci-hdrc: $ git grep compatible drivers/usb/chipidea/ >> I simply would do "socionext,uniphier-v5b-nand" (and v5a). >> The fact that it is denali is part of the documentation. >> > > Let me think about this. > > Socionext bought two version of Denali IP, > and we are now re-using the newer one (v5b) for several SoCs. > Socionext has some more product lines other than Uniphier SoC family, > perhaps wider re-use might happen in the future. > > At first, I included "uniphier" in compatible, but I am still wondering > if such a specific string is good or not. > > Also, comments from Altera engineers are appreciated. Adding a few more on Cc -- Best regards, Marek Vasut
Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
Hi Rob, 2016-12-03 1:26 GMT+09:00 Rob Herring : >> >> >> (Plan A) >> "denali,socfpga-nand" (for Altera SOCFPGA variant) >> "denali,uniphier-nand-v1" (for old Socionext UniPhier family variant) >> "denali,uniphier-nand-v2" (for new Socionext UniPhier family variant) >> >> (Plan B) >> "altera,denali-nand"(for Altera SOCFPGA variant) >> "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant) >> "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant) > Let the Altera folks worry about their stuff. At least for soft IP in > FPGA, it's a bit of a special case. The old string can remain as bad > as it is. Hmm, I am not sure if this IP would fit in FPGA (to use it along with NIOS-II?) (even if it happened, nothing of this IP would be customizable on users' side. When buying the IP, SoC vendors submit a list of desired features. Denali (now Cadence) generates the RTL according to the configuration sheet. The function is fixed at this point. So, generic compatible would be useless anyway.) If we are talking about SOCFPGA, SOCFPGA is not only FPGA. Rather "SOC" + "FPGA". It consists of two parts: [1] SOC part (Cortex-A9 + various hard-wired peripherals such UART, USB, SD, NAND, ...) [2] FPGA part (User design logic) The Denali NAND controller is included in [1]. So, as far as we talk about the Denali on SOCFPGA, it is as hard-wired as Intel, Socionext's ones. > I simply would do "socionext,uniphier-v5b-nand" (and v5a). > The fact that it is denali is part of the documentation. > Let me think about this. Socionext bought two version of Denali IP, and we are now re-using the newer one (v5b) for several SoCs. Socionext has some more product lines other than Uniphier SoC family, perhaps wider re-use might happen in the future. At first, I included "uniphier" in compatible, but I am still wondering if such a specific string is good or not. Also, comments from Altera engineers are appreciated. -- Best Regards Masahiro Yamada
[PATCH linux-firmware 1/2] WHENCE: Add new amdgpu firmware
Missed in commit 9c011a98a94ab1320f6c073ae500ae4dc33ce838. Signed-off-by: Ben Hutchings --- Please run 'make check' before committing to catch this sort of error. Ben. WHENCE | 2 ++ 1 file changed, 2 insertions(+) diff --git a/WHENCE b/WHENCE index e731c68f309d..a7fc762dff64 100644 --- a/WHENCE +++ b/WHENCE @@ -1837,6 +1837,7 @@ Licence: Redistributable. See LICENSE.radeon for details. Driver: amdgpu - AMD Radeon File: amdgpu/topaz_ce.bin +File: amdgpu/topaz_k_smc.bin File: amdgpu/topaz_mc.bin File: amdgpu/topaz_me.bin File: amdgpu/topaz_mec2.bin @@ -1847,6 +1848,7 @@ File: amdgpu/topaz_sdma1.bin File: amdgpu/topaz_sdma.bin File: amdgpu/topaz_smc.bin File: amdgpu/tonga_ce.bin +File: amdgpu/tonga_k_smc.bin File: amdgpu/tonga_mc.bin File: amdgpu/tonga_me.bin File: amdgpu/tonga_mec2.bin signature.asc Description: Digital signature
Re: [PATCH] net: wireless: realtek: constify rate_control_ops structures
On Sat, Dec 3, 2016 at 2:09 AM, Larry Finger wrote:
> On 12/02/2016 03:50 AM, Bhumika Goyal wrote:
>>
>> The structures rate_control_ops are only passed as an argument to the
>> functions ieee80211_rate_control_{register/unregister}. This argument is
>> of type const, so rate_control_ops having this property can also be
>> declared as const.
>> Done using Coccinelle:
>>
>> @r1 disable optional_qualifier @
>> identifier i;
>> position p;
>> @@
>> static struct rate_control_ops i@p = {...};
>>
>> @ok1@
>> identifier r1.i;
>> position p;
>> @@
>> ieee80211_rate_control_register(&i@p)
>>
>> @ok2@
>> identifier r1.i;
>> position p;
>> @@
>> ieee80211_rate_control_unregister(&i@p)
>>
>> @bad@
>> position p!={r1.p,ok1.p,ok2.p};
>> identifier r1.i;
>> @@
>> i@p
>>
>> @depends on !bad disable optional_qualifier@
>> identifier r1.i;
>> @@
>> static
>> +const
>> struct rate_control_ops i={...};
>>
>> @depends on !bad disable optional_qualifier@
>> identifier r1.i;
>> @@
>> +const
>> struct rate_control_ops i;
>>
>> File size before:
>>textdata bss dec hex filename
>>1991 104 02095 82f wireless/realtek/rtlwifi/rc.o
>>
>> File size after:
>>textdata bss dec hex filename
>>2095 0 02095 wireless/realtek/rtlwifi/rc.o
>>
>> Signed-off-by: Bhumika Goyal
>> ---
>> drivers/net/wireless/realtek/rtlwifi/rc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c
>> b/drivers/net/wireless/realtek/rtlwifi/rc.c
>> index ce8621a..107c13c 100644
>> --- a/drivers/net/wireless/realtek/rtlwifi/rc.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
>> @@ -284,7 +284,7 @@ static void rtl_rate_free_sta(void *rtlpriv,
>> kfree(rate_priv);
>> }
>>
>> -static struct rate_control_ops rtl_rate_ops = {
>> +static const struct rate_control_ops rtl_rate_ops = {
>> .name = "rtl_rc",
>> .alloc = rtl_rate_alloc,
>> .free = rtl_rate_free,
>>
>
> The content of your patch is OK; however, your subject is not. By
> convention, "net: wireless: realtek:" is assumed. We do, however, include
> "rtlwifi:" to indicate which part of drivers/net/wireless/realtek/ is
> referenced.
>
Ok, I will send a v2 with the correct subject. Thanks for the input.
Thanks,
Bhumika
> NACK
>
> Larry
>
[PATCH linux-firmware 2/2] WHENCE: Add new snd_intel_sst_core
Missed in commit 128052ee31f7023b07c5d65c2212abce6e52076c. Signed-off-by: Ben Hutchings --- Please run 'make check' before committing to catch this sort of error. Ben. WHENCE | 1 + 1 file changed, 1 insertion(+) diff --git a/WHENCE b/WHENCE index a7fc762dff64..d021c40c5169 100644 --- a/WHENCE +++ b/WHENCE @@ -3039,6 +3039,7 @@ License: Redistributable. See LICENCE.IntcSST2 for details Driver: snd_intel_sst_core File: intel/fw_sst_0f28.bin +File: intel/fw_sst_0f28_ssp0.bin License: Redistributable. See LICENCE.fw_sst_0f28 for details signature.asc Description: Digital signature
[mnt] 81e3bb1b6f: BUG:sleeping_function_called_from_invalid_context_at_fs/dcache.c
FYI, we noticed the following commit:
commit: 81e3bb1b6f6d84d47e773f34a14b0955e528c6eb ("mnt: Tuck mounts under
others instead of creating shadow/side mounts.")
https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
for-testing
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G
caused below changes:
+--+++
| | f84df2a6f2
| 81e3bb1b6f |
+--+++
| boot_successes | 14
| 3 |
| boot_failures| 0
| 13 |
| BUG:sleeping_function_called_from_invalid_context_at_fs/dcache.c | 0
| 12 |
| calltrace:SyS_mount | 0
| 12 |
| invoked_oom-killer:gfp_mask=0x | 0
| 1 |
| Mem-Info | 0
| 1 |
+--+++
[ 11.335778] rc.local[3455]:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/lkp/lkp/src/bin
Starting Login Service...
[ 12.095031] random: fast init done
[ 12.107647] BUG: sleeping function called from invalid context at
fs/dcache.c:757
[ 12.109075] in_atomic(): 1, irqs_disabled(): 0, pid: 3475, name: mount
[ 12.109967] 4 locks held by mount/3475:
[ 12.110636] #0:
[ 12.110834] (
&sb->s_type->i_mutex_key
[ 12.111598] #2
){++}
[ 12.112265] , at:
[ 12.112834] [] lock_mount+0x2f/0xf6
[ 12.113591] #1:
[ 12.113786] (
namespace_sem
[ 12.122117] ){++}
, at:
[ 12.122794] [] lock_mount+0x5b/0xf6
[ 12.123608] #2:
[ 12.123803] (
mount_lock
[ 12.124468] ){+.+...}
, at:
[ 12.125163] [] attach_recursive_mnt+0xb8/0x2c1
[ 12.126030] #3:
[ 12.126242] (
mount_lock
[ 12.126898] #2
){+.+...}
[ 12.127565] , at:
[ 12.128142] [] graft_tree+0x54/0x56
[ 12.128894] CPU: 0 PID: 3475 Comm: mount Not tainted
4.9.0-rc6-5-g81e3bb1 #1
[ 12.130158] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[ 12.131500] c90002b17d18 8158eef7 88003e1cc040
02f5
[ 12.132936] c90002b17d40 810cbb24 82226d44
02f5
[ 12.134378] c90002b17d68 810cbbae
88003376a7b8
[ 12.135825] Call Trace:
[ 12.136385] [] dump_stack+0x86/0xc0
[ 12.137151] [] ___might_sleep+0x1fa/0x20d
[ 12.137941] [] __might_sleep+0x77/0x7e
[ 12.138723] [] dput+0x38/0x357
[ 12.139457] [] path_put+0x16/0x21
[ 12.140204] [] mnt_change_mountpoint+0xc2/0xcf
[ 12.141019] [] attach_recursive_mnt+0x1eb/0x2c1
[ 12.141853] [] graft_tree+0x54/0x56
[ 12.142613] [] do_add_mount+0xab/0xca
[ 12.143393] [] do_mount+0xaa7/0xb06
[ 12.144162] [] ? copy_mount_options+0x2e/0x117
[ 12.144975] [] SyS_mount+0x77/0x9f
[ 12.145735] [] entry_SYSCALL_64_fastpath+0x1f/0xc2
To reproduce:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.9.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV
[PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues
The use of any kind of wait queue is an overkill for pcpu-rwsems.
While one option would be to use the less heavy simple (swait)
flavor, this is still too much for what pcpu-rwsems needs. For one,
we do not care about any sort of queuing in that the only (rare) time
writers (and readers, for that matter) are queued is when trying to
acquire the regular contended rw_sem. There cannot be any further
queuing as writers are serialized by the rw_sem in the first place.
This patch, therefore, implements custom wait/wake, with an rcu-aware
writer task pointer. The only time this is !nil is when a writer is
determining if it is going to block, and reset as soon as we know that
the percpu_down_write() call has succeeded. All this is obviously done while
holding the regular rw_sem. As such, we can avoid the queue handling and
locking overhead (although we currently end up taking the waitqueue
spinlock fastpath, so it wouldn't be a very big an impact).
Signed-off-by: Davidlohr Bueso
---
include/linux/percpu-rwsem.h | 5 ++---
kernel/locking/percpu-rwsem.c | 26 +-
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h
index 5b2e6159b744..9942b7e8bde8 100644
--- a/include/linux/percpu-rwsem.h
+++ b/include/linux/percpu-rwsem.h
@@ -4,7 +4,6 @@
#include
#include
#include
-#include
#include
#include
@@ -12,7 +11,7 @@ struct percpu_rw_semaphore {
struct rcu_sync rss;
unsigned int __percpu *read_count;
struct rw_semaphore rw_sem;
- wait_queue_head_t writer;
+ struct task_struct *writer; /* blocked writer */
int readers_block;
};
@@ -22,7 +21,7 @@ static struct percpu_rw_semaphore name = {
\
.rss = __RCU_SYNC_INITIALIZER(name.rss, RCU_SCHED_SYNC),\
.read_count = &__percpu_rwsem_rc_##name,\
.rw_sem = __RWSEM_INITIALIZER(name.rw_sem), \
- .writer = __WAIT_QUEUE_HEAD_INITIALIZER(name.writer), \
+ .writer = NULL, \
}
extern int __percpu_down_read(struct percpu_rw_semaphore *, int);
diff --git a/kernel/locking/percpu-rwsem.c b/kernel/locking/percpu-rwsem.c
index ce182599cf2e..7856a77396d3 100644
--- a/kernel/locking/percpu-rwsem.c
+++ b/kernel/locking/percpu-rwsem.c
@@ -1,7 +1,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -18,7 +17,7 @@ int __percpu_init_rwsem(struct percpu_rw_semaphore *sem,
/* ->rw_sem represents the whole percpu_rw_semaphore for lockdep */
rcu_sync_init(&sem->rss, RCU_SCHED_SYNC);
__init_rwsem(&sem->rw_sem, name, rwsem_key);
- init_waitqueue_head(&sem->writer);
+ sem->writer = NULL;
sem->readers_block = 0;
return 0;
}
@@ -94,6 +93,8 @@ EXPORT_SYMBOL_GPL(__percpu_down_read);
void __percpu_up_read(struct percpu_rw_semaphore *sem)
{
+ struct task_struct *writer;
+
smp_mb(); /* B matches C */
/*
* In other words, if they see our decrement (presumably to aggregate
@@ -102,8 +103,13 @@ void __percpu_up_read(struct percpu_rw_semaphore *sem)
*/
__this_cpu_dec(*sem->read_count);
+ rcu_read_lock();
+ writer = rcu_dereference(sem->writer);
+
/* Prod writer to recheck readers_active */
- wake_up(&sem->writer);
+ if (writer)
+ wake_up_process(writer);
+ rcu_read_unlock();
}
EXPORT_SYMBOL_GPL(__percpu_up_read);
@@ -159,8 +165,18 @@ void percpu_down_write(struct percpu_rw_semaphore *sem)
* will wait for them.
*/
- /* Wait for all now active readers to complete. */
- wait_event(sem->writer, readers_active_check(sem));
+ WRITE_ONCE(sem->writer, current);
+ for (;;) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
+
+ if (readers_active_check(sem))
+ break;
+
+ schedule();
+ }
+
+ rcu_assign_pointer(sem->writer, NULL);
+ __set_current_state(TASK_RUNNING);
}
EXPORT_SYMBOL_GPL(percpu_down_write);
--
2.6.6
Re: [PATCH v9 07/16] drivers: acpi: implement acpi_dma_configure
On Fri, Dec 2, 2016 at 4:38 PM, Lorenzo Pieralisi
wrote:
> Rafael, Mark, Suravee,
>
> On Mon, Nov 21, 2016 at 10:01:39AM +, Lorenzo Pieralisi wrote:
>> On DT based systems, the of_dma_configure() API implements DMA
>> configuration for a given device. On ACPI systems an API equivalent to
>> of_dma_configure() is missing which implies that it is currently not
>> possible to set-up DMA operations for devices through the ACPI generic
>> kernel layer.
>>
>> This patch fills the gap by introducing acpi_dma_configure/deconfigure()
>> calls that for now are just wrappers around arch_setup_dma_ops() and
>> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
>> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
>>
>> Since acpi_dma_configure() is used to configure DMA operations, the
>> function initializes the dma/coherent_dma masks to sane default values
>> if the current masks are uninitialized (also to keep the default values
>> consistent with DT systems) to make sure the device has a complete
>> default DMA set-up.
>
> I spotted a niggle that unfortunately was hard to spot (and should not
> be a problem per se but better safe than sorry) and I am not comfortable
> with it.
>
> Following commit d0562674838c ("ACPI / scan: Parse _CCA and setup
> device coherency") in acpi_bind_one() we check if the acpi_device
> associated with a device just added supports DMA, first it was
> done with acpi_check_dma() and then commit 1831eff876bd ("device
> property: ACPI: Make use of the new DMA Attribute APIs") changed
> it to acpi_get_dma_attr().
>
> The subsequent check (attr != DEV_DMA_NOT_SUPPORTED) is always true
> on _any_ acpi device we pass to acpi_bind_one() on x86, which was
> fine because we used it to call arch_setup_dma_ops(), which is a nop
> on x86. On ARM64 a _CCA method is required to define if a device
> supports DMA so (attr != DEV_DMA_NOT_SUPPORTED) may well be false.
>
> Now, acpi_bind_one() is used to bind an acpi_device to its physical
> node also for pseudo-devices like cpus and memory nodes. For those
> objects, on x86, attr will always be != DEV_DMA_NOT_SUPPORTED.
>
> So far so good, because on x86 arch_setup_dma_ops() is empty code.
>
> With this patch, I use the (attr != DEV_DMA_NOT_SUPPORTED) check
> to call acpi_dma_configure() which is basically a nop on x86 except
> that it sets up the dma_mask/coherent_dma_mask to a sane default value
> (after all we are setting up DMA for the device so it makes sense to
> initialize the masks there if they were unset since we are configuring
> DMA for the device in question) for the given device.
>
> Problem is, as per the explanation above, we are also setting the
> default dma masks for pseudo-devices (eg CPUs) that were previously
> untouched, it should not be a problem per-se but I am not comfortable
> with that, honestly it does not make much sense.
>
> An easy "fix" would be to move the default dma masks initialization out
> of acpi_dma_configure() (as it was in previous patch versions of this
> series - I moved it to acpi_dma_configure() just a consolidation point
> for initializing the masks instead of scattering them in every
> acpi_dma_configure caller) I can send this as a fix-up patch to Joerg if
> we think that's the right thing to do (or I can send it to Rafael later
> when the code is in the merged depending on the timing) just let me
> know please.
Why can't arch_setup_dma_ops() set those masks too?
Thanks,
Rafael
[PATCH] net: ethernet: ti: cpdma: use desc_read in chan_process instead of raw read
There is desc_read() macros to read desc fields, so no need to
use __raw_readl();
Signed-off-by: Ivan Khoronzhuk
---
Based on net-next/master
drivers/net/ethernet/ti/davinci_cpdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index c776e45..d96dca5 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -1132,7 +1132,7 @@ static int __cpdma_chan_process(struct cpdma_chan *chan)
}
desc_dma = desc_phys(pool, desc);
- status = __raw_readl(&desc->hw_mode);
+ status = desc_read(desc, hw_mode);
outlen = status & 0x7ff;
if (status & CPDMA_DESC_OWNER) {
chan->stats.busy_dequeue++;
--
2.7.4
Re: [PATCH v2] ACPI: Document _OSI and _REV for Linux BIOS writers
On Friday, December 02, 2016 09:14:48 PM Lukas Wunner wrote: > On Wed, Nov 30, 2016 at 11:00:30PM -0500, Len Brown wrote: > > From: Len Brown > > > > Based on a recent session at the Linux Plumber's Conference, > > we need to be more clear about how a BIOS should use _OSI > > to properly support Linux. > > > > Signed-off-by: Len Brown > > Reviewed-by: Lukas Wunner Applied. Thanks, Rafael
Re: include/linux/rtmutex.h: NOOP rt_mutex_destroy if !CONFIG_DEBUG_RT_MUTEXES
This seems consistent with the spirit of DEBUG_MUTEX in non-RT kernels,
so hopefully this is acceptable to the RT maintainers.
Reviewed-by: Andy Ritger
Thanks,
- Andy
On Tue, Oct 25, 2016 at 07:03:51PM -0700, Alex Goins wrote:
> mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. When
> mutex_destroy is indirectly used by non-GPL kernel modules that use inline
> functions such as reservation_object_fini(), users can use a kernel with
> DEBUG_MUTEX disabled to avoid a dependence on the GPL-only symbol
> mutex_destroy.
>
> The RT Linux patches replace mutex_destroy with rt_mutex_destroy.
> Currently, rt_mutex_destroy is GPL_ONLY irrespective of whether mutex
> debugging is enabled.
>
> This patch aligns rt_mutex_destroy with mutex_destroy by using the same
> no-op inline technique. This allows non-GPL modules to access the same
> functionality with RT Linux as with regular Linux.
>
> Signed-off-by: Alex Goins
> ---
> include/linux/rtmutex.h | 7 ++-
> kernel/locking/rtmutex.c | 5 ++---
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/rtmutex.h b/include/linux/rtmutex.h
> index 1abba5c..741e844 100644
> --- a/include/linux/rtmutex.h
> +++ b/include/linux/rtmutex.h
> @@ -56,6 +56,12 @@ struct hrtimer_sleeper;
> #endif
>
> #ifdef CONFIG_DEBUG_RT_MUTEXES
> + extern void rt_mutex_destroy(struct rt_mutex *lock);
> +#else
> + static inline void rt_mutex_destroy(struct rt_mutex *lock) {}
> +#endif
> +
> +#ifdef CONFIG_DEBUG_RT_MUTEXES
> # define __DEBUG_RT_MUTEX_INITIALIZER(mutexname) \
> , .name = #mutexname, .file = __FILE__, .line = __LINE__
> # define rt_mutex_init(mutex)__rt_mutex_init(mutex,
> __func__)
> @@ -87,7 +93,6 @@ static inline int rt_mutex_is_locked(struct rt_mutex *lock)
> }
>
> extern void __rt_mutex_init(struct rt_mutex *lock, const char *name);
> -extern void rt_mutex_destroy(struct rt_mutex *lock);
>
> extern void rt_mutex_lock(struct rt_mutex *lock);
> extern int rt_mutex_lock_interruptible(struct rt_mutex *lock);
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index 1ec0f48..8d3a80e 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -1513,6 +1513,7 @@ bool __sched rt_mutex_futex_unlock(struct rt_mutex
> *lock,
> return rt_mutex_slowunlock(lock, wqh);
> }
>
> +#ifdef CONFIG_DEBUG_RT_MUTEXES
> /**
> * rt_mutex_destroy - mark a mutex unusable
> * @lock: the mutex to be destroyed
> @@ -1524,12 +1525,10 @@ bool __sched rt_mutex_futex_unlock(struct rt_mutex
> *lock,
> void rt_mutex_destroy(struct rt_mutex *lock)
> {
> WARN_ON(rt_mutex_is_locked(lock));
> -#ifdef CONFIG_DEBUG_RT_MUTEXES
> lock->magic = NULL;
> -#endif
> }
> -
> EXPORT_SYMBOL_GPL(rt_mutex_destroy);
> +#endif
>
> /**
> * __rt_mutex_init - initialize the rt lock
Re: [PATCH] drm/i915: Remove instructions to file a bug report.
On Fri, Dec 2, 2016 at 5:03 PM, Matt Turner wrote: > From these instructions, users assume that /sys/class/drm/card0/error > contains all the information a developer needs to diagnose and fix a GPU > hang. > > In fact it doesn't, and we have no tools for solving them (other than > stabbing in the dark). Most of the time the error state itself isn't > even useful because it just shows a hang on a PIPE_CONTROL or similar. > > Until a time when the error state contains enough information to > actually solve a hang, stop telling users to file unsolvable bugs, and > instead rely on users who know where and how to file a good bug report > to find their own way there. > > Signed-off-by: Matt Turner > --- > Maybe now's a good time to discuss what *would* be useful to put in the > error state for debugging hangs. The currently executing shader program > would be a great place to start. Looks like Ben had a patch: https://cgit.freedesktop.org/~bwidawsk/drm-intel/commit/?h=extra_error_objs&id=711da2570cd3302d0cb9f2489a101e4a7c966a6c
Re: [PATCH] clk: uniphier: Fix build with gcc-4.4.
Hi Vinson,
2016-12-03 9:37 GMT+09:00 Vinson Lee :
> gcc-4.4 has issues with anonymous unions in initializers.
>
> CC drivers/clk/uniphier/clk-uniphier-sys.o
> drivers/clk/uniphier/clk-uniphier-sys.c:45: error: unknown field ‘factor’
> specified in initializer
>
> Fixes: 1574d5722636 ("clk: uniphier: remove unneeded member name for union")
> Signed-off-by: Vinson Lee
This driver has COMPILE_TEST option, but kbuild test robot
did not mention about this.
This is a bad way of fixing, I think.
(what if a new member is inserted before the union in the future?)
Rather, please revert the bad commit.
> .name = "sd" #ch "-sel",\
> .type = UNIPHIER_CLK_TYPE_MUX, \
> .idx = -1, \
> - .mux = {\
> + { .mux = { \
> .parent_names = { \
> "sd-44m", \
> "sd-33m", \
> @@ -63,7 +63,7 @@
> 0x1200, \
> 0x1300, \
> }, \
> - }, \
> + } },\
> }, \
No, please do not do this.
--
Best Regards
Masahiro Yamada
Re: [PATCH net-next] liquidio: 'imply' ptp instead of 'select'
Hi Arnd, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Arnd-Bergmann/liquidio-imply-ptp-instead-of-select/20161203-084019 config: x86_64-allmodconfig compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: make ARCH=x86_64 allmodconfig make ARCH=x86_64 All errors (new ones prefixed by >>): >> drivers/net/ethernet/cavium/Kconfig:81: syntax error >> drivers/net/ethernet/cavium/Kconfig:80: unknown option "imply" make[2]: *** [allmodconfig] Error 1 make[1]: *** [allmodconfig] Error 2 make: *** [sub-make] Error 2 -- >> drivers/net/ethernet/cavium/Kconfig:81: syntax error >> drivers/net/ethernet/cavium/Kconfig:80: unknown option "imply" make[2]: *** [oldconfig] Error 1 make[1]: *** [oldconfig] Error 2 make: *** [sub-make] Error 2 -- >> drivers/net/ethernet/cavium/Kconfig:81: syntax error >> drivers/net/ethernet/cavium/Kconfig:80: unknown option "imply" make[2]: *** [olddefconfig] Error 1 make[2]: Target 'oldnoconfig' not remade because of errors. make[1]: *** [oldnoconfig] Error 2 make: *** [sub-make] Error 2 vim +81 drivers/net/ethernet/cavium/Kconfig d07a147f David Daney 2016-03-14 74 port on Cavium Networks' Octeon CN57XX, CN56XX, CN55XX, d07a147f David Daney 2016-03-14 75 CN54XX, CN52XX, and CN6XXX chips. d07a147f David Daney 2016-03-14 76 111fc64a Raghu Vatsavayi 2016-11-28 77 config LIQUIDIO_VF 111fc64a Raghu Vatsavayi 2016-11-28 78 tristate "Cavium LiquidIO VF support" 111fc64a Raghu Vatsavayi 2016-11-28 79 depends on 64BIT && PCI_MSI 2d6e65ca Arnd Bergmann 2016-12-03 @80 imply PTP_1588_CLOCK 111fc64a Raghu Vatsavayi 2016-11-28 @81 ---help--- 111fc64a Raghu Vatsavayi 2016-11-28 82 This driver supports Cavium LiquidIO Intelligent Server Adapter 111fc64a Raghu Vatsavayi 2016-11-28 83 based on CN23XX chips. 111fc64a Raghu Vatsavayi 2016-11-28 84 :: The code at line 81 was first introduced by commit :: 111fc64a237f231bc2d3187bdf8358eb7966e6a9 liquidio CN23XX: VF registration :: TO: Raghu Vatsavayi :: CC: David S. Miller --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH 20/22] staging: lustre: osc: set lock data for readahead lock
From: Jinshan Xiong
If osc_io_readahead() finds a lock that belongs to the previous
instance of osc_object, the lock data pointer will be null. It has
to instantiate with new instance otherwise those pages won't be
destroyed at lock cancel, and then finally hit the assertion in
osc_req_attr_set().
This patch revised dlmlock_at_pgoff() to call osc_match_base() to
find caching locks for readahead. And new osc_object will be set
to the lock if it doesn't have one yet.
Signed-off-by: Jinshan Xiong
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8005
Reviewed-on: http://review.whamcloud.com/19453
Reviewed-by: Bobi Jam
Reviewed-by: John L. Hammond
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/osc/osc_io.c |1 +
drivers/staging/lustre/lustre/osc/osc_lock.c|7 +--
drivers/staging/lustre/lustre/osc/osc_request.c | 49 ++
3 files changed, 18 insertions(+), 39 deletions(-)
diff --git a/drivers/staging/lustre/lustre/osc/osc_io.c
b/drivers/staging/lustre/lustre/osc/osc_io.c
index 369761f..d96f4f2 100644
--- a/drivers/staging/lustre/lustre/osc/osc_io.c
+++ b/drivers/staging/lustre/lustre/osc/osc_io.c
@@ -88,6 +88,7 @@ static int osc_io_read_ahead(const struct lu_env *env,
dlmlock = osc_dlmlock_at_pgoff(env, osc, start, 0);
if (dlmlock) {
+ LASSERT(dlmlock->l_ast_data == osc);
if (dlmlock->l_req_mode != LCK_PR) {
struct lustre_handle lockh;
diff --git a/drivers/staging/lustre/lustre/osc/osc_lock.c
b/drivers/staging/lustre/lustre/osc/osc_lock.c
index 130460d..001fe75 100644
--- a/drivers/staging/lustre/lustre/osc/osc_lock.c
+++ b/drivers/staging/lustre/lustre/osc/osc_lock.c
@@ -1205,10 +1205,9 @@ struct ldlm_lock *osc_dlmlock_at_pgoff(const struct
lu_env *env,
* with a uniq gid and it conflicts with all other lock modes too
*/
again:
- mode = ldlm_lock_match(osc_export(obj)->exp_obd->obd_namespace,
- flags, resname, LDLM_EXTENT, policy,
- LCK_PR | LCK_PW | LCK_GROUP, &lockh,
- dap_flags & OSC_DAP_FL_CANCELING);
+ mode = osc_match_base(osc_export(obj), resname, LDLM_EXTENT, policy,
+ LCK_PR | LCK_PW | LCK_GROUP, &flags, obj, &lockh,
+ dap_flags & OSC_DAP_FL_CANCELING);
if (mode != 0) {
lock = ldlm_handle2lock(&lockh);
/* RACE: the lock is cancelled so let's try again */
diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c
b/drivers/staging/lustre/lustre/osc/osc_request.c
index bc698d3..0977127 100644
--- a/drivers/staging/lustre/lustre/osc/osc_request.c
+++ b/drivers/staging/lustre/lustre/osc/osc_request.c
@@ -1813,16 +1813,11 @@ int osc_build_rpc(const struct lu_env *env, struct
client_obd *cli,
return rc;
}
-static int osc_set_lock_data_with_check(struct ldlm_lock *lock,
- struct ldlm_enqueue_info *einfo)
+static int osc_set_lock_data(struct ldlm_lock *lock, void *data)
{
- void *data = einfo->ei_cbdata;
int set = 0;
- LASSERT(lock->l_blocking_ast == einfo->ei_cb_bl);
- LASSERT(lock->l_resource->lr_type == einfo->ei_type);
- LASSERT(lock->l_completion_ast == einfo->ei_cb_cp);
- LASSERT(lock->l_glimpse_ast == einfo->ei_cb_gl);
+ LASSERT(lock);
lock_res_and_lock(lock);
@@ -1836,21 +1831,6 @@ static int osc_set_lock_data_with_check(struct ldlm_lock
*lock,
return set;
}
-static int osc_set_data_with_check(struct lustre_handle *lockh,
- struct ldlm_enqueue_info *einfo)
-{
- struct ldlm_lock *lock = ldlm_handle2lock(lockh);
- int set = 0;
-
- if (lock) {
- set = osc_set_lock_data_with_check(lock, einfo);
- LDLM_LOCK_PUT(lock);
- } else
- CERROR("lockh %p, data %p - client evicted?\n",
- lockh, einfo->ei_cbdata);
- return set;
-}
-
static int osc_enqueue_fini(struct ptlrpc_request *req,
osc_enqueue_upcall_f upcall, void *cookie,
struct lustre_handle *lockh, enum ldlm_mode mode,
@@ -2016,7 +1996,7 @@ int osc_enqueue_base(struct obd_export *exp, struct
ldlm_res_id *res_id,
ldlm_lock_decref(&lockh, mode);
LDLM_LOCK_PUT(matched);
return -ECANCELED;
- } else if (osc_set_lock_data_with_check(matched, einfo)) {
+ } else if (osc_set_lock_data(matched, einfo->ei_cbdata)) {
*flags |= LDLM_FL_LVB_READY;
/* We already have a lock, and it's referenced. */
(*upcall)(cookie, &lockh, ELDLM_LOCK_MATCHED);
@@ -2128,19 +2108,18 @@ int osc_match_base(struct obd_export *exp, struct
ldlm_res_
[PATCH 14/22] staging: lustre: obd: add callback for llog_cat_process_or_fork
From: Alexander Boyko
Currently llog_process_or_fork() is hard coded to
always pass the function pointer llog_cat_process_cb().
Change llog_cat_process_or_fork() to pass in any
function pointer which will allow us more options
for llog_cat callback routines in the future.
Signed-off-by: Alexander Boyko
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7156
Seagate-bug-id: MRP-2383
Reviewed-on: http://review.whamcloud.com/16416
Reviewed-by: Andreas Dilger
Reviewed-by: Nathaniel Clark
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/obdclass/llog_cat.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/llog_cat.c
b/drivers/staging/lustre/lustre/obdclass/llog_cat.c
index ce8e2f6..de9d01d 100644
--- a/drivers/staging/lustre/lustre/obdclass/llog_cat.c
+++ b/drivers/staging/lustre/lustre/obdclass/llog_cat.c
@@ -188,7 +188,8 @@ static int llog_cat_process_cb(const struct lu_env *env,
static int llog_cat_process_or_fork(const struct lu_env *env,
struct llog_handle *cat_llh,
- llog_cb_t cb, void *data, int startcat,
+ llog_cb_t cat_cb, llog_cb_t cb,
+ void *data, int startcat,
int startidx, bool fork)
{
struct llog_process_data d;
@@ -209,18 +210,15 @@ static int llog_cat_process_or_fork(const struct lu_env
*env,
cd.lpcd_first_idx = llh->llh_cat_idx;
cd.lpcd_last_idx = 0;
- rc = llog_process_or_fork(env, cat_llh, llog_cat_process_cb,
- &d, &cd, fork);
+ rc = llog_process_or_fork(env, cat_llh, cat_cb, &d, &cd, fork);
if (rc != 0)
return rc;
cd.lpcd_first_idx = 0;
cd.lpcd_last_idx = cat_llh->lgh_last_idx;
- rc = llog_process_or_fork(env, cat_llh, llog_cat_process_cb,
- &d, &cd, fork);
+ rc = llog_process_or_fork(env, cat_llh, cat_cb, &d, &cd, fork);
} else {
- rc = llog_process_or_fork(env, cat_llh, llog_cat_process_cb,
- &d, NULL, fork);
+ rc = llog_process_or_fork(env, cat_llh, cat_cb, &d, NULL, fork);
}
return rc;
@@ -229,7 +227,7 @@ static int llog_cat_process_or_fork(const struct lu_env
*env,
int llog_cat_process(const struct lu_env *env, struct llog_handle *cat_llh,
llog_cb_t cb, void *data, int startcat, int startidx)
{
- return llog_cat_process_or_fork(env, cat_llh, cb, data, startcat,
- startidx, false);
+ return llog_cat_process_or_fork(env, cat_llh, llog_cat_process_cb, cb,
+ data, startcat, startidx, false);
}
EXPORT_SYMBOL(llog_cat_process);
--
1.7.1
[PATCH] blk-stat: fix a typo
Signed-off-by: Shaohua Li
---
block/blk-stat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-stat.c b/block/blk-stat.c
index 688c958..4d01185 100644
--- a/block/blk-stat.c
+++ b/block/blk-stat.c
@@ -12,7 +12,7 @@
static void blk_stat_flush_batch(struct blk_rq_stat *stat)
{
const s32 nr_batch = READ_ONCE(stat->nr_batch);
- const s32 nr_samples = READ_ONCE(stat->nr_batch);
+ const s32 nr_samples = READ_ONCE(stat->nr_samples);
if (!nr_batch)
return;
--
2.9.3
Re: [PATCH] usb: dwc2: fix flags for DMA descriptor allocation in dwc2_hsotg_ep_enable
On 12/1/2016 1:02 AM, Marek Szyprowski wrote:
> dwc2_hsotg_ep_enable can be called from interrupt context, so all
> allocations should be done with GFP_ATOMIC flags. This fixes following
> issue on ARM architecture:
>
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x74/0x94)
> [] (dump_stack) from [] (__warn+0xd4/0x100)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from []
> (smp_call_function_many+0xcc/0x2a4)
> [] (smp_call_function_many) from []
> (on_each_cpu_mask+0x38/0xa8)
> [] (on_each_cpu_mask) from []
> (start_isolate_page_range+0x134/0x1b8)
> [] (start_isolate_page_range) from []
> (alloc_contig_range+0xac/0x2f8)
> [] (alloc_contig_range) from [] (cma_alloc+0xe0/0x1a8)
> [] (cma_alloc) from [] (__alloc_from_contiguous+0x38/0xe0)
> [] (__alloc_from_contiguous) from []
> (cma_allocator_alloc+0x30/0x38)
> [] (cma_allocator_alloc) from [] (__dma_alloc+0x1c0/0x2c8)
> [] (__dma_alloc) from [] (arm_dma_alloc+0x3c/0x48)
> [] (arm_dma_alloc) from []
> (dwc2_hsotg_ep_enable+0xec/0x46c)
> [] (dwc2_hsotg_ep_enable) from []
> (usb_ep_enable+0x2c/0x3c)
> [] (usb_ep_enable) from [] (ecm_set_alt+0xa8/0x154)
> [] (ecm_set_alt) from [] (composite_setup+0xd74/0x1540)
> [] (composite_setup) from []
> (dwc2_hsotg_complete_setup+0xb8/0x370)
> [] (dwc2_hsotg_complete_setup) from []
> (usb_gadget_giveback_request+0xc/0x10)
> [] (usb_gadget_giveback_request) from []
> (dwc2_hsotg_complete_request+0x78/0x128)
> [] (dwc2_hsotg_complete_request) from []
> (dwc2_hsotg_epint+0x69c/0x81c)
> [] (dwc2_hsotg_epint) from [] (dwc2_hsotg_irq+0xfc/0x748)
> [] (dwc2_hsotg_irq) from []
> (__handle_irq_event_percpu+0x58/0x140)
> [] (__handle_irq_event_percpu) from []
> (handle_irq_event_percpu+0x1c/0x58)
> [] (handle_irq_event_percpu) from []
> (handle_irq_event+0x38/0x5c)
> [] (handle_irq_event) from []
> (handle_fasteoi_irq+0xc4/0x19c)
> [] (handle_fasteoi_irq) from []
> (generic_handle_irq+0x18/0x28)
> [] (generic_handle_irq) from []
> (__handle_domain_irq+0x6c/0xe4)
> [] (__handle_domain_irq) from []
> (gic_handle_irq+0x50/0x9c)
> [] (gic_handle_irq) from [] (__irq_svc+0x6c/0xa8)
>
> Fixes: 5f54c54b0ba83 ("usb: dwc2: gadget: Add DDMA chain pointers to
> dwc2_hsotg_ep structure")
> Signed-off-by: Marek Szyprowski
> ---
> drivers/usb/dwc2/gadget.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index b95930f20d90..c55db4aa54d6 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -3753,7 +3753,7 @@ static int dwc2_hsotg_ep_enable(struct usb_ep *ep,
> hs_ep->desc_list = dma_alloc_coherent(hsotg->dev,
> MAX_DMA_DESC_NUM_GENERIC *
> sizeof(struct dwc2_dma_desc),
> - &hs_ep->desc_list_dma, GFP_KERNEL);
> + &hs_ep->desc_list_dma, GFP_ATOMIC);
> if (!hs_ep->desc_list) {
> ret = -ENOMEM;
> goto error2;
>
Acked-by: John Youn
Regards,
John
[PATCH 07/22] staging: lustre: obdclass: lu_site_purge() to handle purge-all
From: Alex Zhuravlev if the callers wants to purge all objects, then scanning should start from the first bucket. Signed-off-by: Alex Zhuravlev Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7038 Reviewed-on: http://review.whamcloud.com/18505 Reviewed-by: Mike Pershin Reviewed-by: Faccini Bruno Reviewed-by: Oleg Drokin Signed-off-by: James Simmons --- drivers/staging/lustre/lustre/obdclass/lu_object.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/lustre/lustre/obdclass/lu_object.c b/drivers/staging/lustre/lustre/obdclass/lu_object.c index 43868ed..a02aaa3 100644 --- a/drivers/staging/lustre/lustre/obdclass/lu_object.c +++ b/drivers/staging/lustre/lustre/obdclass/lu_object.c @@ -338,7 +338,7 @@ int lu_site_purge(const struct lu_env *env, struct lu_site *s, int nr) struct cfs_hash_bd bd2; struct list_head dispose; int did_sth; - unsigned int start; + unsigned int start = 0; int count; int bnr; unsigned int i; @@ -351,7 +351,8 @@ int lu_site_purge(const struct lu_env *env, struct lu_site *s, int nr) * Under LRU list lock, scan LRU list and move unreferenced objects to * the dispose list, removing them from LRU and hash table. */ - start = s->ls_purge_start; + if (nr != ~0) + start = s->ls_purge_start; bnr = (nr == ~0) ? -1 : nr / (int)CFS_HASH_NBKT(s->ls_obj_hash) + 1; again: /* -- 1.7.1
Re: [RFC][PATCH 1/3] phy: phy-hi6220-usb: Wire up extconn support to hikey's phy driver
On 12/1/2016 12:12 PM, John Stultz wrote:
> On Thu, Dec 1, 2016 at 12:23 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 23 November 2016 09:16 AM, John Stultz wrote:
>>> This wires extconn support to hikey's phy driver, and
>>> connects it to the usb UDC layer via a usb_phy structure.
>>>
>>> Not sure if this is the right way to connect phy -> UDC,
>>> but I'm lacking a clear example.
>>>
>>> Cc: Wei Xu
>>> Cc: Guodong Xu
>>> Cc: Amit Pundir
>>> Cc: Rob Herring
>>> Cc: John Youn
>>> Cc: Douglas Anderson
>>> Cc: Chen Yu
>>> Cc: Kishon Vijay Abraham I
>>> Cc: Felipe Balbi
>>> Cc: Greg Kroah-Hartman
>>> Cc: linux-...@vger.kernel.org
>>> Signed-off-by: John Stultz
>>> ---
>>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 11 +++
>>> drivers/phy/Kconfig | 2 +
>>> drivers/phy/phy-hi6220-usb.c | 139
>>> ++
>>> 3 files changed, 152 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>>> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>>> index 17839db..171fbb2 100644
>>> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>>> @@ -732,10 +732,21 @@
>>> regulator-always-on;
>>> };
>>>
>>> + usb_vbus: usb-vbus {
>>> + compatible = "linux,extcon-usb-gpio";
>>> + id-gpio = <&gpio2 6 1>;
>>> + };
>>> +
>>> + usb_id: usb-id {
>>> + compatible = "linux,extcon-usb-gpio";
>>> + id-gpio = <&gpio2 5 1>;
>>> + };
>>> +
>>> usb_phy: usbphy {
>>> compatible = "hisilicon,hi6220-usb-phy";
>>> #phy-cells = <0>;
>>> phy-supply = <&fixed_5v_hub>;
>>> + extcon = <&usb_vbus>, <&usb_id>;
>>> hisilicon,peripheral-syscon = <&sys_ctrl>;
>>> };
>>>
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>> index fe00f91..76f4f17 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -254,8 +254,10 @@ config PHY_MT65XX_USB3
>>> config PHY_HI6220_USB
>>> tristate "hi6220 USB PHY support"
>>> depends on (ARCH_HISI && ARM64) || COMPILE_TEST
>>> + depends on EXTCON
>>> select GENERIC_PHY
>>> select MFD_SYSCON
>>> + select USB_PHY
>>> help
>>> Enable this to support the HISILICON HI6220 USB PHY.
>>>
>>> diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
>>> index b2141cb..89d8475 100644
>>> --- a/drivers/phy/phy-hi6220-usb.c
>>> +++ b/drivers/phy/phy-hi6220-usb.c
>>> @@ -12,7 +12,12 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> #include
>>> +#include
>>>
>>> #define SC_PERIPH_CTRL4 0x00c
>>>
>>> @@ -44,9 +49,21 @@
>>>
>>> #define EYE_PATTERN_PARA 0x7053348c
>>>
>>> +
>>> +struct hi6220_usb_cable {
>>> + struct notifier_block nb;
>>> + struct extcon_dev *extcon;
>>> + int state;
>>> +};
>>> +
>>> struct hi6220_priv {
>>> struct regmap *reg;
>>> struct device *dev;
>>> + struct usb_phy phy;
>>> +
>>> + struct delayed_work work;
>>> + struct hi6220_usb_cable vbus;
>>> + struct hi6220_usb_cable id;
>>> };
>>>
>>> static void hi6220_phy_init(struct hi6220_priv *priv)
>>> @@ -112,23 +129,85 @@ static int hi6220_phy_exit(struct phy *phy)
>>> return hi6220_phy_setup(priv, false);
>>> }
>>>
>>> +
>>> static struct phy_ops hi6220_phy_ops = {
>>> .init = hi6220_phy_start,
>>> .exit = hi6220_phy_exit,
>>> .owner = THIS_MODULE,
>>> };
>>>
>>> +static void hi6220_detect_work(struct work_struct *work)
>>> +{
>>> + struct hi6220_priv *priv =
>>> + container_of(to_delayed_work(work), struct hi6220_priv, work);
>>> + struct usb_otg *otg = priv->phy.otg;
>>> +
>>> + if (!IS_ERR(priv->vbus.extcon))
>>> + priv->vbus.state = extcon_get_cable_state_(priv->vbus.extcon,
>>> + EXTCON_USB);
>>> + if (!IS_ERR(priv->id.extcon))
>>> + priv->id.state = extcon_get_cable_state_(priv->id.extcon,
>>> + EXTCON_USB_HOST);
>>> + if (otg->gadget) {
>>> + if (priv->id.state)
>>> + usb_gadget_vbus_connect(otg->gadget);
>>> + else
>>> + usb_gadget_vbus_disconnect(otg->gadget);
>>> + }
>>> +}
>>> +
>>> +static int hi6220_otg_vbus_notifier(struct notifier_block *nb,
>>> + unsigned long event, void *ptr)
>>> +{
>>> + struct hi6220_usb_cable *vbus = container_of(nb,
>>> + struct hi6220_usb_cable, nb);
>>> + s
[PATCH 21/22] staging: lustre: remove set but unused variables
From: Yang Sheng
Remove set but unused variables in nidstring.c
and osc_request.c as reported by make W=1.
Signed-off-by: Yang Sheng
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8378
Reviewed-on: http://review.whamcloud.com/23221
Reviewed-by: Bob Glossman
Reviewed-by: Emoly Liu
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lnet/lnet/nidstrings.c |2 --
drivers/staging/lustre/lustre/osc/osc_request.c |3 +--
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/nidstrings.c
b/drivers/staging/lustre/lnet/lnet/nidstrings.c
index e1f1ca8..a9fe3e6 100644
--- a/drivers/staging/lustre/lnet/lnet/nidstrings.c
+++ b/drivers/staging/lustre/lnet/lnet/nidstrings.c
@@ -247,10 +247,8 @@ struct addrrange {
{
struct cfs_lstr addrrange;
struct cfs_lstr net;
- struct cfs_lstr tmp;
struct nidrange *nr;
- tmp = *src;
if (!cfs_gettok(src, '@', &addrrange))
goto failed;
diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c
b/drivers/staging/lustre/lustre/osc/osc_request.c
index 0977127..0c50225 100644
--- a/drivers/staging/lustre/lustre/osc/osc_request.c
+++ b/drivers/staging/lustre/lustre/osc/osc_request.c
@@ -933,7 +933,6 @@ static u32 osc_checksum_bulk(int nob, u32 pg_count,
int i = 0;
struct cfs_crypto_hash_desc *hdesc;
unsigned int bufsize;
- int err;
unsigned char cfs_alg = cksum_obd2cfs(cksum_type);
LASSERT(pg_count > 0);
@@ -975,7 +974,7 @@ static u32 osc_checksum_bulk(int nob, u32 pg_count,
}
bufsize = sizeof(cksum);
- err = cfs_crypto_hash_final(hdesc, (unsigned char *)&cksum, &bufsize);
+ cfs_crypto_hash_final(hdesc, (unsigned char *)&cksum, &bufsize);
/* For sending we only compute the wrong checksum instead
* of corrupting the data so it is still correct on a redo
--
1.7.1
[PATCH 17/22] staging: lustre: clio: remove mtime check in vvp_io_fault_start()
From: Bobi Jam
In fault IO initialization, inode's mtime is saved, and after
getting locks, when the IO is about to start, vvp_io_fault_start()
checks the mtime's intactness.
It's a false alarm, since the timestamp from MDS could be stale,
we maintain mtime mainly on OST objects, and if the check in
vvp_io_fault_start() happens before mtime on OST objects are merged,
it will get wrong timestamp from the inode, even the timestamp it
fetched in vvp_io_fault_init() could be wrong in the first place.
This patch remove the mtime check in vvp_io_fault_start().
Signed-off-by: Bobi Jam
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7198
Reviewed-on: http://review.whamcloud.com/19162
Reviewed-by: Andreas Dilger
Reviewed-by: Jinshan Xiong
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/llite/vvp_io.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/vvp_io.c
b/drivers/staging/lustre/lustre/llite/vvp_io.c
index 114906d..0b6d388 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_io.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_io.c
@@ -1064,12 +1064,6 @@ static int vvp_io_fault_start(const struct lu_env *env,
loff_t size;
pgoff_t last_index;
- if (fio->ft_executable &&
- inode->i_mtime.tv_sec != vio->u.fault.ft_mtime)
- CWARN("binary "DFID
- " changed while waiting for the page fault lock\n",
- PFID(lu_object_fid(&obj->co_lu)));
-
down_read(&lli->lli_trunc_sem);
/* offset of the last byte on the page */
--
1.7.1
[PATCH 18/22] staging: lustre: import: don't reconnect during connect interpret
From: Mikhal Pershin
The import connect flags might be cleared by ptlrpc_connect_import()
wrongly if there is still connect interpret function is running.
Use imp_connected boolean variable to indicate that we are still
interpretting connect reply and don't try to reconnect until it ends.
Signed-off-by: Mikhal Pershin
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7558
Reviewed-on: http://review.whamcloud.com/19312
Reviewed-by: John L. Hammond
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
.../staging/lustre/lustre/include/lustre_import.h |4 +++-
drivers/staging/lustre/lustre/ptlrpc/import.c | 16 +++-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_import.h
b/drivers/staging/lustre/lustre/include/lustre_import.h
index 4499c69..f0c931c 100644
--- a/drivers/staging/lustre/lustre/include/lustre_import.h
+++ b/drivers/staging/lustre/lustre/include/lustre_import.h
@@ -299,7 +299,9 @@ struct obd_import {
*/
imp_force_reconnect:1,
/* import has tried to connect with server */
- imp_connect_tried:1;
+ imp_connect_tried:1,
+/* connected but not FULL yet */
+imp_connected:1;
__u32imp_connect_op;
struct obd_connect_data imp_connect_data;
__u64imp_connect_flags_orig;
diff --git a/drivers/staging/lustre/lustre/ptlrpc/import.c
b/drivers/staging/lustre/lustre/ptlrpc/import.c
index 66f5b49..e828019 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/import.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/import.c
@@ -622,7 +622,8 @@ int ptlrpc_connect_import(struct obd_import *imp)
spin_unlock(&imp->imp_lock);
CERROR("already connected\n");
return 0;
- } else if (imp->imp_state == LUSTRE_IMP_CONNECTING) {
+ } else if (imp->imp_state == LUSTRE_IMP_CONNECTING ||
+ imp->imp_connected) {
spin_unlock(&imp->imp_lock);
CERROR("already connecting\n");
return -EALREADY;
@@ -971,6 +972,13 @@ static int ptlrpc_connect_interpret(const struct lu_env
*env,
ptlrpc_maybe_ping_import_soon(imp);
goto out;
}
+
+ /*
+* LU-7558: indicate that we are interpretting connect reply,
+* pltrpc_connect_import() will not try to reconnect until
+* interpret will finish.
+*/
+ imp->imp_connected = 1;
spin_unlock(&imp->imp_lock);
LASSERT(imp->imp_conn_current);
@@ -1194,12 +1202,18 @@ static int ptlrpc_connect_interpret(const struct lu_env
*env,
obd2cli_tgt(imp->imp_obd),
imp->imp_connection->c_remote_uuid.uuid);
ptlrpc_connect_import(imp);
+ spin_lock(&imp->imp_lock);
+ imp->imp_connected = 0;
imp->imp_connect_tried = 1;
+ spin_unlock(&imp->imp_lock);
return 0;
}
out:
+ spin_lock(&imp->imp_lock);
+ imp->imp_connected = 0;
imp->imp_connect_tried = 1;
+ spin_unlock(&imp->imp_lock);
if (rc != 0) {
IMPORT_SET_STATE(imp, LUSTRE_IMP_DISCON);
--
1.7.1
[PATCH 16/22] staging: lustre: llite: Invoke file_update_time in page_mkwrite
From: Yang Sheng
Only update file times if page_mkwrite is not set. So we
need call file_update_time by ourselves.
Signed-off-by: Yang Sheng
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1118
Reviewed-on: http://review.whamcloud.com/18683
Reviewed-by: Andreas Dilger
Reviewed-by: Niu Yawei
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/llite/llite_mmap.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/llite_mmap.c
b/drivers/staging/lustre/lustre/llite/llite_mmap.c
index f50b6c1..ee01f20 100644
--- a/drivers/staging/lustre/lustre/llite/llite_mmap.c
+++ b/drivers/staging/lustre/lustre/llite/llite_mmap.c
@@ -369,6 +369,7 @@ static int ll_page_mkwrite(struct vm_area_struct *vma,
struct vm_fault *vmf)
bool retry;
int result;
+ file_update_time(vma->vm_file);
do {
retry = false;
result = ll_page_mkwrite0(vma, vmf->page, &retry);
--
1.7.1
[PATCH 15/22] staging: lustre: rpc: increase bulk size
From: Jinshan Xiong
To make the ptlrpc be able to size 16MB IO
Signed-off-by: Jinshan Xiong
Signed-off-by: Gu Zheng
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7990
Reviewed-on: http://review.whamcloud.com/19366
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
.../lustre/lustre/include/lustre/lustre_idl.h |6 +-
drivers/staging/lustre/lustre/include/lustre_net.h |8 ++--
drivers/staging/lustre/lustre/ptlrpc/wiretest.c|2 ++
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index b9f333b..20f55b7 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -1683,8 +1683,12 @@ struct obd_ioobj {
__u32 ioo_bufcnt; /* number of niobufs for this object */
};
+/*
+ * NOTE: IOOBJ_MAX_BRW_BITS defines the _offset_ of the max_brw field in
+ * ioo_max_brw, NOT the maximum number of bits in PTLRPC_BULK_OPS_BITS.
+ * That said, ioo_max_brw is a 32-bit field so the limit is also 16 bits.
+ */
#define IOOBJ_MAX_BRW_BITS 16
-#define IOOBJ_TYPE_MASK((1U << IOOBJ_MAX_BRW_BITS) - 1)
#define ioobj_max_brw_get(ioo) (((ioo)->ioo_max_brw >> IOOBJ_MAX_BRW_BITS) + 1)
#define ioobj_max_brw_set(ioo, num)\
do { (ioo)->ioo_max_brw = ((num) - 1) << IOOBJ_MAX_BRW_BITS; } while (0)
diff --git a/drivers/staging/lustre/lustre/include/lustre_net.h
b/drivers/staging/lustre/lustre/include/lustre_net.h
index 2be135d..411eb0d 100644
--- a/drivers/staging/lustre/lustre/include/lustre_net.h
+++ b/drivers/staging/lustre/lustre/include/lustre_net.h
@@ -69,13 +69,17 @@
#define PTLRPC_MD_OPTIONS 0
/**
- * Max # of bulk operations in one request.
+ * log2 max # of bulk operations in one request: 2=4MB/RPC, 5=32MB/RPC, ...
* In order for the client and server to properly negotiate the maximum
* possible transfer size, PTLRPC_BULK_OPS_COUNT must be a power-of-two
* value. The client is free to limit the actual RPC size for any bulk
* transfer via cl_max_pages_per_rpc to some non-power-of-two value.
+ * NOTE: This is limited to 16 (=64GB RPCs) by IOOBJ_MAX_BRW_BITS.
*/
-#define PTLRPC_BULK_OPS_BITS 2
+#define PTLRPC_BULK_OPS_BITS 4
+#if PTLRPC_BULK_OPS_BITS > 16
+#error "More than 65536 BRW RPCs not allowed by IOOBJ_MAX_BRW_BITS."
+#endif
#define PTLRPC_BULK_OPS_COUNT (1U << PTLRPC_BULK_OPS_BITS)
/**
* PTLRPC_BULK_OPS_MASK is for the convenience of the client only, and
diff --git a/drivers/staging/lustre/lustre/ptlrpc/wiretest.c
b/drivers/staging/lustre/lustre/ptlrpc/wiretest.c
index f50f487..e12eb83 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/wiretest.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/wiretest.c
@@ -1576,6 +1576,8 @@ void lustre_assert_wire_constants(void)
(long long)(int)offsetof(struct obd_ioobj, ioo_bufcnt));
LASSERTF((int)sizeof(((struct obd_ioobj *)0)->ioo_bufcnt) == 4, "found
%lld\n",
(long long)(int)sizeof(((struct obd_ioobj *)0)->ioo_bufcnt));
+ LASSERTF(IOOBJ_MAX_BRW_BITS == 16, "found %lld\n",
+(long long)IOOBJ_MAX_BRW_BITS);
/* Checks for union lquota_id */
LASSERTF((int)sizeof(union lquota_id) == 16, "found %lld\n",
--
1.7.1
[PATCH 22/22] staging: lustre: libcfs: remove lnet upcall code
From: Alexander Zarochentsev
Removing lnet upcall infrastructure completely
as nobody uses it anymore. The upcall causes a delay
before calling BUG() and might even cause a hang
making getting a crash dump unreliable or containing
outdated info.
Signed-off-by: Alexander Zarochentsev
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8418
Seagate-bug-id: MRP-2939
Reviewed-on: http://review.whamcloud.com/21440
Reviewed-by: Andreas Dilger
Reviewed-by: James Simmons
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
.../staging/lustre/include/linux/libcfs/libcfs.h |1 -
.../lustre/include/linux/libcfs/libcfs_private.h |2 -
.../staging/lustre/lnet/libcfs/linux/linux-debug.c | 54
drivers/staging/lustre/lnet/libcfs/module.c|8 ---
4 files changed, 0 insertions(+), 65 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
index 70eb08e..cc2c0e9 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
@@ -125,7 +125,6 @@ int libcfs_ioctl_getdata(struct libcfs_ioctl_hdr **hdr_pp,
/**
* The path of debug log dump upcall script.
*/
-extern char lnet_upcall[1024];
extern char lnet_debug_log_upcall[1024];
extern struct cfs_wi_sched *cfs_sched_rehash;
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
index 41a651f..aab15d8 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
@@ -169,8 +169,6 @@
#define ntohs(x) ___ntohs(x)
#endif
-void libcfs_run_upcall(char **argv);
-void libcfs_run_lbug_upcall(struct libcfs_debug_msg_data *msg);
void libcfs_debug_dumplog(void);
int libcfs_debug_init(unsigned long bufsize);
int libcfs_debug_cleanup(void);
diff --git a/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
b/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
index d8a9894..39a72e3 100644
--- a/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
+++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
@@ -57,7 +57,6 @@
#include
-char lnet_upcall[1024] = "/usr/lib/lustre/lnet_upcall";
char lnet_debug_log_upcall[1024] = "/usr/lib/lustre/lnet_debug_log_upcall";
/**
@@ -92,58 +91,6 @@ void libcfs_run_debug_log_upcall(char *file)
}
}
-void libcfs_run_upcall(char **argv)
-{
- int rc;
- int argc;
- static const char * const envp[] = {
- "HOME=/",
- "PATH=/sbin:/bin:/usr/sbin:/usr/bin",
- NULL
- };
-
- argv[0] = lnet_upcall;
- argc = 1;
- while (argv[argc])
- argc++;
-
- LASSERT(argc >= 2);
-
- rc = call_usermodehelper(argv[0], argv, (char **)envp, 1);
- if (rc < 0 && rc != -ENOENT) {
- CERROR("Error %d invoking LNET upcall %s %s%s%s%s%s%s%s%s;
check /sys/kernel/debug/lnet/upcall\n",
- rc, argv[0], argv[1],
- argc < 3 ? "" : ",", argc < 3 ? "" : argv[2],
- argc < 4 ? "" : ",", argc < 4 ? "" : argv[3],
- argc < 5 ? "" : ",", argc < 5 ? "" : argv[4],
- argc < 6 ? "" : ",...");
- } else {
- CDEBUG(D_HA, "Invoked LNET upcall %s %s%s%s%s%s%s%s%s\n",
- argv[0], argv[1],
- argc < 3 ? "" : ",", argc < 3 ? "" : argv[2],
- argc < 4 ? "" : ",", argc < 4 ? "" : argv[3],
- argc < 5 ? "" : ",", argc < 5 ? "" : argv[4],
- argc < 6 ? "" : ",...");
- }
-}
-
-void libcfs_run_lbug_upcall(struct libcfs_debug_msg_data *msgdata)
-{
- char *argv[6];
- char buf[32];
-
- snprintf(buf, sizeof(buf), "%d", msgdata->msg_line);
-
- argv[1] = "LBUG";
- argv[2] = (char *)msgdata->msg_file;
- argv[3] = (char *)msgdata->msg_fn;
- argv[4] = buf;
- argv[5] = NULL;
-
- libcfs_run_upcall(argv);
-}
-EXPORT_SYMBOL(libcfs_run_lbug_upcall);
-
/* coverity[+kill] */
void __noreturn lbug_with_loc(struct libcfs_debug_msg_data *msgdata)
{
@@ -158,7 +105,6 @@ void __noreturn lbug_with_loc(struct libcfs_debug_msg_data
*msgdata)
dump_stack();
if (!libcfs_panic_on_lbug)
libcfs_debug_dumplog();
- libcfs_run_lbug_upcall(msgdata);
if (libcfs_panic_on_lbug)
panic("LBUG");
set_task_state(current, TASK_UNINTERRUPTIBLE);
diff --git a/drivers/staging/lustre/lnet/libcfs/module.c
b/drivers/staging/lustre/lnet/libcfs/module.c
index 5884a33..161e042 100644
--- a/drivers/staging/lustre/lnet/libcfs/module.c
+++ b/drivers/staging/lustre/lnet/libcfs/module.c
@@ -365,14 +365,6 @@ static int proc_cpt_table(struct ctl_table *table, int
write,
.mode = 0444,
[PATCH] net: ping: check minimum size on ICMP header length
Prior to commit c0371da6047a ("put iov_iter into msghdr") in v3.19, there
was no check that the iovec contained enough bytes for a icmp header,
and the read loop would walk across neighboring stack contents. Since
the iov_iter conversion, bad arguments are noticed, but the returned
error is EFAULT. Returning EMSGSIZE is a clearer fix and solves the
problem prior to v3.19.
This was found using trinity with KASAN on v3.18:
BUG: KASAN: stack-out-of-bounds in memcpy_fromiovec+0x60/0x114 at addr
ffc071077da0
Read of size 8 by task trinity-c2/9623
page:ffbe034b9a08 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x0()
page dumped because: kasan: bad access detected
CPU: 0 PID: 9623 Comm: trinity-c2 Tainted: GBU 3.18.0-dirty #15
Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
Call trace:
[] dump_backtrace+0x0/0x1ac arch/arm64/kernel/traps.c:90
[] show_stack+0x10/0x1c arch/arm64/kernel/traps.c:171
[< inline >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x7c/0xd0 lib/dump_stack.c:50
[< inline >] print_address_description mm/kasan/report.c:147
[< inline >] kasan_report_error mm/kasan/report.c:236
[] kasan_report+0x380/0x4b8 mm/kasan/report.c:259
[< inline >] check_memory_region mm/kasan/kasan.c:264
[] __asan_load8+0x20/0x70 mm/kasan/kasan.c:507
[] memcpy_fromiovec+0x5c/0x114 lib/iovec.c:15
[< inline >] memcpy_from_msg include/linux/skbuff.h:2667
[] ping_common_sendmsg+0x50/0x108 net/ipv4/ping.c:674
[] ping_v4_sendmsg+0xd8/0x698 net/ipv4/ping.c:714
[] inet_sendmsg+0xe0/0x12c net/ipv4/af_inet.c:749
[< inline >] __sock_sendmsg_nosec net/socket.c:624
[< inline >] __sock_sendmsg net/socket.c:632
[] sock_sendmsg+0x124/0x164 net/socket.c:643
[< inline >] SYSC_sendto net/socket.c:1797
[] SyS_sendto+0x178/0x1d8 net/socket.c:1761
CVE-2016-8399
Reported-by: Qidan He
Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
net/ipv4/ping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 205e2000d395..8257be3f032c 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -654,7 +654,7 @@ int ping_common_sendmsg(int family, struct msghdr *msg,
size_t len,
void *user_icmph, size_t icmph_len) {
u8 type, code;
- if (len > 0x)
+ if (len > 0x || len < icmph_len)
return -EMSGSIZE;
/*
--
2.7.4
--
Kees Cook
Nexus Security
[PATCH] drm/i915: Remove instructions to file a bug report.
>From these instructions, users assume that /sys/class/drm/card0/error
contains all the information a developer needs to diagnose and fix a GPU
hang.
In fact it doesn't, and we have no tools for solving them (other than
stabbing in the dark). Most of the time the error state itself isn't
even useful because it just shows a hang on a PIPE_CONTROL or similar.
Until a time when the error state contains enough information to
actually solve a hang, stop telling users to file unsolvable bugs, and
instead rely on users who know where and how to file a good bug report
to find their own way there.
Signed-off-by: Matt Turner
---
Maybe now's a good time to discuss what *would* be useful to put in the
error state for debugging hangs. The currently executing shader program
would be a great place to start.
drivers/gpu/drm/i915/i915_gpu_error.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 334f15d..8ddca7b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1431,7 +1431,6 @@ void i915_capture_error_state(struct drm_i915_private
*dev_priv,
u32 engine_mask,
const char *error_msg)
{
- static bool warned;
struct drm_i915_error_state *error;
unsigned long flags;
@@ -1475,16 +1474,6 @@ void i915_capture_error_state(struct drm_i915_private
*dev_priv,
i915_error_state_free(&error->ref);
return;
}
-
- if (!warned) {
- DRM_INFO("GPU hangs can indicate a bug anywhere in the entire
gfx stack, including userspace.\n");
- DRM_INFO("Please file a _new_ bug report on
bugs.freedesktop.org against DRI -> DRM/Intel\n");
- DRM_INFO("drm/i915 developers can then reassign to the right
component if it's not a kernel issue.\n");
- DRM_INFO("The gpu crash dump is required to analyze gpu hangs,
so please always attach it.\n");
- DRM_INFO("GPU crash dump saved to
/sys/class/drm/card%d/error\n",
-dev_priv->drm.primary->index);
- warned = true;
- }
}
void i915_error_state_get(struct drm_device *dev,
--
2.7.3
[PATCH 19/22] staging: lustre: llite: ll_dir_ioctl cleanup of redundant comparisons
From: Parinay Kondekar
In ll_dir_ioctl() two identical comparisions are present for
return code (rc) of ll_dir_getstripe(). This patch removes
the other inside if( ) condition which is not necessary.
Signed-off-by: Parinay Kondekar
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6512
Reviewed-on: http://review.whamcloud.com/18027
Reviewed-by: Bobi Jam
Reviewed-by: James Simmons
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/llite/dir.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c
b/drivers/staging/lustre/lustre/llite/dir.c
index 351e900..3dc7344 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -1227,9 +1227,6 @@ static long ll_dir_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
/* Get default LMV EA */
if (lum.lum_magic == LMV_USER_MAGIC) {
- if (rc)
- goto finish_req;
-
if (lmmsize > sizeof(*ulmv)) {
rc = -EINVAL;
goto finish_req;
--
1.7.1
[PATCH 13/22] staging: lustre: statahead: set sai_index_wait with lli_sa_lock held
From: Fan Yong
It is the sponsor thread of the statahead thread to update the
sai::sai_index_wait. Originally, it didn't hold the lli_sa_lock
when did that. Becuase of out-of-order execution others may miss
to wakeup such thread.
On the other hand, if the statahead RPC gets failure, it should
wakeup the sponsor thread, not the statahead thread.
Signed-off-by: Li Xi
Signed-off-by: Fan Yong
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7828
Reviewed-on: http://review.whamcloud.com/18499
Reviewed-by: Lai Siyao
Reviewed-by: Andreas Dilger
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/llite/statahead.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/statahead.c
b/drivers/staging/lustre/lustre/llite/statahead.c
index b43955f..4769a22 100644
--- a/drivers/staging/lustre/lustre/llite/statahead.c
+++ b/drivers/staging/lustre/lustre/llite/statahead.c
@@ -659,8 +659,8 @@ static int ll_statahead_interpret(struct ptlrpc_request
*req,
struct ll_inode_info *lli = ll_i2info(dir);
struct ll_statahead_info *sai = lli->lli_sai;
struct sa_entry *entry = (struct sa_entry *)minfo->mi_cbdata;
+ wait_queue_head_t *waitq = NULL;
__u64 handle = 0;
- bool wakeup;
if (it_disposition(it, DISP_LOOKUP_NEG))
rc = -ENOENT;
@@ -693,7 +693,8 @@ static int ll_statahead_interpret(struct ptlrpc_request
*req,
spin_lock(&lli->lli_sa_lock);
if (rc) {
- wakeup = __sa_make_ready(sai, entry, rc);
+ if (__sa_make_ready(sai, entry, rc))
+ waitq = &sai->sai_waitq;
} else {
entry->se_minfo = minfo;
entry->se_req = ptlrpc_request_addref(req);
@@ -704,13 +705,15 @@ static int ll_statahead_interpret(struct ptlrpc_request
*req,
* with parent's lock held, for example: unlink.
*/
entry->se_handle = handle;
- wakeup = !sa_has_callback(sai);
+ if (!sa_has_callback(sai))
+ waitq = &sai->sai_thread.t_ctl_waitq;
+
list_add_tail(&entry->se_list, &sai->sai_interim_entries);
}
sai->sai_replied++;
- if (wakeup)
- wake_up(&sai->sai_thread.t_ctl_waitq);
+ if (waitq)
+ wake_up(waitq);
spin_unlock(&lli->lli_sa_lock);
return rc;
@@ -1397,10 +1400,10 @@ static int revalidate_statahead_dentry(struct inode
*dir,
struct dentry **dentryp,
bool unplug)
{
+ struct ll_inode_info *lli = ll_i2info(dir);
struct sa_entry *entry = NULL;
struct l_wait_info lwi = { 0 };
struct ll_dentry_data *ldd;
- struct ll_inode_info *lli;
int rc = 0;
if ((*dentryp)->d_name.name[0] == '.') {
@@ -1446,7 +1449,9 @@ static int revalidate_statahead_dentry(struct inode *dir,
sa_handle_callback(sai);
if (!sa_ready(entry)) {
+ spin_lock(&lli->lli_sa_lock);
sai->sai_index_wait = entry->se_index;
+ spin_unlock(&lli->lli_sa_lock);
lwi = LWI_TIMEOUT_INTR(cfs_time_seconds(30), NULL,
LWI_ON_SIGNAL_NOOP, NULL);
rc = l_wait_event(sai->sai_waitq, sa_ready(entry), &lwi);
@@ -1514,7 +1519,6 @@ static int revalidate_statahead_dentry(struct inode *dir,
* dentry_may_statahead().
*/
ldd = ll_d2d(*dentryp);
- lli = ll_i2info(dir);
/* ldd can be NULL if llite lookup failed. */
if (ldd)
ldd->lld_sa_generation = lli->lli_sa_generation;
--
1.7.1
[PATCH] clk: uniphier: Fix build with gcc-4.4.
gcc-4.4 has issues with anonymous unions in initializers.
CC drivers/clk/uniphier/clk-uniphier-sys.o
drivers/clk/uniphier/clk-uniphier-sys.c:45: error: unknown field ‘factor’
specified in initializer
Fixes: 1574d5722636 ("clk: uniphier: remove unneeded member name for union")
Signed-off-by: Vinson Lee
---
drivers/clk/uniphier/clk-uniphier-mio.c | 4 ++--
drivers/clk/uniphier/clk-uniphier.h | 12 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/uniphier/clk-uniphier-mio.c
b/drivers/clk/uniphier/clk-uniphier-mio.c
index 4974d38..7441eeb 100644
--- a/drivers/clk/uniphier/clk-uniphier-mio.c
+++ b/drivers/clk/uniphier/clk-uniphier-mio.c
@@ -30,7 +30,7 @@
.name = "sd" #ch "-sel",\
.type = UNIPHIER_CLK_TYPE_MUX, \
.idx = -1, \
- .mux = {\
+ { .mux = { \
.parent_names = { \
"sd-44m", \
"sd-33m", \
@@ -63,7 +63,7 @@
0x1200, \
0x1300, \
}, \
- }, \
+ } },\
}, \
UNIPHIER_CLK_GATE("sd" #ch, (_idx), "sd" #ch "-sel", 0x20 + 0x200 *
(ch), 8)
diff --git a/drivers/clk/uniphier/clk-uniphier.h
b/drivers/clk/uniphier/clk-uniphier.h
index 81d7e5c..8735a7d 100644
--- a/drivers/clk/uniphier/clk-uniphier.h
+++ b/drivers/clk/uniphier/clk-uniphier.h
@@ -81,12 +81,12 @@ struct uniphier_clk_data {
.name = (_name),\
.type = UNIPHIER_CLK_TYPE_CPUGEAR, \
.idx = (_idx), \
- .cpugear = {\
+ { .cpugear = { \
.parent_names = { __VA_ARGS__ },\
.num_parents = (_num_parents), \
.regbase = (_regbase), \
.mask = (_mask) \
-}, \
+} }, \
}
#define UNIPHIER_CLK_FACTOR(_name, _idx, _parent, _mult, _div) \
@@ -94,11 +94,11 @@ struct uniphier_clk_data {
.name = (_name),\
.type = UNIPHIER_CLK_TYPE_FIXED_FACTOR, \
.idx = (_idx), \
- .factor = { \
+ { .factor = { \
.parent_name = (_parent), \
.mult = (_mult),\
.div = (_div), \
- }, \
+ } },\
}
#define UNIPHIER_CLK_GATE(_name, _idx, _parent, _reg, _bit)\
@@ -106,11 +106,11 @@ struct uniphier_clk_data {
.name = (_name),\
.type = UNIPHIER_CLK_TYPE_GATE, \
.idx = (_idx), \
- .gate = { \
+ { .gate = { \
.parent_name = (_parent), \
.reg = (_reg), \
.bit = (_bit), \
- }, \
+ } },\
}
#define UNIPHIER_CLK_DIV(parent, div) \
--
2.7.4
[PATCH 12/22] staging: lustre: libcfs: report hnode value for cfs_hash_putref
From: Yang Sheng Add more debugging info. Signed-off-by: Yang Sheng Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7084 Reviewed-on: http://review.whamcloud.com/17673 Reviewed-by: Andreas Dilger Reviewed-by: Fan Yong Reviewed-by: Mike Pershin Reviewed-by: Oleg Drokin Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/libcfs/hash.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/lustre/lnet/libcfs/hash.c b/drivers/staging/lustre/lnet/libcfs/hash.c index b90dfb9..c93c59d 100644 --- a/drivers/staging/lustre/lnet/libcfs/hash.c +++ b/drivers/staging/lustre/lnet/libcfs/hash.c @@ -1215,7 +1215,7 @@ void cfs_hash_putref(struct cfs_hash *hs) struct cfs_hash_bd bds[2]; int bits = 0; - LASSERT(hlist_unhashed(hnode)); + LASSERTF(hlist_unhashed(hnode), "hnode = %p\n", hnode); cfs_hash_lock(hs, 0); cfs_hash_dual_bd_get_and_lock(hs, key, bds, 1); -- 1.7.1
[PATCH 09/22] staging: lustre: llite: Add client mount opt to ignore suppress_pings
From: Wally Wang
When Lustre servers enable 'suppress_pings', all clients will stop
pinging. However, some clients may not have external mechanism
to notify Lustre servers for node death and therefore need to
preserve the Lustre ping.
This patch provides a mount option 'always_ping' so that the
client will not stop pinging even if the server has enabled
'suppress_pings'.
Signed-off-by: Wally Wang
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6391
Reviewed-on: http://review.whamcloud.com/14127
Reviewed-by: Li Wei
Reviewed-by: Chris Horn
Reviewed-by: Lai Siyao
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
.../staging/lustre/lustre/llite/llite_internal.h |3 +++
drivers/staging/lustre/lustre/llite/llite_lib.c| 16
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index e37ba1f..2f46d47 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -391,6 +391,8 @@ enum stats_track_type {
#define LL_SBI_USER_FID2PATH 0x4 /* allow fid2path by unprivileged users
*/
#define LL_SBI_XATTR_CACHE0x8 /* support for xattr cache */
#define LL_SBI_NOROOTSQUASH0x10 /* do not apply root squash */
+#define LL_SBI_ALWAYS_PING 0x20 /* always ping even if server
+ * suppress_pings */
#define LL_SBI_FLAGS { \
"nolck",\
@@ -414,6 +416,7 @@ enum stats_track_type {
"user_fid2path",\
"xattr_cache", \
"norootsquash", \
+ "always_ping", \
}
/*
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index 2a51efa..25f5aed 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -224,6 +224,10 @@ static int client_common_fill_super(struct super_block
*sb, char *md, char *dt,
/* real client */
data->ocd_connect_flags |= OBD_CONNECT_REAL;
+ /* always ping even if server suppress_pings */
+ if (sbi->ll_flags & LL_SBI_ALWAYS_PING)
+ data->ocd_connect_flags &= ~OBD_CONNECT_PINGLESS;
+
data->ocd_brw_size = MD_MAX_BRW_SIZE;
err = obd_connect(NULL, &sbi->ll_md_exp, obd, &sbi->ll_sb_uuid,
@@ -373,6 +377,10 @@ static int client_common_fill_super(struct super_block
*sb, char *md, char *dt,
data->ocd_connect_flags |= OBD_CONNECT_LRU_RESIZE;
+ /* always ping even if server suppress_pings */
+ if (sbi->ll_flags & LL_SBI_ALWAYS_PING)
+ data->ocd_connect_flags &= ~OBD_CONNECT_PINGLESS;
+
CDEBUG(D_RPCTRACE, "ocd_connect_flags: %#llx ocd_version: %d ocd_grant:
%d\n",
data->ocd_connect_flags,
data->ocd_version, data->ocd_grant);
@@ -788,6 +796,11 @@ static int ll_options(char *options, int *flags)
*flags &= ~tmp;
goto next;
}
+ tmp = ll_set_opt("always_ping", s1, LL_SBI_ALWAYS_PING);
+ if (tmp) {
+ *flags |= tmp;
+ goto next;
+ }
LCONSOLE_ERROR_MSG(0x152, "Unknown option '%s', won't mount.\n",
s1);
return -EINVAL;
@@ -2361,6 +2374,9 @@ int ll_show_options(struct seq_file *seq, struct dentry
*dentry)
if (sbi->ll_flags & LL_SBI_USER_FID2PATH)
seq_puts(seq, ",user_fid2path");
+ if (sbi->ll_flags & LL_SBI_ALWAYS_PING)
+ seq_puts(seq, ",always_ping");
+
return 0;
}
--
1.7.1
[PATCH 06/22] staging: lustre: llog: reset llog bitmap
From: wang di
Once update request fails due to eviction or other failures,
all of update request in the sending list should return fail,
because after the failure, the update log in the following
request will have wrong llog bitmap.
Signed-off-by: wang di
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7039
Reviewed-on: http://review.whamcloud.com/16969
Reviewed-by: Alex Zhuravlev
Reviewed-by: James Simmons
Reviewed-by: Lai Siyao
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/obdclass/llog.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/llog.c
b/drivers/staging/lustre/lustre/obdclass/llog.c
index ae63047..65e6ce6 100644
--- a/drivers/staging/lustre/lustre/obdclass/llog.c
+++ b/drivers/staging/lustre/lustre/obdclass/llog.c
@@ -114,6 +114,7 @@ static int llog_read_header(const struct lu_env *env,
rc = lop->lop_read_header(env, handle);
if (rc == LLOG_EEMPTY) {
struct llog_log_hdr *llh = handle->lgh_hdr;
+ size_t len;
/* lrh_len should be initialized in llog_init_handle */
handle->lgh_last_idx = 0; /* header is record with index 0 */
@@ -127,6 +128,12 @@ static int llog_read_header(const struct lu_env *env,
memcpy(&llh->llh_tgtuuid, uuid,
sizeof(llh->llh_tgtuuid));
llh->llh_bitmap_offset = offsetof(typeof(*llh), llh_bitmap);
+ /*
+* Since update llog header might also call this function,
+* let's reset the bitmap to 0 here
+*/
+ len = llh->llh_hdr.lrh_len - llh->llh_bitmap_offset;
+ memset(LLOG_HDR_BITMAP(llh), 0, len - sizeof(llh->llh_tail));
ext2_set_bit(0, LLOG_HDR_BITMAP(llh));
LLOG_HDR_TAIL(llh)->lrt_len = llh->llh_hdr.lrh_len;
LLOG_HDR_TAIL(llh)->lrt_index = llh->llh_hdr.lrh_index;
--
1.7.1
[PATCH 04/22] staging: lustre: osc: handle osc eviction correctly
From: Jinshan Xiong
Cleanup everything if an OSC is being evicted.
Group lock is not well supported yet.
Signed-off-by: Jinshan Xiong
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6271
Reviewed-on: http://review.whamcloud.com/14989
Reviewed-by: John L. Hammond
Reviewed-by: Bobi Jam
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/ldlm/ldlm_lock.c |3 +-
drivers/staging/lustre/lustre/osc/osc_cache.c | 25
.../staging/lustre/lustre/osc/osc_cl_internal.h| 11 ++-
drivers/staging/lustre/lustre/osc/osc_internal.h |2 +
drivers/staging/lustre/lustre/osc/osc_io.c | 60 +++
drivers/staging/lustre/lustre/osc/osc_object.c | 19 ++
drivers/staging/lustre/lustre/osc/osc_request.c| 42 +++--
7 files changed, 124 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
index d03e6d4..c1665f9 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
@@ -1130,8 +1130,7 @@ static int lock_matches(struct ldlm_lock *lock, struct
lock_match_data *data)
if (!data->lmd_unref && LDLM_HAVE_MASK(lock, GONE))
return INTERVAL_ITER_CONT;
- if ((data->lmd_flags & LDLM_FL_LOCAL_ONLY) &&
- !ldlm_is_local(lock))
+ if (!equi(data->lmd_flags & LDLM_FL_LOCAL_ONLY, ldlm_is_local(lock)))
return INTERVAL_ITER_CONT;
if (data->lmd_flags & LDLM_FL_TEST_LOCK) {
diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c
b/drivers/staging/lustre/lustre/osc/osc_cache.c
index b0f030c..76942cc 100644
--- a/drivers/staging/lustre/lustre/osc/osc_cache.c
+++ b/drivers/staging/lustre/lustre/osc/osc_cache.c
@@ -247,7 +247,7 @@ static int osc_extent_sanity_check0(struct osc_extent *ext,
goto out;
}
- if (ext->oe_dlmlock) {
+ if (ext->oe_dlmlock && !ldlm_is_failed(ext->oe_dlmlock)) {
struct ldlm_extent *extent;
extent = &ext->oe_dlmlock->l_policy_data.l_extent;
@@ -2710,8 +2710,8 @@ int osc_queue_sync_pages(const struct lu_env *env, struct
osc_object *obj,
/**
* Called by osc_io_setattr_start() to freeze and destroy covering extents.
*/
-int osc_cache_truncate_start(const struct lu_env *env, struct osc_io *oio,
-struct osc_object *obj, __u64 size)
+int osc_cache_truncate_start(const struct lu_env *env, struct osc_object *obj,
+u64 size, struct osc_extent **extp)
{
struct client_obd *cli = osc_cli(obj);
struct osc_extent *ext;
@@ -2808,9 +2808,11 @@ int osc_cache_truncate_start(const struct lu_env *env,
struct osc_io *oio,
/* we need to hold this extent in OES_TRUNC state so
* that no writeback will happen. This is to avoid
* BUG 17397.
+* Only partial truncate can reach here, if @size is
+* not zero, the caller should provide a valid @extp.
*/
- LASSERT(!oio->oi_trunc);
- oio->oi_trunc = osc_extent_get(ext);
+ LASSERT(!*extp);
+ *extp = osc_extent_get(ext);
OSC_EXTENT_DUMP(D_CACHE, ext,
"trunc at %llu\n", size);
}
@@ -2836,13 +2838,10 @@ int osc_cache_truncate_start(const struct lu_env *env,
struct osc_io *oio,
/**
* Called after osc_io_setattr_end to add oio->oi_trunc back to cache.
*/
-void osc_cache_truncate_end(const struct lu_env *env, struct osc_io *oio,
- struct osc_object *obj)
+void osc_cache_truncate_end(const struct lu_env *env, struct osc_extent *ext)
{
- struct osc_extent *ext = oio->oi_trunc;
-
- oio->oi_trunc = NULL;
if (ext) {
+ struct osc_object *obj = ext->oe_obj;
bool unplug = false;
EASSERT(ext->oe_nr_pages > 0, ext);
@@ -3183,8 +3182,10 @@ static int discard_cb(const struct lu_env *env, struct
cl_io *io,
/* page is top page. */
info->oti_next_index = osc_index(ops) + 1;
if (cl_page_own(env, io, page) == 0) {
- KLASSERT(ergo(page->cp_type == CPT_CACHEABLE,
- !PageDirty(cl_page_vmpage(page;
+ if (!ergo(page->cp_type == CPT_CACHEABLE,
+ !PageDirty(cl_page_vmpage(page
+ CL_PAGE_DEBUG(D_ERROR, env, page,
+ "discard dirty page?\n");
/* discard the page */
cl_page_discard(env, io, page);
diff --git a/drivers/staging/lustre/lustre/osc/osc_cl_internal.h
b/drivers/staging/lustre/lustre/osc/osc_cl_internal.h
index cce55a9..c09ab97 100644
---
[PATCH 10/22] staging: lustre: obdclass: limit lu_site hash table size on clients
From: Li Dongyang
Allocating a big hash table using the current formula
does not really work for clients. We will create new
hash table for each mount on a single client which is
a lot of memory more than expected.
This patch limits the hash table up to 8M for clients,
which has 524288 entries.
Signed-off-by: Li Dongyang
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7689
Reviewed-on: http://review.whamcloud.com/18048
Reviewed-by: Fan Yong
Reviewed-by: Alex Zhuravlev
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/obdclass/lu_object.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/lu_object.c
b/drivers/staging/lustre/lustre/obdclass/lu_object.c
index a02aaa3..80e0984 100644
--- a/drivers/staging/lustre/lustre/obdclass/lu_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/lu_object.c
@@ -68,6 +68,7 @@ enum {
#define LU_SITE_BITS_MIN 12
#define LU_SITE_BITS_MAX 24
+#define LU_SITE_BITS_MAX_CL19
/**
* total 256 buckets, we don't want too many buckets because:
* - consume too much memory
@@ -878,6 +879,9 @@ static unsigned long lu_htable_order(struct lu_device *top)
unsigned long cache_size;
unsigned long bits;
+ if (!strcmp(top->ld_type->ldt_name, LUSTRE_VVP_NAME))
+ bits_max = LU_SITE_BITS_MAX_CL;
+
/*
* Calculate hash table size, assuming that we want reasonable
* performance when 20% of total memory is occupied by cache of
--
1.7.1
Re: [PATCH v4 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management
Hi Stanimir, [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.9-rc7 next-20161202] [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/Stanimir-Varbanov/Qualcomm-video-decoder-encoder-driver/20161203-054705 base: git://linuxtv.org/media_tree.git master reproduce: make htmldocs All warnings (new ones prefixed by >>): make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. include/linux/init.h:1: warning: no structured comments found include/linux/workqueue.h:392: warning: No description found for parameter '...' include/linux/workqueue.h:392: warning: Excess function parameter 'args' description in 'alloc_workqueue' include/linux/workqueue.h:413: warning: No description found for parameter '...' include/linux/workqueue.h:413: warning: Excess function parameter 'args' description in 'alloc_ordered_workqueue' include/linux/kthread.h:26: warning: No description found for parameter '...' kernel/sys.c:1: warning: no structured comments found drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found include/linux/fence-array.h:61: warning: No description found for parameter 'fence' include/sound/core.h:324: warning: No description found for parameter '...' include/sound/core.h:335: warning: No description found for parameter '...' include/sound/core.h:388: warning: No description found for parameter '...' drivers/media/dvb-core/dvb_frontend.h:677: warning: No description found for parameter 'refcount' include/media/media-entity.h:1054: warning: No description found for parameter '...' >> include/media/v4l2-mem2mem.h:446: warning: No description found for >> parameter 'b' include/media/v4l2-mem2mem.h:454: warning: No description found for parameter 'b' include/media/v4l2-mem2mem.h:463: warning: No description found for parameter 'b' >> include/media/v4l2-mem2mem.h:463: warning: No description found for >> parameter 'n' include/media/v4l2-mem2mem.h:472: warning: No description found for parameter 'b' include/media/v4l2-mem2mem.h:472: warning: No description found for parameter 'n' >> include/media/v4l2-mem2mem.h:533: warning: No description found for >> parameter 'vbuf' include/media/v4l2-mem2mem.h:543: warning: No description found for parameter 'vbuf' include/media/v4l2-mem2mem.h:555: warning: No description found for parameter 'vbuf' include/net/mac80211.h:3207: ERROR: Unexpected indentation. include/net/mac80211.h:3210: WARNING: Block quote ends without a blank line; unexpected unindent. include/net/mac80211.h:3212: ERROR: Unexpected indentation. include/net/mac80211.h:3213: WARNING: Block quote ends without a blank line; unexpected unindent. include/net/mac80211.h:1772: ERROR: Unexpected indentation. include/net/mac80211.h:1776: WARNING: Block quote ends without a blank line; unexpected unindent. kernel/sched/fair.c:7259: WARNING: Inline emphasis start-string without end-string. kernel/time/timer.c:1240: ERROR: Unexpected indentation. kernel/time/timer.c:1242: ERROR: Unexpected indentation. kernel/time/timer.c:1243: WARNING: Block quote ends without a blank line; unexpected unindent. include/linux/wait.h:121: WARNING: Block quote ends without a blank line; unexpected unindent. include/linux/wait.h:124: ERROR: Unexpected indentation. include/linux/wait.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. kernel/time/hrtimer.c:1021: WARNING: Block quote ends without a blank line; unexpected unindent. kernel/signal.c:317: WARNING: Inline literal start-string without end-string. drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent. drivers/message/fusion/mptbase.c:5054: WARNING: Definition list ends without a blank line; unexpected unindent. drivers/tty/serial/serial_core.c:1893: WARNING: Definition list ends without a blank line; unexpected unindent. include/linux/spi/spi.h:369: ERROR: Unexpected indentation. WARNING: dvipng command 'dvipng' cannot be run (needed for math display), check the imgmath_dvipng setting vim +/b +446 include/media/v4l2-mem2mem.h 440 * v4l2_m2m_for_each_dst_buf() - iterate over a list of destination ready 441 * buffers 442 * 443 * @m2m_ctx: m2m context assigned to the instance given by struct &v4l2_m2m_ctx 444 */ 445 #define v4l2_m2m_for_each_dst_buf(m2m_ctx, b) \ > 446 list_for_each_entry(b, &m2m_ctx->cap_q_ctx.rdy_queue, list) 447 448 /** 449
[PATCH 11/22] staging: lustre: mdt: fail FMODE_WRITE open if the client is read only
From: Li Dongyang O_WRONLY/O_RDWR open on a file will get EROFS on a read only client, but the rpc gets sent to the mdt anyway. mdt will increase the mot_write_count of the mdt object, blocking subsequent FMODE_EXEC open to the same file. This patch makes sure we fail the FMODE_WRITE open with EROFS on the client straight away without sending the rpc to mdt. Signed-off-by: Li Dongyang Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7727 Reviewed-on: http://review.whamcloud.com/18242 Reviewed-by: Ian Costello Reviewed-by: Nathaniel Clark Reviewed-by: Yang Sheng Reviewed-by: Oleg Drokin Signed-off-by: James Simmons --- drivers/staging/lustre/lustre/llite/namei.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/namei.c b/drivers/staging/lustre/lustre/llite/namei.c index b07079c..9426759 100644 --- a/drivers/staging/lustre/lustre/llite/namei.c +++ b/drivers/staging/lustre/lustre/llite/namei.c @@ -572,6 +572,10 @@ static int ll_lookup_it_finish(struct ptlrpc_request *request, } } + if (it->it_op & IT_OPEN && it->it_flags & FMODE_WRITE && + dentry->d_sb->s_flags & MS_RDONLY) + return ERR_PTR(-EROFS); + if (it->it_op & IT_CREAT) opc = LUSTRE_OPC_CREATE; else -- 1.7.1
[PATCH 05/22] staging: lustre: lmv: remove nlink check in lmv_revalidate_slaves
From: wang di
Remove nlink < 2 check in lmv_revalidate_slaves, because
after nlink reaches to LDISKFS_LINK_MAX (65000), the inode
nlink will be set to 1.
Signed-off-by: wang di
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6984
Reviewed-on: http://review.whamcloud.com/16490
Reviewed-by: James Simmons
Reviewed-by: Jian Yu
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/lmv/lmv_intent.c | 16 +---
1 files changed, 1 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lmv/lmv_intent.c
b/drivers/staging/lustre/lustre/lmv/lmv_intent.c
index b1071cf..aa42066 100644
--- a/drivers/staging/lustre/lustre/lmv/lmv_intent.c
+++ b/drivers/staging/lustre/lustre/lmv/lmv_intent.c
@@ -220,21 +220,7 @@ int lmv_revalidate_slaves(struct obd_export *exp,
/* refresh slave from server */
body = req_capsule_server_get(&req->rq_pill,
&RMF_MDT_BODY);
- LASSERT(body);
-
- if (unlikely(body->mbo_nlink < 2)) {
- /*
-* If this is bad stripe, most likely due
-* to the race between close(unlink) and
-* getattr, let's return -EONENT, so llite
-* will revalidate the dentry see
-* ll_inode_revalidate_fini()
-*/
- CDEBUG(D_INODE, "%s: nlink %d < 2 corrupt
stripe %d "DFID":" DFID"\n",
- obd->obd_name, body->mbo_nlink, i,
- PFID(&lsm->lsm_md_oinfo[i].lmo_fid),
- PFID(&lsm->lsm_md_oinfo[0].lmo_fid));
-
+ if (!body) {
if (it.it_lock_mode && lockh) {
ldlm_lock_decref(lockh,
it.it_lock_mode);
it.it_lock_mode = 0;
--
1.7.1
[PATCH 02/22] staging: lustre: osc: fix debug log message formatting
From: Ashish Purkar
Corrected newline specifier in debug log message.
Signed-off-by: Ashish Purkar
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7029
Reviewed-on: http://review.whamcloud.com/16046
Reviewed-by: Andreas Dilger
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/osc/osc_page.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/lustre/lustre/osc/osc_page.c
b/drivers/staging/lustre/lustre/osc/osc_page.c
index a80a847..c5129d1 100644
--- a/drivers/staging/lustre/lustre/osc/osc_page.c
+++ b/drivers/staging/lustre/lustre/osc/osc_page.c
@@ -462,7 +462,7 @@ static void osc_lru_del(struct client_obd *cli, struct
osc_page *opg)
* stealing one of them.
*/
if (osc_cache_too_much(cli)) {
- CDEBUG(D_CACHE, "%s: queue LRU workn", cli_name(cli));
+ CDEBUG(D_CACHE, "%s: queue LRU work\n", cli_name(cli));
(void)ptlrpcd_queue_work(cli->cl_lru_work);
}
wake_up(&osc_lru_waitq);
--
1.7.1
[PATCH 03/22] staging: lustre: mdt: race between open and migrate
From: wang di
During intent open, it was found that if the parent has
been migrated to another MDT, it should retry the open
request with the new object, so it needs to keep the
old object in the orphan list, which will be cleanup
during next recovery. Note: if the client still using
the old FID after next recovery, it will return -ENOENT
for the application. Also enqueue the lease lock of
the migrating file, then compare the lease before
migration to make sure no other clients open the file
at the same time.
Signed-off-by: wang di
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6475
Reviewed-on: http://review.whamcloud.com/14497
Reviewed-by: James Simmons
Reviewed-by: Andreas Dilger
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
.../lustre/lustre/include/lustre_req_layout.h |1 +
drivers/staging/lustre/lustre/llite/dir.c |2 +-
drivers/staging/lustre/lustre/llite/file.c | 76 ---
.../staging/lustre/lustre/llite/llite_internal.h |2 +-
drivers/staging/lustre/lustre/mdc/mdc_lib.c| 59 +---
drivers/staging/lustre/lustre/mdc/mdc_reint.c | 20 +-
drivers/staging/lustre/lustre/ptlrpc/layout.c | 18 +
7 files changed, 138 insertions(+), 40 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_req_layout.h
b/drivers/staging/lustre/lustre/include/lustre_req_layout.h
index 7657132..fbcd395 100644
--- a/drivers/staging/lustre/lustre/include/lustre_req_layout.h
+++ b/drivers/staging/lustre/lustre/include/lustre_req_layout.h
@@ -167,6 +167,7 @@ void req_capsule_shrink(struct req_capsule *pill,
extern struct req_format RQF_MDS_REINT_SETXATTR;
extern struct req_format RQF_MDS_QUOTACTL;
extern struct req_format RQF_MDS_SWAP_LAYOUTS;
+extern struct req_format RQF_MDS_REINT_MIGRATE;
/* MDS hsm formats */
extern struct req_format RQF_MDS_HSM_STATE_GET;
extern struct req_format RQF_MDS_HSM_STATE_SET;
diff --git a/drivers/staging/lustre/lustre/llite/dir.c
b/drivers/staging/lustre/lustre/llite/dir.c
index ce05493..351e900 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -1083,7 +1083,7 @@ static long ll_dir_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
goto out_free;
}
- rc = ll_get_fid_by_name(inode, filename, namelen, NULL);
+ rc = ll_get_fid_by_name(inode, filename, namelen, NULL, NULL);
if (rc < 0) {
CERROR("%s: lookup %.*s failed: rc = %d\n",
ll_get_fsname(inode->i_sb, NULL, 0), namelen,
diff --git a/drivers/staging/lustre/lustre/llite/file.c
b/drivers/staging/lustre/lustre/llite/file.c
index ea21e19..aa29583 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -2531,7 +2531,8 @@ int ll_fsync(struct file *file, loff_t start, loff_t end,
int datasync)
}
int ll_get_fid_by_name(struct inode *parent, const char *name,
- int namelen, struct lu_fid *fid)
+ int namelen, struct lu_fid *fid,
+ struct inode **inode)
{
struct md_op_data *op_data = NULL;
struct ptlrpc_request *req;
@@ -2543,7 +2544,7 @@ int ll_get_fid_by_name(struct inode *parent, const char
*name,
if (IS_ERR(op_data))
return PTR_ERR(op_data);
- op_data->op_valid = OBD_MD_FLID;
+ op_data->op_valid = OBD_MD_FLID | OBD_MD_FLTYPE;
rc = md_getattr_name(ll_i2sbi(parent)->ll_md_exp, op_data, &req);
ll_finish_md_op_data(op_data);
if (rc < 0)
@@ -2556,6 +2557,9 @@ int ll_get_fid_by_name(struct inode *parent, const char
*name,
}
if (fid)
*fid = body->mbo_fid1;
+
+ if (inode)
+ rc = ll_prep_inode(inode, req, parent->i_sb, NULL);
out_req:
ptlrpc_req_finished(req);
return rc;
@@ -2565,9 +2569,12 @@ int ll_migrate(struct inode *parent, struct file *file,
int mdtidx,
const char *name, int namelen)
{
struct ptlrpc_request *request = NULL;
+ struct obd_client_handle *och = NULL;
struct inode *child_inode = NULL;
struct dentry *dchild = NULL;
struct md_op_data *op_data;
+ struct mdt_body *body;
+ u64 data_version = 0;
struct qstr qstr;
int rc;
@@ -2586,22 +2593,25 @@ int ll_migrate(struct inode *parent, struct file *file,
int mdtidx,
dchild = d_lookup(file_dentry(file), &qstr);
if (dchild) {
op_data->op_fid3 = *ll_inode2fid(dchild->d_inode);
- if (dchild->d_inode) {
+ if (dchild->d_inode)
child_inode = igrab(dchild->d_inode);
- if (child_inode) {
- inode_lock(child_inode);
- op_data->op_fid3 = *ll_inode2fid(chil
[PATCH 08/22] staging: lustre: clio: revise read ahead algorithm
From: Jinshan Xiong
ras_window_len should only be updated in ras_update() by read
pattern and it can't be adjusted in ll_readahead() at all;
ras_consecutive_pages is used to detect read pattern from
mmap. It will be used to increase read ahead window length
gradually.
Signed-off-by: Jinshan Xiong
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5505
Reviewed-on: http://review.whamcloud.com/11528
Reviewed-by: John L. Hammond
Reviewed-by: Bobi Jam
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
.../staging/lustre/lustre/llite/llite_internal.h |5 +-
drivers/staging/lustre/lustre/llite/rw.c | 71 +++-
2 files changed, 43 insertions(+), 33 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index ae0bb09..e37ba1f 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -1005,8 +1005,11 @@ int ll_xattr_list(struct inode *inode, const char *name,
int type,
*/
int cl_sb_init(struct super_block *sb);
int cl_sb_fini(struct super_block *sb);
-void ll_io_init(struct cl_io *io, const struct file *file, int write);
+enum ras_update_flags {
+ LL_RAS_HIT = 0x1,
+ LL_RAS_MMAP = 0x2
+};
void ll_ra_count_put(struct ll_sb_info *sbi, unsigned long len);
void ll_ra_stats_inc(struct inode *inode, enum ra_stat which);
diff --git a/drivers/staging/lustre/lustre/llite/rw.c
b/drivers/staging/lustre/lustre/llite/rw.c
index e34017d..e2d5e75 100644
--- a/drivers/staging/lustre/lustre/llite/rw.c
+++ b/drivers/staging/lustre/lustre/llite/rw.c
@@ -457,30 +457,25 @@ static int ll_readahead(const struct lu_env *env, struct
cl_io *io,
spin_lock(&ras->ras_lock);
- /* Enlarge the RA window to encompass the full read */
- if (vio->vui_ra_valid &&
- ras->ras_window_start + ras->ras_window_len <
- vio->vui_ra_start + vio->vui_ra_count) {
- ras->ras_window_len = vio->vui_ra_start + vio->vui_ra_count -
- ras->ras_window_start;
- }
+ /**
+* Note: other thread might rollback the ras_next_readahead,
+* if it can not get the full size of prepared pages, see the
+* end of this function. For stride read ahead, it needs to
+* make sure the offset is no less than ras_stride_offset,
+* so that stride read ahead can work correctly.
+*/
+ if (stride_io_mode(ras))
+ start = max(ras->ras_next_readahead, ras->ras_stride_offset);
+ else
+ start = ras->ras_next_readahead;
- /* Reserve a part of the read-ahead window that we'll be issuing */
- if (ras->ras_window_len > 0) {
- /*
-* Note: other thread might rollback the ras_next_readahead,
-* if it can not get the full size of prepared pages, see the
-* end of this function. For stride read ahead, it needs to
-* make sure the offset is no less than ras_stride_offset,
-* so that stride read ahead can work correctly.
-*/
- if (stride_io_mode(ras))
- start = max(ras->ras_next_readahead,
- ras->ras_stride_offset);
- else
- start = ras->ras_next_readahead;
+ if (ras->ras_window_len > 0)
end = ras->ras_window_start + ras->ras_window_len - 1;
- }
+
+ /* Enlarge the RA window to encompass the full read */
+ if (vio->vui_ra_valid &&
+ end < vio->vui_ra_start + vio->vui_ra_count - 1)
+ end = vio->vui_ra_start + vio->vui_ra_count - 1;
if (end != 0) {
unsigned long rpc_boundary;
@@ -602,7 +597,7 @@ static void ras_reset(struct inode *inode, struct
ll_readahead_state *ras,
ras->ras_consecutive_pages = 0;
ras->ras_window_len = 0;
ras_set_start(inode, ras, index);
- ras->ras_next_readahead = max(ras->ras_window_start, index);
+ ras->ras_next_readahead = max(ras->ras_window_start, index + 1);
RAS_CDEBUG(ras);
}
@@ -733,10 +728,11 @@ static void ras_increase_window(struct inode *inode,
static void ras_update(struct ll_sb_info *sbi, struct inode *inode,
struct ll_readahead_state *ras, unsigned long index,
- unsigned int hit)
+ enum ras_update_flags flags)
{
struct ll_ra_info *ra = &sbi->ll_ra_info;
int zero = 0, stride_detect = 0, ra_miss = 0;
+ bool hit = flags & LL_RAS_HIT;
spin_lock(&ras->ras_lock);
@@ -766,7 +762,7 @@ static void ras_update(struct ll_sb_info *sbi, struct inode
*inode,
* to for subsequent IO. The mmap case does not increment
* ras_requests and thus can never trigger this behavior.
*/
- if (ras-
[PATCH 01/22] staging: lustre: llite: clear LLIF_DATA_MODIFIED in atomic
From: Jinshan Xiong
This flag should be cleared atomically after the op_data flag
MDS_DATA_MODIFIED is packed. Otherwise, if there exists an
operation to dirty the file again, the state may be missed on
the MDT.
Stop using spin lock lli_lock to protect operations of changing
file flags; using bit operations instead.
Signed-off-by: Jinshan Xiong
Signed-off-by: James Simmons
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6377
Reviewed-on: http://review.whamcloud.com/14100
Reviewed-by: John L. Hammond
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/llite/file.c | 61 +++
.../staging/lustre/lustre/llite/llite_internal.h | 12 ++--
drivers/staging/lustre/lustre/llite/llite_lib.c| 18 +--
drivers/staging/lustre/lustre/llite/llite_mmap.c |7 +--
drivers/staging/lustre/lustre/llite/vvp_io.c | 10 +--
drivers/staging/lustre/lustre/llite/xattr_cache.c |7 +-
6 files changed, 38 insertions(+), 77 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/file.c
b/drivers/staging/lustre/lustre/llite/file.c
index 6c2abb3..ea21e19 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -75,45 +75,39 @@ static void ll_file_data_put(struct ll_file_data *fd)
kmem_cache_free(ll_file_data_slab, fd);
}
-void ll_pack_inode2opdata(struct inode *inode, struct md_op_data *op_data,
- struct lustre_handle *fh)
+/**
+ * Packs all the attributes into @op_data for the CLOSE rpc.
+ */
+static void ll_prepare_close(struct inode *inode, struct md_op_data *op_data,
+struct obd_client_handle *och)
{
- op_data->op_fid1 = ll_i2info(inode)->lli_fid;
+ struct ll_inode_info *lli = ll_i2info(inode);
+
+ ll_prep_md_op_data(op_data, inode, NULL, NULL,
+ 0, 0, LUSTRE_OPC_ANY, NULL);
+
op_data->op_attr.ia_mode = inode->i_mode;
op_data->op_attr.ia_atime = inode->i_atime;
op_data->op_attr.ia_mtime = inode->i_mtime;
op_data->op_attr.ia_ctime = inode->i_ctime;
op_data->op_attr.ia_size = i_size_read(inode);
+ op_data->op_attr.ia_valid |= ATTR_MODE | ATTR_ATIME | ATTR_ATIME_SET |
+ATTR_MTIME | ATTR_MTIME_SET |
+ATTR_CTIME | ATTR_CTIME_SET;
op_data->op_attr_blocks = inode->i_blocks;
op_data->op_attr_flags = ll_inode_to_ext_flags(inode->i_flags);
- if (fh)
- op_data->op_handle = *fh;
+ op_data->op_handle = och->och_fh;
- if (ll_i2info(inode)->lli_flags & LLIF_DATA_MODIFIED)
+ /*
+* For HSM: if inode data has been modified, pack it so that
+* MDT can set data dirty flag in the archive.
+*/
+ if (och->och_flags & FMODE_WRITE &&
+ test_and_clear_bit(LLIF_DATA_MODIFIED, &lli->lli_flags))
op_data->op_bias |= MDS_DATA_MODIFIED;
}
/**
- * Packs all the attributes into @op_data for the CLOSE rpc.
- */
-static void ll_prepare_close(struct inode *inode, struct md_op_data *op_data,
-struct obd_client_handle *och)
-{
- op_data->op_attr.ia_valid = ATTR_MODE | ATTR_ATIME | ATTR_ATIME_SET |
- ATTR_MTIME | ATTR_MTIME_SET |
- ATTR_CTIME | ATTR_CTIME_SET;
-
- if (!(och->och_flags & FMODE_WRITE))
- goto out;
-
- op_data->op_attr.ia_valid |= ATTR_SIZE | ATTR_BLOCKS;
-out:
- ll_pack_inode2opdata(inode, op_data, &och->och_fh);
- ll_prep_md_op_data(op_data, inode, NULL, NULL,
- 0, 0, LUSTRE_OPC_ANY, NULL);
-}
-
-/**
* Perform a close, possibly with a bias.
* The meaning of "data" depends on the value of "bias".
*
@@ -181,17 +175,6 @@ static int ll_close_inode_openhandle(struct obd_export
*md_exp,
PFID(ll_inode2fid(inode)), rc);
}
- /* DATA_MODIFIED flag was successfully sent on close, cancel data
-* modification flag.
-*/
- if (rc == 0 && (op_data->op_bias & MDS_DATA_MODIFIED)) {
- struct ll_inode_info *lli = ll_i2info(inode);
-
- spin_lock(&lli->lli_lock);
- lli->lli_flags &= ~LLIF_DATA_MODIFIED;
- spin_unlock(&lli->lli_lock);
- }
-
if (op_data->op_bias & (MDS_HSM_RELEASE | MDS_CLOSE_LAYOUT_SWAP) &&
!rc) {
struct mdt_body *body;
@@ -2888,6 +2871,8 @@ static int ll_inode_revalidate(struct dentry *dentry,
__u64 ibits)
LTIME_S(inode->i_mtime) = ll_i2info(inode)->lli_mtime;
LTIME_S(inode->i_ctime) = ll_i2info(inode)->lli_ctime;
} else {
+ struct ll_inode_info *lli = ll_i2info(inode);
+
/* In case of restore, the MDT has the right size and has
* already s
[PATCH 00/22] Next batch of missing work for upstream client
Batch of various fixes and clean ups missing in the upstream client. Only one smaller batch of patches left to sync lustre 2.8.0 version. These patches are independent of each other so they can be landed in any order. Alex Zhuravlev (1): staging: lustre: obdclass: lu_site_purge() to handle purge-all Alexander Boyko (1): staging: lustre: obd: add callback for llog_cat_process_or_fork Alexander Zarochentsev (1): staging: lustre: libcfs: remove lnet upcall code Ashish Purkar (1): staging: lustre: osc: fix debug log message formatting Bobi Jam (1): staging: lustre: clio: remove mtime check in vvp_io_fault_start() Fan Yong (1): staging: lustre: statahead: set sai_index_wait with lli_sa_lock held Jinshan Xiong (5): staging: lustre: llite: clear LLIF_DATA_MODIFIED in atomic staging: lustre: osc: handle osc eviction correctly staging: lustre: clio: revise read ahead algorithm staging: lustre: rpc: increase bulk size staging: lustre: osc: set lock data for readahead lock Li Dongyang (2): staging: lustre: obdclass: limit lu_site hash table size on clients staging: lustre: mdt: fail FMODE_WRITE open if the client is read only Mikhal Pershin (1): staging: lustre: import: don't reconnect during connect interpret Parinay Kondekar (1): staging: lustre: llite: ll_dir_ioctl cleanup of redundant comparisons Wally Wang (1): staging: lustre: llite: Add client mount opt to ignore suppress_pings Yang Sheng (3): staging: lustre: libcfs: report hnode value for cfs_hash_putref staging: lustre: llite: Invoke file_update_time in page_mkwrite staging: lustre: remove set but unused variables wang di (3): staging: lustre: mdt: race between open and migrate staging: lustre: lmv: remove nlink check in lmv_revalidate_slaves staging: lustre: llog: reset llog bitmap .../staging/lustre/include/linux/libcfs/libcfs.h |1 - .../lustre/include/linux/libcfs/libcfs_private.h |2 - drivers/staging/lustre/lnet/libcfs/hash.c |2 +- .../staging/lustre/lnet/libcfs/linux/linux-debug.c | 54 drivers/staging/lustre/lnet/libcfs/module.c|8 - drivers/staging/lustre/lnet/lnet/nidstrings.c |2 - .../lustre/lustre/include/lustre/lustre_idl.h |6 +- .../staging/lustre/lustre/include/lustre_import.h |4 +- drivers/staging/lustre/lustre/include/lustre_net.h |8 +- .../lustre/lustre/include/lustre_req_layout.h |1 + drivers/staging/lustre/lustre/ldlm/ldlm_lock.c |3 +- drivers/staging/lustre/lustre/llite/dir.c |5 +- drivers/staging/lustre/lustre/llite/file.c | 137 +--- .../staging/lustre/lustre/llite/llite_internal.h | 22 ++-- drivers/staging/lustre/lustre/llite/llite_lib.c| 34 +++--- drivers/staging/lustre/lustre/llite/llite_mmap.c |8 +- drivers/staging/lustre/lustre/llite/namei.c|4 + drivers/staging/lustre/lustre/llite/rw.c | 71 ++- drivers/staging/lustre/lustre/llite/statahead.c| 18 ++- drivers/staging/lustre/lustre/llite/vvp_io.c | 16 +-- drivers/staging/lustre/lustre/llite/xattr_cache.c |7 +- drivers/staging/lustre/lustre/lmv/lmv_intent.c | 16 +-- drivers/staging/lustre/lustre/mdc/mdc_lib.c| 59 + drivers/staging/lustre/lustre/mdc/mdc_reint.c | 20 +++- drivers/staging/lustre/lustre/obdclass/llog.c |7 + drivers/staging/lustre/lustre/obdclass/llog_cat.c | 16 +-- drivers/staging/lustre/lustre/obdclass/lu_object.c |9 +- drivers/staging/lustre/lustre/osc/osc_cache.c | 25 ++-- .../staging/lustre/lustre/osc/osc_cl_internal.h| 11 +- drivers/staging/lustre/lustre/osc/osc_internal.h |2 + drivers/staging/lustre/lustre/osc/osc_io.c | 61 +++-- drivers/staging/lustre/lustre/osc/osc_lock.c |7 +- drivers/staging/lustre/lustre/osc/osc_object.c | 19 +++ drivers/staging/lustre/lustre/osc/osc_page.c |2 +- drivers/staging/lustre/lustre/osc/osc_request.c| 94 +++--- drivers/staging/lustre/lustre/ptlrpc/import.c | 16 ++- drivers/staging/lustre/lustre/ptlrpc/layout.c | 18 +++ drivers/staging/lustre/lustre/ptlrpc/wiretest.c|2 + 38 files changed, 452 insertions(+), 345 deletions(-)
Re: [PATCH v2 0/7] RMI4 cleanups and switch hid-rmi to rmi_core
Hi Benjamin, Thanks for adding the irq handling to hid-rmi and fifo support in the core. On 12/02/2016 03:41 AM, Benjamin Tissoires wrote: Hi, Well, the cleanup part of the series has already been applied, so I guess this is just "switch hid-rmi to rmi_core". The series applies on top of Dmitri's synaptics-rmi4 branch However, as mentioned in v1, I'd like to get some testings from actually integrated devices befor we flip the switch for HID. Andrew, Dennis? Tested on a Dell XPS 13 9343 and a Lenovo S21e. That covers the two generations of our HID touchpads which have gone into production. Andrew Function f03 has been tested in the rmi4-smbus, and the attn data API on a test synaptics board. Cheers, Benjamin Andrew Duggan (3): HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4 HID: rmi: Handle all Synaptics touchpads using hid-rmi HID: rmi: Support the Lenovo Thinkpad X1 Tablet dock using hid-rmi Benjamin Tissoires (2): Input: synaptics-rmi4 - allow to add attention data Input: synaptics-rmi4 - store the attn data in the driver Dennis Wassenberg (1): Input: synaptics-rmi4 - F03: grab data passed by transport device Lyude Paul (1): Input: synaptics-rmi4 - add support for F03 drivers/hid/Kconfig | 4 + drivers/hid/hid-core.c | 4 +- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-rmi.c | 974 ++-- drivers/input/rmi4/Kconfig | 9 + drivers/input/rmi4/Makefile | 1 + drivers/input/rmi4/rmi_bus.c| 3 + drivers/input/rmi4/rmi_driver.c | 50 ++- drivers/input/rmi4/rmi_driver.h | 1 + drivers/input/rmi4/rmi_f03.c| 251 +++ drivers/input/rmi4/rmi_f11.c| 12 +- drivers/input/rmi4/rmi_f12.c| 43 +- drivers/input/rmi4/rmi_f30.c| 11 +- include/linux/rmi.h | 16 +- 14 files changed, 508 insertions(+), 872 deletions(-) create mode 100644 drivers/input/rmi4/rmi_f03.c
Re: [PATCH v2 3/7] Input: synaptics-rmi4 - allow to add attention data
On 12/02/2016 03:41 AM, Benjamin Tissoires wrote:
The HID implementation of RMI4 provides the data during
the interrupt (in the input report). We need to provide
a way for this transport driver to provide the attention
data while calling an IRQ.
We use a fifo in rmi_core to not lose any incoming event.
Signed-off-by: Benjamin Tissoires
Reviewed-by: Andrew Duggan
---
no changes in v2
---
drivers/input/rmi4/rmi_driver.c | 49 +++--
include/linux/rmi.h | 11 +
2 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index a718e51..85062e4 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -191,16 +191,53 @@ static int rmi_process_interrupt_requests(struct
rmi_device *rmi_dev)
return 0;
}
+void rmi_set_attn_data(struct rmi_device *rmi_dev, unsigned long irq_status,
+ void *data, size_t size)
+{
+ struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev);
+ struct rmi4_attn_data attn_data;
+ void *fifo_data;
+
+ if (!drvdata->enabled)
+ return;
+
+ fifo_data = kmemdup(data, size, GFP_ATOMIC);
+ if (!fifo_data)
+ return;
+
+ attn_data.irq_status = irq_status;
+ attn_data.size = size;
+ attn_data.data = fifo_data;
+
+ kfifo_put(&drvdata->attn_fifo, attn_data);
+}
+EXPORT_SYMBOL_GPL(rmi_set_attn_data);
+
static irqreturn_t rmi_irq_fn(int irq, void *dev_id)
{
struct rmi_device *rmi_dev = dev_id;
- int ret;
+ struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev);
+ struct rmi4_attn_data attn_data = {0};
+ int ret, count;
+
+ count = kfifo_get(&drvdata->attn_fifo, &attn_data);
+ if (count) {
+ *(drvdata->irq_status) = attn_data.irq_status;
+ rmi_dev->xport->attn_data = attn_data.data;
+ rmi_dev->xport->attn_size = attn_data.size;
+ }
ret = rmi_process_interrupt_requests(rmi_dev);
if (ret)
rmi_dbg(RMI_DEBUG_CORE, &rmi_dev->dev,
"Failed to process interrupt request: %d\n", ret);
+ if (count)
+ kfree(attn_data.data);
+
+ if (!kfifo_is_empty(&drvdata->attn_fifo))
+ return rmi_irq_fn(irq, dev_id);
+
return IRQ_HANDLED;
}
@@ -880,8 +917,9 @@ void rmi_disable_irq(struct rmi_device *rmi_dev, bool enable_wake)
{
struct rmi_device_platform_data *pdata = rmi_get_platform_data(rmi_dev);
struct rmi_driver_data *data = dev_get_drvdata(&rmi_dev->dev);
+ struct rmi4_attn_data attn_data = {0};
int irq = pdata->irq;
- int retval;
+ int retval, count;
mutex_lock(&data->enabled_mutex);
@@ -898,6 +936,13 @@ void rmi_disable_irq(struct rmi_device *rmi_dev, bool enable_wake)
retval);
}
+ /* make sure the fifo is clean */
+ while (!kfifo_is_empty(&data->attn_fifo)) {
+ count = kfifo_get(&data->attn_fifo, &attn_data);
+ if (count)
+ kfree(attn_data.data);
+ }
+
out:
mutex_unlock(&data->enabled_mutex);
}
diff --git a/include/linux/rmi.h b/include/linux/rmi.h
index 7780e40..1d48656 100644
--- a/include/linux/rmi.h
+++ b/include/linux/rmi.h
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -331,6 +332,12 @@ struct rmi_device {
};
+struct rmi4_attn_data {
+ unsigned long irq_status;
+ size_t size;
+ void *data;
+};
+
struct rmi_driver_data {
struct list_head function_list;
@@ -357,11 +364,15 @@ struct rmi_driver_data {
bool enabled;
struct mutex enabled_mutex;
+ DECLARE_KFIFO(attn_fifo, struct rmi4_attn_data, 16);
};
int rmi_register_transport_device(struct rmi_transport_dev *xport);
void rmi_unregister_transport_device(struct rmi_transport_dev *xport);
+void rmi_set_attn_data(struct rmi_device *rmi_dev, unsigned long irq_status,
+ void *data, size_t size);
+
int rmi_driver_suspend(struct rmi_device *rmi_dev, bool enable_wake);
int rmi_driver_resume(struct rmi_device *rmi_dev, bool clear_wake);
#endif
Re: [PATCH v2 4/7] Input: synaptics-rmi4 - store the attn data in the driver
On 12/02/2016 03:41 AM, Benjamin Tissoires wrote:
Now that we have a proper API to set the attention data, there is
no point in keeping it in the transport driver.
Signed-off-by: Benjamin Tissoires
Reviewed-by: Andrew Duggan
---
no changes in v2
---
drivers/input/rmi4/rmi_driver.c | 5 ++---
drivers/input/rmi4/rmi_f03.c| 13 +++--
drivers/input/rmi4/rmi_f11.c| 12 ++--
drivers/input/rmi4/rmi_f12.c| 43 +
drivers/input/rmi4/rmi_f30.c| 11 ++-
include/linux/rmi.h | 5 ++---
6 files changed, 45 insertions(+), 44 deletions(-)
diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index 85062e4..05a3c4b 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -155,7 +155,7 @@ static int rmi_process_interrupt_requests(struct rmi_device
*rmi_dev)
if (!data)
return 0;
- if (!rmi_dev->xport->attn_data) {
+ if (!data->attn_data.data) {
error = rmi_read_block(rmi_dev,
data->f01_container->fd.data_base_addr + 1,
data->irq_status, data->num_of_irq_regs);
@@ -223,8 +223,7 @@ static irqreturn_t rmi_irq_fn(int irq, void *dev_id)
count = kfifo_get(&drvdata->attn_fifo, &attn_data);
if (count) {
*(drvdata->irq_status) = attn_data.irq_status;
- rmi_dev->xport->attn_data = attn_data.data;
- rmi_dev->xport->attn_size = attn_data.size;
+ drvdata->attn_data = attn_data;
}
ret = rmi_process_interrupt_requests(rmi_dev);
diff --git a/drivers/input/rmi4/rmi_f03.c b/drivers/input/rmi4/rmi_f03.c
index 06279cd..996dcbb 100644
--- a/drivers/input/rmi4/rmi_f03.c
+++ b/drivers/input/rmi4/rmi_f03.c
@@ -166,6 +166,7 @@ static int rmi_f03_config(struct rmi_function *fn)
static int rmi_f03_attention(struct rmi_function *fn, unsigned long *irq_bits)
{
struct rmi_device *rmi_dev = fn->rmi_dev;
+ struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev);
struct f03_data *f03 = dev_get_drvdata(&fn->dev);
u16 data_addr = fn->fd.data_base_addr;
const u8 ob_len = f03->rx_queue_length * RMI_F03_OB_SIZE;
@@ -176,20 +177,20 @@ static int rmi_f03_attention(struct rmi_function *fn,
unsigned long *irq_bits)
int i;
int ret;
- if (!rmi_dev || !rmi_dev->xport)
+ if (!rmi_dev)
return -ENODEV;
- if (rmi_dev->xport->attn_data) {
+ if (drvdata->attn_data.data) {
/* First grab the data passed by the transport device */
- if (rmi_dev->xport->attn_size < ob_len) {
+ if (drvdata->attn_data.size < ob_len) {
dev_warn(&fn->dev, "F03 interrupted, but data is
missing!\n");
return 0;
}
- memcpy(obs, rmi_dev->xport->attn_data, ob_len);
+ memcpy(obs, drvdata->attn_data.data, ob_len);
- rmi_dev->xport->attn_data += ob_len;
- rmi_dev->xport->attn_size -= ob_len;
+ drvdata->attn_data.data += ob_len;
+ drvdata->attn_data.size -= ob_len;
} else {
/* Grab all of the data registers, and check them for data */
ret = rmi_read_block(fn->rmi_dev, data_addr + RMI_F03_OB_OFFSET,
diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index 44fc275..bc5e37f 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -1284,19 +1284,19 @@ static int rmi_f11_attention(struct rmi_function *fn,
unsigned long *irq_bits)
int error;
int valid_bytes = f11->sensor.pkt_size;
- if (rmi_dev->xport->attn_data) {
+ if (drvdata->attn_data.data) {
/*
* The valid data in the attention report is less then
* expected. Only process the complete fingers.
*/
- if (f11->sensor.attn_size > rmi_dev->xport->attn_size)
- valid_bytes = rmi_dev->xport->attn_size;
+ if (f11->sensor.attn_size > drvdata->attn_data.size)
+ valid_bytes = drvdata->attn_data.size;
else
valid_bytes = f11->sensor.attn_size;
- memcpy(f11->sensor.data_pkt, rmi_dev->xport->attn_data,
+ memcpy(f11->sensor.data_pkt, drvdata->attn_data.data,
valid_bytes);
- rmi_dev->xport->attn_data += f11->sensor.attn_size;
- rmi_dev->xport->attn_size -= f11->sensor.attn_size;
+ drvdata->attn_data.data += f11->sensor.attn_size;
+ drvdata->attn_data.size -= f11->sensor.attn_size;
} else {
error = rmi_read_block(rmi_dev,
data_base_addr, f11->sensor.data_pkt,
diff --git a/drivers/input/rmi4/rmi_
Re: [RFD] Common userspace tool for fscypto
On Wed, Nov 30, 2016 at 09:27:28AM +0100, Richard Weinberger wrote: > > BTW: This limitations needs to be clearly documented somewhere. > Usually an user thinks that only she can access encrypted files... > > Thanks, > //richard For what it's worth, I've been making a few updates to the public design document for ext4 encryption based on what's actually upstream now: https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npaWdRfXFoNnB8JYnykNTg It still needs work, though. It doesn't really answer the questions about access control and key revocation, for example, and of course now the upstream code isn't actually ext4 specific anymore. At some point it might be nice to write some in-tree documentation for fscrypto, e.g. a file Documentation/filesystems/fscrypto.txt. Eric
Re: [PATCH 5/6] g_NCR5380: Autoprobe IRQ by default
Hi Ondrej, On Wed, 2 Nov 2016, I wrote: > > I think this patch is incomplete and you should add these changes: > > diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c > index 7299ad9..0bf0322 100644 > --- a/drivers/scsi/g_NCR5380.c > +++ b/drivers/scsi/g_NCR5380.c > @@ -44,7 +44,7 @@ static int ncr_53c400; > static int ncr_53c400a; > static int dtc_3181e; > static int hp_c2502; > -module_param(ncr_irq, int, 0); > +module_param(ncr_irq, int, IRQ_AUTO); Oops, this doesn't even compile! Sorry about that. What I was trying to achieve was, -static int ncr_irq; +static int ncr_irq = IRQ_AUTO; I will update my patch queue, compile test it, and ask you to review. --
Re: [PATCH 5/7] Documentation: DT: net: cpsw: allow to specify descriptors pool size
On Fri, Dec 02, 2016 at 11:22:28AM -0600, Grygorii Strashko wrote: > > > On 12/02/2016 05:28 AM, Ivan Khoronzhuk wrote: > > On Thu, Dec 01, 2016 at 05:34:30PM -0600, Grygorii Strashko wrote: > >> Add optional property "descs_pool_size" to specify buffer descriptor's > >> pool size. The "descs_pool_size" should define total number of CPDMA > >> CPPI descriptors to be used for both ingress/egress packets > >> processing. If not specified - the default value 256 will be used > >> which will allow to place descriptor's pool into the internal CPPI > >> RAM on most of TI SoC. > >> > >> Signed-off-by: Grygorii Strashko > >> --- > >> Documentation/devicetree/bindings/net/cpsw.txt | 5 + > >> 1 file changed, 5 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt > >> b/Documentation/devicetree/bindings/net/cpsw.txt > >> index 5ad439f..b99d196 100644 > >> --- a/Documentation/devicetree/bindings/net/cpsw.txt > >> +++ b/Documentation/devicetree/bindings/net/cpsw.txt > >> @@ -35,6 +35,11 @@ Optional properties: > >> For example in dra72x-evm, pcf gpio has to be > >> driven low so that cpsw slave 0 and phy data > >> lines are connected via mux. > >> +- descs_pool_size : total number of CPDMA CPPI descriptors to be used for > >> +both ingress/egress packets processing. if not > >> +specified the default value 256 will be used which > >> +will allow to place descriptors pool into the > >> +internal CPPI RAM. > > Does it describe h/w? Why now module parameter? or even smth like ethtool > > num > > ring entries? > > > > It can be module parameter too. in general this is expected to be > one-time boot setting only. > > - OR > So, do you propose to use >ethtool -g ethX > >ethtool -G ethX [rx N] [tx N] > ? It has a little different names, but yes, why not? No need, maybe, butIt's just a proposition, at least I was thinking about it after proposition from +cc Schuyler Patton to leave rx desc num property. In this case it's possible to tune tx/rx desc num ratio, even with SRAM descs. > > Now cpdma has one pool for all RX/TX channels, so changing this settings > by ethtool will require: pause interfaces, reallocate cpdma pool, Pause can lead to losts only for rx, and only for very short time, so it's not very bad, especially when user knows what he is doing. > re-arrange buffers between channels, resume interface. Correct? correct. But, some alternative variants can be used, like replacing descriptors. Shrink num of desc for every channels to 1, replace/add others, and expand. In this case no losts, but it's harder to debug issues after > > How do you think - we can move forward with one pool or better to have two > (Rx and Tx)? I think one is enough, just split, if no harm on perf. > > Wouldn't it be reasonable to still have DT (or module) parameter to avoid > cpdma reconfiguration on system startup (pause/resume interfaces) (faster > boot)? Would be, your choice, but it's not flexible. > > How about cpdma re-allocation policy (with expectation that is shouldn't > happen too often)? > - increasing of Rx, Tx will grow total number of physically allocated buffers > (total_desc_num) > - decreasing of Rx, Tx will just change number of available buffers (no > memory re-allocation) > > - OR > Can we move forward with current patch (total number of CPDMA CPPI > descriptors defined in DT) > and add ethtool -G ethX [rx N] [tx N] which will allow to re-split descs > between RX and TX? No objections, It anyway requires re-allocations. Re-split of Rx and Tx will not have a lot changes as most code exists already. > > > > -- > regards, > -grygorii
Re: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.
On Fri, Dec 02, 2016 at 09:36:42AM +0100, Thomas Gleixner wrote: > On Fri, 2 Dec 2016, David Gibson wrote: > > On Thu, Dec 01, 2016 at 12:59:51PM +0100, Thomas Gleixner wrote: > > > So I assume that you are talking about a VM which was not scheduled by the > > > host due to overcommitment (who ever thought that this is a good idea) or > > > whatever other reason (yes, people were complaining about wreckage caused > > > by stopping kernels with debuggers) for a long enough time to trigger that > > > overflow situation. If that's the case then the unsigned conversion will > > > just make it more unlikely but it still will happen. > > > > It was essentially the stopped by debugger case. I forget exactly > > why, but the guest was being explicitly stopped from outside, it > > wasn't just scheduling lag. I think it was something in the vicinity > > of 10 minutes stopped. > > Ok. Debuggers stopping stuff is one issue, but if I understood Liav > correctly, then he is seing the issue on a heavy loaded machine. Right. I can't speak to other situations which might trigger this. > Liav, can you please describe the scenario in detail? Are you observing > this on bare metal or in a VM which gets scheduled out long enough or was > there debugging/hypervisor intervention involved? > > > It's long enough ago that I can't be sure, but I thought we'd tried > > various different stoppage periods, which should have also triggered > > the unsigned overflow you're describing, and didn't observe the crash > > once the change was applied. Note that there have been other changes > > to the timekeeping code since then, which might have made a > > difference. > > > > I agree that it's not reasonable for the guest to be entirely > > unaffected by such a large stoppage: I'd have no complaints if the > > guest time was messed up, and/or it spewed warnings. But complete > > guest death seems a rather more fragile response to the situation than > > we'd like. > > Guests death? Is it really dead/crashed or just stuck in that endless loop > trying to add that huge negative value piecewise? Well, I don't know. But the point was it was unusable from the console, and didn't come back any time soon. > That's at least what Liav was describing as he mentioned > __iter_div_u64_rem() explicitely. > > While I'm less worried about debuggers, I worry about the real thing. > > I agree that we should not starve after resume from a debug stop, but in > that case the least of my worries is time going backwards. > > Though if the signed mult overrun is observable in a live system, then we > need to worry about time going backwards even with the unsigned > conversion. Simply because once we fixed the starvation issue people with > insane enough setups will trigger the unsigned overrun and complain about > time going backwards. > > Thanks, > > tglx > > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
On 12/02/2016 06:39 PM, Bjorn Helgaas wrote:
> On Thu, Dec 01, 2016 at 11:08:23PM -0500, Jon Masters wrote:
>> Let's see if I summarized this correctly...
>>
>> 1. The MMIO registers for the host bridge itself need to be described
>>somewhere, especially if we need to find those in a quirk and poke
>>them. Since those registers are very much part of the bridge device,
>>it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.
>>
>> 2. The address space covering these registers MUST be described as a
>>ResourceConsumer in order to avoid accidentally exposing them as
>>available for use by downstream devices on the PCI bus.
>>
>> 3. The ACPI specification allows for resources of the type "Memory32Fixed".
>>This is a macro that doesn't have the notion of a producer or consumer.
>>HOWEVER various interpretations seem to be that this could/should
>>default to being interpreted as a consumed region.
>
> I agree; I think that per spec, Memory24, Memory32, Memory32Fixed, IO,
> and FixedIO should all be for consumed resources, not for bridge
> windows, since they don't have the notion of producer.
Ok. If we ultimately codify this somewhere as the general Linux kernel
consensus (Rafael?) then we can also go and get the various ARM server
specs updated to reflect this in (for e.g.) reference firmware builds.
> I'm pretty sure there's x86 firmware in the field that uses these for
> windows, so I think we have to accept that usage, at least on x86.
Ok. I was pondering how to even go about finding that out, but even if
I scheduled a job across RH's infra to look, that would be a drop in
the bucket of possible machines that might be out there doing this.
> Per spec, we should ignore the Consumer/Producer bit in Word/DWord/QWord
> descriptors. In bridge devices on x86, I think we have to treat them as
> producers (windows) because that's how they've been typically used.
Ok.
>> BUT if we were to do that, it would break existing shipping systems since
>> there are quirks out there that use this form to find the base CSR:
>>
>>if (acpi_res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
>> fixed32 = &acpi_res->data.fixed_memory32;
>> port->csr_base = ioremap(fixed32->address,
>> fixed32->address_length);
>> return AE_CTRL_TERMINATE;
>> }
>
> I think this is a valid usage of FixedMemory32 in terms of the spec.
> Linux currently handles this as a window if it appears in a PNP0A03
> device because some x86 firmware used it that way.
>
> We might be able to handle it differently on arm64, e.g., by making an
> arm64 version of pci_acpi_root_prepare_resources() that checks for
> IORESOURCE_WINDOW.
This is something we should figure out the consensus on and codify.
>> 2. What would happen if we had a difference policy on arm64 for such
>>resources. x86 has an "exception" for accessing the config space
>>using IO port 0xCF8-0xCFF (a fairly reasonable exception!) and
>>we can make the rules for a new platform (i.e. actually prescribe
>>exactly what the behavior is, rather than have it not be defined).
>>This is of course terrible in that existing BIOS vendors and so on
>>won't necessarily know this when working on ARM ACPI later on.
>
>> Indeed. And in the case of m400, it is currently this in shipping systems:
>>
>>Memory32Fixed (ReadWrite,
>> 0x1F50, // Address Base
>> 0x0001, // Address Length
>> )
>
> [0.822990] pci_bus :00: root bus resource [mem
> 0x1f2b-0x1f2b]
I think this is wrong. The PCI core thinks [mem 0x1f2b-0x1f2b]
is available for use by devices on bus :00, but I think you're
saying it is consumed by the bridge itself, not forwarded down to PCI.
>
> I think this ASL is perfectly spec-compliant, and what's wrong is the
> way Linux is interpreting it.
>
> I'm not clear on what's terrible about idea 2. I think it's basically
> what I suggested above, i.e., something like the patch below, which I
> think (hope) would keep us from thinking that region is a window.
I was guarded because I like harmony between architectures (where it
makes sense). But that said, there is nothing to prevent having a
different interpretation on ARM, as long as everyone agrees on it.
> Even without this patch, I don't think it's a show-stopper to have
> Linux mistakenly thinking this region is routed to PCI, because the
> driver does reserve it and the PCI core will never try to use it.
Ok. So are you happy with pulling in Duc's v4 patch and retaining
status quo on the bridge resources for 4.10? We can continue to
discuss this and ultimately set a direction for the spec, as well
as clean up existing and future designs (certainly the latter) to
ensure all possible resources used by a platform are describ
Re: [PATCH v5 1/6] usb: separate out sysdev pointer from usb_bus
Hi all, On Thu, Nov 17, 2016 at 05:13:43PM +0530, Sriram Dash wrote: > From: Arnd Bergmann > > For xhci-hcd platform device, all the DMA parameters are not > configured properly, notably dma ops for dwc3 devices. > > The idea here is that you pass in the parent of_node along with > the child device pointer, so it would behave exactly like the > parent already does. The difference is that it also handles all > the other attributes besides the mask. > > sysdev will represent the physical device, as seen from firmware > or bus.Splitting the usb_bus->controller field into the > Linux-internal device (used for the sysfs hierarchy, for printks > and for power management) and a new pointer (used for DMA, > DT enumeration and phy lookup) probably covers all that we really > need. > > Signed-off-by: Arnd Bergmann > Signed-off-by: Sriram Dash > Tested-by: Baolin Wang > Cc: Felipe Balbi > Cc: Grygorii Strashko > Cc: Sinjan Kumar > Cc: David Fisher > Cc: Catalin Marinas > Cc: "Thang Q. Nguyen" > Cc: Yoshihiro Shimoda > Cc: Stephen Boyd > Cc: Bjorn Andersson > Cc: Ming Lei > Cc: Jon Masters > Cc: Dann Frazier > Cc: Peter Chen > Cc: Leo Li > --- > Changes in v5: > - No update > > Changes in v4: > - No update > > Changes in v3: > - usb is_device_dma_capable instead of directly accessing > dma props. > > Changes in v2: > - Split the patch wrt driver I didn't notice this series had been reposted a few times. For some reason, this wasn't that easy to find in search engines... Anyway, when the whole series is applied, this fixes my XHCI probe issues for DWC3 host mode. Thanks! Tested-by: Brian Norris But I noticed that Felipe has applied patches 5 and 6 in -next, while the rest are still outstanding. That means I hit the dma_mask WARN_ON() in xhci-plat.c, and it eventually fails to probe with -EIO still: [2.060272] [ cut here ] [2.064908] WARNING: CPU: 5 PID: 1 at drivers/usb/host/xhci-plat.c:159 xhci_plat_probe+0x5c/0x444 ... [2.25] [] xhci_plat_probe+0x5c/0x444 [2.294456] [] platform_drv_probe+0x60/0xac [2.300200] [] driver_probe_device+0x12c/0x2a0 [2.306204] [] __driver_attach+0x84/0xb0 [2.311687] [] bus_for_each_dev+0x9c/0xcc [2.317256] [] driver_attach+0x2c/0x34 [2.322566] [] bus_add_driver+0xf0/0x1f4 [2.328049] [] driver_register+0x9c/0xe8 [2.333530] [] __platform_driver_register+0x60/0x6c [2.339968] [] xhci_plat_init+0x2c/0x34 [2.345366] [] do_one_initcall+0xa4/0x13c [2.350936] [] kernel_init_freeable+0x1bc/0x274 [2.357026] [] kernel_init+0x18/0x104 [2.362247] [] ret_from_fork+0x10/0x50 [2.374615] xhci-hcd: probe of xhci-hcd.1.auto failed with error -5 [2.380962] [ cut here ] [2.385588] WARNING: CPU: 4 PID: 1 at drivers/usb/host/xhci-plat.c:159 xhci_plat_probe+0x5c/0x444 ... [2.637372] [] xhci_plat_probe+0x5c/0x444 [2.642941] [] platform_drv_probe+0x60/0xac [2.648685] [] driver_probe_device+0x12c/0x2a0 [2.654688] [] __driver_attach+0x84/0xb0 [2.660170] [] bus_for_each_dev+0x9c/0xcc [2.665739] [] driver_attach+0x2c/0x34 [2.671048] [] bus_add_driver+0xf0/0x1f4 [2.676532] [] driver_register+0x9c/0xe8 [2.682012] [] __platform_driver_register+0x60/0x6c [2.688450] [] xhci_plat_init+0x2c/0x34 [2.693845] [] do_one_initcall+0xa4/0x13c [2.699415] [] kernel_init_freeable+0x1bc/0x274 [2.705505] [] kernel_init+0x18/0x104 [2.710726] [] ret_from_fork+0x10/0x50 [2.716075] xhci-hcd: probe of xhci-hcd.2.auto failed with error -5 What's happening with patches 1-4? Regards, Brian
[PATCH] crypto: rsa - fix a potential race condition in build
When building kernel with RSA enabled with multithreaded, the below compile failure might be caught: | /buildarea/kernel-source/crypto/rsa_helper.c:18:28: fatal error: rsapubkey-asn1.h: No such file or directory | #include "rsapubkey-asn1.h" | ^ | compilation terminated. | CC crypto/rsa-pkcs1pad.o | CC crypto/algboss.o | CC crypto/testmgr.o | make[3]: *** [/buildarea/kernel-source/scripts/Makefile.build:289: crypto/rsa_helper.o] Error 1 | make[3]: *** Waiting for unfinished jobs | make[2]: *** [/buildarea/kernel-source/Makefile:969: crypto] Error 2 | make[1]: *** [Makefile:150: sub-make] Error 2 | make: *** [Makefile:24: __sub-make] Error 2 The header file is not generated before rsa_helper is compiled, so adding dependency to avoid such issue. Signed-off-by: Yang Shi --- crypto/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/crypto/Makefile b/crypto/Makefile index 99cc64a..8db39f9 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -40,6 +40,7 @@ obj-$(CONFIG_CRYPTO_ECDH) += ecdh_generic.o $(obj)/rsapubkey-asn1.o: $(obj)/rsapubkey-asn1.c $(obj)/rsapubkey-asn1.h $(obj)/rsaprivkey-asn1.o: $(obj)/rsaprivkey-asn1.c $(obj)/rsaprivkey-asn1.h +$(obj)/rsa_helper.o: $(obj)/rsa_helper.c $(obj)/rsaprivkey-asn1.h clean-files += rsapubkey-asn1.c rsapubkey-asn1.h clean-files += rsaprivkey-asn1.c rsaprivkey-asn1.h -- 2.0.2
Re: [PATCH v4 9/9] media: venus: enable building of Venus video driver
Hi Stanimir,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on next-20161202]
[cannot apply to v4.9-rc7]
[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/Stanimir-Varbanov/Qualcomm-video-decoder-encoder-driver/20161203-054705
base: git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/media/platform/qcom/venus/hfi_venus.c: In function
'venus_tzbsp_set_video_state':
>> drivers/media/platform/qcom/venus/hfi_venus.c:455:9: error: implicit
>> declaration of function 'qcom_scm_video_set_state'
>> [-Werror=implicit-function-declaration]
return qcom_scm_video_set_state(state, 0);
^~~~
cc1: some warnings being treated as errors
vim +/qcom_scm_video_set_state +455
drivers/media/platform/qcom/venus/hfi_venus.c
93fa34d2 Stanimir Varbanov 2016-12-01 439
93fa34d2 Stanimir Varbanov 2016-12-01 440 pkt = (struct
hfi_sys_set_resource_pkt *) packet;
93fa34d2 Stanimir Varbanov 2016-12-01 441
93fa34d2 Stanimir Varbanov 2016-12-01 442 ret = pkt_sys_set_resource(pkt,
id, size, addr, cookie);
93fa34d2 Stanimir Varbanov 2016-12-01 443 if (ret)
93fa34d2 Stanimir Varbanov 2016-12-01 444 return ret;
93fa34d2 Stanimir Varbanov 2016-12-01 445
93fa34d2 Stanimir Varbanov 2016-12-01 446 ret =
venus_iface_cmdq_write(hdev, pkt);
93fa34d2 Stanimir Varbanov 2016-12-01 447 if (ret)
93fa34d2 Stanimir Varbanov 2016-12-01 448 return ret;
93fa34d2 Stanimir Varbanov 2016-12-01 449
93fa34d2 Stanimir Varbanov 2016-12-01 450 return 0;
93fa34d2 Stanimir Varbanov 2016-12-01 451 }
93fa34d2 Stanimir Varbanov 2016-12-01 452
93fa34d2 Stanimir Varbanov 2016-12-01 453 static int
venus_tzbsp_set_video_state(enum tzbsp_video_state state)
93fa34d2 Stanimir Varbanov 2016-12-01 454 {
93fa34d2 Stanimir Varbanov 2016-12-01 @455 return
qcom_scm_video_set_state(state, 0);
93fa34d2 Stanimir Varbanov 2016-12-01 456 }
93fa34d2 Stanimir Varbanov 2016-12-01 457
93fa34d2 Stanimir Varbanov 2016-12-01 458 static int venus_boot_core(struct
venus_hfi_device *hdev)
93fa34d2 Stanimir Varbanov 2016-12-01 459 {
93fa34d2 Stanimir Varbanov 2016-12-01 460 struct device *dev =
hdev->core->dev;
93fa34d2 Stanimir Varbanov 2016-12-01 461 static const unsigned int
max_tries = 100;
93fa34d2 Stanimir Varbanov 2016-12-01 462 u32 ctrl_status = 0;
93fa34d2 Stanimir Varbanov 2016-12-01 463 unsigned int count = 0;
:: The code at line 455 was first introduced by commit
:: 93fa34d264d32979ec1634d8fc366d7cf6ff453d media: venus: hfi: add Venus
HFI files
:: TO: Stanimir Varbanov
:: CC: 0day robot
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH] Yama: allow access for the current ptrace parent
From: Josh Stone
Under ptrace_scope=1, it's possible to have a tracee that is already
ptrace-attached, but is no longer a direct descendant. For instance, a
forking daemon will be re-parented to init, losing its ancestry to the
tracer that launched it.
The tracer can continue using ptrace in that state, but it will be
denied other accesses that check PTRACE_MODE_ATTACH, like process_vm_rw
and various procfs files. There's no reason to prevent such access for
a tracer that already has ptrace control anyway.
This patch adds a case to ptracer_exception_found to allow access for
any task in the same thread group as the current ptrace parent.
Signed-off-by: Josh Stone
Cc: Kees Cook
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: linux-security-mod...@vger.kernel.org
Signed-off-by: Kees Cook
---
James, can you pull this into your -next tree? I made a tiny fix to the
comment style, but it is otherwise identical to what Josh sent originally.
---
security/yama/yama_lsm.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index 0309f2111c70..968e5e0a3f81 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -309,7 +309,7 @@ static int task_is_descendant(struct task_struct *parent,
* @tracer: the task_struct of the process attempting ptrace
* @tracee: the task_struct of the process to be ptraced
*
- * Returns 1 if tracer has is ptracer exception ancestor for tracee.
+ * Returns 1 if tracer has a ptracer exception ancestor for tracee.
*/
static int ptracer_exception_found(struct task_struct *tracer,
struct task_struct *tracee)
@@ -320,6 +320,18 @@ static int ptracer_exception_found(struct task_struct
*tracer,
bool found = false;
rcu_read_lock();
+
+ /*
+* If there's already an active tracing relationship, then make an
+* exception for the sake of other accesses, like process_vm_rw().
+*/
+ parent = ptrace_parent(tracee);
+ if (parent != NULL && same_thread_group(parent, tracer)) {
+ rc = 1;
+ goto unlock;
+ }
+
+ /* Look for a PR_SET_PTRACER relationship. */
if (!thread_group_leader(tracee))
tracee = rcu_dereference(tracee->group_leader);
list_for_each_entry_rcu(relation, &ptracer_relations, node) {
@@ -334,6 +346,8 @@ static int ptracer_exception_found(struct task_struct
*tracer,
if (found && (parent == NULL || task_is_descendant(parent, tracer)))
rc = 1;
+
+unlock:
rcu_read_unlock();
return rc;
--
2.7.4
--
Kees Cook
Nexus Security
Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
On Thu, Dec 01, 2016 at 11:08:23PM -0500, Jon Masters wrote:
> Hi Bjorn, Duc, Mark,
>
> I switched my brain to the on mode and went and read some specs, and a few
> tables, so here's my 2 cents on this...
>
> On 12/01/2016 06:22 PM, Duc Dang wrote:
> > On Thu, Dec 1, 2016 at 3:07 PM, Bjorn Helgaas wrote:
> >> On Thu, Dec 01, 2016 at 02:10:10PM -0800, Duc Dang wrote:
>
> > The SoC provide some number of RC bridges, each with a different base
> > for some mmio registers. Even if segment is legitimate in MCFG, there
> > is still a problem if a platform doesn't use the segment ordering
> > implied by the code. But the PNP0A03 _CRS does have this base address
> > as the first memory resource, so we could get it from there and not
> > have hard-coded addresses and implied ording in the quirk code.
>
> I'm confused. Doesn't the current code treat every item in PNP0A03
> _CRS as a window? Do you mean the first resource is handled
> differently somehow? The Consumer/Producer bit could allow us to do
> this by marking the RC MMIO space as "Consumer", but I didn't think
> that strategy was quite working yet.
>
> Let's see if I summarized this correctly...
>
> 1. The MMIO registers for the host bridge itself need to be described
>somewhere, especially if we need to find those in a quirk and poke
>them. Since those registers are very much part of the bridge device,
>it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.
>
> 2. The address space covering these registers MUST be described as a
>ResourceConsumer in order to avoid accidentally exposing them as
>available for use by downstream devices on the PCI bus.
>
> 3. The ACPI specification allows for resources of the type "Memory32Fixed".
>This is a macro that doesn't have the notion of a producer or consumer.
>HOWEVER various interpretations seem to be that this could/should
>default to being interpreted as a consumed region.
I agree; I think that per spec, Memory24, Memory32, Memory32Fixed, IO,
and FixedIO should all be for consumed resources, not for bridge
windows, since they don't have the notion of producer.
I'm pretty sure there's x86 firmware in the field that uses these for
windows, so I think we have to accept that usage, at least on x86.
> 4. At one point, a regression was added to the kernel:
>
>63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
>host bridge itself")
>
>Which lead to a series on conversations about what should happen
>for bridge resources (e.g. https://lkml.org/lkml/2015/3/24/962 )
>
> 5. This resulted in the following commit reverting point 4:
>
>2c62e8492ed7 ("x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff]
>available on PCI bus")
>
>Which also stated that:
>
>"This solution will also ease the way to consolidate ACPI PCI host
> bridge common code from x86, ia64 and ARM64"
>
> End of summary.
>
> So it seems that generally there is an aversion to having bridge resources
> be described in this manner and you would like to require that they be
> described e.g. using QWordMemory with a ResourceConsumer type?
Per spec, we should ignore the Consumer/Producer bit in Word/DWord/QWord
descriptors. In bridge devices on x86, I think we have to treat them as
producers (windows) because that's how they've been typically used.
> BUT if we were to do that, it would break existing shipping systems since
> there are quirks out there that use this form to find the base CSR:
>
>if (acpi_res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
> fixed32 = &acpi_res->data.fixed_memory32;
> port->csr_base = ioremap(fixed32->address,
> fixed32->address_length);
> return AE_CTRL_TERMINATE;
> }
I think this is a valid usage of FixedMemory32 in terms of the spec.
Linux currently handles this as a window if it appears in a PNP0A03
device because some x86 firmware used it that way.
We might be able to handle it differently on arm64, e.g., by making an
arm64 version of pci_acpi_root_prepare_resources() that checks for
IORESOURCE_WINDOW.
> 2. What would happen if we had a difference policy on arm64 for such
>resources. x86 has an "exception" for accessing the config space
>using IO port 0xCF8-0xCFF (a fairly reasonable exception!) and
>we can make the rules for a new platform (i.e. actually prescribe
>exactly what the behavior is, rather than have it not be defined).
>This is of course terrible in that existing BIOS vendors and so on
>won't necessarily know this when working on ARM ACPI later on.
> Indeed. And in the case of m400, it is currently this in shipping systems:
>
>Memory32Fixed (ReadWrite,
> 0x1F50, // Address Base
> 0x0001, // Address Length
> )
> >>> [0.8
Re: [PATCH net-next] liquidio: 'imply' ptp instead of 'select'
On 12/02/2016 03:04 PM, Arnd Bergmann wrote:
ptp now depends on the optional POSIX_TIMERS setting and fails to build
if we select it without that:
warning: (LIQUIDIO_VF && TI_CPTS) selects PTP_1588_CLOCK which has unmet direct
dependencies (NET && POSIX_TIMERS)
warning: (LIQUIDIO_VF && TI_CPTS) selects PTP_1588_CLOCK which has unmet direct
dependencies (NET && POSIX_TIMERS)
ERROR: "posix_clock_unregister" [drivers/ptp/ptp.ko] undefined!
ERROR: "posix_clock_register" [drivers/ptp/ptp.ko] undefined!
ERROR: "pps_unregister_source" [drivers/ptp/ptp.ko] undefined!
ERROR: "pps_event" [drivers/ptp/ptp.ko] undefined!
ERROR: "pps_register_source" [drivers/ptp/ptp.ko] undefined!
It seems that two patches have collided here, the build failure
is a result of the combination. Changing the new option to 'imply'
as well fixes it.
Fixes: 111fc64a237f ("liquidio CN23XX: VF registration")
Fixes: d1cbfd771ce8 ("ptp_clock: Allow for it to be optional")
Signed-off-by: Arnd Bergmann
I didn't know about this new "imply" thing. This seems like a plausible
fix, so...
Acked-by: David Daney
Thanks for fixing this up.
---
drivers/net/ethernet/cavium/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/Kconfig
b/drivers/net/ethernet/cavium/Kconfig
index bbc8bd16cb97..dcbce6cac63e 100644
--- a/drivers/net/ethernet/cavium/Kconfig
+++ b/drivers/net/ethernet/cavium/Kconfig
@@ -77,7 +77,7 @@ config OCTEON_MGMT_ETHERNET
config LIQUIDIO_VF
tristate "Cavium LiquidIO VF support"
depends on 64BIT && PCI_MSI
- select PTP_1588_CLOCK
+ imply PTP_1588_CLOCK
---help---
This driver supports Cavium LiquidIO Intelligent Server Adapter
based on CN23XX chips.
Re: [PATCH 2/7] net: ethernet: ti: cpdma: fix desc re-queuing
On Fri, Dec 02, 2016 at 10:45:07AM -0600, Grygorii Strashko wrote:
>
>
> On 12/02/2016 05:03 AM, Ivan Khoronzhuk wrote:
> > On Thu, Dec 01, 2016 at 05:34:27PM -0600, Grygorii Strashko wrote:
> >> The currently processing cpdma descriptor with EOQ flag set may
> >> contain two values in Next Descriptor Pointer field:
> >> - valid pointer: means CPDMA missed addition of new desc in queue;
> > It shouldn't happen in normal circumstances, right?
>
> it might happen, because desc push compete with desc pop.
> You can check stats values:
> chan->stats.misqueued
> chan->stats.requeue
> under different types of net-loads.
I've done this, of-course.
By whole logic the misqueued counter has to cover all cases.
But that's not true.
>
> TRM:
> "
> If the pNext pointer is initially NULL, and more packets need to be queued
> for transmit, the software
> application may alter this pointer to point to a newly appended descriptor.
> The EMAC will use the new
> pointer value and proceed to the next descriptor unless the pNext value has
> already been read. In this
> latter case, the transmitter will halt on the transmit channel in question,
> and the software application may
> restart it at that time. The software can detect this case by checking for an
> end of queue (EOQ) condition
> flag on the updated packet descriptor when it is returned by the EMAC.
> "
That's true. No issues in desc.
In the code no any place to update next_desc except submit function.
And this case is supposed to be caught here:
For submit:
cpdma_chan_submit()
spin_lock_irqsave(&chan->lock);
...
--->__cpdma_chan_submit()
...
--> desc_write(prev, hw_next, desc_dma); // here next pointer is updated,
it can be not in time
...
--> mode = desc_read(prev, hw_mode); // pay attention, it's read after
updating next pointer
--> if ((mode & CPDMA_DESC_EOQ) &&
--> (chan->state == CPDMA_STATE_ACTIVE)) { // here checked if it was late
update
-> chan_write(chan, hdp, desc_dma); // here transmit is restarted, if
needed
For process it only caught the fact of late update, but it has to be caught in
submit() already:
__cpdma_chan_process()
spin_lock_irqsave(&chan->lock);
--> if (mode & CPDMA_DESC_EOQ) // here transmit is restarted, if needed
-> chan_write(chan, hdp, desc_dma); // but w/o updating next pointer
Seems there is no place where hw_next is updated w/o updating hdp :-| in case
of late hw_next set. And that is strange. I know it happens, I've checked it
before of-course. Then I thought, maybe there is some problem with write order,
thus out of sync, nothing more.
>
>
> > So, why it happens only for egress channels? And Does that mean
> > there is some resynchronization between submit and process function,
> > or this is h/w issue?
>
> no hw issues. this patch just removes one unnecessary I/O access
No objections against patch. Anyway it's better then before.
Just want to know the real reason why it happens, maybe there is smth else.
>
> >
> >> - null: no more descriptors in queue.
> >> In the later case, it's not required to write to HDP register, but now
> >> CPDMA does it.
> >>
> >> Hence, add additional check for Next Descriptor Pointer != null in
> >> cpdma_chan_process() function before writing in HDP register.
> >>
> >> Signed-off-by: Grygorii Strashko
> >> ---
> >> drivers/net/ethernet/ti/davinci_cpdma.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
> >> b/drivers/net/ethernet/ti/davinci_cpdma.c
> >> index 0924014..379314f 100644
> >> --- a/drivers/net/ethernet/ti/davinci_cpdma.c
> >> +++ b/drivers/net/ethernet/ti/davinci_cpdma.c
> >> @@ -1152,7 +1152,7 @@ static int __cpdma_chan_process(struct cpdma_chan
> >> *chan)
> >>chan->count--;
> >>chan->stats.good_dequeue++;
> >>
> >> - if (status & CPDMA_DESC_EOQ) {
> >> + if ((status & CPDMA_DESC_EOQ) && chan->head) {
> >>chan->stats.requeue++;
> >>chan_write(chan, hdp, desc_phys(pool, chan->head));
> >>}
> >> --
> >> 2.10.1
> >>
>
> --
> regards,
> -grygorii
Re: [PATCH] Yama: allow access for the current ptrace parent
On Wed, Nov 30, 2016 at 5:24 PM, Josh Stone wrote:
> Under ptrace_scope=1, it's possible to have a tracee that is already
> ptrace-attached, but is no longer a direct descendant. For instance, a
> forking daemon will be re-parented to init, losing its ancestry to the
> tracer that launched it.
>
> The tracer can continue using ptrace in that state, but it will be
> denied other accesses that check PTRACE_MODE_ATTACH, like process_vm_rw
> and various procfs files. There's no reason to prevent such access for
> a tracer that already has ptrace control anyway.
>
> This patch adds a case to ptracer_exception_found to allow access for
> any task in the same thread group as the current ptrace parent.
Nice catch, thanks!
> Signed-off-by: Josh Stone
> Cc: Kees Cook
> Cc: James Morris
> Cc: "Serge E. Hallyn"
> Cc: linux-security-mod...@vger.kernel.org
> ---
> security/yama/yama_lsm.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
> index 0309f2111c70..da67a6e07a60 100644
> --- a/security/yama/yama_lsm.c
> +++ b/security/yama/yama_lsm.c
> @@ -309,7 +309,7 @@ static int task_is_descendant(struct task_struct *parent,
> * @tracer: the task_struct of the process attempting ptrace
> * @tracee: the task_struct of the process to be ptraced
> *
> - * Returns 1 if tracer has is ptracer exception ancestor for tracee.
> + * Returns 1 if tracer has a ptracer exception ancestor for tracee.
> */
> static int ptracer_exception_found(struct task_struct *tracer,
>struct task_struct *tracee)
> @@ -320,6 +320,17 @@ static int ptracer_exception_found(struct task_struct
> *tracer,
> bool found = false;
>
> rcu_read_lock();
> +
> + /* If there's already an active tracing relationship, then make an
I'll adjust the comment style here and add it to my tree for -next.
> +* exception for the sake of other accesses, like process_vm_rw.
> +*/
> + parent = ptrace_parent(tracee);
> + if (parent != NULL && same_thread_group(parent, tracer)) {
> + rc = 1;
> + goto unlock;
> + }
> +
> + /* Look for a PR_SET_PTRACER relationship. */
> if (!thread_group_leader(tracee))
> tracee = rcu_dereference(tracee->group_leader);
> list_for_each_entry_rcu(relation, &ptracer_relations, node) {
> @@ -334,6 +345,8 @@ static int ptracer_exception_found(struct task_struct
> *tracer,
>
> if (found && (parent == NULL || task_is_descendant(parent, tracer)))
> rc = 1;
> +
> +unlock:
> rcu_read_unlock();
>
> return rc;
> --
> 2.9.3
>
Thanks!
-Kees
--
Kees Cook
Nexus Security
Re: [PATCH net-next] liquidio: 'imply' ptp instead of 'select'
On Sat, 3 Dec 2016, Arnd Bergmann wrote:
> ptp now depends on the optional POSIX_TIMERS setting and fails to build
> if we select it without that:
>
> warning: (LIQUIDIO_VF && TI_CPTS) selects PTP_1588_CLOCK which has unmet
> direct dependencies (NET && POSIX_TIMERS)
> warning: (LIQUIDIO_VF && TI_CPTS) selects PTP_1588_CLOCK which has unmet
> direct dependencies (NET && POSIX_TIMERS)
> ERROR: "posix_clock_unregister" [drivers/ptp/ptp.ko] undefined!
> ERROR: "posix_clock_register" [drivers/ptp/ptp.ko] undefined!
> ERROR: "pps_unregister_source" [drivers/ptp/ptp.ko] undefined!
> ERROR: "pps_event" [drivers/ptp/ptp.ko] undefined!
> ERROR: "pps_register_source" [drivers/ptp/ptp.ko] undefined!
>
> It seems that two patches have collided here, the build failure
> is a result of the combination. Changing the new option to 'imply'
> as well fixes it.
>
> Fixes: 111fc64a237f ("liquidio CN23XX: VF registration")
> Fixes: d1cbfd771ce8 ("ptp_clock: Allow for it to be optional")
> Signed-off-by: Arnd Bergmann
Acked-by: Nicolas Pitre
> ---
> drivers/net/ethernet/cavium/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/cavium/Kconfig
> b/drivers/net/ethernet/cavium/Kconfig
> index bbc8bd16cb97..dcbce6cac63e 100644
> --- a/drivers/net/ethernet/cavium/Kconfig
> +++ b/drivers/net/ethernet/cavium/Kconfig
> @@ -77,7 +77,7 @@ config OCTEON_MGMT_ETHERNET
> config LIQUIDIO_VF
> tristate "Cavium LiquidIO VF support"
> depends on 64BIT && PCI_MSI
> - select PTP_1588_CLOCK
> + imply PTP_1588_CLOCK
> ---help---
> This driver supports Cavium LiquidIO Intelligent Server Adapter
> based on CN23XX chips.
> --
> 2.9.0
>
>
Re: [PATCH] iproute2: ss: escape all null bytes in abstract unix domain socket
On Fri, 02 Dec 2016 10:59:56 -0800 Eric Dumazet wrote: > On Sat, 2016-11-12 at 10:17 +0300, Stephen Hemminger wrote: > > On Sat, 29 Oct 2016 22:20:19 +0300 > > Isaac Boukris wrote: > > > > > Abstract unix domain socket may embed null characters, > > > these should be translated to '@' when printed by ss the > > > same way the null prefix is currently being translated. > > > > > > Signed-off-by: Isaac Boukris > > > > Applied > > Probably not a good idea to have : > >for (int i = 0; i < len; i++) >if (name[i] == '\0') >name[i] = '@'; > > ss.c: In function 'unix_show_sock': > ss.c:3128:4: error: 'for' loop initial declarations are only allowed in C99 > mode > ss.c:3128:4: note: use option -std=c99 or -std=gnu99 to compile your code > make[1]: *** [ss.o] Error 1 > > > Thanks, fixed by patch from Simon
[PATCH] x86: Unbreak "make isoimage" with isolinux
From: Andi Kleen make isoimage doesn't work on recent Fedora versions, the resulting image always fails with "Failed to load ldlinux.c32 ..." The fix (originally found by "SebbiUltimate" on reddit) just copies the file into the iso image. On Fedora, this is somewhat complicated by the fact that the syslinux package was split into syslinux and "syslinux-nonlinux", but the ldlinux.c32 file needed to boot Linux is actually in the syslinux-nonlinux package(!). So it will only work when that package is installed, which updates from older versions don't do. Signed-off-by: Andi Kleen --- arch/x86/boot/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index 12ea8f8384f4..8d0919872c5c 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -160,6 +160,8 @@ isoimage: $(obj)/bzImage -rm -rf $(obj)/isoimage mkdir $(obj)/isoimage for i in lib lib64 share end ; do \ + [ -r /usr/$$i/syslinux/ldlinux.c32 ] && \ + cp /usr/$$i/syslinux/ldlinux.c32 $(obj)/isoimage ; \ if [ -f /usr/$$i/syslinux/isolinux.bin ] ; then \ cp /usr/$$i/syslinux/isolinux.bin $(obj)/isoimage ; \ if [ -f /usr/$$i/syslinux/ldlinux.c32 ]; then \ -- 2.9.3
[PATCH] perf/x86: Fix exclusion of BTS and LBR for Goldmont
From: Andi Kleen
The earlier patch ccbebba4 allowed enabling PT and LBR at the same
time on Goldmont. However it also allowed enabling BTS and LBR
at the same time, which is still not supported. Fix this by
bypassing the check only for PT.
Marking for stable because this allows crashing kernels. Also
should be merged for 4.9.
Fixes: ccbebba4 ("erf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core
supports it")
Cc: alexander.shish...@intel.com
Cc: kan.li...@intel.com
Cc: sta...@vger.kernel.org # 4.6+
Signed-off-by: Andi Kleen
---
arch/x86/events/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index d0efb5cb1b00..baa1eed55e88 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -364,7 +364,7 @@ int x86_add_exclusive(unsigned int what)
{
int i;
- if (x86_pmu.lbr_pt_coexist)
+ if (what == x86_lbr_exclusive_pt && x86_pmu.lbr_pt_coexist)
return 0;
if (!atomic_inc_not_zero(&x86_pmu.lbr_exclusive[what])) {
@@ -387,7 +387,7 @@ fail_unlock:
void x86_del_exclusive(unsigned int what)
{
- if (x86_pmu.lbr_pt_coexist)
+ if (what == x86_lbr_exclusive_pt && x86_pmu.lbr_pt_coexist)
return;
atomic_dec(&x86_pmu.lbr_exclusive[what]);
--
2.9.3
Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation
On Fri, Dec 2, 2016 at 2:55 PM, Andy Lutomirski wrote: >> >> Honestly, I think Intel should clean up their documentation. > > I'm not sure I follow. If a user program gets migrated, it might end > up doing cross-modification when it expects self-modification. If > that trips the program up, is that a user bug or a kernel bug? Well, the user may not see it as a cross-modification. Example: user compiles a program, and writes out the new binary. That write goes to the page cache. The user then immediately executes that program. It's technically a "cross modification", because the build that wrote the page cache ran on one CPU, and then it gets loaded on another. Not, page faulting the binary does bring in a known serializing instruction: iret. But let's theorize that we have your "optimistic sysret" return path because sometimes it can happen. So the "iret" isn't exactly fundamental. But we know we will write %cr2, which is a serializing instruction. But that's not fundamental either, because we could just have a program just load the object file into its own address space using the dynamic linker. And if you don't unmap anything, there won't be any TLB flushes. Now, that is safe too, but by then we're not even relying on simply the fact that the code couldn't even have been in any virtual caches in the running environment, so it _must_ have come from the physically indexed data cache. So no actual serializing instruction even _needed_. So there is no room for any cache I$ coherency issue at any point, but note how we got to the point where we're now basically depending on some fairly fundamental logic that is not in the Intel documentation? THAT is what I don't like. I don't doubt for a moment that what we're doing is entirely coherent, and we're fine. But the intel memory ordering documentation simply doesn't cover this situation at all. The "real" memory ordering documentation only covers the normal data cache. And then they handwave the "self-modifying code" situation with incomplete examples and just bullshit "you need a serializing instruction", which clearly isn't actually the case, and is also something that we very much don't even do. It would be better if here was actual documentation, and we had some nice clear "yeah, we don't need any stinking serializing instructions, because we're already doing X". Linus
[PATCH 1/2] net: ethernet: sxgbe: do not use xmit_lock in tx completion handler
The driver already uses its private lock for synchronization between the
xmit function and the xmit completion handler, making the additional use of
the xmit_lock unnecessary.
Furthermore the driver does not set NETIF_F_LLTX resulting in xmit to be
called with the xmit_lock held and then taking the private lock.
On the other hand the xmit completion handler uses the reverse locking
order, by first taking the private lock, and then the xmit_lock, which
leads to the potential danger of a deadlock.
Fix this issue by not taking the xmit_lock in the completion handler.
By doing this also remove an unnecessary double check for a stopped tx
queue.
Signed-off-by: Lino Sanfilippo
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
Please note that this patch is only compile tested.
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 5dbe406..578cbec 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -782,14 +782,9 @@ static void sxgbe_tx_queue_clean(struct sxgbe_tx_queue
*tqueue)
/* wake up queue */
if (unlikely(netif_tx_queue_stopped(dev_txq) &&
sxgbe_tx_avail(tqueue, tx_rsize) > SXGBE_TX_THRESH(priv)))
{
- netif_tx_lock(priv->dev);
- if (netif_tx_queue_stopped(dev_txq) &&
- sxgbe_tx_avail(tqueue, tx_rsize) > SXGBE_TX_THRESH(priv)) {
- if (netif_msg_tx_done(priv))
- pr_debug("%s: restart transmit\n", __func__);
- netif_tx_wake_queue(dev_txq);
- }
- netif_tx_unlock(priv->dev);
+ if (netif_msg_tx_done(priv))
+ pr_debug("%s: restart transmit\n", __func__);
+ netif_tx_wake_queue(dev_txq);
}
spin_unlock(&tqueue->tx_lock);
--
1.9.1
Avoid deadlock situation due to use of xmit_lock
Hi, after stumbling over a potential deadlock situation in the altera driver (see http://marc.info/?l=linux-netdev&m=148054615230447&w=2), I checked all other ethernet drivers for the same issue and actually found it in 2 more, namely stmmac, and sxgbe. Please see the commit messages for a description of the problem. These 2 patches fix the concerning drivers. Regards, Lino
[PATCH 2/2] net: ethernet: stmmac: do not use xmit_lock in tx completion handler
The driver already uses its private lock for synchronization between the
xmit function and the xmit completion handler, making the additional use of
the xmit_lock unnecessary.
Furthermore the driver does not set NETIF_F_LLTX resulting in xmit to be
called with the xmit_lock held and then taking the private lock.
On the other hand the xmit completion handler uses the reverse locking
order, by first taking the private lock, and then the xmit_lock, which
leads to the potential danger of a deadlock.
Fix this issue by not taking the xmit_lock in the completion handler.
By doing this also remove an unnecessary double check for a stopped tx
queue.
Signed-off-by: Lino Sanfilippo
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
Please note that this patch is only compile tested.
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 48a4e84..8def423 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1380,14 +1380,9 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
if (unlikely(netif_queue_stopped(priv->dev) &&
stmmac_tx_avail(priv) > STMMAC_TX_THRESH)) {
- netif_tx_lock(priv->dev);
- if (netif_queue_stopped(priv->dev) &&
- stmmac_tx_avail(priv) > STMMAC_TX_THRESH) {
- netif_dbg(priv, tx_done, priv->dev,
- "%s: restart transmit\n", __func__);
- netif_wake_queue(priv->dev);
- }
- netif_tx_unlock(priv->dev);
+ netif_dbg(priv, tx_done, priv->dev,
+ "%s: restart transmit\n", __func__);
+ netif_wake_queue(priv->dev);
}
if ((priv->eee_enabled) && (!priv->tx_path_in_lpi_mode)) {
--
1.9.1
[PATCH net-next] liquidio: 'imply' ptp instead of 'select'
ptp now depends on the optional POSIX_TIMERS setting and fails to build
if we select it without that:
warning: (LIQUIDIO_VF && TI_CPTS) selects PTP_1588_CLOCK which has unmet direct
dependencies (NET && POSIX_TIMERS)
warning: (LIQUIDIO_VF && TI_CPTS) selects PTP_1588_CLOCK which has unmet direct
dependencies (NET && POSIX_TIMERS)
ERROR: "posix_clock_unregister" [drivers/ptp/ptp.ko] undefined!
ERROR: "posix_clock_register" [drivers/ptp/ptp.ko] undefined!
ERROR: "pps_unregister_source" [drivers/ptp/ptp.ko] undefined!
ERROR: "pps_event" [drivers/ptp/ptp.ko] undefined!
ERROR: "pps_register_source" [drivers/ptp/ptp.ko] undefined!
It seems that two patches have collided here, the build failure
is a result of the combination. Changing the new option to 'imply'
as well fixes it.
Fixes: 111fc64a237f ("liquidio CN23XX: VF registration")
Fixes: d1cbfd771ce8 ("ptp_clock: Allow for it to be optional")
Signed-off-by: Arnd Bergmann
---
drivers/net/ethernet/cavium/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/Kconfig
b/drivers/net/ethernet/cavium/Kconfig
index bbc8bd16cb97..dcbce6cac63e 100644
--- a/drivers/net/ethernet/cavium/Kconfig
+++ b/drivers/net/ethernet/cavium/Kconfig
@@ -77,7 +77,7 @@ config OCTEON_MGMT_ETHERNET
config LIQUIDIO_VF
tristate "Cavium LiquidIO VF support"
depends on 64BIT && PCI_MSI
- select PTP_1588_CLOCK
+ imply PTP_1588_CLOCK
---help---
This driver supports Cavium LiquidIO Intelligent Server Adapter
based on CN23XX chips.
--
2.9.0
Re: [PATCH 2/2] HID: i2c-hid: support regulator power on/off
On Fri, Dec 02, 2016 at 02:19:00PM -0800, Brian Norris wrote: > On some boards, we need to enable a regulator before using the HID, and > it's also nice to save power in suspend by disabling it. Support an > optional "vdd-supply" and a companion initialization delay. > > Signed-off-by: Brian Norris > Signed-off-by: Caesar Wang > Cc: Jiri Kosina > Cc: linux-in...@vger.kernel.org > --- > v2: > * support compatible property for wacom, with specific "vdd-supply" > * name > * support the 100ms delay needed for this digitizer > * target regulator support only at specific device > > v3: > * drop Wacom specifics and allow this to be used generically > * add "init-delay-ms" property support > > v4: > * use devm_regulator_get() (with a 'dummy' regulator for most cases) >instead of _optional() version, to make code less conditional (Dmitry) > * fix but where 'init_delay_ms' wasn't getting assigned properly > * disable regulator in probe() failure path > --- > drivers/hid/i2c-hid/i2c-hid.c | 44 > +-- > include/linux/i2c/i2c-hid.h | 6 ++ > 2 files changed, 48 insertions(+), 2 deletions(-) > > diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c > index b3ec4f2de875..5c6e037613d7 100644 > --- a/drivers/hid/i2c-hid/i2c-hid.c > +++ b/drivers/hid/i2c-hid/i2c-hid.c > @@ -38,6 +38,7 @@ > #include > #include > #include > +#include > > #include > > @@ -937,6 +938,10 @@ static int i2c_hid_of_probe(struct i2c_client *client, > } > pdata->hid_descriptor_address = val; > > + ret = of_property_read_u32(dev->of_node, "init-delay-ms", &val); > + if (!ret) > + pdata->init_delay_ms = val; > + > return 0; > } > > @@ -983,6 +988,15 @@ static int i2c_hid_probe(struct i2c_client *client, > ihid->pdata = *platform_data; > } > > + ihid->pdata.supply = devm_regulator_get(&client->dev, "vdd"); Oh, haveni't noticed that the rest of the driver does not use devm. Well, I'll leave it up to hid-i2c folks to decide if they are OK with mixing up the managed and non-managed resources, it seems safe to me in this case. Reviewed-by: Dmitry Torokhov Thanks. -- Dmitry
Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation
On Fri, Dec 2, 2016 at 1:10 PM, Linus Torvalds wrote: > On Fri, Dec 2, 2016 at 12:41 PM, Andy Lutomirski wrote: >> >> Because, if so, we should maybe serialize whenever we migrate a >> process to a different CPU. > > The intel docs are bad on this issue. > > Technically what we do could fall under the "cross-modifying code" > case, where one CPU does the write, and then we run it on another CPU. > > And no, we do *not* do a serializing instruction before returning to > user space. Sure, we might do an iret (which is serializing), but we > equally well might be doing a systret (which is not). > > Honestly, I think Intel should clean up their documentation. > I'm not sure I follow. If a user program gets migrated, it might end up doing cross-modification when it expects self-modification. If that trips the program up, is that a user bug or a kernel bug? Admittedly, I'd be very surprised if this happened in practice. Migration is *slow*, caches tend to get blown away, lots of code gets executed, etc. Presumably any prefetched / trace cached / decoded / i-cached user code is long gone when we migrate.
Re: Odd build breakage in 4.9-rc7
On 2016-12-02 3:11 PM, Nicolas Pitre wrote: On Thu, 1 Dec 2016, Paul Bolle wrote: On Thu, 2016-12-01 at 12:42 -0500, Nicolas Pitre wrote: OK I understand what the problem is. However most of those hunks below are definitely wrong. ;-) Probably. By now I've narrowed it down to just these two hunks: And they're both wrong. ;-) There is no relation between MODVERSIONS and TRIM_UNUSED_KSYMS. I'm trying to determine the best way to fix it. Stay tuned. Will do. I'm curious to see what a proper fix might look like. Here it is: - >8 Subject: kbuild: fix building bzImage with CONFIG_TRIM_UNUSED_KSYMS enabled When building a specific target such as bzImage, modules aren't normally built. However if CONFIG_TRIM_UNUSED_KSYMS is enabled, no built modules means none of the exported symbols are used and therefore they will all be trimmed away from the final kernel. A subsequent "make modules" will fail because modpost cannot find the needed symbols for those modules in the kernel binary. Let's make sure modules are also built whenever CONFIG_TRIM_UNUSED_KSYMS is enabled and that the kernel binary is properly rebuilt accordingly. For my previously failing case, things behave again with this patch. Thanks much! Tested-by: Jarod Wilson -- Jarod Wilson ja...@redhat.com
Re: [PATCH v3 6/9] bus: fsl-mc: dpio: add QBMan portal APIs for DPAA2
On 12/02/2016 12:41 AM, Stuart Yoder wrote:
> From: Roy Pledge
>
> Add QBman APIs for frame queue and buffer pool operations.
>
> Signed-off-by: Roy Pledge
> Signed-off-by: Haiying Wang
> Signed-off-by: Stuart Yoder
> ---
>
> Notes:
> -v3
>-replace hardcoded dequeue token with a #define and check that
> token when checking for a new result (bug fix suggested by
> Ioana Radulescu)
> -v2
>-fix bug in buffer release command, by setting bpid field
>-handle error (NULL) return value from qbman_swp_mc_complete()
>-error message cleanup
>-fix bug in sending management commands where the verb was
> properly initialized
>
> drivers/bus/fsl-mc/dpio/Makefile |2 +-
> drivers/bus/fsl-mc/dpio/qbman-portal.c | 1028
>
> drivers/bus/fsl-mc/dpio/qbman-portal.h | 464 ++
> 3 files changed, 1493 insertions(+), 1 deletion(-)
> create mode 100644 drivers/bus/fsl-mc/dpio/qbman-portal.c
> create mode 100644 drivers/bus/fsl-mc/dpio/qbman-portal.h
>
> diff --git a/drivers/bus/fsl-mc/dpio/Makefile
> b/drivers/bus/fsl-mc/dpio/Makefile
> index 128befc..6588498 100644
> --- a/drivers/bus/fsl-mc/dpio/Makefile
> +++ b/drivers/bus/fsl-mc/dpio/Makefile
> @@ -6,4 +6,4 @@ subdir-ccflags-y := -Werror
>
> obj-$(CONFIG_FSL_MC_DPIO) += fsl-mc-dpio.o
>
> -fsl-mc-dpio-objs := dpio.o
> +fsl-mc-dpio-objs := dpio.o qbman-portal.o
> diff --git a/drivers/bus/fsl-mc/dpio/qbman-portal.c
> b/drivers/bus/fsl-mc/dpio/qbman-portal.c
> new file mode 100644
> index 000..bbc032c
> --- /dev/null
> +++ b/drivers/bus/fsl-mc/dpio/qbman-portal.c
> @@ -0,0 +1,1028 @@
> +/*
> + * Copyright (C) 2014 Freescale Semiconductor, Inc.
In previous patches the copyright years are 2014 - 2016. Maybe we should
do the same here too.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are
> met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in the
> + * documentation and/or other materials provided with the distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote products
> + * derived from this software without specific prior written
> permission.
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of the
> + * GNU General Public License ("GPL") as published by the Free Software
> + * Foundation, either version 2 of that License or (at your option) any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
> THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +#include
> +#include
> +#include
> +#include
> +
> +#include "qbman-portal.h"
> +
> +#define QMAN_REV_4000 0x0400
> +#define QMAN_REV_4100 0x0401
> +#define QMAN_REV_4101 0x04010001
> +
> +/* All QBMan command and result structures use this "valid bit" encoding */
> +#define QB_VALID_BIT ((u32)0x80)
> +
> +/* QBMan portal management command codes */
> +#define QBMAN_MC_ACQUIRE 0x30
> +#define QBMAN_WQCHAN_CONFIGURE 0x46
> +
> +/* CINH register offsets */
> +#define QBMAN_CINH_SWP_EQAR0x8c0
> +#define QBMAN_CINH_SWP_DQPI0xa00
> +#define QBMAN_CINH_SWP_DCAP0xac0
> +#define QBMAN_CINH_SWP_SDQCR 0xb00
> +#define QBMAN_CINH_SWP_RAR 0xcc0
> +#define QBMAN_CINH_SWP_ISR 0xe00
> +#define QBMAN_CINH_SWP_IER 0xe40
> +#define QBMAN_CINH_SWP_ISDR0xe80
> +#define QBMAN_CINH_SWP_IIR 0xec0
> +
> +/* CENA register offsets */
> +#define QBMAN_CENA_SWP_EQCR(n) (0x000 + ((u32)(n) << 6))
> +#define QBMAN_CENA_SWP_DQRR(n) (0x200 + ((u32)(n) << 6))
> +#define QBMAN_CENA_SWP_RCR(n) (0x400 + ((u32)(n) << 6))
> +#define QBMAN_CENA_SWP_CR 0x600
> +#define QBMAN_CENA_SWP_RR(vb) (0x700 + ((u32)(vb) >> 1))
> +#define QBMAN_CENA_SWP_VDQCR 0x780
> +
> +/* Reverse mapping of QBMAN_CENA_SWP_DQRR() */
> +#define QBMAN_IDX_FROM_DQRR(p) (((unsigned long)
[PATCH 1/2] devicetree: i2c-hid: Add regulator support
From: Caesar Wang
Document a "vdd-supply" and an initialization delay. Can be used for
powering on/off a HID.
Signed-off-by: Caesar Wang
Cc: Rob Herring
Cc: Jiri Kosina
Cc: linux-in...@vger.kernel.org
Signed-off-by: Brian Norris
---
v2:
* add compatible property for wacom, per Rob's request
* name the regulator property specifically (VDD)
v3:
* remove wacom property, per Benjamin's request
* add delay property
v4: no change
---
Documentation/devicetree/bindings/input/hid-over-i2c.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
index 488edcb264c4..1ea290167652 100644
--- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
+++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
@@ -17,6 +17,11 @@ Required properties:
- interrupt-parent: the phandle for the interrupt controller
- interrupts: interrupt line
+Optional properties:
+- vdd-supply: phandle of the regulator that provides the supply voltage.
+- init-delay-ms: time required by the device after power-on before it is ready
+ for communication.
+
Example:
i2c-hid-dev@2c {
--
2.8.0.rc3.226.g39d4020
Re: [PATCH] Input: elantech - Add a special mode for a specific FW The touchapd which sample ver is 0x74 and hw_version is 0x03 have a fw bug which will cause crush sometimes, I add some work-around f
Hi,
Thank you for the patch, see below my feedback on your patch.
Can you provide the contents of fw_verison, capabilities and samples ?
It this fw bug present on multiple laptops ?
On Fri, Dec 02, 2016 at 01:59:17PM +0800, KT Liao wrote:
> Date: Fri, 2 Dec 2016 13:59:17 +0800
> From: KT Liao
> To: linux-kernel@vger.kernel.org, linux-in...@vger.kernel.org,
> dmitry.torok...@gmail.com
> Cc: phoe...@emc.com.tw, kt.l...@emc.com.tw
> Subject: [PATCH] Input: elantech - Add a special mode for a specific FW The
> touchapd which sample ver is 0x74 and hw_version is 0x03 have a fw bug
> which will cause crush sometimes, I add some work-around for it and our
> customer ask us to upstream the patch Signed-off-by: KT Liao
>
It seems that the newlines got lost when you used git-send-email. The
subject should be a oneliner, the remaining part should go to the mail body.
> X-Mailer: git-send-email 2.7.4
> X-Mailing-List: linux-in...@vger.kernel.org
>
> ---
> drivers/input/mouse/elantech.c | 152
> +++--
> 1 file changed, 131 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index db7d1d6..acfe7f2 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -539,6 +539,30 @@ static void elantech_report_absolute_v3(struct psmouse
> *psmouse,
> input_sync(dev);
> }
>
> +static psmouse_ret_t elantech_report_relative_v3(struct psmouse *psmouse)
> +{
> + struct input_dev *dev = psmouse->dev;
> + unsigned char *packet = psmouse->packet;
> + int rel_x = 0, rel_y = 0;
> +
> + if (psmouse->pktcnt < psmouse->pktsize)
> + return PSMOUSE_GOOD_DATA;
This is a duplicate of elantech_process_byte and you skipped the
elantech_packet_dump feature of elantech_process_byte. I think it would be
better to let elantech_process_byte call this elantech_report_relative_v3
just like all the other reportings.
Is it required to also disable the elantech_packet_check_v3 ?
Can you document the typical packet format for
elantech_report_relative_v3 ? Something similar to elantech_report_trackpoint ?
> +
> + input_report_rel(dev, REL_WHEEL, -(signed char)packet[3]);
> +
> + rel_x = (int) packet[1] - (int) ((packet[0] << 4) & 0x100);
> + rel_y = (int) ((packet[0] << 3) & 0x100) - (int) packet[2];
> +
> + input_report_key(dev, BTN_LEFT,packet[0] & 1);
> + input_report_key(dev, BTN_RIGHT, (packet[0] >> 1) & 1);
> + input_report_rel(dev, REL_X, rel_x);
> + input_report_rel(dev, REL_Y, rel_y);
> +
> + input_sync(dev);
> +
> + return PSMOUSE_FULL_PACKET;
> +}
> +
> static void elantech_input_sync_v4(struct psmouse *psmouse)
> {
> struct input_dev *dev = psmouse->dev;
> @@ -696,14 +720,14 @@ static int elantech_packet_check_v1(struct psmouse
> *psmouse)
>
> static int elantech_debounce_check_v2(struct psmouse *psmouse)
> {
> -/*
> - * When we encounter packet that matches this exactly, it means the
> - * hardware is in debounce status. Just ignore the whole packet.
> - */
> -const u8 debounce_packet[] = { 0x84, 0xff, 0xff, 0x02, 0xff, 0xff };
> -unsigned char *packet = psmouse->packet;
> -
> -return !memcmp(packet, debounce_packet, sizeof(debounce_packet));
> + /*
> + * When we encounter packet that matches this exactly, it means the
> + * hardware is in debounce status. Just ignore the whole packet.
> + */
> + const u8 debounce_packet[] = { 0x84, 0xff, 0xff, 0x02, 0xff, 0xff };
> + unsigned char *packet = psmouse->packet;
> +
> + return !memcmp(packet, debounce_packet, sizeof(debounce_packet));
> }
Confirmed, the lines of elantech_debounce_check_v2 do not start with tab
but spaces, but preferably this will be part of a separate commit.
>
> static int elantech_packet_check_v2(struct psmouse *psmouse)
> @@ -995,6 +1019,29 @@ static int elantech_set_absolute_mode(struct psmouse
> *psmouse)
> return rc;
> }
>
> +/* it's the work around mode for some touchpad which has FW bug, but dont'
> support IAP funciton */
This line is too long, split it across multiple lines.
> +static int elantech_set_special_mode(struct psmouse *psmouse)
> +{
> + unsigned char param[3];
> + int rc = 0;
Knowing Dmitry, he would prefer to have error as name instead of rc.
> +
> + param[0] = 0xc8;
> + param[1] = 0x64;
> + param[2] = 0x50;
> +
> + if (elantech_ps2_command(psmouse, ¶m[0], PSMOUSE_CMD_SETRATE) ||
> +elantech_ps2_command(psmouse, ¶m[1], PSMOUSE_CMD_SETRATE) ||
> +elantech_ps2_command(psmouse, ¶m[2], PSMOUSE_CMD_SETRATE) ||
> +elantech_ps2_command(psmouse, param, PSMOUSE_CMD_GETID)) {
> + rc = -1;
> + }
Hm, these do look very similar to intellimouse_detect. Is that a coincidence ?
> +
> + psmouse->set_rate(psmouse, 0x64);
> + psmouse->set_resolution(p
[PATCH 2/2] HID: i2c-hid: support regulator power on/off
On some boards, we need to enable a regulator before using the HID, and
it's also nice to save power in suspend by disabling it. Support an
optional "vdd-supply" and a companion initialization delay.
Signed-off-by: Brian Norris
Signed-off-by: Caesar Wang
Cc: Jiri Kosina
Cc: linux-in...@vger.kernel.org
---
v2:
* support compatible property for wacom, with specific "vdd-supply"
* name
* support the 100ms delay needed for this digitizer
* target regulator support only at specific device
v3:
* drop Wacom specifics and allow this to be used generically
* add "init-delay-ms" property support
v4:
* use devm_regulator_get() (with a 'dummy' regulator for most cases)
instead of _optional() version, to make code less conditional (Dmitry)
* fix but where 'init_delay_ms' wasn't getting assigned properly
* disable regulator in probe() failure path
---
drivers/hid/i2c-hid/i2c-hid.c | 44 +--
include/linux/i2c/i2c-hid.h | 6 ++
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index b3ec4f2de875..5c6e037613d7 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
@@ -937,6 +938,10 @@ static int i2c_hid_of_probe(struct i2c_client *client,
}
pdata->hid_descriptor_address = val;
+ ret = of_property_read_u32(dev->of_node, "init-delay-ms", &val);
+ if (!ret)
+ pdata->init_delay_ms = val;
+
return 0;
}
@@ -983,6 +988,15 @@ static int i2c_hid_probe(struct i2c_client *client,
ihid->pdata = *platform_data;
}
+ ihid->pdata.supply = devm_regulator_get(&client->dev, "vdd");
+ if (IS_ERR(ihid->pdata.supply)) {
+ ret = PTR_ERR(ihid->pdata.supply);
+ if (ret != -EPROBE_DEFER)
+ dev_err(&client->dev, "Failed to get regulator: %d\n",
+ ret);
+ return ret;
+ }
+
if (client->irq > 0) {
ihid->irq = client->irq;
} else if (ACPI_COMPANION(&client->dev)) {
@@ -1000,6 +1014,15 @@ static int i2c_hid_probe(struct i2c_client *client,
}
}
+ ret = regulator_enable(ihid->pdata.supply);
+ if (ret < 0) {
+ dev_err(&client->dev, "Failed to enable regulator: %d\n",
+ ret);
+ goto err;
+ }
+ if (ihid->pdata.init_delay_ms)
+ msleep(ihid->pdata.init_delay_ms);
+
i2c_set_clientdata(client, ihid);
ihid->client = client;
@@ -1015,7 +1038,7 @@ static int i2c_hid_probe(struct i2c_client *client,
* real computation later. */
ret = i2c_hid_alloc_buffers(ihid, HID_MIN_BUFFER_SIZE);
if (ret < 0)
- goto err;
+ goto err_regulator;
pm_runtime_get_noresume(&client->dev);
pm_runtime_set_active(&client->dev);
@@ -1070,6 +1093,9 @@ static int i2c_hid_probe(struct i2c_client *client,
pm_runtime_put_noidle(&client->dev);
pm_runtime_disable(&client->dev);
+err_regulator:
+ regulator_disable(ihid->pdata.supply);
+
err:
if (ihid->desc)
gpiod_put(ihid->desc);
@@ -1100,6 +1126,8 @@ static int i2c_hid_remove(struct i2c_client *client)
if (ihid->desc)
gpiod_put(ihid->desc);
+ regulator_disable(ihid->pdata.supply);
+
kfree(ihid);
acpi_dev_remove_driver_gpios(ACPI_COMPANION(&client->dev));
@@ -1152,6 +1180,11 @@ static int i2c_hid_suspend(struct device *dev)
else
hid_warn(hid, "Failed to enable irq wake: %d\n",
wake_status);
+ } else {
+ ret = regulator_disable(ihid->pdata.supply);
+ if (ret < 0)
+ hid_warn(hid, "Failed to disable supply: %d\n",
+ret);
}
return 0;
@@ -1165,7 +1198,14 @@ static int i2c_hid_resume(struct device *dev)
struct hid_device *hid = ihid->hid;
int wake_status;
- if (device_may_wakeup(&client->dev) && ihid->irq_wake_enabled) {
+ if (!device_may_wakeup(&client->dev)) {
+ ret = regulator_enable(ihid->pdata.supply);
+ if (ret < 0)
+ hid_warn(hid, "Failed to enable supply: %d\n",
+ret);
+ if (ihid->pdata.init_delay_ms)
+ msleep(ihid->pdata.init_delay_ms);
+ } else if (ihid->irq_wake_enabled) {
wake_status = disable_irq_wake(ihid->irq);
if (!wake_status)
ihid->irq_wake_enabled = false;
diff --git a/include/linux/i2c/i2c-hid.h b/include/linux/i2c/i2c-hid.h
index 7aa901d92058..97688cde4a91 100644
--- a/include/linux/i2c/i2c-hid.h
+++
