linux-kernel - Re: [PATCH 08/28] kdb: core for kgdb back end (2 of 2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1fx4ywlgr.fsf@fess.ebiederm.org>
Date:	Thu, 18 Feb 2010 08:35:32 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jason Wessel <jason.wessel@...driver.com>
Cc:	linux-kernel@...r.kernel.org, kgdb-bugreport@...ts.sourceforge.net,
	mingo@...e.hu, mort@....com, linux-arch@...r.kernel.org
Subject: Re: [PATCH 08/28] kdb: core for kgdb back end (2 of 2)

Jason Wessel <jason.wessel@...driver.com> writes:

> Eric W. Biederman wrote:
>> Jason Wessel <jason.wessel@...driver.com> writes:
>>
>>   
>>> This patch contains the hooks and instrumentation into kernel which
>>> live outside the kernel/debug directory, which the kdb core
>>> will call to run commands like lsmod, dmesg, bt etc...
>>>     
>>
>> You know this dropping the locks from vmalloc_info and swap_info
>> is down right ugly, and I don't believe it is safe.  That code
>> was not designed to run while the write_lock is held.
>>   
>
> Perhaps we can find some middle ground.  I don't mind simply not
> allowing the information to be queried from kdb if the locks are not
> available. 
>
> Which is less ugly you, making the swap_lock global or adding a function
> to query it?

My recommendation would be to simply drop the swap_info and meminfo
information for now, and have kdb do what is good at.

Skimming through the history of the discussion it appears Christoph
Hellwig asked you to do something about these bits on the first
review.

>From a maintenance point of view anything where you have to know which
locks a function will take is fragile.  It is entirely too easy to create
a change that is fine in it's normal context but breaks kdb.

Alt-sysrq already allows capturing that kind of information, without any
thorny maintenance issues.  By contrast kdb appears to be a much larger
and inferior tool.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/