All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v3 5/6] grep: enable recurse-submodules to work on <tree> objects
From: Brandon Williams @ 2016-11-14 19:14 UTC (permalink / raw)
  To: Jonathan Tan; +Cc: Junio C Hamano, git, sbeller
In-Reply-To: <5a60b630-15fc-6b63-fb03-25aa0d1ef081@google.com>

On 11/14, Jonathan Tan wrote:
> On 11/14/2016 10:56 AM, Junio C Hamano wrote:
> >Jonathan Tan <jonathantanmy@google.com> writes:
> >
> >>>>to:
> >>>>HEAD:file
> >>>>HEAD:sub/file
> >>>>
> >>>>Signed-off-by: Brandon Williams <bmwill@google.com>
> >>>>---
> >>>
> >>>Unrelated tangent, but this makes readers wonder what the updated
> >>>trailer code would do to the last paragraph ;-).  Does it behave
> >>>sensibly (with some sane definition of sensibleness)?
> >>>
> >>>I am guessing that it would, because neither To: or HEAD: is what we
> >>>normally recognize as a known trailer block element.
> >>
> >>Yes, it behaves sensibly :-) because "Signed-off-by:" is preceded by a
> >>blank line, so the trailer block consists only of that line.
> >
> >Oh, that was not what I was wondering.  Imagine Brandon writing his
> >message that ends in these three questionable lines and then running
> >"commit -s --amend" to add his sign-off---that was the case I was
> >wondering.
> 
> Ah, I see. In that case, it would consider the last block as a
> trailer block and attach it directly:
> 
>   to:
>   HEAD:file
>   HEAD:sub/file
>   Signed-off-by: ...
> 
> It is true that neither to: nor HEAD: are known trailers, but my
> patch set accepts trailer blocks that are 100% well-formed
> regardless of whether the trailers are known (to provide backwards
> compatibility with git-interpret-trailers, and to satisfy the
> certain use cases that I brought up). The "known trailer" check is
> used when the trailer block is not 100% well-formed.
> 
> This issue can be avoided if those lines were indented with at least
> one space or at least one tab.

Who would have thought my simple example would cause this kind of
discussion!  I can update the commit message and indent the output so
that it looks like the following:

to:
  HEAD:file
  HEAD:sub/file

-- 
Brandon Williams

^ permalink raw reply
* Re: [PATCH 3/3] thermal/intel_powerclamp: Convert to CPU hotplug state
From: Jacob Pan @ 2016-11-14 19:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Sebastian Andrzej Siewior, Zhang Rui, Thomas Gleixner,
	Eduardo Valentin, Tejun Heo, Peter Zijlstra, linux-pm,
	linux-kernel, jacob.jun.pan, Eduardo Valentin
In-Reply-To: <20161111173410.GA15785@pathway.suse.cz>

On Fri, 11 Nov 2016 18:34:10 +0100
Petr Mladek <pmladek@suse.com> wrote:

> Please, let me known if I should do this as a separate patch
> and/or resend the patchset.

Rui/Eduardo,
There are four independent posted changes made to powerclamp driver:
Should I roll them into one set such that you can easily apply them?
1. add back module device table https://lkml.org/lkml/2016/11/14/760
2. kworker, this patchset
3. cpu hotplug state, this patch.
4. PF_IDLE https://lkml.org/lkml/2016/11/14/747

Thanks,

Jacob

^ permalink raw reply
* Re: [PATCH 3/3] thermal/intel_powerclamp: Convert to CPU hotplug state
From: Jacob Pan @ 2016-11-14 19:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Sebastian Andrzej Siewior, Zhang Rui, Thomas Gleixner,
	Eduardo Valentin, Tejun Heo, Peter Zijlstra, linux-pm,
	linux-kernel, jacob.jun.pan
In-Reply-To: <20161111173410.GA15785@pathway.suse.cz>

On Fri, 11 Nov 2016 18:34:10 +0100
Petr Mladek <pmladek@suse.com> wrote:

> Please, let me known if I should do this as a separate patch
> and/or resend the patchset.

Rui/Eduardo,
There are four independent posted changes made to powerclamp driver:
Should I roll them into one set such that you can easily apply them?
1. add back module device table https://lkml.org/lkml/2016/11/14/760
2. kworker, this patchset
3. cpu hotplug state, this patch.
4. PF_IDLE https://lkml.org/lkml/2016/11/14/747

Thanks,

Jacob

^ permalink raw reply
* [U-Boot] [PATCH v2 4/4] ARM: DRA7xx: Disable non-FIT based image loading for HS devices
From: Andrew F. Davis @ 2016-11-14 19:14 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20161114191419.14214-1-afd@ti.com>

Disable support for loading non-FIT images for DRA7xx platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 configs/dra7xx_hs_evm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 838de5c..75befb5 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -12,6 +12,7 @@ CONFIG_FIT=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_ABORT_ON_NON_FIT_IMAGE=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
-- 
2.10.1

^ permalink raw reply related
* [U-Boot] [PATCH v2 3/4] ARM: AM437x: Disable non-FIT based image loading for HS devices
From: Andrew F. Davis @ 2016-11-14 19:14 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20161114191419.14214-1-afd@ti.com>

Disable support for loading non-FIT images for AM437x platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 configs/am43xx_hs_evm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 1c53877..9c00e8b 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -10,6 +10,7 @@ CONFIG_FIT=y
 CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1, NAND"
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_ABORT_ON_NON_FIT_IMAGE=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
-- 
2.10.1

^ permalink raw reply related
* [U-Boot] [PATCH v2 2/4] ARM: AM57xx: Disable non-FIT based image loading for HS devices
From: Andrew F. Davis @ 2016-11-14 19:14 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20161114191419.14214-1-afd@ti.com>

Disable support for loading non-FIT images for AM57xx platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 configs/am57xx_hs_evm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index 6631bb2..5812dfe 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -11,6 +11,7 @@ CONFIG_FIT=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_ABORT_ON_NON_FIT_IMAGE=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
-- 
2.10.1

^ permalink raw reply related
* [U-Boot] [PATCH v2 1/4] Introduce CONFIG_SPL_ABORT_ON_NON_FIT_IMAGE
From: Andrew F. Davis @ 2016-11-14 19:14 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20161114191419.14214-1-afd@ti.com>

Introduce CONFIG_SPL_ABORT_ON_NON_FIT_IMAGE. An SPL which define
this will abort image loading if the image is not a FIT image.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 Kconfig          | 9 +++++++++
 common/spl/spl.c | 5 +++++
 2 files changed, 14 insertions(+)

diff --git a/Kconfig b/Kconfig
index 1263d0b..eefebef 100644
--- a/Kconfig
+++ b/Kconfig
@@ -291,6 +291,15 @@ config FIT_IMAGE_POST_PROCESS
 	  injected into the FIT creation (i.e. the blobs would have been pre-
 	  processed before being added to the FIT image).
 
+config SPL_ABORT_ON_NON_FIT_IMAGE
+	bool "Disable SPL loading of non-FIT images"
+	default y if SPL_FIT_SIGNATURE
+	help
+	  SPL will not load and image if it is not a FIT image. This is
+	  useful for devices that only support authentication/encryption
+	  through SPL FIT loading paths and do not want SPL falling back
+	  to legacy image loading when a non-FIT image is present.
+
 config SPL_DFU_SUPPORT
 	bool "Enable SPL with DFU to load binaries to memory device"
 	depends on USB
diff --git a/common/spl/spl.c b/common/spl/spl.c
index bdb165a..3d8bee9 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -93,6 +93,10 @@ void spl_set_header_raw_uboot(struct spl_image_info *spl_image)
 int spl_parse_image_header(struct spl_image_info *spl_image,
 			   const struct image_header *header)
 {
+#ifdef CONFIG_SPL_ABORT_ON_NON_FIT_IMAGE
+	/* non-FIT image found, proceed to other boot methods. */
+	return -EINVAL;
+#else
 	u32 header_size = sizeof(struct image_header);
 
 	if (image_get_magic(header) == IH_MAGIC) {
@@ -156,6 +160,7 @@ int spl_parse_image_header(struct spl_image_info *spl_image,
 		spl_set_header_raw_uboot(spl_image);
 #endif
 	}
+#endif
 	return 0;
 }
 
-- 
2.10.1

^ permalink raw reply related
* [U-Boot] [PATCH v2 0/4] Allow disabling non-FIT image loading from SPL
From: Andrew F. Davis @ 2016-11-14 19:14 UTC (permalink / raw)
  To: u-boot

Hello all,

To address a needed feature brought up by Andreas[0], we need a way to
disable SPL from loading non-FIT images.

The function spl_parse_image_header is common to all SPL loading paths
(common/spl/spl_(nand|net|nor|etc..)) so we add the check here, much
like the existing CONFIG_SPL_ABORT_ON_RAW_IMAGE.

My original attempt was to add CONFIG_SPL_PANIC_ON_MKIMAGE, but then if other
formats are added, flaws in restricting image types may be introduced, so we
would like a single option to restrict all non-FIT types vs disabling types
individually.

Thanks,
Andrew

[0] https://www.mail-archive.com/u-boot at lists.denx.de/msg219253.html

Changes from v1:
 - Changed to abort on non-FIT so other boot methods can be attempted.
 - Made this a default if SPL_FIT_SIGNATURE is selected.

Andrew F. Davis (4):
  Introduce CONFIG_SPL_ABORT_ON_NON_FIT_IMAGE
  ARM: AM57xx: Disable non-FIT based image loading for HS devices
  ARM: AM437x: Disable non-FIT based image loading for HS devices
  ARM: DRA7xx: Disable non-FIT based image loading for HS devices

 Kconfig                         | 9 +++++++++
 common/spl/spl.c                | 5 +++++
 configs/am43xx_hs_evm_defconfig | 1 +
 configs/am57xx_hs_evm_defconfig | 1 +
 configs/dra7xx_hs_evm_defconfig | 1 +
 5 files changed, 17 insertions(+)

-- 
2.10.1

^ permalink raw reply
* Re: [PATCH 2/2] Add basic support for DW CSI-2 Host IPK
From: kbuild test robot @ 2016-11-14 19:12 UTC (permalink / raw)
  To: Ramiro Oliveira
  Cc: kbuild-all, robh+dt, mark.rutland, mchehab, devicetree,
	linux-kernel, linux-media, davem, gregkh, geert+renesas, akpm,
	linux, hverkuil, laurent.pinchart+renesas, arnd, sudipm.mukherjee,
	tiffany.lin, minghsiu.tsai, jean-christophe.trotin,
	andrew-ct.chen, simon.horman, songjun.wu, bparrot,
	CARLOS.PALMINHA, Ramiro.Oliveira
In-Reply-To: <c1699c43562aaae69ab851ff3955086131119c51.1479132355.git.roliveir@synopsys.com>

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

Hi Ramiro,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.9-rc5 next-20161114]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Ramiro-Oliveira/Add-support-for-the-DW-IP-Prototyping-Kits-for-MIPI-CSI-2-Host/20161115-014759
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/media/platform/dwc/dw_mipi_csi.c: In function 'mipi_csi_probe':
>> drivers/media/platform/dwc/dw_mipi_csi.c:597:8: error: implicit declaration of function 'devm_request_irq' [-Werror=implicit-function-declaration]
     ret = devm_request_irq(dev, mipi_csi->ctrl_irq_number,
           ^~~~~~~~~~~~~~~~
>> drivers/media/platform/dwc/dw_mipi_csi.c:598:29: error: 'IRQF_SHARED' undeclared (first use in this function)
              dw_mipi_csi_irq1, IRQF_SHARED,
                                ^~~~~~~~~~~
   drivers/media/platform/dwc/dw_mipi_csi.c:598:29: note: each undeclared identifier is reported only once for each function it appears in
   cc1: some warnings being treated as errors

vim +/devm_request_irq +597 drivers/media/platform/dwc/dw_mipi_csi.c

   591		mipi_csi->ctrl_irq_number = platform_get_irq(pdev, 0);
   592		if (mipi_csi->ctrl_irq_number <= 0) {
   593			dev_err(dev, "IRQ number not set.\n");
   594			return mipi_csi->ctrl_irq_number;
   595		}
   596	
 > 597		ret = devm_request_irq(dev, mipi_csi->ctrl_irq_number,
 > 598				       dw_mipi_csi_irq1, IRQF_SHARED,
   599				       dev_name(dev), mipi_csi);
   600		if (ret) {
   601			dev_err(dev, "IRQ failed\n");

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56871 bytes --]

^ permalink raw reply
* Re: [Libtirpc-devel] [PATCH rpcbind] Move default state-dir to /run/rpcbind
From: Mike Frysinger @ 2016-11-14 19:12 UTC (permalink / raw)
  To: NeilBrown; +Cc: Steve Dickson, Linux NFS Mailing List, libtirpc-devel
In-Reply-To: <87polzj7sx.fsf@notabene.neil.brown.name>

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

On 14 Nov 2016 10:09, NeilBrown wrote:
> On Sat, Nov 12 2016, Mike Frysinger wrote:
> > On 11 Nov 2016 14:36, NeilBrown wrote:
> >> rpcbind can save state in a file to allow restart without forgetting
> >> about running services.
> >> 
> >> The default location is currently "/tmp" which is an over-used
> >> directory that isn't really suitable for system files.
> >> The modern preferences would be a subdirectory of "/run", which can
> >> be selected with a ./configure option.  That subdirectory would still need
> >> to be created by something.
> >
> > the portable path is /var/cache instead of /run.  i don't think libtirpc
> > should be configuring itself to assume Linux by default.
> 
> In principle I agree.  But is /var/cache really a good choice?
> We don't want the state files to persist over a reboot, and I strongly
> suspect that /var/cache is designed to do exactly that.
> 
> Are there agree standards that are broader than Linux that we can look
> to?
> FHS defines /var/run (or even /run) but I suspect it is linux-only.

/var/run should work across systems i believe.  at least BSD's support it.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply
* [refpolicy] su_exec
From: Fakim, Walid @ 2016-11-14 19:12 UTC (permalink / raw)
  To: refpolicy
In-Reply-To: <6ebc2667-b50e-e227-c6fd-16c7454c3c8c@gmail.com>

Ok that worked :D - thanks Dom!

For the benefit of everybody else on the mailing list, I also found this great article by Sven -> http://blog.siphos.be/2015/09/getting-su-to-work-in-init-scripts/

Thanks.

Best Regards,

Walid Fakim


-----Original Message-----
From: Fakim, Walid 
Sent: 14 November 2016 18:23
To: 'Dominick Grift'; refpolicy at oss.tresys.com
Subject: RE: su_exec

Thanks Dom - I'll experiment with that.

I can see that pam_rootok.so is already present in /lib64/security

Am using CentOS 6.8 so might be susceptible to that bug you mention.

I'll try adding the permission - Am assuming you mean ->          allow mydomain_t self:passwd rootok;         <- ?

Thanks.

Best Regards,

Walid Fakim

-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com] 
Sent: 14 November 2016 18:16
To: Fakim, Walid; refpolicy@oss.tresys.com
Subject: Re: su_exec

On 11/14/2016 05:11 PM, Fakim, Walid wrote:
> Hi Guys,
> 
> So for this process am trying to confine, the startup script is using su -c rather than runuser and even though I've got su_exec(mydomain_t) in my te file, it's prompting for a password at startup.
> 
> Any thoughts or experience of seeing this before?
> 
> Thanks.
> 
> Best Regards,
> 
> Walid Fakim
> 
> 

Add pam_rootok.so to /etc/pam.d/su maybe?

Also you may need to allow ":passwd rootok;" permission

If it hit that then the event should show up as a "USER_AVC" in audit.log (ausearch -m USER_AVC -ts today)

In the past there was a problem with PAMs' SELinux awareness and it was not logging USER_AVC denials. That should now be fixed.


--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

^ permalink raw reply
* Re: [PATCH 2/2] Add basic support for DW CSI-2 Host IPK
From: kbuild test robot @ 2016-11-14 19:12 UTC (permalink / raw)
  Cc: kbuild-all, robh+dt, mark.rutland, mchehab, devicetree,
	linux-kernel, linux-media, davem, gregkh, geert+renesas, akpm,
	linux, hverkuil, laurent.pinchart+renesas, arnd, sudipm.mukherjee,
	tiffany.lin, minghsiu.tsai, jean-christophe.trotin,
	andrew-ct.chen, simon.horman, songjun.wu, bparrot,
	CARLOS.PALMINHA, Ramiro.Oliveira
In-Reply-To: <c1699c43562aaae69ab851ff3955086131119c51.1479132355.git.roliveir@synopsys.com>

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

Hi Ramiro,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.9-rc5 next-20161114]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Ramiro-Oliveira/Add-support-for-the-DW-IP-Prototyping-Kits-for-MIPI-CSI-2-Host/20161115-014759
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/media/platform/dwc/dw_mipi_csi.c: In function 'mipi_csi_probe':
>> drivers/media/platform/dwc/dw_mipi_csi.c:597:8: error: implicit declaration of function 'devm_request_irq' [-Werror=implicit-function-declaration]
     ret = devm_request_irq(dev, mipi_csi->ctrl_irq_number,
           ^~~~~~~~~~~~~~~~
>> drivers/media/platform/dwc/dw_mipi_csi.c:598:29: error: 'IRQF_SHARED' undeclared (first use in this function)
              dw_mipi_csi_irq1, IRQF_SHARED,
                                ^~~~~~~~~~~
   drivers/media/platform/dwc/dw_mipi_csi.c:598:29: note: each undeclared identifier is reported only once for each function it appears in
   cc1: some warnings being treated as errors

vim +/devm_request_irq +597 drivers/media/platform/dwc/dw_mipi_csi.c

   591		mipi_csi->ctrl_irq_number = platform_get_irq(pdev, 0);
   592		if (mipi_csi->ctrl_irq_number <= 0) {
   593			dev_err(dev, "IRQ number not set.\n");
   594			return mipi_csi->ctrl_irq_number;
   595		}
   596	
 > 597		ret = devm_request_irq(dev, mipi_csi->ctrl_irq_number,
 > 598				       dw_mipi_csi_irq1, IRQF_SHARED,
   599				       dev_name(dev), mipi_csi);
   600		if (ret) {
   601			dev_err(dev, "IRQ failed\n");

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56871 bytes --]

^ permalink raw reply
* [PATCH] Handle SForced in storage_modifiers
From: Jeff Layton @ 2016-11-14 19:12 UTC (permalink / raw)
  To: linux-sparse; +Cc: Al Viro

We have been seeing errors like this for a while now in the sparse
Fedora package, when doing kernel builds:

    ./include/linux/err.h:53:25: warning: dereference of noderef expression
    ./include/linux/err.h:35:16: warning: dereference of noderef expression

This spews all over the build because this comes from IS_ERR(), which
is called everywhere. Even odder, it turns out that if we build the
package with -fpic turned off, then it works fine.

With some brute-force debugging, I think I've finally found the cause.
This array is missing the SForced element. When this is added then the
problem goes away.

As to why this goes away when -fpic is removed, I can only assume that
we get lucky with the memory layout and have a zeroed out region just
beyond the end of the array.

Fixes: 3829c4d8b097776e6b3472290a9fae08a705ab7a
Cc: Al Viro <viro@ftp.linux.org.uk>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
---
 parse.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/parse.c b/parse.c
index 205e12644a6c..b290ff2636f2 100644
--- a/parse.c
+++ b/parse.c
@@ -1286,7 +1286,8 @@ static unsigned long storage_modifiers(struct decl_state *ctx)
 		[SAuto] = MOD_AUTO,
 		[SExtern] = MOD_EXTERN,
 		[SStatic] = MOD_STATIC,
-		[SRegister] = MOD_REGISTER
+		[SRegister] = MOD_REGISTER,
+		[SForced] = 0
 	};
 	return mod[ctx->storage_class] | (ctx->is_inline ? MOD_INLINE : 0)
 		| (ctx->is_tls ? MOD_TLS : 0);
