root owned writeable files under /sys
Hi All,
With ofed 1.5.1 (and it appears to be the case in prior versions as well), I see the following files created under /sys which are world writeable
# find /sys -type f -perm 222 -ls 6834 0 --w--w--w- 1 root root 0 Jun 3 14:50 /sys/class/infiniband/mlx4_0/diag_counters/clear_diag 8344 0 --w--w--w- 1 root root 4096 Jun 3 14:43 /sys/class/net/ib1/delete_child 8343 0 --w--w--w- 1 root root 4096 Jun 3 14:43 /sys/class/net/ib1/create_child 8295 0 --w--w--w- 1 root root 4096 Jun 3 14:43 /sys/class/net/ib0/delete_child 8294 0 --w--w--w- 1 root root 0 Jun 3 14:39 /sys/class/net/ib0/create_child 6017 0 --w--w--w- 1 root root 4096 Jun 3 14:43 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger
ib0 & ib1 are slave interfaces corresponding to the 2 ports on a ConnectX HCA.
At least the create_child & delete_child files appear to be dangerous to leave as world writeable because they result in resources allocations. I'm not sure about the others. Do these have to be world writeable?
- Sumeet
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Sumeet Lahorani
I see the following files created under /sys which are world writeable
/sys/class/net/ib0/delete_child/sys/class/net/ib0/create_child
At least thecreate_child&delete_childfiles appear to be dangerous to leave as world writeable because they result in resources allocations.
Yes, this looks bad. The below patch fixes that, I tested it on 2.6.35-rc1
[PATCH] make ipoib child entries non-world writable
Sumeet Lahorani <[email protected]> reported that the ipoib child entries are world writable, fix them to be root only writable
drivers/infiniband/ulp/ipoib/ipoib_main.c +2 -2
@@ -1163,7 +1163,7 @@ static ssize_t create_child(struct device *dev,return ret ? ret : count; } -static DEVICE_ATTR(create_child, S_IWUGO, NULL, create_child); +static DEVICE_ATTR(create_child, S_IWUSR, NULL, create_child); static ssize_t delete_child(struct device *dev, struct device_attribute *attr,
@@ -1183,7 +1183,7 @@ static ssize_t delete_child(struct device *dev,return ret ? ret : count; } -static DEVICE_ATTR(delete_child, S_IWUGO, NULL, delete_child); +static DEVICE_ATTR(delete_child, S_IWUSR, NULL, delete_child);int ipoib_add_pkey_attr (struct net_device *dev) {
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks. I realized that my earlier find command didn't capture all the files I was looking for. After your patch, the following still need to be addressed (all are mlx4 files)
# find /sys -type f -perm -222 /sys/class/infiniband/mlx4_0/diag_counters/clear_diag /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1
- Sumeet
Quoted 32 lines · Or Gerlitz
Quoted 6 lines · Sumeet Lahorani
I see the following files created under /sys which are world writeable
/sys/class/net/ib0/delete_child/sys/class/net/ib0/create_child
At least thecreate_child&delete_childfiles appear to be dangerous to leave as world writeable because they result in resources allocations.Yes, this looks bad. The below patch fixes that, I tested it on 2.6.35-rc1
[PATCH] make ipoib child entries non-world writable
Sumeet Lahorani <[email protected]> reported that the ipoib child entries are world writable, fix them to be root only writable
drivers/infiniband/ulp/ipoib/ipoib_main.c +1
-1@@ -1163,7 +1163,7 @@ static ssize_t create_child(struct device *dev,return ret ? ret : count; } -static DEVICE_ATTR(create_child, S_IWUGO, NULL, create_child); +static DEVICE_ATTR(create_child, S_IWUSR, NULL, create_child); static ssize_t delete_child(struct device *dev, struct device_attribute *attr,
drivers/infiniband/ulp/ipoib/ipoib_main.c static ssize_t delete_child(struct device *dev, · line 1189
Quoted 8 lines
drivers/infiniband/ulp/ipoib/ipoib_main.c +1
-1@@ -1183,7 +1183,7 @@ static ssize_t delete_child(struct device *dev,return ret ? ret : count; } -static DEVICE_ATTR(delete_child, S_IWUGO, NULL, delete_child); +static DEVICE_ATTR(delete_child, S_IWUSR, NULL, delete_child);int ipoib_add_pkey_attr (struct net_device *dev) {
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines · Sumeet Lahorani
Thanks. I realized that my earlier find command didn't capture all the files I was looking for. After your patch, the following still need to be addressed (all are mlx4 files)
&& all are not part of the mainline kernel, as such, you should approach the ofed maintainers or make a comment when the relevant code is submitted upstream.
Or.
Quoted 4 lines
/sys/class/infiniband/mlx4_0/diag_counters/clear_diag/sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
I don't understand why mlx4_port1 and mlx4_port2 have world write permissions on your system. I can't see this from the sources nor from installing ofed-1.5.1 on my system. I agree though that the permissions for port_trigger and clear_diag should be changed. We'll push a fix to OFED 1.5.2.
Quoted 51 lines · Sumeet Lahorani
Thanks. I realized that my earlier find command didn't capture all the files I was looking for. After your patch, the following still need to be addressed (all are mlx4 files)
# find /sys -type f -perm -222 /sys/class/infiniband/mlx4_0/diag_counters/clear_diag /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1- Sumeet
Quoted 37 lines · Or Gerlitz
Quoted 7 lines · Sumeet Lahorani
I see the following files created under /sys which are world writeable
/sys/class/net/ib0/delete_child/sys/class/net/ib0/create_child
At least thecreate_child&delete_childfiles appear to be dangerous to leave as world writeable because they result in resources allocations.Yes, this looks bad. The below patch fixes that, I tested it on 2.6.35-rc1
[PATCH] make ipoib child entries non-world writable
Sumeet Lahorani <[email protected]> reported that the ipoib child entries are world writable, fix them to be root only writable
drivers/infiniband/ulp/ipoib/ipoib_main.c +2
-2@@ -1163,7 +1163,7 @@ static ssize_t create_child(struct device *dev, return ret ? ret : count; } -static DEVICE_ATTR(create_child, S_IWUGO, NULL, create_child); +static DEVICE_ATTR(create_child, S_IWUSR, NULL, create_child); static ssize_t delete_child(struct device *dev, struct device_attribute *attr,@@ -1183,7 +1183,7 @@ static ssize_t delete_child(struct device *dev, return ret ? ret : count; } -static DEVICE_ATTR(delete_child, S_IWUGO, NULL, delete_child); +static DEVICE_ATTR(delete_child, S_IWUSR, NULL, delete_child);
Quoted 9 lines
drivers/infiniband/ulp/ipoib/ipoib_main.c static ssize_t delete_child(struct device *dev,
Quoted 3 lines
drivers/infiniband/ulp/ipoib/ipoib_main.c +0
-0int ipoib_add_pkey_attr(struct net_device *dev) {--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
You are right. The mlx4_port* files are world writeable in ofed 1.4.2 but not in 1.5.1.
static int mlx4_init_port_info(struct mlx4_dev *dev, int port)
{
struct mlx4_port_info *info = &mlx4_priv(dev)->port[port];
struct attribute attr = {.name = info->dev_name,
.mode = S_IWUGO | S_IRUGO};- Sumeet
Quoted 6 lines · Eli Cohen
I don't understand why
mlx4_port1andmlx4_port2have world write permissions on your system. I can't see this from the sources nor from installing ofed-1.5.1 on my system. I agree though that the permissions forport_triggerandclear_diagshould be changed. We'll push a fix to OFED 1.5.2.
Quoted 63 lines
Quoted 60 lines · Sumeet Lahorani
Thanks. I realized that my earlier find command didn't capture all the files I was looking for. After your patch, the following still need to be addressed (all are mlx4 files)
# find /sys -type f -perm -222 /sys/class/infiniband/mlx4_0/diag_counters/clear_diag /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1- Sumeet
Quoted 32 lines · Or Gerlitz
Quoted 7 lines · Sumeet Lahorani
I see the following files created under /sys which are world writeable
/sys/class/net/ib0/delete_child/sys/class/net/ib0/create_child
At least thecreate_child&delete_childfiles appear to be dangerous to leave as world writeable because they result in resources allocations.Yes, this looks bad. The below patch fixes that, I tested it on 2.6.35-rc1
[PATCH] make ipoib child entries non-world writable
Sumeet Lahorani <[email protected]> reported that the ipoib child entries are world writable, fix them to be root only writable
drivers/infiniband/ulp/ipoib/ipoib_main.c +1
-1@@ -1163,7 +1163,7 @@ static ssize_t create_child(struct device *dev,return ret ? ret : count; } -static DEVICE_ATTR(create_child, S_IWUGO, NULL, create_child); +static DEVICE_ATTR(create_child, S_IWUSR, NULL, create_child); static ssize_t delete_child(struct device *dev, struct device_attribute *attr,drivers/infiniband/ulp/ipoib/ipoib_main.c static ssize_t delete_child(struct device *dev, · line 1189
Quoted 8 lines
drivers/infiniband/ulp/ipoib/ipoib_main.c +1
-1@@ -1183,7 +1183,7 @@ static ssize_t delete_child(struct device *dev,return ret ? ret : count; } -static DEVICE_ATTR(delete_child, S_IWUGO, NULL, delete_child); +static DEVICE_ATTR(delete_child, S_IWUSR, NULL, delete_child);int ipoib_add_pkey_attr (struct net_device *dev) {--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sysfs IPoIB root owned writable files
In reply to a message not in the archiveQuoted 4 lines
Quoted 4 lines
the following files created under /sys which are world writeable
/sys/class/net/ib0/delete_child/sys/class/net/ib0/create_child
At least thecreate_child&delete_childfiles appear to be dangerous to leave as world writeable because they result in resources allocations.
Roland,
If I see a patch in linux-rdma patchwork, e.g https://patchwork.kernel.org/patch/104502 with the below patch, does this mean it will get to be reviewed/merged towards 2.6.36, or you prefer a reminder on the list?
Or.
Quoted 22 lines
Yes, this looks bad. The below patch fixes that, I tested it on 2.6.35-rc1
[PATCH] make ipoib child entries non-world writable
Sumeet Lahorani <[email protected]> reported that the ipoib child entries are world writable, fix them to be root only writable
drivers/infiniband/ulp/ipoib/ipoib_main.c +1
-1@@ -1163,7 +1163,7 @@ static ssize_t create_child(struct device *dev,return ret ? ret : count; } -static DEVICE_ATTR(create_child, S_IWUGO, NULL, create_child); +static DEVICE_ATTR(create_child, S_IWUSR, NULL, create_child); static ssize_t delete_child(struct device *dev, struct device_attribute *attr,
drivers/infiniband/ulp/ipoib/ipoib_main.c static ssize_t delete_child(struct device *dev, · line 1189
Quoted 8 lines
drivers/infiniband/ulp/ipoib/ipoib_main.c +1
-1@@ -1183,7 +1183,7 @@ static ssize_t delete_child(struct device *dev,return ret ? ret : count; } -static DEVICE_ATTR(delete_child, S_IWUGO, NULL, delete_child); +static DEVICE_ATTR(delete_child, S_IWUSR, NULL, delete_child);int ipoib_add_pkey_attr (struct net_device *dev) {
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Roland Dreier
Appliedthanks, applied
Signature · 6 lines
Roland Dreier <[email protected]> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: root owned writable files under /sys
In reply to a message not in the archiveQuoted 4 lines · Sumeet Lahorani
# find /sys -type f -perm -222 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1
Jack, Tziporet
Can you clarify the status of the upstream kernel mlx4 multi-protocol support? looking on Linus git, I see one commit, 7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5 "mlx4_core: Multiple port type support" dated to Oct 2008, wheres ofed ships couple of patches touching this area, e.g adding the above sysfs entries. So what is the extra functionality introduced or bug/s fixed by those patches? any reason not to push them upstream?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: root owned writable files under /sys
In reply to a message not in the archiveQuoted 5 lines · Or Gerlitz
Jack, Tziporet
Can you clarify the status of the upstream kernel mlx4 multi-protocol support? looking on Linus git, I see one commit,
7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5"mlx4_core: Multiple port type support" dated to Oct 2008, wheres ofed ships couple of patches touching this area, e.g adding the above sysfs entries. So what is the extra functionality introduced or bug/s fixed by those patches? any reason not to push them upstream?
Jack is on vacation and will be back in 2 weeks
I will ask him to look at this when he is back
Tziporet
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: root owned writable files under /sys
In reply to a message not in the archiveQuoted 1 line · Tziporet Koren
Jack is on vacation and will be back in 2 weeks. I will ask him to look at this when he is back
All this could have been much simpler if Yevgeny was responding, he's signed on the multi-protocol related patches shipped with ofed. So far, I had hard time getting responses form him on any of the notes I sent re mlx4_en and _core
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 1 line · Roland Dreier
thanks, applied
I don't see it, and none of the other patches you accepted last night, in the for-next brach of yours, where are they...?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines
I don't see it, and none of the other patches you accepted last night, in the for-next brach of yours, where are they...?
Sitting on my local system ;)
Forgot to do git push to kernel.org.
Signature · 6 lines
Roland Dreier <[email protected]> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: root owned writable files under /sys
In reply to a message not in the archiveOr,
The sysfs entries you refer to are actually introduced in commit 7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5. Which patches in ofed but not upstream are you referring to?
-Jack
-----Original Message-----
From: Or Gerlitz [mailto:ogerlitz-hKgKHo2Ms0FWk0Htik3J/[email protected]]
Sent: Wednesday, July 07, 2010 8:42 AM
To: Sumeet Lahorani; Jack Morgenstein; Tziporet Koren
Cc: Roland Dreier; [email protected]
Subject: Re: root owned writable files under /sys
Quoted 4 lines · Sumeet Lahorani
# find /sys -type f -perm -222 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1
Jack, Tziporet
Can you clarify the status of the upstream kernel mlx4 multi-protocol support? looking on Linus git, I see one commit, 7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5 "mlx4_core: Multiple port type support" dated to Oct 2008, wheres ofed ships couple of patches touching this area, e.g adding the above sysfs entries. So what is the extra functionality introduced or bug/s fixed by those patches? any reason not to push them upstream?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: root owned writable files under /sys
In reply to a message not in the archiveQuoted 2 lines · Jack Morgenstein
The sysfs entries you refer to are introduced in commit
7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5which patches in ofed but not upstream are you referring to?
Hi Jack,
I took another look, indeed the mlx4_port{1,2} sysfs entries are introduced in the commit you pointed on and their permissions looks okay (S_IRUGO | S_IWUSR), they are not world writable.
As for the port_trigger sysfs entry, it is introduced by a patch shipped with ofed which isn't upstream (mlx4_1190_sense_port_trigger.patch) and indeed this entry is world writable.
So the question here, if there's any reason for multi-protocol related patches such as this
guy and its such not to be pushed upstream? I failed to get any constructive response (== pathces to Roland or Dave Miller) from Yevgeny and I was hoping you could be helpful here.
Or.
Quoted 5 lines
Quoted 4 lines · Sumeet Lahorani
# find /sys -type f -perm -222 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: root owned writable files under /sys
In reply to a message not in the archiveJack,
I didn't see any further response on the matter, I got customers to complain on why the port_trigger sysfs entry is world writable and I wonder why isn't this pushed upstream, once you guys do that we can fix the permissions. Also they noted that the diag_counters entry has the same problem and its also not upstream (ofed patch mlx4_0320_diag_counters_sysfs.patch), can some progress be made here?
Or.
Quoted 17 lines · Or Gerlitz
Quoted 2 lines · Jack Morgenstein
The sysfs entries you refer to are introduced in commit
7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5which patches in ofed but not upstream are you referring to?Hi Jack,
I took another look, indeed the mlx4_port{1,2} sysfs entries are introduced in the commit you pointed on and their permissions looks okay (
S_IRUGO|S_IWUSR), they are not world writable.As for the
port_triggersysfs entry, it is introduced by a patch shipped with ofed which isn't upstream (mlx4_1190_sense_port_trigger.patch) and indeed this entry is world writable.So the question here, if there's any reason for multi-protocol related patches such as this
guy and its such not to be pushed upstream? I failed to get any constructive response (== pathces to Roland or Dave Miller) from Yevgeny and I was hoping you could be helpful here.Or.
Quoted 1 line
Sumeet Lahorani wrote:
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
# find /sys -type f -perm -222 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: root owned writable files under /sys
In reply to a message not in the archivePort trigger belongs to Yevgeny P.
Please interact with him regarding this.
-Jack
-----Original Message-----
From: Or Gerlitz [mailto:ogerlitz-hKgKHo2Ms0FWk0Htik3J/[email protected]]
Sent: Thursday, November 18, 2010 11:55 AM
To: Jack Morgenstein
Cc: Sumeet Lahorani; Tziporet Koren; Roland Dreier; [email protected]; Yevgeny Petrilin
Subject: Re: root owned writable files under /sys
Jack,
I didn't see any further response on the matter, I got customers to complain on why the port_trigger sysfs entry is world writable and I wonder why isn't this pushed upstream, once you guys do that we can fix the permissions. Also they noted that the diag_counters entry has the same problem and its also not upstream (ofed patch mlx4_0320_diag_counters_sysfs.patch), can some progress be made here?
Or.
Quoted 17 lines · Or Gerlitz
Quoted 2 lines · Jack Morgenstein
The sysfs entries you refer to are introduced in commit
7ff93f8b7ecbc36e7ffc5c11a61643821c1bfee5which patches in ofed but not upstream are you referring to?Hi Jack,
I took another look, indeed the mlx4_port{1,2} sysfs entries are introduced in the commit you pointed on and their permissions looks okay (
S_IRUGO|S_IWUSR), they are not world writable.As for the
port_triggersysfs entry, it is introduced by a patch shipped with ofed which isn't upstream (mlx4_1190_sense_port_trigger.patch) and indeed this entry is world writable.So the question here, if there's any reason for multi-protocol related patches such as this
guy and its such not to be pushed upstream? I failed to get any constructive response (== pathces to Roland or Dave Miller) from Yevgeny and I was hoping you could be helpful here.Or.
Quoted 1 line
Sumeet Lahorani wrote:
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
# find /sys -type f -perm -222 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/port_trigger /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port2 /sys/devices/pci0000:00/0000:00:04.0/0000:13:00.0/mlx4_port1--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: root owned writable files under /sys
In reply to a message not in the archiveQuoted 1 line · Jack Morgenstein
Port trigger belongs to Yevgeny P. Please interact with him regarding this.
I know, the thing is that I failed to get any response from him on the matter
of pushing it upstream for long time, and this is IB related patch, so I tried to pull you on that... Yevgeny, could you push that patch any time soon?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: root owned writable files under /sys
In reply to a message not in the archiveYevgeny is going to RD next week
Will see if someone can work on this here before he returns
Tziporet
-----Original Message-----
From: Or Gerlitz [mailto:ogerlitz-hKgKHo2Ms0FWk0Htik3J/[email protected]]
Sent: Thursday, November 18, 2010 3:03 PM
To: Jack Morgenstein; Yevgeny Petrilin
Cc: Sumeet Lahorani; Tziporet Koren; [email protected]
Subject: Re: root owned writable files under /sys
Quoted 1 line · Jack Morgenstein
Port trigger belongs to Yevgeny P. Please interact with him regarding this.
I know, the thing is that I failed to get any response from him on the matter
of pushing it upstream for long time, and this is IB related patch, so I tried to pull you on that... Yevgeny, could you push that patch any time soon?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html