On 08/22/2018 02:56 PM, owner-linux...@kvack.org wrote:
>
>
> On 8/22/18 2:42 PM, Dave Hansen wrote:
>> On 08/22/2018 02:10 PM, Kirill A. Shutemov wrote:
For x86, mpx_notify_unmap() looks finally zap the VM_MPX vmas in
bound table
range with zap_page_range() and doesn't update vm
On 08/22/2018 02:56 PM, owner-linux...@kvack.org wrote:
>
>
> On 8/22/18 2:42 PM, Dave Hansen wrote:
>> On 08/22/2018 02:10 PM, Kirill A. Shutemov wrote:
For x86, mpx_notify_unmap() looks finally zap the VM_MPX vmas in
bound table
range with zap_page_range() and doesn't update vm
On 8/22/18 2:42 PM, Dave Hansen wrote:
On 08/22/2018 02:10 PM, Kirill A. Shutemov wrote:
For x86, mpx_notify_unmap() looks finally zap the VM_MPX vmas in bound table
range with zap_page_range() and doesn't update vm flags, so it sounds ok to
me since vmas have been detached, nobody can find
On 8/22/18 2:42 PM, Dave Hansen wrote:
On 08/22/2018 02:10 PM, Kirill A. Shutemov wrote:
For x86, mpx_notify_unmap() looks finally zap the VM_MPX vmas in bound table
range with zap_page_range() and doesn't update vm flags, so it sounds ok to
me since vmas have been detached, nobody can find
On 08/22/2018 02:10 PM, Kirill A. Shutemov wrote:
>> For x86, mpx_notify_unmap() looks finally zap the VM_MPX vmas in bound table
>> range with zap_page_range() and doesn't update vm flags, so it sounds ok to
>> me since vmas have been detached, nobody can find those vmas. But, I'm not
>> familiar
On 08/22/2018 02:10 PM, Kirill A. Shutemov wrote:
>> For x86, mpx_notify_unmap() looks finally zap the VM_MPX vmas in bound table
>> range with zap_page_range() and doesn't update vm flags, so it sounds ok to
>> me since vmas have been detached, nobody can find those vmas. But, I'm not
>> familiar
On Wed, Aug 22, 2018 at 01:45:44PM -0700, Yang Shi wrote:
>
>
> On 8/22/18 4:19 AM, Vlastimil Babka wrote:
> > On 08/15/2018 08:49 PM, Yang Shi wrote:
> > > + downgrade_write(>mmap_sem);
> > > +
> > > + /* Zap mappings with read mmap_sem */
> > > + unmap_region(mm, start_vma, prev, start, end);
On Wed, Aug 22, 2018 at 01:45:44PM -0700, Yang Shi wrote:
>
>
> On 8/22/18 4:19 AM, Vlastimil Babka wrote:
> > On 08/15/2018 08:49 PM, Yang Shi wrote:
> > > + downgrade_write(>mmap_sem);
> > > +
> > > + /* Zap mappings with read mmap_sem */
> > > + unmap_region(mm, start_vma, prev, start, end);
On 8/22/18 4:19 AM, Vlastimil Babka wrote:
On 08/15/2018 08:49 PM, Yang Shi wrote:
+ downgrade_write(>mmap_sem);
+
+ /* Zap mappings with read mmap_sem */
+ unmap_region(mm, start_vma, prev, start, end);
+
+ arch_unmap(mm, start_vma, start, end);
Hmm, did you check
On 8/22/18 4:19 AM, Vlastimil Babka wrote:
On 08/15/2018 08:49 PM, Yang Shi wrote:
+ downgrade_write(>mmap_sem);
+
+ /* Zap mappings with read mmap_sem */
+ unmap_region(mm, start_vma, prev, start, end);
+
+ arch_unmap(mm, start_vma, start, end);
Hmm, did you check
On 8/22/18 4:11 AM, Vlastimil Babka wrote:
On 08/15/2018 08:49 PM, Yang Shi wrote:
+ start_vma = munmap_lookup_vma(mm, start, end);
+ if (!start_vma)
+ goto out;
+ if (IS_ERR(start_vma)) {
+ ret = PTR_ERR(start_vma);
+ goto out;
+
On 8/22/18 4:11 AM, Vlastimil Babka wrote:
On 08/15/2018 08:49 PM, Yang Shi wrote:
+ start_vma = munmap_lookup_vma(mm, start, end);
+ if (!start_vma)
+ goto out;
+ if (IS_ERR(start_vma)) {
+ ret = PTR_ERR(start_vma);
+ goto out;
+
On 08/15/2018 08:49 PM, Yang Shi wrote:
> + downgrade_write(>mmap_sem);
> +
> + /* Zap mappings with read mmap_sem */
> + unmap_region(mm, start_vma, prev, start, end);
> +
> + arch_unmap(mm, start_vma, start, end);
Hmm, did you check that all architectures' arch_unmap() is safe
On 08/15/2018 08:49 PM, Yang Shi wrote:
> + downgrade_write(>mmap_sem);
> +
> + /* Zap mappings with read mmap_sem */
> + unmap_region(mm, start_vma, prev, start, end);
> +
> + arch_unmap(mm, start_vma, start, end);
Hmm, did you check that all architectures' arch_unmap() is safe
On 08/15/2018 08:49 PM, Yang Shi wrote:
> + start_vma = munmap_lookup_vma(mm, start, end);
> + if (!start_vma)
> + goto out;
> + if (IS_ERR(start_vma)) {
> + ret = PTR_ERR(start_vma);
> + goto out;
> + }
> +
> + prev = start_vma->vm_prev;
>
On 08/15/2018 08:49 PM, Yang Shi wrote:
> + start_vma = munmap_lookup_vma(mm, start, end);
> + if (!start_vma)
> + goto out;
> + if (IS_ERR(start_vma)) {
> + ret = PTR_ERR(start_vma);
> + goto out;
> + }
> +
> + prev = start_vma->vm_prev;
>
On 8/15/18 7:46 PM, Matthew Wilcox wrote:
On Wed, Aug 15, 2018 at 02:54:13PM -0700, Yang Shi wrote:
On 8/15/18 2:09 PM, Matthew Wilcox wrote:
On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
(not even compiled, and I can see a good opportunity for combining the
VM_LOCKED
On 8/15/18 7:46 PM, Matthew Wilcox wrote:
On Wed, Aug 15, 2018 at 02:54:13PM -0700, Yang Shi wrote:
On 8/15/18 2:09 PM, Matthew Wilcox wrote:
On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
(not even compiled, and I can see a good opportunity for combining the
VM_LOCKED
On Wed, Aug 15, 2018 at 02:54:13PM -0700, Yang Shi wrote:
>
>
> On 8/15/18 2:09 PM, Matthew Wilcox wrote:
> > On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
> > > (not even compiled, and I can see a good opportunity for combining the
> > > VM_LOCKED loop with the has_uprobes
On Wed, Aug 15, 2018 at 02:54:13PM -0700, Yang Shi wrote:
>
>
> On 8/15/18 2:09 PM, Matthew Wilcox wrote:
> > On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
> > > (not even compiled, and I can see a good opportunity for combining the
> > > VM_LOCKED loop with the has_uprobes
On 8/15/18 2:09 PM, Matthew Wilcox wrote:
On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
(not even compiled, and I can see a good opportunity for combining the
VM_LOCKED loop with the has_uprobes loop)
I was rushing to get that sent earlier. Here it is tidied up to
On 8/15/18 2:09 PM, Matthew Wilcox wrote:
On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
(not even compiled, and I can see a good opportunity for combining the
VM_LOCKED loop with the has_uprobes loop)
I was rushing to get that sent earlier. Here it is tidied up to
On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
> (not even compiled, and I can see a good opportunity for combining the
> VM_LOCKED loop with the has_uprobes loop)
I was rushing to get that sent earlier. Here it is tidied up to
actually compile.
Note the diffstat:
mmap.c |
On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
> (not even compiled, and I can see a good opportunity for combining the
> VM_LOCKED loop with the has_uprobes loop)
I was rushing to get that sent earlier. Here it is tidied up to
actually compile.
Note the diffstat:
mmap.c |
On Thu, Aug 16, 2018 at 02:49:48AM +0800, Yang Shi wrote:
> +static int do_munmap_zap_rlock(struct mm_struct *mm, unsigned long start,
> +size_t len, struct list_head *uf)
> +{
> + unsigned long end;
> + struct vm_area_struct *start_vma, *prev, *vma;
> + int
On Thu, Aug 16, 2018 at 02:49:48AM +0800, Yang Shi wrote:
> +static int do_munmap_zap_rlock(struct mm_struct *mm, unsigned long start,
> +size_t len, struct list_head *uf)
> +{
> + unsigned long end;
> + struct vm_area_struct *start_vma, *prev, *vma;
> + int
When running some mmap/munmap scalability tests with large memory (i.e.
> 300GB), the below hung task issue may happen occasionally.
INFO: task ps:14018 blocked for more than 120 seconds.
Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1
"echo 0 >
When running some mmap/munmap scalability tests with large memory (i.e.
> 300GB), the below hung task issue may happen occasionally.
INFO: task ps:14018 blocked for more than 120 seconds.
Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1
"echo 0 >
28 matches
Mail list logo
