On Fri, Mar 11, 2011 at 12:06 PM, Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > On Thu, Mar 10, 2011 at 10:33 PM, Steve French <smfrench@xxxxxxxxx> wrote: >> [PATCH] [CIFS] do not try to dump cifs mids from smb2 sessions >> >> Convert the debug routines in cifs_debug.c to recognize >> smb2 sessions and not try to dump invalid information on >> pending requests. Check the socket type to see if >> smb2. Move the printing of cifs specific debug information >> to a helper routine to make it clearer which type >> of information we are printing. >> >> cifs and smb2 both use the struct TCP_Server_Info to include information about >> the tcp socket connection to the server. The list of pending requests >> is one of the "per-socket" pieces of information. <snip> > I suppose there would not be a smb2_tcp_ses_lock! Right - with Jeff's suggestions about trying to share more of the transport code and cifs structures, the size of the three structures increases (to accommodate protocol enhancements) but we can reuse more of the transport code and use cifs's tcp_ses_lock and don't need an smb2 version of that. - struct TCP_Server_Info (per-socket, ie tcp session info) - struct cifs_ses (per user info for each socket, ie smb session info) - struct cifs_tcon (each share that we are connected to for each cifs_ses) > Also, although I have not see any issues, is it ok to take a spinlock > within a spinlock (GloablMid_Lock while holding cifs_tcp_ses_lock)? It is better not to nest spinlocks of course, but in this case we are careful to take them in the right order, and this is unchanged from the existing cifs code. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
