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
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
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
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
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
__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:
__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:
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
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
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
10 matches
Mail list logo