[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt



Ben Hutchings dixit:

>-ccflags-y += -D'pr_fmt(fmt)=AUFS_NAME"\040%s:%d:%s[%d]:\040"fmt,__func__,__LINE__,current->comm,current->pid'
>+ccflags-y += -D'pr_fmt(fmt)="aufs\040%s:%d:%s[%d]:\040"fmt,__func__,__LINE__,current->comm,current->pid'

Sadly, this doesn’t work either:

  CC [M]  fs/aufs/module.o
In file included from /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/include/linux/hardirq.h:7:0,
                 from /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/arch/m68k/include/asm/irqflags.h:6,
                 from /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/include/linux/irqflags.h:15,
                 from /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/include/linux/spinlock.h:53,
                 from /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/include/linux/seqlock.h:29,
                 from /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/include/linux/time.h:8,
                 from /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/include/linux/stat.h:60,
                 from /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/include/linux/module.h:10,
                 from /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/fs/aufs/module.c:23:
/tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/arch/m68k/include/asm/hardirq.h: In function 'ack_bad_irq':
/tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/arch/m68k/include/asm/hardirq.h:23:2: error: dereferencing pointer to incomplete type
/tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/arch/m68k/include/asm/hardirq.h:23:2: error: dereferencing pointer to incomplete type
make[7]: *** [fs/aufs/module.o] Error 1

This one does work:
http://lists.debian.org/debian-kernel/2011/12/msg00474.html

The difference between a static inline function and a præprocessor
macro makes the difference. I know, now, why I never used the former
myself ☺ I guess “current” is not defined there.


sfjro@users.sourceforge.net dixit:

>I don't think the "current" macro will be a problem, but I want you to

It does. Also, read this:
http://people.netfilter.org/rusty/unreliable-guides/kernel-hacking/routines-current.html
“This global variable (really a macro) contains a pointer to the
current task structure, so is only valid in user context. For example,
when a process makes a system call, this will point to the task
structure of the calling process. It is not NULL in interrupt context.”

So I don’t know how safe it is to dereference 'current' in the inline
function ack_bad_irq (probably, not at all). On the other hand, the
ack_bad_irq function is probably not expanded in aufs3… so we could
go on. I can try a patch based on yours, but probably the best fix
would be to not use a static inline function in m68k.

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool.”
						-- Edward Burr


Reply to: