Re: [PATCH 0/5] Networking cgroup controller

[Alexei Starovoitov]

On Thu, Aug 25, 2016 at 11:56:27AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Thu, Aug 25, 2016 at 11:04 AM, Alexei Starovoitov
>  wrote:
> > On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) 
> > wrote:
> >> On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo  wrote:
> >> > Hello, Anoop.
> >> >
> >> > On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote:
> >> >> This patchset introduces a cgroup controller for the networking 
> >> >> subsystem as a
> >> >> whole. As of now, this controller will be used for:
> >> >>
> >> >> * Limiting the specific ports that a process in a cgroup is allowed to 
> >> >> bind
> >> >>   to or listen on. For example, you can say that all the processes in a
> >> >>   cgroup can only bind to ports 1000-2000, and listen on ports 
> >> >> 1000-1100, which
> >> >>   guarantees that the remaining ports will be available for other 
> >> >> processes.
> >> >>
> >> >> * Restricting which DSCP values processes can use with their sockets. 
> >> >> For
> >> >>   example, you can say that all the processes in a cgroup can only send
> >> >>   packets with a DSCP tag between 48 and 63 (corresponding to TOS 
> >> >> values of
> >> >>   192 to 255).
> >> >>
> >> >> * Limiting the total number of udp ports that can be used by a process 
> >> >> in a
> >> >>   cgroup. For example, you can say that all the processes in one cgroup 
> >> >> are
> >> >>   allowed to use a total of up to 100 udp ports. Since the total number 
> >> >> of udp
> >> >>   ports that can be used by all processes is limited, this is useful for
> >> >>   rationing out the ports to different process groups.
> >> >>
> >> >> In the future, more networking-related properties may be added to this
> >> >> controller.
> >> >
> >> > Thanks for working on this; however, I share the sentiment expressed
> >> > by others that this looks like too piecemeal an approach.  If there
> >> > are no alternatives, we surely should consider this but it at least
> >> > *looks* like bpf should be able to cover the same functionalities
> >> > without having to revise and extend in-kernel capabilities constantly.
> >> >
> >> My primary concern is the cost that need to be paid to get this 
> >> functionality.
> >> (a) The suggested alternatives eBPF either can't solve the problem in
> >> the current form or need substantial work to get it done. e.g.
> >> udp-port-limit since there is no notion of "maintaining
> >> counters-per-group-of-processes". This is solved by the cgroup infra.
> >
> > what is specifically missing?
> > there are several ways to do counters in bpf and as soon as bpf program
> > is attachable to a cgroup, all of these counter features come for free.
> > Counting bytes or packets or port bind failures or anything else per cgroup
> > with bpf is trivial. No extra code is needed.
> >
> Alexei, I was referring to the association of eBPF to the cgroup. Lack
> of it makes anyone wants to use it invest into additional
> administrative infra that you are currently getting with cgroup-infra.

Please look at Daniel's patches. They have been circulating in different
forms for quite some time now. Your bind port filter use case can be
easily added on top. Then the end result is additional ten lines of code
instead of hundreds.
Another alternative is to go cgroup+lsm+bpf route that Sargun and Mickael
are proposing. I think it will also work for your use case.
The goal we all should have is to have common infra that solves the
largest number of use cases.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

[Luis R. Rodriguez]

On Thu, Aug 25, 2016 at 10:10:52PM +0200, Daniel Vetter wrote:
> Cutting down since a lot of this is probably better discussed at
> ks/lpc. Aside, if you want to check out Chris Wilson's work on our new
> depency handling, it's called kfence.
> 
> https://lkml.org/lkml/2016/7/17/37

Thanks more reading.. :)

> On Thu, Aug 25, 2016 at 9:41 PM, Luis R. Rodriguez  wrote:
> >> > So .. I agree, let's avoid the hacks. Patches welcomed.
> >>
> >> Hm, this is a definite change of tack - back when I discussed this
> >> with Greg about 2 ks ago it sounded like "don't do this". The only
> >> thing we need is some way to wait for rootfs before we do the
> >> request_firmware. Everything else we handle already in the kernel.
> >
> > OK so lets just get this userspace event done, and we're set.
> 
> Ah great. As long as that special wait-for-rootfs-pls firmware request
> is still allowed, i915 folks will be happy. We will call it from
> probe though ;-) but all from our own workers.

We should strive for this to be transparent to drivers, ie, this safeguard of
looking for firmware should be something handled by the kernel as otherwise
we're just forcing a race condition given the review in the last thread.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] docs: split up the driver book

[Jonathan Corbet]

On Tue, 23 Aug 2016 11:30:16 -0300
Mauro Carvalho Chehab  wrote:

> I noticed several issues on the converted document. Just commenting
> a few of them, as they all follow a pattern: kernel-doc markups
> needs review during the conversion to RST, because, unfortunately,
> the conversion is not transparent, as we would want to.

So getting to a couple of others here...

> Also, you should notice that it added several references to
> kthread_create(), with is actually a define:
> 
>   include/linux/kthread.h:#define kthread_create(threadfn, data, namefmt, 
> arg...) \
> 
> It probably makes sense to add some markup for kernel-doc to parse it.

I have a patch for that now, will send it shortly.

> The description for:
> 
>int KickStart(MPT_ADAPTER * ioc, int force, int sleepFlag)
> 
> Looked weird on my eyes. The original kernel-nano tag is:

I thought about fixing these up, but, in the end, the bulk of the funky
stuff from the fusion driver is pulled in with :internal:.  That, I think,
makes little sense for a "driver API" book.  So I'm really inclined to just
remove those includes altogether; they can be added in the future if
somebody puts together an internals book for that driver.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Alan Stern]

On Thu, 25 Aug 2016, Alan Stern wrote:

> > Does the lsusb command do the mapping in the user space or maybe
> > it takes the names from kernel?
> 
> lsusb does the mapping in userspace, based on an ID database.  On my 
> system (Fedora), the database is /etc/udev/hwdb.bin.

There's also /usr/share/hwdata/usb.ids -- I don't know if or how the
two databases are related.  And there's /usr/lib/udev/hwdb.d/20-usb*.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

[Luis R. Rodriguez]

Summoning Felix for the embedded aspect on initramfs below.
Jörg might be interested in the async facilities you speak of as well.

On Thu, Aug 25, 2016 at 01:05:44PM +0200, Daniel Vetter wrote:
> On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez  wrote:
> > On Wed, Aug 24, 2016 at 08:55:55AM +0200, Daniel Vetter wrote:
> >> On Fri, Jun 17, 2016 at 12:54 AM, Luis R. Rodriguez  
> >> wrote:
> >> > Thou shalt not make firmware calls early on init or probe.
> >
> > <-- snip -->
> >
> >> > There are 4 offenders at this time:
> >> >
> >> > mcgrof@ergon ~/linux-next (git::20160609)$ export 
> >> > COCCI=scripts/coccinelle/api/request_firmware.cocci
> >> > mcgrof@ergon ~/linux-next (git::20160609)$ make coccicheck MODE=report
> >> >
> >> > drivers/fmc/fmc-fakedev.c: ERROR: driver call request firmware call on 
> >> > its init routine on line 321.
> >> > drivers/fmc/fmc-write-eeprom.c: ERROR: driver call request firmware call 
> >> > on its probe routine on line 136.
> >> > drivers/tty/serial/rp2.c: ERROR: driver call request firmware call on 
> >> > its probe routine on line 796.
> >> > drivers/tty/serial/ucc_uart.c: ERROR: driver call request firmware call 
> >> > on its probe routine on line 1246.
> >>
> >> Plus all gpu drivers which need firmware. And yes we must load them at
> >> probe
> >
> > Do you have an upstream driver in mind that does this ? Is it on device
> > drier module probe or a DRM subsystem specific probe call of some sort ?
> 
> i915 is the one I care about for obvious reasons ;-) It's all from the
> pci device probe function, but nested really deeply.

The above SmPL grammar should capture well nested calls of calls within probe,
so curious why it didn't pick up i915. Let's see.

i915_pci_probe() --> i915_driver_load() -->
i915_load_modeset_init() --> (drivers/gpu/drm/i915/i915_drv.c)
a) intel_csr_ucode_init() (drivers/gpu/drm/i915/intel_csr.c)
...
b) intel_guc_init() (drivers/gpu/drm/i915/intel_guc_loader.c)

The two firmwares come from:

a) intel_csr_ucode_init() --> schedule_work(_priv->csr.work);
csr_load_work_fn() --> request_firmware()

b) intel_guc_init() --> guc_fw_fetch() request_firmware()

---

a) is not dealt with given the grammar does not include scheduled work,
however using work to offload loading firmware seems reasonable here.

b) This should have been picked up, but its not. Upon closer inspection
   the grammar currently expects the module init and probe to be on the
   same file. Loosening this:

diff --git 
a/scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci 
b/scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
index cf180c59e042..e19e6d3dfc0f 100644
--- a/scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
+++ b/scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
@@ -49,7 +49,7 @@ identifier init;
 
 module_init(init);
 
-@ has_probe depends on defines_module_init@
+@ has_probe @
 identifier drv_calls, drv_probe;
 type bus_driver;
 identifier probe_op =~ "(probe)";
@@ -59,7 +59,7 @@ bus_driver drv_calls = {
.probe_op = drv_probe,
 };
 
-@hascall depends on !after_start && defines_module_init@
+@hascall depends on !after_start @
 position p;
 @@
 

I get a lot more complaints but still -- i915 b) case is not yet covered:

./drivers/bluetooth/ath3k.c: ERROR: driver call request firmware call on its 
probe routine on line 546.
./drivers/bluetooth/bcm203x.c: ERROR: driver call request firmware call on its 
probe routine on line 193.
./drivers/bluetooth/bcm203x.c: ERROR: driver call request firmware call on its 
probe routine on line 218.
./drivers/bluetooth/bfusb.c: ERROR: driver call request firmware call on its 
probe routine on line 655.
./drivers/fmc/fmc-fakedev.c: ERROR: driver call request firmware call on its 
init routine on line 321.
./drivers/fmc/fmc-write-eeprom.c: ERROR: driver call request firmware call on 
its probe routine on line 136.
./drivers/tty/serial/ucc_uart.c: ERROR: driver call request firmware call on 
its probe routine on line 1246.
./sound/soc/codecs/wm2000.c: ERROR: driver call request firmware call on its 
probe routine on line 893.
./sound/soc/sh/siu_dai.c: ERROR: driver call request firmware call on its probe 
routine on line 747.
./drivers/net/wireless/intersil/orinoco/orinoco_usb.c: ERROR: driver call 
request firmware call on its probe routine on line 1661.
./sound/soc/intel/common/sst-acpi.c: ERROR: driver call request firmware call 
on its probe routine on line 161.
./drivers/input/touchscreen/goodix.c: ERROR: driver call request firmware call 
on its probe routine on line 744.
./drivers/media/usb/go7007/go7007-loader.c: ERROR: driver call request firmware 
call on its probe routine on line 78.
./drivers/media/usb/go7007/go7007-loader.c: ERROR: driver call request firmware 
call on its probe routine on line 93.
./drivers/tty/serial/rp2.c: ERROR: driver call 

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Jonathan Corbet]

On Wed, 24 Aug 2016 13:06:45 +0800
Baoquan He  wrote:

> Hi Jon, do you think change as below is OK to you?

So nr_cpus is the maximum value, and maxcpus is the current number.
Figures.  No wonder the documentation is confusing...

Anyway, this is much more along the lines of what I was hoping for, yes;
I'll go ahead and apply it.  Many thanks for humoring me on this!

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Networking cgroup controller

[महेश बंडेवार]

On Thu, Aug 25, 2016 at 9:09 AM, Tejun Heo  wrote:
> Hello, Mahesh.
>
> On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) 
> wrote:
>> In short most of the associated problems are handled by the
>> cgroup-infra / APIs while all that need separate solution in
>> alternatives.  Tejun, feels like I'm advocating cgroup approach to you
>> ;)
>
> My concern here is that the proposed fixed mechanism isn't gonna be
> enough.  Port range matching wouldn't scale, so we'd need some hashmap
> style thing which may be too expensive for simple matches so either we
> do something adaptive or have different interfaces for the two and so
> on.  IOW, I think this approach is likely to replicate what iptables
> have been doing with its extensions.  I don't doubt that it is one of
> the workable approaches but hardly an attractive one especially at
> this point.
>
> ebpf approach does have its shortcomings for sure but mending them
> seems a lot more manageable and future-proof than going with fixed but
> constantly expanding set of operations.  e.g. We can add per-cgroup
> bpf programs which are called only on socket creation or other major
> events, or just let bpf programs which get called on bind(2), and add
> some per-cgroup state variables which are maintained by cgroup code
> which can be used from these bpf programs.
>
Well, I haven't seen any of these yet (please point me the right place
if I missed) Especially the hooks that allows users to add per-cgroup
bpf programs that can be used in control-path (I think Daniel's recent
patches allow in data-path).

> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

[Bjørn Mork]

Greg KH  writes:
> On Thu, Aug 25, 2016 at 07:14:52AM +0200, Rafał Miłecki wrote:
>>
>> Good question. I would like to extend this USB port trigger in the
>> future by reacting to USB activity. This involves playing with URBs
>> and I believe that at that point it'd be getting too much USB specific
>> to /rule them all/.
>
> Oh that's never going to work, sorry.  USB "activity" happens deep in
> USB host controller hardware, not up at the kernel level at all.  It's
> just too fast, and would take up too much CPU to do it otherwise.  Heck,
> even old UHCI 1.1 USB controllers did this.
>
> USB "activity" happens all the time, look at a USB bus analyzer if you
> want to see what goes on.  Teasing out what is "real data" and what is
> just "normal bus activity" is impossible at the kernel level,

OK, I am going to play stupid again: Does this mean that usbmon is
impossible?

> and really
> makes no sense at all (your led would just be "on" all the time.)

I don't see how this is any different from e.g. the network activity
triggers.

FWIW, on my system "cat /sys/kernel/debug/usb/usbmon/0u" can be silent
for long periods, and show a rush of lines whenever there is USB
activity.  I imagine that a LED triggered by a hook in a similar place
would be useful on systems with LEDs for that sort of stuff.


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Jacek Anaszewski]

On 08/25/2016 04:30 PM, Alan Stern wrote:

On Thu, 25 Aug 2016, Jacek Anaszewski wrote:


I'd see it as follows:

#cat available_ports
#1-1 1-2 2-1

#echo "1-1" > new_port

#cat observed_ports
#1-1

#echo "2-1" > new_port

#cat observed_ports
#1-1 2-1

We've already had few discussions about the sysfs designs trying
to break the one-value-per-file rule for LED class device, and
there was always strong resistance against.


This scheme has multiple values in both the available_ports and
observed_ports files.  :-(  Not that I have any better suggestions...


Right, I forgot to add a note here, that this follows space
separated list pattern similarly as in case of triggers attribute.
Of course other suggestions are welcome.


Also a description of the device connected to the port would be a nice
feature, however I am not certain about the feasibility thereof.


What kind of description do you mean? Where should it be used / where
should it appear?



Product name/symbol. Actually it should be USB subsystem responsibility
to provide the means for querying the product name by port id, if it
is possible at all.


cat /sys/bus/usb/devices/PORT/product
cat /sys/bus/usb/devices/PORT/manufacturer

These will work if there is a device registered under PORT.


I've found only idProduct and idVendor files. They indeed uniquely
identify the device, but the numbers are not human readable.
Is there a way to retrieve the corresponding names in kernel?
Does the lsusb command do the mapping in the user space or maybe
it takes the names from kernel?

--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Networking cgroup controller

[Alexei Starovoitov]

On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo  wrote:
> > Hello, Anoop.
> >
> > On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote:
> >> This patchset introduces a cgroup controller for the networking subsystem 
> >> as a
> >> whole. As of now, this controller will be used for:
> >>
> >> * Limiting the specific ports that a process in a cgroup is allowed to bind
> >>   to or listen on. For example, you can say that all the processes in a
> >>   cgroup can only bind to ports 1000-2000, and listen on ports 1000-1100, 
> >> which
> >>   guarantees that the remaining ports will be available for other 
> >> processes.
> >>
> >> * Restricting which DSCP values processes can use with their sockets. For
> >>   example, you can say that all the processes in a cgroup can only send
> >>   packets with a DSCP tag between 48 and 63 (corresponding to TOS values of
> >>   192 to 255).
> >>
> >> * Limiting the total number of udp ports that can be used by a process in a
> >>   cgroup. For example, you can say that all the processes in one cgroup are
> >>   allowed to use a total of up to 100 udp ports. Since the total number of 
> >> udp
> >>   ports that can be used by all processes is limited, this is useful for
> >>   rationing out the ports to different process groups.
> >>
> >> In the future, more networking-related properties may be added to this
> >> controller.
> >
> > Thanks for working on this; however, I share the sentiment expressed
> > by others that this looks like too piecemeal an approach.  If there
> > are no alternatives, we surely should consider this but it at least
> > *looks* like bpf should be able to cover the same functionalities
> > without having to revise and extend in-kernel capabilities constantly.
> >
> My primary concern is the cost that need to be paid to get this functionality.
> (a) The suggested alternatives eBPF either can't solve the problem in
> the current form or need substantial work to get it done. e.g.
> udp-port-limit since there is no notion of "maintaining
> counters-per-group-of-processes". This is solved by the cgroup infra.

what is specifically missing?
there are several ways to do counters in bpf and as soon as bpf program
is attachable to a cgroup, all of these counter features come for free.
Counting bytes or packets or port bind failures or anything else per cgroup
with bpf is trivial. No extra code is needed.

> (b) Also the hooks implemented are mostly with a per packet cost vs.
> once when you are establishing the channel. Also not sure if the LSM
> approach will allow some privileged user to over-ride the filters
> attached and thus override the limits imposed. This is on top of the
> administrative costs that currently don't have solution for and you
> get it for free with cgroup infra.
> 
> In short most of the associated problems are handled by the
> cgroup-infra / APIs while all that need separate solution in
> alternatives.  Tejun, feels like I'm advocating cgroup approach to you
> ;)
> 
> Thanks,
> --mahesh..
> 
> 
> > Thanks.
> >
> > --
> > tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Networking cgroup controller

[Tejun Heo]

On Thu, Aug 25, 2016 at 12:09:20PM -0400, Tejun Heo wrote:
> ebpf approach does have its shortcomings for sure but mending them
> seems a lot more manageable and future-proof than going with fixed but
> constantly expanding set of operations.  e.g. We can add per-cgroup
> bpf programs which are called only on socket creation or other major
> events, or just let bpf programs which get called on bind(2), and add
^^
please ignore this part. half-assed edit.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: imgmath and PDF output

[Mauro Carvalho Chehab]

Em Thu, 25 Aug 2016 10:47:50 -0300
Mauro Carvalho Chehab  escreveu:

> Em Thu, 25 Aug 2016 15:03:16 +0200
> Markus Heiser  escreveu:
> 
> > Hi Jon, Mauro, Jani,
> > 
> > today I tested imgmath, it worked well, but needs an
> > additional dvipng installation ...
> > 
> > What do you think, should we document the prerequisites
> > on different linux distributions to build documentation
> > with sphinx.ext.imgmath and PDF output?
> > 
> > What I mean, in the meantime we have two PDF applications,
> > the imgmath uses "latex" (plus dvipng) and the PDF output 
> > uses "xetex".
> > 
> > I tested on a ubuntu 16.04 sandbox, so my experience is,
> > on a debian based system it should be enough to install 
> > *base*, *xetex* and *recommended* -TeX packages, the 
> > imgmath extensions needs an additional dvipng package::
> > 
> >sudo apt-get install \
> >  dvipng texlive-base texlive-xetex \
> >  texlive-latex-recommended

Double-checked: on Ubuntu Xenial, from an LXC image created from
scratch, those are the needed packages:
apt-get install texlive-xetex python3-sphinx python3-sphinx-rtd-theme 
ttf-dejavu dvipng make gcc

I found weird that it would need gcc for html generation, but without it,
the Kernel build doesn't work:

$ make htmldocs
make: gcc: Command not found
make: gcc: Command not found
  HOSTCC  scripts/basic/fixdep
/bin/sh: 1: gcc: not found
scripts/Makefile.host:107: recipe for target 'scripts/basic/fixdep' 
failed

With the above packages, I checked for htmldocs, latexdocs, pdfdocs
and epubdocs makefile targets.

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Networking cgroup controller

[Tejun Heo]

Hello, Mahesh.

On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote:
> In short most of the associated problems are handled by the
> cgroup-infra / APIs while all that need separate solution in
> alternatives.  Tejun, feels like I'm advocating cgroup approach to you
> ;)

My concern here is that the proposed fixed mechanism isn't gonna be
enough.  Port range matching wouldn't scale, so we'd need some hashmap
style thing which may be too expensive for simple matches so either we
do something adaptive or have different interfaces for the two and so
on.  IOW, I think this approach is likely to replicate what iptables
have been doing with its extensions.  I don't doubt that it is one of
the workable approaches but hardly an attractive one especially at
this point.

ebpf approach does have its shortcomings for sure but mending them
seems a lot more manageable and future-proof than going with fixed but
constantly expanding set of operations.  e.g. We can add per-cgroup
bpf programs which are called only on socket creation or other major
events, or just let bpf programs which get called on bind(2), and add
some per-cgroup state variables which are maintained by cgroup code
which can be used from these bpf programs.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/19] compat ABI: use non-compat openat and open_by_handle_at variants

[Arnd Bergmann]

On Monday, August 15, 2016 5:30:28 PM CEST Yury Norov wrote:
> On Mon, Jun 27, 2016 at 09:47:38AM +0200, Andreas Schwab wrote:
> > Yury Norov  writes:
> > 
> > > The only difference is that non-compat version forces O_LARGEFILE,
> > > and it should be the default behaviour for all architectures, as
> > > we don't support 32-bit off_t. The only exception is tile32, that
> > > continues with compat version of syscalls.
> > >
> > > Signed-off-by: Yury Norov 
> > > Acked-by: Arnd Bergmann 
> > > Acked-by: Chris Metcalf  [for tile]
> > > ---
> > >  arch/tile/kernel/compat.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/tile/kernel/compat.c b/arch/tile/kernel/compat.c
> > > index 4912084..489ae19 100644
> > > --- a/arch/tile/kernel/compat.c
> > > +++ b/arch/tile/kernel/compat.c
> > > @@ -94,6 +94,9 @@ COMPAT_SYSCALL_DEFINE5(llseek, unsigned int, fd, 
> > > unsigned int, offset_high,
> > >  #define compat_sys_readahead sys32_readahead
> > >  #define sys_llseek compat_sys_llseek
> > >  
> > > +#define sys_openat   compat_sys_openat
> > > +#define sys_open_by_handle_atcompat_sys_open_by_handle_at
> > > +
> > >  /* Call the assembly trampolines where necessary. */
> > >  #define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn
> > >  #define sys_clone _sys_clone
> > 
> > This is a no-op.  Did you mean to add this?  Without that the testsuite
> > of tar fails on ILP32.
> 
> The change you suggest below is what I originally sent at the end of
> December, but that chunk was lost after one of numerous rebases probably.
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1512.3/00510.html
> 
> IIRC, the only difference between this couple of syscalls and their
> compat versions is that non-compat syscalls set O_LARGEFILE depending
> on (BITS_PER_LONG != 32). Next patch of this series introduces
> ARCH_32BIT_OFF_T config option to force O_LARGEFILE for 64-bit arches,
> and all new 32-bit arches, as ARCH_32BIT_OFF_T is enabled for existing
> 32-bit arches explicitly.
> 
> O_LARGEFILE is controlled like this:
> -#define force_o_largefile() (BITS_PER_LONG != 32)
> +#define force_o_largefile() (!IS_ENABLED(CONFIG_ARCH_32BIT_OFF_T))
> 
> So if I restore original patch, everything will work. But my question
> is: if ARCH_32BIT_OFF_T disables O_LARGEFILE for tile32 anyway, what
> for we redirect native syscall handlers to compat ones? They are
> looking identical...

I've lost context here, but let me try to recall what we had
discussed in the past:

- native 32-bit architectures are handled using CONFIG_ARCH_32BIT_OFF_T
- native 64-bit architectures keep setting the flag.
- compat 32-bit architectures need special cases, but the only one
  that exists is tile, which has to keep not setting O_LARGEFILE
  while new compat architectures (ilp32) should set it.
 
> If my understanding is correct, we can drop the change in
> arch/tile/kernel/compat.c and join this patch with next one in this
> series.
> 
> Chris, Arnd?

The change in arch/tile/kernel/compat.c can either come before the
below change, or in the same patch, but not later.

Arnd

> > diff --git a/include/uapi/asm-generic/unistd.h 
> > b/include/uapi/asm-generic/unistd.h
> > index a26415b..4dcc38d 100644
> > --- a/include/uapi/asm-generic/unistd.h
> > +++ b/include/uapi/asm-generic/unistd.h
> > @@ -178,7 +178,7 @@ __SYSCALL(__NR_fchownat, sys_fchownat)
> >  #define __NR_fchown 55
> >  __SYSCALL(__NR_fchown, sys_fchown)
> >  #define __NR_openat 56
> > -__SC_COMP(__NR_openat, sys_openat, compat_sys_openat)
> > +__SYSCALL(__NR_openat, sys_openat)
> >  #define __NR_close 57
> >  __SYSCALL(__NR_close, sys_close)
> >  #define __NR_vhangup 58
> > @@ -676,8 +676,7 @@ __SYSCALL(__NR_fanotify_mark, sys_fanotify_mark)
> >  #define __NR_name_to_handle_at 264
> >  __SYSCALL(__NR_name_to_handle_at, sys_name_to_handle_at)
> >  #define __NR_open_by_handle_at 265
> > -__SC_COMP(__NR_open_by_handle_at, sys_open_by_handle_at, \
> > - compat_sys_open_by_handle_at)
> > +__SYSCALL(__NR_open_by_handle_at, sys_open_by_handle_at)
> >  #define __NR_clock_adjtime 266
> >  __SC_COMP(__NR_clock_adjtime, sys_clock_adjtime, compat_sys_clock_adjtime)
> >  #define __NR_syncfs 267
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Networking cgroup controller

[महेश बंडेवार]

On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo  wrote:
> Hello, Anoop.
>
> On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote:
>> This patchset introduces a cgroup controller for the networking subsystem as 
>> a
>> whole. As of now, this controller will be used for:
>>
>> * Limiting the specific ports that a process in a cgroup is allowed to bind
>>   to or listen on. For example, you can say that all the processes in a
>>   cgroup can only bind to ports 1000-2000, and listen on ports 1000-1100, 
>> which
>>   guarantees that the remaining ports will be available for other processes.
>>
>> * Restricting which DSCP values processes can use with their sockets. For
>>   example, you can say that all the processes in a cgroup can only send
>>   packets with a DSCP tag between 48 and 63 (corresponding to TOS values of
>>   192 to 255).
>>
>> * Limiting the total number of udp ports that can be used by a process in a
>>   cgroup. For example, you can say that all the processes in one cgroup are
>>   allowed to use a total of up to 100 udp ports. Since the total number of 
>> udp
>>   ports that can be used by all processes is limited, this is useful for
>>   rationing out the ports to different process groups.
>>
>> In the future, more networking-related properties may be added to this
>> controller.
>
> Thanks for working on this; however, I share the sentiment expressed
> by others that this looks like too piecemeal an approach.  If there
> are no alternatives, we surely should consider this but it at least
> *looks* like bpf should be able to cover the same functionalities
> without having to revise and extend in-kernel capabilities constantly.
>
My primary concern is the cost that need to be paid to get this functionality.
(a) The suggested alternatives eBPF either can't solve the problem in
the current form or need substantial work to get it done. e.g.
udp-port-limit since there is no notion of "maintaining
counters-per-group-of-processes". This is solved by the cgroup infra.
(b) Also the hooks implemented are mostly with a per packet cost vs.
once when you are establishing the channel. Also not sure if the LSM
approach will allow some privileged user to over-ride the filters
attached and thus override the limits imposed. This is on top of the
administrative costs that currently don't have solution for and you
get it for free with cgroup infra.

In short most of the associated problems are handled by the
cgroup-infra / APIs while all that need separate solution in
alternatives.  Tejun, feels like I'm advocating cgroup approach to you
;)

Thanks,
--mahesh..


> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Alan Stern]

On Thu, 25 Aug 2016, Jacek Anaszewski wrote:

> I'd see it as follows:
> 
> #cat available_ports
> #1-1 1-2 2-1
> 
> #echo "1-1" > new_port
> 
> #cat observed_ports
> #1-1
> 
> #echo "2-1" > new_port
> 
> #cat observed_ports
> #1-1 2-1
> 
> We've already had few discussions about the sysfs designs trying
> to break the one-value-per-file rule for LED class device, and
> there was always strong resistance against.

This scheme has multiple values in both the available_ports and 
observed_ports files.  :-(  Not that I have any better suggestions...

> >> Also a description of the device connected to the port would be a nice
> >> feature, however I am not certain about the feasibility thereof.
> >
> > What kind of description do you mean? Where should it be used / where
> > should it appear?
> >
> 
> Product name/symbol. Actually it should be USB subsystem responsibility
> to provide the means for querying the product name by port id, if it
> is possible at all.

cat /sys/bus/usb/devices/PORT/product
cat /sys/bus/usb/devices/PORT/manufacturer

These will work if there is a device registered under PORT.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: imgmath and PDF output

[Mauro Carvalho Chehab]

Em Thu, 25 Aug 2016 15:03:16 +0200
Markus Heiser  escreveu:

> Hi Jon, Mauro, Jani,
> 
> today I tested imgmath, it worked well, but needs an
> additional dvipng installation ...
> 
> What do you think, should we document the prerequisites
> on different linux distributions to build documentation
> with sphinx.ext.imgmath and PDF output?
> 
> What I mean, in the meantime we have two PDF applications,
> the imgmath uses "latex" (plus dvipng) and the PDF output 
> uses "xetex".
> 
> I tested on a ubuntu 16.04 sandbox, so my experience is,
> on a debian based system it should be enough to install 
> *base*, *xetex* and *recommended* -TeX packages, the 
> imgmath extensions needs an additional dvipng package::
> 
>sudo apt-get install \
>  dvipng texlive-base texlive-xetex \
>  texlive-latex-recommended
> 
> Jon and Mauro made there own experience with fedora, where
> the installation procedure seems much more complex.
> 
> Might it be good, to document these experiences, to preserve
> your experience?

Yes, IMHO we should document it somehow. What I do when I want to check the
minimum amount of packages to be installed is to create a LXC image
using the lxc-create scripts. This way, we can be sure that the
environment will be the bare minimum one.

On such environment, before the math extension, I had to install
those packages on Ubuntu Xenial, and on Debian Jessie, in order to
build the docs:

texlive-xetex python3-sphinx python3-sphinx-rtd-theme ttf-dejavu make 
gcc python3-sphinx-rtd-theme

As the environment is the bare minimum, you'll notice that it also
required "make".

I didn't track the minimal requirements for Fedora, but I had to
install those patchages on my Fedora 24 server yesterday, for it to build
for PDF:

texlive-amsmath.noarch texlive-mathtools.noarch
texlive-anyfontsize.noarch texlive-xelatex
texlive-xetex texlive-xecolor.noarch
texlive-titlesec.noarch texlive-framed texlive-threeparttable
texlive-wrapfig texlive-upquote texlive-capt-of eqparbox

With regards to documenting it, I would actually prefer to write a
shell or perl script (as it should require a bare minimum environment,
I would not write it in Python) that would be downloading what's needed,
based on the distribution type. I wrote one such script to allow building
the media drivers out of the tree:

https://git.linuxtv.org/media_build.git/tree/build

It checks for the type of distribution using this logic:

$system_release = qx(lsb_release -d) if which("lsb_release");
$system_release =~ s/Description:\s*// if ($system_release);
$system_release = catcheck("/etc/system-release") if !$system_release;
$system_release = catcheck("/etc/redhat-release") if !$system_release;
$system_release = catcheck("/etc/lsb-release") if !$system_release;
$system_release = catcheck("/etc/gentoo-release") if !$system_release;
$system_release = catcheck("/etc/issue") if !$system_release;
$system_release =~ s/\s+$//;

and checks if the prereqs are available. If not, it displays a hint
with the distro-specific command needed to install the dependencies:

sub need_program($)
{
my $prog = shift;

return if findprog($prog);

push @missing, $prog;

$need++;
}

need_program "make";
...

give_hints if ($need);

die "Build can't procceed as $need dependency is missing" if ($need == 
1);
die "Build can't procceed as $need dependencies are missing" if ($need);

The give_hints use the system_release to print the required needs:

sub give_hints()
{

# Distro-specific hints
if ($system_release =~ /Red Hat Enterprise Linux/) {
give_redhat_hints;
return;
}
...
}

sub give_redhat_hints()
{
my $install;

my %map = (
"wget"  => "wget",
"lsdiff"=> "patchutils",
"Digest::SHA"   => "perl-Digest-SHA",
"Proc::ProcessTable"=> "perl-Proc-ProcessTable",
);

foreach my $prog (@missing) {
print "ERROR: please install \"$prog\", otherwise, 
build won't work.\n";
if (defined($map{$prog})) {
$install .= " " . $map{$prog};
} else {
$install .= " " . $prog;
}
}

printf("You should run:\n\tyum install -y $install\n");
}



Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to 

Re: [RFC PATCH v2 04/20] x86: Secure Memory Encryption (SME) support

[Thomas Gleixner]

On Mon, 22 Aug 2016, Tom Lendacky wrote:

> Provide support for Secure Memory Encryption (SME). This initial support
> defines the memory encryption mask as a variable for quick access and an
> accessor for retrieving the number of physical addressing bits lost if
> SME is enabled.

What is the reason that this needs to live in assembly code?
 
Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

imgmath and PDF output

[Markus Heiser]

Hi Jon, Mauro, Jani,

today I tested imgmath, it worked well, but needs an
additional dvipng installation ...

What do you think, should we document the prerequisites
on different linux distributions to build documentation
with sphinx.ext.imgmath and PDF output?

What I mean, in the meantime we have two PDF applications,
the imgmath uses "latex" (plus dvipng) and the PDF output 
uses "xetex".

I tested on a ubuntu 16.04 sandbox, so my experience is,
on a debian based system it should be enough to install 
*base*, *xetex* and *recommended* -TeX packages, the 
imgmath extensions needs an additional dvipng package::

   sudo apt-get install \
 dvipng texlive-base texlive-xetex \
 texlive-latex-recommended

Jon and Mauro made there own experience with fedora, where
the installation procedure seems much more complex.

Might it be good, to document these experiences, to preserve
your experience?

-- Markus --


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

[Greg KH]

On Thu, Aug 25, 2016 at 10:03:52AM +0200, Rafał Miłecki wrote:
> +static void usbport_trig_activate(struct led_classdev *led_cdev)
> +{
> + struct usbport_trig_data *usbport_data;
> + int err;
> +
> + usbport_data = kzalloc(sizeof(*usbport_data), GFP_KERNEL);
> + if (!usbport_data)
> + return;
> + usbport_data->led_cdev = led_cdev;
> +
> + /* Storing ports */
> + INIT_LIST_HEAD(_data->ports);
> + usbport_data->ports_dir = kobject_create_and_add("ports",
> +  _cdev->dev->kobj);

If you _ever_ find yourself in a driver having to use kobject calls,
it's a HUGE hint that you are doing something wrong.

Hint, you are doing this wrong :)

Use an attribute group if you need a subdirectory in sysfs, using a
"raw" kobject like this hides it from all userspace tools and so no
userspace program can see it (hint, try using libudev to access these
files attached to the device...)

> + if (!usbport_data->ports_dir)
> + goto err_free;
> +
> + /* API for ports management */
> + err = device_create_file(led_cdev->dev, _attr_new_port);
> + if (err)
> + goto err_put_ports;
> + err = device_create_file(led_cdev->dev, _attr_remove_port);
> + if (err)
> + goto err_remove_new_port;

Doesn't this race with userspace and fail?  Shouldn't the led core be
creating your leds for you?

> +
> + /* Notifications */
> + usbport_data->nb.notifier_call = usbport_trig_notify,
> + led_cdev->trigger_data = usbport_data;
> + usb_register_notify(_data->nb);

Don't abuse the USB notifier chain with stuff like this please, is that
really necessary?  Why can't your hardware just tell you what USB ports
are in use "out of band"?


> +
> + led_cdev->activated = true;
> + return;
> +
> +err_remove_new_port:
> + device_remove_file(led_cdev->dev, _attr_new_port);
> +err_put_ports:
> + kobject_put(usbport_data->ports_dir);
> +err_free:
> + kfree(usbport_data);
> +}

