Re: NULL pointer dereference when 'rmmod gpio_lynxpoint'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

On 11.05.2016 17:00, Anatol Pomozov wrote:
Hi

I tried to read the gpio handling code, but I do not see any obvious reason for this "insert module" crash. And I had no time to do history bisect.

On Wed, May 11, 2016 at 2:22 AM, Linus Walleij <linus.walleij@xxxxxxxxxx <mailto:linus.walleij@xxxxxxxxxx>> wrote:

    > I compiled lynx gpio into kernel instead of compiling it as a module.
    > And the system got more stable - I rebooted my devices ~50 times
    > already and I do not see the boot problem I had before. 'CONFIG_..=y'
    > definitely makes the situation better.
    >
    > As of bisecting - it will require time do find the commit. I might do
    > it if I find some spare time.

    If nothing else works I'm happy to accept a patch turning the
    driver into a bool and removing all module handling code.


Before doing this I would love to get some feedback from the driver maintainer. Mathias, do you see this issue with the module?

Also I am going to change Arch Linux kernel config to compile this driver as 'y'.

I haven't been looking at this code for some time, Mika has mostly been taking care of it lately.

Driver was originally written as bool (not module) partly because we wanted it to load earlier as
we suspected some other drivers depend on gpio interrupts, and partly because the IO port resources
overlapped with motherboard resources that pnpacpi would request before gpio-lynxpoint.

As driver was written with the original assumption of not being a module, there
might be that the remove codepaths in gpio-lynxopoint are not properly calling
gpiochip_remove (that should call gpiochip_irqchip_remove etc) on driver unload,
or not checking if those return errors, or ourself not returning proper errors on removes that should fail.

An other possible issue could be that if hw reduced acpi stuff that expects os to have a interrupt handler for
gpio interrupts triggered in firmware. Not sure if that eneded up being used anywhere, but I can imagine there being issues
if we remove the interrupt handling for those.

Anyways, I don't mind turning it back to a bool, but I agree with Mika that we really should investigate the cause
behind this and not just do it because it removes the symptoms.

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux