02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
15 May, 2017
4 commits
-
struct rpc_procinfo contains function pointers, and marking it as
constant avoids it being able to be used as an attach vector for
code injections.Signed-off-by: Christoph Hellwig
Acked-by: Trond Myklebust -
p_count is the only writeable memeber of struct rpc_procinfo, which is
a good candidate to be const-ified as it contains function pointers.This patch moves it into out out struct rpc_procinfo, and into a
separate writable array that is pointed to by struct rpc_version and
indexed by p_statidx.Signed-off-by: Christoph Hellwig
-
Declare the p_decode callbacks with the proper prototype instead of
casting to kxdrdproc_t and losing all type safety.Signed-off-by: Christoph Hellwig
Reviewed-by: Jeff Layton
Acked-by: Trond Myklebust -
Declare the p_encode callbacks with the proper prototype instead of
casting to kxdreproc_t and losing all type safety.Signed-off-by: Christoph Hellwig
Reviewed-by: Jeff Layton
Acked-by: Trond Myklebust
07 May, 2014
1 commit
-
The only real user of this header is fs/nfsd/nfsfh.h, so merge the
two. Various lockѕ source files used it to indirectly get other
sunrpc or nfs headers, so fix those up.Signed-off-by: Christoph Hellwig
Signed-off-by: J. Bruce Fields
05 Nov, 2012
1 commit
-
- Offset bound checks are done in the NFS client code.
- So are filehandle size checks
- The cookie length is a constant
- The utsname()->nodename is already boundedSigned-off-by: Trond Myklebust
14 Apr, 2012
1 commit
-
comparing be32 values for < is not doing the right thing...
Signed-off-by: Al Viro
01 Feb, 2012
1 commit
-
Signed-off-by: Trond Myklebust
17 Dec, 2010
3 commits
-
Now that all client-side XDR decoder routines use xdr_streams, there
should be no need to support the legacy calling sequence [rpc_rqst *,
__be32 *, RPC res *] anywhere. We can construct an xdr_stream in the
generic RPC code, instead of in each decoder function.This is a refactoring change. It should not cause different behavior.
Signed-off-by: Chuck Lever
Tested-by: J. Bruce Fields
Signed-off-by: Trond Myklebust -
Now that all client-side XDR encoder routines use xdr_streams, there
should be no need to support the legacy calling sequence [rpc_rqst *,
__be32 *, RPC arg *] anywhere. We can construct an xdr_stream in the
generic RPC code, instead of in each encoder function.Also, all the client-side encoder functions return 0 now, making a
return value superfluous. Take this opportunity to convert them to
return void instead.This is a refactoring change. It should not cause different behavior.
Signed-off-by: Chuck Lever
Tested-by: J. Bruce Fields
Signed-off-by: Trond Myklebust -
We'd like to prevent local buffer overflows caused by malicious or
broken servers. New xdr_stream style decoders can do that.For efficiency, we also want to be able to pass xdr_streams from
call_encode() to all XDR encoding functions, rather than building
an xdr_stream in every XDR encoding function in the kernel.Same idea as the NLM v3 XDR overhaul.
Signed-off-by: Chuck Lever
Tested-by: J. Bruce Fields
Signed-off-by: Trond Myklebust
