* RE: SATA FSL and upstreaming
From: Bhushan Bharat-R65777 @ 2013-05-16 7:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Zang Roy-R61911
Cc: tiejun.chen, Fleming Andy-AFLEMING, linuxppc-dev@lists.ozlabs.org,
Xie Shaohui-B21989, Liu Qiang-B32616
In-Reply-To: <1368687941.9603.56.camel@pasglop>
QmVuLCBXaGljaCBTREsgeW91IGFyZSB1c2luZz8NCg0KLUJoYXJhdA0KDQo+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbmphbWluIEhlcnJlbnNjaG1pZHQgW21haWx0bzpi
ZW5oQGtlcm5lbC5jcmFzaGluZy5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMTYsIDIwMTMg
MTI6MzYgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogQmh1c2hhbiBCaGFyYXQtUjY1
Nzc3OyB0aWVqdW4uY2hlbjsgTGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBBbmR5LUFGTEVNSU5H
Ow0KPiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgWGllIFNoYW9odWktQjIxOTg5DQo+
IFN1YmplY3Q6IFJlOiBTQVRBIEZTTCBhbmQgdXBzdHJlYW1pbmcNCj4gDQo+IE9uIFRodSwgMjAx
My0wNS0xNiBhdCAwNzowMSArMDAwMCwgWmFuZyBSb3ktUjYxOTExIHdyb3RlOg0KPiANCj4gPiBJ
IGp1c3QgdHJpZWQgeW91ciBSQ1cuIG9uZSBlMTAwMCBjYXJkIHdvcmtzIGluIHNsb3Q3Lg0KPiA+
IHdlIG1heSBuZWVkIHRvIGNoZWNrIG90aGVycyAuLi4NCj4gDQo+IFRyaWVkIDQgYW5kIDcgLi4u
DQo+IA0KPiBOb3RlIHRoYXQgdGhpcyAqdXNlZCogdG8gd29yay4gTGFzdCB5ZWFyIEkgaGFkIHRo
aXMgbWFjaGluZSB1cCB3aXRoIDIgY2FyZHMNCj4gZG9pbmcgdGhpbmdzLiBOb3Qgc3VyZSB3aGF0
IGNoYW5nZWQsIGl0J3MgcG9zc2libGUgdGhhdCB0aGUgRElQIGdvdA0KPiBpbmFkdmVydGVudGx5
IGNoYW5nZWQuIE9yIHNvbWVib2R5IHN0b2xlIGEganVtcGVyIGZyb20gaXQgaW4gdGhlIGxhYiA6
LSkNCj4gDQo+ID4gVS1Cb290IDIwMTMuMDEtMDAwNzgtZzI3NDFjOTkgKE1heSAwMyAyMDEzIC0g
MDA6MjA6NDEpDQo+ID4NCj4gPiBDUFUwOiAgUDUwMjBFLCBWZXJzaW9uOiAyLjAsICgweDgyMjgw
MDIwKQ0KPiA+IENvcmU6ICBFNTUwMCwgVmVyc2lvbjogMS4yLCAoMHg4MDI0MDAxMikgQ2xvY2sg
Q29uZmlndXJhdGlvbjoNCj4gPiAgICAgICAgQ1BVMDoyMDAwIE1IeiwgQ1BVMToyMDAwIE1IeiwN
Cj4gPiAgICAgICAgQ0NCOjgwMCAgTUh6LA0KPiA+ICAgICAgICBERFI6NjY2LjY2NyBNSHogKDEz
MzMuMzMzIE1UL3MgZGF0YSByYXRlKSAoQXN5bmNocm9ub3VzKSwgTEJDOjEwMCAgTUh6DQo+ID4g
ICAgICAgIEZNQU4xOiA2MDAgTUh6DQo+ID4gICAgICAgIFFNQU46ICA0MDAgTUh6DQo+ID4gICAg
ICAgIFBNRTogICA0MDAgTUh6DQo+ID4gTDE6ICAgIEQtY2FjaGUgMzIga0IgZW5hYmxlZA0KPiA+
ICAgICAgICBJLWNhY2hlIDMyIGtCIGVuYWJsZWQNCj4gPiBSZXNldCBDb25maWd1cmF0aW9uIFdv
cmQgKFJDVyk6DQo+ID4gICAgICAgIDAwMDAwMDAwOiAwYzU0MDAwMCAwMDAwMDAwMCAxZTEyMDAw
MCAwMDAwMDAwMA0KPiA+ICAgICAgICAwMDAwMDAxMDogZDg5ODRhMDEgMDMwMDIwMDAgZGU4MDAw
MDAgNDEwMDAwMDANCj4gPiAgICAgICAgMDAwMDAwMjA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAw
MDAwIDEwMDcwMDAwDQo+ID4gICAgICAgIDAwMDAwMDMwOiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw
MDAwMCAwMDAwMDAwMA0KPiANCj4gTXkgUkNXIGlzIGlkZW50aWNhbA0KPiANCj4gPiBCb2FyZDog
UDUwMjBEUywgU3lzIElEOiAweDFjLCBTeXMgVmVyOiAweDAyLCBGUEdBIFZlcjogMHgwNCwgdkJh
bms6IDQNCj4gDQo+IE1pbmUgaXM6DQo+IEJvYXJkOiBQNTAyMERTLCBTeXMgSUQ6IDB4MWMsIFN5
cyBWZXI6IDB4MTIsIEZQR0EgVmVyOiAweDA1LCB2QmFuazogNA0KPiANCj4gPiBTRVJERVMgUmVm
ZXJlbmNlIENsb2NrczogQmFuazE9MTAwTWh6IEJhbmsyPTEyNU1oeiBCYW5rMz0xMjVNaHoNCj4g
DQo+IFNhbWUuDQo+IA0KPiA+IEkyQzogICByZWFkeQ0KPiA+IFNQSTogICByZWFkeQ0KPiA+IERS
QU06ICBJbml0aWFsaXppbmcuLi4udXNpbmcgU1BEDQo+ID4gRGV0ZWN0ZWQgVURJTU0gaS1ESU1N
DQo+ID4gRGV0ZWN0ZWQgVURJTU0gaS1ESU1NDQo+ID4gMiBHaUIgbGVmdCB1bm1hcHBlZA0KPiA+
IDQgR2lCIChERFIzLCA2NC1iaXQsIENMPTksIEVDQyBvbikNCj4gPiAgICAgICAgRERSIENvbnRy
b2xsZXIgSW50ZXJsZWF2aW5nIE1vZGU6IGNhY2hlIGxpbmUNCj4gPiAgICAgICAgRERSIENoaXAt
U2VsZWN0IEludGVybGVhdmluZyBNb2RlOiBDUzArQ1MxIFRlc3RpbmcgMHgwMDAwMDAwMCAtDQo+
ID4gMHg3ZmZmZmZmZiBUZXN0aW5nIDB4ODAwMDAwMDAgLSAweGZmZmZmZmZmIFJlbWFwIEREUiAy
IEdpQiBsZWZ0DQo+ID4gdW5tYXBwZWQNCj4gPg0KPiA+IFBPU1QgbWVtb3J5IFBBU1NFRA0KPiA+
IEZsYXNoOiAxMjggTWlCDQo+ID4gTDI6ICAgIDUxMiBLQiBlbmFibGVkDQo+ID4gQ29yZW5ldCBQ
bGF0Zm9ybSBDYWNoZTogMjA0OCBLQiBlbmFibGVkDQo+ID4gU1JJTzE6IGRpc2FibGVkDQo+ID4g
U1JJTzI6IGRpc2FibGVkDQo+ID4gTkFORDogIDEwMjQgTWlCDQo+ID4gTU1DOiAgRlNMX1NESEM6
IDANCj4gPiBFRVBST006IEludmFsaWQgSUQgKGZmIGZmIGZmIGZmKQ0KPiA+IFBDSWUxOiBSb290
IENvbXBsZXgsIHgyLCByZWdzIEAgMHhmZTIwMDAwMA0KPiA+ICAgMDE6MDAuMCAgICAgLSA4MDg2
OjEwNWUgLSBOZXR3b3JrIGNvbnRyb2xsZXINCj4gPiAgIDAxOjAwLjEgICAgIC0gODA4NjoxMDVl
IC0gTmV0d29yayBjb250cm9sbGVyDQo+ID4gUENJZTE6IEJ1cyAwMCAtIDAxDQo+ID4gUENJZTI6
IGRpc2FibGVkDQo+ID4gUENJZTM6IFJvb3QgQ29tcGxleCwgbm8gbGluaywgcmVncyBAIDB4ZmUy
MDIwMDANCj4gPiBQQ0llMzogQnVzIDAyIC0gMDINCj4gPiBQQ0llNDogZGlzYWJsZWQNCj4gDQo+
IEFuZCBJIG5ldmVyIHNlZSBhbnl0aGluZyBoZXJlIGFueW1vcmUuLi4NCj4gDQo+ID4gSW46ICAg
IHNlcmlhbA0KPiA+IE91dDogICBzZXJpYWwNCj4gPiBFcnI6ICAgc2VyaWFsDQo+ID4gTmV0OiAg
IEluaXRpYWxpemluZyBGbWFuDQo+ID4gRm1hbjE6IFVwbG9hZGluZyBtaWNyb2NvZGUgdmVyc2lv
biAxMDYuMS42IFBIWSByZXNldCB0aW1lZCBvdXQgUEhZDQo+ID4gcmVzZXQgdGltZWQgb3V0IFBI
WSByZXNldCB0aW1lZCBvdXQgUEhZIHJlc2V0IHRpbWVkIG91dA0KPiA+IGUxMDAwOiAwMDoxNTox
NzoxNjpjZTpiOA0KPiA+ICAgICAgICBlMTAwMDogMDA6MTU6MTc6MTY6Y2U6YjkNCj4gPiAgICAg
ICAgRk0xQERUU0VDMSwgRk0xQERUU0VDMiwgRk0xQERUU0VDMywgRk0xQERUU0VDNCBbUFJJTUVd
LA0KPiA+IEZNMUBEVFNFQzUsIEZNMUBUR0VDMSwgZTEwMDAjMA0KPiA+IFdhcm5pbmc6IGUxMDAw
IzAgTUFDIGFkZHJlc3NlcyBkb24ndCBtYXRjaDoNCj4gPiBBZGRyZXNzIGluIFNST00gaXMgICAg
ICAgICAwMDoxNToxNzoxNjpjZTpiOA0KPiA+IEFkZHJlc3MgaW4gZW52aXJvbm1lbnQgaXMgIDAw
OjFiOjIxOjY4OjVlOmQ0ICwgZTEwMDAjMQ0KPiA+IFdhcm5pbmc6IGUxMDAwIzEgdXNpbmcgTUFD
IGFkZHJlc3MgZnJvbSBuZXQgZGV2aWNlDQo+ID4NCj4gPiA9Pg0KPiANCj4gDQoNCg==
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Zang Roy-R61911 @ 2013-05-16 7:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1368687558.9603.54.camel@pasglop>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Benjamin
> Herrenschmidt
> Sent: Thursday, May 16, 2013 2:59 PM
> To: Zang Roy-R61911
> Cc: Xie Shaohui-B21989; Liu Qiang-B32616; tiejun.chen; Fleming Andy-
> AFLEMING; Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
> Subject: Re: SATA FSL and upstreaming
>=20
> Ok, so I found this one on the SDK ISO: rcw_15g_2000mhz.bin
>=20
> I flashed that, did pix altbank, I'm now booted from Bank 4 ... and PCIe
> is still showing nothing. I have cards in slots 4 and 7 (assuming that's
> the right numbering, ie, 7 is the top one).
Right.
>=20
> Are we sure we don't have a problem with some DIP ? I saw some of them
> control some SERDES stuff (SW5 iirc)
Your serdes1 clock is 100MHz,which is correct.
Slot7 (PCIe1) does not need extra DIP to make it work.
Maybe you also need to update the U-boot.
Roy
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Zang Roy-R61911 @ 2013-05-16 7:20 UTC (permalink / raw)
To: tiejun.chen
Cc: Fleming Andy-AFLEMING, linuxppc-dev@lists.ozlabs.org,
Xie Shaohui-B21989, Bhushan Bharat-R65777
In-Reply-To: <51947BC3.9040208@windriver.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDE2
LCAyMDEzIDI6MjUgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogQmVuamFtaW4gSGVy
cmVuc2NobWlkdDsgTGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBBbmR5LUFGTEVNSU5HOw0KPiBs
aW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgWGllIFNoYW9odWktQjIxOTg5OyBCaHVzaGFu
IEJoYXJhdC1SNjU3NzcNCj4gU3ViamVjdDogUmU6IFNBVEEgRlNMIGFuZCB1cHN0cmVhbWluZw0K
PiANCj4gT24gMDUvMTYvMjAxMyAwMjoyMCBQTSwgWmFuZyBSb3ktUjYxOTExIHdyb3RlOg0KPiA+
DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogdGllanVu
LmNoZW4gW21haWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiA+PiBTZW50OiBUaHVy
c2RheSwgTWF5IDE2LCAyMDEzIDI6MTggUE0NCj4gPj4gVG86IEJlbmphbWluIEhlcnJlbnNjaG1p
ZHQNCj4gPj4gQ2M6IFphbmcgUm95LVI2MTkxMTsgTGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBB
bmR5LUFGTEVNSU5HOw0KPiA+PiBsaW51eHBwYy0gZGV2QGxpc3RzLm96bGFicy5vcmc7IFhpZSBT
aGFvaHVpLUIyMTk4OTsgQmh1c2hhbg0KPiA+PiBCaGFyYXQtUjY1Nzc3DQo+ID4+IFN1YmplY3Q6
IFJlOiBTQVRBIEZTTCBhbmQgdXBzdHJlYW1pbmcNCj4gPj4NCj4gPj4gT24gMDUvMTYvMjAxMyAw
MjowOSBQTSwgQmVuamFtaW4gSGVycmVuc2NobWlkdCB3cm90ZToNCj4gPj4+IE9uIFRodSwgMjAx
My0wNS0xNiBhdCAwNjowNSArMDAwMCwgWmFuZyBSb3ktUjYxOTExIHdyb3RlOg0KPiA+Pj4+IEkg
ZG8gbm90IHN1Z2dlc3QgY2hhbmdpbmcgdGhlIFJDVy4gSWYgdGhlIFJDVyBpcyBicm9rZW4gb24g
QmVuJ3MNCj4gPj4+PiBzaWRlLCBpdCBpcyBub3QgZWFzeSB0byByZWNvdmVyIGZvciBoaW0uDQo+
ID4+Pj4gTGV0J3MgY2hlY2sgdGhlIFUtYm9vdCBvdXRwdXQgZmlyc3QuDQo+ID4+Pg0KPiA+Pj4g
VS1Cb290IDIwMTMuMDEtMDAwMDktZzdiY2Q3ZjQgKE1hciAxNCAyMDEzIC0gMTQ6MjM6MTYpDQo+
ID4+Pg0KPiA+Pj4gQ1BVMDogIFA1MDIwRSwgVmVyc2lvbjogMS4wLCAoMHg4MjI4MDAxMCkNCj4g
Pj4+IENvcmU6ICBFNTUwMCwgVmVyc2lvbjogMS4wLCAoMHg4MDI0MDAxMCkgQ2xvY2sgQ29uZmln
dXJhdGlvbjoNCj4gPj4+ICAgICAgICAgIENQVTA6MjAwMCBNSHosIENQVTE6MjAwMCBNSHosDQo+
ID4+PiAgICAgICAgICBDQ0I6ODAwICBNSHosDQo+ID4+PiAgICAgICAgICBERFI6NjY2LjY2NyBN
SHogKDEzMzMuMzMzIE1UL3MgZGF0YSByYXRlKSAoQXN5bmNocm9ub3VzKSwNCj4gPj4gTEJDOjEw
MCAgTUh6DQo+ID4+PiAgICAgICAgICBGTUFOMTogNjAwIE1Ieg0KPiA+Pj4gICAgICAgICAgUU1B
TjogIDQwMCBNSHoNCj4gPj4+ICAgICAgICAgIFBNRTogICA0MDAgTUh6DQo+ID4+PiBMMTogICAg
RC1jYWNoZSAzMiBrQiBlbmFibGVkDQo+ID4+PiAgICAgICAgICBJLWNhY2hlIDMyIGtCIGVuYWJs
ZWQNCj4gPj4+IEJvYXJkOiBQNTAyMERTLCBTeXMgSUQ6IDB4MWMsIFN5cyBWZXI6IDB4MTIsIEZQ
R0EgVmVyOiAweDA1LCB2QmFuazoNCj4gPj4+IDAgUmVzZXQgQ29uZmlndXJhdGlvbiBXb3JkIChS
Q1cpOg0KPiA+Pj4gICAgICAgICAgMDAwMDAwMDA6IDBjNTQwMDAwIDAwMDAwMDAwIDFlMTIwMDAw
IDAwMDAwMDAwDQo+ID4+PiAgICAgICAgICAwMDAwMDAxMDogZDg5ODRhMDEgMDMwMDIwMDAgZGU4
MDAwMDAgNDEwMDAwMDANCj4gPj4+ICAgICAgICAgIDAwMDAwMDIwOiAwMDAwMDAwMCAwMDAwMDAw
MCAwMDAwMDAwMCAxMDA3MDAwMA0KPiA+Pj4gICAgICAgICAgMDAwMDAwMzA6IDAwMDAwMDAwIDAw
MDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwDQo+ID4+DQo+ID4+IEkgdGhpbmsgeW91IGNhbiB1c2Ug
QmhhcmF0J3MgUkNXLCB3aGljaCBzZWVtcyBSUl9IWEFQTlNQXzB4MzYsIHRoZW4NCj4gPj4gcGxl
YXNlIHRha2UgYSBsb29rIGF0IHRoaXM6DQo+ID4gV2h5Pw0KPiANCj4gSSBqdXN0IGJlbGlldmUg
QmhhcmF0IHNob3VsZCBwaWNrIGEgcHJvcGVyIFJDVyBmcm9tIFNESy4NCldlIG1heSBhbHNvIG5l
ZWQgdG8gY2hlY2sgdGhlIG9yaWdpbmFsIFJDVyB3aHkgaXQgZG9lcyBub3Qgd29yayENCg0KPiAN
Cj4gPiBCZW4ncyBvbiBib2FyZCBSQ1cgcHJvdG9jb2wgaXMgMHgzNiwgd2hpY2ggc2hvdWxkIHdv
cmsgZm9yIFBDSWUxIChzbG90DQo+IDcpIGFuZCBQQ0llMyAoc2xvdDQpLg0KPiANCj4gRGlkbid0
IHlvdSBzZWUgSSdtIGFsc28gc2F5aW5nIHRvIHVzZSBzbG90IDcgYW5kIHNsb3QgND8NCldoaWNo
IHNsb3QgZGVwZW5kcyBvbiBTZXJkZXMgcHJvdG9jb2wuIHNsb3Q3IGlzIGZpeGVkIHRvIHBjaWUx
Lg0KUm95DQo=
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Xie Shaohui-B21989 @ 2013-05-16 7:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Liu Qiang-B32616, Zang Roy-R61911, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1368687941.9603.56.camel@pasglop>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwg
TWF5IDE2LCAyMDEzIDM6MDYgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogQmh1c2hh
biBCaGFyYXQtUjY1Nzc3OyB0aWVqdW4uY2hlbjsgTGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBB
bmR5LQ0KPiBBRkxFTUlORzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IFhpZSBTaGFv
aHVpLUIyMTk4OQ0KPiBTdWJqZWN0OiBSZTogU0FUQSBGU0wgYW5kIHVwc3RyZWFtaW5nDQo+IA0K
PiBPbiBUaHUsIDIwMTMtMDUtMTYgYXQgMDc6MDEgKzAwMDAsIFphbmcgUm95LVI2MTkxMSB3cm90
ZToNCj4gDQo+ID4gSSBqdXN0IHRyaWVkIHlvdXIgUkNXLiBvbmUgZTEwMDAgY2FyZCB3b3JrcyBp
biBzbG90Ny4NCj4gPiB3ZSBtYXkgbmVlZCB0byBjaGVjayBvdGhlcnMgLi4uDQo+IA0KPiBUcmll
ZCA0IGFuZCA3IC4uLg0KPiANCj4gTm90ZSB0aGF0IHRoaXMgKnVzZWQqIHRvIHdvcmsuIExhc3Qg
eWVhciBJIGhhZCB0aGlzIG1hY2hpbmUgdXAgd2l0aCAyDQo+IGNhcmRzIGRvaW5nIHRoaW5ncy4g
Tm90IHN1cmUgd2hhdCBjaGFuZ2VkLCBpdCdzIHBvc3NpYmxlIHRoYXQgdGhlIERJUCBnb3QNCj4g
aW5hZHZlcnRlbnRseSBjaGFuZ2VkLiANCltTLkhdIFBsZWFzZSBjaGVjayB0aGUgU1cyWzE6NF0s
IHNob3VsZCBiZTogb2ZmIG9mZiBvbiBvZmYNCg0KW1MuSF0gQmVzdCBSZWdhcmRzLCANClNoYW9o
dWkgWGllDQo=
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Bhushan Bharat-R65777 @ 2013-05-16 7:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Zang Roy-R61911
Cc: tiejun.chen, Fleming Andy-AFLEMING, linuxppc-dev@lists.ozlabs.org,
Xie Shaohui-B21989, Liu Qiang-B32616
In-Reply-To: <1368687941.9603.56.camel@pasglop>
QmVuLA0KDQpJZiB5b3UgYXJlIHVzaW5nIFNESzEuMyBhbmQgbGF0ZXIgdGhlbiB0aGUgc3VwcG9y
dCBmb3IgcDUwMjBkcyByZXYgMS4wIHN1cHBvcnQgaXMgcmVtb3ZlZC4NClNvIHVzZSBlYXJsaWVy
IHNkayBmb3IgcmV2IDEuMCBvciB3YWl0IGZvciByZXYyLjAgOikNCg0KVGhhbmtzDQotQmhhcmF0
DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJy
ZW5zY2htaWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBUaHVy
c2RheSwgTWF5IDE2LCAyMDEzIDEyOjM2IFBNDQo+IFRvOiBaYW5nIFJveS1SNjE5MTENCj4gQ2M6
IEJodXNoYW4gQmhhcmF0LVI2NTc3NzsgdGllanVuLmNoZW47IExpdSBRaWFuZy1CMzI2MTY7IEZs
ZW1pbmcgQW5keS1BRkxFTUlORzsNCj4gbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IFhp
ZSBTaGFvaHVpLUIyMTk4OQ0KPiBTdWJqZWN0OiBSZTogU0FUQSBGU0wgYW5kIHVwc3RyZWFtaW5n
DQo+IA0KPiBPbiBUaHUsIDIwMTMtMDUtMTYgYXQgMDc6MDEgKzAwMDAsIFphbmcgUm95LVI2MTkx
MSB3cm90ZToNCj4gDQo+ID4gSSBqdXN0IHRyaWVkIHlvdXIgUkNXLiBvbmUgZTEwMDAgY2FyZCB3
b3JrcyBpbiBzbG90Ny4NCj4gPiB3ZSBtYXkgbmVlZCB0byBjaGVjayBvdGhlcnMgLi4uDQo+IA0K
PiBUcmllZCA0IGFuZCA3IC4uLg0KPiANCj4gTm90ZSB0aGF0IHRoaXMgKnVzZWQqIHRvIHdvcmsu
IExhc3QgeWVhciBJIGhhZCB0aGlzIG1hY2hpbmUgdXAgd2l0aCAyIGNhcmRzDQo+IGRvaW5nIHRo
aW5ncy4gTm90IHN1cmUgd2hhdCBjaGFuZ2VkLCBpdCdzIHBvc3NpYmxlIHRoYXQgdGhlIERJUCBn
b3QNCj4gaW5hZHZlcnRlbnRseSBjaGFuZ2VkLiBPciBzb21lYm9keSBzdG9sZSBhIGp1bXBlciBm
cm9tIGl0IGluIHRoZSBsYWIgOi0pDQo+IA0KPiA+IFUtQm9vdCAyMDEzLjAxLTAwMDc4LWcyNzQx
Yzk5IChNYXkgMDMgMjAxMyAtIDAwOjIwOjQxKQ0KPiA+DQo+ID4gQ1BVMDogIFA1MDIwRSwgVmVy
c2lvbjogMi4wLCAoMHg4MjI4MDAyMCkNCj4gPiBDb3JlOiAgRTU1MDAsIFZlcnNpb246IDEuMiwg
KDB4ODAyNDAwMTIpIENsb2NrIENvbmZpZ3VyYXRpb246DQo+ID4gICAgICAgIENQVTA6MjAwMCBN
SHosIENQVTE6MjAwMCBNSHosDQo+ID4gICAgICAgIENDQjo4MDAgIE1IeiwNCj4gPiAgICAgICAg
RERSOjY2Ni42NjcgTUh6ICgxMzMzLjMzMyBNVC9zIGRhdGEgcmF0ZSkgKEFzeW5jaHJvbm91cyks
IExCQzoxMDAgIE1Ieg0KPiA+ICAgICAgICBGTUFOMTogNjAwIE1Ieg0KPiA+ICAgICAgICBRTUFO
OiAgNDAwIE1Ieg0KPiA+ICAgICAgICBQTUU6ICAgNDAwIE1Ieg0KPiA+IEwxOiAgICBELWNhY2hl
IDMyIGtCIGVuYWJsZWQNCj4gPiAgICAgICAgSS1jYWNoZSAzMiBrQiBlbmFibGVkDQo+ID4gUmVz
ZXQgQ29uZmlndXJhdGlvbiBXb3JkIChSQ1cpOg0KPiA+ICAgICAgICAwMDAwMDAwMDogMGM1NDAw
MDAgMDAwMDAwMDAgMWUxMjAwMDAgMDAwMDAwMDANCj4gPiAgICAgICAgMDAwMDAwMTA6IGQ4OTg0
YTAxIDAzMDAyMDAwIGRlODAwMDAwIDQxMDAwMDAwDQo+ID4gICAgICAgIDAwMDAwMDIwOiAwMDAw
MDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAxMDA3MDAwMA0KPiA+ICAgICAgICAwMDAwMDAzMDogMDAw
MDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCj4gDQo+IE15IFJDVyBpcyBpZGVudGlj
YWwNCj4gDQo+ID4gQm9hcmQ6IFA1MDIwRFMsIFN5cyBJRDogMHgxYywgU3lzIFZlcjogMHgwMiwg
RlBHQSBWZXI6IDB4MDQsIHZCYW5rOiA0DQo+IA0KPiBNaW5lIGlzOg0KPiBCb2FyZDogUDUwMjBE
UywgU3lzIElEOiAweDFjLCBTeXMgVmVyOiAweDEyLCBGUEdBIFZlcjogMHgwNSwgdkJhbms6IDQN
Cj4gDQo+ID4gU0VSREVTIFJlZmVyZW5jZSBDbG9ja3M6IEJhbmsxPTEwME1oeiBCYW5rMj0xMjVN
aHogQmFuazM9MTI1TWh6DQo+IA0KPiBTYW1lLg0KPiANCj4gPiBJMkM6ICAgcmVhZHkNCj4gPiBT
UEk6ICAgcmVhZHkNCj4gPiBEUkFNOiAgSW5pdGlhbGl6aW5nLi4uLnVzaW5nIFNQRA0KPiA+IERl
dGVjdGVkIFVESU1NIGktRElNTQ0KPiA+IERldGVjdGVkIFVESU1NIGktRElNTQ0KPiA+IDIgR2lC
IGxlZnQgdW5tYXBwZWQNCj4gPiA0IEdpQiAoRERSMywgNjQtYml0LCBDTD05LCBFQ0Mgb24pDQo+
ID4gICAgICAgIEREUiBDb250cm9sbGVyIEludGVybGVhdmluZyBNb2RlOiBjYWNoZSBsaW5lDQo+
ID4gICAgICAgIEREUiBDaGlwLVNlbGVjdCBJbnRlcmxlYXZpbmcgTW9kZTogQ1MwK0NTMSBUZXN0
aW5nIDB4MDAwMDAwMDAgLQ0KPiA+IDB4N2ZmZmZmZmYgVGVzdGluZyAweDgwMDAwMDAwIC0gMHhm
ZmZmZmZmZiBSZW1hcCBERFIgMiBHaUIgbGVmdA0KPiA+IHVubWFwcGVkDQo+ID4NCj4gPiBQT1NU
IG1lbW9yeSBQQVNTRUQNCj4gPiBGbGFzaDogMTI4IE1pQg0KPiA+IEwyOiAgICA1MTIgS0IgZW5h
YmxlZA0KPiA+IENvcmVuZXQgUGxhdGZvcm0gQ2FjaGU6IDIwNDggS0IgZW5hYmxlZA0KPiA+IFNS
SU8xOiBkaXNhYmxlZA0KPiA+IFNSSU8yOiBkaXNhYmxlZA0KPiA+IE5BTkQ6ICAxMDI0IE1pQg0K
PiA+IE1NQzogIEZTTF9TREhDOiAwDQo+ID4gRUVQUk9NOiBJbnZhbGlkIElEIChmZiBmZiBmZiBm
ZikNCj4gPiBQQ0llMTogUm9vdCBDb21wbGV4LCB4MiwgcmVncyBAIDB4ZmUyMDAwMDANCj4gPiAg
IDAxOjAwLjAgICAgIC0gODA4NjoxMDVlIC0gTmV0d29yayBjb250cm9sbGVyDQo+ID4gICAwMTow
MC4xICAgICAtIDgwODY6MTA1ZSAtIE5ldHdvcmsgY29udHJvbGxlcg0KPiA+IFBDSWUxOiBCdXMg
MDAgLSAwMQ0KPiA+IFBDSWUyOiBkaXNhYmxlZA0KPiA+IFBDSWUzOiBSb290IENvbXBsZXgsIG5v
IGxpbmssIHJlZ3MgQCAweGZlMjAyMDAwDQo+ID4gUENJZTM6IEJ1cyAwMiAtIDAyDQo+ID4gUENJ
ZTQ6IGRpc2FibGVkDQo+IA0KPiBBbmQgSSBuZXZlciBzZWUgYW55dGhpbmcgaGVyZSBhbnltb3Jl
Li4uDQo+IA0KPiA+IEluOiAgICBzZXJpYWwNCj4gPiBPdXQ6ICAgc2VyaWFsDQo+ID4gRXJyOiAg
IHNlcmlhbA0KPiA+IE5ldDogICBJbml0aWFsaXppbmcgRm1hbg0KPiA+IEZtYW4xOiBVcGxvYWRp
bmcgbWljcm9jb2RlIHZlcnNpb24gMTA2LjEuNiBQSFkgcmVzZXQgdGltZWQgb3V0IFBIWQ0KPiA+
IHJlc2V0IHRpbWVkIG91dCBQSFkgcmVzZXQgdGltZWQgb3V0IFBIWSByZXNldCB0aW1lZCBvdXQN
Cj4gPiBlMTAwMDogMDA6MTU6MTc6MTY6Y2U6YjgNCj4gPiAgICAgICAgZTEwMDA6IDAwOjE1OjE3
OjE2OmNlOmI5DQo+ID4gICAgICAgIEZNMUBEVFNFQzEsIEZNMUBEVFNFQzIsIEZNMUBEVFNFQzMs
IEZNMUBEVFNFQzQgW1BSSU1FXSwNCj4gPiBGTTFARFRTRUM1LCBGTTFAVEdFQzEsIGUxMDAwIzAN
Cj4gPiBXYXJuaW5nOiBlMTAwMCMwIE1BQyBhZGRyZXNzZXMgZG9uJ3QgbWF0Y2g6DQo+ID4gQWRk
cmVzcyBpbiBTUk9NIGlzICAgICAgICAgMDA6MTU6MTc6MTY6Y2U6YjgNCj4gPiBBZGRyZXNzIGlu
IGVudmlyb25tZW50IGlzICAwMDoxYjoyMTo2ODo1ZTpkNCAsIGUxMDAwIzENCj4gPiBXYXJuaW5n
OiBlMTAwMCMxIHVzaW5nIE1BQyBhZGRyZXNzIGZyb20gbmV0IGRldmljZQ0KPiA+DQo+ID4gPT4N
Cj4gDQo+IA0KDQo=
^ permalink raw reply
* Re: SATA FSL and upstreaming
From: Benjamin Herrenschmidt @ 2013-05-16 7:26 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Zang Roy-R61911,
tiejun.chen, Fleming Andy-AFLEMING, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0701C52E@039-SN2MPN1-012.039d.mgd.msft.net>
On Thu, 2013-05-16 at 07:13 +0000, Bhushan Bharat-R65777 wrote:
> Ben, Which SDK you are using?
QorIQ-SDK-V1.3.2-PPC64E5500-20130325-yocto.iso
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/book3e: introduce external_input_edge exception handler for 64bit kernel
From: Kevin Hao @ 2013-05-16 8:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc
In-Reply-To: <1368653426.8202.34@snotra>
[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]
On Wed, May 15, 2013 at 04:30:26PM -0500, Scott Wood wrote:
> On 05/13/2013 09:03:17 PM, Kevin Hao wrote:
> >On Mon, May 13, 2013 at 10:47:17AM -0500, Scott Wood wrote:
> >> On 05/11/2013 06:26:21 PM, Kevin Hao wrote:
> >> >In the external proxy facility mode, the interrupt is automatically
> >> >acknowledged with the same effect as reading the IACK register. So
> >> >this makes external input interrupt more like edge sensitive. That
> >> >means we can leave the irq hard enabled when it occurs with irq
> >soft
> >> >disabled just like the dec and doorbell interrupt. But the External
> >> >Proxy Register(EPR) is only considered valid from the time that the
> >> >external interrupt occurs until MSR[EE] is set to 1. So we have to
> >> >save the EPR before irq hard enabled.
> >>
> >> Is it really worth it?
> >
> >Maybe. :-)
> >Compare with the current kernel:
> > * The overhead is that we need additional load & store the
> >contents of
> > the EPR from/to PACA.
>
> There's also mental overhead of the extra complexity.
Yes, I agree. But since we already have the support for the edge sensitive
interrupt such as doorbell, decrementer, adding another one doesn't really
introduce much code complexity in my opinion.
> The lazy EE
> stuff is already fiddly enough (e.g. the recent KVM patches).
:-)
>
> > * The bonus is we keep the irq hard enabled when a external
> >interrupt occurs
> > with irq soft-disabled. As I know we should leave the irq hard
> >enabled as
> > much as possible. This is also the primary reason that we
> >introduce the
> > Lazy EE.
>
> I don't think "as much as possible" is a good way to look at it, so
> much as "as much as is practical", balanced by also wanting to keep
> the code as simple as is practical.
Yes, I also like simple. That is why I make the following patch first.
http://patchwork.ozlabs.org/patch/235530/
But it seems that Ben doesn't like it. And it also seem not so difficulty
to support the external interrupt as edge sensitive for external proxy,
so I scratch these patches. It seems that you and Ben have different
view about this issue. Anyway I have no strong preference for these two
ways and will leave it to you guys to determine which way we like to adopt.
Thanks,
Kevin
>
> -Scott
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
From: Michael Neuling @ 2013-05-16 10:09 UTC (permalink / raw)
To: Peter Zijlstra
Cc: ak@linux.intel.com, LKML, Stephane Eranian, Linux PPC dev,
Ingo Molnar
In-Reply-To: <20130516090916.GF19669@dyad.programming.kicks-ass.net>
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, May 15, 2013 at 03:37:22PM +0200, Stephane Eranian wrote:
> > On Fri, May 3, 2013 at 2:11 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > > We should always have proper privileges when requesting kernel data.
> > >
> > > Cc: Andi Kleen <ak@linux.intel.com>
> > > Cc: eranian@google.com
> > > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > > Link: http://lkml.kernel.org/n/tip-v0x9ky3ahzr6nm3c6ilwrili@git.kernel.org
> > > ---
> > > arch/x86/kernel/cpu/perf_event_intel_lbr.c | 5 ++++-
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> > > +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> > > @@ -318,8 +318,11 @@ static void intel_pmu_setup_sw_lbr_filte
> > > if (br_type & PERF_SAMPLE_BRANCH_USER)
> > > mask |= X86_BR_USER;
> > >
> > > - if (br_type & PERF_SAMPLE_BRANCH_KERNEL)
> > > + if (br_type & PERF_SAMPLE_BRANCH_KERNEL) {
> > > + if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
> > > + return -EACCES;
> > > mask |= X86_BR_KERNEL;
> > > + }
> > >
> > This will prevent regular users from capturing kernel -> kernel branches.
> > But it won't prevent users from getting kernel -> user branches. Thus
> > some kernel address will still be captured. I guess they could be eliminated
> > by the sw_filter.
> >
> > When using LBR priv level filtering, the filter applies to the branch target
> > only.
>
> How about something like the below? It also adds the branch flags
> Mikey wanted for PowerPC.
>
> ---
> arch/x86/kernel/cpu/perf_event_intel_lbr.c | 12 +++++++++---
> include/linux/perf_event.h | 10 +++++++---
> 2 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> index d978353..f44d635 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> @@ -585,17 +585,23 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
>
> /* if type does not correspond, then discard */
> if (type == X86_BR_NONE || (br_sel & type) != type) {
> - cpuc->lbr_entries[i].from = 0;
> + cpuc->lbr_entries[i].__delete = 1;
> compress = true;
> }
> +
> + /* hide kernel addresses if we're not privileged */
> + if (!(br_sel & X86_BR_KERNEL) && kernel_ip(from)) {
> + cpuc->lbr_entries[i].from = -1L;
> + cpuc->lbr_entries[i].invalid_from = 1;
> + }
> }
>
> if (!compress)
> return;
>
> - /* remove all entries with from=0 */
> + /* remove all entries with __delete */
> for (i = 0; i < cpuc->lbr_stack.nr; ) {
> - if (!cpuc->lbr_entries[i].from) {
> + if (cpuc->lbr_entries[i].__delete) {
> j = i;
> while (++j < cpuc->lbr_stack.nr)
> cpuc->lbr_entries[j-1] = cpuc->lbr_entries[j];
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index f463a46..7acf1c9 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -77,9 +77,13 @@ struct perf_raw_record {
> struct perf_branch_entry {
> __u64 from;
> __u64 to;
> - __u64 mispred:1, /* target mispredicted */
> - predicted:1,/* target predicted */
> - reserved:62;
> + __u64 mispred:1, /* target mispredicted */
> + predicted:1, /* target predicted */
> + invalid_to:1, /* @to isn't to be trusted */
> + invalid_from:1, /* @from isn't to be trusted */
Thanks Peter. One possible issue...
When the kernel has to read the branch from memory, there is no way for
it to know that it's the same one that the HW actually executed. Hence
there's a possibility that the to address is invalid but we can't tell
for sure.
I'm happy to just ignore that and mark calculated to address as valid,
unless you think it would be worthwhile extra information to pass onto
the user?
If we wanted this extra fidelity we could add a possibly_invalid_to:1
flag to your patch but I'm not sure it's worth it to be honest.
mikey
^ permalink raw reply
* Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
From: Michael Neuling @ 2013-05-16 10:15 UTC (permalink / raw)
To: Peter Zijlstra
Cc: ak@linux.intel.com, LKML, Stephane Eranian, Linux PPC dev,
Ingo Molnar
In-Reply-To: <20130516090916.GF19669@dyad.programming.kicks-ass.net>
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, May 15, 2013 at 03:37:22PM +0200, Stephane Eranian wrote:
> > On Fri, May 3, 2013 at 2:11 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > > We should always have proper privileges when requesting kernel data.
> > >
> > > Cc: Andi Kleen <ak@linux.intel.com>
> > > Cc: eranian@google.com
> > > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > > Link: http://lkml.kernel.org/n/tip-v0x9ky3ahzr6nm3c6ilwrili@git.kernel.org
> > > ---
> > > arch/x86/kernel/cpu/perf_event_intel_lbr.c | 5 ++++-
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> > > +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> > > @@ -318,8 +318,11 @@ static void intel_pmu_setup_sw_lbr_filte
> > > if (br_type & PERF_SAMPLE_BRANCH_USER)
> > > mask |= X86_BR_USER;
> > >
> > > - if (br_type & PERF_SAMPLE_BRANCH_KERNEL)
> > > + if (br_type & PERF_SAMPLE_BRANCH_KERNEL) {
> > > + if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
> > > + return -EACCES;
> > > mask |= X86_BR_KERNEL;
> > > + }
> > >
> > This will prevent regular users from capturing kernel -> kernel branches.
> > But it won't prevent users from getting kernel -> user branches. Thus
> > some kernel address will still be captured. I guess they could be eliminated
> > by the sw_filter.
> >
> > When using LBR priv level filtering, the filter applies to the branch target
> > only.
>
> How about something like the below? It also adds the branch flags
> Mikey wanted for PowerPC.
Peter,
BTW PowerPC also has the ability to filter on conditional branches. Any
chance we could add something like the follow to perf also?
Mikey
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index fb104e5..891c769 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -157,8 +157,9 @@ enum perf_branch_sample_type {
PERF_SAMPLE_BRANCH_ANY_CALL = 1U << 4, /* any call branch */
PERF_SAMPLE_BRANCH_ANY_RETURN = 1U << 5, /* any return branch */
PERF_SAMPLE_BRANCH_IND_CALL = 1U << 6, /* indirect calls */
+ PERF_SAMPLE_BRANCH_CONDITIONAL = 1U << 7, /* conditional branches */
- PERF_SAMPLE_BRANCH_MAX = 1U << 7, /* non-ABI */
+ PERF_SAMPLE_BRANCH_MAX = 1U << 8, /* non-ABI */
};
#define PERF_SAMPLE_BRANCH_PLM_ALL \
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index cdf58ec..5b0b89d 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -676,6 +676,7 @@ static const struct branch_mode branch_modes[] = {
BRANCH_OPT("any_call", PERF_SAMPLE_BRANCH_ANY_CALL),
BRANCH_OPT("any_ret", PERF_SAMPLE_BRANCH_ANY_RETURN),
BRANCH_OPT("ind_call", PERF_SAMPLE_BRANCH_IND_CALL),
+ BRANCH_OPT("cnd", PERF_SAMPLE_BRANCH_CONDITIONAL),
BRANCH_END
};
^ permalink raw reply related
* [RFC PATCH powerpc] Set cpu sibling mask before online cpu
From: Li Zhong @ 2013-05-16 10:20 UTC (permalink / raw)
To: PowerPC email list; +Cc: Paul Mackerras
It seems following race is possible:
cpu0 cpux
smp_init->cpu_up->_cpu_up
__cpu_up
kick_cpu(1)
-------------------------------------------------------------------------
waiting online ...
... notify CPU_STARTING
set cpux active
set cpux online
-------------------------------------------------------------------------
finish waiting online
...
sched_init_smp
init_sched_domains(cpu_active_mask)
build_sched_domains
set cpux sibling info
-------------------------------------------------------------------------
Execution of cpu0 and cpux could be concurrent between two separator
lines.
So if the cpux sibling information was set too late (normally
impossible, but could be triggered by adding some delay in
start_secondary, after setting cpu online), build_sched_domains()
running on cpu0 might see cpux active, with an empty sibling mask, then
cause some bad address accessing like following:
[ 0.099855] Unable to handle kernel paging request for data at address 0xc00000038518078f
[ 0.099868] Faulting instruction address: 0xc0000000000b7a64
[ 0.099883] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.099895] PREEMPT SMP NR_CPUS=16 DEBUG_PAGEALLOC NUMA pSeries
[ 0.099922] Modules linked in:
[ 0.099940] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc1-00120-gb973425-dirty #16
[ 0.099956] task: c0000001fed80000 ti: c0000001fed7c000 task.ti: c0000001fed7c000
[ 0.099971] NIP: c0000000000b7a64 LR: c0000000000b7a40 CTR: c0000000000b4934
[ 0.099985] REGS: c0000001fed7f760 TRAP: 0300 Not tainted (3.10.0-rc1-00120-gb973425-dirty)
[ 0.099997] MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24272828 XER: 20000003
[ 0.100045] SOFTE: 1
[ 0.100053] CFAR: c000000000445ee8
[ 0.100064] DAR: c00000038518078f, DSISR: 40000000
[ 0.100073]
GPR00: 0000000000000080 c0000001fed7f9e0 c000000000c84d48 0000000000000010
GPR04: 0000000000000010 0000000000000000 c0000001fc55e090 0000000000000000
GPR08: ffffffffffffffff c000000000b80b30 c000000000c962d8 00000003845ffc5f
GPR12: 0000000000000000 c00000000f33d000 c00000000000b9e4 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000001 0000000000000000
GPR20: c000000000ccf750 0000000000000000 c000000000c94d48 c0000001fc504000
GPR24: c0000001fc504000 c0000001fecef848 c000000000c94d48 c000000000ccf000
GPR28: c0000001fc522090 0000000000000010 c0000001fecef848 c0000001fed7fae0
[ 0.100293] NIP [c0000000000b7a64] .get_group+0x84/0xc4
[ 0.100307] LR [c0000000000b7a40] .get_group+0x60/0xc4
[ 0.100318] Call Trace:
[ 0.100332] [c0000001fed7f9e0] [c0000000000dbce4] .lock_is_held+0xa8/0xd0 (unreliable)
[ 0.100354] [c0000001fed7fa70] [c0000000000bf62c] .build_sched_domains+0x728/0xd14
[ 0.100375] [c0000001fed7fbe0] [c000000000af67bc] .sched_init_smp+0x4fc/0x654
[ 0.100394] [c0000001fed7fce0] [c000000000adce24] .kernel_init_freeable+0x17c/0x30c
[ 0.100413] [c0000001fed7fdb0] [c00000000000ba08] .kernel_init+0x24/0x12c
[ 0.100431] [c0000001fed7fe30] [c000000000009f74] .ret_from_kernel_thread+0x5c/0x68
[ 0.100445] Instruction dump:
[ 0.100456] 38800010 38a00000 4838e3f5 60000000 7c6307b4 2fbf0000 419e0040 3d220001
[ 0.100496] 78601f24 39491590 e93e0008 7d6a002a <7d69582a> f97f0000 7d4a002a e93e0010
[ 0.100559] ---[ end trace 31fd0ba7d8756001 ]---
This patch tries to move the sibling maps updating before
notify_cpu_starting() and cpu online, and a write barrier there to make
sure sibling maps are updated before active and online mask.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/kernel/smp.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index ee7ac5e..c765937 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -637,12 +637,10 @@ __cpuinit void start_secondary(void *unused)
vdso_getcpu_init();
#endif
- notify_cpu_starting(cpu);
- set_cpu_online(cpu, true);
/* Update sibling maps */
base = cpu_first_thread_sibling(cpu);
for (i = 0; i < threads_per_core; i++) {
- if (cpu_is_offline(base + i))
+ if (cpu_is_offline(base + i) && (cpu != base + i))
continue;
cpumask_set_cpu(cpu, cpu_sibling_mask(base + i));
cpumask_set_cpu(base + i, cpu_sibling_mask(cpu));
@@ -667,6 +665,10 @@ __cpuinit void start_secondary(void *unused)
}
of_node_put(l2_cache);
+ smp_wmb();
+ notify_cpu_starting(cpu);
+ set_cpu_online(cpu, true);
+
local_irq_enable();
cpu_startup_entry(CPUHP_ONLINE);
^ permalink raw reply related
* [PATCH v2 00/10] uaccess: better might_sleep/might_fault behavior
From: Michael S. Tsirkin @ 2013-05-16 11:07 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, Koichi Yasutake,
linuxppc-dev
This improves the might_fault annotations used
by uaccess routines:
1. The only reason uaccess routines might sleep
is if they fault. Make this explicit for
all architectures.
2. Accesses (e.g through socket ops) to kernel memory
with KERNEL_DS like net/sunrpc does will never sleep.
Remove an unconditinal might_sleep in the inline
might_fault in kernel.h
(used when PROVE_LOCKING is not set).
3. Accesses with pagefault_disable return EFAULT
but won't cause caller to sleep.
Check for that and avoid might_sleep when
PROVE_LOCKING is set.
I'd like these changes to go in for the benefit of
the vhost driver where we want to call socket ops
under a spinlock, and fall back on slower thread handler
on error.
Please review, and consider for 3.11.
If the changes look good, what's the best way to merge them?
Maybe core/locking makes sense?
Note on arch code updates:
I tested x86_64 code.
Other architectures were build-tested.
I don't have cross-build environment for arm64, tile, microblaze and
mn10300 architectures. The changes look safe enough
but would appreciate review/acks from arch maintainers.
Version 1 of this change was titled
x86: uaccess s/might_sleep/might_fault/
Changes from v1:
add more architectures
fix might_fault() scheduling differently depending
on CONFIG_PROVE_LOCKING, as suggested by Ingo
Michael S. Tsirkin (10):
asm-generic: uaccess s/might_sleep/might_fault/
arm64: uaccess s/might_sleep/might_fault/
frv: uaccess s/might_sleep/might_fault/
m32r: uaccess s/might_sleep/might_fault/
microblaze: uaccess s/might_sleep/might_fault/
mn10300: uaccess s/might_sleep/might_fault/
powerpc: uaccess s/might_sleep/might_fault/
tile: uaccess s/might_sleep/might_fault/
x86: uaccess s/might_sleep/might_fault/
kernel: might_fault does not imply might_sleep
arch/arm64/include/asm/uaccess.h | 4 ++--
arch/frv/include/asm/uaccess.h | 4 ++--
arch/m32r/include/asm/uaccess.h | 12 ++++++------
arch/microblaze/include/asm/uaccess.h | 6 +++---
arch/mn10300/include/asm/uaccess.h | 4 ++--
arch/powerpc/include/asm/uaccess.h | 16 ++++++++--------
arch/tile/include/asm/uaccess.h | 2 +-
arch/x86/include/asm/uaccess_64.h | 2 +-
include/asm-generic/uaccess.h | 10 +++++-----
include/linux/kernel.h | 1 -
mm/memory.c | 14 +++++++++-----
11 files changed, 39 insertions(+), 36 deletions(-)
Thanks,
--
MST
^ permalink raw reply
* [PATCH v2 02/10] arm64: uaccess s/might_sleep/might_fault/
From: Michael S. Tsirkin @ 2013-05-16 11:10 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, Koichi Yasutake,
linuxppc-dev
In-Reply-To: <cover.1368702323.git.mst@redhat.com>
The only reason uaccess routines might sleep
is if they fault. Make this explicit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/arm64/include/asm/uaccess.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 008f848..edb3d5c 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -166,7 +166,7 @@ do { \
#define get_user(x, ptr) \
({ \
- might_sleep(); \
+ might_fault(); \
access_ok(VERIFY_READ, (ptr), sizeof(*(ptr))) ? \
__get_user((x), (ptr)) : \
((x) = 0, -EFAULT); \
@@ -227,7 +227,7 @@ do { \
#define put_user(x, ptr) \
({ \
- might_sleep(); \
+ might_fault(); \
access_ok(VERIFY_WRITE, (ptr), sizeof(*(ptr))) ? \
__put_user((x), (ptr)) : \
-EFAULT; \
--
MST
^ permalink raw reply related
* [PATCH v2 03/10] frv: uaccess s/might_sleep/might_fault/
From: Michael S. Tsirkin @ 2013-05-16 11:10 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, Koichi Yasutake,
linuxppc-dev
In-Reply-To: <cover.1368702323.git.mst@redhat.com>
The only reason uaccess routines might sleep
is if they fault. Make this explicit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/frv/include/asm/uaccess.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/frv/include/asm/uaccess.h b/arch/frv/include/asm/uaccess.h
index 0b67ec5..3ac9a59 100644
--- a/arch/frv/include/asm/uaccess.h
+++ b/arch/frv/include/asm/uaccess.h
@@ -280,14 +280,14 @@ extern long __memcpy_user(void *dst, const void *src, unsigned long count);
static inline unsigned long __must_check
__copy_to_user(void __user *to, const void *from, unsigned long n)
{
- might_sleep();
+ might_fault();
return __copy_to_user_inatomic(to, from, n);
}
static inline unsigned long
__copy_from_user(void *to, const void __user *from, unsigned long n)
{
- might_sleep();
+ might_fault();
return __copy_from_user_inatomic(to, from, n);
}
--
MST
^ permalink raw reply related
* [PATCH v2 04/10] m32r: uaccess s/might_sleep/might_fault/
From: Michael S. Tsirkin @ 2013-05-16 11:11 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, Koichi Yasutake,
linuxppc-dev
In-Reply-To: <cover.1368702323.git.mst@redhat.com>
The only reason uaccess routines might sleep
is if they fault. Make this explicit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/m32r/include/asm/uaccess.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/m32r/include/asm/uaccess.h b/arch/m32r/include/asm/uaccess.h
index 1c7047b..84fe7ba 100644
--- a/arch/m32r/include/asm/uaccess.h
+++ b/arch/m32r/include/asm/uaccess.h
@@ -216,7 +216,7 @@ extern int fixup_exception(struct pt_regs *regs);
({ \
long __gu_err = 0; \
unsigned long __gu_val; \
- might_sleep(); \
+ might_fault(); \
__get_user_size(__gu_val,(ptr),(size),__gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
@@ -227,7 +227,7 @@ extern int fixup_exception(struct pt_regs *regs);
long __gu_err = -EFAULT; \
unsigned long __gu_val = 0; \
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
- might_sleep(); \
+ might_fault(); \
if (access_ok(VERIFY_READ,__gu_addr,size)) \
__get_user_size(__gu_val,__gu_addr,(size),__gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
@@ -295,7 +295,7 @@ do { \
#define __put_user_nocheck(x,ptr,size) \
({ \
long __pu_err; \
- might_sleep(); \
+ might_fault(); \
__put_user_size((x),(ptr),(size),__pu_err); \
__pu_err; \
})
@@ -305,7 +305,7 @@ do { \
({ \
long __pu_err = -EFAULT; \
__typeof__(*(ptr)) __user *__pu_addr = (ptr); \
- might_sleep(); \
+ might_fault(); \
if (access_ok(VERIFY_WRITE,__pu_addr,size)) \
__put_user_size((x),__pu_addr,(size),__pu_err); \
__pu_err; \
@@ -597,7 +597,7 @@ unsigned long __generic_copy_from_user(void *, const void __user *, unsigned lon
*/
#define copy_to_user(to,from,n) \
({ \
- might_sleep(); \
+ might_fault(); \
__generic_copy_to_user((to),(from),(n)); \
})
@@ -638,7 +638,7 @@ unsigned long __generic_copy_from_user(void *, const void __user *, unsigned lon
*/
#define copy_from_user(to,from,n) \
({ \
- might_sleep(); \
+ might_fault(); \
__generic_copy_from_user((to),(from),(n)); \
})
--
MST
^ permalink raw reply related
* [PATCH v2 05/10] microblaze: uaccess s/might_sleep/might_fault/
From: Michael S. Tsirkin @ 2013-05-16 11:11 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, Koichi Yasutake,
linuxppc-dev
In-Reply-To: <cover.1368702323.git.mst@redhat.com>
The only reason uaccess routines might sleep
is if they fault. Make this explicit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/microblaze/include/asm/uaccess.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/microblaze/include/asm/uaccess.h b/arch/microblaze/include/asm/uaccess.h
index efe59d8..2fc8bf7 100644
--- a/arch/microblaze/include/asm/uaccess.h
+++ b/arch/microblaze/include/asm/uaccess.h
@@ -145,7 +145,7 @@ static inline unsigned long __must_check __clear_user(void __user *to,
static inline unsigned long __must_check clear_user(void __user *to,
unsigned long n)
{
- might_sleep();
+ might_fault();
if (unlikely(!access_ok(VERIFY_WRITE, to, n)))
return n;
@@ -371,7 +371,7 @@ extern long __user_bad(void);
static inline long copy_from_user(void *to,
const void __user *from, unsigned long n)
{
- might_sleep();
+ might_fault();
if (access_ok(VERIFY_READ, from, n))
return __copy_from_user(to, from, n);
return n;
@@ -385,7 +385,7 @@ static inline long copy_from_user(void *to,
static inline long copy_to_user(void __user *to,
const void *from, unsigned long n)
{
- might_sleep();
+ might_fault();
if (access_ok(VERIFY_WRITE, to, n))
return __copy_to_user(to, from, n);
return n;
--
MST
^ permalink raw reply related
* [PATCH v2 06/10] mn10300: uaccess s/might_sleep/might_fault/
From: Michael S. Tsirkin @ 2013-05-16 11:12 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, Koichi Yasutake,
linuxppc-dev
In-Reply-To: <cover.1368702323.git.mst@redhat.com>
The only reason uaccess routines might sleep
is if they fault. Make this explicit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/mn10300/include/asm/uaccess.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mn10300/include/asm/uaccess.h b/arch/mn10300/include/asm/uaccess.h
index 780560b..107508a 100644
--- a/arch/mn10300/include/asm/uaccess.h
+++ b/arch/mn10300/include/asm/uaccess.h
@@ -471,13 +471,13 @@ extern unsigned long __generic_copy_from_user(void *, const void __user *,
#define __copy_to_user(to, from, n) \
({ \
- might_sleep(); \
+ might_fault(); \
__copy_to_user_inatomic((to), (from), (n)); \
})
#define __copy_from_user(to, from, n) \
({ \
- might_sleep(); \
+ might_fault(); \
__copy_from_user_inatomic((to), (from), (n)); \
})
--
MST
^ permalink raw reply related
* [PATCH v2 01/10] asm-generic: uaccess s/might_sleep/might_fault/
From: Michael S. Tsirkin @ 2013-05-16 11:10 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, Koichi Yasutake,
linuxppc-dev
In-Reply-To: <cover.1368702323.git.mst@redhat.com>
The only reason uaccess routines might sleep
is if they fault. Make this explicit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/asm-generic/uaccess.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/asm-generic/uaccess.h b/include/asm-generic/uaccess.h
index c184aa8..dc1269c 100644
--- a/include/asm-generic/uaccess.h
+++ b/include/asm-generic/uaccess.h
@@ -163,7 +163,7 @@ static inline __must_check long __copy_to_user(void __user *to,
#define put_user(x, ptr) \
({ \
- might_sleep(); \
+ might_fault(); \
access_ok(VERIFY_WRITE, ptr, sizeof(*ptr)) ? \
__put_user(x, ptr) : \
-EFAULT; \
@@ -225,7 +225,7 @@ extern int __put_user_bad(void) __attribute__((noreturn));
#define get_user(x, ptr) \
({ \
- might_sleep(); \
+ might_fault(); \
access_ok(VERIFY_READ, ptr, sizeof(*ptr)) ? \
__get_user(x, ptr) : \
-EFAULT; \
@@ -255,7 +255,7 @@ extern int __get_user_bad(void) __attribute__((noreturn));
static inline long copy_from_user(void *to,
const void __user * from, unsigned long n)
{
- might_sleep();
+ might_fault();
if (access_ok(VERIFY_READ, from, n))
return __copy_from_user(to, from, n);
else
@@ -265,7 +265,7 @@ static inline long copy_from_user(void *to,
static inline long copy_to_user(void __user *to,
const void *from, unsigned long n)
{
- might_sleep();
+ might_fault();
if (access_ok(VERIFY_WRITE, to, n))
return __copy_to_user(to, from, n);
else
@@ -336,7 +336,7 @@ __clear_user(void __user *to, unsigned long n)
static inline __must_check unsigned long
clear_user(void __user *to, unsigned long n)
{
- might_sleep();
+ might_fault();
if (!access_ok(VERIFY_WRITE, to, n))
return n;
--
MST
^ permalink raw reply related
* Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
From: Peter Zijlstra @ 2013-05-16 11:16 UTC (permalink / raw)
To: Michael Neuling
Cc: ak@linux.intel.com, LKML, Stephane Eranian, Linux PPC dev,
Ingo Molnar
In-Reply-To: <8578.1368699317@ale.ozlabs.ibm.com>
On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
> Peter,
>
> BTW PowerPC also has the ability to filter on conditional branches. Any
> chance we could add something like the follow to perf also?
>
I don't see an immediate problem with that except that we on x86 need to
implement that in the software filter. Stephane do you see any
fundamental issue with that?
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index fb104e5..891c769 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -157,8 +157,9 @@ enum perf_branch_sample_type {
> PERF_SAMPLE_BRANCH_ANY_CALL = 1U << 4, /* any call branch */
> PERF_SAMPLE_BRANCH_ANY_RETURN = 1U << 5, /* any return branch */
> PERF_SAMPLE_BRANCH_IND_CALL = 1U << 6, /* indirect calls */
> + PERF_SAMPLE_BRANCH_CONDITIONAL = 1U << 7, /* conditional branches */
>
> - PERF_SAMPLE_BRANCH_MAX = 1U << 7, /* non-ABI */
> + PERF_SAMPLE_BRANCH_MAX = 1U << 8, /* non-ABI */
> };
>
> #define PERF_SAMPLE_BRANCH_PLM_ALL \
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index cdf58ec..5b0b89d 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -676,6 +676,7 @@ static const struct branch_mode branch_modes[] = {
> BRANCH_OPT("any_call", PERF_SAMPLE_BRANCH_ANY_CALL),
> BRANCH_OPT("any_ret", PERF_SAMPLE_BRANCH_ANY_RETURN),
> BRANCH_OPT("ind_call", PERF_SAMPLE_BRANCH_IND_CALL),
> + BRANCH_OPT("cnd", PERF_SAMPLE_BRANCH_CONDITIONAL),
> BRANCH_END
> };
>
^ permalink raw reply
* [PATCH v2 07/10] powerpc: uaccess s/might_sleep/might_fault/
From: Michael S. Tsirkin @ 2013-05-16 11:15 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, Koichi Yasutake,
linuxppc-dev
In-Reply-To: <cover.1368702323.git.mst@redhat.com>
The only reason uaccess routines might sleep
is if they fault. Make this explicit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/powerpc/include/asm/uaccess.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index 4db4959..9485b43 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -178,7 +178,7 @@ do { \
long __pu_err; \
__typeof__(*(ptr)) __user *__pu_addr = (ptr); \
if (!is_kernel_addr((unsigned long)__pu_addr)) \
- might_sleep(); \
+ might_fault(); \
__chk_user_ptr(ptr); \
__put_user_size((x), __pu_addr, (size), __pu_err); \
__pu_err; \
@@ -188,7 +188,7 @@ do { \
({ \
long __pu_err = -EFAULT; \
__typeof__(*(ptr)) __user *__pu_addr = (ptr); \
- might_sleep(); \
+ might_fault(); \
if (access_ok(VERIFY_WRITE, __pu_addr, size)) \
__put_user_size((x), __pu_addr, (size), __pu_err); \
__pu_err; \
@@ -268,7 +268,7 @@ do { \
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
__chk_user_ptr(ptr); \
if (!is_kernel_addr((unsigned long)__gu_addr)) \
- might_sleep(); \
+ might_fault(); \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
@@ -282,7 +282,7 @@ do { \
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
__chk_user_ptr(ptr); \
if (!is_kernel_addr((unsigned long)__gu_addr)) \
- might_sleep(); \
+ might_fault(); \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
@@ -294,7 +294,7 @@ do { \
long __gu_err = -EFAULT; \
unsigned long __gu_val = 0; \
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
- might_sleep(); \
+ might_fault(); \
if (access_ok(VERIFY_READ, __gu_addr, (size))) \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
@@ -419,14 +419,14 @@ static inline unsigned long __copy_to_user_inatomic(void __user *to,
static inline unsigned long __copy_from_user(void *to,
const void __user *from, unsigned long size)
{
- might_sleep();
+ might_fault();
return __copy_from_user_inatomic(to, from, size);
}
static inline unsigned long __copy_to_user(void __user *to,
const void *from, unsigned long size)
{
- might_sleep();
+ might_fault();
return __copy_to_user_inatomic(to, from, size);
}
@@ -434,7 +434,7 @@ extern unsigned long __clear_user(void __user *addr, unsigned long size);
static inline unsigned long clear_user(void __user *addr, unsigned long size)
{
- might_sleep();
+ might_fault();
if (likely(access_ok(VERIFY_WRITE, addr, size)))
return __clear_user(addr, size);
if ((unsigned long)addr < TASK_SIZE) {
--
MST
^ permalink raw reply related
* [PATCH v2 08/10] tile: uaccess s/might_sleep/might_fault/
From: Michael S. Tsirkin @ 2013-05-16 11:15 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, Koichi Yasutake,
linuxppc-dev
In-Reply-To: <cover.1368702323.git.mst@redhat.com>
The only reason uaccess routines might sleep
is if they fault. Make this explicit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/tile/include/asm/uaccess.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/tile/include/asm/uaccess.h b/arch/tile/include/asm/uaccess.h
index 8a082bc..e4d44bd 100644
--- a/arch/tile/include/asm/uaccess.h
+++ b/arch/tile/include/asm/uaccess.h
@@ -442,7 +442,7 @@ extern unsigned long __copy_in_user_inatomic(
static inline unsigned long __must_check
__copy_in_user(void __user *to, const void __user *from, unsigned long n)
{
- might_sleep();
+ might_fault();
return __copy_in_user_inatomic(to, from, n);
}
--
MST
^ permalink raw reply related
* [PATCH v2 09/10] x86: uaccess s/might_sleep/might_fault/
From: Michael S. Tsirkin @ 2013-05-16 11:15 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, Koichi Yasutake,
linuxppc-dev
In-Reply-To: <cover.1368702323.git.mst@redhat.com>
The only reason uaccess routines might sleep
is if they fault. Make this explicit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
---
arch/x86/include/asm/uaccess_64.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/uaccess_64.h b/arch/x86/include/asm/uaccess_64.h
index 142810c..4f7923d 100644
--- a/arch/x86/include/asm/uaccess_64.h
+++ b/arch/x86/include/asm/uaccess_64.h
@@ -235,7 +235,7 @@ extern long __copy_user_nocache(void *dst, const void __user *src,
static inline int
__copy_from_user_nocache(void *dst, const void __user *src, unsigned size)
{
- might_sleep();
+ might_fault();
return __copy_user_nocache(dst, src, size, 1);
}
--
MST
^ permalink raw reply related
* [PATCH v2 10/10] kernel: might_fault does not imply might_sleep
From: Michael S. Tsirkin @ 2013-05-16 11:16 UTC (permalink / raw)
To: linux-kernel
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, Koichi Yasutake,
linuxppc-dev
In-Reply-To: <cover.1368702323.git.mst@redhat.com>
There are several ways to make sure might_fault
calling function does not sleep.
One is to use it on kernel or otherwise locked memory - apparently
nfs/sunrpc does this. As noted by Ingo, this is handled by the
migh_fault() implementation in mm/memory.c but not the one in
linux/kernel.h so in the current code might_fault() schedules
differently depending on CONFIG_PROVE_LOCKING, which is an undesired
semantical side effect.
Another is to call pagefault_disable: in this case the page fault
handler will go to fixups processing and we get an error instead of
sleeping, so the might_sleep annotation is a false positive.
vhost driver wants to do this now in order to reuse socket ops
under a spinlock (and fall back on slower thread handler
on error).
Address both issues by:
- dropping the unconditional call to might_sleep
from the fast might_fault code in linux/kernel.h
- checking for pagefault_disable() in the
CONFIG_PROVE_LOCKING implementation
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/linux/kernel.h | 1 -
mm/memory.c | 14 +++++++++-----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index e96329c..322b065 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -198,7 +198,6 @@ void might_fault(void);
#else
static inline void might_fault(void)
{
- might_sleep();
}
#endif
diff --git a/mm/memory.c b/mm/memory.c
index 6dc1882..1b8327b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4222,13 +4222,17 @@ void might_fault(void)
if (segment_eq(get_fs(), KERNEL_DS))
return;
- might_sleep();
/*
- * it would be nicer only to annotate paths which are not under
- * pagefault_disable, however that requires a larger audit and
- * providing helpers like get_user_atomic.
+ * It would be nicer to annotate paths which are under preempt_disable
+ * but not under pagefault_disable, however that requires a new flag
+ * for differentiating between the two.
*/
- if (!in_atomic() && current->mm)
+ if (in_atomic())
+ return;
+
+ might_sleep();
+
+ if (current->mm)
might_lock_read(¤t->mm->mmap_sem);
}
EXPORT_SYMBOL(might_fault);
--
MST
^ permalink raw reply related
* Re: [PATCH v2 02/10] arm64: uaccess s/might_sleep/might_fault/
From: Catalin Marinas @ 2013-05-16 13:29 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-m32r-ja, kvm@vger.kernel.org, Peter Zijlstra, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch@vger.kernel.org, linux-am33-list, Hirokazu Takata, x86,
Ingo Molnar, Arnd Bergmann, microblaze-uclinux, Chris Metcalf,
Thomas Gleixner, linux-arm-kernel@lists.infradead.org,
Michal Simek, linux-m32r, Linux Kernel Mailing List,
Koichi Yasutake, linuxppc-dev
In-Reply-To: <90a2283bb84b6ce77c9966d76dbceb5c7edffd18.1368702323.git.mst@redhat.com>
On 16 May 2013 12:10, Michael S. Tsirkin <mst@redhat.com> wrote:
> The only reason uaccess routines might sleep
> is if they fault. Make this explicit.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/arm64/include/asm/uaccess.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
For arm64:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH v2 08/10] tile: uaccess s/might_sleep/might_fault/
From: Chris Metcalf @ 2013-05-16 13:33 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-m32r-ja, kvm, Peter Zijlstra, Catalin Marinas, Will Deacon,
David Howells, linux-mm, Paul Mackerras, H. Peter Anvin,
linux-arch, linux-am33-list, Hirokazu Takata, x86, Ingo Molnar,
Arnd Bergmann, microblaze-uclinux, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, linux-kernel,
Koichi Yasutake, linuxppc-dev
In-Reply-To: <018bba1e097552bc4054e6d90e3f03e7c9a632bb.1368702323.git.mst@redhat.com>
On 5/16/2013 7:15 AM, Michael S. Tsirkin wrote:
> The only reason uaccess routines might sleep
> is if they fault. Make this explicit.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/tile/include/asm/uaccess.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Chris Metcalf <cmetcalf@tilera.com>
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* [PATCH] can: flexcan: allow compilation on arm and powerpc
From: Marc Kleine-Budde @ 2013-05-16 13:42 UTC (permalink / raw)
To: linux-kernel
Cc: Arnd Bergmann, Sascha Hauer, U Bhaskar-B22300, linux-can,
Marc Kleine-Budde, Shawn Guo, linuxppc-dev, linux-arm-kernel
This patch removes the Kconfig symbols HAVE_CAN_FLEXCAN and
IMX_HAVE_PLATFORM_FLEXCAN from arch/{arm,powerpc} and allowing compilation on
all arm and powerpc platforms.
This brings a bigger compile time coverage and removes the following dependency
warning found by Arnd Bergmann:
warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 && IMX_HAVE_PLATFORM_FLEXCAN &&
SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
which has unmet direct dependencies (NET && CAN && CAN_DEV)
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: U Bhaskar-B22300 <B22300@freescale.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Hello,
if the arm and powerpc people are okay with this, I'm taking this patch (and
then will go upstream via David Miller's net-next).
regards,
Marc
arch/arm/mach-imx/Kconfig | 8 --------
arch/arm/mach-imx/devices/Kconfig | 4 ----
arch/arm/mach-mxs/Kconfig | 1 -
arch/powerpc/Kconfig | 1 -
drivers/net/can/Kconfig | 5 +----
5 files changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ba44328..239d084 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -111,7 +111,6 @@ config SOC_IMX25
select ARCH_MXC_IOMUX_V3
select COMMON_CLK
select CPU_ARM926T
- select HAVE_CAN_FLEXCAN if CAN
select MXC_AVIC
config SOC_IMX27
@@ -137,7 +136,6 @@ config SOC_IMX35
select ARCH_MXC_IOMUX_V3
select COMMON_CLK
select CPU_V6K
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_EPIT
select MXC_AVIC
select SMP_ON_UP if SMP
@@ -208,7 +206,6 @@ comment "MX25 platforms:"
config MACH_MX25_3DS
bool "Support MX25PDK (3DS) Platform"
- select IMX_HAVE_PLATFORM_FLEXCAN
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
select IMX_HAVE_PLATFORM_IMXDI_RTC
@@ -223,7 +220,6 @@ config MACH_MX25_3DS
config MACH_EUKREA_CPUIMX25SD
bool "Support Eukrea CPUIMX25 Platform"
- select IMX_HAVE_PLATFORM_FLEXCAN
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
select IMX_HAVE_PLATFORM_IMXDI_RTC
@@ -629,7 +625,6 @@ comment "MX35 platforms:"
config MACH_PCM043
bool "Support Phytec pcm043 (i.MX35) platforms"
- select IMX_HAVE_PLATFORM_FLEXCAN
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
select IMX_HAVE_PLATFORM_IMX_I2C
@@ -665,7 +660,6 @@ config MACH_MX35_3DS
config MACH_EUKREA_CPUIMX35SD
bool "Support Eukrea CPUIMX35 Platform"
- select IMX_HAVE_PLATFORM_FLEXCAN
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
select IMX_HAVE_PLATFORM_IMX_I2C
@@ -776,7 +770,6 @@ comment "Device tree only"
config SOC_IMX53
bool "i.MX53 support"
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_SRC
select IMX_HAVE_PLATFORM_IMX2_WDT
select PINCTRL
@@ -799,7 +792,6 @@ config SOC_IMX6Q
select CPU_V7
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if LOCAL_TIMERS
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_ANATOP
select HAVE_IMX_GPC
select HAVE_IMX_MMDC
diff --git a/arch/arm/mach-imx/devices/Kconfig b/arch/arm/mach-imx/devices/Kconfig
index 3dd2b1b..b0a629d 100644
--- a/arch/arm/mach-imx/devices/Kconfig
+++ b/arch/arm/mach-imx/devices/Kconfig
@@ -2,10 +2,6 @@ config IMX_HAVE_PLATFORM_FEC
bool
default y if ARCH_MX25 || SOC_IMX27 || SOC_IMX35 || SOC_IMX51 || SOC_IMX53
-config IMX_HAVE_PLATFORM_FLEXCAN
- bool
- select HAVE_CAN_FLEXCAN if CAN
-
config IMX_HAVE_PLATFORM_FSL_USB2_UDC
bool
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index 4dc2fbb..ce6e7d6 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -11,7 +11,6 @@ config SOC_IMX28
select ARM_AMBA
select ARM_CPU_SUSPEND if PM
select CPU_ARM926T
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_PWM
select PINCTRL_IMX28
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..7754c6b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -674,7 +674,6 @@ config SBUS
config FSL_SOC
bool
- select HAVE_CAN_FLEXCAN if NET && CAN
config FSL_PCI
bool
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index e456b70..3c06947 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -102,12 +102,9 @@ config CAN_JANZ_ICAN3
This driver can also be built as a module. If so, the module will be
called janz-ican3.ko.
-config HAVE_CAN_FLEXCAN
- bool
-
config CAN_FLEXCAN
tristate "Support for Freescale FLEXCAN based chips"
- depends on HAVE_CAN_FLEXCAN
+ depends on ARM || PPC
---help---
Say Y here if you want to support for Freescale FlexCAN.
--
1.8.2.rc2
^ permalink raw reply related
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