[PATCH v4] i2c: hibvt: add Hisilicon BVT I2C controller driver
add Hisilicon BVT I2C controller driver support.
Signed-off-by: Pan Wen
---
change log
v4:
Modify the default frequency to 100KHz.
v3:
Add a SoC specific compatible string.
v2:
1)Fixed a compile error.
2)Dropped the clock-names property.
.../devicetree/bindings/i2c/i2c-hibvt.txt | 24 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-hibvt.c | 737 +
4 files changed, 772 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-hibvt.txt
create mode 100644 drivers/i2c/busses/i2c-hibvt.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-hibvt.txt
b/Documentation/devicetree/bindings/i2c/i2c-hibvt.txt
new file mode 100644
index 000..db3d2e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-hibvt.txt
@@ -0,0 +1,24 @@
+Hisilicon BVT I2C master controller
+
+Required properties:
+- compatible: should be "hisilicon,hibvt-i2c" and one of the following:
+ "hisilicon,hi3516cv300-i2c"
+- reg: physical base address of the controller and length of memory mapped.
+ region.
+- interrupts: interrupt number to the cpu.
+- clocks: phandles to input clocks.
+
+Optional properties:
+- clock-frequency: Desired I2C bus frequency in Hz, otherwise defaults to
10.
+
+Other properties:
+see Documentation/devicetree/bindings/i2c/i2c.txt.
+
+Examples:
+i2c_bus0: i2c@1211 {
+ compatible = "hisilicon,hi3516cv300-i2c", "hisilicon,hibvt-i2c";
+ reg = <0x1211 0x100>;
+ interrupts = <20>;
+ clocks = <&crg_ctrl HI3516CV300_APB_CLK>;
+ clock-frequency = <10>;
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 5c3993b..fc1b679 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -555,6 +555,16 @@ config I2C_GPIO
This is a very simple bitbanging I2C driver utilizing the
arch-neutral GPIO API to control the SCL and SDA lines.
+config I2C_HIBVT
+ tristate "Hisilicon BVT I2C Controller"
+ depends on ARCH_HISI
+ help
+ Say Y here to include support for Hisilicon BVT I2C controller in the
+ Hisilicon BVT SoCs.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-hibvt.
+
config I2C_HIGHLANDER
tristate "Highlander FPGA SMBus interface"
depends on SH_HIGHLANDER
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 37f2819..42ef2e0 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_I2C_EG20T) += i2c-eg20t.o
obj-$(CONFIG_I2C_EMEV2)+= i2c-emev2.o
obj-$(CONFIG_I2C_EXYNOS5) += i2c-exynos5.o
obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
+obj-$(CONFIG_I2C_HIBVT)+= i2c-hibvt.o
obj-$(CONFIG_I2C_HIGHLANDER) += i2c-highlander.o
obj-$(CONFIG_I2C_HIX5HD2) += i2c-hix5hd2.o
obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o
diff --git a/drivers/i2c/busses/i2c-hibvt.c b/drivers/i2c/busses/i2c-hibvt.c
new file mode 100644
index 000..e8af63e
--- /dev/null
+++ b/drivers/i2c/busses/i2c-hibvt.c
@@ -0,0 +1,737 @@
+/*
+ * Hisilicon BVT I2C Controller Driver
+ *
+ * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
+ *
+ * Authors: wen...@hisilicon.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
Re: [PATCH V2 2/2] fs/super.c: don't fool lockdep in freeze_super() and thaw_super() paths
On Mon 26-09-16 18:55:25, Oleg Nesterov wrote:
> On 09/26, Jan Kara wrote:
> >
> > On Mon 26-09-16 18:08:06, Oleg Nesterov wrote:
> > > +/*
> > > + * Tell lockdep we are holding these locks before we call
> > > ->unfreeze_fs(sb).
> > > + */
> > > +static void sb_freeze_acquire(struct super_block *sb)
> >
> > Can we call this lockdep_sb_freeze_acquire() or something like that so that
> > it is clear this is only about lockdep annotations? Similarly with
> > sb_freeze_unlock()...
>
> OK, thanks, done. See V2 below.
>
> > and I hope you really tested
> > there are no more lockdep false positives ;).
>
> Heh ;) if only I knew how to test this... I ran the following script
> under qemu
>
> mkfs.xfs -f /dev/vda
> mkfs.xfs -f /dev/vdb
>
> mkdir -p TEST SCRATCH
>
> TEST_DEV=/dev/vda TEST_DIR=TEST SCRATCH_DEV=/dev/vdb
> SCRATCH_MNT=SCRATCH \
> ./check `grep -il freeze tests/*/???`
You can run either:
./check -g freeze
to check just the freezing tests or
./check
to run all sensible tests which is what I'd do (but it will take couple of
hours to pass). If that passes, chances are good there are no easy false
positives.
> And yes, I'm afraid this change can uncover some false positives later.
> But at the same time potentially it can find the real problems.
Well, sure it's not an end of world if there is some false positive - we
can just revert the change - but lockdep false positives are always
annoying because they take time to analyze and until they are fixed, you
are unable to see other probles found by lockdep...
> It would be nice to remove another hack in __sb_start_write under
> ifdef(CONFIG_LOCKDEP), but iirc XFS actually takes the same rw_sem twice
> for reading, so we can't do this.
Yes, and I don't really consider this a hack. Filesystem freezing was never
meant to have all the properties of classical rwsems in kernel - I just
happened to notice that the semantics is close to rwsems and so decided to
model it as such in lockdep to get some lockdep verification for it. In
particular "read lock recursion" has always been OK with freeze protection
by design and I don't see strong motivation for changing that.
> ---
> From 70e774533ab6319f9b90a490b036150ad9604af7 Mon Sep 17 00:00:00 2001
> From: Oleg Nesterov
> Date: Mon, 26 Sep 2016 17:23:24 +0200
> Subject: [PATCH V2 2/2] fs/super.c: don't fool lockdep in freeze_super() and
> thaw_super() paths
>
> sb_wait_write()->percpu_rwsem_release() fools lockdep to avoid the
> false-positives. Now that xfs was fixed by Dave's commit dbad7c993053
> ("xfs: stop holding ILOCK over filldir callbacks") we can remove it and
> change freeze_super() and thaw_super() to run with s_writers.rw_sem locks
> held; we add two trivial helpers for that, lockdep_sb_freeze_release()
> and lockdep_sb_freeze_acquire().
>
> xfstests-dev/check `grep -il freeze tests/*/???` does not trigger any
> warning from lockdep.
>
> Signed-off-by: Oleg Nesterov
Thanks. The patch looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/super.c | 37 +
> 1 file changed, 25 insertions(+), 12 deletions(-)
>
> diff --git a/fs/super.c b/fs/super.c
> index 2549896c..0447afe 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -1214,25 +1214,34 @@ EXPORT_SYMBOL(__sb_start_write);
> static void sb_wait_write(struct super_block *sb, int level)
> {
> percpu_down_write(sb->s_writers.rw_sem + level-1);
> - /*
> - * We are going to return to userspace and forget about this lock, the
> - * ownership goes to the caller of thaw_super() which does unlock.
> - *
> - * FIXME: we should do this before return from freeze_super() after we
> - * called sync_filesystem(sb) and s_op->freeze_fs(sb), and thaw_super()
> - * should re-acquire these locks before s_op->unfreeze_fs(sb). However
> - * this leads to lockdep false-positives, so currently we do the early
> - * release right after acquire.
> - */
> - percpu_rwsem_release(sb->s_writers.rw_sem + level-1, 0, _THIS_IP_);
> }
>
> -static void sb_freeze_unlock(struct super_block *sb)
> +/*
> + * We are going to return to userspace and forget about these locks, the
> + * ownership goes to the caller of thaw_super() which does unlock().
> + */
> +static void lockdep_sb_freeze_release(struct super_block *sb)
> +{
> + int level;
> +
> + for (level = SB_FREEZE_LEVELS - 1; level >= 0; level--)
> + percpu_rwsem_release(sb->s_writers.rw_sem + level, 0,
> _THIS_IP_);
> +}
> +
> +/*
> + * Tell lockdep we are holding these locks before we call ->unfreeze_fs(sb).
> + */
> +static void lockdep_sb_freeze_acquire(struct super_block *sb)
> {
> int level;
>
> for (level = 0; level < SB_FREEZE_LEVELS; ++level)
> percpu_rwsem_acquire(s
Re: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready
Hello Stefan, On Mon, Sep 26, 2016 at 05:18:58PM -0700, Stefan Agner wrote: > Some SoC might load the GPIO driver after the I2C driver and > using the I2C bus recovery mechanism via GPIOs. In this case > it is crucial to defer probing if the GPIO request functions > do so, otherwise the I2C driver gets loaded without recovery > mechanisms enabled. > > Signed-off-by: Stefan Agner Acked-by: Uwe Kleine-König Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
linux-next: Tree for Sep 27
Hi all, Changes since 20160923: New tree: vfs-jk The vfs-jk tree gained a conflict against the fuse tree. The rdma tree gained a build failure so I used the version from next-20160923. The drm-exynos tree gained a conflict against the drm tree. The kvm-arm tree lost its build failure but gained a conflict against the tip tree. The percpu tree gained a conflict against the asm-generic tree. The gpio tree gained conflicts against the arm-soc and i2c trees. The akpm-current tree gained a conflict against the arm64 tree. Non-merge commits (relative to Linus' tree): 12416 9245 files changed, 514935 insertions(+), 255035 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 243 trees (counting Linus' and 34 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (08895a8b6b06 Linux 4.8-rc8) Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when not configured) Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4) Merging arm-current/fixes (1a57c286d8ce ARM: pxa/lubbock: add pcmcia clock) Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs for v4.7-rc2) Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init()) Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks for SR-IOV and window alignment) Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support is disabled) Merging net/master (2cf750704bb6 ipmr, ip6mr: fix scheduling while atomic and a deadlock with ipmr_get_route) Merging ipsec/master (b1f2beb87bb0 Merge tag 'media/v4.8-7' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media) Merging netfilter/master (440f895aa97f drivers: net: phy: xgene: Fix 'remove' function) Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes') Merging wireless-drivers/master (db64c5fa590b Merge tag 'iwlwifi-for-kalle-2016-09-15' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (7ac327318e09 Merge tag 'mac80211-for-davem-2016-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging sound-current/for-linus (392c9da24a99 ALSA: hda - Adding one more ALC255 pin definition for headset problem) Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device removal) Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5) Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5) Merging usb.current/usb-linus (3be7988674ab Linux 4.8-rc7) Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix endpoint name) Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add support for another Infineon flashloader) Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phase) Merging staging.current/staging-linus (9395452b4aab Linux 4.8-rc6) Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5) Merging input-current/for-linus (4af2ff91ec3f Input: silead_gsl1680 - use "silead/" prefix for firmware loading) Merging crypto-current/master (0cf43f509f72 crypto: rsa-pkcs1pad - Handle leading zero for decryption) Merging ide/master (79
Re: Kernel Oops on 4.8.0-rc8 while running trinity tests
The kernel oops is still reproducible on 4.8.0-rc8 on PowerPC bare metal While running trinity system call fuzzer, I see these kernel oops messages: Unable to handle kernel paging request for data at address 0xe45f7702 Faulting instruction address: 0xc0055380 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=32 NUMA PowerNV Modules linked in: torture leds_powernv led_class powernv_op_panel powernv_rng rng_core autofs4 [last unloaded: rcutorture] CPU: 28 PID: 19687 Comm: trinity-main Not tainted 4.8.0-rc8-autotest #1 task: c007dc61c600 task.stack: c007ddb2 NIP: c0055380 LR: c0234968 CTR: REGS: c007ddb23640 TRAP: 0300 Not tainted (4.8.0-rc8-autotest) MSR: 90009033 CR: 24002442 XER: CFAR: c00087d0 DAR: e45f7702 DSISR: 4000 SOFTE: 1 GPR00: 0007 c007ddb238c0 c0f7c100 c000 GPR04: 0009 GPR08: e45f7702 007f 0015 GPR12: c000 1000 GPR16: 0001 c2e02798 10034120 GPR20: 10034108 c007ddf842e0 c0ff0df8 GPR24: c1fff7ff c007ddb23a60 0100 GPR28: 0100 c2e02400 c2e02464 NIP [c0055380] __find_linux_pte_or_hugepte+0x1c0/0x330 LR [c0234968] __unmap_hugepage_range+0x178/0x670 Call Trace: [c007ddb23980] [c0234e80] __unmap_hugepage_range_final+0x20/0x50 [c007ddb239b0] [c020a52c] unmap_single_vma+0xcc/0x120 [c007ddb239f0] [c020a984] unmap_vmas+0x84/0x120 [c007ddb23a40] [c0212c00] unmap_region+0xd0/0x1a0 [c007ddb23b30] [c0214e8c] do_munmap+0x2dc/0x4a0 [c007ddb23ba0] [c0216800] mmap_region+0x1c0/0x6e0 [c007ddb23c90] [c02170fc] do_mmap+0x3dc/0x4c0 [c007ddb23d20] [c01f1034] vm_mmap_pgoff+0xc4/0x100 [c007ddb23d90] [c02144d0] SyS_mmap_pgoff+0x100/0x2a0 [c007ddb23e10] [c0012424] sys_mmap+0x44/0x70 [c007ddb23e30] [c00095e0] system_call+0x38/0x108 Instruction dump: 7d290030 79081764 3929 3860 7d2a07b4 7c895c36 7d494838 78630044 7908f5e6 79291f24 7d081b78 796b0020 <7d49402a> 7c694214 2eaa f941ffd0 ---[ end trace f4f25c6801290199 ]--- On Friday 26 August 2016 12:02 PM, Abdul Haleem wrote: Hi, Trinity tests failed on mainline4.8.0-rc3with the following error message: Machine Type : PowerPC Bare Metal & also reproducible on PowerVM LPAR config : attached 06:05:25 20:36:07 INFO | Test: running trinity tests 06:05:25 20:36:07 INFO | trinity 06:05:25 20:36:07 INFO | STARTtrinity trinity timestamp=1471912567localtime=Aug 22 20:36:07 06:06:19 Unable to handle kernel paging request for data at address 0xe475e1dc0700 06:06:19 Faulting instruction address: 0xc00553a0 06:06:19 Oops: Kernel access of bad area, sig: 11 [#1] 06:06:19 SMP NR_CPUS=32 NUMA PowerNV 06:06:19 Modules linked in: torture iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc iptable_filter ip_tables x_tables binfmt_misc kvm_hv kvm leds_powernv led_class powernv_op_panel powernv_rng rng_core autofs4 btrfs xor raid6_pq [last unloaded: rcutorture] 06:06:19 CPU: 24 PID: 16309 Comm: trinity-main Not tainted 4.8.0-rc3-autotest #1 06:06:19 task: c007de33 task.stack: c007d85dc000 06:06:19 NIP: c00553a0 LR: c02345a8 CTR: 06:06:19 REGS: c007d85df640 TRAP: 0300 Not tainted (4.8.0-rc3-autotest) 06:06:19 MSR: 90009033 CR: 24002452 XER: 06:06:19 CFAR: c00087d0 DAR: e475e1dc0700 DSISR: 4000 SOFTE: 1 06:06:19 GPR00: 0007 c007d85df8c0 c0f7ad00 c000 06:06:19 GPR04: 0009 0700 06:06:19 GPR08: e475e1dc0700 007f 0015 06:06:19 GPR12: cfffe000 1000 06:06:19 GPR16: 0001 c007ddfa6798 100341e0 06:06:19 GPR20: 100341c8 c007dc336508 c0ff0df8 06:06:19 GPR24: c1fff7ff c007d85dfa60 0100 06:06:19 GPR28: 0100 c007ddfa6400 c007ddfa6464 0007 06:06:19 NIP [c00553a0] __find_linux_pte_or_hugepte+0x1c0/0x330 06:06:19 LR [c02345a8] __unmap_hugepage_range+0x178/0x670 06:06:19 Call Trace: 06:06:19 [c007d85df980] [c0234ac0] __unmap_hugepage_range_final+0x20/0x50 06:06:19 [c007d85df9b0] [c020a16c] unmap_single_vma+0xcc/
Re: [PATCH] arm64, numa: Add cpu_to_node() implementation.
On 09/20/2016 09:21 PM, Robert Richter wrote: On 20.09.16 19:32:34, Hanjun Guo wrote: On 09/20/2016 06:43 PM, Robert Richter wrote: Unfortunately either your nor my code does fix the BUG_ON() I see with the numa kernel: kernel BUG at mm/page_alloc.c:1848! See below for the core dump. It looks like this happens due to moving a mem block where first and last page are mapped to different numa nodes, thus, triggering the BUG_ON(). Didn't triggered it on our NUMA hardware, could you provide your config then we can have a try? Config attached. Other configs with an initrd fail too. hmm, we can't reproduce it on our hardware, do we need to run some specific stress test on it? Thanks Hanjun
Re: [PATCH] kcov: properly check if we are in an interrupt
On Tue, Sep 27, 2016 at 1:32 AM, Andrew Morton
wrote:
> On Fri, 23 Sep 2016 16:51:13 +0200 Andrey Konovalov
> wrote:
>
>> in_interrupt() returns a nonzero value when we are either in an
>> interrupt or have bh disabled via local_bh_disable(). Since we are
>> interested in only ignoring coverage from actual interrupts, do a
>> proper check of whether we are really in an interrupt.
>>
>> Signed-off-by: Andrey Konovalov
>> ---
>> It would look totally better to reuse in_irq(), in_serving_softirq() and
>> in_nmi() instead of checking flags manually, but that leads to slower
>> generated code (three separate tests for each of the flags). Would it be
>> better to add another macro to preempt.h that would check if we're actually
>> in interrupt and use it?
>
> Yes please. Is there anywhere else where such a macro can be used?
I suspect there is a bunch of places that use in_interrupt(), but mean
the same as KCOV wants -- am I in interrupt? and not am I in interrupt
context or in normal task context but inside local_bh_disable(). For
example, why does fput handles closure asynchronously if the task
called local_bh_disable?
264 void fput(struct file *file)
265 {
266 if (atomic_long_dec_and_test(&file->f_count)) {
267 struct task_struct *task = current;
268
269 if (likely(!in_interrupt() && !(task->flags &
PF_KTHREAD))) {
270 init_task_work(&file->f_u.fu_rcuhead, fput);
271 if (!task_work_add(task,
&file->f_u.fu_rcuhead, true))
272 return;
273 /*
274 * After this task has run exit_task_work(),
275 * task_work_add() will fail. Fall
through to delayed
276 * fput to avoid leaking *file.
277 */
278 }
279
280 if (llist_add(&file->f_u.fu_llist, &delayed_fput_list))
281 schedule_delayed_work(&delayed_fput_work, 1);
282 }
283 }
>> --- a/kernel/kcov.c
>> +++ b/kernel/kcov.c
>> @@ -54,7 +54,8 @@ void notrace __sanitizer_cov_trace_pc(void)
>>* We are interested in code coverage as a function of a syscall
>> inputs,
>>* so we ignore code executed in interrupts.
>>*/
>> - if (!t || in_interrupt())
>> + if (!t || (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_OFFSET
>> + | NMI_MASK)))
>
> Or include a prominent and very apologetic comment here explaining why
> it is open-coded. But I do agree that not open-coding it is better.
[PATCH] staging: ks7010: Use __packed over __attribute__((packed))
This replaces uses of __attribute__((packed)) with __packed, which is
recommended to be used over the direct __attribute__. This patch then
includes as necessary to use __packed.
Signed-off-by: Matthew Kilgore
---
drivers/staging/ks7010/eap_packet.h | 10 ++--
drivers/staging/ks7010/ks_hostif.h | 99 +++--
drivers/staging/ks7010/ks_wlan.h| 4 +-
3 files changed, 59 insertions(+), 54 deletions(-)
diff --git a/drivers/staging/ks7010/eap_packet.h
b/drivers/staging/ks7010/eap_packet.h
index 16a392a..373c0fe 100644
--- a/drivers/staging/ks7010/eap_packet.h
+++ b/drivers/staging/ks7010/eap_packet.h
@@ -1,6 +1,8 @@
#ifndef EAP_PACKET_H
#define EAP_PACKET_H
+#include
+
#define WBIT(n) (1 << (n))
#ifndef ETH_ALEN
@@ -19,14 +21,14 @@ struct ether_hdr {
#define ETHER_PROTOCOL_TYPE_IP 0x0800
#define ETHER_PROTOCOL_TYPE_ARP 0x0806
/* followed by length octets of data */
-} __attribute__ ((packed));
+} __packed;
struct ieee802_1x_hdr {
unsigned char version;
unsigned char type;
unsigned short length;
/* followed by length octets of data */
-} __attribute__ ((packed));
+} __packed;
#define EAPOL_VERSION 2
@@ -69,7 +71,7 @@ struct ieee802_1x_eapol_key {
* represents the number of least significant octets from
* MS-MPPE-Send-Key attribute to be used as the keying material;
* RC4 key used in encryption = Key-IV + MS-MPPE-Recv-Key */
-} __attribute__ ((packed));
+} __packed;
#define WPA_NONCE_LEN 32
#define WPA_REPLAY_COUNTER_LEN 8
@@ -86,7 +88,7 @@ struct wpa_eapol_key {
unsigned char key_mic[16];
unsigned short key_data_length;
/* followed by key_data_length bytes of key_data */
-} __attribute__ ((packed));
+} __packed;
#define WPA_KEY_INFO_TYPE_MASK (WBIT(0) | WBIT(1) | WBIT(2))
#define WPA_KEY_INFO_TYPE_HMAC_MD5_RC4 WBIT(0)
diff --git a/drivers/staging/ks7010/ks_hostif.h
b/drivers/staging/ks7010/ks_hostif.h
index dc806b5b..f35c0c51 100644
--- a/drivers/staging/ks7010/ks_hostif.h
+++ b/drivers/staging/ks7010/ks_hostif.h
@@ -11,6 +11,9 @@
#ifndef _KS_HOSTIF_H_
#define _KS_HOSTIF_H_
+
+#include
+
/*
* HOST-MAC I/F events
*/
@@ -61,7 +64,7 @@
struct hostif_hdr {
uint16_t size;
uint16_t event;
-} __attribute__ ((packed));
+} __packed;
struct hostif_data_request_t {
struct hostif_hdr header;
@@ -70,7 +73,7 @@ struct hostif_data_request_t {
#define TYPE_AUTH 0x0001
uint16_t reserved;
uint8_t data[0];
-} __attribute__ ((packed));
+} __packed;
struct hostif_data_indication_t {
struct hostif_hdr header;
@@ -81,14 +84,14 @@ struct hostif_data_indication_t {
#define TYPE_GMK2 0x0003
uint16_t reserved;
uint8_t data[0];
-} __attribute__ ((packed));
+} __packed;
#define CHANNEL_LIST_MAX_SIZE 14
struct channel_list_t {
uint8_t size;
uint8_t body[CHANNEL_LIST_MAX_SIZE];
uint8_t pad;
-} __attribute__ ((packed));
+} __packed;
/* MIB Attribute */
#define DOT11_MAC_ADDRESS 0x21010100/* MAC Address (R) */
@@ -141,7 +144,7 @@ struct channel_list_t {
struct hostif_mib_get_request_t {
struct hostif_hdr header;
uint32_t mib_attribute;
-} __attribute__ ((packed));
+} __packed;
struct hostif_mib_value_t {
uint16_t size;
@@ -152,7 +155,7 @@ struct hostif_mib_value_t {
#define MIB_VALUE_TYPE_COUNT32 3
#define MIB_VALUE_TYPE_OSTRING 4
uint8_t body[0];
-} __attribute__ ((packed));
+} __packed;
struct hostif_mib_get_confirm_t {
struct hostif_hdr header;
@@ -163,19 +166,19 @@ struct hostif_mib_get_confirm_t {
#define MIB_WRITE_ONLY 3
uint32_t mib_attribute;
struct hostif_mib_value_t mib_value;
-} __attribute__ ((packed));
+} __packed;
struct hostif_mib_set_request_t {
struct hostif_hdr header;
uint32_t mib_attribute;
struct hostif_mib_value_t mib_value;
-} __attribute__ ((packed));
+} __packed;
struct hostif_mib_set_confirm_t {
struct hostif_hdr header;
uint32_t mib_status;
uint32_t mib_attribute;
-} __attribute__ ((packed));
+} __packed;
struct hostif_power_mngmt_request_t {
struct hostif_hdr header;
@@ -188,7 +191,7 @@ struct hostif_power_mngmt_request_t {
uint32_t receiveDTIMs;
#define DTIM_FALSE 0
#define DTIM_TRUE 1
-} __attribute__ ((packed));
+} __packed;
/* power management mode */
enum {
@@ -206,7 +209,7 @@ enum {
struct hostif_power_mngmt_confirm_t {
struct hostif_hdr header;
uint16_t result_code;
-} __attribute__ ((packed));
+} __packed;
struct hostif_start_request_t {
struct hostif_hdr header;
@@ -215,64 +218,64 @@ struct hostif_start_request_t {
#define MODE_INFRASTRUCTURE 1
#define MODE_AP 2 /* not used */
#define MODE_ADHOC 3
-} __attribute__ ((packed));
+} __packed;
struct hostif_start_confirm_t {
struct hostif_hdr header;
uint16_t result_code;
-} __attribute__ ((packed));
+} __
Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()
On 09/22/2016 07:15 AM, David Rientjes wrote: > On Thu, 22 Sep 2016, zijun_hu wrote: > >>> We don't support inserting when va->va_start == tmp_va->va_end, plain and >>> simple. There's no reason to do so. NACK to the patch. >>> >> i am sorry i disagree with you because >> 1) in almost all context of vmalloc, original logic treat the special case >> as normal >>for example, __find_vmap_area() or alloc_vmap_area() > > The ranges are [start, end) like everywhere else. __find_vmap_area() is > implemented as such for the passed address. The address is aligned in > alloc_vmap_area(), there's no surprise here. The logic is correct in > __insert_vmap_area(). > i am sorry to disagree with you i will resend this patch with more detailed illustration
linux-next: manual merge of the akpm-current tree with the arm64 tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/arm/Kconfig
between commit:
1d8f51d41fc7 ("arm/arm64: arch_timer: Use archdata to indicate vdso
suitability")
from the arm64 tree and commit:
7b4d24d8c01d ("atomic64: no need for
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/Kconfig
index 125657b602a4,2a50957c7bfb..
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -1,8 -1,6 +1,7 @@@
config ARM
bool
default y
+ select ARCH_CLOCKSOURCE_DATA
- select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
Re: [PATCH] extcon: usb-gpio: Add VBUS detection support
On Tue, Sep 20, 2016 at 05:53:55PM +0300, Roger Quadros wrote:
> Driver can now work with both ID and VBUS pins or either one of
> them.
>
> There can be the following 3 cases
>
> 1) Both ID and VBUS GPIOs are available:
>
> ID = LOW -> USB_HOST active, USB inactive
> ID = HIGH -> USB_HOST inactive, USB state is same as VBUS.
>
> 2) Only ID GPIO is available:
>
> ID = LOW -> USB_HOST active, USB inactive
> ID = HIGH -> USB_HOST inactive, USB active
>
> 3) Only VBUS GPIO is available:
>
> VBUS = LOW -> USB_HOST inactive, USB inactive
> VBUS = HIGH -> USB_HOST inactive, USB active
>
> Signed-off-by: Roger Quadros
> ---
> .../devicetree/bindings/extcon/extcon-usb-gpio.txt | 3 +
> drivers/extcon/extcon-usb-gpio.c | 169
> -
> 2 files changed, 132 insertions(+), 40 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> index af0b903..dfc14f7 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> @@ -5,7 +5,10 @@ connected to a GPIO pin.
>
> Required properties:
> - compatible: Should be "linux,extcon-usb-gpio"
> +
> +Either one of id-gpio or vbus-gpio must be present. Both can be present as
> well.
> - id-gpio: gpio for USB ID pin. See gpio binding.
> +- vbus-gpio: gpio for USB VBUS pin.
>
> Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
> extcon_usb1 {
> diff --git a/drivers/extcon/extcon-usb-gpio.c
> b/drivers/extcon/extcon-usb-gpio.c
> index a27d350..d589c5f 100644
> --- a/drivers/extcon/extcon-usb-gpio.c
> +++ b/drivers/extcon/extcon-usb-gpio.c
> @@ -24,7 +24,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -36,7 +35,9 @@ struct usb_extcon_info {
> struct extcon_dev *edev;
>
> struct gpio_desc *id_gpiod;
> + struct gpio_desc *vbus_gpiod;
> int id_irq;
> + int vbus_irq;
>
> unsigned long debounce_jiffies;
> struct delayed_work wq_detcable;
> @@ -48,31 +49,47 @@ static const unsigned int usb_extcon_cable[] = {
> EXTCON_NONE,
> };
>
> +/*
> + * "USB" = VBUS and "USB-HOST" = !ID, so we have:
> + * Both "USB" and "USB-HOST" can't be set as active at the
> + * same time so if "USB-HOST" is active (i.e. ID is 0) we keep "USB"
> inactive
> + * even if VBUS is on.
> + *
> + * State |ID | VBUS
> + *
> + * [1] USB|H|H
> + * [2] none |H|L
> + * [3] USB-HOST |L|H
> + * [4] USB-HOST |L|L
> + *
> + * In case we have only one of these signals:
> + * - VBUS only - we want to distinguish between [1] and [2], so ID is always
> 1.
> + * - ID only - we want to distinguish between [1] and [4], so VBUS = ID.
> +*/
> static void usb_extcon_detect_cable(struct work_struct *work)
> {
> - int id;
> + int id, vbus;
> struct usb_extcon_info *info = container_of(to_delayed_work(work),
> struct usb_extcon_info,
> wq_detcable);
>
> - /* check ID and update cable state */
> - id = gpiod_get_value_cansleep(info->id_gpiod);
> - if (id) {
> - /*
> - * ID = 1 means USB HOST cable detached.
> - * As we don't have event for USB peripheral cable attached,
> - * we simulate USB peripheral attach here.
> - */
> + /* check ID and VBUS and update cable state */
> + id = info->id_gpiod ?
> + gpiod_get_value_cansleep(info->id_gpiod) : 1;
> + vbus = info->vbus_gpiod ?
> + gpiod_get_value_cansleep(info->vbus_gpiod) : id;
> +
> + /* at first we clean states which are no longer active */
> + if (id)
> extcon_set_state_sync(info->edev, EXTCON_USB_HOST, false);
> - extcon_set_state_sync(info->edev, EXTCON_USB, true);
> - } else {
> - /*
> - * ID = 0 means USB HOST cable attached.
> - * As we don't have event for USB peripheral cable detached,
> - * we simulate USB peripheral detach here.
> - */
> + if (!vbus)
> extcon_set_state_sync(info->edev, EXTCON_USB, false);
> +
> + if (!id) {
> extcon_set_state_sync(info->edev, EXTCON_USB_HOST, true);
> + } else {
> + if (vbus)
> + extcon_set_state_sync(info->edev, EXTCON_USB, true);
> }
> }
>
> @@ -101,12 +118,21 @@ static int usb_extcon_probe(struct platform_device
> *pdev)
> return -ENOMEM;
>
> info->dev = dev;
> - info->id_gpiod = devm_gpiod_get(&pdev->dev, "id", GPIOD_IN);
> - if (IS_ERR(info->id_gpiod)) {
> - dev_err(dev, "fail
Re: linux-next: build failure after merge of the rdma tree
Hi Christoph, On Tue, 27 Sep 2016 07:04:15 +0200 Christoph Hellwig wrote: > > On Tue, Sep 27, 2016 at 11:23:34AM +1000, Stephen Rothwell wrote: > > Hi Doug, > > > > After merging the rdma tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > Please just disable broken staging code like lustre for the linux-next > builds. We had that discussion before, didn't we? Yeah, sorry. Note, however, that you bothered to fix up this same staging file in another of your patches ... -- Cheers, Stephen Rothwell
RE: [v6,2/2] QE: remove PPCisms for QE
On Tue, Sep 27, 2016 at 7:12AM -0500, Scott Wood wrote: > -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Tuesday, September 27, 2016 7:12 AM > To: Qiang Zhao > Cc: linuxppc-...@lists.ozlabs.org; pku@gmail.com; X.B. Xie > ; linux-kernel@vger.kernel.org > Subject: Re: [v6,2/2] QE: remove PPCisms for QE > > On Mon, 2016-09-26 at 01:46 +, Qiang Zhao wrote: > > On Sun, Sep 25, 2016 at 12:19PM -0500, Scott Wood wrote: > > > > > > > > -Original Message- > > > From: Scott Wood [mailto:o...@buserror.net] > > > Sent: Sunday, September 25, 2016 12:19 PM > > > To: Qiang Zhao > > > Cc: linuxppc-...@lists.ozlabs.org; pku@gmail.com; X.B. Xie > > > ; linux-kernel@vger.kernel.org > > > Subject: Re: [v6,2/2] QE: remove PPCisms for QE > > > > > > On Sat, Sep 24, 2016 at 11:14:11PM -0500, Scott Wood wrote: > > > > > > > > On Fri, Sep 23, 2016 at 10:20:32AM +0800, Zhao Qiang wrote: > > > > > > > > > > QE was supported on PowerPC, and dependent on PPC, Now it is > > > > > supported on other platforms. so remove PPCisms. > > > > > > > > > > Signed-off-by: Zhao Qiang > > > > > --- > > > > > Changes for v2: > > > > > - na > > > > > Changes for v3: > > > > > - add NO_IRQ > > > > > Changes for v4: > > > > > - modify spin_event_timeout to opencoded timeout loop > > > > > - remove NO_IRQ > > > > > - modify virq_to_hw to opencoed code Changes for v5: > > > > > - modify commit msg > > > > > - modify depends of QUICC_ENGINE > > > > > - add kerneldoc header for qe_issue_cmd Changes for v6: > > > > > - add dependency on FSL_SOC and PPC32 for drivers > > > > > depending on QUICC_ENGING but not available on ARM > > > > > > > > > > drivers/irqchip/qe_ic.c| 28 +++- > > > > > drivers/net/ethernet/freescale/Kconfig | 10 ++--- > > > > > drivers/soc/fsl/qe/Kconfig | 2 +- > > > > > drivers/soc/fsl/qe/qe.c| 80 > > > > > - > > > > > - > > > > > drivers/soc/fsl/qe/qe_io.c | 42 -- > > > > > drivers/soc/fsl/qe/qe_tdm.c| 8 ++-- > > > > > drivers/soc/fsl/qe/ucc.c | 10 ++--- > > > > > drivers/soc/fsl/qe/ucc_fast.c | 68 > > > > > ++--- > > > > > > > > > > drivers/tty/serial/Kconfig | 2 +- > > > > > drivers/usb/gadget/udc/Kconfig | 2 +- > > > > > drivers/usb/host/Kconfig | 2 +- > > > > > include/soc/fsl/qe/qe.h| 1 - > > > > > include/soc/fsl/qe/qe_ic.h | 12 ++--- > > > > > 13 files changed, 141 insertions(+), 126 deletions(-) > > > > I assume this means you'll be updating > > > > http://patchwork.ozlabs.org/patch/654473/ > > > > to be based on top of this... > > > Apparently that assumption was wrong, since I now see that you're > > > patching drivers/irqchip/qe_ic.c rather than drivers/soc/fsl/qe/qe_ic.c. > > > Please keep the drivers/irqchip stuff separate and send to the > > > appropriate maintainers. > > > > > You means separate drivers/irqchip/qe_ic.c part from this patch and > > send it with the other qe_ic patches? > > Is it acceptable if I modify qe_ic.c with drivers/soc/fsl/qe/qe_ic.c, > > then send qe_ic patches to move qe_ic to drivers/irqchip? > > I'd recommend against it. It would complicate getting the drivers/irqchip > patchset merged. In any case, it's too late for 4.9. Ok, thank you for your recommend. BR -Zhao Qiang
Re: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses
> When you need to make changes to patches that are part of a series, > you must resubmit the entire series, I imagine that will happen when the patch review time passed by a bit more as Paul Bolle requested it yesterday. > not just the things that are changes. Thanks for your reminder. Regards, Markus
Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)
Andrey Utkin writes: >> Does (only) adding the >> >> pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val); >> >> in solo_reg_write() help? > > Yes. > I have posted a patch with this change few days ago, I thought you have > noticed it. Well, I think you haven't sent me a copy. Anyway, it would be great to determine where exactly writes need a flush. Adding it everywhere is a bit suboptimal, one would think. Can you share some details about the machine you are experiencing the problems on? CPU, chipset? I'd try to see if I can recreate the problem. Alternatively, you could investigate yourself - at first you could put pci_read_config_word() at the end of subroutines (including return statements) using solo_reg_write(). And in that solo_p2m_dma_desc(), before wait_for_completion_timeout(). Then eliminate them using some sort of binary search to see which ones are required. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
[PATCH 0/3] ARM: dts: omap5 uevm: add LEDs, USR1 button and EEPROM
These patches configure * the EEPROM * the LEDs (with some default triggers) * the USR1 gpio button for the OMAP5 UEVM board. H. Nikolaus Schaller (3): DT: EVM: add EEPROM DT: EVM: add LEDs DT: EVM: add USR1 button arch/arm/boot/dts/omap5-uevm.dts | 92 1 file changed, 92 insertions(+) -- 2.7.3
[PATCH 3/3] DT: EVM: add USR1 button
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap5-uevm.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 19f5f0a..1b919f5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -18,6 +18,25 @@
reg = <0x8000 0x7F00>; /* 2032 MB */
};
+ evm_keys {
+ compatible = "gpio-keys";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&evm_keys_pins>;
+
+ #address-cells = <7>;
+ #size-cells = <0>;
+
+ btn1 {
+ label = "BTN1";
+ linux,code = <169>;
+ gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;/* gpio3_83 */
+ gpio-key,wakeup;
+ autorepeat;
+ debounce_interval = <50>;
+ };
+ };
+
evm_leds {
compatible = "gpio-leds";
@@ -105,6 +124,12 @@
};
&omap5_pmx_core {
+ evm_keys_pins: pinmux_evm_keys_gpio_pins {
+ pinctrl-single,pins = <
+ OMAP5_IOPAD(0x0b6, PIN_INPUT | MUX_MODE6) /*
gpio3_83 */
+ >;
+ };
+
i2c5_pins: pinmux_i2c5_pins {
pinctrl-single,pins = <
OMAP5_IOPAD(0x1c6, PIN_INPUT | MUX_MODE0)
/* i2c5_scl */
--
2.7.3
[PATCH 1/3] DT: EVM: add EEPROM
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap5-uevm.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 36ff7c3..be659e8 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -23,6 +23,13 @@
vdda-supply = <&ldo4_reg>;
};
+&i2c1 {
+ eeprom@50 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ };
+};
+
&i2c5 {
pinctrl-names = "default";
pinctrl-0 = <&i2c5_pins>;
--
2.7.3
[PATCH 2/3] DT: EVM: add LEDs
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap5-uevm.dts | 60
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index be659e8..19f5f0a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -17,6 +17,66 @@
device_type = "memory";
reg = <0x8000 0x7F00>; /* 2032 MB */
};
+
+ evm_leds {
+ compatible = "gpio-leds";
+
+ led@1 {
+ label = "omap5:red:led";
+ gpios = <&gpio9 17 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ led@2 {
+ label = "omap5:green:led";
+ gpios = <&gpio9 18 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc1";
+ default-state = "off";
+ };
+
+ led@3 {
+ label = "omap5:blue:led";
+ gpios = <&gpio9 19 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc2";
+ default-state = "off";
+ };
+
+ led@4 {
+ label = "omap5:green:led1";
+ gpios = <&gpio9 2 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ default-state = "off";
+ };
+
+ led@5 {
+ label = "omap5:green:led2";
+ gpios = <&gpio9 3 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ default-state = "off";
+ };
+
+ led@6 {
+ label = "omap5:green:led3";
+ gpios = <&gpio9 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ led@7 {
+ label = "omap5:green:led4";
+ gpios = <&gpio9 5 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ led@8 {
+ label = "omap5:green:led5";
+ gpios = <&gpio9 6 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+ };
};
&hdmi {
--
2.7.3
Re: ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure
>> Memory was not released (as it would be expected) when one call >> of further resource reservations failed. > > This was the only thing in this series that triggered more than a, > very uninspired, "meh" on first read. Will it matter here if the function "kfree" will be called for the data structure members "bcs" and "inbuf" after a later function call failed within the implementation of "gigaset_initcs"? Regards, Markus
Re: ISDN-Gigaset: Fine-tuning for three function implementations
>> Use kmalloc_array() in two functions >> Improve another size determination in gigaset_initcs() >> Delete an error message for a failed memory allocation >> Release memory in gigaset_initcs() after an allocation failure > > Which "static source code analysis" was used for that discovery? Are you eventually asking more for the development tools which were involved here? * Coccinelle software * Script "checkpatch.pl" * My own eyes with help of a current text editor and its programming support Regards, Markus
RE: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.
-Original Message- From: Thomas Gleixner [mailto:t...@linutronix.de] Sent: Tuesday, September 27, 2016 3:01 AM To: Liav Rehana Cc: john.stu...@linaro.org; linux-kernel@vger.kernel.org; Elad Kanfi ; Noam Camus Subject: Re: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation. On Mon, 26 Sep 2016, Liav Rehana wrote: >> During the calculation of the nsec variable in the inline function >> timekeeping_delta_to_ns, it may undergo a sign extension if its msb is >> set just before the shift. The sign extension may, in some cases, gain >> it a value near the maximum value of the 64-bit range. This is bad >> when it is later used in a division function, such as >> __iter_div_u64_rem, where the amount of loops it will go through to >> calculate the division will be too large. >> The following commit fixes that chance of sign extension, >Again. This does not fix anything, it papers over the underlying problem that >the calling code hands in a delta which is big enough to overflow the >multiplication into the negative space. >You just extend the range of deltas >which are handled gracefully, but that does not fix the underlying problem as >we still can run into the multiplication overflow. It won't cause the >result >to be negative, but it will be crap nevertheless. >> while maintaining the type of the nsec variable as signed for other >> functions that use this variable, for possible legit negative time >> intervals. >What is this maintaining? The type of this variable changes to u64 and other >functions cannot use this variable at all because it's local to that function. >This sentence makes no sense at >all. About your first note, I understand that it doesn't fix the overflow chance, but I'm not quite sure what can be done about that. If there was a code in the calling function that detects such event, what do you think can be done about it ? Would you just print a warning and lower delta as to not overflow after the multiplication ? If not, how do you think the problem I ran into can be fixed, if not by eliminating the possibility for sign extension the way I did ? About the other note, I understood from you and John that there are some cases where negative time intervals are valid. What I meant by 'maintaining the type of the nsec variable as signed' was, that for the other functions that call the function I've changed, they do define a variable named nsec, and they define it as signed. In their implementation they assign him a value that is returned from the function I've changed. While the nsec variable is unsigned now in the function that calculates it, it can still return a value with an MSB that is set, which will be handled as negative in the caller function, where it was defined as signed. In that case, the change I added just removes the possibility of a sign extension, but the nsec variable will still be viewed as negative on the caller functions where it was supposed to return a negative value in the function I've changed.
linux-next: manual merge of the gpio tree with the arm-soc tree
Hi Linus,
Today's linux-next merge of the gpio tree got a conflict in:
arch/arm/mach-omap2/board-rx51-peripherals.c
between commit:
9b7141d01a76 ("ARM: OMAP2+: Drop legacy board file for n900")
from the arm-soc tree and commit:
9132ce450bd1 ("ARM: omap2: fix missing include")
from the gpio tree.
I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[PATCH] Fix a issue that Alps Touchpad cursor does not work
fix Touchpad cursor does not work after touching Touchpad
by 3 or more fingers.
Issue reproduction procedure
1.Three or more fingers put on Touchpad.
2.release fingers from Touchpad.
3.move the cursor by one finger.
4.the cursor does not move.
Cause
This code does not notify multi fingers state correctly to system.
For example, when three fingers release from Touchpad,
fingers state is 3 -> 0. It needs to notify
first, second and third finger's releasing state.
But this code does not notify second and third finger's
releasing state by "break" code.
Solution
Delete "break" code, and move xyz input code to the correct place.
Signed-off-by: Masaki Ota
---
drivers/hid/hid-alps.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 048befd..610df92 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -190,16 +190,16 @@ static int alps_raw_event(struct hid_device *hdev,
if (z != 0) {
input_mt_report_slot_state(hdata->input,
MT_TOOL_FINGER, 1);
+ input_report_abs(hdata->input,
+ ABS_MT_POSITION_X, x);
+ input_report_abs(hdata->input,
+ ABS_MT_POSITION_Y, y);
+ input_report_abs(hdata->input,
+ ABS_MT_PRESSURE, z);
} else {
input_mt_report_slot_state(hdata->input,
MT_TOOL_FINGER, 0);
- break;
}
-
- input_report_abs(hdata->input, ABS_MT_POSITION_X, x);
- input_report_abs(hdata->input, ABS_MT_POSITION_Y, y);
- input_report_abs(hdata->input, ABS_MT_PRESSURE, z);
-
}
input_mt_sync_frame(hdata->input);
--
2.7.4
Re: linux-next: build failure after merge of the rdma tree
On Tue, Sep 27, 2016 at 11:23:34AM +1000, Stephen Rothwell wrote: > Hi Doug, > > After merging the rdma tree, today's linux-next build (x86_64 > allmodconfig) failed like this: Please just disable broken staging code like lustre for the linux-next builds. We had that discussion before, didn't we?
linux-next: manual merge of the gpio tree with the i2c tree
Hi Linus,
Today's linux-next merge of the gpio tree got a conflict in:
drivers/gpio/gpio-pca953x.c
between commit:
6212e1d6ed40 ("gpio: pca953x: variable 'id' was used twice")
from the i2c tree and commit:
e23efa30 ("gpio: pca954x: Add vcc regulator and enable it")
from the gpio tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpio/gpio-pca953x.c
index 018f39cc19c8,5d059866d17a..
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@@ -765,29 -759,41 +759,43 @@@ static int pca953x_probe(struct i2c_cli
chip->client = client;
+ reg = devm_regulator_get(&client->dev, "vcc");
+ if (IS_ERR(reg)) {
+ ret = PTR_ERR(reg);
+ if (ret != -EPROBE_DEFER)
+ dev_err(&client->dev, "reg get err: %d\n", ret);
+ return ret;
+ }
+ ret = regulator_enable(reg);
+ if (ret) {
+ dev_err(&client->dev, "reg en err: %d\n", ret);
+ return ret;
+ }
+ chip->regulator = reg;
+
- if (id) {
- chip->driver_data = id->driver_data;
+ if (i2c_id) {
+ chip->driver_data = i2c_id->driver_data;
} else {
- const struct acpi_device_id *id;
+ const struct acpi_device_id *acpi_id;
const struct of_device_id *match;
match = of_match_device(pca953x_dt_ids, &client->dev);
if (match) {
chip->driver_data = (int)(uintptr_t)match->data;
} else {
- id = acpi_match_device(pca953x_acpi_ids, &client->dev);
- if (!id) {
+ acpi_id = acpi_match_device(pca953x_acpi_ids,
&client->dev);
- if (!acpi_id)
- return -ENODEV;
++ if (!acpi_id) {
+ ret = -ENODEV;
+ goto err_exit;
+ }
- chip->driver_data = id->driver_data;
+ chip->driver_data = acpi_id->driver_data;
}
}
- chip->chip_type = PCA_CHIP_TYPE(chip->driver_data);
-
mutex_init(&chip->i2c_lock);
+ lockdep_set_subclass(&chip->i2c_lock,
+ i2c_adapter_depth(client->adapter));
/* initialize cached registers from their original values.
* we can't share this chip with another i2c master.
Re: [PATCH v2 1/2] config: Add new CONFIG_PROVE_LOCKING_SMALL
Hi Babu. On Mon, Sep 26, 2016 at 03:31:37PM -0700, Babu Moger wrote: > Adding the new config parameter CONFIG_PROVE_LOCKING_SMALL for sparc. > > This feature limits the space used for "Lock debugging: prove locking > correctness" by about 4MB. The current sparc systms have the limitation of > 32MB size for kernel size including .text, .data and .bss sections. With > PROVE_LOCKING feature, the kernel size could grow beyond this limit and > causing system bootup issues. With this option, kernel limits the size > of the entries of lock_chains, stack_trace etc. so that kernel fits in > required size limit. This is only visible for sparc. > > Signed-off-by: Babu Moger > --- > lib/Kconfig.debug | 17 + > 1 files changed, 17 insertions(+), 0 deletions(-) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index b9cfdbf..c79de25 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -1035,6 +1035,7 @@ config PROVE_LOCKING > select DEBUG_MUTEXES > select DEBUG_LOCK_ALLOC > select TRACE_IRQFLAGS > + select PROVE_LOCKING_SMALL if SPARC > default n > help >This feature enables the kernel to prove that all locking > @@ -1070,6 +1071,22 @@ config PROVE_LOCKING > >For more details, see Documentation/locking/lockdep-design.txt. > > +config PROVE_LOCKING_SMALL > + bool "Limit the space for prove locking correctness" > + depends on PROVE_LOCKING && SPARC > + help > + This feature limits the space used for "Lock debugging: prove > + locking correctness" by about 4MB. In sparc system, all the > + kernel's code, data, and bss, must have locked translations in > + the TLB so that it does not hit TLB misses. The current sparc > + chips have 8 TLB entries available that may be locked down, and > + with a 4mb page size, this gives a maximum of 32mb of memory for > + the kernel size. With PROVE_LOCKING feature, the kernel size could > + grow beyond this limit and causing system bootup issues. With > + this option, kernel limits the size of the entries of lock_chains, > + stack_trace etc. to debug PROVE_LOCKING so that kernel size fits > + in 32MB. This is only visible for SPARC. Since this is only relevant for sparc, and for sparc this is "select"ed, then there is limited/no gain having this as a visible menu config option. How about adding just a simple non-visible config symbol: config PROVE_LOCKING_SMALL bool The nice help text can be added to the H file, and the select can be move to the sparc/Kconfig file where it really belongs. Sam
Re: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
On Mon, Sep 26, 2016 at 11:44:50AM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-25 20:29:27)
> > On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> > > Quoting Peter Chen (2016-09-16 18:16:05)
> > > > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > > > we need to change this mux to forward the D+/D- lines to either
> > > > > > the port or the hub. Therefore, introduce a driver for this
> > > > > > device that intercepts extcon USB_HOST events and logically
> > > > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > > > attached. When the cable goes away, it will logically deassert
> > > > > > the gpio and mux the "device" lines.
> > > > > >
> > > > > > [1]
> > > > > > https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > > > > >
> > > > > > Cc: MyungJoo Ham
> > > > > > Cc: Chanwoo Choi
> > > > > > Cc:
> > > > > > Signed-off-by: Stephen Boyd
> > > > > > ---
> > > > > >
> > > > > > Should I make the extcon part optional? I could see a case where
> > > > > > there are two
> > > > > > "OTG" ports connected to the mux (or two hubs), and for some reason
> > > > > > the
> > > > > > software may want to mux between them at runtime. If we mandate an
> > > > > > extcon,
> > > > > > that won't be possible to support. Perhaps it would be better to
> > > > > > have
> > > > > > the node, but connect it to the usb controller with a phandle
> > > > > > (maybe of_graph
> > > > > > endpoints would be useful too) so that when the controller wants to
> > > > > > mux over
> > > > > > a port it can do so.
> > > > >
> > > > > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > > > > haven't written any code around it, but the idea is to allow the
> > > > > binding
> > > > > to specify how the mux is connected to upstream and downstream D+/D-
> > > > > lines. This way, we can do some dt parsing of the endpoints and their
> > > > > parent nodes to figure out if the mux needs to be set high or low to
> > > > > use
> > > > > a device connector or a usb hub based on if the id cable is present.
> > > > > Maybe I'm over thinking things though and we could just have a DT
> > > > > property for that.
> > > > >
> > > > > soc {
> > > > > usb@78d9000 {
> > > > > extcon = <&usb_id>, <&usb_id>;
> > > >
> > > > Why you have two same extcon phandler? From my mind, one should id,
> > > > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > > > vbus support, how you support vbus detection for
> > > > connection/disconnection with PC for your chipidea msm patch set?
> > >
> > > This was already in the dts files for db410c. In the chipidea binding
> > > one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> > > understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> > > and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> > > that great on this board because we only have on gpio for this.
> >
> > I think extcon-usb-gpio.c needs to extend for supporting vbus event,
> > otherwise, the micro-b cable's connect/disconnect will introduce
> > EXTCON_USB_HOST event, if you use two <&usb_idx> for both id and
> > vbus event.
> >
>
> Sorry, I'm lost now. extcon-usb-gpio.c already supports EXTCON_USB as an
> event. Is the problem that we're using two of the same phandles in the
> binding?
No, ID and VBUS are different events.
http://www.spinics.net/lists/linux-usb/msg147004.html
--
Best Regards,
Peter Chen
Re: [PATCH v6 0/2] Add USB configuration for imx53
On Mon, Sep 26, 2016 at 01:14:18PM +0200, Fabien Lahoudere wrote: > Changes in V2: > - Patches sent to early with bad contents > Changes in V3: > - Change subject > - Split "configure imx for ULPI phy" for disable-oc code > Changes in V4: > - Fix "Change switch order" commit message > - Indent switch/case (set case on the same column as switch) > - Remove useless test in "Change switch order" > Changes in V5: > - Squash "Change switch order" and "configure imx for ULPI phy" > - Add device tree binding documentation > Changes in v6: > - Remove dt binding because we can disable the feature by using an > existing binding > > Fabien Lahoudere (2): > usb: chipidea: imx: configure imx for ULPI phy > usb: chipidea: imx: Disable internal 60Mhz clock with ULPI PHY > > drivers/usb/chipidea/ci_hdrc_imx.c | 4 ++ > drivers/usb/chipidea/ci_hdrc_imx.h | 1 + > drivers/usb/chipidea/usbmisc_imx.c | 86 > +++--- > 3 files changed, 77 insertions(+), 14 deletions(-) > > -- > 2.1.4 > I will queue them, thanks. -- Best Regards, Peter Chen
Re: [PATCH v3] mmc: sdhci-msm: Add pm_runtime and system PM support
Hi Ulf, On 9/23/2016 3:37 PM, Ulf Hansson wrote: [...] Is there anything else needed in msm sdhci driver so that the auto tuning is taken care of? I am not familiar with any other than sdhci-esdhc-imx which supports the SDHCI_TUNING_MODE_3. I may be wrong though. In the sdhci-esdhc-imx case, enabling of auto tuning seems to be done in esdhc_post_tuning(), where a vendor specific register (ESDHC_MIX_CTRL) is being written to. Perhaps something similar in your case? Thanks Ulf for the comments. Will check this and see if there is something of this sort we have to do to achieve auto tuning. Adding Ritesh who has been posting some SDHCI MSM patches recently in case he knows about this. Internally, we don't use this Auto re-tuning and rely on explicit re-tune by host driver. Question though - 1. why do we need to call sdhci_runtime_resume/suspend from sdhci_msm_runtime_suspend/resume? From what I see is, sdhci_runtime_susend/resume will do reset and re-program of host->pwr and host->clk because of which a retune will be required for the next command after runtime resume. We can *only* disable and enable the clocks in sdhci_msm_runtime_suspend/resume? Thoughts? With this, I suppose you would not see any issue. I see. I assumes that means saving/restoring register context will automatically handled by some other outer logic, when doing clock gating/ungating? In other words, if the controller has valid tuning values, those will be re-used and restored when clock ungating happens? Yes, that is my understanding too. I double confirmed with HW team about this. So, even if we gate the clock directly at GCC, sdhc msm controller is capable of restoring it's register values. In this case, it is not required to call for sdhci_runtime_suspend/resume from sdhci_msm_runtime routines right? Instead we can only have disabling/enabling of clks from sdhci_msm_runtime_suspend/resume. Does this sounds good? Though for this issue, since internally also auto retuning is never used, we can have this mode disabled. I can once again check with HW team to get more details about this mode for MSM controller. Regards, Pramod Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI
Hello,
Ping?
- Sanchayan.
On 16-09-19 10:41:51, Sanchayan Maity wrote:
> Remove the use of DDC I2C bus bitbang to support reading of EDID
> and rely on support from internal HDMI I2C master controller instead.
> As a result remove the device tree property ddc-i2c-bus.
>
> Signed-off-by: Sanchayan Maity
> ---
> Changes since v1:
>
> Change the ranking in i2c aliases
>
> v1: https://lkml.org/lkml/2016/9/14/55
> ---
> arch/arm/boot/dts/imx6q-apalis-ixora.dts | 12 +++-
> arch/arm/boot/dts/imx6qdl-apalis.dtsi| 25 +
> 2 files changed, 12 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> index 207b85b..82b81e0 100644
> --- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> +++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> @@ -55,10 +55,9 @@
>"fsl,imx6q";
>
> aliases {
> - i2c0 = &i2cddc;
> - i2c1 = &i2c1;
> - i2c2 = &i2c2;
> - i2c3 = &i2c3;
> + i2c0 = &i2c1;
> + i2c1 = &i2c2;
> + i2c2 = &i2c3;
> };
>
> aliases {
> @@ -186,11 +185,6 @@
> };
>
> &hdmi {
> - ddc-i2c-bus = <&i2cddc>;
> - status = "okay";
> -};
> -
> -&i2cddc {
> status = "okay";
> };
>
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> index 99e323b..8c67dd8 100644
> --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -53,18 +53,6 @@
> status = "disabled";
> };
>
> - /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
> - i2cddc: i2c@0 {
> - compatible = "i2c-gpio";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_i2c_ddc>;
> - gpios = <&gpio3 16 GPIO_ACTIVE_HIGH /* sda */
> - &gpio2 30 GPIO_ACTIVE_HIGH /* scl */
> - >;
> - i2c-gpio,delay-us = <2>;/* ~100 kHz */
> - status = "disabled";
> - };
> -
> reg_1p8v: regulator-1p8v {
> compatible = "regulator-fixed";
> regulator-name = "1P8V";
> @@ -209,6 +197,12 @@
> };
> };
>
> +&hdmi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hdmi_ddc>;
> + status = "disabled";
> +};
> +
> /*
> * GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
> * board)
> @@ -633,11 +627,10 @@
> >;
> };
>
> - pinctrl_i2c_ddc: gpioi2cddcgrp {
> + pinctrl_hdmi_ddc: hdmiddcgrp {
> fsl,pins = <
> - /* DDC bitbang */
> - MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
> - MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
> + MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA 0x4001b8b1
> >;
> };
>
> --
> 2.9.3
>
Re: [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module
Hello,
Ping?
- Sanchayan.
On 16-09-21 16:54:38, Sanchayan Maity wrote:
> Add support for Toradex Colibri iMX6 module.
>
> Signed-off-by: Sanchayan Maity
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253
> arch/arm/boot/dts/imx6qdl-colibri.dtsi | 890
> +++
> 3 files changed, 1144 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> create mode 100644 arch/arm/boot/dts/imx6qdl-colibri.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f79cac2..44ff380 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -323,6 +323,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6dl-aristainetos_7.dtb \
> imx6dl-aristainetos2_4.dtb \
> imx6dl-aristainetos2_7.dtb \
> + imx6dl-colibri-eval-v3.dtb \
> imx6dl-cubox-i.dtb \
> imx6dl-dfi-fs700-m60.dtb \
> imx6dl-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> new file mode 100644
> index 000..e0c2172
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-colibri.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri_imx6dl-eval-v3", "toradex,colibri_imx6dl",
> + "fsl,imx6dl";
> +
> + aliases {
> + i2c0 = &i2c2;
> + i2c1 = &i2c3;
> + };
> +
> + aliases {
> + rtc0 = &rtc_i2c;
> + rtc1 = &snvs_rtc;
> + };
> +
> + clocks {
> + /* Fixed crystal dedicated to mcp251x */
> + clk16m: clk@1 {
> + compatible = "fixed-clock";
> + reg = <1>;
> + #clock-cells = <0>;
> + clock-frequency = <1600>;
> + clock-output-names = "clk16m";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + wakeup {
> + label = "Wake-Up";
> + gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>; /* SODIMM 45 */
> + linux,code = ;
> + debounce-interval = <10>;
> + wakeup-source;
> + };
> + };
> +
> + lcd_display: display@di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "bgr666";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ipu1_lcdif>;
Re: [PATCH 1/7] selftest: sync: basic tests for sw_sync framework
Emilio López writes: > El 22/09/16 a las 06:43, Michael Ellerman escribió: >> Emilio López writes: >> >> Please don't include the *kernel* headers, they're really not meant to >> be used in userspace programs :) >> >>> +CFLAGS += -I../../../../usr/include/ >> >> That is the correct place to get them from. They'll have been put there >> by 'make headers_install'. > > My inspiration here has been tools/testing/selftests/memfd/Makefile, > which does it this way. If I only include the ones on usr then it > doesn't build, as there's no sync_file.h available, even after running > make headers_install. How am I supposed to use the ioctls from there? It looks like it's missing from include/uapi/linux/Kbuild, you need to add it to the list of exported headers: diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild index dd604395606b..40411b4ff012 100644 --- a/include/uapi/linux/Kbuild +++ b/include/uapi/linux/Kbuild @@ -397,6 +397,7 @@ header-y += stddef.h header-y += string.h header-y += suspend_ioctls.h header-y += swab.h +header-y += sync_file.h header-y += synclink.h header-y += sysctl.h header-y += sysinfo.h cheers
RE: [PATCH] scsi: be2iscsi: mark symbols static where possible
> -Original Message- > From: Baoyou Xie [mailto:baoyou@linaro.org] > Sent: Monday, September 26, 2016 5:31 PM > To: subbu.seethara...@broadcom.com; ketan.muka...@broadcom.com; > jitendra.bhiv...@broadcom.com; j...@linux.vnet.ibm.com; > martin.peter...@oracle.com > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; a...@arndb.de; > baoyou@linaro.org; xie.bao...@zte.com.cn; han@zte.com.cn; > tang.qiang...@zte.com.cn > Subject: [PATCH] scsi: be2iscsi: mark symbols static where possible > > We get 6 warnings when building kernel with W=1: > drivers/scsi/be2iscsi/be_main.c:65:1: warning: no previous prototype for > 'beiscsi_log_enable_disp' [-Wmissing-prototypes] > drivers/scsi/be2iscsi/be_main.c:78:1: warning: no previous prototype for > 'beiscsi_log_enable_change' [-Wmissing-prototypes] > drivers/scsi/be2iscsi/be_main.c:97:1: warning: no previous prototype for > 'beiscsi_log_enable_store' [-Wmissing-prototypes] > drivers/scsi/be2iscsi/be_main.c:116:1: warning: no previous prototype for > 'beiscsi_log_enable_init' [-Wmissing-prototypes] > drivers/scsi/be2iscsi/be_main.c:4587:5: warning: no previous prototype for > 'beiscsi_iotask_v2' [-Wmissing-prototypes] > drivers/scsi/be2iscsi/be_main.c:4976:6: warning: no previous prototype for > 'beiscsi_hba_attrs_init' [-Wmissing-prototypes] > > In fact, these functions are only used in the file in which they are declared and > don't need a declaration, but can be made static. > > So this patch marks these functions with 'static'. > > Signed-off-by: Baoyou Xie > --- [JB] Looks good. Reviewed by: Jitendra Bhivare
Re: [x86-tip] strange nr_cpus= boot regression
Mike Galbraith wrote: >Whew, no mythical creature infestation. Thanks, next encounter with >such an artifact should provide markedly less entertainment. Oh, no worries. Next time it'll be something else. There's no dull day with this this kernel thing ;-) -- Sent from a small device: formatting sucks and brevity is inevitable.
Re: [PATCH 00/11] splice cleanups
On Wed, Sep 14, 2016 at 10:37:05AM +0200, Miklos Szeredi wrote: > This contains assorted cleanups in the splice area: > > - add helpers for pipe buf ops instead of directly calling them > > - page cache buf doesn't seem to need confirming (since ages) > > - generic_file_splice_read() and generic_file_read() have lots of >duplication > > Git tree is here: > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git#splice My apologies for not replying back when it had been first posted, especially since I'd been actively messing with splice-related code at that time (it started in "xfs_file_splice_read: possible circular locking dependency detected" thread on xfs list). I've no objections against your inline helpers. I'm not so sure about ->confirm() and I really think that __generic_file_splice_read() should simply die. Could you rebase the beginning of that thing on top of #work.splice_read in vfs.git?
linux-next: manual merge of the percpu tree with the asm-generic tree
Hi all,
Today's linux-next merge of the percpu tree got a conflict in:
include/asm-generic/percpu.h
between commit:
acbdf0e98066 ("percpu: make this_cpu_generic_read notrace")
from the asm-generic tree and commit:
1b5ca1212742 ("percpu: improve generic percpu modify-return implementation")
from the percpu tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/asm-generic/percpu.h
index 70fefec69e61,40e887068da2..
--- a/include/asm-generic/percpu.h
+++ b/include/asm-generic/percpu.h
@@@ -108,9 -118,9 +118,9 @@@ do {
#define this_cpu_generic_read(pcp)\
({\
typeof(pcp) __ret; \
- preempt_disable(); \
+ preempt_disable_notrace(); \
- __ret = *this_cpu_ptr(&(pcp)); \
+ __ret = raw_cpu_generic_read(pcp); \
- preempt_enable(); \
+ preempt_enable_notrace(); \
__ret; \
})
Re: thousands of kworker processes with 4.7.x and 4.8-rc*
On 2016-09-26 04:07, Nikolay Borisov wrote: Not sure if that's expected behaviour or not. Why don't you sample the stacks of some of those kworker processes to see if they are all executing a parituclar piece of work. That might help you narrow down where they originate from. Cat multiple /proc/$kworker-pid/stack files and see if a pattern emerges. FYI, it was reproduced and bisected here (scroll to the bottom): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564 Tomasz Chmielewski https://lxadm.com
[PATCH] igb: Realign bad indentation
Statements should start on tabstops.
Use a single statement and test instead of multiple tests.
Signed-off-by: Joe Perches
---
drivers/net/ethernet/intel/igb/e1000_mac.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_mac.c
b/drivers/net/ethernet/intel/igb/e1000_mac.c
index 5010e2232c50..5eff82678f0b 100644
--- a/drivers/net/ethernet/intel/igb/e1000_mac.c
+++ b/drivers/net/ethernet/intel/igb/e1000_mac.c
@@ -792,15 +792,13 @@ static s32 igb_set_default_fc(struct e1000_hw *hw)
* control setting, then the variable hw->fc will
* be initialized based on a value in the EEPROM.
*/
- if (hw->mac.type == e1000_i350) {
+ if (hw->mac.type == e1000_i350)
lan_offset = NVM_82580_LAN_FUNC_OFFSET(hw->bus.func);
- ret_val = hw->nvm.ops.read(hw, NVM_INIT_CONTROL2_REG
- + lan_offset, 1, &nvm_data);
-} else {
- ret_val = hw->nvm.ops.read(hw, NVM_INIT_CONTROL2_REG,
- 1, &nvm_data);
-}
+ else
+ lan_offset = 0;
+ ret_val = hw->nvm.ops.read(hw, NVM_INIT_CONTROL2_REG + lan_offset,
+ 1, &nvm_data);
if (ret_val) {
hw_dbg("NVM Read Error\n");
goto out;
@@ -808,8 +806,7 @@ static s32 igb_set_default_fc(struct e1000_hw *hw)
if ((nvm_data & NVM_WORD0F_PAUSE_MASK) == 0)
hw->fc.requested_mode = e1000_fc_none;
- else if ((nvm_data & NVM_WORD0F_PAUSE_MASK) ==
-NVM_WORD0F_ASM_DIR)
+ else if ((nvm_data & NVM_WORD0F_PAUSE_MASK) == NVM_WORD0F_ASM_DIR)
hw->fc.requested_mode = e1000_fc_tx_pause;
else
hw->fc.requested_mode = e1000_fc_full;
--
2.10.0.rc2.1.g053435c
linux-next: manual merge of the kvm-arm tree with the tip tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
arch/arm/include/asm/arch_gicv3.h
between commit:
91ef84428a86 ("irqchip/gic-v3: Reset BPR during initialization")
from the tip tree and commit:
3d9cd95f90b2 ("ARM: gic-v3: Work around definition of gic_write_bpr1")
from the kvm-arm tree.
I fixed it up (I just used the kvm-arm tree version) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
Re: [PATCH 09/11] splice: use get_page_for_read()
On Wed, Sep 14, 2016 at 10:37:14AM +0200, Miklos Szeredi wrote: > What __generic_file_splice_read() does is get a series of uptodate pages > and put them into the pipe buffer. > > The get_page_for_read() helper can now be used to get the pages, > simplifying the code and making sure the splice(2) stays in sync with > read(2). > > For example get_page_for_read() can handle partially uptodate pages and now > splice can take advantage of these as well. ... or, better yet, kill __generic_file_splice_read() off.
Re: [PATCH 08/11] filemap: add get_page_for_read() helper
On Wed, Sep 14, 2016 at 10:37:13AM +0200, Miklos Szeredi wrote: > Getting the page for reading is pretty complicated. This functionality is > also duplicated between generic_file_read() generic_file_splice_read(). > > So first extract the common code from do_generic_file_read() into a > separate helper function that takes a filp, the page index, the offset into > the page and the byte count and returns the page ready for reading (or an > error). > > This makes do_generic_file_read() much easier to read as well. __generic_file_splice_read() horrors are not going to survive - see the patchset posted on fsdevel. do_generic_file_read() getting easier to read is certainly a good thing, provided that we don't screw the code generation for what's a fairly hot path. IOW, that one really needs profiling.
Re: [PATCH V2] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.
On 2016년 09월 23일 01:53, bseg...@google.com wrote:
> Jeehong Kim writes:
>
>>> Peter Zijlstra writes:
>>>
You forgot to Cc Ben, who gave you feedback on v1, which is rather poor
style. Also, I don't see how kernel-janitors is relevant to this patch.
This is very much not a janitorial thing.
(also, why send it twice?)
On Tue, Aug 30, 2016 at 10:12:40PM +0900, Jeehong Kim wrote:
> In case that CONFIG_HOTPLUG_CPU and CONFIG_CFS_BANDWIDTH is turned on
> and tasks in bandwidth controlled task group run on hotplug core,
> the tasks are not controlled by cfs_b->quota when hotplug core is offline
> and then online. The remaining tasks in task group consume all of
> cfs_b->quota on other cores.
>
> The cause of this problem is described as below:
>
> 1. When hotplug core is offline while tasks in task group run
> on hotplug core, unregister_fair_sched_group() deletes
> leaf_cfs_rq_list of tg->cfs_rq[cpu] from &rq_of(cfs_rq)->leaf_cfs_rq_list.
>
> 2. Then, when hotplug core is online, update_runtime_enabled()
Peter Zijlstra writes:
You forgot to Cc Ben, who gave you feedback on v1, which is rather poor
style. Also, I don't see how kernel-janitors is relevant to this patch.
This is very much not a janitorial thing.
(also, why send it twice?)
On Tue, Aug 30, 2016 at 10:12:40PM +0900, Jeehong Kim wrote:
> In case that CONFIG_HOTPLUG_CPU and CONFIG_CFS_BANDWIDTH is turned on
> and tasks in bandwidth controlled task group run on hotplug core,
> the tasks are not controlled by cfs_b->quota when hotplug core is offline
> and then online. The remaining tasks in task group consume all of
> cfs_b->quota on other cores.
>
> The cause of this problem is described as below:
>
> 1. When hotplug core is offline while tasks in task group run
> on hotplug core, unregister_fair_sched_group() deletes
> leaf_cfs_rq_list of tg->cfs_rq[cpu] from &rq_of(cfs_rq)->leaf_cfs_rq_list.
>
> 2. Then, when hotplug core is online, update_runtime_enabled()
> registers cfs_b->quota on cfs_rq->runtime_enabled of all leaf cfs_rq
> on runqueue. However, because this is before enqueue_entity() adds
> &cfs_rq->leaf_cfs_rq_list on &rq_of(cfs_rq)->leaf_cfs_rq_list,
> cfs->quota is not register on cfs_rq->runtime_enabled.
>
> To resolve this problem, this patch makes update_runtime_enabled()
> registers cfs_b->quota by using walk_tg_tree_from().
> +static int __maybe_unused __update_runtime_enabled(struct task_group
> *tg, void *data)
> {
> +struct rq *rq = data;
> +struct cfs_rq *cfs_rq = tg->cfs_rq[cpu_of(rq)];
> +struct cfs_bandwidth *cfs_b = &cfs_rq->tg->cfs_bandwidth;
>
> +raw_spin_lock(&cfs_b->lock);
> +raw_spin_unlock(&cfs_b->lock);
>
> +return 0;
> +}
> +
> +static void __maybe_unused update_runtime_enabled(struct rq *rq)
> +{
> +struct cfs_rq *cfs_rq = &rq->cfs;
> +
> +/* register cfs_b->quota on the whole tg tree */
> +rcu_read_lock();
> +walk_tg_tree_from(cfs_rq->tg, __update_runtime_enabled, tg_nop,
> (void *)rq);
> +rcu_read_unlock();
> }
Looks ok, performance on hotplug doesn't really matter. Ben, you happy
with this?
>>> I'm not 100% sure about the exact timings and mechanics of hotplug, but
>>> cfs-bandwidth wise this is ok. We may still have runtime_remaining = 1,
>>> or we may have < 0 and yet be unthrottled, but either case is ok, even
>>> if hotplug allows tasks to have migrated here already (I'm not sure,
>>> looking at the code).
>>>
>>> Now that I check again you can just loop over the list of tgs rather
>>> than the hierarchical walk_tg_tree_from, but there's certainly no harm
>>> in it.
>> Ben,
>>
>> Is there additional revision which I have to do?
>> If so, could you let me know about that?
>>
>> Regards,
>> Jeehong Kim
> Oh, no, this is fine by me.
>
>
>
Ben,
If this is fine to you, could you sign off on this patch?
Regards,
Jeehong Kim.
Re: [PATCH 06/11] pipe: no need to confirm page cache buf
On Wed, Sep 14, 2016 at 10:37:11AM +0200, Miklos Szeredi wrote: > Things could happen to that page that make it not uptodate while sitting in > the pipe, but it's questionable whether we should care about that. > Checking for being uptodate in the face of such page state change is always > going to be racy. I'm not sure it's the right thing to do here; that area looks like a victim of serious bitrot - once upon a time it was ->map(), which used to lock page, verity that it's valid, and kmap it. ->unmap() did kunmap + unlock. Then the validate part got split off (->pin(), later renamed to ->confirm()), with lock _not_ held over the kmap/kunmap. That's the point when it got racy, AFAICS. OTOH, I would really hate to hold a page locked over e.g. copying to userland - too easy to get deadlocks that way. Jens, could you comment? Pages definitely shouldn't be getting into pipe without having been uptodate; the question is what (if anything) should be done about having a page go non-uptodate (on truncate, hole-punching, etc.) while a reference to it is sitting in a pipe buffer.
Re: [PATCH 1/4] mm, compaction: more reliably increase direct compaction priority-fix
On Tuesday, September 27, 2016 12:20 AM Vlastimil Babka wrote > > When increasing the compaction priority, also reset retries. Otherwise we can > consume all retries on the lower priorities. Also pull the retries increment > into should_compact_retry() so it counts only the rounds where we actually > rely on it. > > Suggested-by: Michal Hocko > Signed-off-by: Vlastimil Babka > Acked-by: Michal Hocko > Cc: Mel Gorman > Cc: Joonsoo Kim > Cc: David Rientjes > Cc: Rik van Riel > --- Acked-by: Hillf Danton
[PATCH] i40e: Make struct i40e_stats const
Move some data to text
$ size drivers/net/ethernet/intel/i40e/i40e_ethtool.o*
textdata bss dec hex filename
25012 0 32 2504461d4
drivers/net/ethernet/intel/i40e/i40e_ethtool.o.new
228682120 32 2502061bc
drivers/net/ethernet/intel/i40e/i40e_ethtool.o.old
Signed-off-by: Joe Perches
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 1835186b62c9..d8847a19dc6b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -104,7 +104,7 @@ static const struct i40e_stats i40e_gstrings_misc_stats[] =
{
* The PF_STATs are appended to the netdev stats only when ethtool -S
* is queried on the base PF netdev, not on the VMDq or FCoE netdev.
*/
-static struct i40e_stats i40e_gstrings_stats[] = {
+static const struct i40e_stats i40e_gstrings_stats[] = {
I40E_PF_STAT("rx_bytes", stats.eth.rx_bytes),
I40E_PF_STAT("tx_bytes", stats.eth.tx_bytes),
I40E_PF_STAT("rx_unicast", stats.eth.rx_unicast),
--
2.10.0.rc2.1.g053435c
[RFC][PATCH v2 0/2] Improve libsas hotplug
v1-v2: Fix memory allocation issue in interrupt context. Yijing Wang (2): libsas: Alloc dynamic work to avoid missing sas events libsas: Fix hotplug issue in libsas drivers/scsi/libsas/sas_ata.c | 34 ++--- drivers/scsi/libsas/sas_discover.c | 245 ++-- drivers/scsi/libsas/sas_event.c | 61 + drivers/scsi/libsas/sas_expander.c | 54 ++-- drivers/scsi/libsas/sas_init.c | 31 - drivers/scsi/libsas/sas_internal.h | 45 ++- drivers/scsi/libsas/sas_phy.c | 50 +++- drivers/scsi/libsas/sas_port.c | 35 -- drivers/scsi/libsas/sas_scsi_host.c | 23 include/scsi/libsas.h | 13 +- include/scsi/sas_ata.h | 4 +- 11 files changed, 404 insertions(+), 191 deletions(-) -- 2.5.0
[RFC][PATCH v2 1/2] libsas: Alloc dynamic work to avoid missing sas events
Now libsas hotplug work is static, LLDD driver queue
the hotplug work into shost->work_q. If LLDD driver
burst post lots hotplug event to libsas, the hotplug
events may pending in the workqueue like
shost->workq
tail | PHYE_LOSS_OF_SIGNAL | PORTE_BYTES_DMAED | head
In this case, if a new PORTE_BYTES_DMAED event coming,
it would be lost, because we can not queue a work which
is already pending in the workqueue, also libsas has a
pending bit to avoid queue the same event.
The lost hotplug event make something confusing, e.g.
we have sas disks connected hardware, but we can not
found them in kernel.
This patch remove the static defined hotplug work,
and use dynamic work to avoid missing hotplug events.
Signed-off-by: Yijing Wang
Signed-off-by: Yousong He
Signed-off-by: Qilin Chen
---
drivers/scsi/libsas/sas_event.c| 61 ++
drivers/scsi/libsas/sas_init.c | 5 +---
drivers/scsi/libsas/sas_internal.h | 3 ++
drivers/scsi/libsas/sas_phy.c | 50 +--
drivers/scsi/libsas/sas_port.c | 23 +++---
include/scsi/libsas.h | 8 -
6 files changed, 66 insertions(+), 84 deletions(-)
diff --git a/drivers/scsi/libsas/sas_event.c b/drivers/scsi/libsas/sas_event.c
index aadbd53..091f5c4 100644
--- a/drivers/scsi/libsas/sas_event.c
+++ b/drivers/scsi/libsas/sas_event.c
@@ -27,6 +27,10 @@
#include "sas_internal.h"
#include "sas_dump.h"
+static const work_func_t sas_ha_event_fns[HA_NUM_EVENTS] = {
+ [HAE_RESET] = sas_hae_reset,
+};
+
void sas_queue_work(struct sas_ha_struct *ha, struct sas_work *sw)
{
if (!test_bit(SAS_HA_REGISTERED, &ha->state))
@@ -40,17 +44,14 @@ void sas_queue_work(struct sas_ha_struct *ha, struct
sas_work *sw)
scsi_queue_work(ha->core.shost, &sw->work);
}
-static void sas_queue_event(int event, unsigned long *pending,
- struct sas_work *work,
+static void sas_queue_event(int event, struct sas_work *work,
struct sas_ha_struct *ha)
{
- if (!test_and_set_bit(event, pending)) {
- unsigned long flags;
+ unsigned long flags;
- spin_lock_irqsave(&ha->lock, flags);
- sas_queue_work(ha, work);
- spin_unlock_irqrestore(&ha->lock, flags);
- }
+ spin_lock_irqsave(&ha->lock, flags);
+ sas_queue_work(ha, work);
+ spin_unlock_irqrestore(&ha->lock, flags);
}
@@ -111,52 +112,60 @@ void sas_enable_revalidation(struct sas_ha_struct *ha)
if (!test_and_clear_bit(ev, &d->pending))
continue;
- sas_queue_event(ev, &d->pending, &d->disc_work[ev].work, ha);
+ sas_queue_event(ev, &d->disc_work[ev].work, ha);
}
mutex_unlock(&ha->disco_mutex);
}
static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event event)
{
+ struct sas_ha_event *ev;
+
BUG_ON(event >= HA_NUM_EVENTS);
- sas_queue_event(event, &sas_ha->pending,
- &sas_ha->ha_events[event].work, sas_ha);
+ ev = kzalloc(sizeof(*ev), GFP_ATOMIC);
+ if (!ev)
+ return;
+
+ INIT_SAS_WORK(&ev->work, sas_ha_event_fns[event]);
+ ev->ha = sas_ha;
+ sas_queue_event(event, &ev->work, sas_ha);
}
static void notify_port_event(struct asd_sas_phy *phy, enum port_event event)
{
+ struct asd_sas_event *ev;
struct sas_ha_struct *ha = phy->ha;
BUG_ON(event >= PORT_NUM_EVENTS);
- sas_queue_event(event, &phy->port_events_pending,
- &phy->port_events[event].work, ha);
+ ev = kzalloc(sizeof(*ev), GFP_ATOMIC);
+ if (!ev)
+ return;
+
+ INIT_SAS_WORK(&ev->work, sas_port_event_fns[event]);
+ ev->phy = phy;
+ sas_queue_event(event, &ev->work, ha);
}
void sas_notify_phy_event(struct asd_sas_phy *phy, enum phy_event event)
{
+ struct asd_sas_event *ev;
struct sas_ha_struct *ha = phy->ha;
BUG_ON(event >= PHY_NUM_EVENTS);
- sas_queue_event(event, &phy->phy_events_pending,
- &phy->phy_events[event].work, ha);
+ ev = kzalloc(sizeof(*ev), GFP_ATOMIC);
+ if (!ev)
+ return;
+
+ INIT_SAS_WORK(&ev->work, sas_phy_event_fns[event]);
+ ev->phy = phy;
+ sas_queue_event(event, &ev->work, ha);
}
int sas_init_events(struct sas_ha_struct *sas_ha)
{
- static const work_func_t sas_ha_event_fns[HA_NUM_EVENTS] = {
- [HAE_RESET] = sas_hae_reset,
- };
-
- int i;
-
- for (i = 0; i < HA_NUM_EVENTS; i++) {
- INIT_SAS_WORK(&sas_ha->ha_events[i].work, sas_ha_event_fns[i]);
- sas_ha->ha_events[i].ha = sas_ha;
- }
-
sas_ha->notify_ha_event = notify_ha_event;
sas_ha->notify_port_event = notify_port_event;
sas_ha->notify_phy_event = sas_notify_phy_eve
Re: [PATCH] power: supply: bq24910_charger: reset first_time check
Hold off on this one. Currently reworking a patch series that won't need this change after all. On Thu, Sep 22, 2016 at 8:32 PM, Matt Ranostay wrote: > bq24190_register_reset() function needs to reset the bdi->first_time > condition every time to avoid spurious interrupts in suspend/resume. > > Signed-off-by: Matt Ranostay > --- > drivers/power/supply/bq24190_charger.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/power/supply/bq24190_charger.c > b/drivers/power/supply/bq24190_charger.c > index f5746b9f4e83..cc1dbdb1737f 100644 > --- a/drivers/power/supply/bq24190_charger.c > +++ b/drivers/power/supply/bq24190_charger.c > @@ -513,6 +513,8 @@ static int bq24190_register_reset(struct bq24190_dev_info > *bdi) > int ret, limit = 100; > u8 v; > > + bdi->first_time = true; > + > /* Reset the registers */ > ret = bq24190_write_mask(bdi, BQ24190_REG_POC, > BQ24190_REG_POC_RESET_MASK, > @@ -1375,7 +1377,6 @@ static int bq24190_probe(struct i2c_client *client, > bdi->model = id->driver_data; > strncpy(bdi->model_name, id->name, I2C_NAME_SIZE); > mutex_init(&bdi->f_reg_lock); > - bdi->first_time = true; > bdi->charger_health_valid = false; > bdi->battery_health_valid = false; > bdi->battery_status_valid = false; > -- > 2.7.4 >
[RFC][PATCH v2 2/2] libsas: Fix hotplug issue in libsas
Now the libsas hotplug has some issues, Dan Williams report
a similar bug here:
https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html
The root cause of the issues is we use one workqueue(shost->work_q) to
process libsas event, and we divide a hot-on or hot-remove flow to several
events to process. E.g. we start a new work and queue it into the same
workqueue in sas_deform_port() to remove the children devices after
the sas port. So if there is one hot-on event between remove sas port
and destruct the children devices, some unexpected errors would
be caused.
This patch modify hotplug event process mechanism to solve the
hotplug problems in libsas. We move device add/del operation to
a new workqueue(named sas_dev_wq).
And we use sas_port_alloc_num to replace sas_port_alloc function
because when discovery is concurrently executing with the device
adding or destroying, the old sas port resource may have not
completely deleted, the new sas port resource of the same name
will be created, and this will cause calltrace about sysfs
device node.
Signed-off-by: Yijing Wang
Signed-off-by: Yousong He
Signed-off-by: Qilin Chen
---
drivers/scsi/libsas/sas_ata.c | 34 ++---
drivers/scsi/libsas/sas_discover.c | 245 ++--
drivers/scsi/libsas/sas_expander.c | 54 ++--
drivers/scsi/libsas/sas_init.c | 26 +++-
drivers/scsi/libsas/sas_internal.h | 46 ++-
drivers/scsi/libsas/sas_port.c | 12 +-
drivers/scsi/libsas/sas_scsi_host.c | 23
include/scsi/libsas.h | 5 +-
include/scsi/sas_ata.h | 4 +-
9 files changed, 340 insertions(+), 109 deletions(-)
diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index 763f012..877efa8 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -619,32 +619,22 @@ static int sas_get_ata_command_set(struct domain_device
*dev)
return ata_dev_classify(&tf);
}
-void sas_probe_sata(struct asd_sas_port *port)
+void sas_probe_sata_device(struct domain_device *dev)
{
- struct domain_device *dev, *n;
-
- mutex_lock(&port->ha->disco_mutex);
- list_for_each_entry(dev, &port->disco_list, disco_list_node) {
- if (!dev_is_sata(dev))
- continue;
-
- ata_sas_async_probe(dev->sata_dev.ap);
- }
- mutex_unlock(&port->ha->disco_mutex);
+ struct asd_sas_port *port = dev->port;
- list_for_each_entry_safe(dev, n, &port->disco_list, disco_list_node) {
- if (!dev_is_sata(dev))
- continue;
+ if (!port || !port->ha || !dev_is_sata(dev))
+ return;
- sas_ata_wait_eh(dev);
+ ata_sas_async_probe(dev->sata_dev.ap);
- /* if libata could not bring the link up, don't surface
-* the device
-*/
- if (ata_dev_disabled(sas_to_ata_dev(dev)))
- sas_fail_probe(dev, __func__, -ENODEV);
- }
+ sas_ata_wait_eh(dev);
+ /* if libata could not bring the link up, don't surface
+* the device
+*/
+ if (ata_dev_disabled(sas_to_ata_dev(dev)))
+ sas_fail_probe(dev, __func__, -ENODEV);
}
static void sas_ata_flush_pm_eh(struct asd_sas_port *port, const char *func)
@@ -729,7 +719,7 @@ int sas_discover_sata(struct domain_device *dev)
if (res)
return res;
- sas_discover_event(dev->port, DISCE_PROBE);
+ sas_notify_device_event(dev, SAS_DEVICE_ADD);
return 0;
}
diff --git a/drivers/scsi/libsas/sas_discover.c
b/drivers/scsi/libsas/sas_discover.c
index 60de662..ea57c66 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -34,6 +34,12 @@
#include
#include "../scsi_sas_internal.h"
+
+static void sas_unregister_common_dev(struct asd_sas_port *port,
+ struct domain_device *dev);
+static void sas_unregister_fail_dev(struct asd_sas_port *port,
+ struct domain_device *dev);
+
/* -- Basic task processing for discovery purposes -- */
void sas_init_dev(struct domain_device *dev)
@@ -158,11 +164,8 @@ static int sas_get_port_device(struct asd_sas_port *port)
if (dev_is_sata(dev) || dev->dev_type == SAS_END_DEVICE)
list_add_tail(&dev->disco_list_node, &port->disco_list);
- else {
- spin_lock_irq(&port->dev_list_lock);
- list_add_tail(&dev->dev_list_node, &port->dev_list);
- spin_unlock_irq(&port->dev_list_lock);
- }
+ else
+ list_add_tail(&dev->dev_list_node, &port->expander_list);
spin_lock_irq(&port->phy_list_lock);
list_for_each_entry(phy, &port->phy_list, port_phy_el)
@@ -212,34 +215,83 @@ void sas_notify_lldd_dev_gone(struct domain_device *dev)
}
}
-static void sas_probe_devi
Re: [x86-tip] strange nr_cpus= boot regression
On Mon, 2016-09-26 at 15:35 -0400, Thomas Gleixner wrote: > On Mon, 26 Sep 2016, Thomas Gleixner wrote: > > Can you please provide your .config and the dmesg of a bad and a good run? > > Don't bother. I found it. > > It's a merge artifact. So git bisect pointing at the merge commit is > entirely correct. > > mainline moves > > > num_processors++; > > to a different place in the function. See commit c291b0151585. > > Now the nodeid patch set in x86/apic does not have this commit and so > f7c28833c2520 removes num_processors++ from the original location before > c291b0151585. Whew, no mythical creature infestation. Thanks, next encounter with such an artifact should provide markedly less entertainment. -Mike
RE: Regression in 4.8 - CPU speed set very low
On 2016.09.26 18:31 Srinivas Pandruvada wrote: > On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote: >> On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote: >>> On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger wrote: >>> But for both we need a reproducer anyway. >> I do not have a reliable reproducer. The condition has always >> happened when >> running a high-compute job such as a 'make -j8' on the kernel, or >> building the >> RPM for openSUSE's implementation of VirtualBox. The latter is what >> I'm using >> for most of my testing. Run some CPU stressor and get all your CPU's going at 100% load. And watch your core temperatures while you do so. > >>> It also would be good to rule out the thermal throttling (as per >>> the Srinivas' comments). It is almost certainly thermal throttling, or similar causing Clock modulation, of it seems 50%. >>> >>> For now, please tell me what's in >>> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq >> 80 > Your effective freq is lower than 800MHz. One of the possible reason is > thermal throttling. > > What distro you are using? And what make and model of LapTop?
Re: [PATCH 00/17] clean up readlinks
On Mon, Sep 12, 2016 at 09:29:02PM +0200, Miklos Szeredi wrote: > The first patch is actually a bug fix, but I put it into this bunch for > simplicity... > > The rest are really cleanups as well as minor bugfixes that are byproducts > of the cleanups. > > This series builds on the fact that i_op.readlink is already set to > generic_readlink() in 43/50 of the cases. And of those 7 only 4 are doing > something special. So more than 90% of readlinks are/could actually just > call back into get_link. > > The interesting cases are: > > - AFS, which has readlink but not get_link > - proc, that allow jumping while following symlinks > > The first is handled by setting IOP_NOFOLLOW on the inode by the fs. > > The second one is handled by introducing is_following_link() which returns > a bool depending on whether current->nameidata is NULL or not. If it > returns false ->get_link() should behave as ->readlink() did. Otherwise it > should behave as id did previously. > > Builds and boots. Can even read symlinks. I have no problem with "let's get rid of generic_readlink" - not that it bought us much, but sure, if you want to have decision made based upon the combination of flags, let's do it. Just make NULL ->readlink + non-NULL ->get_link() mean generic_readlink(), and we are done. Especially if you do the usual "set the flag on inode the first time we need to check". I also have no problem with overlayfs and ecryptfs assuming that we only deal with normal symlinks. Overloading ->get_link() for procfs-style ones is just plain wrong, though. Your current->nameidata != NULL thing is bloody brittle - what happens if some code triggers those readlinks when called by something during pathname resolution? Sure, right now existing callers won't. But it doesn't take much to grow such a place _and_ have the implications go unnoticed for quite a while.
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
On Mon, Sep 26, 2016 at 02:43:17PM -0300, Marcelo Cerri wrote: > > Wouldn't be enough to provide a pair of import/export functions as the > padlock-sha driver does? I don't think that will help as ultimately you need to call the export function on the fallback and that's what requires the extra memory. In fact very operation involving the fallback will need that extra memory too. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3] Input: elants_i2c - get product id on recovery mode for FW update
On Mon, Sep 26, 2016 at 10:30:56AM +0800, Johnny.Chuang wrote:
> There is only one different which is adding a new empty line for coding
> style.
>
> > if (!error)
> > - error = elants_i2c_query_fw_id(ts);
> > + error = error2;
> > +
> > if (!error)
> > error = elants_i2c_query_fw_version(ts);
OK, since I already applied the other version I'll ignore this one as
the difference is not important.
Thanks.
>
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: Saturday, September 24, 2016 5:31 AM
> To: Johnny Chuang
> Cc: Daniel Kurtz; Jennifer Tsai; linux-kernel@vger.kernel.org;
> linux-in...@vger.kernel.org; James Chen; Paul Liang; Jeff Chuang; Agnes
> Cheng
> Subject: Re: [PATCH v3] Input: elants_i2c - get product id on recovery mode
> for FW update
>
> On Fri, Sep 23, 2016 at 04:01:17PM +0800, Johnny Chuang wrote:
> > This CL takes the responsibility for getting product/hardware id on
> > recovery mode.
> > It will fix firmware update script could not find correspond firmware
> > file name on recovery mode.
> > BTW, firmware must need to support reading product/hardware id on boot
> > code.
> >
> > Signed-off-by: Johnny Chuang
>
> This appears to be exactly the same as to what I already have in my "next"
> branch...
>
> > ---
> > drivers/input/touchscreen/elants_i2c.c | 31
> > ---
> > 1 file changed, 20 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/elants_i2c.c
> > b/drivers/input/touchscreen/elants_i2c.c
> > index ac09855..02aec28 100644
> > --- a/drivers/input/touchscreen/elants_i2c.c
> > +++ b/drivers/input/touchscreen/elants_i2c.c
> > @@ -298,7 +298,7 @@ static u16 elants_i2c_parse_version(u8 *buf)
> > return get_unaligned_be32(buf) >> 4; }
> >
> > -static int elants_i2c_query_fw_id(struct elants_data *ts)
> > +static int elants_i2c_query_hw_version(struct elants_data *ts)
> > {
> > struct i2c_client *client = ts->client;
> > int error, retry_cnt;
> > @@ -318,8 +318,13 @@ static int elants_i2c_query_fw_id(struct elants_data
> *ts)
> > error, (int)sizeof(resp), resp);
> > }
> >
> > - dev_err(&client->dev,
> > - "Failed to read fw id or fw id is invalid\n");
> > + if (error) {
> > + dev_err(&client->dev,
> > + "Failed to read fw id: %d\n", error);
> > + return error;
> > + }
> > +
> > + dev_err(&client->dev, "Invalid fw id: %#04x\n", ts->hw_version);
> >
> > return -EINVAL;
> > }
> > @@ -508,7 +513,7 @@ static int elants_i2c_fastboot(struct i2c_client
> > *client) static int elants_i2c_initialize(struct elants_data *ts) {
> > struct i2c_client *client = ts->client;
> > - int error, retry_cnt;
> > + int error, error2, retry_cnt;
> > const u8 hello_packet[] = { 0x55, 0x55, 0x55, 0x55 };
> > const u8 recov_packet[] = { 0x55, 0x55, 0x80, 0x80 };
> > u8 buf[HEADER_SIZE];
> > @@ -553,18 +558,22 @@ static int elants_i2c_initialize(struct elants_data
> *ts)
> > }
> > }
> >
> > + /* hw version is available even if device in recovery state */
> > + error2 = elants_i2c_query_hw_version(ts);
> > if (!error)
> > - error = elants_i2c_query_fw_id(ts);
> > + error = error2;
> > +
> > if (!error)
> > error = elants_i2c_query_fw_version(ts);
> > + if (!error)
> > + error = elants_i2c_query_test_version(ts);
> > + if (!error)
> > + error = elants_i2c_query_bc_version(ts);
> > + if (!error)
> > + error = elants_i2c_query_ts_info(ts);
> >
> > - if (error) {
> > + if (error)
> > ts->iap_mode = ELAN_IAP_RECOVERY;
> > - } else {
> > - elants_i2c_query_test_version(ts);
> > - elants_i2c_query_bc_version(ts);
> > - elants_i2c_query_ts_info(ts);
> > - }
> >
> > return 0;
> > }
> > --
> > 1.8.3.2
> >
>
> --
> Dmitry
>
--
Dmitry
Re: Regression in 4.8 - CPU speed set very low
On 09/26/2016 08:30 PM, Srinivas Pandruvada wrote: On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote: On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote: On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger wrote: On 09/26/2016 05:16 PM, Rafael J. Wysocki wrote: On Tue, Sep 27, 2016 at 12:09 AM, Larry Finger wrote: Maybe it's better to try diagnose the problem instead of spending more time on bisection. In my original post, I asked for such help, but nothing until today. I had no idea what to check, but now I have a better idea. I'd like to know whether or not 4.7 was definitely good, though. I never saw this problem with 4.7, but given the difficulty in triggering the problem, my tests may not have been definitive. If it is one of them, it may be a while before I dare call this one "good". In one respect, that is good as I will be traveling tomorrow and Wednesday. What does "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver" say? intel_pstate You probably don't need to worry about all of the cpufreq changes in 4.8-rc, then. Only a few of them affect intel_pstate and I don't see how any of them may lead to the observed symptoms. First off, if you have a reproducer, please run it on 4.7 and see if you can trigger the issue in there. I'm running 4.8-rc7 at the moment hoping to trigger the problem and get the data requested by Srinivas. Once I get that, I will try 4.7 again. Second, it would be good to have a look at the output from the cpu_frequency and pstate_sample tracepoints around when the issue triggers. The pstate_sample one would be more interesting. But for both we need a reproducer anyway. I do not have a reliable reproducer. The condition has always happened when running a high-compute job such as a 'make -j8' on the kernel, or building the RPM for openSUSE's implementation of VirtualBox. The latter is what I'm using for most of my testing. It also would be good to rule out the thermal throttling (as per the Srinivas' comments). For now, please tell me what's in /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq 80 Your effective freq is lower than 800MHz. One of the possible reason is thermal throttling. What distro you are using? openSUSE Leap 42.1. Larry
Re: [PATCH] watchdog: hpwdt: add support for iLO5
On 09/26/2016 11:57 AM, Brian Boylston wrote:
iLO5 will offer the same watchdog timer as previous generations, but the
PCI subsystem vendor ID will be PCI_VENDOR_ID_HP_3PAR (0x1590) instead of
PCI_VENDOR_ID_HP (0x103c). Add 0x1590 to the whitelist and be more
specific when ignoring the 103c,1979 device.
Signed-off-by: Brian Boylston
Reviewed-by: Guenter Roeck
---
drivers/watchdog/hpwdt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
index 8f89bd8..70c7194 100644
--- a/drivers/watchdog/hpwdt.c
+++ b/drivers/watchdog/hpwdt.c
@@ -39,7 +39,7 @@
#include
#include
-#define HPWDT_VERSION "1.3.3"
+#define HPWDT_VERSION "1.4.0"
#define SECS_TO_TICKS(secs)((secs) * 1000 / 128)
#define TICKS_TO_SECS(ticks) ((ticks) * 128 / 1000)
#define HPWDT_MAX_TIMERTICKS_TO_SECS(65535)
@@ -814,7 +814,8 @@ static int hpwdt_init_one(struct pci_dev *dev,
* not run on a legacy ASM box.
* So we only support the G5 ProLiant servers and higher.
*/
- if (dev->subsystem_vendor != PCI_VENDOR_ID_HP) {
+ if (dev->subsystem_vendor != PCI_VENDOR_ID_HP &&
+ dev->subsystem_vendor != PCI_VENDOR_ID_HP_3PAR) {
dev_warn(&dev->dev,
"This server does not have an iLO2+ ASIC.\n");
return -ENODEV;
@@ -823,7 +824,8 @@ static int hpwdt_init_one(struct pci_dev *dev,
/*
* Ignore all auxilary iLO devices with the following PCI ID
*/
- if (dev->subsystem_device == 0x1979)
+ if (dev->subsystem_vendor == PCI_VENDOR_ID_HP &&
+ dev->subsystem_device == 0x1979)
return -ENODEV;
if (pci_enable_device(dev)) {
Re: [PATCH 1/2] f2fs: fix to commit bio cache after flushing node pages
On 2016/9/27 9:39, Jaegeuk Kim wrote:
> On Tue, Sep 27, 2016 at 08:57:41AM +0800, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2016/9/27 2:33, Jaegeuk Kim wrote:
>>> Hi Chao,
>>>
>>> On Tue, Sep 27, 2016 at 12:09:52AM +0800, Chao Yu wrote:
From: Chao Yu
In sync_node_pages, we won't check and commit last merged pages in private
bio cache of f2fs, as these pages were taged as writeback, someone who is
waiting for writebacking of the page will be blocked until the cache was
committed by someone else.
We need to commit node type bio cache to avoid potential deadlock or long
delay of waiting writeback.
Signed-off-by: Chao Yu
---
fs/f2fs/node.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 9faddcd..f73f774 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1416,6 +1416,7 @@ int sync_node_pages(struct f2fs_sb_info *sbi, struct
writeback_control *wbc)
struct pagevec pvec;
int step = 0;
int nwritten = 0;
+ int ret = 0;
pagevec_init(&pvec, 0);
@@ -1436,7 +1437,8 @@ next_step:
if (unlikely(f2fs_cp_error(sbi))) {
pagevec_release(&pvec);
- return -EIO;
+ ret = -EIO;
+ goto out;
}
/*
@@ -1487,6 +1489,8 @@ continue_unlock:
if (NODE_MAPPING(sbi)->a_ops->writepage(page, wbc))
unlock_page(page);
+ else
+ nwritten++;
if (--wbc->nr_to_write == 0)
break;
@@ -1504,7 +1508,10 @@ continue_unlock:
step++;
goto next_step;
}
- return nwritten;
+out:
+ if (nwritten)
+ f2fs_submit_merged_bio(sbi, NODE, WRITE);
>>>
>>> IIRC, we don't need to flush this, since f2fs_submit_merged_bio_cond() would
>>> handle this in f2fs_wait_on_page_writeback().
>>
>> Yes, it covers all the cases in f2fs private codes, but there are still some
>> codes in mm or fs directory, and they didn't use f2fs_wait_on_page_writeback
>> when waiting page writeback. Such as do_writepages && filemap_fdatawait in
>> __writeback_single_inode...
>
> The do_writepages() is okay, which will call f2fs_write_node_pages().
> The __writeback_single_inode() won't do filemap_fdatawait() with WB_SYNC_ALL.
> We don't need to take care of truncation as well.
>
> Any missing one?
Another is: while testing with first version of checkpoint error injection, I
encounter below dump stack:
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
mount D 8801c1bf7960 0 97685 97397 0x0008
8801c1bf7960 8801c1bf7930 88017590 8801c1bf7980
8801c1bf8000 7fff 88021f7be340
817c8880 8801c1bf7978 817c80a5 880214f58fc0
Call Trace:
[] ? bit_wait+0x50/0x50
[] schedule+0x35/0x80
[] schedule_timeout+0x292/0x3d0
[] ? xen_clocksource_get_cycles+0x15/0x20
[] ? ktime_get+0x3c/0xb0
[] ? bit_wait+0x50/0x50
[] io_schedule_timeout+0xa6/0x110
[] bit_wait_io+0x1b/0x60
[] __wait_on_bit+0x64/0x90
[] wait_on_page_bit+0xc4/0xd0
[] ? autoremove_wake_function+0x40/0x40
[] truncate_inode_pages_range+0x409/0x840
[] ? pcpu_free_area+0x13d/0x1a0
[] ? wake_up_bit+0x25/0x30
[] truncate_inode_pages_final+0x4c/0x60
[] f2fs_evict_inode+0x48/0x390 [f2fs]
[] evict+0xc7/0x1a0
[] iput+0x197/0x200
[] f2fs_fill_super+0xab2/0x1130 [f2fs]
[] mount_bdev+0x184/0x1c0
[] ? f2fs_commit_super+0x100/0x100 [f2fs]
[] f2fs_mount+0x15/0x20 [f2fs]
[] mount_fs+0x39/0x160
[] vfs_kern_mount+0x67/0x110
[] do_mount+0x1bb/0xc80
[] SyS_mount+0x83/0xd0
[] do_syscall_64+0x6e/0x170
[] entry_SYSCALL64_slow_path+0x25/0x25
Any thoughts?
>
>>
>> Thanks,
>>
>>>
>>> Thanks,
>>>
+ return ret;
}
int wait_on_node_pages_writeback(struct f2fs_sb_info *sbi, nid_t ino)
--
2.7.2
>>>
>>> .
>>>
>
> .
>
Re: [x86-tip] strange nr_cpus= boot regression
Hi tglx, I'm sorry for the late reply. Awfully sorry that I could not do anything help. In fact, it's my fault. I should re-base my patches after the commit c291b0151585 in time. I learned a lot from it. Thank a lot, and once again my apologies. Thanks, Dou At 09/27/2016 01:36 AM, Thomas Gleixner wrote: CC'ed: Dou Liyang On Mon, 26 Sep 2016, Mike Galbraith wrote: I've encountered a strange regression in tip, symptom is that if you boot with nr_cpus=nr_you_have, what actually boots is nr_you_have/2. Do not pass nr_cpus=, and all is well. What's the number of possible cpus in your system? Bisection repeatedly goes as below, pointing to the nodeid merge, despite both timers/core and x86/apic (nodeid) being fine. Take tip HEAD, extract all of the commits from nodeid (plus the fix), and revert them in a quilt tree, the tree remains busted. So you remove all the nodeid commits from tip/master and it's still broken? Checkout the timers/core merge commit, and merge nodeid with that, it is indeed bad. Bisecting takes you right the merge commit, with no commit being 'bad', see logs. That's more than strange. An empty merge commit being the culprit. Thanks, tglx
[PATCH v2] f2fs: introduce get_checkpoint_version for cleanup
There exists almost same codes when get the value of pre_version
and cur_version in function validate_checkpoint, this patch adds
get_checkpoint_version to clean up redundant codes.
Signed-off-by: Tiezhu Yang
---
fs/f2fs/checkpoint.c | 63 ++--
1 file changed, 37 insertions(+), 26 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index de8693c..2dbc834 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -663,45 +663,56 @@ static void write_orphan_inodes(struct f2fs_sb_info *sbi,
block_t start_blk)
}
}
-static struct page *validate_checkpoint(struct f2fs_sb_info *sbi,
- block_t cp_addr, unsigned long long *version)
+static int get_checkpoint_version(struct f2fs_sb_info *sbi, block_t cp_addr,
+ struct f2fs_checkpoint *cp_block, struct page *cp_page,
+ unsigned long long *version)
{
- struct page *cp_page_1, *cp_page_2 = NULL;
unsigned long blk_size = sbi->blocksize;
- struct f2fs_checkpoint *cp_block;
- unsigned long long cur_version = 0, pre_version = 0;
- size_t crc_offset;
+ size_t crc_offset = 0;
__u32 crc = 0;
- /* Read the 1st cp block in this CP pack */
- cp_page_1 = get_meta_page(sbi, cp_addr);
+ cp_page = get_meta_page(sbi, cp_addr);
+ cp_block = (struct f2fs_checkpoint *)page_address(cp_page);
- /* get the version number */
- cp_block = (struct f2fs_checkpoint *)page_address(cp_page_1);
crc_offset = le32_to_cpu(cp_block->checksum_offset);
- if (crc_offset >= blk_size)
- goto invalid_cp1;
+ if (crc_offset >= blk_size) {
+ f2fs_msg(sbi->sb, KERN_WARNING,
+ "%s: crc_offset is greater than or equal to blk_size.",
+ __func__);
+ return -EINVAL;
+ }
crc = le32_to_cpu(*((__le32 *)((unsigned char *)cp_block +
crc_offset)));
- if (!f2fs_crc_valid(sbi, crc, cp_block, crc_offset))
- goto invalid_cp1;
+ if (!f2fs_crc_valid(sbi, crc, cp_block, crc_offset)) {
+ f2fs_msg(sbi->sb, KERN_WARNING,
+ "%s: f2fs_crc_valid returns false.", __func__);
+ return -EINVAL;
+ }
- pre_version = cur_cp_version(cp_block);
+ *version = cur_cp_version(cp_block);
+ return 0;
+}
- /* Read the 2nd cp block in this CP pack */
- cp_addr += le32_to_cpu(cp_block->cp_pack_total_block_count) - 1;
- cp_page_2 = get_meta_page(sbi, cp_addr);
+static struct page *validate_checkpoint(struct f2fs_sb_info *sbi,
+ block_t cp_addr, unsigned long long *version)
+{
+ struct page *cp_page_1 = NULL, *cp_page_2 = NULL;
+ struct f2fs_checkpoint *cp_block = NULL;
+ unsigned long long cur_version = 0, pre_version = 0;
+ int err;
- cp_block = (struct f2fs_checkpoint *)page_address(cp_page_2);
- crc_offset = le32_to_cpu(cp_block->checksum_offset);
- if (crc_offset >= blk_size)
- goto invalid_cp2;
+ err = get_checkpoint_version(sbi, cp_addr, cp_block,
+ cp_page_1, version);
+ if (err)
+ goto invalid_cp1;
+ pre_version = *version;
- crc = le32_to_cpu(*((__le32 *)((unsigned char *)cp_block +
crc_offset)));
- if (!f2fs_crc_valid(sbi, crc, cp_block, crc_offset))
+ cp_addr += le32_to_cpu(cp_block->cp_pack_total_block_count) - 1;
+ err = get_checkpoint_version(sbi, cp_addr, cp_block,
+ cp_page_2, version);
+ if (err)
goto invalid_cp2;
-
- cur_version = cur_cp_version(cp_block);
+ cur_version = *version;
if (cur_version == pre_version) {
*version = cur_version;
--
1.8.3.1
Re: [PATCH v3] net: ip, diag -- Add diag interface for raw sockets
On 9/26/16 4:38 PM, Cyrill Gorcunov wrote:
> Something like
>
> Index: linux-ml.git/include/uapi/linux/inet_diag.h
> ===
> --- linux-ml.git.orig/include/uapi/linux/inet_diag.h2016-09-11
> 20:56:18.191584145 +0300
> +++ linux-ml.git/include/uapi/linux/inet_diag.h 2016-09-27 01:34:08.413172394
> +0300
> @@ -38,7 +38,7 @@ struct inet_diag_req_v2 {
> __u8sdiag_family;
> __u8sdiag_protocol;
> __u8idiag_ext;
> - __u8pad;
> + __u8sdiag_raw_protocol; /* SOCK_RAW only, @pad for others */
Seems like that should be a union to keep the API.
> __u32 idiag_states;
> struct inet_diag_sockid id;
> };
>
> and in raw-diag module we will use @sdiag_raw_protocol instead of
> @sdiag_protocol field. Didn't cover ss tool source code yet but
> I think the idea is seen. Still not sure if start using @pad here
> is a good idea (it's uapi), maybe beter to ask nla attribute which would
> come right afterh the inet_diag_req_v2 message?
>
seems reasonable to me since 2 protocols need to be sent to the kernel.
Alternatively, sdiag_protocol could be the actual protocol and the pad union be
a flag field with say bit 0 = INET_DIAG_FLAG_SOCK_RAW. Allows other overrides
in the future if needed.
Re: [PATCH v5 8/8] iommu/amd: Update domain into to dte entry during device driver init
On 09/20/16 at 02:53pm, Joerg Roedel wrote:
> Hmm, have you tried hooking this into the set_dma_mask call-back? Every
> driver should call it for its device, so that should be a better
> indicator to now map a new domain.
Hi Joerg,
I tried hooking this into set_dma_mask call-back, but on my local
machine with amd iommu v2, an ohci pci device doesn't call set_dma_mask.
Then IO_PAGE_FAULT printing flooded.
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI
Controller (rev 11)
Below is the patch I made using set_dma_mask call-back. So should we do
as the original method, or use set_dma_mask method and add set_dma_mask
calling in those driver which missed calling it?
>From 1ca66f886a46839cb937fd1e6a1d84b6719f23c4 Mon Sep 17 00:00:00 2001
From: Baoquan He
Date: Mon, 12 Sep 2016 08:05:15 +0800
Subject: [PATCH] iommu/amd: Update domain into to dte entry during device
driver init
All devices are supposed to reset themselves at device driver initialization
stage. At this time if in kdump kernel those on-flight DMA will be stopped
because of device reset. It's best time to update the protection domain info,
especially pte_root, to dte entry which the device relates to. Usually
device driver initialization will call set_dma_mask to set the
limitation of dma address. Do it in set_dma_mask call-back is a good
chance.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 6c37300..2a0b1ce 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2653,6 +2653,27 @@ static int amd_iommu_dma_supported(struct device *dev,
u64 mask)
return check_device(dev);
}
+static int set_dma_mask(struct device *dev, u64 mask)
+{
+ struct iommu_dev_data *dev_data = get_dev_data(dev);
+ struct protection_domain *domain = get_domain(dev);
+ u16 alias = amd_iommu_alias_table[dev_data->devid];
+ struct amd_iommu *iommu = amd_iommu_rlookup_table[dev_data->devid];
+
+ if (translation_pre_enabled(iommu) && !dev_data->domain_updated) {
+ dev_data->domain_updated = true;
+ set_dte_entry(dev_data->devid, domain, dev_data->ats.enabled);
+ if (alias != dev_data->devid)
+ set_dte_entry(alias, domain, dev_data->ats.enabled);
+ device_flush_dte(dev_data);
+ }
+
+ if (!dev->dma_mask || !amd_iommu_dma_supported(dev, mask))
+ return -EIO;
+ *dev->dma_mask = mask;
+ return 0;
+}
+
static struct dma_map_ops amd_iommu_dma_ops = {
.alloc = alloc_coherent,
.free = free_coherent,
@@ -2661,6 +2682,7 @@ static struct dma_map_ops amd_iommu_dma_ops = {
.map_sg = map_sg,
.unmap_sg = unmap_sg,
.dma_supported = amd_iommu_dma_supported,
+ .set_dma_mask = set_dma_mask,
};
static int init_reserved_iova_ranges(void)
--
2.5.5
Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware
On Mon, 2016-09-26 at 11:05 -0500, Eric W. Biederman wrote: > Ian Kent writes: > > > On Fri, 2016-09-23 at 14:15 -0500, Eric W. Biederman wrote: > > > Ian Kent writes: > > > > > > 2> On Thu, 2016-09-22 at 20:37 -0500, Eric W. Biederman wrote: > > > > > Ian Kent writes: > > > > > > > > > > > On Thu, 2016-09-22 at 10:43 -0500, Eric W. Biederman wrote: > > > > > > > Ian Kent writes: > > > > > > > > > > > > > > > Eric, Mateusz, I appreciate your spending time on this and > > > > > > > > particularly > > > > > > > > pointing > > > > > > > > out my embarrassingly stupid is_local_mountpoint() usage > > > > > > > > mistake. > > > > > > > > > > > > > > > > Please accept my apology for the inconvenience. > > > > > > > > > > > > > > > > If all goes well (in testing) I'll have follow up patches to > > > > > > > > correct > > > > > > > > this > > > > > > > > fairly > > > > > > > > soon. > > > > > > > > > > > > > > Related question. Do you happen to know how many mounts per mount > > > > > > > namespace tend to be used? It looks like it is going to be wise > > > > > > > to > > > > > > > put > > > > > > > a configurable limit on that number. And I would like the default > > > > > > > to > > > > > > > be > > > > > > > something high enough most people don't care. I believe autofs is > > > > > > > likely where people tend to use the most mounts. > > > > > > > > Yes, I agree, I did want to try and avoid changing the parameters to > > > > ->d_mamange() but passing a struct path pointer might be better in the > > > > long > > > > run > > > > anyway. > > > > > > Given that there is exactly one implementation of d_manage in the tree I > > > don't imagine it will be disruptive to change that. > > > > Yes, but it could be used by external modules. > > > > And there's also have_submounts(). > > Good point about have_submounts. > > > I can update that using the existing d_walk() infrastructure or take it > > (mostly) > > into the autofs module and get rid of have_submounts(). > > > > I'll go with the former to start with and see what people think. > > That will be interesting to so. It is not clear to me that if d_walk > needs to be updated, and if d_walk doesn't need to be updated I would > be surprised to see it take into autofs. But I am happy to look at the > end result and see what you come up with. I didn't mean d_walk() itself, just the have_submounts() function that's used only by autofs these days. That's all I'll be changing. To take this functionality into the autofs module shouldn't be a big deal as it amounts to a directory traversal with a check at each node. But I vaguely remember talk of wanting to get rid of have_submounts() and autofs being the only remaining user. So I mentioned it to try and elicit a comment, ;) > > Eric
Re: [PATCH 00/14] perf clang: Support compiling BPF script use builtin clang
On 2016/9/27 7:58, Arnaldo Carvalho de Melo wrote: Le 26 sept. 2016 8:47 PM, "Alexei Starovoitov" mailto:alexei.starovoi...@gmail.com>> a écrit : > > On Mon, Sep 26, 2016 at 09:49:30AM +0800, Wangnan (F) wrote: > > > > > > On 2016/9/24 23:16, Alexei Starovoitov wrote: > > >On Fri, Sep 23, 2016 at 12:49:47PM +, Wang Nan wrote: > > >>This patch set is the first step to implement features I announced > > >>in LinuxCon NA 2016. See page 31 of: > > >> > > >> http://events.linuxfoundation.org/sites/events/files/slides/Performance%20Monitoring%20and%20Analysis%20Using%20perf%20and%20BPF_1.pdf > > >> > > >>This patch set links LLVM and Clang libraries to perf, so perf > > >>is able to compile BPF script to BPF object on the fly. > > >Nice! > > >So single perf binary won't have llvm external dependency anymore > > >or both ways will be maintained? > > >The command line stays the same? > > > > Yes. This patch set doesn't change interface. It compiles BPF script > > with builtin clang, and if it fail, fall back to external clang. > > > > >If I understand the patches correctly, this set is establishing > > >the basic functionality and more complex features coming? > > > > > > > Yes. Following steps are: > > > > 1. Ease of use improvement: automatically include BPF functions > > declaration and macros. > > +1 > > > 2. Perf's hook: compile part of BPF script into native code, run > > them in perf when something happen. Create a channel, coordinate > > BPF and native code use bpf-output event. > > +1 > > > 3. Define a new language to support common profiling task. I'm not > > very clear what the new language should be. It may looks like lua, > > perf converts it to C then to LLVM IR with builtin clang. > > Many tracing languages were invented in the past. > At this point I'm not sure what exactly new language will solve. > To make it easier to write bpf programs? > I think it will be more fruitful to tweak clang/llvm to add > good warnings/errors for cases where we know that C is not going > be compiled into the code that the kernel verifier will accept. > Like we can complain about loops, unitialized variables, > non-inlined and unkown helper functions... all from clang/llvm. > imo that would be the better path forward and will help > both tracing and networking users that write in this restricted C. ++1 > OK. Now let's focus on the first two goals. After that let's consider how to help writing BPF program. Thank you.
Re: [PATCH] of: thermal: Fixed governor at each thermal zone
On 一, 2016-09-19 at 10:18 +0900, Inhyuk Kang wrote: > It is necessary to be added governor at each thermal_zone. > Because some governors should be operated in the during the kernel > booting > in order to avoid heating problem. > > Default governor cannot be covered all thermal zones policy because > some thermal zones want to apply different one. > For example, the power allocator governor operates differently with > step wise governor. > Hence, it is better to parse governor parameter from the device tree. > > Signed-off-by: Inhyuk Kang > The patch looks okay to me. Eduardo, what do you think of this patch? thanks, rui > diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of- > thermal.c > index b8e509c..382c440 100644 > --- a/drivers/thermal/of-thermal.c > +++ b/drivers/thermal/of-thermal.c > @@ -970,6 +970,7 @@ int __init of_parse_thermal_zones(void) > struct thermal_zone_device *zone; > struct thermal_zone_params *tzp; > int i, mask = 0; > + const char *governor; > u32 prop; > > tz = thermal_of_build_thermal_zone(child); > @@ -996,6 +997,9 @@ int __init of_parse_thermal_zones(void) > if (!of_property_read_u32(child, "sustainable- > power", &prop)) > tzp->sustainable_power = prop; > > + if (!of_property_read_string(child, "governor-name", > &governor)) > + strcpy(tzp->governor_name, governor); > + > for (i = 0; i < tz->ntrips; i++) > mask |= 1 << i; >
linux-next: manual merge of the drm-exynos tree with the drm tree
Hi Inki,
Today's linux-next merge of the drm-exynos tree got a conflict in:
drivers/gpu/drm/exynos/exynos_drm_drv.c
between commit:
2b58e98d42af ("drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support
for plane commit")
from the drm tree and commit:
3a87f9383457 ("drm/exynos: fix pending update handling")
from the drm-exynos tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/exynos/exynos_drm_drv.c
index 486943e70f70,a1bc13f4f30a..
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@@ -89,25 -63,9 +63,9 @@@ static void exynos_atomic_commit_comple
* have the relevant clocks enabled to perform the update.
*/
- for_each_crtc_in_state(state, crtc, crtc_state, i) {
- struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-
- atomic_set(&exynos_crtc->pending_update, 0);
- }
-
- for_each_plane_in_state(state, plane, plane_state, i) {
- struct exynos_drm_crtc *exynos_crtc =
- to_exynos_crtc(plane->crtc);
-
- if (!plane->crtc)
- continue;
-
- atomic_inc(&exynos_crtc->pending_update);
- }
-
- drm_atomic_helper_commit_planes(dev, state, false);
+ drm_atomic_helper_commit_planes(dev, state, 0);
- exynos_atomic_wait_for_commit(state);
+ drm_atomic_helper_wait_for_vblanks(dev, state);
drm_atomic_helper_cleanup_planes(dev, state);
Re: [LKP] [lkp] [f2fs] ec795418c4: fsmark.files_per_sec -36.3% regression
On Tue, Sep 27, 2016 at 08:50:02AM +0800, Huang, Ying wrote: > Jaegeuk Kim writes: > > > On Mon, Sep 26, 2016 at 02:26:06PM +0800, Huang, Ying wrote: > >> Hi, Jaegeuk, > >> > >> "Huang, Ying" writes: > >> > >> > Jaegeuk Kim writes: > >> > > >> >> Hello, > >> >> > >> >> On Sat, Aug 27, 2016 at 10:13:34AM +0800, Fengguang Wu wrote: > >> >>> Hi Jaegeuk, > >> >>> > >> >>> > > >> > - [lkp] [f2fs] b93f771286: aim7.jobs-per-min -81.2% regression > >> >>> > > >> > > >> >>> > > >> > The disk is 4 12G ram disk, and setup RAID0 on them via > >> >>> > > >> > mdadm. The > >> >>> > > >> > steps for aim7 is, > >> >>> > > >> > > >> >>> > > >> > cat > workfile < >> >>> > > >> > FILESIZE: 1M > >> >>> > > >> > POOLSIZE: 10M > >> >>> > > >> > 10 sync_disk_rw > >> >>> > > >> > EOF > >> >>> > > >> > > >> >>> > > >> > ( > >> >>> > > >> > echo $HOSTNAME > >> >>> > > >> > echo sync_disk_rw > >> >>> > > >> > > >> >>> > > >> > echo 1 > >> >>> > > >> > echo 600 > >> >>> > > >> > echo 2 > >> >>> > > >> > echo 600 > >> >>> > > >> > echo 1 > >> >>> > > >> > ) | ./multitask -t & > >> >>> > > >> > >> >>> > > >> Any update on these 2 regressions? Is the information is > >> >>> > > >> enough for you > >> >>> > > >> to reproduce? > >> >>> > > > > >> >>> > > > Sorry, I've had no time to dig this due to business travel now. > >> >>> > > > I'll check that when back to US. > >> >>> > > > >> >>> > > Any update? > >> >>> > > >> >>> > Sorry, how can I get multitask binary? > >> >>> > >> >>> It's part of aim7, which can be downloaded here: > >> >>> > >> >>> http://nchc.dl.sourceforge.net/project/aimbench/aim-suite7/Initial%20release/s7110.tar.Z > >> >> > >> >> Thank you for the codes. > >> >> > >> >> I've run this workload on the latest f2fs and compared performance > >> >> having > >> >> without the reported patch. (1TB nvme SSD, 16 cores, 16GB DRAM) > >> >> Interestingly, I could find slight performance improvement rather than > >> >> regression. :( > >> >> Not sure how to reproduce this. > >> > > >> > I think the difference lies on disk used. The ramdisk is used in the > >> > original test, but it appears that your memory is too small to setup the > >> > RAM disk for test. So it may be impossible for you to reproduce the > >> > test unless you can find more memory :) > >> > > >> > But we can help you to root cause the issue. What additional data do > >> > you want? perf-profile data before and after the patch? > >> > >> Any update to this regression? > > > > Sorry, no. But meanwhile, I've purchased more DRAMs. :) > > Now I'm with 128GB DRAM. I can configure 64GB as pmem. > > Is it worth to try the test again? > > I think you are the decision maker for this. You can judge whether the > test is reasonable. And we can adjust our test accordingly. > > BTW: For this test, we use brd ram disk and raid to test. Okay, let me try this again. Thanks, > > Best Regards, > Huang, Ying
Re: [PATCH 1/2] f2fs: fix to commit bio cache after flushing node pages
On Tue, Sep 27, 2016 at 08:57:41AM +0800, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2016/9/27 2:33, Jaegeuk Kim wrote:
> > Hi Chao,
> >
> > On Tue, Sep 27, 2016 at 12:09:52AM +0800, Chao Yu wrote:
> >> From: Chao Yu
> >>
> >> In sync_node_pages, we won't check and commit last merged pages in private
> >> bio cache of f2fs, as these pages were taged as writeback, someone who is
> >> waiting for writebacking of the page will be blocked until the cache was
> >> committed by someone else.
> >>
> >> We need to commit node type bio cache to avoid potential deadlock or long
> >> delay of waiting writeback.
> >>
> >> Signed-off-by: Chao Yu
> >> ---
> >> fs/f2fs/node.c | 11 +--
> >> 1 file changed, 9 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> >> index 9faddcd..f73f774 100644
> >> --- a/fs/f2fs/node.c
> >> +++ b/fs/f2fs/node.c
> >> @@ -1416,6 +1416,7 @@ int sync_node_pages(struct f2fs_sb_info *sbi, struct
> >> writeback_control *wbc)
> >>struct pagevec pvec;
> >>int step = 0;
> >>int nwritten = 0;
> >> + int ret = 0;
> >>
> >>pagevec_init(&pvec, 0);
> >>
> >> @@ -1436,7 +1437,8 @@ next_step:
> >>
> >>if (unlikely(f2fs_cp_error(sbi))) {
> >>pagevec_release(&pvec);
> >> - return -EIO;
> >> + ret = -EIO;
> >> + goto out;
> >>}
> >>
> >>/*
> >> @@ -1487,6 +1489,8 @@ continue_unlock:
> >>
> >>if (NODE_MAPPING(sbi)->a_ops->writepage(page, wbc))
> >>unlock_page(page);
> >> + else
> >> + nwritten++;
> >>
> >>if (--wbc->nr_to_write == 0)
> >>break;
> >> @@ -1504,7 +1508,10 @@ continue_unlock:
> >>step++;
> >>goto next_step;
> >>}
> >> - return nwritten;
> >> +out:
> >> + if (nwritten)
> >> + f2fs_submit_merged_bio(sbi, NODE, WRITE);
> >
> > IIRC, we don't need to flush this, since f2fs_submit_merged_bio_cond() would
> > handle this in f2fs_wait_on_page_writeback().
>
> Yes, it covers all the cases in f2fs private codes, but there are still some
> codes in mm or fs directory, and they didn't use f2fs_wait_on_page_writeback
> when waiting page writeback. Such as do_writepages && filemap_fdatawait in
> __writeback_single_inode...
The do_writepages() is okay, which will call f2fs_write_node_pages().
The __writeback_single_inode() won't do filemap_fdatawait() with WB_SYNC_ALL.
We don't need to take care of truncation as well.
Any missing one?
>
> Thanks,
>
> >
> > Thanks,
> >
> >> + return ret;
> >> }
> >>
> >> int wait_on_node_pages_writeback(struct f2fs_sb_info *sbi, nid_t ino)
> >> --
> >> 2.7.2
> >
> > .
> >
Re: [PATCH v2] fs/select: add vmalloc fallback for select(2)
On Mon, 2016-09-26 at 17:01 -0700, Andrew Morton wrote: > I don't share Eric's concerns about performance here. If the vmalloc() > is called, we're about to write to that quite large amount of memory > which we just allocated, and the vmalloc() overhead will be relatively > low. I did not care of the performance of this particular select() system call really, but other cpus because of more TLB invalidations. At least CONFIG_DEBUG_PAGEALLOC=y builds should be impacted, but maybe we do not care.
Re: Regression in 4.8 - CPU speed set very low
On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote: > On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote: > > > > On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger > r.net> wrote: > > > > > > On 09/26/2016 05:16 PM, Rafael J. Wysocki wrote: > > > > > > > > > > > > On Tue, Sep 27, 2016 at 12:09 AM, Larry Finger > > > wrote: > > > > > > > > > > > > > > > > Maybe it's better to try diagnose the problem instead of > > > > spending more > > > > time on bisection. > > > > > > In my original post, I asked for such help, but nothing until > > > today. I had > > > no idea what to check, but now I have a better idea. > > > > > > > > > > > I'd like to know whether or not 4.7 was definitely good, > > > > though. > > > > > > I never saw this problem with 4.7, but given the difficulty in > > > triggering > > > the problem, my tests may not have been definitive. > > > > > > > > > > > > > > > > > > > > > > If it is one of them, it may be a while before I dare call > > > > > this one > > > > > "good". > > > > > In one respect, that is good as I will be traveling tomorrow > > > > > and > > > > > Wednesday. > > > > > > > > What does "cat > > > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver" say? > > > > > > intel_pstate > > You probably don't need to worry about all of the cpufreq changes > > in > > 4.8-rc, then. Only a few of them affect intel_pstate and I don't > > see > > how any of them may lead to the observed symptoms. > > > > First off, if you have a reproducer, please run it on 4.7 and see > > if > > you can trigger the issue in there. > I'm running 4.8-rc7 at the moment hoping to trigger the problem and > get the data > requested by Srinivas. Once I get that, I will try 4.7 again. > > > > > > Second, it would be good to have a look at the output from the > > cpu_frequency and pstate_sample tracepoints around when the issue > > triggers. The pstate_sample one would be more interesting. > > > > But for both we need a reproducer anyway. > I do not have a reliable reproducer. The condition has always > happened when > running a high-compute job such as a 'make -j8' on the kernel, or > building the > RPM for openSUSE's implementation of VirtualBox. The latter is what > I'm using > for most of my testing. > > > > > It also would be good to rule out the thermal throttling (as per > > the > > Srinivas' comments). > > > > For now, please tell me what's in > > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq > 80 Your effective freq is lower than 800MHz. One of the possible reason is thermal throttling. What distro you are using? Thanks, Srinivas
Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers
> "Lee" == Lee Duncan writes: Lee, Lee> Chris Leech and I are taking over as open-iscsi maintainers. Do you want me to queue the MAINTAINER update? Lee> * Removed git repository, since code in tree Is it your plan to go through the SCSI tree? -- Martin K. Petersen Oracle Linux Engineering
linux-next: build failure after merge of the rdma tree
Hi Doug,
After merging the rdma tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function
'kiblnd_hdev_setup_mrs':
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:7: error: implicit
declaration of function 'ib_get_dma_mr' [-Werror=implicit-function-declaration]
mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
^
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:5: warning: assignment
makes pointer from integer without a cast [-Wint-conversion]
mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
^
Caused by commit
5ef990f06bd7 ("IB/core: remove ib_get_dma_mr")
I have used the rdma tree from next-20160923 for today.
--
Cheers,
Stephen Rothwell
RE: UFS API in the kernel
Hi. If you want to declare some things for user interface, is it be better to put those thing include/uapi/linux/ than include/linux? Agreed with Mr. Pinto's opinion with respect to implementing additional ioctls. Regards. > -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Shaun Tancheff > Sent: Tuesday, September 27, 2016 4:23 AM > To: Joao Pinto > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: UFS API in the kernel > > On Thu, Sep 22, 2016 at 10:21 AM, Joao Pinto > wrote: > > Hi! > > > > I am designing an application that has the goal to be an utility for > > Unipro and UFS testing purposes. This application is going to run on > > top of a recent Linux Kernel containing the new UFS stack (including the > new DWC drivers). > > > > I am considering doing the following: > > a) Create a new config item called CONFIG_UFS_CHARDEV which is going > > to create a char device responsible to make some IOCTL available for > > user-space applications > > b) Create a linux/ufs.h header file that contains data structures > > declarations that will be needed in user-space applications > > I am not very familiar with UFS devices, that said you should have an sgX > chardev being created already so you can handle SG_IO requests. > There also appear to be some sysfs entries being created. > > So between sg and sysfs you should be able to handle any user-space out of > band requests without resorting to making a new chardev. > > Adding more sysfs entries, if you need them, should be fine. > > You may find it easier to expand on the existing interfaces than to get > consensus on a new driver and ioctls. > > Hope this helps, > Shaun > > > Could you please advise me about what the correct approach should be > > to make it as standard as possible and usable in the future? > > > > Thank you very much for your help! > > > > regards, > > Joao > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-scsi" > > in the body of a message to majord...@vger.kernel.org More majordomo > > info at > > https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_ma > > jordomo-2Dinfo.html&d=DQICaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=Wg5NqlNlVTT7Ug > > l8V50qIHLe856QW0qfG3WVYGOrWzA&m=vJFB6pCywWtdvkgHz9Vc0jQz0xzeyZlr-7eCWY > > u88nM&s=yiQLPFpqmMrbqLZz1Jb3aNqOje2dRMLJHEzUDobwcXc&e= > > > > -- > Shaun Tancheff > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html
[PATCH] bus: qcom-ebi2: make it explicitly non-modular
The Kconfig currently controlling compilation of this code is:
drivers/bus/Kconfig:config QCOM_EBI2
drivers/bus/Kconfig:bool "Qualcomm External Bus Interface 2 (EBI2)"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
We don't replace module.h with init.h since the file already has that.
Cc: Linus Walleij
Signed-off-by: Paul Gortmaker
---
drivers/bus/qcom-ebi2.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/bus/qcom-ebi2.c b/drivers/bus/qcom-ebi2.c
index a6444244c411..d34a6ef02827 100644
--- a/drivers/bus/qcom-ebi2.c
+++ b/drivers/bus/qcom-ebi2.c
@@ -14,7 +14,6 @@
* hardware.
*/
-#include
#include
#include
#include
@@ -402,7 +401,4 @@ static struct platform_driver qcom_ebi2_driver = {
.of_match_table = qcom_ebi2_of_match,
},
};
-module_platform_driver(qcom_ebi2_driver);
-MODULE_AUTHOR("Linus Walleij ");
-MODULE_DESCRIPTION("Qualcomm EBI2 driver");
-MODULE_LICENSE("GPL");
+builtin_platform_driver(qcom_ebi2_driver);
--
2.10.0
[PATCH] padata: remove recently added module usage from bool code
In commit 30e92153b4e6 ("padata: Convert to hotplug state machine")
this file started using module.h and got module_init and module_exit
added to it.
However the Kconfig for it is:
init/Kconfig:config PADATA
init/Kconfig: depends on SMP
init/Kconfig: bool
...and so it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
Cc: Steffen Klassert
Cc: Thomas Gleixner
Cc: Sebastian Andrzej Siewior
Cc: linux-cry...@vger.kernel.org
Signed-off-by: Paul Gortmaker
---
kernel/padata.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index 7848f0566403..355807e52b1e 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -30,7 +30,7 @@
#include
#include
#include
-#include
+#include
#define MAX_OBJ_NUM 1000
@@ -1043,11 +1043,6 @@ static __init int padata_driver_init(void)
hp_online = ret;
return 0;
}
-module_init(padata_driver_init);
+device_initcall(padata_driver_init);
-static __exit void padata_driver_exit(void)
-{
- cpuhp_remove_multi_state(hp_online);
-}
-module_exit(padata_driver_exit);
#endif
--
2.10.0
Re: [PATCH 1/3] megaraid_sas: mark symbols static where possible
> "Baoyou" == Baoyou Xie writes: Baoyou> We get a few warnings when building kernel with W=1: Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:94:5: warning: no Baoyou> previous prototype for 'mega_mod64' [-Wmissing-prototypes] Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:112:5: warning: no Baoyou> previous prototype for 'mega_div64_32' [-Wmissing-prototypes] Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:177:6: warning: no Baoyou> previous prototype for 'MR_PopulateDrvRaidMap' Baoyou> [-Wmissing-prototypes] Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:315:5: warning: no Baoyou> previous prototype for 'MR_GetSpanBlock' [-Wmissing-prototypes] Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:451:5: warning: no Baoyou> previous prototype for 'mr_spanset_get_span_block' Baoyou> [-Wmissing-prototypes] Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:692:4: warning: no Baoyou> previous prototype for 'get_arm' [-Wmissing-prototypes] Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:815:4: warning: no Baoyou> previous prototype for 'MR_GetPhyParams' [-Wmissing-prototypes] Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:1293:4: warning: no Baoyou> previous prototype for 'megasas_get_best_arm_pd' Baoyou> [-Wmissing-prototypes] Baoyou> drivers/scsi/megaraid/megaraid_sas_fusion.c:106:1: warning: no Baoyou> previous prototype for 'megasas_enable_intr_fusion' Baoyou> [-Wmissing-prototypes] Baoyou> drivers/scsi/megaraid/megaraid_sas_fusion.c:127:1: warning: no Baoyou> previous prototype for 'megasas_disable_intr_fusion' Baoyou> [-Wmissing-prototypes] Does not apply. Please make sure your patches are against my for-next branch. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers
On Mon, Sep 26, 2016 at 03:25:30PM -0700, Lee Duncan wrote: > Chris Leech and I are taking over as open-iscsi maintainers. Can we get rid of the horribly unusable googlegroups list and just move everything to linux-scsi while we're at it?
Re: [PATCH] [SCSI] mvsas: mark symbols static where possible
> "Baoyou" == Baoyou Xie writes: Baoyou> We get a few warnings when building kernel with W=1: Baoyou> drivers/scsi/mvsas/mv_sas.c:77:18: warning: no previous Baoyou> prototype for 'mvs_find_dev_mvi' [-Wmissing-prototypes] Baoyou> drivers/scsi/mvsas/mv_sas.c:105:5: warning: no previous Baoyou> prototype for 'mvs_find_dev_phyno' [-Wmissing-prototypes] Baoyou> drivers/scsi/mvsas/mv_sas.c:1161:20: warning: no previous Baoyou> prototype for 'mvs_alloc_dev' [-Wmissing-prototypes] Baoyou> drivers/scsi/mvsas/mv_sas.c:1178:6: warning: no previous Baoyou> prototype for 'mvs_free_dev' [-Wmissing-prototypes] Baoyou> drivers/scsi/mvsas/mv_sas.c:1188:5: warning: no previous Baoyou> prototype for 'mvs_dev_found_notify' [-Wmissing-prototypes] Baoyou> drivers/scsi/mvsas/mv_sas.c:1244:6: warning: no previous Baoyou> prototype for 'mvs_dev_gone_notify' [-Wmissing-prototypes] Baoyou> drivers/scsi/mvsas/mv_sas.c:1614:6: warning: no previous Baoyou> prototype for 'mvs_set_sense' [-Wmissing-prototypes] Baoyou> drivers/scsi/mvsas/mv_sas.c:1653:6: warning: no previous Baoyou> prototype for 'mvs_fill_ssp_resp_iu' [-Wmissing-prototypes] Baoyou> drivers/scsi/mvsas/mv_64xx.c:139:6: warning: no previous Baoyou> prototype for 'mvs_64xx_clear_srs_irq' [-Wmissing-prototypes] Baoyou> drivers/scsi/mvsas/mv_64xx.c:566:6: warning: no previous Baoyou> prototype for 'mvs_64xx_make_prd' [-Wmissing-prototypes] Applied to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] pm8001: mark symbols static where possible
> "Baoyou" == Baoyou Xie writes: Baoyou> We get 2 warnings when building kernel with W=1: Baoyou> drivers/scsi/pm8001/pm8001_sas.c:530:23: warning: no previous Baoyou> prototype for 'pm8001_alloc_dev' [-Wmissing-prototypes] Baoyou> drivers/scsi/pm8001/pm8001_hwi.c:4495:5: warning: no previous Baoyou> prototype for 'pm8001_chip_phy_stop_req' [-Wmissing-prototypes] Applied to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 1/2] f2fs: fix to commit bio cache after flushing node pages
Hi Jaegeuk,
On 2016/9/27 2:33, Jaegeuk Kim wrote:
> Hi Chao,
>
> On Tue, Sep 27, 2016 at 12:09:52AM +0800, Chao Yu wrote:
>> From: Chao Yu
>>
>> In sync_node_pages, we won't check and commit last merged pages in private
>> bio cache of f2fs, as these pages were taged as writeback, someone who is
>> waiting for writebacking of the page will be blocked until the cache was
>> committed by someone else.
>>
>> We need to commit node type bio cache to avoid potential deadlock or long
>> delay of waiting writeback.
>>
>> Signed-off-by: Chao Yu
>> ---
>> fs/f2fs/node.c | 11 +--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index 9faddcd..f73f774 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -1416,6 +1416,7 @@ int sync_node_pages(struct f2fs_sb_info *sbi, struct
>> writeback_control *wbc)
>> struct pagevec pvec;
>> int step = 0;
>> int nwritten = 0;
>> +int ret = 0;
>>
>> pagevec_init(&pvec, 0);
>>
>> @@ -1436,7 +1437,8 @@ next_step:
>>
>> if (unlikely(f2fs_cp_error(sbi))) {
>> pagevec_release(&pvec);
>> -return -EIO;
>> +ret = -EIO;
>> +goto out;
>> }
>>
>> /*
>> @@ -1487,6 +1489,8 @@ continue_unlock:
>>
>> if (NODE_MAPPING(sbi)->a_ops->writepage(page, wbc))
>> unlock_page(page);
>> +else
>> +nwritten++;
>>
>> if (--wbc->nr_to_write == 0)
>> break;
>> @@ -1504,7 +1508,10 @@ continue_unlock:
>> step++;
>> goto next_step;
>> }
>> -return nwritten;
>> +out:
>> +if (nwritten)
>> +f2fs_submit_merged_bio(sbi, NODE, WRITE);
>
> IIRC, we don't need to flush this, since f2fs_submit_merged_bio_cond() would
> handle this in f2fs_wait_on_page_writeback().
Yes, it covers all the cases in f2fs private codes, but there are still some
codes in mm or fs directory, and they didn't use f2fs_wait_on_page_writeback
when waiting page writeback. Such as do_writepages && filemap_fdatawait in
__writeback_single_inode...
Thanks,
>
> Thanks,
>
>> +return ret;
>> }
>>
>> int wait_on_node_pages_writeback(struct f2fs_sb_info *sbi, nid_t ino)
>> --
>> 2.7.2
>
> .
>
Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression
Christoph Hellwig writes: > Hi Ying, > >> Any update to this regression? > > Not really. We've optimized everything we could in XFS without > dropping the architecture that we really want to move to. Now we're > waiting for some MM behavior to be fixed that this unconvered. But > in the end will probabkly stuck with a slight regression in this > artificial workload. I see. Thanks for update. Please keep me posted. Best Regards, Huang, Ying
Re: [LKP] [lkp] [f2fs] ec795418c4: fsmark.files_per_sec -36.3% regression
Jaegeuk Kim writes: > On Mon, Sep 26, 2016 at 02:26:06PM +0800, Huang, Ying wrote: >> Hi, Jaegeuk, >> >> "Huang, Ying" writes: >> >> > Jaegeuk Kim writes: >> > >> >> Hello, >> >> >> >> On Sat, Aug 27, 2016 at 10:13:34AM +0800, Fengguang Wu wrote: >> >>> Hi Jaegeuk, >> >>> >> >>> > > >> > - [lkp] [f2fs] b93f771286: aim7.jobs-per-min -81.2% regression >> >>> > > >> > >> >>> > > >> > The disk is 4 12G ram disk, and setup RAID0 on them via mdadm. >> >>> > > >> > The >> >>> > > >> > steps for aim7 is, >> >>> > > >> > >> >>> > > >> > cat > workfile <> >>> > > >> > FILESIZE: 1M >> >>> > > >> > POOLSIZE: 10M >> >>> > > >> > 10 sync_disk_rw >> >>> > > >> > EOF >> >>> > > >> > >> >>> > > >> > ( >> >>> > > >> > echo $HOSTNAME >> >>> > > >> > echo sync_disk_rw >> >>> > > >> > >> >>> > > >> > echo 1 >> >>> > > >> > echo 600 >> >>> > > >> > echo 2 >> >>> > > >> > echo 600 >> >>> > > >> > echo 1 >> >>> > > >> > ) | ./multitask -t & >> >>> > > >> >> >>> > > >> Any update on these 2 regressions? Is the information is enough >> >>> > > >> for you >> >>> > > >> to reproduce? >> >>> > > > >> >>> > > > Sorry, I've had no time to dig this due to business travel now. >> >>> > > > I'll check that when back to US. >> >>> > > >> >>> > > Any update? >> >>> > >> >>> > Sorry, how can I get multitask binary? >> >>> >> >>> It's part of aim7, which can be downloaded here: >> >>> >> >>> http://nchc.dl.sourceforge.net/project/aimbench/aim-suite7/Initial%20release/s7110.tar.Z >> >> >> >> Thank you for the codes. >> >> >> >> I've run this workload on the latest f2fs and compared performance having >> >> without the reported patch. (1TB nvme SSD, 16 cores, 16GB DRAM) >> >> Interestingly, I could find slight performance improvement rather than >> >> regression. :( >> >> Not sure how to reproduce this. >> > >> > I think the difference lies on disk used. The ramdisk is used in the >> > original test, but it appears that your memory is too small to setup the >> > RAM disk for test. So it may be impossible for you to reproduce the >> > test unless you can find more memory :) >> > >> > But we can help you to root cause the issue. What additional data do >> > you want? perf-profile data before and after the patch? >> >> Any update to this regression? > > Sorry, no. But meanwhile, I've purchased more DRAMs. :) > Now I'm with 128GB DRAM. I can configure 64GB as pmem. > Is it worth to try the test again? I think you are the decision maker for this. You can judge whether the test is reasonable. And we can adjust our test accordingly. BTW: For this test, we use brd ram disk and raid to test. Best Regards, Huang, Ying
Re: Regression in 4.8 - CPU speed set very low
On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote: On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger wrote: On 09/26/2016 05:16 PM, Rafael J. Wysocki wrote: On Tue, Sep 27, 2016 at 12:09 AM, Larry Finger wrote: Maybe it's better to try diagnose the problem instead of spending more time on bisection. In my original post, I asked for such help, but nothing until today. I had no idea what to check, but now I have a better idea. I'd like to know whether or not 4.7 was definitely good, though. I never saw this problem with 4.7, but given the difficulty in triggering the problem, my tests may not have been definitive. If it is one of them, it may be a while before I dare call this one "good". In one respect, that is good as I will be traveling tomorrow and Wednesday. What does "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver" say? intel_pstate You probably don't need to worry about all of the cpufreq changes in 4.8-rc, then. Only a few of them affect intel_pstate and I don't see how any of them may lead to the observed symptoms. First off, if you have a reproducer, please run it on 4.7 and see if you can trigger the issue in there. I'm running 4.8-rc7 at the moment hoping to trigger the problem and get the data requested by Srinivas. Once I get that, I will try 4.7 again. Second, it would be good to have a look at the output from the cpu_frequency and pstate_sample tracepoints around when the issue triggers. The pstate_sample one would be more interesting. But for both we need a reproducer anyway. I do not have a reliable reproducer. The condition has always happened when running a high-compute job such as a 'make -j8' on the kernel, or building the RPM for openSUSE's implementation of VirtualBox. The latter is what I'm using for most of my testing. It also would be good to rule out the thermal throttling (as per the Srinivas' comments). For now, please tell me what's in /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq 80 Larry
[linux-next] do_task_stat: BUG: unable to handle kernel paging request at ffffc9000041bfd8
Hello. I'm hitting below bug when a process $pid terminates while somebody else is reading /proc/$pid/stat . According to https://lkml.org/lkml/2016/8/21/10 , it was already fixed. But it seems to me that this bug is still in linux-next-20160923. Is this a different bug? [ 191.915694] BUG: unable to handle kernel paging request at c941bfd8 [ 191.917803] IP: [] do_task_stat+0x951/0xb90 [ 191.919477] PGD 7e051067 PUD 7e052067 PMD 36ae6067 PTE 0 [ 191.921029] Oops: [#1] PREEMPT SMP [ 191.922167] Modules linked in: ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables coretemp pcspkr sg i2c_piix4 sd_mod ata_generic pata_acpi serio_raw ahci libahci e1000 mptspi scsi_transport_spi mptscsih mptbase ata_piix vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm i2c_core libata [ 191.931246] CPU: 0 PID: 10894 Comm: oom_preempt2 Not tainted 4.8.0-rc7-next-20160923+ #472 [ 191.933683] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 [ 191.936572] task: 88007698ce80 task.stack: c90004fe4000 [ 191.938425] RIP: 0010:[] [] do_task_stat+0x951/0xb90 [ 191.940678] RSP: 0018:c90004fe7c40 EFLAGS: 00010202 [ 191.942273] RAX: c941c000 RBX: 8800790060c0 RCX: [ 191.944404] RDX: 0001 RSI: RDI: 88007913ef00 [ 191.946369] RBP: c90004fe7d60 R08: 0001 R09: [ 191.948502] R10: 0001 R11: R12: 88007913ef00 [ 191.950577] R13: 8800773913c0 R14: 0001 R15: 81a28da0 [ 191.952923] FS: 7f56f12bb740() GS:88007ea0() knlGS: [ 191.955128] CS: 0010 DS: ES: CR0: 80050033 [ 191.957154] CR2: c941bfd8 CR3: 79d18000 CR4: 001406f0 [ 191.959227] Stack: [ 191.960242] 28e0 0401 00438000 [ 191.962471] 8800794ee500 000a 28e0 [ 191.964715] 28e0 [ 191.967027] Call Trace: [ 191.968340] [] proc_tgid_stat+0xf/0x20 [ 191.970087] [] proc_single_show+0x4b/0x80 [ 191.971900] [] seq_read+0x100/0x380 [ 191.973578] [] __vfs_read+0x32/0x130 [ 191.975280] [] ? security_file_permission+0x9e/0xc0 [ 191.977290] [] vfs_read+0x89/0x130 [ 191.978981] [] SyS_pread64+0x82/0xb0 [ 191.980761] [] do_syscall_64+0x5c/0x170 [ 191.982682] [] entry_SYSCALL64_slow_path+0x25/0x25 [ 191.984657] Code: ff e8 84 11 ea ff 48 8b 85 50 ff ff ff 49 03 87 b8 01 00 00 48 89 85 50 ff ff ff e9 e8 f8 ff ff 49 8b 84 24 58 08 00 00 4c 89 e7 <48> 8b 40 d8 48 89 85 48 ff ff ff e8 af 69 e3 ff 48 89 85 40 ff [ 191.991974] RIP [] do_task_stat+0x951/0xb90 [ 191.993931] RSP [ 191.995383] CR2: c941bfd8 [ 191.997003] ---[ end trace 8bdf0d4222ebcddb ]--- I can't find a patch titled "[DEBUG] forcibly free stacks immediately" in linux-next. Which patch should I try reverting?
Re: [PATCH] crypto: sha1-powerpc: little-endian support
Fri, Sep 23, 2016 at 04:31:56PM -0300, Marcelo Cerri wrote: > The driver does not handle endianness properly when loading the input > data. Indeed. I tested in both endianesses and it's working fine. Thanks! Herbert, can we go ahead with this fix? > > Signed-off-by: Marcelo Cerri > --- > arch/powerpc/crypto/sha1-powerpc-asm.S | 13 +++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/crypto/sha1-powerpc-asm.S > b/arch/powerpc/crypto/sha1-powerpc-asm.S > index 125e165..82ddc9b 100644 > --- a/arch/powerpc/crypto/sha1-powerpc-asm.S > +++ b/arch/powerpc/crypto/sha1-powerpc-asm.S > @@ -7,6 +7,15 @@ > #include > #include > > +#ifdef __BIG_ENDIAN__ > +#define LWZ(rt, d, ra) \ > + lwz rt,d(ra) > +#else > +#define LWZ(rt, d, ra) \ > + li rt,d; \ > + lwbrx rt,rt,ra > +#endif > + > /* > * We roll the registers for T, A, B, C, D, E around on each > * iteration; T on iteration t is A on iteration t+1, and so on. > @@ -23,7 +32,7 @@ > #define W(t) (((t)%16)+16) > > #define LOADW(t) \ > - lwz W(t),(t)*4(r4) > + LWZ(W(t),(t)*4,r4) > > #define STEPD0_LOAD(t) \ > andcr0,RD(t),RB(t); \ > @@ -33,7 +42,7 @@ > add r0,RE(t),r15; \ > add RT(t),RT(t),r6; \ > add r14,r0,W(t);\ > - lwz W((t)+4),((t)+4)*4(r4); \ > + LWZ(W((t)+4),((t)+4)*4,r4); \ > rotlwi RB(t),RB(t),30; \ > add RT(t),RT(t),r14 > > -- > 2.7.4 > -- Paulo Flabiano Smorigo IBM Linux Technology Center
Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver
On Mon, Sep 26, 2016 at 07:55:13PM -0400, Thomas Gleixner wrote: > On Mon, 26 Sep 2016, Rich Felker wrote: > > On Mon, Sep 26, 2016 at 11:27:14PM +0200, Daniel Lezcano wrote: > > Based on use of ftrace, I was able to see situations where a second > > timer hardirq happened immediately after one occurred, before the > > timer softirq could run. My theory is that this is causing some kind > > of feedback loop where new timer expirations keep getting scheduled > > with a very short interval such that the softirq never gets to run > > (until other interrupt activity disrups the feedback loop). I tried > > reverting 4e85876a9d2a977b4a07389da8c07edf76d10825 which seemed > > relevant and it didn't help, but on further review (right now) there > > seem to be a few related commits just before it that might be > > responsible for the regression. I'll see if I can dig up anything else > > useful. > > Interesting theory, but lets look at the data from the other thread: > > -0 [001] d.h. 2646.702790: irq_handler_entry: irq=72 > name=jcore_pit > -0 [001] d.h. 2646.703398: softirq_raise: vec=1 > [action=TIMER] > -0 [001] d.h. 2646.703607: softirq_raise: vec=9 > [action=RCU] > -0 [001] d.h. 2646.703884: softirq_raise: vec=7 > [action=SCHED] > -0 [001] d.h. 2646.704191: irq_handler_exit: irq=72 > ret=handled > > So it takes 1.4ms to finish the timer irq handler > > -0 [001] d.H. 2646.704509: irq_handler_entry: irq=72 > name=jcore_pit > -0 [001] d.H. 2646.704990: softirq_raise: vec=1 > [action=TIMER] > -0 [001] d.H. 2646.705182: softirq_raise: vec=9 > [action=RCU] > -0 [001] d.H. 2646.705465: softirq_raise: vec=7 > [action=SCHED] > -0 [001] d.H. 2646.705761: irq_handler_exit: irq=72 > ret=handled > > And 1.2ms in this case > > > -0 [001] d.H. 2646.706071: irq_handler_entry: irq=72 > name=jcore_pit > -0 [001] d.H. 2646.706328: irq_handler_exit: irq=72 > ret=handled > > So this one is actually short enough that the soft interrupt can excute and > obviously no new timer is scheduled close enough. > > -0 [001] ..s. 2646.706530: softirq_entry: vec=1 > [action=TIMER] > > Now the obvious question arises: Why is that handler taking that long? And I'm not sure. Even at our clock rate of 50 MHz, 1.2ms is 6 cycles. It's possible much of that overhead is coming from ftrace. I can play around again with just logging the minimum intervals that are programmed, and not using ftrace. > sure the next event being programmed shortely after the other has to do > with various factors (HZ setting, High-resolution timers enabled?). W/o > having the corresponding hrtimer tracepoints available (start and expire) > it's hard to tell what's going on. I do have hrtimers enabled. If it would be helpful I could try again with traces for them enabled too. > But I can tell for sure that there is no feedback loop and its not > disrupted by some other interrupt. FYI no rcu_sched messages or noticable stalls were observed with tracing active. The cpu load from tracing is so high that I would not expect to see the same behavior. I probably failed to make that clear before; sorry. > The above trace is merily seing the PIT > irq and nothing else. It is showing another one happening before the softirq side of the first could run, right? Of course this is probably due to overall ftrace slowness. CONFIG_DYNAMIC_FTRACE does not work on big-endian sh (the objdump needed at build time is hard-coded to assume sh is little-endian and I haven't yet worked out what all needs to be fixed) so I suspect that may be the cause of ftrace being so slow when it's turned on. Oddly, the min_delta cutoff needed to prevent the stalls was on the same order of magnitude as these numbers (2.5ms almost entirely made them go away; 5ms completely). > Can you please provide a trace with hrtimer tracepoints enabled and tell us > the settings of CONFIG_HZ and whether high resolution timers are enabled or > not. Yes. I think these are the relevant config items: CONFIG_HZ=100 CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y Let me know if I missed any. I'll try getting a trace and follow up again. > That workaround of setting min_delta to some absurd big number looks fishy > at best. I agree. I'd like to find the right fix, but usability badly suffers without either a proper fix or a workaround. Rich
Re: [PATCH v4] add u64 number parser
On Sun, 2016-09-25 at 09:14 -0700, James Smart wrote: > add u64 number parser > > Reverted back to version 2 of the patch. This adds the interface > using existing logic. Comments from the prior reviewers to move to > kasprintf were rejected by Linus. > > Signed-off-by: James Smart Acked-by: Jay Freyensee
Re: [PATCH] lpfc: mark symbols static where possible
> "Baoyou" == Baoyou Xie writes: Baoyou> In fact, these functions are only used in the file in which they Baoyou> are declared and don't need a declaration, but can be made Baoyou> static. so this patch marks these functions with 'static'. Applied to 4.9/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
[PATCH] perf: sched-pipe add support for packet I/O mode
Add support to run sched-pipe benchmark test on pipe with packet I/O mode.
Signed-off-by: Shuah Khan
---
tools/perf/bench/sched-pipe.c | 20
1 file changed, 20 insertions(+)
diff --git a/tools/perf/bench/sched-pipe.c b/tools/perf/bench/sched-pipe.c
index 1dc2d13..c6e1b7a 100644
--- a/tools/perf/bench/sched-pipe.c
+++ b/tools/perf/bench/sched-pipe.c
@@ -41,9 +41,16 @@ static int loops = LOOPS_DEFAULT;
/* Use processes by default: */
static boolthreaded;
+/* Use non-packet (normal) I/O mode by default.
+ * In packet mode, each write is a separate packet.
+ */
+static boolpacket_mode;
+
static const struct option options[] = {
OPT_INTEGER('l', "loop",&loops, "Specify number of
loops"),
OPT_BOOLEAN('T', "threaded",&threaded, "Specify
threads/process based task setup"),
+ OPT_BOOLEAN('P', "packet mode", &packet_mode,
+ "Specify packet I/O mode - "),
OPT_END()
};
@@ -83,6 +90,7 @@ int bench_sched_pipe(int argc, const char **argv, const char
*prefix __maybe_unu
unsigned long long result_usec = 0;
int nr_threads = 2;
int t;
+ int flags = 0;
/*
* why does "ret" exist?
@@ -94,6 +102,18 @@ int bench_sched_pipe(int argc, const char **argv, const
char *prefix __maybe_unu
argc = parse_options(argc, argv, options, bench_sched_pipe_usage, 0);
+ if (packet_mode) {
+ /* BUG_ON doesn't make sense exit if pipe2() fails */
+ flags = O_DIRECT;
+ ret = pipe2(pipe_1, flags);
+ if (ret)
+ exit(1);
+ ret = pipe2(pipe_2, flags);
+ if (ret)
+ exit(1);
+ printf("Running sched-pipe in packet I/O mode\n\n");
+ }
+
BUG_ON(pipe(pipe_1));
BUG_ON(pipe(pipe_2));
--
2.7.4
[PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO
If a GPIO gets freed after selecting a new pinctrl configuration the driver should not change pinctrl anymore. Otherwise this will likely lead to a unusable pin configuration for the newly selected pinctrl. Signed-off-by: Stefan Agner --- This turned out to be problematic when using the I2C GPIO bus recovery functionality. After muxing back to I2C, the GPIO is being freed, which cased I2C to stop working completely. -- Stefan drivers/pinctrl/freescale/pinctrl-imx.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c b/drivers/pinctrl/freescale/pinctrl-imx.c index 4761320..61cfa95 100644 --- a/drivers/pinctrl/freescale/pinctrl-imx.c +++ b/drivers/pinctrl/freescale/pinctrl-imx.c @@ -361,8 +361,13 @@ static void imx_pmx_gpio_disable_free(struct pinctrl_dev *pctldev, if (pin_reg->mux_reg == -1) return; - /* Clear IBE/OBE/PUE to disable the pin (Hi-Z) */ reg = readl(ipctl->base + pin_reg->mux_reg); + + /* Only change pad configuration if pad is still a GPIO */ + if (reg & (0x7 << 20)) + return; + + /* Clear IBE/OBE/PUE to disable the pin (Hi-Z) */ reg &= ~0x7; writel(reg, ipctl->base + pin_reg->mux_reg); } -- 2.10.0
Re: Regression in 4.8 - CPU speed set very low
On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger wrote: > On 09/26/2016 05:16 PM, Rafael J. Wysocki wrote: >> >> On Tue, Sep 27, 2016 at 12:09 AM, Larry Finger > > wrote: >> >> >> Maybe it's better to try diagnose the problem instead of spending more >> time on bisection. > > > In my original post, I asked for such help, but nothing until today. I had > no idea what to check, but now I have a better idea. > >> I'd like to know whether or not 4.7 was definitely good, though. > > > I never saw this problem with 4.7, but given the difficulty in triggering > the problem, my tests may not have been definitive. >> >> >>> If it is one of them, it may be a while before I dare call this one >>> "good". >>> In one respect, that is good as I will be traveling tomorrow and >>> Wednesday. >> >> >> What does "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver" say? > > > intel_pstate You probably don't need to worry about all of the cpufreq changes in 4.8-rc, then. Only a few of them affect intel_pstate and I don't see how any of them may lead to the observed symptoms. First off, if you have a reproducer, please run it on 4.7 and see if you can trigger the issue in there. Second, it would be good to have a look at the output from the cpu_frequency and pstate_sample tracepoints around when the issue triggers. The pstate_sample one would be more interesting. But for both we need a reproducer anyway. It also would be good to rule out the thermal throttling (as per the Srinivas' comments). For now, please tell me what's in /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq Thanks, Rafael
[PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready
Some SoC might load the GPIO driver after the I2C driver and
using the I2C bus recovery mechanism via GPIOs. In this case
it is crucial to defer probing if the GPIO request functions
do so, otherwise the I2C driver gets loaded without recovery
mechanisms enabled.
Signed-off-by: Stefan Agner
---
This is an actual issue on NXP Vybrid devices on which the GPIO
driver gets loaded rather later.
--
Stefan
drivers/i2c/busses/i2c-imx.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 592a8f2..47fc1f1 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1009,10 +1009,13 @@ static int i2c_imx_init_recovery_info(struct
imx_i2c_struct *i2c_imx,
rinfo->sda_gpio = of_get_named_gpio(pdev->dev.of_node, "sda-gpios", 0);
rinfo->scl_gpio = of_get_named_gpio(pdev->dev.of_node, "scl-gpios", 0);
- if (!gpio_is_valid(rinfo->sda_gpio) ||
- !gpio_is_valid(rinfo->scl_gpio) ||
- IS_ERR(i2c_imx->pinctrl_pins_default) ||
- IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
+ if (rinfo->sda_gpio == -EPROBE_DEFER ||
+ rinfo->scl_gpio == -EPROBE_DEFER) {
+ return -EPROBE_DEFER;
+ } else if (!gpio_is_valid(rinfo->sda_gpio) ||
+ !gpio_is_valid(rinfo->scl_gpio) ||
+ IS_ERR(i2c_imx->pinctrl_pins_default) ||
+ IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
dev_dbg(&pdev->dev, "recovery information incomplete\n");
return 0;
}
--
2.10.0
Re: [PATCH v3 5/5] mm: enable CONFIG_MOVABLE_NODE on powerpc
On Tue, Sep 27, 2016 at 07:15:41AM +1000, Benjamin Herrenschmidt wrote: What is that business with a command line argument ? Do that mean that we'll need some magic command line argument to properly handle LPC memory on CAPI devices or GPUs ? If yes that's bad ... kernel arguments should be a last resort. Well, movable_node is just a boolean, meaning "allow nodes which contain only movable memory". It's _not_ like "movable_node=10,13-15,17", if that's what you were thinking. We should have all the information we need from the device-tree. Note also that we shouldn't need to create those nodes at boot time, we need to add the ability to create the whole thing at runtime, we may know that there's an NPU with an LPC window in the system but we won't know if it's used until it is and for CAPI we just simply don't know until some PCI device gets turned into CAPI mode and starts claiming LPC memory... Yes, this is what is planned for, if I'm understanding you correctly. In the dt, the PCI device node has a phandle pointing to the memory node. The memory node describes the window into which we can hotplug at runtime. -- Reza Arbab
Re: [PATCH] net: tg3: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes
Date: Sun, 25 Sep 2016 23:31:24 +0200
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes
Applied, thanks.
Re: [PATCH v3 4/5] powerpc/mm: restore top-down allocation when using movable_node
On Tue, Sep 27, 2016 at 07:12:31AM +1000, Benjamin Herrenschmidt wrote: In any case, if the memory hasn't been hotplug, this shouldn't be necessary as we shouldn't be considering it for allocation. Right. To be clear, the background info I put in the commit log refers to x86, where the SRAT can describe movable nodes which exist at boot. They're trying to avoid allocations from those nodes before they've been identified. On power, movable nodes can only exist via hotplug, so that scenario can't happen. We can immediately go back to top-down allocation. That is the missing call being added in the patch. -- Reza Arbab
Re: [PATCH] elevator: remove second argument in elevator_init()
On Thu, Mar 31, 2016 at 1:34 AM, Jens Axboe wrote: > On 03/30/2016 05:31 PM, Alexey Klimov wrote: >> >> Hi all, >> >> On Wed, Jan 27, 2016 at 9:01 PM, Jeff Moyer wrote: >>> >>> Alexey Klimov writes: >>> Last user of elevator_init() with non-NULL name as second argument that supposed to be s390 dasd driver has gone few releases ago. Drivers rely on elevator_change(), elevator_switch() and friends for example. Right now elevator_init() is always called as elevator_init(q, NULL). Patch removes passing of second name argument and its usage. While we're at it fix following if-check after removed lines. We know that elevator_type e is initialized by NULL and need to check only chosen_elevator. Signed-off-by: Alexey Klimov >>> >>> >>> Reviewed-by: Jeff Moyer >> >> >> >> what is the status of this patch? Is it that wrong and are there some >> concerns or do I need to resend it? > > > It looks fine, I'll pick it up for 4.7. > > -- > Jens Axboe So, I guess this one was lost: I can't find it in the tree. Looks like the easiest way will be to rebase (and check that it's still fine) and resend. Right? Best regards, Alexey.
linux-next: manual merge of the vfs-jk tree with the fuse tree
Hi Jan,
Today's linux-next merge of the vfs-jk tree got a conflict in:
fs/fuse/dir.c
between commits:
3b3fb74935ce ("fuse: invalidate dir dentry after chmod")
5f69e628df75 ("fuse: fix killing s[ug]id in setattr")
from the fuse tree and commit:
62490330769c ("fuse: Propagate dentry down to inode_change_ok()")
from the vfs-jk tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/fuse/dir.c
index f7c84ab835ca,b23502174682..
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@@ -1618,10 -1606,10 +1619,10 @@@ int fuse_do_setattr(struct dentry *dent
int err;
bool trust_local_cmtime = is_wb && S_ISREG(inode->i_mode);
- if (!(fc->flags & FUSE_DEFAULT_PERMISSIONS))
+ if (!fc->default_permissions)
attr->ia_valid |= ATTR_FORCE;
- err = inode_change_ok(inode, attr);
+ err = setattr_prepare(dentry, attr);
if (err)
return err;
@@@ -1715,61 -1703,101 +1716,61 @@@ error
static int fuse_setattr(struct dentry *entry, struct iattr *attr)
{
struct inode *inode = d_inode(entry);
-
- if (!fuse_allow_current_process(get_fuse_conn(inode)))
- return -EACCES;
-
- if (attr->ia_valid & ATTR_FILE)
- return fuse_do_setattr(entry, attr, attr->ia_file);
- else
- return fuse_do_setattr(entry, attr, NULL);
-}
-
-static int fuse_getattr(struct vfsmount *mnt, struct dentry *entry,
- struct kstat *stat)
-{
- struct inode *inode = d_inode(entry);
struct fuse_conn *fc = get_fuse_conn(inode);
+ struct file *file = (attr->ia_valid & ATTR_FILE) ? attr->ia_file : NULL;
+ int ret;
- if (!fuse_allow_current_process(fc))
+ if (!fuse_allow_current_process(get_fuse_conn(inode)))
return -EACCES;
- return fuse_update_attributes(inode, stat, NULL, NULL);
-}
-
-static int fuse_setxattr(struct dentry *unused, struct inode *inode,
- const char *name, const void *value,
- size_t size, int flags)
-{
- struct fuse_conn *fc = get_fuse_conn(inode);
- FUSE_ARGS(args);
- struct fuse_setxattr_in inarg;
- int err;
-
- if (fc->no_setxattr)
- return -EOPNOTSUPP;
+ if (attr->ia_valid & (ATTR_KILL_SUID | ATTR_KILL_SGID)) {
+ attr->ia_valid &= ~(ATTR_KILL_SUID | ATTR_KILL_SGID |
+ ATTR_MODE);
- memset(&inarg, 0, sizeof(inarg));
- inarg.size = size;
- inarg.flags = flags;
- args.in.h.opcode = FUSE_SETXATTR;
- args.in.h.nodeid = get_node_id(inode);
- args.in.numargs = 3;
- args.in.args[0].size = sizeof(inarg);
- args.in.args[0].value = &inarg;
- args.in.args[1].size = strlen(name) + 1;
- args.in.args[1].value = name;
- args.in.args[2].size = size;
- args.in.args[2].value = value;
- err = fuse_simple_request(fc, &args);
- if (err == -ENOSYS) {
- fc->no_setxattr = 1;
- err = -EOPNOTSUPP;
- }
- if (!err) {
- fuse_invalidate_attr(inode);
- fuse_update_ctime(inode);
+ /*
+ * The only sane way to reliably kill suid/sgid is to do it in
+ * the userspace filesystem
+ *
+ * This should be done on write(), truncate() and chown().
+ */
+ if (!fc->handle_killpriv) {
+ int kill;
+
+ /*
+ * ia_mode calculation may have used stale i_mode.
+ * Refresh and recalculate.
+ */
+ ret = fuse_do_getattr(inode, NULL, file);
+ if (ret)
+ return ret;
+
+ attr->ia_mode = inode->i_mode;
+ kill = should_remove_suid(entry);
+ if (kill & ATTR_KILL_SUID) {
+ attr->ia_valid |= ATTR_MODE;
+ attr->ia_mode &= ~S_ISUID;
+ }
+ if (kill & ATTR_KILL_SGID) {
+ attr->ia_valid |= ATTR_MODE;
+ attr->ia_mode &= ~S_ISGID;
+ }
+ }
}
- return err;
-}
-
-static ssize_t fuse_getxattr(struct dentry *entry, struct inode *inode,
- const char *name, void *value, size_t size)
-{
- struct fuse_conn *fc = get_
Re: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses
When you need to make changes to patches that are part of a series, you must resubmit the entire series, not just the things that are changes.
Re: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.
On Mon, 26 Sep 2016, Liav Rehana wrote: > During the calculation of the nsec variable in the inline function > timekeeping_delta_to_ns, it may undergo a sign extension if its msb > is set just before the shift. The sign extension may, in some cases, > gain it a value near the maximum value of the 64-bit range. This is > bad when it is later used in a division function, such as > __iter_div_u64_rem, where the amount of loops it will go through to > calculate the division will be too large. > The following commit fixes that chance of sign extension, Again. This does not fix anything, it papers over the underlying problem that the calling code hands in a delta which is big enough to overflow the multiplication into the negative space. You just extend the range of deltas which are handled gracefully, but that does not fix the underlying problem as we still can run into the multiplication overflow. It won't cause the result to be negative, but it will be crap nevertheless. > while maintaining the type of the nsec variable as signed for other > functions that use this variable, for possible legit negative time > intervals. What is this maintaining? The type of this variable changes to u64 and other functions cannot use this variable at all because it's local to that function. This sentence makes no sense at all. Thanks, tglx
Re: [PATCH v2] fs/select: add vmalloc fallback for select(2)
On Thu, 22 Sep 2016 18:43:59 +0200 Vlastimil Babka wrote:
> The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows
> with the number of fds passed. We had a customer report page allocation
> failures of order-4 for this allocation. This is a costly order, so it might
> easily fail, as the VM expects such allocation to have a lower-order fallback.
>
> Such trivial fallback is vmalloc(), as the memory doesn't have to be
> physically contiguous. Also the allocation is temporary for the duration of
> the
> syscall, so it's unlikely to stress vmalloc too much.
>
> Note that the poll(2) syscall seems to use a linked list of order-0 pages, so
> it doesn't need this kind of fallback.
>
> ...
>
> --- a/fs/select.c
> +++ b/fs/select.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -558,6 +559,7 @@ int core_sys_select(int n, fd_set __user *inp, fd_set
> __user *outp,
> struct fdtable *fdt;
> /* Allocate small arguments on the stack to save memory and be faster */
> long stack_fds[SELECT_STACK_ALLOC/sizeof(long)];
> + unsigned long alloc_size;
>
> ret = -EINVAL;
> if (n < 0)
> @@ -580,8 +582,12 @@ int core_sys_select(int n, fd_set __user *inp, fd_set
> __user *outp,
> bits = stack_fds;
> if (size > sizeof(stack_fds) / 6) {
> /* Not enough space in on-stack array; must use kmalloc */
> + alloc_size = 6 * size;
Well. `size' is `unsigned'. The multiplication will be done as 32-bit
so there was no point in making `alloc_size' unsigned long.
So can we tighten up the types in this function? size_t might make
sense, but vmalloc() takes a ulong.
> ret = -ENOMEM;
> - bits = kmalloc(6 * size, GFP_KERNEL);
> + bits = kmalloc(alloc_size, GFP_KERNEL|__GFP_NOWARN);
> + if (!bits && alloc_size > PAGE_SIZE)
> + bits = vmalloc(alloc_size);
I don't share Eric's concerns about performance here. If the vmalloc()
is called, we're about to write to that quite large amount of memory
which we just allocated, and the vmalloc() overhead will be relatively
low.
> if (!bits)
> goto out_nofds;
> }
> @@ -618,7 +624,7 @@ int core_sys_select(int n, fd_set __user *inp, fd_set
> __user *outp,
>
> out:
> if (bits != stack_fds)
> - kfree(bits);
> + kvfree(bits);
> out_nofds:
> return ret;
It otherwise looks OK to me.