And again, why is this USB specific?  Why can't you use this same
userspace api and codebase for PCI ports?  For a sdcard port?  For a
thunderbolt port?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

[Greg KH]

On Thu, Aug 25, 2016 at 07:14:52AM +0200, Rafał Miłecki wrote:
> On 24 August 2016 at 23:04, Greg KH  wrote:
> > On Wed, Aug 24, 2016 at 11:29:51AM +0200, Rafał Miłecki wrote:
> >> On 24 August 2016 at 11:22, Greg KH  wrote:
> >> > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote:
> >> >> +static ssize_t ports_show(struct device *dev, struct device_attribute 
> >> >> *attr,
> >> >> +   char *buf)
> >> >> +{
> >> >> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> >> >> + struct usbport_trig_data *usbport_data = led_cdev->trigger_data;
> >> >> + struct usbport_trig_port *port;
> >> >> + ssize_t ret = 0;
> >> >> + int len;
> >> >> +
> >> >> + list_for_each_entry(port, _data->ports, list) {
> >> >> + len = sprintf(buf + ret, "%s\n", port->name);
> >> >> + if (len >= 0)
> >> >> + ret += len;
> >> >> + }
> >> >> +
> >> >> + return ret;
> >> >> +}
> >> >
> >> > sysfs is "one value per file", here you are listing a bunch of things in
> >> > one sysfs file.  Please don't do that.
> >>
> >> OK. What do you think about creating "ports" subdirectory and creating
> >> file-per-port in it? Then I'd need to bring back something like
> >> "new_port" and "remove_port". Does it sound OK?
> >
> > Maybe, I don't know.  Why is "USB" somehow unique here?  Why isn't this
> > the same for PCI slots/ports?  pccard?  sdcard?  thunderbolt?
> 
> Good question. I would like to extend this USB port trigger in the
> future by reacting to USB activity. This involves playing with URBs
> and I believe that at that point it'd be getting too much USB specific
> to /rule them all/.

Oh that's never going to work, sorry.  USB "activity" happens deep in
USB host controller hardware, not up at the kernel level at all.  It's
just too fast, and would take up too much CPU to do it otherwise.  Heck,
even old UHCI 1.1 USB controllers did this.

USB "activity" happens all the time, look at a USB bus analyzer if you
want to see what goes on.  Teasing out what is "real data" and what is
just "normal bus activity" is impossible at the kernel level, and really
makes no sense at all (your led would just be "on" all the time.)

Are you sure you know how USB works?  Writing things like this makes me
really worry...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Jacek Anaszewski]

On 08/25/2016 10:29 AM, Rafał Miłecki wrote:

On 25 August 2016 at 10:03, Jacek Anaszewski  wrote:

On 08/24/2016 07:52 PM, Rafał Miłecki wrote:


From: Rafał Miłecki 

This commit adds a new trigger responsible for turning on LED when USB
device gets connected to the specified USB port. This can can useful for
various home routers that have USB port(s) and a proper LED telling user
a device is connected.

The trigger gets its documentation file but basically it just requires
specifying USB port in a Linux format (e.g. echo 1-1 > new_port).

During work on this trigger there was a plan to add DT bindings for it,
but there wasn't an agreement on the format yet. This can be worked on
later, a sysfs interface is needed anyway for platforms not using DT.

Signed-off-by: Rafał Miłecki 
---
V2: Trying to add DT support, idea postponed as it will take more time
to discuss the bindings.
V3: Fix typos in commit and Documentation (thanks Jacek!)
Use "ports" sysfs file for adding and removing USB ports (thx Jacek)
Check if there is USB device connected after adding new USB port
Fix memory leak or two
V3.5: Fix e-mail address (thanks Matthias)
  Simplify conditions in usbport_trig_notify (thx Matthias)
  Make "ports" a subdirectory with file per port, to match one value
  per file sysfs rule (thanks Greg)
  As "ports" couldn't be used for adding and removing ports anymore,
  there are now "new_port" and "remove_port". Having them makes this
  API also common with e.g. pci and usb buses.



Now writing new_port with "1-1" produces a file named "1-1" in the
ports directory with 000 permissions. I think that what Greg had
on mind by referring to "one value per file" rule was a set of
files representing ports, like "1-1 1-2 2-1", and each file should be
readable/writeable.

For instance "echo 1 > 1-1" would enable the trigger for the port 1-1
and "echo 0 > 1-1" would disable it. The problem is that we don't know
the number of required ports at compilation time and the sysfs
attributes would have to be dynamically created on driver instantiation.
What is more, as the USB ports can dynamically appear/disappear in the
system, the files would have to be created/removed accordingly during
LED class device lifetime, which is not the best design for the sysfs
interface I think.

Therefore, maybe it would be good to follow the "triggers" sysfs
attribute pattern, where it lists the available LED triggers?

The question is whether there is some mechanism available for
notifying addition/removal of a USB port?


Every port is part of some hub and every hub (even root one) is a USB
device. So I could just get struct usb_device and check its "maxchild"
property. If e.g. I get USB device "1-1" with maxchild 4, I know there
are:
1-1.1
1-1.2
1-1.3
1-1.4

So the sysfs structure you suggested would be possible, I just don't
know if it's preferred one or not.


It would require an ack from Greg.

I'd see it as follows:

#cat available_ports
#1-1 1-2 2-1

#echo "1-1" > new_port

#cat observed_ports
#1-1

#echo "2-1" > new_port

#cat observed_ports
#1-1 2-1

We've already had few discussions about the sysfs designs trying
to break the one-value-per-file rule for LED class device, and
there was always strong resistance against.

Cc Pavel.


Confirmation: yes, right now I create simple files with chmod 000 for
every port added to the usbport observable list.



Also a description of the device connected to the port would be a nice
feature, however I am not certain about the feasibility thereof.


What kind of description do you mean? Where should it be used / where
should it appear?



Product name/symbol. Actually it should be USB subsystem responsibility
to provide the means for querying the product name by port id, if it
is possible at all.

--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Matthias Brugger]

On 25/08/16 10:03, Jacek Anaszewski wrote:

zOn 08/24/2016 07:52 PM, Rafał Miłecki wrote:

From: Rafał Miłecki 

This commit adds a new trigger responsible for turning on LED when USB
device gets connected to the specified USB port. This can can useful for
various home routers that have USB port(s) and a proper LED telling user
a device is connected.

The trigger gets its documentation file but basically it just requires
specifying USB port in a Linux format (e.g. echo 1-1 > new_port).

During work on this trigger there was a plan to add DT bindings for it,
but there wasn't an agreement on the format yet. This can be worked on
later, a sysfs interface is needed anyway for platforms not using DT.

