* Re: linux-next: Tree for December 29 (fcoe/libfc)
From: Kamalesh Babulal @ 2008-12-30 17:40 UTC (permalink / raw)
To: James Bottomley
Cc: Randy Dunlap, Stephen Rothwell, scsi, linux-next, LKML,
Robert Love
In-Reply-To: <1230657124.3296.20.camel@localhost.localdomain>
* James Bottomley <James.Bottomley@HansenPartnership.com> [2008-12-30 17:12:04]:
> On Tue, 2008-12-30 at 08:54 -0800, Randy Dunlap wrote:
> > James Bottomley wrote:
> > > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> > > index 0e5e084..9f4cc8e 100644
> > > --- a/drivers/scsi/Kconfig
> > > +++ b/drivers/scsi/Kconfig
> > > @@ -607,13 +607,12 @@ config SCSI_FLASHPOINT
> > >
> > > config LIBFC
> > > tristate "LibFC module"
> > > - depends on SCSI && SCSI_FC_ATTRS
> > > + select SCSI_FC_ATTRS
> > > ---help---
> > > Fibre Channel library module
> > >
> > > config FCOE
> > > tristate "FCoE module"
> > > - depends on SCSI
> > > select LIBFC
> > > ---help---
> > > Fibre Channel over Ethernet module
> > >
> > >
> >
> > This still has a build error when CONFIG_PCI=n:
> >
> >
> > linux-next-20081229/drivers/scsi/fcoe/fc_transport_fcoe.c: In function 'fcoe_load_transport_driver':
> > linux-next-20081229/drivers/scsi/fcoe/fc_transport_fcoe.c:324: error: 'pci_bus_type' undeclared (first use in this function)
> > make[4]: *** [drivers/scsi/fcoe/fc_transport_fcoe.o] Error 1
>
> OK, so take two would make FCOE depend on SCSI, like this.
>
> James
>
Hi James,
Thanks, the patch fixes same build failure, with !CONFIG_PCI, which I reported some
time back today.
> ---
>
> From: James Bottomley <James.Bottomley@HansenPartnership.com>
> Subject: [SCSI] fcoe: fix configuration problems
>
> fcoe selects libfc and requires SCSI and PCI (the SCSI requirement is
> implicitly covered by an enclosing if). Fix them both up so they
> cannot be configured in an invalid state: make LIBFC select
> SCSI_FC_ATTRS and make FCOE depend on PCI and select LIBFC.
>
Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> ---
> drivers/scsi/Kconfig | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 0e5e084..152d4aa 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -607,13 +607,13 @@ config SCSI_FLASHPOINT
>
> config LIBFC
> tristate "LibFC module"
> - depends on SCSI && SCSI_FC_ATTRS
> + select SCSI_FC_ATTRS
> ---help---
> Fibre Channel library module
>
> config FCOE
> tristate "FCoE module"
> - depends on SCSI
> + depends on PCI
> select LIBFC
> ---help---
> Fibre Channel over Ethernet module
> --
> 1.5.6.6
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* RE: Pull request for FS-Cache, including NFS patches
From: Trond Myklebust @ 2008-12-30 18:44 UTC (permalink / raw)
To: Muntz, Daniel
Cc: Stephen Rothwell, Bernd Schubert, nfsv4, steved, linux-kernel,
dhowells, linux-next, linux-fsdevel, Andrew Morton, rwheeler
In-Reply-To: <7A24DF798E223B4C9864E8F92E8C93EC01AAFE24@SACMVEXC1-PRD.hq.netapp.com>
On Mon, 2008-12-29 at 15:05 -0800, Muntz, Daniel wrote:
> Before throwing the 'FUD' acronym around, maybe you should re-read the
> details. My point was that there were few users of cachefs even when
> the technology had the potential for greater benefit (slower networks,
> less powerful servers, smaller memory caches). Obviously cachefs can
> improve performance--it's simply a function of workload and the
> assumptions made about server/disk/network bandwidth. However, I would
> expect the real benefits and real beneficiaries to be fewer than in the
> past. HOWEVER^2 I did provide some argument(s) in favor of adding
> cachefs, and look forward to extensions to support delayed write,
> offline operation, and NFSv4 support with real consistency checking (as
> long as I don't have to take the customer calls ;-). BTW,
> animation/video shops were one group that did benefit, and I imagine
> they still could today (the one I had in mind did work across Britain,
> the US, and Asia and relied on cachefs for overcoming slow network
> connections). Wonder if the same company is a RH customer...
I did read your argument. My point is that although the argument sounds
reasonable, it ignores the fact that the customer bases are completely
different. The people asking for cachefs on Linux typically run a
cluster of 2000+ clients all accessing the same read-only data from just
a handful of servers. They're primarily looking to improve the
performance and stability of the _servers_, since those are the single
point of failure of the cluster.
As far as I know, historically there has never been a market for 2000+
HP-UX, or even Solaris based clusters, and unless the HP and Sun product
plans change drastically, then simple economics dictates that nor will
there ever be such a market, whether or not they have cachefs support.
OpenSolaris is a different kettle of fish since it has cachefs, and does
run on COTS hardware, but there are other reasons why that hasn't yet
penetrated the HPC market.
> All the comparisons to HTTP browser implementations are, imho, absurd.
> It's fine to keep a bunch of http data around on disk because a) it's RO
> data, b) correctness is not terribly important, and c) a human is
> generally the consumer and can manually request non-cached data if
> things look wonky. It is a trivial case of caching.
See above. The majority of people I'm aware of that have been asking for
this are interested mainly in improving read-only workloads for data
that changes infrequently. Correctness tends to be important, but the
requirements are no different from those that apply to the page cache.
You mentioned the animation industry: they are prime example of an
industry that satisfies (a), (b), and (c). Ditto the oil and gas
exploration industry, as well as pretty much all scientific computing,
to mention only a few examples...
> As for security, look at what MIT had to do to prevent local disk
> caching from breaking the security guarantees of AFS.
See what David has added to the LSM code to provide the same guarantees
for cachefs...
Trond
^ permalink raw reply
* RE: Pull request for FS-Cache, including NFS patches
From: Muntz, Daniel @ 2008-12-30 22:15 UTC (permalink / raw)
To: Trond Myklebust
Cc: Andrew Morton, Stephen Rothwell, Bernd Schubert, nfsv4,
linux-kernel, steved, dhowells, linux-next, linux-fsdevel,
rwheeler
In-Reply-To: <1230662677.4952.37.camel@heimdal.trondhjem.org>
>> As for security, look at what MIT had to do to prevent local disk
>> caching from breaking the security guarantees of AFS.
>
>See what David has added to the LSM code to provide the same guarantees
for cachefs...
>
>Trond
Unless it (at least) leverages TPM, the issues I had in mind can't
really be addressed in code. One requirement is to prevent a local root
user from accessing fs information without appropriate permissions.
This leads to unwieldly requirements such as allowing only one user on a
machine at a time, blowing away the cache on logout, validating (e.g.,
refreshing) the kernel on each boot, etc. Sure, some applications won't
care, but you're also potentially opening holes that users may not
consider.
-Dan
-----Original Message-----
From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]
Sent: Tuesday, December 30, 2008 10:45 AM
To: Muntz, Daniel
Cc: Andrew Morton; Stephen Rothwell; Bernd Schubert;
nfsv4@linux-nfs.org; linux-kernel@vger.kernel.org; steved@redhat.com;
dhowells@redhat.com; linux-next@vger.kernel.org;
linux-fsdevel@vger.kernel.org; rwheeler@redhat.com
Subject: RE: Pull request for FS-Cache, including NFS patches
On Mon, 2008-12-29 at 15:05 -0800, Muntz, Daniel wrote:
> Before throwing the 'FUD' acronym around, maybe you should re-read the
> details. My point was that there were few users of cachefs even when
> the technology had the potential for greater benefit (slower networks,
> less powerful servers, smaller memory caches). Obviously cachefs can
> improve performance--it's simply a function of workload and the
> assumptions made about server/disk/network bandwidth. However, I
> would expect the real benefits and real beneficiaries to be fewer than
> in the past. HOWEVER^2 I did provide some argument(s) in favor of
> adding cachefs, and look forward to extensions to support delayed
> write, offline operation, and NFSv4 support with real consistency
> checking (as long as I don't have to take the customer calls ;-).
> BTW, animation/video shops were one group that did benefit, and I
> imagine they still could today (the one I had in mind did work across
> Britain, the US, and Asia and relied on cachefs for overcoming slow
> network connections). Wonder if the same company is a RH customer...
I did read your argument. My point is that although the argument sounds
reasonable, it ignores the fact that the customer bases are completely
different. The people asking for cachefs on Linux typically run a
cluster of 2000+ clients all accessing the same read-only data from just
a handful of servers. They're primarily looking to improve the
performance and stability of the _servers_, since those are the single
point of failure of the cluster.
As far as I know, historically there has never been a market for 2000+
HP-UX, or even Solaris based clusters, and unless the HP and Sun product
plans change drastically, then simple economics dictates that nor will
there ever be such a market, whether or not they have cachefs support.
OpenSolaris is a different kettle of fish since it has cachefs, and does
run on COTS hardware, but there are other reasons why that hasn't yet
penetrated the HPC market.
> All the comparisons to HTTP browser implementations are, imho, absurd.
> It's fine to keep a bunch of http data around on disk because a) it's
> RO data, b) correctness is not terribly important, and c) a human is
> generally the consumer and can manually request non-cached data if
> things look wonky. It is a trivial case of caching.
See above. The majority of people I'm aware of that have been asking for
this are interested mainly in improving read-only workloads for data
that changes infrequently. Correctness tends to be important, but the
requirements are no different from those that apply to the page cache.
You mentioned the animation industry: they are prime example of an
industry that satisfies (a), (b), and (c). Ditto the oil and gas
exploration industry, as well as pretty much all scientific computing,
to mention only a few examples...
> As for security, look at what MIT had to do to prevent local disk
> caching from breaking the security guarantees of AFS.
See what David has added to the LSM code to provide the same guarantees
for cachefs...
Trond
^ permalink raw reply
* Re: [PATCH -net-next 1/4] firmware: convert e100 driver to request_firmware()
From: Jeff Kirsher @ 2008-12-30 22:33 UTC (permalink / raw)
To: Jaswinder Singh Rajput
Cc: linux.nics, e1000-devel, netdev, LKML, linux-next, davem
In-Reply-To: <1230626401.24796.22.camel@jaswinder.satnam>
On Tue, Dec 30, 2008 at 12:40 AM, Jaswinder Singh Rajput
<jaswinder@infradead.org> wrote:
> Thanks to David Woodhouse for help.
>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> ---
> drivers/net/e100.c | 289 ++++++++++++------------------------
> firmware/Makefile | 2 +
> firmware/WHENCE | 11 ++
> firmware/e100/d101m_ucode.bin.ihex | 38 +++++
> firmware/e100/d101s_ucode.bin.ihex | 38 +++++
> firmware/e100/d102e_ucode.bin.ihex | 38 +++++
> 6 files changed, 219 insertions(+), 197 deletions(-)
> create mode 100644 firmware/e100/d101m_ucode.bin.ihex
> create mode 100644 firmware/e100/d101s_ucode.bin.ihex
> create mode 100644 firmware/e100/d102e_ucode.bin.ihex
>
> diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> index 9f38b16..c2b3fce 100644
> --- a/drivers/net/e100.c
> +++ b/drivers/net/e100.c
> @@ -161,6 +161,7 @@
> #include <linux/skbuff.h>
> #include <linux/ethtool.h>
> #include <linux/string.h>
> +#include <linux/firmware.h>
> #include <asm/unaligned.h>
>
>
> @@ -174,10 +175,17 @@
> #define E100_WATCHDOG_PERIOD (2 * HZ)
> #define E100_NAPI_WEIGHT 16
>
> +#define FIRMWARE_D101M "e100/d101m_ucode.bin"
> +#define FIRMWARE_D101S "e100/d101s_ucode.bin"
> +#define FIRMWARE_D102E "e100/d102e_ucode.bin"
> +
> MODULE_DESCRIPTION(DRV_DESCRIPTION);
> MODULE_AUTHOR(DRV_COPYRIGHT);
> MODULE_LICENSE("GPL");
> MODULE_VERSION(DRV_VERSION);
> +MODULE_FIRMWARE(FIRMWARE_D101M);
> +MODULE_FIRMWARE(FIRMWARE_D101S);
> +MODULE_FIRMWARE(FIRMWARE_D102E);
>
> static int debug = 3;
> static int eeprom_bad_csum_allow = 0;
> @@ -1049,178 +1057,6 @@ static void e100_configure(struct nic *nic, struct cb *cb, struct sk_buff *skb)
> c[16], c[17], c[18], c[19], c[20], c[21], c[22], c[23]);
> }
>
> -/********************************************************/
> -/* Micro code for 8086:1229 Rev 8 */
> -/********************************************************/
> -
> -/* Parameter values for the D101M B-step */
> -#define D101M_CPUSAVER_TIMER_DWORD 78
> -#define D101M_CPUSAVER_BUNDLE_DWORD 65
> -#define D101M_CPUSAVER_MIN_SIZE_DWORD 126
> -
> -#define D101M_B_RCVBUNDLE_UCODE \
> -{\
> -0x00550215, 0xFFFF0437, 0xFFFFFFFF, 0x06A70789, 0xFFFFFFFF, 0x0558FFFF, \
> -0x000C0001, 0x00101312, 0x000C0008, 0x00380216, \
> -0x0010009C, 0x00204056, 0x002380CC, 0x00380056, \
> -0x0010009C, 0x00244C0B, 0x00000800, 0x00124818, \
> -0x00380438, 0x00000000, 0x00140000, 0x00380555, \
> -0x00308000, 0x00100662, 0x00100561, 0x000E0408, \
> -0x00134861, 0x000C0002, 0x00103093, 0x00308000, \
> -0x00100624, 0x00100561, 0x000E0408, 0x00100861, \
> -0x000C007E, 0x00222C21, 0x000C0002, 0x00103093, \
> -0x00380C7A, 0x00080000, 0x00103090, 0x00380C7A, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x0010009C, 0x00244C2D, 0x00010004, 0x00041000, \
> -0x003A0437, 0x00044010, 0x0038078A, 0x00000000, \
> -0x00100099, 0x00206C7A, 0x0010009C, 0x00244C48, \
> -0x00130824, 0x000C0001, 0x00101213, 0x00260C75, \
> -0x00041000, 0x00010004, 0x00130826, 0x000C0006, \
> -0x002206A8, 0x0013C926, 0x00101313, 0x003806A8, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00080600, 0x00101B10, 0x00050004, 0x00100826, \
> -0x00101210, 0x00380C34, 0x00000000, 0x00000000, \
> -0x0021155B, 0x00100099, 0x00206559, 0x0010009C, \
> -0x00244559, 0x00130836, 0x000C0000, 0x00220C62, \
> -0x000C0001, 0x00101B13, 0x00229C0E, 0x00210C0E, \
> -0x00226C0E, 0x00216C0E, 0x0022FC0E, 0x00215C0E, \
> -0x00214C0E, 0x00380555, 0x00010004, 0x00041000, \
> -0x00278C67, 0x00040800, 0x00018100, 0x003A0437, \
> -0x00130826, 0x000C0001, 0x00220559, 0x00101313, \
> -0x00380559, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00130831, 0x0010090B, 0x00124813, \
> -0x000CFF80, 0x002606AB, 0x00041000, 0x00010004, \
> -0x003806A8, 0x00000000, 0x00000000, 0x00000000, \
> -}
> -
> -/********************************************************/
> -/* Micro code for 8086:1229 Rev 9 */
> -/********************************************************/
> -
> -/* Parameter values for the D101S */
> -#define D101S_CPUSAVER_TIMER_DWORD 78
> -#define D101S_CPUSAVER_BUNDLE_DWORD 67
> -#define D101S_CPUSAVER_MIN_SIZE_DWORD 128
> -
> -#define D101S_RCVBUNDLE_UCODE \
> -{\
> -0x00550242, 0xFFFF047E, 0xFFFFFFFF, 0x06FF0818, 0xFFFFFFFF, 0x05A6FFFF, \
> -0x000C0001, 0x00101312, 0x000C0008, 0x00380243, \
> -0x0010009C, 0x00204056, 0x002380D0, 0x00380056, \
> -0x0010009C, 0x00244F8B, 0x00000800, 0x00124818, \
> -0x0038047F, 0x00000000, 0x00140000, 0x003805A3, \
> -0x00308000, 0x00100610, 0x00100561, 0x000E0408, \
> -0x00134861, 0x000C0002, 0x00103093, 0x00308000, \
> -0x00100624, 0x00100561, 0x000E0408, 0x00100861, \
> -0x000C007E, 0x00222FA1, 0x000C0002, 0x00103093, \
> -0x00380F90, 0x00080000, 0x00103090, 0x00380F90, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x0010009C, 0x00244FAD, 0x00010004, 0x00041000, \
> -0x003A047E, 0x00044010, 0x00380819, 0x00000000, \
> -0x00100099, 0x00206FFD, 0x0010009A, 0x0020AFFD, \
> -0x0010009C, 0x00244FC8, 0x00130824, 0x000C0001, \
> -0x00101213, 0x00260FF7, 0x00041000, 0x00010004, \
> -0x00130826, 0x000C0006, 0x00220700, 0x0013C926, \
> -0x00101313, 0x00380700, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00080600, 0x00101B10, 0x00050004, 0x00100826, \
> -0x00101210, 0x00380FB6, 0x00000000, 0x00000000, \
> -0x002115A9, 0x00100099, 0x002065A7, 0x0010009A, \
> -0x0020A5A7, 0x0010009C, 0x002445A7, 0x00130836, \
> -0x000C0000, 0x00220FE4, 0x000C0001, 0x00101B13, \
> -0x00229F8E, 0x00210F8E, 0x00226F8E, 0x00216F8E, \
> -0x0022FF8E, 0x00215F8E, 0x00214F8E, 0x003805A3, \
> -0x00010004, 0x00041000, 0x00278FE9, 0x00040800, \
> -0x00018100, 0x003A047E, 0x00130826, 0x000C0001, \
> -0x002205A7, 0x00101313, 0x003805A7, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00130831, \
> -0x0010090B, 0x00124813, 0x000CFF80, 0x00260703, \
> -0x00041000, 0x00010004, 0x00380700 \
> -}
> -
> -/********************************************************/
> -/* Micro code for the 8086:1229 Rev F/10 */
> -/********************************************************/
> -
> -/* Parameter values for the D102 E-step */
> -#define D102_E_CPUSAVER_TIMER_DWORD 42
> -#define D102_E_CPUSAVER_BUNDLE_DWORD 54
> -#define D102_E_CPUSAVER_MIN_SIZE_DWORD 46
> -
> -#define D102_E_RCVBUNDLE_UCODE \
> -{\
> -0x007D028F, 0x0E4204F9, 0x14ED0C85, 0x14FA14E9, 0x0EF70E36, 0x1FFF1FFF, \
> -0x00E014B9, 0x00000000, 0x00000000, 0x00000000, \
> -0x00E014BD, 0x00000000, 0x00000000, 0x00000000, \
> -0x00E014D5, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00E014C1, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00E014C8, 0x00000000, 0x00000000, 0x00000000, \
> -0x00200600, 0x00E014EE, 0x00000000, 0x00000000, \
> -0x0030FF80, 0x00940E46, 0x00038200, 0x00102000, \
> -0x00E00E43, 0x00000000, 0x00000000, 0x00000000, \
> -0x00300006, 0x00E014FB, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00906E41, 0x00800E3C, 0x00E00E39, 0x00000000, \
> -0x00906EFD, 0x00900EFD, 0x00E00EF8, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -0x00000000, 0x00000000, 0x00000000, 0x00000000, \
> -}
> -
> -static void e100_setup_ucode(struct nic *nic, struct cb *cb, struct sk_buff *skb)
> -{
> -/* *INDENT-OFF* */
> - static struct {
> - u32 ucode[UCODE_SIZE + 1];
> - u8 mac;
> - u8 timer_dword;
> - u8 bundle_dword;
> - u8 min_size_dword;
> - } ucode_opts[] = {
> - { D101M_B_RCVBUNDLE_UCODE,
> - mac_82559_D101M,
> - D101M_CPUSAVER_TIMER_DWORD,
> - D101M_CPUSAVER_BUNDLE_DWORD,
> - D101M_CPUSAVER_MIN_SIZE_DWORD },
> - { D101S_RCVBUNDLE_UCODE,
> - mac_82559_D101S,
> - D101S_CPUSAVER_TIMER_DWORD,
> - D101S_CPUSAVER_BUNDLE_DWORD,
> - D101S_CPUSAVER_MIN_SIZE_DWORD },
> - { D102_E_RCVBUNDLE_UCODE,
> - mac_82551_F,
> - D102_E_CPUSAVER_TIMER_DWORD,
> - D102_E_CPUSAVER_BUNDLE_DWORD,
> - D102_E_CPUSAVER_MIN_SIZE_DWORD },
> - { D102_E_RCVBUNDLE_UCODE,
> - mac_82551_10,
> - D102_E_CPUSAVER_TIMER_DWORD,
> - D102_E_CPUSAVER_BUNDLE_DWORD,
> - D102_E_CPUSAVER_MIN_SIZE_DWORD },
> - { {0}, 0, 0, 0, 0}
> - }, *opts;
> -/* *INDENT-ON* */
> -
> /*************************************************************************
> * CPUSaver parameters
> *
> @@ -1280,42 +1116,101 @@ static void e100_setup_ucode(struct nic *nic, struct cb *cb, struct sk_buff *skb
> #define BUNDLEMAX (u16)6
> #define INTDELAY (u16)1536 /* 0x600 */
>
> +/* Initialize firmware */
> +static const struct firmware *e100_request_firmware(struct nic *nic)
> +{
> + const char *fw_name;
> + const struct firmware *fw;
> + u8 timer, bundle, min_size;
> + int err;
> +
> /* do not load u-code for ICH devices */
> if (nic->flags & ich)
> - goto noloaducode;
> + return NULL;
>
> /* Search for ucode match against h/w revision */
> - for (opts = ucode_opts; opts->mac; opts++) {
> - int i;
> - u32 *ucode = opts->ucode;
> - if (nic->mac != opts->mac)
> - continue;
> -
> - /* Insert user-tunable settings */
> - ucode[opts->timer_dword] &= 0xFFFF0000;
> - ucode[opts->timer_dword] |= INTDELAY;
> - ucode[opts->bundle_dword] &= 0xFFFF0000;
> - ucode[opts->bundle_dword] |= BUNDLEMAX;
> - ucode[opts->min_size_dword] &= 0xFFFF0000;
> - ucode[opts->min_size_dword] |= (BUNDLESMALL) ? 0xFFFF : 0xFF80;
> -
> - for (i = 0; i < UCODE_SIZE; i++)
> - cb->u.ucode[i] = cpu_to_le32(ucode[i]);
> - cb->command = cpu_to_le16(cb_ucode | cb_el);
> - return;
> - }
> -
> -noloaducode:
> - cb->command = cpu_to_le16(cb_nop | cb_el);
> -}
> -
> -static inline int e100_exec_cb_wait(struct nic *nic, struct sk_buff *skb,
> - void (*cb_prepare)(struct nic *, struct cb *, struct sk_buff *))
> -{
> + if (nic->mac == mac_82559_D101M)
> + fw_name = FIRMWARE_D101M;
> + else if (nic->mac == mac_82559_D101S)
> + fw_name = FIRMWARE_D101S;
> + else if (nic->mac == mac_82551_F || nic->mac == mac_82551_10)
> + fw_name = FIRMWARE_D102E;
> + else /* No ucode on other devices */
> + return NULL;
> +
> + err = request_firmware(&fw, fw_name, &nic->pdev->dev);
> + if (err) {
> + DPRINTK(PROBE, ERR, "Failed to load firmware \"%s\": %d\n",
> + fw_name, err);
> + return ERR_PTR(err);
> + }
> + /* Firmware should be precisely UCODE_SIZE (words) plus three bytes
> + indicating the offsets for BUNDLESMALL, BUNDLEMAX, INTDELAY */
> + if (fw->size != UCODE_SIZE * 4 + 3) {
> + DPRINTK(PROBE, ERR, "Firmware \"%s\" has wrong size %zu\n",
> + fw_name, fw->size);
> + release_firmware(fw);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + /* Read timer, bundle and min_size from end of firmware blob */
> + timer = fw->data[UCODE_SIZE * 4];
> + bundle = fw->data[UCODE_SIZE * 4 + 1];
> + min_size = fw->data[UCODE_SIZE * 4 + 2];
> +
> + if (timer >= UCODE_SIZE || bundle >= UCODE_SIZE ||
> + min_size >= UCODE_SIZE) {
> + DPRINTK(PROBE, ERR,
> + "\"%s\" has bogus offset values (0x%x,0x%x,0x%x)\n",
> + fw_name, timer, bundle, min_size);
> + release_firmware(fw);
> + return ERR_PTR(-EINVAL);
> + }
> + /* OK, firmware is validated and ready to use... */
> + return fw;
> +}
> +
> +static void e100_setup_ucode(struct nic *nic, struct cb *cb,
> + struct sk_buff *skb)
> +{
> + const struct firmware *fw = (void *)skb;
> + u8 timer, bundle, min_size;
> +
> + /* It's not a real skb; we just abused the fact that e100_exec_cb
> + will pass it through to here... */
> + cb->skb = NULL;
> +
> + /* firmware is stored as little endian already */
> + memcpy(cb->u.ucode, fw->data, UCODE_SIZE * 4);
> +
> + /* Read timer, bundle and min_size from end of firmware blob */
> + timer = fw->data[UCODE_SIZE * 4];
> + bundle = fw->data[UCODE_SIZE * 4 + 1];
> + min_size = fw->data[UCODE_SIZE * 4 + 2];
> +
> + /* Insert user-tunable settings in cb->u.ucode */
> + cb->u.ucode[timer] &= cpu_to_le32(0xFFFF0000);
> + cb->u.ucode[timer] |= cpu_to_le32(INTDELAY);
> + cb->u.ucode[bundle] &= cpu_to_le32(0xFFFF0000);
> + cb->u.ucode[bundle] |= cpu_to_le32(BUNDLEMAX);
> + cb->u.ucode[min_size] &= cpu_to_le32(0xFFFF0000);
> + cb->u.ucode[min_size] |= cpu_to_le32((BUNDLESMALL) ? 0xFFFF : 0xFF80);
> +
> + cb->command = cpu_to_le16(cb_ucode | cb_el);
> +}
> +
> +static inline int e100_load_ucode_wait(struct nic *nic)
> +{
> + const struct firmware *fw;
> int err = 0, counter = 50;
> struct cb *cb = nic->cb_to_clean;
>
> - if ((err = e100_exec_cb(nic, NULL, e100_setup_ucode)))
> + fw = e100_request_firmware(nic);
> + /* If it's NULL, then no ucode is required */
> + if (!fw || IS_ERR(fw))
> + return PTR_ERR(fw);
> +
> + if ((err = e100_exec_cb(nic, (void *)fw, e100_setup_ucode)))
> DPRINTK(PROBE,ERR, "ucode cmd failed with error %d\n", err);
>
> /* must restart cuc */
> @@ -1435,7 +1330,7 @@ static int e100_hw_init(struct nic *nic)
> return err;
> if((err = e100_exec_cmd(nic, ruc_load_base, 0)))
> return err;
> - if ((err = e100_exec_cb_wait(nic, NULL, e100_setup_ucode)))
> + if ((err = e100_load_ucode_wait(nic)))
> return err;
> if((err = e100_exec_cb(nic, NULL, e100_configure)))
> return err;
> diff --git a/firmware/Makefile b/firmware/Makefile
> index 4993a4b..d99000d 100644
> --- a/firmware/Makefile
> +++ b/firmware/Makefile
> @@ -28,6 +28,8 @@ fw-shipped-$(CONFIG_CHELSIO_T3) += cxgb3/t3b_psram-1.1.0.bin \
> cxgb3/t3c_psram-1.1.0.bin \
> cxgb3/t3fw-7.0.0.bin
> fw-shipped-$(CONFIG_DVB_TTUSB_BUDGET) += ttusb-budget/dspbootcode.bin
> +fw-shipped-$(CONFIG_E100) += e100/d101m_ucode.bin e100/d101s_ucode.bin \
> + e100/d102e_ucode.bin
> fw-shipped-$(CONFIG_SMCTR) += tr_smctr.bin
> fw-shipped-$(CONFIG_SND_KORG1212) += korg/k1212.dsp
> fw-shipped-$(CONFIG_SND_MAESTRO3) += ess/maestro3_assp_kernel.fw \
> diff --git a/firmware/WHENCE b/firmware/WHENCE
> index 8f06639..040967f 100644
> --- a/firmware/WHENCE
> +++ b/firmware/WHENCE
> @@ -360,3 +360,14 @@ License: GPLv2 or OpenIB.org BSD license, no source visible
>
> --------------------------------------------------------------------------
>
> +Driver: e100 -- Intel PRO/100 Ethernet NIC
> +
> +File: e100/d101m_ucode.bin
> +File: e100/d101s_ucode.bin
> +File: e100/d102e_ucode.bin
> +
> +Licence: Unknown
> +
> +Found in hex form in kernel source.
> +
> +--------------------------------------------------------------------------
> diff --git a/firmware/e100/d101m_ucode.bin.ihex b/firmware/e100/d101m_ucode.bin.ihex
> new file mode 100644
> index 0000000..12971ed
> --- /dev/null
> +++ b/firmware/e100/d101m_ucode.bin.ihex
> @@ -0,0 +1,38 @@
> +:10000000150255003704FFFFFFFFFFFF8907A70612
> +:10001000FFFFFFFFFFFF580501000C001213100047
> +:1000200008000C00160238009C001000564020000A
> +:10003000CC802300560038009C0010000B4C24009C
> +:1000400000080000184812003804380000000000C2
> +:1000500000001400550538000080300062061000D2
> +:100060006105100008040E006148130002000C0036
> +:10007000933010000080300024061000610510004D
> +:1000800008040E00610810007E000C00212C2200E4
> +:1000900002000C00933010007A0C380000000800B9
> +:1000A000903010007A0C38000000000000000000C2
> +:1000B00000000000000000009C0010002D4C2400F7
> +:1000C000040001000010040037043A00104004004E
> +:1000D0008A07380000000000990010007A6C2000A8
> +:1000E0009C001000484C24002408130001000C0060
> +:1000F00013121000750C260000100400040001000B
> +:100100002608130006000C00A806220026C91300CA
> +:1001100013131000A80638000000000000000000C3
> +:1001200000000000000000000000000000000000CF
> +:10013000000000000000000000060800101B100076
> +:10014000040005002608100010121000340C3800BE
> +:1001500000000000000000005B1521009900100065
> +:10016000596520009C0010005945240036081300F2
> +:1001700000000C00620C220001000C00131B100098
> +:100180000E9C22000E0C21000E6C22000E6C210031
> +:100190000EFC22000E5C21000E4C2100550538009B
> +:1001A0000400010000100400678C27000008040010
> +:1001B0000081010037043A002608130001000C00FA
> +:1001C00059052200131310005905380000000000E3
> +:1001D000000000000000000000000000000000001F
> +:1001E00000000000000000000000000031081300C3
> +:1001F0000B0910001348120080FF0C00AB0626000C
> +:100200000010040004000100A806380000000000EF
> +:0B02100000000000000000004E417ED6
> +:00000001FF
> +/********************************************************/
> +/* Micro code for 8086:1229 Rev 8 */
> +/********************************************************/
> diff --git a/firmware/e100/d101s_ucode.bin.ihex b/firmware/e100/d101s_ucode.bin.ihex
> new file mode 100644
> index 0000000..102c7fe
> --- /dev/null
> +++ b/firmware/e100/d101s_ucode.bin.ihex
> @@ -0,0 +1,38 @@
> +:10000000420255007E04FFFFFFFFFFFF1808FF06B6
> +:10001000FFFFFFFFFFFFA60501000C0012131000F9
> +:1000200008000C00430238009C00100056402000DD
> +:10003000D0802300560038009C0010008B4F240015
> +:1000400000080000184812007F043800000000007B
> +:1000500000001400A30538000080300010061000D6
> +:100060006105100008040E006148130002000C0036
> +:10007000933010000080300024061000610510004D
> +:1000800008040E00610810007E000C00A12F220061
> +:1000900002000C0093301000900F380000000800A0
> +:1000A00090301000900F38000000000000000000A9
> +:1000B00000000000000000009C001000AD4F240074
> +:1000C00004000100001004007E043A001040040007
> +:1000D000190838000000000099001000FD6F200092
> +:1000E0009A001000FDAF20009C001000C84F2400B3
> +:1000F0002408130001000C0013121000F70F260053
> +:1001000000100400040001002608130006000C0083
> +:100110000007220026C9130013131000000738003F
> +:1001200000000000000000000000000000000000CF
> +:10013000000000000000000000060800101B100076
> +:10014000040005002608100010121000B60F380039
> +:100150000000000000000000A91521009900100017
> +:10016000A76520009A001000A7A520009C001000A1
> +:10017000A74524003608130000000C00E40F2200FD
> +:1001800001000C00131B10008E9F22008E0F210017
> +:100190008E6F22008E6F21008EFF22008E5F210065
> +:1001A0008E4F2100A3053800040001000010040058
> +:1001B000E98F270000080400008101007E043A0056
> +:1001C0002608130001000C00A705220013131000DD
> +:1001D000A70538000000000000000000000000003B
> +:1001E000000000000000000000000000000000000F
> +:1001F00000000000310813000B0910001348120022
> +:1002000080FF0C000307260000100400040001001A
> +:0B02100000073800000000004E438093
> +:00000001FF
> +/********************************************************/
> +/* Micro code for 8086:1229 Rev 9 */
> +/********************************************************/
> diff --git a/firmware/e100/d102e_ucode.bin.ihex b/firmware/e100/d102e_ucode.bin.ihex
> new file mode 100644
> index 0000000..9e806da
> --- /dev/null
> +++ b/firmware/e100/d102e_ucode.bin.ihex
> @@ -0,0 +1,38 @@
> +:100000008F027D00F904420E850CED14E914FA14F8
> +:10001000360EF70EFF1FFF1FB914E00000000000AE
> +:100020000000000000000000BD14E000000000001F
> +:100030000000000000000000D514E00000000000F7
> +:1000400000000000000000000000000000000000B0
> +:100050000000000000000000C114E00000000000EB
> +:100060000000000000000000000000000000000090
> +:100070000000000000000000000000000000000080
> +:100080000000000000000000000000000000000070
> +:100090000000000000000000C814E00000000000A4
> +:1000A000000000000000000000062000EE14E00048
> +:1000B000000000000000000080FF3000460E9400A9
> +:1000C0000082030000201000430EE000000000004A
> +:1000D000000000000000000006003000FB14E000FB
> +:1000E0000000000000000000000000000000000010
> +:1000F0000000000000000000000000000000000000
> +:1001000000000000000000000000000000000000EF
> +:100110000000000000000000416E90003C0E8000D6
> +:10012000390EE00000000000FD6E9000FD0E900012
> +:10013000F80EE000000000000000000000000000D9
> +:1001400000000000000000000000000000000000AF
> +:10015000000000000000000000000000000000009F
> +:10016000000000000000000000000000000000008F
> +:10017000000000000000000000000000000000007F
> +:10018000000000000000000000000000000000006F
> +:10019000000000000000000000000000000000005F
> +:1001A000000000000000000000000000000000004F
> +:1001B000000000000000000000000000000000003F
> +:1001C000000000000000000000000000000000002F
> +:1001D000000000000000000000000000000000001F
> +:1001E000000000000000000000000000000000000F
> +:1001F00000000000000000000000000000000000FF
> +:1002000000000000000000000000000000000000EE
> +:0B02100000000000000000002A362E55
> +:00000001FF
> +/********************************************************/
> +/* Micro code for the 8086:1229 Rev F/10 */
> +/********************************************************/
> --
> 1.5.5.1
>
Please hold off on committing, until we have had ample time to do some
regression testing. While this patch may have been in linux-next,
this is the first we have seen of it.
I am concerned that IPMI traffic will be adversely affected by this patch.
--
Cheers,
Jeff
------------------------------------------------------------------------------
^ permalink raw reply
* RE: Pull request for FS-Cache, including NFS patches
From: Trond Myklebust @ 2008-12-30 22:36 UTC (permalink / raw)
To: Muntz, Daniel
Cc: Stephen Rothwell, Bernd Schubert, nfsv4, steved, linux-kernel,
dhowells, linux-next, linux-fsdevel, Andrew Morton, rwheeler
In-Reply-To: <7A24DF798E223B4C9864E8F92E8C93EC01AAFE66@SACMVEXC1-PRD.hq.netapp.com>
On Tue, 2008-12-30 at 14:15 -0800, Muntz, Daniel wrote:
> >> As for security, look at what MIT had to do to prevent local disk
> >> caching from breaking the security guarantees of AFS.
> >
> >See what David has added to the LSM code to provide the same guarantees
> for cachefs...
> >
> >Trond
>
> Unless it (at least) leverages TPM, the issues I had in mind can't
> really be addressed in code. One requirement is to prevent a local root
> user from accessing fs information without appropriate permissions.
> This leads to unwieldly requirements such as allowing only one user on a
> machine at a time, blowing away the cache on logout, validating (e.g.,
> refreshing) the kernel on each boot, etc. Sure, some applications won't
> care, but you're also potentially opening holes that users may not
> consider.
You can't prevent a local root user from accessing cached data: that's
true with or without cachefs. root can typically access the data
using /dev/kmem, swap, intercepting tty traffic, spoofing user creds,...
If root can't be trusted, then find another machine.
The worry is rather that privileged daemons may be tricked into
revealing said data to unprivileged users, or that unprivileged users
may attempt to read data from files to which they have no rights using
the cachefs itself. That is a problem that is addressable by means of
LSM, and is what David has attempted to solve.
Trond
^ permalink raw reply
* Re: [ofa-general] Re: linux-next: origin tree build failure
From: Stephen Rothwell @ 2008-12-30 22:52 UTC (permalink / raw)
To: Roland Dreier; +Cc: linux-next, Linus, LKML, general
In-Reply-To: <20081231024654.a73f20df.sfr@canb.auug.org.au>
[-- Attachment #1.1: Type: text/plain, Size: 856 bytes --]
Hi Roland,
On Wed, 31 Dec 2008 02:46:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 30 Dec 2008 07:41:36 -0800 Roland Dreier <rdreier@cisco.com> wrote:
> >
> > > I can drop the revert after your fix goes into Linus' tree (since that is
> > > where the breakage is) ... looking forward to it, thanks.
> >
> > Shouldn't it work if the fix is in my for-next branch, since you pull
> > that as part of the -next tree? Or am I unclear on how -next works?
>
> I also build the tree between merging most of the trees (including after
> fetching Linus' latest tree).
So instead of the revert, I will cherry-pick your fix commit just after
Linus' tree today on the assumption that you will send it to him ASAP.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [ofa-general] Re: linux-next: origin tree build failure
From: Roland Dreier @ 2008-12-30 22:56 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Linus, LKML, general
In-Reply-To: <20081231095228.b21cffe0.sfr@canb.auug.org.au>
> So instead of the revert, I will cherry-pick your fix commit just after
> Linus' tree today on the assumption that you will send it to him ASAP.
Yes, I will batch up a few other things and send a pull request today.
- R.
^ permalink raw reply
* RE: Pull request for FS-Cache, including NFS patches
From: Muntz, Daniel @ 2008-12-30 23:00 UTC (permalink / raw)
To: Trond Myklebust
Cc: Stephen Rothwell, Bernd Schubert, nfsv4, steved, linux-kernel,
dhowells, linux-next, linux-fsdevel, Andrew Morton, rwheeler
In-Reply-To: <1230676568.11508.21.camel@heimdal.trondhjem.org>
Yes, and if you have a single user on the machine at a time (with cache
flushed inbetween, kernel refreshed), root can read /dev/kmem, swap,
intercept traffic and read cachefs data to its heart's content--hence,
those requirements.
-Dan
-----Original Message-----
From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]
Sent: Tuesday, December 30, 2008 2:36 PM
To: Muntz, Daniel
Cc: Andrew Morton; Stephen Rothwell; Bernd Schubert;
nfsv4@linux-nfs.org; linux-kernel@vger.kernel.org; steved@redhat.com;
dhowells@redhat.com; linux-next@vger.kernel.org;
linux-fsdevel@vger.kernel.org; rwheeler@redhat.com
Subject: RE: Pull request for FS-Cache, including NFS patches
On Tue, 2008-12-30 at 14:15 -0800, Muntz, Daniel wrote:
> >> As for security, look at what MIT had to do to prevent local disk
> >> caching from breaking the security guarantees of AFS.
> >
> >See what David has added to the LSM code to provide the same
> >guarantees
> for cachefs...
> >
> >Trond
>
> Unless it (at least) leverages TPM, the issues I had in mind can't
> really be addressed in code. One requirement is to prevent a local
> root user from accessing fs information without appropriate
permissions.
> This leads to unwieldly requirements such as allowing only one user on
> a machine at a time, blowing away the cache on logout, validating
> (e.g.,
> refreshing) the kernel on each boot, etc. Sure, some applications
> won't care, but you're also potentially opening holes that users may
> not consider.
You can't prevent a local root user from accessing cached data: that's
true with or without cachefs. root can typically access the data using
/dev/kmem, swap, intercepting tty traffic, spoofing user creds,...
If root can't be trusted, then find another machine.
The worry is rather that privileged daemons may be tricked into
revealing said data to unprivileged users, or that unprivileged users
may attempt to read data from files to which they have no rights using
the cachefs itself. That is a problem that is addressable by means of
LSM, and is what David has attempted to solve.
Trond
^ permalink raw reply
* Re: [ofa-general] Re: linux-next: origin tree build failure
From: Stephen Rothwell @ 2008-12-30 23:17 UTC (permalink / raw)
To: Roland Dreier; +Cc: linux-next, Linus, LKML, general
In-Reply-To: <adahc4ls262.fsf@cisco.com>
[-- Attachment #1.1: Type: text/plain, Size: 450 bytes --]
Hi Roland,
On Tue, 30 Dec 2008 14:56:05 -0800 Roland Dreier <rdreier@cisco.com> wrote:
>
> > So instead of the revert, I will cherry-pick your fix commit just after
> > Linus' tree today on the assumption that you will send it to him ASAP.
>
> Yes, I will batch up a few other things and send a pull request today.
Excellent!
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* RE: Pull request for FS-Cache, including NFS patches
From: Trond Myklebust @ 2008-12-30 23:17 UTC (permalink / raw)
To: Muntz, Daniel
Cc: Stephen Rothwell, Bernd Schubert, nfsv4, steved, linux-kernel,
dhowells, linux-next, linux-fsdevel, Andrew Morton, rwheeler
In-Reply-To: <7A24DF798E223B4C9864E8F92E8C93EC01AAFE6E@SACMVEXC1-PRD.hq.netapp.com>
On Tue, 2008-12-30 at 15:00 -0800, Muntz, Daniel wrote:
> Yes, and if you have a single user on the machine at a time (with cache
> flushed inbetween, kernel refreshed), root can read /dev/kmem, swap,
> intercept traffic and read cachefs data to its heart's content--hence,
> those requirements.
Unless you _are_ root and can check every executable, after presumably
rebooting into your own trusted kernel, then those requirements won't
mean squat. If you're that paranoid, then you will presumably also be
using a cryptfs-encrypted partition for cachefs, which you unmount when
you're not logged in.
That said, most cluster environments will tend to put most of their
security resources into keeping untrusted users out altogether. The
client nodes tend to be a homogeneous lot with presumably only a trusted
few sysadmins...
Trond
> -----Original Message-----
> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]
> Sent: Tuesday, December 30, 2008 2:36 PM
> To: Muntz, Daniel
> Cc: Andrew Morton; Stephen Rothwell; Bernd Schubert;
> nfsv4@linux-nfs.org; linux-kernel@vger.kernel.org; steved@redhat.com;
> dhowells@redhat.com; linux-next@vger.kernel.org;
> linux-fsdevel@vger.kernel.org; rwheeler@redhat.com
> Subject: RE: Pull request for FS-Cache, including NFS patches
>
> On Tue, 2008-12-30 at 14:15 -0800, Muntz, Daniel wrote:
> > >> As for security, look at what MIT had to do to prevent local disk
> > >> caching from breaking the security guarantees of AFS.
> > >
> > >See what David has added to the LSM code to provide the same
> > >guarantees
> > for cachefs...
> > >
> > >Trond
> >
> > Unless it (at least) leverages TPM, the issues I had in mind can't
> > really be addressed in code. One requirement is to prevent a local
> > root user from accessing fs information without appropriate
> permissions.
> > This leads to unwieldly requirements such as allowing only one user on
>
> > a machine at a time, blowing away the cache on logout, validating
> > (e.g.,
> > refreshing) the kernel on each boot, etc. Sure, some applications
> > won't care, but you're also potentially opening holes that users may
> > not consider.
>
> You can't prevent a local root user from accessing cached data: that's
> true with or without cachefs. root can typically access the data using
> /dev/kmem, swap, intercepting tty traffic, spoofing user creds,...
> If root can't be trusted, then find another machine.
>
> The worry is rather that privileged daemons may be tricked into
> revealing said data to unprivileged users, or that unprivileged users
> may attempt to read data from files to which they have no rights using
> the cachefs itself. That is a problem that is addressable by means of
> LSM, and is what David has attempted to solve.
>
> Trond
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: linux-next: manual merge of the sched tree
From: Stephen Rothwell @ 2008-12-30 23:45 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Paul E. McKenney,
Steven Rostedt
In-Reply-To: <20081222063501.GA29160@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 786 bytes --]
Hi Ingo,
On Mon, 22 Dec 2008 07:35:02 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > +#define nmi_enter() \
> > + do { \
> > + ftrace_nmi_enter(); \
> > + lockdep_off(); \
> > ++ rcu_nmi_enter(); \
> > + __irq_enter(); \
> > + } while (0)
> > +#define nmi_exit() \
> > + do { \
> > + __irq_exit(); \
> > ++ rcu_nmi_exit(); \
> > + lockdep_on(); \
> > + ftrace_nmi_exit(); \
> > + } while (0)
>
> yes, that's the same resolution i did for this conflict three days ago in
> tip/master. Thanks,
This conflict is now the sched tree and Linus' tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the device-mapper tree
From: Stephen Rothwell @ 2008-12-31 0:22 UTC (permalink / raw)
To: Alasdair G Kergon; +Cc: linux-next, Ingo Molnar, Kiyoshi Ueda
In-Reply-To: <20081215115823.dc3029d5.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
Hi Alasdair,
On Mon, 15 Dec 2008 11:58:23 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the device-mapper tree got a conflict in
> drivers/md/dm.c between commit 0bfc24559d7945506184d86739fe365a181f06b7
> ("blktrace: port to tracepoints, update") from the ftrace tree and commit
> 758cc022ae793c8418fca30ed1e30466efaae37a ("dm-request-add-caches") from
> the device-mapper tree.
>
> Just overlapping additions. I fixed it up (see below) and can carry the
> fix as necessary.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
> diff --cc drivers/md/dm.c
> index 343094c,50a1f10..0000000
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@@ -52,8 -53,27 +54,29 @@@ struct dm_target_io
> union map_info info;
> };
>
> + /*
> + * For request-based dm.
> + * One of these is allocated per request.
> + */
> + struct dm_rq_target_io {
> + struct mapped_device *md;
> + struct dm_target *ti;
> + struct request *orig, clone;
> + int error;
> + union map_info info;
> + };
> +
> + /*
> + * For request-based dm.
> + * One of these is allocated per bio.
> + */
> + struct dm_rq_clone_bio_info {
> + struct bio *orig;
> + struct request *rq;
> + };
> +
> +DEFINE_TRACE(block_bio_complete);
> +
> union map_info *dm_get_mapinfo(struct bio *bio)
> {
> if (bio && bio->bi_private)
This conflict is now between the device-mapper tree and Linus' tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the device-mapper tree
From: Alasdair G Kergon @ 2008-12-31 1:27 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Ingo Molnar, Kiyoshi Ueda
In-Reply-To: <20081231112249.4a0b68b2.sfr@canb.auug.org.au>
On Wed, Dec 31, 2008 at 11:22:49AM +1100, Stephen Rothwell wrote:
> This conflict is now between the device-mapper tree and Linus' tree.
Ta - I'll sort it when I rebase after the Xmas/New Year break.
Alasdair
--
agk@redhat.com
^ permalink raw reply
* Re: linux-next: manual merge of the security-testing tree
From: Stephen Rothwell @ 2008-12-31 1:50 UTC (permalink / raw)
To: Mark Fasheh; +Cc: linux-next, David Howells, Tiger Yang, James Morris, Jan Kara
In-Reply-To: <20081120163734.9e5f0d61.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]
Hi Mark,
On Thu, 20 Nov 2008 16:37:34 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the security-testing tree got a conflict in
> fs/ocfs2/namei.c between commit 8b50970dda2c81dfbd120ae650fcf5439f268f37
> ("[PATCH 01/10] ocfs2: move new inode allocation out of the transaction")
> from the ocsf2 tree and commit b19c2a3b839b9dfb3f258e8943dc3784ae20c7b0
> ("CRED: Wrap task credential accesses in the OCFS2 filesystem") from the
> security-testing tree.
>
> I fixed it up (see below) and can carry it. The ocfs2 tree change moved
> the place where the security-testing tree change to this file needs to be
> made. The below patch could be applied to the ocfs2 tree (as part of the
> above security-testing patch as all its dependencies are already upstream.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
> diff --cc fs/ocfs2/namei.c
> index 98fd325,2545e74..0000000
> --- a/fs/ocfs2/namei.c
> +++ b/fs/ocfs2/namei.c
> @@@ -187,34 -186,6 +187,34 @@@ bail
> return ret;
> }
>
> +static struct inode *ocfs2_get_init_inode(struct inode *dir, int mode)
> +{
> + struct inode *inode;
> +
> + inode = new_inode(dir->i_sb);
> + if (!inode) {
> + mlog(ML_ERROR, "new_inode failed!\n");
> + return NULL;
> + }
> +
> + /* populate as many fields early on as possible - many of
> + * these are used by the support functions here and in
> + * callers. */
> + if (S_ISDIR(mode))
> + inode->i_nlink = 2;
> + else
> + inode->i_nlink = 1;
> - inode->i_uid = current->fsuid;
> ++ inode->i_uid = current_fsuid();
> + if (dir->i_mode & S_ISGID) {
> + inode->i_gid = dir->i_gid;
> + if (S_ISDIR(mode))
> + mode |= S_ISGID;
> + } else
> - inode->i_gid = current->fsgid;
> ++ inode->i_gid = current_fsgid();
> + inode->i_mode = mode;
> + return inode;
> +}
> +
> static int ocfs2_mknod(struct inode *dir,
> struct dentry *dentry,
> int mode,
This conflict is now between the ocfs2 tree and Linus' tree (the
security-testing tree beat you to being merged :-)).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [patch] powerpc: change u64/s64 to a long long integer type
From: Stephen Rothwell @ 2008-12-31 4:40 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, Ken Chen, Paul Mackerras, Thomas Gleixner,
H. Peter Anvin, linux-next
In-Reply-To: <20081222080341.GA18897@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 4180 bytes --]
Hi Ingo,
On Mon, 22 Dec 2008 09:03:41 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> Subject: powerpc: change u64/s64 to a long long integer type
> From: Ingo Molnar <mingo@elte.hu>
> Date: Mon Dec 22 08:32:41 CET 2008
>
> Convert arch/powerpc/ over to long long based u64:
>
> -#ifdef __powerpc64__
> -# include <asm-generic/int-l64.h>
> -#else
> -# include <asm-generic/int-ll64.h>
> -#endif
> +#include <asm-generic/int-ll64.h>
>
> This will avoid reoccuring spurious warnings in core kernel code that
> comes when people test on their own hardware. (i.e. x86 in ~98% of the
> cases) This is what x86 uses and it generally helps keep 64-bit code
> 32-bit clean too.
Thanks for this great start. Just a few comments ...
Firstly, it would be nice if we could split this into things we can do
now (e.g. logical bug fixes) and things that must be done at the time of
the u64 type change (e.g. the printk's etc). That will make the second
patch hopefully somewhat smaller.
> Index: linux/arch/powerpc/kernel/prom.c
> ===================================================================
> --- linux.orig/arch/powerpc/kernel/prom.c
> +++ linux/arch/powerpc/kernel/prom.c
> @@ -824,11 +824,11 @@ static int __init early_init_dt_scan_cho
> #endif
>
> #ifdef CONFIG_KEXEC
> - lprop = (u64*)of_get_flat_dt_prop(node, "linux,crashkernel-base", NULL);
> + lprop = (unsigned long *)of_get_flat_dt_prop(node, "linux,crashkernel-base", NULL);
> if (lprop)
> crashk_res.start = *lprop;
>
> - lprop = (u64*)of_get_flat_dt_prop(node, "linux,crashkernel-size", NULL);
> + lprop = (unsigned long *)of_get_flat_dt_prop(node, "linux,crashkernel-size", NULL);
These casts are actually not needed at all as of_get_flat_dt_prop()
returns "void *".
> Index: linux/arch/powerpc/oprofile/cell/vma_map.c
> ===================================================================
> --- linux.orig/arch/powerpc/oprofile/cell/vma_map.c
> +++ linux/arch/powerpc/oprofile/cell/vma_map.c
> @@ -92,7 +92,7 @@ vma_map_add(struct vma_to_fileoffset_map
> * A pointer to the first vma_map in the generated list
> * of vma_maps is returned. */
> struct vma_to_fileoffset_map *create_vma_map(const struct spu *aSpu,
> - unsigned long __spu_elf_start)
> + u64 __spu_elf_start)
Wouldn't it make more sense to change the prototype to match the
implementation and the only caller (which passes an "unsigned long")?
> Index: linux/arch/powerpc/platforms/cell/interrupt.c
> ===================================================================
> --- linux.orig/arch/powerpc/platforms/cell/interrupt.c
> +++ linux/arch/powerpc/platforms/cell/interrupt.c
> @@ -148,7 +148,7 @@ static unsigned int iic_get_irq(void)
>
> iic = &__get_cpu_var(iic);
> *(unsigned long *) &pending =
> - in_be64((unsigned long __iomem *) &iic->regs->pending_destr);
> + in_be64((unsigned long long __iomem *) &iic->regs->pending_destr);
in_be64()'s argument is "const volatile u64 __iomem *" so the
original "unsigned long" should have been "u64".
> Index: linux/arch/powerpc/platforms/cell/spu_base.c
> ===================================================================
> --- linux.orig/arch/powerpc/platforms/cell/spu_base.c
> +++ linux/arch/powerpc/platforms/cell/spu_base.c
> @@ -139,10 +139,10 @@ static void spu_restart_dma(struct spu *
> {
> struct spu_priv2 __iomem *priv2 = spu->priv2;
>
> - if (!test_bit(SPU_CONTEXT_SWITCH_PENDING, &spu->flags))
> + if (!test_bit(SPU_CONTEXT_SWITCH_PENDING, (unsigned long *)&spu->flags))
> out_be64(&priv2->mfc_control_RW, MFC_CNTL_RESTART_DMA_COMMAND);
> else {
> - set_bit(SPU_CONTEXT_FAULT_PENDING, &spu->flags);
> + set_bit(SPU_CONTEXT_FAULT_PENDING, (unsigned long *)&spu->flags);
I have submitted a different patch for this. The bitops work on unsigned
longs, so I changed the "flags" to be unsigned long.
So, would you like me to push this along - including splitting it up a
bit (keeping your Signed-off-by, of course)?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [patch] powerpc: change u64/s64 to a long long integer type
From: Ingo Molnar @ 2008-12-31 7:52 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel, Ken Chen, Paul Mackerras, Thomas Gleixner,
H. Peter Anvin, linux-next
In-Reply-To: <20081231154027.457d9197.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> So, would you like me to push this along - including splitting it up a
> bit (keeping your Signed-off-by, of course)?
Sure, feel free - this should really be done by someone with more PowerPC
interest/experience than me.
Ingo
^ permalink raw reply
* Re: Pull request for FS-Cache, including NFS patches
From: Arjan van de Ven @ 2008-12-31 9:49 UTC (permalink / raw)
To: Muntz, Daniel
Cc: Trond Myklebust, Andrew Morton, Stephen Rothwell, Bernd Schubert,
nfsv4, linux-kernel, steved, dhowells, linux-next, linux-fsdevel,
rwheeler
In-Reply-To: <7A24DF798E223B4C9864E8F92E8C93EC01AAFE66@SACMVEXC1-PRD.hq.netapp.com>
On Tue, 30 Dec 2008 14:15:42 -0800
"Muntz, Daniel" <Dan.Muntz@netapp.com> wrote:
> >> As for security, look at what MIT had to do to prevent local disk
> >> caching from breaking the security guarantees of AFS.
> >
> >See what David has added to the LSM code to provide the same
> >guarantees
> for cachefs...
> >
> >Trond
>
> Unless it (at least) leverages TPM, the issues I had in mind can't
> really be addressed in code. One requirement is to prevent a local
> root user from accessing fs information without appropriate
> permissions.
we're talking about NFS here (but also local CDs and potentially CIFS
etc). The level of security you're talking about is going to be the
same before or after cachefs.... very little against local root.
Frankly, any networking filesystem just trusts that the connection is
authenticated... eg there is SOMEONE on the machine who has the right
credentials.
Cachefs doesn't change that; it still validates with the server before
giving userspace the data.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* Re: linux-next: timers tree build failure
From: Takashi Iwai @ 2008-12-31 10:43 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next
In-Reply-To: <20081229093125.GA27293@elte.hu>
At Mon, 29 Dec 2008 10:31:25 +0100,
Ingo Molnar wrote:
>
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > sound/core/hrtimer.c: In function 'snd_hrtimer_open':
> > sound/core/hrtimer.c:60: error: 'struct hrtimer' has no member named 'cb_mode'
> > sound/core/hrtimer.c:60: error: 'HRTIMER_CB_IRQSAFE_UNLOCKED' undeclared (first use in this function)
> >
> > See below ... the sound tree changes are now in Linus' tree, so this
> > needs fixing before the timers tree gets merged.
> >
> > I have applied the merge fix below (which is also in the sound tree) to
> > the timers tree for today.
>
> yes, trivial oneliner conflict, i pushed out a new auto-timers-next tree.
Sorry for late jump-in, as I'm just back from vacation.
The for-next branch of sound.git already includes the fix patch (based
on tip/timers/hrtimers), so I wonder why a conflict occurred... Is it
a conflict fix or is your hrtimers branch rebased?
thanks,
Takashi
^ permalink raw reply
* Re: linux-next: timers tree build failure
From: Takashi Iwai @ 2008-12-31 10:57 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next
In-Reply-To: <s5h7i5gtyki.wl%tiwai@suse.de>
At Wed, 31 Dec 2008 11:43:09 +0100,
I wrote:
>
> At Mon, 29 Dec 2008 10:31:25 +0100,
> Ingo Molnar wrote:
> >
> >
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Hi all,
> > >
> > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > >
> > > sound/core/hrtimer.c: In function 'snd_hrtimer_open':
> > > sound/core/hrtimer.c:60: error: 'struct hrtimer' has no member named 'cb_mode'
> > > sound/core/hrtimer.c:60: error: 'HRTIMER_CB_IRQSAFE_UNLOCKED' undeclared (first use in this function)
> > >
> > > See below ... the sound tree changes are now in Linus' tree, so this
> > > needs fixing before the timers tree gets merged.
> > >
> > > I have applied the merge fix below (which is also in the sound tree) to
> > > the timers tree for today.
> >
> > yes, trivial oneliner conflict, i pushed out a new auto-timers-next tree.
>
> Sorry for late jump-in, as I'm just back from vacation.
>
> The for-next branch of sound.git already includes the fix patch (based
> on tip/timers/hrtimers), so I wonder why a conflict occurred... Is it
> a conflict fix or is your hrtimers branch rebased?
Never mind, I found that Linus already pulled your fix.
Now I'll fix for-next branch on sound.git tree.
thanks,
Takashi
^ permalink raw reply
* Re: linux-next: Tree for December 30
From: Geert Uytterhoeven @ 2008-12-31 11:02 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20081231033039.f203b59c.sfr@canb.auug.org.au>
On Wed, 31 Dec 2008, Stephen Rothwell wrote:
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
The website doesn't seem to have been updated during the last few days?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Pull request for FS-Cache, including NFS patches
From: David Howells @ 2008-12-31 11:15 UTC (permalink / raw)
To: Trond Myklebust
Cc: dhowells, Muntz, Daniel, Andrew Morton, Stephen Rothwell,
Bernd Schubert, nfsv4, linux-kernel, steved, linux-next,
linux-fsdevel, rwheeler
In-Reply-To: <1230679056.11508.37.camel@heimdal.trondhjem.org>
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> Unless you _are_ root and can check every executable, after presumably
> rebooting into your own trusted kernel, then those requirements won't
> mean squat. If you're that paranoid, then you will presumably also be
> using a cryptfs-encrypted partition for cachefs, which you unmount when
> you're not logged in.
Actually... Cachefiles could fairly trivially add encryption. It would have
to be simple encryption but you wouldn't have to store any keys locally.
Currently cachefiles _copies_ data between the backingfs and the netfs pages
because the direct-IO code is only usable to/from userspace. Rather than
copying, encrypt/decrypt could be called.
A key could be constructed at the point a cache file is looked up. It could
be constructed from the coherency data. In the case of NFS that would be
mtime, ctime, isize and change_attr. The coherency data would be encrypted
with this key and then stored on disk, as would the contents of the file.
It might be possible to chuck the cache key (NFS fh) into the encryption key
too and also encrypt the cache key before it is turned into a filename, though
we'd have to be careful to avoid collisions if each filename is encrypted with
a different key.
We'd probably have to be careful about the coherency data decrypting with a
different key showing up as the wrong but valid thing.
The nice thing about this is that the key need not be retained locally since
it's entirely constructed from data fetched from the netfs.
David
^ permalink raw reply
* [BUILD-FAILURE] next-20081230 - S390 - tape drive fails to build with !CONFIG_BLOCK
From: Kamalesh Babulal @ 2008-12-31 11:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, linux-s390, schwidefsky, heiko.carstens
In-Reply-To: <20081231033039.f203b59c.sfr@canb.auug.org.au>
Hi,
next-20081230 randconfig build fails on S390, with CONFIG_BLOCK=n
CC drivers/s390/char/tape_block.o
In file included from drivers/s390/char/tape_block.c:24:
drivers/s390/char/tape.h:159: warning: 'struct request' declared inside parameter list
drivers/s390/char/tape.h:159: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/s390/char/tape_block.c:53: error: variable 'tapeblock_fops' has initializer but incomplete type
drivers/s390/char/tape_block.c:54: error: unknown field 'owner' specified in initializer
drivers/s390/char/tape_block.c:54: warning: excess elements in struct initializer
drivers/s390/char/tape_block.c:54: warning: (near initialization for 'tapeblock_fops')
drivers/s390/char/tape_block.c:55: error: unknown field 'open' specified in initializer
drivers/s390/char/tape_block.c:55: warning: excess elements in struct initializer
drivers/s390/char/tape_block.c:55: warning: (near initialization for 'tapeblock_fops')
drivers/s390/char/tape_block.c:56: error: unknown field 'release' specified in initializer
drivers/s390/char/tape_block.c:56: warning: excess elements in struct initializer
drivers/s390/char/tape_block.c:56: warning: (near initialization for 'tapeblock_fops')
drivers/s390/char/tape_block.c:57: error: unknown field 'locked_ioctl' specified in initializer
drivers/s390/char/tape_block.c:57: warning: excess elements in struct initializer
drivers/s390/char/tape_block.c:57: warning: (near initialization for 'tapeblock_fops')
drivers/s390/char/tape_block.c:58: error: unknown field 'media_changed' specified in initializer
drivers/s390/char/tape_block.c:58: warning: excess elements in struct initializer
drivers/s390/char/tape_block.c:58: warning: (near initialization for 'tapeblock_fops')
drivers/s390/char/tape_block.c:59: error: unknown field 'revalidate_disk' specified in initializer
drivers/s390/char/tape_block.c:59: warning: excess elements in struct initializer
drivers/s390/char/tape_block.c:59: warning: (near initialization for 'tapeblock_fops')
drivers/s390/char/tape_block.c:77: warning: 'struct request' declared inside parameter list
drivers/s390/char/tape_block.c: In function 'tapeblock_end_request':
drivers/s390/char/tape_block.c:79: error: implicit declaration of function 'blk_end_request'
drivers/s390/char/tape_block.c:79: error: implicit declaration of function 'blk_rq_bytes'
drivers/s390/char/tape_block.c: In function '__tapeblock_end_request':
drivers/s390/char/tape_block.c:93: warning: passing argument 1 of 'tapeblock_end_request' from incompatible pointer type
drivers/s390/char/tape_block.c:97: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:97: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:103: error: implicit declaration of function 'elv_next_request'
drivers/s390/char/tape_block.c: At top level:
drivers/s390/char/tape_block.c:111: warning: 'struct request' declared inside parameter list
drivers/s390/char/tape_block.c: In function 'tapeblock_start_request':
drivers/s390/char/tape_block.c:118: warning: passing argument 2 of 'device->discipline->bread' from incompatible pointer type
drivers/s390/char/tape_block.c:121: warning: passing argument 1 of 'tapeblock_end_request' from incompatible pointer type
drivers/s390/char/tape_block.c:134: warning: passing argument 1 of 'tapeblock_end_request' from incompatible pointer type
drivers/s390/char/tape_block.c: In function 'tapeblock_requeue':
drivers/s390/char/tape_block.c:171: error: implicit declaration of function 'blk_queue_plugged'
drivers/s390/char/tape_block.c:175: warning: assignment makes pointer from integer without a cast
drivers/s390/char/tape_block.c:176: error: implicit declaration of function 'rq_data_dir'
drivers/s390/char/tape_block.c:178: error: implicit declaration of function 'blkdev_dequeue_request'
drivers/s390/char/tape_block.c:180: warning: passing argument 1 of 'tapeblock_end_request' from incompatible pointer type
drivers/s390/char/tape_block.c:187: warning: passing argument 2 of 'tapeblock_start_request' from incompatible pointer type
drivers/s390/char/tape_block.c: In function 'tapeblock_request_fn':
drivers/s390/char/tape_block.c:202: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c: In function 'tapeblock_setup_device':
drivers/s390/char/tape_block.c:223: error: implicit declaration of function 'blk_init_queue'
drivers/s390/char/tape_block.c:226: warning: assignment makes pointer from integer without a cast
drivers/s390/char/tape_block.c:230: error: implicit declaration of function 'elevator_exit'
drivers/s390/char/tape_block.c:230: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:231: error: implicit declaration of function 'elevator_init'
drivers/s390/char/tape_block.c:235: error: implicit declaration of function 'blk_queue_hardsect_size'
drivers/s390/char/tape_block.c:236: error: implicit declaration of function 'blk_queue_max_sectors'
drivers/s390/char/tape_block.c:237: error: implicit declaration of function 'blk_queue_max_phys_segments'
drivers/s390/char/tape_block.c:238: error: implicit declaration of function 'blk_queue_max_hw_segments'
drivers/s390/char/tape_block.c:239: error: implicit declaration of function 'blk_queue_max_segment_size'
drivers/s390/char/tape_block.c:240: error: implicit declaration of function 'blk_queue_segment_boundary'
drivers/s390/char/tape_block.c:242: error: implicit declaration of function 'alloc_disk'
drivers/s390/char/tape_block.c:242: warning: assignment makes pointer from integer without a cast
drivers/s390/char/tape_block.c:248: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:249: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:250: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:251: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:252: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:253: error: implicit declaration of function 'set_capacity'
drivers/s390/char/tape_block.c:254: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:259: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:261: error: implicit declaration of function 'add_disk'
drivers/s390/char/tape_block.c:269: error: implicit declaration of function 'blk_cleanup_queue'
drivers/s390/char/tape_block.c: In function 'tapeblock_cleanup_device':
drivers/s390/char/tape_block.c:287: error: implicit declaration of function 'del_gendisk'
drivers/s390/char/tape_block.c:288: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:289: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c:290: error: implicit declaration of function 'put_disk'
drivers/s390/char/tape_block.c:294: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c: In function 'tapeblock_revalidate_disk':
drivers/s390/char/tape_block.c:311: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c: In function 'tapeblock_medium_changed':
drivers/s390/char/tape_block.c:358: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c: In function 'tapeblock_open':
drivers/s390/char/tape_block.c:375: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c: In function 'tapeblock_release':
drivers/s390/char/tape_block.c:416: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c: In function 'tapeblock_ioctl':
drivers/s390/char/tape_block.c:442: error: dereferencing pointer to incomplete type
drivers/s390/char/tape_block.c: In function 'tapeblock_init':
drivers/s390/char/tape_block.c:471: error: implicit declaration of function 'register_blkdev'
drivers/s390/char/tape_block.c: In function 'tapeblock_exit':
drivers/s390/char/tape_block.c:487: error: implicit declaration of function 'unregister_blkdev'
make[2]: *** [drivers/s390/char/tape_block.o] Error 1
Adding the dependency of CONFIG_BLOCK to CONFIG_S390_TAPE_BLOCK
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com
--
drivers/s390/char/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/s390/char/Kconfig b/drivers/s390/char/Kconfig
old mode 100644
new mode 100755
index 6430338..0769ced
--- a/drivers/s390/char/Kconfig
+++ b/drivers/s390/char/Kconfig
@@ -100,7 +100,7 @@ comment "S/390 tape interface support"
config S390_TAPE_BLOCK
bool "Support for tape block devices"
- depends on S390_TAPE
+ depends on S390_TAPE && BLOCK
help
Select this option if you want to access your channel-attached tape
devices using the block device interface. This interface is similar
--
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.28-next-20081230
# Wed Dec 31 04:35:58 2008
#
CONFIG_SCHED_MC=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_NO_IOMEM=y
CONFIG_NO_DMA=y
CONFIG_PGSTE=y
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_S390=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
# CONFIG_TASK_DELAY_ACCT is not set
# CONFIG_TASK_XACCT is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=m
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CGROUP_DEVICE=y
# CONFIG_CPUSETS is not set
# CONFIG_GROUP_SCHED is not set
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_MM_OWNER=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
CONFIG_PID_NS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_STRIP_GENERATED=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
# CONFIG_HOTPLUG is not set
CONFIG_PRINTK=y
# CONFIG_BUG is not set
CONFIG_ELF_CORE=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
# CONFIG_FUTEX is not set
CONFIG_ANON_INODES=y
# CONFIG_EPOLL is not set
CONFIG_SIGNALFD=y
# CONFIG_TIMERFD is not set
# CONFIG_EVENTFD is not set
# CONFIG_SHMEM is not set
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_MARKERS=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_TINY_SHMEM=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
# CONFIG_MODULE_UNLOAD is not set
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_INIT_ALL_POSSIBLE=y
# CONFIG_BLOCK is not set
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_CLASSIC_RCU=y
# CONFIG_TREE_RCU is not set
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_PREEMPT_RCU_TRACE is not set
# CONFIG_FREEZER is not set
#
# Base setup
#
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_64BIT=y
CONFIG_SMP=y
CONFIG_NR_CPUS=64
# CONFIG_HOTPLUG_CPU is not set
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_AUDIT_ARCH=y
CONFIG_S390_SWITCH_AMODE=y
# CONFIG_S390_EXEC_PROTECT is not set
#
# Code generation options
#
# CONFIG_MARCH_G5 is not set
CONFIG_MARCH_Z900=y
# CONFIG_MARCH_Z990 is not set
# CONFIG_MARCH_Z9_109 is not set
# CONFIG_MARCH_Z10 is not set
# CONFIG_PACK_STACK is not set
CONFIG_CHECK_STACK=y
CONFIG_STACK_GUARD=256
CONFIG_WARN_STACK=y
CONFIG_WARN_STACK_SIZE=2048
CONFIG_ARCH_POPULATES_NODE_MAP=y
#
# Kernel preemption
#
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
CONFIG_RESOURCES_64BIT=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_VIRT_TO_BUS=y
CONFIG_UNEVICTABLE_LRU=y
#
# I/O subsystem configuration
#
# CONFIG_MACHCHK_WARNING is not set
CONFIG_QDIO=m
# CONFIG_CHSC_SCH is not set
#
# Misc
#
CONFIG_IPL=y
# CONFIG_IPL_TAPE is not set
CONFIG_IPL_VM=y
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_FORCE_MAX_ZONEORDER=9
# CONFIG_PROCESS_DEBUG is not set
CONFIG_PFAULT=y
# CONFIG_SHARED_KERNEL is not set
# CONFIG_CMM is not set
CONFIG_PAGE_STATES=y
# CONFIG_APPLDATA_BASE is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_SCHED_HRTICK is not set
CONFIG_S390_HYPFS_FS=y
CONFIG_KEXEC=y
CONFIG_ZFCPDUMP=y
# CONFIG_S390_GUEST is not set
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NET_NS is not set
CONFIG_COMPAT_NET_DEV_OPS=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=m
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=y
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_IUCV=y
# CONFIG_AFIUCV is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
# CONFIG_INET_ESP is not set
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y
# CONFIG_TCP_CONG_CUBIC is not set
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=y
# CONFIG_TCP_CONG_HSTCP is not set
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=y
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=y
CONFIG_TCP_CONG_YEAH=y
CONFIG_TCP_CONG_ILLINOIS=m
CONFIG_DEFAULT_BIC=y
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="bic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
# CONFIG_INET6_AH is not set
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=y
CONFIG_INET6_TUNNEL=y
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
CONFIG_NETWORK_SECMARK=y
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=m
CONFIG_SCTP_DBG_MSG=y
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_TIPC is not set
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
# CONFIG_ATM_BR2684 is not set
CONFIG_STP=y
CONFIG_GARP=y
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=y
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_DECNET=y
CONFIG_DECNET_ROUTER=y
CONFIG_LLC=y
CONFIG_LLC2=m
CONFIG_IPX=y
CONFIG_IPX_INTERN=y
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
CONFIG_LAPB=m
CONFIG_ECONET=m
CONFIG_ECONET_AUNUDP=y
CONFIG_ECONET_NATIVE=y
CONFIG_WAN_ROUTER=m
CONFIG_NET_SCHED=y
#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
# CONFIG_NET_SCH_ATM is not set
# CONFIG_NET_SCH_PRIO is not set
CONFIG_NET_SCH_MULTIQ=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=m
# CONFIG_NET_SCH_TEQL is not set
CONFIG_NET_SCH_TBF=y
# CONFIG_NET_SCH_GRED is not set
CONFIG_NET_SCH_DSMARK=y
CONFIG_NET_SCH_NETEM=y
# CONFIG_NET_SCH_DRR is not set
CONFIG_NET_SCH_INGRESS=m
#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
# CONFIG_NET_CLS_TCINDEX is not set
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_CLS_U32_MARK is not set
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_FLOW=y
# CONFIG_NET_CLS_CGROUP is not set
# CONFIG_NET_EMATCH is not set
CONFIG_NET_CLS_ACT=y
# CONFIG_NET_ACT_POLICE is not set
CONFIG_NET_ACT_GACT=y
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=y
CONFIG_NET_ACT_NAT=y
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
CONFIG_NET_ACT_SKBEDIT=m
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set
#
# Network testing
#
CONFIG_NET_PKTGEN=y
# CONFIG_NET_TCPPROBE is not set
CONFIG_CAN=m
CONFIG_CAN_RAW=m
CONFIG_CAN_BCM=m
#
# CAN Device Drivers
#
# CONFIG_CAN_VCAN is not set
# CONFIG_CAN_DEBUG_DEVICES is not set
CONFIG_AF_RXRPC=m
CONFIG_AF_RXRPC_DEBUG=y
CONFIG_RXKAD=m
CONFIG_PHONET=m
CONFIG_FIB_RULES=y
CONFIG_RFKILL=m
CONFIG_NET_9P=y
CONFIG_NET_9P_DEBUG=y
# CONFIG_PCMCIA is not set
CONFIG_CCW=y
#
# Device Drivers
#
#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_DEBUG_DRIVER=y
CONFIG_DEBUG_DEVRES=y
CONFIG_SYS_HYPERVISOR=y
CONFIG_CONNECTOR=m
CONFIG_MISC_DEVICES=y
CONFIG_EEPROM_93CX6=y
CONFIG_ENCLOSURE_SERVICES=m
CONFIG_C2PORT=m
#
# SCSI device support
#
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_NETDEVICES=y
CONFIG_IFB=m
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
CONFIG_MACVLAN=y
CONFIG_EQUALIZER=m
CONFIG_TUN=m
# CONFIG_VETH is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
# CONFIG_NETDEV_1000 is not set
CONFIG_NETDEV_10000=y
CONFIG_TR=y
CONFIG_WAN=y
CONFIG_HDLC=m
CONFIG_HDLC_RAW=m
# CONFIG_HDLC_RAW_ETH is not set
CONFIG_HDLC_CISCO=m
# CONFIG_HDLC_FR is not set
CONFIG_HDLC_PPP=m
# CONFIG_HDLC_X25 is not set
# CONFIG_DLCI is not set
CONFIG_WAN_ROUTER_DRIVERS=m
CONFIG_ATM_DRIVERS=y
CONFIG_ATM_DUMMY=m
CONFIG_ATM_TCP=m
#
# S/390 network device drivers
#
CONFIG_LCS=m
CONFIG_CTCM=y
CONFIG_NETIUCV=m
# CONFIG_SMSGIUCV is not set
CONFIG_CLAW=y
CONFIG_QETH=m
CONFIG_QETH_L2=m
CONFIG_QETH_L3=m
CONFIG_QETH_IPV6=y
CONFIG_CCWGROUP=y
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# Character devices
#
CONFIG_DEVKMEM=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IUCV=y
CONFIG_HW_RANDOM=m
# CONFIG_R3964 is not set
# CONFIG_HANGCHECK_TIMER is not set
#
# S/390 character device drivers
#
# CONFIG_TN3270 is not set
CONFIG_TN3215=y
# CONFIG_TN3215_CONSOLE is not set
CONFIG_SCLP_TTY=y
CONFIG_SCLP_CONSOLE=y
CONFIG_SCLP_VT220_TTY=y
CONFIG_SCLP_VT220_CONSOLE=y
# CONFIG_SCLP_CPI is not set
CONFIG_S390_TAPE=y
#
# S/390 tape interface support
#
#
# S/390 tape hardware support
#
# CONFIG_S390_TAPE_34XX is not set
CONFIG_S390_TAPE_3590=m
CONFIG_VMLOGRDR=m
# CONFIG_VMCP is not set
CONFIG_MONREADER=m
# CONFIG_MONWRITER is not set
CONFIG_S390_VMUR=y
# CONFIG_POWER_SUPPLY is not set
# CONFIG_THERMAL is not set
CONFIG_THERMAL_HWMON=y
# CONFIG_WATCHDOG is not set
# CONFIG_REGULATOR is not set
CONFIG_MEMSTICK=y
# CONFIG_MEMSTICK_DEBUG is not set
#
# MemoryStick drivers
#
CONFIG_MEMSTICK_UNSAFE_RESUME=y
#
# MemoryStick Host Controller Drivers
#
# CONFIG_NEW_LEDS is not set
CONFIG_ACCESSIBILITY=y
CONFIG_STAGING=y
# CONFIG_STAGING_EXCLUDE_BUILD is not set
CONFIG_ECHO=y
#
# File systems
#
CONFIG_FS_POSIX_ACL=y
CONFIG_DNOTIFY=y
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=y
CONFIG_GENERIC_ACL=y
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
# CONFIG_PROC_SYSCTL is not set
# CONFIG_PROC_PAGE_MONITOR is not set
# CONFIG_SYSFS is not set
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
#
# Miscellaneous filesystems
#
# CONFIG_ECRYPT_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set
# CONFIG_NLS is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_KERNEL=y
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_OBJECTS=y
# CONFIG_DEBUG_OBJECTS_SELFTEST is not set
# CONFIG_DEBUG_OBJECTS_FREE is not set
CONFIG_DEBUG_OBJECTS_TIMERS=y
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
CONFIG_DEBUG_KOBJECT=y
# CONFIG_DEBUG_INFO is not set
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_WRITECOUNT=y
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
CONFIG_DEBUG_SG=y
# CONFIG_DEBUG_NOTIFIERS is not set
CONFIG_FRAME_POINTER=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_DETECTOR=y
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
CONFIG_FAULT_INJECTION=y
CONFIG_FAILSLAB=y
CONFIG_FAIL_PAGE_ALLOC=y
CONFIG_LATENCYTOP=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_RING_BUFFER=y
CONFIG_TRACING=y
#
# Tracers
#
# CONFIG_FUNCTION_TRACER is not set
CONFIG_IRQSOFF_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_BOOT_TRACER=y
# CONFIG_TRACE_BRANCH_PROFILING is not set
# CONFIG_STACK_TRACER is not set
CONFIG_BUILD_DOCSRC=y
CONFIG_DYNAMIC_PRINTK_DEBUG=y
CONFIG_SAMPLES=y
CONFIG_SAMPLE_MARKERS=m
CONFIG_SAMPLE_TRACEPOINTS=m
# CONFIG_SAMPLE_KOBJECT is not set
# CONFIG_SAMPLE_KPROBES is not set
CONFIG_DEBUG_PAGEALLOC=y
#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
CONFIG_SECURITYFS=y
CONFIG_SECURITY_FILE_CAPABILITIES=y
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_CRYPTD=y
CONFIG_CRYPTO_AUTHENC=y
CONFIG_CRYPTO_TEST=m
#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=y
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=y
#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_LRW=y
CONFIG_CRYPTO_PCBC=y
CONFIG_CRYPTO_XTS=y
#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=y
#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=y
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=y
CONFIG_CRYPTO_SALSA20=y
CONFIG_CRYPTO_SEED=y
CONFIG_CRYPTO_SERPENT=m
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_LZO=m
#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_HW=y
CONFIG_ZCRYPT=m
# CONFIG_ZCRYPT_MONOLITHIC is not set
CONFIG_CRYPTO_SHA1_S390=y
CONFIG_CRYPTO_SHA256_S390=y
CONFIG_CRYPTO_SHA512_S390=m
# CONFIG_CRYPTO_DES_S390 is not set
CONFIG_CRYPTO_AES_S390=y
CONFIG_S390_PRNG=m
#
# Library routines
#
CONFIG_BITREVERSE=m
CONFIG_GENERIC_FIND_LAST_BIT=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=m
CONFIG_CRC7=m
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=y
# CONFIG_VIRTIO_BALLOON is not set
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply related
* linux-next: Tree for December 31
From: Stephen Rothwell @ 2008-12-31 13:32 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8737 bytes --]
Hi all,
Changes since 20081230:
Dropped trees (temporarily):
driver-core (build problem)
usb (depends on driver-core)
kvm (build problem)
semaphore-removal (due to unfixed conflicts against Linus' tree)
cpu_alloc (build problem)
audit (difficult conflicts)
staging (depends on usb)
I substituted a fix commit from the infiniband tree for the revert build
fix for Linus' tree.
The xfs tree lost its 4 conflicts.
The scsi tree lost its build failure.
The firmware tree lost 3 conflicts (because the conflicting commits were
removed from the scsi tree).
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig,
44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and
i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 132 trees (counting Linus' and 15 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
CONFLICT (content): Merge conflict in drivers/char/tty_audit.c
Created commit 309ba8e: Merge commit 'audit-current/for-linus'
Merging dwmw2/master
$ git cherry-pick 2c4ab6243f91cda62f22af2eb8a6c07590de37b1
Created commit 7c453f0: RDMA/addr: Fix build breakage when IPv6 is disabled
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging tip-core/auto-core-next
CONFLICT (content): Merge conflict in include/linux/hardirq.h
Created commit 6620d2d: Merge commit 'tip-core/auto-core-next'
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
CONFLICT (content): Merge conflict in kernel/time/tick-sched.c
Created commit b665237: Merge commit 'timers/auto-timers-next'
Merging pci/linux-next
Merging quilt/device-mapper
CONFLICT (content): Merge conflict in drivers/md/dm.c
Created commit 7afc9a5: Merge branch 'quilt/device-mapper'
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
CONFLICT (content): Merge conflict in fs/lockd/host.c
CONFLICT (content): Merge conflict in fs/lockd/mon.c
Created commit ff8ad19: Merge commit 'nfsd/nfsd-next'
Merging ieee1394/for-next
Merging ubi/linux-next
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
CONFLICT (content): Merge conflict in fs/ocfs2/namei.c
Created commit 41d1404: Merge commit 'ocfs2/linux-next'
Merging ext4/next
Merging async_tx/next
Applying: net: async_tx merge fix
Created commit 74129d6: Merge commit 'async_tx/next'
Merging udf/for_next
Merging net/master
Merging mtd/master
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/corgi.c
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/poodle.c
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/spitz.c
Created commit 8b5bb2a: Merge commit 'mtd/master'
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
Merging v9fs/for-next
Merging rr_cpumask/master
CONFLICT (content): Merge conflict in kernel/sched.c
Created commit 1653d97: Merge commit 'rr_cpumask/master'
Merging quilt/rr
CONFLICT (content): Merge conflict in kernel/rcuclassic.c
Created commit a788be2: Merge branch 'quilt/rr'
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging bkl-removal/bkl-removal
CONFLICT (content): Merge conflict in fs/ioctl.c
Created commit 28240e8: Merge commit 'bkl-removal/bkl-removal'
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/net/tg3.c
CONFLICT (content): Merge conflict in firmware/Makefile
CONFLICT (content): Merge conflict in firmware/WHENCE
Created commit b64483f: Merge commit 'firmware/master'
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in arch/x86/mm/Makefile
CONFLICT (content): Merge conflict in mm/Makefile
CONFLICT (content): Merge conflict in mm/slub.c
Created commit 6e893bf: Merge commit 'kmemcheck/auto-kmemcheck-next'
Merging generic-ipi/auto-generic-ipi-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
Created commit 0463080: Merge commit 'lblnet/master'
Merging quilt/ttydev
CONFLICT (content): Merge conflict in fs/devpts/inode.c
Created commit e078ab9: Merge branch 'quilt/ttydev'
Merging agp/agp-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
CONFLICT (content): Merge conflict in drivers/uwb/wlp/eda.c
Created commit 3c3975b: Merge commit 'uwb/for-upstream'
Merging watchdog/master
Merging proc/proc
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
CONFLICT (content): Merge conflict in kernel/sched.c
Created commit db8f43b: Merge commit 'cputime/cputime'
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
CONFLICT (content): Merge conflict in kernel/fork.c
Created commit fd70d10: Merge commit 'nommu/master'
Merging boot-params/master
CONFLICT (content): Merge conflict in arch/arm/kernel/setup.c
CONFLICT (content): Merge conflict in arch/parisc/kernel/setup.c
CONFLICT (content): Merge conflict in arch/sh/boards/mach-microdev/setup.c
CONFLICT (content): Merge conflict in arch/sh/boards/mach-migor/setup.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/common.c
Created commit 45ff2be: Merge commit 'boot-params/master'
Merging trivial/for-next
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [BUG] next-20081231 - S390x kernel panics while bootup at init_sched_build_groups()
From: Kamalesh Babulal @ 2008-12-31 16:03 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, linux-s390, heiko.carstens, schwidefsky
In-Reply-To: <20090101003258.eaa44700.sfr@canb.auug.org.au>
Hi,
next-2001231 kernel panic's on S390x box, while boot up
Linux version 2.6.28-next-20081231-autotest (root@lnxabat1) (gcc version 4.1.0 (
SUSE Linux)) #1 SMP Wed Dec 31 08:43:37 CST 2008
setup: Linux is running as a z/VM guest operating system in 64-bit mode
Zone PFN ranges:
DMA 0x00000000 -> 0x00080000
Normal 0x00080000 -> 0x00080000
Movable zone start PFN for each node
early_node_mapÃ1¨ active PFN ranges
0: 0x00000000 -> 0x00040000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 258560
Kernel command line: root=/dev/dasdc1 selinux=0 IDENT=1230735656 BOOT_IMAGE=0
PID hash table entries: 4096 (order: 12, 32768 bytes)
console ÃttyS0¨ enabled
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Memory: 1015808k/1048576k available (2483k kernel code, 0k reserved, 1372k data,
196k init)
Write protected kernel read-only data: 0x12000 - 0x382fff
SLUB: Genslabs=12, HWalign=256, Order=0-3, MinObjects=0, CPUs=64, Nodes=1
Security Framework initialized
SELinux: Disabled at boot.
Mount-cache hash table entries: 256
cpu: 4 configured CPUs, 0 standby CPUs
cpu: Processor 0 started, address 2, identification 20AB8A
cpu: Processor 1 started, address 0, identification 00AB8A
cpu: Processor 2 started, address 1, identification 10AB8A
cpu: Processor 3 started, address 3, identification 30AB8A
Brought up 4 CPUs
Unable to handle kernel pointer dereference at virtual kernel address 0000000100
3fa000
Oops: 003b Ã#1¨ SMP
Modules linked in:
CPU: 0 Not tainted 2.6.28-next-20081231-autotest #1
Process swapper (pid: 1, task: 000000003fe80000, ksp: 000000003fe8ba78)
Krnl PSW : 0704000180000000 0000000000035632 (init_sched_build_groups+0xae/0x4a4
)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:0 PM:0 EA:3
Krnl GPRS: 00000000003c27b0 00000001003fa278 0000000000000000 00000000003c2508
0000000000000000 000000000026f818 0000000000000000 0000000000000000
0000000000000000 000000003fe8be50 00000000ffffffff 000000003fe8bcf0
Krnl Code: 0000000000035626: a7290000 lghi 00: HCPGSP2629I The virt
ual machine is placed in CP mode due to a SIGP stop from
CPU 02.
01: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
CPU 02.
03: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
CPU 02.
02: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 00021416-- 0:conmux-control -- time-stamp -- Dec/31/08 7:04:54 --
-- 0:conmux-control -- time-stamp -- Dec/31/08 7:22:18 --
(bot:conmon-payload) disconnected
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [BUG] next-20081231 -powerpc - panic at tasklet_kill_immediate()
From: Kamalesh Babulal @ 2008-12-31 16:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, linuxppc-dev, mel
In-Reply-To: <20090101003258.eaa44700.sfr@canb.auug.org.au>
Hi Stephen,
next-20081231 kernel panic's, while booting up on powerpc. This
panic was visible in next-20081230 kernel also.
[ 1.268844] Brought up 2 CPUs
[ 1.268873] Unable to handle kernel paging request for data at address 0x00000009
[ 1.268876] Faulting instruction address: 0xc00000000005a9f8
[ 1.268880] Oops: Kernel access of bad area, sig: 11 [#1]
[ 1.268882] SMP NR_CPUS=32 NUMA PowerMac
[ 1.268886] Modules linked in:
[ 1.268889] NIP: c00000000005a9f8 LR: c00000000006ee54 CTR: c00000000005a9c0
[ 1.268893] REGS: c0000002763c3c80 TRAP: 0300 Not tainted (2.6.28-next-20081231-autokern1)
[ 1.268896] MSR: 9000000000009032 <EE,ME,IR,DR> CR: 24000024 XER: 000fffff
[ 1.268903] DAR: 0000000000000009, DSISR: 0000000040000000
[ 1.268905] TASK = c0000002760e20c0[5] 'ksoftirqd/1' THREAD: c0000002763c0000 CPU: 1
[ 1.268908] GPR00: 0000000000000000 c0000002763c3f00 c0000000004f9088 0000000000000001
[ 1.268913] GPR04: c0000002760e28d0 0000000000000000 0000000024000022 c000000000010098
[ 1.268917] GPR08: 0000000000000000 000000000ec1c518 c000000000514a40 0000000000000010
[ 1.268922] GPR12: c00000000051c700 c00000000051c500 0000000000000000 0000000000000000
[ 1.268926] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 1.268930] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000001400000
[ 1.268934] GPR24: 0000000001829d88 c000000000429b28 0000000001400000 0000000000000000
[ 1.268939] GPR28: c0000002760bfc48 0000000000000001 c000000000498a98 c0000000004b0150
[ 1.268950] NIP [c00000000005a9f8] .tasklet_kill_immediate+0x38/0xb8
[ 1.268955] LR [c00000000006ee54] .kthread+0x78/0xc4
[ 1.268957] Call Trace:
[ 1.268960] [c0000002763c3f00] [c00000000006ee1c] .kthread+0x40/0xc4 (unreliable)
[ 1.268967] [c0000002763c3f90] [c0000000000227a8] .kernel_thread+0x54/0x70
[ 1.268969] Instruction dump:
[ 1.268971] 7c8b07b4 7d693670 7d290194 556b06be e95e8040 7d2907b4 79291f24 e94a0000
[ 1.268977] 7c0a482a 7c005c36 780007e0 0b000000 <e8030008> 7800ffe2 0b000000 e8030008
[ 1.268992] ---[ end trace 31fd0ba7d8756001 ]---
[ 1.269016] Unable to handle kernel paging request for data at address 0x00000000
[ 1.269019] Faulting instruction address: 0xc0000000000d9b4c
[ 1.269022] Oops: Kernel access of bad area, sig: 11 [#2]
[ 1.269024] SMP NR_CPUS=32 NUMA PowerMac
[ 1.269026] Modules linked in:
[ 1.269029] NIP: c0000000000d9b4c LR: c0000000000511fc CTR: 0000000000000003
[ 1.269032] REGS: c0000002763c35d0 TRAP: 0300 Tainted: G D (2.6.28-next-20081231-autokern1)
[ 1.269035] MSR: 9000000000009032 <EE,ME,IR,DR> CR: 28004082 XER: 200fffff
[ 1.269040] DAR: 0000000000000000, DSISR: 0000000040000000
[ 1.269043] TASK = c0000002760e20c0[5] 'ksoftirqd/1' THREAD: c0000002763c0000 CPU: 1
[ 1.269046] GPR00: 0000000000000004 c0000002763c3850 c0000000004f9088 c000000276027d00
[ 1.269051] GPR04: c0000002763b6980 0000000000000000 c000000000457278 c000000000457278
[ 1.269055] GPR08: c0000002760e2290 0000000000000000 c00000000051c500 c0000002763b6080
[ 1.269060] GPR12: 0000000048000084 c00000000051c500 0000000000000000 0000000000000000
[ 1.269064] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 1.269068] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[ 1.269073] GPR24: c0000002760e20b0 c0000002760e2228 0000000000000000 c000000276027d00
[ 1.269077] GPR28: 0000000000000000 c0000002763b6980 c00000000049c9b8 0000000000000000
[ 1.269086] NIP [c0000000000d9b4c] .kmem_cache_free+0x1b8/0x244
[ 1.269090] LR [c0000000000511fc] .__cleanup_sighand+0x44/0x5c
[ 1.269092] Call Trace:
[ 1.269095] [c0000002763c3850] [c00000000049abe8] 0xc00000000049abe8 (unreliable)
[ 1.269099] [c0000002763c3900] [c0000000000511fc] .__cleanup_sighand+0x44/0x5c
[ 1.269104] [c0000002763c3980] [c000000000057244] .release_task+0x2dc/0x400
[ 1.269108] [c0000002763c3a20] [c000000000057b14] .do_exit+0x7ac/0x858
[ 1.269112] [c0000002763c3af0] [c000000000020414] .die+0x1c8/0x1cc
[ 1.269117] [c0000002763c3b90] [c000000000027f4c] .bad_page_fault+0xb8/0xd4
[ 1.269122] [c0000002763c3c10] [c000000000005318] handle_page_fault+0x3c/0x5c
[ 1.269128] --- Exception: 300 at .tasklet_kill_immediate+0x38/0xb8
[ 1.269130] LR = .kthread+0x78/0xc4
[ 1.269133] [c0000002763c3f00] [c00000000006ee1c] .kthread+0x40/0xc4 (unreliable)
[ 1.269138] [c0000002763c3f90] [c0000000000227a8] .kernel_thread+0x54/0x70
[ 1.269141] Instruction dump:
[ 1.269142] 4800016d e97d0168 880d01dc 2fa00000 41be0010 7c0004ac 38000000 980d01dc
[ 1.269148] 7c2004ac 38000000 900b0040 48000050 <817f0000> 801f0004 7f8b0040 409c001c
[ 1.269155] ---[ end trace 31fd0ba7d8756001 ]---
[ 1.269157] Fixing recursive fault but reboot is needed!
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox