On Wed, Sep 23, 2020 at 10:16 AM Linus Torvalds
wrote:
>
> But these two patches are very intentionally meant to be just "this
> clearly changes NO semantics at all".
The more I look at these, the more I go "this is a cleanup
regardless", so I'll just keep thes in my tree as-is.
On Mon, Sep 21, 2020 at 2:18 PM Peter Xu wrote:
>
> There's one special path for copy_one_pte() with swap entries, in which
> add_swap_count_continuation(GFP_ATOMIC) might fail. In that case we'll return
> the swp_entry_t so that the caller will release the locks and redo
On 09/22, Peter Xu wrote:
>
> On Tue, Sep 22, 2020 at 08:23:18PM +0200, Oleg Nesterov wrote:
> >
> > But I still think that !pte_none() -> pte_none() transition is not possible
> > under mmap_write_lock()...
> >
> > OK, let me repeat I don't understans these code paths enough, let me reword:
> > I
> > > thinking maybe I
> > > > > > should prepare a standalone patch to clear the swp_entry_t and cc
> > > > > > stable.
> > > > >
> > > > > Well, if copy_one_pte(src_pte) hits a swap entry and returns
> > > > > entry.val != 0, t
c in this patch, it probably
> > > > > means this
> > > > > bug is also in the original code before this series... I'm thinking
> > > > > maybe I
> > > > > should prepare a standalone patch to clear the swp_entry_t and cc
> >
his
> > > > bug is also in the original code before this series... I'm thinking
> > > > maybe I
> > > > should prepare a standalone patch to clear the swp_entry_t and cc
> > > > stable.
> > >
> > > Well, if copy_one_pte(src_pt
nking
> > > maybe I
> > > should prepare a standalone patch to clear the swp_entry_t and cc stable.
> >
> > Well, if copy_one_pte(src_pte) hits a swap entry and returns entry.val !=
> > 0, then
> > pte_none(*src_pte) is not possible after restart? This
patch to clear the swp_entry_t and cc stable.
>
> Well, if copy_one_pte(src_pte) hits a swap entry and returns entry.val != 0,
> then
> pte_none(*src_pte) is not possible after restart? This means that
> copy_one_pte()
> will be called at least once.
Note that we've relea
break;
> > > > }
> > > > +
> > > > if (addr != end)
> > > > goto again;
> > >
> > > After that the main loop can stop again because of need_resched(), and
> > > in this case add_swap_count_con
,
> >
> > > + default:
> > > + break;
> > > }
> > > +
> > > if (addr != end)
> > > goto again;
> >
> > After that the main loop can stop again because of need_resched(), and
> > in this case add_swap_co
On Tue, Sep 22, 2020 at 12:11:29AM -0700, John Hubbard wrote:
> On 9/21/20 2:17 PM, Peter Xu wrote:
> > There's one special path for copy_one_pte() with swap entries, in which
> > add_swap_count_continuation(GFP_ATOMIC) might fail. In that case we'll
> > return
o again;
>
> After that the main loop can stop again because of need_resched(), and
> in this case add_swap_count_continuation(data.entry) will be called again?
No, this is not possible, copy_one_pte() should be called at least once,
progress = 0 before restart. Sorry for noise.
Oleg.
On 09/21, Peter Xu wrote:
>
> @@ -866,13 +877,18 @@ static int copy_pte_range(struct mm_struct *dst_mm,
> struct mm_struct *src_mm,
> pte_unmap_unlock(orig_dst_pte, dst_ptl);
> cond_resched();
>
> - if (entry.val) {
> - if (add_swap_count_continuation(entry, GFP_KERNE
On 9/21/20 2:17 PM, Peter Xu wrote:
There's one special path for copy_one_pte() with swap entries, in which
add_swap_count_continuation(GFP_ATOMIC) might fail. In that case we'll return
I might be looking at the wrong place, but the existing code seems to call
add_swap_count_co
There's one special path for copy_one_pte() with swap entries, in which
add_swap_count_continuation(GFP_ATOMIC) might fail. In that case we'll return
the swp_entry_t so that the caller will release the locks and redo the same
thing with GFP_KERNEL.
It's confusing when copy_one_pt
On 03/04/07, Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
Daniel J Blueman wrote:
> On 13 Mar, 20:20, Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
>
>> I had a look at copy_one_pte().
>> I cannot see any ioproc_update_page() call, not even for the COW pages.
>> I
On 13 Mar, 20:20, Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
I had a look at copy_one_pte().
I cannot see any ioproc_update_page() call, not even for the COW pages.
Is it intentional?
There could be an ioproc_update_range() call in
memory.c:copy_pte_range(), after the pte_unmap_unlock(
Andrew Morton wrote:
(cc restored. Please always do reply-to-all).
On Wed, 14 Mar 2007 08:35:07 + Matt Keenan <[EMAIL PROTECTED]> wrote:
Christoph Hellwig wrote:
On Tue, Mar 13, 2007 at 08:15:25PM +0100, Zoltan Menyhart wrote:
I had a look at copy_one_pte().
I
(cc restored. Please always do reply-to-all).
> On Wed, 14 Mar 2007 08:35:07 + Matt Keenan <[EMAIL PROTECTED]> wrote:
> Christoph Hellwig wrote:
> > On Tue, Mar 13, 2007 at 08:15:25PM +0100, Zoltan Menyhart wrote:
> >
> >> I had a look at copy
Christoph Hellwig wrote:
On Tue, Mar 13, 2007 at 08:15:25PM +0100, Zoltan Menyhart wrote:
I had a look at copy_one_pte().
I cannot see any ioproc_update_page() call, not even for the COW pages.
Is it intentional?
There is no such thing as ioproc_update_page in any mainline tree.
You
On Tue, Mar 13, 2007 at 08:15:25PM +0100, Zoltan Menyhart wrote:
> I had a look at copy_one_pte().
> I cannot see any ioproc_update_page() call, not even for the COW pages.
> Is it intentional?
There is no such thing as ioproc_update_page in any mainline tree.
You must be looking at so
I had a look at copy_one_pte().
I cannot see any ioproc_update_page() call, not even for the COW pages.
Is it intentional?
We can live with a COW page for a considerably long time.
How could the IO-PROC. know that a process-ID / user virt. addr. pair
refers to the same page?
The comment above
22 matches
Mail list logo
