Re: [PATCH] cifs: cifsacl: Use a temporary ops variable to reduce code length

Looks correct. Acked-by: Shirish Pargaonkar <shirishpargaon...@gmail.com> On Sun, May 7, 2017 at 3:31 AM, Joe Perches via samba-technical <samba-techni...@lists.samba.org> wrote: > Create an ops variable to store tcon->ses->server->ops and cache > indirections and red

Re: [PATCH] cifs: cifsacl: Use a temporary ops variable to reduce code length

Looks correct. Acked-by: Shirish Pargaonkar On Sun, May 7, 2017 at 3:31 AM, Joe Perches via samba-technical wrote: > Create an ops variable to store tcon->ses->server->ops and cache > indirections and reduce code size a trivial bit. > > $ size fs/cifs/cifsacl.o* >

Re: [PATCH 2/6] cifs: merge the hash calculation helpers

Looks correct. Tested with -o vers=1.0, -o vers=2.0, and -o vers=2.1. Will test using mount option vers=3.0 as soon as I find a server. Reviewed-by: Shirish Pargaonkar <shirishpargaon...@gmail.com> Tested-by: Shirish Pargaonkar <shirishpargaon...@gmail.com> On Sat, Apr 9, 2016 at

Re: [PATCH 2/6] cifs: merge the hash calculation helpers

Looks correct. Tested with -o vers=1.0, -o vers=2.0, and -o vers=2.1. Will test using mount option vers=3.0 as soon as I find a server. Reviewed-by: Shirish Pargaonkar Tested-by: Shirish Pargaonkar On Sat, Apr 9, 2016 at 3:50 PM, Al Viro wrote: > three practically identical cop

Re: [RFC][PATCHSET] reduce messing with iovecs in cifs

Looking at the series. I briefly looked at 2/6 and looks correct but would add tested-by once I test that patch against a SMB server. On Sat, Apr 9, 2016 at 3:43 PM, Al Viro wrote: > Now that sendmsg/recvmsg do not mangle iovecs and are capable of > handling

Re: [RFC][PATCHSET] reduce messing with iovecs in cifs

Looking at the series. I briefly looked at 2/6 and looks correct but would add tested-by once I test that patch against a SMB server. On Sat, Apr 9, 2016 at 3:43 PM, Al Viro wrote: > Now that sendmsg/recvmsg do not mangle iovecs and are capable of > handling bvec-based ->msg_iter, we can

Re: [PATCH 4/4] [SMB3] Fix coverity warning

Looks correct. Acked-by: Shirish Pargaonkar On Fri, Mar 27, 2015 at 12:28 AM, Steve French wrote: > Coverity reports a warning for referencing the beginning of the > SMB2/SMB3 frame using the ProtocolId field as an array. Although > it works the same either way, this patch sho

Re: [PATCH 3/4] [SMB3] Fix dereference before null check warning

Looks correct. Acked-by: Shirish Pargaonkar On Fri, Mar 27, 2015 at 12:28 AM, Steve French wrote: > null tcon is not likely in these paths in current > code, but obviously it does clarify the code to > check for null (if at all) before derefrencing > rather than after. > > Re

Re: [PATCH 2/4] [CIFS] Don't ignore errors on encrypting password in SMBTcon

Looks correct, although we could just goto a label at the end of this function which does the same. Acked-by: Shirish Pargaonkar On Fri, Mar 27, 2015 at 12:28 AM, Steve French wrote: > Although unlikely to fail (and tree connect does not commonly send > a password since SECMOD

Re: [PATCH 1/4] [SMB3] Fix warning on uninitialized buftype

Looks correct. Acked-by: Shirish Pargaonkar On Fri, Mar 27, 2015 at 12:27 AM, Steve French wrote: > Pointed out by coverity analyzer. resp_buftype is > not initialized in one path which can rarely log > a spurious warning (buf is null so there will > not be a problem with

Re: [PATCH 3/4] [SMB3] Fix dereference before null check warning

Looks correct. Acked-by: Shirish Pargaonkar shirishpargaon...@gmail.com On Fri, Mar 27, 2015 at 12:28 AM, Steve French smfre...@gmail.com wrote: null tcon is not likely in these paths in current code, but obviously it does clarify the code to check for null (if at all) before derefrencing

Re: [PATCH 1/4] [SMB3] Fix warning on uninitialized buftype

Looks correct. Acked-by: Shirish Pargaonkar shirishpargaon...@gmail.com On Fri, Mar 27, 2015 at 12:27 AM, Steve French smfre...@gmail.com wrote: Pointed out by coverity analyzer. resp_buftype is not initialized in one path which can rarely log a spurious warning (buf is null so

Re: [PATCH 2/4] [CIFS] Don't ignore errors on encrypting password in SMBTcon

Looks correct, although we could just goto a label at the end of this function which does the same. Acked-by: Shirish Pargaonkar shirishpargaon...@gmail.com On Fri, Mar 27, 2015 at 12:28 AM, Steve French smfre...@gmail.com wrote: Although unlikely to fail (and tree connect does not commonly

Re: [PATCH 4/4] [SMB3] Fix coverity warning

Looks correct. Acked-by: Shirish Pargaonkar shirishpargaon...@gmail.com On Fri, Mar 27, 2015 at 12:28 AM, Steve French smfre...@gmail.com wrote: Coverity reports a warning for referencing the beginning of the SMB2/SMB3 frame using the ProtocolId field as an array. Although it works the same

Re: [PATCH] Block: fix unbalanced bypass-disable in blk_register_queue

Tested-by: Shirish Pargaonkar On Tue, Sep 9, 2014 at 10:50 AM, Alan Stern wrote: > When a queue is registered, the block layer turns off the bypass > setting (because bypass is enabled when the queue is created). This > doesn't work well for queues that are unregistered and then r

Re: [PATCH] Block: fix unbalanced bypass-disable in blk_register_queue

Tested-by: Shirish Pargaonkar shirishpargaon...@gmail.com On Tue, Sep 9, 2014 at 10:50 AM, Alan Stern st...@rowland.harvard.edu wrote: When a queue is registered, the block layer turns off the bypass setting (because bypass is enabled when the queue is created). This doesn't work well

Re: WARNING in block layer triggered in 3.17-rc3

see this issue/warning in 3.12 also. On Mon, Sep 8, 2014 at 10:51 AM, James Bottomley wrote: > On Mon, 2014-09-08 at 10:51 -0400, Alan Stern wrote: >> On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: >> >> > I think the problem is, when a gendisk is detached, its reque

Re: WARNING in block layer triggered in 3.17-rc3

So should a request queue be in bypass mode when the device is being detached and queue is being unregistereed because requests can get queued up? On Mon, Sep 8, 2014 at 9:51 AM, Alan Stern wrote: > On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: > >> I think the problem is, wh

Re: WARNING in block layer triggered in 3.17-rc3

So should a request queue be in bypass mode when the device is being detached and queue is being unregistereed because requests can get queued up? On Mon, Sep 8, 2014 at 9:51 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: I think the problem

Re: WARNING in block layer triggered in 3.17-rc3

see this issue/warning in 3.12 also. On Mon, Sep 8, 2014 at 10:51 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2014-09-08 at 10:51 -0400, Alan Stern wrote: On Sun, 7 Sep 2014, Shirish Pargaonkar wrote: I think the problem is, when a gendisk is detached, its

Re: WARNING in block layer triggered in 3.17-rc3

I think the problem is, when a gendisk is detached, its request queue is not put in bypass mode cause when it is re-attached, code tries to put it out of bypass mode, hence the warning. So either of these should work, I have not tested it, just coded it up. diff --git a/block/blk-sysfs.c

Re: WARNING in block layer triggered in 3.17-rc3

I think the problem is, when a gendisk is detached, its request queue is not put in bypass mode cause when it is re-attached, code tries to put it out of bypass mode, hence the warning. So either of these should work, I have not tested it, just coded it up. diff --git a/block/blk-sysfs.c

Re: [PATCH] fs: cifs: cifsencrypt.c: Cleaning up missing null-terminate in conjunction with strncpy

ard Strandqvist wrote: >> 2014-08-02 19:33 GMT+02:00 Joe Perches : >> > On Sat, 2014-08-02 at 11:55 -0500, Shirish Pargaonkar wrote: >> >> Acked-by: Shirish Pargaonkar >> > [] >> >> > diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c &

Re: [PATCH] fs: cifs: cifsencrypt.c: Cleaning up missing null-terminate in conjunction with strncpy

Strandqvist wrote: 2014-08-02 19:33 GMT+02:00 Joe Perches j...@perches.com: On Sat, 2014-08-02 at 11:55 -0500, Shirish Pargaonkar wrote: Acked-by: Shirish Pargaonkar spargaon...@suse.com [] diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c [] @@ -307,7 +307,7 @@ int

Re: [PATCH] fs: cifs: cifsencrypt.c: Cleaning up missing null-terminate in conjunction with strncpy

Acked-by: Shirish Pargaonkar On Sat, Jul 26, 2014 at 5:28 PM, Rickard Strandqvist wrote: > If you are going to use memset before strncpy you must copy sizeof -1 > > Signed-off-by: Rickard Strandqvist > --- > fs/cifs/cifsencrypt.c |2 +- > 1 file changed, 1 insert

Re: [PATCH] fs: cifs: cifsencrypt.c: Cleaning up missing null-terminate in conjunction with strncpy

Acked-by: Shirish Pargaonkar spargaon...@suse.com On Sat, Jul 26, 2014 at 5:28 PM, Rickard Strandqvist rickard_strandqv...@spectrumdigital.se wrote: If you are going to use memset before strncpy you must copy sizeof -1 Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se

Re: [PATCH block/for-linus] blkcg: don't call into policy draining if root_blkg is already gone

been > there even before the commit as blk_queue_bypass_start() could race > against queue destruction, win the initial bypass test but perform the > actual draining after blk_cleanup_queue() already destroyed all blkgs. > > Fix it by skippping calling into policy draining if all the blk

Re: [PATCH block/for-linus] blkcg: don't call into policy draining if root_blkg is already gone

destruction, win the initial bypass test but perform the actual draining after blk_cleanup_queue() already destroyed all blkgs. Fix it by skippping calling into policy draining if all the blkgs are already gone. Signed-off-by: Tejun Heo t...@kernel.org Reported-by: Shirish Pargaonkar spargaon

Re: [PATCH] blkio: Release blkg infrastructure only after last policy is deactivated.

/blk_release_queue() i.e. put by blk_cleanup_queue() should always be the last put. Regards, Shirish On Fri, Jul 4, 2014 at 12:18 PM, Tejun Heo wrote: > On Tue, Jun 24, 2014 at 05:43:40PM -0400, Tejun Heo wrote: >> Hello, >> >> On Tue, Jun 24, 2014 at 04:37:58PM -0500, Shi

Re: [PATCH] blkio: Release blkg infrastructure only after last policy is deactivated.

/blk_release_queue() i.e. put by blk_cleanup_queue() should always be the last put. Regards, Shirish On Fri, Jul 4, 2014 at 12:18 PM, Tejun Heo t...@kernel.org wrote: On Tue, Jun 24, 2014 at 05:43:40PM -0400, Tejun Heo wrote: Hello, On Tue, Jun 24, 2014 at 04:37:58PM -0500, Shirish Pargaonkar

Re: [PATCH] blkio: Release blkg infrastructure only after last policy is deactivated.

5PM -0500, shirishpargaon...@gmail.com wrote: >> From: Shirish Pargaonkar >> >> Release blkg infrastructure only after last policy is deactivated >> (i.e. let blkg_destroy_all() be called only from blkcg_deactivate_policy()) >> >> Otherwise, module can oops because r

Re: [PATCH] blkio: Release blkg infrastructure only after last policy is deactivated.

:25PM -0500, shirishpargaon...@gmail.com wrote: From: Shirish Pargaonkar spargaon...@suse.com Release blkg infrastructure only after last policy is deactivated (i.e. let blkg_destroy_all() be called only from blkcg_deactivate_policy()) Otherwise, module can oops because root_blkg gets assigned

Re: [PATCH] blkio: Release blkg infrastructure only after last policy is deactivated.

] c013b520 SyS_delete_module+0x200/0x350 [c002db203e30] c0009dfc syscall_exit+0x0/0x7c --- Exception: c01 (System Call) at 3fff92974040 SP (3fffd65d4cc0) is in userspace On Mon, Jun 23, 2014 at 1:52 PM, wrote: > From: Shirish Pargaonkar > > Release blkg infrastructure only a

Re: [PATCH] blkio: Release blkg infrastructure only after last policy is deactivated.

] [c002db203d40] c013b520 SyS_delete_module+0x200/0x350 [c002db203e30] c0009dfc syscall_exit+0x0/0x7c --- Exception: c01 (System Call) at 3fff92974040 SP (3fffd65d4cc0) is in userspace On Mon, Jun 23, 2014 at 1:52 PM, shirishpargaon...@gmail.com wrote: From: Shirish Pargaonkar

Re: [PATCH v2] cifs: Fix possible deadlock with cifs and work queues

Just a thought, although leasing code does not cause such deadlocks with rwsems, perhaps leasing and oplock code can reside on one workqueue! On Fri, Mar 21, 2014 at 10:07 AM, Steven Rostedt wrote: > > We just had a customer report a deadlock in their 3.8-rt kernel. > Looking into this, it is

Re: [PATCH v2] cifs: Fix possible deadlock with cifs and work queues

Just a thought, although leasing code does not cause such deadlocks with rwsems, perhaps leasing and oplock code can reside on one workqueue! On Fri, Mar 21, 2014 at 10:07 AM, Steven Rostedt rost...@goodmis.org wrote: We just had a customer report a deadlock in their 3.8-rt kernel. Looking

Re: [PATCH linux-next] cifs: Use data structures to compute NTLMv2 response offsets

Looks correct. You may want to verify that the code works fine for both sec=ntlmssp/ntlmsspi and sec=ntlmv2/ntlmv2i mount options. Reviewed-by: Shirish Pargaonkar On Thu, Nov 7, 2013 at 5:40 PM, Tim Gardner wrote: > A bit of cleanup plus some gratuitous variable renaming. I think us

Re: [PATCH linux-next] cifs: Use data structures to compute NTLMv2 response offsets

Looks correct. You may want to verify that the code works fine for both sec=ntlmssp/ntlmsspi and sec=ntlmv2/ntlmv2i mount options. Reviewed-by: Shirish Pargaonkar spargaon...@suse.com On Thu, Nov 7, 2013 at 5:40 PM, Tim Gardner tim.gard...@canonical.com wrote: A bit of cleanup plus some

Re: [PATCH] [RFC] vfs: don't revalidate dentries that serve as mountpoints

For a similar issue in cifs vfs (samba bugzilla 8950), I was going to try unset the bit DCACHE_OP_REVALIDATE of d_flags of the dentry. Would something like work for the mountpoint dentry? On Mon, Nov 4, 2013 at 7:16 PM, Jeff Layton wrote: > We had a couple of reports of people that are

Re: [PATCH] [RFC] vfs: don't revalidate dentries that serve as mountpoints

For a similar issue in cifs vfs (samba bugzilla 8950), I was going to try unset the bit DCACHE_OP_REVALIDATE of d_flags of the dentry. Would something like work for the mountpoint dentry? On Mon, Nov 4, 2013 at 7:16 PM, Jeff Layton jlay...@redhat.com wrote: We had a couple of reports of

Re: [PATCH linux-next] cifs: Cleanup and clarify CalcNTLMv2_response()

Tim, Since when a NTLMv2 response is sent, contains a session key, hmac-md5 digest, and the blob, the offset has + 8 to include 16 bytes of hmac-md5 digest. hmac-md5 digest is based on 8 bytes of server challenge and the blob. So hmac-md5 digest (output) overwrites total 16 bytes in overall

Re: [PATCH linux-next] cifs: Cleanup and clarify CalcNTLMv2_response()

Tim, Since when a NTLMv2 response is sent, contains a session key, hmac-md5 digest, and the blob, the offset has + 8 to include 16 bytes of hmac-md5 digest. hmac-md5 digest is based on 8 bytes of server challenge and the blob. So hmac-md5 digest (output) overwrites total 16 bytes in overall

Re: cp --reflink and target file open flags

I think it would not matter which ioctl is used if the target file is not opened with flag O_RDWR. Perhaps cifs.ko can make the decision to change O_WRONLY to O_RDWR based on the flag and location of the source and destination files. On Thu, Oct 17, 2013 at 5:45 AM, David Disseldorp wrote: >

Re: cp --reflink and target file open flags

I think it would not matter which ioctl is used if the target file is not opened with flag O_RDWR. Perhaps cifs.ko can make the decision to change O_WRONLY to O_RDWR based on the flag and location of the source and destination files. On Thu, Oct 17, 2013 at 5:45 AM, David Disseldorp

Re: [PATCH 2/2 linux-next] cifs: Make big endian multiplex ID sequences monotonic on the wire

On Wed, Oct 16, 2013 at 10:09 AM, Tim Gardner wrote: > The multiplex identifier (MID) in the SMB header is only > ever used by the client, in conjunction with PID, to match responses > from the server. As such, the endianess of the MID is not important. > However, When tracing packet sequences on

Re: [PATCH 2/2 linux-next] cifs: Make big endian multiplex ID sequences monotonic on the wire

On Wed, Oct 16, 2013 at 10:09 AM, Tim Gardner t...@tpi.com wrote: The multiplex identifier (MID) in the SMB header is only ever used by the client, in conjunction with PID, to match responses from the server. As such, the endianess of the MID is not important. However, When tracing packet

Re: Mount failure due to restricted access to a point along the mount path

So instead of breaking superblock sharing and fscache functionality with 2), it may be better off to explore 1). Will spend some time doing so. Regards, Shirish On Fri, May 10, 2013 at 9:27 AM, Jeff Layton wrote: > On Fri, 10 May 2013 16:13:30 +0200 > Miklos Szeredi wrote: > >> Hi, >> >> A

Re: Mount failure due to restricted access to a point along the mount path

So instead of breaking superblock sharing and fscache functionality with 2), it may be better off to explore 1). Will spend some time doing so. Regards, Shirish On Fri, May 10, 2013 at 9:27 AM, Jeff Layton jlay...@redhat.com wrote: On Fri, 10 May 2013 16:13:30 +0200 Miklos Szeredi

NIST SP800-138 availibility using kernel crypto APIs for SMB3.0 MAC generation

With the recent patches added to kernel crypto for improving AES support, adding aesni etc, it seems like it is time to add AES CMAC to the cifs kernel module (for the popular SMB3 signing and per-share encryption) but needed for an implementation for SP800-138 in kernel crypto codebase. Was

NIST SP800-138 availibility using kernel crypto APIs for SMB3.0 MAC generation

With the recent patches added to kernel crypto for improving AES support, adding aesni etc, it seems like it is time to add AES CMAC to the cifs kernel module (for the popular SMB3 signing and per-share encryption) but needed for an implementation for SP800-138 in kernel crypto codebase. Was