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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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/