Signed-off-by: Rafał Miłecki 
---
V2: Trying to add DT support, idea postponed as it will take more time
to discuss the bindings.
V3: Fix typos in commit and Documentation (thanks Jacek!)
Use "ports" sysfs file for adding and removing USB ports (thx Jacek)
Check if there is USB device connected after adding new USB port
Fix memory leak or two
V3.5: Fix e-mail address (thanks Matthias)
  Simplify conditions in usbport_trig_notify (thx Matthias)
  Make "ports" a subdirectory with file per port, to match one value
  per file sysfs rule (thanks Greg)
  As "ports" couldn't be used for adding and removing ports anymore,
  there are now "new_port" and "remove_port". Having them makes this
  API also common with e.g. pci and usb buses.


Now writing new_port with "1-1" produces a file named "1-1" in the
ports directory with 000 permissions. I think that what Greg had
on mind by referring to "one value per file" rule was a set of
files representing ports, like "1-1 1-2 2-1", and each file should be
readable/writeable.

For instance "echo 1 > 1-1" would enable the trigger for the port 1-1
and "echo 0 > 1-1" would disable it. The problem is that we don't know
the number of required ports at compilation time and the sysfs
attributes would have to be dynamically created on driver instantiation.
What is more, as the USB ports can dynamically appear/disappear in the
system, the files would have to be created/removed accordingly during
LED class device lifetime, which is not the best design for the sysfs
interface I think.

Therefore, maybe it would be good to follow the "triggers" sysfs
attribute pattern, where it lists the available LED triggers?

The question is whether there is some mechanism available for
notifying addition/removal of a USB port?



I think this should be easily doable through the notifier catching 
USB_BUS_[ADD,REMOVE].


Regards,
Matthias


Also a description of the device connected to the port would be a nice
feature, however I am not certain about the feasibility thereof.


The last big missing thing is Documentation update (this is why I'm
sending RFC). Greg pointed out we should have some entries in
Documentation/ABI, but it seems none of triggers have it. Any idea why
is that? Do we need to change it? Or is it required for new code only?
If so, should I care about Documentation/leds/ledtrig-usbport.txt at
all in this patch?

For now I didn't update Documentation/leds/ledtrig-usbport.txt with the
new new_port and remove_port API, until I get a clue how to proceed.
---
 Documentation/leds/ledtrig-usbport.txt |  49 ++
 drivers/leds/trigger/Kconfig   |   8 +
 drivers/leds/trigger/Makefile  |   1 +
 drivers/leds/trigger/ledtrig-usbport.c | 309
+
 4 files changed, 367 insertions(+)
 create mode 100644 Documentation/leds/ledtrig-usbport.txt
 create mode 100644 drivers/leds/trigger/ledtrig-usbport.c

diff --git a/Documentation/leds/ledtrig-usbport.txt
b/Documentation/leds/ledtrig-usbport.txt
new file mode 100644
index 000..fa42227
--- /dev/null
+++ b/Documentation/leds/ledtrig-usbport.txt
@@ -0,0 +1,49 @@
+USB port LED trigger
+
+
+This LED trigger can be used for signalling to the user a presence of
USB device
+in a given port. It simply turns on LED when device appears and turns
it off
+when it disappears.
+
+It requires specifying a list of USB ports that should be observed.
Used format
+matches Linux kernel format and consists of a root hub number and a
hub port
+separated by a dash (e.g. 3-1).
+
+It is also possible to handle devices with internal hubs (that are
always
+connected to the root hub). User can simply specify internal hub
ports then
+(e.g. 1-1.1, 1-1.2, etc.).
+
+Please note that this trigger allows assigning multiple USB ports to
a single
+LED. This can be useful in two cases:
+
+1) Device with single USB LED and few physical ports
+
+In such a case LED will be turned on as long as there is at least one
connected
+USB device.
+
+2) Device with a physical port handled by few controllers
+
+Some devices have e.g. one controller per PHY standard. E.g. USB 3.0
physical
+port may be handled by ohci-platform, ehci-platform and xhci-hcd. If

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Jacek Anaszewski]

zOn 08/24/2016 07:52 PM, Rafał Miłecki wrote:

From: Rafał Miłecki 

This commit adds a new trigger responsible for turning on LED when USB
device gets connected to the specified USB port. This can can useful for
various home routers that have USB port(s) and a proper LED telling user
a device is connected.

The trigger gets its documentation file but basically it just requires
specifying USB port in a Linux format (e.g. echo 1-1 > new_port).

During work on this trigger there was a plan to add DT bindings for it,
but there wasn't an agreement on the format yet. This can be worked on
later, a sysfs interface is needed anyway for platforms not using DT.

Signed-off-by: Rafał Miłecki 
---
V2: Trying to add DT support, idea postponed as it will take more time
to discuss the bindings.
V3: Fix typos in commit and Documentation (thanks Jacek!)
Use "ports" sysfs file for adding and removing USB ports (thx Jacek)
Check if there is USB device connected after adding new USB port
Fix memory leak or two
V3.5: Fix e-mail address (thanks Matthias)
  Simplify conditions in usbport_trig_notify (thx Matthias)
  Make "ports" a subdirectory with file per port, to match one value
  per file sysfs rule (thanks Greg)
  As "ports" couldn't be used for adding and removing ports anymore,
  there are now "new_port" and "remove_port". Having them makes this
  API also common with e.g. pci and usb buses.


Now writing new_port with "1-1" produces a file named "1-1" in the
ports directory with 000 permissions. I think that what Greg had
on mind by referring to "one value per file" rule was a set of
files representing ports, like "1-1 1-2 2-1", and each file should be
readable/writeable.

For instance "echo 1 > 1-1" would enable the trigger for the port 1-1
and "echo 0 > 1-1" would disable it. The problem is that we don't know
the number of required ports at compilation time and the sysfs
attributes would have to be dynamically created on driver instantiation.
What is more, as the USB ports can dynamically appear/disappear in the
system, the files would have to be created/removed accordingly during
LED class device lifetime, which is not the best design for the sysfs
interface I think.

Therefore, maybe it would be good to follow the "triggers" sysfs
attribute pattern, where it lists the available LED triggers?

The question is whether there is some mechanism available for
notifying addition/removal of a USB port?

Also a description of the device connected to the port would be a nice
feature, however I am not certain about the feasibility thereof.


The last big missing thing is Documentation update (this is why I'm
sending RFC). Greg pointed out we should have some entries in
Documentation/ABI, but it seems none of triggers have it. Any idea why
is that? Do we need to change it? Or is it required for new code only?
If so, should I care about Documentation/leds/ledtrig-usbport.txt at
all in this patch?

For now I didn't update Documentation/leds/ledtrig-usbport.txt with the
new new_port and remove_port API, until I get a clue how to proceed.
---
 Documentation/leds/ledtrig-usbport.txt |  49 ++
 drivers/leds/trigger/Kconfig   |   8 +
 drivers/leds/trigger/Makefile  |   1 +
 drivers/leds/trigger/ledtrig-usbport.c | 309 +
 4 files changed, 367 insertions(+)
 create mode 100644 Documentation/leds/ledtrig-usbport.txt
 create mode 100644 drivers/leds/trigger/ledtrig-usbport.c

