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] [day] [month] [year] [list]
Message-ID: <49E57E05.60400@petalogix.com>
Date:	Wed, 15 Apr 2009 08:26:13 +0200
From:	Michal Simek <michal.simek@...alogix.com>
To:	David Miller <davem@...emloft.net>
CC:	arnd@...db.de, linux-kernel@...r.kernel.org
Subject: Re: struct exception_table_entry

David Miller wrote:
> From: Arnd Bergmann <arnd@...db.de>
> Date: Tue, 14 Apr 2009 16:36:11 +0200
>
>   
>> On Thursday 09 April 2009, Michal Simek wrote:
>>
>>     
>>> I am doing some cleanup things in MB MMU kernel and I looked at
>>> exception_table_entry structure.
>>> Only alpha use different types among others. Some arch use only
>>> different names and types int/long.
>>> I think that this structure could be moved to any generic location ->
>>> asm-generic/uaccess.h folder.
>>>
>>> I think that this structure types should be acceptable for every archs?
>>>
>>> #ifndef exception_table_entry
>>> struct exception_table_entry {
>>>     unsigned long insn;
>>>     unsigned long fixup;
>>> };
>>> #endif
>>>
>>> What do you think?
>>>       
>> Yes, sounds good to me. Have you tried using my generic version of
>> uaccess.h on microblaze? It already contains a definition like this,
>> though most of the header doesn't apply for MMU-based architectures.
>>
>> I suppose it can be improved a bit, but should do the basic job.
>>     
>
> Note that for space saving several 64-bit architectures use plain
> "int" here when they know that all kernel addresses are in the low
> 32-bits of the address space.
>   
Just one my note: use u32 instead of int.

Michal
> sparc64 is one such architecture and I'd prefer if the size of these
> tables does not bloat up when you guys try to make this thing generic.
>   


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