[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140618183145.GM4841@wotan.suse.de>
Date: Wed, 18 Jun 2014 20:31:45 +0200
From: "Luis R. Rodriguez" <mcgrof@...e.com>
To: Petr Mládek <pmladek@...e.cz>
Cc: "Luis R. Rodriguez" <mcgrof@...not-panic.com>, hpa@...ux.intel.com,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
Michal Hocko <mhocko@...e.cz>, Joe Perches <joe@...ches.com>,
Arun KS <arunks.linux@...il.com>,
Kees Cook <keescook@...omium.org>,
Davidlohr Bueso <davidlohr@...com>,
Chris Metcalf <cmetcalf@...era.com>
Subject: Re: [RFT v5h printk: allow increasing the ring buffer depending on
the number of CPUs
On Wed, Jun 18, 2014 at 04:21:45PM +0200, Petr Mládek wrote:
> On Wed 2014-06-18 12:59:26, Luis R. Rodriguez wrote:
> > On Wed, Jun 18, 2014 at 10:31:02AM +0200, Petr Mládek wrote:
> > > On Wed 2014-06-18 02:18:16, Luis R. Rodriguez wrote:
> > > I am happy with this solution. And I agree that it is better to split
> > > log_buf_len_align() in a separate patch as you suggested in the other
> > > mail.
> >
> > OK just to be on safe side I noticed memblock_virt_alloc() and
> > memblock_virt_alloc_nopanic() allow passing an explicit alignment
> > requirement, traced back the orignal code with no good reason to
> > not use the LOG_ALIGN, so I think using that would be the safest
> > thing to do. Will roll that into the first patch, curious if the
> > folks that ran into the alignment issues on ARM could reproduce
> > an align barf without this on some situations, perhaps not because
> > of the power of 2 thing and since the min value for LOG_BUF_SHIFT
> > is 12.
>
> Great catch. It makes sense to me. There is no reason to have aligned
> stores when the buffer itself is not properly aligned.
>
> IMHO, it would make sense to have separate patch for this change. It might be
> candidate for stable releases.
OK thanks for the review and all your help, I'll split that up into another
patch, so it'll be 3 total.
Luis
--
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/
Powered by blists - more mailing lists