On Thu, Jun 28, 2018 at 01:42:52AM +0200, Ard Biesheuvel wrote:
> But what point is there to letting LSMs decide that they do not trust
> an I/O device if there is nothing we can do about it? How can we
> prevent such an I/O device from modifying our memory?
Simply LSMs can opt to not trust such
On Thu, Jun 28, 2018 at 12:21:47AM +0200, Ard Biesheuvel wrote:
> On 27 June 2018 at 20:00, Luis R. Rodriguez wrote:
> > On Mon, Jun 25, 2018 at 05:08:08PM -0700, Bjorn Andersson wrote:
> >> On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote:
> >>
> >> > O
On Mon, Jun 25, 2018 at 05:08:08PM -0700, Bjorn Andersson wrote:
> On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote:
>
> > On 7 June 2018 at 20:21, Bjorn Andersson wrote:
> > > On Thu 07 Jun 09:33 PDT 2018, Greg Kroah-Hartman wrote:
> [..]
> > >>
> > >> Why not just use kmalloc, it will always
On Thu, Jun 07, 2018 at 11:06:11AM -0700, Bjorn Andersson wrote:
> On Thu 07 Jun 09:23 PDT 2018, Ard Biesheuvel wrote:
>
> > On 7 June 2018 at 18:18, Bjorn Andersson wrote:
> > > On Wed 06 Jun 13:32 PDT 2018, Luis R. Rodriguez wrote:
> > >
> > >> On Fri
On Thu, Jun 07, 2018 at 09:49:50AM -0700, Bjorn Andersson wrote:
> On Tue 08 May 09:10 PDT 2018, Luis R. Rodriguez wrote:
>
> > On Tue, May 08, 2018 at 03:38:05PM +0000, Luis R. Rodriguez wrote:
> > > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> &g
On Thu, Jun 07, 2018 at 12:41:12AM +0200, Ard Biesheuvel wrote:
> On 7 June 2018 at 00:29, Luis R. Rodriguez wrote:
> > Given no one is providing a clear answer, and we cannot easily describe the
> > buffer at run time we'll just move forward with
> > READING_FIRMWARE
On Wed, Jun 06, 2018 at 10:41:07PM +0200, Ard Biesheuvel wrote:
> On 6 June 2018 at 22:32, Luis R. Rodriguez wrote:
> > On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote:
> >> On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote:
> >> >
On Fri, Jun 01, 2018 at 09:23:46PM +0200, Luis R. Rodriguez wrote:
> On Tue, May 08, 2018 at 03:38:05PM +0000, Luis R. Rodriguez wrote:
> > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> > >
> > > I think the Qualcomm folks owning this (Andy, David
On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote:
> On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> > On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez
> > wrote:
> > > Is ptr below
> > >
> > > ret = r
On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote:
> On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> > On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez <mcg...@kernel.org>
> > wrote:
> > > A
On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote:
> > Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
> >
> > It would be good for us to hear from And
+, Luis R. Rodriguez wrote:
> On Wed, Apr 25, 2018 at 01:00:09AM -0400, Mimi Zohar wrote:
> > On Tue, 2018-04-24 at 23:42 +0000, Luis R. Rodriguez wrote:
> > > On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
> > > > On Tue, 2018-04-24 at 17:09 +0200, Han
On Wed, Apr 25, 2018 at 01:00:09AM -0400, Mimi Zohar wrote:
> On Tue, 2018-04-24 at 23:42 +0000, Luis R. Rodriguez wrote:
> > On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
> > > On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
> > > > On 23-04-18
On Mon, Dec 04, 2017 at 03:19:39AM +0530, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
>
> Unit Testing:
>
> - build successful
> - LTP testsuite passes.
> - checkpatch.pl
This will ensure I get emails on my work and personal email address.
Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org>
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3deaddc8c578..997b8062397a 100644
--- a/MAINT
this driver anymore.
Before trying to due away with prism54 once more stuff it into staging,
which is our hospice for dying drivers.
Acked-by: Kalle Valo <kv...@codeaurora.org>
Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org>
---
MAINTAINERS
Greg,
This v2 adds the TODO you requested to clarify prism54 will be removed in
two kernel releases from now, and so no further cleanup is needed other
than to ensure the driver compiles.
This is based on linux-next tag next-20170807.
Luis
Luis R. Rodriguez (2):
wireless: move prism54 out
On Thu, Aug 03, 2017 at 05:42:15PM -0700, Greg KH wrote:
> On Thu, Aug 03, 2017 at 04:59:36PM -0700, Luis R. Rodriguez wrote:
> > prism54 is deprecated in favor of the p54pci device driver. Although
> > only *one soul* had reported issues with it long ago Linux most Linux
&g
this driver anymore.
Before trying to due away with prism54 once more stuff it into staging,
which is our hospice for dying drivers.
Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org>
---
MAINTAINERS | 4 ++--
drivers/net/wireless/intersil/K
Kalle, Greg,
This moves the prism54 diver to staging. The reason for this are
stated on the driver's own commit log. Let me know what tree you'd
prefer this to go through.
Luis R. Rodriguez (2):
wireless: move prism54 out to staging
MAINTAINERS: update email address for mcgrof for few
This will ensure I get emails on my work and personal email address.
Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org>
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 97cf436e6750..49ae596584e7 100644
--- a/MAINT
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
On Sun, May 10, 2015 at 03:09:03PM +0200, Greg KH wrote:
On Mon, May 04, 2015 at 05:15:51PM -0700, Luis R. Rodriguez wrote:
---
drivers/staging/sm750fb/sm750.c| 36
drivers/staging/sm750fb/sm750.h| 3 ---
drivers/staging/sm750fb/sm750_hw.c
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
On Sun, May 03, 2015 at 09:24:59PM +0200, Greg KH wrote:
On Tue, Apr 21, 2015 at 01:12:03PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code
On Tue, Apr 21, 2015 at 1:13 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
On Mon, Jun 23, 2014 at 06:41:28AM -0700, Joe Perches wrote:
Adding the helper reduces object code size as well as overall
source size line count.
It's also consistent with all the various zalloc mechanisms
in the kernel.
Done with a simple cocci script and some typing.
Awesome, any
30 matches
Mail list logo
