Re: [PATCH v4] cpufreq: s5pv210: Defer probe if getting regulators fail
On Sun, 13 Jan 2019 at 20:58, Paweł Chmiel wrote: > > There is possibility, that when probing driver, regulators are not yet > initialized. In this case we should return EPROBE_DEFER and wait till > they're initialized, since they're required currently for cpufreq driver > to work. Also move regulator initialization code at beginning of probe, > so we can defer as fast as posibble. > > Signed-off-by: Paweł Chmiel > --- > Changes from v3: > - Zero dmc_base pointers after unmapping them > - If getting vddarm regulator fails just return, no need to do goto > jump which would do the same > > Changes from v2: > - Handle all error paths in probe > > Changes from v1: > - Fix compilation error > - Reorganize code so it's smaller Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH] tty: not call tty close in fallback
y...@hpe.com: 550 5.1.1 User Unknown You are sending e-mails/patches from a non-existant address? On 14. 01. 19, 7:56, y...@hpe.com wrote: > From: Li RongQing > > when fail to open tty, tty is not in open status and not need > to call close But tty drivers are special and expect close even on failed open, right? See tty_open. > Signed-off-by: Li RongQing > --- > drivers/tty/serdev/serdev-ttyport.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/tty/serdev/serdev-ttyport.c > b/drivers/tty/serdev/serdev-ttyport.c > index fa1672993b4c..bcc1e27d00de 100644 > --- a/drivers/tty/serdev/serdev-ttyport.c > +++ b/drivers/tty/serdev/serdev-ttyport.c > @@ -121,7 +121,7 @@ static int ttyport_open(struct serdev_controller *ctrl) > > ret = tty->ops->open(serport->tty, NULL); > if (ret) > - goto err_close; > + goto err_unlock; > > tty_unlock(serport->tty); > > @@ -142,8 +142,6 @@ static int ttyport_open(struct serdev_controller *ctrl) > > return 0; > > -err_close: > - tty->ops->close(tty, NULL); > err_unlock: > tty_unlock(tty); > tty_release_struct(tty, serport->tty_idx); > thanks, -- js suse labs
Re: [PATCHv2 3/7] mm/memblock: introduce allocation boundary for tracing purpose
Hi Pingfan,
On Fri, Jan 11, 2019 at 01:12:53PM +0800, Pingfan Liu wrote:
> During boot time, there is requirement to tell whether a series of func
> call will consume memory or not. For some reason, a temporary memory
> resource can be loan to those func through memblock allocator, but at a
> check point, all of the loan memory should be turned back.
> A typical using style:
> -1. find a usable range by memblock_find_in_range(), said, [A,B]
> -2. before calling a series of func, memblock_set_current_limit(A,B,true)
> -3. call funcs
> -4. memblock_find_in_range(A,B,B-A,1), if failed, then some memory is not
> turned back.
> -5. reset the original limit
>
> E.g. in the case of hotmovable memory, some acpi routines should be called,
> and they are not allowed to own some movable memory. Although at present
> these functions do not consume memory, but later, if changed without
> awareness, they may do. With the above method, the allocation can be
> detected, and pr_warn() to ask people to resolve it.
To ensure there were that a sequence of function calls didn't create new
memblock allocations you can simply check the number of the reserved
regions before and after that sequence.
Still, I'm not sure it would be practical to try tracking what code that's
called
from x86::setup_arch() did memory allocation.
Probably a better approach is to verify no memory ended up in the movable
areas after their extents are known.
> Signed-off-by: Pingfan Liu
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Dave Hansen
> Cc: Andy Lutomirski
> Cc: Peter Zijlstra
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Yinghai Lu
> Cc: Tejun Heo
> Cc: Chao Fan
> Cc: Baoquan He
> Cc: Juergen Gross
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Cc: Vlastimil Babka
> Cc: Michal Hocko
> Cc: x...@kernel.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux...@kvack.org
> ---
> arch/arm/mm/init.c | 3 ++-
> arch/arm/mm/mmu.c | 4 ++--
> arch/arm/mm/nommu.c | 2 +-
> arch/csky/kernel/setup.c| 2 +-
> arch/microblaze/mm/init.c | 2 +-
> arch/mips/kernel/setup.c| 2 +-
> arch/powerpc/mm/40x_mmu.c | 6 --
> arch/powerpc/mm/44x_mmu.c | 2 +-
> arch/powerpc/mm/8xx_mmu.c | 2 +-
> arch/powerpc/mm/fsl_booke_mmu.c | 5 +++--
> arch/powerpc/mm/hash_utils_64.c | 4 ++--
> arch/powerpc/mm/init_32.c | 2 +-
> arch/powerpc/mm/pgtable-radix.c | 2 +-
> arch/powerpc/mm/ppc_mmu_32.c| 8 ++--
> arch/powerpc/mm/tlb_nohash.c| 6 --
> arch/unicore32/mm/mmu.c | 2 +-
> arch/x86/kernel/setup.c | 2 +-
> arch/xtensa/mm/init.c | 2 +-
> include/linux/memblock.h| 10 +++---
> mm/memblock.c | 23 ++-
> 20 files changed, 59 insertions(+), 32 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 32e4845..58a4342 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -93,7 +93,8 @@ __tagtable(ATAG_INITRD2, parse_tag_initrd2);
> static void __init find_limits(unsigned long *min, unsigned long *max_low,
> unsigned long *max_high)
> {
> - *max_low = PFN_DOWN(memblock_get_current_limit());
> + memblock_get_current_limit(NULL, max_low);
> + *max_low = PFN_DOWN(*max_low);
> *min = PFN_UP(memblock_start_of_DRAM());
> *max_high = PFN_DOWN(memblock_end_of_DRAM());
> }
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index f5cc1cc..9025418 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1240,7 +1240,7 @@ void __init adjust_lowmem_bounds(void)
> }
> }
>
> - memblock_set_current_limit(memblock_limit);
> + memblock_set_current_limit(0, memblock_limit, false);
> }
>
> static inline void prepare_page_table(void)
> @@ -1625,7 +1625,7 @@ void __init paging_init(const struct machine_desc
> *mdesc)
>
> prepare_page_table();
> map_lowmem();
> - memblock_set_current_limit(arm_lowmem_limit);
> + memblock_set_current_limit(0, arm_lowmem_limit, false);
> dma_contiguous_remap();
> early_fixmap_shutdown();
> devicemaps_init(mdesc);
> diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
> index 7d67c70..721535c 100644
> --- a/arch/arm/mm/nommu.c
> +++ b/arch/arm/mm/nommu.c
> @@ -138,7 +138,7 @@ void __init adjust_lowmem_bounds(void)
> adjust_lowmem_bounds_mpu();
> end = memblock_end_of_DRAM();
> high_memory = __va(end - 1) + 1;
> - memblock_set_current_limit(end);
> + memblock_set_current_limit(0, end, false);
> }
>
> /*
> diff --git a/arch/csky/kernel/setup.c b/arch/csky/kernel/setup.c
> index dff8b89..e6f88bf 100644
> --- a/arch/csky/kernel/setup.c
> +++ b/arch/csky/kernel/setup.c
> @@ -100,7 +100,7 @@ static void __init csky_memblock_init(void)
>
> highend_pfn = max_pfn;
> #endif
> -
Re: [PATCH v2] docs-rst: doc-guide: Minor grammar fixes
On Mon, Jan 14, 2019 at 09:14:59AM +0200, Joel Nider wrote: > While using this guide to learn the new documentation method, I saw > a few phrases that I felt could be improved. These small changes > improve the grammar and choice of words to further enhance the > installation instructions. > > Signed-off-by: Joel Nider > Acked-by: Matthew Wilcox Acked-by: Mike Rapoport > --- > v2: address Matthew's comment > > Documentation/doc-guide/sphinx.rst | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Documentation/doc-guide/sphinx.rst > b/Documentation/doc-guide/sphinx.rst > index 02605ee..c039224 100644 > --- a/Documentation/doc-guide/sphinx.rst > +++ b/Documentation/doc-guide/sphinx.rst > @@ -27,8 +27,8 @@ Sphinx Install > == > > The ReST markups currently used by the Documentation/ files are meant to be > -built with ``Sphinx`` version 1.3 or upper. If you're desiring to build > -PDF outputs, it is recommended to use version 1.4.6 or upper. > +built with ``Sphinx`` version 1.3 or higher. If you desire to build > +PDF output, it is recommended to use version 1.4.6 or higher. > > There's a script that checks for the Sphinx requirements. Please see > :ref:`sphinx-pre-install` for further details. > @@ -37,15 +37,15 @@ Most distributions are shipped with Sphinx, but its > toolchain is fragile, > and it is not uncommon that upgrading it or some other Python packages > on your machine would cause the documentation build to break. > > -A way to get rid of that is to use a different version than the one shipped > -on your distributions. In order to do that, it is recommended to install > +A way to avoid that is to use a different version than the one shipped > +with your distributions. In order to do so, it is recommended to install > Sphinx inside a virtual environment, using ``virtualenv-3`` > or ``virtualenv``, depending on how your distribution packaged Python 3. > > .. note:: > > #) Sphinx versions below 1.5 don't work properly with Python's > - docutils version 0.13.1 or upper. So, if you're willing to use > + docutils version 0.13.1 or higher. So, if you're willing to use >those versions, you should run ``pip install 'docutils==0.12'``. > > #) It is recommended to use the RTD theme for html output. Depending > @@ -82,7 +82,7 @@ output. > PDF and LaTeX builds > > > -Such builds are currently supported only with Sphinx versions 1.4 and upper. > +Such builds are currently supported only with Sphinx versions 1.4 and higher. > > For PDF and LaTeX output, you'll also need ``XeLaTeX`` version 3.14159265. > > -- > 2.7.4 > -- Sincerely yours, Mike.
Generating identifiers similar to UUIDs but without dashes
Hello, The file “/proc/sys/kernel/random/uuid” provides a bit of useful data. The formal definition of the string representation for universally unique identifiers requires the use of four dashes for the concatenation of fields. https://tools.ietf.org/html/rfc4122#page-4 https://stackoverflow.com/questions/24481801/is-uuid-without-dashes-hyphens-valid#answer-24484051 Now I am looking again for possibilities to generate reasonably unique identifiers also without these dashes. Can any data processing benefit from the avoidance of such extra characters? Regards, Markus
Re: [PATCH] drm/cirrus: fix connector leak at unload
On Fri, Jan 11, 2019 at 11:16:38PM +0100, Daniel Vetter wrote: > On Fri, Jan 11, 2019 at 11:06:20PM +0100, Daniel Vetter wrote: > > On Fri, Jan 11, 2019 at 09:02:34AM -0500, Rob Clark wrote: > > > This fixes an '*ERROR* connector VGA-2 leaked!' splat at driver unload. > > > > > > Signed-off-by: Rob Clark > > > --- > > > Similar case to the issue that was fixed recently in drm/ast > > > > Reviewed-by: Daniel Vetter > > Actually I just pushed a patch to drm-misc-next to rename this function to > drm_helper_force_disable_all(), so you need to respin ... My r-b still > holds. Fixed and queued up. thanks, Gerd
[PATCH] firmware: hardcode the debug message for -ENOENT
From d6892f54a81bf85ad011bfb8822567690713d575 Mon Sep 17 00:00:00 2001
When the return code of "-ENOENT" was printed inside
of the debug message, which could be hardcoded simply.
Signed-off-by: John Zhao
---
drivers/base/firmware_loader/main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/base/firmware_loader/main.c
b/drivers/base/firmware_loader/main.c
index 8e9213b..9ab1409 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -328,12 +328,12 @@ fw_get_filesystem_firmware(struct device *device,
struct fw_priv *fw_priv)
rc = kernel_read_file_from_path(path, _priv->data, ,
msize, id);
if (rc) {
- if (rc == -ENOENT)
- dev_dbg(device, "loading %s failed with error
%d\n",
-path, rc);
- else
+ if (rc != -ENOENT)
dev_warn(device, "loading %s failed with error
%d\n",
path, rc);
+ else
+ dev_dbg(device, "loading %s failed with error
-ENOENT\n",
+path);
continue;
}
dev_dbg(device, "direct-loading %s\n", fw_priv->fw_name);
--
2.7.4
Re: ppc64le reliable stack unwinder and scheduled tasks
Joe Lawrence writes:
> On Fri, Jan 11, 2019 at 08:51:54AM +0100, Nicolai Stange wrote:
>> Joe Lawrence writes:
>>
>> > On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
>
> [ ... snip ... ]
>
>> >> For testing, could you try whether clearing the word at STACK_FRAME_MARKER
>> >> from _switch() helps?
>> >>
>> >> I.e. something like (completely untested):
>> >
>> > I'll kick off some builds tonight and try to get tests lined up
>> > tomorrow. Unfortunately these take a bit of time to run setup, schedule
>> > and complete, so perhaps by next week.
>>
>> Ok, that's probably still a good test for confirmation, but the solution
>> you proposed below is much better.
>
> Good news, 40 tests (RHEL-7 backport) with clearing out the
> STACK_FRAME_MARKER were all successful. Previously I would see stalled
> livepatch transitions due to the unreliable report in ~10% of test
> cases.
>
>> >> diff --git a/arch/powerpc/kernel/entry_64.S
>> >> b/arch/powerpc/kernel/entry_64.S
>> >> index 435927f549c4..b747d0647ec4 100644
>> >> --- a/arch/powerpc/kernel/entry_64.S
>> >> +++ b/arch/powerpc/kernel/entry_64.S
>> >> @@ -596,6 +596,10 @@ _GLOBAL(_switch)
>> >> SAVE_8GPRS(14, r1)
>> >> SAVE_10GPRS(22, r1)
>> >> std r0,_NIP(r1) /* Return to switch caller */
>> >> +
>> >> + li r23,0
>> >> + std r23,96(r1) /* 96 == STACK_FRAME_MARKER * sizeof(long) */
>> >> +
>> >> mfcrr23
>> >> std r23,_CCR(r1)
>> >> std r1,KSP(r3) /* Set old stack pointer */
>> >>
>> >>
>> >
>> > This may be sufficient to avoid the condition, but if the contents of
>> > frame 0 are truely uninitialized (not to be trusted), should the
>> > unwinder be even looking at that frame (for STACK_FRAMES_REGS_MARKER),
>> > aside from the LR and other stack size geometry sanity checks?
>>
>> That's a very good point: we'll only ever be examining scheduled out tasks
>> and current (which at that time is running klp_try_complete_transition()).
>>
>> current won't be in an interrupt/exception when it's walking its own
>> stack. And scheduled out tasks can't have an exception/interrupt frame
>> as their frame 0, correct?
>>
>> Thus, AFAICS, whenever klp_try_complete_transition() finds a
>> STACK_FRAMES_REGS_MARKER in frame 0, it is known to be garbage, as you
>> said.
>
> I gave this about 20 tests and they were also all successful, what do
> you think? (The log could probably use some trimming and cleanup.) I
> think either solution would fix the issue.
>
> -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8--
>
> From edd3fb9e8a16d5a7ccc98759e9397f386f0e82ca Mon Sep 17 00:00:00 2001
> From: Joe Lawrence
> Date: Fri, 11 Jan 2019 10:25:26 -0500
> Subject: [PATCH] powerpc/livepatch: relax reliable stack tracer exception
> check
>
> The ppc64le reliable stack tracer iterates over a given task's stack,
> verifying a set of conditions to determine whether the trace is
> 'reliable'. These checks include the presence of any exception frames.
>
> We should be careful when inspecting the bottom-most stack frame (the
> first to be unwound), particularly for scheduled-out tasks. As Nicolai
> Stange explains, "If I'm reading the code in _switch() correctly, the
> first frame is completely uninitialized except for the pointer back to
> the caller's stack frame." If a previous do_IRQ() invocation, for
> example, has left a residual exception-marker on the first frame, the
> stack tracer would incorrectly report this task's trace as unreliable.
>
FWIW, it's not been do_IRQ() who wrote the exception marker, but it's
caller hardware_interrupt_common(), more specifically the
EXCEPTION_PROLOG_COMMON_3 part therof.
> save_stack_trace_tsk_reliable() already skips the first frame when
> verifying the saved Link Register. It should do the same when looking
> for the STACK_FRAME_REGS_MARKER. The task it is unwinding will be
> either 'current', in which case the tracer will have never been called
> from an exception path, or the task will be inactive and its first
> frame's contents will be uninitialized (aside from backchain pointer).
I thought about this a little more and can't see anything that would
prevent higher, i.e. non-_switch() frames to also alias with prior
exception frames. That STACK_FRAME_REGS_MARKER is written to a stack
frame's "parameter area" and most functions probably don't initialize
this either. So, AFAICS, higher stack frames could potentially be
affected by the very same problem.
I think the best solution would be to clear the STACK_FRAME_REGS_MARKER
upon exception return. I have a patch ready for that and will post it
after it has passed some basic testing -- hopefully later this day.
That being said, I still think that your patch should also get applied
in some form -- looking at unitialized memory is just not a good thing
to do.
>
> Fixes: df78d3f61480 ("powerpc/livepatch: Implement reliable stack tracing for
> the consistency model")
> Signed-off-by: Joe
general protection fault in crypto_remove_spawns (2)
Hello, syzbot found the following crash on: HEAD commit:4b3c31c8d4dd Merge branch 'i2c/for-current' of git://git.k.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=144cb81740 kernel config: https://syzkaller.appspot.com/x/.config?x=b05cfdb4ee8ab9b2 dashboard link: https://syzkaller.appspot.com/bug?extid=ee4f315443a4ea97512e compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ee4f315443a4ea975...@syzkaller.appspotmail.com binder: 18706:18709 ioctl 40046207 0 returned -16 kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 18713 Comm: cryptomgr_test Not tainted 5.0.0-rc1+ #21 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:crypto_remove_spawns+0x7ac/0x1340 crypto/algapi.c:194 Code: 49 8d 7c 24 10 48 89 f8 48 c1 e8 03 80 3c 18 00 0f 85 f2 06 00 00 49 c7 44 24 10 00 00 00 00 4d 8d 66 10 4c 89 e0 48 c1 e8 03 <80> 3c 18 00 0f 85 ef 06 00 00 49 83 7e 10 00 74 0a e8 4e 9e 24 fe RSP: :888054737b88 EFLAGS: 00010202 RAX: 0002 RBX: dc00 RCX: 11100a8e6f86 RDX: RSI: 835d58d2 RDI: 888085c226b8 RBP: 888054737df8 R08: 88804fb4e4c0 R09: 88804fb4ed60 R10: 88804fb4ed40 R11: 0001 R12: 0010 R13: ed100a8e6f8e R14: R15: 888054737dd0 FS: () GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f6091a29000 CR3: 876f9000 CR4: 001406e0 kobject: 'loop2' (d1d42c09): kobject_uevent_env DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: kobject: 'loop2' (d1d42c09): fill_kobj_path: path = '/devices/virtual/block/loop2' crypto_alg_tested+0x52d/0x790 crypto/algapi.c:339 cryptomgr_test+0x18/0x30 crypto/algboss.c:226 kthread+0x357/0x430 kernel/kthread.c:246 binder: BINDER_SET_CONTEXT_MGR already set ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Modules linked in: kobject: 'loop3' (91226001): kobject_uevent_env binder: 18723:18724 ioctl 40046207 0 returned -16 kobject: 'loop3' (91226001): fill_kobj_path: path = '/devices/virtual/block/loop3' kobject: 'loop5' (38d1e891): kobject_uevent_env kobject: 'loop5' (38d1e891): fill_kobj_path: path = '/devices/virtual/block/loop5' kobject: 'loop1' (47f20675): kobject_uevent_env kobject: 'loop1' (47f20675): fill_kobj_path: path = '/devices/virtual/block/loop1' kobject: 'loop0' (f3ca3d42): kobject_uevent_env kobject: 'loop0' (f3ca3d42): fill_kobj_path: path = '/devices/virtual/block/loop0' kobject: 'loop5' (38d1e891): kobject_uevent_env kobject: 'loop5' (38d1e891): fill_kobj_path: path = '/devices/virtual/block/loop5' kobject: 'loop1' (47f20675): kobject_uevent_env kobject: 'loop1' (47f20675): fill_kobj_path: path = '/devices/virtual/block/loop1' kobject: 'loop2' (d1d42c09): kobject_uevent_env kobject: 'loop2' (d1d42c09): fill_kobj_path: path = '/devices/virtual/block/loop2' ---[ end trace d2934b3fdb1c156e ]--- RIP: 0010:crypto_remove_spawns+0x7ac/0x1340 crypto/algapi.c:194 Code: 49 8d 7c 24 10 48 89 f8 48 c1 e8 03 80 3c 18 00 0f 85 f2 06 00 00 49 c7 44 24 10 00 00 00 00 4d 8d 66 10 4c 89 e0 48 c1 e8 03 <80> 3c 18 00 0f 85 ef 06 00 00 49 83 7e 10 00 74 0a e8 4e 9e 24 fe RSP: :888054737b88 EFLAGS: 00010202 RAX: 0002 RBX: dc00 RCX: 11100a8e6f86 RDX: RSI: 835d58d2 RDI: 888085c226b8 RBP: 888054737df8 R08: 88804fb4e4c0 R09: 88804fb4ed60 R10: 88804fb4ed40 R11: 0001 R12: 0010 R13: ed100a8e6f8e R14: R15: 888054737dd0 FS: () GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0110cfd0 CR3: 94f35000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
KASAN: slab-out-of-bounds Read in xfrm_policy_insert_list
Hello, syzbot found the following crash on: HEAD commit:8d008e64a2eb mISDN: hfcsusb: Use struct_size() in kzalloc() git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=164f010740 kernel config: https://syzkaller.appspot.com/x/.config?x=7308e68273924137 dashboard link: https://syzkaller.appspot.com/bug?extid=071bdf2137f3025fb82b compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+071bdf2137f3025fb...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in xfrm_policy_insert_list+0xd32/0xfb0 net/xfrm/xfrm_policy.c:1532 Read of size 1 at addr 8880a57d0699 by task syz-executor0/22062 CPU: 0 PID: 22062 Comm: syz-executor0 Not tainted 4.20.0+ #18 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1db/0x2d0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:132 xfrm_policy_insert_list+0xd32/0xfb0 net/xfrm/xfrm_policy.c:1532 xfrm_policy_inexact_insert+0x155/0xda0 net/xfrm/xfrm_policy.c:1195 xfrm_policy_insert+0x623/0x910 net/xfrm/xfrm_policy.c:1570 xfrm_add_policy+0x2a1/0x6c0 net/xfrm/xfrm_user.c:1657 xfrm_user_rcv_msg+0x458/0x8d0 net/xfrm/xfrm_user.c:2663 netlink_rcv_skb+0x17d/0x410 net/netlink/af_netlink.c:2477 xfrm_netlink_rcv+0x70/0x90 net/xfrm/xfrm_user.c:2671 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] netlink_unicast+0x574/0x770 net/netlink/af_netlink.c:1336 netlink_sendmsg+0xa05/0xf90 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xdd/0x130 net/socket.c:631 ___sys_sendmsg+0x7ec/0x910 net/socket.c:2116 __sys_sendmsg+0x112/0x270 net/socket.c:2154 __do_sys_sendmsg net/socket.c:2163 [inline] __se_sys_sendmsg net/socket.c:2161 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161 do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457ec9 Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f2e4aef1c78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 00457ec9 RDX: RSI: 2000 RDI: 0004 RBP: 0073bf00 R08: R09: R10: R11: 0246 R12: 7f2e4aef26d4 R13: 004c5394 R14: 004d8e30 R15: Allocated by task 2682: save_stack+0x45/0xd0 mm/kasan/common.c:73 set_track mm/kasan/common.c:85 [inline] kasan_kmalloc mm/kasan/common.c:482 [inline] kasan_kmalloc+0xcf/0xe0 mm/kasan/common.c:455 kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:397 kmem_cache_alloc+0x12d/0x710 mm/slab.c:3541 getname_flags fs/namei.c:140 [inline] getname_flags+0xd6/0x5b0 fs/namei.c:129 getname+0x1a/0x20 fs/namei.c:211 do_sys_open+0x3a5/0x7c0 fs/open.c:1057 __do_sys_open fs/open.c:1081 [inline] __se_sys_open fs/open.c:1076 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1076 do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 2682: save_stack+0x45/0xd0 mm/kasan/common.c:73 set_track mm/kasan/common.c:85 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:444 kasan_slab_free+0xe/0x10 mm/kasan/common.c:452 __cache_free mm/slab.c:3485 [inline] kmem_cache_free+0x86/0x260 mm/slab.c:3747 putname+0xef/0x130 fs/namei.c:261 do_sys_open+0x3f4/0x7c0 fs/open.c:1072 __do_sys_open fs/open.c:1081 [inline] __se_sys_open fs/open.c:1076 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1076 do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 8880a57d0800 which belongs to the cache names_cache of size 4096 The buggy address is located 359 bytes to the left of 4096-byte region [8880a57d0800, 8880a57d1800) The buggy address belongs to the page: page:ea000295f400 count:1 mapcount:0 mapping:88821bc49080 index:0x0 compound_mapcount: 0 flags: 0x1fffc010200(slab|head) raw: 01fffc010200 ea0002949788 ea00027c8208 88821bc49080 raw: 8880a57d0800 00010001 page dumped because: kasan: bad access detected Memory state around the buggy address: 8880a57d0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 8880a57d0600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 8880a57d0680: fc fc fc fc fc fc fc fc
[GIT PULL] MFD for v5.0
On Mon, 14 Jan 2019, Pavel Machek wrote: > On Wed 2019-01-09 07:20:18, Lee Jones wrote: > > Good morning Linus, > > > > Please accept my apologies for the lateness. > > I'd say that for 5.1, you are pretty early :-). Ha ha! Yes, indeed. It seems sending late messes with the brain! Ideally I'd like this accepted for 5.0 please. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[GIT PULL] Backlight for v5.0
On Wed, 09 Jan 2019, Lee Jones wrote: > Good morning Linus, > > Please accept my apologies for the lateness. This should be v5.0 of course. Sending late seems to mess with the brain. > Christmas holidays, yada yada yada! :) > > The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: > > Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git > tags/backlight-next-4.21 > > for you to fetch changes up to 3cee7a7d05b11038c8b5fa093e45c6f839ffc867: > > backlight: 88pm860x_bl: Use of_node_name_eq for node name comparisons > (2018-12-14 12:30:24 +) > > > - Fix-ups >- Use new of_node_name_eq() API call; > > - Bug Fixes >- Internally track 'enabled' state; pwm_bl >- Fix auto-generated brightness tables parsed by DT; pwm_bl > > > Heiko Stuebner (2): > backlight: pwm_bl: Re-add driver internal enabled tracking > backlight: pwm_bl: Fix devicetree parsing with auto-generated > brightness tables > > Rob Herring (1): > backlight: 88pm860x_bl: Use of_node_name_eq for node name comparisons > > drivers/video/backlight/88pm860x_bl.c | 2 +- > drivers/video/backlight/pwm_bl.c | 28 +--- > 2 files changed, 18 insertions(+), 12 deletions(-) > -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] acpi/nfit: Fix command-supported detection
Hi Dan,
On 12-Jan-19 5:29 AM, Dan Williams wrote:
The _DSM function number validation only happens to succeed when the
generic Linux command number translation corresponds with a
DSM-family-specific function number. This breaks NVDIMM-N
implementations that correctly implement _LSR, _LSW, and _LSI, but do
not happen to publish support for DSM function numbers 4, 5, and 6.
Recall that the support for _LS{I,R,W} family of methods results in the
DIMM being marked as supporting those command numbers at
acpi_nfit_register_dimms() time. The DSM function mask is only used for
ND_CMD_CALL support of non-NVDIMM_FAMILY_INTEL devices.
Fixes: 31eca76ba2fc ("nfit, libnvdimm: limited/whitelisted dimm command...")
Cc:
Link: https://github.com/pmem/ndctl/issues/78
Reported-by: Sujith Pandel
Signed-off-by: Dan Williams
---
Sujith, this is a larger change than what you originally tested, but it
should behave the same. I wanted to consolidate all the code that
handles Linux command number to DIMM _DSM function number translation.
If you have a chance to re-test with this it would be much appreciated.
Thanks for the report!
Re-verified by applying this patch over LTS kernel-4.20.2 with ndctl v62.
namespace creation and modification works fine on Dell NVDIMM-Ns.
Thanks for helping me on this!
Tested-by: Sujith Pandel
Re: [PATCH] tty: not call tty close in fallback
On 14. 01. 19, 7:56, y...@hpe.com wrote: > From: Li RongQing > > when fail to open tty, tty is not in open status and not need > to call close But tty drivers are special and expect close even on failed open, right? See tty_open. > Signed-off-by: Li RongQing > --- > drivers/tty/serdev/serdev-ttyport.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/tty/serdev/serdev-ttyport.c > b/drivers/tty/serdev/serdev-ttyport.c > index fa1672993b4c..bcc1e27d00de 100644 > --- a/drivers/tty/serdev/serdev-ttyport.c > +++ b/drivers/tty/serdev/serdev-ttyport.c > @@ -121,7 +121,7 @@ static int ttyport_open(struct serdev_controller *ctrl) > > ret = tty->ops->open(serport->tty, NULL); > if (ret) > - goto err_close; > + goto err_unlock; > > tty_unlock(serport->tty); > > @@ -142,8 +142,6 @@ static int ttyport_open(struct serdev_controller *ctrl) > > return 0; > > -err_close: > - tty->ops->close(tty, NULL); > err_unlock: > tty_unlock(tty); > tty_release_struct(tty, serport->tty_idx); > thanks, -- js suse labs
Re: [PATCH v3 0/5] kvm "virtio pmem" device
> > Until you have images (and hence host page cache) shared between > > multiple guests. People will want to do this, because it means they > > only need a single set of pages in host memory for executable > > binaries rather than a set of pages per guest. Then you have > > multiple guests being able to detect residency of the same set of > > pages. If the guests can then, in any way, control eviction of the > > pages from the host cache, then we have a guest-to-guest information > > leak channel. > > I don't think we should ever be considering something that would allow a > guest to evict page's from the host's pagecache [1]. The guest should > be able to kick its own references to the host's pagecache out of its > own pagecache, but not be able to influence whether the host or another > guest has a read-only mapping cached. > > [1] Unless the guest is allowed to modify the host's file; obviously > truncation, holepunching, etc are going to evict pages from the host's > page cache. This is so correct. Guest does not not evict host page cache pages directly. In case of virtio-pmem & DAX, guest clears guest page cache exceptional entries. Its solely decision of host to take action on the host page cache pages. In case of virtio-pmem, guest does not modify host file directly i.e don't perform hole punch & truncation operation directly on host file. Thanks, Pankaj
[PATCH v2] docs-rst: doc-guide: Minor grammar fixes
While using this guide to learn the new documentation method, I saw a few phrases that I felt could be improved. These small changes improve the grammar and choice of words to further enhance the installation instructions. Signed-off-by: Joel Nider Acked-by: Matthew Wilcox --- v2: address Matthew's comment Documentation/doc-guide/sphinx.rst | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index 02605ee..c039224 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -27,8 +27,8 @@ Sphinx Install == The ReST markups currently used by the Documentation/ files are meant to be -built with ``Sphinx`` version 1.3 or upper. If you're desiring to build -PDF outputs, it is recommended to use version 1.4.6 or upper. +built with ``Sphinx`` version 1.3 or higher. If you desire to build +PDF output, it is recommended to use version 1.4.6 or higher. There's a script that checks for the Sphinx requirements. Please see :ref:`sphinx-pre-install` for further details. @@ -37,15 +37,15 @@ Most distributions are shipped with Sphinx, but its toolchain is fragile, and it is not uncommon that upgrading it or some other Python packages on your machine would cause the documentation build to break. -A way to get rid of that is to use a different version than the one shipped -on your distributions. In order to do that, it is recommended to install +A way to avoid that is to use a different version than the one shipped +with your distributions. In order to do so, it is recommended to install Sphinx inside a virtual environment, using ``virtualenv-3`` or ``virtualenv``, depending on how your distribution packaged Python 3. .. note:: #) Sphinx versions below 1.5 don't work properly with Python's - docutils version 0.13.1 or upper. So, if you're willing to use + docutils version 0.13.1 or higher. So, if you're willing to use those versions, you should run ``pip install 'docutils==0.12'``. #) It is recommended to use the RTD theme for html output. Depending @@ -82,7 +82,7 @@ output. PDF and LaTeX builds -Such builds are currently supported only with Sphinx versions 1.4 and upper. +Such builds are currently supported only with Sphinx versions 1.4 and higher. For PDF and LaTeX output, you'll also need ``XeLaTeX`` version 3.14159265. -- 2.7.4
Re: [PATCH] mm: Introduce GFP_PGTABLE
On Mon 14-01-19 09:30:55, Anshuman Khandual wrote: > > > On 01/13/2019 11:05 PM, Michal Hocko wrote: > > On Sat 12-01-19 15:56:38, Anshuman Khandual wrote: > >> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL | > >> __GFP_ZERO) and using it for allocating page table pages. This causes some > >> code duplication which can be easily avoided. GFP_KERNEL allocated and > >> cleared out pages (__GFP_ZERO) are required for page tables on any given > >> architecture. This creates a new generic GFP flag flag which can be used > >> for any page table page allocation. Does not cause any functional change. > > > > I agree that some unification is due but GFP_PGTABLE is not something to > > expose in generic gfp.h IMHO. It just risks an abuse. I would be looking > > Why would you think that it risks an abuse ? It does not create new semantics > of allocation in the buddy. Its just uses existing GFP_KERNEL allocation which > is then getting zeroed out. The risks (if any) is exactly same as GFP_KERNEL. Beucase my experience just tells me that people tend to use whatever they find and name fits what they think they need. > > at providing asm-generic implementation and reuse it to remove the code > > Does that mean GFP_PGTABLE can be created but not in gfp.h but in some other > memory related header file ? I would just keep it close to its users. If that is a single arch generic place then only better. But I suspect some arches have special requirements. > > duplication. But I haven't tried that to know that it will work out due > > to small/subtle differences between arches. > > IIUC from the allocation perspective GFP_ACCOUNT is the only thing which gets > added with GFP_PGTABLE for user page table for memcg accounting purpose. There > does not seem to be any other differences unless I am missing something. It's been some time since I've checked the last time. Some arches were using GPF_REPEAT (__GFP_RETRY_MAYFAIL) back then. I have removed most of those but some were doing a higher order allocations so they probably have stayed. -- Michal Hocko SUSE Labs
Re: [PATCH v5 12/20] memory: mtk-smi: Add gals support
Hi Matthias, Gentle ping about this and the other mtk-smi part in this patchset. The memory part don't have its specific maintainer, normally we need SoC maintain's help. Thus, For this file(memory/mtk-smi.c), your review is needed before Joerg accept it. Appreciate in advance. On Tue, 2019-01-01 at 11:55 +0800, Yong Wu wrote: > In some SoCs like mt8183, SMI add GALS(Global Async Local Sync) module > which can help synchronize for the modules in different clock frequency. > It can be seen as a "asynchronous fifo". This is a example diagram: > > M4U > | > -- > || > gals0-rx gals1-rx > || > || > gals0-tx gals1-tx > || > > SMI Common > > | > +-++-+- ... > | || | > | gals-rx gals-rx | > | || | > | || | > | gals-tx gals-tx | > | || | > larb1 larb2 larb3 larb4 > > GALS only help transfer the command/data while it doesn't have the > configuring register, thus it has the special "smi" clock and doesn't > have the "apb" clock. From the diagram above, we add "gals0" and > "gals1" clocks for smi-common and add a "gals" clock for smi-larb. > > This patch adds gals clock supporting in the SMI. Note that some larbs > may still don't have the "gals" clock like larb1 and larb4 above. > > This is also a preparing patch for mt8183 which has GALS. > > Signed-off-by: Yong Wu > --- > drivers/memory/mtk-smi.c | 36 > 1 file changed, 36 insertions(+) [...]
[PATCH] tty: not call tty close in fallback
From: Li RongQing when fail to open tty, tty is not in open status and not need to call close Signed-off-by: Li RongQing --- drivers/tty/serdev/serdev-ttyport.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/tty/serdev/serdev-ttyport.c b/drivers/tty/serdev/serdev-ttyport.c index fa1672993b4c..bcc1e27d00de 100644 --- a/drivers/tty/serdev/serdev-ttyport.c +++ b/drivers/tty/serdev/serdev-ttyport.c @@ -121,7 +121,7 @@ static int ttyport_open(struct serdev_controller *ctrl) ret = tty->ops->open(serport->tty, NULL); if (ret) - goto err_close; + goto err_unlock; tty_unlock(serport->tty); @@ -142,8 +142,6 @@ static int ttyport_open(struct serdev_controller *ctrl) return 0; -err_close: - tty->ops->close(tty, NULL); err_unlock: tty_unlock(tty); tty_release_struct(tty, serport->tty_idx); -- 2.16.2
Re: KASAN: null-ptr-deref Read in ip6_hold_safe
On Mon, Jan 14, 2019 at 7:52 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/.. > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1492759f40 > kernel config: https://syzkaller.appspot.com/x/.config?x=b03c5892bb940c76 > dashboard link: https://syzkaller.appspot.com/bug?extid=8433ca0841e308ef4cc7 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+8433ca0841e308ef4...@syzkaller.appspotmail.com +Wei > kernel msg: ebtables bug: please report to author: EBT_ENTRY_OR_ENTRIES > shouldn't be set in distinguisher > == > BUG: KASAN: null-ptr-deref in atomic_read > include/asm-generic/atomic-instrumented.h:21 [inline] > BUG: KASAN: null-ptr-deref in atomic_fetch_add_unless > include/linux/atomic.h:575 [inline] > BUG: KASAN: null-ptr-deref in atomic_add_unless include/linux/atomic.h:597 > [inline] > BUG: KASAN: null-ptr-deref in dst_hold_safe include/net/dst.h:308 [inline] > BUG: KASAN: null-ptr-deref in ip6_hold_safe+0xca/0x620 net/ipv6/route.c:1021 > Read of size 4 at addr 0068 by task syz-executor4/21421 > > CPU: 0 PID: 21421 Comm: syz-executor4 Not tainted 4.20.0+ #3 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1db/0x2d0 lib/dump_stack.c:113 > kasan_report_error mm/kasan/report.c:352 [inline] > kasan_report mm/kasan/report.c:412 [inline] > kasan_report.cold+0x19f/0x2ba mm/kasan/report.c:396 > check_memory_region_inline mm/kasan/kasan.c:260 [inline] > check_memory_region+0x123/0x190 mm/kasan/kasan.c:267 > kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272 > atomic_read include/asm-generic/atomic-instrumented.h:21 [inline] > atomic_fetch_add_unless include/linux/atomic.h:575 [inline] > atomic_add_unless include/linux/atomic.h:597 [inline] > dst_hold_safe include/net/dst.h:308 [inline] > ip6_hold_safe+0xca/0x620 net/ipv6/route.c:1021 > rt6_get_pcpu_route net/ipv6/route.c:1241 [inline] > ip6_pol_route+0x3a3/0x1490 net/ipv6/route.c:1890 > ip6_pol_route_output+0x54/0x70 net/ipv6/route.c:2066 > fib6_rule_lookup+0x277/0x870 net/ipv6/fib6_rules.c:122 > ip6_route_output_flags+0x2c4/0x350 net/ipv6/route.c:2095 > ip6_route_output include/net/ip6_route.h:88 [inline] > ip6_dst_lookup_tail+0xe18/0x1d50 net/ipv6/ip6_output.c:958 > ip6_dst_lookup_flow+0xca/0x270 net/ipv6/ip6_output.c:1086 > ip6_sk_dst_lookup_flow net/ipv6/ip6_output.c:1124 [inline] > ip6_sk_dst_lookup_flow+0x5d6/0xbf0 net/ipv6/ip6_output.c:1114 > udpv6_sendmsg+0x20d7/0x3550 net/ipv6/udp.c:1441 > inet_sendmsg+0x1af/0x740 net/ipv4/af_inet.c:798 > sock_sendmsg_nosec net/socket.c:621 [inline] > sock_sendmsg+0xdd/0x130 net/socket.c:631 > ___sys_sendmsg+0x7ec/0x910 net/socket.c:2116 > __sys_sendmsg+0x112/0x270 net/socket.c:2154 > __do_sys_sendmsg net/socket.c:2163 [inline] > __se_sys_sendmsg net/socket.c:2161 [inline] > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161 > protocol 88fb is buggy, dev hsr_slave_0 > do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 > protocol 88fb is buggy, dev hsr_slave_1 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x457ec9 > Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7fb05ac4ac78 EFLAGS: 0246 ORIG_RAX: 002e > RAX: ffda RBX: 0003 RCX: 00457ec9 > RDX: RSI: 20013000 RDI: 0004 > RBP: 0073bf00 R08: R09: > R10: R11: 0246 R12: 7fb05ac4b6d4 > R13: 004c4d2e R14: 004d8650 R15: > == > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with > syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/75c0ef057f657b8d%40google.com. > For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] input_event: Provide override for sparc64
On Sat, Dec 29, 2018 at 10:35:14AM -0800, Deepa Dinamani wrote:
> The usec part of the timeval is defined as
> __kernel_suseconds_t tv_usec; /* microseconds */
>
> Arnd noticed that sparc64 is the only architecture
> that defines __kernel_suseconds_t as int rather than long.
>
> This breaks the current y2038 fix for kernel as we only
> access and define the timeval struct for non-kernel use cases.
> But, this was hidden by an another typo in the use of __KERNEL__
> qualifier.
>
> Fix the typo, and provide an override for sparc64.
>
> Fixes: 152194fe9c3f ("Input: extend usable life of event timestamps to 2106
> on 32 bit systems")
> Reported-by: Arnd Bergmann
> Signed-off-by: Deepa Dinamani
Applied, thank you.
> ---
> include/uapi/linux/input.h | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index fb78f6f500f3..ffab958bc512 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -26,13 +26,17 @@
> */
>
> struct input_event {
> -#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) &&
> !defined(__KERNEL)
> +#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) &&
> !defined(__KERNEL__)
> struct timeval time;
> #define input_event_sec time.tv_sec
> #define input_event_usec time.tv_usec
> #else
> __kernel_ulong_t __sec;
> +#ifdef CONFIG_SPARC64
> + unsigned int __usec;
> +#else
> __kernel_ulong_t __usec;
> +#endif
> #define input_event_sec __sec
> #define input_event_usec __usec
> #endif
> --
> 2.17.1
>
--
Dmitry
Re: [PATCH] keyboard/mtk-pmic-keys.c: Remove duplicate header
On Sat, Jan 05, 2019 at 10:39:07AM +0530, Brajeswar Ghosh wrote: > Remove linux/kernel.h which is included more than once > > Signed-off-by: Brajeswar Ghosh Applied, thank you. > --- > drivers/input/keyboard/mtk-pmic-keys.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/input/keyboard/mtk-pmic-keys.c > b/drivers/input/keyboard/mtk-pmic-keys.c > index 02c67a1749fc..5027ebb7b4e8 100644 > --- a/drivers/input/keyboard/mtk-pmic-keys.c > +++ b/drivers/input/keyboard/mtk-pmic-keys.c > @@ -19,7 +19,6 @@ > #include > #include > #include > -#include > #include > #include > #include > -- > 2.17.1 > -- Dmitry
KASAN: null-ptr-deref Read in ip6_hold_safe
Hello, syzbot found the following crash on: HEAD commit:b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=1492759f40 kernel config: https://syzkaller.appspot.com/x/.config?x=b03c5892bb940c76 dashboard link: https://syzkaller.appspot.com/bug?extid=8433ca0841e308ef4cc7 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+8433ca0841e308ef4...@syzkaller.appspotmail.com kernel msg: ebtables bug: please report to author: EBT_ENTRY_OR_ENTRIES shouldn't be set in distinguisher == BUG: KASAN: null-ptr-deref in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline] BUG: KASAN: null-ptr-deref in atomic_fetch_add_unless include/linux/atomic.h:575 [inline] BUG: KASAN: null-ptr-deref in atomic_add_unless include/linux/atomic.h:597 [inline] BUG: KASAN: null-ptr-deref in dst_hold_safe include/net/dst.h:308 [inline] BUG: KASAN: null-ptr-deref in ip6_hold_safe+0xca/0x620 net/ipv6/route.c:1021 Read of size 4 at addr 0068 by task syz-executor4/21421 CPU: 0 PID: 21421 Comm: syz-executor4 Not tainted 4.20.0+ #3 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1db/0x2d0 lib/dump_stack.c:113 kasan_report_error mm/kasan/report.c:352 [inline] kasan_report mm/kasan/report.c:412 [inline] kasan_report.cold+0x19f/0x2ba mm/kasan/report.c:396 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x123/0x190 mm/kasan/kasan.c:267 kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272 atomic_read include/asm-generic/atomic-instrumented.h:21 [inline] atomic_fetch_add_unless include/linux/atomic.h:575 [inline] atomic_add_unless include/linux/atomic.h:597 [inline] dst_hold_safe include/net/dst.h:308 [inline] ip6_hold_safe+0xca/0x620 net/ipv6/route.c:1021 rt6_get_pcpu_route net/ipv6/route.c:1241 [inline] ip6_pol_route+0x3a3/0x1490 net/ipv6/route.c:1890 ip6_pol_route_output+0x54/0x70 net/ipv6/route.c:2066 fib6_rule_lookup+0x277/0x870 net/ipv6/fib6_rules.c:122 ip6_route_output_flags+0x2c4/0x350 net/ipv6/route.c:2095 ip6_route_output include/net/ip6_route.h:88 [inline] ip6_dst_lookup_tail+0xe18/0x1d50 net/ipv6/ip6_output.c:958 ip6_dst_lookup_flow+0xca/0x270 net/ipv6/ip6_output.c:1086 ip6_sk_dst_lookup_flow net/ipv6/ip6_output.c:1124 [inline] ip6_sk_dst_lookup_flow+0x5d6/0xbf0 net/ipv6/ip6_output.c:1114 udpv6_sendmsg+0x20d7/0x3550 net/ipv6/udp.c:1441 inet_sendmsg+0x1af/0x740 net/ipv4/af_inet.c:798 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xdd/0x130 net/socket.c:631 ___sys_sendmsg+0x7ec/0x910 net/socket.c:2116 __sys_sendmsg+0x112/0x270 net/socket.c:2154 __do_sys_sendmsg net/socket.c:2163 [inline] __se_sys_sendmsg net/socket.c:2161 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161 protocol 88fb is buggy, dev hsr_slave_0 do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 protocol 88fb is buggy, dev hsr_slave_1 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457ec9 Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fb05ac4ac78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 00457ec9 RDX: RSI: 20013000 RDI: 0004 RBP: 0073bf00 R08: R09: R10: R11: 0246 R12: 7fb05ac4b6d4 R13: 004c4d2e R14: 004d8650 R15: == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
[RFC PATCH] time/nohz: allow the boot CPU to be nohz_full
We have a supercomputer site testing nohz_full to reduce jitter with
good results, but they want CPU0 to be nohz_full. That happens to be
the boot CPU, which is disallowed by the nohz_full code.
They have existing job scheduling code which wants this, I don't know
too much detail beyond that, but I hope the kernel can be made to
work with their config.
This patch has the boot CPU take over the jiffies update in the low
res timer before SMP is brought up, after which the nohz CPU will take
over.
It also modifies the housekeeping check code a bit to ensure at least
one !nohz CPU is in the present map so it comes up at boot, rather
than having the nohz code take the boot CPU out of the nohz mask.
This keeps jiffies incrementing on the nohz_full boot CPU before SMP
init, but I'm not sure if this is covering all races and platform
considerations. Sorry I don't know the timer code too well, I would
appreciate any help.
Thanks,
Nick
---
kernel/sched/isolation.c | 18 --
kernel/time/tick-common.c | 30 +-
kernel/time/tick-sched.c | 14 +-
3 files changed, 42 insertions(+), 20 deletions(-)
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index e6802181900f..6f8ac38d39a0 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -65,6 +65,7 @@ void __init housekeeping_init(void)
static int __init housekeeping_setup(char *str, enum hk_flags flags)
{
cpumask_var_t non_housekeeping_mask;
+ cpumask_var_t tmp;
int err;
alloc_bootmem_cpumask_var(_housekeeping_mask);
@@ -75,25 +76,30 @@ static int __init housekeeping_setup(char *str, enum
hk_flags flags)
return 0;
}
+ alloc_bootmem_cpumask_var();
if (!housekeeping_flags) {
alloc_bootmem_cpumask_var(_mask);
cpumask_andnot(housekeeping_mask,
cpu_possible_mask, non_housekeeping_mask);
- if (cpumask_empty(housekeeping_mask))
+ cpumask_andnot(tmp, cpu_present_mask, non_housekeeping_mask);
+ if (cpumask_empty(tmp)) {
+ pr_warn("Housekeeping: must include one present CPU, "
+ "using boot CPU:%d\n", smp_processor_id());
cpumask_set_cpu(smp_processor_id(), housekeeping_mask);
+ cpumask_clear_cpu(smp_processor_id(),
non_housekeeping_mask);
+ }
} else {
- cpumask_var_t tmp;
-
- alloc_bootmem_cpumask_var();
- cpumask_andnot(tmp, cpu_possible_mask, non_housekeeping_mask);
+ cpumask_andnot(tmp, cpu_present_mask, non_housekeeping_mask);
+ if (cpumask_empty(tmp))
+ cpumask_set_cpu(smp_processor_id(), tmp);
if (!cpumask_equal(tmp, housekeeping_mask)) {
pr_warn("Housekeeping: nohz_full= must match
isolcpus=\n");
free_bootmem_cpumask_var(tmp);
free_bootmem_cpumask_var(non_housekeeping_mask);
return 0;
}
- free_bootmem_cpumask_var(tmp);
}
+ free_bootmem_cpumask_var(tmp);
if ((flags & HK_FLAG_TICK) && !(housekeeping_flags & HK_FLAG_TICK)) {
if (IS_ENABLED(CONFIG_NO_HZ_FULL)) {
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 14de3727b18e..c971278dbe95 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -50,6 +50,9 @@ ktime_t tick_period;
*procedure also covers cpu hotplug.
*/
int tick_do_timer_cpu __read_mostly = TICK_DO_TIMER_BOOT;
+#ifdef CONFIG_NO_HZ_FULL
+static int tick_do_timer_boot_cpu __read_mostly = -1;
+#endif
/*
* Debugging: see timer_list.c
@@ -78,7 +81,11 @@ int tick_is_oneshot_available(void)
*/
static void tick_periodic(int cpu)
{
+#ifdef CONFIG_NO_HZ_FULL
+ if (tick_do_timer_cpu == cpu || tick_do_timer_boot_cpu == cpu) {
+#else
if (tick_do_timer_cpu == cpu) {
+#endif
write_seqlock(_lock);
/* Keep track of the next tick event */
@@ -190,12 +197,25 @@ static void tick_setup_device(struct tick_device *td,
* this cpu:
*/
if (tick_do_timer_cpu == TICK_DO_TIMER_BOOT) {
- if (!tick_nohz_full_cpu(cpu))
+ /*
+* The boot CPU may be nohz_full, in which case just
+* leave it set to TICK_DO_TIMER_BOOT for the next
+* CPU. tick_do_timer_boot_cpu is set to run the
+* tick at early boot until the housekeeping CPU
+* comes up.
+*/
+ if (!tick_nohz_full_cpu(cpu)) {
tick_do_timer_cpu = cpu;
- else
-
Re: [PATCH] lib: test_ubsan: VLA no longer used in kernel
On Sun, Jan 13, 2019 at 7:32 PM Olof Johansson wrote:
>
> Since we now build with -Wvla, any use of VLA throws a warning.
> Including this test, so... maybe we should just remove the test?
>
> lib/test_ubsan.c: In function 'test_ubsan_vla_bound_not_positive':
> lib/test_ubsan.c:48:2: warning: ISO C90 forbids variable length array 'buf'
> [-Wvla]
>
> For the out-of-bounds test, switch to non-VLA setup.
>
> lib/test_ubsan.c: In function 'test_ubsan_out_of_bounds':
> lib/test_ubsan.c:64:2: warning: ISO C90 forbids variable length array 'arr'
> [-Wvla]
>
> Cc: Colin Ian King
> Cc: Jinbum Park
> Cc: Andrey Ryabinin
> Cc: Dmitry Vyukov
> Cc: Kees Cook
> Signed-off-by: Olof Johansson
Acked-by: Dmitry Vyukov
> ---
> lib/test_ubsan.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/lib/test_ubsan.c b/lib/test_ubsan.c
> index 280f4979d00ed..9ea10adf7a66f 100644
> --- a/lib/test_ubsan.c
> +++ b/lib/test_ubsan.c
> @@ -42,14 +42,6 @@ static void test_ubsan_divrem_overflow(void)
> val /= val2;
> }
>
> -static void test_ubsan_vla_bound_not_positive(void)
> -{
> - volatile int size = -1;
> - char buf[size];
> -
> - (void)buf;
> -}
> -
> static void test_ubsan_shift_out_of_bounds(void)
> {
> volatile int val = -1;
> @@ -61,7 +53,7 @@ static void test_ubsan_shift_out_of_bounds(void)
> static void test_ubsan_out_of_bounds(void)
> {
> volatile int i = 4, j = 5;
> - volatile int arr[i];
> + volatile int arr[4];
>
> arr[j] = i;
> }
> @@ -113,7 +105,6 @@ static const test_ubsan_fp test_ubsan_array[] = {
> test_ubsan_mul_overflow,
> test_ubsan_negate_overflow,
> test_ubsan_divrem_overflow,
> - test_ubsan_vla_bound_not_positive,
> test_ubsan_shift_out_of_bounds,
> test_ubsan_out_of_bounds,
> test_ubsan_load_invalid_value,
> --
> 2.11.0
>
Re: [PATCH v2 2/2] mfd: tps65218.c: Add input voltage options
On Thursday 03 January 2019 07:17 PM, Christian Hohnstaedt wrote:
> These options apply to all regulators in this chip.
>
> ti,strict-supply-voltage-supervision:
> Set STRICT flag in CONFIG1
> ti,under-voltage-limit-microvolt:
> Select 2.75, 2.95, 3.25 or 3.35 V UVLO in CONFIG1
> ti,under-voltage-hyst-microvolt:
> Select 200mV or 400mV UVLOHYS in CONFIG2
CHECK: Alignment should match open parenthesis
#146: FILE: drivers/mfd/tps65218.c:219:
+ if (of_property_read_u32(tps->dev->of_node,
+ "ti,strict-supply-voltage-supervision", ))
CHECK: Alignment should match open parenthesis
#156: FILE: drivers/mfd/tps65218.c:229:
+ tps65218_update_bits(tps, TPS65218_REG_CONFIG1,
+ TPS65218_CONFIG1_STRICT,
CHECK: Alignment should match open parenthesis
#166: FILE: drivers/mfd/tps65218.c:239:
+ if (of_property_read_u32(tps->dev->of_node,
+ "ti,under-voltage-hyst-microvolt", ))
CHECK: Alignment should match open parenthesis
#176: FILE: drivers/mfd/tps65218.c:249:
+ tps65218_update_bits(tps, TPS65218_REG_CONFIG2,
+ TPS65218_CONFIG2_UVLOHYS,
CHECK: Alignment should match open parenthesis
#188: FILE: drivers/mfd/tps65218.c:261:
+ if (of_property_read_u32(tps->dev->of_node,
+"ti,under-voltage-limit-microvolt", ))
CHECK: Alignment should match open parenthesis
#211: FILE: drivers/mfd/tps65218.c:284:
+ tps65218_update_bits(tps, TPS65218_REG_CONFIG1,
+ TPS65218_CONFIG1_UVLO_MASK, uvloval,
Some checkpatch warnings to be fixed.
Other than that i tested your patch on am437x-gp-evm for boot and
suspend/resume.
After fixing them you can add my:
Tested-by: Keerthy
Reviewed-by: Keerthy
>
> Signed-off-by: Christian Hohnstaedt
> ---
> drivers/mfd/tps65218.c | 87
>
> include/linux/mfd/tps65218.h | 4 ++
> 2 files changed, 91 insertions(+)
>
> diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
> index 8bcdecf..b5e0f3a 100644
> --- a/drivers/mfd/tps65218.c
> +++ b/drivers/mfd/tps65218.c
> @@ -211,6 +211,81 @@ static const struct of_device_id
> of_tps65218_match_table[] = {
> };
> MODULE_DEVICE_TABLE(of, of_tps65218_match_table);
>
> +static int tps65218_voltage_set_strict(struct tps65218 *tps)
> +{
> + u32 strict;
> +
> + if (of_property_read_u32(tps->dev->of_node,
> + "ti,strict-supply-voltage-supervision", ))
> + return 0;
> +
> + if (strict != 0 && strict != 1) {
> + dev_err(tps->dev,
> + "Invalid ti,strict-supply-voltage-supervision value\n");
> + return -EINVAL;
> + }
> +
> + tps65218_update_bits(tps, TPS65218_REG_CONFIG1,
> + TPS65218_CONFIG1_STRICT,
> + strict ? TPS65218_CONFIG1_STRICT : 0, TPS65218_PROTECT_L1);
> + return 0;
> +}
> +
> +static int tps65218_voltage_set_uv_hyst(struct tps65218 *tps)
> +{
> + u32 hyst;
> +
> + if (of_property_read_u32(tps->dev->of_node,
> + "ti,under-voltage-hyst-microvolt", ))
> + return 0;
> +
> + if (hyst != 40 && hyst != 20) {
> + dev_err(tps->dev,
> + "Invalid ti,under-voltage-hyst-microvolt value\n");
> + return -EINVAL;
> + }
> +
> + tps65218_update_bits(tps, TPS65218_REG_CONFIG2,
> + TPS65218_CONFIG2_UVLOHYS,
> + hyst == 40 ? TPS65218_CONFIG2_UVLOHYS : 0,
> + TPS65218_PROTECT_L1);
> + return 0;
> +}
> +
> +static int tps65218_voltage_set_uvlo(struct tps65218 *tps)
> +{
> + u32 uvlo;
> + int uvloval;
> +
> + if (of_property_read_u32(tps->dev->of_node,
> + "ti,under-voltage-limit-microvolt", ))
> + return 0;
> +
> + switch (uvlo) {
> + case 275:
> + uvloval = TPS65218_CONFIG1_UVLO_275;
> + break;
> + case 295:
> + uvloval = TPS65218_CONFIG1_UVLO_295;
> + break;
> + case 325:
> + uvloval = TPS65218_CONFIG1_UVLO_325;
> + break;
> + case 335:
> + uvloval = TPS65218_CONFIG1_UVLO_335;
> + break;
> + default:
> + dev_err(tps->dev,
> + "Invalid ti,under-voltage-limit-microvolt value\n");
> + return -EINVAL;
> + }
> +
> + tps65218_update_bits(tps, TPS65218_REG_CONFIG1,
> + TPS65218_CONFIG1_UVLO_MASK, uvloval,
> + TPS65218_PROTECT_L1);
> + return 0;
> +}
> +
> static int tps65218_probe(struct i2c_client *client,
> const struct i2c_device_id *ids)
> {
> @@ -249,6 +324,18 @@ static int tps65218_probe(struct i2c_client *client,
>
> tps->rev = chipid & TPS65218_CHIPID_REV_MASK;
>
> + ret = tps65218_voltage_set_strict(tps);
> + if (ret)
> + return ret;
> +
> + ret =
Re: [PATCH] Input: mcs_touchkey - use struct_size() in kzalloc()
On Tue, Jan 08, 2019 at 03:15:56PM -0600, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding the
> size of a structure that has a zero-sized array at the end, along with memory
> for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can now
> use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Applied, thank you.
> ---
> drivers/input/keyboard/mcs_touchkey.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/keyboard/mcs_touchkey.c
> b/drivers/input/keyboard/mcs_touchkey.c
> index be56d4f262a7..b132662201a4 100644
> --- a/drivers/input/keyboard/mcs_touchkey.c
> +++ b/drivers/input/keyboard/mcs_touchkey.c
> @@ -113,9 +113,8 @@ static int mcs_touchkey_probe(struct i2c_client *client,
> return -EINVAL;
> }
>
> - data = kzalloc(sizeof(struct mcs_touchkey_data) +
> - sizeof(data->keycodes[0]) * (pdata->key_maxval + 1),
> - GFP_KERNEL);
> + data = kzalloc(struct_size(data, keycodes, pdata->key_maxval + 1),
> +GFP_KERNEL);
> input_dev = input_allocate_device();
> if (!data || !input_dev) {
> dev_err(>dev, "Failed to allocate memory\n");
> --
> 2.20.1
>
--
Dmitry
Re: [PATCH v2] rbtree: fix the red root
‐‐‐ Original Message ‐‐‐ On Sunday, January 13, 2019 11:52 PM, Douglas Gilbert wrote: > On 2019-01-13 10:59 p.m., Esme wrote: > > > ‐‐‐ Original Message ‐‐‐ > > On Sunday, January 13, 2019 10:52 PM, Douglas Gilbert dgilb...@interlog.com > > wrote: > > > > > On 2019-01-13 10:07 p.m., Esme wrote: > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Sunday, January 13, 2019 9:33 PM, Qian Cai c...@lca.pw wrote: > > > > > > > > > On 1/13/19 9:20 PM, David Lechner wrote: > > > > > > > > > > > On 1/11/19 8:58 PM, Michel Lespinasse wrote: > > > > > > > > > > > > > On Fri, Jan 11, 2019 at 3:47 PM David Lechner > > > > > > > da...@lechnology.com wrote: > > > > > > > > > > > > > > > On 1/11/19 2:58 PM, Qian Cai wrote: > > > > > > > > > > > > > > > > > A GPF was reported, > > > > > > > > > kasan: CONFIG_KASAN_INLINE enabled > > > > > > > > > kasan: GPF could be caused by NULL-ptr deref or user memory > > > > > > > > > access > > > > > > > > > general protection fault: [#1] SMP KASAN > > > > > > > > > kasan_die_handler.cold.22+0x11/0x31 > > > > > > > > > notifier_call_chain+0x17b/0x390 > > > > > > > > > atomic_notifier_call_chain+0xa7/0x1b0 > > > > > > > > > notify_die+0x1be/0x2e0 > > > > > > > > > do_general_protection+0x13e/0x330 > > > > > > > > > general_protection+0x1e/0x30 > > > > > > > > > rb_insert_color+0x189/0x1480 > > > > > > > > > create_object+0x785/0xca0 > > > > > > > > > kmemleak_alloc+0x2f/0x50 > > > > > > > > > kmem_cache_alloc+0x1b9/0x3c0 > > > > > > > > > getname_flags+0xdb/0x5d0 > > > > > > > > > getname+0x1e/0x20 > > > > > > > > > do_sys_open+0x3a1/0x7d0 > > > > > > > > > __x64_sys_open+0x7e/0xc0 > > > > > > > > > do_syscall_64+0x1b3/0x820 > > > > > > > > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > > > > > > > It turned out, > > > > > > > > > gparent = rb_red_parent(parent); > > > > > > > > > tmp = gparent->rb_right; <-- GPF was triggered here. > > > > > > > > > Apparently, "gparent" is NULL which indicates "parent" is > > > > > > > > > rbtree's root > > > > > > > > > which is red. Otherwise, it will be treated properly a few > > > > > > > > > lines above. > > > > > > > > > /* > > > > > > > > > * If there is a black parent, we are done. > > > > > > > > > * Otherwise, take some corrective action as, > > > > > > > > > * per 4), we don't want a red root or two > > > > > > > > > * consecutive red nodes. > > > > > > > > > */ > > > > > > > > > if(rb_is_black(parent)) > > > > > > > > > break; > > > > > > > > > Hence, it violates the rule #1 (the root can't be red) and > > > > > > > > > need a fix > > > > > > > > > up, and also add a regression test for it. This looks like was > > > > > > > > > introduced by 6d58452dc06 where it no longer always paint the > > > > > > > > > root as > > > > > > > > > black. > > > > > > > > > Fixes: 6d58452dc06 (rbtree: adjust root color in > > > > > > > > > rb_insert_color() only > > > > > > > > > when necessary) > > > > > > > > > Reported-by: Esme espl...@protonmail.ch > > > > > > > > > Tested-by: Joey Pabalinas joeypabali...@gmail.com > > > > > > > > > Signed-off-by: Qian Cai c...@lca.pw > > > > > > > > > > > > > > > > Tested-by: David Lechner da...@lechnology.com > > > > > > > > FWIW, this fixed the following crash for me: > > > > > > > > Unable to handle kernel NULL pointer dereference at virtual > > > > > > > > address 0004 > > > > > > > > > > > > > > Just to clarify, do you have a way to reproduce this crash > > > > > > > without the fix ? > > > > > > > > > > > > I am starting to suspect that my crash was caused by some new code > > > > > > in the drm-misc-next tree that might be causing a memory corruption. > > > > > > It threw me off that the stack trace didn't contain anything related > > > > > > to drm. > > > > > > See: https://patchwork.freedesktop.org/patch/276719/ > > > > > > > > > > It may be useful for those who could reproduce this issue to turn on > > > > > those > > > > > memory corruption debug options to narrow down a bit. > > > > > CONFIG_DEBUG_PAGEALLOC=y > > > > > CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y > > > > > CONFIG_KASAN=y > > > > > CONFIG_KASAN_GENERIC=y > > > > > CONFIG_SLUB_DEBUG_ON=y > > > > > > > > I have been on SLAB, I configured SLAB DEBUG with a fresh pull from > > > > github. Linux syzkaller 5.0.0-rc2 #9 SMP Sun Jan 13 21:57:40 EST 2019 > > > > x86_64 > > > > ... > > > > In an effort to get a different stack into the kernel, I felt that > > > > nothing works better than fork bomb? :) > > > > Let me know if that helps. > > > > root@syzkaller:~# gcc -o test3 test3.c > > > > root@syzkaller:~# while : ; do ./test3 & done > > > > > > And is test3 the same multi-threaded program that enters the kernel via > > > /dev/sg0 and then calls SCSI_IOCTL_SEND_COMMAND which goes to the SCSI > > > mid-level and thence to the
[PATCH v8 7/8] gpio: pci-idio-16: Utilize for_each_set_clump8 macro
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump8 macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-pci-idio-16.c | 75 -
1 file changed, 28 insertions(+), 47 deletions(-)
diff --git a/drivers/gpio/gpio-pci-idio-16.c b/drivers/gpio/gpio-pci-idio-16.c
index 6b7349783223..b0ed6bb68296 100644
--- a/drivers/gpio/gpio-pci-idio-16.c
+++ b/drivers/gpio/gpio-pci-idio-16.c
@@ -108,45 +108,24 @@ static int idio_16_gpio_get_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct idio_16_gpio *const idio16gpio = gpiochip_get_data(chip);
- size_t i;
- const unsigned int gpio_reg_size = 8;
- unsigned int bits_offset;
- size_t word_index;
- unsigned int word_offset;
- unsigned long word_mask;
- const unsigned long port_mask = GENMASK(gpio_reg_size - 1, 0);
- unsigned long port_state;
+ unsigned int offset;
+ unsigned long gpio_mask;
void __iomem *ports[] = {
>reg->out0_7, >reg->out8_15,
>reg->in0_7, >reg->in8_15,
};
+ const unsigned int ngpio = ARRAY_SIZE(ports) * 8;
+ void __iomem *port_addr;
+ unsigned long port_state;
/* clear bits array to a clean slate */
bitmap_zero(bits, chip->ngpio);
- /* get bits are evaluated a gpio port register at a time */
- for (i = 0; i < ARRAY_SIZE(ports); i++) {
- /* gpio offset in bits array */
- bits_offset = i * gpio_reg_size;
-
- /* word index for bits array */
- word_index = BIT_WORD(bits_offset);
-
- /* gpio offset within current word of bits array */
- word_offset = bits_offset % BITS_PER_LONG;
+ for_each_set_clump8(offset, gpio_mask, mask, ngpio) {
+ port_addr = ports[offset / 8];
+ port_state = ioread8(port_addr) & gpio_mask;
- /* mask of get bits for current gpio within current word */
- word_mask = mask[word_index] & (port_mask << word_offset);
- if (!word_mask) {
- /* no get bits in this port so skip to next one */
- continue;
- }
-
- /* read bits from current gpio port */
- port_state = ioread8(ports[i]);
-
- /* store acquired bits at respective bits array offset */
- bits[word_index] |= (port_state << word_offset) & word_mask;
+ bitmap_set_value8(bits, ngpio, port_state, offset);
}
return 0;
@@ -186,30 +165,32 @@ static void idio_16_gpio_set_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct idio_16_gpio *const idio16gpio = gpiochip_get_data(chip);
+ unsigned int offset;
+ unsigned long gpio_mask;
+ void __iomem *ports[] = {
+ >reg->out0_7, >reg->out8_15,
+ };
+ const unsigned int ngpio = ARRAY_SIZE(ports) * 8;
+ size_t index;
+ void __iomem *port_addr;
+ unsigned int bitmask;
unsigned long flags;
unsigned int out_state;
- raw_spin_lock_irqsave(>lock, flags);
+ for_each_set_clump8(offset, gpio_mask, mask, ngpio) {
+ index = offset / 8;
+ port_addr = ports[index];
- /* process output lines 0-7 */
- if (*mask & 0xFF) {
- out_state = ioread8(>reg->out0_7) & ~*mask;
- out_state |= *mask & *bits;
- iowrite8(out_state, >reg->out0_7);
- }
+ bitmask = bitmap_get_value8(bits, ngpio, offset) & gpio_mask;
+
+ raw_spin_lock_irqsave(>lock, flags);
- /* shift to next output line word */
- *mask >>= 8;
+ out_state = ioread8(port_addr) & ~gpio_mask;
+ out_state |= bitmask;
+ iowrite8(out_state, port_addr);
- /* process output lines 8-15 */
- if (*mask & 0xFF) {
- *bits >>= 8;
- out_state = ioread8(>reg->out8_15) & ~*mask;
- out_state |= *mask & *bits;
- iowrite8(out_state, >reg->out8_15);
+ raw_spin_unlock_irqrestore(>lock, flags);
}
-
- raw_spin_unlock_irqrestore(>lock, flags);
}
static void idio_16_irq_ack(struct irq_data *data)
--
2.20.1
[PATCH v8 8/8] gpio: pcie-idio-24: Utilize for_each_set_clump8 macro
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump8 macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-pcie-idio-24.c | 111 ---
1 file changed, 42 insertions(+), 69 deletions(-)
diff --git a/drivers/gpio/gpio-pcie-idio-24.c b/drivers/gpio/gpio-pcie-idio-24.c
index 52f1647a46fd..2ceff1f5d8fd 100644
--- a/drivers/gpio/gpio-pcie-idio-24.c
+++ b/drivers/gpio/gpio-pcie-idio-24.c
@@ -198,52 +198,35 @@ static int idio_24_gpio_get_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct idio_24_gpio *const idio24gpio = gpiochip_get_data(chip);
- size_t i;
- const unsigned int gpio_reg_size = 8;
- unsigned int bits_offset;
- size_t word_index;
- unsigned int word_offset;
- unsigned long word_mask;
- const unsigned long port_mask = GENMASK(gpio_reg_size - 1, 0);
- unsigned long port_state;
+ unsigned int offset;
+ unsigned long gpio_mask;
void __iomem *ports[] = {
>reg->out0_7, >reg->out8_15,
>reg->out16_23, >reg->in0_7,
>reg->in8_15, >reg->in16_23,
};
+ const unsigned int ngpio = ARRAY_SIZE(ports) * 8;
+ size_t index;
+ unsigned long port_state;
const unsigned long out_mode_mask = BIT(1);
/* clear bits array to a clean slate */
bitmap_zero(bits, chip->ngpio);
- /* get bits are evaluated a gpio port register at a time */
- for (i = 0; i < ARRAY_SIZE(ports) + 1; i++) {
- /* gpio offset in bits array */
- bits_offset = i * gpio_reg_size;
-
- /* word index for bits array */
- word_index = BIT_WORD(bits_offset);
-
- /* gpio offset within current word of bits array */
- word_offset = bits_offset % BITS_PER_LONG;
-
- /* mask of get bits for current gpio within current word */
- word_mask = mask[word_index] & (port_mask << word_offset);
- if (!word_mask) {
- /* no get bits in this port so skip to next one */
- continue;
- }
+ for_each_set_clump8(offset, gpio_mask, mask, ngpio) {
+ index = offset / 8;
/* read bits from current gpio port (port 6 is TTL GPIO) */
- if (i < 6)
- port_state = ioread8(ports[i]);
+ if (index < 6)
+ port_state = ioread8(ports[index]);
else if (ioread8(>reg->ctl) & out_mode_mask)
port_state = ioread8(>reg->ttl_out0_7);
else
port_state = ioread8(>reg->ttl_in0_7);
- /* store acquired bits at respective bits array offset */
- bits[word_index] |= (port_state << word_offset) & word_mask;
+ port_state &= gpio_mask;
+
+ bitmap_set_value8(bits, ngpio, port_state, offset);
}
return 0;
@@ -294,59 +277,49 @@ static void idio_24_gpio_set_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct idio_24_gpio *const idio24gpio = gpiochip_get_data(chip);
- size_t i;
- unsigned long bits_offset;
+ unsigned int offset;
unsigned long gpio_mask;
- const unsigned int gpio_reg_size = 8;
- const unsigned long port_mask = GENMASK(gpio_reg_size, 0);
- unsigned long flags;
- unsigned int out_state;
void __iomem *ports[] = {
>reg->out0_7, >reg->out8_15,
>reg->out16_23
};
+ const unsigned int ngpio = ARRAY_SIZE(ports) * 8;
+ size_t index;
+ unsigned int bitmask;
+ unsigned long flags;
+ unsigned int out_state;
const unsigned long out_mode_mask = BIT(1);
- const unsigned int ttl_offset = 48;
- const size_t ttl_i = BIT_WORD(ttl_offset);
- const unsigned int word_offset = ttl_offset % BITS_PER_LONG;
- const unsigned long ttl_mask = (mask[ttl_i] >> word_offset) & port_mask;
- const unsigned long ttl_bits = (bits[ttl_i] >> word_offset) & ttl_mask;
-
- /* set bits are processed a gpio port register at a time */
- for (i = 0; i < ARRAY_SIZE(ports); i++) {
- /* gpio offset in bits array */
- bits_offset = i * gpio_reg_size;
-
- /* check if any set bits for current port */
- gpio_mask = (*mask >> bits_offset) & port_mask;
- if (!gpio_mask) {
- /* no set bits for this port so move on to next port */
- continue;
- }
- raw_spin_lock_irqsave(>lock, flags);
+ for_each_set_clump8(offset, gpio_mask, mask, ngpio) {
+ index = offset / 8;
- /* process output
[PATCH v8 6/8] gpio: ws16c48: Utilize for_each_set_clump8 macro
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump8 macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-ws16c48.c | 72 +++--
1 file changed, 20 insertions(+), 52 deletions(-)
diff --git a/drivers/gpio/gpio-ws16c48.c b/drivers/gpio/gpio-ws16c48.c
index 5cf3697bfb15..1d071a3d3e81 100644
--- a/drivers/gpio/gpio-ws16c48.c
+++ b/drivers/gpio/gpio-ws16c48.c
@@ -134,42 +134,19 @@ static int ws16c48_gpio_get_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct ws16c48_gpio *const ws16c48gpio = gpiochip_get_data(chip);
- const unsigned int gpio_reg_size = 8;
- size_t i;
- const size_t num_ports = chip->ngpio / gpio_reg_size;
- unsigned int bits_offset;
- size_t word_index;
- unsigned int word_offset;
- unsigned long word_mask;
- const unsigned long port_mask = GENMASK(gpio_reg_size - 1, 0);
+ unsigned int offset;
+ unsigned long gpio_mask;
+ unsigned int port_addr;
unsigned long port_state;
/* clear bits array to a clean slate */
bitmap_zero(bits, chip->ngpio);
- /* get bits are evaluated a gpio port register at a time */
- for (i = 0; i < num_ports; i++) {
- /* gpio offset in bits array */
- bits_offset = i * gpio_reg_size;
+ for_each_set_clump8(offset, gpio_mask, mask, chip->ngpio) {
+ port_addr = ws16c48gpio->base + offset / 8;
+ port_state = inb(port_addr) & gpio_mask;
- /* word index for bits array */
- word_index = BIT_WORD(bits_offset);
-
- /* gpio offset within current word of bits array */
- word_offset = bits_offset % BITS_PER_LONG;
-
- /* mask of get bits for current gpio within current word */
- word_mask = mask[word_index] & (port_mask << word_offset);
- if (!word_mask) {
- /* no get bits in this port so skip to next one */
- continue;
- }
-
- /* read bits from current gpio port */
- port_state = inb(ws16c48gpio->base + i);
-
- /* store acquired bits at respective bits array offset */
- bits[word_index] |= (port_state << word_offset) & word_mask;
+ bitmap_set_value8(bits, chip->ngpio, port_state, offset);
}
return 0;
@@ -203,39 +180,30 @@ static void ws16c48_gpio_set_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct ws16c48_gpio *const ws16c48gpio = gpiochip_get_data(chip);
- unsigned int i;
- const unsigned int gpio_reg_size = 8;
- unsigned int port;
- unsigned int iomask;
+ unsigned int offset;
+ unsigned long gpio_mask;
+ size_t index;
+ unsigned int port_addr;
unsigned int bitmask;
unsigned long flags;
- /* set bits are evaluated a gpio register size at a time */
- for (i = 0; i < chip->ngpio; i += gpio_reg_size) {
- /* no more set bits in this mask word; skip to the next word */
- if (!mask[BIT_WORD(i)]) {
- i = (BIT_WORD(i) + 1) * BITS_PER_LONG - gpio_reg_size;
- continue;
- }
-
- port = i / gpio_reg_size;
+ for_each_set_clump8(offset, gpio_mask, mask, chip->ngpio) {
+ index = offset / 8;
+ port_addr = ws16c48gpio->base + index;
/* mask out GPIO configured for input */
- iomask = mask[BIT_WORD(i)] & ~ws16c48gpio->io_state[port];
- bitmask = iomask & bits[BIT_WORD(i)];
+ gpio_mask &= ~ws16c48gpio->io_state[index];
+ bitmask = bitmap_get_value8(bits, chip->ngpio, offset) &
+ gpio_mask;
raw_spin_lock_irqsave(>lock, flags);
/* update output state data and set device gpio register */
- ws16c48gpio->out_state[port] &= ~iomask;
- ws16c48gpio->out_state[port] |= bitmask;
- outb(ws16c48gpio->out_state[port], ws16c48gpio->base + port);
+ ws16c48gpio->out_state[index] &= ~gpio_mask;
+ ws16c48gpio->out_state[index] |= bitmask;
+ outb(ws16c48gpio->out_state[index], port_addr);
raw_spin_unlock_irqrestore(>lock, flags);
-
- /* prepare for next gpio register set */
- mask[BIT_WORD(i)] >>= gpio_reg_size;
- bits[BIT_WORD(i)] >>= gpio_reg_size;
}
}
--
2.20.1
[PATCH v8 5/8] gpio: gpio-mm: Utilize for_each_set_clump8 macro
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump8 macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-gpio-mm.c | 73 +++--
1 file changed, 22 insertions(+), 51 deletions(-)
diff --git a/drivers/gpio/gpio-gpio-mm.c b/drivers/gpio/gpio-gpio-mm.c
index 8c150fd68d9d..4c1037a005ab 100644
--- a/drivers/gpio/gpio-gpio-mm.c
+++ b/drivers/gpio/gpio-gpio-mm.c
@@ -172,46 +172,26 @@ static int gpiomm_gpio_get(struct gpio_chip *chip,
unsigned int offset)
return !!(port_state & mask);
}
+static const size_t ports[] = { 0, 1, 2, 4, 5, 6 };
+
static int gpiomm_gpio_get_multiple(struct gpio_chip *chip, unsigned long
*mask,
unsigned long *bits)
{
struct gpiomm_gpio *const gpiommgpio = gpiochip_get_data(chip);
- size_t i;
- static const size_t ports[] = { 0, 1, 2, 4, 5, 6 };
- const unsigned int gpio_reg_size = 8;
- unsigned int bits_offset;
- size_t word_index;
- unsigned int word_offset;
- unsigned long word_mask;
- const unsigned long port_mask = GENMASK(gpio_reg_size - 1, 0);
+ unsigned int offset;
+ unsigned long gpio_mask;
+ const unsigned int ngpio = ARRAY_SIZE(ports) * 8;
+ unsigned int port_addr;
unsigned long port_state;
/* clear bits array to a clean slate */
bitmap_zero(bits, chip->ngpio);
- /* get bits are evaluated a gpio port register at a time */
- for (i = 0; i < ARRAY_SIZE(ports); i++) {
- /* gpio offset in bits array */
- bits_offset = i * gpio_reg_size;
-
- /* word index for bits array */
- word_index = BIT_WORD(bits_offset);
-
- /* gpio offset within current word of bits array */
- word_offset = bits_offset % BITS_PER_LONG;
-
- /* mask of get bits for current gpio within current word */
- word_mask = mask[word_index] & (port_mask << word_offset);
- if (!word_mask) {
- /* no get bits in this port so skip to next one */
- continue;
- }
-
- /* read bits from current gpio port */
- port_state = inb(gpiommgpio->base + ports[i]);
+ for_each_set_clump8(offset, gpio_mask, mask, ngpio) {
+ port_addr = gpiommgpio->base + ports[offset / 8];
+ port_state = inb(port_addr) & gpio_mask;
- /* store acquired bits at respective bits array offset */
- bits[word_index] |= (port_state << word_offset) & word_mask;
+ bitmap_set_value8(bits, ngpio, port_state, offset);
}
return 0;
@@ -242,37 +222,28 @@ static void gpiomm_gpio_set_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct gpiomm_gpio *const gpiommgpio = gpiochip_get_data(chip);
- unsigned int i;
- const unsigned int gpio_reg_size = 8;
- unsigned int port;
- unsigned int out_port;
+ unsigned int offset;
+ unsigned long gpio_mask;
+ const unsigned int ngpio = ARRAY_SIZE(ports) * 8;
+ size_t index;
+ unsigned int port_addr;
unsigned int bitmask;
unsigned long flags;
- /* set bits are evaluated a gpio register size at a time */
- for (i = 0; i < chip->ngpio; i += gpio_reg_size) {
- /* no more set bits in this mask word; skip to the next word */
- if (!mask[BIT_WORD(i)]) {
- i = (BIT_WORD(i) + 1) * BITS_PER_LONG - gpio_reg_size;
- continue;
- }
+ for_each_set_clump8(offset, gpio_mask, mask, ngpio) {
+ index = offset / 8;
+ port_addr = gpiommgpio->base + ports[index];
- port = i / gpio_reg_size;
- out_port = (port > 2) ? port + 1 : port;
- bitmask = mask[BIT_WORD(i)] & bits[BIT_WORD(i)];
+ bitmask = bitmap_get_value8(bits, ngpio, offset) & gpio_mask;
spin_lock_irqsave(>lock, flags);
/* update output state data and set device gpio register */
- gpiommgpio->out_state[port] &= ~mask[BIT_WORD(i)];
- gpiommgpio->out_state[port] |= bitmask;
- outb(gpiommgpio->out_state[port], gpiommgpio->base + out_port);
+ gpiommgpio->out_state[index] &= ~gpio_mask;
+ gpiommgpio->out_state[index] |= bitmask;
+ outb(gpiommgpio->out_state[index], port_addr);
spin_unlock_irqrestore(>lock, flags);
-
- /* prepare for next gpio register set */
- mask[BIT_WORD(i)] >>= gpio_reg_size;
- bits[BIT_WORD(i)] >>= gpio_reg_size;
}
}
--
2.20.1
[PATCH v8 3/8] gpio: 104-dio-48e: Utilize for_each_set_clump8 macro
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump8 macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-104-dio-48e.c | 73 ++---
1 file changed, 22 insertions(+), 51 deletions(-)
diff --git a/drivers/gpio/gpio-104-dio-48e.c b/drivers/gpio/gpio-104-dio-48e.c
index 92c8f944bf64..23413d90e944 100644
--- a/drivers/gpio/gpio-104-dio-48e.c
+++ b/drivers/gpio/gpio-104-dio-48e.c
@@ -183,46 +183,26 @@ static int dio48e_gpio_get(struct gpio_chip *chip,
unsigned offset)
return !!(port_state & mask);
}
+static const size_t ports[] = { 0, 1, 2, 4, 5, 6 };
+
static int dio48e_gpio_get_multiple(struct gpio_chip *chip, unsigned long
*mask,
unsigned long *bits)
{
struct dio48e_gpio *const dio48egpio = gpiochip_get_data(chip);
- size_t i;
- static const size_t ports[] = { 0, 1, 2, 4, 5, 6 };
- const unsigned int gpio_reg_size = 8;
- unsigned int bits_offset;
- size_t word_index;
- unsigned int word_offset;
- unsigned long word_mask;
- const unsigned long port_mask = GENMASK(gpio_reg_size - 1, 0);
+ unsigned int offset;
+ unsigned long gpio_mask;
+ const unsigned int ngpio = ARRAY_SIZE(ports) * 8;
+ unsigned int port_addr;
unsigned long port_state;
/* clear bits array to a clean slate */
bitmap_zero(bits, chip->ngpio);
- /* get bits are evaluated a gpio port register at a time */
- for (i = 0; i < ARRAY_SIZE(ports); i++) {
- /* gpio offset in bits array */
- bits_offset = i * gpio_reg_size;
-
- /* word index for bits array */
- word_index = BIT_WORD(bits_offset);
-
- /* gpio offset within current word of bits array */
- word_offset = bits_offset % BITS_PER_LONG;
-
- /* mask of get bits for current gpio within current word */
- word_mask = mask[word_index] & (port_mask << word_offset);
- if (!word_mask) {
- /* no get bits in this port so skip to next one */
- continue;
- }
-
- /* read bits from current gpio port */
- port_state = inb(dio48egpio->base + ports[i]);
+ for_each_set_clump8(offset, gpio_mask, mask, ngpio) {
+ port_addr = dio48egpio->base + ports[offset / 8];
+ port_state = inb(port_addr) & gpio_mask;
- /* store acquired bits at respective bits array offset */
- bits[word_index] |= (port_state << word_offset) & word_mask;
+ bitmap_set_value8(bits, ngpio, port_state, offset);
}
return 0;
@@ -252,37 +232,28 @@ static void dio48e_gpio_set_multiple(struct gpio_chip
*chip,
unsigned long *mask, unsigned long *bits)
{
struct dio48e_gpio *const dio48egpio = gpiochip_get_data(chip);
- unsigned int i;
- const unsigned int gpio_reg_size = 8;
- unsigned int port;
- unsigned int out_port;
+ unsigned int offset;
+ unsigned long gpio_mask;
+ const unsigned int ngpio = ARRAY_SIZE(ports) * 8;
+ size_t index;
+ unsigned int port_addr;
unsigned int bitmask;
unsigned long flags;
- /* set bits are evaluated a gpio register size at a time */
- for (i = 0; i < chip->ngpio; i += gpio_reg_size) {
- /* no more set bits in this mask word; skip to the next word */
- if (!mask[BIT_WORD(i)]) {
- i = (BIT_WORD(i) + 1) * BITS_PER_LONG - gpio_reg_size;
- continue;
- }
+ for_each_set_clump8(offset, gpio_mask, mask, ngpio) {
+ index = offset / 8;
+ port_addr = dio48egpio->base + ports[index];
- port = i / gpio_reg_size;
- out_port = (port > 2) ? port + 1 : port;
- bitmask = mask[BIT_WORD(i)] & bits[BIT_WORD(i)];
+ bitmask = bitmap_get_value8(bits, ngpio, offset) & gpio_mask;
raw_spin_lock_irqsave(>lock, flags);
/* update output state data and set device gpio register */
- dio48egpio->out_state[port] &= ~mask[BIT_WORD(i)];
- dio48egpio->out_state[port] |= bitmask;
- outb(dio48egpio->out_state[port], dio48egpio->base + out_port);
+ dio48egpio->out_state[index] &= ~gpio_mask;
+ dio48egpio->out_state[index] |= bitmask;
+ outb(dio48egpio->out_state[index], port_addr);
raw_spin_unlock_irqrestore(>lock, flags);
-
- /* prepare for next gpio register set */
- mask[BIT_WORD(i)] >>= gpio_reg_size;
- bits[BIT_WORD(i)] >>= gpio_reg_size;
}
}
--
2.20.1
[PATCH v8 4/8] gpio: 104-idi-48: Utilize for_each_set_clump8 macro
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump8 macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-104-idi-48.c | 37 --
1 file changed, 8 insertions(+), 29 deletions(-)
diff --git a/drivers/gpio/gpio-104-idi-48.c b/drivers/gpio/gpio-104-idi-48.c
index 88dc6f2449f6..59c571aecf9a 100644
--- a/drivers/gpio/gpio-104-idi-48.c
+++ b/drivers/gpio/gpio-104-idi-48.c
@@ -93,42 +93,21 @@ static int idi_48_gpio_get_multiple(struct gpio_chip *chip,
unsigned long *mask,
unsigned long *bits)
{
struct idi_48_gpio *const idi48gpio = gpiochip_get_data(chip);
- size_t i;
+ unsigned int offset;
+ unsigned long gpio_mask;
static const size_t ports[] = { 0, 1, 2, 4, 5, 6 };
- const unsigned int gpio_reg_size = 8;
- unsigned int bits_offset;
- size_t word_index;
- unsigned int word_offset;
- unsigned long word_mask;
- const unsigned long port_mask = GENMASK(gpio_reg_size - 1, 0);
+ const unsigned int ngpio = ARRAY_SIZE(ports) * 8;
+ unsigned int port_addr;
unsigned long port_state;
/* clear bits array to a clean slate */
bitmap_zero(bits, chip->ngpio);
- /* get bits are evaluated a gpio port register at a time */
- for (i = 0; i < ARRAY_SIZE(ports); i++) {
- /* gpio offset in bits array */
- bits_offset = i * gpio_reg_size;
+ for_each_set_clump8(offset, gpio_mask, mask, ngpio) {
+ port_addr = idi48gpio->base + ports[offset / 8];
+ port_state = inb(port_addr) & gpio_mask;
- /* word index for bits array */
- word_index = BIT_WORD(bits_offset);
-
- /* gpio offset within current word of bits array */
- word_offset = bits_offset % BITS_PER_LONG;
-
- /* mask of get bits for current gpio within current word */
- word_mask = mask[word_index] & (port_mask << word_offset);
- if (!word_mask) {
- /* no get bits in this port so skip to next one */
- continue;
- }
-
- /* read bits from current gpio port */
- port_state = inb(idi48gpio->base + ports[i]);
-
- /* store acquired bits at respective bits array offset */
- bits[word_index] |= (port_state << word_offset) & word_mask;
+ bitmap_set_value8(bits, ngpio, port_state, offset);
}
return 0;
--
2.20.1
[PATCH v8 2/8] lib/test_bitmap.c: Add for_each_set_clump8 test cases
The introduction of the for_each_set_clump8 macro warrants test cases to
verify the implementation. This patch adds test case checks for whether
an out-of-bounds clump index is returned, a zero clump is returned, or
the returned clump value differs from the expected clump value.
Cc: Andy Shevchenko
Cc: Andrew Morton
Cc: Rasmus Villemoes
Signed-off-by: William Breathitt Gray
---
lib/test_bitmap.c | 65 +++
1 file changed, 65 insertions(+)
diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 6cd7d0740005..66ddb3fb98cb 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -88,6 +88,36 @@ __check_eq_u32_array(const char *srcfile, unsigned int line,
return true;
}
+static bool __init __check_eq_clump8(const char *srcfile, unsigned int line,
+ const unsigned int offset,
+ const unsigned int size,
+ const unsigned char *const clump_exp,
+ const unsigned long *const clump)
+{
+ unsigned long exp;
+
+ if (offset >= size) {
+ pr_warn("[%s:%u] bit offset for clump out-of-bounds: expected
less than %u, got %u\n",
+ srcfile, line, size, offset);
+ return false;
+ }
+
+ exp = clump_exp[offset / 8];
+ if (!exp) {
+ pr_warn("[%s:%u] bit offset for zero clump: expected nonzero
clump, got bit offset %u with clump value 0",
+ srcfile, line, offset);
+ return false;
+ }
+
+ if (*clump != exp) {
+ pr_warn("[%s:%u] expected clump value of 0x%lX, got clump value
of 0x%lX",
+ srcfile, line, exp, *clump);
+ return false;
+ }
+
+ return true;
+}
+
#define __expect_eq(suffix, ...) \
({ \
int result = 0; \
@@ -104,6 +134,7 @@ __check_eq_u32_array(const char *srcfile, unsigned int line,
#define expect_eq_bitmap(...) __expect_eq(bitmap, ##__VA_ARGS__)
#define expect_eq_pbl(...) __expect_eq(pbl, ##__VA_ARGS__)
#define expect_eq_u32_array(...) __expect_eq(u32_array, ##__VA_ARGS__)
+#define expect_eq_clump8(...) __expect_eq(clump8, ##__VA_ARGS__)
static void __init test_zero_clear(void)
{
@@ -361,6 +392,39 @@ static void noinline __init test_mem_optimisations(void)
}
}
+static const unsigned char clump_exp[] __initconst = {
+ 0x01, /* 1 bit set */
+ 0x02, /* non-edge 1 bit set */
+ 0x00, /* zero bits set */
+ 0x28, /* 3 bits set across 4-bit boundary */
+ 0x28, /* Repeated clump */
+ 0x0F, /* 4 bits set */
+ 0xFF, /* all bits set */
+ 0x05, /* non-adjacent 2 bits set */
+};
+
+static void __init test_for_each_set_clump8(void)
+{
+#define CLUMP_EXP_NUMBITS 64
+ DECLARE_BITMAP(bits, CLUMP_EXP_NUMBITS);
+ unsigned int start;
+ unsigned long clump;
+
+ /* set bitmap to test case */
+ bitmap_zero(bits, CLUMP_EXP_NUMBITS);
+ bitmap_set(bits, 0, 1); /* 0x01 */
+ bitmap_set(bits, 8, 1); /* 0x02 */
+ bitmap_set(bits, 27, 3);/* 0x28 */
+ bitmap_set(bits, 35, 3);/* 0x28 */
+ bitmap_set(bits, 40, 4);/* 0x0F */
+ bitmap_set(bits, 48, 8);/* 0xFF */
+ bitmap_set(bits, 56, 1);/* 0x05 - part 1 */
+ bitmap_set(bits, 58, 1);/* 0x05 - part 2 */
+
+ for_each_set_clump8(start, clump, bits, CLUMP_EXP_NUMBITS)
+ expect_eq_clump8(start, CLUMP_EXP_NUMBITS, clump_exp, );
+}
+
static int __init test_bitmap_init(void)
{
test_zero_clear();
@@ -369,6 +433,7 @@ static int __init test_bitmap_init(void)
test_bitmap_arr32();
test_bitmap_parselist();
test_mem_optimisations();
+ test_for_each_set_clump8();
if (failed_tests == 0)
pr_info("all %u tests passed\n", total_tests);
--
2.20.1
[PATCH v8 1/8] bitops: Introduce the for_each_set_clump8 macro
This macro iterates for each 8-bit group of bits (clump) with set bits,
within a bitmap memory region. For each iteration, "start" is set to the
bit offset of the found clump, while the respective clump value is
stored to the location pointed by "clump". Additionally, the
bitmap_get_value8 and bitmap_set_value8 functions are introduced to
respectively get and set an 8-bit value in a bitmap memory region.
Suggested-by: Andy Shevchenko
Suggested-by: Rasmus Villemoes
Cc: Arnd Bergmann
Cc: Andrew Morton
Signed-off-by: William Breathitt Gray
---
include/asm-generic/bitops/find.h | 14 ++
include/linux/bitops.h| 5 ++
lib/find_bit.c| 81 +++
3 files changed, 100 insertions(+)
diff --git a/include/asm-generic/bitops/find.h
b/include/asm-generic/bitops/find.h
index 8a1ee10014de..9a76adff59c6 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -80,4 +80,18 @@ extern unsigned long find_first_zero_bit(const unsigned long
*addr,
#endif /* CONFIG_GENERIC_FIND_FIRST_BIT */
+unsigned long bitmap_get_value8(const unsigned long *const bitmap,
+ const unsigned int size,
+ const unsigned int start);
+
+void bitmap_set_value8(unsigned long *const bitmap, const unsigned int size,
+ const unsigned long value, const unsigned int start);
+
+unsigned int find_next_clump8(unsigned long *const clump,
+ const unsigned long *const addr,
+ unsigned int offset, const unsigned int size);
+
+#define find_first_clump8(clump, bits, size) \
+ find_next_clump8((clump), (bits), 0, (size))
+
#endif /*_ASM_GENERIC_BITOPS_FIND_H_ */
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 705f7c442691..61c10f20079e 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -40,6 +40,11 @@ extern unsigned long __sw_hweight64(__u64 w);
(bit) < (size);\
(bit) = find_next_zero_bit((addr), (size), (bit) + 1))
+#define for_each_set_clump8(start, clump, bits, size) \
+ for ((start) = find_first_clump8(&(clump), (bits), (size)); \
+(start) < (size); \
+(start) = find_next_clump8(&(clump), (bits), (start) + 8, (size)))
+
static inline int get_bitmask_order(unsigned int count)
{
int order;
diff --git a/lib/find_bit.c b/lib/find_bit.c
index ee3df93ba69a..c2af1f013ea2 100644
--- a/lib/find_bit.c
+++ b/lib/find_bit.c
@@ -218,3 +218,84 @@ EXPORT_SYMBOL(find_next_bit_le);
#endif
#endif /* __BIG_ENDIAN */
+
+/**
+ * bitmap_get_value8 - get an 8-bit value within a memory region
+ * @bitmap: address to the bitmap memory region
+ * @size: bitmap size in number of bits
+ * @start: bit offset of the 8-bit value
+ *
+ * Returns the 8-bit value located at the @start bit offset within the @bitmap
+ * memory region.
+ */
+unsigned long bitmap_get_value8(const unsigned long *const bitmap,
+ const unsigned int size,
+ const unsigned int start)
+{
+ const size_t index = BIT_WORD(start);
+ const unsigned int offset = start % BITS_PER_LONG;
+ const unsigned int low_width = (offset + 8 > BITS_PER_LONG) ?
+ BITS_PER_LONG - offset : 8;
+ const unsigned long low = bitmap[index] >> offset;
+ const unsigned long high = (low_width < 8 && start + 8 <= size) ?
+ bitmap[index + 1] << low_width : 0;
+
+ return (low | high) & 0xFF;
+}
+EXPORT_SYMBOL(bitmap_get_value8);
+
+/**
+ * bitmap_set_value8 - set an 8-bit value within a memory region
+ * @bitmap: address to the bitmap memory region
+ * @size: bitmap size in number of bits
+ * @value: the 8-bit value; values wider than 8 bits may clobber bitmap
+ * @start: bit offset of the 8-bit value
+ */
+void bitmap_set_value8(unsigned long *const bitmap, const unsigned int size,
+ const unsigned long value, const unsigned int start)
+{
+ const size_t index = BIT_WORD(start);
+ const unsigned int offset = start % BITS_PER_LONG;
+ const unsigned int low_width = (offset + 8 > BITS_PER_LONG) ?
+ BITS_PER_LONG - offset : 8;
+ const unsigned long low_mask = GENMASK(offset + low_width - 1, offset);
+ const unsigned int high_width = 8 - low_width;
+ const unsigned long high_mask = GENMASK(high_width - 1, 0);
+
+ /* set lower portion */
+ bitmap[index] &= ~low_mask;
+ bitmap[index] |= value << offset;
+
+ /* set higher portion if space available in bitmap */
+ if (high_width && start + 8 <= size) {
+ bitmap[index + 1] &= ~high_mask;
+ bitmap[index + 1] |= value >> low_width;
+ }
+}
+EXPORT_SYMBOL(bitmap_set_value8);
+
+/**
+ * find_next_clump8 - find
RE: [PATCH v2 2/2] driver: clocksource: Add nxp system counter timer driver support
Ping...
BR
Jacky Bai
> -Original Message-
> From: Jacky Bai
> Sent: 2018年12月12日 13:28
> To: daniel.lezc...@linaro.org; t...@linutronix.de; robh...@kernel.org;
> shawn...@kernel.org; mark.rutl...@arm.com; Aisheng Dong
>
> Cc: linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; dl-linux-imx
>
> Subject: [PATCH v2 2/2] driver: clocksource: Add nxp system counter timer
> driver support
>
> The system counter (sys_ctr) is a programmable system counter which
> provides a shared time base to the Cortex A15, A7, A53 etc cores.
> It is intended for use in applications where the counter is always powered on
> and supports multiple, unrelated clocks. The sys_ctr hardware
> supports:
> - 56-bit counter width (roll-over time greater than 40 years)
> - compare frame(64-bit compare value) contains programmable interrupt
>generation
>
> Signed-off-by: Bai Ping
> ---
> change v1->v2:
> - no change
> ---
> drivers/clocksource/Kconfig| 8 ++
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-imx-sysctr.c | 204
> +
> 3 files changed, 213 insertions(+)
> create mode 100644 drivers/clocksource/timer-imx-sysctr.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index
> c57b156..7e5f2de 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -579,6 +579,14 @@ config CLKSRC_IMX_TPM
> Enable this option to use IMX Timer/PWM Module (TPM) timer as
> clocksource.
>
> +config CLKSRC_IMX_SYS_CTR
> + bool "Clocksource using i.MX system counter" if COMPILE_TEST
> + depends on (ARM || ARM64) && CLKDEV_LOOKUP
> + select CLKSRC_MMIO
> + help
> + Enable this option to use IMX system counter timer as
> + clocksource.
> +
> config CLKSRC_ST_LPC
> bool "Low power clocksource found in the LPC" if COMPILE_TEST
> select TIMER_OF if OF
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index dd91381..372bf4e 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -71,6 +71,7 @@ obj-$(CONFIG_CLKSRC_MIPS_GIC) +=
> mips-gic-timer.o
> obj-$(CONFIG_CLKSRC_TANGO_XTAL) += tango_xtal.o
> obj-$(CONFIG_CLKSRC_IMX_GPT) += timer-imx-gpt.o
> obj-$(CONFIG_CLKSRC_IMX_TPM) += timer-imx-tpm.o
> +obj-$(CONFIG_CLKSRC_IMX_SYS_CTR) += timer-imx-sysctr.o
> obj-$(CONFIG_ASM9260_TIMER) += asm9260_timer.o
> obj-$(CONFIG_H8300_TMR8) += h8300_timer8.o
> obj-$(CONFIG_H8300_TMR16)+= h8300_timer16.o
> diff --git a/drivers/clocksource/timer-imx-sysctr.c
> b/drivers/clocksource/timer-imx-sysctr.c
> new file mode 100644
> index 000..ad3c27f
> --- /dev/null
> +++ b/drivers/clocksource/timer-imx-sysctr.c
> @@ -0,0 +1,204 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +//
> +// Copyright 2017-2018 NXP
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define CNTCV_LO 0x8
> +#define CNTCV_HI 0xc
> +#define CMPCV_LO 0x20
> +#define CMPCV_HI 0x24
> +#define CMPCR0x2c
> +
> +#define SYS_CTR_EN 0x1
> +#define SYS_CTR_IRQ_MASK 0x2
> +
> +static void __iomem *sys_ctr_rd_base;
> +static void __iomem *sys_ctr_cmp_base;
> +static struct clock_event_device clockevent_sysctr;
> +
> +static inline void sysctr_timer_enable(bool enable) {
> + u32 val;
> +
> + val = readl(sys_ctr_cmp_base + CMPCR);
> + val &= ~SYS_CTR_EN;
> + if (enable)
> + val |= SYS_CTR_EN;
> +
> + writel(val, sys_ctr_cmp_base + CMPCR); }
> +
> +static void sysctr_irq_acknowledge(void) {
> + u32 val;
> +
> + /* clear th enable bit(EN=0) to clear the ISTAT */
> + val = readl(sys_ctr_cmp_base + CMPCR);
> + val &= ~SYS_CTR_EN;
> + writel(val, sys_ctr_cmp_base + CMPCR); }
> +
> +static inline u64 sysctr_read_counter(void) {
> + u32 cnt_hi, tmp_hi, cnt_lo;
> +
> + do {
> + cnt_hi = readl_relaxed(sys_ctr_rd_base + CNTCV_HI);
> + cnt_lo = readl_relaxed(sys_ctr_rd_base + CNTCV_LO);
> + tmp_hi = readl_relaxed(sys_ctr_rd_base + CNTCV_HI);
> + } while (tmp_hi != cnt_hi);
> +
> + return ((u64) cnt_hi << 32) | cnt_lo; }
> +
> +static u64 notrace sysctr_read_sched_clock(void) {
> + return sysctr_read_counter();
> +}
> +
> +static u64 sysctr_clocksource_read(struct clocksource *cs) {
> + return sysctr_read_counter();
> +}
> +
> +static int __init sysctr_clocksource_init(unsigned int rate) {
> + sched_clock_register(sysctr_read_sched_clock, 56, rate);
> + return clocksource_mmio_init(sys_ctr_rd_base, "i.MX sys_ctr",
> + rate, 200, 56, sysctr_clocksource_read); }
> +
> +static int sysctr_set_next_event(unsigned long delta,
> + struct clock_event_device *evt)
> +{
> + u32 cmp_hi, cmp_lo;
> + u64 next;
> +
> +
[PATCH v8 0/8] Introduce the for_each_set_clump8 macro
Changes in v8: - Return unsigned long for bitmap_get_value8 for consistency - Add clobbering risk warning to bitmap_set_value8 documentation - Reimplement bitmap_get_value8 and bitmap_set_value8 to account for clumps that fall across bitmap word boundaries - Add a bitmap size argument to the bitmap_get_value8 and bitmap_set_value8 functions While adding GPIO get_multiple/set_multiple callback support for various drivers, I noticed a pattern of looping manifesting that would be useful standardized as a macro. This patchset introduces the for_each_set_clump8 macro and utilizes it in several GPIO drivers. The for_each_set_clump macro8 facilitates a for-loop syntax that iterates over a memory region entire groups of set bits at a time. For example, suppose you would like to iterate over a 32-bit integer 8 bits at a time, skipping over 8-bit groups with no set bit, where represents the current 8-bit group: Example:1010 00110011 First loop: 1010 Second loop:1010 00110011 Third loop: 00110011 Each iteration of the loop returns the next 8-bit group that has at least one set bit. The for_each_set_clump8 macro has four parameters: * start: set to the bit offset of the current clump * clump: set to the current clump value * bits: bitmap to search within * size: bitmap size in number of bits In this version of the patchset, the for_each_set_clump macro has been reimplemented and simplified based on the suggestions provided by Rasmus Villemoes and Andy Shevchenko in the version 4 submission. In particular, the function of the for_each_set_clump macro has been restricted to handle only 8-bit clumps; the drivers that use the for_each_set_clump macro only handle 8-bit ports so a generic for_each_set_clump implementation is not necessary. Thus, a solution for large clumps (i.e. those larger than the width of a bitmap word) can be postponed until a driver appears that actually requires such a generic for_each_set_clump implementation. For what it's worth, a semi-generic for_each_set_clump (i.e. for clumps smaller than the width of a bitmap word) can be implemented by simply replacing the hardcoded '8' and '0xFF' instances with respective variables. I have not yet had a need for such an implementation, and since it falls short of a true generic for_each_set_clump function, I have decided to forgo such an implementation for now. In addition, the bitmap_get_value8 and bitmap_set_value8 functions are introduced to get and set 8-bit values respectively. Their use is based on the behavior suggested in the patchset version 4 review. William Breathitt Gray (8): bitops: Introduce the for_each_set_clump8 macro lib/test_bitmap.c: Add for_each_set_clump8 test cases gpio: 104-dio-48e: Utilize for_each_set_clump8 macro gpio: 104-idi-48: Utilize for_each_set_clump8 macro gpio: gpio-mm: Utilize for_each_set_clump8 macro gpio: ws16c48: Utilize for_each_set_clump8 macro gpio: pci-idio-16: Utilize for_each_set_clump8 macro gpio: pcie-idio-24: Utilize for_each_set_clump8 macro drivers/gpio/gpio-104-dio-48e.c | 73 ++-- drivers/gpio/gpio-104-idi-48.c| 37 +++--- drivers/gpio/gpio-gpio-mm.c | 73 ++-- drivers/gpio/gpio-pci-idio-16.c | 75 drivers/gpio/gpio-pcie-idio-24.c | 111 +++--- drivers/gpio/gpio-ws16c48.c | 72 ++- include/asm-generic/bitops/find.h | 14 include/linux/bitops.h| 5 ++ lib/find_bit.c| 81 ++ lib/test_bitmap.c | 65 + 10 files changed, 307 insertions(+), 299 deletions(-) -- 2.20.1
Re: [PATCH v1] clk: qcom: lpass: Add CLK_IGNORE_UNUSED for lpass clocks
On 1/8/2019 2:34 AM, Stephen Boyd wrote: Quoting Taniya Das (2019-01-06 22:26:00) Hello Stephen, On 12/21/2018 2:34 AM, Stephen Boyd wrote: Quoting Taniya Das (2018-12-20 03:46:25) The LPASS clocks has a dependency on the GCC lpass clocks to be enabled before accessing them and that was the reason to mark the gcc lpass clocks as critical. But in the case where the lpass subsystem would require a restart, toggling the lpass reset would from HW clear the SW enable bits of the GCC lpass clocks. Thus the next time bringing up the lpass subsystem out of reset would fail. Allow the lpass clock driver to enable/disable the gcc lpass clocks and mark the lpass clocks not be accessed during late_init if no client vote. You need to add more details here. It feels like you wrote the beginning of a paragraph and then stopped abruptly, leaving the reader hanging for the whole story. Why is late_init important? Why do we need to leave them on from the bootloader? What if the bootloader doesn't leave them enabled? This is all rather hacky so I'm deeply confused. Does the lpass driver need to get these gcc clks and enable/prepare them during probe? But then it needs to also allow a reset happen and change the clk state? I suspect this situation is circling a larger problem where a reset is toggled and that changes some clk state without the clk framework knowing. There's not much we can do about that besides having some mechanism for the clks to know that their state is now out of sync. If that can be done on the provider driver side then we should have an easier time not needing to write a bunch of framework code to handle this. OMAP folks are dealing with the same problems from what I recall. Hmm, if I mark the CLK_IS_CRITICAL, I don't see a way to handle it in provider. Please suggest if you think provider could handle it. As far as I know, I'm not suggesting the use of CLK_IS_CRITICAL here. But removing CLK_IS_CRITICAL and relying on some random bootloader behavior also looks wrong. Can you clarify what's going on? To enable LPASS clocks the requirement is to enable the GCC_LPASS_SWAY clock. 1) If the LPASS drivers are enabled/probed before the clock late init the client would take care to maintain the dependency to enable the GCC_LPASS_SWAY clock before enabling the LPASS clocks. 2) There could be a condition where the LPASS drivers would probe/init later the clock late_init. When the clock_late_init would try to access the LPASS clocks, since we cannot maintain the dependency this access would fail. To avoid this the earlier patch has made the GCC_LPASS_SWAY clock as CRITICAL. 3) Marking the GCC_LPASS_SWAY clock as CRITICAL has a issue, in the case where the LPASS subsystem would be restarted due to some critical failure on LPASS. Toggling the restart register of LPASS would clear the hardware state of this clock and thus the next access of the LPASS clocks would result in failure of the system. 4) To avoid issues happening in (2) and (3) all the LPASS clocks chould be safely marked as CLK_IGNORE_UNUSED. And lpass drivers would take care of the dependency to enable the required clocks. Hope the above helps. -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation. --
[PATCH] docs: Bump version to 5.x
This shows up in the index of https://www.kernel.org/doc/html/latest/ so
I figured it should be updated.
Fixes: bfeffd15528 ("Linux 5.0-rc1")
Signed-off-by: Joel Stanley
--
We could also remove the version number instead of applying this patch.
---
Documentation/admin-guide/README.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/README.rst
b/Documentation/admin-guide/README.rst
index 0797eec76be1..a09baa324951 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -1,9 +1,9 @@
.. _readme:
-Linux kernel release 4.x
Re: [PATCH v1 7/7] arm64: dts: sdm845: wireup the thermal trip points to cpufreq
On 11-01-19, 11:58, Matthias Kaehlcke wrote:
> On Fri, Jan 11, 2019 at 09:16:53AM +0530, Viresh Kumar wrote:
> Just to gain a better understanding: is cpuidle cooling already
> available for arm64 (or is there a patch set)? I came across the
> relatively new idle injecting framework but it seems currently the
> only user is the Intel powerclamp driver.
Daniel was trying to upstream it earlier:
lore.kernel.org/lkml/1522945005-7165-7-git-send-email-daniel.lezc...@linaro.org
> > > even though only one will be active at any given
> > > time. However I wonder if we could change this:
> >
> > I won't say it that way. I see it as all the CPUs are active during a
> > cooling state, i.e. they are all participating.
>
> agreed, I was referring to the CPU cooling device, which (without
> cpuidle injection) could be considered a single device per freq domain.
Even without cpuidle injection all CPUs actually take part in cooling.
> > > For device tree based platform the above implies that cooling maps
> > > must include a list of all possible cooling devices of a frequency
> > > domain, even though only one of them will exist at any given time.
> > >
> > > For example:
> > >
> > > cooling-maps {
> > > map0 {
> > > trip = <_alert0>;
> > > cooling-device = < THERMAL_NO_LIMIT 4>,
> > >< THERMAL_NO_LIMIT 4>,
> > >< THERMAL_NO_LIMIT 4>,
> > >< THERMAL_NO_LIMIT 4>;
> > > };
> > > map1 {
> > > trip = <_crit0>;
> > > cooling-device = < THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > >< THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > >< THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > >< THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> >
> > This is the right thing to do hardware description wise, no matter
> > what the kernel does.
>
> Not sure I would call it a hardware description. I'd say we pretend
> the thermal configuration is a hardware description so the DT folks
> don't yell at us ;-) IMO a CPU cooling device is an abstraction, I
> think there is no such IP block on most systems.
Right.
> It seems with cpuidle injection CPUs can perform cooling actions
> individually, with that I agree that representing them as individual
> cooling devices in the DT makes sense. Without that a cooling device
> per freq domain would seem a resonable abstraction.
But we actually have 4 different cooling devices no matter what. The only thing
is that they switch their cooling state together. And that shouldn't bother DT
is what I thought :)
> One of the reasons I dislike the above list of cooling devices is that
> it is repeated for different thermal-zone/cooling-maps, but I guess
> we have to live with that, would be nice if the DT would allow to do
> something like this:
>
> thermal-zones {
> cooling_maps_fd0 : cooling-maps {
> map0 {
> trip = <_alert0>;
> cooling-device = < THERMAL_NO_LIMIT 4>,
>< THERMAL_NO_LIMIT 4>,
>< THERMAL_NO_LIMIT 4>,
>< THERMAL_NO_LIMIT 4>;
> };
> map1 {
> trip = <_crit0>;
> cooling-device = < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
>< THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
>< THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
>< THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> };
>
> cpu0-thermal {
> ...
> cooling-maps = @cooling_maps_fd0;
> ...
> };
>
> cpu1-thermal {
> ...
> cooling-maps = @cooling_maps_fd0;
> ...
> };
>
> ...
> };
Yeah, maybe. There aren't lot of examples of such duplication though if I
remember correctly.
--
viresh
Re: [PATCH 2/3] sysrq: Remove duplicated sysrq message
On (01/11/19 17:20), Petr Mladek wrote:
> The commit 97f5f0cd8cd0a0544 ("Input: implement SysRq as a separate input
> handler") added pr_fmt() definition. It caused a duplicated message
> prefix in the sysrq header messages, for example:
>
> [ 177.053931] sysrq: SysRq : Show backtrace of all active CPUs
> [ 742.864776] sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c)
>
> Fixes: 97f5f0cd8cd0a05 ("Input: implement SysRq as a separate input handler")
> Signed-off-by: Petr Mladek
Reviewed-by: Sergey Senozhatsky
A side note:
> - pr_cont("This sysrq operation is disabled.\n");
> + pr_info("This sysrq operation is disabled.\n");
I wouldn't mind this messages to become more informative.
+ pr_info("sysrq 0x%x operation is disabled.\n", key);
?
A bunch of "This sysrq operation is disabled" in serial0 log file
(post mortem) is not very helpful.
-ss
Re: [PATCH v10 05/12] ARM: dts: aspeed: peci: Add PECI node
Hi Jae, On Tue, 8 Jan 2019 at 08:11, Jae Hyun Yoo wrote: > > This commit adds PECI bus/adapter node of AST24xx/AST25xx into > aspeed-g4 and aspeed-g5. This looks good, aside from the alias. It will go via my aspeed tree once the bindings are merged. Send them to linux-asp...@lists.ozlabs.org at that time. In the future I suggest leaving the changes to arch/arm/boot/dts until after the bindings and driver patches have landed. They will rarely go in before hand as the bindings need to be agreed on. > serial3 = > serial4 = > serial5 = > + peci0 = I don't think this is necessary. Can you explain why you think you need it? Cheers, Joel
Re: linux-next: manual merge of the scsi tree with Linus' tree
Thanks Stephen's help.
Ching Huang
Stephen Rothwell 於 2019年1月14日 週一 上午10:48寫道：
>
> Hi all,
>
> Today's linux-next merge of the scsi tree got a conflict in:
>
> drivers/scsi/arcmsr/arcmsr_hba.c
>
> between commit:
>
> 750afb08ca71 ("cross-tree: phase out dma_zalloc_coherent()")
>
> from Linus' tree and commit:
>
> 381d66da7212 ("scsi: arcmsr: Rename acb structure member roundup_ccbsize to
> ioqueue_size")
>
> from the scsi tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/scsi/arcmsr/arcmsr_hba.c
> index 57c6fa388bf6,9f85d5abbb0c..
> --- a/drivers/scsi/arcmsr/arcmsr_hba.c
> +++ b/drivers/scsi/arcmsr/arcmsr_hba.c
> @@@ -585,12 -641,9 +641,11 @@@ static bool arcmsr_alloc_io_queue(struc
>
> switch (acb->adapter_type) {
> case ACB_ADAPTER_TYPE_B: {
> - struct MessageUnit_B *reg;
> - acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_B),
> 32);
> + acb->ioqueue_size = roundup(sizeof(struct MessageUnit_B), 32);
> - dma_coherent = dma_zalloc_coherent(>dev,
> acb->ioqueue_size,
> - _coherent_handle, GFP_KERNEL);
> + dma_coherent = dma_alloc_coherent(>dev,
> - acb->roundup_ccbsize,
> ++acb->ioqueue_size,
> +_coherent_handle,
> +GFP_KERNEL);
> if (!dma_coherent) {
> pr_notice("arcmsr%d: DMA allocation failed\n",
> acb->host->host_no);
> return false;
> @@@ -616,13 -655,9 +657,11 @@@
> }
> break;
> case ACB_ADAPTER_TYPE_D: {
> - struct MessageUnit_D *reg;
> -
> - acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_D),
> 32);
> + acb->ioqueue_size = roundup(sizeof(struct MessageUnit_D), 32);
> - dma_coherent = dma_zalloc_coherent(>dev,
> acb->ioqueue_size,
> - _coherent_handle, GFP_KERNEL);
> + dma_coherent = dma_alloc_coherent(>dev,
> - acb->roundup_ccbsize,
> ++acb->ioqueue_size,
> +_coherent_handle,
> +GFP_KERNEL);
> if (!dma_coherent) {
> pr_notice("arcmsr%d: DMA allocation failed\n",
> acb->host->host_no);
> return false;
> @@@ -662,11 -671,9 +675,11 @@@
> case ACB_ADAPTER_TYPE_E: {
> uint32_t completeQ_size;
> completeQ_size = sizeof(struct deliver_completeQ) *
> ARCMSR_MAX_HBE_DONEQUEUE + 128;
> - acb->roundup_ccbsize = roundup(completeQ_size, 32);
> + acb->ioqueue_size = roundup(completeQ_size, 32);
> - dma_coherent = dma_zalloc_coherent(>dev,
> acb->ioqueue_size,
> - _coherent_handle, GFP_KERNEL);
> + dma_coherent = dma_alloc_coherent(>dev,
> - acb->roundup_ccbsize,
> ++acb->ioqueue_size,
> +_coherent_handle,
> +GFP_KERNEL);
> if (!dma_coherent){
> pr_notice("arcmsr%d: DMA allocation failed\n",
> acb->host->host_no);
> return false;
Re: [PATCH] sysrq: Restore original console_loglevel when sysrq disabled
On (01/11/19 16:32), Petr Mladek wrote: > The same problem is with the sysrq header line. It uses the trick > with console_loglevel by intention. We want to show it but > it is not really an error message May be. I usually see it as an "error". My case: systemd sets sysrq on every boot to /lib/sysctl.d/50-default.conf kernel.sysrq value, which I usually set to 1. But after every systemd package update I have to edit 50-default.conf again, because somebody concluded that overwriting /lib/sysctl.d/50-default.conf during package update was the right thing to do. So, occasionally, when I need to do sysrq all I get is "This sysrq operation is disabled" error. So I swear a lot, reboot the box, change the sysrq mask and try to reproduce the problem. /* I became familiar with "sysrq_always_enabled=1" just recently. */ "This sysrq operation is disabled" is always bad news and is always not what I want to see. -ss
Re: [PATCH resend] w1: add missing kernel-doc entry for of_match_table
ping?
also adding Mr. Corbet.
On 11/1/18 4:41 PM, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix kernel-doc warning for missing struct member description:
>
> ../include/linux/w1.h:281: warning: Function parameter or member
> 'of_match_table' not described in 'w1_family'
>
> Signed-off-by: Randy Dunlap
> Cc: Evgeniy Polyakov
> ---
> include/linux/w1.h |1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20181101.orig/include/linux/w1.h
> +++ linux-next-20181101/include/linux/w1.h
> @@ -266,6 +266,7 @@ struct w1_family_ops {
> * @family_entry:family linked list
> * @fid: 8 bit family identifier
> * @fops:operations for this family
> + * @of_match_table: Open Firmware device matching table
> * @refcnt: reference counter
> */
> struct w1_family {
>
>
>
--
~Randy
Re: [PATCH v10 01/12] dt-bindings: Add a document of PECI subsystem
On Tue, 8 Jan 2019 at 08:11, Jae Hyun Yoo wrote: > > This commit adds a document of generic PECI bus, adapter and client > driver. > > Cc: Rob Herring > Cc: Mark Rutland > Cc: Andrew Jeffery > Cc: Joel Stanley > Signed-off-by: Jae Hyun Yoo > Reviewed-by: Haiyue Wang > Reviewed-by: James Feist > Reviewed-by: Vernon Mauery > Reviewed-by: Rob Herring Reviewed-by: Joel Stanley
Re: [PATCH v5 2/8] iommu/vt-d: Add per-device IOMMU feature ops entries
Hi Joerg,
Thanks for reviewing my patch.
On 1/11/19 7:16 PM, Joerg Roedel wrote:
Hi,
this looks a bit confusing to me because I can see no checking whether
the device actually supports scalable mode.
Yes. I should put some checking there. Device scalable mode capability
is exposed in PCI extended capability list.
More below:
On Thu, Jan 10, 2019 at 11:00:21AM +0800, Lu Baolu wrote:
+static int intel_iommu_enable_auxd(struct device *dev)
+{
+ struct device_domain_info *info;
+ struct dmar_domain *domain;
+ unsigned long flags;
+
+ if (!scalable_mode_support())
+ return -ENODEV;
+
+ domain = get_valid_domain_for_dev(dev);
+ if (!domain)
+ return -ENODEV;
+
+ spin_lock_irqsave(_domain_lock, flags);
+ info = dev->archdata.iommu;
+ info->auxd_enabled = 1;
+ spin_unlock_irqrestore(_domain_lock, flags);
+
+ return 0;
+}
This code sets a flag to mark scalable mode enabled. Doesn't the device
need some handling too, like enabling the PASID capability and all?
Yes. My design was rough. We should prepare the device for scalable mode
instead of assuming that everything is ready.
+
+static bool
+intel_iommu_dev_has_feat(struct device *dev, enum iommu_dev_features feat)
+{
+ struct device_domain_info *info = dev->archdata.iommu;
+
+ if (feat == IOMMU_DEV_FEAT_AUX)
+ return scalable_mode_support() && info && info->auxd_enabled;
+
+ return false;
+}
Why is this checking the auxd_enabled flag?
We need an API to check whether this feature is enabled. In vfio, it
is used like below,
if (iommu_dev_has_feat(dev, FEAT_AUX_DOMAIN))
iommu_aux_attach_device(dev, domain)
else
iommu_attach_device(dev, domain)
The function should just
return whether the device _supports_ scalable mode, not whether it is
enabled.
Do we want to have an API to tell whether device has aux-domain feature?
It could be included in the enable API. The enable API returns failure
if device doesn't support aux-domain.
Regards,
Joerg
Best regards,
Lu Baolu
Re: [PATCH 1/2 v6] kdump: add the vmcoreinfo documentation
在 2019年01月11日 22:56, Borislav Petkov 写道: > On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote: >> This document lists some variables that export to vmcoreinfo, and briefly >> describles what these variables indicate. It should be instructive for >> many people who do not know the vmcoreinfo. >> >> Suggested-by: Borislav Petkov >> Signed-off-by: Lianbo Jiang >> --- >> Documentation/kdump/vmcoreinfo.txt | 500 + >> 1 file changed, 500 insertions(+) >> create mode 100644 Documentation/kdump/vmcoreinfo.txt > > Ok, below is what I'm going to commit if no one complains. I hope you'd > find some time to work on adding the checkpatch check for patches which > add vmcoreinfo members but do not document them I noticed that the checkpatch was coded in Perl. But i am not familiar with the Perl program language, that would be beyond my ability to do this, i have to learn the Perl program language step by step. :-) > and also remove those vmcoreinfo members which are unused. > Do you mean this one 'KERNEL_IMAGE_SIZE'? Currently unused by Makedumpfile, but used to compute the module virtual address by Crash. I have corrected this issue in VMCOREINFO doc. Thanks. Lianbo > Which should be easy because we don't have to be backwards-compatible > with makedumpfile as this is not an ABI. > > Thx. > > --- > From: Lianbo Jiang > Date: Thu, 10 Jan 2019 20:19:43 +0800 > Subject: [PATCH] kdump: Document kernel data exported in the vmcoreinfo note > > Document data exported in vmcoreinfo and briefly describe its use by > userspace tools.a > > [ bp: heavily massage and redact the text. ] > > Suggested-by: Borislav Petkov > Signed-off-by: Lianbo Jiang > Signed-off-by: Borislav Petkov > Cc: Andrew Morton > Cc: Baoquan He > Cc: Dave Young > Cc: Jonathan Corbet > Cc: Thomas Gleixner > Cc: Vivek Goyal > Cc: ander...@redhat.com > Cc: k-ha...@ab.jp.nec.com > Cc: ke...@lists.infradead.org > Cc: linux-...@vger.kernel.org > Cc: mi...@redhat.com > Cc: x86-ml > Link: https://lkml.kernel.org/r/20190110121944.6050-2-liji...@redhat.com > --- > Documentation/kdump/vmcoreinfo.txt | 494 + > 1 file changed, 494 insertions(+) > create mode 100644 Documentation/kdump/vmcoreinfo.txt > > diff --git a/Documentation/kdump/vmcoreinfo.txt > b/Documentation/kdump/vmcoreinfo.txt > new file mode 100644 > index ..2dc3797940a3 > --- /dev/null > +++ b/Documentation/kdump/vmcoreinfo.txt > @@ -0,0 +1,494 @@ > + > + VMCOREINFO > + > + > +=== > +What is it? > +=== > + > +VMCOREINFO is a special ELF note section. It contains various > +information from the kernel like structure size, page size, symbol > +values, field offsets, etc. These data are packed into an ELF note > +section and used by user-space tools like crash and makedumpfile to > +analyze a kernel's memory layout. > + > + > +Common variables > + > + > +init_uts_ns.name.release > + > + > +The version of the Linux kernel. Used to find the corresponding source > +code from which the kernel has been built. > + > +PAGE_SIZE > +- > + > +The size of a page. It is the smallest unit of data used by the memory > +management facilities. It is usually 4096 bytes of size and a page is > +aligned on 4096 bytes. Used for computing page addresses. > + > +init_uts_ns > +--- > + > +The UTS namespace which is used to isolate two specific elements of the > +system that relate to the uname(2) system call. It is named after the > +data structure used to store information returned by the uname(2) system > +call. > + > +User-space tools can get the kernel name, host name, kernel release > +number, kernel version, architecture name and OS type from it. > + > +node_online_map > +--- > + > +An array node_states[N_ONLINE] which represents the set of online nodes > +in a system, one bit position per node number. Used to keep track of > +which nodes are in the system and online. > + > +swapper_pg_dir > +- > + > +The global page directory pointer of the kernel. Used to translate > +virtual to physical addresses. > + > +_stext > +-- > + > +Defines the beginning of the text section. In general, _stext indicates > +the kernel start address. Used to convert a virtual address from the > +direct kernel map to a physical address. > + > +vmap_area_list > +-- > + > +Stores the virtual area list. makedumpfile gets the vmalloc start value > +from this variable and its value is necessary for vmalloc translation. > + > +mem_map > +--- > + > +Physical addresses are translated to struct pages by treating them as > +an index into the mem_map array. Right-shifting a physical address > +PAGE_SHIFT bits converts it into a page frame number which is an index > +into that
[PATCH] soc: fsl: dpio: fix cpu range check
cpu_possible(cpu) will always return true when cpu parameter
is from cpumask_next().
Check for nr_cpu_ids rather than !cpu_possible(cpu).
Signed-off-by: Bharat Bhushan
---
drivers/soc/fsl/dpio/dpio-driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/dpio/dpio-driver.c
b/drivers/soc/fsl/dpio/dpio-driver.c
index e58fcc9096e8..eb369dd9e0a7 100644
--- a/drivers/soc/fsl/dpio/dpio-driver.c
+++ b/drivers/soc/fsl/dpio/dpio-driver.c
@@ -133,7 +133,7 @@ static int dpaa2_dpio_probe(struct fsl_mc_device *dpio_dev)
else
next_cpu = cpumask_next(next_cpu, cpu_online_mask);
- if (!cpu_possible(next_cpu)) {
+ if (next_cpu >= nr_cpu_ids) {
dev_err(dev, "probe failed. Number of DPIOs exceeds
NR_CPUS.\n");
err = -ERANGE;
goto err_allocate_irqs;
--
2.20.1
[PATCH v1 1/3] dt-bindings: mtd: mtk-quadspi: update bindings for MT7629 SoC
This updates bindings for the MT7629 SPI-NOR controller. Signed-off-by: Ryder Lee Reviewed-by: Rob Herring --- Changes since v1: add a Reviewed-by tag. --- Documentation/devicetree/bindings/mtd/mtk-quadspi.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt index 56d3668..a12e3b5 100644 --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt @@ -1,4 +1,4 @@ -* Serial NOR flash controller for MTK MT81xx (and similar) +* Serial NOR flash controller for MediaTek SoCs Required properties: - compatible:For mt8173, compatible should be "mediatek,mt8173-nor", @@ -10,6 +10,7 @@ Required properties: "mediatek,mt2712-nor", "mediatek,mt8173-nor" "mediatek,mt7622-nor", "mediatek,mt8173-nor" "mediatek,mt7623-nor", "mediatek,mt8173-nor" + "mediatek,mt7629-nor", "mediatek,mt8173-nor" "mediatek,mt8173-nor" - reg: physical base address and length of the controller's register - clocks:the phandle of the clocks needed by the nor controller -- 1.9.1
[PATCH v1 2/3] mtd: spi-nor: mtk-quadspi: add SNOR_HWCAPS_READ for capcity setting
From: Guochun Mao
SNOR_HWCAPS_READ is a basic read mode for both flash and controller,
it should be supported, so add the capcity for mtk-quadspi.
Signed-off-by: Guochun Mao
---
Changes since v1: none.
---
drivers/mtd/spi-nor/mtk-quadspi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index 5442993..d9eed68 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -431,7 +431,8 @@ static int mtk_nor_init(struct mtk_nor *mtk_nor,
struct device_node *flash_node)
{
const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ_FAST |
+ .mask = SNOR_HWCAPS_READ |
+ SNOR_HWCAPS_READ_FAST |
SNOR_HWCAPS_READ_1_1_2 |
SNOR_HWCAPS_PP,
};
--
1.9.1
[PATCH v1 3/3] mtd: spi-nor: mtk-quadspi: rename config to a common one
The quadspi is a generic communication interface which could be shared with other MediaTek SoCs. Hence rename it to a common one. Signed-off-by: Ryder Lee --- Changes since v1: rebase to v5.0-rc1. --- drivers/mtd/spi-nor/Kconfig | 16 drivers/mtd/spi-nor/Makefile | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index b433e5f..99d9d53 100644 --- a/drivers/mtd/spi-nor/Kconfig +++ b/drivers/mtd/spi-nor/Kconfig @@ -7,14 +7,6 @@ menuconfig MTD_SPI_NOR if MTD_SPI_NOR -config MTD_MT81xx_NOR - tristate "Mediatek MT81xx SPI NOR flash controller" - depends on HAS_IOMEM - help - This enables access to SPI NOR flash, using MT81xx SPI NOR flash - controller. This controller does not support generic SPI BUS, it only - supports SPI NOR Flash. - config MTD_SPI_NOR_USE_4K_SECTORS bool "Use small 4096 B erase sectors" default y @@ -68,6 +60,14 @@ config SPI_NXP_SPIFI Flash. Enable this option if you have a device with a SPIFI controller and want to access the Flash as a mtd device. +config SPI_MTK_QUADSPI + tristate "MediaTek Quad SPI controller" + depends on HAS_IOMEM + help + This enables support for the Quad SPI controller in master mode. + This controller does not support generic SPI. It only supports + SPI NOR. + config SPI_INTEL_SPI tristate diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile index 2adedbe..189a15c 100644 --- a/drivers/mtd/spi-nor/Makefile +++ b/drivers/mtd/spi-nor/Makefile @@ -3,7 +3,7 @@ obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o -obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o +obj-$(CONFIG_SPI_MTK_QUADSPI)+= mtk-quadspi.o obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o obj-$(CONFIG_SPI_INTEL_SPI)+= intel-spi.o obj-$(CONFIG_SPI_INTEL_SPI_PCI)+= intel-spi-pci.o -- 1.9.1
Re: [PATCH v5 4/6] usb: gadget: add mechanism to specify an explicit status stage
On Fri, Jan 11, 2019 at 10:50:11AM -0500, Alan Stern wrote: > On Fri, 11 Jan 2019, Paul Elder wrote: > > > On Wed, Jan 09, 2019 at 02:06:31PM -0500, Alan Stern wrote: > > > On Wed, 9 Jan 2019, Paul Elder wrote: > > > > > > > A usb gadget function driver may or may not want to delay the status > > > > stage of a control OUT request. An instance where it might want to is to > > > > asynchronously validate the data of a class-specific request. > > > > > > > > A function driver that wants an explicit status stage should set the > > > > newly added explicit_status flag of the usb_request corresponding to the > > > > data stage. Later on, the function driver can explicitly complete the > > > > status stage by enqueueing a usb_request for ACK, or calling > > > > usb_ep_set_halt() for STALL. > > > > > > > > To support both explicit and implicit status stages, a UDC driver must > > > > call the newly added usb_gadget_control_complete function right before > > > > calling usb_gadget_giveback_request. To support the explicit status > > > > stage, it might then check what stage the usb_request was queued in, and > > > > for control IN ACK the host's zero-length data packet, or for control > > > > OUT send a zero-length DATA1 ACK packet. > > > > > > > > Signed-off-by: Paul Elder > > > > v4 Acked-by: Alan Stern > > > > v1 Reviewed-by: Laurent Pinchart > > > > > > This looks good and has passed my tests so far. > > > > Good! Thank you :) > > > > > Can you check your uvc > > > changes using dummy_hcd with the patch below? > > > > I'm not sure what to make of the test results. I get the same results > > with or without the patch. Which I guess makes sense... in dummy_queue, > > this is getting hit when the uvc function driver tries to complete the > > delayed status: > > > > req = usb_request_to_dummy_request(_req); > > if (!_req || !list_empty(>queue) || !_req->complete) > > return -EINVAL; > > > > So the delayed/explicit status stage is never completed, afaict. > > I presume you are hitting the !list_empty(>queue) test, yes? The > other two tests are trivial. Yes, that is what's happening. > Triggering the !list_empty() test means the request has already been > submitted and not yet completed. This probably indicates there is a > bug in the uvc function driver code. The uvc function driver works with musb, though :/ I compared the sequence of calls to the uvc setup, completion handler, and status stage sending, and for some reason dummy_hcd, after an OUT setup-completion-status sequence, calls a completion-status-completion sequence, and then goes on the the next request. musb simply goes on to the next request after the setup-completion-status sequence. I commented out the paranoia block in dummy_timer, and dummy_hcd still does the extra completion, but it doesn't error out anymore. I doubt that's the/a solution though, especially since I get: [ 22.616577] uvcvideo: Failed to query (129) UVC probe control : -75 (exp. 26). [ 22.624481] uvcvideo: Failed to initialize the device (-5). Not sure if that's a result of dummy_hcd not supporting isochronous transfers or not. I'm not sure where to continue investigating :/ Thanks, Paul
linux-next: Tree for Jan 14
Hi all, Changes since 20190111: The vfs tree still had its build failure for which I applied a patch. It also gained conflicts against the vfs-fixes tree. The mali-dp tree gained a build failure so I used the version from next-20190111. The scsi tree gained conflicts against Linus' and the scsi-fixes trees. Non-merge commits (relative to Linus' tree): 1685 1763 files changed, 54811 insertions(+), 26906 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 295 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (6b529fb0a3ea Merge tag 'for-5.0-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux) Merging fixes/master (75d4f49b8a3b drm/nouveau/nvkm: mark expected switch fall-throughs) Merging kbuild-current/fixes (84978a55c0dc kbuild: Disable LD_DEAD_CODE_DATA_ELIMINATION with ftrace & GCC <= 4.7) Merging arc-current/for-curr (5fac3149be6f ARC: adjust memblock_reserve of kernel memory) Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential uninitialized return) Merging arm64-fixes/for-next/fixes (279667212ab2 arm64: kexec_file: return successfully even if kaslr-seed doesn't exist) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (bfeffd155283 Linux 5.0-rc1) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (8d008e64a2eb mISDN: hfcsusb: Use struct_size() in kzalloc()) Merging bpf/master (fb4129b9279d Merge branch 'bpf-fix-bitfield-printing') Merging ipsec/master (35e6103861a3 xfrm: refine validation of template and selector families) Merging netfilter/master (a799aea0988e netfilter: nft_flow_offload: Fix reverse route lookup) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (bfeffd155283 Linux 5.0-rc1) Merging mac80211/master (1d51b4b1d3f2 Merge tag 'm68k-for-v4.20-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k) Merging rdma-fixes/for-rc (9d9f59b4204b RDMA/mthca: Clear QP objects during their allocation) Merging sound-current/for-linus (d1dd42110d27 ALSA: hda/realtek - Disable headset Mic VREF for headset mode of ALC225) Merging sound-asoc-fixes/for-linus (d9c51542207a Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (1cd824361eed Merge branch 'regmap-4.21' into regmap-5.0) Merging regulator-fixes/for-linus (0ab66b3c326e regulator: max77620: Initialize values for DT properties) Merging spi-fixes/for-linus (aa54c1c9d90e spi: fix initial SPI_SR value in spi-fsl-dspi) Merging pci-current/for-linus (a3869d43c980 PCI: amlogic: Fix build failure due to missing gpio header) Merging driver-core.current/driver-core-linus (735df0ff6ece Documentation: driver core: remove use of BUS_ATTR) Merging tty.current/tty-linus (d3736d82e816 tty: Don't hold ldisc lock in tty_reopen() if ldisc present) Merging usb.current/usb-linus (b9fcb0e6b705 usb: storage: Remove outdated URL from MAINTAINERS) Merging usb-gadget-fixes/fixes (069caf5950df USB: omap_udc: fix rejection of out transfers when DMA is
Re: [PATCH v11 10/15] tracing: Add alternative synthetic event trace action syntax
Hi Tom, On Fri, Jan 11, 2019 at 10:25:40AM -0600, Tom Zanussi wrote: > Hi Namhyung, > > On Fri, 2019-01-11 at 15:07 +0900, Namhyung Kim wrote: > > On Wed, Jan 09, 2019 at 01:49:17PM -0600, Tom Zanussi wrote: > > > From: Tom Zanussi > > > > > > Add a 'trace(synthetic_event_name, params)' alternative to > > > synthetic_event_name(params). > > > > > > Currently, the syntax used for generating synthetic events is to > > > invoke synthetic_event_name(params) i.e. use the synthetic event > > > name > > > as a function call. > > > > > > Users requested a new form that more explicitly shows that the > > > synthetic event is in effect being traced. In this version, a new > > > 'trace()' keyword is used, and the synthetic event name is passed > > > in > > > as the first argument. > > > > > > Signed-off-by: Tom Zanussi > > > --- > > > Documentation/trace/histogram.rst | 21 > > > kernel/trace/trace.c | 1 + > > > kernel/trace/trace_events_hist.c | 42 > > > +++ > > > 3 files changed, 60 insertions(+), 4 deletions(-) > > > > > > diff --git a/Documentation/trace/histogram.rst > > > b/Documentation/trace/histogram.rst > > > index 79476c906b1a..4939bad1c1cd 100644 > > > --- a/Documentation/trace/histogram.rst > > > +++ b/Documentation/trace/histogram.rst > > > @@ -1874,6 +1874,7 @@ The available handlers are: > > > The available actions are: > > > > > >- (param list) - generate > > > synthetic event > > > + - trace(,(param list)) - generate > > > synthetic event > > > > Shouldn't it be > > > > "trace(,param list)" > > > > ? Otherwise it looks like we need two parentheses. > > Good point, I'll remove the params. > > > > > IMHO, it seems better for consistency using this new syntax only. > > Of course it should support the old syntax as well for compatibility > > (and maybe make it undocumented?). But I won't insist strongly.. > > > > OK, yeah, I really hate when things are undocumented, so I think > removing the documentation would be a step backward, but maybe changing > the emphasis to the trace() form would suffice. How about the below?: Looks good to me! Thanks, Namhyung > > > diff --git a/Documentation/trace/histogram.rst > b/Documentation/trace/histogram.rst > index e5bcef360997..0ea59d45aef1 100644 > --- a/Documentation/trace/histogram.rst > +++ b/Documentation/trace/histogram.rst > @@ -1873,46 +1873,45 @@ The available handlers are: > > The available actions are: > > - - (param list) - generate synthetic event >- trace(,param list) - generate synthetic event >- save(field,...)- save current event fields >- snapshot() - snapshot the trace buffer > > The following commonly-used handler.action pairs are available: > > - - onmatch(matching.event).(param list) > - > -or > - >- onmatch(matching.event).trace(,param list) > > -The 'onmatch(matching.event).(params)' hist > -trigger action is invoked whenever an event matches and the > -histogram entry would be added or updated. It causes the named > -synthetic event to be generated with the values given in the > +The 'onmatch(matching.event).trace(,param > +list)' hist trigger action is invoked whenever an event matches > +and the histogram entry would be added or updated. It causes the > +named synthetic event to be generated with the values given in the > 'param list'. The result is the generation of a synthetic event > that consists of the values contained in those variables at the > -time the invoking event was hit. > - > -There are two equivalent forms available for generating synthetic > -events. In the first form, the synthetic event name is used as if > -it were a function name. For example, if the synthetic event name > -is 'wakeup_latency', the wakeup_latency event would be generated > -by invoking it as if it were a function call, with the event field > -values passed in as arguments: wakeup_latency(arg1,arg2). The > -second form simply uses the 'trace' keyword as the function name > -and passes in the synthetic event name as the first argument, > -followed by the field values: trace(wakeup_latency,arg1,arg2). > - > -The 'param list' consists of one or more parameters which may be > -either variables or fields defined on either the 'matching.event' > -or the target event. The variables or fields specified in the > -param list may be either fully-qualified or unqualified. If a > -variable is specified as unqualified, it must be unique between > -the two events. A field name used as a param can be unqualified > -if it refers to the target event, but must be fully qualified if > -it refers to the matching event. A fully-qualified name is of the > -form 'system.event_name.$var_name' or 'system.event_name.field'. > +
Re: [PATCH v3] scsi/ata: Use unsigned int for cmd's type in ioctls in scsi_host_template
On Sun, Jan 13, 2019 at 08:54:35PM -0800, Bart Van Assche wrote:
> On 1/13/19 8:42 PM, Nathan Chancellor wrote:
> > @@ -1292,7 +1292,7 @@ int esas2r_ioctl_handler(void *hostdata, int cmd,
> > void __user *arg)
> > ioctl = memdup_user(arg, sizeof(struct atto_express_ioctl));
> > if (IS_ERR(ioctl)) {
> > esas2r_log(ESAS2R_LOG_WARN,
> > - "ioctl_handler access_ok failed for cmd %d, "
> > + "ioctl_handler access_ok failed for cmd %u, "
> >"address %p", cmd,
> >arg);
> > return PTR_ERR(ioctl);
>
> If you have to repost this patch, please use that opportunity to join the
> above split strings. Additionally, since this patch touches much more SCSI
Sorry, I should have caught that. If I have to post again, I will fix
that.
> code than ATA code I think it should have been sent to Martin instead of to
> Jens. Anyway:
>
I had Jens, Martin, and James on the 'to' line, with all of the other
maintainers of the individual files on cc. If I should have done it
differently, please let me know.
> Reviewed-by: Bart Van Assche
>
Thank you, I will carry this forward if I need to.
Nathan
Re: [PATCH v3] scsi/ata: Use unsigned int for cmd's type in ioctls in scsi_host_template
On 1/13/19 8:42 PM, Nathan Chancellor wrote:
@@ -1292,7 +1292,7 @@ int esas2r_ioctl_handler(void *hostdata, int cmd, void
__user *arg)
ioctl = memdup_user(arg, sizeof(struct atto_express_ioctl));
if (IS_ERR(ioctl)) {
esas2r_log(ESAS2R_LOG_WARN,
- "ioctl_handler access_ok failed for cmd %d, "
+ "ioctl_handler access_ok failed for cmd %u, "
"address %p", cmd,
arg);
return PTR_ERR(ioctl);
If you have to repost this patch, please use that opportunity to join
the above split strings. Additionally, since this patch touches much
more SCSI code than ATA code I think it should have been sent to Martin
instead of to Jens. Anyway:
Reviewed-by: Bart Van Assche
Re: [PATCH v2] rbtree: fix the red root
On 2019-01-13 10:59 p.m., Esme wrote: ‐‐‐ Original Message ‐‐‐ On Sunday, January 13, 2019 10:52 PM, Douglas Gilbert wrote: On 2019-01-13 10:07 p.m., Esme wrote: ‐‐‐ Original Message ‐‐‐ On Sunday, January 13, 2019 9:33 PM, Qian Cai c...@lca.pw wrote: On 1/13/19 9:20 PM, David Lechner wrote: On 1/11/19 8:58 PM, Michel Lespinasse wrote: On Fri, Jan 11, 2019 at 3:47 PM David Lechner da...@lechnology.com wrote: On 1/11/19 2:58 PM, Qian Cai wrote: A GPF was reported, kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN kasan_die_handler.cold.22+0x11/0x31 notifier_call_chain+0x17b/0x390 atomic_notifier_call_chain+0xa7/0x1b0 notify_die+0x1be/0x2e0 do_general_protection+0x13e/0x330 general_protection+0x1e/0x30 rb_insert_color+0x189/0x1480 create_object+0x785/0xca0 kmemleak_alloc+0x2f/0x50 kmem_cache_alloc+0x1b9/0x3c0 getname_flags+0xdb/0x5d0 getname+0x1e/0x20 do_sys_open+0x3a1/0x7d0 __x64_sys_open+0x7e/0xc0 do_syscall_64+0x1b3/0x820 entry_SYSCALL_64_after_hwframe+0x49/0xbe It turned out, gparent = rb_red_parent(parent); tmp = gparent->rb_right; <-- GPF was triggered here. Apparently, "gparent" is NULL which indicates "parent" is rbtree's root which is red. Otherwise, it will be treated properly a few lines above. /* * If there is a black parent, we are done. * Otherwise, take some corrective action as, * per 4), we don't want a red root or two * consecutive red nodes. */ if(rb_is_black(parent)) break; Hence, it violates the rule #1 (the root can't be red) and need a fix up, and also add a regression test for it. This looks like was introduced by 6d58452dc06 where it no longer always paint the root as black. Fixes: 6d58452dc06 (rbtree: adjust root color in rb_insert_color() only when necessary) Reported-by: Esme espl...@protonmail.ch Tested-by: Joey Pabalinas joeypabali...@gmail.com Signed-off-by: Qian Cai c...@lca.pw Tested-by: David Lechner da...@lechnology.com FWIW, this fixed the following crash for me: Unable to handle kernel NULL pointer dereference at virtual address 0004 Just to clarify, do you have a way to reproduce this crash without the fix ? I am starting to suspect that my crash was caused by some new code in the drm-misc-next tree that might be causing a memory corruption. It threw me off that the stack trace didn't contain anything related to drm. See: https://patchwork.freedesktop.org/patch/276719/ It may be useful for those who could reproduce this issue to turn on those memory corruption debug options to narrow down a bit. CONFIG_DEBUG_PAGEALLOC=y CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y CONFIG_KASAN=y CONFIG_KASAN_GENERIC=y CONFIG_SLUB_DEBUG_ON=y I have been on SLAB, I configured SLAB DEBUG with a fresh pull from github. Linux syzkaller 5.0.0-rc2 #9 SMP Sun Jan 13 21:57:40 EST 2019 x86_64 ... In an effort to get a different stack into the kernel, I felt that nothing works better than fork bomb? :) Let me know if that helps. root@syzkaller:~# gcc -o test3 test3.c root@syzkaller:~# while : ; do ./test3 & done And is test3 the same multi-threaded program that enters the kernel via /dev/sg0 and then calls SCSI_IOCTL_SEND_COMMAND which goes to the SCSI mid-level and thence to the block layer? And please remind me, does it also fail on lk 4.20.2 ? Doug Gilbert Yes, the same C repro from the earlier thread. It was a 4.20.0 kernel where it was first detected. I can move to 4.20.2 and see if that changes anything. Hi, I don't think there is any need to check lk 4.20.2 (as it would be very surprising if it didn't also have this "feature"). More interesting might be: has "test3" been run on lk 4.19 or any earlier kernel? Doug Gilbert
[PATCH v3] scsi/ata: Use unsigned int for cmd's type in ioctls in scsi_host_template
Clang warns several times in the scsi subsystem (trimmed for brevity):
drivers/scsi/hpsa.c:6209:7: warning: overflow converting case value to
switch condition type (2147762695 to 18446744071562347015) [-Wswitch]
case CCISS_GETBUSTYPES:
^
drivers/scsi/hpsa.c:6208:7: warning: overflow converting case value to
switch condition type (2147762694 to 18446744071562347014) [-Wswitch]
case CCISS_GETHEARTBEAT:
^
The root cause is that the _IOC macro can generate really large numbers,
which don't find into type 'int', which is used for the cmd paremeter in
the ioctls in scsi_host_template. My research into how GCC and Clang are
handling this at a low level didn't prove fruitful. However, looking at
the rest of the kernel tree, all ioctls use an 'unsigned int' for the
cmd parameter, which will fit all of the _IOC values in the scsi/ata
subsystems.
Make that change because none of the ioctls expect to take a negative
value, it brings the ioctls inline with the reset of the kernel, and it
removes ambiguity, which is never good when dealing with compilers.
Link: https://github.com/ClangBuiltLinux/linux/issues/85
Link: https://github.com/ClangBuiltLinux/linux/issues/154
Link: https://github.com/ClangBuiltLinux/linux/issues/157
Signed-off-by: Nathan Chancellor
---
v2 -> v3:
* Fix another -Wswitch warning from drivers/scsi/cxlflash/main.c, coming
from decode_hioctl (uncovered via a powernv_defconfig build).
v1 -> v2:
* Fix build breakage in cxlflash driver from forgetting to update
prototype (thanks to 0day for catching it).
I would appreciate some review so I could get this accepted...
drivers/ata/libata-scsi.c | 5 +++--
drivers/scsi/aacraid/aachba.c | 2 +-
drivers/scsi/aacraid/aacraid.h| 4 ++--
drivers/scsi/aacraid/commctrl.c | 2 +-
drivers/scsi/aacraid/linit.c | 6 --
drivers/scsi/cxlflash/common.h| 3 ++-
drivers/scsi/cxlflash/main.c | 2 +-
drivers/scsi/cxlflash/superpipe.c | 12 +---
drivers/scsi/esas2r/esas2r.h | 4 ++--
drivers/scsi/esas2r/esas2r_ioctl.c| 13 ++---
drivers/scsi/esas2r/esas2r_main.c | 2 +-
drivers/scsi/hpsa.c | 15 +--
drivers/scsi/ipr.c| 3 ++-
drivers/scsi/libsas/sas_scsi_host.c | 2 +-
drivers/scsi/scsi_debug.c | 3 ++-
drivers/scsi/smartpqi/smartpqi_init.c | 3 ++-
include/linux/libata.h| 5 +++--
include/scsi/libsas.h | 3 ++-
include/scsi/scsi_host.h | 6 --
19 files changed, 53 insertions(+), 42 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 3d4887d0e84a..6291f1dbf342 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -778,7 +778,7 @@ static int ata_ioc32(struct ata_port *ap)
}
int ata_sas_scsi_ioctl(struct ata_port *ap, struct scsi_device *scsidev,
-int cmd, void __user *arg)
+unsigned int cmd, void __user *arg)
{
unsigned long val;
int rc = -EINVAL;
@@ -829,7 +829,8 @@ int ata_sas_scsi_ioctl(struct ata_port *ap, struct
scsi_device *scsidev,
}
EXPORT_SYMBOL_GPL(ata_sas_scsi_ioctl);
-int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)
+int ata_scsi_ioctl(struct scsi_device *scsidev, unsigned int cmd,
+ void __user *arg)
{
return ata_sas_scsi_ioctl(ata_shost_to_port(scsidev->host),
scsidev, cmd, arg);
diff --git a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c
index 75ab5ff6b78c..6085aa087a2f 100644
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -3455,7 +3455,7 @@ static int delete_disk(struct aac_dev *dev, void __user
*arg)
}
}
-int aac_dev_ioctl(struct aac_dev *dev, int cmd, void __user *arg)
+int aac_dev_ioctl(struct aac_dev *dev, unsigned int cmd, void __user *arg)
{
switch (cmd) {
case FSACTL_QUERY_DISK:
diff --git a/drivers/scsi/aacraid/aacraid.h b/drivers/scsi/aacraid/aacraid.h
index 3291d1c16864..1df5171594b8 100644
--- a/drivers/scsi/aacraid/aacraid.h
+++ b/drivers/scsi/aacraid/aacraid.h
@@ -2706,12 +2706,12 @@ void aac_set_intx_mode(struct aac_dev *dev);
int aac_get_config_status(struct aac_dev *dev, int commit_flag);
int aac_get_containers(struct aac_dev *dev);
int aac_scsi_cmd(struct scsi_cmnd *cmd);
-int aac_dev_ioctl(struct aac_dev *dev, int cmd, void __user *arg);
+int aac_dev_ioctl(struct aac_dev *dev, unsigned int cmd, void __user *arg);
#ifndef shost_to_class
#define shost_to_class(shost) >shost_dev
#endif
ssize_t aac_get_serial_number(struct device *dev, char *buf);
-int aac_do_ioctl(struct aac_dev * dev, int cmd, void __user *arg);
+int aac_do_ioctl(struct aac_dev *dev, unsigned int cmd, void __user *arg);
int aac_rx_init(struct aac_dev *dev);
int aac_rkt_init(struct aac_dev *dev);
int
Re: [PATCH] input_event: Provide override for sparc64
> On Dec 29, 2018, at 10:35 AM, Deepa Dinamani wrote:
>
> The usec part of the timeval is defined as
> __kernel_suseconds_ttv_usec; /* microseconds */
>
> Arnd noticed that sparc64 is the only architecture
> that defines __kernel_suseconds_t as int rather than long.
>
> This breaks the current y2038 fix for kernel as we only
> access and define the timeval struct for non-kernel use cases.
> But, this was hidden by an another typo in the use of __KERNEL__
> qualifier.
>
> Fix the typo, and provide an override for sparc64.
>
> Fixes: 152194fe9c3f ("Input: extend usable life of event timestamps to 2106
> on 32 bit systems")
> Reported-by: Arnd Bergmann
> Signed-off-by: Deepa Dinamani
> ---
> include/uapi/linux/input.h | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index fb78f6f500f3..ffab958bc512 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -26,13 +26,17 @@
> */
>
> struct input_event {
> -#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) &&
> !defined(__KERNEL)
> +#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) &&
> !defined(__KERNEL__)
>struct timeval time;
> #define input_event_sec time.tv_sec
> #define input_event_usec time.tv_usec
> #else
>__kernel_ulong_t __sec;
> +#ifdef CONFIG_SPARC64
> +unsigned int __usec;
> +#else
>__kernel_ulong_t __usec;
> +#endif
> #define input_event_sec __sec
> #define input_event_usec __usec
> #endif
> --
> 2.17.1
Ping.
This is required for the proper functioning of the y2038 additions to input
event.
-Deepa
Re: [PATCH] fs/dax: Convert to use vmf_error()
On Sat, Jan 5, 2019 at 12:50 AM Souptick Joarder wrote:
>
> This code is converted to use vmf_error().
>
> Signed-off-by: Souptick Joarder
Any comment on this patch ?
> ---
> fs/dax.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 48132ec..ed39161 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1220,9 +1220,7 @@ static vm_fault_t dax_fault_return(int error)
> {
> if (error == 0)
> return VM_FAULT_NOPAGE;
> - if (error == -ENOMEM)
> - return VM_FAULT_OOM;
> - return VM_FAULT_SIGBUS;
> + return vmf_error(error);
> }
>
> /*
> --
> 1.9.1
>
Re: [PATCH] mm: Introduce GFP_PGTABLE
On 01/12/2019 09:19 PM, Matthew Wilcox wrote: > On Sat, Jan 12, 2019 at 02:49:29PM +0100, Christophe Leroy wrote: >> As far as I can see, >> >> #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT) >> >> So what's the difference between: >> >> (GFP_KERNEL_ACCOUNT | __GFP_ZERO) & ~__GFP_ACCOUNT >> >> and >> >> (GFP_KERNEL | __GFP_ZERO) & ~__GFP_ACCOUNT > > Nothing. But there's a huge difference in the other parts of that same > file where GFP_ACCOUNT is _not_ used. > > I think this unification is too small to bother with. Something I've > had on my todo list for some time and have not done anything about > is to actually unify all of the architecture pte/pmd/... allocations. > There are tricks some architectures use that others would benefit from. Sure. Could you please elaborate on this ? Invariably all kernel pgtable page allocations should use GFP_PGTABLE and all user page table allocation should use (GFP_PGTABLE | __GFP_ACCOUNT). Ideally there should be default generic functions user_pgtable_gfp() or kernel_pgtable_gfp() returning these values. Overrides can be provided if an arch still wants some more control.
Re: [PATCHv6] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr
Hi,
Just fix a few of the commit log comments...
On 1/13/19 7:15 PM, Pingfan Liu wrote:
> People reported a bug on a high end server with many pcie devices, where
> kernel bootup with crashkernel=384M, and kaslr is enabled. Even
> though we still see much memory under 896 MB, the finding still failed
> intermittently. Because currently we can only find region under 896 MB,
> if w/0 ',high' specified. Then KASLR breaks 896 MB into several parts
if w/o
or preferably:
if without
> randomly, and crashkernel reservation need be aligned to 128 MB, that's
> why failure is found. It raises confusion to the end user that sometimes
> crashkernel=X works while sometimes fails.
> If want to make it succeed, customer can change kernel option to
> "crashkernel=384M, high". Just this give "crashkernel=xx@yy" a very
no space? just
"crashkernel=384M,high"
> limited space to behave even though its grammer looks more generic.
grammar
> And we can't answer questions raised from customer that confidently:
> 1) why it doesn't succeed to reserve 896 MB;
> 2) what's wrong with memory region under 4G;
> 3) why I have to add ',high', I only require 384 MB, not 3840 MB.
> This patch tries to get memory region from 896 MB firstly, then [896MB,4G],
> finally above 4G.
> Dave Young sent the original post, and I just re-post it with commit log
> improvement as his requirement.
> http://lists.infradead.org/pipermail/kexec/2017-October/019571.html
> There was an old discussion below (previously posted by Chao Wang):
> https://lkml.org/lkml/2013/10/15/601
>
> Signed-off-by: Pingfan Liu
> Cc: Dave Young
> Cc: Baoquan He
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Cc: ying...@kernel.org,
> Cc: vgo...@redhat.com
> ---
> v5 -> v6
> discard bottom-up allocation, just repost dyoung's original patch with
> commit log improved
> ---
> arch/x86/kernel/setup.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 3d872a5..fa62c81 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -551,6 +551,22 @@ static void __init reserve_crashkernel(void)
> high ? CRASH_ADDR_HIGH_MAX
>: CRASH_ADDR_LOW_MAX,
> crash_size, CRASH_ALIGN);
> +#ifdef CONFIG_X86_64
> + /*
> + * crashkernel=X reserve below 896M fails? Try below 4G
> + */
> + if (!high && !crash_base)
> + crash_base = memblock_find_in_range(CRASH_ALIGN,
> + (1ULL << 32),
> + crash_size, CRASH_ALIGN);
> + /*
> + * crashkernel=X reserve below 4G fails? Try MAXMEM
> + */
> + if (!high && !crash_base)
> + crash_base = memblock_find_in_range(CRASH_ALIGN,
> + CRASH_ADDR_HIGH_MAX,
> + crash_size, CRASH_ALIGN);
> +#endif
> if (!crash_base) {
> pr_info("crashkernel reservation failed - No suitable
> area found.\n");
> return;
>
ciao.
--
~Randy
linux-next: build warning after merge of the net tree
Hi all,
After merging the net tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
ld: warning: orphan section `.bpfilter_umh' from
`net/bpfilter/bpfilter_umh_blob.o' being placed in section `.bpfilter_umh'
Introduced by commit
61fbf5933d42 ("net: bpfilter: restart bpfilter_umh when error occurred")
--
Cheers,
Stephen Rothwell
pgpoTtWv9YudO.pgp
Description: OpenPGP digital signature
Re: [PATCH] mm: Introduce GFP_PGTABLE
On 01/12/2019 10:18 PM, Shakeel Butt wrote:
>> --- a/arch/x86/kernel/espfix_64.c
>> +++ b/arch/x86/kernel/espfix_64.c
>> @@ -57,8 +57,6 @@
>> # error "Need more virtual address space for the ESPFIX hack"
>> #endif
>>
>> -#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO)
>> -
>> /* This contains the *bottom* address of the espfix stack */
>> DEFINE_PER_CPU_READ_MOSTLY(unsigned long, espfix_stack);
>> DEFINE_PER_CPU_READ_MOSTLY(unsigned long, espfix_waddr);
>> @@ -172,7 +170,7 @@ void init_espfix_ap(int cpu)
>> pud_p = _pud_page[pud_index(addr)];
>> pud = *pud_p;
>> if (!pud_present(pud)) {
>> - struct page *page = alloc_pages_node(node, PGALLOC_GFP, 0);
>> + struct page *page = alloc_pages_node(node, GFP_PGTABLE, 0);
>>
>> pmd_p = (pmd_t *)page_address(page);
>> pud = __pud(__pa(pmd_p) | (PGTABLE_PROT & ptemask));
>> @@ -184,7 +182,7 @@ void init_espfix_ap(int cpu)
>> pmd_p = pmd_offset(, addr);
>> pmd = *pmd_p;
>> if (!pmd_present(pmd)) {
>> - struct page *page = alloc_pages_node(node, PGALLOC_GFP, 0);
>> + struct page *page = alloc_pages_node(node, GFP_PGTABLE, 0);
>>
>> pte_p = (pte_t *)page_address(page);
>> pmd = __pmd(__pa(pte_p) | (PGTABLE_PROT & ptemask));
>> diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
>> index 7bd0170..d608b03 100644
>> --- a/arch/x86/mm/pgtable.c
>> +++ b/arch/x86/mm/pgtable.c
>> @@ -13,19 +13,17 @@ phys_addr_t physical_mask __ro_after_init = (1ULL <<
>> __PHYSICAL_MASK_SHIFT) - 1;
>> EXPORT_SYMBOL(physical_mask);
>> #endif
>>
>> -#define PGALLOC_GFP (GFP_KERNEL_ACCOUNT | __GFP_ZERO)
>> -
> You have silently dropped __GFP_ACCOUNT from all the allocations in this file.
Right, they need to be added back explicitly after GFP_PGTABLE. Matthew had
pointed this earlier. Will fix it next time around.
>
> BTW why other archs not using __GFP_ACCOUNT for the user page tables?
>
Some archs do and some dont. User page tables pages should use __GFP_ACCOUNT
for allocation. I am working on fixing it for arm64.
[PATCH] perf mem/c2c: Fix perf_mem_events to support powerpc
Powerpc hw does not have inbuilt latency filter (--ldlat) for mem-load
event and, perf_mem_events by default includes ldlat=30 which is
causing failure on powerpc. Refactor code to support perf mem/c2c on
powerpc.
This patch depends on kernel side changes done my Madhavan:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-December/182596.html
Signed-off-by: Ravi Bangoria
---
tools/perf/Documentation/perf-c2c.txt | 16
tools/perf/Documentation/perf-mem.txt | 2 +-
tools/perf/arch/x86/util/Build| 1 +
tools/perf/arch/x86/util/mem-events.c | 25 +
tools/perf/util/mem-events.c | 26 --
tools/perf/util/mem-events.h | 2 ++
6 files changed, 45 insertions(+), 27 deletions(-)
create mode 100644 tools/perf/arch/x86/util/mem-events.c
diff --git a/tools/perf/Documentation/perf-c2c.txt
b/tools/perf/Documentation/perf-c2c.txt
index 095aebd..4e12551 100644
--- a/tools/perf/Documentation/perf-c2c.txt
+++ b/tools/perf/Documentation/perf-c2c.txt
@@ -19,8 +19,11 @@ C2C stands for Cache To Cache.
The perf c2c tool provides means for Shared Data C2C/HITM analysis. It allows
you to track down the cacheline contentions.
-The tool is based on x86's load latency and precise store facility events
-provided by Intel CPUs. These events provide:
+On x86, the tool is based on load latency and precise store facility events
+provided by Intel CPUs. On PowerPC, the tool uses random instruction sampling
+with thresholding feature.
+
+These events provide:
- memory address of the access
- type of the access (load and store details)
- latency (in cycles) of the load access
@@ -46,7 +49,7 @@ RECORD OPTIONS
-l::
--ldlat::
- Configure mem-loads latency.
+ Configure mem-loads latency. (x86 only)
-k::
--all-kernel::
@@ -119,11 +122,16 @@ Following perf record options are configured by default:
-W,-d,--phys-data,--sample-cpu
Unless specified otherwise with '-e' option, following events are monitored by
-default:
+default on x86:
cpu/mem-loads,ldlat=30/P
cpu/mem-stores/P
+and following on PowerPC:
+
+ cpu/mem-loads/P
+ cpu/mem-stores/P
+
User can pass any 'perf record' option behind '--' mark, like (to enable
callchains and system wide monitoring):
diff --git a/tools/perf/Documentation/perf-mem.txt
b/tools/perf/Documentation/perf-mem.txt
index f8d2167..199ea0f 100644
--- a/tools/perf/Documentation/perf-mem.txt
+++ b/tools/perf/Documentation/perf-mem.txt
@@ -82,7 +82,7 @@ RECORD OPTIONS
Be more verbose (show counter open errors, etc)
--ldlat ::
- Specify desired latency for loads event.
+ Specify desired latency for loads event. (x86 only)
In addition, for report all perf report options are valid, and for record
all perf record options.
diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index 844b8f3..9827240 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -6,6 +6,7 @@ libperf-y += perf_regs.o
libperf-y += group.o
libperf-y += machine.o
libperf-y += event.o
+libperf-y += mem-events.o
libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_BPF_PROLOGUE) += dwarf-regs.o
diff --git a/tools/perf/arch/x86/util/mem-events.c
b/tools/perf/arch/x86/util/mem-events.c
new file mode 100644
index 000..5b4dcfe
--- /dev/null
+++ b/tools/perf/arch/x86/util/mem-events.c
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "mem-events.h"
+
+struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
+ PERF_MEM_EVENT("ldlat-loads", "cpu/mem-loads,ldlat=%u/P", "mem-loads"),
+ PERF_MEM_EVENT("ldlat-stores", "cpu/mem-stores/P", "mem-stores"),
+};
+
+static char mem_loads_name[100];
+static bool mem_loads_name__init;
+
+char *perf_mem_events__name(int i)
+{
+ if (i == PERF_MEM_EVENTS__LOAD) {
+ if (!mem_loads_name__init) {
+ mem_loads_name__init = true;
+ scnprintf(mem_loads_name, sizeof(mem_loads_name),
+ perf_mem_events[i].name,
+ perf_mem_events__loads_ldlat);
+ }
+ return mem_loads_name;
+ }
+
+ return (char *)perf_mem_events[i].name;
+}
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 93f74d8..1ffefd3 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -15,31 +15,13 @@
unsigned int perf_mem_events__loads_ldlat = 30;
-#define E(t, n, s) { .tag = t, .name = n, .sysfs_name = s }
-
-struct perf_mem_event perf_mem_events[PERF_MEM_EVENTS__MAX] = {
- E("ldlat-loads","cpu/mem-loads,ldlat=%u/P", "mem-loads"),
- E("ldlat-stores", "cpu/mem-stores/P", "mem-stores"),
+struct perf_mem_event __weak perf_mem_events[PERF_MEM_EVENTS__MAX] = {
+ PERF_MEM_EVENT("ldlat-loads", "cpu/mem-loads/P", "mem-loads"),
+
Re: ppc64le reliable stack unwinder and scheduled tasks
On Fri, Jan 11, 2019 at 08:51:54AM +0100, Nicolai Stange wrote:
> Joe Lawrence writes:
>
> > On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
[ ... snip ... ]
> >> For testing, could you try whether clearing the word at STACK_FRAME_MARKER
> >> from _switch() helps?
> >>
> >> I.e. something like (completely untested):
> >
> > I'll kick off some builds tonight and try to get tests lined up
> > tomorrow. Unfortunately these take a bit of time to run setup, schedule
> > and complete, so perhaps by next week.
>
> Ok, that's probably still a good test for confirmation, but the solution
> you proposed below is much better.
Good news, 40 tests (RHEL-7 backport) with clearing out the
STACK_FRAME_MARKER were all successful. Previously I would see stalled
livepatch transitions due to the unreliable report in ~10% of test
cases.
> >> diff --git a/arch/powerpc/kernel/entry_64.S
> >> b/arch/powerpc/kernel/entry_64.S
> >> index 435927f549c4..b747d0647ec4 100644
> >> --- a/arch/powerpc/kernel/entry_64.S
> >> +++ b/arch/powerpc/kernel/entry_64.S
> >> @@ -596,6 +596,10 @@ _GLOBAL(_switch)
> >>SAVE_8GPRS(14, r1)
> >>SAVE_10GPRS(22, r1)
> >>std r0,_NIP(r1) /* Return to switch caller */
> >> +
> >> + li r23,0
> >> + std r23,96(r1) /* 96 == STACK_FRAME_MARKER * sizeof(long) */
> >> +
> >>mfcrr23
> >>std r23,_CCR(r1)
> >>std r1,KSP(r3) /* Set old stack pointer */
> >>
> >>
> >
> > This may be sufficient to avoid the condition, but if the contents of
> > frame 0 are truely uninitialized (not to be trusted), should the
> > unwinder be even looking at that frame (for STACK_FRAMES_REGS_MARKER),
> > aside from the LR and other stack size geometry sanity checks?
>
> That's a very good point: we'll only ever be examining scheduled out tasks
> and current (which at that time is running klp_try_complete_transition()).
>
> current won't be in an interrupt/exception when it's walking its own
> stack. And scheduled out tasks can't have an exception/interrupt frame
> as their frame 0, correct?
>
> Thus, AFAICS, whenever klp_try_complete_transition() finds a
> STACK_FRAMES_REGS_MARKER in frame 0, it is known to be garbage, as you
> said.
I gave this about 20 tests and they were also all successful, what do
you think? (The log could probably use some trimming and cleanup.) I
think either solution would fix the issue.
-->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8--
>From edd3fb9e8a16d5a7ccc98759e9397f386f0e82ca Mon Sep 17 00:00:00 2001
From: Joe Lawrence
Date: Fri, 11 Jan 2019 10:25:26 -0500
Subject: [PATCH] powerpc/livepatch: relax reliable stack tracer exception
check
The ppc64le reliable stack tracer iterates over a given task's stack,
verifying a set of conditions to determine whether the trace is
'reliable'. These checks include the presence of any exception frames.
We should be careful when inspecting the bottom-most stack frame (the
first to be unwound), particularly for scheduled-out tasks. As Nicolai
Stange explains, "If I'm reading the code in _switch() correctly, the
first frame is completely uninitialized except for the pointer back to
the caller's stack frame." If a previous do_IRQ() invocation, for
example, has left a residual exception-marker on the first frame, the
stack tracer would incorrectly report this task's trace as unreliable.
save_stack_trace_tsk_reliable() already skips the first frame when
verifying the saved Link Register. It should do the same when looking
for the STACK_FRAME_REGS_MARKER. The task it is unwinding will be
either 'current', in which case the tracer will have never been called
from an exception path, or the task will be inactive and its first
frame's contents will be uninitialized (aside from backchain pointer).
Fixes: df78d3f61480 ("powerpc/livepatch: Implement reliable stack tracing for
the consistency model")
Signed-off-by: Joe Lawrence
---
arch/powerpc/kernel/stacktrace.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index e2c50b55138f..0793e75c45a6 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -84,6 +84,12 @@ save_stack_trace_regs(struct pt_regs *regs, struct
stack_trace *trace)
EXPORT_SYMBOL_GPL(save_stack_trace_regs);
#ifdef CONFIG_HAVE_RELIABLE_STACKTRACE
+/*
+ * This function returns an error if it detects any unreliable features of the
+ * stack. Otherwise it guarantees that the stack trace is reliable.
+ *
+ * If the task is not 'current', the caller *must* ensure the task is inactive.
+ */
int
save_stack_trace_tsk_reliable(struct task_struct *tsk,
struct stack_trace *trace)
@@ -143,7 +149,7 @@ save_stack_trace_tsk_reliable(struct task_struct *tsk,
return 1;
/* Mark stacktraces with exception frames as unreliable. */
- if (sp
Re: [PATCH 2/2] dt-bindings: iio: chemical: Add bindings for bme680
Hi Sebastien,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on iio/togreg]
[also build test ERROR on v5.0-rc2 next-20190111]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sebastien-Bourdelin/iio-chemical-bme680-Add-device-tree-support/20190114-063618
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> drivers/iio/chemical/bme680_i2c.c:77:1: error: Expected ; at end of
>> declaration
>> drivers/iio/chemical/bme680_i2c.c:77:1: error: got extern
In file included from include/linux/acpi.h:41:0,
from drivers/iio/chemical/bme680_i2c.c:14:
include/linux/module.h:213:1: error: expected ',' or ';' before 'extern'
extern typeof(name) __mod_##type##__##name##_device_table \
^
drivers/iio/chemical/bme680_i2c.c:77:1: note: in expansion of macro
'MODULE_DEVICE_TABLE'
MODULE_DEVICE_TABLE(of, bme680_of_i2c_match);
^~~
--
>> drivers/iio/chemical/bme680_spi.c:117:1: error: Expected ; at end of
>> declaration
>> drivers/iio/chemical/bme680_spi.c:117:1: error: got extern
>> drivers/iio/chemical/bme680_spi.c:123:43: error: undefined identifier
>> 'of_match_ptr'
In file included from include/linux/acpi.h:41:0,
from drivers/iio/chemical/bme680_spi.c:7:
include/linux/module.h:213:1: error: expected ',' or ';' before 'extern'
extern typeof(name) __mod_##type##__##name##_device_table \
^
drivers/iio/chemical/bme680_spi.c:117:1: note: in expansion of macro
'MODULE_DEVICE_TABLE'
MODULE_DEVICE_TABLE(of, bme680_of_spi_match);
^~~
drivers/iio/chemical/bme680_spi.c:123:22: error: implicit declaration of
function 'of_match_ptr'; did you mean 'hash_ptr'?
[-Werror=implicit-function-declaration]
.of_match_table = of_match_ptr(bme680_of_spi_match),
^~~~
hash_ptr
drivers/iio/chemical/bme680_spi.c:123:22: warning: initialization makes
pointer from integer without a cast [-Wint-conversion]
drivers/iio/chemical/bme680_spi.c:123:22: note: (near initialization for
'bme680_spi_driver.driver.of_match_table')
drivers/iio/chemical/bme680_spi.c:123:22: error: initializer element is not
constant
drivers/iio/chemical/bme680_spi.c:123:22: note: (near initialization for
'bme680_spi_driver.driver.of_match_table')
cc1: some warnings being treated as errors
vim +77 drivers/iio/chemical/bme680_i2c.c
1b3bd859 Himanshu Jha2018-07-26 72
a8182f08 Sebastien Bourdelin 2019-01-11 73 static const struct of_device_id
bme680_of_i2c_match[] = {
a8182f08 Sebastien Bourdelin 2019-01-11 74 { .compatible = "bosch,bme680",
},
a8182f08 Sebastien Bourdelin 2019-01-11 75 {},
a8182f08 Sebastien Bourdelin 2019-01-11 76 }
a8182f08 Sebastien Bourdelin 2019-01-11 @77 MODULE_DEVICE_TABLE(of,
bme680_of_i2c_match);
a8182f08 Sebastien Bourdelin 2019-01-11 78
:: The code at line 77 was first introduced by commit
:: a8182f084d7571c44c76305024da0f40a0911cf7 iio: chemical: bme680: Add
device-tree support
:: TO: Sebastien Bourdelin
:: CC: 0day robot
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] mm: Introduce GFP_PGTABLE
On 01/13/2019 11:05 PM, Michal Hocko wrote: > On Sat 12-01-19 15:56:38, Anshuman Khandual wrote: >> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL | >> __GFP_ZERO) and using it for allocating page table pages. This causes some >> code duplication which can be easily avoided. GFP_KERNEL allocated and >> cleared out pages (__GFP_ZERO) are required for page tables on any given >> architecture. This creates a new generic GFP flag flag which can be used >> for any page table page allocation. Does not cause any functional change. > > I agree that some unification is due but GFP_PGTABLE is not something to > expose in generic gfp.h IMHO. It just risks an abuse. I would be looking Why would you think that it risks an abuse ? It does not create new semantics of allocation in the buddy. Its just uses existing GFP_KERNEL allocation which is then getting zeroed out. The risks (if any) is exactly same as GFP_KERNEL. > at providing asm-generic implementation and reuse it to remove the code Does that mean GFP_PGTABLE can be created but not in gfp.h but in some other memory related header file ? > duplication. But I haven't tried that to know that it will work out due > to small/subtle differences between arches. IIUC from the allocation perspective GFP_ACCOUNT is the only thing which gets added with GFP_PGTABLE for user page table for memcg accounting purpose. There does not seem to be any other differences unless I am missing something.
Re: [PATCH 14/15] arch: add split IPC system calls where needed
Hi Arnd, Arnd Bergmann writes: > The IPC system call handling is highly inconsistent across architectures, > some use sys_ipc, some use separate calls, and some use both. We also > have some architectures that require passing IPC_64 in the flags, and > others that set it implicitly. > > For the additon of a y2083 safe semtimedop() system call, I chose to only > support the separate entry points, but that requires first supporting > the regular ones with their own syscall numbers. > > The IPC_64 is now implied by the new semctl/shmctl/msgctl system > calls even on the architectures that require passing it with the ipc() > multiplexer. > > I'm not adding the new semtimedop() or semop() on 32-bit architectures, > those will get implemented using the new semtimedop_time64() version > that gets added along with the other time64 calls. > Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop(). > > Signed-off-by: Arnd Bergmann > --- > One aspect here that might be a bit controversial is the use of > the same system call numbers across all architectures, synchronizing > all of them with the x86-32 numbers. With the new syscall.tbl > files, I hope we can just keep doing that in the future, and no > longer require the architecture maintainers to assign a number. > > This is mainly useful for implementers of the C libraries: if > we can add future system calls everywhere at the same time, using > a particular version of the kernel headers also guarantees that > the system call number macro is visible. > --- > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++ > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++ > arch/powerpc/kernel/syscalls/syscall.tbl | 12 I have some changes I'd like to make to our syscall table that will clash with this. I'll try and send them today. > diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl > b/arch/powerpc/kernel/syscalls/syscall.tbl > index db3bbb8744af..1bffab54ff35 100644 > --- a/arch/powerpc/kernel/syscalls/syscall.tbl > +++ b/arch/powerpc/kernel/syscalls/syscall.tbl > @@ -425,3 +425,15 @@ > 386 nospu pkey_mprotect sys_pkey_mprotect > 387 nospu rseqsys_rseq > 388 nospu io_pgetevents sys_io_pgetevents > compat_sys_io_pgetevents > +# room for arch specific syscalls > +392 64 semtimedop sys_semtimedop > +393 common semget sys_semget > +394 common semctl sys_semctl > compat_sys_semctl > +395 common shmget sys_shmget > +396 common shmctl sys_shmctl > compat_sys_shmctl > +397 common shmat sys_shmat > compat_sys_shmat > +398 common shmdt sys_shmdt > +399 common msgget sys_msgget > +400 common msgsnd sys_msgsnd > compat_sys_msgsnd > +401 common msgrcv sys_msgrcv > compat_sys_msgrcv > +402 common msgctl sys_msgctl > compat_sys_msgctl We already have a gap at 366-377 from when we tried to add the split IPC calls a few years back. I guess I don't mind leaving that gap and using the common numbers as you've done here. But it would be good to add a comment pointing out that we have room at 366 for more arch specific syscalls as well. cheers
Re: [PATCH v2] rbtree: fix the red root
‐‐‐ Original Message ‐‐‐ On Sunday, January 13, 2019 10:52 PM, Douglas Gilbert wrote: > On 2019-01-13 10:07 p.m., Esme wrote: > > > ‐‐‐ Original Message ‐‐‐ > > On Sunday, January 13, 2019 9:33 PM, Qian Cai c...@lca.pw wrote: > > > > > On 1/13/19 9:20 PM, David Lechner wrote: > > > > > > > On 1/11/19 8:58 PM, Michel Lespinasse wrote: > > > > > > > > > On Fri, Jan 11, 2019 at 3:47 PM David Lechner da...@lechnology.com > > > > > wrote: > > > > > > > > > > > On 1/11/19 2:58 PM, Qian Cai wrote: > > > > > > > > > > > > > A GPF was reported, > > > > > > > kasan: CONFIG_KASAN_INLINE enabled > > > > > > > kasan: GPF could be caused by NULL-ptr deref or user memory access > > > > > > > general protection fault: [#1] SMP KASAN > > > > > > > kasan_die_handler.cold.22+0x11/0x31 > > > > > > > notifier_call_chain+0x17b/0x390 > > > > > > > atomic_notifier_call_chain+0xa7/0x1b0 > > > > > > > notify_die+0x1be/0x2e0 > > > > > > > do_general_protection+0x13e/0x330 > > > > > > > general_protection+0x1e/0x30 > > > > > > > rb_insert_color+0x189/0x1480 > > > > > > > create_object+0x785/0xca0 > > > > > > > kmemleak_alloc+0x2f/0x50 > > > > > > > kmem_cache_alloc+0x1b9/0x3c0 > > > > > > > getname_flags+0xdb/0x5d0 > > > > > > > getname+0x1e/0x20 > > > > > > > do_sys_open+0x3a1/0x7d0 > > > > > > > __x64_sys_open+0x7e/0xc0 > > > > > > > do_syscall_64+0x1b3/0x820 > > > > > > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > > > > > It turned out, > > > > > > > gparent = rb_red_parent(parent); > > > > > > > tmp = gparent->rb_right; <-- GPF was triggered here. > > > > > > > Apparently, "gparent" is NULL which indicates "parent" is > > > > > > > rbtree's root > > > > > > > which is red. Otherwise, it will be treated properly a few lines > > > > > > > above. > > > > > > > /* > > > > > > > * If there is a black parent, we are done. > > > > > > > * Otherwise, take some corrective action as, > > > > > > > * per 4), we don't want a red root or two > > > > > > > * consecutive red nodes. > > > > > > > */ > > > > > > > if(rb_is_black(parent)) > > > > > > > break; > > > > > > > Hence, it violates the rule #1 (the root can't be red) and need a > > > > > > > fix > > > > > > > up, and also add a regression test for it. This looks like was > > > > > > > introduced by 6d58452dc06 where it no longer always paint the > > > > > > > root as > > > > > > > black. > > > > > > > Fixes: 6d58452dc06 (rbtree: adjust root color in > > > > > > > rb_insert_color() only > > > > > > > when necessary) > > > > > > > Reported-by: Esme espl...@protonmail.ch > > > > > > > Tested-by: Joey Pabalinas joeypabali...@gmail.com > > > > > > > Signed-off-by: Qian Cai c...@lca.pw > > > > > > > > > > > > Tested-by: David Lechner da...@lechnology.com > > > > > > FWIW, this fixed the following crash for me: > > > > > > Unable to handle kernel NULL pointer dereference at virtual address > > > > > > 0004 > > > > > > > > > > Just to clarify, do you have a way to reproduce this crash without > > > > > the fix ? > > > > > > > > I am starting to suspect that my crash was caused by some new code > > > > in the drm-misc-next tree that might be causing a memory corruption. > > > > It threw me off that the stack trace didn't contain anything related > > > > to drm. > > > > See: https://patchwork.freedesktop.org/patch/276719/ > > > > > > It may be useful for those who could reproduce this issue to turn on those > > > memory corruption debug options to narrow down a bit. > > > CONFIG_DEBUG_PAGEALLOC=y > > > CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y > > > CONFIG_KASAN=y > > > CONFIG_KASAN_GENERIC=y > > > CONFIG_SLUB_DEBUG_ON=y > > > > I have been on SLAB, I configured SLAB DEBUG with a fresh pull from github. > > Linux syzkaller 5.0.0-rc2 #9 SMP Sun Jan 13 21:57:40 EST 2019 x86_64 > > ... > > In an effort to get a different stack into the kernel, I felt that nothing > > works better than fork bomb? :) > > Let me know if that helps. > > root@syzkaller:~# gcc -o test3 test3.c > > root@syzkaller:~# while : ; do ./test3 & done > > And is test3 the same multi-threaded program that enters the kernel via > /dev/sg0 and then calls SCSI_IOCTL_SEND_COMMAND which goes to the SCSI > mid-level and thence to the block layer? > > And please remind me, does it also fail on lk 4.20.2 ? > > Doug Gilbert Yes, the same C repro from the earlier thread. It was a 4.20.0 kernel where it was first detected. I can move to 4.20.2 and see if that changes anything. Esme
Re: [PATCH v2] rbtree: fix the red root
On 2019-01-13 10:07 p.m., Esme wrote: ‐‐‐ Original Message ‐‐‐ On Sunday, January 13, 2019 9:33 PM, Qian Cai wrote: On 1/13/19 9:20 PM, David Lechner wrote: On 1/11/19 8:58 PM, Michel Lespinasse wrote: On Fri, Jan 11, 2019 at 3:47 PM David Lechner da...@lechnology.com wrote: On 1/11/19 2:58 PM, Qian Cai wrote: A GPF was reported, kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN kasan_die_handler.cold.22+0x11/0x31 notifier_call_chain+0x17b/0x390 atomic_notifier_call_chain+0xa7/0x1b0 notify_die+0x1be/0x2e0 do_general_protection+0x13e/0x330 general_protection+0x1e/0x30 rb_insert_color+0x189/0x1480 create_object+0x785/0xca0 kmemleak_alloc+0x2f/0x50 kmem_cache_alloc+0x1b9/0x3c0 getname_flags+0xdb/0x5d0 getname+0x1e/0x20 do_sys_open+0x3a1/0x7d0 __x64_sys_open+0x7e/0xc0 do_syscall_64+0x1b3/0x820 entry_SYSCALL_64_after_hwframe+0x49/0xbe It turned out, gparent = rb_red_parent(parent); tmp = gparent->rb_right; <-- GPF was triggered here. Apparently, "gparent" is NULL which indicates "parent" is rbtree's root which is red. Otherwise, it will be treated properly a few lines above. /* * If there is a black parent, we are done. * Otherwise, take some corrective action as, * per 4), we don't want a red root or two * consecutive red nodes. */ if(rb_is_black(parent)) break; Hence, it violates the rule #1 (the root can't be red) and need a fix up, and also add a regression test for it. This looks like was introduced by 6d58452dc06 where it no longer always paint the root as black. Fixes: 6d58452dc06 (rbtree: adjust root color in rb_insert_color() only when necessary) Reported-by: Esme espl...@protonmail.ch Tested-by: Joey Pabalinas joeypabali...@gmail.com Signed-off-by: Qian Cai c...@lca.pw - Tested-by: David Lechner da...@lechnology.com FWIW, this fixed the following crash for me: Unable to handle kernel NULL pointer dereference at virtual address 0004 Just to clarify, do you have a way to reproduce this crash without the fix ? I am starting to suspect that my crash was caused by some new code in the drm-misc-next tree that might be causing a memory corruption. It threw me off that the stack trace didn't contain anything related to drm. See: https://patchwork.freedesktop.org/patch/276719/ It may be useful for those who could reproduce this issue to turn on those memory corruption debug options to narrow down a bit. CONFIG_DEBUG_PAGEALLOC=y CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y CONFIG_KASAN=y CONFIG_KASAN_GENERIC=y CONFIG_SLUB_DEBUG_ON=y I have been on SLAB, I configured SLAB DEBUG with a fresh pull from github. Linux syzkaller 5.0.0-rc2 #9 SMP Sun Jan 13 21:57:40 EST 2019 x86_64 ... In an effort to get a different stack into the kernel, I felt that nothing works better than fork bomb? :) Let me know if that helps. root@syzkaller:~# gcc -o test3 test3.c root@syzkaller:~# while : ; do ./test3 & done And is test3 the same multi-threaded program that enters the kernel via /dev/sg0 and then calls SCSI_IOCTL_SEND_COMMAND which goes to the SCSI mid-level and thence to the block layer? And please remind me, does it also fail on lk 4.20.2 ? Doug Gilbert
Re: [PATCH 14/15] arch: add split IPC system calls where needed
Hi Arnd, Arnd Bergmann writes: > The IPC system call handling is highly inconsistent across architectures, > some use sys_ipc, some use separate calls, and some use both. We also > have some architectures that require passing IPC_64 in the flags, and > others that set it implicitly. > > For the additon of a y2083 safe semtimedop() system call, I chose to only > support the separate entry points, but that requires first supporting > the regular ones with their own syscall numbers. > > The IPC_64 is now implied by the new semctl/shmctl/msgctl system > calls even on the architectures that require passing it with the ipc() > multiplexer. > > I'm not adding the new semtimedop() or semop() on 32-bit architectures, > those will get implemented using the new semtimedop_time64() version > that gets added along with the other time64 calls. > Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop(). > > Signed-off-by: Arnd Bergmann > --- > One aspect here that might be a bit controversial is the use of > the same system call numbers across all architectures, synchronizing > all of them with the x86-32 numbers. With the new syscall.tbl > files, I hope we can just keep doing that in the future, and no > longer require the architecture maintainers to assign a number. > > This is mainly useful for implementers of the C libraries: if > we can add future system calls everywhere at the same time, using > a particular version of the kernel headers also guarantees that > the system call number macro is visible. > --- > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++ > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++ > arch/powerpc/kernel/syscalls/syscall.tbl | 12 I have some changes I'd like to make to our syscall table that will clash with this. I'll try and send them today. > diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl > b/arch/powerpc/kernel/syscalls/syscall.tbl > index db3bbb8744af..1bffab54ff35 100644 > --- a/arch/powerpc/kernel/syscalls/syscall.tbl > +++ b/arch/powerpc/kernel/syscalls/syscall.tbl > @@ -425,3 +425,15 @@ > 386 nospu pkey_mprotect sys_pkey_mprotect > 387 nospu rseqsys_rseq > 388 nospu io_pgetevents sys_io_pgetevents > compat_sys_io_pgetevents > +# room for arch specific syscalls > +392 64 semtimedop sys_semtimedop > +393 common semget sys_semget > +394 common semctl sys_semctl > compat_sys_semctl > +395 common shmget sys_shmget > +396 common shmctl sys_shmctl > compat_sys_shmctl > +397 common shmat sys_shmat > compat_sys_shmat > +398 common shmdt sys_shmdt > +399 common msgget sys_msgget > +400 common msgsnd sys_msgsnd > compat_sys_msgsnd > +401 common msgrcv sys_msgrcv > compat_sys_msgrcv > +402 common msgctl sys_msgctl > compat_sys_msgctl We already have a gap at 366-377 from when we tried to add the split IPC calls a few years back. I guess I don't mind leaving that gap and using the common numbers. But would be good to add a comment pointing out that we have room there for arch specific syscalls as well. cheers
[PATCH 2/2] kbuild: merge KBUILD_VMLINUX_{INIT,MAIN} into KBUILD_VMLINUX_OBJS
The top Makefile does not need to export KBUILD_VMLINUX_INIT and
KBUILD_VMLINUX_MAIN separately.
Put every built-in.a into KBUILD_VMLINUX_OBJS. The order of
$(head-y), $(init-y), $(core-y), ... is still retained.
Signed-off-by: Masahiro Yamada
---
Makefile| 6 +++---
scripts/link-vmlinux.sh | 28 ++--
2 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/Makefile b/Makefile
index 499b968..68898cc 100644
--- a/Makefile
+++ b/Makefile
@@ -975,15 +975,15 @@ libs-y2 := $(patsubst %/, %/built-in.a,
$(filter-out %.a, $(libs-y)))
virt-y := $(patsubst %/, %/built-in.a, $(virt-y))
# Externally visible symbols (used by link-vmlinux.sh)
-export KBUILD_VMLINUX_INIT := $(head-y) $(init-y)
-export KBUILD_VMLINUX_MAIN := $(core-y) $(libs-y2) $(drivers-y) $(net-y)
$(virt-y)
+export KBUILD_VMLINUX_OBJS := $(head-y) $(init-y) $(core-y) $(libs-y2) \
+ $(drivers-y) $(net-y) $(virt-y)
export KBUILD_VMLINUX_LIBS := $(libs-y1)
export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds
export LDFLAGS_vmlinux
# used by scripts/package/Makefile
export KBUILD_ALLDIRS := $(sort $(filter-out arch/%,$(vmlinux-alldirs)) arch
Documentation include samples scripts tools)
-vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_INIT) $(KBUILD_VMLINUX_MAIN)
$(KBUILD_VMLINUX_LIBS)
+vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_OBJS) $(KBUILD_VMLINUX_LIBS)
# Recurse until adjust_autoksyms.sh is satisfied
PHONY += autoksyms_recursive
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 4788def..bc7f1fc 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -3,22 +3,17 @@
#
# link vmlinux
#
-# vmlinux is linked from the objects selected by $(KBUILD_VMLINUX_INIT) and
-# $(KBUILD_VMLINUX_MAIN) and $(KBUILD_VMLINUX_LIBS). Most are built-in.a files
-# from top-level directories in the kernel tree, others are specified in
-# arch/$(ARCH)/Makefile. Ordering when linking is important, and
-# $(KBUILD_VMLINUX_INIT) must be first. $(KBUILD_VMLINUX_LIBS) are archives
-# which are linked conditionally (not within --whole-archive), and do not
-# require symbol indexes added.
+# vmlinux is linked from the objects selected by $(KBUILD_VMLINUX_OBJS) and
+# $(KBUILD_VMLINUX_LIBS). Most are built-in.a files from top-level directories
+# in the kernel tree, others are specified in arch/$(ARCH)/Makefile.
+# $(KBUILD_VMLINUX_LIBS) are archives which are linked conditionally
+# (not within --whole-archive), and do not require symbol indexes added.
#
# vmlinux
# ^
# |
-# +-< $(KBUILD_VMLINUX_INIT)
-# | +--< init/version.o + more
-# |
-# +--< $(KBUILD_VMLINUX_MAIN)
-# |+--< drivers/built-in.a mm/built-in.a + more
+# +--< $(KBUILD_VMLINUX_OBJS)
+# |+--< init/built-in.a drivers/built-in.a mm/built-in.a + more
# |
# +--< $(KBUILD_VMLINUX_LIBS)
# |+--< lib/lib.a + more
@@ -51,8 +46,7 @@ modpost_link()
local objects
objects="--whole-archive\
- ${KBUILD_VMLINUX_INIT} \
- ${KBUILD_VMLINUX_MAIN} \
+ ${KBUILD_VMLINUX_OBJS} \
--no-whole-archive \
--start-group \
${KBUILD_VMLINUX_LIBS} \
@@ -71,8 +65,7 @@ vmlinux_link()
if [ "${SRCARCH}" != "um" ]; then
objects="--whole-archive\
- ${KBUILD_VMLINUX_INIT} \
- ${KBUILD_VMLINUX_MAIN} \
+ ${KBUILD_VMLINUX_OBJS} \
--no-whole-archive \
--start-group \
${KBUILD_VMLINUX_LIBS} \
@@ -83,8 +76,7 @@ vmlinux_link()
-T ${lds} ${objects}
else
objects="-Wl,--whole-archive\
- ${KBUILD_VMLINUX_INIT} \
- ${KBUILD_VMLINUX_MAIN} \
+ ${KBUILD_VMLINUX_OBJS} \
-Wl,--no-whole-archive \
-Wl,--start-group \
${KBUILD_VMLINUX_LIBS} \
--
2.7.4
[PATCH] Documentation: fix coding-style.rst Sphinx warning
From: Randy Dunlap Fix Sphinx warning in coding-style.rst: Documentation/process/coding-style.rst:446: WARNING: Inline interpreted text or phrase reference start-string without end-string. Signed-off-by: Randy Dunlap --- Documentation/process/coding-style.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-50-rc2.orig/Documentation/process/coding-style.rst +++ lnx-50-rc2/Documentation/process/coding-style.rst @@ -443,7 +443,7 @@ In function prototypes, include paramete Although this is not required by the C language, it is preferred in Linux because it is a simple way to add valuable information for the reader. -Do not use the `extern' keyword with function prototypes as this makes +Do not use the ``extern`` keyword with function prototypes as this makes lines longer and isn't strictly necessary.
[PATCH 1/2] kbuild: remove top-level built-in.a
The symbol table in the final archive is unneeded because it is passed
to the linker after the --whole-archive option. Every object file in
the archive is included in the link anyway.
Pass thin archives from subdirectories directly to the linker, and
remove the final archiving step.
Signed-off-by: Masahiro Yamada
---
scripts/link-vmlinux.sh | 30 ++
1 file changed, 6 insertions(+), 24 deletions(-)
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index c8cf453..4788def 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -44,24 +44,6 @@ info()
fi
}
-# Thin archive build here makes a final archive with symbol table and indexes
-# from vmlinux objects INIT and MAIN, which can be used as input to linker.
-# KBUILD_VMLINUX_LIBS archives should already have symbol table and indexes
-# added.
-#
-# Traditional incremental style of link does not require this step
-#
-# built-in.a output file
-#
-archive_builtin()
-{
- info AR built-in.a
- rm -f built-in.a;
- ${AR} rcsTP${KBUILD_ARFLAGS} built-in.a \
- ${KBUILD_VMLINUX_INIT} \
- ${KBUILD_VMLINUX_MAIN}
-}
-
# Link of vmlinux.o used for section mismatch analysis
# ${1} output file
modpost_link()
@@ -69,7 +51,8 @@ modpost_link()
local objects
objects="--whole-archive\
- built-in.a \
+ ${KBUILD_VMLINUX_INIT} \
+ ${KBUILD_VMLINUX_MAIN} \
--no-whole-archive \
--start-group \
${KBUILD_VMLINUX_LIBS} \
@@ -88,7 +71,8 @@ vmlinux_link()
if [ "${SRCARCH}" != "um" ]; then
objects="--whole-archive\
- built-in.a \
+ ${KBUILD_VMLINUX_INIT} \
+ ${KBUILD_VMLINUX_MAIN} \
--no-whole-archive \
--start-group \
${KBUILD_VMLINUX_LIBS} \
@@ -99,7 +83,8 @@ vmlinux_link()
-T ${lds} ${objects}
else
objects="-Wl,--whole-archive\
- built-in.a \
+ ${KBUILD_VMLINUX_INIT} \
+ ${KBUILD_VMLINUX_MAIN} \
-Wl,--no-whole-archive \
-Wl,--start-group \
${KBUILD_VMLINUX_LIBS} \
@@ -160,7 +145,6 @@ cleanup()
rm -f .tmp_System.map
rm -f .tmp_kallsyms*
rm -f .tmp_vmlinux*
- rm -f built-in.a
rm -f System.map
rm -f vmlinux
rm -f vmlinux.o
@@ -217,8 +201,6 @@ fi;
# final build of init/
${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init
-archive_builtin
-
#link vmlinux.o
info LD vmlinux.o
modpost_link vmlinux.o
--
2.7.4
Re: [RFC PATCH 2/2] kexec, KEYS: Make use of platform keyring for signature verify
Hi, Mimi, Dave I checked the previous patches: https://www.spinics.net/lists/keyrings/msg03518.html https://www.spinics.net/lists/keyrings/msg03517.html https://www.spinics.net/lists/keyrings/msg03516.html That the latest patched I could found that placed the platform keyring in certs/ However it didn't cc kexec list, and so I think Dave didn't receive them. I could compose a patch to use the previous design, how do you think? On Sun, Jan 13, 2019 at 9:40 AM Dave Young wrote: > > Hi, > > On 01/11/19 at 11:13am, Mimi Zohar wrote: > > On Fri, 2019-01-11 at 21:43 +0800, Dave Young wrote: > > [snip] > > > > > Personally I would like to see platform key separated from integrity. > > > But for the kexec_file part I think it is good at least it works with > > > this fix. > > > > > > Acked-by: Dave Young > > > > The original "platform" keyring patches that Nayna posted multiple > > times were in the certs directory, but nobody commented/responded. So > > she reworked the patches, moving them to the integrity directory and > > posted them (cc'ing the kexec mailing list). It's a bit late to be > > asking to move it, isn't it? > > Hmm, apologize for being late, I did not get chance to have a look the > old series. Since we have the needs now, it should be still fine > > Maybe Kairui can check Nayna's old series, see if he can do something > again? > > > > > Mimi > > > > Thanks > Dave -- Best Regards, Kairui Song
Re: ufshcd_queuecommand() triggering after ufshcd_suspend()?
Hey all, I think there are two different issues: 1. clk_gating's state(including state's trace event) and is_suspended is not wrapped by ufshcd_is_clkgating_allowed which Hisilicon's kirin platoform soc does not need but is set and checked in a regular path. 2. I think SCSI is necessary to block queue to stop sending to ufs after system suspend or, add a new state for ufs like UFSHCD_STATE_SUSPENDING or what else. hba->is_sys_suspended is too late to stop ufshcd_queuecommand On Fri, Jan 11, 2019 at 06:39:56AM +, Avri Altman wrote: > +Zang > > Thanks, > Avri > > > > > From: John Stultz > Sent: Friday, January 11, 2019 1:02:21 AM > To: Sahitya Tummala; Christoph Hellwig; Wei Li; Martin K. Petersen > Cc: Evan Green; Avri Altman; Vijay Viswanath; lkml; linux-s...@vger.kernel.org > Subject: ufshcd_queuecommand() triggering after ufshcd_suspend()? > > Hey all, > Frequently, since support for the HiKey960's UFS code landed in > 4.19, I've noticed the following warning on reboot: > > [ 23.086860] WARNING: CPU: 0 PID: 2507 at > drivers/scsi/ufs/ufshcd.c:2460 ufshcd_queuecommand+0x59c/0x5a8 > [ 23.096256] Modules linked in: > [ 23.099313] CPU: 0 PID: 2507 Comm: kworker/0:1H Tainted: G S > 5.0.0-rc1-00068-g3f81a19 #273 > [ 23.108873] Hardware name: HiKey960 (DT) > [ 23.112802] Workqueue: kblockd blk_mq_requeue_work > [ 23.117591] pstate: 8045 (Nzcv daif +PAN -UAO) > [ 23.122378] pc : ufshcd_queuecommand+0x59c/0x5a8 > [ 23.126990] lr : ufshcd_queuecommand+0x58c/0x5a8 > [ 23.131600] sp : ff8015e1ba80 > [ 23.134907] x29: ff8015e1ba80 x28: ffc217f94048 > [ 23.140214] x27: 0010 x26: ffc217a7c8b8 > [ 23.145520] x25: ffc217a7c000 x24: ffc217a7ceb0 > [ 23.150827] x23: x22: ffc217a7c808 > [ 23.156133] x21: ffc217f94120 x20: 0010 > [ 23.161440] x19: ff801186d000 x18: ff801186db08 > [ 23.166746] x17: x16: > [ 23.172053] x15: ff8095e1b7c7 x14: 692064616574736e > [ 23.177360] x13: 6928204e4f5f534b x12: 4c43203d21206574 > [ 23.182666] x11: 6174732e676e6974 x10: 61675f6b6c633e2d > [ 23.187973] x9 : 61626820646e616d x8 : 6d6f636575657571 > [ 23.193280] x7 : x6 : ff801186e000 > [ 23.198586] x5 : ff801186e270 x4 : ff8010096dc0 > [ 23.203894] x3 : 0001 x2 : 47dd99afde511d00 > [ 23.209201] x1 : x0 : > [ 23.214509] Call trace: > [ 23.216952] ufshcd_queuecommand+0x59c/0x5a8 > [ 23.221220] scsi_queue_rq+0x5b4/0x880 > [ 23.224964] blk_mq_dispatch_rq_list+0xb0/0x510 > [ 23.229492] blk_mq_sched_dispatch_requests+0xf4/0x198 > [ 23.234626] __blk_mq_run_hw_queue+0xb4/0x120 > [ 23.238978] __blk_mq_delay_run_hw_queue+0x110/0x200 > [ 23.243937] blk_mq_run_hw_queue+0xb8/0x118 > [ 23.248114] blk_mq_run_hw_queues+0x58/0x78 > [ 23.252291] blk_mq_requeue_work+0x140/0x168 > [ 23.256560] process_one_work+0x158/0x468 > [ 23.260564] worker_thread+0x50/0x460 > [ 23.264222] kthread+0x104/0x130 > [ 23.267447] ret_from_fork+0x10/0x1c > [ 23.271017] ---[ end trace 45f1ee04059cdf00 ]--- > > Since the warning is triggering from the WARN_ON(hba->clk_gating.state > != CLKS_ON) line, I annotated the clk_gating.state changes, and am > seeing on reboot: > vdc: Waited 0ms for vold > sd 0:0:0:3: [sdd] Synchronizing SCSI cache > sd 0:0:0:2: [sdc] Synchronizing SCSI cache > sd 0:0:0:1: [sdb] Synchronizing SCSI cache > sd 0:0:0:0: [sda] Synchronizing SCSI cache > ufshcd_suspend: setting clk_gating.state CLKS_OFF > ufshcd_queuecommand hba->clk_gating.state != CLKS_ON (instead its 0) > > > So it seems like ufshcd_suspend() is has run, but then the workqueue > (occasionally) fires afterwards triggering the issue. > > Maybe should something in ufshcd_queuecommand be checking the > clk_gating.is_suspended flag before proceeding? > > Other ideas? The logic all seems to be in the generic code, but I'm > not sure if maybe the ufs-hisi.c code is mis-managing something? > > thanks > -john -- Thanks, Zang Leigang
[PATCH] Documentation: add ibmvmc to toctree(index) and fix warnings
From: Randy Dunlap Fix Sphinx warnings in ibmvmc.rst, add an index.rst file in Documentation/misc-devices/, and insert that index file into the top-level index file. Documentation/misc-devices/ibmvmc.rst:2: WARNING: Explicit markup ends without a blank line; unexpected unindent. Documentation/misc-devices/ibmvmc.rst:: WARNING: document isn't included in any toctree Signed-off-by: Randy Dunlap Cc: Steven Royer Cc: Jonathan Corbet --- Documentation/index.rst |1 + Documentation/misc-devices/ibmvmc.rst |1 + Documentation/misc-devices/index.rst | 17 + 3 files changed, 19 insertions(+) --- lnx-50-rc2.orig/Documentation/misc-devices/ibmvmc.rst +++ lnx-50-rc2/Documentation/misc-devices/ibmvmc.rst @@ -1,4 +1,5 @@ .. SPDX-License-Identifier: GPL-2.0+ + == IBM Virtual Management Channel Kernel Driver (IBMVMC) == --- lnx-50-rc2.orig/Documentation/index.rst +++ lnx-50-rc2/Documentation/index.rst @@ -90,6 +90,7 @@ needed). filesystems/index vm/index bpf/index + misc-devices/index Architecture-specific documentation --- --- /dev/null +++ lnx-50-rc2/Documentation/misc-devices/index.rst @@ -0,0 +1,17 @@ +.. SPDX-License-Identifier: GPL-2.0 + + +Assorted Miscellaneous Devices Documentation + + +This documentation contains information for assorted devices that do not +fit into other categories. + +.. class:: toc-title + + Table of contents + +.. toctree:: + :maxdepth: 2 + + ibmvmc
[PATCH] pvcalls-front: fix potential null dereference
static checker warning:
drivers/xen/pvcalls-front.c:373 alloc_active_ring()
error: we previously assumed 'map->active.ring' could be null
(see line 357)
drivers/xen/pvcalls-front.c
351 static int alloc_active_ring(struct sock_mapping *map)
352 {
353 void *bytes;
354
355 map->active.ring = (struct pvcalls_data_intf *)
356 get_zeroed_page(GFP_KERNEL);
357 if (!map->active.ring)
^
Check
358 goto out;
359
360 map->active.ring->ring_order = PVCALLS_RING_ORDER;
361 bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
362 PVCALLS_RING_ORDER);
363 if (!bytes)
364 goto out;
365
366 map->active.data.in = bytes;
367 map->active.data.out = bytes +
368 XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
369
370 return 0;
371
372 out:
--> 373 free_active_ring(map);
^^^
Replace map->active.ring->ring_order with PVCALLS_RING_ORDER
to avoid potential null dereference.
Fixes: 9f51c05dc41a ("pvcalls-front: Avoid get_free_pages(GFP_KERNEL)
under spinlock")
Reported-by: Dan Carpenter
Signed-off-by: Wen Yang
CC: Boris Ostrovsky
CC: Juergen Gross
CC: Stefano Stabellini
CC: Dan Carpenter
CC: xen-de...@lists.xenproject.org
CC: linux-kernel@vger.kernel.org
---
drivers/xen/pvcalls-front.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 307861f..e56f9a3 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -344,7 +344,7 @@ int pvcalls_front_socket(struct socket *sock)
static void free_active_ring(struct sock_mapping *map)
{
free_pages((unsigned long)map->active.data.in,
- map->active.ring->ring_order);
+ PVCALLS_RING_ORDER);
free_page((unsigned long)map->active.ring);
}
--
2.9.5
[PATCHv6] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr
People reported a bug on a high end server with many pcie devices, where
kernel bootup with crashkernel=384M, and kaslr is enabled. Even
though we still see much memory under 896 MB, the finding still failed
intermittently. Because currently we can only find region under 896 MB,
if w/0 ',high' specified. Then KASLR breaks 896 MB into several parts
randomly, and crashkernel reservation need be aligned to 128 MB, that's
why failure is found. It raises confusion to the end user that sometimes
crashkernel=X works while sometimes fails.
If want to make it succeed, customer can change kernel option to
"crashkernel=384M, high". Just this give "crashkernel=xx@yy" a very
limited space to behave even though its grammer looks more generic.
And we can't answer questions raised from customer that confidently:
1) why it doesn't succeed to reserve 896 MB;
2) what's wrong with memory region under 4G;
3) why I have to add ',high', I only require 384 MB, not 3840 MB.
This patch tries to get memory region from 896 MB firstly, then [896MB,4G],
finally above 4G.
Dave Young sent the original post, and I just re-post it with commit log
improvement as his requirement.
http://lists.infradead.org/pipermail/kexec/2017-October/019571.html
There was an old discussion below (previously posted by Chao Wang):
https://lkml.org/lkml/2013/10/15/601
Signed-off-by: Pingfan Liu
Cc: Dave Young
Cc: Baoquan He
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: ying...@kernel.org,
Cc: vgo...@redhat.com
---
v5 -> v6
discard bottom-up allocation, just repost dyoung's original patch with commit
log improved
---
arch/x86/kernel/setup.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 3d872a5..fa62c81 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -551,6 +551,22 @@ static void __init reserve_crashkernel(void)
high ? CRASH_ADDR_HIGH_MAX
: CRASH_ADDR_LOW_MAX,
crash_size, CRASH_ALIGN);
+#ifdef CONFIG_X86_64
+ /*
+* crashkernel=X reserve below 896M fails? Try below 4G
+*/
+ if (!high && !crash_base)
+ crash_base = memblock_find_in_range(CRASH_ALIGN,
+ (1ULL << 32),
+ crash_size, CRASH_ALIGN);
+ /*
+* crashkernel=X reserve below 4G fails? Try MAXMEM
+*/
+ if (!high && !crash_base)
+ crash_base = memblock_find_in_range(CRASH_ALIGN,
+ CRASH_ADDR_HIGH_MAX,
+ crash_size, CRASH_ALIGN);
+#endif
if (!crash_base) {
pr_info("crashkernel reservation failed - No suitable
area found.\n");
return;
--
2.7.4
[PATCH] kbuild: remove unused baseprereq
Commit eea199b445f6 ("kbuild: remove unnecessary LEX_PREFIX and
YACC_PREFIX") removed the last users of this macro.
Signed-off-by: Masahiro Yamada
---
scripts/Kbuild.include | 4
1 file changed, 4 deletions(-)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 525bff6..3081603 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -24,10 +24,6 @@ depfile = $(subst $(comma),_,$(dot-target).d)
basetarget = $(basename $(notdir $@))
###
-# filename of first prerequisite with directory and extension stripped
-baseprereq = $(basename $(notdir $<))
-
-###
# Escape single quote for use in echo statements
escsq = $(subst $(squote),'\$(squote)',$1)
--
2.7.4
答复: [PATCH][v2] tty: fix race between flush_to_ldisc and tty_open
> -邮件原件- > 发件人: Kohli, Gaurav [mailto:gko...@codeaurora.org] > 发送时间: 2019年1月11日 21:57 > 收件人: Li,Rongqing ; linux-kernel@vger.kernel.org; > jsl...@suse.com; gre...@linuxfoundation.org; a...@linux.intel.com > 主题: Re: [PATCH][v2] tty: fix race between flush_to_ldisc and tty_open > > Hi, > > it don't seems to be good idea to put lock on one function and unlock in some > other function. If in future some one has to call tty_init_dev, how he can > track > the unlocking as well of ldisc lock. > > Regards > Gaurav > This similar condition has existed for a long time, tty_unlock(tty) must be called in some other functions who call tty_init_dev, since tty_init_dev hold tty_lock, and does not release it so I think it is user responsibility to fully understand tty_init_dev; and I can add some comments for tty_init_dev if this patch can be acceptable; or a workaround like below: diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c index a42a028a9d4e..2f5ad256b6ad 100644 --- a/drivers/tty/tty_buffer.c +++ b/drivers/tty/tty_buffer.c @@ -425,7 +425,7 @@ static void flush_to_ldisc(struct work_struct *work) struct tty_ldisc *disc; tty = port->itty; - if (tty == NULL) + if (tty == NULL || tty->driver_data == NULL) return; disc = tty_ldisc_ref(tty); thanks -RongQing
Re: [PATCH v2] rbtree: fix the red root
‐‐‐ Original Message ‐‐‐ On Sunday, January 13, 2019 9:33 PM, Qian Cai wrote: > On 1/13/19 9:20 PM, David Lechner wrote: > > > On 1/11/19 8:58 PM, Michel Lespinasse wrote: > > > > > On Fri, Jan 11, 2019 at 3:47 PM David Lechner da...@lechnology.com wrote: > > > > > > > On 1/11/19 2:58 PM, Qian Cai wrote: > > > > > > > > > A GPF was reported, > > > > > kasan: CONFIG_KASAN_INLINE enabled > > > > > kasan: GPF could be caused by NULL-ptr deref or user memory access > > > > > general protection fault: [#1] SMP KASAN > > > > > kasan_die_handler.cold.22+0x11/0x31 > > > > > notifier_call_chain+0x17b/0x390 > > > > > atomic_notifier_call_chain+0xa7/0x1b0 > > > > > notify_die+0x1be/0x2e0 > > > > > do_general_protection+0x13e/0x330 > > > > > general_protection+0x1e/0x30 > > > > > rb_insert_color+0x189/0x1480 > > > > > create_object+0x785/0xca0 > > > > > kmemleak_alloc+0x2f/0x50 > > > > > kmem_cache_alloc+0x1b9/0x3c0 > > > > > getname_flags+0xdb/0x5d0 > > > > > getname+0x1e/0x20 > > > > > do_sys_open+0x3a1/0x7d0 > > > > > __x64_sys_open+0x7e/0xc0 > > > > > do_syscall_64+0x1b3/0x820 > > > > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > > > It turned out, > > > > > gparent = rb_red_parent(parent); > > > > > tmp = gparent->rb_right; <-- GPF was triggered here. > > > > > Apparently, "gparent" is NULL which indicates "parent" is rbtree's > > > > > root > > > > > which is red. Otherwise, it will be treated properly a few lines > > > > > above. > > > > > /* > > > > > * If there is a black parent, we are done. > > > > > * Otherwise, take some corrective action as, > > > > > * per 4), we don't want a red root or two > > > > > * consecutive red nodes. > > > > > */ > > > > > if(rb_is_black(parent)) > > > > > break; > > > > > Hence, it violates the rule #1 (the root can't be red) and need a fix > > > > > up, and also add a regression test for it. This looks like was > > > > > introduced by 6d58452dc06 where it no longer always paint the root as > > > > > black. > > > > > > > > > > Fixes: 6d58452dc06 (rbtree: adjust root color in rb_insert_color() > > > > > only > > > > > when necessary) > > > > > Reported-by: Esme espl...@protonmail.ch > > > > > Tested-by: Joey Pabalinas joeypabali...@gmail.com > > > > > Signed-off-by: Qian Cai c...@lca.pw > > > > > > > > > > - > > > > > > > > Tested-by: David Lechner da...@lechnology.com > > > > FWIW, this fixed the following crash for me: > > > > Unable to handle kernel NULL pointer dereference at virtual address > > > > 0004 > > > > > > Just to clarify, do you have a way to reproduce this crash without the > > > fix ? > > > > I am starting to suspect that my crash was caused by some new code > > in the drm-misc-next tree that might be causing a memory corruption. > > It threw me off that the stack trace didn't contain anything related > > to drm. > > See: https://patchwork.freedesktop.org/patch/276719/ > > It may be useful for those who could reproduce this issue to turn on those > memory corruption debug options to narrow down a bit. > > CONFIG_DEBUG_PAGEALLOC=y > CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y > CONFIG_KASAN=y > CONFIG_KASAN_GENERIC=y > CONFIG_SLUB_DEBUG_ON=y I have been on SLAB, I configured SLAB DEBUG with a fresh pull from github. Linux syzkaller 5.0.0-rc2 #9 SMP Sun Jan 13 21:57:40 EST 2019 x86_64 ... In an effort to get a different stack into the kernel, I felt that nothing works better than fork bomb? :) Let me know if that helps. root@syzkaller:~# gcc -o test3 test3.c root@syzkaller:~# while : ; do ./test3 & done [1] 5671 [2] 5672 [3] 5673 [4] 5675 [5] 5677 [6] 5693 [7] 5699 [8] 5701 [9] 5741 [ 128.063843] INFO: trying to register non-static key. [ 128.064903] the code is fine but needs lockdep annotation. [ 128.066010] turning off the locking correctness validator. [ 128.067120] CPU: 0 PID: 5719 Comm: modprobe Not tainted 5.0.0-rc2 #9 [ 128.068420] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1ubuntu1 04/01/2014 [ 128.070236] Call Trace: [ 128.070763] dump_stack+0x104/0x174 [ 128.071467] register_lock_class+0x598/0x5a0 [ 128.072326] __lock_acquire+0x84/0x16d0 [ 128.073090] ? find_held_lock+0x35/0xa0 [ 128.073876] lock_acquire+0xe7/0x200 [ 128.074599] ? acct_collect+0xd9/0x250 [ 128.075352] _raw_spin_lock_irq+0x49/0x60 [ 128.076165] ? acct_collect+0xd9/0x250 [ 128.076931] acct_collect+0xd9/0x250 [ 128.077687] do_exit+0x430/0x1370 [ 128.078373] ? task_work_run+0xb1/0x110 [ 128.079158] do_group_exit+0x79/0x130 [ 128.079904] __x64_sys_exit_group+0x1c/0x20 [ 128.080751] do_syscall_64+0x99/0x2f0 [
linux-next: manual merge of the scsi tree with the scsi-fixes tree
Hi all,
Today's linux-next merge of the scsi tree got a conflict in:
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
between commit:
7bb25a89aad2 ("scsi: hisi_sas: Set protection parameters prior to adding SCSI
host")
from the scsi-fixes tree and commit:
ef63464bcf8f ("scsi: hisi_sas: Create root and device debugfs directories")
from the scsi tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index c92b3822c408,b780b5269f0f..
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@@ -2507,12 -2672,9 +2672,15 @@@ hisi_sas_v3_probe(struct pci_dev *pdev
sha->sas_port[i] = _hba->port[i].sas_port;
}
+ if (hisi_hba->prot_mask) {
+ dev_info(dev, "Registering for DIF/DIX prot_mask=0x%x\n",
+ prot_mask);
+ scsi_host_set_prot(hisi_hba->shost, prot_mask);
+ }
+
+ if (hisi_sas_debugfs_enable)
+ hisi_sas_debugfs_init(hisi_hba);
+
rc = scsi_add_host(shost, dev);
if (rc)
goto err_out_ha;
pgpFKfoGTJwNy.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 0/5] kvm "virtio pmem" device
On Sun, Jan 13, 2019 at 03:38:21PM -0800, Matthew Wilcox wrote: > On Mon, Jan 14, 2019 at 10:29:02AM +1100, Dave Chinner wrote: > > Until you have images (and hence host page cache) shared between > > multiple guests. People will want to do this, because it means they > > only need a single set of pages in host memory for executable > > binaries rather than a set of pages per guest. Then you have > > multiple guests being able to detect residency of the same set of > > pages. If the guests can then, in any way, control eviction of the > > pages from the host cache, then we have a guest-to-guest information > > leak channel. > > I don't think we should ever be considering something that would allow a > guest to evict page's from the host's pagecache [1]. The guest should > be able to kick its own references to the host's pagecache out of its > own pagecache, but not be able to influence whether the host or another > guest has a read-only mapping cached. > > [1] Unless the guest is allowed to modify the host's file; obviously > truncation, holepunching, etc are going to evict pages from the host's > page cache. Right, and that's exactly what I mean by "we need to be real careful with functionality like this". To be honest, I really don't think I've even touched the surface here. e.g. Filesystems and storage can share logical and physical extents. Which means that image files that share storage (e.g. because they are all cloned from the same master image and/or there's in-line deduplication running on the storage) and can be directly accessed by guests may very well be susceptible to detection of host side deduplication and subsequent copy-on-write operations. This really doesn't seem much different to me from the guest being able to infer host side KSM page deduplication and COW operation in the guest side page cache. The only difference is that DAX is being used to probe the host side page cache and storage rather than the guest side. IOWs, I suspect there's a world of pain waiting for us if we punch huge holes through the virtual machine abstractions like this. Improving performance is a laudible goal, but at what price? Cheers, Dave. -- Dave Chinner da...@fromorbit.com
linux-next: manual merge of the scsi tree with Linus' tree
Hi all,
Today's linux-next merge of the scsi tree got a conflict in:
drivers/scsi/arcmsr/arcmsr_hba.c
between commit:
750afb08ca71 ("cross-tree: phase out dma_zalloc_coherent()")
from Linus' tree and commit:
381d66da7212 ("scsi: arcmsr: Rename acb structure member roundup_ccbsize to
ioqueue_size")
from the scsi tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/scsi/arcmsr/arcmsr_hba.c
index 57c6fa388bf6,9f85d5abbb0c..
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@@ -585,12 -641,9 +641,11 @@@ static bool arcmsr_alloc_io_queue(struc
switch (acb->adapter_type) {
case ACB_ADAPTER_TYPE_B: {
- struct MessageUnit_B *reg;
- acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_B),
32);
+ acb->ioqueue_size = roundup(sizeof(struct MessageUnit_B), 32);
- dma_coherent = dma_zalloc_coherent(>dev,
acb->ioqueue_size,
- _coherent_handle, GFP_KERNEL);
+ dma_coherent = dma_alloc_coherent(>dev,
- acb->roundup_ccbsize,
++acb->ioqueue_size,
+_coherent_handle,
+GFP_KERNEL);
if (!dma_coherent) {
pr_notice("arcmsr%d: DMA allocation failed\n",
acb->host->host_no);
return false;
@@@ -616,13 -655,9 +657,11 @@@
}
break;
case ACB_ADAPTER_TYPE_D: {
- struct MessageUnit_D *reg;
-
- acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_D),
32);
+ acb->ioqueue_size = roundup(sizeof(struct MessageUnit_D), 32);
- dma_coherent = dma_zalloc_coherent(>dev,
acb->ioqueue_size,
- _coherent_handle, GFP_KERNEL);
+ dma_coherent = dma_alloc_coherent(>dev,
- acb->roundup_ccbsize,
++acb->ioqueue_size,
+_coherent_handle,
+GFP_KERNEL);
if (!dma_coherent) {
pr_notice("arcmsr%d: DMA allocation failed\n",
acb->host->host_no);
return false;
@@@ -662,11 -671,9 +675,11 @@@
case ACB_ADAPTER_TYPE_E: {
uint32_t completeQ_size;
completeQ_size = sizeof(struct deliver_completeQ) *
ARCMSR_MAX_HBE_DONEQUEUE + 128;
- acb->roundup_ccbsize = roundup(completeQ_size, 32);
+ acb->ioqueue_size = roundup(completeQ_size, 32);
- dma_coherent = dma_zalloc_coherent(>dev,
acb->ioqueue_size,
- _coherent_handle, GFP_KERNEL);
+ dma_coherent = dma_alloc_coherent(>dev,
- acb->roundup_ccbsize,
++acb->ioqueue_size,
+_coherent_handle,
+GFP_KERNEL);
if (!dma_coherent){
pr_notice("arcmsr%d: DMA allocation failed\n",
acb->host->host_no);
return false;
pgpcNOv73umMy.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 0/6] Static calls
On 1/13/19 6:31 PM, H. Peter Anvin wrote:
>
> static cpumask_t text_poke_cpumask;
>
> static void text_poke_sync(void)
> {
> smp_wmb();
> text_poke_cpumask = cpu_online_mask;
> smp_wmb(); /* Should be optional on x86 */
> cpumask_clear_cpu(_poke_cpumask, smp_processor_id());
> on_each_cpu_mask(_poke_cpumask, text_poke_sync_cpu, NULL, false);
> while (!cpumask_empty(_poke_cpumask)) {
> cpu_relax();
> smp_rmb();
> }
> }
>
> static void text_poke_sync_cpu(void *dummy)
> {
> (void)dummy;
>
> smp_rmb();
> cpumask_clear_cpu(_bitmask, smp_processor_id());
> /*
>* We are guaranteed to return with an IRET, either from the
>* IPI or the #BP handler; this provides serialization.
>*/
> }
>
The invariants here are:
1. The patching routine must set each bit in the cpumask after each event
that requires synchronization is complete.
2. The bit can be (atomically) cleared on the target CPU only, and only in a
place that guarantees a synchronizing event (e.g. IRET) before it may
reaching the poked instruction.
3. At a minimum the IPI handler and #BP handler needs to clear the bit. It
*is* also possible to clear it in other places, e.g. the NMI handler, if
necessary as long as condition 2 is satisfied.
-hpa
[RFC PATCH 3/4] watchdog: hpwdt: Add more information into message
Default NMI handling code prints the same into the kernel log.
Signed-off-by: Ivan Mironov
---
drivers/watchdog/hpwdt.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
index e2958df46c69..95d002b5b120 100644
--- a/drivers/watchdog/hpwdt.c
+++ b/drivers/watchdog/hpwdt.c
@@ -155,19 +155,20 @@ static int hpwdt_my_nmi(void)
static int hpwdt_pretimeout(unsigned int ulReason, struct pt_regs *regs)
{
unsigned int mynmi = hpwdt_my_nmi();
- static char panic_msg[] =
- "00: An NMI occurred. Depending on your system the reason "
- "for the NMI is logged in any one of the following resources:\n"
- "1. Integrated Management Log (IML)\n"
- "2. OA Syslog\n"
- "3. OA Forward Progress Log\n"
- "4. iLO Event Log";
if (!mynmi)
return NMI_DONE;
- hex_byte_pack(panic_msg, mynmi);
- nmi_panic(regs, panic_msg);
+ pr_emerg("%02x: An NMI occurred (reason %02x, CPU %d). Depending on "
+"your system the reason for the NMI is logged in any one of "
+"the following resources:\n"
+"1. Integrated Management Log (IML)\n"
+"2. OA Syslog\n"
+"3. OA Forward Progress Log\n"
+"4. iLO Event Log\n",
+mynmi, ulReason, smp_processor_id());
+
+ nmi_panic(regs, "hpwdt: NMI: Not continuing");
return NMI_HANDLED;
}
--
2.20.1
[RFC PATCH 1/4] watchdog: hpwdt: Don't disable watchdog on NMI
Existing code disables watchdog on NMI right before completely hanging the system. There are two problems here: * First, watchdog is expected to reset the system in a case of such failure, no matter what. * Second, this code has no effect if there are more than one watchdog. Signed-off-by: Ivan Mironov --- drivers/watchdog/hpwdt.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c index ef30c7e9728d..2467e6bc25c2 100644 --- a/drivers/watchdog/hpwdt.c +++ b/drivers/watchdog/hpwdt.c @@ -170,8 +170,6 @@ static int hpwdt_pretimeout(unsigned int ulReason, struct pt_regs *regs) if (ilo5 && !pretimeout && !mynmi) return NMI_DONE; - hpwdt_stop(); - hex_byte_pack(panic_msg, mynmi); nmi_panic(regs, panic_msg); -- 2.20.1
[RFC PATCH 2/4] watchdog: hpwdt: Don't panic on foreign NMI
Currently, hpwdt unconditionally panics on foreign NMIs in some cases. This goes against the default kernel behaviour (which is configured by unknown_nmi_panic and panic_on_unrecovered_nmi). With this patch, hpwdt will simply ignore NMI unless one of "mynmi" flags is set by iLO. Signed-off-by: Ivan Mironov --- drivers/watchdog/hpwdt.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c index 2467e6bc25c2..e2958df46c69 100644 --- a/drivers/watchdog/hpwdt.c +++ b/drivers/watchdog/hpwdt.c @@ -33,7 +33,6 @@ #define DEFAULT_MARGIN 30 #define PRETIMEOUT_SEC 9 -static bool ilo5; static unsigned int soft_margin = DEFAULT_MARGIN; /* in seconds */ static bool nowayout = WATCHDOG_NOWAYOUT; static bool pretimeout = IS_ENABLED(CONFIG_HPWDT_NMI_DECODING); @@ -164,10 +163,7 @@ static int hpwdt_pretimeout(unsigned int ulReason, struct pt_regs *regs) "3. OA Forward Progress Log\n" "4. iLO Event Log"; - if (ilo5 && ulReason == NMI_UNKNOWN && !mynmi) - return NMI_DONE; - - if (ilo5 && !pretimeout && !mynmi) + if (!mynmi) return NMI_DONE; hex_byte_pack(panic_msg, mynmi); @@ -332,9 +328,6 @@ static int hpwdt_init_one(struct pci_dev *dev, dev_info(>dev, "pretimeout: %s.\n", pretimeout ? "on" : "off"); - if (dev->subsystem_vendor == PCI_VENDOR_ID_HP_3PAR) - ilo5 = true; - return 0; error_wd_register: -- 2.20.1
[RFC PATCH 0/4] watchdog: hpwdt: Fix NMI-related behaviour when CONFIG_HPWDT_NMI_DECODING is enabled
Hi, I found out that hpwdt alters NMI behaviour unexpectedly if compiled with enabled CONFIG_HPWDT_NMI_DECODING: * System starts to panic on any NMI with misleading message. * Watchdog provided by hpwdt is not working after such panic. Here are the patches that should fix this. This is an RFC patch series because I am not sure that patches are correct. Questions: * Are "mynmi" flags always set on all supported iLO versions when iLO is the source of NMI? * Is it safe to reset "mynmi" flags to zero if code decides to not panic? Ivan Mironov (4): watchdog: hpwdt: Don't disable watchdog on NMI watchdog: hpwdt: Don't panic on foreign NMI watchdog: hpwdt: Add more information into message watchdog: hpwdt: Make panic behaviour configurable drivers/watchdog/hpwdt.c | 45 ++-- 1 file changed, 25 insertions(+), 20 deletions(-) -- 2.20.1
[RFC PATCH 4/4] watchdog: hpwdt: Make panic behaviour configurable
This adds an option to not panic on NMI even if it was caused by iLO.
Signed-off-by: Ivan Mironov
---
drivers/watchdog/hpwdt.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
index 95d002b5b120..b12858491189 100644
--- a/drivers/watchdog/hpwdt.c
+++ b/drivers/watchdog/hpwdt.c
@@ -37,6 +37,10 @@ static unsigned int soft_margin = DEFAULT_MARGIN;/* in
seconds */
static bool nowayout = WATCHDOG_NOWAYOUT;
static bool pretimeout = IS_ENABLED(CONFIG_HPWDT_NMI_DECODING);
+#ifdef CONFIG_HPWDT_NMI_DECODING
+static bool panic_on_nmi = true;
+#endif /* CONFIG_HPWDT_NMI_DECODING */
+
static void __iomem *pci_mem_addr; /* the PCI-memory address */
static unsigned long __iomem *hpwdt_nmistat;
static unsigned long __iomem *hpwdt_timer_reg;
@@ -146,7 +150,10 @@ static int hpwdt_set_pretimeout(struct watchdog_device
*wdd, unsigned int req)
static int hpwdt_my_nmi(void)
{
- return ioread8(hpwdt_nmistat) & 0x6;
+ int nmistat = ioread8(hpwdt_nmistat);
+
+ iowrite8(nmistat & ~0x6, hpwdt_nmistat);
+ return nmistat & 0x6;
}
/*
@@ -168,7 +175,10 @@ static int hpwdt_pretimeout(unsigned int ulReason, struct
pt_regs *regs)
"4. iLO Event Log\n",
mynmi, ulReason, smp_processor_id());
- nmi_panic(regs, "hpwdt: NMI: Not continuing");
+ if (panic_on_nmi)
+ nmi_panic(regs, "hpwdt: NMI: Not continuing");
+
+ pr_emerg("Dazed and confused, but trying to continue\n");
return NMI_HANDLED;
}
@@ -376,6 +386,9 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
started (default="
#ifdef CONFIG_HPWDT_NMI_DECODING
module_param(pretimeout, bool, 0);
MODULE_PARM_DESC(pretimeout, "Watchdog pretimeout enabled");
-#endif
+
+module_param(panic_on_nmi, bool, 0);
+MODULE_PARM_DESC(panic_on_nmi, "Cause panic on NMI induced by iLO
(default=1)");
+#endif /* CONFIG_HPWDT_NMI_DECODING */
module_pci_driver(hpwdt_driver);
--
2.20.1
Re: [PATCH v2] rbtree: fix the red root
On 1/13/19 9:20 PM, David Lechner wrote: > On 1/11/19 8:58 PM, Michel Lespinasse wrote: >> On Fri, Jan 11, 2019 at 3:47 PM David Lechner wrote: >>> >>> On 1/11/19 2:58 PM, Qian Cai wrote: A GPF was reported, kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN kasan_die_handler.cold.22+0x11/0x31 notifier_call_chain+0x17b/0x390 atomic_notifier_call_chain+0xa7/0x1b0 notify_die+0x1be/0x2e0 do_general_protection+0x13e/0x330 general_protection+0x1e/0x30 rb_insert_color+0x189/0x1480 create_object+0x785/0xca0 kmemleak_alloc+0x2f/0x50 kmem_cache_alloc+0x1b9/0x3c0 getname_flags+0xdb/0x5d0 getname+0x1e/0x20 do_sys_open+0x3a1/0x7d0 __x64_sys_open+0x7e/0xc0 do_syscall_64+0x1b3/0x820 entry_SYSCALL_64_after_hwframe+0x49/0xbe It turned out, gparent = rb_red_parent(parent); tmp = gparent->rb_right; <-- GPF was triggered here. Apparently, "gparent" is NULL which indicates "parent" is rbtree's root which is red. Otherwise, it will be treated properly a few lines above. /* * If there is a black parent, we are done. * Otherwise, take some corrective action as, * per 4), we don't want a red root or two * consecutive red nodes. */ if(rb_is_black(parent)) break; Hence, it violates the rule #1 (the root can't be red) and need a fix up, and also add a regression test for it. This looks like was introduced by 6d58452dc06 where it no longer always paint the root as black. Fixes: 6d58452dc06 (rbtree: adjust root color in rb_insert_color() only when necessary) Reported-by: Esme Tested-by: Joey Pabalinas Signed-off-by: Qian Cai --- >>> >>> Tested-by: David Lechner >>> FWIW, this fixed the following crash for me: >>> >>> Unable to handle kernel NULL pointer dereference at virtual address 0004 >> >> Just to clarify, do you have a way to reproduce this crash without the fix ? > > I am starting to suspect that my crash was caused by some new code > in the drm-misc-next tree that might be causing a memory corruption. > It threw me off that the stack trace didn't contain anything related > to drm. > > See: https://patchwork.freedesktop.org/patch/276719/ > It may be useful for those who could reproduce this issue to turn on those memory corruption debug options to narrow down a bit. CONFIG_DEBUG_PAGEALLOC=y CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y CONFIG_KASAN=y CONFIG_KASAN_GENERIC=y CONFIG_SLUB_DEBUG_ON=y
Re: [PATCH v3 0/6] Static calls
On 1/11/19 11:39 AM, Jiri Kosina wrote:
> On Fri, 11 Jan 2019, h...@zytor.com wrote:
>
>> I still don't see why can't simply spin in the #BP handler until the
>> patch is complete.
>
> I think this brings us to the already discussed possible deadlock, when
> one CPU#0 is in the middle of text_poke_bp(), CPU#1 is spinning inside
> spin_lock_irq*() and CPU#2 hits the breakpont while holding that very
> 'lock'.
>
> Then we're stuck forever, because CPU#1 will never handle the pending
> sync_core() IPI (it's not NMI).
>
> Or have I misunderstood what you meant?
>
OK, I was thinking about this quite a while ago, and even started hacking on
it, but apparently I managed to forget some key details.
Specifically, you do *not* want to use the acknowledgment of the IPI as the
blocking condition, so don't use a waiting IPI.
Instead, you want a CPU bitmap (or percpu variable) that the IPI handler
clears. When you are spinning in the IPI handler, you *also* need to clear
that bit. Doing so is safe even in the case of batched updates, because you
are guaranteed to execute an IRET before you get to patched code.
So the synchronization part of the patching routine becomes:
static cpumask_t text_poke_cpumask;
static void text_poke_sync(void)
{
smp_wmb();
text_poke_cpumask = cpu_online_mask;
smp_wmb(); /* Optional on x86 */
cpumask_clear_cpu(_poke_cpumask, smp_processor_id());
on_each_cpu_mask(_poke_cpumask, text_poke_sync_cpu, NULL, false);
while (!cpumask_empty(_poke_cpumask)) {
cpu_relax();
smp_rmb();
}
}
static void text_poke_sync_cpu(void *dummy)
{
(void)dummy;
smp_rmb();
cpumask_clear_cpu(_bitmask, smp_processor_id());
/*
* We are guaranteed to return with an IRET, either from the
* IPI or the #BP handler; this provides serialization.
*/
}
The spin routine then needs add a call to do something like this. By
(optionally) not comparing to a specific breakpoint address we allow for
batching, but we may end up spinning on a breakpoint that is not actually a
patching breakpoint until the patching is done.
int poke_int3_handler(struct pt_regs *regs)
{
/* In the current handler, but shouldn't be needed... */
smp_rmb();
if (likely(!atomic_read(bp_patching_in_progress)))
return 0;
if (user_mode(regs) unlikely(!user_mode(regs) &&
atomic_read(_patching_in_progress)) {
text_poke_sync();
regs->ip--;
return 1; /* May end up retaking the trap */
} else {
return 0;
}
}
Unless I'm totally mistaken, the worst thing that will happen with this code
is that it may end up taking a harmless spurious IPI at a later time.
-hpa
Re: [PATCH v2] rbtree: fix the red root
On 1/11/19 8:58 PM, Michel Lespinasse wrote: On Fri, Jan 11, 2019 at 3:47 PM David Lechner wrote: On 1/11/19 2:58 PM, Qian Cai wrote: A GPF was reported, kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN kasan_die_handler.cold.22+0x11/0x31 notifier_call_chain+0x17b/0x390 atomic_notifier_call_chain+0xa7/0x1b0 notify_die+0x1be/0x2e0 do_general_protection+0x13e/0x330 general_protection+0x1e/0x30 rb_insert_color+0x189/0x1480 create_object+0x785/0xca0 kmemleak_alloc+0x2f/0x50 kmem_cache_alloc+0x1b9/0x3c0 getname_flags+0xdb/0x5d0 getname+0x1e/0x20 do_sys_open+0x3a1/0x7d0 __x64_sys_open+0x7e/0xc0 do_syscall_64+0x1b3/0x820 entry_SYSCALL_64_after_hwframe+0x49/0xbe It turned out, gparent = rb_red_parent(parent); tmp = gparent->rb_right; <-- GPF was triggered here. Apparently, "gparent" is NULL which indicates "parent" is rbtree's root which is red. Otherwise, it will be treated properly a few lines above. /* * If there is a black parent, we are done. * Otherwise, take some corrective action as, * per 4), we don't want a red root or two * consecutive red nodes. */ if(rb_is_black(parent)) break; Hence, it violates the rule #1 (the root can't be red) and need a fix up, and also add a regression test for it. This looks like was introduced by 6d58452dc06 where it no longer always paint the root as black. Fixes: 6d58452dc06 (rbtree: adjust root color in rb_insert_color() only when necessary) Reported-by: Esme Tested-by: Joey Pabalinas Signed-off-by: Qian Cai --- Tested-by: David Lechner FWIW, this fixed the following crash for me: Unable to handle kernel NULL pointer dereference at virtual address 0004 Just to clarify, do you have a way to reproduce this crash without the fix ? I am starting to suspect that my crash was caused by some new code in the drm-misc-next tree that might be causing a memory corruption. It threw me off that the stack trace didn't contain anything related to drm. See: https://patchwork.freedesktop.org/patch/276719/ I don't think the fix is correct, because it just silently ignores a corrupted rbtree (red root node). But the code that creates this situation certainly needs to be fixed - having a reproduceable test case would certainly help here. Regarding 6d58452dc06, the reasoning was that this code expects to be called after inserting a new (red) leaf into an rbtree that had all of its data structure invariants satisfied. So in this context, it should not be necessary to always reset the root to black, as this should already be the case...
RE: [PATCH] rtc: snvs: make sure clock is enabled for interrupt handle
Hi, Alexandre Best Regards! Anson Huang > -Original Message- > From: Alexandre Belloni [mailto:alexandre.bell...@bootlin.com] > Sent: 2019年1月11日 22:32 > To: Anson Huang > Cc: a.zu...@towertech.it; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; dl-linux-imx > Subject: Re: [PATCH] rtc: snvs: make sure clock is enabled for interrupt > handle > > Hi, > > On 11/01/2019 07:09:02+, Anson Huang wrote: > > During system suspend, the SNVS RTC's clock will be disabled in noirq > > suspend phase, but SNVS RTC's alarm interrupt could still arrive, > > system will hang if SNVS RTC driver tries to access register without > > clock enabled, this patch fixes the issue of this scenario. > > > > Are you sure this is the real issue? I don't think the handler can be called > before the resume_noirq callback. Isn't the issue that your clock driver has > not > yet resumed by the time you call the rtc driver resume_noirq callback ? Yes, since the RTC alarm is wakeup source, it is NOT being disabled during suspend flow at all, after rtc drvier's noirq suspend callback is being called, rtc clock is disabled in this callback, rtc alarm could arrive at this point then ARM IRQ is NOT disabled yet, so rtc irq handler will be called, so the handler will access RTC register with RTC clock disabled and cause system hang. The point is RTC clock is disabled in noirq suspend callback. > > > Signed-off-by: Anson Huang > > --- > > drivers/rtc/rtc-snvs.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/rtc/rtc-snvs.c b/drivers/rtc/rtc-snvs.c index > > b2483a7..0b9eff1 100644 > > --- a/drivers/rtc/rtc-snvs.c > > +++ b/drivers/rtc/rtc-snvs.c > > @@ -239,6 +239,9 @@ static irqreturn_t snvs_rtc_irq_handler(int irq, void > *dev_id) > > u32 lpsr; > > u32 events = 0; > > > > + if (data->clk) > > + clk_enable(data->clk); > > + > > Anyway, won't that need a clk_prepare_enable because it has been > clk_disable_unprepare in suspend_noirq? And this is something you can not > do in atomic context Yes, but the prepare/unprepared can NOT be called in atomic context, since the SNVS RTC clock on i.MX SoC is always from a clock source without prepare/unprepared needed, such as from ipg or OSC etc., so just doing enable/disable is good enough for it. Anson. > > -- > Alexandre Belloni, Bootlin > Embedded Linux and Kernel engineering > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbootl > in.comdata=02%7C01%7Canson.huang%40nxp.com%7Ca90608144e90 > 494a6f3608d677d1818a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C > 0%7C636828139042107931sdata=oX%2Bqnj4X3nS%2Ba88otedt9WyIy > VhBNVl5eixVWeV44TA%3Dreserved=0
Re: [PATCH] drm/mediatek: Add MTK Framebuffer-Device (mt7623)
On Fri, 2019-01-11 at 17:07 +0100, Noralf Trønnes wrote:
>
> Den 11.01.2019 11.25, skrev Daniel Vetter:
> > On Fri, Jan 11, 2019 at 05:49:15PM +0800, CK Hu wrote:
> >> Hi, Daniel:
> >>
> >> On Fri, 2019-01-11 at 10:20 +0100, Daniel Vetter wrote:
> >>> On Fri, Jan 11, 2019 at 11:20:09AM +0800, CK Hu wrote:
> Hi, Daniel:
>
> On Thu, 2019-01-10 at 21:02 +0100, Daniel Vetter wrote:
> > On Thu, Jan 10, 2019 at 08:01:37PM +0100, Frank Wunderlich wrote:
> >> Hi Daniel,
> >>
> Would be good to use the new generic fbdev emulation code here, for
> even
> less code. Or at least know why this isn't possible to use for mtk
> (and
> maybe address that in the core code). Hand-rolling fbdev code
> shouldn't be
> needed anymore.
> >>>
> >>> Back on the mailing list, no private replies please:
> >>
> >> i don't wanted to spam all people with dumb questions ;)
> >
> > There's no dumb questions, only insufficient documentation :-)
> >
> >>> For examples please grep for drm_fbdev_generic_setup(). There's also a
> >>> still in-flight series from Gerd Hoffmann to convert over bochs. That,
> >>> plus all the kerneldoc linked from there should get you started.
> >>> -Daniel
> >>
> >> this is one of google best founds if i search for
> >> drm_fbdev_generic_setup:
> >>
> >> https://lkml.org/lkml/2018/12/19/305
> >>
> >> not very helpful...
> >>
> >> so i tried kernel-doc
> >>
> >> https://www.kernel.org/doc/html/latest/gpu/drm-kms-helpers.html?highlight=drm_fbdev_generic_setup#c.drm_fbdev_generic_setup
> >>
> >> which is nice function-reference but i've found no generic workflow
> >>
> >> as the posted driver is "only" a driver ported from kernel 4.4 by
> >> Alexander, i don't know if this new framework can be used and which
> >> parts need to be changed. I only try to bring his code Mainline
> >> Maybe CK Hu can help here because driver is originally from him and he
> >> knows internals. Or maybe you can help here?
> >>
> >> i personally make my first steps as spare-time kernel-developer :)
> >
> > There's a ton of in-kernel users of that function already, I meant you
> > can
> > use those to serve as examples ... If those + the kerneldoc aren't
> > good enough, then we need to improve them.
> > -Daniel
>
> I've tried with drm_fbdev_generic_setup() and it works fine with simple
> modification. The patch is
>
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -379,6 +380,7 @@ static void mtk_drm_kms_deinit(struct drm_device
> *drm)
> .gem_prime_get_sg_table = mtk_gem_prime_get_sg_table,
> .gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
> .gem_prime_mmap = mtk_drm_gem_mmap_buf,
> + .gem_prime_vmap = mtk_drm_gem_prime_vmap,
> .ioctls = mtk_ioctls,
> .num_ioctls = ARRAY_SIZE(mtk_ioctls),
> .fops = _drm_fops,
> @@ -416,6 +418,8 @@ static int mtk_drm_bind(struct device *dev)
> if (ret < 0)
> goto err_deinit;
>
> + drm_fbdev_generic_setup(drm, 32);
> +
> return 0;
>
>
> But I implement .gem_prime_vmap with a workaround,
>
>
> --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
> @@ -280,3 +280,8 @@ int mtk_gem_create_ioctl(struct drm_device *dev,
> void *data,
> mtk_drm_gem_free_object(_gem->base);
> return ret;
> }
> +
> +void *mtk_drm_gem_prime_vmap(struct drm_gem_object *obj)
> +{
> + return (void *)1;
> +}
>
> Current drm_fb_helper depends on drm_client to create fbdev. When
> drm_client create drm_client_buffer, it need to vmap to get kernel
> vaddr. But I think for fbdev, the vaddr is useless. Do you agree that I
> temporarily implement .gem_prime_vmap in such way?
> >>>
> >>> The vmap is used by fbcon, without that fbdev won't really work I think.
> >>> So I'm rather confused on what you tested ...
> >>>
> >>> Adding Noralf, he's the expert here.
> >>> -Daniel
> >>
> >> I test with fb_test [1], it is a user space program just open /dev/fb0
> >> and mmap it to user space. I does not turn on fbcon so everything looks
> >> well. If support fbcon is essential, I would implement vmap correctly.
> >> If it's not essential, I think I could return 0 when
> >> CONFIG_FRAMBUFFER_CONSOLE is defined.
> >
> > I think fbdev emulation without working fbcon is fairly useless. And it
> > shouldn't be that much work to
Re: [PATCH 1/2 v6] kdump: add the vmcoreinfo documentation
在 2019年01月11日 20:33, Borislav Petkov 写道: > On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote: >> +init_uts_ns.name.release >> + >> + >> +The version of the Linux kernel. Used to find the corresponding source >> +code from which the kernel has been built. >> + > > ... > >> + >> +init_uts_ns >> +--- >> + >> +This is the UTS namespace, which is used to isolate two specific >> +elements of the system that relate to the uname(2) system call. The UTS >> +namespace is named after the data structure used to store information >> +returned by the uname(2) system call. >> + >> +User-space tools can get the kernel name, host name, kernel release >> +number, kernel version, architecture name and OS type from it. > > Already asked this but no reply so lemme paste my question again: > > "And this document already fulfills its purpose - those two vmcoreinfo > exports are redundant and the first one can be removed. > > And now that we agreed that VMCOREINFO is not an ABI and is very tightly > coupled to the kernel version, init_uts_ns.name.release can be removed, > yes? > > Or is there anything speaking against that?" > Sorry for this, that is my mistake. Thanks for your reminder. I agree on your point of view. But i forgot that i should remove this variable in this post. I would like to remove this variable and post again. Thanks. Lianbo
