Re: [PATCH v2] mm: BUG when __kmap_atomic_idx equals KM_TYPE_NR

2014-08-04 Thread Chintan Pandya
On 08/01/2014 04:15 AM, Andrew Morton wrote: On Thu, 31 Jul 2014 14:58:58 +0530 Chintan Pandya wrote: I think Andrew's comment earlier was referring to the changelog only and not the patch, which looked correct. I think Andrew asked for a BUG case details also to justify the overhead. But

Re: [PATCH v2] mm: BUG when __kmap_atomic_idx equals KM_TYPE_NR

2014-08-04 Thread Chintan Pandya
On 08/01/2014 04:15 AM, Andrew Morton wrote: On Thu, 31 Jul 2014 14:58:58 +0530 Chintan Pandyacpan...@codeaurora.org wrote: I think Andrew's comment earlier was referring to the changelog only and not the patch, which looked correct. I think Andrew asked for a BUG case details also to

Re: [PATCH v2] mm: BUG when __kmap_atomic_idx equals KM_TYPE_NR

2014-07-31 Thread Andrew Morton
On Thu, 31 Jul 2014 14:58:58 +0530 Chintan Pandya wrote: > > > > I think Andrew's comment earlier was referring to the changelog only and > > not the patch, which looked correct. > > I think Andrew asked for a BUG case details also to justify the > overhead. But we have never encountered that

Re: [PATCH v2] mm: BUG when __kmap_atomic_idx equals KM_TYPE_NR

2014-07-31 Thread Chintan Pandya
On 07/31/2014 12:32 PM, David Rientjes wrote: On Thu, 31 Jul 2014, Chintan Pandya wrote: __kmap_atomic_idx is per_cpu variable. Each CPU can use KM_TYPE_NR entries from FIXMAP i.e. from 0 to KM_TYPE_NR - 1. Allowing __kmap_atomic_idx to over- shoot to KM_TYPE_NR can mess up with next CPU's 0th

Re: [PATCH v2] mm: BUG when __kmap_atomic_idx equals KM_TYPE_NR

2014-07-31 Thread David Rientjes
On Thu, 31 Jul 2014, Chintan Pandya wrote: > __kmap_atomic_idx is per_cpu variable. Each CPU can > use KM_TYPE_NR entries from FIXMAP i.e. from 0 to > KM_TYPE_NR - 1. Allowing __kmap_atomic_idx to over- > shoot to KM_TYPE_NR can mess up with next CPU's 0th > entry which is a bug. Hence BUG_ON if

[PATCH v2] mm: BUG when __kmap_atomic_idx equals KM_TYPE_NR

2014-07-31 Thread Chintan Pandya
__kmap_atomic_idx is per_cpu variable. Each CPU can use KM_TYPE_NR entries from FIXMAP i.e. from 0 to KM_TYPE_NR - 1. Allowing __kmap_atomic_idx to over- shoot to KM_TYPE_NR can mess up with next CPU's 0th entry which is a bug. Hence BUG_ON if __kmap_atomic_idx >= KM_TYPE_NR. Signed-off-by:

[PATCH v2] mm: BUG when __kmap_atomic_idx equals KM_TYPE_NR

2014-07-31 Thread Chintan Pandya
__kmap_atomic_idx is per_cpu variable. Each CPU can use KM_TYPE_NR entries from FIXMAP i.e. from 0 to KM_TYPE_NR - 1. Allowing __kmap_atomic_idx to over- shoot to KM_TYPE_NR can mess up with next CPU's 0th entry which is a bug. Hence BUG_ON if __kmap_atomic_idx = KM_TYPE_NR. Signed-off-by:

Re: [PATCH v2] mm: BUG when __kmap_atomic_idx equals KM_TYPE_NR

2014-07-31 Thread David Rientjes
On Thu, 31 Jul 2014, Chintan Pandya wrote: __kmap_atomic_idx is per_cpu variable. Each CPU can use KM_TYPE_NR entries from FIXMAP i.e. from 0 to KM_TYPE_NR - 1. Allowing __kmap_atomic_idx to over- shoot to KM_TYPE_NR can mess up with next CPU's 0th entry which is a bug. Hence BUG_ON if

Re: [PATCH v2] mm: BUG when __kmap_atomic_idx equals KM_TYPE_NR

2014-07-31 Thread Chintan Pandya
On 07/31/2014 12:32 PM, David Rientjes wrote: On Thu, 31 Jul 2014, Chintan Pandya wrote: __kmap_atomic_idx is per_cpu variable. Each CPU can use KM_TYPE_NR entries from FIXMAP i.e. from 0 to KM_TYPE_NR - 1. Allowing __kmap_atomic_idx to over- shoot to KM_TYPE_NR can mess up with next CPU's 0th

Re: [PATCH v2] mm: BUG when __kmap_atomic_idx equals KM_TYPE_NR

2014-07-31 Thread Andrew Morton
On Thu, 31 Jul 2014 14:58:58 +0530 Chintan Pandya cpan...@codeaurora.org wrote: I think Andrew's comment earlier was referring to the changelog only and not the patch, which looked correct. I think Andrew asked for a BUG case details also to justify the overhead. But we have never