Confira !!
Assunto : Re: [PATCH 3/5] mm / mremap: use pmd_addr_end para calcular o próximo em move_page_tables ()
De : Russell King - administrador do ARM Linux <linux @ xxxxxxxxxxxxxxx>
Data : Wed, 29 Jan 2020 09:47:38 +0000
Em resposta a : < 7147774a-14e9-4ff3-1548-4565f0d214d5@gmail.com >
Agente do usuário : Mutt / 1.10.1 (13-07-2018)
Em Domingo, 26 de janeiro de 2020 às 05:47:57 +0300, Dmitry Osipenko escreveu:
> 2020/01/18 02:22, Wei Yang пишет:
> > Use o ajudante geral em vez de fazê-lo com a mão.
> >
> > Assinado-off-by: Wei Yang <richardw.yang@xxxxxxxxxxxxxxx>
> > ---
> > mm / mremap.c | 7 ++ -----
> > um ficheiro alterados, 2 inserções (+), 5 deleções (-)
> >
> > dif --git um / mm / mremap.cb / mm / mremap.c
> > c2af8ba4ba43 índice ..a258914f3ee1 100644
> > --- uma / mm / mremap.c
> > +++ b / mm / mremap.c
> > @@ -253,11 +253,8 @@ unsigned longos move_page_tables (vm_area_struct struct * vma ,
>> Para (; old_addr <OLD_END; old_addr + = extensão, new_addr + = extensão) {
> > cond_resched ();
>> - próximo = (antigo_addr + PMD_SIZE) & PMD_MASK;
> > - / * mesmo se próxima transbordou, medida abaixo será ok * /
> > + next = pmd_addr_end (old_addr, OLD_END);
>> extensão = próximo - antigo_addr;
> > - if (grau> OLD_END - old_addr)
> > - medida = OLD_END - old_addr;
>> old_pmd = get_old_pmd (vma-> vm_mm, old_addr);
> > If (old_pmd!)
> > Continuar;
>> @@ -301,7 +298,>
> > If (pte_alloc (new_vma-> vm_mm, new_pmd))
> > break;
>> - próximo = (novo_addr + PMD_SIZE) & PMD_MASK;
>> + próximo = pmd_addr_end (novo_addr, novo_addr + len);
> > If (grau> next - new_addr)
> > medida = next - new_addr;
> > Move_ptes (VMA, old_pmd, old_addr, old_addr + medida, new_vma,
> >
>
> Olá Wei,
>
> Começando com a próxima 20200122, eu estou vendo o seguinte em kmsg em NVIDIA
> Tegra (ARM32):
>
> BUG :
>
> E trava, eventualmente, do kernel.
>
> Do Git pontos bissecção para este patch e reverter isso ajuda. Por favor, corrija,
> obrigado antecipadamente.
O exposto acima está definitivamente errado - pXX_addr_end () foi projetado para ser usado
com um índice de endereço na tabela da tabela pXX e o índice de endereço
da última entrada na mesma tabela pXX ou do início do
_próxima_ tabela pXX. Indicações de endereço final arbitrário não são permitidas.
Quando as tabelas de páginas são "acumuladas" quando os níveis não existem, é comum
prática para essas macros apenas retornarem seu índice de endereço final.
Portanto, se eles são usados com indicações de endereços finais arbitrários, o
a iteração falhará.
A única maneira de fazer isso é:
next = pmd_addr_end (old_addr,
pud_addr_end (old_addr,
p4d_addr_end (old_addr,
pgd_addr_end (old_addr, old_end))));
que fornece pmd_addr_end () (e cada um dos intermediários pXX_addr_end ())
o argumento final correto. No entanto, isso é mais complexo e detalhado,
e provavelmente menos eficiente que o código atual.
Eu sugeriria que não há nada para "consertar" no código v5.5,
e tentar "limpá-lo" resultará em menos eficiência ou
código quebrado.
-
Sistema de correção do RMK: https://www.armlinux.org.uk/developer/patches/
Banda larga FTTC para linha de 0,8 milhas nos subúrbios: sincronização de 12,1 Mbps abaixo de 622kbps
De acordo com o speedtest.net: 11,9 Mbps abaixo de 500kbps
_______________________________________________
lista de discussão linux-arm-kernel
linux-arm-kernel @ xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Fonte
Até a próxima !!
Nenhum comentário:
Postar um comentário