From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Leonard Crestez To: "sboyd@codeaurora.org" CC: "linux-kernel@vger.kernel.org" , "mturquette@baylibre.com" , "linux-clk@vger.kernel.org" Subject: Re: [PATCH] clk: core: Copy connection id Date: Sat, 25 Feb 2017 09:20:02 +0000 Message-ID: <1488014402.6461.3.camel@nxp.com> References: <60d115f6c11bc51cd8bc10c64cd222c3cdb43cc7.1487596492.git.leonard.crestez@nxp.com> <20170224204439.GD25384@codeaurora.org> In-Reply-To: <20170224204439.GD25384@codeaurora.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 List-ID: T24gRnJpLCAyMDE3LTAyLTI0IGF0IDEyOjQ0IC0wODAwLCBTdGVwaGVuIEJveWQgd3JvdGU6DQo+ IE9uIDAyLzIwLCBMZW9uYXJkIENyZXN0ZXogd3JvdGU6DQo+ID4gU29tZSBkcml2ZXJzIHVzZSBz cHJpbnRmIHRvIGJ1aWxkIGNsayBjb25uZWN0aW9uIGlkIG5hbWVzIGJ1dCB0aGUNCj4gPiBjbGsN Cj4gPiBjb3JlIHdpbGwgc2F2ZSB0aG9zZSBzdHJpbmdzIGFuZCBvY2Nhc2lvbmFsbHkgcHJpbnQg dGhlbSBiYWNrLg0KPiA+IER1cGxpY2F0ZQ0KPiA+IHRoZSBjb25faWQgc3RyaW5ncyBpbnN0ZWFk IG9mIGZpeGluZyBhbGwgdGhlIHVzZXJzLg0KPiANCj4gR29vZCBjYXRjaC4gV2hhdCBhYm91dCBk ZXZfaWQgdGhvdWdoPyBUaGF0IGNvdWxkIGFsc28gaGF2ZSB0aGUNCj4gc2FtZSBwcm9ibGVtIGlm IHNvbWUgZGV2aWNlIGlzIHJlbW92ZWQgYW5kIHdlJ3JlIHN0aWxsIGhvbGRpbmcgYQ0KPiByZWZl cmVuY2UgdG8gdGhlIGtvYmplY3QncyBuYW1lLiBUaGlzIGlzIHByb2JhYmx5IG1vcmUgcmFyZSB0 aGFuDQo+IHdoYXQgaXMgaGFwcGVuaW5nIGhlcmUsIGJ1dCBzdGlsbCBzZWVtcyBwb3NzaWJsZSB0 aGF0IHdlIG1pZ2h0DQo+IHRyaXAgb3ZlciB0aGF0IGxhdGVyLg0KDQpBIGRldmljZSBzaG91bGQg bm9ybWFsbHkgZnJlZSB0aGUgY2xrcyBpdCB1c2VzIGJlZm9yZSBpdCBpcyBkZXN0cm95ZWQuDQpU aGlzIG1lYW5zIHRoYXQgaWYgZGV2X2lkIGlzIHBvaW50aW5nIHRvIGZyZWVkIG1lbW9yeSB0aGVu IHRoZSBjbGsNCml0c2VsZiB3YXMgcHJvYmFibHkgbGVha2VkLCByaWdodD8NCg0KVGhpcyBpcyBv YnZpb3VzIG1pc3VzZSBvZiB0aGUgQVBJLCBub3QgbGlrZSBzcHJpbnRmLWluZyBhIGNvbl9pZCBp biBhDQpjb21wbGV4IGRyaXZlci4gSSBkb24ndCByZWFsbHkgdGhpbmsgaXQncyB3b3J0aCBjb3B5 aW5nIHN0cmluZ3MgZm9yIGl0Lg0KDQotLQ0KUmVnYXJkcywNCkxlb25hcmQ= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751683AbdBYJgR (ORCPT ); Sat, 25 Feb 2017 04:36:17 -0500 Received: from mail-ve1eur01on0080.outbound.protection.outlook.com ([104.47.1.80]:9740 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751419AbdBYJgP (ORCPT ); Sat, 25 Feb 2017 04:36:15 -0500 From: Leonard Crestez To: "sboyd@codeaurora.org" CC: "linux-kernel@vger.kernel.org" , "mturquette@baylibre.com" , "linux-clk@vger.kernel.org" Subject: Re: [PATCH] clk: core: Copy connection id Thread-Topic: [PATCH] clk: core: Copy connection id Thread-Index: AQHSi3wypNDeVI6X5k2xubw35qCiQKF4pqmAgADTDgA= Date: Sat, 25 Feb 2017 09:20:02 +0000 Message-ID: <1488014402.6461.3.camel@nxp.com> References: <60d115f6c11bc51cd8bc10c64cd222c3cdb43cc7.1487596492.git.leonard.crestez@nxp.com> <20170224204439.GD25384@codeaurora.org> In-Reply-To: <20170224204439.GD25384@codeaurora.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=leonard.crestez@nxp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [85.204.4.237] x-ms-office365-filtering-correlation-id: 2650ec55-94a4-4395-bad8-08d45d5f7ab8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081);SRVR:AM5PR04MB3217; x-microsoft-exchange-diagnostics: 1;AM5PR04MB3217;7:PIj91fPPuxmDBEoW1mGO0LoLb7jG7mehmzFxu9lg7Bc6OhM00+lbTf4TT5hzweDdX8DDm0YFRd9g7a/xXcjJ4nE5sTkFGnHMUClcor+zEKVFfyWaeYClKQEi+/dm5++v2WE7kUeshoRHO243IsjxY8oE2Kol6jwcvsmQxUfV8etkaetZhcQvPGrKHwJCM2HAW9esbX9c7fbZsd2SQm7HX3XiQYQjmifvods4UcXw7pd/8aKVjeZZblca8vibm6k/P+Dg7QAFtev+2A01qZJE84XdqUapdFw9zq5cNY0/K3jg5tr7OmiEp7uFhpCdeTelP4sp4dYLQkvyBHo9usaaOg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(6072148);SRVR:AM5PR04MB3217;BCL:0;PCL:0;RULEID:;SRVR:AM5PR04MB3217; x-forefront-prvs: 02296943FF x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(189002)(199003)(377424004)(24454002)(6916009)(2950100002)(229853002)(6486002)(81166006)(81156014)(1730700003)(8676002)(77096006)(103116003)(36756003)(53936002)(5640700003)(25786008)(54906002)(6512007)(6436002)(99286003)(6506006)(8936002)(5660300001)(2501003)(6246003)(110136004)(66066001)(38730400002)(68736007)(33646002)(50986999)(76176999)(54356999)(102836003)(6116002)(86362001)(7736002)(92566002)(101416001)(2351001)(305945005)(3846002)(3660700001)(122556002)(2900100001)(3280700002)(97736004)(189998001)(105586002)(4326007)(106356001)(106116001)(2906002);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR04MB3217;H:AM5PR04MB3219.eurprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0388D9E1D964274A8E0FCB1FCB04A8FC@eurprd04.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2017 09:20:02.6664 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR04MB3217 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v1P9aLlb015447 On Fri, 2017-02-24 at 12:44 -0800, Stephen Boyd wrote: > On 02/20, Leonard Crestez wrote: > > Some drivers use sprintf to build clk connection id names but the > > clk > > core will save those strings and occasionally print them back. > > Duplicate > > the con_id strings instead of fixing all the users. > > Good catch. What about dev_id though? That could also have the > same problem if some device is removed and we're still holding a > reference to the kobject's name. This is probably more rare than > what is happening here, but still seems possible that we might > trip over that later. A device should normally free the clks it uses before it is destroyed. This means that if dev_id is pointing to freed memory then the clk itself was probably leaked, right? This is obvious misuse of the API, not like sprintf-ing a con_id in a complex driver. I don't really think it's worth copying strings for it. -- Regards, Leonard