litmus-rt-edfsc.git - LITMUS^RT with the EDF-SC plugin for Real-Time Systems journal paper

diff options

author	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>	2015-01-27 13:01:45 -0500
committer	Bjorn Helgaas <bhelgaas@google.com>	2015-01-28 18:08:20 -0500
commit	d2be00c0fb5ae0794deffcdb0425cd5a8d823db0 (patch)
tree	6f0a31e8a236f9278c15b40988f4ea23fbfdc496 /include/linux/inotify.h
parent	97bf6af1f928216fd6c5a66e8a57bfa95a659672 (diff)

of/pci: Free resources on failure in of_pci_get_host_bridge_resources()

In the function of_pci_get_host_bridge_resources() if the parsing of ranges fails, previously allocated resources inclusive of bus_range are not freed and are not expected to be freed by the function caller on error return. This patch fixes the issues by adding code that properly frees resources and bus_range before exiting the function with an error return value. Fixes: cbe4097f8ae6 ("of/pci: Add support for parsing PCI host bridge resources from DT") Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> CC: Arnd Bergmann <arnd@arndb.de> CC: Rob Herring <robh+dt@kernel.org>

Diffstat (limited to 'include/linux/inotify.h')

0 files changed, 0 insertions, 0 deletions

NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format (from dmesg, etc). Ignore any references in this or other docs to "decoding the Oops" or "running it through ksymoops". If you post an Oops from 2.6 that has been run through ksymoops, people will just tell you to repost it. Quick Summary ------------- Find the Oops and send it to the maintainer of the kernel area that seems to be involved with the problem. Don't worry too much about getting the wrong person. If you are unsure send it to the person responsible for the code relevant to what you were doing. If it occurs repeatably try and describe how to recreate it. That's worth even more than the oops. If you are totally stumped as to whom to send the report, send it to linux-kernel@vger.kernel.org. Thanks for your help in making Linux as stable as humanly possible. Where is the Oops? ---------------------- Normally the Oops text is read from the kernel buffers by klogd and handed to syslogd which writes it to a syslog file, typically /var/log/messages (depends on /etc/syslog.conf). Sometimes klogd dies, in which case you can run dmesg > file to read the data from the kernel buffers and save it. Or you can cat /proc/kmsg > file, however you have to break in to stop the transfer, kmsg is a "never ending file". If the machine has crashed so badly that you cannot enter commands or the disk is not available then you have three options :- (1) Hand copy the text from the screen and type it in after the machine has restarted. Messy but it is the only option if you have not planned for a crash. Alternatively, you can take a picture of the screen with a digital camera - not nice, but better than nothing. If the messages scroll off the top of the console, you may find that booting with a higher resolution (eg, vga=791) will allow you to read more of the text. (Caveat: This needs vesafb, so won't help for 'early' oopses) (2) Boot with a serial console (see Documentation/serial-console.txt), run a null modem to a second machine and capture the output there using your favourite communication program. Minicom works well. (3) Use Kdump (see Documentation/kdump/kdump.txt), extract the kernel ring buffer from old memory with using dmesg gdbmacro in Documentation/kdump/gdbmacros.txt. Full Information ---------------- NOTE: the message from Linus below applies to 2.4 kernel. I have preserved it for historical reasons, and because some of the information in it still applies. Especially, please ignore any references to ksymoops. From: Linus Torvalds <torvalds@osdl.org> How to track down an Oops.. [originally a mail to linux-kernel] The main trick is having 5 years of experience with those pesky oops messages ;-) Actually, there are things you can do that make this easier. I have two separate approaches: gdb /usr/src/linux/vmlinux gdb> disassemble <offending_function> That's the easy way to find the problem, at least if the bug-report is well made (like this one was - run through ksymoops to get the information of which function and the offset in the function that it happened in).


context:
space:
mode: