* [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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.