[PATCH] Documentation: Better document the hardlockup_panic sysctl
Commit ac1f591249d95372f ("kernel/watchdog.c: add sysctl knob
hardlockup_panic") added the hardlockup_panic sysctl, but did not add it
to Documentation/sysctl/kernel.txt. Add this, and reference it from the
corresponding entry in Documentation/admin-guide/kernel-parameters.txt.
Signed-off-by: Scott Wood
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
Documentation/sysctl/kernel.txt | 14 ++
2 files changed, 17 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 6571fbfdb2a1..dfb7c35b5826 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2538,6 +2538,9 @@
This is useful when you use a panic=... timeout and
need the box quickly up again.
+ These settings can be accessed at runtime via
+ the nmi_watchdog and hardlockup_panic sysctls.
+
netpoll.carrier_timeout=
[NET] Specifies amount of time (in seconds) that
netpoll should wait for a carrier. By default netpoll
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 694968c7523c..63663039acb7 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -34,6 +34,7 @@ show up in /proc/sys/kernel:
- hostname
- hotplug
- hardlockup_all_cpu_backtrace
+- hardlockup_panic
- hung_task_panic
- hung_task_check_count
- hung_task_timeout_secs
@@ -313,6 +314,19 @@ will be initiated.
1: on detection capture more debug information.
==
+hardlockup_panic:
+
+This parameter can be used to control whether the kernel panics
+when a hard lockup is detected.
+
+ 0 - don't panic on hard lockup
+ 1 - panic on hard lockup
+
+See Documentation/lockup-watchdogs.txt for more information. This can
+also be set using the nmi_watchdog kernel parameter.
+
+==
+
hotplug:
Path for the hotplug policy agent.
--
2.9.5
Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation
On 12/09/2017 09:19 AM, Pavel Machek wrote: > On Thu 2017-12-07 15:02:21, Michal Hocko wrote: >> On Thu 07-12-17 13:58:05, Cyril Hrubis wrote: >>> Hi! >> (It does seem unfortunate that the man page cannot help the programmer >> actually write correct code here. He or she is forced to read the kernel >> implementation, in order to figure out the true alignment rules. I was >> hoping we could avoid that.) > > It would be nice if we had this information exported somehere so that we > do not have to rely on per-architecture ifdefs. > > What about adding MapAligment or something similar to the /proc/meminfo? > What's the use case you envision for that? I don't see how that would be better than using SHMLBA, which is available at compiler time. Because unless someone expects to be able to run an app that was compiled for Arch X, on Arch Y (surely that's not requirement here?), I don't see how the run-time check is any better. >>> >>> I guess that some kind of compile time constant in uapi headers will do >>> as well, I'm really open to any solution that would expose this constant >>> as some kind of official API. >> >> I am not sure this is really feasible. It is not only a simple alignment >> thing. Look at ppc for example (slice_get_unmapped_area). Other >> architectures might have even more complicated rules e.g. arm and its >> cache_is_vipt_aliasing. Also this applies only on MAP_SHARED || file >> backed mappings. >> >> I would really leave dogs sleeping... Trying to document all this in the >> man page has chances to confuse more people than it has chances to help >> those who already know all these nasty details. > > You don't have to provide all the details, but warning that there's arch- > specific magic would be nice... Hi Pavel, In version 4 of this patch (which oddly enough, I have trouble finding via google, it only seems to show up in patchwork.kernel.org [1]), I phrased it like this: Don't interpret addr as a hint: place the mapping at exactly that address. addr must be suitably aligned: for most architectures a multiple of page size is sufficient; however, some architectures may impose additional restrictions. ...which is basically what Cyril was asking for, in his early feedback. Does that work for you? (Maybe I need to repost that patch. In any case the CC's need updating, at least.) [1] https://patchwork.kernel.org/patch/10094905/ thanks, -- John Hubbard NVIDIA > Pavel > > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html >
Re: [PATCH] hyperv: make HYPERV a menuconfig to ease disabling it all
On Sat, 9 Dec 2017 16:21:51 +0100 Vincent Legoll wrote: > No need to get into the submenu to disable all HYPERV-related > config entries. > > This makes it easier to disable all HYPERV config options > without entering the submenu. It will also enable one > to see that en/dis-abled state from the outside menu. > > This is only intended to change menuconfig UI, not change > the config dependencies. > > Signed-off-by: Vincent Legoll > --- > drivers/hv/Kconfig | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig > index 50b89ea0e60f..5804081d936d 100644 > --- a/drivers/hv/Kconfig > +++ b/drivers/hv/Kconfig > @@ -1,4 +1,7 @@ > -menu "Microsoft Hyper-V guest support" > +menuconfig HYPERV_MENU > + bool "Microsoft Hyper-V guest support" > + > +if HYPERV_MENU > > config HYPERV > tristate "Microsoft Hyper-V client drivers" > @@ -23,4 +26,4 @@ config HYPERV_BALLOON > help > Select this option to enable Hyper-V Balloon driver. > > -endmenu > +endif # HYPERV_MENU Will this break existing configs?
Re: [PATCH] kbuild: move cc-option and cc-disable-warning after incl. arch Makefile
2017-11-27 21:25 GMT+09:00 Geert Uytterhoeven :
> Hi Yamada-san,
>
> On Mon, Nov 27, 2017 at 1:15 PM, Masahiro Yamada
> wrote:
>> Geert reported commit ae6b289a3789 ("kbuild: Set KBUILD_CFLAGS before
>> incl. arch Makefile") broke cross-compilation using a cross-compiler
>> that supports less compiler options than the host compiler.
>>
>> For example,
>>
>> cc1: error: unrecognized command line option "-Wno-unused-but-set-variable"
>>
>> This problem happens on architectures that setup CROSS_COMPILE in their
>> arch/*/Makefile.
>>
>> Move the cc-option and cc-disable-warning back to the original position,
>> but keep the Clang target options.
>>
>> Fixes: ae6b289a3789 ("kbuild: Set KBUILD_CFLAGS before incl. arch Makefile")
>> Reported-by: Geert Uytterhoeven
>> Signed-off-by: Masahiro Yamada
>
> Thanks for the quick response!
>
> Tested-by: Geert Uytterhoeven
>
> Gr{oetje,eeting}s,
>
> Geert
Applied to linux-kbuild/fixes.
--
Best Regards
Masahiro Yamada
Re: kernel BUG at net/core/skbuff.c:LINE! (2)
On Sun, 2017-12-10 at 12:38 +0800, Xin Long wrote: > On Sun, Dec 10, 2017 at 3:36 AM, Cong Wang > wrote: > > On Fri, Dec 8, 2017 at 12:45 AM, Xin Long > > wrote: > > > This isn't a sctp problem, but mld's, seems when lo's mtu became > > > 0, > > > it allocs a skb without enough space in add_grec(): > > > > Shouldn't we just set its min_mtu to ETH_MIN_MTU? > > No idea why there's no min_mtu limitation for lo dev. Because it wont solve this bug. ETH_MIN_MTU is really about IPv4.
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: Linux 4.15-rc1 (2017-11-26 16:01:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes for you to fetch changes up to 8be0b9886b6470a1261c9c2d0cfc1f0f89bf21b9: Merge branch 'fixes' into for-next (2017-12-09 20:23:58 -0800) ARM: SoC fixes for 4.15-rc ARM SoC fixes for this merge window: - A revert of all SCPI changes from the 4.15 merge window. They had regressions on the Amlogic platforms, and the submaintainer isn't around to fix these bugs due to vacation, etc. So we agreed to revert and revisit in next release cycle. - A series fixing a number of bugs for ARM CCN interconnect, around module unload, smp_processor_id() in preemptable context, and fixing some memory allocation failure checks. - A handful of devicetree fixes for different platforms, fixing warnings and errors that were previously ignored by the compiler. - The usual set of mostly minor fixes for different platforms. Adam Ford (2): ARM: dts: logicpd-som-lv: Fix gpmc addresses for NAND and enet ARM: dts: logicpd-somlv: Fix wl127x pinmux Arnaud Patard (1): meson-gx-socinfo: Fix package id parsing Arnd Bergmann (3): ARM: dts: r8a779x: Add '#reset-cells' in cpg-mssr ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 builds Merge branch 'fixes' into for-next Arvind Yadav (1): bus: arm-ccn: constify attribute_group structures. Christophe JAILLET (2): bus: arm-ccn: Check memory allocation failure bus: arm-ccn: Simplify code Colin Ian King (1): ARM: meson: fix spelling mistake: "Couln't" -> "Couldn't" Dai Okamura (1): arm64: dts: uniphier: correct on-board device IRQ number for PXs3 Dan Carpenter (1): ARM: OMAP2+: Missing error code in omap_device_build() Fabio Estevam (2): ARM: dts: vf610-zii-dev-rev-c: Fix the I2C EEPROM address Revert "ARM: dts: imx53: add srtc node" Florian Fainelli (3): ARM: dts: NSP: Disable AHCI controller for HR NSP boards ARM: dts: NSP: Fix PPI interrupt types Merge tag 'bcm2835-dt-next-fixes-2017-11-15' into devicetree/fixes Jens Wiklander (1): optee: fix invalid of_node_put() in optee_driver_init() Keerthy (1): ARM: AM33xx: PRM: Remove am33xx_pwrdm_read_prev_pwrst function Kim Phillips (1): bus: arm-ccn: fix module unloading Error: Removing state 147 which has instances left. Marc Zyngier (2): bus: arm-ccn: Fix use of smp_processor_id() in preemptible context bus: arm-cci: Fix use of smp_processor_id() in preemptible context Martin Blumenstingl (2): ARM: dts: meson: correct the sort order for the the gpio_intc node ARM: dts: meson: fix the memory region of the GPIO interrupt controller Masahiro Yamada (3): arm64: dts: uniphier: remove unnecessary interrupt-parent MAINTAINERS: exclude other Socionext SoC DT files from ARM/UNIPHIER entry arm64: dts: sort vendor subdirectories in Makefile alphabetically Neil Armstrong (1): ARM64: dts: meson-gx: fix UART pclk clock name Olof Johansson (12): Merge tag 'renesas-dt-fixes-for-v4.15' of https://git.kernel.org/.../horms/renesas into fixes Merge tag 'arm-soc/for-4.15/devicetree-fixes-1' of http://github.com/Broadcom/stblinux into fixes Merge tag 'tee-drv-fix-for-4.15' of https://git.linaro.org/people/jens.wiklander/linux-tee into fixes Merge tag 'uniphier-fixes-v4.15' of git://git.kernel.org/.../masahiroy/linux-uniphier into fixes Merge tag 'imx-fixes-4.15' of git://git.kernel.org/.../shawnguo/linux into fixes Merge tag 'omap-for-v4.15/fixes-v2-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes firmware: arm_scpi: Revert updates made during v4.15 merge window Merge branch 'fixes' into for-next Merge tag 'omap-for-v4.15/fixes-dt-warnings' of git://git.kernel.org/.../tmlind/linux-omap into fixes Merge tag 'ccn/fixes-for-4.15' of git://git.linaro.org/people/pawel.moll/linux into fixes Merge tag 'amlogic-fixes-1' of git://git.kernel.org/.../khilman/linux-amlogic into fixes Merge branch 'fixes' into for-next Peter Ujfalusi (2): ARM: dts: am4372: Correct the interrupts_properties of McASP ARM: dts: am437x-cm-t43: Correct the dmas property of spi0 Rob Herring (4): ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv ARM: dts: am33xx: Add missing #phy-cells to ti,am335x-usb-phy arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv Stefan Wahren (1): ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells Tero Kristo (2): ARM: OMAP3: hwmod_data: add missing module_of
Re: kernel BUG at net/core/skbuff.c:LINE! (2)
On Sun, 2017-12-10 at 12:36 +0800, Xin Long wrote: > The new patch works to me, just two questions: > 1. should it use "idev->cnf.mtu6" here for mld ? No idea why some parts of IPv6 would use a different view of device mtu. Maybe others can comment. > > 2. 'if (int < unsigned int)' is still not nice, though in 'if > (AVAILABLE(skb) < sizeof())' > AVAILABLE(skb) seems always to return >= 0 after your patch. Really if AVAILABLE(skb) was negative, a bug already happened.
[PATCH v3 2/2] staging: rtl8712: Cleanup codestyle, change spaces to tabs
Cleanup below checkpatch issues:
ERROR:CODE_INDENT: code indent should use tabs where possible
1409: FILE: rtl871x_security.c:1409:
+from_timer(padapter, t, securitypriv.tkip_timer);$
WARNING:LEADING_SPACE: please, no spaces at the start of a line
1409: FILE: rtl871x_security.c:1409:
+from_timer(padapter, t, securitypriv.tkip_timer);$
Signed-off-by: Neil Singh
---
drivers/staging/rtl8712/rtl871x_security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index 630f18f..f459152 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -1406,7 +1406,7 @@ u32 r8712_aes_decrypt(struct _adapter *padapter, u8
*precvframe)
void r8712_use_tkipkey_handler(struct timer_list *t)
{
struct _adapter *padapter =
-from_timer(padapter, t, securitypriv.tkip_timer);
+ from_timer(padapter, t, securitypriv.tkip_timer);
padapter->securitypriv.busetkipkey = true;
}
--
2.1.4
Re: kernel BUG at net/core/skbuff.c:LINE! (2)
On Sun, Dec 10, 2017 at 3:36 AM, Cong Wang wrote: > On Fri, Dec 8, 2017 at 12:45 AM, Xin Long wrote: >> This isn't a sctp problem, but mld's, seems when lo's mtu became 0, >> it allocs a skb without enough space in add_grec(): > > Shouldn't we just set its min_mtu to ETH_MIN_MTU? No idea why there's no min_mtu limitation for lo dev.
[PATCH v3 0/2] staging: rtl8712: Cleanup codestyle
Cleanup some codestyle issues identified by checkpatch. Changes since v2: - Modify patches so they themselves don't trigger the checkpatch issues CHECK:PARENTHESIS_ALIGNMENT and WARNING:EMAIL_SUBJECT Changes since v1: - Split single patch into multiple Neil Singh (2): staging: rtl8712: Cleanup codestyle, break up long line staging: rtl8712: Cleanup codestyle, change spaces to tabs drivers/staging/rtl8712/rtl871x_security.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) -- 2.1.4
[PATCH v3 1/2] staging: rtl8712: Cleanup codestyle, break up long line
Cleanup below checkpatch issue:
WARNING:LONG_LINE: line over 80 characters
1000: FILE: rtl871x_security.c:1000:
+static void construct_ctr_preload(u8 *ctr_preload, sint a4_exists, sint
qc_exists,
Signed-off-by: Neil Singh
---
drivers/staging/rtl8712/rtl871x_security.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index 56d36f6..630f18f 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -997,8 +997,9 @@ static void construct_mic_header2(u8 *mic_header2, u8
*mpdu, sint a4_exists,
/* Builds the last MIC header block from*/
/* header fields. */
//
-static void construct_ctr_preload(u8 *ctr_preload, sint a4_exists, sint
qc_exists,
- u8 *mpdu, u8 *pn_vector, sint c)
+static void construct_ctr_preload(u8 *ctr_preload,
+ sint a4_exists, sint qc_exists,
+ u8 *mpdu, u8 *pn_vector, sint c)
{
sint i;
--
2.1.4
Re: kernel BUG at net/core/skbuff.c:LINE! (2)
On Sun, Dec 10, 2017 at 12:59 AM, Eric Dumazet wrote:
> On Sat, 2017-12-09 at 19:23 +0800, Xin Long wrote:
>> On Fri, Dec 8, 2017 at 4:45 PM, Xin Long
>> wrote:
>> > On Fri, Dec 8, 2017 at 4:16 PM, syzbot
>> > > > .com>
>> > wrote:
>> > > syzkaller has found reproducer for the following crash on
>> > > 82bcf1def3b5f1251177ad47c44f7e17af039b4b
>> > > git://git.cmpxchg.org/linux-mmots.git/master
>> > > compiler: gcc (GCC) 7.1.1 20170620
>> > > .config is attached
>> > > Raw console output is attached.
>> > >
>> > > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> > > for information about syzkaller reproducers
>> > >
>> > >
>> > > skbuff: skb_over_panic: text:10b86b8d len:196 put:20
>> > > head:3b477e60 data:0e85441e tail:0xd4 end:0xc0
>> > > dev:lo
>> > > [ cut here ]
>> > > kernel BUG at net/core/skbuff.c:104!
>> > > invalid opcode: [#1] SMP KASAN
>> > > Dumping ftrace buffer:
>> > >(ftrace buffer empty)
>> > > Modules linked in:
>> > > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.15.0-rc2-mm1+ #39
>> > > Hardware name: Google Google Compute Engine/Google Compute
>> > > Engine, BIOS
>> > > Google 01/01/2011
>> > > RIP: 0010:skb_panic+0x15c/0x1f0 net/core/skbuff.c:100
>> > > RSP: 0018:8801db307508 EFLAGS: 00010286
>> > > RAX: 0082 RBX: 8801c517e840 RCX:
>> > > RDX: 0082 RSI: 11003b660e61 RDI: ed003b660e95
>> > > RBP: 8801db307570 R08: 11003b660e23 R09:
>> > > R10: R11: R12: 85bd4020
>> > > R13: 84754ed2 R14: 0014 R15: 8801c4e26540
>> > > FS: () GS:8801db30()
>> > > knlGS:
>> > > CS: 0010 DS: ES: CR0: 80050033
>> > > CR2: 00463610 CR3: 0001c6698000 CR4: 001406e0
>> > > DR0: DR1: DR2:
>> > > DR3: DR6: fffe0ff0 DR7: 0400
>> > > Call Trace:
>> > >
>> > > skb_over_panic net/core/skbuff.c:109 [inline]
>> > > skb_put+0x181/0x1c0 net/core/skbuff.c:1694
>> > > add_grhead.isra.24+0x42/0x3b0 net/ipv6/mcast.c:1695
>> > > add_grec+0xa55/0x1060 net/ipv6/mcast.c:1817
>> > > mld_send_cr net/ipv6/mcast.c:1903 [inline]
>> > > mld_ifc_timer_expire+0x4d2/0x770 net/ipv6/mcast.c:2448
>> > > call_timer_fn+0x23b/0x840 kernel/time/timer.c:1320
>> > > expire_timers kernel/time/timer.c:1357 [inline]
>> > > __run_timers+0x7e1/0xb60 kernel/time/timer.c:1660
>> > > run_timer_softirq+0x4c/0xb0 kernel/time/timer.c:1686
>> > > __do_softirq+0x29d/0xbb2 kernel/softirq.c:285
>> > > invoke_softirq kernel/softirq.c:365 [inline]
>> > > irq_exit+0x1d3/0x210 kernel/softirq.c:405
>> > > exiting_irq arch/x86/include/asm/apic.h:540 [inline]
>> > > smp_apic_timer_interrupt+0x16b/0x700
>> > > arch/x86/kernel/apic/apic.c:1052
>> > > apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
>> > >
>> > > RIP: 0010:native_safe_halt+0x6/0x10
>> > > arch/x86/include/asm/irqflags.h:54
>> > > RSP: 0018:8801d9f97da8 EFLAGS: 0282 ORIG_RAX:
>> > > ff11
>> > > RAX: dc00 RBX: 11003b3f2fb8 RCX:
>> > > RDX: 10c59734 RSI: 0001 RDI: 862cb9a0
>> > > RBP: 8801d9f97da8 R08: R09:
>> > > R10: R11: R12: 0001
>> > > R13: 8801d9f97e60 R14: 869eb920 R15:
>> > > arch_safe_halt arch/x86/include/asm/paravirt.h:93 [inline]
>> > > default_idle+0xbf/0x430 arch/x86/kernel/process.c:355
>> > > arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:346
>> > > default_idle_call+0x36/0x90 kernel/sched/idle.c:98
>> > > cpuidle_idle_call kernel/sched/idle.c:156 [inline]
>> > > do_idle+0x24a/0x3b0 kernel/sched/idle.c:246
>> > > cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:351
>> > > start_secondary+0x330/0x460 arch/x86/kernel/smpboot.c:277
>> > > secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:237
>> > > Code: 03 0f b6 04 01 84 c0 74 04 3c 03 7e 20 8b 4b 78 41 57 48 c7
>> > > c7 a0 38
>> > > bd 85 52 56 4c 89 ea 41 50 4c 89 e6 45 89 f0 e8 0c b6 3d fd <0f>
>> > > 0b 4c 89 4d
>> > > b8 4c 89 45 c0 48 89 75 c8 48 89 55 d0 e8 7d 93
>> > > RIP: skb_panic+0x15c/0x1f0 net/core/skbuff.c:100 RSP:
>> > > 8801db307508
>> > > ---[ end trace 941a8a0f633e271f ]---
>> > >
>> >
>> > This isn't a sctp problem, but mld's, seems when lo's mtu became 0,
>> > it allocs a skb without enough space in add_grec():
>> > if (AVAILABLE(skb) < sizeof(*psrc) +
>> > first*sizeof(struct mld2_grec)) {
>> > if (truncate && !first)
>> > break; /* truncate these */
>> > if (pgr)
>> > pgr->grec_nsrcs = htons(scount);
>> > if (skb)
>> >
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi, On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > This adds a driver for the SMMUv3 PMU into the perf framework. > It includes an IORT update to support PM Counter Groups. > In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU. This would be a matter of concern for software if the SMMU and SMMU PMCG blocks are managed by two independent drivers. The problem arises when we want to alloc/free MSIs for these devices using the APIs, platform_msi_domain_alloc/free_irqs. Platform bus id being same for these two hardware blocks, they end up sharing the same ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management of this shared ITT becomes a problem when they are managed by two independent drivers. We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs function call for all devices that share the platform bus id. Would like to know your expert opinion on what would be the right approach to handle this case ? Thanks. > IORT has no mechanism for determining device names so PMUs > are named based on their physical address. > > Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours > with no failures. > > Neil Leeder (2): > acpi: arm64: add iort support for PMCG > perf: add arm64 smmuv3 pmu driver > > drivers/acpi/arm64/iort.c | 54 +++ > drivers/perf/Kconfig | 9 + > drivers/perf/Makefile | 1 + > drivers/perf/arm_smmuv3_pmu.c | 823 > ++ > include/acpi/actbl2.h | 9 +- > 5 files changed, 895 insertions(+), 1 deletion(-) > create mode 100644 drivers/perf/arm_smmuv3_pmu.c > > -- > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm > Technologies Inc. > Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project. > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Linu cherian
Re: [PATCH v2] fs: handle shrinker registration failure in sget_userns
Al Viro wrote:
> On Sat, Dec 09, 2017 at 08:59:22PM +, Al Viro wrote:
> > On Wed, Nov 29, 2017 at 12:55:15PM +0100, Michal Hocko wrote:
> > > On Thu 23-11-17 14:55:40, Al Viro wrote:
> > > > On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote:
> > > > > Hopefully less screwed version. But as I've said I am not really
> > > > > familiar with the code and do not feel competent to change it so
> > > > > please
> > > > > be very careful here. I've moved the shrinker registration to
> > > > > alloc_super which turned out to be simpler.
> > > >
> > > > I don't get it. Why the hell do we need all that PITA in the first
> > > > place?
> > > > Just make sget_userns() end with
> > > > if (unlikely(regsiter_shrinker(&s->s_shrink) != 0)) {
> > > > deactivate_locked_super(s);
> > > > s = ERR_PTR(-ENOMEM);
> > > > }
> > > > return s;
> > > > and be done with that. All there is to it...
> > >
> > > Al, do you plan to push this fix? Tetsuo's unregister_shrinker
> > > fortification is already in the mmotm tree.
> >
> > Is it in any git branch I could pull from? Or I could just throw it
> > into vfs.git#for-linus before the fix above - up to you, folks...
>
> Actually, looking at mmotm... I don't see it there. Which patch
> is it in?
>
My unregister_shrinker() fortification patch
(
http://lkml.kernel.org/r/1511523385-6433-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
)
is not yet in the mmotm tree due to disagreement between Michal and I, but
you can throw your sget_userns() patch into vfs.git#for-linus anyway.
We will eventually apply unregister_shrinker() fortification patch.
I'm observing whether people notice my __must_check annotation patch
(
http://lkml.kernel.org/r/1511523385-6433-2-git-send-email-penguin-ker...@i-love.sakura.ne.jp
)
in linux-next.git and fix register_shrinker() callers. If people do not fix
the callers, both patches need to be sent to linux.git.
Re: [PATCH v2 1/2] staging: rtl8712: Cleanup checkpatch issue WARNING:LONG_LINE
On 12/09/2017 05:11 AM, Neil Singh wrote:
Cleanup below checkpatch issue:
WARNING:LONG_LINE: line over 80 characters
1000: FILE: rtl871x_security.c:1000:
+static void construct_ctr_preload(u8 *ctr_preload, sint a4_exists, sint
qc_exists,
Signed-off-by: Neil Singh
---
drivers/staging/rtl8712/rtl871x_security.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index 56d36f6..77a5f5d 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -997,7 +997,8 @@ static void construct_mic_header2(u8 *mic_header2, u8
*mpdu, sint a4_exists,
/* Builds the last MIC header block from*/
/* header fields. */
//
-static void construct_ctr_preload(u8 *ctr_preload, sint a4_exists, sint
qc_exists,
+static void construct_ctr_preload(u8 *ctr_preload,
+ sint a4_exists, sint qc_exists,
u8 *mpdu, u8 *pn_vector, sint c)
{
sint i;
Did you run checkpatch on these patches? My system reports the following:
---
patch_1
---
WARNING: A patch subject line should describe the change not the tool that
found it
#95:
Subject: [PATCH v2 1/2] staging: rtl8712: Cleanup checkpatch issue
WARNING:LONG_LINE
CHECK: Alignment should match open parenthesis
#125: FILE: drivers/staging/rtl8712/rtl871x_security.c:1001:
+static void construct_ctr_preload(u8 *ctr_preload,
+ sint a4_exists, sint qc_exists,
---
patch_2
---
WARNING: A patch subject line should describe the change not the tool that
found it
#95:
Subject: [PATCH v2 2/2] staging: rtl8712: Cleanup checkpatch issues CODE_INDENT
and LEADING_SPACE
Larry
Re: [PATCH v3 1/2] eeprom: at24: fix coding style issues
On Thu, Dec 07, 2017 at 02:39:14PM +0100, Bartosz Golaszewski wrote: > -#define AT24_DEVICE_MAGIC(_len, _flags) \ > - ((1 << AT24_SIZE_FLAGS | (_flags)) \ > +#define AT24_DEVICE_MAGIC(_len, _flags) \ > + ((1 << AT24_SIZE_FLAGS | (_flags)) \ > << AT24_SIZE_BYTELEN | ilog2(_len)) Looks like there's been a whitespace accident on that first added line. (Backslash has one more tab in front of it than it should have) -- Regards, Christoph
Re: [PATCH] KVM: X86: Fix host dr6 miss restore
2017-12-08 20:39 GMT+08:00 David Hildenbrand : > On 08.12.2017 10:12, Wanpeng Li wrote: >> From: Wanpeng Li >> >> Reported by syzkaller: >> >>WARNING: CPU: 0 PID: 12927 at arch/x86/kernel/traps.c:780 >> do_debug+0x222/0x250 >>CPU: 0 PID: 12927 Comm: syz-executor Tainted: G OE >> 4.15.0-rc2+ #16 >>RIP: 0010:do_debug+0x222/0x250 >>Call Trace: >> <#DB> >> debug+0x3e/0x70 >>RIP: 0010:copy_user_enhanced_fast_string+0x10/0x20 >> >> _copy_from_user+0x5b/0x90 >> SyS_timer_create+0x33/0x80 >> entry_SYSCALL_64_fastpath+0x23/0x9a >> >> The syzkaller will mmap a buffer which is also the struct sigevent parameter >> of >> timer_create(), it will also call perf_event_open() to set a BP for the >> buffer, >> so when the implementation of timer_create() in kernel tries to get the >> struct >> sigevent parameter by copy_from_user(), rep movsb triggers the BP. The >> syzkaller >> testcase also sets the debug registers for the guest, however, the kvm just >> restores host debug registers when we have active breakpoints. I can observe >> the dr6 single step bit is set and !hw_breakpoint_active() sporadically by >> print >> when running the testcase heavy multithreading. The do_debug() which is >> triggered >> by rep movsb will splash when (dr6 & DR_STEP && !user_mode(regs)). >> >> This patch fixes it by restoring host dr6 unconditionally before preempt/irq >> enable. >> >> Reported-by: Dmitry Vyukov >> Cc: Paolo Bonzini >> Cc: Radim Krčmář >> Cc: David Hildenbrand >> Cc: Dmitry Vyukov >> Signed-off-by: Wanpeng Li >> --- >> arch/x86/kvm/x86.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index 0c5d55c..a6370fd 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -7065,6 +7065,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) >>*/ >> if (hw_breakpoint_active()) >> hw_breakpoint_restore(); >> + else >> + set_debugreg(current->thread.debugreg6, 6); >> >> vcpu->arch.last_guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc()); >> >> > > If you haven't seen it, I analyzed this in > https://lkml.org/lkml/2017/11/7/638 but nobody would respond for now to > my suggestion/question. I think it's fine to restore dr6 before preempt/irq enable. Regards, Wanpeng Li
Re: [PATCH] mtd: nand: gpio: Fix ALE gpio configuration
On Wed, Dec 6, 2017 at 6:27 PM, Christophe Leroy
wrote:
> Fixes a copy/paste error in commit f3d0d8d938b4d ("mtd: nand: gpio:
> Convert to use GPIO descriptors") which breaks gpio-nand driver
>
> Fixes: f3d0d8d938b4d ("mtd: nand: gpio: Convert to use GPIO descriptors")
> Cc: Linus Walleij
> Signed-off-by: Christophe Leroy
Sorry about that :(
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
[no subject]
Hi Lkml http://bit.ly/2y9rB7b atokawotsa
[PATCH 0/4] PM / core: Direct handling of DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED
Hi All, This series is a follow-up for https://marc.info/?l=linux-doc&m=151101644105835&w=2 Patches[1-3/6] from the above have been reviewed and agreed on, so they are in linux-next now and here's a next version of the rest. Patches [1-2/4] are preparatory. The first one is just really small code duplication avoidance on top of this recent fix: https://patchwork.kernel.org/patch/10097563/ and the second one simply moves some code to separate functions. Patch [3/4] causes the PM core to carry out some optimizations for drivers of devices with DPM_FLAG_SMART_SUSPEND set whose "late" and "noirq" suspend (or equivalent) driver callbacks are invoked directly by the core. The underlying observation is that if the device is suspended (via runtime PM) during the "late suspend" phase of a system transition, invoking the "late" and "noirq" callbacks from the driver for it is not going to make it more suspended, so to speak, so it doesn't make sense to invoke them at all. [That optimization is only done for devices with DPM_FLAG_SMART_SUSPEND set, because drivers setting that flag are expected to be prepared for skipping their "late" and "noirq" callbacks if the device is already suspended.] Patch [4/4] makes the core do an analogous thing for devices with DPM_FLAG_LEAVE_SUSPENDED set whose "noirq" and "early" resume (or equivalent) driver callbacks are directly invoked by the core. In that case the observation is that if such devices can be left in suspend after the system transition to the working state, running resume callbacks from their drivers is simply not necessary. Pathes [3-4/4] have been reoredered and reworked a bit since the last iteration, so they are regarded as new. The series is on top of the linux-next branch of the linux-pm.git tree that should be merged into linux-next on Monday. [I have developed debug bus type and driver modules to test that code, but they are not ready to be made available at this point.] Thanks, Rafael
[PATCH 3/4] PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
From: Rafael J. Wysocki
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki
---
Documentation/driver-api/pm/devices.rst | 18 +++---
drivers/base/power/main.c | 85 +---
2 files changed, 88 insertions(+), 15 deletions(-)
Index: linux-pm/Documentation/driver-api/pm/devices.rst
===
--- linux-pm.orig/Documentation/driver-api/pm/devices.rst
+++ linux-pm/Documentation/driver-api/pm/devices.rst
@@ -777,14 +777,16 @@ The driver can indicate that by setting
runtime suspend at the beginning of the ``suspend_late`` phase of system-wide
suspend (or in the ``poweroff_late`` phase of hibernation), when runtime PM
has been disabled for it, under the assumption that its state should not change
-after that point until the system-wide transition is over. If that happens,
the
-driver's system-wide resume callbacks, if present, may still be invoked during
-the subsequent system-wide resume transition and the device's runtime power
-management status may be set to "active" before enabling runtime PM for it,
-so the driver must be prepared to cope with the invocation of its system-wide
-resume callbacks back-to-back with its ``->runtime_suspend`` one (without the
-intervening ``->runtime_resume`` and so on) and the final state of the device
-must reflect the "active" status for runtime PM in that case.
+after that point until the system-wide transition is over (the PM core itself
+does that for devices whose "noirq", "late" and "early" system-wide PM
callbacks
+are executed directly by it). If that happens, the driver's system-wide resume
+callbacks, if present, may still be invoked during the subsequent system-wide
+resume transition and the device's runtime power management status may be set
+to "active" before enabling runtime PM for it, so the driver must be prepared
to
+cope with the invocation of its system-wide resume callbacks back-to-back with
+its ``->runtime_suspend`` one (without the intervening ``->runtime_resume`` and
+so on) and the final state of the device must reflect the "active" runtime PM
+status in that case.
During system-wide resume from a sleep state it's easiest to put devices into
the full-power state, as explained in
:file:`Documentation/power/runtime_pm.txt`.
Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -541,6 +541,24 @@ void dev_pm_skip_next_resume_phases(stru
}
/**
+ * suspend_event - Return a "suspend" message for given "resume" one.
+ * @resume_msg: PM message representing a system-wide resume transition.
+ */
+static pm_message_t suspend_event(pm_message_t resume_msg)
+{
+ switch (resume_msg.event) {
+ case PM_EVENT_RESUME:
+ return PMSG_SUSPEND;
+ case PM_EVENT_THAW:
+ case PM_EVENT_RESTORE:
+ return PMSG_FREEZE;
+ case PM_EVENT_RECOVER:
+ return PMSG_HIBERNATE;
+ }
+ return PMSG_ON;
+}
+
+/**
* dev_pm_may_skip_resume - System-wide device resume optimization check.
* @dev: Target device.
*
@@ -581,6 +599,14 @@ static pm_callback_t dpm_subsys_resume_n
return callback;
}
+static pm_callback_t dpm_subsys_suspend_noirq_cb(struct device *dev,
+pm_message_t state,
+const char **info_p);
+
+static pm_callback_t dpm_subsys_suspend_late_cb(struct device *dev,
+ pm_message_t state,
+
[PATCH 1/4] PM / core: Use dev_pm_skip_next_resume_phases() internally
From: Rafael J. Wysocki Make the PM core call dev_pm_skip_next_resume_phases() to skip the "early resume" and "resume" phases of system-wide transitions to the working state for a given device instead of clearing the relevant status bits for it directly. No intentional changes in functionality. Signed-off-by: Rafael J. Wysocki --- drivers/base/power/main.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: linux-pm/drivers/base/power/main.c === --- linux-pm.orig/drivers/base/power/main.c +++ linux-pm/drivers/base/power/main.c @@ -609,8 +609,7 @@ static int device_resume_noirq(struct de * device again. */ pm_runtime_set_suspended(dev); - dev->power.is_late_suspended = false; - dev->power.is_suspended = false; + dev_pm_skip_next_resume_phases(dev); } Out:
[PATCH 4/4] PM / core: Direct DPM_FLAG_LEAVE_SUSPENDED handling
From: Rafael J. Wysocki
Make the PM core handle DPM_FLAG_LEAVE_SUSPENDED directly for
devices whose "noirq", "late" and "early" driver callbacks are
invoked directly by it.
Namely, make it skip all of the system-wide resume callbacks for
such devices with DPM_FLAG_LEAVE_SUSPENDED set if they are in
runtime suspend during the "noirq" phase of system-wide suspend
(or analogous) transitions or the system transition under way is
a proper suspend (rather than anything related to hibernation) and
the device's wakeup settings are compatible with runtime PM (that
is, the device cannot generate wakeup signals at all or it is
allowed to wake up the system from sleep).
Signed-off-by: Rafael J. Wysocki
---
Documentation/driver-api/pm/devices.rst |9 +
drivers/base/power/main.c | 51 +---
2 files changed, 49 insertions(+), 11 deletions(-)
Index: linux-pm/Documentation/driver-api/pm/devices.rst
===
--- linux-pm.orig/Documentation/driver-api/pm/devices.rst
+++ linux-pm/Documentation/driver-api/pm/devices.rst
@@ -816,3 +816,12 @@ appropriate in its "noirq" resume callba
whether or not the device is left suspended, but the other resume callbacks
(except for ``->complete``) will be skipped automatically by the PM core if the
device really can be left in suspend.
+
+For devices whose "noirq", "late" and "early" driver callbacks are invoked
+directly by the PM core, all of the system-wide resume callbacks are skipped if
+``DPM_FLAG_LEAVE_SUSPENDED`` is set and the device is in runtime suspend during
+the ``suspend_noirq`` (or analogous) phase or the transition under way is a
+proper system suspend (rather than anything related to hibernation) and the
+device's wakeup settings are suitable for runtime PM (that is, it cannot
+generate wakeup signals at all or it is allowed to wake up the system from
+sleep).
Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -620,6 +620,7 @@ static int device_resume_noirq(struct de
{
pm_callback_t callback;
const char *info;
+ bool skip_resume;
int error = 0;
TRACE_DEVICE(dev);
@@ -633,10 +634,15 @@ static int device_resume_noirq(struct de
dpm_wait_for_superior(dev, async);
+ skip_resume = dev_pm_may_skip_resume(dev);
+
callback = dpm_subsys_resume_noirq_cb(dev, state, &info);
if (callback)
goto Run;
+ if (skip_resume)
+ goto Skip;
+
if (dev_pm_smart_suspend_and_suspended(dev)) {
pm_message_t suspend_msg = suspend_event(state);
@@ -651,7 +657,7 @@ static int device_resume_noirq(struct de
if (!dpm_subsys_suspend_late_cb(dev, suspend_msg, NULL) &&
!dpm_subsys_suspend_noirq_cb(dev, suspend_msg, NULL)) {
if (state.event == PM_EVENT_THAW) {
- dev_pm_skip_next_resume_phases(dev);
+ skip_resume = true;
goto Skip;
} else {
pm_runtime_set_active(dev);
@@ -670,7 +676,7 @@ Run:
Skip:
dev->power.is_noirq_suspended = false;
- if (dev_pm_may_skip_resume(dev)) {
+ if (skip_resume) {
/*
* The device is going to be left in suspend, but it might not
* have been in runtime suspend before the system suspended, so
@@ -1245,6 +1251,32 @@ static pm_callback_t dpm_subsys_suspend_
return callback;
}
+static bool device_must_resume(struct device *dev, pm_message_t state,
+ bool no_subsys_suspend_noirq)
+{
+ pm_message_t resume_msg = resume_event(state);
+
+ /*
+* If all of the device driver's "noirq", "late" and "early" callbacks
+* are invoked directly by the core, the decision to allow the device to
+* stay in suspend can be based on its current runtime PM status and its
+* wakeup settings.
+*/
+ if (no_subsys_suspend_noirq &&
+ !dpm_subsys_suspend_late_cb(dev, state, NULL) &&
+ !dpm_subsys_resume_early_cb(dev, resume_msg, NULL) &&
+ !dpm_subsys_resume_noirq_cb(dev, resume_msg, NULL))
+ return !pm_runtime_status_suspended(dev) &&
+ (resume_msg.event != PM_EVENT_RESUME ||
+(device_can_wakeup(dev) && !device_may_wakeup(dev)));
+
+ /*
+* The only safe strategy here is to require that if the device may not
+* be left in suspend, resume callbacks must be invoked for it.
+*/
+ return !dev->power.may_skip_resume;
+}
+
/**
* __device_suspend_noirq - Execute a "noirq suspend" callback for given
device.
* @dev: Device to han
[PATCH 2/4] PM / core: Add helpers for subsystem callback selection
From: Rafael J. Wysocki
Add helper routines to find and return a suitable subsystem callback
during the "noirq" phases of system suspend/resume (or analogous)
transitions as well as during the "late" phase of system suspend and
the "early" phase of system resume (or analogous) transitions.
The helpers will be called from additional sites going forward.
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Ulf Hansson
---
drivers/base/power/main.c | 188 +++---
1 file changed, 128 insertions(+), 60 deletions(-)
Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -552,6 +552,35 @@ bool dev_pm_may_skip_resume(struct devic
return !dev->power.must_resume && pm_transition.event !=
PM_EVENT_RESTORE;
}
+static pm_callback_t dpm_subsys_resume_noirq_cb(struct device *dev,
+ pm_message_t state,
+ const char **info_p)
+{
+ pm_callback_t callback;
+ const char *info;
+
+ if (dev->pm_domain) {
+ info = "noirq power domain ";
+ callback = pm_noirq_op(&dev->pm_domain->ops, state);
+ } else if (dev->type && dev->type->pm) {
+ info = "noirq type ";
+ callback = pm_noirq_op(dev->type->pm, state);
+ } else if (dev->class && dev->class->pm) {
+ info = "noirq class ";
+ callback = pm_noirq_op(dev->class->pm, state);
+ } else if (dev->bus && dev->bus->pm) {
+ info = "noirq bus ";
+ callback = pm_noirq_op(dev->bus->pm, state);
+ } else {
+ return NULL;
+ }
+
+ if (info_p)
+ *info_p = info;
+
+ return callback;
+}
+
/**
* device_resume_noirq - Execute a "noirq resume" callback for given device.
* @dev: Device to handle.
@@ -563,8 +592,8 @@ bool dev_pm_may_skip_resume(struct devic
*/
static int device_resume_noirq(struct device *dev, pm_message_t state, bool
async)
{
- pm_callback_t callback = NULL;
- const char *info = NULL;
+ pm_callback_t callback;
+ const char *info;
int error = 0;
TRACE_DEVICE(dev);
@@ -578,19 +607,7 @@ static int device_resume_noirq(struct de
dpm_wait_for_superior(dev, async);
- if (dev->pm_domain) {
- info = "noirq power domain ";
- callback = pm_noirq_op(&dev->pm_domain->ops, state);
- } else if (dev->type && dev->type->pm) {
- info = "noirq type ";
- callback = pm_noirq_op(dev->type->pm, state);
- } else if (dev->class && dev->class->pm) {
- info = "noirq class ";
- callback = pm_noirq_op(dev->class->pm, state);
- } else if (dev->bus && dev->bus->pm) {
- info = "noirq bus ";
- callback = pm_noirq_op(dev->bus->pm, state);
- }
+ callback = dpm_subsys_resume_noirq_cb(dev, state, &info);
if (!callback && dev->driver && dev->driver->pm) {
info = "noirq driver ";
@@ -705,6 +722,35 @@ void dpm_resume_noirq(pm_message_t state
dpm_noirq_end();
}
+static pm_callback_t dpm_subsys_resume_early_cb(struct device *dev,
+ pm_message_t state,
+ const char **info_p)
+{
+ pm_callback_t callback;
+ const char *info;
+
+ if (dev->pm_domain) {
+ info = "early power domain ";
+ callback = pm_late_early_op(&dev->pm_domain->ops, state);
+ } else if (dev->type && dev->type->pm) {
+ info = "early type ";
+ callback = pm_late_early_op(dev->type->pm, state);
+ } else if (dev->class && dev->class->pm) {
+ info = "early class ";
+ callback = pm_late_early_op(dev->class->pm, state);
+ } else if (dev->bus && dev->bus->pm) {
+ info = "early bus ";
+ callback = pm_late_early_op(dev->bus->pm, state);
+ } else {
+ return NULL;
+ }
+
+ if (info_p)
+ *info_p = info;
+
+ return callback;
+}
+
/**
* device_resume_early - Execute an "early resume" callback for given device.
* @dev: Device to handle.
@@ -715,8 +761,8 @@ void dpm_resume_noirq(pm_message_t state
*/
static int device_resume_early(struct device *dev, pm_message_t state, bool
async)
{
- pm_callback_t callback = NULL;
- const char *info = NULL;
+ pm_callback_t callback;
+ const char *info;
int error = 0;
TRACE_DEVICE(dev);
@@ -730,19 +776,7 @@ static int device_resume_early(struct de
dpm_wait_for_superior(dev, async);
- if (dev->pm_domain) {
- info = "early power domain ";
- callba
Re: [PATCH net-next] libbpf: add function to setup XDP
On Sat, 9 Dec 2017 15:43:15 +0100, Eric Leblond wrote:
> + for (nh = (struct nlmsghdr *)buf; NLMSG_OK(nh, len);
> + nh = NLMSG_NEXT(nh, len)) {
> + if (nh->nlmsg_pid != getpid()) {
> + ret = -LIBBPF_ERRNO__WRNGPID;
> + goto cleanup;
> + }
> + if (nh->nlmsg_seq != seq) {
> + ret = -LIBBPF_ERRNO__INVSEQ;
> + goto cleanup;
> + }
> + switch (nh->nlmsg_type) {
> + case NLMSG_ERROR:
> + err = (struct nlmsgerr *)NLMSG_DATA(nh);
> + if (!err->error)
> + continue;
> + ret = err->error;
> + goto cleanup;
> + case NLMSG_DONE:
> + break;
> + default:
> + break;
> + }
Would it be possible to print out or preferably return to the caller
the ext ack error message? A couple of drivers are using it for XDP
mis-configuration reporting instead of printks. We should encourage
other to do the same and support it in all user space since ext ack
msgs lead to much better user experience.
[PATCH 0/2] iio: magnetometer: Infineon TLV493D-A1B6 support
Hello, This mini-series adds initial support for the Infineon TLV493D-A1B6 3D Magnetic Sensor found on the Infineon 3D Magnetic Sensor 2Go Kit. Tested on a Raspberry Pi 3 with a DT Overlay. https://github.com/afaerber/dt-overlays/blob/master/bcm2837-rpi-3-b%2Btlv493d-a1b6.dts Have a lot of fun! Cheers, Andreas Cc: Marius Tarcatu Cc: devicet...@vger.kernel.org Cc: linux-...@vger.kernel.org Andreas Färber (2): dt-bindings: Add Infineon TLV493D-A1B6 iio: magnetometer: Add Infineon TLV493D-A1B6 .../devicetree/bindings/trivial-devices.txt| 1 + drivers/iio/magnetometer/Kconfig | 9 + drivers/iio/magnetometer/Makefile | 2 + drivers/iio/magnetometer/tlv493d.c | 328 + 4 files changed, 340 insertions(+) create mode 100644 drivers/iio/magnetometer/tlv493d.c -- 2.13.6
[PATCH 1/2] dt-bindings: Add Infineon TLV493D-A1B6
The Infineon TLV493D-A1B6 is an I2C-based 3D Magnetic Sensor. Cc: Marius Tarcatu Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/trivial-devices.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/trivial-devices.txt b/Documentation/devicetree/bindings/trivial-devices.txt index 5f3143f97098..7ad1939cb0d6 100644 --- a/Documentation/devicetree/bindings/trivial-devices.txt +++ b/Documentation/devicetree/bindings/trivial-devices.txt @@ -63,6 +63,7 @@ fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz) +infineon,tlv493d-a1b6 Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor isil,isl1208 Intersil ISL1208 Low Power RTC with Battery Backed SRAM isil,isl1218 Intersil ISL1218 Low Power RTC with Battery Backed SRAM isil,isl12022 Intersil ISL12022 Real-time Clock -- 2.13.6
[PATCH 2/2] iio: magnetometer: Add Infineon TLV493D-A1B6
The Infineon TLV493D is a 3D magnetic sensor, A1B6 is I2C based.
It is found among others on the Infineon 3D Magnetic Sensor 2Go Kit,
which allows to detach the sensor as a breakout board.
Cc: Marius Tarcatu
Signed-off-by: Andreas Färber
---
drivers/iio/magnetometer/Kconfig | 9 +
drivers/iio/magnetometer/Makefile | 2 +
drivers/iio/magnetometer/tlv493d.c | 328 +
3 files changed, 339 insertions(+)
create mode 100644 drivers/iio/magnetometer/tlv493d.c
diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index ed9d776d01af..5945d88a1595 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -175,4 +175,13 @@ config SENSORS_HMC5843_SPI
- hmc5843_core (core functions)
- hmc5843_spi (support for HMC5983)
+config TLV493D
+ tristate "Infineon TLV493D 3D Magnetic Sensor"
+ depends on I2C
+ help
+ Say Y here to build support for Infineon TLV493D-A1B6 I2C-based
+ 3-axis magnetometer.
+
+ This driver can also be built as a module and will be called tlv493d.
+
endmenu
diff --git a/drivers/iio/magnetometer/Makefile
b/drivers/iio/magnetometer/Makefile
index 664b2f866472..df6ad23fee65 100644
--- a/drivers/iio/magnetometer/Makefile
+++ b/drivers/iio/magnetometer/Makefile
@@ -24,3 +24,5 @@ obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o
obj-$(CONFIG_SENSORS_HMC5843) += hmc5843_core.o
obj-$(CONFIG_SENSORS_HMC5843_I2C) += hmc5843_i2c.o
obj-$(CONFIG_SENSORS_HMC5843_SPI) += hmc5843_spi.o
+
+obj-$(CONFIG_TLV493D) += tlv493d.o
diff --git a/drivers/iio/magnetometer/tlv493d.c
b/drivers/iio/magnetometer/tlv493d.c
new file mode 100644
index ..d2fe296b2c80
--- /dev/null
+++ b/drivers/iio/magnetometer/tlv493d.c
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Infineon TLV493D-A1B6 3D magnetic sensor
+ *
+ * Copyright (c) 2016-2017 Andreas Färber
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MOD1_LOW BIT(0)
+#define MOD1_FAST BIT(1)
+#define MOD1_INT BIT(2)
+#define MOD1_P BIT(7)
+
+#define MOD2_PTBIT(5)
+
+struct tlv493d {
+ struct i2c_client *i2c;
+ struct iio_mount_matrix mount_matrix;
+ u8 factset1, factset2, factset3;
+};
+
+static int tlv493d_read_regs(struct tlv493d *s, u8 *buf, int len)
+{
+ int ret;
+
+ ret = i2c_master_recv(s->i2c, buf, len);
+ if (ret < len) {
+ dev_err(&s->i2c->dev, "failed to read registers (%d)", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static unsigned int tlv493d_parity(u32 v)
+{
+ v ^= v >> 16;
+ v ^= v >> 8;
+ v ^= v >> 4;
+ v &= 0xf;
+ return (0x6996 >> v) & 1;
+}
+
+#define MOD1_RES_MASK (0x3 << 3)
+#define MOD1_IICADDR_MASK (0x3 << 5)
+
+static int tlv493d_write_regs(struct tlv493d *s, const u8 *regs, int len)
+{
+ u8 buf[4];
+ int ret;
+
+ if (len != ARRAY_SIZE(buf))
+ return -EINVAL;
+
+ buf[0] = 0;
+ buf[1] = s->factset1 & (MOD1_IICADDR_MASK | MOD1_RES_MASK);
+ buf[1] |= regs[1] & ~(MOD1_P | MOD1_IICADDR_MASK | MOD1_RES_MASK);
+ buf[2] = s->factset2;
+ buf[3] = MOD2_PT | (s->factset3 & 0x1f);
+ buf[3] |= regs[3] & ~(MOD2_PT | 0x1f);
+
+ if ((buf[3] & MOD2_PT) &&
+ !tlv493d_parity((buf[0] << 24) | (buf[1] << 16) | (buf[2] << 8) |
buf[3]))
+ buf[1] |= MOD1_P;
+
+ ret = i2c_master_send(s->i2c, buf, 4);
+ if (ret < 4) {
+ dev_err(&s->i2c->dev, "failed to write registers (%d)", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int tlv493d_power_down(struct tlv493d *s)
+{
+ u8 buf[4];
+
+ buf[0] = 0;
+ buf[1] = 0;
+ buf[2] = 0;
+ buf[3] = 0;
+ return tlv493d_write_regs(s, buf, 4);
+}
+
+static const struct iio_mount_matrix *
+tlv493d_get_mount_matrix(const struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan)
+{
+ struct tlv493d *s = iio_priv(indio_dev);
+
+ return &s->mount_matrix;
+}
+
+static const struct iio_chan_spec_ext_info tlv493d_ext_info[] = {
+ IIO_MOUNT_MATRIX(IIO_SHARED_BY_DIR, tlv493d_get_mount_matrix),
+ {}
+};
+
+#define TLV493D_AXIS_CHANNEL(axis, index) \
+ { \
+ .type = IIO_MAGN, \
+ .channel2 = IIO_MOD_##axis, \
+ .modified = 1, \
+ .address = index, \
+ .scan_index = index,\
+ .scan_type = { \
+ .sign = 's',\
+ .realbits = 12,
[PATCH] mm/slab: make calculate_alignment() function static
calculate_alignment() function is only used inside 'slab_common.c'.
So make it static and let compiler do more optimizations.
After this patch there's small improvements in 'text' and 'data' size.
$ gcc --version
gcc (GCC) 7.2.1 20171128
Before:
text data bss dec hexfilename
9890457 3828702 1212364 14931523 e3d643 vmlinux
After:
text data bss dec hexfilename
9890437 3828670 1212364 14931471 e3d60f vmlinux
Also I fixed a 'style problem' reported by 'scripts/checkpatch.pl'.
WARNING: Missing a blank line after declarations
#53: FILE: mm/slab_common.c:286:
+ unsigned long ralign = cache_line_size();
+ while (size <= ralign / 2)
Signed-off-by: Byongho Lee
---
mm/slab.h| 3 ---
mm/slab_common.c | 56 +---
2 files changed, 29 insertions(+), 30 deletions(-)
diff --git a/mm/slab.h b/mm/slab.h
index 028cdc7df67e..e894889dc24a 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -79,9 +79,6 @@ extern const struct kmalloc_info_struct {
unsigned long size;
} kmalloc_info[];
-unsigned long calculate_alignment(unsigned long flags,
- unsigned long align, unsigned long size);
-
#ifndef CONFIG_SLOB
/* Kmalloc array related functions */
void setup_kmalloc_cache_index_table(void);
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 0d7fe71ff5e4..d25e7b56e20b 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -267,6 +267,35 @@ static inline void memcg_unlink_cache(struct kmem_cache *s)
}
#endif /* CONFIG_MEMCG && !CONFIG_SLOB */
+/*
+ * Figure out what the alignment of the objects will be given a set of
+ * flags, a user specified alignment and the size of the objects.
+ */
+static unsigned long calculate_alignment(unsigned long flags,
+ unsigned long align, unsigned long size)
+{
+ /*
+* If the user wants hardware cache aligned objects then follow that
+* suggestion if the object is sufficiently large.
+*
+* The hardware cache alignment cannot override the specified
+* alignment though. If that is greater then use it.
+*/
+ if (flags & SLAB_HWCACHE_ALIGN) {
+ unsigned long ralign;
+
+ ralign = cache_line_size();
+ while (size <= ralign / 2)
+ ralign /= 2;
+ align = max(align, ralign);
+ }
+
+ if (align < ARCH_SLAB_MINALIGN)
+ align = ARCH_SLAB_MINALIGN;
+
+ return ALIGN(align, sizeof(void *));
+}
+
/*
* Find a mergeable slab cache
*/
@@ -337,33 +366,6 @@ struct kmem_cache *find_mergeable(size_t size, size_t
align,
return NULL;
}
-/*
- * Figure out what the alignment of the objects will be given a set of
- * flags, a user specified alignment and the size of the objects.
- */
-unsigned long calculate_alignment(unsigned long flags,
- unsigned long align, unsigned long size)
-{
- /*
-* If the user wants hardware cache aligned objects then follow that
-* suggestion if the object is sufficiently large.
-*
-* The hardware cache alignment cannot override the specified
-* alignment though. If that is greater then use it.
-*/
- if (flags & SLAB_HWCACHE_ALIGN) {
- unsigned long ralign = cache_line_size();
- while (size <= ralign / 2)
- ralign /= 2;
- align = max(align, ralign);
- }
-
- if (align < ARCH_SLAB_MINALIGN)
- align = ARCH_SLAB_MINALIGN;
-
- return ALIGN(align, sizeof(void *));
-}
-
static struct kmem_cache *create_cache(const char *name,
size_t object_size, size_t size, size_t align,
unsigned long flags, void (*ctor)(void *),
--
2.15.1
[alsa-devel][PATCH v3] ASoC: TSCS42xx: Add support for Tempo Semiconductor's TSCS42xx audio CODEC
Currently there is no support for the TSCS42xx audio CODEC.
Add support for it.
Below is the link to the v2 patch in case the threading is broken. This
patch addressed each issue raised in the last review.
https://patchwork.kernel.org/patch/10058117/
Signed-off-by: Steven Eckhoff
Cc: Steven Eckhoff
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
.../devicetree/bindings/sound/tscs42xx.txt | 15 +
.../devicetree/bindings/vendor-prefixes.txt|1 +
MAINTAINERS|5 +
sound/soc/codecs/Kconfig |8 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tscs42xx.c| 1571
sound/soc/codecs/tscs42xx.h| 2693
7 files changed, 4295 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tscs42xx.txt
create mode 100644 sound/soc/codecs/tscs42xx.c
create mode 100644 sound/soc/codecs/tscs42xx.h
diff --git a/Documentation/devicetree/bindings/sound/tscs42xx.txt
b/Documentation/devicetree/bindings/sound/tscs42xx.txt
new file mode 100644
index ..da8ea96f4cf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tscs42xx.txt
@@ -0,0 +1,15 @@
+TSCS42XX Audio CODEC
+
+Required Properties:
+
+ - compatible : "tscs:tscs42xx"
+
+ - reg : The I2C address of the device
+
+Example:
+
+codec: tscs42xx@69 {
+ compatible = "tscs,tscs42xx";
+ reg = <0x69>;
+ status = "okay";
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0994bdd82cd3..6ee98ba258ca 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -363,6 +363,7 @@ tpo TPO
tronfy Tronfy
tronsmart Tronsmart
truly Truly Semiconductors Limited
+tscs Tempo Semiconductor
tsdTheobroma Systems Design und Consulting GmbH
tyan Tyan Computer Corporation
ucrobotics uCRobotics
diff --git a/MAINTAINERS b/MAINTAINERS
index 9e0045e3ee0c..dbcf1cedda91 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13850,6 +13850,11 @@ T: git
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git
S: Maintained
K: ^Subject:.*(?i)trivial
+TEMPO SEMICONDUCTOR DRIVERS
+M: Steven Eckhoff
+S: Maintained
+F: sound/soc/codecs/tscs42xx.*
+
TTY LAYER
M: Greg Kroah-Hartman
M: Jiri Slaby
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index a42ddbc93f3d..d2f65c37464a 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -158,6 +158,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TPA6130A2 if I2C
select SND_SOC_TLV320DAC33 if I2C
+ select SND_SOC_TSCS42XX if I2C
select SND_SOC_TS3A227E if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_TWL6040 if TWL6040_CORE
@@ -929,6 +930,13 @@ config SND_SOC_TLV320AIC3X
config SND_SOC_TLV320DAC33
tristate
+config SND_SOC_TSCS42XX
+ tristate "Tempo Semiconductor TSCS42xx CODEC"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Add support for Tempo Semiconductor's TSCS42xx audio CODEC.
+
config SND_SOC_TS3A227E
tristate "TI Headset/Mic detect and keypress chip"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 0001069ce2a7..ded86bceca37 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -167,6 +167,7 @@ snd-soc-tlv320aic32x4-i2c-objs := tlv320aic32x4-i2c.o
snd-soc-tlv320aic32x4-spi-objs := tlv320aic32x4-spi.o
snd-soc-tlv320aic3x-objs := tlv320aic3x.o
snd-soc-tlv320dac33-objs := tlv320dac33.o
+snd-soc-tscs42xx-objs := tscs42xx.o
snd-soc-ts3a227e-objs := ts3a227e.o
snd-soc-twl4030-objs := twl4030.o
snd-soc-twl6040-objs := twl6040.o
@@ -406,6 +407,7 @@ obj-$(CONFIG_SND_SOC_TLV320AIC32X4_I2C) +=
snd-soc-tlv320aic32x4-i2c.o
obj-$(CONFIG_SND_SOC_TLV320AIC32X4_SPI)+= snd-soc-tlv320aic32x4-spi.o
obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o
obj-$(CONFIG_SND_SOC_TLV320DAC33) += snd-soc-tlv320dac33.o
+obj-$(CONFIG_SND_SOC_TSCS42XX) += snd-soc-tscs42xx.o
obj-$(CONFIG_SND_SOC_TS3A227E) += snd-soc-ts3a227e.o
obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o
obj-$(CONFIG_SND_SOC_TWL6040) += snd-soc-twl6040.o
diff --git a/sound/soc/codecs/tscs42xx.c b/sound/soc/codecs/tscs42xx.c
new file mode 100644
index ..cc849aa15bef
--- /dev/null
+++ b/sound/soc/codecs/tscs42xx.c
@@ -0,0 +1,1571 @@
+/*
+ * tscs42xx.c -- TSCS42xx ALSA SoC Audio driver
+ *
+ * Copyright 2017 Tempo Semiconductor, Inc.
+ *
+ * Author: Steven Eckhoff
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms o
Re: [PATCH] usb-core: Fix potential null pointer dereference in xhci-debugfs.c
Hi Mathias, thanks for the patch! The system now resumes cleanly from hibernate even with usbmuxd doing its thing. Tested-by: Alexander Kappner While testing this I hit some other issues with xhci-debugfs.c but I'll write these up in a separate bug. On 12/08/2017 09:01 AM, Mathias Nyman wrote: On 08.12.2017 13:06, Alexander Kappner wrote: Hi, I think we need to dig a bit deeper. It's good to check if spriv is valid but there are probably other reasons than kzalloc failing. I agree -- this small allocation is unlikely to fail in practice. Also, while my patch prevents the kernel oops, it also prevents the debugfs entries from being created. I've been debugging this more trying to come up with a better solution, but I might need some guidance as I'm not too familiar with the USB subsystem. The immediate cause of the crash was usbmuxd sending a USBDEVFS_SETCONFIGURATION ioctl to a device, which _only if it fails_ calls usb_hcd_alloc_bandwidth to try and reset the device, which in turn calls xhci_debugfs_create_endpoint. The ioctl handler acquires a device-specific lock via usb_lock_device. When the system resumed from hibernate, xhci_resume was called. This in turn called xhci_mem_cleanup to deallocate the device structures, which include setting the debugfs_private pointer to NULL (via xhci_free_virt_devices_depth_first). It thus seems likely that the ioctl is somehow racing with the hibernate. The call to xhci_resume is protected by a host-controller specific lock (xhci->lock) but it doesn't attempt to take the usb_lock_device device-specific lock. Now my suspicion is that xhci_resume freed and zeroed the device structures while racing with the ioctl handler. I can't seem to find any exclusion mechanism that would prevent xhci_resume from racing with the USBDEVFS_SETCONFIGURATION ioctl (or any other ioctl, for that matter). Am I missing something? If not, is there any reason why an ioctl might need to execute in parallel with the xhci_resume? If not, can we just do a busy wait in xhci_resume until all pending ioctls have returned? I'm not sure, but if I recall correctly then power management is supposed to make sure a driver doesn't access usb devices while the host controller is still resuming. The odd thing here is that xhci_debugfs_remove_slot(xhci, slot_id), and xhci_free_virt_device(xhci, slot_id) are called together when xhci_mem_cleanup() calls xhci_free_virt_devices_depth_first() That means both the xhci_virt_device *dev and dev->debugfs_private should both be freed and xhci->devs[slot_id] set NULL for that virt_device. so xhci_add_endpoint() should fail a lot earlier because the xhci->devs[slot_id] should be a null pointer as well. Allocation is also done together in xhci_alloc_dev() Looking at it more closely there is actually the .free_dev callback that first frees the dev->debugs_private but the virt_dev is only freed conditionally later Attached a patch that frees them together, can you try it out? If it doesn't help we need to add some elaborate tracing Thanks -Mathias
Re: Linux 4.15-rc2: Regression in resume from ACPI S3
Hi! On Sat 2017-12-09 10:55:14, Linus Torvalds wrote: > On Dec 9, 2017 02:33, "Pavel Machek" wrote: > > > I believe I have the issue here, too (-next on thinkpad x60). Which > > patch is expected to fix it? Let me try recent -next... > > > It should be fixed in mainline. I don't know if next has picked it > up yet. Strange. I was at 4.15-rc1, and suspend worked there (thinkpad x60, 32-bit). It was broken in -next. I updated to current mainline ( 4ded3bec65a07343258ed8fd9d46483f032d866f ) and suspend is broken. It suspends ok, I press Fn button to make it resume, fans spin up but moon LED is still lit. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v2] fs: handle shrinker registration failure in sget_userns
On Sat, Dec 09, 2017 at 08:59:22PM +, Al Viro wrote:
> On Wed, Nov 29, 2017 at 12:55:15PM +0100, Michal Hocko wrote:
> > On Thu 23-11-17 14:55:40, Al Viro wrote:
> > > On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote:
> > > > Hopefully less screwed version. But as I've said I am not really
> > > > familiar with the code and do not feel competent to change it so please
> > > > be very careful here. I've moved the shrinker registration to
> > > > alloc_super which turned out to be simpler.
> > >
> > > I don't get it. Why the hell do we need all that PITA in the first place?
> > > Just make sget_userns() end with
> > > if (unlikely(regsiter_shrinker(&s->s_shrink) != 0)) {
> > > deactivate_locked_super(s);
> > > s = ERR_PTR(-ENOMEM);
> > > }
> > > return s;
> > > and be done with that. All there is to it...
> >
> > Al, do you plan to push this fix? Tetsuo's unregister_shrinker
> > fortification is already in the mmotm tree.
>
> Is it in any git branch I could pull from? Or I could just throw it
> into vfs.git#for-linus before the fix above - up to you, folks...
Actually, looking at mmotm... I don't see it there. Which patch
is it in?
Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?
On Sat, 2017-12-09 at 13:03 -0800, Matt Turner wrote: > On Fri, Dec 8, 2017 at 1:16 PM, Eric Dumazet > wrote: > > On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: > > > > > > Thanks for the quick reply! > > > > > > I tried the patch on top of master, but unfortunately the > > > corruption > > > still occurs. > > > > You might try replacing in sbdma_add_rcvbuffer() > > > > sb_new = netdev_alloc_skb(dev, size); > > > > by > > > > sb_new = alloc_skb(size, GFP_ATOMIC); > > > > Maybe the device does not like having a frame spanning 2 pages. > > No such luck. I also gave changing the page size from 16K to 4K a > shot > without success. If your hist is SMP, could you try running it with one CPU only ? Sorry, I have no more ideas :/
Re: [PATCH 1/2] platform/x86: wmi: prefix sysfs files in /sys/bus/wmi with the ACPI device
On Fri, Dec 8, 2017 at 7:41 PM, wrote: >>> On Dec 8, 2017, at 6:34 PM, Mario Limonciello >>> wrote: >>> >>> It's possible for the same GUID to show up on as system twice. >>> This means using solely the GUID for identify the file will not >>> be sufficient. >> >>Isn't the file already in a per-bus directory? > > Yep, but the symlink created in /sys/bus/wmi/devices isn't. > That's where the kernel complains about duplicate sysfs > attributes. > > It's not exactly a pretty path I submitted, but it does avoid > those collisions. > > Example (with this in place from /sys/bus/wmi/devices): > lrwxrwxrwx 1 root root 0 Dec 8 21:39 > PNP0C14:04-70FE8229-D03B-4214-A1C6-1F884B1A892A -> > ../../../devices/platform/PNP0C14:04/wmi_bus/wmi_bus-PNP0C14:04/PNP0C14:04-70FE8229-D03B-4214-A1C6-1F884B1A892A Right, I saw that in the cover letter right after sending this. Greg, is there a cleaner way to deal with this? There are two instances of the same bus type, each of which would like to have a device called "70FE8229-D03B-4214-A1C6-1F884B1A892A". Can we somehow rename the symlinks without renaming the device, or are we just supposed to prefix the device name like Mario is doing here?
Re: [PATCH v8 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver
On 12/08/2017 12:04 AM, Dan Murphy wrote:
> Rob
>
>
> On 12/07/2017 04:49 PM, Rob Herring wrote:
>> On Tue, Dec 05, 2017 at 02:46:29PM -0600, Dan Murphy wrote:
>>> This adds the devicetree bindings for the LM3692x
>>> I2C LED string driver.
>>>
>>> Acked-by: Pavel Machek
>>> Signed-off-by: Dan Murphy
>>> ---
>>>
>>> v8 - Added address-cells and size-cells as well as child node reg -
>>> https://patchwork.kernel.org/patch/10091259/
>>> v7 - No changes - https://patchwork.kernel.org/patch/10087475/
>>> v6 - No changes -https://patchwork.kernel.org/patch/10085567/
>>> v5 - No Changes - https://patchwork.kernel.org/patch/10081071/
>>> v4 - Fix example node, added trigger entry, removed ambiguous x for
>>> compatible and
>>> added common.txt pointer for label -
>>> https://patchwork.kernel.org/patch/10060107
>>> v3 - No changes
>>> v2 - No changes - https://patchwork.kernel.org/patch/10056677/
>>>
>>> .../devicetree/bindings/leds/leds-lm3692x.txt | 47
>>> ++
>>> 1 file changed, 47 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3692x.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
>>> b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
>>> new file mode 100644
>>> index ..84f69342d879
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
>>> @@ -0,0 +1,47 @@
>>> +* Texas Instruments - LM3692x Highly Efficient White LED Driver
>>> +
>>> +The LM3692x is an ultra-compact, highly efficient,
>>> +white-LED driver designed for LCD display backlighting.
>>> +
>>> +The main difference between the LM36922 and LM36923 is the number of
>>> +LED strings it supports. The LM36922 supports two strings while the
>>> LM36923
>>> +supports three strings.
>>> +
>>> +Required properties:
>>> + - compatible:
>>> + "ti,lm36922"
>>> + "ti,lm36923"
>>> + - reg : I2C slave address
>>> + - #address-cells : 1
>>> + - #size-cells : 0
>>> +
>>> +Optional properties:
>>> + - label : see Documentation/devicetree/bindings/leds/common.txt
>>
>> Should be a child prop.
>
> Thanks I forgot to move this to Optional Child Properties.
>
>>
>>> + - enable-gpios : gpio pin to enable/disable the device.
>>> + - vled-supply : LED supply
>>> + - linux,default-trigger : (optional)
>>> + see Documentation/devicetree/bindings/leds/common.txt
>>
>> Ditto.
>
> Ack
>
>>
>>> +
>>> +Required child properties:
>>> + - reg : 0
>>> +
>>> +Example:
>>> +
>>> +lm3692x@36 {
>>
>> leds@36
>
> Rob why does this need to be leds? Is this because it would be a child of an
> I2C node?
>
> Jacek
> Would this not cause and issue for your proposal to take the parent node name
> as part of the LED label?
Yes, it would.
Rob, does something prevent us from adding a requirement that
LED controller DT node has to contain the chip name (besides the
unit address)? Many current LED controller nodes apply this pattern.
Also, I would appreciate if you could express your opinion on
the patch [0].
[0] https://patchwork.kernel.org/patch/10089047/
--
Best regards,
Jacek Anaszewski
[PATCH] serial: bfin_uart: Delete an error message for a failed memory allocation in bfin_serial_probe()
From: Markus Elfring
Date: Sat, 9 Dec 2017 22:05:54 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/tty/serial/bfin_uart.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/bfin_uart.c b/drivers/tty/serial/bfin_uart.c
index 4755fa696321..558f6ebc4f01 100644
--- a/drivers/tty/serial/bfin_uart.c
+++ b/drivers/tty/serial/bfin_uart.c
@@ -1221,11 +1221,9 @@ static int bfin_serial_probe(struct platform_device
*pdev)
if (bfin_serial_ports[pdev->id] == NULL) {
uart = kzalloc(sizeof(*uart), GFP_KERNEL);
- if (!uart) {
- dev_err(&pdev->dev,
- "fail to malloc bfin_serial_port\n");
+ if (!uart)
return -ENOMEM;
- }
+
bfin_serial_ports[pdev->id] = uart;
#ifdef CONFIG_EARLY_PRINTK
--
2.15.1
Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?
On Fri, Dec 8, 2017 at 1:16 PM, Eric Dumazet wrote: > On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: >> >> Thanks for the quick reply! >> >> I tried the patch on top of master, but unfortunately the corruption >> still occurs. > > You might try replacing in sbdma_add_rcvbuffer() > > sb_new = netdev_alloc_skb(dev, size); > > by > > sb_new = alloc_skb(size, GFP_ATOMIC); > > Maybe the device does not like having a frame spanning 2 pages. No such luck. I also gave changing the page size from 16K to 4K a shot without success.
Re: [PATCH 4.4 71/96] e1000e: Separate signaling for link check/link up
Hallo with this patch from here: https://marc.info/?l=linux-kernel&m=151272209903675&w=2 e1000e is great again ! :) tested 4.14.5-rc1 -- Greeting Ronald
Re: [PATCH v2] fs: handle shrinker registration failure in sget_userns
On Wed, Nov 29, 2017 at 12:55:15PM +0100, Michal Hocko wrote:
> On Thu 23-11-17 14:55:40, Al Viro wrote:
> > On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote:
> > > Hopefully less screwed version. But as I've said I am not really
> > > familiar with the code and do not feel competent to change it so please
> > > be very careful here. I've moved the shrinker registration to
> > > alloc_super which turned out to be simpler.
> >
> > I don't get it. Why the hell do we need all that PITA in the first place?
> > Just make sget_userns() end with
> > if (unlikely(regsiter_shrinker(&s->s_shrink) != 0)) {
> > deactivate_locked_super(s);
> > s = ERR_PTR(-ENOMEM);
> > }
> > return s;
> > and be done with that. All there is to it...
>
> Al, do you plan to push this fix? Tetsuo's unregister_shrinker
> fortification is already in the mmotm tree.
Is it in any git branch I could pull from? Or I could just throw it
into vfs.git#for-linus before the fix above - up to you, folks...
Re: [PATCH 2/2] platform/x86: wmi: Allow creating WMI devices with the same GUID
On Fri, Dec 8, 2017 at 6:34 PM, Mario Limonciello
wrote:
> In: commit d1f9e4970742 ("ACPI: WMI: Survive BIOS with duplicate GUIDs")
> parsing two of the same GUID was prevented in the WMI bus driver.
>
> At the time no one understood why GUID 05901221-D566-11D1-B2F0-00A0C9062910
> was being duplicated. It's now known that GUID is used for the binary
> MOF file of a _WDG entry in the ASL. It's entirely possible for multiple
> _WDG entries and for multiple instances to bind in a given driver.
>
> NOTE:
> The only known instance of duplicated GUID's is the WMI BMOF GUID above,
> but it is possible that other vendors may duplicate GUIDs as well. It
> would be better for drivers to not interact with the WMI bus by GUID
> string but by the struct wmi_device provided by the WMI bus during
> probing.
I think you also need to audit all the users of wmi_block_list for
duplicate handling. For example, wmi_install_notify_handler()
probably needs a break statement inside the if (memcmp(...)).
>
> Signed-off-by: Mario Limonciello
> ---
> drivers/platform/x86/wmi.c | 31 ---
> 1 file changed, 31 deletions(-)
>
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index 45d9010aafcf..5ac17e360fa2 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -1102,28 +1102,6 @@ static void wmi_free_devices(struct acpi_device
> *device)
> }
> }
>
> -static bool guid_already_parsed(struct acpi_device *device,
> - const u8 *guid)
> -{
> - struct wmi_block *wblock;
> -
> - list_for_each_entry(wblock, &wmi_block_list, list) {
> - if (memcmp(wblock->gblock.guid, guid, 16) == 0) {
> - /*
> -* Because we historically didn't track the
> relationship
> -* between GUIDs and ACPI nodes, we don't know whether
> -* we need to suppress GUIDs that are unique on a
> -* given node but duplicated across nodes.
> -*/
> - dev_warn(&device->dev, "duplicate WMI GUID %pUL
> (first instance was on %s)\n",
> -guid, dev_name(&wblock->acpi_device->dev));
> - return true;
> - }
> - }
> -
> - return false;
> -}
> -
> /*
> * Parse the _WDG method for the GUID data blocks
> */
> @@ -1157,15 +1135,6 @@ static int parse_wdg(struct device *wmi_bus_dev,
> struct acpi_device *device)
> if (debug_dump_wdg)
> wmi_dump_wdg(&gblock[i]);
>
> - /*
> -* Some WMI devices, like those for nVidia hooks, have a
> -* duplicate GUID. It's not clear what we should do in this
> -* case yet, so for now, we'll just ignore the duplicate
> -* for device creation.
> -*/
> - if (guid_already_parsed(device, gblock[i].guid))
> - continue;
> -
> wblock = kzalloc(sizeof(struct wmi_block), GFP_KERNEL);
> if (!wblock) {
> retval = -ENOMEM;
> --
> 2.14.1
>
[PATCH] serial: fsl_lpuart: Delete an error message for a failed memory allocation in lpuart_start_rx_dma()
From: Markus Elfring
Date: Sat, 9 Dec 2017 21:34:23 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/tty/serial/fsl_lpuart.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index c84e6f0db54e..694751ebabf4 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -998,10 +998,8 @@ static inline int lpuart_start_rx_dma(struct lpuart_port
*sport)
sport->rx_dma_rng_buf_len = 16;
ring->buf = kmalloc(sport->rx_dma_rng_buf_len, GFP_ATOMIC);
- if (!ring->buf) {
- dev_err(sport->port.dev, "Ring buf alloc failed\n");
+ if (!ring->buf)
return -ENOMEM;
- }
sg_init_one(&sport->rx_sgl, ring->buf, sport->rx_dma_rng_buf_len);
sg_set_buf(&sport->rx_sgl, ring->buf, sport->rx_dma_rng_buf_len);
--
2.15.1
[PATCH v3] Staging: pi433: fix brace coding style issues in pi433_if.c
This patch fix several brace on next line, braces not necessary, space
around =/<, and space before/after open/close parenthesis coding style
errors find by checkpatch in pi433_if.c.
Signed-off-by: Tomas Marek
---
Changes in v3:
- DIO0_irq_handler update reverted - will be submitted in separate
patch for the sake of clarity.
Changes in v2:
- DIO0_irq_handler updated - 'if/else if' replaced by 'switch' and
'dev_dbg_ratelimited' used instead of 'dev_dbg' according to Joe
Perches suggestion.
- The removal of braces around SET_CHECKED() reverted - caused syntax
error and is addressed by another patch
"[PATCHv2] staging: pi433: pi433_if.c remove SET_CHECKED macro".
---
drivers/staging/pi433/pi433_if.c | 84 +---
1 file changed, 27 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 55ed45f..9822fb8 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -158,12 +158,9 @@ static irqreturn_t DIO1_irq_handler(int irq, void *dev_id)
{
struct pi433_device *device = dev_id;
- if (device->irq_state[DIO1] == DIO_FIFO_NOT_EMPTY_DIO1)
- {
+ if (device->irq_state[DIO1] == DIO_FIFO_NOT_EMPTY_DIO1) {
device->free_in_fifo = FIFO_SIZE;
- }
- else if (device->irq_state[DIO1] == DIO_FIFO_LEVEL)
- {
+ } else if (device->irq_state[DIO1] == DIO_FIFO_LEVEL) {
if (device->rx_active) device->free_in_fifo = FIFO_THRESHOLD -
1;
elsedevice->free_in_fifo = FIFO_SIZE -
FIFO_THRESHOLD - 1;
}
@@ -236,19 +233,14 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
/* lengths */
SET_CHECKED(rf69_set_sync_size(dev->spi, rx_cfg->sync_length));
- if (rx_cfg->enable_length_byte == OPTION_ON)
- {
+ if (rx_cfg->enable_length_byte == OPTION_ON) {
SET_CHECKED(rf69_set_payload_length(dev->spi, 0xff));
- }
- else if (rx_cfg->fixed_message_length != 0)
- {
+ } else if (rx_cfg->fixed_message_length != 0) {
payload_length = rx_cfg->fixed_message_length;
if (rx_cfg->enable_length_byte == OPTION_ON) payload_length++;
if (rx_cfg->enable_address_filtering != filteringOff)
payload_length++;
SET_CHECKED(rf69_set_payload_length(dev->spi, payload_length));
- }
- else
- {
+ } else {
SET_CHECKED(rf69_set_payload_length(dev->spi, 0));
}
@@ -257,8 +249,7 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
{
SET_CHECKED(rf69_set_sync_values(dev->spi,
rx_cfg->sync_pattern));
}
- if (rx_cfg->enable_address_filtering != filteringOff)
- {
+ if (rx_cfg->enable_address_filtering != filteringOff) {
SET_CHECKED(rf69_set_node_address (dev->spi,
rx_cfg->node_address));
SET_CHECKED(rf69_set_broadcast_address(dev->spi,
rx_cfg->broadcast_address));
}
@@ -394,8 +385,7 @@ pi433_receive(void *data)
return retval;
/* now check RSSI, if low wait for getting high (RSSI interrupt) */
- while ( !rf69_get_flag(dev->spi, rssiExceededThreshold) )
- {
+ while (!rf69_get_flag(dev->spi, rssiExceededThreshold)) {
/* allow tx to interrupt us while waiting for high RSSI */
dev->interrupt_rx_allowed = true;
wake_up_interruptible(&dev->tx_wait_queue);
@@ -418,25 +408,20 @@ pi433_receive(void *data)
irq_set_irq_type(dev->irq_num[DIO0], IRQ_TYPE_EDGE_RISING);
/* fixed or unlimited length? */
- if (dev->rx_cfg.fixed_message_length != 0)
- {
- if (dev->rx_cfg.fixed_message_length > dev->rx_buffer_size)
- {
+ if (dev->rx_cfg.fixed_message_length != 0) {
+ if (dev->rx_cfg.fixed_message_length > dev->rx_buffer_size) {
retval = -1;
goto abort;
}
bytes_total = dev->rx_cfg.fixed_message_length;
dev_dbg(dev->dev,"rx: msg len set to %d by fixed length",
bytes_total);
- }
- else
- {
+ } else {
bytes_total = dev->rx_buffer_size;
dev_dbg(dev->dev, "rx: msg len set to %d as requested by read",
bytes_total);
}
/* length byte enabled? */
- if (dev->rx_cfg.enable_length_byte == OPTION_ON)
- {
+ if (dev->rx_cfg.enable_length_byte == OPTION_ON) {
retval = wait_event_interruptible(dev->fifo_wait_queue,
dev->free_in_fifo <
FIFO_SIZE);
if (retval) goto abort; /* wait was interrupted */
@@ -451,8 +436,7 @@ pi433_receive(void *data)
}
/* address byte
Re: Wireless regressions in v4.15-rc1
On Sat, 2017-12-02 at 14:59 +0200, Kalle Valo wrote: > > net: netlink: Update attr validation to require exact length for some types > https://git.kernel.org/linus/28033ae4e0f5 This was reverted, more or less, to print only a warning: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=6e237d099fac1f73a7b6d7287bb9191f29585a4e > Jouni fixed this already in hostapd but we also need a fix for kernel so > that old hostapd versions continue to work: > > https://w1.fi/cgit/hostap/commit/?id=a2426829ce426de82d2fa47071ca41ea81c43307 > > Jouni also found a similar problem with mesh: > > https://w1.fi/cgit/hostap/commit/?id=963d3149abfcbab5b83f9023bc50321f777360d1 See above for the kernel revert to let old hostapd versions continue to work (properly only on little endian platforms) when they don't have these fixes. > And Johannes already submitted a revert related to wpa_supplicant: > > [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" > diffmboxseries > https://patchwork.ozlabs.org/patch/843863/ That was applied. > And with ath10k I'm now seeing this: > > [ 133.175508] WARNING: CPU: 2 PID: 1743 at net/mac80211/agg-tx.c:315 > ___ieee80211_stop_tx_ba_session+0x1ab/0x280 [mac80211] Just sent a fix for this, kinda a merge/patch failure. > johannes
[PATCH] i2c: update i2c-dev.h warning in documentation
`dev-interface` document gives examples for accessing i2c from
userspace.
There's a note warning developers about the different `i2c-dev.h` header
files which were shipped with the kernel and i2c-tools separately.
However, these commits in i2c-tools repository suggests that the header
files are now identical (in functionality) and `i2c_*` functions are now
defined in a separate header called `i2c/smbus.h`, which is distributed
with i2c-tools:
commit 652619121974 ("Minimize differences with kernel flavor")
commit 93caf007f4cb ("Move SMBus helper functions to include/i2c/smbus.h")
Thus, I've converted the warning paragraph into a historical note and
updated the suggested header files.
Signed-off-by: Cengiz Can
---
Sorry for duplicate mails. My email client hard-wrapped previous patch.
Thanks.
Documentation/i2c/dev-interface | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index 5ff19447ac44..04d110697863 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -9,21 +9,24 @@ i2c adapters present on your system at a given time.
i2cdetect is part of
the i2c-tools package.
I2C device files are character device files with major device number 89
-and a minor device number corresponding to the number assigned as
-explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
+and a minor device number corresponding to the number assigned as
+explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
i2c-10, ...). All 256 minor device numbers are reserved for i2c.
C example
=
-So let's say you want to access an i2c adapter from a C program. The
-first thing to do is "#include ". Please note that
-there are two files named "i2c-dev.h" out there, one is distributed
-with the Linux kernel and is meant to be included from kernel
-driver code, the other one is distributed with i2c-tools and is
-meant to be included from user-space programs. You obviously want
-the second one here.
+So let's say you want to access an i2c adapter from a C program. First, you
+need to include these two headers:
+
+ #include
+ #include
+
+(Please note that there are two files named "i2c-dev.h" out there. One is
+distributed with the Linux kernel and the other one is included in the
+source tree of i2c-tools. They used to be different in content but since 2012
+they're identical. You should use "linux/i2c-dev.h").
Now, you have to decide which adapter you want to access. You should
inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
@@ -35,7 +38,7 @@ Next thing, open the device file, as follows:
int file;
int adapter_nr = 2; /* probably dynamically determined */
char filename[20];
-
+
snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
file = open(filename, O_RDWR);
if (file < 0) {
@@ -69,7 +72,7 @@ the device supports them. Both are illustrated below.
/* res contains the read word */
}
- /* Using I2C Write, equivalent of
+ /* Using I2C Write, equivalent of
i2c_smbus_write_word_data(file, reg, 0x6543) */
buf[0] = reg;
buf[1] = 0x43;
@@ -144,7 +147,7 @@ You can do plain i2c transactions by using read(2) and
write(2) calls.
You do not need to pass the address byte; instead, set it through
ioctl I2C_SLAVE before you try to access the device.
-You can do SMBus level transactions (see documentation file smbus-protocol
+You can do SMBus level transactions (see documentation file smbus-protocol
for details) through the following functions:
__s32 i2c_smbus_write_quick(int file, __u8 value);
__s32 i2c_smbus_read_byte(int file);
@@ -155,7 +158,7 @@ for details) through the following functions:
__s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
__s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
__s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
- __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
+ __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
All these transactions return -1 on failure; you can read errno to see
what happened. The 'write' transactions return 0 on success; the
--
2.15.1
--
Cengiz Can
[PATCH] i2c: update i2c-dev.h warning in documentation
`dev-interface` document gives examples for accessing i2c from
userspace.
There's a note warning developers about the different `i2c-dev.h` header
files which were shipped with the kernel and i2c-tools separately.
However, these commits in i2c-tools repository suggests that the header
files are now identical (in functionality) and `i2c_*` functions are now
defined in a separate header called `i2c/smbus.h`, which is distributed
with i2c-tools:
commit 652619121974 ("Minimize differences with kernel flavor")
commit 93caf007f4cb ("Move SMBus helper functions to include/i2c/smbus.h")
Thus, I've converted the warning paragraph into a historical note and
updated the suggested header files.
Signed-off-by: Cengiz Can
---
Documentation/i2c/dev-interface | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/Documentation/i2c/dev-interface
b/Documentation/i2c/dev-interface index 5ff19447ac44..04d110697863
100644 --- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -9,21 +9,24 @@ i2c adapters present on your system at a given time.
i2cdetect is part of the i2c-tools package.
I2C device files are character device files with major device number 89
-and a minor device number corresponding to the number assigned as
-explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
+and a minor device number corresponding to the number assigned as
+explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
i2c-10, ...). All 256 minor device numbers are reserved for i2c.
C example
=
-So let's say you want to access an i2c adapter from a C program. The
-first thing to do is "#include ". Please note that
-there are two files named "i2c-dev.h" out there, one is distributed
-with the Linux kernel and is meant to be included from kernel
-driver code, the other one is distributed with i2c-tools and is
-meant to be included from user-space programs. You obviously want
-the second one here.
+So let's say you want to access an i2c adapter from a C program.
First, you +need to include these two headers:
+
+ #include
+ #include
+
+(Please note that there are two files named "i2c-dev.h" out there. One
is +distributed with the Linux kernel and the other one is included in
the +source tree of i2c-tools. They used to be different in content but
since 2012 +they're identical. You should use "linux/i2c-dev.h").
Now, you have to decide which adapter you want to access. You should
inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
@@ -35,7 +38,7 @@ Next thing, open the device file, as follows:
int file;
int adapter_nr = 2; /* probably dynamically determined */
char filename[20];
-
+
snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
file = open(filename, O_RDWR);
if (file < 0) {
@@ -69,7 +72,7 @@ the device supports them. Both are illustrated below.
/* res contains the read word */
}
- /* Using I2C Write, equivalent of
+ /* Using I2C Write, equivalent of
i2c_smbus_write_word_data(file, reg, 0x6543) */
buf[0] = reg;
buf[1] = 0x43;
@@ -144,7 +147,7 @@ You can do plain i2c transactions by using read(2)
and write(2) calls. You do not need to pass the address byte; instead,
set it through ioctl I2C_SLAVE before you try to access the device.
-You can do SMBus level transactions (see documentation file
smbus-protocol +You can do SMBus level transactions (see documentation
file smbus-protocol for details) through the following functions:
__s32 i2c_smbus_write_quick(int file, __u8 value);
__s32 i2c_smbus_read_byte(int file);
@@ -155,7 +158,7 @@ for details) through the following functions:
__s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
__s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
__s32 i2c_smbus_read_block_data(int file, __u8 command, __u8
*values);
- __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8
length,
+ __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
All these transactions return -1 on failure; you can read errno to see
what happened. The 'write' transactions return 0 on success; the
--
2.15.1
Re: [PATCH] libsas: flush pending destruct work in sas_unregister_domain_devices()
On Thu, Dec 7, 2017 at 11:54 PM, Jason Yan wrote: > > We have sent a patchset to fix this and to enhance libsas hotplug. > Please refer to https://lkml.org/lkml/2017/9/6/142 > > And I'm going to send a new version soon. Thanks for working on it! Please make sure they will be queued for -stable too, since 3.14, 4.1 and 4.9 are all affected.
[PATCH] dt-bindings: mailbox: ti,message-manager: Fix interrupt name error
Message Manager's mailbox interrupts are queue based and not proxy specific. The interrupt names are wrong in the binding, however correctly reflected in the example provided. Remove the relation to proxy ID in the documentation of binding. Existing device tree descriptions follow the correct conventions already and documentation update has been missed. Signed-off-by: Nishanth Menon --- Documentation/devicetree/bindings/mailbox/ti,message-manager.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt index c3b55b3ede8a..ebf0e3710cee 100644 --- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt @@ -20,9 +20,9 @@ Required properties: order referring to the transfer path. - interrupt-names: Contains interrupt names matching the rx transfer path for a given SoC. Receive interrupts shall be of the - format: "rx__". + format: "rx_". For ti,k2g-message-manager, this shall contain: - "rx_005_002", "rx_057_002" + "rx_005", "rx_057" - interrupts: Contains the interrupt information corresponding to interrupt-names property. -- 2.14.1
Re: kernel BUG at net/core/skbuff.c:LINE! (2)
On Fri, Dec 8, 2017 at 12:45 AM, Xin Long wrote: > This isn't a sctp problem, but mld's, seems when lo's mtu became 0, > it allocs a skb without enough space in add_grec(): Shouldn't we just set its min_mtu to ETH_MIN_MTU?
[PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme
Currently, blk-mq timeout path synchronizes against the usual
issue/completion path using a complex scheme involving atomic
bitflags, REQ_ATOM_*, memory barriers and subtle memory coherence
rules. Unfortunatley, it contains quite a few holes.
There's a complex dancing around REQ_ATOM_STARTED and
REQ_ATOM_COMPLETE between issue/completion and timeout paths; however,
they don't have a synchronization point across request recycle
instances and it isn't clear what the barriers add.
blk_mq_check_expired() can easily read STARTED from N-2'th iteration,
deadline from N-1'th, blk_mark_rq_complete() against Nth instance.
In fact, it's pretty easy to make blk_mq_check_expired() terminate a
later instance of a request. If we induce 5 sec delay before
time_after_eq() test in blk_mq_check_expired(), shorten the timeout to
2s, and issue back-to-back large IOs, blk-mq starts timing out
requests spuriously pretty quickly. Nothing actually timed out. It
just made the call on a recycle instance of a request and then
terminated a later instance long after the original instance finished.
The scenario isn't theoretical either.
This patch replaces the broken synchronization mechanism with a RCU
and generation number based one.
1. Each request has a u64 generation + state value, which can be
updated only by the request owner. Whenever a request becomes
in-flight, the generation number gets bumped up too. This provides
the basis for the timeout path to distinguish different recycle
instances of the request.
Also, marking a request in-flight and setting its deadline are
protected with a seqcount so that the timeout path can fetch both
values coherently.
2. The timeout path fetches the generation, state and deadline. If
the verdict is timeout, it records the generation into a dedicated
request abortion field and does RCU wait.
3. The completion path is also protected by RCU (from the previous
patch) and checks whether the current generation number and state
match the abortion field. If so, it skips completion.
4. The timeout path, after RCU wait, scans requests again and
terminates the ones whose generation and state still match the ones
requested for abortion.
By now, the timeout path knows that either the generation number
and state changed if it lost the race or the completion will yield
to it and can safely timeout the request.
While it's more lines of code, it's conceptually simpler, doesn't
depend on direct use of subtle memory ordering or coherence, and
hopefully doesn't terminate the wrong instance.
While this change makes REQ_ATOM_COMPLETE synchornization unnecessary
between issue/complete and timeout paths, REQ_ATOM_COMPLETE isn't
removed yet as it's still used in other places. Future patches will
move all state tracking to the new mechanism and remove all bitops in
the hot paths.
Signed-off-by: Tejun Heo
---
block/blk-core.c | 2 +
block/blk-mq.c | 198 +++--
block/blk-mq.h | 45 +++
block/blk-timeout.c| 2 +-
block/blk.h| 6 --
include/linux/blk-mq.h | 1 +
include/linux/blkdev.h | 23 ++
7 files changed, 196 insertions(+), 81 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index b888175..ccf3f8e 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -126,6 +126,8 @@ void blk_rq_init(struct request_queue *q, struct request
*rq)
rq->start_time = jiffies;
set_start_time_ns(rq);
rq->part = NULL;
+ seqcount_init(&rq->gstate_seqc);
+ u64_stats_init(&rq->aborted_gstate_sync);
}
EXPORT_SYMBOL(blk_rq_init);
diff --git a/block/blk-mq.c b/block/blk-mq.c
index acf4fbb..2d093f7 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -530,6 +530,9 @@ static void __blk_mq_complete_request(struct request *rq)
bool shared = false;
int cpu;
+ WARN_ON_ONCE(blk_mq_rq_state(rq) != MQ_RQ_IN_FLIGHT);
+ blk_mq_rq_update_state(rq, MQ_RQ_IDLE);
+
if (rq->internal_tag != -1)
blk_mq_sched_completed_request(rq);
if (rq->rq_flags & RQF_STATS) {
@@ -557,6 +560,19 @@ static void __blk_mq_complete_request(struct request *rq)
put_cpu();
}
+static u64 blk_mq_rq_aborted_gstate(struct request *rq)
+{
+ unsigned int start;
+ u64 aborted_gstate;
+
+ do {
+ start = u64_stats_fetch_begin(&rq->aborted_gstate_sync);
+ aborted_gstate = rq->aborted_gstate;
+ } while (u64_stats_fetch_retry(&rq->aborted_gstate_sync, start));
+
+ return aborted_gstate;
+}
+
/**
* blk_mq_complete_request - end I/O on a request
* @rq:the request being processed
@@ -574,14 +590,21 @@ void blk_mq_complete_request(struct request *rq)
if (unlikely(blk_should_fake_timeout(q)))
return;
+ /*
+* If @rq->aborted_gstate equals the current instance, timeout is
+* claiming @rq
[PATCH 1/6] blk-mq: protect completion path with RCU
Currently, blk-mq protects only the issue path with RCU. This patch
puts the completion path under the same RCU protection. This will be
used to synchronize issue/completion against timeout by later patches,
which will also add the comments.
Signed-off-by: Tejun Heo
---
block/blk-mq.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 1109747..acf4fbb 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -568,11 +568,23 @@ static void __blk_mq_complete_request(struct request *rq)
void blk_mq_complete_request(struct request *rq)
{
struct request_queue *q = rq->q;
+ struct blk_mq_hw_ctx *hctx = blk_mq_map_queue(q, rq->mq_ctx->cpu);
+ int srcu_idx;
if (unlikely(blk_should_fake_timeout(q)))
return;
- if (!blk_mark_rq_complete(rq))
- __blk_mq_complete_request(rq);
+
+ if (!(hctx->flags & BLK_MQ_F_BLOCKING)) {
+ rcu_read_lock();
+ if (!blk_mark_rq_complete(rq))
+ __blk_mq_complete_request(rq);
+ rcu_read_unlock();
+ } else {
+ srcu_idx = srcu_read_lock(hctx->queue_rq_srcu);
+ if (!blk_mark_rq_complete(rq))
+ __blk_mq_complete_request(rq);
+ srcu_read_unlock(hctx->queue_rq_srcu, srcu_idx);
+ }
}
EXPORT_SYMBOL(blk_mq_complete_request);
--
2.9.5
[PATCH 3/6] blk-mq: use blk_mq_rq_state() instead of testing REQ_ATOM_COMPLETE
blk_mq_check_inflight() and blk_mq_poll_hybrid_sleep() test
REQ_ATOM_COMPLETE to determine the request state. Both uses are
speculative and we can test REQ_ATOM_STARTED and blk_mq_rq_state() for
equivalent results. Replace the tests. This will allow removing
REQ_ATOM_COMPLETE usages from blk-mq.
Signed-off-by: Tejun Heo
---
block/blk-mq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 2d093f7..39b79bd 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -95,8 +95,7 @@ static void blk_mq_check_inflight(struct blk_mq_hw_ctx *hctx,
{
struct mq_inflight *mi = priv;
- if (test_bit(REQ_ATOM_STARTED, &rq->atomic_flags) &&
- !test_bit(REQ_ATOM_COMPLETE, &rq->atomic_flags)) {
+ if (blk_mq_rq_state(rq) == MQ_RQ_IN_FLIGHT) {
/*
* index[0] counts the specific partition that was asked
* for. index[1] counts the ones that are active on the
@@ -2950,7 +2949,8 @@ static bool blk_mq_poll_hybrid_sleep(struct request_queue
*q,
hrtimer_init_sleeper(&hs, current);
do {
- if (test_bit(REQ_ATOM_COMPLETE, &rq->atomic_flags))
+ if (test_bit(REQ_ATOM_STARTED, &rq->atomic_flags) &&
+ blk_mq_rq_state(rq) != MQ_RQ_IN_FLIGHT)
break;
set_current_state(TASK_UNINTERRUPTIBLE);
hrtimer_start_expires(&hs.timer, mode);
--
2.9.5
[PATCH 5/6] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq
After the recent updates to use generation number and state based
synchronization, blk-mq no longer depends on REQ_ATOM_COMPLETE for
anything.
Remove all REQ_ATOM_COMPLETE usages. This removes atomic bitops from
hot paths too. The next patch will push further along this direction
and include simple performance test results.
Signed-off-by: Tejun Heo
---
block/blk-mq.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 0267040..4ebac33 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -596,14 +596,12 @@ void blk_mq_complete_request(struct request *rq)
*/
if (!(hctx->flags & BLK_MQ_F_BLOCKING)) {
rcu_read_lock();
- if (blk_mq_rq_aborted_gstate(rq) != rq->gstate &&
- !blk_mark_rq_complete(rq))
+ if (blk_mq_rq_aborted_gstate(rq) != rq->gstate)
__blk_mq_complete_request(rq);
rcu_read_unlock();
} else {
srcu_idx = srcu_read_lock(hctx->queue_rq_srcu);
- if (blk_mq_rq_aborted_gstate(rq) != rq->gstate &&
- !blk_mark_rq_complete(rq))
+ if (blk_mq_rq_aborted_gstate(rq) != rq->gstate)
__blk_mq_complete_request(rq);
srcu_read_unlock(hctx->queue_rq_srcu, srcu_idx);
}
@@ -650,8 +648,6 @@ void blk_mq_start_request(struct request *rq)
write_seqcount_end(&rq->gstate_seqc);
set_bit(REQ_ATOM_STARTED, &rq->atomic_flags);
- if (test_bit(REQ_ATOM_COMPLETE, &rq->atomic_flags))
- clear_bit(REQ_ATOM_COMPLETE, &rq->atomic_flags);
if (q->dma_drain_size && blk_rq_bytes(rq)) {
/*
@@ -862,8 +858,7 @@ static void blk_mq_terminate_expired(struct blk_mq_hw_ctx
*hctx,
* now guaranteed to see @rq->aborted_gstate and yield. If
* @rq->aborted_gstate still matches @rq->gstate, @rq is ours.
*/
- if (READ_ONCE(rq->gstate) == rq->aborted_gstate &&
- !blk_mark_rq_complete(rq))
+ if (READ_ONCE(rq->gstate) == rq->aborted_gstate)
blk_mq_rq_timed_out(rq, reserved);
}
--
2.9.5
[PATCH 6/6] blk-mq: remove REQ_ATOM_STARTED
After the recent updates to use generation number and state based
synchronization, we can easily replace REQ_ATOM_STARTED usages by
adding an extra state to distinguish completed but not yet freed
state.
Add MQ_RQ_COMPLETE and replace REQ_ATOM_STARTED usages with
blk_mq_rq_state() tests. REQ_ATOM_STARTED no longer has any users
left and is removed.
Signed-off-by: Tejun Heo
---
block/blk-mq-debugfs.c | 4 +---
block/blk-mq.c | 39 ---
block/blk-mq.h | 1 +
block/blk.h| 1 -
4 files changed, 10 insertions(+), 35 deletions(-)
diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
index b56a4f3..8adc837 100644
--- a/block/blk-mq-debugfs.c
+++ b/block/blk-mq-debugfs.c
@@ -271,7 +271,6 @@ static const char *const cmd_flag_name[] = {
#define RQF_NAME(name) [ilog2((__force u32)RQF_##name)] = #name
static const char *const rqf_name[] = {
RQF_NAME(SORTED),
- RQF_NAME(STARTED),
RQF_NAME(QUEUED),
RQF_NAME(SOFTBARRIER),
RQF_NAME(FLUSH_SEQ),
@@ -295,7 +294,6 @@ static const char *const rqf_name[] = {
#define RQAF_NAME(name) [REQ_ATOM_##name] = #name
static const char *const rqaf_name[] = {
RQAF_NAME(COMPLETE),
- RQAF_NAME(STARTED),
RQAF_NAME(POLL_SLEPT),
};
#undef RQAF_NAME
@@ -409,7 +407,7 @@ static void hctx_show_busy_rq(struct request *rq, void
*data, bool reserved)
const struct show_busy_params *params = data;
if (blk_mq_map_queue(rq->q, rq->mq_ctx->cpu) == params->hctx &&
- test_bit(REQ_ATOM_STARTED, &rq->atomic_flags))
+ blk_mq_rq_state(rq) != MQ_RQ_IDLE)
__blk_mq_debugfs_rq_show(params->m,
list_entry_rq(&rq->queuelist));
}
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 4ebac33..663069d 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -482,7 +482,7 @@ void blk_mq_free_request(struct request *rq)
if (blk_rq_rl(rq))
blk_put_rl(blk_rq_rl(rq));
- clear_bit(REQ_ATOM_STARTED, &rq->atomic_flags);
+ blk_mq_rq_update_state(rq, MQ_RQ_IDLE);
clear_bit(REQ_ATOM_POLL_SLEPT, &rq->atomic_flags);
if (rq->tag != -1)
blk_mq_put_tag(hctx, hctx->tags, ctx, rq->tag);
@@ -530,7 +530,7 @@ static void __blk_mq_complete_request(struct request *rq)
int cpu;
WARN_ON_ONCE(blk_mq_rq_state(rq) != MQ_RQ_IN_FLIGHT);
- blk_mq_rq_update_state(rq, MQ_RQ_IDLE);
+ blk_mq_rq_update_state(rq, MQ_RQ_COMPLETE);
if (rq->internal_tag != -1)
blk_mq_sched_completed_request(rq);
@@ -610,7 +610,7 @@ EXPORT_SYMBOL(blk_mq_complete_request);
int blk_mq_request_started(struct request *rq)
{
- return test_bit(REQ_ATOM_STARTED, &rq->atomic_flags);
+ return blk_mq_rq_state(rq) != MQ_RQ_IDLE;
}
EXPORT_SYMBOL_GPL(blk_mq_request_started);
@@ -629,7 +629,6 @@ void blk_mq_start_request(struct request *rq)
}
WARN_ON_ONCE(blk_mq_rq_state(rq) != MQ_RQ_IDLE);
- WARN_ON_ONCE(test_bit(REQ_ATOM_STARTED, &rq->atomic_flags));
/*
* Mark @rq in-flight which also advances the generation number,
@@ -647,8 +646,6 @@ void blk_mq_start_request(struct request *rq)
blk_add_timer(rq);
write_seqcount_end(&rq->gstate_seqc);
- set_bit(REQ_ATOM_STARTED, &rq->atomic_flags);
-
if (q->dma_drain_size && blk_rq_bytes(rq)) {
/*
* Make sure space for the drain appears. We know we can do
@@ -661,13 +658,9 @@ void blk_mq_start_request(struct request *rq)
EXPORT_SYMBOL(blk_mq_start_request);
/*
- * When we reach here because queue is busy, REQ_ATOM_COMPLETE
- * flag isn't set yet, so there may be race with timeout handler,
- * but given rq->deadline is just set in .queue_rq() under
- * this situation, the race won't be possible in reality because
- * rq->timeout should be set as big enough to cover the window
- * between blk_mq_start_request() called from .queue_rq() and
- * clearing REQ_ATOM_STARTED here.
+ * When we reach here because queue is busy, it's safe to change the state
+ * to IDLE without checking @rq->aborted_gstate because we should still be
+ * holding the RCU read lock and thus protected against timeout.
*/
static void __blk_mq_requeue_request(struct request *rq)
{
@@ -679,7 +672,7 @@ static void __blk_mq_requeue_request(struct request *rq)
wbt_requeue(q->rq_wb, &rq->issue_stat);
blk_mq_sched_requeue_request(rq);
- if (test_and_clear_bit(REQ_ATOM_STARTED, &rq->atomic_flags)) {
+ if (blk_mq_rq_state(rq) != MQ_RQ_IDLE) {
blk_mq_rq_update_state(rq, MQ_RQ_IDLE);
if (q->dma_drain_size && blk_rq_bytes(rq))
rq->nr_phys_segments--;
@@ -786,18 +779,6 @@ static void blk_mq_rq_timed_out(struct request *req, bool
reserved)
const struct blk_mq_ops *ops = req->q->mq_ops;
enum blk_eh_timer_return ret
[PATCH 4/6] blk-mq: make blk_abort_request() trigger timeout path
With issue/complete and timeout paths now using the generation number
and state based synchronization, blk_abort_request() is the only one
which depends on REQ_ATOM_COMPLETE for arbitrating completion.
There's no reason for blk_abort_request() to be a completely separate
path. This patch makes blk_abort_request() piggyback on the timeout
path instead of trying to terminate the request directly.
This removes the last dependency on REQ_ATOM_COMPLETE in blk-mq.
Signed-off-by: Tejun Heo
---
block/blk-mq.c | 2 +-
block/blk-mq.h | 2 --
block/blk-timeout.c | 7 ---
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 39b79bd..0267040 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -785,7 +785,7 @@ struct blk_mq_timeout_data {
unsigned int nr_expired;
};
-void blk_mq_rq_timed_out(struct request *req, bool reserved)
+static void blk_mq_rq_timed_out(struct request *req, bool reserved)
{
const struct blk_mq_ops *ops = req->q->mq_ops;
enum blk_eh_timer_return ret = BLK_EH_RESET_TIMER;
diff --git a/block/blk-mq.h b/block/blk-mq.h
index 5a83ef3..760e7ed 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -94,8 +94,6 @@ extern int blk_mq_sysfs_register(struct request_queue *q);
extern void blk_mq_sysfs_unregister(struct request_queue *q);
extern void blk_mq_hctx_kobj_init(struct blk_mq_hw_ctx *hctx);
-extern void blk_mq_rq_timed_out(struct request *req, bool reserved);
-
void blk_mq_release(struct request_queue *q);
/**
diff --git a/block/blk-timeout.c b/block/blk-timeout.c
index 6427be7..051924f 100644
--- a/block/blk-timeout.c
+++ b/block/blk-timeout.c
@@ -156,12 +156,13 @@ void blk_timeout_work(struct work_struct *work)
*/
void blk_abort_request(struct request *req)
{
- if (blk_mark_rq_complete(req))
- return;
if (req->q->mq_ops) {
- blk_mq_rq_timed_out(req, false);
+ req->deadline = jiffies;
+ mod_timer(&req->q->timeout, 0);
} else {
+ if (blk_mark_rq_complete(req))
+ return;
blk_delete_timer(req);
blk_rq_timed_out(req);
}
--
2.9.5
[PATCHSET] blk-mq: reimplement timeout handling
Currently, blk-mq timeout path synchronizes against the usual issue/completion path using a complex scheme involving atomic bitflags, REQ_ATOM_*, memory barriers and subtle memory coherence rules. Unfortunatley, it contains quite a few holes. It's pretty easy to make blk_mq_check_expired() terminate a later instance of a request. If we induce 5 sec delay before time_after_eq() test in blk_mq_check_expired(), shorten the timeout to 2s, and issue back-to-back large IOs, blk-mq starts timing out requests spuriously pretty quickly. Nothing actually timed out. It just made the call on a recycle instance of a request and then terminated a later instance long after the original instance finished. The scenario isn't theoretical either. This patchset replaces the broken synchronization mechanism with a RCU and generation number based one. Please read the patch description of the second path for more details. Oleg, Peter, I'd really appreciate if you guys can go over the reported breakages and the new implementation. This patchset contains the following six patches. 0001-blk-mq-protect-completion-path-with-RCU.patch 0002-blk-mq-replace-timeout-synchronization-with-a-RCU-an.patch 0003-blk-mq-use-blk_mq_rq_state-instead-of-testing-REQ_AT.patch 0004-blk-mq-make-blk_abort_request-trigger-timeout-path.patch 0005-blk-mq-remove-REQ_ATOM_COMPLETE-usages-from-blk-mq.patch 0006-blk-mq-remove-REQ_ATOM_STARTED.patch and is available in the following git branch. git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git blk-mq-timeout diffstat follows. Thanks. block/blk-core.c |2 block/blk-mq-debugfs.c |4 block/blk-mq.c | 246 +++-- block/blk-mq.h | 48 + block/blk-timeout.c|9 - block/blk.h|7 - include/linux/blk-mq.h |1 include/linux/blkdev.h | 23 8 files changed, 218 insertions(+), 122 deletions(-) -- tejun
Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations
On Fri, Dec 08, 2017 at 03:39:43PM +, Quentin Monnet wrote:
> 2017-12-08 14:12 UTC+ ~ Roman Gushchin
> > On Fri, Dec 08, 2017 at 10:34:16AM +, Quentin Monnet wrote:
> >> 2017-12-07 18:39 UTC+ ~ Roman Gushchin
> >>> This patch adds basic cgroup bpf operations to bpftool:
> >>> cgroup list, attach and detach commands.
> >>>
> >>> Usage is described in the corresponding man pages,
> >>> and examples are provided.
> > [...]
> >>> +MAP COMMANDS
> >>> +=
> >>> +
> >>> +|**bpftool** **cgroup list** *CGROUP*
> >>> +|**bpftool** **cgroup attach** *CGROUP* *ATTACH_TYPE* *PROG*
> >>> [*ATTACH_FLAGS*]
> >>> +|**bpftool** **cgroup detach** *CGROUP* *ATTACH_TYPE* *PROG*
> >>> +|**bpftool** **cgroup help**
> >>> +|
> >>> +|*PROG* := { **id** *PROG_ID* | **pinned** *FILE* | **tag**
> >>> *PROG_TAG* }
> >>
> >> Could you please give the different possible values for ATTACH_TYPE and
> >> ATTACH_FLAGS, and provide some documentation for the flags?
> >
> > I intentionally didn't include the list of possible values, as it depends
> > on the exact kernel version, and other bpftool docs are carefully avoiding
> > specifying such things.
>
> Do they? As far as I can tell the only other bpftool command that uses
> flags is the `bpftool map update`, and it does specify the possible
> values for UPDATE_FLAGS (and document them) in the man page.
You are right about UPDATE_FLAGS, but at the same time we do
not describe bpf program attributes in prog show:
**bpftool prog show** [*PROG*]
Show information about loaded programs. If *PROG* is
specified show information only about given program, otherwise
list all programs currently loaded on the system.
Output will start with program ID followed by program type and
zero or more named attributes (depending on kernel version).
I think, that actually ATTACH_TYPE is similar to PROGRAM_TYPE because
it will likely be extended in the following kernel versions.
So we should probably support specifying it in a numeric form too.
ATTACH_FLAGS are probably less volatile and will unlikely be extended often,
so we can describe them in docs and add a note about the kernel version
next time when a new flag will be added.
Anyway, I don't see any big problem in documenting current ATTACH_FLAG
and ATTACH_TYPE sets, if we think that it's a good way forward.
Thanks!
[PATCH 3/3] serial: ifx6x60: Add some spaces for better code readability
From: Markus Elfring
Date: Sat, 9 Dec 2017 19:55:31 +0100
Use space characters at some source code places according to
the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/tty/serial/ifx6x60.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c
index 1883e3382338..f40f64378406 100644
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -248,8 +248,8 @@ static void mrdy_assert(struct ifx_spi_device *ifx_dev)
if (!val) {
if (!test_and_set_bit(IFX_SPI_STATE_TIMER_PENDING,
&ifx_dev->flags)) {
- mod_timer(&ifx_dev->spi_timer,jiffies +
IFX_SPI_TIMEOUT_SEC*HZ);
-
+ mod_timer(&ifx_dev->spi_timer,
+ jiffies + IFX_SPI_TIMEOUT_SEC * HZ);
}
}
ifx_spi_power_state_set(ifx_dev, IFX_SPI_POWER_DATA_PENDING);
@@ -378,7 +378,7 @@ static int ifx_spi_decode_spi_header(unsigned char *buffer,
int *length,
u16 *in_buffer = (u16 *)buffer;
h1 = *in_buffer;
- h2 = *(in_buffer+1);
+ h2 = *(in_buffer + 1);
if (h1 == 0 && h2 == 0) {
*received_cts = 0;
@@ -410,7 +410,7 @@ static void ifx_spi_setup_spi_header(unsigned char
*txbuffer, int tx_count,
unsigned char more)
{
*(u16 *)(txbuffer) = tx_count;
- *(u16 *)(txbuffer+2) = IFX_SPI_PAYLOAD_SIZE;
+ *(u16 *)(txbuffer + 2) = IFX_SPI_PAYLOAD_SIZE;
txbuffer[1] |= (more << IFX_SPI_MORE_BIT) & IFX_SPI_MORE_MASK;
}
@@ -467,8 +467,8 @@ static int ifx_spi_prepare_tx_buffer(struct ifx_spi_device
*ifx_dev)
/* have data and info for header -- set up SPI header in buffer */
/* spi header needs payload size, not entire buffer size */
ifx_spi_setup_spi_header(ifx_dev->tx_buffer,
- tx_count-IFX_SPI_HEADER_OVERHEAD,
- ifx_dev->spi_more);
+tx_count - IFX_SPI_HEADER_OVERHEAD,
+ifx_dev->spi_more);
/* swap actual data in the buffer */
ifx_dev->swap_buf((ifx_dev->tx_buffer), tx_count,
&ifx_dev->tx_buffer[IFX_SPI_TRANSFER_SIZE]);
@@ -1163,7 +1163,7 @@ static int ifx_spi_spi_probe(struct spi_device *spi)
ret = request_irq(gpio_to_irq(ifx_dev->gpio.reset_out),
ifx_spi_reset_interrupt,
- IRQF_TRIGGER_RISING|IRQF_TRIGGER_FALLING, DRVNAME,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, DRVNAME,
ifx_dev);
if (ret) {
dev_err(&spi->dev, "Unable to get irq %x\n",
--
2.15.1
[PATCH 2/3] serial: ifx6x60: Improve a size determination in ifx_spi_spi_probe()
From: Markus Elfring Date: Sat, 9 Dec 2017 19:22:50 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/tty/serial/ifx6x60.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c index 832751479f41..1883e3382338 100644 --- a/drivers/tty/serial/ifx6x60.c +++ b/drivers/tty/serial/ifx6x60.c @@ -1005,7 +1005,7 @@ static int ifx_spi_spi_probe(struct spi_device *spi) } /* initialize structure to hold our device variables */ - ifx_dev = kzalloc(sizeof(struct ifx_spi_device), GFP_KERNEL); + ifx_dev = kzalloc(sizeof(*ifx_dev), GFP_KERNEL); if (!ifx_dev) return -ENOMEM; -- 2.15.1
[PATCH 1/3] serial: ifx6x60: Delete an error message for a failed memory allocation in ifx_spi_spi_probe()
From: Markus Elfring
Date: Sat, 9 Dec 2017 19:20:37 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/tty/serial/ifx6x60.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c
index 473f4f81d690..832751479f41 100644
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -1006,10 +1006,9 @@ static int ifx_spi_spi_probe(struct spi_device *spi)
/* initialize structure to hold our device variables */
ifx_dev = kzalloc(sizeof(struct ifx_spi_device), GFP_KERNEL);
- if (!ifx_dev) {
- dev_err(&spi->dev, "spi device allocation failed");
+ if (!ifx_dev)
return -ENOMEM;
- }
+
saved_ifx_dev = ifx_dev;
ifx_dev->spi_dev = spi;
clear_bit(IFX_SPI_STATE_IO_IN_PROGRESS, &ifx_dev->flags);
--
2.15.1
[PATCH 0/3] tty/serial/ifx6x60: Adjustments for five function implementations
From: Markus Elfring Date: Sat, 9 Dec 2017 20:03:45 +0100 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an error message for a failed memory allocation in ifx_spi_spi_probe() Improve a size determination in ifx_spi_spi_probe() Add some spaces for better code readability drivers/tty/serial/ifx6x60.c | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) -- 2.15.1
Re: [Patch v6 10/12] [media] v4l2: Add v4l2 control IDs for HEVC encoder
Hi Smitha,
Thanks for the patches!
On 12/08/2017 11:08 AM, Smitha T Murthy wrote:
Add v4l2 controls for HEVC encoder
Signed-off-by: Smitha T Murthy
Reviewed-by: Andrzej Hajda
---
drivers/media/v4l2-core/v4l2-ctrls.c | 118 +++
include/uapi/linux/v4l2-controls.h | 92 ++-
2 files changed, 209 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 4e53a86..3f98318 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -480,6 +480,56 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
NULL,
};
+ static const char * const hevc_profile[] = {
+ "Main",
You forgot "Main 10" profile.
+ "Main Still Picture",
+ NULL,
+ };
+ static const char * const hevc_level[] = {
+ "1",
+ "2",
+ "2.1",
+ "3",
+ "3.1",
+ "4",
+ "4.1",
+ "5",
+ "5.1",
+ "5.2",
+ "6",
+ "6.1",
+ "6.2",
+ NULL,
+ };
+ static const char * const hevc_hierarchial_coding_type[] = {
+ "B",
+ "P",
+ NULL,
+ };
+ static const char * const hevc_refresh_type[] = {
+ "None",
+ "CRA",
+ "IDR",
+ NULL,
+ };
+ static const char * const hevc_size_of_length_field[] = {
+ "0",
+ "1",
+ "2",
+ "4",
+ NULL,
+ };
+ static const char * const hevc_tier_flag[] = {
+ "Main",
+ "High",
+ NULL,
+ };
+ static const char * const hevc_loop_filter_mode[] = {
+ "Disabled",
+ "Enabled",
+ "Disabled at slice boundary",
+ "NULL",
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -575,6 +625,20 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return dv_it_content_type;
case V4L2_CID_DETECT_MD_MODE:
return detect_md_mode;
+ case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
+ return hevc_profile;
+ case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
+ return hevc_level;
+ case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE:
+ return hevc_hierarchial_coding_type;
+ case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE:
+ return hevc_refresh_type;
+ case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:
+ return hevc_size_of_length_field;
+ case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:
Could you drop _FLAG suffix? Looking (briefly) into the spec they not
specify `tier flag` but just `tier`.
+ return hevc_tier_flag;
+ case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE:
+ return hevc_loop_filter_mode;
default:
return NULL;
@@ -776,6 +840,53 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX P-Frame
QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX
Profile";
+ /* HEVC controls */
+ case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame
QP Value";
+ case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP: return "HEVC P-Frame
QP Value";
+ case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP: return "HEVC B-Frame
QP Value";
+ case V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP: return "HEVC Minimum
QP Value";
+ case V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP: return "HEVC Maximum
QP Value";
+ case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE: return "HEVC
Profile";
+ case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:return "HEVC
Level";
+ case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:return "HEVC Tier
Flag";
+ case V4L2_CID_MPEG_VIDEO_HEVC_FRAME_RATE_RESOLUTION:return "HEVC Frame
Rate Resolution";
+ case V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH: return "HEVC Maximum
Coding Unit Depth";
+ case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE: return "HEVC Refresh
Type";
+ case V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED: return "HEVC
Constant Intra Prediction";
+ case V4L2_CID_MPEG_VIDEO_HEVC_LOSSLESS_CU: return "HEVC
Lossless Encoding";
+ case V4L2_CID_MPEG_VIDEO_HEVC_WAVEFRONT:return "HEVC
Wavefront";
+ case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE: return "HEVC Loop
Filter";
+ case V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP: return "HEVC QP
Values";
+ case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE:
Re: [PATCH 4.14 00/75] 4.14.5-stable review
On Sat, Dec 9, 2017 at 5:13 PM, Greg Kroah-Hartman
wrote:
> On Sat, Dec 09, 2017 at 07:56:40AM +, Ivan Kozik wrote:
>> On Sat, Dec 9, 2017 at 7:45 AM, Greg Kroah-Hartman
>> wrote:
>> > On Sat, Dec 09, 2017 at 03:34:24AM +, Ivan Kozik wrote:
>> >> I saw no problems on 8 of 9 machines, but the last one had a problem
>> >> because it used NVIDIA drivers (387); DKMS reported:
>> >>
>> >> FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only
>> >> symbol 'ex_handler_refcount'
>> >> //usr/src/linux-headers-4.14.0-11-common/scripts/Makefile.modpost:92:
>> >> recipe for target '__modpost' failed
>> >> make[3]: *** [__modpost] Error 1
>> >
>> > Is this a new issue? Does 4.14.4 have this issue?
>>
>> I believe it is a new issue, because I have a 4.14.4 build and an
>> NVIDIA DKMS log for that 4.14.4 showing build success.
>>
>> > Odd, is 564c9cc84e2a ("locking/refcounts, x86/asm: Use unique .text
>> > section for refcount exceptions") causing this?
>>
>> That was my guess too, but I did not verify.
>
> That feels really wrong here, I'd like to get some confirmation before I
> add this patch...
I built a 4.14.4 with all the stable-queue patches except:
locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT
and NVIDIA built fine with DKMS, so it looks like the refcount
enablement patch was responsible.
In summary, NVIDIA builds fine with
4.14.4
4.14.4 + all stable-queue except ...Enable CONFIG_ARCH_HAS_REFCOUNT
4.14.4 + all stable-queue + https://lkml.org/lkml/2017/12/4/1110
Thanks,
Ivan
Linux kernel configuration for MPS2 AN385
Hi folks, I am playing with qemu's mps2-an385 emulation and try to get Linux to boot with it, so far with little (ie no) success. Is a working kernel configuration for this board available somewhere ? Thanks, Guenter
Re: [patch V2 2/2] x86/ldt: Prevent ldt inheritance on exec
On Sat, 9 Dec 2017, Thomas Gleixner wrote:
> On Fri, 8 Dec 2017, Thomas Gleixner wrote:
> > +int ldt_dup_context(struct mm_struct *old_mm, struct mm_struct *mm)
> > {
> > struct ldt_struct *new_ldt;
> > - struct mm_struct *old_mm;
> > int retval = 0;
> >
> > - mutex_init(&mm->context.lock);
> > - old_mm = current->mm;
> > - if (!old_mm) {
> > - mm->context.ldt = NULL;
> > + if (!old_mm)
> > return 0;
> > - }
> >
> > mutex_lock(&old_mm->context.lock);
>
> Bah. That's broken. It now nests into old_mm->mmap_sem which is the reverse
> lock order than in ldt_write. Will fix.
Confused myself. mmap_sem is not taken in mainline ldt_write. It's just in
the stuff I'm working on.
Thanks,
tglx
Re: RFC(v2): Audit Kernel Container IDs
On 12/9/2017 2:20 AM, Micka�l Sala�n wrote: > On 12/10/2017 18:33, Casey Schaufler wrote: >> On 10/12/2017 7:14 AM, Richard Guy Briggs wrote: >>> Containers are a userspace concept. The kernel knows nothing of them. >>> >>> The Linux audit system needs a way to be able to track the container >>> provenance of events and actions. Audit needs the kernel's help to do >>> this. >>> >>> Since the concept of a container is entirely a userspace concept, a >>> registration from the userspace container orchestration system initiates >>> this. This will define a point in time and a set of resources >>> associated with a particular container with an audit container ID. >>> >>> The registration is a pseudo filesystem (proc, since PID tree already >>> exists) write of a u8[16] UUID representing the container ID to a file >>> representing a process that will become the first process in a new >>> container. This write might place restrictions on mount namespaces >>> required to define a container, or at least careful checking of >>> namespaces in the kernel to verify permissions of the orchestrator so it >>> can't change its own container ID. A bind mount of nsfs may be >>> necessary in the container orchestrator's mntNS. >>> Note: Use a 128-bit scalar rather than a string to make compares faster >>> and simpler. >>> >>> Require a new CAP_CONTAINER_ADMIN to be able to carry out the >>> registration. >> Hang on. If containers are a user space concept, how can >> you want CAP_CONTAINER_ANYTHING? If there's not such thing as >> a container, how can you be asking for a capability to manage >> them? >> >>> At that time, record the target container's user-supplied >>> container identifier along with the target container's first process >>> (which may become the target container's "init" process) process ID >>> (referenced from the initial PID namespace), all namespace IDs (in the >>> form of a nsfs device number and inode number tuple) in a new auxilliary >>> record AUDIT_CONTAINER with a qualifying op=$action field. > Here is an idea to avoid privilege problems or the need for a new > capability: make it automatic. What makes a container a container seems > to be the use of at least a namespace. You might think so, but I am assured that you can have a container without using namespaces. Intel's "Clear Containers", which use virtualization technology, are one example. I have considered creating "Smack Containers" using mandatory access control technology, more to press the point that "containers" is a marketing concept, not technology. > What about automatically create > and assign an ID to a process when it enters a namespace different than > one of its parent process? This delegates the (permission) > responsibility to the use of namespaces (e.g. /proc/sys/user/max_* limit). That gets ugly when you have a container that uses user, filesystem, network and whatever else namespaces. If all containers used the same set of namespaces I think this would be a fine idea, but they don't. > One interesting side effect of this approach would be to be able to > identify which processes are in the same set of namespaces, even if not > spawn from the container but entered after its creation (i.e. using > setns), by creating container IDs as a (deterministic) checksum from the > /proc/self/ns/* IDs. > > Since the concern is to identify a container, I think the ability to > audit the switch from one container ID to another is enough. I don't > think we need nested IDs. Because a container doesn't have to use namespaces to be a container you still need a mechanism for a process to declare that it is in fact in a container, and to identify the container. > > As a side note, you may want to take a look at the Linux-VServer's XID. > > Regards, > Micka�l >
Re: [patch V2 2/2] x86/ldt: Prevent ldt inheritance on exec
On Fri, 8 Dec 2017, Thomas Gleixner wrote:
> +int ldt_dup_context(struct mm_struct *old_mm, struct mm_struct *mm)
> {
> struct ldt_struct *new_ldt;
> - struct mm_struct *old_mm;
> int retval = 0;
>
> - mutex_init(&mm->context.lock);
> - old_mm = current->mm;
> - if (!old_mm) {
> - mm->context.ldt = NULL;
> + if (!old_mm)
> return 0;
> - }
>
> mutex_lock(&old_mm->context.lock);
Bah. That's broken. It now nests into old_mm->mmap_sem which is the reverse
lock order than in ldt_write. Will fix.
Thanks,
tglx
Re: [PATCH] sched/isolation: Make NO_HZ_FULL select CPU_ISOLATION
On Sat, Dec 09, 2017 at 02:09:07PM +0100, Frederic Weisbecker wrote: > 2017-12-07 18:29 UTC+01:00, Paul E. McKenney : > > On Thu, Dec 07, 2017 at 05:14:54PM +0100, Frederic Weisbecker wrote: > >> 2017-12-04 18:16 UTC+01:00, Paul E. McKenney > >> : > >> > On Mon, Dec 04, 2017 at 04:53:15PM +0100, Frederic Weisbecker wrote: > >> >> 2017-12-02 20:24 UTC+01:00, Paul E. McKenney > >> >> I would prefer to keep it. It's useful for automated boot testing > >> >> based on configs such as 0-day or -tip test machines. But I'm likely > >> >> to migrate it to isolcpus implementation. Maybe something along the > >> >> lines of CONFIG_CPU_ISOLATION_ALL. > >> > > >> > How about instead allowing something like "nohz_full=1-" specify that > >> > all CPUs other than CPU 0 should be nohz_full CPUs? That would shrink > >> > the code by eliminating CONFIG_NO_HZ_FULL_ALL while still allowing > >> > easy automation of that particular scenario. > >> > > >> > (Right now, the boot code complains about "nohz_full=1-", which means > >> > that whatever is generating the boot parameters needs to know how many > >> > CPUs there really are, which as you say can be a pain.) > >> > >> Yes but automated boot testing is rather based on configs than boot > >> options. It's much easier. I think that's how Wu Fengguang lab works, > >> and -tip automated tests as well. > > > > So you have gotten bug reports from them? Because I see splats from > > rcutorture testing rather frequently. This thing is in no way a subtle > > low-probability bug. ;-) > > Nope I haven't got anything from them. So far you're the only > reproducer I know :) > > >> >> >> Did you have any nohz_full= or isolcpus= boot options? > >> >> > > >> >> > Replacing CONFIG_NO_HZ_FULL_ALL=y with nohz_full=1-7 works, that > >> >> > is CONFIG_NO_HZ_FULL=y, CONFIG_NO_HZ_FULL_ALL=n, and nohz_full=1-7 > >> >> > on an eight-CPU test. > >> >> > > >> >> > But it is relatively easy to test. Running the rcutorture TREE04 > >> >> > scenario on a four-socket x86 gets me RCU CPU stall warnings within > >> >> > a few minutes more than half the time. ;-) > >> >> > >> >> Indeed I managed to trigger something. If it's the same thing I should > >> >> be able to track down the root cause. > >> >> > >> >> [ 123.907557] ??? Writer stall state RTWS_STUTTER(8) g160 c160 f0x0 > >> >> ->state 0x1 cpu 2 > >> >> [ 123.915184] rcu_torture_wri S0 111 2 0x8008 > >> >> [ 123.920673] Call Trace: > >> >> [ 123.923096] ? __schedule+0x2bf/0xbb0 > >> >> [ 123.926715] ? _raw_spin_unlock_irqrestore+0x59/0x70 > >> >> [ 123.931657] schedule+0x3c/0x90 > >> >> [ 123.934777] schedule_timeout+0x1e1/0x560 > >> > > >> > It might well be the same thing, as this schedule_timeout() does look > >> > familiar. I have some diagnostic patches in -rcu, please see below > >> > for the overall effect. > >> > >> I fear I can hit that even without any nohz_full CPU as well. > > > > Indeed, I do hit that with my TREE01 scenario, which does not set > > CONFIG_NO_HZ_FULL. But it is much less frequent. The good news is that > > I have finally figured out a way to extract information from this thing > > without suppressing it. At the moment it appears to be a rather strange > > deadlock involving CPU hotplug, timers, and RCU. > > > > But that is a completely different bug from the ones for which I have > > the two patches in my tree. > > > > Anyway, I will keep those two patches because I cannot have the > > corresponding bugs possibly hiding RCU bugs in my testing. If you > > put some other fix in place, I will drop those two patches in favor of > > your fix. > > Ok. I'm a bit troubled by this bug, I hate to push a fix for a bug I > don't understand nor can reproduce. I would be happy to talk you through running the TREE04 rcutorture scenario, if you would like. I just verified that I can reproduce this on a single-socket four-core (8 hardware threads) x86 system running v4.15-rc1, so I would guess that you have access to hardware that can reproduce it. In the meantime, please feel free to take a look at the file tools/testing/selftests/rcutorture/doc/initrd.txt in the kernel source. This file tells how to create the initrd that rcutorture uses to avoid the need to maintain root partitions. Once you have that in place in tools/testing/selftests/rcutorture/initrd (as a expanded file tree, not any sort of archive) the reproducer is as follows, run from the top level of the kernel source tree: bash tools/testing/selftests/rcutorture/bin/kvm.sh --duration 5 --configs TREE04 This will output a bunch of rcutorture status/progress text, ending in something like the following: --- Sat Dec 9 09:49:26 PST 2017 Test summary: Results directory: /home/git/linux-2.6/tools/testing/selftests/rcutorture/res/2017.12.09-09:49:26 tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 7 --duration 5 --configs TREE04 TREE04 --- 350 grace periods (1.16667 per second) WARNING: Assertion failure in /home/git/linux-2.
Re: [PATCH 3/3] staging: pi433: Remove unnecessary #ifdef DEBUG around dev_dbg
On Sat, 2017-12-09 at 19:02 +0100, Simon Sandström wrote:
> dev_dbg() already depends on DEBUG.
Not quite.
It depends on CONFIG_DYNAMIC_DEBUG or DEBUG
In any case, this patch is fine.
> Signed-off-by: Simon Sandström
> ---
> drivers/staging/pi433/rf69.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> index 04a74423c325..6e38e6a515a4 100644
> --- a/drivers/staging/pi433/rf69.c
> +++ b/drivers/staging/pi433/rf69.c
> @@ -767,9 +767,7 @@ int rf69_read_fifo (struct spi_device *spi, u8 *buffer,
> unsigned int size)
> int retval;
>
> if (size > FIFO_SIZE) {
> -#ifdef DEBUG
> dev_dbg(&spi->dev, "read fifo: passed in buffer bigger then
> internal buffer\n");
> -#endif
> return -EMSGSIZE;
> }
>
> @@ -801,9 +799,7 @@ int rf69_write_fifo(struct spi_device *spi, u8 *buffer,
> unsigned int size)
> u8 local_buffer[FIFO_SIZE + 1];
>
> if (size > FIFO_SIZE) {
> -#ifdef DEBUG
> dev_dbg(&spi->dev, "read fifo: passed in buffer bigger then
> internal buffer\n");
> -#endif
> return -EMSGSIZE;
> }
>
[PATCH 3/3] serial: ioc3: Adjust two function calls together with a variable assignment
From: Markus Elfring
Date: Sat, 9 Dec 2017 18:48:57 +0100
The script "checkpatch.pl" pointed information out like the following.
ERROR: do not use assignment in if condition
Thus fix the affected source code places.
Signed-off-by: Markus Elfring
---
drivers/tty/serial/ioc3_serial.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/ioc3_serial.c b/drivers/tty/serial/ioc3_serial.c
index d211bb1407d3..0170d6f2bcdf 100644
--- a/drivers/tty/serial/ioc3_serial.c
+++ b/drivers/tty/serial/ioc3_serial.c
@@ -1540,8 +1540,8 @@ ioc3uart_intr_one(struct ioc3_submodule *is,
* hasn't been delivered to the cpu yet anyway, even
* though we see it as asserted when we read the sio_ir.
*/
- if ((sio_ir = PENDING(card_ptr, idd))
- & hooks->intr_rx_high) {
+ sio_ir = PENDING(card_ptr, idd);
+ if (sio_ir & hooks->intr_rx_high) {
if (port->ip_flags & READ_ABORTED) {
rx_high_rd_aborted++;
}
@@ -2162,10 +2162,10 @@ static struct ioc3_submodule ioc3uart_ops = {
*/
static int __init ioc3uart_init(void)
{
- int ret;
-
/* register with serial core */
- if ((ret = uart_register_driver(&ioc3_uart)) < 0) {
+ int ret = uart_register_driver(&ioc3_uart);
+
+ if (ret < 0) {
printk(KERN_WARNING
"%s: Couldn't register IOC3 uart serial driver\n",
__func__);
--
2.15.1
[PATCH 2/3] serial: ioc3: Improve size determinations in ioc3uart_probe()
From: Markus Elfring
Date: Sat, 9 Dec 2017 18:38:13 +0100
Replace the specification of two data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/tty/serial/ioc3_serial.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/ioc3_serial.c b/drivers/tty/serial/ioc3_serial.c
index 0007c2d65028..d211bb1407d3 100644
--- a/drivers/tty/serial/ioc3_serial.c
+++ b/drivers/tty/serial/ioc3_serial.c
@@ -2016,7 +2016,7 @@ ioc3uart_probe(struct ioc3_submodule *is, struct
ioc3_driver_data *idd)
DPRINT_CONFIG(("%s (0x%p, 0x%p)\n", __func__, is, idd));
- card_ptr = kzalloc(sizeof(struct ioc3_card), GFP_KERNEL);
+ card_ptr = kzalloc(sizeof(*card_ptr), GFP_KERNEL);
if (!card_ptr)
return -ENOMEM;
@@ -2034,7 +2034,7 @@ ioc3uart_probe(struct ioc3_submodule *is, struct
ioc3_driver_data *idd)
/* Create port structures for each port */
for (phys_port = 0; phys_port < PORTS_PER_CARD; phys_port++) {
- port = kzalloc(sizeof(struct ioc3_port), GFP_KERNEL);
+ port = kzalloc(sizeof(*port), GFP_KERNEL);
if (!port) {
ret = -ENOMEM;
goto out4;
--
2.15.1
[PATCH 1/3] serial: ioc3: Delete error messages for a failed memory allocation in ioc3uart_probe()
From: Markus Elfring
Date: Sat, 9 Dec 2017 18:34:36 +0100
Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/tty/serial/ioc3_serial.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/ioc3_serial.c b/drivers/tty/serial/ioc3_serial.c
index d8a1cdd6a53d..0007c2d65028 100644
--- a/drivers/tty/serial/ioc3_serial.c
+++ b/drivers/tty/serial/ioc3_serial.c
@@ -2017,11 +2017,9 @@ ioc3uart_probe(struct ioc3_submodule *is, struct
ioc3_driver_data *idd)
DPRINT_CONFIG(("%s (0x%p, 0x%p)\n", __func__, is, idd));
card_ptr = kzalloc(sizeof(struct ioc3_card), GFP_KERNEL);
- if (!card_ptr) {
- printk(KERN_WARNING "ioc3_attach_one"
- ": unable to get memory for the IOC3\n");
+ if (!card_ptr)
return -ENOMEM;
- }
+
idd->data[is->id] = card_ptr;
Submodule_slot = is->id;
@@ -2038,8 +2036,6 @@ ioc3uart_probe(struct ioc3_submodule *is, struct
ioc3_driver_data *idd)
for (phys_port = 0; phys_port < PORTS_PER_CARD; phys_port++) {
port = kzalloc(sizeof(struct ioc3_port), GFP_KERNEL);
if (!port) {
- printk(KERN_WARNING
- "IOC3 serial memory not available for port\n");
ret = -ENOMEM;
goto out4;
}
--
2.15.1
[PATCH 2/3] staging: pi433: Remove function entry dev_dbg()
ftrace can be used to trace function calls, so there is no need to use
dev_dbg() here.
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/rf69.c | 156 ---
1 file changed, 156 deletions(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 39920240c05c..04a74423c325 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -64,10 +64,6 @@ static inline int rf69_read_mod_write(struct spi_device
*spi, u8 reg, u8 mask, u
int rf69_set_mode(struct spi_device *spi, enum mode mode)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: mode");
-#endif
-
switch (mode) {
case transmit:return rf69_read_mod_write(spi, REG_OPMODE,
MASK_OPMODE_MODE, OPMODE_MODE_TRANSMIT);
case receive: return rf69_read_mod_write(spi, REG_OPMODE,
MASK_OPMODE_MODE, OPMODE_MODE_RECEIVE);
@@ -91,10 +87,6 @@ int rf69_set_data_mode(struct spi_device *spi, u8 data_mode)
int rf69_set_modulation(struct spi_device *spi, enum modulation modulation)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: modulation");
-#endif
-
switch (modulation) {
case OOK: return rf69_read_mod_write(spi, REG_DATAMODUL,
MASK_DATAMODUL_MODULATION_TYPE, DATAMODUL_MODULATION_TYPE_OOK);
case FSK: return rf69_read_mod_write(spi, REG_DATAMODUL,
MASK_DATAMODUL_MODULATION_TYPE, DATAMODUL_MODULATION_TYPE_FSK);
@@ -108,10 +100,6 @@ enum modulation rf69_get_modulation(struct spi_device *spi)
{
u8 currentValue;
-#ifdef DEBUG
- dev_dbg(&spi->dev, "get: mode");
-#endif
-
currentValue = rf69_read_reg(spi, REG_DATAMODUL);
switch (currentValue & MASK_DATAMODUL_MODULATION_TYPE >> 3) { // TODO
improvement: change 3 to define
@@ -124,10 +112,6 @@ enum modulation rf69_get_modulation(struct spi_device *spi)
int rf69_set_modulation_shaping(struct spi_device *spi,
enum mod_shaping mod_shaping)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: mod shaping");
-#endif
-
switch (rf69_get_modulation(spi)) {
case FSK:
switch (mod_shaping) {
@@ -162,10 +146,6 @@ int rf69_set_bit_rate(struct spi_device *spi, u16 bitRate)
u8 msb;
u8 lsb;
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: bit rate");
-#endif
-
// check input value
bitRate_min = F_OSC / 8388608; // 8388608 = 2^23;
if (bitRate < bitRate_min) {
@@ -199,10 +179,6 @@ int rf69_set_deviation(struct spi_device *spi, u32
deviation)
u8 lsb;
u64 factor = 100; // to improve precision of calculation
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: deviation");
-#endif
-
// TODO: Dependency to bitrate
if (deviation < 600 || deviation > 50) {
dev_dbg(&spi->dev, "set_deviation: illegal input param");
@@ -248,10 +224,6 @@ int rf69_set_frequency(struct spi_device *spi, u32
frequency)
u8 lsb;
u64 factor = 100; // to improve precision of calculation
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: frequency");
-#endif
-
// calculat f step
f_step = F_OSC * factor;
do_div(f_step, 524288); // 524288 = 2^19
@@ -297,10 +269,6 @@ int rf69_disable_amplifier(struct spi_device *spi, u8
amplifier_mask)
int rf69_set_output_power_level(struct spi_device *spi, u8 powerLevel)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: power level");
-#endif
-
// TODO: Dependency to PA0,1,2 setting
powerLevel += 18;
@@ -316,10 +284,6 @@ int rf69_set_output_power_level(struct spi_device *spi, u8
powerLevel)
int rf69_set_pa_ramp(struct spi_device *spi, enum paRamp paRamp)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: pa ramp");
-#endif
-
switch (paRamp) {
case ramp3400: return rf69_write_reg(spi, REG_PARAMP, PARAMP_3400);
case ramp2000: return rf69_write_reg(spi, REG_PARAMP, PARAMP_2000);
@@ -345,10 +309,6 @@ int rf69_set_pa_ramp(struct spi_device *spi, enum paRamp
paRamp)
int rf69_set_antenna_impedance(struct spi_device *spi, enum antennaImpedance
antennaImpedance)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: antenna impedance");
-#endif
-
switch (antennaImpedance) {
case fiftyOhm: return rf69_clear_bit(spi, REG_LNA, MASK_LNA_ZIN);
case twohundretOhm: return rf69_set_bit(spi, REG_LNA, MASK_LNA_ZIN);
@@ -360,10 +320,6 @@ int rf69_set_antenna_impedance(struct spi_device *spi,
enum antennaImpedance ant
int rf69_set_lna_gain(struct spi_device *spi, enum lnaGain lnaGain)
{
-#ifdef DEBUG
- dev_dbg(&spi->dev, "set: lna gain");
-#endif
-
switch (lnaGain) {
case automatic: return rf69_read_mod_write(spi, REG_LNA,
MASK_LNA_GAIN, LNA_GAIN_AUTO);
case max:return rf69_read_mod_write(spi, REG_LNA,
MASK_LNA_GAIN, LNA_GAIN_MAX);
@@ -382,10 +338,6 @@ enum lnaGain rf69_get_lna_gain(struct spi_device *spi)
{
u8 currentValue;
-#ifdef DEBUG
- dev_db
[PATCH 1/3] staging: pi433: Remove indentation on #ifdef blocks
ifdef blocks should not increase indentation level.
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/rf69.c | 314 +--
1 file changed, 153 insertions(+), 161 deletions(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 8b6d68f10e8a..39920240c05c 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -64,9 +64,9 @@ static inline int rf69_read_mod_write(struct spi_device *spi,
u8 reg, u8 mask, u
int rf69_set_mode(struct spi_device *spi, enum mode mode)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: mode");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: mode");
+#endif
switch (mode) {
case transmit:return rf69_read_mod_write(spi, REG_OPMODE,
MASK_OPMODE_MODE, OPMODE_MODE_TRANSMIT);
@@ -91,9 +91,9 @@ int rf69_set_data_mode(struct spi_device *spi, u8 data_mode)
int rf69_set_modulation(struct spi_device *spi, enum modulation modulation)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: modulation");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: modulation");
+#endif
switch (modulation) {
case OOK: return rf69_read_mod_write(spi, REG_DATAMODUL,
MASK_DATAMODUL_MODULATION_TYPE, DATAMODUL_MODULATION_TYPE_OOK);
@@ -108,9 +108,9 @@ enum modulation rf69_get_modulation(struct spi_device *spi)
{
u8 currentValue;
- #ifdef DEBUG
- dev_dbg(&spi->dev, "get: mode");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "get: mode");
+#endif
currentValue = rf69_read_reg(spi, REG_DATAMODUL);
@@ -124,9 +124,9 @@ enum modulation rf69_get_modulation(struct spi_device *spi)
int rf69_set_modulation_shaping(struct spi_device *spi,
enum mod_shaping mod_shaping)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: mod shaping");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: mod shaping");
+#endif
switch (rf69_get_modulation(spi)) {
case FSK:
@@ -162,9 +162,9 @@ int rf69_set_bit_rate(struct spi_device *spi, u16 bitRate)
u8 msb;
u8 lsb;
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: bit rate");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: bit rate");
+#endif
// check input value
bitRate_min = F_OSC / 8388608; // 8388608 = 2^23;
@@ -199,9 +199,9 @@ int rf69_set_deviation(struct spi_device *spi, u32
deviation)
u8 lsb;
u64 factor = 100; // to improve precision of calculation
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: deviation");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: deviation");
+#endif
// TODO: Dependency to bitrate
if (deviation < 600 || deviation > 50) {
@@ -248,9 +248,9 @@ int rf69_set_frequency(struct spi_device *spi, u32
frequency)
u8 lsb;
u64 factor = 100; // to improve precision of calculation
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: frequency");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: frequency");
+#endif
// calculat f step
f_step = F_OSC * factor;
@@ -297,9 +297,9 @@ int rf69_disable_amplifier(struct spi_device *spi, u8
amplifier_mask)
int rf69_set_output_power_level(struct spi_device *spi, u8 powerLevel)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: power level");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: power level");
+#endif
// TODO: Dependency to PA0,1,2 setting
powerLevel += 18;
@@ -316,9 +316,9 @@ int rf69_set_output_power_level(struct spi_device *spi, u8
powerLevel)
int rf69_set_pa_ramp(struct spi_device *spi, enum paRamp paRamp)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: pa ramp");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: pa ramp");
+#endif
switch (paRamp) {
case ramp3400: return rf69_write_reg(spi, REG_PARAMP, PARAMP_3400);
@@ -345,9 +345,9 @@ int rf69_set_pa_ramp(struct spi_device *spi, enum paRamp
paRamp)
int rf69_set_antenna_impedance(struct spi_device *spi, enum antennaImpedance
antennaImpedance)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: antenna impedance");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: antenna impedance");
+#endif
switch (antennaImpedance) {
case fiftyOhm: return rf69_clear_bit(spi, REG_LNA, MASK_LNA_ZIN);
@@ -360,9 +360,9 @@ int rf69_set_antenna_impedance(struct spi_device *spi, enum
antennaImpedance ant
int rf69_set_lna_gain(struct spi_device *spi, enum lnaGain lnaGain)
{
- #ifdef DEBUG
- dev_dbg(&spi->dev, "set: lna gain");
- #endif
+#ifdef DEBUG
+ dev_dbg(&spi->dev, "set: lna gain");
+#endif
switch (lnaGain) {
case automatic: return rf69_read_mod_write(spi, REG_LNA,
MASK_LNA
[PATCH 0/3] staging: pi433: Refactor usage of dev_dbg and #ifdef DEBUG
These patches refactors the usage of dev_dbg and #ifdef DEBUG in rf69.c. All dev_dbg() calls that just prints the function name are removed, since we have ftrace. For all other calls the #ifdef DEBUG block around them are removed. There are still two more defines used in rf69.c: DEBUG_FIFO_ACCESS and DEBUG_VALUES. Perhaps they should be removed as well? - Simon --- Simon Sandström (3): staging: pi433: Remove indentation on #ifdef blocks staging: pi433: Remove function entry dev_dbg() staging: pi433: Remove unnecessary #ifdef DEBUG around dev_dbg drivers/staging/pi433/rf69.c | 232 ++- 1 file changed, 32 insertions(+), 200 deletions(-) -- 2.11.0
[PATCH 3/3] staging: pi433: Remove unnecessary #ifdef DEBUG around dev_dbg
dev_dbg() already depends on DEBUG.
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/rf69.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 04a74423c325..6e38e6a515a4 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -767,9 +767,7 @@ int rf69_read_fifo (struct spi_device *spi, u8 *buffer,
unsigned int size)
int retval;
if (size > FIFO_SIZE) {
-#ifdef DEBUG
dev_dbg(&spi->dev, "read fifo: passed in buffer bigger then
internal buffer\n");
-#endif
return -EMSGSIZE;
}
@@ -801,9 +799,7 @@ int rf69_write_fifo(struct spi_device *spi, u8 *buffer,
unsigned int size)
u8 local_buffer[FIFO_SIZE + 1];
if (size > FIFO_SIZE) {
-#ifdef DEBUG
dev_dbg(&spi->dev, "read fifo: passed in buffer bigger then
internal buffer\n");
-#endif
return -EMSGSIZE;
}
--
2.11.0
[PATCH 0/3] tty/serial/ioc3: Adjustments for three function implementations
From: Markus Elfring Date: Sat, 9 Dec 2017 19:00:19 +0100 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete error messages for a failed memory allocation in ioc3uart_probe() Improve size determinations in ioc3uart_probe() Adjust two function calls together with a variable assignment drivers/tty/serial/ioc3_serial.c | 22 +- 1 file changed, 9 insertions(+), 13 deletions(-) -- 2.15.1
[GIT PULL] Btrfs fixes for 4.15-rc3
Hi, this update contains a few fixes (error handling, quota leak, FUA vs nobarrier mount option). There's one one worth mentioning separately - an off-by-one fix that leads to overwriting first byte of an adjacent page with 0, out of bounds of the memory allocated by an ioctl. This is under a privileged part of the ioctl, can be triggerd in some subvolume layouts. After the last tags and branches mess [1], let me note that the pull url is pointed to the signed tag. There are no merge conflics. Please pull, thanks. [1] https://lkml.org/lkml/2017/11/29/952 The following changes since commit ea37d5998b50a72b9045ba60a132eeb20e1c4230: Btrfs: incremental send, fix wrong unlink path after renaming file (2017-11-28 17:15:30 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-4.15-rc3-tag for you to fetch changes up to c8bcbfbd239ed60a6562964b58034ac8a25f4c31: btrfs: Fix possible off-by-one in btrfs_search_path_in_tree (2017-12-07 00:35:15 +0100) Jeff Mahoney (2): btrfs: handle errors while updating refcounts in update_ref_for_cow btrfs: fix missing error return in btrfs_drop_snapshot Justin Maggard (1): btrfs: Fix quota reservation leak on preallocated files Nikolay Borisov (1): btrfs: Fix possible off-by-one in btrfs_search_path_in_tree Omar Sandoval (1): Btrfs: disable FUA if mounted with nobarrier fs/btrfs/ctree.c | 18 -- fs/btrfs/disk-io.c | 12 +--- fs/btrfs/extent-tree.c | 1 + fs/btrfs/inode.c | 2 ++ fs/btrfs/ioctl.c | 2 +- 5 files changed, 21 insertions(+), 14 deletions(-)
Re: [PATCH net-next] libbpf: add function to setup XDP
On Sat, Dec 09, 2017 at 09:34:46AM -0700, David Ahern wrote: > On 12/9/17 7:43 AM, Eric Leblond wrote: > > + /* started nested attribute for XDP */ > > + nla = (struct nlattr *)(((char *)&req) > > + + NLMSG_ALIGN(req.nh.nlmsg_len)); > > + nla->nla_type = NLA_F_NESTED | 43/*IFLA_XDP*/; > > as a part of the move into libbpf can the magic numbers be replaced by > the names directly and there as a comment? In general it would be nice to use names instead of numbers, but it's much bigger change then this patch, since it would require copying and syncing a bunch of headers into tools/ which may not be such a good idea in the end. Only removal of min() looks a bit suspicious to me. Eric, is it because it now comes from some header?
Re: [PATCH 4.14 00/75] 4.14.5-stable review
Den 09.12.2017 kl. 19:13, skrev Greg Kroah-Hartman:
On Sat, Dec 09, 2017 at 07:56:40AM +, Ivan Kozik wrote:
On Sat, Dec 9, 2017 at 7:45 AM, Greg Kroah-Hartman
wrote:
On Sat, Dec 09, 2017 at 03:34:24AM +, Ivan Kozik wrote:
I saw no problems on 8 of 9 machines, but the last one had a problem
because it used NVIDIA drivers (387); DKMS reported:
FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only
symbol 'ex_handler_refcount'
//usr/src/linux-headers-4.14.0-11-common/scripts/Makefile.modpost:92:
recipe for target '__modpost' failed
make[3]: *** [__modpost] Error 1
Is this a new issue? Does 4.14.4 have this issue?
I believe it is a new issue, because I have a 4.14.4 build and an
NVIDIA DKMS log for that 4.14.4 showing build success.
Odd, is 564c9cc84e2a ("locking/refcounts, x86/asm: Use unique .text
section for refcount exceptions") causing this?
That was my guess too, but I did not verify.
That feels really wrong here, I'd like to get some confirmation before I
add this patch...
It's needed.
The reason you hit in 4.14.5 queue is because of:
[PATCH 4.14 64/75] locking/refcounts, x86/asm: Enable
CONFIG_ARCH_HAS_REFCOUNT
From foo@baz Wed Dec 6 18:04:41 CET 2017
From: Kees Cook
Date: Sat, 2 Sep 2017 13:09:46 -0700
Subject: locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT
that does this:
- select ARCH_HAS_REFCOUNTif BROKEN
+ select ARCH_HAS_REFCOUNT
So it exposes previously hidden code
--
Thomas
[PATCH] Make "Memory Debugging" a menuconfig to ease disabling it all
No need to get into the submenu to disable all "Memory Debugging"-related config entries. This makes it easier to disable all "Memory Debugging" config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Changes since v1: Move some invisible config options ouit of the if/endif DEBUG_MEMORY block to alleviate the warnings: "selects XXX which has unmet direct dependencies" This moves the HAVE_ARCH_KASAN out of Kconfig.kasan Signed-off-by: Vincent Legoll --- lib/Kconfig.debug | 28 +--- lib/Kconfig.kasan | 3 --- 2 files changed, 17 insertions(+), 14 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 947d3e2ed5c2..19ca76e7b9ed 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -436,7 +436,10 @@ config DEBUG_KERNEL Say Y here if you are developing drivers or trying to debug and identify kernel problems. -menu "Memory Debugging" +menuconfig DEBUG_MEMORY + bool "Memory Debugging" + +if DEBUG_MEMORY source mm/Kconfig.debug @@ -539,9 +542,6 @@ config SLUB_STATS out which slabs are relevant to a particular load. Try running: slabinfo -DA -config HAVE_DEBUG_KMEMLEAK - bool - config DEBUG_KMEMLEAK bool "Kernel memory leak detector" depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK @@ -636,9 +636,6 @@ config DEBUG_VM_PGFLAGS If unsure, say N. -config ARCH_HAS_DEBUG_VIRTUAL - bool - config DEBUG_VIRTUAL bool "Debug VM translations" depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL @@ -708,9 +705,6 @@ config DEBUG_HIGHMEM This option enables additional error checking for high memory systems. Disable for production systems. -config HAVE_DEBUG_STACKOVERFLOW - bool - config DEBUG_STACKOVERFLOW bool "Check for stack overflows" depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW @@ -731,7 +725,19 @@ config DEBUG_STACKOVERFLOW source "lib/Kconfig.kasan" -endmenu # "Memory Debugging" +endif # DEBUG_MEMORY + +config HAVE_ARCH_KASAN + bool + +config ARCH_HAS_DEBUG_VIRTUAL + bool + +config HAVE_DEBUG_KMEMLEAK + bool + +config HAVE_DEBUG_STACKOVERFLOW + bool config ARCH_HAS_KCOV bool diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan index bd38aab05929..2396d5116e20 100644 --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -1,6 +1,3 @@ -config HAVE_ARCH_KASAN - bool - if HAVE_ARCH_KASAN config KASAN -- 2.14.1
[PATCH,v2] Make "Memory Debugging" a menuconfig to ease disabling it all
The v2 of the patch tries to do that, but the Kconfig.kasan modification is kind of infortunate, as it moves the HAVE_ARCH_KASAN config option out of that file. If this is not acceptable please advise on how I can achieve it. Thanks
Re: [PATCH v2] drivers: visorbus: move driver out of staging
On Fri, Dec 08, 2017 at 02:13:18PM -0800, Joe Perches wrote: > On Fri, 2017-12-08 at 21:55 +, Kershner, David A wrote: > > > -Original Message- > > > From: Joe Perches [mailto:j...@perches.com] > > > Sent: Friday, December 8, 2017 11:53 AM > > > To: Greg KH ; Kershner, David A > > > > > > Cc: jes.soren...@gmail.com; linux-kernel@vger.kernel.org; driverdev- > > > de...@linuxdriverproject.org; *S-Par-Maintainer > > > ; erik.arfvid...@gmail.com; > > > wadgaonkar...@gmail.com > > > Subject: Re: [PATCH v2] drivers: visorbus: move driver out of staging > > > > > > On Fri, 2017-12-08 at 16:39 +0100, Greg KH wrote: > > > > On Thu, Dec 07, 2017 at 12:11:07PM -0500, David Kershner wrote: > > > > > Move the visorbus driver out of staging > > > > (drivers/staging/unisys/visorbus) > > > > > and to drivers/visorbus. Modify the configuration and makefiles so > > > > they > > > > > now reference the new location. The s-Par header file visorbus.h that > > > > is > > > > > referenced by all s-Par drivers, is being moved into include/linux. > > > > > > Perhaps moving visorbus.h and visorbus_private.h to > > > drivers/visorbus would be better than adding more > > > relatively localized #include files to include/linux/ > > > > > > what about controlvmchannel? > > > > > > > The file visorbus.h is currently included by 4 drivers: visorbus and 3 > > other drivers that are staying in staging for now, but we plan to move out > > soon. > > OK. > > Where do you plan on moving the 3 other drivers? > > Today, these drivers (visorhba, visorinput, and visornic) > are all under the staging/unisys directory > > visorbus -> drivers/visorbus > visorhba -> ? > visorinput -> ? > visornic -> ? > > Perhaps all these, including visorbus, should be under virt/ > or perhaps visorbus should be under virt/ and the others > under drivers/virt/ They will move to the proper subsystem directory (storage, input, networking), when they are ready. thanks, greg k-h
Re: [PATCH] HID: elecom: rewrite report fixup for EX-G and future mice
On Thu, Dec 07, 2017 at 11:04:37AM +0100, Jiri Kosina wrote: > On Tue, 5 Dec 2017, Tomasz Kramkowski wrote: > > > On Mon, Dec 04, 2017 at 08:55:50PM +, Tomasz Kramkowski wrote: > > > +static void mouse_button_fixup(struct hid_device *hdev, > > > +__u8 *rdesc, unsigned int *rsize, > > > +int nbuttons) > > > > I've just remembered what has been bugging me yesterday when I was > > reviewing this patch. I had come to the realisation (and then > > subsequently forgotten) that this function should probably return __u8 * > > and also get assigned to rdesc on the other end. It seems to me that it > > makes most sense to allow for the possibility (although slim) of this > > function eventually being expanded to actually replace the report > > descriptor > > Sure, but you can extend the API of mouse_button_fixup() once such need > arises; no need to pass data pointers around without having actual use for > them. Alright, that's fine. Anything else to change before I send a v2? Also, would you like v2 in-reply-to the root of this thread or as its own thread? -- Tomasz Kramkowski | GPG: 40B037BA0A5B8680 | Web: https://the-tk.com/
Re: UDL's fbdev doesn't work for user-space apps
On Mon 2017-12-04 11:50:40, Jose Abreu wrote: > Hi Alexey, > > On 04-12-2017 11:32, Alexey Brodkin wrote: > > My first [probably incorrect] assumption is Xserver requires fbdev > > (/dev/fbX) > > and it cannot use DRI video card natively. Is that correct? > > > > > > Xserver can use DRI directly, you need to enable modesetting > driver in Xorg config or use the designated driver for your card > (if there is any). Still, dev/fb1 should work. Can be tested using dd, even :-) Best regards, Pavel > > e.g.: > > Section "Device" > Identifier "Card0" > Driver "modesetting" > Option "kmsdev" "/dev/dri/card0" > Option "SWcursor" "true" > BusID "PCI:X:X:X" > EndSection > > Best Regards, > Jose Miguel Abreu -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation
On Thu 2017-12-07 15:02:21, Michal Hocko wrote: > On Thu 07-12-17 13:58:05, Cyril Hrubis wrote: > > Hi! > > > >> (It does seem unfortunate that the man page cannot help the programmer > > > >> actually write correct code here. He or she is forced to read the > > > >> kernel > > > >> implementation, in order to figure out the true alignment rules. I was > > > >> hoping we could avoid that.) > > > > > > > > It would be nice if we had this information exported somehere so that we > > > > do not have to rely on per-architecture ifdefs. > > > > > > > > What about adding MapAligment or something similar to the /proc/meminfo? > > > > > > > > > > What's the use case you envision for that? I don't see how that would be > > > better than using SHMLBA, which is available at compiler time. Because > > > unless someone expects to be able to run an app that was compiled for > > > Arch X, on Arch Y (surely that's not requirement here?), I don't see how > > > the run-time check is any better. > > > > I guess that some kind of compile time constant in uapi headers will do > > as well, I'm really open to any solution that would expose this constant > > as some kind of official API. > > I am not sure this is really feasible. It is not only a simple alignment > thing. Look at ppc for example (slice_get_unmapped_area). Other > architectures might have even more complicated rules e.g. arm and its > cache_is_vipt_aliasing. Also this applies only on MAP_SHARED || file > backed mappings. > > I would really leave dogs sleeping... Trying to document all this in the > man page has chances to confuse more people than it has chances to help > those who already know all these nasty details. You don't have to provide all the details, but warning that there's arch- specific magic would be nice... Pavel (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 4.14 00/75] 4.14.5-stable review
On Sat, Dec 09, 2017 at 07:56:40AM +, Ivan Kozik wrote:
> On Sat, Dec 9, 2017 at 7:45 AM, Greg Kroah-Hartman
> wrote:
> > On Sat, Dec 09, 2017 at 03:34:24AM +, Ivan Kozik wrote:
> >> I saw no problems on 8 of 9 machines, but the last one had a problem
> >> because it used NVIDIA drivers (387); DKMS reported:
> >>
> >> FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only
> >> symbol 'ex_handler_refcount'
> >> //usr/src/linux-headers-4.14.0-11-common/scripts/Makefile.modpost:92:
> >> recipe for target '__modpost' failed
> >> make[3]: *** [__modpost] Error 1
> >
> > Is this a new issue? Does 4.14.4 have this issue?
>
> I believe it is a new issue, because I have a 4.14.4 build and an
> NVIDIA DKMS log for that 4.14.4 showing build success.
>
> > Odd, is 564c9cc84e2a ("locking/refcounts, x86/asm: Use unique .text
> > section for refcount exceptions") causing this?
>
> That was my guess too, but I did not verify.
That feels really wrong here, I'd like to get some confirmation before I
add this patch...
thanks,
greg k-h
[PATCH] Change some filesystem menus into menuconfig to ease disabling it all
No need to get into the submenu to disable all related config entries. This makes it easier to disable all related config options without entering the submenu. It will also enable one to see that en/dis-abled state from the outside menu. This is only intended to change menuconfig UI, not change the config dependencies. Signed-off-by: Vincent Legoll --- fs/Kconfig | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/fs/Kconfig b/fs/Kconfig index 7aee6d699fd6..94ee1422e995 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -105,29 +105,38 @@ source "fs/autofs4/Kconfig" source "fs/fuse/Kconfig" source "fs/overlayfs/Kconfig" -menu "Caches" +menuconfig FS_CACHE_MENU + bool "Caches" + +if FS_CACHE_MENU source "fs/fscache/Kconfig" source "fs/cachefiles/Kconfig" -endmenu +endif # FS_CACHE_MENU if BLOCK -menu "CD-ROM/DVD Filesystems" +menuconfig FS_CDVD_MENU + bool "CD-ROM/DVD Filesystems" + +if FS_CDVD_MENU source "fs/isofs/Kconfig" source "fs/udf/Kconfig" -endmenu +endif # FS_CDVD_MENU endif # BLOCK if BLOCK -menu "DOS/FAT/NT Filesystems" +menuconfig FS_FAT_MENU + bool "DOS/FAT/NT Filesystems" + +if FS_FAT_MENU source "fs/fat/Kconfig" source "fs/ntfs/Kconfig" -endmenu +endif # FS_FAT_MENU endif # BLOCK menu "Pseudo filesystems" -- 2.14.1
Re: [PATCH 4.4 13/49] usb: dwc2: Fix UDC state tracking
On Fri, Dec 08, 2017 at 03:37:17AM +, Ben Hutchings wrote:
> On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > From: John Stultz
> >
> >
> > [ Upstream commit ce2b21a4e5ce042c0a42c9db8fa9e0f849427d5e ]
> >
> > It has been noticed that the dwc2 udc state reporting doesn't
> > seem to work (at least on HiKey boards). Where after the initial
> > setup, the sysfs /sys/class/udc/f72c.usb/state file would
> > report "configured" no matter the state of the OTG port.
> >
> > This patch adds a call so that we report to the UDC layer when
> > the gadget device is disconnected.
> >
> > This patch does depend on the previous patch ("usb: dwc2:
> > Improve gadget state disconnection handling") in this patch set
> > in order to properly work.
>
> Then you should add that (commit d2471d4a24df).
Ah, but that patch doesn't apply :(
So, I've dropped this one, and the one after this one (which depended on
this one), so all should be back to how things were.
Sasha, can you fix this up and submit all 3 for the 4.4, 4.9 and 4.14
trees sometime in the future?
thanks,
greg k-h
Re: [PATCH v2 4/7] drm/rockchip: dw_hdmi: add inno hdmi phy ops
Hi Algea,
Am Samstag, 30. September 2017, 09:44:46 CET schrieb Algea Cao:
> Because some RK chips use inno hdmi phy, such as RK3328, we add
> inno hdmi phy ops.
>
> Signed-off-by: Algea Cao
> ---
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 110
> +++-
> 1 file changed, 107 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index 09c77f9..7658b2f 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -12,7 +12,7 @@
> #include
> #include
> #include
> -
> +#include
> #include
> #include
> #include
> @@ -26,6 +26,18 @@
> #define RK3288_HDMI_LCDC_SEL BIT(4)
> #define RK3399_GRF_SOC_CON20 0x6250
> #define RK3399_HDMI_LCDC_SEL BIT(6)
> +#define RK3328_GRF_SOC_CON2 0x0408
> +#define RK3328_DDC_MASK_EN ((3 << 10) | (3 << (10 + 16)))
> +#define RK3328_GRF_SOC_CON3 0x040c
> +#define RK3328_IO_CTRL_BY_HDMI (0xf000 | BIT(13) | BIT(12))
> +#define RK3328_GRF_SOC_CON4 0x0410
> +#define RK3328_IO_3V_DOMAIN (7 << (9 + 16))
> +#define RK3328_IO_5V_DOMAIN ((7 << 9) | (3 << (9 + 16)))
This is slightly confusing. (9+16) is obviously the write-enable-mask, so
shouldn't the write-enable-mask not at least cover the changed bits?
> +static enum drm_connector_status
> +inno_dw_hdmi_phy_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
> +{
> + struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
> + enum drm_connector_status status;
> +
> + status = dw_hdmi_phy_read_hpd(dw_hdmi, data);
> +
> + if (hdmi->dev_type == RK3228_HDMI)
> + return status;
There is no need to encode the functionality for both variants
(and possibly later ones) into one function.
As Neil said in his reply to patch2, we don't really want to carry
that dev_type property, so why don't you just define this as
rk3328_inno_phy_read_hpd and then use it like
static const struct dw_hdmi_phy_ops rk3228_dw_hdmi_phy_ops = {
.init = inno_dw_hdmi_phy_init,
.disable= inno_dw_hdmi_phy_disable,
.read_hpd = dw_hdmi_phy_read_hpd,
};
static const struct dw_hdmi_phy_ops rk3328_dw_hdmi_phy_ops = {
.init = inno_dw_hdmi_phy_init,
.disable= inno_dw_hdmi_phy_disable,
.read_hpd = rk3328_inno_phy_read_hpd,
};
> + if (status == connector_status_connected)
> + regmap_write(hdmi->regmap,
> + RK3328_GRF_SOC_CON4,
> + RK3328_IO_5V_DOMAIN);
> + else
> + regmap_write(hdmi->regmap,
> + RK3328_GRF_SOC_CON4,
> + RK3328_IO_3V_DOMAIN);
That should definitely get a comment explaining what this is doing and
why :-) . Especially as it seems related to the plug/unplug events.
According to the TRM, the hdmiphy IP block has its own interrupt. Can
you tell me if it is firing on hotplug events? Because I'm wondering if
these GRF settings wouldn't be better live in the hdmiphy driver
[if it gets an irq on plug/unplug], which in turn would make the phy
handling in dw_hdmi a lot easier.
> + return status;
> +}
> +
[...]
> @@ -361,7 +453,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
> struct device *master,
> return -ENOMEM;
>
> match = of_match_node(dw_hdmi_rockchip_dt_ids, pdev->dev.of_node);
> - plat_data = match->data;
> + plat_data = (struct dw_hdmi_plat_data *)match->data;
> hdmi->dev = &pdev->dev;
> hdmi->chip_data = plat_data->phy_data;
> hdmi->dev_type = plat_data->dev_type;
> @@ -383,6 +475,18 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
> struct device *master,
> return ret;
> }
>
> + if (hdmi->dev_type == RK3328_HDMI || hdmi->dev_type == RK3228_HDMI) {
> + hdmi->phy = devm_phy_get(dev, "hdmi_phy");
> + if (IS_ERR(hdmi->phy)) {
> + ret = PTR_ERR(hdmi->phy);
> + dev_err(dev, "failed to get phy: %d\n", ret);
> + return ret;
> + }
> + plat_data->phy_data = hdmi;
> + ret = inno_dw_hdmi_init(hdmi);
> + if (ret < 0)
> + return ret;
> + }
You could also just declare it optional in the binding, try to get the phy
via devm_phy_optional_get and if it's NULL just assume that it's the
regular internal phy as with previous socs. That way you can drop the
dev-type-check.
Aka, if a phy is defined we are pretty sure we want to use that one :-) .
Heiko
Re: [PATCH 4.4 20/49] usbip: tools: Install all headers needed for libusbip development
On Fri, Dec 08, 2017 at 03:56:40AM +, Ben Hutchings wrote:
> On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Ben Hutchings
> >
> >
> > [ Upstream commit c15562c0dcb2c7f26e891923b784cf1926b8c833 ]
> >
> > usbip_host_driver.h now depends on several additional headers, which
> > need to be installed along with it.
> >
> > Fixes: 021aed845303 ("staging: usbip: userspace: migrate usbip_host_driver
> > ...")
> > Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with
> > ...")
> > Signed-off-by: Ben Hutchings
> > Acked-by: Shuah Khan
> > Signed-off-by: Greg Kroah-Hartman
> > Signed-off-by: Sasha Levin
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > tools/usb/usbip/Makefile.am |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > --- a/tools/usb/usbip/Makefile.am
> > +++ b/tools/usb/usbip/Makefile.am
> > @@ -1,6 +1,7 @@
> > SUBDIRS := libsrc src
> > includedir = @includedir@/usbip
> > include_HEADERS := $(addprefix libsrc/, \
> > - usbip_common.h vhci_driver.h usbip_host_driver.h)
> > + usbip_common.h vhci_driver.h usbip_host_driver.h \
> > + list.h sysfs_utils.h usbip_host_common.h)
>
> usbip_host_common.h was added in 4.7 (by the second commit listed
> above), so for 4.4 and 3.18 it should not be added to this list.
Thanks, now dropped from those trees.
Many thanks for the great review.
greg k-h
Re: [PATCH 4.4 00/49] 4.4.105-stable review
On Fri, Dec 08, 2017 at 12:00:47PM -0800, Kevin Hilman wrote: > kernelci.org bot writes: > > > stable-rc/linux-4.4.y boot: 122 boots: 2 failed, 106 passed with 12 > > offline, 2 conflicts (v4.4.104-50-gffc1d3fcd46a) > > > > Full Boot Summary: > > https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.104-50-gffc1d3fcd46a/ > > Full Build Summary: > > https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.104-50-gffc1d3fcd46a/ > > > > Tree: stable-rc > > Branch: linux-4.4.y > > Git Describe: v4.4.104-50-gffc1d3fcd46a > > Git Commit: ffc1d3fcd46a59815958ce25e4e70da1a8a5799d > > Git URL: > > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > Tested: 62 unique boards, 20 SoC families, 18 builds out of 182 > > > > Boot Regressions Detected: > > > > arm: > > > > exynos_defconfig: > > exynos5422-odroidxu3: > > lab-collabora: failing since 31 days (last pass: > > v4.4.95-21-g32458fcb7bd6 - first fail: v4.4.96-41-g336421367b9c) > > exynos5422-odroidxu3_rootfs:nfs: > > lab-collabora: failing since 23 days (last pass: > > v4.4.95-21-g32458fcb7bd6 - first fail: v4.4.97-57-g528c687b455d) > > TL;DR; All is well. > > These two are passing in another lab, so this is a board/lab setup issue > under. Guillaume (Cc'd) is investigating. I figured with a lab that was failing for that long, I didn't need to worry about it. thanks, greg k-h > Kevin
Re: [PATCH 4.4 38/49] xen-netfront: Improve error handling during initialization
On Fri, Dec 08, 2017 at 05:10:49AM +, Ben Hutchings wrote:
> On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > From: Ross Lagerwall
> >
> >
> > [ Upstream commit e2e004acc7cbe3c531e752a270a74e95cde3ea48 ]
> [...]
> > @@ -1950,9 +1942,10 @@ abort_transaction_no_dev_fatal:
> > xenbus_transaction_end(xbt, 1);
> > destroy_ring:
> > xennet_disconnect_backend(info);
> > - kfree(info->queues);
> > - info->queues = NULL;
> > + xennet_destroy_queues(info);
> > out:
> > + unregister_netdev(info->netdev);
> > + xennet_free_netdev(info->netdev);
> > return err;
> > }
>
> This last bit of cleanup looks wrong. It was subsequently changed
> upstream by:
>
> 86b5672b1adb xen-netfront: avoid crashing on resume after a failure in
> talk_to_netback()
Good catch, but it's d86b5672b1ad ("xen-netfront: avoid crashing on
resume after a failure in talk_to_netback()")
:)
thanks,
greg k-h
Re: [PATCH] Make "Memory Debugging" a menuconfig to ease disabling it all
On 12/09/2017 04:40 AM, Vincent Legoll wrote: > This patch introduces some Kconfig warnings: > > warning: (X86) selects HAVE_DEBUG_KMEMLEAK which has unmet direct > dependencies (DEBUG_MEMORY) > warning: (X86) selects HAVE_ARCH_KASAN which has unmet direct > dependencies (DEBUG_MEMORY) > warning: (X86) selects ARCH_HAS_DEBUG_VIRTUAL which has unmet direct > dependencies (DEBUG_MEMORY) > warning: (X86) selects HAVE_DEBUG_STACKOVERFLOW which has unmet direct > dependencies (DEBUG_MEMORY) > > What would be the best way to fix that ? > > excluding those config options from the "if DEBUG_MEMORY" code > block seems to alleviate the warnings, but is that OK to do ? > > Would moving them out of the if/endif block be acceptable ? That sounds OK to me since none of them have prompts, i.e., they are not user visible, but they are indicators of what the arch supports. -- ~Randy
Re: [PATCH 4.4 33/49] net: sctp: fix array overrun read on sctp_timer_tbl
On Fri, Dec 08, 2017 at 04:34:51AM +, Ben Hutchings wrote:
> On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > From: Colin Ian King
> >
> >
> > [ Upstream commit 0e73fc9a56f22f2eec4d2b2910c649f7af67b74d ]
> >
> > The comparison on the timeout can lead to an array overrun
> > read on sctp_timer_tbl because of an off-by-one error. Fix
> > this by using < instead of <= and also compare to the array
> > size rather than SCTP_EVENT_TIMEOUT_MAX.
> >
> > Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
>
> SCTP_EVENT_TIMEOUT_MAX is one less than the array size, so the bounds
> check using <= was correct. This is cleanup, not a bug fix.
Ah, I was wondering why no one caught this earlier for submission.
Coverity isn't the smartest tool at times :(
thanks,
greg k-h
Re: [PATCH 4.4 29/49] nfs: Dont take a reference on fl->fl_file for LOCK operation
On Fri, Dec 08, 2017 at 04:18:58AM +, Ben Hutchings wrote:
> On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Benjamin Coddington
> >
> >
> > [ Upstream commit 4b09ec4b14a168bf2c687e1f598140c3c11e9222 ]
> >
> > I have reports of a crash that look like __fput() was called twice for
> > a NFSv4.0 file. It seems possible that the state manager could try to
> > reclaim a lock and take a reference on the fl->fl_file at the same time the
> > file is being released if, during the close(), a signal interrupts the wait
> > for outstanding IO while removing locks which then skips the removal
> > of that lock.
> >
> > Since 83bfff23e9ed ("nfs4: have do_vfs_lock take an inode pointer") has
> > removed the need to traverse fl->fl_file->f_inode in nfs4_lock_done(),
> > taking that reference is no longer necessary.
> [...]
>
> No objection to this in 4.4, but that other commit only went into 4.2
> so this fix doesn't look suitable for 3.18.
Good catch, now dropped, thanks.
greg k-h
Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray
On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote: > 1. Using lockdep_set_novalidate_class() for anything other > than device->mutex will throw checkpatch warnings. Nice. (*) [] > (*) checkpatch.pl is considered mostly harmful round here, too, > but that's another rant How so? > (**) the frequent occurrence of "core code/devs aren't held to the > same rules/standard as everyone else" is another rant I have stored > up for a rainy day. Yeah. I wouldn't mind reading that one... Rainy season is starting right about now here too.
Re: kernel BUG at net/core/skbuff.c:LINE! (2)
On Sat, 2017-12-09 at 19:23 +0800, Xin Long wrote:
> On Fri, Dec 8, 2017 at 4:45 PM, Xin Long
> wrote:
> > On Fri, Dec 8, 2017 at 4:16 PM, syzbot
> > > .com>
> > wrote:
> > > syzkaller has found reproducer for the following crash on
> > > 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> > > git://git.cmpxchg.org/linux-mmots.git/master
> > > compiler: gcc (GCC) 7.1.1 20170620
> > > .config is attached
> > > Raw console output is attached.
> > >
> > > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > > for information about syzkaller reproducers
> > >
> > >
> > > skbuff: skb_over_panic: text:10b86b8d len:196 put:20
> > > head:3b477e60 data:0e85441e tail:0xd4 end:0xc0
> > > dev:lo
> > > [ cut here ]
> > > kernel BUG at net/core/skbuff.c:104!
> > > invalid opcode: [#1] SMP KASAN
> > > Dumping ftrace buffer:
> > > (ftrace buffer empty)
> > > Modules linked in:
> > > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.15.0-rc2-mm1+ #39
> > > Hardware name: Google Google Compute Engine/Google Compute
> > > Engine, BIOS
> > > Google 01/01/2011
> > > RIP: 0010:skb_panic+0x15c/0x1f0 net/core/skbuff.c:100
> > > RSP: 0018:8801db307508 EFLAGS: 00010286
> > > RAX: 0082 RBX: 8801c517e840 RCX:
> > > RDX: 0082 RSI: 11003b660e61 RDI: ed003b660e95
> > > RBP: 8801db307570 R08: 11003b660e23 R09:
> > > R10: R11: R12: 85bd4020
> > > R13: 84754ed2 R14: 0014 R15: 8801c4e26540
> > > FS: () GS:8801db30()
> > > knlGS:
> > > CS: 0010 DS: ES: CR0: 80050033
> > > CR2: 00463610 CR3: 0001c6698000 CR4: 001406e0
> > > DR0: DR1: DR2:
> > > DR3: DR6: fffe0ff0 DR7: 0400
> > > Call Trace:
> > >
> > > skb_over_panic net/core/skbuff.c:109 [inline]
> > > skb_put+0x181/0x1c0 net/core/skbuff.c:1694
> > > add_grhead.isra.24+0x42/0x3b0 net/ipv6/mcast.c:1695
> > > add_grec+0xa55/0x1060 net/ipv6/mcast.c:1817
> > > mld_send_cr net/ipv6/mcast.c:1903 [inline]
> > > mld_ifc_timer_expire+0x4d2/0x770 net/ipv6/mcast.c:2448
> > > call_timer_fn+0x23b/0x840 kernel/time/timer.c:1320
> > > expire_timers kernel/time/timer.c:1357 [inline]
> > > __run_timers+0x7e1/0xb60 kernel/time/timer.c:1660
> > > run_timer_softirq+0x4c/0xb0 kernel/time/timer.c:1686
> > > __do_softirq+0x29d/0xbb2 kernel/softirq.c:285
> > > invoke_softirq kernel/softirq.c:365 [inline]
> > > irq_exit+0x1d3/0x210 kernel/softirq.c:405
> > > exiting_irq arch/x86/include/asm/apic.h:540 [inline]
> > > smp_apic_timer_interrupt+0x16b/0x700
> > > arch/x86/kernel/apic/apic.c:1052
> > > apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
> > >
> > > RIP: 0010:native_safe_halt+0x6/0x10
> > > arch/x86/include/asm/irqflags.h:54
> > > RSP: 0018:8801d9f97da8 EFLAGS: 0282 ORIG_RAX:
> > > ff11
> > > RAX: dc00 RBX: 11003b3f2fb8 RCX:
> > > RDX: 10c59734 RSI: 0001 RDI: 862cb9a0
> > > RBP: 8801d9f97da8 R08: R09:
> > > R10: R11: R12: 0001
> > > R13: 8801d9f97e60 R14: 869eb920 R15:
> > > arch_safe_halt arch/x86/include/asm/paravirt.h:93 [inline]
> > > default_idle+0xbf/0x430 arch/x86/kernel/process.c:355
> > > arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:346
> > > default_idle_call+0x36/0x90 kernel/sched/idle.c:98
> > > cpuidle_idle_call kernel/sched/idle.c:156 [inline]
> > > do_idle+0x24a/0x3b0 kernel/sched/idle.c:246
> > > cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:351
> > > start_secondary+0x330/0x460 arch/x86/kernel/smpboot.c:277
> > > secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:237
> > > Code: 03 0f b6 04 01 84 c0 74 04 3c 03 7e 20 8b 4b 78 41 57 48 c7
> > > c7 a0 38
> > > bd 85 52 56 4c 89 ea 41 50 4c 89 e6 45 89 f0 e8 0c b6 3d fd <0f>
> > > 0b 4c 89 4d
> > > b8 4c 89 45 c0 48 89 75 c8 48 89 55 d0 e8 7d 93
> > > RIP: skb_panic+0x15c/0x1f0 net/core/skbuff.c:100 RSP:
> > > 8801db307508
> > > ---[ end trace 941a8a0f633e271f ]---
> > >
> >
> > This isn't a sctp problem, but mld's, seems when lo's mtu became 0,
> > it allocs a skb without enough space in add_grec():
> > if (AVAILABLE(skb) < sizeof(*psrc) +
> > first*sizeof(struct mld2_grec)) {
> > if (truncate && !first)
> > break; /* truncate these */
> > if (pgr)
> > pgr->grec_nsrcs = htons(scount);
> > if (skb)
> > mld_sendpack(skb);
> > skb = mld_newpack(idev, dev->mtu); <---
> >
> > I will check this for sure
Re: [PATCH 4.14 00/75] 4.14.5-stable review
On Fri, Dec 08, 2017 at 12:03:34PM -0800, Kevin Hilman wrote: > kernelci.org bot writes: > > > stable-rc/linux-4.14.y boot: 142 boots: 1 failed, 127 passed with 14 > > offline (v4.14.4-76-gf91a57b206e0) > > > > Full Boot Summary: > > https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.4-76-gf91a57b206e0/ > > Full Build Summary: > > https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.4-76-gf91a57b206e0/ > > > > Tree: stable-rc > > Branch: linux-4.14.y > > Git Describe: v4.14.4-76-gf91a57b206e0 > > Git Commit: f91a57b206e0ca82c4d3f13372c392e3b374e1ce > > Git URL: > > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > Tested: 76 unique boards, 23 SoC families, 18 builds out of 189 > > > > Boot Regressions Detected: > > > > arm64: > > > > defconfig: > > meson-gxbb-p200: > > TL;DR; All is well. > > Re-ran this one and it's fine. Great, thanks for letting me know. greg k-h
Re: [PATCH 2/3] kbuild: prepare to remove C files pre-generated by flex and bison
On 12/09/2017 08:02 AM, Masahiro Yamada wrote: > > Signed-off-by: Masahiro Yamada > --- > > Documentation/process/changes.rst | 25 + > scripts/Makefile.lib | 20 +--- > 2 files changed, 42 insertions(+), 3 deletions(-) > > diff --git a/Documentation/process/changes.rst > b/Documentation/process/changes.rst > index 560beae..fc9c7c3 100644 > --- a/Documentation/process/changes.rst > +++ b/Documentation/process/changes.rst > @@ -32,6 +32,8 @@ you probably needn't concern yourself with isdn4k-utils. > GNU C 3.2 gcc --version > GNU make 3.81 make --version > binutils 2.20 ld -v > +flex 2.5.35 flex --version > +bison 2.0 bison --version > util-linux 2.10ofdformat --version > module-init-tools 0.9.10 depmod -V > e2fsprogs 1.41.4 e2fsck -V > @@ -79,6 +81,19 @@ The build system has, as of 4.13, switched to using thin > archives (`ar T`) > rather than incremental linking (`ld -r`) for built-in.o intermediate steps. > This requires binutils 2.20 or newer. > > +Flex > + > + > +Since Linux 4.16, the build system generates lexical analisers analyzers or analysers > +during build. This requires flex 2.5.35 or later. thanks. -- ~Randy
