Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

9735 Need to provide SMB 2.1 Client (and prerequisites) #37

Closed
wants to merge 4 commits into from

Conversation

gwr
Copy link
Member

@gwr gwr commented Oct 6, 2018

Getting this ready to integrate after several cherry-pick and squash reorganizations from
https://github.com/Nexenta/illumos-nexenta/commits/release-4.0.5-FP

Yes, all of this is running in production.

BTW, I know illumos does not use pull requests, and this is not a request to "merge".
This is just an easy way to get a relatively large stack of changes up for review.

Update: I've learned that reorganizing and rebase folowed by "push -f" to the branch used by a PR like this works OK, so I've been doing that as each chunk of this work lands upstream.
Resolved comments typically show up with an "outdated" diff.
Good to know github PRs work ok with the branch changing that way.

/* Handle user@domain format. */
if (tmp_user.lg_domain[0] == '\0' &&
(p = strchr(tmp_user.lg_e_username, '@')) != NULL) {
buf = strdup(tmp_user.lg_e_username);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe if (buf == NULL) goto errout; ??

Copy link
Member Author

@gwr gwr Oct 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, checking for strdup failure would be nice. (fixed in the recent push -f)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

@gwr gwr self-assigned this Oct 7, 2018
@gwr gwr force-pushed the smb2clnt1f branch 4 times, most recently from 4fa7705 to 848c425 Compare October 8, 2018 04:48
#else /* _KERNEL */

#include <stdio.h>
#include <stdlib.h>
#include <strings.h>

#include <idmap.h>
#endif /* _KERNEL */
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, probably should update to match the ifdef, here and below.
(Thanks @sjorge)

@gwr gwr force-pushed the smb2clnt1f branch 2 times, most recently from c17a751 to 59626d9 Compare October 8, 2018 17:33
# Copyright 2017 Nexenta Systems, Inc. All rights reserved.
#

set -o emacs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this probably shouldn't be here. It may override personal preferences of other dbx users...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Even though it is my preference)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed. just forgot it was there when I committed this.

# Do this both ways, for now...
CSTD= $(CSTD_GNU99)
C99MODE= -xc99=%all
C99LMODE= -Xc99=%all
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels wrong somehow. Is this to workaround confusion in upper Makefiles?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was just because I was building this code on a couple different maintenance branches both before and after this sweeping "Hey, let's go rename a bunch of variables!" change.
We can get rid of the "old way" part for this integration.

int
smb_iod_start(smb_ctx_t *ctx)
{

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra newline.

case AF_NETBIOS:
err = fknewvc(ctx, ai);
if (err == 0)
goto OK;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only non-errorneous return condition here. Maybe just return (0) right from this code and skip the OK: branch altogether?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There used to be some other stuff here so the goto made more sense.
As it is now, yeah, just a break here would be fine.

}

/*
* Resolve the server address,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like your comment formatter could reflow these into 80 columns instead of 40ish?

@@ -61,21 +64,18 @@
#define NT_SD_REVISION 1
#define NT_ACL_REVISION 2

#ifdef _KERNEL
#ifdef __lint
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the purpose of this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see. Don't we have __unused now? seems like ti would be cleaner than this, which is a really ugly hack.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was getting compiler errors with __unused.
I see now that was probably due to the CSTD Makefile change.
I'll try fixing that and then this can probably go back to using
the inline with an __unused arg.

hexdump(recvbuf, rlen);
/*
* Just dump strings found in the response data.
* Skip the irst 0x90 (RPC wrappers).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: 'first' ?

void
discon_usage(void)
{
printf(gettext("usage: smbutil discon [connection options] "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't ignoring the return value where make lint complain?

CPPFLAGS.first += -I../common
CPPFLAGS= $(CPPFLAGS.first)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like you're not even using any prior value of CPPFLAGS though. This seems strangely constructed.

Why not just CPPFLAGS = -I ../common $(CPPFLAGS) -- assuming you want to prepend and not just eliminate other CPPFLAGS values?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must have been running into some problem I've since forgotten about.
I'll have to look into that.

CPPFLAGS += -I$(SRC)/uts/common
CPPFLAGS += -D_FAKE_KERNEL

C99MODE= -xc99=%all
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the newer CSTD=... macro be defined here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. This may be why I was getting compiler errors with __unused above.

CPPFLAGS += -I$(SRC)/uts/common
CPPFLAGS += -D_FAKE_KERNEL

C99MODE= -xc99=%all
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same CSTD comment here.

int offset;

mblk_cache = kmem_cache_create("streams_mblk", sizeof (mblk_t), 32,
NULL, NULL, NULL, NULL, NULL, mblk_kmem_flags);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The more I think about this, the more I wonder why we need to bother with the whole separate caches for kernel space mblks. Is there value in keeping this complexity for your emulation layer?

Copy link
Member Author

@gwr gwr Oct 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was just doing what got me there in the shortest amount of time. :)
Is there anything else here you think I should chop out?
I got rid of everything that was easy to take out.


/*ARGSUSED*/
mblk_t *
esballoca(unsigned char *base, size_t size, uint_t pri, frtn_t *frp)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be fairly stunned if any of your user space code or even your in-kernel code ever neeed desballoc or esballoca. These are for device drivers that want to loan up premapped buffers, and should not be called by anything that isn't a hardware driver I believe.

}

#ifdef _KERNEL

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another chunk of code we don't need.

