RFC: [PATCH-2.6] Add helper function to lock multiple page cache pages.
Hi,
On Thu, 27 Jan 2005, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
What would you propose can I do to perform the required zeroing in a
deadlock safe manner whilst also ensuring that it cannot happen that a
concurrent -readpage() will cause me to miss a page and thus end up
with non-initialized/random data on disk for that page?
The only thing I can think of is to lock all the pages.
[snip discussion of how this can be done safely - for details see
Andrew's post with the subject Re: Advice sought on how to lock multiple
pages in -prepare_write and -writepage]
Below is a patch which adds a function
mm/filemap.c::find_or_create_pages(), locks a range of pages. Please see
the function description in the patch for details.
Nathan, would this be useful to you?
Andrew, would this be acceptable? And does it look right from a safety
point of view? I have added the try locks as you suggested.
Note, I have only compile tested this function as the NTFS code
implementing hole filling is nowhere near ready to even test yet...
Best regards,
Anton
--
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ http://www-stu.christs.cam.ac.uk/~aia21/
--- ntfs-2.6-devel/mm/filemap.c.old 2005-02-01 16:19:13.0 +
+++ ntfs-2.6-devel/mm/filemap.c 2005-02-02 15:06:57.158759886 +
@@ -586,6 +586,123 @@
EXPORT_SYMBOL(find_or_create_page);
/**
+ * find_or_create_pages - locate and/or add a number of page cache pages
+ * @mapping: address space in which to locate the pages
+ * @start: starting page index
+ * @nr_pages: number of pages to locate
+ * @pages: where the resulting pages are placed
+ * @gfp_mask: page allocation mode (for new pages)
+ * @locked_page: already locked page in the range of pages to lock
+ * @wbc: writeback control of @locked_page if applicable
+ *
+ * find_or_create_pages() locates @nr_pages starting at page index @start in
+ * the page cache described by the address space @mapping. The pages are
+ * placed in @pages. If any pages are not present in the page cache, new pages
+ * are allocated using @gfp_mask and are added to the page cache of @mapping as
+ * well as to the VM's LRU list. The returned pages are locked and have their
+ * reference count incremented. The locking is done in ascending page index
+ * order.
+ *
+ * @locked_page is a locked page in the requested range of pages. A reference
+ * is not acquired for @locked_page as the caller is assumed to hold one
+ * already. (Callers of -prepare_write and -writepage take a reference on
+ * the page.)
+ *
+ * @wbc is the writeback control of @locked_page if called from -writepage and
+ * NULL otherwise (called from -prepare_write()).
+ *
+ * Note, find_or_create_pages() may sleep, even if @gfp_flags specifies an
+ * atomic allocation!
+ *
+ * Return 0 on success and -errno on error. Possible errors are:
+ * -ENOMEM memory exhaustion
+ * -EDEADLKcould not safely acquire required locks
+ * -ESTALE @locked_page was truncated by a racing process
+ */
+int find_or_create_pages(struct address_space *mapping, pgoff_t start,
+ const unsigned int nr_pages, struct page **pages,
+ const unsigned int gfp_mask, struct page *locked_page,
+ const struct writeback_control *wbc)
+{
+ struct page *cached_page = NULL;
+ struct inode *inode = mapping-host;
+ pgoff_t lp_idx = locked_page-index;
+ int err, nr;
+
+ if (lp_idx != start) {
+ if (wbc wbc-for_reclaim) {
+ if (!down_read_trylock(inode-i_sb-s_umount))
+ return -EDEADLK;
+ if (down_trylock(inode-i_sem)) {
+ up_read(inode-i_sb-s_umount);
+ return -EDEADLK;
+ }
+ }
+ unlock_page(locked_page);
+ }
+ err = nr = 0;
+ while (nr nr_pages) {
+ if (start == lp_idx) {
+ pages[nr] = locked_page;
+ if (nr) {
+ lock_page(locked_page);
+ if (wbc) {
+ if (wbc-for_reclaim) {
+ up(inode-i_sem);
+ up_read(inode-i_sb-s_umount);
+ }
+ /* Was the page truncated under us? */
+ if (page_mapping(locked_page) !=
+ mapping) {
+ err = -ESTALE;
+
Re: RFC: [PATCH-2.6] Add helper function to lock multiple page cache pages.
On Wed, Feb 02, 2005 at 03:12:50PM +, Anton Altaparmakov wrote:
I think the below loop would be clearer as a for loop ...
err = 0;
for (nr = 0; nr nr_pages; nr++, start++) {
if (start == lp_idx) {
pages[nr] = locked_page;
if (!nr)
continue;
lock_page(locked_page);
if (!wbc)
continue;
if (wbc-for_reclaim) {
up(inode-i_sem);
up_read(inode-i_sb-s_umount);
}
/* Was the page truncated under us? */
if (page_mapping(locked_page) != mapping) {
err = -ESTALE;
goto err_out_locked;
}
} else {
pages[nr] = find_lock_page(mapping, start);
if (pages[nr])
continue;
if (!cached_page) {
cached_page = alloc_page(gfp_mask);
if (unlikely(!cached_page))
goto err_out;
}
err = add_to_page_cache_lru(cached_page,
mapping, start, gfp_mask);
if (unlikely(err)) {
if (err == -EEXIST)
continue;
goto err_out;
}
pages[nr] = cached_page;
cached_page = NULL;
}
}
The above fixes two bugs in the below:
- if (!unlikely(cached_page)) should be if (unlikely(!cached_page))
- The -EEXIST case after add_to_page_cache_lru() would result in
an infinite loop in the original as nr wasn't being incremented.
+ err = nr = 0;
+ while (nr nr_pages) {
+ if (start == lp_idx) {
+ pages[nr] = locked_page;
+ if (nr) {
+ lock_page(locked_page);
+ if (wbc) {
+ if (wbc-for_reclaim) {
+ up(inode-i_sem);
+ up_read(inode-i_sb-s_umount);
+ }
+ /* Was the page truncated under us? */
+ if (page_mapping(locked_page) !=
+ mapping) {
+ err = -ESTALE;
+ goto err_out_locked;
+ }
+ }
+ }
+ } else {
+ pages[nr] = find_lock_page(mapping, start);
+ if (!pages[nr]) {
+ if (!cached_page) {
+ cached_page = alloc_page(gfp_mask);
+ if (!unlikely(cached_page))
+ goto err_out;
+ }
+ err = add_to_page_cache_lru(cached_page,
+ mapping, start, gfp_mask);
+ if (unlikely(err)) {
+ if (err == -EEXIST)
+ continue;
+ goto err_out;
+ }
+ pages[nr] = cached_page;
+ cached_page = NULL;
+ }
+ }
+ nr++;
+ start++;
+ }
--
Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception. -- Mark Twain
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: [PATCH-2.6] Add helper function to lock multiple page cache pages.
Hi Matthew,
On Wed, 2005-02-02 at 15:43 +, Matthew Wilcox wrote:
On Wed, Feb 02, 2005 at 03:12:50PM +, Anton Altaparmakov wrote:
I think the below loop would be clearer as a for loop ...
err = 0;
for (nr = 0; nr nr_pages; nr++, start++) {
if (start == lp_idx) {
pages[nr] = locked_page;
if (!nr)
continue;
lock_page(locked_page);
if (!wbc)
continue;
if (wbc-for_reclaim) {
up(inode-i_sem);
up_read(inode-i_sb-s_umount);
}
/* Was the page truncated under us? */
if (page_mapping(locked_page) != mapping) {
err = -ESTALE;
goto err_out_locked;
}
} else {
pages[nr] = find_lock_page(mapping, start);
if (pages[nr])
continue;
if (!cached_page) {
cached_page = alloc_page(gfp_mask);
if (unlikely(!cached_page))
goto err_out;
}
err = add_to_page_cache_lru(cached_page,
mapping, start, gfp_mask);
if (unlikely(err)) {
if (err == -EEXIST)
continue;
goto err_out;
}
pages[nr] = cached_page;
cached_page = NULL;
}
}
The above fixes two bugs in the below:
- if (!unlikely(cached_page)) should be if (unlikely(!cached_page))
Ah, oops. Thanks! Well spotted! I did say it was only compile
tested... (-;
- The -EEXIST case after add_to_page_cache_lru() would result in
an infinite loop in the original as nr wasn't being incremented.
That was exactly what was meant to happen. It is not a bug. It is a
feature. This is why it is a while loop instead of a for loop. I need
to have @nr and @start incremented only if the code reaches the end of
the loop.
The -EEXIST case needs to repeat for the same @nr and @start. It
basically means that someone else allocated the page with index @start
and added it to the page cache in between us running find_lock_page()
and add_to_page_cache_lru(). So what we want to do is to run
find_lock_page() again which should then find and lock the page that the
other process created.
Of course what could happen is that between us getting the -EEXIST and
us repeating the find_lock_page() the page is freed again so the
find_lock_page() fails again. Perhaps this time we will succeed with
add_to_page_cache_lru() and if not we repeat again. Eventually either
find_lock_page() or add_to_page_cache_lru() will succeed so in practise
it will never be an endless loop.
If the while loop is changed to a for loop, the continue; on -EEXIST
would need to be changed to goto repeat; and a label repeat: would
need to be placed at the beginning of the loop. I considered this but
decided the while loop looks nicer. (-:
Thanks for the review!
+ err = nr = 0;
+ while (nr nr_pages) {
+ if (start == lp_idx) {
+ pages[nr] = locked_page;
+ if (nr) {
+ lock_page(locked_page);
+ if (wbc) {
+ if (wbc-for_reclaim) {
+ up(inode-i_sem);
+ up_read(inode-i_sb-s_umount);
+ }
+ /* Was the page truncated under us? */
+ if (page_mapping(locked_page) !=
+ mapping) {
+ err = -ESTALE;
+ goto err_out_locked;
+ }
+ }
+ }
+ } else {
+ pages[nr] = find_lock_page(mapping, start);
+ if (!pages[nr]) {
+ if (!cached_page) {
+ cached_page = alloc_page(gfp_mask);
+ if (!unlikely(cached_page))
+ goto err_out;
+ }
+ err = add_to_page_cache_lru(cached_page,
+ mapping, start, gfp_mask);
+ if (unlikely(err)) {
+
Re: [PATCH] OpenBSD Networking-related randomization port
*Sigh*. This thread is heading into the weeds. I have things I should be doing instead, but since nobody seems to actually be looking at what the patch *does*, I guess I'll have to dig into it a bit more... Yes, licensing issues need to be resolved before a patch can go in. Yes, code style standards needs to be kept up. And yes, SMP-locking issues need to be looked at. (And yes, ipv6 needs to be looked at, too!) But before getting sidetracked into the fine details, could folks please take a step back from the trees and look at the forest? Several people have asked (especially when the first patch came out), but I haven't seen any answers to the Big Questions: 1) Does this patch improve Linux's networking behaviour in any way? 2) Are the techniques in this patch a good way to achieve those improvements? Let's look at the various parts of the change: - Increases the default random pool size. Opinion: whatever. No real cost, except memory. Increases the maximum amount that can be read from /dev/random without blocking. Note that this is already adjustable at run time, so the question is why put it in the kernel config. If you want this, I'd suggest instead an option under CONFIG_EMBEDDED to shrink the pools and possibly get rid of the run-time changing code, then you could increase the default with less concern. - Changes the TCP ISN generation algorithm. I have't seen any good side to this. The current algorithm can be used for OS fingerprinting based on starting two TCP connections from different sources (ports or IPs) and noticing that the ISNs only differ in the low 24 bits, but is that a serious issue? If it is, there are better ways to deal with it that still preserve the valuable timer property. I point out that the entire reason for the cryptographically marginal half_md4_transform oprtation was that a full MD5 was a very noticeable performance bottleneck; the hash was only justified by the significant real-world attacks. obsd_get_random uses two calls to half_md4_transform. Which is the same cost as a full MD4 call. Frankly, they could just change half_md4_transform to return 64 bits instead of 32 and make do with one call. - Changes to the IP ID generation algorithm. All it actually does is change the way the initial inet-id is initialized for the inet_opt structure associated with the TCP socket. And if you look at ip_output.c:ip_push_pending_frames(), you'll see that, if DF is set (as is usual for a TCP connection), iph-id (the actual IP header ID) is set to htons(inet-id++). So it's still an incrementing sequence. This is in fact (see the comment in ip.h:ip_select_ident()) a workaround for a Microsoft VJ compression bug. The fix was added in 2.4.4 (via DaveM's zerocopy-beta-3 patch); before that, Linux 2.4 sent a constant zero as the IP ID of DF packets. See discussion at http://www.postel.org/pipermail/end2end-interest/2001-May/thread.html http://tcp-impl.lerc.nasa.gov/tcp-impl/list/archive/2378.html I'm not finding the diagnosis of the problem. I saw one report at http://oss.sgi.com/projects/netdev/archive/2001-01/msg6.html and Dave Miller is pretty much on top of it when he posts http://marc.theaimsgroup.com/?l=linux-kernelm=98275316400452w=2 but I haven't found the actual debugging leading to the conclusion. This also led to some discussion of the OpenBSD IP ID algorithm that I haven't fully waded through at http://mail-index.netbsd.org/tech-net/2003/11/ If the packet is fragmentable (the only time the IP ID is really needed by the receiver), it's done by route.c:__ip_select_ident(). Wherein the system uses inet_getid to assign p-ip_id_count++ based on the route cache's struct inet_peer *p. (If the route cache is OOM, the system falls back on random IP ID assignment.) This latter technique nicely prevents the sort of stealth port scanning that was mentioned earlier in this thread, and prevents a person at address A from guessing the IP ID range I'm using to talk to address B. So note that the boast about Randomized IP IDs in the grsecurity description at http://www.gentoo.org/proj/en/hardened/grsecurity.xml is, as far as I can tell from a quick look at the code, simply false. As for the algorithm itself, it's described at http://www.usenix.org/events/usenix99/full_papers/deraadt/deraadt_html/node18.html but it's not obvious to me that it'd be hard to cryptanalyze given a stream of consecutive IDs. You need to recover: - The n value for each inter-ID gap, - The LCRNG state ru_a, ru_x, ru_b, - The 15-bit XOR masks ru_seed and ru_seed2, and - The discrete log generator ru_j (ru_g = 2^ru_j mod RU_N). Which is actually just a multiplier (mod RU_N-1 = 32748) on the input to the pmod() operation. So the IP ID generation can be summarized as: ru_x = (ru_a * ru_x + ru_b) % 31104; /*
Re: [PATCH] OpenBSD Networking-related randomization port
El mié, 02-02-2005 a las 17:17 +, [EMAIL PROTECTED] escribió: There *are* things in OpenBSD, like randomized port assignment (as opposed to the linear scan in tcp_v4_get_port()) that would be worth emulating. Maybe worry about that first? Completely agreed with you, I was just trying to help with split up patches, but, as your analysis shows, it's more a weak implementation than a real security improvement. All I can say, just ignore the patch.I will work on other (worthy) issues that are in a bigger need. Maybe I would work something out on randomized source ports, as soon as I get time for it. Note also that Brad fixed obsd_rand.c code this week, I've added him to the CC list because there are things that may concern grSecurity he should be able to comment further on it and discuss whatever concerns *his* work (which is, BTW, a good thing (tm) to have in mind even if he didn't send split up patches for each feature, which I really don't know). I've just ported it out of grsecurity. Thanks for your meaningful comments, Cheers. -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
RE: [Announce] megaraid_mbox 2.20.4.4 patch
On Tuesday, February 01, 2005 1:15 PM, Matt Domsch wrote: This patch is mangled. Long lines are wrapped, and appears to be in ISO-8859-1, such that spaces (ascii 0x20) appear as hex 0xa0. This makes it difficult to review, and impossible to apply. +// definitions for the device attributes for exporting logical drive number +// for a scsi address (Host, Channel, Id, Lun) + +CLASS_DEVICE_ATTR(megaraid_mbox_app_hndl, S_IRUSR, megaraid_sysfs_show_app_hndl, + NULL); How is this being used by your apps please? Otherwise the patch looks sane. Thanks for feedback and sorry for inconvenience. Here, I'm attaching updated patch and inlining as well. Thanks, Seokmann LSI Logic Corporation. --- diff -Naur linux_bk/Documentation/scsi/ChangeLog.megaraid linux_bk.new/Documentation/scsi/ChangeLog.megaraid --- linux_bk/Documentation/scsi/ChangeLog.megaraid 2005-02-02 11:06:01.488871288 -0500 +++ linux_bk.new/Documentation/scsi/ChangeLog.megaraid 2005-02-02 11:06:15.256778248 -0500 @@ -1,3 +1,89 @@ +Release Date : Thu Jan 27 00:01:03 EST 2005 - Atul Mukker [EMAIL PROTECTED] +Current Version: 2.20.4.4 (scsi module), 2.20.2.5 (cmm module) +Older Version : 2.20.4.3 (scsi module), 2.20.2.4 (cmm module) + +1. Bump up the version of scsi module due to its conflict. + +Release Date : Thu Jan 21 00:01:03 EST 2005 - Atul Mukker [EMAIL PROTECTED] +Current Version: 2.20.4.3 (scsi module), 2.20.2.5 (cmm module) +Older Version : 2.20.4.2 (scsi module), 2.20.2.4 (cmm module) + +1. Remove driver ioctl for logical drive to scsi address translation and + replace with the sysfs attribute. To remove drives and change + capacity, application shall now use the device attribute to get the + logical drive number for a scsi device. For adding newly created + logical drives, class device attribute would be required to uniquely + identify each controller. + - Atul Mukker [EMAIL PROTECTED] + + James, I've been thinking about this a little more, and you may be on + to something here. Let each driver add files as such: + + - Matt Domsch [EMAIL PROTECTED], 12.15.2004 +linux-scsi mailing list + + + Then, if you simply publish your LD number as an extra parameter of + the device, you can look through /sys to find it. + + - James Bottomley [EMAIL PROTECTED], 01.03.2005 +linux-scsi mailing list + + + I don't see why not ... it's your driver, you can publish whatever + extra information you need as scsi_device attributes; that was one of + the designs of the extensible attribute system. + + - James Bottomley [EMAIL PROTECTED], 01.06.2005 +linux-scsi mailing list + +2. Add AMI megaraid support - Brian King [EMAIL PROTECTED] + PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3, + PCI_VENDOR_ID_AMI, PCI_SUBSYS_ID_PERC3_DC, + +3. Make some code static - Adrian Bunk [EMAIL PROTECTED] + Date: Mon, 15 Nov 2004 03:14:57 +0100 + + The patch below makes some needlessly global code static. + -wait_queue_head_t wait_q; + +static wait_queue_head_t wait_q; + + Signed-off-by: Adrian Bunk [EMAIL PROTECTED] + +4. Added NEC ROMB support - NEC MegaRAID PCI Express ROMB controller + PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_MEGARAID_NEC_ROMB_2E, + PCI_SUBSYS_ID_NEC, PCI_SUBSYS_ID_MEGARAID_NEC_ROMB_2E, + +5. Fixed Tape drive issue : For any Direct CDB command to physical device + including tape, timeout value set by driver was 10 minutes. With this + value, most of command will return within timeout. However, for those + command like ERASE or FORMAT, it takes more than an hour depends on + capacity of the device and the command could be terminated before it + completes. + To address this issue, the 'timeout' field in the DCDB command will + have NO TIMEOUT (i.e., 4) value as its timeout on DCDB command. + + + +Release Date : Thu Dec 9 19:10:23 EST 2004 + - Sreenivas Bagalkote [EMAIL PROTECTED] + +Current Version: 2.20.4.2 (scsi module), 2.20.2.4 (cmm module) +Older Version : 2.20.4.1 (scsi module), 2.20.2.3 (cmm module) + +i. Introduced driver ioctl that returns scsi address for a given ld. + + Why can't the existing sysfs interfaces be used to do this? + - Brian King ([EMAIL PROTECTED]) + + I've looked into solving this another way, but I cannot see how + to get this driver-private mapping of logical drive number- HCTL + without putting code something like this into the driver. + + ...and by providing a mapping a function to userspace, the driver + is free to change its mapping algorithm in the future if necessary .. + - Matt Domsch ([EMAIL PROTECTED]) + Release Date : Thu Dec 9 19:02:14 EST
Re: [PATCH 2.6.11-rc2 0/29] ide: driver updates
Tejun Heo wrote:
Hello, B. Zolnierkiewicz.
These patches are various fixes/improvements to the ide driver. They
are against the 2.6 bk tree as of today (20050202).
01_ide_remove_adma100.patch
Removes drivers/ide/pci/adma100.[hc]. The driver isn't
compilable (missing functions) and no Kconfig actually enables
CONFIG_BLK_DEV_ADMA100.
Also, the libata-dev-2.6 tree has an ata_adma driver which is
complete, but needs some testing (and I have h/w).
05_ide_merge_pci_driver_hc.patch
Merges drivers/ide/pci/*.h files into their corresponding *.c
files. Rationales are
1. There's no reason to separate pci drivers into header and
body. No header file is shared and they're simple enough.
2. struct pde_pci_device_t *_chipsets[] are _defined_ in the
header files. That isn't the custom and there's no good
reason to do differently in these drivers.
3. Tracking changelogs shows that the bugs fixed by 00 and 01
are introduced during mass-updating ide pci drivers by
forgetting to update *.h files.
Personally, I agree. However, I would ask Alan for his rationale before
applying this...
07_ide_reg_valid_t_endian_fix.patch
ide_reg_valid_t contains bitfield flags but doesn't reverse
bit orders using __*_ENDIAN_BITFIELD macros. And constants
for ide_reg_valid_t, IDE_{TASKFILE|HOB}_STD_{IN|OUT}_FLAGS,
are defined as byte values which are correct only on
little-endian machines. This patch defines reversed constants
and .h byte union structure to make things correct on big
endian machines. The only code which uses above macros is in
flagged_taskfile() and the code is currently unused, so this
patch doesn't change any behavior. (The code will get used in
later patches.)
doesn't this fix change behavior on existing big endian machines?
15_ide_flagged_taskfile_data_byte_order_fix.patch
In flagged_taskfile(), when writing data register,
taskfile-data goes to the lower byte and hobfile-data goes
to the upper byte on little endian machines and the opposite
happens on big endian machines. This patch make
taskfile-data always go to the lower byte regardless of
endianess.
ditto
16_ide_flagged_taskfile_select_dev_bit_masking.patch
In flagged_taskfile(), make off DEV bit before OR'ing it with
drive-select.all when writing to IDE_SELECT_REG.
Probably the right thing to do, but be very very careful you have
audited all uses...
21_ide_do_taskfile.patch
Merged do_rw_taskfile() and flagged_taskfile() into
do_taskfile(). During the merge, the following changes took
place.
1. flagged taskfile now honors HOB feature register.
(do_rw_taskfile() did write to HOB feature.)
2. No do_rw_taskfile() HIHI check on select register. Except
for the DEV bit, all bits are honored.
3. Uses taskfile-data_phase to determine if dma trasfer is
requested. (do_rw_taskfile() directly switched on
taskfile-command for all dma commands)
I think Bart already had plans for this (similar to your patch)?
22_ide_taskfile_flush.patch
All REQ_DRIVE_TASK users except ide_task_ioctl() converted
to use REQ_DRIVE_TASKFILE.
Rationale?
24_ide_remove_task.patch
Unused REQ_DRIVE_TASK handling removed.
this series is nice.
25_ide_taskfile_cmd.patch
All in-kernel REQ_DRIVE_CMD users except for ide_cmd_ioctl()
converted to use REQ_DRIVE_TASKFILE.
26_ide_taskfile_cmd_ioctl.patch
ide_cmd_ioctl() converted to use ide_taskfile_ioctl(). This
is the last user of REQ_DRIVE_CMD.
ditto
27_ide_remove_cmd.patch
Removed unused REQ_DRIVE_CMD handling.
28_ide_taskfile_init_drive_cmd.patch
ide_init_drive_cmd() now initializes rq-flags to
REQ_DRIVE_TASKFILE.
29_ide_explicit_TASKFILE_NO_DATA.patch
Make data_phase explicit in NO_DATA cases.
I would make sure this series gets some amount of testing in -mm before
pushing upstream, though...
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFT 2.6.11-rc2-bk10] libata (SATA) driver update
Mainly for testing by Promise and nVIDIA users, but also includes a fix
for a few lesser-used SCSI commands (that affect all SATA users).
See attached...
BK users:
bk pull bk://gkernel.bkbits.net/libata-2.6
This will update the following files:
drivers/scsi/libata-core.c | 91 ++--
drivers/scsi/libata-scsi.c |8 +--
drivers/scsi/sata_nv.c | 45 -
drivers/scsi/sata_promise.c | 12 -
4 files changed, 135 insertions(+), 21 deletions(-)
through these ChangeSets:
Albert Lee:
o [libata] SCSI-to-ATA translation fixes
Andrew Chew:
o sata_nv: enable generic class support for future NVIDIA SATA
Jeff Garzik:
o [libata sata_promise] support Promise SATAII TX2/TX4 cards
o [libata] Remove CDROM drive from PATA DMA blacklist
o [libata] add DMA blacklist
diff -Nru a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
--- a/drivers/scsi/libata-core.c2005-02-02 04:02:11 -05:00
+++ b/drivers/scsi/libata-core.c2005-02-02 04:02:11 -05:00
@@ -1700,6 +1700,69 @@
DPRINTK(EXIT\n);
}
+static void ata_pr_blacklisted(struct ata_port *ap, struct ata_device *dev)
+{
+ printk(KERN_WARNING ata%u: dev %u is on DMA blacklist, disabling
DMA\n,
+ ap-id, dev-devno);
+}
+
+static const char * ata_dma_blacklist [] = {
+ WDC AC11000H,
+ WDC AC22100H,
+ WDC AC32500H,
+ WDC AC33100H,
+ WDC AC31600H,
+ WDC AC32100H,
+ WDC AC23200L,
+ Compaq CRD-8241B,
+ CRD-8400B,
+ CRD-8480B,
+ CRD-8482B,
+ CRD-84,
+ SanDisk SDP3B,
+ SanDisk SDP3B-64,
+ SANYO CD-ROM CRD,
+ HITACHI CDR-8,
+ HITACHI CDR-8335,
+ HITACHI CDR-8435,
+ Toshiba CD-ROM XM-6202B,
+ CD-532E-A,
+ E-IDE CD-ROM CR-840,
+ CD-ROM Drive/F5A,
+ WPI CDD-820,
+ SAMSUNG CD-ROM SC-148C,
+ SAMSUNG CD-ROM SC,
+ SanDisk SDP3B-64,
+ SAMSUNG CD-ROM SN-124,
+ ATAPI CD-ROM DRIVE 40X MAXIMUM,
+ _NEC DV5800A,
+};
+
+static int ata_dma_blacklisted(struct ata_port *ap, struct ata_device *dev)
+{
+ unsigned char model_num[40];
+ char *s;
+ unsigned int len;
+ int i;
+
+ ata_dev_id_string(dev-id, model_num, ATA_ID_PROD_OFS,
+ sizeof(model_num));
+ s = model_num[0];
+ len = strnlen(s, sizeof(model_num));
+
+ /* ATAPI specifies that empty space is blank-filled; remove blanks */
+ while ((len 0) (s[len - 1] == ' ')) {
+ len--;
+ s[len] = 0;
+ }
+
+ for (i = 0; i ARRAY_SIZE(ata_dma_blacklist); i++)
+ if (!strncmp(ata_dma_blacklist[i], s, len))
+ return 1;
+
+ return 0;
+}
+
static unsigned int ata_get_mode_mask(struct ata_port *ap, int shift)
{
struct ata_device *master, *slave;
@@ -1712,17 +1775,37 @@
if (shift == ATA_SHIFT_UDMA) {
mask = ap-udma_mask;
- if (ata_dev_present(master))
+ if (ata_dev_present(master)) {
mask = (master-id[ATA_ID_UDMA_MODES] 0xff);
- if (ata_dev_present(slave))
+ if (ata_dma_blacklisted(ap, master)) {
+ mask = 0;
+ ata_pr_blacklisted(ap, master);
+ }
+ }
+ if (ata_dev_present(slave)) {
mask = (slave-id[ATA_ID_UDMA_MODES] 0xff);
+ if (ata_dma_blacklisted(ap, slave)) {
+ mask = 0;
+ ata_pr_blacklisted(ap, slave);
+ }
+ }
}
else if (shift == ATA_SHIFT_MWDMA) {
mask = ap-mwdma_mask;
- if (ata_dev_present(master))
+ if (ata_dev_present(master)) {
mask = (master-id[ATA_ID_MWDMA_MODES] 0x07);
- if (ata_dev_present(slave))
+ if (ata_dma_blacklisted(ap, master)) {
+ mask = 0;
+ ata_pr_blacklisted(ap, master);
+ }
+ }
+ if (ata_dev_present(slave)) {
mask = (slave-id[ATA_ID_MWDMA_MODES] 0x07);
+ if (ata_dma_blacklisted(ap, slave)) {
+ mask = 0;
+ ata_pr_blacklisted(ap, slave);
+ }
+ }
}
else if (shift == ATA_SHIFT_PIO) {
mask = ap-pio_mask;
diff -Nru a/drivers/scsi/libata-scsi.c b/drivers/scsi/libata-scsi.c
--- a/drivers/scsi/libata-scsi.c2005-02-02 04:02:11 -05:00
+++ b/drivers/scsi/libata-scsi.c2005-02-02 04:02:11 -05:00
@@ -498,9 +498,9 @@
tf-nsect = n_sect 0xff;
- tf-hob_lbah = (sect 16) 0xff;
-
when and where shall I encrypt dentry?
Hi all, I am trying to add some cryptographic functionality to ext2 file system for my masters project. I am working with kernel 2.4.21 Along with regular files, I intend to encrypt directory contents too. For reading I guess the function ext2_get_page in fs/ext2/dir.c is used. Hence I can put my decryption routine in that function. Is that correct? I was trying to look for the routine which writes the dentry on disk, but was unable to find it. I found out that the function d_instantiate is used to fill in inode information for a dentry, but unable to see when it is written on disk. I suppose that I have to encrypt the dentry just before writing on to the disk, as if i encrypt it before, other functions using it wont be able to access until they decrypt. So please help me with this, that when and where shall I encrypt the directory contents. Thanks and regards, Vineet ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: when and where shall I encrypt dentry?
The correct place to encrypt or decrypt ANYTHING is just before access to the outside world, i.e., in the case of a file-system, the reads and writes to the storage device (disk drive). You are in a world of hurt if you intend to encrypt 'data' and directories separately. If you need to use an existing file-system and then encrypt it, you use the same technique but your storage device is a container file that you mount using the loop device. This allows you to have an encrypted file-system below some mount-point and a normal file-system above. FYI, there are existing tools/code that allow one to mount an encrypted file-system. Perhaps your masters project just got easier? On Wed, 2 Feb 2005, Vineet Joglekar wrote: Hi all, I am trying to add some cryptographic functionality to ext2 file system for my masters project. I am working with kernel 2.4.21 Along with regular files, I intend to encrypt directory contents too. For reading I guess the function ext2_get_page in fs/ext2/dir.c is used. Hence I can put my decryption routine in that function. Is that correct? I was trying to look for the routine which writes the dentry on disk, but was unable to find it. I found out that the function d_instantiate is used to fill in inode information for a dentry, but unable to see when it is written on disk. I suppose that I have to encrypt the dentry just before writing on to the disk, as if i encrypt it before, other functions using it wont be able to access until they decrypt. So please help me with this, that when and where shall I encrypt the directory contents. Thanks and regards, Vineet ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] shared subtrees
On Tue, 2005-02-01 at 15:21, J. Bruce Fields wrote: On Tue, Jan 25, 2005 at 01:07:12PM -0800, Ram wrote: If there exists a private subtree in a larger shared subtree, what happens when the larger shared subtree is rbound to some other place? Is a new private subtree created in the new larger shared subtree? or will that be pruned out in the new larger subtree? mount --rbind will always do at least all the mounts that it did before the introduction of shared subtrees--so certainly it will copy private subtrees along with shared ones. (Since subtrees are private by default, anything else would make --rbind do nothing by default.) My understanding of Viro's RFC is that the new subtree will have no connection with the preexisting private subtree (we want private subtrees to stay private), but that the new copy will end up with whatever propagation the target of the mount --rbind had. (So the addition of the copy of the private subtree to the target vfsmount will be replicated on any vfsmount that the target vfsmount propogates to, and those copies will propagate among themselves in the same way that the copies of the target vfsmount propagate to each other.) ok. that makes sense. As you said the private subtree shall get copied to the new location, however propogations wont be set in either directions. However I have a rather unusual requirement which forces multiple rbind of a shared subtree within the same shared subtree. I did the calculation and found that the tree simply explodes with vfsstructs. If I mark a subtree within the larger shared tree as private, then the number of vfsstructs grows linearly O(n). However if there was a way of marking a subtree within the larger shared tree as unclonable than the increase in number of vfsstruct is constant. What I am essentially driving at is, can we add another feature which allows me to mark a subtree as unclonable? Read below to see how the tree explodes: to run you through an example: (In case the tree pictures below gets garbled, it can also be seen at http://www.sudhaa.com/~ram/readahead/sharedsubtree/subtree ) step 1: lets say the root tree has just two directories with one vfsstruct. root /\ tmpusr All I want is to be able to see the entire root tree (but not anything under /root/tmp) to be viewable under /root/tmp/m* step2: mount --make-shared /root mkdir -p /tmp/m1 mount --rbind /root /tmp/m1 the new tree now looks like this: root /\ tmpusr / m1 / \ tmp usr / m1 it has two vfsstructs step3: mkdir -p /tmp/m2 mount --rbind /root /tmp/m2 the new tree now looks like this: root /\ tmp usr /\ m1 m2 / \ / \ tmp usr tmp usr / \ / m1 m2 m1 / \ / \ tmp usr tmp usr // \ m1 m1 m2 / \ tmp usr / \ m1 m2 it has 6 vfsstructs step 4: mkdir -p /tmp/m3 mount --rbind /root /tmp/m3 I wont' draw the tree..but it will have 24 vfstructs at step i the number of vfsstructs V[i] = i*V[i-1] which is an exponential function. This is a issue in general if somebody does a --rbind of shared tree within the same shared tree multiple times. However this issue can be alleviated if we mark the subtree as private. In the above example, if I mark the tree under /root/tmp as private the number of vfsstructs will reduce drastically to O(n). But if there is a way of marking a subtree unclonable, this entire issue can be resolved. RP --Bruce Fields - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] prism54: misc cleanups
This patch makes some functions in prism54 that are only required
locally static.
As a side effect it turned out that the mgt_unlatch_all function was
completely unused, and it's therefore #if 0'ed.
I also considered moving display_buffer as static inline into
islpci_mgt.h, but I wasn't 100% sure and therefore left it.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 20 Dec 2004
drivers/net/wireless/prism54/isl_ioctl.c | 32 +++---
drivers/net/wireless/prism54/isl_ioctl.h |5 --
drivers/net/wireless/prism54/islpci_dev.c |5 +-
drivers/net/wireless/prism54/islpci_dev.h |2 -
drivers/net/wireless/prism54/islpci_mgt.c |2 +
drivers/net/wireless/prism54/oid_mgt.c| 38 +-
drivers/net/wireless/prism54/oid_mgt.h|4 --
7 files changed, 28 insertions(+), 60 deletions(-)
--- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.h.old
2004-10-30 06:52:18.0 +0200
+++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.h
2004-10-30 07:02:58.0 +0200
@@ -41,15 +41,10 @@
void prism54_wpa_ie_init(islpci_private *priv);
void prism54_wpa_ie_clean(islpci_private *priv);
-void prism54_wpa_ie_add(islpci_private *priv, u8 *bssid,
- u8 *wpa_ie, size_t wpa_ie_len);
-size_t prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie);
int prism54_set_mac_address(struct net_device *, void *);
int prism54_ioctl(struct net_device *, struct ifreq *, int);
-int prism54_set_wpa(struct net_device *, struct iw_request_info *,
- __u32 *, char *);
extern const struct iw_handler_def prism54_handler_def;
--- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.c.old
2004-10-30 06:43:10.0 +0200
+++ linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/isl_ioctl.c
2004-10-30 07:11:26.0 +0200
@@ -36,6 +36,14 @@
#include net/iw_handler.h/* New driver API */
+
+static void prism54_wpa_ie_add(islpci_private *priv, u8 *bssid,
+ u8 *wpa_ie, size_t wpa_ie_len);
+static size_t prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie);
+static int prism54_set_wpa(struct net_device *, struct iw_request_info *,
+ __u32 *, char *);
+
+
/**
* prism54_mib_mode_helper - MIB change mode helper function
* @mib: the struct islpci_mib object to modify
@@ -47,7 +55,7 @@
* Wireless API modes to Device firmware modes. It also checks for
* correct valid Linux wireless modes.
*/
-int
+static int
prism54_mib_mode_helper(islpci_private *priv, u32 iw_mode)
{
u32 config = INL_CONFIG_MANUALRUN;
@@ -647,7 +655,7 @@
return current_ev;
}
-int
+static int
prism54_get_scan(struct net_device *ndev, struct iw_request_info *info,
struct iw_point *dwrq, char *extra)
{
@@ -1582,7 +1590,7 @@
#define MAC2STR(a) (a)[0], (a)[1], (a)[2], (a)[3], (a)[4], (a)[5]
#define MACSTR %02x:%02x:%02x:%02x:%02x:%02x
-void
+static void
prism54_wpa_ie_add(islpci_private *priv, u8 *bssid,
u8 *wpa_ie, size_t wpa_ie_len)
{
@@ -1649,7 +1657,7 @@
up(priv-wpa_sem);
}
-size_t
+static size_t
prism54_wpa_ie_get(islpci_private *priv, u8 *bssid, u8 *wpa_ie)
{
struct list_head *ptr;
@@ -1736,7 +1744,7 @@
}
}
-int
+static int
prism54_process_trap_helper(islpci_private *priv, enum oid_num_t oid,
char *data)
{
@@ -2314,7 +2322,7 @@
return ret;
}
-int
+static int
prism54_set_wpa(struct net_device *ndev, struct iw_request_info *info,
__u32 * uwrq, char *extra)
{
@@ -2358,7 +2366,7 @@
return 0;
}
-int
+static int
prism54_get_wpa(struct net_device *ndev, struct iw_request_info *info,
__u32 * uwrq, char *extra)
{
@@ -2367,7 +2375,7 @@
return 0;
}
-int
+static int
prism54_set_prismhdr(struct net_device *ndev, struct iw_request_info *info,
__u32 * uwrq, char *extra)
{
@@ -2380,7 +2388,7 @@
return 0;
}
-int
+static int
prism54_get_prismhdr(struct net_device *ndev, struct iw_request_info *info,
__u32 * uwrq, char *extra)
{
@@ -2389,7 +2397,7 @@
return 0;
}
-int
+static int
prism54_debug_oid(struct net_device *ndev, struct iw_request_info *info,
__u32 * uwrq, char *extra)
{
@@ -2401,7 +2409,7 @@
return 0;
}
-int
+static int
prism54_debug_get_oid(struct net_device *ndev, struct iw_request_info *info,
struct iw_point *data, char *extra)
{
@@ -2437,7 +2445,7 @@
return ret;
}
-int
+static int
prism54_debug_set_oid(struct net_device *ndev, struct iw_request_info *info,
struct iw_point *data, char *extra)
{
--- linux-2.6.10-rc1-mm2-full/drivers/net/wireless/prism54/islpci_dev.h.old
2004-10-30 06:58:23.0 +0200
+++
[patch libata-dev-2.6 1/1] libata: sync SMART ioctls with ATA pass thru spec (T10/04-262r7)
Update libata's SMART-related ioctl handlers to match the current
ATA command pass-through specification (T10/04-262r7). Also change
related SCSI op-code definition to match current spec.
Signed-off-by: John W. Linville [EMAIL PROTECTED]
---
Contact w/ spec author (Curtis Stevens @ Western Digital) indicates
that while a revision 8 of the spec is expected, that it is really
only a re-formatting of the text to match T10 requirements. According
to Stevens, revision 8 is expected to be the last version of the spec.
drivers/scsi/libata-scsi.c |6 --
include/scsi/scsi.h|6 +++---
2 files changed, 7 insertions(+), 5 deletions(-)
--- sata-smart-2.6/drivers/scsi/libata-scsi.c.orig 2005-02-01
16:24:01.687622085 -0500
+++ sata-smart-2.6/drivers/scsi/libata-scsi.c 2005-02-01 16:49:18.213876086
-0500
@@ -109,14 +109,16 @@ int ata_cmd_ioctl(struct scsi_device *sc
return -ENOMEM;
scsi_cmd[1] = (4 1); /* PIO Data-in */
+ scsi_cmd[2] = 0x0e; /* no off.line or cc, read from dev,
+ block count in sector count field */
sreq-sr_data_direction = DMA_FROM_DEVICE;
} else {
scsi_cmd[1] = (3 1); /* Non-data */
+ /* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
sreq-sr_data_direction = DMA_NONE;
}
scsi_cmd[0] = ATA_16;
- scsi_cmd[2] = 0x1f; /* no off.line or cc, yes all registers */
scsi_cmd[4] = args[2];
if (args[0] == WIN_SMART) { /* hack -- ide driver does this too... */
@@ -179,7 +181,7 @@ int ata_task_ioctl(struct scsi_device *s
memset(scsi_cmd, 0, sizeof(scsi_cmd));
scsi_cmd[0] = ATA_16;
scsi_cmd[1] = (3 1); /* Non-data */
- scsi_cmd[2] = 0x1f; /* no off.line or cc, yes all registers */
+ /* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
scsi_cmd[4] = args[1];
scsi_cmd[6] = args[2];
scsi_cmd[8] = args[3];
--- sata-smart-2.6/include/scsi/scsi.h.orig 2005-02-01 16:22:12.390234346
-0500
+++ sata-smart-2.6/include/scsi/scsi.h 2005-02-01 16:23:02.828491161 -0500
@@ -113,9 +113,9 @@ extern const char *const scsi_device_typ
/* values for service action in */
#defineSAI_READ_CAPACITY_16 0x10
-/* Temporary values for T10/04-262 until official values are allocated */
-#defineATA_160x85 /* 16-byte pass-thru [0x85 ==
unused]*/
-#defineATA_120xb3 /* 12-byte pass-thru [0xb3 ==
obsolete set limits command] */
+/* Values for T10/04-262r7 */
+#defineATA_160x85 /* 16-byte pass-thru */
+#defineATA_120xa1 /* 12-byte pass-thru */
/*
* SCSI Architecture Model (SAM) Status codes. Taken from SAM-3 draft
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch libata-dev-2.6 1/1] libata: sync SMART ioctls with ATA pass thru spec (T10/04-262r7)
On Wed, Feb 02 2005, John W. Linville wrote:
Update libata's SMART-related ioctl handlers to match the current
ATA command pass-through specification (T10/04-262r7). Also change
related SCSI op-code definition to match current spec.
Signed-off-by: John W. Linville [EMAIL PROTECTED]
---
Contact w/ spec author (Curtis Stevens @ Western Digital) indicates
that while a revision 8 of the spec is expected, that it is really
only a re-formatting of the text to match T10 requirements. According
to Stevens, revision 8 is expected to be the last version of the spec.
drivers/scsi/libata-scsi.c |6 --
include/scsi/scsi.h|6 +++---
2 files changed, 7 insertions(+), 5 deletions(-)
--- sata-smart-2.6/drivers/scsi/libata-scsi.c.orig2005-02-01
16:24:01.687622085 -0500
+++ sata-smart-2.6/drivers/scsi/libata-scsi.c 2005-02-01 16:49:18.213876086
-0500
@@ -109,14 +109,16 @@ int ata_cmd_ioctl(struct scsi_device *sc
return -ENOMEM;
scsi_cmd[1] = (4 1); /* PIO Data-in */
+ scsi_cmd[2] = 0x0e; /* no off.line or cc, read from dev,
+ block count in sector count field */
sreq-sr_data_direction = DMA_FROM_DEVICE;
} else {
scsi_cmd[1] = (3 1); /* Non-data */
+ /* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
sreq-sr_data_direction = DMA_NONE;
}
scsi_cmd[0] = ATA_16;
- scsi_cmd[2] = 0x1f; /* no off.line or cc, yes all registers */
scsi_cmd[4] = args[2];
if (args[0] == WIN_SMART) { /* hack -- ide driver does this too... */
@@ -179,7 +181,7 @@ int ata_task_ioctl(struct scsi_device *s
memset(scsi_cmd, 0, sizeof(scsi_cmd));
scsi_cmd[0] = ATA_16;
scsi_cmd[1] = (3 1); /* Non-data */
- scsi_cmd[2] = 0x1f; /* no off.line or cc, yes all registers */
+ /* scsi_cmd[2] is already 0 -- no off.line, cc, or data xfer */
scsi_cmd[4] = args[1];
scsi_cmd[6] = args[2];
scsi_cmd[8] = args[3];
--- sata-smart-2.6/include/scsi/scsi.h.orig 2005-02-01 16:22:12.390234346
-0500
+++ sata-smart-2.6/include/scsi/scsi.h2005-02-01 16:23:02.828491161
-0500
@@ -113,9 +113,9 @@ extern const char *const scsi_device_typ
/* values for service action in */
#define SAI_READ_CAPACITY_16 0x10
-/* Temporary values for T10/04-262 until official values are allocated */
-#define ATA_160x85 /* 16-byte pass-thru [0x85 ==
unused]*/
-#define ATA_120xb3 /* 12-byte pass-thru [0xb3 ==
obsolete set limits command] */
+/* Values for T10/04-262r7 */
+#define ATA_160x85 /* 16-byte pass-thru */
+#define ATA_120xa1 /* 12-byte pass-thru */
Ehh are you sure that is correct? 0xa1 is the BLANK command, I would
hate to think there would be a collision like that.
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch libata-dev-2.6 1/1] libata: sync SMART ioctls with ATA pass thru spec (T10/04-262r7)
On Wed, Feb 02, 2005 at 07:51:22PM +0100, Jens Axboe wrote: On Wed, Feb 02 2005, John W. Linville wrote: -/* Temporary values for T10/04-262 until official values are allocated */ -#defineATA_160x85 /* 16-byte pass-thru [0x85 == unused]*/ -#defineATA_120xb3 /* 12-byte pass-thru [0xb3 == obsolete set limits command] */ +/* Values for T10/04-262r7 */ +#defineATA_160x85 /* 16-byte pass-thru */ +#defineATA_120xa1 /* 12-byte pass-thru */ Ehh are you sure that is correct? 0xa1 is the BLANK command, I would hate to think there would be a collision like that. Well, I'm sure that is what is in T10/04-262r7 in Table 1 on Page 1. The spec is available here: http://www.t10.org/ftp/t10/document.04/04-262r7.pdf Previous versions of the spec did not specify a value. As to whether or not the current spec is in error, hopefully Curtis can elablorate? John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] SCSI qlogicfc.c: some cleanups
This patch does the following cleanups:
- make some needlessly global functions static
- remove qlogicfc.h since it doesn't contain much
- remove the unused function isp2x00_reset
Please review especially the latter two points.
---
This patch was already sent on:
- 15 Nov 2004
drivers/scsi/qlogicfc.c | 62 ---
drivers/scsi/qlogicfc.h | 80
2 files changed, 25 insertions(+), 117 deletions(-)
--- linux-2.6.10-rc1-mm5-full/drivers/scsi/qlogicfc.h 2004-11-13
23:01:28.0 +0100
+++ /dev/null 2004-08-23 02:01:39.0 +0200
@@ -1,80 +0,0 @@
-/*
- * QLogic ISP2x00 SCSI-FCP
- *
- * Written by Erik H. Moe, [EMAIL PROTECTED]
- * Copyright 1995, Erik H. Moe
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2, or (at your option) any
- * later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- */
-
-/* Renamed and updated to 1.3.x by Michael Griffith [EMAIL PROTECTED] */
-
-/* This is a version of the isp1020 driver which was modified by
- * Chris Loveland [EMAIL PROTECTED] to support the isp2x00
- */
-
-
-/*
- * $Date: 1995/09/22 02:32:56 $
- * $Revision: 0.5 $
- *
- * $Log: isp1020.h,v $
- * Revision 0.5 1995/09/22 02:32:56 root
- * do auto request sense
- *
- * Revision 0.4 1995/08/07 04:48:28 root
- * supply firmware with driver.
- * numerous bug fixes/general cleanup of code.
- *
- * Revision 0.3 1995/07/16 16:17:16 root
- * added reset/abort code.
- *
- * Revision 0.2 1995/06/29 03:19:43 root
- * fixed biosparam.
- * added queue protocol.
- *
- * Revision 0.1 1995/06/25 01:56:13 root
- * Initial release.
- *
- */
-
-#ifndef _QLOGICFC_H
-#define _QLOGICFC_H
-
-/*
- * With the qlogic interface, every queue slot can hold a SCSI
- * command with up to 2 scatter/gather entries. If we need more
- * than 2 entries, continuation entries can be used that hold
- * another 5 entries each. Unlike for other drivers, this means
- * that the maximum number of scatter/gather entries we can
- * support at any given time is a function of the number of queue
- * slots available. That is, host-can_queue and host-sg_tablesize
- * are dynamic and _not_ independent. This all works fine because
- * requests are queued serially and the scatter/gather limit is
- * determined for each queue request anew.
- */
-
-#define DATASEGS_PER_COMMAND 2
-#define DATASEGS_PER_CONT 5
-
-#define QLOGICFC_REQ_QUEUE_LEN 255 /* must be power of two - 1 */
-#define QLOGICFC_MAX_SG(ql)(DATASEGS_PER_COMMAND + (((ql) 0) ?
DATASEGS_PER_CONT*((ql) - 1) : 0))
-#define QLOGICFC_CMD_PER_LUN8
-
-int isp2x00_detect(Scsi_Host_Template *);
-int isp2x00_release(struct Scsi_Host *);
-const char * isp2x00_info(struct Scsi_Host *);
-int isp2x00_queuecommand(Scsi_Cmnd *, void (* done)(Scsi_Cmnd *));
-int isp2x00_abort(Scsi_Cmnd *);
-int isp2x00_reset(Scsi_Cmnd *, unsigned int);
-int isp2x00_biosparam(struct scsi_device *, struct block_device *,
- sector_t, int[]);
-#endif /* _QLOGICFC_H */
--- linux-2.6.10-rc1-mm5-full/drivers/scsi/qlogicfc.c.old 2004-11-13
22:57:07.0 +0100
+++ linux-2.6.10-rc1-mm5-full/drivers/scsi/qlogicfc.c 2004-11-13
23:14:30.0 +0100
@@ -71,7 +71,25 @@
#define pci64_dma_build(hi,lo) \
((dma_addr_t)(((u64)(lo))|(((u64)(hi))32)))
-#include qlogicfc.h
+/*
+ * With the qlogic interface, every queue slot can hold a SCSI
+ * command with up to 2 scatter/gather entries. If we need more
+ * than 2 entries, continuation entries can be used that hold
+ * another 5 entries each. Unlike for other drivers, this means
+ * that the maximum number of scatter/gather entries we can
+ * support at any given time is a function of the number of queue
+ * slots available. That is, host-can_queue and host-sg_tablesize
+ * are dynamic and _not_ independent. This all works fine because
+ * requests are queued serially and the scatter/gather limit is
+ * determined for each queue request anew.
+ */
+
+#define DATASEGS_PER_COMMAND 2
+#define DATASEGS_PER_CONT 5
+
+#define QLOGICFC_REQ_QUEUE_LEN 255 /* must be power of two - 1 */
+#define QLOGICFC_MAX_SG(ql)(DATASEGS_PER_COMMAND + (((ql) 0) ?
DATASEGS_PER_CONT*((ql) - 1) : 0))
+#define QLOGICFC_CMD_PER_LUN8
/* Configuration section
*/
@@ -693,7 +711,7 @@
}
-int isp2x00_detect(Scsi_Host_Template * tmpt)
+static int isp2x00_detect(Scsi_Host_Template * tmpt)
{
int hosts = 0;
unsigned long wait_time;
@@ -1083,7 +1101,7 @@
#endif /* ISP2x00_FABRIC */
-int
[2.6 patch] SCSI sim710.c: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 15 Nov 2004
--- linux-2.6.10-rc1-mm5-full/drivers/scsi/sim710.c.old 2004-11-14
01:27:51.0 +0100
+++ linux-2.6.10-rc1-mm5-full/drivers/scsi/sim710.c 2004-11-14
01:28:48.0 +0100
@@ -47,7 +47,7 @@
#define MAX_SLOTS 8
static __u8 __initdata id_array[MAX_SLOTS] = { [0 ... MAX_SLOTS-1] = 7 };
-char *sim710; /* command line passed by insmod */
+static char *sim710; /* command line passed by insmod */
MODULE_AUTHOR(Richard Hirst);
MODULE_DESCRIPTION(Simple NCR53C710 driver);
@@ -61,7 +61,7 @@
#define ARG_SEP ','
#endif
-__init int
+static __init int
param_setup(char *str)
{
char *pos = str, *next;
@@ -314,7 +314,7 @@
differential, scsi_id);
}
-struct eisa_driver sim710_eisa_driver = {
+static struct eisa_driver sim710_eisa_driver = {
.id_table = sim710_eisa_ids,
.driver = {
.name = sim710,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] shared subtrees
On Wed, 2005-02-02 at 11:45, Mike Waychison wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ram wrote: On Tue, 2005-02-01 at 15:21, J. Bruce Fields wrote: On Tue, Jan 25, 2005 at 01:07:12PM -0800, Ram wrote: If there exists a private subtree in a larger shared subtree, what happens when the larger shared subtree is rbound to some other place? Is a new private subtree created in the new larger shared subtree? or will that be pruned out in the new larger subtree? mount --rbind will always do at least all the mounts that it did before the introduction of shared subtrees--so certainly it will copy private subtrees along with shared ones. (Since subtrees are private by default, anything else would make --rbind do nothing by default.) My understanding of Viro's RFC is that the new subtree will have no connection with the preexisting private subtree (we want private subtrees to stay private), but that the new copy will end up with whatever propagation the target of the mount --rbind had. (So the addition of the copy of the private subtree to the target vfsmount will be replicated on any vfsmount that the target vfsmount propogates to, and those copies will propagate among themselves in the same way that the copies of the target vfsmount propagate to each other.) ok. that makes sense. As you said the private subtree shall get copied to the new location, however propogations wont be set in either directions. However I have a rather unusual requirement which forces multiple rbind of a shared subtree within the same shared subtree. I did the calculation and found that the tree simply explodes with vfsstructs. If I mark a subtree within the larger shared tree as private, then the number of vfsstructs grows linearly O(n). However if there was a way of marking a subtree within the larger shared tree as unclonable than the increase in number of vfsstruct is constant. What I am essentially driving at is, can we add another feature which allows me to mark a subtree as unclonable? Read below to see how the tree explodes: to run you through an example: (In case the tree pictures below gets garbled, it can also be seen at http://www.sudhaa.com/~ram/readahead/sharedsubtree/subtree ) step 1: lets say the root tree has just two directories with one vfsstruct. root /\ tmpusr All I want is to be able to see the entire root tree (but not anything under /root/tmp) to be viewable under /root/tmp/m* step2: mount --make-shared /root mkdir -p /tmp/m1 mount --rbind /root /tmp/m1 the new tree now looks like this: root /\ tmpusr / m1 / \ tmp usr / m1 it has two vfsstructs step3: mkdir -p /tmp/m2 mount --rbind /root /tmp/m2 At this step, you probably shouldn't be using --rbind, but --bind instead to only bind a copy of the root vfsmount, so it now looks like: root /\ tmp usr /\ m1 m2 / \ / \ tmp usr tmp usr / \ / \ m1 m2 m1 m2 Well I thought about this. Even Bruce Fields suggested this in a private thread. But this solution can be racy. You may have to do multiple binds for all the vfstructs that reside in the subtree under / (but not under /root/tmp). And doing it atomically without racing with other simultaneous mounts would be tricky. RP - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAS3ndQs4kOxk3/MRAm/qAJ0awCE49/g+HhMdX0MBZnFLSp2IjACgj5EQ El+YLq25hQeDAt9Y92nqoAU= =so+d -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] shared subtrees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ram wrote: On Tue, 2005-02-01 at 15:21, J. Bruce Fields wrote: On Tue, Jan 25, 2005 at 01:07:12PM -0800, Ram wrote: If there exists a private subtree in a larger shared subtree, what happens when the larger shared subtree is rbound to some other place? Is a new private subtree created in the new larger shared subtree? or will that be pruned out in the new larger subtree? mount --rbind will always do at least all the mounts that it did before the introduction of shared subtrees--so certainly it will copy private subtrees along with shared ones. (Since subtrees are private by default, anything else would make --rbind do nothing by default.) My understanding of Viro's RFC is that the new subtree will have no connection with the preexisting private subtree (we want private subtrees to stay private), but that the new copy will end up with whatever propagation the target of the mount --rbind had. (So the addition of the copy of the private subtree to the target vfsmount will be replicated on any vfsmount that the target vfsmount propogates to, and those copies will propagate among themselves in the same way that the copies of the target vfsmount propagate to each other.) ok. that makes sense. As you said the private subtree shall get copied to the new location, however propogations wont be set in either directions. However I have a rather unusual requirement which forces multiple rbind of a shared subtree within the same shared subtree. I did the calculation and found that the tree simply explodes with vfsstructs. If I mark a subtree within the larger shared tree as private, then the number of vfsstructs grows linearly O(n). However if there was a way of marking a subtree within the larger shared tree as unclonable than the increase in number of vfsstruct is constant. What I am essentially driving at is, can we add another feature which allows me to mark a subtree as unclonable? Read below to see how the tree explodes: to run you through an example: (In case the tree pictures below gets garbled, it can also be seen at http://www.sudhaa.com/~ram/readahead/sharedsubtree/subtree ) step 1: lets say the root tree has just two directories with one vfsstruct. root /\ tmpusr All I want is to be able to see the entire root tree (but not anything under /root/tmp) to be viewable under /root/tmp/m* step2: mount --make-shared /root mkdir -p /tmp/m1 mount --rbind /root /tmp/m1 the new tree now looks like this: root /\ tmpusr / m1 / \ tmp usr / m1 it has two vfsstructs step3: mkdir -p /tmp/m2 mount --rbind /root /tmp/m2 At this step, you probably shouldn't be using --rbind, but --bind instead to only bind a copy of the root vfsmount, so it now looks like: root /\ tmp usr /\ m1 m2 / \ / \ tmp usr tmp usr / \ / \ m1 m2 m1 m2 - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAS3ndQs4kOxk3/MRAm/qAJ0awCE49/g+HhMdX0MBZnFLSp2IjACgj5EQ El+YLq25hQeDAt9Y92nqoAU= =so+d -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] SCSI qlogicisp.c: some cleanups
This patch does the following cleanups:
- make some needlessly global functions static
- remove qlogicisp.h since it doesn't contain much
- remove the unused functions isp1020_abort and isp1020_reset
Please review especially the latter two points.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 15 Nov 2004
drivers/scsi/qlogicisp.c | 99 +++
drivers/scsi/qlogicisp.h | 69 ---
2 files changed, 20 insertions(+), 148 deletions(-)
--- linux-2.6.10-rc1-mm5-full/drivers/scsi/qlogicisp.h 2004-11-13
23:03:31.0 +0100
+++ /dev/null 2004-08-23 02:01:39.0 +0200
@@ -1,69 +0,0 @@
-/*
- * QLogic ISP1020 Intelligent SCSI Processor Driver (PCI)
- * Written by Erik H. Moe, [EMAIL PROTECTED]
- * Copyright 1995, Erik H. Moe
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2, or (at your option) any
- * later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- */
-
-/* Renamed and updated to 1.3.x by Michael Griffith [EMAIL PROTECTED] */
-
-/*
- * $Date: 1995/09/22 02:32:56 $
- * $Revision: 0.5 $
- *
- * $Log: isp1020.h,v $
- * Revision 0.5 1995/09/22 02:32:56 root
- * do auto request sense
- *
- * Revision 0.4 1995/08/07 04:48:28 root
- * supply firmware with driver.
- * numerous bug fixes/general cleanup of code.
- *
- * Revision 0.3 1995/07/16 16:17:16 root
- * added reset/abort code.
- *
- * Revision 0.2 1995/06/29 03:19:43 root
- * fixed biosparam.
- * added queue protocol.
- *
- * Revision 0.1 1995/06/25 01:56:13 root
- * Initial release.
- *
- */
-
-#ifndef _QLOGICISP_H
-#define _QLOGICISP_H
-
-/*
- * With the qlogic interface, every queue slot can hold a SCSI
- * command with up to 4 scatter/gather entries. If we need more
- * than 4 entries, continuation entries can be used that hold
- * another 7 entries each. Unlike for other drivers, this means
- * that the maximum number of scatter/gather entries we can
- * support at any given time is a function of the number of queue
- * slots available. That is, host-can_queue and host-sg_tablesize
- * are dynamic and _not_ independent. This all works fine because
- * requests are queued serially and the scatter/gather limit is
- * determined for each queue request anew.
- */
-#define QLOGICISP_REQ_QUEUE_LEN63 /* must be power of two - 1 */
-#define QLOGICISP_MAX_SG(ql) (4 + ((ql) 0) ? 7*((ql) - 1) : 0)
-
-int isp1020_detect(Scsi_Host_Template *);
-int isp1020_release(struct Scsi_Host *);
-const char * isp1020_info(struct Scsi_Host *);
-int isp1020_queuecommand(Scsi_Cmnd *, void (* done)(Scsi_Cmnd *));
-int isp1020_abort(Scsi_Cmnd *);
-int isp1020_reset(Scsi_Cmnd *, unsigned int);
-int isp1020_biosparam(struct scsi_device *, struct block_device *,
- sector_t, int[]);
-#endif /* _QLOGICISP_H */
--- linux-2.6.10-rc1-mm5-full/drivers/scsi/qlogicisp.c.old 2004-11-13
23:00:09.0 +0100
+++ linux-2.6.10-rc1-mm5-full/drivers/scsi/qlogicisp.c 2004-11-13
23:14:07.0 +0100
@@ -37,7 +37,21 @@
#include asm/byteorder.h
#include scsi.h
#include scsi/scsi_host.h
-#include qlogicisp.h
+
+/*
+ * With the qlogic interface, every queue slot can hold a SCSI
+ * command with up to 4 scatter/gather entries. If we need more
+ * than 4 entries, continuation entries can be used that hold
+ * another 7 entries each. Unlike for other drivers, this means
+ * that the maximum number of scatter/gather entries we can
+ * support at any given time is a function of the number of queue
+ * slots available. That is, host-can_queue and host-sg_tablesize
+ * are dynamic and _not_ independent. This all works fine because
+ * requests are queued serially and the scatter/gather limit is
+ * determined for each queue request anew.
+ */
+#define QLOGICISP_REQ_QUEUE_LEN63 /* must be power of two - 1 */
+#define QLOGICISP_MAX_SG(ql) (4 + ((ql) 0) ? 7*((ql) - 1) : 0)
/* Configuration section */
@@ -655,7 +669,7 @@
}
-int isp1020_detect(Scsi_Host_Template *tmpt)
+static int isp1020_detect(Scsi_Host_Template *tmpt)
{
int hosts = 0;
struct Scsi_Host *host;
@@ -736,7 +750,7 @@
}
-int isp1020_release(struct Scsi_Host *host)
+static int isp1020_release(struct Scsi_Host *host)
{
struct isp1020_hostdata *hostdata;
@@ -757,7 +771,7 @@
}
-const char *isp1020_info(struct Scsi_Host *host)
+static const char *isp1020_info(struct Scsi_Host *host)
{
static char buf[80];
struct isp1020_hostdata *hostdata;
@@ -783,7 +797,7 @@
* interrupt handler may
Re: [RFC] shared subtrees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ram wrote: On Wed, 2005-02-02 at 11:45, Mike Waychison wrote: Ram wrote: On Tue, 2005-02-01 at 15:21, J. Bruce Fields wrote: On Tue, Jan 25, 2005 at 01:07:12PM -0800, Ram wrote: If there exists a private subtree in a larger shared subtree, what happens when the larger shared subtree is rbound to some other place? Is a new private subtree created in the new larger shared subtree? or will that be pruned out in the new larger subtree? mount --rbind will always do at least all the mounts that it did before the introduction of shared subtrees--so certainly it will copy private subtrees along with shared ones. (Since subtrees are private by default, anything else would make --rbind do nothing by default.) My understanding of Viro's RFC is that the new subtree will have no connection with the preexisting private subtree (we want private subtrees to stay private), but that the new copy will end up with whatever propagation the target of the mount --rbind had. (So the addition of the copy of the private subtree to the target vfsmount will be replicated on any vfsmount that the target vfsmount propogates to, and those copies will propagate among themselves in the same way that the copies of the target vfsmount propagate to each other.) ok. that makes sense. As you said the private subtree shall get copied to the new location, however propogations wont be set in either directions. However I have a rather unusual requirement which forces multiple rbind of a shared subtree within the same shared subtree. I did the calculation and found that the tree simply explodes with vfsstructs. If I mark a subtree within the larger shared tree as private, then the number of vfsstructs grows linearly O(n). However if there was a way of marking a subtree within the larger shared tree as unclonable than the increase in number of vfsstruct is constant. What I am essentially driving at is, can we add another feature which allows me to mark a subtree as unclonable? Read below to see how the tree explodes: to run you through an example: (In case the tree pictures below gets garbled, it can also be seen at http://www.sudhaa.com/~ram/readahead/sharedsubtree/subtree ) step 1: lets say the root tree has just two directories with one vfsstruct. root /\ tmpusr All I want is to be able to see the entire root tree (but not anything under /root/tmp) to be viewable under /root/tmp/m* step2: mount --make-shared /root mkdir -p /tmp/m1 mount --rbind /root /tmp/m1 the new tree now looks like this: root /\ tmpusr / m1 / \ tmp usr / m1 it has two vfsstructs step3: mkdir -p /tmp/m2 mount --rbind /root /tmp/m2 At this step, you probably shouldn't be using --rbind, but --bind instead to only bind a copy of the root vfsmount, so it now looks like: root /\ tmp usr /\ m1 m2 / \ / \ tmp usr tmp usr / \ / \ m1 m2 m1 m2 Well I thought about this. Even Bruce Fields suggested this in a private thread. But this solution can be racy. You may have to do multiple binds for all the vfstructs that reside in the subtree under / (but not under /root/tmp). And doing it atomically without racing with other simultaneous mounts would be tricky. Well, fwiw, I have the same kind of race in autofsng. I counter it by building up the vfsmount tree elsewhere and mount --move'ing it. Unfortunately, the RFC states that moving a shared vfsmount is prohibited (for which the reasoning slips my mind). - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAUFQdQs4kOxk3/MRAksjAJ4wCzY7jc8aUGKeiHKTywFKxhN1qACeI4HM eO3XGtYgnbOZJYT3K1nbKd4= =wwuF -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] shared subtrees
On Wed, Feb 02, 2005 at 04:08:32PM -0500, Mike Waychison wrote: Well, fwiw, I have the same kind of race in autofsng. I counter it by building up the vfsmount tree elsewhere and mount --move'ing it. Unfortunately, the RFC states that moving a shared vfsmount is prohibited (for which the reasoning slips my mind). See http://marc.theaimsgroup.com/?l=linux-fsdevelm=110594248826226w=2 As I understand it, the problem isn't sharing of the vfsmount being moved, but sharing of the vfsmount on which that vfsmount is mounted.--b. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] shared subtrees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 J. Bruce Fields wrote: On Wed, Feb 02, 2005 at 04:08:32PM -0500, Mike Waychison wrote: Well, fwiw, I have the same kind of race in autofsng. I counter it by building up the vfsmount tree elsewhere and mount --move'ing it. Unfortunately, the RFC states that moving a shared vfsmount is prohibited (for which the reasoning slips my mind). See http://marc.theaimsgroup.com/?l=linux-fsdevelm=110594248826226w=2 As I understand it, the problem isn't sharing of the vfsmount being moved, but sharing of the vfsmount on which that vfsmount is mounted.--b. Okay, thanks for the refresher. That still keeps you from using the 'build tree elsewhere' and 'mount - --move' approach though, as the parent mountpoint would likely be shared. - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAUcUdQs4kOxk3/MRAubGAJ0fUrpVS9U5oQof5jv4JieVOo6JjwCgjHXa oHcjXLEV5zj4OrB+TEipQdY= =3hhk -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] shared subtrees
On Wed, Feb 02, 2005 at 04:33:08PM -0500, Mike Waychison wrote: That still keeps you from using the 'build tree elsewhere' and 'mount - --move' approach though, as the parent mountpoint would likely be shared. I believe it's also just the source mountpoint that's the problem, not the destination; does that help? --Bruce Fields - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: [PATCH-2.6] Add helper function to lock multiple page cache pages.
Anton Altaparmakov [EMAIL PROTECTED] wrote: Below is a patch which adds a function mm/filemap.c::find_or_create_pages(), locks a range of pages. Please see the function description in the patch for details. This isn't very nice, is it, really? Kind of a square peg in a round hole. If you took the approach of defining a custom file_operations.write() then I'd imagine that the write() side of things would fall out fairly neatly: no need for s_umount and i_sem needs to be taken anyway. No trylocking. And for the vmscan-writepage() side of things I wonder if it would be possible to overload the mapping's -nopage handler. If the target page lies in a hole, go off and allocate all the necessary pagecache pages, zero them, mark them dirty? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] IDE: remove WAIT_READY dependency on APM
applied, sorry for the delay - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Announce] megaraid_mbox 2.20.4.4 patch
On Wed, 2005-02-02 at 10:56 -0500, Ju, Seokmann wrote: + .sdev_attrs = megaraid_device_attrs, + .shost_attrs= megaraid_class_device_attrs, These are, perhaps, slightly confusing names. The terms device and class_device have well defined meanings in the generic device model, neither of which is what you mean here. Why not simply megaraid_sdev_attrs and megaraid_shost_attrs? Other than this, it looks fine to me too. James - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch libata-dev-2.6 1/1] libata: sync SMART ioctls with ATA pass thru spec (T10/04-262r7)
Jens Axboe wrote: snip -/* Temporary values for T10/04-262 until official values are allocated */ -#define ATA_160x85 /* 16-byte pass-thru [0x85 == unused]*/ -#define ATA_120xb3 /* 12-byte pass-thru [0xb3 == obsolete set limits command] */ +/* Values for T10/04-262r7 */ +#define ATA_160x85 /* 16-byte pass-thru */ +#define ATA_120xa1 /* 12-byte pass-thru */ Ehh are you sure that is correct? 0xa1 is the BLANK command, I would hate to think there would be a collision like that. That very point came up recently in a MMC meeting: http://www.t10.org/ftp/t10/document.05/05-056r0.pdf To confuse things further ATA_16 is shown as opcode 0x98 in the latest draft of SPC-3 (rev 21c 15 January 2005) http://www.t10.org/ftp/t10/drafts/spc3/spc3r21c.pdf [annex D.3.1]. Hopefully these matters will be sorted out at the next t10 meeting in March. Doug Gilbert - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] IDE: possible cleanups
On Mon, 31 Jan 2005 20:01:54 +0100, Adrian Bunk [EMAIL PROTECTED] wrote: This patch contains the following possible cleanups: - make some needlessly global code static - ide-dma.c: remove the unneeded EXPORT_SYMBOL(__ide_dma_test_irq) Signed-off-by: Adrian Bunk [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch libata-dev-2.6 1/1] libata: sync SMART ioctls with ATA pass thru spec (T10/04-262r7)
Douglas Gilbert wrote: Hopefully these matters will be sorted out at the next t10 meeting in March. So that means I have to hold off releasing SMART support for SATA for yet another couple months? Oh well... Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 01/29] ide: remove adma100
On Wed, 2 Feb 2005 11:43:53 +0900, Tejun Heo [EMAIL PROTECTED] wrote: 01_ide_remove_adma100.patch Removes drivers/ide/pci/adma100.[hc]. The driver isn't compilable (missing functions) and no Kconfig actually enables CONFIG_BLK_DEV_ADMA100. Signed-off-by: Tejun Heo [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 02/29] ide: cleanup it8172
On Wed, 2 Feb 2005 11:44:54 +0900, Tejun Heo [EMAIL PROTECTED] wrote:
02_ide_cleanup_it8172.patch
In drivers/ide/pci/it8172.h, it8172_ratefilter() and
init_setup_it8172() are declared and the latter is referenced
in it8172_chipsets. Both functions are not defined or used
anywhere. This patch removes the prototypes and reference.
it8172 should be compilable now.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
applied, also this trivial patch is needed to fix it8172 build:
diff -Nru a/drivers/ide/pci/it8172.c b/drivers/ide/pci/it8172.c
--- a/drivers/ide/pci/it8172.c 2005-02-03 01:00:22 +01:00
+++ b/drivers/ide/pci/it8172.c 2005-02-03 01:00:22 +01:00
@@ -56,7 +56,7 @@
{
ide_hwif_t *hwif= HWIF(drive);
struct pci_dev *dev = hwif-pci_dev;
- int is_slave= (hwif-drives[1] == drive);
+ int is_slave= (hwif-drives[1] == drive);
unsigned long flags;
u16 drive_enables;
u32 drive_timing;
@@ -94,7 +94,7 @@
}
pci_write_config_word(dev, 0x40, drive_enables);
- spin_unlock_irqrestore(ide_lock, flags)
+ spin_unlock_irqrestore(ide_lock, flags);
}
static u8 it8172_dma_2_pio (u8 xfer_rate)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 03/29] ide: cleanup opti621
On Wed, 2 Feb 2005 11:45:38 +0900, Tejun Heo [EMAIL PROTECTED] wrote: 03_ide_cleanup_opti621.patch In drivers/ide/pci/opti612.[hc], init_setup_opt621() is declared, defined and referenced but never actullay used. Thie patch removes the function. Signed-off-by: Tejun Heo [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 06/29] ide: IDE_CONTROL_REG cleanup
On Wed, 2 Feb 2005 11:48:30 +0900, Tejun Heo [EMAIL PROTECTED] wrote: 06_ide_start_request_IDE_CONTROL_REG.patch Replaced HWIF(drive)-io_ports[IDE_CONTROL_OFFSET] with equivalent IDE_CONTROL_REG in ide-io.c. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Index: linux-ide-export/drivers/ide/ide-io.c === --- linux-ide-export.orig/drivers/ide/ide-io.c 2005-02-02 10:27:15.996184821 +0900 +++ linux-ide-export/drivers/ide/ide-io.c 2005-02-02 10:28:03.340503581 +0900 @@ -884,7 +884,7 @@ static ide_startstop_t start_request (id if (rc) printk(KERN_WARNING %s: bus not ready on wakeup\n, drive-name); SELECT_DRIVE(drive); - HWIF(drive)-OUTB(8, HWIF(drive)-io_ports[IDE_CONTROL_OFFSET]); + HWIF(drive)-OUTB(8, IDE_CONTROL_REG); rc = ide_wait_not_busy(HWIF(drive), 1); if (rc) printk(KERN_WARNING %s: drive not ready on wakeup\n, drive-name); IDE_CONTROL_REG macro and co. are obfuscations and should die... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 10/29] ide: __ide_do_rw_disk() return value fix
On Wed, 2 Feb 2005 11:52:48 +0900, Tejun Heo [EMAIL PROTECTED] wrote: 10_ide_do_rw_disk_pre_task_out_intr_return_fix.patch In __ide_do_rw_disk(), ide_started used to be returned blindly after issusing PIO write. This can cause hang if pre_task_out_intr() returns ide_stopped due to failed ide_wait_stat() test. Fixed to pass the return value of pre_task_out_intr(). Signed-off-by: Tejun Heo [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 12/29] ide: add ide_hwgroup_t.polling
On Wed, 2 Feb 2005 11:55:38 +0900, Tejun Heo [EMAIL PROTECTED] wrote: 12_ide_hwgroup_t_polling.patch ide_hwgroup_t.polling field added. 0 in poll_timeout field used to indicate inactive polling but because 0 is a valid jiffy value, though slim, there's a chance that something weird can happen. Is there really a possibility of something weird? I'm not claiming that I like this way of coding but poll_timeout is assigned either to '0' or to 'jiffies + WAIT_WORSTCASE'. Bartlomiej - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 11/29] ide: add ide_drive_t.sleeping
On Wed, 2 Feb 2005 11:54:48 +0900, Tejun Heo [EMAIL PROTECTED] wrote:
11_ide_drive_sleeping_fix.patch
ide_drive_t.sleeping field added. 0 in sleep field used to
indicate inactive sleeping but because 0 is a valid jiffy
value, though slim, there's a chance that something can go
weird. And while at it, explicit jiffy comparisons are
converted to use time_{after|before} macros.
Same question as for add ide_hwgroup_t.polling patch.
AFAICS drive-sleep is either '0' or 'timeout + jiffies' (always 0)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 09/29] ide: __ide_do_rw_disk() lba48 dma check fix
On Wed, 2 Feb 2005 11:51:42 +0900, Tejun Heo [EMAIL PROTECTED] wrote: 09_ide_do_rw_disk_lba48_dma_check_fix.patch In __ide_do_rw_disk(), the shifted block, instead of the original rq-sector, should be used when checking range for lba48 dma. Signed-off-by: Tejun Heo [EMAIL PROTECTED] good catch! applied - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 13/29] ide: use time_after() macro
On Wed, 2 Feb 2005 11:56:49 +0900, Tejun Heo [EMAIL PROTECTED] wrote: 13_ide_tape_time_after.patch Explicit jiffy comparision converted to time_after() macro. Signed-off-by: Tejun Heo [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arp_queue: serializing unlink + kfree_skb
On Mon, 31 Jan 2005 22:33:26 +1100
Herbert Xu [EMAIL PROTECTED] wrote:
We're using atomic integers to signal that we're done with an object.
The object is usually represented by a piece of memory.
The problem is that in most of the places where we do this (and that's
not just in the networking systems), there are no memory barriers between
the last reference to that object and the decrease on the atomic counter.
I agree.
if (atomic_read(skb-users) != 1) {
smp_mb__before_atomic_dec();
if (!atomic_dec_and_test(skb-users))
return;
}
__kfree_skb(skb);
This looks good. Olaf can you possibly ask the reproducer if
this patch makes the ARP problem go away?
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/02 15:53:55-08:00 [EMAIL PROTECTED]
# [NET]: Add missing memory barrier to SKB release.
#
# Here, we are using atomic counters to signal that we are done
# with an object. The object is usually represented by a piece
# of memory.
#
# The problem is that in most of the places we do this, there are
# no memory barriers between the last reference to that object
# and the decrease on the atomic counter.
#
# Based upon a race spotted in arp_queue handling by Olaf Kirch.
#
# Signed-off-by: David S. Miller [EMAIL PROTECTED]
#
# include/linux/skbuff.h
# 2005/02/02 15:51:57-08:00 [EMAIL PROTECTED] +6 -2
# [NET]: Add missing memory barrier to SKB release.
#
diff -Nru a/include/linux/skbuff.h b/include/linux/skbuff.h
--- a/include/linux/skbuff.h2005-02-02 15:54:13 -08:00
+++ b/include/linux/skbuff.h2005-02-02 15:54:13 -08:00
@@ -353,8 +353,12 @@
*/
static inline void kfree_skb(struct sk_buff *skb)
{
- if (atomic_read(skb-users) == 1 || atomic_dec_and_test(skb-users))
- __kfree_skb(skb);
+ if (atomic_read(skb-users) != 1) {
+ smp_mb__before_atomic_dec();
+ if (!atomic_dec_and_test(skb-users))
+ return;
+ }
+ __kfree_skb(skb);
}
/* Use this if you didn't touch the skb state [for fast switching] */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ipv4 routing: splitting of ip_route_[in|out]put_slow, 2.6.10-rc3
On Mon, 20 Dec 2004 12:13:24 +0100 Einar Lück [EMAIL PROTECTED] wrote: This patch splits up ip_route_[in|out]put_slow in inlined functions. Basic idea: * improve overall comprehensibility * allow for an easier application of patch for improved multipath support Patch applied to my 2.6.12 pending tree. Thanks a lot Einar. One minor comment is that there are some minor cases where excessing in_dev get/put can be eliminated. For example, in __mkroute_output() we really only need to do the in_dev_get(dev_out) once, yet we do it twice due to how the return path of this function always puts the reference even in the non-error case. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 14/29] ide: remove NULL checking in ide_error()
On Wed, 2 Feb 2005 11:57:28 +0900, Tejun Heo [EMAIL PROTECTED] wrote: 14_ide_error_remove_NULL_test.patch In ide_error(), drive cannot be NULL. ide_dump_status() can't handle NULL drive. applied, you missed Signed-off-by line - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 18/29] ide: comment fixes
On Wed, 2 Feb 2005 12:02:54 +0900, Tejun Heo [EMAIL PROTECTED] wrote: 18_ide_comment_fixes.patch Comment fixes. Signed-off-by: Tejun Heo [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 0/29] ide: driver updates
On Wed, 2 Feb 2005 11:40:17 +0900, Tejun Heo [EMAIL PROTECTED] wrote: Hello, B. Zolnierkiewicz. Hi, These patches are various fixes/improvements to the ide driver. They are against the 2.6 bk tree as of today (20050202). Nice series. As you probably already know I merged most of the easy stuff. I will comment on the real stuff soon. Thanks, Bartlomiej - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3
On Mon, 20 Dec 2004 12:19:43 +0100 Einar Lück [EMAIL PROTECTED] wrote: This patch is an approach towards solving some problems with the current multipath implementation: * routing cache allows only one route to be cached for a certain search key * a mulitpath/load balancing decision is only made in case a corresponding route is not yet cached In the scenarios, that are relevant to us (high amount of outgoing connection requests), this is a serious problem. I agree that per-connection attempt a new multipath decision should be made, but within a flow I disagree. This needs to be flow based. Can you describe more precisely the scenerios, that are relevant to us? If you are only interested in more precise multipathing when TCP connections on the local system are made, this we can implement via a flag to the ipv4 routing cache which forces a new multipath decision when TCP sockets have their identity established. We have a precise interface that is invoked at this time, called ip_route_connect(). So that is where we would pass in some flag to indicate that we desire the new multipath behavior. If you want this behavior on a router, you will need to mark the packets using something like firewall marking on the SKB, then this mark would be used at route cache lookup time to determine what kind of multipath decisions to make. There is no way we can enable the new behavior for every routing cache lookup. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 04/29] ide: cleanup piix
On Wed, 2 Feb 2005 11:46:11 +0900, Tejun Heo [EMAIL PROTECTED] wrote: 04_ide_cleanup_piix.patch In drivers/ide/pci/piix.[hc], init_setup_piix() is defined and used but only one init_setup function is defined and no demultiplexing is done using init_setup callback. As other drivers call ide_setup_pci_device() directly in such cases, this patch removes init_setup_piix() and makes piix_init_one() call ide_setup_pci_device() directly. Signed-off-by: Tejun Heo [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] 4/7 replace uml_strdup by kstrdup
Pekka Enberg wrote: On Tue, 1 Feb 2005 03:28:31 +, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: diff -buprN -X dontdiff vanilla-2.6.11-rc2-bk9/arch/um/os-Linux/drivers/tuntap_user.c linux-2.6.11-rc2-bk9/arch/um/os-Linux/drivers/tuntap_user.c --- vanilla-2.6.11-rc2-bk9/arch/um/os-Linux/drivers/tuntap_user.c 2004-12-24 21:35:40.0 + +++ linux-2.6.11-rc2-bk9/arch/um/os-Linux/drivers/tuntap_user.c 2005-01-31 20:39:08.591154025 + [snip] - pri-dev_name = uml_strdup(buffer); + pri-dev_name = kstrdup(buffer); Please compile-test before submitting. I'm really sorry about this... I've compiled with an allyesconfig to validate the changes, but that doesn't build the UML parts :( Anyway, thanks for pointing this out. I still haven't got feedback regarding the acceptance of these patches. If there is a chance they're accepted, maybe the best thing to do is to post the series again with this correction and the sound patch corrections. -- Paulo Marques - www.grupopie.com All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
driver model: fix types in usb
Hi!
From: Bernard Blackham [EMAIL PROTECTED]
This fixes types in USB w.r.t. driver model. It should not actually
change any code. Please apply,
Pavel
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
diff -ru linux-2.6.11-rc2-2.1.5.15/drivers/usb/core/hub.c
linux-2.6.11-rc2-2.1.5.16/drivers/usb/core/hub.c
--- linux-2.6.11-rc2-2.1.5.15/drivers/usb/core/hub.c2005-01-30
13:37:32.0 +0800
+++ linux-2.6.11-rc2-2.1.5.16/drivers/usb/core/hub.c2005-02-02
22:30:48.0 +0800
@@ -1235,10 +1235,10 @@
*/
if (udev-bus-b_hnp_enable || udev-bus-is_b_host) {
static int __usb_suspend_device (struct usb_device *,
- int port1, u32 state);
+ int port1, pm_message_t state);
err = __usb_suspend_device(udev,
udev-bus-otg_port,
- PM_SUSPEND_MEM);
+ PMSG_SUSPEND);
if (err 0)
dev_dbg(udev-dev, HNP fail, %d\n, err);
}
@@ -1523,7 +1523,7 @@
* Linux (2.6) currently has NO mechanisms to initiate that: no khubd
* timer, no SRP, no requests through sysfs.
*/
-int __usb_suspend_device (struct usb_device *udev, int port1, u32 state)
+int __usb_suspend_device (struct usb_device *udev, int port1, pm_message_t
state)
{
int status;
@@ -1621,7 +1621,7 @@
/**
* usb_suspend_device - suspend a usb device
* @udev: device that's no longer in active use
- * @state: PM_SUSPEND_MEM to suspend
+ * @state: PMSG_SUSPEND to suspend
* Context: must be able to sleep; device not locked
*
* Suspends a USB device that isn't in active use, conserving power.
@@ -1670,7 +1670,7 @@
usb_set_device_state(udev, udev-actconfig
? USB_STATE_CONFIGURED
: USB_STATE_ADDRESS);
- udev-dev.power.power_state = PM_SUSPEND_ON;
+ udev-dev.power.power_state = PMSG_ON;
/* 10.5.4.5 says be sure devices in the tree are still there.
* For now let's assume the device didn't go crazy on resume,
@@ -1871,7 +1871,7 @@
return status;
}
-static int hub_suspend(struct usb_interface *intf, u32 state)
+static int hub_suspend(struct usb_interface *intf, pm_message_t state)
{
struct usb_hub *hub = usb_get_intfdata (intf);
struct usb_device *hdev = hub-hdev;
@@ -1943,7 +1943,7 @@
}
up(udev-serialize);
}
- intf-dev.power.power_state = PM_SUSPEND_ON;
+ intf-dev.power.power_state = PMSG_ON;
hub_activate(hub);
return 0;
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pci: Arch hook to determine config space size
On Dinsdag 01 Februar 2005 05:57, Benjamin Herrenschmidt wrote:
BTW. I'm thinking about moving all those PCI/VIO related fields out of
struct device_node to their own structure and keep only a pointer to
that structure in device_node. That way, we avoid the bloat for every
single non-pci node in the system, and we can have different structures
for different bus types (along with proper iommu function pointers and
that sort-of-thing).
How about something along the lines of this patch? Instead of adding a
pointer to the pci data from the device node, it embeds the node inside
a new struct pci_device_node. The patch is not complete and therefore
not expected to work as is, but maybe you want to reuse it.
The interesting part that is missing is creating and destroying
pci_device_nodes in prom.c, maybe you have an idea how to do that.
I'm also not sure about eeh. Are the eeh functions known to be called
only for device_nodes of PCI devices? If not, eeh_mode and
eeh_config_addr might have to stay inside of device_node.
Arnd
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6-64/arch/ppc64/kernel/pci.h
===
--- linux-2.6-64.orig/arch/ppc64/kernel/pci.h 2005-01-24 23:46:37.0
+0100
+++ linux-2.6-64/arch/ppc64/kernel/pci.h2005-02-02 00:11:01.485740824
+0100
@@ -29,8 +29,8 @@
/* PCI device_node operations */
struct device_node;
-typedef void *(*traverse_func)(struct device_node *me, void *data);
-void *traverse_pci_devices(struct device_node *start, traverse_func pre,
+typedef void *(*traverse_func)(struct pci_device_node *me, void *data);
+void *traverse_pci_devices(struct pci_device_node *start, traverse_func pre,
void *data);
void pci_devs_phb_init(void);
Index: linux-2.6-64/arch/ppc64/kernel/pSeries_iommu.c
===
--- linux-2.6-64.orig/arch/ppc64/kernel/pSeries_iommu.c 2005-02-01
22:53:00.673332472 +0100
+++ linux-2.6-64/arch/ppc64/kernel/pSeries_iommu.c 2005-02-02
00:11:01.486740672 +0100
@@ -48,7 +48,7 @@
#define DBG(fmt...)
-extern int is_python(struct device_node *);
+extern int is_python(struct pci_device_node *);
static void tce_build_pSeries(struct iommu_table *tbl, long index,
long npages, unsigned long uaddr,
@@ -289,7 +289,7 @@
* Currently we hard code these sizes (more or less).
*/
static void iommu_table_setparms_lpar(struct pci_controller *phb,
- struct device_node *dn,
+ struct pci_device_node *dn,
struct iommu_table *tbl,
unsigned int *dma_window)
{
@@ -308,7 +308,7 @@
static void iommu_bus_setup_pSeries(struct pci_bus *bus)
{
- struct device_node *dn, *pdn;
+ struct pci_device_node *dn, *pdn;
DBG(iommu_bus_setup_pSeries, bus %p, bus-self %p\n, bus, bus-self);
@@ -331,7 +331,7 @@
DBG(Python root bus %s\n, bus-name);
- iohole = (unsigned int *)get_property(dn, io-hole, 0);
+ iohole = (unsigned int *)get_property(dn-node,
io-hole, 0);
if (iohole) {
/* On first bus we need to leave room for the
@@ -349,7 +349,7 @@
tbl = kmalloc(sizeof(struct iommu_table), GFP_KERNEL);
- iommu_table_setparms(dn-phb, dn, tbl);
+ iommu_table_setparms(dn-phb, dn-node, tbl);
dn-iommu_table = iommu_init_table(tbl);
} else {
/* 256 MB window by default */
@@ -368,7 +368,7 @@
tbl = kmalloc(sizeof(struct iommu_table), GFP_KERNEL);
- iommu_table_setparms(dn-phb, dn, tbl);
+ iommu_table_setparms(dn-phb, dn-node, tbl);
dn-iommu_table = iommu_init_table(tbl);
} else {
@@ -382,17 +382,19 @@
static void iommu_bus_setup_pSeriesLP(struct pci_bus *bus)
{
struct iommu_table *tbl;
- struct device_node *dn, *pdn;
+ struct pci_device_node *dn, *pdn;
+ struct device_node *n;
unsigned int *dma_window = NULL;
dn = pci_bus_to_OF_node(bus);
/* Find nearest ibm,dma-window, walking up the device tree */
- for (pdn = dn; pdn != NULL; pdn = pdn-parent) {
- dma_window = (unsigned int *)get_property(pdn,
ibm,dma-window, NULL);
+ for (n = dn-node; n; n = n-parent) {
+ dma_window = (unsigned int *)get_property(n, ibm,dma-window,
NULL);
if (dma_window != NULL)
break;
}
+ pdn = to_pci_node(n);
if (dma_window == NULL) {
DBG(iommu_bus_setup_pSeriesLP: bus %s seems to have no
Re: pci: Arch hook to determine config space size
On Wed, 2005-02-02 at 11:05 +0100, Arnd Bergmann wrote: How about something along the lines of this patch? Instead of adding a pointer to the pci data from the device node, it embeds the node inside a new struct pci_device_node. The patch is not complete and therefore not expected to work as is, but maybe you want to reuse it. The interesting part that is missing is creating and destroying pci_device_nodes in prom.c, maybe you have an idea how to do that. I'm also not sure about eeh. Are the eeh functions known to be called only for device_nodes of PCI devices? If not, eeh_mode and eeh_config_addr might have to stay inside of device_node. I'd rather not go that way for now. There are at least PCI and VIO devices concerned by this, and maybe more (depending on how I deal with macio devices for example). We also want, ultimately, to have the DMA routines be function pointers in this auxilliary structure. Ben.
[PATCH] InfiniBand: add missing break between cases
From: Libor Michalek [EMAIL PROTECTED] Add a missing break statement between RC and UD cases in mthca_post_send(). This fixes a possible oops for protocols that use the RC transport. Signed-off-by: Libor Michalek [EMAIL PROTECTED] Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_qp.c2005-01-28 11:11:02.0 -0800 +++ linux-bk/drivers/infiniband/hw/mthca/mthca_qp.c 2005-02-02 21:35:09.683871535 -0800 @@ -1323,6 +1323,8 @@ break; } + break; + case UD: ((struct mthca_ud_seg *) wqe)-lkey = cpu_to_be32(to_mah(wr-wr.ud.ah)-key); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
On Tue, Feb 01, 2005 at 07:15:49PM -0500, Theodore Ts'o wrote: Umm, so exactly how many applications use multithreading (or otherwise trigger the GLIBC mprotect call), For the record, I've been informed that the glibc mprotect() call doesn't happen in any modern glibc's; there may have been one buggy glibc that was released very briefly before it was fixed in the next release. But if that's what the paxtest developers are hanging their hat on, it seems awfully lame to me. desabotaged seems like the correct description from my vantage point. - Ted - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: driver model u32 - pm_message_t conversion: help needed
Pavel == Pavel Machek [EMAIL PROTECTED] writes: Pavel Hi! Two Long time ago, BenH said that making patches is easy, Pavel so I hope to get his help now... And will probably need more. Pavel Suspend routines change, slowly. Pavel - int (*suspend)(struct device * dev, u32 state); + int Pavel (*suspend)(struct device * dev, pm_message_t state); Pavel For now u32 is typedef-ed to pm_message_t, but that is not Pavel going to be the case for 2.6.12. What needs to be done is Pavel changing all state parameters from u32 to Pavel pm_message_t. suspend() functions should not use state variable Pavel for now (except for PCI ones, those are allowed to call Pavel pci_choose_state and convert state into pci_power_t, and use Pavel that). Pavel, Sorry for being late responding to this, but I'd say this is a prime example for typedef's considered evil (see Greg's OLS talk ;). It would be a lot cleaner if it was made a struct and then passing a struct pointer as the argument instead of passing the struct by value as you do right now. Pavel -static int agp_via_suspend(struct pci_dev *pdev, u32 state) Pavel +static int agp_via_suspend(struct pci_dev *pdev, pm_message_t Cheers, Jes - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is there any list like this for Linux system administration?
Hello everyone, Is there any mailing list like this for Linux system administration? Plz help me regarding this? Thanks and Regards, selva __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote: Vivek Goyal [EMAIL PROTECTED] writes: Well, trying to put the already discussed ideas together. I was planning to work on following design. Please comment. Crashed Kernel --Capture Kernel(or User Space) Interface: -- The whole idea is that Crash image is represented in ELF Core format. These ELF Headers are prepared by kexec-tools user space and put in one segment. Address of start of image is passed to the capture kernel(or user space) using one command line (eg. crashimage=). Now either kernel space or user space can parse the elf headers and extract required information and export final kernel elf core image. Sounds sane. We need to make certain there is a checksum of that region but putting it in a separate segment should ensure that. I also think we need to look at the name crashimage= and see if we can find something more descriptive. But that is minor. Possibly elfcorehdr= We have a little while to think about that one before we are stuck. elfcorehdr= also looks good. [EMAIL PROTECTED] wrote: If we were using an ELF header I would include one PT_NOTE program header per cpu (Giving each cpu it's own area to mess around in). And I would use one PT_LOAD segment per possible memory zone. So in the worst case (current sgi altix) (MAX_NUMNODES=256, MAX_NR_ZONES=3, MAX_NR_CPUS=1024) 256*3+1024 = 1792 program headers. At 56 bytes per 64bit program header that is 100352 bytes or 98KiB. A little bit expensive. A tuned data structure with 64bit base and size would only consume 1792*16 = 28672 or 28KiB. If I prepare One elf header for each physical contiguous memory area (as obtained from /proc/iomem) instead of per zone, then number of elf headers will come down significantly. A clarification on terminology we are talking about struct Elf64_Phdr here. There is only one Elf header. That seems to be clear farther down. Exactly. There shall be one Elf header for whole of the image. In addition there will be one struct Elf64_Phdr, per contiguous physical memory area. One Elf64_Phdr of PT_NOTE type for notes section and one Elf64_Phdr for backup region. I don't have any idea on number of actual physically contiguous regions present per machine, but roughly assuming it to be 1 per node, it will lead to 256 + 1024 = 1280 program headers.At 56 bytes per 64 bit program header this will amount to 70KB. This is worst case estimate and on lower end machines this will require much less a space. On machines as big as 1024 cpus, this should not be a concern, as big machines come with big RAMs. Agreed. Size is not the primary issue. There is some clear waste but that is a secondary concern. Not performing a 1-1 mapping to the kernel data structures also seems to be a win, as the concepts are noticeably different. Eric, do you still think that ELF headers are inappropriate to be passed across interface boundary. I have serious concerns about the kernel generating the ELF headers and only delivering them after the kernel has crashed. Because then we run into questions of what information can be trusted. If we avoid that issue I am not too concerned. I hope, all elf headers once prepared by kexec-tools need not to change later (Cannot think of any piece of information which shall change later). These shall be put in separate segment. And SHA-256 shall take care of authenticity of information after crash. Regarding Backup Region --- - Kexec user space does the reservation for backup region segment. - Purgatory copies the backup data to backup region. (Already implemented) - A separate elf header is prepared to represent backed up memory region. And offset field of this program header can contain the actual physical address where backup contents are stored. I like that. I was thinking a virtual versus physical address separation. But using the offset field is much more appropriate, and it leaves us the potential of doing something nice like specifying the kernels virtual address later on. Looking exclusively at the offset field to know which memory addresses to dump sounds good. For now we should have virtual==physical==offset except for the backup region. For notes section program header, virtual = physical = 0 and offset shall point to crash_notes[], so that notes can directly be read by the capture kernel (or user space). Thanks Vivek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory leak in 2.6.11-rc1?
I applied the patch and it works like a charm. As a kinky side effect: before
this patch, using a compiled-in vesa or vga16 framebuffer worked with the
proprietary nvidia driver, whereas now tty1-6 are corrupt when not using
80x25. Strangeness :)
Lennert
On Monday 24 January 2005 23:35, Linus Torvalds wrote:
On Mon, 24 Jan 2005, Andrew Morton wrote:
Would indicate that the new pipe code is leaking.
Duh. It's the pipe merging.
Linus
--- 1.40/fs/pipe.c2005-01-15 12:01:16 -08:00
+++ edited/fs/pipe.c 2005-01-24 14:35:09 -08:00
@@ -630,13 +630,13 @@
struct pipe_inode_info *info = inode-i_pipe;
inode-i_pipe = NULL;
- if (info-tmp_page)
- __free_page(info-tmp_page);
for (i = 0; i PIPE_BUFFERS; i++) {
struct pipe_buffer *buf = info-bufs + i;
if (buf-ops)
buf-ops-release(info, buf);
}
+ if (info-tmp_page)
+ __free_page(info-tmp_page);
kfree(info);
}
pgpGO7TveTbBa.pgp
Description: PGP signature
Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
Hi! Umm, so exactly how many applications use multithreading (or otherwise trigger the GLIBC mprotect call), and how many applications use nested functions (which is not ANSI C compliant, and as a result, very rare)? Do the tests both ways, and document when the dummy() re-entrant function might actually be hit in real life, and then maybe people won't feel that you are deliberately and unfairly overstating things to try to root for one security approach versus another. Well, you can already do the test both ways. There is a kiddie mode, which doesn't do this test. And a blackhat mode, which does it. Basically removing the mprotect and nested function is demoting blackhat mode into kiddie mode. Of course, with name like paxtest, maybe its only goal was propganda for the PaX way of doing things, in which case, that's fine. Well, I can understand that perception. That is, if I would have made any contributions to PaX. Fact is, I haven't contributed as much as a single ASCII character to PaX. I'm just a user of PaX, just as I am a user of the Linux kernel. Sure, I recommend other people to use PaX. Why not? It works well for me. I recommend Linux to other people. I guess that's a bad thing too, right? When I started Trusted Debian (which is what Adamantix used to be called), I looked around for security related stuff and found out about PaX. So I decided to give it a try and also the ET_DYN executable to maximise the use of ASLR (Address Space Layout Randomisation). After compiling a bunch of programs this way, I was kind of feeling uneasy. One would expect that such an intrusive kernel patch would break stuff. And PaX didn't. In fact, I didn't have any proof whether it worked or not. Since my purpose was to distribute this stuff and I am not smart enough to fully understand the kernel code, I would not be able to truthfully tell people wether this PaX stuff worked or not. So I decided to write a test-suite. Well, it tests PaX functionality, not GCC functionality or POSIX compliance, so I named it PaXtest. That is how PaXtest began. I don't understand where this ``propaganda'' mindframe comes from, but I don't have any money I make off of PaXtest, I don't have a stock price to worry about, no trademarks to defend and stuff like that. And in fact, I don't care whether you use PaXtest or not and what you think about the results. It is sufficient for me to know that they are accurately reflecting the underlying system. But if you want it to be viewed as an honest, fair, and unbaised, then make it very clear in the test results how programs with and without nested functions, and with and without multithreading, would actually behave. Ok, so how exactly do you propose to do this? Or are you afraid that someone might then say --- oh, so PaX's extra complexity is only needed if we care about programs that use nested functions --- yawn, I think we'll pass on the complexity. Is that a tradeoff that you're afraid to allow people to make with full knowledge? That's looking at this from the bottom up. I'm looking at this from a different perspective. In civil engineering, it is normal to explore worst case scenarios. Suppose you don't do that and a bridge collapses and people die. Or a plane breaks in two while flying and people die. I'm sure you agree that that is a Really Bad Thingtm, right? In the computer industry however, we mostly insist in building fragile systems. I'm just stating a fact, and not trying to imply that I'm any better than anyone else. There is a whole list of perfectly good excuses for building fragile computer systems. These systems are a risk. That's ok, as long as the risk can be managed. That is basically what most of security in the real-world (and I'm not talking about the technical level real-world here) is about: Risk management. But you can't do risk management properly, unless you know what could happen in the worst case. Otherwise you get situations which Linus described regarding the OpenWall patch, where people might get a false sense of security (note that this is also reflected in the PaXtest results when run on an OpenWall kernel). There are clear differences between how PaX and exec-shield behave in worst case situations. PaXtest shows these when you run blackhat mode but not when you run kiddie mode. And that's all there is to it. Now, what any person does with the PaXtest results, that is up to that person and not for you or me to decide. And that is why I want to stop the FUD which is being spread and to stop people from abusing their reputation as kernel developer to influence other people to cripple their copies of PaXtest, thereby removing their ability to explore the worst-case scenario. Crippling PaXtest effectively works as a form of censorship. Personally, I think the Linux community is more served by an open discussion than by censorship. But I seems some people have a different opinion
Re: driver model u32 - pm_message_t conversion: help needed
Hi! Pavel Hi! Two Long time ago, BenH said that making patches is easy, Pavel so I hope to get his help now... And will probably need more. Pavel Suspend routines change, slowly. Pavel - int (*suspend)(struct device * dev, u32 state); + int Pavel (*suspend)(struct device * dev, pm_message_t state); Pavel For now u32 is typedef-ed to pm_message_t, but that is not Pavel going to be the case for 2.6.12. What needs to be done is Pavel changing all state parameters from u32 to Pavel pm_message_t. suspend() functions should not use state variable Pavel for now (except for PCI ones, those are allowed to call Pavel pci_choose_state and convert state into pci_power_t, and use Pavel that). Sorry for being late responding to this, but I'd say this is a prime example for typedef's considered evil (see Greg's OLS talk ;). It would be a lot cleaner if it was made a struct and then passing a struct pointer as the argument instead of passing the struct by value as you do right now. Sorry, can't do that. That would require flag day and change everything at once. That is just not feasible. When things are settled, it is okay to change it to struct passed by value.. It is small anyway and at least we will not have problems with freeing it etc. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
On Wed, 2005-02-02 at 10:35 +0100, Peter Busser wrote: Hi! Umm, so exactly how many applications use multithreading (or otherwise trigger the GLIBC mprotect call), and how many applications use nested functions (which is not ANSI C compliant, and as a result, very rare)? Do the tests both ways, and document when the dummy() re-entrant function might actually be hit in real life, and then maybe people won't feel that you are deliberately and unfairly overstating things to try to root for one security approach versus another. Well, you can already do the test both ways. There is a kiddie mode, which doesn't do this test. And a blackhat mode, which does it. Basically removing the mprotect and nested function is demoting blackhat mode into kiddie mode. actually you don't. The presence of the nested function (technically, the taking of the address of a nested function) marks the PT_GNU_STACK field in the binary, not the runtime behavior. As such, paxtest does not offer any real such choice in behavior. The binary needs stack trampolines, just that in one case you don't use them. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
On Wednesday 02 February 2005 09:26, Theodore Ts'o wrote: On Tue, Feb 01, 2005 at 07:15:49PM -0500, Theodore Ts'o wrote: Umm, so exactly how many applications use multithreading (or otherwise trigger the GLIBC mprotect call), For the record, I've been informed that the glibc mprotect() call doesn't happen in any modern glibc's; there may have been one buggy glibc that was released very briefly before it was fixed in the next release. But if that's what the paxtest developers are hanging their hat on, it seems awfully lame to me. desabotaged seems like the correct description from my vantage point. Well, great! One problem eliminated. Anyways, for me it is not important whether what GLIBC exactly does or doesn't do. There are tons of different libraries and applications which do all kinds of stuff. You can only guess what exactly goes on. And not all compilers generate PT_GNU_STACK stuff either. And so on and so forth. What is important to me is the question whether the PaXtest results are accurately reflecting the underlying system or not. Therefore I would like to see proof that exec-shield does NOT open up in situations where PaXtest says it does. So far I have seen ``sabotage'' FUD, opinions and excuses. But no proof. Nor any reasonable evidence. That doesn't surprise me, because PaXtest is accurate in what it does. Groetjes, Peter. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: driver model u32 - pm_message_t conversion: help needed
Hi! Pavel Hi! Two Long time ago, BenH said that making patches is easy, Pavel so I hope to get his help now... And will probably need more. Pavel Suspend routines change, slowly. Pavel - int (*suspend)(struct device * dev, u32 state); + int Pavel (*suspend)(struct device * dev, pm_message_t state); Pavel For now u32 is typedef-ed to pm_message_t, but that is not Pavel going to be the case for 2.6.12. What needs to be done is Pavel changing all state parameters from u32 to Pavel pm_message_t. suspend() functions should not use state variable Pavel for now (except for PCI ones, those are allowed to call Pavel pci_choose_state and convert state into pci_power_t, and use Pavel that). Sorry for being late responding to this, but I'd say this is a prime example for typedef's considered evil (see Greg's OLS talk ;). It would be a lot cleaner if it was made a struct and then passing a struct pointer as the argument instead of passing the struct by value as you do right now. Sorry, can't do that. That would require flag day and change everything at once. That is just not feasible. When things are settled, it is okay to change it to struct passed by value.. It is small anyway and at least we will not have problems with freeing it etc. Well, we could switch to passing struct by reference (typedef struct pm_message *pm_message_t) , but AFAICS it would only bring us problems with lifetime rules etc. Lets not do it. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Tue, Feb 01, 2005 at 11:41:48PM -0800, Pete Zaitcev wrote:
On 30 Jan 2005 12:10:34 +0100, Peter Osterlund [EMAIL PROTECTED] wrote:
- Slow motion of finger produces no motion, then a jump. So, it's very
hard to
target smaller UI elements and some web links.
I see this too when I don't use the X touchpad driver. With the X
driver there is no problem. I think the problem is that mousedev.c in
the kernel has to use integer arithmetic, so probably small movements
are rounded off to 0. I'll try to come up with a fix for this.
Thanks for the hint. I tried various schemes and mathematical transformations
and found one which gives unquestionably the best result, with smoothest, most
precise and comfortable pointer movement:
Well, you removed the scaling to the touchpad resolution, which will
cause ALPS touchpad to be significantly slower than Synaptics touchpads.
Similarly, the screen size used to be taken into account, but probably
that was a mistake, since the value is usually left at default and
doesn't correspond to the real screen size.
--- linux-2.6.11-rc2/drivers/input/mousedev.c 2005-01-22 14:54:14.0
-0800
+++ linux-2.6.11-rc2-lem/drivers/input/mousedev.c 2005-02-01
23:20:19.0 -0800
@@ -122,19 +122,19 @@ static void mousedev_touchpad_event(stru
if (mousedev-touch) {
switch (code) {
case ABS_X:
- size = dev-absmax[ABS_X] - dev-absmin[ABS_X];
- if (size == 0) size = xres;
fx(0) = value;
if (mousedev-pkt_count = 2)
- mousedev-packet.dx = ((fx(0) - fx(1))
/ 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
+ mousedev-packet.dx = (value - fx(2)) /
2;
+ else if (mousedev-pkt_count == 1)
+ mousedev-packet.dx = value - fx(1);
break;
case ABS_Y:
- size = dev-absmax[ABS_Y] - dev-absmin[ABS_Y];
- if (size == 0) size = yres;
fy(0) = value;
if (mousedev-pkt_count = 2)
- mousedev-packet.dy = -((fy(0) - fy(1))
/ 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
+ mousedev-packet.dy = (fy(2) - value) /
2;
+ else if (mousedev-pkt_count == 1)
+ mousedev-packet.dy = fy(1) - value;
break;
}
}
I'm not kidding. Someone obviously outsmarted himself when programming this.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Really annoying bug in the mouse driver
Dmitry Torokhov wrote: It still complains in dmesg about throwing away bytes, right? Please try loading the box some more to make sure mouse survives some abuse. No, it doesn't. The only message I still get is the one below. I've tried it with aprox. 90% CPU usage already and I didn't have any additional problems. kernel: psmouse.c: bad data from KBC - bad parity Your keyboard controller reported that the byte transmitted from the mouse was mangled somehow and we should not trust it. I am not sure why it would make mouse jump.. was there any mention of reconnect in the logs? Did it happen just once? It happened once when I was at the computer and several times while I wasn't. There's no reconnect in the logs: [EMAIL PROTECTED]:~$ cat /var/log/messages | grep reconnect [EMAIL PROTECTED]:~$ Regards, Victor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ALSA HELP: Crackling and popping noises with via82xx
At Tue, 1 Feb 2005 21:34:59 -0500, Timothy Miller wrote: I've mentioned this problem before. It seemed to go away around the 2.6.8 timeframe, but when I started using 2.6.9, it came back. I'm using 2.6.10, and it's still happening. Basically, I get random poppling and crackling noises out of my speakers. Sometimes it's silent, and sometimes, it crackles and pops for minutes at a time. It's really disturbing, really, because it happens suddenly, sometimes very loudly, and usually when I'm concentrating. :) Check the kernel message whether the driver mentions about DXS channels. If yes, try to add dxs_support=4 (or dxs_support=1) module option. See ALSA-Configuration.txt for details. Takashi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] lib/sort: Replace qsort in XFS
Zan Lynx [EMAIL PROTECTED] wrote:
And you get in the habit of using 0 instead of NULL and before you know
it you've used it in a variable argument list for a GTK library call on
an AMD64 system and corrupted the stack. :-)
Using NULL without a cast is equally broken in a variadic context.
Sure it doesn't break on AMD64 but it'll break on platforms where
NULL pointers of different types have different representations.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] lib/sort: Heapsort implementation of sort()
Andreas Gruenbacher [EMAIL PROTECTED] wrote:
static inline void swap(void *a, void *b, int size)
{
if (size % sizeof(long)) {
char t;
do {
t = *(char *)a;
*(char *)a++ = *(char *)b;
*(char *)b++ = t;
} while (--size 0);
} else {
long t;
do {
t = *(long *)a;
*(long *)a = *(long *)b;
*(long *)b = t;
size -= sizeof(long);
} while (size sizeof(long));
}
}
What if a/b aren't aligned?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
On Tue, Feb 01, 2005 at 11:10:48PM -0600, Jack O'Quin wrote: Ingo Molnar [EMAIL PROTECTED] writes: (also, believe me, this is not arrogance or some kind of game on our part. If there was a nice clean solution that solved your and others' problems equally well then it would already be in Linus' tree. But there is no such solution yet, at the moment. Moreover, the pure fact that so many patch proposals exist and none looks dominantly convincing shows that this is a problem area for which there are no easy solutions. We hate such moments just as much as you do, but they do happen.) The actual requirement is nowhere near as difficult as you imagine. You and several others continue to view realtime in a multi-user context. That doesn't work. No wonder you have no good solution. A notion of process/thread scoping is needed from my point of view. How to implement that is another matter and there are no clear solutions that don't involve major changes in some way to fundamental syscalls like fork/clone() and underlying kernel structures from what I see. The very notion of Unix fork semantics isn't sufficient enough to contain these semantics. It's more about controlling things with known quantities over time, not about process creation relationships, and therein lies the mismatch. Also, as media apps get more sophisticated they're going to need some kind of access to the some traditional softirq facilities, possibily migrating it into userspace safely somehow, with how it handles IO processing such as iSCSI, FireWire, networking and all peripherals that need some kind of prioritized IO handling. It's akin to O_DIRECT, where folks need to determine policy over the kernel's own facilities, IO queues, but in a more broad way. This is inevitable for these category of apps. Scary ? yes I know. Think XFS streaming with guaranteed rate IO, then generalize this for all things that can be streamed in the kernel. A side note, they'll also be pegging CPU usage and attempting to draw to the screen at the same time. It would be nice to have slack from scheduler frames be use for less critical things such as drawing to the screen. The policy for scheduling these IO requests maybe divorced from the actual priority of the thread requesting it which present some problems with the current Linux code as I understand it. Whether this suitable for main stream inclusion is another matter. But as a person that wants to write apps of this nature, I came into this kernel stuff knowing that there's going to be a conflict between the the needs of media apps folks and what the Linux kernel folks will tolerate as a community. The humble RT-LSM was actually optimal for the multi-user scenario: don't load it. Then it adds no security issues, complexity or scheduler pathlength. As an added benefit, the sysadmin can easily verify that it's not there. The cost/performance characteristics of commodity PC's running Linux are quite compelling for a wide range of practical realtime applications. But, these are dedicated machines. The whole system must be carefully tuned. That is the only method that actually works. The scheduler is at most a peripheral concern; the best it can do is not screw up. It's very compelling and very deadly to the industry if these things become common place in the normal Linux kernel. It would instantly make Linux the top platform for anything media related, graphic and audio. (Hopefully, I can get back to kernel coding RT stuff after this current distraction that has me reassigned onto an emergency project) I hope I clarified some of this communication and not completely scare Ingo and others too much. Just a little bit is ok. :) bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] lib/sort: Heapsort implementation of sort()
On Wed, 2005-02-02 at 11:50, Herbert Xu wrote:
Andreas Gruenbacher [EMAIL PROTECTED] wrote:
static inline void swap(void *a, void *b, int size)
{
if (size % sizeof(long)) {
char t;
do {
t = *(char *)a;
*(char *)a++ = *(char *)b;
*(char *)b++ = t;
} while (--size 0);
} else {
long t;
do {
t = *(long *)a;
*(long *)a = *(long *)b;
*(long *)b = t;
size -= sizeof(long);
} while (size sizeof(long));
}
}
What if a/b aren't aligned?
That would be the case if the entire array was unaligned, or (size %
sizeof(long)) != 0. If people sort arrays that are unaligned even though
the element size is a multiple of sizeof(long) (or sizeof(u32) as Matt
proposes), they are just begging for bad performance. Otherwise, we're
doing byte-wise swap anyway.
--
Andreas Gruenbacher [EMAIL PROTECTED]
SUSE Labs, SUSE LINUX GMBH
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] 7/7 replace snd_kmalloc_strdup by kstrdup
At Tue, 01 Feb 2005 17:15:56 +, Paulo Marques wrote: [1 text/plain; us-ascii (7bit)] Takashi Iwai wrote: [...] Thanks, that looks almost fine except: diff -uprN -X dontdiff vanilla-2.6.11-rc2-bk9/sound/core/sound.c linux-2.6.11-rc2-bk9/sound/core/sound.c --- vanilla-2.6.11-rc2-bk9/sound/core/sound.c 2005-01-31 20:05:34.0 + +++ linux-2.6.11-rc2-bk9/sound/core/sound.c 2005-02-01 15:02:04.0 + @@ -401,7 +401,6 @@ EXPORT_SYMBOL(snd_hidden_kfree); EXPORT_SYMBOL(snd_hidden_vmalloc); EXPORT_SYMBOL(snd_hidden_vfree); #endif -EXPORT_SYMBOL(snd_kmalloc_strdup); EXPORT_SYMBOL(copy_to_user_fromio); EXPORT_SYMBOL(copy_from_user_toio); /* init.c */ I guess here missing EXPORT(snd_hidden_kstrdup)? Good catch. Here is the revised patch... I hope this time everything is ok That's perfect :) thanks, Takashi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
* Jack O'Quin [EMAIL PROTECTED] wrote: Remember when I asked how you handle changes to sizeof(struct rusage)? That was a serious question. I hope there's a solution. [...] what does any of what we've talking about have to do with struct rusage? One of the patches i wrote adds a new rlimit. It has no impact on rusage, at all. A new rlimit can be added transparently, we routinely add new rlimits, and no, most of them have no matching rusage fields! But, I got no answer, only handwaving. i very much replied to your point: http://marc.theaimsgroup.com/?l=linux-kernelm=110672338910363w=2 Does getrusage() return anything for this? How can a field be added to the rusage struct without breaking binary compatibility? Can we assume that no programs ever use sizeof(struct rusage)? rlimits are easily extended and there are no binary compatibility worries. The kernel doesnt export the maximum towards userspace. getrusage() will return the value on new kernels and will return -EINVAL on old kernels, so new userspace can deal with this accordingly. (and here i meant getrlimit(), not getrusage() - getrusage() is not affected by the patch at all.) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] FUSE - fix race in interrupted request
Hi Andrew,
This patch fixes a potential race between request_wait_answer()
calling background_request() and fuse_dev_writev() calling
request_end() if a request is interrupted. The race could cause
inodes and files to acquire an extra reference, making them
unfreeable.
Please apply.
Thanks,
Miklos
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.11-rc2-mm2/fs/fuse/dev.c linux-fuse/fs/fuse/dev.c
--- linux-2.6.11-rc2-mm2/fs/fuse/dev.c 2005-01-30 21:40:53.0 +0100
+++ linux-fuse/fs/fuse/dev.c2005-02-02 12:44:26.0 +0100
@@ -233,7 +233,7 @@ static void request_wait_answer(struct f
if (!req-sent !list_empty(req-list)) {
list_del(req-list);
__fuse_put_request(req);
- } else if (req-sent)
+ } else if (!req-finished req-sent)
background_request(req);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I RESEND THE MESSAGE
Dear friend, Assalamu Alaikum Salaam,I want to drop you a quick note because I did not hear back from you concerning the information I sent you the otherday.Incase you did not recieve the letter introducing my intent. I am mohammed Hassan an Iraqi.I got your contacts through my personal research and out of desperation decided to reach you through this medium. I have USD$100 million for investment purpose. I want you to recieve this fund on my behalf and invest on a profitable business venture on an agreed terms.If you are interested please get intouch with me as soon as possible for more details.Include your private telephone number in your response. Wasslam Mohammed Hassan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] 1/7 create kstrdup library function
Pekka Enberg wrote: At some point in time, I wrote: kstrdup() is a special-case _memory allocator_ (not so much a string operation) so I think it should go into mm/slab.c where we currently have kcalloc(). On Tue, 01 Feb 2005 17:00:17 +, Paulo Marques [EMAIL PROTECTED] wrote: I was following Rusty Russell's approach. Also, I believe this is more intuitive because the standard libc strdup function is declared in string.h. However, I really don't have strong feelings either way, so if the majority agrees that this should be in mm/slab, its fine by me. Intuitive, perhaps, but I think it's wrong. I don't like it because it makes string operations depend on slab. Furthermore, kstrdup() is not a string operation. It is about memory allocation, really, just like kcalloc(). I agree with the is like kcalloc argument in the sense that it does an allocation + something else. But in this case the something else is in fact a string operation, so this just seem to be in the middle. One possible way to clean this up would be to extract the standard-like allocators (kmalloc, kcalloc, and kstrdup) from mm/slab.c and move them into a separate file. I don't like this approach. From a quick grep you get 4972 kmalloc's in .c files in the kernel tree and only 35 kstrdup's. Moving kstrdup around is still just 7 patches, kmalloc is a much bigger problem. Anyway, as I said before, if more people believe that moving kstrdup into mm/slab.c is the way to go, then its fine by me. The problem I was trying to solve was having several versions of strdup-like functions all around the kernel, and this problem gets fixed either way. Right now, the poll goes something like this: string.c: me, Rusty Russell slab.c: Pekka Enberg I think we need more votes :) -- Paulo Marques - www.grupopie.com All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TRIVIAL 2.6] Update panic() comment.
[TRIVIAL 2.6] Update panic() comment. panic() doesn't flush the filesystem cache anymore. The comment above the function still claims it does. Thanks, Heiko = panic.c 1.22 vs edited = --- 1.22/kernel/panic.c 2004-11-08 03:16:06 +01:00 +++ edited/panic.c 2005-02-02 12:25:21 +01:00 @@ -49,8 +49,7 @@ * panic - halt the system * @fmt: The text string to print * - * Display a message, then perform cleanups. Functions in the panic - * notifier list are called after the filesystem cache is flushed (when possible). + * Display a message, then perform cleanups. * * This function never returns. */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
Umm, so exactly how many applications use multithreading (or otherwise trigger the GLIBC mprotect call), and how many applications use nested functions (which is not ANSI C compliant, and as a result, very rare)? i think you're missing the whole point of paxtest. it's not about what glibc et al. do or don't do. it's about what an exploit can do (by virtue of forcing the exploited application to do something). if your line of thinking was correct, then why didn't you also object to the fact that the paxtest applications overflow their own stack/heap/etc? or that they put 'shellcode' onto the stack/heap/etc and invoke it by abusing a memory corrupting bug? surely no sane real-life application does any of this. so once again, let me explain what paxtest does. it tests PaX for its claims. since PaX claims to be an intrusion prevention system, paxtest tries to simulate said intrusions (in particular, we're talking about exploiting memory corruption bugs). the stress is on 'simulate'. none of the paxtest applications are full blown exploits. nor do they need to be. knowing what PaX does (or claims to do), it's very easy to design and write small applications that perform the core steps of an exploit that may be able to break the protection mechanisms. i.e., any 'real' exploit would eventually have to perform these core steps, so by ensuring that they don't work (at least when the PaX claims stand) we can ensure that no real life exploit would work either. now let's get back to mprotect(), nested functions, etc. when an exploit writer knows that the only barrier that prevents him from executing his shellcode is a circumventible memory protection, then guess what, he'll first try to circumvent said memory protection then execute his shellcode as usual. since memory protection is controlled by mmap/mmprotect, his goal will be to somehow force the exploited application to end up calling these functions to get an executable region holding his shellcode. your concerns would be valid if this was impossible to achieve by an exploit, sadly, you'd be wrong too, it's possible to force an exploited application to call something like dl_make_stack_executable() and then execute the shellcode. there're many ways of doing this, the simplest (in terms of lines of code) was chosen for paxtest. or put another way, would you still argue that the use of the nested function trampoline is sabotage whereas an exploit forcing a call to dl_make_stack_executable() isn't? because the two achieve the exact same thing, they open up the address space (or part of it, depending on the intrusion prevention system) for shellcode execution. one thing that paxtest didn't get right in the 'kiddie' mode is that it still ran with an executable stack, that was not the intention but rather an oversight, it'll be fixed in the next release. still, this shouldn't leave you with a warm and fuzzy feeling about the security of intrusion prevention systems that 'pass' the 'kiddie' mode but fail the 'blackhat' mode, in the real life out there, only the latter matters (if for no other reason, then for natural evolution/adaptation of exploit writers). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hugepages demand paging V2 [3/8]: simple numa compatible allocator
Hi Christoph,
Changelog
* Simple NUMA compatible allocation of hugepages in the nearest node
Index: linux-2.6.9/mm/hugetlb.c
===
--- linux-2.6.9.orig/mm/hugetlb.c 2004-10-22 13:28:27.0 -0700
+++ linux-2.6.9/mm/hugetlb.c 2004-10-25 16:56:22.0 -0700
@@ -32,14 +32,17 @@
{
int nid = numa_node_id();
struct page *page = NULL;
-
- if (list_empty(hugepage_freelists[nid])) {
- for (nid = 0; nid MAX_NUMNODES; ++nid)
- if (!list_empty(hugepage_freelists[nid]))
- break;
+ struct zonelist *zonelist = NODE_DATA(nid)-node_zonelists;
I think the previous line should be replaced with
struct zonelist *zonelist = NODE_DATA(nid)-node_zonelists + __GFP_HIGHMEM;
because NODE_DATA(nid)-node_zonelists means a zonelist for __GFP_DMA zones.
__GFP_HIGHMEM would be suitable for hugetlbpages.
+ struct zone **zones = zonelist-zones;
+ struct zone *z;
+ int i;
+
+ for(i=0; (z = zones[i])!= NULL; i++) {
+ nid = z-zone_pgdat-node_id;
+ if (!list_empty(hugepage_freelists[nid]))
+ break;
}
- if (nid = 0 nid MAX_NUMNODES
- !list_empty(hugepage_freelists[nid])) {
+ if (z) {
page = list_entry(hugepage_freelists[nid].next,
struct page, lru);
list_del(page-lru);
-
Thanks,
Hirokazu Takahashi.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 1/7 create kstrdup library function
Paulo Marques writes: I agree with the is like kcalloc argument in the sense that it does an allocation + something else. But in this case the something else is in fact a string operation, so this just seem to be in the middle. Sure, but now you're forcing all users of string.h to depend on the slab as well. Conceptually, kstrdup() is an initializing memory allocator, not a string operation, which is why I think it should go into slab.c. Paulo Marques writes: I don't like this approach. From a quick grep you get 4972 kmalloc's in .c files in the kernel tree and only 35 kstrdup's. Moving kstrdup around is still just 7 patches, kmalloc is a much bigger problem. Hmm? Yes, moving the declaration from slab.h to some other header is painful. I only talked about moving the definition from slab.c. Paulo Marques writes: Anyway, as I said before, if more people believe that moving kstrdup into mm/slab.c is the way to go, then its fine by me. The problem I was trying to solve was having several versions of strdup-like functions all around the kernel, and this problem gets fixed either way. Right now, the poll goes something like this: string.c: me, Rusty Russell slab.c: Pekka Enberg I think we need more votes :) Could we also get Rusty's confirmation on this? Pekka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux hangs during IDE initialization at boot for 30 sec
Benjamin Herrenschmidt benh at kernel.crashing.org writes: This looks like bogus HW, or bogus list of IDE interfaces ... How can I test to see if this is the case? The IDE layer waits up to 30 seconds for a device to drop it's busy bit, which is necessary for some drives that aren't fully initialized yet. Sure, make sense. I suspect in your case, it's reading ff, which indicates either that there is no hardware where the kernel tries to probe, or that there is bogus IDE interfaces which don't properly have the D7 line pulled low so that BUSY appears not set in absence of a drive. Right. How do I find the value of D7? I'm not sure how the list of intefaces is probed on this machine, that's probably where the problem is. Thanks, Richard Hughes - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux hangs during IDE initialization at boot for 30 sec
Richard Hughes wrote: Benjamin Herrenschmidt benh at kernel.crashing.org writes: This looks like bogus HW, or bogus list of IDE interfaces ... How can I test to see if this is the case? The IDE layer waits up to 30 seconds for a device to drop it's busy bit, which is necessary for some drives that aren't fully initialized yet. Sure, make sense. I suspect in your case, it's reading ff, which indicates either that there is no hardware where the kernel tries to probe, or that there is bogus IDE interfaces which don't properly have the D7 line pulled low so that BUSY appears not set in absence of a drive. Right. How do I find the value of D7? I'm not sure how the list of intefaces is probed on this machine, that's probably where the problem is. I've read that people have had this problem go away if they disable this option: generic/default IDE chipset support If you have chipset support for your IDE controller this isn't needed, and I'd recommend disabling it. The why it made the problem go away is something I can't answer. Cheers, Con signature.asc Description: OpenPGP digital signature
[PATCH] Minor Kexec bug fix (2.6.11-rc2-mm2)
Hi Andrew,
This patch has been generated against 2.6.11-rc2-mm2. This fixes a very
minor bug in kexec.
Thanks
Vivek
This patch fixes a minor bug in kexec. Changing the data type of flags makes
sure proper control flow of code during crash event.
Signed-off-by: Vivek Goyal [EMAIL PROTECTED]
---
linux-2.6.11-rc2-mm2-kdump-vivek/include/linux/kexec.h |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN include/linux/kexec.h~kexec_minor_bug_fix include/linux/kexec.h
--- linux-2.6.11-rc2-mm2-kdump/include/linux/kexec.h~kexec_minor_bug_fix
2005-02-02 16:28:18.0 +0530
+++ linux-2.6.11-rc2-mm2-kdump-vivek/include/linux/kexec.h 2005-02-02
16:29:01.0 +0530
@@ -79,7 +79,7 @@ struct kimage {
unsigned long control_page;
/* Flags to indicate special processing */
- int type : 1;
+ unsigned int type : 1;
#define KEXEC_TYPE_DEFAULT 0
#define KEXEC_TYPE_CRASH 1
};
_
Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
Hi! one thing that paxtest didn't get right in the 'kiddie' mode is that it still ran with an executable stack, that was not the intention but rather an oversight, it'll be fixed in the next release. still, this shouldn't leave you with a warm and fuzzy feeling about the security of intrusion prevention systems that 'pass' the 'kiddie' mode but fail the 'blackhat' mode, in the real life out there, only the latter matters (if for no other reason, then for natural evolution/adaptation of exploit writers). I apologise for this bug. If someone had pointed this out in a clear and to-the-point kind of way, then this would have been fixed a long time ago. Anyways, if anyone else has any suggestions, fixes, or special wishes for PaXtest (some exec-shield specific tests perhaps?), then please speak up now. I'd rather not bother this list again about PaXtest related issues. Groetjes, Peter. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cpufreq problem wrt suspend/resume on Athlon64
Hi, I have noticed that the condition (cur_freq != cpu_policy-cur), which is unlikely() according to cpufreq.c:cpufreq_resume(), occurs on every resume on my box (Athlon64-based Asus). Every time the box resumes, I get a message like that: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 160, is 180 kHz. (the numbers vary: there may be 80 vs 160 or even 80 vs 180). Also, when the box is suspended on AC power and resumed on batteries, it often reboots. Please let me know if there's anything (relatively simple :-)) that I can do about it. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq problem wrt suspend/resume on Athlon64
Hi! I have noticed that the condition (cur_freq != cpu_policy-cur), which is unlikely() according to cpufreq.c:cpufreq_resume(), occurs on every resume on my box (Athlon64-based Asus). Every time the box resumes, I get a message like that: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 160, is 180 kHz. (the numbers vary: there may be 80 vs 160 or even 80 vs 180). Also, when the box is suspended on AC power and resumed on batteries, it often reboots. Please let me know if there's anything (relatively simple :-)) that I can do about it. Introduce _suspend() routine to cpufreq, and force cpu to 800MHz during suspend(). Put it back to right frequency during resume(). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Accelerated frame buffer functions
How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( Any help is greatly appreciated! -- Haakon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cdrtools 2.01 not working in 2.6.10
I can't use cdrtools 2.01 with kernel 2.6.10 (i386, P4). Once the 0 of xxx MB written message appears, the CD-writer spins down, the HD led lits, and the system nearly hangs (many processes in D(isk) state). After a minute or two, timeout messages on hda (main HD) appear in dmesg, followed by hdc (CD-writer, plextor) timeout messages. Is this a known issue of 2.6.10? I'm not giving more details because I believe I'm not the only one with this problem. However, all works fine with 2.6.9. If this is an unknown issue, I could give more details (logs, config, etc.). Otherwise, will this be solved by 2.6.11? Cheers, Rodrigo Ventura PS: please CC replies to me (yoda AT isr DOT ist DOT utl DOT pt). -- *** Rodrigo Martins de Matos Ventura [EMAIL PROTECTED] *** Web page: http://www.isr.ist.utl.pt/~yoda *** Teaching Assistant and PhD Student at ISR: ***Instituto de Sistemas e Robotica, Polo de Lisboa *** Instituto Superior Tecnico, Lisboa, PORTUGAL *** PGP fingerprint = 0119 AD13 9EEE 264A 3F10 31D3 89B3 C6C4 60C6 4585 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dynamic tick, version 050127-1
Hi! I don't think it's HPET timer, or CONFIG_SMP. It also looks like your local APIC timer is working. If you have a serial console, you can put one letter printks in the code. Can you check if you ever get to smp_apic_timer_interrupt()? That's where you should get to after the sleep, and that calls the PIT timer interrupt to get it going again. I'm thinking that you'll get to smp_apic_timer_interrupt(), but once therebut function dyn_tick-interrupt(0, NULL, regs) never gets called. dyn_tick-interrupt *is* being called: Feb 2 14:53:41 amd last message repeated 36 times Feb 2 14:53:41 amd postfix/postfix-script: starting the Postfix mail system Feb 2 14:53:41 amd kernel: dyn_tick-interrupt Feb 2 14:53:41 amd kernel: dyn_tick-interrupt Feb 2 14:53:41 amd postfix/master[1301]: daemon started -- version 2.1.5 Feb 2 14:53:41 amd kernel: dyn_tick-interrupt Feb 2 14:53:45 amd last message repeated 30 times Feb 2 14:53:45 amd log1n[1220]: ROOT LOGIN on `tty8' Feb 2 14:53:45 amd kernel: dyn_tick-interrupt Feb 2 14:54:16 amd last message repeated 228 times I'll try turning off CONFIG_PREEMPT... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dynamic tick, version 050127-1
Hi!
Hmmm, that sounds like the local APIC does not wake up the PIT
interrupt properly after sleep. Hitting the keys causes the timer
interrupt to get called, and that explains why it keeps running. But
the timer ticks are not happening as they should for some reason.
This should not happen (tm)...
:-). Any ideas how to debug it? Previous version of patch seemed to work
better...
I don't think it's HPET timer, or CONFIG_SMP. It also looks like your
local APIC timer is working.
If you have a serial console, you can put one letter printks in the
code. Can you check if you ever get to smp_apic_timer_interrupt()?
That's where you should get to after the sleep, and that calls the
PIT timer interrupt to get it going again. I'm thinking that you'll
get to smp_apic_timer_interrupt(), but once therebut function
dyn_tick-interrupt(0, NULL, regs) never gets called.
I definitely get to smp_apic_timer_interrupt:
Feb 2 14:46:53 amd kernel:
ic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_ti
Feb 2 14:46:54 amd kernel:
irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsmp_apic_timer_irqsm
I'll test with this code:
if (dyn_tick-state (DYN_TICK_ENABLED | DYN_TICK_SKIPPING)) {
if (dyn_tick-skip_cpu == cpu dyn_tick-skip
DYN_TICK_MIN_SKIP) {
printk(dyn_tick-interrupt\n);
dyn_tick-interrupt(0, NULL, regs);
} else
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dynamic tick, version 050127-1
Hi! Hmmm, that sounds like the local APIC does not wake up the PIT interrupt properly after sleep. Hitting the keys causes the timer interrupt to get called, and that explains why it keeps running. But the timer ticks are not happening as they should for some reason. This should not happen (tm)... :-). Any ideas how to debug it? Previous version of patch seemed to work better... I don't think it's HPET timer, or CONFIG_SMP. It also looks like your local APIC timer is working. I ran find /, now my machine seems to work... Except that the time is now two times as fast as it should be, ouch. If you have a serial console, you can put one letter printks in the code. Can you check if you ever get to smp_apic_timer_interrupt()? That's where you should get to after the sleep, and that calls the PIT timer interrupt to get it going again. I'm thinking that you'll get to smp_apic_timer_interrupt(), but once therebut function dyn_tick-interrupt(0, NULL, regs) never gets called. Serial console would be slightly tricky to arrange... Heh, is it possible that I'm not running NMI deadlock detector and therefore it does not tick or something like that? It's OK to put printks to the timer code here, there's tons of output only when the system is busy :) Also, can you post your .config again? And also please post output from: dmesg | grep -i time\|tick\|apic [EMAIL PROTECTED]:~$ dmesg | grep -i time\|tick\|apic PCI: Setting latency timer of device :00:11.5 to 64 dyn-tick: Maximum ticks to skip limited to 1339 dyn-tick: Timer using dynamic tick [EMAIL PROTECTED]:~$ Config is attached. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! config.gz Description: Binary data
Re: Accelerated frame buffer functions
On Wed, 2 Feb 2005, Haakon Riiser wrote: How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( Any help is greatly appreciated! X-Windows already does this. Execute `/usr/bin/X11/x11perf -all` to watch. Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dynamic tick, version 050127-1
Hi! I used your config advices from second mail, still it does not work as expected: system gets too sleepy. Like it takes a nap during boot after dyn-tick: Maximum ticks to skip limited to 1339, and key is needed to make it continue boot. Then cursor stops blinking and machine is hung at random intervals during use, key is enough to awake it. Hmmm, that sounds like the local APIC does not wake up the PIT interrupt properly after sleep. Hitting the keys causes the timer interrupt to get called, and that explains why it keeps running. But the timer ticks are not happening as they should for some reason. This should not happen (tm)... :-). Any ideas how to debug it? Previous version of patch seemed to work better... I don't think it's HPET timer, or CONFIG_SMP. It also looks like your local APIC timer is working. I turned off CONFIG_PREEMPT, but nothing changed :-(. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux hangs during IDE initialization at boot for 30 sec
Con Kolivas kernel at kolivas.org writes: I'm not sure how the list of intefaces is probed on this machine, that's probably where the problem is. I've read that people have had this problem go away if they disable this option: generic/default IDE chipset support Okay I'll try this tonight. I'm running a stock Fedora kernel at the moment (rawhide) so this issue might affect more people than we think. If you have chipset support for your IDE controller this isn't needed, and I'd recommend disabling it. The why it made the problem go away is something I can't answer. Richard. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Accelerated frame buffer functions
[Dick Johnson] On Wed, 2 Feb 2005, Haakon Riiser wrote: How can I use a frame buffer driver's optimized copyarea, fillrect, blit, etc. from userspace? The only way I've ever seen anyone use the frame buffer device is by mmap()ing it and doing everything manually in the mapped memory. I assume there must be ioctls for accessing the accelerated functions, but after several hours of grepping and googling, I give up. :-( X-Windows already does this. Yeah, I thought the X11 fbdev driver supported acceleration, but not according to its manpage: fbdev is an Xorg driver for framebuffer devices. This is a non-accelerated driver [...] -- Haakon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
Itsuro Oda [EMAIL PROTECTED] writes: Hi, I can't understand why ELF format is necessary. ELF format is not. However essentially the information an ELF provides is. So using an ELF header to convey that information is a sane choice of data structure. I think the only necessary information is what physical address regions are valid to read. This information is necessary for any sort of dump tools. (and must get it while the system is normal.) The Eric's /proc/cpumem idea sounds nice to me. Patches welcome. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
Koichi Suzuki [EMAIL PROTECTED] writes: I meant with kexec and dump hook, there could be many more things can be done in addition to full core dump. Initiating failover to other node will be one example. Starting with this hook, there must be many good ideas. So my idea is to make this hook general purpose, not for specific core dump tool. Again that is what is has been implemented. A fully stand alone executable that lives in an independent and reserved address in memory is jumped to. The goal in the generic kernel is to keep the code path to do that as small and as simple as possible to reduce the chances of it being mis-implemented, or the chances of attempting to use corrupted kernel functionality. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] s390: getdents patch for 32 - 64 converter
Hi Sripathi,
This patch solves a problem with working of getdents while using 32 bit
binaries on 64 bit Linux/390. glibc expects d_type to be passed if we
have a kernel version after 2.6.4, so we have to also handle it in the
32bit syscall converter. Similar patch was given for PPC by Marcus
Meissner
(http://ozlabs.org/pipermail/linuxppc64-dev/2004-March/001359.html) and
was integrated into 2.6.5.
thanks for bringing this to my attention. This is indeed broken,
but I prefer a different solution: remove the s390 specific compat
functions and use the generic ones.
Andrew, would you please add this to your patch collection?
blue skies,
Martin.
---
[patch] s390: compat_sys_old_readdir and compat_sys_getdents.
From: Sripathi Kodi [EMAIL PROTECTED]
From: Martin Schwidefsky [EMAIL PROTECTED]
s390 should use the generic compat functions for compat_sys_old_readdir
and compat_sys_getdents. The s390 specific ones are buggy and superflous.
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
diffstat:
arch/s390/kernel/compat_linux.c | 130 --
arch/s390/kernel/compat_wrapper.S |4 -
2 files changed, 2 insertions(+), 132 deletions(-)
diff -urN linux-2.6/arch/s390/kernel/compat_linux.c
linux-2.6-patched/arch/s390/kernel/compat_linux.c
--- linux-2.6/arch/s390/kernel/compat_linux.c 2005-02-02 13:47:25.0
+0100
+++ linux-2.6-patched/arch/s390/kernel/compat_linux.c 2005-02-02
13:50:32.0 +0100
@@ -355,136 +355,6 @@
return sys_ftruncate(fd, (high 32) | low);
}
-/* readdir getdents */
-
-#define NAME_OFFSET(de) ((int) ((de)-d_name - (char *) (de)))
-#define ROUND_UP(x) (((x)+sizeof(u32)-1) ~(sizeof(u32)-1))
-
-struct old_linux_dirent32 {
- u32 d_ino;
- u32 d_offset;
- unsigned short d_namlen;
- chard_name[1];
-};
-
-struct readdir_callback32 {
- struct old_linux_dirent32 * dirent;
- int count;
-};
-
-static int fillonedir(void * __buf, const char * name, int namlen,
- loff_t offset, ino_t ino, unsigned int d_type)
-{
- struct readdir_callback32 * buf = (struct readdir_callback32 *) __buf;
- struct old_linux_dirent32 * dirent;
-
- if (buf-count)
- return -EINVAL;
- buf-count++;
- dirent = buf-dirent;
- put_user(ino, dirent-d_ino);
- put_user(offset, dirent-d_offset);
- put_user(namlen, dirent-d_namlen);
- copy_to_user(dirent-d_name, name, namlen);
- put_user(0, dirent-d_name + namlen);
- return 0;
-}
-
-asmlinkage long old32_readdir(unsigned int fd, struct old_linux_dirent32
*dirent, unsigned int count)
-{
- int error = -EBADF;
- struct file * file;
- struct readdir_callback32 buf;
-
- file = fget(fd);
- if (!file)
- goto out;
-
- buf.count = 0;
- buf.dirent = dirent;
-
- error = vfs_readdir(file, fillonedir, buf);
- if (error 0)
- goto out_putf;
- error = buf.count;
-
-out_putf:
- fput(file);
-out:
- return error;
-}
-
-struct linux_dirent32 {
- u32 d_ino;
- u32 d_off;
- unsigned short d_reclen;
- chard_name[1];
-};
-
-struct getdents_callback32 {
- struct linux_dirent32 * current_dir;
- struct linux_dirent32 * previous;
- int count;
- int error;
-};
-
-static int filldir(void * __buf, const char * name, int namlen, loff_t offset,
ino_t ino,
- unsigned int d_type)
-{
- struct linux_dirent32 * dirent;
- struct getdents_callback32 * buf = (struct getdents_callback32 *) __buf;
- int reclen = ROUND_UP(NAME_OFFSET(dirent) + namlen + 1);
-
- buf-error = -EINVAL; /* only used if we fail.. */
- if (reclen buf-count)
- return -EINVAL;
- dirent = buf-previous;
- if (dirent)
- put_user(offset, dirent-d_off);
- dirent = buf-current_dir;
- buf-previous = dirent;
- put_user(ino, dirent-d_ino);
- put_user(reclen, dirent-d_reclen);
- copy_to_user(dirent-d_name, name, namlen);
- put_user(0, dirent-d_name + namlen);
- buf-current_dir = ((void *)dirent) + reclen;
- buf-count -= reclen;
- return 0;
-}
-
-asmlinkage long sys32_getdents(unsigned int fd, struct linux_dirent32 *dirent,
unsigned int count)
-{
- struct file * file;
- struct linux_dirent32 * lastdirent;
- struct getdents_callback32 buf;
- int error = -EBADF;
-
- file = fget(fd);
- if (!file)
- goto out;
-
- buf.current_dir = dirent;
- buf.previous = NULL;
- buf.count = count;
- buf.error = 0;
-
- error = vfs_readdir(file, filldir, buf);
- if (error 0)
- goto out_putf;
- lastdirent = buf.previous;
- error = buf.error;
- if(lastdirent) {
-
Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
And the feedback begins :) Itsuro Oda [EMAIL PROTECTED] writes: Hi, I don't like calling crash_kexec() directly in (ex.) panic(). It should be call_dump_hook() (or something like this). I think the necessary modifications of the kernel is only: - insert the hooks that calls a dump function when crash occur crash_kexec() - binding interface that binds a dump function to the hook (like register_dump_hook()) sys_kexec_load(...); - supply the information of valid physical address regions /proc/iomem or possibly /proc/cpumem. At least until someone actually implements hot plug memory support. (- maybe some existent functions and variables need to be exported ?) I think this makes any sort of dump functions can be implemented as a kernel module. I don't think it is best way that the kexec based crashdump is built in the kernel. For people developing code outside of the kernel I can see where this is a problem. Given the insane auditing requirements necessary to get a reliable code path I don't see how not putting the implementation in the kernel is sane. Anything that needs to be touched at that point is core kernel functionality GPL_ONLY if it is exported at all. Touching anything from a module at that point is not sane. Basically the code path setup with crash_kexec is little more than a jump instruction. And it should be audited and reduced as much as possible. I don't see how you get simpler or what piece of functionality could possibly improve by having multiple implementations in kernel modules. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Copyright / licensing question
Hi, I have got an offer to write a book on Linux filesystems. In this I would like to cover existing filesystems like ext3, xfs etc. I would also cover embedded file systems such as jffs,ROMfs,cramsf etc. I am having some licensing questions. It would be really great if you can clarify on them 1. For explaining the internals of a filesystem in detail, I need to take their code from kernel sources 'as it is' in the book. Do I need to take any permissions from the owner/maintainer regarding this ? Will it violate any license if reproduce the driver source code in my book ?? 2. I will write some custom drivers also for illustration. For this I shall include kernel headers. I also intend to put this in the book. From whom I need to take permission regarding this ? The book will be supported by a web-site. I have no problems in releasing my custom code under GPL. But Am I violating any license by putting the code in the book ? Please CC me Thanks yours Frank Klein __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Copyright / licensing question
On Wed, 2005-02-02 at 06:49 -0800, Frank klein wrote: Hi, I have got an offer to write a book on Linux filesystems. In this I would like to cover existing filesystems like ext3, xfs etc. I would also cover embedded file systems such as jffs,ROMfs,cramsf etc. I am having some licensing questions. It would be really great if you can clarify on them 1. For explaining the internals of a filesystem in detail, I need to take their code from kernel sources 'as it is' in the book. Do I need to take any permissions from the owner/maintainer regarding this ? Will it violate any license if reproduce the driver source code in my book ?? no. However what you SHOULD do is attribute the code properly and point the reader clearly at the origin and to the fact that the code is licensed under the terms of the GPL only. (or in case of dual license, well you get the point) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
Mirko Parthey wrote: On Mon, Jan 31, 2005 at 05:22:02PM +0100, wrote: My Debian machine hangs during shutdown, with messages like this: unregister_netdevice: waiting for br0 to become free. Usage count = 1 I narrowed it down to the command # brctl delbr br0 which does not return in the circumstances shown below. The problem is reproducible with both 2.6.11-rc2 from kernel.org and the Debian kernel-image-2.6.10-1-686. [...] The problem was introduced between 2.6.8.1 and 2.6.9, and it is still present in 2.6.11-rc2-bk9. Mirko - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Jep it appears in 2.6.8 and above. I don't know the process who's using it: Before shutdown: PID TTY TIME CMD 1 ?00:00:00 init 2 ?00:00:00 ksoftirqd/0 3 ?00:00:00 events/0 4 ?00:00:00 khelper 9 ?00:00:00 kthread 19 ?00:00:00 kacpid 17 ?00:00:00 vesafb 100 ?00:00:00 kblockd/0 164 ?00:00:00 pdflush 165 ?00:00:00 pdflush 166 ?00:00:00 kswapd0 167 ?00:00:00 aio/0 168 ?00:00:00 jfsIO 169 ?00:00:00 jfsCommit 170 ?00:00:00 jfsSync 171 ?00:00:00 xfslogd/0 172 ?00:00:00 xfsdatad/0 173 ?00:00:00 xfsbufd 774 ?00:00:00 kseriod 862 ?00:00:00 ata/0 882 ?00:00:00 kcryptd/0 883 ?00:00:00 kmirrord/0 887 ?00:00:00 xfssyncd 939 ?00:00:00 udevd 1061 ?00:00:00 devfsd 1242 ?00:00:00 khubd 1616 ?00:00:00 syslog-ng 2562 ?00:00:00 khpsbpkt 2646 ?00:00:00 knodemgrd_0 3987 ?00:00:00 crond 4027 tty2 00:00:00 agetty 4028 tty3 00:00:00 agetty 4029 tty4 00:00:00 agetty 4030 tty5 00:00:00 agetty 4031 tty6 00:00:00 agetty 4473 tty1 00:00:00 bash 4553 tty1 00:00:00 ps And my System can't shutdown because of this bug. Currently disabling this checking function seems to be the only solution (see my diff). Matthias-Christian Ott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
