linux-kernel - Re: [RFT v3] eata: Convert eata driver as normal PCI and platform device drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 26 Sep 2015 15:57:03 +0930
From:	Arthur Marsh <arthur.marsh@...ernode.on.net>
To:	Jiang Liu <jiang.liu@...ux.intel.com>,
	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Hannes Reinecke <hare@...e.de>,
	Ballabio Dario <dario.ballabio@....com>,
	Christoph Hellwig <hch@...radead.org>,
	Dario Ballabio <ballabio_dario@....com>,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-scsi@...r.kernel.org, x86@...nel.org
Subject: Re: [RFT v3] eata: Convert eata driver as normal PCI and platform
 device drivers

Arthur Marsh wrote on 24/09/15 15:26:
>
>
> Jiang Liu wrote on 24/09/15 13:58:
>
>> Hi James,
>>     Thanks for review. How about the attached patch which addresses
>> the three suggestions from you?
>> Thanks!
>> Gerry
>
> I've applied the patch, rebuilt the kernel and verified that it allows
> unloading of the eata module and reloading it, as well as a successful
> kexec.
>
> Regards,
>
> Arthur.

After some more thorough testing I've encountered an ongoing problem 
trying to use kexec with filesystems mounted with the eata driver.

If I boot up and have the eata driver loaded but no filesystem check or 
mounting of filesystems on the disk attached to the DPT2044W controller, 
then attempt a kexec reboot I get the reboot pausing after the 
"synchronizing scsi cache" messages and getting the errors that I have 
included as pictures in my previous reports.

If I do a normal boot which includes eata being loaded, the disk 
attached to the DPT2044W controller having its filesystems checked and 
mounted, then attempt a kexec reboot, I get the reboot pausing after the 
"synchronizing SCSI cache" messages as before.

If I un-mount the filesystems on the disk attached to the DPT2044W 
controller after start-up and try a reboot I get the same problem.

If I do modprobe -r eata after un-mounting the filesystems on the disk 
attached to the DPT2044W controller after a start-up kexec *works fine*.

If I do:

start-up
un-mount filesystems on disk attached to DPT2044W controller
modprobe -r eata
modprobe eata
fsck -a of filesystems on disk attached to DPT2044W controller
mount filesystems

then a kexec reboot works fine.

I did some more experimenting and found a workaround:

I was unable to blacklist the eata module but if I did:

modprobe -r eata
modprobe eata

in a cron job before the fsck and mount commands then
I could then perform a kexec reboot successfully.

I also verified that if I did:

modprobe -r eata

after eata was loaded on boot-up without any fsck or mounting of 
filesystems on the disk attached to the DPT2044W controller using the 
eata the kexec reboot worked fine.

In summary:

if eata is loaded kexec reboot will fail unless a modprobe -r eata is 
done either manually or by a cron job.

if a modprobe -r eata has been done, then even if I modprobe eata and 
fsck and mount filesystems, kexec reboot works.

Any suggestions for further tests or checks welcome.

Arthur.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/