* removed once a copy-callback routine is made available.
*/
if (dp->db_type == M_MULTIDATA) {
#ifdef _KERNEL
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kill it with fire. In fact I'd just nuke this whole block... M_MULTIDATA will never ever be seen in your user space code. It only happens for certain legacy SPARC drivers. (Cassini.)

# Use is subject to license terms.
#
# Copyright 2017 Nexenta Systems, Inc. All rights reserved.
#
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you linting this stuff?!?!?! For the love of God, why???? I mean, lint the kernel bits sure. But this is not deployed to prod, and modern GCC gives pretty decent warnings. I'd just skip lint on the user framework altogether rather than run it and suppress all these warnings...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, could do.

kidmap_get_destroy(idmap_get_handle_t *get_handle);

#ifdef _KERNEL
/*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kill it please

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same case as other copied code -- was just trying to keep these like the originals.
(for now, anyway)

* fid_pad will force the alignment.
*/
#define MAXFIDSZ 64
#define OLD_MAXFIDSZ 16
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this symbol relevant here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto above

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find that with headers, it's a bit more time consuming to figure out what can be removed.
You OK with leaving these (mostly) the same as the originals?

extern avl_tree_t vskstat_tree;
extern kmutex_t vskstat_tree_lock;

#if defined(_KERNEL) || defined(_FAKE_KERNEL)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't we always _FAKE_KERNEL? Or am I missing something?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In these too, I found it useful to keep all these headers as close as possible to the originals.

# Common Development and Distribution License (the "License").
# You may not use this file except in compliance with the License.
#
# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm somewhat stunned you bothered to put in Makefiles for SPARC ... has anyone actually tried building this on SPARC?

SMB client but is very useful for some kinds of development work.

The architecture of this roughly parallels the in-kernel version,
where the kernel modules are build as libraries including:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/build/built

@gwr gwr force-pushed the smb2clnt1f branch 3 times, most recently from 134157b to bdac70a Compare October 16, 2018 18:43
NEX-16818 Add fksmbcl development tool
Reviewed by: Evan Layton <evan.layton@nexenta.com>
Reviewed by: Matt Barden <matt.barden@nexenta.com>

and: (fix ref leaks, lint)
Fix libsmbfs build smbfs_ntacl.c error at __unused
Catch up with later libfakekernel stuff
smbfs_ntacl.c review by @sjorge
Chop out some stuff in fake_stream.c
Don't bother to lint under $SRC/lib/smbclnt
Consider small-content Makefiles as new files
fix .dbxrc, nits, add to README
Catch up with C99MODE/CSTD
Go back to inline in smbfs_ntacl.c now CSTD is fixed.
Kill lgrep in libsmbfs
Fix fksmbcl_main.c lint nit
NEX-16824 SMB client connection setup rework
NEX-15557 SMB client tries to connect twice
Reviewed by: Evan Layton <evan.layton@nexenta.com>
Reviewed by: Matt Barden <matt.barden@nexenta.com>

and session key changes
NEX-14666 Need to provide SMB 2.1 Client
NEX-17187 panic in smbfs_acl_store
NEX-17231 smbfs create xattr files finds wrong file
NEX-17232 SMB client reconnect failures
NEX-17224 smbfs lookup EINVAL should be ENOENT
NEX-17260 SMB1 client fails to list directory after NEX-14666
NEX-17264 SMB client test tp_smbutil_013 fails after NEX-14666

Reviewed by: Evan Layton <evan.layton@nexenta.com>
Reviewed by: Matt Barden <matt.barden@nexenta.com>
Reviewed by: Rick McNeal <rick.mcneal@nexenta.com>
Reviewed by: Saso Kiselkov <saso.kiselkov@nexenta.com>
Reviewed by: Joyce McIntosh <joyce.mcintosh@nexenta.com>

and: (cleanup, fix missing include, improve debug)
@gwr
Copy link
Member Author

gwr commented Oct 20, 2018

Updated now that 9873 has landed. We're down to 3 commits (Yea!:)

Reviewed by: Gordon Ross <gordon.ross@nexenta.com>
Reviewed by: Joyce McIntosh <joyce.mcintosh@nexenta.com>
@gwr
Copy link
Member Author

gwr commented Feb 26, 2019

Still waiting for reviewers...

@jclulow
Copy link
Member

jclulow commented Feb 26, 2019

You may need to prod folks on IRC and/or the mailing list. I'm not sure how many people actually get the GitHub notifications for things they're not already participating in!

@gdamore
Copy link
Member

gdamore commented Feb 26, 2019

FYI, we have merged this code (there may have been mods, I will follow up) into our code base, and are using it in our shipping product at this point.

@jclulow
Copy link
Member

jclulow commented Feb 26, 2019

It seems that the three remaining commits have had some amount of qualified internal review at Nexenta, and as Garrett mentions the changes are also used and shipped in at least one other distribution. I think it would be fine to signal to the developer list that you're intending to integrate, then let a couple of days go past (presumably without comment) and then just proceed to RTI with notes about the testing/shipping.

@citrus-it
Copy link
Member

It seems that the three remaining commits have had some amount of qualified internal review at Nexenta, and as Garrett mentions the changes are also used and shipped in at least one other distribution. I think it would be fine to signal to the developer list that you're intending to integrate, then let a couple of days go past (presumably without comment) and then just proceed to RTI with notes about the testing/shipping.

Hear hear. I've had this in an OmniOS branch for a while too but do not have an AD environment for testing the integration there. I've read over the code and didn't spot anything but unfortunately don't know this area (or the protocol) well enough to be able to review properly.

@gwr
Copy link
Member Author

gwr commented Mar 14, 2019

Pushed to illumos/master adee678

@gwr gwr closed this Mar 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
7 participants