Message-Id: <200410071927.i97JRQKO006355@turing-police.cc.vt.edu>
To: "David S. Miller" <davem@davemloft.net>
Cc: arun.sharma@intel.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Kill a sparse warning in binfmt_elf.c 
In-Reply-To: Your message of "Thu, 07 Oct 2004 12:16:23 PDT."
             <20041007121623.674796d1.davem@davemloft.net> 
From: Valdis.Kletnieks@vt.edu
References: <4164756E.4010408@intel.com> <200410071811.i97IBQf0031262@turing-police.cc.vt.edu> <41658FB4.5090402@intel.com> <200410071854.i97IsvU5031703@turing-police.cc.vt.edu>
            <20041007121623.674796d1.davem@davemloft.net>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_68684898P";
	 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 07 Oct 2004 15:27:26 -0400
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1257
Lines: 36

--==_Exmh_68684898P
Content-Type: text/plain; charset=us-ascii

On Thu, 07 Oct 2004 12:16:23 PDT, "David S. Miller" said:

> The caller's aren't, that is the point.  They run dump_write()
> with set_fs(KERNEL_DS), which allows kernel pointers to be treated
> as user ones in system call handling paths, which is why the cast
> is needed somewhere.

Right - and my point is that putting one cast way down at the bottom
to quiet a warning doesn't do much good - the cast should be pushed
up to as close to that set_fs() as feasible.  Otherwise if some other,
new, caller surfaces and bogusly passes something *else* in that
void * pointer, it gets a lot harder for sparse and similar to do their
jobs. 


--==_Exmh_68684898P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBZZiecC3lWbTT17ARAn6HAJ9MkB/1noTVsKBfbWYsqMBK2cYfbwCdEMaI
2OVRSwrzlkOnDMvOUL0JaXk=
=DZOA
-----END PGP SIGNATURE-----

--==_Exmh_68684898P--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/