Re: [PATCH v2] stm class: Document the stm_ftrace

2017-04-26 Thread Chunyan Zhang 
Hi Alex,

Could you take this patch please if there's no further comments?

Thanks,
Chunyan

On 23 March 2017 at 14:13, Chunyan Zhang  wrote:
> This patch adds a description to the stm_ftrace device source, an
> interface for collecting Ftrace's function trace information via
> STM devices.
>
> Signed-off-by: Chunyan Zhang 
> ---
>  Documentation/trace/stm.txt | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.txt
> index 11cff47..0376575 100644
> --- a/Documentation/trace/stm.txt
> +++ b/Documentation/trace/stm.txt
> @@ -83,7 +83,7 @@ by writing the name of the desired stm device there, for 
> example:
>  $ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link
>
>  For examples on how to use stm_source interface in the kernel, refer
> -to stm_console or stm_heartbeat drivers.
> +to stm_console, stm_heartbeat or stm_ftrace drivers.
>
>  Each stm_source device will need to assume a master and a range of
>  channels, depending on how many channels it requires. These are
> @@ -107,5 +107,16 @@ console in the STP stream, create a "console" policy 
> entry (see the
>  beginning of this text on how to do that). When initialized, it will
>  consume one channel.
>
> +stm_ftrace
> +==
> +
> +This is another "stm_source" device, once the stm_ftrace has been
> +linked with an stm device, and if "function" tracer is enabled,
> +function address and parent function address which Ftrace subsystem
> +would store into ring buffer will be exported via the stm device at
> +the same time.
> +
> +Currently only Ftrace "function" tracer is supported.
> +
>  [1] 
> https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf
>  [2] 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html
> --
> 2.7.4
>
--
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

[PATCH v2] FS-Cache: fix buffer size for decimal value of special cookie type

2017-04-26 Thread Jérémy Lefaure 
When building object-list.o, gcc (version 7) raises a warning on the
sprintf call in fscache_objlist_show:

  CC  fs/fscache/object-list.o
fs/fscache/object-list.c: In function ‘fscache_objlist_show’:
fs/fscache/object-list.c:265:19: warning: ‘sprintf’ may write a
terminating nul past the end of the destination [-Wformat-overflow=]
sprintf(_type, "%02u", cookie->def->type);
   ^~
fs/fscache/object-list.c:265:4: note: ‘sprintf’ output between 3 and 4
bytes into a destination of size 3
sprintf(_type, "%02u", cookie->def->type);
^

Moreover, the documentation says that value for special cookies is a
hexadecimal value (see Documentation/filesystems/caching/fscache.txt).

Increasing the buffer size to use a decimal value fixes the problem
without any effect on userland tools. Also, this patch updates the
documentation.

Signed-off-by: Jérémy Lefaure 
---
v2:
_ keep decimal value
_ fix _type buffer size
_ fix documentation

I didn't have the time to test this patch yet but everything should be fine.


 Documentation/filesystems/caching/fscache.txt |  2 +-
 fs/fscache/object-list.c  | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/filesystems/caching/fscache.txt 
b/Documentation/filesystems/caching/fscache.txt
index 50f0a5757f48..9c3df61b3c16 100644
--- a/Documentation/filesystems/caching/fscache.txt
+++ b/Documentation/filesystems/caching/fscache.txt
@@ -374,7 +374,7 @@ and the second set of columns describe the object's cookie, 
if present:
COLUMN  DESCRIPTION
=== ===
NETFS_COOKIE_DEF Name of netfs cookie definition
-   TY  Cookie type (IX - index, DT - data, hex - special)
+   TY  Cookie type (IX - index, DT - data, decimal - special)
FL  Cookie flags
NETFS_DATA  Netfs private data stored in the cookie
OBJECT_KEY  Object key  } 1 column, with separating comma
diff --git a/fs/fscache/object-list.c b/fs/fscache/object-list.c
index 67f940892ef8..3452d7dbf1e1 100644
--- a/fs/fscache/object-list.c
+++ b/fs/fscache/object-list.c
@@ -169,7 +169,7 @@ static int fscache_objlist_show(struct seq_file *m, void *v)
struct fscache_object *obj = v;
struct fscache_cookie *cookie;
unsigned long config = data->config;
-   char _type[3], *type;
+   char _type[4], *type;
u8 *buf = data->buf, *p;
 
if ((unsigned long) v == 1) {
@@ -194,7 +194,7 @@ static int fscache_objlist_show(struct seq_file *m, void *v)
if ((unsigned long) v == 2) {
seq_puts(m, "   = === === === == ="
 " == == == ="
-" |  == == ");
+" |  === == ");
if (config & (FSCACHE_OBJLIST_CONFIG_KEY |
  FSCACHE_OBJLIST_CONFIG_AUX))
seq_puts(m, " ");
@@ -256,13 +256,13 @@ static int fscache_objlist_show(struct seq_file *m, void 
*v)
 
switch (cookie->def->type) {
case 0:
-   type = "IX";
+   type = " IX";
break;
case 1:
-   type = "DT";
+   type = " DT";
break;
default:
-   sprintf(_type, "%02u", cookie->def->type);
+   sprintf(_type, "%03u", cookie->def->type);
type = _type;
break;
}
-- 
2.12.2

--
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: [RFC PATCH 00/14] cgroup: Implement cgroup v2 thread mode & CPU controller

2017-04-26 Thread Tejun Heo 
Hello, Waiman.

On Wed, Apr 26, 2017 at 12:05:27PM -0400, Waiman Long wrote:
> Does anyone has time to take a look at these patches?
> 
> As the merge window is going to open up next week, I am not going to
> bother you guys when the merge window opens.

Will get to it next week.  Sorry about the delay.  We're deploying
cgroup2 across the fleet and seeing a lot of interesting issues and I
was chasing down CPU controller performance issues for the last month
or so, which is now getting wrapped up.

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] em28xx: allow setting the eeprom bus at cards struct

2017-04-26 Thread Frank Schäfer 

Am 25.04.2017 um 12:06 schrieb Mauro Carvalho Chehab:
> Right now, all devices use bus 0 for eeprom. However,
> it seems that newer versions of Terratec H6 uses a different
> buffer for eeprom.
>
> So, add support to use a different I2C address for eeprom and
> add a new card ID for the board described at:
>   http://forum.kodi.tv/showthread.php?tid=312902
I'm not 100% sure, but IIRC the bridge expects the eeprom to be always
on bus 0.

Anyway, looking at the information provided by the thread creator, it
seems that the eeprom is detected as usual on bus 0.
Otherwise "board has no eeprom" would have been printed to the log.
What happens here is that em28xx_i2c_read_block() fails with -ETIMEDOUT,
which means that the i2c status reported by the em2884 is (still) 0x02
or 0x04 when the timeout is reached.
See em28xx_i2c_send_bytes() and em28xx_i2c_recv_bytes().
Further tests/debugging is required to find out what exactly is going on.
Turning on debug module paramters i2c_debug and reg_debug would help.

> PS.: This patch was meant to allow testing the device. It may
> be wrong or incomplete, as it doesn't attempt to set GPIOs.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/em28xx/em28xx-cards.c | 20 
>  drivers/media/usb/em28xx/em28xx-i2c.c   |  5 +
>  drivers/media/usb/em28xx/em28xx.h   |  5 -
>  3 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index a12b599a1fa2..b788ae0d5646 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -1193,6 +1193,23 @@ struct em28xx_board em28xx_boards[] = {
>   .i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
>   EM28XX_I2C_FREQ_400_KHZ,
>   },
> + [EM2884_BOARD_TERRATEC_H6] = {
> + .name = "Terratec Cinergy H6",
> + .has_dvb  = 1,
> + .ir_codes = RC_MAP_NEC_TERRATEC_CINERGY_XS,
> +#if 0
> + .tuner_type   = TUNER_PHILIPS_TDA8290,
According to the thread, the tuner is a TDA18271 !?

Regards,
Frank

> + .tuner_addr   = 0x41,
> + .dvb_gpio = terratec_h5_digital, /* FIXME: probably wrong */
> + .tuner_gpio   = terratec_h5_gpio,
> +#else
> + .tuner_type   = TUNER_ABSENT,
> +#endif
> + .def_i2c_bus  = 1,
> + .eeprom_i2c_bus  = 1,
> + .i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
> + EM28XX_I2C_FREQ_400_KHZ,
> + },
>   [EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C] = {
>   .name = "Hauppauge WinTV HVR 930C",
>   .has_dvb  = 1,
> @@ -2496,6 +2513,8 @@ struct usb_device_id em28xx_id_table[] = {
>   .driver_info = EM2884_BOARD_TERRATEC_H5 },
>   { USB_DEVICE(0x0ccd, 0x10b6),   /* H5 Rev. 3 */
>   .driver_info = EM2884_BOARD_TERRATEC_H5 },
> + { USB_DEVICE(0x0ccd, 0x10b2),   /* H6 */
> + .driver_info = EM2884_BOARD_TERRATEC_H6 },
>   { USB_DEVICE(0x0ccd, 0x0084),
>   .driver_info = EM2860_BOARD_TERRATEC_AV350 },
>   { USB_DEVICE(0x0ccd, 0x0096),
> @@ -2669,6 +2688,7 @@ static inline void em28xx_set_model(struct em28xx *dev)
>  
>   /* Should be initialized early, for I2C to work */
>   dev->def_i2c_bus = dev->board.def_i2c_bus;
> + dev->eeprom_i2c_bus = dev->board.eeprom_i2c_bus;
>  }
>  
>  /* Wait until AC97_RESET reports the expected value reliably before 
> proceeding.
> diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c 
> b/drivers/media/usb/em28xx/em28xx-i2c.c
> index 8c472d5adb50..df0ab4b6f18f 100644
> --- a/drivers/media/usb/em28xx/em28xx-i2c.c
> +++ b/drivers/media/usb/em28xx/em28xx-i2c.c
> @@ -665,8 +665,6 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned 
> bus,
>   *eedata = NULL;
>   *eedata_len = 0;
>  
> - /* EEPROM is always on i2c bus 0 on all known devices. */
> -
>   dev->i2c_client[bus].addr = 0xa0 >> 1;
>  
>   /* Check if board has eeprom */
> @@ -975,8 +973,7 @@ int em28xx_i2c_register(struct em28xx *dev, unsigned bus,
>   dev->i2c_client[bus] = em28xx_client_template;
>   dev->i2c_client[bus].adapter = >i2c_adap[bus];
>  
> - /* Up to now, all eeproms are at bus 0 */
> - if (!bus) {
> + if (bus == dev->eeprom_i2c_bus) {
>   retval = em28xx_i2c_eeprom(dev, bus, >eedata, 
> >eedata_len);
>   if ((retval < 0) && (retval != -ENODEV)) {
>   dev_err(>intf->dev,
> diff --git a/drivers/media/usb/em28xx/em28xx.h 
> b/drivers/media/usb/em28xx/em28xx.h
> index e8d97d5ec161..a333ca954129 100644
> --- a/drivers/media/usb/em28xx/em28xx.h
> +++ b/drivers/media/usb/em28xx/em28xx.h
> @@ -148,6 +148,7 @@
>  #define EM28178_BOARD_PLEX_PX_BCUD98
>  #define

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

2017-04-26 Thread One Thousand Gnomes 
> open() what? As far as I know, for System-V PTYs, there is no path you can
> open() that will give you the PTY master. Am I missing something?

Sorry brain fade - no.
> 
> >> > If I want to do the equvalent of the TIOCSTI attack then I fork a process
> >> > and exit the parent. The child can now use ptrace to reprogram your shell
> >> > to do whatever interesting things it likes (eg running child processes
> >> > called "su" via a second pty/tty pair). Not exactly rocket science.  
> >>
> >> Why would the child be able to ptrace the shell? AFAICS, in the most
> >> relevant scenarios, the child can't ptrace the shell because the
> >> shell has a different UID (in the case of e.g. su or sudo). In other  
> >
> > If I am the attacker wanting to type something into your su when you go
> > and su from my account, or where the user account is trojanned I do the
> > following
> >
> > fork
> > exit parent
> > child ptraces the shell (same uid as it's not setuid)
> >
> > You type "su" return
> > The modified shell opens a new pty/tty pair and runs su over it
> > My ptrace hooks watch the pty/tty traffic until you go to the loo
> > My ptrace hooks switch the console
> > My ptrace hooks type lots of stuff and hack your machine while eating the
> > output
> >
> > and you come back, do stuff and then exit
> >
> > And if you are in X it's even easier and I don't even need to care about
> > sessions or anything. X has no mechanism to sanely fix the problem, but
> > Wayland does.  
> 
> I think the "When using a program like su or sudo" in the patch description
> refers to the usecase where you go from a more privileged context (e.g. a
> root shell) to a less privileged one (e.g. a shell as a service-specific
> account used to run a daemon), not the other way around.

Which is the sudo case and why sudo uses a separate pty/tty pair as it's
not just TIOCSTI that's an issue but there are a load of ioctls that do
things like cause signals to the process or are just annoying -
vhangup(), changing the speed etc

(And for console changing the keymap - which is a nasty one)

> [However, I do think that it's a nice side effect of this patch that it will
> prevent a malicious program from directly injecting something like an
> SSH command into my shell in a sufficiently hardened environment
> (with LSM restrictions that prevent the malicious program from opening
> SSH keyfiles or executing another program that can do that). Although
> you could argue that in such a case, the LSM should be taking care of
> blocking TIOCSTI.]

I would submit that creating a new pty/tty pair is the proper answer for
that case however. Making the tty calls respect namespaces is however
still a no-brainer IMHO.

Alan
--
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

[PATCH v3 3/3] Documentation/kernel-parameters.txt: Update 'memmap=' option description

2017-04-26 Thread Baoquan He 
In commit:

  9710f581bb4c ("x86, mm: Let "memmap=" take more entries one time")

... 'memmap=' was changed to adopt multiple, comma delimited values in a
single entry, so update the related description.

In the special case of only specifying size value without an offset,
like memmap=nn[KMG], memmap behaves similarly to mem=nn[KMG], so update
it too here.

Furthermore, for memmap=nn[KMG]$ss[KMG], an escape character needs be added
before '$' for some bootloaders. E.g in grub2, if we specify memmap=100M$5G
as suggested by the documentation, "memmap=100MG" gets passed to the kernel.

Clarify all this.

Signed-off-by: Baoquan He 
Cc: Jonathan Corbet 
Cc: "Rafael J. Wysocki" 
Cc: Andrew Morton 
Cc: Greg Kroah-Hartman 
Cc: Bjorn Helgaas 
Cc: Mauro Carvalho Chehab 
Cc: linux-doc@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 986e443..d518144 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2097,6 +2097,12 @@
memmap=nn[KMG]@ss[KMG]
[KNL] Force usage of a specific region of memory.
Region of memory to be used is from ss to ss+nn.
+   If @ss[KMG] is omitted, it equals to mem=nn[KMG]
+   which limits max address as nn[KMG].
+   Multiple different options can be put into one entry
+   with comma delimited to save space:
+   Example:
+   memmap=100M@2G,100M#3G,1G!1024G
 
memmap=nn[KMG]#ss[KMG]
[KNL,ACPI] Mark specific memory as ACPI data.
@@ -2109,6 +2115,9 @@
 memmap=64K$0x1869
 or
 memmap=0x1$0x1869
+   Some bootloaders may need escape character before '$',
+   like in grub2, otherwise '$' and the following number
+   will be eaten.
 
memmap=nn[KMG]!ss[KMG]
[KNL,X86] Mark specific memory as protected.
-- 
2.5.5

--
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