linux-kernel - Re: [BUG] staging: android: ashmem: Deadlock during ashmem

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: <CAJsYZ5nQg9g73r5yLicq6gAGbKEXVAFqtF2av=heeNtrNSPSWg@mail.gmail.com>
Date:	Tue, 23 Apr 2013 21:50:34 +0530
From:	Shankar Brahadeeswaran <shankoo77@...il.com>
To:	Robert Love <rlove@...gle.com>
Cc:	Dan Carpenter <dan.carpenter@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Bjorn Bringert <bringert@...gle.com>,
	Al Viro <viro@...iv.linux.org.uk>, devel@...verdev.osuosl.org,
	Hugh Dickins <hughd@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Anjana V Kumar <anjanavk12@...il.com>
Subject: Re: [BUG] staging: android: ashmem: Deadlock during ashmem_shrink

>ashmem originally did not support read or write operations, just mmap,
>which is all 99% of users want. The original concurrency model with
>per-mapping ashmem_mutex's works fine there.

The situation I'm reporting here does not involve read/write. This is
to do with ashmem_mmap and ashmem_shrink.
The following is the control flow that could lead to dead lock
 ashmem_mmap
      |
      ----> ashmem_mutex acquired
      |
      -----> shmem_file_setup
                |
                ------> several calls that leads to __alloc_pages
                |     Now assuming that low memory condition is hit,
we could enter into reclaim path
                ..... ---------> shrink_slab (calls all the shrinker functions)
                   |
                    -----> ashmem_shrink --- Tries to acquire the same
ashmem_mutex that is taken
                              in this same path while in ashmem_mmap
leading to dead lock.

I'm unable to think of a straight forward way to fix this. If you have
any suggestions please provide the same.
If we are unable to solve this too with minor mods, as suggested by
Dan we have to re-look at the locking in this driver.

Warm Regards,
Shankar


On Mon, Apr 22, 2013 at 8:13 PM, Robert Love <rlove@...gle.com> wrote:
> On Mon, Apr 22, 2013 at 10:22 AM, Dan Carpenter
> <dan.carpenter@...cle.com> wrote:
>> Read Al's email again:  https://lkml.org/lkml/2013/3/20/458
>>
>> I don't know much about VFS locking, but the ashmem locking seems
>> pretty bogus to me.  Why can't multiple threads read() at the same
>> time?
>
> ashmem originally did not support read or write operations, just mmap,
> which is all 99% of users want. The original concurrency model with
> per-mapping ashmem_mutex's works fine there. It is only with the later
> addition of read and write that locking becomes a cluster. If there
> isn't an obvious way to refactor the locking, I'd suggest removing
> read and write.
>
>        Robert
--
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/