[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAq6er1=oeR9RP2JbwjaOY+F3saUwE7OgWVh-CCVqDuejKCTbw@mail.gmail.com>
Date: Tue, 20 Jun 2017 10:11:36 +0100
From: Andy Whitcroft <apw@...onical.com>
To: Dave Jones <davej@...emonkey.org.uk>,
Hugh Dickins <hughd@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>, Michal Hocko <mhocko@...e.com>
Subject: Re: Linux 4.12-rc6
On Tue, Jun 20, 2017 at 4:42 AM, Dave Jones <davej@...emonkey.org.uk> wrote:
> Almost shutdown, but not quite. Coincidentally, coverity just finished
> the rc6 run, and barfed this up.. related ?
>
> *** CID 1412907: Control flow issues (DEADCODE)
> /include/linux/mm.h: 2243 in vm_end_gap()
> 2237
> 2238 static inline unsigned long vm_end_gap(struct vm_area_struct *vma)
> 2239 {
> 2240 unsigned long vm_end = vma->vm_end;
> 2241
> 2242 if (vma->vm_flags & VM_GROWSUP) {
>>>> CID 1412907: Control flow issues (DEADCODE)
>>>> Execution cannot reach this statement: "vm_end += stack_guard_gap;".
> 2243 vm_end += stack_guard_gap;
> 2244 if (vm_end < vma->vm_end)
> 2245 vm_end = -PAGE_SIZE;
> 2246 }
> 2247 return vm_end;
> 2248 }
I suspect this is because coverity can tell we do not use VM_GROWSUP
in x86. I assume it would say the corresponding thing about the
VM_GROWSDOWN code in vm_start_gap() on those architectures with upward
growing stacks.
-apw
Powered by blists - more mailing lists