Re: [RFT v5h printk: allow increasing the ring buffer depending on the number of CPUs

["Luis R. Rodriguez" <mcgrof@suse.com>]

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