from:"Steven French"

Re: [GIT PULL] fscache rewrite -- please drop for now

2020-08-17 Thread Steven French




On 8/10/20 12:06 PM, Jeff Layton wrote:

On Mon, 2020-08-10 at 12:35 -0400, David Wysochanski wrote:

On Mon, Aug 10, 2020 at 11:48 AM David Howells  wrote:

Steve French  wrote:


cifs.ko also can set rsize quite small (even 1K for example, although
that will be more than 10x slower than the default 4MB so hopefully no
one is crazy enough to do that).

You can set rsize < PAGE_SIZE?


I can't imagine an SMB3 server negotiating an rsize or wsize smaller than
64K in today's world (and typical is 1MB to 8MB) but the user can specify a
much smaller rsize on mount.  If 64K is an adequate minimum, we could change
the cifs mount option parsing to require a certain minimum rsize if fscache
is selected.

I've borrowed the 256K granule size used by various AFS implementations for
the moment.  A 512-byte xattr can thus hold a bitmap covering 1G of file
space.



Is it possible to make the granule size configurable, then reject a
registration if the size is too small or not a power of 2?  Then a
netfs using the API could try to set equal to rsize, and then error
out with a message if the registration was rejected.


...or maybe we should just make fscache incompatible with an
rsize that isn't an even multiple of 256k? You need to set mount options
for both, typically, so it would be fairly trivial to check this at
mount time, I'd think.



Yes - if fscache is specified on mount it would be easy to round rsize 
up (or down), at least for cifs.ko (perhaps simply in the mount.cifs 
helper so a warning could be returned to the user) to whatever boundary 
you prefer in fscache.   The default of 4MB (or 1MB for mounts to some 
older servers) should be fine.  Similarly if the user requested the 
default but the server negotiated an unusual size, not a multiple of 
256K, we could round try to round it down if possible (or fail the mount 
if not possible to round it down to 256K).

Re: MAINTAINERS without commits in the last 3 years

2016-08-25 Thread Steven French

We can change mine from sfre...@samba.org to smbfre...@gmail.com since
Samba.org email is more awkward to get that gmail these days (I read it
less often) and I use a non-Samba.org email for my commits.


> On Aug 24, 2016, at 6:33 PM, Joe Perches  wrote:
> 
> Many email addresses in MAINTAINERS no longer work so many
> sections in
> MAINTAINERS could likely be considered either
> obsolete or unmaintained.
> 
> Marking these sections appropriately or simply removing the
> sections would make MAINTAINERS and get_maintainer.pl more
> useful.
> 
> These M: entries in MAINTAINERS haven't authored or had any
> -by: signature entries in git log for the last 3 years.
> 
> Some of these, like sta...@kernel.org and triv...@kernel.org, are
> obviously addresses that should not be deleted from MAINTAINERS,
> but most of them are candidates for removal or update.
> 
> The email addresses below are also bcc'd here to see what bounces.
> The list of the bounces will be collected.
> 
> Thoughts?
> 
> aacr...@adaptec.com
> aacr...@microsemi.com
> achim_leub...@adaptec.com
> adap...@gmail.com
> adilger.ker...@dilger.ca
> a...@cwi.nl
> ag...@suse.com
> a...@comnets.uni-bremen.de
> a...@alarsen.net
> ali...@web.de
> alist...@devzero.co.uk
> aloisio.alme...@openbossa.org
> andrew.d.henr...@intel.com
> andrew.hen...@gmail.com
> andre...@usa.net
> anil.s.keshavamur...@intel.com
> arhu...@freaks-unidos.net
> arvin...@gmail.com
> ath9k-de...@qca.qualcomm.com
> ballabio_da...@emc.com
> bcm-kernel-feedback-l...@broadcom.com
> ber...@plugable.com
> bi...@melbpc.org.au
> brij...@gmail.com
> brk...@us.ibm.com
> brucech...@via.com.tw
> castet.matth...@free.fr
> ccaul...@redhat.com
> cezary.jackiew...@gmail.com
> chaoming...@realsil.com.cn
> char...@alacritech.com
> chess...@tux.org
> chr...@sous-sol.org
> c...@cs.cmu.edu
> co...@colino.net
> courmi...@gmail.com
> dept-gelinuxnic...@qlogic.com
> dept-hsglinuxnic...@qlogic.com
> dev...@lanana.org
> dh.herrm...@googlemail.com
> d...@opfer-online.de
> dm-de...@redhat.com
> dmitry.tarnya...@lockless.no
> d...@syst.com.br
> d...@dotat.at
> douglas_warze...@dell.com
> dougthomp...@xmission.com
> drw...@gmail.com
> dsax...@plexity.net
> d...@gentoo.org
> duncan.sa...@free.fr
> e...@pasemi.com
> eib...@gdsys.de
> epa...@parisplace.org
> erik.and...@gmail.com
> everest-linux...@qlogic.com
> fa...@cs.unc.edu
> f...@drama.obuda.kando.hu
> fisc...@norbit.de
> fiz...@tin.it
> florian.c.schilha...@googlemail.com
> florianschandi...@gmx.de
> for...@alittletooquiet.net
> fr...@f-seidel.de
> fujita.tomon...@lab.ntt.co.jp
> fun...@jurai.org
> gilles.mul...@lip6.fr
> go...@debian.or.jp
> guillaume.lign...@gmail.com
> gust...@padovan.org
> hal.rosenst...@gmail.com
> haraldwe...@viatech.com
> henk.vergo...@gmail.com
> her...@canonical.com
> hlhun...@gmail.com
> hskinnem...@gmail.com
> hswon...@gmail.com
> hubert.feurst...@contec.at
> ibm-a...@hmh.eng.br
> inaky.perez-gonza...@intel.com
> infinip...@intel.com
> i...@jurassic.park.msu.ru
> intel-linux-...@intel.com
> io...@badula.org
> jansimon.moel...@gmx.de
> jarkko.lavi...@nokia.com
> ja...@wilsonet.com
> jayakumar.a...@gmail.com
> jay...@intworks.biz
> jclib...@gmail.com
> jd...@addtoit.com
> j.du...@option.com
> j...@parisc-linux.org
> jens.tapro...@taprogge.org
> jer...@goop.org
> j...@trained-monkey.org
> ji...@cam.ac.uk
> jirisl...@gmail.com
> jjcia...@raiz.uncu.edu.ar
> joc...@scram.de
> jo...@lazybastard.org
> johan.hedb...@gmail.com
> j...@johnmccutchan.com
> jonat...@buzzard.org.uk
> jon.nettle...@gmail.com
> josh.h.mor...@us.ibm.com
> j...@f6fbb.org
> jreu...@yaina.de
> j...@vanzandt.mv.com
> jtp.p...@samsung.com
> jue...@gmail.com
> juhle...@akamai.com
> k...@fi.muni.cz
> ker...@savoirfairelinux.com
> kevin.cur...@farsite.co.uk
> k...@gmx.de
> k...@reisers.ca
> klass...@mathematik.tu-chemnitz.de
> kou.ishiz...@toshiba.co.jp
> k...@deine-taler.de
> kuz...@ms2.inr.ac.ru
> lafo...@gnumonks.org
> lafo...@openezx.org
> lauro.venan...@openbossa.org
> lcostant...@gmail.com
> l...@flatcap.org
> l...@kernel.org
> lene...@twibble.org
> linasveps...@gmail.com
> linux-dri...@qlogic.com
> linuxdriv...@attotech.com
> linux-graphics-maintai...@vmware.com
> linux-ker...@hansmi.ch
> linux-net-driv...@solarflare.com
> linuxr...@lsi.com
> li...@simtec.co.uk
> linuxw...@intel.com
> linux-wi...@intel.com
> lio...@gmail.com
> liqin.li...@gmail.com
> m...@melware.de
> maintain...@bluecherrydvr.com
> mal...@foss.arm.com
> manohar.va...@gmail.com
> mark.brown...@gmail.com
> matt...@wil.cx
> m...@qti.qualcomm.com
> mbroe...@plusserver.de
> mcg...@gmail.com
> mche...@kernel.org
> mdharm-...@one-eyed-alien.net
> m...@sgi.com
> m.huls...@tudelft.nl
> miguel.ojeda.sando...@gmail.com
> m...@compulab.co.il
> miq...@df.uba.ar
> mi...@sfgoth.com
> m...@volny.cz
> m...@ucw.cz
> mkpe...@internode.on.net
> mostr...@earthlink.net
> m...@selenic.com
> mpor...@kernel.crashing.org
> mr.swami.re...@ti.com
> neepa...@cisco.com
> nic_s...@realtek.com
>

Re: MAINTAINERS without commits in the last 3 years

2016-08-25 Thread Steven French

We can change mine from sfre...@samba.org to smbfre...@gmail.com since
Samba.org email is more awkward to get that gmail these days (I read it
less often) and I use a non-Samba.org email for my commits.


> On Aug 24, 2016, at 6:33 PM, Joe Perches  wrote:
> 
> Many email addresses in MAINTAINERS no longer work so many
> sections in
> MAINTAINERS could likely be considered either
> obsolete or unmaintained.
> 
> Marking these sections appropriately or simply removing the
> sections would make MAINTAINERS and get_maintainer.pl more
> useful.
> 
> These M: entries in MAINTAINERS haven't authored or had any
> -by: signature entries in git log for the last 3 years.
> 
> Some of these, like sta...@kernel.org and triv...@kernel.org, are
> obviously addresses that should not be deleted from MAINTAINERS,
> but most of them are candidates for removal or update.
> 
> The email addresses below are also bcc'd here to see what bounces.
> The list of the bounces will be collected.
> 
> Thoughts?
> 
> aacr...@adaptec.com
> aacr...@microsemi.com
> achim_leub...@adaptec.com
> adap...@gmail.com
> adilger.ker...@dilger.ca
> a...@cwi.nl
> ag...@suse.com
> a...@comnets.uni-bremen.de
> a...@alarsen.net
> ali...@web.de
> alist...@devzero.co.uk
> aloisio.alme...@openbossa.org
> andrew.d.henr...@intel.com
> andrew.hen...@gmail.com
> andre...@usa.net
> anil.s.keshavamur...@intel.com
> arhu...@freaks-unidos.net
> arvin...@gmail.com
> ath9k-de...@qca.qualcomm.com
> ballabio_da...@emc.com
> bcm-kernel-feedback-l...@broadcom.com
> ber...@plugable.com
> bi...@melbpc.org.au
> brij...@gmail.com
> brk...@us.ibm.com
> brucech...@via.com.tw
> castet.matth...@free.fr
> ccaul...@redhat.com
> cezary.jackiew...@gmail.com
> chaoming...@realsil.com.cn
> char...@alacritech.com
> chess...@tux.org
> chr...@sous-sol.org
> c...@cs.cmu.edu
> co...@colino.net
> courmi...@gmail.com
> dept-gelinuxnic...@qlogic.com
> dept-hsglinuxnic...@qlogic.com
> dev...@lanana.org
> dh.herrm...@googlemail.com
> d...@opfer-online.de
> dm-de...@redhat.com
> dmitry.tarnya...@lockless.no
> d...@syst.com.br
> d...@dotat.at
> douglas_warze...@dell.com
> dougthomp...@xmission.com
> drw...@gmail.com
> dsax...@plexity.net
> d...@gentoo.org
> duncan.sa...@free.fr
> e...@pasemi.com
> eib...@gdsys.de
> epa...@parisplace.org
> erik.and...@gmail.com
> everest-linux...@qlogic.com
> fa...@cs.unc.edu
> f...@drama.obuda.kando.hu
> fisc...@norbit.de
> fiz...@tin.it
> florian.c.schilha...@googlemail.com
> florianschandi...@gmx.de
> for...@alittletooquiet.net
> fr...@f-seidel.de
> fujita.tomon...@lab.ntt.co.jp
> fun...@jurai.org
> gilles.mul...@lip6.fr
> go...@debian.or.jp
> guillaume.lign...@gmail.com
> gust...@padovan.org
> hal.rosenst...@gmail.com
> haraldwe...@viatech.com
> henk.vergo...@gmail.com
> her...@canonical.com
> hlhun...@gmail.com
> hskinnem...@gmail.com
> hswon...@gmail.com
> hubert.feurst...@contec.at
> ibm-a...@hmh.eng.br
> inaky.perez-gonza...@intel.com
> infinip...@intel.com
> i...@jurassic.park.msu.ru
> intel-linux-...@intel.com
> io...@badula.org
> jansimon.moel...@gmx.de
> jarkko.lavi...@nokia.com
> ja...@wilsonet.com
> jayakumar.a...@gmail.com
> jay...@intworks.biz
> jclib...@gmail.com
> jd...@addtoit.com
> j.du...@option.com
> j...@parisc-linux.org
> jens.tapro...@taprogge.org
> jer...@goop.org
> j...@trained-monkey.org
> ji...@cam.ac.uk
> jirisl...@gmail.com
> jjcia...@raiz.uncu.edu.ar
> joc...@scram.de
> jo...@lazybastard.org
> johan.hedb...@gmail.com
> j...@johnmccutchan.com
> jonat...@buzzard.org.uk
> jon.nettle...@gmail.com
> josh.h.mor...@us.ibm.com
> j...@f6fbb.org
> jreu...@yaina.de
> j...@vanzandt.mv.com
> jtp.p...@samsung.com
> jue...@gmail.com
> juhle...@akamai.com
> k...@fi.muni.cz
> ker...@savoirfairelinux.com
> kevin.cur...@farsite.co.uk
> k...@gmx.de
> k...@reisers.ca
> klass...@mathematik.tu-chemnitz.de
> kou.ishiz...@toshiba.co.jp
> k...@deine-taler.de
> kuz...@ms2.inr.ac.ru
> lafo...@gnumonks.org
> lafo...@openezx.org
> lauro.venan...@openbossa.org
> lcostant...@gmail.com
> l...@flatcap.org
> l...@kernel.org
> lene...@twibble.org
> linasveps...@gmail.com
> linux-dri...@qlogic.com
> linuxdriv...@attotech.com
> linux-graphics-maintai...@vmware.com
> linux-ker...@hansmi.ch
> linux-net-driv...@solarflare.com
> linuxr...@lsi.com
> li...@simtec.co.uk
> linuxw...@intel.com
> linux-wi...@intel.com
> lio...@gmail.com
> liqin.li...@gmail.com
> m...@melware.de
> maintain...@bluecherrydvr.com
> mal...@foss.arm.com
> manohar.va...@gmail.com
> mark.brown...@gmail.com
> matt...@wil.cx
> m...@qti.qualcomm.com
> mbroe...@plusserver.de
> mcg...@gmail.com
> mche...@kernel.org
> mdharm-...@one-eyed-alien.net
> m...@sgi.com
> m.huls...@tudelft.nl
> miguel.ojeda.sando...@gmail.com
> m...@compulab.co.il
> miq...@df.uba.ar
> mi...@sfgoth.com
> m...@volny.cz
> m...@ucw.cz
> mkpe...@internode.on.net
> mostr...@earthlink.net
> m...@selenic.com
> mpor...@kernel.crashing.org
> mr.swami.re...@ti.com
> neepa...@cisco.com
> nic_s...@realtek.com
> ning@intel.com
>

Re: [PATCH v1] cifs: use server timestamp for ntlmv2 authentication

2015-09-17 Thread Steven French

Nice catch.

Merged into cifs-2.6.git for next

> On Sep 17, 2015, at 2:40 PM, Peter Seiderer  wrote:
> 
> Linux cifs mount with ntlmssp against an Mac OS X (Yosemite
> 10.10.5) share fails in case the clocks differ more than +/-2h:
> 
> digest-service: digest-request: od failed with 2 proto=ntlmv2
> digest-service: digest-request: kdc failed with -1561745592 proto=ntlmv2
> 
> Fix this by (re-)using the given server timestamp for the
> ntlmv2 authentication (as Windows 7 does).
> 
> Signed-off-by: Peter Seiderer 
> ---
> fs/cifs/cifsencrypt.c | 53 +--
> 1 file changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
> index aa0dc25..e6bfa92 100644
> --- a/fs/cifs/cifsencrypt.c
> +++ b/fs/cifs/cifsencrypt.c
> @@ -444,6 +444,48 @@ find_domain_name(struct cifs_ses *ses, const struct 
> nls_table *nls_cp)
>   return 0;
> }
> 
> +/* Server has provided av pairs/target info in the type 2 challenge
> + * packet and we have plucked it and stored within smb session.
> + * We parse that blob here to find the server given timestamp
> + * as part of ntlmv2 authentication (or local current time as
> + * default in case of failure)
> + */
> +static u64
> +find_timestamp(struct cifs_ses *ses)
> +{
> + unsigned int attrsize;
> + unsigned int type;
> + unsigned int onesize = sizeof(struct ntlmssp2_name);
> + unsigned char *blobptr;
> + unsigned char *blobend;
> + struct ntlmssp2_name *attrptr;
> +
> + if (!ses->auth_key.len || !ses->auth_key.response)
> + return 0;
> +
> + blobptr = ses->auth_key.response;
> + blobend = blobptr + ses->auth_key.len;
> +
> + while (blobptr + onesize < blobend) {
> + attrptr = (struct ntlmssp2_name *) blobptr;
> + type = le16_to_cpu(attrptr->type);
> + if (type == NTLMSSP_AV_EOL)
> + break;
> + blobptr += 2; /* advance attr type */
> + attrsize = le16_to_cpu(attrptr->length);
> + blobptr += 2; /* advance attr size */
> + if (blobptr + attrsize > blobend)
> + break;
> + if (type == NTLMSSP_AV_TIMESTAMP) {
> + if (attrsize == sizeof(u64))
> + return *((u64 *)blobptr);
> + }
> + blobptr += attrsize; /* advance attr value */
> + }
> +
> + return cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME));
> +}
> +
> static int calc_ntlmv2_hash(struct cifs_ses *ses, char *ntlmv2_hash,
>   const struct nls_table *nls_cp)
> {
> @@ -641,6 +683,7 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct 
> nls_table *nls_cp)
>   struct ntlmv2_resp *ntlmv2;
>   char ntlmv2_hash[16];
>   unsigned char *tiblob = NULL; /* target info blob */
> + u64 rsp_timestamp;
> 
>   if (ses->server->negflavor == CIFS_NEGFLAVOR_EXTENDED) {
>   if (!ses->domainName) {
> @@ -659,6 +702,12 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct 
> nls_table *nls_cp)
>   }
>   }
> 
> + /* Must be within 5 minutes of the server (or in range +/-2h
> +  * in case of Mac OS X), so simply carry over server timestamp
> +  * (as Windows 7 does)
> +  */
> + rsp_timestamp = find_timestamp(ses);
> +
>   baselen = CIFS_SESS_KEY_SIZE + sizeof(struct ntlmv2_resp);
>   tilen = ses->auth_key.len;
>   tiblob = ses->auth_key.response;
> @@ -675,8 +724,8 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct 
> nls_table *nls_cp)
>   (ses->auth_key.response + CIFS_SESS_KEY_SIZE);
>   ntlmv2->blob_signature = cpu_to_le32(0x0101);
>   ntlmv2->reserved = 0;
> - /* Must be within 5 minutes of the server */
> - ntlmv2->time = cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME));
> + ntlmv2->time = rsp_timestamp;
> +
>   get_random_bytes(>client_chal, sizeof(ntlmv2->client_chal));
>   ntlmv2->reserved2 = 0;
> 
> -- 
> 2.1.4
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1] cifs: use server timestamp for ntlmv2 authentication

2015-09-17 Thread Steven French

Nice catch.

Merged into cifs-2.6.git for next

> On Sep 17, 2015, at 2:40 PM, Peter Seiderer  wrote:
> 
> Linux cifs mount with ntlmssp against an Mac OS X (Yosemite
> 10.10.5) share fails in case the clocks differ more than +/-2h:
> 
> digest-service: digest-request: od failed with 2 proto=ntlmv2
> digest-service: digest-request: kdc failed with -1561745592 proto=ntlmv2
> 
> Fix this by (re-)using the given server timestamp for the
> ntlmv2 authentication (as Windows 7 does).
> 
> Signed-off-by: Peter Seiderer 
> ---
> fs/cifs/cifsencrypt.c | 53 +--
> 1 file changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
> index aa0dc25..e6bfa92 100644
> --- a/fs/cifs/cifsencrypt.c
> +++ b/fs/cifs/cifsencrypt.c
> @@ -444,6 +444,48 @@ find_domain_name(struct cifs_ses *ses, const struct 
> nls_table *nls_cp)
>   return 0;
> }
> 
> +/* Server has provided av pairs/target info in the type 2 challenge
> + * packet and we have plucked it and stored within smb session.
> + * We parse that blob here to find the server given timestamp
> + * as part of ntlmv2 authentication (or local current time as
> + * default in case of failure)
> + */
> +static u64
> +find_timestamp(struct cifs_ses *ses)
> +{
> + unsigned int attrsize;
> + unsigned int type;
> + unsigned int onesize = sizeof(struct ntlmssp2_name);
> + unsigned char *blobptr;
> + unsigned char *blobend;
> + struct ntlmssp2_name *attrptr;
> +
> + if (!ses->auth_key.len || !ses->auth_key.response)
> + return 0;
> +
> + blobptr = ses->auth_key.response;
> + blobend = blobptr + ses->auth_key.len;
> +
> + while (blobptr + onesize < blobend) {
> + attrptr = (struct ntlmssp2_name *) blobptr;
> + type = le16_to_cpu(attrptr->type);
> + if (type == NTLMSSP_AV_EOL)
> + break;
> + blobptr += 2; /* advance attr type */
> + attrsize = le16_to_cpu(attrptr->length);
> + blobptr += 2; /* advance attr size */
> + if (blobptr + attrsize > blobend)
> + break;
> + if (type == NTLMSSP_AV_TIMESTAMP) {
> + if (attrsize == sizeof(u64))
> + return *((u64 *)blobptr);
> + }
> + blobptr += attrsize; /* advance attr value */
> + }
> +
> + return cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME));
> +}
> +
> static int calc_ntlmv2_hash(struct cifs_ses *ses, char *ntlmv2_hash,
>   const struct nls_table *nls_cp)
> {
> @@ -641,6 +683,7 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct 
> nls_table *nls_cp)
>   struct ntlmv2_resp *ntlmv2;
>   char ntlmv2_hash[16];
>   unsigned char *tiblob = NULL; /* target info blob */
> + u64 rsp_timestamp;
> 
>   if (ses->server->negflavor == CIFS_NEGFLAVOR_EXTENDED) {
>   if (!ses->domainName) {
> @@ -659,6 +702,12 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct 
> nls_table *nls_cp)
>   }
>   }
> 
> + /* Must be within 5 minutes of the server (or in range +/-2h
> +  * in case of Mac OS X), so simply carry over server timestamp
> +  * (as Windows 7 does)
> +  */
> + rsp_timestamp = find_timestamp(ses);
> +
>   baselen = CIFS_SESS_KEY_SIZE + sizeof(struct ntlmv2_resp);
>   tilen = ses->auth_key.len;
>   tiblob = ses->auth_key.response;
> @@ -675,8 +724,8 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct 
> nls_table *nls_cp)
>   (ses->auth_key.response + CIFS_SESS_KEY_SIZE);
>   ntlmv2->blob_signature = cpu_to_le32(0x0101);
>   ntlmv2->reserved = 0;
> - /* Must be within 5 minutes of the server */
> - ntlmv2->time = cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME));
> + ntlmv2->time = rsp_timestamp;
> +
>   get_random_bytes(>client_chal, sizeof(ntlmv2->client_chal));
>   ntlmv2->reserved2 = 0;
> 
> -- 
> 2.1.4
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: struct cifs_dfs_referral_inode_operations is unused

2008-01-28 Thread Steven French

We have one DFS patch remaining to merge and then will need to do a 
cleanup patch


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com



Adrian Bunk <[EMAIL PROTECTED]> 
01/28/2008 04:11 PM

To
Igor Mammedov <[EMAIL PROTECTED]>, Steven French/Austin/[EMAIL PROTECTED]
cc
[EMAIL PROTECTED], linux-kernel@vger.kernel.org
Subject
struct cifs_dfs_referral_inode_operations is unused






struct cifs_dfs_referral_inode_operations is unused, which does not seem 
to have been intended?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed



--
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: struct cifs_dfs_referral_inode_operations is unused

2008-01-28 Thread Steven French

We have one DFS patch remaining to merge and then will need to do a 
cleanup patch


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com



Adrian Bunk [EMAIL PROTECTED] 
01/28/2008 04:11 PM

To
Igor Mammedov [EMAIL PROTECTED], Steven French/Austin/[EMAIL PROTECTED]
cc
[EMAIL PROTECTED], linux-kernel@vger.kernel.org
Subject
struct cifs_dfs_referral_inode_operations is unused






struct cifs_dfs_referral_inode_operations is unused, which does not seem 
to have been intended?

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed



--
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: 2.6.22-rc1-mm1 cifs_mount oops

2007-05-23 Thread Steven French

If srvTcp->tsk is NULL then the thread (cifs_demultiplex_thread) is 
getting ready to exit and kthread_stop would not be needed.

It would probably be possible to recode this so we don't need to call 
kthread_stop at all (send_sig is apparently required to wake up this 
thread when blocked in certain places in the tcp stack - and in 
combination with the existing flags might be good enough) - but I don't 
know if it would make it simpler.Fortunately there is no race, a few 
lines after srvTcp->tsk is set to zero by the cifs_demultipex_thread, it 
will sleep briefly before exiting (kthread_stop won't be called on a 
thread that does not exist).

That section of code in fs/cifs/connect.c now looks like:

2071 if (srvTcp->tsk) {
2072 struct task_struct *tsk;
2073 
/* If we could verify that kthread_stop would
2074 
   always wake up processes blocked in
2075 
   tcp in recv_mesg then we could remove the
2076send_sig call */
2077 send_sig(SIGKILL,srvTcp->tsk,1);
2078 tsk = srvTcp->tsk;
2079 if(tsk)
2080 kthread_stop(srvTcp->tsk);
2081 }
2082 }
2083 
 /* If find_unc succeeded then rc == 0 so we can not end */
