Проблема при работе /proc на ядре 2.4.18

Что насчет того, чтобы собрать UML или добавить KDB к ядру и попробовать прочесать, что там происходит?

Можешь скинуть diff от generic.c и inode.c между 2.4.18 и 2.4.24?

Это результат diff -B ver18/fs/proc/generic.c ver24/fs/proc/generic.c

141c141
< proc_file_lseek(struct file * file, loff_t offset, int orig)
---
> proc_file_lseek(struct file * file, loff_t offset, int origin)
143,158c143,161
<     switch (orig) {
<     case 0:
< 	if (offset < 0)
< 	    return -EINVAL;    
< 	file->f_pos = offset;
< 	return(file->f_pos);
<     case 1:
< 	if (offset + file->f_pos < 0)
< 	    return -EINVAL;    
< 	file->f_pos += offset;
< 	return(file->f_pos);
<     case 2:
< 	return(-EINVAL);
<     default:
< 	return(-EINVAL);
<     }
---
> 	long long retval;
> 
> 	switch (origin) {
> 		case 2:
> 			offset += file->f_dentry->d_inode->i_size;
> 			break;
> 		case 1:
> 			offset += file->f_pos;
> 	}
> 	retval = -EINVAL;
> 	if (offset>=0 && (unsigned long long)offset<=file->f_dentry->d_inode->i_sb->s_maxbytes) {
> 		if (offset != file->f_pos) {
> 			file->f_pos = offset;
> 			file->f_reada = 0;
> 		}
> 		retval = offset;
> 	}
> 	/* RED-PEN user can fake an error here by setting offset to >=-4095 && <0  */
> 	return retval;
457c460,464
< 			proc_register(parent, ent);
---
> 			if (proc_register(parent, ent) < 0) {
> 				kfree(ent->data);
> 				kfree(ent);
> 				ent = NULL;
> 			}
474c481,484
< 		proc_register(parent, ent);
---
> 		if (proc_register(parent, ent) < 0) {
> 			kfree(ent);
> 			ent = NULL;
> 		}
489c499,502
< 		proc_register(parent, ent);
---
> 		if (proc_register(parent, ent) < 0) {
> 			kfree(ent);
> 			ent = NULL;
> 		}
518c531,534
< 		proc_register(parent, ent);
---
> 		if (proc_register(parent, ent) < 0) {
> 			kfree(ent);
> 			ent = NULL;
> 		}

Это результат diff -B ver18/fs/proc/inode.c ver24/fs/proc/inode.c 

25c25
< struct proc_dir_entry * de_get(struct proc_dir_entry *de)
---
> static inline struct proc_dir_entry * de_get(struct proc_dir_entry *de)
35c35
< void de_put(struct proc_dir_entry *de)
---
> static void de_put(struct proc_dir_entry *de)
188a189
> 	s->s_maxbytes = ~0UL;

> file_entry->read_proc = vars_reader;

попробуйте прочитать этот файл из user-level.

если в generic_ip действительно 0, то у вас будет OOPS
в proc_file_read() и вы будете знать, что проблема в
create_proc_entry(). иначе что-то c filp_open().

в принципе вы забыли про S_IFREG в create_proc_entry(),
но по крайней мере в 4.26 он автоматически ставится если
!(mode & S_IFMT), так что дело вряд ли в этом.

Попробовали прочитать этот файл из user-level:

#include <fcntl.h> #include <stdio.h>

int main(void) { char buffer[20]; int f = open("/proc/test_dir/testname", O_RDWR); if (f<0) { printf("ERROR!\n"); } else { printf("Open OK!\n"); buffer[5] = 0; read(f,buffer,5); printf("%s\n",buffer); }

return 0; }

Результат - читается нормально и в точности то, что туда подкладывает функция vars_reader(). Честно говоря, я озадачен такой двойственностью поведения...

Станислав.

> Результат - читается нормально

значит, generic_ip не 0.

может, с include'ами путаница?

Не думаю. Я всегда заменяю /usr/include/linux /usr/include/asm /usr/include/asm-generic когда компилирую модули ядра.

Более того, при загрузке модуля выводится строка с ожидаемым номером версии.

С другой стороны, открывая файл из ядра я печатаю содержимое поля u.generic_ip и там лежит NULL! (см. в тексте модуля) Вот трасса: Dec 28 02:07:17 localhost kernel: dir_iops: c02c5e40 Dec 28 02:07:17 localhost kernel: dir_fops: c02c5de0 Dec 28 02:07:17 localhost kernel: file_iops: 00000000 Dec 28 02:07:17 localhost kernel: file_fops: c02c5d20 Dec 28 02:07:17 localhost kernel: file_data: 00000000 Dec 28 02:07:17 localhost kernel: file_read_proc: d08b317c Dec 28 02:07:17 localhost kernel: file_write_proc: 00000000 Dec 28 02:07:17 localhost kernel: vsfmnt: c138e320 Dec 28 02:07:17 localhost kernel: fops: c02c5d20 Dec 28 02:07:17 localhost kernel: node: 00000000

Есть ли какое-то различие между открытием файла из ядра и открытием файла из юзера?

Станислав.

> Я всегда заменяю /usr/include/linux /usr/include/asm /usr/include/asm-generic

оффтопик, но этого делать не стоит. лучше -nostdinc,
а в /usr/include/ оставить то, что поставил glibc.

а вы уверены, что то ядро, на котором все исполняется
было собрано с этими же исходниками? лучше пересобрать
и снова проверить.

> Вот трасса: Dec 28 02:07:17 localhost kernel

ну отформатируйте, читать же невозможно...

> localhost kernel: fops: c02c5d20

совпадает с proc_file_operations в System.map?

Да, совпадает...