On Mon, 2022-11-21 at 16:05 +0100, Greg Kroah-Hartman wrote:
> On Mon, Nov 21, 2022 at 09:03:18AM -0500, James Bottomley wrote:
> > On Mon, 2022-11-21 at 12:05 +0100, Greg Kroah-Hartman wrote:
> > > On Sun, Nov 20, 2022 at 10:14:26PM -0500, James Bottomley wrote:
[...]
> >
On Mon, 2022-11-21 at 12:05 +0100, Greg Kroah-Hartman wrote:
> On Sun, Nov 20, 2022 at 10:14:26PM -0500, James Bottomley wrote:
> > On Sun, 2022-11-20 at 17:13 +0100, Greg Kroah-Hartman wrote:
> > > On Sat, Nov 19, 2022 at 01:20:09AM -0500, Nayna wrote:
> > > >
&
are objects are not namespaced. I mentioned it here as an
> > > > example of the difference between firmware and kernel objects.
> > > > It is also in response to the feedback from James Bottomley in
> > > > RFC v2 [
> > > > https://lore.kernel.org/lin
On Thu, 2022-06-23 at 10:54 +0200, Greg Kroah-Hartman wrote:
[...]
> > diff --git a/fs/fwsecurityfs/inode.c b/fs/fwsecurityfs/inode.c
> > new file mode 100644
> > index ..5d06dc0de059
> > --- /dev/null
> > +++ b/fs/fwsecurityfs/inode.c
> > @@ -0,0 +1,159 @@
> > +//
On Mon, 2022-02-28 at 23:59 +0200, Mike Rapoport wrote:
>
> On February 28, 2022 10:42:53 PM GMT+02:00, James Bottomley <
> james.bottom...@hansenpartnership.com> wrote:
> > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
[...]
> > > > I do wish we coul
On Mon, 2022-02-28 at 21:56 +0100, Christian König wrote:
>
> Am 28.02.22 um 21:42 schrieb James Bottomley:
> > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
> > > Am 28.02.22 um 20:56 schrieb Linus Torvalds:
> > > > On Mon, Feb 28, 2022 at 4:19
On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
> Am 28.02.22 um 20:56 schrieb Linus Torvalds:
> > On Mon, Feb 28, 2022 at 4:19 AM Christian König
> > wrote:
> > > I don't think that using the extra variable makes the code in any
> > > way
> > > more reliable or easier to read.
> > So I
On Tue, 2022-02-01 at 15:41 +0100, Greg KH wrote:
> On Tue, Feb 01, 2022 at 09:24:50AM -0500, James Bottomley wrote:
> > [cc's added]
> > On Tue, 2022-02-01 at 14:50 +0100, Greg KH wrote:
[...]
> > > You all need to work together to come up with a unified place for
&g
[cc's added]
On Tue, 2022-02-01 at 14:50 +0100, Greg KH wrote:
> On Tue, Feb 01, 2022 at 12:44:08PM +, Dov Murik wrote:
[...]
> > # ls -la /sys/kernel/security/coco/efi_secret
> > total 0
> > drwxr-xr-x 2 root root 0 Jun 28 11:55 .
> > drwxr-xr-x 3 root root 0 Jun 28 11:54 ..
> > -r--r- 1
On Fri, 2020-10-09 at 14:34 -0700, Eric Biggers wrote:
> On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The kmap() calls in this FS are localized to a single thread. To
> > avoid the over head of global PKRS updates use the new
> > kmap_thread()
On Mon, 2020-08-17 at 12:28 -0700, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 07:41:58AM -0700, James Bottomley wrote:
> > On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> > > From: Allen Pais
> > >
> > > Commit 12cc923f1ccc ("tasklet: Introduce n
On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> From: Allen Pais
>
> Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> introduced a new tasklet initialization API. This series converts
> all the scsi drivers to use the new tasklet_setup() API
I've got to say I agree
On Tue, 2020-06-16 at 14:13 +, Johannes Thumshirn wrote:
> On 16/06/2020 16:09, Bart Van Assche wrote:
> > On 2020-06-16 02:42, Finn Thain wrote:
> > > Martin said, "I'd appreciate a patch to remove it"
> > >
> > > And Bart said, "do you want to keep this driver in the kernel
> > > tree?"
> >
On Wed, 2020-03-04 at 07:35 -0500, Mimi Zohar wrote:
> On Tue, 2020-03-03 at 23:43 -0800, James Bottomley wrote:
> > On Tue, 2020-03-03 at 21:33 -0500, Nayna Jain wrote:
> > > diff --git a/security/integrity/ima/Kconfig
> > > b/security/integrity/ima/Kconfig
> > &
On Tue, 2020-03-03 at 21:33 -0500, Nayna Jain wrote:
> Every time a new architecture defines the IMA architecture specific
> functions - arch_ima_get_secureboot() and arch_ima_get_policy(), the
> IMA
> include file needs to be updated. To avoid this "noise", this patch
> defines a new IMA Kconfig
On Thu, 2019-08-08 at 19:00 +0300, Christoph Hellwig wrote:
> parisc is the only architecture that sets ARCH_NO_COHERENT_DMA_MMAP
> when an MMU is enabled. AFAIK this is because parisc CPUs use VIVT
> caches,
We're actually VIPT but the same principle applies.
> which means exporting normally
On Fri, 2019-01-18 at 11:57 -0500, Dennis Clarke wrote:
> On 1/18/19 11:18 AM, Arnd Bergmann wrote:
> > This is a minor update of the patches I posted last week, I
> > would like to add this into linux-next now, but would still do
> > changes if there are concerns about the contents. The first
> >
On Sun, 2018-12-30 at 18:50 +0100, LEROY Christophe wrote:
> Arnd Bergmann a écrit :
> > On Sat, Dec 29, 2018 at 3:51 AM Michael Schmitz
> > wrote:
[...]
> > > (On second thought - I don't want to speculate whether there's
> > > weird compiler options that could result in the
> > >
On Wed, 2017-10-18 at 18:10 +0300, Jarkko Sakkinen wrote:
> On Tue, Oct 17, 2017 at 08:57:13AM -0700, James Bottomley wrote:
> >
> > On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote:
> > >
> > > >
> > > >
> > >
On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote:
> >
> > Fixes is only for bug fixes. These don't fix any bugs.
>
> How do you distinguish these in questionable source code
> from other error categories or software weaknesses?
A style change is one that doesn't change the effect of
On Tue, 2017-03-14 at 12:29 +, Reshetova, Elena wrote:
> > Elena Reshetova writes:
> >
> > > refcount_t type and corresponding API should be
> > > used instead of atomic_t when the variable is used as
> > > a reference counter. This allows to avoid accidental
> > >
On Wed, 2016-02-10 at 19:32 -0600, Tyrel Datwyler wrote:
> Add defines for mad version and mad os_type, and replace the magic
> numbers in set_adapter_info() accordingly.
>
> Signed-off-by: Tyrel Datwyler
> ---
Is there some reason you didn't carry the review tag over
On Fri, 2016-02-12 at 08:51 -0800, Tyrel Datwyler wrote:
> On 02/12/2016 08:43 AM, James Bottomley wrote:
> > On Wed, 2016-02-10 at 19:32 -0600, Tyrel Datwyler wrote:
> > > Add defines for mad version and mad os_type, and replace the
> > > magic
> > > numbe
Could you please add a cover letter (a 0/30) and thread your patches
from that? For large patch series, it really does make following
everything a lot easier for me (and most other people who use a threaded
mail reader).
Thanks,
James
___
On Thu, 2015-08-13 at 20:30 -0700, Dan Williams wrote:
On Thu, Aug 13, 2015 at 7:31 AM, Christoph Hellwig h...@lst.de wrote:
On Wed, Aug 12, 2015 at 09:01:02AM -0700, Linus Torvalds wrote:
I'm assuming that anybody who wants to use the page-less
scatter-gather lists always does so on memory
On Wed, 2015-08-12 at 09:05 +0200, Christoph Hellwig wrote:
Dan Williams started to look into addressing I/O to and from
Persistent Memory in his series from June:
http://thread.gmane.org/gmane.linux.kernel.cross-arch/27944
I've started looking into DMA mapping of these SGLs
On Wed, 2015-05-13 at 15:31 +0200, Arnd Bergmann wrote:
On Wednesday 13 May 2015 08:23:41 Brian King wrote:
On 05/13/2015 03:10 AM, Arnd Bergmann wrote:
On Tuesday 12 May 2015 18:24:43 Brian King wrote:
Commit 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c broke 64 bit DMA for
mpt2sas on
On Fri, 2014-10-24 at 10:40 +1100, Benjamin Herrenschmidt wrote:
On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
Hey guys, was looking over the generic GUP while working on a sparc64
issue and I noticed that you guys do speculative page gets, and after
talking with Johannes Weiner
On Tue, 2014-09-09 at 06:40 -0400, Peter Hurley wrote:
On 09/08/2014 10:56 PM, James Bottomley wrote:
On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
On 09/08/2014 01:50 AM, James Bottomley wrote:
But additionally, even if gcc combines adjacent writes _that are part
of the program
On Mon, 2014-09-08 at 18:52 +0100, One Thousand Gnomes wrote:
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on
On Mon, 2014-09-08 at 11:12 -0700, H. Peter Anvin wrote:
On 09/07/2014 10:56 PM, James Bottomley wrote:
On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
How many PARISC systems do we have that actually do real work on Linux?
I'd be very surprised if this problem didn't exist
On Mon, 2014-09-08 at 16:45 -0400, Chris Metcalf wrote:
On 9/8/2014 1:50 AM, James Bottomley wrote:
Actual alignment is pretty irrelevant. That's why all architectures
which require alignment also have to implement misaligned traps ... this
is a fundamental requirement of the networking
On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
On 09/08/2014 01:50 AM, James Bottomley wrote:
Two things: I think that gcc has given up on combining adjacent writes,
perhaps because unaligned writes on some arches are prohibitive, so
whatever minor optimization was believed
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM
On Sun, 2014-09-07 at 16:41 -0400, Peter Hurley wrote:
On 09/07/2014 03:04 PM, James Bottomley wrote:
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote
paul...@linux.vnet.ibm.com wrote:
On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote:
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to bitfields, because compilers often
+ generate code to modify these using non-atomic read-modify-write
+ sequences. Do not attempt to use bitfields to
On Sat, 2014-03-22 at 11:13 -0700, Laura Abbott wrote:
Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture
specific scatterlist.h, make it a proper Kconfig option and use that
instead. At same time, remove the header files are are now mostly
useless and just include
On Sat, 2014-03-22 at 22:23 +, Russell King - ARM Linux wrote:
On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote:
Perhaps now might be the time to ask which are the remaining
architectures that cannot do SG chaining and then we can fix them and
pull the whole thing out
On Sat, 2014-03-22 at 22:52 +, Russell King - ARM Linux wrote:
On Sat, Mar 22, 2014 at 03:37:40PM -0700, James Bottomley wrote:
On Sat, 2014-03-22 at 22:23 +, Russell King - ARM Linux wrote:
On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote:
Perhaps now might
On Mon, 2013-02-04 at 10:09 +, James Hogan wrote:
The IRQ_PER_CPU Kconfig symbol was removed in the following commit:
Commit 6a58fb3bad099076f36f0f30f44507bc3275cdb6 (genirq: Remove
CONFIG_IRQ_PER_CPU) merged in v2.6.39-rc1.
But IRQ_PER_CPU wasn't removed from any of the architecture
On Wed, 2013-01-23 at 17:29 -0800, Michel Lespinasse wrote:
Update the parisc arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
Acked-by: Rik van Riel r...@redhat.com
---
On Fri, 2012-07-27 at 15:19 +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-07-18 at 18:49 +0200, o...@aepfle.de wrote:
From: Linda Xie lx...@us.ibm.com
James, can I assume you're picking up those two ?
If they get acked by the maintiners ...
James
On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
+ lib/mpi/generic_mpih-mul1.c: error: inconsistent operand
constraints in an 'asm': = 50:70
+ lib/mpi/generic_mpih-mul2.c: error: inconsistent
On Tue, 2011-08-30 at 08:32 +1000, Stephen Rothwell wrote:
Hi Linus,
On Mon, 29 Aug 2011 10:44:51 +1000 Stephen Rothwell s...@canb.auug.org.au
wrote:
After merging the fixes tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/kernel/built-in.o:
On Thu, 2011-05-19 at 13:08 +0900, Hitoshi Mitake wrote:
On Thu, May 19, 2011 at 04:11, Moore, Eric eric.mo...@lsi.com wrote:
On Wednesday, May 18, 2011 12:31 PM Milton Miller wrote:
Ingo I would propose the following commits added in 2.6.29 be reverted.
I think the current concensus is
On Tue, 2011-05-17 at 22:15 -0600, Matthew Wilcox wrote:
On Wed, May 18, 2011 at 09:37:08AM +0530, Desai, Kashyap wrote:
On Wed, 2011-05-04 at 17:23 +0530, Kashyap, Desai wrote:
The following code seems to be there in
/usr/src/linux/arch/x86/include/asm/io.h.
This is not going to
, but for the Blackfin pieces:
Acked-by: Mike Frysinger vap...@gentoo.org
This goes for parisc as well.
Acked-by: James Bottomley james.bottom...@hansenpartnership.com
James
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote:
On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote:
Hi,
this series makes it possible to build bit-identical kernel image and
modules from identical sources. Of course the build is already
deterministic in terms of behavior
On Wed, 2009-12-02 at 17:51 -0800, Pravin Bathija wrote:
Powerpc 44x uses 36 bit real address while the real address defined
in MPT Fusion driver is of type 32 bit. This causes ioremap to fail and
driver
fails to initialize. This fix changes the data types representing the real
On Thu, 2009-11-05 at 08:43 -0500, Josh Boyer wrote:
On Tue, Sep 15, 2009 at 03:25:55PM -0700, pbath...@amcc.com wrote:
From: Pravin Bathija pbath...@amcc.com
Powerpc 44x uses 36 bit real address while the real address defined
in MPT Fusion driver is of type 32 bit. This causes ioremap to
2.6.30-rc8 worked fine ... unless this is a known problem, I suppose I
can begin bisecting.
The boot log of the hang is:
Please wait, loading kernel...
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 0250, size: 8280 Kbytes
OF stdout device is: /ht/i...@8/ser...@2f8
Preparing
On Mon, 2009-06-22 at 11:11 -0500, Brian King wrote:
James,
I was running into a similar hang on one of my Power boxes as well.
Reverting c868d550115b9ccc0027c67265b9520790f05601 allowed by system
to boot. It looks like that patch injected a bug where we can end up
waiting on an
On Thu, 2009-05-21 at 14:51 -0500, James Bottomley wrote:
On Thu, 2009-05-21 at 13:47 -0500, Brian King wrote:
cc'ing linuxppc-dev...
-Brian
James Bottomley wrote:
Kernels after 2.6.30-rc1 stopped booting on my powerstation. The ipr
just times out and refuses to probe
On Thu, 2009-05-21 at 13:47 -0500, Brian King wrote:
cc'ing linuxppc-dev...
-Brian
James Bottomley wrote:
Kernels after 2.6.30-rc1 stopped booting on my powerstation. The ipr
just times out and refuses to probe devices. If I let it drop into the
initramfs system, this is what
On Thu, 2009-03-26 at 12:04 +0530, Sachin Sant wrote:
Sachin Sant wrote:
Today's next failed to boot on a powerpc box
(Power6 blade IBM,7998-61X) with following recursive locking message.
=
[ INFO: possible recursive locking detected ]
On Mon, 2009-02-09 at 11:11 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2009-02-08 at 22:29 +1100, Michael Ellerman wrote:
On Fri, 2009-02-06 at 18:42 -0800, Geoff Levand wrote:
Change the PS3 platform code to use hard coded numbers for its
LV1 device types.
The PS3 platform code
OK, so could we get this in to -rc5 please? It's a bug fix for parisc
since we're currently printing rubbish.
James
---
From: James Bottomley [EMAIL PROTECTED]
Date: Wed, 3 Sep 2008 20:43:36 -0500
Subject: lib: Correct printk %pF to work on all architectures
It was introduced by
commit
commit deac93df26b20cf8438339b5935b5f5643bc30c9
Author: James Bottomley [EMAIL PROTECTED]
Date: Wed Sep 3 20:43:36 2008 -0500
lib: Correct printk %pF to work on all architectures
Broke the non modular builds by moving an essential function into
modules.c. Fix this by moving it out again
On Wed, 2008-09-10 at 10:09 +1000, Benjamin Herrenschmidt wrote:
On Tue, 2008-09-09 at 19:04 -0500, James Bottomley wrote:
commit deac93df26b20cf8438339b5935b5f5643bc30c9
Author: James Bottomley [EMAIL PROTECTED]
Date: Wed Sep 3 20:43:36 2008 -0500
lib: Correct printk %pF to work
internal linker which knows how to deal with function descriptors sits.
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
arch/ia64/kernel/module.c |9 +
arch/parisc/kernel/module.c | 13 +
arch/powerpc/kernel/module_64.c |9 +
include/linux
On Wed, 2008-09-03 at 14:22 -0700, Linus Torvalds wrote:
On Wed, 3 Sep 2008, James Bottomley wrote:
Make dereference_function_descriptor() more accommodating by allowing
architecture overrides.
Don't do it like this.
We don't want some stupid useless weak function that is empty
On Wed, 2008-09-03 at 15:54 -0700, Linus Torvalds wrote:
Anyway, it's easy to do (if a slightly larger diff) ... I have to move
the prototype from include/kernel.h to include/module.h because I need
an assured asm/xxx include before it to get the override.
I don't really see what this has
On Wed, 2008-09-03 at 16:15 -0700, Linus Torvalds wrote:
On Wed, 3 Sep 2008, James Bottomley wrote:
You want me to pull the elf header files into lib/vsprintf.c and have
something like
No.
I want you to stop polluting linux/module.h with total and utter crap.
Please tell my WHY
Correct cc's added
On Mon, 2008-07-07 at 22:25 +1000, Stephen Rothwell wrote:
Hi James,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'map_sg_data':
drivers/scsi/ibmvscsi/ibmvscsi.c:431: error: 'FW_FEATURE_CMO'
On Tue, 2008-07-08 at 08:05 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2008-07-07 at 09:39 -0500, James Bottomley wrote:
Caused because commit 341b56db6804040aa9559e913865108424e3b18b
([SCSI]
ibmvscsi: driver enablement for CMO), which was 15/16 in a series,
has
been merged before
On Tue, 2008-06-10 at 10:41 -0700, Jesse Barnes wrote:
On Monday, June 09, 2008 11:56 pm Nick Piggin wrote:
So that still doesn't tell us what *minimum* level of ordering we should
provide in the cross platform readl/writel API. Some relatively sane
suggestions would be:
- as strong as
On Thu, 2008-05-29 at 10:47 -0400, Jes Sorensen wrote:
Roland == Roland Dreier [EMAIL PROTECTED] writes:
This is a different issue. We deal with it on powerpc by having
writel set a per-cpu flag and spin_unlock() test it, and do the
barrier if needed there.
Roland Cool... I assume you
On Tue, 2008-05-27 at 08:50 -0700, Roland Dreier wrote:
Though it's my understanding that at least ia64 does require the
explicit barriers anyway, so we are still in a dodgy situation here
where it's not clear what drivers should do and we end up with
possibly excessive barriers on
On Tue, 2008-05-27 at 10:38 -0700, Roland Dreier wrote:
Actually, this specifically should not be. The need for mmiowb on altix
is because it explicitly violates some of the PCI rules that would
otherwise impede performance. The compromise is that readX on altix
contains the needed
On Fri, 2007-09-14 at 12:50 -0700, Medve Emilian-EMMEDVE1 wrote:
Which solution would you be more comfortable with?
The one which is currently in -mm is this one:
http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=49892223f7d3a2333ef9e6cbdd526676e1fc517a
James
On Fri, 2007-07-13 at 17:10 +0200, Geert Uytterhoeven wrote:
On Fri, 13 Jul 2007, Arnd Bergmann wrote:
On Friday 13 July 2007, James Bottomley wrote:
IC.
- flush_kernel_dcache_page() is a no-op on ppc64
(ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE is defined on parisc only
73 matches
Mail list logo