Re: [PATCH v3] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
On 01/10/2014 02:42 AM, Will Deacon wrote: > On Thu, Jan 09, 2014 at 12:47:24PM +, Stefano Stabellini wrote: >> On Thu, 9 Jan 2014, Arnd Bergmann wrote: >>> On Thursday 09 January 2014, Will Deacon wrote: On Wed, Jan 08, 2014 at 06:00:23PM +, Stefano Stabellini wrote: > Remove !GENERIC_ATOMIC64 build dependency: > - rename atomic64_xchg to armv7_atomic64_xchg and define it even ifdef > GENERIC_ATOMIC64; > - call armv7_atomic64_xchg directly from xen/events.h. > > Remove !CPU_V6 build dependency: > - introduce __cmpxchg8 and __cmpxchg16, compiled even ifdef > CONFIG_CPU_V6; > - implement sync_cmpxchg using __cmpxchg8 and __cmpxchg16. > > Signed-off-by: Stefano Stabellini > CC: a...@arndb.de > CC: li...@arm.linux.org.uk > CC: will.dea...@arm.com > CC: gang.c...@asianux.com > CC: catalin.mari...@arm.com > CC: jaccon.bastiaan...@gmail.com > CC: linux-arm-ker...@lists.infradead.org > CC: linux-kernel@vger.kernel.org > I'm confused here. It looks like you want to call armv7 code in a v6 kernel. What am I missing? >>> >>> This is about being able to build a kernel that runs on ARMv6 and ARMv7 >>> and also includes Xen. Because of obvious hardware limitations, Xen >>> will only run on v7, but currently you cannot even build it once you >>> enable (pre-v6K) ARMv6 support, since the combined v6+v7 kernel can't >>> do atomic accesses in a generic way on non-32bit variables. >> >> Yep, that's right. > > Ok, thanks for the explanation. Looking at the patch, I wonder whether it's > not cleaner just to implement xchg code separately for Xen? The Linux code > isn't always sufficient (due to the GENERIC_ATOMIC64 stuff) and most of the > churn coming out of this patch is an attempt to provide some small code > reuse at the cost of code readability. > > What do others think? > What Will said sounds reasonable to me. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: cris: uapi: be sure of "_UAPI" prefix for all guard macros
On 11/17/2013 07:35 PM, Chen Gang wrote: > For all uapi headers, need use "_UAPI" prefix for its guard macro > (which will be stripped by "scripts/headers_installer.sh"). > > Also be sure that all standard header files have their guard macros. > I removed all files which only includes related "asm-generic" header file in its real contents, and did not care about whether it has guard macro or not (e.g. "errno.h"), can it cause issue? BTW: I also changed my Signed-off-by mail address (now I am a real 'free' guy which has no 'jobs'). Thanks. > Also be sure that all "#endif" are followed with correct comments, and > single empty line after "#ifndef" and/or before "#endif", and no empty > lines after "#endif". > > > Signed-off-by: Chen Gang > --- > arch/cris/include/uapi/arch-v10/arch/sv_addr_ag.h | 9 +++-- > arch/cris/include/uapi/arch-v10/arch/svinto.h | 6 +++--- > arch/cris/include/uapi/arch-v10/arch/user.h | 6 +++--- > arch/cris/include/uapi/arch-v32/arch/cryptocop.h | 3 --- > arch/cris/include/uapi/arch-v32/arch/user.h | 6 +++--- > arch/cris/include/uapi/asm/Kbuild | 22 -- > arch/cris/include/uapi/asm/auxvec.h | 6 +++--- > arch/cris/include/uapi/asm/bitsperlong.h | 1 - > arch/cris/include/uapi/asm/byteorder.h| 8 +++- > arch/cris/include/uapi/asm/errno.h| 6 -- > arch/cris/include/uapi/asm/ethernet.h | 8 +--- > arch/cris/include/uapi/asm/etraxgpio.h| 6 +++--- > arch/cris/include/uapi/asm/fcntl.h| 1 - > arch/cris/include/uapi/asm/ioctl.h| 1 - > arch/cris/include/uapi/asm/ioctls.h | 6 +++--- > arch/cris/include/uapi/asm/ipcbuf.h | 1 - > arch/cris/include/uapi/asm/kvm_para.h | 1 - > arch/cris/include/uapi/asm/mman.h | 1 - > arch/cris/include/uapi/asm/msgbuf.h | 6 +++--- > arch/cris/include/uapi/asm/param.h| 6 +++--- > arch/cris/include/uapi/asm/poll.h | 1 - > arch/cris/include/uapi/asm/posix_types.h | 6 +++--- > arch/cris/include/uapi/asm/ptrace.h | 5 + > arch/cris/include/uapi/asm/resource.h | 6 -- > arch/cris/include/uapi/asm/rs485.h| 4 > arch/cris/include/uapi/asm/sembuf.h | 6 +++--- > arch/cris/include/uapi/asm/setup.h| 6 +++--- > arch/cris/include/uapi/asm/shmbuf.h | 6 +++--- > arch/cris/include/uapi/asm/sigcontext.h | 7 +++ > arch/cris/include/uapi/asm/siginfo.h | 6 -- > arch/cris/include/uapi/asm/signal.h | 1 - > arch/cris/include/uapi/asm/socket.h | 8 +++- > arch/cris/include/uapi/asm/sockios.h | 6 +++--- > arch/cris/include/uapi/asm/stat.h | 6 +++--- > arch/cris/include/uapi/asm/statfs.h | 6 -- > arch/cris/include/uapi/asm/swab.h | 4 > arch/cris/include/uapi/asm/sync_serial.h | 6 +++--- > arch/cris/include/uapi/asm/termbits.h | 6 +++--- > arch/cris/include/uapi/asm/termios.h | 1 - > arch/cris/include/uapi/asm/types.h| 5 + > 40 files changed, 95 insertions(+), 117 deletions(-) > delete mode 100644 arch/cris/include/uapi/asm/bitsperlong.h > delete mode 100644 arch/cris/include/uapi/asm/errno.h > delete mode 100644 arch/cris/include/uapi/asm/fcntl.h > delete mode 100644 arch/cris/include/uapi/asm/ioctl.h > delete mode 100644 arch/cris/include/uapi/asm/ipcbuf.h > delete mode 100644 arch/cris/include/uapi/asm/kvm_para.h > delete mode 100644 arch/cris/include/uapi/asm/mman.h > delete mode 100644 arch/cris/include/uapi/asm/poll.h > delete mode 100644 arch/cris/include/uapi/asm/resource.h > delete mode 100644 arch/cris/include/uapi/asm/siginfo.h > delete mode 100644 arch/cris/include/uapi/asm/statfs.h > > diff --git a/arch/cris/include/uapi/arch-v10/arch/sv_addr_ag.h > b/arch/cris/include/uapi/arch-v10/arch/sv_addr_ag.h > index 5517f04..de850ff 100644 > --- a/arch/cris/include/uapi/arch-v10/arch/sv_addr_ag.h > +++ b/arch/cris/include/uapi/arch-v10/arch/sv_addr_ag.h > @@ -13,9 +13,8 @@ > *! > *!**/ > > -#ifndef __sv_addr_ag_h__ > -#define __sv_addr_ag_h__ > - > +#ifndef _UAPI__sv_addr_ag_h__ > +#define _UAPI__sv_addr_ag_h__ > > #define __test_sv_addr__ 0 > > @@ -134,6 +133,4 @@ IO_RD(R_EXT_DMA_0_STAT) & IO_MASK( R_EXT_DMA_0_STAT, S ) > == IO_STATE( R_EXT_DMA_0_STAT, S, STARTED ) > #endif > > - > -#endif /* ifndef __sv_addr_ag_h__ */ > - > +#endif /* _UAPI__sv_addr_ag_h__ */ > diff --git a/arch/cris/include/uapi/arch-v10/arch/svinto.h > b/arch/cris/include/uapi/arch-v10/arch/svinto.h > index da5c152..9327d3b 100644 > --- a/arch/cris/include/uapi/arch-v10/arch/sv
Re: [Suggestion] about latest commit for "scripts/get_maintainers.pl"
On 11/02/2013 02:32 AM, Joe Perches wrote:
> On Fri, 2013-11-01 at 19:20 +0800, Chen Gang wrote:
>> > Hello Joe:
> Hello Chen Gang.
>
>> > I meet a failure about "scripts/get_maintainers.pl", it is about the
>> > commit "750432d get_maintainer.pl incomplete output", if use original
>> > "scripts/get_maintainer.pl", it will be OK.
>> >
>> > Please help check, thanks.
> I don't get that effect.
For me now, I made 3 patches for hexagon, 2 of them can cause issue. I
use sfr next-20131101 tree, the related patch is in attachment (1, 3 can
cause issue), hope they are useful for us.
> I'll look into it and see what I find next week.
Thank you very much, just please help analyze it when you have time.
> You seem to have a work-around available.
Yes, at least now, it doesn't matter to me. I guess this issue is not
urgent to us.
Thanks.
--
Chen Gang
>From ef7384078bacdc5151039ea710943e5710d7c5ed Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Fri, 1 Nov 2013 18:58:18 +0800
Subject: [PATCH 1/3] hexagon: kernel: remove useless variables 'dn', 'r' and
'err' in time_init_deferred() in "time.c"
Signed-off-by: Chen Gang
---
arch/hexagon/kernel/time.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/hexagon/kernel/time.c b/arch/hexagon/kernel/time.c
index 9903fad..d0c4f5a 100644
--- a/arch/hexagon/kernel/time.c
+++ b/arch/hexagon/kernel/time.c
@@ -191,9 +191,6 @@ void __init time_init_deferred(void)
{
struct resource *resource = NULL;
struct clock_event_device *ce_dev = &hexagon_clockevent_dev;
- struct device_node *dn;
- struct resource r;
- int err;
ce_dev->cpumask = cpu_all_mask;
--
1.7.7.6
>From 2e587500be49b44b8d8a5b1e429c6f75b0803495 Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Fri, 1 Nov 2013 19:44:02 +0800
Subject: [PATCH] hexagon: kernel: kgdb: include related header for pass compiling.
Need include related headers for pass compiling, the related error (with allmodconfig for v4):
CC arch/hexagon/kernel/kgdb.o
arch/hexagon/kernel/kgdb.c:30: error: invalid use of undefined type 'struct pt_regs'
arch/hexagon/kernel/kgdb.c:31: error: invalid use of undefined type 'struct pt_regs'
...
arch/hexagon/kernel/kgdb.c:220: error: implicit declaration of function 'local_irq_save'
arch/hexagon/kernel/kgdb.c:222: error: implicit declaration of function 'local_irq_restore'
...
Signed-off-by: Chen Gang
---
arch/hexagon/kernel/kgdb.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
index 82d5c25..038580c 100644
--- a/arch/hexagon/kernel/kgdb.c
+++ b/arch/hexagon/kernel/kgdb.c
@@ -18,6 +18,8 @@
* 02110-1301, USA.
*/
+#include
+#include
#include
#include
--
1.7.7.6
>From cc69a713ea496aa8e952d9c3c312a659dc1fd5ab Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Fri, 1 Nov 2013 19:45:59 +0800
Subject: [PATCH] hexagon: include: asm: kgdb: extend DBG_MAX_REG_NUM for "cs0/1"
Need extend maximized number for "cs0/1", the related warning (with allmodconfig for v4):
arch/hexagon/kernel/kgdb.c:79: warning: excess elements in array initializer
arch/hexagon/kernel/kgdb.c:79: warning: (near initialization for 'dbg_reg_def')
arch/hexagon/kernel/kgdb.c:80: warning: excess elements in array initializer
arch/hexagon/kernel/kgdb.c:80: warning: (near initialization for 'dbg_reg_def')
Signed-off-by: Chen Gang
---
arch/hexagon/include/asm/kgdb.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/hexagon/include/asm/kgdb.h b/arch/hexagon/include/asm/kgdb.h
index 32a6fb6..ccd3ac3 100644
--- a/arch/hexagon/include/asm/kgdb.h
+++ b/arch/hexagon/include/asm/kgdb.h
@@ -34,10 +34,11 @@ static inline void arch_kgdb_breakpoint(void)
* 32 gpr + sa0/1 + lc0/1 + m0/1 + gp + ugp + pred + pc = 42 total.
* vm regs = psp+elr+est+badva = 4
* syscall+restart = 2 more
- * so 48 = 42 +4 + 2
+ * also add cs0/1 = 2
+ * so 48 = 42 + 4 + 2 + 2
*/
#define DBG_USER_REGS 42
-#define DBG_MAX_REG_NUM (DBG_USER_REGS + 6)
+#define DBG_MAX_REG_NUM (DBG_USER_REGS + 8)
#define NUMREGBYTES (DBG_MAX_REG_NUM*4)
#endif /* __HEXAGON_KGDB_H__ */
--
1.7.7.6
Re: [PATCH] kernel/modsign_certificate.S: use real contents instead of macro GLOBAL()
On 10/26/2013 10:42 AM, Chen Gang wrote: > On 10/24/2013 11:29 PM, Josh Boyer wrote: >> On Wed, Oct 23, 2013 at 10:31 PM, Chen Gang wrote: >>> For some architectures, tool chain is not smart enough to recognize the >>> macro with multiple lines (e.g. arc tool chain), and for common ".S" >>> file, this kind of macro is also rarely used. >>> >>> So expand the related contents of macro to let it pass compiling (can >>> use "arc-elf32-objdump -x" to know about it). >>> >>> The related error (allmodconfig for arc): >>> >>> LD init/built-in.o >>> kernel/built-in.o: In function `load_module_signing_keys': >>> kernel/modsign_pubkey.c:66: undefined reference to >>> `modsign_certificate_list' >>> kernel/modsign_pubkey.c:71: undefined reference to >>> `modsign_certificate_list_end' >>> kernel/modsign_pubkey.c:67: undefined reference to >>> `modsign_certificate_list_end' >>> >>> The related tool chain information: >>> >>> [root@gchenlinux linux-next]# arc-elf32-as -v >>> GNU assembler version 2.23.2 (arc-elf32) using BFD version (GNU Binutils) >>> 2.23.2 >>> [root@gchenlinux linux-next]# arc-elf32-ld -v >>> GNU ld (GNU Binutils) 2.23.2 >>> [root@gchenlinux linux-next]# arc-elf32-gcc -v >>> Using built-in specs. >>> COLLECT_GCC=arc-elf32-gcc >>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arc-elf32/4.8.0/lto-wrapper >>> Target: arc-elf32 >>> Configured with: ../gcc/configure --without-header --disable-nls >>> --enable-language=c --disable-threads --disable-shared --enable-werror=no >>> target_configargs=enable_vtable_verify=yes --target=arc-elf32 >>> --with-cpu=arc700 : (reconfigured) ../gcc/configure --disable-nls >>> --enable-language=c --disable-threads --disable-shared --enable-werror=no >>> target_configargs=enable_vtable_verify=yes --target=arc-elf32 >>> --with-cpu=arc700 : (reconfigured) ../gcc/configure --without-header >>> --disable-nls --enable-language=c --disable-threads --disable-shared >>> --enable-werror=no target_configargs=enable_vtable_verify=yes >>> --target=arc-elf32 --with-cpu=arc700 --disable-multilib >>> --with-headers=../newlib/newlib/libc/include >>> Thread model: single >>> gcc version 4.8.0 (GCC) >> >> Is this only an issue with using multi-line macro definitions in .S >> files? The practice of using multi-line macro definitions isn't rare. >> Look at e.g. include/linux/module.h, and a number of other header >> files. >> > > Yes, excluding "arch/*", for all ".S" files, except x86 driver and this > file, no others use multi-line macro definition, and "arch/arc" don't > use mulit-line macro definitions, either. > Oh, sorry, what my written is not quite precise, and my real meaning is: "no others *intend* to use multi-line macro definition in *.S". > The related search command is: > > "find | grep -i "\.S$" | grep -v "/arch/" | grep -v "Documentation" | > xargs grep define". > > Hmm... at least, in our case, we need not use the multi-line macro > definition, if expand it, the total lines will be shrunk, that will > be more clearer and simpler to source code readers and writers. > > >> This seems like a toolchain bug that should be fixable if it works for >> other architectures. >> > > Hmm... at least, we are sure the toolchain is not quite smart enough > (but we can not say it must be a bug). > > > So for me, I recommend to apply this patch (maybe the patch comment > need improvement). It is quite valuable to continue discussing about > it, but it is not related with whether applying this patch or not. > >> josh >> >> > > Thanks. > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suggestion] about calling debug_hotplug_cpu() which enabled by 'allmodconfig' for a x86_64 dual core laptop.
On 10/03/2013 10:51 PM, Toshi Kani wrote: > On Thu, 2013-10-03 at 00:49 +, Chen Gang wrote: >> On 10/03/2013 03:33 AM, Toshi Kani wrote: >>> On Thu, 2013-10-03 at 00:41 +0800, Chen Gang F T wrote: >>>> On 10/02/2013 11:28 PM, Toshi Kani wrote: >>>>> On Wed, 2013-10-02 at 03:10 +, Chen Gang wrote: >>>>>> Hello Maintainers: >>>>>> >>>>>> Under my x86_64 dual core laptop, I build kernel next-20130927 with >>>>>> 'allmodconfig', and install it, the machine can not start. Related >>>>>> information is: >>>>>> >>>>>> after call debug_hotplug_cpu(), output "cpu 0 is offline" and >>>>>> then "Failed to execute /init". >>>>>> >>>>>> After remove "_debug_hotplug_cpu(0, 0);", can pass the issue (but will >>>>>> fail in another place). I guess, the reason is my laptop cpu is not >>>>>> 'hotplug', but have to call debug_hotplug_cpu() with allmodconfig. >>>>>> >>>>>> >>>>>> I will continue analyzing, welcome any additional suggestions or >>>>>> completions. >>>>> >>>>> allmodconfig sets CONFIG_DEBUG_HOTPLUG_CPU0 to y (which is defined as >>>>> "def_bool n"), which puts CPU0 offline during boot for testing. This >>>>> debug feature is causing the problem on your laptop. I am not familiar >>>>> with allmodconfig, but it seems that it enables all the config options, >>>>> preferably with 'm'. >>>>> >>>> >>>> Hmm... excuse me, I don't know: for laptop, if cpu0 is offline, whether >>>> it still can work or not. If any members know about it, please tell me, >>>> thanks. >>> >>> CPU online/offline works on laptops as long as they have more than one >>> CPU. You can boot with other kernel and test this feature >>> with /sys/devices/system/cpu/cpuX/online on your laptop. cpu0 is a >>> special case and you may need to specify "cpu0_hotplug" boot option. >>> >> >> Thank you for your confirmation, "for dual core (although laptop), after >> system boot up, can let cpu0 offline". :-) > > Good. :) > >>>> In my opinion, if enable DEBUG_HOTPLUG_CPU0, but "should not let cpu0 >>>> offline for laptop", we need let 'offline' operation fail. >>> >>> Whether it is a laptop or not should not be a matter here. But I agree >>> with you that enabling CONFIG_DEBUG_HOTPLUG_CPU0 is not useful (and can >>> be harmful) unless a user really intends to test this feature. >>> >> >> Hmm... I will continue analyzing. After finish analyzing (let kernel >> boot up OK), I should give a confirmation: "during boot up, can we still >> let cpu0 offline for dual core?". >> >> In fact, 'allmodconfig' is just a mad user which often does useless >> things to intend to find issues. > > I see. If this option is used for testing, enabling DEBUG_HOTPLUG_CPU0 > does make sense. > Thank you for your encouragement. My current idea about testing/analyzing/fixing is: can boot up in allmodconfig for x86, smp version on dual/one core cpu. can boot up under other architectures in allmodconfig in kvm machine. can boot up with defconfig on x86 and various virtual machines. My original idea is to use outside testing tools (e.g. LTP) for kernel, hope I won't delay again (I have delayed several times), before outside testing, we need pass internal test firstly (at least, can boot up). Thanks. > Thanks, > -Toshi > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suggestion] about calling debug_hotplug_cpu() which enabled by 'allmodconfig' for a x86_64 dual core laptop.
On 10/02/2013 11:28 PM, Toshi Kani wrote: > On Wed, 2013-10-02 at 03:10 +, Chen Gang wrote: >> Hello Maintainers: >> >> Under my x86_64 dual core laptop, I build kernel next-20130927 with >> 'allmodconfig', and install it, the machine can not start. Related >> information is: >> >> after call debug_hotplug_cpu(), output "cpu 0 is offline" and then >> "Failed to execute /init". >> >> After remove "_debug_hotplug_cpu(0, 0);", can pass the issue (but will >> fail in another place). I guess, the reason is my laptop cpu is not >> 'hotplug', but have to call debug_hotplug_cpu() with allmodconfig. >> >> >> I will continue analyzing, welcome any additional suggestions or >> completions. > > allmodconfig sets CONFIG_DEBUG_HOTPLUG_CPU0 to y (which is defined as > "def_bool n"), which puts CPU0 offline during boot for testing. This > debug feature is causing the problem on your laptop. I am not familiar > with allmodconfig, but it seems that it enables all the config options, > preferably with 'm'. > Hmm... excuse me, I don't know: for laptop, if cpu0 is offline, whether it still can work or not. If any members know about it, please tell me, thanks. In my opinion, if enable DEBUG_HOTPLUG_CPU0, but "should not let cpu0 offline for laptop", we need let 'offline' operation fail. And I am analyzing (just constructing environments: KVM, kgdb ...), before let kernel start successfully, only according to my current proofs, we can not say "let laptop cpu0 offline" must be an issue. Thanks. > Thanks, > -Toshi > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/rcutree.c: deem to be lazy if there are no callbacks.
On 09/04/2013 03:36 AM, Paul E. McKenney wrote: > On Mon, Aug 26, 2013 at 10:21:18AM +0800, Chen Gang F T wrote: >> >> Firstly, thank you for your reply with these details. >> >> On 08/26/2013 03:18 AM, Paul E. McKenney wrote: >>> On Thu, Aug 22, 2013 at 11:01:53AM +0800, Chen Gang wrote: >>>> On 08/21/2013 10:23 PM, Paul E. McKenney wrote: >>>>> On Wed, Aug 21, 2013 at 01:59:29PM +0800, Chen Gang wrote: >>> >>> [ . . . ] >>> >>>>> Don't get me wrong, I do welcome appropriate patches. In fact, if >>>>> you look at RCU's git history, you will see that I frequently accept >>>>> patches from a fair number of people. And if you were willing to >>>>> invest some time and thought, you might eventually be able to generate >>>>> an appropriate (albeit low priority) patch to this function. However, >>>>> you seem to be motivated to submit small patches with a minimum of >>>>> thought and preparation, perhaps because you need to meet some external >>>>> or self-imposed quota of accepted patches. And if you are in fact driven >>>>> by a quota that prevents you from taking the time required to carefully >>>>> think things through, you are wasting your time with RCU. >>>> >>>> Hmm... at least, some contents you said above is correct to me. >>>> >>>> At least, I should provide 10 patches per month, it is a necessary >>>> basic requirement to me. >>> >>> OK, that does help explain the otherwise inexplicable approach you have >>> been taking. Let's see how you have been doing, based on committer date >>> in Linus's tree: >>> >>> 1 2012-11 >>> 15 2013-01 >>> 7 2013-02 >>> 20 2013-03 >>> 21 2013-04 >>> 12 2013-05 >>> 17 2013-06 >>> 10 2013-07 >>> >>> The last few months might be understated a bit due to patches >>> still being in maintainer trees. This is a nice contrast from my >>> first impression of you from https://lkml.org/lkml/2013/6/9/64 and >>> https://lkml.org/lkml/2013/8/19/650, neither of which gave me any >>> reason to trust your work, to put it mildly. And if I cannot trust >>> your work, I obviously cannot accept your patches. >>> >> >> Hmm... better to check patches independent personal feelings (trust >> some one, or not). >> >> ;-) > > Believe me, I judged based on your first two patches! Those were my > first impression of you. > OK, I can understand. >>> You do seem to select for localized bug fixes, which require less work >>> than the performance-motivated patches you were putting forward earlier >>> in this thread. With a localized bug, you demonstrate the bug, show the >>> fix, and that is that. From what I can see, part of the problem with >>> your patches in this email thread is that you are trying to move from >>> localized bug fixes to performance issues without doing the additional >>> work required. Please see below for a rough outline of this additional >>> work. >>> >> >> Hmm... it seems I need describe my work flow for fixing bugs in details. >> >> 1. Is it a bug ? >> if so, I can be marked as Reported-by and continue to 2nd. >> else, it is a waste mail. >> >> 2. Try to fix it in simple ways (so can save the maintainers time >> resource). >> if it can be accepted by maintainers, it is OK (I can be Signed-off-by). >> else need continue to 3rd. >> >>exception: if I can not find a simple way to fix it, I will send >> [Suggestion] mail. >> >> 3. Do the maintainers know how to fix it ? >> if yes, fix it together with maintainers (may mark me only as >> Reported-by). >> else need continue to Last. >> >> Last: I should analyze it and fix it (it is my duty to fix it). >> >> >> How do you feel about this work flow ? welcome any suggestions or >> completions. > > I am surprised that there are no testing or validation steps. > Hmm... "fix it together" in 3rd step, may include test. And for the 'Last' (I should analyze it and fix it, if maintainers do not know either or lack of maintainers), your original information is very good reference. Our mailing list is also developing mailing list (it is not only result report mailing list, or integration mailing list), so I can develop and test with anth
Re: [PATCH v2 0/8] Drop support for Renesas H8/300 architecture
Thank you for your valuable information: it will let kernel waste mails less, and also can save my time resources. On 09/04/2013 04:59 AM, Guenter Roeck wrote: > On Tue, Sep 03, 2013 at 08:39:38PM +0100, Al Viro wrote: >> On Tue, Sep 03, 2013 at 11:52:17AM +0800, Chen Gang F T wrote: >> >>> extreme sample: let 'kernel code style' and 'gcc code style' in one file, >>> that will make the code very ugly. >> >> gcc style will make any code very ugly, no matter what (if anything) else is >> in the same file... >> Hmm... for me, I don't check/judge the 'coding style' of different products, what I focus on is to follow the original product 'coding style'. e.g. Windows, gcc, Linux kernel, their 'coding styles' are quite different with each other. Originally I worked under Windows, I followed Windows coding style. Now I worked under Linux kernel, I follow Linux kernel coding style. I plan to make patch for gcc, I will follow gcc coding style. (hope this month I can, but I am not sure, I have no experience for gcc development). And excuse me, I will be silent during 2013-09-05 - 2013-09-20 (but can response mail). During these days, I will focus on gcc issues (wish can fix one), and also do some company's internal things. Thanks. >> [digs out the ports history table] >> x86: 0.01[alive] >> i386: 0.01..2.6.24-rc1 [folded into x86] >> x86_64: 2.5.5-pre1..2.6.24-rc1 [folded into x86] >> x86:2.6.24-rc1 [alive] >> alpha: 1.1.67 [alive] >> sparc: 1.1.77 [alive] >> sparc64:2.1.19..2.6.28 [folded into sparc] >> mips:1.1.82 [alive] >> mips64: 2.3.48-pre2..2.6.0-test2 [folded into mips] >> powerpc: 1.3.45 [alive] >> ppc:1.3.45..2.6.26 [folded into powerpc] >> ppc64: 2.5.5..2.6.15-rc1 [folded into powerpc] >> powerpc:2.6.15-rc1 [alive] >> m68k:1.3.94 [alive] >> m68knommu: 2.5.46..2.6.38 [folded into m68k] >> arm: 2.1.80 [alive] >> arm26: 2.5.71..2.6.23-rc2 [gone] >> arm64: 3.7-rc1 [alive][might eventually fold] >> sh: 2.3.16 [alive] >> sh64: 2.6.8-rc1..2.6.24 [folded into sh, nearly dead there] >> ia64:2.3.43-pre1 [alive] >> s390:2.3.99pre8 [alive] >> s390x: 2.5.0..2.5.67 [folded into s390] >> parisc: 2.4.0-test12[alive] >> cris:2.5.0 [alive] >> um: 2.5.35 [alive] >> v850:2.5.46..2.6.26 [gone] >> h8300: 2.5.68 [moderately responsive] >> m32r:2.6.9-rc3 [alive] >> frv: 2.6.11-rc1 [alive] >> xtensa: 2.6.13-rc1 [alive] >> avr32: 2.6.19-rc1 [alive] >> blackfin:2.6.22-rc1 [alive] >> mn10300: 2.6.25-rc1 [alive] >> microblaze: 2.6.30-rc2 [alive] >> score: 2.6.32-rc1 [abandoned][cloned off mips] >> tile:2.6.36-rc1 [alive] >> unicore32: 2.6.39-rc1 [alive][cloned off arm] >> openrisc:3.1-rc1 [alive] >> hexagon: 3.2-rc1 [alive] >> c6x: 3.3-rc1 [alive] >> arc: 3.9-rc1 [alive] >> metag: 3.9-rc1 [alive] >> >> Frankly, I would've expected score and lefotvers of sh64 (aka sh5) to be >> the first against the wall - h8300 was a bit surprising... >> > > Great summary. > > There seemed to be a consensus to remove h8300, at least so far and > sufficiently > enough for me to ask Stephen to add the removal branch to linux-next. > We'll see if that triggers any further responses. > > With score, I am not entirely sure. I got one Ack for the removal, but > on the other side the score maintainers came back and claimed they would > still support it. We'll see if anything changes in practice. I am still > not sure if I should ask for the removal branch to be added to linux-next. > Frankly I thought I might jump the gun here more than with h8300. > > Either case, what to ultimately do with those two architectures will be > up to the community to decide. > > Guenter > Thanks again. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/8] Drop support for Renesas H8/300 architecture
On 09/03/2013 11:26 AM, Guenter Roeck wrote: > On 09/02/2013 07:53 PM, Chen Gang F T wrote: >> Hello Guenter Roeck: >> >> >> I don't care about whether I am in cc mailing list, but at least, >> please help confirm 2 things: >> >>Is what I had done for h8300 just making wastes and noisy in kernel and >> related sub-system mailing list ? >> >>and is the disccusion about h8300 between us also wastes and noisy in >> kernel mailing list ? >> > > It raised my awareness of the status of h8300 maintenance, > so I would not see it as noise or waste. I might have suggested > a different target for your efforts, but that is your choice to make, > not mine. > OK, thank you for your confirmation, I plan to scan all architectures one by one with allmodconfig. Hmm... if suitable, next, when I focus one of architectures, I also cc to you, if it can be removed, please let me know in time, so can avoid sending waste mails to mailing list. I plan to try one of architectures within arc, hexagon, and metag. I will begin at 2013-09-20 (or later), if some (or all) of them can be removed, please let me know, thanks. > On the code review side, I had suggested that you should not add new > ifdefs into code, much less unnecessary ones. Your counter-argument > was that you wanted to follow the existing coding style in the file > in question. To me, that argument is along the line of "the coding > style in this file is bad, let's do more of it". Hmm... in fact, I will not say whether the code style is good or bad. I mainly focus on to try to avoid multiple code styles within one file. extreme sample: let 'kernel code style' and 'gcc code style' in one file, that will make the code very ugly. > That doesn't make much sense to me, so I did not bother to respond. > Setting that aside, it is not up to me to approve or reject your patches. > Whoever does that would be the one you have to convince. > OK, I can understand, and now it seems it can be canceled, since h8300 has been removed. > Guenter > Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/8] Drop support for Renesas H8/300 architecture
Hello Guenter Roeck: I don't care about whether I am in cc mailing list, but at least, please help confirm 2 things: Is what I had done for h8300 just making wastes and noisy in kernel and related sub-system mailing list ? and is the disccusion about h8300 between us also wastes and noisy in kernel mailing list ? And also I have to make an apologize to kernel and other related sub system mailing list: some of patches about h8300 which I have sent in 2013-09-02 are really wastes (and I wasted my time resource for it, too). the excuse (not reason) is I do not know about Guenter Roeck has sent this patch (I am not in this cc list, so I find it one day delay). BTW: I also add some another related members in cc mailing list to let them know about some of suspending thread about h8300 (which waiting for allmodconfig finish) can be canceled. Thanks. On 08/31/2013 07:51 AM, Guenter Roeck wrote: > H8/300 has been dead for several years, the kernel for it has > not compiled for ages, and recent versions of gcc for it are broken. > It is time to drop support for it. > > Yes, I understand it is not that simple to drop an architecture, > and it may need some discussion, but someone has to put a stake > into the ground. Keeping a virtually dead architecture on life support > takes resources which are better spent elsewhere. > > v2: > - s/Renesys/Renesas/g > - Found and removed more architecture specific code in fs/minix > and in smc9194 driver > - Added explicit Cc: for h8300 maintainer > - Added subsystem maintainer Acks > > > Guenter Roeck (8): > Drop support for Renesas H8/300 (h8300) architecture > ide: Drop H8/300 driver > net/ethernet: smsc9194: Drop conditional code for H8/300 > net/ethernet: Drop H8/300 Ethernet driver > watchdog: Drop references to H8300 architecture > Drop MAINTAINERS entry for H8/300 > Drop remaining references to H8/300 architecture > fs/minix: Drop dependency on H8300 > > Documentation/scheduler/sched-arch.txt |5 - > MAINTAINERS |8 - > arch/h8300/Kconfig | 109 > arch/h8300/Kconfig.cpu | 171 -- > arch/h8300/Kconfig.debug | 68 --- > arch/h8300/Kconfig.ide | 44 -- > arch/h8300/Makefile | 71 --- > arch/h8300/README| 38 -- > arch/h8300/boot/Makefile | 22 - > arch/h8300/boot/compressed/Makefile | 37 -- > arch/h8300/boot/compressed/head.S| 47 -- > arch/h8300/boot/compressed/misc.c| 180 -- > arch/h8300/boot/compressed/vmlinux.lds | 32 - > arch/h8300/boot/compressed/vmlinux.scr |9 - > arch/h8300/defconfig | 42 -- > arch/h8300/include/asm/Kbuild|8 - > arch/h8300/include/asm/asm-offsets.h |1 - > arch/h8300/include/asm/atomic.h | 146 - > arch/h8300/include/asm/barrier.h | 29 - > arch/h8300/include/asm/bitops.h | 211 --- > arch/h8300/include/asm/bootinfo.h|2 - > arch/h8300/include/asm/bug.h | 12 - > arch/h8300/include/asm/bugs.h| 16 - > arch/h8300/include/asm/cache.h | 13 - > arch/h8300/include/asm/cachectl.h| 14 - > arch/h8300/include/asm/cacheflush.h | 40 -- > arch/h8300/include/asm/checksum.h| 102 > arch/h8300/include/asm/cmpxchg.h | 60 -- > arch/h8300/include/asm/cputime.h |6 - > arch/h8300/include/asm/current.h | 25 - > arch/h8300/include/asm/dbg.h |2 - > arch/h8300/include/asm/delay.h | 38 -- > arch/h8300/include/asm/device.h |7 - > arch/h8300/include/asm/div64.h |1 - > arch/h8300/include/asm/dma.h | 15 - > arch/h8300/include/asm/elf.h | 101 > arch/h8300/include/asm/emergency-restart.h |6 - > arch/h8300/include/asm/fb.h | 12 - > arch/h8300/include/asm/flat.h| 26 - > arch/h8300/include/asm/fpu.h |1 - > arch/h8300/include/asm/ftrace.h |1 - > arch/h8300/include/asm/futex.h |6 - > arch/h8300/include/asm/gpio-internal.h | 52 -- > arch/h8300/include/asm/hardirq.h | 19 - > arch/h8300/include/asm/hw_irq.h |1 - > arch/h8300/include/asm/io.h | 358 --- > arch/h8300/include/asm/irq.h | 49 -- > arch/h8300/in
Re: [PATCH] kernel/rcutree.c: deem to be lazy if there are no callbacks.
Firstly, thank you for your reply with these details. On 08/26/2013 03:18 AM, Paul E. McKenney wrote: > On Thu, Aug 22, 2013 at 11:01:53AM +0800, Chen Gang wrote: >> On 08/21/2013 10:23 PM, Paul E. McKenney wrote: >>> On Wed, Aug 21, 2013 at 01:59:29PM +0800, Chen Gang wrote: > > [ . . . ] > >>> Don't get me wrong, I do welcome appropriate patches. In fact, if >>> you look at RCU's git history, you will see that I frequently accept >>> patches from a fair number of people. And if you were willing to >>> invest some time and thought, you might eventually be able to generate >>> an appropriate (albeit low priority) patch to this function. However, >>> you seem to be motivated to submit small patches with a minimum of >>> thought and preparation, perhaps because you need to meet some external >>> or self-imposed quota of accepted patches. And if you are in fact driven >>> by a quota that prevents you from taking the time required to carefully >>> think things through, you are wasting your time with RCU. >> >> Hmm... at least, some contents you said above is correct to me. >> >> At least, I should provide 10 patches per month, it is a necessary >> basic requirement to me. > > OK, that does help explain the otherwise inexplicable approach you have > been taking. Let's see how you have been doing, based on committer date > in Linus's tree: > > 1 2012-11 > 15 2013-01 > 7 2013-02 > 20 2013-03 > 21 2013-04 > 12 2013-05 > 17 2013-06 > 10 2013-07 > > The last few months might be understated a bit due to patches > still being in maintainer trees. This is a nice contrast from my > first impression of you from https://lkml.org/lkml/2013/6/9/64 and > https://lkml.org/lkml/2013/8/19/650, neither of which gave me any > reason to trust your work, to put it mildly. And if I cannot trust > your work, I obviously cannot accept your patches. > Hmm... better to check patches independent personal feelings (trust some one, or not). ;-) > You do seem to select for localized bug fixes, which require less work > than the performance-motivated patches you were putting forward earlier > in this thread. With a localized bug, you demonstrate the bug, show the > fix, and that is that. From what I can see, part of the problem with > your patches in this email thread is that you are trying to move from > localized bug fixes to performance issues without doing the additional > work required. Please see below for a rough outline of this additional > work. > Hmm... it seems I need describe my work flow for fixing bugs in details. 1. Is it a bug ? if so, I can be marked as Reported-by and continue to 2nd. else, it is a waste mail. 2. Try to fix it in simple ways (so can save the maintainers time resource). if it can be accepted by maintainers, it is OK (I can be Signed-off-by). else need continue to 3rd. exception: if I can not find a simple way to fix it, I will send [Suggestion] mail. 3. Do the maintainers know how to fix it ? if yes, fix it together with maintainers (may mark me only as Reported-by). else need continue to Last. Last: I should analyze it and fix it (it is my duty to fix it). How do you feel about this work flow ? welcome any suggestions or completions. Thanks. >> And what my focus is efficiency: let appliers and maintainers together >> to provide contributes to outside with efficiency. > > Sounds great, but there are many possible definitions of "efficiency". > Given your quota, I would expect your definition to involve number of > patches accepted. In contrast, my definition for RCU instead involves > maintainability, robustness, scalability, and, for a few critical > code paths, performance. I therefore need you to have thought through > and carefully tested your patch. > Hmm... it seems I need give more description for the 'efficiency' which I point to. If it is no negative effect with the quality, we need try to use less resources (e.g. time resources) to provide more contributions (e.g. fix issue). >> If you already know about it, why need I continue ? but if you don't >> know either, I should try. > > What I need you to do in future RCU performance patch submissions is: > > 1.Think through your patch and the code that it is modifying. > If you submit a patch to me, you should be able to answer the > sorts of questions that I was asking in this thread. > > 2.Tell me what situations your patch helps and not. > > 3.Tell me how much your patch improves performance in the > situations where it helps. > > 4.Test the code. If it makes a measurable difference, present > the performance results. (It would be very surprising if your > early-loop exit patch made a significant difference, expecially > on a CONFIG_PREEMPT=n kernel.) > > 5.Rather than randomly dropping into the code, use actual measurements > to determine where to focus
Re: [PATCH 0/3] mm: mempolicy: the failure processing about mpol_to_str()
On 08/20/2013 04:09 PM, Chen Gang wrote:
> On 08/20/2013 03:51 PM, Chen Gang wrote:
>> On 08/20/2013 03:48 PM, Chen Gang wrote:
>>> On 08/20/2013 02:47 PM, Cyrill Gorcunov wrote:
On Tue, Aug 20, 2013 at 01:41:40PM +0800, Chen Gang wrote:
>
>> sure you'll have to change shmem_show_mpol statement to return int code.
>> Won't this be more short and convenient?
>>
>>
>
> Hmm... if return -ENOSPC, in common processing, it still need continue
> (but need let outside know about the string truncation).
>
> So I still suggest to give more check for it.
I still don't like adding additional code like
+ ret = mpol_to_str(buffer, sizeof(buffer), mpol);
+ if (ret < 0)
+ switch (ret) {
+ case -ENOSPC:
+ printk(KERN_WARNING
+ "in %s: string is truncated in
mpol_to_str().\n",
+ __func__);
>>
>> Oh, that need 'break' in my original patch. :-)
>>
+ default:
+ printk(KERN_ERR
+ "in %s: call mpol_to_str() fail, errcode:
%d. buffer: %p, size: %zu, pol: %p\n",
+ __func__, ret, buffer, sizeof(buffer),
mpol);
+ return;
+ }
this code is pretty neat for debugging purpose I think but in most case (if
only I've not missed something obvious) it simply won't be the case.
>>>
>>> For mpol_to_str(), it is for printing string, I suggest to fill buffer
>>> as full as possible like another printing string functions, -ENOSPC is
>>> not critical error, callers may can bear it, and still want to continue.
>>>
>>> For 2 callers, I still suggest to process '-ENOSPC' and continue, it is
>>> really not a critical error, they can continue.
>>>
>>> For the 'default' error processing:
>>>
>>> I still suggest to 'printk' in shmem_show_mpol(), because when failure
>>> occurs, it has no return value to mark the failure to upper caller.
>>> Hmm... but for show_numa_map(), may remove the 'printk', only return the
>>> error code is OK. :-)
>>>
>>>
>>> Thanks.
>>>
>
> Oh, for '-ENOSPC', it means critical error, it is my fault.
>
> So, for simplify thinking and implementation, use your patch below is OK
> to me (but I suggest to print error information in the none return value
> function).
>
> :-)
>
Won't somthing like below do the same but with smaller code change?
Note I've not even compiled it but it shows the idea.
---
fs/proc/task_mmu.c |4 +++-
mm/shmem.c | 17 +
2 files changed, 12 insertions(+), 9 deletions(-)
Index: linux-2.6.git/fs/proc/task_mmu.c
===
--- linux-2.6.git.orig/fs/proc/task_mmu.c
+++ linux-2.6.git/fs/proc/task_mmu.c
@@ -1402,8 +1402,10 @@ static int show_numa_map(struct seq_file
walk.mm = mm;
pol = get_vma_policy(task, vma, vma->vm_start);
- mpol_to_str(buffer, sizeof(buffer), pol);
+ n = mpol_to_str(buffer, sizeof(buffer), pol);
mpol_cond_put(pol);
+ if (n < 0)
+ return n;
seq_printf(m, "%08lx %s", vma->vm_start, buffer);
Index: linux-2.6.git/mm/shmem.c
===
--- linux-2.6.git.orig/mm/shmem.c
+++ linux-2.6.git/mm/shmem.c
@@ -883,16 +883,20 @@ redirty:
#ifdef CONFIG_NUMA
#ifdef CONFIG_TMPFS
-static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
+static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
{
char buffer[64];
+ int ret;
if (!mpol || mpol->mode == MPOL_DEFAULT)
- return; /* show nothing */
+ return 0; /* show nothing */
- mpol_to_str(buffer, sizeof(buffer), mpol);
+ ret = mpol_to_str(buffer, sizeof(buffer), mpol);
+ if (ret < 0)
+ return ret;
seq_printf(seq, ",mpol=%s", buffer);
+ return 0;
}
static struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
@@ -951,9 +955,7 @@ static struct page *shmem_alloc_page(gfp
}
#else /* !CONFIG_NUMA */
#ifdef CONFIG_TMPFS
-static inline void shmem_show_mpol(struct seq_file *seq, struct mempolicy
*mpol)
-{
-}
+static inline int shmem_show_mpol(struct seq_file *seq, struct mempolicy
*mpol) { return 0; }
#endif /* CONFIG_TMPFS */
static inline struct page *shmem_swapin(swp_entry_t swap, gfp_t gfp,
@@ -2577,8 +2579,7 @@ static int shmem_show_options(struct seq
if (!gid_eq(sbinfo->gid, GLOBAL_ROOT_GID))
seq_printf(seq, ",gid=%u",
Re: [PATCH] kernel/sysctl_binary.c: improve the usage of return value 'result'
On 08/07/2013 06:13 AM, Eric W. Biederman wrote:
> Andrew Morton writes:
>
>> On Tue, 06 Aug 2013 15:29:42 +0800 Chen Gang wrote:
>>
>>> Improve the usage of return value 'result', so not only can make code
>>> clearer to readers, but also can improve the performance.
>>
>> It used to be pervasive kernel style do to
>>
>> ret = -ENOMEM;
>> foo = alloc(...);
>> if (!foo)
>> goto out;
>>
>> whereas nowadays people usually do the more straightforward
>>
>> foo = alloc(...);
>> if (!foo) {
>> ret = -ENOMEM;
>> goto out;
>> }
>>
>> The thinking was that the old style generated better code, but for the
>> life of me I can't remember why :(
>
> Because doing the assignment outside of the if() goto . Allows the
> compiler to emit the if() goto as a single branch.
>
> While a smart compiler may perform the code motion across the branch,
> it is much easier for the compiler to branch to somewhere else perform
> the assignment and then branch out.
>
For my opinion, for assembly code, the old style is clearer than the new
style. And commonly, the old style will be faster than new style.
Thanks.
> Eric
>
>
>> Your patch switches from old-style to new-style. And it appears to
>> have increased the text size. I did this, to switch three sites back
>> to old-style:
>>
>> ---
>> a/kernel/sysctl_binary.c~kernel-sysctl_binaryc-improve-the-usage-of-return-value-result-fix
>> +++ a/kernel/sysctl_binary.c
>> @@ -941,17 +941,15 @@ static ssize_t bin_string(struct file *f
>> copied = result;
>> lastp = oldval + copied - 1;
>>
>> -if (get_user(ch, lastp)) {
>> -result = -EFAULT;
>> +result = -EFAULT;
>> +if (get_user(ch, lastp))
>> goto out;
>> -}
>>
>> /* Trim off the trailing newline */
>> if (ch == '\n') {
>> -if (put_user('\0', lastp)) {
>> -result = -EFAULT;
>> +result = -EFAULT;
>> +if (put_user('\0', lastp))
>> goto out;
>> -}
>> copied -= 1;
>> }
>> }
>> @@ -976,11 +974,10 @@ static ssize_t bin_intvec(struct file *f
>> char *buffer;
>> ssize_t result;
>>
>> +result = -ENOMEM;
>> buffer = kmalloc(BUFSZ, GFP_KERNEL);
>> -if (!buffer) {
>> -result = -ENOMEM;
>> +if (!buffer)
>> goto out;
>> -}
>>
>> if (oldval && oldlen) {
>> unsigned __user *vec = oldval;
>> _
>>
>> and kernel/sysctl_binary.o's .text got six bytes smaller.
>>
>> Now, smaller text doesn't mean faster code. But it probably means
>> larger cache footprint, which can mean slower code.
>>
>> IOW, it isn't obvious that this was an improvement.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: m68k: include: asm: define 'VM_DATA_DEFAULT_FLAGS' no matter whether has 'NOMMU' or not.
On 08/05/2013 09:37 AM, Greg Ungerer wrote: > Hi Chen Gang, > > On 01/07/13 12:43, Chen Gang wrote: >> Hello Maintainers: >> >> Please help check the patch whether OK or not, when you have time. >> >> Thanks. >> >> On 06/22/2013 02:49 PM, Chen Gang wrote: >>> >>> Define 'VM_DATA_DEFAULT_FLAGS' when 'NOMMU' to pass compiling. >>> >>> So move it from "include/asm/page_mm.h to "include/asm/page.h" >>> >>> The related make: >>> >>> make ARCH=m68k randconfig >>> make ARCH=m68k menuconfig >>> choose cross compiler >>> disable MMU support >>> make ARCH=m68k V=1 EXTRA_CFLAGS=-W >>> >>> The related error: >>> >>> security/selinux/hooks.c: In function ‘selinux_init’: >>> security/selinux/hooks.c:5821:21: error: ‘VM_DATA_DEFAULT_FLAGS’ >>> undeclared (first use in this function) >>> >>> (the attachment is the related .config file) >>> >>> >>> Signed-off-by: Chen Gang > > I am fine with this: > > Acked-by: Greg Ungerer > Thank you very much. > Do you want me to add this to the m68knommu git tree, and push to > Linus? > Yeah, thank you. :-) > Regards > Greg > > >>> --- >>> arch/m68k/include/asm/page.h|3 +++ >>> arch/m68k/include/asm/page_mm.h |3 --- >>> 2 files changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/arch/m68k/include/asm/page.h b/arch/m68k/include/asm/page.h >>> index 7c360da..38b024a 100644 >>> --- a/arch/m68k/include/asm/page.h >>> +++ b/arch/m68k/include/asm/page.h >>> @@ -48,6 +48,9 @@ extern unsigned long _ramend; >>> #include >>> #endif >>> >>> +#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \ >>> +VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) >>> + >>> #include >>> >>> #endif /* _M68K_PAGE_H */ >>> diff --git a/arch/m68k/include/asm/page_mm.h >>> b/arch/m68k/include/asm/page_mm.h >>> index 89f2014..5029f73 100644 >>> --- a/arch/m68k/include/asm/page_mm.h >>> +++ b/arch/m68k/include/asm/page_mm.h >>> @@ -173,7 +173,4 @@ static inline __attribute_const__ int >>> __virt_to_node_shift(void) >>> >>> #endif /* __ASSEMBLY__ */ >>> >>> -#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \ >>> -VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) >>> - >>> #endif /* _M68K_PAGE_MM_H */ >>> >> >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH trivial] include/linux/coda.h: remove useless '#else'
On 07/31/2013 09:53 AM, Chen Gang wrote:
> On 07/31/2013 09:44 AM, Chen Gang wrote:
>> On 07/30/2013 08:29 PM, Joe Perches wrote:
>>> On Tue, 2013-07-30 at 15:30 +0800, Chen Gang wrote:
'#else' is useless, need remove.
Signed-off-by: Chen Gang
---
include/linux/coda.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/linux/coda.h b/include/linux/coda.h
index cff544f..d30209b 100644
--- a/include/linux/coda.h
+++ b/include/linux/coda.h
@@ -60,7 +60,6 @@ Mellon the rights to redistribute these changes without
encumbrance.
#if defined(__linux__)
typedef unsigned long long u_quad_t;
-#else
#endif
#include
#endif
>>>
>>> Why have the #if at all?
>>>
>>>
>>>
>>
OH, sorry, what I said about openrisc cross-compiler is not precise.
Need a patch for openrisc (just like another architectures have done):
---diff begin---
diff --git a/arch/openrisc/Makefile b/arch/openrisc/Makefile
index 4739b83..89076a6 100644
--- a/arch/openrisc/Makefile
+++ b/arch/openrisc/Makefile
@@ -24,7 +24,7 @@ OBJCOPYFLAGS:= -O binary -R .note -R .comment -S
LDFLAGS_vmlinux :=
LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
-KBUILD_CFLAGS += -pipe -ffixed-r10
+KBUILD_CFLAGS += -pipe -ffixed-r10 -D__linux__
ifeq ($(CONFIG_OPENRISC_HAVE_INST_MUL),y)
KBUILD_CFLAGS += $(call cc-option,-mhard-mul)
---diff end-
But for "include/linux/coda.h", I still suggest to check __linux__
whether defined, at least it can find the building issues.
And next, I will send the related patch to openrisc mailing list.
:-)
Thanks.
>> Hmm... some old version compilers do not define __linux__ automatically
>> (e.g. or32-linux-gcc 4.5.1-or32-1.0rc1, which is the latest cross
>> compiler for openrisc, though).
>>
>> If not define __linux__, the compiler will report error (u_quad_t is
>> not defined).
>>
>> When we remove "#if defined(__linux__)" from "include/linux/coda.h",
>> the compiler will not report error, and 'cdev_t' will be defined as
>> 'dev_t', not 'u_quad_t' (I guess, it is an implicit bug).
>>
>>
>> In "uapi/include/*", only "coda.h" has "#if defined(__linux__)", maybe
>> they want multiple OS can share the same "coda.h" file (at least, we
>> can not say it is a bad idea).
>>
>> Neither suitable to define __linux__ in "include/linux/coda.h".
>>
>>
>> All together, I think:
>>
>> the direct cause:
>> "uapi/include/coda.h" wants to share itself for multiple OS (so they
>> need check __linux__).
>> (in "uapi/include/*", only coda.h need check __linux__)
>>
>> the root cause:
>> the compiler for linux should define __linux__ automatically, the latest
>> version of gcc has done, but some of the old version is not.
>> most of cross compilers have merged their code into gcc main tree, but
>> still left some (e.g. openrisc).
>> (at least, I can not build openrisc from gcc main tree correctly, but
>> most of others can)
>> some of latest cross compilers still use old version of gcc, (still not
>> define __linux__ automatically).
>>
>
> Maybe what I said is incorrect (it is just my current understanding).
>
> Welcome any other members' suggestions or completions for discussing and
> checking.
>
> Thanks.
>
>>
>> The related code in "uapi/linux/coda.h" is below:
>>
>> ---code begin---
>>
>> 73 #if defined(DJGPP) || defined(__CYGWIN32__)
>> 74 #ifdef KERNEL
>> 75 typedef unsigned long u_long;
>> 76 typedef unsigned int u_int;
>> 77 typedef unsigned short u_short;
>> 78 typedef u_long ino_t;
>> 79 typedef u_long dev_t;
>> 80 typedef void * caddr_t;
>> 81 #ifdef DOS
>> 82 typedef unsigned __int64 u_quad_t;
>> 83 #else
>> 84 typedef unsigned long long u_quad_t;
>> 85 #endif
>> 86
>> 87 #define inline
>> 88
>> 89 struct timespec {
>> 90 long ts_sec;
>> 91 long ts_nsec;
>> 92 };
>> 93 #else /* DJGPP but not KERNEL */
>> 94 #include
>> 95 typedef unsigned long long u_quad_t;
>> 96 #endif /* !KERNEL */
>> 97 #endif /* !DJGPP */
>> 98
>> 99
>> 100 #if defined(__linux__)
>> 101 #include
>> 102 #define cdev_t u_quad_t
>> 103 #ifndef __KERNEL__
>> 104 #if !defined(_UQUAD_T_) && (!defined(__GLIBC__) || __GLIBC__ < 2)
>> 105 #define _UQUAD_T_ 1
>> 106 typedef unsigned long long u_quad_t;
>> 107 #endif
>> 108 #endif /* __KERNEL__ */
>> 109 #else
>> 110 #define cdev_t dev_t
>> 111 #endif
>> 112
>>
>> ---code end-
>>
>>
>> Thanks.
>>
>
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
Re: [PATCH] kernel/params.c: print failure information instead of 'KOBJ_ADD' to user space, when sysfs_create_file() fails.
On 07/10/2013 10:35 AM, Chen Gang wrote:
> On 07/10/2013 10:17 AM, Chen Gang F T wrote:
>> On 07/09/2013 04:07 PM, Rusty Russell wrote:
>>> Chen Gang writes:
>>>> When sysfs_create_file() fails, recommend to print the related failure
>>>> information. And it is useless to still 'KOBJ_ADD' to user space.
>>>>
>>>> Signed-off-by: Chen Gang
>>>
>>> sysfs_create_file() should not fail during boot, should it?
>>>
>>
>> Hmm..., please reference locate_module_kobject() in "kernel/params.c",
>> which is an '__init' function, and also call sysfs_create_file(), it
>> processes the related error.
>>
>> So I recommend to get the check too in version_sysfs_builtin().
>>
>
> Oh, also for locate_module_kobject(), if !CONFIG_MODULES, when error
> occurs, it still print the information about "Adding module".
>
> Hmm..., do we need call kobject_get() before kobject_put() in failure
> processing block ?
>
Oh, sorry for what I said for kobject_get/put() items above, it is
incorrect.
What about the diff below for kobject_get() ?
---diff begin---
diff --git a/kernel/params.c b/kernel/params.c
index 440e65d..ef8d720 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -754,11 +754,11 @@ static struct module_kobject * __init
locate_module_kobject(const char *name)
name, err);
return NULL;
}
-
- /* So that we hold reference in both cases. */
- kobject_get(&mk->kobj);
}
+ /* So that we hold reference in both cases. */
+ kobject_get(&mk->kobj);
+
return mk;
}
---diff end-
And it also need add additional kobject_put(), if we really need
process the failure in version_sysfs_builtin().
Thanks.
>
> 740 mk = kzalloc(sizeof(struct module_kobject), GFP_KERNEL);
> 741 BUG_ON(!mk);
> 742
> 743 mk->mod = THIS_MODULE;
> 744 mk->kobj.kset = module_kset;
> 745 err = kobject_init_and_add(&mk->kobj, &module_ktype, NULL,
> 746"%s", name);
> 747 #ifdef CONFIG_MODULES
> 748 if (!err)
> 749 err = sysfs_create_file(&mk->kobj,
> &module_uevent.attr);
> 750 #endif
> 751 if (err) {
> 752 kobject_put(&mk->kobj);
> 753 pr_crit("Adding module '%s' to sysfs failed (%d),
> the system may be unstable.\n",
> 754 name, err);
> 755 return NULL;
> 756 }
> 757
> 758 /* So that we hold reference in both cases. */
> 759 kobject_get(&mk->kobj);
> 760 }
> 761
> 762 return mk;
> 763 }
>
>
>> Thanks.
>>
>>> Cheers,
>>> Rusty.
>>>
>>>> ---
>>>> kernel/params.c |8 +++-
>>>> 1 files changed, 7 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/kernel/params.c b/kernel/params.c
>>>> index 440e65d..f5299c1 100644
>>>> --- a/kernel/params.c
>>>> +++ b/kernel/params.c
>>>> @@ -845,7 +845,13 @@ static void __init version_sysfs_builtin(void)
>>>>mk = locate_module_kobject(vattr->module_name);
>>>>if (mk) {
>>>>err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
>>>> - kobject_uevent(&mk->kobj, KOBJ_ADD);
>>>> + if (err)
>>>> + printk(KERN_WARNING
>>>> + "%s (%d): sysfs_create_file fail for %s,
>>>> err: %d\n",
>>>> + __FILE__, __LINE__,
>>>> + vattr->module_name, err);
>>>> + else
>>>> + kobject_uevent(&mk->kobj, KOBJ_ADD);
>>>>kobject_put(&mk->kobj);
>>>>}
>>>>}
>>>> --
>>>> 1.7.7.6
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>
>>
>
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/params.c: print failure information instead of 'KOBJ_ADD' to user space, when sysfs_create_file() fails.
On 07/09/2013 04:07 PM, Rusty Russell wrote:
> Chen Gang writes:
>> When sysfs_create_file() fails, recommend to print the related failure
>> information. And it is useless to still 'KOBJ_ADD' to user space.
>>
>> Signed-off-by: Chen Gang
>
> sysfs_create_file() should not fail during boot, should it?
>
Hmm..., please reference locate_module_kobject() in "kernel/params.c",
which is an '__init' function, and also call sysfs_create_file(), it
processes the related error.
So I recommend to get the check too in version_sysfs_builtin().
Thanks.
> Cheers,
> Rusty.
>
>> ---
>> kernel/params.c |8 +++-
>> 1 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/kernel/params.c b/kernel/params.c
>> index 440e65d..f5299c1 100644
>> --- a/kernel/params.c
>> +++ b/kernel/params.c
>> @@ -845,7 +845,13 @@ static void __init version_sysfs_builtin(void)
>> mk = locate_module_kobject(vattr->module_name);
>> if (mk) {
>> err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
>> -kobject_uevent(&mk->kobj, KOBJ_ADD);
>> +if (err)
>> +printk(KERN_WARNING
>> + "%s (%d): sysfs_create_file fail for %s,
>> err: %d\n",
>> + __FILE__, __LINE__,
>> + vattr->module_name, err);
>> +else
>> +kobject_uevent(&mk->kobj, KOBJ_ADD);
>> kobject_put(&mk->kobj);
>> }
>> }
>> --
>> 1.7.7.6
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/smp.c: free related resources when failure occurs in hotplug_cfd()
On 07/08/2013 10:26 PM, Paul Gortmaker wrote: > [[PATCH] kernel/smp.c: free related resources when failure occurs in > hotplug_cfd()] On 08/07/2013 (Mon 16:50) Chen Gang wrote: > >> > When failure occurs in hotplug_cfd(), need release related resources, >> > or will cause memory leak. >> > >> > Also beautify the related code. > No. Please do not mix real fixes with trivial whitespace changes. > It makes it harder for the reviewer to find the actual fix, and it > makes the fix less portable to other releases (i.e. stable trees.) > OH, at least, need delete white spaces. > Also, you say "beautify", but that is a matter of opinion. You > shuffle around the tabs in your whitespace change, and yet even > then you don't manage to adapt it to the general coding style of > having multi-line args align with where the 1st arg starts. So > you have done nothing but pollute the "git blame" history of that > file for other users. > OK, I will send patch v2 for it (which will remove the waste 'beautifying' operation). > You might want to slow down on the quantity of patches you send, > and spend more time reading the comments from other people on > reviewed patches and learning some of the implicit requirements > from those. No, that only means I still need improving my patch sending. Hmm... for 'learning', I think: "learn with each other, never too old to learn, never stop learning", so we can learn from most of patches or replies which sent by many members. e.g. I understand that for beautifying code, I need more consideration: not only about coding style rules, but also the readers from 'git' and the reviewers from 'diff'. > I've noticed that you are already dangerously close > to annoying several key subsystem maintainers, and that is not > the right long term approach to working with the linux community. If no reply, I will(of cause) no reply either. Especially, every members' time resource is always expensive. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.
Firstly, thank you very much for your reply. On 07/05/2013 07:13 PM, Arnd Bergmann wrote: > On Friday 05 July 2013, Chen Gang F T wrote: >> > Hello All: >> > >> > It seems 'asm-generic' dislikes 'mad users' (e.g allmodconfig, >> > randconfig, and me). >> > >> > I guess the main reason is: 'asm-generic' thinks what mad users talk >> > about is useless in real world, so it is just noisy. >> > >> > I can understand, at least what I talk about is not for urgent things. >> > (maybe 'asm-generic' also thinks it not important either, every members >> > have their own opinions). >> > >> > Next, I still use allmodconfig/randconfig for some architectures which I >> > am interested in (and also for learning compilers), but I will skip all >> > things which are related with 'asm-generic', since it dislikes me (a mad >> > user). > As the asm-generic maintainer I think I have to clarify a few things: > > * Build-time fixes for warnings and randconfig errors are good, > and you have sent a number of good bug fixes all over the kernel, > I definitely welcome getting more of those. In many cases the > fix is trivial and obvious, in other cases you need to know > much more of the background to understand what the underlying > problem is and why you should not just fix the symptom. > Since we (at least my company) has already get benifits from Public Open Source, we should try to provide the contribution back to Public Open Source. Providing contributions to Public Open Source is part of my duty (what I should do). > * You have made an (understandable) mistake with this particular > patch. It would have been nice if you had not made it, but I > can see that you are still learning about these things. There > is a fine line between what makes sense to be enabled as a > 'compile test' and what should better be left disabled by > Kconfig. > We have to meet three roles: 'user', 'provider' and 'tester' (which is may mad user, and not quite familiar with the details). For 'user', they really need 'COMPILE_TEST', so it should be added into kernel wide. And 'user' often thinks the 'tester' is just a 'mad user' for 'tester' offten does "mad things" which will be useless in real world. For 'provider', he/she often feels the 'tester' is not familiar the details (in fact, they really not familiar), but he/she has to discuss with 'tester' (especially 'user' does not care about it). He/She really feels it is just boring and waste time. Instead of discussing the details, 'tester' should only provide the related proof and only can discus the related API, he/she wants the 'provider' to explain about the proof and make the API clearer to every one (not only for 'expert'). Now, I think, I may just play a 'tester' role for 'asm-generic'. > * When experienced developers tell you that you are mistaken, you > need to make an effort to understand what the mistake was so you > can learn from it and not make the same mistake again. If you > make the same mistakes again, maintainers will get annoyed and > ignore you (or worse), which is not a good situation to be > in when you want to get your patches merged. 'tester' wants the 'provider' to explain the proof: e.g. 'COMPILE_TEST' help contents whether really say: "can allow 'COMIPLE_TEST=y' in architectures which no related HW support" e.g. If compile fails because of no HW support with "COMPILE_TEST=y", can we still let it suspending ? e.g. Does it still count an issue, although in real world, it may not happen, at least now ? 'tester' also wants the 'provider' to explain 'asm-generic': Arnd said: "It's a set of examples for the architectures to look at and include if they want to" Steven saind: "The purpose of asm-generic is to add a standard infrastructure that some archs may be able to optimize." (In fact, they are not precisely the same). Did 'provider' have the related document for it (I guess so, could you provide the related location), thanks ? according to the definition of 'asm-generic' (either of them): the 'CONFIG_BUG' need really remove from 'asm-generic', for it is only related with some of architectures, not generic enough for all architectures (we can continue to discus it in the related thread). it belongs architectures wide, not kernel wide, is it better to move "./
Re: [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.
Hello All: It seems 'asm-generic' dislikes 'mad users' (e.g allmodconfig, randconfig, and me). I guess the main reason is: 'asm-generic' thinks what mad users talk about is useless in real world, so it is just noisy. I can understand, at least what I talk about is not for urgent things. (maybe 'asm-generic' also thinks it not important either, every members have their own opinions). Next, I still use allmodconfig/randconfig for some architectures which I am interested in (and also for learning compilers), but I will skip all things which are related with 'asm-generic', since it dislikes me (a mad user). At last, I make an apologize to 'asm-generic' for my mad discussing. Bye !! On 07/05/2013 08:48 AM, Chen Gang F T wrote: > On 07/05/2013 08:14 AM, Stephen Rothwell wrote: >> On Fri, 05 Jul 2013 08:03:31 +0800 Chen Gang F T >> wrote: >>>> >>>> When a module select "COMPILE_TEST=y" (e.g with allmodconfig), it has >>>> right to compile under the architecture which no related HW support. >>>> >>>> If it can not pass compiling, at least it is not the module's issue, >>>> neither the architecture's issue. >>>> >>>> We have to look for who has duty on it. At least now, it seems only >>>> 'asm-generic' can be qualified to play this unlucky role. >> You keep saying this, but others have told you that this is not the >> problem. >> > > In real world, it is not the problem. > > But for 'mad users' (e.g. allmodconfig, randconfig, and me too), they > have not provided enough reason for it (prove that is not a problem for > 'mad users'). > > >>>> Could you provide your suggestions or completions for this issue ? >> If something doesn't build for a particular config, then either it needs >> to be fixed or excluded from building in that particular config. > > I agree with you, if get rid of 'COMPILE_TEST'. > > Thanks. > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] include/asm-generic/iomap.h: trivial: use '__ASM_GENERIC_IOMAP_H' instead of '__GENERIC_IO_H'
Hello maintainers: Please help check this patch whether OK, when you have time. Thanks. On 06/28/2013 10:37 AM, Chen Gang wrote: > Recommend to let the header file macro mark match the file name. > > Signed-off-by: Chen Gang > --- > include/asm-generic/iomap.h |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h > index 6afd7d6..facfb39 100644 > --- a/include/asm-generic/iomap.h > +++ b/include/asm-generic/iomap.h > @@ -1,5 +1,5 @@ > -#ifndef __GENERIC_IO_H > -#define __GENERIC_IO_H > +#ifndef __ASM_GENERIC_IOMAP_H > +#define __ASM_GENERIC_IOMAP_H > > #include > #include > @@ -78,4 +78,4 @@ static inline void pci_iounmap(struct pci_dev *dev, void > __iomem *addr) > > #include > > -#endif > +#endif /* __ASM_GENERIC_IOMAP_H */ > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.
On 07/05/2013 08:12 AM, Greg KH wrote: > I'm done with this thread, it's madness.. Yeah, especially discussing with 'mad users' (e.g. allmodconfig, randconfig, and me too). ;-) Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.
On 07/05/2013 08:14 AM, Stephen Rothwell wrote: > On Fri, 05 Jul 2013 08:03:31 +0800 Chen Gang F T > wrote: >> > >> > When a module select "COMPILE_TEST=y" (e.g with allmodconfig), it has >> > right to compile under the architecture which no related HW support. >> > >> > If it can not pass compiling, at least it is not the module's issue, >> > neither the architecture's issue. >> > >> > We have to look for who has duty on it. At least now, it seems only >> > 'asm-generic' can be qualified to play this unlucky role. > You keep saying this, but others have told you that this is not the > problem. > In real world, it is not the problem. But for 'mad users' (e.g. allmodconfig, randconfig, and me too), they have not provided enough reason for it (prove that is not a problem for 'mad users'). >> > Could you provide your suggestions or completions for this issue ? > If something doesn't build for a particular config, then either it needs > to be fixed or excluded from building in that particular config. I agree with you, if get rid of 'COMPILE_TEST'. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.
On 07/04/2013 05:25 PM, Arnd Bergmann wrote:
> On Thursday 04 July 2013, Chen Gang wrote:
>
>> > --patch begin--
>> >
>> > 'asm-generic' need provide necessary configuration checking, if can't
>> > pass checking, 'asm-generic' shouldn't implement it.
>> >
>> > For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
>> > let it pass configuration checking, and provide related dummy contents
>> > for it.
>> >
>> > Part of 'COMPLE_TEST' help contents in "init/Kconfig":
>> >
>> > "...Despite they cannot be loaded there (or even when they load they
>> > cannot be used due to missing HW support)..."
>> >
>> > One sample for using 'COMPILE_TEST':
>> >
>> > 'PTP_1588_CLOCK_PCH' in drivers/ptp/Kconfig, which need depend on
>> > 'HAS_IOMEM'.
> Then please submit a patch that adds the 'depends on HAS_IOMEM' line there.
> That line was clearly left out by accident.
>
Yes, I will send the related patch for it (I have sent one, but that
seems incorrect, I will send patch v2 for that, after this patch
finishes discussing).
But excluding 'PTP_1588_CLOCK_PCH' own issue, it is as a sample for our
discussion (If "COMPILE_TEST=y", it should can be compiled under the
archs which no 'HAS_IOMEM').
>> > Signed-off-by: Chen Gang
>> > ---
>> > include/asm-generic/io.h | 22 ++
>> > 1 files changed, 18 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
>> > index d5afe96..301ce80 100644
>> > --- a/include/asm-generic/io.h
>> > +++ b/include/asm-generic/io.h
>> > @@ -303,13 +303,18 @@ static inline void *phys_to_virt(unsigned long
>> > address)
>> > /*
>> > * Change "struct page" to physical address.
>> > *
>> > - * This implementation is for the no-MMU case only... if you have an MMU
>> > - * you'll need to provide your own definitions.
>> > + * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
>> > + * if you have an MMU and IOMEM, you'll need to provide your own
>> > definitions.
>> > */
>> > -#ifndef CONFIG_MMU
>> > +#if !defined(CONFIG_MMU) || \
>> > + (!defined(CONFIG_HAS_IOMEM) && defined(CONFIG_COMPILE_TEST))
>> > static inline void __iomem *ioremap(phys_addr_t offset, unsigned long
>> > size)
>> > {
>> > +#if !defined(CONFIG_MMU)
>> >return (void __iomem*) (unsigned long)offset;
>> > +#else
>> > + return NULL;
>> > +#endif
>> > }
>> >
>> > #define __ioremap(offset, size, flags)ioremap(offset, size)
> This is wrong for multiple reasons, all of which have been discussed in
> this thread before.
Hmm..., COMPILE_TEST has integrated into 3.11 (at least can be found in
next tree).
When a module select "COMPILE_TEST=y" (e.g with allmodconfig), it has
right to compile under the architecture which no related HW support.
If it can not pass compiling, at least it is not the module's issue,
neither the architecture's issue.
We have to look for who has duty on it. At least now, it seems only
'asm-generic' can be qualified to play this unlucky role.
Could you provide your suggestions or completions for this issue ?
Thanks.
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.
On 07/04/2013 11:06 AM, Steven Rostedt wrote: > On Thu, 2013-07-04 at 10:42 +0800, Chen Gang F T wrote: > >> > Hmm..., I think maybe also has another way: get rid of 'COMPILE_TEST' >> > (regress the related patch, which is only existent in next-* tree). > I'm not working on linux-next at the moment. Hmm, I'm not even working > on mainline at the moment, the kernel I have is still 3.10-rc5. > OK, thanks. I can understand. Every contributors have their own focus areas, each area is valuable enough to go deeper and deeper. >> > >> > Or could you provide your suggestions or completions about it ? >> > >> > Thanks. >> > >>> > > I'm still confused by what you are trying to accomplish. >> > >> > Currently, I am trying to compile all architectures with allmodconfig in >> > next-* tree (which will have "COMPILE_TEST=y"). >> > >> > So I can find and solve the related issues (I am one of contributors). >> > > So, you want all archs to pass an allmodconfig? > Yeah, that is my current goal. By this way, I can find more issues and try to solve them (it will be good for public kernel), and also I can familiar the compiler step by step (the cross-compilers also has their issues). (In fact, I also want randconfig, and has already done for some architectures). ;-) > Well, one thing is, if a module doesn't build for an arch, then why not > keep that module from building for that arch. > Please see the related comment in "init/Kconfig" of next-* tree. config COMPILE_TEST bool "Compile also drivers which will not load" default n help Some drivers can be compiled on a different platform than they are intended to be run on. Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support), developers still, opposing to distributors, might want to build such drivers to compile-test them. If you are a developer and want to build everything available, say Y here. If you are a user/distributor, say N here to exclude useless drivers to be distributed. > If module foo.ko doesn't build for arch bazinga, then just add in the > Kconfig for the module foo: > > config FOO > depends on !BAZINGA > > Then that module wont build for the specific arch, and all are happy. If > someone someday wants to support module foo for arch bazinga, then they > can fix module foo for that arch. If get rid of 'COMPILE_TEST', what you said above are reasonable. When one module select "COMPILE_TEST=y", if it can not pass compiling because of HW not support, it is not the module's issue, at least. Hmm..., but at least for me, I still think, "COMPILE_TEST=y" is really useful. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.
On 07/04/2013 10:29 AM, Steven Rostedt wrote: > On Thu, 2013-07-04 at 10:10 +0800, Chen Gang F T wrote: > >> > Select "COMPILE_TEST=y" with allmodconfig, but can not pass compiling in >> > many architectures, one of the most reasons is "HW does not support". >> > >> > 'asm-generic' is really existent for a long time, and make an important >> > role for both architectures and modules. >> > > The purpose of asm-generic is to add a standard infrastructure that some > archs may be able to optimize. It's not so that all archs can compile > all modules. > Yes, I can understand. But at present, it seems only 'asm-generic' can play the unlucky role for current issues (at least, it is neither architectures issue nor modules issue). Hmm..., I think maybe also has another way: get rid of 'COMPILE_TEST' (regress the related patch, which is only existent in next-* tree). Or could you provide your suggestions or completions about it ? Thanks. > I'm still confused by what you are trying to accomplish. Currently, I am trying to compile all architectures with allmodconfig in next-* tree (which will have "COMPILE_TEST=y"). So I can find and solve the related issues (I am one of contributors). One of main issues is about it. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.
On 07/04/2013 09:23 AM, Steven Rostedt wrote: > On Wed, 2013-07-03 at 18:12 -0700, Greg KH wrote: > >> > confused, > Good. I thought I was the only one. Confusion loves company, that way we > can follow each other around in endless circles. If you think, this mail has already make noises to many other members, please reply mail next, which only contents the related members. And I will follow with the address which you provide. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.
On 07/04/2013 10:03 AM, Steven Rostedt wrote: > On Thu, 2013-07-04 at 09:49 +0800, Chen Gang wrote: > >> > Hmm... at least, it is neither architectures issue nor modules issue. >> > >> > So we have to look for who have duty for it, since it is a 'generic' >> > issue for many architectures and modules, we have to find it in >> > 'generic' area (e.g. "./include/*"). >> > >> > At least now, it seems only "asm-generic/*" can play the unlucky role !! >> > >> > Or, do you think it is still the modules issue themselves ? > What problem are you trying to solve? asm-generic has been around for a > long time, and so has allmodconfig. I'm unaware of any issues with > either of them. > Select "COMPILE_TEST=y" with allmodconfig, but can not pass compiling in many architectures, one of the most reasons is "HW does not support". 'asm-generic' is really existent for a long time, and make an important role for both architectures and modules. > But as my last email got blocked because your ISP thinks my ISP is a > spambot (it's road runner, which I'm sure there are spammers), you wont > get this anyway. Oh, sorry for not reply the original mail, and did not see in my backup mail, now, I can use my backup mail to continue. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
On 2013年04月26日 11:54, Mike Qiu wrote: > 于 2013/4/26 11:42, Chen Gang 写道: >> On 2013年04月26日 11:25, Chen Gang wrote: >>> On 2013年04月26日 11:08, Mike Qiu wrote: 于 2013/4/26 10:06, Chen Gang 写道: > On 2013年04月26日 10:03, Mike Qiu wrote: >> �� 2013/4/26 9:36, Chen Gang д��: On 2013��04��26�� 09:18, Chen Gang wrote: >> On 2013��04��26�� 09:06, Chen Gang wrote: >> CFAR is the Come From Register. It saves the location of the >> last branch and is hence overwritten by any branch. Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ? . = 0x900 .globl decrementer_pSeries decrementer_pSeries: HMT_MEDIUM_PPR_DISCARD SET_SCRATCH0(r13) b decrementer_pSeries_0 ... Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900. >> I will try your diff V2, to see if the machine can boot up > OK, thanks. (hope it can work) It seems that the machine can be bootup in powernv mode, but I'm not sure if my machine call that module. At lease my machine can boot up >> Please reference commit number: 1707dd161349e6c54170c88d94fed012e3d224e3 >> (1707dd1 powerpc: Save CFAR before branching in interrupt entry paths) >> >> What our diff v2 has done is just the fix for our patch v2 (just like >> the commit 1707dd1 has done). >> >> Please check, thanks. >> >> :-) > I will check this evening or tomorrow, I have something else to do this > afteroon. I think the diff v2 is correct, but is not the best one for this issue. I prefer the Paul's patch for this issue which has better performance :-) Thanks. -- Chen Gang Flying Transformer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM64: kernel: compiling issue: need define readq and writeq for driver module using.
On 2013年04月19日 20:13, Arnd Bergmann wrote: > On Friday 19 April 2013, Chen Gang wrote: >> > when compiling with allmodconfig, CONFIG_64BIT=y >> > the file drivers/base/regmap/regmap-mmio.c will use readq and writeq. >> > >> > so we need implement these functions. >> > >> > BTW: >> > the coding style can not pass ./scripts/checkpatch.pl. >> > it seems better to provide additional patch for beautifying code. >> > >> > Signed-off-by: Chen Gang > Acked-by: Arnd Bergmann thanks. -- Chen Gang Flying Transformer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] kernel: audit_tree: resource management: need put_tree and goto Err when failure occures
On 2013年04月18日 04:07, Andrew Morton wrote: > On Wed, 17 Apr 2013 12:04:02 +0800 Chen Gang wrote: > >> > since "normally audit_add_tree_rule() will free it on failure", >> > need free it completely, when failure occures. >> > >> > need additional put_tree before return, since get_tree was called. >> > always need goto error processing area for list_del_init. > Isn't that get_tree() in audit_add_tree_rule() simply unneeded? In > other words, is this patch correct: > excuse me: I am not quite familiar with it, and also have to do another things. so I have to spend additional time resource to make sure about it. is it ok ? I should make sure about it within this week (2013-04-21) I should finish related test (if need), within next week (2013-4-28) if have additional suggestions or completions, please reply. (if no reply, I will follow the time point above) thanks. gchen. > --- a/kernel/audit_tree.c~a > +++ a/kernel/audit_tree.c > @@ -682,7 +682,6 @@ int audit_add_tree_rule(struct audit_kru > goto Err; > } > > - get_tree(tree); > err = iterate_mounts(tag_mount, tree, mnt); > drop_collected_mounts(mnt); > > @@ -703,7 +702,6 @@ int audit_add_tree_rule(struct audit_kru > return -ENOENT; > } > rule->tree = tree; > - put_tree(tree); > > return 0; > Err: > _ > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Chen Gang Flying Transformer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: acct: kfree, also set related variable to NULL after kfree
On 2013年04月12日 22:29, Serge E. Hallyn wrote: > Quoting Chen Gang (gang.c...@asianux.com): >> > >> > after kfree acct, also set ns->bacct to NULL. >> > >> > Signed-off-by: Chen Gang > Acked-by: Serge Hallyn > thanks. -- Chen Gang Flying Transformer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: trace: ftrace: strncpy, using strlcpy instead of strncpy
On 2013年04月09日 23:00, Steven Rostedt wrote: > I'll queue this up for my 3.10 queue. I'm going to merge this patch with > the previous patch you sent that updates trace.c > > Thanks, > > -- Steve thanks too. -- Chen Gang Flying Transformer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux: printk is needed in filter.h when CONFIG_BPF_JIT is defined
On 2013年03月29日 02:31, David Miller wrote: > Please post networking patches to net...@vger.kernel.org, thanks. ok, thanks. it is my fault. originally, I get mail addresses by ./scripts/get_maintainers.pl it is a useful tool for members to get mail addresses. I should fully use it, but should not depend on it. next time I should think of the mail addresses, after get them from the tool. thanks. -- Chen Gang Flying Transformer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suggestion] drivers/block/aoe: using uninitialized variable.
On 2013年03月27日 22:04, Ed Cashin wrote: > Thanks. Jens Axboe said about it to Dan Carpenter that ... > >> > It was fixed up yesterday, it was a merge error in the for-next branch. thanks. :-) -- Chen Gang Flying Transformer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suggestion] PowerPC: kernel: cross compiling issue with allmodconfig
On 2013年03月23日 03:17, Yoder Stuart-B08248 wrote: > allmodconfig is creating config combinations that don't > happen in a normal build (at least currently)-- 64-bit build > that enables EPAPR_PARAVIRT but not PPC_BOOK3E_64. if it should not happen. can we add dependency to let it will never happen in any config combinations ? let allmodconfig can not create this config combinamtions: "64-bit build that enables EPAPR_PARAVIRT but not PPC_BOOK3E_64". thanks. -- Chen Gang Flying Transformer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suggestion] PowerPC: kernel: cross compiling issue with allmodconfig
it seems: only move slb_miss_realmode to the end, can fix this issue without negative effect. diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index 200afa5..56bd923 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -1066,78 +1066,6 @@ unrecov_user_slb: #endif /* __DISABLED__ */ -/* - * r13 points to the PACA, r9 contains the saved CR, - * r12 contain the saved SRR1, SRR0 is still ready for return - * r3 has the faulting address - * r9 - r13 are saved in paca->exslb. - * r3 is saved in paca->slb_r3 - * We assume we aren't going to take any exceptions during this procedure. - */ -_GLOBAL(slb_miss_realmode) - mflrr10 -#ifdef CONFIG_RELOCATABLE - mtctr r11 -#endif - - stw r9,PACA_EXSLB+EX_CCR(r13) /* save CR in exc. frame */ - std r10,PACA_EXSLB+EX_LR(r13) /* save LR */ - - bl .slb_allocate_realmode - - /* All done -- return from exception. */ - - ld r10,PACA_EXSLB+EX_LR(r13) - ld r3,PACA_EXSLB+EX_R3(r13) - lwz r9,PACA_EXSLB+EX_CCR(r13) /* get saved CR */ - - mtlrr10 - - andi. r10,r12,MSR_RI /* check for unrecoverable exception */ - beq-2f - -.machine push -.machine "power4" - mtcrf 0x80,r9 - mtcrf 0x01,r9 /* slb_allocate uses cr0 and cr7 */ -.machine pop - - RESTORE_PPR_PACA(PACA_EXSLB, r9) - ld r9,PACA_EXSLB+EX_R9(r13) - ld r10,PACA_EXSLB+EX_R10(r13) - ld r11,PACA_EXSLB+EX_R11(r13) - ld r12,PACA_EXSLB+EX_R12(r13) - ld r13,PACA_EXSLB+EX_R13(r13) - rfid - b . /* prevent speculative execution */ - -2: mfspr r11,SPRN_SRR0 - ld r10,PACAKBASE(r13) - LOAD_HANDLER(r10,unrecov_slb) - mtspr SPRN_SRR0,r10 - ld r10,PACAKMSR(r13) - mtspr SPRN_SRR1,r10 - rfid - b . - -unrecov_slb: - EXCEPTION_PROLOG_COMMON(0x4100, PACA_EXSLB) - DISABLE_INTS - bl .save_nvgprs -1: addir3,r1,STACK_FRAME_OVERHEAD - bl .unrecoverable_exception - b 1b - - -#ifdef CONFIG_PPC_970_NAP -power4_fixup_nap: - andcr9,r9,r10 - std r9,TI_LOCAL_FLAGS(r11) - ld r10,_LINK(r1) /* make idle task do the */ - std r10,_NIP(r1)/* equivalent of a blr */ - blr -#endif - .align 7 .globl alignment_common alignment_common: @@ -1336,6 +1264,78 @@ _GLOBAL(opal_mc_secondary_handler) /* + * r13 points to the PACA, r9 contains the saved CR, + * r12 contain the saved SRR1, SRR0 is still ready for return + * r3 has the faulting address + * r9 - r13 are saved in paca->exslb. + * r3 is saved in paca->slb_r3 + * We assume we aren't going to take any exceptions during this procedure. + */ +_GLOBAL(slb_miss_realmode) + mflrr10 +#ifdef CONFIG_RELOCATABLE + mtctr r11 +#endif + + stw r9,PACA_EXSLB+EX_CCR(r13) /* save CR in exc. frame */ + std r10,PACA_EXSLB+EX_LR(r13) /* save LR */ + + bl .slb_allocate_realmode + + /* All done -- return from exception. */ + + ld r10,PACA_EXSLB+EX_LR(r13) + ld r3,PACA_EXSLB+EX_R3(r13) + lwz r9,PACA_EXSLB+EX_CCR(r13) /* get saved CR */ + + mtlrr10 + + andi. r10,r12,MSR_RI /* check for unrecoverable exception */ + beq-2f + +.machine push +.machine "power4" + mtcrf 0x80,r9 + mtcrf 0x01,r9 /* slb_allocate uses cr0 and cr7 */ +.machine pop + + RESTORE_PPR_PACA(PACA_EXSLB, r9) + ld r9,PACA_EXSLB+EX_R9(r13) + ld r10,PACA_EXSLB+EX_R10(r13) + ld r11,PACA_EXSLB+EX_R11(r13) + ld r12,PACA_EXSLB+EX_R12(r13) + ld r13,PACA_EXSLB+EX_R13(r13) + rfid + b . /* prevent speculative execution */ + +2: mfspr r11,SPRN_SRR0 + ld r10,PACAKBASE(r13) + LOAD_HANDLER(r10,unrecov_slb) + mtspr SPRN_SRR0,r10 + ld r10,PACAKMSR(r13) + mtspr SPRN_SRR1,r10 + rfid + b . + +unrecov_slb: + EXCEPTION_PROLOG_COMMON(0x4100, PACA_EXSLB) + DISABLE_INTS + bl .save_nvgprs +1: addir3,r1,STACK_FRAME_OVERHEAD + bl .unrecoverable_exception + b 1b + + +#ifdef CONFIG_PPC_970_NAP +power4_fixup_nap: + andcr9,r9,r10 + std r9,TI_LOCAL_FLAGS(r11) + ld r10,_LINK(r1) /* make idle task do the */ + std r10,_NIP(r1)/* equivalent of a blr */ + blr +#endif + +/* * Hash table stuff */ .align 7 On 2013年03月21日 13:55, Chen Gang wrote: > Hello All: > > summary: > the root cause is no enough room in exception area (0x5500 -- 0x7000). > > it is caused by the patches "for saving/restre PPR"
Re: [Suggestion] Latest randconfig build errors for Head.S
On 2013年03月15日 19:29, Arnd Bergmann wrote: > On Friday 15 March 2013, Chen Gang F T wrote: >> > excuse me, my English is not quite well. >> > >> > I guess your meaning is: >> > "that bug" means the toolchain's bug (need toolchain people fix it). >> > prefer to apply your patch, before "that bug" is fixed (we don't know >> > when) >> > >> > is it correct ? > Yes, correct. thanks, and I support you. -- Chen Gang Flying Transformer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suggestion] Latest randconfig build errors for Head.S
于 2013年03月15日 18:56, Arnd Bergmann 写道: > Right. The fact that as prints a warning for those instructions makes sense > given that we are telling it we want to run on *all* ARM architectures, > and that ARMv8 has deprecated them officially. > > Of course, what is bogus about this is the "NULL" part rather than printing > the text that was meant to come out to explain the situation. I don't > know how to report that bug other than what I tried before, but if it gets > fixed by printing the right text, we will still want to build a kernel > without getting any warnings. excuse me, my English is not quite well. I guess your meaning is: "that bug" means the toolchain's bug (need toolchain people fix it). prefer to apply your patch, before "that bug" is fixed (we don't know when) is it correct ? thanks. -- Chen Gang Flying Transformer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Consult] Plan: personal contributes plan for 2013
Hello all: Opinion: after think of again, for "10 patches per month": I think in kernel wide, it is not quite hard to perform. Finished: currently (within Jan 2013) in next-20130125 tree, can find about 11 patches of mine. patch contents: usb, staging, tty sub-systems, ... patch type: 1 for MAINTAINER, 1 for beautify code, others for memory override or resource management. marked as: 9 for Signed-of-by, 2 for Reported-by (please use "git log", then search "Chen Gang" to get details) (also, I do it in part time in Jan 2013) Ways: for memory override: A) search strcpy, strncpy, sprintf, and memcpy in kernel wide B) we will get more than 10,000 lines (maybe almost 100,000 lines). C) then see each of them. in my experience (statistic): can find a bug per 10 lines. for resource management: A) at least, we can search 'kfree' in kernel wide B) we will get more than 10,000 lines (maybe almost 100,000 lines). C) then see each of them. in my experience (statistic): can find a bug per 100 lines. Hope: if most of my patches are qualified both for "Accept" and for "Quality" I hope to share this simple way to every one. so that, most of us can provide more valuable patches in this simple way. else (most of my patches are not qualified) please give reasons. if really they are, I should notice next time (also need adjust my plan) thanks -- Chen Gang Flying Transformer <>
Re: [char-misc-next V2] mei: drop the warning when cl is not initialized during unlinking
于 2013年01月14日 23:12, Greg KH 写道: > If you think you can do better than that, wonderful, I would love for > you to start out reviewing code and helping with handling stuff like > that. Please do so before complaining about anything. it seems, he is not complaining, maybe for him, he has to treat it as an urgent thing. and for every member, it is necessary to have a rest, so can keep our contributes (work) with efficiency and sustainable. so, please give more understanding with each other, so can make our cooperation better and better. by the way: maybe it is necessary to think of a backup working flow to process such kind of issues: "how to make the negative effect lowest, when important members have to have a necessary rest". -- Chen Gang Flying Transformer <>
Re: Why is the kfree() argument const?
于 2013年01月14日 01:41, Guenter Roeck 写道: > Maybe the confusion arises from the somewhat lax use of the term "const > pointer", and the csomewhat confusing way of defining variable attributes in > C. > Strictly speaking, > const char *name; > which is identical to > char const *name; > is not a const pointer, it is a pointer to a constant (string in this case). > A "const pointer", or "constant pointer to an object", would be > char * const name; Maybe. :-) -- Chen Gang Flying Transformer <>
Re: Why is the kfree() argument const?
于 2013年01月14日 04:54, Cong Ding 写道: > On Sun, Jan 13, 2013 at 9:10 AM, Chen Gang F T > wrote: >> > all together: >> > kfree() should use 'const void *' as parameter type >> > the free() of C Library is incorrect (it use void *). > you are definitely wrong. both of them are correct - it's the > difference between kernel space and user space. > for API features, they are should be no different. "- From a very obvious and very *real* caller perspective, 'free()' really doesn't change the thing the pointer points to. It does something totally different: it makes the *pointer* itself invalid." "we want the types to be as tight as possible" so should use 'const void *' both for 'kfree()' and 'free()' . -- Chen Gang Flying Transformer <>
Re: Why is the kfree() argument const?
Hello Antoine:
after read through the whole reply of Linus Torvalds for it
(the time stamp is "Wed, 16 Jan 2008 10:39:00 -0800 (PST)").
at least for me, his reply is correct in details.
although what you said is also correct,
it seems you misunderstanding what he said.
all together:
kfree() should use 'const void *' as parameter type
the free() of C Library is incorrect (it use void *).
于 2013年01月13日 03:18, antoine.t...@gmail.com 写道:
> On Wednesday, January 16, 2008 8:39:48 PM UTC+2, Linus Torvalds wrote:
>
>> "const" has *never* been about the thing not being modified. Forget all
>> that claptrap. C does not have such a notion.
>
> I beg your pardon?!
>
> C has had that very notion ever since its first standard (1989). Here is an
> excerpt from that standard (ISO/IEC 9899:1990, section 6.5.3):
>
> "If an attempt is made to modify an object defined with a const-qualified
> type through use of an lvalue with non-const-qualified type, the behavior is
> undefined."
>
>
>> "const" is a pointer type issue, and is meant to make certain mis-uses
>> more visible at compile time. It has *no* other meaning, and anybody who
>> thinks it has is just setting himself up for problems.
>
> 'const' is also a pointer issue, but not only - see above quote from the C
> Standard.
>
>
> Defining an object 'const' can have an impact on optimization (and also on
> whether the object is placed in read-only memory). Here are trivial examples
> to illustrate:
>
>
>
>
> void foo1(const int* pi)
> {
> *(int*)pi = 1;
> }
>
>
>
> #include
> void foo1(const int* pi);
> int main(void)
> {
> int i = 0;
> foo1(&i);
> printf("i = %d\n", i);
> return 0;
> }
>
>
>
>
> Program1 defines 'i' non-const, and modifies it through a const pointer, by
> casting const away in foo1(). This is allowed - although not necessarily wise.
>
> Program1 has well defined behavior: it prints "i = 1". The generated code
> dutifully retrieves the value of 'i' before passing it to printf().
>
>
>
>
>
> void foo2(const int* pi)
> {
> }
>
>
>
> #include
> void foo2(const int* pi);
> int main(void)
> {
> const int i = 0;
> foo2(&i);
> printf("i = %d\n", i);
> return 0;
> }
>
>
>
>
> Program2 defines 'i' const. A pointer to 'i' is passed to foo2(), which does
> not modify 'i'.
>
> Program2 has well defined behavior: it prints "i = 0". When it generates code
> for main1.c, the compiler can assume that 'i' is not modified, because 'i' is
> defined const.
>
> When compiling main2.c with gcc 4.4.7 with optimizations turned off (-O0),
> the generated code retrieves the value of 'i' before passing it to printf().
> With optimizations turned on (-O3), it inlines the value of 'i', 0, in the
> call to printf(). Both versions have the same, correct behavior.
>
>
>
>
>
> void foo3(const int* pi)
> {
> *(int*)pi = 1;
> }
>
>
>
> #include
> void foo3(const int* pi);
> int main(void)
> {
> const int i = 0;
> foo3(&i);
> printf("i = %d\n", i);
> return 0;
> }
>
>
>
>
> Program3 defines 'i' const, and attempts to modify it through a const
> pointer, by casting const away in foo3().
>
> On my particular system, when compiling Program3 with gcc 4.4.7 with
> optimizations turned off (-O0), the program prints "i = 1". With
> optimizations turned on (-O3), it prints "i = 0".
>
> The question of which of these two behaviors is "correct" would be pointless,
> since Program3 has undefined behavior.
>
>
> Antoine
> --
--
Chen Gang
Flying Transformer
<>
Re: [Consult] our latest kernel and latest Android under arm Samsung S5PV210 with yaffs2 file system
于 2013年01月08日 22:53, Theodore Ts'o 写道: firstly, thank you for your reply in details. :-) > yaffs2 is not a _standard_ file system for Android. There may be some > phones which use it, but the much more common is either FAT (for the > older phones) or ext4. The Google AOSP releases for pretty much all > modern Nexus phones (Galaxy Nexus and newer if I recall correctly, > certainly for GN, N4, N7, etc.) all use ext4. > for development, yaffs2 may be not a _standard_ file system for Android. but for marketing, it is realy used as a common file system. as far as I know: some of HTC phone use it. some embedded developement board use it. it is well known in embedded area (can find many documents about it) > > So if your existing Android device is using yaffs2, you'll need to > integrate yaffs2, since yaff2 is not in the upstream kernel. As far > as hardware support, it will depend on the specifics of your > development board, ... > thank you for your suggestions. I will integrate yaffs2 to my current using kernel. > ..., Others hopefully on this list will be able to answer it. > > welcome any members to reply, thanks. and additional consult: is it suitable to integrate yaffs2 into upstream kernel ? :-) thanks. -- Chen Gang Flying Transformer <>
[Consult] our latest kernel and latest Android under arm Samsung S5PV210 with yaffs2 file system
Hello all: Consult: whether the latest kernel can update the latest android OS ? it is android 4.0 (kernel-3.0.8) under arm Samsung S5PV210 with yaffs2 file system Background: development board: the core hardware is Samsung S5PV210 the extended vendor is FriendlyARM (a Chinese vendor) use yaffs2 file system for android it seems yaffs2 is a standard file system for android. for my android HTC phone is also yaffs2 file system. finished: for the android kernel its own can compile from the source code successfully. can update to the development board successfully. only need zImages, not need additional modules. can start android without any files under /system/lib/modules/* current: I am trying to use our latest kernel (such as next-20130104) can compile from the source code successfully. it has no source code for yaffs2 file system. not know whether can update the latest kernel. whether match the firmwares it already has files for firmwares in /system/etc/firmware/* do not know the public latest kernel whether can match them. whether need special image packing the vendor use additional tools for image packing: CONFIG_INITRAMFS_SOURCE="scripts/FriendlyARM.cpio" do not know the public latest kernel whether also need it. Choice: A) need choose another suitable branch of public kernel for it ? B) need additional configuration and download additional patches ? C) can not use latest public kernel to update latest android kernel ? D) none of choices above. welcome any members to providing suggestions or completions. thanks -- Chen Gang Flying Transformer <>
Re: how to look for source code in kernel
于 2012年12月28日 13:12, amit mehta 写道: On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote: > can anybody tell me how to look into source code, as most are hidden in > kernel. You can find the Linux source code at http://kernel.org/ . >> for browsing the code unfortunately there is no good tool as in windows we >> have source insight.We can use wine in linux but that sucks. > Funny you say that! > Never heard of cscope, ctags ? at least for me: vi (or vim) with another command line tools (grep, wc...) are enough. for reading or editing source code: grasp one editor is enough. I originally work under Windows OS using VC IDE and source insight for many years (at least 6 years). but I never feel they are better than vi, and neither less than vi. each editor has its own efficiency using ways, what we need do is to grasp it. when you grasp the editor (no matter what it is), it will be enough for you. > > -Amit > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Flying Transformer <>
Re: how to look for source code in kernel
于 2012年12月28日 13:12, amit mehta 写道: On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote: > can anybody tell me how to look into source code, as most are hidden in > kernel. You can find the Linux source code at http://kernel.org/ . >> for browsing the code unfortunately there is no good tool as in windows we >> have source insight.We can use wine in linux but that sucks. > Funny you say that! > Never heard of cscope, ctags ? at least for me: vi (or vim) with another command line tools (grep, wc...) are enough. for reading or editing source code: grasp one editor is enough. I originally work under Windows OS, using VC IDE and source insight for many years (at least 6 years). but I never feel they are better than vi, and neither less than vi. each editor has its own efficiency using ways, what we need do is to grasp it. when you grasp the editor (no matter what it is), it will be enough for you. > -Amit > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Flying Transformer <>
