* [PATCH] USB: usbfs: Suppress emission of uevents for interfaces handled via usbfs
From: Ingo Rohloff @ 2019-10-09 10:38 UTC (permalink / raw)
To: linux-usb, linux-hotplug
In-Reply-To: <20191009112141.04bd42a1@ingpc3.intern.lauterbach.com>
From 17d1e75543e26cfe702e7f5b0d4e07e0e45e5250 Mon Sep 17 00:00:00 2001
From: Ingo Rohloff <ingo.rohloff@lauterbach.com>
Date: Tue, 8 Oct 2019 20:27:57 +0200
Subject: [PATCH] USB: usbfs: Suppress emission of uevents for interfaces
handled via usbfs.
commit 1455cf8dbfd0
("driver core: emit uevents when device is bound to a driver")
added bind/unbind uevents when a driver is bound/unbound
to a physical device.
For USB devices which are handled via the generic usbfs layer
(via libusb for example), this is problematic:
Each time a user space program calls
ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr);
and then later
ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr);
The kernel will now produce a bind/unbind event,
which does not really contain any useful information.
This allows a user space program to run a DoS attack against
programs which listen to uevents (in particular systemd/eudev/upowerd):
A malicious user space program just has to call in a tight loop
ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr);
ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr);
With this loop the malicious user space program floods
the kernel and all programs listening to uevents with
tons of bind/unbind events.
This patch suppresses uevents for interfaces claimed via usbfs.
Signed-off-by: Ingo Rohloff <ingo.rohloff@lauterbach.com>
---
drivers/usb/core/devio.c | 7 ++++++-
drivers/usb/core/driver.c | 2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 3f899552f6e3..a1af1d9b2ae7 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -764,8 +764,13 @@ static int claimintf(struct usb_dev_state *ps, unsigned int ifnum)
intf = usb_ifnum_to_if(dev, ifnum);
if (!intf)
err = -ENOENT;
- else
+ else {
+ /* suppress uevents for devices handled by usbfs */
+ dev_set_uevent_suppress(&intf->dev, 1);
err = usb_driver_claim_interface(&usbfs_driver, intf, ps);
+ if (err != 0)
+ dev_set_uevent_suppress(&intf->dev, 0);
+ }
if (err = 0)
set_bit(ifnum, &ps->ifclaimed);
return err;
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 2b27d232d7a7..6a15bc5c2869 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -594,6 +594,8 @@ void usb_driver_release_interface(struct usb_driver *driver,
*/
if (device_is_registered(dev)) {
device_release_driver(dev);
+ /* make sure we allow uevents again */
+ dev_set_uevent_suppress(dev, 0);
} else {
device_lock(dev);
usb_unbind_interface(dev);
--
2.17.1
^ permalink raw reply related
* [PATCH] USB: usbfs: Suppress emission of uevents for interfaces handled via usbfs.
From: Ingo Rohloff @ 2019-10-09 9:21 UTC (permalink / raw)
To: linux-usb, linux-hotplug
commit 1455cf8dbfd0
("driver core: emit uevents when device is bound to a driver")
added bind/unbind uevents when a driver is bound/unbound
to a physical device.
For USB devices which are handled via the generic usbfs layer
(via libusb for example), this is problematic:
Each time a user space program calls
ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr);
and then later
ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr);
The kernel will now produce a bind/unbind event,
which does not really contain any useful information.
This allows a user space program to run a DoS attack against
programs which listen to uevents (in particular systemd/eudev/upowerd):
A malicious user space program just has to call in a tight loop
ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr);
ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr);
With this loop the malicious user space program floods
the kernel and all programs listening to uevents with
tons of bind/unbind events.
This patch suppresses uevents for interfaces claimed via usbfs.
Signed-off-by: Ingo Rohloff <ingo.rohloff@lauterbach.com>
---
drivers/usb/core/devio.c | 7 ++++++-
drivers/usb/core/driver.c | 2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 3f899552f6e3..a1af1d9b2ae7 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -764,8 +764,13 @@ static int claimintf(struct usb_dev_state *ps, unsigned int ifnum)
intf = usb_ifnum_to_if(dev, ifnum);
if (!intf)
err = -ENOENT;
- else
+ else {
+ /* suppress uevents for devices handled by usbfs */
+ dev_set_uevent_suppress(&intf->dev, 1);
err = usb_driver_claim_interface(&usbfs_driver, intf, ps);
+ if (err != 0)
+ dev_set_uevent_suppress(&intf->dev, 0);
+ }
if (err = 0)
set_bit(ifnum, &ps->ifclaimed);
return err;
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 2b27d232d7a7..6a15bc5c2869 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -594,6 +594,8 @@ void usb_driver_release_interface(struct usb_driver *driver,
*/
if (device_is_registered(dev)) {
device_release_driver(dev);
+ /* make sure we allow uevents again */
+ dev_set_uevent_suppress(dev, 0);
} else {
device_lock(dev);
usb_unbind_interface(dev);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] usbfs: Suppress uevents for claiminterface/releaseinterface
From: Greg KH @ 2019-10-08 19:46 UTC (permalink / raw)
To: Ingo Rohloff; +Cc: linux-usb, linux-hotplug
In-Reply-To: <20191008213200.68194e8c@ingpc3.intern.lauterbach.com>
On Tue, Oct 08, 2019 at 09:32:10PM +0200, Ingo Rohloff wrote:
> Hello,
>
> With recent Ubuntu 18/Linux Mint 19.2 etc, lots of user space programs
> (in particular systemd/eudev/upowerd) have problems with the "BIND/UNBIND"
> events produced since kernel 4.13.
> Some problems are described, when googling for
> linux "usb" "bind event"
>
> Now this might be blamed on these particular user space programs.
> But: This also means that programs accessing a USB device via the generic
> usbfs layer can easily flood the kernel and all user space programs listening
> to uevents with tons of BIND/UNBIND events by calling
>
> ioctl(usbfd, USBDEVFS_CLAIMINTERFACE, &intf);
> ioctl(usbfd, USBDEVFS_RELEASEINTERFACE, &intf);
>
> in a tight loop.
> Of course this is an extreme example, but I have a use case where exactly
> this happens (running Linux Mint 19.2).
> The result is that "systemd-udev" needs > 100% CPU and
> upowerd spams the system log with messages about "bind/unbind" events.
>
> I am also not sure if these particular bind/unbind events contain any useful
> information; these events just mean an arbitrary user space program has
> bound/unbound from a particular USB interface.
>
> The following patch tries to suppress emission of uevents
> for USB interfaces which are claimed/released via usbfs.
>
> I am not sure if this is the right way to do it, but at least
> it seems to do what I intended...
>
> with best regards
> Ingo Rohloff
> From 57970b0a5a36809ddb8f15687c18ca2147dc73bd Mon Sep 17 00:00:00 2001
> From: Ingo Rohloff <ingo.rohloff@lauterbach.com>
> Date: Tue, 8 Oct 2019 20:27:57 +0200
> Subject: [PATCH] USB: usbfs: Suppress emission of uevents for interfaces
> handled via usbfs.
>
> commit 1455cf8dbfd0
> ("driver core: emit uevents when device is bound to a driver")
> added BIND and UNBIND events when a driver is bound/unbound
> to a physical device.
>
> For USB devices which are handled via the generic usbfs layer
> (via libusb for example). This is problematic:
> Each time a user space program calls
> ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr);
> and then later
> ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr);
> The kernel will now produce a BIND/UNBIND event, which
> does not really contain any useful information.
>
> Additionally this easily allows a user space program to run a
> DoS attack against programs which listen to uevents
> (in particular systemd/eudev/upowerd):
> A malicious user space program just has to call in a tight loop
>
> ioctl(usbfd, USBDEVFS_CLAIMINTERFACE, &intf);
> ioctl(usbfd, USBDEVFS_RELEASEINTERFACE, &intf);
>
> with this loop the malicious user space program floods
> the kernel and all programs listening to uevents with
> tons of BIND/UNBIND events.
>
> The following patch tries to suppress uevents for interfaces
> claimed via usbfs.
> ---
> drivers/usb/core/devio.c | 7 ++++++-
> drivers/usb/core/driver.c | 2 ++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index 3f899552f6e3..a1af1d9b2ae7 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -764,8 +764,13 @@ static int claimintf(struct usb_dev_state *ps, unsigned int ifnum)
> intf = usb_ifnum_to_if(dev, ifnum);
> if (!intf)
> err = -ENOENT;
> - else
> + else {
> + /* suppress uevents for devices handled by usbfs */
> + dev_set_uevent_suppress(&intf->dev, 1);
> err = usb_driver_claim_interface(&usbfs_driver, intf, ps);
> + if (err != 0)
> + dev_set_uevent_suppress(&intf->dev, 0);
> + }
> if (err = 0)
> set_bit(ifnum, &ps->ifclaimed);
> return err;
> diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
> index 2b27d232d7a7..6a15bc5c2869 100644
> --- a/drivers/usb/core/driver.c
> +++ b/drivers/usb/core/driver.c
> @@ -594,6 +594,8 @@ void usb_driver_release_interface(struct usb_driver *driver,
> */
> if (device_is_registered(dev)) {
> device_release_driver(dev);
> + /* make sure we allow uevents again */
> + dev_set_uevent_suppress(dev, 0);
> } else {
> device_lock(dev);
> usb_unbind_interface(dev);
> --
> 2.17.1
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- Your patch was attached, please place it inline so that it can be
applied directly from the email message itself.
- Your patch does not have a Signed-off-by: line. Please read the
kernel file, Documentation/SubmittingPatches and resend it after
adding that line. Note, the line needs to be in the body of the
email, before the patch, not at the bottom of the patch or in the
email signature.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* [PATCH] usbfs: Suppress uevents for claiminterface/releaseinterface
From: Ingo Rohloff @ 2019-10-08 19:32 UTC (permalink / raw)
To: linux-usb, linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
Hello,
With recent Ubuntu 18/Linux Mint 19.2 etc, lots of user space programs
(in particular systemd/eudev/upowerd) have problems with the "BIND/UNBIND"
events produced since kernel 4.13.
Some problems are described, when googling for
linux "usb" "bind event"
Now this might be blamed on these particular user space programs.
But: This also means that programs accessing a USB device via the generic
usbfs layer can easily flood the kernel and all user space programs listening
to uevents with tons of BIND/UNBIND events by calling
ioctl(usbfd, USBDEVFS_CLAIMINTERFACE, &intf);
ioctl(usbfd, USBDEVFS_RELEASEINTERFACE, &intf);
in a tight loop.
Of course this is an extreme example, but I have a use case where exactly
this happens (running Linux Mint 19.2).
The result is that "systemd-udev" needs > 100% CPU and
upowerd spams the system log with messages about "bind/unbind" events.
I am also not sure if these particular bind/unbind events contain any useful
information; these events just mean an arbitrary user space program has
bound/unbound from a particular USB interface.
The following patch tries to suppress emission of uevents
for USB interfaces which are claimed/released via usbfs.
I am not sure if this is the right way to do it, but at least
it seems to do what I intended...
with best regards
Ingo Rohloff
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-USB-usbfs-Suppress-emission-of-uevents-for-interface.patch --]
[-- Type: text/x-patch, Size: 2644 bytes --]
From 57970b0a5a36809ddb8f15687c18ca2147dc73bd Mon Sep 17 00:00:00 2001
From: Ingo Rohloff <ingo.rohloff@lauterbach.com>
Date: Tue, 8 Oct 2019 20:27:57 +0200
Subject: [PATCH] USB: usbfs: Suppress emission of uevents for interfaces
handled via usbfs.
commit 1455cf8dbfd0
("driver core: emit uevents when device is bound to a driver")
added BIND and UNBIND events when a driver is bound/unbound
to a physical device.
For USB devices which are handled via the generic usbfs layer
(via libusb for example). This is problematic:
Each time a user space program calls
ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr);
and then later
ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr);
The kernel will now produce a BIND/UNBIND event, which
does not really contain any useful information.
Additionally this easily allows a user space program to run a
DoS attack against programs which listen to uevents
(in particular systemd/eudev/upowerd):
A malicious user space program just has to call in a tight loop
ioctl(usbfd, USBDEVFS_CLAIMINTERFACE, &intf);
ioctl(usbfd, USBDEVFS_RELEASEINTERFACE, &intf);
with this loop the malicious user space program floods
the kernel and all programs listening to uevents with
tons of BIND/UNBIND events.
The following patch tries to suppress uevents for interfaces
claimed via usbfs.
---
drivers/usb/core/devio.c | 7 ++++++-
drivers/usb/core/driver.c | 2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 3f899552f6e3..a1af1d9b2ae7 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -764,8 +764,13 @@ static int claimintf(struct usb_dev_state *ps, unsigned int ifnum)
intf = usb_ifnum_to_if(dev, ifnum);
if (!intf)
err = -ENOENT;
- else
+ else {
+ /* suppress uevents for devices handled by usbfs */
+ dev_set_uevent_suppress(&intf->dev, 1);
err = usb_driver_claim_interface(&usbfs_driver, intf, ps);
+ if (err != 0)
+ dev_set_uevent_suppress(&intf->dev, 0);
+ }
if (err == 0)
set_bit(ifnum, &ps->ifclaimed);
return err;
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 2b27d232d7a7..6a15bc5c2869 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -594,6 +594,8 @@ void usb_driver_release_interface(struct usb_driver *driver,
*/
if (device_is_registered(dev)) {
device_release_driver(dev);
+ /* make sure we allow uevents again */
+ dev_set_uevent_suppress(dev, 0);
} else {
device_lock(dev);
usb_unbind_interface(dev);
--
2.17.1
^ permalink raw reply related
* Re: udev syntax and features
From: Andrei Borzenkov @ 2018-10-19 4:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <04a28467-5e2d-238f-8812-29ba4f34311c@telus.net>
17.10.2018 23:06, Greg пишет:
> Hello all.
>
> I have a few questions about udev.
>
> I have tried the net for several hours/days, but much of the udev
> documentation out there is over 5 years old and I have had no lucuck
> with the following questions:
>
> Udev. Q1. is it case sensitive? i.e. is kernel="sd?*" allowed as a
> synonym for KERNEL="sd?*"
>
It is case sensitive.
> Udev Q2. What does UDEV define as a "long running process"? Are
> there some docs or a udevadm cmd that will report udev compile time
> options? A config file that specs that? a systemd unit file that
> specs that?
>
Default is 3 minutes. It can be changed with udevd argument or kernel
command line. Note that it applies only to external (non-builtin) commands.
> Udev. Q3. Would a command like: systemctl set-environment
> GKH="Gregory the Great" qualify as long running? (it takes about
> 0.132 secs)
>
Should not unless connection hangs.
> Udev Q4. Could ANY list variable that can be modded with += have TWO
> (or more) new terms added to it?
>
> such as say SYMLINK+="/media/%k","/mnt/%k" ?
>
As far as I know everything after "+=" is treated as single value which
gets added to list of values of this "variable". Where have you seen
example of such usage? You would need two "+=" statements with different
values. Your example would fail with invalid syntax (unknown keyword
after comma).
> Udev Q5. Similar to the above I would like to have
> RUN+="/path/to/Somecmd %k %n","/path/to/Someothercmd $foo" in some
> rule. is that OK?
>
See above. You need two "RUN+=" statements. Note that timeout is applied
to each individual command, not to overall execution time. At least if I
interpret code correctly.
> Udev. Q6. Is RUN guaranteed to be last? so that PROGRAM will set the
> var RESULT before RUN starts its stuff?
>
Yes, RUN are started after all other rules have been processed. I am not
aware of formal design specification, but changing this would have quite
some compatibility impact.
> Udev. Q7. At what point does SYSTEMD_WANTS take effect? How would I
> ensure that say my PROGRAM had set RESULT before the SYSTEMD_WANTS
> magic happened?
>
SYSTEMD_WANTS is evaluated by systemd when it gets notified by udev
about device event. This notification is sent by udev after kernel event
processing has been completed (including after all RUN have been
executed). What follows, it should see any RESULT assignment done as
part of rules processing.
Note that you need to save RESULT in some environment variable to be
accessible.
> Udev. Q8. IMPORT and RUN and PROGRAM all have a "type" option one of
> which is "builtin" which refers to bultin cmds. where do I get a list
> of such builtins? there is nothing in man udev.
>
I do not think such list exists. You may want to direct your question to
systemd list where udev development happens now.
^ permalink raw reply
* udev syntax and features
From: Greg @ 2018-10-17 20:06 UTC (permalink / raw)
To: linux-hotplug
Hello all.
I have a few questions about udev.
I have tried the net for several hours/days, but much of the udev
documentation out there is over 5 years old and I have had no lucuck
with the following questions:
Udev. Q1. is it case sensitive? i.e. is kernel="sd?*" allowed as a
synonym for KERNEL="sd?*"
Udev Q2. What does UDEV define as a "long running process"? Are there
some docs or a udevadm cmd that will report udev compile time options? A
config file that specs that? a systemd unit file that specs that?
Udev. Q3. Would a command like: systemctl set-environment GKH="Gregory
the Great" qualify as long running? (it takes about 0.132 secs)
Udev Q4. Could ANY list variable that can be modded with += have TWO (or
more) new terms added to it?
such as say SYMLINK+="/media/%k","/mnt/%k" ?
Udev Q5. Similar to the above I would like to have
RUN+="/path/to/Somecmd %k %n","/path/to/Someothercmd $foo" in some rule.
is that OK?
Udev. Q6. Is RUN guaranteed to be last? so that PROGRAM will set the var
RESULT before RUN starts its stuff?
Udev. Q7. At what point does SYSTEMD_WANTS take effect? How would I
ensure that say my PROGRAM had set RESULT before
the SYSTEMD_WANTS magic happened?
Udev. Q8. IMPORT and RUN and PROGRAM all have a "type" option one of
which is "builtin" which refers to bultin cmds.
where do I get a list of such builtins? there is nothing in man udev.
Thank you.
Greg Morse
--
Sent from My Linux Mint Desktop
^ permalink raw reply
* Re: reserve memory
From: Greg KH @ 2018-07-17 6:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAJ2oMhJHYVG3mypArk44h4_k_KLgccx60HUW48+84hDU7z41gQ@mail.gmail.com>
On Tue, Jul 17, 2018 at 08:15:24AM +0300, Ran Shalit wrote:
> On Mon, Jul 16, 2018 at 8:48 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Mon, Jul 16, 2018 at 03:41:05PM +0300, Ran Shalit wrote:
> >> Hello,
> >>
> >> When doing :
> >> echo 1 > /sys/bus/pci/rescan
> >
> > Eeek, don't do that unless you _REALLY_ have no other option.
> >
> Hi,
>
> What are the alternatives ?
Using real PCI hotplug hardware. This is a hack that forces the kernel
to rescan the bus because it was not told it needed to do it. Because
it was not told that, this implies your hardware is not really a pci
hotplug system.
> I haven't find any information of this issue of memory allocation and
> rescan, so any pointer will help,
Why do you feel you need to do the above? Why isn't your hardware "just
working" when you add/remove a new PCI device?
thanks,
greg k-h
^ permalink raw reply
* Re: reserve memory
From: Ran Shalit @ 2018-07-17 5:15 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAJ2oMhJHYVG3mypArk44h4_k_KLgccx60HUW48+84hDU7z41gQ@mail.gmail.com>
On Mon, Jul 16, 2018 at 8:48 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Jul 16, 2018 at 03:41:05PM +0300, Ran Shalit wrote:
>> Hello,
>>
>> When doing :
>> echo 1 > /sys/bus/pci/rescan
>
> Eeek, don't do that unless you _REALLY_ have no other option.
>
Hi,
What are the alternatives ?
I haven't find any information of this issue of memory allocation and
rescan, so any pointer will help,
Thanks,
ranran
>> Does it results in memory allocation for the new added device ?
>
> It depends. It depends in your platform and what you mean exactly by
> "memory allocation".
>
>> Is it that by adding "pci=hpmemsize" we can reserve the memory for the
>> hot-plug device ? ( So, that there is no dynamic allocation in runtime
>> )
>
> I don't know, you should ask this on the linux-pci mailing list as that
> is where the developers who added this are at.
>
> good luck!
>
> greg k-h
^ permalink raw reply
* Re: reserve memory
From: Greg KH @ 2018-07-16 17:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAJ2oMhJHYVG3mypArk44h4_k_KLgccx60HUW48+84hDU7z41gQ@mail.gmail.com>
On Mon, Jul 16, 2018 at 03:41:05PM +0300, Ran Shalit wrote:
> Hello,
>
> When doing :
> echo 1 > /sys/bus/pci/rescan
Eeek, don't do that unless you _REALLY_ have no other option.
> Does it results in memory allocation for the new added device ?
It depends. It depends in your platform and what you mean exactly by
"memory allocation".
> Is it that by adding "pci=hpmemsize" we can reserve the memory for the
> hot-plug device ? ( So, that there is no dynamic allocation in runtime
> )
I don't know, you should ask this on the linux-pci mailing list as that
is where the developers who added this are at.
good luck!
greg k-h
^ permalink raw reply
* reserve memory
From: Ran Shalit @ 2018-07-16 12:41 UTC (permalink / raw)
To: linux-hotplug
Hello,
When doing :
echo 1 > /sys/bus/pci/rescan
Does it results in memory allocation for the new added device ?
Is it that by adding "pci=hpmemsize" we can reserve the memory for the
hot-plug device ? ( So, that there is no dynamic allocation in runtime
)
Thank you,
ranran
^ permalink raw reply
* Re: When should we use "hdparm" ?
From: Ran Shalit @ 2018-07-13 7:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAJ2oMhJXCx6zyFbAF1FFNDcoUkPrx4PHHkxGrHHq3B38pNDQ9A@mail.gmail.com>
Hi,
I also not sure why we don't use power off/on control any more with
the SATA/IDE newer devices.
Thanks,
ranran
On Fri, Jul 13, 2018 at 10:48 AM, Ran Shalit <ranshalit@gmail.com> wrote:
> On Fri, Jul 13, 2018 at 10:25 AM, Greg KH <greg@kroah.com> wrote:
>> On Fri, Jul 13, 2018 at 09:29:50AM +0300, Ran Shalit wrote:
>>> Hello,
>>>
>>> We have some old system (2.4 kernel) which use hot swap with sata
>>> (IDE) , but using commands such as:
>>> hdparm -U 0
>>> hdparm -R 0 0x1f0 ...
>>>
>>> But in newer system HW&SW we never use these commands when removing
>>> and inserting sata.
>>
>> What do you do instead?
>>
> I just mount and unmount partition.
> In the old system, we manually power the the storage device after
> instert and (poweroff on remove) , and then used the hdparm
> register/unregister comands.
> Without the hdparm commands the device doesn't exist in /dev , i.e. we
> must do this register/unregister in the old HW &old kernel.
>
>
>>> Why was it used once and why is it not used in newer system ?
>>
>> In the 2.4 kernel there was not kernel support for hot-swap devices like
>> this, so you had to "manually" do it with these types of commands.
>>
>>> Is it that newer system do this somehow automatically ? Where ?is it
>>> done, in SW or HW ?
>>
>> How exactly are you swapping your ide drives today?
>>
>
> With newer HW&SW don't do now any hot swapping, just mount/unmount.
> Seems that insert/remove id done under power (?),
> I just try to understand why the newer system (HW&SW) don't need to
> use these commands any more (hdparm).
>
>> And the 2.4 kernel was over a decade ago, hopefully you have upgraded
>> your hardware since then :)
>>
>> thanks,
>>
>> greg k-h
^ permalink raw reply
* Re: When should we use "hdparm" ?
From: Ran Shalit @ 2018-07-13 7:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAJ2oMhJXCx6zyFbAF1FFNDcoUkPrx4PHHkxGrHHq3B38pNDQ9A@mail.gmail.com>
On Fri, Jul 13, 2018 at 10:25 AM, Greg KH <greg@kroah.com> wrote:
> On Fri, Jul 13, 2018 at 09:29:50AM +0300, Ran Shalit wrote:
>> Hello,
>>
>> We have some old system (2.4 kernel) which use hot swap with sata
>> (IDE) , but using commands such as:
>> hdparm -U 0
>> hdparm -R 0 0x1f0 ...
>>
>> But in newer system HW&SW we never use these commands when removing
>> and inserting sata.
>
> What do you do instead?
>
I just mount and unmount partition.
In the old system, we manually power the the storage device after
instert and (poweroff on remove) , and then used the hdparm
register/unregister comands.
Without the hdparm commands the device doesn't exist in /dev , i.e. we
must do this register/unregister in the old HW &old kernel.
>> Why was it used once and why is it not used in newer system ?
>
> In the 2.4 kernel there was not kernel support for hot-swap devices like
> this, so you had to "manually" do it with these types of commands.
>
>> Is it that newer system do this somehow automatically ? Where ?is it
>> done, in SW or HW ?
>
> How exactly are you swapping your ide drives today?
>
With newer HW&SW don't do now any hot swapping, just mount/unmount.
Seems that insert/remove id done under power (?),
I just try to understand why the newer system (HW&SW) don't need to
use these commands any more (hdparm).
> And the 2.4 kernel was over a decade ago, hopefully you have upgraded
> your hardware since then :)
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: When should we use "hdparm" ?
From: Greg KH @ 2018-07-13 7:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAJ2oMhJXCx6zyFbAF1FFNDcoUkPrx4PHHkxGrHHq3B38pNDQ9A@mail.gmail.com>
On Fri, Jul 13, 2018 at 09:29:50AM +0300, Ran Shalit wrote:
> Hello,
>
> We have some old system (2.4 kernel) which use hot swap with sata
> (IDE) , bu using commands such as:
> hdparm -U 0
> hdparm -R 0 0x1f0 ...
>
> But in newer system HW&SW we never use these commands when removing
> and inserting sata.
What do you do instead?
> Why was it used once and why is it not used in newer system ?
In the 2.4 kernel there was not kernel support for hot-swap devices like
this, so you had to "manually" do it with these types of commands.
> Is it that newer system do this somehow automatically ? Where ?is it
> done, in SW or HW ?
How exactly are you swaping your ide drives today?
And the 2.4 kernel was over a decade ago, hopefully you have upgraded
your hardware since then :)
thanks,
greg k-h
^ permalink raw reply
* When should we use "hdparm" ?
From: Ran Shalit @ 2018-07-13 6:29 UTC (permalink / raw)
To: linux-hotplug
Hello,
We have some old system (2.4 kernel) which use hot swap with sata
(IDE) , bu using commands such as:
hdparm -U 0
hdparm -R 0 0x1f0 ...
But in newer system HW&SW we never use these commands when removing
and inserting sata.
Why was it used once and why is it not used in newer system ?
Is it that newer system do this somehow automatically ? Where ?is it
done, in SW or HW ?
Thank you,
ranran
^ permalink raw reply
* Re: [uio] panic in name_show()
From: Francesco Ruggeri @ 2017-08-11 20:54 UTC (permalink / raw)
To: linux-hotplug, linux-kernel; +Cc: Francesco Ruggeri
In-Reply-To: <20170811182907.BBAB488201C7@us152.sjc.aristanetworks.com>
On Fri, Aug 11, 2017 at 11:29 AM, Francesco Ruggeri <fruggeri@arista.com> wrote:
> I have run into this panic while some devices were being hotunplugged,
> and I am able to easily reproduce it with the attached module, which
> creates a dummy uio device (in my case /sys/class/uio/uio74).
> The panic is the result of a race between uio_unregister_device(),
> which sets idev->info to NULL,
Never mind. The code that is setting idev->info to NULL is coming from
a non-standard driver.
Sorry for the noise.
Francesco Ruggeri
> and name_show() which dereferences it.
> Seen in 4.9, 3.18 and 3.4.
>
> Thanks,
> Francesco Ruggeri
^ permalink raw reply
* [uio] panic in name_show()
From: Francesco Ruggeri @ 2017-08-11 18:29 UTC (permalink / raw)
To: linux-hotplug, linux-kernel; +Cc: fruggeri
I have run into this panic while some devices were being hotunplugged,
and I am able to easily reproduce it with the attached module, which
creates a dummy uio device (in my case /sys/class/uio/uio74).
The panic is the result of a race between uio_unregister_device(),
which sets idev->info to NULL, and name_show() which dereferences it.
Seen in 4.9, 3.18 and 3.4.
Thanks,
Francesco Ruggeri
-bash-4.3# insmod dummydev.ko
-bash-4.3# cat /sys/class/uio/uio74/name
uio_dummydev
-bash-4.3# rmmod dummydev
-bash-4.3#
Then on different bash shells on different cpus I run
while true ;do insmod dummydev.ko; rmmod dummydev ;done
while true ;do cat /sys/class/uio/uio74/name ;done
-bash-4.3# taskset 1 bash
bash-4.3# while true ;do insmod dummydev.ko; rmmod dummydev ;done
[ 448.104247] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 448.197773] IP: [<ffffffffa016f1ba>] name_show+0x24/0x31 [uio]
[ 448.267454] PGD 245c8d067 [ 448.297612] PUD 14b221067
PMD 0 [ 448.336088]
[ 448.353773] Oops: 0000 [#1] PREEMPT SMP
[ 448.399531] Modules linked in: dummydev(O-) l2mod_dma(PO) xt_u32 nfnetlink_log nfnetlink nf_log_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_REJECT nf_reject_ipv6 ip6table_mangle nf_log_ipv4 nf_log_common nf_conntrack_ipv4 nf_defrag_ipv4 xt_LOG xt_limit xt_hl xt_multiport ipt_REJECT nf_reject_ipv4 xt_tcpudp iptable_mangle sch_prio msr strata_dma_drv(PO) arista_bde(PO) rbfd(PO) 8021q garp stp llc tun xt_conntrack xfrm_user nf_conntrack_tftp xfrm4_tunnel tunnel4 xt_CT nf_conntrack xt_mark ipcomp ip6table_raw iptable_raw xfrm_ipcomp iptable_filter ip6table_filter ip_tables ip6_tables esp4 x_tables ah4 af_key xfrm_algo x86_pkg_temp_thermal coretemp scd(O) kshim(PO) uio fan thermal tpm_tis tpm_tis_core tpm kvm_intel kvm irqbypass [last unloaded: dummydev]
[ 449.193038] CPU: 1 PID: 5278 Comm: cat Tainted: P O 4.9.20.Ar-5809926.eostrunkkernel49 #1
[ 449.304316] task: ffff880148e4ce00 task.stack: ffffc90004544000
[ 449.375031] RIP: 0010:[<ffffffffa016f1ba>] [<ffffffffa016f1ba>] name_show+0x24/0x31 [uio]
[ 449.473832] RSP: 0018:ffffc90004547da8 EFLAGS: 00010286
[ 449.537271] RAX: ffff88016a306000 RBX: ffffffffa01707c0 RCX: ffffffffa016f196
[ 449.622548] RDX: 0000000000000000 RSI: ffffffffa01701e4 RDI: ffff88016a306000
[ 449.707826] RBP: ffffc90004547da8 R08: ffff88014b16d810 R09: ffff88017d1df600
[ 449.793105] R10: ffffc90004547dc0 R11: 0000000000000246 R12: ffffffff81653b30
[ 449.878380] R13: ffffc90004547f08 R14: ffff88014b1b76c0 R15: ffff88014b212500
[ 449.963661] FS: 0000000000000000(0000) GS:ffff88024f880000(0063) knlGS:00000000f73b0940
[ 450.060376] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 450.129016] CR2: 0000000000000008 CR3: 0000000154571000 CR4: 00000000000406e0
[ 450.214293] Stack:
[ 450.238214] ffffc90004547dc8 ffffffff81382de9 ffff88014b16d810 ffff88014b1b76c0
[ 450.326613] ffffc90004547de8 ffffffff811d37f4 0000000000000000 0000000000010000
[ 450.415009] ffffc90004547df8 ffffffff811d242c ffffc90004547e60 ffffffff81187b60
[ 450.503409] Call Trace:
[ 450.532542] [<ffffffff81382de9>] dev_attr_show+0x25/0x49
[ 450.597019] [<ffffffff811d37f4>] sysfs_kf_seq_show+0x83/0xcf
[ 450.665655] [<ffffffff811d242c>] kernfs_seq_show+0x26/0x28
[ 450.732212] [<ffffffff81187b60>] seq_read+0x181/0x358
[ 450.793574] [<ffffffff81142639>] ? handle_mm_fault+0xc50/0xd5a
[ 450.864287] [<ffffffff811d2c68>] kernfs_fop_read+0x3a/0x166
[ 450.931887] [<ffffffff8116823a>] __vfs_read+0x18/0x2f
[ 450.993242] [<ffffffff81168c8c>] vfs_read+0xa6/0x10d
[ 451.053562] [<ffffffff81169d28>] SyS_read+0x51/0x8e
[ 451.112844] [<ffffffff81003b09>] do_fast_syscall_32+0xc9/0x150
[ 451.183559] [<ffffffff815e480c>] entry_SYSENTER_compat+0x4c/0x5b
[ 451.256356] Code: 08 16 e1 5d 48 98 c3 66 66 66 66 90 55 48 89 d0 48 8b 97 c0 00 00 00 48 c7 c6 e4 01 17 a0 48 89 c7 48 89 e5 48 8b 92 48 03 00 00 <48> 8b 52 08 e8 14 08 16 e1 5d 48 98 c3 66 66 66 66 90 55 48 89
[ 451.482028] RIP [<ffffffffa016f1ba>] name_show+0x24/0x31 [uio]
[ 451.552747] RSP <ffffc90004547da8>
[ 451.594346] CR2: 0000000000000008
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/kprobes.h>
#include <linux/kallsyms.h>
#include <linux/netdevice.h>
#include <net/net_namespace.h>
#include <net/dst.h>
#include <linux/uio_driver.h>
static struct device *dummydev = NULL;
static const char *devname = "dummydev";
static struct uio_info uio_info = {
.name = "uio_dummydev",
.version = "1.2.3",
.irq = UIO_IRQ_CUSTOM,
};
static void dummydev_release(struct device *dev) {}
int init_module(void)
{
int ret;
dummydev = kzalloc(sizeof(struct device), GFP_ATOMIC);
if (!dummydev) {
dev_info(dummydev, "INFO %s - kzalloc() failed\n", __func__);
goto out;
}
dev_set_name(dummydev, devname);
dummydev->release = dummydev_release;
ret = device_register(dummydev);
if (ret) {
dev_info(dummydev,
"INFO %s - device_register() failed\n", __func__);
goto out_free;
}
ret = uio_register_device(dummydev, &uio_info);
if (ret) {
dev_info(dummydev,
"INFO %s - uio_register_device() failed\n", __func__);
goto out_dev_unregister;
}
dev_info(dummydev, "INFO %s - created\n", __func__);
return 0;
out_dev_unregister:
device_unregister(dummydev);
out_free:
kfree(dummydev);
out:
return 1;
}
void cleanup_module(void)
{
if (!dummydev)
return;
dev_info(dummydev, "INFO %s - removing\n", __func__);
uio_unregister_device(&uio_info);
device_unregister(dummydev);
kfree(dummydev);
}
MODULE_LICENSE("GPL");
^ permalink raw reply
* INFO: task systemd-udevd:326 blocked for more than 120 seconds.
From: Cristian @ 2017-05-06 20:50 UTC (permalink / raw)
To: linux-hotplug
Hi,
dmesg:
[ 605.178422] INFO: task systemd-udevd:326 blocked for more than 120 seconds.
[ 605.178434] Not tainted 4.11.0-041100rc8-generic #201704232131
[ 605.178437] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 605.178442] systemd-udevd D 0 326 1 0x00000104
[ 605.178449] Call Trace:
[ 605.178467] __schedule+0x3c6/0x8c0
[ 605.178474] schedule+0x36/0x80
[ 605.178479] schedule_preempt_disabled+0xe/0x10
[ 605.178484] __mutex_lock.isra.5+0x26d/0x4e0
[ 605.178492] __mutex_lock_slowpath+0x13/0x20
[ 605.178497] ? __mutex_lock_slowpath+0x13/0x20
[ 605.178501] mutex_lock+0x2f/0x40
[ 605.178508] __blkdev_get+0x121/0x440
[ 605.178513] blkdev_get+0x12a/0x330
[ 605.178519] blkdev_open+0x5b/0x70
[ 605.178523] do_dentry_open+0x20a/0x310
[ 605.178528] ? bd_acquire+0xd0/0xd0
[ 605.178533] vfs_open+0x4e/0x80
[ 605.178540] path_openat+0x623/0x1500
[ 605.178546] ? kernfs_seq_stop_active+0x2b/0x30
[ 605.178552] do_filp_open+0x99/0x110
[ 605.178558] ? _crng_backtrack_protect+0x62/0x80
[ 605.178562] ? __check_object_size+0x100/0x19d
[ 605.178567] do_sys_open+0x130/0x220
[ 605.178571] ? do_sys_open+0x130/0x220
[ 605.178576] SyS_open+0x1e/0x20
[ 605.178582] do_syscall_64+0x5b/0xc0
[ 605.178586] entry_SYSCALL64_slow_path+0x25/0x25
[ 605.178590] RIP: 0033:0x7f4a8b59bd70
[ 605.178593] RSP: 002b:00007fff0a24e0b8 EFLAGS: 00000246 ORIG_RAX:
0000000000000002
[ 605.178598] RAX: ffffffffffffffda RBX: 00007fff0a24e150 RCX: 00007f4a8b59bd70
[ 605.178600] RDX: 0000561d1157fd23 RSI: 00000000000a0800 RDI: 0000561d12af1c10
[ 605.178603] RBP: 00007fff0a24e600 R08: 0000561d1157f400 R09: 0000000000000000
[ 605.178605] R10: 0000561d12ab4e40 R11: 0000000000000246 R12: 00007fff0a24e260
[ 605.178607] R13: 0000561d12aa2010 R14: 0000561d12aaa0e0 R15: 00007fff0a24e130
Regards,
--
Cristian
^ permalink raw reply
* Re: Understanding stop_machine() use for cpu_down()
From: Hardik H Bagdi @ 2017-01-26 14:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CADdiZBT-wvAmmtRem1=arnvPcyJrgH3s43ngAuzqk3poHe-FJA@mail.gmail.com>
Okay, got you.
Thanks a lot!
Harry
On Thu, Jan 26, 2017 at 2:10 AM, Greg KH <greg@kroah.com> wrote:
> On Wed, Jan 25, 2017 at 06:41:53PM -0500, Hardik H Bagdi wrote:
>> Hi,
>>
>> I'm trying to understand why stop_machine() is necessary for
>> cpu_down() operation.
>
> Great! But you might want to ask this on a linux kernel specific
> mailing list. This is for the old linux hotplug scripts :)
>
> Perhaps linux-kernel@vger.kernel.org and cc: the proper kernel
> developers who work in this area?
>
> good luck!
>
> greg k-h
^ permalink raw reply
* Re: Understanding stop_machine() use for cpu_down()
From: Greg KH @ 2017-01-26 7:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CADdiZBT-wvAmmtRem1=arnvPcyJrgH3s43ngAuzqk3poHe-FJA@mail.gmail.com>
On Wed, Jan 25, 2017 at 06:41:53PM -0500, Hardik H Bagdi wrote:
> Hi,
>
> I'm trying to understand why stop_machine() is necessary for
> cpu_down() operation.
Great! But you might want to ask this on a linux kernel specific
mailing list. This is for the old linux hotplug scripts :)
Perhaps linux-kernel@vger.kernel.org and cc: the proper kernel
developers who work in this area?
good luck!
greg k-h
^ permalink raw reply
* Understanding stop_machine() use for cpu_down()
From: Hardik H Bagdi @ 2017-01-25 23:41 UTC (permalink / raw)
To: linux-hotplug
Hi,
I'm trying to understand why stop_machine() is necessary for
cpu_down() operation.
I see that multi_cpu_stop() on every online cpu (which hogs the cpu
and then triggers state changes state)
and then, take_cpu_down is invoked on the outgoing cpu.
This happens by every cpu decrementing the msdata->thread_ack and last
one trigger a state change.
I'm trying to understand why is this necessary.
Is to wait for RCU grace period(s)?
If yes, what variable/struct is being protected and how does
stop_machine() help there?
I see there was a patch (https://lwn.net/Articles/538819/) but had
some issues with idle_loop.
Is there an alternative where the stop_machine would not be necessary?
Or more specifically, is there a reason why every CPU would need to stop?
Any help would be appreciated.
Thanks,
Hardik
^ permalink raw reply
* Re: Dangling UDEV links after removing FC LUNs
From: Greg KH @ 2016-12-03 17:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20161203162005.Horde.7B1kAhbyMfoGECiY5wzO_1J@owncloud.homeatcloud.cz>
On Sat, Dec 03, 2016 at 04:20:05PM +0000, admin wrote:
> Dear list,
> we're using Q-Logic QLE2562 Fibre Channel adapters (qla2xxx driver) against a HPE 3PAR 7400c storage array in an OpenStack environment. The OpenStack 3PAR driver manages volume attachments from the array to the servers. There is 4 path multipath to every volume.
>
> As the LUNs are removed, sometimes udev does not remove all links, particularly in /run/udev/links and /dev/disk/by-path. The symptoms are multiple records in one by-path directory under /run/udev/links, broken links to no longer attached luns in dev/disk/by-path and links between wrong LUNs and scsi devices there. I'm getting "multipathd: udev trigger error" in syslog.
>
> OpenStack relies on these links. When another volume is attached using a LUN that has these leftover links and it happens that it is the first of the 4 paths, OpenStack incorrectly identifies the volume and attaches the same volume to multiple instances, leading to data loss.
>
> What could be causing this behavior?
>
> Ubuntu version 14.04
> Linux version Ubuntu 4.4.0-47.68~14.04.1-generic 4.4.24
> udev 204-5ubuntu20.19
Please contact Canonical for support of their old kernel release and
udev package, there's not much the community can do about that, sorry.
Good luck!
greg k-h
^ permalink raw reply
* Dangling UDEV links after removing FC LUNs
From: admin @ 2016-12-03 16:20 UTC (permalink / raw)
To: linux-hotplug
Dear list,
we're using Q-Logic QLE2562 Fibre Channel adapters (qla2xxx driver) against a HPE 3PAR 7400c storage array in an OpenStack environment. The OpenStack 3PAR driver manages volume attachments from the array to the servers. There is 4 path multipath to every volume.
As the LUNs are removed, sometimes udev does not remove all links, particularly in /run/udev/links and /dev/disk/by-path. The symptoms are multiple records in one by-path directory under /run/udev/links, broken links to no longer attached luns in dev/disk/by-path and links between wrong LUNs and scsi devices there. I'm getting "multipathd: udev trigger error" in syslog.
OpenStack relies on these links. When another volume is attached using a LUN that has these leftover links and it happens that it is the first of the 4 paths, OpenStack incorrectly identifies the volume and attaches the same volume to multiple instances, leading to data loss.
What could be causing this behavior?
Ubuntu version 14.04
Linux version Ubuntu 4.4.0-47.68~14.04.1-generic 4.4.24
udev 204-5ubuntu20.19
Thanks for any troubleshooting tips, Tomas Vondra
^ permalink raw reply
* Re: Assign BAR address for pci device after hotplug
From: Greg KH @ 2016-08-10 8:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AT5PR84MB0177723391A9CA3EAEE43C0088050@AT5PR84MB0177.NAMPRD84.PROD.OUTLOOK.COM>
On Tue, Aug 09, 2016 at 05:26:12PM -0700, divakar wrote:
> I don't doubt the truth in your comments about the HW.
> Unfortunately i have to work with the HW i have and i am trying to find
> the best possible way to do this. I can certainly provide feedback for
> the next product/design based on the learnings from the current one.
> At this point these cards are not expected to be plugged into different
> machine. So based on your statements if i can fake it i will take that
> path as a starter. Is there a writeup/documentation/eg which i can
> follow to understand the required steps? for now i have started looking
> at /drivers/pci/hotplug/* .
Nope, you are on your own, and get to keep the pieces of your kernel
when things blow up...
Please realize that you have already spent more money on this than it
would have cost to buy "real" hardware that will solve these issues for
you automatically :(
greg k-h
^ permalink raw reply
* Re: Assign BAR address for pci device after hotplug
From: divakar @ 2016-08-10 0:26 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AT5PR84MB0177723391A9CA3EAEE43C0088050@AT5PR84MB0177.NAMPRD84.PROD.OUTLOOK.COM>
I don't doubt the truth in your comments about the HW.
Unfortunately i have to work with the HW i have and i am trying to find
the best possible way to do this. I can certainly provide feedback for
the next product/design based on the learnings from the current one.
At this point these cards are not expected to be plugged into different
machine. So based on your statements if i can fake it i will take that
path as a starter. Is there a writeup/documentation/eg which i can
follow to understand the required steps? for now i have started looking
at /drivers/pci/hotplug/* .
Again thanks for your patience and time.
Thanks
On Tuesday, August 09, 2016 08:59:43 PM Greg KH wrote:
> On Tue, Aug 09, 2016 at 11:48:59AM -0700, divakar wrote:
> > May be i missed one piece of information. I thought i had that in my
> > inline response but just realized i missed it.
> >
> > Device 0 ( FPGA 0), has custom logic which will detect the presence
> > of the card 1 and card 2 and controls the power switches to the
> > same. So If this makes fpga0 a "hotplug controller " then i can add
> > the resource management logic/code for devices on card 1 and card 2
> > to this driver. Currently fpga_0 driver does some init for some of
> > the devices on itself. can i follow any hp controller driver
> > example to do the above or is there any specific driver/eg i can
> > follow? noted your point on reading the spec for the details and i
> > am on it.
>
> You might get away with it for your limited hardware platform, but all
> bets are off if you plug it into something else.
>
> Again, PCI resource management is handled by the firmware/bios and the
> pci hotplug controller. You can try to fake it out, with limited
> success, but really, why do you want to do so? Just use a real
> machine, that's what the pci hotplug hardware was designed for. It's
> much cheaper than trying to work around it in the end, trust me...
>
> greg k-h
^ permalink raw reply
* Re: Assign BAR address for pci device after hotplug
From: Greg KH @ 2016-08-09 18:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AT5PR84MB0177723391A9CA3EAEE43C0088050@AT5PR84MB0177.NAMPRD84.PROD.OUTLOOK.COM>
On Tue, Aug 09, 2016 at 11:48:59AM -0700, divakar wrote:
> May be i missed one piece of information. I thought i had that in my
> inline response but just realized i missed it.
>
> Device 0 ( FPGA 0), has custom logic which will detect the presence of
> the card 1 and card 2 and controls the power switches to the same. So If
> this makes fpga0 a "hotplug controller " then i can add the resource
> management logic/code for devices on card 1 and card 2 to this driver.
> Currently fpga_0 driver does some init for some of the devices on
> itself. can i follow any hp controller driver example to do the above or
> is there any specific driver/eg i can follow? noted your point on reading
> the spec for the details and i am on it.
You might get away with it for your limited hardware platform, but all
bets are off if you plug it into something else.
Again, PCI resource management is handled by the firmware/bios and the
pci hotplug controller. You can try to fake it out, with limited
success, but really, why do you want to do so? Just use a real machine,
that's what the pci hotplug hardware was designed for. It's much
cheaper than trying to work around it in the end, trust me...
greg k-h
^ 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