сбой системных вызовов для iomapped памяти в Linux. - PullRequest
4 голосов
/ 30 марта 2012

Я отображаю некоторую память в vmalloced области в драйвере.Я также делюсь этой областью с пользовательскими процессами, используя флаг (PAGE_SHARED в ioremap_page_range).

Теперь я могу получить доступ к этой общей памяти в пространстве пользователя.Я могу писать и читать в эту память.Однако, если я передаю эту память в качестве буфера системным вызовам, таким как recv или send, то вызовы завершаются неудачно из-за плохой памяти (Memory not mapped into user process).

Однако я уверен, что мой буфер неесть какие-то проблемы.Таким образом, кажется, что существует некоторый конфликт в том, как я делю память и проверяю ошибки для системных вызовов.

код драйвера:

shared_buf = __get_vm_area(size, VM_IOREMAP, VMALLOCS_START, VMALLOC_END); 
ioremap_page_range(shared_buf->addr, size, phy_addr_of_io, PAGE_SHARED);      

После этого я делаю вызов ioctl и передаю этот shared_buf-> addr приложению пространства пользователя.
Я пишу и читаю, используя этот адрес.Затем я делаю

ret = recv(sockfd, shared_buf->area, 0) and I get an error "bad addr".   

Вместо этого, если я пытаюсь

ret = recv(sockfd, local_buf, size, 0);  
memcpy(shared_buf->addr, local_buf, size); Then it goes without issues.   

(Отказ от ответственности: я использую shared_buf->area в потоках, которые не сделали IOCTL. Однако это то же самоепроцесс.)

Кто-нибудь может увидеть ошибку?

1 Ответ

3 голосов
/ 30 марта 2012

Все системные вызовы подтверждают, что переданный указатель находится в пользовательской части адресного пространства. vmalloc space не находится в этой пользовательской части; следовательно, вы не можете использовать его для системных вызовов. Что еще более важно, не предоставляйте пользовательским процессам прямой доступ к памяти в адресном пространстве vmalloc. Это просто напрашивается на неприятности. И, вероятно, ужасно небезопасно - могут ли другие процессы получить к нему доступ? Напишите mmapable файл вместо .

...