Commit Graph

31 Commits

Author SHA1 Message Date
Enji Cooper
33193da27e Fix up r316081 by using nitems(cam_errbuf) instead of sizeof(cam_errbuf)
Part of my original reasoning as far as converting the snprintf
calls was to permit switching over from char[] to wchar_t[] in the
future, as well as futureproof in case cam_errbuf's size was ever
changed.

Unfortunately, my approach was bugged because it conflated the
number of items with the size of the buffer, instead of the number of
elements being a fixed size != 1 byte.

Use nitems(..) instead which counts the quantity of items of a specific
type, as opposed to an unqualified sizeof(..) (which assumes that the
number of characters is equal to the buffer size).

MFC after:	2 months
Noted by:	cem
Sponsored by:	Dell EMC Isilon
2017-03-29 08:38:31 +00:00
Enji Cooper
c9bac21cc9 libcam: use __func__ instead of hardcoding the function name as func_name
MFC after:	3 days
Tested with:	`cam_device_copy(NULL, NULL)` // ;)..
Sponsored by:	Dell EMC Isilon
2017-03-28 22:32:11 +00:00
Enji Cooper
7b7820a8e4 Use sizeof(cam_errbuf) instead of CAM_ERRBUF_SIZE in snprintf calls
Reindent snprintf calls' arguments to match style(9) guidelines with
respect to indentation.

MFC after:	3 days
Sponsored by:	Dell EMC Isilon
2017-03-28 08:24:16 +00:00
Enji Cooper
4056f95699 libcam: NULL out freed ccb.cdm.matches and ccb.cdm.patterns pointers
This is being done to avoid potential double frees with the values.

Differential Revision:	D9970
MFC after:	1 week
Reviewed by:	imp
Sponsored by:	Dell EMC Isilon
2017-03-20 16:30:02 +00:00
Don Lewis
95320acebc Fix multiple Coverity Out-of-bounds access false postive issues in CAM
The currently used idiom for clearing the part of a ccb after its
header generates one or two Coverity errors for each time it is
used.  All instances generate an Out-of-bounds access (ARRAY_VS_SINGLETON)
error because of the treatment of the header as a two element array,
with a pointer to the non-existent second element being passed as
the starting address to bzero().  Some instances also alsp generate
Out-of-bounds access (OVERRUN) errors, probably because the space
being cleared is larger than the sizeofstruct ccb_hdr).

In addition, this idiom is difficult for humans to understand and
it is error prone.  The user has to chose the proper struct ccb_*
type (which does not appear in the surrounding code) for the sizeof()
in the length calculation.  I found several instances where the
length was incorrect, which could cause either an actual out of
bounds write, or incompletely clear the ccb.

A better way is to write the code to clear the ccb itself starting
at sizeof(ccb_hdr) bytes from the start of the ccb, and calculate
the length based on the specific type of struct ccb_* being cleared
as specified by the union ccb member being used.  The latter can
normally be seen in the nearby code.  This is friendlier for Coverity
and other static analysis tools because they will see that the
intent is to clear the trailing part of the ccb.

Wrap all of the boilerplate code in a convenient macro that only
requires a pointer to the desired union ccb member (or a pointer
to the union ccb itself) as an argument.

Reported by:	Coverity
CID:		1007578, 1008684, 1009724, 1009773, 1011304, 1011306
CID:		1011307, 1011308, 1011309, 1011310, 1011311, 1011312
CID:		1011313, 1011314, 1011315, 1011316, 1011317, 1011318
CID:		1011319, 1011320, 1011321, 1011322, 1011324, 1011325
CID:		1011326, 1011327, 1011328, 1011329, 1011330, 1011374
CID:		1011390, 1011391, 1011392, 1011393, 1011394, 1011395
CID:		1011396, 1011397, 1011398, 1011399, 1011400, 1011401
CID:		1011402, 1011403, 1011404, 1011405, 1011406, 1011408
CID:		1011409, 1011410, 1011411, 1011412, 1011413, 1011414
CID:		1017461, 1018387, 1086860, 1086874, 1194257, 1229897
CID:		1229968, 1306229, 1306234, 1331282, 1331283, 1331294
CID:		1331295, 1331535, 1331536, 1331539, 1331540, 1341623
CID:		1341624, 1341637, 1341638, 1355264, 1355324
Reviewed by:	scottl, ken, delphij, imp
MFH:		1 month
Differential Revision:	https://reviews.freebsd.org/D6496
2016-05-24 00:57:11 +00:00
Enji Cooper
fbcdfe1d5b Clean up trailing whitespace in lib/libcam; no functional change
MFC after: 3 weeks
Sponsored by: EMC / Isilon Storage Division
2016-04-14 21:10:53 +00:00
Enji Cooper
211d866621 Set dev->fd to -1 when calling cam_close_spec_device with a valid dev->fd
descriptor to avoid trashing valid file descriptors that access dev->fd at a
later point in time

PR: 192671
Submitted by: Scott Ferris <scott.ferris@isilon.com>
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
2015-10-17 09:07:53 +00:00
Nathan Whitehorn
169a84dd18 Add missing header.
Submitted by:	Sean Bruno
2013-10-30 15:46:50 +00:00
Nathan Whitehorn
abe8350519 printf() specifier updates to CAM to handle either 32-bit or 64-bit lun_id_t.
MFC after:	2 weeks
2013-10-30 14:13:15 +00:00
Xin LI
21d1182ecf Fix a typo: XPORT_SPI should be tested against transport, nor protocol.
Submitted by:	Sascha Wildner <swildner dragonflybsd org>
Reviewed by:	mjacob
MFC after:	2 weeks
2013-06-03 21:52:19 +00:00
Jaakko Heinonen
75a0cc3bd6 Use snprintf(3) constantly when generating CAM error messages.
PR:		bin/57088
Submitted by:	Rui Lopes, arundel
MFC after:	2 weeks
2012-03-03 09:19:20 +00:00
Ed Schouten
b3608ae18f Replace index() and rindex() calls with strchr() and strrchr().
The index() and rindex() functions were marked LEGACY in the 2001
revision of POSIX and were subsequently removed from the 2008 revision.
The strchr() and strrchr() functions are part of the C standard.

This makes the source code a lot more consistent, as most of these C
files also call into other str*() routines. In fact, about a dozen
already perform strchr() calls.
2012-01-03 18:51:58 +00:00
Andriy Gapon
84803238a8 camlib.c: update one overlooked comment 2010-10-11 21:34:35 +00:00
Andriy Gapon
5bcc8fafda cam_get_device, cam_open_device: make behavior simpler and more deterministic
Remove or re-work support for the several features from the past:
- remove incomplete support for trimming slice/partition names
- remove mapping from old device names "sd" and "st"
- remove whitespace trimming
- remove unconditional skipping of leading 'r' in a device name
- skip leading 'n' or 'e' only if the following device name matches
  a list of known devices that support no-rewind and eject-on-close
  features; currently this is only sa(4)
- reflect the above changes in comments in code and in cam(3)
- remove a note cautioning against use of cam_get_device and
  cam_open_device in cam(3)

Reviewed by:	mjacob
2010-10-11 09:27:37 +00:00
Marius Strobl
25ea4c843f Supply a valid Connect ID when issuing XPT_DEV_MATCH, which
according to my reading of the CAM draft is mandatory for
all CCB function calls and enforced by xptioctl() since at
least r168752. Previously we happened to use 0 as the Path
ID, causing the XPT_DEV_MATCH call to fail if there's no
SCSI bus 0. Basically the same bug was also fixed the same
way for camcontrol(8) as part of r126514.

