linux-kernel - Re: [PATCH 0/2] blackfin: ptrace mm/sram

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <AANLkTik5mWPysArnlyZKdnjUxNzyde8myKCbTvxJIj8G@mail.gmail.com>
Date:	Thu, 27 May 2010 16:21:04 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>, linux-sh@...r.kernel.org,
	uclinux-dist-devel@...ckfin.uclinux.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] blackfin: ptrace mm/sram_list fixes

On Thu, May 27, 2010 at 15:55, Oleg Nesterov wrote:
> On 05/26, Oleg Nesterov wrote:
>> On 05/25, Mike Frysinger wrote:
>> > we probably should add proper locking to this
>> > structure though.
>>
>> Agreed. I'll try to make the trivial patch tomorrow. I think we
>> can just use mm->mmap_sem, is_user_addr_valid() needs this lock
>> for find_vma() anyway.
>
> please see the patches.

awesome !  wasnt expecting someone to do the work for us :).

> UNTESTED! the second one certainly needs the review from someone
> who knows what this code does ;)

np.  after i look them over, i'll suck them into the Blackfin tree and
let them settle for a release for our test suites to shake out
problems.

> BTW. Obviously sys_sram_alloc() can create multiple sram_list_struct
> nodes with the same ->addr (with or without this patch), I hope this
> is fine.

how so ?  Blackfin is a nommu arch, so there should be no aliasing
issues.  each of the individual L1 sub-allocators manage a different
address range, and none of those should return an address that is
already in use.  it could happen that the code calling these funcs
calls a free func directly instead of going through the lsl free, but
that's a bug in the usage, not this code.
-mike
--
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/