linux-kernel - Re: A question about state machine function state

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:	Mon, 1 Jun 2015 08:42:38 +0200
From:	Joerg Roedel <joro@...tes.org>
To:	Baoquan He <bhe@...hat.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: A question about state machine function state_next()

Hi Baoquan,

On Mon, Jun 01, 2015 at 11:09:40AM +0800, Baoquan He wrote:
> I am reading amd iommu code because I have some knowledge about intel
> iommu since review Zhenhua's fixing kdump error patches. Now there's
> a question I didn't find answer.
> 
> In amd iommu state_next() is the state machine running function. However
> I only found 4 function to call iommu_go_to_state() to change the state,
> they are:
> amd_iommu_detect()
> amd_iommu_prepare()
> amd_iommu_enable()
> amd_iommu_init()
> 
> And they are called according to above sequence. It means only below 4
> cases are checked and the code blocks are executed. Then where to call
> amd_iommu_enable_interrupts() and amd_iommu_init_dma(). Could you help
> to tell what I missed?
> 
> static int __init state_next(void)
> {
> 	int ret = 0;
> 
> 	switch (init_state) {
> 	case IOMMU_START_STATE:     //checked and execute
> 	case IOMMU_IVRS_DETECTED:   //checked and execute
> 	case IOMMU_ACPI_FINISHED:   //checked and execute
> 	case IOMMU_ENABLED:         //checked and execute
> 	...
> }

Yes, it is right that only these four states are used as exit-states for
the functions above. The other states are not really needed, but the
work done is these steps is. Originally my idea was to use the
intermedite states to see where initialization failed, but that is
easier to achieve elsewhere.

So this has been on my list of things to clean up, just didn't got
around to do it yet.


	Joerg

--
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/