- 12 1月, 2011 1 次提交
-
-
由 Dave Chinner 提交于
We currently have a global error message buffer in cmn_err that is protected by a spin lock that disables interrupts. Recently there have been reports of NMI timeouts occurring when the console is being flooded by SCSI error reports due to cmn_err() getting stuck trying to print to the console while holding this lock (i.e. with interrupts disabled). The NMI watchdog is seeing this CPU as non-responding and so is triggering a panic. While the trigger for the reported case is SCSI errors, pretty much anything that spams the kernel log could cause this to occur. Realistically the only reason that we have the intemediate message buffer is to prepend the correct kernel log level prefix to the log message. The only reason we have the lock is to protect the global message buffer and the only reason the message buffer is global is to keep it off the stack. Hence if we can avoid needing a global message buffer we avoid needing the lock, and we can do this with a small amount of cleanup and some preprocessor tricks: 1. clean up xfs_cmn_err() panic mask functionality to avoid needing debug code in xfs_cmn_err() 2. remove the couple of "!" message prefixes that still exist that the existing cmn_err() code steps over. 3. redefine CE_* levels directly to KERN_* 4. redefine cmn_err() and friends to use printk() directly via variable argument length macros. By doing this, we can completely remove the cmn_err() code and the lock that is causing the problems, and rely solely on printk() serialisation to ensure that we don't get garbled messages. A series of followup patches is really needed to clean up all the cmn_err() calls and related messages properly, but that results in a series that is not easily back portable to enterprise kernels. Hence this initial fix is only to address the direct problem in the lowest impact way possible. Signed-off-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NAlex Elder <aelder@sgi.com>
-
- 12 12月, 2009 1 次提交
-
-
由 Christoph Hellwig 提交于
Remove our own STATIC_INLINE macro. For small function inside implementation files just use STATIC and let gcc inline it, and for those in headers do the normal static inline - they are all small enough to be inlined for debug builds, too. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NDave Chinner <david@fromorbit.com> Signed-off-by: NAlex Elder <aelder@sgi.com>
-
- 22 12月, 2008 1 次提交
-
-
由 Christoph Hellwig 提交于
xfs_fs_vcmn_err can be called under a spinlock, but does a sleeping memory allocation to create buffer for it's internal sprintf. Fortunately it's the only caller of icmn_err, so we can merge the two and have one single static buffer and spinlock protecting it. While we're at it make sure we proper __attribute__ format annotations so that the compiler can detect mismatched format strings. Reported-by: NAlexander Beregalov <a.beregalov@gmail.com> Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NEric Sandeen <sandeen@sandeen.net> Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
-
- 30 4月, 2008 2 次提交
-
-
由 David Chinner 提交于
Noted-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NDave Chinner <dgc@sgi.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 David Chinner 提交于
SGI-PV: 979416 SGI-Modid: xfs-linux-melb:xfs-kern:31008a Signed-off-by: NDavid Chinner <dgc@sgi.com> Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
-
- 05 9月, 2007 1 次提交
-
-
由 Christoph Hellwig 提交于
- remove the != 0 inside the unlikely in ASSERT_ALWAYS because sparse now complains about comparisons between pointers and 0 - add a standalone ASSERT implementation because defining it to ASSERT_ALWAYS means the string is expanded before the token passing stringification. This way we get the actual content of the assertion in the assfail message and don't overflow sparse's stringification buffer leading to sparse error messages. SGI-PV: 968555 SGI-Modid: xfs-linux-melb:xfs-kern:29310a Signed-off-by: NChristoph Hellwig <hch@infradead.org> Signed-off-by: NDavid Chinner <dgc@sgi.com> Signed-off-by: NTim Shimmin <tes@sgi.com>
-
- 08 5月, 2007 1 次提交
-
-
由 Joe Perches 提交于
Patch provided by Joe Perches SGI-PV: 961696 SGI-Modid: xfs-linux-melb:xfs-kern:28209a Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NLachlan McIlroy <lachlan@sgi.com> Signed-off-by: NTim Shimmin <tes@sgi.com>
-
- 10 2月, 2007 1 次提交
-
-
由 David Chinner 提交于
gcc-4.1 and more recent aggressively inline static functions which increases XFS stack usage by ~15% in critical paths. Prevent this from occurring by adding noinline to the STATIC definition. Also uninline some functions that are too large to be inlined and were causing problems with CONFIG_FORCED_INLINING=y. Finally, clean up all the different users of inline, __inline and __inline__ and put them under one STATIC_INLINE macro. For debug kernels the STATIC_INLINE macro uninlines those functions. SGI-PV: 957159 SGI-Modid: xfs-linux-melb:xfs-kern:27585a Signed-off-by: NDavid Chinner <dgc@sgi.com> Signed-off-by: NDavid Chatterton <chatz@sgi.com> Signed-off-by: NTim Shimmin <tes@sgi.com>
-
- 09 6月, 2006 1 次提交
-
-
由 Nathan Scott 提交于
interface. SGI-PV: 953338 SGI-Modid: xfs-linux-melb:xfs-kern:26103a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 12 1月, 2006 1 次提交
-
-
由 Nathan Scott 提交于
equivalents. SGI-PV: 907752 SGI-Modid: xfs-linux-melb:xfs-kern:24961a Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 02 11月, 2005 2 次提交
-
-
由 Nathan Scott 提交于
boilerplate. SGI-PV: 913862 SGI-Modid: xfs-linux:xfs-kern:23903a Signed-off-by: NNathan Scott <nathans@sgi.com> -
由 Christoph Hellwig 提交于
SGI-PV: 942243 SGI-Modid: xfs-linux:xfs-kern:198658a Signed-off-by: NChristoph Hellwig <hch@sgi.com> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 21 6月, 2005 1 次提交
-
-
由 Christoph Hellwig 提交于
SGI-PV: 938063 SGI-Modid: xfs-linux:xfs-kern:194416a Signed-off-by: NChristoph Hellwig <hch@sgi.com> Signed-off-by: NNathan Scott <nathans@sgi.com>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-