All of lore.kernel.org
 help / color / mirror / Atom feed
* [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

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

* 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

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

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

* [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: [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

* 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

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

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

* [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: [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

* 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

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

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

* 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

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


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.