LINUX.ORG.RU
Форум — Development  

file-max limit 150000 reached

 


0

2

В модуле ядра делаю такой тест

int max = 200000 ;
for(i=0; i < max; i++)
  {
      struct file *file_struct = NULL;
      file_struct = filp_open('/home/Aress/my_file', O_RDONLY, 0);
      filp_close(file_struct, NULL);
  };

При работе модуля, открываем и закрываем файл 200000 раз.
Во время работы, в лог dmesg попадает сообщение file-max limit 150000 reached
Такое ощущение, как-будто файл открывается, и не закрывается.
В чём проблема?


Ололо, в ляликсе уже в ядре из файла читать можно?

anonymous
()

Какого ядра? Какой filp_close?

Хоть ничего и не понятно, советую уточнить возвращаемое значение filp_close.

vzzo ★★★
()
Ответ на: комментарий от vzzo

filp_close возвращает 0, вроде то что и должен, при закрытии файла.

Aresss
() автор топика

У тебя скобки неправильные какие-то. 

'/home/Aress/my_file'
надо использовать 
"/home/Aress/my_file"

SZT ★★★★★
()
Ответ на: комментарий от SZT

Да тут проблема не в синтаксисе. А в том, что повидение ядра не понятное. 100К раз открываешь и закрываешь файл, а система считает, что файлы остаются открытыми. В чём тут дело?

Aresss
() автор топика
Ответ на: комментарий от SZT

int i
разве тип индекса важен при работе в цикле? (если в минуса уйдёт переменная, то в конце концов всёравно сравнится с целым положительным)

Aresss
() автор топика
Ответ на: комментарий от Aresss

Если ты не знаешь таких базовых вещей, зачем ты лезешь в ядро? Вполне возможно что ошибка где-то в другом месте. Учитывая что в предоставленном тобой примере строка записана в ' кавычках вместо " и учитывая что нормальный компилятор при попытке записать строку в одинарные кавычки просто не станет такое компилировать, этот пример не скопирован непосредственно из того твоего кода, который вызывает подобное поведение. Предоставь оригинальный код, и желательно побольше.

Могу еще посоветовать почитать исходники соответствующих функций: http://lxr.free-electrons.com/source/fs/open.c#L984 http://lxr.free-electrons.com/source/fs/open.c#L1072

Лучше подобные вопросы по ядру где-нибудь в LKML задавать. И кстати, зачем тебе из ядра открывать файл? Чего ты хочешь этим достичь?

SZT ★★★★★
()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от SZT

SZT, а ты занимаешься чем-то по ядру или смежным темам? Ответь, пожалуйста, мне на почту, её можно найти в LKML.

Простите за оффтоп.

Krieger_Od ★★
()

Проблема в том, что кто-то не понимает, что и зачем он делает.

Зачем тебе читать файл из ядра?

post-factum ★★★★★
()
Ответ на: комментарий от SZT

Просто нет слов.
Хоть в теме и информативности для меня оказалось 0. Но всёже спасибо за потраченное время.
Также спасибо за данную оценку моих способностей, ваше мнение, важно для меня. В будущем, буду пользоваться нормальным компилятором.
И не могу не ответить на вопрос «И кстати, зачем тебе из ядра открывать файл? Чего ты хочешь этим достичь?», как это не странно - я хочу открыть файл из модуля ядра, очевидно же.
Насчёт исходников, это конечноже замечательно - посмотреть их. Да вопрос то был в другом.......
И ещё, код цикла с открытием файла и его закрытием взят из модуля. После отработки цикла, модуль возвращает -1 (return -1; )

Aresss
() автор топика
Ответ на: комментарий от post-factum

Ещё один аналогичный вопрос «Зачем тебе читать файл из ядра?», это какимто образом поможет решить проблему? (да и не проблема это вовсе).

Aresss
() автор топика

Я ни разу не разработчик модулей ядра, но ты в своей программе попробуй логировать кол-во открытых файлов в системе из /proc/sys/fs/file-nr.

Вот что нашёл по ссылке: https://www.kernel.org/doc/Documentation/sysctl/fs.txt

Historically, the three values in file-nr denoted the number of allocated file handles, the number of allocated but unused file handles, and the maximum number of file handles. Linux 2.6 always reports 0 as the number of free file handles — this is not an error, it just means that the number of allocated file handles exactly matches the number of used file handles.

hope13 ★★★
()
Ответ на: комментарий от lenin386

завершится. Char по умолчанию не всегда знаковый.

Да. Но если собирать через gcc без каких-либо специальных флагов под x86-64 архитектуру, char будет знаковым и оно как раз никогда не завершиться. Если учитывать всякие нестандартные случаи, можно еще можно упомянуть что char не обязан вообще быть 8-битным. Кое-где он 16-битный, и тогда даже если он signed, этот цикл завершится.

SZT ★★★★★
()
Ответ на: комментарий от Aresss

Я из такого костыльного только с udp работал из kernel space (такая была постановка задачи, пришлось дергать sendmsg из kernel space). Кажется (надо гуглить для уточнения), все эти функции для работы с файлами тоже работают с адресами из user space, т.к. вообще напрямую из ядра не принято файлы читать. Ну а значит нужны get/set_fs.

Tayler ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development