On Tue, Apr 16, 2019 at 04:33:51PM -0700, Andrew Morton wrote:
Sorry for the delay, I was on vacation all last week.
> What's the status of this patchset, btw?
>
> I have a note here that
> powerpc-mmu-drop-mmap_sem-now-that-locked_vm-is-atomic.patch is to be
> updated.
Yes, the series needs a
On Thu, 11 Apr 2019 16:28:07 -0400 Daniel Jordan
wrote:
> On Thu, Apr 11, 2019 at 10:55:43AM +0100, Mark Rutland wrote:
> > On Thu, Apr 11, 2019 at 02:22:23PM +1000, Alexey Kardashevskiy wrote:
> > > On 03/04/2019 07:41, Daniel Jordan wrote:
> >
> > > > - dev_dbg(dev, "[%d]
On Thu, Apr 11, 2019 at 10:55:43AM +0100, Mark Rutland wrote:
> On Thu, Apr 11, 2019 at 02:22:23PM +1000, Alexey Kardashevskiy wrote:
> > On 03/04/2019 07:41, Daniel Jordan wrote:
>
> > > - dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %ld/%ld%s\n", current->pid,
> > > + dev_dbg(dev, "[%d]
On Thu, Apr 11, 2019 at 02:22:23PM +1000, Alexey Kardashevskiy wrote:
> On 03/04/2019 07:41, Daniel Jordan wrote:
> > - dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %ld/%ld%s\n", current->pid,
> > + dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %lld/%lu%s\n", current->pid,
> > incr ? '+' :
On 03/04/2019 07:41, Daniel Jordan wrote:
> Taking and dropping mmap_sem to modify a single counter, locked_vm, is
> overkill when the counter could be synchronized separately.
>
> Make mmap_sem a little less coarse by changing locked_vm to an atomic,
> the 64-bit variety to avoid issues with
On Tue, Apr 02, 2019 at 04:43:57PM -0700, Davidlohr Bueso wrote:
> On Tue, 02 Apr 2019, Andrew Morton wrote:
>
> > Also, we didn't remove any down_write(mmap_sem)s from core code so I'm
> > thinking that the benefit of removing a few mmap_sem-takings from a few
> > obscure drivers (sorry ;)) is
On Wed, Apr 03, 2019 at 06:46:07AM +0200, Christophe Leroy wrote:
>
>
> Le 02/04/2019 à 22:41, Daniel Jordan a écrit :
> > Taking and dropping mmap_sem to modify a single counter, locked_vm, is
> > overkill when the counter could be synchronized separately.
> >
> > Make mmap_sem a little less
On Tue, Apr 02, 2019 at 03:04:24PM -0700, Andrew Morton wrote:
> On Tue, 2 Apr 2019 16:41:53 -0400 Daniel Jordan
> wrote:
> > static long kvmppc_account_memlimit(unsigned long stt_pages, bool inc)
> > {
> > long ret = 0;
> > + s64 locked_vm;
> >
> > if (!current || !current->mm)
>
Le 02/04/2019 à 22:41, Daniel Jordan a écrit :
Taking and dropping mmap_sem to modify a single counter, locked_vm, is
overkill when the counter could be synchronized separately.
Make mmap_sem a little less coarse by changing locked_vm to an atomic,
the 64-bit variety to avoid issues with
On Tue, 02 Apr 2019, Andrew Morton wrote:
Also, we didn't remove any down_write(mmap_sem)s from core code so I'm
thinking that the benefit of removing a few mmap_sem-takings from a few
obscure drivers (sorry ;)) is pretty small.
afaik porting the remaining incorrect users of locked_vm to
On Tue, 2 Apr 2019 16:41:53 -0400 Daniel Jordan
wrote:
> Taking and dropping mmap_sem to modify a single counter, locked_vm, is
> overkill when the counter could be synchronized separately.
>
> Make mmap_sem a little less coarse by changing locked_vm to an atomic,
> the 64-bit variety to
Taking and dropping mmap_sem to modify a single counter, locked_vm, is
overkill when the counter could be synchronized separately.
Make mmap_sem a little less coarse by changing locked_vm to an atomic,
the 64-bit variety to avoid issues with overflow on 32-bit systems.
Signed-off-by: Daniel
12 matches
Mail list logo
