Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753314AbbGIDSC (ORCPT ); Wed, 8 Jul 2015 23:18:02 -0400 Received: from mail-lb0-f177.google.com ([209.85.217.177]:35401 "EHLO mail-lb0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751622AbbGIDRx (ORCPT ); Wed, 8 Jul 2015 23:17:53 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 8 Jul 2015 20:17:52 -0700 X-Google-Sender-Auth: _E_ZwMm28RmmeeszWNYqNCas5gY Message-ID: Subject: Re: Linux 4.2-rc1 From: Linus Torvalds To: Ming Lei Cc: Shuah Khan , Greg Kroah-Hartman , Linux Kernel Mailing List , Shuah Khan Content-Type: multipart/mixed; boundary=089e013d17546b2a78051a68b3f0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3003 Lines: 58 --089e013d17546b2a78051a68b3f0 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 8, 2015 at 5:58 PM, Ming Lei wrote: > On Thu, Jul 9, 2015 at 1:29 AM, Linus Torvalds > wrote: >> Also, it looks like you need to hold the "fw_lock" to even look at >> that pointer, since the buffer can get reallocated etc. > > Yes, the above code with holding 'fw_lock' is right fix for the issue since > sysfs read can happen anytime, and there is one race between firmware > request abort and reading uevent of sysfs. So if fw_priv->buf is NULL, what should we do? Should we skip the TIMEOUT= and ASYNC= fields too? Something like the attached, perhaps? Shuah, how reproducible is this? Does this (completely untested) patch make any difference? Linus --089e013d17546b2a78051a68b3f0 Content-Type: text/plain; charset=US-ASCII; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ibvmjagw0 IGRyaXZlcnMvYmFzZS9maXJtd2FyZV9jbGFzcy5jIHwgMTYgKysrKysrKysrKysrKy0tLQogMSBm aWxlIGNoYW5nZWQsIDEzIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0 IGEvZHJpdmVycy9iYXNlL2Zpcm13YXJlX2NsYXNzLmMgYi9kcml2ZXJzL2Jhc2UvZmlybXdhcmVf Y2xhc3MuYwppbmRleCA5YzQyODgzNjJhOGUuLjg5NGJkYTExNDIyNCAxMDA2NDQKLS0tIGEvZHJp dmVycy9iYXNlL2Zpcm13YXJlX2NsYXNzLmMKKysrIGIvZHJpdmVycy9iYXNlL2Zpcm13YXJlX2Ns YXNzLmMKQEAgLTU2MywxMCArNTYzLDggQEAgc3RhdGljIHZvaWQgZndfZGV2X3JlbGVhc2Uoc3Ry dWN0IGRldmljZSAqZGV2KQogCWtmcmVlKGZ3X3ByaXYpOwogfQogCi1zdGF0aWMgaW50IGZpcm13 YXJlX3VldmVudChzdHJ1Y3QgZGV2aWNlICpkZXYsIHN0cnVjdCBrb2JqX3VldmVudF9lbnYgKmVu dikKK3N0YXRpYyBpbnQgZG9fZmlybXdhcmVfdWV2ZW50KHN0cnVjdCBmaXJtd2FyZV9wcml2ICpm d19wcml2LCBzdHJ1Y3Qga29ial91ZXZlbnRfZW52ICplbnYpCiB7Ci0Jc3RydWN0IGZpcm13YXJl X3ByaXYgKmZ3X3ByaXYgPSB0b19maXJtd2FyZV9wcml2KGRldik7Ci0KIAlpZiAoYWRkX3VldmVu dF92YXIoZW52LCAiRklSTVdBUkU9JXMiLCBmd19wcml2LT5idWYtPmZ3X2lkKSkKIAkJcmV0dXJu IC1FTk9NRU07CiAJaWYgKGFkZF91ZXZlbnRfdmFyKGVudiwgIlRJTUVPVVQ9JWkiLCBsb2FkaW5n X3RpbWVvdXQpKQpAQCAtNTc3LDYgKzU3NSwxOCBAQCBzdGF0aWMgaW50IGZpcm13YXJlX3VldmVu dChzdHJ1Y3QgZGV2aWNlICpkZXYsIHN0cnVjdCBrb2JqX3VldmVudF9lbnYgKmVudikKIAlyZXR1 cm4gMDsKIH0KIAorc3RhdGljIGludCBmaXJtd2FyZV91ZXZlbnQoc3RydWN0IGRldmljZSAqZGV2 LCBzdHJ1Y3Qga29ial91ZXZlbnRfZW52ICplbnYpCit7CisJc3RydWN0IGZpcm13YXJlX3ByaXYg KmZ3X3ByaXYgPSB0b19maXJtd2FyZV9wcml2KGRldik7CisJaW50IGVyciA9IDA7CisKKwltdXRl eF9sb2NrKCZmd19sb2NrKTsKKwlpZiAoZndfcHJpdi0+YnVmKQorCQllcnIgPSBkb19maXJtd2Fy ZV91ZXZlbnQoZndfcHJpdiwgZW52KTsKKwltdXRleF91bmxvY2soJmZ3X2xvY2spOworCXJldHVy biBlcnI7Cit9CisKIHN0YXRpYyBzdHJ1Y3QgY2xhc3MgZmlybXdhcmVfY2xhc3MgPSB7CiAJLm5h bWUJCT0gImZpcm13YXJlIiwKIAkuY2xhc3NfYXR0cnMJPSBmaXJtd2FyZV9jbGFzc19hdHRycywK --089e013d17546b2a78051a68b3f0-- -- 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/