From: kbuild test robot <lkp@intel.com>
To: zhongjiang <zhongjiang@huawei.com>
Cc: kbuild-all@01.org, ebiederm@xmission.com,
akpm@linux-foundation.org, kexec@lists.infradead.org,
linux-mm@kvack.org
Subject: Re: [PATCH v2] kexec: add resriction on the kexec_load
Date: Fri, 22 Jul 2016 14:49:59 +0800 [thread overview]
Message-ID: <201607221439.VrD5UxKG%fengguang.wu@intel.com> (raw)
In-Reply-To: <1469165566-12897-1-git-send-email-zhongjiang@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 4347 bytes --]
Hi,
[auto build test ERROR on stable/master]
[also build test ERROR on v4.7-rc7]
[cannot apply to next-20160721]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/zhongjiang/kexec-add-resriction-on-the-kexec_load/20160722-143017
base: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git master
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
kernel/kexec_core.c: In function 'sanity_check_segment_list':
>> kernel/kexec_core.c:222:3: error: 'total' undeclared (first use in this function)
total += image->segment[i].memsz;
^~~~~
kernel/kexec_core.c:222:3: note: each undeclared identifier is reported only once for each function it appears in
>> kernel/kexec_core.c:151:16: warning: unused variable 'total_segments' [-Wunused-variable]
unsigned long total_segments = 0;
^~~~~~~~~~~~~~
vim +/total +222 kernel/kexec_core.c
145 gfp_t gfp_mask,
146 unsigned long dest);
147
148 int sanity_check_segment_list(struct kimage *image)
149 {
150 int result, i;
> 151 unsigned long total_segments = 0;
152 unsigned long nr_segments = image->nr_segments;
153
154 /*
155 * Verify we have good destination addresses. The caller is
156 * responsible for making certain we don't attempt to load
157 * the new image into invalid or reserved areas of RAM. This
158 * just verifies it is an address we can use.
159 *
160 * Since the kernel does everything in page size chunks ensure
161 * the destination addresses are page aligned. Too many
162 * special cases crop of when we don't do this. The most
163 * insidious is getting overlapping destination addresses
164 * simply because addresses are changed to page size
165 * granularity.
166 */
167 result = -EADDRNOTAVAIL;
168 for (i = 0; i < nr_segments; i++) {
169 unsigned long mstart, mend;
170
171 mstart = image->segment[i].mem;
172 mend = mstart + image->segment[i].memsz;
173 if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK))
174 return result;
175 if (mend >= KEXEC_DESTINATION_MEMORY_LIMIT)
176 return result;
177 }
178
179 /* Verify our destination addresses do not overlap.
180 * If we alloed overlapping destination addresses
181 * through very weird things can happen with no
182 * easy explanation as one segment stops on another.
183 */
184 result = -EINVAL;
185 for (i = 0; i < nr_segments; i++) {
186 unsigned long mstart, mend;
187 unsigned long j;
188
189 mstart = image->segment[i].mem;
190 mend = mstart + image->segment[i].memsz;
191 for (j = 0; j < i; j++) {
192 unsigned long pstart, pend;
193
194 pstart = image->segment[j].mem;
195 pend = pstart + image->segment[j].memsz;
196 /* Do the segments overlap ? */
197 if ((mend > pstart) && (mstart < pend))
198 return result;
199 }
200 }
201
202 /* Ensure our buffer sizes are strictly less than
203 * our memory sizes. This should always be the case,
204 * and it is easier to check up front than to be surprised
205 * later on.
206 */
207 result = -EINVAL;
208 for (i = 0; i < nr_segments; i++) {
209 if (image->segment[i].bufsz > image->segment[i].memsz)
210 return result;
211 }
212
213 /* Verity all segment size donnot exceed the specified size.
214 * if segment size from user space is too large, a large
215 * amount of time will be wasted when allocating page. so,
216 * softlockup may be come up.
217 */
218 for (i = 0; i < nr_segments; i++) {
219 if (image->segment[i].memsz > (totalram_pages / 2))
220 return result;
221
> 222 total += image->segment[i].memsz;
223 }
224
225 if (total > (totalram_pages / 2))
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 24863 bytes --]
next prev parent reply other threads:[~2016-07-22 6:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-22 5:32 zhongjiang
2016-07-22 6:49 ` kbuild test robot [this message]
2016-07-22 5:36 zhongjiang
2016-07-22 19:58 ` Andrew Morton
2016-07-23 7:27 ` zhong jiang
2016-07-23 11:23 ` zhong jiang
2016-07-23 13:37 ` zhong jiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201607221439.VrD5UxKG%fengguang.wu@intel.com \
--to=lkp@intel.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=kbuild-all@01.org \
--cc=kexec@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=zhongjiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox