* zImage on mpc5200
From: sarpa @ 2007-06-26 15:11 UTC (permalink / raw)
To: linuxppc-embedded
I am building the Linux kernel target "zImage.elf" in PPC branch of Linux
Kernel 2.6.16.11 and then converting it to zImage.bin using OBJCOPY so that
i can flash it to my PPC based target using BDI. i am currently facing
issues in booting this kernel using my own bootloader(i am not using
u-boot). Before I flood mailing list with more detailed questions I just
wish to know if the standalone kernel image type zImage.elf is know to work
in Linux kernel 2.6.16.11 or not ? Has anyone ever tested standalone
zImage.elf on PPC ? Note that I am able to boot uImage using U-boot for this
kernel but now I am trying to use my own Bootloader to boot zImage.elf "
--
View this message in context: http://www.nabble.com/zImage-on-mpc5200-tf3982933.html#a11307459
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Who can help me with my NFS?
From: Linas Vepstas @ 2007-06-26 15:11 UTC (permalink / raw)
To: xu chen; +Cc: linuxppc-dev
In-Reply-To: <947266.20019.qm@web92009.mail.cnb.yahoo.com>
On Tue, Jun 26, 2007 at 01:59:33PM +0800, xu chen wrote:
> I ported my opb_ethernet driver to the ml403 board, with the reference system provided by Xilinx Co. Now I can ping the host with the board, and can also ping the board with PC. But I can't mount the NFS of my PC. The host configuration is correct, and the host can also be mounted by other PCs. Here is my tcpdump log when the board mount the PC's NFS, PC's IP: 192.168.1.107; board's IP: 192.168.1.134
Does telnet work? Can you ftp?
I had problems with nfs once when the device driver failed to compute the
checksum on the packets. This allowed some things to work, but not
others. Does tcp work, but udp is borken, or are tehy both broken?
--linas
^ permalink raw reply
* RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
From: Mohammad Sadegh Sadri @ 2007-06-26 14:53 UTC (permalink / raw)
To: eemingliu; +Cc: akonovalov, linuxppc-embedded
Dear Ming,
Thanks to your comments , Our tests now give the following results:
ML403--->PC : 410Mbits/s
PC--->ML403 : 210Mbits/s
We have described the characteristics of our base system in previous posts here
In additiona we have :
1- enabled the ppc caches
2- we have set BD_IN_BRAM in adapter.c to 1. ( default is 0 )
TX_THRESHOLD is 16 and RX_THRESHOLD is 2.
the virtex4 fx12 device on ML403 is now completely full, we do not have any free block memories nor any logic slices. Maybe if we had more space we could choose higher values for XTE_SEND_BD_CNT and XTE_RECV_BD_CNT i.e. 384. Do you think this will improve performance?
There is also another interesting test,
We executed netperf on both of PC and ML403 simultanously , when we do not put BDs in BRAM, the performance of ML403-->PC link drops from 390Mbits to 45Mbits, but when using PLB BRAMs for BDs the performance decreases from 410Mbits/s to just 130Mbita/s. It is important when the user wants to transfer data in both directions simulatanously.
Thanks
----------------------------------------
> From: eemingliu@hotmail.com
> To: mamsadegh@hotmail.com
> CC: akonovalov@ru.mvista.com; linuxppc-embedded@ozlabs.org
> Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> Date: Mon, 25 Jun 2007 10:03:30 +0000
>
> Dear Mohammad,
>
> >The results are as follows:
> >PC-->ML403
> >TCP_SENDFILE : 38Mbps
> >
> >ML403--->PC
> >TCP_SENDFILE: 155Mbps
>
> This result is unreasonable. Because PC is more powerful than your board,
> so PC->board should be faster than board->PC.
>
> >The transfer rate from ML403 to PC has improved by a factor of 2,
> >I see on the posts here in the mailing list that you have reached a band
> width of 301Mbps.
>
> Yes, with all features which could improve performance enabled, we can get
> around 300Mbps for TCP transfer. one more hint, did you enable caches on
> your system? perhaps it will help. Anyway, double check your hardware
> design to make sure all features are enabled.That's all I can suggest.
>
> BR
> Ming
>
>
> >
> >
> >
> >
> >----------------------------------------
> > > From: eemingliu@hotmail.com
> > > To: mamsadegh@hotmail.com; akonovalov@ru.mvista.com;
> linuxppc-embedded@ozlabs.org; grant.likely@secretlab.ca
> > > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > Date: Sat, 23 Jun 2007 19:10:16 +0000
> > >
> > > Use the following command in Linux please:
> > >
> > > ifconfig eth0 mtu 8982
> > >
> > > As well you should do that on your PC in the measurement.
> > >
> > > Ming
> > >
> > >
> > > >From: Mohammad Sadegh Sadri
> > > >To: Ming Liu ,
> > > ,,
> > >
> > > >Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > >Date: Sat, 23 Jun 2007 19:08:29 +0000
> > > >
> > > >
> > > >Dear Ming,
> > > >
> > > >Really thanks for reply,
> > > >
> > > >about thresholds and waitbound OK! I'll adjust them in adapter.c ,
> > > >
> > > >but what about enabling jumbo frames? should I do any thing special to
> > > enable Jumbo fram support?
> > > >
> > > >we were thinking that it is enabled by default. Is it?
> > > >
> > > >thanks
> > > >
> > > >
> > > >
> > > >
> > > >----------------------------------------
> > > > > From: eemingliu@hotmail.com
> > > > > To: mamsadegh@hotmail.com; akonovalov@ru.mvista.com;
> > > linuxppc-embedded@ozlabs.org; grant.likely@secretlab.ca
> > > > > Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > > Date: Sat, 23 Jun 2007 18:48:19 +0000
> > > > >
> > > > > Dear Mohammad,
> > > > > There are some parameters which could be adjusted to improve the
> > > > > performance. They are: TX and RX_Threshold TX and RX_waitbound. In
> my
> > > > > system, we use TX_Threshold=16 and Rx_Threshold=8 and both
> waitbound=1.
> > > > >
> > > > > Also Jumbo frame of 8982 could be enable.
> > > > >
> > > > > Try those hints and share your improvement with us.
> > > > >
> > > > > BR
> > > > > Ming
> > > > >
> > > > > >From: Mohammad Sadegh Sadri
> > > > > >To: Andrei Konovalov , Linux PPC Linux
> > > > > PPC, Grant Likely
> > > > > >Subject: ML403 gigabit ethernet bandwidth - 2.6 kernel
> > > > > >Date: Sat, 23 Jun 2007 12:19:12 +0000
> > > > > >
> > > > > >
> > > > > >Dear all,
> > > > > >
> > > > > >Recently we did a set of tests on performance of virtex 4FX hard
> TEMAC
> > > > > module using ML403
> > > > > >
> > > > > >we studied all of the posts here carefully: these are the system
> > > > > characteristics;
> > > > > >
> > > > > >Board : ML403
> > > > > >EDK : EDK9.1SP2
> > > > > >Hard TEMAC version and PLTEMAC version are both 3.0.a
> > > > > >PPC clock frequency : 300MHz
> > > > > >Kernel : 2.6.21-rc7 , downloaded from grant's git tree some thing
> near
> > > one
> > > > > week ago
> > > > > >DMA type: 3 (sg dma)
> > > > > >DRE : enabled for TX and RX, (2)
> > > > > >CSUM offload is enabled for both of TX and RX
> > > > > >tx and rx fifo sizes : 131072 bits
> > > > > >
> > > > > >the board comes up over NFS root file system completely and
> without
> > > any
> > > > > problems.
> > > > > >
> > > > > >PC system used for these tests is : CPU P4 Dual Core, 3.4GHz ,
> > > 2Gigabytes
> > > > > memory, Dual gigabit ethernet port, running linux 2.6.21.3
> > > > > >We have tested the PC system band width and it can easily reach
> > > 966mbits/s
> > > > > when connected to the same PC. ( using the same cross cable used
> for
> > > ml403
> > > > > test)
> > > > > >
> > > > > >Netperf is compiled with TCP SEND FILE enabled, ( -DHAVE_SENDFILE)
> > > > > >
> > > > > >(from board to PC)
> > > > > >netperf -t TCP_SENDFILE -H 10.10.10.250 -F /boot/zImage.elf -- -m
> > > 16384 -s
> > > > > 87380 -S 87380
> > > > > >
> > > > > >the measured bandwidth for this test was just 40.66Mbits.
> > > > > >It is also true for netperf from PC to board.
> > > > > >
> > > > > >we do not have any more idea about what we should do to improve
> the
> > > > > bandwidth.
> > > > > >any help or ideas is appreciated...
> > > > > >
> > > > > >_________________________________________________________________
> > > > > >Connect to the next generation of MSN
> > > > >
> > >
> Messenger?>http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
>
> > >
> > > > >
> > > > > >_______________________________________________
> > > > > >Linuxppc-embedded mailing list
> > > > > >Linuxppc-embedded@ozlabs.org
> > > > > >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > > > >
> > > > > _________________________________________________________________
> > > > > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> > > > >
> > > >
> > > >_________________________________________________________________
> > > >News, entertainment and everything you care about at Live.com. Get it
> now!
> > > >http://www.live.com/getstarted.aspx
> > >
> > > _________________________________________________________________
> > > 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
> > >
> >
> >_________________________________________________________________
> >Discover the new Windows Vista
> >http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
>
> _________________________________________________________________
> 免费下载 MSN Explorer: http://explorer.msn.com/lccn/
>
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
^ permalink raw reply
* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Josh Boyer @ 2007-06-26 13:57 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <1ce7f225511ea3d67a63b8a4ac683e0c@kernel.crashing.org>
On Tue, 2007-06-26 at 15:46 +0200, Segher Boessenkool wrote:
> >>> But I meant adding
> >>> something in the Documentation/powerpc/ directory and maybe
> >>> feature-removal-schedule.txt. Basically a written down thing in the
> >>> kernel source to refer people to.
> >>
> >> How about this time next year -- special event at
> >> the OLS PowerPC BOF :-)
> >
> > Heh, sounds good to me.
> >
> > Of course, getting stuff done in a year.... ;)
>
> Well the arch/ppc tree is basically frozen already, all Freescale
Actually, that's the part I wanted to document. Not the actual removal
(or maybe in addition to anyway). So far, we've just been saying
"basically frozen", "I think we stopped taking new submissions", etc.
If that's the case, just officially declare it frozen somehow in the
kernel source.
Of course, that would mean Paul needs to officially say that with the
big maintainer stamp :).
josh
^ permalink raw reply
* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Segher Boessenkool @ 2007-06-26 13:46 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1182864764.19501.7.camel@weaponx.rchland.ibm.com>
>>> But I meant adding
>>> something in the Documentation/powerpc/ directory and maybe
>>> feature-removal-schedule.txt. Basically a written down thing in the
>>> kernel source to refer people to.
>>
>> How about this time next year -- special event at
>> the OLS PowerPC BOF :-)
>
> Heh, sounds good to me.
>
> Of course, getting stuff done in a year.... ;)
Well the arch/ppc tree is basically frozen already, all Freescale
stuff got moved over already as far as I can see, and 4xx has
started moving. I think a year is enough, since the tree is
frozen anyway, people can resurrect stuff from older releases
if need be, no problem with deleting it. In fact, why not do
so this year :-) [Yeah that was a joke].
Segher
^ permalink raw reply
* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Josh Boyer @ 2007-06-26 13:32 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <b75c4d9610522f1a45ed1e65c9a4a548@kernel.crashing.org>
On Tue, 2007-06-26 at 09:48 +0200, Segher Boessenkool wrote:
> > But I meant adding
> > something in the Documentation/powerpc/ directory and maybe
> > feature-removal-schedule.txt. Basically a written down thing in the
> > kernel source to refer people to.
>
> How about this time next year -- special event at
> the OLS PowerPC BOF :-)
Heh, sounds good to me.
Of course, getting stuff done in a year.... ;)
josh
^ permalink raw reply
* RE: Follow up on 4 Gig of DDR on MPC8548E
From: Morrison, Tom @ 2007-06-26 11:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, ltib, linuxppc-embedded
In-Reply-To: <1182814323.5521.143.camel@localhost.localdomain>
>> apparently after more investigations - it looks like there is =
something in the ext2 driver code
>> that is mal-adjusted....I haven't talked to the guy today who was =
looking at that - but the ext2
>> driver code that was openning a 'virtual file' / console - had some =
problems mapping that
>> space - again, my gut is telling me more stronger there is a problem =
with signed/unsigned...
>> now deeper in the ext2 code...
> I very much doubt there is a signed/unsigned issue in ext2 or =
elsewhere...
>
> You have CONFIG_HIGHMEM ? What are your setting for KERNELBASE and =
PAGE_OFFSET ?
Ben,
=20
I am sorry it I alluded to ext2 code itself having a signed/unsigned =
problem -=20
just that the problem was manifesting itself inside the ext2 code in a =
very=20
strange way ...with something that I guessed below it that was violating =
a signed/unsigned API....
=20
and I was wrong with this hunch (gotta check my hunch meter)...
It was a nuance in the configuration of inbound windows for PCI/PEX=20
that was dribbling onto the memory that was consistently being i/o =
mapped
to the ext2 driver - which then got confused and bailed completely.
=20
We now have it working as we want it to with all 4 GIG of=20
DDR working as we want it.
=20
Thank you for pushing us to push through the hunch and get to the=20
root cause. It was a tough one to find.
=20
Tom
=20
^ permalink raw reply
* booting linux-2.6.15 hang on custom mpc8555 board
From: huangyun @ 2007-06-26 10:33 UTC (permalink / raw)
To: linuxppc-embedded
hi,everyone
I have porting linux2.6.15 of eldk4.0 to my mpc8555 board, my bootloader
is u-boot1.1.6, the uboot running is ok,but it hang at booting kernel.no
any print message.
I have check the CCSRBAR(0xe0000000) and bd_t struct is the same as linux
kernel, my serial port use uart1. somebody help me! i'm a linux kernel
newer.
there is some booting information:
CPU: 8555, Version: 1.1, (0x80790011)
Core: E500, Version: 2.0, (0x80200020)
Clock Configuration:
CPU: 660 MHz, CCB: 330
DDR: 165 MHz, LBC: 82 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: IP
PCI1: 32 bit, 66 MHz (compiled)
I2C: ready
DRAM: Initializing
DDR: 256 MB
before relocate_code
FLASH:
the first flash SST39VF040 size: 512 KB
the second flash MX29LV640MBTC size: 8 MB
the third flash MX29LV640MBTC size: 8 MB
Total Flash capacity: 16.5 MB
L2 cache 256KB: enabled
*** Warning - bad CRC, using default environment
leave the env
enter into getenv
leave getenv
In: serial
Out: serial
Err: serial
Net:
TSEC0, TSEC1
Hit any key to stop autoboot: 0
Waiting for PHY auto negotiation to complete. done
Speed: 1000, full duplex
Using TSEC0 device
TFTP from server 192.168.96.110; our IP address is 192.168.96.168
Filename 'uImage'.
Load address: 0x1000000
Loading: #################################################################
#################################################################
#################################################################
##################
done
Bytes transferred = 1088988 (109ddc hex)
## Booting image at 01000000 ...
Image Name: Linux-2.6.15
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1088924 Bytes = 1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ...OK
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-06-26 10:08 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get two more bug fixes for powerpc, plus defconfig updates.
Thanks,
Paul.
arch/powerpc/configs/cell_defconfig | 243 ++++++---------
arch/powerpc/configs/celleb_defconfig | 169 +++-------
arch/powerpc/configs/chrp32_defconfig | 353 +++++++++++++--------
arch/powerpc/configs/ebony_defconfig | 138 +++-----
arch/powerpc/configs/g5_defconfig | 342 +++++++++++----------
arch/powerpc/configs/holly_defconfig | 125 ++------
arch/powerpc/configs/iseries_defconfig | 36 --
arch/powerpc/configs/linkstation_defconfig | 384 ++++++++++-------------
arch/powerpc/configs/lite5200_defconfig | 182 +++++------
arch/powerpc/configs/maple_defconfig | 248 +++++++--------
arch/powerpc/configs/pasemi_defconfig | 58 ----
arch/powerpc/configs/pmac32_defconfig | 375 +++++++++++------------
arch/powerpc/configs/ppc64_defconfig | 460 +++++++++++++++++-----------
arch/powerpc/configs/prpmc2800_defconfig | 98 +-----
arch/powerpc/configs/ps3_defconfig | 79 +----
arch/powerpc/configs/pseries_defconfig | 387 ++++++++++++++----------
arch/powerpc/kernel/signal_64.c | 10 -
arch/powerpc/kernel/vdso32/gettimeofday.S | 4
arch/powerpc/kernel/vdso64/gettimeofday.S | 7
19 files changed, 1748 insertions(+), 1950 deletions(-)
commit ae62fbb5f1f796d87cbdbe6701e13f2b52d5c0a7
Author: Paul Mackerras <paulus@samba.org>
Date: Tue Jun 26 14:49:11 2007 +1000
[POWERPC] Fix subtle FP state corruption bug in signal return on SMP
This fixes a bug which can cause corruption of the floating-point state
on return from a signal handler. If we have a signal handler that has
used the floating-point registers, and it happens to context-switch to
another task while copying the interrupted floating-point state from the
user stack into the thread struct (e.g. because of a page fault, or
because it gets preempted), the context switch code will think that the
FP registers contain valid FP state that needs to be copied into the
thread_struct, and will thus overwrite the values that the signal return
code has put into the thread_struct.
This can occur because we clear the MSR bits that indicate the presence
of valid FP state after copying the state into the thread_struct. To fix
this we just move the clearing of the MSR bits to before the copy. A
similar potential problem also occurs with the Altivec state, and this
fixes that in the same way.
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 74609f4536f2b8fd6a48381bbbe3cd37da20a527
Author: Tony Breeds <tony@bakeyournoodle.com>
Date: Tue Jun 26 09:50:32 2007 +1000
[POWERPC] Fix VDSO gettimeofday() when called with NULL struct timeval
Consider the prototype for gettimeofday():
int gettimofday(struct timeval *tv, struct timezone *tz);
Although it is valid to call with /either/ tv or tz being NULL, and
the C version of sys_gettimeofday() supports this, the current version
of gettimeofday() in the VDSO will SEGV if called with a NULL tv.
This adds a check for tv being NULL so that it doesn't SEGV.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit ca74c013441200b162f6a384b23b833d1865a9e8
Author: Paul Mackerras <paulus@samba.org>
Date: Tue Jun 26 14:19:35 2007 +1000
[POWERPC] Update defconfigs
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit d30d6badd1769a00bc5a800b8af4e8b3f169c633
Author: will schmidt <will_schmidt@vnet.ibm.com>
Date: Sat Jun 23 01:24:56 2007 +1000
[POWERPC] Update g5_defconfig
Update the g5_defconfig with default settings.
This is to keep things up to date, and specifically to ensure that the
CONFIG_MACINTOSH_DRIVERS option is enabled. This also turns on
CONFIG_MSI.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
cc: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* reboot command in linux is not working
From: Nethra @ 2007-06-26 8:19 UTC (permalink / raw)
To: linuxppc-dev
hi,
I m using MPC8272ADS board , u-boot-1.1.6 and linux is 2.6.10 (montavista).
reboot command is not working...what may be the problem?
this is the output i m getting after giving reboot command....
root@cashel:~#
root@cashel:~#
root@cashel:~#
root@cashel:~# reboot
Broadcast message from root (console) (Thu Jan 1 00:00:46 1970):
The system is going down for reboot NOW!
INIT: Switching to runlevel: 6
INIT: Sending processes the TERM signal
INIT: Sending processes the KILL signal
Stopping MontaVista target tools daemon: mvltd. Stopping internet
superserver: inetd.
Stopping NFS common utilities: lockd statd.
Stopping portmap daemon: portmap.
Stopping hotplug subsystem:
pci
pci [success]
usb
usb [success]
isapnp
isapnp [success]
ide
ide [success]
input
input [success]
scsi
scsi [success]
done.
Stopping system log daemon: klogd syslogd.
Unmounting /dev...done.
Sending all processes the TERM signal... done.
Sending all processes the KILL signal... done.
Unmounting remote filesystems... done.
Deactivating swap...done.
Unmounting local filesystems...done.
Starting reboot command: reboot
Rebooting...
Restarting system.teMachine check in kernel mode.
Caused by (from SRR1=41000): Transfer error ack signal
Oops: machine check, sig: 7 [#1]
PREEMPT
NIP: FF000104 LR: FF000104 SP: C315DE00 REGS: c315dd50 TRAP: 0200 Not
tainted
MSR: 00041000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK = c37560f0[1035] 'reboot' THREAD: c315c000
Last syscall: 54
GPR00: 00001032 C315DE00 C37560F0 00249CA0 FF000104 00001002 0000349C
EFFFFFFF
GPR08: C021E133 C000E7A8 0000C000 00100088 00000001 1001A108 100D4FF8
100C9368
GPR16: FFFFFFFF 00000000 00000000 00000000 00000000 00000001 00000001
00000001
GPR24: 00000000 00000001 00000000 00000000 00000000 00000004 00000000
FF000104
Call trace: [00001032]
thanks in advance,
Nethra
--
View this message in context: http://www.nabble.com/reboot-command-in-linux-is-not-working-tf3981084.html#a11301692
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v2] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Segher Boessenkool @ 2007-06-26 7:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <1182822947.5521.145.camel@localhost.localdomain>
>> Updated to include feedback from Ben and Segher, also reposition the
>> compare in the 64bit VDSO to catch all the references to tv.
>>
>> From: Tony Breeds <tony@bakeyournoodle.com>
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Yep fine, thanks Tony.
Segher
^ permalink raw reply
* Re: [PATCH 3/3] Make jprobes a little safer for users
From: Abhishek Sagar @ 2007-06-26 7:54 UTC (permalink / raw)
To: michael
Cc: linux-arch, Andrew Morton, linux-ia64, linux-kernel,
anil.s.keshavamurthy, linuxppc-dev, Christoph Hellwig
In-Reply-To: <1182839683.6673.22.camel@concordia.ozlabs.ibm.com>
On 6/26/07, Michael Ellerman <michael@ellerman.id.au> wrote:
> It did occur to me that someone might be doing something crazy like
> branching to code that's not in the kernel/module text - but I was
> hoping that wouldn't be the case. I'm not sure what ITCM is?
The reference to tightly coupled memory (ITCM) was just to have you
consider the possibility of the jprobe handler being outside kernel
text region. Totally paranoid really.
> > > int __kprobes register_jprobe(struct jprobe *jp)
> > > {
> > > + unsigned long addr = arch_deref_entry_point(jp->entry);
> > > +
> > > + if (!kernel_text_address(addr))
> > > + return -EINVAL;
> >
> > Seems like you're checking for the jprobe handler to be within
> > kernel/module range. Why not narrow this down to just module range
> > (!module_text_address(addr), say)? Core kernel functions would not be
> > ending with a 'jprobe_return()' anyway.
>
> There's jprobe code in net/ipv4/tcp_probe.c and net/dccp/probe.c that
> can be builtin or modular, so I think kernel_text_address() is right.
Ok..thanks for that clarification.
--
Abhishek Sagar
^ permalink raw reply
* Re: [CURIOUSITY] When will we stop caring about arch/ppc?
From: Segher Boessenkool @ 2007-06-26 7:48 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1182804609.20939.5.camel@weaponx.rchland.ibm.com>
> But I meant adding
> something in the Documentation/powerpc/ directory and maybe
> feature-removal-schedule.txt. Basically a written down thing in the
> kernel source to refer people to.
How about this time next year -- special event at
the OLS PowerPC BOF :-)
Segher
^ permalink raw reply
* RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
From: Ming Liu @ 2007-06-26 7:42 UTC (permalink / raw)
To: greg.crocker, linuxppc-embedded
In-Reply-To: <e4fee3c50706251242h722c00dbpfc7881aa890a5e1e@mail.gmail.com>
Actually I have asked the xilinx expert on the statistics. With the
PLB_TEMAC, we can also get a result like that, say 300Mbps for TCP. (From
their numbers, the throughput is even higher.)
Some remindings from my experience: Remember to enable everything in the
hardware and software which can improve the performance, such as,
CS_offloading, data allighment engines, large fifos, and so on, from the
configuration of PLB_TEMAC in EDK. As well, remember to enable cache. In
the software field, interrupt_coaleascing will also help. At this time,
normally we can get more than 100Mbps for TCP. Jumbo-frame of 8982 will
almost double this number.
Have fun.
BR
Ming
>From: "Greg Crocker" <greg.crocker@gmail.com>
>To: linuxppc-embedded@ozlabs.org
>Subject: RE: ML403 gigabit ethernet bandwidth - 2.6 kernel
>Date: Mon, 25 Jun 2007 15:42:09 -0400
>
>I was able to achieve ~320 Mbit/sec data rate using the Gigabit
>System
>Reference Design (GSRD XAPP535/536) from Xilinx. This utilizes the
>LocalLink TEMAC to perform the transfers. The reference design
>provides the
>Linux 2.4 drivers that can be ported to Linux 2.6 with a little
>effort.
>
>This implementation did not use checksum offloading and the data
>rates were
>achieved using TCP_STREAM on netperf.
>
>Greg
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees
From: Segher Boessenkool @ 2007-06-26 7:40 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <467FE6E5.1070403@freescale.com>
>> Yup, they're both marked for removal so let's just remove them
>> at the same time.
>
> As soon as Paul creates a "for-2.6.25" branch, that's when I was
> planning on doing it.
Sounds like as good a time as any.
>> Does the kernel provide a warning to users of too-old firmware^Wuboot
>> telling them to update btw?
>
> Nope. The current U-Boot code updates mac-address and/or
> local-mac-address, whichever ones exist. If neither exists, it
> doesn't do anything. If both exists, it updates both with the same
> value. This makes it DTS-agnostic, so to speak.
>
> The kernel looks at each of the properties and uses the first one that
> has a valid MAC address. Again, this is U-Boot- and DTS-agnostic.
Yeah, that's fine. I just meant the current kernel (before
.25) could detect you are using a uboot that won't work after
.25 anymore, and shout at the user. Would save you some bug
reports ;-)
> In other words, the current U-Boot and Linux code is written to not
> care what the other one does. I have no plans to remove the code in
> the kernel that looks for obsolete entries (I'm talking about function
> of_get_mac_address), because it's "safe".
Well you should remove the "address" thing, it is _not_ safe.
> However, now that you mention it, I could update function
> of_get_mac_address() to display a warning if it only finds the
> 'address' property.
Yeah exactly.
> That property is definitely wrong and should never be in the DTS or
> any device tree passed to the kernel.
Segher
^ permalink raw reply
* Re: [PATCH 3/3] Make jprobes a little safer for users
From: Andrew Morton @ 2007-06-26 6:51 UTC (permalink / raw)
To: michael
Cc: linux-arch, linux-ia64, linux-kernel, anil.s.keshavamurthy,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <1182837838.6673.17.camel@concordia.ozlabs.ibm.com>
On Tue, 26 Jun 2007 16:03:58 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> On Tue, 2007-06-26 at 07:53 +0200, Christoph Hellwig wrote:
> > On Tue, Jun 26, 2007 at 11:48:51AM +1000, Michael Ellerman wrote:
> > > I realise jprobes are a razor-blades-included type of interface, but
> > > that doesn't mean we can't try and make them safer to use. This guy I
> > > know once wrote code like this:
> > >
> > > struct jprobe jp = { .kp.symbol_name = "foo", .entry = "jprobe_foo" };
> > >
> > > And then his kernel exploded. Oops.
> > >
> > > This patch adds an arch hook, arch_deref_entry_point() (I don't like it either)
> > > which takes the void * in a struct jprobe, and gives back the text address
> > > that it represents.
> > >
> > > We can then use that in register_jprobe() to check that the entry point
> > > we're passed is actually in the kernel text, rather than just some random
> > > value.
> >
> > Please don't add more weak functions, they're utterly horrible for
> > anyone trying to understand the code. Otherwise this looks fine to me.
>
> What do you recommend instead? #define ARCH_HAS_FOO_BAR ?
o lord, save us, no.
> I don't see what's utterly horrible about them.
Me either.
> The fact that they're
> weak is fairly reasonable documentation that they're overridden
> somewhere else. And grep/cscope/ctags will find both the weak and
> non-weak versions for you?
yup.
In this case we could just require that each jprobes-supporting
architecture implement arch_deref_entry_point().
Or one could do the Linus trick. In each architecture which implements
arch_deref_entry_point() do:
#define arch_deref_entry_point arch_deref_entry_point
in the per-arch header file then, in non-arch code, do
#ifndef arch_deref_entry_point
static unsigned long arch_deref_entry_point(...)
{
<generic implementation>
}
#endif
That's just the ARCH_HAS_FOO_BAR thing, only less fugly.
^ permalink raw reply
* Re: [PATCH 3/3] Make jprobes a little safer for users
From: Michael Ellerman @ 2007-06-26 6:34 UTC (permalink / raw)
To: Abhishek Sagar
Cc: linux-arch, Andrew Morton, linux-ia64, linux-kernel,
anil.s.keshavamurthy, linuxppc-dev, Christoph Hellwig
In-Reply-To: <863e9df20706252319j239eaf44wee7a46ad742c9585@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]
On Tue, 2007-06-26 at 11:49 +0530, Abhishek Sagar wrote:
> On 6/26/07, Michael Ellerman <michael@ellerman.id.au> wrote:
>
> > We can then use that in register_jprobe() to check that the entry point
> > we're passed is actually in the kernel text, rather than just some random
> > value.
>
> A similar cleanup is possible even for return probes then. I wonder if
> there are any kprobe related scenarios where the executable code may
> be located outside the core kernel text region (e.g, ITCM?). In that
> case would it also be wrong to assume that the jprobe handler may be
> situated outside the kernel core text / module region? Would it then
> make sense to move this check from register_jprobe() to the arch
> dependent code?
It did occur to me that someone might be doing something crazy like
branching to code that's not in the kernel/module text - but I was
hoping that wouldn't be the case. I'm not sure what ITCM is?
> > int __kprobes register_jprobe(struct jprobe *jp)
> > {
> > + unsigned long addr = arch_deref_entry_point(jp->entry);
> > +
> > + if (!kernel_text_address(addr))
> > + return -EINVAL;
>
> Seems like you're checking for the jprobe handler to be within
> kernel/module range. Why not narrow this down to just module range
> (!module_text_address(addr), say)? Core kernel functions would not be
> ending with a 'jprobe_return()' anyway.
There's jprobe code in net/ipv4/tcp_probe.c and net/dccp/probe.c that
can be builtin or modular, so I think kernel_text_address() is right.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] Make jprobes a little safer for users
From: Abhishek Sagar @ 2007-06-26 6:19 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-arch, Andrew Morton, linux-ia64, linux-kernel,
anil.s.keshavamurthy, linuxppc-dev, Christoph Hellwig
In-Reply-To: <7a070581b2fe53ea65216e86c86abc4f40464341.1182822366.git.michael@ellerman.id.au>
On 6/26/07, Michael Ellerman <michael@ellerman.id.au> wrote:
> We can then use that in register_jprobe() to check that the entry point
> we're passed is actually in the kernel text, rather than just some random
> value.
A similar cleanup is possible even for return probes then. I wonder if
there are any kprobe related scenarios where the executable code may
be located outside the core kernel text region (e.g, ITCM?). In that
case would it also be wrong to assume that the jprobe handler may be
situated outside the kernel core text / module region? Would it then
make sense to move this check from register_jprobe() to the arch
dependent code?
> int __kprobes register_jprobe(struct jprobe *jp)
> {
> + unsigned long addr = arch_deref_entry_point(jp->entry);
> +
> + if (!kernel_text_address(addr))
> + return -EINVAL;
Seems like you're checking for the jprobe handler to be within
kernel/module range. Why not narrow this down to just module range
(!module_text_address(addr), say)? Core kernel functions would not be
ending with a 'jprobe_return()' anyway.
--
Abhishek Sagar
-
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 3/3] Make jprobes a little safer for users
From: Michael Ellerman @ 2007-06-26 6:03 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, Andrew Morton, linux-ia64, linux-kernel,
anil.s.keshavamurthy, linuxppc-dev
In-Reply-To: <20070626055347.GB6841@lst.de>
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
On Tue, 2007-06-26 at 07:53 +0200, Christoph Hellwig wrote:
> On Tue, Jun 26, 2007 at 11:48:51AM +1000, Michael Ellerman wrote:
> > I realise jprobes are a razor-blades-included type of interface, but
> > that doesn't mean we can't try and make them safer to use. This guy I
> > know once wrote code like this:
> >
> > struct jprobe jp = { .kp.symbol_name = "foo", .entry = "jprobe_foo" };
> >
> > And then his kernel exploded. Oops.
> >
> > This patch adds an arch hook, arch_deref_entry_point() (I don't like it either)
> > which takes the void * in a struct jprobe, and gives back the text address
> > that it represents.
> >
> > We can then use that in register_jprobe() to check that the entry point
> > we're passed is actually in the kernel text, rather than just some random
> > value.
>
> Please don't add more weak functions, they're utterly horrible for
> anyone trying to understand the code. Otherwise this looks fine to me.
What do you recommend instead? #define ARCH_HAS_FOO_BAR ?
I don't see what's utterly horrible about them. The fact that they're
weak is fairly reasonable documentation that they're overridden
somewhere else. And grep/cscope/ctags will find both the weak and
non-weak versions for you?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Who can help me with my NFS?
From: xu chen @ 2007-06-26 5:59 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3342 bytes --]
I ported my opb_ethernet driver to the ml403 board, with the reference system provided by Xilinx Co. Now I can ping the host with the board, and can also ping the board with PC. But I can't mount the NFS of my PC. The host configuration is correct, and the host can also be mounted by other PCs. Here is my tcpdump log when the board mount the PC's NFS, PC's IP: 192.168.1.107; board's IP: 192.168.1.134
/* log started */
20:14:42.349932 arp who-has 192.168.1.107 tell 192.168.1.134
20:14:47.070616 arp reply 192.168.1.107 is-at 00:e0:4c:fe:d0:f1 (oui Unknown)
20:14:42.394658 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: S 1146939992:1146939992(0) win 5840 <mss 1460,sackOK,timestamp 196450 0,nop,wscale 1>
20:14:42.394707 IP 192.168.1.107.sunrpc > 192.168.1.134.cadlock: S 1643811256:1643811256(0) ack 1146939993 win 5792 <mss 1460,sackOK,timestamp 27240469 196450,nop,wscale 2>
20:14:42.446740 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: . ack 1 win 2920 <nop,nop,timestamp 196477 27240469>
20:14:42.498840 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: P 1:45(44) ack 1 win 2920 <nop,nop,timestamp 196490 27240469>
20:14:42.871984 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: P 1:45(44) ack 1 win 2920 <nop,nop,timestamp 196584 27240469>
20:14:43.568070 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: P 1:45(44) ack 1 win 2920 <nop,nop,timestamp 196758 27240469>
20:14:44.912202 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: P 1:45(44) ack 1 win 2920 <nop,nop,timestamp 197094 27240469>
20:14:47.552563 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: P 1:45(44) ack 1 win 2920 <nop,nop,timestamp 197754 27240469>
20:14:52.785247 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: P 1:45(44) ack 1 win 2920 <nop,nop,timestamp 199062 27240469>
20:15:03.202489 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: P 1:45(44) ack 1 win 2920 <nop,nop,timestamp 201666 27240469>
20:15:23.988960 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: P 1:45(44) ack 1 win 2920 <nop,nop,timestamp 206862 27240469>
20:15:28.989426 arp who-has 192.168.1.107 tell 192.168.1.134
20:15:28.989446 arp reply 192.168.1.107 is-at 00:e0:4c:fe:d0:f1 (oui Unknown)
20:15:42.557376 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: F 45:45(0) ack 1 win 2920 <nop,nop,timestamp 211503 27240469>
20:15:42.557423 IP 192.168.1.107.sunrpc > 192.168.1.134.cadlock: . ack 1 win 1448 <nop,nop,timestamp 27255509 196477,nop,nop,sack 1 {45:46}>
20:15:42.610524 IP 192.168.1.134.rtip > 192.168.1.107.rlzdbase: UDP, length 100
20:15:45.660481 IP 192.168.1.134.rtip > 192.168.1.107.rlzdbase: UDP, length 100
20:15:47.555896 arp who-has 192.168.1.134 tell 192.168.1.107
20:15:47.605255 arp reply 192.168.1.134 is-at 00:0a:35:01:7e:d1 (oui Unknown)
20:15:48.708674 IP 192.168.1.134.rtip > 192.168.1.107.rlzdbase: UDP, length 100
20:15:51.757068 IP 192.168.1.134.rtip > 192.168.1.107.rlzdbase: UDP, length 100
20:15:54.805366 IP 192.168.1.134.rtip > 192.168.1.107.rlzdbase: UDP, length 100
20:15:57.853759 IP 192.168.1.134.rtip > 192.168.1.107.rlzdbase: UDP, length 100
20:16:00.902163 IP 192.168.1.134.rtip > 192.168.1.107.rlzdbase: UDP, length 100
20:16:05.513866 IP 192.168.1.134.cadlock > 192.168.1.107.sunrpc: P 1:45(44) ack 1 win 2920 <nop,nop,timestamp 217242 27255509>
/* log ended */
---------------------------------
雅虎免费邮箱-3.5G容量，20M附件
[-- Attachment #2: Type: text/html, Size: 3634 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] Make jprobes a little safer for users
From: Christoph Hellwig @ 2007-06-26 5:53 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-arch, Andrew Morton, linux-ia64, linux-kernel,
anil.s.keshavamurthy, linuxppc-dev, Christoph Hellwig
In-Reply-To: <7a070581b2fe53ea65216e86c86abc4f40464341.1182822366.git.michael@ellerman.id.au>
On Tue, Jun 26, 2007 at 11:48:51AM +1000, Michael Ellerman wrote:
> I realise jprobes are a razor-blades-included type of interface, but
> that doesn't mean we can't try and make them safer to use. This guy I
> know once wrote code like this:
>
> struct jprobe jp = { .kp.symbol_name = "foo", .entry = "jprobe_foo" };
>
> And then his kernel exploded. Oops.
>
> This patch adds an arch hook, arch_deref_entry_point() (I don't like it either)
> which takes the void * in a struct jprobe, and gives back the text address
> that it represents.
>
> We can then use that in register_jprobe() to check that the entry point
> we're passed is actually in the kernel text, rather than just some random
> value.
Please don't add more weak functions, they're utterly horrible for
anyone trying to understand the code. Otherwise this looks fine to me.
^ permalink raw reply
* Re: [PATCH 2/3] Remove JPROBE_ENTRY()
From: Christoph Hellwig @ 2007-06-26 5:52 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-arch, Andrew Morton, linux-ia64, linux-kernel,
anil.s.keshavamurthy, linuxppc-dev, Christoph Hellwig
In-Reply-To: <98c8ff25191ced991066092ffd4899526097da1e.1182822366.git.michael@ellerman.id.au>
On Tue, Jun 26, 2007 at 11:48:51AM +1000, Michael Ellerman wrote:
> AFAICT now that jprobe.entry is a void *, JPROBE_ENTRY doesn't do
> anything useful - so remove it ..
>
> I've left a do-nothing version so that out-of-tree jprobes code will still
> compile without modifications.
Please kill the definition. We don't want to keep unused crap around
just to let code compile. And I have some plans for even deeper change
in this area, so they'll have to change anyway.
^ permalink raw reply
* Re: [PATCH 1/3] Make struct jprobe.entry a void *
From: Michael Ellerman @ 2007-06-26 4:35 UTC (permalink / raw)
To: ananth
Cc: linux-arch, Andrew Morton, linux-ia64, linux-kernel,
anil.s.keshavamurthy, linuxppc-dev, Christoph Hellwig
In-Reply-To: <20070626035946.GA20460@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
On Tue, 2007-06-26 at 09:29 +0530, Ananth N Mavinakayanahalli wrote:
> On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote:
> > ---
> >
> > It isn't obvious where kprobes patches should go, is anyone "the" maintainer?
> > Instead I've just sent this to everyone who'd touched the code lately, or
> > might be otherwise interested.
>
> There isn't a single maintainer for the kprobes infrastructure as it
> contains quite a bit of low level arch specific code. The working model
> currently is that the patches are sent to lkml with a cc to the
> maintainers listed, as you've rightly done.
OK, no worries. I guess that's a bit messy to put into a MAINTAINERS entry.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] Make struct jprobe.entry a void *
From: Ananth N Mavinakayanahalli @ 2007-06-26 3:59 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-arch, Andrew Morton, linux-ia64, linux-kernel,
anil.s.keshavamurthy, linuxppc-dev, Christoph Hellwig
In-Reply-To: <78935473b1f70c863ab0be7d6cf4bcb04922b20b.1182822366.git.michael@ellerman.id.au>
On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote:
> ---
>
> It isn't obvious where kprobes patches should go, is anyone "the" maintainer?
> Instead I've just sent this to everyone who'd touched the code lately, or
> might be otherwise interested.
There isn't a single maintainer for the kprobes infrastructure as it
contains quite a bit of low level arch specific code. The working model
currently is that the patches are sent to lkml with a cc to the
maintainers listed, as you've rightly done.
Ananth
^ permalink raw reply
* Re: [PATCH 1/3] Make struct jprobe.entry a void *
From: Ananth N Mavinakayanahalli @ 2007-06-26 3:51 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-arch, Andrew Morton, linux-ia64, linux-kernel,
anil.s.keshavamurthy, linuxppc-dev, Christoph Hellwig
In-Reply-To: <78935473b1f70c863ab0be7d6cf4bcb04922b20b.1182822366.git.michael@ellerman.id.au>
On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote:
> Currently jprobe.entry is a kprobe_opcode_t *, but that's a lie. On some
> platforms it doesn't point to an opcode at all, it points to a function
> descriptor.
>
> It's really a pointer to something that the arch code can turn into a
> function entry point. And that's what actually happens, none of the
> generic code ever looks at jprobe.entry, it's only ever dereferenced
> by arch code.
>
> So just make it a void *.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Tested on powerpc. Ack to all three patches plus Andrew's declaration
fixup.
Thanks Michael for the patches.
Acked-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> ---
>
> It isn't obvious where kprobes patches should go, is anyone "the" maintainer?
> Instead I've just sent this to everyone who'd touched the code lately, or
> might be otherwise interested.
>
>
> include/linux/kprobes.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
> index 23adf60..f4e53b7 100644
> --- a/include/linux/kprobes.h
> +++ b/include/linux/kprobes.h
> @@ -116,7 +116,7 @@ struct kprobe {
> */
> struct jprobe {
> struct kprobe kp;
> - kprobe_opcode_t *entry; /* probe handling code to jump to */
> + void *entry; /* probe handling code to jump to */
> };
>
> DECLARE_PER_CPU(struct kprobe *, current_kprobe);
> --
> 1.5.1.3.g7a33b
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox