7

Sto scrivendo un modulo del kernel che deve essere chiamato dal processo p1 per sovrascrivere una pagina di dati che appartiene a un processo di destinazione p2., mentre viene chiamato da un processo, scrive su una pagina da un altro processo

Innanzitutto, all'interno del modulo del kernel e durante la risposta a un evento di scrittura sul file system proc emesso da p1. Ho usato l'id di processo del processo di destinazione (p2) per cercare la struttura del task di quest'ultimo (p2_task).

Per cercare la pagina specifica ho utilizzato get_user_pages(), ovviamente chiamandolo su (p2_task->mm). Ho quindi chiamato kmap() nella pagina restituita dalla funzione precedente. Una volta ottenuto il puntatore, ho usato le tipiche funzioni di memoria (memset()) per scrivere in quella memoria. Finalmente chiamato kunmap().

Tuttavia, una volta riavviato il processo, posso vedere che ciò che ho fatto non ha avuto alcun effetto sul processo di destinazione p2.

Non sono sicuro di cosa ho sbagliato. Qualcuno può aiutare?

Sospetto che in qualche modo non si possa scrivere in memoria appartiene al processo p2 mentre si risponde a una richiesta proveniente da p2. Poiché qui siamo in un contesto diverso.

È vero, se non altro che posso controllare. Se è il problema, c'è comunque che posso aggirare questo?

+1

mia comprensione che 'kmap()' restituisce un indirizzo virtuale (in basso mem) per una pagina fisica. Cioè se la pagina fisica ha già un indirizzo virtuale kernel-spazio 'kmap()' lo restituisce. Altrimenti rimappina la stessa pagina fisica in un indirizzo virtuale dello spazio del kernel e poi restituisce questo nuovo indirizzo virtuale. Quindi, non è necessaria una nuova pagina fisica. Si noti inoltre che il nuovo indirizzo virtuale viene creato all'interno dello spazio del kernel non all'interno di p2. – hebbo

+0

tutto viene eseguito dallo spazio del kernel. – hebbo

+0

Scusa, pensavo volessi p1 sovrascrivere p2. Vedo ora, si cita solo p1 per dire che è stato chiamato da un contesto utente diverso. Vedi http://makelinux.net/ldd3/chp-15-sect-3, che sta facendo ciò che hai delineato sopra. L'unica differenza che vedo è prendere/rilasciare mmap_sem e chiamare SetPageDirty(). –

risposta

0

Suona come un problema TLB per me, per cui p2 ha l'indirizzo virtuale dei dati memorizzati nella cache in hardware. P2 ha precedentemente letto/scritto la pagina nel suo spazio indirizzo prima che p1 cambi il valore?

provare a lanciare questo p1 dopo aver modificato il valore: flush_tlb_page(struct vm_area_struct * vma, unsigned long address)

Problemi correlati