romez777

Комментарии к функции дважды это упоминают: /** * __pskb_pull_tail - advance tail of skb header * ... * All the pointers pointing into skb header may change and must be * reloaded after call to this function. */ /* Moves tail of skb head forward, copying data from fragmented part, * when it is necessary. * 1. It may fail due to malloc failure. * 2. It may change skb pointers. * ... */ Функция изменяет как минимум два указателя, tail и data_len, это видно из кода. Такого правила, "высеченного в камне", нет. Использование функций с "__" префиксом широко практикуется в драйверах, там где это оправданно, например исключить проверки и валидации входных параметров, поскольку это уже сделано в коде драйвера. Более того, __pskb_pull_tail() экспортируемый символ, следовательно может использоваться. Эта функция вызывается из pskb_may_pull(), в чем экзотика?

Комментарии к коду pskb_may_pull() на http://elixir.free-electrons.com/linux/lat.../skbuff.c#L1610 говорят, что функция может изменить skb указатели. Если так, то после выполнения этого API, нужно обновлять указатели, например, на L3/L4 заголовки. Но я просмотрел примеры использования функции в ядре, и не нашел чтобы это делали. Почему?

Приветствую. Интересует, разбирался ли кто-либо подробно в OVS с целью портирования оного на железный свитч с поддержкой OpenFlow; под портированием я понимаю дописывание OVS таким образом, чтобы поиск в openflow таблицах выполнялось бы ресурсами свитча, а не софта (в ядре или в userspace). В самом OVS заложена такая возможность и даже есть соответствующий документ описывающий портирование, но там многое хотелось бы прояснить, поэтому если здесь есть товарищи с тамким опытом, pls отзовитесь.

Приветствую, Система x86, линукс ядро 2.6.35 Читаю https://www.kernel.org/doc/Documentation/DMA-API.txt секцию «Part Id» про функцию dma_map_single() Там есть такие слова: it is recommended that driver writers map virtual regions that begin and end on page boundaries (which are guaranteed also to be cache line boundaries). Я знаю (и об этом написано в LDD), что get_free_page() гарантирует выделение памяти по границе страницы. А будет ли гарантировать подобное kmem_cache_alloc()? (Драйвер, с которым я работаю, держит небольшой buffer pool и из него черпает буферы для dma операций). Спасибо.

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

IMHO слишком категорично. Нормалный спец это человек свободный (в том числе от уз брака) и творческий :) Так высылайте резюме, рассмотрим )

Предложение все еще в силе и актуально. Были интервью с кандидатами, но уровень к сожалению не устраивал.

Все еще актуально.

Вакансии по-прежнему актуальны.

Отвечая на ваш вопрос -- совершенно верно, компания консалтинговая, что не мешает ей тем не менее получать "большие" куски большого проекта клиента и работать над ним. Кстати, мы также являемся официальным партнером Cavium и EzChip.

Приветствую, В нашу компанию http://gonorthforge.com ищутся инженеры с хорошим знанием сетевых процессоров. Если уровень действительно высокий и будет продемонстриирован на интервью, то компания возьмется за оформление рабочей визы для не-локальных кандидатов. Описание вакансий и требования здесь: http://gonorthforge.com/wp-content/uploads...de-Software.pdf http://gonorthforge.com/wp-content/uploads...ssor-_C_C++.pdf Резюме просьбма направлять на [email protected] Роман.

Приветствую, достался в "наследство" сравнительно большое embedded проект (ARM процесор, linux 2.6.31, busybox), который нужно поддерживать. Столкнулся со следующей проблемой: ядерный модуль (часть этого проекта) всегда загружается первым, потом демон устанавливающий соединение по netlink сокету. Проблема в том, что после выгружения демона из памяти по SIGINT или SIGKILL, число референсов на этот модуль в ядре не 0 (cat /proc/net/modules | grep my_module, 3й параметр) и соответственно rmmod возвращает ошибку: % rmmod my_module.ko % rmmod: my_module.ko: Resource temporarily unavailable Т.е. получаем -11 EAGAIN. Из кода демона известно, что открываются 3 netlink сокета в модуль и по таймеру один из сокетов регулярно читается, но после запуска демона число references в модуле (/proc/net/modules) поднимается с 0 до 6, после убийства демона опускается до 3, т.е. либо остаются открытые дескрипторы, либо что-то еще. Подскажите, какие есть методы обнаружить и отловить такого рода баг? Буду пременого благодарен! :)

В вопросе разобрался, нашел где в ядре задаются адреса по которым будут грузиться модули (это архитектурно специфичные настройки): % more arch/arm/include/asm/memory.h ... /* * PAGE_OFFSET - the virtual address of the start of the kernel image * TASK_SIZE - the maximum size of a user space task. */ #define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET) #define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(0x01000000)) /* * The module space lives between the addresses given by TASK_SIZE * and PAGE_OFFSET - it must be within 32MB of the kernel text. */ #define MODULES_VADDR (PAGE_OFFSET - 16*1024*1024) А вот выделение памяти под модуль: % more arch/arm/kernel/module.c ... void *module_alloc(unsigned long size) { return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, GFP_KERNEL, PAGE_KERNEL_EXEC, -1, __builtin_return_address(0)); }

Приветствую, ядро 2.6.31.8 сконфигурировано с включенным CONFIG_VMSPLIT_3G, т.е. 1G под ядерную память и 3G под юзер спейс — соответственно ядро занимает пространство 0xc0000000 - 0xffffffff, а пользовательские процессы живут в диапазоне 0x00000000 - 0xbfffffff. Однако наблюдаю следующее: # cat /sys/module/mydrv/sections/.data 0xbf00b4f4 # cat /sys/module/mydrv/sections/.text 0xbf006000 И это поведение всех драйверов на этой системе, вот так расположен марвеловский драйвер ethernet свитча на этой же платформе: # cat /sys/module/mvPpDrv/sections/.text /sys/module/mvPpDrv/sections/.data /sys/module/mvPpDrv/sections/.bss 0xbf006000 0xbf00b4f4 0xbf00c3a4 Вот на всякий случай информация о процессоре: # cat /proc/cpuinfo Processor : Feroceon 88FR131 rev 1 (v5l) BogoMIPS : 799.53 Features : swp half thumb fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part : 0x131 CPU revision : 1 Hardware : Feroceon-KW Revision : 0000 Serial : 0000000000000000 Не понимаю как получается что ядерный модуль оказался загружен по user space адресам? Я предполагал, что модуль после insmod должен стать частью ядра и жить в ядерном пространстве. Возможно я ошибаюсь — просьба просветить и поправить. Спасибо!

Спасибо за ответ. А что скажете насчет следующего -- в качестве ключа _всегда_ использовать самый первый элемент списка, тот что в голове списка, сравнивать/добавлять по нему. Но возможна ситуация когда одинаковый nexthop присутствует в нескольких узлах дерева (например, один nexthop для группы IP сетей). Либо делать хеш, crc на каждый из лист-нодов, суммировать и это будет ключом. Из минусов -- каждый раз при добавлении нового nexthop'а пересчитывать ключ, удалять нод из дерева и добавлять с новым ключом. Comments are welcome :)