Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp721743yba; Thu, 18 Apr 2019 08:30:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqys1XOElx+cMd2xW0is0baaVw1OwwC8uZHSeSRG7Ri62E/Ojcea6S6knLwACSBtCdbygvHX X-Received: by 2002:a17:902:781:: with SMTP id 1mr94543665plj.300.1555601422174; Thu, 18 Apr 2019 08:30:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555601422; cv=none; d=google.com; s=arc-20160816; b=fHrFznPje1m4uflub1ZrLTHzhy6EQDEuXBjRblqAYaCZC3a0VgN7resTRW/KAz7sRO LG2KgnboozPJq/JxWMjpC05S1rjX1cbcBvCSE918Qd9iDl4ddKTCr/Y2xtbEjl4Qokdu eYshZjza5xTSmJIEsPYwaQu7+RFJR56ahaasXfgANPlXF9ZWbXnPXWPqvQnZmP7mZiNa rWF2U+KGv/xueOAz6C1vap9fHDeroFERdLI3guOimBlGWGkIelNHQ/DTsBbFnDamiuxr gpbbJwCmhVlQuNhBV9OR5bRbW3F+otqQ8cU7Airx7fAuoDQCc6Dhn2X0zYNtTHSACXN3 G9mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=PTV7w2sFD53HDQMqtsdrCsqIcgw/TVT2YeOyBYCnr5o=; b=rwgeT6oSz35CATLxGbVAWdKQmlMaPhCCAZHMkqi+O0Gu5T5nqcf51YAribjCloWcvr EX6rP9BoBWz8pGmMo6BBwjQtZ8F/3Rceyxu1fSipzj5XhulU/1qwJMVEAAraFlSkvwqe uFdA7HeJiD+sHrH51BS0E1mmwO2w82JCTe8Jva6wNlViUcPf+bAtaZvyz+Q/stUJ9dcR YS9qGHfNxEM3+rPq2hoQRlbEW/NSnPeFrIceJvsrem0MLh/eXmiJxciwTOEChfzv4WGh SPOZzsPqeItwxwyYEmI9L1L/6UPizbehuC0LcH2W1vFYYcZLNA45r3Jwm+KEUtpPDxUO sOBg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g97si462536plb.70.2019.04.18.08.30.06; Thu, 18 Apr 2019 08:30:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389038AbfDRP3L (ORCPT + 99 others); Thu, 18 Apr 2019 11:29:11 -0400 Received: from mail-it1-f195.google.com ([209.85.166.195]:51392 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731317AbfDRP3L (ORCPT ); Thu, 18 Apr 2019 11:29:11 -0400 Received: by mail-it1-f195.google.com with SMTP id s3so3933263itk.1 for ; Thu, 18 Apr 2019 08:29:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PTV7w2sFD53HDQMqtsdrCsqIcgw/TVT2YeOyBYCnr5o=; b=ZwbsfNoF2wE0VlUqMdQm4QRGSpBepAzSm+PeMUg1lRzgiZthWwgwJTJibYEPB+h5eh CkQVJTkD90LJvvb56JcOp6TyZxqHDbHY26mB+q4e7oKnGrEUMytZg9RGocADikm/q4M1 zxWHsizKuRcFeSJ4hufwKHkWeryVwk3dgW5kVFWbDBRCwFLxpJA+mqttGGT1QHEad/yi FVL/J7cJwUGENQhB5wE9JMF/rynmmJptf5OEwSccYs1FE0lHm6BPmmMnsYNpxIH4BQm4 Vnqqv3dXi9ZOMsyHGOqEBXm8BF6aN8+ZaNwzGt4LYZlFt7BguS8vwtfPaTRUdy+cwyB6 VlSg== X-Gm-Message-State: APjAAAVaLQMJXNpMiStVZSB9co5TuOyQ/aUkVGiT9cXsUIbgXGpbtsJP zO0Qviwl7NIbrnDvVKEMFKoZ6Q== X-Received: by 2002:a05:660c:12ce:: with SMTP id k14mr3743232itd.23.1555601348493; Thu, 18 Apr 2019 08:29:08 -0700 (PDT) Received: from google.com ([2620:15c:183:0:20b8:dee7:5447:d05]) by smtp.gmail.com with ESMTPSA id p17sm790420iol.69.2019.04.18.08.29.06 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 18 Apr 2019 08:29:07 -0700 (PDT) Date: Thu, 18 Apr 2019 09:29:02 -0600 From: Raul Rangel To: Greg Kroah-Hartman Cc: Alan Stern , Guenter Roeck , linux-usb@vger.kernel.org, Guenter Roeck , Oliver Neukum , Daniel Kurtz , zwisler@chromium.org, Sebastian Andrzej Siewior , Martin Blumenstingl , Dmitry Torokhov , linux-kernel , "Gustavo A. R. Silva" , Miquel Raynal , Johan Hovold , Mathias Nyman , Raul Rangel Subject: Re: [PATCH v3] usb/hcd: Send a uevent signaling that the host controller had died Message-ID: <20190418152902.GA185502@google.com> References: <20190418065141.GB12503@kroah.com> <20190418143048.GA11555@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190418143048.GA11555@kroah.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 18, 2019 at 04:30:48PM +0200, Greg Kroah-Hartman wrote: > On Thu, Apr 18, 2019 at 10:21:32AM -0400, Alan Stern wrote: > > On Thu, 18 Apr 2019, Greg Kroah-Hartman wrote: > > > > > On Wed, Apr 17, 2019 at 04:20:09PM -0700, Guenter Roeck wrote: > > > > On Wed, Apr 17, 2019 at 3:41 PM Raul Rangel wrote: > > > > > > > > > > On Wed, Apr 17, 2019 at 03:23:52PM -0700, Guenter Roeck wrote: > > > > > > On Wed, Apr 17, 2019 at 3:11 PM Raul Rangel wrote: > > > > > > > > > > > > > > On Wed, Apr 17, 2019 at 04:39:23PM -0400, Alan Stern wrote: > > > > > > > > > > > > > > > > This sounds like a golden opportunity! Submit a separate patch making > > > > > > > > the parameter to kobject_uevent_env be const (actually const char * > > > > > > > > const []), then submit this patch on top of that one. > > > > > > > So there are other parts of the code base that dynamically create their > > > > > > > array values. So by making the function take const, it breaks :( > > > > > > > > > > > > Confused. The calling code can still be non-const. I don't see the > > > > > > parameter modified in kobject_uevent_env(), so declaring it const > > > > > > should be possible. Can you give an example of code that no longer > > > > > > works ? > > > > > static int notify_user_space(struct thermal_zone_device *tz, int trip) > > > > > { > > > > > char *thermal_prop[5]; > > > > > int i; > > > > > > > > > > mutex_lock(&tz->lock); > > > > > thermal_prop[0] = kasprintf(GFP_KERNEL, "NAME=%s", tz->type); > > > > > thermal_prop[1] = kasprintf(GFP_KERNEL, "TEMP=%d", tz->temperature); > > > > > thermal_prop[2] = kasprintf(GFP_KERNEL, "TRIP=%d", trip); > > > > > thermal_prop[3] = kasprintf(GFP_KERNEL, "EVENT=%d", tz->notify_event); > > > > > thermal_prop[4] = NULL; > > > > > kobject_uevent_env(&tz->device.kobj, KOBJ_CHANGE, thermal_prop); > > > > > for (i = 0; i < 4; ++i) > > > > > kfree(thermal_prop[i]); > > > > > mutex_unlock(&tz->lock); > > > > > return 0; > > > > > } > > > > > > > > > > drivers/thermal/user_space.c:48:52: error: passing 'char *[5]' to parameter of type 'const char *const *' discards qualifiers in nested pointer types [-Werror,-Wincompatible-pointer-types-discards-qualifiers] > > > > > kobject_uevent_env(&tz->device.kobj, KOBJ_CHANGE, thermal_prop); > > > > > ^~~~~~~~~~~~ > > > > > include/linux/kobject.h:238:22: note: passing argument to parameter 'envp' here > > > > > const char *const envp[]); > > > > > ^ > > > > > > > > > > http://c-faq.com/ansi/constmismatch.html explains why it fails. > > > > > > > > > Interesting. One never stops learning. So the best you could do would > > > > be char * const envp[], but I guess that doesn't help much. > > > > > > Yeah, I went down this path a year or so ago and had to give it up as > > > well :( > > > > Well, the signature could still be changed as Guenter suggests. > > > > And the array being added in the new code could still be static. > > After all, there isn't really any danger that the contents of those > > strings will be modified, right? It's just that the const modifiers > > weren't put in until it was too late and there were too many existing > > callers. Perhaps a comment about this could be included in the > > kerneldoc for kobject_uevent_env. > > I am all for changing this, but I remember I tried to, and somehow > failed, but I don't remember the full details sorry, it was a while ago. > If someone figures out how to make this all const, I will gladly take > that patch. > Well we could use varargs... int kobject_uevent_env(struct kobject *kobj, enum kobject_action action, ...); This will accept both const char* and char *. Example https://repl.it/@RaulRangel/Const-char-var-args It seems like most callers have a fixed number of env params, so you wouldn't need a function that takes a list. > thanks, > > greg k-h