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

Косяк с NFS в 2.6.19-rc* (fs/nfs/dir.c)


0

0 

В третьем релиз-кандидате (на самом деле - раньше, еще в rc1)
ядра поломался (а точнее пофиксился и неслабо проапдейтился)
клиентский код NFS, ниже приведен дифф на виновной функции.

Не заценит ли уважаемое кернел-хаккерское подмножетво ALL оные
и не подскажет ли - как вернуть поддержку NFS на путь исправления?

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

#==============================================
# косячная функция
#==============================================

diff -urdN linux-2.6.18/fs/nfs/dir.c linux-2.6.19/fs/nfs/dir.c
--- linux-2.6.18/fs/nfs/dir.c	2006-10-28 00:21:02.130255000 +0400
+++ linux-2.6.19/fs/nfs/dir.c	2006-10-28 00:21:39.630255000 +0400
@@ -1,17 +1,24 @@
 void nfs_access_add_cache(struct inode *inode, struct nfs_access_entry *set)
 {
-	struct nfs_inode *nfsi = NFS_I(inode);
-	struct nfs_access_entry *cache = &nfsi->cache_access;
-
-	if (cache->cred != set->cred) {
-		if (cache->cred)
-			put_rpccred(cache->cred);
-		cache->cred = get_rpccred(set->cred);
-	}
-	/* FIXME: replace current access_cache BKL reliance with inode->i_lock */
-	spin_lock(&inode->i_lock);
-	nfsi->cache_validity &= ~NFS_INO_INVALID_ACCESS;
-	spin_unlock(&inode->i_lock);
+	struct nfs_access_entry *cache = kmalloc(sizeof(*cache), GFP_KERNEL);
+	if (cache == NULL)
+		return;
+	RB_CLEAR_NODE(&cache->rb_node);
 	cache->jiffies = set->jiffies;
+	cache->cred = get_rpccred(set->cred);
 	cache->mask = set->mask;
+
+	nfs_access_add_rbtree(inode, cache);
+
+	/* Update accounting */
+	smp_mb__before_atomic_inc();
+	atomic_long_inc(&nfs_access_nr_entries);
+	smp_mb__after_atomic_inc();
+
+	/* Add inode to global LRU list */
+	if (!test_and_set_bit(NFS_INO_ACL_LRU_SET, &NFS_FLAGS(inode))) {
+		spin_lock(&nfs_access_lru_lock);
+		list_add_tail(&NFS_I(inode)->access_cache_inode_lru, &nfs_access_lru_list);
+		spin_unlock(&nfs_access_lru_lock);
+	}
 }

#==============================================
# фрагмент include/asm/bitops.h (x86_64)
#==============================================

static __inline__ int test_and_set_bit(int nr, volatile void * addr)
{
	int oldbit;

	__asm__ __volatile__( LOCK_PREFIX
		"btsl %2,%1\n\tsbbl %0,%0"
		:"=r" (oldbit),"+m" (ADDR)
		:"dIr" (nr) : "memory");
	return oldbit;
}

← Падение демона и gdb.
Правильная реализация макроса в Сommon Lisp →

># фрагмент include/asm/bitops.h (x86_64)

тут все в порядке.

Что конкретно не работает ? Почему именно эта функция ?

>как вернуть поддержку NFS на путь исправления?

баг репорт написать.

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

По моему там тоже все в порядке, т.к. старый код с FIXME работал - а новый перестал. Видимо из-за замерженных в 2.6.19 и бэкпортированных на 2.6.18 патчей - с ними тоже все обламывается.

"Эта функция" - потому как именно в ней вызывается test_and_set_bit(), которому в свою очередь передается нечто левое и получается:

include/asm/bitops.h:122: error: inconsistent operand constraints in an `asm'

Нарисовал "багрепортец" Trond Myklebust'у, ждем ответа, пока живя без NFS-клиента...

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

поробуй заменить на

static __inline__ int test_and_set_bit(int nr, volatile void * addr)
{
        int oldbit;

        __asm__ __volatile__( LOCK_PREFIX
                "btsl %2,%1\n\tsbbl %0,%0"
                :"=r" (oldbit),"=m" (ADDR)
                :"dIr" (nr) : "memory");
        return oldbit;
}


gcc какая версия ?

xnix ★★
() 

вообще у меня это ядро собралось нормально(x86_64).

xnix@darkstar:~$ gcc --version
gcc (GCC) 4.1.2 20060928 (prerelease)

кинь свой конфиг на kernel.xnix@gmail.com

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

ver_linux fragment:

Linux darkstar 2.6.18 #1 SMP Wed Oct 25 01:24:36 MSD 2006 x86_64 x86_64 x86_64 GNU/Linux
 
Gnu C                  3.4.6
Gnu make               3.81
binutils               2.17
util-linux             2.13-pre7
mount                  2.13-pre7
module-init-tools      3.2.2
e2fsprogs              1.39
jfsutils               1.1.11
reiserfsprogs          3.6.19.3
reiser4progs           1.0.6
xfsprogs               2.8.11
PPP                    2.4.4
Linux C Library        > libc.2.5
Dynamic linker (ldd)   2.5
Linux C++ Library      6.0.3
Procps                 3.2.7
Net-tools              1.60
Kbd                    1.12
Sh-utils               6.3
udev                   102

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

> вообще у меня это ядро собралось нормально(x86_64).

> xnix@darkstar:~$ gcc --version
> gcc (GCC) 4.1.2 20060928 (prerelease)

> кинь свой конфиг на kernel.xnix@gmail.com

2.6.18 (.1) без патча с http://www.linux-nfs.org/Linux-2.6.x/2.6.18/ тоже собирается и прекрасно работает - косяк в сочетании нового кода и ассемблерных bitops'ах для x86_64.

Ассемлерный же код менять стремно - test_and_set_bit() используется дофига где, в т.ч. и в сорцах моей / файловой системы - не рискну использовать такой кернел :) Если просто поменять и собрать - то замена вида:

- :"=r" (oldbit),"+m" (ADDR)
+ :"=r" (oldbit),"=m" (ADDR)

для файлика fs/nfs/dir.c работает и оный компилится успешно.

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

Все, проблемку разрулили, собралось с использованием gcc-4.1.1,
и тут же прикатилось письмо: 

From: Andi Kleen <ak@suse.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Gharik <gharik@mail.ru>
Subject: Re: NFS client module compilation failure
Date: Sat, 28 Oct 2006 08:38:55 -0700

...

It's a known bug in some old gcc 3 compiler. I probably need to 
add a ifdef for it sometime or unsupport that gcc version

-Andi

Что в общем печально, т.к. частично ломает совместимость с gcc
третьей серии, хоть она официально и мертва. Придется мигрировать
на gcc-4.х (или держать его отдельно для ядра), никуда не денешься...

А еще очень интересно - что таки на это
скажет Патрег к моменту выхода 2.6.19? :)

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

И в завершение:

From: Andi Kleen <ak@suse.de> To: gharik@mail.ru Subject: Re: NFS client module compilation failure Date: Sat, 28 Oct 2006 09:13:17 -0700

As a temporary workaround you can replace the diR in the asm statement with iR I'll try to figure out a generic solution.

-Andi

e
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Падение демона и gdb.
Development
Правильная реализация макроса в Сommon Lisp →