From: Andi Kleen a...@linux.intel.com
These data structures are accessed by different CPUs and have some
fields which are mostly read only and others which are frequently
written. Separate some common ones into separate cache line
to minimize false sharing while submitting a command.
This allows
Alexei Starovoitov alexei.starovoi...@gmail.com writes:
disable Value Range Propagation pass:
-fdisable-tree-vrp1 -fdisable-tree-vrp2
and complete unroll pass:
-fdisable-tree-cunrolli
Can you file a gcc bug with test case?
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To
On Wed, Jul 24, 2013 at 04:42:42AM +0100, Ben Hutchings wrote:
This looks like a candidate for stable:
Don't know if it's a security issue, but should be fine for stable.
-Andi
commit 16da05b1158d1bcb31656e636a8736a663b1cf1f
Author: Andi Kleen a...@firstfloor.org
Date: Mon Sep 3 20:50
--
From: Andi Kleen a...@linux.intel.com
Subject: sections: fix section conflicts in drivers/scsi
NAK this, please. We're fixing all of this by removing CONFIG_HOTPLUG,
so all __dev annotations become nops and there's little point
On Fri, Sep 14, 2012 at 03:03:49PM +0100, James Bottomley wrote:
On Fri, 2012-09-14 at 06:50 -0700, Andi Kleen wrote:
--
From: Andi Kleen a...@linux.intel.com
Subject: sections: fix section conflicts in drivers/scsi
NAK
Naresh Kumar Inna nar...@chelsio.com writes:
OK, I think I should be able to arrange the patch set to fulfill that
requirement. I was under the impression it was fine for new drivers to
split patches in this fashion, since they go as a single commit, sorry
about that.
What they normally do
));
^
Signed-off-by: Andi Kleen a...@linux.intel.com
diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c
index 73f231c..8d4626c 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_io.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_io.c
@@ -1807,7 +1807,7 @@ static void bnx2fc_parse_fcp_rsp(struct
-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/sg.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux/drivers/scsi/sg.c
===
--- linux.orig/drivers/scsi/sg.c
+++ linux/drivers/scsi/sg.c
@@ -745,7
On Mon, Feb 25, 2008 at 06:43:08AM -0800, James Bottomley wrote:
On Mon, 2008-02-25 at 00:36 +0100, Andi Kleen wrote:
Don't use unnecessary GFP_ATOMIC in sg.c
sg.c uses GFP_ATOMIC for a lot of allocations where it isn't necessary.
There are no locks hold and I don't see any other reasons
On Mon, Feb 25, 2008 at 06:48:28AM -0800, James Bottomley wrote:
On Mon, 2008-02-25 at 00:35 +0100, Andi Kleen wrote:
sense buffers are something that still needs to be explicitely
bounced in the scsi layer. Instead of using the global unchecked_isa_dma
flag define a special fine grained
On Mon, Feb 25, 2008 at 07:00:34AM -0800, James Bottomley wrote:
On Mon, 2008-02-25 at 15:56 +0100, Andi Kleen wrote:
On Mon, Feb 25, 2008 at 06:43:08AM -0800, James Bottomley wrote:
On Mon, 2008-02-25 at 00:36 +0100, Andi Kleen wrote:
Don't use unnecessary GFP_ATOMIC in sg.c
On Mon, Feb 25, 2008 at 07:04:20AM -0800, James Bottomley wrote:
On Mon, 2008-02-25 at 15:58 +0100, Andi Kleen wrote:
On Mon, Feb 25, 2008 at 06:46:58AM -0800, James Bottomley wrote:
On Mon, 2008-02-25 at 00:35 +0100, Andi Kleen wrote:
Should not be needed because the block layer
On Mon, Feb 25, 2008 at 06:46:58AM -0800, James Bottomley wrote:
On Mon, 2008-02-25 at 00:35 +0100, Andi Kleen wrote:
Should not be needed because the block layer bounces that all.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/scsi_scan.c |6 ++
1 file
You've already added a new special field with your u64
sense_buffer_mask;
Ok I'll add another one for this case so that you can still
have zero copy SCSI scan. Or maybe it can check the block
layer bounce information directly here.
It's a special case field for ISA devices because everything
On Mon, Feb 25, 2008 at 02:47:46PM -0700, Matthew Wilcox wrote:
On Mon, Feb 25, 2008 at 12:35:16AM +0100, Andi Kleen wrote:
That patch is a little more complicated than the others. advansys
was the only ISA driver who actually passed -cmnd to the firmware.
So I implemented a simple own
On Mon, Feb 25, 2008 at 03:50:22PM -0700, Matthew Wilcox wrote:
On Mon, Feb 25, 2008 at 11:40:35PM +0100, Andi Kleen wrote:
(I must have fixed it somehow because it works on parisc, which is most
unforgiving of drivers which do DMA without the DMA API).
At least on x86 the DMA API
Block layer bounces anyways.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/st.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/scsi/st.c
===
--- linux.orig/drivers/scsi/st.c
+++ linux
Should not be needed because the block layer bounces that all.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/scsi_scan.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
Index: linux/drivers/scsi/scsi_scan.c
All buffers are bounced by the block layer
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux/drivers/scsi/sr.c
===
--- linux.orig/drivers/scsi/sr.c
+++ linux/drivers/scsi/sr.c
@@ -674,7 +674,7 @@ static void get_sectorsize
.
Needed for followup patches.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
Documentation/scsi/scsi_mid_low_api.txt |4
drivers/scsi/hosts.c|1 +
drivers/scsi/scsi.c | 12 +++-
include/scsi/scsi_host.h| 10
- Audited -cmnd use and it always copies
- Allocate hostdata separately with GFP_DMA for the ISA case
- Tell scsi layer to bounce sense_buffer for ISA case
- Tell block layer to bounce for isa case
- Remove unchecked_isa_dma
Untested due to lack of hardware
Signed-off-by: Andi Kleen [EMAIL
All ISA drivers who relied on dma able hostdata have been converted
to allocate it separately. So remove the unchecked_isa_dma hostdata
support in the mid layer
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/hosts.c |3 ---
1 file changed, 3 deletions(-)
Index: linux/drivers
- Audited -cmnd use and it always copies
- Allocate DMAable hostdata separately
- Tell block layer explicitely to bounce
- Audited sense_buffer use and it always copies
- Remove unchecked_isa_dma finally
Untested due to lack of hardware
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers
of hardware.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/NCR53c406a.c |8 ++-
drivers/scsi/aha152x.c| 22 ---
drivers/scsi/sym53c416.c |9 +++
drivers/scsi/u14-34f.c| 52 +++---
drivers/scsi
All ISA drivers explicitely tell the block layer now that it needs
to bounce for them, so SCSI mid layer doesn't need to do that automatically
for unchecked_isa_dma anymore.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c |2 --
1 file changed, 2 deletions(-)
Index
All buffers are bounced by the block layer
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux/drivers/scsi/ch.c
===
--- linux.orig/drivers/scsi/ch.c
+++ linux/drivers/scsi/ch.c
@@ -231,7 +231,7 @@ ch_read_element_status
No drivers need it anymore
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/scsi.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux/drivers/scsi/scsi.c
===
--- linux.orig/drivers/scsi/scsi.c
Lots of drivers set it to 0. Remove that. Patch should be a nop.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/arm/acornscsi.c |1 -
drivers/scsi/arm/cumana_1.c |1 -
drivers/scsi/dc395x.c|1 -
drivers/scsi/eata_pio.c |2 --
drivers/scsi/hptiop.c
Bounced by the block layer anyways
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux/drivers/scsi/sr_vendor.c
===
--- linux.orig/drivers/scsi/sr_vendor.c
+++ linux/drivers/scsi/sr_vendor.c
@@ -117,7 +117,7 @@ int
They are only used to allocate data buffers, and those are bounced
by the block layer anyways.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/sg.c | 36 +---
1 file changed, 9 insertions(+), 27 deletions(-)
Index: linux/drivers/scsi/sg.c
- -cmnd handling audited and does always copy
- Allocate hostdata separately
- Enable sense_buffer isa bounce buffering
- Remove unchecked_isa_dma
- Enable block layer bouncing explicitely for isa adapters
Untested due to lack of hardware
Signed-off-by: Andi Kleen [EMAIL PROTECTED
Everything should be bounced by the block layer now
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/sr_ioctl.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
Index: linux/drivers/scsi/sr_ioctl.c
, but only because it happens
to patch the same places (no real functional dependency)
Tested by burning a CD on a kernel with all lock/sleep/etc. debugging enabled.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/sg.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions
I opted to remove it because it's unlikely that user space uses it.
An alternative would be to always make it report 0 now.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/scsi_sysfs.c |2 --
1 file changed, 2 deletions(-)
Index: linux/drivers/scsi/scsi_sysfs.c
the mid layer to do this anymore.
- allocate hostdata with GFP_DMA separately for the ISA case
- Tell block layer explicitely to bounce for ISA case
- remove unchecked_isa_dma
Untested due to lack of hardware
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/advansys.c | 216
Now that no low level driver relies on ISA DMAable scsi_cmnds anymore
it is safe to always use the same static slab for them.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/scsi.c | 46 +++---
1 file changed, 23 insertions(+), 23
This patchkit fixes all existing drivers that used isa_unchecked_dma
to not need that anymore. I have some upcoming infrastructure changes
for DMA memory management and isa_unchecked_dma was in the way.
Enabling isa_unchecked_dma had several effects:
- All incoming scsi_cmnds were in GFP_DMA
Now that all users are gone it can be safely completely removed.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
Documentation/scsi/scsi_mid_low_api.txt |3 ---
drivers/scsi/hosts.c|1 -
include/scsi/scsi_host.h|6 --
3 files changed, 10
Some people consider it worth it for their memory restricted systems
and would like to drive the annotations even further. [1]
They could get much better bang-for-the-buck (as in memory saved
for amount of work invested) by tackling some the dynamic memory allocation
pigs.
In general it's a
The ideal solution would be to do mapping against a different struct
device for each port, so that we could maintain the proper DMA mask for
each of them at all times. However I'm not sure if that's possible.
I cannot imagine why it should be that difficult. The PCI subsystem
could over a
--guessing data in;
program cdparanoia not setting count and/or reply_len properly
printk: 1078 messages suppressed.
and many more of those. With this patch the message is only printed once
for a command in a row.
v1-v2: Prevent rate limit messages too (pointed out by jejb)
Signed-off-by: Andi
On Thu, Jan 10, 2008 at 12:03:24PM -0700, Matthew Wilcox wrote:
On Thu, Jan 10, 2008 at 07:59:44PM +0100, Andi Kleen wrote:
Really, all this is doing is open coding what the ioctl handler is doing
anyway, isn't it? in which case, why bother to change it at all?
Because once it's open
On Thu, Jan 10, 2008 at 08:07:48PM +0100, Andre Noll wrote:
On 19:59, Andi Kleen wrote:
But perhaps for such a long ioctl handler it would be better to move
the lock/unlock_kernel()s into the individual case ...: statements;
then it could be eliminated step by step.
Sure, I can do
On Thu, Jan 10, 2008 at 01:03:48PM -0600, James Bottomley wrote:
On Thu, 2008-01-10 at 19:59 +0100, Andi Kleen wrote:
Really, all this is doing is open coding what the ioctl handler is doing
anyway, isn't it? in which case, why bother to change it at all?
Because once it's open coded
Really, all this is doing is open coding what the ioctl handler is doing
anyway, isn't it? in which case, why bother to change it at all?
Because once it's open coded it is visible and can then be eliminated.
Does SCSI need the BKL at all?
But perhaps for such a long ioctl handler it would be
If your goal is to get rid of the BKL everywhere, sure. It's not clear
to me this is the most productive way of spending our time though.
I believe eventually eliminating -ioctl (as opposed to -unlocked_ioctl)
would be a productive thing to do. Still having implicit BKL semantics in
such an
Jon Watte [EMAIL PROTECTED] writes:
Any help or pointers to self-help would be appreciated!
The usual mistake is to not enable CONFIG_BLK_DEV_SD
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Wed, Jan 09, 2008 at 10:41:59PM +0100, Stefan Richter wrote:
Matthew Wilcox wrote:
OK, how about this?
config BLK_DEV_ATA_SD
tristate ATA disc support
select BLK_DEV_SD
config BLK_DEV_ATA_SR
tristate ATA CDROM support
select BLK_DEV_SR
It's probably OK
On Thu, Jan 10, 2008 at 12:03:59AM +0100, Stefan Richter wrote:
Andi Kleen wrote:
On Wed, Jan 09, 2008 at 10:41:59PM +0100, Stefan Richter wrote:
However, this further obfuscates the fact that libata uses Linux' SCSI
midlayer and highlevel. Which is a bad thing. For example
. With this patch the message is only printed once
for a command in a row.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/scsi/sg.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
Index: linux/drivers/scsi/sg.c
The popular solutions I've seen are:
1) Random bytes, or fixed id + random bytes. Even on a worldwide net,
collisions are highly unlikely.
The problem is that the random bytes are not necessarily random; especially
not at boot:
get_random_bytes gets its randomness from the entropy pool.
I can see where you're coming from, but logically, this is wrong.
There's a huge slew of enterprise machines that only have DVD on SATA.
... and enterprise systems don't really care about a few KB more of code.
In fact you definitely want to have SATA compiled in in case you need
to recover the
The current setup expresses the dependencies as they exist -- OPTIONAL
extras, and that is a problem once a year or so, when someone builds
Disk support over SCSI/SATA is hardly an optional extra. It's more the 99+%
case.
their own kernel but must learn this fact anew.
When it costs 1
way would
be to just select SD automatically for !EMBEDDED
Here's a patch:
-Andi
Select BLK_DEV_SD for all SCSI/libata drivers
This avoid a common user mistake.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux-2.6.23-rc1-misc/drivers/ata/Kconfig
I'd say that someone needs to use a vendor kernel, or at least
begin with a vendor .config file...
Vendor kernels tend to compile forever and require initrds. For
just testing a kernel quickly compiling only a few drivers in
is much more convenient.
Also when you've been using CONFIG_IDE
On Sat, Sep 08, 2007 at 08:30:06PM +0200, Stefan Richter wrote:
Andi Kleen wrote:
when you've been using CONFIG_IDE before it is not completely
obvious you need BLK_SD for your hard disk.
Switching to different drivers without reading the help text?
Tough.
The individual driver
So anyway, what's actually failing is one of these:
Thanks for the analysis.
In theory we could not fail DAC if the machine has 4GB RAM to work around
such buggy drivers, but then they would fail anyways with 4GB. Also
the failure was intended to allow some drivers to use more efficient non
Jeff Garzik [EMAIL PROTECTED] writes:
No code changes, only indentation and blank line additions, plus code to
call the new split-out functions.
Could you put the ISA code into #ifdef CONFIG_ISA while you're on it?
That would allow dropping it on x86-64
-Andi
-
To unsubscribe from this
aic79xx in scsi-misc would oops when no hardware was present.
Reason was a duplicated call to free the spi transport object -
it was done both in ahd_linux_exit and in the cleanup part
of ahd_linux_init.
Just remove the superfluous call.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux
Arjan van de Ven [EMAIL PROTECTED] writes:
You want to *use* the kernel pagecache as much as you can. You do so by
using mmap and such, and msync to force content to disk. That uses the
Last time I checked you couldn't mmap block devices. Has this changed
now? Could be a problem for an iSCSI
Luben Tuikov [EMAIL PROTECTED] writes:
+/** Misc Macros
***/
[... lots of code...]
What are they all good for? As far as I can see every one of them
duplicates or wraps something Linux already has.
How about you just use the
[...]
Willy pointed out a bogus hunk in the original patch that should not
have been there. Retransmit with that removed. Also mark scsi_cmnd_serial
inline.
This patch fixes one of Christroph's fixme comments in the SCSI midlayer.
The selection of the serial number and pid for commands was
On Wed, Jan 19, 2005 at 11:25:42AM -0700, Moore, Eric Dean wrote:
On Tuesday, January 18, 2005 4:22 AM, Andi Kleen wrote:
Convert mptctl driver to new compat_ioctl entry point.
Only compile tested.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
This doesn't compile. Andi - Pls
On Thu, Jan 20, 2005 at 06:24:25PM -0700, Moore, Eric Dean wrote:
On Thursday, January 20, 2005 2:38 AM, Andi Kleen wrote:
Sorry. I swear it compiled at one point, but some last minute
changes must have broken it. Please try this version.
Convert mptctl to compat_ioctl. I also
On Wed, Jan 19, 2005 at 07:55:01AM -0800, James Bottomley wrote:
On Wed, 2005-01-19 at 00:27 +0100, Andi Kleen wrote:
On Tue, Jan 18, 2005 at 07:35:36AM -0800, James Bottomley wrote:
Shouldn't this also be surrounded by #ifdef CONFIG_COMPAT (on the
grounds that you never fill it in unless
On Tue, Jan 18, 2005 at 09:35:53PM +1000, Douglas Gilbert wrote:
Andi Kleen wrote:
snip
@@ -1343,6 +1366,9 @@
.write = sg_write,
.poll = sg_poll,
.ioctl = sg_ioctl,
+#ifdef CONFIG_COMPAT
+.ioctl = sg_compat_ioctl,
+#endif
Andi,
Two initializations of .ioctl looks
How about having a macro ...
.ioctl =st_ioctl,
COMPAT_IOCTL_ENTRY(st_compat_ioctl)
.open = st_open,
which could be defined something like:
#ifdef CONFIG_COMPAT
#define COMPAT_IOCTL_ENTRY(x) .compat_ioctl = x,
#else
#define COMPAT_IOCTL_ENTRY(x) /*
On Tue, Jan 18, 2005 at 07:35:36AM -0800, James Bottomley wrote:
On Tue, 2005-01-18 at 12:03 +0100, Andi Kleen wrote:
Add a call vector for 32bit compat ioctls to the SCSI host
structure. This is needed for some followon patches.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Shouldn't
68 matches
Mail list logo