-- 
2.7.4


^ permalink raw reply related
* Re: [PATCH] thermal/powerclamp: add back module device table
From: Jacob Pan @ 2016-11-14 19:09 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: LKML, Zhang Rui, eric.ernst, Linux PM, Rafael Wysocki,
	jacob.jun.pan
In-Reply-To: <20161109150835.GA6382@kroah.com>

On Wed, 9 Nov 2016 16:08:35 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> >  drivers/thermal/intel_powerclamp.c | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)  
> 
> No signed-off-by :(
> 
> No Fixes: line, and no stable: line :(

my bad, just resent with fixes.

^ permalink raw reply
* [PATCH] crypto: gf128mul - Zero memory when freeing multiplication table
From: Alex Cope @ 2016-11-14 19:02 UTC (permalink / raw)
  To: linux-crypto; +Cc: Alex Cope, Eric Biggers

GF(2^128) multiplication tables are typically used for secret
information, so it's a good idea to zero them on free.

Signed-off-by: Alex Cope <alexcope@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 crypto/gf128mul.c         | 4 ++--
 include/crypto/gf128mul.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
index 5276607..0594dd6 100644
--- a/crypto/gf128mul.c
+++ b/crypto/gf128mul.c
@@ -352,8 +352,8 @@ void gf128mul_free_64k(struct gf128mul_64k *t)
 	int i;
 
 	for (i = 0; i < 16; i++)
-		kfree(t->t[i]);
-	kfree(t);
+		kzfree(t->t[i]);
+	kzfree(t);
 }
 EXPORT_SYMBOL(gf128mul_free_64k);
 
diff --git a/include/crypto/gf128mul.h b/include/crypto/gf128mul.h
index da2530e..7217fe6 100644
--- a/include/crypto/gf128mul.h
+++ b/include/crypto/gf128mul.h
@@ -177,7 +177,7 @@ void gf128mul_4k_bbe(be128 *a, struct gf128mul_4k *t);
 
 static inline void gf128mul_free_4k(struct gf128mul_4k *t)
 {
-	kfree(t);
+	kzfree(t);
 }
 
 
-- 
2.8.0.rc3.226.g39d4020

^ permalink raw reply related
* Refactoring skeleton flash control
From: Abhishek Pandit @ 2016-11-14 19:09 UTC (permalink / raw)
  To: anoo, openbmc, Nancy Yuen

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

Hey Adriana,

I'm planning on refactoring the skeleton flash update code and pulling it
out into it's own repo (openbmc/phosphor-flash-control).

I've started with how I think the dbus interface should behave:
https://gerrit.openbmc-project.xyz/#/c/1166/.

The overall plan for the flash interface in my head:

   - REST (or some other) interface receives image + signature to update
   flash
      - Gets saved to filesystem and flash control is called
   - Flash control loads the files into memory and verifies the signature
      - Reference implementation would probably just be pgp
   - Flash control locks the flash device
      - This needs some more thought and probably new dbus interfaces;
      important for host flash
   - Image written to flash
   - Lock on flash device released
   - Signal asserted (Done)

---

For the most part, I don't think I'll rewrite too much of the existing
skeleton code except to have it use the c++ bindings (continue using
libflash and existing MTD devices for bmc update).

Locking the host flash would require some additional thought since
currently it's accessible directly and a mailbox approach would also
require some way to lock the flash when doing read/write.

--

Please take a look at the gerrit. I'll start adding some more information
around locking + signing this week.

Abhishek

[-- Attachment #2: Type: text/html, Size: 1751 bytes --]

^ permalink raw reply
* Re: [meta-oe][krogoth][PATCH] syslog-ng: expand service file @variables@ earlier
From: Denys Dmytriyenko @ 2016-11-14 19:09 UTC (permalink / raw)
  To: openembedded-devel; +Cc: Ian Ray
In-Reply-To: <271f87f6-ac90-2389-3499-9c3bb8d80fa6@gmail.com>

On Thu, Nov 03, 2016 at 08:20:53AM -0700, akuster808 wrote:
> 
> 
> On 10/27/2016 10:02 AM, Denys Dmytriyenko wrote:
> > From: Ian Ray <ian.ray@ge.com>
> > 
> > Move variable expansion of @SBINDIR@, @LOCALSTATEDIR@, and @BASEBINDIR@
> > earlier during install, to before the systemd service file is installed
> > by an automake rule.
> > 
> > Signed-off-by: Ian Ray <ian.ray@ge.com>
> > Signed-off-by: Denys Dmytriyenko <denys@ti.com>
> 
> merged to staging.

Armin,

Any updates on this? Also, I don't see it in krogoth-next - what staging you 
are referring to?

-- 
Denys


> >  meta-oe/recipes-support/syslog-ng/syslog-ng.inc | 9 ++++++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> > 
> > diff --git a/meta-oe/recipes-support/syslog-ng/syslog-ng.inc b/meta-oe/recipes-support/syslog-ng/syslog-ng.inc
> > index 4e0f697..898e9c2 100644
> > --- a/meta-oe/recipes-support/syslog-ng/syslog-ng.inc
> > +++ b/meta-oe/recipes-support/syslog-ng/syslog-ng.inc
> > @@ -60,6 +60,12 @@ do_configure_prepend() {
> >      eval "${@bb.utils.contains('DISTRO_FEATURES', 'largefile', '', 'sed -i -e "s/-D_LARGEFILE_SOURCE//" -e "s/-D_FILE_OFFSET_BITS=64//" ${S}/configure.in', d)}"
> >  }
> >  
> > +do_install_prepend() {
> > +    sed -i -e 's,@SBINDIR@,${sbindir},g' ${S}/contrib/systemd/*.service
> > +    sed -i -e 's,@LOCALSTATEDIR@,${localstatedir},g' ${S}/contrib/systemd/*.service
> > +    sed -i -e 's,@BASEBINDIR@,${base_bindir},g' ${S}/contrib/systemd/*.service
> > +}
> > +
> >  do_install_append() {
> >      install -d ${D}/${sysconfdir}/${BPN}
> >      install ${WORKDIR}/syslog-ng.conf ${D}${sysconfdir}/${BPN}/${BPN}.conf
> > @@ -70,9 +76,6 @@ do_install_append() {
> >      install -d ${D}/${localstatedir}/lib/${BPN}
> >      # Remove /var/run as it is created on startup
> >      rm -rf ${D}${localstatedir}/run
> > -    sed -i -e 's,@SBINDIR@,${sbindir},g' ${S}/contrib/systemd/*.service
> > -    sed -i -e 's,@LOCALSTATEDIR@,${localstatedir},g' ${S}/contrib/systemd/*.service
> > -    sed -i -e 's,@BASEBINDIR@,${base_bindir},g' ${S}/contrib/systemd/*.service
> >  }
> >  
> >  FILES_${PN} += "${datadir}/include/scl/ ${datadir}/xsd ${datadir}/tools"
> > 
> -- 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel


^ permalink raw reply
* [PATCH] thermal/powerclamp: add back module device table
From: Jacob Pan @ 2016-11-14 19:08 UTC (permalink / raw)
  To: LKML, Linux PM
  Cc: stable, Zhang Rui, Greg Kroah-Hartman, Rafael Wysocki, Jacob Pan

Commit 3105f234e0aba43e44e277c20f9b32ee8add43d4 replaced module
cpu id table with a cpu feature check, which is logically correct.
But we need the module device table to allow module auto loading.

Fixes:3105f234 thermal/powerclamp: correct cpu support check
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
---
 drivers/thermal/intel_powerclamp.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/intel_powerclamp.c b/drivers/thermal/intel_powerclamp.c
index bd4914e..745fcec 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -704,9 +704,16 @@ static int powerclamp_set_cur_state(struct thermal_cooling_device *cdev,
 	.set_cur_state = powerclamp_set_cur_state,
 };
 
+static const struct x86_cpu_id __initconst intel_powerclamp_ids[] = {
+	{ X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_MWAIT },
+	{}
+};
+MODULE_DEVICE_TABLE(x86cpu, intel_powerclamp_ids);
+
 static int __init powerclamp_probe(void)
 {
-	if (!boot_cpu_has(X86_FEATURE_MWAIT)) {
+
+	if (!x86_match_cpu(intel_powerclamp_ids)) {
 		pr_err("CPU does not support MWAIT");
 		return -ENODEV;
 	}
-- 
1.9.1

^ permalink raw reply related
* Re: specifying order of /dev/mmcblk devices via device-tree?
From: Russell King - ARM Linux @ 2016-11-14 19:08 UTC (permalink / raw)
  To: Tim Harvey, Ulf Hansson
  Cc: Mark Rutland, Javier Martinez Canillas, Fabio Estevam,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAJ+vNU26tx-1bLKNpzYJ0UCeFJ-SczZOca1dYdt5mCGDxAuKTQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

So, someone merged a patch which makes mmcblk devices follow the
host controller numbering.

Now my cubox-i fails to boot correctly because the SD card in the
_only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".

USDHC1 is wired to the on-microsom WiFi, and never has anything
remotely near a SD card or eMMC present.  So, this change is
confusing on these platforms.

Moreover, this is _going_ to break SolidRun distros if people upgrade
their kernels.

It may be appropriate for eMMC, but it's not appropriate everywhere.

This is a user visible _regression_ in 4.9-rc.  Whoever did this,
please revert whatever change caused this, and next time limit it
to only eMMC.

Thanks.

On Fri, Oct 28, 2016 at 09:45:00AM -0700, Tim Harvey wrote:
> On Fri, Oct 28, 2016 at 8:37 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> > On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
> >> Greetings,
> >>
> >> I have an IMX6 board that has the following:
> >> sdhc1: mmc0: sdio radio
> >> sdhc2: mmc1: /dev/mmcblk1: microSD connector
> >> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
> >>
> >> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
> >> registered as /dev/mmcblk1 so that permanent storage is the first
> >> mmcblk device as I think this is more intuitive however currently
> >> these get instanced in the order they appear in the imx6qdl.dtsi
> >> device-tree configuration and are not able to be mapped the way I want
> >> them in my dts file.
> >>
> >> Is there a way, or if not is there a desire for a way, to specify the
> >> order of /dev/mmcblk devices via device-tree?
> >
> > As with many other devices, there is no standard way of controlling the
> > Linux enumeration (and given the ID space is shared with other dynamic
> > devices it's not something that could generally work).
> >
> > These should be refererd to by UUID if possible.
> >
> > If not, we could cosider adding a by-dt-path or something like that.
> >
> > Thanks,
> > Mark.
> 
> Mark / Javier/ Fabio,
> 
> Thanks - this is very useful.
> 
> Yes, I agree that using UUID's is the way to go and now I see how that
> can be easily accessed via uboot 'part' command.
> 
> Regards,
> 
> Tim
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Russell King - ARM Linux @ 2016-11-14 19:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAJ+vNU26tx-1bLKNpzYJ0UCeFJ-SczZOca1dYdt5mCGDxAuKTQ@mail.gmail.com>

So, someone merged a patch which makes mmcblk devices follow the
host controller numbering.

Now my cubox-i fails to boot correctly because the SD card in the
_only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".

USDHC1 is wired to the on-microsom WiFi, and never has anything
remotely near a SD card or eMMC present.  So, this change is
confusing on these platforms.

Moreover, this is _going_ to break SolidRun distros if people upgrade
their kernels.

It may be appropriate for eMMC, but it's not appropriate everywhere.

This is a user visible _regression_ in 4.9-rc.  Whoever did this,
please revert whatever change caused this, and next time limit it
to only eMMC.

Thanks.

On Fri, Oct 28, 2016 at 09:45:00AM -0700, Tim Harvey wrote:
> On Fri, Oct 28, 2016 at 8:37 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
> >> Greetings,
> >>
> >> I have an IMX6 board that has the following:
> >> sdhc1: mmc0: sdio radio
> >> sdhc2: mmc1: /dev/mmcblk1: microSD connector
> >> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
> >>
> >> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
> >> registered as /dev/mmcblk1 so that permanent storage is the first
> >> mmcblk device as I think this is more intuitive however currently
> >> these get instanced in the order they appear in the imx6qdl.dtsi
> >> device-tree configuration and are not able to be mapped the way I want
> >> them in my dts file.
> >>
> >> Is there a way, or if not is there a desire for a way, to specify the
> >> order of /dev/mmcblk devices via device-tree?
> >
> > As with many other devices, there is no standard way of controlling the
> > Linux enumeration (and given the ID space is shared with other dynamic
> > devices it's not something that could generally work).
> >
> > These should be refererd to by UUID if possible.
> >
> > If not, we could cosider adding a by-dt-path or something like that.
> >
> > Thanks,
> > Mark.
> 
> Mark / Javier/ Fabio,
> 
> Thanks - this is very useful.
> 
> Yes, I agree that using UUID's is the way to go and now I see how that
> can be easily accessed via uboot 'part' command.
> 
> Regards,
> 
> Tim
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply
* Re: [PATCH v3 5/6] grep: enable recurse-submodules to work on <tree> objects
From: Jonathan Tan @ 2016-11-14 19:08 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, sbeller, Brandon Williams
In-Reply-To: <xmqqfumtyjoy.fsf@gitster.mtv.corp.google.com>

On 11/14/2016 10:56 AM, Junio C Hamano wrote:
> Jonathan Tan <jonathantanmy@google.com> writes:
>
>>>> to:
>>>> HEAD:file
>>>> HEAD:sub/file
>>>>
>>>> Signed-off-by: Brandon Williams <bmwill@google.com>
>>>> ---
>>>
>>> Unrelated tangent, but this makes readers wonder what the updated
>>> trailer code would do to the last paragraph ;-).  Does it behave
>>> sensibly (with some sane definition of sensibleness)?
>>>
>>> I am guessing that it would, because neither To: or HEAD: is what we
>>> normally recognize as a known trailer block element.
>>
>> Yes, it behaves sensibly :-) because "Signed-off-by:" is preceded by a
>> blank line, so the trailer block consists only of that line.
>
> Oh, that was not what I was wondering.  Imagine Brandon writing his
> message that ends in these three questionable lines and then running
> "commit -s --amend" to add his sign-off---that was the case I was
> wondering.

Ah, I see. In that case, it would consider the last block as a trailer 
block and attach it directly:

   to:
   HEAD:file
   HEAD:sub/file
   Signed-off-by: ...

It is true that neither to: nor HEAD: are known trailers, but my patch 
set accepts trailer blocks that are 100% well-formed regardless of 
whether the trailers are known (to provide backwards compatibility with 
git-interpret-trailers, and to satisfy the certain use cases that I 
brought up). The "known trailer" check is used when the trailer block is 
not 100% well-formed.

This issue can be avoided if those lines were indented with at least one 
space or at least one tab.

^ permalink raw reply
* Re: [PATCH] fetch/push: document that private data can be leaked
From: Matt McCutchen @ 2016-11-14 19:08 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <xmqqbmxhyjij.fsf@gitster.mtv.corp.google.com>

On Mon, 2016-11-14 at 11:00 -0800, Junio C Hamano wrote:
> Matt McCutchen <matt@mattmccutchen.net> writes:
> 
> > 
> > > 
> > > Yup, and then "do not push to untrustworthy place without
> > > checking
> > > what you are pushing", too?
> > 
> > If there is no private data in the repository, then there is no
> > need
> > for the user to check what they are pushing. As I've indicated
> > before,
> > IMO manually checking each push would not be a workable security
> > measure in the long term anyway.
> 
> Then what is?

Don't put private data in the same repository, then the whole issue
becomes moot.  Am I missing something?

Matt

^ permalink raw reply
* Re: [PATCH] fetch/push: document that private data can be leaked
From: Jeff King @ 2016-11-14 19:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Matt McCutchen, git
In-Reply-To: <xmqqbmxhyjij.fsf@gitster.mtv.corp.google.com>

On Mon, Nov 14, 2016 at 11:00:04AM -0800, Junio C Hamano wrote:

> Matt McCutchen <matt@mattmccutchen.net> writes:
> 
> >> Yup, and then "do not push to untrustworthy place without checking
> >> what you are pushing", too?
> >
> > If there is no private data in the repository, then there is no need
> > for the user to check what they are pushing. As I've indicated before,
> > IMO manually checking each push would not be a workable security
> > measure in the long term anyway.
> 
> Then what is?  Don't answer; this is a rhetorical question.
> 
> The answer is "do not push to untrustworthy place", if you are
> unable to check what you are pushing.

I think "check what you are pushing" only covers one case (attacker lies
to you during a fetch, and you accidentally push that back, thinking
they already have it).

But consider the other case mentioned: the attacker lies to you while
pushing and _says_ they have X, then deduces information from the delta
you generate. The only advice there is "do not push to an untrusted
place from a repository containing private objects".

So I think the in-between answer is "it is OK to push to an
untrustworthy place, but do not do it from a repo that may contain
secret contents".

-Peff

^ permalink raw reply
* [Bug 93649] [radeonsi] Graphics lockup while playing tf2
From: bugzilla-daemon @ 2016-11-14 19:06 UTC (permalink / raw)
  To: dri-devel
In-Reply-To: <bug-93649-502@http.bugs.freedesktop.org/>


[-- Attachment #1.1: Type: text/plain, Size: 425 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=93649

--- Comment #60 from Rosco P. Coltrane <roscofdporg@manashort.com> ---
Some people are reporting that they can reproduce the bug on windows 7. 

https://github.com/ValveSoftware/Source-1-Games/issues/1943#issuecomment-260154700

Are we absolutely sure that it is not a hardware problem?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1325 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply
* [PATCH 2/2] Btrfs: abort transaction if fill_holes() fails
From: Josef Bacik @ 2016-11-14 19:06 UTC (permalink / raw)
  To: linux-btrfs, kernel-team
In-Reply-To: <1479150382-19273-1-git-send-email-jbacik@fb.com>

At this point we will have dropped extent entries from the file, so if we fail
to insert the new hole entries then we are leaving the fs in a corrupt state
(albeit an easily fixed one).  Abort the transaciton if this happens so we can
avoid corrupting the fs.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
---
 fs/btrfs/file.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 1c15a98..d6fc719 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -2234,9 +2234,14 @@ static int fill_holes(struct btrfs_trans_handle *trans, struct inode *inode,
 	key.offset = offset;
 
 	ret = btrfs_search_slot(trans, root, &key, path, 0, 1);
-	if (ret < 0)
+	if (ret <= 0) {
+		/* We should have dropped this offset, so if we find it then
+		 * something has gone horribly wrong.
+		 */
+		if (ret == 0)
+			ret = -EINVAL;
 		return ret;
-	BUG_ON(!ret);
+	}
 
 	leaf = path->nodes[0];
 	if (hole_mergeable(inode, leaf, path->slots[0]-1, offset, end)) {
@@ -2539,6 +2544,12 @@ static int btrfs_punch_hole(struct inode *inode, loff_t offset, loff_t len)
 			ret = fill_holes(trans, inode, path, cur_offset,
 					 drop_end);
 			if (ret) {
+				/* If we failed then we didn't insert our hole
+				 * entries for the area we dropped, so now the
+				 * fs is corrupted, so we must abort the
+				 * transaction.
+				 */
+				btrfs_abort_transaction(trans, ret);
 				err = ret;
 				break;
 			}
@@ -2603,6 +2614,8 @@ static int btrfs_punch_hole(struct inode *inode, loff_t offset, loff_t len)
 	if (cur_offset < ino_size && cur_offset < drop_end) {
 		ret = fill_holes(trans, inode, path, cur_offset, drop_end);
 		if (ret) {
+			/* Same comment as above. */
+			btrfs_abort_transaction(trans, ret);
 			err = ret;
 			goto out_trans;
 		}
-- 
2.7.4


^ permalink raw reply related
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.