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: <3908561D78D1C84285E8C5FCA982C28F32838E10@ORSMSX114.amr.corp.intel.com>
Date:	Wed, 18 Jun 2014 17:50:45 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Liu hua <sdu.liu@...wei.com>,
	"anton@...msg.org" <anton@...msg.org>,
	"ccross@...roid.com" <ccross@...roid.com>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	Wang Nan <wangnan0@...wei.com>,
	"peifeiyue@...wei.com" <peifeiyue@...wei.com>
Subject: RE: Should Pstore(ramoops) records customized information?

> (1) The backend (ramoops) provides servel memory regions staticly. Each region
>  is a ring buffer, which does not connect with certain PSTORE_TYPE_ID. So no one
>  can modify or use it before allocation.
>
> (2) A pstore user allocs a memory region, pstore will return a pstore_type_id.
>
>        pstore_type_id = alloc_pstroe_region()
>
> (3) This user record certain message to this region.
>
>        psinfo->write(pstore_type_id, ...)

Don't you need to match up the number of back-end ring buffer regions
with the number of users in the kernel that call alloc_pstore_region()?

Or do you envision that the backend can create these regions on demand?

Would different users need different sized regions? I think logging of
console messages might be able to work with a smaller ring buffer
than the ftrace logger. So perhaps we need a "size" argument when allocating?

Since these "regions" are in fact "ring buffers", the name of the allocation
routine should make that clear.  So call it "pstore_alloc_ring_buffer()"

After the system hangs/crashes ... how would you like pstore to
name these objects in /sys/fs/pstore/ for applications to pick them
up for analysis?  Maybe pstore_alloc_ring_buffer() needs a "char *name"
argument as well as a size?

-Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