Re: [tip:perfcounters/core] x86: Add NMI types for kmap_atomic

[Ingo Molnar]

* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> +static int kmap_type_to_context(enum km_type type)
> +{
> +	switch (type) {
> +	case KM_BOUNCE_READ:
> +		return KM_CTX_USER;
> +	case KM_SKB_SUNRPC_DATA:
> +		return KM_CTX_USER;
> +	case KM_SKB_DATA_SOFTIRQ:
> +		return KM_CTX_SOFTIRQ;
> +	case KM_USER0:
> +		return KM_CTX_USER;
> +	case KM_USER1:
> +		return KM_CTX_USER;
> +	case KM_BIO_SRC_IRQ:
> +		return KM_CTX_IRQ;
> +	case KM_BIO_DST_IRQ:
> +		return KM_CTX_IRQ;
> +	case KM_PTE0:
> +		return KM_CTX_USER;
> +	case KM_PTE1:
> +		return KM_CTX_USER;
> +	case KM_IRQ0:
> +		return KM_CTX_IRQ;
> +	case KM_IRQ1:
> +		return KM_CTX_IRQ;
> +	case KM_SOFTIRQ0:
> +		return KM_CTX_SOFTIRQ;
> +	case KM_SOFTIRQ1:
> +		return KM_CTX_SOFTIRQ;
> +	case KM_NMI:
> +		return KM_CTX_NMI;
> +	case KM_NMI_PTE:
> +		return KM_CTX_NMI;
> +	}
> +
> +	return KM_CTX_MAX;

why not do a very simple stack of atomic kmaps, like Hugh suggested?

That would mean a much simpler interface:

	kaddr = kmap_atomic(page);

no index needed. The kunmap pops the entry off the stack:

	kunmap_atomic(kaddr);

This becomes simpler too.

Now, a stack can be overflown by imbalance - but that's easy to 
detect and existing entries are easily printed and thus the source 
of the leak is easily identified.

In my book this design beats the current enumeration of kmap types 
indices hands down ... It would likely be much more robust as well, 
and much more easy to extend.

Am i missing any subtlety?

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