diff --git a/Documentation/leds/ledtrig-usbport.txt 
b/Documentation/leds/ledtrig-usbport.txt
new file mode 100644
index 000..fa42227
--- /dev/null
+++ b/Documentation/leds/ledtrig-usbport.txt
@@ -0,0 +1,49 @@
+USB port LED trigger
+
+
+This LED trigger can be used for signalling to the user a presence of USB 
device
+in a given port. It simply turns on LED when device appears and turns it off
+when it disappears.
+
+It requires specifying a list of USB ports that should be observed. Used format
+matches Linux kernel format and consists of a root hub number and a hub port
+separated by a dash (e.g. 3-1).
+
+It is also possible to handle devices with internal hubs (that are always
+connected to the root hub). User can simply specify internal hub ports then
+(e.g. 1-1.1, 1-1.2, etc.).
+
+Please note that this trigger allows assigning multiple USB ports to a single
+LED. This can be useful in two cases:
+
+1) Device with single USB LED and few physical ports
+
+In such a case LED will be turned on as long as there is at least one connected
+USB device.
+
+2) Device with a physical port handled by few controllers
+
+Some devices have e.g. one controller per PHY standard. E.g. USB 3.0 physical
+port may be handled by ohci-platform, ehci-platform and xhci-hcd. If there is
+only one LED user will most likely want to assign ports from all 3 hubs.
+
+
+This trigger can be activated from user space on led class devices as 

[PATCH V4] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

From: Rafał Miłecki 

This commit adds a new trigger responsible for turning on LED when USB
device gets connected to the specified USB port. This can can useful for
various home routers that have USB port(s) and a proper LED telling user
a device is connected.

The trigger gets its documentation file but basically it just requires
specifying USB port in a Linux format (e.g. echo 1-1 > new_port).

During work on this trigger there was a plan to add DT bindings for it,
but there wasn't an agreement on the format yet. This can be worked on
later, a sysfs interface is needed anyway for platforms not using DT.

Another planned feature is support for LED reacting to the USB activity.
This can be implemented with another sysfs file for setting mode. The
default mode wouldn't change so there won't be ABI breakage and such
feature can be safely implemented later.

Signed-off-by: Rafał Miłecki 
---
V2: Trying to add DT support, idea postponed as it will take more time
to discuss the bindings.
V3: Fix typos in commit and Documentation (thanks Jacek!)
Use "ports" sysfs file for adding and removing USB ports (thx Jacek)
Check if there is USB device connected after adding new USB port
Fix memory leak or two
V3.5: Fix e-mail address (thanks Matthias)
  Simplify conditions in usbport_trig_notify (thx Matthias)
  Make "ports" a subdirectory with file per port, to match one value
  per file sysfs rule (thanks Greg)
  As "ports" couldn't be used for adding and removing ports anymore,
  there are now "new_port" and "remove_port". Having them makes this
  API also common with e.g. pci and usb buses.
V4: Add Documentation/ABI/testing/sysfs-class-led-trigger-usbport and
reference it in Documentation/leds/ledtrig-usbport.txt to avoid doc
duplication.
---
 .../ABI/testing/sysfs-class-led-trigger-usbport|  25 ++
 Documentation/leds/ledtrig-usbport.txt |  46 +++
 drivers/leds/trigger/Kconfig   |   8 +
 drivers/leds/trigger/Makefile  |   1 +
 drivers/leds/trigger/ledtrig-usbport.c | 309 +
 5 files changed, 389 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-usbport
 create mode 100644 Documentation/leds/ledtrig-usbport.txt
 create mode 100644 drivers/leds/trigger/ledtrig-usbport.c

diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-usbport 
b/Documentation/ABI/testing/sysfs-class-led-trigger-usbport
new file mode 100644
index 000..653bde1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-usbport
@@ -0,0 +1,25 @@
+What:  /sys/class/leds//new_port
+Date:  August 2016
+KernelVersion: 4.9
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Adds USB port (specified by a name using Linux format, e.g. 1-1)
+   to the list of observable ones. This will have immediate effect
+   if there is device already connected. This will also make
+   trigger checking for a match on every USB (dis)connection event.
+
+What:  /sys/class/leds//remove_port
+Date:  August 2016
+KernelVersion: 4.9
+Contact:   linux-l...@vger.kernel.org
+Description:
+   This allows removing USB port from the list of observable ones.
+
+What:  /sys/class/leds//ports/
+Date:  August 2016
+KernelVersion: 4.9
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Every port entry is a name (in Linux format) of USB port that is
+   being observed by the usbport trigger. It's useful for checking
+   the current state of trigger setup.
diff --git a/Documentation/leds/ledtrig-usbport.txt 
b/Documentation/leds/ledtrig-usbport.txt
new file mode 100644
index 000..8e36e2d
--- /dev/null
+++ b/Documentation/leds/ledtrig-usbport.txt
@@ -0,0 +1,46 @@
+USB port LED trigger
+
+
+This LED trigger can be used for signalling to the user a presence of USB 
device
+in a given port. It simply turns on LED when device appears and turns it off
+when it disappears.
+
+It requires specifying a list of USB ports that should be observed. Used format
+matches Linux kernel format and consists of a root hub number and a hub port
+separated by a dash (e.g. 3-1).
+
+It is also possible to handle devices with internal hubs (that are always
+connected to the root hub). User can simply specify internal hub ports then
+(e.g. 1-1.1, 1-1.2, etc.).
+
+Please note that this trigger allows assigning multiple USB ports to a single
+LED. This can be useful in two cases:
+
+1) Device with single USB LED and few physical ports
+
+In such a case LED will be turned on as long as there is at least one connected
+USB device.
+
+2) Device with a physical port handled by few controllers
+
+Some devices have e.g. one controller per PHY standard. E.g. USB 3.0 physical
+port may be handled by ohci-platform, 

Re: [PATCHv11 3/3] rdmacg: Added documentation for rdmacg

[Parav Pandit]

Hi Rami Rosen,

On Thu, Aug 25, 2016 at 4:25 AM, Rami Rosen  wrote:
> Hi,
>
>> +Whenever RDMA resource charing occurs, owner rdma cgroup is returned to
> Should be: charging instead of charing
>
>> +(b) Query resource limit:
>> +cat /sys/fs/cgroup/rdma/2/rdma.max
>> +#Output:
>> +mlx4_0 uctx=max pd=max ah=2 mr=100 mw=max cq=max srq=max qp=10 flow=max
>> +ocrdma1 uctx=1 pd=5 ah=1 mr=10 cq=10 srq=max qp=20 flow=max flow=max
>
> Is this really so: double"flow=max" at the end of the ocrdma1 line?
> (flow=max flow=max)
>
>> +5-4. RDMA
>> +
>> +The "rdma" controller regulates the distribution and accounting of
>> +of RDMA resources.
> "of of" should be only a single "of"
>

>
>> + mlx4_1 uctx=1 ah=0 pd=1 cq=4 qp=4 mr=100 srq=0 flow=10
>> + ocrdma1 uctx=2 pd=2 ah=2 mr=20 mw=max cq=1 srq=1 qp=10 flow=10
>
> Seems to be inconsistency here: in the first line you have qp=4
> *before* srq=0, but in the second line you have qp=10 *after* srq=1.
>

I will fix above 4 typo errors.
Christoph has done quick review, I will wait for him to complete the
review before spinning v12 for these fixes.

> Keep on the good work!
Thank you for the motivation.

>
> Regards,
> Rami Rosen
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv11 0/3] rdmacg: IB/core: rdma controller support

[Christoph Hellwig]

On Wed, Aug 24, 2016 at 05:17:47PM -0400, Tejun Heo wrote:
> Looks good to me.  I just have a nit in the documentation.  Christoph,
> what do you think?

Looks reasonable from a quick look, but I didn't do a full review yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html