2084 
if (tcon)  /* up accidently freeing someone elses tcon struct */
2085 tconInfoFree(tcon);
2086 if (existingCifsSes == NULL) {
2087 if (pSesInfo) {
2088 if ((pSesInfo->server) && 
2089 (pSesInfo->status == CifsGood)) {
2090 int temp_rc;
2091 
temp_rc = CIFSSMBLogoff(xid, pSesInfo);
2092 
/* if the socketUseCount is now zero */
2093 
if ((temp_rc == -ESHUTDOWN) &&
2094 
   (pSesInfo->server) && 
(pSesInfo->server->tsk)) {
2095 
struct task_struct *tsk;
2096 

send_sig(SIGKILL,pSesInfo->server->tsk,1);
2097 
tsk = pSesInfo->server->tsk;
2098 if(tsk)
2099 
kthread_stop(tsk);


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com



"young dave" <[EMAIL PROTECTED]> 
05/23/2007 08:05 PM

To
Steven French/Austin/[EMAIL PROTECTED]
cc
"Andrew Morton" <[EMAIL PROTECTED]>, David 
Kleikamp/Austin/[EMAIL PROTECTED], "Linux Kernel Mailing List" 
, Shirish S Pargaonkar/Austin/[EMAIL PROTECTED]
Subject
Re: 2.6.22-rc1-mm1 cifs_mount oops






Hi,

I have one problem about this:  after the srvTcp->tsk is set to NULL
(maybe the thread is  still there, isn't it?), is the kthread still
needed to be stopped by calling kthread_stop()? If it is true, then
the task_struct should be saved before send_sig like my patch:

if (srvTcp->tsk) {
+   struct task_struct * tsk = srvTcp->tsk;
   send_sig(SIGKILL,srvTcp->tsk,1);
-   kthread_stop(srvTcp->tsk);
+   kthread_stop(tsk);

Regards
dave


-
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: 2.6.22-rc1-mm1 cifs_mount oops

2007-05-23 Thread Steven French

> This can end up running kthread_stop() against an already-exited task.
I don't think so since cifs_demultiplex_thread waits sufficiently long 
before 
exit but after setting srvTcp->tsk to zero (the wait is immediately after 
waking up any processes that may be blocked on requests on this socket to 
give
file requests time to exit from the cifs vfs).   As long as this (mount) 
process were 
scheduled within 1.25 seconds it should be ok although more complicated 
than I
would like (that is why this thread was the last one in cifs to switch
to kthread API).

I wish there were an obvious way to do this, perhaps without using 
kthread_stop at all
for this thread (since that by itself does not seem to work for threads 
blocked 
in various socket calls).


--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2069,8 +2069,12 @@ cifs_mount(struct super_block *sb, struct 
cifs_sb_info *cifs_sb,
 srvTcp->tcpStatus = 
CifsExiting;
 spin_unlock(_Lock);
 if (srvTcp->tsk) {
 struct 
task_struct *tsk;
 send_sig(SIGKILL,srvTcp->tsk,1);
- kthread_stop(srvTcp->tsk);
+/* 
srvTcp->tsk can be zeroed at any time */
+tsk = 
srvTcp->tsk;
+if (tsk)
+  kthread_stop(tsk);
 }


I don't think so 


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
-
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: 2.6.22-rc1-mm1 cifs_mount oops

2007-05-23 Thread Steven French

I don't think it is racy against thread startup since server->tsk is not 
filled in until after the demultiplex thread does allow_signal.

I looked more at each of the three send_sig calls which precede the three 
places we do kthread_stop on this thread.   Without the three send_sig 
calls (e.g. in the umount path) umount takes 7 more seconds (presumably 
because the socket does not wake up as quickly) - so at first glance it 
looks like we still need a way of waking up this thread when it is stuck 
in a socket - and send_sig is the obvious way to do it.
I will merge Shaggy's version (similar to Dave Young's) into the cifs-2.6 
tree now.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com



Andrew Morton <[EMAIL PROTECTED]> 
05/22/2007 09:22 PM

To
"young dave" <[EMAIL PROTECTED]>
cc
"Linux Kernel Mailing List" , Steven 
French/Austin/[EMAIL PROTECTED]
Subject
Re: 2.6.22-rc1-mm1 cifs_mount oops






On Wed, 23 May 2007 00:50:13 + "young dave" 
<[EMAIL PROTECTED]> wrote:

> Hi,
> when I use mount -t cifs , the kernel oops, seems break at
> kthread_stop, I'm not sure.
> 
> But if I add the CONFIG_CIFS_DEBUG2=y to config file, rebuild kernel,
> then the oops disappeared.
> 
> Below is the oops message:
> 
> BUG: unable to handle kernel NULL pointer dereference at virtual
> address 0008
>  printing eip:
> c012e910
> *pde = 
> Oops: 0002 [#1]
> PREEMPT
> Modules linked in: cifs smbfs radeon drm ipv6 snd_seq_dummy
> snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> snd_mixer_oss capability commoncap e100 mii psmouse sg evdev serio_raw
> snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc intel_agp
> agpgart i2c_i801 pcspkr
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00210246   (2.6.22-rc1-mm1 #3)
> EIP is at kthread_stop+0x10/0x90
> eax: c051bde0   ebx:    ecx: c1fba000   edx: c1fef040
> esi:    edi: 0064   ebp: c2a36c80   esp: c1fbbd58
> ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
> Process mount.cifs (pid: 3955, ti=c1fba000 task=c2b38540 
task.ti=c1fba000)
> Stack: c1fef040 ff90 ff90 f8a7a328 c285a504 f8a9a9fb 0083 
00cf
>00dc 000b c2b38540 c2af5740 c292c540   
c285a4c0
> c411b400 c3a4f500 c3cec200 c1fef052 c291c1e0 c1fef037 
c291c940
> Call Trace:
>  [] cifs_mount+0xbe8/0xf10 [cifs]
>  [] idr_get_new_above_int+0x3e/0x50
>  [] cifs_read_super+0x4e/0x160 [cifs]
>  [] set_anon_super+0x0/0xd0
>  [] cifs_get_sb+0x60/0xd0 [cifs]
>  [] vfs_kern_mount+0x91/0x130
>  [] permit_mount+0x28/0xa0
>  [] do_new_mount+0x8a/0x140
>  [] do_mount+0x25e/0x280
>  [] schedule+0x2e0/0x680
>  [] exact_copy_from_user+0x32/0x70
>  [] copy_mount_options+0x5a/0xc0
>  [] sys_mount+0x79/0xc0
>  [] syscall_call+0x7/0xb
>  ===
> Code: 88 d1 d3 e0 89 43 5c 83 c4 18 5b c3 eb 0d 90 90 90 90 90 90 90
> 90 90 90 90 90 90 53 83 ec 08 89 c3 b8 e0 bd 51 c0 e8 90 26 31 00 
> 43 08 31 c9 b8 f0 c1 58 c0 89 0d ec c1 58 c0 e8 3b 01 00 00
> EIP: [] kthread_stop+0x10/0x90 SS:ESP 0068:c1fbbd58
> 

I assume cifs_demultiplex_thread() took the SIGKILL, zeroed server->tsk
then exitted.  Then, cifs_mount() did a kthread_stop() on the now-NULL
pointer.

I don't see a non-racy way of fixing this as the code stands at present. 
This:

--- a/fs/cifs/connect.c~cifs-oops-fix
+++ a/fs/cifs/connect.c
@@ -2086,7 +2086,6 @@ cifs_mount(struct super_block *sb, struc
  if ((temp_rc == -ESHUTDOWN) &&
 (pSesInfo->server) && (pSesInfo->server->tsk)) {
 send_sig(SIGKILL,pSesInfo->server->tsk,1);
-kthread_stop(pSesInfo->server->tsk);
  }
 } else
  cFYI(1, ("No session or bad tcon"));
_

has a decent chance of fixing it.  But it's now racy against thread
*startup*: if we send SIGKILL to that task before it has done its
allow_signal(), it will presumably never get shut down.

Steve, can we just pull all the signal stuff out of there and use the
kthread machinery alone?



-
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: 2.6.22-rc1-mm1 cifs_mount oops

2007-05-23 Thread Steven French

Yes - this patch looks better.

I also am not sure whether the send_sig is still necessary to wake up a 
thread blocked in tcp recv_msg (only do a wake_up_process vs. doing a 
send_sig(SIGKILL) )

Unless someone knows for sure whether the send_sig is redundant, I would 
like to merge Shaggy's version of the patch


"young dave" <[EMAIL PROTECTED]> wrote on 05/23/2007 03:37:04 AM:

> Hi,
> Sorry for the wrong patch in my last post.
> 
> How about save the tsk then call kthread_stop like this:
> 
> diff -udr linux/fs/cifs/connect.c linux.new/fs/cifs/connect.c
> --- linux/fs/cifs/connect.c 2007-05-23 10:59:13.0 +
> +++ linux.new/fs/cifs/connect.c 2007-05-23 16:33:54.0 +
> @@ -2069,8 +2069,9 @@
> srvTcp->tcpStatus = CifsExiting;
> spin_unlock(_Lock);
> if (srvTcp->tsk) {
> +   struct task_struct * tsk = srvTcp->tsk;
> send_sig(SIGKILL,srvTcp->tsk,1);
> -   kthread_stop(srvTcp->tsk);
> +   kthread_stop(tsk);
> }
> }
>  /* If find_unc succeeded then rc == 0 so we can not end 
*/
> 
> Regards
> dave

Shaggy's suggested patch seems slightly better:

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 216fb62..b6e2158 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2069,8 +2069,12 @@ cifs_mount(struct super_block *sb, struct 
cifs_sb_info *cifs_sb,
 srvTcp->tcpStatus = 
CifsExiting;
 spin_unlock(_Lock);
 if (srvTcp->tsk) {
+struct 
task_struct *tsk;
 send_sig(SIGKILL,srvTcp->tsk,1);
- kthread_stop(srvTcp->tsk);
+/* 
srvTcp->tsk can be zeroed at any time */
+tsk = 
srvTcp->tsk;
+if (tsk)
+  kthread_stop(tsk);
 }
 }
  /* If find_unc succeeded then rc == 0 so 
we can not end */

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
-
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: 2.6.22-rc1-mm1 cifs_mount oops

2007-05-23 Thread Steven French

Yes - this patch looks better.

I also am not sure whether the send_sig is still necessary to wake up a 
thread blocked in tcp recv_msg (only do a wake_up_process vs. doing a 
send_sig(SIGKILL) )

Unless someone knows for sure whether the send_sig is redundant, I would 
like to merge Shaggy's version of the patch


young dave [EMAIL PROTECTED] wrote on 05/23/2007 03:37:04 AM:

 Hi,
 Sorry for the wrong patch in my last post.
 
 How about save the tsk then call kthread_stop like this:
 
 diff -udr linux/fs/cifs/connect.c linux.new/fs/cifs/connect.c
 --- linux/fs/cifs/connect.c 2007-05-23 10:59:13.0 +
 +++ linux.new/fs/cifs/connect.c 2007-05-23 16:33:54.0 +
 @@ -2069,8 +2069,9 @@
 srvTcp-tcpStatus = CifsExiting;
 spin_unlock(GlobalMid_Lock);
 if (srvTcp-tsk) {
 +   struct task_struct * tsk = srvTcp-tsk;
 send_sig(SIGKILL,srvTcp-tsk,1);
 -   kthread_stop(srvTcp-tsk);
 +   kthread_stop(tsk);
 }
 }
  /* If find_unc succeeded then rc == 0 so we can not end 
*/
 
 Regards
 dave

Shaggy's suggested patch seems slightly better:

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 216fb62..b6e2158 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2069,8 +2069,12 @@ cifs_mount(struct super_block *sb, struct 
cifs_sb_info *cifs_sb,
 srvTcp-tcpStatus = 
CifsExiting;
 spin_unlock(GlobalMid_Lock);
 if (srvTcp-tsk) {
+struct 
task_struct *tsk;
 send_sig(SIGKILL,srvTcp-tsk,1);
- kthread_stop(srvTcp-tsk);
+/* 
srvTcp-tsk can be zeroed at any time */
+tsk = 
srvTcp-tsk;
+if (tsk)
+  kthread_stop(tsk);
 }
 }
  /* If find_unc succeeded then rc == 0 so 
we can not end */

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
-
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: 2.6.22-rc1-mm1 cifs_mount oops

2007-05-23 Thread Steven French

I don't think it is racy against thread startup since server-tsk is not 
filled in until after the demultiplex thread does allow_signal.

I looked more at each of the three send_sig calls which precede the three 
places we do kthread_stop on this thread.   Without the three send_sig 
calls (e.g. in the umount path) umount takes 7 more seconds (presumably 
because the socket does not wake up as quickly) - so at first glance it 
looks like we still need a way of waking up this thread when it is stuck 
in a socket - and send_sig is the obvious way to do it.
I will merge Shaggy's version (similar to Dave Young's) into the cifs-2.6 
tree now.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com



Andrew Morton [EMAIL PROTECTED] 
05/22/2007 09:22 PM

To
young dave [EMAIL PROTECTED]
cc
Linux Kernel Mailing List linux-kernel@vger.kernel.org, Steven 
French/Austin/[EMAIL PROTECTED]
Subject
Re: 2.6.22-rc1-mm1 cifs_mount oops






On Wed, 23 May 2007 00:50:13 + young dave 
[EMAIL PROTECTED] wrote:

 Hi,
 when I use mount -t cifs , the kernel oops, seems break at
 kthread_stop, I'm not sure.
 
 But if I add the CONFIG_CIFS_DEBUG2=y to config file, rebuild kernel,
 then the oops disappeared.
 
 Below is the oops message:
 
 BUG: unable to handle kernel NULL pointer dereference at virtual
 address 0008
  printing eip:
 c012e910
 *pde = 
 Oops: 0002 [#1]
 PREEMPT
 Modules linked in: cifs smbfs radeon drm ipv6 snd_seq_dummy
 snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
 snd_mixer_oss capability commoncap e100 mii psmouse sg evdev serio_raw
 snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc intel_agp
 agpgart i2c_i801 pcspkr
 CPU:0
 EIP:0060:[c012e910]Not tainted VLI
 EFLAGS: 00210246   (2.6.22-rc1-mm1 #3)
 EIP is at kthread_stop+0x10/0x90
 eax: c051bde0   ebx:    ecx: c1fba000   edx: c1fef040
 esi:    edi: 0064   ebp: c2a36c80   esp: c1fbbd58
 ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
 Process mount.cifs (pid: 3955, ti=c1fba000 task=c2b38540 
task.ti=c1fba000)
 Stack: c1fef040 ff90 ff90 f8a7a328 c285a504 f8a9a9fb 0083 
00cf
00dc 000b c2b38540 c2af5740 c292c540   
c285a4c0
 c411b400 c3a4f500 c3cec200 c1fef052 c291c1e0 c1fef037 
c291c940
 Call Trace:
  [f8a7a328] cifs_mount+0xbe8/0xf10 [cifs]
  [c02633fe] idr_get_new_above_int+0x3e/0x50
  [f8a6d04e] cifs_read_super+0x4e/0x160 [cifs]
  [c0166fc0] set_anon_super+0x0/0xd0
  [f8a6d6c0] cifs_get_sb+0x60/0xd0 [cifs]
  [c0167491] vfs_kern_mount+0x91/0x130
  [c017d648] permit_mount+0x28/0xa0
  [c017e09a] do_new_mount+0x8a/0x140
  [c017e95e] do_mount+0x25e/0x280
  [c044] schedule+0x2e0/0x680
  [c017e602] exact_copy_from_user+0x32/0x70
  [c017e69a] copy_mount_options+0x5a/0xc0
  [c017ec19] sys_mount+0x79/0xc0
  [c01040bc] syscall_call+0x7/0xb
  ===
 Code: 88 d1 d3 e0 89 43 5c 83 c4 18 5b c3 eb 0d 90 90 90 90 90 90 90
 90 90 90 90 90 90 53 83 ec 08 89 c3 b8 e0 bd 51 c0 e8 90 26 31 00 ff
 43 08 31 c9 b8 f0 c1 58 c0 89 0d ec c1 58 c0 e8 3b 01 00 00
 EIP: [c012e910] kthread_stop+0x10/0x90 SS:ESP 0068:c1fbbd58
 

I assume cifs_demultiplex_thread() took the SIGKILL, zeroed server-tsk
then exitted.  Then, cifs_mount() did a kthread_stop() on the now-NULL
pointer.

I don't see a non-racy way of fixing this as the code stands at present. 
This:

--- a/fs/cifs/connect.c~cifs-oops-fix
+++ a/fs/cifs/connect.c
@@ -2086,7 +2086,6 @@ cifs_mount(struct super_block *sb, struc
  if ((temp_rc == -ESHUTDOWN) 
 (pSesInfo-server)  (pSesInfo-server-tsk)) {
 send_sig(SIGKILL,pSesInfo-server-tsk,1);
-kthread_stop(pSesInfo-server-tsk);
  }
 } else
  cFYI(1, (No session or bad tcon));
_

has a decent chance of fixing it.  But it's now racy against thread
*startup*: if we send SIGKILL to that task before it has done its
allow_signal(), it will presumably never get shut down.

Steve, can we just pull all the signal stuff out of there and use the
kthread machinery alone?



-
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: 2.6.22-rc1-mm1 cifs_mount oops

2007-05-23 Thread Steven French

 This can end up running kthread_stop() against an already-exited task.
I don't think so since cifs_demultiplex_thread waits sufficiently long 
before 
exit but after setting srvTcp-tsk to zero (the wait is immediately after 
waking up any processes that may be blocked on requests on this socket to 
give
file requests time to exit from the cifs vfs).   As long as this (mount) 
process were 
scheduled within 1.25 seconds it should be ok although more complicated 
than I
would like (that is why this thread was the last one in cifs to switch
to kthread API).

I wish there were an obvious way to do this, perhaps without using 
kthread_stop at all
for this thread (since that by itself does not seem to work for threads 
blocked 
in various socket calls).


--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2069,8 +2069,12 @@ cifs_mount(struct super_block *sb, struct 
cifs_sb_info *cifs_sb,
 srvTcp-tcpStatus = 
CifsExiting;
 spin_unlock(GlobalMid_Lock);
 if (srvTcp-tsk) {
 struct 
task_struct *tsk;
 send_sig(SIGKILL,srvTcp-tsk,1);
- kthread_stop(srvTcp-tsk);
+/* 
srvTcp-tsk can be zeroed at any time */
+tsk = 
srvTcp-tsk;
+if (tsk)
+  kthread_stop(tsk);
 }


I don't think so 


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
-
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: 2.6.22-rc1-mm1 cifs_mount oops

2007-05-23 Thread Steven French

If srvTcp-tsk is NULL then the thread (cifs_demultiplex_thread) is 
getting ready to exit and kthread_stop would not be needed.

It would probably be possible to recode this so we don't need to call 
kthread_stop at all (send_sig is apparently required to wake up this 
thread when blocked in certain places in the tcp stack - and in 
combination with the existing flags might be good enough) - but I don't 
know if it would make it simpler.Fortunately there is no race, a few 
lines after srvTcp-tsk is set to zero by the cifs_demultipex_thread, it 
will sleep briefly before exiting (kthread_stop won't be called on a 
thread that does not exist).

That section of code in fs/cifs/connect.c now looks like:

2071 if (srvTcp-tsk) {
2072 struct task_struct *tsk;
2073 
/* If we could verify that kthread_stop would
2074 
   always wake up processes blocked in
2075 
   tcp in recv_mesg then we could remove the
2076send_sig call */
2077 send_sig(SIGKILL,srvTcp-tsk,1);
2078 tsk = srvTcp-tsk;
2079 if(tsk)
2080 kthread_stop(srvTcp-tsk);
2081 }
2082 }
2083 
 /* If find_unc succeeded then rc == 0 so we can not end */
2084 
if (tcon)  /* up accidently freeing someone elses tcon struct */
2085 tconInfoFree(tcon);
2086 if (existingCifsSes == NULL) {
2087 if (pSesInfo) {
2088 if ((pSesInfo-server)  
2089 (pSesInfo-status == CifsGood)) {
2090 int temp_rc;
2091 
temp_rc = CIFSSMBLogoff(xid, pSesInfo);
2092 
/* if the socketUseCount is now zero */
2093 
if ((temp_rc == -ESHUTDOWN) 
2094 
   (pSesInfo-server)  
(pSesInfo-server-tsk)) {
2095 
struct task_struct *tsk;
2096 

send_sig(SIGKILL,pSesInfo-server-tsk,1);
2097 
tsk = pSesInfo-server-tsk;
2098 if(tsk)
2099 
kthread_stop(tsk);


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com



young dave [EMAIL PROTECTED] 
05/23/2007 08:05 PM

To
Steven French/Austin/[EMAIL PROTECTED]
cc
Andrew Morton [EMAIL PROTECTED], David 
Kleikamp/Austin/[EMAIL PROTECTED], Linux Kernel Mailing List 
linux-kernel@vger.kernel.org, Shirish S Pargaonkar/Austin/[EMAIL PROTECTED]
Subject
Re: 2.6.22-rc1-mm1 cifs_mount oops






Hi,

I have one problem about this:  after the srvTcp-tsk is set to NULL
(maybe the thread is  still there, isn't it?), is the kthread still
needed to be stopped by calling kthread_stop()? If it is true, then
the task_struct should be saved before send_sig like my patch:

if (srvTcp-tsk) {
+   struct task_struct * tsk = srvTcp-tsk;
   send_sig(SIGKILL,srvTcp-tsk,1);
-   kthread_stop(srvTcp-tsk);
+   kthread_stop(tsk);

Regards
dave


-
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

2007-03-29 Thread Steven French

This should be fixed in 2.6.21 as of 2/26.  The fix was 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3677db10a635a39f63ea509f8f0056d95589ff90


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

Andrew Morton <[EMAIL PROTECTED]> wrote on 03/29/2007 03:54:57 AM:

> On Wed, 28 Mar 2007 20:35:55 +0200 "Valentin Zaharov" 
> <[EMAIL PROTECTED]> wrote:
> 
> > Hi,
> > 
> > We have continous problem with server freezes. We are using cifs 
mounts
> > on apache powered web servers with content located on Win2k3 server.
> > Servers freeze from time to time, producing following error just 
before
> > freeze:
> > 
> > Mar 26 21:50:37 UFR2 kernel:  CIFS VFS: cifs_strtoUCS: char2uni 
returned
> > -22 Mar 26 21:51:45 UFR2 last message repeated 55 times Mar 26 
21:52:49
> > UFR2 last message repeated 30 times Mar 26 21:54:16 UFR2 last message
> > repeated 10 times Mar 26 21:56:13 UFR2 last message repeated 20 times
> > Mar 26 21:58:34 UFR2 last message repeated 75 times Mar 26 21:59:43 
UFR2
> > last message repeated 30 times Mar 26 22:01:02 UFR2 last message
> > repeated 30 times Mar 26 22:02:04 UFR2 last message repeated 30 times
> > Mar 26 22:03:08 UFR2 last message repeated 50 times Mar 26 22:04:27 
UFR2
> > last message repeated 10 times Mar 26 22:05:59 UFR2 last message
> > repeated 20 times Mar 26 22:07:10 UFR2 last message repeated 20 times
> > Mar 26 22:29:00 UFR2 last message repeated 64 times Mar 27 00:47:40 
UFR2
> > last message repeated 15 times Mar 27 01:42:41 UFR2 last message
> > repeated 95 times Mar 27 02:15:57 UFR2 last message repeated 90 times
> > Mar 27 02:27:13 UFR2 last message repeated 45 times Mar 27 03:14:08 
UFR2
> > last message repeated 95 times Mar 27 04:26:10 UFR2 last message
> > repeated 2 times Mar 27 06:11:35 UFR2 last message repeated 45 times 
Mar
> > 27 06:20:20 UFR2 last message repeated 15 times Mar 27 06:20:20 UFR2
> > last message repeated 12 times Mar 27 06:27:53 UFR2 kernel: BUG: soft
> > lockup detected on CPU#3!
> > Mar 27 06:27:53 UFR2 kernel:  [] softlockup_tick+0x9e/0xac 
Mar
> > 27 06:27:53 UFR2 kernel:  [] update_process_times+0x3b/0x5e
> > Mar 27 06:27:53 UFR2 kernel:  []
> > smp_apic_timer_interrupt+0x6c/0x7a
> > Mar 27 06:27:53 UFR2 kernel:  []
> > apic_timer_interrupt+0x28/0x30 Mar 27 06:27:53 UFR2 kernel:
> > [] generic_fillattr+0x75/0xa8 Mar 27 06:27:53 UFR2 kernel:
> > [] cifs_getattr+0x1e/0x2b [cifs] Mar 27 06:27:53 UFR2 
kernel:
> > [] cifs_getattr+0x0/0x2b [cifs] Mar 27 06:27:53 UFR2 kernel:
> > [] vfs_getattr+0x21/0x30 Mar 27 06:27:53 UFR2 kernel:
> > [] vfs_fstat+0x22/0x31 Mar 27 06:27:53 UFR2 kernel:
> > [] sys_fstat64+0xf/0x23 Mar 27 06:27:53 UFR2 kernel:
> > [] sys_open+0x1a/0x1c Mar 27 06:27:53 UFR2 kernel:
> > [] sysenter_past_esp+0x5d/0x81 Mar 27 06:27:53 UFR2 kernel:
> > [] xdr_xcode_array2+0x307/0x506 Mar 27 06:27:53 UFR2 kernel:
> 
> You didn't tell us what kernel version you're running.
> 
> Hanging in generic_fillattr: i_size_read() got stuck.  This is because 
CIFS
> doesn't correctly hold i_mutex across i_size_write().
> 
> Steve, where are we up to with the fixes for that?

-
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

2007-03-29 Thread Steven French

This should be fixed in 2.6.21 as of 2/26.  The fix was 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3677db10a635a39f63ea509f8f0056d95589ff90


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

Andrew Morton [EMAIL PROTECTED] wrote on 03/29/2007 03:54:57 AM:

 On Wed, 28 Mar 2007 20:35:55 +0200 Valentin Zaharov 
 [EMAIL PROTECTED] wrote:
 
  Hi,
  
  We have continous problem with server freezes. We are using cifs 
mounts
  on apache powered web servers with content located on Win2k3 server.
  Servers freeze from time to time, producing following error just 
before
  freeze:
  
  Mar 26 21:50:37 UFR2 kernel:  CIFS VFS: cifs_strtoUCS: char2uni 
returned
  -22 Mar 26 21:51:45 UFR2 last message repeated 55 times Mar 26 
21:52:49
  UFR2 last message repeated 30 times Mar 26 21:54:16 UFR2 last message
  repeated 10 times Mar 26 21:56:13 UFR2 last message repeated 20 times
  Mar 26 21:58:34 UFR2 last message repeated 75 times Mar 26 21:59:43 
UFR2
  last message repeated 30 times Mar 26 22:01:02 UFR2 last message
  repeated 30 times Mar 26 22:02:04 UFR2 last message repeated 30 times
  Mar 26 22:03:08 UFR2 last message repeated 50 times Mar 26 22:04:27 
UFR2
  last message repeated 10 times Mar 26 22:05:59 UFR2 last message
  repeated 20 times Mar 26 22:07:10 UFR2 last message repeated 20 times
  Mar 26 22:29:00 UFR2 last message repeated 64 times Mar 27 00:47:40 
UFR2
  last message repeated 15 times Mar 27 01:42:41 UFR2 last message
  repeated 95 times Mar 27 02:15:57 UFR2 last message repeated 90 times
  Mar 27 02:27:13 UFR2 last message repeated 45 times Mar 27 03:14:08 
UFR2
  last message repeated 95 times Mar 27 04:26:10 UFR2 last message
  repeated 2 times Mar 27 06:11:35 UFR2 last message repeated 45 times 
Mar
  27 06:20:20 UFR2 last message repeated 15 times Mar 27 06:20:20 UFR2
  last message repeated 12 times Mar 27 06:27:53 UFR2 kernel: BUG: soft
  lockup detected on CPU#3!
  Mar 27 06:27:53 UFR2 kernel:  [c0134b57] softlockup_tick+0x9e/0xac 
Mar
  27 06:27:53 UFR2 kernel:  [c0121440] update_process_times+0x3b/0x5e
  Mar 27 06:27:53 UFR2 kernel:  [c010d885]
  smp_apic_timer_interrupt+0x6c/0x7a
  Mar 27 06:27:53 UFR2 kernel:  [c01032ec]
  apic_timer_interrupt+0x28/0x30 Mar 27 06:27:53 UFR2 kernel:
  [c0153d75] generic_fillattr+0x75/0xa8 Mar 27 06:27:53 UFR2 kernel:
  [f8e78ed2] cifs_getattr+0x1e/0x2b [cifs] Mar 27 06:27:53 UFR2 
kernel:
  [f8e78eb4] cifs_getattr+0x0/0x2b [cifs] Mar 27 06:27:53 UFR2 kernel:
  [c0153dc9] vfs_getattr+0x21/0x30 Mar 27 06:27:53 UFR2 kernel:
  [c0153e93] vfs_fstat+0x22/0x31 Mar 27 06:27:53 UFR2 kernel:
  [c015443a] sys_fstat64+0xf/0x23 Mar 27 06:27:53 UFR2 kernel:
  [c0150fc5] sys_open+0x1a/0x1c Mar 27 06:27:53 UFR2 kernel:
  [c0102820] sysenter_past_esp+0x5d/0x81 Mar 27 06:27:53 UFR2 kernel:
  [c0310033] xdr_xcode_array2+0x307/0x506 Mar 27 06:27:53 UFR2 kernel:
 
 You didn't tell us what kernel version you're running.
 
 Hanging in generic_fillattr: i_size_read() got stuck.  This is because 
CIFS
 doesn't correctly hold i_mutex across i_size_write().
 
 Steve, where are we up to with the fixes for that?

-
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 2.6.19.2: Freeze with CIFS mount

2007-01-30 Thread Steven French

The cifs entries in the dmesg log do not indicate any errors, much less 
show the cause of this
particular problem.

The repeated entry:
CIFS VFS: Send error in SETFSUnixInfo = -5
is expected on connection to certain older versions of Samba servers (or 
other servers that 
only partially support the current CIFS Unix Extensions).  It is harmless.

It would be useful to know (e.g. if it is possible to trace the network 
traffic on the server side on your NAS box) whether
any network traffic from the client is being sent when (or just before) 
the hang occurs.

It is possible that the restarting of the NAS box allows reconnection of 
the smb/cifs session to proceed
which presumably could be hanging or looping in the network adapter 
driver, the tcp stack or cifs on
the client, but it is hard to tell without more information.   I don't 
know much about either of the
GigE drivers loaded on your system to determine if there is an easy way to 
tell their state.

There are various ways to analyze system hangs including (at least in some 
cases) getting a system dump which
can be used to isolate the failing location - hopefully 



[EMAIL PROTECTED] wrote on 01/30/2007 06:37:48 AM:

> Hello,
> 
> I report a problem that occurs on a Core2 system (x86_64 used) with a 
Linux 
> 2.6.19.2, when i use a NAS : Maxtor Shared Storage II 320Go (Linux 
2.6.12 
> inside).
> 
> In fact, this NAS can be web-configured to sleep after 30 min. Also,i 
mount a 
> partition of this device through this kind of entry inside the fstab :
> 
> 
> //192.168.1.60/Archive   /home/tuxico/NAS/Archive   cifs 
> noauto,users,iocharset=iso8859-1,noperm,nosetuids,noacl,sfu,
> file_mode=0600,dir_mode=0755,uid=tuxico,gid=users,
> credentials=/root/.credentials 
> 0 0
> 
> 
> Under those circumstances, the Core2 system which is connected to it, 
freeze 
> sometimes completely (mouse, keyboard are frozen, no connection possible 
from 
> an external system - sshd not respond).
> 
> This occurs regularly (within 3-4 days) and it seems that the problem 
results 
> from the awakening of the NAS device.
> 
> Indeed I have disable the sleep feature of the device (via its web 
control 
> panel), then i was unable to trigger the problem for at least 7 days of 
> uptime of the Core2 system.
> 
> I join the .config, the result of lspci, and the CIFS logs that have 
been 
> written to /var/log/messages (i don't know if there are relevant or not 
but 
> in the doubt...).
> 
> Thanks in advance for the help.
> 
> Best regards,
> 
>    Eric
> [attachment "lspci" deleted by Steven French/Austin/IBM] [attachment
> "dotconfig" deleted by Steven French/Austin/IBM] [attachment 
> "cifslog" deleted by Steven French/Austin/IBM] 

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

-
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 2.6.19.2: Freeze with CIFS mount

2007-01-30 Thread Steven French

The cifs entries in the dmesg log do not indicate any errors, much less 
show the cause of this
particular problem.

The repeated entry:
CIFS VFS: Send error in SETFSUnixInfo = -5
is expected on connection to certain older versions of Samba servers (or 
other servers that 
only partially support the current CIFS Unix Extensions).  It is harmless.

It would be useful to know (e.g. if it is possible to trace the network 
traffic on the server side on your NAS box) whether
any network traffic from the client is being sent when (or just before) 
the hang occurs.

It is possible that the restarting of the NAS box allows reconnection of 
the smb/cifs session to proceed
which presumably could be hanging or looping in the network adapter 
driver, the tcp stack or cifs on
the client, but it is hard to tell without more information.   I don't 
know much about either of the
GigE drivers loaded on your system to determine if there is an easy way to 
tell their state.

There are various ways to analyze system hangs including (at least in some 
cases) getting a system dump which
can be used to isolate the failing location - hopefully 



[EMAIL PROTECTED] wrote on 01/30/2007 06:37:48 AM:

 Hello,
 
 I report a problem that occurs on a Core2 system (x86_64 used) with a 
Linux 
 2.6.19.2, when i use a NAS : Maxtor Shared Storage II 320Go (Linux 
2.6.12 
 inside).
 
 In fact, this NAS can be web-configured to sleep after 30 min. Also,i 
mount a 
 partition of this device through this kind of entry inside the fstab :
 
 
 //192.168.1.60/Archive   /home/tuxico/NAS/Archive   cifs 
 noauto,users,iocharset=iso8859-1,noperm,nosetuids,noacl,sfu,
 file_mode=0600,dir_mode=0755,uid=tuxico,gid=users,
 credentials=/root/.credentials 
 0 0
 
 
 Under those circumstances, the Core2 system which is connected to it, 
freeze 
 sometimes completely (mouse, keyboard are frozen, no connection possible 
from 
 an external system - sshd not respond).
 
 This occurs regularly (within 3-4 days) and it seems that the problem 
results 
 from the awakening of the NAS device.
 
 Indeed I have disable the sleep feature of the device (via its web 
control 
 panel), then i was unable to trigger the problem for at least 7 days of 
 uptime of the Core2 system.
 
 I join the .config, the result of lspci, and the CIFS logs that have 
been 
 written to /var/log/messages (i don't know if there are relevant or not 
but 
 in the doubt...).
 
 Thanks in advance for the help.
 
 Best regards,
 
Eric
 [attachment lspci deleted by Steven French/Austin/IBM] [attachment
 dotconfig deleted by Steven French/Austin/IBM] [attachment 
 cifslog deleted by Steven French/Austin/IBM] 

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

-
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 2.6.20-rc3] CIFS: Remove 2 unneeded kzalloc casts

2007-01-21 Thread Steven French

thx - I have added these to the cifs git tree.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

"Ahmed S. Darwish" <[EMAIL PROTECTED]> wrote on 01/06/2007 07:17:44 AM:

> Hi, 
> A patch to remove two unnecessary kzalloc casts found
> 
> Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]>
> 
> diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
> index aedf683..90f95ed 100644
> --- a/fs/cifs/misc.c
> +++ b/fs/cifs/misc.c
> @@ -71,9 +71,7 @@ sesInfoAlloc(void)
>  {
> struct cifsSesInfo *ret_buf;
> 
> -   ret_buf =
> -   (struct cifsSesInfo *) kzalloc(sizeof (struct cifsSesInfo),
> -  GFP_KERNEL);
> +   ret_buf = kzalloc(sizeof (struct cifsSesInfo), GFP_KERNEL);
> if (ret_buf) {
>write_lock();
>atomic_inc();
> @@ -109,9 +107,8 @@ struct cifsTconInfo *
>  tconInfoAlloc(void)
>  {
> struct cifsTconInfo *ret_buf;
> -   ret_buf =
> -   (struct cifsTconInfo *) kzalloc(sizeof (struct cifsTconInfo),
> -   GFP_KERNEL);
> +   ret_buf = kzalloc(sizeof (struct cifsTconInfo),
> +   GFP_KERNEL);
> if (ret_buf) {
>write_lock();
>atomic_inc();
> 
> -- 
> Ahmed S. Darwish
> http://darwish-07.blogspot.com

-
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 2.6.20-rc3] CIFS: Remove 2 unneeded kzalloc casts

2007-01-21 Thread Steven French

thx - I have added these to the cifs git tree.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

Ahmed S. Darwish [EMAIL PROTECTED] wrote on 01/06/2007 07:17:44 AM:

 Hi, 
 A patch to remove two unnecessary kzalloc casts found
 
 Signed-off-by: Ahmed Darwish [EMAIL PROTECTED]
 
 diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
 index aedf683..90f95ed 100644
 --- a/fs/cifs/misc.c
 +++ b/fs/cifs/misc.c
 @@ -71,9 +71,7 @@ sesInfoAlloc(void)
  {
 struct cifsSesInfo *ret_buf;
 
 -   ret_buf =
 -   (struct cifsSesInfo *) kzalloc(sizeof (struct cifsSesInfo),
 -  GFP_KERNEL);
 +   ret_buf = kzalloc(sizeof (struct cifsSesInfo), GFP_KERNEL);
 if (ret_buf) {
write_lock(GlobalSMBSeslock);
atomic_inc(sesInfoAllocCount);
 @@ -109,9 +107,8 @@ struct cifsTconInfo *
  tconInfoAlloc(void)
  {
 struct cifsTconInfo *ret_buf;
 -   ret_buf =
 -   (struct cifsTconInfo *) kzalloc(sizeof (struct cifsTconInfo),
 -   GFP_KERNEL);
 +   ret_buf = kzalloc(sizeof (struct cifsTconInfo),
 +   GFP_KERNEL);
 if (ret_buf) {
write_lock(GlobalSMBSeslock);
atomic_inc(tconInfoAllocCount);
 
 -- 
 Ahmed S. Darwish
 http://darwish-07.blogspot.com

-
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: [GIT PULL] fscache rewrite -- please drop for now

Re: MAINTAINERS without commits in the last 3 years

Re: MAINTAINERS without commits in the last 3 years

Re: [PATCH v1] cifs: use server timestamp for ntlmv2 authentication

Re: [PATCH v1] cifs: use server timestamp for ntlmv2 authentication

Re: struct cifs_dfs_referral_inode_operations is unused

Re: struct cifs_dfs_referral_inode_operations is unused

Re: 2.6.22-rc1-mm1 cifs_mount oops

Re: 2.6.22-rc1-mm1 cifs_mount oops

Re: 2.6.22-rc1-mm1 cifs_mount oops

Re: 2.6.22-rc1-mm1 cifs_mount oops

Re: 2.6.22-rc1-mm1 cifs_mount oops

Re: 2.6.22-rc1-mm1 cifs_mount oops

Re: 2.6.22-rc1-mm1 cifs_mount oops

Re: 2.6.22-rc1-mm1 cifs_mount oops

Re: cifs causes BUG: soft lockup detected on CPU

Re: cifs causes BUG: soft lockup detected on CPU

Re: Linux 2.6.19.2: Freeze with CIFS mount

Re: Linux 2.6.19.2: Freeze with CIFS mount

Re: [PATCH 2.6.20-rc3] CIFS: Remove 2 unneeded kzalloc casts

Re: [PATCH 2.6.20-rc3] CIFS: Remove 2 unneeded kzalloc casts

21 matches

Site Navigation

Mail list logo

Footer information