PR:		127605
Submitted by:	Eygene Ryabinkin
Approved by:	silence from ken and scottl
MFC after:	1 week
2008-10-27 21:46:58 +00:00
Matt Jacob
bd3fd815a7 2nd and final commit that moves us to CAM_NEW_TRAN_CODE
as the default.

Reviewed by multitudes.
2006-11-02 00:54:38 +00:00
Joe Marcus Clarke
a7a6dfbd14 Go with a different version of the previous patch so to preserve errno.
Approved by:	scottl (implicit)
2006-04-30 07:08:43 +00:00
Joe Marcus Clarke
8bc181f506 Fix a file descriptor leak in cam_lookup_pass() when the ioctl to find
the passthru device fails.

Approved by:	scottl
MFC after:	1 day
2006-04-30 07:02:40 +00:00
Xin LI
ae73eb3a7f Better memory handling:
- It is acceptable to call free(3) when the given pointer itself
   is NULL, so we do not need to determine NULL before passing
   a pointer to free(3)
 - Handle failure of malloc(3)

MT6/5 Candidate

Submitted by:	Dan Lukes <dan at obluda cz>
PR:		bin/83352
2005-07-13 10:40:07 +00:00
Scott Long
c893420ff0 Change a couple of comments so that GCC doesn't think that they contain
tri-graphs.
2004-07-29 15:35:45 +00:00
Kenneth D. Merry
9460610494 string cleanup:
- fix a potential overrun made worse by rev 1.5 of camlib.h
 - change strncpy() and strcpy() calls to strlcpy()
 - use sizeof(string[]) instead of STRING_LEN to avoid future problems
 - get rid of an unused variable

Thanks to BDE for pointing out some of the problems.

MFC after:	2 weeks
2002-05-14 04:32:02 +00:00
Matthew Dillon
090f02d93c Add __FBSDID()s to libcam 2001-09-30 21:13:43 +00:00
Matt Jacob
3d09a65d42 Make sure you don't have a file descriptor leak for the 'real'
underlying CAM device. This needs to be checked not only in
the open routine, but the device->fd has to be initialized
as well.

PR:		28688
Submitted (partially) by:	T. William Wells <bill@twwells.com>
MFC after:	2 weeks
2001-07-04 07:43:10 +00:00
Matt Jacob
31faeddf80 get pd_type from inquiry data itself 2000-01-16 20:15:43 +00:00
Kenneth D. Merry
661d7edf84 Fix a file descriptor leak in cam_open_btl(). The xpt device was opened,
but never closed.

Submitted by:	amobbs@allstor-sw.co.uk
1999-09-12 19:40:20 +00:00
Peter Wemm
7f3dea244c $Id$ -> $FreeBSD$ 1999-08-28 00:22:10 +00:00
Mike Pritchard
3d416122d3 cam_get_device() was returning 0 on failure, and 1 on success, while
camcontrol(8) and the documentation in camlib.c and cam(3) all expect
-1 on failure and 0 on success.  Updated camlib.c to return the values
specified by the documentation.

PR:	12023
1999-06-15 20:03:01 +00:00
Kenneth D. Merry
b735c71405 Use snprintf to make sure we don't overflow a buffer. 1998-11-15 23:17:39 +00:00
Kenneth D. Merry
2327ec3a76 Fix an error message. (it was using an uninitialized variable)
Reported by:	dan@math.berkeley.edu (Dan Strick)
1998-11-15 23:12:42 +00:00
Kenneth D. Merry
621a60d46b Add a "dummy light" (actually two dummy lights) to catch people who don't
have the passthrough device configured in their kernel.

This will hopefully reduce the number of people complaining that they can't
get {camcontrol, xmcd, tosha, cdrecord, etc.} to work.

Reviewed by:	gibbs
1998-10-12 21:54:13 +00:00
Justin T. Gibbs
f736a45077 CAM userland utility library, a replacement for libscsi.
Submitted by: "Kenneth D. Merry" <ken@FreeBSD.org>
1998-09-15 06:16:46 +00:00