When device_create_file() fails and returns a non-zero value,
no error return code of driver_sysfs_add() is assigned.
To fix this bug, ret is assigned with the return value of
device_create_file(), and then ret is checked.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
v2:
* Fix a redunda
On 2021/3/23 21:57, Greg KH wrote:
On Fri, Mar 05, 2021 at 02:24:05AM -0800, Jia-Ju Bai wrote:
When device_create_file() fails and returns a non-zero value,
no error return code of driver_sysfs_add() is assigned.
To fix this bug, ret is assigned with the return value of
device_create_file(),
On Fri, Mar 05, 2021 at 02:24:05AM -0800, Jia-Ju Bai wrote:
> When device_create_file() fails and returns a non-zero value,
> no error return code of driver_sysfs_add() is assigned.
> To fix this bug, ret is assigned with the return value of
> device_create_file(), and then ret is checked.
>
> Re
On Fri, Mar 5, 2021 at 11:24 AM Jia-Ju Bai wrote:
>
> When device_create_file() fails and returns a non-zero value,
> no error return code of driver_sysfs_add() is assigned.
> To fix this bug, ret is assigned with the return value of
> device_create_file(), and then ret is checked.
>
> Reported-by
When device_create_file() fails and returns a non-zero value,
no error return code of driver_sysfs_add() is assigned.
To fix this bug, ret is assigned with the return value of
device_create_file(), and then ret is checked.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/base/dd.c
On Tue, Feb 16, 2021 at 03:34:27PM +0100, Rafael J. Wysocki wrote:
> On Tue, Feb 16, 2021 at 3:24 PM Greg Kroah-Hartman
> wrote:
> >
> > No need to save the debugfs dentry for the "devices_deferred" debugfs
> > file (gotta love the juxtaposition), if we need to remove it we can look
> > it up from
On Tue, Feb 16, 2021 at 3:24 PM Greg Kroah-Hartman
wrote:
>
> No need to save the debugfs dentry for the "devices_deferred" debugfs
> file (gotta love the juxtaposition), if we need to remove it we can look
> it up from debugfs itself.
>
> Cc: "Rafael J. Wysocki"
> Cc: linux-kernel@vger.kernel.or
No need to save the debugfs dentry for the "devices_deferred" debugfs
file (gotta love the juxtaposition), if we need to remove it we can look
it up from debugfs itself.
Cc: "Rafael J. Wysocki"
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/dd.c | 7 +++
Fixes the following W=1 kernel build warning(s):
drivers/infiniband/hw/hfi1/pio_copy.c:73: warning: Function parameter or
member 'dd' not described in 'pio_copy'
Cc: Mike Marciniszyn
Cc: Dennis Dalessandro
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: linux-r...@vger.kern
On 2020-10-11 3:46 p.m., Mikhail Gavrilov wrote:
Hi folks!
I have a question.
What happens when dd writes data to a missing device?
For example:
# dd
if=/home/mikhail/Downloads/Fedora-Workstation-Live-x86_64-Rawhide-20201010.n.0.iso
of=/dev/adb
Today I and wrongly entered /dev/adb instead of
On Mon, Oct 12, 2020 at 12:46:03AM +0500, Mikhail Gavrilov wrote:
> Hi folks!
> I have a question.
> What happens when dd writes data to a missing device?
>
> For example:
> # dd
> if=/home/mikhail/Downloads/Fedora-Workstation-Live-x86_64-Rawhide-20201010.n.0.iso
> of=/
On Mon, 12 Oct 2020, Mikhail Gavrilov wrote:
> I have a question.
> What happens when dd writes data to a missing device?
>
> For example:
> # dd
> if=/home/mikhail/Downloads/Fedora-Workstation-Live-x86_64-Rawhide-20201010.n.0.iso
> of=/dev/adb
>
> Today I and wrong
Hi folks!
I have a question.
What happens when dd writes data to a missing device?
For example:
# dd
if=/home/mikhail/Downloads/Fedora-Workstation-Live-x86_64-Rawhide-20201010.n.0.iso
of=/dev/adb
Today I and wrongly entered /dev/adb instead of /dev/sdb,
and what my surprise was when the data
Hi Sam / Theirry,
On Wed, 2 Sep 2020 at 12:14, Sumit Semwal wrote:
>
> Some Poco F1 phones from Xiaomi have a FHD+ video mode panel based on the
> Novatek NT36672A display controller; Add support for the same.
This latest version (v7) had all the outstanding comments fixed, and
Bjorn has also gi
Some Poco F1 phones from Xiaomi have a FHD+ video mode panel based on the
Novatek NT36672A display controller; Add support for the same.
Most of the panel data is taken from downstream panel dts, and is converted to
drm-panel based driver by me.
It has been validated with v5.9-rc1 based drm-misc-
On Mon, Aug 13, 2018 at 7:40 PM Rishabh Bhatnagar wrote:
>
> From: Rishabh Bhatnagar
>
> Drivers that are registered at an initcall level may have to
> wait until late_init before the probe deferral mechanism can
> retry their probe functions. It is possible that their
> dependencies were resolve
On 2018-08-13 10:39, Rishabh Bhatnagar wrote:
From: Rishabh Bhatnagar
Drivers that are registered at an initcall level may have to
wait until late_init before the probe deferral mechanism can
retry their probe functions. It is possible that their
dependencies were resolved much earlier, in some
From: Rishabh Bhatnagar
Drivers that are registered at an initcall level may have to
wait until late_init before the probe deferral mechanism can
retry their probe functions. It is possible that their
dependencies were resolved much earlier, in some cases even
before the next initcall level. Invo
On Fri, Aug 10, 2018 at 11:52 PM Rishabh Bhatnagar
wrote:
>
> Drivers that are registered at an initcall level may have to
> wait until late_init before the probe deferral mechanism can
> retry their probe functions. It is possible that their
> dependencies were resolved much earlier, in some case
Drivers that are registered at an initcall level may have to
wait until late_init before the probe deferral mechanism can
retry their probe functions. It is possible that their
dependencies were resolved much earlier, in some cases even
before the next initcall level. Invoke one probe retry cycle
a
On 2018-08-10 00:10, Rafael J. Wysocki wrote:
On Fri, Aug 10, 2018 at 12:30 AM, wrote:
On 2018-08-06 01:53, Rafael J. Wysocki wrote:
On Fri, Aug 3, 2018 at 12:20 AM, Sodagudi Prasad
wrote:
From: RAFAEL J. WYSOCKI
Date: Wed, Aug 1, 2018 at 2:21 PM
Subject: Re: [PATCH] dd: Invoke one
On Fri, Aug 10, 2018 at 12:30 AM, wrote:
> On 2018-08-06 01:53, Rafael J. Wysocki wrote:
>>
>> On Fri, Aug 3, 2018 at 12:20 AM, Sodagudi Prasad
>> wrote:
>>>>
>>>> From: RAFAEL J. WYSOCKI
>>>> Date: Wed, Aug 1, 2018 at 2:21 PM
>>
On 2018-08-06 01:53, Rafael J. Wysocki wrote:
On Fri, Aug 3, 2018 at 12:20 AM, Sodagudi Prasad
wrote:
From: RAFAEL J. WYSOCKI
Date: Wed, Aug 1, 2018 at 2:21 PM
Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every
initcall level
To: Rishabh Bhatnagar
Cc: "Rafael J. Wy
On Fri, Aug 3, 2018 at 12:20 AM, Sodagudi Prasad
wrote:
>> From: RAFAEL J. WYSOCKI
>> Date: Wed, Aug 1, 2018 at 2:21 PM
>> Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every
>> initcall level
>> To: Rishabh Bhatnagar
>> Cc: "Rafael J.
From: RAFAEL J. WYSOCKI
Date: Wed, Aug 1, 2018 at 2:21 PM
Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every
initcall level
To: Rishabh Bhatnagar
Cc: "Rafael J. Wysocki" , Greg Kroah-Hartman
, Linux Kernel Mailing List
, ckad...@codeaurora.org,
ts...@codeaurora.o
On Wed, Aug 1, 2018 at 11:18 PM, wrote:
> On 2018-07-24 01:24, Rafael J. Wysocki wrote:
>>
>> On Mon, Jul 23, 2018 at 10:22 PM, wrote:
>>>
>>> On 2018-07-23 04:17, Rafael J. Wysocki wrote:
On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar
wrote:
>
>
> Drivers
On 2018-07-24 01:24, Rafael J. Wysocki wrote:
On Mon, Jul 23, 2018 at 10:22 PM, wrote:
On 2018-07-23 04:17, Rafael J. Wysocki wrote:
On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar
wrote:
Drivers that are registered at an initcall level may have to
wait until late_init before the prob
On Mon, Jul 23, 2018 at 10:22 PM, wrote:
> On 2018-07-23 04:17, Rafael J. Wysocki wrote:
>>
>> On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar
>> wrote:
>>>
>>> Drivers that are registered at an initcall level may have to
>>> wait until late_init before the probe deferral mechanism can
>>> r
On 2018-07-23 04:17, Rafael J. Wysocki wrote:
On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar
wrote:
Drivers that are registered at an initcall level may have to
wait until late_init before the probe deferral mechanism can
retry their probe functions. It is possible that their
dependencies
On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar
wrote:
> Drivers that are registered at an initcall level may have to
> wait until late_init before the probe deferral mechanism can
> retry their probe functions. It is possible that their
> dependencies were resolved much earlier, in some cases
Drivers that are registered at an initcall level may have to
wait until late_init before the probe deferral mechanism can
retry their probe functions. It is possible that their
dependencies were resolved much earlier, in some cases even
before the next initcall level. Invoke one probe retry cycle
a
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Wen Xiong
[ Upstream commit f36ea50ca0043e7b1204feaf1d2ba6bd68c08d36 ]
When formatting NVMe to 512B/4K + T10 DIf/DIX, dd with split op returns
"Input/output error". Looks block l
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Wen Xiong
[ Upstream commit f36ea50ca0043e7b1204feaf1d2ba6bd68c08d36 ]
When formatting NVMe to 512B/4K + T10 DIf/DIX, dd with split op returns
"Input/output error". Looks block l
From: Wen Xiong
[ Upstream commit f36ea50ca0043e7b1204feaf1d2ba6bd68c08d36 ]
When formatting NVMe to 512B/4K + T10 DIf/DIX, dd with split op returns
"Input/output error". Looks block layer split the bio after calling
bio_integrity_prep(bio). This patch fixes the issue.
Below is ho
From: Wen Xiong
[ Upstream commit f36ea50ca0043e7b1204feaf1d2ba6bd68c08d36 ]
When formatting NVMe to 512B/4K + T10 DIf/DIX, dd with split op returns
"Input/output error". Looks block layer split the bio after calling
bio_integrity_prep(bio). This patch fixes the issue.
Below is ho
On Thu 30-11-17 22:01:03, Wu Fengguang wrote:
> On Thu, Nov 30, 2017 at 02:50:16PM +0100, Michal Hocko wrote:
> > On Thu 30-11-17 21:38:40, Wu Fengguang wrote:
> > > Hello,
> > >
> > > It looks like a regression in 4.15.0-rc1 -- the test case simply run a
> > > set of parallel dd's and there seems
On Thu, Nov 30, 2017 at 10:08:04PM +0800, Fengguang Wu wrote:
[ 78.848629] dd: page allocation failure: order:0,
mode:0x1080020(GFP_ATOMIC), nodemask=(null)
[ 78.857841] dd cpuset=/ mems_allowed=0-1
[ 78.862502] CPU: 0 PID: 6131 Comm: dd Tainted: G O 4.15.0-rc1
#1
[ 78.848629] dd: page allocation failure: order:0,
mode:0x1080020(GFP_ATOMIC), nodemask=(null)
[ 78.857841] dd cpuset=/ mems_allowed=0-1
[ 78.862502] CPU: 0 PID: 6131 Comm: dd Tainted: G O 4.15.0-rc1
#1
[ 78.870437] Call Trace:
[ 78.873610]
[ 78.876342] dump_stack
ivers rely on atomic allocations.
I just wonder if any changes make the pressure more tight than before.
It may not even be a MM change -- in theory drivers might also use atomic
allocations more aggressively than before.
[...]
[ 71.088242] dd: page allocation failure: order:0,
mode:0x10
. So the failure really depends on the
state of the free memory and that can vary between runs depending on
timing I guess. So I am not really sure this is a regression. But maybe
there is something reclaim related going on here.
[...]
> [ 71.088242] dd: page allocation failure: order:0,
&
On Tue, May 03, 2016 at 08:07:39AM -0700, Greg KH wrote:
> On Tue, May 03, 2016 at 03:11:26PM +0200, Thierry Reding wrote:
> > On Tue, Mar 08, 2016 at 11:15:22PM +0800, Yi Zhang wrote:
> > > the driver_data may be used for sanity check, it fails the
> > > probe() if driver_data is NULL after it is
On Tue, May 03, 2016 at 03:11:26PM +0200, Thierry Reding wrote:
> On Tue, Mar 08, 2016 at 11:15:22PM +0800, Yi Zhang wrote:
> > the driver_data may be used for sanity check, it fails the
> > probe() if driver_data is NULL after it is re-triggered.
> > for example, soc_probe() in sound/soc/soc-core.
On Tue, Mar 08, 2016 at 11:15:22PM +0800, Yi Zhang wrote:
> the driver_data may be used for sanity check, it fails the
> probe() if driver_data is NULL after it is re-triggered.
> for example, soc_probe() in sound/soc/soc-core.c
>
> Signed-off-by: Yi Zhang
> ---
> drivers/base/dd.c | 3 ++-
> 1
the driver_data may be used for sanity check, it fails the
probe() if driver_data is NULL after it is re-triggered.
for example, soc_probe() in sound/soc/soc-core.c
Signed-off-by: Yi Zhang
---
drivers/base/dd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dd
From: Alan Tull
Version 2 :
* Get regulator_init_data from platform data or device tree.
* One regulator per pmbus part.
* Clean up Kconfig and #includes.
This set of patches adds regulator support to pmbus_core.c and to
ltc2978.c. Other pmbus parts can use this to add their own
regulator
Move both functions after driver_deferred_probe_trigger() in the source file
since upcoming patch will need to call the _trigger from _add.
Move also the _del so the functions will be kept together.
Signed-off-by: Peter Ujfalusi
---
drivers/base/dd.c | 40
up
On 03/22/2014 05:52 PM, Francis Moreau wrote:
> Hello,
>
> I'm posting here because it might be a behaviour related to the kernel
> internals that I can't explain from my user point of view :)
>
> Basically I'm doing this:
>
> mount -o bind /dev/ /mn
sically I'm doing this:
>>
>> mount -o bind /dev/ /mnt/dev &&
>> chroot /mnt dd bs=440 conv=notrunc count=1 if=gptmbr.bin of=/dev/loop0
>> umount /mnt/dev
>>
>> but umount gives the following error: "umount: /mnt/dev: target is busy"
On Sat, Mar 22, 2014 at 05:52:24PM +0100, Francis Moreau wrote:
> I'm posting here because it might be a behaviour related to the kernel
> internals that I can't explain from my user point of view :)
>
> Basically I'm doing this:
>
> mount -o bind /dev/ /mnt
Hello,
I'm posting here because it might be a behaviour related to the kernel
internals that I can't explain from my user point of view :)
Basically I'm doing this:
mount -o bind /dev/ /mnt/dev &&
chroot /mnt dd bs=440 conv=notrunc count=1 if=gptmbr.bin of=/dev/loop0
te:
>>>>> Alex,
>>>>>
>>>>> We noticed some perf-stat.cpu-migrations changes by your commit
>>>>
>>>> Thanks for your wonder testing, Fengguang!
>>>> How many CPU in your system and how many dd task running?
>>
;> We noticed some perf-stat.cpu-migrations changes by your commit
> >>
> >> Thanks for your wonder testing, Fengguang!
> >> How many CPU in your system and how many dd task running?
> >
> > For the case
> >
> > kbuildx/micro/dd-wri
hanks for your wonder testing, Fengguang!
>> How many CPU in your system and how many dd task running?
>
> For the case
>
> kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd
>
> It's a KVM with 4 CPUs, 16G memory. There are 4 virtual disks, on top
> of each
On Mon, Dec 23, 2013 at 01:19:04PM +0800, Alex Shi wrote:
> On 12/22/2013 08:30 AM, fengguang...@intel.com wrote:
> > Alex,
> >
> > We noticed some perf-stat.cpu-migrations changes by your commit
>
> Thanks for your wonder testing, Fengguang!
> How many CPU in yo
On 12/22/2013 08:30 AM, fengguang...@intel.com wrote:
> Alex,
>
> We noticed some perf-stat.cpu-migrations changes by your commit
Thanks for your wonder testing, Fengguang!
How many CPU in your system and how many dd task running?
>
> 6eb8b571283e64e96ca1a91aad085f9e08f857f0 i
718f6494 6eb8b571283e64e96ca1
--- -
37779 ~40%+115.2% 81288 ~50%
kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10dd
37779 +115.2% 81288 TOTAL
proc-vmstat.pgscan_direct_normal
kbuildx/micro/dd-write/4HDD-JBOD-cfq-ext4-10
On Tue, Nov 06, 2007 at 10:04:51PM +0100, Milan Broz wrote:
> Petar Bogdanovic wrote:
> > I experience some strange problems with my loopback-on-ext3-setup.
> > After creating a plain `zeroed' dummy-file and doing a /dev/loop/0 on
> > it, every dd or mke2fs hangs while do
On Tue, Nov 06, 2007 at 10:04:51PM +0100, Milan Broz wrote:
> Petar Bogdanovic wrote:
> > I experience some strange problems with my loopback-on-ext3-setup.
> > After creating a plain `zeroed' dummy-file and doing a /dev/loop/0 on
> > it, every dd or mke2fs hangs while do
Petar Bogdanovic wrote:
> I experience some strange problems with my loopback-on-ext3-setup.
> After creating a plain `zeroed' dummy-file and doing a /dev/loop/0 on
> it, every dd or mke2fs hangs while doing certain write()s. Here are the
> steps just in order to show, how si
Hi,
I experience some strange problems with my loopback-on-ext3-setup.
After creating a plain `zeroed' dummy-file and doing a /dev/loop/0 on
it, every dd or mke2fs hangs while doing certain write()s. Here are the
steps just in order to show, how simple the setup is:
1) create a
On 2/8/07, Oleg Verych <[EMAIL PROTECTED]> wrote:
> Check to see if `${CROSS_COMPILE}mkimage` exists and if not, fall back to
> the standard `mkimage`
Why this can't be done by
PATH=$CROSS_COMPILE:$PATH
in your environment?
because it wouldnt matter ? the tool is called
"$CROSS_COMPILE-mk
On Thu, 8 Feb 2007 06:24:40 +0100 Oleg Verych <[EMAIL PROTECTED]> wrote:
> If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> with "dash" (very good `sh' equivalents) will fail.
Does the kernel presently build with that shell?
-
To unsubscribe from this list: send the line
Hallo.
search-a-little-harder-for-mkimage.patch
--
Subject: search a little harder for mkimage
From: "Mike Frysinger" <[EMAIL PROTECTED]>
> Check to see if `${CROSS_COMPILE}mkimage` exists and if not, fall back to
> the standard `mkimage`
Why
Hi,
With recent linux distributions (using NPTL), I noticed that dd can hang
waiting on a futex when being killed. The problem sould be reproduceable
with the following script :
---$<---$<---$<---$<---$<---$<---$<
#!/bin/sh
echo 'When y
On Wed, 16 Mar 2005 15:31:14 +0100, Colin Leroy <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Using 2.6.10 and 2.6.11, trying to use dd from the ide cdrom in my
> Ibook G4 fails like this:
> /dev/hdc:
> HDIO_GET_MULTCOUNT failed: Invalid argument
> IO_support = 0 (d
Hi,
Using 2.6.10 and 2.6.11, trying to use dd from the ide cdrom in my
Ibook G4 fails like this:
[EMAIL PROTECTED] /usr/src/linux-2.6.10]$ dd if=/dev/hdc of=/dev/null
dd: reading `/dev/hdc': Input/output error
0+0 records in
0+0 records out
[EMAIL PROTECTED] /usr/src/linux-2.6.10]$ dmes
Hi,
I don't where else to send this ... so please send it to the right person if this is
the wrong address.
Below is a bug report. Please let me know if you can look at it.
Thanks
Marc
[1.] One line summary of the problem:
dd if=/dev/sdb of=/dev/null bs=64k makes fast system *slow
Mikael Pettersson wrote:
> There's a known bug in dd where it incorrectly attempts to truncate
> the output file even though it's a block device.
dd also attempts to truncate a character device, therefore fails in the
same way.
The kernel should probably return EINVAL for this r
On Mon, 22 Jan 2001 23:23:36 -0600 (CST), Thomas Molina wrote:
>[1.] One line summary of the problem: seek= parameter for dd under 2.4.0
>gives permission denied error
>[2.] Full description of the problem/report:I was creating a new
>root+boot disk for 2.4.0 this evening. I issued
[1.] One line summary of the problem: seek= parameter for dd under 2.4.0
gives permission denied error
[2.] Full description of the problem/report:I was creating a new
root+boot disk for 2.4.0 this evening. I issued the command:
dd if=/tmp/rootfs.gz of=/dev/fd0 bs=1k seek=335
and got the error
David Santinoli wrote:
> On Fri, Jan 12, 2001 at 07:53:14PM -0800, Rob Landley wrote:
> > If I do the dd line in the title under 2.4.0 I get an
> > out.txt file of 591 bytes.
> And it's the same under 2.2.x, too.
>
> > dd says it completes happily even when
On Fri, Jan 12, 2001 at 07:53:14PM -0800, Rob Landley wrote:
> If I do the dd line in the title under 2.4.0 I get an
> out.txt file of 591 bytes.
And it's the same under 2.2.x, too.
> dd says it completes happily even when copying from
> random. 0+100 records in, 0+100 records
In article <[EMAIL PROTECTED]> you wrote:
> If I do the dd line in the title under 2.4.0 I get an
> out.txt file of 591 bytes.
/dev/random will only give you as much bytes as are available. and even then
you should not do it cause you drain the random pool. Use /dev/urandom
instead
--- David Ford <[EMAIL PROTECTED]> wrote:
> Rob Landley wrote:
>
> > If I do the dd line in the title under 2.4.0 I get
> an
> > out.txt file of 591 bytes.
>
> It isn't broken, you have no more entropy. You must
> have some system
> activity of va
> dd says it completes happily even when copying from
> random. 0+100 records in, 0+100 records out. It
This means that dd completed 100 reads, and none of them were of the
requested length (1 bytes).
> takes about thirty seconds to finish on the dual
> gigahertz processor i
Rob Landley wrote:
> If I do the dd line in the title under 2.4.0 I get an
> out.txt file of 591 bytes.
It isn't broken, you have no more entropy. You must have some system
activity of various sorts before you regain some entropy. Moving the mouse
around, hitting keys, etc, will
If I do the dd line in the title under 2.4.0 I get an
out.txt file of 591 bytes.
If I do the same thing from /dev/zero, I get the
expected 1,000,000 byte file.
I've shoehorned 2.4.0 into a fresh red hat 7.0 install
which could quite easily be a bad thing, yes ripped
out their strange gc
On Thu, Nov 16, 2000 at 03:02:31AM -0500, Alexander Viro wrote:
: On Thu, 16 Nov 2000, Mikael Pettersson wrote:
:
:: dd implements the seek=NNN option by calling ftruncate() before
:: starting the write. This is where 2.4.0-test10 breaks, since
:: ftruncate on a block device now provokes an
On Thu, Nov 16, 2000 at 06:53:30AM -0500, Alexander Viro wrote:
> > I didn't know about notrunc. Yet another GNU invention?
>
> Maybe, but I doubt it. Anyway, it made its way into 4.4BSD, it's present
> in Solaris, it's in SuS and AFAIK in POSIX.
Yes (for 1003.2-1992).
It is not in 4.3BSD.
-
To
27;t modify the current position
at all. Try and you'll see. Besides, WTF _is_ lseek() for a character
device?
> My guess is that dd uses ftruncate because that's correct for
> regular files and has happened to also work (as an alias for
> lseek) for devices.
>
> > Use
On Thu, 16 Nov 2000, Alexander Viro wrote:
> And what kind of meaning would you assign to truncate on floppy?
On a block or char device, truncate == lseek seems reasonable.
My guess is that dd uses ftruncate because that's correct for
regular files and has happened to also work (as
On Thu, 16 Nov 2000, Mikael Pettersson wrote:
> I noticed because I needed to build a boot floppy with an
> initial ram disk under 2.4.0-test11pre5. The standard recipe
> (Documentation/ramdisk.txt) basically goes:
> - dd if=bzImage of=/dev/fd0 bs=1k
> notice how many blocks d
2.4.0-test10 broke `dd' for block devices, due to the following
change to do_sys_truncate & do_sys_ftruncate:
diff -u --recursive --new-file v2.4.0-test9/linux/fs/open.c linux/fs/open.c
--- v2.4.0-test9/linux/fs/open.cSun Oct 8 10:50:33 2000
+++ linux/fs/open.c Thu Oct 26
[EMAIL PROTECTED] wrote...
> kernel BUG at vmscan.c:102!
I hit the same bug() an hour ago.
It was preceeded by a complete system lock up (not even sysrq worked)
and then fsck oopsed after triggering the above bug.
The lockup happened whilst I was diffing two kernel trees.
Seems large amounts of
Linux native
root@pcx4168:~# dd if=/dev/hdc2 of=/dev/hda2 bs=32k
invalid operand:
CPU:0
EIP:0010:[]
EFLAGS: 00010282
eax: 001c ebx: 0200 ecx: c12ea000 edx:
esi: c11f6448 edi: 0001 ebp: 0762e045 esp: c12ebecc
ds: 0018 es: 0018 ss: 0018
Process kswapd
85 matches
Mail list logo
