Re: [linux-cifs-client] Re: BUG: scheduling while atomic - linux 2.6.22
Dave Kleikamp wrote: On Tue, 2007-08-28 at 07:11 +0800, Michael Deegan wrote: Hi, On Tue Aug 7 16:00:19 GMT 2007, Martin Koegler wrote: A vanilla 2.6.22 kernel (SMP PREEMPT i686) produced the following messages, while working with a CIFS mount point: Aug 27 22:33:08 wibble kernel: BUG: scheduling while atomic: bash/0x0001/4077 Aug 27 22:33:08 wibble kernel: Aug 27 22:33:08 wibble kernel: Call Trace: Aug 27 22:33:08 wibble kernel: [] __sched_text_start+0x5f/0x79b Aug 27 22:33:08 wibble kernel: [] kernel_sendmsg+0x2c/0x3e Aug 27 22:33:08 wibble kernel: [] wait_for_response+0xbe/0x155 Aug 27 22:33:08 wibble kernel: [] autoremove_wake_function+0x0/0x2e Aug 27 22:33:08 wibble kernel: [] SendReceive+0x1fb/0x3f8 Aug 27 22:33:08 wibble kernel: [] CIFSSMBOpen+0x1c6/0x27a Aug 27 22:33:08 wibble kernel: [] cifs_reopen_file+0x1ea/0x356 Aug 27 22:33:08 wibble kernel: [] find_writable_file+0x84/0xe7 Aug 27 22:33:08 wibble kernel: [] is_size_safe_to_change+0x16/0x4e Aug 27 22:33:08 wibble kernel: [] fill_in_inode+0x270/0x4ec Aug 27 22:33:08 wibble kernel: [] cifs_readdir+0xe24/0x1071 Aug 27 22:33:08 wibble kernel: [] filldir64+0x0/0xb8 Aug 27 22:33:08 wibble kernel: [] do_page_fault+0x40b/0x74a Aug 27 22:33:08 wibble kernel: [] __mutex_lock_slowpath+0x234/0x23f Aug 27 22:33:08 wibble kernel: [] filldir64+0x0/0xb8 Aug 27 22:33:08 wibble kernel: [] vfs_readdir+0x5d/0x92 Aug 27 22:33:08 wibble kernel: [] sys_getdents64+0x75/0xba Aug 27 22:33:08 wibble kernel: [] error_exit+0x0/0x84 Aug 27 22:33:08 wibble kernel: [] system_call+0x7e/0x83 Aug 27 22:33:08 wibble kernel: I'm using a 2.6.22.1 kernel (with SMP and PREEMPT, including BKL) on Debian etch AMD64, and Samba 3.0.24-6etch4. This is a known problem that is fixed in 2.6.23-rc4. cifs_readdir() takes a spinlock and calls a blocking function. The fix is here: http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a403a0a370946e7dbcda6464a3509089daee54bc Steve, Has this patch been submitted to the stable kernel? No - but seems like a resonable idea, although a little larger than typical patch to stable kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: BUG: scheduling while atomic - linux 2.6.22
Dave Kleikamp wrote: On Tue, 2007-08-28 at 07:11 +0800, Michael Deegan wrote: Hi, On Tue Aug 7 16:00:19 GMT 2007, Martin Koegler wrote: A vanilla 2.6.22 kernel (SMP PREEMPT i686) produced the following messages, while working with a CIFS mount point: Aug 27 22:33:08 wibble kernel: BUG: scheduling while atomic: bash/0x0001/4077 Aug 27 22:33:08 wibble kernel: Aug 27 22:33:08 wibble kernel: Call Trace: Aug 27 22:33:08 wibble kernel: [805265df] __sched_text_start+0x5f/0x79b Aug 27 22:33:08 wibble kernel: [8049cb7a] kernel_sendmsg+0x2c/0x3e Aug 27 22:33:08 wibble kernel: [8032ba42] wait_for_response+0xbe/0x155 Aug 27 22:33:08 wibble kernel: [802392bf] autoremove_wake_function+0x0/0x2e Aug 27 22:33:08 wibble kernel: [8032c0e1] SendReceive+0x1fb/0x3f8 Aug 27 22:33:08 wibble kernel: [803192c2] CIFSSMBOpen+0x1c6/0x27a Aug 27 22:33:08 wibble kernel: [80323b8a] cifs_reopen_file+0x1ea/0x356 Aug 27 22:33:08 wibble kernel: [8032455c] find_writable_file+0x84/0xe7 Aug 27 22:33:08 wibble kernel: [80324b51] is_size_safe_to_change+0x16/0x4e Aug 27 22:33:08 wibble kernel: [8032fbc7] fill_in_inode+0x270/0x4ec Aug 27 22:33:08 wibble kernel: [80330c67] cifs_readdir+0xe24/0x1071 Aug 27 22:33:08 wibble kernel: [802733c8] filldir64+0x0/0xb8 Aug 27 22:33:08 wibble kernel: [80218c71] do_page_fault+0x40b/0x74a Aug 27 22:33:08 wibble kernel: [80527ffb] __mutex_lock_slowpath+0x234/0x23f Aug 27 22:33:08 wibble kernel: [802733c8] filldir64+0x0/0xb8 Aug 27 22:33:08 wibble kernel: [80273594] vfs_readdir+0x5d/0x92 Aug 27 22:33:08 wibble kernel: [8027363e] sys_getdents64+0x75/0xba Aug 27 22:33:08 wibble kernel: [8052948d] error_exit+0x0/0x84 Aug 27 22:33:08 wibble kernel: [8020958e] system_call+0x7e/0x83 Aug 27 22:33:08 wibble kernel: I'm using a 2.6.22.1 kernel (with SMP and PREEMPT, including BKL) on Debian etch AMD64, and Samba 3.0.24-6etch4. This is a known problem that is fixed in 2.6.23-rc4. cifs_readdir() takes a spinlock and calls a blocking function. The fix is here: http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a403a0a370946e7dbcda6464a3509089daee54bc Steve, Has this patch been submitted to the stable kernel? No - but seems like a resonable idea, although a little larger than typical patch to stable kernel. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: [PATCH] CIFS: make sec=none force an anonymous mount
Shirish S Pargaonkar wrote: When a session setup request is sent as an anonymous user (NUL user), should/could there be password associated with that? Right now, sec=none option, will prompt you for a password. And when we add code to retry session setup as anonymous user if the first session setup request fails, should that retry request be sent with the password or without password? When smbfs sends requests as an anonymous user, it does not send a password along with it. Regards, Shirish We should allow a password to be specified (presumably it is not common for a server to have a password associated with a null user), but probably not prompt (similar to "guest" - except for the case of guest, we start with the username of uid of current process, and only if it fails with access denied do we try "user=" (or equivalently sec=none)) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: [PATCH] CIFS: make sec=none force an anonymous mount
Shirish S Pargaonkar wrote: When a session setup request is sent as an anonymous user (NUL user), should/could there be password associated with that? Right now, sec=none option, will prompt you for a password. And when we add code to retry session setup as anonymous user if the first session setup request fails, should that retry request be sent with the password or without password? When smbfs sends requests as an anonymous user, it does not send a password along with it. Regards, Shirish We should allow a password to be specified (presumably it is not common for a server to have a password associated with a null user), but probably not prompt (similar to guest - except for the case of guest, we start with the username of uid of current process, and only if it fails with access denied do we try user= (or equivalently sec=none)) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CIFS: make sec=none force an anonymous mount
Jeff Layton wrote: On Fri, May 04, 2007 at 10:26:29AM -0500, Steve French (smfltc) wrote: Jeff Layton wrote: We had a customer report that attempting to make CIFS mount with a null username (i.e. doing an anonymous mount) doesn't work. Looking through the code, it looks like CIFS expects a NULL username from userspace in order to trigger an anonymous mount. The mount.cifs code doesn't seem to ever pass a null username to the kernel, however. Yes - cifs kernel code expects a NULL username (e.g. "username=") if you really don't want to pass the default username of the uid of the current process and you don't set the username explicitly (e.g. in a credential file or mount parameter). Samba userspace tools (and smbfs) handled this by first trying to setup the SMB session using the default user, and if that fails with access denied then retrying sessionsetup with a null username string. This would be easy to change in mount.cifs (ie as long as username was not explicitly passed on mount then if mount fails with access denied simply add a retry with "username="). This was discussed at SambaXP. Does this mean you're NAK'ing this patch in favor of a userspace fix? My perspective is that if someone explicitly requests sec=none, then we ought to do an anonymous mount regardless of how the username is set. Would you agree that that behavior is what you would want? Your patch is probably ok to add, although I would like to see if any of the other Samba team had thoughts on this, as "null user" sessions are a fairly obscure part of the protocol. But even with the kernel change, mount.cifs also should change for a loosely related case that of 1) sec=none is not specified by the user 2) but username also is not specified explicitly For that case we need to retry on access denied as if it were a request for a "null user" mount ie send sec=none (or equivalently username=) the 2nd time. This gets more complicated since mount.cifs also has to retry on a couple of other cases (e.g. when the server does not support port 445 but does not take the standard server string "*SMBSERVER" on the RFC1001 called name). If there are no objections from any of the other Samba guys I will take your patch which has the effect of treating "sec=none" as meaning "ingore any userid if specified, and set the username to null on the session setup"). That is consistent with what we documented. I had though for a while that a user who mounts passing both "sec=none" and a username might also expect to get a null password (they could have done this with "guest" or with "password=") or might want to try to send the password in plaintext - but I doubt that we want to support a user who wants to send the password plaintext without the server requiring it (and in that case cifs can be built and configured to allow plaintext if absolutely necessary to support those ancient servers). Basically if we set username to null in kernel when (sec=none) Thanks, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CIFS: make sec=none force an anonymous mount
Jeff Layton wrote: We had a customer report that attempting to make CIFS mount with a null username (i.e. doing an anonymous mount) doesn't work. Looking through the code, it looks like CIFS expects a NULL username from userspace in order to trigger an anonymous mount. The mount.cifs code doesn't seem to ever pass a null username to the kernel, however. Yes - cifs kernel code expects a NULL username (e.g. "username=") if you really don't want to pass the default username of the uid of the current process and you don't set the username explicitly (e.g. in a credential file or mount parameter). Samba userspace tools (and smbfs) handled this by first trying to setup the SMB session using the default user, and if that fails with access denied then retrying sessionsetup with a null username string. This would be easy to change in mount.cifs (ie as long as username was not explicitly passed on mount then if mount fails with access denied simply add a retry with "username="). This was discussed at SambaXP. Christoph Hellwig wrote: Looks useful. In case you have some spare time at your hand it would be really nice to convert cifs option parsing to the lib/parser.c code and move all validation of the arguments into one place, so it's easily understanable and better to maintain. Yes - that would be excellent. The parse_mount_options badly needs to be rewritten now that the number of mount options needed has grown. This is something Alex Bokovoy and I discussed last week at SambaXP for both the kernel code and the user space mount.cifs code. Alex had volunteered to rewrite the user space cifs mount option parsing code (and also change to use the safer talloc library) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CIFS: make sec=none force an anonymous mount
Jeff Layton wrote: We had a customer report that attempting to make CIFS mount with a null username (i.e. doing an anonymous mount) doesn't work. Looking through the code, it looks like CIFS expects a NULL username from userspace in order to trigger an anonymous mount. The mount.cifs code doesn't seem to ever pass a null username to the kernel, however. Yes - cifs kernel code expects a NULL username (e.g. username=) if you really don't want to pass the default username of the uid of the current process and you don't set the username explicitly (e.g. in a credential file or mount parameter). Samba userspace tools (and smbfs) handled this by first trying to setup the SMB session using the default user, and if that fails with access denied then retrying sessionsetup with a null username string. This would be easy to change in mount.cifs (ie as long as username was not explicitly passed on mount then if mount fails with access denied simply add a retry with username=). This was discussed at SambaXP. Christoph Hellwig wrote: Looks useful. In case you have some spare time at your hand it would be really nice to convert cifs option parsing to the lib/parser.c code and move all validation of the arguments into one place, so it's easily understanable and better to maintain. Yes - that would be excellent. The parse_mount_options badly needs to be rewritten now that the number of mount options needed has grown. This is something Alex Bokovoy and I discussed last week at SambaXP for both the kernel code and the user space mount.cifs code. Alex had volunteered to rewrite the user space cifs mount option parsing code (and also change to use the safer talloc library) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CIFS: make sec=none force an anonymous mount
Jeff Layton wrote: On Fri, May 04, 2007 at 10:26:29AM -0500, Steve French (smfltc) wrote: Jeff Layton wrote: We had a customer report that attempting to make CIFS mount with a null username (i.e. doing an anonymous mount) doesn't work. Looking through the code, it looks like CIFS expects a NULL username from userspace in order to trigger an anonymous mount. The mount.cifs code doesn't seem to ever pass a null username to the kernel, however. Yes - cifs kernel code expects a NULL username (e.g. username=) if you really don't want to pass the default username of the uid of the current process and you don't set the username explicitly (e.g. in a credential file or mount parameter). Samba userspace tools (and smbfs) handled this by first trying to setup the SMB session using the default user, and if that fails with access denied then retrying sessionsetup with a null username string. This would be easy to change in mount.cifs (ie as long as username was not explicitly passed on mount then if mount fails with access denied simply add a retry with username=). This was discussed at SambaXP. Does this mean you're NAK'ing this patch in favor of a userspace fix? My perspective is that if someone explicitly requests sec=none, then we ought to do an anonymous mount regardless of how the username is set. Would you agree that that behavior is what you would want? Your patch is probably ok to add, although I would like to see if any of the other Samba team had thoughts on this, as null user sessions are a fairly obscure part of the protocol. But even with the kernel change, mount.cifs also should change for a loosely related case that of 1) sec=none is not specified by the user 2) but username also is not specified explicitly For that case we need to retry on access denied as if it were a request for a null user mount ie send sec=none (or equivalently username=) the 2nd time. This gets more complicated since mount.cifs also has to retry on a couple of other cases (e.g. when the server does not support port 445 but does not take the standard server string *SMBSERVER on the RFC1001 called name). If there are no objections from any of the other Samba guys I will take your patch which has the effect of treating sec=none as meaning ingore any userid if specified, and set the username to null on the session setup). That is consistent with what we documented. I had though for a while that a user who mounts passing both sec=none and a username might also expect to get a null password (they could have done this with guest or with password=) or might want to try to send the password in plaintext - but I doubt that we want to support a user who wants to send the password plaintext without the server requiring it (and in that case cifs can be built and configured to allow plaintext if absolutely necessary to support those ancient servers). Basically if we set username to null in kernel when (sec=none) Thanks, Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-cifs-client Digest, Vol 42, Issue 1
what also puzzles me... almost every filesystem that's not at revision 1
anymore (ext2/3/4, reiser4, smb2) does not have the usually omnipresent "fs"
suffix anymore (cf. reiserfs, smbfs).
Maybe it's time to drop all the "fs" suffixes? :)
For the case of cifs (and nfs and afs) the "fs" is part of the name of
the protocol ("common internet file system [protocol]") but for the
other filesystems I agree that it seems redundant to put "fs" in the
name (with a few exceptions e.g. "GFS2" would sound strange if named
"G2" or "global2", and OCFS2 is presumably a product name).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-cifs-client Digest, Vol 42, Issue 1
what also puzzles me... almost every filesystem that's not at revision 1 anymore (ext2/3/4, reiser4, smb2) does not have the usually omnipresent fs suffix anymore (cf. reiserfs, smbfs). Maybe it's time to drop all the fs suffixes? :) For the case of cifs (and nfs and afs) the fs is part of the name of the protocol (common internet file system [protocol]) but for the other filesystems I agree that it seems redundant to put fs in the name (with a few exceptions e.g. GFS2 would sound strange if named G2 or global2, and OCFS2 is presumably a product name). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Samba, inotify on a Windows share
Here's what I try to do. I want to monitor from a Linux Gentoo machine with inotify enabled on a directory for new files hosted by a windows share(Windows server, not Samba). Samba now uses inotify if available on the server side to support the Directory Change Notification requested by certain cifs client (Windows explorer on most Windows clients e.g.) but the Linux CIFS client does not have a complete implementation of the mapping between the fcntl dnotify (the old way to do the same thing on Linux) and the cifs transact change notify request on the wire. It would not be too hard to finish up if anyone is looking for a small project. support for inotify on the client (mapping to the cifs transact change notify on the wire) would be a little harder because Linux's inotify is a broader API than the older fcntl but it could be done for some common cases. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Samba, inotify on a Windows share
Here's what I try to do. I want to monitor from a Linux Gentoo machine with inotify enabled on a directory for new files hosted by a windows share(Windows server, not Samba). Samba now uses inotify if available on the server side to support the Directory Change Notification requested by certain cifs client (Windows explorer on most Windows clients e.g.) but the Linux CIFS client does not have a complete implementation of the mapping between the fcntl dnotify (the old way to do the same thing on Linux) and the cifs transact change notify request on the wire. It would not be too hard to finish up if anyone is looking for a small project. support for inotify on the client (mapping to the cifs transact change notify on the wire) would be a little harder because Linux's inotify is a broader API than the older fcntl but it could be done for some common cases. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cifs and kthread_run / kernel_thread
Wilhelm Meier wrote:
m Montag, 2. April 2007 schrieb Wilhelm Meier:
It seems to me that I rewrote cifs_demultiplex_thread to use kthread_run
in DFS patch.
o.k., I found the patch on the list. Will do some testing with it.
o.k., the patch seems to be fine for linux-vserver. cifs-mounting inside the
guest is now possible.
Do you see any possiblility to include this part of Igors work (not the whole
DFS thing) to the mainline? It fixes the use of the deprecated api.
-
Wilhelm
Index: connect.c
===
--- connect.c (.../2.6.19.1) (revision 20)
+++ connect.c (.../kthread_support) (revision 20)
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -119,7 +120,7 @@
struct mid_q_entry * mid_entry;
spin_lock(_Lock);
- if(server->tcpStatus == CifsExiting) {
+ if( kthread_should_stop() ) {
/* the demux thread will exit normally
next time through the loop */
spin_unlock(_Lock);
@@ -181,7 +182,7 @@
spin_unlock(_Lock);
up(>tcpSem);
- while ((server->tcpStatus != CifsExiting) && (server->tcpStatus !=
CifsGood))
+ while ( (!kthread_should_stop()) && (server->tcpStatus != CifsGood))
{
try_to_freeze();
if(server->protocolType == IPV6) {
@@ -198,7 +199,7 @@
} else {
atomic_inc();
spin_lock(_Lock);
- if(server->tcpStatus != CifsExiting)
+ if( !kthread_should_stop() )
server->tcpStatus = CifsGood;
server->sequence_number = 0;
spin_unlock(_Lock);
@@ -344,7 +345,6 @@
int isMultiRsp;
int reconnect;
- daemonize("cifsd");
allow_signal(SIGKILL);
current->flags |= PF_MEMALLOC;
server->tsk = current; /* save process info to wake at shutdown */
@@ -360,7 +360,7 @@
GFP_KERNEL);
}
- while (server->tcpStatus != CifsExiting) {
+ while (!kthread_should_stop()) {
if (try_to_freeze())
continue;
if (bigbuf == NULL) {
@@ -399,7 +399,7 @@
kernel_recvmsg(csocket, _msg,
, 1, 4, 0 /* BB see socket.h flags */);
- if (server->tcpStatus == CifsExiting) {
+ if ( kthread_should_stop() ) {
break;
} else if (server->tcpStatus == CifsNeedReconnect) {
cFYI(1, ("Reconnect after server stopped responding"));
@@ -523,7 +523,7 @@
total_read += length) {
length = kernel_recvmsg(csocket, _msg, , 1,
pdu_length - total_read, 0);
- if((server->tcpStatus == CifsExiting) ||
+ if( kthread_should_stop() ||
(length == -EINTR)) {
/* then will exit */
reconnect = 2;
@@ -756,7 +756,6 @@
GFP_KERNEL);
}
- complete_and_exit(_complete, 0);
return 0;
}
@@ -1779,10 +1778,11 @@
so no need to spinlock this init of tcpStatus */
srvTcp->tcpStatus = CifsNew;
init_MUTEX(>tcpSem);
- rc = (int)kernel_thread((void *)(void
*)cifs_demultiplex_thread, srvTcp,
- CLONE_FS | CLONE_FILES | CLONE_VM);
- if(rc < 0) {
- rc = -ENOMEM;
+ srvTcp->tsk = kthread_run((void *)(void
*)cifs_demultiplex_thread, srvTcp, "cifsd");
+ if( IS_ERR(srvTcp->tsk) ) {
+ rc = PTR_ERR(srvTcp->tsk);
+ cERROR(1,("error %d create cifsd thread", rc));
+ srvTcp->tsk = NULL;
sock_release(csocket);
kfree(volume_info.UNC);
kfree(volume_info.password);
@@ -1973,7 +1973,7 @@
spin_unlock(_Lock);
if(srvTcp->tsk) {
send_sig(SIGKILL,srvTcp->tsk,1);
- wait_for_completion(_complete);
+ kthread_stop(srvTcp->tsk);
}
}
/* If find_unc succeeded then rc == 0 so we can not end */
@@ -1987,9 +1987,9 @@
temp_rc = CIFSSMBLogoff(xid, pSesInfo);
/* if the
Re: [linux-cifs-client] Re: cifs and kthread_run / kernel_thread
Q (Igor Mammedov) wrote: Steve French (smfltc) wrote: No - IIRC the original patch (for the switch of cifs from kernel_thread to kthread) had a minor implementation problem in handling the cifs_demultiplex thread, so this one small area was left with the old style. iii) Is it difficult to switch to the new interface? No, I don't think so, but I have not investigated it. We would be happy to review and test a patch for this though. *** It seems to me that I rewrote cifs_demultiplex_thread to use kthread_run in DFS patch. Yes - Q's patch has the final change to kthread (as part of a larger DFS change). The original patch which switched to kthread was done long before this. I have not broken all the large dfs patch into small pieces but will look to see if just this part can be done easily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: cifs and kthread_run / kernel_thread
Q (Igor Mammedov) wrote: Steve French (smfltc) wrote: No - IIRC the original patch (for the switch of cifs from kernel_thread to kthread) had a minor implementation problem in handling the cifs_demultiplex thread, so this one small area was left with the old style. iii) Is it difficult to switch to the new interface? No, I don't think so, but I have not investigated it. We would be happy to review and test a patch for this though. *** It seems to me that I rewrote cifs_demultiplex_thread to use kthread_run in DFS patch. Yes - Q's patch has the final change to kthread (as part of a larger DFS change). The original patch which switched to kthread was done long before this. I have not broken all the large dfs patch into small pieces but will look to see if just this part can be done easily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cifs and kthread_run / kernel_thread
Wilhelm Meier wrote:
m Montag, 2. April 2007 schrieb Wilhelm Meier:
It seems to me that I rewrote cifs_demultiplex_thread to use kthread_run
in DFS patch.
o.k., I found the patch on the list. Will do some testing with it.
o.k., the patch seems to be fine for linux-vserver. cifs-mounting inside the
guest is now possible.
Do you see any possiblility to include this part of Igors work (not the whole
DFS thing) to the mainline? It fixes the use of the deprecated api.
-
Wilhelm
Index: connect.c
===
--- connect.c (.../2.6.19.1) (revision 20)
+++ connect.c (.../kthread_support) (revision 20)
@@ -30,6 +30,7 @@
#include linux/mempool.h
#include linux/delay.h
#include linux/completion.h
+#include linux/kthread.h
#include linux/pagevec.h
#include asm/uaccess.h
#include asm/processor.h
@@ -119,7 +120,7 @@
struct mid_q_entry * mid_entry;
spin_lock(GlobalMid_Lock);
- if(server-tcpStatus == CifsExiting) {
+ if( kthread_should_stop() ) {
/* the demux thread will exit normally
next time through the loop */
spin_unlock(GlobalMid_Lock);
@@ -181,7 +182,7 @@
spin_unlock(GlobalMid_Lock);
up(server-tcpSem);
- while ((server-tcpStatus != CifsExiting) (server-tcpStatus !=
CifsGood))
+ while ( (!kthread_should_stop()) (server-tcpStatus != CifsGood))
{
try_to_freeze();
if(server-protocolType == IPV6) {
@@ -198,7 +199,7 @@
} else {
atomic_inc(tcpSesReconnectCount);
spin_lock(GlobalMid_Lock);
- if(server-tcpStatus != CifsExiting)
+ if( !kthread_should_stop() )
server-tcpStatus = CifsGood;
server-sequence_number = 0;
spin_unlock(GlobalMid_Lock);
@@ -344,7 +345,6 @@
int isMultiRsp;
int reconnect;
- daemonize(cifsd);
allow_signal(SIGKILL);
current-flags |= PF_MEMALLOC;
server-tsk = current; /* save process info to wake at shutdown */
@@ -360,7 +360,7 @@
GFP_KERNEL);
}
- while (server-tcpStatus != CifsExiting) {
+ while (!kthread_should_stop()) {
if (try_to_freeze())
continue;
if (bigbuf == NULL) {
@@ -399,7 +399,7 @@
kernel_recvmsg(csocket, smb_msg,
iov, 1, 4, 0 /* BB see socket.h flags */);
- if (server-tcpStatus == CifsExiting) {
+ if ( kthread_should_stop() ) {
break;
} else if (server-tcpStatus == CifsNeedReconnect) {
cFYI(1, (Reconnect after server stopped responding));
@@ -523,7 +523,7 @@
total_read += length) {
length = kernel_recvmsg(csocket, smb_msg, iov, 1,
pdu_length - total_read, 0);
- if((server-tcpStatus == CifsExiting) ||
+ if( kthread_should_stop() ||
(length == -EINTR)) {
/* then will exit */
reconnect = 2;
@@ -756,7 +756,6 @@
GFP_KERNEL);
}
- complete_and_exit(cifsd_complete, 0);
return 0;
}
@@ -1779,10 +1778,11 @@
so no need to spinlock this init of tcpStatus */
srvTcp-tcpStatus = CifsNew;
init_MUTEX(srvTcp-tcpSem);
- rc = (int)kernel_thread((void *)(void
*)cifs_demultiplex_thread, srvTcp,
- CLONE_FS | CLONE_FILES | CLONE_VM);
- if(rc 0) {
- rc = -ENOMEM;
+ srvTcp-tsk = kthread_run((void *)(void
*)cifs_demultiplex_thread, srvTcp, cifsd);
+ if( IS_ERR(srvTcp-tsk) ) {
+ rc = PTR_ERR(srvTcp-tsk);
+ cERROR(1,(error %d create cifsd thread, rc));
+ srvTcp-tsk = NULL;
sock_release(csocket);
kfree(volume_info.UNC);
kfree(volume_info.password);
@@ -1973,7 +1973,7 @@
spin_unlock(GlobalMid_Lock);
if(srvTcp-tsk) {
send_sig(SIGKILL,srvTcp-tsk,1);
- wait_for_completion(cifsd_complete);
+ kthread_stop(srvTcp-tsk);
}
}
/* If find_unc succeeded then rc == 0
RE: cifs causes BUG: soft lockup detected on CPU
"Valentin Zaharov" wrote on 04/01/2007 03:02:07 AM:
> Hi again,
>
> After applying changes manually to 2.6.20.4 according to the link that
> Steven sent I still get those errors (attached below) but no crash so
> far.
> I am wondering if its ok or having errors still will cause freezes.
It is ok and I see no indication of lookup. You have two errors logged:
a) a missing entry in the kernel translation table for your default
codepage to UCS-16 (Unicode).
"char2uni returned -22" (EINVAL, presumably due to a missing character)
b) some access denied (-13) warnings on cifs_get_info_info (lookup).
This is probably harmless.
We could isolate the failing character by modifying the error log entry
but you may be able to guess at the problem by seeing which filenames
are requested with '?' in it ('?' is used when translation to Unicode
fails)
We could probably isolate the missing character by checking what
is logged to dmesag after this minor modification to the warning
message (we would also need to know which nls codepage
you are running).
diff --git a/fs/cifs/cifs_unicode.c b/fs/cifs/cifs_unicode.c
index d2a8b29..793c4b9 100644
--- a/fs/cifs/cifs_unicode.c
+++ b/fs/cifs/cifs_unicode.c
@@ -74,8 +74,8 @@ cifs_strtoUCS(__le16 * to, const char *f
charlen = codepage->char2uni(from, len, _to[i]);
if (charlen < 1) {
cERROR(1,
- ("cifs_strtoUCS: char2uni returned %d",
-charlen));
+ ("strtoUCS: char2uni of %d returned %d",
+(int)*from, charlen));
/* A question mark */
to[i] = cpu_to_le16(0x003f);
charlen = 1;
> Thanks in advance,
>
> Apr 1 04:23:49 UFR2 kernel: CIFS VFS: cifs_strtoUCS: char2uni returned
> -22
> Apr 1 04:37:14 UFR2 last message repeated 30 times
> Apr 1 04:38:53 UFR2 last message repeated 10 times
> Apr 1 04:40:33 UFR2 last message repeated 10 times
> Apr 1 04:45:31 UFR2 last message repeated 10 times
> Apr 1 04:47:11 UFR2 last message repeated 10 times
> Apr 1 05:00:32 UFR2 last message repeated 10 times
> Apr 1 05:07:21 UFR2 last message repeated 10 times
> Apr 1 05:21:50 UFR2 last message repeated 10 times
> Apr 1 05:23:29 UFR2 last message repeated 10 times
> Apr 1 05:29:07 UFR2 last message repeated 10 times
> Apr 1 05:30:58 UFR2 last message repeated 10 times
> Apr 1 05:30:58 UFR2 last message repeated 9 times
> Apr 1 05:55:33 UFR2 kernel: CIFS VFS: Error 0xfff3 on
> cifs_get_inode_info in lookup of \nv322657
> Apr 1 05:55:33 UFR2 kernel: CIFS VFS: Error 0xfff3 on
> cifs_get_inode_info in lookup of \nv322657
> Apr 1 06:28:41 UFR2 kernel: CIFS VFS: cifs_strtoUCS: char2uni returned
> -22
> Apr 1 07:24:36 UFR2 last message repeated 10 times
> Apr 1 07:26:29 UFR2 last message repeated 10 times
> Apr 1 07:28:17 UFR2 last message repeated 10 times
> Apr 1 07:30:09 UFR2 last message repeated 10 times
> Apr 1 07:35:45 UFR2 last message repeated 10 times
> Apr 1 07:44:46 UFR2 last message repeated 10 times
> Apr 1 08:23:10 UFR2 last message repeated 10 times
> Apr 1 08:24:52 UFR2 last message repeated 10 times
> Apr 1 10:04:37 UFR2 last message repeated 10 times
> Apr 1 10:04:37 UFR2 last message repeated 8 times
> Apr 1 10:36:17 UFR2 kernel: CIFS VFS: Error 0xfff3 on
> cifs_get_inode_info in lookup of \nv322657
> Apr 1 10:36:18 UFR2 last message repeated 4 times
> Apr 1 10:38:19 UFR2 kernel: CIFS VFS: cifs_strtoUCS: char2uni returned
> -22
>
>
> Valentin Zaharov
>
> System Department
>
> NetVision Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cifs and kthread_run / kernel_thread
Hi all,
I would like to use cifs inside linux-vserver guests. Discussion this with the
vserver people, we found that cifs is using the new kthread_run and the old
kernel_thread interface for starting kernel-threads. The old-style interface
renders cifs unusable inside a vserver-guest :-(
My questions:
i) Are there newer versions of cifs, where only kthread_run is used in all
places?
No - IIRC the original patch (for the switch of cifs from kernel_thread
to kthread) had a
minor implementation problem in handling the cifs_demultiplex thread, so
this one small
area was left with the old style.
iii) Is it difficult to switch to the new interface?
No, I don't think so, but I have not investigated it. We would be happy
to review and test a patch for this though.
gs cifs # grep kthread_run *.[ch]
cifsfs.c: oplockThread = kthread_run(cifs_oplock_thread,
NULL, "cifsoplockd");
cifsfs.c: dnotifyThread = kthread_run(cifs_dnotify_thread,
NULL, "cifsdnotifyd");
gs cifs # grep kernel_thread *.[ch]
cifs.mod.c: { 0x7e9ebb05, "kernel_thread" },
connect.c: rc = (int)kernel_thread((void *)(void
*)cifs_demultiplex_thread, srvTcp,
Thx,
Wilhelm
*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cifs and kthread_run / kernel_thread
Hi all,
I would like to use cifs inside linux-vserver guests. Discussion this with the
vserver people, we found that cifs is using the new kthread_run and the old
kernel_thread interface for starting kernel-threads. The old-style interface
renders cifs unusable inside a vserver-guest :-(
My questions:
i) Are there newer versions of cifs, where only kthread_run is used in all
places?
No - IIRC the original patch (for the switch of cifs from kernel_thread
to kthread) had a
minor implementation problem in handling the cifs_demultiplex thread, so
this one small
area was left with the old style.
iii) Is it difficult to switch to the new interface?
No, I don't think so, but I have not investigated it. We would be happy
to review and test a patch for this though.
gs cifs # grep kthread_run *.[ch]
cifsfs.c: oplockThread = kthread_run(cifs_oplock_thread,
NULL, cifsoplockd);
cifsfs.c: dnotifyThread = kthread_run(cifs_dnotify_thread,
NULL, cifsdnotifyd);
gs cifs # grep kernel_thread *.[ch]
cifs.mod.c: { 0x7e9ebb05, kernel_thread },
connect.c: rc = (int)kernel_thread((void *)(void
*)cifs_demultiplex_thread, srvTcp,
Thx,
Wilhelm
*
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: cifs causes BUG: soft lockup detected on CPU
Valentin Zaharov wrote on 04/01/2007 03:02:07 AM:
Hi again,
After applying changes manually to 2.6.20.4 according to the link that
Steven sent I still get those errors (attached below) but no crash so
far.
I am wondering if its ok or having errors still will cause freezes.
It is ok and I see no indication of lookup. You have two errors logged:
a) a missing entry in the kernel translation table for your default
codepage to UCS-16 (Unicode).
char2uni returned -22 (EINVAL, presumably due to a missing character)
b) some access denied (-13) warnings on cifs_get_info_info (lookup).
This is probably harmless.
We could isolate the failing character by modifying the error log entry
but you may be able to guess at the problem by seeing which filenames
are requested with '?' in it ('?' is used when translation to Unicode
fails)
We could probably isolate the missing character by checking what
is logged to dmesag after this minor modification to the warning
message (we would also need to know which nls codepage
you are running).
diff --git a/fs/cifs/cifs_unicode.c b/fs/cifs/cifs_unicode.c
index d2a8b29..793c4b9 100644
--- a/fs/cifs/cifs_unicode.c
+++ b/fs/cifs/cifs_unicode.c
@@ -74,8 +74,8 @@ cifs_strtoUCS(__le16 * to, const char *f
charlen = codepage-char2uni(from, len, wchar_to[i]);
if (charlen 1) {
cERROR(1,
- (cifs_strtoUCS: char2uni returned %d,
-charlen));
+ (strtoUCS: char2uni of %d returned %d,
+(int)*from, charlen));
/* A question mark */
to[i] = cpu_to_le16(0x003f);
charlen = 1;
Thanks in advance,
Apr 1 04:23:49 UFR2 kernel: CIFS VFS: cifs_strtoUCS: char2uni returned
-22
Apr 1 04:37:14 UFR2 last message repeated 30 times
Apr 1 04:38:53 UFR2 last message repeated 10 times
Apr 1 04:40:33 UFR2 last message repeated 10 times
Apr 1 04:45:31 UFR2 last message repeated 10 times
Apr 1 04:47:11 UFR2 last message repeated 10 times
Apr 1 05:00:32 UFR2 last message repeated 10 times
Apr 1 05:07:21 UFR2 last message repeated 10 times
Apr 1 05:21:50 UFR2 last message repeated 10 times
Apr 1 05:23:29 UFR2 last message repeated 10 times
Apr 1 05:29:07 UFR2 last message repeated 10 times
Apr 1 05:30:58 UFR2 last message repeated 10 times
Apr 1 05:30:58 UFR2 last message repeated 9 times
Apr 1 05:55:33 UFR2 kernel: CIFS VFS: Error 0xfff3 on
cifs_get_inode_info in lookup of \nv322657
Apr 1 05:55:33 UFR2 kernel: CIFS VFS: Error 0xfff3 on
cifs_get_inode_info in lookup of \nv322657
Apr 1 06:28:41 UFR2 kernel: CIFS VFS: cifs_strtoUCS: char2uni returned
-22
Apr 1 07:24:36 UFR2 last message repeated 10 times
Apr 1 07:26:29 UFR2 last message repeated 10 times
Apr 1 07:28:17 UFR2 last message repeated 10 times
Apr 1 07:30:09 UFR2 last message repeated 10 times
Apr 1 07:35:45 UFR2 last message repeated 10 times
Apr 1 07:44:46 UFR2 last message repeated 10 times
Apr 1 08:23:10 UFR2 last message repeated 10 times
Apr 1 08:24:52 UFR2 last message repeated 10 times
Apr 1 10:04:37 UFR2 last message repeated 10 times
Apr 1 10:04:37 UFR2 last message repeated 8 times
Apr 1 10:36:17 UFR2 kernel: CIFS VFS: Error 0xfff3 on
cifs_get_inode_info in lookup of \nv322657
Apr 1 10:36:18 UFR2 last message repeated 4 times
Apr 1 10:38:19 UFR2 kernel: CIFS VFS: cifs_strtoUCS: char2uni returned
-22
Valentin Zaharov
System Department
NetVision Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Can't mount NAS device
strace did show something useful mount(...) = -1 ENOTDIR (Not a directory) and then that led me to spotting the obvious bug which is on your NAS device (server). The server is returning a malformed (illegal) response. The Linux cifs client was getting a 22 byte response to a level 0x200 (FILE_UNIX_BASIC_INFO) request that is supposed to be 100 bytes. Basically connecting the mount to the server succeeded but the stat of "." (the top directory in the mount) failed since it is not recognized as a directory. When you disable the Unix Extensions on the client ie echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled you bypass the bug on the server, because the response to the call which is malformed is not issued (and an older infolevel is requested). If your server vendor produces a fix let me know and I can add the information about the required level of server to the Linux cifs client "how-to" / user's guide. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can't mount NAS device
strace did show something useful mount(...) = -1 ENOTDIR (Not a directory) and then that led me to spotting the obvious bug which is on your NAS device (server). The server is returning a malformed (illegal) response. The Linux cifs client was getting a 22 byte response to a level 0x200 (FILE_UNIX_BASIC_INFO) request that is supposed to be 100 bytes. Basically connecting the mount to the server succeeded but the stat of . (the top directory in the mount) failed since it is not recognized as a directory. When you disable the Unix Extensions on the client ie echo 0 /proc/fs/cifs/LinuxExtensionsEnabled you bypass the bug on the server, because the response to the call which is malformed is not issued (and an older infolevel is requested). If your server vendor produces a fix let me know and I can add the information about the required level of server to the Linux cifs client how-to / user's guide. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: [PATCH] consolidate generic_writepages and mpage_writepages]
From: Miklos Szeredi <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] consolidate generic_writepages and mpage_writepages
Date: Fri, 16 Feb 2007 17:23:25 +0100
From: Miklos Szeredi <[EMAIL PROTECTED]>
Clean up massive code duplication between mpage_writepages() and
generic_writepages().
The new generic function, write_cache_pages() takes a function pointer
argument, which will be called for each page to be written.
Maybe cifs_writepages() too can use this infrastructure, but I'm not
touching that with a ten-foot pole.
The cifs case ought to be one of the simpler ones, pseudo-code is pretty
easy, the hard part is all of the stuff unrelated to cifs:
Ideally if there were generic functions to help out, cifs writepages
would look roughly like the following
cifs_writepages(struct address_space *mapping, struct writeback_control
*wbc)
{
while (no more pages to write) {
/* find writeable file handle for this inode */
/* find the biggest set of contiguous pages that total less than
wsize */
if (packet signing is enabled)
/* write lock pages so they can not be changed under us
while we are calculating the checksum */
CIFSSMBWrite2(tree_connection, network_file_handle, array of
iovecs, number of iovecs);
if(packet signing was enabled)
/* unlock pages */
if(error) {
set page errors
if (mounted "hard" )
continue; /* retry */
else /* if no retry possible */
return error to caller;
}
update bytes written statistics
update index to point to next set of pages
} /* end while loop */
}
If it were even better, CIFSSMBWrite2 could be called async - so that it
did not have to wait for a network response from Samba (just an ack from
TCP), before issuing the next write onto the wire - but this would
require that we could queue a pointer to a completion routine to the mpx
entry.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: [PATCH] consolidate generic_writepages and mpage_writepages]
From: Miklos Szeredi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] consolidate generic_writepages and mpage_writepages
Date: Fri, 16 Feb 2007 17:23:25 +0100
From: Miklos Szeredi [EMAIL PROTECTED]
Clean up massive code duplication between mpage_writepages() and
generic_writepages().
The new generic function, write_cache_pages() takes a function pointer
argument, which will be called for each page to be written.
Maybe cifs_writepages() too can use this infrastructure, but I'm not
touching that with a ten-foot pole.
The cifs case ought to be one of the simpler ones, pseudo-code is pretty
easy, the hard part is all of the stuff unrelated to cifs:
Ideally if there were generic functions to help out, cifs writepages
would look roughly like the following
cifs_writepages(struct address_space *mapping, struct writeback_control
*wbc)
{
while (no more pages to write) {
/* find writeable file handle for this inode */
/* find the biggest set of contiguous pages that total less than
wsize */
if (packet signing is enabled)
/* write lock pages so they can not be changed under us
while we are calculating the checksum */
CIFSSMBWrite2(tree_connection, network_file_handle, array of
iovecs, number of iovecs);
if(packet signing was enabled)
/* unlock pages */
if(error) {
set page errors
if (mounted hard )
continue; /* retry */
else /* if no retry possible */
return error to caller;
}
update bytes written statistics
update index to point to next set of pages
} /* end while loop */
}
If it were even better, CIFSSMBWrite2 could be called async - so that it
did not have to wait for a network response from Samba (just an ack from
TCP), before issuing the next write onto the wire - but this would
require that we could queue a pointer to a completion routine to the mpx
entry.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How many people are using 2.6.16?
David Chinner wrote: On Wed, Jan 31, 2007 at 08:02:37AM +0100, Adrian Bunk wrote: On Tue, Jan 30, 2007 at 06:36:48PM -0800, Linus Torvalds wrote: The issue was somewhat confused by people certainly *reporting* it for older kernels. Also, as part of the dirty bit cleanups and sanity checkingwe did actually seem to fix a long-standing CIFS corruption (and apparently reisertfs/XFS problems too). But the *common* case was actually introduced with 2.6.19, and 2.6.16 wouldn't be affected. Thanks for the clarifications. Regarding the longstanding CIFS/reiserfs/XFS problems, it seems the status is: XFS: fix not yet in your tree With the WARN_ON() in cancel_dirty_page() removed: http://git2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ecdfc9787fe527491baefc22dce8b2dbd5b2908d XFS will behave exactly the same as 2.6.19 and previous releases. The patches I sent were only ever really workarounds to greatly reduce the race window that could lead to the warning being triggered. We really need Nick Piggin's invalidate/truncate/mmap race fixes to properly solve the XFS issues uncovered by Linus' changes. Given that we haven't had any reported cases of data corruption on XFS (and I couldn't trigger any even when seeing the warnings) I think we are fairly safe just maintaining the status quo and waiting the right fix to make it's way into the tree Cheers, Dave. We did have one bug report of data corruption in cifs on older kernels copying large files which this resolves, but 2.6.16 seems far enough to go back. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How many people are using 2.6.16?
David Chinner wrote: On Wed, Jan 31, 2007 at 08:02:37AM +0100, Adrian Bunk wrote: On Tue, Jan 30, 2007 at 06:36:48PM -0800, Linus Torvalds wrote: The issue was somewhat confused by people certainly *reporting* it for older kernels. Also, as part of the dirty bit cleanups and sanity checkingwe did actually seem to fix a long-standing CIFS corruption (and apparently reisertfs/XFS problems too). But the *common* case was actually introduced with 2.6.19, and 2.6.16 wouldn't be affected. Thanks for the clarifications. Regarding the longstanding CIFS/reiserfs/XFS problems, it seems the status is: XFS: fix not yet in your tree With the WARN_ON() in cancel_dirty_page() removed: http://git2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ecdfc9787fe527491baefc22dce8b2dbd5b2908d XFS will behave exactly the same as 2.6.19 and previous releases. The patches I sent were only ever really workarounds to greatly reduce the race window that could lead to the warning being triggered. We really need Nick Piggin's invalidate/truncate/mmap race fixes to properly solve the XFS issues uncovered by Linus' changes. Given that we haven't had any reported cases of data corruption on XFS (and I couldn't trigger any even when seeing the warnings) I think we are fairly safe just maintaining the status quo and waiting the right fix to make it's way into the tree Cheers, Dave. We did have one bug report of data corruption in cifs on older kernels copying large files which this resolves, but 2.6.16 seems far enough to go back. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
