]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
ipc: convert invalid scenarios to use WARN_ON
authorDavidlohr Bueso <dave@stgolabs.net>
Wed, 9 Sep 2015 22:39:20 +0000 (15:39 -0700)
committerSasha Levin <sasha.levin@oracle.com>
Fri, 4 Mar 2016 15:25:45 +0000 (10:25 -0500)
commit6e82212c489fcdc50446bff12bd1ed5e8ef110a2
tree91cbcd13b093e1e60753d352c8e1bc7bee6f421c
parent0eba52da056a131ae7d5715e9bae4e147356d3d9
ipc: convert invalid scenarios to use WARN_ON

[ Upstream commit d0edd8528362c07216498340e928159510595e7b ]

Considering Linus' past rants about the (ab)use of BUG in the kernel, I
took a look at how we deal with such calls in ipc.  Given that any errors
or corruption in ipc code are most likely contained within the set of
processes participating in the broken mechanisms, there aren't really many
strong fatal system failure scenarios that would require a BUG call.
Also, if something is seriously wrong, ipc might not be the place for such
a BUG either.

1. For example, recently, a customer hit one of these BUG_ONs in shm
   after failing shm_lock().  A busted ID imho does not merit a BUG_ON,
   and WARN would have been better.

2. MSG_COPY functionality of posix msgrcv(2) for checkpoint/restore.
   I don't see how we can hit this anyway -- at least it should be IS_ERR.
    The 'copy' arg from do_msgrcv is always set by calling prepare_copy()
   first and foremost.  We could also probably drop this check altogether.
    Either way, it does not merit a BUG_ON.

3. No ->fault() callback for the fs getting the corresponding page --
   seems selfish to make the system unusable.

Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
ipc/msgutil.c
ipc/shm.c