Hi Saravana,
On 15.07.2020 10:53, Saravana Kannan wrote:
> On Wed, Jul 15, 2020 at 1:22 AM Marek Szyprowski
> <m.szyprowski@xxxxxxxxxxx> wrote:
>> On 10.07.2020 15:23, Greg Kroah-Hartman wrote:
>>> On Mon, Jul 06, 2020 at 03:45:02PM -0700, Saravana Kannan wrote:
>>>> On Tue, Jun 16, 2020 at 8:45 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote:
>>>>> On Fri, May 29, 2020 at 5:30 AM Greg Kroah-Hartman
>>>>> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>>> Looks semi-sane, but it's too close to the merge window at the moment
>>>>>> for me to take this. If there's no objections by the time 5.8-rc1 is
>>>>>> out, I'll queue it up in my tree for 5.9-rc1.
>>>>> Another friendly reminder :)
>>>> *nudge* *nudge*
>>> Looks sane, given no objections, let's see what linux-next thinks about
>>> it...
>> linux-next is not very happy from this patchset... Starting from
>> next-20200713 I see a few new issues on various Samsung Exynos based
>> boards. Here are examples from Exynos4412-based Odroid U3 board (ARM
>> 32bit, kernel compiled from exynos_defconfig):
> Thanks for the bug reports.
>
>> BUG: sleeping function called from invalid context at
>> kernel/locking/mutex.c:935
>> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 12, name: kworker/0:1
>> 2 locks held by kworker/0:1/12:
>> #0: ee8074a8 ((wq_completion)rcu_gp){+.+.}-{0:0}, at:
>> process_one_work+0x174/0x7dc
>> #1: ee921f20 ((work_completion)(&sdp->work)){+.+.}-{0:0}, at:
>> process_one_work+0x174/0x7dc
>> Preemption disabled at:
>> [<c01b10f0>] srcu_invoke_callbacks+0xc0/0x154
> Sigh... probably some SRCU screw up when the device link is deleted.
> I'll look at it by the end of this week. If you don't mind, what SRCU
> debug config caught this for you? That way, I can reproduce it on my
> end.
Just the options enabled in the default exynos_defconfig in current
linux-next. I didn't check any particular options yet.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
