<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/cifs/misc.c, branch linux-3.3.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.3.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.3.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2011-10-13T04:42:17Z</updated>
<entry>
<title>cifs: Add mount options for backup intent (try #6)</title>
<updated>2011-10-13T04:42:17Z</updated>
<author>
<name>Shirish Pargaonkar</name>
</author>
<published>2011-09-26T14:56:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3d3ea8e64efbeb3e4289675dbbfab82333395642'/>
<id>urn:sha1:3d3ea8e64efbeb3e4289675dbbfab82333395642</id>
<content type='text'>
Add mount options backupuid and backugid.

It allows an authenticated user to access files with the intent to back them
up including their ACLs, who may not have access permission but has
"Backup files and directories user right" on them (by virtue of being part
of the built-in group Backup Operators.

When mount options backupuid is specified, cifs client restricts the
use of backup intents to the user whose effective user id is specified
along with the mount option.

When mount options backupgid is specified, cifs client restricts the
use of backup intents to the users whose effective user id belongs to the
group id specified along with the mount option.

If an authenticated user is not part of the built-in group Backup Operators
at the server, access to such files is denied, even if allowed by the client.

Signed-off-by: Shirish Pargaonkar &lt;shirishpargaonkar@gmail.com&gt;
Reviewed-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Steve French &lt;smfrench@gmail.com&gt;
</content>
</entry>
<entry>
<title>cifs: clean up checkSMB</title>
<updated>2011-10-13T04:41:36Z</updated>
<author>
<name>Jeff Layton</name>
</author>
<published>2011-10-11T10:41:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=376b43f41c8b9315f7efdf085d214b6024337381'/>
<id>urn:sha1:376b43f41c8b9315f7efdf085d214b6024337381</id>
<content type='text'>
The variable names in this function are so ambiguous that it's very
difficult to know what it's doing. Rename them to make it a bit more
clear.

Also, remove a redundant length check. cifsd checks to make sure that
the rfclen isn't larger than the maximum frame size when it does the
receive.

Finally, change checkSMB to return a real error code (-EIO) when
it finds an error. That will help simplify some coming changes in the
callers.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Steve French &lt;smfrench@gmail.com&gt;
</content>
</entry>
<entry>
<title>cifs: simplify refcounting for oplock breaks</title>
<updated>2011-07-31T21:21:20Z</updated>
<author>
<name>Jeff Layton</name>
</author>
<published>2011-07-26T16:20:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ad635942c869ad8fc9af270d4998c42b4e978b32'/>
<id>urn:sha1:ad635942c869ad8fc9af270d4998c42b4e978b32</id>
<content type='text'>
Currently, we take a sb-&gt;s_active reference and a cifsFileInfo reference
when an oplock break workqueue job is queued. This is unnecessary and
more complicated than it needs to be. Also as Al points out,
deactivate_super has non-trivial locking implications so it's best to
avoid that if we can.

Instead, just cancel any pending oplock breaks for this filehandle
synchronously in cifsFileInfo_put after taking it off the lists.
That should ensure that this job doesn't outlive the structures it
depends on.

Reported-by: Al Viro &lt;viro@ZenIV.linux.org.uk&gt;
Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Steve French &lt;sfrench@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>[CIFS] Rename three structures to avoid camel case</title>
<updated>2011-05-27T04:34:02Z</updated>
<author>
<name>Steve French</name>
</author>
<published>2011-05-27T04:34:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=96daf2b09178d8ebde2b0d56b027de917c17dfdf'/>
<id>urn:sha1:96daf2b09178d8ebde2b0d56b027de917c17dfdf</id>
<content type='text'>
secMode to sec_mode
and
cifsTconInfo to cifs_tcon
and
cifsSesInfo to cifs_ses

Signed-off-by: Steve French &lt;sfrench@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>cifs: keep BCC in little-endian format</title>
<updated>2011-05-19T14:10:53Z</updated>
<author>
<name>Jeff Layton</name>
</author>
<published>2011-05-04T12:05:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=820a803ffac3ef591e597bc107f8e289a823a29c'/>
<id>urn:sha1:820a803ffac3ef591e597bc107f8e289a823a29c</id>
<content type='text'>
This is the same patch as originally posted, just with some merge
conflicts fixed up...

Currently, the ByteCount is usually converted to host-endian on receive.
This is confusing however, as we need to keep two sets of routines for
accessing it, and keep track of when to use each routine. Munging
received packets like this also limits when the signature can be
calulated.

Simplify the code by keeping the received ByteCount in little-endian
format. This allows us to eliminate a set of routines for accessing it
and we can now drop the *_le suffixes from the accessor functions since
that's now implied.

While we're at it, switch all of the places that read the ByteCount
directly to use the get_bcc inline which should also clean up some
unaligned accesses.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Steve French &lt;sfrench@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>consistently use smb_buf_length as be32 for cifs (try 3)</title>
<updated>2011-05-19T14:10:51Z</updated>
<author>
<name>Steve French</name>
</author>
<published>2011-04-29T05:40:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=be8e3b0044a68e1f1002c432f6b40d290cf0701d'/>
<id>urn:sha1:be8e3b0044a68e1f1002c432f6b40d290cf0701d</id>
<content type='text'>
       There is one big endian field in the cifs protocol, the RFC1001
       length, which cifs code (unlike in the smb2 code) had been handling as
       u32 until the last possible moment, when it was converted to be32 (its
       native form) before sending on the wire.   To remove the last sparse
       endian warning, and to make this consistent with the smb2
       implementation  (which always treats the fields in their
       native size and endianness), convert all uses of smb_buf_length to
       be32.

       This version incorporates Christoph's comment about
       using be32_add_cpu, and fixes a typo in the second
       version of the patch.

Signed-off-by: Steve French &lt;sfrench@us.ibm.com&gt;
Signed-off-by: Pavel Shilovsky &lt;piastry@etersoft.ru&gt;
Signed-off-by: Steve French &lt;sfrench@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>cifs: fix broken BCC check in is_valid_oplock_break</title>
<updated>2011-04-12T00:54:30Z</updated>
<author>
<name>Jeff Layton</name>
</author>
<published>2011-03-16T19:15:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8679b0dba7cb98842cbe37f61ef05ef64106334c'/>
<id>urn:sha1:8679b0dba7cb98842cbe37f61ef05ef64106334c</id>
<content type='text'>
The BCC is still __le16 at this point, and in any case we need to
use the get_bcc_le macro to make sure we don't hit alignment
problems.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Steve French &lt;sfrench@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>Allow user names longer than 32 bytes</title>
<updated>2011-04-12T00:42:06Z</updated>
<author>
<name>Steve French</name>
</author>
<published>2011-02-25T07:11:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8727c8a85f3951ef0eef36a665f5dceebb4c495d'/>
<id>urn:sha1:8727c8a85f3951ef0eef36a665f5dceebb4c495d</id>
<content type='text'>
We artificially limited the user name to 32 bytes, but modern servers handle
larger.  Set the maximum length to a reasonable 256, and make the user name
string dynamically allocated rather than a fixed size in session structure.
Also clean up old checkpatch warning.

Signed-off-by: Steve French &lt;sfrench@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>cifs: fix length checks in checkSMB</title>
<updated>2011-01-31T22:35:37Z</updated>
<author>
<name>Jeff Layton</name>
</author>
<published>2011-01-31T14:14:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6284644e8de1f4005166c918c3d2aa4c510ab9f6'/>
<id>urn:sha1:6284644e8de1f4005166c918c3d2aa4c510ab9f6</id>
<content type='text'>
The cERROR message in checkSMB when the calculated length doesn't match
the RFC1001 length is incorrect in many cases. It always says that the
RFC1001 length is bigger than the SMB, even when it's actually the
reverse.

Fix the error message to say the reverse of what it does now when the
SMB length goes beyond the end of the received data. Also, clarify the
error message when the RFC length is too big. Finally, clarify the
comments to show that the 512 byte limit on extra data at the end of
the packet is arbitrary.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Steve French &lt;sfrench@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>cifs: force a reconnect if there are too many MIDs in flight</title>
<updated>2011-01-31T04:38:15Z</updated>
<author>
<name>Jeff Layton</name>
</author>
<published>2011-01-29T12:02:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=92a4e0f0169498867ecb19c2244510dd4beba149'/>
<id>urn:sha1:92a4e0f0169498867ecb19c2244510dd4beba149</id>
<content type='text'>
Currently, we allow the pending_mid_q to grow without bound with
SIGKILL'ed processes. This could eventually be a DoS'able problem. An
unprivileged user could a process that does a long-running call and then
SIGKILL it.

If he can also intercept the NT_CANCEL calls or the replies from the
server, then the pending_mid_q could grow very large, possibly even to
2^16 entries which might leave GetNextMid in an infinite loop. Fix this
by imposing a hard limit of 32k calls per server. If we cross that
limit, set the tcpStatus to CifsNeedReconnect to force cifsd to
eventually reconnect the socket and clean out the pending_mid_q.

While we're at it, clean up the function a bit and eliminate an
unnecessary NULL pointer check.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Reviewed-by: Shirish Pargaonkar &lt;shirishpargaonkar@gmail.com&gt;
Signed-off-by: Steve French &lt;sfrench@us.ibm.com&gt;
</content>
</entry>
</feed>
