Re: Samba kernel panics.

From: Johan Hendriks <joh.hendriks_at_gmail.com>
Date: Wed, 18 Nov 2020 12:13:05 +0100
On 18/11/2020 05:53, Kyle Evans wrote:
> On Tue, Nov 17, 2020 at 10:01 PM Mark Johnston <markj_at_freebsd.org> wrote:
>> On Tue, Nov 17, 2020 at 08:19:12PM +0200, Konstantin Belousov wrote:
>>> On Tue, Nov 17, 2020 at 06:20:31PM +0100, Johan Hendriks wrote:
>>>> Hello all after updating FreeBSD13 from r367724 to r367755 my samba server
>>>> craches the server.
>>>> I did rebuild samba 4.11 but that does not help.
>>>>
>>>> The output on the console is the following.
>>>>
>>>> Fatal trap 12: page fault while in kernel mode
>>>> cpuid =3; apic id = 06
>>>> fault virtual address    = 0x803a122b8
>>>> fault code                   = supervisor read instruction, protection
>>>> violation
>>>> instruction pointer      = 0x20:0x803a122b8
>>>> stack pointer               = 0x28:0xfffffe0127733a50
>>>> frame pointer              = 0x28:0x803a122b0
>>>> code segment             = base 0x0, limit 0xfffff, type 0x1b
>>>>                                     = DPL 0, pres 1, long 1, def32 0, gran 1
>>>> processor eflags          = 17340 (smbd)
>>>> trap number                = 12
>>>> panic: page fault
>>>> cpuid =3
>>>> time = 1605632521
>>>> KDB: stack backtrace:
>>>> db_trace_self_wrapper() at db_trace_setf_wrapper+0x2b/frame
>>>> 0xfffffe0127733700
>>>> vpanic() at vpanic+0x182/frame 0xfffffe0127733750
>>>> panic() at panic+0x43/frame 0xfffffe01277337b0
>>>> trap_fatal() at trap_fatal+0x387/frame 0xfffffe0127733810
>>>> trap_pfault() at trap_pfault+0x4f/frame 0xfffffe0127733870
>>>> trap() at trap+0x27d/frame 0xfffffe0127733980
>>>> calltrap() at caltrap+0x8/frame 0xfffffe0127733980
>>>> --- trap 0xc, rip = 0x803a122b8, rsp = 0xfffffe0127733a50, rbp = 0x803a122b0
>>>> ---
>>>> KDB: enter: panic
>>>> [ thread pid 17340 tid 101772 ]
>>>> stopped at        kdb_enter+0x37: movq     $0,0x1fa9446(%rip)
>>>> db>
>>> This looks like SMEP catching an issue, but it is not clear why.
>> Probably fixed by r367783?  The bug would have partially overwritten the
>> stack frame, resulting in a jump to a user address after a return.
>>
> Ah, yes, sorry that I missed this -- smbd was in-fact the exact
> program that the reporter noted observed it with, and what the fix was
> confirmed with. Sorry for the breakage~
>
> Kyle Evans
>
I can confirm all is working fine again after i svnupped to r367785
Thank you all for your time.

regards
Johan
Received on Wed Nov 18 2020 - 10:13:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC